The previously unknown state-sponsored group is compromising industrial targets with the ShadowPad malware before burrowing deeper into networks.

A previously unknown Chinese-speaking advanced persistent threat (APT) is exploiting the ProxyLogon Microsoft Exchange vulnerability to deploy the ShadowPad malware, researchers said — with the end goal of taking over building-automation systems (BAS) and moving deeper into networks.

That's according to researchers at Kaspersky ICS CERT, who said that the infections affected industrial control systems (ICS) and telecom firms in Afghanistan and Pakistan, as well as a logistics and transport organization in Malaysia. The attacks came to light in October but appear to date back to March 2021.

"We believe that it is highly likely that this threat actor will strike again and we will find new victims in different countries," according to Kaspersky's Monday analysis.

In this specific spate of attacks, Kaspersky observed a unique set of tactics, techniques, and procedures (TTPs) linking the incidents together, including attackers compromising BAS engineering computers as their initial access point. Researchers noted this is an unusual move for an APT group, despite proof-of-concept malware being available for such platforms.

"Building-automation systems are rare targets for advanced threat actors," said Kirill Kruglov, security expert at Kaspersky ICS CERT, in the alert. "However, those systems can be a valuable source of highly confidential information and may provide the attackers with a backdoor to other, more secured, areas of infrastructures."

The attacks also threaten the physical integrity of buildings, researchers warned. BAS infrastructure unites operational features, such as electricity, lighting, HVAC systems, fire alarms, and security cameras, so they can be managed from a single management console.

"Once a BAS is compromised, all processes within that are at risk, including those relating to information security," according to Kaspersky's alert about the attacks.

In a real-world example of this rare kind of attack, last December a building automation engineering firm suddenly lost contact with hundreds of its BAS devices, including light switches, motion detectors, shutter controllers, and others — after being locked down with the system's own digital security key, which the attackers hijacked. The firm had to revert to manually flipping on and off the central circuit breakers in order to power on the lights in the building.  

**ProxyLogon Leads to ShadowPad Malware in Stealthy Infections**

In many cases, the cyberattackers exploited the ProxyLogon remote code-execution (RCE) vulnerability in MS Exchange (CVE-2021-26855), the firm added. When used in an attack chain, the exploits for these ProxyLogon could allow an attacker to authenticate as the Exchange server and deploy a Web shell so they can remotely control the target server.

ProxyLogon was disclosed in March 2021 after being exploited as a zero-day bug by a Chinese state-sponsored group that Microsoft calls Hafnium — but soon a dizzying array of threat groups piled on to exploit the issue to enable different kinds of attacks.

In this case, once in, the APT deploys the ShadowPad remote access Trojan (RAT) — a popular backdoor and loader used by various Chinese APTs. According to previous analysis from Secureworks, ShadowPad is advanced and modular, first deployed by the "Bronze Atlas" threat group in 2017. "A growing list of other Chinese threat groups have deployed it globally since 2019 in attacks against organizations in various industry verticals," the report noted.

Kaspersky researchers said that in the BAS attacks, "The ShadowPad backdoor was downloaded onto the attacked computers under the guise of legitimate software."

Specifically, the malware originally masqueraded as the mscoree.dll file, which is a Microsoft library file essential for the execution of "managed code" applications written for use with the .NET Framework. As such, the malware was launched by the legitimate AppLaunch.exe application, which itself was executed by creating a task in the Windows Task Scheduler. Last fall, the attackers switched to using the DLL-hijacking technique in legitimate software for viewing OLE-COM objects (OleView). The Windows Task Scheduler is also used in the newer approach. In both cases, using such living-off-the-land tools (i.e., legitimate native software) means that the activity is unlikely to raise any system-intrusion flags.

After the initial infection, the attackers first sent commands manually, then automatically, to deploy additional tools. Researchers said those included the following:

*   The CobaltStrike framework (for lateral movement)
*   Mimikatz (for stealing credentials)
*   The well-known PlugX RAT
*   BAT files (for stealing credentials)
*   Web shells (for remote access to the Web server)
*   The Nextnet utility (for scanning network hosts)

"The artifacts found indicate that the attackers stole domain-authentication credentials from at least one account in each attacked organization (probably from the same computer that was used to penetrate the network)," according to Kaspersky. "These credentials were used to further spread the attack over the network … we do not know the ultimate goal of the attacker. We think it was probably data harvesting."

**How to Protect Against APT Attacks Targeting BAS, Critical Infrastructure**

The attacks develop "extremely rapidly," Kaspersky said, so early-state detection and mitigation is key to minimizing damage. The researchers recommended the following best practices to protect industrial infrastructure, including BAS footprints:

*   Regularly update operating systems and any application software that are part of the enterprise's network. Apply security fixes and patches to operational-technology (OT) network equipment such as BAS, as soon as they are available.
*   Conduct regular security audits of OT systems to identify and eliminate possible vulnerabilities.
*   Use OT network traffic monitoring, analysis, and detection solutions for better protection from attacks that potentially threaten OT systems and main enterprise assets.
*   Provide dedicated OT security training for IT security teams and OT engineers.
*   Provide the security team responsible for protecting ICS with up-to-date threat intelligence.
*   Use layered security solutions for OT endpoints and networks.

China-Backed APT Pwns Building-Automation Systems with ProxyLogon

Swarms of breach attempts against the Atlassian Confluence vulnerability are likely to continue for years, researchers say, averaging 20,000 attempts daily as of this week.

Since it was first identified on June 2, the Atlassian Confluence remote code-execution (RCE) vulnerability tracked as CVE-2022-26134 has attracted the repeated attention of threat actors. Now, after peaking at up to 100,000 attack attempts daily on targets, cyberattackers have settled at a steady rate of 20,000 malware injection shots per day, launched from around 6,000 IPs.

Researchers at Akamai observed that attacks on the Atlassian Confluence bug are mainly focused in the commerce, high tech, and financial services sectors, and range from probing to malware injection in hopes of installing cryptominers and webshells.

"What is particularly concerning is how much of a shift upward this attack type has garnered over the last several weeks," a Tuesday Akamai report on the Atlassian Confluence vulnerability said. "As we have seen with similar vulnerabilities, this CVE-2022-26134 \[bug\] will likely continue to be exploited for at least the next couple of years."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Atlassian Confluence Exploits Peak at 100K Daily

Creating temporary keys that are not stored in central repositories and time out automatically could improve security for even small businesses.

While multifactor authentication, single-sign-on infrastructure, and stronger password requirements have improved the security of most enterprise identity and access management (IAM) environments, the longevity of passwords continues to pose problems for businesses, especially in granting temporary access to contractors and third-party partners.

A variety of vendors are trying to solve this problem. Last week, for example, data-security firm Keeper Security announced one-time shared passwords that allow companies to grant third-party partners temporary access to data and resources without adding them to the company's overall IT environment. The approach allows specific types of documents to be shared to a single user device, automatically removing access when the time expires.

The business case is all about securing access granted to contractors, says Craig Lurey, chief technology officer and co-founder of Keeper Security.

"We get asked constantly to allow short term, temporary access to third parties without requiring them to onboard as a licensed user," he says. "With this new feature, there is not 20 steps anymore. It is just instant, but preserving that encryption, simplifying the secure-sharing process, and eliminating the need to send private information over text messages."

**Credential Theft Is Big Business**

Supply chain breaches, stolen credentials, and the proliferation of software keys and secrets continue to undermine IT and data security. In March, secrets-detection firm GitGuardian found that developers leaked 50% more credentials, access tokens, and API keys in 2021, compared to 2020. Overall, 3 out of every 1,000 commits exposed a sensitive password, key, or credential, the company said at the time.

Failing to protect software secrets, user passwords, and machine credentials can lead to compromises of application infrastructure and development environments. Attackers have increasingly targeted identities and credentials as a way to gain initial access to corporate networks. Last week, for example, software security firm Sonatype discovered that at least five malicious Python packages attempt to exfiltrate secrets and environment variables for Amazon environments.

"It remains yet to be known who the actors behind these packages are and what is their ultimate goal," Sonatype stated in an advisory on the issue. "Were the stolen credentials being intentionally exposed on the web or a consequence of poor OpSec practices?"

**How Zero-Knowledge Encryption Protects Credentials**

Managing the access credentials for data means avoiding centralized storage of sensitive keys — a security advantage of zero-knowledge encryption (ZKE) — and regularly expiring keys so that former contractors, partners, and employees no longer have access to data. ZKE breaks up keys in specific ways, using both cryptography and tokenization, to prevent any device or database from having all the necessary information to reconstitute the master keys to unlock data.

    

Source: Keeper Security

The move to de-emphasize master passwords and keys is part of the cybersecurity industry's effort to create a passwordless security infrastructure. Yet, in the end, most enterprises rely on some sort of password to secure massive stores of keys or unlock cloud IAM services, says Lurey.

"Every year, the platforms try to come up with new schemes to bury the password, \[but\] at the end of the day, those platforms still rely on passwords, especially for account recovery," he says. "There is a growing number of passwords and secrets that everyone has to deal with, whether you are on the tech side and you have to deal with API keys and software secrets, or on the personal side and the growing number of sites that require personal or private information."

Creating a zero-knowledge way of managing secrets and offering one-use, temporary passwords requires significant design effort and a move away from the consolidation among large brands that are assuming the mantles of identity providers, Lurey says.

"The reason why the password continues to be popular is because it is something that you have that can be used to encrypt and decrypt data at the end of the day," he says. "The passkeys, which are just passwords, are being stored by Apple, Google, and Microsoft, so those are being synched with other devices and onboard devices, but how do you sync those secrets — it is basically a rabbit hole of authentication issues."

**The Passwordless Path Ahead**

The focus on ZKE is relatively new, and the vast majority of companies protect their secrets using key management systems, says Andras Cser, vice president and principal analyst for security and risk at Forrester Research. The focus on passwordless technologies typically involves biometrics, QR-code-based authentication, pushing authentication tokens to mobile devices, and sending one-time passwords via e-mail or text message, he says.

"Because of phishing issues, OTP and passwordless is slowly replacing the static password for authentication. Identity management and governance (IMG) to onboard, review, and off-board contractors and third parties for access is very important in this flow," Cser says.

Whether ZKE takes off will likely depend on whether third-party identity services using de facto standards, such as the FIDO2 and WebAuthn passwordless standards, gain popularity. In a white paper acknowledging the slow adoption of FIDO and the future integration with WebAuthn, the FIDO Alliance outlined what its passwordless future would look like, using mobile devices as standardized authenticators and allowing credentials to be synced across devices.

The changes will make "FIDO the first authentication technology that can match the ubiquity of passwords, without the inherent risks and phishability," the white paper stated.

Can Zero-Knowledge Crypto Solve Our Password Problems?

Developers need to think like WAF operators for security. Start with secure coding and think of Web application firewalls not as a prophylactic but as part of the secure coding test process.

A key approach to shifting security left is moving perimeter-focused security solutions down the stack by placing them in front of services and other infrastructure components, such as containers and container orchestration systems or API management systems and gateways.

While this does allow for more granular security, it's not a free lunch for developers. Just saying "The WAF will stop it" subverts the entire thinking and purpose of shifting left. Rather, developers must move from thinking of Web application firewalls (WAFs) as a prophylactic, to instead thinking of WAFs as a crucial part of their secure coding test process. Here's how they can accomplish that.

**The Explosion of WAFs and Cloud-Native Software**

While many companies still deploy WAF appliances, the fastest-growing segment of this market is WAF software that runs in the cloud. With the rise of cloud-native architectures and ephemeral infrastructure, more organizations are putting WAFs deeper into their application stacks — right in front of microservices. Some are even using WAFs for internal protection to enact robust zero-trust frameworks. So, the new reality is, developers are far more likely to come into close contact with WAFs today than at any point in the past. That said, WAFs at the microservice level are not foolproof.

**Before Deploying the WAF: Secure Coding Is Critical**

To start, developers must create applications under the assumption that all security controls can and will fail. This is important because it encourages them to build applications that are secure by default. Secure coding means using basic design principles — like code minification to obscure code — while ensuring that all variables and calls are checked against the OWASP Top 10 vulnerability list. There are dozens of ways that attackers can exploit poorly written code, including SQL injection, cross-site scripting, broken access controls, and file upload vulnerabilities.

A key part of this effort is to ensure developers are running linters and formatting checkers against all code. Usually, you will want developers to run code through software composition analysis (SCA) to identify risky dependencies and libraries that require updates. A secure coding process and mentality is more critical now because cloud-native microservices have turned security inside out.

At this point, the application security or DevSecOps teams run the code against some sort of simulation and add the WAF. For many developers, this is the end of the story. They assume, "We have deployed a WAF. We're safe now." They are wrong. Increasingly, the applications developers ship microservices, linked via APIs. Developers "own" their microservices and APIs and are responsible for security. The microservices and APIs may have highly specific rules and optimizations that can impact WAF behaviors and policies. Each application is different, and many unique APIs emerge.

For microservices, developers tend to rapidly ship code and make faster iterations on microservices because those smaller applications are loosely coupled and do not impact other applications. That makes for greater agility but also greater security risk if the changes are not run through the same cumbersome security process as observed at application launch.

**Learning to Think Like a WAF Operator**

Developers should always ask themselves before they ship code, "How will this impact my WAF coverage and security posture?" This question is good because it teaches them to think about how WAFs are working and not working — in other words, threat modeling.

Threat modeling is critical because there are known ways that attackers work around WAFs or exploit WAF weaknesses. For example, by default, Kubernetes exposes APIs for services and connections. Locking down Kubernetes APIs without messing up functionality is notoriously difficult, particularly if you're changing the applications and service calls in the applications on a regular basis. Recently, Shadowserver Foundation calculated that 84% of Kubernetes APIs servers had left themselves exposed to detection on the public Internet.

Understanding a WAF is a key precursor to threat modeling and, by extension, thinking like a firewall operator. Some WAF comprehension is tacit knowledge. For instance, tuning a WAF to limit false positives and false negatives to an acceptable level remains challenging. Developers looking to shift left can piggyback on experienced WAF operators to learn the tuning process and, in turn, better understand how the WAF responds to real-world traffic. Today, some organizations also deploy machine learning to help developers easily tune their WAFs by making rule and policy suggestions based on unsupervised learning across multiple WAFs.

**Better WAF Comprehension Leads to More Secure Code**

Even better, good WAF comprehension also transfers over into more secure coding. Developers that intimately understand WAFs — and have hands-on experience tuning them — benefit from tacit knowledge that is difficult to teach, and experience that goes beyond Open Web Application Security Project (OWASP} checklists. An equally good practice is, in a safe environment, to have developers work alongside red-team members to see how a smart attacker might compromise their apps and bypass default WAF settings.

The bottom line is simple: Developers, take time to know your WAF and learn its weaknesses. WAF wisdom will help you write secure code now and save your apps from being hacked in the future.

A WAF Is Not a Free Lunch: Teaching the Shift-Left Security Mindset

Like a hydra, every time one ransomware gang drops out (REvil or Conti), plenty more step up to fill the void (Black Basta).

After a 2021 beleaguered by ransomware, attack volumes continue to balloon in 2022. In fact, a report issued Tuesday indicates that in just the first three months of this year, the volume of ransomware detections almost doubled the total volume reported for all of last year. 

The increasingly high numbers came in spite of what appeared to be the downfall of a major ransomware group at the end of 2021: REvil. This serves as a testament to the persistence of criminal actors in reforming, rebranding, and regrouping their criminal gangs to profit handsomely off of ransomware tactics.

This persistence has been studied most recently by security researchers who have noted the rapid rise of the Black Basta ransomware gang in the past two months, quickly following the emergence of the LAPSUS$ group earlier in the year.

**Ransomware 2022 Volumes: Up, Up, Up**

The numbers today come by way of the quarterly "Internet Security Report" from WatchGuard Threat Lab, which examines Q1 2022 threat trends. Researchers with the firm report that unique ransomware detections in the first three months of the year were triple the volume of the same time period in 2021. Meantime, Q1 2022 ransomware volume equaled more than 80% of the total volume recorded in all of 2021.

“Based on the early spike in ransomware this year and data from previous quarters, we predict 2022 will break our record for annual ransomware detections,” says WatchGuard chief security officer Corey Nachreiner, noting that the last annual high-water mark for ransomware volume came back in 2018.

**LAPSUS$ Steps Up in the Underground Economy**

The report from his team explains that even in the face of high-profile arrests and charges made by US and Russian authorities in late 2021 and early 2022 that resulted in the disruption of the prolific REvil ransomware gang, the ransomware hits keep coming. Their analysis shows that REvil’s disruption “opened the door” for LAPSUS$ to emerge in a big way.

“The LAPSUS$ group made global headlines with their double-extortion ransomware techniques that caused cybersecurity decision-makers to take notice,” the report states. “The group was known to hire employees of organizations to steal information from the inside and then use extortion techniques to blackmail victim organizations. Their victim list also put decision makers on notice. Microsoft, Nvidia, Samsung, Ubisoft, Okta, and T-Mobile are all victims of LAPSUS$.”

This kind of resurgence of new groups should dampen security teams' celebrations of the demise of groups like REvil and Conti, which in May were reported to have shut down their operations. Stats from NCC Group show a slight dip in attacks that month, with a warning that other heads of the ransomware gang Hydra were already starting to emerge.

**Black Basta: New Kid on the Ransomware Block**

Most recently, the Black Basta ransomware gang has surged into the scene. Earlier in the month, two separate reports from Uptycs and NCC Group showed that Black Basta was targeting ESXi-based systems and servers among other victims, and leveraging the Qbot malware family (aka Qakbot) to maintain persistence on networks it goes after. 

"While Black Basta isn't the first to develop capabilities against ESXi (LockBit, Hive, and Cheerscrypt already have demonstrated ESXi capabilities), this shows the relative sophistication of the teams working under Black Basta performing the ransomware operations," said Jake Williams, executive director of cyber threat intelligence at SCYTHE, in a statement provided to Dark Reading. "Use of commodity malware like Qakbot demonstrates that there is no such thing as a 'commodity' malware infection. Organizations must treat every malware detection as an opportunity for a threat actor to deploy ransomware."

Meantime, an advisory report from the Cybereason Nocturnus research team last week offered further details about Black Basta’s tactics, techniques, and procedures. They deemed the threat from the group to be highly severe, as it has victimized more than 50 companies in English-speaking countries worldwide since April. Researchers said the hallmark of the firm is its use of double extortion – i.e., stealing sensitive files and information and using it to extort victims by threatening publication of the details unless a ransom is paid. The amounts asked for are often in the millions.

The sudden rise of Black Basta has some speculating that the group is actually just a regrouping of the two most recently disbanded groups.

“Due to their rapid ascension and the precision of their attacks, Black Basta is likely operated by former members of the defunct Conti and REvil gangs, the two most profitable ransomware gangs in 2021,” says Lior Div, CEO of Cybereason.

Ransomware Volume Nearly Doubles 2021 Totals in a Single Quarter

Abuse primitives have a longer shelf life than bugs and zero-days and are cheaper to maintain. They're also much harder for defenders to detect and block.

Microsoft's cloud services revenue grew 46% in the first quarter of 2022, and its cloud market share has increased by almost 9% since 2017. With Azure finally being used in earnest by the mainstream, now is the ideal time to get involved in Azure abuse research. There are many undiscovered abuse primitives out there, a lot of misconfiguration debt built up, and growing numbers of adversaries starting to target Azure more seriously.

Why spend time looking for abuse primitives rather than bugs or software exploits? Abuses have a much longer shelf life than bugs and zero-days, and they're cheaper to maintain. More importantly for attackers, they exist in nearly all implementations of the software in question and are much harder for defenders to detect and block. That's why it's vital for researchers to uncover new abuse options so they can be fixed or mitigated.

Here's my five-step process for researching a specific system within Azure and trying to find new attack primitives. Following this approach will help you save time, stay on track, and produce better results.

**Step One: Begin With the End in Mind**

First, you'll need to gain an understanding of how your system of choice works, how it interacts with other systems in Azure, and how it can be abused. Beyond that, think about what your final product will be — a blog post? A conference session? Defensive remediation guidelines or updates to an open source tool? Determine what's needed to create these assets. Consider producing audit code as well, so defenders can check for these dangerous configurations, and abuse code, too, so others can easily verify how these configurations can be abused. These are the "success criteria" for your research that will help you maintain focus, avoid unnecessary rabbit holes, and ensure a valuable end result.

**Step Two: Study the Intent and Design of the System**

Once you know exactly what you need to discover, begin research just like anyone else would — doing Google searches and reading official documentation. Look for anything that seems abusable (like the ability to reset passwords and permissions required), dig further into those, and take notes as you go.

Use LinkedIn to identify any product architects or other Microsoft staff involved in creating the subject of your study. Review their LinkedIn and Twitter feeds and look for the resources they've authored or reposted (blog posts, conference presentations, etc.). Delve into community resources like forums or GitHub repositories associated with this service, as these user groups are generally much more open in their discourse around problems and weaknesses than the Microsoft folks. Keep taking notes on the system. Once you can speak intelligently about the architecture and intent of the system and write a highly accurate, nontechnical brief about it, you're ready to move on.

**Step Three: Explore the System**

Documentation can only take you so far — it doesn't keep up with changes in Azure and there are almost always hidden connections that go undocumented. It's tempting to jump straight into this step, but without the context on the system that you built through research, you'll probably waste a lot of time.

Start exploring the system with the easiest interface — often this is the Azure portal GUI. If you bring up the Developer tools in the Chrome browser, you can see all the API requests that the browser is making. Copy them to PowerShell and you'll have a good start to building your own client. Use the official CLI tools in Azure (az binary, the Az PowerShell module, and Azure AD PowerShell module).  

When you’ve explored enough that you can build your own basic client to interact with the system, it’s time to proceed. This provides a foundation for a more mature client, and for automating the process of testing abuse capabilities.

**Step Four: Catalog Abuse Capabilities**

Now you can use your client to enumerate all the permissions that that system can assign, and test the abuse primitives you already know about against each of those permissions (e.g., can you promote yourself to global admin or change a global admin’s password?). Keep an eye out for other abuse primitives that might present themselves during your research — and test them as well to reveal any discrepancies between what the official documentation says and how things work in reality.

Realistically, you’ll need to automate this process. When I went through this research methodology examining the Azure Graph API, I had a list of about 175 permissions and a dozen abuse primitives to test against each of them … you do the math.

**Step Five: Share Findings**

The final step is to help others learn from your work. Write a blog post, do a talk and/or share your code. The point is to help others save time and expand or add on to your work. Think of it as writing the blog post you needed at the start of your research.

To learn more, watch a talk I gave on this topic (and access the accompanying deck). Inspired to start researching Azure abuses? Here are some useful websites to find technical content around Azure security: The Lazy Administrator, Good Workaround!, AZAdvertizer, Thomas Van Laere, and Microsoft Portals.

How to Find New Attack Primitives in Microsoft Azure

Researchers have created a new community website for reporting and tracking security issues in cloud platforms and services — plus fixes for them where available.

Organizations traditionally have struggled to track vulnerabilities in public cloud platforms and services because of the lack of a common vulnerability enumeration (CVE) program like the one that MITRE maintains for publicly disclosed software security issues.

A new community-based database launched this week seeks to begin addressing that issue by providing a central repository of information on known cloud service-provider security issues and the steps organizations can take to mitigate them.

The database — cloudvulndb.org — is the brainchild of security researchers at Wiz, who for some time have been advocating the need for a public catalog of known security flaws on platforms and services run by the likes of AWS, Microsoft, and Google. The database currently lists some 70 cloud security issues and vulnerabilities that security researcher Scott Piper had previously compiled in a document on GitHub titled "Cloud Service Provider security mistakes." Going forward, anyone is free to suggest new issues to add to the website or to suggest new fixes to existing issues. The goal is to list issues that a cloud service provider might have already addressed.

**Centralized Vulnerability Repository**

"The centralized database can help organizations review all past security issues in their \[cloud service provider\] at any time and check if they have not applied necessary remediation actions," says Alon Schindel, director of data and threat research at Wiz. "For example, organizations can check if they were using a certain service during a critical security issue’s exploitability period and use the recommended detection methods — if available — to check if they were affected."

For now, the vulnerability database site does not have a system in place to automatically notify users when new security issues are added to it. But the goal is to add an RSS feed or mailing list for that purpose, says Schindel, one of the maintainers of the new database.

Schindel — like many other researchers — has noted how the lack of a formal and standardized system for publicly recording cloud security issues, and sharing information about them, is heightening risks for organizations. In a blog last November, Schindel and another Wiz researcher pointed to vulnerabilities — such as one dubbed ChaosDB in Microsoft Azure and another called OMIGOD in Microsoft Azure — as specific reasons why a cloud vulnerability database has become a critical industry necessity. Both vulnerabilities were serious. And unlike many cloud vulnerabilities, the responsibility for mitigating risk with both vulnerabilities rested not just with the cloud provider but also with their customers.

ChaosDB impacted four Azure services and gave users overly permissive access to storage buckets belonging to other cloud tenants. OMIGOD was a set of four flaws in OMI, a Microsoft cloud middleware technology, that enabled remote code execution and privilege escalation. Though Azure and Microsoft addressed the vulnerabilities promptly, many organizations using the affected services had limited information on the changes they needed to make to address them, the Wiz researchers said.

"Typically, cloud service provider security issues do not have a patch in the traditional sense, as issues are fixed internally by the CSP without the need for any manual user action," Schindel says. But no CVEs mean that there are no industry conventions for assessing severity, no proper notification channels, and no unified tracking mechanisms. 

"This means that it’s difficult for a cloud customer to answer otherwise simple questions like, 'Is my environment currently vulnerable to this?' or, 'Was it ever vulnerable to this?'" he adds.

**Inconsistent Practices**

Currently all major CSPs accept responsibly disclosed vulnerabilities, and some have an official bug bounty or vulnerability reward program in place. Occasionally, a cloud service provider might even publish details of a fix they might have developed for a reported security vulnerability. However, there is little consistency among the various providers, Schindel says. 

"Notification channels vary; vendors usually email affected customers only or send them a notification through a service health system," he says.

Wiz has been unable to find any consistency in the publication cadence of security issues of the different CSPs, though Microsoft usually included fixes for Azure vulnerability in its monthly patch release cycle.

Wiz will maintain the new site, though anyone is free to contribute to it. The goal is to try and get major CSPs to engage with the effort or to use the site to provide more transparency around vulnerabilities discovered in their services. This can include information such as indicating the time periods during which a security issue might have been exploitable. 

"We also hope that the value of such a database will help CSPs standardize their security issues publication processes," he says.

New Vulnerability Database Catalogs Cloud Security Issues

NIST SP800-219 introduces the macOS Security Compliance Project (mSCP) to assist organizations with creating security baselines and defining controls to protect macOS endpoints.

No operating system is immune to threats, and a thorough endpoint security strategy accommodates the requirements for each one. Toward that end, the National Institute of Standards and Technology (NIST) has published the final version of its guidance on securing macOS endpoints. 

NIST SP 800-219 provides system administrators, security professionals, security policy authors, information security officers, and auditors with resources to secure and assess macOS desktop and laptop system security in an automated way. NIST derived the guidance from the open source macOS Security Compliance Project, born out of a collaboration between NIST, NASA, the Defense Information Systems Agency, and Los Alamos National Laboratory.

The goal of the mSCP is to simplify the macOS security development cycle by reducing the amount of effort required to implement security baselines, NIST says. Security baselines refers to "groups of settings used to configure a system to meet a target level or set of requirements or to verify that a system complies with requirements." The project is intended to help IT and security staff create customized security baselines of technical security controls by leveraging a library of rules, with each rule mapped to requirements from security standards, regulations, or frameworks, NIST says in the guidance document.

The mSCP provides scripts that can be used with baselines to create scripts and profiles for configuring macOS; generate a mapping between security standards, regulations, and frameworks; produce human-readable documentation in a variety of formats; customize existing baselines; and generate Security Content Automation Protocol (SCAP) content for use in automated security compliance scans.

Security baselines and associated rules for configuring and managing macOS endpoint devices can be found on mSCP’s GitHub page. Organizations should take a risk-based approach for selecting the appropriate settings and defining values that consider the context under which the baseline will be used, NIST says.

**Make It Easier to Upgrade**

Agencies and organizations typically delay deploying the new macOS release because they are waiting for guidance. The mSCP is intended to provide guidance of the security features in new operating system releases at the earliest availability. Instead of having to produce a new guidance document for each macOS release, NIST will focus on continually curating and updating the information in mSCP, giving organizations one consistent reference point.

"Generally, the technical security settings in macOS do not drastically change from release to release, with only a handful of new settings being introduced. By pursuing a rules-based approach, mSCP rules that remain applicable can be reused and incorporated into guidance for the latest macOS version. This enables quicker adoption of new security features that are not offered in prior versions of macOS," NIST says.

NIST Finalizes macOS Security Guidance

Balancing public service with fraud prevention requires rule revisions and public trust.

If a person loses their state ID or their driver's license, they may — depending on the regulations of their state — need to take a trip to the Secretary of State's office or Department of Motor Vehicles and wait in line with a handful of significant documents proving their identity in order to replace it.

That is, until COVID-19.

As states closed their government buildings in the early stages of the coronavirus pandemic, government agencies were forced to reckon with how unprepared their antiquated systems were to provide digitized services during a once-in-a-lifetime pandemic requiring the public to shelter in place. Simultaneously, the public and the private sector faced cyberattacks that left valuable, sensitive information in the hands of threat actors.

So, how do government agencies administering public benefits prevent fraud and protect valuable personal data? That question was the subject of "Future of Identity Fraud Roundtable," an online panel hosted on June 17 by Socure and Venable. During the discussion, experts weighed in on the unique challenges government agencies face when verifying people's identities, providing government assistance, and preventing synthetic identity fraud, in which cybercriminals combine real information with fabricated information to build a fake identity

"I think pretty much every state and government entity is seeking to deliver good quality digital experiences to our constituents," said J.R. Sloan, CIO for the State of Arizona, during the panel. "During the pandemic phase ... this was a public safety issue. We needed to be able to deliver no-touch experiences."

Estimates on just how much fraud occurred during the coronavirus pandemic vary. An academic paper published by researchers at the University of Texas — Austin found $64.2 billion worth of potentially misreported loans. A higher estimate from the Small Business Administration (SBA) identified at least $78.1 billion in possibly fraudulent loans and grants. Excluding data on coronavirus fraud cases brought by the Justice Department, the Secret Service reportedly said that nearly $100 billion had been stolen from coronavirus relief programs for businesses and individuals, a conclusion it reached using its own cases and data from the US Department of Labor and the SBA.

Over the past two years, federal government agencies' public benefit programs have been under attack from cybercriminals in other countries, as well as domestic cybercriminals using synthetic identities to intercept benefits meant for the American public, said Jordan Burris, senior director for product market strategy at Socure.

Cybercriminals have been sharing information and digital guides on using stolen personal information to apply for government benefits, said Linda Miller, principal of advisor services at Grant Thornton and former deputy executive director of the US Pandemic Response Accountability Committee, during the panel.

"The game has completely changed. And it's not going to change back," Miller said during the panel. "They're only going to get more and more sophisticated and more skilled as the government continues to be challenged to effectively deal with this problem."

**Hurdles to Going Digital**

Unlike the private sector, government agencies have to serve the public, which often entails reaching people who don't have addresses or bank accounts, Miller said. Verifying the identities of these vulnerable groups could prove to be harder, because there are fewer data points available for the government to cross-check, she explained.

While government agencies can use some basic indicators, such as a foreign IP address, to screen out fraudsters, there is no one-size-fits-all solution for agencies to manage populations of people who are harder to authenticate, she said.

"These problems around how do we solve this identity proofing problem in a way that is going to ensure equity across a lot of different types of groups that need government benefits, is not going to create a ton more problems for the constituents, and sell to the citizens as they're trying to get access to their benefits," Miller said. "What we need to think about is using data in a smarter way, and meeting people where they are in terms of how much data do we have on an individual."

Though sharing data between government agencies could allow them to verify benefit applicants' identities easily, one challenge government agencies face is the regulations for what data they can and cannot share with each other, Burris said. For some pieces of information to be shared — including a Social Security number, a taxpayer identification number, alien registration numbers, or passport numbers — permission to share data among various government agencies could require Congress to pass federal laws allowing it.

**Recent Progress in Data Policy**

Though regulations currently bar government agencies from sharing certain personal information, there are proposals to change agency processes that could allow them to test safe data sharing, Suzette Kent, CEO of Kent Advisory Services and former US CIO, said during the panel. Such proposals could allow, for example, military to share and recover veteran or retirement data following a disaster, Kent said.

"We have to look at what information agencies are authorized to gather, and how they may use it, and ensure that those things are fit \[for\] purpose for the types of things that we're doing," Kent said. "That may require law, policy, technology, and engagement with the particular citizen set that you're serving."

A recent example of biometric authentication gone wrong was the IRS' attempt to implement facial recognition technology for verifying the identities of people opening new online accounts. The agency announced on Feb. 7 that it abandoned its plans to use a third-party facial recognition company for authenticating new accounts.

With remote biometric identity proofing came issues around privacy, access, and equity, which was met with immediate backlash, Miller said. As government agencies try to use this technology, they're also required to comply with the National Institute of Standards and Technology's "highest level of identity authorization." But it has become clear that many federal and state government agencies aren't ready to address the numerous complexities of NIST compliance and the other issues that emerge, she said.

Regardless of the remote authentication tool, government agencies need to maintain public trust and be transparent about how they're using biometric technologies, Burris said.

Failing to maintain public trust "erodes the ability to leverage innovation in order to combat what we're seeing from a fraud standpoint," Burris said. "I would say any vendor working in this space, again, needs to be transparent with practices, so that we don't have that erosion."

Federal, State Agencies' Aid Programs Face Synthetic Identity Fraud

LockBit 3.0 promises to 'Make Ransomware Great Again!' with a side of cybercrime crowdsourcing.

The LockBit ransomware group just released its latest ransomware-as-a-service offering, LockBit 3.0, and along with it a first for the Dark Web: a bug-bounty program.

The bounty program offers up rewards for personal identifiable information (PII) on high-value targets, security exploits, and more, according to screen grabs of messages that appear to have been shared by LockBit actors.

"We invite all security researchers, ethical and unethical hackers on the planet," the group reportedly posted, offering payments for website bugs, locker bugs, TOX messenger exploits, and information to fuel doxxing campaigns, with payments starting at $1,000. The group is even willing to pay for fresh cybercrime ideas, the ad say.

LockBit is on a roll. In the wake of Conti's shutdown, LockBit 2.0 emerged as the dominant ransomware-as-a-service group in May, with the dubious distinction of being behind 40% of all ransomware attacks during the month. LockBit operators seem poised to capitalize with a new, malicious twist on bug-bounty programs.

**'No Honor Among Ransomware Operators'**

"I wish this surprised me," Mike Parkin, senior technical engineer at Vulcan Cyber, said in reaction to the LockBit bug-bounty launch. "But malware gangs have reached a level of maturity that they are, literally, professionally run businesses."

While the innovation is noteworthy as a development in the ransomware business, John Bambenek, principal threat hunter at Netenrich, said he doubts anyone would actually submit something and expect to collect the bounty.

"This development is different; however, I doubt they will get many takers," Bambenek said in a statement provided to Dark Reading. "I know that if I find a vulnerability, I'm using it to put them in prison. If a criminal finds one, it'll be to steal from them because there is no honor among ransomware operators."

Source

DARKReading