You are browsing the archive for Forensic Analysis.

Beyond good ol’ Run key, Part 16

August 27, 2014 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

Documenting various persistence mechanisms would not be complete without mentioning these that could be based on legitimate and fully-documented system features. One such mechanism we are going to talk about is called ‘custom Power Shell profile’. It is a distant cousin of autoexec.bat and it can be abused to ensure some malware component is loaded anytime someone starts powershell host.

There is actually a full article describing this mechanism here, so I will just quote the most important (from the forensics perspective) bit:

  • %windir%\system32\Windows­PowerShell\v1.0\profile.ps1
    • This is for all users of the computer and for all shells.
  • %windir%\system32\Windows­PowerShell\v1.0\Microsoft.Power­Shell_profile.ps1
    • This is for all users of the computer, but it is only for the Microsoft.PowerShell shell.
  • %UserProfile%\Documents\Windows­PowerShell\profile.ps1
    • This is for the current user only and all shells.
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
    • This is for the current user only and only for the Microsoft.PowerShell shell.

You can test it by running the following commands (obviously file writing restrictions apply depending on the OS and the user privileges):

md %UserProfile%\Documents\WindowsPowerShell\
md %windir%\system32\WindowsPowerShell
md %windir%\system32\WindowsPowerShell\v1.0\

echo echo profile1 >%windir%\system32\WindowsPowerShell\v1.0\profile.ps1
echo echo profile2 >%windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
echo echo profile3 >%UserProfile%\Documents\WindowsPowerShell\profile.ps1
echo echo profile4 >%UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

and then run PowerShell.

Btw. If you are wondering what these commands are doing – first 3 ensure the respective directories exist; the next 4 ones create dummy profile files with a simple command ‘echo xyz’, where xyz is a number of the profile. When executed for testing purposes they will simply show you which profile has been loaded by PowerShell. In a real-case scenario these would be replaced with an instruction to launch malware or could be any PowerShell command.

Anyway, back to the test. You will most likely be surprised to see that PowerShell does not load these profiles without a fight i.e. you may see a couple of error messages.

This is because by default the OS policy prevents executing PowerShell scripts (including the profile scripts) and one has to enable them first as documented here.

The Windows Registry values guarding this policy are stored under respective hkcu/hklm branches:

software\policies\microsoft\windows\powershell\
         EnableScripts (REG_DWORD)
         ExecutionPolicy (REG_SZ)

One can enforce then script execution by running the following commands (hklm may replace hkcu):

reg add hkcu\Software\Policies\Microsoft\Windows\PowerShell /f /v EnableScripts /t reg_dword /d 1
reg add hkcu\Software\Policies\Microsoft\Windows\PowerShell /f /v ExecutionPolicy /t reg_sz /d Unrestricted

Launching PowerShell now will show the following:

powershell_profile

You can download a batch file that I used to test the commands here.

Tested on Windows 8.1 and Windows 7.

Beyond good ol’ Run key, Part 15

August 4, 2014 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis

Today I am going to show you yet another debugging mechanism that allows to load a couple of phantom DLLs.

This time the culprit is DirectX.

The DirectX is pretty much a standard for programming anything that is multimedia-related on Windows. Since this includes games, animations, demos, as well as video players, picture viewers, etc. the phantom DLLs (they are debug DLLs in this case) can be easily made persistent because they will be loaded anytime one of such DirectX-aware applications starts.

Dropping one (or both) of these DLLs:

  • d3d8d.dll
  • d3d9d.dll

in one of the directories covered by the PATH variable and adding the following Registry Entry

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Direct3D]
@=""
"LoadDebugRuntime"=dword:00000001

will ensure that these DLLs will be loaded anytime a Direct X (its component called Direct 3D) is being used by some application. They are loaded by respective Direct X versions (8 or 9).

To test on XP (DirectX version 8 still is being used by dxdiag):

  • Add the registry entry
  • Drop test d3d8d.dll and d3d9d.dll into e.g. c:\windows\system32 directory
  • Run dxdiag
  • Go to Display tab
  • Click Test Direct 3D
  • You should see that d3d9d.dll is loaded when dxdiag starts and d3d8d.dll loads when you test Direct 3D feature on the Display tab

To test on Win 7 (DirectX version 8 doesn’t seem to be used by dxdiag, but DLLs are present and applications loading Direct X 8 libraries will _still_ load the DLLs):

  • Add the registry entry
  • Drop test d3d9d.dll into e.g. c:\windows\system32 directory
  • Run dxdiag
  • You should see that d3d9d.dll is loaded when dxdiag starts

In other words, it should work on all OSes that have the Direct X 8 or 9 installed.

You may be wondering if the same trick works for newer versions of DirectX.

It does.

The naming convention stays the same (e.g. d3d10d.dll, d3d11d.dll), but the major change is that:

  • The loading is not system-wide (or, more specifically DirectX-ecosystem wide), but application specific, hence a different registry entry is being used to load these DLLs
    • e.g. for dxdiag it would be
      • HKEY_CURRENT_USER\Software\
         Microsoft\Direct3D\dxdiag\
         D3D10LoadDebugRuntime=1
  • The DLLs (e.g. d3d10d.dll) are loaded only under very specific circumstances (only a couple of Direct X functions related to shaders load the debug DLLs) so chance for it to be a successful persistent mechanism are much lower
    • I guess the DLLs are used to test performance of the graphic primitives, but I have no programming experience with Direct X so can only speculate here