New research shows that 57 vulnerabilities that threat actors are currently using in ransomware attacks enable everything from initial access to data theft.

Many vulnerabilities that ransomware operators used in 2022 attacks were years old and paved the way for the attackers to establish persistence and move laterally in order to execute their missions.

The vulnerabilities, in products from Microsoft, Oracle, VMware, F5, SonicWall, and several other vendors, present a clear and present danger to organizations that haven't remediated them yet, a new report from Ivanti revealed this week.

**Old Vulns Still Popular**

Ivanti's report is based on an analysis of data from its own threat intelligence team and from those at Securin, Cyber Security Works, and Cyware. It offers an in-depth look at vulnerabilities that bad actors commonly exploited in ransomware attacks in 2022.

Ivanti's analysis showed that ransomware operators exploited a total of 344 unique vulnerabilities in attacks last year—an increase of 56 compared to 2021. Of this, a startling 76% of the flaws were from 2019 or before. The oldest vulnerabilities in the set were in fact three remote code execution (RCE) bugs from 2012 in Oracle's products: CVE-2012-1710 in Oracle Fusion middleware and CVE-2012-1723 and CVE-2012-4681 in the Java Runtime Environment.

Srinivas Mukkamala, Ivanti’s chief product officer, says that while the data shows ransomware operators weaponized new vulnerabilities faster than ever last year, many continued to rely on old vulnerabilities that remain unpatched on enterprise systems. 

"Older flaws being exploited is a by-product of the complexity and time-consuming nature of patches," Mukkamala says. "This is why organizations need to take a risk-based vulnerability management approach to prioritize patches so that they can remediate vulnerabilities that pose the most risk to their organization."

**The Biggest Threats**

Among the vulnerabilities that Ivanti identified as presenting the greatest danger were 57 that the company described as offering threat actors capabilities for executing their entire mission. These were vulnerabilities that allow an attacker to gain initial access, achieve persistence, escalate privileges, evade defenses, access credentials, discover assets they might be looking for, move laterally, collect data, and execute the final mission.

The three Oracle bugs from 2012 were among 25 vulnerabilities in this category that were from 2019 or older. Exploits against three of them (CVE-2017-18362, CVE-2017-6884, and CVE-2020-36195) in products from ConnectWise, Zyxel, and QNAP, respectively, are not currently being detected by scanners, Ivanti said.

A plurality (11) of the vulnerabilities in the list that offered a complete exploit chain stemmed from improper input validation. Other common causes for vulnerabilities included path traversal issues, OS command injection, out-of-bounds write errors, and SQL injection. 

**Widely Prevalent Flaws Are Most Popular**

Ransomware actors also tended to prefer flaws that exist across multiple products. One of the most popular among them was CVE-2018-3639, a type of speculative side-channel vulnerability that Intel disclosed in 2018. The vulnerability exists in 345 products from 26 vendors, Mukkamala says. Other examples include CVE-2021-4428, the infamous Log4Shell flaw, which at least six ransomware groups are currently exploiting. The flaw is among those that Ivanti found trending among threat actors as recently as December 2022. It exists in at least 176 products from 21 vendors including Oracle, Red Hat, Apache, Novell, and Amazon.

Two other vulnerabilities ransomware operators favored because of their widespread prevalence are CVE-2018-5391 in the Linux kernel and CVE-2020-1472, a critical elevation of privilege flaw in Microsoft Netlogon. At least nine ransomware gangs including those behind Babuk, CryptoMix, Conti, DarkSide, and Ryuk, have used the flaw, and it continues to trend in popularity among others as well, Ivanti said.

In total, the security found that some 118 vulnerabilities that were used in ransomware attacks last year were flaws that existed across multiple products.

"Threat actors are very interested in flaws that are present in most products," Mukkamala says.

**None on the CISA List**

Notably, 131 of the 344 flaws that ransomware attackers exploited last year are not included in the US Cybersecurity and Infrastructure Security Agency's closely followed Known Exploited Vulnerabilities (KEV) database. The database lists software flaws that threat actors are actively exploiting and which CISA assesses as being especially risky. CISA requires federal agencies to address vulnerabilities listed in the database on a priority basis and usually within two weeks or so.

"It's significant that these aren't in CISA's KEV because many organizations use the KEV to prioritize patches," Mukkamala says. That shows that while KEV is a solid resource, it doesn't provide a full view of all the vulnerabilities being used in ransomware attacks, he says.

Ivanti found that 57 vulnerabilities used in ransomware attacks last year by groups such as LockBit, Conti, and BlackCat, had low- and medium-severity scores in the national vulnerability database. The danger: this could lull organizations who use the score to prioritize patching into a false sense of security, the security vendor said.

Majority of Ransomware Attacks Last Year Exploited Old Bugs

A growing group of OWASP members and board leaders are calling for the AppSec group to make big changes to stay apace with modern development.

As the OWASP Foundation navigates its third decade of existence, many application security experts and OWASP volunteer contributors say it's time for the organization to make some big changes to stay relevant. This week, a group of over 60 high-profile OWASP members sent an open letter to the OWASP Board of Directors and to the foundation's executive director demanding significant changes to the foundation. Many of these co-signers were leaders of flagship OWASP projects, lifetime contributors, and former OWASP board members.

"OWASP simply isn't driving innovation anymore," says Contrast Security co-founder and CTO Jeff Williams, author of the first OWASP Top Ten, the OWASP chair from 2001 through 2011, and one of the co-signers. "Open source has changed, and OWASP needs to keep up by supporting contributors better."

Among the signatories were also two current board members, Glenn ten Cate and Mark Curphey. While Curphey says the letter is the result of mutual collaboration within the group, it also aligns very closely with a manifesto he published last year as a part of his successful bid for a seat on the 2023 board. As the founder of OWASP, Curphey hadn't been directly involved with the organization for some time, but had always been a supporter and advocate for OWASP while he was busy being a security practitioner, security product leader, and entrepreneur in the application security space.

Curphey focused on the following three major points during his campaign for the board:

*   to change the funding model of OWASP to look more like how Linux Foundation and its Open Software Security Foundation works with donors to support their project,
*   to install a chief product officer to lead the charge to clean up projects (and prioritize the high-impact ones) as well as renovate the OWASP site to make it more developer friendly, and
*   to change the culture of OWASP to eliminate red tape and to add more transparency in how vendors are (or are not) involved in the OWASP mission.

The open letter echoes many of these points, while calling for a change in governance that could fuel a drastic effort in fundraising that they feel could pull in millions of dollars to hire dedicated developers and project leaders.

**OWASP Then and Now**

When OWASP was founded way back in 2001, it was a scrappy labor of love founded by application security advocates who were concerned about the mounting risk to the Internet posed by insecure Web applications. They wanted to boost awareness of the problem outside the bubble of cybersecurity insiders. And so OWASP was born to help deliver education and resources to not just security professionals, but also developers and enterprise stakeholders.

The idea was to give organizations technical guidance that could enable developers to improve their coding practices and reduce the risk of vulnerabilities in the software they deployed. This was the genesis of the OWASP Top 10, the group's vaunted list of the 10 riskiest flaws in applications that was first published in 2003 and which has since spawned numerous updates and sub-lists, and which has fueled a whole host of security open source projects, commercial products, and services.

Lots of things have changed since those early years. The awareness piece of OWASP has certainly hit its mark, and today the group has grown to support over 240 chapters and tens of thousands of members and participants around the world. It hosts a full slate of local and global events, and a number of projects like the Top 10, the Software Assurance Maturity Model (SAMM), and Zed Attack Proxy (ZAP).

However, the scope of application security work to be done has broadened considerably as the world has moved way beyond Web applications and is now awash with mobile apps, IoT and embedded systems, wearables, and everything in between — all of which is driven by software.

And the development environment has radically changed, too. Modern development practices have coopted methods like continuous integration/continuous delivery (CI/CD), DevOps, and Agile development to take over from traditional waterfall development patterns. Developers lean heavily on microservices architectures and mix-and-match open source components to build out their software.

Unfortunately, in the face of all that change, some things have also stayed the same. Many of the issues on that first OWASP Top 10 are just as problematic today and still on the list, including injection flaws, misconfigurations, and authentication failures. Now, though, these nagging problems that have never gone away are only exacerbated by the expanded scope, the speed of development, and the tangle of software supply chain dependencies that have been added to the mix over the years.

**Clamoring for Change**

In the context of these factors, many OWASP insiders argue that the nonprofit has not kept up with the pace of change within the software development world. They say the foundation isn't supporting the needs of the OWASP community, especially in regard to the foundation's flagship projects, which includes over a dozen projects among OWASP's 274 other projects.

"What worked in the past simply isn’t working now and OWASP needs to change. Year after year, concerns have been raised and there have been promises of change, but year after year it hasn't happened," said the open letter to the OWASP Board of Directors and to the foundation's executive director. "The gap between what our projects and the community around them want, and the support that OWASP provides, continues to grow wider."

With the publication of this latest missive, the letter's cosigners say that some of OWASP's most impactful projects — ones that are relied upon by many enterprises and by products enterprises use today — are left to "operate independently, in some cases managing their own sponsorships, finance, websites, domains, communication platforms, and developer tools."

The signatories are clamoring for some drastic changes in funding models and governance to get the group back to serving the needs of developers in the context of modern software delivery models. They developed an action list consists of five major points, calling the foundation and board to:

1.  develop a community plan that prioritizes key initiatives, pointing to the OSSF plan as a reference
2.  change the foundation's governance structure to "better reflect the need of the entire security community"
3.  establish an aggressive funding campaign to raise $5 million to $10 million to pay for dedicated developers, community managers, and support staff
4.  improve centralized infrastructure and services for the community to take the heat off the projects
5.  take a more centralized hand in managing the product portfolio and what goes on in local chapters

Williams says he signed because he felt that the changes the group called for are "unfortunately necessary."

"OWASP has a glaring hole in not having a financial plan built from the bottom up based on project needs," he says. "Without that, it's impossible to fundraise effectively. Writing down an aggressive funding plan, going after some big funding increments, and taking on more aggressive projects is the only way to keep OWASP moving quickly."

**Next-Step Realities**

The question is whether the foundation and the OWASP community is willing and able to make some of these changes. According to Chenxi Wang, a former OWASP board member, there are many items in the proposal that are "much needed" since she believes OWASP has devolved into an organization that doesn't do much more than run events.

"But some of the other items seem to be too ambitious for OWASP, which has a volunteer board and a small operating staff. For example, the item to 'actively manage the project portfolio and chapters' would require a substantial effort going forward, which may not be something the foundation can do with today's resources," she says. "Also, the proposal about funding prioritized projects would require a change to today's model and may disenfranchise newer projects."

As she sees it, the proposal is going to require drastic changes to the funding model, the community model, and the way funds are distributed.

"To do all of this in one swoop is going to be too disruptive," Wang says. "A phased approach is the only way to make this happen."

For his part, OWASP Foundation executive director Andrew van der Stock says he also agrees with many of the points in the letter. The day after the letter was published, the proposals were presented at the foundation's monthly board meeting. He says the meeting went well, and he agrees that the board needs to set a prioritized plan anyway as a part of their fiduciary duty.

"Beyond the way it was presented, there's nothing in there that we disagree with," he says of the letter. "I think creating a plan within 30 days is definitely doable. My major concern is really around if we don't manage to achieve all of the five goals in a timeframe that the projects want us to achieve it in."

He also does wonder whether the board's current bylaws and the will of the OWASP community's paying members will allow for the kind of governance and funding changes the co-signers want. For example, OWASP isn't set up the way the OSSF organization is, which currently has a board that consists of members that buy their seats through corporate membership and pay significantly to retain those seats. OWASP currently has about 7,000 financial members in addition to the 80,000 people who participate in the community through events, chapter meetings, and projects. That paying membership includes individuals who pay $50 a year, lifetime members who pay $500, and corporate sponsors who pay $5,000 and up, depending on the level of support they want to give.

"I don't think our community would support that change. It's one of those things that I think is going to be a little bit unrealistic," says van der Stock, who adds that these kinds of changes would require a change in OWASP bylaws, which are already in the last stages of being overhauled to a set of "fairly standard" nonprofit bylaws in response to a discovery about a year ago that the original bylaws were invalid according to Delaware General Corporate Law. That routine procedure alone required an extensive process that included a vote by the general membership.

Nevertheless, van der Stock says that OWASP could definitely flourish if the board can find a way to pull in more funding.

"If we could get between $5 million and $10 million a year, we could get a lot done. If we could get people to work on projects full-time, these things would appear much quicker and probably with much higher quality," he says, noting that the foundation currently only has five staffers on its roster. "I think the only friction really, and the only thing that might be contested, is the governance model. I think our community would have a lot to say about that."

This is the concern from Williams as well.

"I'm worried that OWASP won't be able to respond to the letter, given the current governance structures," he says.

But according to Curphey, the board meeting was a good start to laying out the change-makers' proposal and considering next steps.

"The board meeting was positive," he says. "There's still a long way to go, but we'll see. I did have to leave early to attend another board meeting, but when I left was very pleased with progress and desire from current board to adapt and change."

**Why Should CISOs Care?**

The big question for CISOs and security practitioners is whether any of this internal jockeying at OWASP really matters to them. According to Wang, the decisions and actions the foundation makes today may not necessarily directly impact CISOs right now. But it could have a long-term ripple effect that influences the kind of technology options they'll have for helping developers in the long run.

"This could result in better support of emergent technologies, which down the line could impact the way practitioners adopt these technologies," she says.

Is OWASP at Risk of Irrelevance?

Established network security players like Check Point are responding to the shift to cloud-native applications, which have exposed more vulnerabilities in open source software supply chains.

When Check Point Software acquired Israeli startup Spectral a year ago, it joined the ranks of other network security providers acknowledging the growing threat of software supply chain attacks. Spectral helped fill a critical gap in CloudGuard, Check Point's unified threat protection and network security platform for public and hybrid clouds, with its code scanning and leakage detection tools.

Spectral offers infrastructure as code (IaC) scanning, code-tampering prevention, hardcoded secrets detection source controls, and CI/CD security and source code leakage detection tools. It provided the underpinning of Check Point's Cloud-Native Application Protection Platform (CNAPP), which is now part of CloudGuard, one of four core Check Point product lines.

**Understanding the Role of CNAPP**

CNAPP is gaining a lot of attention as developers shift to cloud-native application development to support new business applications and digital transformation initiatives. Gartner describes CNAPPs as "an integrated set of security and compliance capabilities designed to help secure and protect cloud-native applications across development and production."

Developers are increasingly relying on open source code and microservices from a widely distributed and often vast community to compose their containers and serverless functions. While the source code may come from an established ecosystem, it is common for some components to have roots from unknown or obsolete sources. CNAPP enables organizations to establish DevSecOps processes where software developers take the lead in discovering potential flaws in code before deploying application runtimes into production, says Melinda Marks, a senior analyst at Enterprise Strategy Group.

"This is important for preventing security issues before you deploy your applications to the cloud because once you deploy them, they're available for the hackers," Marks says.

**Agentless Scanning and Other New Features**

After integrating Spectral's tools into CloudGuard upon completing last year's acquisition, Check Point added some critical new capabilities to the CNAPP, rolled out this month, including permissions and entitlement management, agentless scanning, and deeper risk scoring of an organization's entire environment. Check Point officials underscored the company CNAPP push last week during its annual CPX 360 event in New York.

"We significantly enriched the platform to address many important elements of the cloud-native control environment," Check Point chief product officer Dorit Dor tells Dark Reading. Check Point also announced plans to feed all data from CloudGuard to its new Horizon Events, a unified dashboard that gathers logs from the entire Check Point ecosystem. Check Point introduced Horizon Events late last year, and an early access version is now available.

For Check Point, adding CNAPP to CloudGuard was critical. Check Point's key competitors are also on the CNAPP bandwagon. Among them, Palo Alto Networks has significantly emphasized its Prisma Cloud, which recently gained added Software Composition Analysis (SCA) and Secret Scanning capabilities. In December, Palo Alto Networks acquired supply chain security tool provider Cider Security.

**Check Point Shares CNAPP Roadmap**

Dor touted Spectral's "very strong" secret scanning capabilities. She explained that developers could plug it into their CI/CD environments and implement policies as code through open policy agents.

Dor presented the roadmap for CloudGuard, noting that Check Point is looking to implement more AI. Check Point plans to improve observability and visibility to help developers identify malicious code. Also in the pipeline, Check Point is working on allowing CloudGuard to handle the entire software bill of materials (SBOM) lifecycle, ultimately enabling and enforcing them.

Check Point is also working on enhancing how CloudGuard works with network security. "Network Security has been there for a long time; we have a very mature network security solution," Dor said. "But the challenge now is to make it speak more of the language of the developers." Check Point is addressing that by integrating network security into its AWS Security framework and offering it with the AWS network security as a service. Dor noted that Check Point recently integrated CloudGuard network security with Microsoft Azure, allowing administrators to manage their Microsoft environments.

"It's a space for continuous investment," Dor said. With a direction toward multi-cloud coverage, the goal is to enable it to "support your developers natively and to support the system administration and giving you one cloud control plane."

Check Point Boosts AppSec Focus With CNAPP Enhancements

The primary victims so far have been employees of telcos in the Middle East, who were hit with custom backdoors via the cloud, in a likely precursor to a broader attack.

A previously unknown threat actor is targeting telecommunications companies in the Middle East in what appears to be a cyber-espionage campaign similar to many that have hit telecom organizations in multiple countries in recent years.

Researchers from SentinelOne who spotted the new campaign said they're tracking it as WIP26, a designation the company uses for activity it has not been able to attribute to any specific cyberattack group.

In a report this week, they noted that they had observed WIP26 using public cloud infrastructure to deliver malware and store exfiltrated data, as well as for command-and-control (C2) purposes. The security vendor assessed that the threat actor is using the tactic — like many others do these days — to evade detection and make its activity harder to spot on compromised networks. 

"The WIP26 activity is a relevant example of threat actors continuously innovating their TTPs \[tactics, techniques and procedures\] in an attempt to stay stealthy and circumvent defenses," the company said.

**Targeted Mideast Telecom Attacks**

The attacks that SentinelOne observed usually began with WhatsApp messages directed at specific individuals within target telecom companies in the Middle East. The messages contained a link to an archive file in Dropbox that purported to contain documents on poverty-related topics pertinent to the region. But in reality, it also included a malware loader. 

Users tricked into clicking on the link ended up having two backdoors installed on their devices. SentinelOne found one of them, tracked as CMD365, using a Microsoft 365 Mail client as its C2, and the second backdoor, dubbed CMDEmber, using a Google Firebase instance for the same purpose.

The security vendor described WIP26 as using the backdoors to conduct reconnaissance, elevate privileges, deploy addition malware — and to steal the user's private browser data, information on high-value systems on the victim's network, and other data. SentinelOne assessed that a lot of the data that both backdoors have been collecting from victim systems and network suggest the attacker is prepping for a future attack. 

"The initial intrusion vector we observed involved precision targeting," SentinelOne said. "Further, the targeting of telecommunication providers in the Middle East suggests the motive behind this activity is espionage-related."

**Telecom Companies Continue to Be Favorite Espionage Targets**

WIP26 is one of many threat actors that have targeted telecom companies over the past few years. Some of the more recent examples — like a series of attacks on Australian telecom companies such as Optus, Telestra, and Dialog — were financially motivated. Security experts have pointed to those attacks as a sign of increased interest in telecom companies among cybercriminals looking to steal customer data, or to hijack mobile devices via so-called SIM swapping schemes.

More often though, cyberespionage and surveillance have been primary motivations for attacks on telecommunications providers. Security vendors have reported several campaigns where advanced persistent threat groups from countries like China, Turkey, and Iran have broken into a communication provider's network so they could spy on individuals and groups of interest to their respective governments.

One example is Operation Soft Cell, where a China-based group broke into the networks of major telecommunications companies around the world to steal call data records so they could track specific individuals. In another campaign, a threat actor tracked as Light Basin stole Mobile Subscriber Identity (IMSI) and metadata from the networks of 13 major carriers. As part of the campaign, the threat actor installed malware on the carrier networks that that allowed it to intercept calls, text messages, and call records of targeted individuals.

Novel Spy Group Targets Telecoms in 'Precision-Targeted' Cyberattacks

BEC gangs Midnight Hedgehog and Mandarin Capybara show how online marketing and translation tools are making it easy for these threat groups to scale internationally.

Business email compromise (BEC) attacks involve impersonating an executive or business partner in order to convince a corporate target to wire large sums of cash to an attacker-controlled bank account. Mounting a successful international version of this cyberattack typically requires a lot of effort and resources. Necessary steps include researching the target thoroughly enough to make phishing lures convincing and hiring native speakers to translate scams into multiple languages. But that's all changing as threat groups avail themselves of free, online tools that take some of the legwork out of the process.

A report from Abnormal Security released this week identified two BEC groups that exemplify the trend: Midnight Hedgehog and Mandarin Capybara. Both are leveraging Google Translate, which lets threat actors whip up a plausible phishing lure, in almost any language, in an instant.

Researchers in the report also warned that tools like commercial business marketing services are also making it easier than ever for less-sophisticated and less-resourced BEC threat groups to succeed. These, mostly used by sales and marketing departments to identify "leads," make it simple to track down the best targets regardless of their region. 

It's all bad news for defenders given that BEC attacks are already lucrative, racking up $2.4 billion in losses in 2021 alone, according to the FBI's Crime Report — and the number of BEC attacks continues to explode. Now, with some of the cost being driven out of performing them, volumes are only likely to go up.

**BEC Groups Scale Fast With Translation, Marketing Tools**

Abnormal Security's Crane Hassold, director of threat intelligence who wrote the report, noted that Midnight Hedgehog has been around since January 2021 and impersonates CEOs as its specialty, according to the report.

So far, the firm has observed two distinct phishing emails from the group translated into 11 different languages: Danish, Dutch, Estonian, French, German, Hungarian, Italian, Norwegian, Polish, Spanish, and Swedish. Thanks to Google Translate's effectiveness, the emails are missing the simple errors users are trained to look out for and view as suspicious.

    

Source: devee via Adobe Stock

"We've taught our users to look for spelling mistakes and grammatical errors to better identify when they may have received an attack," the report added. "When these are not present, there are fewer alarm bells to alert native speakers that something isn't right."

Requested payments from Midnight Hedgehog range anywhere from $17,000 to $45,000, the report said.

The second BEC threat group the report highlights, Mandarin Capybara, also sends emails purporting to be from company executives, but uses a twist: It contacts payroll to have direct-deposited paychecks sent to an account they control.

Abnormal Security has observed Mandarin Capybara targeting companies around the globe with phishing lures in Dutch, English, French, German, Italian, Polish, Portuguese, Spanish, and Swedish, but it also targets companies outside of Europe with phishing emails aimed at English speakers in the US and Australia, unlike Midnight Hedgehog, which the report said sticks to non-English-speaking victims in Europe.

**Lowering the Barriers to BEC Entry**

Extending campaigns across any language with translation tools and using online services to identify "leads" of their own on who to victimize with their next cyberattack makes it easier than ever to scale operations across borders for BEC cyberattackers.

"As email marketing and translation tools become more accurate, effective, and accessible, we will continue to see hackers exploiting them to scam companies with increasing success," the report explained. "Not only that, because these emails sound legitimate and rely on behavioral manipulation instead of malware-infected files, Midnight Hedgehog, Mandarin Capybara, and other similar BEC groups will be able to easily bypass legacy security systems and spam filters."

The answer to defending against the rising number and increased sophistication of BEC attacks, Hassold explains to Dark Reading, is a two-pronged approach.

"As social engineering attacks become more sophisticated and it becomes more difficult to distinguish them from legitimate emails, it becomes even more important to prevent them from reaching their destination," he tells Dark Reading. "Security awareness training certainly has a role in defending against phishing attacks, but the best way to prevent employees from falling for these attacks is simply to ensure that they never receive them in the first place."

That means implementing behavioral-based machine learning and AI tools tuned to detect anything outside "normal" behavior will be a key to stopping this new supercharged version of international BEC attacks, the report said.

Google Translate Helps BEC Groups Scam Companies in Any Language

The long-time NSA and cyber specialist says he's exiting the public sector.

The first-ever National Cyber Director for the US, Chris Inglis, has stepped down from his post, announcing that he's leaving the public sector behind after nearly 30 years working at federal agencies.

Inglis, former NSA deputy director, was unanimously confirmed in 2021 as Biden's top adviser in all things cybersecurity. The newly created role involved the coordination and implementation of national cyber policy and strategy, working closely with CISA director Jen Easterly, and facilitating national cyber incident response efforts.

He most recently worked to craft the government's National Cyber Strategy, which President Biden is expected to announce in the coming days. It reportedly goes much further than previous cybersecurity policies and executive orders, according to The Washington Post, which obtained a draft copy. 

There are two notable advancements in the draft: implementing a set of mandatory regulations, and instituting a "hack-back" policy. Regarding the latter, the EO is expected to green-light the use of the full brunt of the US cyber arsenal to either retaliate for or preempt cyber incursions by threat groups (and nation-states) against US interests and assets, including private-sector companies.

"Today I am stepping down from my role as the Nation's inaugural National Cyber Director at @ONCD. I do so with the utmost gratitude to @POTUS, @VP, and Congress for giving me the opportunity to serve in this Administration," Inglis tweeted this week. "Mr. President, thank you for placing your trust in me and for placing such a high priority on providing a safe, equitable, and resilient cyberspace for all."

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

Subscribe

Inglis Retires as National Cyber Director Ahead of Biden's Cybersecurity EO

The snow sports specialist is investigating to see what caused the operations-disrupting "cyber incident."

Burton Snowboards, a favorite brand for downhill shredders and X-Games fans everywhere, has closed down its e-commerce operations due to a "cyber incident" that occurred earlier this week.

In an online system-outage update, the Burlington-based company noted that a Feb. 14 attack continues to impact "some of our operations," and added, "we are working closely with third-party specialists to investigate the incident and determine the full nature and scope."

Other details are scant to nonexistent. But as of press time, the outdoor outfitter still wasn't able to process online orders three days after the attack — a decidedly unfortunate state of affairs heading into the core North American ski season.

It did however have recommendations for those who need some gnarly gear fast: Simply visit a Burton-purveying store, or use its new gear-rental service, which will see returnable snowboards, boots, bindings, and outerwear delivered to one's doorstep.

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

Subscribe

Not Stoked: Burton Snowboards' Online Orders Disrupted After Cyberattack

Weeks after an exploit was first announced in a popular cloud-based file transfer service, could some organizations still be vulnerable? The answer is yes.

Last week, the Cybersecurity and Infrastructure Security Agency (CISA) added three new entries to its Known Exploited Vulnerabilities catalog. Among them was CVE-2023-0669, a bug that has paved the way for exploits and follow-on ransomware attacks against hundreds of organizations in recent weeks.

The bug was discovered in GoAnywhere, a Windows-based file-sharing software from Fortra, formerly HelpSystems. According to its website, GoAnywhere is used at more than 3,000 organizations to manage documents of all kinds. According to data from Enlyft, most of those are large organizations — with at least 1,000 and, often, more than 10,000 employees — mostly based in the United States.

The bug tracked as CVE-2023-0669 allows hackers to remotely execute code in target systems, through the internet, without need for authentication. As of this writing, this vulnerability has not yet received an official CVSS rating from the National Vulnerability Database.

But we need not wonder about how dangerous it is, as hackers have already pounced. On Feb. 10 — days after Fortra released a patch — the Clop ransomware gang claimed to have exploited CVE-2023-0669 in over 130 organizations.

After three weeks and counting, it's unclear whether or not more organizations are still at risk.

**Timeline of the GoAnywhere Exploit(s)**

On Feb. 2, two abnormal commands triggered alerts in an IT environment monitored by endpoint detection and response (EDR) vendor Huntress. Both were executed on a host designated for processing transactions on the GoAnywhere platform, though the significance of this wasn't clear yet.

"At first glance, the alert itself was fairly generic," wrote Joe Slowik, threat intelligence manager for Huntress. "But further analysis revealed a more interesting set of circumstances."

An entity on this alerted network had attempted to download a file from a remote resource. Slowik and his colleagues tried to access the file themselves, but by then the port used to download it had been closed up. "We don't really know for certain why," Slowik tells Dark Reading. "It's possible that the adversary was working at a very rapid clip."

They did have the IP address of that entity, however, which traced back to Bulgaria, and was flagged as malicious by VirusTotal. The actor seemed to be from outside of the organization, and had used their first command to download and run a dynamic link library (DLL) file.

"Knowing that the DLL was also executed further raised the risk level of the incident," Slowik says, "since if it was malware that was downloaded, it is now running on the system."

There were other signs, too, that this was a compromise. But even after isolating the relevant server, a second server at the targeted organization became infected. "We were worried that we had a very persistent adversary," Slowik recalls.

The researchers still lacked a copy of the downloaded malware, but all of the evidence surrounding it seemed to accord with activity previously associated with a malware family called Truebot. "The post in the URI structure that was used mapped to earlier Truebot samples," Slowik says. "The DLL exports that were referenced in order to launch the malware, or similar to historical tripod samples, as well as some strings and code structures, all matched. Within the samples themselves, all of it aligned very nicely with what had previously been reported in 2022 for Truebot."

Truebot has been linked to a prolific Russian group called TA505. Notably, TA505 has utilized the ransomware-as-a-service (RaaS) malware "Clop" in previous attacks.

On the same day as Slowik's investigation, reporter Brian Krebs publicly republished an advisory Fortra had sent to its users the day before. GoAnywhere was being exploited, its developers explained, and they were implementing a temporary service outage in response.

Whatever mitigations were taken weren't enough. On Feb. 10, hackers behind the Clop ransomware told Bleeping Computer that they’d used the GoAnywhere exploit to breach over more than organizations.

**How CVE-2023-0669 Works**

CVE-2023-0669 is a cross-site request forgery (CSRF) but that arises from how unpatched GoAnywhere users install their software licenses.

Interestingly, it was as much a design choice as an oversight. "Typically, installing a license involves downloading a license file from a server and uploading it to your device," explains Ron Bowes, lead security researcher for Rapid7, who released the most detailed publicized analysis of how an internal user could trigger the exploit. "Fortra chose to make that whole process transparent, where the license is delivered through the administrator's browser. That means the user gets a much smoother experience."

However, that seamlessness came at a cost. "There is no CSRF protection (and the cookie is not actually required, so no authentication is required to exploit this issue)," Bowes explained in his analysis. "That means that this can, by design, be exploited via cross-site request forgery."

In its report, Rapid7 labeled the exploitability of this vulnerability as "very high."

"While the administration port should not be exposed to the internet," Bowes says, "it's very easy to configure it that way by mistake. And once an attacker understands the vulnerability, it can be exploited without any risk of crashing the application or corrupting data."

Rapid7 also labeled "very high" the value of such an exploit to an attacker. As Bowes explains, "due to the nature of the application (managed file transfer, or MFT), it's common for a GoAnywhere MFT server to sit on a network perimeter and to have the file transfer ports publicly exposed. This makes it a good target for both pivoting into an organization's internal network, and/or stealing potentially sensitive data directly off the target."

On Feb. 6, Fortra fixed CVE-2023-0669 "by adding what they call a 'license request token,'" Bowes explains, "which is included in the encrypted request to Fortra's server. It behaves exactly as a CSRF token would, preventing an attacker from leveraging an administrator's browser."

**What to Do Now**

As severe as the exploit is, only a fraction of GoAnywhere customers are vulnerable to outside hackers through CVE-2023-0669. However, even those without Internet-exposed GoAnywhere instances are still vulnerable to internal users or attackers who have gained initial compromise to a network via regular Web browsers.

The bug can be exploited remotely if an organization’s GoAnywhere administration port — 8000 or 8001 — is exposed on the Internet. As of last week, more than 1,000 GoAnywhere instances were exposed, but, Bleeping Computer explained, only 135 of those pertained to the relevant ports 8000 and 8001. Most of those vulnerable seem to have already been swept up in one big campaign by the Clop group.

"We urgently advise all GoAnywhere MFT customers to apply this patch," Fortra wrote in another advisory to its internal customers. "Particularly for customers running an admin portal exposed to the Internet, we consider this an urgent matter."

Massive GoAnywhere RCE Exploit: Everything You Need to Know

With a rearranging of priorities and good incident response plans, organizations can be ready to face the future of software attacks.

We've been hearing a lot about software supply chain attacks over the past two years, and with good reason. The cybersecurity ecosystem and industry at large have been inundated with warnings about this attack vector, with high-profile attacks leading to a stark increase in vendor solutions, as government regulations keep trying to catch up. Yet despite the popularity of AppSec-related incidents, Enso Security's research has shown that most organizations do not have an incident response plan in place specific to these attacks. Others that do have an IR playbook often prepare to respond to infrastructure-related attacks such as ransomware, rather than attacks based on application channels. Given the prevalence of these attacks, this post will focus on software supply chain incident response and will include a quick response playbook as well as trends and characteristics that make AppSec incident response deserving of its own plan.

Before we dive in, it's important to remember that incident response is a profession and involves a fair amount of resources and strategy. Designing a proper incident response plan for AppSec threats doesn't happen overnight, and each response plan is uniquely suited to a specific organization. With that being said, we hope our quick tips will be able to help organizations get a strong head start.

**A Quick, AppSec Incident Response Checklist**

Below is a basic AppSec incident response checklist for a malicious package incident, such as the ESLint attack, which, for me, was the first time I had to respond in real-time to a malicious dependency potentially running in the continuous integration (CI) pipeline.

Here is an example of a basic incident response playbook for a public popular dependency gone malicious:

**1\. Check CI logs** for the specific usage of the malicious packages.

**2\. Identify the assets** to which the malicious code gains access.

**3\. Identify all possible compromised credentials** and rotate all credentials in the relevant environments.

**4\. Identify all associated developers** who have committed the malicious package, rotate the relevant credentials, and have security or IT begin an investigation of their workstations.

**5\. Notify R&D** that there is a malicious package suspicion and relevant keys may be rotated shortly.

**6\. Audit all access** to organization assets. Identify any anomalies that indicate breached credentials usage. Continue this step beyond the initial incident response.

While these steps are being taken, the company's executive management team should consider and draft both an internal and a public response to a potential incident, and involve the required departments, such as customer success, external affairs, legal, etc.

**Why Do We Need a Dedicated AppSec Incident Response Playbook?**

**R&D as the attack surface:** As the rate of production is faster than ever, developers are the largest growing moving targets for attacks. Security must get in front of this attack vector by having the security controls in place and continuously collecting the relevant data from R&D — not just when there's an emergency. The nature of supply chain attacks requires security to have a much deeper understanding of the business, and they must be able to show leadership that they are able to manage and assess security issues based on their own data, without burdening R&D during an incident.

**Mass-casualty event:** Unlike traditional ransomware attacks that target one organization at a time, supply chain attacks are often mass-casualty events, potentially affecting thousands of organizations in one "hit." A standard incident response plan will not be suited for massive security events in which external consultations are needed. Experts will be overwhelmed and trying to assist dozens of customers in such an attack, and the organization cannot run the risk of a delayed response.

**AppSec is an immature discipline:** The importance of AppSec has only recently been acknowledged, evident by the current and expected increases in spending, market growth, and regulatory activity. Software supply chain attacks are also a relatively new phenomenon that security teams must deal with, as they were not prioritizing this kind of threat only five years ago. Today, security teams face these challenges on a daily basis. As the application attack surface continues to expand and has become globally intertwined, the available solutions and know-how are still playing catch-up.

**Attacker sophistication not (always) required:** Attackers are lucky enough to leverage the fact that there is still a concerning lack of adequate tools to defend the industry from supply chain risks, and the security tools that do exist are still quite new. Supply chain attacks are extremely lucrative and a small crime brings attackers a disproportionate amount of treasure. If an attacker succeeds, they can get access to important data from not one organization but thousands. On the defense side, organizations have little visibility into CI builds and even less visibility into developer stations, making it extremely difficult to secure this attack surface.

Despite this seemingly unbalanced match between malicious actors and AppSec teams, we shouldn't feel defeated. As these threats grow more prevalent, security teams are getting better at incident response, and vendors are building innovative tools to better serve security professionals. With a little rearranging of priorities and updating of the incident response manual to better suit threats of an AppSec nature, organizations can be ready to face the future of software attacks.

AppSec Threats Deserve Their Own Incident Response Plan

New ESXiArgs-ransomware attacks include a workaround for CISA's decryptor, researchers find.

Just a week after the Cybersecurity and Infrastructure Security Agency (CISA) released its recovery script against ransomware targeting VMWare ESXi virtual machines, a modified version of the malware is already in circulation that renders the decryptor script useless.

So far, around 3,800 servers across the globe have already fallen victim to EXSiArgs ransomware, CISA and the FBI warn.

"Where the old encryption routine skipped large chunks of data based on the size of the file, the new encryption routine only skips small (1MB) pieces and then encrypts the next 1MB," researchers at Malwarebytes said in a new report on the ESXi vulnerability. "This ensures that all files larger than 128MB are encrypted for 50%. Files under 128MB are fully encrypted which was also the case in the old variant."

Targets of ESXi-Args ransomware can tell if they are infected with the new variant if the ransom note directs the victim to contact the threat actor via the TOX encrypted messenger, the report added. The ransom note from the old ESXiArgs variant that can be mitigated by the CISA-issued decryptor includes a Bitcoin address.

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

Subscribe

Source

DARKReading