Techie Feeds

Explained: Sage ransomware

Malwarebytes - Wed, 03/29/2017 - 15:00

Sage is yet another ransomware that has become a common threat nowadays. Similarly to Spora, it has capabilities to encrypt files offline. The malware is actively developed and currently, we are facing an outbreak of version 2.2. of this product.

Analyzed samples Distribution method

Most often, Sage is dropped by downloader scripts distributed via phishing e-mails (office documents with malicious macros or standalone JS files). In the analyzed case, the sample was dropped via a JavaScript file.

Behavioral analysis

After being deployed, Sage deletes the original sample and runs another copy, dropped in %APPDATA% (names of the dropped files are different for different machines – probably generated basing on GUID):

The dropped copy deploys itself once again, with a parameter ‘g’. Example:

"C:\Users\tester\AppData\Roaming\FkGtk5ju.exe" g

After finishing its work, that dropped copy is also being deleted with the help of a batch script dropped in the %TEMP% folder.

The content dropped in %TEMP% is shown on the below picture. We can see the batch scripts and the BMP that is being set as a wallpaper:

Sample contents of the batch scripts is given below. As we can see, the ping command is used to delay operations.

Just in case the system gets restarted before the encryption finished, Sage sets a link in the Startup folder, so that it can continue after the reboot:

However, if the ransomware successfully completed encryption process and deleted itself, the link is left abandoned.

After finishing, the wallpaper is changed. In version 2.2 the wallpaper looks very similar to 2.0, except the font is green instead of red:

At the end of the execution, the ransom note !HELP_SOS.hta opens automatically:

In addition to the written information, Sage 2.2 plays a voice message informing about the infection. It is deployed via WScript running the default Microsoft voice-to-speech service – just like in the case of Cerber.

Some content is left in %APPDATA%:

Encrypted files are added to the “sage”extension and their icons are changed:

Visualization of a file – before and after encryption:

Files with the same plaintext produce different ciphertexts, that leads to the conclusion that each file is encrypted with a new key.

Sage can work well without internet connection, however, if connected it sends data via UDP (similarly to Cerber):

The traffic is encrypted:

Page for the victim

The ransom note contains a link to the page for the victim. Encrypted and Base64 encoded key of the victim is passed via URL to the server of attackers. Example: http://7gie6ffnkrjykggd.onion/login/AQAAAAAAAAAAv4NRzsVPkfwPPWixq2mqtFwGWlZTeCDpL_BGPyeJFhDA

The key can be also pasted via field on the website:

Keep in mind that the first login on the page for the victim triggers the timer to start. From this moment, the countdown to the price increment is running.

The website is protected by a simple captcha and allows for a simple customization – the victim can choose one of the supported languages (currently 17):

The page contains typical information, such as the amount of ransom to be paid and further instructions:

The malware allows to test decryption capabilities by permitting the victim to upload some encrypted files (the size of the file must be lesser than 15 KB):

However, the result is not available instantly:

After some hours, the decrypted version of the uploaded file is indeed available to download:


Sage is delivered packed by various crypters. After defeating the first layer we obtain second PE file – the malicious core, that is not further obfuscated.

At the beginning of the execution, Sage generates the Victim ID/key and saves it in the .tmp file dropped in %APPDATA% folder. Then, it removes backups from the system:

Executed commands:

vssadmin.exe delete shadows /all /quiet bcdedit.exe /set {default} recoveryenabled no bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures

Sage enumerates through the files, and if they matched the defined criteria, they are getting encrypted. First, the malware creates a file with the same name as the attacked one, but with three dots at the end.

Both files coexist in the system until the encrypting is finished.

Then, the original file is deleted and the newly created one – renamed with the extension .sage:

At the end, only the .sage file is left:

What is attacked?

Sage comes with a long list of the attacked extensions, that is hard-coded in the binary:

dat mx0 cd pdb xqx old cnt rtp qss qst fx0 fx1 ipg ert pic img cur fxr slk m4u mpe mov wmv mpg vob mpeg 3g2 m4v avi mp4 flv mkv 3gp asf m3u m3u8 wav mp3 m4a m rm flac mp2 mpa aac wma djv pdf djvu jpeg jpg bmp png jp2 lz rz zipx gz bz2 s7z tar 7z tgz rar ziparc paq bak set back std vmx vmdk vdi qcow ini accd db sqli sdf mdf myd frm odb myi dbf indb mdb ibd sql cgn dcr fpx pcx rif tga wpg wi wmf tif xcf tiff xpm nef orf ra bay pcd dng ptx r3d raf rw2 rwl kdc yuv sr2 srf dip x3f mef raw log odg uop potx potm pptx rss pptm aaf xla sxd pot eps as3 pns wpd wps msg pps xlam xll ost sti sxi otp odp wks vcf xltx xltm xlsx xlsm xlsb cntk xlw xlt xlm xlc dif sxc vsd ots prn ods hwp dotm dotx docm docx dot cal shw sldm txt csv mac met wk3 wk4 uot rtf sldx xls ppt stw sxw dtd eml ott odt doc odm ppsm xlr odc xlk ppsx obi ppam text docb wb2 mda wk1 sxm otg oab cmd bat h asx lua pl as hpp clas js fla py rb jsp cs c jar java asp vb vbs asm pas cpp xml php plb asc lay6 pp4 pp5 ppf pat sct ms11 lay iff ldf tbk swf brd css dxf dds efx sch dch ses mml fon gif psd html ico ipe dwg jng cdr aep aepx 123 prel prpr aet fim pfb ppj indd mhtm cmx cpt csl indl dsf ds4 drw indt pdd per lcd pct prf pst inx plt idml pmd psp ttf 3dm ai 3ds ps cpx str cgm clk cdx xhtm cdt fmv aes gem max svg mid iif nd 2017 tt20 qsm 2015 2014 2013 aif qbw qbb qbm ptb qbi qbr 2012 des v30 qbo stc lgb qwc qbp qba tlg qbx qby 1pa ach qpd gdb tax qif t14 qdf ofx qfx t13 ebc ebq 2016 tax2 mye myox ets tt14 epb 500 txf t15 t11 gpc qtx itf tt13 t10 qsd iban ofc bc9 mny 13t qxf amj m14 _vc tbp qbk aci npc qbmb sba cfp nv2 tfx n43 let tt12 210 dac slp qb20 saj zdb tt15 ssg t09 epa qch pd6 rdy sic ta1 lmr pr5 op sdy brw vnd esv kd3 vmb qph t08 qel m12 pvc q43 etq u12 hsr ati t00 mmw bd2 ac2 qpb tt11 zix ec8 nv lid qmtf hif lld quic mbsb nl2 qml wac cf8 vbpf m10 qix t04 qpg quo ptdb gto pr0 vdf q01 fcr gnc ldc t05 t06 tom tt10 qb1 t01 rpf t02 tax1 1pe skg pls t03 xaa dgc mnp qdt mn8 ptk t07 chg #vc qfi acc m11 kb7 q09 esk 09i cpw sbf mql dxi kmo md u11 oet ta8 efs h12 mne ebd fef qpi mn5 exp m16 09t 00c qmt cfdi u10 s12 qme int? cf9 ta5 u08 mmb qnx q07 tb2 say ab4 pma defx tkr q06 tpl ta2 qob m15 fca eqb q00 mn4 lhr t99 mn9 qem scd mwi mrq q98 i2b mn6 q08 kmy bk2 stm mn1 bc8 pfd bgt hts tax0 cb resx mn7 08i mn3 ch meta 07i rcs dtl ta9 mem seam btif 11t efsl $ac emp imp fxw sbc bpw mlb 10t fa1 saf trm fa2 pr2 xeq sbd fcpa ta6 tdr acm lin dsb vyp emd pr1 mn2 bpf mws h11 pr3 gsb mlc nni cus ldr ta4 inv omf reb qdfx pg coa rec rda ffd ml2 ddd ess qbmd afm d07 vyr acr dtau ml9 bd3 pcif cat h10 ent fyc p08 jsd zka hbk bkf mone pr4 qw5 cdf gfi cht por qbz ens 3pe pxa intu trn 3me 07g jsda 2011 fcpr qwmo t12 pfx p7b der nap p12 p7c crt csr pem gpg key

In order to access all the files without any interference, Sage searches and terminates any associated processes. Processes are identified by their names:

msftesql.exe sqlagent.exe sqlbrowser.exe sqlservr.exe sqlwriter.exe oracle.exe ocssd.exe dbsnmp.exe synctime.exe mydesktopqos.exe agntsvc.exe isqlplussvc.exe xfssvccon.exe mydesktopservice.exe ocautoupds.exe encsvc.exe firefoxconfig.exe tbirdconfig.exe ocomm.exe mysqld.exe mysqld-nt.exe mysqld-opt.exe dbeng50.exe sqbcoreservice.exe

As it is common in ransomware, some paths are excluded from the attack. In this case, blacklisted are not only system directories, but also others, related to popular games like “League of Legends”, “steamapps”, “GOG Games”, and etc.

tmp Temp winnt 'Application Data' AppData ProgramData 'Program Files (x86)' 'Program Files' '$Recycle Bin' '$RECYCLE BIN' Windows.old $WINDOWS.~BT DRIVER DRIVERS 'System Volume Information' Boot Windows WinSxS DriverStore 'League of Legends' steamapps cache2 httpcache GAC_MSIL GAC_32 'GOG Games' Games 'My Games' Cookies History IE5 Content.IE5 node_modules All Users AppData ApplicationData nvidia intel Microsoft System32 'Sample Music' 'Sample Pictures' 'Sample Videos' 'Sample Media' Templates

Some countries (recognized by keyboard layouts) are also excluded from the attack. Below is the function checking if the selected keyboard layout is present in the system:

Systems with the following keyboard layouts are omitted by Sage 2.2: Belarusian, Kazak, Ukrainian, Uzbek, Sakha, Russian, Latvian.

How does the encryption works?

Sage uses two cryptographic algorithms: Elliptic Curves and ChaCha20. ChaCha20 is used to encrypt content of each file, while ECC is used to protect the randomly generated keys.

Each random key is retrieved using a cryptographically secure generator (SystemFunction036). The filled buffer is preprocessed by a simple algorithm:

Victim ID

At the beginning of the execution, Sage creates a random buffer and encrypts it using ECC. The buffer created in the first round of encryption we will refer as a Victim ID and the output of the next rounds – as Encrypted Victim ID.

In the first round, the random value is encrypted using ECC, producing the Victim ID.

In the second round, the same random value is encrypted using ECC along with another buffer, that is hardcoded in the binary. The output is processed in the similar way like the random buffer:

In the third round, the resulting buffer is again encrypted by ECC – producing the Encrypted Victim ID.

Both output buffers are kept in the memory of the application and used further (also they are saved in the TMP file dropped in %APPDATA% folder).

The part highlighted on the screenshot is the Victim ID (after that, next 32 bytes are the Encrypted Victim ID):

The victim ID is also saved in the ransom note, in Base64* encrypted version:

*The character set is slightly modified in comparison to the classic Base64. In order to decode it as Base64 we must replace ‘-‘ with ‘+’ and ‘_’ with ‘/’ for example the ID: AQAAAAAAAAAAGwsZ-IAO5_pntzI3UnC8VweSZXaKQ0gTJ9PRS8AkiAnA is Base64: AQAAAAAAAAAAGwsZ+IAO5/pntzI3UnC8VweSZXaKQ0gTJ9PRS8AkiAnA

In addition, the Victim ID is also saved in each and every encrypted file:

The Encrypted Victim ID takes part in encrypting file’s content (as a key unique per victim).

File encryption

At the beginning of the file encrypting function, a new 32 bytes long key is generated (unique per each file).

The random number is encrypted with the help of ECC twice:

  • Individually – to make the key1 that is stored in the file
  • Along with the Encrypted Victim’s ID – to make the key2, used by ChaCha20

As we can see, the key2 is used to initialize the cryptographic function’s context. ChaCha20 can be recognized by typical constants used in the initialization function:

The file is encrypted chunk by chunk (the maximal chunk size is 0x20000) with the help of ChaCha20:

At the end of the file, the first derived key (key1) and some additional data is appended:

Appended data is separated from the encrypted file’s content by two hard-coded markers: 0x5A9EDEAD and 0x5A9EBABE

Markers at the end of the encrypted file:

After the first marker Sage stores the following information: Victim ID, Key1, size of the original file.

Network communication

Sage does not need any data from the CnC in order to work. However, as mentioned before, it may generate some UDP traffic. It is because it has capabilities to send some data about the attacked system. Depending on the configuration, the data may be sent either via UDP or via HTTP POST request. The data is encrypted before being sent – also with the help of ChaCha20 algorithm. In the observed case, the ChaCha20 key was a buffer filled with 0 bytes.

Examples of the data sent to the CnC

Sage sends the generated keys to the CnC, i.e.:

Compare with the buffer before encryption:

The same data is also formatted into a human-readable form, like shown below. However, so far we didn’t observed any use of this data. It may be some unfinished feature, that will be developed further in new versions of this product. Formatted equivalent of the above buffer:

[bin(33) 01CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, 4, { "v": 1, "gpk": bin(32) CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, "pk": bin(32) 2BB7BD5394B845629C90BB2B43D9655DC9C86347C4C695AB18150D7031B9E41F, }]

Other examples – collected information about the attacked machine:

[bin(33) 01CB3B94D965A389978A16035ED700C87A780088730989C24C581325340A866C4B, 3, { "s": { "w": { "v": [ 6, 1, false, false, 7601, 1, 0, ], "u": "tester", "p": "TESTMACHINE", }, "c": " Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz", "m": 232, "k": [68486165, 4026598409, 4026991637], }, "i": 12288, "w": null, }] Adding icons

Interesting and uncommon feature deployed by Sage is the change of icons for the used datatypes. Padlock icon is added to the encrypted files with the .sage extension and the key icon is added to the files with .hta extensions (that are used for the ransom notes). Icon change is implemented via setting appropriate registry keys:


Sage, similar to Spora, uses a complex way of deriving keys. So far, there is no solution that would allow recovering files without paying the ransom – that’s why we recommend focusing on prevention instead. Malwarebytes 3.0 Premium users are protected from Sage ransomware as long as it is installed prior to being infected.

Appendix  – Fortinet about Sage 2.0

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog:

The post Explained: Sage ransomware appeared first on Malwarebytes Labs.

Categories: Techie Feeds

What are exploits? (And why you should care)

Malwarebytes - Wed, 03/29/2017 - 14:00

Exploits: they’re not your mama’s cyberthreats. At one point in the not-so-distant past, exploits were responsible for delivering 80 percent of malware to people’s systems. But exploits seem to be experiencing a lull today. Does this mean they’re gone for good and we can all let down our guard? Or is this simply the calm before the storm? Let’s break down this stealthy threat so you can not only know your enemy, but also be appropriately prepared should the exploit attacks return.


What is an exploit?

An exploit is a program or piece of code that finds and takes advantage of a security flaw in an application or system so that cybercriminals can use it for their benefit, i.e., exploit it.

Cybercriminals frequently deliver exploits to computers as part of a kit, or a collection of exploits, that is hosted on websites or hidden on invisible landing pages. When you land on one of these sites, the exploit kit automatically fingerprints your computer to see which operating system you are on, which programs and you have running, and most importantly, whether any of these have security flaws, called vulnerabilities. It is basically looking at your computer for weaknesses to exploit—not unlike the Trojans did with Achilles’ heel.

After discovering vulnerabilities, the exploit kit uses its pre-built code to essentially force the gaps open and deliver malware, bypassing many security programs.

So are exploits a form of malware? Technically, no. Exploits are not malware themselves, but rather methods for delivering the malware. An exploit kit doesn’t infect your computer. But it opens the door to let the malware in.


How do exploits attack?

People most often come across exploit kits from booby-trapped high-trafficked websites. Cybercriminals typically choose popular, reputable sites in order to reap the highest return on their investment. This means the news sites you read, the website you use to browse real estate, or the online store where you buy your books are all possible candidates. Sites such as,, and have been compromised in the past.

So you’re surfing the web, stopping by a website you love, and the compromised site redirects you in the background, without opening any new browser windows or alerting you in any other way so that you can be scanned for suitability for infection. Based on this, you are either selected for exploitation or discarded.

How is your favorite website compromised? In one of two ways: 1. A piece of malicious code is hidden in plain sight on the website (via good old-fashioned hacking) 2. An advertisement that is displayed on the website has been infected. These malicious ads, known as malvertising, are especially dangerous, as users don’t even need to click on the ad in order to be exposed to the threat. Both methods, hacked sites or malvertising, immediately redirect you (point your web browser) to an invisible landing page that is hosting the exploit kit. Once there, if you have vulnerabilities on your computer, it’s game over.

The exploit kit identifies vulnerabilities and launches the appropriate exploits in order to drop malicious payloads. These payloads (the malware) can then execute and infect your computer with all kinds of bad juju. Ransomware is a particular favorite payload of exploit kits these days.


Which software is vulnerable?

In theory, given enough time, every piece of software is potentially vulnerable. Specialist criminal teams spend lots of time pulling apart programs so they can find vulnerabilities. However, they typically focus on the applications with the highest user-base, as they present the richest targets. As with all forms of cybercrime, it’s a numbers game. Top application targets include Internet Explorer, Flash, Java, Adobe Reader, and Microsoft Office.


How security folks fight it

Software companies understand that the programs they develop may contain vulnerabilities. As incremental updates are made to the programs in order to improve functionality, looks, and experience, so too are security fixes made to close vulnerabilities. These fixes are called patches, and they are often released on a regular schedule. For example, Microsoft releases a cluster of patches for their programs on the second Tuesday of each month, known as Patch Tuesday.

Companies may also release patches for their programs ad-hoc when a critical vulnerability is discovered. These patches essentially sew up the hole so exploit kits can’t find their way in and drop off their malicious packages.

The problem with patches is they often aren’t released immediately after a vulnerability is discovered, so criminals have time to act and exploit. The other problem is that they rely on users downloading those “annoying” updates as soon as they come out. Most exploit kits target vulnerabilities that have already been patched for a long time because they know most people don’t update regularly.

For software vulnerabilities that have not yet been patched by the company who makes them, there are technologies and programs developed by cybersecurity companies that shield programs and systems known to be favorites for exploitation. These technologies essentially act as barriers against vulnerable programs and stop exploits in multiple stages of attack, that way, they never have a chance to drop off their malicious payload.


Types of exploits

Exploits can be grouped into two categories: known and unknown, also called zero-day exploits.

Known exploits are exploits that security researchers have already discovered and documented. These exploits take advantage of the known vulnerabilities in software programs and systems (that perhaps users haven’t updated in a long time). Security professionals and software developers have already created patches for these vulnerabilities, but it can be difficult to keep up with all the required patches for every piece of software—hence why these known exploits are still so successful.

Unknown exploits, or zero-days, are used on vulnerabilities that have not yet been reported to the general public. This means that cybercriminals have either spotted the flaw before the developers noticed it, or they’ve created an exploit before developers get a chance to fix the flaw. In some cases, developers may not even find the vulnerability in their program that led to an exploit for months, if not years! Zero-days are particularly dangerous because even if users have their software fully updated, they can still be exploited, and their security can be breached.


Biggest exploit offenders

The three exploit kits most active in the wild right now are named RIG, Neutrino, and Magnitude. RIG remains the most popular kit, and it’s being used in both malvertising and website compromising campaigns to infect people’s machines with ransomware. Neutrino is a Russian-made kit that’s been used in malvertising campaigns against top publishers, and it preys on Java vulnerabilities (also to deliver ransomware). Magnitude is using malvertising to launch its attacks as well, though it’s strictly focused on countries in Asia.

Two lesser-known exploit campaigns, Pseudo-Darkleech and EITest, are currently the most popular redirection vehicles using compromised websites. These offenders inject code into sites such as WordPress, Joomla, or Drupal, and automatically redirect visitors to an exploit kit landing page.

As with all forms of cyberthreats, exploits, their methods of delivery, and the malware they drop are constantly evolving. It’s a good idea to stay on top of the most common forms to make sure the programs they target are patched on your computer.


Current exploit kit landscape

Right now, the exploit scene is pretty bleak, which is a good thing for those in the security industry and, essentially, for anyone using a computer. This is because in June 2016, Angler, a sophisticated exploit kit that was responsible for nearly 60 percent of all exploit attacks the year before, was shut down. There hasn’t been any other exploit kit that’s built up the same level of market share since.

Threat actors have been a bit gun shy about running back to exploit kits, for fear of another Angler takedown. Once Angler was dismantled, cybercriminals turned their focus back to some more traditional forms of attack, including phishing and emails with malicious attachments (malspam). But rest assured, they’ll be back once a new, more reliable exploit kit proves effective in the black market.


How to protect against exploits

The instinct may be to take little to no action to protect against exploits, since there’s not a lot of exploit-related cybercriminal activity right now. But that would be like choosing not to lock your doors since there hasn’t been a robbery in your neighborhood in a year. A couple of simple security practices can help you stay ahead of the game.

First, make sure you keep your software programs, plugins, and operating systems updated at all times. This is done by simply following instructions when reminded by those programs that updates are ready. You can also check settings from time to time to see if there are patch notifications that may have fallen off your radar.

Second, invest in cybersecurity that protects against both known and unknown exploits. Several next-generation cybersecurity companies, including Malwarebytes, have started integrating anti-exploit technology into their products.

So you can either kick back and pray that we’ve seen the last of exploits. Or, you can keep your shields up by consistently updating your programs and operating systems, and using top-notch anti-exploit security programs. The smart money says exploits will be back. And when they return, you won’t have a weak heel to expose to them.

The post What are exploits? (And why you should care) appeared first on Malwarebytes Labs.

Categories: Techie Feeds

A week in security (Mar 20th – Mar 26th)

Malwarebytes - Tue, 03/28/2017 - 22:40

Last week, we investigated Twitter app scammers using stolen celebrity nudes as bait, explored the world of Chinese PUPs and backdoors, took a deep dive into a Ramnit campaign targeting people in the UK and Canada, and looked at a bout of SMS Phishing. We also examined the claims of hackers in relation to wiping Apple devices and poked around a tech support screenlocker scam.


Stay safe, everyone!

Malwarebytes Labs Team

The post A week in security (Mar 20th – Mar 26th) appeared first on Malwarebytes Labs.

Categories: Techie Feeds

World of Warcraft phish campaign lures victims with free pet

Malwarebytes - Tue, 03/28/2017 - 15:00

A phishing campaign currently in circulation is attempting to bait World of Warcraft with the promise of free in-game pets. We’ve seen two variations on this so far, and it’s possible there’s more. Both of the below examples lead to the same phishing URL. As great as the promise of some free content is, this is nothing more than an attempt at stealing your gaming credentials.

One of the emails read as follows:

You are receiving this e-mail because Your friend has purchased World of Warcraft In-Game Pet: Brightpaw for you as a gift!
Claim Your Gift
To claim your gift, enter your Gift Key on the Account Management. You’ll be sent to the download page afterwards, if needed.

The second mail claims a “WoW mount mystic rune sabre” is up for grabs.

Keen Warcraft players will notice the email is branded with Battle(dot)net, the name of Blizzard’s online gaming service – but this name has just been retired, which may well set off a few alarm bells.

Both emails lead to a phish located at (deep breath):


The phish again touts the Battle(dot)net name and asks for an email and password.

Feel free to ignore this one and send it straight to your trash folder, there’s no free pets at the end of this path, just headaches and calls to customer support.

Christopher Boyd

The post World of Warcraft phish campaign lures victims with free pet appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Mobile Menace Monday: Preinstalled adware and sometimes worse

Malwarebytes - Mon, 03/27/2017 - 16:00

BLU manufactured mobile devices have been discovered with preinstalled adware known as Android/Adware.YeMobi.

Behavior of YeMobi

The incriminating behavior of adware YeMobi is its ability to launch the default browser on a mobile device and use it to display ads. There is an unusual element to this as well—it only displays ads while the Google Play store app is running.  As seen in the code below, if (the Google Play store app) is active, activity MessageLoadDetail is loaded.  Activity MessageLoadDetail then goes onto to display ads.

The rise of preinstalled malware

Buying a new phone only to find it comes preinstalled with adware or even more dangerous malware is frustrating.  Trust us, it’s just as frustrating not being able to remove these apps for our customers.

With the ease of selling online, Android devices re-imaged with custom ROMs(“Read-Only Memory”) containing preinstalled shady/malicious apps are starting to appear more and more on the online marketplace.  Sellers can easily re-image an Android device with a custom ROM which replaces the default operating system—typically stored in read-only memory. Sellers then turn around and sell these devices for cheap online.

Just like when installing apps, it’s important to buy your mobile device from trusted sources.  Avoid buying devices online from untrusted sellers/stores; even if the price is hard to pass up.

Disabling YeMobi and other preinstalled apps

In order to keep essential operating system apps from being removed on Android devices, you cannot uninstall preinstalled apps. However, you can disable some preinstalled apps—like Adware YeMobi. Simply go into settings > apps, find the YeMobi app, open its settings, and disable it via the Disable button.

Finding preinstalled malware on your device can be tricky—a mobile scanner can assist with finding them for you. Malwarebytes Anti-Malware Mobile detects Adware YeMobi along with other preinstalled malware and can be found for FREE on Google Play.

As always, stay safe out there!

The post Mobile Menace Monday: Preinstalled adware and sometimes worse appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Explained: Packer, Crypter, and Protector

Malwarebytes - Mon, 03/27/2017 - 15:00

In this article, we will try to explain the terms packer, crypter, and protector in the context of how they are used in malware. Bear in mind that no definitions for these categories are set in stone and that they all have overlap and that there are exceptions to the rules. But this is the classification that makes sense to me.

What they all have in common is their goal

The payload, which is the actual malware that the threat actor wants to run on the victims’ computers, is protected against reverse engineering and detection (by security software). This is done by adding code that is not strictly malicious, but only intended to hide the malicious code. So the goal is to hide the payload from the victim and from researchers that get their hands on the file.


This usually is short for “runtime packers” which are also known as “self-extracting archives”. Software that unpacks itself in memory when the “packed file” is executed. Sometimes this technique is also called “executable compression”. This type of compression was invented to make files smaller. So users wouldn’t have to unpack them manually before they could be executed. But given the current size of portable media and internet speeds, the need for smaller files is not that urgent anymore. So when you see some packers being used nowadays, it is almost always for malicious purposes. In essence to make reverse engineering more difficult, with the added benefit of a smaller footprint on the infected machine.


The crudest technique for crypters is usually called obfuscation. A more elaborate blog post on that is Obfuscation: Malware’s best friend. Obfuscation is also used often in scripts, like javascripts and vbscripts. But most of the time these are not very hard to bypass or de-obfuscate. More complex methods use actual encryption. Most crypters do not only encrypt the file, but the crypter software offers the user many other options to make the hidden executable as hard to detect by security vendors as possible The same is true for some packers. An in-depth analysis of one crypter (as an example) can be found in our blog post Malware Crypters – the Deceptive First Layer. Another thing you will find in that post is the expression FUD (Fully Undetectable) which is the ultimate goal for malware authors. Being able to go undetected by any security vendor is the holy grail for malware authors. But if they can go undetected for a while and then easily change their files again once they are detected, they will settle for that.


A protector in this context is software that is intended to prevent tampering and reverse engineering of programs. The methods used can, and usually will, include both packing and encrypting. That combination plus some added features makes what is usually referred to as a protector. So a researcher will be faced with protective layers around the payload, making reverse engineering difficult.

A completely different approach, which also falls under the umbrella of protectors, is code virtualization, which uses a customized and different virtual instruction set every time you use it to protect your application. Of these protectors there are professional versions that are used in the gaming industry against piracy. But the technique itself has also made its way into malware, more specifically ransomware. Which enables ransomware that doesn’t need a C&C server to communicate the encryption key. The protection is so efficient that the encryption key can be hardcoded into the ransomware. An example is Locky Bart that uses WProtect, an open-source code-virtualization project.


We discussed several techniques to protect malware against analysis, hoping to make sense of the different names that are in use for this class of programs.

The post Explained: Packer, Crypter, and Protector appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Advanis tech support screenlocker

Malwarebytes - Fri, 03/24/2017 - 15:00

Recently we noticed a change on one of the domains that we monitor because they are known to host files related to tech support scams and involved in browlocks, fake alerts, and screenlockers.

The domain and the screenlocker

At the moment the installer is being pushed by InstallCapital which is a pay-per-install network .

The domain hosting the installer is called installreports[dot]com and this time we found it was hosting a tech support screenlocker we dubbed Advanis after the folder it creates in the Windows directory and the entry it creates in the list of installed programs and features.

MT is the name of the main executable. The one that shows the screenlocker. Here it is probably short for “Market Tools”, which is the name of the Windows form.


@TheWack0lian found this code snippet –

–telling us that the screenlocker could be minimized by using the “Backspace” key. Once you have done that, removal is no problem. A full removal guide for Advanis can be found on our forums.

File details

SHA 256 of the installer 30a32cb629d2a576288b4536d241b6e90f0540c3275288bfd4982233e12d182f

Malwarebytes web protection module blocks the domain and detects the installer as Trojan.TechSupportScam.

The advertised number on the lockscreen leads back to the domain getfixpc[dot]net.


Finding out who is behind a threat is not always easy, but we think we have a solid case for this one.

Meet Baskar K.

He registered the domain installreports[dot]com with the email address:

Using his own name and providing his phone number and physical address.

The same personal data was used to register

That domain is listed as the homepage at the stackoverflow profile I posted a screenshot of.

For the same physical address we also found an email address baskark**** that has been used to register a host of dubious domains:


Those are all blocked now by Malwarebytes Web Protection Module.

Safe surfing!

Thanks to TheWack0lian and William Tsing for their additional research.


Pieter Arntz

The post Advanis tech support screenlocker appeared first on Malwarebytes Labs.

Categories: Techie Feeds

New targeted attack against Saudi Arabia Government

Malwarebytes - Thu, 03/23/2017 - 22:26

A new spear phishing campaign is targeting Saudi Arabia governmental organizations. The attack originates from a phishing email containing a Word document in Arabic language. If the victim opens it up, it will not only infect their system but send the same phishing document to other contacts via their Outlook inbox.

We know that at least about a dozen Saudi agencies were targeted. As with most email-borne attacks, this one leverages social engineering to execute malicious code via a Macro.

Document overview: Macro might run executable Contains obfuscated macro code Loads DLL into its own memory Runs dropped executable Macro might read system main characteristics Runs existing executable Macro might overwrite file Access Windows sensitive data: Windows Address Book Suspicious delay Starts macro code when document is opened Searches inside certificate store database Gathers system main data (MachineGuid, ComputerName, SystemBiosVersion ...) Check user main folders path Access Windows sensitive data: Windows Profiles information Contains macro Contains macro with create file functionalities Drops .EXE file Drops .DLL file Access Windows sensitive data: certificates

A quick analysis with oletools shows us the sections within the macro:

The payload is embedded in the macro as Base64 code. It uses the certutil program to decode the Base64 into a PE file which is then executed:

Binary overview: Searches inside certificate store database Loads DLL into its own memory Gathers system main data (MachineGuid, ComputerName, SystemBiosVersion ...) Access Windows sensitive data: Windows Profiles information Access Windows sensitive data: Windows Address Book Drops .DLL file Drops .EXE file Access Windows sensitive data: certificates

Let’s take a look at the dropped binary itself. It is coded in .NET and not obfuscated. Here’s the encrypted payload:

Decrypting it we can see the main payload (neuro_client.exe renamed to Firefox-x86-ui.exe here) and two helper DLLs: 

It sets persistence for auto-relaunch via the Task Scheduler:

The purpose of this piece of malware appears to be stealing information and uploading it to a remote server:

We can see that stolen data is then POSTed to a server at (Official Saudi Press Agency) although by the time we checked, the server was no longer responding:

According to reports from sources, Malwarebytes Anti-Exploit blocked the targeted attack proactively without the use of signature updates thanks to its Application Behavior protection layer for all consumer and corporate users of Malwarebytes. Malwarebytes Anti-Malware also detects and remediates the threat completely.

We will continue to analyze this threat and update the post at a later time with more information.


Word dropper:

MD5: 3cd5fa46507657f723719b7809d2d1f9 SHA256: a6dbc36c472b3ba70a98efd0db35e75c340086be15d3c3ab4e39033604d0bcf9

Binary payload:

MD5: 4ed42233962a89deaa89fd7b989db081 SHA256: a96c57c35df18ac20d83b08a88e502071bd0033add0914b951adbd1639b0b873

Payload names:

C:\ProgramData\*\*-x86-ui.exe with * being one of these: firefox|chrome|opera|abby|mozilla|google|hewlet|epson|xerox|ricoh|adobe|corel|java|nvidia|realtek|oracle|winrar|7zip|vmware|juniper|kaspersky|mcafee|symantec|yahoo|goog

Network communications: webmail.ecra/ews/exchange/exchange.asmx

The post New targeted attack against Saudi Arabia Government appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Hackers threaten to wipe Apple devices

Malwarebytes - Thu, 03/23/2017 - 15:00

According to a report from Motherboard, a group of hackers calling themselves “Turkish Crime Family” is threatening to remotely erase devices belonging to hundreds of millions of Apple customers. They will do this on April 7, they say, if Apple doesn’t pay them a ransom.

The hackers claim to have access to over 300 million iCloud e-mail addresses (addresses ending in,, or, and 559 million Apple ID accounts in all. (Keep in mind that an Apple ID need not be associated with an iCloud e-mail address.) However, the hackers have provided no proof of this, beyond a supposed YouTube video showing them logging on to a few iCloud accounts.

I’m a bit skeptical of these claims. I seriously doubt that they have the credentials to access that many accounts. There’s no indication that there has been an Apple ID breach, so it seems more likely that their source of credentials – if any – would be from phishing scams.

However, it would take time for phishing scams to gather that many accounts and some of the data gathered would “expire,” as people change passwords or enable two-factor authentication. (It’s not unusual for people to fall for a phishing scam, but get suspicious after they’ve provided their credentials due to unexpected results.)

It could also, of course, be a sham. The hackers could have a handful of credentials that they used to make their YouTube video and they’re pretending to have more in hopes that Apple will pay their ransom.

Still, there’s a very real chance that at least some number of Apple devices could get remotely locked or erased on April 7. If you have a Mac, iPhone, or iPad, what can you do to make sure this doesn’t happen to you? There are a few basic steps you can take to ensure that, if these hackers are telling the truth, you aren’t among the victims.


Change your password

First and foremost, change the password for your Apple ID. To do so, simply log in here:

Once you’re logged in, scroll down to the Security section and click the Change Password link.

Enable two-factor authentication

Your password is only one barrier to entry to your Apple ID account and it’s not really enough these days. Two-factor authentication (2FA) requires you to have two things in order to log in to your iCloud/Apple ID account: something you know (your password) and something you have. In the case of an Apple ID, that second factor is a trusted device, which could be any of your Apple devices.

When you enable two-factor authentication, you will get alerts on your trusted device(s) whenever someone tries to log in to your Apple ID. You will be shown a map of the general area the access is coming from and can allow or disallow it. If you allow it, you’ll be asked to enter a 6-digit code, which is displayed on your trusted device(s). This code is different every time.

Obviously, this isn’t much of a deterrent for someone who has physical access to one of your trusted devices and who knows your Apple ID password. However, this is quite good for protecting against remote access to your Apple ID by someone who has captured your password.

To learn more about Apple’s two-factor authentication, including how to enable it, see:

Note that if you currently have Apple’s older two-step verification turned on, which uses four-digit codes, that is pretty good, but not quite as secure. It’s adequate to protect against this particular threat, but at some point you should consider switching over to two-factor authentication.


Disable Find My Mac/iPhone

Personally, I want to keep this feature turned on for all my devices. This allows me to remotely wipe any device that has been lost or stolen, potentially find a lost device by making it play a loud sound, and other useful things. If you’ve taken the precautions above turning this feature off shouldn’t be necessary.

However, if your opinion differs from mine and you don’t want to be able to remotely locate and take action on a device from your iCloud account, you can disable Find My Mac or Find My iPhone on that device.

On a Mac, open System Preferences and click the iCloud icon. Then simply uncheck the Find My Mac box, at the bottom of the list.

On an iOS device (e.g. an iPhone or iPad), open the Settings app and tap the iCloud item, then scroll down to the Find My iPhone item.

If Find My iPhone is listed as being turned on, tap it, and on the next page, flip the “switch” to turn it off.

Once Find My Mac/iPhone is disabled, even if a hacker somehow manages to gain access to your iCloud account, they will be unable to remotely wipe or lock that device. That also means, however, that you will be unable to do anything about it if someone steals that device.


Back up your devices

If all else fails and your device does somehow get wiped – or if it gets lost, stolen, destroyed, the data is corrupted somehow, or any other issue that can cause data loss occurs – a good set of backups is important.

Your Mac can be backed up very easily using Time Machine, a third-party backup program, or one of the various cloud-based backup services. Whatever you do, make sure that your files are backed up both locally (on one or more hard drives in your home or office) as well as off-site (either an online backup or on a hard drive that you keep in another location).

Your iOS devices can be backed up to iCloud, but of course, if someone gains access to your iCloud account, that’s not adequate protection. I recommend also backing up onto your computer periodically via iTunes. If that computer is kept backed up, that protects your iOS device backups as well.

The post Hackers threaten to wipe Apple devices appeared first on Malwarebytes Labs.

Categories: Techie Feeds

SMS phishing for the masses

Malwarebytes - Wed, 03/22/2017 - 15:00

Phishing remains one of the top threats that affects both consumers and businesses thanks to ever evolving tricks. While ‘classic’ phishing emails remain a problem, they can somewhat be thwarted via spam filters, whereas SMS phishing scams are much more difficult to protect against.

Case in point, here’s a fraudulent text message purporting to be from RBC, a Canadian financial institution, which made it through our phone without getting blocked:

Text message: Activities on your RBC Account is unsual. click to secure

If you followed the instructions and visited the link, you’d be redirected to a decoy site looking almost exactly like the real one. The crooks have designed the template to harvest as many credentials as they can (i.e. driver’s license, phone number, all three security questions) in order to gain illegal access to your account:

Click to view slideshow.

It is pretty scary to think that within minutes you could give crooks all the information they need to perform all sorts of illegal activity on your bank account, as well as perpetrate additional identity theft by impersonating you.

Checking the IP address where the phishing page resides (, we find another phish for Bank Of Montreal (BMO), but also a domain ( used to host the PHP panel of an application called “Sendroid”.

Sendroid is a framework to help you manage your bulk SMS campaigns and in itself is not malicious. Users are required to have a proper SMS provider in order to actually start sending text messages.

However, some user comments left on Sendroid’s purchase page show how it could be easily abused by spammers:

 I have like 4000 contact to send sms to. And my gateway batch size is set to 200. Does this mean that, the sendroid portal will only allow me to send sms to 200 people out of the 4000?

That’s a lot of contacts, but who knows… could be a popular guy.

It would be interesting to know the success rates of such phishing campaigns. Much like regular spam, it’s all about volume and even getting a small fraction of marks is enough to make it profitable.

Please be on the lookout for such fraudulent SMS text messages. The “intimacy” of receiving a message on a phone makes this scheme even more dangerous because we are more likely to have our guards down and fall for it.

This campaign was reported to RBC and the website has been blacklisted.

The post SMS phishing for the masses appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Canada and the U.K. hit by Ramnit Trojan in new malvertising campaign

Malwarebytes - Tue, 03/21/2017 - 15:48

Over the last few days we have observed an increase in malvertising activity coming from adult websites that have significant traffic (several million monthly visits each). Malicious actors are using pop-under ads (adverts that load in a new browser window under the current active page) to surreptitiously redirect users to the RIG exploit kit.

This particular campaign abuses the ExoClick ad network (ExoClick was informed and took action to stop the fraudulent advertiser based on our reports) and, according to our telemetry, primarily targets Canada and the U.K.. The ultimate payloads we collected during this time period were all the Ramnit information stealer (banking, FTP credentials, etc.) which despite a takedown in 2015 has rebounded and is quite active again.

Pop-under ads and TDS

Pop-under ads are usually triggered when a user clicks on an item on the site they are browsing. In this particular example, clicking on one of the category thumbnails launches the pop-under window behind the main page.

Figure1: Pop-under advert fires up RIG EK (blocked by Malwarebytes)

The first stage redirection includes a link to within two different JavaScript snippets. This Traffic Distribution System (TDS) mostly loads benign adult portals/offers via ExoClick. The actual malvertising incident takes place next with a 302 redirect to a malicious TDS this time, which performs some geolocation fingerprinting and checks the upper referer before loading the RIG exploit kit.

Traffic overview:

Figure 2: Web traffic showing redirection chain to RIG EK from


Redirection chain:

Figure 3: TDS redirection based on the user’s geolocation

We noted the same attack pattern with several other adult portals using the malicious TDS mentioned above to load RIG EK:

Figure 4: Web traffic showing redirection chain to RIG EK from

Ramnit going after Canada and the U.K.

The payloads we collected via our honeypot were all the Ramnit Trojan, which is interesting considering the traffic flow from the TDS (Canada, U.K. being the most hits recorded in our telemetry). A report from IBM security researcher Limor Kessem in December 2015 indicated that Canada was the top target with 55% of all Ramnit activity. A follow up report from the same researcher in August 2016 showed a new wave of attacks directed this time at the U.K.

We informed ExoClick and they have been able to locate and terminate the rogue advertiser. Malwarebytes users were already protected against this distribution campaign and the Ramnit Trojan.


Malware hashes:

53ba545c599a66a148e590b11e9cdc0d49141b03d9f870fcd52593f39bcd690d 845824afa87c0eccf25b09cbf57fbe2ab9e356b6cdbac220271e9c4e732bb174 3feb4c5198cd00361dc5631334288f9ba6a25b3d35028b0cd10f453525ff1c9e c72e3c5120e948599a2f6f215a7ef53f71763ce16303782872bab9cf5599610a be3705cf0964cebe7084439f502ae4d40fc063693be44fbe54fe7a9f8ae180df 228af3aa07a2c37badf83cdd552710434601d8f3abf60df8d8264cdf3f694d70

RIG EK domains:


The post Canada and the U.K. hit by Ramnit Trojan in new malvertising campaign appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Chinese PUPs and backdoor drivers: making systems less secure since 2013

Malwarebytes - Mon, 03/20/2017 - 15:00

PUPs affect systems all across the world and are developed in many countries. A few weeks ago I came across an installer for a China-developed WiFi hotspot application, targeting English speakers, and being dropped by one of the major PUP bundler networks (it has since started to be dropped by another). The SHA-256 hash for the installer is B89017C2627CA80C68292453440CFCAE07A12798422737915F80F0720879C3D4.

The PUP bundler runs the installer with the /silent command line argument. The installer drops a bunch of files; there’s a .7z file in its resources, with the first two bytes swapped (probably to prevent easy detection as .7z SFX by decompression tools).

Among these files are two drivers with the same functionality (one for 32-bit Windows and the other for 64-bit Windows). The SHA-256 hash of the 32-bit driver is: E6427DF5D439EE854485C1C1BC8747487B5F0848D5EBA98838BD8F377F9E8DBE, and the SHA-256 hash of the 64-bit driver is: E5BC7CC800866C749FC588F5FC2F31D8B3202DD9EE3F40D450528AC08B08F311. When obtained, these two drivers had very low detection rates (the 64-bit driver was fully undetected).


Drivers in a PUP always make me suspicious, so these files naturally warranted a further look. Analysis below will be performed on the 32-bit driver.

At the entry point of the driver, one of the first things done is to check the OS version. If the OS version is not one of the following, the driver will not load:

  • Kernel major version 5
    • Windows 2000
    • Windows XP
    • Windows Server 2003
    • Windows XP x64
  • Kernel major version 6
    • Windows Vista / Server 2008
    • Windows 7 / Server 2008 R2
    • Windows 8 / Server 2012
    • Windows 8.1 / Server 2012 R2
    • Early Windows 10 builds (up to build 988x)
  • Kernel major version 10, minor version 0, build number less than or equal to 14393
    • Windows 10 (build 10240 / v1507)
    • Windows 10 v1511
    • Windows 10 v1607 / Server 2016

Most notable is the build number check that means that on any version of Windows later than Windows 10 v1607, the driver will not load.

If this check passes, the driver continues to set itself up, setting the DriverObject MajorFunctions, creating the device, etc. This overt functionality may or may not be malicious.

However, soon before returning from the driver entry point, another function is called.

This function repeats the version check done previously and then creates another device, HelpDetectWz, and hooks the MajorFunctions that were set up previously:

Afterwards, a couple of lists are created, a function is called that resolves some kernel APIs (manually, by getting the kernel filename, loading the kernel again into memory, and then parsing its exports — resolved API name strings are also obfuscated, by ROT-1), and creates a new thread.

The main API for drivers like this are IOCTLs. The HelpDetectWz device has code for two of them: 0x8000C004 and 0x800C00C.

Three exports that got resolved on driver load are nt!KdDisableDebugger, nt!KdEnableDebugger, and nt!KdDebuggerEnabled.

These are used by the IOCTL code as anti-debug: each IOCTL wraps its real code around calls to KdDisableDebugger() and KdEnableDebugger() to try and prevent the use of a kernel debugger to step through the code. In addition, one of the IOCTLs checks KdDebuggerEnabled to see if the debugger really was disabled, and doesn’t perform the real functionality (after setting up inputs) if it wasn’t disabled.

(If you have a kernel debugger setup and you’re working with the drivers above, you could easily patch out those calls/jump in memory using the kernel debugger before calling the IOCTL!)

In addition, both IOCTLs’ input buffers have to be obfuscated. The obfuscation is XOR with a static 1024-byte key:

Now that this background information has been given, let’s move on to the relevant IOCTL code.

The first IOCTL copies deobfuscated data from the passed IOCTL buffer into a structure and if the kernel debugger really is disabled, adds that structure to a list. It then waits for some operation to complete before returning a value from that structure. This value is copied into the IOCTL buffer to then be returned to the caller.

Upon further investigation, that operation to be completed happens in the thread that was started at driver load.

This thread waits to be triggered, then while the driver is loaded it gets the last value added to that list, calls a function on it, then waits to be triggered again. If the driver gets unloaded, the driver unload function flips a global variable, which causes this thread to clean up (so no callers get stuck waiting for an operation that will never complete).

The function that gets called? It resolves some APIs (in the already loaded kernel), deobfuscates part of the buffer that was copied into the structure (again, so this part of the buffer is doubly-encrypted, using the same XOR key), loads it as a PE, gets its entry point, and calls it using IoCreateDriver, with no signature checks whatsoever.

So, this driver contains a backdoor enabling the defeat of Driver Signature Enforcement. If the driver has already been installed on a system, it doubles as a local privilege escalation, as non-administrators can also call the IOCTLs.

Further investigation

After finding this backdoor, I searched online for the device name `HelpDetectWz`, and found a post on a Chinese forum from 2013 describing a very similar driver inside a calendar application.

Searching on VirusTotal enabled me to find several Chinese applications with similar drivers including the very same backdoor.

Even more interesting, some of these similar drivers have some obfuscated code, up to and including being packed with VMProtect:

Clearly, some Chinese developer really didn’t want their backdoor to be discovered.

Some of the applications including these drivers include a Chinese Android rooting toolkit, a Chinese driver updater (there’s an English version available, which doesn’t include the drivers for some reason), a Chinese WiFi hotspot application (Chinese version of the PUP that the driver was initially discovered in, perhaps), and a Chinese USB drive helper utility. The latest version of the mentioned Chinese calendar application no longer contains the driver.


A PoC to use the HelpDetectWz functionality to load an unsigned driver is available here — included are source and binaries to two test drivers (x86 and x64, coded in pure assembler), which will bug check the system when loaded. Many thanks to slipstream of Ring of Lightning for the PoC!

Malwarebytes 3.0 detects the drivers and related applications and installers as PUP.Optional.WifiHotspot, Rootkit.HelpDetectWz.PUA and Rootkit.DriveTheLife.PUA.

The post Chinese PUPs and backdoor drivers: making systems less secure since 2013 appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Twitter app spams Fappening bait and Amazon surveys

Malwarebytes - Mon, 03/20/2017 - 13:37

With news of another so-called Fappening (nude photos of celebrities distributed without permission) doing the rounds, it was inevitable that scammers would look to take advantage. We’ve already seen message board aficionados warn others of dodgy download links and random Zipfiles claiming to contain stolen nude photos and video clips, but today we’re going to look at one specific spam campaign aimed at Twitter users.

The daisy chain begins with multiple links claiming to display stolen images of Paige, a well known WWE wrestler, caught up in the latest dump of files. With regards to two specific messages, we saw close to 300 over a 24 hour period (and it’s possible there were others we didn’t see). These appear to have been the most common, however.

The messages read as follows:

1) “VIDEO: WWE Superstar Paige Leaked Nude Pics and Videos”

2) “Incredible!!! Leaked Nude Pics and Videos of WWE Superstar Paige!!!!: [url] (Acept the App First)”

Well, that doesn’t sound suspicious at all.

The Bit(dot)ly link, so far clicked close to 7,000 times, resolves to the following:


That smoothly segues into an offered Twitter App install tied to a site called Viralnews(dot)com.

The app permissions are as follows:

This application will be able to:

Read Tweets from your timeline.
See who you follow, and follow new people.
Update your profile.
Post Tweets for you.

Will not be able to:

Access your direct messages.
See your email address.
See your Twitter password.

We’ll come back to the app later, but as far as the Viralnews goes, it appears to play no part in what lies ahead (and looks like a very retro linkdump site). Once the app is installed, would-be picture viewers are sent to a site located at


The site reinforces the idea that salacious stolen imagery is on the way – except that the site quickly greys out and makes it clear you have to click yet another link to continue. It’s another bit(dot)ly (highlighted in the bottom left hand corner), which (after another redirect) took us to the following URL:


We have a landing page, still promising stolen images (and indeed, serving one up) with the continuing promise of more to come. From the blurb:

1 First Click on the Bottom Download
2 Then you will be redirected to an Amazon Giftcard Website where you have to Leave your Email
3 Leave your Email in the Blank Box to win an Amazon Giftcard and Click on SUBMIT
4 Then You will be Redirected to a MEGA Download where you could Download Paige Leaked Videos and Photos

As per the screenshot, there’s one final redirect URL (a bit(dot)do address) which took us to an Amazon themed survey gift card page. Suffice to say, filling this in hands your personal information to marketers – and there’s no guarantee you’ll get any pictures at the end of it (and given the images have been stolen without permission, one might say the people jumping through hoops receive their just desserts in the form of a large helping of “nothing at all”).

At this point, it’s time to return to the app and see what it’s been up to on the Twitter account we installed it on:

Automated spam posts, complete with yet more pictures used as bait.

As freshly leaked pictures and video of celebrities continue to be dropped online, so too will scammers try to make capital out of image-hungry clickers. Apart from the fact that these images have been taken without permission so you really shouldn’t be hunting for them, anyone going digging on less than reputable sites is pretty much declaring open season on their computers. Do yourself a favour and leave this leak alone. It probably won’t be long before the Malware authors and exploit slingers roll into town.

Christopher Boyd

The post Twitter app spams Fappening bait and Amazon surveys appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Diamond Fox – part 1: introduction and unpacking

Malwarebytes - Fri, 03/17/2017 - 15:00

Diamond Fox (also known as Gorynch) is a stealer written in Visual Basic that has been present on the black market for several years. Some time ago, builders of its older versions (i.e. were cracked and leaked online – thanks to this we could have a closer view at the full package that is being sold by the authors to other criminals.

In 2016 the malware was almost completely rewritten – its recent version, called “Crystal” was described some months ago by Dr. Peter Stephenson from SC Media (read more).

In this short series of posts, we will take a deep dive in a sample of Diamond Fox delivered by the Nebula Exploit Kit (described here). We will also make a brief comparison with the old, leaked version, in order to show the evolution of this product.

In this first part, we will take a look at Diamond Fox’s behavior in the system, but the main focus will be about unpacking the sample and turning it into a form that can be decompiled by a Visual Basic Decompiler.

Analyzed samples Behavioral analysis

After being deployed, Diamond Fox runs silently, however, we can notice some symptoms of its presence in the system. First of all, the UAC (User Account Control) gets disabled and we can see an alert about it:

Another pop-up is asking the user to restart the system so that this change will take effect:

The initial executable is deleted and the malware re-runs itself from the copy installed in the %TEMP% folder. It drops two copies of itself – dwn.exe and spoolsv.exe. Viewing the process activity under Process Explorer, we can observe the spawned processes:

It also deploys wscript.exe.

For persistence, Diamond Fox creates a new folder with a special name (read more about this feature): %TEMP%\lpt8.{20D04FE0-3AEA-1069-A2D8-08002B30309D}.

Thanks to this trick, the user cannot access the files dropped inside. Another copy (backup) is dropped in the Startup folder.

While running, the malware creates some files with .c extensions in %APPDATA% folder:

Also, new files are created in the folder from which the sample was run:

The file keys.c contains an HTML formatted log about the captured user activities, i.e. keystrokes. Here’s an example of the report content (displayed as HTML):

The files log.c and Off.c are unreadable.

Examining the content of the %TEMP% folder we can also find that the malware dropped downloaded payload inside:

It is a XOR encrypted PE file (key in the analyzed case is: 0x2), that turns out to be an update of the main Diamond Fox bot.

Network communication

Diamond Fox communicates with the CnC using an HTTP-based protocol. It beacons to gate.php

Data from the bot is sent to the CnC in form of a POST request. Pattern:

13e=<encoded content>

Responses from the CnC have the following pattern:

<number of bytes in content> <content> <error code>

We can observe the bot downloading in chunks some encrypted content (probably the payload/bot update):

It also periodically uploads the stolen data. In the example below: sending the report about the logged user activities (content of the previously mentioned file keys.c):


Diamond Fox is distributed packed by various crypters, that require different approaches for unpacking. They are not specifically linked with this particular family of malware, that’s why this part is not going to be described here. However, if you are interested in seeing the complete process of unpacking the analyzed sample you can follow the video:

After defeating the first layer of protection, we can see a new PE file. It is wrapped in another protective stub – this time typical for this version of Diamond Fox. The executable has three unnamed sections followed by a section named L!NK. The entry point of the program is atypical – set at the point 0.

It makes loading the application under common debuggers a bit problematic. However, under a disassembler (i.e. PE-bear) we can see, where this Entry Point really leads to:

The header of the application is interpreted as code and executed. Following the jump leads to the real Entry Point, that is in the second section of the executable:

I changed the the executable Entry Point and set it to the jump target (RVA 0xEDB0).

Saved application could be loaded in typical debuggers (i.e. OllyDbg) without any issues, to follow next part of unpacking.

The steps to perform at this level are just like in the case of manual unpacking of UPX. The execution of the packer stub starts by pushing all registers on the stack (instruction PUSHAD). We need to find the point of execution where the registers are restored, because it is usually done when the unpacking of the core finished. For the purpose of finding it, after the PUSHAD instruction is executed, we follow the address of the stack (pointed by ESP). We set a hardware breakpoint on the access to the first DWORD.

We resume the execution. The application will stop on the hardware breakpoint just after the POPAD was executed restoring the previous state of the registers.

This block of code ends with a jump to the unpacked content. We need to follow it in order to see the real core of the application and be able to dump it. Following the jump leads to the Entry Point typical for Visual Basic applications. It is a good symptom because we know that the core of Diamond Fox is a Visual Basic application.

Now we can copy the address of the real Entry Point (in the analyzed case it is 0x4012D4) and dump the unpacked executable for further analysis.

I will use Scylla Dumper. Not closing OllyDbg, I attached Scylla to the running process of Diamond Fox (named s_1.exe in my case).

I set as the OEP (Original Entry Point) the found one, then I clicked IAT Autosearch and Get Imports:

Scylla found several imports in the unpacked executable:

We can view the eventual invalid and suspected imports and remove them – however, in this case, it is not required. We can just dump the executable by pressing button Dump.

Then, it is very important to recover the found import table by clicking Fix Dump and pointing to the dumped file. As a result, we should get an executable named by Scylla in the following pattern: <original name>_dump_SCY.exe.

Now, we got the unpacked file that we can load under the debugger again. But, most importantly, we can decompile it by a Visual Basic Decompiler to see all the insights of the code.

Example of the decompiled code – part responsible for communication with the CnC (click to enlarge):


Unpacking Diamond Fox is not difficult, provided we know a few tricks that are typical for this malware family. Fortunately, the resulting code is no further obfuscated. The authors left some open strings that make functionality of particular blocks of code easy to guess. In the next post, we will have a walk through the decompiled code and see the features provided by the latest version of Diamond Fox.

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog:

The post Diamond Fox – part 1: introduction and unpacking appeared first on Malwarebytes Labs.

Categories: Techie Feeds

A week in security (Mar 6th – Mar 12th)

Malwarebytes - Tue, 03/14/2017 - 19:58

Last week, we had a bumper crop of blog posts for you to get your teeth into, including our Cybercrime Tactics and Techniques report, an issue with a popular mobile app called “Facebook Lite”, and we poked around a fake online scanner. We also took a rummage around the large collection of Mac security myths, warned you away from a 419 scam, walked you through the joys of TORifying a VM, and gave you an Exploit Kits review. Finally, we took a look at CryptoBlock Ransomware, and did much the same for Spora.


Stay safe!

The Malwarebytes Labs Team

The post A week in security (Mar 6th – Mar 12th) appeared first on Malwarebytes Labs.

Categories: Techie Feeds

How not to phish a security researcher on Twitter

Malwarebytes - Tue, 03/14/2017 - 15:00

You’ve compromised a few accounts. You’ve worked up a list of people most likely to click your links or send you personal data. You’ve figured out your fake Twitter verification scam and the bogus accounts are ready to roll. You’re feeling good about your general angle of approach, but – watch out! – because things are about to go horribly wrong.

For my part, I don’t go to the zoo and put my head in a crocodile’s mouth. I try to avoid sunbathing on NASCAR tracks. I wouldn’t download a car.

With that in mind, then, I can’t quite fathom the rationale behind picking your an Infosec researcher as the target of a “Get verified on Twitter” scam, especially given that I’m already verified:

“We just verified your account message us”

Yes, of course you did.

It’s highly likely they didn’t bother to check my profile bio or they’d have made their excuses and left. That’s what I keep telling myself, anyway. There’s no accounting for that rare breed of YOLO scammer.

I gave them a follow to see what they’d send by DM, because that’s usually how they do things. Not long after:

“Hello we need you to confirm some info to keep your verified account can you do this”

Things have now changed a little – they’re no longer telling me I can get verified, or that they have verified me; it’s now all about keeping said status.

I was all geared up to send some DMs their way in response but a technical hitch left me unable to do so. At this point, a game of “Please send me a message somehow” commenced in the hope that they might take the bait and show me what their scam consisted of:

If the recipient had been a bot, then it’s possible nothing would be forthcoming because they’re not always created with the ability to reply. If there was a person at the other end, then I might get a DM to my inbox. If they were feeling particularly adventurous, they might fire over a message publicly. Would they send a security researcher who spends their time writing about scams and has “Malware Analyst @malwarebytes” on their bio a phish attempt? A phish attempt that would not only be hugely unproductive for them, but also likely end up as a bout of mockery, account cancellation, and a blog post?

To coin a phrase, “whoops”.

“We need you to confrim [sic] your name age twitter password and email address and phone number”

As it turns out, spelling “Twitter” like “TVVITTER” is not a key indicator of success. In the end, they couldn’t even muster a semi-decent phishing page, or a phishing page at all for that matter. Just a barebones attempt at being the Wallet Inspector and simply asking me to send them my credentials. In fact, the Wallet Inspector had been busy:

Lots of attempts at luring people into DM conversations, and making a beeline for their logins.

Immediately after being called out, the scammers went into panic mode and started deleting incriminating tweets which let me throw in a Watchmen reference, so that was nice.

“Do you seriously think I would explain if there were even the slightest possibility you could affect the outcome? I did it 35 minutes ago.”

— Chris Boyd (@paperghost) March 12, 2017

Top tip: always screenshot everything before making a move. It’s one weird trick that scammers hate.

I’m not sure what use blocking me was at this point, because the damage (for them) was already done. At least it made them feel a bit better, I guess?

Time to play out their last, desperate, phishy moments…

yo @verified @Support you have phishing going on at @HQ_TVVITTER

— Chris Boyd (@paperghost) March 12, 2017

@paperghost @verified @Support @HQ_TVVITTER SUSPENDED! That was fast cc @martijn_grooten

— DEY! (@DEYCrypt) March 12, 2017

Now that’s a fast takedown (roughly a minute or so?) by Twitter.

And so my brief encounter with an overly ambitious Twitter phisher comes to an end. I’d like to say parting is such sweet sorrow, but Banhammers are great so I guess I’m not that bothered. Remember: no random Twitter feed can grant you verified status and especially not one making creative use of the English language to spell “Twitter”. If someone asks you for login credentials either publicly or by DM, report them to the appropriate channels and go about your business.

Unless it’s inspecting wallets, in which case you’ll probably be appearing on the blog in the near future…


Christopher Boyd

The post How not to phish a security researcher on Twitter appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Adware vs. Ad-fraud

Malwarebytes - Mon, 03/13/2017 - 18:18

Adware and ad-fraud are in the same business and both don’t care very much how they make money, as long as it keeps pouring in. But there are some major differences. To understand these differences it’s imperative to have a look at the separate entities.


Adware: any software application that shows advertisements while one of the components of the adware is running. The word is a contraction of advertising and software and often just regarded as “advertising-supported free-ware”.

This is the well-known trade-off of not having to pay for your software and having to look at some advertisements in return. While this simple business model may appeal to many of us, there are definitely boundaries. We draw lines at the amount of advertisements, the moment and the way they are presented to us (consider i.e. in-game advertising), and the kind of advertisements (i.e. pop-ups of an adult nature may give those looking over your shoulder the wrong idea).

There are also some criteria that security vendors take into consideration when classifying adware:

  • Do the advertisements disappear when you uninstall the software they came with?
  • Was the user given a warning and a chance to opt-out during install?
  • What is the nature of the changes the adware makes on the affected system?
  • How easy is it to remove under normal circumstances?
  • What is the impact on the user’s privacy?
  • Does the adware grab permissions to update itself or install other similar programs?

This is why you will see (most) adware classified as potentially unwanted programs (PUPs), some as spy-ware, and others could even be classified as Trojans.


Ad-fraud: a type of fraud that lets advertisers pay for advertisements even though the number of impressions (the times that the advertisement has been seen) is enormously exaggerated. There are many different methods to achieve this:

  • SEO fraud – sites are artificially made to appear to be very popular, so advertisers will pay high prices for advertisements nobody may ever see.
  • Stacking or stuffing – sites are filled with lots of advertisements. Sometimes on top of each other, or sometimes only one pixel big. When someone visits the site, all the advertisements register one impression.
  • Domain spoofing – the site where the advertisement is placed is another one as the advertiser expected. He pays a high price for a site with low or no traffic.
  • Click-fraud – systems that are part of a botnet or have some other Trojan infection, are sent to visit a site (or click on a URL). Despite the amount of impressions, the return value of the click is very low. The chance that the potential customer is mad at you, is bigger than the chance he’ll buy something.

The malware involved in this type of fraud is usually classified as a Trojan as the systems are remotely controlled and told to visit a site (to heighten the popularity) or click a URL (to register an impression). As you can imagine hiring a botnet to do these tasks for you is a lot cheaper than owning and running large server-farms, although this happens as well. Or they sometimes pay people in low-income countries to do micro-tasks for micro payment.


So, we have seen that both adware and ad-fraud earn their money in the advertising business. But the means are very different. While the main victims of adware are the users that may have knowingly installed advertising supported software, in the case of ad-fraud the main victims are the advertisers. Even though there might be unsuspecting users running click-bots or multi-purpose bots.


Pieter Arntz

The post Adware vs. Ad-fraud appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Explained: Spora ransomware

Malwarebytes - Fri, 03/10/2017 - 18:00

Nowadays, ransomware has become the most popular type of malware. Most of the new families are prepared by amateurs (script-kiddies) and they are distributed on a small scale. There are only a few major players on this market that are prepared by professionals. Recently, Spora ransomware joined this set. As we will see, some of the elements suggest that there is a well-prepared team of criminals behind it.

Spora got some hype of being a ransomware that can encrypt files offline. In fact, this concept is nothing novel – we already saw many ransomware families that can do the same. For example DMA Locker 3.0, Cerber, or some newer editions of Locky. However, it has some other features that make it interesting.

Analyzed samples Distribution method

Spora is distributed by various ways – from phishing e-mails (described here) to infected websites dropping malicious payloads.

Some examples of the distribution method used by this ransomware are described here (the campaign from 14.02.2017) and here (the campaign from 06.03.2017).

Behavioral analysis

After being deployed, Spora ransomware runs silently and encrypts files with selected extensions. Then, it attempts to redeploy itself with elevated privileges. No UAC bypass mechanism has been used – instead, the UAC popup appears repeatedly till the user accepts it:

Then, it deploys another system tool – vssadmin, for deleting shadow copies:

It doesn’t even try to be silent – command line window is displayed.

It also drops its own copy into C: directory. Several modifications are being made in existing folder’s settings. First of all, Spora disables displaying an arrow icon to indicate shortcuts. It makes all the existing folders as hidden and creates shortcuts to each of them. The shortcut not only deploys the original folder but also the dropped malware sample.

Example of a command, deployed when the user clicks on the shortcut:

C:\Windows\C:\Windows\system32\cmd.exe /c start explorer.exe "Program Files" & type "81d59edde88fc4969d.exe" > "%temp%\81d59edde88fc4969d.exe" && "%temp%\81d59edde88fc4969d.exe"

Spora doesn’t change filenames, nor adds extensions. Each file is encrypted with a separate key (files with the same plaintext are encrypted to different ciphertexts). Encrypted content has high entropy, no patterns are visible, that suggest a stream cipher or chained blocks (probably AES in CBC mode).

Visualization of a file – before and after encryption:


The malware drops related files in several locations. The following files can be found in %APPDATA%.

The file with the .KEY extension and a ransom note in HTML format are also dropped on the Desktop:

The .KEY file contains encrypted data about the victim that needs to be uploaded later to the attacker’s website for the purpose of synchronizing the status of the victim.

When the encryption finishes, a ransom note pops up. In the first analyzed cases it was in a Russian language. However, other language versions also exists, for example – English note given below:

The content of the .KEY file is Base64 encoded and stored as a hidden field inside the ransom note:

In newer versions (#2) the .KEY file was not dropped at all, and the full synchronization with the remote server was based on its equivalent submitted automatically as the hidden field. It shows the second step in evolution of this ransomware – to make the interface even simpler and more accessible.

Website for the victim

Ransomware itself is not looking sophisticated, except for its website for the victim and the internals of the .KEY file (or it’s base64 equivalent). In older versions, a user was asked to upload the .KEY file to the website and all of his/her private information are retrieved, i.e. username, infection date, status, etc.

In newer versions, there is no necessity to upload anything – when the user clicks the link on the ransom note, the base64 content containing all the data is submitted automatically.

Some information is also encoded inside the victim ID: country code (first two characters), hash, statistics about encrypted files types (how many particular types of files has been encrypted of each category: office document, PDF, Corel Draw, DB, Image, Archive). You can find a decoder here.

Another step taken by authors to provide a user-friendly interface is the fact that the site (although hosted as a hidden service) does not require users to download a Tor browser, like most of the ransomware, but instead, provides a convenient gateway at


Spora executable comes packed in various crypters. It has been also observed distributed in bundles with other malware. In case #1, after defeating the first encryption layer, we can find two UPX-packed payloads. They can be unpacked by the standard UPX application. As a result, we are getting samples that are not further obfuscated. In the mentioned case, Spora ransomware was distributed along with a malicious downloader (38e645e88c85b64e5c73bee15066ec19) similar to the one described here. (Since this article is dedicated to Spora ransomware only, the second payload will not be further described).

Execution flow

Spora’s execution path varies depending on the parameter with which it has been deployed. On its initial run it is executed without any parameter. Then, the basic steps are the following:

1. Create mutex (pattern: m<VolumeSerialNumber:decimal>)

2. Decrypt AES protected data stored in the binary (i.e. RSA public key, ransom note, sample ID)

3. Search files with the attacked extensions. Make a list of their paths and statistics of the types.

4. Generate RSA key pair (one per victim)

5. Encrypt files with the selected extensions

After completing these operations, Spora redeploys it’s own binary – this time with Administrative privileges (causing UAC alert to pop-up). It passes in the command-line a parameter ‘\u’ that modifies the execution path.

Some of the steps that are executed in such case are:

1. Delete shadow copies

2. Modify lnkfile settings (in order to hide an arrow added by default to indicate shortcut – more about it’s purpose described in the section “Behavioral analysis”)

3. Drop it’s own copy and the ransom not on every drive

4. Deploy explorer displaying the ransom note

What is attacked?

Spora ransomware attacks the following extensions:

xls doc xlsx docx rtf odt pdf psd dwg cdr cd mdb 1cd dbf sqlite accdb jpg jpeg tiff zip rar 7z backup sql bak

They are grouped in several categories, used to build statistics for the attackers. The categories can be described as such: office documents, PDF/PPT documents, Corel Draw documents, database files, images, and archives:

Several system directories are excluded from the attack:

windows program files program files (x86) games How does the encryption works?

Encryption used by Spora ransomware is complex, follows several levels. It uses Windows Crypto API. The executable comes with two hardcoded keys: AES key – used to decrypt elements hardcoded in the binary, and an RSA public key – used to encrypt keys generated on the victim’s machine.

In addition to operations related to encrypting victim’s files, Spora uses Windows Crypto API for other purposes – i.e. to encrypt temporary data, and to decrypt some elements stored in the binary.

First, it creates a file in %APPDATA% – the filename is  the Volume Serial Number. This file is used for temporary storing information.

The temporarily stored information is encrypted with the help of the function CryptProtectData:

It includes, i.e. list of the fies to be encrypted (with extensions matching the list):

The malware sample comes with a hardcoded key that is being imported:

It is an AES 256 key, stored in a form of blob.  Explanation on the fields in the Blob Header:

08 - PLAINTEXTKEYBLOB - key is a session key 02 - CUR_BLOB_VERSION 0x00006610 - AlgID: CALG_AES_256 0x20 - 32 - key length

The AES key is used for decrypting another key, stored in a binary – that is an RSA public key:

-----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6COfj49E0yjEopSpP5kbeCRQp WdpWvx5XJj5zThtBa7svs/RvX4ZPGyOG0DtbGNbLswOYKuRcRnWfW5897B8xWgD2 AMQd4KGIeTHjsbkcSt1DUye/Qsu0jn4ZB7yKTEzKWeSyon5XmYwoFsh34ueErnNL LZQcL88hoRHo0TVqAwIDAQAB -----END PUBLIC KEY-----

After that, the same AES key is imported again and used to decrypt other elements:

  • The ransom note in HTML format:

  • A hardcoded ID of the sample:


For every victim, Spora creates locally a fresh pair of RSA keys. Below you can see the fragment of code generating new RSA key pair (1024 bit):

Explanation of the parameters:

0xA400 - AlgId: CALG_RSA_KEYX 0x04000001 - RSA1024BIT_KEY | CRYPT_EXPORTABLE

The private key from the generated pair is exported and Base64 encoded:

The formated version of the private key is stored in a buffer – along with the collected data about the machine and the infection, including: date, username, country code, malware sample id, and statistics of encrypted file types.


Then, another AES key is being generated. It is exported and encrypted by the public RSA key, that was hardcoded in the sample. Below – encrypting the exported AES key blob:

The generated AES key is used to encrypt the victim’s data (including the private key from the generated pair):

The prepared encrypted content is merged into one data block. First, the AES encrypted victim’s data is copied. After that follows the RSA encrypted AES key (selected on the below picture):

This merged data is stored in the .KEY file (or in the hidden, base64 encoded content in the ransom note). It needs to be uploaded to the server by the victim – that’s how the attackers get access to the data necessary to decrypt files after the ransom is paid.

Spora does not change files’ extensions, so it needs some other method of identifying whether or not the individual file is encrypted. It is done by reading some fragments of the content.

As we can see above, the 132 bytes at the end of the file are reserved for the data stored by Spora: 128 byte long AES key followed by its 4 byte long Crc32. In order to decide if the file is encrypted or not, data at the file’s end is read and the saved Crc32 is compared with the computed Crc32 of the read 128 bytes. If the check passed, Spora finishes processing the file. Otherwise, it follows with the encryption:

For each file, a new, individual AES key is generated. It is used to encrypt mapped file content. The exported representation of the individual key is encrypted by the previously generated RSA key and then stored at the end of the encrypted file. After that, it’s Crc32 is being computed and also stored at the end.


Spora is an interesting ransomware, for sure created by authors with programming experience. However, the code is not obfuscated and the execution is very noisy in comparison to other malware – it may suggest that the authors are not professional malware designers (in contrary to i.e. authors of Cerber).

The used cryptography implementation seems to have no flaws that would allow for decrypting attacked files without paying the ransom, so, we recommend focusing on prevention. Users with Malwarebytes 3.0 installed will be protected from Spora ransomware. While there currently is no decryption for those infected we suggest keeping a backup of the infected files as there might be a decrypter in the future.

Appendix – Spora ID decoder – Bleeping Computer about Spora

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog:

The post Explained: Spora ransomware appeared first on Malwarebytes Labs.

Categories: Techie Feeds

CryptoBlock ransomware and its C2

Malwarebytes - Fri, 03/10/2017 - 16:00

CryptoBlock is an interesting ransomware to keep an eye on. We expect this to be a ransomware that is in development to eventually develop into a RaaS (Ransomware as a Service).

Since the ransomware seems to be in development, we decided there might be some weak points and investigate if we could find one. Even though it is in development to be a RaaS, as it seems users have already been infected by this variant somehow.

After getting the name CryptoBlock, we decided to check at VirusTotal and see how many droppers for it we could find there, as well as to get some information on the ransomware. Finding a single dropper on VirusTotal, I noticed it was contacting the domain to send a key to and also to get a BTC wallet.

By going to this domain directly, we can see that the threat actor has left a note for interested, criminal consumers that the RaaS should be up and running soon.

Even with the RaaS not up and running yet, it’s obvious that the ransomware itself was already fully working for the threat actor, and they either had made a few early victims or they ran it on some test computers.

At this point, we decided to run a static analysis on the EXE. Seeing that .NET dll’s were called in the VirusTotal report, we knew it was written in C# or VB. So we opened the EXE in DNSpy, only to find that it was completely obfuscated with ConfuserEX, which is very hard to unravel, especially when it comes to the later versions.

Given the fact that we had a server to work with from previous research, I decided to start on that side, before going through a painstaking de-obfuscation process.

In the server we found some weird entries, pointing to what seemed to be a “Learn PHP game”.

After a search for a lot of these filenames and it didn’t take long before we came across a Pastebin example of one of these php pages. It was quite crude, but it was exactly what we were hoping to find.

Using this newfound information, we were able to look at a copy of the config.php file on the server.

Uh oh! What’s that? Those are the complete master credentials (username and password) to the entire CryptoBlock server, valid for every email, database, SSH, cPanel, and more. Having this information, we went to the site’s cPanel interface and got the login page as such:


Typing in the shiny new credentials gave us all we ever wanted for Christmas…complete access to a threat actor’s overseas server.

We have made copies of all databases, the PHP files, and the personal information used to rent the server.

Looking through the personal information, it became sadly obvious the hosting company didn’t require much more information than an email address to host this server. This email address turned out to be a fake one.

Let’s look at some of the stats for the server that were recovered from the apache logs and presented through statistics graphs.

Click to view slideshow.

One notable thing we can learn from these statistics, there is a possibility that this ransomware has been able to affect quite a few people. But even more interesting to us, it shows that there are a few IP addresses from Europe that have been visiting this server by the thousands since it was brought up. There is a huge chance that these IPs are the real IPs of the threat actor owning this server and were logged while they were performing their tests. This is further supported by the fact that the most used part of the site, is a PHP page that is used by the debug build of the ransomware server: checkaction.php.

Weirdly, the threat actor seems to have a database full of stolen credentials from “Pay for Porn” sites besides the database the ransomware uses.

Here is an example of the first page of the database tables used by the ransomware for IDs, BTC addresses, payments, and keys.

Another interesting fact we found is that the threat actor applied for a Blockchain API account, and was denied.

The threat actor is also distributing an exploitable Ammyy Admin executable from the server. It seems they either may be scamming people into letting them onto the machine remotely, or they are simply running it silently as a malicious drive-by. The file on the server is called test.exe.

We will keep an eye on the developments that this ransomware and the server will go through and try to keep you posted on any significant changes.

As far as protection from this threat though, if you are using Malwarebytes 3.0 with Anti-Ransomware technology, you are going to be protected from this ransomware at numerous levels, so please make sure you utilize it or a similar solution.

The post CryptoBlock ransomware and its C2 appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Exploit kits: Winter 2017 review

Malwarebytes - Thu, 03/09/2017 - 20:08

A few months have passed since our Fall 2016 review of the most common exploit kits we are seeing in our telemetry and honeypots. Today, we take another look at the current (bleak) EK scene by going over RIG, Sundown, Neutrino and Magnitude.

There haven’t been any major changes in the past little while and exploit kit-related infections remain low compared to those via malicious spam. This is in part due to the lack of fresh and reliable exploits in today’s drive-by landscape.

Pseudo-Darkleech and EITest are the most popular redirection campaigns from compromised websites. They refer to code that is injected into – for the most part – WordPress, Joomla, or Drupal websites and automatically redirects visitors to an exploit kit landing page.

Malvertising campaigns keep fuelling redirections to exploit kits as well, but can greatly vary in size and impact. The daily malverts from shady ad networks continue unchanged while the larger attacks going after top ad networks and publishers come in waves.

In the following video, we do a quick overview of those exploit kits; if you are interested in the more technical details please scroll down for additional information on each of them.

Most used vulnerabilities

Internet Explorer

  • CVE-2016-0189
  • CVE-2014-6332
  • CVE-2013-2551

Information disclosure

  • CVE-2016-3351
  • CVE-2016-3298
  • CVE-2016-0162


  • CVE-2016-7200
  • CVE-2016-7201


  • CVE-2016-4117
  • CVE-2016-1019
  • CVE-2015-8651
  • CVE-2015-7645


  • CVE-2016-0034

RIG EK remains the most popular exploit kit at the moment used both in malvertising and compromised websites campaigns. Its primary payloads are ransomware (Cerber and CryptoShield).

The landing page structure (URL and source code) hasn’t really changed, but it is now using a pre-landing page to filter bots and other non-legitimate traffic.

Payload here: Dreambot

Gate (browser check)

Landing page

Sundown EK

Sundown EK keeps on changing its URL patterns, mainly for the Flash exploit and its payload URLs. Sundown is a lot more quiet than RIG EK and for the most part contained to some malvertising campaigns.

Payload here: VenusLocker

Landing page

Neutrino EK

Neutrino EK seems to be the weapon of choice for special malvertising attacks that are difficult to reproduce. It features its usual pre-filtering gate that includes several checks against VMs and security software.

Payload here: Neutrino bot

Filtering gate (fingerprinting)

Landing page

Magnitude EK

Magnitude EK is a very geo-aware exploit kit being restricted to Asia at the moment. It uses decoy finance or bitcoin websites with a special referer to lead to its gate.

Payload here: Cerber

IE exploit

Landing page

Wrap up

There are more exploit kits than just those mentioned in this blog, but some were not included because they were simply copycats or because we have only seen them very sporadically.

Some EKs are indeed quite difficult to reproduce without a proper setup and some previous knowledge of the various traps affiliates and traffers are putting in the way. In other cases, they may fall off the radar until a new campaign (i.e. malvertising) is put in place.

While there hasn’t been a big focus on getting newer exploits integrated, we can note that exploit kit authors are investing some time into better bot detection and evasion, essentially trying to optimize the leads they are getting.

However, we should still be aware that this situation could change as new and powerful exploits can be discovered at any time and come with a ready-to-use proof of concept. For instance, CVE-2017-0037, a vulnerability that affects IE and Edge, is something attackers are likely to integrate soon.

The post Exploit kits: Winter 2017 review appeared first on Malwarebytes Labs.

Categories: Techie Feeds


Subscribe to Furiously Eclectic People aggregator - Techie Feeds