Errant Security

The worst feeling in the world for me is knowing exactly how do to something, but being limited by some tool or peculiar reason. It happens to me a lot when working on electronics and trying to lay out traces on a PCB. But no one cares about that, this is a cyber blog. I was playing in a CTF a few weeks ago and I was trying to track down a malicious process and time was ticking. I didn’t have a SIEM and I was feeling too lazy to set up sysmon and starting sending stuff to the local event viewer.

This is where shimcache and amcache come in. Both are caches that store metadata about executed programs on windows.

Background: A shim. Just like in carpentry and enginnering something just doesn’t fix perfect. So what do you do? You take piece of something and cram it in there to make it snug. Microsoft did the same thing. They built small libraries to ensure legacy applications work. The shimcache is where the relavent information is logged for debugging programs.

But it didn’t really take off in the DFIR community until Andrew Davis released the ShimCache Parser tool (on madiant’s github) and this paper.

So what can you get shim cache?

File path of the executed file Size of the file Last modified time Last Updated time Exctuion flags

Seems like a nice cache of imformation!

But wait! Theres more!

Shimcache was implemented on Windows XP through though sever 2012 (Vista, Server 2008, Server 2012, 7), starting with windows 8 Microsoft amcache to replace shimcache which added more DFIR goodies.

Amcache will tell us:

File Reference Volume GUID Possible First Run Timestamp (Last Modified on key) Modified Time File path Program ID SHA1 hash

The amcache adding the SHA1 functionality really adds more value in the sense that some malware may erase it self or replace itself with an innoclous file for the incident responders to find

The way to gather this information is through some python scripts released by Madiaant.

We went ahead and tried it on one of our Windows 7 VMs.

12/03/18 20:31:06,N/A,C:\Users\VIRPC-1\Downloads\puttyX.exe,N/A,True 12/03/18 04:59:28,N/A,C:\Windows\SysWOW64\Macromed\Flash\FlashPlayerUpdateService.exe,N/A,True 12/03/18 05:30:14,N/A,C:\ProgramData\chocolatey\bin\ls.exe,N/A,True 12/03/18 21:08:19,N/A,C:\Windows\system32{A6D608F0-0BDE-491A-97AE-5C4B05D86E01}.bat,N/A,False 12/03/18 21:02:51,N/A,C:\Windows\devcon\64bits\devconx64.exe,N/A,True 12/03/18 05:29:43,N/A,C:\Users\VIRPC-1\Desktop\winlogbeat-6.5.1-windows-x86_64\winlogbeat.exe,N/A,True

What we did is used MSFVenom to package putty with a back door to connect back to our attacker box. With that we then ran mimikatz to get passwords. We then rebooted to make sure it was written to the cache. There are also modules to get the data out of memory of the live system. So if your are not getting the information you expect out of shimcache make sure you check the uptime on the system!

While you dont see any of the mimikatz in the log you do see the puttyX.exe run. And thats pretty neat.

One possible use case is if you see an executible being downloaded across your network sensors you can then see if it executed on the workstation that requested.

This method of investigation doesnt scale to an entire enterprise but it can help for a targeted investigation.

Cheers.


feature-top