The Part of the Attack Your Identity Logs Don’t Explain

Microsoft’s September 9 research describes identity-focused social engineering that begins on personal phone numbers. Employees may be contacted by SMS or phone by someone claiming to be IT and told that a passkey, MFA or SSO configuration needs attention. The resulting cloud activity can become visible across sign-ins, authentication-method changes, Microsoft Graph, SharePoint, OneDrive and Exchange while evidence of the interaction that started it remains thin or absent from enterprise endpoint telemetry. Microsoft says that in many investigations, the employee’s recollection of the call or text becomes the earliest and sometimes the only evidence explaining how the compromise began.

A lot of enterprise programs draw a deliberate boundary around the personal phone. Privacy, legal exposure and employee consent make that understandable. The attack path does not stop at the same boundary. A personal number can still receive an instruction that leads directly into an enterprise identity workflow.

Microsoft’s finding is useful because it shows exactly where the evidence chain can break. The identity platform may retain detailed evidence of the authentication event, the session and everything that follows while the instruction that caused the person to act occurred somewhere the organization was not observing.

A material incident disclosed this week makes the distinction current. Astrana Health said threat actors impersonated company personnel, spoofed the company’s main corporate telephone number and contacted employees in an effort to obtain unauthorized access. Astrana says private or confidential information was accessed or acquired without authorization. Its investigation remains ongoing, so the filing does not establish exactly how each telephone interaction translated into system access.

So I’ll ask it the way I’d ask it across the table:

Signals & Moves You Shouldn’t Ignore

The opening interaction may never reach endpoint telemetry

Microsoft describes calls and SMS messages sent to employees’ personal numbers under the guise of an urgent passkey, MFA or SSO update. The employee can be guided through an adversary-in-the-middle or device-code authentication flow. When the phishing link is opened on a personal mobile device that is not onboarded to Defender for Endpoint, Microsoft says the related activity may be absent from endpoint telemetry.

The important distinction is where the evidence chain begins. An organization can have detailed records of the identity event while having very little evidence of the instruction that caused the employee to act.

Astrana put the telephone channel inside a material incident

Astrana’s September 22 Form 8-K says attackers spoofed its main corporate telephone number while impersonating company personnel and contacting employees. The company reported unauthorized access and said private or confidential information was accessed or acquired.

The filing does not identify the precise authentication mechanism that followed the calls. It does establish that the telephone interaction belonged to an incident the company determined was material.

The phone interaction can therefore be part of the incident even when the enterprise’s strongest telemetry begins later.

A legitimate authentication flow can separate the user’s action from the session requesting access

Microsoft’s September 22 EvilTokens research describes large-scale abuse of device-code authentication. Device-code authentication legitimately allows a user to complete authentication on a device separate from the one requesting access. In a phishing scenario, the attacker initiates the flow and persuades the victim to enter the code on Microsoft’s legitimate authentication page. The victim then authorizes the attacker’s session without handing over the account password.

Microsoft says EvilTokens facilitated campaigns that compromised more than 12,000 inboxes across more than 10,000 organizations worldwide. Affected organizations spanned financial services, healthcare, construction, wholesale distribution, higher education, real estate and other sectors.

The scale is useful context. The architectural lesson is smaller: the authentication can be genuine while the instruction that caused the user to authenticate belongs to another channel, device or owner.

The Control Gap

Most enterprise systems can provide strong evidence about the part of the workflow they own.

The identity platform records authentication, session activity and authentication-method changes. Endpoint tooling records activity on devices inside its management boundary. Help-desk systems retain the support interactions that reach the ticketing process. Other telecom records may exist elsewhere in the chain.

Those records do not automatically become one authorization record.

The gap is evidence continuity between instruction and action.

An authentication log can establish that a factor was satisfied. It does not necessarily establish who instructed the person to satisfy it, whether that instruction was authorized, or whether the person was responding to the workflow the organization intended. Microsoft’s investigations show why that distinction is operational rather than theoretical.

The same problem can appear in recovery, MFA re-registration, help-desk verification and high-consequence approvals. Each control may operate correctly inside its own scope while the enterprise lacks a record connecting the beginning of the decision to the action later accepted by the system.

That is the boundary I would inspect before spending more time arguing about whether the phone belongs in the MDM inventory.

My Take

I spent years in telecom and I cannot remember getting the classic phone call from somebody pretending to be IT and telling me my MFA needed attention. Texts were a different story.

One hit my work number during a transition onto a new team. It used my name informally, the timing made sense, and the message asked me to verify something through a link. It did not read like a scam on first glance. There was enough context around the business for me to think there might actually be a reason somebody was contacting me.

What stopped me was the URL. There were characters in it that I did not expect. I looked again, got my bearings and realized the context that made the message believable was exactly what I should have been questioning.

I do not know what would have happened had I followed the link, because I didn’t. I am not going to turn that memory into evidence of an attack technique I did not investigate. The useful part is that this happened on a work line inside a company that dealt with phone fraud every day, and I still needed a minute to recognize that the instruction itself was suspect.

That is why one part of Microsoft’s research landed differently for me. In many of these investigations, the employee’s memory of the call or text becomes the earliest and sometimes the only evidence explaining how the compromise began.

Picture an incident timeline where the first line reads:

“William remembers getting a message.”

Everything after that can be beautiful. Sign-in logs. Authentication changes. Session activity. Graph calls. Downloads. Microsoft’s investigations show how much richer the telemetry becomes once the activity moves into the cloud environment.

The weakest record can still be the one at the beginning.

There may be call-detail or messaging records elsewhere in the chain. That is different from having the original instruction, its business authorization and the resulting identity event reconciled in the incident record the security team is working from.

I think that is the assumption worth challenging. We put tremendous effort into proving that an authentication event occurred. We should be more careful about treating that event as proof that the instruction which caused it was legitimate.

So I am changing the way I ask about this. I am less interested in whether the phone appears in the managed-device inventory. I want to know what record connects the instruction on the phone to the identity action the enterprise later accepted.

One Thing Worth Doing This Week

Take one completed high-consequence identity event from your environment. Use an MFA re-registration, account recovery, authentication-method change or privileged recovery event.

For that one event, establish three things.

Use actual evidence. Write UNKNOWN where the answer depends on recollection or assumption.

I built the full worksheet so you do not have to turn those questions into a form yourself. It covers the event scope, the initiating instruction, the resulting identity event, reconciliation ownership, evidence continuity and unresolved gaps.

Download the free Phone-Side Evidence Check →

The exercise is complete when another reviewer can identify the instruction evidence, the resulting identity event and the accountable owner without relying on an oral explanation.

Field Notes

There is a sequencing choice behind this week’s exercise.

Mobile Security Guru’s job here is to document the condition and give the security leader a way to prove whether it exists. Turning that finding into a reusable operating method is a different job.

The free worksheet is the first record. Build In-House will carry the same problem forward into the broader Phone-Side Path Register, where multiple approval, recovery, step-up authentication and verification paths can be mapped and maintained rather than examined one event at a time.

That distinction is deliberate. The Friday Brief should establish why the record is needed before a consulting process tries to operationalize it.

The research should still be useful six months from now when this week’s incident has fallen out of the news cycle.

Cleared Today

A standing section on third-party access. Part 2: semiconductors.

The equipment vendor’s engineer can have technical access while work authorization lives somewhere else

The current revision of SEMI E187 introduces cumulative security levels for semiconductor manufacturing equipment. Security Level 1 provides a baseline, while Security Level 2 adds stronger requirements for equipment with higher availability or integrity needs and systems facing greater exposure through external connectivity, including remote vendor support conducted over public networks.

Separate SEMI reporting on fab-data security identifies vendor access as one of the higher-risk exposure points. Vendors may require elevated privileges to maintain, calibrate or troubleshoot equipment, while fabs can face compromised vendor accounts, limited visibility into vendor actions and privileges broader than the work requires.

Those are real technical controls. A separate record answers whether the specific engineer using that access remains authorized to perform the work today.

The vendor account may still be active. The equipment may accept the authentication. The remote-support path may satisfy the technical requirements applied to it. The service window, statement of work, site sponsorship or maintenance authorization may be governed somewhere else.

That state can live with procurement, the equipment owner, vendor management or the person sponsoring the work. Stronger equipment security does not automatically reconcile those systems.

This week’s question: For a vendor engineer with current technical access, what record proves that person is authorized for this equipment, at this site, during this service window?

For your highest-risk authentication-change workflow, what system records the instruction that caused the user to act?

EVERY FRIDAY. SIGNALS. ONE CONTROL GAP. ONE ACTION.

Sources

• Microsoft Security Research. Passkey-themed social engineering leads to identity and cloud compromise. September 9, 2026.
• Astrana Health, Inc. Form 8-K, Item 1.05. September 22, 2026.
• Microsoft Threat Intelligence. Unmasking EvilTokens: Getting to the root of device code phishing. September 22, 2026.
• Microsoft Digital Crimes Unit. Disrupting EvilTokens: The AI Chatbot Built for Cybercrime. September 22, 2026.
• SEMI. Major Revision of SEMI E187: Introducing Tiered Security Levels and Comprehensive Defense Architecture for Fab Equipment. August 2026.
• SEMI. Securing Fab Data: From IP Protection to Vendor Governance.

#MobileSecurity #CISO #IdentitySecurity #MFA #ThirdPartyRisk