Back to Home
    Use Case

    Credential Compromise and Account Takeover

    A stolen credential does not generate a failed login. It generates a successful one, from a valid account, using an approved method, against a system that user is entitled to reach. Nothing in that sequence is anomalous to a rule engine, which is why the detection has to be behavioural and the response has to be fast.

    IdentityUEBAAccount Takeover

    Why rules do not catch a valid login

    Detection logic built on signatures and thresholds asks whether an event is known to be bad. Credential misuse defeats that question by definition: every individual action is permitted, and the account performing it is legitimate. The compromise is visible only in the relationship between the actions and the person they are supposed to belong to.

    This is also why credential attacks are attractive. They require no malware, leave no file to hash, and produce authentication records indistinguishable from ordinary work until someone reconstructs the pattern. By the time that reconstruction happens manually, the account has usually been used for what it was taken for.

    The useful question is not whether a behaviour is bad. It is whether this behaviour is unusual for this entity, at this time, relative to its peers.

    Anomaly detection that asks whether an action is malicious will never flag a stolen credential. Asking whether the action is unusual for that specific account will.

    A behavioural fingerprint per entity

    Every user, device, application and service account carries a continuous behavioural fingerprint, profiled across four time dimensions: the last hour, day, week and month. That spread matters, because credential misuse frequently looks normal at one resolution and obviously wrong at another. A single out-of-hours session means little; the same account working out of hours for the first time in a month, from a source it has never used, means something.

    Peer-group analytics adds the second axis. An entity is compared against its behavioural cohort rather than only against its own history, which is what catches a newly compromised account that has no long baseline of its own, and what stops a role change from generating a fortnight of noise.

    Minor anomalies accumulate rather than expiring individually. Cumulative risk scoring across dimensions triggers an investigation when a pattern forms, so a sequence of individually unremarkable deviations does not fall below every threshold it crosses.

    • Impossible travel, where two sessions are geographically incompatible in the time between them
    • Concurrent sessions from sources that cannot plausibly be the same person
    • Source deviation, where an account authenticates from infrastructure it has never used
    • First-seen account, geography or service combination for that entity
    • Off-hours access and privileged session shape that does not match the cohort
    • Dormant account reactivation, which is one of the strongest single signals in the set

    From signal to verdict

    A behavioural signal on its own is a starting point, not a conclusion, and treating it as an alert is how identity analytics earned its reputation for noise. What determines whether it is useful is what happens in the next minute.

    AuraXP™ takes the signal and investigates it: it forms competing hypotheses, works out what evidence separates them, and queries endpoint, identity, cloud and network telemetry to test each one. Did the session do anything consistent with the user's actual role. Was there a preceding phishing interaction. Did the same source touch other accounts. Is there a device the credential has never been paired with.

    The output is a verdict with the evidence trail that produced it, an attack timeline across the affected entities, and a recommended response. Typical cycle: 60 to 120 seconds, which is the difference between catching an account takeover during the session and reading about it afterwards.

    Containing an account without breaking the person

    Identity response has an asymmetry the endpoint side does not. Disabling the wrong host inconveniences one user; disabling the wrong account can stop a shift, a trading desk or a clinical workflow, and the pressure not to act is correspondingly high. Response has to be proportional to the evidence, and it has to be reversible.

    Available actions are bounded and specific: disable the account, force a password reset, revoke active sessions, or flag the user as risky for review without interrupting them. Network and endpoint actions run alongside where the investigation warrants them, such as blocking the source or isolating a host the credential was used against.

    Which of those run automatically is a policy decision rather than a product default. Low-risk and pre-approved actions execute within 60 seconds of confirmation; anything with wider impact holds for analyst, manager or customer approval. AirWatch™ validates each action against the evidence before it executes and records why it was taken.

    Insider misuse is the same detection problem

    An account being used by an outsider and an account being misused by its owner present almost identically: valid credentials, permitted actions, unusual pattern. The behavioural model does not need to distinguish them to be useful, and in practice the same signals carry both.

    Dormant account misuse, privilege anomalies and off-hours access are elevated without manual triage. The entity relationship graph models live connections between users, devices, applications and network paths, so access that is technically permitted but structurally unusual, a service account reaching a system nothing in its cohort touches, becomes visible as a relationship rather than as an event.

    What separates the two cases is the investigation, not the detection, and that is where the evidence chain earns its place: an insider case ends in an HR and legal process where the reasoning has to survive review.

    Questions

    Frequently asked questions

    How do you detect a compromised account when every action is permitted?

    By profiling each entity's behaviour continuously across the last hour, day, week and month, and comparing it both against its own history and against its peer group. The detection asks whether the behaviour is unusual for that entity at that time relative to its cohort, not whether the action itself is prohibited.

    What is impossible travel detection?

    Flagging two authentication events that are geographically incompatible given the time between them, for example a session in one country followed forty minutes later by a session on another continent. It is one of several credential misuse signals, alongside concurrent sessions and source deviation.

    How is this different from a login anomaly rule in a SIEM?

    A rule fires on a fixed condition and has no view of whether that condition is normal for the account in question. Behavioural profiling establishes what normal is per entity and per cohort, accumulates minor deviations across time dimensions, and passes the result to an investigation that gathers corroborating evidence before anything reaches an analyst.

    Does this cover service accounts and machine identities?

    Yes. Every entity is profiled, including devices, applications and service accounts. Machine identities are often the clearer case, because their legitimate behaviour is more regular than a person's, so deviation stands out more sharply.

    What response actions are available for a compromised identity?

    Disabling the account, forcing a password reset, revoking active sessions, and flagging the user as risky for review. Network and endpoint actions such as blocking the source or isolating an affected host run alongside where the investigation supports them.

    Will it disable an executive's account on a false positive?

    Only if your policy allows it to. Which actions run autonomously and which require approval is configured per action and per risk level, and AirWatch™ validates each one against the investigation evidence before execution. High-impact identity actions typically hold for analyst or manager approval.

    Does it also cover insider threat rather than external takeover?

    Yes. The signals are largely the same, because both present as valid credentials performing permitted actions in an unusual pattern. Dormant account misuse, privilege anomalies and off-hours access are elevated without manual triage, and the evidence chain is built to survive the HR and legal review an insider case ends in.

    Next step

    See it running on your environment

    A walkthrough on your own estate, with your own detections, rather than a canned demo.