Valid Accounts

Valid accounts is what happens after credential theft or a successful brute force pays off: the attacker isn't exploiting anything anymore, they're just logging in, the same way any legitimate user does, because they now have credentials that actually work. This is precisely what makes it hard to catch. There's no malware signature to match and no anomalous process to flag, just an authentication event that is, on its face, completely normal.

This technique spans the whole intrusion, not just the beginning. The same valid-account logic that gets an attacker in the door is often what lets them move between hosts, escalate privilege, and maintain access long after the original compromise, all using credentials that were never supposed to leave the organization.

Once an attacker has a working username and password, whether from brute force, phishing, a credential dump, or a leaked breach database, they use it exactly like the account's real owner would: log in, access what that account can access, and blend into the normal flow of legitimate authentication traffic.

The giveaway is rarely the login itself. It's context around it: a login from a location, device, or time of day the real user has never used before, a login immediately following other suspicious activity elsewhere in the environment, or an account suddenly accessing resources it has no ordinary business reason to touch.

Data source: Windows Security event log logon events (Event 4624), keyed on an NTLM network logon naming a source host the account has no history on, plus paired Event 4625 failures

{
  "host": {
    "name": "WKSTN01"
  },
  "event": {
    "code": "4624",
    "action": "logged-in"
  },
  "source": {
    "ip": "203.0.113.44"
  },
  "winlog": {
    "event_data": {
      "LogonType": "3",
      "TargetUserName": "jdoe"
    }
  }
}

Prebuilt Elastic rule: Unusual Source IP for a User to Logon from

This is fundamentally a baseline problem: a valid login only stands out against what's normal for that specific account. Hunting effectively means knowing, or being able to quickly check, where and when a given account usually logs in from.

Hunting manually: filter event.code: "4624" for the account in question, and compare the source.ip and time of day against that account's recent history. A login from a new source immediately after a period of suspicious activity elsewhere, especially one tied to an account that doesn't normally travel or work remotely, is the pattern worth escalating.

Legitimate reasons for a login from an unfamiliar source are common: a user traveling, working from a new device, connecting through a VPN exit node that changes their apparent source IP, or IT staff logging into an account temporarily for support purposes.

The distinguishing signal is corroboration, not the unfamiliar source alone: does this login coincide with other suspicious activity (a preceding brute-force burst, unusual subsequent access), or does it stand entirely on its own with no other red flags. A single unfamiliar login with an otherwise unremarkable session is far more likely routine than a red flag; the same pattern immediately following a failed-logon burst from the same source is a different story entirely.

• MITRE ATT&CK T1078: Valid Accounts
• Elastic Security: Unusual Source IP for a User to Logon from

1 scenario in this catalog covers T1078. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →