Beyond the Basics: Advanced Insider Threat Detection

Insider risk programs are deceptively hard to get right. Building one that actually reduces risk — rather than just performing security theater — means aligning executive sponsorship, a multidisciplinary stakeholder team (e.g. legal, information security, law enforcement), the technical telemetry to proactively hunt threats, and a formalized incident response plan to contain them. And telemetry alone isn’t enough — it takes skilled analysts who can investigate the signal, decipher intent, and tell a genuine threat from ordinary noise.¹ A smaller organization may genuinely struggle to stand one up, but a large, well-resourced one has little excuse not to build it properly from the ground up.

Most insider risk conversations start — and often stop — with the classics: the employee logging in at 3 a.m., the sudden spike in file downloads, the badge swipe at a building someone has no reason to be in. Those fundamentals are genuinely valuable and worth getting right first. But they’re also the patterns everyone watches for, which means they’re the ones a determined insider learns to avoid. In the rest of this post, I want to share a few sharper, more technical techniques that go beyond the usual behavioral cues — the kind of signals that are harder to see.

Identifying the “Crown Jewels”

If your house caught fire, what would you grab? Nobody grabs the couch. You grab the people, the pets, the passports, the photos. That instant list is your crown jewels — what you’ve decided is worth saving when time and resources run short. Organizations face the same struggle. If you try to protect it all, you protect nothing well.¹

But every organization defines its crown jewels differently. A defense contractor might point to its engineering blueprints; an AI company, to its model weights. The specifics vary by who you are and what you do, but the question never changes: what would hurt the most to lose?

Once you know what you’re protecting, you scope your resources strategically to ensure proper systems are in place to guard the things that matter most. For the rest of this post, we’ll focus from a data perspective, since it’s something relatable to most large organizations.

The Signal a VPN Can’t Hide

Technique: Wi-Fi Positioning / BSSID Geolocation

Say your company operates only in the US, and policy says corporate laptops stay in-country. How do you catch someone who quietly took theirs overseas — worse, to an adversarial country?

IP geolocation is the obvious answer, and the easy one to beat. A VPN or residential-proxy tunnel lets someone appear to sit in Ohio while they’re really on the other side of the world. IP tells you where their traffic exits, not where the device is.

But assume the laptop is a managed endpoint already collecting the wireless networks in radio range. Every access point broadcasts a BSSID (a unique hardware address), and those APs generally are static. WiGLE — a crowd-sourced database of over a billion wireless networks mapped to GPS coordinates — has spent years cataloging where they physically live. Match the BSSIDs the device sees against WiGLE, and you get its real location, whatever its IP claims. The VPN says “Ohio”; the three access points in range all resolve to a city block somewhere your company has no business operating. The traffic lied; the airwaves didn’t.

Why it holds up: VPNs and proxies manipulate routing — they do nothing to the RF environment around the device. And while MAC randomization protects phones, the infrastructure BSSIDs you’re matching belong to fixed access points, so they stay put as reliable landmarks. Treat a hit as a strong lead to corroborate, not proof — and scope this to managed corporate devices with legal in the loop, since tracking device location touches real privacy obligations.

The Outlier on the Team

Technique: Peer Group Analysis

People who do the same job tend to need the same access. Give ten support engineers the same responsibilities and their permissions converge — and that convergence makes the odd one out stand out. When someone holds access far beyond their peers, that gap is worth a second look, especially if that access grants them privilege to a crown jewel.

This is peer group analysis: instead of asking “is this access reasonable?” in a vacuum — impossible to answer at scale — you ask “is this normal for someone in this role?” The peer group sets the baseline, and the outlier writes its own alert. If everyone on a team can access the same two repositories their service depends on, but one engineer has access to fifteen — including the crown-jewel repo holding your core product’s source — why? Maybe leftover access from an old role. Maybe the quiet over-privilege an insider needs to walk off with the codebase. You won’t know until you look — but the comparison tells you where to look.

Remember, an outlier is a question, not a verdict. Excess access means investigate, not accuse — tenure, dual-hatting, and approved exceptions are all innocent explanations.

Look Beyond a Single Hop

Technique: Attack Path Analysis

Consider a scenario:

• Company: Acme
• Crown jewel: Proprietary data sitting in the company’s email servers
• Employee: Alice Appleseed
• Job role: Microsoft Exchange Administrator
• Standard account: ACME\aliceappleseed
• Privileged (JIT) account: ACME\aliceappleseed_jit

Alice administers Acme’s Exchange environment. Regular users can only open their own mailbox, but her role lets her reach anyone’s. To keep that power in check, Acme uses just-in-time (JIT) access: before Alice can touch another mailbox, she has to elevate to her JIT account and get approval — and even then, only briefly, to debug the service.

Because anyone can be an insider threat — administrators included — Acme alerts whenever a user accesses a large number of mailboxes they don’t own. At scale, that pattern looks like email exfiltration.

But Alice knows the plumbing. She knows Exchange runs under a service account that can read any mailbox. Finding the JIT process a nuisance, she dumps that service account’s secret and simply authenticates as it — arbitrary mailbox access, no elevation, no approval, no alert.

Acme monitored user identities for mailbox abuse, but not system identities. Maybe it was a blind spot — detection engineers often aren’t experts in the services they write detections for. Or maybe the service account legitimately needs broad access to function, so it was knowingly left out of scope. Either way, the result is the same: a clean path around the control.

The fix: any system identity with privileged access to a crown jewel belongs in the risk assessment, right alongside the human ones. This example is just two hops — dump a secret, impersonate an account — but a capable adversary can chain many hops to reach the same goal. If your monitoring stops at the first hop, that’s exactly where they’ll go next.

Uno Reverse

Technique: Deception / Honeytokens

Every technique so far analyzes behavior to find the outlier. This one flips the script: instead of waiting to spot the insider, you set a trap and let them reveal themselves.

A honeytoken is bait that no legitimate workflow should ever touch — a decoy repository named like it holds your crown-jewel source, a fake set of admin credentials, a canary cloud access key, a seeded customer record. It looks real, but it exists only to be watched. The moment someone accesses it, you get an alert with almost no false positives, because there’s no innocent reason to reach for something that isn’t part of any real job.

Picture a repo called foundation-model-weights sitting alongside your actual services, enticing but entirely fake. Real engineers have no reason to clone it; they don’t even know it’s bait. But the insider hunting for the company’s most valuable asset — the model itself — sees exactly what they were looking for, and the instant they pull it, they’ve raised their own hand.

That’s the real power: it inverts the asymmetry. Normally the defender has to catch every move while the insider only needs one gap. With deception, the insider has to be right every time about what’s real — and if your bait is convincing, they can’t be.

Signals Are Leads, Not Verdicts

Attack paths, peer-group outliers, geolocation mismatches, tripped honeytokens — each of these surfaces something the odd-hours dashboards miss. But none of them is a conclusion. Every signal is a lead: a reason to look closer, investigate, and verify before anyone acts on it. There’s almost always an innocent explanation, and finding out which is the whole job.

That’s also why signal quality matters as much as coverage. A lead that fires constantly stops being a lead — it becomes noise, and noise is worse than nothing. It buries the real hits, burns out the analysts chasing it, and quietly trains everyone to ignore the alert. The goal isn’t to catch everything; it’s to surface a small number of high-confidence leads, each worth a human’s time to run down.

Define your crown jewels, point these techniques at what actually matters, tune them until the signal is sharp — and then verify. That’s the difference between a program that reduces risk and one that just generates work.