Why SucuriLabs uses specialist models to stop email malware

The tempting way to detect malware in email attachments is to build one large model. Give it every file you see. Ask it one question: is this malicious?

We tried the general approach. It created a practical problem. Training took a long time, and the results were noisy. A model trying to understand every kind of attachment was also learning a lot of differences that had nothing to do with malware.

The fix was not another round of tuning. We changed the shape of the system.

SucuriLabs now routes attachments to specialist models. Each model learns the patterns relevant to one attachment family. For the family with the most variation, we combine several model outputs with a stacked ensemble.

The important idea is simple: a model works better when it has a narrower job and the right context for that job.

The general classifier became the bottleneck

At first, a single model looks easier to operate. There is one training pipeline, one threshold, and one score to put into the email-security decision.

Figure 1 - General classifier architecture

The cost shows up as the system grows. Attachments that people use for normal work can have very different internal structures. Malware authors take advantage of those differences too. They change the content, layout, and surrounding metadata to hide the signals a broad detector expects to see.

A generic model has to learn two unrelated things at the same time:

That is a poor use of training time. The model spends effort learning broad differences between files before it can focus on the signals that matter for a specific attachment. It can also produce noise by treating a feature that is ordinary for one family as suspicious everywhere else.

We could have kept adding data, features, and tuning cycles to that one model. That would have made it bigger, slower, and harder to reason about. Instead, we asked a more useful question: why should one classifier be an expert in everything?

We stopped asking one model to understand every attachment

The new flow starts by identifying the attachment family and sending it to the model built for that job.

Figure 2 - Mixture of expert classifiers architecture

Each expert sees the representation relevant to its own family. That lets it learn the difference between normal variation and meaningful risk without being distracted by unrelated files.

The change also makes the system easier to evolve. When we need to improve one specialist, we do not need to retrain every other specialist. When we see a new evasion pattern, we can investigate it in the part of the pipeline responsible for that attachment family instead of treating it as a mystery inside one large model.

This is a better operational boundary as well as a better modelling boundary. It narrows the question for the model and narrows the investigation for the engineer responsible for improving it.

Embedded files go back through the router

Some attachments contain other files. Looking only at the outer file can miss the strongest signal, because the meaningful evidence may be in an embedded file.

For these container-style attachments, we extract the embedded files and send each one back through the same router. The router selects the appropriate expert for every extracted file, just as it does for a top-level attachment.

We then use stacking to combine the results. The meta-classifier receives the outer file's score and the scores of its embedded files as features, then produces the final risk signal.

Figure 3 - Container files extraction and classification architecture

This is different from a simple vote. The outer-file model and the embedded-file experts answer different questions. The meta-classifier learns how their scores work together instead of treating every score as equally important.

That gives the final decision both views: what the outer file looks like and what the system found inside it. If the embedded files carry the strongest risk signal, their specialist scores are available to the meta-classifier rather than being hidden behind the outer file's score.

That is why the final decision must be evaluated on reviewed examples that were not used to teach the base models. The test is not whether the ensemble looks clever. The test is whether it improves the decision you have to make when an email arrives.

An attachment score is evidence, not the final answer

An attachment can be unusual and still be legitimate. It might come from a trusted sender in a normal conversation. It might also arrive from an unfamiliar sender with an urgent request that does not match the recipient's usual work.

The attachment model sees one part of that story. The wider email-security system sees more:

Combining those signals matters for accuracy and for usability. A high-risk attachment signal can help stop a harmful message before it reaches the inbox. A message that is initially allowed can also be reassessed and remediated when new evidence appears later.

This is the practical advantage of treating the classifier as an enrichment, rather than as a black-box verdict. The system can act on strong evidence and still give security teams the context they need to understand the decision.

What changed for the people using the product

For an engineer, the architecture is a collection of smaller models and one stacked ensemble. For the person receiving email, it is much simpler.

The goal is to keep a malicious attachment from becoming a judgment call in the middle of a busy day. When the evidence is strong, SucuriLabs can block or quarantine the message before it reaches the inbox. When later intelligence changes the assessment, the system can find and remediate the message rather than leaving the recipient to discover the risk first.

That does not mean every unfamiliar attachment is bad, or that any detection system can catch every new threat. It means we can improve the right part of the system as attacks change, while avoiding the noise that makes people ignore security warnings.

The takeaway: multiple specialists beat one bug generalist when the problem has real differences

There is a common instinct to solve a classification problem with the biggest possible model and the biggest possible training set. That is not always the fastest path to a dependable system.

In our case, the general classifier was slow to train and noisy because it was trying to answer too many different questions. Routing attachments to specialists gave each model a clearer job. Stacking gave us an extra layer of judgment where one specialist still needed more than one view.

That is the part worth remembering. Better malware detection did not start with a more complicated model. It started with splitting one broad problem into the smaller problems the system actually needed to solve.