This article is a translation of the original article from habr.com by user secm3n, and it is a real example of good work by Red Team specialists. Enjoy reading.

As a rule, Red Team engagements are assigned to already experienced hacker teams who have honed their skills through numerous pentests. They have tried-and-true tactics and methods of breaking in, as well as confidence in their abilities. And yet, sometimes they make ‘rookie’ mistakes during their first Red Team engagements in their careers. I know this from my own experience.

In this article, I’ll reminisce about one of my first Red Team projects:

  1. I’ll dissect the differences between Red Team and pentesting from the performer’s point of view.
  2. I’ll share offline reconnaissance techniques and examine the process of finding vulnerabilities using a real case as an example.
  3. I’ll highlight common mistakes that pentesters make when transitioning to Red Team.

Even experienced professionals don’t always see the subtle differences between pentesting and Red Team engagements. The difference lies in the approach to identifying vulnerabilities and assessing an organization’s security.

The task of the Red Team is to simulate a real cyberattack. The team looks for critical vulnerabilities to achieve a specific goal or multiple goals, such as stealing trade secrets. The client’s information security team is unaware of what’s happening and may actively obstruct the Red Team if they discover their activities.

Pentesting is carried out under completely different conditions: pentesters have a goal that the team tries to achieve in a single pre-agreed manner (unless the client requests otherwise). Moreover, the client’s information security team is always aware of the pentesters’ actions and does not hinder them in any way.

The key feature of the Red Team is the stealth of their actions. The team minimizes traces and tries not to attract the attention of the company’s security service. This allows for assessing the competence of the client’s information security specialists. Red Team engagements are as close to real attacks as possible, whereas pentesting is a more formalized event. It often includes communication and information exchange with the client’s information security service and administrators.

Difference between Red Team and Pentest

Red Team – Methods and Goals
Involves a combination of various approaches: social engineering, simulation of real attacks, OWASP Testing Guide, MITRE ATT&CK Framework, SANS Penetration Testing Framework, Information Systems Security Assessment Framework (ISSAF), PTES. The goal is to test the speed and quality of the Blue Team’s response.

Red Team – Approach
The team works in a real environment, with protective measures not disabled. There may be active counteraction from the client. If the Red Team’s actions are exposed, the project is considered complete.

Pentest – Methods and Goals
A structured methodology aimed at finding and exploiting technical vulnerabilities in networks and systems. The goal is to identify threats and provide recommendations for their remediation.

Pentest – Approach
The client’s information security service knows the start and end times of the testing, as well as the main stages and conditions of the pentest. There is an exchange of information between the information security service and the pentesters. The client not only does not interfere but sometimes even assists in certain aspects of the work.

Both approaches — Red Team and pentesting — allow assessing the company’s level of security but are conducted under different conditions. To illustrate this clearly, I referred to old records. I will tell you how the team I worked with conducted its first Red Team engagement.

Red Teaming in Practice: Task Setting

We had to investigate a company that provides financial and credit services to citizens. Let’s call it The-Company-That-Must-Not-Be-Named (TCTMBN). Some details and parts of our actions will be concealed in the interest of the client. The essence will remain, but the story will become slightly simpler and shorter.

We were supposed to conduct penetration testing using the Red Team method, simulating the actions of attackers. Only the director of the company’s information security service knew about the upcoming attack. The client chose various components of the corporate infrastructure as targets:

  • Data Warehouse (DWH)
  • Databases with clients’ personal data and some components of 1C
  • Backups

In the ideal outcome, we were supposed to complete the task without the information security service noticing anything. But how did it turn out in reality?

Active and Passive Information Gathering

At the beginning of a project, pentesters are usually in a more advantageous position: the client provides them with all the necessary information: a list of company domains or a range of IP addresses to check. The executors often coordinate their actions with the information security service, for example, when using exploits in the working infrastructure, and do not waste time on unpromising attack vectors.

The Red Team works differently: we only had the company’s name, and we had to find all the information about the client’s IT infrastructure ourselves. We were interested in data about offices, employees, contractors, clients, and partners of the client: these people could have access to the infrastructure or corporate services.

For passive reconnaissance, we used several dozen utilities, including HackerTarget, Hunter, IntelX, IPdata, IPinfo, and NetworksDB, working with DNS, BGP protocols, and SSL certificates. As a result, we discovered:

  • Several subsidiary projects besides the company’s main website. We also identified a CIDR belonging to the client’s infrastructure.
  • The locations of offices and documentation from open sources about the physical protection of objects.
  • Several thousand corporate email addresses of employees, some of which appeared in password breaches.

Unfortunately, we could not use the identified credentials to access corporate services — the passwords had already been changed. Password spraying attacks with the leaked email addresses and common passwords also failed.

We tried to conduct a phishing campaign targeting executives’ addresses to gain initial access to the client’s network but encountered difficulties here as well. Later, we examined employees’ mailboxes and found that the emails were identified as phishing by the security systems and thus were quarantined.

Next, we moved on to active reconnaissance. Using DNS reconnaissance tools, we compiled a list of subdomains in the company’s domain zones and scanned the services operating there.

Although we did not find easy paths, we managed to gather information for further work. The priority targets for testing became:

  • The main website and its API.
  • Services operating in the domain.
  • The company’s offices, which we decided to visit personally and plant devices.

Testing the External Network Perimeter

We analyzed TCTMBN’s website and found several critical vulnerabilities. Exploiting them could have led to a massive leak of confidential information and personal data. One of these vulnerabilities was a classic IDOR (Insecure Direct Object References).

Access to some objects in the system was implemented via a direct link with unique identifiers. However, the system did not check whether the requested identifier belonged to the user. Additionally, the identifiers themselves had low entropy, making them vulnerable to brute-force attacks.

GET /api/v1/file/1337/preview/big HTTP/1.1
Host: КННН.com
Cookie: bonusHidden=false; _platform=%7B%22firstName%22%3A%22T%22%2C%22lastName%22%3A%22T%22%7D
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer [..]
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers
Connection: close

By sending a GET request like /api/v1/file/1337/preview/big with an arbitrary numerical file identifier, it was possible to access the database containing passports, contracts, and other documents of TCTMBN’s clients. This was a large database: newly uploaded files received an identifier with a number greater than 3,000,000.

Demonstrating the Presence of IDOR

The same issue occurred when making a GET request to the API: /api/v1/file/10?download=false.

We also discovered the possibility of injecting arbitrary code into the SQL query in the personal account search form on the website. This vulnerability could be exploited using the Boolean-based technique. In this scenario, the attacker receives different content depending on the logical result (True or False) when sending a query to the database.

The vulnerability can be demonstrated with two queries. By comparing the length of the responses, it becomes clear that they differ. This occurs because in the first case, the SQL query includes a condition that returns True, while in the second case, it returns False. To simplify working with this type of attack, a tool called sqli_blinder is often used.

In the end, we were able to extract refresh tokens for the administrative account from the database.

Compromise of Administrative Account Refresh Tokens

In addition to these vulnerabilities, we identified several dozen less serious bugs. As a result, we gained access to some databases with personal data but did not find anything that would help us penetrate the internal network of the company.

This is an expected outcome. According to our statistics, successfully breaching the web and advancing the attack into the corporate network occurs in about 10% of cases. This may be because we often work with large companies that have fairly mature information security processes and services. These companies have already been targeted multiple times before us — by both pentesters and attackers. Therefore, security issues are given a lot of attention, including at the architectural level. For example, external services may be reliably isolated from corporate networks.

Physical Penetration into Client Offices

Often, it is easier to hack into the infrastructure of large companies offline. Therefore, in parallel with the external pentest, we sent our agents to the client’s offices.

First, they conducted OSINT: they examined the company’s YouTube channel and watched playlists with HR materials. From the videos, it is possible to understand the approximate layout of the offices, the organization of access inside, the location of sockets, and even blind spots of surveillance cameras, and use this information for their purposes.

The First Site

At the first office, we got lucky: there was an open-to-all meetup on information security in the financial sector. We combined business with pleasure — listened to the presentations and found convenient RJ-45 sockets in the hallways. However, we decided not to install wired drops as we could not accurately determine which sockets belonged to the client’s LAN and which were part of neighboring tenants’ networks.

There was another option — to work with the corporate Wi-Fi network. For the audit, we used wifite. WPA-E with client authentication made the network resistant to typical WPA/WPA2/WPS protocol attacks. Therefore, we decided to return to the office the next day and set up a fake access point.

We couldn’t get inside after the meetup ended. Fortunately, the network had a good signal outside the secured area, for example, in the business center’s cafeteria, where we could enter with a temporary pass. It was there that we applied the EvilTwin technique in conjunction with GTC Downgrade.

The fact is that authentication clients and servers are usually configured to support various EAP methods: this helps reduce the likelihood of device compatibility issues. Among these methods are some insecure ones — EAP-GTC and EAP-PAP. The GTC Downgrade attack is a version downgrade attack on EAP. It can force a victim to authenticate on a fake access point using a weakly protected EAP method that transmits credentials in plain text or NetNTLM hashes.

On That Day, Using eaphammer, We Compromised 27 Accounts: 22 Passwords Were Obtained in Plain Text, and 5 as NetNTLM Hashes. The Validation of Intercepted Login-Password Pairs Was Successful; We Gained Domain Access and Collected Information About Active Directory Objects Using BloodHound for Further Analysis.

The accounts obtained during this attack were useful in subsequent stages of the Red Team engagement. Additionally, we concealed a network implant in the building — an Android smartphone with internet access, an unlocked bootloader, and Nethunter installed. However, the signal was unstable, so it wasn’t possible to work productively on an ongoing basis through this communication channel.

The Second Site

Working with the second TCTMBN office didn’t go smoothly at first. We couldn’t get inside even with a ladder and a work overall. No kidding, an electrician’s outfit is a universal pass in almost any business center, but it didn’t work here. We had to look for other places to catch the corporate Wi-Fi:

  • Paid parking close to the building.
  • Smoking area for employees and clients near the main entrance.
  • Nearby restaurant.

The main problem was that we had no place to “settle in” for quiet work: we needed to occupy a specific table in the restaurant or spend hours in the smoking area. In the end, we rented a car-sharing vehicle for a week, which we drove to the parking lot at night and left it in the target network’s coverage area.

In the Trunk, We Hid a Set Consisting of an Enhanced Wi-Fi Antenna (Alfa AWUS036NHA), a Laptop, and a 4G Modem. We Powered Everything Using a Couple of Car Batteries and Connected Via AnyDesk. Finally, We Had a Stable Remote Connection to the Client’s Internal Network.

Investigating the Corporate Infrastructure

After establishing the connection, we used the credentials obtained from the first office. We managed to access employee emails and Office 365 services (SharePoint, Teams). This success was due to the absence of two-factor authentication, which the company administrators had not configured.

In the email accounts, we found credentials for other services as well as instructions and settings for the corporate VPN. Although we could not connect to the VPN without the second factor, we accessed 1C and data-docs without issues.

The most valuable find awaited us on one of the file servers — an export file from 1Password containing 163 unique records with credentials for various systems.

Obtaining the Password File

Local Accounts

In the 1Password file, we found the password for the local account sadmin. This account had local administrator rights on several BPA servers.

The servers did not have event logging configured for subsequent log analysis. Additionally, they had internet access.

Group Policy Disabled Auditing on Hosts

These servers could have become a starting point for an attack on the organization. However, at that moment, the security team suspected something and blocked one of the accounts we were using in parallel. In response, we decided to use another attack vector that seemed more promising.

In the same 1Password export, we discovered an account that was part of the “Account Operators” group. This group is one of the most dangerous due to its GenericAll privileges over users, computers, and other groups, with exceptions only for built-in groups like Domain Admins, Administrators, and Backup Operators.

We managed to find the credentials of a support employee who was part of this group. We discovered that the Description attribute field contained a path to a shared resource, \\server\Shared_Folders\IT, and we assumed that this directory might contain valuable information. Therefore, we decided to attempt to access the file system of the server hosting this resource.

Reading the ms-msc-admpwd Attribute

The Account Operators group has GenericAll rights over domain objects. This allows it to read the ms-msc-admpwd attribute (LAPS) and retrieve the password for the local account. We found the local account name in the group policy for local server admin, where the standard name administrator was changed to sadmin.

The next step was to gain access to the file system, but no useful information was found there.

Access to Disk D$

Access to the Certification Authority

The attack was dragging on. We spent several days investigating the domain and started to worry about the potential loss of access to the account in the Account Operators group. Without it, we would lose our chances of reaching the data warehouse (DWH) and backups.

To establish a foothold in the infrastructure, we decided to obtain the root certificate from the certification authority. This would allow us to issue fake certificates for any user.

Membership in the servers_admins group granted our account local administrator rights on the server. The group policy rdp certificate required a certificate on the client side; otherwise, connecting to the server via RDP was impossible. Therefore, we used the PSRemoting technique for remote access to the necessary server and then created a backup of the certification authority certificate.

We also created an LSA dump containing information about local accounts.

The client’s domain was running on the 2012 version. This limited the capabilities of PKINIT; for example, we could not obtain a Kerberos TGT ticket using the certificate. However, the certificate could still be used for the Pass-The-Cert technique.

Pass-The-Cert allows using a certificate to connect to LDAP. With it, you can perform various queries, such as creating users and adding them to groups if you have the appropriate permissions.

Results of the Pass-The-Cert Technique

Thus, the copy of the certificate we created could potentially be used to generate certificates for any user.

Project Results

During the project, we achieved the following results:

  • Gained access to databases containing client documents.
  • Established reliable wireless access to the company’s internal network.
  • Accessed various company services and systems through compromised employee accounts. Gained access to email, SharePoint, internal document management system, 1C KED and 1C ZUP, Redash, and other systems.
  • Using the privileges obtained in the domain, accessed backup systems. However, due to the large size of the backups, it was impossible to covertly export them from the internal network.

From a penetration testing perspective, these results can be considered successful. However, as a Red Team, we were unsuccessful because the project ended earlier than planned.

Results of Incident Response Team’s Performance

While we were working, the client’s security team was not idle. They periodically detected suspicious activities—blocking service accounts with access to sensitive information, changing passwords even before we attempted to access them. Despite the large number of compromised accounts, we were able to continue our work, but at one point, a client representative informed us that we were exposed.

Initial suspicions were raised by our Wi-Fi adapter. We initially forgot to change the MAC address, and during the first connection, it was identified as Alpha. This brand is associated with hackers and drew attention during log analysis.

Additionally, the team made a mistake during data analysis. One of our testers connected their Outlook to a compromised email account. The account was blocked, and this might have been fine if not for the peculiarities of Outlook. If the program cannot authenticate with the given account, it tries to use the current Windows account. The username matched our employee’s nickname on Habr and Telegram, which allowed tracking the connection to our company.

Finally, There Was a Mistake in Organizing the Phishing Attack

An error occurred during the setup of the phishing attack. When registering the domain for sending emails, the account was named LLC Bastion. In a pentest, this might not matter much, but when the TCTMBN’s security team began their investigation and reviewed the quarantined emails, it ultimately exposed the operation. And the main rule of Red Team is: if you are exposed — the game is over.

…And Other Interesting Mistakes

Regarding other mistakes, the team made several early on.

For instance, the social engineers didn’t bring equipment for conducting attacks during the reconnaissance phase, which was particularly unfortunate in cases where penetration into the client’s office was successful. Another time, after gaining access to the corporate network on a Friday evening, the Red Team went off to celebrate the weekend. By the time they returned, the Blue Team had discovered the attack and blocked access, and we never regained it.

These errors have common causes: inertia of thinking and lack of habit in working discreetly under active countermeasures. In classic pentests, camouflage isn’t required, whereas in Red Team engagements, a lot of small details need to be considered due to the need for stealth.

Red Team specialists constantly balance between two tasks. On one hand, they need to avoid harming the client’s infrastructure. On the other hand, they must ensure the confidentiality of their actions. This requires constant attention and significantly increases cognitive load.

Therefore, Red Teaming is considered one of the most challenging activities in the practice of security teams. But this difficulty also makes it an attractive challenge for many professionals. This is why many enter the profession for such tasks.

Red Team vs Blue Team in Cyber Security | Zero To Mastery