From Detonation to Detection: The Sandbox Now Writes the Rules

Intended readership: SOC analysts, malware analysts, detection engineers, threat hunters, incident response teams, MSSPs, SOC managers, CISOs.

Available in: Group-IB Malware Detonation Platform

Malware has never been cheaper to produce. AI tooling helps attackers write, repackage, and mutate samples faster than signature feeds can catalogue them, and more of those samples are built to recognize an analysis environment and stay quiet inside it. That puts the weight on one question: what does this specific file do, and how quickly can we make sure it cannot do it again?

A sandbox has always answered the first half of that question. You bring it a file, and the report tells you what the file dropped, where it hid, and which C2 server it connected to.

The second half is where most organizations stall. Understanding how a sample behaves and being able to detect that behavior are different jobs. In the best-case scenario, organizations have detection engineers who can do it. Everyone else hands the report to whoever analyzed the sample and hopes for the best.

This release removes that step. The Group-IB Malware Detonation Platform now derives detection logic directly from the behavior observed during detonation, producing indicators of compromise, Sigma rules, and threat hunting queries.

Keep reading to see what now comes out of a detonation…

Why detonation matters more than it used to

Three shifts have changed what a malware detonation platform has to deliver.

Every sample is closer to a first sighting. Generative AI has lowered the skill needed to write working malware and made it trivial to spin up variants of existing code. Group-IB’s High-Tech Crime Trends Report 2026 describes the result as cybercrime becoming industrialized. A hash, a family signature, or a feed entry only helps if someone has already seen that exact thing. Increasingly, nobody has, and running the file to watch what it does is the only way to find out.

Malware is getting better at hiding from analysis. Environment checks and delayed execution have moved from advanced tooling into commodity malware. A sandbox that presents a generic virtual machine increasingly gets a sample that does nothing, and a clean report that means nothing. We come back to how the platform handles this below.

The window to act is shrinking. Attackers move from initial access to impact faster than before, and a technique that works once is reused against the next host and the next organization. An analysis that ends with a report, and then waits days for someone to turn it into a detection rule, leaves that window open. What counts now is not only how well you understand a sample, but how quickly that understanding becomes a control.

Taken together, the value of a sandbox has moved. Explaining a sample is table stakes. What matters is closing the gap between detonation and detection, and that gap is exactly where the shortage of detection engineers hurts most. This release is built to close it.

What a sandbox was for

Until several years ago, our sandbox was essentially a binary classifier, much like most sandboxes at the time. A file went in, a verdict came out, with enough explanation to justify it.

Then we built it into an analytical sandbox. It no longer answered only “Is this bad?” but also “What exactly did it do?”: the process tree, the configuration, the artifacts, the memory dumps, and a graph of the entire execution. That replaced work a malware analyst would otherwise have to do manually in a virtual machine, watching the system change and drawing conclusions from those changes.

That part of the work is essentially finished. You can see everything the sample did, which raises the question of what a sandbox is for next.

Detonation is one step in a bigger process. When something gets through, investigators and threat hunters work back through telemetry to establish what was actually done, while researchers take the artifacts and work out what the thing is capable of, so the first group knows what to look for. The response cycle then reaches its final stage: applying the lessons learned. In practice, that means creating new detection rules so the same technique cannot succeed again.

This is where malware analysis has always been heading. If the platform can tell that a file is malicious, and can tell which objects and behaviors within the execution are the malicious ones, it has what it needs to write those rules itself.

The part that needs a detection engineer

Making sure the same thing cannot work twice means creating new detection content, which requires specialist expertise.

In an organization with a detection engineering team, the malware analyst now has to explain the sample to the engineers. This introduces a handover between two specialists who need to communicate the details of something intricate.

In an organization without one, the analyst writes the rules themselves. They may be highly skilled at malware analysis but lack specialist detection engineering expertise, which can affect the quality of the resulting rules.

In an organization that has neither, whether because the budget does not stretch that far or because those specialists are simply unavailable in that market, the rule does not get written at all. The report is read, the incident is closed, and nothing about the defenses changes.

What comes out of a detonation now

All of these cases have the same solution. If the detection logic comes out of the detonation itself, nobody has to write it, and this is what the Group-IB Malware Detonation Platform now does.

The platform produces four types of output, all derived from observed behavior:

Indicators of compromise: file hashes and dropped file names, C2 domains and IP addresses, URI paths and mutex names, registry keys used for persistence, all normalized to a consistent form. The platform separates artifacts produced by the malicious activity from everything else the execution touched. That judgment is what an analyst would otherwise have to make line by line.

Sigma rules, for behavioral detection. Most SIEMs either support Sigma natively or provide tools to translate Sigma rules into their own syntax, making it a common format for detection engineering teams.

Threat hunting queries for searching telemetry for activity that existing controls may have missed.

Suricata and YARA rules will join them within the next month: Suricata for intrusion detection systems analyzing network traffic, and YARA for tools scanning files and memory.

The platform now turns every detonation into detection logic: the sample reveals its behavior once, and that behavior becomes the rule that waits for it.

Figure 1. One detonation, four kinds of detection content

The list now covers the pyramid of pain from top to bottom, which is what makes the output last. Indicators expire as soon as the attacker recompiles the malware or moves to a new domain; behavioral rules only stop working when the malware is genuinely rewritten. Generating both means one detonation gives you detections that trigger immediately and detections that keep working after the indicators stop matching.

Figure 2. Pyramid of pain, now covered by detonation and rule generation in full

What makes the generated rules useful?

Automatically generating a rule is only useful if the malware actually reveals behavior worth detecting while it is being observed. Modern samples often check the environment before they act, looking for virtualization artifacts, an empty user profile, the wrong locale or time zone, missing business applications, or a machine that is not joined to a domain. If those checks suggest a lab environment, the sample may remain dormant, leaving little to nothing useful in the report.

The Malware Detonation Platform addresses this by mirroring the customer’s own infrastructure rather than presenting the sample with a generic virtual machine. Delayed payloads are handled in a similar way: the platform determines the likely attack scenario and adjusts the environment to meet the conditions the sample is waiting for, including triggers set for a later date or after a specified number of reboots.

The rules are generated from behavior observed in that environment, so they reflect what this particular sample actually did rather than what malware from the same family is generally known to do. Rules for known families are already available in security engines, threat intelligence feeds, and public repositories. They are not the reason you brought this file to a sandbox.

Built for full automation

The design goal was to eliminate the manual step rather than simply give you a better dashboard.

A file goes into the sandbox and the rules come out the other side, where a SOAR collects them and pushes them into your security controls. The process no longer depends on someone manually reading the report or handing it over to another specialist.

Your SOC gets that time back for the tasks that actually need a person looking at them. For a team with neither malware analysts nor detection engineers, automation provides something else: a process they did not previously have.

Analysis used to end with a report. It now ends with the defenses updated.

Now covering both major platforms

Detonation coverage now extends to Linux, in alpha on Ubuntu 24.04, with the same depth as the Windows environment: process trees, file system activity, kernel-level events, a behavioral graph, and a video capture of the execution. Linux-tagged samples are routed to it automatically, and 308 Linux detection signatures now carry MITRE ATT&CK mappings so they stay in the report’s signature panel.

This means the detection logic described above can now be generated across both Windows and Linux environments.

Why people run their own sandbox

There is a reason large security teams run analytical sandboxes such as Malware Detonation Platform inside their own perimeter rather than uploading samples to a public service.

Submitting a sample to a public service can expose the fact that it has been discovered and analyzed. For a bank or government body that wants to identify the perpetrators, that is a bad trade. The analysis therefore stays internal, which means the detection content has to be produced internally as well.