Doomsday Preppers: Fortifying Your Red Team Infrastructure

Slide 1

Slide 1 text

Slide 2

Slide 2 text

1 Introduction This way to the shelter..

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slides/Resources online bit.ly/RedTeamInfrastructure

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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”

Slide 8

Slide 8 text

3 “Standard” Infrastructure

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

4 Infrastructure Weaknesses

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

5 “Advanced” Infrastructure Now with laser beams!

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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!

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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!

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Domain Fronting

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

6 For the Reds “Front Toward Enemy”

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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/

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

7 For the Blues Our first catch of the day

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

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!

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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