The Post-Compromise Gap: Why Mature Keep Winning

Why Your Current Security Products Are Failing

Traditionally, most security teams have focused on perimeter defense and when breached focus their efforts around network security monitoring and endpoint detection. Current security products excel at these areas, with:

Endpoint Detection and Response (EDR) offerings like CrowdStrike, Elastic, and SentinelOne leading the way. EDRs are not good, they are great at detecting a large majority of traditional malware attacks targeting the endpoint.
Network Detection and Response (NDR) like Darktrace and Vectra, while often noisier, provide an invaluable source of telemetry and level of visibility for the security team.

However, despite the deployment of these products, both mature adversaries and Red Teams do not seem to be deterred in their attempts to compromise organizations and persist within networks for extended periods of time. That begs the question, why are these detections failing and where is the disconnect between the understanding and expectation of what attacks look like and what they often shape up to be?

On the majority of Red Team engagements we have been involved in, often hands on as an operator - we have always followed a common set of playbooks. These techniques, while not novel, have been highly effective at both:

Obtaining initial access without deploying malware to endpoint systems
Escalating privileges and compromising high value targets
Persisting within networks for extended periods of time

These playbooks are not unique to the engagements we have been involved in, but are instead a reflection of the reality of the modern security landscape - with real world attacks quickly shaping up to match these playbooks.

And almost every time, these playbooks are successful and lead to the compromise of the organization, often without detection, but almost always without eviction/response.

If you are on a Blue Team and have recently sparred with a Red Team you likely have a sour memory of lacking the ability to detect and respond to the techniques used by the Red Team - at least that is what everyone tells me.

Why is this the case, and more importantly, what can be done to improve the situation?

What Has Changed for Adversaries?

We will break down both the tactics, techniques, and procedures (TTPs) that work for Adversaries and Red Teams. The disconnect between what Blue Teams expect and what Adversaries are doing is often due to a lack of understanding of the adversary's TTPs. Bridging this gap will help Blue Teams understand the reality of the modern security landscape and start to close the gap.

Traditional Attack Paths

All breaches begin with initial access. The goal of initial access is to identify and "exploit" a primitive that allows them to deploy malware to an endpoint within the target organization's network.

From this foothold, the attacker can perform enumeration actions like Active Directory discovery and network scans to identify any potential misconfigurations and understand what systems and services exist in the environment.

Traditionally, adversaries have focused on obtaining initial access to an environment through a primitive that allows them to deploy malware to an endpoint. These primitives are often incredibly situational, based on the organization. For example, in the case of phishing this would be targeting either employees or high-privilege helpdesk operators to download and execute a payload.

From this position on the network the attacker would then begin by enumerating both Active Directory with LDAP queries and performing network scans to identify services and systems accessible from the current foothold. For example, if an SMB share was identified as readable - an attacker would look to see if they could access the share and enumerate any files with credentials.

Mature security teams will have implemented a number of controls to prevent this type of initial access at multiple layers. These types of attacks are often highly unlikely to be successful against well-defended organizations.

Modern Adversary TTPs

These techniques, while not novel, have been jokingly referred to as Read Teaming due to the nature of the actions taken by the adversaries - primarily focused around spending large amounts of time reading through internal knowledge and document stores.

This often includes locations like:

Source Code Repositories (GitHub, GitLab, BitBucket)
Internal Documentation (Confluence, Google Docs, SharePoint)
IT Support Ticketing Systems (Jira, ServiceNow)
Collaboration Platforms (Slack, Microsoft Teams)

The pattern we observe consistently: once an attacker gains access to a user's identity, they spend the majority of their time understanding the environment. They are reading your IT runbooks. They are searching your wikis for "VPN" and "AWS" and "password". They are looking at your architecture diagrams.

This is not unique to our engagements. CISA's Scattered Spider advisory documents the same behavior:

"Once persistence is established on a target network, Scattered Spider threat actors often perform discovery, specifically searching for SharePoint sites, credential storage documentation, VMware vCenter infrastructure, backups, and instructions for setting up/logging into Virtual Private Networks (VPNs)."

The ShinyHunters campaign against Snowflake customers demonstrated this at scale - 165+ organizations compromised using credentials harvested from infostealer logs, some dating back to 2020. No exploitation required. They logged in and queried the data.

Privilege Escalation

Modern privilege escalation rarely involves exploits.

On the majority of our engagements, we escalate privileges by finding credentials - not by exploiting vulnerabilities. The credentials are almost always sitting in one of the following locations:

Internal Documentation

IT wikis with service account passwords
Onboarding guides with default credentials
Architecture documents with connection strings

Source Code and Configuration

Hardcoded AWS access keys in repositories
Database credentials in configuration files
API tokens committed to version control

Cloud Infrastructure

AWS Secrets Manager entries accessible to overly permissive IAM roles
Azure Key Vault secrets readable by compromised service principals
SSM Parameter Store values with sensitive data

Password Managers and Vaults

CyberArk credentials checked out by compromised users
LastPass vaults accessible via session tokens
1Password shared vaults with broad access

The ReliaQuest analysis of a Scattered Spider incident documents exactly this pattern - attackers accessed CyberArk credentials for VMware vCenter, checked them out using legitimate access, and used them to create unmanaged VMs for staging operations.

From a detection perspective, this looks like normal user activity. An authorized user accessing documentation. An authorized user checking out credentials from a PAM solution. An authorized user querying Secrets Manager.

Your EDR sees none of this. It is watching for process injection and malicious binaries while the attacker is browsing SharePoint.

Cloud Enumeration

Once credentials are obtained - whether from documentation, code repositories, or credential vaults - attackers enumerate cloud infrastructure using legitimate tools and APIs.

Identity Provider Enumeration

For Entra ID / Azure AD environments, attackers use tools like:

AzureHound - Queries Microsoft Graph API to enumerate users, groups, service principals, role assignments, and privilege escalation paths
GraphRunner - PowerShell post-exploitation for mailbox search and SharePoint enumeration
ROADtools - Tenant enumeration with web UI visualization

Unit 42 documents how AzureHound is used:

"Threat actors enumerate Entra ID groups, roles and role assignments because they collectively define how access and permissions are distributed across users, applications and resources."

These tools make legitimate API calls. From the perspective of Microsoft Graph, this is indistinguishable from an administrator running compliance reports or an IT team auditing permissions.

AWS Enumeration

For AWS environments, attackers use:

S3 Browser - GUI tool for bucket enumeration (ListBuckets, ListObjects, GetBucketLocation)
AWS CLI - Querying IAM roles, Secrets Manager, SSM Parameter Store
Systems Manager Inventory - Discovering EC2 instances for lateral movement

CrowdStrike's Scattered Spider analysis documents the tooling:

"Used S3 Browser to enumerate victims' Amazon Web Services (AWS) S3 buckets (AWS CloudTrail events: ListBuckets and ListObjects) and exfiltrate data to remote adversary-controlled S3 buckets."

Again - these are legitimate API calls. CloudTrail logs them, but distinguishing malicious enumeration from normal developer activity requires context that most organizations do not have.

Why Detection Is Hard

The challenge is not that security teams lack telemetry. The challenge is that modern attacks generate telemetry that looks identical to legitimate activity.

Attack Phase	What EDR Sees	What NDR Sees
Help desk social engineering	Nothing	Nothing
Authentication with stolen credentials	Nothing (valid login)	Nothing (expected traffic)
MFA device enrollment	Nothing	Nothing
RMM tool installation	Low priority (signed binary)	Expected application traffic
AzureHound enumeration	Nothing (no endpoint execution)	HTTPS to Microsoft endpoints
SharePoint / Confluence search	Nothing	Nothing
S3 bucket enumeration	Nothing	HTTPS to AWS endpoints
Secrets Manager access	Nothing	Nothing
Data staging	Nothing	Possible egress volume alert
Exfiltration	Nothing	Possible egress volume alert
Ransomware deployment	High severity alert	Encryption traffic patterns

The majority of the attack lifecycle uses valid credentials, legitimate tools, and native APIs. Detection fires at the end - when ransomware executes or data exfiltration volumes trigger egress alerts.

By then, the attacker has had weeks or months of access. The UK retail incidents in 2025 demonstrated dwell times of approximately 8 weeks before ransomware deployment.

The Behavioral Baseline Problem

Behavioral analytics does not solve this problem.

When an attacker compromises a user's credentials, they inherit that user's behavioral baseline. The queries they run, the systems they access, the data they touch - it all falls within the expected pattern for that identity.

Enumeration tools can throttle their requests to avoid volume-based detection. A patient attacker running AzureHound across multiple sessions over several days will not trigger rate-based alerts.

The fundamental issue is that we are trying to identify malicious patterns in legitimate activity. The tools are legitimate. The APIs are legitimate. The access patterns are within expected bounds.

What Threats Are We Addressing?

The threat landscape in 2025 has converged around identity-based attacks. We are seeing this pattern across multiple threat actors:

Scattered Spider / UNC3944

Help desk social engineering for initial access
RMM tools for persistence (AnyDesk, TeamViewer, ScreenConnect)
AzureHound / GraphRunner for cloud enumeration
DragonForce ransomware deployment on VMware ESXi
CISA Advisory

ShinyHunters / UNC5537

Infostealer-harvested credentials for initial access
Snowflake / Salesforce data theft at scale
OAuth device flow abuse for persistence
Mandiant Research

BlackBasta (pre-shutdown)

Microsoft Teams-based social engineering
Email bombing followed by fake IT support calls
Quick Assist / AnyDesk for remote access
Azure Run Command for payload execution

APT29 / Midnight Blizzard

Password spraying against cloud service accounts
Residential proxies to mask authentication
Cloud authentication token theft
Microsoft Threat Intelligence

Silk Typhoon / Hafnium

SaaS provider supply chain compromise
OAuth token theft from application registrations
Azure Key Vault credential extraction
Microsoft Threat Intelligence

The common thread: identity is the attack surface. Initial access via social engineering or credential theft. Persistence via MFA manipulation or federation backdoors. Discovery via legitimate APIs. Privilege escalation via credential harvesting from documentation and vaults.

Traditional security products are optimized for a different threat model - malware delivery, exploit execution, anomalous network traffic. They remain excellent at detecting those attacks. But the attacks have moved on.

The Post-Compromise Window

There is a window between initial access and impact where attackers operate with minimal detection coverage.

Diagram

Prevention (IdP, MFA) covers initial access. Response (EDR, IR) covers impact. The post-compromise window - where attackers spend 90% of their time - has limited detection coverage.

This is where credentials are harvested, infrastructure is mapped, and data is staged.

This window - where attackers are actively operating but have not yet triggered detection - is where the damage accumulates. It is where credentials are harvested, infrastructure is mapped, and data is staged.

The organizations that close this window are the ones that detect the reconnaissance activity, not just the final impact.

What Can Be Done?

There is no single solution that addresses this problem. But there are approaches that improve detection coverage in the post-compromise window.

Identity Monitoring

Baseline identity behavior and alert on anomalies
Monitor for MFA device changes, federation configuration changes, privileged role assignments
Track authentication patterns across cloud applications

Cloud API Monitoring

Ingest and analyze CloudTrail, Entra ID audit logs, and Microsoft Graph activity logs
Build detections for enumeration patterns (mass ListBuckets, service principal enumeration)
Monitor for sensitive data plane API calls

Credential Hygiene

Regular rotation of service account credentials
Audit and remediate hardcoded credentials in code repositories
Restrict access to credential vaults and monitor checkout activity

Deception

Deploy resources with no legitimate business purpose
Any access to these resources is definitionally suspicious
Provides high-confidence signal during the reconnaissance phase

The challenge with the first three approaches is signal-to-noise. Legitimate users also change MFA devices. Legitimate administrators also enumerate cloud resources. Legitimate developers also access secrets.

Deception inverts the model: instead of trying to identify malicious patterns in legitimate activity, you create resources where any activity is malicious. AzureHound will enumerate your decoy service principals. Attackers searching SharePoint will find your planted credentials. S3 Browser will list your decoy buckets.

The alert is binary. Access equals unauthorized activity.

Conclusion

The state of red teaming in 2025 reflects the state of real-world attacks. Identity-based initial access. Patient reconnaissance through documentation and cloud APIs. Credential harvesting from vaults and configuration files. Privilege escalation without exploits.

EDR and NDR remain essential - they are still excellent at detecting malware and network-based attacks. But the attack surface has expanded to include identity providers, cloud APIs, and SaaS applications. Detection strategies need to expand as well.

If you are a Blue Team that recently lost to a Red Team, you are not alone. The techniques we use as operators are the same techniques used by Scattered Spider, ShinyHunters, and APT29. They are effective because they exploit a gap in detection coverage.

Closing that gap requires detection that does not depend on identifying malicious behavior. It requires resources where any behavior is definitionally malicious.

Want to see how deception closes the post-compromise gap? See how it works or reach out at hey@deceptiq.com.

The Post-Compromise Gap: Why Mature Adversaries Keep Winning