Malware RSS Feed

The King is dead. Long live the King!

Malware Alerts - Wed, 05/09/2018 - 02:00

In late April 2018, a new zero-day vulnerability for Internet Explorer (IE) was found using our sandbox; more than two years since the last in the wild example (CVE-2016-0189). This particular vulnerability and subsequent exploit are interesting for many reasons. The following article will examine the core reasons behind the latest vulnerability, CVE-2018-8174.

Searching for the zero day

Our story begins on VirusTotal (VT), where someone uploaded an interesting exploit on April 18, 2018. This exploit was detected by several AV vendors including Kaspersky, specifically by our generic heuristic logic for some older Microsoft Word exploits.

Virustotal scan results for CVE-2018-8174

After the malicious sample was processed in our sandbox system, we noticed that a fully patched version of Microsoft Word was successfully exploited. From this point we began a deeper analysis of the exploit. Let’s take a look at the full infection chain:

Infection chain

The infection chain consists of the following steps:

  • A victim receives a malicious Microsoft Word document.
  • After opening the malicious document, a second stage of the exploit is downloaded; an HTML page containing VBScript code.
  • The VBScript code triggers a Use After Free (UAF) vulnerability and executes shellcode.
Initial analysis

We’ll start our analysis with the initial Rich Text Format (RTF) document, that was used to deliver the actual exploit for IE. It only contains one object, and its contents are obfuscated using a known obfuscation technique we call “nibble drop“.

Obfuscated object data in RTF document

After deobfuscation and hex-decoding of the object data, we can see that this is an OLE object that contains a URL Moniker CLSID. Because of this, the exploit initially resembles an older vulnerability leveraging the Microsoft HTA handler (CVE-2017-0199).

URL Moniker is used to load an IE exploit

With the CVE-2017-0199 vulnerability, Word tries to execute the file with the default file handler based on its attributes; the Content-Type HTTP header in the server’s response being one of them. Because the default handler for the “application/hta” Content-Type is mshta.exe,it is chosen as the OLE server to run the script unrestricted. This allows an attacker to directly call ShellExecute and launch a payload of their choice.

However, if we follow the embedded URL in the latest exploit, we can see that the content type in the server’s response is not “application/hta”, which was a requirement for CVE-2017-0199 exploitation, but rather “text/html”. The default OLE server for “text/html” is mshtml.dll, which is a library that contains the engine, behind Internet Explorer.

WINWORD.exe querying registry for correct OLE server

Furthermore, the page contains VBScript, which is loaded with a safemode flag set to its default value, ‘0xE’. Because this disallows an attacker from directly executing a payload, as was the case with the HTA handler, an Internet Explorer exploit is needed to overcome that.

Using a URL moniker like that to load a remote web page is possible, because Microsoft’s patch for Moniker-related vulnerabilities (CVE-2017-0199, CVE-2017-8570 and CVE-2017-8759) introduced an activation filter, which allows applications to specify which COM objects are restricted from instantiating at runtime.

Some of the filtered COM objects, restricted from creating by IActivationFilter in MSO.dll

At the time of this analysis, the list of filtered CLSIDs consisted of 16 entries. TheMSHTML CLSID ({{25336920-03F9-11CF-8FD0-00AA00686F13}}) is not in the list, which is why the MSHTML COM server is successfully created in Word context.

This is where it becomes interesting. Despite a Word document being the initial attack vector, thevulnerability is actually in VBScript, not in Microsoft Word. This is the first time we’ve seen a URL Moniker used to load an IE exploit, and we believe this technique will be used heavily by malware authors in the future. This technique allows one to load and render a web page using the IE engine, even if default browser on a victim’s machine is set to something different.

The VBScript in the downloaded HTML page contains both function names and integer values that are obfuscated.

Obfuscated IE exploit

Vulnerability root cause analysis

For the root cause analysis we only need to look at the first function (‘TriggerVuln’) in the deobfuscated version which is called right after ‘RandomizeValues’ and ‘CookieCheck’.

Vulnerability Trigger procedure after deobfuscation

To achieve the desired heap layout and to guarantee that the freed class object memory will be reused with the ‘ClassToReuse’ object, the exploit allocates some class objects. To trigger the vulnerability this code could be minimized to the following proof-of-concept (PoC):

CVE-2018-8174 Proof Of Concept

When we then launch this PoC in Internet Explorer with page heap enabled we can observe a crash at the OLEAUT32!VariantClear function.

Access Violation on a call to freed memory

Freed memory pointer is reused when the second array (ArrB) is destroyed

With this PoC we were able to trigger a Use-after-free vulnerability; both ArrA(1) and ArrB(1) were referencing the same ‘ClassVuln’ object in memory. This is possible because when “Erase ArrA” is called, the vbscript!VbsErase function determines that the type of the object to delete is a SafeArray, and then calls OLEAUT32!SafeArrayDestroy.

It checks that the pointer to a tagSafeArray structure is not NULL and that its reference count, stored in the cLocks field is zero, and then continues to call ReleaseResources.

VARTYPE of ArrA(1) is VT_DISPATCH, so VBScriptClass::Release is called to destruct the object

ReleaseResources, in turn will check the fFeatures flags variable, and since we have an array of VARIANTs, it will subsequently call VariantClear; a function that iterates each member of an array and performs the necessary deinitialization and calls the relevant class destructor if necessary. In this case, VBScriptClass::Release is called to destroy the object correctly and handle destructors like Class_Terminate, since the VARTYPE of ArrA(1) is VT_DISPATCH.

Root cause of CVE-2018-8174 – ‘refCount’ being checked only once, before TerminateClass function

This ends up being the root cause of the vulnerability. Inside the VBScriptClass::Release function, the reference count is checked only once, at the beginning of the function. Even though it can be (and actually is, in the PoC) incremented in an overloaded TerminateClass function, no checks will be made before finally freeing the class object.

Class_Terminate is a deprecated method, now replaced by the ‘Finalize’ procedure. It is used to free acquired resources during object destruction and is executed as soon as object is set to nothing and there are no more references to that object. In our case, the Class_Terminate method is overloaded, and when a call to VBScriptClass::TerminateClass is made, it is dispatched to the overloaded method instead. Inside of that overloaded method, another reference is created to the ArrA(1) member. At this point ArrB(1) references ArrA(1), which holds a soon to be freed ClassVuln object.

Crash, due to calling an invalid virtual method when freeing second object

After the Class_Terminate sub is finished, the object at Arr(1) is freed, but ArrB(1) still maintains a reference to that freed class object. When the execution continues, and ArrB is erased, the whole cycle repeats, except that this time, ArrB(1) is referencing a freed ClassVuln object, and so we observe a crash when one of the virtual methods in the ClassVuln vtable is called.


In this write up we analyzed the core reasons behind CVE-2018-8174, a particularly interesting Use-After-Free vulnerability that was possible due to incorrect object lifetime handling in the Class_Terminate VBScript method. The exploitation process is different from what we’ve seen in exploits for older vulnerabilities (CVE-2016-0189 and CVE-2014-6332) as the Godmode technique is no longer used. The full exploitation chain is as interesting as the vulnerability itself, but is out of scope of this article.

With CVE-2018-8174 being the first public exploit to use a URL moniker to load an IE exploit in Word, we believe that this technique, unless fixed, will be heavily abused by attackers in the future, as It allows you force IE to load ignoring the default browser settings on a victim’s system.

We expect this vulnerability to become one of the most exploited in the near future, as it won’t be long until exploit kit authors start abusing it in both drive-by (via browser) and spear-phishing (via document) campaigns. To stay protected, we recommend applying latest security updates, and using a security solution with behavior detection capabilities.

In our opinion this is the same exploit which Qihoo360 Core Security Team called “Double Kill” in their recent publication. While this exploit is not limited to browser exploitation, it was reported as an IE zero day, which caused certain confusion in the security community.

After finding this exploit we immediately shared the relevant information with Microsoft and they confirmed that it is in fact CVE-2018-8174.

This exploit was found in the wild and was used by an APT actor. More information about that APT actor and usage of the exploit is available to customers of Kaspersky Intelligence Reporting Service. Contact:


Kaspersky Lab products successfully detect and block all stages of the exploitation chain and payload with the following verdicts:

  • HEUR:Exploit.MSOffice.Generic – RTF document
  • PDM:Exploit.Win32.Generic – IE exploit – detection with Automatic Exploit Prevention technology
  • HEUR:Exploit.Script.Generic – IE exploit
  • HEUR:Trojan.Win32.Generic – Payload
  • b48ddad351dd16e4b24f3909c53c8901 – RTF document
  • 15eafc24416cbf4cfe323e9c271e71e7 – Internet Explorer exploit (CVE-2018-8174)
  • 1ce4a38b6ea440a6734f7c049f5c47e2 – Payload
  • autosoundcheckers[.]com

SynAck targeted ransomware uses the Doppelgänging technique

Malware Alerts - Mon, 05/07/2018 - 06:00

The Process Doppelgänging technique was first presented in December 2017 at the BlackHat conference. Since the presentation several threat actors have started using this sophisticated technique in an attempt to bypass modern security solutions.

In April 2018, we spotted the first ransomware employing this bypass technique – SynAck ransomware. It should be noted that SynAck is not new – it has been known since at least September 2017 – but a recently discovered sample caught our attention after it was found to be using Process Doppelgänging. Here we present the results of our investigation of this new SynAck variant.

Anti-analysis and anti-detection techniques Process Doppelgänging

SynAck ransomware uses this technique in an attempt to bypass modern security solutions. The main purpose of the technique is to use NTFS transactions to launch a malicious process from the transacted file so that the malicious process looks like a legitimate one.

Part of the procedure that implements Process Doppelgänging

Binary obfuscation

To complicate the malware analysts’ task, malware developers often use custom PE packers to protect the original code of the Trojan executable. Most packers of this type, however, are effortlessly unpacked to reveal the original unchanged Trojan PE file that’s suitable for analysis.

This, however, is not the case with SynAck. The Trojan executable is not packed; instead, it is thoroughly obfuscated prior to compilation. As a result, the task of reverse engineering is considerably more complicated with SynAck than it is with other recent ransomware strains.

The control flow of the Trojan executable is convoluted. Most of the CALLs are indirect, and the destination address is calculated by arithmetic operation from two DWORD constants.

All of the WinAPI function addresses are imported dynamically by parsing the exports of system DLLs and calculating a CRC32-based hash of the function name. This in itself is neither new nor particularly difficult to analyze. However, the developers of SynAck further complicated this approach by obscuring both the address of the procedure that retrieves the API function address, and the target hash value.

Let’s illustrate in detail how SynAck calls WinAPI functions. Consider the following piece of disassembly:

This code takes the DWORD located at 403b13, subtracts the constant 78f5ec4d, with the result 403ad0, and calls the procedure at this address.

This procedure pushes two constants (N1 = ffffffff877bbca1 and N2 = 2f399204) onto the stack and passes the execution to the procedure at 403680 which will calculate the result of N1 xor N2 = a8422ea5.

This value is the hash of the API function name that SynAck wants to call. The procedure 403680 will then find the address of this function by parsing the export tables of system DLLs, calculating the hash of each function name and comparing it to the value a8422ea5. When this API function address is found, SynAck will pass the execution to this address.

Notice that instead of a simple CALL in the image above it uses the instructions PUSH + RET which is another attempt to complicate analysis. The developers of SynAck use different instruction combinations instead of CALL when calling WinAPI functions:

push reg
jmp reg
mov [rsp-var], reg
jmp qword ptr [rsp-var] Deobfuscation

To counter these attempts by the malware developers, we created an IDAPython script that automatically parses the code, extracts the addresses of all intermediate procedures, extracts the constants and calculates the hashes of the WinAPI functions that the malware wants to import.

We then calculated the hash values of the functions exported from Windows system DLLs and matched them against the values required by SynAck. The result was a list showing which hash value corresponds to which API function.

Part of the list of API functions imported by SynAck and their hashes

Our script then uses this list to save comments in the IDA database to indicate which API is going to be called by the Trojan. Here is the code from the example above after deobfuscation.

Disassembly screen – note the comment with the target API function name

Hex-Rays decompilation screen – again, the API function names are recognized

Language check

At an early stage of execution the Trojan performs a check to find out whether it has been launched on a PC from a certain list of countries. To do this, it lists all the keyboard layouts installed on the victim’s PC and checks against a list hardcoded into the malware body. If it finds a match, SynAck sleeps for 300 seconds and then just calls ExitProcess to prevent encryption of files belonging to a victim from these countries.

Part of the procedure that stops the Trojan if the language check is not passed

Part of the procedure that checks the keyboard layouts on the infected PC

Directory name validation

Shortly after the language check, which can be considered fairly common among modern ransomware, SynAck performs a check on the directory where its executable is started from. If there’s an attempt to launch it from an ‘incorrect’ directory, the Trojan won’t proceed and will just exit instead. This measure has been added by the malware developers to counter automatic sandbox analysis.

As with API imports, the Trojan doesn’t store the strings it wants to check; instead it stores their hashes – a tactic that hinders efforts to find the original strings.

SynAck contains nine hashes; we have been able to brute-force two of them:

0x05f9053d == hash("output")
0x2cd2f8e2 == hash("plugins")

In the process we found a lot of collisions (gibberish strings that give the same hash value as the meaningful ones).

Cryptographic scheme

Like other ransomware, SynAck uses a combination of symmetric and asymmetric encryption algorithms. At the core of the SynAck algorithm lies the hybrid ECIES scheme. It is composed of ‘building blocks’ which interact with each other: ENC (symmetric encryption algorithm), KDF (key derivation function), and MAC (message authentication code). The ECIES scheme can be implemented using different building blocks. To calculate a key for the symmetric algorithm ENC, this scheme employs the ECDH protocol (Diffie-Hellman over a chosen elliptic curve).

The developers of this Trojan chose the following implementation:


KDF: PBKDF2-SHA1 with one iteration


ECDH curve: standard NIST elliptic curve secp192r1


This is the function that implements the ECIES scheme in the SynAck sample.

Input: plaintext, input_public_key

Output: ciphertext, ecies_public_key, MAC

  1. The Trojan generates a pair of asymmetric keys: ecies_private_key and ecies_public_key;
  2. Using the generated ecies_private_key and input_public_key the Trojan calculates the shared secret according to the Diffie-Hellman protocol on an elliptic curve:
ecies_shared_secret = ECDH(ecies_private_key, input_public_key)
  1. Using the PBKDF2-SHA1 function with one iteration, the Trojan derives two byte arrays, key_enc and key_mac, from ecies_shared_secret. The size of key_enc is equal to the size of the plaintext;
  2. The plaintext is XORed byte to byte with the key_enc;
  3. The Trojan calculates the MAC (message authentication code) of the obtained ciphertext using the algorithm HMAC-SHA1 with key_mac as the key.

At the first step the Trojan generates a pair of private and public keys: the private key (session_private_key) is a 192-bit random number and the public key (session_public_key) is a point on the standard NIST elliptic curve secp192r1.

Then the Trojan gathers some unique information such as computer and user names, OS version info, unique infection ID, session private key and some random data and encrypts it using a randomly generated 256-bit AES key. The encrypted data is saved as the encrypted_unique_data buffer.

To encrypt the AES key, the Trojan uses the ECIES-XOR-HMAC-SHA1 function (see description above; hereafter referred to as the ECIES function). SynAck passes the AES key as the plaintext parameter and the hardcoded cybercriminal’s master_public_key as input_public_key. The field encrypted_aes_key contains the ciphertext returned by the function, public_key_n is the ECIES public key and message_authentication_code is the MAC.

At the next step the Trojan forms the structure cipher_info.

struct cipher_info
uint8_t encrypted_unique_data[240];
uint8_t public_key_n[49];
uint8_t encrypted_aes_key[44];
uint8_t message_authentication_code[20];

It is shown in the image below.

Encrypted initialization information

This data is then encoded in base64 and written into the ransom note.

Ransom note

As we can see, the criminals ask the victim to include this encoded text in their message.

File encryption

The content of each file is encrypted by the AES-256-ECB algorithm with a randomly generated key. After encryption, the Trojan forms a structure containing information such as the encryption label 0xA4EF5C91, the used AES key, encrypted chunk size and the original file name. This information can be represented as a structure:

struct encryption_info
uint32_t label = 0xA4EF5C91;
uint8_t aes_key[32];
uint32_t encrypted_chunk_size;
uint32_t reserved;
uint8_t original_name_buffer[522];

The Trojan then calls the ECIES function and passes the encryption_info structure as the plaintext and the previously generated session_public_key as the input_public_key. The result returned by this function is saved into a structure which we dubbed file_service_structure. The field encrypted_file_info contains the ciphertext returned by the function, ecc_file_key_public is the ECIES public key and message_authentication_code is the MAC.

struct file_service_structure
uint8_t ecc_file_key_public[49];
encryption_info encrypted_file_info;
uint8_t message_authentication_code[20];

This structure is written to the end of the encrypted file. This results in an encrypted file having the following structure:

struct encrypted_file
uint8_t encrypted_data[file_size - file_size % AES_BLOCK_SIZE];
uint8_t original_trailer[file_size % AES_BLOCK_SIZE];
uint64_t encryption_label = 0x65CE3D204A93A12F;
uint32_t infection_id;
uint32_t service_structure_size;
file_service_structure service_info;

The encrypted file structure is shown in the image below.

Encrypted file structure

After encryption the files will have randomly generated extensions.

Directory after encryption

Other features Termination of processes and services

Prior to file encryption, SynAck enumerates all running processes and all services and checks the hashes of their names against two lists of hardcoded hash values (several hundred combined). If it finds a match, the Trojan will attempt to kill the process (using the TerminateProcess API function) or to stop the service (using ControlService with the parameter SERVICE_CONTROL_STOP).

To find out which processes it wants to terminate and which services to stop, we brute-forced the hashes from the Trojan body. Below are some of the results.

Processes Services Hash Name Hash Name 0x9a130164 dns.exe 0x11216a38 vss 0xf79b0775 lua.exe 0xe3f1f130 mysql 0x6475ad3c mmc.exe 0xc82cea8d qbvss 0xe107acf0 php.exe 0xebcd4079 sesvc 0xf7f811c4 vds.exe 0xf3d0e358 vmvss 0xcf96a066 lync.exe 0x31c3fbb6 wmsvc 0x167f833f nssm.exe 0x716f1a42 w3svc 0x255c7041 ssms.exe 0xa6332453 memtas 0xbdcc75a9 w3wp.exe 0x82953a7a mepocs 0x410de6a4 excel.exe 0x9197b633 httpd.exe 0x83ddb55a ilsvc.exe 0xb27761ed javaw.exe 0xfd8b9308 melsc.exe 0xa105f60b memis.exe 0x10e94bcc memta.exe 0xb8de9e34 mepoc.exe 0xeaa98593 monad.exe 0x67181e9b mqsvc.exe 0xd6863409 msoia.exe 0x5fcab0fe named.exe 0x7d171368 qbw32.exe 0x7216db84 skype.exe 0xd2f6ce06 steam.exe 0x68906b65 store.exe 0x6d6daa28 vksts.exe 0x33cc148e vssvc.exe 0x26731ae9 conime.exe 0x76384ffe fdhost.exe 0x8cc08bd7 mepopc.exe 0x2e883bd5 metray.exe 0xd1b5c8df mysqld.exe 0xd2831c37 python.exe 0xf7dc2e4e srvany.exe 0x8a37ebfa tabtip.exe

As we can see, SynAck seeks to stop programs related to virtual machines, office applications, script interpreters, database applications, backup systems, gaming applications and so on. It might be doing this to grant itself access to valuable files that could have been otherwise used by the running processes.

Clearing the event logs

To impede possible forensic analysis of an infected machine, SynAck clears the event logs stored by the system. To do so, it uses two approaches. For Windows versions prior to Vista, it enumerates the registry key SYSTEM\CurrentControlSet\Services\EventLog and uses OpenEventLog/ClearEventLog API functions. For more modern Windows versions, it uses the functions from EvtOpenChannelEnum/EvtNextChannelPath/EvtClearLog and from Wevtapi.dll.

Ransom note on logon screen

SynAck is also capable of adding a custom text to the Windows logon screen. It does this by modifying the LegalNoticeCaption and LegalNoticeText keys in the registry. As a result, before the user signs in to their account, Windows shows a message from the cybercriminals.

Windows logon screen with ransom text

Attack statistics

We have currently only observed several attacks in the USA, Kuwait, Germany, and Iran. This leads us to believe that this is targeted ransomware.

Detection verdicts




Who’s who in the Zoo

Malware Alerts - Thu, 05/03/2018 - 06:00

ZooPark is a cyberespionage operation that has been focusing on Middle Eastern targets since at least June 2015. The threat actors behind the operation infect Android devices using several generations of malware, with the attackers including new features in each iteration. We label them from v1-v4, with v4 being the most recent version deployed in 2017. From the technical point of view, the evolution of ZooPark has shown notable progress: from the very basic first and second versions, the commercial spyware fork in its third version and then to the complex spyware that is version 4. This last step is especially interesting, showing a big leap from straightforward code functionality to highly sophisticated malware.

Evolution of ZooPark malware features

We have observed two main distribution vectors for ZooPark – Telegram channels and watering holes. The second one was the preferred vector: we found several news websites that have been hacked by the attackers to redirect visitors to a downloading site that serves malicious APKs. Some of the themes observed in campaign include “Kurdistan referendum”, “TelegramGroups” and “Alnaharegypt news”, among others.

Target profile has evolved during the last years of campaign, focusing on victims in Egypt, Jordan, Morocco and Lebanon.

If you would like to learn more about our intelligence reports or request more information on a specific report, contact us at:

 Read the full “Who’s who in the Zoo. Cyberespionage operation targets Android users in the Middle East.” report

Social Media Privacy Settings

SANS Tip of the Day - Tue, 05/01/2018 - 01:00
Privacy settings on social networks have limited value. They are confusing to configure and change often. Ultimately, if you do not want your parents or boss reading it, do not post it.

DDoS attacks in Q1 2018

Malware Alerts - Thu, 04/26/2018 - 06:00

News overview

In early January, it was reported that an amateur hacker had come close to pulling off a botnet attack using “improvised” materials. Armed with information gleaned from hacker forums, the DIYer created a Trojan using a zero-day exploit in Huawei routers and released it online. The attack was soon nipped in the bud, but the wannabe cybercriminal could not be traced.

Other slightly weightier news: first, experts reported growth in the Reaper (or IoTroop) botnet (not to be confused with North Korean hacker group The Reaper), first discovered last quarter; second, IT security resources hinted at the emergence of new “strains” of Mirai and Satori (the latter, known as Okiru, is intended for ARC processors), but so far without details. Moreover, in early February a platform selling JenX botnet services was detected and neutralized. JenX was found to be using a fan server for the video game GTA: San Andreas as its C&C. In terms of power, JenX was nothing to write home about, but the originality of its creators deserves a mention. On the topic of original botnets, another worth noting is DoubleDoor: the first known piece of “wild” malware to bundle two IoT vulnerabilities together.

As for new methods and vulnerabilities, besides the multiget hole in Memcached, last quarter news broke of a vulnerability in WordPress that makes it easy to down a web server. Fortunately, no in-the-wild attacks were observed.

The attack targets for this new weaponry remained largely the same. Profit is still the main motive behind DDoS attacks (the number of attacks on business in Russia alone doubled in 2017), although high-profile “commercial” attacks in the last three months were not so numerous. Within the space of three days in early February, players of Final Fantasy encountered problems signing into certain services. At roughly the same time, BusinessWire experienced similar difficulties lasting more than a week, during which period neither editors nor readers could access the news portal. There was no reported ransom demand, so the motive behind the attack can be assumed to be competition-related.

It would be amiss not to mention a series of attacks that hit GitHub and an unknown service provider in early March, which produced record volumes of garbage traffic — over 1 TB/s. This capacity was achieved by leveraging Memcached, a popular caching service for Linux servers. Interestingly, in some of these attacks the garbage traffic itself contained ransom demands in Monero.

Political motives are less common, but often more visible due to their topicality. The most headlining incident of late was, of course, the threat to sabotage the opening ceremony of the Winter Olympics in early February, most likely through a DDoS offensive. Even before that, in late January, the US Department of Defense repelled an influx of spam, and in late March their Russian counterparts had to survive a DDOS attack. In addition, experts reported that North Korean group The Reaper was extending its reach. Despite not showing any DDoS activity, it could soon start moving in that direction.

Another hard-hitting DDoS attack on major financial institutions in the Netherlands was initially thought to be political, but on closer inspection turned out to be pure hooliganism: Dutch police arrested a teen suspect for causing week-long mayhem at several banks simply to prove that it was possible.

DDoS is also becoming more popular as a means of personal revenge. California, for instance, witnessed the case of David Goodyear, who was found guilty of trying to launch a DDoS attack against an amateur astronomy forum when it blacklisted him for using bad language. True, he can’t be accused of not trying other methods before turning his hand to cybercrime: Goodyear repeatedly registered on the forum under different chat names, but each time earned himself a ban for boorish behavior.

Quarter trends

Due to its capacity and relative accessibility, Memcached was the springboard for last quarter’s most sensational attacks. However, it could prove to be a short-lived trend, and here’s why.

In late February, Kaspersky DDoS Protection support was contacted by a company reporting an unusually high load on its communications channel in what it suspected to be a DDoS attack.

At first glance, the picture did indeed resemble a typical DDoS attack: the channel was clogged up, and users couldn’t access the company’s services. However, our investigation revealed that a CentOS Linux server with a vulnerable Memcached service was installed on one of the client servers. This service, used by the cybercriminals during the attack, generated large amounts of outgoing traffic, overloading the channel. In other words, the client was not the target, but an unwitting accomplice in the DDoS attack: the attackers used its server as an amplifier. After Kaspersky Lab’s recommendations were implemented, the malicious parasitic traffic stopped.

This situation is typical for Memcached attacks: owners of vulnerable servers hijacked during attacks notice the load increase and rush to patch any vulnerabilities not to suffer even more downtime losses. As a result, the number of vulnerable servers that can be utilized for this type of attack is rapidly declining, for which reason Memcached attacks will likely dry up soon.

Still, the picture in Q1 shows that “amplified” attacks, which were on the wane, have again picked up momentum. NTP and DNS-based boosting has practically disappeared, since most vulnerable services have already been patched. Cybercriminals will likely seek out other non-standard amplification methods besides Memcached. Last quarter, for instance, we registered a quite rare (yet effective) type of amplification attack, in which the LDAP service was used as an amplifier. Alongside Memcached, NTP, and DNS, this service has one of the biggest amplification factors. Despite the relatively small number of LDAP servers available, this type of attack could be a hit on the shadow Internet in the coming months.

Statistics for botnet-assisted DDoS attacks Methodology

Kaspersky Lab has extensive experience of combating cyber threats, including DDoS attacks of various complexity types and ranges. Company experts track the actions of botnets by using the DDoS Intelligence system.

As part of the Kaspersky DDoS Protection solution, the DDoS Intelligence system intercepts and analyzes commands sent to bots from C&C servers; it does not require any user devices to be infected or cybercriminals to execute any actual commands.

This report contains DDoS Intelligence statistics for Q1 2018.

In the context of this report, it is assumed that an incident is a separate (single) DDoS-attack if the interval between botnet activity periods does not exceed 24 hours. For example, if one particular web resource was attacked by the same botnet in two waves with an interval of 24 hours or more, the incident is considered as two attacks. Bot requests originating from different botnets but directed at one resource also count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

DDoS Intelligence statistics are limited to botnets detected and analyzed by Kaspersky Lab. Note that botnets are just one of the tools for performing DDoS attacks, and that the data presented in this report do not cover every single DDoS attack that occurred during the period under review.

Quarter results
  • In Q1 2018, DDoS attacks were registered against targets in 79 countries (84 in the previous quarter). As ever, the vast majority (95.14%) occurred in the top ten countries.
  • As for attack targets, as usual about half were located in China (47.53%), although the share was somewhat lower against the previous quarter.
  • The number of attacks and targets rose significantly, as did the number of long-duration attacks. The most sustained DDoS attack lasted 297 hours (more than 12 days), making it one of the longest in recent years.
  • The share of Linux botnets fell slightly to 66% against the previous quarter’s 71%.
  • Significant peaks in the number and power of cyberattacks were observed in mid-January and early March, while the mid-quarter period was relatively calm.
Geography of attacks

China easily retained pole position by number of attacks: its share remained almost unchanged, up from 59.18% to 59.42%. The US share (17.83%), the second largest, increased by a more noticeable 1.83%. South Korea again took bronze, but its share fell by more than 2%, from 10.21% to 8%.

Britain (1.30%) moved from fourth to fifth. Tenth place in Q1 2018 went to Russia, whose share decreased from 1.25% to 0.76%. The Netherlands and Vietnam dropped out of the top ten, but Hong Kong (with a solid 3.67% against 0.67% in Q4 2017) and Japan (1.16%) reappeared.

Distribution of DDoS attacks by country, Q1 2018 and Q4 2017

As regards the distribution of attack targets, top spot again belongs to China, although its share declined from 51.84% to 47.53%. Meanwhile, the still second-place US saw its share increase from 19.32% to 24.10%. Third position was taken by South Korea (9.62%). France’s ranking changed significantly: shedding just 0.65% this quarter, it dropped from fifth to ninth place.

The list of top ten most attacked countries said goodbye to Russia and the Netherlands, but welcomed Hong Kong (4.76%) straight into fourth place, and Japan (1.6%) into sixth. Overall this quarter, the total share of top ten countries increased slightly to 94.17% against 92.9% at the end of 2017.

Distribution of unique DDoS-attack targets by country, Q4 2017 and Q1 2018

Dynamics of the number of DDoS attacks

Most Q1 activity occurred in the first and last third. The number of attacks peaked on January 19 (666) and March 7 (687 attacks). This is probably linked to the end of the New Year holidays (the number of attacks began to rise around the second week of January) and the March sales (in connection with International Women’s Day). The quietest days were observed at roughly the same time: January 16 and March 11. The mid-quarter period passed relatively smoothly without significant peaks or noticeable declines.

The calmest day of the week in the latest quarter was Sunday, accounting for just 11.35% of all attacks.

Distribution of DDoS attacks by day of the week, Q4 2017 and Q1 2018

Types and duration of DDoS attacks

The share of SYN-DDOS attacks increased slightly (from 55.63% to 57.3%), but there was no repeat of the situation seen in previous quarters. The share of ICMP attacks almost doubled, from 3.4% to 6.1%. Accordingly, UDP, TCP and HTTP floods were forced to cede some ground: their shares dropped by 1-2% against the previous quarter.

Distribution of DDoS attacks by type, Q1 2018

After some respite at the end of 2017, we saw a return of sustained attacks: the longest lasted 297 hours (12.4 days). And although that falls short of the world record, the magnitude is still considerable. We have to go back to late 2015 for a longer attack.

The share of all other sustained attacks (50 hours or more) increased by more than six times, from 0.10% to 0.63%. At the other end of the spectrum, the share of the shortest attacks (9 hours or less) also grew: if last quarter they accounted for 85.5% of all attacks, now the figure stands at 91.47%. Meanwhile, the number of attacks lasting between 10 hours and three days in the latest quarter almost halved from 14.85% to 7.76%.

Distribution of DDoS attacks by duration (hours), Q4 2017 and Q1 2018

The top ten countries by number of C&C servers last quarter underwent a major reshuffle: Canada, Turkey, Lithuania, and Denmark dropped out, while Italy, Hong Kong, Germany, and Britain climbed upwards. The top three remained practically unchanged: South Korea (30.92%), the US (29.32%), China (8.03%). Only Russia (2.01%), having shared bronze with China in late 2017, slid down to ninth place.

The US share almost doubled, bringing it within touching distance of this ranking’s perennial leader South Korea. In addition, the shares of Italy (6.83%), which last quarter did not even make the top ten, the Netherlands (5.62%), and France (3.61%) increased significantly. This jump was due to a sharp rise in the number of C&C accounts for Darkai (in the US, Italy, the Netherlands, and France) and AESDDoS (in China) bots.

Distribution of botnet C&C servers by country, Q1 2018

The share of Linux botnets last quarter fell slightly compared to the end of 2017, down to 66% from 71%. Accordingly, the share of Windows-based botnets climbed from 29% to 34%.

Correlation between Windows- and Linux-based botnet attacks, Q1 2018


In Q1 2018, we observed a significant increase in both the total number and duration of DDoS attacks against Q4 2017. The new Linux-based botnets Darkai (a Mirai clone) and AESDDoS are largely responsible for this hike. The number of now familiar Xor attacks also rose. Neither did Windows-based botnets remain idle, making some headway against Linux in the total number of attacks. The old Yoyo botnet was particularly lively, almost five times as active.

The number of mixed attacks involving several botnet families also increased. This is a clear continuation of the trend that we spoke about at the end of last year: to optimize outlays, attackers utilize unused parts of botnets to generate garbage traffic, redeploying them across targets.

Amplified attacks returned to the cyber arena, particularly through the Memcached service. However, we expect that server owners will quickly spot the abundance of garbage traffic and patch up the vulnerabilities, which will dent the popularity of attacks of this type. That being the case, DDoS masterminds will likely seek out other amplification methods, one of which could be LDAP services.

Energetic Bear/Crouching Yeti: attacks on servers

Malware Alerts - Mon, 04/23/2018 - 06:00

Energetic Bear/Crouching Yeti is a widely known APT group active since at least 2010. The group tends to attack different companies with a strong focus on the energy and industrial sectors. Companies attacked by Energetic Bear/Crouching Yeti are geographically distributed worldwide with a more obvious concentration in Europe and the US. In 2016-2017, the number of attacks on companies in Turkey increased significantly.

The main tactics of the group include sending phishing emails with malicious documents and infecting various servers. The group uses some of the infected servers for auxiliary purposes – to host tools and logs. Others are deliberately infected to use them in waterhole attacks in order to reach the group’s main targets.

Recent activity of the group against US organizations was discussed in a US-CERT advisory, which linked the actor to the Russian government, as well as an advisory by the UK National Cyber Security Centre.

This report by Kaspersky Lab ICS CERT presents information on identified servers that have been infected and used by the group. The report also includes the findings of an analysis of several webservers compromised by the Energetic Bear group during 2016 and in early 2017.

Attack victims

The table below shows the distribution of compromised servers (based on the language of website content and/or the origins of the company renting the server at the time of compromise) by countries, attacked company types and the role of each server in the overall attack scheme. Victims of the threat actor’s attacks were not limited to industrial companies.

Table 1. Compromised servers

Country Description Role in the attack Russia Opposition political website Waterhole Real estate agency Auxiliary (collecting user data in the waterhole attack) Football club Waterhole Developer and integrator of secure automation systems and IS consultant Waterhole Developers of software and equipment Auxiliary (collecting user data in the waterhole attack, tool hosting) Investment website Auxiliary (collecting user data in the waterhole attack) Ukraine Electric power sector company Waterhole Bank Waterhole UK Aerospace company Waterhole Germany Software developer and integrator Waterhole Unknown Auxiliary (collecting user data in the waterhole attack) Turkey Oil and gas sector enterprise Waterhole Industrial group Waterhole Investment group Waterhole Greece Server of a university Auxiliary (collecting user data in the waterhole attack) USA Oil and gas sector enterprise Waterhole Unknown Affiliate network site Auxiliary (collecting user data in the waterhole attack) Waterhole

All waterhole servers are infected following the same pattern: injecting a link into a web page or JS file with the following file scheme: file://IP/filename.png.

Injected link with the file scheme

The link is used to initiate a request for an image, as a result of which the user connects to the remote server over the SMB protocol. In this attack type, the attackers’ goal is to extract the following data from the session:

  • user IP,
  • user name,
  • domain name,
  • NTLM hash of the user’s password.

It should be noted that the image requested using the link is not physically located on the remote server.

Scanned resources

Compromised servers are in some cases used to conduct attacks on other resources. In the process of analyzing infected servers, numerous websites and servers were identified that the attackers had scanned with various tools, such as nmap, dirsearch, sqlmap, etc. (tool descriptions are provided below).

Table 2. Resources that were scanned from one of the infected servers

(based on the content)
Description Russia Non-profit organization Sale of drugs Travel/maps Resources based on the Bump platform (platform for corporate social networks) – non-profit organization, social network for college/university alumni, communication platform for NGOs, etc. Business – photographic studio Industrial enterprise, construction company Door manufacturing Cryptocurrency exchange Construction information and analysis portal Personal website of a developer Vainah Telecom IPs and Subnets (Chechen Republic)
Various Chechen resources (governmental organizations, universities, industrial enterprises, etc.) Web server with numerous sites (alumni sites, sites of industrial and engineering companies, etc.) Muslim dating site Brazil Water treatment Turkey Hotels Embassy in Turkey Software developer Airport website City council website Cosmetics manufacturer Religious website Turktelekom subnet with a large number of sites Telnet Telecom subnet with a large number of sites Georgia Personal website of a journalist Kazakhstan Unknown web server Ukraine Office supplies online store Floral business Image hosting service Online course on sales Dealer of farming equipment and spare parts Ukrainian civil servant’s personal website Online store of parts for household appliance repair Timber sales, construction Tennis club website Online store for farmers Online store of massage equipment Online clothes store Website development and promotion Online air conditioner store Switzerland Analytical company US Web server with many domains France Web server with many domains Vietnam Unknown server International Flight tracker

The sites and servers on this list do not seem to have anything in common. Even though the scanned servers do not necessarily look like potential final victims, it is likely that the attackers scanned different resources to find a server that could be used to establish a foothold for hosting the attackers’ tools and, subsequently, to develop the attack.

Part of the sites scanned may have been of interest to the attackers as candidates for hosting waterhole resources.

In some cases, the domains scanned were hosted on the same server; sometimes the attackers went through the list of possible domains matching a given IP.

In most cases, multiple attempts to compromise a specific target were not identified – with the possible exception of sites on the Bump platform, flight tracker servers and servers of a Turkish hotel chain.

Curiously, the sites scanned included a web developer’s website,, and resources links to which were found on this site. These may have been links to resources developed by the site’s owner:,,

Toolset used Utilities

Utilities found on compromised servers are open-source and publicly available on GitHub:

  • Nmap – an open-source utility for analyzing the network and verifying its security.
  • Dirsearch — a simple command-line tool for brute forcing (performing exhaustive searches of) directories and files on websites.
  • Sqlmap — an open-source penetration testing tool, which automates the process of identifying and exploiting SQL injection vulnerabilities and taking over database servers.
  • Sublist3r — a tool written in Python designed to enumerate website subdomains. The tool uses open-source intelligence (OSINT). Sublist3r supports many different search engines, such as Google, Yahoo, Bing, Baidu and Ask, as well as such services as Netcraft, Virustotal, ThreatCrowd, DNSdumpster and ReverseDNS. The tool helps penetration testers to collect information on the subdomains of the domain they are researching.
  • Wpscan — a WordPress vulnerability scanner that uses the blackbox principle, i.e., works without access to the source code. It can be used to scan remote WordPress sites in search of security issues.
  • Impacket — a toolset for working with various network protocols, which is required by SMBTrap.
  • SMBTrap — a tool for logging data received over the SMB protocol (user IP address, user name, domain name, password NTLM hash).
  • Commix — a vulnerability search and command injection and exploitation tool written in Python.
  • Subbrute – a subdomain enumeration tool available for Python and Windows that uses an open name resolver as a proxy and does not send traffic to the target DNS server.
  • PHPMailer – a mail sending tool.

In addition, a custom Python script named was found on one of the servers. The script was designed to check FTP hosts from an incoming list.

Malicious php files

The following malicious php files were found in different directories in the nginx folder and in a working directory created by the attackers on an infected web servers:

File name Brief description md5sum Time of the latest file change (MSK) Size, bytes ini.php wso shell+ mail f3e3e25a822012023c6e81b206711865 2016-07-01 15:57:38 28786 mysql.php wso shell+ mail f3e3e25a822012023c6e81b206711865 2016-06-12 13:35:30 28786 opts.php wso shell c76470e85b7f3da46539b40e5c552712 2016-06-12 12:23:28 36623 error_log.php wso shell 155385cc19e3092765bcfed034b82ccb 2016-06-12 10:59:39 36636 code29.php web shell 1644af9b6424e8f58f39c7fa5e76de51 2016-06-12 11:10:40 10724 proxy87.php web shell 1644af9b6424e8f58f39c7fa5e76de51 2016-06-12 14:31:13 10724 theme.php wso shell 2292f5db385068e161ae277531b2e114 2017-05-16 17:33:02 133104 sma.php PHPMailer 7ec514bbdc6dd8f606f803d39af8883f 2017-05-19 13:53:53 14696 media.php wso shell 78c31eff38fdb72ea3b1800ea917940f 2017-04-17 15:58:41 1762986

In the table above:

  • Web shell is a script that allows remote administration of the machine.
  • WSO is a popular web shell and file manager (it stands for “Web Shell by Orb”) that has the ability to masquerade as an error page containing a hidden login form. It is available on GitHub:

Two of the PHP scripts found, ini.php and mysql.php, contained a WSO shell concatenated with the following email spamming script:

All the scripts found are obfuscated.

wso shell – error_log.php

Deobfuscated wso shell – error_log.php

One of the web shells was found on the server under two different names (proxy87.php and code29.php). It uses the eval function to execute a command sent via HTTP cookies or a POST request:

Web shell – proxy87.php

Deobfuscated web shell – proxy87.php

Modified sshd

A modified sshd with a preinstalled backdoor was found in the process of analyzing the server.

Patches with some versions of backdoors for sshd that are similar to the backdoor found are available on GitHub, for example:

Compilation is possible on any OS with binary compatibility.

As a result of replacing the original sshd file with a modified one on the infected server, an attacker can use a ‘master password’ to get authorized on the remote server, while leaving minimal traces (compared to an ordinary user connecting via ssh).

In addition, the modified sshd logs all legitimate ssh connections (this does not apply to the connection that uses the ‘master password’), including connection times, account names and passwords. The log is encrypted and is located at /var/tmp/.pipe.sock.

Decrypted log at /var/tmp/.pipe.sock

Activity of the attackers on compromised servers

In addition to using compromised servers to scan numerous resources, other attacker activity was also identified.

After gaining access to the server, the attackers installed the tools they needed at different times. Specifically, the following commands for third-party installations were identified on one of the servers:

  • apt install traceroute
  • apt-get install nmap
  • apt-get install screen
  • git clone

Additionally, the attackers installed any packages and tools for Python they needed.

The diagram below shows times of illegitimate logons to one of the compromised servers during one month. The attackers checked the smbtrap log file on working days. In most cases, they logged on to the server at roughly the same time of day, probably in the morning hours:

Times of illegitimate connections with the server (GMT+3)

In addition, in the process of performing the analysis, an active process was identified that exploited SQL injection and collected data from a database of one of the victims.


The findings of the analysis of compromised servers and the attackers’ activity on these servers are as follows:

  1. With rare exceptions, the group’s members get by with publicly available tools. The use of publicly available utilities by the group to conduct its attacks renders the task of attack attribution without any additional group ‘markers’ very difficult.
  2. Potentially, any vulnerable server on the internet is of interest to the attackers when they want to establish a foothold in order to develop further attacks against target facilities.
  3. In most cases that we have observed, the group performed tasks related to searching for vulnerabilities, gaining persistence on various hosts, and stealing authentication data.
  4. The diversity of victims may indicate the diversity of the attackers’ interests.
  5. It can be assumed with some degree of certainty that the group operates in the interests of or takes orders from customers that are external to it, performing initial data collection, the theft of authentication data and gaining persistence on resources that are suitable for the attack’s further development.
Appendix I – Indicators of Compromise Filenames and Paths Tools*


*Note that these tools can also be used by other threat actors.

PHP files:




PHP file hashes


Yara rules

rule Backdoored_ssh {
$a1 = “OpenSSH”
$a2 = “usage: ssh”
$a3 = “HISTFILE”
uint32(0) == 0x464c457f and filesize<1000000 and all of ($a*)

Appendix II – Shell script to check a server for tools Shell script for Debian

cd /tmp
mkdir $workdir
cd $workdir
find / -type d -iname smbtrap > find-smbtrap.txt 2>/dev/null
find / -type d -iname dirsearch > find-dirsearch.txt 2>/dev/null
find / -type d -iname nmap > find-nmap.txt 2>/dev/null
find / -type d -iname wpscan > find-wpscan.txt 2>/dev/null
find / -type d -iname sublist3r > find-sublist3r.txt 2>/dev/null
dpkg -l | grep -E \(impacket\|pcapy\|nmap\) > dpkg-grep.txt
cp /var/lib/dpkg/info/openssh-server.md5sums . #retrieve initial hash for sshd
md5sum /usr/sbin/sshd > sshd.md5sum #calculate actual hash for sshd

Shell script for Centos

cd /tmp
mkdir $workdir
cd $workdir
find / -type d -iname smbtrap > find-smbtrap.txt 2>/dev/null
find / -type d -iname dirsearch > find-dirsearch.txt 2>/dev/null
find / -type d -iname nmap > find-nmap.txt 2>/dev/null
find / -type d -iname wpscan > find-wpscan.txt 2>/dev/null
find / -type d -iname sublist3r > find-sublist3r.txt 2>/dev/null
rpm -qa | grep -E \(impacket\|pcapy\|nmap\) > rpm-grep.txt
rpm -qa –dump | grep ssh > rpm-qa-dump.txt #retrieve initial hash for sshd
sha256sum /usr/sbin/sshd > sshd.sha256sum #calculate actual sha256 hash for sshd
md5sum /usr/sbin/sshd > sshd.md5sum #calculate actual md5 hash for sshd

 Energetic Bear/Crouching Yeti: attacks on servers

Tens of thousands per Gram

Malware Alerts - Thu, 04/19/2018 - 06:00

Looking at Instagram one morning, I spotted several posts from some fairly well-known people (in certain circles) who had invested in an ICO held by Telegram. Interesting, I thought to myself. I fancy a piece of that. Only I was pretty sure that if Telegram was indeed holding an ICO, it would be a private affair — off limits to cash-strapped social media-based “investors.” That’s when I decided to do some digging.

Let’s start with a brief history lesson. In late 2017, information appeared on specialized resources about a Telegram ICO to finance the launch of its own blockchain platform based on TON (Telegram Open Network) technology. Despite the fact that Pavel Durov did not confirm the ICO rumors, and no information was posted on the company’s official website (and still hasn’t been), the mooted project attracted a huge number of potential investors. According to various (dubious) sources, participation in the ICO is by invitation only, and the first closed round, the so-called presale, has already taken place. Technical documentation and a white paper also appeared online, but their authenticity is not confirmed.

Perhaps the masterminds behind the project deliberately clothed it in mystery to spark interest. In any case, the lack of information bred speculation and provided fertile ground for scammers: the rumors prompted mailshots seemingly from official representatives of the platform, inviting people to take part in the ICO and purchase tokens. And there was a mushrooming of sites supposedly selling Grams (the name of the cryptocurrency that Telegram presumably intends to launch).

When creating fake sites, cybercriminals try to keep to the style of technical documentation and white papers

Meanwhile, Pavel Durov tweeted that all TON-related news would be posted only on the official website, and asked for any “Gram” sales to be reported:

If you see or receive offers to "buy Grams", let us know at

— Pavel Durov (@durov) 21 января 2018 г.

Despite the announcement, fake sites continued scooping cash from unwitting victims. But to give credit where it’s due, their creators did a superb job. Unlike some phishing fakes, these sites really do lure people in. Not only that, most use a secure connection, require registration, and generate a unique online wallet for each new victim, making it hard to track the movement of money.

Grams can be purchased in a selection of cryptocurrencies

The price of the new cryptocurrency varies greatly from one fake site to the next. And although most of them create unique wallets for victims, I managed to find several that use static wallets. From the transaction history of one of them, we see that the cybercriminals withdrew 85 ETH:

Withdrawal of funds harvested in Ethereum

At the time of writing this article, the Ethereum exchange rate was about $422. This resource alone seems to have collected more than 35 000$(2 million rubles), and there are dozens like it. Judging by their content, it’s possible they have common ownership. For example, several have one and the same Our Team section.

Suspiciously similar Our Team sections

While the presence of the Durov brothers doesn’t raise any question marks, Lucas Pernas-Valles seems to exist only on dozens of other fake sites. He may indeed be a member of Telegram’s new project team, but a brief online check reveals that the person in the photo is not called Lucas Pernas-Valles, although he does have cryptocurrency links.

It should be noted that this ICO project is one of relatively few to have attracted mass attention. And where there’s mass attention, there’s fraud. The lack of reliable information from official sources only serves to aggravate the situation

Leaking ads

Malware Alerts - Tue, 04/17/2018 - 17:15

When we use popular apps with good ratings from official app stores we assume they are safe. This is partially true – usually these apps have been developed with security in mind and have been reviewed by the app store’s security team. However, we found that because of third-party SDKs many popular apps are exposing user data to the internet, with advertising SDKs usually to blame. They collect user data so they can show relevant ads, but often fail to protect that data when sending it to their servers.

During our research into dating app security, we found that some analyzed apps were transmitting unencrypted user data through HTTP. It was unexpected behavior because these apps were using HTTPS to communicate with their servers. But among the HTTPS requests there were unencrypted HTTP requests to third-party servers. These apps are pretty popular, so we decided to take a closer look at these requests.

HTTP request with unencrypted user data

One of the apps was making POST requests to the api.quantumgraph[.]com server. By doing so it was sending an unencrypted JSON file to a server that is not related to the app developers. In this JSON file we found lots of user data, including device information, date of birth, user name and GPS coordinates. Furthermore, this JSON contained detailed information about app usage that included information about profiles liked by the user. All this data was sent unencrypted to the third-party server and the sheer volume makes it really scary. This is due to the use of a qgraph analytics module.

Unencrypted user data sent by app

Two other dating apps from our research were basically doing the same. They were using HTTPS to communicate with their servers, but at the same time there were HTTP requests with unencrypted user data being sent to a third-party server. This time it was another server belonging not to an analytics company but to an advertising network used by both dating apps. Another difference was GET HTTP requests with user data being used as parameters in a URL. But in general these apps were doing the same thing – transmitting unencrypted user data to third-party servers.

List of HTTP requests from advertising SDK

At this point it already looked bad, so I decided to check my own device, collecting network activity for one hour. It turned out to be enough to identify unencrypted requests with my own data. And again the cause of these requests was a third-party SDK used by a popular app. It was transmitting my location, device information and token for push messages.

HTTP request from my device with my own unencrypted data

So I decided to take a look at those dating apps with the leaking SDKs to find out why it was happening. It came as no surprise that they were used by more than one third party in these apps – in fact, every app contained at least 40 different modules. They make up a huge part of these apps – at least 75% of the Dalvik bytecode was in third-party modules; in one app the proportion of third-party code was as high as 90%.

List of modules from analyzed dating apps

Developers often use third-party code to save time and make use of existing functionality. This makes perfect sense and allows developers to focus on their own ideas instead of working on something that has already been developed many times before. However, this means developers are unlikely to know all the details of the third-party code used and it may contain security issues. That’s what happened with the apps from our research.

Getting results

Knowing that there are popular SDKs exposing user data and that almost every app uses several SDKs, we decided to search for more of these apps and SDKs. To do so we used network traffic dumps from our internal Android sandbox. Since 2014 we have collected network activities from more than 13 million APKs. The idea is simple – we install and launch an app and imitate user activity. During app execution we collect logs and network traffic. There is no real user data, but to the app it looks like a real device with a real user.

We searched for the two most popular HTTP requests – GET and POST. In GET requests user data is usually part of the URL parameters, while in GET requests user data is in the Content field of the request, not the URL. In our research, we looked for apps transmitting unencrypted user data using at least one of these requests, though many were exposing user data in both requests.

We were able to identify more than 4 million APKs exposing some data to the internet. Some of them were doing it because their developers had made a mistake, but most of the popular apps were exposing user data because of third-party SDKs. For each type of request (GET or POST) we extracted the domains where apps were transmitting user data. Then we sorted these domains by app popularity – how many users had these apps installed. That’s how we identified the most popular SDKs leaking user data. Most of them were exposing device information, but some were transmitting more sensitive information like GPS coordinates or personal information.

Four most popular domains where apps were exposing sensitive data through GET requests

This domain is part of a popular advertising network. It was used by the two dating apps mentioned at the beginning of this article. We found many more popular apps with this SDK – at least five of them have more than 100 million installations according to Google Play Store and many others with millions of installations.

It transmits the following data in unencrypted form:

  • device information (manufacturer name, model, screen resolution)
  • network information (MCC, MNC)
  • package name of the app
  • device coordinates
  • Key words

HTTP request with user data in URL

Key words are the most interesting part of the transmitted data. They can vary depending on app parameter settings. In our data there was usually some personal information like name, date of birth and gender. Location needs to be set by an app too – and usually apps provide GPS coordinates to the advertising SDK.

We found several different versions of this SDK. The most common version was able to use HTTPS instead of HTTP. But it needs to be set by the app developers and according to our findings they mostly didn’t bother, leaving the default value HTTP.

Advertising SDK using HTTP by default

This domain is also part of a popular advertising network. We found two apps with more than 500 million installations, seven apps with more than 100 million installations and many others with millions of installations.

It transmits the following data:

  • device information (manufacturer name, model, screen resolution, OS version, device language, time zone, IMEI, MAC)
  • network information (MCC, MNC)
  • package name of the app
  • device coordinates

We should mention that while most of this data was transmitted in plain text as URL parameters, the coordinates, IMEI and MAC address were encoded with Base64. We can’t say they were protected, but at least they weren’t in plain text. We were unable to find any versions of this SDK where it’s possible to use HTTPS – all versions had HTTP URLs hardcoded.

Advertising SDK collects device location

Another popular advertising SDK that collects the same data as the others:

  • device information (manufacturer name, model)
  • network operator code
  • package name of the app
  • device coordinates

We found seven apps with more than 10 million installations from Google Play Store and many other apps with fewer installations. We were unable to find any way for the developers to switch from HTTP to HTTPS in this SDK either.

The fourth advertising SDK is appsgeyser and it differs from the others in that it is actually a platform to build an app. It allows people who don’t want to develop an app to simply create one. And that app will have an advertising SDK in it that uses user data in HTTP requests. So, these apps are actually developed by this service and not by developers.

They transmit the following data:

  • device information (manufacturer name, model, screen resolution, OS version, android_id)
  • network information (operator name, connection type)
  • device coordinates

We found a huge amount of apps that have been created with this platform and are using this advertising SDK, but most of them are not very popular. The most popular have just tens of thousands of installations. However, there really are lots of these apps.

Screenshot of

According to the web page there are more than 6 million apps with almost 2 billion installations between them. And they showed almost 200 billion ads – probably all via HTTP.

Four most popular domains where apps were exposing sensitive data through POST requests

All apps posting unencrypted data to this server were created by the same company, so it isn’t because of third-party code. But these apps are very popular – one of them was installed more than 500 million times from Google Play Store. These apps collect a large amount of device information:

  • manufacturer name
  • model
  • screen resolution
  • OS version
  • device language
  • country
  • android_id
  • IMEI
  • IMSI
  • MAC

Device information collected by the app

This unencrypted data is then sent to the server. Furthermore, among the data they are uploading is a list of supported commands – one of them is to install an app. The list of commands is transmitted in plain text and the answer from the server is also unencrypted. This means it can be intercepted and modified. What is even worse about this functionality is that the app can silently install a downloaded app. The app just needs to be a system app or have root rights to do so.

Fragment of code related to the silent installation of apps upon command from the server


Here is another example of popular apps leaking user data not because of third-party code but because of a mistake by developers. We found several popular Lenovo apps collecting and transmitting unencrypted device information:

  • IMEI
  • OS version
  • language
  • manufacturer name
  • model
  • screen resolution

H TTP request with unencrypted device information

This information is not very sensitive. But we found several Lenovo apps that were sending more sensitive data in unencrypted form, such as GPS coordinates, phone number and email.

App code for the collection of device coordinates and other data

We reported these issues to Lenovo and they fixed everything.

This domain is used by a very popular advertising SDK. There are tons of apps using it. One of them even has more than 500 million installations and seven other apps have more than 100 million installations. Most of the apps with this SDK are games. There are two interesting things about this SDK – the transmitted data and the protocol used.

This SDK sends the following data to the server:

  • device information (screen resolution, storage size, volume, battery level)
  • network information (operator name, IP address, connection type, signal strength)
  • device coordinates

It also sends information about hardware availability:

  • Front/rear camera availability
  • NFC permission
  • Bluetooth permission
  • Microphone permission
  • GPS coordinates permission

Advertising SDK that collects information about device hardware features

It may also send some personal information, such as age, income, education, ethnicity, political view, etc. There’s no magic involved – the SDK has no way of finding this information unless the apps that are using this SDK provide it. We have yet to see any app providing these details to the SDK, but we think users should be aware of the risks when entering such details to apps. The information could be passed on to the SDK and the SDK could expose it to the internet.

Advertising SDK could send personal information

The second interesting thing about this SDK is that it uses HTTPS to transmit data, but usually only for the initial communication. After that it may receive new configuration settings from the server that specify an HTTP URL. At least that’s what happened on my device and several other times with different apps on our test devices.

HTTPS URL in advertising SDK

Another SDK that is leaking data uses the domain. This is an analytics SDK, not an advertising one. We found two apps with more than 10 million installations from Google Play Store and another seven apps with more than a million installations. More than 90% of detected users with this SDK were from India.

This SDK posts JSON files with data via HTTP. The data may vary from app to app because it’s an analytics SDK and it sends information provided by the app. In most cases, the following items are among the sent data:

  • Device information
  • Personal information
  • Device coordinates
  • App usage

List of installed apps were sent in unencrypted form to the server

In the case of the dating app, there were likes, swipes and visited profiles – all user activity.

App usage was sent in unencrypted form to the server

This SDK was using a hardcoded HTTP URL, but after our report they created a version with an HTTPS URL. However, most apps are still using the old HTTP version.

Other SDKs

Of course, there are other SDKs using HTTP to transmit user data, but they are less popular and almost identical to those described above. Many of them expose device locations, while some also expose emails and phone numbers.

Phone number and email collected by an app to be sent via HTTP

Other findings

During our research, we found many apps that were transmitting unencrypted authentication details via HTTP. We were surprised to discover how many apps are still using HTTP to authenticate their services.

Unencrypted request with authentication token

They weren’t always transmitting user credentials – sometimes they were credentials for their services (for example databases) too. It makes no sense having credentials for such services because they are exposed to the internet. Such apps usually transmit authentication tokens, but we saw unencrypted logins and passwords too.

Unencrypted request with credentials


Digging into an HTTP request with unencrypted data allowed us to discover a new malicious site. It turns out that many malicious apps use HTTP to transmit user data too. And in the case of malware it is even worse because it can steal more sensitive data like SMSs, call history, contacts, etc. Malicious apps not only steal user data but expose it to the internet making it available for others to exploit and sell.

Leaked data

In this research we analyzed the network activity of more than 13 million APK files in our sandbox. On average, approximately every fourth app with network communications was exposing some user data. The fact that there are some really popular apps transmitting unencrypted user data is significant. According to Kaspersky Lab statistics, on average every user has more than 100 installed apps, including system and preinstalled apps, so we presume most users are affected.

In most cases these apps were exposing:

  • IMEI, International Mobile Equipment Identities (unique phone module id) which users can’t reset unless they change their device.
  • IMSI, International Mobile Subscriber Identities (unique SIM card id) which users can’t reset unless they change their SIM card.
  • Android ID – a number randomly generated during the phone’s setup, so users can change it by resetting their device to factory settings. But from Android 8 onwards there will be a randomly generated number for every app, user and device.
  • Device information such as the manufacturer, model, screen resolution, system version and app name.
  • Device location.

Some apps expose personal information, mostly the user’s name, age and gender, but it can even include the user’s income. Their phone number and email address can also be leaked.

Why is it wrong?

Because this data can be intercepted. Anyone can intercept it on an unprotected Wi-Fi connection, the network owner could intercept it, and your network operator could find out everything about you. Data will be transmitted through several network devices and can be read on any of them. Even your home router can be infected – there are many examples of malware infecting home routers.

Without encryption this data is being exposed as plain text and can be simply extracted from the requests. By knowing the IMSI and IMEI anyone can track your data from different sources – you need to change both the SIM card and device at the same time to change them. Armed with these numbers, anyone can collect the rest of your leaking data.

Furthermore, HTTP data can be modified. Someone could change the ads being displayed or, even worse, change the link to an app. Because some advertising networks promote apps and ask users to install them, it could result in malware being downloaded instead of the requested app.

Apps can intercept HTTP traffic and bypass the Android permission system. Android uses permissions to protect users from unexpected app activity. This involves apps declaring what access they will need. Starting from Android 6, all permissions have been divided into two groups – normal and dangerous. If an app needs dangerous permissions, it has to ask the user for permission in runtime, not just before installation. So, in order to get the location, the app will need to ask the user to grant access. And to read the IMEI or IMSI the app will also need to ask the user for access, because this is classified as a dangerous permission.

But an app can add a proxy to Wi-Fi settings and read all the data being transmitted from other apps. To do so it needs to be a system app or be provisioned as the Profile or Device Owner. Or an app can set a VPN service on the device transmitting user data to its server. After that the app can find out the device’s location without accessing it just by reading the HTTP requests.


HTTP (blue) and HTTPS (orange) usage in apps since March 2014

Starting from the second half of 2016, more and more apps have been switching from HTTP to HTTPS. So, we are moving in the right direction, but too slowly. As of January 2018, 63% of apps are using HTTPS but most of them are still also using HTTP. Almost 90% of apps are using HTTP. And many of them are transmitting unencrypted sensitive data.

Advice for developers
  • Do not use HTTP. You can expose user data, which is really bad.
  • Turn on 301 redirection to HTTPS for your frontends.
  • Encrypt data. Especially if you have to use HTTP. Asymmetric cryptography works great.
  • Always use the latest version of an SDK. Even if it means additional testing before the release. This is really important because some security issues could be fixed. From what we have seen, many apps do not update third-party SDKs, using outdated versions instead.
  • Check your app’s network communications before publishing. It won’t take more than a few minutes but you will be able to find out if any of your SDKs are switching from HTTPS to HTTP and exposing user data.
Advice for users
  • Check your app permissions. Do not grant access to something if you don’t understand why. Most apps do not need access to your location. So don’t grant it.
  • Use a VPN. It will encrypt the network traffic between your device and external servers. It will remain unencrypted behind the VPN’s servers, but at least it’s an improvement.

Roaming Mantis uses DNS hijacking to infect Android smartphones

Malware Alerts - Mon, 04/16/2018 - 04:30

In March 2018, Japanese media reported the hijacking of DNS settings on routers located in Japan, redirecting users to malicious IP addresses. The redirection led to the installation of Trojanized applications named facebook.apk and chrome.apk that contained Android Trojan-Banker. According to our telemetry data, this malware was detected more than 6,000 times, though the reports came from just 150 unique users (from February 9 to April 9, 2018). Of course, this is down to the nature of the malware distribution, but it also suggests a very painful experience for some users, who saw the same malware appear again and again in their network. More than half of the detections were observed targeting the Asian region.

During our research we received some invaluable information about the true scale of this attack. There were thousands of daily connections to the command and control (C2) infrastructure, with the device locale for the majority of victims set to Korean. Since we didn’t find a pre-existing name for this malware operation, we decided to assign a new one for future reference. Based on its propagation via smartphones roaming between Wi-Fi networks, potentially carrying and spreading the infection, we decided to call it ‘Roaming Mantis’.


Roaming Mantis malware is designed for distribution through a simple, but very efficient trick based on a technique known as DNS hijacking. When a user attempts to access any website via a compromised router, they will be redirected to a malicious website. For example, if a user were to navigate to using a web browser, the browser would be redirected to a rogue server which has nothing to do with the security research blog. As long as the browser displays the original URL, users are likely to believe the website is genuine. The web page from the rogue server displays the popup message (screenshot below): “To better experience the browsing, update to the latest chrome version.”

Looking at the HTML source of the malicious webpage, it seems to support five locales: Korean, Traditional Chinese, Simplified Chinese, Japanese and English.

However, after carefully studying the HTML source, we found that the actual number of target locales is only four: Korean, Simplified Chinese, Japanese and English, based on Android devices. As shown in the image above, the HTML code contains an identical message in Traditional Chinese and Simplified Chinese. Also, the HTML source contains several short code comments in Simplified Chinese.

Analyzing chrome.apk

One of the applications pushed to users impersonated a Chrome browser for Android. Kaspersky Lab got a copy of chrome.apk (md5:f3ca571b2d1f0ecff371fb82119d1afe) in April 2018. The Android application package structure is as follows:

The package contains classes.dex, which is a Dalvik VM executable file. Its main purpose is to read the file named /assets/db. It decodes the data inside with a Base64 decoder and produces another Dalvik VM executable named test.dex:

The extracted test.dex contains the main malicious payload, which is described in more detail below. The Base64 encoding technique is probably used to bypass trivial signature-based detection.

AndroidManifest.xml contains one of the key components of the package – the permissions requested by the application from the device owner during installation.

From the xml above, it seems that Roaming Mantis requests permission to be notified when the device is booted, using the internet, collecting account information, managing SMS/MMS and making calls, recording audio, controlling external storage, checking packages, working with file systems, drawing overlay windows and so on. All these requests are of course backed up by malicious functionality implemented in test.dex.

For instance, after installation, the malware overlays all other windows with one carrying a message in broken English: “Account No.exists risks, use after certification”. After that, the malware starts its own webserver on the device, and renders a page spoofing Google’s authentication on

The page uses a Google account name obtained from the infected device and asks the owner to complete two input boxes with ‘Name:’ and ‘Date of birth:’, which would facilitate access to the user account. After the user enters their name and date of birth, the browser is redirected to a blank page at${random_port}/submit.

While analyzing the extracted test.dex, we found an interesting piece of code.

Just like the distribution page, the malware supports four locales: Korean, Traditional Chinese, Japanese and English. The code above was taken from an original Google authentication page intended for an English environment, though we aren’t sure why the three Korean strings appear here. The English translations are as follows:

  • I have an anomaly on my Google account. For voice verification, enter your verification number to verify your Google account. //구글 계정이 이상이 있습니다.음성검증을 들어 인증번호를 입력하여 구글 계정을 검증하도록합니다.
  • Verification Number. //인증번호
  • Please enter your verification number. //인증번호를 입력하세요

Judging by these strings, it’s clear that the criminals behind the malware are trying to get a verification code for two-factor authentication. There may be a bug or design fault that causes Korean strings to be displayed not just for Korean users but also for those using Japanese and English. Traditional Chinese users will see strings in Traditional Chinese. The authors could have overlooked this in the rush to launch the campaign, but it reveals a certain bias by the authors towards Korean and Traditional Chinese.

Permission to receive/read/write/send SMS/MMS and record audio could also allow the malware operators to steal a verification code for the two-factor authentication function.

Secondly, this malware contains references to Android application IDs popular in South Korea and mostly linked to mobile banking and games.

The following hardcoded strings were extracted from the malware:

  • kbstar.kbbank
  • ibk.neobanking
  • sc.danb.scbankapp
  • shinhan.sbanking
  • smart
  • epost.psf.sdsi
  • kftc.kjbsmb
  • smg.spbs
  • ncsoft.lineagem19
  • ncsoft.lineagem
  • co.neople.neopleotp
  • nexon.axe
  • nexon.nxplay

Another piece of code verifies the presence of the su binary in /system/bin/, /system/xbin/, /system/sbin/, sbin/ or /vendor/bin/ on a device.

Regular Android devices do not have the su binary. Its presence means the device is probably rooted. For attackers this may indicate that a device is owned by an advanced Android user (a signal to stop messing with the device) or, alternatively, a chance to leverage root access to gain access to the whole system.

C2 communication

Kaspersky Lab discovered a hardcoded URL template ( in the malicious application used for malware control. The site is legitimate; however, some content on the user profile pages is controlled by the owners of the profiles.

A list of account IDs separated by the “|” character were included in the malware: “329505231|329505325|329505338”.

After getting the content from the webpage, the malware extracts a Chinese string from a specific part of the HTML code.

For example, the malicious application receives the page at

After that, it uses the hardcoded regular expression “<p>([\u4e00-\u9fa5]+?)</p>\s+</div>” to extract a Chinese string located in a very distinct place on the web page. Next, each character is decoded by subtracting 0x4E00, doing a right bitwise shift operation for 3 bits and xoring using the word “beg” as the key.

The result is the real C2 address, which the malware connects to by using a web socket. We traced this activity in the debug log of an infected device.

In another recent sample (MD5:4d9a7e425f8c8b02d598ef0a0a776a58), the connection protocol, including a hardcoded legitimate website, accounts and the regular expression for retrieving next level C2, had been changed:

MD5 f3ca571b2d1f0ecff371fb82119d1afe 4d9a7e425f8c8b02d598ef0a0a776a58 Date March 29 2018 April 7 2018 Legitimate web[.]com/user/%s[.]com/p/%s/detail account_IDs ● 329505231
● 329505325
● 329505338 ● haoxingfu88
● haoxingfu12389
● wokaixin158998 pattern “<p>([\u4e00-\u9fa5]+?)</p>\s+</div>” “公司</span>([\\u4e00-\\u9fa5]+?)<“ Encrypted dex \assets\db \assets\data.sql Encoding Base64 Base64 + zlib compression

In addition, the \assets\db file name was changed to \assets\data.sql and it’s encoding algorithm have also been changed from Base64 to Base64+zlib. The malware author seems to be updating the code quite regularly.

Researchers wishing to track Roaming Mantis campaign can use the following simplified python script to decode the real C2 server.

#!/usr/bin/env python # -*- coding: utf-8 -*- import sys import re page = open(sys.argv[1],"rb").read() #pattern = u'&lt;p&gt;([\u4e00-\u9fa5]+?)&lt;/p&gt;\s+&lt;/div&gt;' # pattern = u'公司&lt;/span&gt;([\u4e00-\u9fa5]+?)&lt;' # match =, page.decode("utf-8")) ext = dec = '' j = 0 for i in range(len(ext)): dec = dec + chr((ord(ext[i]) - 0x4e00) &gt;&gt; 3 ^ ord('beg'[j])) j = (j+1) %3 print(dec)

An example of script input and output:

$ python 220.136.76[.]200:8844 $ python 220.136.179[.]5:28833

Most interestingly, the malware is embedded with a new feature that communicates with the C2 via email protocols. The data sent contains language, phone number, access information, and the result of a PING test to the C2.

Malware detection statistics

Kaspersky Lab products detect Roaming Mantis’s malicious apk file as Trojan-Banker.AndroidOS.Wroba. Based on the verdict, we checked the statistics from Kaspersky Security Network (KSN) for the two months from February 9 to April 9, 2018.

There were more than 6,000 detections coming from just over 150 unique users. The most affected countries were South Korea, Bangladesh and Japan. Based on the design of the malware and our detection statistics, this malware was designed to be spread mainly in Asian countries. While Kaspersky Lab products may only see a limited number of infections, based on further analysis of the C2 infrastructure we saw roughly 3,000 connections to C2 infrastructure per day, which suggests a much larger scale for this Android malware campaign. Upon every connection the malware sends information about compromised devices to the C2, including system locale, which indicates the possible origins of the victims. 98% of affected devices appear to have the Korean locale set.

We have done some calculations and built the following chart based on observed locales:

The breakdown of the remaining 2% reveals a few more system locales: en_GB, en_US, zh_CN, ja_JP and others.

As usual in such cases, Kaspersky Lab has got in touch with local CERTs (South Korea being the first) to provide information about the victims to help unsuspecting users remove the malware and prevent further reinfections.


Kaspersky Lab observed Roaming Mantis’ Android application being distributed via a DNS hijacking technique with the help of compromised routers. The malware aims to steal user information, including credentials for two-factor authentication, and give the attackers full control over compromised Android devices.

At the moment, clues appear to suggest a financial motive and low OPSEC for this attack, which is why we think it is likely to be the work of cybercriminal hackers.

Our research revealed that the malare contains Android application IDs for popular mobile banking and game applications in South Korea. The malware is most prevalent in South Korea, and Korean is the first language targeted in HTML and test.dex. Based on our findings, it appears the malicious app was originally distributed to South Korean targets. Support was then added for Traditional Chinese, English and Japanese, broadening its target base in the Asian region.

However, it’s still unclear how the attackers hijacked the router DNS settings. If you have any concerns about the DNS settings on your router, please check the user manual and verify that your DNS settings haven’t been tampered with, or contact your ISP for support. Kaspersky Lab also strongly recommends changing the default login and password for the admin web interface of their router, never install firmware from third-party sources and regularly update router firmware to prevent similar attacks in the future.

Based on our investigation, the Roaming Mantis attackers left some additional clues. For example, some comments in the HTML source, malware strings and a hardcoded legitimate website point to Simplified Chinese. Therefore, we believe the cybercriminals are familiar with both Simplified Chinese and Korean.

The malicious threat actor behind this campaign remains very active and the malware is updated every day. We will keep tracking this campaign to protect our customers and update our readers with new information.

Kaspersky Lab products detect this malware with the following verdict(s):


Malicious hosts:

Malicious apks:



APT Trends report Q1 2018

Malware Alerts - Thu, 04/12/2018 - 06:00

In the second quarter of 2017, Kaspersky’s Global Research and Analysis Team (GReAT) began publishing summaries of the quarter’s private threat intelligence reports in an effort to make the public aware of the research we have been conducting. This report serves as the next installment, focusing on the relevant activities that we observed during Q1 2018.

These summaries serve as a representative snapshot of what has been discussed in greater detail in our private reports, in order to highlight the significant events and findings that we feel people should be aware of. For brevity’s sake, we are choosing not to publish indicators associated with the reports highlighted. However, if you would like to learn more about our intelligence reports or request more information on a specific report, readers are encouraged to contact:

Remarkable new findings

We are always very interested in analyzing new techniques used by existing groups, or in finding new clusters of activity that might lead us to discover new actors. In Q1 2018 we observed a bit of both, which are briefly summarized in this section.

We would like to start by highlighting all the new exploitation techniques applicable for the Meltdown/Spectre vulnerabilities that affect different CPU architectures and vendors. Even though we haven’t seen any of them exploited in the wild so far (only several PoCs) and although vendors have provided various patches to mitigate them, there is still no real solution. The problem relies on the optimization methods used at the processor’s architecture level. Given that a massive hardware replacement is not a realistic solution, Meltdown and Spectre might very well open the door to new infection vectors and persistence methods that we will see in the future.

A similar case was the announcement of several flaws for AMD processors. Even when the full technical details were not yet available, AMD confirmed that these flaws could be exploited for privilege escalation and persistence once a target has been compromised.

We also observed an increasing interest from attackers, including sophisticated actors, in targeting routers and networking hardware. Some early examples of such attacks driven by advanced groups include Regin and CloudAtlas. Additionally, the US Government published an advisory on unusual reboots in a prominent router brand, which might indicate that these specific devices are being actively targeted.

In our Slingshot analysis, we described how the campaign was using Mikrotik routers as an infection vector, compromising the routers to later infect the final victim through the very peculiar mechanism that Mikrotik used for the remote management of devices. In actual fact, we recognised the interest of some actors in this particular brand when the Chimay-red exploit for Mikrotek was mentioned in Wikileak´s Vault7. This same exploit was later reused by the Hajime botnet in 2018, showing once again how dangerous leaked exploits can be. Even when the vulnerability was fixed by Mikrotik, networking hardware is rarely managed properly from a security perspective. Additionally, Mikrotik reported a zero day vulnerability (CVE-2018-7445) in March 2018.

We believe routers are still an excellent target for attackers, as demonstrated by the examples above, and will continue to be abused in order to get a foothold in the victim´s infrastructure.

One of the most relevant attacks during this first quarter of 2018 was the Olympic Destroyer malware, affecting several companies related to the Pyeongchang Olympic Games’ organization and some Olympic facilities. There are different aspects of this attack to highlight, including the fact that attackers compromised companies that were providing services to the games´ organization in order to gain access, continuing the dangerous supply chain trend.

Besides the technical considerations, one of the more open questions is related to the general perception that attackers could have done much more harm than they actually did, which opened some speculation as to what the real purpose of the attack was.

MZ DOS and Rich headers of both files (3c0d740347b0362331c882c2dee96dbf – OlympicDestroyer, 5d0ffbc8389f27b0649696f0ef5b3cfe – Bluenoroff) are exactly the same.

In addition, a very relevant aspect is the effort attackers put in to planting several elaborative false flags, making this attack one of the most difficult we have analyzed in terms of attribution.

In February, we published a report about a previously unknown advanced Android backdoor that we call Skygofree. It seems that the author could be an Italian company selling the product in a similar way to how Hacking Team did in the past, however we don’t yet have any proof of this. Interestingly, shortly after we detected the Android samples of this malware, we also found an early iOS version of the backdoor. In this case, attackers had abused a rogue MDM (Mobile Device Management) server in order to install their malware in victims’ devices, probably using social engineering techniques to trick them into connecting with the rogue MDM.

Finally, we would like to highlight three new actors that we have found, all of them focused in the Asia region:

  • Shaggypanther – A Chinese-speaking cluster of activity targeting government entities, mainly in Taiwan and Malaysia, active since 2008 and using hidden encrypted payloads in registry keys. We couldn’t relate this to any known actor.
  • Sidewinder – An actor mainly targeting Pakistan military targets, active since at least 2012. We have low confidence that this malware might be authored by an Indian company. To spread the malware, they use unique implementations to leverage the exploits of known vulnerabilities (such as CVE-2017-11882) and later deploy a Powershell payload in the final stages.
  • CardinalLizard – We are moderately confident that this is a new collection of Chinese-speaking activity targeting businesses, active since 2014. Over the last few years, the group has shown an interest in the Philippines, Russia, Mongolia and Malaysia, the latter especially prevalent during 2018. The hackers use a custom malware featuring some interesting anti-detection and anti-emulation techniques. The infrastructure used also shows some overlaps with RomaingTiger and previous PlugX campaigns, but this could just be due to infrastructure reuse under the Chinese-speaking umbrella.
Activity of well-known groups

Some of the most heavily tracked groups, especially those that are Russian-speaking, didn´t show any remarkable activity during the last three months, as far as we know.

We observed limited activity from Sofacy in distributing Gamefish, updating its Zebrocy toolset and potentially registering new domains that might be used for future campaigns. We also saw the group slowly shift its targeting to Asia during the last months.

In the case of Turla (Snake, Uroburos), the group was suspected of breaching the German Governmental networks, according to some reports. The breach was originally reported as Sofacy, but since then no additional technical details or official confirmation have been provided.

The apparent low activity of these groups – and some others such as The Dukes – could be related to some kind of internal reorganization, however this is purely speculative.

Asia – high activity

The ever-growing APT activity in this part of the World shouldn´t be a surprise, especially seeing as the Winter Olympic Games was hosted in South Korea in January 2018. More than 30% of our 27 reports during Q1 were focused on the region.

Probably one of the most interesting activities relates to Kimsuky, an actor with a North-Korean nexus interested in South Korean think tanks and political activities. The actor renewed its arsenal with a completely new framework designed for cyberespionage, which was used in a spear-phishing campaign against South Korean targets, similar to the one targeting KHNP in 2014. According to McAfee, this activity was related to attacks against companies involved in the organization of the Pyeongchang Olympic Games, however we cannot confirm this.

The Korean focus continues with our analysis of the Flash Player 0-day vulnerability (CVE-2018-4878), deployed by Scarcruft at the end of January and triggered by Microsoft Word documents distributed through at least one website. This vulnerability was quickly reported by the Korean CERT (KN-CERT), which we believe helped to quickly mitigate any aggressive spreading. At the time of our analysis, we could only detect one victim in South Africa.

Forgotten PDB path inside the malware used by Scarcruft with CVE-2018-4876

Furthermore, IronHusky is a Chinese-speaking actor that we first detected in summer 2017. It is very focused on tracking the geopolitical agenda of targets in central Asia with a special focus in Mongolia, which seems to be an unusual target. This actor crafts campaigns for upcoming events of interest. In this case, they prepared and launched one right before a meeting with the International Monetary Fund and the Mongolian government at the end of January 2018. At the same time, they stopped their previous operations targeting Russian military contractors, which speaks volumes about the group’s limitations. In this new campaign, they exploited CVE-2017-11882 to spread common RATs typically used by Chinese-speaking groups, such as PlugX and PoisonIvy.

The final remark for this section covers the apparently never-ending greed of BlueNoroff, which has been moving to new targets among cryptocurrencies companies and expanding its operations to target PoS’s. However, we haven´t observed any new remarkable changes in the modus operandi of the group.

Middle East – always under pressure

There was a remarkable peak in StrongPity’s activity at the beginning of the year, both in January and March. For this new wave of attacks, the group used a new version of its malware that we simply call StrongPity2. However, the most remarkable aspect is the use of MiTM techniques at the ISP level to spread the malware, redirecting legitimate downloads to their artifacts. The group combines this method with registering domains that are similar to the ones used for downloading legitimate software.

StrongPity also distributed FinFisher using the same MiTM method at the ISP level, more details of which were provided by CitizenLab.

Desert Falcons showed a peak of activity at the end of 2017 and the beginning of 2018. Their toolset for this new campaign included Android implants that they had previously used back in 2014. The group continues to heavily rely on social engineering methods for malware distribution, and use rudimentary artifacts for infecting their victims. In this new wave we observed high-profile victims based mostly in Palestine, Egypt, Jordan, Israel, Lebanon and Turkey.

A particularly interesting case we analyzed was the evolution of what we believe to be the Gaza Team actor. What makes us question whether this is the same actor that we have tracked in the past, is the fact that we observed a remarkable boost in the artifacts used by the group. We actually can´t be sure whether the group suddenly developed these new technical capabilities, or if they had some internal reorganization or acquired improved tools. Another possibility is that the group itself was somehow hacked and a third actor is now distributing their artifacts through them.

Final Thoughts

As a summary of what happened during the last 3 months, we have the impression that some well-known actors are rethinking their strategies and reorganizing their teams for future attacks. In addition, a whole new wave of attackers are becoming much more active. For all these new attackers we observe different levels of sophistication, but let´s admit that the entry barrier for cyberespionage is much lower than it used to be in terms of the availability of different tools that can be used for malicious activities. Powershell, for instance, is one of the most common resources used by any of them. In other cases, there seems to be a flourishing industry of malware development behind the authorship of the tools that have been used in several campaigns.

Some of the big stories like Olympic Destroyer teach us what kind of difficulties we will likely find in the future in terms of attribution, while also illustrating how effective supply chain attacks still are. Speaking of new infection vectors, some of the CPU vulnerabilities discovered in the last few months will open new possibilities for attackers; unfortunately there is not an easy, universal protection mechanism for all of them. Routing hardware is already an infection vector for some actors, which should make us think whether we are following all the best practices in protecting such devices.

We will continue to track all the APT activity we can find and will regularly highlight the more interesting findings, but if you want to know more please reach out to us at

Operation Parliament, who is doing what?

Malware Alerts - Thu, 04/12/2018 - 03:00


Kaspersky Lab has been tracking a series of attacks utilizing unknown malware since early 2017. The attacks appear to be geopolitically motivated and target high profile organizations. The objective of the attacks is clearly espionage – they involve gaining access to top legislative, executive and judicial bodies around the world.

  1. The attackers have targeted a large number of organizations globally since early 2017, with the main focus on the Middle East and North Africa (MENA), especially Palestine. High-profile organizations have also been targeted in other regions. The number of attacks has decreased since the beginning of 2018.
  2. The attacks were initially discovered while investigating a phishing attack that targeted political figures in the MENA region. At first the attacks looked to be the work of the low-sophistication Gaza Cybergang (decoys, file names), but further analysis painted a very different picture.
  3. Targets include high-profile entities such as parliaments, senates, top state offices and officials, political science scholars, military and intelligence agencies, ministries, media outlets, research centers, election commissions, Olympic organizations, large trading companies, and other unknown entities.
  4. The malware basically provides a remote CMD/PowerShell terminal for the attackers, enabling them to execute any scripts/commands and receive the result via HTTP requests.
  5. Kaspersky Lab users and Threat Management and Defense clients are protected from the attacks.

Cisco Talos recently published a blogpost describing targeted attacks in the Middle East region which we believe may be connected.

Victimology and Statistics

Based on our findings, we believe the attackers represent a previously unknown geopolitically motivated threat actor. The campaign started in 2017, with the attackers doing just enough to achieve their goals. They most likely have access to additional tools when needed and appear to have access to an elaborate database of contacts in sensitive organizations and personnel worldwide, especially of vulnerable and non-trained staff. The victim systems range from personal desktop or laptop systems to large servers with domain controller roles or similar. The nature of the targeted ministries varied, including those responsible for telecommunications, health, energy, justice, finance and so on.

Victims have been spotted in the Palestinian Territories, Egypt, Jordan, the UAE, Saudi Arabia, Djibouti, Qatar, Lebanon, Chile, Somalia, Iraq, Morocco, Syria, India, Iran, Canada, the USA, the UK, Germany, Israel, Afghanistan, Serbia, Russia, Oman, Kuwait, South Korea and Denmark.

Victim organization type Number of victim organizations Unknown 91 Senates/Parliaments 7 Prime Ministerial Offices 3 Military/Intelligence Agencies 5 Other Gov./Ministerial/Diplomatic Offices 20 Financial/Banking Institutions 5 Media Outlets 2 Olympic/Sports Bodies 2 Research Centers/Scholars 2 Election Commissions 1 Distribution/Logistics 1

The number of victims/victim organizations probably doesn’t represent the full scope of the attacks – only a portion.

Attack description and attribution

Operation Parliament appears to be another symptom of escalating tensions in the Middle East region. The attackers have taken great care to stay under the radar, imitating another attack group in the region. They have been particularly careful to verify victim devices before proceeding with the infection, safeguarding their command and control servers. The targeting seems to have slowed down since the beginning of 2018, probably winding down when the desired data or access was obtained. The targeting of specific victims is unlike previously seen behavior in regional campaigns by Gaza Cybergang or Desert Falcons and points to an elaborate information-gathering exercise that was carried out before the attacks (physical and/or digital).

With deception and false flags increasingly being employed by threat actors, attribution is a hard and complicated task that requires solid evidence, especially in complex regions such as the Middle East.

See the following for more information and examples of false flags being used in cyberattacks:

Wave your false flags! …or the Nightmares and Nuances of a Self-Aware Attribution Space

OlympicDestroyer is here to trick the industry

Malware description

The malware was first seen packed with VMProtect; when unpacked the sample didn’t show any similarities with previously known malware. All the strings and settings were encrypted and obfuscated. Functionality was identified that enables HTTP communication with the C&C server and invokes “processcreate” based on parameters received as a response.

The configuration and strings are encrypted using 3DES and Base64 encoding. Data sent to the C&C server is also encrypted using 3DES and Base64. Different keys are used for local and network encryption.

The malware starts communicating with the C&C server by sending basic information about the infected machine. The C&C server then replies with the encrypted serialized configuration.

The malware basically provides a remote CMD/PowerShell terminal for the attackers, enabling them to execute scripts/commands and receive the results via HTTP requests.

Sample of the C&C response with encrypted commands and configurations

Examples of attack decoys

Translation: Contacts list of media personnel

Translation: Relations between UAE and Jordan, and the impact caused by the non-boycott of Qatar

Translation: Military retirement statement 2017 June

Translation: The new Hamas structure for Gaza strip 2017

Translation: Clarification report (on Gaza employee salaries)

What should high-profile organizations do?

High-profile organizations should have elevated levels of cybersecurity. Attacks against them are inevitable and are unlikely to ever cease. These organizations need to pay particular attention to their security, implementing additional measures to ensure they are well protected. Anti-targeted attack solutions, threat intelligence capabilities and data flows, default-deny application lockdown, endpoint detection and response, data leak and insider threat prevention, and even isolated/air-gapped networks should form the basis of any strategy for protecting organizations in the current threat landscape.

The victims of Operation Parliament need to re-evaluate their approach to cybersecurity.

Additional information

For more information about the attacks and the indicators of compromise, please contact:

Alternatively, please visit:

To find more information about cybersecurity awareness training for enterprise or government staff, go to Kaspersky Security Awareness.

Don't Trust Links Sent in Email Messages

SANS Tip of the Day - Tue, 04/10/2018 - 01:00
A common method cyber criminals use to hack into people's computers is to send them emails with malicious links. People are tricked into opening these links because they appear to come from someone or something they know and trust. If you click on a link, you may be taken to a site that attempts to harvest your information or tries to hack into your computer. Only click on links that you were expecting. Not sure about an email? Call the person to confirm they sent it.

Pocket cryptofarms

Malware Alerts - Wed, 04/04/2018 - 06:00

In recent months, the topic of cryptocurrency has been a permanent news fixture — the value of digital money has been see-sawing spectacularly. Such pyrotechnics could hardly have escaped the attention of scammers, which is why cryptocurrency fluctuations have gone hand in hand with all kinds of stories. These include hacked exchanges, Bitcoin and Monero ransoms, and, of course, hidden mining. We’ve noticed that attackers no longer limit themselves to servers, desktops, and laptops. They are increasingly drawn to mobile devices, mainly Android. We decided to take a closer look to see which mobile apps stealthily mine digital coins on user devices and how widespread they are.

Primitive counterfeit apps

We found several types of malware posing as popular programs and games, but actually just showing ads and secretly mining cryptocurrencies using the CoinHive SDK. In particular, we unearthed counterfeit versions of Instagram, Netflix, Bitmoji, and others. The scammers had added the word “hack” to the original app names. These “hacked” apps were distributed through forums and third-party stores. Kaspersky Lab products detect such programs as RiskTool.AndroidOS.Miner.

Fragment of RiskTool.AndroidOS.Miner.a code that runs a hidden miner and displays an advertising page

Advertising page that RiskTool.AndroidOS.Miner.a shows to the user

Primitive miners based on web frameworks

There are a number of web frameworks that make it easy to create mobile apps, including miners. At the heart of such apps there lies a web page containing a JS script for mining cryptocurrency (for example, the CoinHive script). Most of the miners we found of this type were based on the Thunkable and Cordova frameworks. These apps are most commonly distributed through third-party sites, although one of them was found in the official Google Play store, where it was removed after we reported it.

Screenshot of a game in the Google Play store that mined cryptocurrency

We also found one app built on a different framework, Andromo. It looks like a discount aggregator at first glance, but instead of linking to sites with discounted products, it loads a page that mines cryptocurrency and doesn’t even try to hide it:

One more app caught our eye — Crypto Mining for Children. Based on the B4A framework, it was found in the official Google store (at the time of writing this article it had been deleted). Its stated goal was to mine cryptocurrency for charity. But the description contained no word about where or how the coins would be spent — something that any bona fide fundraising organization would publish. What’s more, the name of the developer bore a striking resemblance to that of a well-known mobile app (a cryptocurrency wallet), but with one letter missing. That’s a common trick used by phishers.

Useful apps infected with miners

This category is made of programs that Kaspersky Lab products detect as Trojan.AndroidOS.Coinge; they are popular apps in which cybercriminals have added malicious code for mining cryptocurrency.

Infected version of the TSF Launcher app

Interestingly, the cybercriminals added the malicious code to the code of other SDKs used by the app. That way, the app runs a library that does the mining. Not only that, we managed to detect a modification of this Trojan that does away with the need for a library: the malware adds its code to all web pages it opens. It’s worth noting that both methods of infection are similar to those used by Trojan-PSW.AndroidOS.MyVk to steal passwords.

A modification of Trojan.AndroidOS.Coinge adds mining code to all opened web pages

We managed to detect 23 different apps infected by Trojan.AndroidOS.Coinge.

Miners in apps for watching soccer

According to Kaspersky Security Network, the most common mining apps among those we found were connected to the topic of soccer. The name PlacarTV (placar means “account” in Portuguese) or something similar cropped up frequently. The main function of such apps was to show soccer videos while secretly mining cryptocurrency.

The PlacarTV app uses CoinHive for mining

The PlacarTV app interface

Our data shows that some of these apps were distributed through Google Play, with the most popular having been installed more than 100,000 times.

A modification of the PlacarTV app that was distributed through Google Play

The apps access the server. This same domain is used in the developer’s email address specified in the Google Play store. Unbeknown to visitors, the site runs a script that mines cryptocurrency.

Code of the page used to mine cryptocurrency

Mobile clickers

Members of the Trojan.Clicker malware family typically open web pages and click them without the user noticing. Such pages can contain both adverts and subscriptions to WAP services. But having started to make easy money from unsuspecting users, the creators seemingly got greedy. And it wasn’t long before cryptocurrency mining was added to the feature set of some clickers. We already analyzed a similar case when a miner was caught lurking in the modules of the Loapi Trojan.

Another Trojan-turned-miner is Ubsob. This malware poses as a suite of useful apps. When started, it downloads and installs an app that it uses to mask itself. Its creators broadened their horizons by adding code borrowed from the app NeoNeonMiner for cryptomining.

Installation of the original app initialized by the Ubsob Trojan

Furthermore, the Trojan requests device administrator rights to establish a foothold in the system. This means that to delete it, it must first be removed from the list of device administrators. During the process, the malware displays a scary message – “These action can lead to data lost. Are you really wont to erase all your data?”

Message displayed by the Ubsob Trojan when attempting to deprive it of administrator rights

The Trojan mainly “resides” in CIS countries, above all Russia.

Other interesting finds Fire-prevention miner

Probably the most interesting Trojan we analyzed is Trojan.AndroidOS.Coinge.j. It has no legitimate app functions at all and installs itself either as a porn app or as an Android system app. As soon as it starts, the malware requests device administrator rights to prevent its removal.

Trojan.AndroidOS.Coinge.j requests device administrator rights

The Trojan uses several layers of encryption and obfuscation to protect its code from analysis, but that’s not the only string to its bow. The malware monitors the device battery and temperature to mine cryptocurrency without posing a fire hazard. It seems the cybercriminals have no desire to repeat the “success” of Loapi, which incinerated our test phone.

Almost a third (29%) of the Trojan’s victims were in India. It is also active in the United States (8%), Britain (6%), Iran (5%), and Ukraine (5%). Like Ubsod, it uses the code of a legitimate app to mine cryptocurrencies.

VPN with undocumented features

We found another battery and temperature-monitoring miner in Google Play under the guise of the VPN app for establishing a VPN connection. By the time of detection, it had been installed more than 50,000 times. We reported it to Google.

Code of the VPN app

Information about the VPN app on Google Play


Keep in mind that mobile mining has a number of limitations:

  • First, mobile devices trail a long way behind desktop systems performance-wise, let alone dedicated mining farms, which eats into the profitability of cryptocurrency mining on mobile devices.
  • Second, heavy use of mobile devices causes them to heat up noticeably, alerting the user.
  • Lastly, smartphones’ relatively small battery power means they discharge quickly if used intensively, making mining more visible to the user and time-limited.

However, our study showed that cybercriminals are not put off by these limitations. We uncovered numerous mobile miners built on various frameworks and distributed in various ways, including through the official Google Play store. Perhaps cybercriminals are banking on compensating for smartphones’ poor performance and mobile miners’ easy detection through the sheer number of handheld devices out there and their high infectibility.



Your new friend, KLara

Malware Alerts - Wed, 03/28/2018 - 06:00

While doing threat research, teams need a lot of tools and systems to aid their hunting efforts – from systems storing Passive DNS data and automated malware classification to systems allowing researchers to pattern-match a large volume of data in a relatively short period of time. These tools are extremely useful when working on APT campaigns where research is very agile and spans multiple months. One of the most frequently used tools for hunting new variants of malware is called YARA and was developed by Victor Manuel Alvarez while working for VirusTotal, now part of Alphabet.

In R&D we use a lot of open-source projects and we believe giving back to the community is our way of saying ‘Thank you’. More and more security companies are releasing their open-source projects and we would like to contribute with our distributed YARA scanner.

What is YARA?

YARA is defined as “a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples”. In other words, it is a pattern-matching tool, but on steroids. It can support complex matching rules as well as searching files with specific metadata (for example, it can search all files that use a certificate containing the string “Microsoft Corporation” but is not signed by “Microsoft”).

How can YARA help you find the next APT in your network?

YARA’s usefulness is amazing, especially given traditional protection measures are no longer enough in today’s complex threat landscape. Modern protection systems, combined with constant network monitoring and incident response have to be deployed in order to successfully protect equipment.

Protective measures that were effective yesterday don’t guarantee the same level of security tomorrow. Indicators of compromise (IoCs) can help you search for footprints of known malware or for an active infection. But serious threat actors have started to tailor their tools to fit each victim, thus making IoCs much less effective. Good YARA detection rules still allow analysts to find malware, exploits and 0-days which couldn’t be found any other way. The rules can be deployed in networks and on various multi-scanner systems.

That’s why, as part of our Threat Intelligence services, we offer a range of training courses, one of them being our world-famous YARA Training, held by our GReAT ninjas: Costin Raiu, Vitaly Kamluk and Sergey Mineev.

Finding exploits in the wild

One of the most remarkable cases in which Kaspersky Lab’s GReAT used YARA was the much publicized Silverlight 0-day. The team started hunting for it after Hacking Team, the Italian company selling “legal surveillance tools” for governments and LEAs, was hacked. One of the stories in the media attracted our researchers’ attention — according to the article, a programmer offered to sell Hacking Team a Silverlight 0-day, an exploit for an obsolete Microsoft plug-in which at one time had been installed on a huge number of computers.

GReAT decided to create a YARA rule based on this programmer’s older, publicly available proof-of-concept exploits. Our researchers found that he had a very particular style when coding the exploits, using very specific comments, shell code and function names. All of this unique information was used to write a YARA rule — the experts set it to carry out a clear task, basically saying “Go and hunt for any piece of malware that shows the characteristics described in the rule”. Eventually it caught a new sample, a 0-day, and the team immediately reported it to Microsoft.

KLara, GReAT’s distributed YARA scanner

As mentioned above, any team carrying out threat intelligence needs to have powerful tools in their arsenal in order to find the latest threats and detect attacks as soon as possible. Within our R&D department we have built a lot of tools internally, but we believe most progress is made when useful tools are shared with the community. As such, we are releasing our internal tool for running YARA rules over a large set of data (malware/virus collections).

What is KLara?

In order to hunt efficiently for malware, you need a large collection of samples to search through. Researchers usually need to fire a YARA rule over a collection/set of malicious files and then get the results back. In some cases, the rule needs adjusting. Unfortunately, scanning a large collection of files takes time. However, if a custom architecture is used instead, scanning 10TB of files can take around 30 minutes. Of course, if there are multiple YARA rules that need to be run simultaneously, it’s important the system is also distributed. And this is where KLara comes in. KLara is a distributed system written in Python, allowing researchers to scan one or more YARA rules over collections with samples, getting notifications by email and in the web interface when the scan results are ready. Systems like KLara are important when large collections of data are involved. Of course, researchers will have their own small virus collections on their computers in order to make sure their YARA rules are sound, but when searching for viruses in the wild, this task requires a lot of processing power and this can only be achieved with a cloud system.

Why is it important to have a distributed YARA scanner?

Attacks using APTs are extremely dangerous, regardless of whether the target belongs to the public, private or government sector. From our experience, constant monitoring of logs, netflow, alerts and any suspicious files helps mitigate an attack during reconnaissance stages. There are some projects similar to KLara that SOC teams can leverage, but most of them are private, meaning either the virus collection or rules exist somewhere in the cloud, outside the team’s direct control.

KLara, on the other hand, allows anyone running any kind of hardware to set up their own private YARA scanner, keeping TLP RED YARA rules local.

KLara under the hood

The project uses the dispatcher/worker model, with the usual architecture of one dispatcher and multiple workers. Worker and dispatcher agents are written in Python. Because the worker agents are written in Python, they can be deployed in any compatible ecosystem (Windows or UNIX). The same logic applies to the YARA scanner (used by KLara): it can be compiled on both platforms.

Jobs can be submitted and their status retrieved using a web-based portal, while each user has their own personal account allowing them to be part of a group, as well as share their KLara jobs with any other valid account.

Accounts have multiple properties that can be set by the administrator: what group they are part of, what scan repositories they can run their YARA rules over (based on group membership), if they can see other groups’ jobs, or the maximum number of jobs that can be submitted monthly (individual quotas).

By using the dashboard, authenticated users can submit jobs on the ‘Add a new job’ page:

And check their status on the ‘Current jobs’ page:

Once a user submits a task, they can view its status, resubmit it or delete it. One of the workers will fetch the job from the dispatcher and if it has eligible scan repositories on its file systems, will start the YARA scan. Once finished, the user is notified by email of the results.

Each job’s metadata consists of one or multiple YARA rules, the submitter’s account info and a set of scan repositories that can be selected:

On the main page, a summary is displayed:

  • Job status: New/Assigned/Finished/Error
  • Job management: Restart/Delete job
  • How many files have been matched
  • Name of the first rule in the rules set
  • The repository path over which YARA scanned for matches.

A more detailed status can be seen once we click on a job:

Any YARA results will be displayed at the bottom, as well as a list of matched MD5s.

Each user can have a search quota and be part of a group. Groups can choose to restrict users (preventing them from seeing what other jobs group members submit).

Finally, each user can change their email address if they want notifications to be sent to another email account.

API access

In order to facilitate automatic job submissions as well as automatic results retrieval, KLara implements a simple REST API allowing any valid account with a valid API Key to query any allowed job’s status. It allows scripts to:

  • Submit new tasks
  • Get the job results as well as job details (if it’s still scanning or assigned, finished or if there’s an unprocessed (new) job)
  • Get all the YARA results from a specific job.
  • Get all the matched MD5 hashes

More info about using the API can be found in the repository.

How can you get KLara?

The software was released on our official Kaspersky Lab GitHub account on 9 March, 2018.

We welcome anyone who wants to contribute to this project to submit pull requests. As we said before, we believe in giving back to the community the best tools we can provide in order to fight malware.

The software is open-sourced under GNU General Public License v3.0 and available with no warranty from the developers.