Incident response - don't know how VBS script got here

Any help is greatly appreciated!

Fileless intrusion perhaps? Do you have Sysmon running to analyze all commands, even by Powershell?

best regards,
Robin

Forgot to mention that I don't have memory image, just pure HDD image. I did not use Sysmon, since it is for live forensics, but I don't want to power on the machine.
Usually all PS and CMD history is gone when machine is powered off. I do have swap and shadow copy to analyze. I see PS spawned from WMI, PS is version 2.0 with limited to no logging.
Funny thing is that I will usually see PS execution before the VBS is dropped, but that's not the case here.

I see PS spawned from WMI, PS is version 2.0 with limited to no logging.

In this case it is very likely WMI or PS Remoting was used and everything was done in RAM. I would have a look at the swap file if there any remains of any started processes. And i would carve the HDD for deleted scripts of any kind (vbs, ps1, cmd, bat and so on- i am sure you know what to look for).

And i would have a look at other clients from this customer. If one host has this suspicious autostart entry, there might be some more. Looking for uncommon connections on the firewall or IDS/ IPS might be a good idea, too.

That`s my 2 cent in this case. Perhaps other FF members have some better ideas?

best regards,
Robin

…where I don't know how a VBS script got into HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\Run\

Okay, I found the version of the OS at the bottom, so we're good with that…

What is the LastWrite time for the Run key? I'm just asking at this point, and not assuming that the value added for the VBscript was the last action to take place.

The VBS script is located in the C\Users\AppData\Local\Temp folder…

Okay, what are the MFT times for the VB script…all of them? Does it appear that some sort of time stomping took place? How do they correlate to the Run key LastWrite time?

How do those times correlate to when the image was taken? Was it a few hours, days, weeks?

…and upon execution creates a random folder in Temp and puts another executable there. This executable is obviously a meterpreter reverse shell. Every time it runs and not able to connect to external IP, it deletes the exe and the folder to hide presence. Then it respawns again in 5min.

Persistence mechanism is obvious, however I don't understand how it got there.

It appears that you have the basis for what you need.

What I have tried so far
1) Super Timeline analysis - looking for events around the time the VBS was created
2) Event Log analysis
3) Prefetch, deleted files, last run apps, etc.
4) Web history

None of the analysis hinted me of how that file got in the temp folder and in the Run reg key.
Machine is Win 7 Home and does not have MS office or Adobe Reader installed.

Okay, you have a Super Timeline…what was the reason for creating it?

Since i don't know anything about the malicious code, i say it could be

* Insider.
* Legit app generating the script.
* Pentest leftover (some DO forget to clean up).
* Remote exploit with a downloader w/persist script.

What kind of web history do you have? Generally if you just have a browser dump it wont tell you all the scripts that have been included and executed on each page, just the site the user visited, you need packet captures for that, or at least netflow/firewall logs to identify what sites have been contacted, compare that against a lists of bad hosts. DNS logs can also be useful for this.

If the file system is NTFS I would suggest having a look at the USN Change Journal.

If this is present it may contain the history of the VBS file, from when it was first created and any previous names it had. It may be illuminating to look for other file system activity at the same time (for instance folders created/deleted, archive files etc). At the very least, this should confirm when the VBS file first appeared.

The journal is stored in the $J stream of the \$Extend\$UsnJrnl file. You can generate a timeline in Excel using Binary Markup Toolkit (BMTK). There is a walk-through in the Quick Start Guide explaining how to do this.

Jim

www.binarymarkup.com

Since you mentioned Win7 and shadow copy, I assume NTFS. You could also consider looking into $LogFile, which contains (although limited in amount) a much more detailed FS history than UsnJrnl. And certainly worthwhile looking into if the UsnJrnl is not active. Unallocated space on the FS can be worth scanning for deleted INDX (primarily $I30) and UsnJrnl entries. Regarding shadow copies, also look into $LogFile/$MFT there as well. You said you did not have a memory capture, but maybe you have hiberfil.sys. If so, then it is in fact a memory snapshot from the last time the system was hibernated.

Thanks for all responses, let me try out your suggestions and I'll come back to you.