# KernelHawk ScreenConnect RAT remediation This tool audits and removes the specific ScreenConnect instance installed by the 2026-08-12 `SPECIAL PARTY INVITATION` malware chain. It is bound to instance `fa12121053c2d7fe`, relay `relay.rupilure.top` at `74.120.121.48:8041`, MSI product code `{1512A1A9-AF5F-B443-AFD0-CB33309C9829}`, credential-provider CLSID `{6FF59A85-BC37-4CD4-232E-D6E8F83B1EAE}`, and the known payload hashes. Unrelated ScreenConnect installations are outside this tool's scope. A product name alone never triggers quarantine. The instance folders must match the exact instance id. The disguised `%ProgramData%\Windows Security` folder is quarantined only when a file, folder name, or configuration value beneath it carries an identifier from this incident. Other remote-access software is reported for a human decision and left alone. Files are moved into quarantine under `%ProgramData%\KernelHawk-ScreenConnect-Remediation`, where they remain available for recovery. Registry keys are exported before removal. The audit engine also writes evidence for each targeted persistence item to `cleanup-evidence` in that run's audit folder before removing it. This applies to: - scheduled tasks - autorun values - IFEO debuggers - WMI subscriptions - firewall rules - Defender exclusions - startup files The relay name is never resolved or contacted: the script reads the local DNS cache instead, so cleaning a host does not announce itself to the campaign's own infrastructure. No audit output is sent to KernelHawk or anywhere else; it stays under `%ProgramData%\KernelHawk-ScreenConnect-Remediation`. A run may still produce network traffic through services already configured on the computer. The audit validates file signatures with `Get-AuthenticodeSignature`, which may retrieve certificate revocation data from a certificate authority. `/apply` starts Microsoft Defender; its cloud protection may communicate with Microsoft or submit a sample if your policy enables it. On an isolated machine, expect signature checks to be slower while those lookups time out. Run from an elevated Command Prompt (`cscript`, not `wscript` -- the script refuses to run under the windowed host, where its output would be several hundred dialog boxes): ```bat cscript //nologo remediate_party_invitation_rat.vbs cscript //nologo remediate_party_invitation_rat.vbs /apply ``` The first command only audits; `/apply` follows the fixed sequence below. 1. Take the pre-remediation snapshot. 2. Perform a read-only network check. 3. Export targeted registry keys and verify the evidence gate. 4. Create a restore point. 5. Stop the target processes and service. 6. Invoke the exact MSI uninstall. 7. Remove the target service and the malicious URL scheme. 8. Remove the credential-provider persistence and clean the ScreenConnect LSA entry. 9. Quarantine hash-matching droppers and target folders. 10. Remove the evidence-gated persistence items listed above when they carry a confirmed incident marker. 11. Take the post-remediation snapshot. 12. Start a Defender Quick Scan. `/apply` refuses to start if `full_audit.ps1` is not in the same folder, and it stops before changing anything if the pre-remediation audit does not complete, because that snapshot is the only record of how the machine was found. Hash-matching droppers are looked for in every local user profile, not only the profile of the account running the elevated prompt. Each targeted item must be recorded before removal. A registry key without a verified export stays in place. The same fail-closed rule applies when the tool cannot write evidence for any targeted persistence item listed above. The reason is recorded in `audit-errors.csv`. That check is also applied as a whole, and it is applied early. Registry evidence is captured and verified before anything on the machine is touched, so if any targeted key exists and could not be exported, `/apply` stops before the restore point, before any process is terminated, before the service is stopped, and before the MSI uninstall, service delete, registry or LSA change, quarantine, indicator cleanup and Defender scan. When it stops there, the only things written are the log, the pre-remediation audit snapshot, and whichever registry exports did succeed. Audit mode accepts a partial snapshot and labels it partial. Before remediation, `/apply` requires an audit with no recorded errors because that snapshot is the only justification for changing the machine. After remediation, it requires another error-free audit to verify the cleanup. A partial post-remediation audit exits nonzero and directs you to `audit-errors.csv`; until those errors are resolved, treat the machine as unverified. When that happens the script does not say the remediation completed. It reports that the remediation actions finished but verification failed, tells you not to treat the computer as clean, and exits 3. Only a run whose post-remediation verification finished cleanly prints "Remediation completed". Exit codes: 0 success, 3 the audit did not complete, 4 wrong script host (use `cscript`), 5 `/apply` without an elevated prompt, 6 `full_audit.ps1` missing, 7 `/apply` stopped because the pre-remediation audit failed, 8 `/apply` stopped because registry evidence could not be preserved. ## Validation status Audit mode has been run end to end on a clean Windows 11 host: it completes in about a minute, records no audit errors, and reports no campaign findings on a machine that does not have this infection. The `/apply` path has NOT been exercised against a live infection. It is indicator-bound and fail-closed by design, and its refusal paths are tested, but no run has yet removed this malware from a real machine. Treat it accordingly: run the audit first, read it, and try `/apply` on a disposable or backed-up system before you use it on one you cannot rebuild. The full audit records the following evidence: - active TCP and UDP activity - listeners - process hashes and signatures - services - scheduled tasks and autoruns - IFEO debuggers - permanent WMI subscriptions - startup folders - local accounts and administrators - Defender settings and exclusions - firewall rules - proxies - DNS state - routes - remote-access state and software - current interactive and SMB sessions - BITS transfers - Windows Firewall connection history - recent executable and script files - Security event logs - RDP event logs - WinRM event logs - DNS event logs - OpenSSH event logs - PowerShell event logs - WMI event logs - Defender event logs - task event logs - account event logs - service event logs Results are written beneath `%ProgramData%\KernelHawk-ScreenConnect-Remediation\Audits`. Alternative footholds are ranked in `findings.csv`, `findings.json`, and `SUMMARY.txt`. The tool automatically removes only indicators proven to belong to this incident. It reports other remote-management tools and suspicious persistence for review so approved business tooling is not destroyed. After `/apply`: 1. Reboot and run Microsoft Defender Offline scan. 2. Rotate passwords from a known-clean device. 3. Review the identity logs. 4. Review email and remote-access logs. 5. Review client data logs. A cleanup script cannot prove that credentials or copied data remain confidential. ## Open-source status The MIT License governs this community remediation. Forensic acquisition, incident-response support, and credential rotation remain separate tasks. If the system's integrity cannot be established, rebuild it.