Pretexting Reconnaissance Email with Tracking Pixel / Beacon Link
Before committing to a spearphishing attachment (T1598.002) or spearphishing link (T1598.003) payload, adversaries increasingly send an innocuous, low-payload pretexting email first — a brief 'checking in', 'meeting request', or 'invoice follow-up' message with no attachment and no overt malicious link. The email instead embeds a uniquely-tokenized tracking pixel (a 1x1 image or invisible-CSS beacon) or a benign-looking beacon link, where the token is minted per-recipient. When the recipient's mail client renders the image or a human clicks the link, the beacon fires a GET request back to adversary-controlled infrastructure, confirming the mailbox is live, fingerprinting the recipient's IP address, approximate geolocation, mail client/user agent, and open time, and validating that a real human (not a sandbox or secure email gateway detonation chamber) triggered it. Star Blizzard, TA453, and TA427 have been documented using single-pixel and unique-URL tracking beacons in low-content reconnaissance emails to qualify targets and time follow-on credential-harvesting or malware-laden messages for when the mailbox is confirmed active. Because these emails carry no attachment and no overtly malicious URL pattern, they routinely pass secure email gateway and sandbox scoring; detection instead relies on correlating the low-payload email itself (via EmailEvents/EmailUrlInfo) with the subsequent beacon fetch observed in web proxy/gateway logs.
What is THREAT-Recon-PretextingReconEmailTrackingBeacon Pretexting Reconnaissance Email with Tracking Pixel / Beacon Link?
Pretexting Reconnaissance Email with Tracking Pixel / Beacon Link (THREAT-Recon-PretextingReconEmailTrackingBeacon) 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 Pretexting Reconnaissance Email with Tracking Pixel / Beacon Link, covering the data sources and telemetry it touches: Microsoft 365 Defender for Office 365 — EmailEvents, EmailUrlInfo, Web Proxy / Secure Web Gateway logs (Zscaler, BlueCoat, Forcepoint, Palo Alto), Email Gateway: Application Log Content. The queries below are rated medium severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Reconnaissance
let TrackingTokenPattern = @"[?&](uid|id|token|tid|rid|cid|pid|mid|track|beacon|open|px)=[A-Za-z0-9\-_]{8,}";
let PixelExtensions = dynamic([".gif", ".png", ".jpg", ".jpeg"]);
let FreemailDomains = dynamic(["gmail.com", "yahoo.com", "hotmail.com", "outlook.com", "protonmail.com", "tutanota.com", "icloud.com", "aol.com"]);
// Alert 1: Low-payload external email (no attachment, at most one embedded URL) carrying
// a uniquely-tokenized tracking pixel or beacon link — the pretexting recon signature
let CandidateEmails = EmailEvents
| where Timestamp > ago(7d)
| where EmailDirection == "Inbound"
| where DeliveryAction !in ("Blocked", "Junked")
| where AttachmentCount == 0
| where UrlCount <= 2
| project NetworkMessageId, Timestamp, SenderFromAddress, SenderFromDomain, SenderMailFromDomain,
RecipientEmailAddress, Subject, UrlCount, AuthenticationDetails;
CandidateEmails
| join kind=inner (
EmailUrlInfo
| where Timestamp > ago(7d)
| extend HasTrackingToken = Url matches regex TrackingTokenPattern
| extend IsPixelUrl = UrlDomain != "" and PixelExtensions has_any (dynamic([".gif", ".png", ".jpg", ".jpeg"])) and (Url endswith ".gif" or Url endswith ".png" or Url endswith ".jpg" or Url endswith ".jpeg")
| where HasTrackingToken or IsPixelUrl
| project NetworkMessageId, Url, UrlDomain, HasTrackingToken, IsPixelUrl
) on NetworkMessageId
| extend FreemailSender = SenderFromDomain in~ (FreemailDomains)
| extend SuspicionScore = toint(HasTrackingToken) + toint(IsPixelUrl) + toint(FreemailSender)
| where SuspicionScore >= 1
| extend ThreatType = "PretextingRecon_TrackingBeaconEmail"
| project Timestamp, SenderFromAddress, SenderFromDomain, SenderMailFromDomain, RecipientEmailAddress,
Subject, Url, UrlDomain, HasTrackingToken, IsPixelUrl, FreemailSender, UrlCount, SuspicionScore, ThreatType
| sort by Timestamp desc;
// Alert 2: Confirm the beacon fired — the recipient's own device generated an outbound
// request to the tracking domain shortly after the email was delivered (target validated)
let BeaconCandidates = CandidateEmails
| join kind=inner (
EmailUrlInfo
| where Timestamp > ago(7d)
| where Url matches regex TrackingTokenPattern
| project NetworkMessageId, Url, UrlDomain
) on NetworkMessageId
| project DeliveryTime = Timestamp, RecipientEmailAddress, SenderFromDomain, Url, UrlDomain;
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor has_any ("Zscaler", "BlueCoat", "McAfee", "Squid", "Forcepoint", "Palo Alto Networks")
| where isnotempty(RequestURL)
| join kind=inner BeaconCandidates on $left.RequestURL == $right.Url
| where datetime_diff('minute', TimeGenerated, DeliveryTime) between (0 .. 4320)
| extend ThreatType = "PretextingRecon_BeaconFired_TargetValidated"
| project TimeGenerated, DeliveryTime, SourceUserName, SourceIP, RequestURL, UrlDomain,
RecipientEmailAddress, SenderFromDomain, ThreatType
| sort by TimeGenerated desc Two-stage detection: (1) identifies inbound emails with no attachment and at most one embedded URL where that URL carries a unique per-recipient tracking token (query parameters like uid=, token=, tid=) or points to a raster image beacon (.gif/.png/.jpg) — the structural fingerprint of a pretexting reconnaissance email, distinct from bulk marketing tracking which typically ships alongside rich HTML content and multiple links; (2) correlates the flagged email's tracking URL against subsequent web proxy/gateway request logs within a 3-day window to confirm the recipient's device actually fetched the beacon, which validates the mailbox is live and the target has been fingerprinted ahead of a follow-on attack. Alert 2 firing is the higher-fidelity signal since it proves human interaction rather than just email delivery.
Data Sources
Required Tables
False Positives
- Legitimate email marketing and newsletter platforms (Mailchimp, HubSpot, SendGrid, Constant Contact) that embed open-tracking pixels and per-recipient click-tracking links for engagement analytics — these typically arrive at higher volume with consistent sender domains and can be allow-listed
- Sales engagement and outreach tools (Outreach.io, Salesloft, Yesware, Mixmax) used by legitimate business development teams, which embed identical per-recipient tracking pixel patterns for email-open notifications
- Calendar/meeting scheduling tools (Calendly, Doodle) that include tracking parameters in confirmation links sent to recipients
- Read-receipt and delivery-confirmation features built into legitimate CRM or helpdesk platforms (Salesforce, Zendesk, Intercom) that use similarly structured per-message tracking tokens
Sigma rule & cross-platform mapping
The detection logic for Pretexting Reconnaissance Email with Tracking Pixel / Beacon Link (THREAT-Recon-PretextingReconEmailTrackingBeacon) 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:
category: network_connection
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for THREAT-Recon-PretextingReconEmailTrackingBeacon
References (5)
- https://attack.mitre.org/techniques/T1598/002/
- https://attack.mitre.org/techniques/T1598/003/
- https://www.proofpoint.com/us/blog/threat-insight
- https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/advanced-hunting-emailurlinfo-table
- https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/advanced-hunting-emailevents-table
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.
- Test 1Low-Payload Email with Unique Tracking Token URL
Expected signal: EmailEvents record with AttachmentCount=0, UrlCount=1; EmailUrlInfo record for the tracking URL containing a uid= query parameter matching the tracking token regex.
- Test 2Tracking Pixel Beacon Fetch Simulation
Expected signal: Web proxy/gateway access log entry showing a GET request to status-updates-portal.example/px.gif with the uid= tracking parameter, timestamped shortly after the simulated email delivery.
- Test 3Bulk Freemail Sender Recon Email Without Tracking Token (Negative Control)
Expected signal: EmailEvents record with AttachmentCount=0, UrlCount=0; no EmailUrlInfo record for this NetworkMessageId.
Response Playbook
Triage
- Retrieve the full email including headers from the mail store or gateway quarantine — do not click any embedded links or allow the mail client to auto-render remote images on an analyst workstation; disable automatic image download before review
- Extract the tracking URL/pixel domain and the per-recipient token from the URL query string; check whether the domain is newly registered (WHOIS < 30 days), uses a URL shortener, or resolves to infrastructure with no legitimate business purpose
- Check SPF/DKIM/DMARC authentication results and the reply-to/return-path headers for mismatches against the claimed sender identity — pretexting emails frequently spoof or closely mimic a known contact or vendor
- Search web proxy/gateway logs for any outbound request to the tracking domain from the recipient's device around or after the email delivery time — a hit confirms the beacon fired and the target was fingerprinted
- Determine whether this is a single targeted email or part of a low-and-slow campaign: search email logs for the same tracking domain, URL path pattern, or sender infrastructure across other mailboxes over the past 30 days
- Review the recipient's role and access level — pretexting recon is frequently a precursor to BEC or targeted spearphishing against finance, executive, IT admin, or HR personnel
Containment
- Block the tracking/beacon domain at the web proxy, DNS filtering layer, and email gateway to prevent the beacon from firing for any additional recipients who have not yet opened the email
- Quarantine or purge the pretexting email across all mailboxes that received it, using Exchange Admin Center or Purview Content Search, before recipients render remote images or click the link
- If the beacon already fired (confirmed via proxy logs), treat the recipient as a validated, fingerprinted target and increase monitoring for follow-on spearphishing attachment/link or BEC attempts against that mailbox for the following 30 days
- Add the sender domain and tracking infrastructure indicators to the email gateway and threat intelligence platform blocklists
Evidence Collection
- Full email with headers exported as .eml, preserving SPF/DKIM/DMARC results and originating IP
- The tracking/beacon URL and any resolvable image asset, submitted to URLscan.io or a sandboxed browser to observe the exact beacon request and response without revealing the analyst's real IP/user agent
- Web proxy/gateway log entries showing the outbound request to the tracking domain: source IP, user agent, timestamp relative to email delivery
- Exchange/O365 Message Trace and Unified Audit Log entries for the NetworkMessageId — delivery path and any MessageOpened/read activity
- WHOIS and passive DNS history for the tracking domain and any associated infrastructure
Escalation Criteria
- ! Beacon confirmed fired (proxy log correlation) for a high-value target (executive, finance, IT admin) — treat as active reconnaissance against a validated live target
- ! Same tracking infrastructure or token pattern observed across multiple recipients in the organization — indicates a coordinated targeting campaign, not opportunistic spam
- ! Follow-on spearphishing attachment or link email arrives at the same recipient within days of the beacon firing — strong indicator the recon-to-attack pipeline is active and time-critical response is needed
- ! Sender infrastructure overlaps with known threat actor indicators from threat intelligence feeds
Investigation Guide
Forensic Artifacts
- >
Email headers: SPF/DKIM/DMARC results, X-Originating-IP, reply-to/return-path mismatches - >
EmailUrlInfo / EmailAttachmentInfo entries for the NetworkMessageId — confirms zero attachments and the exact embedded URL(s) - >
Web proxy/gateway access logs for the recipient's device — the outbound GET to the tracking domain, including user agent and response code - >
DNS query logs for the tracking domain around and after email delivery - >
Passive DNS and WHOIS history for the tracking/beacon domain — recently registered domains or bulletproof hosting are strong indicators
Tuning Guidance
Legitimate marketing platforms, sales engagement tools, and CRM read-receipt features all use structurally identical per-recipient tracking pixels and tokenized links, so this detection will have a meaningful false-positive rate out of the box. Build an allow-list of known-good tracking domains observed from your organization's actual marketing/sales tooling (Mailchimp, HubSpot, Outreach.io, Salesloft, Calendly, etc.) and exclude those domains from Alert 1. Prioritize triage on Alert 2 (confirmed beacon fire correlated with an external, non-allow-listed sender) since it proves live human interaction rather than just delivery, and weight further by recipient sensitivity (finance, executives, IT admins) and by whether the sender domain is newly registered or otherwise unfamiliar to the organization.
Hunting Queries
Hunt for tracking-token domains that appear across multiple recipients in the organization over the past 30 days — a single tracking domain hitting several unrelated mailboxes indicates a coordinated pretexting reconnaissance campaign rather than a single opportunistic message.
EmailUrlInfo
| where Timestamp > ago(30d)
| where Url matches regex @"[?&](uid|id|token|tid|rid|cid|pid|mid|track|beacon|open|px)=[A-Za-z0-9\-_]{8,}"
| join kind=inner (
EmailEvents
| where Timestamp > ago(30d)
| where AttachmentCount == 0
| project NetworkMessageId, SenderFromAddress, SenderFromDomain, RecipientEmailAddress, Subject
) on NetworkMessageId
| summarize RecipientCount = dcount(RecipientEmailAddress), Recipients = make_set(RecipientEmailAddress), Subjects = make_set(Subject) by UrlDomain
| where RecipientCount >= 2
| sort by RecipientCount desc index=o365 sourcetype="o365:management:activity" Workload=Exchange Operation=MessageReceived earliest=-30d
| eval HasTrackingToken=if(match(Urls, "[?&](uid|id|token|tid|rid|cid|pid|mid|track|beacon|open|px)=[A-Za-z0-9_\-]{8,}"), 1, 0)
| where HasTrackingToken=1
| rex field=Urls "(?<UrlDomain>https?://[^/]+)"
| stats dc(RecipientAddress) as RecipientCount, values(RecipientAddress) as Recipients, values(Subject) as Subjects by UrlDomain
| where RecipientCount>=2
| sort - RecipientCount Atomic Red Team Tests
Simulates delivery of a brief pretexting email containing a single link whose query string carries a unique per-recipient tracking token, with no attachment — the core structural signature this detection targets.
Command
powershell.exe -Command "$token = [guid]::NewGuid().ToString('N'); $body = \"Hi, just checking if you got a chance to review the attached update. Details here: https://status-updates-portal.example/track?uid=$token\"; Send-MailMessage -To '[email protected]' -From '[email protected]' -Subject 'Quick follow-up' -Body $body -SmtpServer 'localhost'" Cleanup
None required — no artifacts are left on the endpoint; remove the test message from the target mailbox if delivered to a live environment. Expected Telemetry
EmailEvents record with AttachmentCount=0, UrlCount=1; EmailUrlInfo record for the tracking URL containing a uid= query parameter matching the tracking token regex.
Expected Detection
Alert 1 fires: HasTrackingToken=true, SuspicionScore>=1, ThreatType=PretextingRecon_TrackingBeaconEmail.
Simulates the recipient's mail client or browser fetching the embedded tracking pixel image, generating the outbound web request that the proxy-correlation alert (Alert 2) is designed to catch.
Command
powershell.exe -Command "Invoke-WebRequest -Uri 'https://status-updates-portal.example/px.gif?uid=abcdef1234567890' -UseBasicParsing -TimeoutSec 5" Cleanup
None required — this generates only an outbound HTTP request; no local artifacts persist. Expected Telemetry
Web proxy/gateway access log entry showing a GET request to status-updates-portal.example/px.gif with the uid= tracking parameter, timestamped shortly after the simulated email delivery.
Expected Detection
Alert 2 fires: proxy log RequestURL joins to the EmailUrlInfo tracking URL within the 4320-minute (3-day) correlation window, ThreatType=PretextingRecon_BeaconFired_TargetValidated.
Sends a similar low-payload email from a freemail domain but with no tracking token and no pixel-style URL, to validate the detection does not over-fire on freemail sender alone.
Command
powershell.exe -Command "Send-MailMessage -To '[email protected]' -From '[email protected]' -Subject 'Long time no speak' -Body 'Hey, hope things are going well on your end. Lets catch up soon.' -SmtpServer 'localhost'" Cleanup
None required — no artifacts are left on the endpoint; remove the test message from the target mailbox if delivered to a live environment. Expected Telemetry
EmailEvents record with AttachmentCount=0, UrlCount=0; no EmailUrlInfo record for this NetworkMessageId.
Expected Detection
Alert 1 does not fire (no URL to join against, SuspicionScore condition unmet) — confirms the detection requires a tracking-token or pixel URL, not freemail sender alone.