We'll quickly discuss its importance in system management and security, then dive into a case study revealing sneaky persistence mechanisms embedded within these tasks. We will detail how the core topic of detection plays a crucial role, with a particular focus on utilizing Windows Event Logs (WEL) and Sysmon logs to identify and track suspicious activities orchestrated through Scheduled Tasks.
Introduction to Windows Scheduled Tasks
Windows Scheduled Tasks is a powerful tool integrated into Microsoft operating systems, designed to automate tasks that need to run at specific times or under certain conditions. Microsoft defines Scheduled Tasks as a service that "enables you to configure and schedule automated tasks on your machine" (Microsoft Documentation). While incredibly useful for streamlining administrative and maintenance duties, this utility is not without its vulnerabilities.
Why Persistence Matters? The Role of Scheduled Tasks to Threat Actors and Malware Authors
Threat actors and malware authors use persistence to maintain access to compromised systems, ensuring their malicious activities continue undetected over time. Scheduled Tasks are a favored tool for this because they can effectively execute malware at regular intervals, even after system restarts. This technique is discreet, blending into legitimate automation activities, which makes it an effective method for evading detection and maintaining long-term access to a target system.
Case Study: Detecting Sneaky Persistence in Windows Scheduled Tasks Using Windows Event Logs and Sysmon
To perform this technique, a user must obtain SYSTEM level privileges on the compromised machine. This can be achieved through various privilege escalation TTPs, such as User Impersonation, Credential Theft, and Service Manipulation.
Scheduled Task in Windows Registry
Before we dive-in into the POC and detection let’s understand where to find it in the registry.
In Windows, all scheduled task are registered in these keys:
- “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Tasks”
- “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache”
We will tackle these keys as we progress with the topic.
Tracking Registry Events using Windows Event and Sysmon Logs
In this demonstration, we will add two different entries to our scheduled task, leveraging the elevated privileges we have obtained on the machine. We have named these entries:
- Skype
- Google Updater
We will use 'Skype' for native Windows Event Logs (WEL) and 'Google Updater' for Sysmon logs. To interact with the Windows Registry, we will utilize the following native Windows commands which will be executed in our remote C2 environment:
- REG ADD
- REG QUERY
- REG DELETE
Adding Scheduled Task: Windows Event Logs(WEL)
Here, we have successfully added the “Skype” task.
Let’s discuss these subkeys.
- ID = UUID (used for identifying the task)
- Index = 1(Boot), 2(Logon), 3(Pain), 4(Maintenance)
- SD = Security Descriptor(permission of the task and responsible for deciding who are allowed to see this task)
Looking at the native Windows Event Logs it generates these pattern.
- 4702 - a scheduled task was updated
- 4690 - attempt was made to duplicate a handle to an object
- 4673 - a privilege service was called
- 4658, 4656, 4663 - Registry related event IDs.
Adding Scheduled Task: Sysmon Logs
In the Windows Event Logs, we observed that the addition of actions generates only a series of patterns, making it unclear what specific actions the threat actor performed. To gain a comprehensive understanding, analysts need to conduct multi-data source analysis.
The Sysmon logs have been incredibly useful for elucidating the system's activities. When a Scheduled Task is added, Sysmon generates the Event ID 1 (Process Create), which includes details such as the “OriginalFileName(Image)” and “User".
Then, Sysmon generates event ID 11(File Created) which has the “TargetFileName” which is the full path to our added Scheduled Task.
Listing Scheduled Task using REG QUERY: Windows Event Logs vs Sysmon Logs
In Windows, 'REG QUERY' is a popular command line tool used to list a registry key. We will employ this query to determine the event IDs it will generate.. So here’s our findings:
Windows Event Logs does not provide a clear definition of what was happening just a series of logs.
Again, Sysmon save it! It has the following:
- Image(reg.exe)
- CommandLine(command executed “REG QUERY”)
- User(SYSTEM)
Sneaky Scheduled Task: Dropping Stealthy Persistence
When a task is added it creates these subkeys:
- ID = UUID (used for identifying the task)
- Index = 1(Boot), 2(Logon), 3(Pain), 4(Maintenance)
- SD = Security Descriptor(permission of the task and responsible for deciding who are allowed to see this task)
Remember, we required SYSTEM privileges on the compromised machine to interact with the Security Descriptor (SD) value of the Scheduled Task (Google Updater). Why is this necessary? By default, Windows restricts all normal users and administrators from deleting it—only users with SYSTEM privileges have this capability.
The logic behind this is that deleting the 'Security Descriptor' “SD” subkey from the 'Scheduled Task' removes its entries, effectively making the task invisible to all users.
Let’s see this in action by executing ‘REG DELETE’ command.
Here, we have successfully deleted this subkey with a SYSTEM type privilege.
Sysmon generates the following:
- Event ID 1(Process Create) = reg.exe
- CommandLine = REG DELETE “/v” value “/f” force
- User = NT AUTHORITY\SYSTEM
In the Task Scheduler window, our task appears completely hidden, yet it remains visible in the registry. Let’s retrieve the 'Id' data and navigate to 'TaskCache\Tasks', which contains and organizes all tasks registered in the system.
Here, we see the details of our newly added scheduled task, now completely hidden. The 'Actions' section specifies the commands to be executed when the task is triggered, such as '-enc <command>'.
When we listed the scheduled task using Command Prompt, as expected, it returned no results.
Detection: ELK and Splunk Query Sysmon ID 1(Process Create)
The filter used in the following example will vary depending on the maturity of your organization's threat hunting capabilities, as it differs from and makes use of a data dictionary that indicates all fields within your SIEM.
What is Data Dictionaries? It create a uniform way to categorize and label data, efficiently for conducting threat hunting activities. It links data sources to the analytics used in your organization. By implementing a standard data dictionary, the team can gain increased visibility for detecting adversaries in the environment, irrespective of their originating OS. These dictionaries contain detailed information on various security events, represented by event logs, with the aim of establishing standardized terminology for data from different sources.
Here is a sample ELK and Splunk query to monitor instances of “reg.exe” in your environment.
Note: The “user” thing is optional.
REG_QUERY_DELETE_SYSMON_LOGS
For ELK:
user.name : "user" AND data_stream.dataset : "windows.sysmon_operational" AND winlog.event_id : 1 AND process.name : "reg.exe"
For Splunk:
user.name="user" data_stream.dataset="windows.sysmon_operational" winlog.event_id=1 process.name="reg.exe"
Summary
Threat actors used both old and new ways to persist in order to access compromised systems continuously. The creativity behind these tactics, both new and established, and the challenges they pose to defenders. Emphasizing the importance of understanding and adapting to these tactics, techniques, and procedures (TTPs) also, discussed about the roles of Windows Event Logs (WEL) and Sysmon logs in identifying threat actions. We learned how these logs differ in generating data and which are more valuable for detecting malicious activities. This blog emphasize the necessity of leveraging multiple data sources for analysis to avoid relying solely on one type of evidence, ensuring a more comprehensive and reliable investigative outcome.
If you found this topic interesting and you don’t have any exposure to Malware Analysis, Reverse Engineering, Digital Forensics and Incident Response, why not take a look at our gamified blue team lab platform.
About Security Blue Team
Security Blue Team is a leading online defensive cybersecurity training provider with over 100,000 students worldwide, and training security teams across governments, military units, law enforcement agencies, managed security providers, and many more industries.