Account activity: j.doe
Account
- Account
- user account – works like a person (regular hours, few sources)
- Last password change
- 2026-10-10 08:41 (reset by adm.helpdesk)
- Account state in the period
- Account disabled ×1
- SIEM alerts
- 2 alerts of Windows rules for the account in the period
Verdict
Suspicious – escalate: Possible password spraying; Possible account compromise; RDP access granted (Remote Desktop Users); group memberships enumerated in bulk.
Risk score 104 (needs review from 1, suspicious from 30 with at least one high-severity finding): threats and risky changes make it; other anomalies add at most a little.
Recommendation: Check the new sources and confirm with the user whether the attempts were theirs. If a guessed password was used successfully, reset the password, revoke sessions and review what the account did afterwards. Confirm the new sources and the activity with the account owner immediately. If they are not recognised, reset the password, revoke all sessions and escalate as an incident. Confirm the listed risky changes and actions with the account owner or the administrators who made them; revert them if nobody expected them.
Risky changes and actions
- medium The account allowed RDP logon (Remote Desktop Users): Member added: svc-backup at 2026-10-10 02:19. ATT&CK T1098.007 Additional Local or Domain Groups ↗
What to do
- Find the change ticket or ask the administrator who made it.
- Not approved: revert the change and escalate to L2.
- Check the RDP logons (logon type 10) that followed.
- medium Group memberships enumerated in bulk (up to 6 local groups or 0 user lookups in one hour): typical of BloodHound, SharpHound or net localgroup scripts. Open in SIEM ↗ ATT&CK T1069.001 Permission Groups Discovery: Local Groups ↗
What to do
- Identify the process and host that read the group memberships.
- BloodHound / SharpHound without an approved test: escalate.
H3 Possible password spraying high severity high confidence Open in SIEM ↗ ATT&CK T1110.003 Password Spraying ↗
- 2 new sources with wrong-password or unknown-account attempts in the recent days: 10.8.4.33 (VPN: r.roe), WIN-K3J8Q2.
- Successful authentication right after a series of failures from a new source: 10.8.4.33 (VPN: r.roe), WIN-K3J8Q2.
- 1 of the 2 sources are in VPN (10.8.0.0/16).
- 10.8.4.33: VPN session of r.roe at that time (another person's device).
- The same sources tried wrong passwords on many other accounts too: WIN-K3J8Q2 (11 accounts). A spraying attack tries a few common passwords on many accounts; check which of them succeeded.
What to do
- Open the triggering events: wrong passwords or unknown accounts, and from which sources.
- Identify the sources (inventory, DHCP, VPN). Unknown or external: block them at the firewall or VPN.
- Check whether a success from the same sources followed (timeline right after the failures).
- A guess succeeded: reset the password, revoke sessions and escalate to L2.
H4 Possible account compromise high severity high confidence Open in SIEM ↗ ATT&CK T1078.002 Valid Accounts: Domain Accounts ↗
- 2 new sources authenticated successfully; 2 of them together with signs of an attack on the account (password guessing from the same source just before, RDP from it or new processes right after):
- 10.8.4.33: successful logon at 2026-10-10 01:00, right after 60 wrong-password or unknown-account attempts from it (bad password (Kerberos) ×36, bad password ×24; 01:00–02:00), during normally quiet hours, over remote interactive (RDP) logon.
- WIN-K3J8Q2: successful logon at 2026-10-10 01:00, right after 48 wrong-password or unknown-account attempts from it (bad password ×48; 01:00–02:00), during normally quiet hours, over remote interactive (RDP) logon.
- 1 of the 2 sources are in VPN (10.8.0.0/16).
- 10.8.4.33: VPN session of r.roe at that time (another person's device).
What to do
- Call the user and confirm the logon from the source and at the time shown in the evidence.
- Check the source host in the inventory or EDR: whose machine is it, is it managed?
- Not confirmed: disable the account or reset its password, revoke sessions, escalate to L2.
- Review what the account did after that logon (click the time to filter the report to that hour).
H1 Stale credentials medium confidence
- 86 failed authentications, 100% of them with a wrong password.
- Failures on 3 days (2026-09-18 – 2026-10-10).
- Failure sources: 10.8.4.33 (VPN: r.roe) (60), WIN-K3J8Q2 (48), 10.20.1.42 (2).
What to do
- Find the device or service in the failure sources (click a source in the activity flow).
- Ask the owner which devices and services use the account: phone mail, mapped drives, services, scheduled tasks.
- Update the stored password there; the failures should stop within an hour.
- No source found: check where the failures were recorded (4625) and the NPS calling station.
Observations
- 1 Kerberos TGTs used RC4 encryption (weak protocol or setting).
- 3 service tickets used RC4 encryption (weak protocol or setting).
- 1 new VPN addresses had only this account's own VPN sessions in the period: its own device over VPN, not counted as new sources.
The verdict covers the whole period; the filters below narrow the charts and tables.
Anomalies
The 7 investigated days compared with the 23 baseline days before them, for the same account. Click an anomaly to filter the report to it.
10 anomalies (8 medium, 2 low) — click to show
- medium The account allowed RDP logon (Remote Desktop Users): Member added: svc-backup at 2026-10-10 02:19. ATT&CK T1098.007 Additional Local or Domain Groups ↗
- medium Group memberships enumerated in bulk (up to 6 local groups or 0 user lookups in one hour): typical of BloodHound, SharpHound or net localgroup scripts. Open in SIEM ↗ ATT&CK T1069.001 Permission Groups Discovery: Local Groups ↗
- medium New source 10.8.4.33: 69 events in the recent days (9 successful, 60 failed) in Successful logon (4624), Failed logon (4625), Kerberos TGT request (4768), Kerberos service ticket request (4769), Kerberos pre-authentication failure (4771); never seen in the baseline. Address in the VPN network (10.8.0.0/16). At its first use it was the VPN session of r.roe. Open in SIEM ↗
- medium New source WIN-K3J8Q2: 54 events in the recent days (6 successful, 48 failed) in Successful logon (4624), Failed logon (4625), NTLM credential validation (4776); never seen in the baseline. Open in SIEM ↗
- medium New logon type 10 in Successful logon (4624): 1 events in the recent days (1 successful, 0 failed), never seen in the baseline. Open in SIEM ↗
- medium 24 failed Failed logon (4625) in hours that are normally quiet (00:00–07:00, 17:00–20:00, 23:00–24:00); about 0 expected.
- medium 36 failed Kerberos pre-authentication failure (4771) in hours that are normally quiet (00:00–07:00, 17:00–20:00, 23:00–24:00); about 0 expected.
- medium 24 failed NTLM credential validation (4776) in hours that are normally quiet (00:00–07:00, 17:00–20:00, 23:00–24:00); about 0 expected.
- low VPN session over a new internet provider: Example Mobile PL (Warsaw, Poland) at 2026-10-07 20:03; not seen in the baseline. Open in SIEM ↗
- low New service SRV-APP03$ in Kerberos service ticket request (4769): 3 events in the recent days (3 successful, 0 failed), never seen in the baseline. Open in SIEM ↗
VPN sessions
5 sessions of the account in the period (1 in the investigated days) from 1 countries over 2 providers (VPN gateway logs); on the timeline they are the shaded periods. Marked: a country or provider not seen in the baseline. Click a row to filter the report to its VPN address and time; “Open” shows the session's VPN gateway events in the SIEM.
Sessions (5, 1 marked)
| Start | Duration | Place | Provider | Public address | VPN address |
|---|---|---|---|---|---|
| 2026-10-07 20:03 | 2 h 29 min | Warsaw, Poland new provider | Example Mobile PL | 203.0.113.150 Open ↗ | 10.8.4.35 |
| 2026-09-29 20:13 | 2 h 31 min | Warsaw, Poland | Example Telecom PL | 203.0.113.24 Open ↗ | 10.8.4.27 |
| 2026-09-25 20:14 | 2 h 35 min | Warsaw, Poland | Example Telecom PL | 203.0.113.24 Open ↗ | 10.8.4.23 |
| 2026-09-21 20:19 | 2 h 16 min | Warsaw, Poland | Example Telecom PL | 203.0.113.24 Open ↗ | 10.8.4.19 |
| 2026-09-17 20:07 | 2 h 36 min | Warsaw, Poland | Example Telecom PL | 203.0.113.24 Open ↗ | 10.8.4.15 |
SIEM alerts
Alerts of Windows rules in the period whose matched event names the account.
2 alerts: Windows - Kerberos pre-authentication failures ×1, Windows - RDP logon at night ×1
Show the alerts (click a time to filter the report to that hour)
| Time | Rule | Event | Engine finding |
|---|---|---|---|
| 2026-10-10 01:58 | Windows - RDP logon at night | 4624 | high – RDP logon of j.doe at 01:58 from a source first seen the same night Open ↗ VPN session of r.roe at that time |
| 2026-10-10 01:40 | Windows - Kerberos pre-authentication failures | 4771 | medium – 36 failed Kerberos pre-authentications for j.doe in 20 minutes from the VPN session of r.roe Open ↗ VPN session of r.roe at that time |
Activity timeline
Hourly events by type and result. Click a bar to filter by that event and result; drag or scroll to zoom. Markers on the top lane are changes of the account (hover for details).
Activity flow
Who authenticated from where, how and to what; processes started on the domain controllers; directory actions. Orange: new compared with the baseline; red: mostly failures; boxes: detections. Click a node to expand or collapse it, double-click to filter the report by it (with Shift: hide it); scroll to zoom and drag to move.
What to do
Working rhythm
Activity by event
Click a row to filter by the event. The days shown follow the switch in the menu.
Details by event
The days shown follow the switch in the menu. + / − next to an event show only it or hide it in the whole report; click the rest of the event's header to expand or collapse it. Click a value to show only it, or − to hide it. A filter's +/− switches it between the two.
Changes
Click a time to filter the whole report to one hour around the change; click a change type, result, author, object or group member to filter these lists. The filters and the search above also apply here.
Changes of the account (2)
Password changes and resets (the whole period, at least 90 days back) (2)
Changes made by this account to other accounts and groups (1)
Scope and limitations
- Demo report generated from synthetic data. What a real report covers depends on the log sources configured in the SIEM.
- Anomalies compare the investigated days with the baseline days of the same account only; a short or unusual baseline makes them less reliable.
- Event types without a definition are shown with fields found in a sample of the account's events and take part in the timeline, filters and flow, but not in the hypotheses.