Network provider DLL registered in the registry

Siemphony@siemphonymediumT1556.008unverified

Registering a network provider is how NPPSPY-style credential capture is installed: mpnotify.exe hands every interactive and domain logon's cleartext password to each registered provider, so the registration itself is the earliest and cheapest thing to watch. Two writes make a provider real, and this rule is one selection for each. The first is `ProviderPath` under a service's `NetworkProvider` subkey, which names the DLL that will receive credentials — an event is kept only when the value written does not point into System32 or SysWOW64, because every provider Windows ships (ntlanman.dll, drprov.dll, davclnt.dll) lives there. The second is a write to `ProviderOrder` under `Control\NetworkProvider\Order` or its `HwOrder` twin, the ordered list a provider's service name has to be added to before Windows will load it; that leg carries no path to filter on, so it matches every rewrite of the list. This addresses MITRE's `MonitoredRegistryKeys` and `SuspiciousDLLPaths` knobs, populated here with the two key paths above and with System32/SysWOW64 as the expected-location set — MITRE names the knobs, the values are authored. Three limits are worth stating. A DLL dropped into System32 before it is registered defeats the path filter entirely, and is caught only if the operator also rewrites `ProviderOrder`; that is the main reason the order leg is kept despite being the noisier of the two. AN1598's other three arms are not attempted here — its Sysmon EventID 11 file-creation, EventID 7 module-load and EventID 10 process-access legs are separate log sources, and its `TimeWindow` knob asks for the registry write, the DLL creation and the subsequent load during logon to be correlated, which needs a cross-event join and a timeframe that Sigma models neither of. And this rule is written in the Sysmon EventID 13 vocabulary (`TargetObject`, `Details`), which is the vocabulary Sigma's `registry_set` category is shaped around; the brief maps Security EventID 4657 onto that category, but 4657 splits the key and the value name into `ObjectName` and `ObjectValueName` and carries the data in `ObjectValue`, so an estate collecting 4657 needs those fields mapped onto `TargetObject` and `Details` before this rule can match at all — turning on *Audit Registry* and the SACL will not by itself make it fire. On the Sysmon side, registry events are not collected by a bare Sysmon install and several widely used configurations filter the registry down to a short include list, so confirm `Control\NetworkProvider` and `Services\*\NetworkProvider` are in the running config before treating a quiet result as a clean one. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0580, not hand-written and not tested by its author. Any lab result is on this rule's own page.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.

DeviceRegistryEvents| where ((RegistryKey endswith "\\NetworkProvider\\ProviderPath" and not ((RegistryValueData contains "\\System32\\" or RegistryValueData contains "\\SysWOW64\\"))) or (RegistryKey endswith "\\NetworkProvider\\Order\\ProviderOrder" or RegistryKey endswith "\\NetworkProvider\\HwOrder\\ProviderOrder"))

Splunk · SPL

Run this as a search.

index=* ((TargetObject="*\\NetworkProvider\\ProviderPath" AND NOT ((Details="*\\System32\\*" OR Details="*\\SysWOW64\\*"))) OR (TargetObject="*\\NetworkProvider\\Order\\ProviderOrder" OR TargetObject="*\\NetworkProvider\\HwOrder\\ProviderOrder"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(registry.path) LIKE "*\\\\networkprovider\\\\providerpath" AND NOT ((TO_LOWER(registry.data.strings) LIKE "*\\\\system32\\\\*" OR TO_LOWER(registry.data.strings) LIKE "*\\\\syswow64\\\\*"))) OR (TO_LOWER(registry.path) LIKE "*\\\\networkprovider\\\\order\\\\providerorder" OR TO_LOWER(registry.path) LIKE "*\\\\networkprovider\\\\hworder\\\\providerorder"))

Wazuh · XML rule

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

<group name="sigma,windows,registry_set,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetObject" type="pcre2">(?i)\\NetworkProvider\\ProviderPath$</field>    <field name="Details" negate="yes" type="pcre2">(?i)(\\System32\\|\\SysWOW64\\)</field>    <description>Network provider DLL registered in the registry (1/2)</description>    <mitre>      <id>T1556.008</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetObject" type="pcre2">(?i)(\\NetworkProvider\\Order\\ProviderOrder$|\\NetworkProvider\\HwOrder\\ProviderOrder$)</field>    <description>Network provider DLL registered in the registry (2/2)</description>    <mitre>      <id>T1556.008</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_set / windows
Level: medium
Category: account_manipulation
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: f83b287a-4df6-47ef-b348-01eb9bcc01a1

ATT&CKT1556.008

T1556.008Network Provider DLL

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.

Lessonaccount manipulation

account manipulationAI draft — unreviewed

01 · What this rule detects

Windows hands every interactive and domain logon's cleartext password to each registered network provider, so registering one is a complete credential-capture install — the NPPSPY shape. This rule watches the two registry writes that make a provider real, and nothing else. A hit means someone declared a DLL as a logon credential receiver; it does not mean a password was taken. AN1598's file-creation, image-load and process-access arms are separate log sources and are not attempted here.

02 · Telemetry you need

category: registry_set / product: windows, copied verbatim from AN1598 — Sysmon EventID 13. Two prerequisites decide whether a quiet result means clean or blind. Registry events are not collected by a bare Sysmon install, and several widely used configs narrow registry capture to a short include list, so confirm Control\NetworkProvider and Services\*\NetworkProvider are in the running config. Second, the rule is written in the Sysmon vocabulary: TargetObject carries key-plus-value, Details carries the data. The brief also maps Security EventID 4657 onto registry_set, but 4657 splits those across ObjectName, ObjectValueName and ObjectValue. Turning on Audit Registry and the SACL will not make this fire — a 4657 estate needs the field mapping first.

03 · How the logic works

Two independent legs, OR-ed. selection_provider_path matches TargetObject|endswith: '\NetworkProvider\ProviderPath' — the value under a service key naming the DLL that will receive credentials. ProviderPath is a value name, not a subkey, which is why it sits at the tail of TargetObject. Alone it fires on every provider on the box, so filter_system_dll subtracts events whose Details contains \System32\ or \SysWOW64\; every provider Windows ships (ntlanman.dll, drprov.dll, davclnt.dll) lives there. selection_provider_order matches writes to \NetworkProvider\Order\ProviderOrder and its HwOrder twin — the ordered list a service name must join before Windows loads the provider. That leg has no path to filter on, so it matches every rewrite of the list. The two legs are what MITRE's MonitoredRegistryKeys and SuspiciousDLLPaths knobs ask for; the specific key paths and the System32/SysWOW64 expected-location set are the pipeline's own values. MITRE's TimeWindow knob — correlate the registry write, the DLL creation and its load at logon — is a cross-event join Sigma cannot express.

04 · Common false positives

The order leg has no filter and will dominate. The rule's own false positives lead with software that ships a provider: VPN and remote-access clients, Citrix and Horizon agents, DFS tooling, arriving estate-wide in deployment bursts. Review added one the rule does not list — HwOrder is system-maintained and gets rewritten by network binding changes, so virtual and VPN adapters appearing and disappearing, NIC driver updates and docking all produce recurring hits with no installer behind them. On a laptop fleet that is plausibly the true volume leader.
The path leg has the opposite problem: its filter is an unanchored substring on a field the adversary writes, so dropping the payload at C:\ProgramData\System32\np.dll suppresses it while the DLL sits in a fully writable directory.

05 · Detection maturity

tier_1: , and it stays there until it has been run against real data. Nothing above has touched a log line — it is analysis, not evidence.
tier_2: is a fortnight read-only, ranking hits by TargetObject and user context to learn whether HwOrder churn or installer bursts leads.
tier_3: is AN1598's remaining arms as companions — EventID 11 on the DLL write, EventID 7 on its load inside mpnotify.exe — joined under MITRE's TimeWindow downstream.

Tuning & false positivesexperimental · 4 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

Anchor the filter before deploying: \Windows\System32\, \Windows\SysWOW64\
Expect the hijack case. Overwriting the ProviderPath of a provider already in
Split the legs. Keep the path leg at medium and drop the order leg to low, or

Declared by the author

Installation and upgrade of software that ships its own network provider. VPN and remote-access clients, virtual desktop agents such as Citrix Workspace and VMware Horizon, DFS and network-drive tools, and older NetWare or Micro Focus clients all write a ProviderPath under Program Files and insert their service name into ProviderOrder. This is the loudest match this rule has, it arrives estate-wide in bursts during a deployment or an agent upgrade wave, and it is why the level sits at medium rather than high.
Machine build, imaging and sysprep. A task sequence that installs the standard agent set rewrites ProviderOrder once per product per build, so every newly provisioned host produces several matches under a task-sequence process rather than an interactive shell.
Windows feature and role changes that add or remove a provider, such as enabling or disabling the WebClient/WebDAV service or the Remote Desktop client components, which rewrite the order list without any DLL being introduced.
Repair, reinstall and rollback flows for an already-installed client, including MSI self-repair and endpoint tooling that reasserts its configuration on a schedule, each of which rewrites the same values it wrote at install time.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

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.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

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

Recordings of T1556.008, evaluated against their registry_set events.

Share this rule

/u/siemphony/f83b287a-4df6-47ef-b348-01eb9bcc01a1

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.

Network provider DLL registered in the registry

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it