Soon, all countires in Europe, including the UK and Switzerland, will have the power to accept all and reject all cookies with a single click.
The post “Reject All” cookie consent button is coming to European Google Search and YouTube appeared first on Malwarebytes Labs.

Google will soon be giving European countries a “Reject All” button in the Search and YouTube cookie consent banner.

This change, which was revealed by Google’s Product Manager for Privacy, Safety & Security Sammit Adhya in a blog post, has already been rolled out in France and will be cascaded to the rest of the European Economic Area, the UK, and Switzerland. Adhya didn’t provide a date on the cascade.

From the Adhya’s post:

> “In the past year, regulators who interpret European laws requiring these banners, including data protection authorities in France, Germany, Ireland, Italy, Spain and the UK, have updated their guidance for compliance. We’re committed to meeting the standards of that updated guidance and have been working with a number of these authorities.”

With directions from France’s Commission Nationale de l’Informatique et des Libertés (CNIL), Google finished a redesign of its cookie banner and changed the infrastructure behind how it handles cookies.

CNIL slapped Google with a $170M (€150M) fine for the confusing language in its cookie consent banners earlier this year. CNIL also found the asymmetry of letting users accept all tracking cookies with one click but allowing them to painstakingly untick individual options to reject them all as “unlawful.” Because the average user typically doesn’t want to bother doing this, they are left with no choice but to click “Accept all”—a win for Google’s business.

France has a strong case for declaring Google’s cookie consent behavior. In a 2019 study conducted by academics at Ruhr University Bochum (Germany) and the University of Michigan (USA), researchers found that European consumers think that most cookie consent notices are meaningless or manipulative.

![](https://blog.malwarebytes.com/wp-content/uploads/2022/04/google-new-cookie-banner-600x565.png)

_Google has made it easy for users to accept and reject all cookies with this new consent banner first released to French users. (Source: Google)_

Adhya implied that this could be the first step for Google to change the way cookies work on its sites. He said he knew the implications of these changes and how they impact other sites and content creators who conduct business online.

> “We believe this update responds to updated regulatory guidance and is aligned with our broader goal of helping build a more sustainable future for the web. We believe it is possible both to protect people’s privacy online and to give companies and developers tools to build thriving digital businesses.”

“Reject All” cookie consent button is coming to European Google Search and YouTube

Four months after the Log4Shell vulnerability was disclosed, most affected open source components remain unpatched, and companies continue to use vulnerable versions of the logging tool.

Attackers who want to exploit the critical remote code execution vulnerability disclosed in the Apache Log4j logging tool over four months ago still have a vast array of targets to go after.

In a recent scan using the Shodan search engine, Rezilion found more than 90,000 Internet-exposed servers containing a vulnerable version of the software. The security vendor believes the number represents only a small fraction of available attacker targets because it only considers publicly facing servers running open source software. If internal network servers and servers running proprietary applications are factored in, the total number of vulnerable targets is likely much higher, Rezilion said.

A Rezilion report this week that summarized the results of its study pointed to other data points that appear to bolster the company's conclusion.

Among them is data from a Google open source scanning service called Open Source Insights, which showed that just 7,140 Java packages out of a total of 17,840 affected packages have been patched for Log4Shell since the flaw was disclosed. Another data point from Sonatype found that as of Apr. 20, 2022, some 36% of Log4j versions being actively downloaded from the Maven Central Java application repository were still vulnerable to Log4Shell — a number that has remained largely unchanged since February.

"Similar to other historic high-profile vulnerabilities, even though four months have passed, there is still a huge attack surface that is vulnerable to Log4Shell," says Yotam Perkal, director of vulnerability research at Rezilion. "The 90,000 publicly accessible vulnerable servers are probably only the tip of the iceberg in terms of actual vulnerable attack surface."

The Apache Foundation disclosed the Log4Shell vulnerability (CVE-2021-44228) along with an updated and fixed version of the software on Dec. 9, 2021. The flaw is present in virtually every Java application environment, is considered trivially easy to exploit, and gives attackers a way to gain complete control over vulnerable systems. Many security experts consider the flaw to be one of the most dangerous to be disclosed in recent memory, and they have urged organizations to install the updated and fixed version of the software as soon as possible.

Despite the high concerns, there have been very few publicly reported instances of the flaw being exploited in a major breach. However, there are considerable fears that in many cases attackers may have already quietly exploited the flaw to gain access to enterprise networks and are waiting for an opportune moment to strike.

Security experts have pointed to the ubiquity of the flaw and the difficulty involved in detecting it — Java files containing the flaw can sometimes be buried deep inside applications — as potential reasons for the slow remediation pace so far.

Rezilion said one issue is that many people are unwittingly using software that relies on vulnerable versions of Log4j either because they don't have visibility into their software components or are using vulnerable third-party software. The Log4j flaw has also proven to be challenging to detect in production environments.

**Tip of the Iceberg?**  
Perkal says that the 90,000 vulnerable servers that Rezilion found via a Shodan search contained open source components with obsolete — and therefore potentially vulnerable — versions of Log4j; components with up-to-date Log4j versions that contained evidence of use of previous, potential vulnerable versions; and public-facing Minecraft servers with vulnerable Log4j versions.

"There are probably a lot of servers running these applications on internal networks and hence not visible publicly through Shodan," Perkal says. "We must assume that there are also proprietary applications as well as commercial products still running vulnerable versions of Log4j."

Significantly, all the exposed open source components contained a significant number of additional vulnerabilities that were unrelated to Log4j. On average, half of the vulnerabilities were disclosed prior to 2020 but were still present in the "latest" version of the open source components, he says. Rezilion's analysis showed that in many cases when open source components were patched, it took more than 100 days for the patched version to become available via platforms like Docker Hub.

Nicolai Thorndahl, head of professional services at Logpoint, says flaw detection continues to be a challenge for many organizations because while Log4j is used for logging in many applications, the providers of software don't always disclose its presence in software notes. "So, many companies don't actually know if it is being used in their system or not," Thorndahl says.

Often, many applications are using old versions of Log4j that are no longer being supported and are vulnerable. "Very few, if any, companies have a \[configuration management database\] so detailed that it would show where they are using Log4j," he says.

Thorndahl expects there will be more attacks exploiting the flaw, even though there have been very few so far.

"Most likely what we will see down the line, maybe four months, maybe a year, as we have seen before, is that incidents will be disclosed \[where\] companies detected they have been breached and the Log4j vulnerability was used and they probably had access for a long period of time," he says.

Log4j Attack Surface Remains Massive

The move to IaC has its challenges but done right can fundamentally improve an organization's overall security posture.

Infrastructure as code (IaC) has become a core part of many organizations' IT practices, with adoption of technologies like HashiCorp's Terraform and AWS CloudFormation increasing rapidly. The move to IaC sees companies moving away from either manually configuring servers or using imperative scripting languages to automate those changes and toward a model in which declarative code is used to outline a resource's preferred final state.

As with any change in approach to IT, there are security considerations to understand. The move to IaC presents some risks along with opportunities to improve the way companies secure their environments. Given IaC's key role in configuring the security parameters of an organization's systems and the speed at which a flawed template could be rolled out across a large number of systems, ensuring that good security practices are adhered to is vital to making the best use of this technology.

**IaC Security Risks and Opportunities**  
With the move to IaC, there are new security risks to consider. The first is secrets management. When creating and managing resources, credentials will often be needed to authenticate to remote systems; when IaC code is written to automate these tasks, there is a risk that credentials or API keys may be hard-coded into the code. Care should be taken to ensure that proper secrets management processes are followed to avoid this. Secrets should be held in a secure location, such as a cloud key management service (KMS), and retrieved on demand by scripts as they run.

A second risk is that misconfigurations may creep into the IaC templates — for example, if code is copy/pasted in from an external source — and then propagate throughout an environment quickly as the IaC is used. Avoiding this risk requires both automated and manual review, as with any other source code.

The opportunity inherent in moving to IaC-driving environments is that once all of your infrastructure is defined in code, it's possible to apply common automated linters and review tools to it to ensure that good practices are followed. Tooling can draw from common libraries of good practice and be supplemented with custom rules that apply organization-specific practices.

Additionally, with an IaC-based approach, all configurations should be stored in version- controlled source code repositories. This provides improved tracking of changes so that companies can track modifications over time and also ensure appropriate access control and that auditing is in place.

Lastly, IaC-based deployment means that test environments should be able to effectively mirror production, meaning that security testing can be safely conducted with higher confidence that any results will be meaningful in production.

**IaC Technology Stacks**  
There are a variety of options for IaC. Typically, large organizations will use many of these at the same time, as different tools have different strengths and weaknesses.

Terraform from HashiCorp is one of the most widely used IaC toolsets. It has the advantage of being open source and not tied to any one cloud platform or infrastructure provider, meaning that it works across a range of environments.

Unsurprisingly, the major cloud service providers also have IaC toolsets that focus on their clouds. Amazon's CloudFormation, Microsoft's ARM and Bicep, and Google's Cloud Deployment Manager all provide a means for users of that company's cloud to take advantage of the IaC paradigm.

Another popular option for cloud-native IaC is Pulumi, which allows developers to use programming languages they already know (e.g., JavaScript or Golang) to write their IaC templates.

**IaC Review Tools**  
There are a number of open source tools that can help with the process of security reviews of IaC code. These tools take a similar approach in providing a rule set of common security misconfigurations for a given set of IaC languages. In addition to the main IaC format, some of these tools will review other formats, like Kubernetes manifests and Dockerfiles. Some of the commonly used tools in this arena include the following:

*   Trivy is a vulnerability and misconfiguration scanner that includes rules from the tfsec and cfsec projects covering Terraform and CloudFormation, as well as a set of rules for Kubernetes and Docker. It can be easily integrated into a CI/CD pipeline and run by developers as part of the coding environment.
*   Checkov is a tool written in Python that covers a wide range of IAC languages, including Terraform, CloudFormation, Azure Bicep and ARM, and Kubernetes manifests. It also helps with the challenge of ensuring that IaC files don't hard-code secrets by scanning for instances where this can occur.
*   Terrascan is another popular option for IaC scanning. Despite the name, it supports a range of IaC formats in the same way as Trivy and Checkov. Similarly to Trivy, Terrascan is written in Golang and can be integrated into CI/CD pipelines and run as a standalone program.

**Smoothing the Security Path**  
The move to IaC is well underway at a variety of organizations. While it does bring challenges, the process — if well handled — can fundamentally improve organizations' overall security posture by allowing all of their system configurations to be held in version-controlled source code repositories and regularly checked for misconfigurations.

Given the power of IaC, it is vital that its adoption be accompanied by strong security practices, with scanning and validation key to those processes. By using open source review tools like the ones mentioned above, companies can help to smooth their path in adopting this technology.

The Ins and Outs of Secure Infrastructure as Code

By Waqas
The vulnerability that existed for the last 8 months allowed attackers to weaponize the VirusTotal platform to achieve…
This is a post from HackRead.com Read the original post: Critical RCE Vulnerability Reported in Google’s VirusTotal

**The vulnerability that existed for the last 8 months allowed attackers to weaponize the VirusTotal platform to achieve remote code execution on an unpatched 3rd party sandboxing machine employing anti-virus engines.**

In January 2022, a report dubbed “VirusTotal Hacking” revealed how the platform can be used to access stolen login credentials and other sensitive files. Now, the IT security researchers at CySource have reported a method to abuse the VirusTotal malware scanning service to execute arbitrary commands and access multiple internal hosts remotely by using a remote code execution (RCE) vulnerability (CVE-2021-22204).

According to researchers, the vulnerability could allow attackers to weaponize the VirusTotal platform and achieve remote code execution on an unpatched 3rd party sandboxing machine employing anti-virus engines.

**How Could the Vulnerability be Exploited?**

Israeli security services provider CySource’s researchers Shai Alfasi and Marlon Fabiano da Silva embedded a payload in the DjVu file’s metadata for exploiting the vulnerability, identified in ExifTool open-source utility. This utility extracts Exchangeable Image File annotations, metadata, and tags.

Moreover, it can trigger another vulnerability to obtain remote code execution. This vulnerability is triggered by DjVu files and was identified by researcher William Bowling in 2021 in ExifTool 12.23. It was surprising that none of the VirusTotal anti-virus scanners could detect the CySource researchers’ Base64 encoded payload they included in the malicious DjVu file’s metadata.

> “Instead of ExifTool detecting the metadata of the file, it executes our payload.”
> 
> CySource

The researchers also got a reverse shell that allowed them to access over 50 internal network hosts with high privileges at Google and its other VirusTotal security vendor partners. Every time they uploaded a file with a new hash and a new payload, VirusTotal forwarded it to bots.

This indicates that apart from an RCE, the payload was forwarded by Google servers to the company’s internal network, partners, and customers as well. When researchers were able to invade the networks, they mapped out various services, including MySQL, Kubernetes container orchestration, Oracle databases, web applications, and Secure Shell (SSH).

**More Vulnerability News on Hackread.com**

1.  Hackers mining Monero on Microsoft SQL databases for last 2 years
2.  Hackers are using a 19-year-old WinRAR bug to install nasty malware
3.  12-Year-Old vulnerability in Windows Defender risked 1 billion devices
4.  Google, Microsoft and Oracle generated the most vulnerabilities in 2021
5.  Google Drive accounted for 50% of malicious Office document downloads

**Google Released Patch after Eight Months**

The vulnerability was disclosed to Google’s vulnerability reward program in April 2021, and the report was accepted in May 2021. However, the fix was dispatched in January 2022, after which CySource received the green signal to share details of the bug.

It is still unclear why Google took so long to fix this vulnerability. VirusTotal is a trusted service from Google’s subsidiary Chronicle, offering access to more than 70 different anti-virus scanning solutions from mainstream security vendors, including ESET, Kaspersky, and 360 Total Security. It is, therefore, quite shocking that a dangerous remote code execution vulnerability plagued this service for over eight months.

![](https://secure.gravatar.com/avatar/cf728b76a63b387b11edeafcb1b9b654?s=100&d=wavatar&r=g)

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Critical RCE Vulnerability Reported in Google’s VirusTotal

Unauthenticated Cross-Site Scripting (XSS) vulnerability in Tripetto's Tripetto plugin <= 5.1.4 on WordPress via SVG image upload.

CVE-2021-36895: WordPress form builder plugin for contact forms, surveys and quizzes – Tripetto

An issue was discovered in CipherMail Webmail Messenger 1.1.1 through 4.1.4. A local attacker could access secret keys (found in a Roundcube configuration file) that are used to protect Webmail user passwords and two-factor authentication (2FA).

CVE-2022-28218: Webmail Messenger release notes - CipherMail Email Encryption

Making document.domain immutable

![Google is about to depreciate a little-used and insecure web dev hack](https://portswigger.net/cms/images/97/da/bdef-article-220426-chrome-main-image.png "tanuha2001 / Shutterstock")

Web developers who rely on a workaround that relaxed the same origin policy to allow sub-domains to exchange content will soon need to take a different approach.

Starting with the upcoming Chrome 106 release, Google’s web browser will close a loophole that went against best practices as well as, more importantly, posing a danger in hosted environments.

More specifically, starting from Chrome 106, websites will be unable to set ‘document.domain’, a technique that allows same-site-but-cross-origin communications.

Read more of the latest news about browser security

The current mainstream release of Google’s browser – Chrome 100 – already throws up a warning about the soon-to-be depreciated facility that allows website developers to take advantage of document.domain to relax the same-origin policy.

Website developers are urged to scan their website to access the potential impact of the deprecation of document.domain before swamping out instances where the “hack” has been applied for more secure method of cross-origin communication, as explained in a recent blog post by Google.

“On Chrome, websites will be unable to set document.domain. You will need to use alternative approaches, such as postMessage() or the Channel Messaging API, to communicate cross-origin,” Google explains.

“If your website relies on same-origin policy relaxation via document.domain to function correctly, the site will need to send an Origin-Agent-Cluster: ?0 header, as will all other documents that require that behavior.”

These alternative techniques have existed for some years however in reality, few developers rely on document.domain to relax the same-origin policy.

**Disavowed**

Google is effectively killing a feature that is not widely used and is gaining a huge security benefit as a result.

The development switches the browser security paradigm from site isolation to origin isolation – drastically reducing the utility of Spectre-style attacks in the process.

Google and other browser makers are laying the groundwork for preventing attackers from pivoting between sub-domains using Spectre-style attacks.

The same-origin policy offers assurances that any web page cannot access (modify, or extract data from) another page, unless those pages are hosted on the same origin.

The use of document.domain by web devs runs contrary to this rubric and poses a particular threat in the context of Spectre-style attacks, as a Github post by Google Chrome security developer Mike West illustrates.

**Host of problems**

Websites set document.domain in order to allow same-site documents to communicate more easily. Whilst offering convenience benefits, the approach introduces a security risk, as Google explains.

If a hosting service provides different subdomains per user, an attacker can set document.domain to pretend they are the same-origin as another user’s page.

Further, an attacker can host a website under a shared hosting service, which serves sites through the same IP address with different port numbers.

In that case, the attacker can pretend to be on the same-site-but-same-origin as yours. This is possible because document.domain ignores the port number part of the domain.

Other browser makers, including Mozilla, are also looking to depreciate document.domain.

RELATED Spectre attacks against websites still a serious threat, Google warns

Disavowed: Chrome plans to deprecate ‘document.domain’ lays the groundwork for shift in browser security

By Deeba Ahmed
Hackread.com earlier reported a website designed by software engineer Philip Wang that can create realistic faces of people…
This is a post from HackRead.com Read the original post: New Scam Utilizing AI-Generated Images to Represent Fake Law Firm

**Hackread.com earlier reported a website designed by software engineer Philip Wang that can create realistic faces of people who don’t even exist simply by clicking the Refresh button.**

**Non-Existent People Posed as Boston Law Firm**

It may seem like a story straight out of a Hollywood script, but it is indeed true that scammers are using AI-generated images to scam people. According to Ben Dickson of TechTalks, he received an email from a law firm’s attorney, which turned out to be fake, and surprisingly, the sender didn’t even exist.

**Details of the Scam**

In his blog post published in TechTalks, Dickson wrote that on April 13, Nicole Palmer sent an email citing “DMCA Copyright Infringement Notice.” The email introduced Nicole as a Trademark Attorney of Arthur Davidson Legal Services and claimed that the recipient had used an image in TechTalks that belonged to one of her clients.

“Our client is happy for their image to be used and shared across the internet. However, proper image credit is due for past or ongoing usage,” the email supposedly sent by Nicole read.

The email contained references to Section 512(c) of DMCA with a professional signature that made it appear legit. If it wasn’t done, Nicole threatened legal action against Dickson.

![](https://www.hackread.com/wp-content/uploads/2022/04/Nicole-Palmer-fake-email-side-1024x332.jpg)

DMCA Notice (Image: TechTalks)

**How was the Scam Discovered?**

Dickson spent around 7 days adding credit to that image and a homepage to Nicole’s client’s website. But, when he couldn’t be successful, he re-read the email and identified something off. It was a link to an image-sharing website called Imgur. On this site, anyone can upload images without creating a profile.

“So it was perfectly possible that they had downloaded the image from my website, uploaded it on Imgur, and then claimed that their image was there before mine,” Dickson wrote.

Dickson had taken that image from Pexels, a license-free stock photo library. He emailed Nicole with proof that no attribution was needed and waited for a reply. When he didn’t receive a response, he checked out her legal firm Arthur Davidson Legal website, which seemed authentic with profiles of 18 lawyers who graduated from prestigious institutions, 420 cases, and a 90% success rate with 380 wins.

A quick Google search didn’t yield any results of such a well-known law firm either. Red flags were raised when Dickson noted the website domain was set up in February 2022 while the firm was established in 2009.

Later, it turned out that Nicole Palmer didn’t even exist because when Dickson checked her photograph on the website, he learned that a generative adversarial network created the image.

![New Scam Utilizing AI-Generated Images to Represent a Fake Law Firm](https://www.hackread.com/wp-content/uploads/2022/04/fake-nicole-palmer.jpg)

Fake AI-Generated Image of Nicole Palmer (Image: TechTalks)

It is worth noting that in 2019, Hackread.com reported a website (thispersondoesnotexist.com) designed by software engineer Philip Wang that can create realistic faces of people who don’t even exist simply by clicking the Refresh button.

It is quite possible that Palmer’s image was also created using the same website. Nevertheless, watch out for fake emails claiming to represent law firms or threatening people with phony DMCA notices or subpoenas.

1.  AI firm exposes 2.5 million sensitive medical records online
2.  ‘Optical Adversarial Attack’ uses a low-cost projector to trick AI
3.  New Underactor tool reveals pixelated text to expose sensitive data
4.  Ukrainian News Channel Hacked to Run Deepfake video of President Zelensky
5.  These people don’t exist – They were created by tech using Artificial Intelligence

New Scam Utilizing AI-Generated Images to Represent Fake Law Firm

Ransomware continues as the top threat, while a novel increase in APT activity emerges




By Caitlin Huey.
Ransomware was still the top threat Cisco Talos Incident Response (CTIR) saw in active engagements this quarter, continuing a trend that started in 2020. As mentioned in the 2021...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

**Ransomware continues as the top threat, while a novel increase in APT activity emerges**

![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_m4GPG0IRtDZT8UPmsyLr0gHPUOZG1xe-nqkh_-htxekZ2VwXvCDwQ8BYNRdgArcMmYzlZFnuF0jeHt6cX635yT0RoREd4bm8DmU2JUzXrdw3rsGmOB8tMP6AvQ1RHXqXJXrFF_aM73nFmVAh8Q3U1yVoIP7sM9E5QwxT2wmK99_PaSTG7iyWXvVm/s16000/TIR_quarterly_trends_banner.jpg)

_By Caitlin Huey._

Ransomware was still the top threat Cisco Talos Incident Response (CTIR) saw in active engagements this quarter, continuing a trend that started in 2020. As mentioned in the 2021 year-in-review report, CTIR continues to deal with an expanding set of ransomware adversaries and major cybersecurity incidents affecting organizations worldwide.  

![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUDkQFdigkJg7M2nBf3gqfEKhHJO6U55wD02LN9awloHiV14wGiJp9DeUDcT8UHImiNQsCzeR08Omtjk6FCRRyYYrRg4ffp-oVJ793zZLouMKN3LHw8G0JAoUG_VtyM_3C-yISYFTlWoTN7Uc0DAUawRa3FyPe6Rz4XBddpnrDWdE8aSqRv3HRC_mL/w200-h48/blog-onepager-button.jpg)

The first quarter of 2022 also featured an increase in engagements involving advanced persistent threat (APT) activity. This included Iranian state-sponsored MuddyWater APT activity, China-based Mustang Panda activity leveraging USB drives to deliver the PlugX remote access trojan (RAT), and a suspected Chinese adversary dubbed “Deep Panda” exploiting Log4j. 

**Targeting**

A wide variety of verticals were targeted, including education, energy, financial services, health care, industrial production and equipment, local government, manufacturing, real estate, telecommunications and utilities. The top targeted vertical was telecommunications, following a trend where it was among the top targeted verticals in the previous quarter, closely followed by organizations in the education and government sectors. 

**Threats**

Ransomware continued to comprise the majority of threats CTIR responded to. No one ransomware family was observed twice in incidents that closed out this quarter. This is indicative of a trend toward greater democratization of ransomware adversaries that Talos began observing last year. This quarter also saw the appearance of emerging ransomware families, including Cerber (aka CerberImposter), Entropy and Cuba. There were also high-profile ransomware families, such as Hive and Conti. 

CTIR observed ransomware adversaries exfiltrating sensitive data supporting double extortion as another method to further compel victims to pay the ransom, a continuation of a trend that began in the winter of 2019. For example, in an Entropy ransomware engagement affecting a local government organization, CTIR identified traffic and activity associated with mega\[.\]nz, a utility commonly used for file transfer and data exfiltration. It was first observed executing from the following path: "C:\\Users\\admin\\AppData\\Local\\MEGAsync\\MEGAsync.exe".  

After ransomware, the next most commonly observed threat this quarter included exploitation of Log4j, the Apache logging utility commonly used by organizations globally. Adversaries have continued to exploit Log4j (CVE-2021-44228, CVE-2021-45046, and related vulnerabilities) since the security flaws were initially published in December 2021. In January 2022, CTIR started to observe a growing number of engagements in which adversaries are attempting to exploit Loj4j in vulnerable VMware Horizon servers. 

In one engagement affecting an education institution, CTIR found evidence of PowerShell scripts including a line that killed the process “ws\_TomcatService.exe”, a key parent process in commonly observed malicious Log4j activity. The combination of the timeframe and the unpatched, vulnerable state of the VMware Horizon server suggests that Log4j exploitation was a probable root cause of the compromise. The adversary also installed cryptocurrency miners; conducted reconnaissance with Bloodhound, an application used to enumerate relations within Active Directory (AD); created at least one local “DomainAdmin” account; and leveraged remote desktop protocol (RDP) for potential lateral movement. 

**Advanced persistent threats**

As mentioned above, CTIR observed a novel increase in APT activity in engagements compared to previous quarters. This includes activity associated with Iranian state-sponsored MuddyWater, China-based Mustang Panda deploying the PlugX RAT, and a suspected Chinese state-sponsored actor dubbed Deep Panda leveraging Log4j. 

For example, a health care organization was affected by threat activity associated with Deep Panda in which the adversary exploited Log4j to deploy a custom backdoor. CTIR initially observed a PowerShell command that downloaded three additional files — “1.bat”, “syn.exe” and “l.dll” — from the attacker’s server, which has been linked to the adversary by other security firms. The PowerShell script executes “1.bat,” which subsequently executes “syn.exe” and proceeds to delete all three files from the disk. The “syn.exe” file creates a service set to autorun and is launched via “svchost.exe”. The “1.dll” file is packed with Themida, which is used to detect monitoring programs that may be used for malware reversing.    

In another engagement affecting a telecommunications organization, CTIR’s research provided moderate to high confidence that several of the indicators of compromise (IOCs) and tactics, techniques and procedures (TTPs) discovered were linked to Mustang Panda. The initial compromise was determined to be due to a malware-infected USB connected to corporate resources that subsequently deployed PlugX, a RAT commonly deployed by Mustang Panda that steals credentials from compromised machines. After the USB was connected to the corporate environment for approximately one hour, a hidden directory was created within “C:\\ProgramData” containing files associated with PlugX. The variant can uniquely spread via USB, which distinguishes it from other PlugX variants. This PlugX variant creates a hidden folder named “RECYCLE.BIN” and copies three files: a benign EXE, a loader DLL and an encrypted DAT file. The malware hides all of the folders in the root directory and creates LNK files for each one in order to deceive the victim. In this instance, the malware used legitimate Avast-signed executables to sideload a malicious PlugX DLL.  

**Initial vectors**

For the majority of engagements, identifying an initial vector was difficult due to shortfalls in logging and visibility. However, in engagements in which the initial vector could be confirmed, or reasonably assumed, this quarter featured a number of engagements where adversaries exploited public-facing applications that were vulnerable to Log4j. For example, in one engagement affecting a telecommunications company, CTIR observed a large number of PowerShell download requests to an IP address associated with Log4j exploitation attempts against vulnerable VMware Horizon servers. Following this activity, high CPU usage was detected on a VMware Horizon server, leading to the identification of several clusters of cryptocurrency miners, consistent with typical cryptocurrency miner threat actor behavior following the release of high-profile vulnerabilities.

In a Cerber ransomware incident affecting a holding company, the adversary used vulnerabilities affecting GitLab (CVE-2021-22204 and CVE-2021-22205) to upload and execute code remotely, ultimately granting unauthorized access to that system in the context of the "git" account. This is consistent with reporting from other security firms on a new version of Cerber ransomware targeting Atlassian Confluence and GitLab servers with older RCE vulnerabilities. The adversary attempted to expand access through privilege escalation and lateral movement and ultimately executed ransomware.  

**Security weaknesses**

The top recommendation that responders have for organizations is to implement multi-factor authentication (MFA) on all critical services, including endpoint detection response (EDR) solutions. MFA is an effective way to prevent adversaries from gaining unwanted access, and we routinely see threat activity that could have been prevented if MFA had been enabled.  

In one engagement that kicked off this quarter affecting a telecommunications company involving pre-ransomware TTPs, the adversary compromised the organization’s help desk/call center partner company. This was identified as the root cause of the compromise due to the third party having access to the organization’s Citrix machines while not enabling MFA. CTIR recommends that all third parties in the environment are following MFA security policies and guidelines.

**Top-observed MITRE ATT&CK techniques**

Below is a list of the MITRE ATT&CK techniques observed in this quarter’s IR engagements. Given that some techniques can fall under multiple tactics, we grouped them under the most relevant tactic in which they were leveraged. The table below represents the techniques used with a relevant example, and the approximate number of times seen. However, it is not an exhaustive list.

Key findings from the MITRE ATT&CK appendix include: 

*   We observed an increase in engagements in which initial access was achieved via phishing with a malicious link or document that relied upon subsequent user execution. Compared to last quarter, we observed more threats leveraging social engineering techniques, as well as masquerading as legitimate files or utilities to entice users to click or execute a given link or file.
*   Due to the number of engagements responders supported that exploited Log4j, we observed an increase in techniques relying on exploiting unpatched and vulnerable public-facing applications. This coincides with our observations of adversaries capitalizing on organizations’ lack of up-to-date patches and improper data protections.
*   We saw a large increase in defense evasion and collection techniques compared to previous quarters. The observed collection techniques exhibited the actors’ interest in specific information, including collecting details about certain hosts that could be used for targeting, keylogging to access credentials in the browser, and selecting particular files of interest for possible exfiltration.  
*   Consistent with last quarter’s findings, we continued to see a reliance on utilities such as PsExec and Cobalt Strike and a variety of remote access software, such as TeamViewer and ScreenConnect, to facilitate remote access. 

Tactic

Technique

Example

Initial Access (TA0001)

T1190 Exploit Public-Facing Application

Attackers successfully exploited a vulnerable application that was publicly exposed to the Internet.

Reconnaissance (TA0043)

T1592 Gather Victim Host Information

Malicious file contains details about host

Persistence (TA0003)

T1053 Scheduled Task/Job

Scheduled tasks were created on a compromised server

Execution (TA0002)

T1059.001 Command and Scripting Interpreter: PowerShell

Executes PowerShell code to retrieve information about the client's Active Directory environment

Discovery (TA0007)

T1087 Account Discovery

Use a utility like ADRecon to enumerate information on users and groups

Credential Access (TA0006)

T1003.001 OS Credential Dumping: LSASS Memory

Use “lsass.exe” for stealing password hashes from memory

Privilege Escalation (TA0004)

T1574.002 Hijack Execution Flow: DLL Side-Loading

A malicious PowerShell script attempted to side-load a DLL into memory

Lateral Movement (TA0008)

T1021.001 Remote Desktop Protocol

Adversary made attempts to move laterally using Windows Remote Desktop

Defense Evasion (TA0005)

T1027 Obfuscated Files or Information

Use base64-encoded PowerShell scripts

Command and Control (TA0011)

T1219 Remote Access Software

Remote access tools found on the compromised system

Impact (TA0040)

T1486 Data Encrypted for Impact

Deploy Conti ransomware and encrypt critical systems

Exfiltration (TA0010)

T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage

Actor exfiltrated data to file sharing site mega\[.\]nz

Collection (TA0009)

T1114.003 Email Collection: Email Forwarding Rule

Adversary used a compromised account to create a new inbox rule to place emails in a folder

Software/Tool

S0029 PsExec

Adversary made use of PsExec for lateral movement

Quarterly Report: Incident Response trends in Q1 2022

Researchers propose fresh approaches to cloud-security bugs and mitigating exposure, impact and risk.

Researchers propose fresh approaches to cloud-security bugs and mitigating exposure, impact and risk.

Big gaps exist in the 22-year-old Common Vulnerability and Exposures (CVE) system that do not address dangerous flaws in cloud services that drive millions of apps and backend services. Too often, cloud providers needlessly expose customers to risk by not sharing the details of bugs discovered on their platform. A CVE-like approach to cloud bug management must exist to help customers weigh exposure, impact and mitigate risk.

That is the opinion of a growing number of security firms pushing for a better cloud vulnerability and risk management. They argue because of CVE identification rules, which only assign CVE tracking numbers to vulnerabilities that end-users and network admin can directly manage, the current model is broken.

MITRE, the non-profit organization behind the CVE system, does not designate CVE IDs for security issues deemed to be the responsibility of cloud providers. The assumption is that cloud providers own the problem, and that assigning CVEs that are not customer-controlled or patched by admins falls outside of the CVE system purview.

_\[**Editor’s Note:** This article was originally published in the free Threatpost eBook “Cloud Security: The Forecast for 2022.” In it we explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists. Please download the FREE eBook for the full story\]_

“\[It is a false\] assumption that all issues can be resolved by the cloud provider and therefore do not need a tracking number,” wrote Scott Piper, a cloud-security researcher with Summit Route, in a recent blog. “This view is sometimes incorrect, and even when the issue can be resolved by the cloud provider, I still believe it warrants having a record.”

Piper’s critiques are part of his introduction to a curated list of dozens of documented instances of cloud-service provider mistakes that he says prove the point.

Over the past year, for example, Amazon Web Services snuffed out a host of cross-account vulnerabilities. As well, Microsoft recently patched two nasty Azure bugs (ChaosDB and OMIGOD). And, last year, Alphabet’s Google Cloud Platform tackled a number of bugs, including a policy-bypass flaw.

“As we uncover new types of vulnerabilities, we discover more and more issues that do not fit the current \[MITRE CVE reporting\] model,” wrote cloud researchers Alon Schindel and Shir Tamari with the cloud security firm Wiz, in a post. “Security industry call to action: we need a \[centralized\] cloudvulnerability database.”

The researchers acknowledged that cloud service providers do respond quickly to cloud bugs and work fast to mitigate issues. However, the process of identifying, tracking and helping those affected to assess risk needs streamlining.

![AWS computing](https://media.threatpost.com/wp-content/uploads/sites/103/2020/08/21091044/podcast-news-wrap-300x203.jpg)

An example: When researchers found a series of cross-account AWS vulnerabilities in August, Amazon moved quickly to mitigate the problem by changing AWS defaults and updating the user set-up guides. Next, AWS emailed affected customers and urged them to update any vulnerable configurations.

“The problem here is that \[many\] users weren’t aware of the vulnerable configuration and the response actions they should take. Either the email never made it to the right person, or it got lost in a sea of other issues,” Schindel and Tamari wrote.

In the context of cloud, affected users should be able to easily track a vulnerability and whether it has already been addressed in their organizations, as well as what cloud resources have already been scoped and fixed, the researchers said.

The CVE approach to cloud bugs also has the support of the Cloud Security Alliance (CSA), which counts Google, Microsoft and Oracle as executive members.

**Cloud Bug CVE Approach: Shared Industry Goals**

The efforts share many of the same goals, including:

*   Standardized notification channels to be used by all cloud service providers
*   Standardized bug or issue tracking
*   Severity scoring to help prioritize mitigation efforts
*   Transparency into the vulnerabilities and their detection

In August, Brian Martin, on his blog Curmudgeonly Ways, pointed out that MITRE’s history covering cloud vulnerabilities is mixed.

“At times, some of the CVE (editorial) Board has advocated for CVEs to expand to cover cloud vulnerabilities, while others argue against it. At least one who advocated for CVE coverage said they should get CVE IDs, \[with\] others that supported and disagreed with the idea saying that if cloud was covered, \[those bugs\] should get their own ID scheme,” he wrote.

Martin also pointed out that even if a CVE-like system were created, the question remains: Who will run it?

“The only thing worse than such a project not getting off the ground is one that does, becomes an essential part of security programs, and then goes away,” he said.

In July, under the auspices of CSA, the Global Security Database Working Group was chartered to go one step further than the idea of expanding CVE tracking. Its goal is to offer an alternative to CVEs and what the group called a one-size-fits-all approach to vulnerability identification. The working group believes the “on-demand” nature and continued growth of IT infrastructures brought on by cloud migration necessitate a corresponding maturity in cybersecurity.

“What we see is a need to figure out how to create identifiers for vulnerabilities in software, services and other IT infrastructure that is proportional to the amount of technology in existence,” said Jim Reavis, cofounder and chief executive officer of CSA, when introducing the working group. “The common design goal is for vulnerability identifiers to be easily discovered, fast to assign, updatable and publicly available” – not just in the cloud, but across IT infrastructure.

**_Moving to the cloud? Discover emerging cloud-security threats along with solid advice for how to defend your assets with our_** **_FREE downloadable eBook_****_, “Cloud Security: The Forecast for 2022.”_** **_We explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists._**

Tag

#google