Five steps to safely redeploy live malware

Here’s a quick guide to how we transform sophisticated nation-state malware into a safe and controlled tool. We’ve broken down our process into five practical steps.

1. Analyse

First, obtain all parts of the malware execution chain, often covering everything from the phishing email to the malware executed on the target (Cobalt Strike, RATs, custom malware, etc.).

Then perform an analysis of the full attack. If the attack was obtained based on a publication by another company, you can often use their write-up for guidance. But, be aware that these write-ups are often incomplete and sometimes misleading or wrong. It’s imperative to conduct your own research, which you will use throughout the development process and when following up with blue teams involved in the emulation. Note these important points:

• C2 interactions
• Artifacts on system (dropped files, reg keys, etc)/li>
• Obfuscation methods, decryption keys, etc
• Process injections
• Execution guardrails

2. Defuse

Because we’re working with live malware we intend to execute in customer environments, we must be especially careful when securing it. Defusing involves multiple steps, depending on how complex the malware is. The steps we take are:

1. Disable any connections to the original threat actor’s infrastructure
2. Neutralise any malicious payloads injected into processes or dropped onto the system
3. Run the malware in different testing environments for long periods while monitoring for any remaining connection attempts to attacked controlled infrastructure

3. Transform

Now, it’s time to transform the malware into a tool by bringing it fully under control. This step differs between attacks, but the premise stays the same: apply the absolute minimum number of changes necessary for bringing the malware under our control, as to not taint the TTPs. This often means changing IP addresses and ports used for connecting to the C2 server. In some malware this is a simple byte patch. In other malware, it requires building unpacking and repacking scripts that allow you to change values inside of packed areas. We may also need to update API endpoint domains if the public services the malware depends on have changed since it was created.

4. Rehost

Following the transformations, we start implementing the C2 server from scratch. This involves reverse engineering the C2 protocols from the binaries, extracting encryption keys and commands, and writing a front-end for it in your favourite programming language. After this is built, we can host our own version of the C2 server and interact with the malware exactly like the threat actor would have done.

5. Apply AV Evasion

Any attack used for adversary emulation purposes is an attack that has already been disclosed, otherwise you wouldn’t have malware or intel to work with. When an attack becomes public, most detection teams will implement signatures for it right away.

As such, we must apply some retroactive AV evasion to the malware to keep it from being immediately detected by most any anti-virus. However, applying AV evasion that goes beyond simple static signatures might eliminate important TTPs that belong to the threat actor. This would defeat the purpose of testing against the threat actor’s toolkit, so we have to find a middle ground. We do this by applying AV evasion to the binary that mimics what would happen if the threat actor re-compiled their malware with minor edits and improvements to their codebase. Here are some attributes we consider fine to edit because they could reasonably be expected to change in future versions of the malware:

• The ordering of instructions
• Registers used in instructions
• String encryption keys
• Domain names and IP addresses

Most APT detections rely on weak byte pattern signatures, making them easy to bypass with the edits above. We don’t modify core behaviours like Hell’s Gate, even if that means some flags could be raised by AV. pattern signatures, making them easy to bypass with the edits above. We don’t modify core behaviours like Hell’s Gate. When signatures flag those techniques, we keep them because they’re valuable TTPs for adversary emulation testing.