It is commonly known that malware abuses native Windows utilities to achieve the attacker’s nefarious goals. For example, a native utility like Vssadmin can be abused by ransomware to inhibit system recovery (T1490) of a Windows endpoint.
This blog post covers how Wazuh can be used to detect when some native Windows utilities are executed on an endpoint. We will attempt to detect when Nltest, BCDedit, Vssadmin, Attrib, and Schtasks are executed in the Windows Command Prompt(cmd). While the execution of these tools is not malicious by default and does not necessarily mean there is an ongoing attack. They are worth monitoring for the following reasons:
- For forensic analysis and for gaining better insights into the events happening on the monitored endpoints.
- To detect abuse by malicious actors.
Requirements
- An installed Wazuh manager (version 4.3.3).
- An enrolled Wazuh agent running on a Windows 10 endpoint.
- Sysmon installed on the endpoint.
Setup Sysmon and log collection
- On the endpoint, download Sysmon from the Microsoft Sysinternals page.
- Next, download this Sysmon XML configuration file.
- Install Sysmon with this configuration via Command Prompt(Administrator user):
.\Sysmon.exe -accepteula -i .\sysmonconfig.xml
- On the Wazuh manager, edit the shared configuration file at
/var/ossec/etc/shared/default/agent.conf
file. This specifies the location to collect Sysmon logs which are sent from the agent to the manager. This will apply to all agents in thedefault
group:
<agent_config os="windows"> <localfile> <location>Microsoft-Windows-Sysmon/Operational</location> <log_format>eventchannel</log_format> </localfile> </agent_config>
Detection with Wazuh
This section explains how we create detection rules that will generate alerts when any of these utilities (Nltest, BCDedit, Vssadmin, Attrib, and Schtasks) are executed on a Windows endpoint. In this case, we look at the inputs in the command line and not the result of the execution. Detection rules are added to the /var/ossec/etc/rules/local_rules.xml
file on the Wazuh manager. Make sure to restart the Wazuh manager after applying these rules.
Note
Some of these commands are destructive. If you want to test them, run on a test VM.
- Nltest: This is a Windows command-line utility used in Active Directory environments to list domain controllers and enumerate domain trusts. The associated MITRE techniques are Domain Trust Discovery [T1482], Remote System Discovery [T1018], and System Network Configuration Discovery [T1016].
Rules have been created to detect the following executions in the Command Prompt:
nltest /domain_trusts nltest /domain_trusts /all_trusts nltest /dclist:"[DOMAIN]" nltest /parentdomain
Rules:
<group name="nltest"> <rule id="100601" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)nltest\s+\/domain_trusts</field> <description>Network Location Test enumerating active directory.</description> <mitre> <id>T1482</id> </mitre> </rule> <rule id="100602" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)nltest\s+\/dclist|nltest\s+\/dsgetdc</field> <description>Network Location Test enumerating remote domain controllers.</description> <mitre> <id>T1018</id> </mitre> </rule> <rule id="100603" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)nltest\s+\/parentdomain</field> <description>Network Location Test enumerating parent domain of a local machine.</description> <mitre> <id>T1016</id> </mitre> </rule> </group>
Below shows screenshots of alerts displayed on the Wazuh dashboard when Nltest commands are executed:
- BCDEdit: This is used for editing the boot configuration of Windows systems. Microsoft points out that BCDEdit execution can be a sign of ransomware activity. It can be used to “Turn off warnings and automatic repairs after boot failures that can be caused by the encryption process”. Rules have been created to detect when BCDEdit does the following:
- Set an entry option value.
- Delete an element from an entry.
- Import a file to restore the state of the system store.
The associated MITRE technique is Inhibit System Recovery [T1490].
We tested the rules with these commands in the Command Prompt:
bcdedit /set {default} recoveryenabled No bcdedit /set {default} bootstatuspolicy ignoreallfailures bcdedit /f /delete {bootmgr} bcdedit.exe /import "C:\Users\redacted\redacted.txt" /clean
Rules:
<group name="bcdedit"> <rule id="100621" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)BCDEdit\s+/set|BCDEdit.exe\s+/set</field> <description>BCDEdit set an entry option.</description> <mitre> <id>T1490</id> </mitre> </rule> <rule id="100622" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)BCDEdit\s+/f\s+/delete|BCDEdit\s+/delete|BCDEdit.exe\s+/f\s+/delete|BCDEdit.exe\s+/delete</field> <description>BCDEdit deleted an element from a specified entry.</description> <mitre> <id>T1490</id> </mitre> </rule> <rule id="100623" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)BCDEdit.exe\s+/import|BCDEdit\s+/import</field> <description>BCDEdit imported a file to restore the state of the system store.</description> <mitre> <id>T1490</id> </mitre> </rule> </group>
Below shows screenshots of alerts displayed on the Wazuh dashboard when BCDEdit commands are executed:
- Vssadmin: This is used to manage volume shadow copy backups. Rules have been created to detect deleting and resizing of shadow copies. The associated MITRE technique is Inhibit System Recovery T1490.
We tested the rules with these commands in the Command Prompt:
vssadmin delete shadows /For=C: /Oldest vssadmin delete shadows /all vssadmin delete shadows /all /quiet vssadmin resize shadowstorage
Rules:
<group name="vssadmin"> <rule id="100631" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)VSSADMIN\s+delete\s+shadows|VSSADMIN.exe\s+delete\s+shadows</field> <description>vssadmin deleted shadow copies.</description> <mitre> <id>T1490</id> </mitre> </rule> <rule id="100632" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)VSSADMIN\s+resize\s+shadowstorage|VSSADMIN.exe\s+resize\s+shadowstorage</field> <description>vssadmin resized a shadow copy storage.</description> <mitre> <id>T1490</id> </mitre> </rule> </group>
Below shows screenshots of alerts displayed on the Wazuh dashboard when Vssadmin commands are executed:
- Attrib: This is used to remove and set file attributes (hidden, read-only, system, and archive). Attackers use this to hide malicious files and folders anywhere on the system. The associated MITRE technique is Hide Artifacts: Hidden Files and Directories [T1564.001].
We tested the rules created in the Command Prompt:
attrib +h [File/Folder] attrib +s +h [File/Folder]
Rules:
<group name="attrib"> <rule id="100641" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)ATTRIB\s+\+h|ATTRIB.EXE\s+\+h|ATTRIB\s+\+s\s+\+h|ATTRIB.exe\s+\+s\s+\+h</field> <description>attrib was used to hide files or directories. Current directory: $(win.eventdata.currentDirectory).</description> <mitre> <id>T1564.001</id> </mitre> </rule> </group>
Below shows screenshots of alerts displayed on the Wazuh dashboard when Attrib commands are executed:
- Schtasks: This allows system administrators to manage scheduled tasks. Schtasks can create, delete, run, and end scheduled tasks on a local or remote computer. Attackers have been known to exploit this utility to schedule malicious tasks. Rules have been written to detect when schtasks does the following:
- Create a new task.
- Create a new task using an XML file.
- Delete a scheduled task.
The associated MITRE technique is Scheduled Task/Job: Scheduled Task [T1053.005].
We tested the rules with these commands in the Command Prompt:
schtasks /create /tn test-task /tr "C:\Windows\System32\calc.exe" /sc onlogon /ru System /f schtasks.exe /CREATE /XML C:\Windows\TEMP\redacted.xml /TN task-task /F schtasks.exe /CREATE /XML C:\redacted\redacted.xml /TN task-task /F SCHTASKS /Delete /TN * /F
Rules:
<group name="schtasks"> <rule id="100651" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)SCHTASKS\s+/CREATE|SCHTASKS.EXE\s+/CREATE</field> <description>schtasks attempted to create a new task: $(win.eventdata.commandLine).</description> <mitre> <id>T1053.005</id> </mitre> </rule> <rule id="100652" level="7"> <if_sid>100651</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)\/XML\s.+.XML</field> <description>schtasks created a new task using an XML file: $(win.eventdata.commandLine).</description> <mitre> <id>T1053.005</id> </mitre> </rule> <rule id="100653" level="7"> <if_sid>61603</if_sid> <field name="win.eventdata.commandLine" type="pcre2">(?i)SCHTASKS\s+/Delete|SCHTASKS.EXE\s+/Delete</field> <description>schtasks attempted to delete a scheduled task: $(win.eventdata.commandLine).</description> <mitre> <id>T1053.005</id> </mitre> </rule> </group>
Below shows screenshots of alerts displayed on the Wazuh dashboard when Schtasks commands are executed:
Conclusion
This blog post examines utilities commonly abused by malwares and their detection with Wazuh. As mentioned earlier their execution doesn’t necessarily mean there is an ongoing attack. Applying these detection rules will help system administrators have more visibility and insights into the events happening on each endpoint in a network.