Identity-based APT 2026 attack: how groups go from endpoints to the cloud and mail – Red Team and Detection Guide

Depov

Activist
ULTIMATE
SUPREME
PREMIUM
MEMBER
Joined
Feb 18, 2025
Messages
126
Reaction score
116
Deposit
0$
In November 2023, the APT29 (Midnight Blizzard) climbed into the corporate environment of Microsoft through the password spraying of the only test cloud tenant without an MFA. Test tenant. Without MFA. At Microsoft. From there - through the attacked malicious OAuth application with rights full_access_as_app to Exchange Online - the group for about two months quietly read the mail of the management and legal department until the incident was opened in January 2024. EDR did not issue a single ailet: the whole chain passed in the identity-plane, bypassing the endpoints, according to Microsoft MSRC (January 2024).

Six months later, the UNC5537 cluster (according to Mandiant attribution; some of the data were later distributed by ShinyHunters) affected about 165 organizations - Snowflake customers. Again credentials from the Infosilers, again enforce without MFA, again without triggering endpoint agents. The IBM X-Force Threat Intelligence Index 2025 records an increase in attacks using valid accounting data by 71% year-on-year, and CrowdRStrike Global Threat Report 2025 gives even tougher: 75% of the incursions through valid creedials, 79% without malware. For mature APT clusters, the endpoint has become an optional link in kill chain.
The economy of identity-first attacks: why APT leave the endpoints
Moving attackers to identity-plane is a rational choice, not a fashionable word from the reports. Three factors make the cloud account APT the main vector.
EDR is blind in design. When the attacker authenticates with validation accounts through the Graph API or EWS, it does not start the process on the host, does not load DLL, does not touch the file system. For endpoint agent (CrowdRSTrake Falcon, SentinelOne, Kaspersky EDR Expert, Elastic 8.x+) it looks like a legitimate session. Compromise of accounting data in the cloud - a blind zone of the EDR not because of the configuration curve, but by architecture. The agent monitors the host, and the attacker does not come to the host.

The scale of the conveyor credentials. According to IBM X-Force, about 6 000 fresh accounts appear in the dark web every day. Infostilers VIDAR, REDLINE, LUMMA, RISEPRO, RACOON STEALER and METASTEALER (according to Push Security, these are the options used in the anti-Snowflake campaign) provide the industrial flow of credential pairs. In the absence of a spread secret MFA, one pair = access to dozens of SaaS-applications. According to Verizon DBIR 2025, 38% of the leaks are related to the credential theft, and 68% are associated with the participation of the human factor.

Detection time is not in favor of protection. Mandiant M-Trends 2025 captures the median dwell time of 11 days - a historical minimum, but for identity-perestation it is an optimistic estimate. When fixing lives in OAuth grants or federation trust, SOC with an endpoint-center focus may not detect the attacker months. 57% of organizations learn about the incident from the outside, rather than from their own detection systems. Read this number again.

The financial context for Blue Team: the median ransomware, according to Verizon DBIR 2025, is $46 000, the maximum in a single incident is $75M. For state-owned APT, the motivation is not financial, but negotiable fines for PD leaks and direct damage from the compromise of mail management correspondence is multiples more expensive.
Kill chain identity attacks: from password spray to Golden SAML
The typical identity-based chain of APT in the cloud infrastructure goes through five stages. Each is on a specific MITRE ATT&CK technique and has its own detection signal.
Initial Access and Credential Theft (T1078, T1621)
Valid Accounts (T1078, Initial Access / Persistence / Defense Evasion) The foundation of the chain. Sources credentials: infosellers, password spraying, credential stuffing from combologists. In the Microsoft case - password spray vs test tenant. In the Snowflake case - credentials from the informers, caught in Telegram channels and on a dark web forum. According to CrowdStrike, the average time of the element movement after the initial access is 62 minutes, the record is 51 seconds. Minute. It's not an hour.

Applicability: any environment with cloud IdP (Entra ID, Okta, Google Workspace). Critical in the presence of legacy auth protocols (IMAP/SMTP) - password spray through them bypasses the MFA because the legacy protocols do not support MFA-challenge in principle. On Windows-hosts attackers use LOLBAS-utilitis Cmdkey.exe (cmdkey /list) for listing cached credentials - mapping MITRE: T1078 (Valid Accounts).

Detection: correlation >10 unsuccessful auth-attempts on >5 different UPN with one IP in 10 minutes - control password spray. SigmaHQ has 116 rules available on the T1078 tag, including azure_tap_added.yml (detection of Temporary Access Pass) and azure_pim_change_settings.yml (Changing the PIM settings).

MFA Fatigue (T1621, Multi-Factor Authentication Request Generation, Credential Access) If MFA is included via push notifications, APT29 uses MFA resilience: a series of push-requests in non-working hours (02:00–04:00). The victim presses “Confirm” to stop the flow – at three o’clock in the morning people do not think, but react. According to Unit 42, more than a third of the 2024-2025 incidents began with social engineering, and MFA fatigue is one of the working technicians.

Applicability: Wednesday with push-based MFA (Microsoft Authenticator push, Duo Push). Does not work against FIDO2, phishing-resistant MFA, number matching.

Detection: >5 deviated MFA queries (ResultType 500121 in Entra ID) in 15 minutes from one UPN, followed by successful authentication.
Persistence and Lateral Movement (T1606.002, T1550.001, T1098)
Golden SAML (T1606.002, SAML Tokens, Credential Access). In the presence of AD FS in a hybrid medium, the attacker targets a token-signing certificate. Compromise of the certificate allows you to forge SAML tokens for any user in the federation - including Global Admin - without re-authentication. In fact, this is a master key to everything.

Platform: azure-ad. In the Atomic Red Team repository, the Golden SAML test for T1606.002 has a platform: ad - it emulates the fake SAML tokens against Azure AD. The preparatory stage - extracting token-signing certificate from AD FS-host - in the Atomic repository is not covered and is performed separately through the lateral movement on-prem-segment. The technique is not applicable to organizations that have completely migrated to cloud-native identity without AD FS.

Detection: SAML-assertions with anomalous NotBefore/NotOnOrAfter (>24 h), tokens for users without AD FS-autente in the last 30 days, changes to the metaadata. MITRE D3FEND: D3-CCSA (Credential Compromise Scope Analysis) and D3-CR (Crendential Revocation).

Application Access Token (T1550.001, Lateralition Movement) After gaining access to the identity-plane, the attacker moves between the services via OAuth tokens: Graph API, EWS, SharePoint Online - everything is available without re-authentication. According to CloudSEK, persistence APT29 “was primarily is within email and collaboration platforms rather than through endpoint-focused intrusion”. No binaries on the disk, no suspicious processes - a clean API.

Account Manipulation (T1098, Persistence / Privilege Escalation) Fixing: Adding client secret to the existing Service Principal, creating a new federation trust, assigning roles. Three tests are available for the T1098 for the T1098: Admin Account Manipulate (PowerShell, Windows), Domain Account and Group Manipulate (PowerShell, Windows), AWS group/user product (WS).

Detection for T1550.001 and T1098: new OAuth consent grant with permissions Mail.Read, Mail.ReadWrite, Files.Read.All. Adding credentials to Service Principal in AuditLogs. By SigmaHQ: okta_session_impersonation_granted.yml (T1199) - session impersonation as a Trusted Relationship abuse indicator.
Insider threat and compromised legitimate hosts
Here’s what a real headache for SOC: a compromised account is indistinguishable from insider threat tools for standard monitoring. When an attacker uses a real employee’s valid credentials, his actions – reading mail, downloading files from SharePoint, access to Teams – look like normal user activity.

The distinction requires a baseline of the behavior of a particular user: geolocation, activity time, set of applications, the amount of downloaded data. Without behavioral baseline (D3-AM, Access Modeling according to MITRE D3FEND) detection is impossible. Not “difficulty” is impossible.
When what technique is used: decision tree for detection engine
1780169440890.png

Detection engineering: KQL, Sigma and correlations for identity-attacks
Adjustments to the environment
• SIEM: Microsoft Sentinel (KQL requests below). For Splunk, Elastic 8.x+, MaxPatrol SIEM, KUMA - conversion of Sigma-rules via sigma-cli or pySigma
• Sources: Entra ID Sign-in Logs, Audit Logs, Microsoft 365 Unified Audit Log. For Okta: System Log API
• Retention: at least 90 days, recommended 180 (identity attacks have a dwell time above average)
• Rights: Security Reader in Entra ID, access to Log Analytics workspace
Sigma-rules and additional correlations
From SigmaHQ (github.com/SigmaHQ/sigma) compromise for email detection and identity threats are the most relevant:
• azure_tap_added.yml(T1078) - Adding Temporary Access Pass Frequently Used for Bypass MFA
• azure_pim_change_settings.yml(T1078) - Change of settings Privileged Identity Management
• okta_session_impersonation_granted.yml(T1199) - session impersonation in Okta
What requires custom beyond the standard Sigma:
• Abnormal OAuth's Enson: New Application with Mail.Read / Mail.Read.All from a user who has not previously created App Records
• Federation trust changes: new entries in Trusted Domain Objects - preparation indicator for Golden SAML
• Service Principal credential rotation: Addition client secret to SP, which >180 days did not add credentials
According to MITRE D3FEND, the key security equipment: D3-DAM (Domain Account Monitoring) and D3-AM (Access Modeling) for T1078; D3-CCSA (Credential Compromise Scope) for T1606.002; D3-AL (Account Locking) with mass password spray.
Hardening identity infrastructure: checklist
Ready-made checklist to transfer to the infrastructure team. According to NIST CSF v2.0 measures are mapped PR.AAA-01 (Identity Management, Authentication, and Access Control) and DE.AE-01 (Adverse Event Analysis). Print and hang over the monitor - seriously.
1. Enforce MFA on 100% accounts, including test, service and break-glass. MFA type: FIDO2 or certificate-based. Not push-only, not SMS. Test tenant Microsoft without MFA has become an entry point for APT29 - this is not a theory.
2. Block legacy authentication in Entra ID (Conditional Access - Block Holding Auth). Password spray via IMAP/SMTP/POP3 bypasses MFA.
3. Prohibit User Enson for OAutho Apps. Allow only admin consent workflow. Monitor AuditLogs to new consent grants.
4. Rotate AD FS token-signing certificate at least once every 90 days. Private key - in HSM. Monitor changes to metadadata.
5. Automate the advert with client secret or certificate to any Service Principal (Add service basic teacher in AuditLogs).
6. Create whitelist allowed OAuth App IDs. Alert on the emergence of a new application with permissions Mail.Read and above.
7. Conditional Access: Location + device compliance + risk level. Don't rely on MFA. Each authentication is through the policy stack.
8. Retention logs: at least 180 days. Identity-based attacks have a dwell time above the median 11 days (Mandiant M-Trends 2025).
9. Audit of cached credentials at workstations. cmdkey /listshows the stored accounts - LOLBAS-vector for T1078.
10. The Atomic Red Team is running quarterly: T1098 Account Manipulation - three atomic tests (Admin Account, Domain Account, AWS group); T1606.002 SAML Tokens - automatic test of Golden SAML on azure-ad. Verify that SIEM generates an alterth to each test. If the altrate didn't come, it would not have come in case of a real attack.
The observation that has been formed over the past two years on the analysis of incidents with identity-based compromising: the SOC teams have been building detection around endpoints for years - suspicious processes, lateral movement through SMB, anomalous DNS. APT, meanwhile, shifted to a plane where these signals simply do not exist. One OAuth grant - and the attacker reads the mail of the CEO through the Graph API without a single artifact on the disk.

75% of the incurs via valid credentials on CrowdStrike and +71% growth in the credential-based attacks on IBM X-Force is not a trend, it is a paradigm shift. EDR is not broken - it works normally, just four out of five incidents pass it in design. Organizations that by mid-2026 do not monitor OAutholy grants, trust changes and Service Principal subreddized entities will detect compromises only after notification from CERT or counterparty.
 
Top Bottom