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.

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:

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 4^th of 2019, again referencing GandCrab.

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

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:

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:

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?

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.

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:

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.

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 10^th, 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 8^th, 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 10^th and June 11^th.  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 10^th and 11^th 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:

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 20^th to 30^th 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 25^th and July 30^th, 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.

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.

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 3^rd to 26^th 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 13^th, 2019 and June 26^th, 2019 by the same actors in different regions.

HIDDEN-USER.bat

POSTED IMAGE OF THE TOOL IN USE

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

• 009666D97065E97FFDE7B1584DB802EB (June 3^rd, 2019)
• 3746F1823A47B4AA4B520264D1CF4606 (June 11^th, 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.

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 19^th,. 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.

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.

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)

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

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.

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.

2. Go to Threat Prevention | Show Advanced.

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

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.

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%\McAfee\Endpoint Security\Logs\ExploitPrevention_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%\\System32\\WBEM\\WMIPRVSE.EXE” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\CSRSS.EXE” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\WERFAULT.EXE” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\SERVICES.EXE” }

Exclude OBJECT_NAME { -v “*\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE” }

}

Target {

Match THREAD {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “**\\MEMCOMPRESSION” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\WERFAULT.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 “**\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\**” }

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.

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.

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:

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

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

[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).

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

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

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:

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.

The HTML code which plays the recording is shown below:

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.

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

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:

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.

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:

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.

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:

[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:

• 16Shop now targets Amazon
• How to recognize and protect yourself from phishing
• New Wave of Browser Hijackers and How to Protect Your Environment
• How to Spot Phishing Lures
• Don’t get hooked – phishing email advice for your employees

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

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:

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:

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.

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.

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.

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.

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.

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

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:

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:

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.

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 2^nd version of Buran will identify the victim using random values.

FIGURE 10. GENERATE RANDOM VALUES

After that it will decrypt a registry subkey called “Software\Buran\Knock” 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:

FIGURE 11. SPECIAL USER AGENT BURAN

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:

Blacklisted files in Buran:

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:

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:

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 2^nd version of Buran one of the main things added is the deletion of the shadow copies using WMI.

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

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:

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.

The ransom note changed between versions:

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:

Similarities in Behavior:

Files stored in the temp folder:

VegaLocker:

Jumper:

Buran:

Registry changes:

VegaLocker:

Buran:

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:

Indicators of Compromise

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.

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:

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.

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:

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:

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.

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

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:

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:

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:

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.

YARA RULE

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

IOCs

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

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 a 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:

Figure 1 RDP access to a Canadian factory is being offered

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.” ¹ 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.

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:

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

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:

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

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.

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:

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:

\\Users\\Usuario\\Documents\\Proyectos\\sher.lock\\Debug\\LooCipher.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:

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

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:

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:

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.

LooCipher and Network Traffic:

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

The data sent to the server is:

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:

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:

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

e1200cb52d52855abfbc0c2dddefdf737fe187a8

b4380cc94fa7319877c381f76c260fcc4e3a7078

3aa1a0fa9db50294873335144b42562af23d7b27

7e1dc07f454cc615e36830a29e82694934840af0

bd430b7387f38c7126cd6e69fa638b437101f7de

49b86dd0a20e9a1c6ed5fd310507f4c3fe3930e0

86e72cfefde89c074f7ea5593818bc70e836ea4a

dc92d7fe3638632819b5895a7be9d474cfc90bd7

b11898dec3bcb95e0e152e938896be59ebf19544

35a91e97fc73c15d686ad78e05eff37eee7d25d3

2c781a50102725d42e7c61e56f336fc070f8f8d1

5e06c80c56e080f93d16edb7c0bed4b8aea8de2b

3d84f4091946b95ef1e9adb78b8c109925a31d32

50c4d99bd876f843833114887da4585563dd852f

674da4f22fcbbc28d8bb4c7f15b07a7ad3e32785

da1237ded3073e4c2e9ac840def641a37a3d13e5

365943cf84c05a8ff2f9b12fc1b79e4676914df0

3396d8f3195175196ba642c1d82b431ed2d9461a

10ce0d2f2cd0351ef6cac4b690c46b45b27652a1

44fccc7fac106aa8ff9e4244a255de9f55023da2

102318b5c8cd5464bfdd43c7108020e21f009c78

19d4708a9cd411c283992adf26ddf14a0c27e924

1e99e83d78df1bf1eeeb1d0df24a4680333c0ef7

0920d949ace0e1259bd0e035f450f9475c9f3a05

082e8ee73b6b1a828a299941bd1d65a259dbb71f

82c4bb136c75ec4e3a01693f0d1a930b4bf596e0

ecbee10531ab298a56606216d5a43078f7537c25

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

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

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

There are number of ways scammers use to target your money or personal details.  These scams include support sites for services such as Office365, iCloud, Gmail, etc. They will charge you for the service and steal your credit card details. Software activation scam sites will steal your activation code and they may resell it at a low cost.

There have been many articles about these types of scams, including one we posted earlier this year about support scams – https://securingtomorrow.mcafee.com/consumer/consumer-threat-notices/mcafee-customer-support-scam.

In this article, we would like to provide more examples of the scam sites and tips to help you spot them and avoid entering your personal information.

Scam sites may include these major services’ names in their domains, and include links for the official sites, to appear like legitimate (authorized) support for these companies.

The screenshots below are examples of various types of scam sites.

This one is an example of a software activation scam site. It targets users who are confused about how to set up their software. As shown below, the scammer asks users to enter their personal information and the activation key, pretending to help with the software setup.

On the same page, it provides the details on how to find the activation key and how to set up the software.

After following these steps and entering the personal information, you get an error as shown in the screen shot below.

At this time, the scammer has already received the user’s information, which could then be used for financial gain. As the error occurs, they expect the user to call the numbers above and they will charge the user for that call, even though they can get the same service for free from the respective software companies. This activation code can then be sold at a low cost on pirated software sites.

When you encounter a site which you suspect to be a support scam, try Googling its phone number. You may be surprised that a lot more of other support scam sites with the same phone number will appear in the results. In this example, the same number is linked to at least 4 other support scams.

For these sites, they have the same appearance as shown in the screenshot below.

The below screenshot shows a typical scam site that tries to mimic the official site but is not as professional. It only provides the phone number and contact form, and nothing else.

Users may encounter these sites in various ways:

• By clicking on links from unsolicited emails.
• From pop-up ads from risky sites such as illegal movie streams.
• Ad campaign pop-ups from otherwise legitimate sites that have had malicious ads injected or not thoroughly vetted.
• Advertised in online classified ads, forum posts and blog sites.
• Advertised in Social media sites such as Facebook, Reddit, YouTube and Tumblr.

One way to be sure that you have the correct contact information is to get it from the legitimate website.  When you search for the contact information, always make sure that the search result shows the link to the respective organization.  Please be aware that this may not always come up on top of your search.

When you click the link in the search result, make sure that you land on the expected site.

Advice to Consumers:

Online users should be careful in their choices of trying to get technical support and activation setup.

Consumers should be aware that these companies will not send unsolicited email messages or unsolicited phone calls to request users’ personal or financial information to offer technical support to fix their computer or for activation setup.

As highlighted in this blog, a user will often be presented with a fake error screen to be tricked into calling a premium rate phone number. Warnings or error messages from legitimate companies never include their phone numbers.

Users do not have to pay for such a service which they can get from the respective companies directly for free. Also, software companies will never ask you to pay with Bitcoin or gift cards. Users should only use the official website and, if unsure, they should contact the official website via its contact form.

These tech support domains may be registered in various countries. Their lifespan may be short, like a year or two. Just for the examples listed in this article, the average domain life cycle was 2.1 years. They mimic the look and feel of the official web sites by copying the logo and other graphics, but they are often not quite as professional looking as the official ones.

If you find suspected scam sites, please submit them to McAfee for review at https://trustedsource.org as well as reporting to your local law enforcement.

The Below Discovered and Analyzed URLs are Covered By WebAdvisor

hxxps://www-norton-com-setup.xyz
hxxp://nortoncomsetup.co/
<hxxp://mcafeeactivate.support
hxxp://www.yourpcassistant.com
hxxp://manage-norton-setup.com/
hxxp://contacttechassistance.com/
hxxps://i123hp.com
hxxps://canon.com-ijsetup.com
hxxp://www.mydragonsupport.com
hxxps://www.retail-cards.com/
hxxps://wwwofficesetup.com/
hxxps://how-tosetup.com/
hxxps://www.sbcglobalsupportnumber.com
hxxps://acersupportnumber.com
hxxps://www.canonsupportnumber.org/
hxxps://applesupportnumber.net/
hxxp://mssetup.com
hxxp://officecomsetup.support
hxxp://wwwofficesetup.com
hxxp://howtoactivatemcafee.com
hxxp://www-mcafee-com-activate.co.uk

The post Top Tips to Spot Tech Support Scams appeared first on McAfee Blogs.

This week McAfee Advanced Threat Research (ATR) published new findings, uncovering security flaws in two popular IoT devices: a connected garage door opener and a “smart” ring, which, amongst many uses, utilizes near field communication (NFC) to open door locks.

I’d like to use these cases as examples of a growing concern in the area of product security. The industry of consumer devices has seen some positive momentum for security in recent years. For example, just a few years back, nearly every consumer-grade router shipped with a default username and password, which, if left unchanged, represented a serious security concern for home networks. At a minimum, most routers at least now ship with a unique password printed on the physical device itself, dramatically increasing the overall network security. Despite positive changes such as this, there is a long way to go.

If we think about the history of garage doors, they began as a completely manual object, requiring the owner to lift or operate it physically. The first overhead garage door was invented in the early 1920s, and an electric version came to market just a few years later. While this improved the functionality of the device and allowed for “remote” entry, it wasn’t until many years later that an actual wireless remote was added, giving consumers the ability to allow wireless access into their home. This was the beginning of an interesting tradeoff for consumers – an obvious increase in convenience which introduced a potential new security concern.

The same concept applies to the front door. Most consumers still utilize physical keys to secure the front door to their homes. However, the introduction of NFC enabled home door locks, which can be opened using compatible smart rings, adds both convenience and potentially compromised security.

For example, upon investigating the McLear NFC Ring, McAfee ATR uncovered a design insecurity, which could allow an attacker to easily clone the NFC Ring and gain entry to a home utilizing an NFC enabled smart lock.

While the NFC Ring modernizes physical household security, the convenience that comes with technology implementation also introduces a security issue.

The issue here is at a higher level; where and when do we draw the line for convenience versus security? The numerous benefits technology enhancements bring are exciting and often highly valuable; but many are unaware of the lengths cyber criminals will go to (for example, we once uncovered a vulnerability in a coffee pot which we were able to leverage to gain access to a home Wi-Fi network) and the many ways new features can reduce the security of a system.

As we move towards automation and remote access to nearly every computerized system on the planet, it’s our shared responsibility to maintain awareness of this fact and demand a higher bar for the products that we buy.

So what can be done? The responsibility is shared between consumers and manufacturers, and there are a few options:

For consumers:

• Practice proper cyber hygiene. From a technical perspective, consumers have many tools at their disposal, even when security concerns do manifest. Implement a strong password policy, put IoT devices on their own, separate, network, utilize dual-factor authentication when possible, minimize redundant systems and patch quickly when issues are found.
• Do your research. Consumers should ensure they are aware of the security risks associated with products available on the market.

For product manufacturers:

• Manufacturer supported awareness. Product manufacturers can help by clearly stating the level of security their product provides in comparison with the technology or component they seek to advance.

Embrace vulnerability disclosure. Threat actors are constantly tracking flaws which they can weaponize; conversely, threat researchers are constantly working to uncover and secure product vulnerabilities. By partnering with researchers and responding quickly, vendors have a unique opportunity

The post The Tradeoff Between Convenience and Security – A Balancing Act for Consumers and Manufacturers appeared first on McAfee Blogs.

Steve Povolny contributed to this report.

McAfee’s Advanced Threat Research team performs security analysis of products and technologies across nearly every industry vertical. Special interest in the consumer space and Internet of Things (IoT) led to the discovery of an insecure design with the McLear NFC Ring a household access control device. The NFC Ring can be used to interact with NFC-enabled door locks which conform to the ISO/IEC 14443A NFC card type. Once the NFC Ring has been paired with the NFC enabled door lock, the user can access their house by simply placing the NFC Ring within NFC range of the door lock.

McLear originally invented the NFC Ring to replace traditional keys with functional jewelry. The NFC Ring uses near field communication (NFC) for access control, to unlock and control mobile devices, share and transfer information, link people and much more. McLear NFC Ring aims to redefine and modernize access control to bring physical household security through convenience. Their latest ring also supports payment capability with McLear Smart Payment Rings, which were not in scope for this research.

Identity is something which uniquely identifies a person or object; an NFC tag is a perfect example of this. Authentication can be generally classified into three types; something you know, something you have and something you are. A NFC Ring is different from the general NFC access tag devices (something you have) as the Ring sits on your finger, so it is a hybrid authentication type of something you have and something you are. This unique combination, as well as the accessibility of a wearable Ring with NFC capabilities sparked our interest in researching this product as an NFC-enabled access control device. Therefore, the focus of our research was on NFC Ring protection against cloning as opposed to the door lock, since NFC access control tags and door locks have been well-researched.

The research and findings for this flaw were reported to McLear on September 25, 2019. To date, McAfee Advanced Threat Research has not received a response from the vendor.

Duplicating Keys Beyond the Hardware Store

In the era of Internet of Things (IoT), the balance between security and convenience is an important factor to get right during the concept phase of a new product and the bill of materials (BOM) selection. The hardware selection is critical as it often determines the security objectives and requirements that can be fulfilled during design and implementation of the product lifecycle. The NFC Ring uses an NFC capable Integrate Circuit (IC) which can be easily cloned and provides no security other than NFC proximity. The NFC protocol does not provide authentication and relies on its operational proximity as a form of protection. The problem with NFC Tags is that they automatically transmit their UID when in range of NFC device reader without any authentication.

Most consumers today use physical keys to secure access to their household door. The physical key security model requires an attacker to get physical access to the key or break the door or door lock. The NFC Ring, if designed securely, would provide equal or greater security than the physical key security model. However, since the NFC Ring can be easily cloned without having to attain physical access to the Ring, it makes the product’s security model less secure than a consumer having a physical key.

In this blog we discuss cloning of the NFC Ring and secure design recommendations to improve its security to a level equal to or greater than existing physical keys.

NFC Ring Security Model and Identity Theft

All McLear non-payment NFC Rings using NTAG216 ICs are impacted by this design flaw. Testing was performed specifically on the OPN which has an NTAG216 IC. The NFC Ring uses the NTAG 216 NFC enabled Integrated Circuit (IC) to provide secure access control by means of NFC communication.

The NFC protocol provides no security as it’s just a transmission mechanism.  The onus is on product owners to responsibly design and implement a security layer to meet the security objectives, capable of thwarting threats identified during the threat modeling phase at concept commit.

The main threats against an NFC access control tag are physical theft and tag cloning by NFC. At a minimum, a tag should be protected against cloning by NFC; with this research, it would ensure the NFC Ring provides the same level of security as a physical key. Ideal security would also protect against cloning even when the NFC Ring has been physically stolen which would provide greater security than that of a physical key.

The NTAG216 IC provide the following security per the NFC Ring spec:

1. Manufacturer programmed 7-byte UID for each device
2. Pre-programmed capability container with one-time programmable bits
3. Field programmable read-only locking function
4. ECC based originality signature
5. 32-bit password protection to prevent unauthorized memory operations

The NFC Ring security model is built on the “Manufacturer programmed 7-byte UID for each device” as the Identity and Authentication with the access control principle or door lock. This 7-byte UID (unique identifier) can be read by any NFC enabled device reader such as a proxmark3 or mobile phone when within NFC communication range.

The NFC Ring security model can be broken by any NFC device reader when they come within NFC communication range since the static 7-byte UID is automatically transmitted without any authentication. Once the 7-byte UID has been successfully read, a magic NTAG card can be programmed with the UID, which forms a clone of the NFC Ring and allows an attacker to bypass the secure access control without attaining physical access to the NFC Ring.

The NFC Ring is insecure by design as it relies on the static 7-byte UID programmed at manufacture within the NTAG216 for device identity and authentication purposes. The NFC Ring security model relies on NFC proximity and a static identifier which can be cloned.

In addition, we discovered that the UIDs across NFC Rings maybe predictable (this was a very small sample size of three NFC Rings):

• NFC Ring#1 UID 04d0e722993c80
• NFC Ring#2 UID 04d24722993c80
• NFC Ring#3 UID 04991c4a113c80

There is only a 22-byte difference between the UID of NFC Ring#1 and NFC Ring#2 (0x24-0x0e). By social engineering when a victim purchased their NFC Ring, an attacker could purchase a significant sample size of NFC Rings around the same time and possibly brute force their NFC Ring UID.

Social Engineering

Social Engineering consists of a range of techniques which can be used through human interaction for many malicious purposes such as identity theft. In the case of the NFC Ring the goal is to steal the user’s identity and gain access to their home. Reconnaissance can be performed online to gain background information such as what type of technology is being used by the victim for their home access.

One of the most common exchanges of technology today has become the passing of a phone between two untrusted parties to take a picture. The NFC Ring social engineering attack could be as simple as requesting the victim to take a picture with the attacker-supplied phone. The victim-as-helpful-photographer holds the attacker’s phone, which can read NFC tags and could be equipped with a custom Android app to read the NFC Ring UID, all transparent to the victim while they are snapping away. There is no sign to the victim that their NFC Ring is being read by the phone. It is recorded in the system log and cannot be viewed until a USB cable is attached with required software. Once the Ring is compromised, it can be reprogrammed on a standard writable card, which can be used to unlock smart home locks that partner with this product. The victim’s home is breached.

How It’s Done: NFC Ring Cloning

To successfully clone an NFC Tag, one must first identify the Tag type. This can be done by looking up the product specifications in some cases, or verifying by means of an NFC device reader such as a proxmark3.

From the NFC Ring specs we can determine most of the required tag characteristics:

1. IC Model: NTAG216
2. Operating Frequency: 13.56Mhz
3. ISO/IEC: 14443A
4. User writable space: 888 bytes
5. Full specifications

In addition, by communicating with a proxmark3 attackers can physically verify the NFC Tag characteristics and obtain the UID which is required for cloning.

The most straightforward method to stealing the unique identifier of the Ring would be through a mobile phone. The following steps were taken in the below demo:

1. Reading of NFC Ring with proxmark3 and cloning NTAG21x emulator card
2. Setting attacker’s phone to silent to prevent NFC Tag detection sound
3. Running our customized Android app to prevent Android activity popup when NFC Tag detected and read.

Mitigation Secure Design Recommendations

Lock the door. The existing insecure design can be mitigated by using NFC Doorlock password protection in combination with the NFC Ring for two factor authentication.

Authenticate. NFC Ring designers must mandate a secure PKI design with an NFC Tag which contains a crypto module that provides TAG authentication. The NFC Ring secure design must mandate a security layer on top of NFC to access control device manufacturers to ensure secure and trustworthy operation.

Randomize UIDs. In addition, the NFC designers must ensure they are not manufacturing NFC Rings with sequential UIDs which may be predictable with purchase date.

Consumer Awareness

To make customers aware of the security risks associated with products available on the market, product manufacturers should clearly state the level of security which their product provides in comparison with the technology or component they claim to be advancing. Are customers holding the master key to unlock their door, and are there duplicates?

In the case of the NFC Ring, while convenient, it clearly does not provide the same level of security to consumers as a physical key. This decrease in security model from a physical key to a NFC Ring is not due to technology limitations but due to an insecure design.

The post The Cloning of The Ring – Who Can Unlock Your Door? appeared first on McAfee Blogs.

The idea of controlling your garage door remotely and verifying that everything is secure at home, or having packages delivered directly into your garage is enticing for many people. The convenience that many of these IOT devices provide often persuades consumers away from thinking about the possible security concerns.

McAfee Advanced Threat Research recently investigated Chamberlain’s MyQ Hub, a “Universal” garage door automation platform. The way Chamberlain has made this device universal is via a Hub, which acts as a new garage door opener, similar to the one that you would have in your car. This allows the MyQ Hub to retrofit and work with a wide variety of garage doors.

We found that Chamberlain did a fairly good job of securing this device, which is typically uncommon for IOT devices. However, we discovered that there is a flaw in the way the MyQ Hub communicates with the remote sensor over radio frequencies.

From an attack perspective there are three main vectors that we began to look at: local network, remote access (API, or third-party integration), and RF communications between the sensor and the Hub. The first thing we attempted was to gain access to the device via the local network. A quick port scan of the device revealed that it was listening on port 80. When attempting to navigate to the device at port 80 it would redirect to start.html and return a 404 error. No other ports were open on the device.

The inside of the Chamberlain MyQ Hub

Disassembling the Hub revealed a small SOC (system on a chip) module that was handling the Wi-Fi and web communications and a secondary PIC microcontroller which was responsible for controlling the RF side of things for both the garage door and the remote door sensor. The MyQ Hub listed on FCC’s website also included a Bluetooth module that was not present on the two MyQ Hubs that we purchased.

The UART connection was disconnected or not enabled, but the JTAG connection worked to communicate directly with the main Wi-Fi module. With the JTAG connection we were able to dump the entire contents of the flash chip and debug the system unrestricted. The main Wi-Fi module was a Marvell microcontroller that was running a RTOS (Real Time Operating System), which acts much different than a normal Linux system. While it will still run predefined applications, RTOS’ usually don’t have a filesystem like traditional systems do.  We extracted the entire contents of the Marvell microprocessor, and were able to analyze the assembly and determine how the web server behaves.

From looking through the web server code we were able to identify how the device is setup through the local API as well as finding some interesting, albeit not very useful commands that we could send.

Local API commands

There were more URLs that we found to be accessible and some additional API paths, but nothing stood out as a good place to start an attack from. At this point we decided to investigate the other attack vectors.

We didn’t spend too much time looking into the third-party attack vector and remote API since it becomes sort of a gray area for researching. While we were testing with the /sys/mode API call we were able to put the device into a soft factory reset, where we were able to attempt to add the device to a different account. From capturing the SSL traffic on the mobile application, we were able to see that it was failing since the serial number was already registered to another account. We used a technique called SSL unpinning to decrypt traffic from the Android application; we’ll post a future blog explaining this process in greater detail. One thing that we wanted to try was to modify the Android app to send a different serial number. Since we don’t believe that the device ever cleared the original garage door information, we could have potentially opened the device from the new account. However, this is all speculation and was not tested because we didn’t want to access the remote API.

The last vector we looked at was RF. We began trying to break down the frequency modulation between the remote door sensor and the Hub. We originally thought it was some sort of FSK (frequency shift keying) where data is transmitted digitally. If the signal is in one frequency the corresponding bit is 0 and if the signal is shown on another frequency the bit is 1. This idea was thrown out since the MyQ remote sensor was using 3 different frequencies not just two.

Looking at the door sensor’s FCC filing we noticed a particularly helpful revision that they made.

OOK stands for “On OFF Keying” and is another method of encoding digital bits into RF. OOK will either be sending a signal (1) or not sending a signal (0). This means both the transmitter and receiver must be synchronized.

On Off Keying Graphical Representation

Here is the binary representation for the signal captured from the MyQ remote door sensor. This is a tightly zoomed-in window of the entire signal.

One full message captured, each color is a different frequency

aaaaaaaa559999aa59655659a6965aa9a99996aa6aa0aaaaaaaa55a9699a6566696699555a6a5556966555500aaaaaaaa559999aa59655659a6965aa9a99996aa6aa

We can observe the state transmission captured from all three frequencies and converted to hexadecimal. It’s easy to identify data patterns within the transmission, as represented in color above, but we were never able to crack it to arbitrarily transmit false states from our SDR (Software Defined Radio). We also noticed that the RF engineers at Chamberlain had security in mind not only by separating the signal into three separate frequencies, but also by implementing rolling codes. You may be familiar with the rolling code technique from things like your standard garage door opener or your car key fob. Rolling code devices prevent an attacker from directly capturing a signal and replaying it. This is prevented by the signal containing a unique identifier that is noted by the receiver and if the receiver ever sees that signal with the unique ID again it will ignore it.

The way attackers have overcome rolling code devices is by a method called “Roll Jam.” An attacker will jam the rolling code signal from the transmitter, blocking it from ever making it to the receiver, while simultaneously capturing the valid rolling code and storing it. This way the attacker now has an unused and valid rolling code that the receiver has never seen before. The caveat to this method is that normally the victim will notice that either the garage door or car didn’t unlock. A stealthier method to Roll Jam is always capturing the latest code and replaying the latest signal minus 1. This way the car or door will open but the attacker still owns the latest code for their use.

The MyQ also had a rolling code implementation that we were able to develop a variant of this technique against. We took the concept of jamming the original code from the receiver by transmitting a large amount of “noise” directly adjacent to the valid signal frequency. This causes the receiver in the MyQ Hub to overload and not hear the valid signal. However, with the precision of the SDR, we were able to ignore the noise that we are transmitting and store the signal. This was further complicated by the fact that there were three frequencies that we had to simultaneously listen for and jam. If you are interested in this FHSS (Frequency Hopping Spread Spectrum) Roll Jam technique, please read our white paper.

Within the research related to Chamberlain Garage Door Hub described in this blog, the only interference was to unlicensed spectrum radio frequency for the minimum period while the garage door hub was transmitting state signal, and there was no interference with any communications signal licensed or authorized under the Communications Act or FCC rules.

This technique worked, but since the remote sensor and the MyQ Hub always have the advantage in RF landscape, it was unreliable. The jamming aspect of the attack worked nicely; however, since we are outside of the garage and the remote sensor and the Hub are both located within the same garage, it is harder to jam and listen at the same time with the garage door and walls acting as barriers. With higher powered radios, frequency-tuned antennas, and disregard for FCC’s laws, the jamming of the remote sensor could take place at a much further distance than we were able to test in our lab environment.

A waterfall view of the remote sensor signal (red) and jamming (black)

With our jamming working reliably, we confirmed that when a user closes the garage door via the MyQ application, the remote sensor never responds with the closed signal because we are jamming it. The app will alert the user that “Something went wrong. Please try again.” This is where a normal user, if not in direct sight of the garage door, would think that their garage door is indeed open, when in reality it is securely closed. If the user believes the MyQ app then they would do as the application indicates and “try again” – this is where the statelessness of garage doors comes into play. The MyQ Hub will send the open/closed signal to the garage door and it will open, because it is already closed, and it is simply changing state. This allows an attacker direct entry into the garage, and, in many cases, into the home.

Since now the garage door is really open the attacker probably doesn’t want to leave the state as-is, notifying the victim that something went wrong again. Putting the garage door into a closed state and allowing the app to clear the error will put the victim at ease. This could be executed either by a replay from a previously captured closed signal, or, in the most simplistic manner by removing the remote sensor from the Velcro on the garage door and placing it in the vertical position, signaling to the Hub that the door closed successfully.

Attack Reproduction State Flowchart

We also realized that in a real-world scenario, an attacker wouldn’t likely sit outside of a garage all day, so we decided to automate the attack. We used GNU radio to implement a JIT (just in time) method of jamming where the SDR will sit dormant listening on the MyQ’s three separate frequencies. The moment it notices that the remote door sensor is beginning a transmission, it will dynamically enable and start jamming of the signal.

GNU Radio JIT Jamming and State Capture over 3 Simultaneous Frequencies

This expands the use cases of this type of attack by being able to create a small device that could be placed out of sight near the garage door. This technique is also described in more detail in our FHSS white paper. The JIT jamming makes it very difficult to locate the device using RF triangulation and allows it to be better equipped for battery operation.

While this may not be too common for individuals using the MyQ Hub, recall the earlier reference to third-party partnerships with MyQ for garage delivery. Another possible attack would be when a delivery driver uses the application. The primary reason users sign up for this service is the concept of a package delivery to a secure location (garage) even when they are not home. The victim can be absent from the property yet have access via the MyQ app over the internet to open or close the garage door if a delivery driver uses the MyQ hub for an in-garage delivery. A determined hacker could pull this attack off and the victim may have a higher probability of believing that the door may in fact be open. We disclosed our findings in full to Chamberlain on 9/25/2019, including detailed reproduction steps for the jamming attack. We also talked to Chamberlain on this issue with the third-party delivery drivers and how it could fit into this attack model. After extensive testing and validation of the issue, the vendor released an update to the myQ App as of version 4.145.1.36946. This update provides a valuable warning message to users indicating the garage door state may not be accurate, but it does not eliminate the user from remotely controlling the door itself.

The beauty of IOT devices are that they solve problems that we have learned to deal with. After we experience the convenience and the way these devices can automate, secure, or assist in our lives it is hard to see them ever going away. This ease and automation often overshadows the potential security threat that they may pose. Even simple enhancements to manual products over time have this effect; take for example the now-legacy garage door opener in your car. The ability to capture and replay the basic signals transformed the threat from physical to digital space. While the Chamberlain MyQ Hub ultimately produces a generally more secure method of accessing garages than its predecessors, consumers should be aware that any extension of a technology platform, such as using WiFi, a mobile app and FHSS RF transmissions, also extends possible threat vectors.

We would like to finish by commenting that the likelihood of a real-world attack on this target is low, based on the complexity of the attack and installation footprint. We have discussed this with Chamberlain, who has validated the findings and agrees with this assessment. Chamberlain has made clear efforts to build a secure product and appears to have eliminated much of the low-hanging fruit common to IoT devices. This vendor has been a pleasure to work with and clearly prioritizes security as a foresight in the development of its product.

NOTE: Within the research related to Chamberlain Garage Door Hub described in this blog, the only interference was to unlicensed spectrum radio frequency for the minimum period while the garage door hub was transmitting state signal, and there was no interference with any communications signal licensed or authorized under the Communications Act or FCC rules.

The post We Be Jammin’ – Bypassing Chamberlain myQ Garage Doors appeared first on McAfee Blogs.

Recent political tensions in the Middle East region have led to significant speculation of increased cyber-related activities. McAfee is on a heightened state of alert to monitor the evolving threats and rapidly implement coverage across all McAfee products as intelligence becomes available. Known campaigns associated with the threat actors from this region were integrated into our products and we continue to monitor our global telemetry for any further activity.

Current activity

We are observing activity that claim to be attributed from threat actors from this region, however, distinguishing attribution between cybercrime and nation state will be crucial since the line will likely blur. For example, typical cybercrime activities such as ransomware, or indeed defacements or DDoS, could well be a mask for nation-state activities.

The post Iran Cyber Threat Update appeared first on McAfee Blogs.

By: Jan Schnellbächer and Martin Stecher, McAfee Germany GmbH

This week security researches around the world were very busy working on Microsoft’s major crypto-spoofing vulnerability (CVE-2020-0601) otherwise known as Curveball. The majority of research went into attacks with malicious binaries that are signed with a spoofed Certificate Authority (CA) which unpatched Win10 systems would in turn trust. The other attack vector —HTTPS-Server-Certificates— got less attention until Saleem Rashid posted a first working POC on Twitter, followed by Kudelski Security and “Ollypwn” who published more details  on how the Proof-Of-Concepts are created.

McAfee Security experts followed the same approach and were able to  reproduce the attack.  In addition, they confirmed that users  browsing via unpatched Windows-Systems were protected provided their clients were deployed behind McAfee’s Web Gateway or Web Gateway Cloud Service and running the certificate verification policy. This is typically part of the SSL Scanner but is also available as a separate policy even if no SSL inspection should be done (see KB92322 for details).

In our first attempt, we used the spoofed version of a CA from the Windows Root CA Trust store to sign a server certificate and then only provided the server certificate when the HTTPS connection wanted to be established. That attempt failed and we assumed that we did not get the spoofing right. Then we learned that the spoofed CA actually needs to be included together with the server certificate and that chain of certificates is then accepted by an unpatched Windows 10 system.

But why is that? By sending the spoofed version, it becomes obvious that this is not the same certificate that exists in the trust store and should be denied immediately. Also, in the beginning, we tried hard to make the spoofed CA as similar to the original CA as possible (same common name, same serial number, etc.). In fact, we found that none of that plays any role when Windows does the certificate verification.

A good indication of what’s happening behind the scenes, is already provided by Windows’ own certificate information dialogs. We started with the “UserTrust ECC Certificate” in the Windows Trusted Root CA catalog which carries the friendly name “Sectigo ECC”. Then we created a spoofed version of that CA and gave it a new common name “EVIL CA”. With that, it was easy to set up a new test HTTPS server in our test network and manipulate the routing of a test client so that it would reach our server when the user types https://www.google.com into the browser. The test server  was presenting SSL session information for debugging purposes instead of any Google content.

When you click onto the lock symbol, the browser tells you that the connection has been accepted as valid and trusted and that the original “Sectigo ECC” root CA  had signed the server certificate.

But we know that this was not the case, and in contrast to our own original assumptions, Windows did not even verify the server certificate against the “Sectigo ECC. It compared it against the included spoofed CA. That can be seen, when you do another click to “View certificates”:

As the screenshot shows, we are still in the same SSL session (the master key is the same on both pictures), but now Windows is showing that the (correct) issuer of the server certificate is our spoofed “EVIL CA”.

Windows’ cryptographic signature verification works correctly

The good news is that Windows does not really have an issue with the cryptographic functions to validate the signature of an elliptic curve certificate! That verification works correctly. The problem is how the trust chain comparison is done to prove that the chain of signatures is correctly ending in the catalog of trusted root CAs.

We assumed that an attack would use a signing CA that points to an entry in the trusted Root CA store and verification of the signature would be limited so that the signature would be accepted although it was not signed with that original CA but a spoofed CA. But in fact, Windows is validating the embedded certificate chain — which is perfectly valid and cryptographically correct— and then matches the signing certificate with the entries in the trusted Root CA store. This last piece is what has not been done correctly (prior to the system patch).

Our tests revealed that Windows does not even try to match the certificates. It only matches the public key of the certificates (and a few more comparisons and checks) – making the comparison incomplete. That was the actual bug of this vulnerability (at least as web site certificates are concerned).

The Trusted Certificate Store is actually a Trusted Public Key Store

When we talk about the trust chain in SSL/TLS communication, we mean a chain of certificates that are signed by a CA until we reach a trusted Root CA. But Microsoft appears to ignore the certificates for the most part and manages a chain of the public keys of certificates. The comparison is also comparing the algorithm. At a time where only RSA certificates were used, that was sufficient. It was not possible for an attacker to create his own key pair with the same public key as the trusted certificate. With the introduction of Elliptic Curve Cryptography (ECC), Microsoft’s comparison of only the algorithm and the public key is failing. It is failing to also compare the characteristics of the elliptic curve itself. Without this additional parameter, it simply creates the same public key (curve point) again on a different curve. This is what was fixed on Patch-Tuesday — the comparison of the public key information now includes the curve characteristics.

This screenshot shows that the original certificate on the right side and the spoofed CA on the left are very different. Different common name, and a totally different elliptic curve (a standard curve for the original CA and a handcrafted for the spoofed version), but the signature seen under the “pub” entry is identical. That has been sufficient to make Windows believe that the embedded spoofed CA was the same as the trusted CA in the certificate store.

Why not comparing certificates by name or serial number?

A different (and maybe more natural) algorithm is to compare certificates by their common name and/or their serial number and whenever you have a match, continue the trust chain and verification with the certificate in the trust store. Why is Windows comparing public keys instead? We can only speculate but the advantage might be for Enterprises who want to swap their certificates without rolling out new root CAs to all client computers. Imagine an organization that maintains its own PKI and installs its own Root CA in the store of trusted certificates. When these companies go through mergers and acquisitions and the company name may change. This would be a good time to also change the common name of your signing certificate. However, if you do not have a good way to remote maintain all clients and update the certificate in the trusted store, it is easier to tell the Cooperation to use the original key pair of public and private keys and create a new certificate with that same key pair. The new cert will still match the old cert and no other client update is necessary. Convenient! But Is it secure? At this point it is not really a chain of trusted certificates but a chain of trusted public keys.

We tested whether this could also be mis-used to create a new cert when the old one has expired but that is not the case. After comparing the public keys, Windows is still using the expiration date of the certificate in the trusted store to determine whether the chain is still valid, which is good.

How to harden the process?

The root problem of this approach is that the complete cryptographic verification happens with the embedded certificates and only after verification the match against the entry in the trusted Root CAs store is done. That always has room for oversights and incomplete matching algorithms as we have seen with this vulnerability. A safe approach is to first match the certificates (or public keys), find the corresponding entry in the Trusted Root CA store and then use that trusted certificate to continue the signature verification. That way, the verification fails on the safe side and broken chains can be identified easily.

We do not know whether that has been changed with the patched Windows version or if only the matching algorithm has been improved. If not, we recommend reviewing this alternative approach and further hardening the implementation in the operating system and browser.

The post What CVE-2020-0601 Teaches Us About Microsoft’s TLS Certificate Verification Process appeared first on McAfee Blogs.

Enterprise customers looking for information on defending against Curveball can find information here.

2020 came in with a bang this year, and it wasn’t from the record-setting number of fireworks on display around the world to celebrate the new year. Instead, just over two weeks into the decade, the security world was rocked by a fix for CVE-2020-0601 introduced in Microsoft’s first patch Tuesday of the year. The bug was submitted by the National Security Administration (NSA) to Microsoft, and though initially deemed as only “important”, it didn’t take long for everyone to figure out this bug fundamentally undermines the entire concept of trust that we rely on to secure web sites and validate files. The vulnerability relies on ECC (Elliptic Curve Cryptography), which is a very common method of digitally signing certificates, including both those embedded in files as well as those used to secure web pages. It represents a mathematical combination of values that produce a public and private key for trusted exchange of information. Ignoring the intimate details for now, ECC allows us to validate that files we open or web pages we visit have been signed by a well-known and trusted authority. If that trust is broken, malicious actors can “fake” signed files and web sites and make them look to the average person as if they were still trusted or legitimately signed. The flaw lies in the Microsoft library crypt32.dll, which has two vulnerable functions. The bug is straightforward in that these functions only validate the encrypted public key value, and NOT the parameters of the ECC curve itself. What this means is that if an attacker can find the right mathematical combination of private key and the corresponding curve, they can generate the identical public key value as the trusted certificate authority, whomever that is. And since this is the only value checked by the vulnerable functions, the “malicious” or invalid parameters will be ignored, and the certificate will pass the trust check.

As soon as we caught wind of the flaw, McAfee’s Advanced Threat Research team set out to create a working proof-of-concept (PoC) that would allow us to trigger the bug, and ultimately create protections across a wide range of our products to secure our customers. We were able to accomplish this in a matter of hours, and within a day or two there were the first signs of public PoCs as the vulnerability became better understood and researchers discovered the relative ease of exploitation.

Let’s pause for a moment to celebrate the fact that (conspiracy theories aside) government and private sector came together to report, patch and publicly disclose a vulnerability before it was exploited in the wild. We also want to call out Microsoft’s Active Protections Program, which provided some basic details on the vulnerability allowing cyber security practitioners to get a bit of a head start on analysis.

The following provides some basic technical detail and timeline of the work we did to analyze, reverse engineer and develop working exploits for the bug.  This blog focuses primarily on the research efforts behind file signing certificates.  For a more in-depth analysis of the web vector, please see this post.

Creating the proof-of-concept

The starting point for simulating an attack was to have a clear understanding of where the problem was. An attacker could forge an ECC root certificate with the same public key as a Microsoft ECC Root CA, such as the ECC Product Root Certificate Authority 2018, but with different “parameters”, and it would still be recognized as a trusted Microsoft CA. The API would use the public key to identify the certificate but fail to verify that the parameters provided matched the ones that should go with the trusted public key.

There have been many instances of cryptography attacks that leveraged failure of an API to validate parameters (such as these two) and attackers exploiting this type of vulnerability. Hearing about invalid parameters should raise a red flag immediately.

To minimize effort, an important initial step is to find the right level of abstraction and details we need to care about. Minimal details on the bug refer to public key and curve parameters and nothing about specific signature details, so likely reading about how to generate public/private key in Elliptical Curve (EC) cryptography and how to define a curve should be enough.

The first part of this Wikipedia article defines most of what we need to know. There’s a point G that’s on the curve and is used to generate another point. To create a pair of public/private keys, we take a random number k (the private key) and multiply it by G to get the public key (Q). So, we have Q = k*G. How this works doesn’t really matter for this purpose, so long as the scalar multiplication behaves as we’d expect. The idea here is that knowing Q and G, it’s hard to recover k, but knowing k and G, it’s very easy to compute Q.

Rephrasing this in the perspective of the bug, we want to find a new k’ (a new private key) with different parameters (a new curve, or maybe a new G) so that the ECC math gives the same Q back. The easiest solution is to consider a new generator G’ that is equal to our target public key (G’= Q). This way, with k’=1 (a private key equal to 1) we get k’G’ = Q which would satisfy the constraints (finding a new private key and keeping the same public key).

The next step is to verify if we can actually specify a custom G’ while specifying the curve we want to use. Microsoft’s documentation is not especially clear about these details, but OpenSSL, one of the most common cryptography libraries, has a page describing how to generate EC key pairs and certificates. The following command shows the standard parameters of the P384 curve, the one used by the Microsoft ECC Root CA.

Elliptic Curve Parameter Values

We can see that one of the parameters is the Generator, so it seems possible to modify it.

Now we need to create a new key pair with explicit parameters (so all the parameters are contained in the key file, rather than just embedding the standard name of the curve) and modify them following our hypothesis. We replace the Generator G’ by the Q from Microsoft Certificate, we replace the private key k’ by 1 and lastly, we replace the public key Q’ of the certificate we just generated by the Q of the Microsoft certificate.

To make sure our modification is functional, and the modified key is a valid one, we use OpenSSL to sign a text file and successfully verify its signature.

Signing a text file and verifying the signature using the modified key pair (k’=1, G’=Q, Q’=Q)

From there, we followed a couple of tutorials to create a signing certificate using OpenSSL and signed custom binaries with signtool. Eventually we’re greeted with a signed executable that appeared to be signed with a valid certificate!

Spoofed/Forged Certificate Seemingly Signed by Microsoft ECC Root CA

Using Sysinternal’s SigChecker64.exe along with Rohitab’s API Monitor (which, ironically is on a site not using HTTPS) on an unpatched system with our PoC, we can clearly see the vulnerability in action by the return values of these functions.

Rohitab API Monitor – API Calls for Certificate Verification

Industry-wide vulnerabilities seem to be gaining critical mass and increasing visibility even to non-technical users. And, for once, the “cute” name for the vulnerability showed up relatively late in the process. Visibility is critical to progress, and an understanding and healthy respect for the potential impact are key factors in whether businesses and individuals quickly apply patches and dramatically reduce the threat vector. This is even more essential with a bug that is so easy to exploit, and likely to have an immediate exploitation impact in the wild.

McAfee Response

McAfee aggressively developed updates across its entire product lines.  Specific details can be found here.

The post CurveBall – An Unimaginative Pun but a Devastating Bug appeared first on McAfee Blogs.

There has been a dramatic shift in the platforms targeted by attackers over the past few years. Up until 2016, browsers tended to be the most common attack vector to exploit and infect machines but now Microsoft Office applications are preferred, according to a report published here during March 2019. Increasing use of Microsoft Office as a popular exploitation target poses an interesting security challenge. Apparently, weaponized documents in email attachments are a top infection vector.

Object Linking and Embedding (OLE), a technology based on Component Object Model (COM), is one of the features in Microsoft Office documents which allows the objects created in other Windows applications to be linked or embedded into documents, thereby creating a compound document structure and providing a richer user experience. OLE has been massively abused by attackers over the past few years in a variety of ways. OLE exploits in the recent past have been observed either loading COM objects to orchestrate and control the process memory, take advantage of the parsing vulnerabilities of the COM objects, hide malicious code or connecting to external resources to download additional malware.

Microsoft Rich Text Format is heavily used in the email attachments in phishing attacks. It has been gaining massive popularity and its wide adoption in phishing attacks is primarily attributed to the fact that it has an ability to contain a wide variety of exploits and can be used efficiently as a delivery mechanism to target victims. Microsoft RTF files can embed various forms of object types either to exploit the parsing vulnerabilities or to aid further exploitation. The Object Linking and Embedding feature in Rich Text Format files is largely abused to either link the RTF document to external malicious code or to embed other file format exploits within itself and use it as the exploit container. Apparently, the RTF file format is very versatile.

In the below sections, we attempt to outline some of the exploitation and infection strategies used in Microsoft Rich Text format files over the recent past and then towards the end , we introspect on the key takeaways that can help automate the analysis of RTF exploits and set the direction for the generic analysis approach.

RTF Control Words

Rich Text Format files are heavily formatted using control words. Control words in the RTF files primarily define the way the document is presented to the user. Since these RTF control words have the associated parameters and data, parsing errors for them can become a target for exploitation. Exploits in the past have been found using control words to embed malicious resources as well. Consequently, it becomes significant to examine a destination control word that consumes data and extract the stream. RTF specifications describe several hundred control words consuming data.

RTF parsers must also be able to handle the control word obfuscation mechanisms commonly used by attackers, to further aid the analysis process. Below is one of the previous instances’ exploits using control word parameters to introduce executable payloads inside the datastore control word.

Overlay Data in RTF Files

Overlay data is the additional data which is appended to the end of RTF documents and is predominantly used by exploit authors to embed decoy files or additional resources, either in the clear, or encrypted form which is usually decrypted when the attacker-controlled code is executed. Overlay data of the volume beyond a certain size should be deemed suspicious and must be extracted and analysed further. However, Microsoft Word RTF parser will ignore the overlay data while processing RTF documents. Below are some instances of RTF exploits with a higher volume of overlay data appended at the end of the file, with CVE-2015-1641 embedding both the decoy document and multi-staged shellcodes with markers.

Object Linking and Embedding in RTF Files

Linked or embedded objects in RTF documents are represented as RTF objects, precisely to the RTF destination control word “object”. The data for the embedded or linked object is stored as the parameter to the RTF sub-destination control word “objdata” in the hex-encoded OLESaveToStream format. Modifier control word “objclass” determines the type of the object embedded in the RTF files and helps the client application to render the object. However, the hex encoded object data as the argument to the “objdata” control word can also be heavily obfuscated, either to make the reverse engineering and analysis effort more time consuming or to break the immature RTF parsers. Apparently, OLE has been one of the dominant attack vectors in the recent past, with many instances of OLE based exploits used in targeted attacks, essentially implying robust RTF document parsers for the extraction of objects, along with deeper inspection of object data is extremely critical.

Object Linking – Linking RTF to External Resource

Using object linking, it is possible to link the RTF files to the remote object which could be the link to the malicious resource hosted on the remote server. This leads the resulting RTF file to behave as a downloader and subsequently execute the downloaded resource by invoking the registered application-specific resource handlers. Inspecting the modifier RTF control words to “object”, linked objects are indicated by another nested control word “objautlink”, as represented below in the RTF document.

As indicated in the above representation, object data as the argument to the RTF control word “objdata” is OLE1.0NativeStream in the OLESaveToStream format which is followed by the NativeDataSize indicating the size of the OLE2.0 Compound document that is wrapped in the NativeStream. As per the Rich Text Format specifications, if the object is linked to the container application, which in this case is the RTF document, the Root Storage directory entry of the compound document will have the CLSID of the StdOleLink indicating the linked object. Also, when the object is in the OLE2.0 format, the linked source data is specified in the MonikerStream of the OLESteam structure. As highlighted below, while parsing the object data, the ole32.OleConvertOLESTREAMToIStorage function is responsible for converting the OLE1.0 NativeStream data to OLE2.0 structured storage format. Following the pointer to the OLE stream lpolestream will allow us to visualize the parsed extracted native data. Below is a memory snapshot from when an RTF document with a linked object was parsed by the winword.exe process.

Launching the RTF document with the link to external object will throw up a dialogue box asking to update the data from the linked object, as shown below.

However, this is not the ideal exploitation strategy to target victims. This error can be eliminated by inserting another modifier control word “objupdate”, which internally calls link object’s IOleObject::Update method to update the link’s source.

Subsequently the urlmon.dll, which is the registered server for the URL Moniker, is instantiated.

Once the COM object is instantiated, the connection is initiated to the external resource and, based on the content-type header returned by the server in the response, URL Moniker consults the Mime database in the registry and invokes registered application handlers.

Details on how URL Moniker is executed and an algorithm to determine which appropriate handlers to invoke is described by Microsoft here.  We have had multiple such RTF exploits in the past including CVE-2017-0199, CVE-2017-8756 and others using Monikers to download and execute remote code.

However, COM objects used in the mentioned exploits had been blacklisted by Microsoft in the newer versions, but similar techniques could be used in future which essentially necessitates the analysis of OLE structured storage streams.

Object Embedding – RTF Containing OLE Controls

As indicated earlier, embedded objects are represented in the container documents in the OLE2 format. When the object is stored in the OLE2 format, the container application (here Rich Text Format files) creates the OLE Compound File Storage for each of the objects embedded and the respective object data is stored in the OLE Compound File Stream Objects. Layout of the container documents storing embedded objects is as represented below and described in the Microsoft documentation here.

RTF exploits historically have been found embedding and loading multiple OLE controls in order to bypass exploit mitigations and to take advantage of memory corruption vulnerabilities by loading vulnerable OLE controls. Embedded OLE controls in the RTF document are usually indicated by nested control word “objocx” or “objemb” followed by the “objclass” with the argument as the name of the OLE control to render the object. Below is one of the examples of the previous exploit used in the targeted attacks, which exploited a vulnerability in the COM object and loaded another OLE control to aid the exploitation process which had the staged malicious code embedded. Apparently, it is critical to extract this object data, extract the OLE2 compound file storage and extract each of the stream objects for further inspection of hidden malicious shellcodes.

Object Embedding – RTF Containing Other Documents

Malicious RTF documents can use the OLE functionality to embed other file formats like Flash files and Word documents, either to exploit respective file format vulnerabilities or to further assist and set up the stage for the successful exploitation process. Multiple RTF exploits have been observed in the past embedding OOXML documents using OLE functionality to manipulate the process heap memory and bypass Windows exploit mitigations. In RTF files, embedded objects are usually indicated by nested control word “objemb” with a version-dependent “ProgID” string as the argument to the nested control word “objclass”. One such RTF exploit used in targeted attacks in the recent past, is as indicated below.

Below is another instance where the PDF file was physically embedded within the compound document. As mentioned, the embedded object is stored physically along with all the information required to render it.

In the embedded object, the creating application’s identifier is stored in the CLSID field of the compound file directory entry of the CFB storage object. If we take a look at the previous instance, when the object data is extracted and inspected manually, the following CLSID is observed in the CFB storage object, which corresponds to the CLSID_Microsoft_Word_Document.

When OLE2 stream objects are parsed and the embedded OOXML is extracted and analysed after deflating the contents, we see the suspicious ActiveX object loading activity and embedded malicious code in one of the binary files. Apparently, it is significant to extract the embedded files in RTF and perform further analysis.

OLE Packages in RTF Files

RTF documents can also embed other file types like scripts (VBSsript, JavaScript, etc.), XML files and executables via OLE packages. An OLE package in an RTF file is indicated by the ProgID string “package” as the argument to the nested control word “objclass”. Packager format is the legacy format that does not have an associated OLE server. Looking at the associated CLSID in the registry, there is no specific data format mapped with Packages.

This essentially implies that OLE packages can store multiple file types and, if a user clicks the object, it will lead to execution of it and, eventually, infection of the machine if they are malicious scripts. RTF documents have been known to deliver malware by embedding scripts via OLE packages and then using Monikers, as described in the previous sections, to drop files in the desired directory and then execute them. One such instance of a malicious RTF document exploiting CVE-2018-0802, embedding an executable file, is shown below.

Since many RTF documents have been found delivering malware via OLE packages, it is critical to look for these embedded objects and analyse them for such additional payloads. Embedded executables / scripts within RTF could be malicious. Looking for OLE packages and extracting embedded files should be a trivial task.

The above exploit delivery strategies can allow us to take a step towards building analysis frameworks for RTF documents. Primarily, inspecting the linked or embedded objects turns out to be the critical aspect of automated analysis tasks along with the RTF control words inspection. The following are the key takeaways:

• Using the RTF file as the container, many other file format exploits can be embedded inside using the Object Linking and Embedding feature, essentially weaponizing the RTF documents.
• Extract and analysing embedded or linked objects for malicious code, payload or resource handler invocations becomes very essential.
• If RTF document has a higher volume of appended data, it must be further looked at.
• Non-OLE control words and OLE packages must also be analysed for any malicious content.

McAfee Response

As Microsoft Office vulnerabilities continue to surface, generic inspection methods will have to be improved and enhanced, consequently leading to better detection results. As a reminder, the McAfee Anti-Malware engine used on all our endpoints and most of our appliances has the potential to unpack Office, RTF and OLE documents, expose the streams of content and unpack these streams if necessary.

The post An Inside Look into Microsoft Rich Text Format and OLE Exploits appeared first on McAfee Blogs.

Today McAfee released the results of a survey of county websites and county election administration websites in the 13 states projected as battleground states in the 2020 U.S. presidential elections. We found that significant majorities of these websites lacked the official government .GOV website validation and HTTPS website security measures to prevent malicious actors from launching copycat web domains posing as legitimate county government sites.

These shortcomings could make it possible for malicious actors to spread false and misleading election information through mass bulk email and website promotion campaigns that could suppress, misdirect, or otherwise disrupt Election Day proceedings in such a way that they could impact the number of votes cast and, ultimately, perhaps impact the results of the 2020 U.S. elections.

Why .GOV & HTTPS?

Whereas websites using .COM, .NET, .ORG, and .US in their names are easily accessible to anyone with a credit card from website domain vendors such as GoDaddy.com, acquiring a .GOV website name requires that buyers submit evidence to the U.S. government that they truly are buying these names on behalf of legitimate local, county, or state government entities.

The lack of .gov in a website name means that no controlling government authority has validated that the website in question is legitimate.

When website visitors see the HTTPS and a lock icon in the address of a website they are visiting, this means that their browser has made a secure connection with that website through a technology called Secure Sockets Layer (SSL). While SSL sounds technical, the security it delivers is easy to understand. These signifiers simply tell visitors that any personal voter registration information that they share with those websites is encrypted and cannot be intercepted and stolen by hackers while they are visiting the site.

Additionally, and more importantly to the election disinformation issue, they also tell visitors that they cannot be re-routed against their will from legitimate government websites to other websites pretending to be government websites.

What McAfee’s survey found

McAfee’s January 2020 survey researched states projected by U.S. election prognosticators to be pivotal in determining the victor in the 2020 Presidential Elections. States surveyed include Arizona, Florida, Georgia, Iowa, Michigan, Minnesota, Nevada, New Hampshire, North Carolina, Ohio, Pennsylvania, Texas, and Wisconsin. Together, these states account for 201 of the 270 electoral votes required to win the U.S. presidential election.

State counties lacking .GOV validation

Of the 1,117 counties in the survey group, 83.3% of their websites lack .GOV validation. Minnesota ranked the lowest among the surveyed states in terms of .GOV website validation with 95.4% of counties lacking U.S. government certification. Other states severely lacking in .GOV coverage included Texas (94.9%), New Hampshire (90.0%), Michigan (89.2%), Iowa (88.9%), Nevada (87.5%), and Pennsylvania (83.6%).

Arizona had the highest percentage of main county websites validated by .GOV with 66.7% coverage, but even this percentage suggests that a third of the Grand Canyon State’s county websites are unvalidated and that hundreds of thousands of voters could still be subjected to disinformation schemes.

State counties lacking HTTPS protection

McAfee’s survey found that 46.6% of county websites lack HTTPS encryption. Texas ranked the lowest in terms of encryption with 77.2% of its county websites failing to protect citizens visiting these web properties. Other states with counties lacking in encryption included Pennsylvania (46.3%), Minnesota (42.5%), and Georgia (38.4%).

Assessment of Iowa and New Hampshire

In Iowa, 88.9% of county websites lack .GOV validation, and as many as 29.3% lack HTTPS encryption. Ninety percent of New Hampshire’s county websites lack .GOV validation, and as many as 30% of the Granite State’s counties lack encryption.

Inconsistent naming standards

McAfee’s research found that some states attempted to establish standard naming standards, such as www.co.[county name].[two-letter state abbreviation].us. Unfortunately, these formats were followed so inconsistently that a voter seeking election information from her county website cannot be confident that a web domain following such a standard is indeed a legitimate site.

Easy-to-remember naming formats

McAfee found 103 cases in which counties set up easy-to-remember, user-friendly domain names to make their election information easier to remember and access for the broadest possible audience of citizens. Examples include www.votedenton.com, www.votestanlycounty.com, www.carrollcountyohioelections.gov, www.voteseminole.org, and www.worthelections.com. While 93 of these counties (90.2%) protected voters visiting these sites with encryption, only two validated these special domains and websites with .GOV. This suggests that malicious parties could easily set up numerous websites with similarly named domains to spoof these legitimate sites.

.GOV and elections

The lack of .gov matters because, without an official government body validating whether websites truly belong to the government entities they claim, it’s possible for malicious actors to spoof legitimate government sites with fraudulent websites.

If a malicious foreign actor can spoof government websites, he can send hundreds of thousands of emails to voters and use both those emails and the websites to which they are tied to send voters information on the wrong polling places, phony voter registration processes or requirements (barriers), or other incorrect voting instructions that could suppress, misdirect, or otherwise disrupt a key county’s electorate from voting.

If the malicious actor can launch such a digital disinformation campaign close enough to election day, he could reach a critical mass of voters. If he does so before county and state officials become aware of the campaign, it could be very difficult for the officials to counter the disinformation before voter behavior is impacted.

If the actor can successfully disrupt the voting behavior of just tens of thousands of citizens in these key states, their votes may not be counted or their confidence in the validity of election results and even legitimacy of the democratic process overall could be badly shaken.

Ultimately, if a malicious actor seeks to undermine confidence in America’s system of government, such a digital disinformation campaign can succeed in damaging confidence in the electoral process, even if he cannot succeed in impacting actual votes.

Ohio’s Strategy for transitioning to .GOV

While only 19.3% of Ohio’s 88 county main websites have .GOV validation, the state leads McAfee’s survey with 76.1% of county election websites and webpages validated by .GOV certification.

This leadership position appears to be the result of a state-led initiative to transition county election-related content to .GOV validated web properties. A majority of counties have subsequently transitioned their main county websites to .GOV domains, their election-specific websites to .GOV domains, or their election-specific webpages to Ohio’s own .GOV-validated https://ohio.gov/ domain (i.e. https://www.boe.ohio.gov/vanwert/). See here for a complete list of Ohio county election websites.

Such a .GOV transition strategy constitutes an interim solution until more comprehensive efforts are made at the state and federal government level through initiatives such as The DOTGOV Act of 2020. This legislation would require the Department of Homeland Security (DHS) to support .GOV adoption for local governments with technical guidance and financial support.

Please see the following for more information on this subject:

• McAfee 2020 Election Voter Info Webpage
• The DOTGOV Act of 2020 Blog

The post U.S. Battleground County Website Security Survey appeared first on McAfee Blogs.

Intelligence became an integral military discipline centuries ago. More recently, this practice evolved into what is called Intelligence Preparation of the Battlefield, or IPB. In both military and civilian agencies, the discipline uses information collection followed by analysis to provide guidance and direction to operators making tactical or organizational decisions. Used strategically, this type of intelligence puts an organization in a stronger position to operate offensively or defensively because in theory, they now know more than their enemy.

This same concept can be applied in the theater of cybersecurity operations. However, the current scope of intelligence in many enterprises describes just one aspect of the IPB discipline: information collection. The critical component missing to complete the process is a specialized researcher trained in this type of analysis and subsequent application of intelligence.

A disciplined intelligence cycle goes deep—applying advanced data collection methodologies from open, closed and propriety sources, social media, human intelligence and the dark web against areas such as cybercrime, hactivism, or cyber espionage to thoroughly analyze the adversary. Intelligence can ultimately be used to prepare organizations tactically and strategically to both anticipate and mitigate modern threats.

The latest research and analysis from McAfee Advanced Program Group (APG) researcher Anne An detailing the actions of Chinese non-state threat actor groups is a great example of intelligence that is invaluable for organizations. This unique take on Chinese cyber criminality educates practitioners on the threats around them, empowering them to prepare their organization to be proactive, rather than reactive. Further, there are many times where organizations are unaware they have been a victim of a cyberattack. This could include stolen data, which McAfee APG may find being sold on the dark markets, and in some cases, could have a devastating effect on their business.

Sun Tzu, the Chinese general, and military strategist once articulated, “The art of war teaches us to rely not on the likelihood of the enemy’s not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.”  These ancient words are still very meaningful today. If organizations robustly embrace the intelligence process, their defensive posture will exponentially improve.

The post Intelligence in the Enterprise appeared first on McAfee Blogs.

Preface

Because of its longevity and technical sophistication, the Russian cybercriminal underground has long been the benchmark for threat researchers focused on studying cybercrime tactics and techniques; there is a plethora of publications dedicated to analyzing its economy and hacking forums. However, only a handful of studies have centered on the emerging threats and trends from other, less prominent, cybercriminal undergrounds.

Recent data shows that the Chinese cybercriminal underground’s profits exceeded US$15.1 billion in 2017, while causing more than $13.3 billion worth of damage relating to data loss, identity theft and fraud. Over the years, the McAfee Advanced Programs Group (APG) has observed Chinese non-state threat actor groups gradually transform from small local networks targeting mostly Chinese businesses and citizens to large, well-organized criminal groups capable of hacking international organizations.

The development of commercial-scale exploit toolkits and criminal networks that focus on monetization of malware have amplified the growing risks of cybercrime in the Asia Pacific region to include a DDoS attack against the People’s Bank of China in December 2013, a $1 billion SWIFT hack against Bangladesh Bank in February 2016 and a $60 million theft from Far Eastern International Bank in Taiwan in October 2017, to name just a few.

This blog provides a rare glimpse inside the Chinese cybercriminal underground. Analyzing its current business models and techniques has yielded insights into the drastic changes in its operations, including the tactics and strategies it is borrowing from Russian cybercriminals.

Timeline: The Rise of the Chinese Cybercriminal Underground

China established its first cable connection to the world wide web in 1994, around the same time as cybercrime syndicates from Russia and other emerging cybercriminal undergrounds were executing their first major cybercrimes. Chinese leaders have since prioritized the development and acceleration of Internet technologies and, today, the size of China’s Internet use is massive and unparalleled at 800 million users.

However, this growth in Internet usage is not without irony as it has been accompanied by a significant increase in cybercriminal activity. Despite the Chinese government placing high importance on running one of the world’s most sophisticated Internet censorship systems, local cybercriminals are finding workarounds that contribute to China having one of the fastest growing cybercriminal underground economies.

China’s cybercrime enterprise is large, lucrative and expanding quickly. According to 2018 Internet Development Statistics, China’s cybercriminal underground was worth more than US $15 billion, nearly twice the size of its information security industry. The same Chinese-language source also shows that China’s cybercrime is growing at a rate of more than 30 percent a year. An estimated 400,000 people work in underground cybercriminal networks.

Changes in Tactics, Techniques and Procedures

In order to quickly scale up their businesses and maximize return on investment (ROI), Chinese cybercriminals have continuously adapted their tactics, techniques and procedures (TTPs). One significant change is that Chinese cybercriminals are slowly moving away from a high degree of one-to-one engagement through China’s popular QQ instant messaging platform to now establishing more formal cybercriminal networks. These networks use centralized advertising and standard service processes similar to Russian and other more sophisticated cybercriminal underground forums. Cybercriminals can access these centralized networks hosting on the deep web to post their products and services. A large amount of stolen data is available via automated services, where carders can order the credit and debit card information they want without having to interact with another user. With regard to hacking services, Chinese cybercriminals also offer modules for prospective clients to fill out their service requests, including types of attacks, target IP addresses, desirable malware or exploit toolkits and online payment processing. Through establishing a standardized model of sale, Chinese cybercriminals can expand their activity quickly without incurring additional overhead costs.

Attacks-as-a-service

Similar to other prominent cybercrime underworlds, Chinese cybercriminal underground markets are focused on providing excellent customer service. Many of the hackers expand their working hours to include weekends and even provide 24/7 technical support for customers who do not have a technical background. Distributed Denial of Service (DDoS) botnets, traffic sales, source code writing services, email/SMS spam and flooding services are available on the Chinese black markets.

Despite government censorship, a small number of Chinese cybercriminals still use dark web marketplaces to offer their services and products. Those marketplaces are typically specialized in the commercialization of stolen personally identifiable information (PII), bank accounts with high balances, hacking services, and malware customization. However, these darknet markets or hacking forums are not easily accessible because the Chinese government blocks the Tor anonymity network. A large number of Chinese cybercriminals continue to use exclusive and opaque QQ groups, Weibo fora and Baidu Teiba for advertising and communication. Chinese cybercriminals are also active on the clearnet. To avoid government censors and crackdowns, Chinese cybercriminals extensively use slang or other linguistic tactics for communication and advertising, which can be difficult for outsiders to comprehend. For instance, Chinese cybercriminals call a compromised computer or server “chicken meat.” Stolen bank accounts, credit card passwords, or other hijacked accounts are referred to as either “letters” or “envelopes.” Malicious websites and email accounts used for credential phishing attacks or spamming are referred to as “boxes.” Stolen information or details stored in the back of the magnetic stripe of a bank card are referred to as “data”, “track material” or simply “material.”

Moving Operational Base Abroad

Another noticeable trend is that an increasing number of Chinese cybercriminal gangs are moving their operational base abroad, using cryptocurrencies to launder money. They appear to prefer countries and jurisdictions with weak cybercrime legislation or weak enforcement, such as Malaysia, Indonesia, Cambodia and the Philippines. Since 2017, China’s Ministry of Public Security has uncovered over5,000 cases of cross-border telecommunication fraud involving more than US $150 million. Some of the cybercriminal groups are highly structured and work as traditional mafia-like groups that engage delinquent IT professionals; some Chinese cybercrime gangs are well-structured with clear divisions of labor and multiple supply chains. Members are typically located in close geographic proximity, even when the attacks are transnational.

Unique Culture and Practices

Chinese hackers employ different payment methods, recruiting strategies, and operating structures from other cybercriminal undergrounds. AliPay and bank transfers are the generally accepted payment methods advertised by Chinese-language hacking forums; many other forums typically prefer Monero and Bitcoin.

The “Master-Apprentice Mechanism,” which is a form of mentorship, plays a significant role in the Chinese hacking communities. Many Chinese hacker groups utilize the strategy to recruit new members or make profits. As shown in the following graph, QQ hacking group masters, usually masterminds of an organized crime group or an administrator of a hacking community, collect training fees from the members they recruit. These members, known as “apprentices” or “hackers-in-training” are required to participate in multiple criminal “missions” before they complete the training programs. Once training is complete, they are eligible to upgrade to full-time hackers working for their masters and responsible for downstream operations, such as targeted attacks, website hacking and database exfiltration.

Growth of Chinese Cybercrime

The Chinese cybercriminal underground has gone through drastic changes over the years. It gradually transformed from small local networks, targeting mostly Chinese businesses or citizens, to larger and well-organized criminal groups capable of hacking international organizations. My research indicates that there has been a growing threat activity targeting individuals and organizations in South Korea, Taiwan, Singapore, Germany, Canada and the United States. Chinese cybercriminals offer a wide variety of goods and services, ranging from physical counterfeit of US and Canadian driver’s licenses, scans of counterfeit US and Canadian driver’s licenses, US cell phone numbers, credit cards and identification cards to stolen social media and email accounts.

As shown in the following screenshots, 1 million stolen US emails accounts with encrypted passwords are selling for US $117; 1.9 million stolen German email accounts with clear text passwords are available on the Chinese black market for US $400. Counterfeit or scans of US or Canadian passports or drivers licenses are also for sale for as little as US $13.

As shown in the following screenshot, Chinese hackers are also selling stolen personal data, including identification cards and passports from Taiwan and South Korean citizens.

Login credentials for banks around the world are available on the Chinese cybercriminal underground market, and the higher the available balance of an account, the higher its selling price. Packages of hacked accounts from major US social media companies and networking platforms, gaming service providers, as well as media service providers are sold for as little as US $29 in the underground cybercrime market. These social media accounts are sometimes hacked with the intention of using them as a way to generate fake accounts to ensnare even more web users. A large number of email accounts from Taiwanese (i.e., @yahoo.com.tw) and South Korean email service providers (i.e., @nate.com, @yahoo.com.kr) are being sold on the Chinese black market.

Increasingly Difficult to Separate Cybercrime From Cyberespionage Activity

As the Chinese cybercriminal underground quickly expands its scope and sophistication, it is increasingly difficult to separate cybercrime from cyber espionage activity. This is especially true as I observe that Chinese cybercriminals offer services to spy on businesses and sell commodities that can be used to target businesses or government officials for economic and political espionage purposes. One of the most interesting items I found for sale in the Chinese cybercriminal underground is a full business dossier on Chinese companies and government agencies. Some Chinese hackers sell internal employee directories from high-profile technology companies. Chinese cybercriminals appear to work with malicious insiders or hire hackers to work as undercover agents inside of telecommunications service providers, financial services and technology companies to steal company secrets or other proprietary information. Documents include detailed contact information of CEOs and senior management from China’s top 50 companies. Other business proprietary information, such as credentials associated with a company’s various bank accounts, funding history, marketing strategies, and Tax Identification Number (TIN) are also available for sale on the black market. Malicious actors can use the above-mentioned information to launch targeted attacks against a business or leverage third-party vulnerabilities, such as trusted financial services, staffing firms and IT service providers to infiltrate a target system.

Conclusion

China’s cybercrime networks are rapidly growing in scope and sophistication. Compared to my earlier research paper on China’s cybercriminal underground from three years ago, Chinese cybercriminals have begun to embrace a sophisticated business-model approach and develop complex hierarchies, partnerships and collaboration with cybercriminal groups at home and internationally. These globally operating and organized cybercrime networks are basing themselves in countries with weak legal systems and law enforcement, while taking full advantage of global Internet connectivity to attack targets worldwide. A growing number of Chinese cybercriminals from these networks leverage the deep web to host their infrastructure and sell illegal goods and services, instead of relying on traditional peer-to-peer engagement through the QQ platform. To accelerate profitability, the Chinese hacking community has adopted tactics and techniques similar to Russian and other prominent cybercriminal underground markets to become more structured and service-oriented. In contrast, the Russian cybercriminal networks have been known for their multi-faceted criminal organizational structure specialized in monetizing PII theft and financial fraud. Yet, China’s cybecriminal underground, on the other hand, has placed greater emphasis on community and discipleship in achieving financial gains. Many of China’s cybercriminal networks incorporate this discipleship, also known as the “master-apprentice mechanism”, into a recruiting strategy that is largely different from their Russian counterparts. As China’s cybercrime continues to evolve and advance, international organizations operating in the Asia Pacific region are facing an expanding threat landscape from cybercriminal activity targeting high-value business assets. Intellectual property and identity theft can also cause substantial economic consequences.

The post How Chinese Cybercriminals Use Business Playbook to Revamp Underground appeared first on McAfee Blogs.