Possible Autostart/start mechanisms that are built-in ‘natively’ in Windows and also available by means of extra features offered by many applications go beyond typical path locations and registry keys highlighted by popular programs and scripts like Autoruns and SilentRunners. I have covered some of the non-standard persistence techniques in 2 older posts in the series here and here, but as usual – there is always more to write about.

In this post I will cover another batch of less known and possibly ‘obscure’ technique that could be potentially used for autostart/start purposes. I write ‘obscure’, because it is not a typical way of doing autostart, but let’s be honest – there is nothing really extraordinary about it – just a simple abuse of built-in features in both OS and applications.

Code-in-the-middle proxy

Long story short, it is a well known fact that many existing registry entries and files pointing to or containing code can be modified to introduce a code-in-the-middle proxy (DLL, EXE, etc.) that will be executed/loaded first instead of a legitimate entry. The original entries are preserved so that they can be transparently executed/loaded once malware is running. There are many existing examples of this technique already being used e.g. hijacks of Shell Open Command,  Image File Execution Options , etc., but it is important to remember that this technique can be extended literally to any registry key or file that is loaded either during autostart or often used by users.

Application Registration (App Paths) hijacking

Another proxy technique that could be used to hijack popular applications relies on registry entries stored under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

As per Microsoft:

The entries found under App Paths are used primarily for the following purposes:

• To map an application’s executable file name to that file’s fully qualified path.
• To pre-pend information to the PATH environment variable on a per-application, per-process basis.

A legitimate entry that can be found on many newer versions of Windows is shown below:

It is responsible for launching MS Paint program when someone tries to run it using a legacy ‘pbrush.exe’ name.

One could add a modification for e.g. calc.exe:

From now on, anytime someone tries to run calc.exe manually (e.g. from command line/ via Start Menu/Run  window), Notepad will be launched. It may not be a main persistence mechanism, but could be used for re-infection purposes on systems that have been cleaned up, but not rebuilt.

Text Services (TSF)

Microsoft defines Text Services as:

Microsoft Windows Text Services Framework (TSF) is a system service available as a redistributable for Windows 2000. TSF provides a simple and scalable framework for the delivery of advanced text input and natural language technologies. TSF can be enabled in applications, or as a TSF text service. A TSF text service provides multilingual support and delivers text services such as keyboard processors, handwriting recognition, and speech recognition.

From a practical point of view, TSF offers ways to extend available input methods by allowing to install support for languages that are not natively supported by Windows. A good example of such extension is Ekaya – an extension for a Myanmar (Burmese) language.

In order for TSF to work on Windows XP, one has to enable the ‘Extended support of advanced text services to all programs’:

On Windows 7, it is enabled by default (but to install a TSF DLL one requires administrator privileges).

Examples on how to use TSF are provided in Microsoft SDK (look for ‘Samples\winui\Input\tsf\TextService’ directory). For the purpose of this article, I just picked up the simplest possible example i.e. a project from the ‘Samples\winui\Input\tsf\TextService\TextService-Step01′ subdirectory and updated it with a trivial cosmetic change – a call to OutputDebugString so that we can observe processes loading and unloading our test DLL.

BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID pvReserved)
{
  TCHAR szFileFullPath[256];
  TCHAR buf[300];
    switch (dwReason)
    {
        case DLL_PROCESS_ATTACH:

            g_hInst = hInstance;
            GetModuleFileName (NULL,szFileFullPath,256);
             _tcscpy (buf, TEXT("TSF DLL loaded: "));
             _tcscat (buf, szFileFullPath);
            OutputDebugString(buf);
            if (!InitializeCriticalSectionAndSpinCount(&g_cs, 0))
                return FALSE;

            break;

        case DLL_PROCESS_DETACH:

            GetModuleFileName (NULL,szFileFullPath,256);
             _tcscpy (buf, TEXT("TSF DLL unloaded: "));
             _tcscat (buf, szFileFullPath);
            OutputDebugString(buf);

            DeleteCriticalSection(&g_cs);

            break;
    }

    return TRUE;
}

Once registered with Regsrv32.exe:

regsvr32 TextService-Step01.dll

the DLL is now active and it will now be loaded to each new process utilizing Text Services (pretty much every single GUI application, including these already running) as can be shown via DebugView from Sysinternals.

Running a few test applications shows the following output in DebugView:

Of course, it survives the reboot and is loaded next time user logs on and applications are executed + it works under Windows 7 without any problem:

You may be wondering if there is any visual indication of the DLL being present on the system.

There is.

If you look at the legitimate software like aforementioned Ekaya – it adds a set of icons to the Language Bar:

and

It can be also seen in Text Services and Input Languages section (you can find it under Regional Settings):

There is no requirement for TSF DLLs to add extra features to the Language Bar, so the Text Services and Input Languages section under Regional Settings is the only place where it is possible to spot the loaded DLL – for our test sample it looks like this:

DLL load order

This is a trick relying on  DLL load order – it has been covered on many security blogs in last 2 years so I just mention it for completeness – there are many DLLs that can be ‘injected’ into a loading process of many popular programs. Two of them: fxsst.dll and ntshrui.dll have been covered by Nick Harbour from Mandiant in his posts from July 2010 and June 2011.

IIS Server Extensions (ISAPI filters)

In my older post I mentioned plugins and various extensions that can be loaded into various applications. There are really a lot of possibilities here, including multum of popular software, Windows Shell extensions, aforementioned Text services, IME, URL handlers, and so on and so forth. There are also possibilities of writing server environment-specific extensions e.g. ISAPI filters: As per the information on the page

Every ISAPI filter is contained in a separate DLL that must export two entry-point functions, GetFilterVersionand HttpFilterProc, and optionally export the TerminateFilter function. The metabase property, FilterLoadOrder, contains a list of all filters that IIS loads when the Web service is started.

 AppCertDlls

This is also a known technique – it has been researched and published by EP_X0FF in 2007 on sysinternals forum. There were a few follow-up posts about it, and a sample code can be found here, here and here. If you are interested you may also read ReactOS code that implements this feature here (search for ‘BasepIsProcessAllowed’).

Using a slightly modified code from one of the posts, we can build a DLL to demonstrate how it works.

First we need to add a registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDlls

then any REG_EXPAND_SZ value pointing to a DLL we have built.

 Now we need to restart the system to ensure a system-wide coverage. For testing purposes, it is okay to restart Windows Explorer so that it can refresh its internal program state to include these DLL in a process creation sequence. Or, one can simply launch cmd.exe and then run programs from command line to observe the DLL being loaded into each newly created process:

 You may be wondering how it works under 64-bit system. It works pretty well.

In fact, you can register both 32-bit and 64-bit DLLs as a notification on a 64-bit system:

to ensure notifications will be processed for both 64-bit and 32-bit programs:

That’s all ! Thanks for reading!

There is a lot of ZeroAccess analysis all over the place, so not sure if anyone documented it before, but oh well…  here it goes…

I have been recently looking at a new sample of ZeroAccess and spotted that at an early stage of the infection, it injects a small code into Windows Explorer:

The snippet is then executed via Asynchronous Procedure Call (NtQueueApcThread). Just looking at the size of the payload and the strings made me curious enough so I decided to have a quick look at the code.

Turns out, this little snippet doesn’t like Shell_NotifyIconW API very much and it patches it in a very clever and selective way.

The disassembled code of the main routine from the snippet looks like this:

The PatchShell_NotifyIconW function shown on the screenshot is responsible for allocating a small buffer in memory (via ZwAllocateVirtualMemory) that will hold a code of the function modifying the standard behavior of Shell_NotifyIconW API.

As per MSDN, the Shell_NotifyIconW function takes 2 arguments:

BOOL Shell_NotifyIcon(
  _In_  DWORD dwMessage,
  _In_  PNOTIFYICONDATA lpdata
);

The new function installed by ZeroAccess looks like this:

The 33333333h is an address (patched at run-time) to the old unpatched version of the function, so that once ZeroAccess modifies the function’s behavior it can pass the control back to the original function.

As you can see, the patch is simple – it only modifies a dwMessage value so that it is always equal to NIM_DELETE, which pretty much means that any attempts to add/modify/change status of an icon on the notification area (tray) will fail.

While I have not tested it as I don’t have any image with all these security settings on, it seems to be a simple trick to prevent the ‘annoying’  security notifications from happening while the malware is doing its evil thing. This is indirectly confirmed by the way the actual patch occurs. Instead of patching the entry code of Shell_NotifyIconW in a typical, process-global detour-like fashion, the malware walks through all DLLs loaded into Windows Explorer and finds addresses of Shell_NotifyIconW function only within the Import Address Tables  of two DLLs: ActionCenter.dll and wscntfy.dll. These hold the code responsible for the system/tray icon area notifications related to current security state of the system.

Quite frankly, I like this piece of code as it is very neatly written (it even self-removes itself from memory after it is executed) but more importantly, these popups are actually quite annoying!

In my previous post I described various less-known autoruns mechanisms that can be utilized by malware. This post follows-up on some of the ideas I have described there and lists another batch of applications providing features that could be potentially used by malware authors. This is not to scaremonger users of these applications -  the features described here are actually very useful and needed, and certainly developed in the best interest of the users. Still, they are potential avenues for developing hidden autostart so with ‘the better evil known than unknown’ in mind, here it goes:

Winrar archiver

Allows to define external viewer:

The value is stored under the following registry location:

• HKEY_CURRENT_USER\Software\WinRAR\Viewer\ExternalViewer

The other user-defined value worth remembering of is the AV scanner integration;

stored in the registry under the following path:

• HKEY_CURRENT_USER\Software\WinRAR\VirusScan\Name

 WinZip Archiver

WinZip allows for creating Self-extracting archives, the task can be accomplished with a help of an externally defined application:

The value is stored under:

• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\zip2exe

Other interesting values:

• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\viewer
• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\vviewer

Winzip in version 10 and earlier allowed for an antivirus scan same way as WinRar. This feature has been removed from newer versions as explained in this article. The users of old WinZip 10 could define the path to various external programs including antivirus, executable for creating Self-extracting .exes, viewer, as well as 3 external applications to handle old 16-bit archivers ARJ, LHZ and ARC.

The user-defined values could be found in Registry:

• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\arc
• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\arj
• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\lha
• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\scan
• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\viewer
• HKEY_CURRENT_USER\Software\Nico Mak Computing\WinZip\programs\zip2exe

Internet Download Manager

Downloading files from the internet is certainly not a safe operation and IDM allows to define what application will be executed and act an external AV scanner upon a file download:

The actual value is stored here:

• HKEY_CURRENT_USER\Software\DownloadManager\VScannerProgram

Download Accelerator Plus (DAP)

The very same functionality is present in DAP:

and the value is stored here:

• HKEY_CURRENT_USER\Software\SpeedBit\Download Accelerator\AntiVirusEXE

 Orbit Downloader

Another popular downloader also offers the antivirus scan functionality:

This time the user-defined value is stored not in Registry, but in a configuration file:

• %USERPROFILE%\Application Data\Orbit\conf.dat

e.g.

c:\Documents and Settings\user\Application Data\Orbit\conf.dat

 Windows Live Messenger

Instant Messenger applications also allow for defining applications that will be executed upon arrival of a file from the other users of IM. Such setting is present in WLM as well:

The actual value is stored under MSNMessnger branch:

• HKEY_CURRENT_USER\Software\Microsoft\MSNMessenger\AntiVirus

The value is stored as a binary and in this case data is just an UnicodeZ string

Miranda

Another popular IM that offers antivirus scan is Miranda:

the value is stored in a file in the following location:

• %USERPROFILE%\Application Data\Miranda\PROFILEFOLDER\PROFILEFILENAME.dat

e.g.

c:\Documents and Settings\user\Application Data\Miranda\foo\foo.dat

It took around 2 hours to download all these applications, test them and write this blog entry. Not a thorough and very advanced research as you can see, but this is what it takes to find new stuff. If you have some spare time and like (or want to learn how) to write a new RegRipper plugin, perhaps now it’s a good time to give it a go Thanks for reading!

I recently kept posting quite a lot about random stats from 300k/1M samples. Today something different for a change: non-obvious or less-known autorun entries.

The ‘obvious’ introduction

As we know, malware needs to work. To do so, it needs to ensure it runs when the system starts. Well, not really. In fact, it just needs to ensure it runs in general and can start at any time as long as it is at a right moment to activate its payload (e.g. keylogger doesn’t need to autostart with the system; it can activate when the user opens a browser or mail client).

Malware authors are really lucky.  There are so many autorun possibilities in Windows that it is really hard to count. One of the best known tools that try to enumerate most of the entries are Start Runners and Sysinternals’ autoruns. They both do a a great job by highlighting many of the suspicious files, but… deep inside the registry and file system exist a HUGE number of completely new, unexplored (or possibly less or under- explored) paths that can be (maybe already are)  misused.

Obviously, run-at-system start, run-at-logon are commonly used out of convenience, yet all file/registry locations supporting this persistence mechanism are already very well known and pretty much every single AV is always scanning these locations first (not to mention forensic investigators poking around on the analyzed system ). There are of course many examples of other autostart locations that are not system/logon related and these include Browser Helper Objects, Layered Service Provider DLLs, codecs, protocols handlers, shell extensions, toolbars, deskbars, etc. etc. These are not all though and there is a lot of possibilities out there.  In this post I provide a quick brain dump of various ideas related to this subject – some may be considered silly, or not worth attention, but… oh well, it’s just a post about possibilities Better evil known that unknown.

The autoruns hidden inside other applications

One of the non-standard autorun entries that is probably the most known and documented is the ICQ entry stored under:

• HKEY_CURRENT_USER\Software\Mirabilis\ICQ\Agent\Apps

The old version of ICQ allowed to add a list of applications that it would launch when it connected to network – the following screenshots are taken from old versions of this great software (imho it used to be a real killer app!).

Adding calculator to be run by ICQ was relatively easy:

And it would then appear on the list:

Looking at the registry under

• HKEY_CURRENT_USER\Software\Mirabilis\ICQ\Agent\Apps

would show us the actual entry:

I have a vague memory of successfully testing it ages ago, but since the old version no longer works and I was unable to confirm it for this blog post let’s just trust the evidence that can be found online: Googling for this key brings up quite a few hits that show evidence of it being actively used by malware.

As far as I know new versions of ICQ do not support it anymore.

This, obviously is not the only app ever developed that ‘by design’ helps in launching application when some task/event is completed.

For example, similar functionality can be found in many torrent applications e.g. utorrent:

Adding the entry as shown on the screenshot would make utorrent launch calculator every time it finishes downloading the torrent (the actual data for utorrent autorun is stored inside its configuration file settings.dat).

Same goes for bittorrent client (not a surprise the code of the clients being shared)

Again, the settings.dat holds the ‘autorun’ data:

There may be other applications like this.

The even more hidden autoruns hidden inside applications

Pretty much every single downloader, torrent client, media grabber, etc. contains an option to preview files a.k.a. media player.

This is certainly a possible malware’s autorun as it will be executed anytime someone tries to preview/prelisten the video/music downloaded from P2p client or grabbed from a media grabber; again in a case of e.g. for utorrent:

and emule:

There are certainly lots of applications like this.

‘Scanning’ files with AV when downloaded

Another option to place a malicious file resides in many applications e.g. browsers, mail clients. They allow to scan every single  file that has been downloaded from the internet, attached to email or received via Instant Messenger with an extremal application.

Such feature is available e.g. in Firefox with a Download Status Bar installed.

The about:config page shows the following options (false assigned to ‘downbar.function.virusScan’ property indicates the scan is being disabled)”

the default application selected is ‘C:/Program Files/myAnti-VirusProgram.exe’, but of course malware could easily replace it: 

and modify the ‘downbar.function.virusScan’ property to true.

Notably, placing malware as ‘c:\Program Files\myAnti-VirusProgram.exe’ doesn’t seem to work due to slash/backslash war (this could be a neat trick if it worked).

Windows Shell alternatives

Windows Explorer is not the only Windows Shell available. In fact there are lots of alternatives and each of them brings lots of new options to the table. Looking at programs used by hundreds of thousands (if not millions) of users and including Total Commander, FAR, and many others can cause a real headache. From an offensive perspective there are really a lot of opportunities: from plugins and extensions, to completely new (lame, but certainly workable) ‘rootkitish’ methods for hiding under (sic!) the shell (e.g. custom views, or even simple GUI attacks).

The less obvious places for malware autorun

Most of producers of scanners/printers/combos offer  ‘associated software’ that will be taking control of many aspects of the dialog between the user, device and computer.

One of the tasks handled by the software is  ‘Start this program’ function which is an application that runs when certain events happen e.g. you press a specific button on the scanner/printer. The following screenshot is taken on a system with a CanoScan 4400F scanner attached to it, but with no software installed. The ‘Start this program’ option is grayed out.

Installing a Canon Toolbox gives assigns this program to an event associated with various user activities e.g. pressing COPY button on the scanner.

Clicking the ComboBox reveals more events – all of them are associated with the specific application:

You are probably wondering now where the information about this is stored in the registry/on the file system.

The program responding to device events itself is an example of Push-Model Aware Applications added to the system via Windows Image Acquisition (WIA) / Still Image  interface (STI).

The location in the registry where the Push-Model Aware Applications installed on the system are actually listed are described in the article that I just linked to:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\StillImage\Registered Applications

The programs registered this way can respond to STI events. Of course, malware could overwrite/manipulate the entry and act as a man in the middle between the devioe and the actual software configured to respond to the event. It could also be added to respond to certain events – the actual registry entries that need to be added are described here (I have not tested it though): and include:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\AutoplayHandlers\Handlers

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\StillImage\Registered Applications

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StillImage\Events\STIProxyEvent

Autostart by re-using existing entries

Instead of adding new entries to Run/Startup folder, etc. malware can leverage existing registry entries. In many cases, swapping VERY common entries e.g. for jusched.exe from Java updater, or ctfmon.exe could do the trick. Another option is companion infection for active processes on the system – especially interesting for applications in a Portable format as they are used more and more often and not too many people actually inspect their content. They can also easily be hidden on an inspected system and escape routine analysis of Program Files directory.

Plugins,  Plugins,  Plugins

I mentioned plugins in a context of Windows Explorer alternatives, the same goes for various office suites, Drawing/design applications, gfx viewers (note e.g. Irfanview has a subfolder storing all the plugins – DLL files) and so on and so forth. This is a tip of an iceberg.

File System infection

One of the most interesting pieces of malware back in DOS era was DIR-II. It had a unique way of infecting executable files by modifying their cluster map in the FAT itself. Each .exe would point to a cluster containing the malicious code (always the same cluster) so with a malware NOT active in memory, the file system would appear to be corrupted (because of multiple entries pointing to the same cluster – a problem known as cross-linking). With malware active in memory it would ‘fix’ cross-linking on the fly and execute files properly.

The very same technique could be potentially implemented for NTFS – this would require placing a small .exe on a system then changing the cluster sequence within FILE Record to always point to a cluster occupied by .exe. Other alternative (especially for the one formatted with a FILE record larger than 1024 bytes) would require a tiny .exe that could be stored within the $MFT file record itself (replacing non-resident attribute with a resident attribute) while the actual clusters used by a host file could be stored either in a different part of the file record or within the malicious code itself. In both cases, small .exe would read original clusters and transfer control to the host. Very very non-trivial task. Luckily.

Amongst many various techniques that are used by malware to prevent its detection and analysis (e.g. rootkits, disabling OS tools, anti-debug, anti-disasm, anti-dumping, anti-VM, anti-sandbox, etc.), there are a few that are not so common, yet still “make it ” to some malicious releases. These techniques do not prevent malware analysis itself, but aim at making it difficult for forensic guys to analyze post-intrusion activities. And since the reason for using these is to wipe out traces of actual hacking, finding these inside the binaries usually suggests that the malware is designed to be remotely controlled in a manual fashion (and is not a typical botnet serving different purposes like like spam, or DDoS campaigns). Indeed, anti-forensics routines are often seen in backdoors as well as hacking tools used by carders and APT-like malware. Of course, many of these techniques are not new – even old tools from early noughties use it.

Out of curiosity, I recently searched my sample collection for malware that actually do use anti-forensics techniques (Windows specific only). In order to do searches, I first had to think of various techniques I came across in the past or heard of, and then create a list of interesting targets – this is a list I came up with so far:

• Cache and cookies cleanup (as shown in Purple Haze)
• Event Logs cleanup (as used in various hacking tools)
• RestorePoints cleanup (very rarely used technique, I found only a few samples doing so)
• Weak timestomping (used by many samples, it does change only the timestamps visible in Explorer and shell)
• Full timestomping (haven’t seen any sample yet)
• Changing attributes (this one I skipped, because it’s very common, I list it here only for the completeness)
• Alternate Data Streams (also skipped, because it’s quite common and hard to find good keywords)
• Patching (creating a way to autostart malware without any known autostart keys; also skipped as it is hard to find good keywords other than opening or mapping files in memory + file names of files being patched, usually user32.dll, etc. so it’s too generic)

My searches continue and if I come across something new, I will add it to the list. And if you know some more or spot some techniques I missed, please do let me know.  Thanks in advance!

So, here it is – if you see any of these functions in the malware you analyze, you better get ready for some serious business!

Cache/Cookies cache cleanup

I posted and example recently when I briefly talked about Purple Haze:

APIs and strings to look for:

• FindFirstUrlCacheEntryA / FindFirstUrlCacheEntryW
• UnlockUrlCacheEntryFileA / UnlockUrlCacheEntryFileW
• DeleteUrlCacheEntryA / DeleteUrlCacheEntryW
• FindNextUrlCacheEntryA / FindNextUrlCacheEntryW
• FindCloseUrlCache
• ‘cookie’
• ‘Temporary Internet Folder’

Event logs cleanup

The recent sample I came across is a new version of Gh0st. Its source can be easily found online, so it’s not a surprise we continue to see new updated versions. A simple routine used to clean the Event logs uses a triplet of functions i.e. OpenEventLog, ClearEventLog and CloseEventLog that is executed with 3 different Event log types i.e. Application, Security, System.

APIs and strings to to look for:

• OpenEventLogA / OpenEventLogW
• ClearEventLogA / ClearEventLogW
• CloseEventLog
• ‘Application’
• ‘Security’
• ‘System’

Restore Points cleanup

This is very rarely seen. The sample I looked at contained the following code:

APIs and strings to to look for:

• SRRemoveRestorePoint
• SRSetRestorePointA / SRSetRestorePointW
• ‘srclient.dll’
• ‘Last known good configuration’

Weak timestomping

This is an easy one:

APIs and strings to to look for:

• GetSystemTime
• SystemTimeToFileTime
• SetFileTime

Full Timestomping

This is based on Vincent Liu’s technique used in his timestomp tool and later expanded upon by Joakim Schicht in his SetMACE script – it allows for a full modification of all time stamps within the MFT record on NTFS system (2x $FILE_NAME records and $STANDARD_INFORMATION) either by using NtSetInformationFile / ZwSetInformationFile or by directly writing to a \\.\PhysicalDriveXXX device (where XXX is a number 0, 1, 2, …):

I have not found any malware using it, but this is also non-trivial to find.

APIs and strings to to look for:

• NtSetInformationFile / ZwSetInformationFile
• ‘\\.\PhysicalDrive’

and often together with the following, commonly used functions:

• NtQueryInformationFile / ZwQueryInformationFile
• NtOpenFile / ZwOpenFile
• NtClose / ZwClose
• DeviceIoControl / NtDeviceIoControl / ZwDeviceIoControl
• RtlInitUnicodeString