A funny malware exploit I've recently seen was this one...<p><a href="https://mastodon.social/@slipstream/99116564964787956" rel="nofollow">https://mastodon.social/@slipstream/99116564964787956</a><p>> So, there's a Chinese botnet package known as "Destroyer" (破坏者). It, ironically, can itself be destroyed, thanks to a stack buffer overflow. I wasn't able to get full RCE, but a jump to "call ExitProcess" should be enough, no? It can be triggered directly after "start DDoS", for even more lulz.<p>> Here's the exploit: <a href="https://gist.github.com/Wack0/d0aa7f56d5d044fb918056207d2149b1" rel="nofollow">https://gist.github.com/Wack0/d0aa7f56d5d044fb918056207d2149...</a><p>> The C2 for this shitty chinese skiddie ddos-botnet has a stack buffer overflow in the parsing of packet opcode 3. This opcode is used for sending ddos-stats, so it only works when a packet with opcode 6 (start-ddos) is sent to us.<p>> Unfortunately, two addresses are written to before returning; these addresses get clobbered, and the C2 binary is compiled with an ancient compiler (VC++6 lol). No null bytes, so we can only overwrite two addressses, one of which has to be the return address... We can get eip control via SEH, but the full packet buffer is too far away on the stack for us to be able to jump to a ROP chain :(<p>> So the best we can do here is return to "call ExitProcess", at least there the bots are neutered enough to be absolutely useless... (there's additional functionality in the bot, but it seems the C2 that i have has no UI to send those packets lol)<p>> So, exploitation: (1) connect to C2. (2) send initial (system info) packet, this includes OS info string (we provide the string sent for "unknown OS" here), and CPU info (number of CPUs + CPU speed), we provide the specs of the highest-range Ryzen Threadripper here, because we can. (3) wait for packet 6 (start ddos) to be sent to us. (4) send our evil packet 3. (5) ??? (6) C2 killed :)
I like the fact that malware authors also seem to have trouble setting up a (secure) software development lifecycle. On the other hand if they were to threat model it, expoiting weaknesses in the agent does not cross a trust boundery so why bother. Imagine this would be different for their command and control infrastructure.
Minus the lulz, what is the point of this? It seems there's some possibility of remotely disabling malware... and then some more possibility of malicious piggy backing on already installed malware.<p>It's an interesting point that malware is typically poorly developed, but not sure what the point of this research is.
What's with the color scheme on that website? I have good eyesight and I'm struggling with the contrast ratio. God help anybody with vision problems.