[RedTeam] Review of Red Team Operations with Cobalt Strike (2019) Training Course (Part 1)

TL;DR

If you ask any red team or adversary simulation operators which tool they use the most, the answer would be Cobalt Strike Command and Control (“C2”). There are actually many other C2 frameworks existing, and some of them have their niche specialties, such as Covenant, .NET C2, and Merlin, HTTP/2 C2. However, in my opinion, what makes Cobalt Strike more attractive than the others is (1) its maturity/stability in use; (2) flexibility of its toolkit; not to mention (3) continuous upgrade/maintenance by the creator, Raphael Mudge who is founder of both SpecterOps and Strategic Cyber LLC and greatly respected offensive security guru.

Speaking of Raphael Mudge, after he announced and released Cobalt Strike 4.0 at the end of 2019, he also published amazing training course of “Red Team Operations with Cobalt Strike (2019).” This course is publicly available at this following YouTube link and consists of 9 video series. The series are around 1-hour or hour-and-half long each. As I wanted to hone my skill sets around red team operations and Cobalt Strike in general, I thought these training series would be perfect for me :)

In this review, I will avoid to talk too much about the actual course contents/materials (because I highly recommend you do go to watch all the video series on your own!); instead, I will try to cover topics he talks about on each series and share some of my notes that I took during the course.

Red Team Ops with Cobalt Strike (1 of 9): Operations

The first one was more introductory video about red team operations, attack kill chain and Cobalt Strike in general. He also talks about what we need to consider when conducting a red team/adversary simulation.

Source: Red Team Ops with Cobalt Strike (1 of 9): Operations
### RedTeam Operational Considerations

├──[1] Gaining access via sending phishing emails
│ ├── Anti-malware?
│ ├── Anti-spam?
│ └── Sandbox controls?

├──[2] After gaining access to the target host
│ ├── End-point security controls? (e.g., AV)
│ ├── Local application running policy?
│ ├── EDR? (e.g., Cylance, CrowdStrike)
│ └── SOC? (e.g., Security Analyst, SIEMs)

├──[3] After gaining code/command execution
│ ├── Firewall or proxy sanitizing tools?
│ ├── Network Security Monitoring ("NSM")?
│ └── Threat Intelligent Feed

└──[4] How to succeed at evasion
├── Know your tools and their behaviors
│ └─> They generate "Events" --> What to do with them?
├── Access and understand the defenses
└── Decide the best option to use
### Cobalt Strike Intro

├──[1] Beacon (C2 Callback Agent)
│ ├── HTTP/S or DNS to egress network
│ └── SMB or TCP for peer-to-peer C2

├──[2] Malleable C2 controls...
│ ├── Network traffics
│ ├── In-memory content, characteristics and behavior
│ └── Process injection behavior

└──[3] Multiple team servers (*Recommended)
├── Staging Server
│ ├── Getting initial callbacks
│ ├── Initial privilege escalation + install persistence
│ └── Expect these servers to get caught!
├── Long Haul Server
│ ├── "Low and Slow" persistent callbacks
│ └── pass access to post-exploitation as needed
└── Post-Exploitation Server
└── Post-exploitation and lateral movement

Red Team Ops with Cobalt Strike (2 of 9): Infrastructure

The second video talks more about Cobalt Strike features and how to setup redirectors to protect your team servers as well as explains different listener/beacon payload options.

Source: Red Team Ops with Cobalt Strike (2 of 9): Infrastructure
### Cobalt Strike Beacons

├── HTTP Beacon
│ └── You can add IPv4, IPv6 or Domain (FQDN) for listeners

├── HTTPS Beacon
│ └── You can add valid SSL cert

├── DNS Beacon
│ ├── Edit zone file for a domain you control
│ ├── Create an A record for CS system
│ └── Create an NS record that points to your CS system FQDN

├── SMB/TCP Beacon
│ ├── Peer-to-peer beacon
│ │ └─> This creates a child process of your initial beacon
│ ├── Control over SMB beacon
│ │ ├── beacon> link [host] [pipe]
│ │ └── beacon> unlink [host] [pid]
│ └── Control over TCP beacon
│ ├── beacon> connect [host] [port]
│ └── beacon> unlink [host] [pid]
└── External C2 Beacon
├── You can start an External C2 listener on your CS server
└── Use other External C2 to connect to the listener
### Cobalt Strike Infrastructure

├── Listeners
│ ├── Egress: Beacons out of a network
│ ├── Peer-to-peer: Communicates through a parent payload
│ └── Alias: Reference to a payload handler

├── Payloads
│ ├── Stager
│ │ ├── Download a payload --> pass it for execution
│ │ ├── Less secure
│ │ ├── More brittle (it can crash)
│ │ └── Easier to be detected
│ └── Stageless
│ ├── No stager. Single file contains all.
│ └──[!] Most of the CS payloads are now stageless

├── Redirectors
│ ├── Use Iptables, Socat or other tools to forward traffics to
│ │ your CS team server.
│ ├── Use an Apache or Nginx reverse proxy config
│ ├── Use a CDN as a redirector for HTTPS traffic
│ │
│ ├──[HTTP Redirector Example]
│ │ ├── Start a team server (main.bigb0ss.com)
│ │ └── On the redirector box (redir.bigb0ss.com)
│ │ ├── apt-get update && apt-get install socat
│ │ ├── screen -S socat_redir
│ │ └── socat TCP4-LISTEN:80,fork TCP4:main.bigb0ss.com:80
│ │
│ └──[CDN Redirector Example]
├── Use valid SSL certificate
│ ├── Allows HTTP Post and HTTP GET verbs (*Malleable C2)
│ ├── Consider using HTTP-GET only C2 (*Malleable C2)
│ ├── Be aware of transformed requests (*Malleable C2)
│ └──[!] Disable all cache options
│ └─> This is because we want the CDN to not cache our
│ contents and callback to us every time the target
│ calls back to our C2.
Source: Red Team Ops with Cobalt Strike (2 of 9): Infrastructure

└── Domain Fronting
├─: Domain fronting is basically making the C2 traffic from the
│ target system that looks like going into the highly trusted
│ domain "T" but actually making it to our C2. Helps
│ bypassing egress controls or making the C2 traffic blended
│ into normal/legitimate traffics.

├── CDN Domains
│ └─: Reason for using CDN domains are that they are highly
│ trusted, and it is hard to block all the trusted CDN
│ domains. If blocked, people cannot access to some
│ legitimate websites.

├── HTTP Traffic Considerations
│ └─: For plain HTTP traffic, if the target organization is
│ using a proxy server, it can inspect the HTTP GET
│ request host and its "Host:" header value. If the
│ request host and the header value are not matching, it
│ will overwrite the "Host:" header to point it to the
│ GET request host. This is called "Normalization."
│ └─>[!] This will break the Domain Fronting.

├── HTTPS Traffic Considerations
│ └─: For plain HTTPS traffic, the proxy server is only able
│ to see the "CONNECT Domain:443" URL and unable to
│ inspect the encrypted the headers. But many companies
│ can do MitM-SSL between the proxy server and the SSL
│ connection, so they may catch the domain fronting
│ attempts. (However, consider that like finance and
│ healthcare organizations would not do the MitM-SSL
│ because they don't want to see people's PII date
│ accidentally.)

└── Server Name Indication ("SNI") Considerations
└─: Some CDN providers now check the "SIN:" value within
the HTTP/S request, and if that is different than
"Host:" header, it flags as malicious. It is one of the
reasons why people say Domain Fronting is dead now, but
not always.

Red Team Ops with Cobalt Strike (3 of 9): C2

The third video was one of my favorites. This goes into deep-dive of the Malleable C2 setup, which is one of the sexiest features of Cobalt Strike. Also, it talks about different types of C2s.

Malleable C2 Key Blocks

Source: Red Team Operations with Cobalt Strike (3 of 9):C2
### Malleable C2 Profile

├── Network traffic modifications
├── In-memory content, characteristics and behaviors
├── Process injection behaviors
├── Testing Profile: ./c2lient [profile]

└──[Pro Tips]
├── Don't use public example in production
├── Don't allow an empty http-get > server > output response.
├── Use 'prepend' to prepend junk data
├── Use 'transform' to mask/randomize data
├── Change URIs and use 'prepend' to mask IOCs in http-stager
│ block. (If you are going to allow staging)
├── Use http-config block to standardize server headers and
│ order of the header for all HTTP server responses.
├── Use plausible useragent value for target network.
└── Use HTTP Get-Only C2 for difficult egress situations.

For the Malleable C2, I wrote another blog post with detailed explanation for each block. You can find it there:

### C2 Considerations

├──[HTTP/S Proxy]
│ ├── CS's HTTP/S payloads are built with WinINet libraries, so
│ │ it has default features of automatic NTLM authentication
│ │ for domain users; however, if you are calling as SYSTEM
│ │ this may fail.
│ └──[!] Be aware that WinINet library may have TLS limitation
│ incompatible with your redirectors.

├──[Network Security Monitoring]
│ ├── Use an Apache, Nginx or a CDN as a redirector
│ │ ├─> It smooths CS-specific indicators, better JA3S
│ │ │ fingerprint, etc.
│ │ └── JA3 (JA3S - server) technology indicates the value of
│ │ the applications; therefore, using a redirector as a
│ │ legit software like Apache or Nginx is really
│ │ important. (You don't want your redirector to be
│ │ looking like a random Java on Debian running) -> One of
│ │ the biggest reasons why you should use redirectors.
│ ├── Host redirectors on different VPS providers.
│ ├── Domains are better with age and categorization.
│ ├── Do not use IPv4 addresses for C2.
│ ├── Have a valid SSL certificate

├──[Communication Path Do/Don't]
│ ├── Do
│ │ ├── Egress from plausible user processes on workstations
│ │ ├── Use SMB Beacon from workstations to servers
│ │ └── Use built-in Windows tools and APIs to find targets
│ └── Don't
│ ├── Servers should not egress
│ ├── SMB beacon from server to workstations is weird
│ └── Scan to find targets

├──[DNS C2 Detection]
│ ├──[Blue] Use Split-Split DNS
│ │ [Red] Do not use DNS C2
│ ├──[Blue] Monitor volume of DNS requests
│ │ [Red] Use DNS C2 as low&slow fallback option only
│ ├──[Blue] Check for CS DNS C2 IOCs
│ │ [Red] Set 'dns_stager_prepend' and 'dns_stager_subhost'
│ ├──[Blue] Check for bogon IP (0.0.0.0)
│ │ [Red] Change 'dns_idle' in profile.
│ │ Avoid 'mode dns' as this will send bogon responses
│ └──[Blue] Check for length of request hostnames
[Red] Set 'dns_mas_txt' to limit TXT length.
│ Set 'maxdns' to limit hostname length.

└──[Cobalt Strike C2 Detection]
├──[Blue] Check for CS default SSL cert
[Red] Use valid SSL cert
│ Use redirectors
│ Only allow HTTP/S connections from redirectors
├──[Blue] Check for port 50050 open
[Red] Firewall port 50050 and access via SSH tunnel
└──[Blue] Empty index page, 404, text/plain Content-Type
[Red] Host content on your redirectors

Next, Part 2 will cover :

  • Red Team Ops with Cobalt Strike (4 of 9): Weaponization
  • Red Team Ops with Cobalt Strike (5 of 9): Initial Access
  • Red Team Ops with Cobalt Strike (6 of 9): Post Exploitation

Thanks for reading!

OSCE | OSCP | CREST | Offensive Security Consultant — All about Penetration Test | Red Team | Cloud Security | Web Application Security

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store