You are browsing the archive for Malware Analysis.

Beyond good ol’ Run key, Part 29

March 13, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

LNK files are used by malware for many years so there is not much new about it that can be said with regards to persistence.

Examples include:

  • Placing shortcut files in popular locations (Desktop, Start Menu)
  • Replacing an .exe path inside the .lnk files with one pointing to a malicious executable (‘man-in-the-middle’, or a variant of a companion virus)
  • Exploits (as used by Stuxnet)
  • Etc.

The following examples explore 2 more (but less popular) methods of leveraging LNK files as a persistence mechanism.

Hot Keys

The first one relies on Hot Keys. LNK files placed on a Desktop or in a Start Menu have an interesting property – they can register hot keys that may activate the respective lnk file i.e. launch them.

This was handy back in a day when icons on a desktop were hidden most of the time and using shortcuts allowed accessing the most popular applications w/o a need to minimize all windows, or browsing through the Start Menu. Today, the new Taskbar in Win7/8/10 + Windows+<number> combinations make this functionality pretty much obsolete. But it’s still there. And one can modify an existing Desktop/Start Menu shortcut, or create a new one that will point to a malware.

It will be activated anytime a specific combination of keys is hit.

Of course, which key combination to choose is a tricky part – a wrong choice could affect running applications. One can always explore possibilities by checking the Shortcut Key section on the Shortcut Properties Window. Interestingly, manually setting the keys will almost always include a CTRL+ALT prefix (added by the OS). It limits a range of popular keys that can be entered via Shortcut Properties Window (note: some keys f.ex. F1-F12 are not prefixed):

lnk0

One could bypass this restriction by setting the keys directly via COM object responsible for creation of shortcuts (IShellLink interface), or even manually modifying the .lnk file (on a binary level).

To demonstrate this trivial trick we can look at the following snippet of code.

set w = CreateObject("Wscript.shell")
d = w.SpecialFolders("Desktop")
set l = w.CreateShortcut(d + "\foo.lnk")
l.WindowStyle = 4
l.TargetPath = "c:\test\malware.exe"
l.Hotkey = "Captial"
l.Save

It leverages a COM IShellLink interface accessed via Visual Basic Script to create a shortcut to a c:\test\malware.exe file. The ‘malware’ will be activated anytime someone presses a CAPS LOCK. A trivia fact: ‘Captial’ is actually how VBS refers to a CAPS LOCK key.

This choice of key(s) is actually not that bad – people don’t use CAPS LOCK at all and at the same time – they often press it accidentally every once in a while. After some more tests it also looks that it does NOT affect running programs, so f.ex. if you type something, then press CAPS LOCK (malware runs), applications will still interpret CAPS LOCK and switch to capital letters. Pressing it again brings the small letters back (while malware executes again).

A kinda similar concept applies to F1 which could be used as an alternative (people don’t use a built-in Help that often either).

This is how the generated shortcut looks like in the Shortcuts Properties Window:

lnk1

And this is what happens when you hit Caps Lock:

lnk3aThe c:\test\malware.exe is a simple program showing a message box.

Command line modification

The other way one can exploit the .LNK files is by modifying not the path to the executable itself, but by changing the command line arguments. This is in fact a technique that is actively used by malicious plugins. They use this trick to patch .LNK files pointing the Google Chrome browser to load a malicious plugin via a modified command line. The command line switch that is added is ‘–load-extension’.

Chrome uses a lot of command line arguments that could be potentially abused the same way.

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