The Backup Exclusion That Became a Blind Spot

Treat the missing file telemetry as a collection problem before it becomes a conclusion problem. Order:

1. Acquire the artefact, don't infer it. Use live response to pull the DLL, its directory listing, timestamps, and the scheduled task XML from one host. Hash it, check Authenticode signer and whether the certificate chains to a legitimate publisher, and submit to a sandbox and multi-engine reputation. A Veeam-signed component with a valid chain looks very different from an unsigned DLL dropped last Tuesday.
2. Establish whether it is fleet-wide or unique. Query all 850 hosts for rundll32 with the same parent path. A backup component appears on backup servers; a backdoor appears on the three hosts the actor reached. Uniqueness is a strong discriminator.
3. Rebuild the execution chain from what is left. Task Scheduler creation (4698/4702), service creation (7045), Amcache and Prefetch, WMI event subscriptions, and recent file writes elsewhere on disk - the dropper probably wrote outside the excluded path too.
4. Get the network picture the firewall hid. Live response netstat/connection table and a packet capture on one host for 30 minutes gives you destination, JA3, and beacon interval, which the hourly byte aggregation cannot.
5. Check credential exposure. Shared local admin password plus three compromised hosts means lateral movement is plausible; query 4624 type 3 and 4648 on other hosts for that account.

Only after steps 1 and 4 fail to explain the activity would I call it benign. Absence of hash data is not absence of malice - it is absence of visibility.

The exclusion was a reasonable performance decision with an unreasonable implementation. Path-based exclusions exclude everything that ever lands in that folder, so anyone who can write there inherits the blind spot - and a staging directory is exactly where a backup service account writes on a schedule.

Replacement design:

• Exclude by signer or hash of the backup binaries, not by directory. Veeam's executables carry a stable publisher certificate; scanning can skip those processes while still scanning anything else that appears in the folder.
• Constrain write access. ACL the staging directory so only the backup service account can create files. A user-context process writing there becomes both impossible and detectable.
• Add file integrity monitoring on the directory, alerting on any file creation whose signer is not the backup vendor, plus any DLL creation at all if the backup product does not legitimately drop DLLs.
• Detect the execution pattern. Alert on rundll32, regsvr32, or svchost-spawned DLL loads from user-writable directories, and on scheduled tasks whose action points into staging paths. These fire regardless of scan exclusions.
• Govern the exclusion list. Every exclusion carries an owner, a business justification, a review date, and a compensating control reference. Review quarterly; 14-month-old exclusions with no owner are the norm and should not be.
• Instrument the performance claim. Measure agent CPU and backup window duration before and after removing the path exclusion so the change can be defended to the backup team with data.

The general principle: never exclude a location an attacker can write to without adding detection that covers the same location by another means.

It changes both timing and scope. Normally you contain in order of severity, one host at a time, verifying as you go. With a shared local admin credential on a Tuesday-to-now dwell time, you must assume credential theft already happened and act concurrently.

Revised sequence:

1. Contain all three simultaneously - network quarantine via switch ACL or agent isolation, preserving EDR management traffic so you keep telemetry. Sequential isolation gives the actor time to move off a host you have not reached yet.
2. Rotate the shared credential immediately, estate-wide, and treat every host where that account has logged on interactively or over SMB as in scope until disproven. Use LAPS or a managed local-admin solution rather than another manually shared password.
3. Hunt the credential use before the attacker retools: 4624 logon type 3 with that account, 4648 explicit credentials, 5140/5145 share access, and SMB scans from the three hosts in the preceding days.
4. Preserve before cleaning. Memory capture and disk images on at least one host before reimaging, otherwise attribution and scope estimation rest entirely on process telemetry you already know is thin.
5. Check the backup infrastructure itself. The staging directory is written by the backup service account, which is often domain-privileged; if that account is compromised the blast radius is the whole estate, not three servers.

Only after the credential is rotated and lateral movement is ruled out do you return to normal per-host remediation and reimage.