Identity weaknesses played a material role in almost 90% of the 750-plus incidents Palo Alto Networks’ Unit 42 investigated in 2025, with 65% of initial access driven by identity-based attacks. This was not solely because those organizations lacked multi-factor authentication (MFA) or security training. Rather, attackers targeted gaps between those controls, including the help desk, initial MFA enrollment, and account recovery workflows. Many security architectures treat these identity interactions as low-risk events. Attackers understand this and target these weaker points instead of more heavily defended access paths.

Closing these gaps requires a model that evaluates identity signals across every high-risk interaction and adjusts verification depth in real time. This blog examines the social engineering tactics affecting enterprises today and presents a defensive playbook grounded in identity threat detection.

Four social engineering tactics reshaping the enterprise threat environment

Social engineering attacks exploit trust in identity systems and human workflows. Four of the most common tactics reported across incidents include:

Help desk impersonation and credential reset fraud

Scattered Spider (UNC3944/Muddled Libra) made this tactic famous, but the technique has proliferated well beyond one group. According to a joint Federal Bureau of Investigation (FBI) and Cybersecurity and Infrastructure Security Agency (CISA) advisory updated in late July 2025, threat actors call IT service desks, impersonate employees, request password resets and MFA token transfers, and gain access to single sign-on environments. Unit 42’s 2026 Global Incident Response Report documented a case where Scattered Spider social-engineered a help desk to access a privileged access manager, retrieved stored credentials, and compromised a domain-privileged account within 40 minutes. From there, they breached a password vault and escalated into the client’s cloud environment.

The tactic works because help desks verify callers using static personal identity data that attackers can obtain from breached databases.

Voice phishing

Vishing is increasingly overtaking email phishing as a primary social engineering vector. Mandiant’s M-Trends 2026 Report found that voice phishing accounted for 11% of all initial breach vectors, while email phishing fell to 6%. In cloud-specific compromises, vishing reached 23%. The CrowdStrike 2025 Global Threat Report recorded a 442% increase in vishing incidents.

In a Singapore case in early 2025, attackers cloned a finance manager’s voice and directed employees to transfer HK$18.5 million. According to Cyble’s Analysis, deepfake-as-a-service platforms became widely accessible throughout 2025, removing the skill barrier that had previously limited these attacks to sophisticated threat actors.

What makes deepfake vishing different from traditional vishing is that the caller sounds exactly like someone the target knows. The psychological defense of “that doesn’t sound like my CFO” disappears.

Adversary-in-the-middle session hijacking

Phishing-resistant MFA can thwart credential theft, but it does not stop session theft. The Microsoft Security Research Team documented a multi-stage AiTM campaign in January 2026 targeting the energy sector. Attackers used SharePoint links to phish credentials through a proxy that captured session cookies in transit. Once they obtained the session token, they created malicious inbox rules and compromised business email accounts. Resetting the user’s password did not remediate the breach. The session cookies had to be revoked, and the malicious inbox rules had to be removed.

AiTM attacks exploit a specific blind spot: Most organizations treat authentication as a one-time gate. Once a session is established, the session token carries full trust. Attackers who intercept that token inherit that trust without ever needing the credential again.

Collaboration platform abuse

The shift to hybrid work turned Teams, Slack, and Zoom into attack surfaces. The Microsoft DART Team documented a March 2026 case in which an attacker impersonated IT support through Teams, initiated a live conversation, and convinced a user to grant remote access via Quick Assist. Rapid7’s Q1 2025 Incident Response Report identified Teams as a common social engineering vector, with attackers posing as IT staff and tricking users into installing remote access tools. Reuters reported in June 2025 that UNC6040, which is a threat actor with close ties to the ShinyHunters hacking group, used voice phishing to convince employees to install a modified Salesforce Data Loader application, then exfiltrated data from more than 20 organizations.

These platforms are designed for speed and trust. Social engineering attacks exploit that design philosophy. A message from “IT Support” in a company messaging platform often feels safer than an email containing a suspicious link.

The identity threat detection playbook

If training reduces but cannot eliminate human error, and MFA protects the authentication screen but not the processes surrounding it, then an effective defense must operate at the identity layer itself. It must evaluate identity risk signals during every high-risk interaction and make a risk-informed decision before the transaction proceeds. That is the operating principle behind the playbook that follows.

Correlate independent identity risk signals per interaction

A help desk password reset verified by a single factor, such as knowledge of the employee’s last four SSN digits, represents the exact failure mode that Scattered Spider exploits. The countermeasure is to evaluate multiple independent risk signals before processing any high-risk identity action.

That means checking the caller’s phone number against telecom carrier data for recent SIM swaps or porting events. It also means evaluating device and session metadata against historical patterns. Is this a recognized device, or a new one routing through a flagged IP address? It also requires matching user-supplied PII against authoritative identity data sources such as credit bureaus and government records.

No single risk signal produces a definitive verdict. A recently ported number might be legitimate. A recently ported number originating from an unrecognized device and showing a geolocation mismatch presents a very different risk profile. The detection power comes from correlation.

Adjust verification depth based on real-time risk

Not every identity interaction warrants the same verification burden. A login from a recognized device, a known IP address, and stable phone carrier data should proceed with minimal friction. A password reset from an unfamiliar device routed through a proxy network, combined with a phone number that was ported 36 hours earlier, should trigger a higher-assurance challenge such as document verification, biometric liveness detection, or a knowledge-based question drawn from credit or employment history.

The decisions governing which challenge to present, and at what threshold, should be policy configurable. Teams evaluating these capabilities should ask: How quickly can we add a new risk signal source or adjust a decisioning threshold?

Design for signal-source failure

Any architecture that relies on external authoritative identity data sources depends on their resilience. If a telecom API goes down or a fraud consortium feed returns errors, the verification process may fail open, creating security risk, or fail closed, blocking legitimate users. Neither outcome is acceptable at scale.

Robust identity defenses require automated failover. If one document verification data sources times out, the system should route requests to a backup. If a primary carrier data source returns an error, a secondary data source should be queried automatically. Attackers who discover that a specific data source outage weakens verification controls will time their attacks accordingly. Redundancy across authoritative identity data sources is a design requirement for any identity threat detection system.

How ID Dataweb enables this playbook

ID Dataweb is an identity threat detection and risk mitigation platform. Rather than replacing existing IAM or fraud systems, it augments them by correlating risk signals and applying consistent decisioning logic across applications.

Signal correlation across independent data sources

During a password reset, MFA enrollment change, or account recovery workflow, ID Dataweb evaluates risk signals from telecom carriers, credit bureaus, government databases, device fingerprinting services, and fraud consortiums through a single integration point. For each transaction, it evaluates:

  • Phone intelligence: Number age, SIM swap recency, port history, and carrier alignment with the user’s profile.
  • Device and session risk: Device reputation, IP risk scoring, geolocation consistency, and indicators such as TOR usage, bot signatures, and proxy routing.
  • Identity verification: PII matching against authoritative records to detect synthetic or stolen identities.

Adaptive step-up decisioning

The ID Dataweb platform applies rules that security teams can configure without code changes:

  • Low-risk interactions can proceed with no additional friction.
  • Medium-risk interactions trigger phone possession verification, biometric validation, or a dynamic knowledge-based challenge drawn from credit or employment history.
  • High-risk interactions escalate to government-issued document verification combined with biometric liveness detection.

Automated failover across data sources

The ID Dataweb architecture provides automated backup routing across its authoritative identity data sources. If one document verification data source times out, the system reroutes requests to another data source. If a telecom data source returns an error, a secondary source is queried without user-visible disruption. Verification outcomes do not degrade when a single data source experiences an outage.

Conclusion

The four tactics discussed here target different identity interactions, but they succeed for the same underlying reason. The verification applied at those interaction points does not correlate enough independent risk signals to distinguish attackers from legitimate users. Most organizations affected by these tactics had MFA deployed and security awareness programs in place, yet they lacked risk signal correlation at the identity interactions attackers targeted. A help desk agent checking the last four digits of an SSN cannot detect a SIM swap. An MFA prompt cannot detect that a session token has already been intercepted in transit. The playbook outlined above addresses these gaps by treating every high-risk identity interaction as a signal-correlation problem, adjusting verification depth based on real-time risk, and building failover capabilities that maintain coverage when a data source becomes unavailable.