3500+ Visual Basic coders cannot be… wait a second

Posted on by

Update

Originally, this post had an incorrect title 🙂 By mistake I used “3500K” which is equivalent to 3.5M. The number should be 3500 a.k.a. 3.5K

Old Post

The number of malware writers is enormous. This is a fact. If someone tells you that there are only 10-100 active ppl or groups doing so, then maybe they are right. But… they are most likely not.

Clustering large number of samples allows us to cherrypick a lot of interesting statistics. I shared quite a lot of them back in 2012-2013. Over last weekend I crunched my databases again and this time I focused on Visual Basic ‘goodness’.

Despite being old, this programming platform still has a lot of followers. It ‘helps’ writing RunPE  wrappers and their authors often leverage VB’s built-in virtual machine which produces executables that are a big pain to analyze w/o some dedicated tools.

Now, my focus on VB was very specific. If you ever looked at the VB apps before, you know that they often leave traces of the original project path used by the application author inside the file. Yes, the ‘.vbp’ path. Looking through a histogram of all normalized .vbp paths extracted from a decent collection of malware I was able to find over 3500 user names used in the profiles of people who code them (focusing only on c:\users\* and c:\documents and settings\*). The number is pretty high, but that is not surprising.  If you add it to 7000 names I extracted in 2013 from debug strings then we are already crossing 10K profiles (possibly people). Multiply it by 2 since I excluded a lot of non-user-accountish paths, and the same name can belong to many people.

Of course, stats are always biased:

  • I don’t have all samples
  • Some of these paths could be automatically generated/modified/made up
  • Lots of other reasons

but numbers speak for themselves anyway.

Here is a list of top user names – lots of variations of the Admin account in multiple languages top the list:

  • Administrator
  • Administrador
  • Admin
  • Administrateur
  • user
  • Owner
  • ADMINI~1
  • Pedro
  • David
  • Usuario
  • pc
  • 2fast4you
  • IubHost
  • ben
  • box1
  • xp
  • DANIEL
  • M3
  • Master
  • Tolga
  • o_O
  • M3N3G@TT1_
  • sher soft
  • Jhon
  • Antrax10

Various interesting names are also on the list:

  • Alpacino
  • WHO
  • Metal_Zone
  • LORDOFDARK
  • MicrosoftCorporation
  • Emperor Zhou Tai Nu
  • mitnick
  • KingOfHackers
  • ^_^
  • AnTiviRus7
  • Compaq_Owner
  • Hacker test Machine
  • KillerMadara
  • x-men
  • ghost prince
  • HACKED-PC
  • SkY-NeT SySteMs
  • Administrator.VIRUS
  • Sauvegarde [ Don’t Toutch ]
  • Evil Karma
  • DJ-HacKeR
  • Fuck Yu !
  • H4x0r!
  • o-._.-o
  • Oracle Machine
  • Jesus Cristo
  • oussama
  • OWNED LAN HOUSE
  • $T0N3R
  • DeV-PoInT HaCkEr
  • FUCKWIT
  • GETFUCKED
  • ~RED_DEVIL~
  • 0p3nf1r3
  • BaD HackeR
  • PrediatOr
  • PuNkDuDe
  • redC0mmand3r
  • Soda_Da_Pimp
  • British_Intel
  • Saeed_virus
  • wolverine
  • Computer Zimmer
  • E.M.I.N.E.M
  • _M3t4m0rf0siS_
  • -$-BaNdO’s CoRp-$-
  • A__L__I__E__N
  • BrainFart
  • FaTaLCoDeR
  • FUCK OFF
  • fucked up
  • FuckYou
  • g0df4th3r

The not so boring land of Borland executables, part 1

Posted on by

“Borland”, “Inprise”, “Code Gear”, “Embarcadero”, “Delphi”, “C++ Builder”, as well as “Boolean”, “False”, “True”, “System”, “AnsiChar” are keywords that are very familiar to anyone who reverse engineers executables on regular basis. Seeing them is a good indicator that the samples we look at were most likely produced by compilers coming either directly, or through its descendants and spinoffs from Borland.

I want to talk about them, because Borland executables can be a goldmine for forensic investigators.

The part 1 will focus on the infamous number 0x2A425E19 (708992537) a.k.a 1992-06-19 22:22:17 (Friday).

This is a compilation timestamp of many Delphi files and let’s face it – it is just simply annoying.

Lots of people complained about it in the past; it is actually a very well-known bug, have not been addressed for many years, and only (as per the note in the link provided): “In Delphi 7 this structure was filled properly, but in 2006 not.” i.e. Delphi 4 – Delphi 2006 do not set this timestamp correctly.

Now, this is actually an interesting forensic artifact as it tells you the file was compiled most likely with Delphi 4 – Delphi 2006.

There is more to it.

If the compilation stamp is wrong you can still manage to win the game. If the Delphi executable has a resource directory you may retrieve its compilation timestamp. It is stored in an old-school DOS time format (note that non-Delphi files store it as an EPOCH timestamp, as per PE documentation; yes, Delphi executables are weird 🙂 ). And lo and behold, it may be actually a compilation timestamp that indicates when the whole thing was compiled, or at least give you a better estimate!

In any case, it’s better than nothing.

Example for the same file:

PE Comp.:    1992-06-19 22:22:17 2A425E19, 708992537
.rsrc comp.: 2010-12-09 14:25:36 3D897332, 1032418098

PE Compilation timestamp is the buggy 1992-06-19 22:22:17, but the .rsrc directory timestamp is a very reasonable timestamp 2010-12-09 14:25:36.

And yes, there is a script that you can use to do a dirty work for ya (use it for Delphi executables only).

perl pect.pl <filename>

Download pect.pl here.