The alert that taught me the most about social engineering never fired on the message itself. It fired eleven days later, on an Okta login from an anonymizing proxy against a Super Admin account whose multifactor authentication (MFA) had been reset by our own help desk.
The attacker used the phone, impersonated an employee well enough to answer the verification questions, and walked out with a privileged account. Every filter I owned had nothing to inspect, because the attack produced no message artifact at all, no attachment, no link, no spoofed domain to check.
The signals my filters were built to catch, forged headers and malicious payloads, are exactly the signals modern social engineering has learned to stop producing. The attacker arranges the operation so the filter has nothing to score.
In brief:
- Sender authentication validates mail origin only. When the sending account is genuinely compromised or the tenant is legitimately provisioned, Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) all pass, and the message is clean by every signal a signature-based filter reads.
- The evidence moves into identity-plane telemetry and behavioral baselines the email gateway never sees.
- These text-based advanced attacks generate almost no early human signal for the security operations center (SOC), so detection has to be automated and behavioral.
- Identity-layer correlation would have caught these earlier, and relationship baselines and earlier kill-chain signals extend that coverage.
What "getting past filters" actually means in the queue
A filter blocks malicious email by inspecting sender authentication and reputation before scanning the payload. The attacks that reach my analysts have already satisfied every one of those checks honestly. By the time a message reaches the queue, those controls have done their simple part.
A filter catches a specific behavioral signal: a forged header, a domain with no history, a URL resolving to known-bad infrastructure, or an attachment that detonates in the sandbox. Social engineering that gets through avoids producing that signal, usually by borrowing something legitimate. The evidence still exists; it has just moved off the surface the filter watches and onto one most SOCs aren't correlating.
The patterns move evidence off the email surface
Four patterns account for most of what I've pulled out of the queue in the last two years. Each one moves the exploit off the technical layer, where authentication has visibility, and onto the trust layer, where it has none.
Legitimacy borrowing that rides trusted infrastructure
The strongest version sends phishing from the target's own trusted providers, so authentication passes because it should. When an attacker abuses a cloud provider's own email-sending or workflow-automation feature, the mail ships from the provider's infrastructure, and SPF, DKIM, and DMARC pass because it came from infrastructure the authentication layer was built to trust, with no forged header to find.
Device code phishing applies the same logic to Open Authorization (OAuth). The victim authenticates on the real login.microsoftonline.com page, so the event happens on Microsoft's own infrastructure. There's no malicious link to catch. The evidence lands on the identity plane, in the consent grant and the token issued to an attacker-registered app, outside the gateway.
Conversational priming that lands before the payload
Some attackers send a clean first message on purpose. The opener carries no link, no attachment, no urgency, no known-bad sender. Its only job is to prompt a human response and bank a trusted-sender relationship before any payload exists. The filter passes it, because at that stage there is nothing malicious to find. The malicious request arrives later, inside a conversation the filter already blessed.
I've watched this play out as a thread that looked normal until the payment instruction landed. The attacker used a one-character lookalike domain and pasted prior text to pass as a follow-up, so legacy tools had no history to flag. The queue shows little human signal until an identity-plane event, a payment approval or a new inbox rule, ties back to the priming conversation.
Help-desk impersonation that routes around the review step
This pattern targets the IT service desk's identity check. SCATTERED SPIDER operators call the help desk, impersonate an employee, and request an MFA reset for a privileged account, answering the verification questions well enough. In the MGM Resorts case, they reached Super Admin in Okta and registered a second inbound-federation identity provider to impersonate any user.
Fast access handoffs can outrun analyst review cycles, with operators moving from initial access to ransomware in less than a day, and voice phishing rose sharply during 2024 alongside a broader shift toward malware-free activity.
This class leaves evidence in an MFA factor reset on a Super Admin account, followed by a login from a new device via anonymizing proxy, one never associated with the account. That was the alert that fired on my incident, eleven days too late because nobody correlated the help-desk ticket to the login.
Relationship impersonation that authenticates cleanly
DMARC reject stops an attacker from spoofing your domain, but compromised accounts and attacker-owned tenants still authenticate cleanly. Much of the business email compromise (BEC) that reaches my queue uses vendor or business-partner impersonation, and it passes authentication because the sending account is real.
One pattern asks accounts payable to confirm a tiny Automated Clearing House (ACH) test deposit; the message passed SPF, DKIM, and DMARC because it rode a long-established vendor domain through a compromised account. The only anomaly was the unusual amount, which authentication never inspects.
Verizon's 2025 breach data puts pretexting second among social engineering actions at 30 percent, behind phishing, most often as business email compromise. A first-time sender to a payment-sensitive mailbox should be scored against reply-to behavior, and fabricated thread bodies show up when quoted history has no matching message-IDs. Neither is an authentication signal.
Why these patterns share the same bypass logic
Strip the channels away and every one of these is T1204, User Execution, or its identity-plane equivalent. The attacker relies on a human or a genuinely-authenticated account, the one path no signature covers. MITRE's phishing mitigations are just SPF/DKIM/DMARC and user training. No purely technical control covers the class, which is why no configuration change stops it.
Authentication has no visibility into intent. Thread hijacking passes DKIM because the account really is the vendor's, and device code phishing produces no malicious URL because the victim logs in on the genuine page. Help-desk vishing generates no email at all, while an attacker-controlled Microsoft 365 (M365) tenant passes SPF and DMARC because it's legitimately provisioned.
The exploit moved onto the trust and process layer the filter can't see. Stolen credentials rising to the second most common initial access vector at 16% is the same story from the initial-access side. Adversaries use valid access as the way in.
The real detection surface is identity and behavior
Identity and behavior changes would have flagged every pattern above earlier, if the events were correlated with recent process activity instead of scored in isolation. The MFA fatigue case that nearly beat us got through because the detection rule only counted failures, while the attacker's pattern was a wave of denials ending in a single success from the same IP.
Watch the post-reset sequence. An MFA reset cancels a user's factor enrollments, so a password reset followed by a new factor or device enrollment is suspicious, and help-desk vishing surfaces here without a message to inspect. The correlation window has to be measured in minutes, because fast handoffs can finish before a standard security information and event management (SIEM) review cycle runs.
Run relationship-graph and communication baselines alongside authentication checks on inbound mail. The observables that catch vendor email compromise (VEC), a first-time sender to a payment mailbox or a reply-to lookalike mismatch, are behavioral gaps authentication never reads. Behavioral profiling has a real cost, since it generates false positives on new vendor mail.
Build detection engineering around earlier kill-chain signals, which is what the SANS survey called for after finding that false positives remain the leading operational burden and postures stay endpoint-heavy. Pre-click domain-behavior analysis is the sharpest example. It can identify malicious infrastructure before any user engages, so it catches the lookalike domain before the priming conversation lands.
Frequently asked questions about social engineering
These answers connect social engineering to the adjacent telemetry that records persuasion working before any gateway artifact exists, the evidence an analyst needs before the request becomes a payment or a token grant.
How should a SOC define social engineering in investigations?
Social engineering manipulates a person, or a genuinely-authenticated account, into an action that gives an attacker access, not technical exploitation of a vulnerability. In practitioner terms, it produces no artifact for a filter to inspect, no forged header, no bad payload, often no spoofed domain. It sits behind the human element in 60% of breaches in the 2025 Verizon DBIR.
How do social engineering attacks get past email filters?
They get through by omitting the signals the filter scores. Attackers send from compromised legitimate accounts or their own legitimately-provisioned tenants, so SPF, DKIM, and DMARC pass honestly, and they omit malicious links and attachments so there's nothing to sandbox. Some route entirely off email, through help-desk phone calls or OAuth device code flows on real login pages. The gateway has no artifact to catch.
What does social engineering look like in SOC telemetry?
It shows up off the email surface, on the identity plane and the endpoint. Watch for an MFA factor reset followed by a login from a new device or anonymizing proxy, a burst of push denials ending in one approval from the same IP, inbox rules created right after a login from odd geography, and a domain with no thread history hitting a payment-sensitive mailbox. Almost none of these get reported, so the signal is almost entirely machine-generated.
What detection controls actually catch social engineering before the click?
Pre-click domain-behavior analysis flags bad domains, the earliest control. Identity-plane correlation in minute-scale windows catches help-desk vishing and MFA abuse. Relationship-graph baselines cover vendor impersonation that authenticates cleanly. In the incidents I care about, what mattered was linking the message or help-desk action to the next identity event.