In a stark reminder of the financial devastation Business Email Compromise (BEC) attacks can inflict on healthcare organizations, a former CPA was recently sentenced for laundering $5.3 million stolen from Children's Healthcare of Atlanta. The 2023 attack targeted a vendor of the pediatric healthcare system, exploiting the trust inherent in vendor communications to divert substantial funds to criminal accounts.
For healthcare defenders, this case illustrates a critical reality: BEC is not just a financial fraud problem—it's a security operation that requires technical detection, proactive hunting, and vendor risk management. When attackers compromise vendor email accounts, they gain the ability to manipulate payment instructions, forge invoices, and potentially access sensitive communications that may contain protected health information (PHI). The dual impact of financial loss and potential HIPAA violations makes this a top-tier concern for healthcare security teams.
Technical Analysis
The Children's Healthcare of Atlanta incident represents a classic vendor-focused BEC campaign with the following technical characteristics:
Attack Vector: Vendor email account compromise, likely through credential phishing or password spraying attacks targeting the vendor's Microsoft 365 or Google Workspace environment.
Persistence Mechanism: Attackers typically establish persistence through:
- Email forwarding rules to external accounts (monitoring for payment communications)
- Inbox rules to hide or mark legitimate payment emails as read
- OAuth token theft maintaining access even after password resets
- Added mailbox delegates for continued access
Attack Chain:
- Initial access to vendor email account
- Reconnaissance period monitoring financial communications
- Establishment of forwarding rules to track payment discussions
- Impersonation of vendor with modified payment instructions
- Funds transferred to money mule accounts (including the sentenced CPA)
- Rapid layering and movement of funds through financial system
Affected Systems:
- Vendor email platforms (Microsoft 365, Google Workspace)
- Healthcare organization financial/AP systems
- Banking portals and payment processing platforms
- Potential PHI exposure in email communications with vendors
Exploitation Status: BEC remains actively exploited across healthcare, with CISA including BEC in their Known Exploited Vulnerabilities Catalog due to its prevalence and impact. No CVE is required for BEC— attackers exploit human trust and process weaknesses rather than software vulnerabilities.
Detection & Response
Effective BEC defense requires multiple detection layers. The following rules and queries target key observable behaviors.
SIGMA Rules
---
title: Suspicious Outbound Funds Transfer to New Beneficiary
id: bea0c8f1-4d52-4a9b-9e0a-2b3c4d5e6f7g
status: experimental
description: Detects outbound financial transfers to new or recently modified beneficiary accounts, which may indicate BEC activity.
references:
- https://attack.mitre.org/techniques/T1566/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1566
logsource:
product: erp
detection:
selection:
EventID:
- 1001 # Payment processed
- 1002 # Funds transfer initiated
Action|contains:
- 'transfer'
- 'payment'
Amount|gte: 10000
filter:
BeneficiaryAccount|startswith:
- 'US-' # Pre-existing internal accounts
condition: selection and not filter
timeframe: 7d
falsepositives:
- Legitimate payments to new vendors
- Employee expense reimbursements
level: high
---
title: Email Forwarding Rule Created to External Domain
id: c2d3e4f5-6a7b-8c9d-0e1f-2a3b4c5d6e7f
status: experimental
description: Detects creation of inbox forwarding rules to external domains, a common persistence mechanism in BEC attacks.
references:
- https://attack.mitre.org/techniques/T1114/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1114.003
logsource:
product: o365
service: exchange
detection:
selection:
Operation|contains:
- 'New-InboxRule'
- 'Set-InboxRule'
Parameters|contains:
- 'ForwardTo'
- 'RedirectTo'
Parameters|contains:
- '@'
Parameters|notcontains:
- 'company.com' # Replace with your internal domain
falsepositives:
- Legitimate email forwarding setup by users
level: medium
---
title: Vendor Payment Account Modification
id: d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a
status: experimental
description: Detects modifications to vendor payment details within financial systems, a key BEC indicator.
references:
- https://attack.mitre.org/techniques/T1659/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.impact
- attack.t1659
logsource:
product: sap
detection:
selection:
EventID: 1005 # Vendor master data change
ChangedFields|contains:
- 'BANK_ACCOUNT'
- 'IBAN'
- 'BANK_KEY'
filter:
ChangedBy|endswith:
- '_SERVICE' # Automated service accounts
condition: selection and not filter
falsepositives:
- Legitimate vendor banking updates
level: high
KQL (Microsoft Sentinel / Defender)
// Hunt for unusual vendor payment modifications
let Timeframe = 7d;
let VendorThreshold = 3;
let PaymentModifications =
MaterializedChangeLog
| where TimeGenerated >= ago(Timeframe)
| where ObjectType == "Vendor"
| where ChangedFields has "Bank" or ChangedFields has "Payment"
| project TimeGenerated, ChangedBy, VendorID, ChangedFields, PreviousValues, NewValues;
let HighVolumeModifiers =
PaymentModifications
| summarize Count = count() by ChangedBy
| where Count >= VendorThreshold;
PaymentModifications
| join kind=inner HighVolumeModifiers on ChangedBy
| project TimeGenerated, ChangedBy, VendorID, ChangedFields, PreviousValues, NewValues
| order by TimeGenerated desc
// Identify new email forwarding rules
let ExternalDomains =
OfficeActivity
| where TimeGenerated >= ago(30d)
| where Operation =~ "New-InboxRule" or Operation =~ "Set-InboxRule"
| extend ForwardTo = parse_(tostring(Parameters))[0]
| where isnotempty(ForwardTo)
| where ForwardTo !contains "@yourdomain.com" // Replace with your domain
| distinct ForwardTo;
OfficeActivity
| where TimeGenerated >= ago(7d)
| where Operation =~ "New-InboxRule" or Operation =~ "Set-InboxRule"
| extend ForwardTo = parse_(tostring(Parameters))[0]
| where isnotempty(ForwardTo)
| where ForwardTo in (ExternalDomains)
| project TimeGenerated, UserId, ClientIP, Operation, ForwardTo, Parameters
| order by TimeGenerated desc
// Detect anomalous large transfers to new beneficiaries
let NewBeneficiaries =
BankTransfer
| where TimeGenerated >= ago(30d)
| project BeneficiaryAccount, FirstSeen = min(TimeGenerated)
| summarize by BeneficiaryAccount, FirstSeen;
BankTransfer
| where TimeGenerated >= ago(7d)
| where Amount > 50000 // Adjust threshold for your organization
| join kind=inner NewBeneficiaries on BeneficiaryAccount
| where TimeGenerated - FirstSeen <= time(7d)
| project TimeGenerated, Initiator, BeneficiaryAccount, Amount, FirstSeen
| order by TimeGenerated desc
Velociraptor VQL
-- Hunt for suspicious Outlook forwarding rules on endpoints
SELECT * FROM foreach(
SELECT OSPath FROM glob(globs="*/Microsoft/Outlook/*.pst"),
SELECT
parse_string_with_regex(string=Data, regex='Rule Name: (?P<RuleName>.*?)\\nAction: (?P<Action>.*?)\\nConditions: (?P<Conditions>.*?)\\n\\n') AS RuleData
FROM read_file(filename=OSPath)
WHERE Data =~ "Forward" OR Data =~ "Redirect"
)
-- Check for suspicious browser saved passwords related to financial portals
SELECT * FROM artifact=Windows.Chrome.History()
WHERE Url =~ "bank" OR Url =~ "payment" OR Url =~ "portal"
AND LastVisitedTime > now() - 7d
-- Identify processes accessing email credential files
SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE Name IN ("powershell.exe", "cmd.exe", "python.exe", "wscript.exe")
AND (CommandLine =~ "outlook" OR CommandLine =~ "credential" OR CommandLine =~ "token")
Remediation Script (PowerShell)
# Script to detect and remove suspicious email forwarding rules
# Requires Exchange Online PowerShell module
function Detect-Remove-SuspiciousForwarding {
param(
[string[]]$TrustedDomains = @("yourdomain.com"),
[switch]$WhatIf
)
Write-Host "Checking for suspicious email forwarding rules..." -ForegroundColor Cyan
# Get all mailboxes
$mailboxes = Get-Mailbox -ResultSize Unlimited
foreach ($mailbox in $mailboxes) {
$inboxRules = Get-InboxRule -Mailbox $mailbox.PrimarySmtpAddress -ErrorAction SilentlyContinue
foreach ($rule in $inboxRules) {
$isSuspicious = $false
# Check for forwarding to external domains
if ($rule.ForwardTo -or $rule.RedirectTo) {
$forwardTargets = @($rule.ForwardTo) + @($rule.RedirectTo)
foreach ($target in $forwardTargets) {
if ($target) {
$domain = ($target -split "@")[1]
if ($domain -notin $TrustedDomains) {
$isSuspicious = $true
if ($WhatIf) {
Write-Host "[DETECT] Suspicious forwarding rule found for $($mailbox.PrimarySmtpAddress):" -ForegroundColor Yellow
Write-Host " Rule Name: $($rule.Name)" -ForegroundColor Yellow
Write-Host " Forwarding to: $target" -ForegroundColor Yellow
} else {
Write-Host "[REMOVE] Removing suspicious forwarding rule for $($mailbox.PrimarySmtpAddress):" -ForegroundColor Red
Write-Host " Rule Name: $($rule.Name)" -ForegroundColor Red
Remove-InboxRule -Mailbox $mailbox.PrimarySmtpAddress -Identity $rule.Identity -Confirm:$false
}
}
}
}
}
# Check for rules that delete messages (often used to hide evidence)
if ($rule.DeleteMessage -eq $true -and $rule.Enabled -eq $true) {
if ($WhatIf) {
Write-Host "[DETECT] Rule deleting messages found for $($mailbox.PrimarySmtpAddress): $($rule.Name)" -ForegroundColor Yellow
} else {
Write-Host "[DISABLE] Disabling rule that deletes messages for $($mailbox.PrimarySmtpAddress): $($rule.Name)" -ForegroundColor Red
Set-InboxRule -Mailbox $mailbox.PrimarySmtpAddress -Identity $rule.Identity -Enabled $false
}
}
}
}
Write-Host "Scan complete." -ForegroundColor Green
}
# Example usage - first run with WhatIf to see what would be changed
# Detect-Remove-SuspiciousForwarding -WhatIf
# Detect-Remove-SuspiciousForwarding
# Check for recent suspicious mailbox login activity
function Get-SuspiciousMailboxLogins {
param(
[int]$Days = 7
)
$startDate = (Get-Date).AddDays(-$Days)
Write-Host "Checking for suspicious mailbox login activity in the last $Days days..." -ForegroundColor Cyan
Get-StaleMailboxReport -StartDate $StartDate | Format-Table
# Check for successful logins from unusual locations
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
$stats = Get-MailboxStatistics -Identity $_.PrimarySmtpAddress
$lastLogon = $stats.LastLogonTime
if ($lastLogon -ge $startDate) {
Write-Host "Recent login detected: $($_.PrimarySmtpAddress) at $lastLogon" -ForegroundColor Green
}
}
}
Remediation
To protect against BEC attacks similar to the Children's Healthcare of Atlanta incident, implement the following controls:
Immediate Actions:
-
Enable MFA for All Vendor Communications: Require multi-factor authentication for all email accounts with vendor relationships, preferably using FIDO2 security keys or certificate-based authentication.
-
Establish Out-of-Band Verification: Implement a policy requiring phone verification (to known numbers, not those in emails) for all payment changes above $10,000 or new vendor setup.
-
Audit Email Forwarding Rules: Run the PowerShell script above to identify and remove suspicious forwarding rules.
Medium-Term Improvements:
-
Implement DMARC, SPF, and DKIM: Configure email authentication standards to prevent domain spoofing. Start with a "p=none" DMARC policy and progress to "p=quarantine" then "p=reject" as confidence increases.
-
Deploy AI-Powered BEC Detection: Implement solutions like Microsoft Defender for Office 365 ATP or Proofpoint that use machine learning to identify fraudulent email patterns based on communication graphs and behavioral analysis.
-
Enhance Vendor Onboarding: Require all vendors to complete security questionnaires and demonstrate email security controls before establishing payment relationships.
Long-Term Strategy:
-
Vendor Security Monitoring: Extend security monitoring to key vendors where technically feasible and contractually permitted.
-
Regular Security Awareness Training: Conduct quarterly phishing simulations specifically targeting finance and procurement teams with scenarios mimicking BEC attacks.
-
Incident Response Playbooks: Develop and test specific BEC response procedures, including banking notification protocols and legal response steps.
Vendor Advisory:
Vendors should be directed to:
- Implement anomaly detection on email accounts
- Regularly review delegated permissions and inbox rules
- Establish email change verification procedures
- Review access logs for unusual locations and times
- Encrypt sensitive financial data in transit and at rest
The Children's Healthcare of Atlanta case demonstrates that BEC remains a highly profitable attack vector for criminals. With healthcare organizations processing millions in payments, they remain prime targets. Technical controls, combined with process improvements and security awareness, are essential to protecting both financial assets and patient data.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.