The AI Incident Reporting and Security Enhancement Act would allow NIST to create a process for reporting and tracking vulnerabilities found in AI systems.

Source: zemkooo via Alamy Stock Photo

A House committee advanced a bill that would allow the National Institute of Standards and Technology (NIST) to create a formal process for reporting security vulnerabilities in artificial intelligence (AI) systems. As is the case for many security projects, funding concerns could stymie the initiative.

The AI Incident Reporting and Security Enhancement Act was approved by voice vote by the House Science, Space and Technology committee on Wednesday. The bill was introduced by a bipartisan trio of representatives from North Carolina, California, and Virginia. If approved by the full Congress and signed into law, it would give NIST the mandate to incorporate AI systems in the National Vulnerability Database (NVD).

NVD is the federal government's centralized repository for tracking security vulnerabilities in software and hardware. In its current form, the bill would add to the workload of the already-beleaguered NIST teams managing the NVD. NIST earlier this year paused updating data on reported vulnerabilities, in a move program manager Tanya Brewer said was the result of budget cuts, flat staff growth, and an increase in database-related email traffic.

The bill specifies that the increased workload for NIST would be "subject to the availability of funding," but Rep. Deborah Ross (D-NC), a sponsor of the bill, said that they were aware of "significant funding and scaling challenges" NIST already experienced maintaining the database.

"My colleagues and I on this committee are actively exploring solutions to help NIST address this problem and get the money," she said.

Even though the bill was approved in committee, some committee members expressed concern about some of the language used in the bill. There were concerns that terms such as "substantial artificial intelligence security incident" and "intelligence incident" would need to be clarified to make it more likely that the bill would pass. This kind of specificity is also a bigger concern in Congress in the wake of the Supreme Court overturning the Chevron doctrine.

The bill would also require NIST to consult with other federal agencies, like the Cybersecurity and Infrastructure Security Agency, private-sector organizations, standards organizations, and civil society groups, to develop a common lexicon for reporting AI cybersecurity incidents.

**About the Author**

Jennifer Lawinski is a writer and editor with more than 20 years experience in media, covering a wide range of topics including business, news, culture, science, technology and cybersecurity. After earning a Master's degree in Journalism from Boston University, she started her career as a beat reporter for The Daily News of Newburyport. She has since written for a variety of publications including CNN, Fox News, Tech Target, CRN, CIO Insight, MSN News and Live Science. She lives in Brooklyn with her partner and two cats.

Congress Advances Bill to Add AI to National Vulnerability Database

British Transport Police and Network Rail are investigating the incident, in which bad actors posted Islamophobic messages on the transport system's network.

Source: mark phillips via Alamy Stock Photo

A cybersecurity incident is being investigated after Islamophobic messages were displayed to users through a compromised Wi-Fi landing page.

Network Rail, the non-departmental public body, is probing the incident, which affected 20 stations, all managed by the same body; 10 of the stations are in London, the rest are distributed across key commuter stations in Reading, Leeds, Glasglow Central, and others.

"We received reports at around 1703 yesterday \[Sept. 25\] of a cyberattack displaying Islamophobic messaging on some Network Rail Wi-Fi services," said the British Transport Police (BTP), which is also involved in the case. 

Telent, the communications company that operates Network Rail's Wi-Fi, reported that it is aware of the incident and is also involved in the investigation to identify the root cause.

"Nation states and criminals are increasingly targeting key third-party suppliers to cause widespread disruption to multiple industries at once, and the attack on the rail service is just the latest example of this," said Dan Schiappa, chief product and services officer at Arctic Wolf, in an emailed statement to Dark Reading. "It is vital every company, regardless of whether it is critical infrastructure or not, ensures the suppliers it works with have strong cybersecurity otherwise they are leaving a huge hole in their defenses."

And while it may be too soon to point fingers at any party involved, as the investigation continues, Network Rail has suspended Wi-Fi services for the time being.

**About the Author**

Public Wi-Fi Compromised in UK Train Stations

Beware that friendly text from the IT department giving you an "update" about restoring your broadband connectivity.

Source: Mike Hill via Alamy Stock Photo

Hurricane Helene is whirling its way toward the Florida coast, with the US National Hurricane Center warning those in the path of the storm to prepare for a Category 3 landing on the night of Sept. 26, followed by a life-threatening 20-foot storm surge.

Unfortunately, cybercriminals are likely planning a storm of their own, in the form of fraud and phishing efforts tied to interest and anxiety related to Helene.

A charity appeal for donations is a common gambit that cyber scammers perpetrate after a natural disaster, along with notices that purport to come from energy or phone providers about outages, and even unsolicited offers of help from "contractors" who can remove fallen trees or outfit your office with a generator — as long as you pay upfront.

There are many, many variations on the theme, including business email compromise (BEC)\-enabled attacks that use a legitimate organization's email to hide nefarious purposes.

Being suspicious is the top defense here. As the US Cybersecurity and Infrastructure Security Agency (CISA) warned on Sept. 26, individual citizens and corporate users alike should remain vigilant when "handling emails with hurricane-related subject lines, attachments, or hyperlinks. In addition, be wary of social media pleas, texts, or door-to-door solicitations relating to severe weather events."

**About the Author**

Tara Seals has 20+ years of experience as a journalist, analyst and editor in the cybersecurity, communications and technology space. Prior to Dark Reading, Tara was Editor in Chief at Threatpost, and prior to that, the North American news lead for Infosecurity Magazine. She also spent 13 years working for Informa (formerly Virgo Publishing), as executive editor and editor-in-chief at publications focused on both the service provider and the enterprise arenas. A Texas native, she holds a B.A. from Columbia University, lives in Western Massachusetts with her family and is on a never-ending quest for good Mexican food in the Northeast.

Hurricane Helene Prompts CISA Fraud Warning

Developers need to do more than scan code and vet software components, and ops should do more than just defend the deployment pipeline.

Source: whiteMocca via Shutterstock

Combining software development, deployment, and operations pipelines into DevOps teams promises increased efficiency, easier and more frequent updates, and better quality applications. Yet the complexity of the infrastructure has also led to a growing attack surface that is hard to monitor and maintain.

On the development side, the average organization uses four to nine different programming languages, has to deal with millions of new packages and images every year, and remediates thousands of vulnerabilities in the most common open source components, according to JFrog's Software Supply Chain State of the Union 2024 report. At the other end of the DevOps pipeline, two-thirds of companies have delayed deployment of an application due to Kubernetes security concerns, and nearly half (46%) had actual security incidents, according to Red Hat's The State of Kubernetes Security 2024 report.

Cybersecurity professionals aiming to secure the application pipeline have to pay attention to the software being written by developers, the open source components imported by developers, the containers and cloud infrastructure used to deploy software, and the build tools used to make the software, says Jeff Williams, chief technology officer and co-founder of Contrast Security, a software security firm.

"The problem is it's such a huge attack surface," he says. "It's not just your pipeline. It's all the other code that goes into developing software — it's IDEs and test tools and performance suites ... any one of them is capable of subverting the code that your developers are building and producing."

Gaining an integrated view of the entire DevOps pipeline, from development to application deployment, is increasingly important. Software components — not just open source libraries but Docker containers and other infrastructure assets — often have vulnerable code, increasing risk. Third-party tools can be compromised — remember Codecov's breach —allowing malicious code to be injected into projects under development. Cloud infrastructure and storage can be misconfigured or improperly protected, a la Snowflake instances.

Having good visibility into the state of the DevOps software pipeline and deployment infrastructure is critical, says Josh Lemos, chief information security officer at DevOps provider GitLab (and no relation to the author).

"There are two real important trains that need to run," he says. "One is you need the development and packaging security, compliance, and attestation of all of your build artifacts in one of those trains — or work streams. The other is the deployment monitoring and orchestration of those things in your production environments."

**Write, Use, Buy, Build**

Overall, DevOps security teams need to protect four areas that are open to attack. The first and second areas are most obvious to developers: the code that they write and the software components that they use, says Contrast Security's Williams.

"We've been talking about \[that code\] since the beginning of OWASP ... if you got bugs in the code you write, people exploit them, and you get breached. It's not good," he says.

Companies also have to pay attention to the code that they buy or — through a service — use indirectly. Finally, they need to secure the applications and services that are used to build and deploy software — the IDEs, test tools, performance suites, and instrumentation.

"Any one of those is capable of subverting the final code," Williams says, adding that most DevOps teams do not pay attention to the full attack surface posed by their pipeline and software supply chain. "I think we're still in the Stone Age, when it comes to real supply chain security."

While the vast majority of companies (87%) are building or moving applications to cloud-native, most (59%) did not understand the security implications of doing so and have suffered a security issue as a result. Predictably, the collection of common security incidents are as varied as the infrastructure needed to produce and deploy software: Network breaches, API vulnerabilities, certificate misconfigurations, cluster misconfigurations, and vulnerabilities in containers are among the top causes of security incidents, according to a November 2023 survey of cloud-native application security issues.

Even companies that are monitoring parts of their DevOps pipelines are not getting good coverage, says Williams.

"It's not everywhere, and almost nothing covers part of the DevOps like developer workstations and IDEs and testing frameworks and plugins," he says. "I mean, there's a universe of code that nobody's monitoring, and most organizations are not really thinking about this problem."

**Questioning Your DevOps Infrastructure**

For most companies, ensuring that they have visibility into the entire pipeline is essential. Monitoring can warn when a retired package is suddenly revived in the repository by an untrusted party, or when secrets are included in code that might otherwise be pushed to a repository, or when a Docker image has significant amounts of unused software.

Companies need to have continuous monitoring of each step in the pipeline, says Paul Davis, field CISO at software supply chain provider JFrog.

"\[Knowing\] what's going ... and \[seeing that\] a package has gone bad in production, or that I need to roll back a package because somebody's come with a new vulnerability — that ease of use \[and visibility\] into the attack surface, that insight and that traceability — is key for me," he says.

Companies should also take action around four specific areas of their DevOps infrastructure, according to GitLab's Lemos. First, the identities of any developer, ops specialist, device or service that takes part in the pipeline should be logged. Companies should also maintain a list of software artifact that they are using, which ones have vulnerabilities, and maintain a private repository, if possible. The build systems should be frequently tested, and any automated triggers — such as changes to third-party software that triggers a build — should be analyzed for potential security implications. Finally, the entire pipeline should be architected to minimize the impact — the "blast radius" — of a compromise, he says.

"The best thing I've seen companies do as a first step is to get to some known good design patterns," Lemos says. "The more of that that you can abstract away from \[bad security practices\], the more successful your security program will be, the less churn and load you'll have, and the more reusable your code becomes."

**The Promise, and Peril, of AI**

The breadth of the DevOps attack surface also represents an opportunity for automation and AI assistance. DevOps already gains much of its agility and speed through automation, with configuration- and infrastructure-as-code dominating because expressing architecture as files allow repeatability for operations, while analyzing the instructions allow for more secure infrastructure.

Yet, when it comes to security, most companies are holding back on adoption, says Laurent Gil, chief product officer for Kubernetes automation platform Cast AI.

"Almost every security company offers automation in some form, and yet nobody is using it," he says. "\[Security teams\] should know that it's okay to use automation to either block things that should be blocked, or to auto-remediate when you find something that contains vulnerabilities."

AI development also brings new ways of working with code and data — an attack surface area that is not fully understood and for which DevOps teams are not ready, says GitLab's Lemos.

"There is the possibility to do really old-style attacks, because you're combining data and content into a model," he says. "A model with a pickle file that gets consumed into a data scientist's workstation, if they deserialize it and it has a payload, they've just invited in some malicious code into their environment."

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

Moving DevOps Security Out of 'the Stone Age'

Source: whiteMocca via Shutterstock

Combining software development, deployment, and operations pipelines into DevOps teams promises increased efficiency, easier and more frequent updates, and higher-quality applications. Yet the complexity of the infrastructure has also led to a growing attack surface that is hard to monitor and maintain.

On the development side, the average organization uses four to nine different programming languages, deals with millions of new packages and images every year, and has to remediate thousands of vulnerabilities in the most common open source components, according to JFrog's "Software Supply Chain State of the Union 2024" report. At the other end of the DevOps pipeline, two-thirds of companies have delayed deployment of an application due to Kubernetes security concerns, and nearly half (46%) had actual security incidents, according to Red Hat's 2024 "The State of Kubernetes" security report.

Cybersecurity professionals aiming to secure the application pipeline have to pay attention to the software being written by developers, the open source components imported by developers, the containers and cloud infrastructure used to deploy software, and the build tools used to make the software, says Jeff Williams, chief technology officer and co-founder of Contrast Security, a software security firm.

"The problem is it's such a huge attack surface," he says. "It's not just your pipeline. It's all the other code that goes into developing software — it's IDEs and test tools and performance suites. ... Any one of them is capable of subverting the code that your developers are building and producing."

Gaining an integrated view of the entire DevOps pipeline, from development to application deployment, is increasingly important. Software components — not just open source libraries but Docker containers and other infrastructure assets — often have vulnerable code, increasing risk. Third-party tools can be compromised — remember Codecov's breach — allowing malicious code to be injected into projects under development. Cloud infrastructure and storage can be misconfigured or improperly protected, a la Snowflake instances.

Having good visibility into the state of the DevOps software pipeline and deployment infrastructure is critical, says Josh Lemos, chief information security officer at DevOps provider GitLab (and no relation to the author).

"There are two really important trains that need to run," he says. "One is you need the development and packaging security, compliance, and attestation of all of your build artifacts in one of those trains or work streams. The other is the deployment monitoring and orchestration of those things in your production environments."

**Write, Use, Buy, Build**

Overall, DevOps security teams need to protect four areas that are open to attack. The first and second areas are most obvious to developers: the code that they write and the software components that they use, says Contrast Security's Williams.

"We've been talking about \[that code\] since the beginning of OWASP," he says. "If you have bugs in the code you write, people exploit them, and you get breached. It's not good."

Companies also have to pay attention to the code that they buy or, through a service, use indirectly. Finally, they need to secure the applications and services that are used to build and deploy software —the IDEs, test tools, performance suites, and instrumentation.

"Any one of those is capable of subverting the final code," Williams says, adding that most DevOps teams do not pay attention to the full attack surface posed by their pipelines and software supply chains. "I think we're still in the Stone Age when it comes to real supply chain security."

While the vast majority of companies (87%) are building or moving applications to cloud-native, 59% did not understand the security implications of doing so and have suffered a security issue as a result. Predictably, the collection of common security incidents are as varied as the infrastructure needed to produce and deploy software: Network breaches, API vulnerabilities, certificate misconfigurations, cluster misconfigurations, and vulnerabilities in containers are among the top causes of security incidents, according to a November 2023 survey of cloud-native application security issues.

Even companies that are monitoring parts of their DevOps pipelines are not getting good coverage, says Williams.

"It's not everywhere, and almost nothing covers part of the DevOps like developer workstations and IDEs and testing frameworks and plug-ins," he says. "I mean, there's a universe of code that nobody's monitoring, and most organizations are not really thinking about this problem."

**Questioning Your DevOps Infrastructure**

For most companies, ensuring that they have visibility into the entire pipeline is essential. Monitoring can warn when a retired package is suddenly revived in the repository by an untrusted party, or when secrets are included in code that might otherwise be pushed to a repository, or when a Docker image has significant amounts of unused software.

Companies need to have continuous monitoring of each step in the pipeline, says Paul Davis, field CISO at software supply chain provider JFrog.

"\[Knowing\] what's going ... and \[seeing that\] a package has gone bad in production, or that I need to roll back a package because somebody's come with a new vulnerability, that ease of use \[and visibility\] into the attack surface — that insight and that traceability — is key for me," he says.

Companies should also take action around four specific areas of their DevOps infrastructure, according to GitLab's Lemos. First, the identities of any developer, ops specialist, device, or service that takes part in the pipeline should be logged. Companies should also maintain a list of software artifacts that they are using, which ones have vulnerabilities, and maintain a private repository, if possible. The build systems should be frequently tested and any automated triggers — such as changes to third-party software that triggers a build — should be analyzed for potential security implications. Finally, the entire pipeline should be architected to minimize the impact — that is, the "blast radius" — of a compromise, he says.

"The best thing I've seen companies do as a first step is to get to some known good design patterns," Lemos says. "The more of that that you can abstract away from \[bad security practices\], the more successful your security program will be, the less churn and load you'll have, and the more reusable your code becomes."

**The Promise and Peril of AI**

The breadth of the DevOps attack surface also represents an opportunity for automation and the assistance of artificial intelligence (AI). DevOps already gains much of its agility and speed through automation, with configuration- and infrastructure-as-code dominating because expressing architecture as files allows repeatability for operations, while analyzing the instructions allows for more secure infrastructure.

Yet when it comes to security, most companies are holding back on adoption, says Laurent Gil, chief product officer for Kubernetes automation platform CAST AI.

"Almost every security company offers automation in some form, and yet nobody is using it," he says. "\[Security teams\] should know that it's OK to use automation to either block things that should be blocked or to auto-remediate when you find something that contains vulnerabilities."

Yet AI development also brings new ways of working with code and data — an attack surface area that is not fully understood and for which DevOps teams are not ready, Lemos says.

"There is the possibility to do really old-style attacks because you're combining data and content into a model," he says. "A model with a pickle file that gets consumed into a data scientist's workstation, if they deserialize it and it has a payload, they've just invited some malicious code into their environment."

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

Moving DevOps Security Out of the 'Stone Age'

An environment that values creativity, continuous learning, and calculated risk-taking can prevent boredom while building a resilient, adaptable team ready to tackle whatever challenges come their way.

Source: ronstik via Alamy Stock Photo

COMMENTARY

We're so fixated on external threats that we usually fail to look within. Boredom in IT teams often led by technical debt is a real problem, and it's costing companies more than they realize. Cyber threats are evolving, and our approach to combating these threats needs to evolve alongside it. Security is now a problem we need to tackle at all levels, but essentially, it requires a team of reactive developers that can tackle these threats at the start of the development life cycle. The engagement level of your IT team should really be a security concern.

**The Ripple Effect of Boredom**

Think about the last time you were genuinely excited about a project. It's likely it involved building innovative solutions or solving complex problems. That's no coincidence. The best software engineers thrive on creativity, continuous learning, and curiosity. 

When IT teams get stuck maintaining legacy systems or performing repetitive tasks, that fuel starts to run dry. The result is a team that's not just bored but actively falling behind in an industry that never stops moving forward.

How do you spot boredom? I've seen it plenty of times in my own career. Typical warning signs include:

*   Technical debt accumulates: Small issues can easily compound into major headaches and, if not solved immediately, create tedious work in the future. As one of our clients experienced, what began as a "we'll fix it later" API workaround ended up costing months of refactoring when they needed to scale.
    
*   Innovation stagnates: Boredom kills creativity. Consider how a simple idea like containerization revolutionized deployment practices. These innovations don't come from teams going through the motions, they emerge when curious minds are given room to explore.
    
*   Skills atrophy: The tech world moves fast. If your team isn't learning, they're falling behind. I've seen teams struggling with cloud migrations because their skills were anchored in on-premises solutions. The cost isn't solely in retraining but in the missed opportunities and the inability to leverage new technologies effectively.
    
*   Talent exodus: The best engineers won't stick around if they're not challenged. Expect increased turnover.
    
*   Security vulnerabilities increase: Engaged teams are your first line of defense against cyber threats. When developers are invested in their work, they're more likely to spot potential security issues early. Bored teams, on the other hand, might miss critical vulnerabilities hidden in seemingly routine code. 
    
*   Product quality suffers: Passionate developers think about edge cases, user experience, and long-term maintainability. When motivation is eroded, so is attention to detail. This could manifest as buggy releases, poor user experiences, or systems that become increasingly difficult to maintain over time.
    

**How to Keep Things Interesting **

Even cutting-edge teams can fall into ruts if they're not careful. The key factor isn't necessarily the age of the technology, but the approach to working with it. Are you just keeping the lights on, or are you constantly looking for ways to improve and evolve your systems?

So, how do we fix this? Installing ping-pong tables or providing free snacks isn't quite what you should be after. The first priority is creating an environment where creativity and innovation can thrive, and where security is more than a boring checklist. 

Here are some concrete steps to take to wake up and engage your IT team:

*   Allow space for creativity and exploration: Set aside dedicated time for your team to exercise their creativity and curiosity. For example, implement a "10% time" policy where developers can work on self-directed projects one afternoon a week. This could lead to innovations like a new internal tool that streamlines your deployment process, or a creative solution to a long-standing bug.
    
*   Modernize and automate the boring stuff: Actively look for opportunities to introduce new tech — and do that by listening to the devs themselves and what tech they want to work with daily. Aggressively reduce false positives and noise in your workflows. Implement tools that automate repetitive tasks and filter out low-impact alerts. This frees up your team to focus on challenging, high-value problems. 
    
*   Give developers ownership of security: Instead of treating security as a separate, boring checklist, integrate it into the development process. Make security accessible to developers by giving them the tools and knowledge to "shift left" — addressing security early in the development cycle. This turns security from a chore into an engaging part of the creative process.
    
*   Implement a "get back to building" mindset: Focus on letting developers do what they love — building. Structure workflows to minimize interruptions and context-switching. For example, set up "no-meeting Wednesdays" or four-hour blocks of uninterrupted development time. This allows for deep work and the satisfaction of seeing projects progress.
    
*   Encourage continuous learning with practical applications: Provide context-rich, actionable information in your training efforts. Instead of generic training sessions, tie learning directly to ongoing projects. For instance, when introducing a new security tool, frame it as a workshop where the team applies it to a current development challenge.
    
*   Simplify and streamline processes: Look for ways to simplify your development and security processes. Could your code review process be streamlined? Is your deployment pipeline overly complex? Engage your team in finding elegant solutions to these challenges. The process of simplification itself can be a motivating and creative exercise.
    
*   Implement "security as code": Treat security configurations and policies as code. This not only improves consistency and version control but also makes security work feel more like a core development task rather than an external obligation.
    

The goal isn't to implement every new idea or chase every trend. It's about creating a culture where ideas flow freely, challenges are framed as learning opportunities, and your team feels encouraged to be creative. If you create an environment that values creativity, continuous learning, and calculated risk-taking, you can not only fight boredom, you can also build a resilient, adaptable team ready to tackle whatever challenges come their way.

Take a look at your team. Are they just going through the motions, or are they genuinely engaged? If it's the former, it's time to shake things up.

**About the Author**

Security Researcher & Advocate, Aikido

As a security researcher and advocate at Aikido, Mackenzie spends his days translating security jargon into human speak and convincing developers that they can care about security without sacrificing their will to live. He loves creating and advocating for security tools that easily integrate into the development process, focusing on reducing alert fatigue and improving the overall developer experience in security implementations.

Before joining Aikido, Mackenzie served as a developer advocate at GitGuardian for more than four years and co-founded and acted as chief technology officer (CTO) for Conpago, a technology company focused on combating social isolation among the elderly through innovative communication devices. Mackenzie is the host ofThe Security Repopodcast, where he explores emerging tech topics in cybersecurity and interviews other experts. In his personal time he brings cybersecurity stories to life in The Red Team Chronicles comic series. Mackenzie also regularly speaks at tech conferences like DevOxx, DefCon, NDC and BlackAlps.

Boredom Is the Silent Killer in Your IT Systems

Researchers have uncovered one of the first examples of threat actors using artificial intelligence chatbots for malware creation, in a phishing attack spreading the open source remote access Trojan.

Source: Irene R via Shutterstock

Threat actors have used generative artificial intelligence (GenAI) to write malicious code in the wild to spread an open source remote access Trojan (RAT). It's one of the first observed examples of attackers weaponizing the chatbot technology for this purpose.

Researchers from HP Wolf Security have found evidence of the campaign, in which the attackers used GenAI to help them write VBScript and JavaScript code that was then used to distribute the AsyncRAT, an easily accessible, commercial malware that can be used for controlling a victim's computer.

The researchers first noticed the behavior when investigating a suspicious email in June. It had "an unusual French email attachment" posing as an invoice, HP Wolf Security revealed in its "Threat Insights Report" (PDF) for this month. The researchers ultimately discovered a campaign that was using both scripting types — code that was not, as it usually is, obfuscated — to spread AsyncRAT.

"The scripts' structure, comments, and choice of function names and variables were strong clues that the threat actor used GenAI to create the malware," according to the report.

It's widely believed that attackers already have used GenAI to help them write more convincing phishing emails, but so far there has been little evidence of the use of the technology to write malicious code, largely because legitimate chatbot tools have guardrails that prevent malicious use. However, security experts have known since the advent of the technology that it was only a matter of time before threat actors would find a way around those gates, and malicious chatbot development is a phenomenon on the Dark Web.

Related:Dark Reading Confidential: The CISO and the SEC

The campaign demonstrates that attackers are quickly leveling up in their use of GenAI in a way that should put defenders on alert, the researchers noted. "The activity shows how GenAI is accelerating attacks and lowering the bar for cybercriminals to infect endpoints or malicious files before they even reach someone's inbox," according to the report.

**Investigating a Malicious Email Campaign**

Once the researchers discovered the disguised invoice, they dug deeper to find that the attachment was simply an HTML file which, when opened in the browser, asks for a password. At first they believed the threat to be an HTML-smuggling attack; however, it didn't behave the way other threats do in that the payload stored inside the HTML file was not encrypted inside an archive.

Instead, the file was encrypted within the JavaScript code itself, using the Advanced Encryption Standard (AES) and implementing it without making any mistakes. This meant that for researchers to decrypt the file, they needed the correct password.

Related:How Should CISOs Navigate the SEC Cybersecurity and Disclosure Rules?

Eventually, the research team brute-forced the correct password to the file and found that the decrypted archive contained a VBScript file that, when run, starts an infection chain that ultimately deploys the AsyncRAT. "The VBScript writes various variables to the Windows Registry, which are reused later in the chain," according to the report.

Part of that infection chain is the drop of a JavaScript file into the user directory that then reads a PowerShell script from the registry and injects it into a newly started PowerShell process. The PowerShell script then makes use of the other registry variables, and runs two more executables, which start the malware payload after injecting it into a legitimate process.

**Unpacking GenAI-Generated Scripts**

It was through a deeper analysis of both the VBScript and the JavaScript used in the infection chain that the researchers noticed that the code was not obfuscated, which seemed odd because code obfuscation is something attackers typically use to cover their tracks.

"In fact, the attacker had left comments throughout the code, describing what each line does — even for simple functions," according to the report. "Genuine code comments in malware are rare because attackers want to their make malware as difficult to understand as possible."

Related:Cybersecurity Success Hinges on Full Organizational Support, New CompTIA Report Asserts

This behavior and the scripts' structure, consistent comments for each function, and the choice of function names and variables, made it reasonably clear that the attacker used GenAI to develop the scripts, according to HP Wolf Security.

Now that threat actors are starting to harness GenAI in their attack strategies, defenders also should integrate the technology into their security posture to fight fire with fire. Organizations can use GenAI to recognize patterns of threats to identify unauthorized access or malicious intent before attackers have a chance to infiltrate an environment. Indeed, the same efficiencies that GenAI create in an attack flow for malicious actors also can be leveraged by defenders to make their jobs easier, the security researchers said.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

GenAI Writes Malicious Code to Spread AsyncRAT

Who needs advanced malware when you can take advantage of a bunch of OSS tools and free cloud services to compromise your target?

Source: National Picture Library via Alamy Stock Photo

A threat actor is leveraging Cloudflare Worker cloud services and other tools to perform espionage against government and law enforcement targets in and around the Indian subcontinent.

"SloppyLemming" is an advanced persistent threat (APT) that Crowdstrike (tracking it as Outrider Tiger) has previously linked to India. That attribution rings consistent with the group's latest effort to steal valuable intelligence from a wide range of sensitive organizations in countries hugging India's borders.

Among its victims: government agencies — legislative bodies, foreign affairs, defense — IT and telecommunications providers, construction companies, and Pakistan's sole nuclear power facility. Pakistani police departments and other law enforcement came under particular fire, but SloppyLemming's attacks also spread to the Bangladeshi and Sri Lankan militaries and governments, as well as organizations in China's energy and academic sectors, and there have been hints of potential targeting in or around Australia's capital, Canberra.

The campaign, described in a new blog post from Cloudflare, employs Discord, Dropbox, GitHub, and most notably Cloudflare's own "Workers" platform together in phishing attack chains that end in credential harvesting and email compromise.

**Hackers Using Cloudflare Workers**

SloppyLemming attacks generally begin with a spear-phishing email — say, a fake maintenance alert from a police station's IT department. It distinguishes itself more in step two when it abuses Cloudflare's Workers service.

Cloudflare Workers are a serverless computing platform for running scripts that operate on Web traffic flowing through Cloudflare's global servers. They're essentially chunks of JavaScript that intercept requests made to a user's website in transit — before they reach the user's origin server and apply some sort of function to them, for example, redirecting links or adding security headers.

Like other flexible, multifunctional legitimate services, Cloudflare Workers can also be abused for malicious ends. In 2020, Korean hackers used Workers to perform SEO spam, and a backdoor called "BlackWater" used it to interface with its command-and-control (C2) server; the following year, attackers used it to facilitate a cryptocurrency scam.

SloppyLemming uses a custom-built tool called "CloudPhish" to handle credential logging logic and exfiltration. CloudPhish users first define their targets, and their intended channel for exfiltration. Then the program scrapes the HTML content associated with the target's webmail login page, and creates a malicious copycat with it. When the target enters their login information, it's stolen via a Discord webhook.

**Abusing Cloud Services**

SloppyLemming has other tricks up its sleeve, too. In limited cases, it used a malicious Worker to collect Google OAuth tokens.

Another Worker was used to redirect to a Dropbox URL, where lay a RAR file designed to exploit CVE-2023-38831, a "high" severity, 7.8 out of 10 CVSS-rated issue in WinRAR versions prior to 6.23. The same vulnerability was recently used by a Russian threat group against Ukrainian citizens. At the end of this Dropbox-heavy exploit chain was a remote access tool (RAT) that engaged several more Workers.

"They use at least three, or four, or five different cloud tools," notes Blake Darché, head of Cloudforce One at Cloudflare. "Threat actors generally are trying to take advantage of companies by using different services from different companies, so \[victims\] can't coordinate what they're doing."

To make sense of attack chains that spread across so many platforms, he says, "You've got to have good control of your network, and implement zero-trust architectures so you understand what's going in and out of your network, through all the different peripheries: DNS traffic, email traffic, Web traffic, understanding it in totality. I think a lot of organizations really struggle in this area."

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

'SloppyLemming' APT Abuses Cloudflare Service in Pakistan Attacks

The latest draft version of NIST's password guidelines simplifies password management best practices and eliminates those that did not promote stronger security.

Source: Vitalii Vodolazskyi via Shutterstock

The National Institute of Standards and Technology (NIST) is no longer recommending using a mixture of character types in passwords or regularly changing passwords.

NIST's second public draft version of its password guidelines (SP 800-63-4) outlines technical requirements as well as recommended best practices for password management and authentication. The latest guidelines instruct credential service providers (CSP) to stop requiring users to set passwords that use specific types or characters or mandating periodic password changes (commonly every 60 or 90 days). Also, CSPs were instructed to stop using knowledge-based authentication or security questions when selecting passwords.

Other recommendations include:

*   CSPs shall require passwords to be minimum of eight characters in length and should require passwords to be a minimum of 15 characters in length.
    
*   CSPs should allow passwords of a maximum of at least 64 characters.
    
*   CSPs should allow ASCII and Unicode characters to be included in passwords.
    

When NIST first introduced its password recommendations (NIST 800-63B) in 2017, it recommended complexity: passwords comprising a mix of uppercase and lowercase letters, numbers, and special characters. However, complex passwords are not always strong (i.e., "Password123!" or "q1@We3$Rt5"). And complexity meant users were making their passwords predictable and easy to guess, writing them down in easy-to-find places, or reusing them across accounts. In recent years, NIST has shifted its focus to password length, since longer passwords are harder to crack with brute-force attacks and can be easier for users to remember without being predictable.

NIST also is now recommending password resets in the case of a credential breach only. Making people change passwords frequently has resulted in people choosing weaker passwords. When passwords are sufficiently long and random, and there's no evidence of a breach, making users change it could potentially lead to weaker security.

The difference with this draft is the shift in language. Previous versions used the words "should not" while this draft says "shall not," which means the rule has moved from a suggestion to an actual requirement.

*   Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords and
    
*   Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
    

Public comment on this draft (via email \[email protected\]) is open until 11:59 pm Eastern Time on Oct. 7.

**About the Author**

Dark Reading

The Edge is Dark Reading's home for features, threat data and in-depth perspectives on cybersecurity.

NIST Drops Password Complexity, Mandatory Reset Rules

The company said the rogue update that caused disruptions on a global scale resulted from a "perfect storm" of issues.

Source: wisely via Shutterstock

A contrite CrowdStrike executive this week described the company's faulty July 19 content configuration update that crashed 8.5 million Windows systems worldwide as resulting from a "perfect storm" of issues that have since been addressed.

Testifying before members of the House Committee on Homeland Security on Sept. 24, CrowdStrike's senior vice president, Adam Meyers, apologized for the incident and reassured the committee of steps the company has implemented since then to prevent a similar failure.

The House Committee called for the hearing in July after a CrowdStrike content configuration update for the company's Falcon Sensor caused millions of Windows systems to crash, triggering widespread and lengthy service disruptions for businesses, government agencies, and critical infrastructure organizations worldwide. Some have pegged losses to affected organizations from the incident to be in the billions of dollars.

**Chess Game Gone Awry**

When asked to explain the root cause for the incident, Meyers told the House Committee that the problem stemmed from a mismatch between what the Falcon sensor expected and what the content configuration update actually contained.

Essentially, the update caused Falcon Sensor to try and follow a threat detection configuration for which there were no corresponding rules on what to do. "If you think about a chessboard \[and\] trying to move a chess piece to someplace where's there's no square," Meyers said. "That's effectively what happened inside the sensor. This was kind of a perfect storm of issues."

CrowdStrike's validation and testing processes for content configuration updates did not catch the issue because this specific scenario had not occurred before, Meyers explained.

Rep. Morgan Luttrell of Texas characterized CrowdStrike's failure to spot the buggy update as a "very large miss," especially for a company with a large presence in government and critical infrastructure sectors. "You mentioned North Korea, China, and Iran \[and other\] outside actors are trying to get us every day," Luttrell said during the hearing. "We shot ourselves in the foot inside of the house," with the faulty update. Luttrell demanded to know what preventive measures CrowdStrike has implemented since July.

In his written testimony and responses to questions from committee members, Meyers listed several changes that CrowdStrike has implemented to prevent against a similar lapse. The measures include new validation and testing processes, more control for customers over how and when they receive updates, and a phased rollout process that enables CrowdStrike to quickly reverse an update if problems surface. Following the incident, CrowdStrike has also begun treating all content updates as code, meaning they receive the same level of scrutiny and testing as code updates.

**Multiple Changes**

"Since July 19, 2024, we have implemented multiple enhancements to our deployment processes to make them more robust and help prevent recurrence of such an incident — without compromising our ability to protect customers against rapidly-evolving cyber threats," Meyers said in written testimony.

Meyers defended the need for companies like CrowdStrike to be able to continue making updates at the kernel level of the operating system when committee members probed him about the potential risks associated with the practice. "I would suggest that while things can be conducted in user mode, from a security perspective, kernel visibility is certainly critical," he stated. In its root cause analysis of the incident, CrowdStrike noted that considerable work still needs to happen within the Windows ecosystem for security vendors to be able to issue updates directly to user space instead of the Windows kernel.

**Missing the Bigger Picture?**

But some viewed the hearing as not going far enough to identify and focus on some of the more significant takeaways from the incident. "To think of the July 19 outage as a CrowdStrike failure is simply wrong," says Jim Taylor, chief product and technology officer at RSA. "More than 8 million devices failed, and it's not CrowdStrike's fault that those didn't have backups built to withstand an outage, or that the Microsoft systems they were running couldn't default to on-premises backups," he notes.

The global outage was the result of organizations for years abdicating responsibility for building resilient systems and instead relying on a limited number of cloud vendors to carry out critical business functions. "Focusing on one company misses the forest for the trees," Meyers says. "I wish the hearing had done more to ask what organizations are doing to build resilient systems capable of withstanding an outage."

Grant Leonard, chief information security officer (CISO) of Lumifi, says one shortcoming of the hearing was overemphasis on the root cause of the outage and relatively less focus on lessons learned. "Questions about CrowdStrike's decision-making process during the crisis, their communication strategies with affected clients, and their plans for preventing similar incidents in the future would have provided more actionable insights for the industry," Leonard says. "Exploring these areas could help other companies improve their incident response protocols and quality assurance processes."

Leonard expects the hearing will result in a renewed emphasis on quality assurance processes across the cybersecurity industry. "We will likely see an uptick in solid reviews and trial runs of business continuity and disaster recovery plans," he says. The incident could also lead to a more cautious approach to auto-updates and patching across the industry, with companies implementing more rigorous testing protocols. "Additionally, it could prompt a reevaluation of liability and indemnity clauses in cybersecurity service contracts, potentially shifting the balance of responsibility between vendors and clients."

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

Source

DARKReading