Arista VeloCloud Orchestrator On-Prem — CVE-2026-16812

Arista Security Advisory 0144 (2026-07-27) discloses CVE-2026-16812, an OS command injection flaw (CWE-78, CVSS v3.1 and v4.0 base score 10.0) in VeloCloud Orchestrator (VCO) On-Prem. Privileged internal functionality that was never intended to be remotely reachable is exposed on the VCO web interface. Arista states plainly that "VCO is exposed by default. There is no configuration that can prevent the exposure," and that tenant or operator credentials are not required. The vulnerability was discovered externally and is known to be actively exploited; CISA added it to the KEV catalog on 2026-07-27 with a three-day federal remediation deadline of 2026-07-30 under BOD 26-04.

Why the blast radius is bigger than one box. The attacker objective here is not the orchestrator VM, it is everything the orchestrator holds. A VCO instance is the control plane for an entire SD-WAN fabric: it stores orchestrator databases, SD-WAN configuration, device inventory, and the credentials and cryptographic key material for every managed VeloCloud Edge. Arista's own post-remediation guidance says compromise "may allow attackers access to the VeloCloud Edge devices as well" and calls for credential rotation, validation of managed device state, and restoration or replacement of affected orchestrator instances from trusted sources. Treat a confirmed hit as a fabric-wide credential-compromise event, not a single-host incident.

Highest-value defensive angle. Arista published exactly three atomic indicators — the source IPs observed conducting the attacks — and nothing else: no payload hashes, no webshell names, no exploit path, no actor attribution. So the pack is built in two layers. Layer one is a cheap, high-confidence sweep of network telemetry from any Falcon sensor for those three IPs, inbound and outbound. Layer two is behavioural Linux post-exploitation hunting on the orchestrator host itself: a shell spawned by the web tier, reverse-shell command lines, curl/wget/python staging, cron and systemd persistence, database export and key-material access, and abnormal fan-out from the orchestrator toward managed Edges.

Defender priority: patch to a fixed VCO release (5.2.3.14 / 6.1.3.4 / 6.4.2.4 / 7.0.0.1) or take the web interface off any untrusted network today. Then hunt — an exploited orchestrator that is patched afterwards is still an orchestrator whose Edge credentials and keys are in someone else's hands. Patching closes the door; it does not evict the guest.

Nine sources were fetched and snapshotted verbatim into Arista-VeloCloud-CVE-2026-16812-Hunt-sources/. Every atomic indicator shipped in this pack traces back to at least one of those snapshots.

Hunter notes and decisions

• No prompt-injection or agent-directed text was found in any fetched source. All nine pages were checked for text addressed to an automated system; none was present. No source was dropped for that reason.
• The CISA KEV HTML page returned HTTP 403 to the fetcher. The machine-readable KEV feed (same catalog) was snapshotted instead and is the authoritative due-date reference.
• Two press sources contain factual errors (see table). Both are retained as corroboration of the three IPs only; their erroneous fields are explicitly not carried forward.
• No exploitation detail exists publicly. There is no published request path, parameter, payload, webshell name, file hash, or C2 domain. This pack therefore ships three atomic IPs and a body of behavioural logic. Anything else in the IOC appendix is a labelled REPLACE_WITH_ placeholder — deliberately, so nobody blocks a fabricated indicator.
• Attribution is unknown. No actor, no campaign name, no ransomware association (KEV records "Unknown"). Do not assume a ransomware playbook follows.

The chain below is inferred from the vulnerability class and Arista's own IOC-review checklist, not from published attacker tradecraft. Steps 1 and 2 are stated by the vendor; steps 3 onward are the standard consequences of unauthenticated command execution on a Linux management appliance and are exactly the behaviours Arista tells operators to look for. They are labelled as hypotheses, not observations.

Hunt hypotheses (fidelity-ordered)

Telemetry reality check: H3 through H8 all assume a Falcon Linux sensor is installed on the VCO virtual appliance. Many organisations run vendor appliances unsensored — see §5 and §15 for exactly which queries degrade to nothing in that case, and what replaces them.

Arista published three atomic indicators and stated there is "no single definitive indicator" for this vulnerability. Everything else below the line is behavioural. No hashes, domains, URLs, webshell filenames or payload artifacts have been published by any source — this pack invents none.

Not published, do not fabricate: exploit request path, injected parameter, payload hash, webshell name, C2 domain, actor or campaign name, first-exploitation date, victim count. If a feed or a colleague hands you one of these, verify it against Arista Advisory 0144 before it enters a blocklist.

Be honest about the sensor gap. A VeloCloud Orchestrator appliance may well carry no Falcon sensor — vendor-supported virtual appliances often prohibit or complicate third-party agents. If that is your situation, Q3 through Q9 will return zero rows and that zero means nothing, not "clean". Your evidence then comes from: (a) Q1/Q2 run estate-wide, which still catch anything the orchestrator talked to that is sensored; (b) Q10 against VCO web access logs shipped into NG-SIEM; (c) the native, on-appliance checks in §7; and (d) perimeter firewall and NetFlow records. Record which of these you actually have before you call the hunt complete.

These run where Falcon cannot see. They follow Arista's own IOC-review checklist. Everything here is read-only evidence collection — run it before you patch or rebuild, because upgrading destroys the timeline.

A. VCO web access logs

• Requests from 8.19.75.217, 206.72.242.124, 206.72.242.162 — any method, any status, including 4xx/5xx. A 500 from these sources is as interesting as a 200.
• Unusual URL-like path components, encoded characters (%00, %2e%2e, %2f, %3b, %7c, %60), or references to local/internal services.
• Abnormally high request rates from a single source, or bursts of requests to endpoints your admins never touch.
• Requests to internal-only endpoints arriving from outside the management network.

B. VCO backend application, system and database logs

• Command execution, file creation, database export or archive artifacts on the VCO host with no matching change ticket.
• Privileged maintenance actions outside expected administrative workflows.
• Sensitive configuration changes with no corresponding administrator activity.
• Access to VCO database contents, configuration data, device inventory, credentials, certificates or key material.
• Authentication logs (/var/log/auth.log or /var/log/secure): new accounts, sudo use by service identities, SSH key-based logins from unfamiliar sources.

C. On-appliance read-only triage (before remediation)

# Read-only. Capture output off-box. Do NOT remediate before collecting.
# 1. Recently modified files across the appliance (last 30 days)
find / -xdev -mtime -30 -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort

# 2. Persistence surfaces
crontab -l ; ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly
systemctl list-unit-files --state=enabled
systemctl list-timers --all
find /home /root -name authorized_keys -exec ls -la {} \; 2>/dev/null

# 3. Accounts and privilege
awk -F: '$3 < 1000 {print}' /etc/passwd
getent group sudo wheel 2>/dev/null
last -F -n 100

# 4. Live network state and listeners
ss -tunap
ip route show ; ip neigh show

# 5. Running processes and their parents
ps -eo pid,ppid,user,lstart,etime,cmd --sort=start_time

# 6. Preserve, then hash, then hand to IR
tar -czf /var/tmp/vco-evidence.tgz /var/log 2>/dev/null

D. Perimeter, proxy and NetFlow

• Any flow to or from the three published IPs, in either direction, for the full retention window — not just since the advisory.
• Outbound HTTP/S from the VCO management address to anything that is not an Arista update or licensing endpoint.
• Large egress volumes from the management VLAN, especially to cloud storage or paste services.
• Confirm whether the VCO web interface was ever reachable from the internet or from user VLANs. Arista notes it is exposed by default.

E. Downstream Edge fabric

• Edge configuration changes, firmware pushes or tunnel re-establishments that do not map to a change record.
• AAA logs (RADIUS/TACACS) for orchestrator service accounts authenticating from unexpected sources.
• Certificate and key rotation status for every managed Edge — Arista's post-remediation guidance treats this as mandatory after suspected compromise.

No query carries an in-query time filter. Set the window with the console time picker; each card records the intended lookback as a // LOOKBACK: comment. For the three published IPs, run the maximum retention you have — Arista never said when exploitation began.

// HUNT: Inbound connection from a published CVE-2026-16812 attacker IP
// MITRE: T1190 | CONF: high  FP: low  COST: low
// REQUIRES: Falcon network telemetry from any sensored host (NetworkReceiveAcceptIP4)
// LOOKBACK: maximum available retention - exploitation start date is unpublished
// FALSE POSITIVES: authorised scanning or red-team egress sharing the same netblock
// TUNING: if a hit resolves to your own scanner, exclude by aid, never by removing the IP
#event_simpleName=/^NetworkReceiveAcceptIP4$/
| in(RemoteAddressIP4, values=["8.19.75.217", "206.72.242.124", "206.72.242.162"])
| table([@timestamp, aid, ComputerName, LocalAddressIP4, LocalPort, RemoteAddressIP4, RemotePort, ContextBaseFileName])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Outbound connection to a published CVE-2026-16812 attacker IP
// MITRE: T1071.001, T1041 | CONF: high  FP: low  COST: low
// REQUIRES: Falcon network telemetry from any sensored host (NetworkConnectIP4)
// LOOKBACK: maximum available retention
// FALSE POSITIVES: TI enrichment proxies, sandbox detonation hosts, security scanners
// TUNING: exclude known enrichment/sandbox hosts by aid; do not exclude by RemotePort
#event_simpleName=/^NetworkConnectIP4$/
| in(RemoteAddressIP4, values=["8.19.75.217", "206.72.242.124", "206.72.242.162"])
| table([@timestamp, aid, ComputerName, ContextBaseFileName, LocalAddressIP4, RemoteAddressIP4, RemotePort, Protocol_decimal])
| sort(@timestamp, order=desc, limit=500)

// HUNT: POSIX shell spawned by the VCO web / application tier (command injection)
// MITRE: T1190, T1059.004 | CONF: high  FP: medium  COST: low
// REQUIRES: Falcon Linux sensor ON the VCO host - ProcessRollup2
// LOOKBACK: 90d
// FALSE POSITIVES: appliance health checks, log rotation, backup and upgrade helpers
// TUNING: baseline for 7d, then exclude the recurring ParentBaseFileName + CommandLine
// TUNING: pairs that belong to the vendor's own maintenance scripts - exclude the exact
// TUNING: command line, never the whole parent process
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(node|nginx|httpd|apache2|java|python[0-9]*|uwsgi|gunicorn|supervisord|php-fpm)$/i
| FileName=/^(sh|bash|dash|ksh|zsh|busybox)$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Reverse-shell / shell-redirection command line on a Linux host
// MITRE: T1059.004, T1219 | CONF: high  FP: medium  COST: medium
// REQUIRES: Falcon Linux sensor - ProcessRollup2 with CommandLine capture
// LOOKBACK: 90d
// FALSE POSITIVES: admin troubleshooting, monitoring plugins that shell out to nc
// TUNING: triage the dev/tcp and pty.spawn matches first - they are the rarest.
// TUNING: exclude your monitoring agent by ParentBaseFileName once its exact nc
// TUNING: invocation is baselined; keep the dev/tcp branch un-excluded always
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| CommandLine=/(bash\s+-i|dev\/tcp|dev\/udp|nc\s+-[a-z]*e|ncat\s+-[a-z]*e|socat\s+.{0,40}exec|pty\.spawn|python[0-9]*\s+-c\s+.{0,80}socket)/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Download utility fetching a remote payload on a management-plane Linux host
// MITRE: T1105 | CONF: medium  FP: high  COST: medium
// REQUIRES: Falcon Linux sensor - ProcessRollup2 with CommandLine capture
// LOOKBACK: 90d
// FALSE POSITIVES: apt/yum/dnf mirrors, license and telemetry callbacks, health probes
// TUNING: restrict to the orchestrator aid set, then exclude vendor update and licensing
// TUNING: hostnames by CommandLine substring; prioritise rows whose ParentBaseFileName
// TUNING: is a web/app process (same parents as Q3) - that pairing is the real signal
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(curl|wget|python[0-9]*|perl|tftp|scp|fetch)$/i
| CommandLine=/(http:\/\/|https:\/\/|ftp:\/\/|urllib|urlretrieve)/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Linux persistence tooling executed on a management-plane host
// MITRE: T1053.003, T1543.002, T1098.004, T1136.001 | CONF: medium  FP: high  COST: low
// REQUIRES: Falcon Linux sensor - ProcessRollup2
// LOOKBACK: 90d
// FALSE POSITIVES: Ansible/Puppet/Chef runs, vendor upgrade routines, package post-install
// TUNING: exclude ParentBaseFileName of your config-management agent and the package
// TUNING: manager; keep every row whose parent is a web/app process or a shell that
// TUNING: descends from one - that is the pairing this hunt exists for
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(crontab|systemctl|systemd-run|at|atd|useradd|adduser|usermod|groupmod|ssh-keygen|chattr|update-rc\.d)$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: ELF / critical-file write into staging or persistence paths
// MITRE: T1105, T1053.003, T1543.002, T1098.004 | CONF: medium  FP: medium  COST: medium
// REQUIRES: Falcon Linux sensor - ELFFileWritten, CriticalFileModified
// NOTE: CriticalFileModified coverage on Linux varies by sensor version and policy.
// If it returns nothing at all, that is a telemetry gap, not a clean result.
// (!) validate in tenant: confirm both event types are populated before trusting a null result
// LOOKBACK: 90d
// FALSE POSITIVES: package installs, vendor upgrade bundles, backup extraction
// TUNING: exclude writes whose ContextBaseFileName is the package manager (dpkg, rpm,
// TUNING: apt, yum, dnf); keep every write into /tmp, /dev/shm and /var/tmp
#event_simpleName=/^(ELFFileWritten|CriticalFileModified)$/
| TargetFileName=/(\/tmp\/|\/var\/tmp\/|\/dev\/shm\/|authorized_keys|\/etc\/cron|\/etc\/systemd\/|\/usr\/lib\/systemd\/|\/etc\/rc\.local)/i
| table([@timestamp, aid, ComputerName, UserName, ContextBaseFileName, TargetFileName])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Database export / archive / key-material access on the orchestrator host
// MITRE: T1005, T1552.001, T1552.004, T1560.001 | CONF: medium  FP: medium  COST: medium
// REQUIRES: Falcon Linux sensor - ProcessRollup2 with CommandLine capture
// LOOKBACK: 90d
// FALSE POSITIVES: nightly backup jobs, vendor support-bundle generation, cert renewal
// TUNING: exclude the backup service account by UserName and the backup window by hour,
// TUNING: then keep everything left - an off-schedule dump is the whole point of this hunt
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(mysqldump|mysql|mariadb-dump|pg_dump|pg_dumpall|psql|mongodump|tar|zip|gzip|xz|openssl|base64|scp)$/i
| CommandLine=/(velocloud|vco|orchestrator|edge|inventory|\.pem|\.key|\.p12|\.pfx|\.crt|credential|passwd|shadow|keystore)/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc, limit=500)

// HUNT: Abnormal remote-admin fan-out from a management-plane host (Edge credential reuse)
// MITRE: T1078, T1021.004 | CONF: medium  FP: medium  COST: high
// REQUIRES: Falcon Linux sensor - ProcessRollup2
// LOOKBACK: 30d, then narrow to any day that stands out
// FALSE POSITIVES: scheduled mass config push, firmware campaign, inventory sweep
// TUNING: raise or lower the Runs threshold to your fleet size - 25 suits a mid-size
// TUNING: estate; exclude your automation service account by UserName once its normal
// TUNING: daily volume is baselined, and always check the change calendar first
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(ssh|scp|sftp|curl|ansible|ansible-playbook|expect|sshpass)$/i
| groupBy([aid, ComputerName, UserName, FileName], function=[count(as=Runs), collect(CommandLine, limit=20)], limit=500)
| Runs > 25
| sort(Runs, order=desc, limit=100)

// HUNT: Injection-shaped request against the VCO web interface (third-party HTTP logs)
// MITRE: T1190 | CONF: medium  FP: medium  COST: medium
// REQUIRES: VCO / reverse-proxy / WAF access logs ingested into NG-SIEM.
// This query needs NO Falcon sensor on the appliance - it is the fallback path.
// (!) validate in tenant: HTTP parser field names are tenant- and parser-specific.
// Confirm url / src_ip / http_method / status against one real sample row and rename
// to your parser's fields before scheduling this query.
// LOOKBACK: maximum available retention
// FALSE POSITIVES: vulnerability scanners, broken clients, internal monitoring probes
// TUNING: exclude your scanner source ranges by src_ip, then rank what remains by
// TUNING: source IP and keep any source that later receives a 200 with an odd body size
url=/(%00|%2e%2e|%2f\.\.|%3b|%7c|%60|%24%28|\$\(|`|;\s*(curl|wget|bash|sh|nc|python)\s)/i
| groupBy([src_ip, http_method, status], function=[count(as=Hits), collect(url, limit=20)], limit=500)
| sort(Hits, order=desc, limit=200)

Field-verification note. Q7 and Q10 carry an explicit (!) validate in tenant line inside the query. CriticalFileModified coverage on Linux is sensor-version and policy dependent, and the HTTP parser fields in Q10 are tenant-specific by definition. Everything else in this pack uses core Falcon data-model fields that are stable across tenants.

Promotion decisions

Custom IOA — "Linux reverse shell from management-plane host"

• Rule group: Linux · Management plane (scope to the orchestrator and jump-host groups, not the whole estate).
• Rule type: Process Creation.
• Image filename pattern: .*/(sh|bash|dash|nc|ncat|socat|python[0-9]*)$
• Command line pattern: .*(bash\s+-i|dev/tcp|nc\s+-[a-z]*e|socat.{0,40}exec|pty\.spawn).*
• Action: start at Detect · Informational-to-Medium for one week, review the hit set, then promote to Prevent only once the benign set is empty.
• Exclusions: your monitoring agent's exact nc invocation; never exclude the dev/tcp branch.

Scheduled Search / alert package

Alert email body (template)

WHAT FIRED
A host in the estate communicated with an IP address that Arista Networks published
as conducting attacks exploiting CVE-2026-16812 (VeloCloud Orchestrator On-Prem,
unauthenticated OS command injection, CVSS 10.0, CISA KEV due 2026-07-30).

WHY IT MATTERS
The orchestrator holds SD-WAN configuration, device inventory, and the credentials
and key material for every managed VeloCloud Edge. A compromise of the orchestrator
is a compromise of the fabric, not of one virtual machine.

IMMEDIATE ACTIONS (first 30 minutes)
1. Determine direction. Outbound = probable compromise. Inbound only = targeting.
2. Identify whether the host is, or routes to, a VeloCloud Orchestrator On-Prem VM.
3. Check the VCO build against 5.2.3.14 / 6.1.3.4 / 6.4.2.4 / 7.0.0.1.
4. PRESERVE FIRST: VCO web access logs, backend application logs, system logs,
   database logs and file-system timestamps - before any patch or reboot.
5. Block the three IPs at the perimeter and add them to Falcon IOC Management.
6. If compromise is suspected, escalate to IR and open the fabric-wide credential
   and key rotation workstream. Do not stop at patching.

ESCALATION PATH
L1 -> IR on-call -> network engineering (SD-WAN owner) -> CISO if Edge credential
rotation is required.

L1 triage checklist

1. Confirm the direction of the flow (Q1 inbound vs Q2 outbound) and record it in the ticket.
2. Identify the asset: is it the VCO VM, a proxy in front of it, or an unrelated host?
3. Record the running VCO version and whether it predates the fixed release for its train.
4. Confirm whether the VCO web interface is reachable from outside the management network.
5. Preserve logs and file-system timestamps before any remediation action.
6. Run Q3 and Q4 scoped to that aid for the surrounding 24 hours.
7. Run Q6, Q7 and Q8 scoped to that aid for the surrounding 30 days.
8. If any behavioural query returns a hit, escalate to IR and treat Edge credentials as compromised until proven otherwise.

Pivot queries

• Host-scoped: take the aid from the alert and re-run Q3 through Q8 with | aid = "<aid from alert>" appended after the event filter.
• Estate-wide: re-run Q1 and Q2 across maximum retention to find every other host that ever touched the same infrastructure.
• Process-tree: pivot any Q3 hit into the Falcon process explorer for the parent and its full descendant tree.

Three atomic indicators ship here, all three traceable to the Arista advisory snapshot. Everything else is a labelled placeholder or a behavioural signature — because Arista published no hashes, no domains and no payload artifacts, and a fabricated indicator in a blocklist is worse than an empty one.

type,value,action,severity,expiration,description,tags
ipv4,8.19.75.217,detect,critical,2027-01-30,Arista-published attacker IP for CVE-2026-16812,campaign:CVE-2026-16812
ipv4,206.72.242.124,detect,critical,2027-01-30,Arista-published attacker IP for CVE-2026-16812,campaign:CVE-2026-16812
ipv4,206.72.242.162,detect,critical,2027-01-30,Arista-published attacker IP for CVE-2026-16812,campaign:CVE-2026-16812
sha256,REPLACE_WITH_PAYLOAD_SHA256,detect,critical,2027-01-30,No payload hash has been published - fill only from your own IR then raise to prevent,campaign:CVE-2026-16812
domain,REPLACE_WITH_C2_DOMAIN,detect,high,2026-10-30,No C2 domain has been published - fill only from your own IR,campaign:CVE-2026-16812
# Arista published no file hashes; no webshell names; no payload artifacts; no C2 domains.
# The three IPv4 rows above are the complete published atomic indicator set.

BEH-01  POSIX shell (sh/bash/dash) parented by node|nginx|httpd|apache2|java|python|uwsgi
        |gunicorn|php-fpm on a VeloCloud Orchestrator host          [Q3]  conf: high
BEH-02  Reverse-shell command line: bash -i, dev/tcp, nc -e, socat exec, pty.spawn
                                                                    [Q4]  conf: high
BEH-03  curl|wget|python|perl|tftp fetching an http(s)/ftp URL on the orchestrator
                                                                    [Q5]  conf: medium
BEH-04  crontab|systemctl|systemd-run|useradd|ssh-keygen executed with a web/app-tier
        ancestor                                                    [Q6]  conf: medium
BEH-05  ELF or critical-file write to /tmp, /var/tmp, /dev/shm, /etc/cron*, systemd
        unit paths, or authorized_keys                              [Q7]  conf: medium
BEH-06  mysqldump|pg_dump|mongodump|tar|zip|openssl invoked with velocloud|vco|edge|
        inventory|.pem|.key|.p12 in the command line                [Q8]  conf: medium
BEH-07  Burst of ssh|scp|sftp|curl|ansible from a management host toward the Edge fleet
                                                                    [Q9]  conf: medium
BEH-08  VCO web request containing %00, %2e%2e, %3b, %7c, %60, backtick or $( followed
        by a shell utility name                                    [Q10]  conf: medium

# Arista Security Advisory 0144 - IPs observed conducting CVE-2026-16812 attacks.
# Block bidirectionally at the perimeter AND log the denies - the deny log is evidence.
8.19.75.217
206.72.242.124
206.72.242.162

# nftables (adjust table/chain names to your ruleset)
nft add rule inet filter input  ip saddr { 8.19.75.217, 206.72.242.124, 206.72.242.162 } log prefix \"CVE-2026-16812-in \" drop
nft add rule inet filter output ip daddr { 8.19.75.217, 206.72.242.124, 206.72.242.162 } log prefix \"CVE-2026-16812-out \" drop

# iptables equivalent
iptables -I INPUT  -s 8.19.75.217    -j LOG --log-prefix \"CVE-2026-16812-in \"
iptables -I INPUT  -s 8.19.75.217    -j DROP
iptables -I INPUT  -s 206.72.242.124 -j DROP
iptables -I INPUT  -s 206.72.242.162 -j DROP
iptables -I OUTPUT -d 8.19.75.217    -j DROP
iptables -I OUTPUT -d 206.72.242.124 -j DROP
iptables -I OUTPUT -d 206.72.242.162 -j DROP

# CVE-2026-16812 exposure audit - VeloCloud Orchestrator On-Prem
# CISA KEV: added 2026-07-27, FCEB due date 2026-07-30 (BOD 26-04)

[ ] Enumerate every VeloCloud Orchestrator On-Prem instance (prod, DR, lab, forgotten)
[ ] Record the running version of each
[ ] FIXED RELEASES - anything below these is vulnerable:
      5.2 train  ->  5.2.3.14 or later
      6.1 train  ->  6.1.3.4 or later
      6.4 train  ->  6.4.2.4 or later
      7.0 train  ->  7.0.0.1 or later
[ ] NOT affected, do not spend time on: VCO Hosted, VCO Dedicated, VeloCloud Gateway,
    VeloCloud Edge, Arista EOS platforms, CloudVision, Wireless APs, NDR, NG Firewall
[ ] Is the VCO web interface reachable from the internet?          (expected: NO)
[ ] Is it reachable from user/guest VLANs?                          (expected: NO)
[ ] Is it restricted to a trusted administrative network?           (expected: YES)
[ ] Are VCO web/app/system/database logs shipped off-box to the SIEM? (expected: YES)
[ ] Is a Falcon Linux sensor installed on the VCO VM?                (if NO, see 5)
[ ] Have the three attacker IPs been blocked and the denies logged?
[ ] Has a full-retention search for those IPs been run and documented?

Do not build a proof-of-concept exploit to test these detections. The positive tests above are deliberately benign process-execution stand-ins. There is no published exploit path for CVE-2026-16812 and this pack does not supply one.

Playbook 1 — Preserve evidence before any remediation

Run this first. Patching or rebooting a VCO destroys the very logs Arista tells you to keep.

## Prerequisites: read-only shell or console access to the VCO host; an off-box
##                destination with enough space; change ticket raised.
## Reboot required: no
## Rollback: none required - every command is read-only or writes to a new file
##           under /var/tmp. To undo, delete the archive you created.

# 1. Snapshot the VM at the hypervisor first if you can - it is the cleanest evidence.
#    (vSphere / KVM console action, not a shell command.)

# 2. Capture logs and timestamps to a new archive
mkdir -p /var/tmp/ir-cve-2026-16812
tar -czf /var/tmp/ir-cve-2026-16812/logs.tgz /var/log 2>/dev/null
find / -xdev -mtime -60 -type f -printf '%TY-%Tm-%TdT%TH:%TM:%TS %p\n' 2>/dev/null \
  > /var/tmp/ir-cve-2026-16812/timeline.txt

# 3. Capture volatile state
ps -eo pid,ppid,user,lstart,etime,cmd --sort=start_time > /var/tmp/ir-cve-2026-16812/ps.txt
ss -tunap                                               > /var/tmp/ir-cve-2026-16812/sockets.txt
last -F -n 200                                          > /var/tmp/ir-cve-2026-16812/logins.txt
crontab -l                                              > /var/tmp/ir-cve-2026-16812/crontab.txt 2>/dev/null
systemctl list-unit-files --state=enabled               > /var/tmp/ir-cve-2026-16812/units.txt

# 4. Hash and copy off-box, then verify the copy
sha256sum /var/tmp/ir-cve-2026-16812/* > /var/tmp/ir-cve-2026-16812/SHA256SUMS
scp -r /var/tmp/ir-cve-2026-16812 ir-collector.internal-host.example.com:/evidence/

# 5. Verify on the collector BEFORE you touch the orchestrator again
#    sha256sum -c SHA256SUMS

Playbook 2 — Restrict the VCO web interface to trusted admin networks

Apply upstream of the appliance wherever possible. The host-level rules below are a stopgap for when you cannot get a firewall change through in time.

## Prerequisites: the CIDR of your trusted administrative network; out-of-band or
##                console access to the VCO in case you lock yourself out; a change
##                window; Playbook 1 already completed.
## Reboot required: no
## Rollback: nftables - `nft delete table inet vcoguard` removes every rule added here.
##           iptables - re-run each command with -D instead of -I/-A.
##           Persistence is NOT saved by these commands, so a reboot also reverts them
##           until you explicitly save the ruleset.

# ---- Option A: upstream firewall / load balancer (PREFERRED) ----
# Permit tcp/443 to the VCO management address ONLY from the admin CIDR.
# Deny and LOG everything else. Vendor syntax varies; the rule shape is:
#   permit tcp <admin-cidr> host <vco-mgmt-ip> eq 443
#   deny   tcp any          host <vco-mgmt-ip> eq 443 log

# ---- Option B: host-level nftables stopgap on the VCO VM ----
ADMIN_CIDR=\"REPLACE_WITH_ADMIN_CIDR\"      # e.g. 192.0.2.0/24
nft add table inet vcoguard
nft add chain inet vcoguard input { type filter hook input priority 0 \; policy accept \; }
nft add rule  inet vcoguard input ip saddr \$ADMIN_CIDR tcp dport { 80, 443 } accept
nft add rule  inet vcoguard input tcp dport { 80, 443 } log prefix \"vco-webui-deny \" drop

# ---- Option C: iptables stopgap ----
iptables -I INPUT -p tcp -s \$ADMIN_CIDR --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j LOG --log-prefix \"vco-webui-deny \"
iptables -A INPUT -p tcp --dport 443 -j DROP

# ---- Verify from OUTSIDE the admin network (expect a timeout, not a login page) ----
# curl -sk --max-time 5 https://<vco-mgmt-ip>/ ; echo \"exit=\$?\"

Playbook 3 — Block the published attacker infrastructure

## Prerequisites: perimeter firewall change access; Falcon admin role for the IOC
##                Management step; the CSV from section 10.
## Reboot required: no
## Rollback: remove the three IPs from the firewall ruleset and set their Falcon IOC
##           entries to `no action` (or delete them). Keep the deny logs regardless -
##           they are evidence, not noise.

# 1. Perimeter - bidirectional, logged. See the "Perimeter block list" block in
#    section 10 for ready-to-paste nftables and iptables rules.

# 2. Falcon IOC Management - import the CSV from section 10 (grab-csv):
#    Falcon console -> Endpoint security -> IOC management -> Import
#    Action: detect  |  Severity: critical  |  Expiry: 2027-01-30
#    Leave the REPLACE_WITH_ rows OUT of the import - they are placeholders.

# 3. Proxy / DNS - add the three addresses to the egress deny list and confirm the
#    proxy logs a block rather than silently failing open.

# 4. Re-run Q1 and Q2 across full retention AFTER the block goes in, so that the
#    historical search is not truncated by the new rule.

Playbook 4 — Upgrade to a fixed VCO release

## Prerequisites: Playbook 1 completed (evidence preserved); a current VM snapshot or
##                backup; the fixed image downloaded from Arista for your train; a
##                maintenance window; Arista TAC engaged if you are on an unsupported
##                release train.
## Reboot required: YES - a VCO upgrade restarts orchestrator services and the host.
##                  Managed Edges continue forwarding traffic while the orchestrator
##                  is down, but configuration changes and new Edge activations will
##                  not be possible during the window.
## Rollback: restore the pre-upgrade VM snapshot. Take and VERIFY that snapshot before
##           starting - it is the only rollback path, and a snapshot you have not
##           tested is not a rollback plan.

# 1. Record the current version and confirm the target for your train:
#      5.2 train  ->  5.2.3.14 or later
#      6.1 train  ->  6.1.3.4 or later
#      6.4 train  ->  6.4.2.4 or later
#      7.0 train  ->  7.0.0.1 or later

# 2. Snapshot the VM. Verify the snapshot is complete and consistent.

# 3. Apply the vendor upgrade per Arista's documented procedure for your deployment
#    (image and steps differ by train - follow Arista, not this pack).

# 4. Post-upgrade verification:
#    - confirm the reported version is at or above the fixed release
#    - confirm all managed Edges reconnect and report healthy
#    - confirm administrative login works from the trusted admin network ONLY
#    - re-confirm the Playbook 2 restriction survived the upgrade

# 5. If exploitation is suspected, DO NOT stop here. Patching a compromised
#    orchestrator leaves the attacker's stolen credentials and keys valid.
#    Proceed to Playbook 5.

Playbook 5 — Fabric-wide credential and key rotation (post-compromise)

## Prerequisites: IR lead assigned; a confirmed or suspected compromise; Playbooks 1
##                and 4 complete; an approved maintenance window per Edge group; a
##                tested rollback for each credential class.
## Reboot required: no for credential rotation itself; some Edge certificate changes
##                  require a tunnel re-establishment - treat that as a service impact.
## Rollback: rotation is intentionally one-way. The rollback is the PREVIOUS credential
##           set, which must be exported and sealed BEFORE rotation begins so a failed
##           rotation can be reversed. Do not start without that export.

# 1. Rebuild rather than clean. Arista's own guidance contemplates "restoration or
#    replacement of affected orchestrator instances from trusted sources". Prefer a
#    fresh orchestrator from a trusted image with restored configuration over an
#    in-place cleanup of a host that ran attacker code.

# 2. Rotate, in this order:
#    a) VCO operator and tenant administrator credentials
#    b) VCO API tokens and service-account secrets
#    c) Orchestrator database credentials
#    d) Edge activation keys / enrolment secrets
#    e) Certificates and private key material for the orchestrator and every Edge

# 3. Validate managed device state per Arista's post-remediation guidance:
#    - compare each Edge's running configuration against a known-good baseline
#    - investigate any Edge whose config changed outside a change record
#    - confirm every tunnel re-established with the NEW key material

# 4. Review administrator activity across the full suspected exposure window, not
#    just since the advisory - the exploitation start date is unpublished.

# 5. Close the loop: re-run every query in section 8 after rotation. New hits after
#    rotation mean the attacker still has a foothold and the incident is not over.

The failure mode to avoid: patching the orchestrator, seeing no more inbound hits, and closing the ticket. If the box ran attacker code, the Edge credentials and keys it held are already gone and the patch does nothing about that. Phase 4 is not optional when Phase 2 finds anything.

Known gaps, stated plainly

• No sensor on the appliance is the dominant gap. Q3 through Q9 — six of ten queries — assume a Falcon Linux sensor on the VCO VM. If there is none, those queries return zero rows and that zero is meaningless. Your coverage then rests on Q1/Q2 estate-wide, Q10 against ingested HTTP logs, the §7 native checks, and perimeter/NetFlow records. Write down which of those you actually have.
• No atomic indicators beyond three IPs. No hashes, no domains, no webshell names, no exploit path. Every other detection in this pack is behavioural by necessity, and behavioural detections need a baseline before they can alert.
• The Edge fleet is effectively dark. VeloCloud Edges do not run a Falcon sensor. Downstream credential abuse is detectable only through Edge syslog, config-change audit and AAA logs.
• The three IPs are perishable. Infrastructure rotates. A clean Q1/Q2 result three months from now says little about exploitation that happened in July.

Validation gates for every query above are in §11 — telemetry readiness, event coverage, parser-field confirmation, a 7-day benign baseline, safe positive tests, and the promotion criteria. Nothing in this pack should be promoted to an alert before gates 4 through 6 pass in your own tenant.

Source snapshots for all nine references are stored alongside this pack in Arista-VeloCloud-CVE-2026-16812-Hunt-sources/, one plain-text file per source, so that every atomic indicator in §10 can be traced back to the text it came from.