rootkall's blog

 Introduction This is not going to be a long article. I wrote some article before about blunders in malware infrastractures. Some threat actors make some bad mistakes and that could cost them their infrastructures or logs in case of stealers. - This article shows an example of a simple bug that could cost the threat actors their entire infrastructure https://www.rootkall.com/2025/03/hacking-website-used-to-deliver-malware.html - This one is about a Stealer called Gremlin, the logs were accessible via an "Index Of" page :p https://www.rootkall.com/2025/04/gremlin-stealer-strings-decryption.html I wasn't really sure if I should write about this case but sharing knowledge is always good. As you can see in the screenshot, someone shared a C2 panel, and I love these in the sense that I try to compromise them. I pointed out in an answer to the tweet the blunder error that is made. The C2 Panel is Open source: A quick search of "C2WebServer" in a search engine would yi...

 Introduction This is a quick static analysis blog post.  @solostalking  shared with me on twitter a sample of a new stealer this morning. I decided to take a quick a look at it. Found how it decrypts the strings. It can be automated. I'll just showcase the algorithm. sample: https://app.any.run/tasks/69325fa1-b37e-41dc-a1f8-bb0038345a3d Decrypting the strings Since it's a .NET sample. Let's open it in DnSpy. Skimming through the methods of the main module, I found this one Obviously, seeing a loaded resource and some obfuscation + it returns a string, you think it's a string decryption method. It loads an encrypted resource. Uses the first and second parameters to calculate an offset. And finally a decryption routine. Notice how all the elements of the array are xored with the SAME INTEGER which is the third parameter.  We can make use of Cyberchef's XOR bruteforce and bulk decrypt everything in resource. We can recognize some strings such as chrome.exe etc......

 Introduction This is by no means a thorough analysis. It's merely a quick discussion and highlight of my findings while working on a new LummaC2 version. I managed to write a config extractor which can be found here : https://github.com/lowlevel01/config-extractors/blob/main/lumma.py Sample hash : sha256: 820a1d5a52a6afbf36fe4c00e4d65716d3f796b53eab4c2bcd93a193e95a376d TLDR; - A new Lumma version that uses fnv1a hashing algorithm instead of MurMur2 for Dynamic API Resolving - Hashing algorithm not identified by the Hash-db plugin - ChaCha20 encrypted config. In this case, the 4 nullbytes mentioned by  eSentire's blogpost  are not appended to the nonce which is kept 8 bytes long The config extractor: new API Hashing algorithm This new version uses FNV1A hashing algorithm instead of MurMur2 for Dynamic API Resolving. The prime number and the initial hash are decrypted from the stack at runtime. Here is a re-implementation in python: A friend of mine with good crypto k...