AV-05 · Insider threat and privilege misuse

Insider threats include malicious employees, negligent users, and over-privileged contractors whose access can cause serious harm — intentionally or accidentally. The challenge is that insiders already have the keys.

$ action: Enforce least privilege, log sensitive actions, build separation of duties, and establish a fair, evidence-based investigation process before you need one.

1. Why Insider Threat Exists

Organizations have to give real people real access to do real work. That necessary trust creates risk when access is excessive, unreviewed, or used outside its approved purpose. Most environments have both problems: too much access, and not enough visibility into how it's used.

Not every insider incident is malicious. Many damaging events come from a rushed admin who disabled logging 'temporarily' and forgot to re-enable it, or a contractor who copied files to a personal drive for convenience. Controls need to account for negligence and policy gaps, not only intentional harm.

Insider activity is hard to detect because normal work and harmful work can look similar in logs. Context is everything: the same file copy can be legitimate work at 9am on Tuesday or a serious red flag at 2am the night before someone's last day.

2. What Insiders Can Do (and Why It Is High Impact)

An insider with admin access can copy sensitive data to personal storage, disable security tooling, modify firewall rules, create hidden accounts, approve their own risky changes, or hand access to an external attacker through a weak remote session. None of that requires exploiting a vulnerability.

The impact is often higher than commodity attacks because insiders know where the crown jewels are, which controls are soft, and which actions are least likely to trigger an immediate alert. An attacker who spent weeks on reconnaissance knows less than a sysadmin who's worked there for three years.

In practice, many insider incidents start as privilege misuse incidents. Broad access, shared admin accounts, and weak audit logging create the conditions where one bad decision — or one bad actor — can affect dozens of systems before anyone notices.

3. How Defenders Reduce Insider Risk Without Breaking Operations

Start with access design. Least privilege, role-based access, separate admin accounts, approval workflows for high-risk actions. When access reflects actual job duties, anomalies stand out. When everyone has everything, nothing looks unusual.

Log sensitive actions specifically — not just sign-ins. Focus audit policies on account creation, privilege grants, firewall and policy changes, data exports, disabling security controls, and access to admin systems outside normal hours.

Build a fair, evidence-based triage process. Insider investigations require careful documentation, strong chain-of-custody discipline, and early coordination with HR and legal. Jumping to conclusions on a single alert causes both false accusations and missed real incidents.

detection-signals

$Admin actions — account creation, privilege grant, firewall rule change — occur outside normal business hours or from a device not in the user's history.
$A user bulk-downloads or compresses files in a directory they rarely access, especially from a sensitive data store.
$Audit logging configuration is modified, a security service is stopped, or log forwarding drops — without a corresponding approved change ticket.
$A shared admin account is used by a user who isn't listed as an authorized user in the access review record.
$Unusual access pattern to sensitive systems appears in the two weeks before a documented resignation or termination — requires careful policy-governed handling.

telemetry-sources

$Identity provider and privileged access logs (admin actions, role changes, MFA events).
$Windows/Linux admin logs, audit logs, and file access logs on sensitive systems.
$Firewall, VPN, proxy, and DLP logs for unusual data movement and destination patterns.
$Change management/ticketing systems to confirm whether risky actions were approved.
$EDR/XDR or host telemetry for archival tools, unusual copy operations, and script activity.

recommended-tools-and-guides

open Wazuh Correlate host and security events to track privileged actions and tampering attempts. open Sigma Create detections for admin misuse patterns and suspicious control changes. open Zeek Observe unusual internal data transfers and protocol behavior tied to sensitive hosts. open Security Onion Use integrated visibility and case workflows for insider-risk investigations. open /learning/linux-windows-logging-basics-for-defenders Build the host logging foundations required for sensitive-action monitoring.

related-learning-modules

Build fundamentals and workflows that directly support defending against this threat pattern.

open /learning/linux-windows-logging-basics-for-defenders Linux and Windows Logging Basics for Defenders open /learning/alert-triage-false-positives-detection-tuning Alert Triage, False Positives, and Detection Tuning open /learning/post-incident-review-hardening-backlog-detection-coverage-gaps Post-Incident Review, Hardening Backlog, and Detection Coverage Gaps

related-tool-pages

Use these detailed tool guides to practice safe validation, evidence collection, and triage workflows for this threat.

open /learning/tools/wazuh Wazuh open /learning/tools/sigma Sigma open /learning/tools/zeek Zeek open /learning/tools/security-onion Security Onion open /learning/tools/osquery osquery

lab-safe-detection-workflows

These commands are for learning, validation, and defensive triage in your own lab or authorized environment. Adapt to your tooling and log locations.

Sensitive action log review (host + auth context)

journalctl --since "-24h" | grep -Ei "sudo|useradd|usermod|passwd|firewall|audit|disable|policy" | tail -n 120
grep -Ei "sudo|session opened|session closed|FAILED|Accepted" /var/log/auth.log | tail -n 120 || true
printf "time,account,host,action,approved_change,evidence,next_step\n" > insider-triage.csv

$ why: Build a documented timeline before escalation. Insider-related triage requires evidence discipline and context about approvals/change windows.

Internal data movement baseline check (authorized NSM review)

zeek -r internal-file-access.pcap local
zeek-cut ts id.orig_h id.resp_h service orig_bytes resp_bytes < conn.log | head -n 50
tshark -r internal-file-access.pcap -z io,stat,60 -q

$ why: Use NSM and packet evidence to compare data movement volume and paths against expected operational behavior.

triage-questions

?Was this action expected for the user's role, shift, and current approved work — or does it deviate from what their job actually requires?
?Is there an approved change ticket or documented business justification for this privileged action?
?What specific data, systems, or controls were touched, and what is the realistic impact?
?Does the pattern suggest negligence, a compromised account, or deliberate misuse — and what evidence supports that conclusion?
?What containment step is proportionate and appropriate right now, given what you actually know versus what you suspect?

defender-actions.checklist

$Enforce least privilege and separate admin accounts.
$Review and re-certify access regularly (especially privileged and third-party accounts).
$Log and alert on high-risk administrative and policy-changing actions.
$Correlate sensitive actions with change approvals and ticketing records.
$Prepare an insider-risk response process with evidence handling and cross-team coordination.

study-workflow

Learn what normal behavior looks like for this area (auth, exposure, config, or internal traffic).
Identify the logs and telemetry that should show the behavior.
Practice one safe validation in a lab or authorized environment.
Write a short playbook for detection, triage, and response.
Review the related tool guides under /learning/tools.

<- previous threat AV-04 · Lateral movement after initial access -> next threat AV-06 · State-backed and foreign targeted intrusions