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


– 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).

The cyberpoppers, the security fix, and … the Other guys

May 10, 2017 in Preaching

Cyberpopping is a term I coined for the lack of a better word to describe any vague and most of the time responsibility-free activity that is either used and/or abused to sell and market IT security in whatever form and shape possible. Yup, the activity where the seller is not being necessarily responsible for overseeing that security to the remediation/closure/assurance phase.

We all practice it.

There are various cyberpoppers out there:

  • 0days
  • APT
  • Dumps
  • Security Certificates
  • Security Conferences
  • Social media, including Twitter and blogs (including yours truly)
  • Periodical reports from vendors and Gartner
  • Compliance requirements (PCI DSS, ISO)
  • Groups, forums
  • etc.

At every step of this journey the ego and schadenfreude prevails. We all know better. And anytime we find something new and cool, the Champagne cork pops and we get the fix. I love it, you love it. We are one big family of security enfants terrible 🙂

As I get older though and get more and more insight into the less flashy part of the security world – one where the security is actually being implemented – it becomes more and more apparent to me that none of these things really help the Other guys. If you watched the movie you know who I am talking about. These poor creatures that sit in the backend offices, spend hours on the calls, actually talk to business people and clients, speak to non-technical people, and ensure the stuff that we are all breaking, or talk about breaking – is actually fixed. This is not a fun job, it’s error-prone, it ricochets when they screw up (it often costs big bucks!), it is long hours, and on-calls where the big decisions are made. I just want to take the moment today to say thank you to all engineers, admins, firewall guys, architects, customer-facing security guys, vulnerability management teams, and ISOs and any other guys who actually deal with the _real_ world aspects of IT security.

Copyright note: the pic adapted from the one posted on wikipedia