ShellWasp is a new tool to faciliate creating shellcode utilizing syscalls, released at DEF CON 30 on August 12, 2022. It was also at Black Hat Middle East and Africa in November, 2022! On April 19, 2023, ShellWasp 2.0 ws released with massive updates, including alternative ways to get OSBuild (via User_Shared_Data, PEB via r12), and three new ways to invoke the syscall via WoW64 (one for Win7 and two for Win10/11).
NEW: Please refer to this HITB Amsterdam 2023 page for further details, including full-length, hour long video, to learn more about this project: https://conference.hitb.org/hitbsecconf2023ams/session/windows-syscalls-in-shellcode-advanced-techniques-for-malicious-functionality/ Slides are available for download at HITB. SThis project has evolved tremendously since its initial debut at DEFCON 30. hellWasp is a way to help perform syscalls in WoW64 shellcode, and the latest version features multiple, novel methods of invoking the syscall in a WoW64 environment, as detailed in the HITB Amsterstam 2023 talk. If you are building complex syscall shellcode with multiple syscalls being used (not for the faint-hearted), and you want to make sure there is no common way of invoking it, such as fs:0xc0, then these new additions may be of interest. Though for simplicity's sake, I recommend beginning with the "simpler" way of invoking it, via fs:0xc0.
ShellWasp automates building templates of syscall shellcode. The template is intended to be just that - a template. The user still must determine what parameter values to use and how to generate them. The intent is to simplify the process for those desiging to create syscall shellcode by hand. Nearly all user-mode syscalls supported, including all the ones I could find function prototypes for. ShellWasp also solves the syscall portability problem for syscalls. It identifies the OS build, and ShellWasp creates a syscall arrray in response to user input, allowing the current syscall values (SSNs) to be found at runtime, rather than having to be hardcoded, which can limit how you can use them across OS builds. ShellWasp takes care of managing the syscall array, so if a syscall is used multiple times, there will only be one entry in the syscall array. Thus, ShellWasp will allows syscall values (SSNs) to be obtained dynamically.
ShellWasp supports Windows 7/10/11. It uses both existing syscall tables, as well as newly created syscall tables for newer versions of Windows 10 & 11. These are created through an original process, parsing WinDbg results. To achieve a more compact shellcode size, ShellWasp utilizes precomputed syscall tables in JSON format. This allows us to keep the shellcode size minimal.
The shellcode size created by ShellWasp is relatively small in size. Users can select the OS builds to support, and it is recommend to use perhaps just some of the most recent ones from Windows 7/10/11, rather than every possible one. This can help keep size more manageable. Additionall, the way in which syscalls are called differs from Windows 7 and Windows 10/11. ShellWasp will automatically take care of that based on the selections the user makes. We have created syscall shellcode that works across all three OS, using our technique.
ShellWasp 2.0 includes some alternative ways to discover the OSBuild. ShellWasp 2.0 additionally provides three new ways to invoke the syscall from WoW64, all without syscall, int 0x2e or fs:0xc0 - two for Windows 10/11 and one for Windows 7. These two new methods have not been seen before (see below images).
ShellWasp is not an alternative to SysWhispers2/3 or the work of ElephantSe4l, with Freshycalls, etc. This is a different direction for utilizing Windows syscalls. The method of determing OS build or the SSN is not important. (ShellWasp provides a few ways to determine this.) ShellWasp is about helping faciliate syscall shellcode in a compact and reliable form.
The Assembly generated by ShellWasp is compact in size. Additionally, as many people have automatic Windows update, it may be desirable to select only more recent OS builds, rather than every possible one, and this helps reduce size as well. Users can easily and quickly rearrange syscalls in shellcode.
ShellWasp only supports Windows 7/10/11 at the moment, as a desing choice. It is easy to select desired Windows releases via config file or UI. Changes can also be saved to the to config.
Note: You select the OS builds to target--it is not necessary to target every single build--and you select the syscalls to use. The above is just a random illustration. ShellWasp takes care of a lot of the details, but you still need to build out the parameters and required structures.
Download via GitHub and run it on the command line, e.g. py shellWasp.py
Desired settings for selected OS builds/releases as well as Windows syscalls can be added to the config file. They also may be added or changed in the UI.
- On Nov. 1, 2022, support was added for Windows 10 22H2 and Windows 11 22H2. These are the newest Windows releases. Note: we do not support Insider preview builds nor Server.
- On Nov. 1, 2022, the mechanism by which the pointer to the syscall array is preserved has been changed. In testing shellcode with chains of several Windows syscalls, some stability issues were noted with values on the stack. In order to avoid those issues, it was decided to change the stack cleanup (
add esp, 0xXX) andpop edi, tomov edi, [esp+0xYY]- YY being the number of bytes that would have been "cleaned" from the stack. Thepush edithat follows is retained. ShellWasp maintains a pointer to the syscall array at edi, and since the actual syscall itself destroys the value contained in edi, there needs to be a way to restore it, after the return from the far jump to kernel-mode. It was felt this new Assembly would be a more stable way to accomplish this. Of course, another option could be to have a pointer to the syscall array stored at some location on ebp or other memory, and then that could be used to restore EDI. That would in some ways be simpler, as it would be possible to avoiding needing to count the number of bytes to go back. However, it was felt thatmov edi, [esp+0xYY]would be safer for novices. If it was stored elsewhere in memory at a fixed location, such as the stack, it could be possible to accidentally overwrite it. Both approaches take minimal time and effort. - April 19, 2023 - ShellWasp 2.0 is released with masssive changes, including alternative ways to identify to the OSBuild, and three previously undocumented ways to invoke the syscall via WoW64 (one for Windows 7 and two for Windows 10/11).
A setup file is provided to help ensure the correct libraries are installed.
To set up ShellWasp, simply use the following command: py setup.py install
You may substitute py with python as need be. This will make sure that Colorama and keystone-engine are installed. Keystone is used to compile the Assembly, which ensures it is valid Assembly. However, the generated bytes are not currently displayed, as ShellWasp is intended to produce a template, whose parameters need to be customized. This may be enabled as an optional setting in the future.
If you do not wish to use the setup.py file, you can also install these manually. pip install keystone-engine and pip install colorama may be used for that purpose.
Please note that comments I made regarding sorting by address techniques no longer working were incorrect. I apologize for the error. Keep in mind this tool is geared for WoW64, 32-bit shellcode, not as a replacement for other syscall techniques. Our efforts remain in that WoW64 realm.
This project is released under the terms of the MIT license.
Please note that this GitHub is currently incomplete, and it will be updated with more information at a later date, including install instructions.