Rogue MFA Methods, Fake Devices, Quiet Apps: How Attackers Stay in a Tenant After You Think They Are Gone

Kicking an attacker out of a Microsoft 365 account is easy. Knowing they are actually gone is the hard part, because good attackers spend their first hours planting ways back in. We covered initial compromise through cookie hijacking, and the attacks that follow, in a previous article; this post zooms in on the persistence techniques common in Microsoft 365 as of June 2024, paired with recommended security baselines mapped to the CIS Controls. A theme to watch for: many of these protective policies are not configured by default.

How does the attacker get in to begin with?#

Persistence is the second act. The initial compromise can come from any number of attack methods depending on the other weaknesses in the environment, including:

• Phishing: the common opening of BEC today, where a clicked link leads to a man-in-the-middle attack or full user compromise if MFA is not enforced
• Token theft: session tokens harvested through AiTM attacks or cookie hijacking, used to bypass MFA and take over the account
• Malware: a compromised device giving up the account through various methods
• MFA fatigue: hammering a user with MFA requests after credential compromise until they approve one. Number matching has helped here, but the push method remains open to social engineering

Once in, attackers hide their presence and maintain access to buy time for a higher-level goal, moving along the attack chain to perform reconnaissance, move laterally, elevate privileges, or launch another campaign.

One scoping note: this article assumes the compromised user is a normal user with no elevated privileges. Privileged users open up significantly more persistence methods than what is covered here.

The three persistence techniques we see most:

1. Joining a device or MFA method
2. Registering applications
3. Creating inbox manipulation rules

Persistence play one: register an MFA method that belongs to the attacker#

If the user had no MFA at all, the attacker faces little initial friction. For users who did have MFA, the attacker's stolen session from AiTM or token theft is only good for a limited window, so the priority is keeping access after it expires. The move: add a second factor they control, typically SMS, email, or most commonly OTP on Microsoft Authenticator, and sign in at will from then on.

Protection 1: Tighten the Authentication Methods policy#

Modify the default settings (opens in new tab) in the Authentication methods section of Entra. We always recommend disabling SMS, email, and phone, the weaker forms of MFA. A logging detail worth knowing: "PhoneAppOTP" represents Microsoft Authenticator OTP, and attackers favor it because its metadata shows DeviceName as NO_DEVICE and DeviceToken as NO_DEVICE_TOKEN, which makes it less attributable.

Since most organizations have moved to number matching, disable OTP on Microsoft Authenticator as well.

CIS 4.8: Uninstall or Disable Unnecessary Services on Enterprise Assets and Software

Protection 2: Gate MFA registration behind Conditional Access#

Within a Conditional Access policy, under Target resources, choose User Actions from the dropdown and select Register security information. That targets the moment a user adds an MFA method or configures self-service password reset settings.

Several grant controls work here, each with a tradeoff:

• Require MFA: require MFA to enroll MFA? Yes. The user fulfills another MFA prompt before adding a method, which stops an attacker holding a stolen token cold, and even an MFA fatigue attacker would have to social-engineer a second approval. The operational cost: net new users need Temporary Access Passes issued during onboarding.
• Require a trusted location: registration only succeeds from defined IPs or countries. Harder with a remote workforce, but even a country-level restriction adds real protection.
• Require a compliant or managed device: with devices enrolled in Intune or Entra joined/hybrid joined, require that any MFA registration happen from one of them.

CIS 6.4: Require MFA for Remote Network Access

Protection 3: Hunt for MFA manipulation#

If you suspect compromise, the Entra admin center keeps an audit trail of registration activity under User registration details (Protection > Authentication Methods > User Registration Details).

For deeper hunting in Entra or Defender, this Microsoft security article (opens in new tab) provides detailed KQL queries for investigating MFA manipulation.

CIS 8.11: Conduct Audit Log Reviews

Persistence play two: join a device that looks like it belongs#

Attackers planning to keep access for months want to blend in, and a device joined with the compromised user's credentials does exactly that. It can end up Entra ID joined or registered, potentially even showing as compliant in Intune, which makes it far less likely to trip Entra's native risk detections. On the network side, the attacker may be in the same country or behind a VPN masking their real IP, so the sign-in logs offer no obvious anomaly either.

Protection 1: Gate device registration the same way#

The same User Actions mechanism in Conditional Access covers device joins.

Requiring MFA and/or a trusted location to register devices is a strong way to keep attacker hardware out of the directory.

CIS 6.4: Require MFA for Remote Network Access

Protection 2: Allow only corporate-approved devices#

A combination of Intune and Conditional Access settings can ensure only corporate-approved devices join the network. In Conditional Access, block personal devices:

In Intune, block personal devices from enrolling into MDM:

For more granularity, use corporate device identifiers (opens in new tab) to define corporate devices by serial number:

CIS 1.2: Address Unauthorized Assets

Protection 3: Hunt for rogue registrations#

This KQL query hunts for rogue device registrations:

// Hunting for rogue device registrations
let startTime = ago(7d);
let endTime = now();
CloudAppEvents
| where Timestamp between(startTime .. endTime)
| where ActionType == "Add registered owner to device." 
| where RawEventData contains "notorius"
| where AccountDisplayName == "Device Registration Service"
| where isnotempty(RawEventData.ObjectId) and isnotempty(RawEventData.ModifiedProperties[0].NewValue) and isnotempty(RawEventData.Target[1].ID) and isnotempty(RawEventData.ModifiedProperties[1].NewValue)
| extend AccountUpn = tostring(RawEventData.ObjectId)
| extend AccountObjectId = tostring(RawEventData.Target[1].ID)
| extend DeviceObjectId = tostring(RawEventData.ModifiedProperties[0].NewValue)
| extend DeviceDisplayName = tostring(RawEventData.ModifiedProperties[1].NewValue)
| project Timestamp,ReportId,AccountUpn,AccountObjectId,DeviceObjectId,DeviceDisplayName

CIS 8.11: Conduct Audit Log Reviews

Persistence play three: consent to an app that works without credentials#

Service principals, surfaced as Enterprise applications in this scenario, are a favorite for both persistence and privilege elevation. When tenant settings allow it, an attacker on a compromised account grants consent to an application with permissions like reading the user's mailbox and sending mail on their behalf. The critical detail: from that point the attacker operates programmatically, without needing the user's credentials at all. The service principal becomes the identity of record. The two most common apps seen in these compromises:

• eM Client
• PerfectData

In many compromises the attacker uses both apps simultaneously. And here is the uncomfortable part: these are legitimate applications from verified publishers, so the Microsoft ecosystem does not treat them as malicious even though their presence in these cases almost always is. Attackers also deploy outright illegitimate apps as part of phishing campaigns:

Protection 1: Turn off user consent in Entra#

Modify the user consent settings in Entra (Applications > Enterprise Applications > Consent and Permissions) to not allow user consent. We specifically do not like the middle option of allowing consent to apps from verified publishers, for exactly the reasons above: eM Client and PerfectData are verified publishers. Users should be coming to you for a review of any app and its permissions.

CIS 6.1: Establish an Access Granting Process

Protection 2: Investigate consent grants#

Microsoft maintains an application consent incident response playbook (opens in new tab) detailing the audit log records available and how to investigate with them.

CIS 8.11: Conduct Audit Log Reviews

Persistence play four: inbox rules that hide the whole operation#

After the initial compromise, attackers typically:

• Delete the evidence of their initial attack from the inbox
• Set up mailbox rules to hide their ongoing presence

Since they can now send from a legitimate address, the next move is often a campaign against other users, internal or external. The supporting inbox rules keep the real user from noticing: automatically archiving or marking as read the replies, non-delivery reports, and auto-generated security notifications the campaign produces.

Protection 1: Route suspicious inbox alerts into your PSA#

Defender for Office 365 Plan 1, included with Business Premium, generates native alerts for suspicious inbox activity:

By default these alerts only reach the tenant admins. Redirect them to your PSA tool via an email connector so they get triaged like the incidents they are.

CIS 13.1: Centralize Security Event Alerting

Protection 2: Block auto-forwarding to external domains#

A long-standing hardening recommendation, configurable in three places:

• The default anti-spam outbound policy (Defender admin center)
• The remote domains policy (Exchange admin center)
• Transport rules

Note that this blocks exfiltration by forwarding, but it does not cover the mark-as-read and move-to-archive evasion tactics, which is why the alerting above matters too.

CIS 4.2: Establish and Maintain a Secure Configuration Process for Network Infrastructure

Where do these baselines come from?#

Every protection above maps to the CIS Controls, and if that framing is useful, there is more where it came from:

1. Free CIS self-assessment mapped to Microsoft 365: get your copy here.
2. CIS to M365 e-book and multi-tenant Power BI template: get your copy here (opens in new tab).
3. Automated M365 assessment mapped to the CIS Controls: CloudCapsule runs against a tenant and automates the pass/fail values of the CIS controls across M365 security recommendations based on the existing configuration.