Following the previous Citadel Analysis we wrote-->>[HERE], we received so many requests & questions like:
Friends, thank you very much for asking the above questions, and for your patience in waiting the answer. Once dealing with the Trojan banker the sensitivity of information is higher than other PWS, specially to the real "live" case like this disclosure. But don't worry, we won't leave the analysis unfinished & this case is followed properly.
Let's make it short, after long discussion with authority involved + with anonymous malware crusaders (which I respect very much, with thank's for the great help) finally we have every permission needed to release these "limited" information due to answering the questions and for raising malware awareness purpose.
Please bear with my writings, I a not a writer by default.. Well, OK. here we go..
How was it decoded?
What I can explain in answering this is: Dealing with encryption, the key must be saved in the system overall as a binary form somewhere, which is accessible to the malware in exact-unchanged location, hopefully unnoticed to researchers. So, by the possibility, the only legendary place used to save those kind of data is the registry. And, seeing the binary reversing result showing so many registry and crypto access used to a certain place, making this deduction becoming a solid hint.
Moving forward, in our case that data had been saved in the registry as per Cryptography RNG Seed data of the below rows
↑This is going to be the 8 rows of 32bits data(key) which lead to the AES/256 encryption used for the configuration files of citadel. This is a little surprising me since my reference showing me the usage of AES/128 instead.. well, things are indeed evolved, so does malware.
For the data sent to the motherships is the different story, the additionally RC4 is used to crypt the those sent data.
The reason for these encrypted method is predictable, first, for not making the config & sent information so crack-able unless you understand Citadel (or ZeuS) encryption concept, and, secondly is, to prevent the binary RE & Forensics analysis for decoding the "SHOWN" data.
For instance, what I saw in Citadel's binary is practically not so many info can be used as crime investigation evidence itself, thus as we went to the memory analysis to find that memory was fed up with config encrypted data and transmission data (was handled by same binary) which was hard to separate which goes to where,
Yes, I know you have another "more" tons of questions for this section. We are very sorry, that we cannot write more info in the blog, but please follow to the next sections and you will see how the logic flow, OR just contact us by email.
Config File
Please refer to the previous post, you'll find the config file which was in the mentioned folder with the quick snapshot picture over there, after being downloaded soon on post-infection stage.
Depends on your timing in downloading the configuration file (see the downloaded binary data in traffic captured AFTER infection), there is possibility you get the different config data.
The config data itself WE separated into settings, handles upon captures TAG & JSON format, with additionally injected stealer/phishing forms.
Additionally, please be noted that "Both the JSON and Configuration headers were generated by a research tool which outputs the configuration headers, field descriptions, and JSON code. To avoid confusion (for those familiar with Zeus/Citadel already) this is not a new Citadel version and Citadel itself doesn't use JSON format internally. "
In our case, the config data was decoded to have the below explanatory summary by our analysis, please see well row by row for it may contain important information for you.
The configuration headers
The series of CnC with separated functions
The trojan updated setting:
List of the CnC urls/landing page:
↑you see that we deal with the legendary "file.php" & "content.php" hacked sites...
List of the configuration file download urls:
The executed shell prompt command list:
Capture, Ignore, Keylogging,
This part is very important, the "capture functionality" of this trojan, Citadel defines which URL to be logged/captured or which others to be ignored here, also in addition: which URL to get the screenshot are also defined too.
There are mis-perception between researchers who stated that this part has ACL functionalities, but after decoded this part, is clearly proved the real actual function. In our case, this part of config was decoded as follows:
What we can analyze after seeing the config above?
Yes, Facebook, Wellsfargo.com and Australian banks were aimed, their url is clearly written in the capture function, moreover the access related to the site with URI: *payment.com will be captured and it was written the rule to ignore the ,JPG extension files of the .COM sites. The first and second deducted analysis result is self-explanatory while why Ctadel ignore the JPG is for not flooding transmitted traffic with useless image files.
Phishing code injection.
If the URL ssuccessfully captured and then what happen next? The trojan will log and additionally INJECT the malicious codes stated in the JSON format in the configuration files, with noted: if it found previously defined TARGET-ed url ones. Actually this function was seen in ZeuS (and its variant), and Citadel just keep the ZeuS original code for this part.
OK. Please see the below decoded config data:
Which linked to the below next config format in JSON (showing the TARGET and logged functions:
↑Wee see the java.exe or bank.exe is the filename used for the malware downloads for the targeted sites. we should noted this naming thingies, as so we note the URL used for these access, for mitigation purpose.
OK. So what had been injected? The code of phishing forms like we used to see in Cridex/Fareit PWS kind of format was used to be injected upon the targeted sites, see the partial decoded TRAFFIC downloaded as per snipped codes below:
The online banking account's credential phishing traces..
And..Online account's phishing traces..
What else? AntiVirus product's updates URL Redirector
Citadel has the function to redirect the DNS request of the certain sites to be redirected into a certain IP, in the main configuration this function is often spotted to be used to redirect the antivirus upates/download urls into the Citadel's pointed sites.
In our case we found this function is used to redirect the huge list of AV products updates to the IP address: 209.85.229.104 (Google), let's see the following codes:
What had been sent?
Eventhough we are limited in answering this question, we can say that what had been logged and phished above was all encrypted and sent to the remote host. Phishing data will be sent to the defined gateway with the HTTP/POST method via form, with the URL like below: (this is shared for blocking purpose)
While the PC info, logged data and Citadel botnet communication were sent as per recorded PCAP traffic in the previous post.
Moral of the story
Instead to pass the sample as per it is to the AV industry and let the industry does the work, we should also broaden ourself with the information of "which malware, does what, with what". I understand there are so few information of the banking trojans for the reading reference to end users, I hope this post is not only to answer fellow researcher's questions but as one of important reference to mitigate the infection of this trojan in the future.
If you find the specific malware match to the description, help the industry by providing your thoughts, ideas and reference related to the infection you handle/spot. Your concern is the best weapon to fight these stealers. And do not be afraid to make mistake in reporting the infection incident, there is no such EXACT criteria when we are dealing with these stuffs anyway, all people are learners here. I urgue you to explain incident with learning as much as you can too.
In our circle there are plenty good blog posts of malware analysis written by the very dedicated individual researchers, read & follow them is one of our best advise.