Silver Fox Abuses Microsoft-Signed WatchDog Driver amsdk.sys to Deploy ValleyRAT

Overview

Security researchers attribute a Bring Your Own Vulnerable Driver (BYOVD) campaign to a threat actor known as Silver Fox that leverages a previously unknown vulnerable Windows kernel driver to neutralize endpoint defenses and deploy ValleyRAT. The vulnerable component is a 64-bit, validly signed kernel device driver named amsdk.sys (version 1.0.600), distributed as part of WatchDog Anti-malware.

The threat actor known as Silver Fox has been attributed to abuse of a previously unknown vulnerable driver associated with WatchDog Anti-malware as part of a Bring Your Own Vulnerable Driver (BYOVD) attack aimed at disarming security solutions installed on compromised hosts.

Background & why this matters

BYOVD attacks exploit legitimate, signed third‑party kernel drivers that contain vulnerabilities. Because these drivers are signed and execute at kernel privilege, attackers can load them into the kernel to perform powerful actions—disabling security controls, tampering with memory protections, and evading detection. The abuse of a Microsoft‑signed driver is particularly concerning because Windows’ trust model treats signed kernel drivers as high‑assurance code, and many enterprise controls implicitly trust such artifacts.

ValleyRAT is a remote access trojan (RAT). RATs provide remote control, data exfiltration and credential harvesting capabilities to operators once they achieve persistence on a target. When combined with a kernel‑level foothold obtained through a vulnerable signed driver, the ability of defenders to detect and remediate such intrusions is substantially degraded.

Technical analysis and practitioner commentary

At a technical level, the reported campaign follows the BYOVD playbook: adversaries obtain or reuse a legitimate, signed driver that contains an exploitable vulnerability; they load or install the driver on a compromised host; and they exploit the flaw to perform kernel‑level operations that disable endpoint protections or hide malicious artifacts. The final payload observed in this instance is ValleyRAT.

Key practical implications for defenders:

• Signed does not mean safe: Code signing establishes provenance and non‑repudiation, but it does not guarantee the absence of bugs or vulnerabilities. Attackers are increasingly weaponizing that trust relationship.
• Kernel abuse elevates stakes: Exploiting a kernel driver vulnerability can allow malware to bypass user‑mode defenses, tamper with telemetry, and persist across reboots. Traditional detection tools that operate in user mode may be blind to these activities.
• Supply chain and vendor hygiene matter: Vulnerable drivers distributed by legitimate vendors can become attack vectors if not updated and if systems allow their use without additional validation.

Comparable cases and industry context

The abuse of legitimate signed drivers to achieve kernel privileges has been observed broadly in the industry and is a recognized technique in adversary toolkits. While specifics of each campaign vary, the underlying pattern—using a signed component with a latent vulnerability to bypass security controls—has been repeatedly documented and warned about by security vendors and incident response teams.

Enterprises should view this incident within that larger trend: signed drivers and other trusted components are attractive for attackers because they help evade controls that primarily rely on signature trust and process‑level monitoring.

Detection, mitigation and recommendations for practitioners

Defenders can reduce risk and improve detection by combining short‑term compensating controls with longer‑term hardening:

• Visibility and telemetry
• Monitor kernel driver loads and service creation events. Maintain logs of loaded kernel modules and correlate them with inventory and known good builds.
• Collect and analyze network telemetry for signs of RAT activity such as unexpected outbound connections, uncommon protocols, or long‑lived command‑and‑control sessions.
• Harden driver policies
• Implement and enforce driver signature validation policies where possible (e.g., enable code integrity and driver signing checks). Consider Windows features such as Device Guard / Windows Defender Application Control (WDAC) to restrict which drivers may load.
• Use Secure Boot and Hypervisor‑protected Code Integrity (HVCI) to raise the difficulty of arbitrary kernel modifications.
• Restrict administrative access
• Limit which accounts can install drivers or create kernel‑mode services. Apply strict least‑privilege controls and reduce the number of administrators who can install device drivers.
• Compensating operational controls
• Establish allowlists/denylists for kernel drivers based on file hashes and publisher metadata. When a vulnerable signed driver is identified, distribute denylist entries until a vendor fix is available.
• Patch and update vendor‑supplied security tools promptly. Where possible, coordinate with the vendor to obtain and deploy updated drivers or mitigations.
• Hunt and respond
• Perform threat hunting for indicators of ValleyRAT behavior—remote command execution, unusual service or driver activity, and persistent scheduled tasks or autoruns.
• When a suspected BYOVD event is detected, capture kernel memory and relevant artifacts for forensic analysis and preserve logs for incident response and potential vendor notification.

Actionable immediate steps for organizations that discover amsdk.sys or suspect related activity:

• Isolate affected hosts from the network, collect volatile and persistence evidence, and engage incident response resources.
• Query enterprise telemetry for presence of amsdk.sys version 1.0.600 and for processes that loaded the driver or interacted with it.
• Apply temporary controls (blocklist driver hash, restrict driver installation via policy) and pursue vendor remediation updates.

Potential risks and broader implications

There are several risks raised by this campaign that affect both security posture and operational resilience:

• Detection evasion: Kernel‑level tampering can suppress or tamper with endpoint telemetry, making detection and attribution harder for defenders.
• Persistence and impact: Access obtained via a kernel vulnerability can be durable across reboots and enable broad system compromise, including data exfiltration and lateral movement.
• Trust model erosion: Repeated abuse of signed vendor drivers can erode organizational trust in software supply chains and force more restrictive policies that may break legitimate deployments.

Organizations should assume that signed components are not immune to exploitation and plan defenses accordingly: inventory, restrict, monitor, and apply layered controls so that a single vulnerable artifact cannot result in full compromise.

Conclusion

The Silver Fox campaign demonstrates a persistent and effective adversary strategy: weaponize legitimate trust. The abuse of a Microsoft‑signed WatchDog Anti‑malware driver (amsdk.sys v1.0.600) to deploy ValleyRAT underscores that signing alone does not equal safety. Defenders must increase visibility into kernel activity, tighten driver policies and administrative controls, and treat third‑party drivers as potential attack vectors. Rapid detection, containment and coordinated vendor remediation are essential to reduce risk and prevent similar BYOVD attacks from enabling stealthy, kernel‑level intrusions.

Source: thehackernews.com