You are browsing the archive for Forensic Analysis.

Beyond good ol’ Run key, Part 62

April 19, 2017 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

Update

This is not an RCE. If it was, I would not publish it on this blog 🙂

Turns out “Simpsons already did it” and as pointed out by @arekfurt a normal template-based persistence is already implemented in EmpireProject and is based on awesome work of @enigma0x3. Interestingly, disabling macros is not needed to deliver the same functionality (as explained below).

Dropping any macro sheet inside the XLSTART folder and opening it from there will not show the macro warning 🙂

Old Post

Every once in a while we come across weird things that we not only discover accidentally, but are finding hard to understand. Today I was playing around with Word Macros and to my surprise I was able to accidentally run one, while my Macro Options were set to Disable all macros with notification.

Intrigued, I quickly realized that instead of adding it to a test word document, I accidentally added it to the normal template file.

Could it be… ?

I rushed to add the AutoOpen macro to the normal template that will launch the Calculator anytime the template is used:

Now I only needed to open some word document…

How nice!

Interestingly, the Security Warning appears ONLY after I visit options while the document is open.

Swap calculator with anything else, and a new stealth persistence mechanism is born…

Now, what about Excel?

Excel doesn’t have the Normal template equivalent by default, but you can add one. To do so, you just need to record any macro named Auto_Open and store it inside a personal template (by choosing ‘Store macro in Personal Macro Workbook‘):

(alternatively, you can create a personal template directly on the system by placing a prepared XLSB file in a following location: c:\Users\<USER>\AppData\Roaming\Microsoft\Excel\XLSTART\PERSONAL.XLSB)

Then switch to the macro editor, and write the code as below:

This will ensure the Calculator will be executed anytime someone opens Excel, even if the macros are *cough* *cough* disabled…

Beyond good ol’ Run key, Part 61

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

3.5 years ago in the part 4 of the series we talked about various Registry keys related to debuggers.

Today we will implement one.

One of the important system processes present in Windows since Vista is the Local Session Manager that runs from the file called lsm.exe. In Windows 10 the service was moved from a separate service process to lsm.dll that is loaded under svchost.exe. I don’t discuss Vista and Win8 details below, because who is using them anyway, but… it should work there too.

The lsm process has a little secret.

When it starts it checks for a presence of the following entries:

  • HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server
    • DebugTS=1 or 2 or 3
    • LSMBreakOnStart=1 or 2 or 3 (Windows 10 only)
    • Debugger = any string

The value of DebugTS (or LSMBreakOnStart) determines how LSM process will behave:

  • 1 – it will check if the user or kernel mode debugger is running, and if any of them is present it will just call DebugBreak to break into debugger session.
  • 2 – if the user mode debugger is not present, the LSM will actually launch it (guess what this post is all about…).
  • 3 – similar to 1.

For the option 2, the LSM will launch the NTSD debugger process using the following command line syntax:

  • ntsd -d -G -x -p <LSM pid>

Yup. The \windows\system32 path is not even specified, so the ntsd just needs to be placed in any location covered by the PATH environment variable.

And in case you are wondering, the ntsd will be launched with the full SYSTEM privileges.

Windows 7:

Window 10:

In order for things to work you need to implement ntsd.exe as a debugger to mimic the expected behavior. It has to take the PID from the command line, or retrieve the parent’s PID via NtQueryInformationProcess (or other means) and attach itself to LSM process. It then needs to create a debugging loop that will ensure the lsm.exe continues to work… and a system starts with the ntsd.exe running in a background. Since the ntsd is launched in an insecure way, it is most likely a subject to a path companion attack (both via PATH and the ntsd.com). I have not tested the latter, cuz it’s 2:00am.