Skip Navigation
BlackBerry Blog

An Introduction to AlphaLocker

/ 05.04.16 / Jim Walter

It is always a treat, as a malware researcher, to come across something new and unique, and to then follow the resulting rabbit hole as far as you can go. I believe most of us in the cybersecurity industry enjoy that particular part of the puzzle, especially when you are able to fully trace the origin of a novel artifact or binary. Starting with a single random file, and ending up with a broad picture of the economy behind that malware is highly satisfying and often eye-opening.

Which brings us to yet another family of ransomware – AlphaLocker.  


Introducing AlphaLocker

This family of ransomware is directly purchased from the author via the Internet. The buyer can then choose to host/spread/distribute it in whatever way they see fit - as opposed to some of the more recent turn-key offerings like Ransom32, ORX-Locker, or Encryptor RAAS, which lack a full administrative panel and other customization features present in a fully packaged malware ‘kit’.

This is an interesting example to highlight for a couple of reasons. First and foremost, AlphaLocker is cheap compared to other types of ransomware. The first versions began to appear in March 2016, priced at only $65 USD, paid via Bitcoin.


Figure1: AlphaLocker Advertising


Figure 2: More AlphaLocker Advertising


Figure 3: Still More AlphaLocker Advertising

For that low price you get your own unique copy of the main executable (the actual ransomware), the master decryptor binary (based onHidden Tear), and your own administrative panel instance. Hosting, spreading, and other typical ransomware services are then left to the buyer.

The lower price point allows ‘less-skilled’ ne'er–do–wells to possess and control (and profit from) ransomware, with little to no coding and zero ramp-up time. 

Sample Review

Also of note is the fact that the author(s) of AlphaLocker are continually generating updates to evade detection by traditional signature-based AV technologies. While that practice is absolutely the norm amongst malware authors, it never ceases to amaze just how easily the bad guys are able to keep up the evasion, staying one step ahead of signature-based detection technologies.

In reviewing a handful of AlphaLocker samples via a popular multi-engine sample-scanning site, most of the samples were only detected by between zero and nine out of 56 AV vendors. In one example, the AlphaLocker binary was compiled on 4/17/2016 and submitted to the sample-scanning site that same day, showing a 9/56 detection ratio. Upon a rescan 12 days later on 4/29/2016, the detection rate for that exact same sample was still only 22/56.

Worryingly enough, some of those detections are based on the respective vendors’ cloud-based detection mechanisms. In other words, if you take away connectivity to said service, that product would cease to detect as well.

We will cover detections with CylancePROTECT® further down in this blog, in order to illustrate how our artificial intelligence based approach stops malware dead pre-execution, without the need for signatures, prior knowledge of the sample, cloudy heuristics, frequent updates, and so on.

There is another critical point worth mentioning here. AlphaLocker is based on the Eda2 project, by Utku Sen. This was an ‘open source’ ransomware project that, until recently, was openly available via Utku’s github. In January 2016, the source was pulled by Utku in response to the code being used in real attacks (and the data could not be recovered via a built-in backdoor). This is a CRITICAL point. Not only is the behavior blatantly and contextually malicious, but the actual source code is public and easy to find.

Again, there is no reason why any reputable AV product should fail to detect this ransomware. Unfortunately, most are still failing.

Delving Deeper

Before we explore this detection piece further, I’d like to walk you through the full AlphaLocker service, including the admin panels and specifics on the ransomware binaries themselves. During our analysis here at Cylance, we were able to get a rare and close glimpse into the AlphaLocker ecosystem. Sometimes we luck out and get to take careful advantage of silly oversights on the part of the ‘bad guys’. In this case, we were able to find more than one active C2, where the initial config files were still present - in this case, install.php.

All of AlphaLocker’s configuration and support files are unencrypted and in English, while the author(s) appear to be Russian (based on data contained in some of the panel files, as well as the particular forums in which the ransomware is advertised). 

All of the included configuration and supporting files are shown below:


Figure 4: AlphaLocker C2 Panel Root 1

The included README file covers full installation, including setup of the panel itself (PHP modules, dependencies, etc.) as well as setup of the BTC-based payment system:


Figure 5: AlphaLocker README 1


Figure 6: AlphaLocker README 2


Figure 7: AlphaLocker README 3

The admin panel credentials AND the MySQL root credentials are stored, in plain text, within db.php in the server’s root:


Figure 8: AlphaLocker db.php

AlphaLocker’s admin login panel can be reached via login.php:


Figure 9: AlphaLocker Panel 1

Upon login, infected and encrypted hosts can be viewed and managed by the buyer. Stats and various maintenance settings are available as well. 


Figure 10: AlphaLocker Panel 2


Figure 11: AlphaLocker Panel 3


Figure 12: AlphaLocker Panel 4

The Malware

The actual ransomware executables for AlphaLocker are rather straightforward, given the EDA2 foundation. Files are individually encrypted with their own unique key (AES). AES keys are RSA-encrypted via a keypair stored in the local MySQL DB and posted to the C2. In general, for most EDA2-based malware, the flow is similar to the following:

  1. 1. The executable sends a POST request to the C2, which contains the unique ID for the victim.

  2. 2. The C2 creates the public/private RSA (2048) keypair, and sends the public key to the main ransomware executable. The private key remains stored in the DB.

  3. 3. A random AES key is generated (per file).

  4. 4. The ransomware executable encrypts each file with the newly generated AES key.

  5. 5. The AES key is encrypted with the RSA public key, and is then sent to the C2 via POST.

The samples we tested also modify the desktop background on the victim/host’s computer. A common thread across the EDA2-based threats is the hosting of background images on 

The affected encrypted file types can vary across samples. The individual buyer of the ransomware has the choice of file types to support. The default set of files, which will be encrypted across all available drives is as follows:

.asf, .pdf, .xls, .docx, .xlsx, .mp3, .waw, .jpg, .jpeg, .txt, .rtf, .doc, .rar, .zip, .psd, .tif, .wma, .gif, .bmp, .ppt, .pptx, .docm, .xlsm, .pps, .ppsx, .ppd, .eps, .png, .ace, .djvu, .tar, .cdr, .max, .wmv, .avi, .wav, .mp4, .pdd, .php, .aac, .ac3, .amf, .amr, .dwg, .dxf, .accdb, .mod, .tax2013, .tax2014, .oga, .ogg, .pbf, .ra, .raw, .saf, .val, .wave, .wow, .wpk, .3g2, .3gp, .3gp2, .3mm, .amx, .avs, .bik, .dir, .divx, .dvx, .evo, .flv, .qtq, .tch, .rts, .rum, .rv, .scn, .srt, .stx, .svi, .swf, .trp, .vdo, .wm, .wmd, .wmmp, .wmx, .wvx, .xvid, .3d, .3d4, .3df8, .pbs, .adi, .ais, .amu, .arr, .bmc, .bmf, .cag, .cam, .dng, .ink, .jif, .jiff, .jpc, .jpf, .jpw, .mag, .mic, .mip, .msp, .nav, .ncd, .odc, .odi, .opf, .qif, .xwd, .abw, .act, .adt, .aim, .ans, .asc, .ase, .bdp, .bdr, .bib, .boc, .crd, .diz, .dot, .dotm, .dotx, .dvi, .dxe, .mlx, .err, .euc, .faq, .fdr, .fds, .gthr, .idx, .kwd, .lp2, .ltr, .man, .mbox, .msg, .nfo, .now, .odm, .oft, .pwi, .rng, .rtx, .run, .ssa, .text, .unx, .wbk, .wsh, .7z, .arc, .ari, .arj, .car, .cbr, .cbz, .gz, .gzig, .jgz, .pak, .pcv, .puz, .rev, .sdn, .sen, .sfs, .sfx, .sh, .shar, .shr, .sqx, .tbz2, .tg, .tlz, .vsi, .wad, .war, .xpi, .z02, .z04, .zap, .zipx, .zoo, .ipa, .isu, .jar, .js, .udf, .adr, .ap, .aro, .asa, .ascx, .ashx, .asmx, .asp, .indd, .asr, .qbb, .bml, .cer, .cms, .crt, .dap, .htm, .moz, .svr, .url, .wdgt, .abk, .bic, .big, .blp, .bsp, .cgf, .chk, .col, .cty, .dem, .elf, .ff, .gam, .grf, .h3m, .h4r, .iwd, .ldb, .lgp, .lvl, .map, .md3, .mdl, .nds, .pbp, .ppf, .pwf, .pxp, .sad, .sav, .scm, .scx, .sdt, .spr, .sud, .uax, .umx, .unr, .uop, .usa, .usx, .ut2, .ut3, .utc, .utx, .uvx, .uxx, .vmf, .vtf, .w3g, .w3x, .wtd, .wtf, .ccd, .cd, .cso, .disk, .dmg, .dvd, .fcd, .flp, .img, .isz, .mdf, .mds, .nrg, .nri, .vcd, .vhd, .snp, .bkf, .ade, .adpb, .dic, .cch, .ctt, .dal, .ddc, .ddcx, .dex, .dif, .dii, .itdb, .itl, .kmz, .lcd, .lcf, .mbx, .mdn, .odf, .odp, .ods, .pab, .pkb, .pkh, .pot, .potx, .pptm, .psa, .qdf, .qel, .rgn, .rrt, .rsw, .rte, .sdb, .sdc, .sds, .sql, .stt, .tcx, .thmx, .txd, .txf, .upoi, .vmt, .wks, .wmdb, .xl, .xlc, .xlr, .xlsb, .xltx, .ltm, .xlwx, .mcd, .cap, .cc, .cod, .cp, .cpp, .cs, .csi, .dcp, .dcu, .dev, .dob, .dox, .dpk, .dpl, .dpr, .dsk, .dsp, .eql, .ex, .f90, .fla, .for, .fpp, .jav, .java, .lbi, .owl, .pl, .plc, .pli, .pm, .res, .rsrc, .so, .swd, .tpu, .tpx, .tu, .tur, .vc, .yab, .aip, .amxx, .ape, .api, .mxp, .oxt, .qpx, .qtr, .xla, .xlam, .xll, .xlv, .xpt, .cfg, .cwf, .dbb, .slt, .bp2, .bp3, .bpl, .clr, .dbx, .jc, .potm, .ppsm, .prc, .prt, .shw, .std, .ver, .wpl, .xlm, .yps, .1cd, .bck, .html, .bak, .odt, .pst, .log, .mpg, .mpeg, .odb, .wps, .xlk, .mdb, .dxg, .wpd, .wb2, .dbf, .ai, .3fr, .arw, .srf, .sr2, .bay, .crw, .cr2, .dcr, .kdc, .erf, .mef, .mrw, .nef, .nrw, .orf, .raf, .rwl, .rw2, .r3d, .ptx, .pef, .srw, .x3f, .der, .pem, .pfx, .p12, .p7b, .p7c, .jfif, .exif

Example: (where xxxxx is a random string of letters).


Figure 13: Background Image Direct 1


Figure 14: Background Image Direct 2

AlphaLocker is not the only family of ransomware pulling their wallpaper from in this fashion. Another EDA2-based kit known as SkidLocker does the same:


Figure 15: SkidLocker Background 1

Skidlocker strings show the hosting of the image as follows:

http : //
http : //
http : //
http : //
http : //
http : //
http : //
http : // 

Upon infection and subsequent encryption of files, the victim is provided with a simple text file with instructions on how to pay the ransom. Key.php is typically hosted on the same C2 server, and the victim’s unique ID is passed to key.php as a parameter:


Figure 16: AlphaLocker Ransom Note (README Notepad File)

When the victim browses to the assigned URL, they will see the following BTC payment interface:



Figure 17: AlphaLocker BitCoin Payment page

So, as far as EDA2-based ransomware goes, AlphaLocker sticks close to default. 

CylancePROTECT vs. AlphaLocker

Moving onto detection, we gathered multiple samples of AlphaLocker from a variety of sources and pitted them against CylancePROTECT. CylancePROTECT detected and prevented 100% of the AlphaLocker samples tested:


Figure 18: CylancePROTECT Minimized View, Showing Quarantined AlphLocker Files


Figure 19: CylancePROTECT Console View

Hashes (SHA256)


Believe the math!!!

Convinced that the next generation of endpoint security is right for your organization? Contact a Cylance expert to get started!

Jim Walter

About Jim Walter

Senior Security Researcher at Cylance

Jim Walter is a Senior Security Researcher at Cylance.