Category Archives: Compromise Detection

Beyond good ol’ Run key, Part 27

Posted on by

Things are never boring in the Visual Basic world. In part 20 I described how localization DLLs can be used as a potential persistence mechanism on the localized systems. Today, we will look at yet another localization feature offered by this platform.

Application in VB can be marked as localized by changing their internal language ID (LCID). They may also include a name for the localization DLL (two of them, actually).

In the example below, we can see a VB application marked as localized to German (the LCID is set to German=407h), the MSVBVM60.DLL will attempt to load the DLL marked szLangDll as well as szSecLangDll (as long as the latter is not equal to ‘*’ as in the below example).

vb_localizedSo, one way to ensure persistence is to find an existing VB app on the system, modify its internal LCID to a value different than the one on a local system and then place the respective localization DLL in the system directory as described in part 20. Another way would be modifying the embedded szLangDll name to something else and such dll would be loaded. Thirdly, we could modify szSecLangDll from ‘*’ to anything we want and such DLL would be also loaded.

This is a pretty lame and is not far off from part 25 – a requirement to modify an executable is ridiculous for today’s standard, but I am adding it for completeness.

Bonus:

szSecLangDll is typically marked as ‘*’ – this is an internal marker that VB uses as an indicator telling the engine NOT to load the second localization DLL. Interestingly, I have seen Korean applications where this ‘*’ was changed to a tilde. I do not know why. If such application is found on the system this could be leveraged to develop a persistence mechanism based on such a tilde-based file name.

Have a look – we can see 3 persistence mechanisms at work here:

  • vb6ko.dll – described in part 20
  • HKLM\SOFTWARE\Microsoft\VBA\Monitors – described in part 6
  • ~.dll – described here as a result of Korean application using a non-standard szSecLangDll marker ‘~’ instead of ‘*’

tilde1

Detecting APT remnants in $MFT

Posted on by

Update 2018-12-15

This tool was an experiment; please do not use it anymore as it produces unreliable reports; the tool has not been updated for many years. Use modern AV/EDR software instead. Thanks!

Old Post

In a post from 2012 I introduced a simple tool that was scanning $MFT for traces of flame.

Today i decided to update the list of file names the tool recognizes to include:

  • the latest in many APT campaigns – credit goes to kbandla @ https://github.com/kbandla/APTnotes/
  • some tools typically used by hackers (their full and short file names)
  • ‘stashed data’ file names e.g. ‘1.rar’
  • other file names commonly used by hackers [lots of generic names]

This is an experimental tool so do not jump if you see something in RED (well, you should not anyway, cuz it could mean you got pwned).

Just assess it and take it from there – look for the file names highlighted by HCD on your drive. If you can’t find it, use a forensic tool to export a full list of file names. p.s. I will add a feature to include full paths in future versions – code is ready, but needs some more polishing.

In any case, if you you see something red you should probably look at your system anyway… If you find bugs, or False Positives pls let me know. Thanks.

Download the tool from here.

Example:

HCD ran on the system where DoubleFantasy installer was executed previously; system also contains various reversing tools e.g. ollydbg.exe and bintext.exe:

pic

Last, but not least, I am aware of some bugs, but better have something than nothing to fight clowns writing malware for governments…

What’s next?

If you suspect something ‘funny’ you can use the following tools to extract a full filelist from $MFT:

Another way to test your system is by running LOKI by Florian Roth – a tool that scans your system for IOCs (Indicators Of Compromise) for many well-known APT campaigns.