# AlomSec 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.

It does not remove unrelated ScreenConnect installations. Nothing is quarantined
on the strength of a product name: the instance folders are matched by their
exact instance id, and 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. Remote-access software that carries no
such identifier is reported for a human decision and left alone.

Files are moved into quarantine under
`%ProgramData%\Argus-Omni-ScreenConnect-Remediation`; they are not permanently
deleted. Registry keys are exported before removal, and every scheduled task,
autorun value, IFEO debugger, WMI subscription, firewall rule, Defender
exclusion, and startup file the audit engine removes is written to
`cleanup-evidence` in that run's audit folder first.

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 AlomSec or anywhere else; it stays
under `%ProgramData%\Argus-Omni-ScreenConnect-Remediation`.

That is not the same as saying the run produces no network traffic. The audit
validates file signatures with `Get-AuthenticodeSignature`, which may retrieve
certificate revocation data from a certificate authority, and `/apply` starts
Microsoft Defender, whose cloud protection may communicate with Microsoft or
submit a sample if your policy enables it. Both use services this computer is
already configured to use. 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 is audit-only. The second takes a pre-remediation snapshot,
stops the target service and processes, invokes the exact MSI uninstall, removes
the target service, URL scheme and credential-provider persistence, cleans the
ScreenConnect LSA entry, quarantines hash-matching droppers and target folders,
removes any scheduled tasks, autoruns, WMI subscriptions, IFEO debuggers,
firewall rules, or Defender exclusions containing the confirmed incident
markers, takes a post-remediation snapshot, and starts 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.

Nothing is removed until it has been written out first. If a registry key cannot
be exported, that key is not deleted; if a scheduled task, autorun value, IFEO
debugger, WMI subscription, firewall rule, Defender exclusion, or startup file
cannot be written to `cleanup-evidence`, that item is left in place and 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.

The order under `/apply` is: pre-remediation audit, read-only network check,
registry export and evidence gate, restore point, stop the RAT processes and
service, uninstall and remove persistence, quarantine, post-remediation audit,
Defender scan.

Audit mode accepts a partial snapshot and says so. `/apply` does not, at either
end: the pre-remediation audit must finish with no recorded errors because it is
the only justification for destroying anything, and the post-remediation audit
must finish with no recorded errors because it is the verification that the
cleanup worked. A partial post-remediation audit exits nonzero and tells you to
read `audit-errors.csv` before treating the machine as cleaned.

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 active TCP and UDP activity, listeners, process hashes
and signatures, services, scheduled tasks, autoruns, IFEO debuggers, permanent
WMI subscriptions, startup folders, local accounts and administrators, Defender
settings and exclusions, firewall rules, proxies, DNS, routes, remote-access
state and software, current interactive and SMB sessions, BITS transfers,
Windows Firewall connection history, recent executable/script files, and
Security, RDP, WinRM, DNS, OpenSSH, PowerShell, WMI, Defender, task, account,
and service event logs. Results are written beneath
`%ProgramData%\Argus-Omni-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`, reboot and run Microsoft Defender Offline scan. Rotate passwords
from a known-clean device and review identity, email, remote-access, and client
data logs. A cleanup script cannot prove that credentials or copied data remain
confidential.

## Open-source status

This community remediation is distributed under the MIT License. It is not a
replacement for forensic acquisition, incident-response support, credential
rotation, or rebuilding a system whose integrity cannot be established.