The Log Was There. The Breach Was in It. Nobody Looked at the Right Field.

The forensic timeline told a precise story. The attacker's first successful authentication appeared in the log at 02:14 AM on a Tuesday. The account was legitimate — a service account used by the HR payroll integration. The source IP was an anonymized VPN exit node in Amsterdam. The authentication succeeded because the password hadn't been rotated in nineteen months and had been exposed in a credential stuffing database available on criminal forums since the previous spring.

Every piece of that story was in the logs. The timestamp. The source IP. The account name. The authentication success event. The geolocation of the source. All of it — logged, ingested into the SIEM, stored, and never acted on.

Over the next forty-seven days, the attacker authenticated to that account 312 times. They accessed eleven internal systems. They exfiltrated 84GB of employee data. They established persistence through a scheduled task on the HR integration server.

The authentication logs contained every session. The SIEM had ingested every event. The alerts were never written.

The Three Alerts That Would Have Caught It

Post-breach analysis of this incident identified three detection opportunities that existed in the data but were never acted on:

Alert 1: Impossible travel / geolocation anomaly

A service account used exclusively by an HR integration process — running on a server inside the corporate network — should never authenticate from an Amsterdam VPN exit node. The geolocation of the source IP was available in the authentication log. The SIEM had the data. The correlation rule that says "service accounts authenticating from consumer VPN exit nodes are anomalous" was never written.

Alert 2: Authentication volume anomaly

This HR integration service account had authenticated an average of three times per day for the previous eight months. Over the forty-seven day breach period, it authenticated 312 times — an average of 6.6 times per day, with spikes of 20+ authentications on days when the attacker was actively working. A rule that alerts when a service account's authentication volume exceeds two standard deviations from its 30-day baseline would have fired on day one of the elevated activity.

Alert 3: New system access by established account

The service account had been accessing the same three internal systems for eight months. During the breach, it accessed eleven internal systems. Eight of those were first-time accesses for that account. A rule that alerts when an account accesses a resource it has never accessed before would have fired on the first lateral movement step.

None of these alerts required sophisticated threat intelligence. All of them required knowing what normal looks like for the specific account, and alerting when observed behaviour deviates from that normal.

Why the Alerts Weren't Written

The most common explanation for gaps like this is "we didn't know to look for it." This is partially correct and mostly incomplete.

The full explanation has four components:

1. The SIEM was configured for compliance, not detection.

Many SIEM deployments are initially scoped around compliance requirements: log retention for X years, evidence collection for Y standard, audit trail completeness for Z regulation. Compliance logging and detection logging are not the same thing. Compliance logging asks "did we record the event?" Detection logging asks "does this event indicate a threat?" The first question has a deterministic answer. The second requires building alert logic against specific threat scenarios.

2. No alert development process existed.

Writing a new detection rule was informal and ad-hoc. There was no process that said "for each new class of credential-based attack documented in threat intelligence, write a corresponding detection rule and test it." Without a systematic process for translating threat knowledge into detection logic, alert coverage grows through individual initiative rather than comprehensive planning.

3. The account was not classified as requiring monitoring.

High-privilege accounts and sensitive accounts should receive enhanced logging and monitoring. Service accounts with access to payroll data are sensitive accounts. This account was not in the enhanced monitoring list because it had never been formally assessed against a data sensitivity framework.

4. Baseline behaviour had never been established.

Alerting on deviation from normal requires knowing what normal is. Baselining — the process of recording what typical authentication patterns, access patterns, and behaviour patterns look like for specific accounts and systems — requires deliberate effort upfront. Without baselines, deviation-based detection is impossible.

Building Detection That Finds This Class of Attack

Step 1: Baseline service account behaviour

For every service account with access to sensitive data, establish a 30-day baseline of:

• Authentication times (which hours does this account typically authenticate?)
• Authentication source (which systems/IPs does this account authenticate from?)
• Authentication volume (how many authentications per day is typical?)
• Resources accessed (which systems/endpoints does this account typically access?)

-- Example baseline query in SIEM (pseudo-SQL)
SELECT
  account_name,
  source_ip,
  COUNT(*) as auth_count,
  MIN(timestamp) as first_seen,
  MAX(timestamp) as last_seen
FROM authentication_logs
WHERE account_type = 'service_account'
  AND timestamp BETWEEN NOW() - INTERVAL '30 days' AND NOW()
GROUP BY account_name, source_ip
ORDER BY account_name, auth_count DESC

Step 2: Alert on geolocation anomalies for service accounts

alert if:
  account_type == "service_account"
  AND authentication_result == "success"
  AND source_ip_geolocation.country NOT IN (account_baseline.expected_countries)

Service accounts should authenticate from predictable network locations. Authentication from countries not in the account's baseline is high-fidelity.

Step 3: Alert on first-time resource access

alert if:
  account_name in (sensitive_accounts_list)
  AND resource_accessed NOT IN (account_resource_history[account_name])
  AND authentication_result == "success"

Step 4: Alert on volume anomalies

alert if:
  account_name in (service_accounts_list)
  AND daily_authentication_count > (account_baseline.avg_daily_auths + (3 * account_baseline.stddev_daily_auths))

Three standard deviations above the baseline will catch genuine anomalies while avoiding false positives from normal day-to-day variation.

The Log Fields That Matter Most (That Most Teams Don't Index)

Authentication logs contain dozens of fields. Most SIEM deployments index a subset. The fields that are most commonly NOT indexed but matter most for detecting this class of attack:

Source IP geolocation — the country, city, ASN, and whether the IP is a known VPN/proxy exit node. Standard authentication logs include the source IP. Geolocation enrichment is often a separate process that many deployments skip.

Authentication context — for service accounts, what triggered the authentication? An HR integration service should authenticate in the context of a scheduled job, not interactively.

Session duration and activity — an authenticated session that persists for eight hours with continuous activity from a service account is anomalous. Session duration is often in a different log than authentication events and requires correlation.

Credential age — when was this credential last rotated? A service account password that is 19 months old is elevated risk. This data lives in Active Directory, not in authentication logs, and requires joining data sources.

The breach was in the logs from day one. The data was there. The process for turning log data into detection intelligence — baselining, alerting on deviation, enriching with context, joining data sources — was not there. That process is detection engineering. It is the work that turns a SIEM from a log storage system into a detection system.

A SIEM without detection engineering is an expensive evidence database that tells you what happened after the fact. Detection engineering is what turns it into a system that tells you what is happening while you can still respond.