Autocompleted code is convenient and quick, but it may expose your organization to security and compliance risks.

In recent months, we've marveled at the quality of computer-generated faces, cat pictures, videos, essays, and even art. Artificial intelligence (AI) and machine learning (ML) have also quietly slipped into software development, with tools like GitHub Copilot, Tabnine, Polycode, and others taking the logical next step of putting existing code autocomplete functionality on AI steroids. Unlike cat pics, though, the origin, quality, and security of application code can have wide-reaching implications — and at least for security, research shows that the risk is real.

Prior academic research has already shown that GitHub Copilot often generates code with security vulnerabilities. More recently, hands-on analysis from Invicti security engineer Kadir Arslan showed that insecure code suggestions are still the rule rather than the exception with Copilot. Arslan found that suggestions for many common tasks included only the absolute bare bones, often taking the most basic and least secure route, and that accepting them without modification could result in functional but vulnerable applications.

A tool like Copilot is (by design) autocompletion turned up a notch, trained on open source code to suggest snippets that could be relevant in a similar context. This makes the quality and security of suggestions closely tied to the quality and security of the training set. So the bigger questions are not about Copilot or any other specific tool but about AI-generated software code in general.

It's reasonable to assume Copilot is only the tip of the spear and that similar generators will become commonplace in the years ahead. This means we, the technology industry, need to start asking how such code is being generated, how it's used, and who will take responsibility when things go wrong.

**Satnav Syndrome**

Traditional code autocompletion that looks up function definitions to complete function names and remind you what arguments you need is a massive time-saver. Because these suggestions are merely a shortcut to looking up the docs for yourself, we've learned to implicitly trust whatever the IDE suggests. Once an AI-powered tool comes in, its suggestions are no longer guaranteed to be correct — but they still feel friendly and trustworthy, so they are more likely to be accepted.

Especially for less experienced developers, the convenience of getting a free block of code encourages a shift of mindset from, "Is this code close enough to what I would write" to, "How can I tweak this code so it works for me."

GitHub very clearly states that Copilot suggestions should always be carefully analyzed, reviewed, and tested, but human nature dictates that even subpar code will occasionally make it into production. It's a bit like driving while looking more at your GPS than the road.

**Supply Chain Security Issues**

The Log4j security crisis has moved software supply chain security and, specifically, open source security into the limelight, with a recent White House memo on secure software development and a new bill on improving open source security. With these and other initiatives, having any open source code in your applications could soon need to be written into a software bill of materials (SBOM), which is only possible if you knowingly include a specific dependency. Software composition analysis (SCA) tools also rely on that knowledge to detect and flag outdated or vulnerable open source components.

But what if your application includes AI-generated code that, ultimately, originates from an open source training set? Theoretically, if even one substantial suggestion is identical to existing code and accepted as-is, you could have open source code in your software but not in your SBOM. This could lead to compliance issues, not to mention the potential for liability if the code turns out to be insecure and results in a breach — and SCA won't help you, as it can only find vulnerable dependencies, not vulnerabilities in your own code.

**Licensing and Attribution Pitfalls**

Continuing that train of thought, to use open source code, you need to comply with its licensing terms. Depending on the specific open source license, you will at least need to provide attribution or sometimes release your own code as open source. Some licenses forbid commercial use altogether. Whatever the license, you need to know where the code came from and how it's licensed.

Again, what if you have AI-generated code in your application that happens to be identical to existing open source code? If you had an audit, would it find that you are using code without the required attribution? Or maybe you need to open source some of your commercial code to remain compliant? Perhaps that's not yet a realistic risk with current tools, but these are the kind of questions we should all be asking today, not in 10 years' time. (And to be clear, GitHub Copilot does have an optional filter to block suggestions that match existing code to minimize supply chain risks.)

**Deeper Security Implications**

Going back to security, an AI/ML model is only as good (and as bad) as its training set. We've seen that in the past — for example, in cases of face recognition algorithms showing racial biases because of the data they were trained on. So if we have research showing that a code generator frequently produces suggestions with no consideration for security, we can infer that this is what its learning set (i.e., publicly available code) was like. And what if insecure AI-generated code then feeds back into that code base? Can the suggestions ever be secure?

The security questions don't stop there. If AI-based code generators gain popularity and start to account for a meaningful proportion of new code, it's likely somebody will try to attack them. It's already possible to fool AI image recognition by poisoning its learning set. Sooner or later, malicious actors will try to put uniquely vulnerable code in public repositories in the hope that it comes up in suggestions and eventually ends up in a production application, opening it up to an easy attack.

And what about monoculture? If multiple applications end up using the same highly vulnerable suggestion, whatever its origin, we could be looking at vulnerability epidemics or maybe even AI-specific vulnerabilities.

**Keeping an Eye on AI**

Some of these scenarios may seem far-fetched today, but they are all things that we in the tech industry need to discuss. Again, GitHub Copilot is in the spotlight only because it currently leads the way, and GitHub provides clear warnings about the caveats of AI-generated suggestions. As with autocomplete on your phone or route suggestions in your satnav, they are only hints to make our lives easier, and it's up to us to take them or leave them.

With their potential to exponentially improve development efficiency, AI-based code generators are likely to become a permanent part of the software world. In terms of application security, though, this is yet another source of potentially vulnerable code that needs to pass rigorous security testing before being allowed into production. We're looking at a brand new way to slip vulnerabilities (and potentially unchecked dependencies) directly into your first-party code, so it makes sense to treat AI-augmented codebases as untrusted until tested — and that means testing everything as often as you can.

Even relatively transparent ML solutions like Copilot already raise some legal and ethical questions, not to mention security concerns. But just imagine that one day, some new tool starts generating code that works perfectly and passes security tests, except for one tiny detail: Nobody knows how it works. That's when it’s time to panic.

Are We Ready for AI-Generated Code?

Testing is an ongoing mission, not a one-and-done fix.

Cybersecurity must evolve beyond reactively handling breaches and pivoting to protect an organization's data after the fact. Without proper precautions, cybercriminals from all over the world can easily take advantage of vulnerabilities within a company's Web applications, mobile applications, APIs, and more. Penetration testing, also known as pen testing, is a method of cybersecurity in which an expert plays the role of a malicious actor to expose the holes and flaws within a security infrastructure or codebase. 

Pen testing is primarily facilitated by dedicated pen testers — some hired internally and others externally through an agency or freelance service. My six years at Cobalt have taught me new, unique, and hidden best practices. It's my ongoing mission and commitment to spread my knowledge and lessons with other security executives to enhance organizations' protection efforts.

**What Is the Goal of Pen Testing?**

Simply put, penetration testing is when a dedicated group of cybersecurity professionals simulate different cyberattacks on an application or network to test for potential vulnerabilities. The goal is to improve the security posture of an organization and discover easily exploitable vulnerabilities within a security system so the company can proactively fix them. Bugs are bound to occur, but being aware of where vulnerabilities lie can polish your product and tighten up your security. 

While many companies invest heavily in building up their infrastructure, the majority of the steps needed to protect investments happen _after_ deployment. Thus, companies are left with a reactive response in place, addressing breaches and attacks on their network once it's too late. Given the fact that cyberattacks have the potential to ripple both internally and externally, leaders must take a proactive approach to cybersecurity, developing at-the-ready responses to squash incoming threats as they appear.

The merits of pen testing come into the limelight once organizations recognize the cycle of destruction caused by cyberattacks. This cycle entails more than the data potentially stolen. It involves the time not only to address the initial vulnerability but to recover and secure any data that could have been potentially stolen. Needless time and resources are spent cleaning up the mess, rather than developing new code. A cycle develops wherein an organization launches new code into their network, an unforeseen vulnerability shows up, and the team has to scramble to fix the issue before it grows even larger. By taking the necessary steps before the new code goes into production, companies can remove themselves from this vicious circle of destruction.

According to Cobalt's "State of Pentesting Report 2021," pen testing can be a time-consuming task. In fact, 55% of organizations said it takes weeks to get a pen test scheduled, with 22% saying it takes months. Modern pen testing practices use both automated tools and skilled manual testers to ensure maximum security in an efficient and timely fashion. Staying agile in your organization's cybersecurity practices will help cut down on the amount of time it takes to schedule the proper precautions.

**What Are the Outside Benefits?**

Pen testing has benefits outside of just vulnerability identification. Code often is dependent on other code, so frequent pen testing allows for new code to be tested before it's deployed into the live build, thus streamlining the development process and lowering development costs. Frequent pen testing also provides more timely results, enabling teams to be at the ready for emerging threats — compared with the standard annual pen test, where developers won't be aware of vulnerabilities for months on end. 

In 2021, many security professionals had to quickly respond to the Log4j threat, but those who frequently pen tested were prepared to patch the exploitable vulnerabilities it caused. Due to the insight these developers obtained from previous pen tests, future code will become more secure, and engineers will learn from mistakes when developing future versions of their products. The more often these pen tests happen, the more compliant your products and code will become.

**When to Schedule a Pen Test**

The best time to schedule a pen test is — of course — before an attack occurs. While we cannot predict exactly when a breach will come, staying proactive and regularly testing and retesting vulnerabilities can save the company from a vicious cyberattack. Organizations can use pen testing to prepare new products, updates, and tools for customer or employee use, all while staying compliant and secure. But for those products to safely go into the hands of the intended audience, they need to be tested.

Proactivity starts with internally evaluating where vulnerabilities already exist within a security system. If discovered early, these vulnerabilities can be dealt with before they take on a life of their own — ultimately saving the company's reputation. Take note of all of the assets your team has (websites, servers, live code, etc.), and set a clear plan for exposure detection. Once your team is clear on the future strategy and practices, your pen testers can begin identifying and exposing the vulnerabilities that may be in your company's resources. Once the test is concluded, developers can start remediating any discovered vulnerabilities.

The important takeaway here is, these tests should not be performed on a one-and-done basis. Pen tests must be executed regularly to ensure security remains up to date with modern breaching methods. Cybersecurity changes (and becomes more complex) each day, forcing organizations to be ready for what's to come at a moment's notice.

How Routine Pen Testing Can Reveal the Unseen Flaws in Your Cybersecurity Posture

BatLoader has spread rapidly to roost in systems globally, tailoring payloads to its victims.

A dangerous new malware loader with features for determining whether it's on a business system or a personal computer has begun rapidly infecting systems worldwide over the past few months.

Researchers at VMware Carbon Black are tracking the threat, dubbed BatLoader, and say its operators are using the dropper to distribute a variety of malware tools including a banking Trojan, an information stealer, and the Cobalt Strike post-exploit toolkit on victim systems. The threat actor's tactic has been to host the malware on compromised websites and lure users to those sites using search engine optimization (SEO) poisoning methods.

**Living Off the Land**

BatLoader relies heavily on batch and PowerShell scripts to gain an initial foothold on a victim machine and to download other malware onto it. This has made the campaign hard to detect and block, especially in the early stages, analysts from VMware Carbon Black's managed detection and response (MDR) team said in a report released on Nov. 14.

VMware said its Carbon Black MDR team had observed 43 successful infections in the last 90 days, in addition to numerous other unsuccessful attempts where a victim downloaded the initial infection file but did not execute it. Nine of the victims were organizations in the business services sector, seven were financial services companies, and five were in manufacturing. Other victims included organizations in the education, retail, IT, and healthcare sectors.

On Nov. 9, eSentire said its threat-hunting team had observed BatLoader's operator luring victims to websites masquerading as download pages for popular business software such as LogMeIn, Zoom, TeamViewer, and AnyDesk. The threat actor distributed links to these websites via ads that showed up prominently in search engine results when users searched for any of these software products.

The security vendor said that in one late October incident, an eSentire customer arrived at a fake LogMeIn download page and downloaded a Windows installer that, among other things, profiles the system and uses the information to retrieve a second-stage payload.

"What makes BatLoader interesting is that it has logic built into it that determines if the victim computer is a personal computer or a corporate computer," says Keegan Keplinger, research and reporting lead with eSentire’s TRU research team. "It then drops the type of malware appropriate for the situation."

**Selective Payload Delivery**

For example, if BatLoader hits a personal computer, it downloads Ursnif banking malware and the Vidar information stealer. If it hits a domain-joined or corporate computer, it downloads Cobalt Strike and the Syncro remote monitoring and management tool, in addition to the banking Trojan and information stealer.

"If BatLoader lands on a personal computer, it will proceed with fraud, infostealing, and banking-based payloads like Ursnif," Keegan says. "If BatLoader detects that it's in an organizational environment, it will proceed with intrusion tools like Cobalt Strike and Syncro."

Keegan says eSentire has observed "a lot" of recent cyberattacks involving BatLoader. Most of the attacks are opportunistic and hit anyone looking for trusted and popular free software tools. 

"To get in front of organizations, BatLoader leverages poisoned ads so that when employees look for trusted free software, like LogMeIn and Zoom, they instead land on sites controlled by attackers, delivering BatLoader."

**Overlaps With Conti, ZLoader**

VMware Carbon Black said that while there are several aspects of the BatLoader campaign that are unique, there are also several attributes of the attack chain that have a resemblance with the Conti ransomware operation. 

The overlaps include an IP address that the Conti group used in a campaign leveraging the Log4j vulnerability, and the use of a remote management tool called Atera that Conti has used in previous operations. 

In addition to the similarities with Conti, BatLoader also has several overlaps with Zloader, a banking Trojan that appears derived from the Zeus banking Trojan of the early 2000s, the security vendor said. The biggest similarities there include the use of SEO poisoning to lure victims to malware-laden websites, the use of Windows Installer for establishing an initial foothold and the use of PowerShell, batch scripts, and other native OS binaries during the attack chain.

Mandiant was the first to report on BatLoader. In a blog post in February, the security vendor reported observing a threat actor using "free productivity apps installation" and "free software development tools installation" themes as SEO keywords to lure users to download sites. 

"This initial BatLoader compromise was the beginning of a multi-stage infection chain that provides the attackers with a foothold inside the target organization," Mandiant said. The attackers used every stage to set up the next phase of the attack chain using tools such as PowerShell, Msiexec.exe, and Mshta.exe to evade detection.

Researchers Sound Alarm on Dangerous BatLoader Malware Dropper

AppSec engineer keynote says Log4j revealed lessons were not learned from the Equifax breach

Adam Bannister 14 November 2022 at 16:16 UTC  
Updated: 14 November 2022 at 16:54 UTC

AppSec engineer keynote says Log4j revealed lessons were not learned from the Equifax breach

Shutting the proverbial back door to your networks “cuts the risks \[of attacks\] down tremendously”, said application security engineer Sean Wright at Friday’s All Day DevOps.

The keynote speaker urged security teams to have “appropriate access controls in place” in order to protect themselves against a 742% rise in ‘next generation’ supply chain attacks, a threat that has mushroomed since the SolarWinds incident rocked the open source ecosystem in December 2020.

Among other techniques, attackers are leveraging typosquatting, dependancy confusion, malicious code injections, vulnerabilities within packages, protestware, and takeovers of package author accounts (the latter prompting package managers to implement multi-factor authentication (MFA)).

RELATED Researchers find 633% increase in cyber-attacks aimed at open source repositories

“Make sure that your servers are really well defined \[in terms of\] what and who they can speak to”, said Wright, who re-recorded his virtual keynote presentation after technical hiccups cut his live appearance short.

“Your servers should never, never ever have open outbound access”, Wright advised.

Many modern supply chain attacks “leverage the fact that many organizations do filter things coming in, but they never pay any attention to what’s going out”, added Wright.

**Swimming upstream**

The dramatic increase in the size of the open source ecosystem has persuaded attackers to diversify beyond attacking applications to targeting their upstream components too, he noted. If anything, Wright was surprised they did not do this sooner and at greater scale.

For context, his own research indicated that between 2015 and 2022 there had been trillions of download requests across various package managers, with Java downloads soaring 3,870%, JavaScript rising 13,900%, and .NET jumping 34,100%.

When a typical app has 20-30 dependencies, which themselves will often have 5-10 dependencies with something like 10,000 lines of code each, finding vulnerabilities is not so much a ‘needle in a haystack’ problem but a “needle in an open ocean” challenge, according to Wright.

AppSec engineer Sean Wright demonstrates dramatic growth in the open source ecosystem

Resources such as Google’s Open Source Insights are therefore invaluable. This “awesome” tool builds dependency graphs for open source packages, and annotates them with ownership, license, popularity, and other metadata.

Wright also recommended using Dependancy Track for a centralized view of your software bills of materials (SBOMs).

When a vulnerability surfaces, he advised security teams to pay attention to the vector more than the severity score, since the CVSS rating often changes as understanding of a bug deepens.

**Purge your build system**

The former software developer warned that, while package managers are quick to remove rogue packages from public repos, their use of caching means developers should “purge” their private repos and local build systems.

He praised a raft of recent initiatives around bolstering the software supply chain – SLSA, Sigstore Cosign, NIST guidance, and OSSF Security Scorecards – but despite these resources there remains much work to do.

Read more of the latest software supply chain attack news

After all, the critical Log4j bug showed that organizations had failed to heed the lesson offered by the Apache Struts bug that thrashed Equifax’s reputation in 2017 – “we’re finding 33% of downloads are still the vulnerable version”, he lamented.

“You wouldn’t typically allow any random stranger to commit code to your codebase,” Wright concluded. “But when we’re pulling down packages from random developers that’s exactly what we’re doing.”

All Day DevOps is a 24-hour software developer-focused conference. Presentations are still available to view on demand.

DON’T MISS Passport-SAML auth bypass triggers fix of critical, upstream XMLDOM bug

All Day DevOps: Third of Log4j downloads still pull vulnerable version despite threat of supply chain attacks

Technology consolidates Windows and Linux software risk together in one UI, helping teams manage vulnerabilities and comply with new regulatory standards.

**BE’ER SHEVA, Israel, (November 9, 2022) —** Rezilion, an automated software security platform, announced today the expansion of its Dynamic Software Bill of Materials (SBOM) capability to support Windows environments. Through this expansion, Rezilion will provide organizations with a first-of-its-kind toolset to efficiently manage software vulnerabilities and meet new regulatory standards, for the 56% of software today that’s built for Windows OS.

“We are seeing a widespread interest in adopting SBOMs as many organizations realize that their future security, risk, and compliance posture relies heavily on the need to see into their software supply chain,” said Liran Tancman, CEO, Rezilion. “A Dynamic SBOM that supports Windows environments widens the scope of possibility and gives the ability to a massive number of new customers to meet regulatory standards and detect and manage their software vulnerabilities strategically.”

While many tools exist for organizations to manage vulnerabilities in their software, the vast majority of these were initially built for use with Linux OS, resulting in gaps in functionality when they’re used for Windows. A dearth of “Windows-first” tooling also affects organizations’ preparedness to comply with new regulations such as the President’s Executive Order (EO) 14028, which will require teams to provide regulators with a thorough inventory of their software environments and related vulnerabilities.The market has been alarmingly slow to respond to this increasingly urgent need for better solutions. As evidence of this, Microsoft itself released its first, basic, open source “Windows-first” SBOM generation tool as recently as July of this year.

As a result of these gaps, for organizations with large, legacy Windows environments (including critical infrastructures), a new threat on the scale of the “Y2K” scare of the late 1990’s is emerging. Be it attackers or regulators, these organizations must modernize their security standards, or suffer consequences of looming risks ahead.

First released in May, Rezilion’s Dynamic SBOM can be deployed in all software environments – both Windows and Linux simultaneously – and provides a real-time versus static inventory of all software components in a single graphical UI. Rezilion’s solution also integrates dynamic runtime analysis to not only detect software vulnerabilities, but validate their actual exploitability, helping teams to clear away “false-positive” scan results and avoid wasteful patching work that shifts resources away from build activity.

Other key features and capabilities include:

*   **Dynamic Identification** – Instantly search and pinpoint vulnerable components such as Log4J across millions of files and on thousands of hosts, containers, and applications.
*   **Holistic Insight & Control** – View Windows and Linux risk side by side in one UI, to get a complete picture of your attack surface, manage risk efficiently and comply with auditors
*   **Tackle Legacy Vulnerability Backlogs Efficiently** – Aggregate detected vulnerabilities, filter out false-positives and prioritize what matters to address risks quickly and meet modern remediation SLAs as defined by CISA with a fraction of the effort

Learn more about Rezilion’s Dynamic SBOM at https://www.rezilion.com/platform/dynamic-sbom/.

Book a demo today to learn more about Rezilion’s Windows software security solutions a https://www.rezilion.com/lp/windows-security-demo/.

**About Rezilion**

Rezilion’s platform automatically secures the software you deliver to customers. Rezilion’s continuous runtime analysis detects vulnerable software components on any layer of the software stack and determines their exploitability, filtering out up to 95% of identified vulnerabilities. Rezilion then automatically mitigates exploitable vulnerabilities across the SDLC, reducing vulnerability backlogs and remediation timelines from months to hours while giving DevOps teams time to build.

Rezilion Expands Dynamic SBOM Capability to Support Windows Environments

Long-awaited security fixes for ProxyNotShell and Mark of the Web bypasses are part of a glut of actively exploited zero-day vulnerabilities and other critical flaws that admins need to prioritize in the coming hours.

Microsoft finally patched the publicly known "ProxyNotShell" and Mark of the Web (MotW) security vulnerabilities in its penultimate monthly security update for 2022 — two of six zero-day bugs under active exploit in the wild.

The targeted zero-days are part of a tranche of 68 security fixes for November's Patch Tuesday group, 11 of which are rated critical.

The fixes address CVEs that affect the gamut of the security giant's product line, including Azure, BitLocker, Dynamics, Exchange Server, Office and Office components, Network Policy Server (NPS), SharePoint Server, SysInternals, Visual Studio, Windows and Windows Components, and the Linux kernel and other open source software bugs affecting Microsoft products.

**Actively Exploited Zero-Day Vulnerabilities**

The group of zero-days listed as under active attack is the largest for Microsoft so far this year.

Two of them are the critical ProxyNotShell flaws affecting Exchange Server, first disclosed in September. Both carry a CVSS vulnerability-severity score rating of 8.8 out of 10. The bug tracked as CVE-2022-41040 is a server-side request forgery (SSRF) flaw that enables attackers to elevate privileges on a compromised system, and CVE-2022-41082 is a remote code execution (RCE) flaw when PowerShell is remotely accessible to the attacker. They can be chained together for full "pwning" of an Exchange Server.

"At long last, Microsoft released patches for the ProxyNotShell vulnerabilities that are being actively exploited by Chinese threat actors," Automox researcher Preetham Gurram said in a Nov. 8 analysis. "The elevation of privilege and remote code execution vulnerabilities have been exposed and exploited since late September, so we recommend applying patches within 24 hours if you have vulnerable on-prem or hybrid Exchange Servers where temporary mitigation has not been applied."

Microsoft also addressed the known and analyzed Mark of the Web issues — they're being tracked as CVE-2022-41091 and CVE-2022-41049, two separate vulnerabilities that exist in different versions of Windows. The important-rated bugs both allow attackers to sneak malicious attachments and files past Microsoft's MotW security feature — Microsoft says only the former is being exploited in the wild. 

Another zero-day being used in active campaigns is a critical RCE bug affecting Windows Scripting Languages (CVE-2022-41128, CVSS 8.8). Mike Walters, vice president of vulnerability and threat research at Action1, tells Dark Reading that it specifically affects the JScript9 scripting language, which is Microsoft’s legacy JavaScript dialect, used by the Internet Explorer browser.

"The new zero-day vulnerability … as low complexity, uses the network vector, and requires no privilege to use, but it needs user interaction, such as using a phishing email to convince the victim to visit a malicious server share or website," he explains. "It affects all Windows OS versions starting from Windows 7 and Windows Server 2008 R2. … However, the proof-of-concept has not yet been publicly disclosed."

The remaining two bugs are important-rated elevation of privilege (EoP) issues carrying 7.8 CVSS scores. One is a memory bug that affects Microsoft's next-gen cryptography, the Windows CNG Key Isolation Service (CVE-2022-41125).

"With low privileges required and a local attack vector, this vulnerability does not necessitate any user interaction. Instead, an attacker would have to gain execution privileges on the victim’s device and run a specially crafted application to elevate privileges to exploit this vulnerability," Automox researcher Gina Geisel said in an emailed analysis. "With a long list of Windows 10 and 11 affected (in addition to Win 8.0, 7.0, Server 2008, 2012, 2016, 2019, 2022, and 2022 Azure), this vulnerability exposes industry-leading versions of Windows and could have wide-ranging impacts."

The second exists in Windows Print Spooler (CVE-2022-41073), and Action1's Walters describes it as a relative of last year's PrintNightmare bug.

"Microsoft continues to patch minions of the PrintNightmare vulnerability," he says. "This vulnerability has a local vector through which an attacker can gain system rights on the target server or desktop."

**Critical Bugs of Note for November**

Other issues in November's update that admins should prioritize include a vulnerability in Windows Kerberos RC4-HMAC (CVE-2022-37966). It earns a critical rating (CVSS 8.1), even though an attacker needs to have access and the ability to run code on the target system to exploit it.

That's likely because Kerberos is an authentication protocol to verify a user or the host's identity, noted Automox's Gurram. It provides a token that enables a service to act on behalf of its client when connecting to other services; when used within an organization's domain, it enables single sign-on (SSO).

"The primary encryption type used in Windows is based on the RC4 stream cipher, with an MD5-HMAC algorithm used for the checksum field," Gurram said. "RC4 encryption is considered to be the least secure and most attackable encryption algorithm. If being used for encrypting Kerberos tokens in the Active Directory domain, it can be exploited and take full control of any service accounts."

ZDI's Dustin Childs noted in a blog post that for this bug and another critical-rated issue in Kerberos tracked as CVE-2022-37967 (CVSS 7.2), admins will need to take additional actions beyond just applying the patch.

"Specifically, you’ll need to review KB5020805 and KB5021131 to see the changes made and next steps," he advised. "Microsoft notes this is a phased rollout of fixes, so look for additional updates to further impact the Kerberos functionality."

Childs also flagged three critical-rated fixes for the Point-to-Point Tunneling Protocol (PPTP), all carrying CVSS scores of 8.1, and all allowing RCE (CVE-2022-41039, CVE-2022-41088, and CVE-2022-41044).

"There seems to be a continuing trend of researchers looking for (and finding) bugs in older protocols," Childs said. "If you rely on PPTP, you should really consider upgrading to something more modern."

The remaining critical bugs are as follows:

*   CVE-2022-38015: A denial-of-service (DoS) bug in Hyper-V (CVSS 6.5), which Microsoft said "could allow a Hyper-V guest to affect the functionality of the Hyper-V host.”
*   CVE-2022-41118: An RCE bug affecting the Chakra and Jscript scripting languages (CVSS 7.5)
*   CVE-2022-39327: An Azure CLI RCE bug (no CVSS) — a previously released fix that is just being documented now.

**Patch ASAP**

Even though this month's update is relatively light, admins should get to patching ASAP, according to Bharat Jogi, director of vulnerability and threat research at Qualys — especially with so many zero-day exploits circulating.

"As we approach the holiday season, security teams must be on high alert and increasingly vigilant, as attackers typically ramp up activity during this time (e.g., Log4j, SolarWinds, etc.)," he said in emailed commentary. "It is likely we will see bad actors attempting to take advantage of disclosed zero-days and vulnerabilities released that organizations have left unpatched."

Microsoft Quashes Bevy of Actively Exploited Zero-Days for November Patch Tuesday

Retailers and hospitality companies expect to battle credential harvesting, phishing, bots, and various malware variants.

For companies in the retail and hospitality sector, the holiday shopping season represents their busiest time of year, both for sales and fighting cybercrime threats.

This year is no different, with companies in the sector anticipating that phishing, fraud, credential harvesting, and the ever-evolving malware landscape will cast a shadow over their security posture in the coming months, according to a report published by Retail & Hospitality Information Sharing and Analysis Center (RH-ISAC) this week.

The 2022 RH-ISAC Holiday Season Threat Trends Summary report polled analysts and members of the industry group about what their security focus is this season — which is defined as the time between Oct. 1 and Dec. 31, when people tend to do their online shopping for holidays that are celebrated in much of the world — as well as what they experienced in the previous 2020 and 2021 holiday seasons. RH-ISAC associate member Flashpoint also provided research and data for the report.

While many threats plaguing the sector have remained consistent over the years, others are evolving rapidly as threat actors develop new malware and exploit fresh vulnerabilities, posing new issues and requiring both reinforcement and change in defense tactics with each season.

**Phishing and Credential Theft**

Retailers cited recurring threats as their biggest worries this year, with phishing — which the organizations noted is a year-round concern — a significant worry that remains consistent. In 2020, nearly 20% of retailers said phishing was the most frequently shared threat among their member exchange, Slack, and the core member listserv boards, while the number was 16% in 2021, according to the report.

Indeed, the holiday season tends to bring a host of socially engineered promotional campaigns aimed at fooling account holders to harvest their credentials and perform other nefarious activities, organizations noted.

Of more concern than phishing, however, is what is often a result of that threat activity: credential harvesting, which 42% and 37% say was the most-shared threat in 2020 and 2021, respectively. Retailers also worry about a rise by threat actors in the use  of info-stealers that harvest customer data purchase don hacker forums, as well as customer account takeover that typically ramps up over the holidays.

Other types of fraud involving gift cards and loyalty cards — with the former allowing threat actors to remain anonymous and thus difficult to track while shopping — will be a focus this year, as well as fraud related to returning items that were not purchased legitimately.

**Evolving Malware Landscape**

The report outlined year-over-year changes between 2020 and 2021 in retail threats linked to malware, bots, and vulnerabilities — results that demonstrate just how quickly this threat landscape in particular can evolve.

Some of these threats, such as QakBot, Emotet, Agent Tesla, and Dridex — remain a constant worry. However, others — such as Log4Shell — emerge quickly and predictably, forcing organizations to pivot in terms of defense, researchers found.

Bots in particular have risen in profile in terms of their impact on online retailers, especially over the past two years, as individuals who otherwise participate in no criminal activity began exploring ways to earn additional income as resellers of stolen information on threat actor forums, according to the report.

"These 'side hustles' support an already thriving ecosystem wherein actors have been scalping high-demand products to sell at high markups," according to the report. "The use of automation to support this activity causes significant negative side effects on the back end and can even lead to DDoS-like disruptions."

Year-over-year changes in malware and bot activity reflect how quickly this threat landscape in particular can change. For example, in 2020, the Emotet banking Trojan and its loader were the top malware threats shared by retailers — 15% and 8%, respectively — while the remote access trojan (RAT) AgentTesla earned 4% of overall mentions.

In 2021, however, AgentTesla rose to greater prominence, with 16% of mentions by retailers, while Emotet virtually disappeared from message boards, respondents said. Moreover, the now infamous Log4j debacle emerged as a threat, with 16% of mentions by retail and hospitality companies.

Retailers say they expect the most prevalent malware and bot activity this holiday season to come from QakBot, Emotet, Agent Tesla, and Dridex, according to the report.

Changes in threat activity so far this year include an increase in imposter websites, and emerging phishing attempts that are either product-focused or impersonated executives. The latter reflects a rise in socially engineered attacks that aimed to harvest credentials and bypass multifactor authentication, retailers say.

**Retail and Hospitality Defenses**

Because of the diversity of the threats the retail and hospitality sector expects to see during the holiday shopping season, the defense tactics they plan to adopt this year also are varied and must encompass both a macro and micro approach to understanding their enemies, they reported.

"Members reported focusing on understanding very specific tactics fraudsters and threat actors are using across kill chains to enhance detection and mitigation efforts," according to the report. "Understanding broad trends across the threat landscape and how they work within member environments has enabled analysts to create more effective alerting, detection, and mitigation efforts."

One tactic they are adopting is to work closely with their respective customer service departments, in part by providing customer service representatives with threat training. They also are maintaining brand protection services to help take down malicious imposter sites, as well as instituting internal fraud working groups to counter threats.

Staffing-wise, retailers and hospitality vendors cite consistency as key, with the need to ensure that those working directly to spot threats have the appropriate experience and knowledge to respond. The companies say they could implement change freezes, staffing adjustments, or other operational changes to prepare for the season, including an improvement in endpoint detection and red team operations to validate threat concerns and highlight areas for improvement, according to the report.

Among the tools and practices the companies find particularly helpful for shoring up security over the holidays: leading vendor threat intelligence platforms and cyber threat intelligence feeds; RH-ISAC community resources and sharing platforms; updated policies and plans; and partnerships with leading cybersecurity associations and nonprofit organizations for additional threat research context.

Retail Sector Prepares for Annual Holiday Cybercrime Onslaught

TA569 has modified the JavaScript of a legitimate content and advertising engine used by news affiliates, in order to spread the FakeUpdates initial access framework.

The cyber-threat threat actor known as TA569, or SocGholish, has compromised JavaScript code used by a media content provider in order to spread the FakeUpdates malware to major media outlets across the US.

According to a series of tweets from the Proofpoint Threat Research Team posted late Wednesday, the attackers have tampered with the codebase of an application that the unnamed company uses to serve video and advertising to national and regional newspaper websites. The supply chain attack is being used to spread TA569's custom malware, which is typically employed to establish an initial access network for follow-on attacks and ransomware delivery.

Detection might be tricky, the researchers warned: "TA569 historically removed and reinstated these malicious JS injects on a rotating basis," according to one of the tweets. "Therefore the presence of the payload and malicious content can vary from hour to hour and shouldn't be considered a false positive."

More than 250 regional and national newspaper sites have accessed the malicious JavaScript, with impacted media organizations serving cities such as Boston, Chicago, Cincinnati, Miami, New York, Palm Beach, and Washington, DC, according to Proofpoint. However, only the impacted media content company knows the full range of the attack and its impact on affiliate sites, the researchers said.

The tweets cited Proofpoint threat detection analyst Dusty Miller, senior security researcher Kyle Eaton, and senior threat researcher Andrew Northern for the discovery and investigation of the attack.

**Historical Links to Evil Corp**

FakeUpdates is an initial access malware and attack framework in use since at least 2020 (but potentially earlier), that in the past has used drive-by downloads masquerading as software updates to propagate. It previously has been linked to activity by the suspected Russian cybercrime group Evil Corp, which has been formally sanctioned by the US government.

The operators typically host a malicious website that executes a drive-by download mechanism — such as JavaScript code injections or URL redirections — which in turn triggers the download of an archive file that contains malware.

Symantec researchers previously observed Evil Corp using the malware as part of an attack sequence to download WastedLocker, then a new ransomware strain, on target networks back in July 2020.

A surge of drive-by download attacks that used the framework followed toward the end of that year, with the attackers hosting malicious downloads by leveraging iFrames to serve up compromised websites via a legitimate site.

More recently, researchers tied a threat campaign distributing FakeUpdates through existing infections of the Raspberry Robin USB-based worm, a move that signified a link between the Russian cybercriminal group and the worm, which acts as a loader for other malware.

**How to Approach the Supply Chain Threat**

The campaign discovered by Proofpoint is yet another example of attackers using the software supply chain to infect code that's shared across multiple platforms, to broaden the impact of malicious attack without having to work any harder.

Indeed, there already have been numerous examples of the ripple effect these attacks can have, with the now infamous SolarWinds and Log4J scenarios being among the most prominent.

The former started in late December 2020 with a breach in the SolarWinds Orion software and spread deep into the next year, with multiple attacks across various organizations. The latter saga unfolded in early December 2021, with the discovery of a flaw dubbed Log4Shell in a widely used Java logging tool. That spurred multiple exploits and made millions of applications vulnerable to attack, many of which remain unpatched today.

Supply chain attacks have become so prevalent that security administrators are looking for guidance about how to prevent and mitigate them, which both the public and private sector have been happy to offer.

Following an executive order issued by President Biden last year directing government agencies to improve the security and integrity of the software supply chain, the National Institute for Standards and Technology (NIST) earlier this year updated its cybersecurity guidance for addressing software supply chain risk. The publication includes tailored sets of suggested security controls for various stakeholders, such as cybersecurity specialists, risk managers, systems engineers, and procurement officials.

Security professionals also have offered organizations advice on how to better secure the supply chain, recommending that they take a zero-trust approach to security, monitor third-party partners more than any other entity in an environment, and choose one supplier for software needs that offers frequent code updates.

Supply Chain Attack Pushes Out Malware to More than 250 Media Websites

Frauscher Sensortechnik GmbH FDS102 for FAdC R2 and FAdCi R2 v2.8.0 to v2.9.1 are vulnerable to malicious code upload without authentication by using the configuration upload function. This could lead to a complete compromise of the FDS102 device.

    

Safety & Security

Frauscher PSIRT

We at Frauscher stand for safety in rail transport and individual solutions for our customers. That is why we have introduced a process for security-relevant topics, which helps us to react as quickly as possible to alleged security risks. We work according to a comprehensive approach to secure our products, services and individual solutions. 

For this purpose, we have established our **Product Security Incident Response Team (PSIRT)**. You can reach our experts via the contact options listed at the bottom of the page.

**How does it work?**

**

Reporting

**

When you report a potential security risk to our experts, you will receive a confirmation from our Product Security Incident Response Team after a careful review.

**

Expert analysis

**

The potential risk will be analysed closely by our experts. If desired, you will receive regular status reports on the progress of the analysis.

**

Implementation

**

In this step, any necessary immediate measures are implemented, and long-term measures are planned.

**

Publication

**

The publication of the results and measures will be available on this page.

**Security Advisory**

****Frauscher Diagnostic System FDS102 for FAdC**® **R2 and FAdCi R2 configuration upload vulnerability****

Publication Date: 28.10.2022

CVE-ID: CVE-2022-3575  
CVSS v3.1 Base Score: 9.8  
CVSS v3.1 Overall Score: 5.9  
CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C/CR:X/IR:X/AR:X/MAV:A/MAC:X/MPR:X/MUI:X/MS:X/MC:L/MI:L/MA:L  
CWE-ID: CWE-434

****Summary****

*   FDS102 for FAdC® R2 and FAdCi R2 v2.8.0 to v2.9.1 are vulnerable to malicious code upload without authentication by using the configuration upload function. This could lead to a complete compromise of the FDS102 device.

****Affected versions:****

*   v2.8.0, v2.9.0, v2.9.1

****Remediation****

*   Update to v2.9.2 or higher

**Log4j Vulnerability CVE-2021-44228**

Published: 15.12.2021

**Summary**

*   **None of our Axle Counters and Wheel Sensors are affected** (e.g. FAdC®, ACS2000, RSR110, RSR123, RSR180, ...).
*   **None of our diagnostic products are affected** (e.g. FDS, RMD, ASD, ...).

**Contact Frauscher PSIRT**

You can contact our experts directly with all security-related questions and comments about our products and solutions. You are also welcome to report potential security risks or problems via this channel. Our experts will get back to you as soon as possible.

CVE-2022-3575: Frauscher PSIRT

Containers and their supporting infrastructure are too important to ignore.

How will threat actors attack and utilize containers? This is a question I constantly think about. I've been working in this area for more than two decades now, and I feel like I should have an answer. But I don't.

Instead, I have a lot of different ideas, none of which I can really pinpoint as correct. Part of this indecision is because of all the time I spent learning security in the "legacy" world. Containers do not really have an analog. Sure, virtual machines (VMs) are often conflated with containers, but they were never able to scale like containers. They are also used for completely different purposes than containers. It's taken a while to adjust my thinking and understand where containers actually fit into the attack surface.

The public examples of attacks against containerized environments are very limited. The breaches almost always are cryptomining related, which are serious attacks, but the incident responder in me finds them underwhelming. Another commonality is they are mostly the result of a misconfiguration, whether that be in Kubernetes or a cloud account. The combination of the motives and the tactics have not been very inspiring so far.

**The Old Way**

Remote code execution (RCE) vulnerabilities have been the main concern in computer security for a long time. They are still, but how does this way of thinking apply to containers? It's easy to immediately jump to RCE as the primary threat, but it doesn't seem to be the right way to approach containers. For one thing, containers are often very short lived – 44% of containers live less than five minutes – so an intruder would have to be quick.

This approach also assumes that the container is exposed to the Internet. Certainly some containers are set up this way, but they often are very simple and use well-tested technologies, like NGINX. There may be zero-days out for these applications, but they would be extremely valuable and hard to come by. My experience has shown me that a lot of containers are used internally and don't connect directly to the Internet. The RCE scenario gets a lot more difficult in that case. I should mention Log4j, though these sorts of vulnerabilities have the potential of being exploited remotely even if the vulnerable system isn't on the edge.

**The New Way**

If RCE isn't the biggest threat facing containers, then what is? Are containers even on the radar of threat actors? Yes, containers and their supporting infrastructure are too important to ignore. Container orchestration software has allowed containerized workloads to be scaled to unimaginable numbers. The usage trend is also increasing, so you can be sure they will be a target. They just can't be thought of like servers you get at through RCE vulnerabilities.

Instead, the reverse is actually true. Instead of attacking containers from the outside in, they need to be attacked from the inside out. This is essentially what supply chain attacks do. Supply chain is an extremely effective attack vector against containers when you start to understand how they are built. A container starts with a definition file, such as Dockerfile, which defines everything that will be in the container when it runs. It is turned into an image once built, and that image is what may be spun up into a workload an innumerable amount of times. If anything in that definition file is compromised, then every single workload that runs is compromised.

Containers are often, but not always, purpose-built with an application that does something and exits. These applications can be almost anything — the important thing to understand is how much is built using libraries, either closed source or open source, written by other people. GitHub has millions of projects, and that's not the only repository of code out there. As we saw with SolarWinds, closed source is vulnerable to supply chain attacks as well.

A supply chain attack is a great way for threat actors to get into a target's container environment. They can even let the customer's infrastructure scale their attack for them if the compromise goes unnoticed. This type of scenario is already playing itself out, as we saw with the Codecov breach. But it is difficult to detect due to how new all of this is and how our thinking is still rooted in the problems of the past.

**A Way Forward**

As with fixing most problems, visibility is usually a great place to start. It's hard to fix what you can't see. To secure your containers you need to have visibility into the containers themselves, as well as the whole pipeline that builds them. Vulnerability management is one type of visibility that must be integrated into the build pipeline. I would also include other static analysis tools, such as ones that look for leaked secrets to that as well. Since what a supply chain attack looks like can't really be predicted, runtime monitoring becomes critical so you know exactly what your containers are doing.

Tag

#log4j