Beware: a fake "bank payment" installs covert remote access to your computer

An analysis of a real threat we detected and investigated. This article has two parts: the first is for all users (how not to get caught), the second is technical, for system administrators.

A phishing campaign disguised as bank payment documents has been gaining traction. The email looks businesslike, with a "payment" in the attachment. In reality it hides malware that tries to install a covert remote-access tool — effectively handing control of your computer to an attacker. The worst part: at the time of the attack, most antivirus products barely detect this threat.

Here's how it works, how to recognize the danger, and what to do to protect yourself.

Part 1. For users: what the attack looks like and how to avoid it

Step 1. The email with a "payment"

It all starts with an ordinary-looking email. The subject line is about a payment, an invoice, or a payment order. The attachment is an archive (usually .rar) with a name like "Payment", including a date and an invoice number. The bank name in the file name is also part of the lure, to make it look convincing.

An example phishing email with an archive attachment.

Step 2. A file pretending to be a document

If you open the archive, inside is a file named something like Payment_...950008.pdf. It looks like a PDF document. But it's a trick: the file's real name ends with .pdf.js — meaning it's not a document but a script (a program). By default, Windows hides the .js part, so the person sees only "…pdf" and assumes they're opening a payment document.

Double extension: the file looks like a "pdf" but is actually an executable ".js" script.

This is the main thing people fall for. A real payment document is a PDF, Word, or Excel file. A file with a .js, .vbs, .exe, or .scr extension is never a document — it's a program.

Step 3. A fake window to distract you

If you run this file, a decoy window appears on screen — for example, a message saying "Windows is no longer supported". Its only purpose is to divert your attention while the real work happens in the background.

The decoy window. While the user reads it, the malicious payload is being prepared in the background.

Step 4. The request for administrator rights

Next the program starts insistently asking for administrator rights — a system UAC window appears (asking permission to make changes). If you click "No" or close it, it appears again and again, to pressure the person into eventually agreeing.

The administrator rights request. This is where everything is decided — do NOT agree.

Here's the key defensive moment: until you click "Yes" in this window, the malware won't install. If you see such a window after opening a suspicious file — click "No", close everything, and contact your IT specialist.

🚩 User checklist: how not to get caught

• Don't open archive attachments from emails about a "payment" or "invoice" unless you were expecting exactly this document from exactly this sender.

• Enable file extensions in Windows (File Explorer → View → check "File name extensions"). Then you'll immediately see the real file type.

• A file with a .js, .vbs, .exe, .scr, or .cmd extension is not a document. A real payment document is a .pdf, .docx, or .xlsx.

• Never agree to an administrator rights request if you don't understand which program is asking and why.

• If you're unsure about a payment — call the counterparty or the bank using an official number, not the contacts from the email.

• If you've already opened a suspicious file — disconnect from the network and contact an IT specialist; don't just try to "close it".

Part 2. Technical analysis (for specialists)

Below is a detailed breakdown of the attack chain, indicators of compromise (IOCs), and defensive recommendations. This part will be useful for system administrators and information security professionals.

Overview (kill chain)

The full chain: from phishing email to backdoor installation.

How it works, step by step:

1. Delivery. A phishing email with a RAR archive disguised as a bank payment.

2. Lure. Inside is a JScript file with a double extension .pdf.js (real type: JScript). The file is padded with junk code to roughly 8 MB to hinder analysis and evade scanners by size/signature.

3. Execution. The file runs via wscript.exe. The script contacts an external server (Cloudflare R2) and downloads an MSI installer from it via the msxml6.dll component (MSXML), saving it into C:\ProgramData\. In parallel it opens a genuine Microsoft support page ("what does it mean if Windows isn't supported") in the browser as a distraction.

4. Persistence. A VBS script is written to the user's Startup folder, running on every login.

5. Escalation. The VBS calls ShellExecute … "runas" in a loop — repeatedly requesting UAC elevation until the user consents.

6. Silent install. After consent, a helper script runs msiexec /i "…DAOGCLFRGMQNKN.msi" /qn — a silent MSI installation.

7. Payload. The payload is RemoteUtilities, a legitimate remote-access tool deployed covertly. Effectively a full remote-control backdoor.

A key finding from analysis in an isolated environment: the payload (MSI) is not embedded in the script — it is downloaded from the network. We ran the sample in a virtual machine with no internet access, and the script failed precisely at the network-request stage (msxml6.dll: The server name or address could not be resolved); the MSI never appeared. This means: blocking the source host at the perimeter completely breaks the attack, even if the user has already run the file. The decoy window still appears — but without network access, nothing further happens.

Process tree in the sandbox: wscript launches the browser to the decoy page and drops the MSI.

Why antivirus barely detects the threat

At the time of investigation, detection was very low — a handful of engines out of 60+ on VirusTotal. Reasons:

• Obfuscation by volume. The JS body is padded with thousands of lines of meaningless "junk" code (empty functions, fake comments), among which only a few dozen lines of real logic hide. This dilutes the signature.

• A "legitimate" payload. RemoteUtilities is not a virus but a commercial remote-access product. Antivirus flags it at most as a potentially unsafe application, not as a threat. What makes it malicious is only the way it's deployed (covert silent install).

• Anti-analysis. The sample shows signs of sandbox evasion (long sleeps, to outlast automated analysis).

Low detection on VirusTotal — most antivirus products missed the threat at the time of the attack.A fragment of obfuscated code: thousands of lines of "junk" hide the real logic.

Takeaway for specialists: relying on an antivirus verdict alone is not enough here. Whether the chain executed is more reliably confirmed through execution forensics (Prefetch, marker files, presence of payload services/processes) and behavioral analysis, rather than signature detection.

What the attacker gains

RemoteUtilities gives the attacker full remote access: desktop control, file transfer, command line. According to the behavioral analysis, the techniques include stealing session cookies (MITRE ATT&CK T1539) — hijacking authenticated browser sessions.

MITRE ATT&CK techniques recorded in the behavioral report.

Indicators of compromise (IOCs)

For hunting within your infrastructure and blocking at the perimeter:

Additional trick: the email's HTML body embeds a logo and the text "Add to Drive / Scanned by Gmail" — mimicking the Google Drive interface to make the link look legitimate. In reality it points not to Drive but to the attacker's R2 hosting.

Note: the specific source host in the r2.cloudflarestorage.com domain should be blocked precisely — this is a legitimate Cloudflare service, and blocking it wholesale would harm other services.

🛡 Defensive recommendations

For users and workstations:

• Enable file extension display via GPO — so double extensions are visible.

• Block .js, .vbs, .wsf, .hta attachments at the mail gateway.

• Don't disable UAC. In this incident, a lowered UAC level was a genuine weak link.

Radical measure (kills the entire attack class):

• Disable Windows Script Host via policy where it isn't needed: HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings\Enabled = 0 (via GPO). The whole chain starts through wscript.exe — without WSH, the .js dropper won't run at all.

For detection (Sysmon / SIEM):

• Rule: wscript.exe / cscript.exe initiating an outbound network connection.

• Rule: creation of an MSI (PE file) in C:\ProgramData\.

• Rule: appearance of VBS files in Startup folders.

• Enable process creation auditing (Event ID 4688) with command line.

Conclusion

This is an example of a competently executed but not "elite" attack: it relies not on technical sophistication but on human inattention — a hidden file extension, a fake window, and an insistent rights request. The main defense is not the antivirus (which barely sees this threat) but user attentiveness and basic organizational measures: showing file extensions, blocking scripts in email, and disabling WSH where it isn't needed.

If you've received a similar email or have doubts about your computer's security — contact IT-Master, and we'll help check and protect your system.