Persistence 101: Looking at the Startup directory as attacker and defender

When attackers compromise hosts and plant malware, one of the key objectives is gain persistence. Writing a malware on a host does not warrant it survives reboot. In order to persist, the Startup directory can be used. Achieving persistence on systems running Windows utilizing the Startup directory is no news. The technique is also documented in the MITRE ATT&CK framework as T1060. In this article we revisit this technique (experimenting on a Windows 10 host), we present tricks that malware authors use and most importantly highlight what defenders can do to detect or hunt for malware that persists with this technique.

Attacker’s standpoint

This technique only requires an executable file or a link file, that points to an executable, to be written in the following path:

%systemdrive%\Users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Following a reboot or user-logon, the Windows operating system, executes the executable file(s) that exist in the path.

Experiment #1 - Be straightforward

In order to experiment with this technique, we copied the Windows Calculator in the Startup directory, renamed it to ‘malware.exe’ and then rebooted the machine. Indeed, our copy of calculator was launched as soon as we logged in.

Observations on Experiment #1

Since the calculator is an active process launched during startup, one would expect that tools like Process Hacker and Process Explorer would list this process. However, only Task Manager was able to show that Calculator was actually running on the host. The process is running under the context of the user account that logs on the host.

We did the same experiment again but this time we enabled the Boot Logging on Process Explorer. This time, the result is what we expected. The ‘malware.exe’ process was spawned by the parent process ‘Explorer.exe’.

Variation(s)

Is there a way to execute a payload when we don’t want to directly copy an executable in the Startup directory or we want to execute a script instead (Batch, VBScript, JavaScript, HTML Application)? Then, the way to go is to either create a link file (shortcut) that points to the executable/script we want to execute persistently or just write the script itself in this directory.

Experiment #2 - The link file

Let’s think of the link files as containers that can be used to direct users to execute something they are not aware of. This rational is based on the assumption that a small number of users would ever right-click a link file and check the target path of this file. In the target path a path to malicious executable or to malicious script can be placed.

In this experiment, we copied the renamed Windows Calculator into the path C:\Windows\Tasks\ and created a link file that points to this file. As an additional step to trick the investigators/hunters we named the link file Microsoft Outlook. A link file with this name would likely not raise suspicion - even if it did, further analysis would be required. Have in mind that cyber operations contain forms of deception, exactly like what happens in real battlefields. We then placed the link file in the startup directory and rebooted the machine. Result? Our copy of Calculator - named malware.exe - is launched by Explorer.

Link files can also be used as a means to execute files that cannot be executed directly or binaries that require command line arguments. For example, a link file pointing to rundll32.exe can be used to execute a DLL planted by the attacker. Many Leaving Off The Land Binaries (documented in https://lolbas-project.github.io) can be used along with link files.

Experiment #3 - The dropped script

We did the same procedure but this time writing three scripts in the Startup directory. An HTML Application script (.hta), a VBScript (.vbs), a JavaScript (.js) and a Batch script (.bat). Each script is set to launch the legit copy of Calculator located in C:\Windows\System32. See below the code we used in each of the scripts.

VBScript launcher:

Dim obj
Set obj = CreateObject("Shell.Application")
obj.ShellExecute "C:\Windows\System32\calc.exe", , , , 2
Set obj = Nothing

JavaScript launcher:

var oShell = new ActiveXObject("Shell.Application");
oShell.ShellExecute("C:\\Windows\\system32\\calc.exe","","","open","1");

HTA launcher:

<script>
    var a = new ActiveXObject("WScript.Shell");
    a.run('C:\\Windows\\System32\\calc.exe', 0);
    window.close();
</script>

Batch launcher:

C:\Windows\System32\calc.exe

Observations on Experiment #3

The dropped scripts were successfully executed and Calculator was launched in every case. For VBScript and JavaScript, the parent process of Calculator is WScript.exe. Following the process tree we recorded using SysInternals’ Procmon, we observe that the parent process of WScript is Explorer.exe. For HTA, the parent process is mstha.exe. Following the process tree again, we observe that the parent process of mshta.exe is again Explorer.exe. For Batch scripts, the parent process of Calculator is cmd.exe and the parents process of cmd.exe is again explorer.exe. See the following screenshots that show the process tree.

wscript WScript process tree

msht mshta process tree

batch batch process tree

Combined Techniques

There have been incidents in which attackers have installed legitimate applications vulnerable to DLL Search Order Hijacking (Mitre Technique: T1038). The legitimate application persists on the host using the Startup directory. With this technique, attackers are able to load malware in the context of legit applications and thus conceal their actions as well as raise the bar for defenders.

Defender’s standpoint

What the defenders/investigators can do to detect/investigate this persistence mechanism? There are certain things that can be applied:

In an enterprise environment, set up alerts for file write events in the Startup directory (look for files with the following extensions: .exe, .bat, .vbs, .js, .hta as well as link files)
Maintain a list of known good and permitted in your environment applications
For analyzing stand-alone systems, tools like SysInternals’ Autoruns, reveal files that exist in the startup directory
Acquire and analyze files that exist in this directory. Files with extensions .bat, .vbs, .js, .hta are more likely to demonstrate malicious behavior. However, scripts that facilitate system administration could also exist in Startup directory
In digital forensic investigations, always consider that when the parent process of a suspicious process is ‘Explorer.exe’ this doesn’t necessarily indicate that the activity was triggered by manual activity. The activity could be the result of persistent execution

Recap

In this article we touched one the most well-known persistence mechanisms, the Startup directory. We presented how executable files as well as scripts written in this directory survive reboot. We also showed the parent-child process relationship between the executed resources and finally provided recommendations to defenders.

* Any feedback on this article would be greatly appreciated

tags: #persistence