You are browsing the archive for Compromise Detection.

Beyond good ol’ Run key, Part 17

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

.NET components (a couple of DLLs loaded anytime .NET apps are executed) in the Windows 8.X have been somehow modified and when they are loaded they look for an environment variable called APPX_PROCESS. I am not sure what it is – googling around didn’t bring any results, but experimenting with it led me to a discovery of yet another phantom DLL called WinAppXRT.dll. If the environment variable is set anytime some .NET components are loaded they in turn will attempt to load the aforementioned DLL (e.g. launching powershell or any .NET app should be enough).

Since environment variables can be set via Registry we can use it to develop yet another persistence mechanism.

Adding the following:

[HKEY_CURRENT_USER\Environment]
"APPX_PROCESS"="1"

and dropping the WinAppXRT.dll in e.g. c:\windows\system32 (or any other location accessible via PATH) will ensure the WinAppXRT.dll is loaded everytime user launches an application using .NET.

WinAppXRT

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.