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.
This technique only requires an executable file or a link file, that points to an executable, to be written in the following path:
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’.
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
Dim obj Set obj = CreateObject("Shell.Application") obj.ShellExecute "C:\Windows\System32\calc.exe", , , , 2 Set obj = Nothing
var oShell = new ActiveXObject("Shell.Application"); oShell.ShellExecute("C:\\Windows\\system32\\calc.exe","","","open","1");
<script> var a = new ActiveXObject("WScript.Shell"); a.run('C:\\Windows\\System32\\calc.exe', 0); window.close(); </script>
Observations on Experiment #3
WScript process tree
mshta process tree
batch process tree
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.
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
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