In 2022, multiple high-profile vulnerabilities like Log4j and OpenSSL provided important takeaways for future public reporting.

As we pass the first anniversary of the Log4j vulnerability disclosure, it's a timely reminder that when a vulnerability is serious, it deserves our utmost attention. Organizations taking vulnerability disclosure more seriously is a net positive for the industry, especially because patching is so vital for basic cyber hygiene and accountability.

But, when a vulnerability is overblown or overpromoted, it can misguide the security community and distract from other more serious incidents — or cause other serious problems, like alert fatigue.

As public vulnerability disclosure becomes more commonplace for researchers, vendors, and the broader security community, the question of "when to panic or not panic?" is important. Here are some key lessons for approaching vulnerability management.

**1\. Distinguish Between Noise and Necessity**

For security experts and the media alike, it's imperative to determine when something is critical and when an issue might be overblown. According to research, the Log4j vulnerability Log4Shell could potentially impact 72% of organizations, and it was coined an "endemic vulnerability" by the US Cybersecurity and Infrastructure Security Agency.

Months later, the Text4Shell vulnerability was disclosed. Media and researchers alike wondered if it was "the next Log4Shell." But the vulnerability was proven to have a much lower impact and was much less severe.

This is one example of a gray area between ensuring something is well-broadcast and its actual impact. Being able to make this distinction can help prevent alert fatigue, which has been associated with security staff burnout and is costly to a company due to direct expenditures spent responding to these alerts, including initial triage.

In another case, if a vulnerability is originally thought to be more severe, it could be overblown. For example, a vulnerability in OpenSSL disclosed in December generated significant attention due to the ubiquity of OpenSSL inside many products to enable Transport Layer Security (TLS).

This one may have been overhyped because of the last significant vulnerability in the software in 2014: Heartbleed. Given this past, when it was announced that the new vulnerability's severity level was critical, people were understandably concerned.

But the hype around the latest OpenSSL vulnerability turned out to be kind of a non-event. At the time of release, the two CVEs (common vulnerabilities and exposures) were downgraded from critical to high. This hype wound up being a distraction because it actually led to a more complicated ConnectWise vulnerability being under-covered. The ConnectWise vulnerability had the potential to be more harmful and impact nearly 5,000 servers.

**2\. Communicate and Mitigate Risk**

Communicating risk will always have to be a collaborative effort because it happens in so many channels. Organizations post on their own websites and forums, the government issues bulletins, and the InfoSec community is particularly active on social media — researchers sometimes "scoop" vendors before they can release details about the vulnerability or mitigations themselves.

Often, there exists an educational gap between deeply technical security researchers and IT professionals and the broader business community. This disconnect results in organizations not knowing the right steps to take when a vulnerability is publicly disclosed.

**3\. Follow the Data**

The Common Vulnerability Scoring System provides a qualitative measure of the severity of cybersecurity vulnerabilities, and ratings can range from 0 to 10. It is one resource that can help us compare the vulnerability at hand to the rate of "noise" in the community. Leaning on data and hard numbers can help ensure we're paying attention to what really matters.

There are other risk-scoring models to help organizations prioritize vulnerabilities. To address the specific needs of cyber-insurance underwriting, Coalition offers the Coalition Exploit Scoring System (CESS) to help organizations prioritize vulnerability mitigation. CESS is powered by a set of machine learning models that assign severity scores to vulnerabilities based on multiple features — the description, social mentions, incident data, honeypot exploitation, and similarity to previous vulnerabilities — and measures the potential, or how likely it is, that attackers will actually exploit the CVE. This way, organizations can prioritize responses and resources according to their threat level.

Think of the CESS score as a percentile regarding severity and likelihood of exploitation. Our threshold of deeming an exploit "critical" is 0.7 or 70%. For example, CESS ranked the new OpenSSL vulnerability as 0.66 in our percentile scale, with a 1.0 being 100%. Our threshold for significance to notify policyholders is 0.7 or 70%. This slight 0.4 decile difference is actually really helpful in understanding the thousands of vulnerabilities that exist and helps cut through the noise of the hundreds publicized daily. Coalition uses CESS to prioritize which vulnerabilities policyholders should address first based on a two-pronged data approach: which vulnerabilities are the most severe and which are most likely to be exploited. Other security organizations will likely implement similar data-driven risk-scoring systems.

**How Vendors Fit In**

Vendors have a role to play in ensuring customers have a trusted source, whether communicating vulnerability severity scores or providing a balanced perspective with clear mitigation advice and updates. Vulnerability management is twofold, and the onus to resolve issues is just as much on the vendor side to communicate them properly as on the organization side to patch them efficiently.

All organizations have a responsibility when it comes to incident response and vulnerability management. Spending time educating on the technicality of how a vulnerability works and the potential exposure around technologies vulnerabilities often target can go a long way in seeing trouble before it starts.

Not everything is the "next Heartbleed" or "next Log4shell," but having the right resources in place can ensure we are ready for new security challenges without being distracted by the newest shiny object.

3 Lessons Learned in Vulnerability Management

Default settings can leave blind spots but avoiding this issue can be done.

When you hear "default settings" in the context of the cloud, a few things can come to mind: default admin passwords when setting up a new application, a public AWS S3 bucket, or default user access. Often, vendors and providers consider customer usability and ease more important than security, resulting in default settings. One thing needs to be clear: Just because a setting or control is default doesn't mean it's recommended or secure.

Below, we'll review some examples of defaults that can leave your organization at risk.

**Azure**

Azure SQL Databases, unlike Azure SQL Managed Instances, have a built-in firewall that can be configured to allow connectivity at the server or database level. This gives users a lot of options to ensure the right things are talking.

For applications inside Azure to connect to an Azure SQL Database, there is an "Allow Azure Services" setting on the server that sets the starting and ending IP addresses to 0.0.0.0. Called "AllowAllWindowsAzureIps," it sounds harmless, but this option configured the Azure SQL Database firewall to not only allow all connections from your Azure configuration but from _any_ Azure configurations. By using this feature, you open your database to allow connections from other customers, putting more pressure on logins and identity management.

One thing to note is whether there are any public IP addresses allowed to the Azure SQL Database. It is unusual to do so and, while you can use the default, it doesn't mean you should. You’ll want to reduce the attack surface for an SQL server — one way to do this is by defining firewall rules with granular IP addresses. Define the exact list of available addresses from both data centers and other resources.

**Amazon Web Services (AWS)**

EMR is a big-data solution from Amazon. It offers data processing, interactive analytics, and machine learning using open source frameworks. Yet Another Resource Negotiator (YARN) is a prerequisite for the Hadoop framework, which EMR uses. The concern is that YARN on EMR's main server exposes a representational state transfer API, allowing remote users to submit new apps to the cluster. Security controls in AWS are not enabled by default here.

This is a default configuration that may not be noticed because it sits at a couple of different crossroads. This issue is something we find with our own policies looking for open ports open to the Internet, but because it is a platform, customers can get confused that there is an underlying EC2 infrastructure making EMR work. Moreover, when they go to check the configuration, confusion can occur when they notice that in the configuration for EMR, they see the "block public access" setting is enabled. Even with this default setting enabled, EMR exposes port 22 and 8088, which can be used for remote code execution. If this isn't blocked by a service control policy (SCP), access control list, or on-host firewall (e.g., Linux IPTables), known scanners on the Internet are actively looking for these defaults.

**Google Cloud Platform (GCP)**

GCP embodies the idea of identity being the new perimeter of the cloud. It utilizes a powerful and granular permissions system. However, the one pervasive issue that affects people the most concerns Service Accounts. This issue resides in the CIS Benchmarks for GCP.

Because Service Accounts are used to give services in GCP the ability to make authorized API calls, the defaults in the creation are frequently misused. Service Accounts allow other Users or other Service Accounts to impersonate it. It's important to understand the deeper context of concern, which could be fully unfettered access in your environment, that could be surrounding these default settings. In other words, in the cloud, a simple misconfiguration can have a greater blast radius than what meets the eye. A cloud attack path can start at a misconfiguration, but end at your sensitive data through privilege escalations, lateral movement, and covert effective permissions.

All user-managed (but not user-created) default Service Accounts have the Editor role assigned to them to support the services in GCP they offer. The fix isn't necessarily a simple removal of the Editor role, as doing so might break functionality of the service. This is where a deep understanding of permissions becomes important because you must know exactly which permissions the Service Account is using or not using, and over time. Due to the risk that a programmatic identity is potentially more susceptible to misuse, leveraging a security platform to get at least privilege becomes vital.

While these are just a few examples within the major clouds, I hope this will inspire you to take a close look at your controls and configurations. Cloud providers aren't perfect. They are susceptible to human error, vulnerabilities, and security gaps, just like the rest of us. And while cloud service providers offer exceptionally secure infrastructure, it's always best to go the extra mile and never be complacent in your security hygiene. Often, a default setting leaves blind spots, and achieving true security takes effort and maintenance.

The Dangers of Default Cloud Configurations

About three-quarters of Java and .NET applications have vulnerabilities from the OWASP Top 10 list, while only 55% of JavaScript codebases have such flaws, according to testing data.

More than three-quarters of applications written in Java and .NET have at least one vulnerability from the OWASP Top 10, a list of software weaknesses that developers typically use as a baseline for application security.

That's according to software-testing firm Veracode, which found in an analysis of nearly 760,000 applications that about one in five applications using those two programming ecosystems had at least one high-severity or critical-severity vulnerability.

Overall, the average application had a 27% chance to have at least one vulnerability introduced every month, with poorly written apps and infrequently scanned apps likely to be more flawed, while applications with a longer history of security processes and being written by well-trained developers less likely to introduce new flaws, the data showed.

The analysis highlights the importance of integrating security into the development pipeline, says Tim Jarrett, vice president of strategic product management at Veracode.

"The data consistently shows that if you build a habit of security into your process, you have a better outcome, both in terms of fixing overall flaws, and ... you also slow the flood of stuff coming in, and that makes a big difference," he says.

Meanwhile, software companies and development teams continue to struggle to eliminate defects and vulnerabilities from application code. While developers and open source projects are fixing software flaws more quickly, the half-life of the average vulnerability continues to be measured in months, not days or weeks, according to Veracode's "State of Software Security" report, published on Jan. 11. 

For example, Java and .NET applications, which accounted for 71% of total applications analyzed by the study, saw half of flaws still impacting the applications after 243 days and 158 days, respectively.

    

Source: Veracode's "State of Software Security" report

Application bloat and age both had a significant negative impact on their security. The average application accumulated about 40% more code and is more likely to have vulnerabilities. About 54% of two-year old applications have flaws, while 69% of five-year-old applications flaws, the analysis found.

**JavaScript's Surprising Security**

Surprisingly, applications written in JavaScript or using one of the JavaScript frameworks tended to fare better in vulnerability scans. While about 80% of Java and .NET applications had a vulnerability, only 56% of JavaScript applications did. And while about 20% of Java and .NET applications had a high-severity vulnerability, less than 10% of JavaScript applications did.

JavaScript frameworks are newer, have more security, and have the benefits of an open source ecosystem, from which Java has only relatively recently benefited, Jarret says.

"JavaScript is a newer language, so applications written in it \[are\] newer, and there is a correlation we have established in previous reports between the age of the application and flaw remediation time," he says. "A lot of the tooling for JavaScript \[is\] mature and it's a well supported language."

Moreover, where a vulnerability in a Java application is a first-party problem — leaving the developer to fix the issues — in JavaScript and the Node.js framework, vulnerabilities are often a third-party issue, because the vulnerability has occurred in a component on which the software depends.

"The way that you fix a security problem in a Java application is still largely \[where\] you make a change to a class file and you compile it," he says. "Where in a JavaScript application, it\['s\] more of a package management problem. And that is a different thing for a developer to learn, which may be easier."

**New Programming Languages Languish**

The report's data also highlights the difference between the programming languages that developers are learning and those language actually used in the majority of enterprises. The top languages and ecosystems — Java, .NET, and JavaScript — seen by Veracode are not developers' choice of programming technology.

While JavaScript and JS-based frameworks — such as Node.js, React.js, and Angular — dominate the lists of developer-preferred technology, Java is one of the least liked programming languages, with 54% of respondents dreading the language, compared with 46% who loved it, according to Stack Overflow's 2022 Developer Survey. 

Yet Java dominated the share of applications scanned by Veracode clients (44%) compared with 14% for JavaScript. 

In addition, the most loved programming language, Rust, does not even show up in Veracode's data, while developers' No. 6, Python, only accounts for less than 4% of scanned applications.

Part of the reason for the disconnect is that established applications are written in established programming languages, says Veracode's Jarrett.

"You have the full universe of all the code that is out there, and then you have the kind of the foam on the crest of the wave of new development is happening, and that is where you see people picking up Go and Rust and Dart and Flutter," he says.

Because of the aggregated codebases of applications written in those languages, that situation likely will not change.

"Old applications never die, unfortunately, so there is a lot of critical mass in enterprises with these big Java codebases and .NET codebases," he says.

Java, .NET Developers Prone to More Frequent Vulnerabilities

Analyzing and learning from incidents is the ideal path to finding more insightful data and metrics, according to the VOID report.

Security teams have traditionally used _mean time to repair_ (MTTR) as a way to measure how effectively they are handling security incidents. However, variations in incident severity, team agility, and system complexity may make that security metric less useful, says Courtney Nash, lead research analyst at Verica and main author of the Open Incident Database (VOID) report.

MTTR originated in manufacturing organizations and was a measure of the average time required to repair a failed physical component or device. These devices had simpler, predictable operations with wear and tear that lent themselves to reasonably standard and consistent estimates of MTTR. Over time the use of MTTR has expanded to software systems, and software companies began using it as an indicator of system reliability and team agility or effectiveness.

Unfortunately, Nash says, its variability means that MTTR could either lead to false confidence or cause unnecessary concern.

"It's not an appropriate metric for complex software systems, in part because of the skewed distribution of duration data and because failures in such systems don't arrive uniformly over time," Nash says. "Each failure is inherently different, unlike issues with physical manufacturing devices."

**Moving Away From MTTR**

"\[MTTR\] tells us little about what an incident is really like for the organization, which can vary wildly in terms of the number of people and teams involved, the level of stress, what is needed technically and organizationally to fix it, and what the team learned as a result," Nash says.

MTTR falls victim to the oversimplification of incidents because it is calculating an average — the average time, says Nora Jones, CEO and co-founder of Jeli. Simply measuring this single average of reported times (and those reported times have also been proven to not be reliable in the first place) inhibits organizations from seeing and addressing what's going on within the infrastructure, what's contributing to that recurring incident, and how people are responding to incidents.

"Incidents come in all shapes and size — you'll see them span the complete range in severity, impact to customers, and resolution complexity all within one organization," Jones explains. "You really have to look at the people and tools together and take a qualitative approach to incident analysis."

However, Nash says moving away from MTTR isn't an overnight shift — it's not as simple as just swapping one metric for another.

"At the end of the day, it's being honest about the contributing factors, and the role that people play in coming up with solutions," she says. "It sounds simple, but it takes time, and these are the concrete activities that will build better metrics."

**Broadening the Use of Metrics**

Nash says analyzing and learning from incidents is the ideal path to finding more insightful data and metrics. A team can collect things like the number of people involved hands-on in an incident; how many unique teams were involved; which tools people used; how many chat channels there were; and if there were concurrent incidents.

As an organization gets better at conducting incident reviews and learning from them, it will start to see traction in things like the number of people attending post-incident review meetings, increased reading and sharing of post-incident reports, and using those reports in things like code reviews, training, and onboarding.

David Severski, senior security data scientist at the Cyentia Institute, says when working on the Verizon DBIR, Cyentia created and released the Vocabulary for Event Reporting and Incident Sharing to expand the types of metrics used to measure an incident.

"It defines data points we think are important to collect on security incidents," he says. "We still use this basic template in Cyentia research with some updates, for example identifying ATT&CK TTPs utilized."

The metrics for measuring an incident is not a one-size-fits-all across organization sizes and types. "Teams understand where they are today, assess where their priorities are within their current constraints, and understand their focus metrics might even evolve over time as their organization develops and scales," Jones says.

Additionally, it's about shifting focus to learnings, and then continuously improving based on those learnings, for example shifting to assessing trends and if things are trending in the right direction over time, as opposed to single-point-in-time metrics.

Why Mean Time to Repair Is Not Always A Useful Security Metric

Password manager accounts may have, ironically, been compromised via simple credential stuffing, thanks to password reuse.

Norton LifeLock customers have fallen victim to a credential-stuffing attack. Cyberattackers used a third-party list of stolen username and password combinations to attempt to break into Norton accounts, and possibly password managers, the company is warning.

Gen Digital, owner of the LifeLock brand, is sending data-breach notifications to customers, noting that it picked up on the activity on Dec. 12, when its IDS systems flagged "an unusually high number of failed logins" on Norton accounts. After a 10-day investigation, it turns out that the activity stretched back to Dec. 1, the company said.

While Gen Digital didn't say how many of the accounts were compromised, it did caution customers that the attackers were able to access names, phone numbers, and mailing addresses from any Norton accounts where they were successful.

And it added, "we cannot rule out that the unauthorized third party also obtained details stored \[in the Norton Password Manager\], especially if your Password Manager key is identical or very similar to your Norton account password." 

Those "details," of course, are the strong passwords generated for any online services the victim uses, including corporate logins, online banking, tax filing, messaging apps, e-commerce sites, and more.

**Password Reuse Subverts Password Management**

In credential-stuffing attacks, threat actors use a list of logins obtained from another source — buying cracked account info on the Dark Web, for instance — to try against new accounts, hoping that users have reused their email addresses and passwords across multiple services.

As such, the irony of the Norton incident is not lost on Roger Grimes, data-driven defense evangelist at KnowBe4.

"If I understand the reported facts, the irony is that the victimized users would have probably been protected if they had used their involved password manager to create strong passwords on their Norton logon account," he said via email. "Password managers create strong, perfectly random passwords that are essentially unguessable and uncrackable. The attack here seems to be that users self-created and used weak passwords to protect their Norton logon account that also protected their Norton password manager."

Attackers lately have focused identity and access management systems as a target, given that one compromise can unlock a veritable treasure trove of data across high-value accounts for attackers, not to mention a bevy of enterprise pivot points for moving deeper into networks.

LastPass, for instance, was targeted in August 2022 via an impersonation attack, in which cyberattackers were able to breach its development environment to make off with source code and customer data. Last month, the company suffered a follow-on attack on a cloud storage bucket that it uses.

And last March, Okta revealed that cyberattackers had used a third-party customer support engineer's system to gain access to an Okta back-end administrative panel for managing customers — among other things. About 366 customers were impacted, with two actual data breaches occurring.

Norton LifeLock Warns on Password Manager Account Compromises

The bargain T95 Android TV device was delivered with preinstalled malware, adding to a trend of Droid devices coming out-of-the-box tainted.

At $39.99 with a $3 coupon option for Amazon Prime members, the T95 Android 10.0 TV box might seem like a good value. But when an unsuspecting but cybersecurity-savvy customer ordered one up, he said it came "festooned" with malware — no extra charge.

Daniel Milisic warned consumers in Reddit and GitHub posts that he just happened to have bought the box to run Pi-hole tracker blocking — and that he immediately made a startling discovery. His first clue something was funky with the device's security was that it was signed with Android 10 test keys.

"If test keys weren't enough of a bad omen, I also found ADB wide open over the Ethernet port — right out of the box," Milisic added.

Then he let Pi-hole go to work.

"After running the Pi-hole install I set the box's DNS1 and DNS2 to 127.0.0.1 and got a hell of a surprise,” Milisic wrote. “The box was reaching out to many known, active malware addresses.”

Milisic explained he discovered traffic-monitoring malware, and an additional type of malware he said operates similarly to Android mobile malware CopyCat, but he wasn't able to identify it as a known variant. 

To boot, the malicious code is unremovable: Ultimately, Milisic was unable to strip the malware from the device, so it's currently unplugged, he said.

**Preinstalled Malware Isn't New**

Hardware being sold with preinstalled and often unremovable malware is an ongoing issue for consumers. Researchers at Check Point, for instance, warned consumers back in 2017 that a telecom company was distributing more than 36 different Android devices preloaded with adware.

In 2018 Chinese PC maker Lenovo was ordered to pay millions in a class-action lawsuit over its laptops coming with preinstalled adware, in the well-publicized "Superfish" incident. More recently, in April 2022, security researchers with ESET reported they had found and disclosed firmware-level vulnerabilities in millions of Lenovo consumer laptops that could allow attackers to escalate device privileges and drop malware undetected.

And in July 2020, researchers at Malwarebytes raised the alarm that government-funded Android phones for low-income households came out of the box with preinstalled Chinese malware that was deemed incapable of being removed.

The trend indicates that security teams and end users alike should source their devices using a bit of extra caution, from phones to laptops to TV boxes and more. 

"The main take-away here: Don't trust cheap Android boxes on AliExpress or Amazon that have firmware signed with test keys," Milisic warned. "They are stealing your data and (unless you can watch DNS logs) do so without a trace!"

Malware Comes Standard With This Android TV Box on Amazon

Rhadamanthys spreads through Google Ads that redirect to bogus download sites for popular workforce software — as well as through more typical malicious emails.

A sneaky new info stealer is sliding onto user machines via website redirects from Google Ads that pose as download sites for popular remote-workforce software, such as Zoom and AnyDesk.

Threat actors behind the new malware strain, "Rhadamanthys Stealer" — available for purchase on the Dark Web under a malware-as-a-service model — are using two delivery methods to propagate their payload, researchers from Cyble revealed in a blog post published Jan. 12.

One is through carefully crafted phishing sites that impersonate download sites not only for Zoom but also AnyDesk, Notepad++, and Bluestacks. The other is through more typical phishing emails that deliver the malware as a malicious attachment, the researchers said.

Both delivery methods pose a threat to the enterprise, as phishing combined with human gullibility on the part of unsuspecting corporate workers continues to be a successful way for threat actors "to gain unauthorized access to corporate networks, which has become a serious concern," they said.

Indeed, an annual survey by Verizon on data breaches found that in 2021, about 82% of all breaches involved social engineering in some form, with threat actors preferring to phish their targets via email more than 60% of the time.

**"Highly Convincing" Scam**

Researchers detected a number of phishing domains that the threat actors created to spread Rhadamanthys, most of which appear to be legitimate installer links for the various aforementioned software brands. Some of the malicious links they identified include: _bluestacks-install\[.\]com, zoomus-install\[.\]com, install-zoom\[.\]com, install-anydesk\[.\]com, and zoom-meetings-install\[.\]com_.

"The threat actors behind this campaign … created a highly convincing phishing webpage impersonating legitimate websites to trick users into downloading the stealer malware, which carries out malicious activities," they wrote.

If users take the bait, the websites will download an installer file disguised as a legitimate installer to download the respective applications, silently installing the stealer in the background without the user knowing, the researchers said.

In the more traditional email aspect of the campaign, attackers use spam that leverage the typical social engineering tool of portraying an urgency to respond to a message with a financial theme. The emails purport to be sending account statements to recipients with a Statement.pdf attached that they are advised to click on so they can reply with an "immediate response."

If someone clicks on the attachment, it displays a message indicating that it's an "Adobe Acrobat DC Updater" and includes a download link labelled "Download Update." That link, once clicked on, downloads a malware executable for the stealer from the URL _"https\[:\]\\\\zolotayavitrina\[.\]com/Jan-statement\[.\]exe"_ into the victim machine's Downloads folder, the researchers said.

Once this file is executed, the stealer is deployed to lift sensitive data such as browser history and various account log-in credentials — including specific technology to target crypto-wallet — from the target's computer, they said.

**The Rhadamanthys Payload**

Rhadamanthys acts more or less like a typical info stealer; however, it does have some unique features that researchers identified as they observed its execution on a victim's machine.

Though its initial installation files are in obfuscated Python code, the eventual payload is decoded as a shellcode in the form of a 32-bit executable file compiled with Microsoft visual C/C++ compiler, the researchers found.

The shellcode's first order of business is to create a mutex object aimed at ensuring that only one copy of the malware is running on the victim's system at any given time. It also checks to see if it's running on a virtual machine, ostensibly to prevent the stealer from being detected and analyzed in a virtual environment, the researchers said.

"If the malware detects that it is running in a controlled environment, it will terminate its execution," they wrote. "Otherwise, it will continue and perform the stealer activity as intended."

That activity includes collecting system information — such as computer name, username, OS version, and other machine details — by executing a series of Windows Management Instrumentation (WMI) queries. That's followed up by a query of the directories of the installed browsers — including Brave, Edge, Chrome, Firefox, Opera Software, and others — on the victim’s machine to search for and steal browser history, bookmarks, cookies, auto-fills, and login credentials.

The stealer also has a specific mandate to target various crypto wallets, with specific targets such as Armory, Binance, Bitcoin, ByteCoin, WalletWasabi, Zap, and others. It also steals data from various crypto-wallet browser extensions, which are hardcoded in the stealer binary, the researchers said.

Other applications targeted by Rhadamanthys are: FTP clients, email clients, file managers, password managers, VPN services, and messaging apps. The stealer also captures screenshots of the victim’s machine. The malware eventually sends all the stolen data to the attackers' command-and-control (C2) server, the researchers said.

**Dangers to the Enterprise**

Since the pandemic, the corporate workforce has become overall more geographically dispersed, posing unique security challenges. Software tools that make it easier for remote workers to collaborate — like Zoom and AnyDesk — have become popular targets not only for app-specific threats, but also for social engineering campaigns by attackers that want to capitalize on these challenges.

And while most corporate workers by now should know better, phishing remains a highly successful way for attackers to gain a foothold in an enterprise network, the researchers said. Because of this, Cybel researchers recommend that all enterprises use security products to detect phishing emails and websites across their network. These should also be extended to mobile devices accessing corporate networks, they said.

Enterprises should educate employees on the dangers of opening email attachments from untrusted sources, as well as downloading pirated software from the Internet, the researchers said. They should also reinforce the importance of using strong passwords and enforce multifactor authentication wherever possible.  

Finally, Cyble researchers advised that as a general rule of thumb, enterprises should block URLs — such as Torrent/Warez sites — that can be used to spread malware.

Sneaky New Stealer Woos Corporate Workers Through Fake Zoom Downloads

High-profile software provider compromises in the past few months show that threat actors are actively targeting the services underpinning corporate infrastructure. Here's what to do about it.

In early January, development-pipeline service provider CircleCI warned users of a security breach, urging companies to immediately change the passwords, SSH keys, and other secrets stored on or managed by the platform.

The attack on the DevOps service left the company scrambling to determine the scope of the breach, limit attackers' ability to modify software projects, and determine which development secrets had been compromised. In the intervening days, the company rotated authentication tokens, changed configuration variables, worked with other providers to expire keys, and continued investigating the incident.

"At this point, we are confident that there are no unauthorized actors active in our systems; however, out of an abundance of caution, we want to ensure that all customers take certain preventative measures to protect your data as well," the company stated in an advisory last week.

The CircleCI compromise is the latest incident that underscores attackers' increasing focus on fundamental enterprise services. Identity services, such as Okta and LastPass, have disclosed compromises of their systems in the past year, while developer-focused services, such as Slack and GitHub, hastened to respond to successful attacks on their source code and infrastructure as well.

The glut of attacks on core enterprise tools highlights the fact that companies should expect these types of providers to become regular targets in the future, says Lori MacVittie, a distinguished engineer and evangelist at cloud security firm F5.

"As we rely more on services and software to automate everything from the development build to testing to deployment, these services become an attractive attack surface," she says. "We don't think of them as applications that attackers will focus on, but they are."

**Identity & Developer Services Under Cyberattack**

Attackers lately have focused on two major categories of services: identity and access management systems, and developer and application infrastructure. Both types of services underpin critical aspects of enterprise infrastructure.

Identity is the glue that connects every part of an organization as well as connecting that organization to partners and customers, says Ben Smith, field CTO at NetWitness, a detection and response firm.

"It doesn't matter what product, what platform, you are leveraging ... adversaries have recognized that the only thing better than an organization that specializes in authentication is an organization that specializes on authentication for other customers," he says.

Developer services and tools, meanwhile, have become another oft-attacked enterprise service. In September, a threat actor gained access to the Slack channel for the developers at Rockstar Games, for instance, downloading videos, screenshots, and code from the upcoming Grand Theft Auto 6 game. And on Jan. 9, Slack said that it discovered that "a limited number of Slack employee tokens were stolen and misused to gain access to our externally hosted GitHub repository."

Because identity and developer services often give access to a wide variety of corporate assets — from application services to operations to source code — compromising those services can be a skeleton key to the rest of the company, NetWitness's Smith says.

"They are very very attractive targets, which represent low-hanging fruit," he says. "These are classic supply chain attacks — a plumbing attack, because the plumbing is not something that is visible on a daily basis."

**For Cyberdefense, Manage Secrets Wisely & Establish Playbooks**

Organizations should prepare for the worst and recognize that there are no simple ways to prevent the impact of such wide-ranging, impactful events, says Ben Lincoln, managing senior consultant at Bishop Fox.

"There are ways to protect against this, but they do have some overhead," he says. "So I can see developers being reluctant to implement them until it becomes evident that they are necessary."

Among the defensive tactics, Lincoln recommends the comprehensive management of secrets. Companies should be able to "push a button" and rotate all necessary password, keys, and sensitive configuration files, he says.

"You need to limit exposure, but if there is a breach, you hopefully have a push button to rotate all those credentials immediately," he says. "Companies should plan extensively in advance and have a process ready to go if the worst thing happens."

Organizations can also set traps for attackers. A variety of honeypot-like strategies allow security teams to have a high-fidelity warning that attackers may be in their network or on a service. Creating fake accounts and credentials, so-called credential canaries, can help detect when threat actors have access to sensitive assets.

In all other ways, however, companies need to apply zero-trust principles to reduce their attack surface area of — not just machines, software, and services — but also operations, MacVittie says.

"Traditionally, operations was hidden and safe behind a big moat \[in the enterprise\], so companies did not pay as much mind to them," she says. "The way that applications and digital services are constructed today, operations involve a lot of app-to-app, machine-to-app identities, and attackers have started to realize that those identities are as valuable."

CircleCI, LastPass, Okta, and Slack: Cyberattackers Pivot to Target Core Enterprise Tools

With the $7.2M contract, Cloudflare will enhance resilience and simplify security for .gov domain users.

**San Francisco, CA, January 13, 2023** **–** Cloudflare, Inc. (NYSE: NET), the security, performance, and reliability company helping to build a better Internet, has been awarded a $7.2 million contract from the Cybersecurity and Infrastructure Security Agency (CISA) to provide Registry and Authoritative DNS services to the .gov TLD (Top Level Domain).

"The Internet has made the United States government more accessible for constituents than ever before, whether they're applying for a passport, learning health and safety recommendations for their communities, or reaching out to a representative," said Matthew Prince, co-founder & CEO of Cloudflare. "Having a reliable and secure DNS for government agencies is critical to instill trust in all .gov activity, and working with us to achieve this is a testament to the reliability and security of the Cloudflare network."

CISA is the nation’s risk advisor, working with partners to defend against today’s threats and collaborating to build more secure and resilient infrastructure for the future. CISA builds the nation’s capacity to defend against cyber attacks by providing cybersecurity tools, incident response capabilities, and assessment services to safeguard the Federal IT enterprise, state and local partners, and systems that support national critical functions.

DNS is a core Internet service that is foundational to the security of the applications that sit on top of it. CISA turned to Cloudflare to provide registry and DNS services to meet the need for highly available DNS services that enhance resilience and simplify security operations for .gov domain users. CISA makes .gov domains available at no cost to US-based government organizations, but it takes more than registering a domain to put it on the Internet. DNS services guide visitors to the site. The .gov TLD registry and DNS services are available to all bona fide U.S.-based government organizations.

With this contract, Cloudflare will provide managed name servers for the .gov zone and authoritative DNS hosting for .gov domain names. Cloudflare will support CISA’s goals:

*   Reducing the attack surface of .gov-related infrastructure and government organizations
*   Automating sensitive portions of DNS security management, setting DNS records that make it hard to successfully impersonate the government in email by default, and offering new features
*   Gaining visibility to better detect and prevent certain DNS ecosystem issues instead of reacting to them

Cloudflare recently achieved FedRAMP moderate authorization and is available on the FedRAMP marketplace. Cloudflare provides security, performance, and reliability services through its global network to over 40 United States Federal Government agencies. In 2021, CISA began utilizing Cloudflare to deliver a protective DNS resolver solution for all Federal Civilian Executive Branch (FCEB) agencies. Cloudflare is committed to supporting critical government functions, including the nation's election infrastructure. Through its Athenian Project, Cloudflare provides services for free to state, county, and local officials administering elections.

For more information, visit:

*   Cloudflare for Public Sector

**About Cloudflare** Cloudflare, Inc. (www.cloudflare.com / @cloudflare) is on a mission to help build a better Internet. Cloudflare’s suite of products protect and accelerate any Internet application online without adding hardware, installing software, or changing a line of code. Internet properties powered by Cloudflare have all web traffic routed through its intelligent global network, which gets smarter with every request. As a result, they see significant improvement in performance and a decrease in spam and other attacks. Cloudflare was awarded by Reuters Events for Global Responsible Business in 2020, named to Fast Company's Most Innovative Companies in 2021, and ranked among Newsweek's Top 100 Most Loved Workplaces in 2022.

**Forward-Looking Statements** This press release contains forward-looking statements within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934, as amended, which statements involve substantial risks and uncertainties. In some cases, you can identify forward-looking statements because they contain words such as “may,” “will,” “should,” “expect,” “explore,” “plan,” “anticipate,” “could,” “intend,” “target,” “project,” “contemplate,” “believe,” “estimate,” “predict,” “potential,” or “continue,” or the negative of these words, or other similar terms or expressions that concern Cloudflare’s expectations, strategy, plans, or intentions. However, not all forward-looking statements contain these identifying words. Forward-looking statements expressed or implied in this press release include, but are not limited to, statements regarding the capabilities and effectiveness of Cloudflare’s Registry and Authoritative DNS solutions and its other products and technology, the benefits to the U.S. government and Cloudflare’s other customers from using Cloudflare’s Registry and Authoritative DNS solutions and its other products and technology, the expected functionality and performance of Cloudflare’s Registry and Authoritative DNS solutions and its other products and technology, the benefits to Cloudflare from achieving FedRAMP moderate authorization, Cloudflare’s technological development, future operations, growth, initiatives, or strategies, and comments made by Cloudflare’s CEO and others. Cloudflare’s actual results could differ materially from those stated or implied in forward-looking statements due to a number of factors, including but not limited to, risks detailed in its filings with the Securities and Exchange Commission (SEC), including Cloudflare’s Quarterly Report on Form 10-Q filed on November 3, 2022, as well as other filings that we may make from time to time with the SEC.

The forward-looking statements made in this press release relate only to events as of the date on which the statements are made. We undertake no obligation to update any forward-looking statements made in this press release to reflect events or circumstances after the date of this press release or to reflect new information or the occurrence of unanticipated events, except as required by law. We may not actually achieve the plans, intentions, or expectations disclosed in Cloudflare’s forward-looking statements, and you should not place undue reliance on Cloudflare’s forward-looking statements.

Cloudflare Wins CISA Contract for Registry and Authoritative Domain Name System (DNS) Services

Establish clear and consistent processes and standards to scale lite threat modeling's streamlined approach across your organization.

New development happens all the time at busy software companies. But is secure development happening as well?

A process called lite threat modeling (LTM) involves stakeholders in secure development, ensuring that security is baked in and not bolted on. What is LTM, and how does it differ from traditional threat modeling?

**The Lite Threat Modeling Approach**

LTM is a streamlined approach to identify, assess, and mitigate potential security threats and vulnerabilities in a system or application. It's a simplified version of traditional threat modeling, which typically involves a more comprehensive and detailed analysis of security risks.

With LTM, we're not manually sticking pins into the system or app to see if it breaks, as we would with pen testing. Rather, we poke "theoretical holes" in the application, uncovering possible attack avenues and vulnerabilities.

Here are some questions to consider asking:

*   Who would want to attack our systems?
*   What components of the system can be attacked, and how?
*   What's the worst thing that could happen if someone broke in?
*   What negative impact would this have on our company? On our customers?

**When Are LTMs performed? **

It's best to perform an LTM whenever a new feature is released, a security control is changed, or any changes are made to existing system architecture or infrastructure.

Ideally, LTMs are performed _after_ the design phase and _before_ implementation. After all, it's much, much easier to fix a vulnerability before it gets released into production. To scale LTMs across your organization, be sure to establish clear and consistent processes and standards. This can involve defining a common set of threat categories, identifying common sources of threats and vulnerabilities, and developing standard procedures for assessing and mitigating risks.

**How to Perform LTMs at Your Organization **

To start performing LTMs within your own organization, first have your internal security teams lead your LTM conversations. As your engineering teams get more familiar with the process, they can begin performing their own threat models.

To scale LTMs across your organization, be sure to establish clear and consistent processes and standards. This can involve defining a common set of threat categories, identifying common sources of threats and vulnerabilities, and developing standard procedures for assessing and mitigating risks.

**Common LTM Mistakes to Avoid**

Security people are great at threat modeling: They often expect the worst and are imaginative enough to think up edge cases. But these qualities also lead them to fall into LTM traps, such as:

*   **Focusing too much on outliers.** This occurs during an LTM exercise when the focus of the conversation veers away from the most realistic threats to its outliers. To solve this, be sure to thoroughly understand your ecosystem. Use information from your security information and event management (SIEM) and other security monitoring systems. If you have, say, 10,000 attacks hitting your application programming interface (API) endpoints, for example, you know that's what your adversaries are focused on. This is what your LTM should be focused on as well.
*   **Getting too technical.** Often, once a theoretical vulnerability has been discovered, technical people jump into "problem-solving mode." They end up "solving" the problem and talking about technical implementation instead of talking about the impact that vulnerability has on the organization. If you find this is happening during your LTM exercises, try to pull the conversation back: Tell the team that you're not going to talk about implementation yet. Talk through the _risk and impact_ first.
*   **Assuming tools alone handle risks.** Frequently, developers expect their tools to find all the problems. After all, the reality is that a threat model isn't meant to find a specific vulnerability. Rather, it's meant to look at the overall risk of the system, at the architectural level. In fact, insecure design was one of OWASP's most recent Top 10 Web Application Security Risks. You need threat models at the architectural level because architectural security issues are the most difficult to fix.
*   **Overlooking potential threats and vulnerabilities.** Threat modeling isn't a one-time exercise. It is important to regularly reassess potential threats and vulnerabilities to stay ahead of ever-changing attack vectors and threat actors.
*   **Not reviewing high-level implementation strategies.** Once potential threats and vulnerabilities have been identified, it's important to implement effective countermeasures to mitigate or eliminate them. This may include implementing technical controls, such as input validation, access control or encryption, as well as nontechnical controls, such as employee training or administrative policies.

**Conclusion**

LTM is a streamlined approach for identifying, assessing, and mitigating potential security threats and vulnerabilities. It is extremely developer-friendly and it gets secure code moving by doing threat modeling early in the software development life cycle (SDLC). Better still, an LTM can be done by software developers and architects themselves, as opposed to relying on labs to run threat modeling.

By developing and implementing LTMs in a consistent and effective manner, organizations can quickly and effectively identify and address the most critical security risks, while avoiding common pitfalls and mistakes.

Source

DARKReading