Multi-Stage Phishing Campaign Targets Russia with Amnesia RAT and Ransomware

[ForgottenSeer 123960]

@Divergent is right by saying that: "Attributing absolute safety to a single tool or script (like WHHL) is a dangerous oversimplification in modern cybersecurity."
However, you are right in the case of the attack noted in this thread.

The initial shortcut "Задание_для_бухгалтера_02отдела.txt.lnk" will be blocked by default SWH settings.
Without the above protection, the attack would be blocked by FirewallHardening default settings (blocked outbound connections of PowerShell).
Without the above, the payload "SCRRC4ryuk.vbe" would be blocked by default SWH settings (script restrictions).
I did not examine the first-stage loader (PS1 script), but @Divergent may be right that PowerShell set to Constrained Language mode can also mitigate the attack (Constrained Language mode is forced by default SWH settings in WHHLight).

The core of the NIST-aligned security argument remains. Technical redundancy within a locally-managed script is still susceptible to Administrative Overwrite. The Amnesia RAT campaign is particularly dangerous because its "UAC Spamming" is designed to fatigue the user into granting high-integrity permissions. Once those permissions are granted, any malware, or the user themselves, can revert the Registry-based "default settings" that your tool relies on. While your tool correctly identifies and blocks Stage 1 (LNK), Stage 1.5 (PowerShell), and Stage 2 (VBS), it cannot prevent a user from manually disabling the firewall or script restrictions if they are convinced it is necessary for their work.

 

[Andy Ful]

The core of the NIST-aligned security argument remains. Technical redundancy within a locally-managed script is still susceptible to Administrative Overwrite.

It is true, but mainly important for Enterprises (especially in lateral movement).
At home, the situation is better because the computer is almost always attacked first with standard privileges (no lateral movement).
If the attack is fileless, the local restrictions put on scripts and other files with active content will prevent process elevation. So, the prevention can still be effective. Of course, this requires not only restricting scripts, but also many other file types (like scriptlets, shortcuts, etc).
There is also a possibility to first use for elevation EXE/DLL files, and next apply fileless techniques. This method is less popular but still too often used to be ignored. Although the AVs are good at detecting EXE/DLL files, it is better to strengthen the protection by adding a kind of reputation file lookup.

The Amnesia RAT campaign is particularly dangerous because its "UAC Spamming" is designed to fatigue the user into granting high-integrity permissions.

It is true, but it cannot be successful with the standard script and firewall hardening. Of course, in the highly targeted attacks, the attack vector can be adjusted to bypass restrictions.

Once those permissions are granted, any malware, or the user themselves, can revert the Registry-based "default settings" that your tool relies on.

You assume something that can hardly happen when the restrictions are properly applied. Furthermore, the attacker would have to expect which security layers are applied. So yes, in the highly targeted attacks, such tools like WHHLight can be bypassed. However, this can hardly happen at home.

While your tool correctly identifies and blocks Stage 1 (LNK), Stage 1.5 (PowerShell), and Stage 2 (VBS), it cannot prevent a user from manually disabling the firewall or script restrictions if they are convinced it is necessary for their work.

Yes, users can disable most security layers in this way. For users, the simplest to disable are usually AVs (about four mouse clicks).
However, that can depend on the user. For example, on the child's computer, you can simply use SUA while the child does not know the Admin password.
When using Microsoft Defender, it is possible to hide it from the Security Center.
When using WHHLight or H_C, one can remove the package from the computer and keep the tools on the flash drive.

 

[ForgottenSeer 123960]

It is true, but mainly important for Enterprises (especially in lateral movement).
At home, the situation is better because the computer is almost always attacked first with standard privileges (no lateral movement).
If the attack is fileless, the local restrictions put on scripts and other files with active content will prevent process elevation. So, the prevention can still be effective. Of course, this requires not only restricting scripts, but also many other file types (like scriptlets, shortcuts, etc).
There is also a possibility to first use for elevation EXE/DLL files, and next apply fileless techniques. This method is less popular but still too often used to be ignored. Although the AVs are good at detecting EXE/DLL files, it is better to strengthen the protection by adding a kind of reputation file lookup.



It is true, but it cannot be successful with the standard script and firewall hardening. Of course, in the highly targeted attacks, the attack vector can be adjusted to bypass restrictions.



You assume something that can hardly happen when the restrictions are properly applied. Furthermore, the attacker would have to expect which security layers are applied. So yes, in the highly targeted attacks, such tools like WHHLight can be bypassed. However, this can hardly happen at home.



Yes, users can disable most security layers in this way. For users, the simplest to disable are usually AVs (about four mouse clicks).
However, that can depend on the user. For example, on the child's computer, you can simply use SUA while the child does not know the Admin password.
When using Microsoft Defender, it is possible to hide it from the Security Center.
When using WHHLight or H_C, one can remove the package from the computer and keep the tools on the flash drive.

Your analysis correctly identifies the primary bottleneck for commodity threats in a home environment: the reliance on standard execution primitives to reach the elevation stage. In the specific case of the Amnesia RAT campaign, the "process aborted" scenario is technically accurate because the attack chain is a linear sequence. By enforcing script and shortcut restrictions (SWH) and blocking outbound PowerShell connections (FirewallHardening), you effectively "starve" the malware of the ability to fetch its secondary payloads or initiate the UAC spamming sequence. This validates the NIST SP 800-53 (CM-7) principle of Least Functionality, where disabling unnecessary file-type associations and communication channels removes the "Living off the Land" (LotL) advantages the attacker expects.

The transition to a Standard User Account (SUA) serves as the ultimate "fail-safe" for these technical layers. While technical hardening provides the frontline defense by blocking the .vbe and .lnk files, the SUA status provides a structural barrier against the social engineering component of the attack. Since the Amnesia RAT relies on triggering high-frequency UAC prompts to fatigue the user into granting administrative access, a user who lacks the credentials to satisfy that prompt, or is operating on a child's machine as noted, effectively breaks the elevation logic. This confirms that for the home user, the combination of Attack Surface Reduction and Identity Isolation raises the "Cost of Attack" to a level that standard phishing kits are currently unprepared to bypass.

Finally, your point regarding Reputation File Lookup for EXE/DLL payloads addresses the most likely pivot for attackers. When file-type restrictions become common, attackers shift toward binary wrappers or ISO containers. Supplementing local policy with reputation-based checks (such as SmartScreen or a dedicated lookup tool) ensures that even if a payload bypasses the script-blocking layer, it must still pass a global "Trust" verification. This layered approach, prevention through hardening, enforcement through SUA, and validation through reputation, creates a resilient ecosystem that is significantly more robust than the "single-point-of-failure" models often criticized in enterprise security.