Doomsday Preppers - HackMiami

Transcript

1. Doomsday Preppers:
   Fortifying Your Red
   Team Infrastructure
   

   View Slide

2. 1
   Introduction
   

   View Slide

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

   View Slide

4. Slides/Resources online
   bit.ly/RedTeamInfrastructure
   

   View Slide

5. Agenda
   ▪ Introduction
   ▪ “Standard” Infrastructure
   ▪ “Advanced” 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. Design
   ▪ One (or few) hosts handle all
   functionality
   ▫ Payloads/C2/Phishing/etc
   ▪ Quick to deploy
   ▪ Simple hardening
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

14. View Slide

15. View Slide

16. View Slide

17. View Slide

18. View Slide

19. View Slide

20. 5
    “Advanced” Infrastructure
    

    View Slide

21. View Slide

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

23. Design
    ▪ Document the setup
    ▫ Know what points where
    ▪ Split hosts amongst providers
    ▫ (Pay attention to terms of service!)
    ▪ Forward all logs to central
    server via rsyslog
    

    View Slide

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

25. View Slide

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

27. Domains
    

    View Slide

28. Domains
    

    View Slide

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

    View Slide

30. Domains
    

    View Slide

31. Domains
    

    View Slide

32. Domains
    

    View Slide

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

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

35. View Slide

36. Mobile Redirection
    Apache mod_rewrite
    

    View Slide

37. Invalid URI Redirection
    Apache mod_rewrite
    

    View Slide

38. Apache mod_rewrite
    OS-Specific Payloads
    

    View Slide

39. Apache mod_rewrite
    

    View Slide

40. Apache mod_rewrite
    

    View Slide

41. DNS
    ▪ socat vs. iptables
    ▫ https://github.com/bluscreenofjeff/Red-
    Team-Infrastructure-Wiki#dns
    ▪ Modify query results in profile
    ▫ 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

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

    View Slide

43. DNS Redirection
    

    View Slide

44. DNS Redirection
    

    View Slide

45. DNS Redirection
    

    View Slide

46. NAT’d DNS Redirection
    Cobalt Strike
    (192.168.20.10)
    SOCAT & SSH
    Main Redirector
    (104.236.x.x)
    SOCAT
    Volatile Redirector
    (45.63.y.y)
    IPTables
    https://gist.github.com/pcting/1041387
    

    View Slide

47. Modify Your C2 Channels!
    ▪ Don’t use defaults
    ▪ Use a different profile for each
    c2 channel
    ▪ Blend your profiles into your
    target environment
    

    View Slide

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

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

    View Slide

50. Modified C2 Signatures
    

    View Slide

51. Modified C2 Signatures
    

    View Slide

52. Modified C2 Signatures
    

    View Slide

53. Domain Fronting
    

    View Slide

54. Domain Fronting
    ▪ https://www.bamsoftware.com/paper
    s/fronting/
    ▪ Utilize high-trust domains
    ▫ Cloudfront
    ▫ AWS
    ▫ Google
    ▪ Implementation varies per
    provider
    

    View Slide

55. View Slide

56. Domain Fronting (cont.)
    

    View Slide

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

58. Finding Frontable Domains
    ▪ Searchable by CNAME
    ▫ Google ‘CNAME “*.cloudfront.net”’
    ▪ Bruteforce/find subdomains
    ▫ Can search alexa top x sites
    ▫ Search by domain
    ▫ https://github.com/rvrsh3ll/FindFrontab
    leDomains
    

    View Slide

59. View Slide

60. 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
    ▫ Skype Pre-Phish:
    https://www.youtube.com/watch?v=oTyLdAU
    jw30
    ▪ WATCH ALL LOGS
    ▫ Look for CURL/WGET/Python requests
    ▫ Geolocate IPs
    ▫ ID appliances
    ▫ ID incident response actions
    

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

65. 7
    For the Blues
    

    View Slide

66. View Slide

67. Hunting C2 Infrastructure
    ▪ Default requests
    ▫ Notable lack of headers
    ▫ Lack of proper HTTP response codes
    ▪ Static Content
    ▫ “It Works!” responses
    ▪ Reference
    ▫ http://www.chokepoint.net/2017/04/hunti
    ng-red-team-empire-c2.html
    ▫ http://www.chokepoint.net/2017/04/hunti
    ng-red-team-meterpreter-c2.html
    

    View Slide

68. Default Empire Response
    

    View Slide

69. Shodan Search For Empire
    http://securesql.info/hacks/2017/4/5/fall-of-an-empire
    

    View Slide

70. Identifying malicious DNS traffic
    ▪ Request length
    ▪ Same domain with many subdomains
    ▫ Entropy in subdomains
    ■ KDJSOISJFSLKJSOIFJ.example.com
    ■ Subdomain.example.com
    ▪ DNS Server resolves to 0.0.0.0 or
    something funky
    

    View Slide

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

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

    View Slide

73. VPS Lookup
    

    View Slide

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

    View Slide