In this post I thought I would share some information on Powershell download cradles I put together recently. I’m going to provide an overview, highlighting areas I found interesting thinking about detection from both network and endpoint views.

I have also included a link to a results summary and a noisemaker script I have been using to test. I focused on Powershell download cradles, or more specifically cradles that I could execute a Powershell payload. I have also not included all the .NET methods that seem to be effectively the same as Powershell WebClient.

So what is a cradle and why do I care?

A download cradle is a single line command for download and code execution. Typically seen at the end of a maldoc or exploit, implementing the second stage download of exploit/infection within the attack lifecycle. A download cradle can also be part of a persistence mechanism, tooling or execution at other attack stages when an attacker attempts to download capability or run fileless.

From an evil standpoint - the best download cradles are proxy, credential and https aware so will slide right by a corporate firewall. For defenders, obtaining visibility and focusing detection at a common attack chokepoint, we can minimize impact effectively.

There is a large menu of evil download cradles - a selection with un-obfuscated CommandLine

Network Detection

Network is usually the easiest point of visibility but can be noisy looking at unfiltered events. I have found interesting use cases baselining current activity then spotting deviations from normal filtering on User-Agent, content, http method, destination domain and URL.

Understanding the traffic behavior for each cradle and whitelisting trusted components is a good start on building out detection.

Download Cradle summary table

Endpoint Detection

Endpoint visibility enables the lions share of quality detection opportunities and bypasses network encryption limitations. I see several main visibility areas that highlight the benefit of modern endpoint capability in addition to network monitoring.

Process Image Chains

Some of these process relationships may be legitimate in a large environment so appropriate baselining is recommended. A mature blue team understands expected process image and chain mappings to spot deviation from normal. A mature team is also able to spot new and unusual process paths across multigenerational chains.

Process chain from a cradle triggered by opening a maldoc

Command Line

Considering process command line makes the blue team’s job much easier by adding another whitelistable data point to the process chain stack.

DDE attack (top) and WMI based macro (bottom)

Some of the gaps to this method as a standalone technique is command line obfuscation. Obfuscation is an extreamly large area and to give coverage justice, I have included a link in my references below to some excellent research by Daniel Bohannon (Invoke-CradleCrafter was a huge influence on some of the types of cradles I tested).

This download cradle was generated by Daniel Bohannon's excellent obfuscation toolsets.

From a defenders standpoint, obfuscation can defeat specific command line detection, however itself is an indicator. Understanding process chains and their command line enables defenders to whitelist known good and spot abnormalities.</p>

Its also worthy to note, depending on the obfuscation type - enabling latest Powershell version 5.x script block logging and Windows10 Anti-Malware Scan Interface equipped tools can assist detection of obfuscated Powershell payloads at runtime.

Module loads

Module loads provide another unique visibility point vital for modern endpoint based detection. For an attacker living off the land it is impossible for a download cradle to operate without network based modules. Below you can see an example of Powershell loaded network modules during execution.

Powershell Webclient network module loads Some good examples I picked out of my dataset are:

Powershell.exe loading rasman.dll and rasapi32.dll (Powershell network methods)
Powershell.exe loading ieproxy.dll (Powershell IE COM methods)
Powershell.exe loading dnsapi.dll or winhttp.dll or wininet.dll (Common network modules)
Powershell.exe loading msxml3.dll (Powershell MsXml COM)
Powershell.exe loading qmgrprxy.dll or Microsoft.BackgroundIntelligentTransfer.Management.Interop.dll (Powershell BITS)
Certutil.exe loading wininet.dll
regsvr32.exe loading scrobj.dll and wininet.dll (Squiblydoo)

Keep in mind, the list above is focused on Powershell cradles. I have seen downloaders implemented for COM objects from vbscript and other languages so it may be worth also considering module loads more heuristically - e.g common script interpreters. Module visibility is key.

Network connections

Network connections from the endpoints view provides additional context to detect bad. A mature blue team can collect and baseline network connections by process and user context. In most environments, powershell.exe (and others) would be unexpected connecting to the internet on a standard user endpoint.

Network activity by process - importance of endpoint context

File write events

Despite most Powershell download cradles in my list above being classed as memory resident, there are some that write payloads and artefacts. In the example below of particular interest in the Internet Explorer and Office COM object methods are the cached and *.url link files for downloaded file.

A selection of Powershell Office COM object file writes - url files are link files that will provide path and file downloaded Monitoring for unusual file writes by Powershell and certutil.exe are other simple techniques enabled by visibility that can be used to detect download cradle activity.

Registry

Not all download cradles I looked at had specific registry IOCs that were worth monitoring. An exception is the existence of powershell_RASMANCS and powershell_RASAPI32 tracing keys that are evidence of Powershell network communication.

$Monitor for activity to HKLM\SOFTWARE\Microsoft\Tracing\powershell_RASMANCS and HKLM\SOFTWARE\Microsoft\Tracing\powershell_RASAPI32$

Other Artefacts

I would expect all modern EDR vendors to provide event visibility of the above artefacts as standard. However, in real world situations, agent coverage may be incomplete or we may be getting into the fight late for event telemetry.

With that in mind, a component for download cradle detection is traditional forensic capability. Evidence of execution, registry, event logs or volatile data analysis spotting similar artefacts to the event data above is the obvious starting point. In the example below I have highlighted a prefetch entry with reference to the handle to some of the DLLs listed above.

Evidence of Execution - Powershell Webclient method Microsoft BITS also has some specific forensic artefacts I have previously covered in another post that I have included in my references below.

Final Thoughts

Network and endpoint visibility should be priority of all blue teams. Although focusing on a small section of the attack lifecycle, this post has been an overview of some of the areas I found interesting when thinking about download cradle detection. Understanding offensive technique and forensic artefacts enables blue teams to write high quality detections near the top the pyramid of pain. Correlating this data towards your own visibility levels, blue teams can work towards improvement and optimising resources for both detection and response.

Let me know if you have any questions. I have added my testing results and script here. I would be interested to hear results testing these out on different vendors.