T1598

Phishing for Information

Reconnaissance Last updated:

Detects adversary phishing-for-information campaigns targeting employees via email, spearphishing, and social engineering to harvest credentials, one-time passwords, and sensitive organizational data. Detection operates across three layers: (1) inbound email analysis identifying spoofed senders (From/MailFrom domain mismatch), credential-harvesting subject line keywords, and URLs pointing to non-trusted domains; (2) URL click telemetry correlating users navigating to phishing infrastructure after suspicious email delivery; and (3) post-phishing authentication anomalies such as sign-ins from new geographies within minutes of a suspicious email click. This technique is actively used by Scattered Spider for MFA/OTP capture, APT28 for credential collection against campaign targets, and Kimsuky for intelligence gathering against research institutions.

What is T1598 Phishing for Information?

Phishing for Information (T1598) maps to the Reconnaissance tactic — the adversary is trying to gather information they can use to plan future operations in MITRE ATT&CK.

This page provides production-ready detection logic for Phishing for Information, covering the data sources and telemetry it touches: Microsoft Defender for Office 365. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Reconnaissance
Technique
T1598 Phishing for Information
Canonical reference
https://attack.mitre.org/techniques/T1598/
Microsoft Sentinel / Defender
kusto
let PhishingKeywords = dynamic(["verify your account", "confirm your identity", "urgent action required", "account suspended", "click to verify", "validate credentials", "one-time password", "account will be locked", "update your information", "security notification", "unusual sign-in", "confirm your credentials"]);
let TrustedDomains = dynamic(["microsoft.com", "office.com", "office365.com", "microsoftonline.com", "google.com", "amazon.com", "github.com", "okta.com", "salesforce.com"]);
EmailEvents
| where TimeGenerated > ago(1d)
| where DeliveryAction !in ("Blocked")
| where EmailDirection == "Inbound"
| extend SpoofedSender = (SenderFromDomain != SenderMailFromDomain and isnotempty(SenderMailFromDomain))
| extend SuspiciousSubject = (Subject has_any (PhishingKeywords))
| join kind=leftouter (
    EmailUrlInfo
    | where TimeGenerated > ago(1d)
    | where isnotempty(UrlDomain)
    | where UrlDomain !has_any (TrustedDomains)
    | summarize SuspiciousUrls = make_set(Url, 5), SuspiciousUrlDomains = make_set(UrlDomain, 5) by NetworkMessageId
) on NetworkMessageId
| where SpoofedSender or SuspiciousSubject or isnotempty(SuspiciousUrls)
| extend RiskScore = toint(SpoofedSender) * 50 + toint(SuspiciousSubject) * 30 + iff(isnotempty(SuspiciousUrls), 20, 0)
| where RiskScore >= 30
| project TimeGenerated, RecipientEmailAddress, SenderFromAddress, SenderMailFromAddress, Subject, DeliveryAction, NetworkMessageId, SpoofedSender, SuspiciousSubject, SuspiciousUrls, SuspiciousUrlDomains, RiskScore
| order by RiskScore desc, TimeGenerated desc

Detects inbound emails exhibiting phishing-for-information characteristics: spoofed sender addresses (From domain differs from MailFrom domain indicating SPF alignment failures or display-name spoofing), subject lines containing credential harvesting or social engineering keywords, and URLs pointing to domains not in the trusted baseline. Requires Microsoft Defender for Office 365 Plan 2 with Advanced Hunting enabled in the Microsoft 365 Defender portal.

high severity medium confidence

Data Sources

Microsoft Defender for Office 365

Required Tables

EmailEvents EmailUrlInfo

False Positives

  • Security awareness training platforms (KnowBe4, Proofpoint Security Awareness Training) sending simulated phishing emails with intentional urgency language — add their sending domains to an exclusion list
  • Legitimate password reset and account verification emails from external SaaS vendors (Okta, Salesforce, ServiceNow) that use 'verify your account' or 'urgent action' language — add known-good vendor domains to TrustedDomains
  • Marketing automation platforms (Mailchimp, HubSpot, Marketo) using display-name spoofing where MailFrom belongs to the ESP but From shows the client company brand — causing SpoofedSender false positives
  • Bulk email systems with legitimate SPF misalignment for delivery routing purposes, where the technical envelope sender differs from the brand display From address

Sigma rule & cross-platform mapping

The detection logic for Phishing for Information (T1598) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  product: azure

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1GoPhish Credential Harvesting Campaign Simulation

    Expected signal: EmailEvents alert on phishing keywords in test email subjects; UrlClickEvents showing recipient navigated to GoPhish landing page URL; HTTP POST to GoPhish listener captured in web proxy logs; AADSignInLogs showing no anomalous auth (validates that controls blocked credential use)

  2. Test 2Evilginx2 Adversary-in-the-Middle Phishing Proxy Setup

    Expected signal: Network flow logs showing HTTPS connection to proxy infrastructure with non-organizational certificate; DeviceNetworkEvents showing browser connection to AiTM domain; AADSignInLogs showing token replay from attacker IP shortly after legitimate user authentication

  3. Test 3Spearphishing Voice (Vishing) Pretext Simulation with Callback Detection

    Expected signal: User report submitted to security team via phishing report button or SIEM ingestion of helpdesk ticket; if conducted via licensed vishing simulation platform (e.g., Proofpoint Vishing Simulator), campaign results exported to SIEM; telephony logs showing inbound calls from spoofed caller IDs


Response Playbook

Triage

  1. Step 1: Retrieve full email headers from Exchange Admin Center (Message Trace) or M365 Defender Threat Explorer. Inspect Authentication-Results header for SPF=fail, DKIM=fail, and DMARC=fail or p=none (no enforcement). A SPF failure combined with Display Name impersonating a trusted internal sender is high confidence for spoofing.
  2. Step 2: Compare the 5321.MailFrom (envelope sender in Return-Path header) against the 5322.From (display From header). Discrepancies where MailFrom belongs to a generic ESP or unknown domain while From shows a corporate executive name indicate display-name spoofing — a common T1598 technique.
  3. Step 3: Extract and expand all URLs from the email body. Unshorten any redirect chains using curl -I or a sandbox URL expander. Submit final destination URLs to VirusTotal and URLScan.io. Look for: domain registration age under 30 days (WHOIS lookup), lookalike domains (e.g., paypa1[.]com, company-it-helpdesk[.]net), and HTML forms requesting credential input.
  4. Step 4: Query UrlClickEvents in M365 Defender Advanced Hunting for the NetworkMessageId: `UrlClickEvents | where NetworkMessageId == "<id>" | project TimeGenerated, AccountUpn, Url, IPAddress, IsClickedThrough`. Identify which recipients clicked through and record their UPNs and click timestamps.
  5. Step 5: For each recipient who clicked, pivot to AADSignInLogs for the 90 minutes following their click time. Look for: new country/IP not in the user's baseline (LocationDetails), IsInteractive=true successful authentications, and MFA push notifications immediately followed by MFA success (indicating live OTP relay as used by Scattered Spider).
  6. Step 6: Assess campaign scope — query EmailEvents for emails from the same SenderMailFromDomain, same URL domain, or similar subject pattern across all users in the last 72 hours. Cross-reference with SecurityAlert table for any Defender for Office 365 ATP alerts triggered by the same sender.

Containment

  1. Soft-delete the phishing email from all recipient mailboxes using M365 Defender Threat Explorer Actions > Delete messages (soft delete moves to Recoverable Items; hard delete purges). Document NetworkMessageId and affected recipients before deletion.
  2. Block the sender domain at the Exchange Online Protection level: in Security & Compliance Center, add the domain to Tenant Allow/Block Lists under Sender block entries. For high-confidence spoofing, also block the originating IP range.
  3. Block phishing URLs in Microsoft Defender for Office 365 Safe Links custom block list to prevent delayed clicks on already-delivered messages. URL blocks are applied retroactively to all delivered emails.
  4. If credential capture is confirmed (user clicked through to credential form and subsequently had anomalous sign-in): immediately reset the user's password, revoke all active sessions via `Revoke-MgUserSignInSession -UserId <upn>`, and force MFA re-registration if OTP interception is suspected.
  5. If adversary-in-the-middle (AiTM) attack is confirmed — indicated by phishing site with valid TLS cert, OTP prompts relayed in real time, and session cookie theft — invalidate all refresh tokens: `Update-MgUser -UserId <upn> -PasswordProfile @{ForceChangePasswordNextSignIn=$true}` and review all OAuth app consents granted.

Evidence Collection

  1. Export full email with headers from Exchange via Graph API: `GET /v1.0/users/{userId}/messages/{messageId}/$value` — saves as .eml file preserving all authentication headers for forensic review.
  2. Pull URL click telemetry: `UrlClickEvents | where NetworkMessageId == "<id>" | project TimeGenerated, AccountUpn, Url, IPAddress, IsClickedThrough, Workload` — establishes which users interacted and from what IP addresses.
  3. Export AADSignInLogs for all affected recipients for the 72-hour window post-delivery. Preserve: IPAddress, Location, DeviceDetail, ConditionalAccessStatus, AuthenticationDetails (MFA method used), and RiskDetail fields.
  4. Collect Defender for Office 365 detonation report for phishing URLs (available in Threat Explorer under URL Analysis tab) — captures JavaScript behavior, credential form fields, and redirect chains in a sandboxed environment.
  5. Document threat intelligence enrichment: WHOIS registration date for sender and URL domains, VirusTotal domain/IP reputation, AbuseIPDB reports, and any infrastructure overlap with known threat actor campaigns using tools like Maltego or MISP.

Escalation Criteria

  • ! Escalate immediately if UrlClickEvents shows 5 or more users clicked phishing links — indicates active in-progress campaign requiring incident-level response and potential enterprise-wide credential reset.
  • ! Escalate if AADSignInLogs shows successful interactive authentication from a new country within 60 minutes of a phishing click — indicates live credential use and possible active attacker session.
  • ! Escalate if phishing content is requesting OTP/MFA codes directly (indicated by landing page capturing both password and a second factor field) — AiTM infrastructure enables real-time MFA bypass as used by Scattered Spider/Octo Tempest.
  • ! Escalate if phishing targets executives, Global Admins, Exchange Admins, or Security Admins — privileged account compromise has immediate blast radius affecting all tenant resources.
  • ! Escalate if sender infrastructure is shared with known threat actor campaigns identified in commercial threat intelligence (e.g., MSTIC, CrowdStrike, Mandiant advisories) — indicates nation-state or sophisticated eCrime targeting.

Investigation Guide

Forensic Artifacts

  • > Email headers: Authentication-Results (SPF, DKIM, DMARC pass/fail), X-MS-Exchange-Organization-SCL (spam confidence level 0-9), X-Originating-IP, X-MS-Exchange-CrossTenant-AuthSource
  • > Exchange Message Trace logs: complete SMTP relay path, connector usage, and SmartHost routing showing email origin and any relay hops
  • > Microsoft Defender for Office 365 Threat Explorer: URL detonation sandbox results, sender reputation scoring, and email cluster analysis showing campaign patterns
  • > UrlClickEvents table: user click timestamps, source IP at time of click, full redirect chain to final URL, and IsClickedThrough boolean
  • > AADSignInLogs: authentication events correlated to phishing click timeline — IPAddress, LocationDetails.City/CountryOrRegion, DeviceDetail.OperatingSystem, ConditionalAccessStatus, AuthenticationDetails
  • > Browser history artifacts on endpoint: evidence of visit to credential harvesting page — accessible via forensic acquisition or EDR telemetry (DeviceNetworkEvents with RemoteUrl matching phishing domain)
  • > Network proxy/firewall logs: HTTP/HTTPS connections to phishing infrastructure with HTTP referrer headers showing email client origin

Tuning Guidance

This detection produces significant volume due to the prevalence of legitimate emails using urgency language. Apply tuning in three stages: (1) Build an exclusion list of known security awareness training sender domains (KnowBe4, Proofpoint TAP, Cofense PhishMe) and suppress all alerts from these domains. (2) Create a known-good vendor allowlist for external SaaS services that routinely send account notification emails (Okta, Salesforce, ServiceNow, Workday) — for these domains, retain SPF/DKIM failure detection but suppress keyword matching. (3) Increase the RiskScore threshold to 70 for general employees and lower it to 20 for privileged accounts (Global Admin, Exchange Admin, Security Admin, Finance roles). The highest-fidelity composite signal is SpoofedSender=true AND RiskScore >= 50 — prioritize these over single-indicator matches. Consider integrating threat intelligence feeds to auto-update phishing domain blocklists rather than relying solely on keyword scoring.


Hunting Queries

Hunts for users who clicked through phishing links and then authenticated from a new IP or location within 90 minutes — the strongest indicator of successful credential harvesting with immediate adversary use.

Hunting — KQL
kql
// Hunt: users who clicked phishing links and subsequently authenticated from new locations
let ClickWindow = 90min;
let RecentClicks = UrlClickEvents
| where TimeGenerated > ago(7d)
| where IsClickedThrough == true
| project ClickTime = TimeGenerated, AccountUpn, NetworkMessageId, ClickedUrl = Url;
let RecentSignIns = AADSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where IsInteractive == true
| project SignInTime = TimeGenerated, UserPrincipalName, IPAddress, City = tostring(LocationDetails.city), Country = tostring(LocationDetails.countryOrRegion), DeviceOS = tostring(DeviceDetail.operatingSystem);
RecentClicks
| join kind=inner RecentSignIns on $left.AccountUpn == $right.UserPrincipalName
| where SignInTime between (ClickTime .. (ClickTime + ClickWindow))
| extend TimeDeltaMinutes = datetime_diff('minute', SignInTime, ClickTime)
| project ClickTime, SignInTime, TimeDeltaMinutes, AccountUpn, ClickedUrl, IPAddress, City, Country, DeviceOS, NetworkMessageId
| order by TimeDeltaMinutes asc
Hunting — SPL
spl
index=* sourcetype="ms:o365:management:activity" Operation="UrlClick"
| rex field=_raw "\"UserId\":\"(?<UserId>[^\"]+)\""
| rex field=_raw "\"Url\":\"(?<ClickedUrl>[^\"]+)\""
| eval ClickTime=_time
| join type=inner UserId [
    index=* sourcetype="ms:o365:signin:audit" ResultType=0
    | rex field=_raw "\"UserPrincipalName\":\"(?<UserId>[^\"]+)\""
    | rex field=_raw "\"IPAddress\":\"(?<SignInIP>[^\"]+)\""
    | rex field=_raw "\"City\":\"(?<SignInCity>[^\"]+)\""
    | eval SignInTime=_time ]
| where SignInTime >= ClickTime AND SignInTime <= ClickTime + 5400
| eval TimeDeltaMin=round((SignInTime - ClickTime)/60, 1)
| table ClickTime, SignInTime, TimeDeltaMin, UserId, ClickedUrl, SignInIP, SignInCity
| sort TimeDeltaMin

Hunts for phishing-for-information campaigns targeting high-value organizational roles (Finance, HR, C-Suite, IT/Security) with BEC-themed or credential-harvesting subjects — common pattern for APT reconnaissance and financial fraud precursors.

Hunting — KQL
kql
// Hunt: high-value role targeting — phishing aimed at privileged or sensitive job functions
let SensitiveRoleKeywords = dynamic(["hr@", "payroll@", "finance@", "cfo@", "ceo@", "cto@", "it@", "admin@", "security@", "helpdesk@", "recruiting@"]);
let BECKeywords = dynamic(["invoice", "wire transfer", "direct deposit", "w-2", "tax form", "benefits enrollment", "payroll change", "vendor payment", "purchase order"]);
EmailEvents
| where TimeGenerated > ago(7d)
| where DeliveryAction != "Blocked"
| where EmailDirection == "Inbound"
| where RecipientEmailAddress has_any (SensitiveRoleKeywords)
    or Subject has_any (BECKeywords)
    or Subject has_any (["IT help desk", "password reset", "account credentials", "VPN access", "new employee"])
| extend TargetedRole = case(
    RecipientEmailAddress has_any (["cfo@","ceo@","cto@"]), "C-Suite",
    RecipientEmailAddress has_any (["payroll@","finance@"]), "Finance",
    RecipientEmailAddress has_any (["hr@","recruiting@"]), "HR",
    RecipientEmailAddress has_any (["it@","admin@","helpdesk@","security@"]), "IT/Security",
    "General")
| summarize EmailCount = count(), UniqueSubjects = dcount(Subject), Senders = make_set(SenderFromAddress, 10), Subjects = make_set(Subject, 10) by TargetedRole, SenderFromDomain, bin(TimeGenerated, 1h)
| where EmailCount >= 2 or TargetedRole in ("C-Suite", "Finance")
| order by EmailCount desc
Hunting — SPL
spl
index=* sourcetype="ms:o365:management:activity" Workload=Exchange Operation="MessageDelivered"
| rex field=_raw "\"RecipientAddress\":\"(?<RecipientAddress>[^\"]+)\""
| rex field=_raw "\"SenderAddress\":\"(?<SenderAddress>[^\"]+)\""
| rex field=_raw "\"Subject\":\"(?<EmailSubject>[^\"]+)\""
| eval TargetRole=case(
    match(lower(RecipientAddress),"cfo|ceo|cto"), "C-Suite",
    match(lower(RecipientAddress),"payroll|finance"), "Finance",
    match(lower(RecipientAddress),"hr@|recruit"), "HR",
    match(lower(RecipientAddress),"it@|admin@|helpdesk|security@"), "IT-Security",
    1==1, "General")
| eval SensitiveTarget=if(TargetRole!="General", 1, 0)
| eval SensitiveContent=if(match(lower(EmailSubject),"invoice|wire|payroll|w-2|tax|benefits|credential|password|vpn|account"), 1, 0)
| where SensitiveTarget=1 OR SensitiveContent=1
| stats count as EmailCount, values(EmailSubject) as Subjects by SenderAddress, TargetRole, span(_time, 1h)
| sort -EmailCount

Hunts for emails with Reply-To headers pointing to different domains than the sender — a technique used to redirect victim replies to attacker-controlled mailboxes while appearing to originate from a legitimate sender, commonly used in spearphishing for information and BEC campaigns.

Hunting — KQL
kql
// Hunt: reply-to header mismatch — sender's reply-to points to attacker-controlled mailbox
EmailEvents
| where TimeGenerated > ago(7d)
| where DeliveryAction != "Blocked"
| where EmailDirection == "Inbound"
| where isnotempty(ReplyToAddresses)
| extend ReplyToDomain = tostring(split(tostring(parse_json(ReplyToAddresses)[0]), "@")[1])
| where ReplyToDomain != SenderFromDomain
    and ReplyToDomain != SenderMailFromDomain
    and ReplyToDomain !in ("gmail.com", "outlook.com", "hotmail.com")  // Adjust for your org's norms
| extend MismatchRisk = case(
    ReplyToDomain has_any (["protonmail", "tutanota", "guerrillamail", "tempmail"]), "High",
    ReplyToDomain != SenderFromDomain, "Medium",
    "Low")
| where MismatchRisk != "Low"
| project TimeGenerated, SenderFromAddress, SenderMailFromAddress, ReplyToAddresses, ReplyToDomain, RecipientEmailAddress, Subject, MismatchRisk
| order by MismatchRisk, TimeGenerated desc
Hunting — SPL
spl
index=* sourcetype="ms:o365:management:activity" Workload=Exchange Operation="MessageDelivered"
| rex field=_raw "\"SenderAddress\":\"[^@]+@(?<SenderDomain>[^\"]+)\""
| rex field=_raw "\"ReplyToAddresses\":\"[^@]+@(?<ReplyToDomain>[^\"]+)\""
| rex field=_raw "\"Subject\":\"(?<EmailSubject>[^\"]+)\""
| rex field=_raw "\"RecipientAddress\":\"(?<RecipientAddress>[^\"]+)\""
| where isnotnull(ReplyToDomain) AND ReplyToDomain!=SenderDomain
| eval AnonMailbox=if(match(lower(ReplyToDomain),"protonmail|tutanota|guerrilla|tempmail|mailnull"), 1, 0)
| eval RiskLevel=if(AnonMailbox=1, "High", "Medium")
| stats count as MessageCount, values(EmailSubject) as Subjects, values(RecipientAddress) as Recipients by SenderDomain, ReplyToDomain, RiskLevel
| sort -MessageCount

Atomic Red Team Tests

Test 1 GoPhish Credential Harvesting Campaign Simulation
linux

Deploys GoPhish framework to simulate a credential phishing campaign targeting internal users, validating email security controls, URL sandboxing, and click telemetry detection coverage for T1598.

Command

bash
# Authorized red team use only — requires written authorization
# Download and start GoPhish
wget -q https://github.com/gophish/gophish/releases/download/v0.12.1/gophish-v0.12.1-linux-64bit.zip -O /tmp/gophish.zip
cd /tmp && unzip -q gophish.zip && chmod +x gophish
cd /tmp && ./gophish &
sleep 5
# Retrieve API key from default credentials (admin:gophish)
GP_TOKEN=$(curl -sk -X POST https://localhost:3333/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"gophish"}' | python3 -c 'import sys,json; print(json.load(sys.stdin)["data"]["api_key"])')
# Create credential harvesting landing page
curl -sk -X POST "https://localhost:3333/api/pages/?api_key=${GP_TOKEN}" \
  -H 'Content-Type: application/json' \
  -d '{"name":"T1598-test-page","html":"<html><body><h2>Account Verification Required</h2><form method=POST action=/post><label>Email: <input name=email type=email></label><br><label>Password: <input name=password type=password></label><br><input type=submit value=Verify></form></body></html>","capture_credentials":true,"capture_passwords":true}'
echo "[T1598] GoPhish campaign configured at https://localhost:3333"

Cleanup

bash
pkill -f gophish; rm -rf /tmp/gophish /tmp/gophish.zip /tmp/gophish.db

Expected Telemetry

EmailEvents alert on phishing keywords in test email subjects; UrlClickEvents showing recipient navigated to GoPhish landing page URL; HTTP POST to GoPhish listener captured in web proxy logs; AADSignInLogs showing no anomalous auth (validates that controls blocked credential use)

Expected Detection

M365 Defender should alert on phishing URL delivery; Safe Links should detonate the landing page URL and flag credential input form; email security gateway should flag spoofed sender if From/MailFrom are mismatched in test configuration

Test 2 Evilginx2 Adversary-in-the-Middle Phishing Proxy Setup
linux

Configures Evilginx2 reverse proxy to simulate AiTM (adversary-in-the-middle) phishing infrastructure used by Scattered Spider and other actors to capture session cookies and OTP codes in real time, bypassing MFA.

Command

bash
# Authorized red team use only — AiTM simulation for detection validation
# Install Go dependency if needed
which go || (apt-get install -y golang-go 2>/dev/null || yum install -y golang 2>/dev/null)
# Clone and build Evilginx2
git clone https://github.com/kgretzky/evilginx2 /tmp/evilginx2-test
cd /tmp/evilginx2-test && go build -o bin/evilginx2 main.go 2>/dev/null
# Configure for offline/lab testing only (no live phishlets — DNS not configured)
cat > /tmp/evilginx2_test_config.yaml << 'EOF'
# T1598 AiTM simulation config — lab use only, no live domain
server_addr: 127.0.0.1
https_port: 8443
http_port: 8080
dns_port: 5300
phishlets: {}
EOF
echo "[T1598] Evilginx2 AiTM proxy framework built at /tmp/evilginx2-test/bin/evilginx2"
echo "[T1598] In real campaign: would proxy target IdP login, capturing session cookies post-MFA"
echo "[T1598] Detection validation: confirm proxy TLS cert in network inspection; UrlClickEvents for phishlet domain"

Cleanup

bash
rm -rf /tmp/evilginx2-test /tmp/evilginx2_test_config.yaml

Expected Telemetry

Network flow logs showing HTTPS connection to proxy infrastructure with non-organizational certificate; DeviceNetworkEvents showing browser connection to AiTM domain; AADSignInLogs showing token replay from attacker IP shortly after legitimate user authentication

Expected Detection

Microsoft Entra ID Protection should flag token replay risk (unfamiliar sign-in properties); Conditional Access policy enforcing compliant device should block session cookie replay from non-enrolled device; network proxy with TLS inspection should flag certificate mismatch on IdP domain

Test 3 Spearphishing Voice (Vishing) Pretext Simulation with Callback Detection
linux

Simulates T1598.004 vishing scenarios used by Scattered Spider targeting help desk staff to extract OTP codes and credential resets via telephone-based social engineering. Tests user reporting procedures and IR response to voice-based phishing.

Command

bash
# Vishing simulation — documents attack pattern without making actual calls
# Use for tabletop exercise and detection tuning validation
python3 << 'EOF'
import json
import datetime
import sys

vishing_scenarios = [
    {
        "scenario": "IT Help Desk Impersonation",
        "pretext": "Hello, this is IT support calling about a security incident on your account. I need to verify your identity — can you provide your current MFA code?",
        "information_targeted": ["OTP/MFA code", "employee ID", "manager name"],
        "threat_actor_association": "Scattered Spider / Octo Tempest",
        "mitre_technique": "T1598.004"
    },
    {
        "scenario": "Executive Assistant Impersonation",
        "pretext": "Hi, I'm calling on behalf of the CEO — they need you to urgently share your VPN credentials for a board meeting access issue.",
        "information_targeted": ["VPN credentials", "corporate email password"],
        "threat_actor_association": "BEC / Business Email Compromise actors",
        "mitre_technique": "T1598.004"
    }
]

for i, scenario in enumerate(vishing_scenarios, 1):
    print(f"[SIMULATION {i}] {scenario['scenario']}")
    print(f"  Pretext: {scenario['pretext'][:80]}...")
    print(f"  Targets: {', '.join(scenario['information_targeted'])}")
    print(f"  Actor TTP: {scenario['threat_actor_association']}")
    print()

log_entry = {
    "test_run": datetime.datetime.utcnow().isoformat(),
    "technique": "T1598.004",
    "scenarios_simulated": len(vishing_scenarios),
    "outcome": "SIMULATION COMPLETE - verify user reporting rate"
}
with open('/tmp/vishing_test_log.json', 'w') as f:
    json.dump(log_entry, f, indent=2)
print("[T1598] Simulation log written to /tmp/vishing_test_log.json")
EOF

Cleanup

bash
rm -f /tmp/vishing_test_log.json

Expected Telemetry

User report submitted to security team via phishing report button or SIEM ingestion of helpdesk ticket; if conducted via licensed vishing simulation platform (e.g., Proofpoint Vishing Simulator), campaign results exported to SIEM; telephony logs showing inbound calls from spoofed caller IDs

Expected Detection

Primary detection relies on user reporting — validate that simulated vishing calls generate security tickets; verify that MFA push notifications from help desk context appear in AADSignInLogs with unusual IP; confirm security awareness training completion rate improves after exercise

Related Detections

Detection Variants (1)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.