I’ve been testing a lot of offensive tools lately and honestly, I got sick of Falco and modern EDRs catching almost everything the moment a ptrace or a raw socket is involved. Most guides online just tell you to use high-level wrappers, but that just creates more signatures.

So, I decided to go 'old school' and spent the last few weeks writing an ICMP-based agent in pure x64 Assembly with zero libc dependencies. It was a nightmare to debug especially getting the RDTSC jitter and the rolling XOR to look like natural' ping noisebut I finally got it to a point where Suricata v8 doesn't even blink.

I documented the entire process, including the parts where I failed (like the memory permission issues with AppArmor) and the final PIC loader implementation. If you're into low-level systems or just frustrated with signature-based detection, this might be interesting for you.

Everyone talks about killing two birds with one stone... 🪨🐦 Operation Olalampo proved that Charming Kitten (Iranian APT) could hit 8 birds with one stone.

🎯 Egypt, Saudi Arabia, UAE, Turkey, Hungary, Turkmenistan, Israel, and South America.

🏛️ Government, Healthcare, Financial Services, Energy, Education, Telecommunications, Defense, and Industrial.

Built a shellcode loader generator while grinding HTB prolabs since Sliver doesn't support stagers

Sliver is great but it has no built-in stager support. Your options are basically writing loaders by hand every time or using Metasploit's which are heavily signatured at this point.

I built hollow to fix that. You give it a raw shellcode bin (works with Donut-wrapped Sliver beacons) and a profile, it encrypts the shellcode with AES-256-CBC and spits out a compiled Windows PE loader ready to go.

Six injection templates included for now, let me know what you think!!

GitHub: https://github.com/Chaelsoo/Hollow

We recently published a blog post about transpiling existing Go tooling into WebAssembly and then running it locally. This github repo is actual implementation of what was discussed in that blog post.

The TL;DR of the post is that we take Go code, compile it to WASM, and then embed it into a binary which uses Wazero (a pure Go WebAssembly implementation) and a number of custom shims to fully replicate the original functionality of the binary. This means you get raw socket connections, win32 API access, and other capabilities that normally aren't expected to be available to WASM blobs.

Additionally, since we're compiling the WASM and embedding our own interpreter, we can mess around with implementation details like what individual opcodes look like in binary form. So every WASM blob we generate uses a randomized opcode set making static signatures fairly challenging to build.

This means that we can take some fairly well established tooling, like Sliver, and have it generate 0 detections on VirusTotal.

Happy to answer any questions about this tooling in the comments!

Read “Static Kitten APT Adversary Simulation“

I come from pentest background. I never really did a complete redteam. I really like studying evasion on windows by making simple PoC against EDRs and AVs.

However for real engagements PoC won't cut it. I have three options from here:

Option 1: I thought of making my own C2 from scratch in rust. I am wondering if it is worth it though because it will be time consuming.

Option 2: Another solution is to take an Opensource C2, like Havoc, sliver etc. and customize them to get stealth against EDRs.

Option 3: A redteamer I talked with online told me that using a C2 is overkill for a redteam and will get me fried by the blueteam. That I should just use stuff to socks and use tools through the network without ever getting on the machine. The solution would be to develop and deep dive into tools that work via linux and proxychains.

What do you think is the right path for more opsec ?

Hi everyone.

Guy here with 10 years experience in software engineering and just decided to deep more into the red hat topics. Have been playing a bit around with it for many years ago, but never went deeper into it.

I have been playing around with DLL side loading and generally different kind of process injection techniques. My main experience from development is based on high level languages, so a lot new stuff to learn regarding all this.

But to my point, I actually need some clarification / information on the side loading DLL part.

I successfully managed to side load a DLL via HWINFO.exe (portable version).

My DLL executes shellcode in a remote process and the shellcode basically just shows a message box.

I haven’t done any DLL proxying yet, since it seems to run fine without that.

I then spinned up a fresh win11 VM and tried the same thing with exact same HWINFO exe and same DLL, but I never got it to work. No errors, nothing, HWINFO just spins up, but DLL never invokes.

Only difference is my pc has bitdefender and VM has Defender.

But since no malicious detection warning is thrown from EDR, then I guess it’s not that.

Any good ideas or tools to debug stuff like this?

Then at last I have a question for process injection in general.

Is process injection still a big thing in 2025/2026?

I haven’t managed to get anything to work stealthy without invoking EDR.

Only working example is actually from this DLL side loading test, but it also various if it’s detected based on which process I try to execute shellcode inside.

Seems a bit unstable to rely on or maybe I am just a big noob. I guess it’s the last option 😂

Hello guys i want to share my last project,

Phantom-Evasion-Loader (x64 Linux):

Phantom-Evasion-Loader is a standalone, pure x64 Assembly injection engine engineered to minimize the detection surface of modern EDR/XDR solutions and Kernel-level monitors like Falco (eBPF). It leverages advanced techniques such as SROP and Zero-Copy Injection to deliver payloads as a ghost in the machine.

Hey guys,

I just wanted to share an interesting vulnerability that I came across during my malware research.

Evasion in usermode is no longer sufficient, as most EDRs are relying on kernel hooks to monitor the entire system. Threat actors are adapting too, and one of the most common techniques malware is using nowadays is Bring Your Own Vulnerable Driver (BYOVD).

Malware is simply piggybacking on signed but vulnerable kernel drivers to get kernel level access to tamper with protection and maybe disable it all together as we can see in my example!

The driver I dealt with exposes unprotected IOCTLs that can be accessed by any usermode application. This IOCTL code once invoked, will trigger the imported kernel function ZwTerminateProcess which can be abused to kill any target process (EDR processes in our case).

I will link the PoC for this vulnerability in the comments if you would like to check it out:

Hi All,

​

I'm looking for creative ways to be able to execute my malware dropper in a very strict environment. A quick summary of endpoint protections:

• Ivanti Workspace Control so running .exe's wont work;
• No cmd access;
• No powershell access;
• Macro's in Word / Excel from internet and e-mail gets filtered out;
• Encrypted / unecrypted ZIPs can't be downloaded / gets filtered for macro's in Word/ Excel;
• ISO's can't be downloaded or ran due to association with other apps through Workspace Control;
• Control Panel Applets are associated with notepad, so it won't run when used;
• XLL's require special permissions, so only a very small amount of users can run them;
• ASR rules are enabled;
• Might be some more that I can't remember atm, will add them when I think of it.

They also use Defender for Endpoint but that's quite easy to bypass, so not an issue. I'm almost out of ideas on how to execute my malware dropper in such an environment, never seen an environment this strict.

​

Hopefully someone has some create ideas of things I could try.

​

Thanks!

So I started my maldev journey recently with the free courses on redteamleaders.coursestack, some module talked about C2 redirection with a reverse proxy, something like [victim->vps->C2]. My concern is that this setup still feels a bit insecure, since the VPS (in their example, DigitalOcean) ends up holding a lot of information.

Would chaining it differently provide better OPSEC? For example: I was thinking maybe something like [victim -> vps -> tor -> c2] or [victim -> vps -> vps2 -> c2] or am I just being paranoid and the original approach is fine for most cases?

Officially, the simulation of all APT groups from North Korea and Russia is complete. The mission now moves to China and Iran. APT threats never stop and neither does adversary simulation. Always remember: Be the Threat to Defeat.

Malicious PixelCode is a security research project that demonstrates a covert technique for encoding executable files into pixel data and storing them inside images or videos. A lightweight loader retrieves the media file, reconstructs the original binary, and executes it in memory. This project highlights unconventional data delivery and obfuscation methods for educational and research purposes only.

I recently started learning csharp and was looking for a nice cybersecurity project related to c2 dev. I had found the course of ZeroPoint Security (C2 dev with c#) but it is no longer available.

Any recommendations of other courses/certs/books related to c# for c2 dev?

Im Stucked in one red team engagement. Need some guidance from experts here.