Detect Spearphishing Service in IBM QRadar
Adversaries may send spearphishing messages via third-party services to elicit sensitive information that can be used during targeting. This includes messages sent through social media platforms (LinkedIn, Twitter, Facebook, WhatsApp), personal webmail, and other non-enterprise controlled services. Adversaries create fake personas — often posing as recruiters, colleagues, or vendors — to build rapport with targets and extract credentials, security configurations, VPN details, or other actionable intelligence. Because these messages transit third-party platforms outside the victim's network perimeter, they generate no traditional endpoint or network telemetry on the victim side. Detection must focus on downstream indicators: post-harvest sign-in anomalies, inbox rule changes, MFA modifications, and OAuth consent grants.
MITRE ATT&CK
- Tactic
- Reconnaissance
- Technique
- T1598 Phishing for Information
- Sub-technique
- T1598.001 Spearphishing Service
- Canonical reference
- https://attack.mitre.org/techniques/T1598/001/
QRadar Detection Query
SELECT
DATEFORMAT(devicetime, 'yyyy-MM-dd HH:mm:ss') AS "EventTime",
LOGSOURCENAME(logsourceid) AS "LogSource",
LOGSOURCETYPENAME(devicetype) AS "LogSourceType",
"username", "sourceip", "destinationip",
"eventid", "deviceaction", "message",
CASE
WHEN "risklevelduringsignin" IN ('high', 'medium') OR (LOWER("operationname") ILIKE '%new-inboxrule%' AND LOWER("params") ILIKE '%forwardto%') THEN 8
ELSE 4
END AS "RiskScore"
FROM events
WHERE ("risklevelduringsignin" IN ('high', 'medium') OR (LOWER("operationname") ILIKE '%new-inboxrule%' AND LOWER("params") ILIKE '%forwardto%'))
AND LOGSOURCETYPENAME(devicetype) NOT IN ('SIM Audit', 'Custom Rule Engine')
ORDER BY "RiskScore" DESC, "EventTime" DESC
LAST 24 HOURSQRadar AQL detection for Spearphishing Service (T1598.001). SQL-like syntax queries the QRadar events store, correlating log source telemetry with risk scoring to surface reconnaissance and attack patterns. Filters out noise from internal SIM and rule engine log sources.
Data Sources
Required Tables
False Positives & Tuning
- Employees logging in from personal devices, travel locations, or via commercial VPNs generating high-risk sign-in events in Azure AD Identity Protection
- Legitimate inbox forwarding rules created by users to route work email to personal accounts in BYOD environments where this is policy-permitted
- IT helpdesk-initiated MFA resets during support tickets generating security info change audit events under the user's context
- Corporate travel to new countries generating impossible-travel and new-ASN risk detections with no malicious activity
Other platforms for T1598.001
Testing Methodology
Validate this detection against 4 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.
- Test 1Inbox Forwarding Rule Creation — Post-Credential-Harvest Persistence
Expected signal: Office 365 Unified Audit Log within 5-15 minutes: Operation=New-InboxRule with [email protected] and Parameters containing [email protected]. OfficeActivity table in Microsoft Sentinel ingests this event. Azure AD Audit Log may also show an Exchange Online service action on behalf of the user.
- Test 2MFA Security Info Modification — Post-Harvest Account Takeover
Expected signal: Azure AD Audit Logs within 2-5 minutes: OperationName=User registered security info with TargetResources showing the test user's UPN and the new method type. AuditLogs table in Microsoft Sentinel ingests this. InitiatedBy will show the admin account performing the action on behalf of the target user.
- Test 3Social Media OSINT Reconnaissance — Pre-Spearphishing Target Research
Expected signal: No telemetry on victim network — this activity occurs entirely on adversary infrastructure and illustrates why T1598.001 generates zero direct victim-side indicators. If your organization has external brand monitoring (ZeroFox, Constella, Social Links), a mass enumeration of LinkedIn profiles may trigger a brand monitoring alert. DNS queries from the test system to linkedin.com will appear in recursive DNS logs if DNS logging is enabled.
- Test 4Credential Harvesting Page Deployment — Phishing Infrastructure Simulation
Expected signal: If test users click the phishing link: proxy logs (CommonSecurityLog or web proxy sourcetype) show HTTP GET to the phishing page URL and HTTP POST with form data (captured credential submission). If DNS filtering is deployed, DNS queries to the phishing domain may be blocked and logged. If DLP is monitoring for password-pattern HTTP POSTs to non-corporate domains, a DLP alert fires. GoPhish dashboard records click timestamps and submitted credentials for campaign reporting.
References (10)
- https://attack.mitre.org/techniques/T1598/001/
- https://threatpost.com/facebook-launching-pad-phishing-attacks/160351/
- https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection
- https://learn.microsoft.com/en-us/microsoft-365/security/defender/advanced-hunting-signinlogs-table
- https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema
- https://learn.microsoft.com/en-us/microsoft-365/compliance/audit-mailboxes
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1598.001/T1598.001.md
- https://www.microsoft.com/en-us/security/blog/2022/11/03/how-microsoft-threat-intelligence-center-tracks-north-korean-threat-actor-zinc/
- https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-335a
- https://github.com/gophish/gophish
Unlock Pro Content
Get the full detection package for T1598.001 including response playbook, investigation guide, and atomic red team tests.