I can get in a lot of trouble for this one, but I don’t care. Living on a boat is a gift. I don’t have much, and because of that, I can take it anywhere. During my sojourn from too far north to not south enough, I have several favorite resort marinas I like to stay at. The staff are usually amazing, though my 27-year-old boat doesn’t always fit in. Not yacht enough, but more than enough boat. Works for me. I’m not there for the dock. I’m there for the poolside bars and the fruity drinks with umbrellas in them. I got in so much trouble once when somebody asked why I don’t take Zoom calls from the cockpit or keep my camera off when I’m out on the boat. The reason is simple. I live where bikinis are appropriate wear.
Sitting at the poolside bar is a graduate course in humanity. There are the circling hormones of the scantily clad, the bathing bastions of morality among the old enough not to care anymore, and the bumbling, usually amused staff bringing service with a smile to the sunburned masses.
This is where you observe behaviors, make up stories about the people, and hypothesize their motives. My wife, with training similar to mine, loves predicting actions and behaviors. Humans with empathy are good at noticing cues that give you understanding beyond what others would think. In a place without the external social cues of clothes and jewelry and all the other trappings of modern society, people overcompensate to make sure you know who they are.
AI is hard to train to gather all the data required to find the patterns within the patterns, but it can find anomalies. Just like we do, watching the antics of others from the pool bar, sipping something without enough rum but way more ice than you’d think was required. By observing the interactions and behaviors, you can guess what does or does not belong. You just have to be looking to see.
Threat Model
The attacker in this chapter already has what most security programs are designed to prevent them from getting. They hold valid credentials, authenticated successfully, and are inside the perimeter, moving through systems with a real username and a working password, and every tool in the stack sees them as a legitimate user.
This is the attack that dominates breach statistics right now. CrowdStrike’s 2026 Global Threat Report found that 82 percent of 2025 detections were malware-free. No malware signature, no payload, no exploit code on disk. The attacker logged in with stolen credentials and operated through legitimate tools. Palo Alto’s Unit 42 incident response data from the same period showed identity weaknesses played a material role in almost 90 percent of investigations, with initial access driven by identity techniques in 65 percent of cases. The Verizon 2025 DBIR put compromised credentials as the top initial access vector at 22 percent (the 2026 edition moved vulnerability exploitation into first place, partly because Verizon split out pretexting), and IBM measured the average time to identify and contain a credential breach at 246 days.
The attacker in this threat model is usually an operator who bought credentials from an infostealer log marketplace for somewhere between 25 and 500 dollars, tested them against VPN or SSO portals, and started working. Or it is an insider, someone whose access is entirely authorized but whose intent is not. Or it is a former employee whose badge and VPN profile were never deactivated. These three look almost identical from the perspective of your log data because they all share one trait: they authenticate with valid credentials and perform actions that individually appear authorized.
The attacker operating under this model does not need speed. They benefit from patience. A compromised account that accesses one additional file share per week, downloads a few dozen files at a time, and operates during normal business hours generates log entries that are indistinguishable from routine work. The individual actions do not trigger thresholds. The pattern becomes visible only when you compare what this identity is doing today against what this identity has done over the past 90 days, and then compare that trajectory against what similar identities typically do.
The real constraint removal AI provides to this attacker is operational discipline at scale. Before AI tooling, maintaining a credible impersonation of a legitimate user across multiple systems required the attacker to understand the target’s work patterns, their typical applications, their normal data volumes. That understanding came from reconnaissance, from watching, from building a mental model of the person they were pretending to be. AI can now assist with that profiling. An attacker can feed stolen calendar data, email metadata, and org chart information into an LLM and receive a behavioral playbook for the identity they have compromised. The attacker’s dwell time extends because their behavior matches the profile of the person whose credentials they stole. Every layer, from the SIEM to the access review, sees a normal user for 246 days.
Traditional Tools
The standard security stack at a company with 500 to 1500 employees has several tools that bear on this threat, and all of them were designed to solve a different version of the problem.
The SIEM is the center of gravity. Most organizations in this range run something like Splunk, Microsoft Sentinel, Elastic, or a managed SIEM through their MSSP. The SIEM collects log data from multiple sources: Active Directory, VPN concentrators, firewalls, endpoint agents, cloud identity providers, and sometimes badge access and email systems. It stores this data, runs correlation rules against it, and fires alerts when those rules match. The correlation rules are the product of whoever set up the SIEM, whoever has maintained it since, and whatever vendor detection content ships with the platform. Most of those rules are threshold based. Five failed logins in 10 minutes. A login from a country not on the approved list. A service account authenticating interactively. These are real threats, and the rules catch them. The rules were written for an attacker who gets the password wrong, who connects from an unexpected location, who does something a service account should never do.
The identity provider adds its own detection layer. Microsoft Entra ID, Okta, and similar platforms offer risk scoring on sign in events, including impossible travel detection, unfamiliar device detection, and anomalous sign in properties. These are useful and they catch real attacks. They are also scoped to the authentication event itself. Once the attacker passes the sign in risk check, the identity provider has done its job. What the user does after authentication is someone else’s problem.
Endpoint detection and response tools watch what happens on managed devices. CrowdStrike, SentinelOne, Defender for Endpoint, and others monitor process execution, file system activity, network connections from the endpoint, and registry changes. They are built to catch malware, living off the land techniques, lateral movement tools, and known attacker toolkits. They are very good at what they do. They are not built to decide whether an authorized user’s file access pattern has shifted from engineering documentation to HR records over the past three weeks.
Access reviews happen quarterly or annually in most organizations. A manager receives a list of their direct reports’ access entitlements and certifies that each person should still have what they have. This process catches stale access, usually months after the access became stale. It does not catch an employee whose access is correctly provisioned but whose use of that access has changed in ways that indicate either a change in job duties nobody documented or preparation for data exfiltration.
Physical access control, usually a badge system like Lenel, CCURE, or Genetec, logs every door swipe, every card read, every entry and exit. Most organizations send these logs to a facility management system that nobody in security has ever looked at. The badge data sits in its own database, disconnected from everything else, recording a complete physical timeline of every employee’s daily presence that could be correlated against VPN connections, endpoint logons, and data access patterns but never is.
Email systems, whether Microsoft 365 or Google Workspace, log message volume, recipient patterns, attachment sizes, and forwarding rules. DLP rules inspect outbound email for obvious policy violations: credit card numbers, Social Security numbers, documents with classification markings. The logs themselves, the patterns of who communicates with whom and how much, are stored and ignored.
Each of these tools catches the threats it was designed to catch, and none of them is broken.
The Gap
The constraint these tools relied on was that an attacker behaving like a legitimate user would eventually do something a legitimate user would not. Log in from the wrong country. Run mimikatz. Trigger a DLP rule. Access a system they have no business touching. The detection logic across the entire stack assumes that compromise produces observable indicators that are categorically different from normal operations.
That assumption held when the attacker’s operational cost for blending in was high. Maintaining perfect impersonation of a legitimate user across authentication patterns, access patterns, data volumes, communication patterns, and physical presence required either insider knowledge or sustained surveillance. Eventually the attacker would slip by accessing a system at the wrong hour, downloading too much at once, or connecting from a location that did not match their badge swipes. The tools were tuned to catch those slips.
AI removes the cost of maintaining that discipline. An attacker using AI assistance to model the compromised identity’s normal behavior can stay within every threshold in the stack. They do not need to know where every threshold is set, because they are mimicking a pattern that was always within those thresholds. If the real user logs in between 7:30 and 8:15 AM Eastern, accesses four to six applications during a typical day, downloads fewer than 200 MB of files per session, and emails primarily within their business unit, an AI assisted attacker can replicate that pattern while slowly expanding scope. One new file share per week. Ten additional files per download session. One email forwarding rule that copies messages to a personal account.
The technical gap is cross source correlation at the individual identity level over time. Your SIEM already holds the data: VPN logs, authentication events, endpoint telemetry, email activity, and if you bothered to ingest them, badge swipes and printer logs and building access timestamps. The data is in the SIEM or in an adjacent log management system. You are paying for the storage. You are paying for the licensing. You are not using it.
The reason is human bandwidth. A security team of one to three people at a 500 person company cannot build and maintain per user behavioral baselines across six log sources. They cannot write SIEM correlation rules that say “this specific user’s file download volume has increased 40 percent week over week for three consecutive weeks while their badge access pattern shows they are arriving 45 minutes earlier than their six month average.” That rule would need to be per user, adaptive, and computed across data sources that may not even share a common user identifier. No human team at this scale can do that manually. And a commercial UEBA platform that does it automatically costs more than their entire security tooling budget. Exabeam, Securonix, and the UEBA modules inside Splunk and Sentinel need, in my experience, weeks to months of baselining, dedicated tuning by someone who understands the models, and ongoing care and feeding that a three person team cannot provide alongside everything else they do.
The data exists and the storage is paid for, yet nobody analyzes it. The attacker with stolen credentials walks through the environment for 246 days because nobody correlates the VPN connection timing against the badge swipe timing against the file access volume against the email forwarding rules. Each data source is a silo. Each silo has its own team or, more likely, no team at all. The physical security logs go to facilities. The email logs go to IT. The authentication logs go to security. And nobody looks at all of them together for a single identity over time.
AI Augmentation
What you build here is a set of scripts that pull data you already collect, compute per user behavioral profiles across those sources, and surface deviations that warrant a human look. The AI component is the part that turns raw log correlation into scored anomalies with natural language explanations your analyst can act on without reverse engineering the math.
Data ingestion and normalization. Start with the log sources you already have and can query via API. At minimum that is your identity provider (Entra ID, Okta, or Active Directory audit logs), your VPN or remote access logs, and your endpoint telemetry. If your badge access system has an API or exports to CSV, add that. If your email platform exposes audit logs for message volume and forwarding rule changes, add that. The goal is to pull, on a daily batch schedule, the subset of fields you need for each user: timestamps, source IPs, accessed resources, data volumes, and authentication events.
Write a Python script that queries each source API, normalizes the user identifier to a common key (UPN, email, employee ID, whatever you can match across systems), and writes the daily activity record to a structured format, a JSON file per user or a SQLite database. This is not a streaming system. You run it once a day, after midnight, and it produces a daily snapshot of what each user did across every data source you connected.
Baseline computation. For each user, compute rolling statistics over a configurable window, start with 30 days. The features that matter most are login time distribution (mean, standard deviation, and day of week pattern), count of distinct resources accessed per day, data volume transferred per day, count of authentication events from new devices or locations, and any binary events like forwarding rule changes or new OAuth app consents. Store these baselines as simple statistical profiles. You do not need a machine learning model for this step. Mean, standard deviation, and percentile rank within the user’s own history and within their peer group (same department, same role, same office) give you the foundation.
Anomaly scoring with AI. Take each user’s daily activity record, compare it against their 30 day baseline, and identify any feature where the current day falls outside two standard deviations from the user’s own mean or outside the 95th percentile for their peer group. For each flagged deviation, build a prompt that includes the user’s baseline statistics, the current day’s values, the specific deviation, and any corroborating deviations from other data sources. Send this to an LLM via API, whether a local model through Ollama or a cloud API call to Claude or GPT, with instructions to assess whether the combination of deviations is consistent with a change in job duties, a one off event, or a pattern that warrants investigation. Ask it to produce a risk score from 1 to 10 and a two sentence explanation.
The LLM does not make the detection decision. The statistical comparison makes the detection. The LLM provides the triage context that helps your analyst decide whether to spend 30 minutes investigating or move on. A deviation that says “user’s download volume is 3.2 standard deviations above their 30 day mean and their login time shifted 47 minutes earlier than their normal window, while their badge access shows no corresponding change in building entry time” tells the analyst something specific. It tells them the user’s VPN activity does not match their physical presence. That is worth a look.
Cross source correlation. The real power of this approach is correlations that no single tool can surface. Badge access says the user entered the building at 8:45 AM. VPN logs show an active session from their assigned IP starting at 6:30 AM. Either someone is using their credentials remotely before they arrive, or the badge system and VPN system have a data quality issue you need to fix. Both outcomes are useful. Email forwarding rules changed on the same day that the user’s file download volume doubled. A new OAuth application was consented to the same week that the user began accessing file shares outside their normal scope. Individually, none of these is alarming. Together they are, and the “together” is what no tool in the standard stack computes without custom work.
Build the correlation logic as a set of rules that fire when deviations from two or more data sources coincide for the same user within the same time window. Keep the rule set small at first. Five to ten cross source rules are enough to surface the patterns that matter. A VPN session without a corresponding badge entry. A forwarding rule change plus an increase in outbound email volume. A new device authentication plus access to a resource outside the user’s normal scope. An increase in after hours access plus an increase in file download volume.
Output and workflow. The daily output is a ranked list of users whose combined anomaly scores exceed your threshold, with the LLM’s explanation for each. Deliver this as a daily email to the security team or, better, as a ticket in your existing workflow tool. Each entry includes the user’s name, their anomaly score, the specific deviations that contributed, the cross source correlations that fired, and the LLM’s assessment. The analyst reviews the list, investigates the top entries, and marks each as confirmed anomaly, benign deviation, or false positive. Feed the false positive decisions back into the baseline computation as exceptions, so the same benign pattern does not keep surfacing.
Dependency risk. This system creates a dependency on the daily batch pipeline and on the LLM’s availability for scoring. If the pipeline breaks, you stop getting daily anomaly reports. Your fallback is the same thing you were doing before: nothing. That sounds harsh, but it is honest. If you were not doing cross source behavioral baselining before you built this, then a pipeline outage returns you to your prior state. The practical risk is that you come to rely on the daily report and stop doing manual log reviews entirely. Protect against that by keeping one manual log review task per week on the rotation regardless of whether the automated system is running.
An adversary who understands that you run this system could attempt to poison the baseline by operating within normal parameters for the first 30 days of a compromise and then gradually escalating. The defense against baseline poisoning is to run the baseline computation on a window that predates the current period by a buffer. Use days 7 through 37 for the baseline rather than days 1 through 30, so that recent activity does not immediately shift the baseline. You can also maintain a frozen baseline taken from a known clean period and compare current activity against both the rolling baseline and the frozen one. If the frozen baseline catches a deviation that the rolling baseline has absorbed, you have evidence of gradual drift that warrants investigation.
The adversary could also target the LLM itself, if you are using a cloud API, through prompt injection in log data. A username or file path containing instruction text could potentially influence the LLM’s scoring. Mitigate this by treating all log data as untrusted input in your prompts, using structured prompt templates that clearly separate the instruction from the data, and validating the LLM’s output format before accepting the score. If the output is not a number between 1 and 10 followed by two sentences, discard it and flag it for manual review.
The whole system, ingestion scripts, baseline computation, anomaly scoring, and daily report generation, is a few hundred lines of Python, a cron job, and API calls you are already paying for or can run locally. You skip the platform purchase, the 90 day deployment, and the dedicated UEBA engineer. You start getting signal from data you already own by the end of the week you build it, and every day after that, the baselines get more accurate. You already paid for the data. You just have to look at it.
Works Cited
CrowdStrike. (2026, February 24). 2026 CrowdStrike Global Threat Report: AI accelerates adversaries and reshapes the attack surface [Press release]. https://www.crowdstrike.com/en-us/press-releases/2026-crowdstrike-global-threat-report/
CybelAngel. (2026). Infostealer logs: What happens to stolen credentials after infection. https://cybelangel.com/blog/infostealer-logs-after-their-stolen-criminal-economy-data/
IBM. (2025). Cost of a data breach report 2025. https://www.ibm.com/reports/data-breach
Palo Alto Networks Unit 42. (2026, February 19). Global incident response report 2026. https://www.paloaltonetworks.com/resources/research/unit-42-incident-response-report
Verizon. (2025). 2025 data breach investigations report. https://www.verizon.com/business/resources/reports/dbir/
About the Author
