Category Archives: Anti-Forensics

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.

Anti-forensics – live examples

Posted on by

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