Defender-DeviceLogonEvents

4 ActionTypes

ActionType	Title
any	Logon activity (any)
LogonSuccess	Logon succeeded
LogonFailed	Logon failed
LogonAttempted	Logon attempted (no result yet)

any: Logon activity (any)

Table: DeviceLogonEvents

Description

Logon activity (any)

Fields #

Name	Description
`DeviceId`
`Timestamp`
`ActionType`
`LogonType`	Logon type code (2=Interactive, 3=Network, 4=Batch, 5=Service, 7=Unlock, 8=NetworkCleartext, 9=NewCredentials, 10=RemoteInteractive, 11=CachedInteractive).
`AccountName`
`AccountDomain`
`AccountSid`
`RemoteIP`
`RemotePort`
`IsLocalAdmin`
`InitiatingProcessFileName`
`FailureReason`

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

Field	Kind	Value	Rules	Vendors
`Protocol`	eq	`NTLM`	1 rule	kusto
`user`	ends_with	`$`	1 rule	elastic, kusto

Detection Rules #

View all rules referencing this event →

Kusto #

Password Spray source: Below queries detect password spray attacks using sliding window count plugin. Because of implementation of the sliding window, queries work better than the bin() usage, but may create duplicate alerts. Grouping can be used in such cases. Sentinel Query:
Potential NTLM Relay Attack to Domain Controller source: Below query detects NTLM authentication coming from Domain Controller machine accounts. This is not an expected behavior and it's an indication of NTLM relay attack.
If NTLM Relaying is done towards a Linux machine, this query won't detect that. The attacker must have access to a Linux device in that case though.

References #

Microsoft Defender XDR: advanced hunting reference https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-devicelogonevents-table
xdrinternals: XDR table schema https://xdrinternals.com/docs/microsoftxdr/devices/devicelogonevents/

LogonSuccess: Logon succeeded

Table: DeviceLogonEvents

Description

Logon succeeded

Fields #

Name	Description
`DeviceId`
`Timestamp`
`LogonType`	Logon type code (2=Interactive, 3=Network, 4=Batch, 5=Service, 7=Unlock, 8=NetworkCleartext, 9=NewCredentials, 10=RemoteInteractive, 11=CachedInteractive).
`AccountName`
`AccountDomain`
`RemoteIP`
`RemotePort`
`IsLocalAdmin`

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

Field	Kind	Value	Rules	Vendors
`EventType`	eq	`LogonSuccess`	3 rules	kusto
`EventType`	eq	`PowerShellCommand`	1 rule	kusto
`LogonType`	eq	`Network`	2 rules	elastic, kusto, sigma, splunk
`RemoteIPType`	ne	`Loopback`	2 rules	kusto
`DestinationPort`	in	`445`	1 rule	elastic, kusto
`DestinationPort`	in	`80`	1 rule	elastic, kusto, splunk
`Protocol`	eq	`NTLM`	1 rule	kusto
`TargetDomainName`	in	`PUT YOUR AD DOMAINS HERE!`	1 rule	kusto
`TargetDomainName`	in	`contoso`	1 rule	kusto
`TargetDomainName`	in	`contoso.local`	1 rule	kusto
`parent_process_name`	eq	`wsmprovhost.exe`	1 rule	elastic, kusto, splunk
`subnet`	is_null		1 rule	kusto

Detection Rules #

View all rules referencing this event →

Kusto #

Password Spraying source medium: This query detects a password spraying attack, where a single machine has performed a large number of failed login attempts, with a large number of different accounts. For each account, the attacker uses just a few attempts to prevent account lockout. This query uses the DeviceLogonEvents per machine to detect a password spraying attacks. The machine against which the password spraying is performed (can be DC, a server or even an endpoint) needs to be enrolled in Microsoft Defender for Endpoint.↳ also matches LogonFailed: Logon failed
Service Accounts Performing Remote PS source high: Service Accounts Performing Remote PowerShell. The purpose behind this detection is for finding service accounts that are performing remote powershell sessions. There are two phases to the detection: Identify service accounts, Find remote PS cmdlets being ran by these accounts. To accomplish this, we utilize DeviceLogonEvents and DeviceEvents to find cmdlets ran that meet the criteria. One of the main advantages of this method is that only requires server telemetry, and not the attacking client. The first phase relies on the DeviceLogonEvents to determine whether an account is a service account or not, consider the following accounts with logons:. Random_user has DeviceLogonEvents with type 2, 3, 7, 10, 11 & 13. Random_service_account 'should' only have DeviceLogonEvents with type 3,4 or 5.
NTLM Relay Attack source: This query searches for successful NTLM network logins where the device name contained in the NTLM authentication message contains a device that is known to MDE, but the source IP address is different from the known source IP address for that specific device. This could indicate an attacker is relaying the NTLM authentication information. To remove false positives, this query also searches for an outgoing network connection from the initiator to the attacker.

Show 2 more (5 total)

Potentially Relayed NTLM Authentication - Microsoft Defender for Endpoint source: The below query detects NTLM logons where Network Address in the logon event doesn't match the Workstation Name's IP. This indicates potentially relayed NTLM authentication. It analyzes only the logons with domain accounts having admin privileges.
Detect service account login on new device source: This detection rule tries to flag suspicious logins on devices from service accounts, for which these service accounts did not login into those devices for the last 14 days. This might indicate that the service account is compromised and is being used for lateral movement into the environment. Most service accounts have a fairly static set of devices they authenticate to. Because of this, it is easier to flag deviations for service accounts compared to user accounts. However, some service accounts are known to dynamically log into devices based on observed events (susch as the MDI service accounts). Because of this some environment specific finetuning might be needed to reduce BP detections.

References #

Microsoft Defender XDR: advanced hunting reference https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-devicelogonevents-table
xdrinternals: XDR table schema https://xdrinternals.com/docs/microsoftxdr/devices/devicelogonevents/

LogonFailed: Logon failed

Table: DeviceLogonEvents

Description

Logon failed

Fields #

Name	Description
`DeviceId`
`Timestamp`
`LogonType`	Logon type code (2=Interactive, 3=Network, 4=Batch, 5=Service, 7=Unlock, 8=NetworkCleartext, 9=NewCredentials, 10=RemoteInteractive, 11=CachedInteractive).
`AccountName`
`AccountDomain`
`RemoteIP`
`FailureReason`

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

Field	Kind	Value	Rules	Vendors
`RemoteIPType`	ne	`Loopback`	1 rule	kusto

Detection Rules #

View all rules referencing this event →

Kusto #

Password Spraying source medium: This query detects a password spraying attack, where a single machine has performed a large number of failed login attempts, with a large number of different accounts. For each account, the attacker uses just a few attempts to prevent account lockout. This query uses the DeviceLogonEvents per machine to detect a password spraying attacks. The machine against which the password spraying is performed (can be DC, a server or even an endpoint) needs to be enrolled in Microsoft Defender for Endpoint.↳ also matches LogonSuccess: Logon succeeded

References #

Microsoft Defender XDR: advanced hunting reference https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-devicelogonevents-table
xdrinternals: XDR table schema https://xdrinternals.com/docs/microsoftxdr/devices/devicelogonevents/

LogonAttempted: Logon attempted (no result yet)

Table: DeviceLogonEvents

Description

Logon attempted (no result yet)

Fields #

Name	Description
`DeviceId`
`Timestamp`
`LogonType`	Logon type code (2=Interactive, 3=Network, 4=Batch, 5=Service, 7=Unlock, 8=NetworkCleartext, 9=NewCredentials, 10=RemoteInteractive, 11=CachedInteractive).
`AccountName`
`RemoteIP`

References #

Microsoft Defender XDR: advanced hunting reference https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-devicelogonevents-table
xdrinternals: XDR table schema https://xdrinternals.com/docs/microsoftxdr/devices/devicelogonevents/

`j` / `k`	Scroll down / up
`d` / `u`	Half-page down / up
`gg` / `G`	Top / bottom
`h` / `l`	History back / forward
`f`	Follow link (`Shift` = new tab)
`/`	Focus search
`?`	Toggle this help
`↑` / `↓`	Navigate search results
`Enter`	Open highlighted result
`Esc`	Close results / dialog

`type:`	`events` / `rules` / `providers`
`vendor:`	`sigma` / `elastic` / `splunk` / `kusto` / `chronicle` (vendor name alone also works: `sigma:`, `kql:`, `secops:`…)
`tactic:`	TA-id, slug, or name: `credential_access`, `TA0006`
`technique:`	technique or sub-technique ID: `T1003`, `T1003.001` (alias `tech:`)
`severity:`	`critical` / `high` / `medium` / `low` / `informational` (alias `sev:`)
`risk_score`	Numeric comparison on the Elastic risk score (0 to 100): `risk_score>50`, `risk_score<=20`, `risk_score=99` (alias `risk`; Elastic rules only)
`stages:`	Rules with exactly N pipeline stages
`correlation:`	`single_event` / `sequence` / `alternatives` / `alternatives_cross_log` / `all_required` / `correlated`
`with:`	Co-occurrence event-id; stacks (`with:4624 with:4769`) to require all, while a comma list in one occurrence (`with:4624,4769`) is an either-or group. Implies multi-event
`like:`	Structural neighbors of a rule slug (equivalents + subsumption stricter / broader): `like:comsvcs_lsass_memory_dump-splunk-sysmon`
`groupby:`	Entity-grouping substring match against `group_by_keys`: `groupby:user`, `groupby:host`
`uses:`	Rules whose predicate tree touches the field (any kind, any value): `uses:CommandLine`
`excludes:`	Rules with top-level `not()` clauses on the field (FP whitelists): `excludes:ParentImage`
`field:` / `value:`	Predicate search; narrows rule cards to those with a matching leaf and drives the indicator tier. Unquoted = substring, wildcards allowed (`value:mimikatz`)
`indicator:`	Shorthand for `field:F value:V`: `indicator:Image=*\powershell.exe`
`kind:`	Filter by predicate kind. Narrows rule cards to those carrying a matching predicate leaf (`vendor:elastic kind:cidr_match`) and drives the indicator tier: `contains` / `starts_with` / `ends_with` / `regex` / `cidr` / `eq` / `in` … (operator aliases `op:`/`match:`)
`has:` / `no:`	`sample`, `field`, `notes`, `refs`, `trace`, `thirdparty`, `rule`, `pattern`, `timewindow`, `threshold`, `newterms`, `sigma`/`elastic`/`splunk`/`kusto`/`chronicle`
`-op:val`	Exclude matches; works on most operators but not `type:`/`like:`/`has:`/`no:` (use `no:<flag>` to exclude a rule flag): `tactic:execution -vendor:splunk`. Standalone `-kind:`/`-field:`/`-value:` drop every rule carrying a matching predicate leaf (`type:rules -kind:is_null`)
`field:"…"` / `value:"…"`	Quoted value = anchored exact match (also allows spaces): `value:"net user"`
`a,b`	Comma = OR inside one operator (`vendor:sigma,elastic`, `severity:high,critical`); repeating a facet merges the same way. `field:`/`value:` never split (literal commas)
`vendors:` / `stage:`	Singular and plural spellings fold to the canonical operator and value: `tactics:` = `tactic:`, `type:event` = `type:events`, `correlation:sequences` = `correlation:sequence`, `has:thresholds` = `has:threshold`
`"quoted phrase"`	Exact-match a multi-word phrase (free text)

Defender-DeviceLogonEvents

any: Logon activity (any)

Description

Fields #

Common Indicators #

Detection Rules #

Kusto #

References #

LogonSuccess: Logon succeeded

Description

Fields #

Common Indicators #

Detection Rules #

Kusto #

References #

LogonFailed: Logon failed

Description

Fields #

Common Indicators #

Detection Rules #

Kusto #

References #

LogonAttempted: Logon attempted (no result yet)

Description

Fields #

References #

Keyboard shortcuts

Search operators