Doomsday Preppers - HackMiami

Transcript

1. 1.

   Doomsday Preppers: Fortifying Your Red Team Infrastructure

2. 2.

   1 Introduction

3. 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
4. 4.

   Slides/Resources online bit.ly/RedTeamInfrastructure

5. 5.

   Agenda ▪ Introduction ▪ “Standard” Infrastructure ▪ “Advanced” Infrastructure ▪

   For The Blues: Tips and Tradecraft ▪ Questions
6. 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
7. 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”
8. 8.

   3 “Standard” Infrastructure

9. 9.

   Design ▪ One (or few) hosts handle all functionality ▫

   Payloads/C2/Phishing/etc ▪ Quick to deploy ▪ Simple hardening
10. 10.

    Components ▪ Single-server C2 + SMTP ▪ Originates all attacks

    ▪ Default traffic profiles ▪ Open to entire Internet
11. 11.

    Use Cases ▪ Tests w/o active incident response ▪ Fully

    whitebox ▪ Functional testing ▫ Click tracking ▫ Egress testing
12. 12.

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

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

    None
15. 15.

    None
16. 16.

    None
17. 17.

    None
18. 18.

    None
19. 19.

    None
20. 20.

    5 “Advanced” Infrastructure

21. 21.

    None
22. 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
23. 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
24. 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
25. 25.

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

    Domains

28. 28.

    Domains

29. 29.

    Domains ▪ Check categorization ▫ Bluecoat ▫ McAfee (TrustedSource) ▫

    Fortiguard ▪ Senderbase Score ▫ http://www.senderbase.org/ ▪ Check blacklists (web and email) ▫ http://multirbl.valli.org/
30. 30.

    Domains

31. 31.

    Domains

32. 32.

    Domains

33. 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!
34. 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
35. 35.

    None
36. 36.

    Mobile Redirection Apache mod_rewrite

37. 37.

    Invalid URI Redirection Apache mod_rewrite

38. 38.

    Apache mod_rewrite OS-Specific Payloads

39. 39.

    Apache mod_rewrite

40. 40.

    Apache mod_rewrite

41. 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
42. 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
43. 43.

    DNS Redirection

44. 44.

    DNS Redirection

45. 45.

    DNS Redirection

46. 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
47. 47.

    Modify Your C2 Channels! ▪ Don’t use defaults ▪ Use

    a different profile for each c2 channel ▪ Blend your profiles into your target environment
48. 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!
49. 49.

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

50. 50.

    Modified C2 Signatures

51. 51.

    Modified C2 Signatures

52. 52.

    Modified C2 Signatures

53. 53.

    Domain Fronting

54. 54.

    Domain Fronting ▪ https://www.bamsoftware.com/paper s/fronting/ ▪ Utilize high-trust domains ▫

    Cloudfront ▫ AWS ▫ Google ▪ Implementation varies per provider
55. 55.

    None
56. 56.

    Domain Fronting (cont.)

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

    None
60. 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
61. 61.

    Watching the watchers ▪ Monitor domain/IP categorization/blacklisting ▪ Monitor emails,

    if possible ▫ Compromised accounts ▫ Bouncebacks ▪ Roll infrastructure as needed
62. 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/
63. 63.

    Securing the Teamserver ▪ Chattr cron directories ▪ iptables ▫

    Restrict resources to only needed IPs ▪ Lock down SSH ▫ PKI auth only ▫ Limited user rights
64. 64.

    Securing the Teamserver (cont.) ▪ Block non-target country IPs ▪

    Keep your C2 updated!
65. 65.

    7 For the Blues

66. 66.

    None
67. 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
68. 68.

    Default Empire Response

69. 69.

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

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

    Identifying Malicious traffic (cont.) ▪ Analyze network captures ▫ Beacon

    intervals (jitter) ▫ Filter out known-good ▪ VPS address ranges
73. 73.

    VPS Lookup

74. 74.

    Thanks! ANY QUESTIONS? You can contact us at: @424f424f (Steve

    Borosh) @bluscreenofjeff (Jeff Dimmock) http://www.rvrsh3ll.net https://www.bluescreenofjeff.com