A Cybersecurity Guide to Detecting Living-off-the-Land Attacks with Behavioral Machine Learning

A companion to my full technical write-up on Substack, covering the models, the math, and the ways attackers fight back

In February 2024, CISA, the NSA, the FBI and their Five Eyes counterparts published a joint advisory on Volt Typhoon, a PRC state-sponsored group that had gained access to U.S. critical infrastructure networks. According to the advisory, the group had held footholds in some victim environments for at least five years.

The striking detail was how little malware was involved. The operators worked almost entirely with tools already on the machines: PowerShell, WMI, netsh, ntdsutil. Conventional indicators of compromise were largely absent. There were no malicious hashes to block and no suspicious binaries to quarantine. There was just a long series of ordinary-looking administrative commands that happened to be run by the wrong people.

This style of intrusion is called living off the land. It has moved from an advanced technique to a standard one, and it breaks the assumptions most detection tooling is built on.

Why this is so hard to catch

Every binary a living-off-the-land attacker uses is also used legitimately, often thousands of times a day. PowerShell runs login scripts. WMI powers inventory tools. Scheduled tasks run backups. A signature for any of these would fire constantly on normal activity, so the only useful signal is context: who ran the command, from where, in what order, and against which systems.

Take three commands: whoami, then net group “domain admins” /domain, then nltest /dclist. Run within a minute of each other on a workstation that has never done it before, they are a reconnaissance script. Spread across a week on a helpdesk engineer’s machine, they are a normal Tuesday. The commands are identical. Only the behavior around them differs.

Scale makes it worse. A mid-sized enterprise can generate hundreds of millions of endpoint and authentication events per day. A security team might realistically investigate a few dozen alerts in that time. If a detector scores every event, it has to be wrong less than once in ten million tries to stay within budget, and no learned model gets anywhere close to that.

What the official guidance says, and what it leaves open

The joint guidance that accompanied the Volt Typhoon advisory is clear about direction. Defenders should build behavioral baselines, use machine learning to compare current activity against them, and tune aggressively to reduce noise.

What it leaves open is how. Which models? Scored over what units? How do you set a threshold when normal variation is enormous? What happens when the attacker has been in your environment long enough to appear in your training data? And what happens when the attacker knows your baselines exist and deliberately blends in?

Those are the questions the full article tries to answer.

What the full article covers

The Substack piece is long and technical. It works through the problem from the data model up, and each part comes with the math behind it and working Python.

It starts with representation. Security logs are usually treated as rows in a table, but living-off-the-land activity only becomes visible as a path: which process spawned which, which account touched which host, in what order. The article shows how to turn raw Sysmon and Windows authentication logs into provenance graphs, and why a single suspicious command matters much less than the chain it sits in.

From there it builds the detectors. Isolation forests and autoencoders establish per-peer-group baselines, with a training method that holds up when an intruder is already hiding in the data. Transformer-based sequence models score command streams by how surprising each step is, and the article explains why the most common way of summarizing those scores can quietly hide an attack. Temporal graph neural networks, following research systems like EULER and KAIROS, look for authentication edges that shouldn’t exist.

Then it deals with the problem that sinks most behavioral programs: thresholds. Using Bayes’ theorem, extreme value theory and conformal prediction, the article quantifies why alert fatigue happens and what a defender can control about it. There’s also a result from sequential analysis that describes exactly how much detection delay a stricter threshold costs you. The answer changed how I think about where detection engineering effort should go.

The adversarial section turns the detectors against themselves. Published research has shown provenance-based detectors being evaded with a 100% success rate, without the attacker changing what they actually did. The article walks through why that works, how slow baseline poisoning drags a detector’s idea of normal upward over weeks, and which design choices hold up against an attacker who adapts.

It closes with two practical topics. The first is where large language models belong in a detection pipeline, including a prompt injection risk that most teams adding AI to their SOC haven’t considered: the attacker controls text your model reads. The second is how to evaluate any of this honestly, since the metric most papers report tends to overstate how a detector will perform in production.

Who it’s for

If you write detections, run or work in a SOC, build security products, or research machine learning for security, the article is meant for you. It assumes comfort with Python and some statistics, but every formula is explained in context, and the code is written to be read.

If you’re newer to the field, the first two sections work on their own as an introduction to why living-off-the-land attacks are so difficult and what defenders are up against.

Read the full article

The complete piece, with all the derivations, code and sources, is on my Substack: https://brianjamescurry.substack.com/p/behavioral-threat-detection-with

I write there about applied machine learning in cybersecurity. If this is a topic you care about, subscribing is the easiest way to catch the next one.

About the Author

Brian Curry is a Kansas City-based machine learning and AI strategist, marketing economist, and applied researcher. He leads Vector1, an independent research studio working on cognitive AI, causal inference, marketing economics, and knowledge engineering, with a focus on simulation-driven intelligence systems.

Over more than twenty years, Brian has led data science and analytics initiatives at enterprises ranging from $4B to $125B in revenue, including Koch Industries, Tractor Supply, Vail Resorts, Hallmark, Garmin, and AT&T. His work applies economics and causal inference to connect marketing investment to structural outcomes, operational decisions to economic value, and AI adoption to durable competitive advantage.

He is also the founder of KC AI Lab, a 1,500-member AI and ML education community in the Midwest. He lives in Kansas City and is an active part of the Kansas City community.

Research and Open-Source Projects

The modeling approach in this paper draws on PyCausalSim and Papilon.

Causal Inference and Economics

• PyCausalSim: Simulation-driven causal discovery and evaluation, using counterfactual scenarios to isolate structural drivers.
• Papilon: Complex-system simulation and optimization, with applications in media mix modeling and adaptive architectures.
• Daedalus: Causal analytics for money-flow mapping and macroeconomic tracking.
• The Autonomy Economy: A macroeconomic framework for the combined effects of rapid productivity growth and structural price deflation in an AI-automated economy.

Forecasting and Applied Modeling

• Regimecast: Time-series regime detection, structural breaks, and economic forecasting.
• CarryNet: Financial modeling for commodity carry trade analysis.
• Foodmesh-ml: Machine learning, optimization, and simulation for distributed food systems.

Cognitive AI and Semantic Architecture

• Memory-Node Encapsulation (MNE): A cognitive AI architecture and data structure for artificial episodic memory (NeoCortex-M).
• MeaningFlow: Semantic content modeling, embeddings, clustering, and coverage gap analysis.

Contact: brian@vector1.ai | GitHub @Bodhi8 | Substack

The text of this article may be shared with attribution under Creative Commons Attribution 4.0 International (CC BY 4.0). Code and models referenced here are available separately to paid subscribers.