Windows Endpoint Persistence Investigation

Where it started

The Windows endpoint began behaving abnormally after interaction with a suspicious file received through LinkedIn. Microsoft Defender reported multiple detections, and one symptom became especially useful to investigate: a recurring black console window.

Even after the visible process was stopped, the behaviour returned. That meant simply killing what I could see was not explaining the problem.

The question changed

At first, the obvious question was: what is this process?

But when it came back, the more useful question became: what is starting this process?

That shift changed the direction of the investigation from process identification to persistence tracing.

Process investigation

Using Process Explorer and related Windows tools, I examined the executable path, command line and behaviour. The investigation identified a process named LicenseManager.exe running from an unusual AppData-related location.

The command observed during the investigation associated the executable with update.dat:

LicenseManager.exe update.dat

The friendly-looking filename was not enough to establish legitimacy. The path, arguments and behaviour mattered more.

Tracing the parent with Process Monitor

Process Monitor helped me move backward from the child process and look at process-creation activity. The parent launcher traced back to the Windows Task Scheduler service:

svchost.exe -k netsvcs -p -s Schedule

That was the turning point. If Task Scheduler was creating the process, I needed to inspect scheduled tasks as a possible persistence mechanism.

Looking for persistence

I reviewed relevant persistence locations, including Registry startup entries and scheduled tasks. The key artifact was a scheduled task named WindowsDefenderCacheVerify.

The name sounded legitimate. The configured action did not. It pointed to the same suspicious user-profile/AppData location and supplied update.dat as an argument.

A scheduled task name is only a label.
Its configured action tells you what it actually runs.

Why the console kept returning

The evidence supported a simple cause-and-effect chain:

Scheduled task trigger → Task Scheduler service → LicenseManager.exe → update.dat → conhost.exe / visible console activity

Killing the child process removed only the current instance. The scheduled trigger remained registered, so the process could be launched again when the task fired.

Preserve first, modify second

Before containment, the suspicious scheduled-task configuration was preserved/exported as evidence. I did not want the first response action to destroy the artifact I was using to understand the behaviour.

I then chose a disable-first containment approach rather than immediately deleting the task. That was reversible, preserved evidence and gave me a cleaner way to test the hypothesis.

Did I disable Microsoft Defender?

No.
Microsoft Defender Antivirus itself was not disabled. The item disabled was an individual scheduled task named WindowsDefenderCacheVerify. Its trusted-looking name did not make its configured action legitimate.

Disabling that task stopped the suspected launcher without turning off Microsoft Defender Antivirus.

Validation after containment

After the scheduled task was disabled, the recurring console symptom was no longer observed during the subsequent monitoring/validation period. That supported the hypothesis that the task was responsible for relaunching the process.

I do not treat disappearance of one symptom as proof that an endpoint is completely clean. It is evidence about the specific behaviour being tested.

What I could confirm — and what I could not

Confirmed

The suspicious process executed repeatedly.
Task Scheduler service launched it.
LicenseManager.exe update.dat was observed.
The task WindowsDefenderCacheVerify referenced the suspicious path/argument.
Disabling the task stopped the recurring symptom during observation.

Not confirmed

Exact malware-family attribution.
Attacker identity or motive.
Confirmed credential theft.
Confirmed data exfiltration.
Complete eradication based only on symptom disappearance.

What this project taught me

The biggest lesson for me was that finding a suspicious process was not actually the end of the investigation. The useful question was why it kept coming back.

Once I started tracing what was launching it, the investigation changed completely. It also reinforced something I want to keep carrying into security work: separate what I observed from what I assume, preserve evidence before changing it, and use containment to test a hypothesis when possible.