top of page
Search

Pesky Persistence: How "Turning It Off and On Again" May Not Solve Your Problem

Anyone that uses a computer has heard the old "have you tried turning it off and on again" as a solution to experiencing issues; however, there are times where a reboot or a "hard reset" don't eradicate the source of the woes plaguing the user. In this week's blog post, we delve into persistence mechanisms and how malware can survive a reboot.



What is persistence?


Persistence, as defined by MITRE, is "the adversary trying to maintain their foothold." It's a way for threat actors to reduce the odds of their access to a system being removed, as well as adding an automation functionality to code execution on the target system. There's a wide array of techniques that can be leveraged to achieve this, and we'll cover some of those below.

Persistence techniques


Scheduled tasks/jobs

Scheduled tasks/jobs give threat actors the ability to attempt code execution at a specific time or on a recurrent basis. The malware may have the built-in capability to communicate back to adversary infrastructure via a C2 channel. This would be beneficial in that it, at minimum, would tell the threat actor that the system is live and the implant is still functional. (You can read more about C2 on my previous blog post)

Registry autorun keys

Adding a value to a registry autorun keys will cause the program linked to that value to execute upon user logon. Autorun keys can be found across different hives, and can be specific to the user or system-wide; which hive is used will impact the persistence and its pervasiveness. For example, utilizing a run key that is in the HKLM (Local Machine) hive will ensure that the referenced code is executed upon every system boot, regardless of which user is authenticating. Microsoft's documentation states that the following four keys will execute programs upon user logon:


  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

Windows Services

While scheduled tasks are triggered by time, and registry keys can be triggered upon user login, services are a bit more malleable when it comes to triggers. Services are designed to operate in the background and are normally associated with routine backups or updates; however, they can be leveraged to execute malicious code and programs as well. When setting up services, certain properties can be set to true or false, such as:

  • CanStop

  • CanShutdown

  • CanPauseandContinue

  • CanHandlePowerEvent

  • AutoLog

How those properties are configured impacts the persistence of the service. For example, setting "CanStop" to false prevents the service from being stopped (easily at least). Additionally, the startup type can be configured as:

  • Automatic

  • Automatic (Delayed)

  • Manual

  • Disabled

One additional and majorly convenient feature that Windows services have is a recovery option in the event that the service fails to run. How-To Geek has a good write-up covering more details surrounding this, but taking a look at the image below, one can see that there are multiple contingency options available:

With each option is an additional opportunity for the persistence to do the threat actor's bidding.

Browser Extensions

Browser extensions serve the purpose of adding functionality to a user's experience on the internet. They can be ad blockers, note-taking add-ons, and even tools to help limit a user's time on social media. Like many other tools and features, they can also be leveraged for nefarious purposes. By masquerading malware as a legitimate browser extension, threat actors can steal information and download additional malicious code to the endpoint. Maxime Kjaer offers a phenomenal breakdown in his blog post, where he rips apart a chrome extension and takes a look at what its true purpose and functionality are. Browser extensions that are currently installed on a host can be found under the following registry key:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects


COM Hijacking

Component Object Model (COM) hijacking is when an adversary leverages inter-process communication (IPC) and code reuse to execute malicious code. COM objects were introduced by Microsoft to allow improved interoperability between software. It was originally created to enable communication between Microsoft Office apps. Processes communicate with COM objects, and these COM objects "mediate" the data handling and exchange between, hypothetically, a program written in C and something written in a .NET language. Additionally, COM objects are loaded dynamically as opposed to being hardcode "linked" to the client processes/programs. In order to access COM objects, processes reference registry keys that point them to legitimate pieces of code. In COM hijacking, the adversary hijacks that reference and has the registry key point to a malicious piece of code instead. When done effectively, the threat actor will hijack a COM reference that does not impact the functionality of the program and therefore allows the malicious code to execute undetected. Registry keys relevant to COM hijacking are:


  • HKEY_CURRENT_USER\Software\Classes\CLSID

  • HKEY_LOCAL_MACHINE\Software\Classes\CLSID

Conclusion


Malicious cyber actors can use one or more of the above referenced mechanisms to ensure that malware survives reboots and power outages. Several commercial tools are available to detect this kind of activity, and in large part it can be queried utilizing scripting. Utilizing tools from Microsoft Windows Sysinternals Suite as well as self-developed scripts can highlight the unwanted presence of these mechanisms.

Additional Reading

14 views0 comments
bottom of page