Wireless network association event recorded on a Windows host

Siemphony@siemphonyinformationalT1669unverified

Matches Microsoft-Windows-WLAN-AutoConfig EventIDs 8001-8003, AN1476's association/authentication-event bucket. MITRE's actual discriminators — an unexpected SSID, a location outside the geofence, or a device that should have no Wi-Fi at all — live in the KnownSSIDList and GeoLocationContext knobs, site-specific baselines with no field in this channel to hold them, so the rule can only confirm an association attempt happened. It is written anyway because dual-homed bridging, the mechanism MITRE names for hopping onto a target's Wi-Fi from a wired host, shows up here as a wireless association on a machine not expected to have one — a fact only the deploying analyst's host inventory can supply. UNVERIFIED — derived from MITRE ATT&CK DET0536 and never executed against logs.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

Event| where (EventID == 8001 or EventID == 8002 or EventID == 8003)

Splunk · SPL

Run this as a search.

index=* (EventID="8001" OR EventID="8002" OR EventID="8003")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (event.code == 8001 OR event.code == 8002 OR event.code == 8003)

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="3">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)(^8001$|^8002$|^8003$)</field>    <description>Wireless network association event recorded on a Windows host</description>    <mitre>      <id>T1669</id>    </mitre>  </rule></group>

At a glance

Logsource: wlan-autoconfig / windows
Level: informational
Category: wireless_network_access
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 3 Sept 2026
Rule ID: a39f5a1b-6602-4179-8a67-d0dd2293581a

ATT&CKT1669

T1669Wi-Fi Networks

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonwireless network access

wireless network accessAI draft — unreviewed

01 · What this rule detects

Any wireless network association, authentication or disconnection recorded by Windows' WLAN-AutoConfig service — EventIDs 8001, 8002 and 8003. That's it. The rule does not check which SSID was joined, where the host is, or whether the host is expected to have Wi-Fi at all. AN1476's actual discriminators — MITRE's KnownSSIDList and GeoLocationContext knobs, an unexpected SSID or a connection outside the geofenced norm — have no field on this channel to carry them; a site-specific SSID allowlist and an asset inventory live outside any single Windows event. The rule is written anyway because T1669's named mechanism, a dual-homed system bridging a wired network onto Wi-Fi, shows up here as a wireless association on a host that should have none — a fact only the deploying analyst's inventory can supply, never the event itself.

02 · Telemetry you need

Microsoft-Windows-WLAN-AutoConfig operational log, EventIDs 8001-8003.
AN1476 also lists Security 4776/4625 (account authentication) as a second

03 · How the logic works

One field, three literal values, ORed by the list form. There is no SSID, no InterfaceName, no adapter or signal-strength predicate anywhere in the selection — the rendered Sentinel query is exactly EventID == 8001 or EventID == 8002 or EventID == 8003 and nothing else. That is not an oversight; the review confirms the logsource and field are real and render clean across all four backends. It is a description of what this channel can carry, not a detection: every legitimate association a laptop makes produces the identical three-event pattern as the dual-homed pivot MITRE describes. Separating the two requires a join this rule doesn't attempt — an inventory of hosts that should never have an active WLAN adapter, evaluated downstream of this event, not inside it.

04 · Common false positives

Every normal roam. Office Wi-Fi, a conference room, a hotel, home,
Guest/BYOD onboarding. A new device intentionally associating to a
Driver resets and VPN reconnects. An adapter reset or a brief signal
Not currently listed: the review flags scheduled power-management

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from MITRE ATT&CK DET0536 and never executed against logs. The reviewer's own framing is blunt: this is "a raw feed, not a detection," until something external is joined in.
tier_2: means adding the SSID field and an allowlist, and pulling in the Security 4776/4625 authentication-failure leg AN1476 also names.
tier_3: means building the host-inventory join that actually isolates dual-homed bridging, plus authoring AN1477 and AN1478 — the Linux wpa_supplicant/NetworkManager and macOS unified-log legs of this same strategy have no rule anywhere in this corpus yet.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

This rule only earns its keep paired with an external signal: a host
Add the power-management-cycling source to falsepositives, per the
level: informational is correctly calibrated — the first falsepositives

Declared by the author

Every laptop's normal wireless behaviour — connecting at the office, roaming to a conference room, a hotel or a home network, or reconnecting after sleep or dock-undock — is this event's dominant volume by a wide margin on any estate where Wi-Fi-capable endpoints are the norm.
Guest and BYOD onboarding flows that intentionally associate a new device to a guest SSID, generating the same event with no adversarial intent.
Driver and adapter resets, VPN client reconnects, or Windows' automatic reassociation after a brief signal loss, each of which can produce a fresh 8001/8003 pair without a new physical location.

Noise checknot tested

No baseline event covers this rule’s log type (wlan-autoconfig / windows), so the rule was never evaluated. This is missing data, not a clean result — nothing was checked either way.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1669, evaluated against their — events.

Share this rule

/u/siemphony/a39f5a1b-6602-4179-8a67-d0dd2293581a

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Wireless network association event recorded on a Windows host

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it