When a “Screensaver” Became a Foothold: How We Caught a Multi Stage RAT Before It Stuck
How a Seemingly Harmless File Almost Gave Attackers a Lasting Presence, and How We Stopped It
A file that looks safe can still be dangerous.
In this case, what appeared to be a harmless “screensaver” file was actually the opening move in a carefully staged attack. The goal wasn’t immediate disruption. It was to quietly gain control of a single device and keep that access open for later use.
Here’s how our analysts spotted the warning signs early, understood what was really happening, and shut it down before it could take hold
What First Caught Our Attention
The investigation didn’t begin with how the file looked, but with what it did.
Within minutes of a user opening what they believed was a screensaver file, Microsoft Defender raised a behaviour‑based alert. The alert showed the file launching a standard Windows networking tool and using it to make encrypted connections to the internet. Something a screensaver should never need to do.
More concerning still, that same tool began spawning hidden background processes and quietly downloading additional files.
In technical terms, a digitally signed file with a strong reputation signals had triggered built‑in Windows utilities to carry out covert network communication and stage further components. In plain terms, a file that looked safe was behaving in ways it simply shouldn’t.
That gap between appearance and behaviour was the first clear signal that something more serious was underway.
Screenshot: Microsoft Defender alert thread showing curl.exe spawned by a user‑launched .scr with hidden cmd.exe child
How the Attack Unfolded: Key Stages Observed from Alert to Containment
Once the file was opened, events unfolded quickly.
Stage 1: Initial Execution and In-Memory Activity
Once the user opened what they believed was a legitimate screensaver file, it immediately contacted an external site under the guise of verification. This interaction was used to retrieve a small, disguised file that injected malicious code directly into memory, minimising artefacts left on disk.
Stage 2: Covert External Communication (LOLBins)
The activity then shifted to encrypted outbound communications. To evade detection, the malware leveraged signed Windows utilities, principally curl.exe, invoked by the .scr, with a hidden cmd.exe brokered via a named pipe, to establish TLS sessions and fetch the next stage.
It established encrypted connections to multiple attacker-controlled systems and quietly pulled down follow-on components. This is classic living-off-the-land behaviour: using trusted, pre-installed tools to make command-and-control and staging look like routine admin activity.
Stage 3: Staged Payload Delivery
The malware retrieved a password‑protected archive (XmpStart.7z) and, via a hidden cmd.exe invoking 7z.exe, silently extracted its contents—dropping XmpStart.exe, Update.exe, and a companion DLL to keep the attack moving without a visible window. A second archive (Valve.7z) was staged later in the intrusion to extend capability and durability.
In plain terms, the attackers packed the next tools into locked archives so basic checks couldn’t see inside, then quietly opened them in the background to install the next pieces, without drawing attention.
Stage 4: Persistence and Resilience
One of these programs configured itself to run automatically whenever the user logged in, ensuring access would survive a reboot. It also shifted communication duties to another process, spreading activity across multiple programs to make detection more difficult. During this stage, parts of the malware briefly failed but restarted automatically. An indication of operational resilience rather than failure.
Stage 5: Expansion and System Reconnaissance
A second archive introduced another program that created its own automatic restart mechanism, gathered information about the operating system and installed security software via WMI, and opened an additional communication channel back to the attacker. This activity pointed to preparation for longer‑term access rather than immediate disruption.
Containment:
By stage 5, multiple beacons were active and more than one persistence mechanism was in place. Most of these steps executed automatically within minutes of the user launching the “screensaver.” As soon as telemetry confirmed concurrent beacons and newly created logon persistence (still within the initial response window and before signs of lateral movement), the analyst isolated the affected device. Isolation immediately cut off external communications and prevented further command execution, lateral movement or data access.
Screenshot: Process tree view highlighting .scr → curl.exe → hidden cmd.exe → 7z.exe → XmpStart.exe chain with twin persistence points
Incident Progression
How the incident unfolded
The attack began with a socially engineered PDF sent through the customer’s normal communications platform. That document prompted the user to download and run a sreensaver file. The file appeared trustworthy: it was digitally signed and showed almost no negative reputation at the time.
Once opened, however, it immediately downloaded a disguised file and used it to activate malicious code directly in memory. From there, it shifted communication to another external system using encrypted connections and delegated file downloads to built‑in Windows tools. This allowed the original file to appear relatively benign while riskier actions happened elsewhere.
How the threat established itself
To stay hidden, the attack relied on normal system tools and staged downloads rather than a single obvious malware file:
- A standard Windows networking utility was used to download and unpack archived tools.
- One program configured itself to start automatically and handed off communication to another process.
- A second program added its own startup mechanism, connected to different external systems, and gathered details about the operating system and installed security software.
What the team observed next
Two behaviours elevated the severity of the incident quickly:
- Resilience and operator intent:
Parts of the malware failed briefly but restarted automatically, indicating deliberate design to maintain access. - Multiple communication paths:
Different programs contacted different external systems, reducing reliance on any single connection and increasing the attacker’s ability to remain active even if one route was blocked.
What We Did (Human Led Response)
- Focused on behaviour, not signatures:
Analysts prioritised what the system was doing, unusual use of built‑in tools, hidden background activity, and rapid persistence over the file’s signature or reputation. - Mapped the full kill chain quickly:
By reviewing process activity, network connections, and system changes, the analyst confirmed multiple programs were working together to maintain access. - Contained the threat decisively:
The affected device was isolated to immediately stop the attacker’s communication before any further exploration, credential access, or spread could occur. - Preserved evidence:
The analyst collected volatile memory data, copies of staged files, relevant registry hives, and EDR timelines to support follow‑on hunting and tuning to improve future detections. - Strengthened detections going forward:
The findings were fed back into security controls, improving visibility around unusual use of built‑in tools, hidden command activity, archive‑based staging, and the communication patterns observed.
Why This Was a High Priority Threat
This incident combined several risk‑raising factors:
- Delivery through trust:
The file arrived via a business-critical communications channel where users expect to receive documents. - Deliberate stealth:
A trusted-looking, digitally signed screensaver file fronted the attack. Despite appearing trustworthy to reputation-based controls, it quietly loaded malicious code into memory. Then it relied on normal Windows tools and password‑protected archives to carry out riskier actions, helping the activity blend in with legitimate system behaviour.
- Built‑in staying power:
Multiple restart mechanisms and varied communication paths made the intrusion more resilient and reduced the likelihood that a single failure would disrupt the attacker’s access.
- Reconnaissance now, impact later:
The malware focused on gathering system and security information, often a precursor to longer‑term control.
Even without immediate damage, quiet, persistent access to a device creates a significant business risk that can be used later for data theft, credential abuse, or lateral movement.
Lessons Learned
This case reinforces a few core lessons:
- Files from trusted channels still require strong controls.
- Digital signatures and low detection rates don’t guarantee safety.
- Unexpected behaviour is often the earliest and most reliable warning sign.
- Acting quickly, before persistence is established, makes a critical difference.
Together, these measures shift detection earlier in the attack lifecycle, before persistence becomes entrenched and before a single compromised endpoint can be used as a stepping stone for broader impact.
Final Thought
If your business depends on open communication with customers or partners, assume attackers will try to exploit that trust.
The difference between a close call and a full‑scale incident often comes down to spotting the first real signal and responding before persistence takes hold.
That’s where experienced human investigation still matters most.
Get in touch with our SOC to discuss practical prevention and detection strategies, or download our SOC Threat Findings Report to explore other real‑world detections our team has investigated.