Boldizsár Bencsáth (Boldi) will have a presentation at Kaspersky Security Analyst Summit on 09/03/2018 Friday. The presentation is based on a technical paper which describes findings about modules and information in April 2017 Shadow Brokers leak. The particular information categorizes external APT attackers and calls them SIG1 to SIG45. For more, please check the paper. Please do not forget The corresponding external sample hash list text file.
Category: APT
Duqu 2.0
Stuxnet is probably the most well-known malware of our times. Its fame stems from the facts that it targeted a very specific industrial facility, namely a uranium enrichment plant in Iran, it aimed at physical destruction of uranium centrifuges, and it apparently accomplished its mission successfully. In addition to all these characteristics, IT security experts also appreciate its technical sophistication and the zero-day exploits that it used. Stuxnet was also an alarm to the developed world: it shed light on the capabilities of advanced attackers, and at the same time, on the numerous weaknesses of our computing infrastructure. Putting these two together, people started to feel hopelessly vulnerable.
Yet, unfortunately, Stuxnet is not a unique example for a highly sophisticated targeted threat, but there are numerous other pieces of malware of similar kind, including Duqu, Flame, Regin,… Among those, Duqu is particularly interesting, not only because we discovered it back in 2011, but because our analysis pointed out that – while Duqu’s objective is different – it has very strong similarities to Stuxnet in terms of architecture, code, and methods to achieve stealthiness. Today, it is widely believed within the IT security community that Duqu was created by the same attackers who created Stuxnet.
And now we have a new member of the same family!
By courtesy of Kaspersky Lab, in late May 2015 we received samples (more specifically two DLL files) of a new threat, with the hint that this might be related to the Duqu attacks. Our common understanding was that it would be interesting to figure out whether this new threat, dubbed “Duqu 2.0,” is indeed related to the old Duqu attack, and we in the CrySyS Lab should carry out an independent analysis for answering this question. In order to be able to perform an unbiased investigation, Kaspersky Lab did not share more details on their findings with us. The blog post on Duqu 2.0 from Kaspersky Lab can be found at https://securelist.com/blog/research/70504/the-mystery-of-duqu-2-0-a-sophisticated-cyberespionage-actor-returns/
After analyzing the samples that we received, we think that the attackers behind the Duqu malware are back and active. They reused code and ideas from Duqu in the new Duqu 2.0 malware, but at the same time, they also made modifications in order to render Duqu 2.0 undetectable by the old detection methods.
In our full report, available at http://www.crysys.hu/duqu2/duqu2.pdf, we point out numerous similarities that we discovered between Duqu and Duqu 2.0, including the following:
- Similar string decryption routines related to Anti-Virus product strings
- Similar methods, magic number, bug and file format related to files encrypted with AES by both threats
- Same non-standard CBC mode AES encryption used by both threats
- Extremely similar logging module with exactly the same magic numbers
- Similar C++-like coding and compiling style
Naturally, our report contains supporting details and analysis for all the similarities listed above.
Actually, it is not surprising that the attackers reused their old tools, as they have already invested a lot of design and development effort in them. What is perhaps more interesting that they could tweak and optimize their malware such that it was not detected by state-of-the-art defense mechanisms. In part, this is again due to the information asymmetry between the attackers and the defenders: the attackers had the possibility to read all published analysis reports about Duqu, so they knew what the defenders were prepared for, while the defenders typically know very little about the methods of the attackers. This seems to lead to an endless cat-and-mouse game, where the attackers always have an advantage. This also raises the far reaching questions of how much information the defenders should publish about newly discovered threats, and whether security-by-obscurity is perhaps not such an undesirable approach after all.
Anti-APT product test sample "BAB0" is shared for security experts
As we promised in our previous blog post, we release BAB0, the test sample that bypassed all 5 anti-APT products that we tested earlier in this year.
BAB0 is written in C++, and it has a server side written in PHP. BAB0 is downloaded by the victim as part of an HTML page, where it is actually hidden in an image with steganography. The downloaded page also contains scripts that extract an executable from the image when the user clicks on something that appears to be a download button. The image has already been uploaded to Virus Total with 0/54 hits. Once BAB0 is running, it can communicate with a remote C&C server. To hide the C&C network traffic, BAB0 simulates a user clicking on links in a web forum, and downloads full HTML pages with CSS style sheets and images. The real C&C traffic is hidden inside these HTTP requests and responses. BAB0 allows for file download to the victim and file upload to the server, as well as remote execution of commands on the infected computer.
We release the BAB0 sample because we believe this is the most effective way of pushing the vendors to address this and similar threats in future releases of their products and to raise awareness about the fact there are no silver-bullet products that protect against everything possible. The sample that we are releasing now consists of the PNG image that contains the BAB0 executable and the scripts that extract BAB0 from the image. We do not release the source code of BAB0, neither we release the server side of the sample. The sample tries to connect to our server, but no real attacking functionality is deployed on it. In order not to harm end-users, we shared the information being released now with anti-APT vendors (not just the ones that we have tested) almost three weeks ago, when we released the report on our test results. We also shared the BAB0 sample with other security companies who expressed their interest after reading our report. So vendors and security companies had sufficient time to prepare for the public release of BAB0 and protect their customers.
Download BAB0 sample
Disclaimer: This sample is not a malware, but it is a possibly unwanted program. Its functionality is similar to those found in real threats. If you run our sample, it will start communicating with our server, but our server does not send any command to the particular sample program and we do not conduct anything harmfuly for anybody who runs this sample. This sample is designed for security experts to be run in sandbox environment or to analyze its capabilities. We do not prohibit reverse engineering of the sample, and we give explicit permission to run it by security professionals. However, intellectual propery rights on the software and the incorporated ideas belong to CrySyS Lab, part of the Budapest University of Technology and Economics. The sample is provided in an AS-IS basis, as it is disclosed for free, we do not give any warranty, we do not guarantee it cannot cause harm in any IT system. This is a prototype work. If you are not confident how to work with it, please do not download. Authors and the institution take no responsibility on any damages related to the sample or any derivative work.
According to our understanding, this demonstrative work does not contain any exploit, it is not a weapon and not considered as dual-use product according to Hungarian and EU laws. If you have questions or problems, please contact us.
PS. Easter egg:
Babo means hobbit in Hungarian, and we named our sample so, because it was designed to stealthily bypass all state-of-the-art defenses, while actually being very simple, and this is similar to the way Frodo, the hobbit, managed to bypass all defenses of the fearsome Sauron in the Lord of the Rings.
ps2. before you ask. Password is “infected” as usual in the industry.
New anti-APT tools are no silver bullets: An independent test of APT attack detection appliances
New anti-APT tools are no silver bullets:
An independent test of APT attack detection appliances
CrySyS Lab, BME http://www.crysys.hu/
MRG-Effitas https://www.mrg-effitas.com/
November 26, 2014.
The term Advanced Persistent Threat (APT) refers to a potential attacker that has the capability and the intent to carry out advanced attacks against specific high profile targets in order to compromise their systems and maintain permanent control over them in a stealthy manner. APT attacks often rely on new malware, which is not yet known to and recognized by traditional anti-virus products. Therefore, a range of new solutions, specifically designed to detect APT attacks, have appeared on the market in the recent past, including Cisco’s SourceFire, Checkpoint, Damballa, Fidelis XPS, FireEye, Fortinet, LastLine, Palo Alto’s WildFire, Trend Micro’s Deep Discovery and Websense.
While these tools are useful, determining their real effectiveness is challenging, because measuring their detection rate would require testing them with new, previously unseen malware samples with characteristics similar to those of advanced malware used by APT attackers. Developing such test samples require special expertise and experience obtained either through the development of advanced targeted malware or at least through extensive analysis of known samples.
We in the CrySyS Lab, together with our colleagues at MRG Effitas, decided to join our forces and perform a test of leading APT attack detection tools using custom developed samples. MRG Effitas has a lot of experience in testing anti-virus products, while the CrySyS Lab has a very good understanding of APT attacks gained through the analysis of many targeted malware campaigns. Therefore, collaborating and bringing together our complementary sets of expertise looked like a promising idea. Our goal was not to determine the detection rates of different APT attack detection products, because that would have required testing with a large set of custom developed malware samples, which was not feasible to obtain within the limited time frame and with the limited resources we had for the test. Instead, our goal was simply to implement some ideas we had for bypassing cutting-edge APT attack detection tools without actually being detected, and to test if our ideas really work in practice.
We developed 4 custom samples in 2 weeks and without access to any APT attack detection tools during the development, and then later tested with these samples 5 APT attack detection solutions in Q3 2014. All 5 tested products are well-established in the market; however, we cannot mention vendor names publicly. The result of the test was alarming:
– one of our 4 custom samples bypassed all 5 products,
– another sample of the remaining 3 samples bypassed 3 products,
– only the two simplest samples have been detected by the tested products, and even those triggered alarms with low severity in some cases.
We made the full report (https://blog.mrg-effitas.com/wp-content/uploads/2014/11/Crysys_MRG_APT_detection_test_2014.pdf) on our test available online. It contains our test methodology, including a brief description of each sample we developed for the purpose of the test, and we also present in it the test results in more details. We decided to publish this report for multiple reasons:
– First of all, we believe that our test was more appropriate for evaluating the detection capabilities of APT attack detection tools than some earlier, heavily criticized tests were, because unlike earlier tests, we used custom developed samples that resemble the malware used in APT attacks.
– Second, some of the products that we tested seem to be overestimated by the users who believe that those products are silver bullets. On the other hand, we have already emphasized at multiple occasions that these products can and will be bypassed by determined attackers. Our test is a clear proof of this, and if we could do that, then APT attackers will also be able to do that, if they have not done so yet.
– Third, we observed that some vendors of APT attack detection tools are often reluctant to participate in tests that try to evaluate the effectiveness of their products. On the one hand, we understand their caution, but on the other hand, we all know that the approach of security by obscurity has its own pitfalls. By publishing this report, we would like to encourage anti-APT tool vendors to participate in independent tests more readily and cooperatively, in order to have sufficient amount of convincing results about their products, based on which well-informed decisions can be made by the users.
– And last but not least, we believe that there are significant differences in the APT detection capabilities of the tested products, and users should be aware that not all vendors provide the same detection rate.
The test sample that bypassed all 5 tested products was developed by the CrySyS Lab. It is a custom designed sample written in C++ with a server side written in PHP. It was designed to be as stealthy as possible. It is downloaded by the victim as part of an HTML page, where it is actually hidden in an image with steganography. The downloaded page also contains scripts that extract an executable from the image when the user clicks on something that appears to be a download button. Once the sample is running, it can communicate with a remote C&C server. To hide the C&C network traffic, the sample simulates a user clicking on links in a web forum, and downloads full HTML pages with CSS style sheets and images. The real C&C traffic is hidden inside these HTTP requests. The sample allows for file download from and upload to the C&C server, as well as remote execution of commands on the victim computer.
We named this test sample BAB0, which (babo) means hobbit in Hungarian, as its objective was to stealthily bypass all state-of-the-art defenses, while actually being very simple, and this situation shows a parallel to the story of the Lord of the Rings, where Frodo, the small hobbit managed to bypass all defenses of the fearsome Sauron, the Lord of Mordor, and reached Amon Amarth, where the One Ring was finally destroyed.
We have a strong intention to publish BAB0 in the near future. This may seem to be controversial, as making the details of BAB0 publicly available can help attackers. We have a different opinion: Powerful attackers have probably been using already similar tricks, but apparently detection tools are not yet prepared to cope with them. By publishing BAB0, we push anti-APT vendors to strengthen their products, which will ultimately make the attackers’ job harder.
For further information, please contact either Zoltan Balázs (Zoltan.Balazs@mrg-effitas.com) or Levente Buttyán (buttyan@crysys.hu). Please note that we cannot provide any vendor specific information about the tests, but we can help organizations to test the products integrated in their environment.
The Epic Turla Operation: Information on Command and Control Server infrastructure
Together with international partners, we have investigated the Turla/Uroburos/Snake related Epic/Wipbot/TavDig/Wordlcupsec operations and the command and control server infrastructure of it. Although hundreds of servers related to the threats were discovered by the community, most of them are not alive as of the analysis. We tried to obtain as much information as possible on the operation, structure and data related to these servers.
Our findings are summarized in our short report
For further information please also check Kaspersky Securelist Post,Symantec blog entry too.
MiniDuke 2 (CosmicDuke)
*UPDATE: fixed 4 hashes – 1 character was missing
*UPDATE: 93deb98d89b8acfa4115ce1ca89ac26a45aae4563c3a454bf8b2a26886f40a46 most likely is a False Positive (FP) and not evil
*UPDATE: 8290b324f5cdb5c3ea17fa48a74bc11c856f0da0b049d07d9316d161f71f26a5 is old miniduke sample from 2013
February, 2013 we conducted research together with Kaspersky Lab on a malware campaign called MiniDuke. The research on the threat has not stopped. In 2014 Eset published MiniDuke still duking it out information on related attacks, which we can confirm and for which we’ve sent out some additional information towards the incident response community.
Lately, F-Secure published on CosmicDuke ( see CosmicDuke – Cosmu with a twist of MiniDuke.
Today, Kaspersky Lab also added more insight ( Miniduke is back: Nemesis Gemina and the Botgen Studio) on the threat.
As the information on the threat is now publicly available, we also release some additional hints that can help you to find infections (indicators of compromise).
Hosts:
194.69.193.147
69.89.31.57
72.167.13.78
192.155.88.252
188.241.115.41
31.44.186.38
94.242.199.88
212.76.128.149
91.224.141.235
199.231.188.109
46.246.120.178
178.21.172.157
188.116.32.164
64.18.143.90
209.99.17.27
212.7.198.107
User names for FTP authentication:
upgor
dlgor
kweku
menelaos
heres
lorine
madonna
johan
horus
lofter
adair
Related file hashes:
8778738067b37380d3d05d3eb6fb39478fc34a209959639db752863ea52776e3
58b6119d24eddc536af94c4cfeb28efe78d42856c8436a69a77fcc9f15414b6c
63035a73a19b2b2033d6ea3a269ba175b3e80ef31b914bb247a829efba30fd01
974e1deb961d2a9228444e02db21943072f981045b026cd171c7ece294351c36
2f7a286504336eb8765e68efbf8447e147585c02066a4f85102f4f6b93bc35cb
bf0d84fdc087c3f37cfab3f0492ec8f04de98e5a4c823d5f60851cc5eef438de
145688e8ebccb088da78216f4661c85e93da376da6ea707bb6b7b746ad47f4e1
880ae80fdc874002a6d9c807802794d4a35c384551d73bb36277b2f1e63d67e2
47f3405ab0da5af125bcc6ebb6d17a1573b090c54d7a0a00630ec170ccc4b9d1
5b50e26a01b320f05d66727e9d220d5858cdac203ff62e4b9ced1cafc2683637
9e3c407d3bbf2a69cf6509994ffb17b45c58c3adaf3dc876b23e7d0575e24ca0
7e371cd323898e403df7a80add34d791e160e443bcd2d02f27ddc0c04ba1bdab
9ce93f04dbb6a3b833f1146a54dadfdc224fdf24e3cca1f8a1eb4e902d597ff6
1fe180e5a40ed462a6544f4e428b996043decfdf863980501c51cbd7e3bd96c6
3161f7389ff0f71484dd8a6e2583cc0ada73f79fd4e6ef8b772fa2a738284d3a
5dc69a1fefa3a050b36a2c3aff037660010824aa5d56a2e03babedd7a53b443e
70fd11726810e30e4dc34a530edf2b349f913b1e492c73eb1115204fcdd3cd59
--> likely False Positive: 93deb98d89b8acfa4115ce1ca89ac26a45aae4563c3a454bf8b2a26886f40a46
c4c4776bed7e69bf8efacb3f6904f8c06889680c590ec728ae59c0ff6e8cfa05
64e3a2bba82027dd6ff631fa5890a7ba8331b62a0a4c0b1ca24d143c2b61c323
9c2562e05eb940ae8d73c9baa7cfe85cb3ec619689227f65e4fbeeb3fec598ad
7d1ca4a7684877753d5f4ca2d7599c7d87f231a7215945ef17447309f25da62a
7e371cd323898e403df7a80add34d791e160e443bcd2d02f27ddc0c04ba1bdab
dad4c4aea24f2bd3e2f4b93bf782ebef70e8fdf930aff25a3e1b85a717314aa0
d19acbc3686e05726ca572ff455519db9d7e0707450a3c9cb804c0f0fe6a0d7a
e94b97716d354a21dcff365e91d2f445fe2cac6a01a38f6dd1c921c57eeafef4
7e9c0bda27bbc80d947bc0c6ce29a19c824288d2b481f92a1637b7b8dfc8b81c
8c6c57f7e9c81fcf194d17a752f8da4295fab5dad8eb79bd289256b9cdb7415e
3f1ec44b421061173f7cbdbe2b4b0ec9457fdb146e126dc2a0763a69a452ce3c
ceff70f02f18ef4c1fa0d1b07b9462e04e57e98c4ea91e6a8ff29478197c4742
4ea49a33977a93aed17fef02a54ee8f6138d005259cf55c32cab3e23480053cf
bdc9c247ad790ec60ffd26455e49425cb1fe32f58623d9ac470a7104a0592dd3
--> This is old miniduke sample 8290b324f5cdb5c3ea17fa48a74bc11c856f0da0b049d07d9316d161f71f26a5
51b4e69183f3d02124f3314cc64a7869425f053d8021c74c12f21d7c2afe2163
bd4928921ddadb44f9f573da61dac034533bf14fe38acd5754f3ccec1d566300
64e3a2bba82027dd6ff631fa5890a7ba8331b62a0a4c0b1ca24d143c2b61c323
14ebcb27436b338d63e731b5c369c5d33c38ce5066f995093bc6826bd799103b
3e889cd495e008760fd12751d6d45cadf8a7280c4545f2ebe469f84b9b77c835
1590bdbaff2c178387e924b689b030057b4cbd2865e9c4dd3886a8791ac8e4ee
cb4fc98f33021ac890e717f8927bfcaddaaacac9bf9be71578c7baaf9f9cbf02
TeamSpy – Obshie manevri. Ispolzovat' tolko s razreshenija S-a
The CrySyS Lab, Budapest has been notified by the Hungarian National Security Authority (www.nbf.hu) about the detection of an ongoing high profile targeted attack affecting our home country, Hungary. During our investigation of the incident, we discovered a number of C&C servers, and a large number of malware samples that have been used in multiple attacks campaigns in the last couple of years. Indeed, the collected evidences suggest that part of the attack toolkit we discovered was used back in 2010. It seems that the main objective of the attackers was information gathering from the infected computers. Many of the victims appear to be ordinary users, but some of the victims are high profile industrial, research, or diplomatic targets, including the case that triggered our investigation. As part of the attackers’ activities is based on misusing the TeamViewer remote access tool, we named the entire malicious toolkit TeamSpy.
We detail the findings in our technical report.
As mentioned above, a distinct feature of the attack is the abuse of the legitimate TeamViewer remote access tool. The attackers install an original, legitimate TeamViewer instance on the victim computer, but they modify its behavior with DLL hijacking, and they obtain remote access to the victim computers in real-time. Therefore, the attackers are not only able to remotely observe the infected computers, but they can also misuse TeamViewer to install other tools to obtain important information, files, and other data from the victim.
The collected evidences suggest that attacks have been carried out in multiple campaigns. In addition to the TeamViewer based campaigns, we also saw signs indicating a number of older attacks based on proprietary malware with C&C server based control. We estimate the number of distinct campaigns to be in the order of tens.
The activities of the attackers might be related to other known attack campaigns, like the TeamBot/Sheldor campaign (banking cyber-crime), as we describe later in this document. Despite of this relation to cyber-crime activities, we believe TeamSpy has been used in high-profile targeted attacks too. This is underpinned by the following observations:
• In case of the Hungarian incident, the signs clearly show that the target is high-profile.
• Some malware samples were created just for the retrieval of specific office documents (see the analysis of module 2016_11.txt below) whose name (e.g. “gaza tunnel”) indicate that the target is probably high-profile.
• The telemetry revealed additional high-profile victims outside Hungary. Indeed, multiple victims were found in Iran, including victims at http://www.sashiraz.co.ir, which is an electronics company with government background. The possible date of infection for this victim is from 2010.
• Some tools used by the attackers run traceroute to an unknown host on a subnet, where some other hosts belong to the Ministry of Foreign Affairs of Uzbeghistan.
• Some tools used in the attacks look for files matching the following templates saidumlo secret.* секрет.* парол.* .xls *.pdf *.pgp *pass.* *.rtf *.doc. This list shows the interest of the attackers in “secret” and “password” documents. In addition, the attackers’ interest in .pgp and .p12 files indicates that they were looking not only for passwords, but also for cryptographic keys, which goes beyond attacks against ordinary users.
During our investigation, we uncovered a large set of malware samples that were probably utilized back in the past; hence, our analysis can also shed light on older malware campaigns and might help victims to reveal incidents that are several years old. Therefore, the information disclosed in this report could be used to perform a longitudinal study of targeted malware attacks.
While identity of most of the victims could not be revealed, we have information on some high-profile victims, e.g.:
- 11/2012: Hungarian high profile governmental victim.
- 03/2013: Embassy of NATO/EU state in Russia
- 04/2010: Electronics company in Middle-East, Govt. background
- 03/2013: Multiple research/educational organizations in France and Belgium
- 03/2013: Industrial manufacturer in Russia
New miniduke samples hashes
6a2c682163f7bd572e5b32861f339749a5e6338f *bg_efa.gif
5f9d29ff787ee57cf1efc50ba912b8170d877c8c *bg_efa.gif_dec
7594baa64a94147fe4a480bb1f05421499bafbfa *bg_efd.gif
a26b92e612d3a282a294b9fed313998270fb3de8 *bg_efd.gif_dec
3bcd6d97a08406b09c8a1754fc2813b8c31305ec *bg_efssa.gif
3fc74035fefe01a0f88266e1ea6982568db37969 *bg_efssa.gif_dec
a725f94d95ff667657186295c47d4dc487ec3dec *bg_ght.gif
ffabcf3e947aaeefb52ec4385ceb339bc3bbc4a9 *bg_ght.gif_dec
065624d59c2bf607df10bfec1fb104fee09f9dd6 *bg_ldf.gif
5deb581700d373b5890e3bd684306473d34d02cc *bg_ldf.gif_dec
43ef986db9a1c9ff7fd0d84d8495a4f3d9e82543 *bg_lef.gif
131b72a8d950bcf3de273f8a6aac56f8884b5e1e *bg_lef.gif_dec
03ed5e370513eb4d357fbc391ce57c75d179551e *bg_ler.gif
726924e450ffb50c6cd600dca35e8353e0d42c8b *bg_ler.gif_dec
6799b0d8e9ec469fa455b01ffde63b8c *bg_efa.gif
ac1c9fd4c6ba5ef3673a871960a48622 *bg_efa.gif_dec
665eb69b1a917b5c8e3588efcc258539 *bg_efd.gif
a401042e3276bcb4d4012da392e6374a *bg_efd.gif_dec
9253eae9b443f67b12a2b399f54bb2cb *bg_efssa.gif
f3de8feb3ea4f367053755123389c1ae *bg_efssa.gif_dec
9fee2fcc92b74e0fb65dc42214ae9952 *bg_ght.gif
41d4eb3aab5acd87657c4b9ea9432d9b *bg_ght.gif_dec
37307978b24a9185ec8b4ca14afefd99 *bg_ldf.gif
e92584a5624b2fa044a671198c834221 *bg_ldf.gif_dec
9c2433c9768c43a8f4ae0fc72b1cc1cc *bg_lef.gif
0f76f6e9d7659d4fb087d18bec1bd48f *bg_lef.gif_dec
535011c4887a098fc67adb5eebc64525 *bg_ler.gif
3b83c9bb67ce8166c0312b1abe9cd5a7 *bg_ler.gif_dec
Miniduke
Earlier in February 2013, FireEye announced the discovery of a new malware that exploited a 0-day vulnerability in Adobe Reader. Now, we announce another, as yet unknown malware that exploits the same Adobe Reader vulnerability (CVE-2013-0640).
This new malware was named Miniduke by Kaspersky Labs with whom we carried out its first analysis. Our participation in this research was justified by a detected Hungarian incident. A detailed report on the results of our joint efforts has been published by Kaspersky Labs on their Securelist blog site. That report describes what we currently know about the operation of Miniduke including its stages, and also information on the C&C infrastructure and communications. We have published another report from CrySys Lab that contains information on the indicators of Miniduke infections and gives specific hints on its detection. This blog entry is a brief excerpt of our report.
The available malware samples are highly obfuscated, and compiled by a polymorphic compiler. The attackers were able to produce new variants with only a few minutes difference between compile times. Therefore, the number of distinct samples could be very large. Hashes of known samples are published in our detailed report on indicators.
Due to a large number of compiled samples, there is a high chance that the current version is difficult to detect by signatures. Yet, there are common features in the samples that can be used to identify the malware components.
In every case we encountered, the “Program Files/Startup” contains a file with .lnk extension after installation. This is used to start up the malware after the computer is rebooted.
A not fully cross-checked information is that, during installation, the malware will be copied in two copies on the system and the two executables differ. This might mean that the executable modifies itself. For example, we recovered the following two files:
md5sum base.cat :113e6fc85317fdd135e3f5f19e6c7a58 *base.cat
md5sum ~6rld.tmp : c786a4cdfe08dbe7c64972a14669c4d1 *~6rld.tmp
where base.cat is the startup file, which is created based on ~6lrd.tmp. base.cat is stored in the “All users” directory, whereas ~6lrd.tmp is stored in a user’s directory, e.g., in the guest user directory as “C:\Documents and Settings\guest\Local Settings\Application Data\~6rld.tmp”. This user directory contains at least one more file, update.cmd, with a specific content that could be used for detection.
As for stage 3 of the attack, it is important to note that it is not yet analyized deeply. So once a victim downloads the ~300k long piece of stage 3 code, we don’t know what happens with the previous stages, and we have no information about detections once this stage is reached, except the usage of the C&C server news.grouptumbler.com. Another variant of the stage 3 code is much smaller, only 14k long, and connects to a server in Turkey.
We have identified the following servers delivering stage 2 and stage 3 code to victims:
arabooks.ch 194.38.160.153 / Switzerland
artas.org 95.128.72.24 / France
tsoftonline.com 72.34.47.186 / United States
www.eamtm.com 188.40.99.143 / Germany
The C&C server used by stage 3 of the malware is news.grouptumbler.com (IP 200.63.46.23) and it is located in Panama.
There are multiple layers of C&C communications in the malware. First, the malware uses Google search to receive information from its master. Then, it uses the Twitter messaging service looking for the twits of a specific Twitter user. Commands received via this channel trigger the download of stage 2 and stage 3 code.
Basic detection can be based on the queries that are initiated by the victim computer within seconds:
www.google.com – port TCP/80 - HTTP
twitter.com –port TCP/443 - SSL
www.geoiptool.com –port TCP/80 - HTTP
Known search strings in Google search can also be used to detect the malware:
lUFEfiHKljfLKWPR
HkyeiIDKiroLaKYr
lUFEfiHKDroLaKYr
Unfortunately, these strings are most likely unique to each C&C server or victim, thus unknown samples might use other strings, but possibly with the same length.
Examples for twits containing the URL of the C&C server are shown below:
The weather is good today. Sunny! uri!wp07VkkxYt3Mne5uiDkz4Il/Iw48Ge/EWg==
Albert, my cousin. He is working hard. uri!wp07VkkxYmfNkwN2nBmx4ch/Iu2c+GJow39HbphL
My native town was ruined by tornado. uri!wp07VkkxYt3Md/JOnLhzRL2FJjY8l2It
The malware also sends a query to the geoiptool. An example is shown below:
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0; en-US; Trident/5.0)
Host: www.geoiptool.com
The malware retrieves the URL of the stage 2/3 delivery C&C server from Twitter messages as described above. Then, we can observe the first query from the victim towards the server. This query contains pure HTTP traffic on port 80 to the server following the template below.
GET /original/path/shortname/index.php?e=aaaaaaaaa
where:
- shortname can be a number of strings, generally human readable (e.g. lib, engine, forum, forumengine etc.)
- “e=” is not constant, can be anything, but generally 1-2 letters long
- aaaaaaaaa stands for some Base64-like text (see details below)
- the servers used are assumed to be legitimate sites, just hacked by the attackers.
Based on this format, we can detect a valid query as follows:
The name of the first GET parameter should be discarded
- this means “e=” is not important
- we saw only one GET parameter, queries with multiple parameters are likely not used
For detection, the Base64-like string “aaa…” should be first modified as follows:
- “-” should be replaced by “+”
- “_” should be replaced by “/”
This results in correct Base64 encoding, which can be decoded with library functions such as base64_decode. After decoding, a string of data, partially binary, will be available. Parts are separated by the delimiter character “|”. The format and a numerical example are below:
binary data ( ~100 bytes)|numerical ID ( ~10 digits)|version number
e.g.,
binary data|5551115551|1.13
As the binary data itself may contain the ”|” character, parsing should start from the end (i.e., the numerical ID starts from the second “|” character from the end). In additional, the ID length may vary (not fully confirmed), but it seems to be around 10 digits. Finally, the version number always follows the pattern “one digit.two digits”, e.g., 1.1X 3.1X.
The C&C server’s response – if it sends encrypted files – is a GIF file containing a small icon, and after that, the malware. For stage 3, the file downloaded has a larger size (~300KB). It also begins with a GIF header, but that header is only 13 bytes long, and then starts the encrypted executable (see picture above).
Encryption related to Duqu font expoit (CVE-2011-3402)
You remember the Duqu font related exploit and shell code in the dropper? Yes, that’s the exploit that was recently used in many exploit kits.
First of all, this is a kernel level exploit, it should be kept in mind while checking code.
The original dropper had a decryptor for the stage1 of shell code:
void __fastcall sub_1500(int a1, int a2)
{
int v2; // eax@2
int v3; // ecx@2
int v4; // eax@5
int i; // eax@5
if ( !dword_14FC )
{
v2 = 0;
dword_14FC = 1;
v3 = (unsigned __int8)dword_14F8;
while ( v2 != dword_14F8 )
{
LOBYTE(a2) = v2 ^ *((_BYTE *)sub_17C + v2) ^ v3;
*((_BYTE *)sub_17C + v2) = a2;
a2 = (unsigned __int8)a2;
++v2;
v3 ^= a2;
}
v4 = sub_158C(v2, a2, v3);
sub_17C(v4 - (_DWORD)sub_17C);
for ( i = 0; i != dword_14F8; ++i )
*((_BYTE *)sub_17C + i) = 0;
}
}
It’s not a complicated obfustation/crypto, the interesting thing is that it is not like the ones for Flame. The most similar thing is Stuxnet’s modules’s crypto, maybe later discussed.
The next level is still obfuscated. ntoskrnl.exe function calls are stored in a table by hash of the function call name, just like calls are obfuscated in other parts of Duqu. This is not unusal, but shows specific care on the module.
The hash-function relation table is costructed like under:
seg000:00001043 mov [esi+10h], eax
seg000:00001046 jz loc_11B2
seg000:0000104C push ecx
seg000:0000104D push ecx
seg000:0000104E push 0BF5CA508h ; ExAllocatePool, hash:bf5ca508
seg000:00001053 push edi
seg000:00001054 call sub_7FD
seg000:00001059 add esp, 10h
seg000:0000105C test eax, eax
seg000:0000105E mov [esi+14h], eax
seg000:00001061 jz loc_11B2
seg000:00001067 push edx
seg000:00001068 push edx
seg000:00001069 push 2973E9CCh ; export name: ExFreePool, hash:2973e9cc
seg000:0000106E push edi
seg000:0000106F call sub_7FD
seg000:00001074 add esp, 10h
seg000:00001077 test eax, eax
seg000:00001079 mov [esi+18h], eax
Note the constants 2973ECCh and similar. These are identifiers of ntoskrnl.exe exports (specific functions).
The hash calculation is done like this:
for ( i = 0; ; i += 7 * i * i + 12 * v8 + 17 * v8 * v8 )
{
v8 = (_BYTE *)v3;
if ( !(_BYTE *)v3 )
break;
++v3;
}
It’s not like encryption/obfuscation code for FLame. Maybe the exploit creators also provided this stage to the customers.
Based on this code function calls in the exploit can be recovered. And still, this is just one step among others to fully understand how original Duqu dropper worked…
A few sample values for hashes based on the function described above:
export name: AlpcInitializeMessageAttribute, hash:f8ab4ead
export name: CcCanIWrite, hash:c833f901
export name: CcCoherencyFlushAndPurgeCache, hash:41ab559d
export name: CcCopyRead, hash:99b1f488
export name: CcCopyWrite, hash:96bc06d5
export name: CcCopyWriteWontFlush, hash:210fdfb4
export name: CcDeferWrite, hash:038897a1
export name: CcFastCopyRead, hash:1e3c8f5c
export name: CcFastCopyWrite, hash:c1874039
export name: CcFastMdlReadWait, hash:2eea7438
export name: CcFlushCache, hash:0a30abdd
export name: CcGetDirtyPages, hash:cc24ab45
export name: CcGetFileObjectFromBcb, hash:8244f064
export name: CcGetFileObjectFromSectionPtrs, hash:9406fe99
… possibly TBC…