Following a year of increasingly disruptive attacks, advanced persistent threat groups will likely only become emboldened in 2023, security experts say.

In November, Ukraine's president revealed that the country's IT defenses fended off more than 1,300 Russian cyberattacks, including attacks on satellite communications infrastructure.

The onslaught of cyberattacks highlights one of the shifts in advanced persistent threat (APT) attacks seen in the past year: In 2022, geopolitical tensions ratcheted up, and along with them, cyber operations became the go-to strategy for national governments. While Russia and other nations have used cyberattacks to support military actions in the past, the ongoing war represents the most sustained cyber operation to date and one that will undoubtedly continue in the coming year, experts say.

Military conflict will join cybercrime as a driving force behind APT groups in the coming year, John Lambert, corporate vice president and distinguished engineer at Microsoft's Threat Intelligence Center, stated in the company's Digital Defense Report 2022 released last month.

"The conflict in Ukraine has provided an all-too-poignant example of how cyberattacks evolve to impact the world in parallel with military conflict on the ground," he said. "Power systems, telecommunication systems, media, and other critical infrastructure all became targets of both physical attacks and cyberattacks."

While the increased use of APT attacks by Russia is the most visible change that occurred in the past year, APTs are evolving. More are moving onto critical infrastructure, adopting dual-use tools and living-off-the-land techniques, and pinpointing the software supply chain to gain access to targeted companies.

Cybercriminals are using increasingly sophisticated tools, but APT techniques are typically attributed to nation-state operations, meaning that companies need to become more aware of the techniques used by advanced actors and how they may be motivated by geopolitical concerns, says Adam Meyers, senior vice president of intelligence for cybersecurity services firm CrowdStrike.

"You don't have one uniform threat — it changes by business vertical and geo-location," he says. "You — and this has been our mantra for many years — don't have a malware problem, you have an adversary problem, and if you think about who those adversaries are, what they are after, and how they operate, then you will be in a much better position to defend against them."

**Critical Infrastructure, Satellites Increasingly Targeted**

In 2021, the attack on oil-and-gas distributor Colonial Pipeline highlighted the impact that cybersecurity weakness could have on the US economy. Similarly, this year's attack on the Viasat satellite communication system — likely by Russia — showed that APT threat actors have continued to focus on disrupting critical infrastructure through cyberattacks. The trend has gained momentum over the past year, with Microsoft warning that the number of nation-state notifications (NSNs) the company issued as alerts to customers more than doubled, with 40% of the attacks targeting critical infrastructure, compared to 20% in the prior year.

Critical infrastructure is not just a target of nation-state actors. Cybercriminals focused on ransomware are also targeting critical infrastructure companies, as well as pursuing a hack-and-leak strategy, Kaspersky stated in its recently published APT predictions.

"We believe that in 2023 we will see a record number of disruptive and destructive cyberattacks, affecting government, industry, and critical civilian infrastructure — perhaps energy grids or public broadcasting, for instance," says David Emm, principal security researcher at Kaspersky. "This year, it became clear just how vulnerable physical infrastructure can be, so it's possible we might see targeting of underwater cables and fibre distribution hubs."

**Not Just Cobalt Strike**

Cobalt Strike has become a popular tool among APT groups, because it provides attackers — and when used for its legitimate purposes, red teams and penetration testers — post-exploitation capabilities, covert communications channels, and the ability to collaborate. The red-team tool has "crop\[ped\] up in a myriad of campaigns from state-sponsored APTs to politically motivated threat groups," says Leandro Velasco, a security researcher with cybersecurity firm Trellix.

Yet, as defenders have increasingly focused on detecting both Cobalt Strike and the popular Metasploit Framework, threat actors have moved toward alternatives, including the commercial attack simulation tool Brute Ratel C4 and the open source tool Sliver.

"Brute Ratel C4 ... is especially dangerous since it has been designed to avoid detection by antivirus and EDR protection," Kaspersky's Emm says. Other up-and-coming tools include Manjusaka, which has implants written in Rust for both Windows and Linux, and Ninja, a remote exploitation and control package for post exploitation, he says.

**Identity Under Attack**

Following the coronavirus pandemic, remote work — and the cloud services to support such work — have increased in importance, leading attackers to target those services with identity attacks. Microsoft, for example, saw 921 attacks every second, a 74% increase in volume over the past year, the company stated in its report.

In fact, identity has become a critical component to securing the infrastructure and enterprise, while at the same time becoming a major target of APT groups. Every breach and compromise investigated by CrowdStrike in the past year has had an identity component, CrowdStrike's Meyers says.

"We used to say trust, but verify, but the new mantra is verify and then trust," he says. "These attackers have started targeting that soft underbelly of identity ... that is a complex part of the system."

**IT Supply Chains Under Attack**

The attack on SolarWinds and the widely exploited vulnerability in Log4J2 demonstrated the opportunities that vulnerabilities in the software supply offer to attackers, and companies should expect APT groups to create their own vulnerabilities through attacks on the software supply chain.

While there has been no major event yet, attackers have targeted Python ecosystems with dependency confusion attacks against open source repositories and phishing attacks targeting Python developers. Overall, the number of attacks targeting developers and companies increased by more than 650% over the past year.

In addition, APT actors are finding the weak points in vendor and supplier relationships and exploiting them. In January, for example, the Iran-linked DEV-0198 group compromised an Israeli cloud provider by using a compromised credential from a third-party logistics company, according to Microsoft's report.

"This past year of activity demonstrates that threat actors ... are getting to know the landscape of an organization's trusted relationships better than the organizations themselves," the report stated. "This increased threat emphasizes the need for organizations to understand and harden the borders and entry points of their digital estates."

To harden their defenses against APT groups and advanced attacks, companies should regularly verify their cybersecurity hygiene, develop and deploy incident response strategies, and integrate actionable threat intelligence feeds into their processes, says Trellix's Velasco. To make identity attacks more difficult, multifactor authentication should be routine, he says.

"In 2023, simple security planning is not enough to deter or prevent attackers," Velasco says. "System defenders need to implement a more proactive defensive approach."

Where Advanced Cyberttackers Are Heading Next: Disruptive Hits, New Tech

A do-it-yourself machine-learning system helped a French bank detect three types of exfiltration attacks missed by current rules-based systems, attendees will learn at Black Hat Europe.

Using an internally developed machine-learning model trained on log data, the information security team for a French bank found it could detect three new types of data exfiltration that rules-based security appliances did not catch.

Carole Boijaud, a cybersecurity engineer with Credit Agricole Group Infrastructure Platform (CA-GIP), will take the stage at next week's Black Hat Europe 2022 conference to detail the research into the technique, in a session entitled, "Thresholds Are for Old Threats: Demystifying AI and Machine Learning to Enhance SOC Detection." The team took daily summary data from log files, extracted interesting features from the data, and used that to find anomalies in the bank's Web traffic. 

The research focused on how to better detect data exfiltration by attackers, and resulted in identification of attacks that the company's previous system failed to detect, she says.  

"We implemented our own simulation of threats, of what we wanted to see, so we were able to see what could identify in our own traffic," she says. "When we didn't detect \[a specific threat\], we tried to figure out what is different, and we tried to understand what was going on."

As machine learning has become a buzzword in the cybersecurity industry, some companies and academic researchers are still making headway in experimenting with their own data to find threats that might otherwise hide in the noise. Microsoft, for example, used data collected from the telemetry of 400,000 customers to identify specific attack groups and, using those classifications, predict future actions of the attackers. Other firms are using machine-learning techniques, such as genetic algorithms, to help detect accounts on cloud computing platforms that have too many permissions.

There are a variety of benefits from analyzing your own data with a homegrown system, says Boijaud. Security operation centers (SOCs) gain a better understanding of their network traffic and user activity, and security analysts can gain more insight into the threats attacking their systems. While Credit Agricole has its own platform group to manage infrastructure, handle security, and conduct research, even smaller enterprises can benefit from applying machine learning and data analysis, Boijaud says.

"Developing your own model is not that expensive and I'm convinced that everyone can do it," she says. "If you have access to the data, and you have people who know the logs, they can create their own pipeline, at least in the beginning."

**Finding the Right Data Points to Monitor**

The cybersecurity engineering team used a data-analysis technique known as clustering to identify the most important features to track in their analysis. Among the features that were deemed most significant included the popularity of domains, the number of times systems reached out to specific domains, and whether the request used an IP address or a standard domain name.

"Based on the representation of the data and the fact that we have been monitoring the daily behavior of the machines, we have been able to identify those features," says Boijaud. "Machine learning is about mathematics and models, but one of the important facts is how you choose to represent the data and that requires understanding the data and that means we need people, like cybersecurity engineers, who understand this field."

After selecting the features that are most significant in classifications, the team used a technique known as "isolation forest" to find the outliers in the data. The isolation forest algorithm organizes data into several logical trees based on their values, and then analyzes the trees to determine the characteristics of outliers. The approach scales easily to handle a large number of features and is relatively light, processing-wise.

The initial efforts resulted in the model learning to detect three types of exfiltration attacks that the company would not otherwise have detected with existing security appliances. Overall, about half the exfiltration attacks could be detected with a low false-positive rate, Boijaud says.

**Not All Network Anomalies Are Malicious**

The engineers also had to find ways to determine what anomalies indicated malicious attacks and what may be nonhuman — but benign — traffic. Advertising tags and requests sent to third-party tracking servers were also caught by the system, as they tend to match the definitions of anomalies, but could be filtered out of the final results.

Automating the initial analysis of security events can help companies more quickly triage and identify potential attacks. By doing the research themselves, security teams gain additional insight into their data and can more easily determine what is an attack and what may be benign, Boijaud says.

CCA-GIP plans to expand the analysis approach to use cases beyond detecting exfiltration using Web attacks, she says.

SOC Turns to Homegrown Machine Learning to Catch Cyber-Intruders

Rather than regarding risk assessment as a negative exercise, consider it one that benefits your organization's aims, and then translate the risk level to its impact on operations, reputation, or finances.

The risk assessment methodology is a foundational pillar of effective information security and there are numerous risk methodologies available to allow organizations to identify, quantify, and mitigate information security risks to its information assets. But, as we all know, risk is subjective.

Personal experience, subject knowledge, and anecdotal sources can all result in mixed results. How we make sense of the risks to information and present this information in a meaningful way is where risk assessment comes in, enabling the business to identify risks, determine potential impacts, and to analyze those risks to determine the risk level, appropriate controls, and to calculate a risk rating.

Determining the right risk assessment methodologies for your business will depend upon several factors. These can include the industry the business operates in, its size and scope, and the compliance regulations to which it's subject.

**The Right Fit**

Unless specified contractually, the risk methodology should fit the business, not the other way around. A clear understanding of the risks faced in the collection, processing, storing, sharing, and disposal of information is key to ensuring that those risks are managed appropriately to the impact of a breach, whether to its own or customer data.

You'll also need to decide whether you are looking for a qualitative or quantitative approach or a combination of both methods, and what you're trying to achieve, i.e., the risks you wish to mitigate and where. Are you looking to address threats and vulnerabilities; protect personal information, data sets, or business-critical information; or reduce the risk posed to the services of the business, its physical hardware, or staff?

Component-driven risk focuses on technical components and the threats and vulnerabilities they face, so looks at individual elements. System-driven risk, on the other hand, analyzes systems or processes as a whole, so takes more of an overview. Although different, they are deemed complementary. Most organizations adopt the component methodology, which requires the organization to identify specific information assets and its associated risks to its confidentiality, integrity, and availability (aka, CIA).

The CIA triad enables the security team to keep data secure while ensuring legitimate access to data. It is essential to use alongside your risk framework, as it can help control the risk to data associated with the introduction of new systems or devices, for instance.

Given all these variables, there are, of course, numerous frameworks to choose from. Some of the most well-known are ISO 27005:2011, ISF IRAM2, NIST (SP800-30), Octave Allegro, and ISACA COBIT 5 for risk, for example. There's no one-size-fits-all approach, and all have their strengths and weaknesses, leading many teams to adopt more than one approach.

**Pitfalls to Avoid

Risk methodologies will only ever be as good as the data we put into them. This means it's relatively common for teams to be too restrictive in their scope and to overlook assets. All too often, we've seen examples of asset lists that only contain IT assets, without including information assets, for instance. An information asset has its own value, which doesn't change whether it is in physical, electronic, or tacit form, but excluding this from the organization's asset list would skew results.

Another common failing is to restrict the way risk assessment is used. It's often regarded as a negative exercise because it sees the enforcement of controls, so it's important to counter this by ensuring the assessment benefits the aims of the organization and doesn't hinder or stifle its success.

Understanding what lies behind the risk is also key, i.e., the threats/vulnerabilities and their likelihood of realization — and this needs to be translated in a meaningful way.

Risk assessment can lead to risk registers producing risk matrices and red-amber-green (RAG) status indicators without conveying the relative impact in a business language. Being able to effectively communicate risk to those responsible for managing the purse strings is vital to securing funds for risk protection. For example, describing a risk as red, or 43, will mean very little to most laypeople, whereas a description of the impact to operations, reputation, finances, or punitive measures will see the issues described using business language that will be readily understood by senior management. Indeed, the importance of being able to translate risk into meaningful business impacts is an often underappreciated skill.

The output of risk assessments should guide the business to invest in the controls that best meet its objectives. They should also, just as importantly, highlight when spending on new technology or controls does not contribute to those goals.

Finally, it's important that the applied risk methodology creates an environment where consistent, repeatable results are produced. This will help the business evaluate whether risks have increased, whether existing controls are adequate, and where exposure has increased, leading to a more accurate risk profile and clearer understanding of the overall security risk posture.

**

A Risky Business: Choosing the Right Methodology

Amazon Security Lake will allow organizations to create a purpose-built, standards-based data lake to aggregate and store security data.

Amazon Web Services unveiled the Amazon Security Lake, a standards-based data lake for security data, at this week's AWS re:Invent 2022 conference. The new cybersecurity service will allow organizations to aggregate logs and event data from multiple sources and analyze them to quickly detect and respond to threats.

Security data is usually scattered across an organization's environment, as applications, firewalls, and identity providers maintain their own logs and event data. They are also often in disparate data formats, making it difficult for security teams to aggregate them. Creating processes to normalize data across multiple sources can be costly and time-consuming to build, and managing the data lifecycle is complex.

Many organizations are turning to security data lakes to manage security data from multiple data sources and to integrate with other security tools. These data lakes help centralize and store unlimited amounts of data to power investigations, analytics, threat detection, and compliance initiatives. It also makes it possible to combine the organization's own data with enriched data from other sources for deeper context.

With Amazon Security Lake, organizations will be able to store, analyze, and understand the data collected from both cloud and on-premises infrastructure, the company said. Because Amazon Security Lake supports the Open Cybersecurity Schema Framework (OCSF), an open specification for security telemetry data, it can ingest data from a number of third-party providers. Having the data available in OCSF format means security teams can use the analytics tool of their choice to uncover malicious activity.

“After customers choose their data sources, Amazon Security Lake automatically aggregates and normalizes data from AWS, combines it with third-party sources that support OCSF (an open standard), and optimizes it into a format that is easy to store and query,” AWS said in a statement.   

Amazon Security Lake aggregates data from AWS services, such as CloudTrail, Lambda, AWS Security Hub, GuardDuty, and AWS Firewall Manager, as well as from firewalls and endpoint security products from other companies. Several dozen companies have announced integrations with Amazon Security Lake, including Cisco, CrowdStrike, Palo Alto Networks, Barracuda, Lacework, Trend Micro, and Laminar. Security teams can analyze the data using Amazon's own security services such as Amazon Athena, Amazon OpenSearch, and Amazon SageMaker, as well as third-party providers such as IBM, Splunk, Sumo Logic, Securonix, and SentinelOne.

The data lakes are built using Amazon Simple Storage Service (S3) and AWS Lake Formation, the company said.

AWS Unveils Amazon Security Lake at re:Invent 2022

The threat actor behind an August intrusion used data from that incident to access customer data stored with a third-party cloud service provider, and affiliate GoTo reports breach of development environment.

An attacker who breached the software development environment at LastPass this August and stole source code and other proprietary data from the company appears to have struck the password management firm again.

On Wednesday, LastPass disclosed it is investigating a recent incident where someone using information obtained during the August intrusion managed to access source code and unspecified customer data stored within an unnamed third-party cloud storage service. LastPass did not disclose what kind of customer data the attacker might have accessed but maintained that its products and services remained fully functional.

**Unusual Activity**

"We recently detected unusual activity within a third-party cloud storage service, which is currently shared by both LastPass and its affiliate, GoTo," LastPass said. "We immediately launched an investigation, engaged Mandiant, a leading security firm, and alerted law enforcement."

LastPass' statement coincided with one from GoTo, also on Wednesday, that referred to what appeared to be the same unusual activity within the third-party cloud storage-service. In addition, GoTo's statement described the activity as impacting its development environment but offered no other details. Like LastPass, GoTo said its videoconferencing and collaboration services remained fully functional while it investigates the incident.

It is unclear if the apparent breach of GoTo's development environment is related in any way to the August intrusion at LastPass or if the two incidents are entirely separate. Both companies declined to answer a Dark Reading question on whether the two incidents might be related.

The new breach at LastPass suggests that attackers may have accessed more data from the company in August than previously thought. LastPass has previously noted the intruder in the August breach gained access to its development environment by stealing the credentials of a software developer and impersonating that individual. The company has maintained since then that the threat actor did not gain access to any customer data or encrypted password vaults because of the design of its system and the controls it has in place.

**Were LastPass' Security Controls Strong Enough?**

Those controls include a complete physical and network separation of the development environment from the production environment and ensuring the development environment contains no customer data or encrypted vaults. LastPass has also noted that it does not have any access to the master passwords to customer vaults, thereby ensuring that only the customer can access it.

Michael White, technical director and principal architect at Synopsys Software Integrity Group, says LastPass' practice of separating dev and test and making sure that no customer data is used in dev/test are certainly good practices and in line with recommendations.

However, the fact that a threat actor managed to gain access to its development environment means they potentially had the ability to do a lot of damage.

"The short answer is that we simply cannot know based on what has been said publicly," White says. "However, if the impacted dev systems have any access to common internal tools used for software build and release — for example, source code repositories, build systems, or binary artifact storage — it could allow an attack to insert a surreptitious back door into the code."

So, the mere fact that LastPass might have separated development and test from its production environment is not enough guarantee that customers were fully protected, he says.

LastPass itself has only confirmed the threat actor behind the August breach as accessing its source code and some other intellectual property. But it's unclear if the actor might have done other damage as well, researchers tell Dark Reading.

Joshua Crumbaugh, CEO at PhishFirewall, says development environments tend to present easy targets for threat actors to inject malicious code without being detected. "That malicious code is like finding a needle that you don't know to look for in a haystack of needles," he says.

Development environments are also known for having hardcoded credentials and for insecure storage of API keys, user credentials, and other sensitive information. "Our research continuously demonstrates that development teams are one of the least security aware departments at most organizations," Crumbaugh says. He adds that LastPass' breach sequel suggests they didn't completely trace the attackers' actions after the first breach.

LastPass Discloses Second Breach in Three Months

A vulnerability discovered in GitHub Actions could allow an attacker to poison a developer's pipeline, highlighting the risk that insecure software pipelines pose.

An attacker submitting changes to an open source repository on GitHub could cause downstream software projects that include the latest version of a component to compile updates with malicious code.

That's according to software supply chain security firm Legit Security, which said in an advisory published on Dec. 1 that this "artifact poisoning" weakness could affect software projects that use GitHub Actions — a service for automating development pipelines — by triggering the build process when a change is detected in a software dependency. 

The vulnerability is not theoretical: Legit Security simulated an attack on the project that manages Rust, causing the project to recompile using a customized — and malicious — version of the popular GCC software library, the company stated in the advisory.

The problem likely affects a large number of open source projects because maintainers typically will run tests on contributed code before they actually analyze the code themselves, says Liav Caspi, chief technology officer of Legit Security.

"It is a common pattern today," he says. "A lot of open source projects today, upon a change request, they run a bunch of tests to validate the request because the maintainer does not want to have to review the code first. Instead, it automatically run tests."

The attack takes advantage of the automated build process through GitHub Actions. In the case of the Rust programming language, the vulnerable pattern could have allowed an attacker to execute code in a privileged way as part of the development pipeline, stealing repository secrets and potentially tampering with code, Legit Security said.

"To put it simply: in a vulnerable workflow, any GitHub user can create a fork that builds an artifact," the company stated in its advisory. "Then inject this artifact into the original repository build process and modify its output. This is another form of a software supply chain attack, where the build output is modified by an attacker."

The vulnerability enables an attack similar to the malware-insertion attack that targeted CodeCov and, through that company's software, its downstream customers.

"\[T\]he lack of native GitHub implementation for cross-workflow artifacts communication led many projects and the GitHub Actions community to develop insecure solutions for cross-workflow communication and made this threat highly prevalent," Legit Security stated in the advisory.

GitHub confirmed the issue and paid a bounty for the information, while Rust fixed its vulnerable pipeline, Legit Security stated.

    

Source: Legit Security

**Software Supply Chain Needs Security**

The vulnerability is the latest security issue to affect software supply chains. Industry and government agencies have increasingly sought to bolster the security of open source software and software provided as a service.

In May 2021, for example, the Biden administration released its executive order on Improving the Nation's Cybersecurity, a federal rule that, among other requirements, mandates that the government will require baseline security standards for any software its purchases. On the private industry side, Google and Microsoft have pledged billions of dollars to shore up security in the open source ecosystem, which provides the code that comprises more than three-quarters of the average application's codebase.

**Logical, But Vulnerable**

The security issue belongs to a hard-to-find class of problems known as logic issues, which include issues with permissions, the potential for forked repositories to be inserted into a pipeline, and a lack of differentiation between forked and base repositories.

Because software projects often use automated scripts to check code submissions before forwarded them to the maintainers, pull requests will be run through automation before any human checks them for malicious code. While the automation saves time, it also should be considered a way for attackers to insert malicious code into the pipeline.

"When you are doing open source development, the problem is bigger, because you are accepting contribution from anyone in the world," Caspi says. "You are executing things that you cannot trust."

GitHub acknowledged the issue and expanded the ways of excluding submissions from outside collaborators from being automatically inserted into the Actions pipeline. The company updated its GetArtifact and ListArtifacts APIs with the goal of providing more information to help determine whether an artifact can be trusted.

"Anyone that does anything like the Rust project did — trusting the input from a third party — then they are still vulnerable," Caspi says. "It is a logic problem. GitHub just made it easier to write a safer script."

Artifact Poisoning in GitHub Actions Imports Malware via Software Pipelines

Though there have been fewer than expected publicly reported attacks involving the vulnerability, nearly three-quarters of organizations remain exposed to it.

The Log4j vulnerability continues to present a major threat to enterprise organizations one year after the Apache Software Foundation disclosed it last November — even though the number of publicly disclosed attacks targeting the flaw itself has been less than many might have initially expected.

A high percentage of systems still remain unpatched against the flaw, and organizations face challenges in finding and remediating the issue and then preventing the flaw from being reintroduced into the environment, security researchers say.

"The fact that Log4j is used in \[nearly\] 64% of Java applications and only 50% of those have updated to a fully fixed version means attackers will continue to target it," says David Lindner, CISO at Contrast Security. "At least for now, attackers continue to have a field day in finding paths to exploit through Log4j."

**Multiple Attacks But Fewer Than Expected**

The Log4j flaw (CVE-2021-44228), commonly referred to as Log4Shell, exists in Log4j's Java Naming and Directory Interface (JNDI) function for data storage and retrieval. It gives remote attackers a trivially easy way to take control of vulnerable systems — a problem given that Log4J is used in virtually every Java application environment. Security researchers consider it as one of the most significant vulnerabilities in recent years because of its prevalence and the relative ease with which attackers can exploit it.

Over the past year, there have been numerous reports about threat actors targeting the flaw as a way to gain initial access into a target network. Many of these attacks have involved nation-state-backed advanced persistent threat (APT) groups from China, North Korea, Iran, and other countries. In November, for instance, the US Cybersecurity and Infrastructure Security Agency (CISA) warned about an Iran-government-backed APT group exploiting the Log4j vulnerability in an unpatched VMware Horizon server to deploy cryptomining software and credential harvesters on a federal network.

The warning was similar to one from Fortinet in March about Chinese threat actor Deep Panda using the identical vector to deploy a backdoor on target systems and another from Ahn Labs about North Korea's Lazarus Group distributing its own backdoor the same way. Others such as Microsoft have also reported observing state actors such as Iran's Phosphorous group and China's Hafnium threat actor using Log4 to drop reverse shells on infected systems.

Despite such reports — and several others about financially motivated cybercrime groups targeting Log4j — the actual number of publicly reported compromises involving Log4 has remained comparatively low, especially when compared to incidents involving Exchange Server vulnerabilities like ProxyLogon and ProxyShell. Bob Huber, chief security officer at Tenable, says the scale and scope of reported attacks have been surprisingly lower than expected, considering the simplicity of the vulnerability and the attack path. "Only recently have we seen some significant evidence of targeting, as noted by recent nation state activity from CISA," Huber says.

**Undiminished Threat**

However, that does not mean the threat from Log4j has diminished over the past year, security researchers note.

For one thing, a large percentage of organizations remain as vulnerable to the threat as they were a year ago. An analysis of telemetry related to the bug that Tenable recently conducted showed 72% of organizations were vulnerable to Log4j, as of Oct. 1. Tenable found that 28% of organizations globally have fully remediated against the bug. But Tenable found that organizations which had remediated their systems often encountered Log4j again and again as they added new assets to their environments.

In many instances — 29%, in fact — servers, Web applications, containers, and other assets became vulnerable to Log4j soon after initial remediation.

"Assuming organizations build the fix into the left side of the equation — during the build pipeline for software — rates of reintroduction should diminish," Huber says. "Much of the rate of reintroduction and change depends greatly on an organization's software release cycle."

Also, despite almost ubiquitous awareness of the flaw within the cybersecurity community, vulnerable versions of Log4j remain vexingly hard to find at many organizations because of how applications use it. Some applications might use the open source logging component as a direct dependency in their applications, and in other instances an application might use Log4j as a transitive dependency — or a dependency of another dependency, says Brian Fox, CTO at Sonatype.

"Since transitive dependencies are introduced from your direct dependency choices, they may not always be known or directly visible to your developers," Fox says.

In many cases, when the Apache Foundation first disclosed Log4Shell, companies had to send out thousands of internal emails, collect results in spreadsheets, and recursively scan file systems, Fox says. "This cost companies valuable time and resources to patch the component and prolonged the magnitude of the vulnerability's malicious effect," he says.

Data from the Maven Central Java repository that Sonatype maintains shows that 35% of Log4 downloads currently continue to be of vulnerable versions of the software. "Many companies are still trying to build their software inventory before they can even begin a response and are unaware of the implications of transitive dependencies," Fox says.

Because of all of the issues, the US Department of Homeland Security review board earlier this year concluded that Log4 is an endemic security risk that organizations will need to contend with for years. Members of the board assessed that vulnerable instances of Log4j will remain in systems for many years to come and put organizations at risk of attack for the foreseeable future.

**The One Positive Outcome**

Security researchers tracking the bug say that the positive fallout from Log4j is the heightened attention it has drawn to practices such as software composition analysis and software bill of materials (SBOM). The challenges that organizations have faced just determining whether they are vulnerable or where the vulnerability might exist in their environment has fostered a better understanding of the need for visibility into all the components in their codebase — especially those from open source and third-party sources.

"The investigation into the Log4J issue has reaffirmed the need for better software supply chain attestation in addition to SBOMs that keep up with the speed of DevOps," says Matthew Rose, CISO at ReversingLabs. "Application security and architecture teams have realized that just looking for risk in parts of the application like source code, APIs, or open source packages is not enough. They now realize that a complete understanding of the application's architecture is just as important as finding SQLI or cross-site scripting bugs (XSS)," he says.

One Year After Log4Shell, Most Firms Are Still Exposed to Attack

The Hell's Keychain attack vector highlights common cloud misconfigurations and secrets exposure that can pose grave risk to enterprise customers.

A vulnerability in IBM Cloud databases for PostgreSQL could have allowed attackers to launch a supply chain attack on cloud customers by breaching internal IBM Cloud services and disrupting the hosted system's internal image-building process.

Security researchers from Wiz discovered the flaw, which they dubbed "Hell's Keychain." It included a chain of three exposed secrets paired with overly permissive network access to internal build servers, the researchers revealed in a blog post published Dec. 1. 

While now patched, the vulnerability is significant in that it represents a rare supply-chain attack vector impacting the infrastructure of a cloud service provider (CSP), Wiz CTO Ami Luttwak tells Dark Reading. The discovery also uncovers a class of PostgreSQL vulnerabilities affecting most cloud vendors, including Microsoft Azure and Google Cloud Platform.

"This is a first-of-a-kind supply-chain attack vector, showing how attackers might be able to leverage mistakes in the build process to take over the entire cloud environment," he says.

Specifically, researchers uncovered "major risk caused by improper sanitation of build secrets from container images, allowing for an attacker to gain write access to the central container image repository," Luttwak says. This would have allowed the actor to run malicious code in customers’ environments and modify the data stored in the database.

"Modifications to the PostgreSQL engine effectively introduced new vulnerabilities to the service," the researchers wrote in their post. "These vulnerabilities could have been exploited by a malicious actor as part of an extensive exploit chain culminating in a supply-chain attack on the platform."

As mentioned, the ability to use PostgreSQL to breach IBM Cloud is not unique to the service provider, researchers said. Wiz already has found similar vulnerabilities in other CSP environments, which they plan to disclose soon and which highlight a broader issue of cloud misconfigurations that pose a supply chain threat to enterprise customers.

The existence of the flaw also highlights how improper management of secrets — or long-lived authentication tokens for cloud APIs or other enterprise systems — can impose a high risk of unwanted intrusion by attackers on an organization using a cloud provider, Luttwak says.

"Finding and utilizing exposed secrets is the No. 1 method for lateral movement in cloud environments," he says.

For now, the researchers said they worked with IBM to remedy the issue in IBM Cloud and no customer mitigation action is required.

**Uncovering the Chain**

Researchers were doing a typical audit of IBM Cloud's PostgreSQL-as-a-service to find out if they could escalate privileges to become a "superuser," which would allow them to execute arbitrary code on the underlying virtual machine and continue challenging internal security boundaries from there.

Based on their experience, they said the ability to carry out a supply chain attack on a CSP lies in two key factors: the forbidden link and the keychain.

"The forbidden link represents network access — specifically, it is the link between a production environment and its build environment," the researchers wrote. "The keychain, on the other hand, symbolizes the collection of one or more scattered secrets the attacker finds throughout the target environment."

On its own, either scenario is "unhygienic," but not critically dangerous. However, "they form a fatal compound when combined," the researchers said.

Hell’s Keychain held three specific secrets: a Kubernetes service account token, a private container registry password, and continuous integration and delivery (CI/CD) server credentials.

Combining this chain with the so-called forbidden link between Wiz's personal PostgreSQL instance and IBM Cloud databases’ build environment allowed researchers to enter IBM Cloud’s internal build servers and manipulate their artifacts, the researchers said.

**Implications for Cloud Security**

The scenario presented in Hell's Keychain represents a broader problem within the cloud security community that demands attention and remediation, the researchers said. To wit: scattered plaintext credentials that are found across cloud environments that impose a huge risk on an organization, impairing service integrity and tenant isolation, they said.

For this reason, secret scanning at all stages of the pipeline is crucial, including in CI/CD, code repo, container registries, and within the cloud, Luttwak says.

"Furthermore, lockdown of privileged credentials to the container registry is crucial, as these credentials are often overlooked but are actually the keys to the kingdom," he adds.

CSP customers also should consider image signing verification via admission controllers to ensure these sort of attacks are prevented entirely, Luttwak says.

Hell's Keychain also highlights a common misconfiguration in the use of the popular Kubernetes API for container management within the cloud — pod access, ''which can lead to unrestricted container registry exposure," he says.

Another best practice the researchers recommend is any organization — CSP or otherwise — deploying a cloud environment can take is to impose strict network controls between the Internet-facing environment and the organization's internal network in the production environment, so attackers can't gain a deeper foothold and maintain persistence if they do manage to breach it.

IBM Cloud Supply Chain Vulnerability Showcases New Threat Class

As consumers catch on to the dangers, protection could become a major topic for legislative bodies.

It's no longer a case of _if_ but _when_ a data breach will occur — and consumers are catching on. In the age of digital services, this is a critical development because it means the average US consumer is now demanding the power to make more informed decisions about the way their data is used, stored, and processed. And for US legislative bodies, it means data protection could soon be a major topic on the ballot.

According to the latest Thales Consumer Digital Trust Index, almost half (48%) of US consumers report being victims of a data breach — higher than their global counterparts, at 33%. The sheer volume of cyberattacks in the US has brought data security to the mainstream eye, and consumers are tuning into the legal fallout from breaches affecting millions, including T-Mobile's 2021 cyberattack and Drizly's 2020 hack. Now, they are starting to make more informed decisions about how they want their data handled going forward.

**The Public Is Taking Data Security into Their Own Hands**

Breaches and ransomware attacks have dominated headlines and news cycles, and one in 20 victims reported first hearing about a breach affecting them on the news. Eleven percent of those companies took up to six months to inform consumers about a data breach — a failure on the part of the companies in question.

This pattern of weak transparency has driven consumers to take security matters into their own hands, as they realize inaction is not an option. Just over a fifth have stopped using a company that suffered a data breach, with a large portion of those requesting the company delete their information altogether, while others are keeping a closer eye on their accounts for suspicious activity (21%).

These actions show that data security is a priority for consumers, and it's good practice for organizations to enable them to share this responsibility, in part. Allowing for extra security measures on digital accounts, such as two-factor authentication (2FA), gives consumers more of a sense of control over their information — and that peace of mind is a key element in building trust.

**Paying a Fine Is Not Enough**

As for what they expect from companies that fail to keep their data secure, financial compensation is a natural consequence. Of surveyed consumers, 53% believe companies should offer compensation to victims, but, when it comes to overseeing regulations, only 31% believe companies should receive large fines for breaches, meaning it is far from the biggest priority from a consumer perspective. What more consumers want is better data security measures — not big payouts.

However, the methods consumers believe should be used differ. More than half believe companies should be forced into mandatory data protection controls following a breach. This includes encryption and 2FA, which have long been favored options. And just under half believe companies should be subject to more stringent regulation — for example, being monitored for 12 to 14 months post-breach. Others believe companies should be required to employ more cyber specialists — but the reigning feeling is that regulatory oversight would be a major improvement.

**We're Looking to the Future of US Data Privacy and Security**

One possible contender for that oversight is the American Data Privacy and Protection Act (ADPPA). Similar to the European Union's General Data Protection Regulation (GDPR), which put in place necessary guidelines for European consumer data, ADPPA is a landmark US federal privacy proposal that could potentially meet sweeping demands for security and privacy. Proposed in July 2022, it could also face a number of barriers, including tension between federal and state privacy rights and blowback from tech giants.

While we wait to hear about the progression of this legislation, it is increasingly clear that if it does not become law in the near future, something will have to provide that modicum of oversight. To fully realize what kind of change will be effective, it is important to understand consumer perceptions around data security in the US, and for organizations to provide more visible safeguards in their digital services, in the meantime.

In a digital world, data privacy and security cannot take a backseat. With GDPR leading as example, there is not only a need for similar federal legislation in the US, but a calling for it from US consumers who are tired of finding out they are victim of another breach, leak, or attack. They are ready to take data protection seriously, and it is time we see some federal defenses put in place.

Data Security Concerns Are Driving Changes in US Consumer Behavior and Demands

No longer the realm of lone wolves, the world of cybercrime is increasingly strategic, commoditized, and collaborative.

Just as you keep up with the latest news, tools, and thought leadership in order to protect and secure your organization from cybercriminals, your adversaries are doing the same thing. They are connecting on forums, evaluating new software tools, talking with potential buyers, and searching for new ways to outsmart your security stack.

A peek into their world shows they have advanced capabilities that often outmaneuver well-funded security teams and corporate security tools, especially when pitted against legacy solutions like signature-based antiviruses. Many security operations centers (SOCs) fail to prioritize real threats, while wasting time trying to solve others that they can realistically never scale to meet.

Security defenders need to move beyond the mental image of the lone hooded figure sitting in a dimly lit basement as cigarette smoke wisps up from a dirty ashtray. Let's take stock of the world of cybercrime as it exists today: strategic, commoditized, and collaborative (especially if the criminals have money to spend).

**Strategic Intent Backs Every Attack**

Adversaries always have a business purpose; there’s a plan for every piece of malware. To begin, cybercriminals snoop around for access to your environment, looking for something they can steal and potentially resell to someone else. While an attacker may not know _exactly_ what they want to do once they gain access to your environment, they tend to recognize value when they see it.

They may perform reconnaissance by looking for misconfigurations or exposed ports to exploit, a process often made trivially easy by known CVE databases and free open-port scanners. Initial compromise can also be accomplished by stealing a user’s credentials to access the environment, a process that’s sometimes even easier, before moving laterally to identify key assets.

**The Cyber Weapons Black Market is Maturing**

Cybercriminals have developed a sophisticated underground marketplace. Tools have evolved from relatively inexpensive and low-tech products into those with advanced capabilities delivered via business models familiar to legitimate consumers, like software as a service (SaaS). Threat hunters are witnessing the commoditization of hacking tools.

Phishing kits, pre-packaged exploits, and website cloning tools used to be very common. Designed to mimic website login pages, such as Microsoft Office 365 or Netflix, these tools were quite effective at capturing users’ credentials for many years.

Over the past two decades, though, the security community responded to this type of activity with techniques like pattern recognition, URL crawling, and shared threat intelligence. Tools like VirusTotal have made it a common practice for the discovery of malicious files to be shared with the wider security community almost instantaneously. Naturally, adversaries are well aware of this and have adapted.

**A New Phishing Methodology**

Today’s adversaries have also learned to capitalize on the rise of multi-factor authentication (MFA) by hijacking the verification process.

One new type of phishing kit is called EvilProxy. Like kits of the past, it mimics website login pages to trick users into giving away their login credentials. Unlike phishing kits of the past that were sold as one-time purchases, this new methodology — sold by specialists in access compromise — operates via a rental model, whereby the seller rents out space on their own server for running phishing campaigns.

They host a proxy server that operates like a SaaS model. The service costs about $250 for 10 days of access. This allows the SaaS providers to make more money and enables them to collect statistics they can then publish on hacker forums to market their products and compete against other sellers.

New kits have built-in protections to defend their phishing environment from unexpected visitors. Since they obviously don’t want web crawlers indexing their sites, they use bot protection to block crawlers, nuanced virtualization detection technology to ward off security operations teams doing reconnaissance through a virtual machine (VM), and automation detection to prevent security researchers from crawling their kit websites from different angles.

**The “Adversary in the Middle” Scenario**

In the context of bypassing MFA, acting as a reverse proxy to the authentic login page content creates big problems for typical phishing detection. By sitting between the user and the target website, the reverse proxy server allows the adversary to gain access to the username, password, and session cookie that is set after MFA is completed. They can then replay the session back into a browser and act as the user on that destination.

To the user, everything looks normal. By using slight variations of names in the URLs, the cybercriminals can make the site seem completely legitimate, with everything working as it should. Meanwhile, they have gained unauthorized access through that user, which can then be exploited for their own purposes or auctioned off to the highest bidder.

**The Adversary’s Business Model**

In addition to new phishing methodologies, malware is sold openly on the Internet and operates in a sort of gray space, floating between legal and illegal. One such example is BreakingSecurity.net, which markets the software as a remote surveillance tool for enterprise.

Every piece of malware has a price point associated with it to drive an outcome. And these outcomes have a clear business intent, whether it’s to steal credentials, generate cryptocurrency, demand a ransom, or gain spy capabilities to snoop around a network infrastructure.

Nowadays the creators of these tools are partnering with the buyers through affiliate programs. Similar to a multi-level marketing scheme, they say to the affiliate buyer of the tool, “Come to me when you get in.” They even offer product guarantees and 24/7 support of the tool in exchange for splitting the profits. This allows them to scale and build a hierarchy. Other types of cybercriminal entrepreneurs sell pre-existing compromises to the highest bidder. There are multiple business models at play.

**Today’s Reality: Case for an Advanced Cloud Sandbox**

Security teams should understand what today’s adversaries do and how quickly their actions can play out. The advanced malware on the market now is even more severe than phishing. Whether it’s Maldocs that evade filters, ransomware, information stealers, remote access trojans (RATs), or post-exploitation tools that combine toolsets, threat actors are more advanced than ever before—and so are their business models.

Countermeasures based on standard sandboxes doesn’t provide much in the way of inline prevention. Detection that combines cloud and AI can stop the stealthiest threats inline, in real time, and at scale.

If you’re not evolving with adversaries, you're falling behind. Because today’s cybercriminals are as professional and on their game as you.

Read more _Partner Perspectives_ from Zscaler.

Source

DARKReading