Simplifying User and Entity Behavior Detection

What it is

A detection-engineering methodology post from attackthesoc.com that operationalizes Florian Roth's activity-vs-state distinction for UEBA-style detections, then applies it to a concrete Shadow Credential detection against Active Directory's msDS-KeyCredentialLink (KCL) attribute.

How it works

The author splits Roth's "conditions (states)" into two working categories to structure a rule:

• State — reason backward: what activities must occur to make the state true. Alert on those activities before the state exists (early-warning).
• Condition — reason forward: what symptoms appear once the condition already exists. Alert on those symptoms (something-already-went-wrong).

The example flips designations to show both directions: e.g. for "Salesforce profile allows direct (legacy) login," symptoms would be legacy-auth entries in sign-in logs or Salesforce activity from a user who never authenticated via SSO.

Specificity (fewer false positives) is bought by correlating across different event logs/data sources, and deliberateness by justifying each rule with an explicit "Why?" (its business justification: planning + writing + testing + deploying + maintaining cost).

What to do

For the Shadow Credential case, the target state is "Anomalous credentials exist in KCL for an AD object." The Why: values in msDS-KeyCredentialLink act as persistent alternate credentials — they survive a password change, letting an attacker who added them keep authenticating as that object.

The detection logic the page states: watch Windows Event ID 5136 ("A directory service object was modified") for additions to the KeyCredentialLink attribute of a device where the write did not originate from that same device. Note that 5136 is an extremely high-volume event, especially in Windows Hello for Business (WHfB) environments — hence the correlation requirement to suppress false positives. (The post is cut off before the full rule; it stops at the WHfB caveat.)

Supporting techniques the author recommends stacking on top:

• Mind maps, waterfall modeling, and data flow diagrams to close the visibility gaps that specificity creates.
• Validation via Atomic Red Team, msInvader, and/or TTPForge.

Caveats

The fetched text ends mid-explanation ("You might see this a lot… if you're using Windows Hello for Business ("), so the complete 5136 rule and its exact correlation fields are not present here — expect to open the page for the field-level query. Out-of-the-box ML/UEBA anomaly detections (e.g. "unusual admin activity from an IP unused in 30 days") are the baseline this method is meant to improve on, not replace.