◇ OpenCyber Academy
Technical · Chapter 4 · English

Chapter 4 — Reading authentication logs

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 4 — Reading authentication logs

Lesson map

Lesson 04 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Authentication events"]
  N2["Lab — counting failures"]
  N3["4.2 Lab result"]
  N4["4.3 Success after failure"]
  N5["4.4 Shared accounts"]
  N6["4.5 ATT&CK"]
  N7["Username patterns"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Authentication events"]
  N2["Lab — counting failures"]
  N3["4.2 Lab result"]
  N4["4.3 Success after failure"]
  N5["4.4 Shared accounts"]
  N6["4.5 ATT&CK"]
  N7["Username patterns"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[Learning outcomes]
    |
    v
[4.1 Authentication events]
    |
    v
[Lab — counting failures]
    |
    v
[4.2 Lab result]
    |
    v
[4.3 Success after failure]
    |
    v
[4.4 Shared accounts]
    |
    v
[4.5 ATT&CK]
    |
    v
[Username patterns]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) read authentication log entries; (2) count failures per source; (3) spot success after many failures; (4) explain why shared accounts are risky.

4.1 Authentication events

Logon attempts record user, source, time and result. Patterns in failures reveal guessing. In the portal log, each line carries the time, result, source address and username. Counting failures by source shows whether many attempts came from one place, while counting usernames shows whether one person mistyped or many names were tried. Both counts mattered when Carlos decided how to treat the parks01 case. The lab below performs the first count on synthetic data, using the threshold of 20 failures from the council's rule. It prints an ALERT line for any source at or above it.

Lab — counting failures

"""Count failed logons per source address in a synthetic log (threshold 20 in 10 minutes)."""
from collections import Counter
log = (["09:01 FAIL 198.51.100.7 jsmith"] * 3 + ["09:04 FAIL 203.0.113.80 admin"] * 46
       + ["09:05 FAIL 192.0.2.15 mbrown"] * 2 + ["09:09 OK 203.0.113.80 parks01"])
fails = Counter(line.split()[2] for line in log if line.split()[1] == "FAIL")
for src, n in fails.most_common():
    print(f"{src:15} failures={n:3} {'ALERT' if n >= 20 else 'ok'}")
ok_after = [l for l in log if l.split()[1] == "OK" and fails[l.split()[2]] >= 20]
print("success from alerting source:", ok_after)

Run with python3 lab_failed.py. Verified output:

203.0.113.80    failures= 46 ALERT
198.51.100.7    failures=  3 ok
192.0.2.15      failures=  2 ok
success from alerting source: ['09:09 OK 203.0.113.80 parks01']

4.2 Lab result

The lab counts 46 failures from 203.0.113.80, above the threshold of 20, while two other sources had 3 and 2 failures, which looks like normal typing mistakes. It also finds the 09:09 success for parks01 from the alerting source. For brevity the lab writes every one of the 46 failures against the name admin; the real portal search showed 31 different usernames, which Carlos checks separately in the SIEM. The lab's success line is what turns a failed attack into a possible compromise. Both counts, by source and by username, go into the INC-0417 case note.

4.3 Success after failure

A success from the same source after many failures is a strong sign the guessing worked. It moves the case from "attempt" to "possible compromise". A success alone is ordinary, and many failures alone are an attempt, but together from one source they suggest the attacker found a working password. For parks01 that sequence, 46 failures then a success five minutes later from 203.0.113.80, is what moved the case into confirming compromise. Carlos then checks the tablet and the session to be sure.

4.4 Shared accounts

parks01 is used by several gardeners on a shared tablet. No one person is responsible for its password, which had not changed in three years. Shared accounts are easy to guess and hard to investigate because you cannot tell which person used them. The shared account also made the investigation slower and less certain for Carlos. Carlos could not ask one person whether they had logged in at 09:09; he had to check the shared tablet instead and found it idle in the depot. Named accounts for each gardener, agreed in the lessons, remove both the guessing risk and this ambiguity.

4.5 ATT&CK

MITRE ATT&CK (Strom et al., 2018) describes adversary behaviour; the pattern here matches its brute-force technique under Credential Access. Tagging the case with the brute-force technique lets Northgate count how often it appears and check whether a rule covers it. The coverage map later shows credential guessing well covered, partly because of the rule written after INC-0417. The tag also links the case to the sharing group's warning about guessing against council portals. ATT&CK names the behaviour without saying who was behind it, which is all the SOC needs here.

Username patterns

Carlos also looks at which usernames were tried. The 46 failures used 31 different names, many of them common words such as admin, test and reception. Guessing many names with a few passwords each is a sign of automated guessing rather than a forgetful person. A single user mistyping their own password produces failures on one name only, usually spread over a few minutes. This pattern check takes seconds in the SIEM and helps decide whether the case is an attack or a help-desk call.

Worked example

Carlos records: "46 failures from 203.0.113.80 against multiple usernames 09:04, success as parks01 09:09 from same source. Likely password guessing succeeded. Recommend disable parks01 and check its activity since 09:09."

Synthetic case. The log is synthetic and created by the lab.

Errors and limits

Some sources are shared by many users (for example a mobile carrier); check before blaming one address.

Exercises

Synthesis

Count failures, look for success after failure and treat shared accounts with extra care.

Continue studying — chapter 04 of 18

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →