You are browsing the archive for Forensic Analysis.

← Previous Entries

Using RegisterApplicationRestart as a (lame) sandbox evasion

May 20, 2017 in Anti-Forensics, Forensic Analysis, Sandboxing

The RegisterApplicationRestart function allows the OS to relaunch the application in case it crashes, or fails for other reasons (or when an installer needs to restart the system and then launch again).

To avoid cyclical restarts the program needs to run for at least 60 seconds though.

So, imagine a program that does the following:

  • Check if a specific command line argument is provided
    • If yes
      • Run malware
    • If no
      • Register itself via RegisterApplicationRestart and provide a command line f.ex. /nosandbox
      • Sleep for 60 seconds using Sleep
      • Cause a crash (f.ex. divide by 0)

If the application is ran w/o a sandbox, it will be relaunched by the OS after the crash and with a /nosandbox argument – it will execute the malware.

If the application is ran under sandbox, the sandbox engine will most likely affect the running of the Sleep function. This in turn will disable the functionality of the RegisterApplicationRestart function. The program will run less than 60 seconds, hence won’t be restarted after the crash. The sandbox report will be pretty much empty.

Note, with its default settings, Windows 10 will simply restart the application:

For earlier versions, the user may be asked to choose whether they want to restart the application (depending on Windows Error Reporting settings). Notably, if such dialog  popped up while the sample was running inside the sandbox, there is a chance the sandbox would autoclick the ‘restart’ option for us. But then… well.. it would have to wait these 60 seconds first, wouldn’t it?

Bonus forensic information:

The less used option of RegisterApplicationRestart API is in conjunction with installers. If combined with ExitWindowsEx,EWX_RESTARTAPPS,… it will register the app to be executed by the systems with the next logon. The mechanism of this temporary persistence mechanism is quite interesting.

Right before the user is logged off the csrss.exe process registers a RunOnce entry located in the following location:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\Application Restart #<NUMBER>

– it is simply pointing to the restarted application.

So, if you ever see entries like these:

  • HKCU\Software\Microsoft\Windows\
    CurrentVersion\RunOnce\Application Restart #0
  • HKCU\Software\Microsoft\Windows\
    CurrentVersion\RunOnce\Application Restart #1

etc.

– then it’s most likely a result of an unfinished installer business…

Could it become a persistence mechanism and become a part of the Beyond Good Ol’ Run key series? Perhaps, but I have not found a practical way to do it w/o restarting the system (perhaps aborting the restart could help, but from what I can tell the csrss.exe registers the RunOnce persistence mechanism pretty late).

Comments Off on Using RegisterApplicationRestart as a (lame) sandbox evasion

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, enabling 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…

Comments Off on Beyond good ol’ Run key, Part 62

← Previous Entries