Nov 262014

New anti-APT tools are no silver bullets:
An independent test of APT attack detection appliances

CrySyS Lab, BME

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 ( 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 ( or Levente Buttyán ( 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.

 Posted by at 2:57 pm
Aug 072014

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.

 Posted by at 2:56 pm
Jul 032014

*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).


User names for FTP authentication:


Related file hashes:

--> likely False Positive: 93deb98d89b8acfa4115ce1ca89ac26a45aae4563c3a454bf8b2a26886f40a46
--> This is old miniduke sample 8290b324f5cdb5c3ea17fa48a74bc11c856f0da0b049d07d9316d161f71f26a5

 Posted by at 1:59 pm
Feb 022014

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:
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
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 /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 arg_0 = dword ptr 4
.text:00971000 arg_4 = byte ptr 8
.text:00971000 arg_8 = dword ptr 0Ch
.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 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)

 Posted by at 9:11 pm
Nov 072013

This article reflects results of joint work with Ukatemi guys.
(A magyar nyelvű változat az angol után található.)

Adobe was compromised this September. Stolen data was first found in September and disclosed in early October by Brian Krebs. Later on, some 10 days ago somebody has leaked a 9GB (uncompressed) authentication database stolen from Adobe.

The database was analyzed recently based on the properties of the encryption scheme. contains the results of the analysis: the top 100 frequently used encrypted passworts and the most probable guesses for the raw password.
Press write-up is also available on the research:

We were however curious about the passwords chosen by Hungarians. In the Adobe leak, there are 209 125 email addresses with .hu CCTLD domain name. By the same way how the previous research was carried out, we created a list of most frequent passwords among this 200 thousands of users and tried to pinpoint the most likely cleartext password based on the password hint information and email addresses.

Note, however, that due to the much smaller corpus (200k instead of 154M accounts), we had much lower number of password hints, and thus the confidence of our results is lower.
In the table below, we show the frequency, how many times a password was used in the .hu corpus, and for comparison, we also show the frequency in the full database. If a password is often used in the whole database, then it is most likely not a specific hungarian word, but some internationally known word,phrase or code. In addition to the most likely password, we give secondary ideas in cases where we are not confident enough, and some information about the meaning of the specific word, if it relates to Hungarian language or culture.

Ezév szeptemberében vették észre, hogy valamilyen ismeretlen csoport feltörte a világszerte ismert Adobe szoftvergyártót (többek között az Acrobat Reader, Photoshop és Flash Player gyártóját), és elloptak a cégtől forráskódokat valamint nagyméretű felhasználói adatokat tartalmazó adatbázisokat. Október elején került napvilágra az adatlopás ténye, és október végén hírek kaptak napvilágra arról, hogy a cég 154 millió felhasználójának adatai is napvilágra kerültek. Pár nappal később egyre több helyen volt elérhető ez az ellopott 9GB méretű információhalmaz. Az adatok tartalmazzák a felhasználók e-mail címeit, kódolt jelszavát és ún. jelszó-tanácsát is. A kódolt jelszó egy szimmetrikus rejtjelezővel, egy erősnek számító 3DES algoritmussal van rejtjelezve, a jelszó-tanács egy védelem nélküli szöveg.
A rejtjelezett jelszót kulcs nélkül nem lehet dekódolni, és a kulcs egyelőre nem szivárgott ki. Ezért a jelszavak elvileg nem feltörhetőek. Sajnos azonban az iparági gyakorlattól eltérően a tárolási mód sérülékenységeket rejt magában. A rejtjelezett kulcsok nem salt-oltak és ECB módban “IV” nélkül rejtejelezettek. Ezek a szakkifejezések azt mondják ki: ha két felhasználónak azonos a jelszava, akkor a rejtjelezett párjuk is azonos.

Ez pedig gond. Sok felhasználó esetén sokan használnak azonos jelszót. Ha két felhasználó azonos jelszót használ, akkor a kódolt jelszavuk is azonos lesz. Ha találunk két felhasználót, akiknek azonos a kódolt jelszavuk, és az egyik a jelszó-tanács mezőben az írja, hogy “A jelszó három a betű és az 12 számsor”, akkor nagy valószínűséggel tudjuk, hogy a másik felhasználónak is aaa12 a jelszava. Nincs lehetőségünk a teljes bizonyosság megszerzésére, tehát ez a trükk főleg olyan jelszavakra működik, ahol a jelszavakat sokan használják és sok a jelszó-tanács (password hint) is.

Ennek megfelelően külföldön már pár napja publikáltak egy listát a leggyakoribb 100 rejtelezett jelszóról és annak megfejtett párjairól. A .hu domain névvvel regisztrált email című felhasználók száma meghaladja a 200 000 elemet a listában, közösen az Ukatemi startup cégünk embereivel azt vizsgáltuk meg, hogy mik a magyar jelszóválasztási szokások, és hogyan illeszkednek a nemzetközi környezethez.

Az alábbi listában megtekinthető a magyarok (.hu email) által leggyakrabban használt jelszavak kódolt változata, a darabszám, ahányszor .hu domainről használták, a darabszám, ahányszor nemzetközileg használták (ez is érdekes lehet, hisz vannak magyarok .com cím alatt is, és vannak jelszavak, amik nemzetközi szinten is használatosak). Feltűntettük a legvalósznűbb becslésünket a jelszóra (ami nem biztos, mert nem ellenőrizhető jogszerűen), és a tippjeinket, ha a legbiztosabb ötlet nem igaz. A külföldiek számára kis értelmezést is elhelyeztünk a jelszó jelentéséről.
Összesen csak kb. 3 jelszó esetén nem volt elég adat a nagyjából biztonságos azonosításra, ezeknél valamilyen okból senki, vagy szinte senki nem jelölt meg jelszó-emlékeztetőt.


  • Sok felhasználó jelszava “citrom” – nem túl kreatív és veszélyes
  • Sok jelszó-tanács nagyon egyszerű ” a van ellentéte” “nem narancs” “A tudom ellentéte”
  • Sok tanács kiad plusz információt “Ugyanaz, mint az címemen” – ez külön segítség, hogy mit támadhatunk meg még a jelszóval.
    “Mint mindenhol” – ez is egyértelműen gond, nemcsak, hogy ugyanazt a jelszót használja a felhasználó, de még segíti is a támadót, hogy továbbmenjen.

  • Sok felhasználó “nevem” “barátnő neve” “második nevem” szöveget írt, mondván, esetleg az email címéből ez nem következik. Ugyanakkor, a többi azonos jelszót
    használó felhasználónak elég egy szempillantást venni az email címeire, és triviális, hogy ha 20 emberből 10-nek csilla szerepel a címében, akkor a jelszó csilla, vagy annak becézése lesz. És innentől egy vadidegenről azt is tudhatjuk, hogy mi a neve, barátnője neve, második neve stb., ami segítség ún. social engineering támadásokhoz is.

FRISSÍTÉS: Találtunk pár apróbb hibát, ezeket “FIXED” felirattal javítjuk

Mintaként nézzük meg a következő rövidített listát (lecseréltük X-re a nem releváns részeket):


A “nevem” “name” “Asszony” és “kislanyom” alapján egyértelmű, hogy egy női nevet keresünk. Ezután pedig elég ránézni az e-mail címek listájára, hogy észrevegyük mennyire sok “csilla” szerepel rajta. Persze tévedhetünk, hiszen van egy “lindus” email című is, de a “csilla” elsöprő többségben van.

A jelszavak listájából látszik, hogy nagy az átfedés a nemzetközileg is használt jelszavakkal pl. “123456”, de vannak lokálisak is “szerelem”. A legtöbb jelszó továbbra is név vagy becenév, alig van ettől eltérő az első százban. Tanács: Sose használjuk emberek neveit, beceneveit, vagy azok módosításait, mert ezek a leggyakoribbak. Legyünk kreatívabbak, még mindig igaz, hogy a cseresznye151pok sokkalta biztonságosabb, mint a kr1sztinaIloveyou. A legjobb, ha valami generátorral készítünk jelszavakat, ezek sem tudnak csodát tenni, de egy DooYee7goe5EeFa nagyon erős. Összehasonlíthatatlanul erősebb az eddigi vicces példáknál.

A helyzet tehát az, hogy aki regisztrált az Adobe-nál bármilyen okból, és a jelszavát máshol is használta, azonnal jelszót kell változtatnia a többi helyen.

RankNo. in .huNo. in allEncrypted PWMost likely passwordIs it in top100/english?remarks, other guesses
2525932pbn7wO3zb+8=jelszopassword in hungarian
534813401uQM9dmQq8vE=qwertzhungarian keyboard layout has y=z
15189320q1A6iHNzTFg=valamisomething in hungarian
1717614673zV1jrgwEro=attilahungarian male name
18175284MiWs/2HM40w=lacikahungarian male name
21151274z5rLiwD12co=almafaappletree in hungarian
22150260N4+iUEuZbPw=cicacat in hungarian
23137214MAEvnIZOuSk=petipeter in short
241356662uIMAMQyXI/g=something international, 6600 hits
25134239dvqulUaGiQg=zolikazoltan in short, male name
26126273AhfBRgIzdos=tamasmaybe tomi tomika, male name
27125294W/jzwDNnaOw=lofaszshould be censored
28124367MSycWzt2SLPqvJr9l/X59g==szerelemlove in hungarian
29123220rA3xnflDDXI=esztikemaybe eszter, hungarian female name
32116234zjrHRH4etC0=macikamaybe maci, stands for bear or teddy
33107234m0/4nMkmJyM=gabimaybe gabika, female or male name in short
35104187P9f9Bgw46Hk=nincsmeans it does not exist
36102194zwakdT5tFhk=titoksecret in hungarian
37100192/jNYdvynVr0=csillagstar in hungarian
381001162+bZCz+Mm7WHioxG6CatHBw==budapestcapital of Hungary
3997235iqVZniq2Z6fioxG6CatHBw==cicamicalike pussycat
4097443bDjmWzVDGMo=danimale name in short
4492155FClbZZD1l1A=FIXED: nemtomI dunno in short
4591149Xe2T3yCUsCc=balazsmaybe balu, balika
4690155lwXlGk4RTzc=mazsolakind name
4789247D0B1TLHoZoTioxG6CatHBw==szeretetlove (one version) in hungarian
4888197Yg/0iyYFi+A=janikamale name in short
5086421FvWPZ2OI8V0=tigrismaybe tigris1
52844540TYrTfuuBGm0=monikafemale name in short
5383142p6kbkduAMhPioxG6CatHBw==FIXED: macilaci/TD>Yogi Bear
5482153iolWV4U4baM=madarbird in hungarian
5581131TiMyOmRnnYk=mokussecond guess: manoka mokus is for squirrel
5680214ugYjb/7SO9DioxG6CatHBw==FIXED: nemtudom“I don’t know”
59796920QkLIDf6naxw=no hint, strange
61784829XWs+3joEULU=0123456maybe 012345
6374377syBP2PbOprLioxG6CatHBw==FIXED: freemail
64739787C6fdPcrsYlU=123asdor asd123
68717991E3P4TkKmrIE=no hint, strange
7169111WHnoclxstks=some woman’s name, bea, betti, zsuzsa or monika are most likely
77681398Nd+cNdQ360=csillahungarian female name
7866959remGyraE2+rioxG6CatHBw==viktoriahungarian female name
79665213SVXt5Rlot1U=cleveror something related to iq, cleverness, and a brand of computer mouse
816613531DuMurYI43dU=blablablahblah in hungarian
8265737vEldih7WrfY=vivienfemale name
8365129o2D+z1QYuHo=FIXED: nyuszibunny in hugarian
84657070U1yPApWcaOA=barbarafemale name
8662128vQGGxx87Fyk=leventemale name
8762957DOklOXTFPo=zsoleszor other forms of zsolt, like zsolti
896181gkfBa7HrOnY=citromfunny, many “” users chose that, hungarian: lemon
9160102kiQXbvrKbiA=robior robert, robby, roby, or similar
926088GsQ/41R7pXw=FIXED: krisztifemale name
9360194/EoAhM0rWA8=katamaybe katalin, kati, female name
9659181Kt3DWt8h3tg=ildikohungarian female name
9857146MoedSZDdCmk=zsuzsior zsuzsanna, hungarian name like suzy
1005697pp3j26xZbvTioxG6CatHBw==kiskacsastands for duck in hungarian. fix: kacsa->kiskacsa “small duck”
10156P2x/N9v5UaM=melindafemale name in short

Edited by: Boldizsar Bencsath

 Posted by at 9:36 pm
Aug 202013

UPDATE: A full research report on the NMI and other passthrough attacks is available online at:

Gábor Pék (CrySyS Lab)  started to explore possible vulnerabilities in the use of directly assigned (passthrough) devices in contemporary hypervisors (Xen and KVM). As a result of this research, he pointed out some misbehaviors in the interrupt handling method of current platforms. One of this issues is going to be presented in this article.  A paper is to be published about all the discovered issues in collaboration with other researchers from Eurecom, France.


Direct-device assignment is one of the most controversial issues in hardware virtualization, as it allows for using devices almost at native speed, however, raises many security problems.  As most of these issues can be evaded by properly configured system software and hardware, the security issues of that area seemed to be solved.  At the same time, virtual instances with direct-device assignment are publicly available  via various cloud providers, so the security issues have to be examined in more details. In this article,  an interesting vulnerability is going to be presented which is not a simple software bug, but an example for an issue on how to handle improperly a hardware-level mechanism: the interrupt generation.

More precisely, native host-side Non-Maskable Interrupts (NMI) can be generated on systems (e.g., Xen, KVM etc) with System Error Reporting (SERR) enabled via a passthrough device being attached to a fully virtualized  (HVM) guest even when all the available hardware  protection mechanisms are turned on (Intel VT-d DMA and Interrupt Remapping).

As a result of the NMI, the corresponding host-side NMI handler is executed which may cause Denial of Service (DoS).

To reproduce the issue, the attacker has to create a malformed MSI request by writing to the LAPIC MMIO space (0xFEExxxxx) in the guest physical address range. This can be accomplished by a modified DMA transaction. Examples for malformed MSI requests include Interrupt Vector numbers being set below 16 or MSI requests with invalid size (not DWORD).

Output of Xen 4.2 Dom0 after the attack (xl dmesg):

(XEN) NMI – PCI system error (SERR)

Output of KVM 3.4 host after the attack (/var/log/kern.log):

NMI: PCI system error (SERR) for reason a1 on CPU 0.
Dazed and confused, but trying to continue

The NMI is reported as a result of an ‘Unsupported Request’ PCI system error, and has nothing to do with compatibility format MSIs with delivery mode of NMI. Note that Interrupt Remapping disables the use of compatibility format MSIs by clearing the GCMD.CFI flag. By turning x2APIC mode on system software cannot even reconfigure that flag.

Later investigations showed that the host-side NMI was not generated by the PCI device being assigned to a fully virtualized (hardware-assisted) guest, but the Host Bridge(00:00.0). See the output of lspci.

Before the attack:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
Subsystem: …
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>

After the attack:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
Subsystem: …
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR+ <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>

Vulnerable Systems

Affected platforms enable System Error Reporting, where the corresponding NMI handler is executed in the hypervisor/host OS that should have never happened in normal circumstances when Intel VT-d Interrupt Remapping is enabled. Note that only Xen and KVM were tested and verified, however, every other system software can be affected which runs above a platform with SERR and Intel VT-d enabled.

While Intel does not recommend to turn SERR reporting on by default, some platforms do enable it as it carries essential information about legal system errors.

SERR reporting can either be disabled for the Host Bridge, or system software can block SERR error signaling due to Unsupported Request error resulting from malformed MSI requests. The former advice is quite intrusive as it suppresses all the system errors coming from the Host Bridge. At the same time, this is supported by all the chipsets. The second option is a more fine-grained solution, however, there is no information whether it is applicable to all Intel chipsets.

As a consequence, there is no real solution available for the issue for now.


Corresponding CVE number: CVE-2013-3495
Corresponding Xen Security Advisory number: XSA-59


Many thanks go to Jan Beulich from the Xen security team, the Intel Product Security Incident Response Team and Rafal Wojtczuk from Bromium for the in-depth discussions, recommendations and advices.

More details about this issue is going to be published in our upcoming paper.

May you have any questions please let us know.


Mar 202013

The CrySyS Lab, Budapest has been notified by the Hungarian National Security Authority ( 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, 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

Please read the detailed technical report.

 Posted by at 4:38 pm
Feb 272013

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

 Posted by at 10:19 pm
Feb 272013

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 :113e6fc85317fdd135e3f5f19e6c7a58 *
md5sum ~6rld.tmp : c786a4cdfe08dbe7c64972a14669c4d1 *~6rld.tmp

where is the startup file, which is created based on ~6lrd.tmp. 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 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: / Switzerland / France / United States / Germany

The C&C server used by stage 3 of the malware is (IP 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: – port TCP/80 - HTTP –port TCP/443 - SSL –port TCP/80 - HTTP

Known search strings in Google search can also be used to detect the malware:


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)

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


  • 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


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).

 Posted by at 2:00 pm