AV-07 · Supply chain and third-party compromise

Attackers target software suppliers, MSPs, integrators, and trusted update or access paths to reach downstream organizations through relationships that defenders often trust by default.

$ action: Inventory third-party dependencies and access, restrict vendor privileges, verify updates and changes, and monitor trusted channels like you monitor external threats.

1. Why This Threat Exists

Organizations rely on external software, cloud services, MSPs, integrators, and remote support vendors to operate efficiently. These relationships create trust paths that can become high-leverage attack paths if they are not governed and monitored carefully.

Attackers target suppliers because one compromise can create access to many downstream customers. They may abuse update mechanisms, support channels, remote administration tools, build pipelines, or vendor credentials.

This threat exists partly because defenders often classify third-party activity as “trusted” and therefore monitor it less aggressively than unknown internet traffic.

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

A compromised vendor account or tool can introduce malicious changes, create unauthorized remote sessions, push harmful configurations, disable security controls, or provide staging points for lateral movement inside customer environments.

Even when the vendor itself is not compromised, weak third-party access controls (shared accounts, broad VPN access, unmanaged support tools) can create the same effect: an attacker abuses the trust relationship to enter and move within the network.

Defenders should include both software supply chain risk and service-provider access risk under the same operational lens: trusted dependencies with elevated blast radius.

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

Maintain a living inventory of third-party software, update channels, remote support tools, and vendor access paths. You cannot monitor or restrict what you have not documented.

Apply least privilege and segmentation to vendor access. Give third parties only the systems, protocols, and time windows they need. Require strong authentication, logging, and approval workflows for sensitive access.

Verify changes and updates in a controlled process when possible. Monitor trusted channels for unusual timing, source changes, version anomalies, or access behavior that differs from the vendor's normal support pattern.

detection-signals

$Unexpected third-party remote sessions or vendor account activity outside approved windows.
$Software updates or packages arriving from unusual sources, versions, or signing contexts.
$Vendor support tools initiating broader network access than normal.
$Configuration changes on critical systems with no corresponding approved vendor ticket/change.
$Multiple downstream anomalies shortly after a third-party maintenance event.

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.

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 the vendor/session/tool usage expected and approved at this time?
?Did the third-party account or support tool access systems beyond its authorized scope?
?Do observed changes match a documented maintenance ticket and expected outcome?
?What trusted channels (VPN, jump host, update source) may need temporary restriction during triage?
?What monitoring or least-privilege control failed to prevent or flag this 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