This document summarizes a talk about improvements to endpoint security in Windows 10 and how attackers have adapted. It discusses defenses like Device Guard and code integrity policies, as well as WMImplant, a tool developed by the presenters to operate on Device Guard systems using only Windows Management Instrumentation (WMI). WMImplant allows tasks like command execution, file transfer, and persistence via encoding and storing data in WMI properties. It also outlines methods defenders can use to detect malicious WMI usage like active WMI monitoring and the WMIMonitor tool.
4. What’s this talk about?
◈ Device guard!
◈ Code integrity policies
◈ PowerShell Constrained Language mode
◈ Introduction of a way to live off the land
◈ Data Encoding
◈ C2 Data Storage
◈ Commands
4
6. Device Guard
◈ Defensive technology built into Windows 10
and Server 2016
◈ A change from antivirus technologies where
apps are “trusted” unless flagged as
malicious
◈ You now explicitly state which applications
are trusted
6
7. Device Guard
◈ New application whitelisting bypass
published?
◆Don’t trust that application anymore!
◈ Matt Graeber is curating a baseline code
integrity policy blocking offending
applications
7
https://github.com/mattifestation/DeviceGuardBypassMitigationRules
8. Code Integrity Policies
◈ You define trusted applications by creating
Code Integrity policies
◈ Upon creating code integrity policies, they
can be deployed via:
◆GPO
◆SCCM
8
9. Code Integrity Policies
◈ Code integrity policies are largely based on
digital signatures
◈ For unsigned applications, you can deploy
catalog files which can be tied into code
integrity policies
9
10. Code Integrity Policies
◈ Catalog files will need to be updated every
time an application is updated
◆If using digital signatures, this won’t be
a problem
◈ Code integrity policies typically are XML
files converted into a binary
10
11. Code Integrity Policies
◈ Your code integrity policies themselves
should also be signed
◆This can help prevent modification by
users/attackers with administrative rights
11
12. Creating Code Integrity Policies
◈ The easiest way to create code integrity
policies is through PowerShell
◈ Carlos Perez and Matt Graeber have created
walkthroughs for creating a code integrity
policy
12
https://gist.github.com/darkoperator/7d5b85354c0343c7554e
http://www.exploit-monday.com/2016/09/introduction-to-windows-device-guard.html
13. Creating Code Integrity Policies
◈ Largely, you will use the New-CIPolicy
cmdlet and specify the file rule levels for
defining trusted applications
◆File hash
◆File name
◆Publisher
◆FilePublisher 13
15. Creating Code Integrity Policies
◈ Convert XML code integrity policy to a
binary file
◆ConvertFrom-CIPolicy
◈ Deploy in audit mode
◆Non-blocking
◆Generates events
15
16. Creating Code Integrity Policies
◈ After having deployed in audit mode
◆ Review event logs
◆ Make any rule modifications as needed
◆ Deploy in enforcement mode
16
17. PowerShell Constrained Language Mode
◈ Device Guard auto-configures PowerShell to
run in Constrained Language mode
◆Pure PowerShell elements are allowed,
but the types are limited
◆.Net methods are only allowed on the
permitted types
17
19. Attacker’s Perspective
◈ How can we operate on a Device Guard
protected system?
◆Develop a bypass
◇This will be effective at first, but
could potentially be blocked via CI
Policy.
◇This takes R&D 19
20. Attacker’s Perspective
◈ How about living off the land?
◆We know the applications most likely to
be whitelisted
◇PowerShell, WMI, etc.
◆Can they be chained together to attack
systems in a useful manner?
20
22. WMImplant
◈ Developed in PowerShell
◈ Designed to exclusively operate with WMI
◆The mechanism to trigger actions
◆The C2 channel itself
◆Data storage :)
◈ Menu and commands are reminiscent of
Meterpreter - except all WMI based
22
23. First, Thanks
◈ Thanks to the incredibly smart Matt Graeber,
Willi Ballenthin, and Claudiu Teodorescu
◈ Their research is what spurred my interest in
WMI
◈ Without their research, I may have never
developed this capability
23https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/wp-windows-management-instrumentation.pdf
24. What’s WMI?
◈ WMI == Windows Management
Instrumentation
◈ Installed and enabled by default in Windows
since Windows 2000
◈ Enables administrators to query local and
remote systems for management purposes
24
25. WMImplant and Device Guard
◈ WMImplant was developed exclusively
against Device Guard protected systems
◆Remember ConstrainedLanguage
Mode? - We’re great friends with it :)
25
26. WMImplant and Device Guard
◈ Data storage and encoding were problems in
the initial development stages.
◆We want to be able to upload or
download files, run commands, etc.
◆What if all data that we might need to
manipulate isn’t just text?
26
27. WMImplant and Device Guard
◈ We discovered that encoding and data
storage were problems we were going to
need to solve to write an effective post-
exploitation tool
27
31. Encoding - Back to the Drawing Board
◈ Base64 is out
◆We haven’t seen a pure PowerShell
based Base64 encoding/decoding
function
◈ WMImplant can be encoder agnostic,
anything that works can be used.
◆So… let’s turn to Daniel Bohannon 31
32. WMImplant and Encoding - [Int[]][Char[]]
◈ $encode = [Int[]][char[]]$input -Join ','
◆Breaks input into an array of char, then
converts each char into an int
◆It works with binary and text files - in
constrained mode
◈ $decoded = [char[]][int[]]$encode.Split(',') -
Join '' 32
34. WMImplant Encoding and Storage
◈ Awesome!
◈ We can now encode and
decode data in a
Constrained Language
compliant manner.
◈ Next Question: where
should it be stored?
34
35. WMImplant and Data Storage
◈ The initial version of WMImplant used the
system registry to store data
◈ We can easily create and modify registry
values remotely
◆This can be done over WMI with the
StdRegProv
35
36. WMImplant and Data Storage
◈ Registry Pro:
◆Not limited to a very small size
limitations
◈ Registry Con:
◆Lots of parsers for analyzing a system’s
registry
36
37. WMImplant and Data Storage
◈ This led to a conversation with Matt
Dunwoody discussing APT 29 tactics
◆They were creating custom WMI
classes, adding properties, and storing
data in WMI properties.
◈ Let’s try to recreate this!
37
38. WMImplant and Data Storage - New WMI Class
◈ Lucky for us, Matt Graeber already
published code that does this!
38https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/wp-windows-management-
instrumentation.pdf
39. WMImplant and Data Storage - New WMI Class
◈ But… there’s a
problem...
39
41. WMImplant and Data Storage - WMI Property Fail
◈ WMI class creation is allowed within
Constrained Language Mode
◈ WMI property creation is not…
◈ It looks like this idea won’t work
◈ Unless...
41
42. WMImplant and Data Storage - Existing Classes!
◈ What about if we look at existing WMI classes?
◆ Are their properties writable?
◆ Can they accept a “string” type or any
length?
◆ Can the property be modified in Constrained
Language Mode?
◆ Won’t blue screen the box?
42
43. WMImplant and Data Storage - Existing Classes!
◈ Modified an existing script to:
◆Enumerate all WMI classes
◆Enumerate all properties within each
class
◆Find properties of type “string” that are
writable
43https://gist.github.com/ChrisTruncer/f3fe3f04b9fdd1310507363f8bdad8be
44. WMImplant and Data Storage - Existing Classes!
◈ This returned a somewhat limited number of
properties
◆Some only allowed a fixed (small)
length of data
◆Others would error when modifying the
property value.
44
45. WMImplant and Data Storage - Then, there was one
◈ However, this did identify a class that we’ve
not seen before
◆Win32_OSRecoveryConfiguration
◈ This class is used to specify the type of
information that is collected when the
system crashes.
45
47. WMImplant and Data Storage - Then, there was one
◈ It does have a single property which is
writable, and is a string
◆DebugFilePath - The location where
Windows places a memory dump
following an operating system crash.
47
49. WMImplant and Data Storage - DebugFilePath
◈ It looks as if it should only accept a file path
location
◈ It looks as if it would be limited in the length
of data it accepts
◈ That’s what it looks like...
49
51. WMImplant and Data Storage - DebugFilePath
◈ Awesome!
◈ Demonstrates we can write arbitrary strings
to the DebugFilePath property
◈ Our encoder can work with this!
◈ What about length..?
51
53. WMImplant and Data Storage - DebugFilePath
◈ This gives us everything we need!
◆Writeable string property
◆Writeable in Constrained Mode
◆Not fixed in length (256+ MB)
◆Doesn’t blue screen the box :)
53
54. WMImplant and Data Storage - C2 Comms
1.Query the remote machine’s DebugFilePath
property to receive its original value
2.Use WMI to execute a command (ipconfig)
on the targeted machine
3.Encode the results of the command and store
it in the DebugFilePath property
54
55. WMImplant and Data Storage - C2 Comms
4. Query the remote system (from attacking
machine) to receive DebugFilePath value
5. Decode the value and display the results
6. Set the DebugFilePath property back to its
original value.
55
56. WMImplant - C2 Comms
◈ Most of WMImplant’s commands will not
require data storage
◆In this case, results are retrieved with
likely a single WMI query
◈ If storage is required, the previous C2
communications methodology is followed
56
58. WMImplant - Commands
◈ Broken up by what they do:
◆Meta Functions
◆File Operations
◆Lateral Movement
◆Process Manipulation
◆System Manipulation
◆Log Analysis
58
59. WMImplant - Meta Functions
◈ help
◈ exit
◈ change_user - change current user context
for all commands
◈ gen_cli - generate command line command
to run non-interactively
59
64. WMImplant - Uploads and Downloads
◈ These are the only commands that still use
the registry for data storage
◆This is due to not knowing the size of
potential uploads or downloads
◆Also due to unknown size limits of the
WMI property (tested up to 256 MB)
64
65. WMImplant - Uploads
1.Read and encode file that will be uploaded
2.Store in remote system’s registry
3.Start PowerShell on remote system via WMI
4.Read and decode registry value
5.Write decoded results to user-specified file
location
65
66. WMImplant - Lateral Movement Facilitation
◈ command_exec - Run command and receive
output
◈ enable_wdigest - Set UseLogonPassword
key
◈ enable_winrm - enables WinRM
◈ remote_posh - Runs PowerShell script on
target and receives output 66
70. Actively Monitor WMI
1. Use WMI Query Language (WQL) to identify
◆ Recently created “_EventConsumer”
events (persistence)
◆ WMI-based process executions
2. Creates an Event Filter (condition) to perform
an action if any of the above WQL conditions
are true
70
71. Actively Monitor WMI
3. Creates an Event Consumer (action), to log details of
the newly created “__EventConsumer” or executed
process
a. Set it to log all data to the event log with specific
event ID and event name
b. Very high fidelity!
c. Feed these logs to a SIEM - SNARE or universal
forwarder. Then ALERT!
71
72. Automating the Process - WMIMonitor
◈ Mandiant WMIMonitor PowerShell Script
found here:
https://github.com/realparisi/WMI_Monitor
◈ Detailed blog post here:
https://www.fireeye.com/blog/threat-
research/2016/08/wmi_vs_wmi_monitor.html
72
75. Scale Detection with More Signatures
◈ UpRoot IDS
◆https://github.com/Invoke-IR/Uproot
◈ Includes ~14 signatures instead of 2
◈ Centralized logging so if you have a smaller
budget...1 agent instead of 1000+ agents.
75
76. WMImplant - Future Work
◈ Implement whitelisting bypasses
◈ Examine the changing defensive landscape
and identify means to repurpose existing
tools
76
77. WMImplant - Where to get it
◈ WMImplant -
https://github.com/ChrisTruncer/WMImplant
◈ Questions?
◆@ChrisTruncer
◆@Evan_Pena2003
77