Registry Persistence Detection — TryHackMe Walkthrough & Insights

Learn to use the AutoRuns PowerShell module to detect persistence mechanisms that use the Registry.

Room URL: https://tryhackme.com/r/room/registrypersistencedetection

Task 1 Intro

One crucial step that malware does upon successful execution on a target machine is to ensure that it can stay there even after a reboot or removal attempt. This is possible using various techniques, collectively called “malware persistence mechanisms”.

This room will give you an overview of these techniques and introduce a tool that can help detect them and aid in removal.

Learning Objectives

• Learn how malware persists in a machine
• Learn how malware uses the Registry as a persistence mechanism
• Learn how to use the AutoRuns PowerShell module to detect and remediate persistence mechanisms

Connecting to the Machine

We will use the Virtual Machine provided to complete the tasks in this room. You can start it in split-screen view by clicking on the green “Start Machine” button on the upper right section of this task. If the VM is not visible, use the blue “Show Split View” button at the top-right of the page. Alternatively, you can connect to the VM using the credentials below via “Remote Desktop”.

Username Administrator Password Passw0rd! IP MACHINE_IP

xfreerdp /v:<Win-server-IP> /u:<username> /p:<password> /gfx-h264 /cert-ignore

Answer the questions below

Read the above, start the machine, and log in.

Task 2 Intro to Malware Persistence Mechanisms

The term “malware persistence” can be defined as:

“Behaviors that enable malware to remain on a system regardless of system events, such as reboots.”

There are multiple ways malware can gain persistence. The technique/s used vary depending on the targeted operating system, ease of implementation, level of stealthiness, or, sometimes, based on the preference of the malware author. Examples of these techniques would be modifying an operating system’s boot sector, installing malicious configurations, or hijacking execution flow.

In Windows, the most common and easiest-to-implement technique is the abuse of Windows Registry Run keys.

The Windows Registry is a database of low-level operating systems and application settings. The Run keys are specific keys within the Registry that contain a path that runs every time a user logs on, and they are listed below:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run — Run path when the current user logs in
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run — Run path when any user logs in
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce — Run path when the current user logs in, then delete
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce — Run path when any user logs in, then delete

To view these keys, open the Registry Editor by searching for “Regedit” on Windows Search or double-clicking on the Regedit icon pinned on the Windows taskbar.

This is what the Registry Editor window looks like:

If you want to view the value for one of the Run keys, expand the folders and their subfolders until you reach the key you are looking for. For example:

• HKEY_LOCAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > Run

Answer the questions below

2.1 What is the value “Name” of the suspicious registry entry that runs during startup? Include the parenthesis.

Open the Registry Editor (Regedit) at Computer\HKEY_LOCAL_MACHINE\

Navigate deeper into the following path: HKEY_LOCAL_MACHINE\Software\Microsoft\

\Windows\CurrentVersion\

\Run

The suspicious registry entry is found at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

This location is commonly used by malware to ensure it runs every time Windows starts.

There are two entries:
1. (Default) — This is pointing to a suspicious file:

C:\Users\Administrator\AppData\Local\bd84l24d9…

This is not normal behavior, as “(Default)” usually contains no data.

2. SecurityHealth — This points to:

%windir%\system32\SecurityHealthSystray.exe

Check What This File Does

Open file location to check where it is stored.

The batch file (24d9.bat) is running, displaying the message:

pleaseletmepersist
Press any key to continue . . .

This suggests that the batch script is trying to stay active on the system.

Why is this important?
“pleaseletmepersist” is not a normal system message.
The message indicates this script is designed for persistence, meaning it wants to stay on the system after reboots.

What Does This Mean?

The system has a persistence mechanism set up via the Registry Run key.
A batch script (24d9.bat) is automatically executed on startup.
The script likely performs malicious or unwanted actions, such as:
* Reinstalling itself if removed.
* Executing other malware.
* Modifying system settings.

Answer: (Default)

2.2 What is the value “Data” of the suspicious registry entry that runs during startup?

Answer: C:\Users\Administrator\AppData\Local\bd84\24d9.bat

2.3 What string is displayed on the console when the suspicious file runs?

Answer: pleaseletmepersist

Task 3 Intro to the AutoRuns PowerShell Module

As you’ve seen in the previous task, it is possible to detect the existence of persistence mechanisms in the Registry by manually checking keys. However, other registry keys can be used to establish persistence, and they are not as obvious, making them harder to find. Fortunately, some tools can help us with this problem.

A widely-used tool from Microsoft called AutoRuns checks all possible locations where a program can automatically run on start-up or when a user logs in. This tool does what we need, but it is not the one we’ll be using for this room (If you still want to check it out, try the SysInternals room).

For this room, we’ll use the AutoRuns PowerShell module. It does the same thing as the original AutoRuns tool. Still, it allows us to leverage the benefits of PowerShell scripting and has a baseline feature for comparing current snapshots to previous ones. You’ll see why these features are essential later on.

The Windows machine already has the AutoRuns PowerShell module installed. To use it, open PowerShell in Administrator mode by clicking on the PowerShell icon on the Windows Taskbar at the bottom of the screen. Once the PowerShell window appears, type the following to view the available commands:

Administrator: Windows PowerShell

PS C:\> Get-Command -Module AutoRuns
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Compare-AutoRunsBaseLine                           14.0       AutoRuns
Function        Get-PSAutorun                                      14.0       AutoRuns
Function        New-AutoRunsBaseLine                               14.0       AutoRuns

To learn more about each AutoRuns command, we can use the Get-help cmdlet along with each AutoRun command name as shown below:

Administrator: Windows PowerShell

PS C:\> Get-Help CHANGETHIS

You can also check out the tool’s ReadMe page for more information.

Answer the questions below

3.1 What AutoRun function is used for getting and displaying the auto-run entries? (Question Hint Use the Get-Help cmdlet with the Autorun commands to answer the question)

Lists all available AutoRuns functions:

Get-Command -Module AutoRun

The AutoRuns PowerShell module is installed and contains three functions:

The AutoRuns PowerShell module is installed and contains three functions:

1. Compare-AutoRunsBaseLine

• Compares two baseline snapshots to identify changes in auto-run entries.
• This is useful for detecting new persistence mechanisms added by malware.

2. Get-PSAutorun

• Retrieves and displays all auto-run entries currently set on the system.
• Helps security analysts identify suspicious programs running at startup.

3. New-AutoRunsBaseLine

• Creates a baseline snapshot of the system's auto-run entries.
• This snapshot can be used later to compare changes and detect anomalies.

Use the Get-Help Get-PSAutorun

Get-Help Get-PSAutorun 

The Get-PSAutorun function in PowerShell retrieves a list of all programs configured to start automatically at system boot or user logon.

It checks multiple locations, including:

• Registry keys
• Windows services & drivers
• Scheduled tasks
• WMI persistence
• DLL hijacking & logon scripts
• Example 1: Get a Detailed Explanation of the Command:
  Get-Help Get-PSAutorun -detailed

What this does:

This provides a more in-depth description of what `Get-PSAutorun` does, including available parameters and usage notes.

• Example 2: Get the Full Technical Documentation:
  Get-Help Get-PSAutorun -full

What this does:

This displays the complete technical documentation, including:
- Syntax
- All parameters
- Examples
- Return values

Answer: Get-PSAutorun

3.2 What AutoRun function is used for creating a baseline file from Autoruns artifact(s)? (Question Hint Use the Get-Help cmdlet with the Autorun commands to answer the question)

Use the Get-Help New-AutoRunsBaseLine

Get-Help New-AutoRunsBaseLine

The New-AutoRunsBaseLine function in PowerShell is used to create a baseline file from Autoruns artifacts. This baseline file can be used later for comparison to detect changes in startup entries.

• Example 1: Create a Baseline and Save It as a JSON File
  New-AutoRunsBaseLine -FilePath C:\Baseline.json
  
  What this does:
  - Captures the current list of auto-run programs.
  - Saves them to a file C:\Baseline.json.
  - This file can later be compared with a new scan.
• Example 2: Create a Baseline with Confirmation Prompt
  New-AutoRunsBaseLine -FilePath C:\Baseline.json -Confirm
  
  What this does:
  Before saving, it asks for confirmation to proceed.
• Example 3: Simulate Creating a Baseline (Without Running It)
  New-AutoRunsBaseLine -FilePath C:\Baseline.json -WhatIf

What this does:
Shows what would happen if the command runs, but does not execute it.

The baseline snapshot helps detect new persistence mechanisms added by malware.
By saving a baseline before and after a suspected infection, you can track unauthorized changes.
It is useful for SOC analysts, forensic investigators, and IT admins.

Answer: New-AutoRunsBaseLine

3.3 What AutoRun function is used for comparing two baseline files of Autoruns artifact(s)? (Question Hint Use the Get-Help cmdlet with the Autorun commands to answer the question)

Use the Get-Help Compare-AutoRunsBaseLine

Get-Help Compare-AutoRunsBaseLine

The function Compare-AutoRunsBaseLine is used to compare two baseline snapshots.
This is useful for detecting changes, such as new persistence entries added by malware.

• Example 1: Compare Two Baseline Files

Compare-AutoRunsBaseLine -ReferenceBaseLineFile C:\Baseline1.json -DifferenceBaseLineFile C:\Baseline2.json

What this does:

Compares Baseline1.json (first snapshot) with Baseline2.json (new snapshot).
Output: Shows new entries, removed entries, or modified entries in auto-runs.

• Example 2: Detect Suspicious Changes in Persistence Mechanisms

Compare-AutoRunsBaseLine -ReferenceBaseLineFile C:\SafeBaseline.json -DifferenceBaseLineFile C:\CurrentSnapshot.json

What this does:

SafeBaseline.json contains a clean snapshot of the system (before infection).
CurrentSnapshot.json contains a new scan after suspicious activity.
Output: Shows new auto-run entries that may be malware.

• Example 3: Check AutoRuns Changes on a Remote System

Compare-AutoRunsBaseLine -ReferenceBaseLineFile \\RemotePC\C$\Baseline.json -DifferenceBaseLineFile \\RemotePC\C$\NewScan.json

What this does:

Runs the comparison on a remote computer.
Useful for detecting persistence mechanisms in enterprise environments.

Answer: Compare-AutoRunsBaseLine

Task 4 Filtering AutoRuns Entries

AutoRuns PowerShell has a function called Get-PSAutorun that will list all possible auto-start mechanisms available on the machine. It makes this list by looking at categories like the Registry, Windows services, WMI entries, DLL hijacking, and more. Because of this, the output of the command will return many results that might be challenging if not adequately filtered.

Administrator: Windows PowerShell

PS C:\> Get-PSAutorun

Path          : HKLM:\System\CurrentControlSet\Control\Session Manager
Item          : BootExecute
Category      : Boot Execute
Value         : autocheck autochk *
ImagePath     : C:\Windows\system32\autochk.exe
Size          : 956416
LastWriteTime : 11/6/2022 4:24:46 AM
Version       : 10.0.17763.1697
Path          : HKLM:\SOFTWARE\\Microsoft\Windows\CurrentVersion\Explorer\ShellServiceObjects
Item          : {003e0278-eca8-4bb8-a256-3689ca1c2600}
Category      : Explorer
Value         : C:\Windows\system32\shell32.dll
ImagePath     : C:\Windows\system32\shell32.dll
Size          : 22153696
LastWriteTime : 11/6/2022 4:25:16 AM
Version       : 10.0.17763.1911
Path          : HKLM:\SOFTWARE\\Microsoft\Windows\CurrentVersion\Explorer\ShellServiceObjects
Item          : {3BF043EF-A974-49B3-8322-B853CF1E5EC5}
Category      : Explorer
Value         : C:\Windows\System32\SndVolSSO.dll
ImagePath     : C:\Windows\System32\SndVolSSO.dll
Size          : 823808
LastWriteTime : 11/6/2022 4:25:22 AM
Version       : 10.0.17763.652
...

Piping the result of the command above to the Out-GridView cmdlet can make the output more readable.

Administrator: Windows PowerShell

PS C:\> Get-PSAutorun | Out-GridView

The above command will open a new window showing the following output:

Note: Wait for a couple of minutes for the tool to finish populating the results

The results above list all possible places a program can run on start-up. You can filter the results by specifying keywords in the “Filter” bar at the top of the window. You can also sort the results by clicking on the column headers.

We can specify parameter switches when calling the function to filter the result according to the previously mentioned categories. Open a new PowerShell window, and use the Get-Help command to list the available parameters.

Administrator: Windows PowerShell

PS C:\> Get-Help Get-PSAutorun -detailed

Answer the questions below

4.1 What parameter switch is used for filtering for artifacts related to boot execution of images?

See all available filtering options

Get-Help Get-PSAutorun -detailed

BootExecute will only show entries related to Boot Execution.

It lists boot execution artifacts (runs before user logon).

Answer: BootExecute

4.2 How many entries are outputted using the parameter switch from the previous question?

Get-PSAutorun -BootExecute

To make it more easy Pip the result of the command Get-PSAutorun to the Out-GridView cmdlet can make the output more readable.

Get-PSAutorun | Out-GridView

Filter results by typing in the filter bar

Answer: 1

4.3 What parameter switch is used for filtering for artifacts related to printer driver and status monitors?

Answer: PrintMonitorDLLs

4.4 How many entries are listed in the output using the parameter switch from the previous question?

Filter results by typing in the filter bar

Get-PSAutorun -PrintMonitorDLLs | Out-GridView

Answer: 5

4.5 What parameter is used to add a new column to show whether a file is digitally signed?

When using the -VerifyDigitalSignature switch, a new column called “Signed” appears in the output.
This column tells us if the file is digitally signed (“True” or “False”).

Answer: VerifyDigitalSignature

4.6 Searching all categories, how many entries have the “Signed” column set to “false”? (Question Hint Specify the “VerifyDigitalSignature” parameter when calling Get-PSAutorun to get the “Signed” column.)

Use Out-GridView and manually filter by setting “Signed” to False.

Get-PSAutorun -VerifyDigitalSignature | Out-GridView

Answer: 3

4.7 Try to answer the previous question with just Powershell and without using Out-GridView.

(Get-PSAutorun -VerifyDigitalSignature | Where-Object {$_.Signed -eq $false}).Count

• Get-PSAutorun -VerifyDigitalSignature > Retrieves all auto-run entries and adds the “Signed” column.
• Where-Object {$_.Signed -eq $false} > Filters out entries where “Signed” is False (unsigned files).
• .Count > Counts the number of unsigned entries.

or

Get-PSAutorun -VerifyDigitalSignature | Where-Object { $_.Signed -eq $false } | New-AutoRunsBaseLine -Verbose

Answer: No Answer Needed

Task 5 Comparing to a Baseline

While filtering via parameter switches helps reduce the output, there is still a lot to go through. This is where the baseline creation and comparison feature of the AutoRuns PowerShell module is helpful, as only the entries that differ from the baseline are shown in the results.

After creating this room’s machine, a baseline file was generated and saved in the ~/Documents folder. This file serves as a snapshot of the Registry before the malware ran.

To check what Registry keys were changed, a new baseline file needs to be created using the New-AutoRunsBaseLine function.

Administrator: Windows PowerShell

PS C:\> Get-PSAutorun -VerifyDigitalSignature |
>> Where { -not($_.isOSbinary)} |
>> New-AutoRunsBaseLine -Verbose

Note: Generating a new baseline file using the code above will take a few minutes. So please be patient.

When done, the new baseline file is added to the ~/Documents folder.

The two baseline files can now be compared using the following command:

Administrator: Windows PowerShell

PS C:\> Compare-AutoRunsBaseLine -Verbose | Out-GridView

Note: Make sure there are always two baseline files in the ~/Documents folder when comparing. Delete the other files you do not need to avoid confusion.

Answer the questions below

5.1 There is another suspicious logon Registry entry. What is the full path of this key?

Create a New Baseline

A baseline is like taking a “before” picture of your system. It records all programs and files that automatically start when Windows boots.

Get-PSAutorun -VerifyDigitalSignature | Where-Object { -not($_.isOSbinary)} | New-AutoRunsBaseLine -Verbose

• Get-PSAutorun -VerifyDigitalSignature .> Collects all Auto-Start entries (programs that start automatically).
  Where-Object { -not($_.isOSbinary)} > Removes safe system files from the list.
  New-AutoRunsBaseLine -Verbose > Creates a snapshot (Baseline) of all auto-run items and saves it in ~/Documents.

Wait a few minutes until it finishes.

Compare Before & After

Compare-AutoRunsBaseLine -Verbose | Out-GridView

Compare-AutoRunsBaseLine -Verbose .> Compares the two snapshots (before & after malware ran).
| Out-GridView > Opens a graphical table where you can see changes easily.

Two new/modified registry keys that were added after the malware ran.

Both registry keys are suspicious because they were not in the system before but appeared after the malware ran. However, the Winlogon key is more critical in this case.

1- HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon (First One)

This key controls how Windows logs in.
The “Userinit” value inside this key decides which programs run at login.
If malware modifies this key, it can fully take control of the login process.
Very dangerous because malware can use it to:
* Create backdoors (so hackers can log in remotely).
* Prevent users from logging in properly.
* Run itself every time the user logs in.

Winlogon controls the login process itself, making it more powerful for malware.

This key is more serious for persistence.

2- HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (Second One)

This key is used to run programs automatically when Windows starts.
It is commonly used for legitimate applications (like antivirus software, drivers, or background apps).
Malware also uses it, but it is easier to detect and remove.

While this key is suspicious, it is less critical than Winlogon because:

Malware in Run can be stopped more easily.
It doesn’t control login like Winlogon does.

Answer: HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

5.2 What is the value item name of the suspicious Registry entry from question #1?

Now, we need to check the “Item” column in the Out-GridView window for Winlogon, what is the Value Item Name?

“Userinit” is a value inside the Winlogon registry key.
It tells Windows which programs to run when a user logs in.
Normally, it should point to Windows system files.

Why is it Suspicious?

Malware often modifies “Userinit” to run itself when Windows starts.
This allows the malware to stay active even after a restart.
If the value contains a non-standard program, it could mean malware is running at login.

Note: Normally, “Userinit” should be:

C:\Windows\system32\userinit.exe,

Answer: Userinit

5.3 What is the value data of the suspicious Registry entry from question #1?

Now, we need to check the “Value Data” column in the Out-GridView window.

This shows what program is set to run when a user logs in.

Note: The normal value should be only this:

C:\Windows\system32\userinit.exe,

This is the correct system process that runs after login.

But in this case, there is an extra file added:

C:\Users\Administrator\AppData\Local\THM\789a.bat

This means a batch script (.bat file) is running at login, which is not normal.

Why is this dangerous?

The batch file (789a.bat) is likely malware!
It runs every time the user logs in, allowing the malware to stay active.
Since it’s inside AppData\Local\THM, it’s likely a hidden persistence mechanism.

Answer: C:\Windows\system32\userinit.exe, C:\Users\Administrator\AppData\Local\THM\789a.bat

5.4 What is the category that AutoRuns assigned to the entry from question #1?

Now, we need to check the “Category” column in your Out-GridView window.

AutoRuns assigns “Logon” to processes that start automatically when a user logs in.
The Winlogon\Userinit key is specifically designed to run important system files during user login.
Since the malware modified Userinit, AutoRuns detects it as a Logon persistence method.
This means the malware is using a login script to execute itself every time the user start Windows.

Answer: Logon

5.5 What string is displayed on the console when the suspicious file ran?

Now manually execute the batch file in PowerShell (reads the contents of the batch file), look for any echo commands or suspicious actions.

Get-Content C:\Users\Administrator\AppData\Local\THM\789a.bat

The outpote of the batch file contains an echo command, which means it prints a message to the screen when executed.
The message “letmestaymyfriend” could be:
* A signature or marker left by the malware author.
* An indication that the malware is trying to persist and “stay” on the system.
* A message meant to mislead the analyst.

The pause command in the script means the message stays on the screen until the user presses a key.

Answer: letmestaymyfriend

Note: If this was a real incident, the next steps would be

1- Checking if the malware is still running

Get-Process -Name 789a

2- Deleting the malicious batch file

Remove-Item -Path "C:\Users\Administrator\AppData\Local\THM\789a.bat" -Force

3- Fixing the registry to remove persistence

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Userinit" -Value "C:\Windows\system32\userinit.exe,"

4- Checking for any other suspicious auto-start entries

Get-PSAutorun | Where-Object { -not($_.isOSbinary)}

Task 6 Conclusion

We can now take the necessary steps to remove the malicious registry keys and files we found. In this case, it is as easy as deleting or modifying the entries via “RegEdit” and ensuring they are gone after a reboot.

Hopefully, this room has given you an idea of how malware uses the Windows Registry to maintain persistence on a target machine. While there are other techniques that malware uses, the same tool can be used in detecting most of them.

Answer the questions below

Congratulations! You have cleaned your machine of persistence mechanisms… for now.

Useful Resources for Registry Persistence Detection

• Autoruns: https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns
• AutoRuns PowerShell Module: https://github.com/p0w3rsh3ll/AutoRuns
• Out-GridView: https://github.com/p0w3rsh3ll/AutoRuns

Final Thought

This room helps in understanding how malware persists on a Windows system by modifying the Registry. It also demonstrates how to use the AutoRuns PowerShell module to detect and remove suspicious entries that allow malware to run at startup.

By comparing baseline snapshots, we can identify system changes and uncover hidden persistence mechanisms. Using PowerShell, we can analyze auto-run entries, filter out system files, and locate suspicious registry modifications.

This process is valuable for malware analysis, threat hunting, and incident response. By applying these techniques, we can detect and remove persistence threats more effectively.

This hands-on experience greatly improves the ability to investigate and secure a Windows system against malware.

Security is a journey, not a destination! Stay safe, stay secure, and keep defending.