Rapuncel Infostealer: A Microsoft-Signed Driver Turns Against EDR

A valid driver signature is a poor reason to close an investigation. In the Rapuncel campaign, researchers found a signed kernel driver used to terminate security processes while an infostealer targeted credentials.

TL;DR

• Fake GitHub repositories impersonated software vendors to deliver malware.
• The accompanying driver carried 145 security-process names as targets; that is not evidence of 145 independently tested product bypasses.
• Investigate driver loads and sensor outages together. Check which driver policies endpoints actually enforce.

From Download Lure to Kernel Access

LastPass and Delphos reported the campaign on September 17, describing findings through September 10. They identified impersonation of at least 40 companies. LastPass says its systems, services and customer vaults were not compromised.

The downloaded archive delivered payloads through DLL side-loading: a legitimate executable loads an attacker’s library. The accompanying Alinubx.sys driver used kernel-mode process termination, bypassing Protected Process Light checks. It was deployed as nvfsflt64.sys under the service name NvFsFilter, posing as an NVIDIA component. Its signature chained through Microsoft Windows Hardware Compatibility Publisher; this does not establish Microsoft authorship.

Hunt the Driver, Then the Silence

For defenders, the useful question is whether an unexpected driver load precedes the loss of endpoint visibility.

Sysmon Event ID 6 records driver loads, including configured hashes and signature information. Ensure those events reach central storage. Hunt the reported names, then correlate matches with installation activity and security-agent disconnects. These names are investigation leads, not standalone verdicts; attackers can change them.

Review detection exclusions that discard all Microsoft-signed drivers. A trusted signature should contribute context, not erase the event. Route unexpected sensor outages to investigation even when the endpoint itself produces no malware alert.

A Local Hunt for the Reported Driver Names

On Windows, the following read-only PowerShell query searches seven days of retained Sysmon driver-load events. It requires Sysmon to have recorded Event ID 6 during that period and permission to read its Operational log. It reads named XML fields rather than localized event-message text.

$filter = @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id = 6
    StartTime = (Get-Date).AddDays(-7)
}
Get-WinEvent -FilterHashtable $filter | ForEach-Object {
    $event = $_
    $data = @{}
    ([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
        $data[$_.Name] = $_.InnerText
    }
    if ($data['ImageLoaded'] -match '(?i)(^|\\)(Alinubx|nvfsflt64)\.sys$') {
        [pscustomobject]@{Time=$event.TimeCreated; Path=$data['ImageLoaded'];
            Hashes=$data['Hashes']; Signature=$data['Signature']}
    }
}

A hit means a driver with a reported filename loaded, not that Rapuncel has been conclusively identified. Compare its hash with the original report and investigate its origin. No hits only means no matching names were found in the available events: renamed files, excluded events and expired retention remain blind spots. A missing-log or access error is a collection problem, not a clean result.

Correlate Installation, Loading and Agent Health

Use this as a proposed investigation sequence, not an observed victim timeline. Start with a ten-minute window around the driver load and expand it if necessary; ten minutes is an analyst-selected starting point, not a measured campaign interval.

Event 4697 requires successful Audit Security System Extension auditing. Its ServiceType distinguishes a kernel driver (0x1) from a file-system driver (0x2). The recorded installation path is not updated if someone later changes it. Service registration alone does not prove execution.

Join by the same device identity and normalize timestamps. An unexpected service, a matching driver load and an unexplained sensor outage deserve urgent investigation together. Do not require all three before investigating: existing services and missing telemetry can leave an incomplete chain. Check legitimate driver deployments, endpoint upgrades, reboots and network outages before treating the correlation as malicious.

For a broader hunt, remove the filename condition and identify drivers newly appearing in your fleet. Prioritize those with no approved deployment and a nearby agent-health change. Maintain a known-good baseline by hash, version and deployment context; a filename or signer alone is too broad an exception.

Enforce the Boundary Before the Driver Loads

Microsoft distinguishes two controls: the ASR rule Block abuse of exploited vulnerable signed drivers prevents applications from writing covered drivers to disk; it does not prevent loading a driver already present. The vulnerable driver blocklist and App Control policies address loading.

Endpoint administrators should verify effective policy on representative machines, review audit events, and test compatibility before enforcing additional driver restrictions. Microsoft explicitly warns that the blocklist cannot cover every vulnerable driver. Enabling it is useful protection, not proof that this particular sample will be blocked.

If investigation confirms infection, isolate the host and assess credential and session exposure from a clean device. Restore endpoint trust and revoke affected sessions; restarting the security agent alone does not resolve stolen access.

What to Preserve and Scope Next

Before cleanup, preserve available event logs, the download’s origin, file hashes and the endpoint timeline through your incident-response process. If the agent is unresponsive, use an independent containment path such as network isolation at the switch or access layer. An isolation command queued to an offline agent is not completed containment.

Identity responders should establish which accounts and browser sessions were used on the host, revoke affected sessions and rotate exposed credentials from a clean device. Review subsequent sign-ins and account changes. A password reset and session revocation are separate actions; verify the identity provider’s behavior rather than assuming one performs the other.

Finally, search across other endpoints for the same hashes, download origins and service artifacts. Use the earliest matching event to widen the investigation window. If evidence supports kernel-level compromise, plan recovery from a trusted image after preserving evidence; deleting one driver is not enough to establish that the host is trustworthy again.

Related Posts

• BYOVD: How Attackers Use Legitimate Drivers to Kill Your Security Tools
• ChocoPoC: The Exploit You Cloned Is the Attack