sightlobi.blogg.se

1. #Ccleaner malware ip address http post requests full#
2. #Ccleaner malware ip address http post requests code#

The malware proceeds to decrypt two more URLs. It starts by ensuring it receives the correct response from and. The next module is a essentially another backdoor that connects to a few domains before revealing the true IP, it will connect to for the next stage payload. From here, it is as simple as modifying the first two bytes to represent MZ and we have a valid PE file. If we look at the memory of the next decrypted payload, we can see something that looks like a PE header without the MZ signature. The next payload is executed, which decrypts another module and loads it. The new module being run by the service allocates memory, reads the registry where the other payload is located, and then copies it to memory. Some shellcode and another module are written to the registry.Īfter the module is successfully dropped, a service is created under the name Spooler or SessionEnv, depending upon your environment, which then loads the newly dropped module. The last modified time on the modules is changed to match that of the msvcrt.dll that is located in your system32 folder–a technique to stay under the radar by not being able to check last modified files. It looks like the attackers used version 1.1.4 of zlib to decompress the payload into this allocated memory region.ĭepending on if you’re running x86 or 圆4 Windows, it will drop a different module. Instead of using the typical API (VirtualAlloc) to allocate memory, the attackers allocated memory on the heap using LocalAlloc, and then copied a compressed payload to the allocated memory.

#Ccleaner malware ip address http post requests full#

I will not be going too far in depth as full comprehension of the technical analysis will require an understanding of reverse engineering. Although there is an 圆4 version, the following analysis will only include the x86 version because they are nearly identical. The stage two payload that was analyzed in this report (dc9b5e8aa6ec86db8af0a7aa897ca61db3e5f3d2e0942e319074db1aaccfdc83), after launching the infected version of CCleaner, was dropped to only a selective group of targets, as reported by Talos.

#Ccleaner malware ip address http post requests code#

The author probably copied and pasted the code, which is what often happens to avoid duplicative efforts: rewriting the same code for the same functionality twice.ĭue to the uniqueness of the shared code, we strongly concluded that the code was written by the same attacker. The attacker used the simple technique of employing an array to hide a string from being in clear sight of those analyzing the binary (although to those who are more experienced, it is obvious) and remain undetected from antivirus signatures. It is also worth noting that this isn’t a standard method one would use to call an API. Let me put this into better context for you: out of all the billions and billions of pieces of code (both trusted and malicious) contained in the Intezer Code Genome Database, we found this code in only these APTs. The above photo shows the same function between two binaries. Not only did the first payload have shared code between the Axiom group and CCBkdr, but the second did as well.

After uploading the different binaries to Intezer Analyze™, the final payload (that I have access to) had a match with a binary relating to the Axiom group.Īt first glance, I believed it was going to be the same custom base64 function as mentioned in my previous blog post.

Starting from the stage 2 payload, I reverse engineered the module, extracting other hidden shellcode and binaries within.

Also, we would like to give a special thanks to Kaspersky Labs for their collaboration. Since my last post, we have found new evidence in the next stage payloads of the CCleaner supply chain attack that provide a stronger link between this attack and the Axiom group.įirst of all, our researchers would like to thank the entire team at Cisco Talos for their excellent work on this attack (their post regarding stage 2 can be found here) as well as their cooperation by allowing us access to the stage 2 payload.