McAfee Labs

iStock-954683756-min-2-300x200.jpg

Analysis of LooCipher, a New Ransomware Family Observed This Year

Analysis of LooCipher, a New Ransomware Family Observed This Year 1

Initial Discovery

This year seems to again be the year for ransomware. Notorious attacks were made using ransomware and new families are being detected almost on a weekly basis.

The McAfee ATR team has now analyzed a new ransomware family with some special features we would like to showcase. LooCipher represents how a new actor in an early stage of development used the same techniques of distribution as other players in the ransomware landscape. The design of the ransomware note reminded us of the old times of Cerber ransomware, a very well impacted design to force the user to pay the rescue.

Thanks to initiatives like the ‘No More Ransom’ project, one of the partners involved has already provided a valid decryptor to restore files encrypted by LooCipher.

McAfee Telemetry

Based on the data we manage, we detected LooCipher infections in the following regions:

Analysis of LooCipher, a New Ransomware Family Observed This Year 2

Campaign Analysis:

Based on the analysis we performed, this ransomware was delivered through a DOC file. The content and techniques used with this MalDoc are quite simple compared to other doc files used to spread malware, such as Emotet. No special social engineering techniques were applied; the authors only put a simple message on it – “Enable macros”.

Analysis of LooCipher, a New Ransomware Family Observed This Year 3

The file is prepared to download LooCipher from a remote server upon opening the file. We can see the Sub AutoOpen function as a macro in the document:

Analysis of LooCipher, a New Ransomware Family Observed This Year 4

LooCipher will start its encryption routine using a predefined set of characters, creating a block of 16 bytes and using the local system hour:

Analysis of LooCipher, a New Ransomware Family Observed This Year 5

The ransomware will use the AES-ECB encryption algorithm in the process and the key is the same for all the files which facilitates the file recovery process. Other ransomware families use a different key for each file to avoid the possibility of a brute force attack discovering the key used during the infection.

In the encryption process, the ransomware will avoid 3 special folders in the system so as to not break their functionality.

Analysis of LooCipher, a New Ransomware Family Observed This Year 6

Encrypting key files and folders was one of the mistakes we highlighted in our analysis of LockerGoga; that ransomware was completely breaking the functionality of the system. Some binaries found were encrypting all the system, including the LockerGoga binary file.

Regarding the extensions that LooCipher will search and encrypt in the system, the list is hardcoded inside the binary:

Analysis of LooCipher, a New Ransomware Family Observed This Year 7

It is quite interesting see how LooCipher searches for extensions that are not present in Windows systems like “.dmg.” This suggests that the authors may just be going to code sites to find extension lists.

In the analysis we found a PDB reference:

UsersUsuarioDocumentsProyectossher.lockDebugLooCipher.pdb

It is interesting to note that the reference found contains Spanish words, as if the user was using folders named in Spanish, however, the system is configured in English. We currently have no idea why this is so, but it is curious.

BTC payment is the method chosen by LooCipher authors to get money from the victims. So, at the end of the file’s encryption, the ransomware will show a rescue note to the user:

Analysis of LooCipher, a New Ransomware Family Observed This Year 8

LooCipher decryptor will pop up in the system as well with a specific countdown:

Analysis of LooCipher, a New Ransomware Family Observed This Year 9

In the ransom note LooCipher says the BTC address is specifically generated for the user but that is not true; all the BTC addresses we have seen are hardcoded in the binary:

Analysis of LooCipher, a New Ransomware Family Observed This Year 10

This is another special characteristic for this ransomware. Normally, this workflow is providing an email address to contact the authors so they can provide the instructions to the victim, or at least a BTC address to make payment (if there is not a unique BTC address provided to every victim), something that is the main difference between RaaS and one-shot campaigns.

If we apply static analysis in the binaries we have, the same bundle of BTC addresses is included across most that we spot in the wild:

Analysis of LooCipher, a New Ransomware Family Observed This Year 11

None of the BTC addresses found regarding LooCipher showed any transactions so we believe the authors did not monetize the campaign with the binaries we analyzed.

Analysis of LooCipher, a New Ransomware Family Observed This Year 12

LooCipher and Network Traffic:

In the encryption process, LooCipher will contact the C2 server and send information about the victim:

Analysis of LooCipher, a New Ransomware Family Observed This Year 13

The data sent to the server is:

Analysis of LooCipher, a New Ransomware Family Observed This Year 14

Here, a copy of the network traffic could help the user to know the encryption key used.

Decryptor Fallback Mechanism Implemented by LooCipher

The LooCipher authors provide a fallback mechanism to help victims access the instructions and the decryptor again, in case they close the LooCipher window when it appears in the system after encrypting the files:

Analysis of LooCipher, a New Ransomware Family Observed This Year 15

The mechanism sees the LooCipher binary uploaded to the Mega platform. In case the user wants to get the BTC address or decrypt the files after making the payment, they can download this binary and use it. If the files were previously encrypted by LooCipher they would not be encrypted again according to the ransomware’s authors.

I’m Infected by LooCipher. How Can I Get my Files Back?

McAfee is one of the founders and contributors of the ‘No More Ransom’ project. One of our fellow stakeholders created a decryptor for all the files encrypted by LooCipher:

Analysis of LooCipher, a New Ransomware Family Observed This Year 16

So, if you are infected with LooCipher, it is possible get your files back.

Conclusions:

LooCipher authors are not a sophisticated actor compared to other families like Ryuk, LockerGoga or REVil. They tried to spread their ransomware combining the infection with an Office file with a simple macro.

It will be impossible for the authors to come back to the scene if they do not change how the ransomware works.

The McAfee ATR Team advises against paying the ransomware demands and, instead, recommends:

  • Saving a copy of your encrypted files – sometimes in the future a decryptor may be released
  • Having a solid backup workflow in the company
  • Implementing best practices in terms of Cybersecurity

YARA Rule

We uploaded a YARA rule to detect almost all the samples observed in the wild.

MITRE ATT&CK Coverage:

  • Hooking
  • Defense Evasion
  • Network Service Scanning
  • System Information Discovery
  • Data Compressed

McAfee Coverage:

  • Artemis!02ACC0BC1446
  • Artemis!12AA5517CB7C
  • Artemis!1B1335F20CD0
  • Artemis!362AB3B56F40
  • Artemis!64FCC1942288
  • Artemis!8F421FE340E7
  • Artemis!983EF1609696
  • Artemis!A11724DBE1D6
  • Artemis!A7ABF760411F
  • Artemis!B9246AA9B474
  • Artemis!F0D98A6809C1
  • McAfee-Ransom-O
  • Ransomware-GNY!3B9A8D299B2A
  • Ransomware-GNY!66571E3C8036
  • Ransomware-GNY!9CF3C9E4A9B5
  • Ransomware-GNY!A0609D7AD404
  • Ransomware-GNY!A77FDEFE40BE
  • Ransomware-GNY!A9B6521FF980
  • Ransomware-GNY!D3CE02AD4D75
  • Ransomware-GNY!DC645F572D1F
  • RDN/Generic Downloader.x
  • RDN/Generic.ole

IOCs

7720aa6eb206e589493e440fec8690ceef9e70b5e6712a9fec9208c03cac7ff0

35456dc5fdaf2281aad4d8f0441dcd0c715164e9d2ca6412380c2215ed2eab9c

3e8660f0d2b5b4c1c7dfb0d92f1198b65f263d36cd9964505f3a69150a729f6f

2ca214c271920c7261fc0009971961fa6d2ee4bd23820899f4d6e0679739bf2e

2ef92ced4c009fc20645c5602f0b1f2ddca464365b73b62eb0b7217f422590d5

77766f7f78e13dce382aeb4f89c13b9de12a2fa85f0a7550f4239dfe385a6fb5

8834001d7420d8caaa20cd429130249db30c81f0c5da92a2cb2da4dee6669c87

242f9a9cb23c87b6a5913731bce3f4e565f0393d95f2f9a78d675ef481578a61

7db9491697847dd0a65b719b0d836aeb28dec22a9deed57aa601f23a5b32214a

1f5d310da6f3f3a89e22fc86acb71741db56cbe85fbacc43822bec344cbe4058

893c4f7e3d8e9dc6757becbf2f20e81ec09557fc8e6ea72353c7b8984068f145

242198732eecc9c2d07d1db612b6084ece3a8d1d1b337554a7bef4216cbebccf

e209d7003a5d3674ab90fd1d082266a4aaa1bee144b04371abba0c358e95fd03

2a4ce9877a743865d6c11c13aa45da3683af223c196086984f57f3eff07cd3ea

0d72eab82635df496d20a8fb3921e33ed3aac597496cf006322eed48deb2c068

a6d23f11692e23a6c2307b9f5dd660bca3423f2f0202aa398325345f906b07b5

079d555a4935a6748d92e8bd9856ae11ecf4fd5293ed41cf318a407f9aaa6b2d

387be2e56804ed02ed6d4611d82c6f4b88953761d3961a33017adfb274e6cbfa

3e1d8a5faaa35e7f72ecad5f91644efd5bf0d92fdb0341c48a236c843c697196

0c42641fcc805c049883b9617082a8ac6d538fd87cfa371e3fef6114aff71c2a

b31d3de8ffd2b2dce2b570c0172f87a6719f01d4424a7a375bbb249cd15c1157

23b949ed81925ea3c10fa6c74b0d066172409e6a38023bd24672cc4efb47dd64

6987933482f12f0e1301bb0509a46f5889802fe481be160da9a29985acbabbd9

77d5586bc259e944634cff99912779fabfb356f6f840ea5afd6514f52562879d

177e91b5ac698542b5488a95a60816347fcba118f0ad43473aa7d2d5c9223847

0ffeb5639da6e77dfb241f1648fa8f9bac305335f7176def2b17e1b08706d49a

ad7eebdf328c7fd273b278b0ec95cb93bb3428d52f5ff3b69522f1f0b7e3e9a1

hxxps://hcwyo5rfapkytajg[.]tor2web[.]xyz/d[.]php

hxxps://hcwyo5rfapkytajg[.]onion[.]sh/d[.]php

hxxps://hcwyo5rfapkytajg[.]onion[.]ws/d[.]php

hxxps://hcwyo5rfapkytajg[.]tor2web[.]xyz/k[.]php

hxxps://hcwyo5rfapkytajg[.]onion[.]ws/k[.]php

hxxps://hcwyo5rfapkytajg[.]darknet[.]to/d[.]php

hxxps://hcwyo5rfapkytajg[.]onion[.]sh/k[.]php

hxxp://hcwyo5rfapkytajg[.]onion[.]pet/k[.]php

hxxps://hcwyo5rfapkytajg[.]darknet[.]to/k[.]php

hxxp://hcwyo5rfapkytajg[.]onion[.]pet/d[.]php

924cc338d5d03f8914fe54f184596415563c4172679a950245ac94c80c023c7d

e824650b66c5cdd8c71983f4c4fc0e1ac55cd04809d562f3b6b4790a28521486

hcwyo5rfapkytajg[.]darknet[.]to

hcwyo5rfapkytajg[.]onion[.]sh

hcwyo5rfapkytajg[.]onion[.]ws

hcwyo5rfapkytajg[.]tor2web[.]xyz

hxxps://hcwyo5rfapkytajg[.]onion[.]sh/3agpke31mk[.]exe

hxxp://hcwyo5rfapkytajg[.]onion[.]pet/2hq68vxr3f[.]exe

hxxps://hcwyo5rfapkytajg[.]onion[.]sh/info_bsv_2019[.]docm

hxxps://hcwyo5rfapkytajg[.]onion[.]ws/3agpke31mk[.]exe

hxxps://hcwyo5rfapkytajg[.]darknet[.]to/2hq68vxr3f[.]exe

hxxp://hcwyo5rfapkytajg[.]onion[.]pet/info_project_bsv_2019[.]docm

hxxps://hcwyo5rfapkytajg[.]onion[.]ws/info_bsv_2019[.]docm

hxxps://hcwyo5rfapkytajg[.]tor2web[.]xyz/3agpke31mk[.]exe

hxxps://hcwyo5rfapkytajg[.]tor2web[.]xyz/info_bsv_2019[.]docm

hxxps://hcwyo5rfapkytajg[.]onion[.]sh/2hq68vxr3f[.]exe

hxxp://hcwyo5rfapkytajg[.]onion[.]pet/info_bsv_2019[.]docm

hxxp://hcwyo5rfapkytajg[.]onion[.]pet/3agpke31mk[.]exe

hxxps://hcwyo5rfapkytajg[.]darknet[.]to/info_bsv_2019[.]docm

hxxps://hcwyo5rfapkytajg[.]tor2web[.]xyz/2hq68vxr3f[.]exe

hxxps://hcwyo5rfapkytajg[.]onion[.]ws/2hq68vxr3f[.]exe

hxxps://hcwyo5rfapkytajg[.]darknet[.]to/3agpke31mk[.]exe

43cfb0a439705ab2bd7c46b39a7265ff0a14f7bd710b3e1432a9bdc4c1736c49

ff24d9575694ae2a1e6a6101a2dbaa95dd1ab31b44a3931f6d6a62bbf5be2cbd

The post Analysis of LooCipher, a New Ransomware Family Observed This Year appeared first on McAfee Blogs.

Blog-300x189.png

McAfee Labs 2020 Threats Predictions Report

McAfee Labs 2020 Threats Predictions Report 17

With 2019’s headlines of ransomware, malware, and RDP attacks almost behind us, we shift our focus to the cybercrime threats ahead. Cybercriminals are increasing the complexity and volume of their attacks and campaigns, always looking for ways to stay one step ahead of cybersecurity practices – and more often using the world’s evolving technology against us.

Continuing advancements in artificial intelligence and machine learning have led to invaluable technological gains, but threat actors are also learning to leverage AI and ML in increasingly sinister ways. AI technology has extended the capabilities of producing convincing deepfake video to a less-skilled class of threat actor attempting to manipulate individual and public opinion. AI-driven facial recognition, a growing security asset, is also being used to produce deepfake media capable of fooling humans and machines.

Our researchers also foresee more threat actors targeting corporate networks to exfiltrate corporate information in two-stage ransomware campaigns.

With more and more enterprises adopting cloud services to accelerate their business and promote collaboration, the need for cloud security is greater than ever. As a result, the number of organizations prioritizing the adoption container technologies will likely continue to increase in 2020. Which products will they rely on to help reduce container-related risk and accelerate DevSecOps?

The increased adoption of robotic process automation and the growing importance to secure system accounts used for automation raises security concerns tied to Application Programming Interface (API) and their wealth of personal data.

The threatscape of 2020 and beyond promises to be interesting for the cybersecurity community.

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

Twitter @Raj_Samani

Predictions

Broader Deepfakes Capabilities for Less-Skilled Threat Actors

Adversaries to Generate Deepfakes to Bypass Facial Recognition

Ransomware Attacks to Morph into Two-Stage Extortion Campaigns

Application Programming Interfaces (API) Will be Exposed as The Weakest Link Leading to Cloud-Native Threats

DevSecOps Will Rise to Prominence as Growth in Containerized Workloads Causes Security Controls to ‘Shift Left’

Broader Deepfakes Capabilities for Less-skilled Threat Actors

By Steve Grobman

The ability to create manipulated content is not new. Manipulated images were used as far back as World War II in campaigns designed to make people believe things that weren’t true. What’s changed with the advances in artificial intelligence is you can now build a very convincing deepfake without being an expert in technology. There are websites set up where you can upload a video and receive in return, a deepfake video. There are very compelling capabilities in the public domain that can deliver both deepfake audio and video abilities to hundreds of thousands of potential threats actors with the skills to create persuasive phony content.

Deepfake video or text can be weaponized to enhance information warfare. Freely available video of public comments can be used to train a machine-learning model that can develop of deepfake video depicting one person’s words coming out of another’s mouth. Attackers can now create automated, targeted content to increase the probability that an individual or groups fall for a campaign. In this way, AI and machine learning can be combined to create massive chaos.

In general, adversaries are going to use the best technology to accomplish their goals, so if we think about nation-state actors attempting to manipulate an election, using deepfake video to manipulate an audience makes a lot of sense. Adversaries will try to create wedges and divides in society. Or if a cybercriminal can have a CEO make what appears to be a compelling statement that a company missed earnings or that there’s a fatal flaw in a product that’s going to require a massive recall. Such a video can be distributed to manipulate a stock price or enable other financial crimes

We predict the ability of an untrained class to create deepfakes will enhance an increase in quantity of misinformation.

Adversaries to Generate Deepfakes to Bypass Facial Recognition

By Steve Povolny

Computer-based facial recognition, in its earliest forms, has been around since the mid-1960s. While dramatic changes have since taken place, the underlying concept remains: it provides a means for a computer to identify or verify a face. There are many use cases for the technology, most related to authentication and to answer a single question: is this person who they claim to be?

As time moves onwards, the pace of technology has brought increased processing power, memory and storage to facial recognition technology. New products have leveraged facial recognition in innovative ways to simplify everyday life, from unlocking smart phones, to passport ID verification in airports, and even as a law enforcement aid to identify criminals on the street.

One of the most prevalent enhancements to facial recognition is the advancement of artificial intelligence (AI). A recent manifestation of this is deepfakes, an AI-driven technique producing extremely realistic text, images, and videos that are difficult for humans to discern real from fake. Primarily used for the spread of misinformation, the technology leverages capabilities. Generative Adversarial Networks (GANs), a recent analytic technology, that on the downside, can create fake but incredibly realistic images, text, and videos. Enhanced computers can rapidly process numerous biometrics of a face, and mathematically build or classify human features, among many other applications. While the technical benefits are impressive, underlying flaws inherent in all types of models represent a rapidly growing threat, which cyber criminals will look to exploit.

As technologies are adopted over the coming years, a very viable threat vector will emerge, and we predict adversaries will begin to generate deepfakes to bypass facial recognition. It will be critical for businesses to understand the security risks presented by facial recognition and other biometric systems and invest in educating themselves of the risks as well as hardening critical systems.

Ransomware Attacks to Morph into Two-Stage Extortion Campaigns

By John Fokker

In McAfee’s 2019 threat predictions report, we predicted cyber criminals would partner more closely to boost threats; over the course of the year, we observed exactly that. Ransomware groups used pre-infected machines from other malware campaigns, or used remote desktop protocol (RDP) as an initial launch point for their campaign. These types of attacks required collaboration between groups. This partnership drove efficient, targeted attacks which increased profitability and caused more economic damage. In fact,  Europol’s Internet Organised Crime Threat Assessment (IOCTA),  named ransomware the top threat that companies, consumers, and the public sector faced in 2019.

Based on what McAfee Advanced Threat Research (ATR) is seeing in the underground, we expect criminals to exploit their extortion victims even more moving forward. The rise of targeted ransomware created a growing demand for compromised corporate networks. This demand is met by criminals who specialize in penetrating corporate networks and sell complete network access in one-go.

Here are examples of underground ads offering access to businesses:

McAfee Labs 2020 Threats Predictions Report 18

Figure 1 RDP access to a Canadian factory is being offered

McAfee Labs 2020 Threats Predictions Report 19

Figure 2 Access to an Asian Food, Consumer and Industrial company being offered

For 2020, we predict the targeted penetration of corporate networks will continue to grow and ultimately give way to two-stage extortion attacks. In the first stage cybercriminals will deliver a crippling ransomware attack, extorting victims to get their files back. In the second stage criminals will target the recovering ransomware victims again with an extortion attack, but this time they will threaten to disclose the sensitive data stolen before the ransomware attack.

During our research on Sodinobiki we observed two-stage attacks, with cryptocurrency miners installed before an actual ransomware attack took place. For 2020, we predict that cybercriminals will increasingly exfiltrate sensitive corporate information prior to a targeted ransomware attack to sell the stolen data online or to extort the victim and increase monetization.

Application Programming Interfaces (API) Will Be Exposed as The Weakest Link Leading to Cloud-Native Threats

By Sekhar Sarukkai

A recent study showed that more than three in four organizations treat API security differently than web app security, indicating API security readiness lags behind other aspects of application security. The study also showed that more than two-thirds of organizations expose APIs to the public to enable partners and external developers to tap into their software platforms and app ecosystems.

APIs are an essential tool in today’s app ecosystem including cloud environments, IoT, microservices, mobile, and Web-based customer-client communications. Dependence on APIs will further accelerate with a growing ecosystem of cloud applications built as reusable components for back-office automation (such as with Robotic Process Automation) and growth in the ecosystem of applications that leverage APIs of cloud services such as Office 365 and Salesforce.

Threat actors are following the growing number of organizations using API-enabled apps because APIs continue to be an easy – and vulnerable – means to access a treasure trove of sensitive data. Despite the fallout of large-scale breaches and ongoing threats, APIs often still reside outside of the application security infrastructure and are ignored by security processes and teams. Vulnerabilities will continue to include broken authorization and authentication functions, excessive data exposure, and a failure to focus on rate limiting and resource limiting attacks. Insecure consumption-based APIs without strict rate limits are among the most vulnerable.

Headlines reporting API-based breaches will continue into 2020, affecting high-profile apps in social media, peer-to-peer, messaging, financial processes, and others, adding to the hundreds of millions of transactions and user profiles that have been scraped in the past two years. The increasing need and hurried pace of organizations adopting APIs for their applications in 2020 will expose API security as the weakest link leading to cloud-native threats, putting user privacy and data at risk until security strategies mature.

Organizations seeking improvement in their API security strategy should pursue a more complete understanding of their Cloud Service APIs through comprehensive discovery across SaaS, PaaS and IaaS environments, implement policy-based authorization, and explore User and Entity Behavior Analytics (UEBA) technology to detect anomalous access patterns.

 

DevSecOps Will Rise to Prominence as Growth in Containerized Workloads Causes Security Controls to ‘Shift Left’

 By Sekhar Sarukkai

DevOps teams can continuously roll out micro-services and interacting, reusable components as applications. As a result, the number of organizations prioritizing the adoption of container technologies will continue to increase in 2020. Gartner predicts that “by 2022, more than 75 percent of global organizations will be running containerized applications in production – a significant increase from fewer than 30 percent today.” 1 Container technologies will help organizations modernize legacy applications and create new cloud-native applications that are scalable and agile.

Containerized applications are built by assembling reusable components on software defined Infrastructure-as-Code (IaC) which is deployed into Cloud environments. Continuous Integration / Continuous Deployment (CI/CD) tools automate the build and deploy process of these applications and IaC, creating a challenge for pre-emptive and continuous detection of application vulnerabilities and IaC configuration errors. To adjust to the rise in containerized applications operating in a CI/CD model, security teams will need to conduct their risk assessment at the time of code build, before deployment. This effectively shifts security “left” in the deployment lifecycle and integrates security into the DevOps process, a model frequently referred to as DevSecOps.

Additionally, threats to containerized applications are introduced nor only by IaC misconfigurations or application vulnerabilities, but also abused network privileges which allow lateral movement in an attack. To address these run-time threats, organizations are increasingly turning to cloud-native security tools developed specifically for container environments. Cloud Access Security Brokers (CASB) are used to conduct configuration and vulnerability scanning, while Cloud Workload Protection Platforms (CWPP) work as traffic enforcers for network micro-segmentation based on the identity of the application, regardless of its IP. This approach to application identity-based enforcement will push organizations away from the five-tuple approach to network security which is increasingly irrelevant in the context of ephemeral container deployments.

When CASB and CWPP solutions integrate with CI/CD tools, security teams can meet the speed of DevOps, shifting security “left” and creating a DevSecOps practice within their organization.  Governance, compliance, and overall security of cloud environments will improve as organizations accelerate their transition to DevSecOps with these cloud-native security tools.

 

Gartner Best Practices for Running Containers and Kubernetes in Production, Arun Chandrasekaran, 25 February 2019

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

Network-of-internet-of-things-attacked-by-a-hacker-on-one-node-3D-illustration-300x169-3.jpg

Spanish MSSP Targeted by BitPaymer Ransomware

Spanish MSSP Targeted by BitPaymer Ransomware 20

Initial Discovery

This week the news hit that several companies in Spain were hit by a ransomware attack. Ransomware attacks themselves are not new but, by interacting with one of the cases in Spain, we want to highlight in this blog how well prepared and targeted an attack can be and how it appears to be customized specifically against its victims.

In general, ransomware attacks are mass-spread attacks where adversaries try to infect many victims at the same time and cash out quickly. However, this has significantly changed over the past two years where more and more ransomware attacks are targeting high-value targets in all kinds of sectors.

Victims are infected with a different type of malware before the actual ransomware attack takes place. It looks like adversaries are using the infection base to select or purchase the most promising victims for further exploitation and ransomware, in a similar way to how the sale of Remote Desktop Access on underground forums or private Telegram channels is being used for victim selection for ransomware attacks.

In the following paragraphs, we will take you step by step through the modus operandi of the attack stages and most important techniques used and mapped against the MITRE ATT&CK Framework.

The overall techniques observed in the campaign and flow visualization:

Spanish MSSP Targeted by BitPaymer Ransomware 21

Technical Analysis

The overall campaign is well known in the industry and the crew behind it came back to the scene reusing some of the TTPs observed one year ago and adding new ones like: privilege escalation, lateral movement and internal reconnaissance.

Spanish MSSP Targeted by BitPaymer Ransomware 22

Patient 0 – T1189 Drive-by Compromise

The entry point for these types of campaigns starts with a URL that points the user to a fake website (in case the website is compromised) or a legitimate page (in case they decided to use a pay-per-install service) using social engineering techniques; the user gets tricked to download the desired application that will use frameworks like Empire or similar software to download and install next stage malware which, in this case, is Dridex.

First infection – T1090 Connection Proxy

These types of attacks are not limited to one type of malware; we have observed it being used by:

  • Azorult
  • Chthonic
  • Dridex

It is currently unclear why one would select one malware family above the other, but these tools allow for remote access into a victim’s network. This access can then be used by the actor as a launchpad to further exploit the victim’s network with additional malware, post-exploitation frameworks or the access can be sold online.

For quite some time now, Dridex’s behavior has changed from its original form. Less Dridex installs are linked to stealing banking info and more Dridex infections are becoming a precursor to a targeted ransomware attack.

This change or adaptation is something we have observed with other malware families as well.

For this campaign, the Dridex botnet used was 199:

Spanish MSSP Targeted by BitPaymer Ransomware 23

Information Harvesting – T1003 Credential Dumping

From the infection, one or multiple machines are infected, and the next step is to collect as many credentials as they can to perform lateral movement. We observed the use of Mimikatz to collect (high privileged) credentials and re-use them internally to execute additional software in the Active Directory servers or other machines inside the network.

The use of Mimikatz is quite popular, having been observed in the modus operandi of more than 20 different threat actors.

Lateral Movement – T1086 PowerShell

The use of PowerShell helps attackers to automate certain things once they are in a network. In this case, we observed how Empire was used for different sock proxy PowerShell scripts to pivot inside the network:

Spanish MSSP Targeted by BitPaymer Ransomware 24

Extracting information about the IP found in the investigation, we observed that the infrastructure for the Dridex C2 panels and this proxy sock was shared.

Spanish MSSP Targeted by BitPaymer Ransomware 25

PowerShell was also used to find specific folders inside the infected systems:

Spanish MSSP Targeted by BitPaymer Ransomware 26

A reason for an attacker to use a PowerShell based framework like Empire, is the use of different modules, like invoke-psexec or invoke-mimikatz, that can execute remote processes on other systems, or get credentials from any of the systems where it can run Mimikatz. When deployed right, these modules can significantly increase the speed of exploitation.

Once the attackers collected enough high privileged accounts and got complete control over the Active Directory, they would then distribute and execute ransomware on the complete network as the next step of their attack, in this case BitPaymer.

Ransomware Detonation – T1486 Data Encrypted for Impact

BitPaymer seemed to be the final objective of this attack. The actors behind BitPaymer invest time to know their victims and build a custom binary for each which includes the leet-speek name of the victim as the file extension for the encrypted files, i.e. “financials.<name_of_victim>”.

In the ransomware note, we observed the use of the company name too:

Spanish MSSP Targeted by BitPaymer Ransomware 27

Observations

  • One of the remote proxy servers used in the operation shares the same infrastructure as one of the C2 panels used by Dridex.
  • We observed how a Dridex infection served as a launch point for an extensive compromise and BitPaymer ransomware infection.
  • Each binary of Bitpaymer is specially prepared for every single target, including the extension name and using the company name in the ransomware note.
  • Certain Dridex botnet IDs are seen in combination with targeted BitPaymer infections.
  • Companies must not ignore indicators of activity from malware like Dridex, Azorult or NetSupport; they could be a first indicator of other malicious activity to follow.
  • It is still unclear how the fake update link arrived at the users but in similar operations, SPAM campaigns were most likely used to deliver the first stage.

McAfee Coverage

Based on the indicators of compromise found, we successfully detect them with the following signatures:

  • RDN/Generic.hbg
  • Trojan-FRGC!7618CB3013C3
  • RDN/Generic.dx

The C2 IPs are tagged as a malicious in our GTI.

McAfee ATD Sandbox Detonation

Advanced Threat Detection (ATD) is a specialized appliance that identifies sophisticated and difficult to detect threats by executing suspicious malware in an isolated space, analyzing its behavior and assessing the impact it can have on an endpoint and on a network.

For this specific case, the ATD sandbox showcases the activity of Bitpaymer in a system:

Spanish MSSP Targeted by BitPaymer Ransomware 28

We observe the use of icacls and takeown to change permissions inside the system and the living off the land techniques are commonly used by different type of malware.

ATD Sandbox extracted behavior signatures observing Bitpaymer detonation in the isolated environment:

Spanish MSSP Targeted by BitPaymer Ransomware 29

Having the opportunity to detonate malware in this environment could give indicators about the threat types and their capabilities.

McAfee Real Protect

Analysis into the samples garnered from this campaign would have been detected by Real Protect. Real Protect is designed to detect zero-day malware in near real time by classifying it based on behavior and static analysis. Real Protect uses machine learning to automate classification and is a signature-less, small client footprint while supporting both offline mode and online mode of classification. Real Protect improves detection by up to 30% on top of .DAT and McAfee Global Threat Intelligence detections, while producing actionable threat intelligence.

Spanish MSSP Targeted by BitPaymer Ransomware 30

YARA RULE

We have a YARA rule available on our ATR GitHub repository to detect some of the versions of BitPaymer ransomware.

IOCs

Spanish MSSP Targeted by BitPaymer Ransomware 31

The post Spanish MSSP Targeted by BitPaymer Ransomware appeared first on McAfee Blogs.

labs-thumbnail-3-300x169-3.jpeg

Buran Ransomware; the Evolution of VegaLocker

Buran Ransomware; the Evolution of VegaLocker 32

McAfee’s Advanced Threat Research Team observed how a new ransomware family named ‘Buran’ appeared in May 2019. Buran works as a RaaS model like other ransomware families such as REVil, GandCrab (now defunct), Phobos, etc. The author(s) take 25% of the income earned by affiliates, instead of the 30% – 40%, numbers from notorious malware families like GandCrab, and they are willing to negotiate that rate with anyone who can guarantee an impressive level of infection with Buran. They announced in their ads that all the affiliates will have a personal arrangement with them.

For this analysis we present, we will focus on one of the Buran hashes:

Buran Ransomware; the Evolution of VegaLocker 33

We will highlight the most important observations when researching the malware and will share protection rules for the endpoint, IOCs and a YARA rule to detect this malware.

Buran Ransomware Advertisement

This ransomware was announced in a well-known Russian forum with the following message:

 

Buran is a stable offline cryptoclocker, with flexible functionality and support 24/7.

Functional:

Reliable cryptographic algorithm using global and session keys + random file keys;
Scan all local drives and all available network paths;
High speed: a separate stream works for each disk and network path;
Skipping Windows system directories and browser directories;
Decryptor generation based on an encrypted file;
Correct work on all OSs from Windows XP, Server 2003 to the latest;
The locker has no dependencies, does not use third-party libraries, only mathematics and vinapi;

The completion of some processes to free open files (optional, negotiated);
The ability to encrypt files without changing extensions (optional);
Removing recovery points + cleaning logs on a dedicated server (optional);
Standard options: tapping, startup, self-deletion (optional);
Installed protection against launch in the CIS segment.

Conditions:

They are negotiated individually for each advert depending on volumes and material.

Start earning with us!

 

The announcement says that Buran is compatible with all versions of the Windows OS’s (but during our analysis we found how, in old systems like Windows XP, the analyzed version did not work) and Windows Server and, also, that they will not infect any region inside the CIS segment. Note: The CIS segment belongs to ten former Soviet Republics: Armenia, Belarus, Kazakhstan, Kyrgyzstan, Moldova, Russia, Tajikistan, Turkmenistan, Ukraine, and Uzbekistan.

Rig Exploit Kit as an Entry Vector

Based upon the investigation we performed, as well as research by “nao_sec” highlighted in June 2019, we discovered how Buran ransomware was delivered through the Rig Exploit Kit. It is important to note how the Rig Exploit Kit is the preferred EK used to deliver the latest ransomware campaigns.

Buran Ransomware; the Evolution of VegaLocker 34

FIGURE 1. EXPLOIT KIT

The Rig Exploit Kit was using CVE-2018-8174 (Microsoft Internet Explorer VBScript Engine, Arbitrary Code Execution) to exploit in the client-side. After successful exploitation this vulnerability will deliver Buran ransomware in the system.

Static Analysis

The main packer and the malware were written in Delphi to make analysis of the sample more complicated. The malware sample is a 32-bit binary.

Buran Ransomware; the Evolution of VegaLocker 35

FIGURE 2. BURAN STATIC INFORMATION

In our analysis we detected two different versions of Buran, the second with improvements compared to the first one released.

Buran Ransomware; the Evolution of VegaLocker 36

FIGURE 3. BURAN STATIC INFORMATION

The goal of the packer is to decrypt the malware making a RunPE technique to run it from memory. To obtain a cleaner version of the sample we proceed to dump the malware from the memory, obtaining an unpacked version.

Country Protection

Checking locales has become quite popular in RaaS ransomware as authors want to ensure they do not encrypt data in certain countries. Normally we would expect to see more former CIS countries but, in this case, only three are verified.

Buran Ransomware; the Evolution of VegaLocker 37

FIGURE 4. GETTING THE COUNTRY OF THE VICTIM SYSTEM

This function gets the system country and compares it with 3 possible results:

  • 0x7 -> RUSSIAN FEDERATION
  • 0x177 -> BELARUS
  • 0x17C -> UKRAINE

It is important to note here that the advertising of the malware in the forums said it does not affect CIS countries but, with there being 10 nations in the region, that is obviously not entirely accurate.

If the system is determined to be in the Russian Federation, Belarus or Ukraine the malware will finish with an “ExitProcess”.

The next action is to calculate a hash based on its own path and name in the machine. With the hash value of 32-bits it will make a concat with the extension “.buran”. Immediately after, it will create this file in the temp folder of the victim machine. Importantly, if the malware cannot create or write the file in the TEMP folder it will finish the execution; the check will be done extracting the date of the file.

Buran Ransomware; the Evolution of VegaLocker 38

FIGURE 5. BURAN CHECKS IN THE TEMP FOLDER

If the file exists after the check performed by the malware, the temporary file will be erased through the API “DeleteFileW”.

Buran Ransomware; the Evolution of VegaLocker 39

FIGURE 6. CHECK WHETHER A TEMP FILE CAN BE CREATED

This function can be used as a kill switch to avoid infection by Buran.

Buran ransomware could accept special arguments in execution. If it is executed without any special argument, it will create a copy of Buran with the name “ctfmon.exe” in the Microsoft APPDATA folder and will launch it using ShellExecute, with the verb as “runas”. This verb is not in the official Microsoft SDK but, if we follow the MSDN documentation to learn how it works, we can deduce that the program will ignore its own manifest and prompt the UAC to the user if the protection is enabled.

This behavior could change depending on the compilation options chosen by the authors and delivered to the affiliates.

According to the documentation, the function “CreateProcess” checks the manifest, however in Buran, this is avoided due to that function:

Buran Ransomware; the Evolution of VegaLocker 40

FIGURE 7. LAUNCH OF THE NEW INSTANCE OF ITSELF

Buran in execution will create a registry key in the Run subkey section pointing to the new instance of the ransomware with a suffix of ‘*’. The meaning of this value is that Buran will run in safe mode too:

Buran Ransomware; the Evolution of VegaLocker 41

FIGURE 8. PERSISTENCE IN THE RUN SUBKEY IN THE REGISTRY

The writing operation in the registry is done using the “reg” utility, using a one-liner and concatenating different options with the “&” symbol. This method through “reg.exe” avoids a breakpoint in the main binary.

Buran Ransomware; the Evolution of VegaLocker 42

FIGURE 9. WRITE OF PERSISTENCE IN THE REGISTRY

Buran implements this technique with the objective of making analysis of the sample complicated for malware analysts looking at reverse engineering profiles. After these operations, the old instance of the ransomware will die using “Exit Process”.

Analysis of the Delphi code show that the 2nd version of Buran will identify the victim using random values.

Buran Ransomware; the Evolution of VegaLocker 43

FIGURE 10. GENERATE RANDOM VALUES

After that it will decrypt a registry subkey called “SoftwareBuranKnock” in the HKEY_CURRENT_USER hive. For the mentioned key it will check the actual data of it and, if the key does not exist, it will add the value 0x29A (666) to it. Interestingly, we discovered that GandCrab used the same value to generate the ransom id of the victim. If the value and subkey exists the malware will continue in the normal flow; if not, it will decrypt a URL ,“iplogger.ru”, and make a connection to this domain using a special user agent:

Buran Ransomware; the Evolution of VegaLocker 44

FIGURE 11. SPECIAL USER AGENT BURAN

Buran Ransomware; the Evolution of VegaLocker 45

As mentioned, the referrer will be the victim identifier infected with Buran.

The result of this operation is the writing of the subkey previously checked with the value 0x29A, to avoid repeating the same operation.

After this action the malware will enumerate all network shares with the functions :

  • WNetOpenEnumA,
  • WNetEnumResourceA
  • WNetCloseEnum

This call is made in a recursive way, to get and save all discovered shared networks in a list. This process is necessary if Buran wants to encrypt all the network shares as an addition to the logical drives. Buran will avoid enumerating optical drives and other non-mounted volumes. The result of those operations will be saved for Buran to use later in the encryption process.

The ransom note is crypted inside the binary and will be dumped in execution to the victim’s machine. Inside this ransom note, the user will find their victim identifier extracted with the random Delphi function mentioned earlier. This identification is necessary to track their infected users to affiliates to deliver the decryptor after the payment is made.

In the analysis of Buran, we found how this ransomware blacklists certain files and folders. This is usually a mechanism to ensure that the ransomware does not break its functionality or performance.

Blacklisted folders in Buran:

Buran Ransomware; the Evolution of VegaLocker 46

Blacklisted files in Buran:

Buran Ransomware; the Evolution of VegaLocker 47

The encryption process will start with special folders in the system like the Desktop folder. Buran can use threads to encrypt files and during the process will encrypt the drive letters and folders grabbed before in the recognition process.

The ransom note will be written to disk with the name “!!! YOUR FILES ARE ENCRYPTED !!!” with the following content:

Buran Ransomware; the Evolution of VegaLocker 48

FIGURE 12. AN EXAMPLE RANSOM NOTE

Each file crypted is renamed to the same name as before but with the new extension of the random values too.

For example: “rsa.bin.4C516831-800A-6ED2-260F-2EAEDC4A8C45”.

All the files encrypted by Buran will contain a specific filemarker:

Buran Ransomware; the Evolution of VegaLocker 49

FIGURE 13. CRYPTED FILE

In terms of encryption performance, we found Buran slower compared to other RaaS families. According to the authors’ advertisement in the underground forums, they are continually improving their piece of ransomware.

Buran Version 1 vs Buran Version 2

In our research we identified two different versions of Buran. The main differences between them are:

Shadow copies delete process:

In the 2nd version of Buran one of the main things added is the deletion of the shadow copies using WMI.

Buran Ransomware; the Evolution of VegaLocker 50Backup catalog deletion:

Another feature added in the new version is the backup catalog deletion. It is possible to use the Catalog Recovery Wizard to recover a local backup catalog.

Buran Ransomware; the Evolution of VegaLocker 51

System state backup deletion:

In the same line of system destruction, we observed how Buran deletes in execution the system state backup in the system:

Buran Ransomware; the Evolution of VegaLocker 52

Ping used as a sleep method:

As a poor anti-evasion technique, Buran will use ping through a ‘for loop’ in order to ensure the file deletion system.

Buran Ransomware; the Evolution of VegaLocker 53

The ransom note changed between versions:

Buran Ransomware; the Evolution of VegaLocker 54

VegaLocker, Jumper and Now Buran Ransomware

Despite the file marker used, based on the behavior, TTPs and artifacts in the system we could identify that Buran is an evolution of the Jumper ransomware. VegaLocker is the origin for this malware family.

Malware authors evolve their malware code to improve it and make it more professional. Trying to be stealthy to confuse security researchers and AV companies could be one reason for changing its name between revisions.

This is the timeline of this malware family:

Buran Ransomware; the Evolution of VegaLocker 55

Similarities in Behavior:

Files stored in the temp folder:

VegaLocker:

Buran Ransomware; the Evolution of VegaLocker 56

Jumper:

Buran Ransomware; the Evolution of VegaLocker 57

Buran:

Buran Ransomware; the Evolution of VegaLocker 58

Registry changes:

VegaLocker:

Buran Ransomware; the Evolution of VegaLocker 59

Buran:

Buran Ransomware; the Evolution of VegaLocker 60

Extension overlapping:

In one of the variants (Jumper) it is possible to spot some samples using both extensions:

  • .vega
  • .jamper

Shadow copies, backup catalog and systembackup:

In the analyzed samples we saw how VegaLocker used the same methods to delete the shadow copies, backup catalog and the systembackup.

Coverage

  • RDN/Ransom
  • Ransomware-GOS!E60E767E33AC
  • Ransom
  • RDN/Ransom
  • RDN/Generic.cf
  • Ransom-Buran!

Expert Rule:

Buran Ransomware; the Evolution of VegaLocker 61

Indicators of Compromise

Buran Ransomware; the Evolution of VegaLocker 62

MITRE

The sample uses the following MITRE ATT&CK™ techniques:

  • Disabling Security Tools
  • Email Collection
  • File and Directory Discovery
  • File Deletion
  • Hooking
  • Kernel Modules and Extensions
  • Masquerading
  • Modify Registry
  • Network Service Scanning
  • Peripheral Device Discovery
  • Process Injection
  • Query Registry
  • Registry Run Keys / Start Folder
  • Remote Desktop Protocol
  • Remote System Discovery
  • Service Execution
  • System Time Discovery
  • Windows Management Instrumentation

YARA Rule

We created a YARA rule to detect Buran ransomware samples and the rule is available in our GitHub repository

Conclusion

Buran represents an evolution of a well-known player in the ransomware landscape. VegaLocker had a history of infections in companies and end-users and the malware developers behind it are still working on new features, as well as new brands, as they continue to generate profits from those actions. We observed new versions of Buran with just a few months between them in terms of development, so we expect more variants from the authors in the future and, perhaps, more brand name changes if the security industry puts too much focus on them. We are observing an increase in ransomware families in 2019, as well as old players in the market releasing new versions based on their own creations.

For the binaries, all of them appeared with a custom packer and already came with interesting features to avoid detection or to ensure the user must pay due to the difficulty of retrieving the files. It mimics some features from the big players and we expect the inclusion of more features in future developments.

Buran is slower than other ransomware families we observed, and samples are coded in Delphi which makes reverse engineering difficult.

The post Buran Ransomware; the Evolution of VegaLocker appeared first on McAfee Blogs.

Global-Cyber-security-concept-copy-300x214-5.jpg

Office 365 Users Targeted by Voicemail Scam Pages

Office 365 Users Targeted by Voicemail Scam Pages 63

Over the past few weeks McAfee Labs has been observing a new phishing campaign using a fake voicemail message to lure victims into entering their Office 365 email credentials. At first, we believed that only one phishing kit was being used to harvest the user’s credentials. However, during our investigation, we found three different malicious kits and evidence of several high-profile companies being targeted. McAfee Customers using VSE, ENS, Livesafe, WebAdvisor and MGW are protected against this phishing campaign.

The attack begins when the victim receives an email informing them that they have missed a phone call, along with a request to login to their account to access their voicemail.

An example of the malicious email is shown below:

Office 365 Users Targeted by Voicemail Scam Pages 64

The phishing email contains a HTML file as an attachment which, when loaded, will redirect the user to the phishing website. There are slight variations in the attachment, but the most recent ones contain an audio recording of someone talking which will lead the victim to believe they are listening to the beginning of a legitimate voicemail.

Office 365 Users Targeted by Voicemail Scam Pages 65

The HTML code which plays the recording is shown below:

Office 365 Users Targeted by Voicemail Scam Pages 66

Once redirected, the victim is shown the phishing page which asks them to log into their account. The email address is prepopulated when the website is loaded; this is another trick to reinforce the victim’s belief that the site is legitimate.

Office 365 Users Targeted by Voicemail Scam Pages 67

When the password is entered, the user is presented with the following successful login page and redirected to the office.com login page.

Office 365 Users Targeted by Voicemail Scam Pages 68

We observed the following filenames being used for the attachments:

  • 10-August-2019.wav.html [Format: DD-Month-YYYY.wav.html]
  • 14-August-2019.html [Format: DD-Month-YYYY.html]
  • Voice-17-July2019wav.htm [Format: Voice- DD-MonthYYYYwav.htm]
  • Audio_Telephone_Message15-August-2019.wav.html [Format: Audio_Telephone_MessageDD-Month-YYYY.wav.html]

Phishing Sites

As explained in the introduction, we were surprised to observe three different phishing kits being used to generate the malicious websites. All three look almost identical but we were able to differentiate them by looking at the generated HTML code and the parameters which were accepted by the PHP script.

Voicemail Scmpage 2019 (Not a typo)

The first kit is being sold on an ICQ channel and the creator advertises it on social media. The kit goes by the name of ‘Voicemail Scmpage 2019’ and operates on a license key basis, where the license key is checked prior to the phishing site being loaded.

A snippet of the generated HTML code is shown below:

Office 365 Users Targeted by Voicemail Scam Pages 69

A file, data.txt, is created on the compromised website and it contains a list of visitors, including their IP address, web browsers and the date.

Office 365 Users Targeted by Voicemail Scam Pages 70

The following data is harvested from the victims and emailed to the owner of the phishing site:

  • Email
  • Password
  • IP Address
  • Region (Location)

Office 365 Information Hollar

The second phishing kit we discovered is called ‘Office 365 Information Hollar’. This kit is very similar to ‘Voicemail Scmpage 2019’ and gathers the same data, as shown in the image below:

Office 365 Users Targeted by Voicemail Scam Pages 71

Third “Unnamed” Kit

The final phishing kit is unbranded, and we could not find any attribution to it. This kit makes use of code from a previous malicious kit targeting Adobe users back in 2017. It is possible that the original author from 2017 has modified this kit, or perhaps more likely the old code has been re-used by a new group.

Office 365 Users Targeted by Voicemail Scam Pages 72

This kit also harvests the same data as the previous two. The ‘Unnamed Kit’ is the most prevalent malicious page we have observed while tracking these voicemail phishing campaigns.

Targeted Industries

During our investigation we observed the following industries being targeted with these types of phishing emails:

Office 365 Users Targeted by Voicemail Scam Pages 73

[Services includes tourism, entertainment, real estate and others which are too small to group]

A wide range of employees were targeted, from middle management to executive level staff. We believe that this is a ‘Phishing’ and ‘Whaling’ campaign.

Conclusion

The goal of malicious actors is to harvest as many credentials as possible, to gain access to potentially sensitive information and open the possibility of impersonation of staff, which could be very damaging to the company. The entered credentials could also be used to access other services if the victim uses the same password, and this could leave them open to a wider of range targeted attacks.

What sets this phishing campaign apart from others is the fact that it incorporates audio to create a sense of urgency which, in turn, prompts victims to access the malicious link. This gives the attacker the upper hand in the social engineering side of this campaign.

We urge all our readers to be vigilant when opening emails and to never open attachments from unknown senders. We also strongly advise against using the same password for different services and, if a user believes that his/her password is compromised, it is recommended to change it as soon as possible

It is highly recommended to use Two-Factor Authentication (2FA) since it provides a higher level of assurance than authentication methods based on Single-Factor Authentication (SFA), like the one that many users utilise for their Office 365 accounts.

When possible for enterprise customers, we recommend blocking .html and .htm attachments at the email gateway level so this kind of attack will not reach the final user.

Also, be sure to read our companion blog which details how you can stay safe from such phishing campaigns.

Indicators of Compromise

Email Attachment with the following filename:

10-August-2019.wav.html [Format: DD-Month-YYYY.wav.html]

14-August-2019.html [Format: DD-Month-YYYY.html]

Voice-17-July2019wav.htm [Format: Voice- DD-MonthYYYYwav.htm]

Audio_Telephone_Message15-August-2019.wav.html [Format: Audio_Telephone_MessageDD-Month-YYYY.wav.html]

McAfee Detections

HTML/Phishing.g V2 DAT = 9349, V3 DAT = 3800

HTML/Phishing.av V2 DAT = 9371, V3 DAT = 3821

HTML/Phishing.aw V2 DAT = 9371, V3 DAT = 3821

The hashes of the attachments will not be provided as this will provide information on the potential targets

Domains:

(Domains (all blocked by McAfee WebAdvisor)

h**ps://aws.oficce.cloudns.asia/live/?email=

h**ps://katiorpea.com/?email=

h**ps://soiuurea.com/?email=

h**ps://afaheab.com/?email=

h**ps://aheahpincpea.com/?email=

More Information on Phishing Attacks:

The post Office 365 Users Targeted by Voicemail Scam Pages appeared first on McAfee Blogs.

Glass-focused-on-virus-in-digital-code-illustration-659x500-300x228-3.jpg

Did You Check Your Quarantine?!

Did You Check Your Quarantine?! 74

A cost-effective way to detect targeted attacks in your enterprise

While it is easy to get caught up in the many waves of new and exciting protection strategies, we have recently discovered an interesting approach to detect a targeted attack and the related actor(s). Quite surprisingly, a big part of the solution already exists in most enterprises: the tried, tested endpoint security platform. In this case, we used our own McAfee Endpoint Security (ENS). Along with ENS, we used GetQuarantine, a freeware tool from McAfee, and a third-party threat analytics service.

The Problem

We will begin with a working definition of a targeted attack:

A targeted attack is a threat in which a threat actor actively pursues and compromises a specific target. To achieve the goal, the adversary may adapt and improve their attack(s) to counter the victim’s defenses and persist at it for a long period of time.

What does this say? First, the adversary’s objective is to compromise a specific target, not just an arbitrary target. Second, the adversary is skilled enough to know how defenses work and is resourceful enough to actively adapt and improve their attack to beat defenses. Third, the adversary is determined enough to pursue the objective for perhaps an indefinite period of time.

Taken together, the above characteristics challenge most defense technologies. Why so? Because these characteristics run counter to the assumptions on which these technologies are based.

At the heart of it, most defense technologies are signature-based, where the signatures are created either by a human analyst, by a machine, or by using instances of known malicious behavior. The cost of constructing signatures is high and is amortized by using the same signature to defend against the same attack elsewhere.

Twenty years ago, when there were just a few thousand examples of malicious software around, it was relatively easy to find the origin, perpetrators, and the reason for the creation and release of a malicious file or application. Security researchers would manually analyze each sample, carefully identify similarities with previously known samples through sheer memory and label each sample with a unique name. This method worked well because the attacks then were opportunistic and aimed at spreading as wide as possible. This meant that anti-virus companies could discover an attack in one place, extract relevant detection signatures, and send the signature updates to its install base.

Now, security threat intelligence companies receive hundreds of thousands of new malware samples every day. There is simply not enough time or resources to analyze each malware to answer who, what, when, and why? The best any anti-virus software can do is to classify a file into just two bins: good or bad. It is impossible for researchers to manually look at every sample and process them to the same detail as before. To make matters worse, attacks today are targeted. Attackers create one-off variants aimed at a specific enterprise. This makes it virtually impossible to connect attacks across enterprises to understand the attacker.

And therein lies an important problem. Just as the numbers and sophistication of attacks have increased exponentially, the objective of tracking who is behind an attack, and identifying linkages between different malware samples and their authors, and the intent behind an attack, have been lost.

Why should it matter? In the absence of information about who is attempting to breach an organization, defenders are left operating in the dark. They make security decisions based on breaches that happen elsewhere using threat intelligence that is most often irrelevant, and when relevant, is most likely outdated.

The Solution

Analysis of targeted campaigns shows that programs that are part of an attack usually show a couple of similar characteristics. First, the malware or attack mechanism is focused on one enterprise or, at most, one sector and second, the malware program demonstrates evolutionary characteristics where the actor repeatedly unleashes different variants of it. Our proposed solution focuses on these characteristics and tries to uncover targeted campaigns by finding binary semantics between malware found in customer environments and known targeted campaigns.

Our solution strategy is:

Endpoint-security detects a malware sample. It is compared with a sample from a known targeted attack. If the similarity is high, it is a strong indication that the ENS detected sample is a part of that targeted attack and the threat actor is the same.

The strategy is implemented in three building blocks: sample collector, sample storage and targeted attack analysis using third-party threat analytics application.

Sample Collector (GetQuarantine)

Sample collection is performed using McAfee proprietary licensed freeware, GetQuarantine. GetQuarantine is a McAfee e-Policy Orchestrator (ePO) deployable tool that can run on all endpoints protected by McAfee ENS. GetQuarantine runs as an ePO scheduled product deployment task. ENS cleans or deletes items that are detected as threats and saves copies in a non-executable format to the Quarantine folder. The GetQuarantine tool on a scheduled run, checks the quarantine folder and uploads items to the McAfee backend if items are not already uploaded during previous tool runs.

Sample Storage (McAfee Workflow & AWS)

The McAfee workflow backend receives sample submissions from GetQuarantine and stores them in an S3 bucket. Samples are segregated per enterprise and made available for further analysis. Third-party analytics applications like MAGIC can be run on samples to extract targeted attack insights. Analytics services are available to McAfee customers participating in a third-party analytics program. For customers that do not participate in a third-party analytics program, sample processing ends at the McAfee backend layer and the sample eventually gets deleted without further analysis.

Targeted Attack Analysis

For our pilot implementation we used Cythereal MAGIC services. The McAfee backend submits samples to MAGIC for binary similarity analysis. Customers can check analysis reports using Cythereal website. Cythereal is McAfee’s Security Innovation Alliance (SIA) partner.

Cythereal MAGIC™ (malware genomic correlation) is a web-service touted as “BinDiff on Steroids”. The system carries out semantic similarity analysis of programs using advanced program analysis techniques at the assembly instruction-level code. The semantics of the program gives more meaningful insights than structural or behavioral characteristics. MAGIC can find similarity between samples submitted using GetQuarantine and also find variants of those samples from MAGIC’s database. It has the facility to provide alerts for campaign detections and can generate YARA rules that can be used for searching other services, like VirusTotal.

We first tried human-driven in-house analysis using open source tools like SSDEEP, SDHASH, TLSH, etc. to prove the concept of identifying targeted attacks using the binary similarity of samples found in quarantine. Though we were successful in proving this concept with these open source tools, they were not very effective, especially with polymorphic variants, so we explored third-party options and identified Cythereal MAGIC™.

Architecture

Figure 1 shows the overall architecture of our system:

Did You Check Your Quarantine?! 75

[Figure 1: McAfee ENS detects a suspicious sample by studying its behavior or other means and then moves the sample file to the quarantine folder. The scheduled execution of the GetQuarantine Tool configured in ePO as a scheduled task submits the sample to the McAfee backend. The third-party analytics app, periodically receives samples from McAfee backend for further analysis.]

Case Study

For a case study, we used samples from a McAfee discovered campaign, Oceansalt. We tested the solution’s ability to group samples using semantic similarity and also tested the solution’s ability to identify new variants of Oceansalt samples.

Illustration of the Solution’s Ability to Group Malware From Quarantine

McAfee Endpoint Security (ENS) detected two samples of Oceansalt (as listed in Table 1). GetQuarantine submitted these samples to the McAfee backend. Targeted attack analysis of these files showed a semantic similarity of 95.1%. The comparison of their control-flow graphs in Figure 2 justifies the high semantic similarity score.

Did You Check Your Quarantine?! 76

[Table 1: Oceansalt samples reported by McAfee™ security operation center in June-July 2018.]

Did You Check Your Quarantine?! 77

[Figure 2: Control-flow graph of Oceansalt samples from Table 1]

Illustration of the Solution’s Ability to Link New Variants From the Wild to a Known Targeted Attack

Finally, we come to the use case that motivated this study. Malware belonging to a targeted attack is identified by its file-hashes. However, attackers use polymorphism and other obfuscations to create new variants. Though McAfee ENS may block such variants, it may not link it to the original attack. Targeted attack analytics can help fill this void.

To test the solution’s ability to locate such targeted attacks, we uploaded an Oceansalt sample (MD5: 531DEE019792A089A4589C2CCE3DAC95 [VT]) to MAGIC and identified it as an APT. We then uploaded a large number (thousands) of malware samples via GetQuarantine. As we had thought, targeted attack analytics sent an alert that it had detected variants of Oceansalt (Figure 3).

Did You Check Your Quarantine?! 78

[Figure 3: Alert about detecting an Oceansalt variant in the quarantine]

MAGIC’s alert was triggered because it found two Oceansalt variants from the wild which were not previously reported by the McAfee SOC or any other global threat intelligence.

Did You Check Your Quarantine?! 79

[Table 2: Two new variants of Oceansalt samples found using semantic similarity]

Try Your Quarantine

We tested the GetQuarantine-based solution in our lab and found encouraging results. If you would like to try out this solution use the following steps, along with McAfee Endpoint Security (ENS):

  • Download the beta version of GetQuarantine, a proprietary licensed freeware.
  • Deploy it using the ePO ecosystem.
  • On successful sample submission to the McAfee backend, receive an acknowledgment email.

To obtain analysis results from the third-party analytics app, follow these steps:

  • Visit Cythereal MAGIC™.
  • The MAGIC dashboard contains plots with details about various ongoing campaigns.
  • Upon selecting a campaign in the plot, a table with all the associated malware is displayed where the customer can download samples and YARA rules.
  • Whenever MAGIC detects a targeted attack, it sends an alert email to the registered email address of the customer, along with additional threat intelligence, such as information on the threat group, third-party research on the group, and associated IoCs. Customers can also see the list of alerts on the MAGIC website.

Summary

As you can see from this exercise, traditional AV still has lot to offer and can play an important role in overall security strategy againt targeted attacks. We can amplify signals coming out of AV detections using tools like GetQuarantine and by running analytics on quarantine artifacts to uncover targeted attacks. We can take an incremental approach in solving targeted attack challenges.

The post Did You Check Your Quarantine?! appeared first on McAfee Blogs.

iStock-954683756-min-1-300x200.jpg

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 80

Expert Rules are text-based custom rules that can be created in the Exploit Prevention policy in ENS Threat Prevention 10.5.3+. Expert Rules provide additional parameters and allow much more flexibility than the custom rules that can be created in the Access Protection policy. It also allows system administration to control / monitor an endpoint system at a very granular level. Expert rules do not rely on User-Mode hooking; hence they have very minimal impact on a system’s performance. This blog is created as a basic guide to show our customers how to create them and which threats they can help block. Further detailed information can be found in the conclusion.

How Expert Rules work

The following sections show how to add Expert rules via EPO and ENS.

Adding an Expert Rule from EPO

1. Select System Tree | Subgroup (e.g.: ens_10.6.0) | Assigned Policies | Product (Endpoint Security Threat Prevention) | Exploit Prevention (My Default)

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 81

2. Navigate to Signatures and click on Add Expert Rule.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 82

3. In the Rules section, complete the fields.

a. Select the severity and action for the rule. The severity provides information only; it has no select on the rule action.

b. Select the type of rule to create. The Rule content field is populated with the template for the selected type.

c. Change the template code to specify the behavior of the rule.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 83

When you select a new class type, the code in the Rule content field is replaced with the corresponding template code. Endpoint Security assigns the ID number automatically, starting with 20000. Endpoint Security does not limit the number of Expert Rules you can create.

4. Save the rule, then save the settings.

5. Enforce the policy to a client system.

6. Validate the new Expert Rule on the client system.

Adding an Expert Rule directly at the Endpoint:

If we need to add an expert rule from EPO it will be pushed to all endpoints of an entire EPO “WORKGROUP”. There could be situations where expert rules are required to be applied in one/two systems or ENS systems which are not managed by EPO (non-corporate environment where ENS is installed from a standalone setup); in those cases, the expert rule must be added directly at the endpoint. Expert rules can be written and applied directly at the Endpoint system using McAfee Endpoint Security UI. Steps are below:

1. Open McAfee Endpoint Security. Go to Settings.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 84

2. Go to Threat Prevention | Show Advanced.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 85

3. Scroll Down to Expert Rule Section and then click on Add Expert Rule.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 86

4. The expert rule compiler should pop up where an end user can directly write and compile expert rules and, upon compilation, enforce the rules to the system.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 87

If there is no syntax error in the expert rule it can be applied in the system by clicking on the Enforce button. In case there is a syntax error, the details can be found in log file  %ProgramData%McAfeeEndpoint SecurityLogsExploitPrevention_Debug.log

Testing the Rules

When new rules are created, they should first be tested in ‘Report’ mode so that the detections can be observed. When enough confidence in the rule has been gained, it can be turned to ‘Block’ mode.

Expert Rule Examples:

 

Basic Rule:

The following rule will detect an instance of cmd.exe creating any file at c:temp. Please note that cmd.exe might be run by any user and from any part of the system.

Rule {

Process {

Include OBJECT_NAME { -v “cmd.exe” }

}

Target {

Match FILE {

Include OBJECT_NAME { -v “c:temp**” }

Include -access “CREATE”

}

}

}

 

Rules which target specific malicious behavior:

The following rules can be created to help block specific malicious activity which is performed by various malware families and attack techniques.

 

Expert Rule to Block Remote Process Injection [MITRE Technique Process Injection T1055]:

Rule {

Process {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “SYSTEM” }

Exclude OBJECT_NAME { -v “%windir%System32WBEMWMIPRVSE.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32CSRSS.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32WERFAULT.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32SERVICES.EXE” }

Exclude OBJECT_NAME { -v “*GOOGLECHROMEAPPLICATIONCHROME.EXE” }

}

Target {

Match THREAD {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “**MEMCOMPRESSION” }

Exclude OBJECT_NAME { -v “%windir%System32WERFAULT.EXE” }

Include -access “WRITE”

}

}

}

 

Expert Rule which prevents powershell.exe and powershell_ise.exe process from dumping credentials by accessing lsass.exe memory [ MITRE Technique Credential Dumping T1003 ]:

Rule {

Process {

Include OBJECT_NAME {  -v “powershell.exe”  }

Include OBJECT_NAME {  -v “powershell_ise.exe”  }

Exclude VTP_PRIVILEGES -type BITMASK { -v 0x8 }

}

Target {

Match PROCESS {

Include OBJECT_NAME {   -v  “lsass.exe”  }

Include -nt_access “!0x10”

Exclude -nt_access “!0x400”

}

}

}

 

Expert Rule which prevents creation of a suspicious task (PowerShell script or batch file) using “SchTasks.exe” utility [MITRE Technique Scheduled Task T1053]:

Rule {

Process {

Include OBJECT_NAME { -v  “SchTasks.exe” }

Include PROCESS_CMD_LINE { -v “*/Create*” }

}

Target {

Match PROCESS {

Include PROCESS_CMD_LINE { -v “**.bat**” }

}

Match PROCESS {

Include PROCESS_CMD_LINE { -v “**.ps1**” }

}

}

}

 

Expert Rule to prevent Start Up Entry Creation [ MITRE Technique Persistence T1060]:

Adversaries can use several techniques to maintain persistence through system reboots. One of the most popular techniques is creating entries in the Start Up folder. The following expert rule will prevent any process from creating files in the Start Up folder. Recently, the internet has witnessed a full-fledged exploit of a decade old WinRAR vulnerability (CVE-2018-20251) which can be exploited by dropping files in the Start Up directory. The following expert rule will also block such an attempt.

Rule {

Process {

Include OBJECT_NAME { -v ** }

}

Target {

Match FILE {

Include OBJECT_NAME { -v “**AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup**” }

Include -access “CREATE WRITE”

}

}

}

 

Expert Rule which blocks JavaScript Execution within Adobe Reader:

Exploiting a client-side software vulnerability to gain an initial foothold in a network is not new [MITRE Technique T1203]. Adobe Reader is a very popular target because, like any other browser, it supports JavaScript which makes exploitation much easier. The following expert rule can be deployed in any network to prevent Adobe Reader from executing any kind of JavaScript.

Rule {

Process {

Include OBJECT_NAME { -v “AcroRd32.exe”}

}

Target {

Match SECTION {

Include OBJECT_NAME { -v “EScript.api” }

}

}

}

The table below shows how the above four Expert Rules line up in the Mitre Att&ck matrix.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits 88

Conclusion

There are many more rules which can be created within Exploit Prevention (part of McAfee’s ENS Threat Prevention) and they can be customized depending on the customer’s environment and requirements. For example, the Expert Rule which blocks JavaScript Execution within Adobe Reader will be of no use if an organization does not use “Adobe Reader” software. To fully utilize this feature, we recommend our customers read the following guides:

https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/27000/PD27227/en_US/ens_1053_rg_ExpertRules_0-00_en-us.pdf

https://kc.mcafee.com/corporate/index?page=content&id=KB89677

 

Disclaimer: The expert rules used here as examples can cause a significant number of False Positives in some environments, hence we recommend those rules to be explicitly applied only in an environment where better visibility of above (or similar) events at granular level is required.

Acknowledgement:

The author would like to thank following colleagues for their help and inputs authoring this blog.

  • Oliver Devane
  • Abhishek Karnik
  • Cedric Cochin

The post Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits appeared first on McAfee Blogs.

iStock-954683756-min-1-300x200-2.jpg

Using Expert Rules in ENS to Prevent Malicious Exploits

Using Expert Rules in ENS to Prevent Malicious Exploits 89

Expert Rules are text-based custom rules that can be created in the Exploit Prevention policy in ENS Threat Prevention 10.5.3+. Expert Rules provide additional parameters and allow much more flexibility than the custom rules that can be created in the Access Protection policy. It also allows system administration to control / monitor an endpoint system at a very granular level. Expert rules do not rely on User-Mode hooking; hence they have very minimal impact on a system’s performance. This blog is created as a basic guide to show our customers how to create them and which threats they can help block. Further detailed information can be found in the conclusion.

How Expert Rules work

The following sections show how to add Expert rules via EPO and ENS.

Adding an Expert Rule from EPO

1. Select System Tree | Subgroup (e.g.: ens_10.6.0) | Assigned Policies | Product (Endpoint Security Threat Prevention) | Exploit Prevention (My Default)

Using Expert Rules in ENS to Prevent Malicious Exploits 90

2. Navigate to Signatures and click on Add Expert Rule.

Using Expert Rules in ENS to Prevent Malicious Exploits 91

3. In the Rules section, complete the fields.

a. Select the severity and action for the rule. The severity provides information only; it has no select on the rule action.

b. Select the type of rule to create. The Rule content field is populated with the template for the selected type.

c. Change the template code to specify the behavior of the rule.

Using Expert Rules in ENS to Prevent Malicious Exploits 92

When you select a new class type, the code in the Rule content field is replaced with the corresponding template code. Endpoint Security assigns the ID number automatically, starting with 20000. Endpoint Security does not limit the number of Expert Rules you can create.

4. Save the rule, then save the settings.

5. Enforce the policy to a client system.

6. Validate the new Expert Rule on the client system.

Adding an Expert Rule directly at the Endpoint:

If we need to add an expert rule from EPO it will be pushed to all endpoints of an entire EPO “WORKGROUP”. There could be situations where expert rules are required to be applied in one/two systems or ENS systems which are not managed by EPO (non-corporate environment where ENS is installed from a standalone setup); in those cases, the expert rule must be added directly at the endpoint. Expert rules can be written and applied directly at the Endpoint system using McAfee Endpoint Security UI. Steps are below:

1. Open McAfee Endpoint Security. Go to Settings.

Using Expert Rules in ENS to Prevent Malicious Exploits 93

2. Go to Threat Prevention | Show Advanced.

Using Expert Rules in ENS to Prevent Malicious Exploits 94

3. Scroll Down to Expert Rule Section and then click on Add Expert Rule.

Using Expert Rules in ENS to Prevent Malicious Exploits 95

4. The expert rule compiler should pop up where an end user can directly write and compile expert rules and, upon compilation, enforce the rules to the system.

Using Expert Rules in ENS to Prevent Malicious Exploits 96

If there is no syntax error in the expert rule it can be applied in the system by clicking on the Enforce button. In case there is a syntax error, the details can be found in log file  %ProgramData%McAfeeEndpoint SecurityLogsExploitPrevention_Debug.log

Testing the Rules

When new rules are created, they should first be tested in ‘Report’ mode so that the detections can be observed. When enough confidence in the rule has been gained, it can be turned to ‘Block’ mode.

Expert Rule Examples:

 

Basic Rule:

The following rule will detect an instance of cmd.exe creating any file at c:temp. Please note that cmd.exe might be run by any user and from any part of the system.

Rule {

Process {

Include OBJECT_NAME { -v “cmd.exe” }

}

Target {

Match FILE {

Include OBJECT_NAME { -v “c:temp**” }

Include -access “CREATE”

}

}

}

 

Rules which target specific malicious behavior:

The following rules can be created to help block specific malicious activity which is performed by various malware families and attack techniques.

 

Expert Rule to Block Remote Process Injection [MITRE Technique Process Injection T1055]:

Rule {

Process {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “SYSTEM” }

Exclude OBJECT_NAME { -v “%windir%System32WBEMWMIPRVSE.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32CSRSS.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32WERFAULT.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32SERVICES.EXE” }

Exclude OBJECT_NAME { -v “*GOOGLECHROMEAPPLICATIONCHROME.EXE” }

}

Target {

Match THREAD {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “**MEMCOMPRESSION” }

Exclude OBJECT_NAME { -v “%windir%System32WERFAULT.EXE” }

Include -access “WRITE”

}

}

}

 

Expert Rule which prevents powershell.exe and powershell_ise.exe process from dumping credentials by accessing lsass.exe memory [ MITRE Technique Credential Dumping T1003 ]:

Rule {

Process {

Include OBJECT_NAME {  -v “powershell.exe”  }

Include OBJECT_NAME {  -v “powershell_ise.exe”  }

Exclude VTP_PRIVILEGES -type BITMASK { -v 0x8 }

}

Target {

Match PROCESS {

Include OBJECT_NAME {   -v  “lsass.exe”  }

Include -nt_access “!0x10”

Exclude -nt_access “!0x400”

}

}

}

 

Expert Rule which prevents creation of a suspicious task (PowerShell script or batch file) using “SchTasks.exe” utility [MITRE Technique Scheduled Task T1053]:

Rule {

Process {

Include OBJECT_NAME { -v  “SchTasks.exe” }

Include PROCESS_CMD_LINE { -v “*/Create*” }

}

Target {

Match PROCESS {

Include PROCESS_CMD_LINE { -v “**.bat**” }

}

Match PROCESS {

Include PROCESS_CMD_LINE { -v “**.ps1**” }

}

}

}

 

Expert Rule to prevent Start Up Entry Creation [ MITRE Technique Persistence T1060]:

Adversaries can use several techniques to maintain persistence through system reboots. One of the most popular techniques is creating entries in the Start Up folder. The following expert rule will prevent any process from creating files in the Start Up folder. Recently, the internet has witnessed a full-fledged exploit of a decade old WinRAR vulnerability (CVE-2018-20251) which can be exploited by dropping files in the Start Up directory. The following expert rule will also block such an attempt.

Rule {

Process {

Include OBJECT_NAME { -v ** }

}

Target {

Match FILE {

Include OBJECT_NAME { -v “**AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup**” }

Include -access “CREATE WRITE”

}

}

}

 

Expert Rule which blocks JavaScript Execution within Adobe Reader:

Exploiting a client-side software vulnerability to gain an initial foothold in a network is not new [MITRE Technique T1203]. Adobe Reader is a very popular target because, like any other browser, it supports JavaScript which makes exploitation much easier. The following expert rule can be deployed in any network to prevent Adobe Reader from executing any kind of JavaScript.

Rule {

Process {

Include OBJECT_NAME { -v “AcroRd32.exe”}

}

Target {

Match SECTION {

Include OBJECT_NAME { -v “EScript.api” }

}

}

}

The table below shows how the above four Expert Rules line up in the Mitre Att&ck matrix.

Using Expert Rules in ENS to Prevent Malicious Exploits 97

Conclusion

There are many more rules which can be created within Exploit Prevention (part of McAfee’s ENS Threat Prevention) and they can be customized depending on the customer’s environment and requirements. For example, the Expert Rule which blocks JavaScript Execution within Adobe Reader will be of no use if an organization does not use “Adobe Reader” software. To fully utilize this feature, we recommend our customers read the following guides:

https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/27000/PD27227/en_US/ens_1053_rg_ExpertRules_0-00_en-us.pdf

https://kc.mcafee.com/corporate/index?page=content&id=KB89677

 

Disclaimer: The expert rules used here as examples can cause a significant number of False Positives in some environments, hence we recommend those rules to be explicitly applied only in an environment where better visibility of above (or similar) events at granular level is required.

Acknowledgement:

The author would like to thank following colleagues for their help and inputs authoring this blog.

  • Oliver Devane
  • Abhishek Karnik
  • Cedric Cochin

The post Using Expert Rules in ENS to Prevent Malicious Exploits appeared first on McAfee Blogs.

labs-thumbnail-3-300x169-2.jpeg

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 98

Episode 4: Crescendo

This is the final installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandGrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid 2019.

In this final episode of our series we will zoom in on the operations, techniques and tools used by different affiliate groups spreading Sodinokibi ransomware.

Since May we have observed several different modus operandi by different affiliates, for example:

  • Distributing the ransomware using spear-phishing and weaponized documents
  • Bat-files downloading payloads from Pastebin and inject them into a process on the operating system
  • Compromising RDP and usage of script files and password cracking tools to distribute over the victim’s network
  • Compromise of Managed Service Providers and usage of their distribution software to spread the ransomware

To understand more about how this enemy operates, we in McAfee Advanced Threat Research (ATR) decided to operate a global network of honeypots. We were aware of the lively underground trade market of RDP credentials and were curious about what someone would do with a compromised machine. Would they distribute the Sodinokibi ransomware? Would they execute the DejaBlue or BlueKeep exploits? Our specially designed and built RDP honeypots would give us those insights.

Like Moths to a Flame

From June until September 2019, we observed several groups compromise our honey pots and conduct activities related to Sodinokibi; we were able to fully monitor attackers and their actions without their knowledge.

It is important to note the golden rule we operated under: the moment criminal actions were prepared or about to be executed, the actor would be disconnected and the machine would be restored to its original settings with a new IP address.

We noticed some of our honeypot RDP servers were attacked by Persian-speaking actors that were actively harvesting credentials. Our analysis of these attacks led us to various Persian underground channels offering the same tools we observed appearing in Sodinokibi intrusions. Some of these tools are closed source and custom made, originating from within the channels in our analysis.

In this blog we will highlight a few of the intrusions we observed.

Group 1 – Unknown Affiliate ID

McAfee ATR observed initial activity against our South American honey pot begin in late May 2019. We had full visibility as the actor loaded a number of tools, including Sodinokibi, during the initial intrusion period.

The following ransom note (uax291-readme.txt) was dropped onto the system on June 10th, 2019. The actor utilized Masscan and NLBrute to scan and target other assets over RDP which fits with the behavior we have seen in all other Sodinokibi intrusions tracked by McAfee ATR. The actor then created a user account ‘backup’ and proceeded to consistently connect from an IP address range in Belgrade, Serbia.

Group 2 – Affiliate ID 34

Campaign 295 (based on sub-ID in the malware configuration)

The following Sodinokibi variant appeared in our South American honey pot with the original file name of H.a.n.n.a.exe.

  • 58C390FE5845E2BB88D1D22610B0CA61 (June 8th, 2019)

Extracting the configuration from the ransomware sample as we conducted during our affiliate research, the affiliate-id is nr 34.

Upon initial intrusion, the actor created several user accounts on the target system between June 10th and June 11th.  The malware Sodinokibi and credential-harvesting tool Mimikatz were executed under the user account “ibm” that the actor created as part of the entry into the system

Further information revealed that the actor was connecting from two IP addresses in Poland and Finland via the ‘ibm’ account. These logins originated from these countries in a 24hr period between July 10th and 11th with the following two unique machine names WIN-S5N2M6EGS5J and TS11. Machine name WIN-S5N2M6EGS5J was observed to be used by another actor that created the account “asp” and originated from the same Polish IP address.

The actor deployed a variant of the Mimikatz credential harvester during the intrusion, with the following custom BAT file:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 99

We have seen a consistent usage of various custom files used to interact with hacking tools that are shared among the underground communities.

Another tool, known as Everything.exe, was also executed during the same period. This tool was used to index the entire file system and what was on the target system. This tool is not considered malicious and was developed by a legitimate company but can be used for profiling purposes. The usage of reconnaissance tools to profile the machine is interesting as it indicates potential manual lateral movement attempts by the actor on the target system.

July 20th to 30th Intrusion

Activity observed during this period utilized tools similar to those used in other intrusions we have observed in multiple regions, including those by Affiliate ID 34.

In this activity McAfee ATR identified NLBrute being executed again to target victims over RDP; a pattern we have seen over and over again in intrusions involving Sodinokibi.  A series of logins from Iran were observed between July 25th and July 30th, 2019.

We have also seen crypto currency mining apps deployed in most of the intrusions involving Sodinokibi, which may suggest some interesting side activity for these groups. In this incident we discovered a miner gate configuration file with a Gmail address.

Using Open-Source Intelligence (OSINT) investigation techniques, we identified an individual that is most likely tied to the discovered Gmail address. Based on our analysis, this individual is likely part of some Persian-speaking credential cracking crew harvesting RDP credentials and other types of data. The individual is sharing information related to Masscan and Kport scan results for specific countries that can be used for brute force operations.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 100

ACTOR PROFILE

Further, we observed this actor on a Telegram channel discussing operations which align to the behavior we observed during intrusions on our honey pot. The data shared appears to be results from tools such as Masscan or Kport-scan that would be used to compromise further assets.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 101

DISCUSSION OF SCANNING IN FARSI, ON PRIVATE CHANNEL

Other tools were found to have been executed the same day as the activity documented include:

  • Mimikatz

Was executed manually from the command line with the following parameters:

mimikatz.exe “privilege::debug” “sekurlsa::logonPasswords full” “exit”

  • Slayer Leecher
  • MinerGate

Group 3 – Affiliate ID 19

We observed the following Sodinokibi ransom variants attributed to this affiliate appearing in the honey pot in the Middle East. The attacker downloaded a file, ابزار کرک.zip, which can be mostly found in Farsi language private channels. The tool is basically a VPS Checker (really an RDP cracker) as discussed on the channels in the underground.

Campaign 36

Activity from June 3rd to 26th indicates that the attacker present on the system was conducting operations involving the Sodinokibi ransomware. When linking back activity, we observed one notable tool the actor had used during the operation.

‘Hidden-User.bat’ was designed to create hidden users on the target system. This tool links back to some underground distribution on Farsi-speaking private channels.

The file being shared is identical to the one we found to be used actively in the Sodinokibi case in different instances in June 2019, in different cities in the Middle East. We found the following Farsi-speaking users sharing and discussing this tool specifically (Cryptor007 and MR Amir), and others active in these groups. McAfee ATR observed this tool being used on June 13th, 2019 and June 26th, 2019 by the same actors in different regions.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 102

HIDDEN-USER.bat

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 103

POSTED IMAGE OF THE TOOL IN USE

These Sodinokibi variants are strictly appearing in Israel from our observations:

  • 009666D97065E97FFDE7B1584DB802EB (June 3rd, 2019)
  • 3746F1823A47B4AA4B520264D1CF4606 (June 11th, 2019)

We observed the actor dropping one of the above-mentioned variants of Sodinokibi. In this case, the login came from an IP address originating in Iran and with a machine with a female Persian name.

The attackers connecting are most likely Farsi-speaking, as is evident by the browsing history uncovered by McAfee ATR, which indicates where a number of the tools utilized originate from, including Farsi language file sharing sites, such as Picofile.com and Soft98.ir, that contain malicious tools such as NLBrute, etc.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 104

FARSI LANGUAGE SITE FOUND IN BROWSING HISTORY

We observed the actor attempting to run an RDP brute force attack using NLBrute downloaded from the Iranian site Picofile.com. The target was several network blocks in Oman and the United Arab Emirates in the Middle East.

In our analysis we discovered an offer to install ransomware on servers posted in Farsi speaking on August 19th,. This posting date corresponds with the timing of attacks observed in the Middle East. The services mentioned are specifically targeting servers that have been obtained via RDP credential theft campaigns. It is possible that these actors are coming in after the fact and installing ransomware on behalf of the main organizer, according to actor chatter. One specific Farsi language message indicates these services for a list of countries where they could install ransomware for the potential client.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo 105

FARSI LANGUAGE MESSAGE FROM PERSIAN LANGUAGE CHANNEL

Tools and Methods of Group 1

The operators responsible for intrusions involving Sodinokibi variants with an unknown affiliate ID utilize a variety of methods:

  • Initial intrusions made over RDP protocol
  • Using Masscan to identify potential victims
  • Executing NLBrute with custom password lists

Tools and Methods of Group 2

The operators responsible for intrusions involving Sodinokibi variants with PID 34 utilize a variety of methods:

  • Intrusion via RDP protocol
  • Manual execution of subsequent stages of the operation
  • Deployment of Sodinokibi
  • Deployment of Mimikatz
  • Utilization of CryptoCurrency mining
  • Deployment of other brute force and checker tools
  • Running mass port scans and other reconnaissance activities to identify potential targets
  • Executing NLBrute with custom password lists
  • Some of the operators appear write in Farsi and are originating from Iranian IP address space when connecting to observed targets

Tools and Methods of Group 3

The operators responsible for intrusions involving Sodinokibi variants with PID 19 utilize a variety of methods:

  • Intrusion via RDP protocol
  • Manual execution of subsequent stages of the operation
  • Likely a cracking crew working on behalf of an affiliate
  • Deployment of Sodinokibi
  • Custom scripts to erase logs and create hidden users
  • Usage of Neshta to scan internal network shares within an organization in an effort to spread Sodinokibi
  • Running mass port scans and other reconnaissance activities to identify potential targets
  • Limited use of local exploits to gain administrative access
  • Executing NLBrute with custom password lists
  • Some of the operators appear to write in Farsi and are originating from Iranian IP address space when connecting to observed targets

Conclusion

In our blog series about Sodinokibi we began by analyzing the code. One of our observations was that like GandCrab, the Romanian and Persian languages are blacklisted. If these two languages, amongst others, are installed on a victim’s machine, the ransomware would not execute. We asked ourselves the question, “Why Persian?” With the information retrieved from our honeypot investigations, it might give us a hypothesis that the Persian language is present due to the involvement of Persian-speaking affiliates. Would that also count for the Romanian language? Time and evidence will tell.

We observed many affiliates using different sets of tools and skills to gain profit and, across the series, we highlighted different aspects of this massive ongoing operation.

To protect your organization against Sodinokibi, make sure your defense is layered. As demonstrated, the actors we are facing either buy, brute-force or spear-phish themselves into your company or use a trusted-third party that has access to your network. Some guidelines for organizations to protect themselves include employing sandboxing, backing up data, educating their users, and restricting access.

As long as we support the ransomware model, ransomware will exist as it has for the last four years. We cannot fight alone against ransomware and have to unite as public and private parties. McAfee is one of the founding partners of NoMoreRansom.org and are supporting Law Enforcement agencies around the globe in fighting ransomware.

 

We hope you enjoyed reading this series of blogs about Sodinokibi.

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo appeared first on McAfee Blogs.

Network-of-internet-of-things-attacked-by-a-hacker-on-one-node-3D-illustration-768x432-300x169-2.jpg

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 106

Episode 3: Follow the Money

This is the third installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandCrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid 2019.

The Talking Heads once sang “We’re on a road to nowhere.” This expresses how challenging it can be when one investigates the financial trails behind a RaaS scheme with many affiliates, etc.

However, we persisted, and we prevailed. By linking underground forum posts with bitcoin transfer traces, we were able to uncover new information on the size of the campaign and associated revenue; even getting detailed insights into what the affiliates do with their earnings following a successful attack.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 107

With the Sodinokibi ransomware a unique BTC wallet is generated for each victim. As long as no payment is made, no trace of the BTC wallet will be available on the blockchain. The blockchain operates as a public ledger of all bitcoin transactions that have happened. When no currencies are exchanged, no transactions are recorded. Although many victims hit the news, we understand that if they paid, sharing that with the research community is maybe a bridge too far. On one of the underground forums we discovered the following post:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 108

In this post the actors are expanding their successful activity and offering a 60 percent cut as a start and, after three successful payments by the affiliate (read successful ransomware infections and payments received from the victims), the cut increases to 70 percent of the payments received. This is very common as we saw in the past with RaaS schemes like GandCrab and Cryptowall.

Responding to this post is an actor with the moniker of ‘Lalartu’ and his comments are quite interesting, hinting he was involved with GandCrab. As a site-note: “Lalartu’ means ‘ghost/phantom’. Its origins are from the Sumerian civilization where Lalartu was seen as a vampiric demon.

Researching the moniker of ‘Lalartu’ through our data, we went back in time a month or so and discovered a posting from the actor on June 4th of 2019, again referencing GandCrab.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 109

We observe here a couple of transaction IDs (TXID) on the bitcoin ledger, however they are incomplete. More than a week later, on June 17th, 2019, “Lalartu” posted another one with an attachment to it:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 110

 

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 111

In this posting we see a screenshot with partial TXIDs and the amounts. With the help of the Chainalysis software and team, we were able to retrieve the full TXIDs. With that list we were able to investigate the transactions and start mapping them out with their software:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 112

From the various samples we have researched, the amounts asked for payment are between 0.44 and 0.45 BTC, an average of 4,000 USD.

In the above screenshot we see the transactions where some of these amounts are transferred from a wallet, or bitcoins are bought at an exchange and transferred to the wallets associated with the affiliate(s).

Based on the list shared by Lalartu in his post, and the average value of bitcoin around the dates, within 72 hours a value of 287,499.00 USD of ransom had been transferred.

Taking the list of transactions as a starting point in our graph-analysis, we colored the lines red and started from there to investigate the wallets involved and interesting transactions:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 113

Although it might look like spaghetti, once you dive in, very interesting patterns can be discovered. We see victims paying to their assigned wallets; from there it takes an average of two to three transactions before it goes to an ‘affiliate’ or ‘distribution’ wallet. From that wallet we see the split happening as the moniker ‘UNKN’ mentioned in his forum post we started this article with. The 60 or 70 percent stays with the affiliate and the remaining 40/30 percent is forwarded in multiple transactions towards the actors behind Sodinokibi.

Once we identified a couple of these transactions, we started to dig in both directions. What is the affiliate doing with the money and where is the money going for the Sodinokibi actors?

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 114

We picked one promising affiliate wallet and started to dig deeper down and followed the transactions. As described above, the affiliate is getting money transferred mostly through an exchange (since this is being advised by the actors in the ransom note). This is what we see in the example below. Incoming ransomware payments via Coinbase.com are received. The affiliate seems to pay some fee to a service but also sends BTC into Bitmix.biz a popular underground bitcoin mixer that is obfuscating the next transactions to make it difficult to link the transactions back to the ‘final’ wallet or cash-out in a (crypto) currency.

We also observed examples where the affiliates were paying for services, they bought on Hydra Market. Hydra Market is a Russian underground marketplace where many services and illegal products are offered with payment in BTC.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 115

Tracing down the route of splits, we started to search for the 30 or 40 percent cuts of the ransom payments of 0.27359811 BTC or, if the price was doubled, 0.54719622 BTC.

Using the list of amounts and querying the transactions and transfers discovered, we observed a wallet that was receiving a lot of these smaller payments. Due to ongoing research we will not publish the wallet but here is a graph representation of a subset of transactions:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money 116

It seems like a spider, but many incoming ‘split’ transfers, and only a few outgoing ones with larger amounts of bitcoins, were observed.

If we take the average of $2,500 – $5,000 USD as a ransom ask, and the mentioned split of 30/40 percent for the actor maintaining the Sodinokibi ransomware and affiliate infrastructure, they make $700 – $1,500 USD per paid infection.

We already saw in the beginning of this article that the affiliate Lalartu claimed to have made 287k USD in 72 hours, which is an 86k USD profit for the actor from one affiliate only.

In episode 2, The All-Stars, we explained how the structure is setup and how each affiliate has its own id.

As far as we tracked the samples and extracted the amount of id-numbers, we counted over 41 affiliates being active. The data showed a in a relatively short amount of time the velocity and number of infections was high. Taken this velocity combined with a few payments per day, we can imagine that the actors behind Sodinokibi are making a fortune.

Following the traces of one particular affiliate, we ended up seeing large amounts of bitcoins being transferred into a wallet which had a total value of 443 BTC, around 4,5 million USD with the average bitcoin price.

We do understand that there are situations in which executives decide to pay the ransom but, by doing that, we keep this business model alive and also fund other criminal markets.

Conclusion

In this blog we focused on insights into the financial streams behind ransomware. By linking underground forum posts with bitcoin transfer traces, we were able to uncover new information on the size of the campaign and associated revenue. In some cases, we were able even to get detailed insights into what the affiliates do with their earnings following a “successful” attack. It shows that paying ransomware is not only keeping the ‘ransom-model’ alive but is also supporting other forms of crime.

In the next and final episode, “Crescendo” McAfee ATR reveals insights gleaned from a global network of honey pots.

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money appeared first on McAfee Blogs.

Vox Messenger Logo - 512x512

End-2-End Encrypted. Secure. Ad-Free.
Lightweight and Faster than the Competition.

Vox Messenger is an ad-free, secure and end-2-end encrypted alternative to other popular chat messenger apps.

Available for Free. Whitelabel Corporate Edition Available on Request.

Vox Messenger {Secure} - Communicate safely with our private and secure messaging app | Product Hunt Embed

All Rights Reserved - © Copyright 2020 - Vox Messenger (a Division of Kryotech Ltd.)