Category Archives: Forensic Analysis

SCCM (System Center Configuration Manager) and Incident Response

Posted on by

Have you ever heard of SCCM?

Yes?

You probably know what I am going to talk about.

No?

Well, you are going to like it.

It’s been a few years since I discovered this gem and successfully used it for Incident Response work.

Cutting long story short, SCCM (System Center Configuration Manager) is a a configuration platform that helps to manage large networks of computers. On top of typical admin tasks, it also can regularly gather information from the systems including very interesting artifacts e.g. file lists.

Now you know where this post is heading.

Having a database of artifacts from the system, a snapshot, if you will gives the company a very powerful tool for both individual system analysis and a global view of all the files stored across the company (when I say ‘all’ here, it usually means a subset, e.g. .exe; this is due to performance hit and database size limitations; talk to your SCCM admin guys to find out what you have).

So, what potentially can you do then with SCCM?

Let me list a few interesting properties of this system:

  • You get a snapshot of ‘all’ file systems across the company.
  • This snapshot is updated continuously (with a specific interval e.g. every day).
  • You can query it using customizable reports that show both specific files, systems, and lots more.
  • The whole thing is backed by the MS SQL engine, so you can even talk to it in SQL.

Accessing SCCM gives the IR folk many opportunities to access very interesting data useful for a daily IR work; to give you a couple of ideas, let’s run through a couple of scenarios one can utilize SCCM for:

  • A daily reporting looking for specific file names f.ex.:
    • known hacking tool names
    • suspicious file names e.g. including common keywords from spam campaigns like ‘invoice’ or ‘payment’, etc.
    • double file extensions e.g. jpg.exe
    • ‘funny’ tools installed by employees
    • etc.
  • If you connect directly to the SCCM database you can do cross-referencing and lookg for anomalies across systems (note that this requires some deep thinking first as the DB is constantly utilized by the system and any large query will not only piss the admins off, but simply bring the system down).
  • You can use it to automatically remove files.
  • The snapshot offers yet another way to look at the system artifacts which are preserved in a separate location; if we are lucky, it’s possible it may list files that have been already deleted from the system and this way offer some insight in attackers’ doing or provide clues for further analysis – it complements the file listing acquired either through live or offline analysis
  • Remember that this is data which is already gathered anyway, so the cost is null. Okay, it may cost you a beer that you will buy me one day 🙂

Well, that’s it. If you don’t use SCCM yet you better have a good chat with your admins. The chances are that you may actually start using it on regular basis and generate a series of ‘quick wins’ which will not only please your bosses, but more importantly – improve the security of your company.

Beyond good ol’ Run key, Part 4

Posted on by

Last three articles about various startup/autostart methods covered a lot of different well- and less-known techniques for ‘staying alive’. Many of them are actively used by malware and ‘normal’ software; some are just ideas that are worth describing because… luck favors a prepared mind. If you haven’t read them previously, you can do so by visiting these links: Part 1, Part 2, Part 3.

In today’s post I will cover some more techniques including hijacking of various debuggers and some more obscure ways of ‘survival’. I think this is probably the lamest part of the series so far, because the techniques are old-school and amateurish, but luckily it is not the last one, so stay tuned for Part 5 🙂

Hijacking debuggers

The list of debuggers one can replace on the system is as follows:

  • Standalone Debugger (32- and 64- bit)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\AeDebug]
Debugger = PATH

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\
Windows NT\CurrentVersion\AeDebug]
Debugger = PATH
  • .NET Debugger (32- and 64- bit)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
DbgManagedDebugger = PATH 

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
DbgManagedDebugger = PATH
  • Script Debugger
[HKEY_CLASSES_ROOT\CLSID\
{834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]
@=PATH

Registering itself as a Script Debugger
The Windows Script Debugger (WSD) is a standalone tool that one can use to actively debug their scripts (e.g. vbs). Once installed, a developer can run one of the following commands:

  • cscript /x script.vbs

or

  • wscript /x script.vbs

to debug the script.

The name of the executable that is used as a debugger is stored inside the following key

  • [HKEY_CLASSES_ROOT\CLSID\
{834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]

and on a system where the WSD is installed may look like this:

  • [HKEY_CLASSES_ROOT\CLSID\
{834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]
@="C:\\Program Files\\Microsoft Script Debugger\\msscrdbg.exe"

One could replace the script debugger path to lead its own executable anytime the debugger is launched and this way making it kinda persistent on the system. Kinda, as the .exe will be executed only on rare occasion when the debugger is actually being installed (developer’s or power user’s machine).

Other issue is that the launching of the script debugger takes more steps than just looking up the value n the registry and launching the appropriate application.

When VBScript tries to find the debugger it talks to few COM components first (e.g. Process Debug Manager) so in order to make it work, one would need to also register these COM components (if you want to know more details, install WSD and see registry changes associated with the installation).

Hijacking Process Debug Manager

The alternative persistence mechanism could hijack one of these COM components that VBScript ‘talks to’ and replace its server path to point to a malicious file. The DLL does not even need to implement any COM functionality and it’s enough for it to be a simple, loadable library. The Process Debug Manager that I mentioned earlier could do the trick here. Its CLSID’s value on a system where WSD is installed is shown below:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\
{78A51822-51F4-11D0-8F20-00805F2CD064}\InprocServer32]
@="C:\\WINDOWS\\system32\\pdm.dll"

Pointing InprocServer32 to a malicious DLL would load anytime VBScript (or any other module) is ‘consulting’ ProcessDebugManager.

ServiceDll Hijack

Many entries under

  • [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services]

can be hijacked by swapping their ServiceDll parameter to point to a malicious entry. e.g. the Remote Access Service registry entry

  • [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\RemoteAccess\Parameters]

normally points to

  • %SystemRoot%\System32\mprdim.dll

but it can be changed to point to a malicious component. There are many default services that could be hijacked this way.

Mapi32 Stub Library

Older versions of Outlook 2007 allowed to add extra functionality to Outlook by means of installing a custom version of mapi32.dll in the system directory as explained in this article.

The relevant Mapi32.dll Stub Registry Settings are provided in the Registry in the following location:

  • [HKEY_LOCAL_MACHINE\Software\Clients\Mail::(default)]
    • DLLPath

      Full path to the Simple MAPI provider DLL.

    • DLLPathEx

      Full path to the MAPI provider DLL. Provider DLLs that support both Simple MAPI and MAPI must have both keys set.

Obviously, this mechanism is a perfect target for abuse.

Hijacking Client executables

The Registering Programs with Client Types article from Microsoft explains on ‘how to register a program in the Windows registry as one of the following client types: browser, email, media playback, instant messaging, or virtual machine for Java.’. Looking at the registry entries associated with these registration we can find the following key:

  • [HKEY_LOCAL_MACHINE\Software\Clients\]

Many applications listed under this key can be hijacked e.g. Mail program contain keys that point to executables::

  • [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Windows Mail\InstallInfo]
    • HideIconsCommand
    • ReinstallCommand
    • ShowIconsCommand

Windows 2000 Welcome

Installation of Windows 2000 always ends up with the “Getting Started with Windows 2000” window shown on the screen after the system restarts. User has an option to disable it, but the box is ticked ON by default.

The window shows up as a result of welcome.exe being executed from the following location:

  • C:\WINNT\Welcome.exe

The flag that determines whether the welcome.exe is executed or not is stored in the following Registry location:

  • [HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\
tips\Show: 0x00000001]

Replacing welcome.exe and ensuring the value of Show is equal to 1 will make the C:\WINNT\Welcome.exe execute every time system starts.

Well, not quite.

If the file is replaced, it will be ‘magically’ restored from the following location:

  • c:\WINNT\system32\dllcache\welcome.exe

So, the malware needs to be copied into 2 locations, and… the Windows File Protection needs to be disabled as well 🙂

Thanks for reading and see you in the Part 5.