Potential password in username

Status: production
Group by: "Authentication.user"
Author: Mikael Bjerkeland, Splunk
Source: github.com/splunk/security_content

The following analytic identifies instances where users may have mistakenly entered their passwords in the username field during authentication attempts. It detects this by analyzing failed authentication events with usernames longer than 7 characters and high Shannon entropy, followed by a successful authentication from the same source to the same destination. This activity is significant as it can indicate potential security risks, such as password exposure. If confirmed malicious, attackers could exploit this to gain unauthorized access, leading to potential data breaches or further compromise of the system.

MITRE ATT&CK coverage

Tactic	Techniques
Initial Access	`T1078.003` Valid Accounts: Local Accounts
Persistence	`T1078.003` Valid Accounts: Local Accounts
Privilege Escalation	`T1078.003` Valid Accounts: Local Accounts
Stealth	`T1078.003` Valid Accounts: Local Accounts
Credential Access	`T1552.001` Unsecured Credentials: Credentials In Files

Rule body splunk

name: Potential password in username
id: 5ced34b4-ab32-4bb0-8f22-3b8f186f0a38
version: 8
creation_date: '2022-05-27'
modification_date: '2026-05-13'
author: Mikael Bjerkeland, Splunk
status: production
type: Hunting
description: The following analytic identifies instances where users may have mistakenly entered their passwords in the username field during authentication attempts. It detects this by analyzing failed authentication events with usernames longer than 7 characters and high Shannon entropy, followed by a successful authentication from the same source to the same destination. This activity is significant as it can indicate potential security risks, such as password exposure. If confirmed malicious, attackers could exploit this to gain unauthorized access, leading to potential data breaches or further compromise of the system.
data_source:
    - Linux Secure
search: |-
    | tstats `security_content_summariesonly` earliest(_time) AS starttime latest(_time) AS endtime latest(sourcetype) AS sourcetype values(Authentication.src) AS src values(Authentication.dest) AS dest count FROM datamodel=Authentication
      WHERE nodename=Authentication.Failed_Authentication
      BY "Authentication.user"
    | `drop_dm_object_name(Authentication)`
    | lookup ut_shannon_lookup word AS user
    | where ut_shannon>3 AND len(user)>=8 AND mvcount(src) == 1
    | sort count, - ut_shannon
    | eval incorrect_cred=user
    | eval endtime=endtime+1000
    | map maxsearches=70 search="
    | tstats `security_content_summariesonly` earliest(_time) AS starttime latest(_time) AS endtime latest(sourcetype) AS sourcetype values(Authentication.src) AS src values(Authentication.dest) AS dest count FROM datamodel=Authentication
      WHERE nodename=Authentication.Successful_Authentication Authentication.src=\"$src$\" Authentication.dest=\"$dest$\" sourcetype IN (\"$sourcetype$\") earliest=\"$starttime$\" latest=\"$endtime$\" BY \"Authentication.user\"
    | `drop_dm_object_name(\"Authentication\")`
    | `potential_password_in_username_false_positive_reduction`
    | eval incorrect_cred=\"$incorrect_cred$\"
    | eval ut_shannon=\"$ut_shannon$\"
    | sort count"
    | where user!=incorrect_cred
    | outlier action=RM count
    | `potential_password_in_username_filter`
how_to_implement: To successfully implement this search, you need to have relevant authentication logs mapped to the Authentication data model. You also need to have the Splunk TA URL Toolbox (https://splunkbase.splunk.com/app/2734/) installed. The detection must run with a time interval shorter than endtime+1000.
known_false_positives: Valid usernames with high entropy or source/destination system pairs with multiple authenticating users will make it difficult to identify the real user authenticating.
references:
    - https://medium.com/@markmotig/search-for-passwords-accidentally-typed-into-the-username-field-975f1a389928
analytic_story:
    - Credential Dumping
    - Insider Threat
asset_type: Endpoint
mitre_attack_id:
    - T1078.003
    - T1552.001
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: access
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1552.001/password_in_username/linux_secure.log
          source: /var/log/secure
          sourcetype: linux_secure
      test_type: unit

Stages and Predicates

Stage 1: `tstats`

| tstats `security_content_summariesonly` earliest(_time) AS starttime latest(_time) AS endtime latest(sourcetype) AS sourcetype values(Authentication.src) AS src values(Authentication.dest) AS dest count FROM datamodel=Authentication
  WHERE nodename=Authentication.Failed_Authentication
  BY "Authentication.user"

Stage 2: `search`

| `drop_dm_object_name(Authentication)`

Stage 3: `lookup`

| lookup ut_shannon_lookup word AS user

Lookup table: ut_shannon_lookup
Key field: word as user

Stage 4: `where`

| where ut_shannon>3 AND len(user)>=8 AND mvcount(src) == 1

Stage 5: `sort`

| sort count, - ut_shannon

Stage 6: `eval`

| eval incorrect_cred=user

Stage 7: `eval`

| eval endtime=endtime+1000

Stage 8: `macro` (not parsed)

| map maxsearches=70 search="
| tstats `security_content_summariesonly` earliest(_time) AS starttime latest(_time) AS endtime latest(sourcetype) AS sourcetype values(Authentication.src) AS src values(Authentication.dest) AS dest count FROM datamodel=Authentication
  WHERE nodename=Authentication.Successful_Authentication Authentication.src=\"$src$\" Authentication.dest=\"$dest$\" sourcetype IN (\"$sourcetype$\") earliest=\"$starttime$\" latest=\"$endtime$\" BY \"Authentication.user\"
| `drop_dm_object_name(\"Authentication\")`
| `potential_password_in_username_false_positive_reduction`
| eval incorrect_cred=\"$incorrect_cred$\"
| eval ut_shannon=\"$ut_shannon$\"
| sort count"

Stage 9: `where`

| where user!=incorrect_cred

Stage 10: `outlier`

| outlier action=RM count

Stage 11: `search`

| `potential_password_in_username_filter`

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

Field	Kind	Values
`nodename`	eq	`"Authentication.Failed_Authentication"`
`ut_shannon`	gt	`3`

`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)

Potential password in username

MITRE ATT&CK coverage

Rule body splunk

Stages and Predicates

Stage 1: `tstats`

Stage 2: `search`

Stage 3: `lookup`

Stage 4: `where`

Stage 5: `sort`

Stage 6: `eval`

Stage 7: `eval`

Stage 8: `macro` (not parsed)

Stage 9: `where`

Stage 10: `outlier`

Stage 11: `search`

Indicators

Keyboard shortcuts

Search operators

Potential password in username

MITRE ATT&CK coverage

Rule body splunk

Stages and Predicates

Stage 1: tstats

Stage 2: search

Stage 3: lookup

Stage 4: where

Stage 5: sort

Stage 6: eval

Stage 7: eval

Stage 8: macro (not parsed)

Stage 9: where

Stage 10: outlier

Stage 11: search

Indicators

Stage 1: `tstats`

Stage 2: `search`

Stage 3: `lookup`

Stage 4: `where`

Stage 5: `sort`

Stage 6: `eval`

Stage 7: `eval`

Stage 8: `macro` (not parsed)

Stage 9: `where`

Stage 10: `outlier`

Stage 11: `search`