Another day, another malware, and today it was an unknown Delphi application which encrypts your office documents on your non-root and non-CD/DVD drives and prepends it with a copy of itself, turning a document into an executable. Great, everybody loves these kinds of things as your entire IT dependant organization will grind to a complete halt if it hits your organization. So, how did people get infected by this? Well as it seems it was not a drive-by exploit on a large news site or some compromised advertisement server which caused this malware to run, but instead an already existing ZeuS variant named Citadel which downloaded and executed “a.exe”.
Should you worry about all those encrypted document files on your network…, what you should really worry about, is that there apparently was/is a trojan (ZeuS/Citadel) on your network that was doing active C&C communications and has been leaking all kinds of information from your organization for days, weeks or perhaps even months. And apparently none of your IT security defenses has removed it, has blocked it and neither has signaled you that there was something wrong on that system. If you were hit, you will likely start asking yourself some questions now… A properly configured IDS would have picked up the attack earlier and you would have been notified of the event.
Communication to the following IP addresses might indicate malicious behavior on your system:
184.82.162.163
184.22.103.202
So the big question is, why did it encrypt files… because it is not ransomware as it has no ransom note, the answer is, because they can. Interesting are also the references to the FGint library and RSA crypto, which was probably a failed experiment on behalf of the author. But RSA was not used for the encrypted documents, no it was something much more common in malicious software, actually the most common crypto apart from plain xor… RC4.
So, how would you recover such a file? Well the best method would be to use the RC4 key and use the standard RC4 implementation and decrypt the crypted document. You can find this from the separator “[+++scarface+++]” at offset 0x24a00 or 0x25000 depending on the infector version, and not forgetting to skip the last 7 0-bytes, otherwise Office will likely complain when opening the file. The RC4 key appears to be consistent in all versions: \x0d\x0a\x05\x0f\x59\x7b\x38\x5a\x5b\x36\x31\x69\x7e\x0d\x0d\x09
An alternative method for the less adventurous, or perhaps more adventurous users, if you actually run the file, it will decrypt and save a copy of the document to the same filename with “–.doc” appended to it and open it in the default application for that file type. In case nothing else works, or perhaps in case of modified crypto in newer versions and failing tools, this might be a quick way to recover an important file. Note: we do not advise this, but if you have to do this, please do it in a virtual machine without network connectivity. The actual function in the executable used for this is:
You can see in the function the separator of the file scarface, but encrypted with another common encryption function in malicious software, rot13. Other interesting strings are “SayHellotomyLittleFriend” a quote from the movie Scarface and “BreakingBad” a TV series.
The big question is of course, what is the purpose of this Trojan, one might suspect it is ransomware, but without a ransom note I guess that would be a no go. The fact that it infects shares means that it will spread to other systems that open the infected ‘documents’ on a share. Additionally HTTP based connection functionality suggests that the Trojan has additional download tasks and likely executes additional payloads on systems that have been infected. Given the Modus Operandi of this operation, it is likely that it downloads the Citadel Trojan and this entire attack was just to increase the size of the botnet through spreading of network shares. Currently however there appears to be no task defined and no additional malware is downloaded.
The interesting thing with this attack is that it appears to target NL pretty badly with over 2200 infections during the night, with the majority of the infections taking place in The Netherlands and only around 100 in Denmark and only few in other countries. The loader panel can be observed below:
All together it is a pretty interesting attack, which is obviously very visible due to the fallout with encrypted documents. And also due to the large amount of public sector organizations which were heavily affected by this attack.
Thanks to SurfRight for infected office document samples and the blog at http://www.damnthoseproblems.com/ for listing a lot of the information during the attack shared with the public.
Update:
SurfRight has provided a decryptor.
McAfee extra.dat file: https://www.medusoft.eu/w32xdoccrypt-a/#.UCNwk03N-Ao
TrendMicro has detections for Dorifel / QUERVAR here.
I found 3 POST commands to suspect and now no longerexisting domains:
POST http://brightgraph.com/sopelka1/gate.php
POST http://babbleprint.com/sopelka1/file.php
POST http://blogstruct.com/sopelka1/file.php
I happen to have a PCAP file as well of the client to proxy traffic.
POST http://brightgraph.com/sopelka1/file.php HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; BTRS6331; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Host: brightgraph.com
Content-Length: 131
Proxy-Connection: Keep-Alive
Pragma: no-cache
De afgelopen 24 uur zijn op 5 PC’s het Zbot-C virus gevonden, geblokkeerd en verwijderd door Sophos. Op een aantal pc’s werden de websites icecewwamsandi.su en jordanpowelov.su 20 minuten later bezocht waarbij de URL /ngk/file.php was. Deze laatste werd eveneens door Sophos geblokkeerd.
its a smoke curtain, meanwhile the did sent a banking virus, while you are busy cleaning your network drives, well that’s my thought about this 🙂
The Hermes C&C domains have moved to a new address at:
46.28.71.19
We suggest again to block that address.
Another new Hermes was spread via the Citadel c&c server before it went down, detection by anti-virus is again low (2/42) and it has 6 new command and control URLs built in (6 different TLDs) and those point to a new IP address.
We now suggest to block: 184.22.246.252
Last Friday (10th of August) Erwin van Harrewijn from QI reached out to us regarding HTTPS traffic he observed from the bot in his lab setup. He decoded the traffic and was able to provide the image file URL at hxxps://forum.4game.com/image.php?u=18736&XXXXXXXX.
The earlier mentioned image file at http://webwereld.nl/analyse/111452/de-code-van-dorifel-nader-bekeken.html and http://hitmanpro.wordpress.com/2012/08/11/joint-strike-force-against-dorifel/ contained command and control information identical to the command and control information present in the original bot, thanks to Erwin for saving a copy for us. As the command and control already was unreachable since Friday (10th of August) night, the clients did not receive any other commands.
Unfortunately last night the Citadel botnet became active again via a domain name which was still active and was changed to the new server. The Citadel bots received a command to download a new version of the Hermes botnet with 9 different command and control URLs built in, with all different TLDs: .name, .com, .net, .org, .pro, .ru, .in, .cc and .vn.
The new Hermes is only detected by 2 of 40 tested anti-virus products at Virustotal. CAT-Quickheal and McAfee-GW-Edition won today’s lottery, detecting it as “Suspicious” and “Heuristic.LooksLike.Win32.Suspicious.C”… Apparently this trojan is named “Suspicious” and not Hermes ;P
We suggest to block IP address: 184.82.116.202
Funny thing is, and I know this for a fact, that ING has USB restrictions active, and much more aswel… Really makes me wonder how the F this one got through…
If I was negative about every attack or trojan we analyzed, I would probably become a pretty anti social person, I guess. 🙂
Our IDS systems picked up the Citadel infection prior to it dropping XDocCrypt. As far as I know, no monitoring customer actually was affected by this. Now obviously this sounds like self-promotion, which it is… 😉
However, by continuously updating, researching and investing time in our IDS systems we can detect a lot of the threats that are very difficult to catch with only an anti-virus product for example. Now it does not replace an anti-virus product, but it does complement it. When one misses something you can still rely on the other. Some people tend to call this defense in depth, I am not a fan of the term but I guess it is in the right direction.
Unfortunately people spend a great deal of money on anti-virus, but typically not on IDS systems. An IDS system, in my personal opinion, cannot be an unmanaged device you buy and forget, people have to manage it. And some decide to outsource it to people who deal with it day to day (like Fox IT).
Now I cannot say exactly what the situation at those specific government networks was, but I guess the answer was: No, or they did, but no one acted on the warnings.
It appears that systems of the networks of UPC and Ziggo are still able to reach out to the C&C server as the TTL of the domain (reslove-dns .com) has not expired yet, and thus those clients are not connecting to the sinkhole. It should expire in 5 or 6 hours.
Interesting what is mentioned in the Kaspersky write-up:
http://www.securelist.com/en/blog/208193776/Dorifel_is_much_bigger_than_expected_and_it_s_still_active_and_growing
David Jacoby writes, “The infection rate in the Netherlands has gone up to 3113 which is an increase of over 1100 computers in just a few hours.”
We saw 2257 infections nearly over a day and half ago. Add 1100 to that and you end up with 3357. I’d suggest buying a new calculator.
After the panel screenshot we showed most of the additional clients were seen on the 9th of August 2012, with reaching 2979 on Thursday afternoon and 3129 on Friday afternoon.
As the domain name for the C&C in XDocCrypt/Dorifiel is actually now sinkholed, we can expect that there are no additional payloads pushed via this. However the clients that are still infected with Citadel or the new Hermes can get infected with a new crypted version of XDocCrypt/Dorifiel again which might not be picked up by existing anti-virus products.
“All together it is a pretty interesting attack” is much to positive. I’d say ‘an advanced attack’ or an unknown attack.
“If you were hit, you will likely start asking yourself some questions now… A properly configured IDS would have picked up the attack earlier and you would have been notified of the event.”
Ok, please explain what the IDS should have detected and what ‘properly’ is. And about “asking yourself some questions”, does the government have a “properly configured IDS”?
“The big question is of course, what is the purpose of this Trojan..?”
Well… Someone has been smart enough to mass infect an entire government network and keep the entire security industry busy with a very annoying and time intensive infection …
but….
There is no destructive payload. If it was some form of anarchistic vandalism or an attempt for terrorism, the payload would have been irreversible. Whomever build this did no serious attempts to obfuscate the keys used, knowing they would be found ..
To add to that, the payload is way to visible to make the infection stealthy. If the task was to infiltrate and steal information if would have been as non intrusive as possible to remain hidden.
Could be a amateur job gone rogue by accident?
Yet…
The virus itself was fully invisible to any scanner.. all the heuristic arithmetic, cloud scanning and other fancy methods totally failed on this one. And it spread deep… targeting (local) governments. Now that isn’t likely to be the work of an amateur..
So all in all.. it doesn’t make much sense.. unless.. its a diversion. A diversion for something entirely different??
@Mark, ik kom uit een bedrijf weg waar de netwerken perfect dicht zitten. Van de 80 bedrijfsmatige klanten zit er geen een bij die last van deze besmetting heeft gehad. De werkgever waar ik nu zit hebben er toch een aantal van bijzitten.
Wat Rob al aangeeft is dat de klant een werkbare situatie met zo min mogelijk verstoringen wil. Het liefst na die tijd ook zo min mogelijk kosten.
Dat de klant geen software kan downloaden en installeren is logisch. Deze taken horen bij de automatisering te liggen. Verder als je, je mappenstructuur op orde hebt wat doen o.a. exe bestanden en bestanden nu op een datashare. Deze horen netjes in een andere “hidden” share alleen toegankelijk voor systeembeheerders te zijn. Updates wil je automatisch geïnstalleerd hebben, java kun je ook inderdaad makkelijk centraal laten bijwerken zelfs zonder beheerdersrechten.
Today we received a task for xdoccrypt which did not download the suggested Citadel, but instead downloaded the Hermes banking trojan from 184.22.103.202 which we suggested to block in our initial post. The Hermes bot executable was uploaded on the server last night and has a shocking detection rate of 0 of 40 AV products as can be seen on Virus Total:
https://www.virustotal.com/file/5bfcce4e5c674592942c10be6654eeda3d38ee727275934275ebfc400e50f93e/analysis/1344527199/
The task was rolled out to only 100 clients suggesting that the actor is only testing the new Hermes bot. The task for download is an encrypted blob, have fun decrypting it:
RG1j4d3Y7v9QIZxK+uYHcUdbtSj88UzHUgRg45DKxfp8pz4+D3S3q0IDXmD2E3cwLHyuER5AnyE0GHcDMQygnH8lqGELEJAMHKWWHmWAG3qUMaZ4Fz1XrJuDMxc2IIyPG3N3DxyyrKMPERuhFRDkAKI4GRIIGTLlqRMYGzM6ImV0pxR3pRAzAKOGEKR2q2ZerGEyHKqbHHkhJzunG0uIp2R4X0ScrIpioJ5KM0yfJwEUHz45X2umFJEhEHt5BRWIraSPqH8mFUcnEGE2ZGuSCD==
Unfortunately that is not exactly correct, that is another trojan also active in The Netherlands which we named “torrat”. Which is probably a nice one to do a writeup about some other time 🙂
@Mark: we hebben op ons netwerk al jaren een dergelijke inrichting (m.u.v. die USB sticks dan, die mogen wel maar daar mogen geen executables op want die mogen alleen op de locale harde schijf en daar mag de gebruiker niet op schrijven).
Ik kan je verzekeren dat dit het dagelijkse werk niet beinvloedt.
Ook hebben wij die mails gehad over die vordering inzake een failissement maar die vereisten dat je je JAVA niet uptodate hebt dus die hebben hier ook niet gewerkt want JAVA is uiteraard uptodate.
Keer op keer lees je die verhalen van bedrijven en instellingen die de boel allemaal wijd open hebben staan (iedereen is admin, executables mag iedereen zelf installeren en runnen, ga zo maar door) en dan komt er altijd weer dat slappe verhaal dat dit voor de dagelijkse werkzaamheden nodig zou zijn.
Nou dat wil er bij mij niet in. De dagelijkse werkzaamheden vereisen dat het systeem stabiel, betrouwbaar en virusvrij is, niet dat jan en alleman maar software kan installeren en runnen.
@Jeroen: en nu nog een optie die werkbaar is en door klanten geaccepteerd wordt. Helaas willen ze dit soort beveiliging die het dagelijkse werk kan beinvloeden niet hebben.
The virus got in via mails with following subject : “Betreft openstaande vordering faillissementsboedel. t.b.v. de Financiele administratie”. It had an infected attachment.
Klopt dat is een file screening policy. Echter maak dit ook voor datashares. Een install share maak die hidden alleen voor domain admins.
Maak een policy aan welke usb sticks blokkeerd. Configureer een http en smtp proxy welke.exe bestanden niet toelaat. A/V gateway (wat bij dit probleem niet heeft geholpen maargoed iedere actie en restrictie helpt).
Pak RES richt dit in, sta alleen programma’s toe welke in een bedrijfsnetwerk nodig zijn. Denk dat er dan weinig meer gebeurd.
Schreeuw ik hier al een tijd.
Waarom maken mensen geen software restriction policy aan die alleen executables in het gedeelte van de C: schijf toelaat waar de gebruiker niet mag schrijven? (dus meestal alles behalve Documents and Settings)
Dan kan een gewone gebruiker tenminste geen a.exe file downloaden (naar de TEMP directory ofzo) en vervolgens uitvoeren.
missing*
You’re still messing the ” : ” in your URL 😉
Thanks for sharing though.
thanks. Fixed. That was actually the only thing I added to this blog myself 🙁
Mistake in the decryptor url