Monitoring commonly abused Windows utilities

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:
.\Sysmon.exe -accepteula -i .\sysmonconfig.xml
/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 the default
group:<agent_config os="windows"> <localfile> <location>Microsoft-Windows-Sysmon/Operational</location> <log_format>eventchannel</log_format> </localfile> </agent_config>
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.
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:
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:
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:
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:
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:
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.