Event Horizon: An Obfuscation Framework of Alien
Last Update:
Word Count:
Read Time:
Introduction
This article is part of the Inside Different Generations of WebShells series.
In the previous articles, I introduced the design philosophy behind OneShells, NebulaPulsar, and Alien. Together, the provide a flexible framework for post-exploitation across multiple scripting languages and platforms.
However, arbitrary code execution alone is not enough in real-world environments. Modern web application firewall (WAFs) and intrusion detection systems (IDSs) continue to improve, making static webshell traffic increasingly easy to detect.
This article introduces Event Horizon, the obfuscation framework used by Alien. Rather than implementing a fixed obfuscation algorithm, Event Horizon provides a pluggable architecture that allows users to customized how HTTP requests and responses are transformed.
Issues of Detection
Traditional OneShells are simple and effective. They allow arbitrary code execution through a single HTTP request and are widely used during penetration testing and post-exploitation.
Unfortunately, this simplicity also makes them easy to detect.
For example, a traditional PHP OneShell typically contains a loader similar to the followings:
1 | |
Although the payload itself is encoded, the loader remains static. From the defender’s perspective, deteting signatures such as eval(base64_decoded( is often sufficient to identify malicious traffic.
Moreover, the HTTP response is in plaintext, making the communication channel channel even more recognizable.
As we can see in the screenshot above, not only the keyword is very obvious, also the result of executing a cmd command is obvious as well.
Existing Solutions
In the past, some researchers introduced more complicated loaders to solve the problem.
For example:
1 | |
These techniques certainly increase the complexity of the payload.
However, they still rely on a static loader.
Once defenders learn how the loader is constructed, new signatures can be added to WAFs or IDSs, resulting in the same detection problem.
This naturally leads to a different philosophy:
Instead of making the loader more complicated, why ot make both the loader and the communication fully customizable?
This is the initial idea of EventHorizon. In truth, I removed all the features as possible as I can.
Event Horizon
Instead of embedding obfuscation logic directly into Alien, Event Horizon runs as a lightweight local server.
Whenever Alien is about to send an HTTP request, it forwards the payload to Event Horizon. Event Horizon then executes the selected tamper script, transforms the payload, and returns the obfuscated result back to Alien.
This design separates the client from the obfuscation logic, allowing new tamper scripts to be added without modifying Alien itself.
Bilateral Obfuscation
Request Obfuscation
One of the design goals of Event Horizon is to obfuscate the entire communication channel rather than only the loader. Therefore, every HTTP request is processed by the selected tamper script before it is sent to the target server.
The screenshot below shows an example using the XOR tamper script with the key secret:
As shown above, the original PHP payload is no longer visible in the HTTP request. Instead, the entire payload is encrypted using XOR and then encoded in Base64 before transmission. Consequently, traditional signatures such as eval(base64_decoded()) are no longer exposed on the network.
However, this imeediately introduces another problem.
If the HTTP request contains only encrypted data, how can the target OneShell recover and execute the original payload?
The solution is to generate a matching OneShell that contains the corresponding de-obfuscation routine. For example, when the XOR tamper script is selected, we can generates the following PHP OneShell:
1 | |
The generated OneShell first decodes the incoming Base64 data, decrypts it using the configured XOR key, and finally executes the recovered payload using eval().
At first glance, this approach may appear less flexible than a traditional OneShell because the de-obfuscation routine is embedded inside the backdoor. In practice, however, this is simply the trade-off required for traffic obfuscation. The generated OneShell can still be protected using existing PHP obfuscation techniques, making reverse engineering significantly more difficult.
To simplify development, Event Horizon also provides a backdoor builder integrated into Alien. Users only need to select a tamper script and its corresponding parameters, and Alien automatically generates a compatible OneShell.
Response Obfuscation
Obfuscating only HTTP requests is not sufficient.
Although the request payload is now encrypted, the HTTP response still exposes the execution result in plaintext. An observer can therefore still recover command output directly from the network traffic.
To address this issue, EventHorizon also supports response obfuscation through Wrapping Functions.
Whenever Alien generates a payload, it first queries the selected tamper script for a wrappign function. This wrapping function is then injected automatically into the generated payload before it is transmitted to the target.
For example, the following code demonstrates how Alien injects wrapping functions for PHP and VBScrip payloads:
1 | |
Instead of writing directly to the HTTP response, the payload first stores its output inside an internal buffer. Once execution finishes, the injected wrapping function encrypts the buffered data before sending it back to Alien.
As a result, both HTTP requests and HTTP responses are protected by the same tamper algorithm. The entire communication channel is therefore obfuscated, rather than only the initial payload.
The screenshot below shows the final network traffic captured using Wireshark:
As a result, recognizable payload signatures and plaintext outputs are no longer directly observable in captured HTTP traffic.
How to Write a Tampering Script
One of the design goals of Event Horizon is extensibility.
Adding a new tamper algorithm requires only a single Python module.
First, open the directory ./Tamper/obfuscators, and add a new tamper script XOR.py:
1 | |
Also, add the description and parameters JSON:
1 | |
Finally, don’t forget the obfuscator and payload template:
1 | |
Once the script is placed inside the ./Tamper/obfuscators directory, it automatically becomes available inside Alien.
Conclusion
This article introduced Event Horizon, the obfuscation framework used by Alien.
Unlike traditional OneShell clients that rely on static loaders, Event Horizon separates the obfuscation logic from the client itself. By treating obfuscation as a pluggable component, users can freely implement their own tamper algorithms without modifying Alien.
Another important feature of Event Horizon is bilateral obfuscation. Both HTTP requests and responses can be transformed automatically, allowing the communication channel to be customized according to different environments.
Although the current implementation focuses on OneShells, the framework itself is designed to be extensible. Additional scripting languages, obfuscation algorithms, and communication strategies can all be integrated in future versions.
Feedback and suggestions are always welcome!
THANKS FOR READING