O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Ready player 2 Multiplayer Red Teaming Against macOS

3.210 visualizações

Publicada em

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

Publicada em: Software
  • Entre para ver os comentários

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

×