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 :)