Feeling creative? Have something to say about cybersecurity? Submit your caption and our panel of experts will reward the winner with a $25 gift card.

What motivates you? What will change how you do security? Send us a cybersecurity-related caption to describe the above scene and our favorite entry will win its wordsmith a $25 gift card.

Here are four convenient ways to submit your ideas before the Feb. 12 deadline:

*   Via social media: Bluesky, LinkedIn, Facebook, and X. (If you win, we'll respond to you on the same platform, requesting your email address.)
    

**Last Month's Winner**

Shout out — and a $25 gift card — to Paul Mauriks, ICT security specialist, technology solutions, at the Department of Justice and Community Safety in Victoria, Australia for sending us the winning caption for last month's "Sneaking Around" cartoon. Some noteworthy contenders included "I guarantee you there are no backdoors to our network," "Finally found a way to get rid of all that old IT gea.," and "‘Yeah, asset disposal by ‘Back Door Inc.’ I’ll do the supplier assessment thing on Monday…’" Congrats to Paul, and a big thank you to all who participated.

**About the Author**

Cartoonist

John Klossner has been drawing technology cartoons for more than 15 years. His work regularly appears in Computerworld and Federal Computer Week. His illustrations and cartoons have also been published in The New Yorker, Barron's, and The Wall Street Journal.

Name That Toon: Incentives

The US Department of Commerce will prohibit the import of components for connected vehicles from China or Russia, as the US continues to ban technology it sees as potential national security threats.

Source: Hsyn20 via Shutterstock

Smart-vehicle makers are facing supply chain disruption as the US Department of Commerce plans to enforce new regulations banning the import of connected-vehicle technology from China and Russia over cybersecurity fears.

The Commerce Department pursued new regulations after President Biden declared a national emergency over concerns that the United States had become overreliant on China for information and communications technology and services (ICTS). The rule mandates that companies and their suppliers eliminate hardware or software imported from China or Russia in their vehicle connectivity system (VCS) or in their automated driving system (ADS).

It aims to address two concerns: vulnerabilities that would allow a nation-state or criminal organization to implant a backdoor in automotive hardware or software; and the collection of data on US drivers through diagnostic features and other mechanisms, says Yoav Levy, CEO and co-founder of automotive cybersecurity provider Upstream.

"The threat is definitely real," he says. "There are many cases where cars could be hacked — including the safety elements within the cars — and there were many cases where data was stolen or leaked. ... But so far, we haven't seen something like that on a huge scale."

Related:Leveraging Behavioral Insights to Counter LLM-Enabled Hacking

The concerns come as software-defined vehicles (SDVs) shake up the automotive market, while also potentially increasing the cyberattack surface area of automobiles. In the past, vehicle makers created a variety of platforms for their different models, and the number of processors — known as electronic control units (ECUs) — quickly climbed. While the post-pandemic chip shortage slowed the shift to new platforms, manufacturers now aim to quickly reduce the number of ECUs and other hardware needed for the VCS and ADS systems. While current models, for example, can have as many as 130 ECUs, Rivian has already reduced the number of ECUs to seven in its second generation R1 vehicles.

**Wielding the Cyber-Ban Hammer**

Rivian aside, most automobiles have a wide variety of components sourced from China, raising concerns that the United States' reliance on the technologies could allow future compromises.

Banning technology from China and sanctioning Russia is nothing new, says Ivan Novikov, CEO at API security firm Wallarm. The US government has already raised cybersecurity concerns over telecommunications equipment from Huawei, Chinese-made cargo equipment at US seaports, home routers made by Chinese manufacturer TP-Link, and popular social media app TikTok.

Related:Strategic Approaches to Threat Detection, Investigation & Response

"This is kind of the next logical step," he says.

The new commerce regulations will prohibit any "transactions involving VCS hardware and covered software designed, developed, manufactured, or supplied" by people or organizations linked to China or Russia, according to a 213-page final rule, which will be put into effect after months of comments.

Yet, many implementation details remain unclear, Novikov says.

"The open question here is who will enforce the regulations, because the usual enforcement of security requirements and crash \[safety\] tests is under the Department of Transportation," he says. "It's unclear how these two agencies can work together, and how this final DoT requirements or restrictions or controls can work."

**Securing Supply Chains & the Economy?**

The impact on the supply chain will be significant, experts say. The first tier of OEMs — large US and international companies — are not the problem. Their products, however, often come from suppliers that source their own components from Chinese companies, says Alex Oyler, director for North America at industry consultancy SBD Automotive.

It's just one more way that the supply chain is currently undergoing changes, he says. Many carmakers are looking to rewrite their relationships with providers as they move to software-defined vehicles.

Related:Trusted Apps Sneak a Bug Into the UEFI Boot Process

"We're in a bit of a different phase of software-defined vehicle in the sense that OEMs are actually starting to become a lot more prescriptive in the specification of the components that they're sourcing," Oyler says. "It's more of what's called a build-to-print relationship, where they provide not the functional requirements, but requirements for the component architecture — we want this processor, we need this memory, we need this GPU."

The shift to other sources of supply will take years, with the Biden administration allowing carmakers a grace period to comply with the regulations: Software components can no longer be sourced from China and Russia starting with 2027 car models, while by 2030 car models must contain no hardware from prohibited sources.

Making such changes will not be easy, says Upstream's Levy.

"It's not that easy to replace a supplier," he says. "There are financial implications with the supply chain — maybe it's going to be more expensive, or there may be some changes to software that they would need to do for the for the new supplier — an adjustment to the architecture. ... It really depends on what they are actually going to replace."

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

US Ban on Automotive Components Could Curb Supply Chain

A highly targeted cyber-intelligence campaign adds fuel to the increasingly complex relationship between the two former Soviet states.

Source: Daniren via Alamy Stock Photo

A suspected Russia-nexus threat actor has been executing convincing spear phishing attacks against diplomatic entities in Kazakhstan.

UAC-0063, active since at least 2021, was first documented by Ukraine's Computer Emergency Response Team (CERT-UA) in 2023. With medium confidence, CERT-UA tied it to APT28 (aka Fancy Bear, Forest Blizzard, Strontium, Sofacy), from the General Staff Main Intelligence Directorate (GRU) Military Unit 26165. APT28 is best known for its high-profile attacks against Western governments: the Democratic National Committee (DNC) hack of 2016, campaigns against parliamentary bodies in Germany, Norway, and the Netherlands, and much more.

UAC-0063, specifically, has used cyber operations to collect intelligence from government entities, nongovernmental organizations (NGOs), academic institutions, and energy and defense organizations in Eastern Europe — most notably Ukraine — as well as Central Asia, including Kazakhstan, Kyrgyzstan, Tajikistan, and other countries in the vicinity, including Israel and India.

Its latest ongoing campaign, which, in a blog post, researchers from Sekoia date back to at least 2022, may fold into a broader effort by Vladimir Putin's government to gain strategic insights into, and advantage over, a former Soviet state that has sought to broaden its diplomatic horizons in recent years.

**Phishing Kazakh Diplomats**

On Oct. 16, 2024 — one month after it'd been deployed in the wild — researchers spotted a diplomatic document uploaded to VirusTotal. It appeared to be a legitimate draft of a joint declaration between the chancellor of Germany and heads of Central Asian countries.

"The first step, when you open this document, is that it asks you to enable macros," recalls Amaury Garçon, cyber threat intelligence (CTI) analyst at Sekoia Threat Detection & Research (TDR), adding that the document was obscured by "shapes" at first sight. "Some phishing documents look really ugly or have a bad shape \[at first\] — they prompt the user to enable macros, because if you don't enable macros you can't write text in the document, can't move images, etc.," he notes.

Clicking "enable" would trigger various malicious, unseen commands on a target device. While the user was made privy to the full, unadulterated lure document, in the background their security settings would be downgraded so as to remove the need for future "enable macros" prompts. Next a second, blank document was created and opened by a hidden instance of Microsoft Word. The Visual Basic (VB) code associated with this hidden document — now enabled by default, of course — dropped and executed a malicious HTML application (HTA) containing a backdoor named "HatVibe."

The purpose of HatVibe is to receive and execute code from a remote server. Though Sekoia couldn't identify the payloads associated with this phishing campaign, CERT-UA has previously observed HatVibe downloading and executing a more complex Python backdoor named "CherrySpy."

**What This Means for Kazakhstan and Russia**

Six weeks after researchers spotted the first VirusTotal upload associated with this campaign, on Nov. 27, Putin went on a two-day state visit to the country he deemed Russia's "true ally," Kazakhstan. He and Kazakhstan's president, Kassym-Jomart Tokayev, used the opportunity afforded by the Collective Security Treaty Organization (CSTO) summit to discuss various areas for economic partnership — particularly around the energy sector — and signed agreements over energy, education, and transportation.

"Central Asia is a real point of interest for Russian influence," Maxime Arquillière, senior CTI analyst at Sekoia TDR explains. "We know that Kazakhstan is a close ally, but since the beginning of the Ukraine war, Kazakhstan has distanced itself a little bit from Russia, trying to develop new connections with both Western states and also China."

Kazakhstan's centrality in the Asian continent positions it nicely as a trade bridge between China and Europe, particularly while Ukraine and Russia are consumed by war. And as Sekoia notes in its blog, the country's gradually broadening geopolitical ties are evident in recent agreements with Mongolia and Afghanistan's new Taliban government, and, most notably, its balanced position on the war in Ukraine — supporting Ukraine's right to territorial integrity without outright condemning Russia's invasion.

This latest cyber campaign, then, fits neatly into Russia's broader initiatives with regard to its Central Asian neighbor. Sekoia identified 11 lure documents in all, each one legitimate and likely having originated with Kazakhstan's Ministry of Foreign Affairs, pertaining to diplomatic business between Kazakhstan and potential partner nations.

Exactly how the threat actor obtained these documents is not known. They include, for example:

*   Letters from Kazakhstan's embassies in Afghanistan and Belgium, regarding diplomatic and economic developments.
    
*   A draft of a joint statement between Germany and Central Asian states, following a Sept. 16, 2024, summit in Astana.
    
*   Administrative reports and briefings on the Kazakh president's visits to Mongolia and New York.
    

"It's really coherent with the \[need for\] Russian intelligence to conduct this kind of cyber espionage, to know about the strategic interests between Kazakhstan and European states," Arquillière says.

**About the Author**

Nate Nelson is a writer based in New York City. He formerly worked as a reporter at Threatpost, and wrote "Malicious Life," an award-winning Top 20 tech podcast on Apple and Spotify. Outside of Dark Reading, he also co-hosts "The Industrial Security Podcast."

Russian APT Phishes Kazakh Gov't for Strategic Intel

Seven system recovery programs contained what amounted to a backdoor for injecting any untrusted file into the system startup process.

Source: Ognyan Yosifov via Alamy Stock Photo

A vulnerability in trusted system recovery programs could allow privileged attackers to inject malware directly into the system startup process in Unified Extensible Firmware Interface (UEFI) devices.

Seven real-time recovery products — Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, WASAY eRecoveryRX, CES NeoImpact, and SignalComputer HDD King — all make use of "reloader.efi," the Microsoft-signed Extensible Firmware Interface (EFI) file at issue.

The problem, ESET explains in a new report, is that reloader.efi uses a custom loader that enables the application to load even unsigned binaries during the boot process. In essence, it's a backdoor for sneaking any kind of file into a system's startup, past UEFI Secure Boot. The issue has been assigned CVE-2024-7344, and earned a "medium" 6.5 Common Vulnerability Scoring System (CVSS) rating, as it requires administrator privileges to exploit.

**Backdoor to the UEFI Boot Process**

The standard way to load, prepare, and execute UEFI images in system memory is with the autological LoadImage and StartImage functions. The Microsoft-approved "reloader" application goes its own way, using a custom mechanism that allows it to load any binary, trusted or otherwise, at startup.

"Maybe it's a lack of secure coding awareness," Martin Smolár, malware researcher at ESET, guesses of the developers' motives in implementing the custom loader. "Or maybe it's because they found it convenient to create such a functionality. Because when a developer makes a change \[to a signed program\] they need to send it to Microsoft to get it re-signed. This means that they don't need to every time they create a new update or something like that."

Reloader.efi loads arbitrary binaries from a specific, encrypted file, "cloak.dat." When ESET decrypted cloak.dat, it found that it contained an unsigned executable primarily designed for classroom environments. "Its core function is to provide real-time system recovery, ensuring that students from different classes can work in a teacher-predefined computer environment within shared computer labs," Smolár says, though he adds that the same component might be used in other settings, like public Internet cafes. The larger point is that the unsigned executable is run during the startup process, completely bypassing UEFI Secure Boot checks.

This odd classroom recovery software is perfectly honest, but an attacker could easily swap it out for something worse. If they could just get a hold of administrator privileges on a targeted machine, an attacker could access the EFI system partition (ESP) and substitute their own malicious file in place of cloak.dat. Then all they'd need is a quick system reboot to drop any malicious file they wished into the startup process.

**Why UEFI Bugs Are So Bad**

UEFI is a kind of sacred space — a bridge between firmware and operating system, allowing a machine to boot up in the first place.

Any malware that invades this space will earn a dogged persistence through reboots, by reserving its own spot in the startup process. Security programs have a harder time detecting malware at such a low level of the system. Even more importantly, by loading first, UEFI malware will simply have a head start over those security checks that it aims to avoid. Malware authors take advantage of this order of operations by designing UEFI bootkits that can hook into security protocols, and undermine critical security mechanisms like UEFI Secure Boot or HVCI (Hypervisor-Protected Code Integrity), Windows' technology for blocking unsigned code in the kernel.

To ensure that none of this can happen, the UEFI Boot Manager verifies every boot application binary against two lists: "db," which includes all signed and trusted programs, and "dbx," including all forbidden programs. But when a vulnerable binary is signed by Microsoft, the matter is moot.

Microsoft maintains a list of requirements for signing UEFI binaries, but the process is a bit obscure, Smolár says. "I don't know if it involves only running through this list of requirements, or if there are some other activities involved, like manual binary reviews where they look for not necessarily malicious, but insecure behavior," he says.

Microsoft has previously alluded to UEFI binaries being "approved through manual review." In response to an inquiry from Dark Reading, a Microsoft spokesperson provided the following clarification:

"Our process is designed to meet the evolving standard for analysis of third-party binary code, while ensuring effective scalability across our vast ecosystem. It begins with vetting and analysis with the partner, understanding the components they are requesting to be signed, and aspects of the design and functionality that may require additional security measures. Submissions are run through automated security analysis and are manually reviewed through a rigorous process. As a result, we may require additional security reviews, investigations with the submitting partner, or other mitigations. We remain committed to evolving our vetting process to better the security of our ecosystem as we operate within this ever-changing threat landscape."

ESET first discovered CVE-2024-7344 in July 2024. Since then, all vulnerable applications have been fixed, and Microsoft revoked the old, vulnerable binaries in its Jan. 14, 2025, Patch Tuesday update.

**About the Author**

Nate Nelson is a writer based in New York City. He formerly worked as a reporter at Threatpost, and wrote "Malicious Life," an award-winning Top 20 tech podcast on Apple and Spotify. Outside of Dark Reading, he also co-hosts "The Industrial Security Podcast."

Trusted Apps Sneak a Bug Into the UEFI Boot Process

Cybersecurity researchers have detailed an attack that involved a threat actor utilizing a Python-based backdoor to maintain persistent access to compromised endpoints and then leveraged this access to deploy the RansomHub ransomware throughout the target network.
According to GuidePoint Security, initial access is said to have been facilitated by means of a JavaScript malware downloaded named

Python-Based Malware Powers RansomHub Ransomware to Exploit Network Flaws

Ultimately, there is no replacement for an intuitive, security-focused developer working with the critical thinking required to drive down the risk of both AI and human error.

Matias Madou, Co-Founder & CTO, Secure Code Warrior

January 15, 2025

5 Min Read

Source: Nils Ackermann via Alamy Stock Vector

COMMENTARY

The advent of artificial intelligence (AI) coding tools undoubtedly signifies a new chapter in modern software development. With 63% of organizations currently piloting or deploying AI coding assistants into their development workflows, the genie is well and truly out of the bottle, and the industry must now make careful moves to integrate it as safely and efficiently as possible.

The OWASP Foundation has long been a champion of secure coding best practices, providing extensive coverage on how developers can best defend their codebases from exploitable vulnerabilities. Its recent update to the OWASP Top 10 for Large Language Model (LLM) Applications reveals the emerging and most potent threats perpetuated by AI-generated code and generative AI (GenAI) applications, and this is an essential starting point for understanding and mitigating the threats likely to rear their ugly heads. 

We must focus on integrating solid, foundational controls around developer risk management if we want to see more secure, higher quality software in the future, not to mention make a dent in the flurry of global guidelines that demand applications are released that are secure by design.

**The Perilous Crossover Between AI-Generated Code and Software Supply Chain Security**

Prompt Injection's ranking as the No. 1 entry on the latest OWASP Top 10 was unsurprising, given its function as a direct natural language command telling the software what to do (for better or worse). However, Supply Chain Vulnerabilities, which have a much more significant impact at the enterprise level, came in at No. 3. 

OWASP's advice mentions several attack vectors comprising this category of vulnerability, elements such as implementing pretrained models that are also precompromised with backdoors, malware and poisoned data, or vulnerable LoRA adapters that, ironically, are used to increase efficiency, but can, in turn, compromise the base LLM. These present potentially grave, widespread exploitable issues that can permeate the whole supply chain in which they are used.

Sadly, many developers are not skill- and process-enabled enough to navigate these problems safely, and this is even more apparent when assessing AI-generated code for business logic flaws. While not specifically listed as a category, as is apparent in OWASP’s Top 10 Web Application Security Risks, this is partly covered in No. 6, Excessive Agency. Often, a developer will vastly overprivilege the LLM for it to operate more seamlessly, especially in testing environments, or misinterpret how real users will interact with the software, leaving it vulnerable to exploitable logic bugs. These, too, affect supply chain applications and, overall, require a developer to apply critical thinking and threat modeling principles to overcome them. Unchecked AI tool use, or adding AI-powered layers to existing codebases, adds to the overall complexity and is a significant area of developer-driven risk.

**Data Exposure Is a Serious Concern Requiring Serious Awareness**

Sensitive Information Disclosure is second on the new list, but it should be a chief concern for enterprise security leaders and development managers. As OWASP points out, this vector can affect both the LLM itself and its application context, leading to personally identifiable information (PII) exposure, and disclosure of proprietary algorithms and business data.

The nature of how the technology operates can mean that exposing this data is as simple as using cunning prompts rather than actively "hacking" a code-level vulnerability, and "the grandma exploit" is a prime example of sensitive data being exposed due to lax security controls over executable prompts. Here, ChatGPT was duped into revealing the recipe for napalm when prompted to assume the role of a grandmother reading a bedtime story. A similar technique was also used to extract Windows 11 keys. 

Part of the reason this is made possible is through poorly configured model outputs that can expose proprietary training data, which can then be leveraged in inversion attacks to eventually circumvent the security controls. This is a high-risk area for those who are feeding training data into their own LLMs, and the use of the technology requires companywide, role-based security awareness upskilling. The developers building the platform must be well-versed in input validation and data sanitization (as in, these skills are verified and assessed before they can commit code), and every end user must be trained to avoid feeding sensitive data that can be spat out at a later date.

While this may seem trivial on a small scale, at the government or enterprise level, with the potential for tens of thousands of employees to inadvertently participate in exposing sensitive data, it's a significant expansion of an already unwieldy attack surface that must be addressed.

**Are You Paying Attention to Retrieval-Augmented Generation (RAG)?**

Perhaps the most notable new entry in the 2025 list is featured at No. 8, Vector and Embedding Weaknesses. With enterprise LLM applications often utilizing RAG technology as part of the software architecture, this is a vulnerability category to which the industry must pay close attention.

RAG is essential for model performance enhancement, often acting as the "glue" that provides contextual cues between pre-trained models and external knowledge sources. This is made possible by implementing vectors and embeddings, but if they are not implemented securely they can lead to disastrous data exposure, or pave the way for serious data poisoning and embedding inversion attacks. 

A comprehensive understanding of both core business logic and least-privilege access control should be considered a security skills baseline for developers working on internal models. However, realistically, the best-case scenario would involve utilizing the highest-performing, security-skilled developers and their AppSec counterparts to perform comprehensive threat modeling and ensure sufficient logging and monitoring.

As with all LLM technology, while this is a fascinating emerging space, it should be crafted and used with a high level of security knowledge and care. This list is a powerful, up-to-date foundation for the current threat landscape, but the environment will inevitably grow and change quickly. The way in which developers create applications is sure to be augmented in the next few years, but ultimately, there is no replacement for an intuitive, security-focused developer working with the critical thinking required to drive down the risk of both AI and human error.

**About the Author**

Co-Founder & CTO, Secure Code Warrior

Matias Madou is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company, Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences, including RSA Conference, Black Hat, DEF CON, BSIMM, OWASP AppSec, and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

OWASP's New LLM Top 10 Shows Emerging AI Threats

A critical vulnerability (CVE-2024-50603) in the Aviatrix Controller allows unauthenticated RCE. Active exploitation observed by Wiz Research in…

A critical vulnerability (CVE-2024-50603) in the Aviatrix Controller allows unauthenticated RCE. Active exploitation observed by Wiz Research in the wild for cryptojacking and backdoors. Learn about the risks and how to mitigate them.

Wiz Research, a prominent player in the cloud security space, has observed that a critical security flaw, CVE-2024-50603, impacting the Aviatrix Controller cloud networking platform, has been actively exploited in the wild by threat actors. With a CVSS score of 10.0, this critical vulnerability allows unauthenticated remote code execution (RCE) due to improper input sanitization in certain API endpoints.

CVE-2024-50603, is a critical flaw in Aviatrix Controller, a cloud networking platform, allowing unauthenticated remote code execution. A command injection vulnerability arises from improper input sanitization in certain API endpoints. That is, the Aviatrix Controller’s PHP API, which incorporates user-supplied parameters, is vulnerable to attacks due to improper handling, allowing malicious OS commands to be executed by unauthenticated users. 

What’s concerning is that attackers can exploit this flaw simply by crafting malicious commands. For example, instead of providing legitimate cloud-type values, an attacker could inject commands like: ; rm -rf / (to delete all files on the system), or, ;download\_malware.sh (to download and execute malicious software)

The issue arises from how these user-supplied parameters are integrated into the internal workings of the Aviatrix Controller. Instead of properly validating and sanitizing the input, these parameters are directly incorporated into system commands. Exploiting this flaw can grant attackers arbitrary command execution on the system, potentially leading to privilege escalation within the cloud environment.

Wiz Research has observed active exploitation of this vulnerability in the wild, with attackers deploying cryptocurrency miners and backdoors on compromised systems. This is concerning as the Aviatrix Controller often holds significant privileges within cloud environments, enabling attackers to move laterally and gain control of critical cloud resources. Given the widespread use of Aviatrix Controller and its potential for privilege escalation within cloud environments, this vulnerability can put the security of a wide range of organizations in danger.  

The vulnerability impacts Aviatrix Controller versions prior to 7.1.4191 and 7.2.4996. Security teams should immediately upgrade to the patched versions and implement network restrictions to minimize the attack surface, Wiz Research noted in the blog post shared with Hackread.com and published a proof-of-concept exploit, which can be accessed here. 

\[wp\_ad\_camp\_1

Proactive threat hunting is crucial, involving reviewing security logs for suspicious activity, searching for malware findings on compute resources hosting Aviatrix Controller, and analyzing cloud events for abnormal activity. By taking these steps, organizations can mitigate the risks associated with this critical vulnerability and prevent further exploitation.

Ray Kelly, a Fellow at Black Duck commented on the latest development emphasizing the importance of securing API endpoints. _“_The critical vulnerability (CVSS score: 10.0) in the Aviatrix Controller underscores the critical need to secure API endpoints. Developers often assume that APIs are hidden or immune to common web application attacks, but this example highlights how a server can be compromised through a simple web call._“_

_“_Thoroughly testing APIs is challenging due to their size, complexity, and the interdependence of chained calls. However, comprehensive security testing is essential, as neglecting it can lead to catastrophic consequences,_“_ Ray advised.

Hackers Use CVE-2024-50603 to Deploy Backdoor on Aviatrix Controllers

A critical security breach in the software supply chain has been detected. An attacker accessed Kong’s DockerHub account…

A critical security breach in the software supply chain has been detected. An attacker accessed Kong’s DockerHub account and replaced the legitimate Kong Ingress Controller v.3.4.0 image with a malicious version.

A critical security vulnerability was identified in Kong Ingress Controller version 3.4.0. This vulnerability stemmed from an unauthorized image uploaded to DockerHub on December 23rd, 2024. The affected image (hash: sha256:a00659df0771d076fc9d0baf1f2f45e81ec9f13179f499d4cd940f57afc75d43) contained malicious code that enabled cryptojacking. 

This malicious code directed the controller to pool.supportxmr.com, a crypto mining site, which means the image contained code that secretly mined cryptocurrency. Moreover, it would have been executed by any system running the compromised image, effectively turning those systems into unintended mining rigs.

The Kong team became aware of the issue on January 2nd, 2025 and took swift action. They removed version 3.4.0 and all associated tags from DockerHub. Additionally, they rotated all access keys used for DockerHub access. Finally, a patched version, 3.4.1, was released on January 2nd, 2025. This version removed the unauthorized cryptojacking code.

There is currently no evidence to suggest that any Kong Ingress Controller versions besides 3.4.0 (specifically the image hash mentioned above) were affected.

****What You Should Do:****

If you deployed Kong Ingress Controller version 3.4.0 between December 22nd, 2024 and January 3rd, 2025, immediate action is required. You should remove this image from all internal registries and clusters.

To fix the issue, remove the vulnerable image (sha256:a00659df0771d076fc9d0baf1f2f45e81ec9f13179f499d4cd940f57afc75d43) from internal registries and clusters, pull a remediated image from either the patched version 3.4.1 or a clean version 3.4.0.

The fixed image hashes for the clean, re-tagged version of 3.4.0 are:

AMD64: sha256:b358296fa6a1458c977c0513ff918e80b708fa9d7721f9d438f3dfce24f60f4f

ARM64: sha256:e0125aa85a4c9eef7822ba5234e90958c71e1d29474d6247adc3e7e21327e8ee

By taking these steps, you can ensure you are no longer running a vulnerable image and protect your systems from cryptojacking attempts.

Dan Lorenc, CEO and founder of software supply chain security platform Chainguard provided Hackread.com with a detailed comment addressing the core issues within this attack stating, “Supply-chain breaches happen, and it looks like the kong/kubernetes-ingress-controller images are the latest to fall victim. Here’s what we know so far:

*   A DockerHub PAT used to upload release images was compromised sometime before Dec. 23rd
*   The attacker used this PAT to upload a malicious version of the 3.4.0 release image directly to DockerHub
*   This image contained code to mine cryptocurrency and send results to a specific wallet
*   High CPU usage was reported by a user on December 29th, and the malicious images were taken down by January 2nd
*   New versions were uploaded, and the keys used to upload were revoked/rotated by the maintainers

“How should you protect against attacks like this? As a maintainer, any key you have is a key that you can leak,” said Dan. “Lock down and regularly audit all systems that have access to PATs like this, or choose systems that allow OIDC-based authentication to avoid this altogether. CI/CD pipelines are notoriously hard to configure securely; tools like Zizmor (lnkd.in/eGSGrMqm) help here. Signing artefacts can help even if you can’t use OIDC to publish or users pull from mirrors out of your control.”

“As an end-user, pin images you receive from third-parties by digest and test/malware scan them before upgrading. Check signatures if they exist,” Dan explained.

Nevertheless, a crypto mining attack on organizations could have drastic implications, including increased resource consumption, higher energy costs, and a multitude of security risks. The compromised image could have introduced vulnerabilities or backdoors, allowing attackers to gain further access, highlighting the importance of software supply chain security, particularly for critical components like container images. Organizations should employ image integrity verification mechanisms, and conduct regular security audits to identify and mitigate vulnerabilities.

1.  **OracleIV DDoS Botnet Hits Docker Engine API Instances**
2.  **Malware Hits 9Hits, Turns Docker Servers into Crypto Miners**
3.  **Hackers hijacking Bitbucket and Docker Hub for Monero mining**
4.  **TeamTNT Exploits 16M IPs in Malware Attack on Docker Clusters**
5.  **Linux Malware Alert: ‘Spinning YARN’ Hits Docker, Other Key Apps**

Malicious Kong Ingress Controller Image Found on DockerHub

The security vulnerability tracked as CVE-2024-50603, which rates 10 out of 10 on the CVSS scale, enables unauthenticated remote code execution on affected systems, which cyberattackers are using to plant malware.

Source: Everett Collection Historical via Alamy Stock Photo

Multiple threat actors are actively targeting a recently disclosed maximum-severity security bug in the Aviatrix Controller centralized management platform for cloud networking.

In a worst-case scenario, the vulnerability, identified as CVE-2024-50603 (CVSS 10) could allow an unauthenticated remote adversary to run arbitrary commands on an affected system and take full control of it. Attackers are currently exploiting the flaw to deploy XMRig cryptomining malware and the Sliver backdoor on vulnerable targets.

**CVE-2024-50603: A High-Impact Vulnerability**

The vulnerability presents an especially severe risk in Amazon Web Services (AWS) cloud environments, where Aviatrix Controller allows privilege escalation by default, researchers at Wiz Security warned in a blog on Jan. 10.

"Based on our data, around 3% of cloud enterprise environments have Aviatrix Controller deployed," the researchers noted. "In 65% of such environments, the virtual machine hosting Aviatrix Controller has a lateral movement path to administrative cloud control plane permissions."

Hundreds of large companies use Aviatrix's technology to manage cloud networking across AWS, Azure, Google Cloud Platform (GCP), and other multi-cloud environments. Common use cases include automating the deployment and management of cloud network infrastructure, and managing security, encryption, and connectivity policies. The company lists organizations such as Heineken, Raytheon, Yara, and IHG Hotels and Resorts among its customers.

Related:In Appreciation: Amit Yoran, Tenable CEO, Passes Away

CVE-2024-50603 stems from Aviatrix Controller not properly checking or validating the data that users send through its application programming interface (API). It is the latest bug to highlight the security risks tied to the growing use of APIs among organizations of all sizes. Other common API-related risks include those stemming from configuration errors, lack of visibility, and inadequate security testing.

The flaw is present in all supported versions of Aviatrix Controller before 7.2.4996 or 7.1.4191. Aviatrix has issued a patch for the bug and recommends that organizations apply it or upgrade to either versions 7.1.4191 or 7.2.4996 of the Controller.

"In certain circumstances the patch is not fully persistent across controller upgrades and must be re-applied, even if the controller status is displayed as 'patched,'" the company noted. One such circumstance is applying the patch on non-supported versions of the controller, Aviatrix said.

**Hackers Mount Opportunistic Cloud Attacks**

Security researcher Jakub Korepta of SecuRing, who discovered and reported the bug to Aviatrix, publicly disclosed details of the flaw on Jan. 7. Just one day later, a proof-of-concept exploit for the bug became available on GitHub, triggering near-immediate exploit activity.

Related:Managing Cloud Risks Gave Security Teams a Big Headache in 2024

"Since the proof-of-concept release, Wiz observed that most of the vulnerable instances were specifically targeted by attackers looking for unpatched Aviatrix deployments," says Alon Schindel, vice president of AI & Threat Research at Wiz. "The overall volume of exploitation attempts has been steady. However, we see customers patching their systems and preventing attackers from targeting them."

Schindel characterizes the exploit activity so far as largely opportunistic in nature, and emanating from scanners and automated tool sets combing the Internet for unpatched Aviatrix instances.

"Although some of the payloads and infrastructure used suggest higher sophistication in a few cases, most of the attempts appear to be broad sweeps rather than highly customized or targeted attacks on specific organizations," he says.

Available telemetry suggests that multiple threat actors, including organized criminal gangs, are leveraging the flaw in various ways. So far at least, there is no evidence pointing to any single group as dominating the exploitation activity, Schindel says. "Depending on the environment's setup, an attacker might exfiltrate sensitive data, access other parts of the cloud or on-prem infrastructure, or disrupt normal operations," he notes.

Related:DDoS Attacks Surge as Africa Expands Its Digital Footprint

**A Reminder of API-Based Cyber-Risks**

Ray Kelly, a fellow at Black Duck, says the Aviatrix Controller vulnerability is another reminder of both the growing risks associated with API endpoints and the challenges involved in addressing them. The vulnerability shows how a server can be compromised via a simple Web call to an API, and highlights the need for thorough testing of APIs. But such testing can be daunting, given the size, complexity, and interdependence of APIs and the fact that many APIs are developed and managed by external software and service providers.

"One effective approach to mitigating these risks is by establishing clear 'rules of governance' for third-party software," Kelly says. "This includes implementing thorough vetting processes for third-party providers, enforcing consistent security measures, and maintaining continuous monitoring of software performance and vulnerabilities."

Wiz's Schindel says the best recourse for organizations affected by the new Aviatrix bug is to apply the company's patch for it as soon as possible. Organizations that are unable to patch immediately should restrict network access to the Aviatrix Controller via an IP allowlist so only trusted sources can reach it, Schindel advises. They should also monitor logs and system behavior closely for suspicious activity or known exploit indicators, set up alerts for abnormal behavior associated with Aviatrix, and reduce unnecessary lateral movement paths between their cloud identities.

Jessica MacGregor, spokeswoman for Aviatrix says the company issued an emergency patch for the vulnerability back in November 2024 given its potential severity. The security patch applied to all supported releases and also for versions of Aviatrix Controller for which support had ended two years ago. The company also reached out privately to customers via multiple targeted campaigns to make sure affected organizations applied the patch, MacGregor says.

While a significant portion of affected customers have applied the patch and recommended hardening measures, some organizations have not. And it is these customers that are experiencing the current attacks, she notes. "While we strongly recommend that customers remain current in their software, customers on Controller version 6.7+ who have applied the Security Patch can be protected even if they have not upgraded to the latest versions with the permanent fixes," she says.

 MacGregor says Aviatrix wants anyone unable to upgrade or patch their systems to reach out so the company can work with them to harden their configuration based on best practices. "We will also work closely with customers that believe they been exploited to restore their Aviatrix software to a clean state."

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Cloud Attackers Exploit Max-Critical Aviatrix RCE Flaw

By focusing on vigilant security practices, responsible AI deployment, and alignment with global regulatory standards, the OSS community can make 2025 a transformative year for security.

Source: Wavebreakmedia Ltd FUS1407 via Alamy Stock Photo

COMMENTARY

As we move into 2025, open source software (OSS) remains central to digital innovation across industries. However, its widespread adoption brings heightened security challenges and evolving regulatory demands. In the coming year, we expect a rise in targeted OSS supply chain attacks, a greater reliance on AI in cybersecurity — with both positive and negative implications — and a stronger push for global regulatory standards promoting responsible OSS practices.

**Growing Threats in the Open Source Supply Chain**

Following incidents like the XZ Utils backdoor, OSS supply chain attacks are expected to increase in frequency and sophistication. These attacks will likely prompt a heightened sense of urgency within organizations as they realize that a single security scan is insufficient. Moving forward, implementing proactive, continuous monitoring and adopting advanced tools will be essential to identifying threats before they can cause damage.

Understanding the growing importance of OSS security, the Open Source Security Foundation (OpenSSF) has taken steps to address these security challenges. As threats evolve, organizations will increasingly rely on resources like OpenSSF's SIREN mailing list, which notifies the OSS community about emerging threats, and the Open Source Vulnerabilities project, which helps identify malicious packages and other vulnerabilities. Tools such as Scorecard and GUAC provide visibility into project dependencies, helping developers assess risk within their OSS components. As the supply chain threat landscape intensifies, adopting these tools as standard practice will be important for any organization that relies on OSS.

**AI as a Double-Edged Sword in Cybersecurity**

AI will continue transforming cybersecurity in 2025, acting as a powerful ally for defenders and a dangerous weapon for attackers. On the one hand, AI integrated into automated tools and continuous integration and continuous delivery(CI/CD) pipelines will help organizations identify coding flaws and vulnerabilities more efficiently. Security teams will also increasingly rely on AI to analyze vast data volumes and detect unusual patterns in real time.

However, attackers will use AI to enhance their tactics, such as refining social engineering techniques or automating the search for vulnerabilities within codebases. Additionally, they will exploit flaws in AI-generated code for malicious purposes. This double-edged sword with AI highlights the urgent need for robust safeguards and security-focused innovation to harness AI's benefits while mitigating its risks.

**A Global Regulatory Push for Open Source Compliance**

The regulatory landscape surrounding OSS security will shift in 2025 as the European Union's Cyber Resilience Act (CRA) takes effect. By requiring software bills of materials (SBOM) and setting compliance standards, the CRA is expected to establish a global precedent, influencing nations like Japan, India, and the US to adopt similar legislation.

This regulatory shift will likely push more organizations to reassess their OSS practices, prioritizing transparency and accountability. As compliance pressures mount, companies will increasingly contribute to the open source projects they depend on, recognizing that supporting the OSS community bolsters the security and resilience of their digital ecosystems. This collaboration will enhance security and foster sustainable growth in the OSS landscape.

**Opportunities and Strategies for Open Source Security**

While these trends present clear challenges, companies can proactively strengthen OSS security. Businesses need to understand their dependencies and implement proactive measures to secure OSS components. Simple measures — such as supporting the developers behind critical open source projects and investing in secure infrastructure — can make a significant impact.

Most OSS developers are highly skilled but may lack specialized training in cybersecurity practices. OpenSSF aims to bridge this gap by offering tools and training that help embed security into the development process. Companies that adopt OSS due diligence, such as reviewing a project's security practices before integrating it, are better positioned to avoid vulnerabilities and maintain a secure infrastructure.

**Looking Ahead: A Collaborative Approach to Open Source Security**

OSS has grown beyond a convenient tool for developers — it is now a critical component of the global economy, valued in the trillions of dollars. While it will remain a driving force for technological progress, security must be a priority. Companies, governments, and the OSS community must work together to ensure a sustainable, secure, open source ecosystem.

Focusing on vigilant security practices, responsible AI deployment, and alignment with global regulatory standards, the OSS community can make 2025 a transformative year for security. By prioritizing collaboration and investment in security initiatives, we can build a resilient open source future in which OSS continues to power innovation safely and sustainably.

**About the Author**

Chief Security Architect, Open Source Security Foundation

Christopher Robinson (aka CRob) is the chief security architect for the Open Source Software Foundation (OpenSSF). With more than 25 years of experience in engineering and leadership, he has worked with Fortune 500 companies in industries like finance, healthcare, and manufacturing, and spent six years as program architect for Red Hat’s product security team.

Tag

#backdoor