Category Archives: Anti-Forensics

Beyond good ol’ Run key

Posted on by

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.

 

The shortest anti-forensics code in the world – take #2

Posted on by

In my older post, I claimed that replacing command line buffer is the shortest anti-forensics code as it takes 25 bytes only.

Sorry, I lied.

There are many ways to come up with a much shorter anti-forensics code. I will describe three ideas here. All of them are super obvious.

#1

Just use CopyFile function and copy Notepad.exe or any other file always present on the system over the file that is meant to be deleted (before its deletion). You may need some extra bytes for the file names, but well, it’s just one API call that it takes to implement a simple secure deletion.

#2

The second idea came (indirectly) from Harlan Carvey. He has been recently writing about his ongoing work to improve Prefetch file parsing script. While reading the MSDN article he referred to, I stumbled upon a description that I have read many times before, but never really thought of it from the anti-forensic angle.

In order to know what it should prefetch, the Windows XP Cache Manager monitors the page faults, both those that require that data be read from disk (hard faults) and those that simply require that data already in memory be added to a process’s working set (soft faults), that occur during the boot process and application startup. By default it traces through the first two minutes of the boot process, 60 seconds following the time when all Win32 services have finished initializing, or 30 seconds following the start of the user’s shell (typically Microsoft Internet Explorer), whichever of these three events occurs first. The Cache Manager also monitors the first 10 seconds of application startup.

Read the last sentence one more time:

The Cache Manager also monitors the first 10 seconds of application startup.

That is.

To reduce a number of forensically useful artifacts stored inside a Prefetch file, all the application has to do is… wait for 10 seconds. This can be easily achieved by running a function Sleep or NtDelayExecution at the entry point. Of course, there are extra bytes needed to import the function, etc., but since malware is often using one of these API anyway, a few bytes is what it takes.

I ran a quick test and it works as described:

The same code executed without any delay produced this Prefetch file:

General information :
  Filename  : PREFTEST.EXE
  Run count : 1
  Run time  : Fri Mar 16 17:29:33 2012 (UTC)

Prefetch file information:
  Reported size     : 2468
  Real size         : 2468
  Last access time  : Fri Mar 16 17:29:48 2012 (UTC)
  Modification time : Fri Mar 16 17:29:43 2012 (UTC)
  Creation time     : Fri Mar 16 17:29:48 2012 (UTC)

Filepaths block (1240) :
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SORTTBLS.NLS
  \DEVICE\HARDDISKVOLUME1\WINDOWS\PREFETCH\PREFTEST.EXE
  \DEVICE\HARDDISKVOLUME1\WINDOWS\PREFETCH\FILE.TXT

Volume information block (1976) :
  Volume Path   : \DEVICE\HARDDISKVOLUME1
  Serial Number : 1216058920
  Creation Time : Sun Jan  6 13:31:42 2008 (UTC)
  \DEVICE\HARDDISKVOLUME1\
  \DEVICE\HARDDISKVOLUME1\WINDOWS\
  \DEVICE\HARDDISKVOLUME1\WINDOWS\PREFETCH\
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\

and after adding at least 10 seconds delay at its entry point we get the following result:

General information :
  Filename  : PREFTEST.EXE
  Run count : 1
  Run time  : Fri Mar 16 17:30:30 2012 (UTC)

Prefetch file information:
  Reported size     : 2304
  Real size         : 2304
  Last access time  : Fri Mar 16 17:30:46 2012 (UTC)
  Modification time : Fri Mar 16 17:30:40 2012 (UTC)
  Creation time     : Fri Mar 16 17:30:46 2012 (UTC)

Filepaths block (1184) :
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SORTTBLS.NLS
  \DEVICE\HARDDISKVOLUME1\WINDOWS\PREFETCH\PREFTEST.EXE

Volume information block (1824) :
  Volume Path   : \DEVICE\HARDDISKVOLUME1
  Serial Number : 1216058920
  Creation Time : Sun Jan  6 13:31:42 2008 (UTC)
  \DEVICE\HARDDISKVOLUME1\
  \DEVICE\HARDDISKVOLUME1\WINDOWS\
  \DEVICE\HARDDISKVOLUME1\WINDOWS\PREFETCH\
  \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\

So, if you come across an empty Prefetch file in the future, don’t be surprised 🙂

I used this script by Jean François Gingras to parse Prefetch files.

And this is a source of a masm32 code I used in a test:

.586
 .MODEL FLAT,STDCALL
 include    windows.inc
 include    kernel32.inc
 includelib kernel32.lib
 include    user32.inc
 includelib user32.lib

 .data
 file db 'file.txt',0

 .data?
 numOfBytesRead dd ?
 buffer db 256 dup(?)

 .code
 Start:
 ;  invoke Sleep,15*1000
 invoke CreateFileA, OFFSET file, \
 GENERIC_READ, \
 FILE_SHARE_READ or FILE_SHARE_WRITE, \
 NULL, \
 OPEN_EXISTING, \
 FILE_ATTRIBUTE_NORMAL, \
 NULL
 invoke ReadFile, eax, \
 OFFSET buffer, \
 SIZEOF buffer, \
 OFFSET numOfBytesRead, \
 NULL
 ; invoke Sleep,15*1000
 invoke ExitProcess,-1
 END Start

All you have to do is uncomment one of the lines ‘; invoke Sleep,15*1000‘ – first one, if you want to keep the Prefetch file clean, and second one if you want to see ‘file.txt’ inside the Prefetch file associated with the executable. Note, for the .pf file to be created program needs to run for at least 10 seconds and actually read the file.

This sort of tricks may sound like a good idea, but as many forensic investigators already know – and as pointed out by Harlan who commented on one of my previous posts here – that (quoting) “the absence of an artifact where you expect to find one is itself an artifact”. Indeed. Not having any file listed inside the Prefetch file doesn’t change the fact that its sole presence indicates the executable _has_ been ran and some useful forensic data can still be fetched from the *.pf files even if they are kind of empty.

This leads me to the third idea that is the most obvious.

#3

Malware can either delete the prefetch file, or use some way to hide it e.g. using PrefetchADS technique I described in one of my forensic riddles. This also can be achieved with one API call.

 

So, there you have it. Anti-forensics, counter-forensics, or forensics prevention can be implemented in a simple and very effective way. And even if they can’t fool an experienced investigator, they surely can take lots of fun from investigation, increase time spent on chasing after ghosts and remove all the juice from the final report. After all, it’s the ‘smoking gun’ that we all want to show, not a circumstantial evidence that leaves many questions unanswered.