Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ready player 2 Multiplayer Red Teaming Against macOS

2,964 views

Published on

BSides Seattle 2019 talk about operating against macOS devices with a new open source tool called Apfell

Published in: Software
  • Login to see the comments

Ready player 2 Multiplayer Red Teaming Against macOS

  1. 1. READY PLAYER 2 MULTIPLAYER RED TEAMING AGAINST MACOS BSIDES SEATTLE 2019
  2. 2. CODY THOMAS • Senior Operator at SpecterOps • Previously: • Adversary Emulation Engineer at MITRE • Mac/Linux ATT&CK • APT3 Emulation Plan • Twitter: @its_a_feature_ • GitHub: github.com/its-a-feature/ 2
  3. 3. MACOS OPERATIONS What’s the current landscape? 3
  4. 4. CURRENT MACOS OPERATIONS Malware seen in the wild: • WindTail • Signed macOS application • FairyTale: • Signed macOS application • Calisto • Unsigned macOS application • AppleJeus • Signed macOS application • EvilEgg and LamePyre • Utilize EggShell and Empire Red Teaming FOSS Frameworks: • Empire • Python-based agent • Single User Terminal Application • RESTful Interface • EggShell • Python-based agent • Single User Terminal Application • Evil OSX • Python-based agent • Some GUI components 4 https://objective-see.com/downloads/MacMalware_2018.pdf https://github.com/EmpireProject/Empire https://github.com/neoneggplant/EggShell https://github.com/Marten4n6/EvilOSX
  5. 5. OPERATIONAL PROBLEMS ● Want to emulate adversaries, but: ○ Current FOSS capabilities don’t match up ○ More easily caught as “Red Team” ○ Signing macOS applications is not easy ● Want to operate in a team, but: ○ Need proper collaboration and sharing ○ Screen sharing isn’t scalable 5
  6. 6. BRIDGING THE GAP How can we get operations closer to the real thing? 6
  7. 7. JAVASCRIPT FOR AUTOMATION (JXA) ● Scriptable execution: ○ Most of the lower-level Objective C APIs exposed in a JS way ○ Kind of like if PowerShell stopped at version 1 or 2 ● According to Apple: “In OS X 10.10, JavaScript became a peer to AppleScript in OS X.” ● Still isn’t a signed macOS Application though ○ Hard to emulate as a consultant across multiple customers ● Very limited threading capabilities 7https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/index.html
  8. 8. ● Does osascript normally run? ○ AppleScript has been around since 1993 ○ Mainly used by Admins and power users ● How does JXA perform actions? ○ Apple Events for IPC (causes popups in 10.14) ○ Objective C API calls ● Signing? ○ Not a problem – Live off the land ○ osascript is an Apple signed binary ○ Can execute entirely in memory 8 DEFENSIVE CONSIDERATIONS
  9. 9. NOW IT’S TIME TO OP You’ve been tasked to operate against macOS, now what? 9
  10. 10. 10 INTRODUCING It’s not a bug, it’s a feature
  11. 11. WHAT IS APFELL? ● Collaborative, post-exploitation framework with a web front-end ● Apfell server runs on MacOS/Linux (needs python3.6+) ● Apfell agents can be any operating system ○ JXA payload for macOS ○ @xorrior already released a Chrome extension payload ○ Payloads can be scripted or dynamically compiled ● Any number of c2 profiles running at a time 11
  12. 12. DEMO TIME! Let’s operate 12 Demo videos: ● https://youtu.be/9yjNzYtOyHE ● https://youtu.be/FJf9oQkBG0g ● https://youtu.be/_V7PrbDHfY8 ● https://youtu.be/Hgn-RUa9feo ● https://youtu.be/4mABpw20KMQ ● https://youtu.be/KypCqWSQGwE
  13. 13. A FRAMEWORK SHOULD BE: 1. Informative • Track data, environment, operation, OPSEC concerns • Easy to understand user interface • Purple in nature - helping both Red and Blue teams 2. Collaborative • Every operator has their own customized front-end • Can share detailed information easily and quickly 3. Extensible • Easily add/share commands, C2 profiles, payloads • Support multiple operating systems • You shouldn’t have to re-roll a UI for every new payload 13
  14. 14. INFORMATIVE: FOR RED TEAMERS ● Operators ● Commands ○ OPSEC (Artifacts, Transforms) ● Payload Types ○ Creation, loading modules, execution help ● Operational Data Model ○ Let’s use all the data we collect/generate in operations ● Task-Response grouping ○ not just data-dump console ● Searching tasks and responses across an operation 14
  15. 15. INFORMATIVE: FOR BLUE TEAMERS ● Commands mapped to MITRE ATT&CK ○ Regex matching for more granularity ○ Exports to ATT&CK Navigator ○ Auto populates based on the command ● Host/Network artifact tracking per task ○ Helpful for deconfliction and reporting ○ Auto populated while operating ○ Agents can report updates or new artifacts ○ Soon include exportability of artifacts to Splunk/SIEMs 15
  16. 16. COLLABORATIVE ● Web-based GUI ○ No client dependencies besides a modern browser ○ Each operator has their own profile and login ● Users assigned to operations ○ Multiple operations ongoing concurrently ○ Individual tasks sharable amongst team members ● Operators can comment on tasks ○ Seen by all members in that operation 16
  17. 17. EXTENSIBLE ● You can create/add any number of payload types across all OSes ○ JXA, Python, C#, Go, etc ○ Can be scripts or compiled ● You can create/add any number of commands for a payload ○ Command templating ● You can create/add/run any number of C2 profiles at a time ○ They run as sub-processes ○ Only bound ports need to be unique 17
  18. 18. 18 APFELL Enough words, let’s see Apfell
  19. 19. PAYLOAD TYPES • Add / Edit Payload types • Can be wrappers for full payloads • Macro • MSBuild • DyLib 19
  20. 20. COMMANDS • View Code • Provide operator help • Edit code • Add/edit/remove parameters 20
  21. 21. COMMAND TRANSFORMS / ATT&CK / ARTIFACTS • Transform commands • Provide ATT&CK Mappings • Indicate host/network artifacts 21
  22. 22. COMMAND AND CONTROL PROFILES 22
  23. 23. C2 PROFILE PARAMETERS • Specify parameters that will be stamped into an agent during creation • “key” value is stamped out with user’s value in agent code 23
  24. 24. PAYLOAD CREATION - UI • Pick C2 profile, payload type, and initial commands • Stamp all pieces together 24
  25. 25. PAYLOAD CONFIGURATION • All payloads registered in the database • See configuration and comparison to server state at any time 25
  26. 26. CALLBACK VIEW • Familiar table of callbacks like most tools • Detailed task data grouped by task (not time) • Add/track optional comments per task 26
  27. 27. SHARING SINGULAR TASKS • Click task number on almost any page to view JUST that one task and its output • Easy to share URL amongst team members: /tasks/task# • Only viewable by users assigned to that operation 27
  28. 28. TASK VIEW • View all tasks at once across all callbacks • Click to expand and see output 28
  29. 29. SEARCH VIEW • Search all task output or task parameters for key words/phrases • Searches across all callbacks in an operation • Faster and more targeted than just 29
  30. 30. ATT&CK × Transform commands × Provide ATT&CK Mappings × Indicate host/network artifacts 30
  31. 31. APPLY ATT&CK WITH REGEX • Match all tasks where the parameters fit regex: .*id • Check matches and their current ATT&CK mappings 31
  32. 32. BASIC ARTIFACT TRACKING • Define formats for artifacts based on commands and command parameters 32
  33. 33. COMMAND TRANSFORMS • Toggle transforms on/off locally • Can optionally persist settings globally for all operators • Test outputs of each transform: 33
  34. 34. UPLOADING / DOWNLOAD 34 • View all uploads/downloads and file paths across an operation • Real-time updates for in-progress downloads
  35. 35. SCREEN CAPTURES 35 • View screen captures by callback or across an entire operation
  36. 36. COMMAND COMPLETION 36 • Auto populate available commands based on the associated payload type for the callback • Can use L/R arrow keys to cycle through choices
  37. 37. COMMAND PARAMETERS 37 • If a command has registered parameters and you don’t type any on the command line • Pop-up dialog to fill in parameters
  38. 38. APFELL AGENTS What does an agent look like? 38
  39. 39. PAYLOAD DESIGN CONSIDERATIONS 39 ● Modular ○ All commands are stand-alone ○ Main payload is just management engine ○ C2 is abstracted away ■ Creates plug-and-play C2 functionality ○ Stamp in commands at creation ■ And load more in later ● Inspiration ○ Malware samples: PlugX, Flame, CozyDuke, etc
  40. 40. PAYLOAD DESIGN CONSIDERATIONS 40 ● OS Agnostic ○ Apfell is a framework for collaborative operations ○ Payloads can be created for any OS – scripted or compiled ● OPSEC aware ○ Ideally agents track their footprint on host and report back ○ Artifact tracking with real-time data in responses
  41. 41. GOING FORWARD What’s next for Apfell? 41
  42. 42. FUTURE UPDATES – SHORT TERM ● More encryption ○ Currently just HTTPS ● More payload types across multiple operating systems ○ Python, Mach-O, C#, ELF, Go ● More built-in commands ○ Keylogging, Process Injection, Proxy Pivots 42
  43. 43. FUTURE UPDATES – MEDIUM TERM ● More customizable C2 profiles included by default ○ Control GET/POST requests ● More C2 profiles that don’t require external comms ○ SMB, SSH ● More Artifact Tracking / Defensive Guidance ○ Better tracking of operational artifacts ○ Inclusion of defensive measures for commands 43
  44. 44. FUTURE UPDATES – LONG TERM ● Create scriptable Python API for greater control ○ Registerable within the UI – no need for RESTful scripting ● Server speed improvements ○ Automated builds ● More UI Upgrades ○ Attackers think in graphs, not lists ● Community driven updates ○ Please contribute! ☺ 44
  45. 45. 45 THANKS!Any questions? • Twitter: @its_a_feature_ • GitHub: github.com/its-a-feature/ • https://its-a-feature.github.io • Blog series on creating Apfell • macOS AD discovery (Orchard) It’s not a bug, it’s a feature

×