You are browsing the archive for Anti-Forensics.

Beyond good ol’ Run key, Part 28

February 23, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

I was curious if any of the phantom DLLs that I wrote about before still exist on Windows 10 TP. It turns out that they do, but less of them exist than could leveraged as a persistence mechanism when compared to the older versions of OS.

Here is a list of groups I found; the process name is in bold and if you see the DLL name in the parenthesis (following the process name) it means that particular DLL is responsible for loading the actual phantom DLL.

%SYSTEM%\Dism.exe (WimProvider.DLL)
  • %SYSTEM%\Dism\wimgapi.dll
%SYSTEM%\Dism.exe
  • %SYSTEM%\DismCore.dll
%SYSTEM%\FileHistory.exe (clr.dll)
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\api-ms-win-core-winrt-l1-1-0.dll
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\mscoree.dll
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\ole32.dll
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\urlmon.dll
%SYSTEM%\mmc.exe (clr.dll)
  • %WINDOWS%\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\oleaut32.dll
  • %WINDOWS%\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\shell32.dll
  • %WINDOWS%\Microsoft.Net\assembly\GAC_MSIL\MIGUIControls\v4.0_1.0.0.0__31bf3856ad364e35\ntdll.dll
  • %WINDOWS%\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\comctl32.dll
  • %WINDOWS%\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\uxtheme.dll
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\api-ms-win-core-winrt-l1-1-0.dll
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\mscoree.dll
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\ole32.dll
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\VERSION.dll
%SYSTEM%\Narrator.exe (MSTTSEngine.DLL)
  • %SYSTEM%\speech\engines\tts\MSTTSLocEnUS.DLL (I have not explored it, but there is a possibility that on non-English Windows it would be a different localization DLL)
%SYSTEM%\omadmclient.exe
  • cmnet.dll
%SYSTEM%\PresentationHost.exe
  • %WINDOWS%\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationHost_v0400.dll
%SYSTEM%\provtool.exe (ProvEngine.dll)
  • MvHelper.dll
%SYSTEM%\SearchIndexer.exe
  • %SYSTEM%\msfte.dll
  • %SYSTEM%\msTracer.dll
%SYSTEM%\SearchProtocolHost.exe
  • %SYSTEM%\msfte.dll
  • %SYSTEM%\msTracer.dll

Probably the most interesting are SearchIndexer.exe and SearchProtocolHost.exe as they are running by default. Here is a screenshot capturing the moment when %SYSTEM%\msfte.dll is present on the system and user types something in the Search Box

msfte

Beyond good ol’ Run key, Part 27

February 19, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

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