It was an unusual alert from a former client's system. Another team had already taken over IT management, but an old connection remained active and the alert reached me. At first, its cause was unclear. As I began investigating, it became apparent that a computer on the network had been compromised.
In the activity logs, I found remote logins and an automated task with a name that looked like a software update. The task launched a malicious file, and the logs showed that it had already run. Even after the security software deleted the file, the task kept trying to launch it again and again.
Windows Task Scheduler is used for activities such as updates and maintenance. Here, it was being used to run malware repeatedly without anyone having to open it manually. Remote access was significant too: the same capability that lets a support technician work on a computer can, in the wrong hands, allow someone to access data and run programs. What had actually happened, and how far the intrusion had reached, still needed to be established.
I worked within the access available to me. I reviewed the sequence of events, installed protection and response tools, disabled the task and isolated the endpoint. I submitted the file for analysis and compiled the findings into a report for the network administrators who were continuing the response. The report also identified checks needed on systems outside my control. Even from the single computer examined, it was clear that the wider environment needed investigation.
A few days later, workstations were locked and systems were brought down. I was called in to help the team managing the network, this time with recovery and restoring operations. The alert that had prompted my initial investigation now formed the background to a very different task: finding a practical way to restore a working system and whatever data could be recovered.
Backups were available, but full recovery repeatedly failed. The virtual machine had temporary disks and an inconsistent configuration. Trying the same approach again did not produce a stable result, so I separated getting the system running from extracting the data.
First, I identified the operating system disk and attached it to a new, clean virtual machine. The system started. This allowed progress without further complications from the configuration left by the failed recovery attempts.
I then moved the backups to a separate environment and began extracting folders and files. Some parts of the data could not be read correctly. Skipping those areas at that stage allowed the rest to be recovered instead of every attempt stopping at the same point. The usable data was returned to the server, and the remaining gaps were documented.
The system was running again and data was back in use, although recovery was incomplete. For me, that is the heart of the story: noticing an unusual sign, understanding what lies behind it and then finding a practical way forward when the standard recovery process does not work. Experience shows in those decisions, and in the ability to explain what has been achieved and what is still missing.
Suntech helps resolve complex technical problems and supports the backup and recovery of systems and data.