Successfully reported this slideshow.
Your SlideShare is downloading. ×

Windows 10 - Endpoint Security Improvements and the Implant Since Windows 2000

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
The Veil-Framework
The Veil-Framework
Loading in …3
×

Check these out next

1 of 77 Ad

Windows 10 - Endpoint Security Improvements and the Implant Since Windows 2000

Download to read offline

This talk will initially cover Device Guard, and how it works. After discussing high level methods of attacking Device Guard, we will go into detail on WMImplant, a tool which can be used to operate on Device Guard protected systems.

This talk will initially cover Device Guard, and how it works. After discussing high level methods of attacking Device Guard, we will go into detail on WMImplant, a tool which can be used to operate on Device Guard protected systems.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Windows 10 - Endpoint Security Improvements and the Implant Since Windows 2000 (20)

Recently uploaded (20)

Advertisement

Windows 10 - Endpoint Security Improvements and the Implant Since Windows 2000

  1. 1. Windows 10 - Endpoint Security Improvements and the Implant Since Windows 2000 By: @ChrisTruncer and @Evan_Pena2003
  2. 2. @ChrisTruncer Sys Admin turned Red Teamer Open Source Developer Trooper 2
  3. 3. @Evan_Pena2003 Open Source Developer Red Team Lead for West Coast Former sysadmin 3
  4. 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
  5. 5. Device Guard 5
  6. 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. 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. 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. 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. 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. 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. 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. 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
  14. 14. 14
  15. 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. 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. 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
  18. 18. 18
  19. 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. 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
  21. 21. WMImplant Invoke-WMImplant 21
  22. 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. 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. 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. 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. 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. 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
  28. 28. Encoding Invoke-WMImplant 28
  29. 29. WMImplant and Encoding ◈ The first method of encoding data? Base64! ◆[Convert]::ToBase64String() ◈ Only one problem... 29
  30. 30. 30
  31. 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. 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
  33. 33. 33
  34. 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. 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. 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. 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. 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. 39. WMImplant and Data Storage - New WMI Class ◈ But… there’s a problem... 39
  40. 40. 40
  41. 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. 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. 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. 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. 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
  46. 46. 46
  47. 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
  48. 48. 48
  49. 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
  50. 50. 50
  51. 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
  52. 52. 52
  53. 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. 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. 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. 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
  57. 57. WMImplant Commands Invoke-WMImplant 57
  58. 58. WMImplant - Commands ◈ Broken up by what they do: ◆Meta Functions ◆File Operations ◆Lateral Movement ◆Process Manipulation ◆System Manipulation ◆Log Analysis 58
  59. 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
  60. 60. 60 gen_cli change_user
  61. 61. WMImplant - File Operations ◈ cat - read file contents ◈ download - downloads file from target ◈ ls - directory and file listing ◈ ninjacopy - copy any file ◈ search - search for file or extension ◈ upload - upload file to target 61
  62. 62. 62 cat
  63. 63. 63 search
  64. 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. 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. 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
  67. 67. 67 remote_posh
  68. 68. 68
  69. 69. Detecting Malicious WMI WMI vs. WMI 69
  70. 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. 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. 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
  73. 73. The Result (Persistence) 73
  74. 74. The Result (Command Execution 74
  75. 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. 76. WMImplant - Future Work ◈ Implement whitelisting bypasses ◈ Examine the changing defensive landscape and identify means to repurpose existing tools 76
  77. 77. WMImplant - Where to get it ◈ WMImplant - https://github.com/ChrisTruncer/WMImplant ◈ Questions? ◆@ChrisTruncer ◆@Evan_Pena2003 77

×