Doomsday Preppers: Fortifying Your Red Team Infrastructure

Transcript

1. Doomsday Preppers:
   Fortifying Your Red
   Team Infrastructure
   

   View Slide

2. 1
   Introduction
   This way to the shelter..
   

   View Slide

3. Whoami
   ● Steve Borosh
   ○ Penetration Tester / Red Teamer
   ○ Blogger https://www.rvrsh3ll.net/
   ● Jeff Dimmock
   ○ Penetration Tester / Red Teamer
   ○ Blogger https://bluescreenofjeff.com/
   

   View Slide

4. Slides/Resources online
   bit.ly/RedTeamInfrastructure
   

   View Slide

5. Agenda
   ▪ Introduction
   ▪ “Standard” Infrastructure
   ▪ Weaknesses
   ▪ “Advanced” Infrastructure
   ▪ For The Reds: Tips for a Strong Infrastructure
   ▪ For The Blues: Tips and Tradecraft
   ▪ Questions
   

   View Slide

6. Purpose
   ▪ Infrastructure design
   ▫ Build a resilient infrastructure
   ▫ Stay hidden
   ▫ Separation of resources
   ▪ Secure the infrastructure
   ▫ Prevent “hack-back”
   ▫ Prevent data leakage
   ▪ Train both Blue and Red
   

   View Slide

7. Props to prior research
   ▪ blog.cobaltstrike.com - Raphael Mudge
   ▫ “A Vision for Distributed Red Team
   Operations”
   ▫ “Advanced Threat Tactics: Course and
   Notes”
   ▪ Cybersyndicates.com - Alex
   Rymdeko-Harvey
   ▫ “6 Red Team Infrastructure Tips”
   

   View Slide

8. 3
   “Standard” Infrastructure
   

   View Slide

9. View Slide

10. Design
    ▪ One (or few) hosts handle all
    functionality
    ▫ Payloads/C2/Phishing/etc
    ▪ Quick to deploy
    ▪ Simple hardening
    

    View Slide

11. Components
    ▪ Single-server C2 + SMTP
    ▪ Originates all attacks
    ▪ Default traffic profiles
    ▪ Open to entire Internet
    

    View Slide

12. Attacker
    Router/Firewall
    C2/SMTP Server
    Router/Firewall
    Victim
    

    View Slide

13. Use Cases
    ▪ Tests w/o active incident
    response
    ▪ Fully whitebox
    ▪ Functional testing
    ▫ Click tracking
    ▫ Egress testing
    

    View Slide

14. 4
    Infrastructure Weaknesses
    

    View Slide

15. View Slide

16. Weaknesses
    ▪ Hosted payloads are easily
    enumerated by defenders
    ▪ C2 may be easily blocked by IP,
    netblock, or domain name
    ▪ No redundancy in case of outages
    ▪ Susceptible to Internet-wide
    probing or exploitation
    

    View Slide

17. Weaknesses (cont.)
    ▪ Blue team probing hits backend
    servers
    ▪ Lack of adequate protections
    against ‘hacking back’ or probing
    

    View Slide

18. 5
    “Advanced” Infrastructure
    Now with laser beams!
    

    View Slide

19. View Slide

20. Design
    ▪ Based on “Infrastructure for
    Ongoing Red Team Operations” by
    Raphael Mudge
    ▪ Segregate assets based on
    function, minimize overlap
    ▪ Place redirectors in front of
    every host
    

    View Slide

21. Components
    ▪ Four teamservers
    ▫ Phishing & payloads
    ▫ Long-term DNS C2
    ▫ Short-term DNS C2
    ▫ Short-term HTTP C2
    ▪ Four redirectors (VPS hosts)
    ▫ Two for DNS C2 via socat/iptables
    ▫ HTTP C2 via Apache
    ▫ HTTP payloads via Apache
    ▪ SMTP server (VPS host)
    ▪ Four domains
    

    View Slide

22. View Slide

23. Domains
    ▪ expireddomains.net
    ▫ Old first registered age
    ▫ High SimilarWeb score
    ▫ High number of backlinks
    ▪ Register pre-used domains
    ▪ Register domains in same category
    ▪ Finance/Healthcare usually have
    firewall exceptions for SSL
    

    View Slide

24. Domains
    ▪ Check categorization
    ▫ Bluecoat
    ▫ McAfee (TrustedSource)
    ▫ Fortiguard
    ▪ Senderbase Score
    ▫ http://www.senderbase.org/
    ▪ Check blacklists (web and email)
    ▫ http://multirbl.valli.org/
    

    View Slide

25. SMTP
    ▪ Use “redirector” for sending
    ▪ Remove previous server headers
    ▪ Catch-all address to receive
    bounce-backs or responses
    ▪ Use third-party SMTP servers
    ▫ Read the TOS first!
    

    View Slide

26. Apache mod_rewrite
    ▪ Redirect unwanted requests
    ▫ Invalid URIs
    ▫ IR useragents
    ▫ Blacklisted IPs
    ▪ OS-specific payload delivery
    ▪ Payload extension hiding
    ▪ Filter non-C2 requests to C2
    domains
    

    View Slide

27. View Slide

28. DNS
    ▪ socat vs. iptables
    ▪ Modify query results
    ▫ Typical default of 0.0.0.0
    ▫ Nslookup = google,opendns
    ▪ Modify DNS request lengths
    ▫ Max domain name, 253 text characters
    ▫ MRZGS3TLEBWW64TFEBXXM.dns.example.com
    

    View Slide

29. DNS Redirecting
    Socat
    http://www.rvrsh3ll.net/blog/offensive/redir
    ecting-cobalt-strike-dns-beacons/
    IPTables
    ▪ Forward UDP port 53 to teamserver from
    redirector
    

    View Slide

30. Modified C2 Signatures
    ▪ Changes how C2 looks on the wire
    ▪ Impersonate adversary or internal
    applications
    ▪ Malleable C2 -> Cobalt Strike
    ▪ Communication Profile -> Empire
    ▪ Use custom profiles on every
    server!
    

    View Slide

31. Malleable C2 Example (Amazon Traffic)
    https://raw.githubusercontent.com/rsmudge/Malleable-C2-Profiles/master/normal/pandora.profile
    

    View Slide

32. Example Profiles
    ▪ amazon.profile
    ▪ bingsearch_getonly.profile
    ▪ cnnvideo_getonly.profile
    ▪ gmail.profile
    ▪ googledrive_getonly.profile
    ▪ microsoftupdate_getonly.profile
    ▪ msnbcvideo_getonly.profile
    ▪ onedrive_getonly.profile
    ▪ oscp.profile
    ▪ pandora.profile
    ▪ rtmp.profile
    ▪ safebrowsing.profile
    ▪ webbug.profile
    ▪ webbug_getonly.profile
    ▪ wikipedia_getonly.profile
    

    View Slide

33. Domain Fronting
    

    View Slide

34. Domain Fronting
    ▪ Utilize high-trust domains
    ▫ Cloudfront
    ▫ AWS
    ▫ Google
    ▪ Implementation varies per
    provider
    ▪ Uses same infrastructure
    legitimate apps/sites use
    

    View Slide

35. View Slide

36. Domain Fronting (cont.)
    ▪ Resources
    “High-reputation Redirectors and
    Domain Fronting” -Raphael Mudge
    “Domain Fronting via Cloudfront
    Alternate Domains” -Vincent Yiu
    “Escape and Evasion Egressing
    Restricted Networks” -Chris Patten
    and Tom Steele
    

    View Slide

37. Watching the watchers
    ▪ ‘Pre-phish’ with a weak phish to
    fingerprint response
    ▫ Easy-to-spot, but not Nigerian Prince
    ▫ Use completely different infrastructure
    ▫ Perform far in advance
    ▪ WATCH ALL LOGS
    ▫ Look for CURL/WGET/Python requests
    ▫ Geolocate IPs
    ▫ ID appliances
    ▫ ID incident response actions
    

    View Slide

38. Watching the watchers
    ▪ Monitor domain/IP
    categorization/blacklisting
    ▪ Monitor emails, if possible
    ▫ Compromised accounts
    ▫ Bouncebacks
    ▪ Roll infrastructure as needed
    

    View Slide

39. 6
    For the Reds
    “Front Toward Enemy”
    

    View Slide

40. View Slide

41. Logistics
    ▪ Document the setup
    ▫ Know what points where
    ▪ Split hosts amongst providers
    ▫ (Pay attention to terms of service!)
    ▪ Keep elements as independent as
    possible
    ▪ Forward all logs to central
    server via rsyslog
    

    View Slide

42. Securing the Infrastructure
    ▪ Attackers can be attacked too!
    ▫ Metasploit*
    ▫ Empire**
    ▫ Cobalt Strike***
    ▪ RCE on unprotected attack
    infrastructure
    *https://github.com/justinsteven/advisories/blob/master/2016_metasploit_rce_static_key_deserialization.md
    *https://github.com/justinsteven/advisories/blob/master/2017_metasploit_meterpreter_dir_traversal_bugs.md
    **http://www.harmj0y.net/blog/empire/empire-fails/
    ***http://blog.cobaltstrike.com/2016/10/03/cobalt-strike-3-5-1-important-security-update/
    

    View Slide

43. Securing the Teamserver
    ▪ Chattr cron directories
    ▪ iptables
    ▫ Restrict resources to only needed IPs
    ▪ Lock down SSH
    ▫ PKI auth only
    ▫ Limited user rights
    

    View Slide

44. Securing the Teamserver (cont.)
    ▪ Block non-target country IPs
    ▪ Keep your C2 updated!
    

    View Slide

45. 7
    For the Blues
    Our first catch of the day
    

    View Slide

46. View Slide

47. Identifying malicious DNS traffic
    ▪ Request length
    ▪ Same domain with many subdomains
    ▫ Entropy in subdomains
    ▪ DNS Server resolves to 0.0.0.0
    If you start looking for DNS C2
    traffic, it’s easy to spot!
    

    View Slide

48. Identifying other malicious traffic
    ▪ SSL Certs
    ▫ Let’s Encrypt Certs
    ▫ Self-Signed
    ▪ Consistent URL patterns
    ▫ /admin.php etc..
    ▫ Repeated intervals with Bro
    ▪ Research common C2 platforms
    ▫ (low hanging fruit for defenders)
    ▫ Stagers are easy to spot
    

    View Slide

49. Identifying other malicious traffic (cont.)
    ▪ Process monitoring
    ▫ Why is x process talking to the
    Internet?
    ▫ Example Tools
    ■ Sysmon/Procmon
    ■ Carbon Black
    

    View Slide

50. Identifying Malicious traffic (cont.)
    ▪ Analyze network captures
    ▫ Beacon intervals (jitter)
    ▫ Filter out known-good
    ▪ VPS address ranges
    

    View Slide

51. Thanks!
    ANY QUESTIONS?
    You can contact us at:
    @424f424f (Steve Borosh) @bluscreenofjeff (Jeff Dimmock)
    http://www.rvrsh3ll.net https://www.bluescreenofjeff.com
    

    View Slide