Malware RSS Feed

OPC UA security analysis

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

This paper discusses our project that involved searching for vulnerabilities in implementations of the OPC UA protocol. In publishing this material, we hope to draw the attention of vendors that develop software for industrial automation systems and the industrial internet of things to problems associated with using such widely available technologies, which turned out to be quite common. We hope that this article will help software vendors achieve a higher level of protection from modern cyberattacks. We also discuss some of our techniques and findings that may help software vendors control the quality of their products and could prove useful for other software security researchers.

Why we chose the OPC UA protocol for our research

The IEC 62541 OPC UA (Object Linking and Embedding for Process Control Unified Automation) standard was developed in 2006 by the OPC Foundation consortium for reliable and, which is important, secure transfer of data between various systems on an industrial network. The standard is an improved version of its predecessor – the OPC protocol, which is ubiquitous in modern industrial environments.

It is common for monitoring and control systems based on different vendors’ products to use mutually incompatible, often proprietary network communication protocols. OPC gateways/servers serve as interfaces between different industrial control systems and telemetry, monitoring and telecontrol systems, unifying control processes at industrial enterprises.

The previous version of the protocol was based on the Microsoft DCOM technology and had some significant limitations inherent to that technology. To get away from the limitations of the DCOM technology and address some other issues identified while using OPC, the OPC Foundation developed and released a new version of the protocol.

Thanks to its new properties and well-designed architecture, the OPC UA protocol is rapidly gaining popularity among automation system vendors. OPC UA gateways are installed by a growing number of industrial enterprises across the globe. The protocol is increasingly used to set up communication between components of industrial internet of things and smart city systems.

The security of technologies that are used by many automation system developers and have the potential to become ubiquitous among industrial facilities across the globe is one the highest-priority areas of research for Kaspersky Lab ICS CERT. This was our main reason to do an analysis of OPC UA.

Another reason was that Kaspersky Lab is a member of the OPC Foundation consortium and we feel responsible for the security of technologies developed by the consortium. Getting ahead of the story, we can say that, following the results of our research, we received an invitation to join the OPC Foundation Security Working Group and gratefully accepted it.

OPC UA protocol

Originally, OPC UA was designed to support data transport for two data types: the traditional binary format (used in previous versions of the standard) and SOAP/XML. Today, data transfer in the SOAP/XML format is considered obsolete in the IT world and is almost never used in modern products and services. The prospects of it being widely used in industrial automation systems are obscure, so we decided to focus our research on the binary format.

If packets exchanged by services running on the host are intercepted, their structure can easily be understood. There are four types of messages transmitted over the OPC UA protocol:

  • HELLO
  • OPEN
  • MESSAGE
  • CLOSE

The first message is always HELLO (HEL). It serves as a marker for the start of data transfer between the client and the server. The server responds by sending the ACKNOWLEDGE (ACK) message to the client. After the initial exchange of messages, the client usually sends the message OPEN, which means that the data transmission channel using the encryption method proposed by the client is now open. The server responds by sending the message OPEN (OPN), which includes the unique ID of the data channel and shows that the server agrees to the proposed encryption method (or no encryption).

Now the client and the server can start exchanging messages –MESSAGE (MSG). Each message includes the data channel ID, the request or response type, a timestamp, data arrays being sent, etc. At the end of the session, the message CLOSE (CLO) is sent, after which the connection is terminated.

Source: https://readthedocs.web.cern.ch/download/attachments/21178021/OPC-UA-Secure-Channel.JPG?version=1&modificationDate=1286181543000&api=v2

OPC UA is a standard that has numerous implementations. In our research, we only looked at the specific implementation of the protocol developed by the OPC Foundation.

The initial stage

We first became interested in analyzing the OPC UA protocol when the Kaspersky Lab ICS CERT team was conducting security audits and penetration tests at several industrial enterprises. All of these enterprises used the same industrial control system (ICS) software. With the approval of the customers, we analyzed the software for vulnerabilities as part of the testing.

It turned out that part of the network services in the system we analyzed communicated over the OPC UA protocol and most executable files used a library named “uastack.dll”.

The first thing we decided to do as part of analyzing the security of the protocol’s implementation was to develop a basic “dumb” mutation-based fuzzer.

“Dumb” fuzzing, in spite of being called “dumb”, can be very useful and can in some cases significantly improve the chances of finding vulnerabilities. Developing a “smart” fuzzer for a specific program based on its logic and algorithms is time-consuming. At the same time, a “dumb” fuzzer helps quickly identify trivial vulnerabilities that can be hard to get at in the process of manual analysis, particularly when the amount of code to be analyzed is large, as was the case in our project.

The architecture of the OPC UA Stack makes in-memory fuzzing difficult. For the functions that we want to check for vulnerabilities to work correctly, the fuzzing process must involve passing properly formed arguments to the function and initializing global variables, which are structures with a large number of fields. We decided not to fuzz-test functions directly in memory. The fuzzer that we wrote communicated with the application being analyzed over the network.

The fuzzer’s algorithm had the following structure:

  • read input data sequences
  • perform a pseudorandom transformation on them
  • send the resulting sequences to the program over the network as inputs
  • receive the server’s response
  • repeat

After developing a basic set of mutations (bitflip, byteflip, arithmetic mutations, inserting a magic number, resetting the data sequence, using a long data sequence), we managed to identify the first vulnerability in uastack.dll. It was a heap corruption vulnerability, successful exploitation of which could enable an attacker to perform remote code execution (RCE), in this case, with NT AUTHORITY/SYSTEM privileges. The vulnerability we identified was caused by the function that handled the data which had just been read from a socket incorrectly calculating the size of the data, which was subsequently copied to a buffer created on a heap.

Upon close inspection, it was determined that the vulnerable version of the uastack.dll library had been compiled by the product’s developers. Apparently, the vulnerability was introduced into the code in the process of modifying it. We were not able to find that vulnerability in the OPC Foundation’s version of the library.

The second vulnerability was found in a .NET application that used the UA .NET Stack. While analyzing the application’s traffic in wireshark, we noticed in the dissector that some packets had an is_xml bit field, the value of which was 0. In the process of analyzing the application, we found that it used the XmlDocument function, which was vulnerable to XXE attacks for .NET versions 4.5 and earlier. This means that if we changed the is_xml bit field’s value from 0 to 1 and added a specially crafted XML packet to the request body (XXE attack), we would be able to read any file on the remote machine (out-of-bound file read) with NT AUTHORITY/SYSTEM privileges and, under certain conditions, to perform remote code execution (RCE), as well.

Judging by the metadata, although the application was part of the software package on the ICS that we were analyzing, it was developed by the OPC Foundation consortium, not the vendor, and was an ordinary discovery server. This means that other products that use the OPC UA technology by the OPC Foundation may include that server, making them vulnerable to the XXE attack. This makes this vulnerability much more valuable from an attacker’s viewpoint.

This was the first step in our research. Based on the results of that step, we decided to continue analyzing the OPC UA implementation by the OPC Foundation consortium, as well as products that use it.

OPC UA analysis

To identify vulnerabilities in the implementation of the OPC UA protocol by the OPC Foundation consortium, research must cover:

  • The OPC UA Stack (ANSI C, .NET, JAVA);
  • OPC Foundation applications that use the OPC UA Stack (such as the OPC UA .NET Discovery Server mentioned above);
  • Applications by other software developers that use the OPC UA Stack.

As part of our research, we set ourselves the task to find optimal methods of searching for vulnerabilities in all three categories.

Fuzzing the UA ANSI C Stack

Here, it should be mentioned that there is a problem with searching for vulnerabilities in the OPC UA Stack. OPC Foundation developers provide libraries that are essentially a set of exported functions based on a specification, similar to an API. In such cases, it is often hard to determine whether a potential security problem that has been discovered is in fact a vulnerability. To give a conclusive answer to that question, one must understand how the potentially vulnerable function is used and for what purpose – i.e., a sample program that uses the library is necessary. In our case, it was hard to make conclusions on vulnerabilities in the OPC UA Stack without looking at applications in which it was implemented.

What helped us resolve this problem associated with searching for vulnerabilities was open-source code hosted in the OPC Foundation’s repository on GitHub, which includes a sample server that uses the UA ANSI C Stack. We don’t often get access to product source code in the course of analyzing ICS components. Most ICS applications are commercial products, developed mostly for Windows and released with a licensing agreement the terms of which do not include access to the source code. In our case, the availability of the source code helped find errors both in the server itself and in the library. The UA ANSI C Stack source code was helpful for doing manual analysis of the code and for fuzzing. It also helped us find out whether new functionality had been added to a specific implementation of the UA ANSI C Stack.

The UA ANSI C Stack (like virtually all other products by the OPC Foundation consortium) is positioned as a solution that is not only secure, but is also cross-platform. This helped us our during fuzzing, because we were able to build a UA ANSI С Stack together with the sample server code published by the developers in their GitHub account, on a Linux system with binary source code instrumentation and to fuzz-test that code using AFL.

To accelerate fuzzing, we overloaded the networking functions –socket/sendto/recvfrom/accept/bind/select/… – to read input data from a local file instead of connecting to the network. We also compiled our program with AddressSanitizer.

To put together an initial set of examples, we used the same technique as for our first “dumb” fuzzer, i.e., capturing traffic from an arbitrary client to the application using tcpdump. We also added some improvements to our fuzzer – a dictionary created specifically for OPC UA and special mutations.

It follows from the specification of the binary data transmission format in OPC UA that it is sufficiently difficult for AFL to mutate from, say, the binary representation of an empty string in OPC UA (“\xff\xff\xff\xff”) to a string that contains 4 random bytes (for example, “\x04\x00\x00\x00AAAA”). Because of this, we implemented our own mutation mechanism, which worked with OPC UA internal structures, changing them based on their types.

After building our fuzzer with all the improvements included, we got the first crash of the program within a few minutes.

An analysis of memory dumps created at the time of the crash enabled us to identify a vulnerability in the UA ANSI C Stack which, if exploited, could result at least in a DoS condition.

Fuzzing OPC Foundation applications

Since, in the previous stage, we had performed fuzzing of the UA ANSI C Stack and a sample application by the OPC Foundation, we wanted to avoid retesting the OPC UA Stack in the process of analyzing the consortium’s existing products, focusing instead on fuzzing specific components written on top of the stack. This required knowledge of the OPC UA architecture and the differences between applications that use the OPC UA Stack.

The two main functions in any application that uses the OPC UA Stack are OpcUa_Endpoint_Create and OpcUa_Endpoint_Open. The former provides the application with information on available channels of data communication between the server and the client and a list of available services. The OpcUa_Endpoint_Open function defines from which network the service will be available and which encryption modes it will provide.

A list of available services is defined using a service table, which lists data structures and provides information about each individual service. Each of these structures includes data on the request type supported, the response type, as well as two callback functions that will be called during request preprocessing and post-processing (preprocessing functions are, in most cases, “stubs”). We included converter code into the request preprocessing function. It uses mutated data as an input, outputting a correctly formed structure that matches the request type. This enabled us to skip the application startup stage, starting an event loop to create a separate thread to read from our pseudo socket, etc. This enabled us to accelerate our fuzzing from 50 exec/s to 2000 exec/s.

As a result of using our “dumb” fuzzer improved in this way, we identified 8 more vulnerabilities in OPC Foundation applications.

Analyzing third-party applications that use the OPC UA Stack

Having completed the OPC Foundation product analysis stage, we moved on to analyzing commercial products that use the OPC UA Stack. From the ICS systems we worked with during penetration testing and analyzing the security status of facilities for some of our customers, we selected several products by different vendors, including solutions by global leaders of the industry. After getting our customers’ approval, we began to analyze implementations of the OPC UA protocol in these products.

When searching for binary vulnerabilities, fuzzing is one of the most effective techniques. In previous cases, when analyzing products on a Linux system, we used source code binary instrumentation techniques and the AFL fuzzer. However, the commercial products using the OPC UA Stack that we analyzed are designed to run on Windows, for which there is an equivalent of the AFL fuzzer called WinAFL. Essentially, WinAFL is the AFL fuzzer ported to Windows. However, due to differences between the operating systems, the two fuzzers are different in some significant ways. Instead of system calls from the Linux kernel, WinAFL uses WinAPI functions and instead of static source code instrumentation, it uses the DynamoRIO dynamic instrumentation of binary files. Overall, these differences mean that the performance of WinAFL is significantly lower than that of AFL.

To work with WinAFL in the standard way, one has to write a program that will read data from a specially created file and call a function from an executable file or library. Then WinAFL will put the process into a loop using binary instrumentation and will call the function many times, getting feedback from the running program and relaunching the function with mutated data as arguments. That way, the program will not have to be relaunched every time with new input data, which is good, because creating a new process in Windows consumes significant processor time.

Unfortunately, this method of fuzzing couldn’t be used in our situation. Owing to the asynchronous architecture of the OPC UA Stack, the processing of data received and sent over the network is implemented as call-back functions. Consequently, it is impossible to identify a data-processing function for each type of request that would accept a pointer to the buffer containing the data and the size of the data as arguments, as required by the WinAFL fuzzer.

In the source code of the WinAFL fuzzer, we found comments on fuzzing networking applications left by the developer. We followed the developer’s recommendations on implementing network fuzzing with some modifications. Specifically, we included the functionality of communication with the local networking application in the code of the fuzzer. As a result of this, instead of executing a program, the fuzzer sends payload over the network to an application that is already running under DynamoRIO.

However, with all our efforts, we were only able to achieve the fuzzing rate of 5 exec/s. This is so slow that it would take too long to find a vulnerability even with a smart fuzzer like AFL.

Consequently, we decided to go back to our “dumb” fuzzer and improve it.

  1. We improved the mutation mechanism, modifying the data generation algorithm based on our knowledge of the types of data transferred to the OPC UA Stack.
  2. We created a set of examples for each service supported (the python-opcua library, which includes functions for interacting with virtually all possible OPC UA services, proved very helpful in this respect).
  3. When using a fuzzer with dynamic binary instrumentation to test multithreaded applications such as ours, searching for new branches in the application’s code is a sufficiently complicated task, because it is difficult to determine which input data resulted in a certain behavior of the application. Since our fuzzer communicated to the application over the network and we could establish a clear connection between the server’s response and the data sent to it (because communication took place within the limits of one session), there was no need for us to address this issue. We implemented an algorithm which determined that a new execution path has been identified simply when a new response that had not been observed before was received from the server.

As a result of the improvements described above, our “dumb” fuzzer was no longer all that “dumb”, and the number of executions per second grew from 1 or 2 to 70, which is a good figure for network fuzzing. With its help, we identified two more new vulnerabilities that we had been unable to identify using “smart” fuzzing.

Results

As of the end of March 2018, the results of our research included 17 zero-day vulnerabilities in the OPC Foundation’s products that had been identified and closed, as well as several vulnerabilities in the commercial applications that use these products.

We immediately reported all the vulnerabilities identified to developers of the vulnerable software products.

Throughout our research, experts from the OPC Foundation and representatives of the development teams that had developed the commercial products promptly responded to the vulnerability information we sent to them and closed the vulnerabilities without delays.

In most cases, flaws in third-party software that uses the OPC UA Stack were caused by the developers not using functions from the API implemented in the OPC Foundation’s uastack.dll library properly – for example, field values in the data structures transferred were interpreted incorrectly.

We also determined that, in some cases, product vulnerabilities were caused by modifications made to the uastack.dll library by developers of commercial software. One example is an insecure implementation of functions designed to read data from a socket, which was found in a commercial product. Notably, the original implementation of the function by the OPC Foundation did not include this error. We do not know why the commercial software developer had to modify the data reading logic. However, it is obvious that the developer did not realize that the additional checks included in the OPC Foundation’s implementation are important because the security function is built on them.

In the process of analyzing commercial software, we also found out that developers had borrowed code from OPC UA Stack implementation examples, copying that code to their applications verbatim. Apparently, they assumed that the ОРС Foundation has made sure that these code fragments were secure in the same way that it had ensured the security of code used in the library. Unfortunately, that assumption turned out to be wrong.

Exploitation of some of the vulnerabilities that we identified results in DoS conditions and the ability to execute code remotely. It is important to remember that, in industrial systems, denial-of-service vulnerabilities pose a more serious threat than in any other software. Denial-of-service conditions in telemetry and telecontrol systems can cause enterprises to suffer financial losses and, in some cases, even lead to the disruption and shutdown of the industrial process. In theory, this could cause harm to expensive equipment and other physical damage.

Conclusion

The fact that the OPC Foundation is opening the source code of its projects certainly indicates that it is open and committed to making its products more secure.

At the same time, our analysis has demonstrated that the current implementation of the OPC UA Stack is not only vulnerable but also has a range of significant fundamental problems.

First, flaws introduced by developers of commercial software that uses the OPC UA Stack indicate that the OPC UA Stack was not designed for clarity. Unfortunately, an analysis of the source code confirms this. The current implementation of the protocol has plenty of pointer calculations, insecure data structures, magic constants, parameter validation code copied between functions and other archaic features scattered throughout the code. These are features that developers of modern software tend to eliminate from their code, largely to make their products more secure. At the same time, the code is not very well documented, which makes errors more likely to be introduced in the process of using or modifying it.

Second, OPC UA developers clearly underestimate the trust software vendors have for all code provided by the OPC Foundation consortium. In our view, leaving vulnerabilities in the code of API usage examples is completely wrong, even though API usage examples are not included in the list of products certified by the OPC Foundation.

Third, we believe that there are quality assurance issues even with products certified by the OPC Foundation.

It is likely that use fuzz testing techniques similar to those described in this paper are not part of the quality assurance procedures used by OPC UA developers – this is demonstrated by the statistics on the vulnerabilities that we have identified.

The open source code does not include code for unit tests or any other automatic tests, making it more difficult to test products that use the OPC UA Stack in cases when developers of these products modify their code.

All of the above leads us to the rather disappointing conclusion that, although OPC UA developers try to make their product secure, they nevertheless neglect to use modern secure coding practices and technologies.

Based on our assessment, the current OPC UA Stack implementation not only fails to protect developers from trivial errors but also tends to provoke errors –we have seen this in real-world examples. Given today’s threat landscape, this is unacceptable for products as widely used as OPC UA. And this is even less acceptable for products designed for industrial automation systems.

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.

Conclusion

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: intelreports@kaspersky.com

Detection

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
IOCs
  • 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
retn
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:

ENC: XOR

KDF: PBKDF2-SHA1 with one iteration

MAC: HMAC-SHA1

ECDH curve: standard NIST elliptic curve secp192r1

ECIES-XOR-HMAC-SHA1

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.
Initialization

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

Trojan-Ransom.Win32.Agent.abwa
Trojan-Ransom.Win32.Agent.abwb
PDM:Trojan.Win32.Generic

IoCs

0x6F772EB660BC05FC26DF86C98CA49ABC
0x911D5905CBE1DD462F171B7167CD15B9

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: intelreports@kaspersky.com.

 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

Conclusion

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

Country
(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, kashey.ru, and resources links to which were found on this site. These may have been links to resources developed by the site’s owner: www.esodedi.ru, www.i-stroy.ru, www.saledoor.ru

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 ftpChecker.py 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:

https://github.com/wso-shell/WSO

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

https://github.com/bediger4000/php-malware-analysis/tree/master/db-config.php

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:

https://github.com/jivoi/openssh-backdoor-kit

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 https://github.com/sqlmapproject/sqlmap.git

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.

Conclusion

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*

/usr/lib/libng/ftpChecker.py
/usr/bin/nmap/
/usr/lib/libng/dirsearch/
/usr/share/python2.7/dirsearch/
/usr/lib/libng/SMBTrap/
/usr/lib/libng/commix/
/usr/lib/libng/subbrute-master/
/usr/share/python2.7/sqlmap/
/usr/lib/libng/sqlmap-dev/
/usr/lib/libng/wpscan/
/usr/share/python2.7/wpscan/
/usr/share/python2.7/Sublist3r/

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

PHP files:

/usr/share/python2.7/sma.php
/usr/share/python2.7/theme.php
/root/theme.php
/usr/lib/libng/media.php

Logs

/var/tmp/.pipe.sock

PHP file hashes

f3e3e25a822012023c6e81b206711865
c76470e85b7f3da46539b40e5c552712
155385cc19e3092765bcfed034b82ccb
1644af9b6424e8f58f39c7fa5e76de51
2292f5db385068e161ae277531b2e114
7ec514bbdc6dd8f606f803d39af8883f
78c31eff38fdb72ea3b1800ea917940f

Yara rules

rule Backdoored_ssh {
strings:
$a1 = “OpenSSH”
$a2 = “usage: ssh”
$a3 = “HISTFILE”
condition:
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
workdir=428c5fcf495396df04a459e317b70ca2
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
workdir=428c5fcf495396df04a459e317b70ca2
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 https://t.co/ctdTBQCRNc

— 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 mopub.com

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

rayjump.com

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

tappas.net

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.

appsgeyser.com

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 appsgeyser.com

According to the appsgeyser.com 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 ushareit.com

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

Lenovo

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.

Nexage.com

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

Quantumgraph.com

Another SDK that is leaking data uses the quantumgraph.com 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

Malware

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.

Future

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’.

Distribution

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 www.securelist.com 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 127.0.0.1.

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 http://127.0.0.1:${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:

  • wooribank.pib.smart
  • kbstar.kbbank
  • ibk.neobanking
  • sc.danb.scbankapp
  • shinhan.sbanking
  • hanabank.ebk.channel.android.hananbank
  • smart
  • epost.psf.sdsi
  • kftc.kjbsmb
  • smg.spbs
  • webzen.muorigin.google
  • ncsoft.lineagem19
  • ncsoft.lineagem
  • co.neople.neopleotp
  • co.happymoney.android.happymoney
  • nexon.axe
  • nexon.nxplay
  • atsolution.android.uotp2

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 (http://my.tv.sohu.com/user/%s) in the malicious application used for malware control. The site my.tv.sohu.com 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 sohu.com webpage, the malware extracts a Chinese string from a specific part of the HTML code.

For example, the malicious application receives the page at http://my.tv.sohu.com/user/329505338.

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 http://my.tv.sohu[.]com/user/%s https://www.baidu[.]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;' # my.tv.sohu.com pattern = u'公司&lt;/span&gt;([\u4e00-\u9fa5]+?)&lt;' # baidu.com match = re.search(pattern, page.decode("utf-8")) ext = match.group(1) 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 dec_facebook_apk.py my.tv.sohu.com_329505338.html 220.136.76[.]200:8844 $ python dec_facebook_apk.py www.baidu.com_p_wokaixin158998_detail.html 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.

Conclusions

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):
HEUR:Trojan-Banker.AndroidOS.Wroba

IOC

Malicious hosts:
114.44.37[.]112
118.166.1[.]124
118.168.193[.]123
128.14.50[.]146
128.14.50[.]147
220.136.111[.]66
220.136.179[.]5
220.136.76[.]200
43.240.14[.]44
haoxingfu01.ddns[.]net
shaoye11.hopto[.]org

Malicious apks:
03108e7f426416b0eaca9132f082d568
1cc88a79424091121a83d58b6886ea7a
2a1da7e17edaefc0468dbf25a0f60390
31e61e52d38f19cf3958df2239fba1a7
34efc3ebf51a6511c0d12cce7592db73
4d9a7e425f8c8b02d598ef0a0a776a58
808b186ddfa5e62ee882d5bdb94cc6e2
904b4d615c05952bcf58f35acadee5c1
a21322b2416fce17a1877542d16929d5
b84b0d5f128a8e0621733a6f3b412e19
bd90279ad5c5a813bc34c06093665e55
ff163a92f2622f2b8330a5730d3d636c

class.dex:
19e3daf40460aea22962d98de4bc32d2
36b2609a98aa39c730c2f5b49097d0ad
3ba4882dbf2dd6bd4fc0f54ec1373f4c
6cac4c9eda750a69e435c801a7ca7b8d
8a4ed9c4a66d7ccb3d155f85383ea3b3
b43335b043212355619fd827b01be9a0
b7afa4b2dafb57886fc47a1355824199
f89214bfa4b4ac9000087e4253e7f754

test.dex:
1bd7815bece1b54b7728b8dd16f1d3a9
307d2780185ba2b8c5ad4c9256407504
3e4bff0e8ed962f3c420692a35d2e503
57abbe642b85fa00b1f76f62acad4d3b
6e1926d548ffac0f6cedfb4a4f49196e
7714321baf6a54b09baa6a777b9742ef
7aa46b4d67c3ab07caa53e8d8df3005c
a0f88c77b183da227b9902968862c2b9

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: intelreports@kaspersky.com.

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 intelreports@kasperksy.com.

Operation Parliament, who is doing what?

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

Summary

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: intelreports@kaspersky.com

Alternatively, please visit: https://www.kaspersky.com/enterprise-security/apt-intelligence-reporting

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 placartv.com server. This same domain is used in the developer’s email address specified in the Google Play store. Unbeknown to visitors, the site placartv.com runs a script that mines cryptocurrency.

Code of the placartv.com 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 Vilny.net 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 Vilny.net VPN app

Information about the Vilny.net VPN app on Google Play

Conclusion

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.

MD5

F9C4A28284CD7A4534A1102C20F04C9D
B32DBBFBB0D4EC97C59B50D29DDAAA2D
2D846265F6569547490FCB38970FC93E
6E1FDFBDAB69090FEA77B3F2F33098A8
5464647B09D5F2E064183A073AE97D7B
5B7324C165EE6AF26CDA55293DAEACDF
E771099ACA570F53A94BE713A3C2ED63
3062659C25F44EEA5FE8D3D85C99907D
AEBB87E9AEA464EFB6FCC550BF7D2D38
38CE6C161F87345B773795553AAE2C28
CA3E7A442D5A316DA9ED8DB3C4D913A7
34F43BAAFAEBDAC4CC582E1AAACF26BD
F8DE7065A7D9F191FD0A53289CDB959B
34EB1FFDC8D9D5DD3C32A0ACC4995E29
020A9064D3819A0293940A4F0B36DD2A
EE78507A293D007C47F3D2D471AAD013
0E129E2F4EA3C09BFB0C4841E173580C
50BF20954B8388FA3D5E048E6FA493A9