New-credentials logon created by the secondary logon service

Siemphony@siemphonymediumT1550.002unverified

Matches Security 4624 logon sessions of type 9 (NewCredentials) created by the Secondary Logon service, which is the record Windows writes when a process is started under an alternate account for network use only — the local artefact of authenticating as another user without ever holding their cleartext password, and the event a hash-injection tool produces on the host it is run from. This is MITRE's LogonTypeFilter knob set here to type 9, rather than to the type 3 and type 10 that the knob's own examples name: type 3 NTLM is the target-side view, it is far noisier, and it is already the shape of the T1021 rule in this corpus, whereas type 9 fires once, on the operator's own machine, at the moment the credential is injected. The rule sees that injection and not its use — the onward SMB, WMI or service creation performed under the new session is a separate event and Sigma cannot join them — and it cannot compare the requesting account against the supplied account, which is the field pair that would actually separate an operator from an adversary. Unlike much of this corpus the rule needs no audit-policy change, since 4624 is collected by default under Logon/Logoff success, but the record exists only on the source host and never reaches a domain controller, so a fleet-wide endpoint feed is the prerequisite instead. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0409, 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.

SecurityEvent| where (EventID == 4624 and LogonType == 9 and LogonProcessName =~ "seclogo" and AuthenticationPackageName =~ "Negotiate")

Splunk · SPL

Run this as a search.

index=* (EventID="4624" AND LogonType="9" AND LogonProcessName="seclogo" AND AuthenticationPackageName="Negotiate")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (event.code == 4624 AND LogonType == 9 AND TO_LOWER(LogonProcessName) == "seclogo" AND TO_LOWER(AuthenticationPackageName) == "negotiate")

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="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4624$</field>    <field name="LogonType" type="pcre2">(?i)^9$</field>    <field name="LogonProcessName" type="pcre2">(?i)^seclogo$</field>    <field name="AuthenticationPackageName" type="pcre2">(?i)^Negotiate$</field>    <description>New-credentials logon created by the secondary logon service</description>    <mitre>      <id>T1550.002</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: lateral_movement_remote_exec
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 222885e5-e4e2-4365-a242-183cbb040ff5

ATT&CKT1550.002

T1550.002Pass the Hash

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.

Lessonlateral movement remote exec

lateral movement remote execAI draft — unreviewed

01 · What this rule detects

AN1144 correlates NTLM LogonType 3 anomalies with logon-session creation, process or service initiation, and Kerberos ticket issuance to catch both pass-the-hash and overpass-the-hash. This rule implements none of that correlation — it is a single Security 4624 event, LogonType 9 (NewCredentials), created by the Secondary Logon service. That is MITRE's LogonTypeFilter knob, but set to a value the knob's own examples never name: MITRE's description mentions "LogonType 3 for network logon, Type 10 for RDP." Type 9 is the author's choice, made because it fires once, on the operator's own machine, at the moment a credential is injected — before any onward SMB, WMI or service-creation activity, which the rule cannot join to it at all.

02 · Telemetry you need

product: windows, service: security — Security 4624, no category, and no audit-policy change needed since Logon/Logoff success auditing is on by default (unlike most of this corpus). The catch is where the record lives: NewCredentials sessions are written only on the host where the process was launched, never forwarded to a domain controller, so the prerequisite is a fleet-wide endpoint log feed, not a central security-log collector. All four backends render this rule cleanly — translations.json shows no refusals, since every field is a flat scalar comparison with no cross-field OR.

03 · How the logic works

One selection, four fields, implicitly ANDed: EventID: 4624, LogonType: 9, LogonProcessName: 'seclogo', AuthenticationPackageName: 'Negotiate'. condition: selection. seclogo is the Secondary Logon service's process name — the component runas and CreateProcessWithLogonW route through — and Negotiate is the package that mechanism uses. Together they narrow "a type 9 logon happened" down to "a type 9 logon happened via the specific API surface a hash-injection tool would call." Nothing here compares the requesting account against the account being logged on as, which the description names as the field pair that would actually separate an operator from an adversary — Sigma has no cross-field diff and none is attempted.

04 · Common false positives

The review's central finding is a coverage gap, not a noise one: only PtH that routes through the Secondary Logon service produces this record at all. impacket's psexec/wmiexec -hashes, CrackMapExec/NetExec, and mimikatz's sekurlsa::pth /impersonate (no child process) authenticate straight over the wire and create no NewCredentials session — the target sees only a plain LogonType 3. The rule covers one implementation, not the technique, though the description doesn't say so as plainly as it could. On the noise side, the review flags a level/false-positive contradiction: the rule's own first entry calls runas /netonly "the dominant source of matches by a wide margin" and "indistinguishable from an injected hash," yet ships at level: medium rather than the low that combination should imply. The review also found a silent-failure risk: raw 4624 XML frequently space-pads LogonProcessName ("seclogo "), and the rule's exact-match scalar would never satisfy that — it validates clean and matches nothing. There's no machine-account exclusion either, so SYSTEM or computer-account automation calling CreateProcessWithLogonW lands beside the interactive cases the rule is written for. The review's missed false positive: PAM session brokers (CyberArk PSM, BeyondTrust, Delinea) launch every target application under a vaulted account via CreateProcessWithLogonW, making them the highest-volume source on any estate that runs one.

05 · Detection maturity

tier_1: . Never run; the space-padding risk and the coverage gap were both found by reading the YAML against known tool behaviour, not against a log line.
tier_2: run read-only, first checking whether `LogonProcessName` arrives padded in your pipeline, then rank hits by `SubjectUserName` — expect `runas /netonly` operators and any PAM broker to dominate.
tier_3: ** build the dropped correlation as a companion — join this injection event to the subsequent network authentication it enables, inside MITRE's TimeWindow knob, and compare requesting versus supplied account per SourceAccountAnomalyThreshold — so the alert means credential misuse rather than a routine runas session.

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

Change LogonProcessName: 'seclogo' to LogonProcessName|startswith: 'seclogo' so padded values still match. Add a negated SubjectUserName|endswith: '$' filter to drop machine-account noise. Reorder or rebalance the false positives, or drop level to low — a top entry that is both highest-volume and event-indistinguishable from the attack does not support medium. State plainly that this only sees CreateProcessWithLogonW-mediated PtH and needs a companion rule on target-side LogonType 3 NTLM for wire-based tools.

Declared by the author

Administrators using runas /netonly to open a management console, an RSAT snap-in or a database client under a privileged account from an unprivileged desktop. This is the intended use of the mechanism, it is the dominant source of matches by a wide margin, and at the event level it is indistinguishable from an injected hash — which is why this rule is not rated higher.
Management tooling that offers a connect-as-a-different-user option, such as SQL client tools, remote administration consoles and deployment utilities, which request a new-credentials session on the user's behalf without anyone typing runas.
Cross-forest, workgroup and DMZ administration, where supplying credentials for network use only is the only way to reach the resource, so every routine session from an operator's workstation matches.
Build agents and developer tooling that authenticate to an internal artifact, source or package server by launching a child process under a stored service account.

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 T1550.002, evaluated against their — events.

Share this rule

/u/siemphony/222885e5-e4e2-4365-a242-183cbb040ff5

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.

New-credentials logon created by the secondary logon service

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it