Common warning signs include unusual login behaviour, out-of-hours data movement, abnormal LDAP query volumes, new privileged accounts, suspicious internal traffic, and employees receiving urgent requests that bypass normal process. Another signal is slow exfiltration that blends into ordinary traffic, especially when activity appears legitimate on the surface but does not fit the user’s normal pattern.
Why This Matters for Security Teams
A social engineering campaign that is actively progressing rarely looks like a single dramatic event. It usually appears as a sequence of small, explainable anomalies that only make sense when seen together: atypical authentication patterns, unusual internal requests, and movement toward higher-value systems. The practical risk is not just credential theft, it is that the attacker is using legitimate people and processes to build trust, expand access, and reduce the chance of immediate detection.
Teams often miss the early phase because each signal, taken alone, looks mundane. One user approves an unexpected prompt, one helpdesk ticket seems urgent, or one internal login happens from an unusual context. The challenge is to recognise the campaign as an evolving chain rather than a collection of isolated events. For a useful external benchmark on how quickly attacker activity can accelerate once credentials are exposed, see Anthropic’s report on the first AI-orchestrated cyber espionage campaign. In practice, many security teams discover the campaign only after internal access already looks routine on the surface.
How It Works in Practice
A progressing social engineering campaign typically advances through reconnaissance, trust-building, access acquisition, and then internal movement. The early signs often appear in identity, helpdesk, collaboration, and network activity before any obvious data theft. What matters is the combination and timing of events, not just the presence of one suspicious action.
Common indicators include:
- Repeated logins from new devices, impossible travel patterns, or unusual session timing.
- Helpdesk interactions that pressure staff to bypass verification or reset controls.
- New internal relationships forming quickly, especially around finance, IT, or admin functions.
- Privilege changes that do not match the user’s normal role or ticket history.
- Internal traffic that expands across LDAP, file shares, mail, or cloud administration tools.
- Slow, low-volume data movement that blends into ordinary business activity.
When those signals line up, the campaign is often trying to convert one foothold into durable access. That can include credential harvesting, MFA fatigue abuse, impersonation of trusted staff, or the creation of new paths that look legitimate to monitoring tools. The strongest response is usually correlation across identity, endpoint, mail, and network telemetry rather than waiting for a single high-confidence alert. For a concrete example of how social engineering can turn into full tenant access, see MGM Resorts Breach 2023 – Scattered Spider and Uber Breach. These controls tend to break down when the attacker first gains a trusted internal identity and then uses normal tooling to avoid looking exceptional.
Common Variations and Edge Cases
Tighter authentication and approval workflows often slow both attackers and staff, so organisations have to balance verification friction against operational speed. That tradeoff becomes harder in high-volume support environments, merger integrations, and globally distributed teams where legitimate exceptions happen often.
Some campaigns are noisy and obvious, but the more dangerous ones are patient. They may use:
- Long dwell times before privilege escalation.
- Short bursts of activity that mimic business hours in another region.
- Credential use that stays within expected tools while shifting to unexpected data targets.
- Requests that look plausible individually but are suspicious as a sequence.
A common edge case is insider-assisted activity, where the behaviour may not look like classic external phishing but still reflects manipulation or coercion. Another is partial compromise, where only one account is touched and the rest of the campaign is still in preparation. Current guidance suggests treating these as stages of the same incident when the same actor, request pattern, or access path keeps reappearing. If the organisation relies on manual review alone, it will usually see the campaign too late to stop lateral movement or quiet exfiltration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Active social engineering shows up first in monitoring signals. |
| PR.AC — Access Control | Campaign progression often depends on abusing legitimate access paths. | |
| Recommendation — Correlate identity, mail, endpoint, and network telemetry for multi-signal campaign detection. Tighten and review access paths that let a social attack become internal movement. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers commonly progress by reusing or stealing legitimate accounts. |
| T1566 — Phishing | Social engineering campaigns often begin with deceptive contact or lure delivery. | |
| Recommendation — Hunt for legitimate-account use that does not fit normal device, time, or location patterns. Track phishing delivery, follow-on credential capture, and downstream access attempts. | ||
| CIS Controls v8 | 8 — Audit Log Management | Progressing campaigns leave traceable anomalies across logs and sessions. |
| Recommendation — Centralise and review logs that reveal unusual authentication, privilege, and data-movement patterns. | ||
Practitioner Guidance
What to prioritise: Correlate identity anomalies, helpdesk events, internal messaging, and data-transfer patterns as one campaign hypothesis. A single suspicious login is useful; a suspicious login plus a privilege change and an urgent support request is materially stronger evidence.
What to verify: Confirm whether the account owner, device, location, and request history fit the observed activity. Pay special attention to approval paths that were bypassed, not just to the access event itself.
Decision rule: If activity starts to move from social contact into privileged access or data access, treat it as an active intrusion path and escalate for containment rather than waiting for exfiltration proof.
Common mistake: Teams often separate “phishing”, “identity misuse”, and “internal suspicious traffic” into different queues. That segmentation helps the attacker, because the campaign is designed to look like unrelated noise until it is already embedded.
Practitioner takeaway: The key judgment is whether the organisation is seeing isolated anomalies or a coordinated trust abuse sequence, because only the second pattern justifies treating the activity as an active campaign.
