The MFA Prompt and the Phone Call: Investigating Them Together

An employee reports a call from someone claiming to be IT. Several authentication prompts arrived during the conversation, and the employee thinks they accepted one. A VPN connection appears in the same interval. What can the investigator actually connect?

The phone conversation explains the request the employee heard. Authentication records describe what the provider processed. The VPN records describe the remote-access session. Keep all three records and look for evidence linking them. Do not ask the employee’s recollection to answer questions that need system records.

What the Cisco intrusion shows

Cisco Talos’s August 2022 account of an intrusion into Cisco describes credentials stolen through a compromised personal account before voice phishing and repeated MFA push attempts. Cisco reported that an accepted push enabled VPN access in the targeted user’s context. The report also describes later enrollment of additional MFA devices. Cisco Talos: initial vector

Those observations suggest three separate investigative questions: who initiated the authentication attempt, what the employee authorized, and what access followed. Later device enrollment is a fourth question when relevant records justify examining it. Use Cisco’s sequence to guide the investigation, but do not fill gaps in your own timeline with events from that report.

This article begins after an employee reports the interaction. For the employee-facing decision, use IT asked for an MFA code. Here, the analyst’s task is to connect the report to a particular authentication attempt and a particular session.

Ask what happened without supplying the answer

Record the approximate call interval, the account involved, the requested action, and what the employee remembers doing. Ask whether the screen showed a code, an approval button, a number to match, or another instruction. Keep uncertainty in the record: “I think I tapped approve” differs from “I saw a success message.”

Do not ask for the actual sign-in code or a reusable session secret. Preserve the original report and use the organization’s approved process for call metadata or recordings when available. An employee’s description of the caller’s name is a reported claim, not verified identity. A displayed phone number can help locate a call record; it should not become the entire attribution argument.

Ask whether the employee had an intended sign-in in progress. A legitimate attempt can occur during the same interval as an unwanted one. That is why a row saying “MFA succeeded at 10:04” is not enough to determine which prompt the employee approved.

Work with an incomplete packet first

This fictional investigation uses simplified record labels and UTC timestamps. It concerns a dedicated account, test VPN and training page.

The initial finding can say that the reported call overlapped two authentication outcomes and a VPN session. It cannot yet say attempt B created session S or that the caller operated that session.

Link the authentication attempt to the VPN session

Ask the identity and VPN owners how their systems represent one authentication transaction and the resulting session. Use the identifiers actually retained by those systems. When a common transaction reference is unavailable, identify the other corroboration and the remaining uncertainty. The available references depend on the provider and retained logs.

Our sign-in evidence guide explains the distinction between account, client, and resource. That distinction matters here too: an account can be the same while the target application or attempt is different. Preserve the source timestamp and timezone before normalizing the case. If clocks are offset, retain the offset and the method used to establish it.

Now the fictional VPN owner supplies V-2, a session-establishment record explicitly referencing attempt B and session S. That links authentication attempt B to VPN session S. It still does not identify who controlled the endpoint that created S.

The exercise controller supplies C-1 next: the approved test endpoint initiated B and owns S. This fact comes from the controlled exercise, not from guessing that an unfamiliar address must belong to an attacker. In an actual incident, the equivalent attribution may remain unresolved until device, network, or other evidence is available.

A VPN session is not a completed data read

The test endpoint’s session is now established. The application owner supplies R-2: a fresh request associated with S returned the harmless training marker at 10:06. That supports one read in the exercise. It does not establish access to every application reachable through the VPN.

Change the case: suppose the request was denied. Preserve that denial alongside the successful VPN connection. The remote-access decision and application authorization produced different results. The application owner should identify the denial reason before the team attributes it to a particular control.

If the response contains only a screenshot of a page already open in a browser, request evidence of a fresh protected operation. Our session-phishing investigation explains why displayed content and current access can diverge.

Check newly enrolled MFA methods separately

If the packet includes a newly enrolled authentication method, preserve its creation time, target account, administrative or self-service context, and any evidence identifying its controller. A new method is an event to investigate; its presence alone does not establish that the caller owns it.

The Cisco report gives a reason to check for method enrollment. Establish it from the local method inventory and change records before adding it to the incident timeline.

The response owner should coordinate any approved account, method, or session actions through the incident process. Use the identity containment review to keep those objects separate. Closing a support ticket or removing an unexpected method is not a substitute for checking the specific access path under review.

Finish with a join ledger

The fictional join ledger preserves both the initial uncertainty and the later evidence. Replace its exercise rows when applying the method to a real case.

A final case statement should identify its basis: “H-1 reports the call and requested approval. V-2 links accepted attempt B to session S; C-1 identifies the test endpoint controlling that session. R-2 establishes one training-page read. The packet does not establish which prompt the employee accepted or whether the call caused that decision. Other resource activity and method enrollment were not tested.”

For a retest, select the demonstrated weakness. If an employee could not verify the caller, test the independent support route. If the authentication-to-session reference was absent from the analyst’s export, retest the collection and handoff. If the protected request was denied as intended, retain that working control in the report. Each result belongs to its own question.