Let's return to the question of why the task is reading a script from
a registry key and what is in that registry key.
We could look at the Task Scheduler configuration on the infected host,
but we want to do as much as possible from the logs
without logging onto the host directly.
We'd like to find the operation that put this value into the registry.
A good place to start looking would be process events and searching for
the use of the command line tool, reg.exe; however,
as I mentioned in the previous demo,
there are many ways to perform system tasks like this in Windows,
so searching for a command line tool like reg.exe might not reveal the culprit.
Another place to look is the PowerShell pipeline trace logs, EventID 800.
If the registry value was set from PowerShell, it would show up here.
The PowerShell pipeline logs are verbose, but especially helpful here.
We search the pipeline logs for the partial registry path,
Windows current version, that our suspect task was using,
and we found two events where this registry path is being used.
The first of these two events looks promising.
It is setting the value of this registry key to a long Base64‑encoded string.
Decoding this string, we see a familiar obfuscated PowerShell script.
Pulling this out and reformatting it, we can see the same AMSI bypass script,
as we saw in the previous demo.
This time, it's installed as a persistent downloader.
At 9 a.m.
every morning, this task will execute, pull down a PowerShell script,
and execute whatever the attacker has in mind for that day.
Note that there is a section of the decoded script that is still encoded.
The MSTICPy decoder automatically recursed into and decoded this,
and we can see this in the next result row.
This is the target IP address that our script is downloading from.
The address itself has been Base64 encoded and then placed in
the script and the whole script encoded again.
If MSTICPy's Base64 decoder returns multiple rows for a single input row,
it means that it has found nested encoded strings,
which it returns to separate result rows.
In our demo data, this is an internal address,
but a real attack would have the IP address of an
attacker command and control system.
In the notebook,
I've included some references on the events used in
this demo and for de‑ob shell,
a more sophisticated PowerShell de‑obfuscater. In summary,
we looked at analyzing and viewing events to determine the likely time of an
attack and using MSTICPy's timeline to see Scheduled Task creation events. We
used one of those events to view the task parameters. We found that part of the
script was loading from registry value.
Finally, we used PowerShell pipeline events log to
find the process setting that value.
We were able to decode and view the script being executed by the
scheduled task, and we were able to understand the purpose of the
script and confirm its malicious nature.