rootkall's blog

 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...