Identity and access management was front and center at AWS re:inforce this week.

Amazon emphasized identity and access management during its AWS re:Inforce Security conference in Boston this week. Among announcements for GuardDuty Malware Detection and Amazon Detective for Elastic Kubernetes Service (EKS), Amazon Web Services executives highlighted the launch of IAM Roles Anywhere from earlier this month, which enables AWS Identity and Access Management (IAM) to run on resources outside of AWS. With IAM Roles Anywhere, security teams can provide temporary credentials for on-premises resources.

IAM Roles Anywhere enables on-premises servers, container workloads, and applications to use X.509 certificates for the temporary AWS credentials, which can use the same AWS IAM roles and policies. "IAM Roles provides a secure way for your on-premises servers, containers, applications, to obtain temporary AWS credentials," AWS VP of Platforms Kurt Kufeld said.

Creating temporary credentials is an ideal alternative when they are only needed for short-term purposes, Karen Haberkorn, AWS director of product management for identity, said during a technical session.

"This extends IAM Roles so you can use them and workloads running outside of AWS that lets you tap into all the power of AWS services wherever your applications are running," Haberkorn said. "It lets you manage access to AWS services in the exact same way you are doing today for applications that run in AWS, for applications that run on premises, at the edge — really anywhere."

Because IAM Roles Anywhere enables organizations to configure access the same way, it reduces training and provides a more consistent deployment process, Haberkorn added. "And yes, it means a more secure environment," she said. "It's more secure because you no longer having to manage the rotation and the security of any long-term credential that you might have used for on-premises applications in the past."

**New IAM Identity Center**

Amazon also announced that it has renamed its AWS Single Sign-On offering "AWS Identity Center." Principal product manager Ron Cully explained in a blog post this week that the name change is to better reflect its full set of capabilities and to support customers who in recent years have shifted to a multi-account strategy. AWS is also looking to "reinforce its recommended role as the central place to manage access across AWS accounts and applications," Cully wrote.

While AWS hasn't announced any technical changes to AWS Identity Center, Cully said that it has emerged as the "front door into AWS." AWS Identity Center handles all authentication and authorization requests, and now processes half a billion API calls per second.

Curtis Franklin, a senior analyst who covers enterprise security management and security operations at Omdia, noted that AWS underscored IAM throughout the 2-day conference. "AWS gave signs that it considers identity the frontline to security and privacy in the cloud," he said. "I think they are going to continue to bring in partners so that AWS is the single source of truth about who authorized users are and what privileges they can have."

AWS Focuses on Identity Access Management at re:Inforce

While attackers continue to rely on older, unpatched vulnerabilities, many are jumping on new vulnerabilities as soon as they are disclosed.

Attackers play favorites when looking at which software vulnerabilities to target, according to researchers from Palo Alto Networks.

Nearly one in three, or 31%, of incidents analyzed by Unit 42 in its 2022 "Incident Response Report" resulted from attackers gaining access to the enterprise environment by exploiting a software vulnerability. Six CVE categories accounted for more than 87% of vulnerabilities being exploited: ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207), Log4j, ProxyLogon (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065), multiple vulnerabilities in SonicWall and Fortinet products, and a vulnerability in Zoho ManageEngine ADSelfService Plus (CVE-2021-40539).

In 55% of incidents where Unit 42 was able to identify the vulnerability, the attackers had targeted ProxyShell. Just 14% of those cases involved Log4j. Unit 42 researchers analyzed data from a sampling of over 600 incident response engagements between April 2021 and May 2022 for the report.

While attackers continue to rely on older, unpatched vulnerabilities, many are looking at new vulnerabilities as well. Scanning for vulnerabilities is not a difficult task, so attackers begin scanning for systems with a newly disclosed vulnerability as soon as they learn about them.

"The 2021 Attack Surface Management Threat Report \[released in April\] found that attackers typically start scanning for vulnerabilities within 15 minutes of a CVE being announced," the company said in blog post accompanying the incident response report. "In fact, it can practically coincide with the reveal if the vulnerabilities themselves and the access that can be achieved by exploiting them are significant enough."

As an example, researchers detected scanning and exploitation attempts targeting the authentication bypass vulnerability in F5 BIG-IP appliances (CVE-2022-1388) 2,552 times within 10 hours.

Exploiting software vulnerabilities was the second most common attack method, according to the Unit 42 analysis. The top access vector was phishing. Brute-force credential attacks, primarily targeting Remote Desktop Protocol, rounded out the top three. These three attack vectors made up more than three-quarters of incidents (77%) analyzed in the incident response report.

Attackers Have 'Favorite' Vulnerabilities to Exploit

Dark Reading's digest of other "don't-miss" stories of the week — including a Microsoft alert connecting disparate cybercrime activity together, and an explosion of Luca Stealer variants after an unusual Dark Web move.

Being a cybersecurity-focused news team is a busy business, and we can't always bring you all the news that's fit to print in a given week. That's why we've developed our weekly digest that rounds up all of the things that we couldn't get to, in case you missed it (ICYMI).

This week, we go deep into the world of the cybercrime underground, and how these markets and the complex relationships typically function.

ICYMI, read on for the following stories from the Dark Web:

*   **Raspberry Robin USB Worm Linked to Evil Corp.**
*   **Initial Access Brokers Are Now Actively Targeting MSPs**
*   ****Dozens of Luca Stealer Variants Rise Up After Author Goes Open Source****

**Raspberry Robin USB Worm Linked to Evil Corp.**

Raspberry Robin, a backdooring worm that infects PCs via Trojanized USB devices before spreading to other devices on a target's network, has been marshalled into service to enable a campaign that appears to track with Evil Corp. tactics.

According to an updated alert from Microsoft on Thursday, existing, dormant Raspberry Robin infections are being used by a known initial access broker (tracked by the tech giant as DEV-0206) to deploy the FakeUpdates malware, which in turn fetches additional code.

At this point, Evil Corp. takes over, according to the analysis. In this stage, FakeUpdates delivers Cobalt Strike and other hallmarks of "pre-ransomware," before deploying a custom in-house ransomware payload such as WastedLocker, PhoenixLocker, or Macaw.

"Around November 2021, \[Evil Corp.\] started to deploy the LockBit 2.0 … payload in their intrusions," according to the post. "The use of a RaaS payload by the Evil Corp. activity group is likely an attempt … to avoid attribution to their group, which could discourage payment due to their sanctioned status."

DEV-0206 and Evil Corp. have worked together for a while, Microsoft notes, but the initial access was before achieved via malvertising. The connection to Red Raspberry is new and notable, according to the researchers.

"We continue to see Raspberry Robin activity, but we have not been able to associate it with any specific person, company, entity, or country," says Katie Nickels, director of intelligence at Red Canary, which first discovered the threat in 2021. "Ultimately, it’s too early to say if Evil Corp is responsible for, or associated with, Raspberry Robin."

**Initial Access Brokers Are Now Actively Targeting MSPs**

Initial access brokers (IABs) are a key piece of the underground economy; they break into networks, establish backdoors, then rent that access to fellow nefarious types. Researchers at Huntress this week revealed a new twist: IABs actively hawking access to a managed service provider (MSP) as a way to get to their downstream customers.

Huntress CEO Kyle Hanslovan came across an ad on an underground forum offering just such access, boasting that the rental would include an "in" to the networks of at least 50 of the MSP's customers.

MSPs were, infamously, the target for the Kaseya fiasco, which resulted in more than 5,000 organizations suffering REvil ransomware attacks.

MSPs remain an attractive supply chain target for attackers of all types, as flagged by US federal agencies in May. A warning for MSPs and their customers noted that MSPs in multiple countries (including Australia, Canada, New Zealand and the UK) were likely being actively targeted.

**Dozens of Luca Stealer Variants Rise Up After Author Goes Open Source**

The infostealing baddie known as Luca Stealer is about to become more prevalent on the cybercrime scene, researchers are warning, thanks to the source code being revealed online.

Researchers at Cyble said this week that the developer of the Rust-coded malware decided to openly post the source code on cybercrime forums and on GitHub on July 3, in hopes of burnishing a fledgling reputation as a malware coder. It's an odd move in a world where custom malware can be rented out at a premium.

Less than a month later, there are already more than 25 Luca Stealer samples making the rounds, developed by multiple threat actors. And there will likely be even more, given that the original author continued to update the GitHub code, and has provided helpful tips on how to modify it for crime and profit.

Luca Stealer has a host of concerning capabilities, including the ability to lift data from Chromium-based browsers, exfiltrate files, and steal information from messaging applications and cryptowallets. In current observed campaigns, cybercriminals are especially going after crypto enthusiasts, according to Cyble.

ICYMI: Dark Web Happenings Edition With Evil Corp., MSP Targeting & More

In a Black Hat USA talk, Katie Moussouris will discuss why bug-bounty programs are failing in their goals, and what needs to happen next to use bounties in a way that improves security outcomes.

It's been about a decade since the hype for bug-bounty programs first started going supernova, but the jury is still out on the effectiveness of them. According to Katie Moussouris, founder and CEO of Luta Security, the average organization struggles to squeeze meaningful security results from bug bounties, and continue to wrestle with execution.

Bug-bounty programs are certainly more mainstream than ever, with bounties popular at far more than just the big-name tech companies now. Product security and enterprise cybersecurity professionals at a growing range of organizations increasingly turn to such programs to act as an application security backstop, often fueled by the convenience and sales machine of the growing bug-bounty platform market.

But while many organizations may start out strong with their bug-bounty programs, "at about the 18-month to two-year mark they start to collapse under their own weight," Moussouris tells Dark Reading.

This collapse is typically heralded by overwhelmed, overworked program managers at these companies who are unable to keep up with the volume of bugs submitted by bounty hunters, as well as software that still remains riddled with vulnerabilities and often plagued with the most basic of security flaws.

"I can tell you that bug bounties have been a great idea poorly executed for the last decade or so," says Moussouris, who will be discussing the challenges in a talk scheduled for Thursday, August 11 at Black Hat USA, "Bug Bounty Evolution: Not Your Grandson's Bug Bounty."

"I think that there's room for a ton of improvement, not just in how bug bounties are designed and executed, but also in the holistic picture of the ecosystem in which a bug bounty operates," she said.

One of the big systemic issues is the fact that many bug-bounty programs are implemented irrespective of the maturity of the underlying cybersecurity program's practices. That means asset visibility, vulnerability management, developer training, and more, says Moussouris. While bug bounties may be a great supplement to a solid base of application-security practices, some organizations mistakenly believe they can rely solely on the bounties to keep their software safe.

"From our perspective, we like to say no 'bug-bounty Botox.' We want you to be pretty on the inside," says Moussouris. "We want organizations to be not just prepared to fix the bugs thrown over the fence in a vuln-disclosure program or bug-bounty program, but to be actually looking at their core security investments. \[They also need to be\] using bug-bounty programs as an indicator of health of their overall security program. Because if you think about it, every bug is a symptom of an underlying disorder in their security system."

**Design Bug Bounties for Good Security Outcomes**

Moussouris says that the issue is a "systems-dynamic problem at its core." At Black Hat, she plans to explore recommendations on how security teams can design their holistic program to use bounties so that they create the deliberate security outcomes they want and which can be demonstrated in a meaningful and measurable way.

Ultimately, she believes a bug-bounty program shouldn't just highlight the low-hanging fruit that can be discovered from traditional application security practices, but also provide incentives for surfacing the complex, hard-to-find, and harder-to-exploit flaws.

**Better Bug-Bounty Programs for Hunters**

Moussouris says her talk will also tackle the flip side of the bug-bounty ecosystem — namely the fact that the system doesn't serve bug-bounty hunters very well either.

"It's like the worst gig economy job you could possibly get," she explains. "Worse than an Uber or Lyft job, because you get paid with every gig that you take with Uber and Lyft; you do not get paid for every single bug you find if you are a bug-bounty hunter. So both sides of this marketplace have been done wrong by the commercialization as it currently exists."

Ancillary to that, she'll explore what the security world needs to do to expand the marketplace for security labor, including taking a deep dive into apprenticeship models and building a pipeline for developing talent and education around vulnerability remediation and application security resilience.

Why Bug-Bounty Programs Are Failing Everyone

The first half of the year saw more than 11,800 reported security vulnerabilities, but figuring out which ones to patch first remains a thankless job for IT teams.

The number of vulnerabilities disclosed in the first half of the year topped 11,800, forcing companies to determine the impact of an average of 90 security issues per weekday.

The numbers are from cybersecurity firm Flashpoint's "The State of Vulnerability Intelligence — 2022 Midyear Edition" report, which notes that the massive number of vulnerabilities reported in the first half of the year highlights the problems facing companies as they try to triage software security issues and determine which software updates to prioritize. 

Without better guidance, organizations attempting to sort through the security issues struggle to separate those that are highly critical from minor vulnerabilities and those that may not affect their environment at all, says Brian Martin, vice president of vulnerability intelligence at Flashpoint.

"There are some issues that will have no bearing on any real organization in the world — it might be a vulnerability in some Chinese blog that has seven installs worldwide," Martin says. "On the other hand, we do have vulnerabilities in Microsoft products, Google products, Apple products. Stuff that is just as high-profile and concerning as any issue from a Patch Tuesday."  

    

Daily vulnerability volumes in the first half of 2022. Source: Flashpoint

Clouding the issue is the focus put on zero-day vulnerabilities, those labeled as "discovered in the wild" by researchers before a patch is available. These are difficult to collect information on. Google's Project Zero documented 20 such vulnerabilities exploited in the wild in the first half of 2022, while Flashpoint found at least 17 more issues.

Yet the most common attacks usually use known vulnerabilities.

"Discovered-in-the-wild vulnerabilities are often used in high-profile breaches or are attributed to Advanced Persistent Threat (APT) attacks," the report states. "Due to their nature, organizations often lack defensive options for them. However, business leaders need to keep in mind that discovered-in-the-wild vulnerabilities represent a tiny fraction of compromises occurring around the world."

Organizations also had to deal with a growing number of days with hundreds of reported vulnerabilities because of software vendors' regularly scheduled updates. In February, for example, Flashpoint documented 351 issues thanks to releases from Microsoft's Patch Tuesday and disclosures from other software vendors falling on the same day. In April, a similar convergence of software-vulnerability disclosures saw the highest number of vulnerabilities, 356, released in a single day.

"Organizations need to be aware that the vulnerability disclosure landscape is highly volatile, with 'standard' days potentially introducing volumes traditionally seen only on Patch Tuesdays and other similar events," the Flashpoint report states.  

**Snowballing Levels of Vulnerability Disclosures**

The report also shows that the number of vulnerabilities disclosed to vendors continues to remain at high levels.

The National Vulnerability Database (NVD) also documented more than 11,000 flaws assigned Common Vulnerability and Exposures (CVE) identifiers in the first six months of the year. However, a fraction of those are not true reported vulnerabilities but vendors reserving CVE identifiers for future, or yet-to-be disclosed, vulnerabilities. Flashpoint estimates that its database has details on 27% more vulnerabilities than documented in the NVD.  

While various distributions of Linux topped the chart of vulnerable applications — such as SUSE, openSUSE Leap, and Ubuntu — open source–focused companies accounted for only four of the 10 vendors with the highest vulnerability counts in the first half of 2022. Yet high counts are not necessarily a sign of insecurity but are often a sign that the software company has a process in place to detect and remediate issues.

"There are many underlying reasons as to why certain products and vendors tend to have high vulnerability counts, such as overall market share, product-specific market share, routine — or lack of — schedule of disclosures, attention from vulnerability researchers, and vendor response/patch time, among others," the Flashpoint report states. "Therefore, organizations should not be immediately concerned about well-known vendors having 'more' vulnerabilities, as it could be a sign that they are actively disclosing and patching issues."

Security Teams Overwhelmed With Bugs, Bitten by Patch Prioritization

The new GuardDuty Malware Protection and Amazon Detective were among 10 products and services unveiled at AWS re:Inforce in Boston this week.

Amazon Web Services (AWS) has added malware protection to its GuardDuty threat detection service for EC2 compute instances and container workloads backed by Elastic Block Storage (EBS) volumes. The new GuardDuty Malware Protection option is designed to detect suspicious files that could be malware and then alert administrators through the AWS Security Hub.

The release of GuardDuty Malware Protection was among 10 new products and services that the cloud provider revealed during its AWS re:Inforce security conference in Boston this week. Amazon hosted thousands of security professionals at the event, which included a broad agenda of technical sessions, training and certification workshops, and panel discussions.

AWS Platform VP Kurt Kufeld outlined the cloud provider's latest security announcements during the event's opening keynote session. Explaining how the new GuardDuty Malware Protection feature works, Kufeld said when it detects suspicious files, it takes a snapshot of the associated EBS volume as the workload is processing.

GuardDuty then sends its findings to the AWS Security Hub via Amazon EventBridge, the same way it handles other threat activities. Amazon Detective, a tool AWS added in 2020 that uses machine learning to investigate events by analyzing log data, detects if any malware is present. 

"Use the integration to gain visibility into your overall security state for your organization, as well as easily search, filter, triage, investigate, or take action on any of the security findings that you do have," Kufeld said.

GuardDuty then analyzes what it finds with compute that runs in the AWS service account, "not your account, so as not to disturb the workload or require any agents or security software to be deployed inside your workload," Kufeld added. "When malware is detected, GuardDuty malware protection automatically sends additional and contextualized malware findings to GuardDuty console."

Curtis Franklin, a senior analyst who covers enterprise security management and security operations at Omdia, said AWS is taking an aggressive step with the addition of GuardDuty Malware Protection. 

"Calling it malware protection is a stretch; it's malware detection, and that's a critical difference," Franklin said. "It is not a fully featured offering, but it does plant a stake in the market for them."

AWS identified nine partners whose threat protection can integrate with its new malware offering: Bitdefender, CloudHesive, CrowdStrike, Fortinet, Palo Alto Networks, Rapid7, Sophos, Sysdig, and Trellix.

**Kubernetes Support for Amazon Detective**

Among other new offerings, AWS has added support for Kubernetes workloads with the addition of Amazon Detective for EKS, which builds on the managed threat analytics service. Amazon Detective ingests a wide variety of events, such as login attempts, API calls, and traffic, from various AWS services, including GuardDuty, AWS CloudTrail, and Amazon VPC. Since launching Amazon Detective two years ago, AWS has added support for identity and access management (IAM) roles, IP address analytics, integration with Splunk, Amazon S3, and AWS Organizations.

Amazon Detective for EKS was created in response to organizations moving to containers, which has resulted in growth of AWS' Elastic Kubernetes Service (EKS).

"Amazon Detective for EKS analyzes, investigates, and identifies the root cause of security findings for suspicious control-plane activity on EKS clusters," Kufeld said. "With a single-click setting and no agent requirements, it is much easier to start analyzing Amazon EKS specific activity. It uses advanced correlation and graph-based analytics to investigate security findings from suspicious container images or container misconfigurations that may allow access to the underlying EC2 nodes."

Amazon Adds Malware Detection to GuardDuty TDR Service

Why was PII belonging to nearly 1 billion people housed in a single, open database? Why didn't anyone notice it was downloaded?

Questions continue to swirl around a June 30 incident where an unknown individual put up for sale on a popular underground forum a staggering 23TB of personally identifiable information (PII), belonging to some 1 billion people in China. 

And, in the meantime, the database is continuing to cause ripples across the Dark Web.

The dataset was reportedly accessed from an unsecured Shanghai police database hosted on Alibaba's cloud hosting platform. It included names, addresses, birthplaces, phone numbers, national IDs, and criminal records associated with Chinese citizens and even foreign nationals who might have visited Shanghai during the past few years. The database is still available for sale for 20 bitcoins, or roughly $240,000 currently.

The leak is believed to have happened because a dashboard for managing the database was apparently left open to the Internet, without a password, for more than one year. Though the incident represents one of the largest ever compromises of PII to date, news of it has reportedly been largely blacked out in China. 

However, that has not stopped members of the country's prolific hacking community from flocking to the underground forum where the data is available, according to researchers at Cybersixgill who have been tracking the aftermath of the massive breach. There also has been a notable increase in data leaks of Chinese entities that have been shared on the forum since June 30, they noted.

"We anticipate that we will be seeing the reverberations of this breach on the underground for quite some time," predicts Naomi Yusupov, Chinese intelligence analyst at Cybersixgill. She expects that threat actors will try and use the leaked data in social engineering campaigns, in attacks to try and access more data, and in a variety of other malicious ways.

Yusupov also expects the breach to encourage other threat actors to share more data from breaches in China, as has already begun happening. Chinese threat actors appear to be viewing the high asking price for the Shanghai data as an indication that Chinese databases overall are highly valuable. This could encourage more Chinese data leaks, she says.

"The massive uptick in Chinese users active on the forum could increase the communication and knowledge transfer between the Chinese and the English underground," she notes.

**More Than Just Another Cloud Misconfig**

There have been countless instances where organizations have similarly exposed sensitive data by leaving it in poorly secured, Internet-accessible cloud storage buckets like Amazon's S3 and ElasticSearch buckets. The most recent incident involved 3TB of sensitive data belonging to airport employees in Columbia and Peru that was exposed via a misconfigured Amazon S3 bucket. 

Vendors such as Upguard have reported detecting thousands of such instances in recent years. UpGuard's most notable discoveries on S3 buckets include some 540 million records from multiple Facebook third-party apps, trade secrets belonging to GoDaddy, and 73GB of data belonging to Pocket Inet employees.

What makes the Shanghai breach notable is its sheer scale. By most accounts, it is one of the largest ever known compromises of PII.

"We see breaches like this quite often," says Ray Kelly, fellow at the Synopsys Software Integrity Group. "\[But\] the staggering volume and breadth of PII that was contained about Chinese citizens and non-citizens alike will certainly raise red flags."

And it's not just the seeming lapse in securing the database alone that's at issue here: "Was it smart to store 1 billion users' PII in one location to begin with?" he asks rhetorically.

John Bambenek, principal threat hunter at Netenrich, says another big question is why nobody noticed 23TB worth of data being downloaded from the cloud database. 

"Aside from backups, I can’t think of any legitimate use case that involves moving an entire dataset like that," he says. 

Often, database administrators set databases to give people read access and rarely have controls to detect when someone might be abusing that access. Even so, "basic network anomaly detection likely could have caught this," Bambenek says.  

**A Rare Peek**

The Shanghai police data compromise is also notable because there have been few instances where a major cybersecurity incident in China has become public knowledge. 

"While China has historically been home to one of the world's largest communities of cybercriminals, domestic Chinese breaches are rarely disclosed because the Chinese government censors media coverage," Cybersixgill's Yusupov says. For instance, major Chinese social media platforms such as Weibo and WeChat both censored news of the Shanghai police database breach.

Even so, there have been other instances where details of breaches within China have trickled to the outside world, Yusupov notes. One example is a 2016 incident in which an anonymous hacker took to Twitter to expose sensitive information related to dozens of Chinese Communist Party officials and Chinese business magnates, such as Alibaba Group founder Jack Ma and real estate tycoon Wang Jianlin of the Dalian Wanda Group.

Other examples include a 2020 incident where a malicious actor stole the data of more than 538 million users and one in May where tens of thousands of apparently hacked files from China's northern Xinjiang region were released, exposing the persecution of the Uyghur ethnic minority there, she says.

Big Questions Remain Around Massive Shanghai Police Data Breach

The campaign uses four malicious packages to spread "Volt Stealer" and "Lofy Stealer" malware in the open source npm software package repository.

Four packages containing highly obfuscated malicious Python and JavaScript code were discovered this week in the Node Package Manager (npm) repository. 

According to a report from Kaspersky, the malicious packages spread the "Volt Stealer" and "Lofy Stealer" malware, collecting information from their victims, including Discord tokens and credit card information, and spying on them over time.

Volt Stealer is used to steal Discord tokens and harvest people's IP addresses from the infected computers, which are then uploaded to malicious actors via HTTP. 

Lofy Stealer, a newly developed threat, can infect Discord client files and monitor the victim's actions. For example, the malware detects when a user logs in, changes email or password details, or enables or disables multifactor authentication (MFA). It also monitors when a user adds new payment methods, and will harvest full credit card details. The collected information is then uploaded to a remote endpoint.

The package names are "small-sm," "pern-valids," "lifeculer," and "proc-title." While npm has removed them from the repository, applications from any developer who already downloaded them remain a threat.

**Hacking Discord Tokens**

Targeting Discord provides a lot of reach because stolen Discord tokens can be leveraged for spear-phishing attempts on victims' friends. But Derek Manky, chief security strategist and vice president of global threat intelligence at Fortinet’s FortiGuard Labs, points out that the attack surface will of course vary among organizations, depending on their use of the multimedia communications platform.

"The threat level would not be as high as a Tier 1 outbreak like we have seen in the past — for example, Log4j — due to these concepts around the attack surface associated with these vectors," he explains.

Users of Discord have options to protect themselves from these kinds of attacks: "Of course, like any application that is targeted, covering the kill chain is an effective measure to reduce risk and threat level," Manky says.

This means having policies set up for appropriate usage of Discord according to user profiles, network segmentation, and more.

**Why npm Is Targeted for Software Supply Chain Attacks**

The npm software package repository has more than 11 million users and tens of billions of downloads of the packages it hosts. It’s used both by experienced Node.js developers and people using it casually as part of other activities.

The open source npm modules are used both in Node.js production applications and in developer tooling for applications that wouldn't otherwise use Node. If a developer inadvertently pulls in a malicious package to build an application, that malware can go on to target the end users of that application. Thus, software supply chain attacks like these provide more reach for less effort than targeting an individual company.

"That ubiquitous use among developers makes it a big target," says Casey Bisson, head of product and developer enablement at BluBracket, a provider code security solutions.

Npm doesn't just provide an attack vector to large numbers of targets, but that the targets themselves extend beyond end users, Bisson says.

"Enterprises and individual developers both often have greater resources than the average population, and lateral attacks after gaining a beachhead in a developer's machine or enterprise systems are generally also rather fruitful," he adds.

Garwood Pang, senior security researcher at Tigera, a provider of security and observability for containers, points out that while npm provides one of the most popular package managers for JavaScript, not everyone is savvy in how to use it.

"This allows developers access to a huge library of open source packages to enhance their code," he says. "However, due to the ease of use and the amount of listing, an inexperienced developer can easily import malicious packages without their knowledge."

It's no easy feat, though, to identify a malicious package. Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, cites the sheer quantity of components making up a typical NodeJS package.

"Being able to identify correct implementations of any functionality is challenged when there are many different legitimate solutions to the same problem," he says. "Add in a malicious implementation that can then be referenced by other components, and you've got a recipe where it's difficult for anyone to determine if the component they are selecting does what it says on the box and doesn’t include or reference undesirable functionality."  

**More Than npm: Software Supply Chain Attacks on the Rise**

Major supply chain attacks have had a significant impact on software security awareness and decision making, with more investment planned for monitoring attack surfaces.

Mackey points out that software supply chains have always been targets, particularly when one looks at attacks targeting frameworks like shopping carts or development tooling.

"What we're seeing recently is a recognition that attacks we used to categorize as malware or as a data breach are in reality compromises of the trust organizations place in the software they’re both creating and consuming," he says.

Mackey also says that many people assumed that software created by a vendor was entirely authored by that vendor, but, in reality, there could be hundreds of third-party libraries making up even the simplest software — as came to light with the Log4j fiasco.

"Those libraries are effectively suppliers within the software supply chain for the application, but the decision to use any given supplier was made by a developer solving a feature problem and not by a businessperson focused on business risks," he says.

That's prompted calls for the implementation of software bills of materials (SBOMs). And, in May, MITRE launched a prototype framework for information and communications technology (ICT) that defines and quantifies risks and security concerns over the supply chain — including software.

Malicious npm Packages Scarf Up Discord Tokens, Credit Card Info

Trying to get the whole organization on board with better cybersecurity is much tougher than it may sound.

With cyberattacks becoming more frequent and costly, not to mention the additional challenges inherent in securing a remote workforce, it is more important than ever that organizations build a culture of security. This of course, isn't a new thing to say and yet it keeps needing to be said. So, why haven't we solved this yet?

Part of it is that the work never stops. It's like leading a healthy lifestyle; regardless of how fit and healthy you get, you never arrive at a point where you can just stop making healthy decisions and stay healthy. What makes it more challenging is trying to get a whole organization on board with making all the small decisions to stay secure.

**Don't Be the Team of "No"**

Security teams are often seen as the team of "no," or like the doctor telling you that you should really cut out salty foods entirely. You might agree in general, but how realistic is it that you never have salty foods again? If rules are overly restrictive or they make tasks significantly harder, people are going to cheat the system. We have to find a way to have more carrot and less stick. We have to pave the road for employees so that security isn't a chore.

It is absolutely important for there to be training on phishing attacks, use two-factor authentication, and regularly change passwords. But how could we simplify this process? I'm a big fan of companies giving employees a subscription to a password manager. This solves one of those concerns while arguably making employees' lives a bit simpler. It's very much about building a two-way street rather than being a hardened gate. This allows us to start building in processes alongside other departments that make sense for their workflow. These processes will change from company to company, but the key here is to look for ways that security can be improved while also improving the workflow for employees in general.

**Embrace Agility**

One of the biggest reasons security teams are bypassed is that they hinder agility. There is nowhere this is more true than on the development team. I have worked in the SaaS space for some time, and the development team's ability to deliver, and deliver fast, is the core of what will determine a company's success or failure.

However, developers are notorious for finding ways around security protocols because the protocols slow down how fast they are able to launch applications. While some security teams might see this as a failure on the developer team, I see it as a failure of the security program. SaaS companies must be able to deliver applications at the speed of business while also being secure. It's the security team's job to be the security coach of the organization and that involves implementing policies that don’t hinder the developer's ability to do their job.

As one example, developers often use open source to avoid recreating functions that already exist and are easy to plug in. The danger of this, however, is the source of this code. There is plenty of malicious code out there, and we have seen even some of the most talented developers fall prey to it. To prevent this, organizations should prioritize creating internal repositories of vetted code that developers can pull from. If the organization isn't of the size to create their own internal repository, they should look for vendors who provide scanned code libraries. This way the developer workflow isn't impeded, but it is nonetheless made more secure.

**Break Down Silos**

Another key step is to build the culture so that security belongs to everyone within the organization. Anyone who touches a computer has to be security aware. While the security teams have to be able to work with different departments and effectively integrate into their workflows, it must still be a collaborative effort. When it comes to enabling the development teams, I recommend building a security champion (or security liaison) program. This gives security a seat at the table as the developers are designing applications and planning work.  

Establishing this program as early as possible in your organization will increase your awareness of what is going on within different development teams and ensure security does not become a bottleneck in the software delivery pipeline. Finding people to buy into this model from other departments is as good as gold for security professionals because the advice always goes down smoother when it isn't coming from the security team directly.

The challenge of course is finding individuals who are willing to take on the extra work of advocating for security, but in the absence of a champion, look to at least get liaisons to the different departments. The simple truth is that security teams are stretched too thin to be the one and only protection from malicious actors, so we need to get buy-in from the rest of the organization.

3 Tips for Creating a Security Culture

Attackers almost immediately leapt on a just-disclosed bug, CVE-2022-26138, affecting Atlassian Confluence, which allows remote, unauthenticated actors unfettered access to Confluence data.

A critical Atlassian Confluence vulnerability that was disclosed last week is now being actively exploited in the wild, researchers are warning.

According to researchers at Rapid7, the bug in question (CVE-2022-26138, one of three patched last week) is due to a hardcoded password in the Questions for Confluence app, which would allow cyberattackers to gain complete access to data within the on-premises Confluence Server and Confluence Data Center platforms.

More specifically, once installed, the Questions for Confluence app will "create a user account with a hard-coded password and add the account to a user group, which allows access to all nonrestricted pages in Confluence," according to Rapid7's posting. "This easily allows a remote, unauthenticated attacker to browse an organization’s Confluence instance."

The stakes are high. Many organizations use Confluence for project management and collaboration among teams scattered across on-premises and remote locations. Often Confluence environments can house sensitive data on projects that an organization might be working on, or house it on its customers and partners.

Organizations are urged to patch quickly because the password was made public last week, prompting emergency action by Atlassian. Confluence is unfortunately a popular target for attackers, as evidenced by the active exploitation of the bug tracked as CVE-2022-26134 in June, used to spread ransomware.

Admins should note: The bug only exists when the Questions for Confluence app is enabled, and it does not impact the Confluence Cloud instance. However, crucially, “uninstalling the Questions for Confluence app does not remediate this vulnerability," according to Atlassian's advisory last week.

"Confluence has had no shortage of headlines," Rick Holland, CISO at Digital Shadows, said via email. "Hardcoded passwords significantly increase the likelihood of exploitation, especially when the passwords become widely shared. If you play soccer, hardcoded passwords are 'own goals.' Adversaries score enough goals alone; we don't need to put the ball in our own net. Never use hardcoded passwords; take the time to set up proper authentication and minimize future risks."

Source

DARKReading