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