Kimsuky's OAuth foothold: why the password reset does not evict them

You reset the phished analyst’s password, signed them out everywhere, and called the account recovered. An OAuth app keeps reading and sending their mail anyway. This is the Kimsuky (APT43) mailbox-persistence pattern, and the reason the reset fails is that the durable foothold was never the password.

How it works

Kimsuky starts with a tailored spear-phishing message, often spoofing a trusted sender because DMARC is not enforced, that points the target at a fake login page mirroring the real Entra sign-in. The user enters their password. The operator signs in with the harvested credential and immediately plants two footholds. First, they consent to an attacker-controlled OAuth application requesting delegated mailbox read and mail-send permissions, which provisions a service principal and a refresh token for the app in the tenant. Second, they create a hidden inbox rule that forwards inbound mail to an external address. This maps to T1566 (Phishing) and T1078 (Valid Accounts) for entry, T1528 (Steal Application Access Token) for the consent grant, T1098.002 (Account Manipulation: Additional Email Delegate Permissions) for the mailbox rule, and T1114 (Email Collection) for the objective.

Why it matters

The OAuth consent grant is an independent persistence mechanism. The application authenticates as itself with its own refresh token, not with the user’s password or session. So a password reset and a sign-out-everywhere, the reflex response to a phished account, do not touch it. The app keeps reading and sending mail while the account looks recovered. The forwarding rule is the second quiet channel: it copies inbound mail out regardless of what the user does, and it exposes not just the analyst but everyone who writes to them. The account credential was the way in. The app grant and the rule are the way to stay.

How to detect it

The sign-in itself can look ordinary, so the tell is the chain in a short window: a sign-in from a new device and ASN right after a credential-harvest hit, then consent to an unfamiliar OAuth app requesting mailbox scopes, then a new external forwarding rule. In the logs, watch the Entra audit log for consent-to-application events on apps requesting mailbox read and send, watch service-principal sign-ins running with no interactive user, and watch Exchange Online for New-InboxRule events that forward externally. MailItemsAccessed entries in the Unified Audit Log attributed to an application, not the user, are the sign that the app token is being used.

How to contain and shut it down

Lead with the grant and the rule, not the password. Revoke the illicit OAuth consent grant and disable the attacker app’s service principal so its own refresh token is invalidated, which is what actually stops the app reading and sending mail. Delete the external forwarding rule and any other hidden inbox rules the operator created. Then reset the credential and revoke sessions, and understand that alone it does nothing against an app that holds its own token. Sweep the tenant for other illicit consents and forwarding rules to prove there is no second foothold. Scope what happened from the authoritative records: the audit consent event, service-principal sign-ins, MailItemsAccessed by the app, and message-trace records that show exactly what was read and forwarded. The durable fixes are phishing-resistant MFA, an admin-consent workflow so users cannot grant mailbox scopes to third-party apps, blocked or alerted external auto-forwarding, and enforced DMARC, DKIM, and SPF to deny the spoofed-sender lure.

Practice it

GraphLattice Range runs exactly this incident: a spear-phish that harvests a credential, a malicious OAuth consent and a forwarding rule that survive the password reset, and the consent revocation and rule deletion that actually contain it. Teams learn to lead with the grant, not the credential, and to recognize why the reset was never going to be enough.