Detecting the Impossible: Serverless C2 in the Cloud

There are certain sophisticated threat behaviors that are generally considered “impossible” to detect on the network, which are both tedious and challenging for security teams to protect against. These include the use of encryption by attackers, fileless malware that exploits applications commonly used for justified activity to execute malicious code, insider threats that are hidden within normal business operations and non-malware-based lateral movement that blends in as attackers systematically move through a network in search of data or assets to exfiltrate.

As if these threats weren’t enough for security teams to grapple with, the discovery of a new exploitation technique—serverless command and control (C2) running in the cloud—is only making their jobs more difficult. My team and I uncovered a combination of these sophisticated techniques when working with a client in the financial services industry.

The Hard Things About Hard Things (in the SOC)

First, the C2 server was using Transport Layer Security (TLS) encryption for the communication channel. TLS encryption is common on today’s networks and designed to protect the transfer of data and information. However, this is also why attackers use it, since much of the existing security tools are blind to encrypted data.

Second, the C2 server (which is used by attackers to maintain communications with compromised systems) was actually serverless code in the Azure cloud. Therefore, all that is seen on the network is an encrypted tunnel to a subdomain of azurewebsites.net. In many networks, there can be thousands of unique sessions per day, to hundreds of subdomains of azurewebsites.net. To make matters worse, traditional approaches to TLS fingerprinting (such as JA(3)) are quite ineffective at making sense of this traffic, because there is usually a homogenous mix of background updaters, web browsers, business productivity apps, IoT clients and more that interact with the Azure cloud.

Making matters worse, the malware in question persists as an Office add-in, which complicates detection on both the network and the endpoint itself. This malware only runs when certain Office applications are started (which could be frequent based on the victim). And because it runs inside the Office process, it is all the more difficult to detect on the endpoint. Worse yet, it is possible to load malicious add-ins without elevated permissions, user-interventions or notifications. And, the pièce de résistance: Malicious add-ins can download and run other executables without user knowledge leveraging normal user-level permissions.

Understanding the Malware

MWR Labs’ William Knowles wrote about Office persistence, highlighting various persistence techniques including one known as WLL add-ins for Word. In short, users can:

1. Take a malicious DLL
2. Put it in a directory that unprivileged users have access to (%appdata%RoamingMicrosoftWordstartup)
3. Change the extension from .dll to .wll

And that’s it. Word will run the code in the .dll every time the application is opened. Similar capabilities exist for Excel, PowerPoint and other apps in the Office suite.

But what if add-ins are disabled? It doesn’t matter—even if the user has configured Word to disable add-ins, that setting will disable all add-ins, except WLLs. Also as mentioned above, the attacker can use the WLL to download and run other executables.But if the WLL is totally self-contained (meaning it doesn’t need to download and run other files), then examining the process will show nothing because the entire code is running in Word’s process space.

Admittedly, one disadvantage to a completely self-contained .wll is that static detection is easier since the single .wll likely will contain a high percentage of suspicious functionality. Therefore, the attacker in this case created an add-in that is just a simple loader and clean-up for other executables. This seemed to be intended to evade any static analysis detection. Adding a few red-herring imports that are frequently used by legitimate programs and not malware made detection even less likely.

Detecting the Impossible

Although it may sound like this type of exploitation is impossible to detect, there are ways in which organizations can protect themselves against it using advanced network traffic analysis techniques.

Previous approaches to network security have been defeated by many modern threat scenarios because they are locked within the confines of sessions and protocols. The reality is that threat detection is based on understanding behaviors and applications as well as how these manifest into sessions and protocols over (potentially large durations of) time.

In this case, it’s important to factor in that different scenarios can play out when users start up Microsoft Word depending on the version of Office, how it is licensed and the version of Windows that is running, among others. This is a great way to apply machine learning, learn the sequence and then identify with high confidence when Microsoft Word (or any other application) is launched. For instance, looking at the sequence shown below, a handful of requests are made, in order, to the following locations as the application starts up:

1. Several [a-z]-ring.msedge.net connections
2. Possible ocws.officeapps.live.com connections
3. And finally, fp.msedge.net

Now let’s see what happens if an add-in is loaded that communicates on the network:

1. Several <a single letter>-ring.msedge.net connections
2. <request(s) from add-in(s)>
3. Possible ocws.officeapps.live.com connections
4. And finally, fp.msedge.net

To identify network-connected add-ins such as this, users simply need to:

1. Identify the “network fingerprint” of Word starting up
2. Identify the additional add-in connections
3. Alert to the outliers, i.e. “add-in connections that are not common”

Sounds simple enough. Of course, very few technologies really give the defenders the ability to define detection patterns such as this. Never mind that these patterns could change all the time, so simply hard-coding them into the detection solution isn’t much of an option. As mentioned previously, machine learning can help, but what is also needed is a framework and language for expressing attacker tactics, techniques and procedures (TTPs). With the ability to write true TTP-level rules like this, we were not only able to catch this encrypted and serverless C2, but also identify all rogue add-ins with this single detection.

Although this new exploitation discovery can be terrifying from a threat detection and hunting perspective, it can be protected against as long as organizations have access to the latest in network traffic analysis. With advances in machine learning and automation, organizations can effectively arm their networks against an ever-evolving attack landscape.

— Gary Golomb