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.

Where Are All of the Container Breaches?

Linus Torvalds, the creator of Linux and Git, has his own law in software development, and it goes like this: "given enough eyeballs, all bugs are shallow." This phrase puts the finger on the very principle of open source: the more, the merrier - if the code is easily available for anyone and everyone to fix bugs, it's pretty safe. But is it? Or is the saying "all bugs are shallow" only true for

Linus Torvalds, the creator of Linux and Git, has his own law in software development, and it goes like this: "_given enough eyeballs, all bugs are shallow_." This phrase puts the finger on the very principle of open source: the more, the merrier - if the code is easily available for anyone and everyone to fix bugs, it's pretty safe. But is it? Or is the saying "all bugs are shallow" only true for _shallow_ bugs and not ones that lie deeper? It turns out that security flaws in open source can be harder to find than we thought. Emil Wåreus, Head of R&D at Debricked, took it upon himself to look deeper into the community's performance. As the data scientist he is, he, of course, asked the data: _how good is the open source community at finding vulnerabilities in a timely manner_?

****The thrill of the (vulnerability) hunt****

Finding open source vulnerabilities is typically done by the maintainers of the open source project, users, auditors, or external security researchers. But despite these great code-archaeologists helping secure our world, the community still struggles to find security flaws.

On average, it takes _over 800 days_ to discover a security flaw in open source projects. For instance, the infamous Log4shell (CVE-2021-44228) vulnerability was undiscovered for a whopping 2649 days.

The analysis shows that 74% of security flaws are actually undiscovered for at least one year! Java and Ruby seem to have the most challenges here, as it takes the community more than 1000 days to find and disclose vulnerabilities. Our \[white\] hats go off to the PHP/Composer community, which slightly outperforms the others.

****The needle in a techstack****

Other interesting factors are that some of the different weakness types (CWE) seem to be harder to find and disclose, which actually contradicts Linus's law. The weakness types CWE-400 (Uncontrolled Resource Consumption) and CWE-502 (Deserialization of Untrusted Data) typically aren't localized to a single function or may appear as intended logic in the application. In other words, it can't be considered "a shallow bug."

It also seems that the developer community is a bit better at finding CWE-20 (Improper Input Validation), where the flaw most of the time is just a few lines of code in a single function.

****Solve vulnerabilities with powerful remediation****

Why does this matter? As consumers of open source, and that's about every company in the whole world, the problem of vulnerabilities in open source is an important one. The data tells us that we can't fully trust Linus' Law - not because open source is less secure than other software, but because **not all bugs are shallow**.

Luckily, there are powerful tools to perform at-scale analysis of a lot of open source projects at once. There have been \[white knight hackers disclose 1000's\] of vulnerabilities at once using these methods. It would be naive to not assume that ill-minded organizations and individuals do the same. As an ecosystem that lays the foundation for our software-centric world, the community must improve its ability to find, disclose, and fix security flaws in open source significantly.

Last year, Google committed $10 billion to an open source fund to help secure open source with a specific curator role to work alongside the maintainers with specific security efforts.

Furthermore, Debricked helps companies make these vulnerabilities actionable by scanning all your software, every branch, every push, and every commit, for new (open source) vulnerabilities. Debricked even continuously scans all your old commits for every new vulnerability, to make sure they bring up-to-date, accurate, and actionable intelligence on the open source you consume. Debricked even helps developers fix your security flaws with automated pull requests that won't cause dependency hell; pretty neat!

**The truth lies in the data**

So, knowing all this, what is the best way to protect your project or company against open source vulnerabilities? As we've seen in the case of Log4j and Spring4shell as well as the numbers, we can never really trust that the community will find and fix all risks. There's a good chance that there are lots and lots of undiscovered and undisclosed vulnerabilities in your code today, and there's not much you can do about it.

According to Debricked, the best way to mitigate this is by implementing continuous vulnerability scanning to your SDLC. By automatically scanning at every push of code, in combination with the machine learning-powered vulnerability database. This makes sure you're updated in real-time, you'll know about new vulnerabilities before anyone else does. As soon as there's a fix, you can generate a Fix Pull Request automatically or solve it manually with Debricked's help. _Currently, Debricked offers remediation for JavaScript and Go, with more language support is to come shortly._

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Last Years Open Source - Tomorrow's Vulnerabilities

At this year’s KubeCon/CloudNativeCon, both development and operations practitioners were tackling different security needs.

As a self-identified movie buff, some movie lines somehow stick with me over the years. One of them is from Ridley Scott's _Gladiator_ (2000), when a Roman senator says, "The beating heart of Rome is not the marble of the Senate, it is the sand of the Colosseum."

That line popped up in my head as I walked around the halls at KubeCon/CloudNativeCon ("KubeCon"), the marquee event for the Cloud Native Computing Foundation (CNCF). To me, the beating heart of cloud-native security is most definitely KubeCon.

This year's North American edition of the event took place last week in Detroit, bringing together thousands of participants on-site plus many others remotely. In addition to the main three-day event, the growing interest in specific projects has led the Cloud Native Computing Foundation to set up various "co-located events" ahead of the main conference.

For the 2022 event, there was not only a specific CloudNativeSecurityCon two-day event but also plenty of security content across other events, including Application Networking Day, EnvoyCon, Policy Day with OPA, ServiceMeshCon, and more, reflecting the wide interest in cloud-native security topics. Interestingly, the CloudNativeSecurityCon event has itself now "graduated" to an independent event to be hosted separately in February.

**Cloud-Native security: Development vs. Operations**

So, where is the current state of cloud-native security conversations? To Omdia, there is a strong bifurcation: development-centric concerns and operations-centric concerns. It is not as helpful to call these "Dev" and "Ops" because team structure is in flux in many organizations: some may have site reliability engineering (SRE) teams, some may call them operations, platform teams, and more.

On the development side of the ledger, three topics of interest are provenance, noise, and exposure.

Provenance asks the fundamental question: Can we trust the integrity of the external component we're incorporating into our software pipeline? While many examples exist, the 2020 SolarWinds attack was a turning point for interest in the integrity of the software supply chain. At KubeCon, there was palpable momentum behind the idea of signing software images: The sigstore project was announced as general availability and is being used by Kubernetes and other key projects.

Noise refers to reducing the number of vulnerabilities that exist in the environment, starting with slimming down the container base images that are being used. This may include using image bases such as Alpine or Debian Slim or considering "distroless" alternatives that are even smaller. The benefit is that these smaller images have minimal footprint and therefore reduced chance of vulnerabilities popping up.

Exposure: For any given vulnerability, how exposed are we as an organization? There is no better example of this in recent industry history than Log4j, of course. This is the realm of discussions on software bills of materials (SBOMs) as it relates to knowing where components may be used either as images sitting in a registry somewhere or running in production. Interestingly, as this essay is being written, there's advance notice that information about critical vulnerabilities in OpenSSL 3.x will be disclosed imminently, which will likely be another good use case for SBOMs — just where is OpenSSL 3.x used in our organization? Given that SBOM coverage is still not widespread, Omdia expects minimal SBOM usage this time around, unfortunately.

Operations teams are naturally focused on providing and operating an increasingly complex underlying platform and doing so securely. The word “platform” is particularly relevant here: There was notable interest in organizing Kubernetes and many of the growing list of CNCF projects (140 as of this writing, between the various stages of project incubation: sandbox, incubation, graduated) into easier-to-consume platforms. Of specific interest to security audiences, projects such as Cilium (using the underlying eBPF functionality) for networking and observability, SPIFFE/SPIRE (for establishing identities), Falco (for runtime security), Open Policy Agent (for policy-as-code), Cloud Custodian (for governance), and others are worth looking into. The expectation is that these projects will increasingly collaborate with "observability" aspects of cloud-native and will also be deployed using practices such as GitOps.

**Reasons for Optimism on Cloud-Native Security**

Where do we go from here? It was abundantly clear that the cloud-native community cares deeply about security and is moving forward full-speed with tackling the many topics around it. The guidance to security teams is to quickly come up to speed on how these different projects and initiatives are being implemented. It's important to note that for many organizations, this will come not in the form of explicitly using the community project (though some will), but rather as part of a packaged platform from vendors such as Red Hat, SUSE, Canonical, and others, or directly from the cloud providers such as AWS, Google Cloud, Azure, Oracle, and others.

Be aware that, in the context of open source usage, there's no such thing as really "free" — even if one chooses to use the vanilla upstream version of projects, there are inherent costs in maintaining those packages and participating in the community development.

Tag

#log4j