Incident Report: LLM-Assisted Intrusion at a Mid-Market Financial Firm • AI Security Wire

Executive Summary

A mid-market wealth management firm with approximately 280 employees sustained a multi-stage intrusion between late Q4 2025 and early Q1 2026. The threat actor used LLM-generated spear phishing lures, AI-assisted credential stuffing, and automated internal reconnaissance to achieve persistent access to client portfolio systems and exfiltrate approximately 4,200 client records before detection.

Total business impact included regulatory notification obligations, client remediation costs, and reputational damage. The firm has authorised publication of a technical summary to support industry awareness. All identifying details have been anonymised or altered.

Note: This report is a synthetic composite based on documented attack patterns observed across multiple real incidents. It does not represent a single verified event.

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: Initial Access via LLM-Generated Spear Phishing

Delivery

The attacker sent targeted phishing emails to six members of the firm’s client services team. Each email was individualised:

Correct recipient name, role, and direct manager’s name
References to a recent firm announcement (a new fund launch publicised in a press release three weeks prior)
Impersonation of a named contact at an existing custodian relationship
Writing style closely matching the impersonated contact’s previous correspondence (sourced from LinkedIn posts and industry conference recordings)

Post-incident analysis assessed the emails as LLM-generated based on their structural characteristics: no spelling or grammar errors, unusual consistency of personalisation across six different targets, and prose style that matched the impersonated sender more closely than human attackers typically achieve without extended study.

Payload

The emails contained a link to a document hosted on a lookalike domain (registered 18 days prior). The document was a plausible-looking “updated mandate confirmation” PDF. Clicking the embedded link redirected through a transparent proxy to a cloned Microsoft 365 login page that harvested credentials in real time (adversary-in-the-middle phishing kit).

Two of six targets entered credentials. One had MFA enforced; her credential was captured but the session could not be established. The second target, a senior client associate, did not have MFA on her account — an exception granted eight months prior during a system migration that was never remediated.

Initial access achieved: Day 0.

Stage 2: Credential Validation and Enumeration

The attacker used the compromised account to:

Map the organisational structure — reading the directory, shared drives, and email history to identify high-value targets and system administrators
Identify unprotected accounts — querying the M365 admin portal (accessible to the compromised account’s role) to find other accounts without MFA
Harvest credentials from email — searching the mailbox for password reset emails, IT support threads, and any credentials sent via email (found: one VPN account credential in a 14-month-old onboarding email thread)

This reconnaissance phase appeared automated: access logs showed the compromised account making 847 API calls to the M365 Graph API over 40 minutes — a pattern consistent with a scripted enumeration tool rather than manual browsing.

Stage 3: Lateral Movement

Using the VPN credential found in email, the attacker established a VPN session from a residential proxy IP address in the same country. This bypassed geo-block controls. The VPN session was established outside business hours.

From the VPN session:

Connected to the internal portfolio management system using the compromised client associate’s credentials (reused from M365)
Authenticated successfully — password reuse was widespread, and the portfolio system used a legacy authentication mechanism without MFA support
Escalated access by exploiting a misconfigured service account with excessive permissions (read access to all client portfolios, not just the associate’s assigned book)

Lateral movement complete: Day 3.

Stage 4: Persistence and Exfiltration

The attacker established persistence via:

A forwarding rule on the compromised M365 account sending copies of all inbound mail to an external address (rule named _archive to avoid detection)
A scheduled task on an internal server (accessed via the service account) that ran a data export script nightly

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

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

Approximately 4,200 records were exfiltrated over seven nights before detection. Data was staged to a cloud storage endpoint via HTTPS; the traffic blended with normal business use of the same cloud provider.

Stage 5: Detection

On Day 21, the firm’s DLP solution flagged an unusual volume of exports from the portfolio management system originating from the service account. The alert was generated correctly but was triaged as low priority by the SOC analyst on duty, who noted the service account was used for legitimate reporting tasks.

On Day 23, the client associate whose account was compromised reported receiving a password reset notification she had not initiated. The IT helpdesk escalated this to the security team, who correlated it with the open DLP alert. Within four hours, 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

Defensive Failures and Lessons

MFA exceptions require expiry dates

The migration exception that left the target account without MFA had no automated expiry. Organisations should enforce a maximum duration on all MFA exceptions, with automated re-enrolment enforcement at expiry.

Alert on M365 Graph API enumeration

847 Graph API calls in 40 minutes from a user account is not normal human behaviour. This pattern should trigger an automatic alert. Many SIEM rules for M365 focus on login anomalies but do not cover post-authentication API enumeration.

External mail forwarding rules are high-signal indicators

Creation of an external email forwarding rule by a non-administrator is a high-fidelity indicator of compromise. This should alert immediately to the security team, not be discoverable only during post-incident review.

DLP alerts need asset criticality context

The DLP alert was technically correct but lacked context that would have indicated urgency: the exporting account (the service account) had access to the entire client book, not a subset. Enriching DLP alerts with the scope of the exporting identity’s access would have elevated the priority.

VPN access should be MFA-gated separately from device posture

The attacker’s VPN session from a residential proxy passed geo-block controls because the source country matched. Device posture checking and continuous authentication for VPN sessions would have detected the unknown device.

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