Another recurring series, bi-weekly, where I round up a bunch of shit I read that was interesting. You might also find it interesting.
This one should not go out using the newsletter feature, I hope. Again, still getting used to using Ghost.
This was meant to go out on May 19th, but I forgot, so instead - it has some extra links.
The Buzzer, or Repeating Military Cats.
This article from our friend over at Jellicle Intelligence is worth a read if you are interested in numbers stations and all that. It basically is a summary/fact check that busts a few of the more often repeated myths about "the Buzzer", with a lot of good onward links for further reading.
TL;DR: yes, its Russian. Yes, its military signalling. No, it is almost certainly not their Perimeter/dead hand system.
I'm looking forward to more work from Mr Mistoffelees on related subject matters in the future.
Increasing the Vitamin D Content of Mushrooms, by letting them soak up sunlight.
I'd somehow missed this article from Stamets in my mushroom reading until someone posted it on the orange webshit.
The short version is: mushrooms continue to produce things like vitamin D, even when they are "picked" and drying. They even continue production when dried and powdered, if exposed to UV light.
So you can "fortify" your mushrooms vitamin D content by just sun drying them (for storage), or blasting them with UV light.
The caveat here of course is there is such thing as too much UV, excess will break down the Vitamin D again...
It should be noted that mushroom produced D is D2, not D3, but it also seems there is fuck all difference in the two when it comes to you actually consuming it.
Given most of us northern hemisphere dwellers (and especially computer types) are lacking in some D, getting some from mushrooms by just leaving them in the sun or blasting with a UV lamp seems like a possibly worthwhile endeavour.
More on mushrooms later.
Ghidra now has an emulator.
This article provides a nice, quick overview of the new (ish) emulation features shipped with Ghidra, the software reverse engineering toolkit published by the NSA.
Emulation features are really quite useful for routine reverse engineering tasks such as deobfuscating or unpacking malware (or just shit software), being able to emulate the instructions without actually running the code and step through it, etc.
I've yet to experiment with the emulator - or even the debugger support - as most of my Ghidra use is purely static analysis these days.
Probably time for that to change.
PaperCut Exploitation - A Different Path to Code Execution.
Another absolute banger of an article from VulnCheck, which extremely thoroughly outlines alternative way to get code execution on PaperCut servers when exploiting CVE-2023-27350.
In the post, Junior highlights that by simply choosing an alternative method of executing code once you have bypassed authentication, and there are a few ways to execute code, you can circumvent most of the detections that Bitter has published.
This made Bitter very angry at Junior (and not for the first time), they saw it as an attack on their work, etc, etc, blah blah.
Take home message: writing detections is hard. Writing fragile detections is better than a kick in the balls, but you don't get to get salty when someone points out that they are fragile.
rax30 patch diff analysis & nday exploit for zdi-23-496
hypr wrote this excellent article on some patch diffing of a router - the Netgear RAX30.
The article links to another excellent article from Claroty about the first bug (in soap server), and then goes on to show how you can get code execution as root on the router, provided you can plug in a USB drive that gets mounted, due to a misconfiguration in lighttpd.
While such an exploit does require physical access, its pretty neat and shows the fun things you can find when diffing firmware on a device.
NightHawk Memory Obfuscation
I've long been hoping someone would go to town on NightHawk, given how fucking expensive it is (and how talented some of its devs are), and Austin Hudson delivered - showing exactly how its memory obfuscation sausage is made, giving enough information for you to make your own implementation of it.
Apparently a PoC for the audience who just want to copy paste will eventually happen, and we can all move on and try find new ways to hide in memory.
Finally, a reason for the "Rock or Something" on US MRE's.
Look, most of us have at some point watched Steve review MRE's. Some of us will probably have acquired an MRE at some point out of curiosity. American MRE's contain a flameless ration heater that uses an exothermic reaction to make heat if you add water, and on the packaging, it specifies that it should be placed against a "rock or something". This article from Task and Purpose finally lays to rest the burning question we all had: why does it say that?
Identifying Quasar RAT C2 Servers.
An interesting post from Matthew, showing how a unique characteristic in the SSL certificates used by the Quasar RAT can result in being able to remotely identify Quasar RAT C2 servers.
I was able to identify the exact line of code where this is hard-baked. I mean, the user can configure it, but the user is also likely a skid. So.... Yeah.
Hunting Malicious Infrastructure using JARM and HTTP Response
So, related to the other entry in hunting C2 servers is this one, which goes into detail on using JARM (SSL fingerprinting) and webserver responses to fingerprint and detect C2 servers, with Brute Ratel and QBot as the examples.
Many C2 servers will have "unique attributes", which will allow you to pivot from finding one to finding more malicious infrastructure. You can even go as far as to write Nuclei scanning rules to do your own scans, etc.
Emulating embedded devices with Qemu
This blogpost by Olivier Boschko gives a worked example of how to go from a router firmware to emulating it in Qemu for identification and verification of software vulnerabilities.
There is surprisingly little good documentation "by example" out there of this process, so its always good to see a clear, well written example of the procedure.
Debugging D-Link: Emulating firmware and hacking hardware
This post from GreyNoise also covers embedded device hacking and emulation, along with some patch diffing, details on decrypting D-Link's encrypted firmware images, etc. All of which is incredibly useful information. It again uses a worked example, which is helpful to show the process.
Every time I see a good article like this one or Olivier's on the topic of firmware emulation/extraction, I'll be making a note of it in this series.
Someone out there is writing backdoored firmware for routers.
In this entry, Checkpoint uncover a router firmware backdoor targeting TP-LINK devices.
The backdoor itself is pretty simple, being a handful of binaries which collectively offer up a bind shell, SOCKS proxy, reverse shell, file transfer, configuration updates, a watchdog, and HTTP beaconing.
It also tries to disable the firmware update feature as a 'persistence' mechanism by hiding the form on the web interface, which gave me a chuckle.
It is neat to see more firmware rootkits for embedded devices in the wild. We don't see enough of them in my opinion. I intend to change that somewhat :)
Exposed Quadream spyware control web panel
This article on the zeroclicks substack is interesting. Apparently, someone working for (now defunct, lol) spyware vendor Quadream accidentally uploaded a fair chunk of the source code for their control-panel (the panel customers use to interact with the spyware, launch exploits, etc) to Github.
The article goes over some interesting bits found in the leaked source, and makes a few inferences as to how the spyware functions/how it potentially infects victims based on stuff in the code. Neat.
Backdooring SSH Public Keys.
The Hackers Choice have posted an interesting trick that uses a little known quirk of SSH public keys to 'backdoor' a users public key, so that commands are ran whenever they log in. Yet another entry into "infinity ways to backdoor Linux".
Their example one drops their gsocket backdoor (more on that in a later post, I think), ships off the 'secret' from gsocket to a discord channel via a webhook, and then presents the logging in user with their shell prompt or whatever, so they don't notice anything.
They make note that this backdoor can be 'spread' by the user uploading their key elsewhere, for example to a cloud deployment script or ssh-copy-id to a new host.
I do wonder now though, this ability to 'embed' a command in a SSH public key, what impact (if any) will this have on services such as Git servers where SSH public keys can be uploaded via web for authentication?
Someone else can surely answer that question. And probably score a giant bounty.