Detect Spearphishing Service in Google Chronicle
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/
YARA-L Detection Query
rule t1598_001_spearphishing_service {
meta:
author = "df00tech"
description = "Detects post-compromise indicators from spearphishing via third-party services"
mitre_attack_tactic = "TA0043"
mitre_attack_technique = "T1598.001"
confidence = "low"
severity = "medium"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.metadata.product_name = "Azure Active Directory"
$e.security_result.risk_score > 60
condition:
$e
}Google Chronicle YARA-L 2.0 detection rule for Spearphishing Service (T1598.001). Uses Unified Data Model (UDM) event field mappings to detect the same behavioral patterns as the KQL rule, with Chronicle's temporal matching and entity correlation capabilities.
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.