Modern ransomware doesn’t just hide in encrypted binaries; it hides in the “Resolved” folder of an IT support queue. Dwell time isn’t just a failure of a firewall—it’s the success of an attacker who understands that Tier 1 technicians are incentivized to restore access, not investigate anomalies.

The Scenario: A Walkthrough of “Guided Persistence”

This walkthrough demonstrates how an attacker can leverage a standard support workflow to turn a “Temporary Foothold” into “Permanent Dominance.”

Step 1: Initial Access & The “Noise”

The attacker gains valid credentials via phishing, credential stuffing, or infostealers. The organization has MFA enabled (push-based). Every login attempt triggers unsolicited MFA prompts to the authorized user. This maps to the following MITRE ATT&CK techniques:

MITRE ATT&CK:
- T1078: Valid Accounts
- T1621: Multi-Factor Authentication Request Generation

Step 2: The User Symptom

The user’s phone is blowing up with MFA prompts they didn’t initiate. They don’t think “I’m under attack”; they think “My app is glitching.” They contact support: “Something’s wrong with my login. I keep getting MFA requests I didn’t ask for.”

Step 3: The Support “Fix” (The Vulnerability)

Tier 1 logic treats this as an access issue to be resolved quickly to meet handle-time metrics. The instruction given is usually: “Let’s reset your account services and re-enroll your MFA device to clear the error state.”

The Reality: The system wasn’t failing—it was successfully resisting unauthorized access. The support workflow removed that resistance. By resetting the authentication state during an active MFA abuse scenario, security friction is removed, context is lost, and the attacker is provided a clean, unmonitored authentication path. Support hasn’t fixed a bug; they have cleared the primary obstacle stopping the adversary.

Step 4: The Pivot to Persistence

The attacker observes the backend reset and immediately reattempts the login. MFA is re-established under “new” conditions, authentication succeeds, and the logs now show “normal” successful behavior from a verified device.

MITRE ATT&CK:
- T1556.006: Modify Authentication Process: Multi-Factor Authentication
- T1098: Account Manipulation

Why the System Fails: Operational Silos

This works because the security signal and the support response never meet. While Identity logs see multiple MFA failures (Coordinated unauthorized access), the Support Desk sees one frustrated user (Active attack signal misinterpreted), and the SOC sees no alert because the signal was “normalized” upstream.

In most environments, the help desk is the actual first incident response layer. When support resolves a symptom without identifying the cause, they are performing accidental anti-forensics. They don’t just “fix” the issue—they erase the evidence of the attack.

Detection & Strategy

To identify this behavior in your environment, security teams should monitor for MFA resets that occur immediately following a burst of failed authentication attempts. A sample Splunk query for this logic might look like this:

index=identity_logs sourcetype=mfa_provider
| streamstats window=5 count as failure_burst by user where result="failure"
| join user [ search index=support_logs activity="MFA_Reset" ]
| where failure_burst > 3
| table _time, user, failure_burst, activity

Rethinking Dwell Time

Dwell time hasn’t disappeared; it has evolved. Modern dwell time isn’t about hiding better—it’s about being repeatedly misinterpreted. We can visualize the problem with this formula:

Dwell Time = Detection Lag + Classification Friction + Escalation Delay

Most organizations focus on Detection Lag. Attackers benefit from Classification Friction (time spent labeling it a “glitch”) and Escalation Delay (time before security is engaged).

The Shift: From Resolution to Investigation

Organizations need to rethink how identity anomalies are handled at the front line. Define the “Security Pivot”: If a user reports unsolicited MFA prompts, that is a Potential Security Incident, not a routine ticket. Integrate ticketing systems with the SIEM to flag risky operations. Finally, empower technicians to ask “Why did this happen?” before asking “How do I get them back in?”

Final Thought

Attackers don’t need perfect stealth; they need legitimate access and a system that explains away early warning signs. We don’t just lose visibility because attackers are invisible; we lose it because the first people who see them are trained to make the “problem” disappear as quickly as possible.