Incident Report: LLM-Assisted Intrusion at a Mid-Market Financial Firm

Incident Classification: Confirmed | Incident Type: Illustrative | Severity: Critical | Sector: Financial Services | Date Confirmed: May 2026

What Happened

A mid-market wealth management firm (roughly 280 employees) sustained a multi-stage intrusion spanning late Q4 2025 and early Q1 2026. The attacker used LLM-generated spear phishing, AI-assisted credential validation, and scripted internal reconnaissance to reach the firm’s client portfolio systems and extract approximately 4,200 client records. Detection took 23 days.

The firm has authorised publication of a technical summary. All identifying details have been anonymised or altered.

---

Timeline

Date (relative)	Event
Day 0	Initial phishing emails delivered
Day 0	First credential compromise
Day 3	Lateral movement begins
Day 7	Access to portfolio management system achieved
Day 14	Exfiltration commences
Day 21	Anomalous export activity flagged by DLP
Day 23	Incident confirmed, containment initiated
Day 24	External IR firm engaged
Day 31	Full containment achieved
Day 45	Regulatory notification submitted

---

Stage 1: Getting In

The Phishing Campaign

Six people on the firm’s client services team received targeted emails. Each one was personalised: correct name, role, manager’s name, a reference to a fund launch that had been announced in a press release three weeks earlier, and impersonation of a contact at an existing custodian relationship. The writing style matched the impersonated sender’s communications drawn from LinkedIn posts and conference recordings.

Post-incident analysis concluded these were LLM-generated. The tells: zero grammar or spelling errors, a level of personalisation consistency across all six targets that would take a human attacker considerably longer to produce, and prose style that matched the impersonated contact more accurately than manual research typically achieves.

The Credential Harvest

Each email linked to a document on a lookalike domain registered 18 days before the campaign. Clicking the link in the “updated mandate confirmation” PDF redirected through a transparent proxy to a cloned M365 login page. Credentials harvested in real time (an adversary-in-the-middle phishing kit).

Two of the six targets entered credentials. One had MFA enforced; the session couldn’t be established. The second target, a senior client associate, had no MFA on her account. An exception granted eight months earlier during a system migration. Never remediated.

Initial access: Day 0.

---

Stage 2: Mapping the Environment

With the compromised account, the attacker moved quickly. They read the directory, shared drives, and email history to identify high-value targets and administrators. They queried the M365 admin portal (accessible to the compromised account’s role) to find other accounts without MFA. And they searched the mailbox for credentials sent by email. Found one: a VPN credential in a 14-month-old onboarding thread.

Access logs showed 847 API calls to the M365 Graph API over 40 minutes. Not manual browsing. A scripted enumeration tool.

---

Stage 3: Lateral Movement

The VPN credential from the onboarding email worked. The attacker established a VPN session from a residential proxy in the same country, bypassing geo-block controls. Session started outside business hours.

From there:

• Connected to the internal portfolio management system using the compromised associate’s credentials (reused from M365)
• Authenticated successfully (the portfolio system ran a legacy auth mechanism without MFA support)
• Escalated via a misconfigured service account with read access to all client portfolios, not just the associate’s book

Lateral movement complete: Day 3.

---

Stage 4: Persistence and Exfiltration

Two persistence mechanisms. A forwarding rule on the compromised M365 account, named _archive, copying all inbound mail to an external address. And a scheduled task on an internal server (accessed via the service account) running a nightly data export script.

The export script queried the portfolio management system’s database directly:

• Client name, date of birth, NI number
• Account valuations and portfolio composition
• Contact details and relationship notes

4,200 records over seven nights. Data staged to a cloud storage endpoint via HTTPS, traffic blending with normal business activity on the same cloud provider.

---

Stage 5: How Detection Finally Happened

On Day 21, the DLP solution flagged unusually high export volumes from the portfolio management system via the service account. The alert was correct. It was triaged as low priority: the service account was used for legitimate reporting tasks, and the alert gave the analyst no context on how much data that account could access.

Day 23: the compromised associate reported a password reset notification she hadn’t initiated. IT helpdesk escalated to security. They correlated it with the open DLP alert. Four hours later, the team confirmed the forwarding rule, identified the VPN sessions, and initiated containment.

Detection gap: 23 days.

---

Root Causes

Root Cause	Contributing Factor
Missing MFA on compromised account	Migration exception never remediated
Password reuse between M365 and portfolio system	No enforcement of unique passwords for business systems
Service account over-permission	No least-privilege review in 18 months
DLP alert deprioritised	Insufficient analyst context; alert lacked asset criticality tagging
Slow detection of forwarding rule	No alerting on external mail forwarding rule creation

---

What Should Have Caught This Earlier

MFA exceptions need hard expiry dates

The migration exception had no automated expiry. It sat open for eight months. Every MFA exception should have a maximum duration with automated re-enrolment enforcement at expiry. Not a calendar reminder. Automated. Otherwise exceptions become permanent.

847 Graph API calls in 40 minutes should fire an alert

This is not human behaviour. SIEM rules for M365 typically focus on login anomalies. Post-authentication API enumeration (the phase where an attacker maps your environment after they’re already in) is less well covered. Build detection for it. The threshold doesn’t have to be perfect; 500 calls in 30 minutes from a user account is a reasonable starting point.

External mail forwarding rule creation is a high-fidelity indicator

A non-administrator creating an external forwarding rule on a corporate mailbox is one of the most reliable indicators of account compromise that exists. This should generate an immediate, high-priority alert to the security team. Not something discovered during post-incident review.

DLP alerts need to carry asset criticality context

The DLP alert was technically accurate. What it was missing: any indication that the exporting service account had access to the entire client book, not a subset of records. An alert that says “unusual export volume from service account X” is far less actionable than one that says “unusual export volume from service account X, which has read access to 80,000 client records.” That second version gets treated differently by an analyst working a queue.

VPN sessions need more than a geo-check

The residential proxy passed geo-block controls because the source country matched. Device posture checking (is this a known managed device?) and continuous authentication for VPN sessions would have surfaced an unknown device connecting from a residential proxy outside business hours. Geo-blocking alone is a weak control against attackers who can trivially select a same-country exit node.

---

Indicators of Compromise

Email infrastructure:

• Lookalike domain registered ~18 days before campaign
• AiTM phishing kit infrastructure (Evilginx-class)

M365 activity:

• 500 Graph API calls in a 30-minute window from a user account

• External mail forwarding rule creation by non-admin
• Off-hours access from IP addresses not in the user’s normal geolocation cluster

Network:

• Residential proxy IPs for VPN authentication
• Nightly HTTPS uploads to cloud storage outside business hours from a server process

Host:

• Scheduled task creation on an internal server by a service account
• Database export queries with no corresponding business application session

References

• MITRE ATT&CK: Spear Phishing and Credential Theft Techniques
• MITRE ATLAS: LLM-Assisted Attack Techniques
• CISA: Artificial Intelligence
• Microsoft Security Blog: Identity and Access Threats