Offensive

Development
Post-Exploitation Tradecraft
in an EDR World

Dominic Chell: x33fcon 2020

 # whoami

• Dominic Chell:

• Based in the UK

• Offensive Security @ MDSec

• Red Team lead for intelligence-led simulations

• Tweets at @domchell

• Author of several open source tools including SharpShooter,

SharpPack, Chameleon, LyncSniper and more

• Research and blogging at https://www.mdsec.co.uk/blog

MDSec Consulting 2020 (c)

 A STORY: THE PERFECT PHISH

MDSec Consulting 2020 (c)

 A STORY: DISCOVERY

MDSec Consulting 2020 (c)

 A STORY: DISCOVERY

MDSec Consulting 2020 (c)

 A STORY: DISCOVERY

MDSec Consulting 2020 (c)

 A STORY: DISCOVERY

MDSec Consulting 2020 (c)

 A STORY: BEAGONE

MDSec Consulting 2020 (c)

 A STORY: BEAGONE

MDSec Consulting 2020 (c)

 A STORY: WHAT DID THEY SEE?

MDSec Consulting 2020 (c)

 A STORY: WHAT DID THEY SEE?

MDSec Consulting 2020 (c)

 INTRODUCTION

• Environments and defences are becoming more

mature, the blue team has home field advantage:

• Command line logging, PowerShell logging,

sandboxes, EDR, EDP, AWL, AMSI, ETW

• Red team engagements have a growing

investment:

• DFIR can quickly burn entire campaigns that may

have taken days or weeks to setup and mature

MDSec Consulting 2020 (c)

 INTRODUCTION

• In this talk we will…

• Examine some of the techniques used by blue teams to detect

post-exploitation tradecraft

• Describe potential ways to evade these detections

• Demonstrate approaches to automate integrating these evasions

in to our toolkits

• Outline how to better protect your intellectual property and

increase DFIR

• Propose an alternate methodology for post-exploitation tradecraft

MDSec Consulting 2020 (c)

 DETECTING POST-EXPLOITATION TRADECRAFT

• Traditional post-exploitation tradecraft historically

involved running OS commands

• LOLbins used to perform certain actions, e.g.

downloading a file using bitsadmin.exe

• Capturing process creation events (ID 4688) allows a blue

team to trivially monitor for and detect this tradecraft

• Can we abstract ourselves from this concept and only

ever operate in code?

• Some steps have been taken to adapt tradecraft:

• execute-assembly introduced .NET execution using fork

and run model

• Beacon Object Files provide an interface to execute C,

in process

MDSec Consulting 2020 (c)

 DETECTING .NET TRADECRAFT: ETW

• Following the introduction of PowerShell defences, red teams

moved to .NET tradecraft

• This in turn led to more focus on detecting .NET tradecraft from

blue teams (https://blog.f-secure.com/detecting-malicious-use-
of-net-part-1/)

• Event Tracing for Windows (ETW) consumers are now

integrated to many EDRs to receive CLR Runtime traces

• This provides visibility of assembly names, namespaces, class

names and method names even in unmanaged surrogates (e.g.
via execute-assembly)

MDSec Consulting 2020 (c)

 DETECTING .NET TRADECRAFT: ETW

https://www.fireeye.com/blog/threat-research/2019/03/silketw-because-free-telemetry-is-free.html

MDSec Consulting 2020 (c)

 EVADING ETW DETECTIONS

• One trivial approach to

avoiding such signatures
is to obfuscate the
assembly, renaming
namespaces, classes
and methods

• Open source
obfuscators such as
ConfuserEx can assist
here

MDSec Consulting 2020 (c)

 EVADING ETW DETECTIONS

MDSec Consulting 2020 (c)

 EVADING ETW DETECTIONS

• The CLR sends its ETW events from user-

land, from within the CLR hosting process

• To prevent ETW events being sent, ntdll!

EtwEventWrite can be patched

MDSec Consulting 2020 (c)

 EVADING ETW DETECTIONS

• Goodbye .NET ETW events:

https://www.mdsec.co.uk/2020/03/hiding-your-net-etw/

MDSec Consulting 2020 (c)

 DETECTING .NET TRADECRAFT: AMSI

• Version 4.8 of .NET framework introduced AMSI

• .NET exposes the full process memory; traditional

AMSI bypasses (e.g. AmsiScanBuffer) can be used

• CobaltStrike offers “amsi_disable” to patch

• Blue teams can hunt for processes with a modified

amsi.dll using memory scanners by examining the
code sections

• Patch cautiously, restore original values when done

to limit window for detection
https://blog.f-secure.com/hunting-for-amsi-bypasses/

MDSec Consulting 2020 (c)

 DETECTING EXECUTE-ASSEMBLY

• Cobalt Strike’s execute-assembly feature loads the

CLR in to an unmanaged process

• Blue teams can employ various strategies to detect

execute-assembly:

• Fork and run behaviour; additional process creation

events, anomalous parent/child relationships

• No native ETW bypasses built-in so assembly

execution can be collected by ETW consumers

MDSec Consulting 2020 (c)

 DETECTING EXECUTE-ASSEMBLY

• Processes anomalously loading the CLR

modules, e.g.:

• clrjit.dll
• mscoree.dll
• clr.dll

MDSec Consulting 2020 (c)

 DETECTING EXECUTE-ASSEMBLY

• Cobalt Strike’s malleable process injection

allows either RWX or RX pages (startrwx and
userwx):

• PE headers in RWX or
RX pages become an
IoC for memory
scanning

• .NET PE can be carved

MDSec Consulting 2020 (c)

 DETECTING EXECUTE-ASSEMBLY

DEMO: CARVING THE .NET PE

MDSec Consulting 2020 (c)

 HIDING YOUR EXECUTE-ASSEMBLY

• Red teamers wanting to improve their

execute-assembly .NET tradecraft can:

• Select a surrogate that legitimately loads

the CLR

• Stomp the .NET PE headers; set page to

RWX, overwrite header using RtlFillMemory
then set page to RW to blend with
assembly.load()

MDSec Consulting 2020 (c)

 HIDING YOUR EXECUTE-ASSEMBLY

• Sysmon can help find CLR loads for suitable

surrogates, e.g. backgroundTaskHost.exe:

MDSec Consulting 2020 (c)

 HIDING YOUR EXECUTE-ASSEMBLY

• Find the base address of the current

process, stomp the header:

MDSec Consulting 2020 (c)

 .NET TRADECRAFT AUTOMATION

• To maximise our .NET tradecraft, we may

need to bypass AMSI, ETW, stomp the PE,
reset page permissions, obfuscate and more

• Manually applying these to every .NET

assembly we want to run is not feasible

• Fundamentally, we want to bootstrap, build

and deploy our .NET code in an automated
way… sounds like DevOps

MDSec Consulting 2020 (c)

 OFFENSIVE CI/CD

• Integrating a CI/CD pipeline in to our toolchain as assist in

weaponising our offensive tools

• Prior work for offensive CI/CD in .NET includes:

• Building, Modifying, and Packing with Azure DevOps (https://

blog.xpnsec.com/building-modifying-packing-devops/)

• Offensive Development: How To DevOps Your Red Team (https://

www.youtube.com/watch?v=n5_V61NI0tA)

• Offensive Development with GitHub Actions (https://

www.mdsec.co.uk/2020/03/offensive-development-with-github-
actions/)

MDSec Consulting 2020 (c)

 OFFENSIVE CI/CD

• Rather than leveraging an existing pipeline like GitHub Actions

or Azure DevOps, let’s build a custom one…

• .NET Core provides a light weight, cross platform

implementation of .NET and is supported by Docker

• A .NET Core Web API was created to handle build requests

• To build .NET projects, we can leverage Roslyn for

compiling and manipulating each project

• .NET Core bindings for Donut facilitate shellcode

generation

MDSec Consulting 2020 (c)

 OFFENSIVE CI/CD

• CovertToolsmith consists of three core components:

• Loader: compiled on every request, and run on the target endpoint

(e.g. using a CLR harness such as execute-assembly)

• Projects: individual projects such as Ghostpack or artifacts that we

execute in memory or drop to disk

• Engine: .NET core web API that receives requests for projects,
consumes the project source code, bootstraps, compiles and protects
it then returns the compiled and encrypted project back to the loader

• Using the loader is optional, the obfuscated exe can be run direct from a
CLR harness if required; however the loader introduces keying and/or
bootstrapped code

MDSec Consulting 2020 (c)

 CovertToolsmith Architecture

MDSec Consulting 2020 (c)

 OFFENSIVE CI/CD

• Every tool has its own build profile, a JSON

configuration to outline the required resources:
{
SourceProject: "Rubeus",
SrcFolder: "coverttoolsmith/src/Data/src/Rubeus",
ReferenceDirectory: “coverttoolsmith/src/Data/src/
References/net35",
TempDirectory: "/tmp/",
References:
"System.dll;System.Core.dll;mscorlib.dll;System.DirectoryServ
ices.dll;System.DirectoryServices.AccountManagement.dll;Syste
m.IdentityModel.dll"
}

• These are serialised and stored in a SQLite

database for accessing during compilation requests

MDSec Consulting 2020 (c)

 OFFENSIVE CI/CD

DEMO: Running .NET using CovertToolsmith

MDSec Consulting 2020 (c)

 EVADING ANALYSIS

• Whenever a tool or artifact is built, it should be obfuscated:

• Makes it harder to triage the use of tools/artifacts across

the network

• Increases DFIR time

• ConfuserEx provides an open-source protector for .NET to

programatically:

• Rename resources

• Add control flow obfuscation

• Add protections such as anti-tamper, anti-debug etc.

• Encrypt resources and constants

MDSec Consulting 2020 (c)

 EVADING ANALYSIS

• ConfuserEx config is embedded programmatically

in the CovertToolsmith Web API:

• Roslyn compiles the tools to IL, then runs them

through the Confuser engine

MDSec Consulting 2020 (c)

 PROTECTING TOOLS

• Developing custom tools is a significant time investment, you

don’t want them to end on virus total

• With the ability to programatically modify every tool or artifact

we create, we can key them

• As a concept, keying encrypts the payload using a local and/or

remote resources to build a decryption key (Execution Guard
Rails: T1480)

• The resources may be derived from the environment (e.g. the

user’s username+domain+computer name) or from a remote
resource (e.g. DNS, a web page, the CovertToolsmith tunnel)

MDSec Consulting 2020 (c)

 PROTECTING TOOLS

• We can automatically, or manually gather keys

about an endpoint and submit them to the
CovertToolsmith API

• When a tool request is made, if keying is enabled it

will lookup the keys from the internal database and
respond with a copy of the tool or artifact, AES
encrypted using the environmental keys

• The loader or artifact then bruteforces the key to

decrypt itself before being run with Assembly.Load()

MDSec Consulting 2020 (c)

 PROTECTING TOOLS

DEMO: Creating an artifact

MDSec Consulting 2020 (c)

 OFFENSIVE DEVELOPMENT

• The primary benefit of this approach is we avoid

needing to heavily interact with the operating system

• Employing offensive development, we can achieve

everything we need using code, for example:

• What if we wanted to search for passwords?

• Traditionally, we might use something like…

findstr /S /I pass c:\users\

• This wouldn’t look pretty in EDR telemetry, how do

we solve this?

MDSec Consulting 2020 (c)

 OFFENSIVE DEVELOPMENT

• Using offensive dev, we can on the fly

develop something and run it on the target….

MDSec Consulting 2020 (c)

 OFFENSIVE DEVELOPMENT

DEMO: Red Team from your IDE

MDSec Consulting 2020 (c)

 CONCLUSIONS

• Modern EDR rich environments can provide a

wealth of telemetry to blue teams

• Post-exploitation tradecraft must adapt and

blend to avoid detection

• Integrating DevOps principles can assist in

automatically weaponising and protecting
your toolkits

MDSec Consulting 2020 (c)

 Shout Outs

• @peterwintrsmith : Some amazing work on

our CLR harnesses

• @dtmsecurity : Idea seeds from

SharpCompile

• @cobbr_io : Automation ideas from Covenant

MDSec Consulting 2020 (c)

 QUESTIONS

MDSec Consulting 2020 (c)