Detecting T1566 Phishing

How T1566 Phishing gets an adversary into your network

Phishing (T1566) is the technique a SOC lead should expect to see first when an intrusion starts with a user rather than a vulnerability. It lets an adversary place a lure in front of a person, such as a message, link, file or call, so that the user becomes the way in. MITRE defines the Initial Access tactic, TA0001, in one line: "The adversary is trying to get into your network." T1566 is one of the techniques that serves that goal, and this page maps it to ATT&CK version 20.0, the version these detection notes target. You can read the tactic definition on the MITRE ATT&CK tactic page for Initial Access.

T1566 has four sub-techniques, and they are best understood as delivery categories: lures carried in an attachment, lures that point to a link, lures delivered through a third-party service or platform, and lures delivered by voice. Each category leaves different traces, so your monitoring needs to cover more than one platform. Confirm the sub-technique list against the version you target before you write rules, because ATT&CK releases can rename or deprecate entries. In most intrusions, a successful lure is followed by activity on an identity provider, an endpoint or a mail platform, such as a new sign-in, a process starting on a workstation or a change to mailbox rules. That follow-on activity is often where you first have enough evidence to act.

The practical decision is which of your platforms can see the lure and which can see what happens after it. Ask your mail, identity, endpoint and collaboration owners to name the logs they already retain and how long they keep them. Then check whether each category of sub-technique appears in at least one of those logs. Gaps found at this stage are cheaper to close than gaps found during an incident. The detection and response sections on this page cover how to map those logs to specific analytics and how to test them in a private cyber range.

Which telemetry reveals T1566 Phishing

This table maps the five data components named for Initial Access detection (Process Creation, Application Log Content, File Creation, Network Connection Creation and Network Traffic Content) to the signals that expose phishing, the open-source collector to use, and what to confirm for each platform. Read it as a starting point for your own log inventory, since availability depends on your identity provider, endpoint estate and network design.

Data component	Signal to look for	Open-source collector	What to confirm
Process Creation (DC0032)	Office applications or PDF readers spawning script interpreters, shells or archive utilities; macOS user-space processes launched from mail or browser attachments	Wazuh agent, Velociraptor, Sysmon on Windows	Whether process creation with command arguments is logged on each Windows, Linux and macOS fleet, and retention length
Application Log Content (DC0038)	Impossible-travel or new-device sign-ins after a user clicks a link, mailbox rule creation, forwarding changes, and OAuth consent grants to unfamiliar applications	Wazuh with vendor log integrations, Security Onion, Velociraptor artifact collection	Identity provider and mail platform log export availability, audit log tiers, and whether sign-in and consent events are included
File Creation (DC0039)	Attachments or downloaded documents written to user profile or temporary folders, followed by macro-enabled or HTML files being opened	Wazuh File Integrity Monitoring, Velociraptor, auditd on Linux	Which user directories are monitored on each platform and whether macOS quarantine attributes are captured
Network Connection Creation (DC0082)	Endpoint connections to newly registered or rare domains shortly after a message is received, or to credential-harvesting login pages	Zeek connection logs, Suricata flow records, Wazuh network telemetry	Whether DNS and outbound connection logs are retained for remote and roaming endpoints, not only office networks
Network Traffic Content (DC0085)	HTTP and TLS metadata indicating lookalike login pages, redirect chains from link shorteners, or suspicious file downloads from web sources	Suricata rules, Zeek HTTP and SSL logs, Security Onion dashboards	Whether TLS inspection is in place (it changes what content is visible) and the legal and privacy basis for it

Detection logic for phishing signals in your environment

Phishing rarely shows up as one clear event. It appears as a chain: a user opens a message, a document or link launches something unexpected, and an identity or file change follows. The cards below describe detection ideas that connect those steps, with the thresholds to tune and the benign activity that will trigger them.

Suspicious document-to-process parent chains

Alert when a document viewer, office application or PDF reader is the parent of a command interpreter, script host or unsigned binary. On Windows, use process creation telemetry and compare parent and child image names against a baseline of normal macro and add-in behavior. On macOS, look for office or archive tools spawning shells or scripting runtimes. Start with a low threshold on children that are scripting engines, then tune. False positives come from approved macro-enabled finance or reporting files and from add-ins that call helper executables.

Identity provider risky sign-in and token anomalies

Phishing often ends with a stolen credential or session token being used from new infrastructure. Correlate identity provider sign-in logs for impossible travel, new device registrations, sign-ins from unfamiliar autonomous systems, and token issuance shortly after a flagged sign-in. Set the review threshold per user group, since executives and travelling staff generate more legitimate anomalies. Expect false positives from VPN exits, mobile carriers and SSO redirects that change the apparent source address.

Mail link redirection patterns

Flag messages whose links pass through several redirect hops, URL shorteners or newly registered domains before reaching a login page. Mail gateway logs and web proxy records can show the redirect chain when the same user clicks it. Tune on the number of hops and on domain age in your own environment, and confirm what your gateway records. Legitimate marketing platforms, email tracking services and SSO bounce pages will match this pattern, so allowlist them by owner rather than by pattern alone.

File creation in user temp paths

After a user opens an attachment, many payloads write files into per-user temporary or download directories and then execute them. Use file creation telemetry to alert when an office or archive process creates an executable, script or disk image in those paths within a short window of the open event. Review the window length against your endpoint logging latency. Installers, software update helpers and developer tooling that unpack archives into temp directories are common false positives and need explicit baselines.

Sigma rules as shared detection logic

Express each signal above as a Sigma rule so the logic is portable across SIEM back ends such as Wazuh and Security Onion. Keep the rule conceptual: a log source, a selection of conditions, an exclusion list for approved business processes, and a severity level. Record the ATT&CK version the rule maps to, because technique mappings change between releases. Confirm your SIEM's Sigma converter supports the log sources you rely on before you rely on the rule in production.

How to validate that phishing detections fire

This lab-only sequence proves that each T1566 Phishing detection receives its telemetry, fires on benign emulated lures, alerts within a measured window, and leaves gaps documented as tracked work. The output is a validation record that engineers and auditors can both read.

Confirm log sources reach the analytics platform
Before any test, the detection engineer confirms that identity provider sign-in and audit logs, mail gateway or Office Suite audit logs, endpoint process creation and file creation telemetry, and proxy or web content logs from the test tenant arrive in the SIEM. Each source is checked against a written list that maps it to the ATT&CK data components used by the T1566 detection strategies, such as Application Log Content, Process Creation and File Creation. The step closes when every source shows recent events with the expected fields populated, and any missing source is logged as a blocker.
Pin the ATT&CK version and rule inventory
The detection engineer records the ATT&CK version the detections target, for example Enterprise ATT&CK 20.0, and lists every T1566 rule and sub-technique mapping in scope, including the four sub-techniques. Rules are pulled from version control with their identifiers and hashes so the test run refers to a fixed set. The step closes when the inventory is approved by the detection owner and stored with the test plan, because technique mappings can change between ATT&CK releases.
Design benign emulated phishing scenarios
The red team or purple team lead writes a small set of benign scenarios inside a dedicated test tenant and private cyber range, each tied to one sub-technique and one expected detection. Scenarios use clearly labeled, non-malicious content such as a harmless link to an internal training page or a marked test attachment that performs no action on endpoints. Illustrative example: a training lure that opens a logged landing page should generate web content and identity telemetry, but not endpoint execution. The step closes when the scenario sheet lists the expected telemetry and the approver has signed off on the scope.
Run scenarios and record detection results
The operator runs each approved scenario in the order defined in the plan, with a second person observing the test. For every scenario, the analyst records whether each mapped rule fired, the rule identifier, the alert identifier and the matched fields. Results that do not match expectations are marked as a miss, a partial match or a false positive, rather than being adjusted after the fact. The step closes when every scenario has a completed result row with the operator and observer named.
Measure time from event to alert
The analyst compares the timestamp of each scenario event in the source logs with the timestamp of the resulting alert in the case management system, then calculates the gap for each detection. The measurement method, clock source and time zone handling are written down so that repeat runs are comparable. The step closes when a time-to-alert value is recorded for every fired detection and the team agrees which values are acceptable for their response process.
Document gaps and assign remediation
Each miss, partial match, false positive or missing telemetry source becomes a tracked item with an owner, a root cause note and a proposed fix, such as a new log field, a tuned threshold or an added user training reminder for lures the detections cannot see. Gaps that depend on the mitigations Restrict Web-Based Content or User Training are noted separately so that control owners see them. The step closes when every gap has an owner and a ticket reference in the tracker.
Retain the validation record as audit evidence
The final package holds the test plan, the ATT&CK version, the rule inventory with versions, the scenario sheet, the raw result rows, the time-to-alert calculations, the gap register and the sign-off by the detection owner and security lead. The team confirms that test tenant data was handled under the agreed rules and that no live user mailboxes were used. Auditors and compliance leads can trace each claim back to a log entry and a ticket. The step closes when the package is filed in the evidence repository and the next validation date is set in the review calendar.

Preventive controls that reduce phishing success

Phishing succeeds when a message reaches a user, a link or attachment is opened, and the resulting session or process is allowed to act. The controls below break that chain at different points: content filtering, user reporting, containment of opened content, and limits on what a compromised account can reach. Each one needs a named owner and a check against your own configuration.

Restrict web-based content

ATT&CK mitigation Restrict Web-Based Content (M1021) covers controls that limit which web content, domains and downloads users can reach. For T1566 Phishing, this means email link rewriting, secure email gateways, web proxies and DNS filtering that block or warn on newly registered and known-bad domains, plus restrictions on file types downloaded from external sites. Confirm which of these controls exist, which categories they block, and whether block and warn events reach your Wazuh or Security Onion pipeline so that blocked and allowed phishing attempts are both visible to analysts.

User training and reporting

ATT&CK lists User Training as a mitigation for phishing. Confirm its identifier in the enterprise-attack 20.0 STIX bundle before citing it in a control record, because this page does not state the ID. Training is most useful when it is tied to a reporting path: staff should know how to report a suspicious message, and the mailbox or button that receives reports should feed an alert queue. Ask whether simulated phishing campaigns run, how results are used, and whether report rates are tracked alongside the detections in this page.

Application isolation and sandboxing

ATT&CK mitigation Application Isolation and Sandboxing (M1048) limits what a malicious document or link can change on an endpoint. Detonating attachments in a sandbox and isolating browser sessions for links keeps the first execution away from the user's workstation. Confirm which mail flows are sandboxed, whether macro-enabled Office files are blocked or detonated, and whether sandbox verdicts are logged with the message identifier so analysts can join them to mail and process telemetry.

User account management

ATT&CK mitigation User Account Management (M1018) limits how far a phished credential can reach. Enforced multi-factor authentication on mail and identity provider sign-ins, conditional access for risky sign-ins, and least-privilege roles keep one compromised mailbox from administering the tenant. Confirm which accounts lack multi-factor authentication, which administrative roles are assigned to daily-use identities, and whether identity provider sign-in logs reach your detection stack.

Triage and response when a phishing alert fires

The first priority when a phishing alert fires for T1566 Phishing is to decide, quickly and on the record, whether the message reached a user and whether that user took an action that matters. Start by confirming the message itself: pull the sender, envelope and header details, the subject, the URL or attachment hash, and the list of every mailbox that received a copy. Then confirm the user's identity provider sign-in events around the delivery time, because a click on a link or an opened attachment is only half the picture. A sign-in from an unfamiliar location or device after the message arrived should move the case from a mailbox issue to an identity incident. Record each finding with a timestamp in the case ticket before moving to containment, so later reviewers can see why each step was taken.

Containment depends on what the user did. If the user entered credentials on a lure page, reset the password, end active sessions and revoke refresh or session tokens in the identity provider, and require re-enrollment of multi-factor authentication if the factor could have been captured. If a file was opened on a managed endpoint, isolate that host through the EDR or Wazuh active response you already run, and avoid rebooting it so volatile artifacts remain available. Collect evidence with Velociraptor or Wazuh: running processes, recent file creation in user profile paths, browser history and persistence entries for the affected account. Confirm the exact collection set with your own runbook and platform version, since artifact names and agent capabilities differ by deployment.

Scope the incident before closing it. Search the mail platform for the same sender, subject and URL pattern across all recipients, and remove delivered copies only after legal and records owners agree on handling. Review other users who clicked, and check whether any recipient signed in from new infrastructure. Then document the decisions: who approved each containment step, what was collected, what was deliberately left unchanged, and what the lessons are for the detection rule and user training program. Mention the ATT&CK version your detections target, because technique mappings can change between releases. Ask your auditors and incident response retainer provider which evidence format they expect before the case is closed.

Rehearsing phishing detection in a private cyber range

The identity and mail tab covers the parts of the range that receive messages and record sign-in activity. The range should be isolated from production mail domains and use test tenants or self-hosted mail services with seeded test mailboxes. Benign injects are harmless messages labeled as exercise traffic, such as a simulated shared-document notice that links to a non-routable test page, plus sign-in events from unfamiliar locations generated by approved test accounts. The goal is to confirm that Application Log Content from the identity provider and mail platform reaches the Wazuh or Security Onion pipeline with usable fields.

Range setup: Build a test tenant or self-hosted mail stack, seed mailboxes, and forward authentication and mail audit logs to the collector.
Benign injects: Send labeled exercise messages and trigger sign-ins from a test location so the team can practice triage without touching real users.
Detection check: Confirm that Sigma rules for suspicious sign-ins and inbox rule changes fire on the injects and include user, source, and time fields.
Response check: Verify that the on-call analyst can disable the test account, revoke sessions, and purge the exercise message from the test mailboxes within the documented runbook.
Coverage gap review: Record which log fields were missing so the platform team can fix ingestion before the next exercise.

Confirm with your identity and mail vendors which audit events are available on your license tier and how long they are retained.

Questions SOC leads ask about T1566 detection

How do I tune phishing detections to cut false positives without missing real lures?

Start by scoping each rule to one data source and one behavior, then tune on your own mail and identity logs before alerting. Phishing detections are noisy because legitimate users open attachments, click links and sign in from new devices every day. Useful tuning levers include allowlisting known sending infrastructure through your mail gateway, suppressing alerts for trusted internal senders only when authentication results are clean, and grouping alerts by recipient and campaign so analysts review one incident instead of dozens. Run each rule in a detection-only mode for a defined review period, record every false positive with its cause, and change only one variable per tuning cycle so you can see what changed. Confirm the exact log fields your mail and identity platforms emit before you write thresholds, because field names differ between products.

How should we handle ATT&CK version changes for T1566 detections?

Name the ATT&CK version in every detection record and review mappings at each release. ATT&CK v18, released October 28, 2025, replaced detections in technique pages with detection strategies and analytics, and updated data components while deprecating some data sources. Later releases, v19 on April 28, 2026 and v20 on October 13, 2026, can rename, deprecate or revoke techniques, so a mapping that was correct for one version may need changes for the next. Keep a versioned mapping table that links each Sigma rule and analytic to its ATT&CK technique, sub-technique and data component IDs, and diff it against the STIX bundle for the version you target. The official ATT&CK updates page lists what changed in each release, so assign an owner to read it before every upgrade.

How do we measure detection coverage for phishing sub-techniques?

Coverage is the share of in-scope sub-techniques where you can show a working analytic, a tested log source and a documented response. Build the denominator from the T1566 sub-techniques that apply to your environment, then score each one as covered, partially covered or not covered. A rule that exists but has never fired against a test event counts as partially covered. Use the Enterprise STIX bundle for the version you target to pull mapped data components, and check each one against your actual log collection, since a data component that is not ingested gives you no coverage. Re-score after each rule change and after each cyber range exercise, and keep the scoring sheet as evidence for your assessors.

How do we map phishing detections to our existing Sigma rules?

Tag each Sigma rule with its ATT&CK technique and sub-technique identifiers, then check that each tag matches the version you deploy. Sigma supports ATT&CK tags in the rule metadata, which lets you filter rules by technique and generate coverage views. Map rules by the log source they read, such as mail gateway, identity provider, endpoint process creation or Office application logs, because the same behavior may appear in several sources. Where existing rules cover a general concept like suspicious attachments or macro execution, decide whether they belong under T1566 or under an execution technique, and record that decision once so reviewers stop debating it. Convert rules to your SIEM or Wazuh rule format with a pipeline, then validate each converted rule against a replayed sample event, not just a syntax check.

Which telemetry should we confirm before writing phishing detections?

Confirm that you collect the data components the ATT&CK detection strategies reference for T1566: Process Creation, Application Log Content, File Creation, Network Connection Creation, Network Traffic Content and Network Traffic Flow. Process Creation and File Creation usually come from endpoint agents on Linux, macOS and Windows. Application Log Content covers identity provider, mail and Office suite audit logs, which often need an explicit export or connector and may have short default retention. Network data depends on where your sensors sit, so check that proxy and DNS logs reach the SIEM with timestamps you can correlate. Write a short matrix of these sources against your platforms and mark any gap, because missing telemetry will look like a quiet environment rather than a blind spot.

Can our own team run T1566 detection and cyber range exercises, or do we need outside help?

Your team can run these exercises if it has owners for log collection, rule maintenance and incident response, and if it has time to rehearse. The work breaks into four parts: confirming telemetry, writing and tuning rules, building a repeatable test harness in a private range, and running response drills with clear success measures. Outside help is most useful for the first build, for a structured scope with written deliverables, or for an independent review of coverage. DeployOpen implements and hardens self-hosted open-source platforms in your own infrastructure, runs security testing and private cyber ranges, and supports these engagements under fixed scope that is agreed in writing before work starts. Ongoing tuning and continuous testing are available as retainers. Ask any provider to show how they will keep your mappings current with each ATT&CK release.

How DeployOpen builds phishing detections and range exercises

DeployOpen works on T1566 Phishing as a fixed-scope engagement that starts with a written agreement on which platforms, log sources and mail or identity systems are covered. The work moves from detection design in your own environment to rehearsal in a private cyber range, with documented results handed to your team.

How we scope

Confirm which identity provider, mail, office suite and endpoint platforms fall inside the written scope.
Inventory the telemetry you already collect, such as process creation, application logs and file creation events.
Agree which ATT&CK version the detection mappings will target, since releases can rename or deprecate techniques.
Record the four T1566 sub-techniques in scope and any that your environment does not use.

How we build

Draft detection logic in plain language, then express it as Sigma rules mapped to the data components named in ATT&CK.
Deploy and tune rules in your open-source stack, such as Wazuh, Security Onion, Suricata or Zeek, within your infrastructure.
Document expected false positives and the tuning decisions made for each log source and platform.
Map the mitigations Restrict Web-Based Content and User Training to the controls your team already operates.

How we hand over

Deliver detection documentation covering data sources, logic, validation steps and response actions for each in-scope platform.
Run rehearsal exercises in a private cyber range and record which detections fired, missed or fired late.
Provide a gap register listing open items, owners and recommended next steps agreed in the written scope.
Train your analysts on triage and escalation so the detections can be operated without DeployOpen present.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Re-validate phishing detections when ATT&CK releases change technique or sub-technique mappings.
Review rule performance and tuning after changes to mail, identity or endpoint platforms in your environment.
Confirm the support scope, response expectations and review cadence in writing before work begins.

T1566 Phishing