Case Notes: A Phishing Email, a Fake Invoice, and a Backdoor That Survived a Reboot

Summary

On Tuesday morning, a finance employee at Helix Freight Services opened a "payment advice" email. Within a few minutes, their laptop was running malware. By the afternoon, our SOC had contained the device, removed the attacker's tools, and confirmed that the attacker had left a way back in.

This report walks through what we saw, in the order we saw it. It covers suspicious processes, endpoint activity, persistence, and what we found during the investigation. I wrote it so that a junior analyst can follow along, and so that the next shift can reuse the lessons.

Quick facts

• Incident ID: HFS-IR-2026–0147
• Affected host: FIN-WS-014 (finance workstation, Windows 11)
• Affected user: a.rahman
• Severity: High
• Status: Contained and remediated
• Data loss: No evidence of data leaving the network

1. How We Found Out

At 09:26, our EDR raised an alert: "PowerShell launched with an encoded command by a non-standard parent process."

That is an unusual pattern. PowerShell is normally started by a user, a script, or an admin tool. In this case, the parent process was a file in the Downloads folder. We opened a case and started pulling logs from the host.

2. Timeline of Events

All times are local (UTC+5).

09:12: The phishing email arrives The user received an email titled "Vendor Payment Advice — October". It looked like a normal accounts message and carried a ZIP attachment named Q3_Vendor_Payment_Advice.zip.

09:14: The user opens the attachment Inside the ZIP was a single file named Payment_Advice_Oct.pdf.exe. Windows hides known file extensions by default, so the user saw Payment_Advice_Oct.pdf and double-clicked it. This was the initial access file. It is a dropper, meaning its only job is to bring in other malware.

09:15: The dropper starts PowerShell The dropper launched powershell.exe with a long Base64-encoded command. When we decoded it, the script downloaded a file from hxxps://cdn-helixupdate[.]example/get/ms.dat and saved it as C:\Users\Public\Libraries\msupdate.dat.

msupdate.dat is just a data file. It is not an executable and it is not persistent. It is the encrypted package that the next stage unpacks.

09:16: The loader runs A second process started from the user's temp folder: C:\Users\a.rahman\AppData\Local\Temp\WinSvcHost.exe. It unpacked msupdate.dat in memory and opened a connection to the attacker's server at 185.220.101.47 over port 443.

This is the loader. The name was chosen to look like a Windows service host, but it does not belong to Windows.

09:20: First triage snapshot While the attacker was still active, we took a quick autoruns snapshot. It showed a Run key entry pointing to WinSvcHost.exe. At that moment, we noted it as a possible persistence mechanism. (Keep this in mind. We will come back to it.)

09:31: Credential theft attempt The attacker copied a legitimate Microsoft tool (procdump64.exe) to the Public folder, renamed it taskhostw_dbg.exe, and used it to try to dump the memory of the LSASS process. LSASS holds credentials. Our EDR blocked the dump, so no credentials were obtained.

09:38: Network discovery The attacker ran whoami /all, ipconfig /all, net group "Domain Admins" /domain and nltest /dclist: through the loader. These commands collect information about the user and the domain.

09:41: The attacker cleans up A scheduled task named SystemHealthCheck ran once. It launched a batch file, cleanup.bat, which did three things:

1. Deleted WinSvcHost.exe from the Temp folder.
2. Deleted the Run key entry that pointed to it.
3. Deleted the task itself.

The attacker was removing the evidence that our 09:20 snapshot had captured.

10:03: A new scheduled task appears Only a few minutes after the cleanup, Windows logged a new scheduled task (Event ID 4698) named NVIDIA Telemetry Container Sync. It was set to:

• run at every user logon, and
• repeat every 30 minutes.

The task launched a program from C:\ProgramData\NVIDIA Corporation\. This is a very believable location, which is exactly why it was chosen.

10:07: The attacker goes quiet Beaconing continued every 30 minutes, with small and regular connections to the same IP address.

10:52: Containment The host was isolated from the network using the EDR console. The user was contacted, and their password was reset as a precaution.

3. Process Tree

This is the chain of processes we reconstructed. Read it from top to bottom.

explorer.exe
 └── Payment_Advice_Oct.pdf.exe        (dropper, started by the user)
      └── powershell.exe -enc ...      (downloads the payload)
           └── WinSvcHost.exe          (loader, runs from Temp)
                ├── taskhostw_dbg.exe  (renamed procdump, blocked)
                ├── cmd.exe            (discovery commands)
                └── schtasks.exe       (creates tasks)

explorer.exe
 └── Payment_Advice_Oct.pdf.exe        (dropper, started by the user)
      └── powershell.exe -enc ...      (downloads the payload)
           └── WinSvcHost.exe          (loader, runs from Temp)
                ├── taskhostw_dbg.exe  (renamed procdump, blocked)
                ├── cmd.exe            (discovery commands)
                └── schtasks.exe       (creates tasks)

4. Why Persistence Was Easy to Get Wrong

Persistence means the attacker has set up a way to come back after the device restarts, or after the user logs out. This is the part of the incident where it is easiest to make a mistake, so I want to explain it carefully.

During this incident, there were three different artifacts that could have been mistaken for persistence:

The dropper. Payment_Advice_Oct.pdf.exe was only used once, at the start. It does not run again by itself.

The loader. WinSvcHost.exe appeared in our early snapshot with a Run key, which made it look persistent. But the attacker added this entry only as a short-term measure and removed it themselves 20 minutes later. A file that is deleted by the attacker, and does not return after a reboot, is not the long-term persistence.

The cleanup task. SystemHealthCheck is a scheduled task, and scheduled tasks are a classic persistence technique. But it ran one time and deleted itself. It is a cleanup tool, not a way back in.

The test we used is simple:

Does it survive a reboot, and does it bring the attacker back?

Only one artifact passed this test. We will get to it in section 6.

5. Indicators of Compromise (IOCs)

Files

• Q3_Vendor_Payment_Advice.zip (phishing attachment)
• Payment_Advice_Oct.pdf.exe (dropper)
• C:\Users\Public\Libraries\msupdate.dat (encrypted payload data)
• C:\Users\a.rahman\AppData\Local\Temp\WinSvcHost.exe (loader)
• C:\Users\Public\taskhostw_dbg.exe (renamed procdump)
• C:\Users\Public\cleanup.bat (cleanup script)
• C:\ProgramData\NVIDIA Corporation\ (folder created at 10:03, unsigned executable inside)

Network

• cdn-helixupdate[.]example (download server)
• 185.220.101.47:443 (command-and-control)

Scheduled tasks

• SystemHealthCheck (one-time cleanup, self-deleting)
• NVIDIA Telemetry Container Sync (logon trigger, repeats every 30 minutes)

Registry

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run\SysUpdate (temporary, removed by the attacker)

Useful event IDs

• 4688: new process created
• 4698: scheduled task created
• 4699: scheduled task deleted
• Sysmon 1: process creation with full command line
• Sysmon 11: file created
• Sysmon 13: registry value set

6. The Persistence Mechanism

After the cleanup at 09:41, we assumed the attacker had lost access. Then, at 10:07, the beacon returned. That was the clue that something else was running.

We looked at what was new on the host after the cleanup. The scheduled task NVIDIA Telemetry Container Sync stood out for several reasons:

1. The host has no NVIDIA hardware. FIN-WS-014 is a standard finance laptop with Intel graphics. There is no reason to have an NVIDIA telemetry task on it.
2. The folder looked real, but was not. C:\ProgramData\NVIDIA Corporation\ did not exist before 10:03. The attacker created it.
3. The task ran an unsigned file. Real NVIDIA binaries are digitally signed. This one had no signature.
4. The name was a near match. NVIDIA's legitimate telemetry component is called NvTelemetryContainer.exe. The task did not point to that file. It pointed to NvTelemetryHost.exe, a similar-looking name that NVIDIA does not ship.

To confirm, we ran a controlled test. We restored a snapshot of the device in a lab, left the scheduled task in place, and rebooted. After the user logged in, the beacon to 185.220.101.47 returned within 30 seconds.

We also checked the file against the task. The task's Actions tab showed the exact program path, and the file's creation time (10:03) matched the Event ID 4698 entry for the task.

This is the real persistence artifact. It is the executable that the scheduled task starts after every logon, and it is the file that brought the attacker back.

7. Remediation

Immediate actions (done)

• Isolated FIN-WS-014 from the network.
• Reset the password for a.rahman and revoked active sessions.
• Deleted the malicious scheduled task and the folder it used.
• Blocked 185.220.101.47 and cdn-helixupdate[.]example at the firewall and DNS.
• Re-imaged the laptop before returning it to the user.

Follow-up actions

• Search all endpoints for the IOCs above.
• Show file extensions by default through Group Policy.
• Block .exe files inside ZIP attachments at the mail gateway.
• Add a detection rule for scheduled tasks that run from ProgramData and have vendor-style names.
• Run phishing awareness training for the Finance team.

8. MITRE ATT&CK Mapping

• T1566.001 Phishing: Spearphishing Attachment
• T1204.002 User Execution: Malicious File
• T1059.001 Command and Scripting Interpreter: PowerShell
• T1036.005 Masquerading: Match Legitimate Name or Location
• T1003.001 OS Credential Dumping: LSASS Memory
• T1087 / T1018 Account and Remote System Discovery
• T1070.004 Indicator Removal: File Deletion
• T1053.005 Scheduled Task/Job: Scheduled Task
• T1071.001 Application Layer Protocol: Web Protocols

9. Lessons Learned

1. A first snapshot is not the full story. Our 09:20 triage pointed to the wrong file. If we had stopped there, the attacker would have kept access.
2. Attackers copy trusted names. WinSvcHost, taskhostw_dbg, and an NVIDIA task on a laptop with no NVIDIA parts are all designed to look boring.
3. Check what changed after the cleanup. If the activity continues after you think you have removed it, something else is still there.
4. Always test with a reboot. It is the fastest way to separate a temporary foothold from real persistence.

Written by the Helix Freight SOC (Tier 2). Names, hosts, and addresses in this report are fictional and were created for training purposes.