You are browsing the archive for Anti-Forensics.

Beyond good ol’ Run key, Part 40

June 2, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

And here we are… another round anniversary…

To celebrate this special event, I have prepared a special dish for Windows 10 lovers 🙂

To inaugurate the celebration:

  • Create C:\Program Files\Internet Explorer\suspend.dll
  • Profit

Yup. It will launch anytime user starts IE. And when they exit it (the life of a DLL…).

To continue the festivities:

  • Create phoneinfo.dll anywhere the PATH points to, or inside the c:\windows\system, C:\Windows\System32\wbem or on the Desktop – IE will try really hard to load it:
  • Profit

Yup. It will launch anytime user starts IE too. And yup, when they exit it too.

It does work for 64-bit processes too.

And the final fanfares…

When your program crashes on Windows 10, werfault.exe will attempt to load loads of non-existing debugging extensions.:

  • C:\Windows\SYSTEM32\WINXP\uext.dll
  • C:\Windows\SYSTEM32\winext\uext.dll
  • C:\Windows\SYSTEM32\winext\arcade\uext.dll
  • C:\Windows\SYSTEM32\pri\uext.dll
  • C:\Windows\System32\uext.dll
  • C:\Windows\SYSTEM32\winext\arcade\uext.dll
  • C:\Windows\System32\uext.dll
  • C:\Windows\SYSTEM32\WINXP\ntsdexts.dll
  • C:\Windows\SYSTEM32\winext\ntsdexts.dll
  • C:\Windows\SYSTEM32\winext\arcade\ntsdexts.dll
  • C:\Windows\SYSTEM32\pri\ntsdexts.dll
  • C:\Windows\System32\ntsdexts.dll
  • C:\Windows\SYSTEM32\winext\arcade\ntsdexts.dll
  • C:\Windows\System32\ntsdexts.dll

Bonus #1:

The phoneinfo.dll DLL seems to be used by a lot of processes (it is actually loaded by urlmon.dll, so lots of processes are affected).

Bonus #2:

Cursory analysis of code that is responsible for loading this DLL indicates that it’s most likely code used on Windows phones-only and it’s just the DLL is not present on Desktop Windows (yet the code loading the phantom DLL remained). The DLL is responsible for telling the urlmon what Phone Manufacturer and Model to add to one of the internal User Agent strings inside the urlmon library

Beyond good ol’ Run key, Part 39

May 30, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

In my previous post in this series I talked about the Logon scripts. This nice concept of being able to run some code when system-wide, or user-wide events happen is very useful in a managed environment.

The Logon event is one of a number of events that can be recognized by the system and as a response, an appropriate script can be executed. Other events include Logoff, Startup and Shutdown events. Apart from the already described mechanism, one can rely on Group Policies and use GPEDIT.MSC to set up event-aware scripts on the local system.

For example:

  • Startup and Shutdown


  • Logon and Logoff


(note, the screenshots are from XP cuz it’s holiday and I am lazy, but same applies to newer versions of Windows)

Once the appropriate Event is selected f.ex. Startup:


We can add the script using a dialog box:


We can also repeat the sequence and add a number of scripts:


The system stores the scripts in the following location:

  • c:\WINDOWS\System32\GroupPolicy\Machine\Scripts


Inside the folder we can see the following files:

  • The config file:
    • c:\WINDOWS\System32\GroupPolicy\Machine\Scripts\scripts.ini
  • and our scripts:
    • c:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Startup\Startup1.bat
    • c:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Startup\Startup2.bat
    • c:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Shutdown\Shutdown1.bat
    • c:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Shutdown\Shutdown2.bat

Note: I have added 2 scripts for each event.

The content of the files is as follows:


And the same story for Logon/Logoff events:

  • The config file:
    • c:\WINDOWS\System32\GroupPolicy\User\Scripts\scripts.ini
  • and our scripts:
    • c:\WINDOWS\System32\GroupPolicy\User\Scripts\Logoff\Logoff1.bat
    • c:\WINDOWS\System32\GroupPolicy\User\Scripts\Logoff\Logoff2.bat
    • c:\WINDOWS\System32\GroupPolicy\User\Scripts\Logon\Logon1.bat
    • c:\WINDOWS\System32\GroupPolicy\User\Scripts\Logon\Logon2.bat

with the content as follows:

If we restart the computer now (making all the events happen: Logoff, Shutdown, Startup, Logon), we can observe that our scripts are all executed one by one – as indicated by the ‘trace’ files created by each script:

piceI also temporarily modified the startup script to pause before continuing – just to show that the scripts are executed by userinit.exe:


Trivia fact: while preparing the post I noticed that an old autoruns present on my test VM shows some of the scripts incorrectly i.e. under the HKLM\…\Run key:


The latest version works like a charm… or not 🙂 – note that scripts are duplicated and Logoff event shows 6 entries instead of 2:

picmIf in doubt, we can always visit the Registry entries where the information about these 4 events is stored:



Inspecting the Registry entries we can notice that the …\Scripts\Logon\<number>\FileSysPath properties can be modified:


In my case I modify it to c:\test and I am recreating the Logon/Logoff scripts folder structure there:


Luckily, autoruns picks it up too:


Last, but not last – if such entries already exist on the system, an attacker could simply append some commands to existing scripts, or hijack execution of existing commands using many of existing tricks (f.ex. path interception, path companion, etc.).