Operationalizing MITRE ATT&CK in FRC’S AEV Lab Environment with AttackIQ 

Adversarial Exposure Validation (AEV) is the process of testing security defenses by executing the same tactics, techniques, and procedures (TTPs) used by real-world threat actors. Unlike traditional vulnerability scanning, which identifies missing patches or misconfigurations, AEV identifies whether those weaknesses are actually exploitable and if existing security controls like EDR, SIEM, or firewalls can detect or prevent the activity. 

The primary goal of our AEV lab is to better show the efficacy and interoperability of the tools in the FRC portfolio, and in this blog we cover how we use MITRE ATT&CK and AttackIQ to build our tests. Instead of assuming a security tool is working because it is installed, we use the lab to prove its efficacy through automated testing. 

The Foundation: MITRE ATT&CK 

The MITRE ATT&CK framework serves as the common language for our validation efforts. It is a curated knowledge base of adversary behavior broken down into a hierarchy of Tactics, Techniques, and Sub-techniques. 

• Tactics represent the adversary’s technical goals (e.g., Initial Access, Persistence, Privilege Escalation). 

• Techniques are the specific methods used to achieve those goals (e.g., Scheduled Task/Job, Brute Force). 

• Sub-techniques provide further granularity (e.g., OS Credential Dumping: LSASS Memory). 

By aligning our lab simulations with MITRE ATT&CK, we ensure that our testing is grounded in observed real-world behavior. This alignment also allows us to map our defensive “coverage” across a standardized matrix, making it easier to communicate risk and progress to stakeholders. 

Operationalizing the Framework with AttackIQ 

While MITRE ATT&CK provides the “what,” AttackIQ provides the “how.” AttackIQ is an AEV platform that automates the execution of these techniques. Within our lab environment composed of AWS EC2 instances and various security tools, AttackIQ functions as the orchestration layer, allowing us to deploy scripts that act as attacks to our endpoints. 

Crucially, these simulations are designed to be “adversary-informed” but safe for production environments. They mimic malicious behavior—such as attempting to dump credentials from memory—without actually compromising the integrity of the system or the underlying data. 

Deep Dive: Validating Defenses Against APT29 (Pass the Ticket) 

To demonstrate the technical utility of our AEV lab, we focus on a high-priority threat actor: APT29 (also known as Cozy Bear). APT29 is known for its sophisticated use of credential theft and lateral movement to navigate target environments. One of their hallmark methods is the Pass the Ticket (PtT) attack. 

1. Identifying the Adversary Behavior 

Using the MITRE ATT&CK framework (located at attack.mitre.org/groups), we identify the specific techniques typically utilized by APT29 for credential access and lateral movement. In this scenario, we focus on two critical sub-techniques: 

• T1003.001 (OS Credential Dumping: LSASS Memory): The adversary extracts Kerberos tickets from the Local Security Authority Subsystem Service (LSASS) process memory. 

• T1550.003 (Use Alternate Authentication Material: Pass the Ticket): The adversary uses those stolen Kerberos tickets (specifically Ticket Granting Tickets or TGTs) to authenticate to other resources without needing the user’s actual password. 

2. Mapping to AttackIQ 

We map these techniques directly to the “Pass the Ticket (PtT)” scenario within AttackIQ. It is important to note that AttackIQ’s threat intelligence engine already correlates this specific scenario to APT29 (along with other adversaries like APT28 and BRONZE BUTLER), as it mirrors their documented operational patterns. By selecting this scenario, we are emulating the strategic behavior of a known advanced persistent threat.

3. Scenario Execution in the EC2 Lab 

The scenario is executed against our Windows-based EC2 instances protected by our endpoint security stack. The AttackIQ agent initiates the following steps: 

• Credential Harvesting: The agent uses an automated script (typically leveraging a tool like Mimikatz) to dump Kerberos tickets from LSASS memory. 

• Ticket Injection: The agent then attempts to inject one of these harvested tickets into the current session to simulate a logon. 

• Resource Access: Finally, it attempts to use that injected ticket to access a restricted network resource or service. 

4. Analyzing Result Criteria 

AttackIQ provides clear success/failure criteria based on the outcome of the simulation: 

• Prevention Success: The EDR detects the LSASS memory access or the ticket injection and kills the process before the attack can complete. 

• Detection Success: Even if the attack completes, the activity generates high-fidelity telemetry or an alert in our logging system (e.g., Event ID 4624 for a logon with a forged ticket). 

• Failure: The attack completes—meaning the ticket was successfully harvested and injected—without any preventative action or detection alert. 

After running this scenario within our environment, we are able to see that it was stopped and detected by our endpoint security tool (Trellix) we have deployed and configured on our EC2 instance. We can also click and see Activity Details, Observable Details, and logs generated by the attack.

By running this specific APT29-informed scenario, we can move beyond generic antivirus checks and verify if our environment can specifically thwart the “pass the ticket” behavior that sophisticated actors rely on for lateral movement. 

Lab Architecture and Continuous Validation 

Our lab environment consists of multiple EC2 instances running various operating systems and levels of controls using tools from our partners. This setup allows for Continuous Security Validation (CSV), which provides several technical advantages over traditional point-in-time testing: 

• Regression Testing: We use AttackIQ to ensure that new system updates, security patches, or policy changes don’t inadvertently disable existing security detections. 

• Control Efficacy and Configuration Validation: We use the lab to verify that our security controls are not only “active” but correctly tuned for our specific workloads. AttackIQ allows us to identify “silent failures”—instances where a security tool is technically functional but its internal policy is too permissive to block or alert on a specific MITRE ATT&CK technique, such as credential dumping or unauthorized lateral movement. 

• Data-Driven Prioritization: Instead of patching every vulnerability with a high CVSS score, we prioritize those that our AEV lab proves can be exploited as part of a MITRE ATT&CK technique in our specific environment. 

Conclusion 

The combination of  AttackIQ and MITRE ATT&CK transforms security from a theoretical exercise into a measurable, data-driven discipline. By building an Adversarial Exposure Validation lab, we have created a repeatable process for discovering and mitigating risks before they are exploited by an actual adversary. This methodology ensures that our security stack is not just a collection of tools, but a functional, validated system of defense capable of withstanding real-world attacks. 

Ultimately, the synergy between MITRE and AttackIQ enables a Threat-Informed Defense. This approach ensures that every security investment (a new tool, a configuration change, or a staffing decision) is backed by empirical data derived from simulated adversary behavior. 

For security leadership, this provides a clear, defensible narrative. Instead of reporting on the number of blocked emails or generic firewall hits, teams can report on their “Coverage Map” of the MITRE ATT&CK matrix. They can prove, with data, that they have validated their defenses against the specific techniques used by the actors most likely to target their industry. This level of technical maturity ensures that the security stack is not just a collection of expensive products, but a functional, verified, and evolving system of defense.