Severed connection

The attacker’s Telegram bot received the words “Script execution started.” It was the last message of three sent by a script named Adobe_Acrobat_Reader.vbs, running on a computer inside an unsuspecting US diocese.

Fortunately, the attacker wasn’t the only one taking an interest in what was happening on that machine.

Defender disarmed

Script alerts immediately put our analyst on guard. Some are harmless, though plenty aren’t. This one flagged a Visual Basic script executing suspiciously.

It was a lengthy script. Partway through, it wrote registry values to switch off Windows Defender’s anti-spyware, real-time, and tamper protection, a move made to cut visibility and lower the odds of getting caught.

The script’s path, at the bottom of the alert, led to something resembling an Adobe Acrobat installation package ZIP sitting in the Temp folder. It was launched by wscript.exe, Windows’ built-in tool for running scripts. Real PDF installers have no business touching security settings. 

Three messages

The script queried the machine for its name, user, and operating system, then sent those details to a Telegram bot, an automated account on the messaging app. It sent a second message once it had gone after Windows security, and a third after launching msiexec, Windows’ own installer, to fetch additional payloads from an oddly named domain. Each one doubled as a status update.

Telegram is a legitimate messaging service, and to the untrained eye, traffic to it reads as unremarkable. What the script did with it was another matter entirely. Gathering system details and posting them to a bot is textbook reconnaissance.

A Flight Recorder search confirmed the outbound connection to a Telegram domain, and within about a minute of looking it over, the case was clear cut.

Our analyst:

• Isolated the endpoint, cutting its communication with the Telegram chat.
• Started a remediation action to kill the processes behind the script.
• Blocked the domain the script had reached out to for additional payloads.
• Found no evidence of persistence and sent the customer a report with remediation steps.

The script had reported each stage to the attacker’s chat, and the device’s basic details were already out. Isolation made sure nothing more from that machine would get through.

The customer planned to take the machine out of service, before deciding whether to wipe and reinstall it or replace it.

Caught early

The attacker’s goal was never confirmed, because the attack was stopped too early in its chain to show signs of ransomware.

But the installer the script launched was meant to bring in the next phase of the attack, on a machine whose built-in protections it had just tried to switch off. Had the attack continued unchecked, it could have exposed usernames and passwords and opened a path from one desktop toward the rest of the diocese’s network, where we watch over 53 machines.

Because of MDR, that didn’t happen.

Threat actors lean on legitimate tools to blend in, and this script leaned on them at every stage: Windows’ built-in script host to run, Windows’ own installer to fetch its next payload, and a messaging service people use every day to report home. What gave it away was behavior, and reading behavior takes someone who knows what to look for.

---

Reconstruction

From first signal to full handover