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.
Author: Boldizsar Bencsath
A pizzás ügy margójára
Kedves Diákok!
Talán hozzátok is elért a veszprémi pizzéria weboldalát tároló szerver feltöréséről, az arról ellopott adatokról való hír. Erről több olvasható például itt a népszaván.
Nagyon fontos elmondanunk, hogy a támadó -még ha a jó szándék vezérelte is- borzasztóan etikátlanul, törvénytelenül és veszélyesen járt el, és nagyon szeretnénk, ha az adatbiztonsággal foglalkozó hallgatóink soha nem követnének el hasonló hibákat.
Internetes weboldalak biztonsági tesztelésére csakis felkérés alapján, megfelelő megállapodás szerint kerülhet sor- Egy ilyen megállapodás rögzítheti az alkalmazható eszközöket, az ellenőrizhető célpontok körét, az ellenőrzés időbeli korlátozását, és számos más dolgot. Ilyen megállapodás hiányában már a feltörési kísérletek is jogszabályokba ütköznek, de egy sikeres feltörés alapesetben is 3 évig terjedő szabadságvesztéssel járhat!
Az elkövető ráadásul adatokat lopott, ráadásul ezeket közre is adta. Újabb két dolog, ami miatt súlyosan megütheti a bokáját, és akkor még nem beszéltünk a webszolgáltatónak és a cégeknek okozott kárról!
Fontos megjegyezni: Ha igaz a hacker állítása, hogy a szerver katasztrofális biztonsági állapotban van, az szintén elfogadhatatlan, és veszélyezteti emberek személyes adatait, amivel a cég az új adatvédelmi rendelkezések bevezetésével komoly büntetést is kaphatna, és egyetértünk abban is, hogy az ilyen cégeket jó lenne kényszeríteni arra, hogy biztonságukat megfelelően valósítsák meg.
Ugyanakkor nem lehet önbíráskodó módon, törvénytelenül, kérés nélkül ilyen cselekedeteket elkövetni. Még akkor sem, ha valaki nem lop el adatot, és nem publikálja azokat.
Ha a diákjaink valamikor adatbiztonsági sérülékenység jeleit, nyomait látják, vagy esetleg bizonyítékot is szereznek erről (remélhetően véletlenül), úgy a helyes eljárás a szolgáltató, kiszolgáló tulajdonos stb. haladéktalan és teljes körű tájékoztatása. Ha ez nem tehető meg közvetlenül, akkor javasolt a megfelelő, kapcsolódó CERT, kormányzat esetén pl. a GovCERT, a Kormányzati Eseménykezelő Központ tájékoztatása, akik segíteni tudnak a komnmuniákcióban, és a problémák megfelelő kezelésében, jogszerűen, úgy, hogy az mindannyiunk javára váljon.
Kérjük a diákokat, hogy ne próbálják meg utánozni a támadót, nem éri meg a 2 perc hírnév!
Update on the Fancy Bear Android malware (poprd30.apk)
About the APK:
The APK file, that was investigated by Crowd Strike and us is actually corrupt, unzipping yields two warnings and a CRC Error.
$ unzip 6f7523d3019fa190499f327211e01fcb.apk
Archive: 6f7523d3019fa190499f327211e01fcb.apk
warning [6f7523d3019fa190499f327211e01fcb.apk]: 1 extra byte at beginning or within zipfile
(attempting to process anyway)
file #1: bad zipfile offset (local header sig): 1
(attempting to re-compensate)
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
inflating: AndroidManifest.xml
inflating: classes.dex
extracting: res/drawable-hdpi/dmk.png
extracting: res/drawable-hdpi/ic_launcher.png
extracting: res/drawable-mdpi/fon_1.jpg
extracting: res/drawable-mdpi/fon_2.png
extracting: res/drawable-mdpi/fon_3.png
extracting: res/drawable-mdpi/ic_action_search.png
extracting: res/drawable-mdpi/ic_launcher.png
extracting: res/drawable-mdpi/panel_2.gif
extracting: res/drawable-mdpi/panel_4.png
extracting: res/drawable-mdpi/panel_5.png
extracting: res/drawable-mdpi/panel_6.png
extracting: res/drawable-mdpi/panel_7.png
extracting: res/drawable-mdpi/warnings.png bad CRC 73cded37 (should be 902e9cdb)
file #19: bad zipfile offset (local header sig): 660433
(attempting to re-compensate)
extracting: res/drawable-xhdpi/ic_launcher.png
extracting: res/drawable-xxhdpi/ic_launcher.png
inflating: res/layout/activity_reg_form.xml
inflating: res/layout/byleten.xml
inflating: res/layout/dan_dmk.xml
inflating: res/layout/dan_meteo.xml
inflating: res/layout/dan_vr_2.xml
inflating: res/layout/meteo_podg_form.xml
inflating: res/layout/o_avtope_form.xml
inflating: res/layout/pomow_form.xml
inflating: res/layout/promt.xml
extracting: resources.arsc
In this form, it is not possible to install the APK, trying so results in the phone yielding the following error message:
$ adb install 6f7523d3019fa190499f327211e01fcb.apk
Failed to install 6f7523d3019fa190499f327211e01fcb.apk: Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION: Failed to parse /data/app/vmdl135131206.tmp/base.apk: AndroidManifest.xml]
From the error messages we suspected, that an extra byte somehow ended up in the APK file.
The repair process consisted of finding and removing an extra byte from the file “warnings.png”. By changing only this byte and getting a valid APK file, this might be the original file. After repair, we got the following file.
$ sha256sum REPAIRED.apk
5b6ea28333399a73475027328812fb42259c12bb24b6650e5def94f4104f385e REPAIRED.apk
$ unzip -vt REPAIRED.apk
Archive: REPAIRED.apk
testing: META-INF/MANIFEST.MF OK
testing: META-INF/CERT.SF OK
testing: META-INF/CERT.RSA OK
testing: AndroidManifest.xml OK
testing: classes.dex OK
testing: res/drawable-hdpi/dmk.png OK
testing: res/drawable-hdpi/ic_launcher.png OK
testing: res/drawable-mdpi/fon_1.jpg OK
testing: res/drawable-mdpi/fon_2.png OK
testing: res/drawable-mdpi/fon_3.png OK
testing: res/drawable-mdpi/ic_action_search.png OK
testing: res/drawable-mdpi/ic_launcher.png OK
testing: res/drawable-mdpi/panel_2.gif OK
testing: res/drawable-mdpi/panel_4.png OK
testing: res/drawable-mdpi/panel_5.png OK
testing: res/drawable-mdpi/panel_6.png OK
testing: res/drawable-mdpi/panel_7.png OK
testing: res/drawable-mdpi/warnings.png OK
testing: res/drawable-xhdpi/ic_launcher.png OK
testing: res/drawable-xxhdpi/ic_launcher.png OK
testing: res/layout/activity_reg_form.xml OK
testing: res/layout/byleten.xml OK
testing: res/layout/dan_dmk.xml OK
testing: res/layout/dan_meteo.xml OK
testing: res/layout/dan_vr_2.xml OK
testing: res/layout/meteo_podg_form.xml OK
testing: res/layout/o_avtope_form.xml OK
testing: res/layout/pomow_form.xml OK
testing: res/layout/promt.xml OK
testing: resources.arsc OK
No errors detected in compressed data of REPAIRED.apk.
$ jarsigner -verbose -verify REPAIRED.apk
s 2215 Thu Feb 28 18:33:46 CET 2008 META-INF/MANIFEST.MF
2268 Thu Feb 28 18:33:46 CET 2008 META-INF/CERT.SF
1714 Thu Feb 28 18:33:46 CET 2008 META-INF/CERT.RSA
sm 6108 Thu Feb 28 18:33:46 CET 2008 AndroidManifest.xml
sm 543000 Thu Feb 28 18:33:46 CET 2008 classes.dex
sm 7047 Thu Feb 28 18:33:46 CET 2008 res/drawable-hdpi/dmk.png
sm 1703 Thu Feb 28 18:33:46 CET 2008 res/drawable-hdpi/ic_launcher.png
sm 68364 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_1.jpg
sm 153893 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_2.png
sm 182654 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/fon_3.png
sm 311 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/ic_action_search.png
sm 1853 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/ic_launcher.png
sm 2241 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_2.gif
sm 4420 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_4.png
sm 450 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_5.png
sm 1448 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_6.png
sm 551 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/panel_7.png
sm 25089 Thu Feb 28 18:33:46 CET 2008 res/drawable-mdpi/warnings.png
sm 2545 Thu Feb 28 18:33:46 CET 2008 res/drawable-xhdpi/ic_launcher.png
sm 4845 Thu Feb 28 18:33:46 CET 2008 res/drawable-xxhdpi/ic_launcher.png
sm 4356 Thu Feb 28 18:33:46 CET 2008 res/layout/activity_reg_form.xml
sm 20332 Thu Feb 28 18:33:46 CET 2008 res/layout/byleten.xml
sm 10584 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_dmk.xml
sm 20852 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_meteo.xml
sm 10208 Thu Feb 28 18:33:46 CET 2008 res/layout/dan_vr_2.xml
sm 2772 Thu Feb 28 18:33:46 CET 2008 res/layout/meteo_podg_form.xml
sm 2076 Thu Feb 28 18:33:46 CET 2008 res/layout/o_avtope_form.xml
sm 2944 Thu Feb 28 18:33:46 CET 2008 res/layout/pomow_form.xml
sm 952 Thu Feb 28 18:33:46 CET 2008 res/layout/promt.xml
sm 13296 Thu Feb 28 18:33:46 CET 2008 resources.arsc
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
- Signed by “EMAILADDRESS=android@android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US”
Digest algorithm: SHA1
Signature algorithm: SHA1withRSA, 2048-bit key
jar verified.
Warning:
This jar contains entries whose certificate chain is not validated.
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate’s expiration date (2035-07-17) or after any future revocation date.
Re-run with the -verbose and -certs options for more details.
About the RC4/encryption key:
By decompiling and manually “refactoring” the encryption algorithm, we discovered a “textbook” RC4 implementation as the encryption routine, which uses the hard-coded key as a first-part to the encryption key, with the second-part coming as a parameter from the function call:
Analyzing the XAgent linux sample, which also contained this RC4 key, we did not found an RC4 implementation, but a simple XOR based encryption routine:
We found one function call, which used the encryption key from the APK as input, but surprisingly, it was not used as key parameter, but input parameter.
For checking HTTP GET and POST messages a different XOR based check routine can be found, and a Base64-like encoding. After decoding, the XOR based routine checks the http result’s body. It xors the 4-11 bytes with the first 4 bytes as a key. It then should be equal to a hardcoded value (7 bytes) which the sample uses to check whether the recv succeeded or not.
These XAgent linux samples are very similar to a Windows version that has been found in november, 2013 (5f6b2a0d1d966fc4f1ed292b46240767f4acb06c13512b0061b434ae2a692fa1).
Recommended yara for the linux versions:
rule sofacy_xagent {
meta:
author = "AKG"
description = "Sofacy - XAgent"
strings:
service = "ksysdefd"x1 = "AgentKernel"
x2 = "Cryptor"x3 = "AgentModule"
x4 = "ChannelController"x5 = "RemoteKeylogger"
a1 = "UNCORRECT DISPLAY NAME"a2 = "Keylogger started"
a3 = "Keylog thread exit"a4 = "Keylogger yet started"
condition:
service or (2 of (x)) or (2 of ($a))
}
Technical details on the Fancy Bear Android malware (poprd30.apk)
Background
Recently, Crowdstrike has published details about a malicious Android APK file, named poprd30.apk or Попр-Д30.apk. It seems that the malware was created by the Fancy Bear group for tracking Ukrainian field artillery units (more info on this can be found here: https://www.crowdstrike.com/wp-content/brochures/FancyBearTracksUkrainianArtillery.pdf). The corresponding APK is identified by the MD5 hash 6f7523d3019fa190499f327211e01fcb on a related blog site https://www.crowdstrike.com/blog/danger-close-fancy-bear-tracking-ukrainian-field-artillery-units/. However, not much technical details have been given by CrowdStrike on the attack. During discussions on the topic, Jeffrey Carr initiated discussions with us and has sent some questions on if the case is real and how exactly the attack works, in particular, how the malware could have been used in military conflicts.
We carried out only a short investigation on the topic. Our goal was to uncover more technical details about the attack and to confirm the existence of the backdoor in the particular APK file.
Highlights
- We can confirm that the APK file known by the MD5 hash 6f7523d3019fa190499f327211e01fcb contains a backdoor that tries to communicate with a remote server.
- The server IP in the sample is http://69.90.132[.]215/
- The malicious APK does not use GPS to get exact location of the infected phone, it does not even ask for GPS-level position information.
- We note, however, that some location information can be collected by the malicious APK, mainly related to the actual base station used by the phone and the WiFi status.
- The implant in the malicious APK has similarities to the X-Agent implants of the Fancy Bear / APT28 / Sofacy group described in former reports, but this is not necessarily an evidence on the relationship as such similarities can be faked.
- We uncovered two interesting items: the malware authors put the German word “nichts” as a string in the code, as well, they made a typo “phone standart.”
Details
In February 2015, Trend Micro posted details about an iOS espionage app possibly related to the Pawn Storm / Sofacy / APT28 / Fancy Bear group. The technical details can be found at http://blog.trendmicro.com/trendlabs-security-intelligence/pawn-storm-update-ios-espionage-app-found/. Figure 5 of the Trend Micro document shows possible URL GET parameters used by the malicious code:
In the poprd30.apk code very similar items can be found related to the malicious communications:
By looking into BuildConfig it seems that one recompiled this APK modified Androdi Debug Key.
As one can see, strings in the APK file are very similar to those in the X-Agent implant, and have the same common goal: make the HTTP request similar to normal HTTP GET requests with common parameters. However, this similarity alone is not enough to state that the authors are the same, because it is very easy to copy this scheme.
Also, observe the initial value for the SERVER_ANSWER variable. It is “nichts,” which means “nothing” in German. We don’t know why a german word was used here. Note that this value is not used in the code, it stands only as a default value. That means, if no value is received from the server, then the corresponding function will return this value instead of the information received from the server. In the RegG.java file, which has the similar SERVER_ANSWER value it is set to ‘{ “no_jobs”, “or”, “error” };’ for default value. Setting a default value generally helps developers to find out if the data transmission was successful in the parts of the code not close to the transmission itself. One can simply check if the answer is still the default value, and if it is, it can be sure that the transmission was not successfull without complicated routines. However, in this APK we found no reference for checking if the SERVER_ANSWER has not been changed, and we don’t have clear idea why these two default values were used in the code.
Commands
Communication routines are spread across multiple classes: DataConstructor, DataExtractor, Reg, RegG, RegP, RegPBin. The main handling of the commands is in MainService. It is not entirely clear why there are multiple copies of some data and routines.
The malware sends basic info about the phone to the attacker as shown below:
byte[] arrayOfByte = Base64.encode((“<pre><font size=4 color=green><br>CMD 101 success</font>” + “<font size=4 color=blue><br>GoogleAccounts: ” + str1 + “<br>Device ID: ” + str2 + “<br>Model: ” + Build.MODEL + “<br>Manufacturer: ” + Build.MANUFACTURER + “<br>Phone standart: ” + str4 + “<br>Country: ” + str5 + “<br>MCC & MNC: ” + str6 + “<br>Base station: ” + str3 + “<br>Android version: ” + str7 + “<br>Android SDK: ” + m + “</font></pre>”).getBytes(), 0);
The malware can receive the following commands:
- Commands 103 105 108: stop itself
- Command 100 : Send SMS History /commands are self-explanatory/
- Command 101: Collect “all” information about the phone and send
- Command 102: GetCallDetails (Call history)
- Command 104: FetchContacts
- Command 106: GetAppList
- Command 107: GetWifiStatus (is any WiFi network available, what identifier, what MAC address, speed, etc.)
- Command 109: Browser history and bookmarks
- Command 110: Mobile data usage
- Command 111: Folders and files from sdcard directory
- Command 112: File download (SDcard) for command
- Command 101 – Gets GSM network LAC, CID info or base station info (coordinates) if CDMA, andorid version, google accounts, device id, etc.
Command 101 has a typo “phone standart” which should be “standard” both in English and German.
For command 101, it is important to note that it can provide location related information. In case of GSM , the base station related information can provide some (not so accurate) location information. Similarly, in case of CDMA, base station information is related to location, but it is not accurate either. In addition to the base station, WiFi information can also help an adversary to find out the approximate location of the phone, but it is nowhere close to accurate detection of the real location of the phone.
We have not seen any GPS related commands in the code, not even the original “D30 guidance” functionality. Most likely, the APK does not use GPS data. To be even more precise, the application Manifest information does not contain any requests related to GPS level locality permissions; it asks for ACCESS_COARSE_LOCATION only, which relates to the base station/WiFi based location information.
Encryption – RC4
The malware uses communications encrypted by RC4, encoded by Base64 (or very similar – we did not check it carefully), and CRC for error checking. These are very common, but the most important thing is the RC4 implementation and the key in use, which can be proved to be similar to the older X-Agent implants.
The corresponding RC4 key is also visible in the java byte code format:
In hex, the encryption key is 3B C6 73 0F 8B 07 85 c0 74 02 FF CC DE C7 04 FE 72 F1 5F 5E C3 56 B8 D8 78 75 50 E8 B1 D1 FA 59 5D 55 EC 83 10 A1 33 35
Note: Rc4 keys can be arbitrary length, and implementation is very easy, hence it is used many times.On the other hand, RC4 is not secure enough for real crypto operations.
Conclusions
In our investigations, we tried to check if the APK indicated in the CrowdStrike report had backdooor connectivity. We can confirm, that this APK file has malicious functionality and can be used to collect intelligence from the users of the applet. Some additional technical details were discusssed. We (and probably CrowdStrike, too) had no access to the original, unmodified APK file.
UPDATE1
Some linux X-Agent versions used exactly the same RC4 key, see this screenshot:
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
GameOver Zeus now uses Encryption to bypass Perimeter Security – .enc encryption
The criminals behind the malware delivery system for GameOver Zeus have a new trick. Encrypting their EXE file so that as it passes through your firewall, webfilters, network intrusion detection systems and any other defenses you may have in place, it is doing so as a non-executable “.ENC” file. If you are in charge of network security for your Enterprise, you may want to check your logs to see how many .ENC files have been downloaded recently.
Gary Warner wrote a blogpost over it, and shared some files and information with us. The question was, how the .enc file is decoded and used.
The droppers sent out through emails are pretty small, around 10-18 kb. These droppers have an obfuscation layer, so hard to directly analyze them. However, with volatility it was relatively easy with procexedump to extract a small, 5k downloader that actually connects to a server to download the related .enc file, decrypt and decompress it, and execute.
The encrypted files look like this at the beginning:
0000000000: 5A 5A 50 00 E7 31 0E 1E │ 02 17 0E 50 58 87 0E D1 ZZP ç1♫▲☻↨♫PX┼♫Ń
0000000010: 5C 87 3E AC A7 87 0E EB │ 58 BF 23 52 58 C7 0A 6B \┼>¬§┼♫ëXż#RXÇ◙k
0000000020: 41 87 E6 53 54 89 11 53 │ E2 89 0E E7 51 4A 2F EB A┼ćST%◄Sâ%♫çQJ/ë
0000000030: 58 86 42 9E 79 D3 66 3A │ 2B 87 2E 23 2A E8 69 21 X┼BžyÓf:+┼.#*či!
0000000040: 39 EA 0E 73 3B E6 60 3D │ 37 F3 2E 53 3A E2 2E 21 9ę♫s;ć`=7ó.S:â.!
ZZP\0 is a magic string, then a compressed and encrypted part is stored (here: 0xE7 0x31…)
After downloading the .enc file the dropper checks the magic:
.text:00971450 cmp byte ptr [esi], 5Ah
.text:00971453 jnz short loc_9714D2
.text:00971455 cmp byte ptr [esi+1], 5Ah
.text:00971459 jnz short loc_9714D2
.text:0097145B cmp byte ptr [esi+2], 50h
.text:0097145F jnz short loc_9714D2
.text:00971461 cmp [esi+3], bl
.text:00971464 jnz short loc_9714D2
.text:00971466 shl eax, 2
.text:00971469 push eax ; dwBytes
.text:0097146A push 8 ; dwFlags
… and does the decryption….
.text:0097149C loc_97149C: ; CODE XREF: start+455j
.text:0097149C xor [esi+ecx*4], eax
.text:0097149F mov edi, [ebp+78h+Buffer]
.text:009714A2 inc ecx
.text:009714A3 shr edi, 2
.text:009714A6 cmp ecx, edi
.text:009714A8 jb short loc_97149C
eax stores the encryption key, which is 32 bits long.
The executable stores its configuration in a compressed form, but in cleartext.
0000001000: 85 B0 00 64 63 6D 73 73 │ 65 72 76 00 69 63 65 73 •° dcmsserv ices
0000001010: 2E 63 6F 6D 02 00 0C 00 │ 2F 69 6D 61 67 65 80 73 .com☻ ♀ /image?s
0000001020: 2F 73 74 6F 72 69 01 1C │ 08 6C 69 64 00 18 70 64 /stori☺∟◘lid ↑pd
0000001030: 66 2E 18 65 6E 63 0D B4 │ 0F 00 B8 37 B8 0A 1E 01 f.↑enc♪´☼ ¸7¸◙▲☺
0000001040: 0E 02 00 06 65 6C 65 63 │ 00 74 72 69 63 69 61 6E ♫☻ ♠elec trician
0000001050: 73 00 64 75 62 6C 69 6E │ 69 72 20 65 6C 61 6E 64 s dublinir eland
0000001060: 04 78 2F 77 00 70 2D 63 │ 6F 6E 74 65 6E 00 74 2F ♦x/w p-conten t/
0000001070: 75 70 6C 6F 61 64 00 73 │ 2F 32 30 31 34 2F 30 16 upload s/2014/0▬
0000001080: 31 22 70 02 6B 01 03 6B │ 00 00 00 00 00 00 00 00 1"p☻k☺♥k
The compression here is RtlDecompressBuffer standard windows call.
rtldecompressbuffer_dword_972000 = (int (__stdcall *)(_DWORD, _DWORD, _DWORD, _DWORD, _DWORD, _DWORD))GetProcAddress(v9, "RtlDecompressBuffer");
It is called like this:
rtldecompressbuffer_dword_972000(0x102u, v11, 1024, &unk_974000, 256, &v36);
0x102 stands for: 0x100 for max compression level, 0x02 for LZNT1 compression algorithm.
If you don’t have LZNT1 related code at hand, you might use the tool available at the following address: http://reboot.pro/files/file/121-lznt1-tools-bootmgrntfs/
It does not work for all the samples, but works most of the time.
So decompressed config looks like this:
0000000000: 64 63 6D 73 73 65 72 76 │ 69 63 65 73 2E 63 6F 6D dcmsservices.com
0000000010: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000020: 2F 69 6D 61 67 65 73 2F │ 73 74 6F 72 69 65 73 2F /images/stories/
0000000030: 73 6C 69 64 65 73 2F 70 │ 64 66 2E 65 6E 63 00 00 slides/pdf.enc
0000000040: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000050: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000060: B8 37 B8 1E 00 00 00 00 │ 02 00 00 00 65 6C 65 63 ¸7¸▲ ☻ elec
0000000070: 74 72 69 63 69 61 6E 73 │ 64 75 62 6C 69 6E 69 72 triciansdublinir
0000000080: 65 6C 61 6E 64 2E 63 6F │ 6D 00 00 00 2F 77 70 2D eland.com /wp-
0000000090: 63 6F 6E 74 65 6E 74 2F │ 75 70 6C 6F 61 64 73 2F content/uploads/
00000000A0: 32 30 31 34 2F 30 31 2F │ 70 64 66 2E 65 6E 63 00 2014/01/pdf.enc
00000000B0: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
00000000C0: 00 00 00 00 00 00 00 00 │ 00 00 00 00 B8 37 B8 1E ¸7¸▲
00000000D0: 00 01 00 00 02 00 00 00 │ ☺ ☻
The 32-bits xor code used for encryption is stored 0x60 bytes after the beginning of this buffer, that means, for both servers it is 0b8 0x37 0xb8 0x1e.
This should be used cyclically on the .enc file to get the compressed file , which again is compressed with RTLCompressBuffer call.
So how to make a universal decoder for .enc files?
Let’s check this one:
0000000000: 5A 5A 50 00 5F 8D B8 53 │ E2 A7 B8 1D B8 37 B8 9C ZZP _Ť¸S⧸↔¸7¸ś
0000000010: BC 37 88 E1 47 37 B8 A6 │ B8 0F 95 1F B8 77 BC 26 Ľ7?áG7¸|¸☼•▼¸wĽ&
0000000020: A1 37 60 1E B4 39 A7 1E │ 02 39 B8 AA B1 FA 99 A6 ˇ7`▲´9§▲☻9¸Ş+út|
0000000030: B8 36 F4 D3 99 63 D0 77 │ CB 37 98 6E CA 58 DF 6C ¸6ôÓtcĐwË7?nĘXßl
I’m cheating and telling you that it will be decrypted to
0000000000: E7 BA 00 4D 5A 90 00 03 │ 00 00 00 82 04 00 30 FF çş MZ? ♥ '♦ 0˙
0000000010: FF 00 00 B8 00 38 2D 01 │ 00 40 04 38 19 00 D8 00 ˙ ¸ 8-☺ @♦8↓ Ř
0000000020: 0C 0E 1F 00 BA 0E 00 B4 │ 09 CD 21 B8 00 01 4C CD ♀♫▼ ş♫ ´○Í!¸ ☺LÍ
Where B8->00 53->4D E2->5A A7->90 is the transformation.
4D 5A is the standard PE header, and for all the .enc files, the next byte was 0x90. Before the MZ header, the compression magic always contains a 0x00 byte. So we have 4 fixed bytes. Hence let’s calculate the key:
1st byte: 0xB8 xor 0x00 = 0xb8
2nd byte: 0x53 xor 0x4D = 0x1E
3rd byte: 0xE2 xor 0x5A = 0xb8
4th byte: 0xA7 xor 0x90 = 0x37
Remember the config file? The key was B8 37 B8 1E, this is just a rotated version of it with 2 bytes shift as you know, the magic starts with two additional bytes.
So as these bytes are currerntly constants, it’s evident to create a generic decryptor too for the .enc files, that works without the hard coded key, only with the .enc files. After decrypting, of course, you have to run RTLDecompressBuffer to get the actual executable.
Note, there is another small encryption routine in the 5k dropper, we did not fully investigate what it codes:
.text:00971000 encrypt_sub_971000 proc near ; CODE XREF: start+4AFp
.text:00971000
.text:00971000 arg_0 = dword ptr 4
.text:00971000 arg_4 = byte ptr 8
.text:00971000 arg_8 = dword ptr 0Ch
.text:00971000
.text:00971000 mov ecx, [esp+arg_8]
.text:00971004 test ecx, ecx
.text:00971006 jz short loc_971029
.text:00971008 movzx eax, [esp+arg_4]
.text:0097100D imul eax, 1010101h
.text:00971013 mov edx, ecx
.text:00971015 push ebx
.text:00971016 push edi
.text:00971017 mov edi, [esp+8+arg_0]
.text:0097101B shr ecx, 2
.text:0097101E rep stosd
.text:00971020 mov ecx, edx
.text:00971022 and ecx, 3
.text:00971025 rep stosb
.text:00971027 pop edi
.text:00971028 pop ebx
.text:00971029
.text:00971029 loc_971029: ; CODE XREF: encrypt_sub_971000+6j
.text:00971029 mov eax, [esp+arg_0]
.text:0097102D retn
.text:0097102D encrypt_sub_971000 endp
(copied from cef76fa7b4b30f76c7b6d2eefa30d944 sample)