SC-047: Phishing Infrastructure & Business Email Compromise¶

Scenario Overview¶

A sophisticated threat actor registers typosquat domains mimicking a target organization, configures email authentication (SPF, DKIM, DMARC) on the attacker-controlled domain to pass email security checks, and launches a multi-stage Business Email Compromise (BEC) campaign. The attacker harvests credentials from an executive, then impersonates that executive to authorize a fraudulent wire transfer to an attacker-controlled bank account.

Environment: Corporate Microsoft 365 tenant (acme-corp.example.com) Initial Access: Credential harvesting via phishing page on lookalike domain Impact: $2.3M fraudulent wire transfer, executive mailbox compromise Difficulty: Advanced Sector: Manufacturing

Attack Timeline¶

Technical Analysis¶

Phase 1: Resource Development — Domain Infrastructure¶

The attacker registers domains that are visually similar to the target organization's domain through character substitution (typosquatting).

Target domain:    acme-corp.example.com
Attacker domains: acme-c0rp.example.com  (o → 0)
                  acme-corp.examp1e.com  (l → 1)
                  acme--corp.example.com (double hyphen)

Registrar: budget-registrar.example.com
Registration date: 2026-03-01
Registrant: privacy-protected
Hosting IP: 198.51.100.44
Name servers: ns1.attacker-dns.example.com, ns2.attacker-dns.example.com

Phase 2: Email Authentication Setup¶

The attacker configures proper email authentication on the lookalike domain to bypass security filters.

; DNS records for acme-c0rp.example.com (attacker-controlled)
; SPF — authorizes the attacker's mail server
acme-c0rp.example.com.  IN TXT "v=spf1 ip4:198.51.100.44 -all"

; DKIM — signs outbound email with attacker's key
selector1._domainkey.acme-c0rp.example.com. IN TXT "v=DKIM1; k=rsa; p=REDACTED_PUBLIC_KEY"

; DMARC — policy set to reject (ironically increases deliverability)
_dmarc.acme-c0rp.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@acme-c0rp.example.com"

; MX record
acme-c0rp.example.com.  IN MX 10 mail.acme-c0rp.example.com.
mail.acme-c0rp.example.com. IN A 198.51.100.44

Phase 3: Credential Harvesting Page¶

The attacker deploys a convincing Microsoft 365 login page clone.

URL: https://login.acme-c0rp.example.com/oauth2/authorize
TLS Certificate: Let's Encrypt (valid, trusted by all browsers)
Page title: "Sign in - acme-corp"  (note: uses correct branding)

# Harvesting server configuration (reconstructed from forensics)
Backend: 198.51.100.44:443
Credential forwarding: POST to https://198.51.100.44/api/harvest
Session cookie replay: Enabled (real-time MFA bypass via proxy)

The harvesting page acts as a transparent proxy, forwarding credentials to the real Microsoft login in real-time and capturing the session token, effectively bypassing MFA.

# Request flow (simplified):
Victim → https://login.acme-c0rp.example.com → 198.51.100.44 → https://login.microsoftonline.com
                                                  ↓
                                          Credentials logged
                                          Session token captured

Phase 4: Phishing Email Delivery¶

From: it-support@acme-c0rp.example.com
To: cfo@acme-corp.example.com
Subject: [Action Required] Multi-Factor Authentication Update
Date: Mon, 15 Mar 2026 08:31:00 +0000
Message-ID: <REDACTED@acme-c0rp.example.com>

DKIM-Signature: v=1; a=rsa-sha256; d=acme-c0rp.example.com; s=selector1; [VALID]
Authentication-Results: mx.acme-corp.example.com;
  spf=pass (sender IP 198.51.100.44) smtp.mailfrom=acme-c0rp.example.com;
  dkim=pass header.d=acme-c0rp.example.com;
  dmarc=pass (p=reject) header.from=acme-c0rp.example.com

Body:
Dear [CFO Name],

Due to our recent security policy update, all executives are required
to re-verify their multi-factor authentication settings by end of day.

Please click the link below to complete the verification:
https://login.acme-c0rp.example.com/oauth2/authorize?prompt=verify

Thank you,
IT Security Team
Acme Corporation

Phase 5: Mailbox Compromise and Inbox Rule¶

After capturing the CFO's session token, the attacker accesses the mailbox.

# Attacker creates inbox rule to hide evidence (via Graph API)
# POST https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messageRules

{
  "displayName": "Security Updates",
  "sequence": 1,
  "isEnabled": true,
  "conditions": {
    "subjectContains": [
      "suspicious sign-in",
      "unusual activity",
      "security alert",
      "password changed",
      "new sign-in",
      "inbox rule"
    ]
  },
  "actions": {
    "moveToFolder": "deletedItems",
    "markAsRead": true
  }
}

# Attacker login details (from Azure AD sign-in logs)
Sign-in timestamp: 2026-03-15 09:15:22 UTC
User: cfo@acme-corp.example.com
Application: Microsoft Office 365
IP Address: 203.0.113.91
Location: Foreign country (anomalous for this user)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/122.0.0.0
MFA: Bypassed (session token replay)
Status: Success

Phase 6: Business Email Compromise¶

The attacker reads ongoing email threads about a pending vendor payment and crafts a BEC email from the compromised CFO mailbox.

From: cfo@acme-corp.example.com  (legitimate mailbox — compromised)
To: ap-team@acme-corp.example.com
Subject: RE: Q1 Vendor Payment - URGENT Change
Date: Mon, 15 Mar 2026 10:42:17 +0000

Hi Team,

I just got off a call with our vendor's treasury department. They've
changed their banking details effective immediately. Please update
the wire transfer for the Q1 payment ($2,300,000) to the following:

Bank: International Commerce Bank
Account: REDACTED-ATTACKER-ACCOUNT
Routing: REDACTED
SWIFT: REDACTED
Reference: ACME-Q1-2026

This is time-sensitive — please process today. I'm heading into
back-to-back meetings so please don't call, just confirm by email.

Thanks,
[CFO Name]
CFO, Acme Corporation

Detection Opportunities¶

KQL — Lookalike Domain Email Detection¶

// Detect emails from domains visually similar to your organization
EmailEvents
| where SenderFromDomain matches regex @"acme.?c[o0]rp"
| where SenderFromDomain != "acme-corp.example.com"
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    SenderIPv4,
    DeliveryAction
| sort by Timestamp desc

KQL — Suspicious Inbox Rule Creation¶

// Detect inbox rules that hide security notifications
CloudAppEvents
| where ActionType == "New-InboxRule"
| extend RuleDetails = parse_json(RawEventData)
| where RuleDetails.Parameters has_any (
    "suspicious", "security alert", "unusual activity",
    "password changed", "sign-in", "inbox rule"
)
| project
    Timestamp,
    AccountDisplayName,
    ActionType,
    RuleName = RuleDetails.Parameters[0].Value,
    MoveToFolder = RuleDetails.Parameters[3].Value,
    IPAddress,
    UserAgent
| sort by Timestamp desc

KQL — Anomalous Sign-In Location for Executive¶

// Detect sign-ins from unusual locations for executive accounts
SigninLogs
| where UserPrincipalName in ("cfo@acme-corp.example.com", "ceo@acme-corp.example.com")
| where ResultType == 0  // Successful sign-in
| extend City = LocationDetails.city, Country = LocationDetails.countryOrRegion
| summarize
    SignInCount = count(),
    IPs = make_set(IPAddress),
    Locations = make_set(strcat(City, ", ", Country))
    by UserPrincipalName, AppDisplayName, bin(TimeGenerated, 1h)
| where SignInCount > 0
| sort by TimeGenerated desc

KQL — New Domain Age Check in Email¶

// Flag emails from recently registered domains (< 30 days)
EmailEvents
| where Timestamp > ago(7d)
| where DeliveryAction == "Delivered"
| join kind=inner (
    EmailUrlInfo
    | extend DomainAge = datetime_diff('day', now(), UrlDomainCreationDate)
    | where DomainAge < 30
) on NetworkMessageId
| project
    Timestamp,
    SenderFromAddress,
    RecipientEmailAddress,
    Subject,
    Url,
    DomainAge
| sort by DomainAge asc

SPL — Lookalike Domain Detection¶

index=email sourcetype="o365:messageTrace"
| eval sender_domain=lower(mvindex(split(sender, "@"), 1))
| where match(sender_domain, "acme.?c[o0]rp")
  AND sender_domain!="acme-corp.example.com"
| table _time sender recipient subject sender_domain src_ip
        authentication_results
| sort -_time

SPL — Inbox Rule Creation with Suspicious Keywords¶

index=o365 sourcetype="o365:management:activity"
  Operation="New-InboxRule"
| spath path=Parameters{}.Value output=rule_values
| where match(rule_values, "(?i)(suspicious|security alert|unusual|password changed|sign-in)")
| table _time UserId Operation ClientIP rule_values UserAgent
| sort -_time

SPL — Wire Transfer Email Keywords¶

index=email sourcetype="o365:messageTrace"
  (subject="*wire transfer*" OR subject="*bank*change*" OR subject="*urgent*payment*")
| eval sender_domain=mvindex(split(sender, "@"), 1)
| stats count by sender recipient subject sender_domain
| where count > 0
| sort -count

SPL — Foreign Login for Executive Accounts¶

index=azure sourcetype="azure:aad:signin"
  userPrincipalName IN ("cfo@acme-corp.example.com", "ceo@acme-corp.example.com")
  status.errorCode=0
| iplocation clientIpAddress
| eval location=City . ", " . Country
| stats count values(clientIpAddress) as ips values(location) as locations
        by userPrincipalName appDisplayName
| sort -count

Response Playbook¶

Immediate Containment (0-30 minutes)¶

1. Revoke all sessions for the compromised CFO account (Azure AD: Revoke Sessions)
2. Reset the CFO's password and re-enroll MFA with a new method
3. Delete the malicious inbox rule from the CFO's mailbox
4. Contact the bank to freeze/recall the fraudulent wire transfer
5. Block the attacker domain (acme-c0rp.example.com) in email gateway and DNS
6. Block attacker IPs: 198.51.100.44, 203.0.113.91 at the firewall

Eradication (30 minutes - 4 hours)¶

1. Audit all inbox rules across executive mailboxes for similar hiding patterns
2. Review Azure AD sign-in logs for the compromised account — identify all attacker sessions
3. Check for OAuth app consent grants the attacker may have created for persistence
4. Review mail flow rules at the tenant level for attacker-created forwarding
5. Scan for additional compromised accounts using the same phishing campaign
6. Submit the phishing URL to Microsoft (Safe Links) and browser vendors for blocking

Recovery (4-48 hours)¶

1. Implement conditional access policies: Block sign-ins from non-corporate locations for executives
2. Deploy phishing-resistant MFA: FIDO2 keys or certificate-based authentication (session token replay resistant)
3. Enable external email tagging: Banner on all emails from external senders
4. Implement DMARC monitoring with aggregate reports on your domain
5. Deploy typosquat domain monitoring service to detect lookalike registrations
6. Establish dual-authorization for wire transfers exceeding threshold amounts
7. Conduct BEC awareness training for finance and AP staff
8. Implement email authentication verification in the email gateway (reject on DMARC fail)

MITRE ATT&CK Mapping¶

Lessons Learned¶

1. SPF/DKIM/DMARC protect your domain, not your inbox: These protocols verify that the sending domain is authorized — but an attacker with their own properly configured domain will pass all checks. User awareness and lookalike domain monitoring are essential complements.

2. Session token replay defeats traditional MFA: Phishing-resistant MFA methods (FIDO2, certificate-based) bind the authentication to the legitimate site origin and cannot be proxied. SMS/TOTP codes can be intercepted by transparent proxy attacks.

3. Inbox rules are a persistence and evasion mechanism: Attackers routinely create rules to hide security notifications. Monitoring inbox rule creation, especially with suspicious keyword filters, is a high-value detection.

4. BEC is the highest-dollar cybercrime category: FBI IC3 reports consistently show BEC losses exceeding all other cybercrime categories combined. Process controls (dual authorization, out-of-band verification for payment changes) are more effective than purely technical controls.

5. Domain age is a useful signal: Legitimate business partners do not typically send emails from domains registered within the past 30 days. Email gateways should flag or quarantine emails from very young domains.

6. Executive accounts require enhanced monitoring: Conditional access policies, impossible travel detection, and anomalous sign-in alerting should be configured with lower thresholds for C-suite accounts.

Cross-References¶

• Chapter 31: Network Security Architecture — Email security, DNS security, and network-based phishing detection
• Chapter 33: Identity & Access Security — MFA, conditional access, and identity protection
• SC-023: Credential Stuffing & Password Spraying — Related credential theft techniques
• IR Playbook: Phishing Response — Detailed phishing incident response procedures