After the disruption of the Trickbot botnet by Microsoft and “allies”, it had become quiet about Trickbot. At least for a couple of days. Just a few days after the partial takedown, comrade Emotet came to the rescue and executed Trickbot on infected systems  .
If you work on Trickbot, especially extracting Trickbot configs, you probably haven’t missed that something has changed in the last weeks. I recently downloaded some newer samples from Malware Bazaar and was wondering, why my config extraction did not work. So I started debugging my code and fixed it but something was strange.
Let’s take 6ca141e8ed2443113c9e497d231b93cf41d86b224993c48f589b375a830cd27c for example.
The extracted config looks like this:
Normally, the port number looks different and there are usually much more C2’s inside the config. When I looked into a sandbox report, I could also see a C2 IP which is not included in the config.
As usual, the Trickbot config blob is XOR and AES encrypted so we have to find new functions which are executed after the config decryption and ideally taking the config decryption output as an argument. If you are using BinDiff, you should be able to spot it quite fast, just watch out for this beauty:
I reimplemented the function in python and it looks like its working fine.
The output and thus the correct C2 IPs look as follows:
I hardcoded port
443 into my function because I could also see it hardcoded in the Trickbot code but there might be other ports in the future as well. So far I only found the group tags
tar2 with identical configs using those fake IPs.
If any of you have more samples using fake C2 IPs with other group tags or other configs, I would appreciate a hint.