Sentinel Data Ingestion Gap During a Live Investigation
Adventure Works' Sentinel workspace stopped receiving SecurityEvent logs from 200 domain controllers at 03:00. The agents show as 'Connected' in the portal, but no new events appear. A separate investigation into a suspected Kerberoasting attack is underway and depends on those logs. The workspace's daily cap was reached at 02:55 (the cap is set at the workspace level, 50 GB/day, currently at 50.2 GB). The SOC lead wants to raise the cap immediately, but the finance owner of the subscription must approve any increase above 50 GB. Meanwhile, the investigation needs the last 24 hours of 4769 events.
1. Explain why the agents show connected but no data arrives, and outline the fastest path to restore the investigation's data without violating the approval constraint.
Read the worked answer
Why connected but silent: the workspace daily cap is a workspace-level throttle. When the cap is hit, Sentinel stops ingesting new data for the remainder of the day; agents remain connected because the connection is healthy - the data is being dropped at the ingestion layer, not the agent. This is why 'Connected' is misleading.
Fastest compliant path:
- Confirm the cap state and the reset time (daily cap resets at the defined hour). Document the 50.2 GB figure.
- Do not raise the cap above 50 GB without finance approval. Instead, reduce ingestion pressure so the cap is not re-hit: identify the noisiest tables (likely SecurityEvent or a verbose custom table) and apply a data collection rule transformation to drop low-value events (e.g., filter out 4624/4634 noise) before ingestion.
- For the investigation, query the last 24 hours already ingested - the 4769 events before 02:55 are present. If the attack window falls after 02:55, pull the missing window directly from the domain controllers' local Security logs via a one-off collection script into a case evidence store, rather than waiting for the cap to reset.
- Submit the cap-increase request to finance in parallel for the next day, with the transformation as the durable fix.
2. After restoring data, how would you use the 4769 events to confirm or refute Kerberoasting, and what would you add to prevent recurrence?
Read the worked answer
Confirm/refute Kerberoasting with 4769:
- Kerberoasting requests service tickets (4769) with RC4 encryption (TicketEncryptionType 0x17) for service accounts, often in bursts from one account against many SPNs.
- Query: count 4769 by account, by TicketEncryptionType, and by target service name over the window; flag accounts requesting RC4 tickets for multiple distinct SPNs within minutes.
- Corroborate with 4768 (TGT requests) and 4624 logons from the same host, and check whether the requesting host is a workstation rather than a server.
- A confirmed pattern: one user requesting RC4 service tickets for 10+ SPNs in under 5 minutes, especially for accounts with SPNs and weak passwords.
Prevention:
- Enforce AES-only Kerberos (disable RC4) via policy where feasible.
- Rotate passwords on service accounts with SPNs to 25+ characters and move to gMSAs.
- Add a scheduled Sentinel rule for the RC4-burst pattern so detection does not depend on manual hunting.
- Fix the ingestion cap governance: set per-table caps or transformations so a single noisy table cannot starve security-critical logs, and pre-approve a defined cap-increase threshold with finance.