Our first Blog post is live, Introduction to RustPack 🔥 msecops.de/blog/posts/rustpa… More to follow in the future for sure!

Backdooring existing executables or DLLs for stealthy payload execution? With version 1.7.0 of RustPack, this can be easily done in a few seconds. We live-debug/trace the execution flow in the target executable to find a suitable backdoor position at runtime, instead of patching the entry point. 🤠 Even Frontier LLM models analysing the output executable with reversing tools at hand and one task - determining whether the target is benign or malicious - will tell you this is benign. 🔥 We work hard, you get the best possible evasion! #redteam #ost #pentest #maldev

Our first Blog post is live, Introduction to RustPack 🔥 msecops.de/blog/posts/rustpa… More to follow in the future for sure!

Did you know you can hide payloads in images or videos without breaking them? 🎓 That's called steganography. Since RustPack version 1.6.0, we support steganography to, for example, hide payloads in any PNG image file. The image file can get dropped to disk on the target system, but can also get hosted on a remote webserver. The RustPack loader will than download the .PNG file from disk or the remote webserver and retrieve the encrypted payload to execute it in an OPSec safe way from memory. 🔥 Defenders will only see an image being downloaded, which won't lead to attention on a proxy/firewall or NDR solution as it's really "just a picture" - or at least looks like that. In this exemplary video, we embed a messagebox shellcode in a picture to retrieve it from the MSecOps website at runtime. Of course, this feature will also work with any DLL payloads, for example, with a sideload.  And any other input, such as Command & Control shellcode, can be used!💪

RustPack version 1.6.0 was just sent to our customers! This release includes multiple enhancements to existing bypass techniques, but also has some major new features such as: - Steganography support - embedding encrypted payloads in PNG images 🫡 - Payload retrieval from a remote web server - and yes PNG images can also get downloaded from a web server instead of from disk only - Position Independent Code output format, RustPack can now be considered as your personal polymorphic Donut on steroids! Create shellcode from .NET assemblies or PE files to stealthily load them at runtime. 🔥🔥

The MSec Operations - @MSecOps - Discord channel provides vetted Cyber Security experts the opportunity to exchange TTPs, to ask questions and to get answers! 😎 More than 280 verified people already joined. discord.gg/JRxXmy8P4B

Machine learning-based detection is not yet widely used by AV/EDR vendors to flag potentially malicious executables. However, some few vendors have already implemented effective engines for unsigned executables. 💡And this has nothing todo with signatures! In the past, the easiest way to get rid of such detections was to use a DLL instead of an executable, as for those the detections are not that aggressive - yet. From our perspective it's only a matter of time untill DLLs get flagged in a similar way. What are you using to tackle such detections? RustPack 1.5.1 has just been released to our customers. The main change in this release is the implementation of multiple new parameters to bypass these machine learning-based detections. 🔥

Tools such as PsExec.py from Impacket are usually flagged for lateral movement due to the pre-built service executable that is dropped on the remote system. However, some vendors also flag Impacket based on its behaviour. With RustPack, you can easily create service executables that won't be detected by signatures or behaviour-based detection. 😎 In this demo video, an unsigned service executable is generated. This will only fire the payload on a system with the hostname 'Win11' — environmental keying will prevent the payload from showing up in a sandbox or cloud analysis. To avoid Impacket detection, we drop and execute the binary via the recently released Titanis protocol library from @TrustedSec: github.com/trustedsec/Titani…. The result is an Adaptix C2 connection in the SYSTEM context. 🫡 #Pentest #RedTeam #Malware #OST

Around three months ago, we provided our customers with RustPack version 1.4.0. 💪 This version included several changes to the core code of the loader component. For example, there were new options to disable the use of indirect syscalls in case any vendor creates detections on those in the future. It is also possible to switch to ntdll or Win32 function usage. Other changes included: - Process hollowing support as an alternative to module stomping (which was already included), with a new OPSec save spawn/inject technique for shellcode execution; no ETWti events for the execute primitive, which could lead to a memory scan. 🔥 - It is now possible to store encrypted payloads on the target system's registry and load them from there at runtime. - Environmental keying support has been added: the payload will only fire when the target system is joined to the specified domain or when the hostname matches. 🛸 - Additional random anti-emulation stubs were added for each payload and tested successfully against major EDR vendors. - The documentation has been overhauled to include detailed instructions on how to find custom DLL sideload binaries, how to weaponise them, and how to perform COM hijacking! 🎓 RustPack 1.5.0 was released to customers just today. The main change here includes: - Polymorphic obfuscation for each payload, with lots of newly added code stubs. - Control flow obfuscation to make static or dynamic analysis more difficult. - Several anti-static analysis stubs that will lead to broken control flows for reverse engineers. - New anti-debug checks at runtime. Interested in using RustPack yourself? Contact us at info[at]msecops.de! 🫡

Creating COM hijacking payloads has never been easier than with RustPack! With COM Hijacking, you can persist on a target system by 'living' in trusted user processes, such as the Chrome browser. You only need to bring one DLL. When the user opens Chrome, for example, a C2 connection is established. 🔥 Achieving stable payload execution without crashing or freezing the target system requires an understanding of what is relevant. Additionally, lots of processes may attempt to load the hijacked CLSID; you don't want to receive 43 beacons per day from the same system. Limiting execution to a defined process is important here! 🎓 What about combining that payload with environmental keying, anti-emulation, anti-sandboxing, as well as AMSI and ETW bypasses? Doing all this yourself will take time. With RustPack, however, you can create such a payload in a few seconds, and it's stable! The video demonstrates how to create a payload DLL to execute Adaptix C2 shellcode in the Chrome browser. 🛸

Rumour has it that Jonas Lykkegaard's self-delete technique doesn't work on Windows 11 anymore. Well, the original proof of concept (PoC) does not, but slight modifications bring this technique back to Win11!😎 With #RustPack, you can easily generate self-deleting executables or DLLs. The following video showcases a DLL being executed from rundll32.exe and deleting itself while the process continues to run. 🔥 Of course, this also works for DLL sideloads. Having problems generating payloads yourself? Don't have time for proper evasion? Your loaders get flagged regularly? We've got you covered — contact us at info[at]msecops.de 👍

#RustPack version 1.3.0 has been released today. This version includes (again) minor changes to the final payload metadata to remove various potential IoCs. 🔥🔥 For example, most packers use some kind of string based encoding to reduce entropy, such as the well-known UUID, MAC, IPv4 endings. Or custom words. However, having a large amount of strings in a binary can also be considered suspicious, so this release now uses a different encoding that looks like legitimate code instead of strings. 💡 You can never have enough alternatives to bypass AMSI or ETW? With this release, we have reached the point where new techniques should not be needed for some time. We have added three new AMSI bypass techniques and two more ETW bypasses in this release. This makes a total of 7 different AMSI bypasses and 5 ETW bypasses. Of course, we provide our customers with information on which bypass to use against which vendor. Multiple of those bypasses are not used by any public open source tools by now, ensuring long term coverage without detections. If any of these bypasses get flagged by behaviour, we usually also adjust them for the next release so that it's usable again. 😎 One of the newly added AMSI bypasses is a customized Ruy-Lopez version, which not only prevents AMSI related DLLs from loading into a process but which on top also prevents userland hooking DLLs from loading. You will therefore not only get rid of AMSI based detections but also don't have to worry about userland hooks in that process anymore. 🥳 From this release on, all executables and DLLs by default use random metadata information, such as copy right information, productversion and so on. Executables are also shipped with random different Icons, which also reduces overall suspicion. But Operators can now also clone any other files metadata or Icons, so that executables can look like PDF-files or whatever else you prefer to use. Interested in buying RustPack or getting more information? Contact us via info[at]msecops.de ! #Pentest #RedTeam #OST

In one of our previous videos we demonstrated how to generate sideloading binaries by cloning the exports of an existing DLL to forward them - x.com/MSecOps/status/1881421… . However, using Microsoft DLLs and Microsoft-signed binaries is not the best OPsec, as it's easy for EDR vendors to create a detection rule for e.g. "version.dll" being loaded from a non-System32 directory. 🧐 We therefore recommend using third party signed executables that attempt to load their own DLL. This is much harder to track/map on the endpoint. If you know which functions are imported from your signed binary (see import table), you can also generate a sideloading DLL for persistence or initial access use cases. Bring your own third-party signed binary and voila - you're trusted! In this example, we sideload into java.exe, which is signed by Oracle. It attempts to load several DLLs - including jli.dll as shown in the video. #RustPack can easily create such DLLs with custom export functions - anti-debugging features, sandbox evasion, signature evasion and anti-emulation can be easily added. 🔥🔥 Userland hooks are bypassed by default options and you can enable custom AMSI/ETW bypasses for the process on top. If you want to use it for persistence, you can of course still clone the original DLL exports as we did in the previous video and forward them accordingly. 👍 Interested in buying RustPack? Contact us at info[at]msecops.de ! #RedTeam #Pentest #OST #Maldev #Malware #Havoc

#RustPack Version 1.2.0 is now released for our customers. The biggest change was to add full DInvoke support for all payloads. The import table now won't show the Windows APIs being used anymore, instead by default random non malicious imports are added in here to make payloads look more benign. This was in the very end like a re-write of all existing code. Besides from that one new AMSI bypass alternative was added on top of the existing ones. All of them work fine against most EDRs but it's always good to have options. 🙃 On top one new OpSec safe injection technique was integrated, in combination with the existing options it will be hard to flag your payload - even with ETWti data. 🤠 More info here: msecops.de/products

How do you create your payloads in 2025? At MSec Operations we prefer to use DLL sideloading for EDR evasion. This technique allows our malicious code to run within a signed, legitimate executable. Combining this technique with other useful techniques will provide stable execution to fly under the radar. 🛸 The following video demonstrates the use of #RustPack to create such a payload in just a few seconds. The command line usage shows that our input payload is a simple unmodified Apollo C2 executable. We want to clone all the exported functions from the original Windows wininet.dll to create our own library with the same name. The execution of the payload will be delayed by ~5 seconds in this case, without using the Win32 sleep function, but by performing random calculations. ⏲️ Hardware breakpoints are used to bypass the Antimalware Scan Interface (AMSI). Without an AMSI bypass, Apollo would be flagged as a C# assembly when loaded. 🎓 Our payload will only fire on a domain joined system, this basically prevents it from running in e.g. sandbox environments. 🤠 Last but not least, in this example, the encrypted payload itself is stored in a separate file on the target system and not even in the same folder as our malicious DLL. Anyone analysing just the DLL will never be able to find out what the payload is. Automatic sample submissions for cloud analysis usually only upload the executable or DLL, emulators won't see the real payload either. 🤠 Tired of creating such payloads yourself? With #RustPack it's really easy, and payloads always look completely different, even if the same payload is packed twice to avoid signature-based detection Contact us via info[at]msecops.de for more information! 👍

The next version of #RustPack will not expose any of it's used imports anymore 🔥🔥🔥 Instead, there will be random friendly looking imports for each payload. Only if the operators really want to they can still go for zero imports. Just because it's possible.🙂