AV-07 · Supply chain and third-party compromise

Attackers target software suppliers, MSPs, and trusted access paths because one upstream compromise can open doors into dozens of downstream organizations. Defenders often trust these channels by default — which is exactly the problem.

$ action: Inventory third-party dependencies and access paths, restrict vendor privileges, verify changes against approved tickets, and monitor trusted channels the same way you monitor external threats.

1. Why This Threat Exists

Every organization relies on external software, MSPs, cloud services, integrators, and remote support vendors to operate. Those relationships create trust paths that can become high-leverage attack paths if they're not governed and actively monitored.

Attackers target suppliers because the ROI is asymmetric. Compromise one well-positioned MSP and you may have access to the networks of dozens of downstream customers. The attacker does the hard work once; the impact multiplies across every trusted relationship.

The defender's blind spot is classification. Third-party activity often gets labeled 'trusted' and monitored less aggressively than internet traffic. That assumption is exactly what makes supply chain attacks effective.

2. What Supply Chain or Third-Party Compromise Can Do

A compromised vendor account or support tool can push malicious changes, create unauthorized remote sessions, disable security controls, modify configurations, or provide a staging point for lateral movement inside customer environments. The access already has legitimate credentials and often bypasses normal alerting.

Even when the vendor itself isn't compromised, weak third-party access controls create the same effect. Shared support accounts, broad VPN access, unmanaged remote-assistance tools — any of these can be abused to enter and traverse the network under a trusted identity.

Software supply chain risk and service-provider access risk need to be managed under the same operational lens: trusted dependencies with elevated blast radius that require active oversight, not passive assumption.

3. How Defenders Mitigate Third-Party and Supply Chain Risk

Start with a living inventory. Document every third-party software product, update channel, remote support tool, and vendor access path. If it's not documented, it can't be monitored or restricted effectively.

Apply least privilege and segmentation to vendor access. Third parties should reach only the systems they need, through protocols their work requires, during time windows that match approved maintenance. Require strong authentication and full session logging for sensitive access.

Verify changes in a controlled process. Correlate actual system changes against approved vendor tickets. Timing mismatches, undocumented changes, or scope creep are all worth investigating — even if the vendor seems trustworthy.

detection-signals

$A vendor remote session or support tool initiates connections outside an approved maintenance window or to systems beyond its stated scope.
$A software update or package arrives from an unexpected signing identity, an unusual source IP, or a version number that doesn't match the vendor's published release notes.
$A vendor support tool opens network connections to internal systems it has never previously reached.
$Configuration or file changes appear on a critical system with no corresponding approved vendor change ticket.
$Multiple systems show similar anomalies within hours of a third-party maintenance event — suggesting the vendor's access was the common factor.

telemetry-sources

$VPN/remote access logs for vendor accounts and support sessions.
$Privileged access logs and session recording (if deployed) for third-party administration.
$Endpoint/EDR and application logs for update/install events and process launches.
$Change management records, vendor tickets, and maintenance windows.
$Network telemetry (Zeek/Suricata/firewalls) around vendor subnets, jump hosts, and management paths.

recommended-tools-and-guides

open Wazuh Track process and configuration changes on systems touched by vendors. open Zeek Observe network behavior from vendor access paths and jump hosts. open Suricata Alert on suspicious traffic over trusted channels and management protocols. open Nmap Validate vendor-accessible surfaces and confirm segmentation restrictions. open /learning/frameworks/nist-csf-governance-operations Use CSF to assign ownership for third-party access governance, monitoring, and response.

related-learning-modules

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

open /learning/threat-informed-defense-attack-technique-mapping Threat-Informed Defense Using ATT&CK-Style Technique Mapping open /learning/incident-response-playbooks-framework-functions Incident Response Playbooks Aligned to Recognized Cybersecurity Framework Functions 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/zeek Zeek open /learning/tools/suricata Suricata open /learning/tools/nmap Nmap

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.

Vendor access path validation (authorized segmentation check)

nmap -sT -Pn -p 22,3389,443,8443 vendor-jumphost.example.internal
zeek -r vendor-session-sample.pcap local
zeek-cut ts id.orig_h id.resp_h service < conn.log | head -n 50

$ why: Validate which services are reachable through vendor paths and whether observed traffic matches the approved support scope.

Change / maintenance correlation worksheet

printf "time,system,vendor_action,approved_ticket,observed_log,match_status\n" > third-party-change-correlation.csv
journalctl --since "-6h" | grep -Ei "install|update|service|config|restart" | tail -n 120

$ why: Correlate actual system changes to approved vendor work to detect mismatches and suspicious activity quickly.

triage-questions

?Was this vendor session, tool usage, or software update expected and explicitly approved for this time window?
?Did the vendor account or support tool access systems beyond its documented authorized scope?
?Do the observed changes match the approved ticket description and expected technical outcome?
?Which trusted channels — VPN, jump host, update source — may need temporary restriction while triage is underway?
?What monitoring or access-control gap allowed this activity to occur without flagging earlier?

defender-actions.checklist

$Inventory third-party software, support tools, and vendor access paths.
$Restrict vendor access by system, protocol, and time window.
$Require strong authentication and auditable sessions for third-party admin access.
$Correlate vendor actions with tickets/change approvals and alert on mismatches.
$Monitor trusted channels with the same seriousness as internet-facing threats.

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-06 · State-backed and foreign targeted intrusions -> next threat AV-08 · Ransomware and data extortion operations