August 29, 2021

How common are fully automated attacks and are we prepared for them?

It seems to me that the standard defensive toolset is designed for the manual attack model where attackers spend on average ~45+ days within the network.

* We put in place sensors.
* We enrich the data generated by our sensors, send them to a SIEM.
* We use all sorts of tools to analyze the data.
* We write playbooks and write detection signatures to proactively address *known* threats.
* We leverage the ATT&CK matrix to figure out which tactics certain IoCs might indicate.
* We respond, as fast as possible.

But do we respond fast enough? That’s a genuine question for those of you in the industry for decades who’ve seen this stuff. Do you see fully automated attacks? Often? How do you respond?

It’s my hypothesis that the only reason the cybersecurity industry’s current toolsets work at all is because attackers simply aren’t using state-of-the-art techniques. Because all of the tools and strategies I’ve seen are based either on detection tactics that can be countered by the attacker ([behavior emulation](https://www.usenix.org/system/files/conference/woot16/woot16-paper-blackthorne_update.pdf), for example, or system call sequence analysis). Or their calling back to statically defined IPs. Or relying on attacker slowness. Attackers today often manually work their way through network defenses, spending months in the network.

What if they got a little smarter? It would only take one open-source tool for every attacker to instantly operate better. Such a tool could be far more disruptive than Mimikatz or Bloodhound alone I think. I hypothesize that a far more automated and better obfuscated attack is possible through mostly existing research. I’m researching / developing an attack suite designed for automation.

I’m developing this and intend to publish it open-source when it’s done. It’s basically a C2 server which obfuscates the payload provided by the user and adds automated enumeration. It works as follows:

# User configuration

* User assigns its developed or acquired exploits to vulnerable services.
* User assigns its developed or acquired payloads to OS environments in executable binary format.
* User assigns target entry IPs.

The C2 server does the rest.

# Automated Network Traversal

The following steps are all about hiding the payload’s activity from signature detection. But first and foremost, the C2 server automatically injects its own modules to the attacker’s payload and facilitates automated network enumeration. Depending on what services or supply chain exploits the attacker assigns, the tool uses custom versions of Bloodhound and Mimikatz to enumerate the network without the attacker having to write that code or risk making mistakes.

The attacker provides the payload containing the desired effect, and if there is a route to critical machines with the provided exploits, the entire attack is executed potentially in seconds. Depending on how much data the attacker is trying to exfil through the payload, it could take days, but the exfil begins in milliseconds. The manual enumeration phase of the attack is gone.

The attacker’s exploits are also only delivered dynamically if the vulnerable services mapped to them are within reach, so the attacker can purchase or develop exploits to a wide range of services that might be within the targeted network(s), and only risk burning the ones that

## Artifact Trimming

First, the C2 server emulates the payload and flags non-obfuscateable I/O for modification. Basically, it tells the attacker “I can’t protect you from yourself, fix this artifact or you’ll be fingerprinted easily”:

* If a payload prints “I’m evil” to stdout, that can’t be automatically obfuscated away without potentially breaking the program. The attacker must either heed these flags, make modifications, or ignore them and continue.
* Any system calls that have no obfuscation potential are suggested for re-consideration.

## Automated Network Intermediary Routing

* Any web request targets are changed to intermediate IPs. Rather than querying “supervillain.com”, the attack suite will direct this query through some benign intermediary. How this is achieved gets into the weeds, there are many ways. Bottom line is that no outbound traffic will target a C2 server or any suspicious service directly. Web traffic logs are reviewed on a host-by-host basis within the payload to determine which traffic targets are usual. Social networks and public forums are contacted over HTTPS with data encrypted and encoded into benign format.
* C2 server observes the potential end-points, decodes and decrypts the data, and forwards the traffic to its intended target, then sends the response in the same manner.

## Emulator Evasion

Then the C2 server wraps the payload in emulation evasion logic by doing black-box analysis against the most recent release of every popular behavior emulation tool.

* See [**AVLeak, Blackthorne et al**](https://www.usenix.org/system/files/conference/woot16/woot16-paper-blackthorne.pdf) ([**video presentation**](https://www.youtube.com/watch?v=a6yOwvFds78) if preferred, Blackhat 2016).

## Binary Obfuscation

The C2 server then performs advanced binary obfuscation on the resulting executable for every Nth attack entry-point in sweeping attacks (every payload may be uniquely obfuscated, or every 100th payload sent may be, depending on how many versions of the attack are pre-computed for delivery), so the payload delivered to each target is potentially unique:

* C2 uses a genetic-algorithm-based obfuscation program. Reinforcement learning is leveraged.
* C2 traverses executable branches, treating segments of code as black boxes, where it must arrive at the same outcome through different means limited not only to system calls but even register activity.
* Return Oriented Programming (ROP) is introduced as a form of obfuscation. Search [google scholar](https://scholar.google.com/) for academic papers on this there are a few.
* Any system calls are creatively achieved in alternative ways to obfuscate the system call I/O fingerprint. Multiple alternatives are introduced as pseudo random branching conditions.
* If the attacker marks the stage as running with kernel mode privilege, C2 achieves the system call’s objective without using system calls at all.
* Random system calls are introduced between any calls made by the original payload (introducing noise into the I/O analysis channel relied on heavily by EDR solutions)
* Decoy logic noise is of course also introduced. Not dead code, however; each decoy instruction may conditionally execute.
* All statistical usage (patterns: CPU, memory, storage, power) is randomized, evading machine-learning based resource usage pattern detection demonstrated in research.

Each of the above binary obfuscation techniques are designed to either utilize some red-team academic research I’ve read, or counter blue-team detection strategies. That isn’t even the full list. Here’s a pastebin with more: [https://pastebin.com/7uEi8zyy](https://pastebin.com/7uEi8zyy)

## In memory attack? How about in-register.

* Anything written to memory or disk is encoded in the registers. Nothing leaves the registers without encryption and encoding. The encryption key remains in-register.
* The encryption key is cycled frequently.

## Forced Branching Defeat: Many-staged Delivery

Next the C2 server defeats forced branching emulation, by delivering traps in many stages:

* If the attacker is detecting the emulation / VM and behaving innocently, the defender must either make the VM more believable (an unreliable game of cat and mouse, defeated in the above ) or force alternate branching.
* To counter this, before the payload branches toward downloading the malicious code, the program must progress past trapped branches that have a 50% pseudo random chance of executing. This forces the attacker not to discount them as decoy code, force the branch to execute, and after enough of these branches are forced, each calling more code from the command-control server, the C2 server can see that the odds of so many of these 50% chance branches all executing naturally is extremely low. It then withholds the malicious payload by sending a final benign code-set which will not call for any further code. Later when the program is run on the true target without branch forcing, the payload will be sent instead.

## Automated pre-flight test:

* The resulting stages are then executed in a VM against every popular EDR and AV solution and (optionally) sent to VirusTotal. If the result is failure, the stages are re-processed and the user again prompted to fix any previously flagged I/O artifacts which may be triggering detection.

​

Additionally, things like polymorphism in-place on a daily basis, automated clean-up of logs, self-deletion after objective is achieved to make incident response harder, are all interesting possibilities.

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: By filling this form and submitting your commen, you acknowledge, agree and comply with our terms of service. In addition you acknowledge that you are willingly sharing your email address with AiOWikis and you might receive notification emails from AiOWikis for comment notifications. AiOWiksi guarantees that your email address WILL NOT be used for advertisement or email marketting purposes.

This site uses Akismet to reduce spam. Learn how your comment data is processed.