Multiple Bypass Techniques from other researchers
And my rant against AI grifters
AI Bros, Vendors, & Infosec Frauds, go fucking kill yourselves
Oh, I’m just multitasking here, and I’ll just be taking notes. Hopefully, this will be organized by, um, a thingy, right? Make AI useful somehow, right?
Um, saw something about basically, uh, evading host armoring, which was really cool. Because it’s almost as if vendors like Microsoft have two different teams. You have a completely incompetent AI self-dick-sucking marketing grift team, and then you have the other team that actually is a competent security team. And we’re not talking about MSRC [Microsoft Security Response Center]. MSRC is like a niche, like Black Ops kind of thing for Microsoft in the private sector. They are one of the most unappreciated divisions in Microsoft, by the way. I do distinctly remember people from X-Force—IBM X-Force—reporting vulnerabilities and getting frustrated because MSRC is always constantly being shot in the foot, not by themselves, but by Microsoft marketing politics.
And Microsoft marketing politics takes the ideas from Nadella and his cronies of AI sycophants and basically... oh, this one... I’m just looking at this, is really cool for, um, LD_PRELOAD on Linux. But okay, so it’s clearly obvious that people like Nadella of Microsoft have surrounded themselves with a tight circle—kind of like an AI grifter cult. It’s very much like how ants are keeping an aphid prisoner, and the aphid has no other purpose in life but to eat and [excrete] some sort of sugary fluid. Except this sugary fluid is validation and a salary. It’s pretty obvious. And as a result of this sycophancy—and, well, not “sycophancy”—well, it is sycophancy, it has nothing to do with the relationship between ants and slave aphids, but because of this cult of sycophancy... um, let me look at the next one, next article.
What happens is, is that really bad ideas are starting to compromise, um, very vigilant patches. All right? So every good idea has been completely undercut from the ground by a really dumb and bad fucking idea. You know, like even non-technically adept people can realize that maybe forcing AI down the throats of their users in Windows would cause a massive influx of attempted Linux installations, like Linux Mint. I mean, Linux OSs are even more accessible than what was before. Don’t you remember the old days of Linux? Wireless card guaranteed to fail. You know what else? Probably your video card. Probably your video card guaranteed to fail. Speakers never worked. You’ll never be able to print your documents on LibreOffice. And at least half the problems have already been solved.
So while the self-dick-sucking marketing team of Microsoft is huffing their own farts, getting real, real high, smelling their own “gasoline”, and not listening to the Microsoft Security Response Center or whatever other security teams are there to harden Windows... as well as making Windows 11 effectively unusable. As far as I can tell, um, the taskbar has now been located at the top, and people are too stupid to move it back to its original state. I mean, I guess they don’t have things like git reset hard in Microsoft or git merge, but who knows?
You know, but things are so incompetent and dumb. For example, full speed ahead AI Rust rewrite of kernel-level and native code that is the backend for everything of how Windows works. Which is even dumber because Rust is proven to be not memory safe. They call it a safe-typed language. They call it memory safe, and yet there are already proofs of concept in well-written research papers of how memory corruption bugs can be reintroduced. And it’s not exactly like obvious. It’s super subtle. You don’t have to explicitly export an unsafe pointer—in other words, one of those C pointers, they call them unsafe pointers. I’ve seen the write-ups, I’m like, “Holy shit.”
And um, it’s not a concern for me as an attacker, but it is a concern if my own machines—that might be running Steam to play Space Marine 2, right? ‘Cause that’s the best way to enjoy Space Marine 2—is going to crash, blue screen, have a taskbar at the top instead of the bottom, or even worse, someone ransomwares me over some sort of exploit in a peer-to-peer game like Space Marine 2, okay? I’m pretty sure someone has that idea right now.
LazyHook Repo
For—hello, for example, let’s show you some research I’m looking at. There’s a user on GitHub called HWBP (Hardware Breakpoint) and he created a repo called LazyHook. [It aids] behavioral analysis by executing malicious code within trusted Microsoft call stacks. Patchless hooking library, Import Address Table, Export Address Table...
https://github.com/hwbp/LazyHook
So previously, I think, you know, Renz00h described a hardware breakpoint in a Vector Exception Handling [VEH] to hook patchlessly, right? Which defeats inline hooking and technically is superior to Globex-Gate. Um, and in this repo, it says: “The hooked function is in a trusted, digitally signed Microsoft DLL. When your payload executes, the call stack shields a trusted module as the caller. The hardware breakpoint leaves no memory modification, so integrity checks pass.” In other words, it bypasses the well-obfuscated ci.dll or the Code Integrity module.
And it says here in a graph: Target Function Call → CPU Debug Register Triggers → Exception Single Step Raised → Vector Exception Handler Intercepts Exception → Execution Redirected [to] Hook Function → Call Original. Original Function Temporarily Disables Breakpoint → Original Function Executes → Breakpoint Re-enabled.
So it’s basically the same thing as, uh, Renz00h in Malware Development Advanced Volume 1. But have we not talked about this before, and why Globex-Gate was more of a generic gate? And the reason why is... okay, so um, Globex-Gate is a global gate method using inline hooks—old school method, right? And this method is technically superior, but there are only four debug registers in a thread. And why do we only... can we only do it within a thread context? So you have four debug registers for hardware breakpoints per thread.
Um, we open a debugger, you have a global context, but you can actually just click on a few buttons in x64dbg or enter a command in WinDbg to change into the context of a specific thread. So in other words, you need to prioritize what that specific thread does. So for ransomware, you can only tamper—at least with the precision of a hardware breakpoint... The, you can only tamper within the position of a hardware breakpoint... um, only four functions. So you better pick a good choice, okay?
We don’t really have to keep on adding to what is effectively a redundant technique of constantly loading malware through a single PowerShell process, but if you were in a pinch, you would prioritize things like CreateFileW, DeleteFileW, BCryptEncrypt, and maybe something else like... um, hmm, what would be number four? I would leave that to someone else to suggest because while I can generate a key and then wipe it, that encryption key as it encrypts actually can be a side-channel attacked and extracted from the cache. So ransomware also has to flush its own cache lines, by the way. But this is more of a tool for specific components of your malware, okay?
So the solution in this repo says: “Trusted call stack spoofing by hijacking a function in a Microsoft signed assembly (e.g., System.Windows.Forms.dll, user32.dll), we can execute arbitrary logic within a call stack that appears completely legitimate.” So in other words, this is like a hardware breakpoint version of Hook Chain, which is actually a combination of Halo’s Gate, indirect syscalls, and proxy functions.
Um, depending on the malware that you’re trying to protect, it could be more plausible to use my Globex-Gate, or Beacon Gate, or Hook Chain. Or for specific, more simplified malware, this technique LazyHook, because LazyHook abstracts a lot of the complications of obfuscating more sophisticated custom malware. It is definitely something you want to bookmark. I assume that if you write your own malware, you would know exactly what you’re trying to hide and what you prioritize. Just be mindful that using hardware breakpoint hooks can only support four functions [per] thread. I said thread, not the entire process. So we can create multiple threads that do different tasks.
ShigShag Method for AMSI bypasses
All righty then, and I am almost done reading the latest in Host-based Evasion, is what I like to call it. Simply because TryHackMe gave it this category, so pretty much what I’m writing in this article is “Host-based Evasion.”
So we’re going to show you, um... or from this guy, EvilByte, [some] C-based image-side patchless Vectored Exception Handler (VEH) hardware breakpoints. Now, building on our previous limitations: each thread can only have up to four patchless hooks because there are only four debug registers—from DR0 to DR3—to support a hardware breakpoint. Um, let me see... interesting person, follow me on Substack.
Um, let’s go on. So this one’s pretty basic. In fact, it only populated one, I believe, out of four; it only populated AmsiScanBuffer. That’s a proof of concept. So I already told you the previous limitations, right? For example, ransomware may have multiple threads, maybe. And if the thread does the same purpose, but ultimately you’re gonna have to only use the same up to four targeted hooks—patchless hooks—to protect your ransomware from detection, right? And even if you wasted all four hooks just to protect it from scanners, ransomware, simply by behavior itself, it will [be detected]. So, right, of the ransomware process.
However, there is another compromise, and we can go back to ShigShag’s method. It is sound. It’s still a patchless hook. But when I talk of accuracy, I’m talking about if you were to not use a hardware breakpoint, but you hook patchlessly a function within a memory page... in this case, the same thing, AmsiScanBuffer. This alert will fire throughout the entire memory page.
https://shigshag.com/blog/amsi_page_guard
I think I wrote an article before about exactly how much code could be in a memory page. Have you compiled “Hello World” in 64-bit, right? No message box, by the way. Let’s just do printf, pointer to a string, “Hello World” in C. So in total, you may have two 64-bit memory addresses, so that’s 16 bytes. You have the eight bytes to call the pointer to printf from the standard C library. And then you also have a pointer to the string. So that will be the length of “Hello World!” So that’s how much memory it takes. How much is that? Somewhere in double digits, maybe like 20, 30 bytes for a pointer to a function that calls another pointer to a C null-terminated string.
Let’s think, how many times can you copy and paste that onto a memory page? Hundreds? So you got to be careful when you use ShigShag’s method, although this basically gives you unlimited slots. And this involves reverse engineering the DLL. So that’s pretty much the only way this can accurately work, is that... I suspect the author known as ShigShag, which has a super cool profile picture of Squirtle with sunglasses—cool dude, I like this guy—so you have to be super accurate, because the function you are hooking has to... this... Okay, let’s see, what’s this?
Yeah, it’s basically what it says. Apply PAGE_EXECUTE_READ, apply PAGE_GUARD protection to the address so we can fire the exception, and then the Vectored Exception Handler catches that exception: STATUS_GUARD_PAGE_VIOLATION.
So, is there a flaw? What if there was a bunch of functions on that same memory page within the average size of 4,096 bytes, also known as a kilobyte [sic - speaker likely meant 4KB]? So in other words, it could also fire on functions—or pointers to functions—on that memory page that are not related to AmsiScanBuffer. And if you were to intercept with no hardware breakpoints—zero hardware breakpoints—and then attempt to handle that exception, and then you change what it would return, then now it’s so unpredictable. It’s likely to crash. You understand?
So there is an unlimited, no-patch hooking method, but this requires more reverse engineering. So be careful if you use ShigShag’s write-up. You need to reverse engineer and load amsi.dll into memory. I don’t care if you put it in Notepad. Just go use Process Hacker or x64dbg or something. Dump that whole memory page where amsi.dll got called and try to trigger AmsiScanBuffer and check neighboring functions, okay? Just to be safe. Because that’s a whole kilobyte [4KB] of memory, the average memory page size on a modern Windows machine.
Other than that, ShigShag managed to actually figure this out, so you just freed one slot, by the way. You just got patchless AMSI bypasses, so now you can use four more slots per thread in your hardware breakpoint debug registers. That’s cool.
Learning on my own
OK, so you might be wondering: why the hell am I basically making reviews instead of just reporting like a journalist? Why am I also making reviews of TTPs [Tactics, Techniques, and Procedures] made by other people, and why would I suggest situations on how it could be optimized?
Well, I mean the last part was a great service, but what I’m trying to say is: look, dude, I have my own time. I have to start learning too, okay? So if someone else solved the problem for me, yeah, oh yeah, I’m going to learn the shit before I move right on. I got my own stuff I got to learn too. I didn’t say I was a pro web app hacker. Okay? That’s one of my weaknesses. I do reverse exploits to use in mass exploitation. That is true. And I’m learning too. Okay? I was actually surprised how simple the SharePoint gadgets were chained to get RCE [Remote Code Execution], by the way.
But I got my own... um, how many links was this? I was actually reading 20 different links before I added my own commentary. So I had to knock all this down in like... just one day, of Friday since 10 o’clock in the morning. And I was actually reading them for weeks, and I was just collecting all these write-ups because, um, on top of reinventing the wheel, you could also—as Pantera had to level up—reinvent the steel and improve on the tradecraft.
No Virtual* Shellcode Runners in C#
I don’t know if I’ve ever said this, but it was a trick based upon JIT spraying and overwrites—a really innovative technique that is actually even better than D/Invoke. It was almost perfect. Basically, in C#, you can allocate a buffer, all right? And in this buffer, you can overwrite the beginning of it with native shellcode. So just like how we’re doing this in this ransomware, we’re gonna do it again in C#. And whether you chose to compile it and then run it through reflection techniques—which we can go through too, it’s not that hard—or you can um, keep it uncompiled and then just stomp it out.
https://github.com/Mr-Un1k0d3r/DotnetNoVirtualProtectShellcodeLoader/blob/main/OffensiveX-2025.pdf
Um, just... just one little teeny little bit. And all I’m asking is that you allocate the size of the buffer to an evenly sized, average memory page that we’ve been harping about the entire article: 4 kilobytes or 4096 bytes. And the reason why is we’re going to make it look like it was a regular section of memory. And you can fill it up initially with null bytes or software breakpoints. Those are very commonly found. I prefer null bytes because that’s what code caves look like.
And the only reason why we’re going to use a modulus operator to calculate the size of how many fake memory pages we’re going to make is because having a thread start up from an oddly shaped memory page—as it would look like—it’s going to look really weird, and it’s a serious red flag, by the way. What else of this? All I’m asking is just one more thing to add... Thinking. What’s one more thing I had to add? Yeah, I think that’s it.