Jump to content
  • SeedTheNet
  • SeedTheNet
    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.

    SeedTheNet
    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

    SeedTheNet
    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
     

    SeedTheNet
    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

    SeedTheNet
    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

    SeedTheNet
    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

    SeedTheNet
    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." 

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

    SeedTheNet
    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

    SeedTheNet
    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!

    SeedTheNet
    Authors
    Maher Yamout A reboot a day can keep the fuckers away
    Introduction
    In the ever-evolving landscape of mobile security, hunting for malware in the iOS ecosystem is akin to navigating a labyrinth with invisible walls. Imagine having a digital compass that not only guides you through this maze, but also reveals the hidden mechanisms of iOS malware previously shrouded in mystery. This is not a tool – this is the nature of digital forensic artifacts. In this blog post, we’ll explore one particular forensic artifact that stands out for uncovering some of the most elusive malware on iOS devices and shedding more light on the traces left by the sophisticated threats endangering the trusted companions in our pockets.
    In 2021 and 2022, we had the privilege of working on a few Pegasus malware infections on several iPhone devices. The iPhones were Initially given to us by our partners for general security checks before we discovered the infections.
    Investigating such cases can be complicated, costly, or time consuming due to the nature of the iOS ecosystem. As a result, related threats can often go undetected by the general public. To date, the common methods for analyzing an iOS mobile infection are either to examine an encrypted full iOS backup, or to analyze the network traffic of the device in question. Both methods, however, are time consuming or require a high level of expertise, which limits their use.
    Through our analysis, we discovered that the infections left traces in an unexpected system log, Shutdown.log, which is a system log file available on any mobile iOS device. Since the detection method was consistent across several infections we’ve analyzed, we thought we would dissect and understand this log file in more detail, as it could be used as another method to detect mobile malware.
    Overview of an iOS artifact: Shutdown.log
    Shutdown.log is a text-based log file created on iOS devices. Each reboot event is logged in this file along with multiple environment characteristics. Having looked at dozens of these log files, they can have entries going back several years, which can provide a wealth of information.
    When a user initiates a reboot, the operating system attempts to gracefully terminate running processes before rebooting. If a “client” process is still running when the reboot activity begins, it is logged with its process identifier (PID) and corresponding filesystem path. The log entry notes that these processes prevented a normal reboot and that the system is waiting for them to terminate. A UNIX timestamp is provided for the system event indicating that memory buffers are flushed in preparation for a full OS shutdown.
    Sample snippet from an iOS Shutdown.log file
    Compared to more time-consuming acquisition methods like forensic device imaging or a full iOS backup, retrieving the Shutdown.log file is rather straightforward. The log file is stored in a sysdiagnose (sysdiag) archive.
    Sysdiag can be thought of as a collection of system logs and databases that can be generated for debugging and troubleshooting purposes. The method for generating a sysdiag may differ from one iOS version to another. Nevertheless, this archive can be found in the OS general settings, specifically under “Privacy and Analytics”, although again the exact location name may differ between iOS versions.
    The archive is created relatively quickly, typically taking only a few minutes. The result is a .tar.gz file about 200-400MB in size. This file can then be transferred to the analysis machine. Once the archive is unpacked, the Shutdown.log file is located within the “\system_logs.logarchive\Extra” directory.
    Malware detections and lessons learned
    When we first started analyzing the supposedly infected phones, we tested them with the MVT tool developed by Amnesty International. At the time, MVT identified malware indicators by parsing the DataUsage database, among other forensic artifacts.
    Because mobile malware was becoming more prevalent, and detection methods were time consuming, we looked for a faster and easier method. While network traffic analysis can be a very effective lightweight method for identifying a potential iPhone infection, processing network traffic can require a high level of expertise and resources. Sysdiag dump analysis is a minimally intrusive and a resource-light method of identifying possible iPhone infections using system-based artifacts. It can serve to supplement infection identification from a different vantage point.
    If we take a sample log file for a spin, it shows a known Pegasus infection trace under “/private/var/db/com.apple.xpc.roleaccountd.staging/rolexd”.
    Sample infection trace in a Shutdown.log entry
    Having received the infection indicator in this log and confirmed the infection using MVT’s processing of other iOS artifacts, this log now becomes part of a holistic approach to investigating the infection. Since we confirmed the consistency of this behavior with the other Pegasus infections we analyzed, we believe it will serve as a reliable forensic artifact to support infection analysis.
    While analyzing the various infections, we made several observations. One of the infected phones had infection indicators in the usual artifacts such as the DataUsage database, but there were no traces in the Shutdown.log. Further analysis revealed that the user didn’t reboot on the day of the infection. This observation makes sense, since Shutdown.log only records entries upon reboot.
    Another interesting observation we made on another infected phone is that occasionally, when there’s a “sticky” process preventing a reboot such as the processes related to Pegasus, the log file will also record a notification indicating that a reboot was delayed; we’ve observed Pegasus-related processes in more than four reboot delay notices. While we did see instances of non-infected phones with two to three reboot delay notices, we consider excessive delays (more than four) to be another log anomaly that needs to be investigated.
    As we continued researching sysdiag archives and Shutdown.log, we read up on CitizenLab’s analysis of Reign and spotted something we had seen before: the malware’s path.
    Reign malware path in iOS filesystem, identified by CitizenLab
    Comparing the Shutdown.log for the Pegasus infections we analyzed and the artifacts for the Reign path above, we noticed other similarities with such infections. Malware execution originating from “/private/var/db/” seems to be consistent across all the infections we’ve seen, even if the process names are different. This is also true for another mobile malware family, Predator, where a similar path, “/private/var/tmp/”, is often used.
    Since all three malware families were using a similar filesystem path, and since we confirmed from the Pegasus infection analysis that such a path can be seen in Shutdown.log, we believe that this log file may be able to help identify infections by these malware families. But there’s a BIG caveat… the user needs to reboot as often as possible. How often, you may ask? Well, it depends! It depends on the user’s threat profile; every few hours, every day, or perhaps around “important events”; we’ll leave this as an open-ended question.
    Analysis scripts
    To automate the analysis process, we’ve created a few Python3 scripts to help extract, analyze and parse the Shutdown.log artifact. As a prerequisite, the user needs to generate a sysdiag dump and extract the archive to the analysis machine.
    Script 1: iShutdown_detect
    The first script is about detecting the anomalies mentioned above, inside the Shutdown.log. The script analyzes the log file in question in the background and displays any of the anomalies. Think of this script as a lightweight method to analyze a forensic artifact for unusual entries. It’s meant to support an investigation, not as a silver bullet.
    The examples below show some of the results you would expect to see:
    “Sticky” processes delaying reboot more than three times
    Detecting an instance of Pegasus indicator
    Detecting an instance of Pegasus indicator with more than three delays for rebooting
    Script 2: iShutdown_parse
    We understand that there are instances where analysts and users want to share their log files and parse them for different purposes. So this script is an attempt to support that need. This script takes a sysdiag archive as an argument and extracts the Shutdown.log file from it. If instructed, it will also convert it to a CSV file, decode the timestamps, and generate a summary of the parsing that includes the source sysdiag and the extracted Shutdown.log hashes.
    Log extraction and parsing output
    Script 3: iShutdown_stats
    The last script can be used for various purposes, such as understanding how often or when a user has rebooted the phone. This script takes into account that you have extracted the log file in question as it takes it, and not the sysdiag archive, as an argument.
    Reboot stats of a target Shutdown.log
    Conclusion
    In conclusion, we’ve analyzed and confirmed the reliability of detecting a Pegasus malware infection using the Shutdown.log artifact stored in a sysdiag archive. The lightweight nature of this method makes it readily available and accessible. Moreover, this log file can store entries for several years, making it a valuable forensic artifact for analyzing and identifying anomalous log entries. Again, this is not a silver bullet that can detect all malware, and this method relies on the user rebooting the phone as often as possible.
    We’ll continue to analyze the Shutdown.log file in more detail and on different platforms. We expect to be able to create more heuristics from the entries in it. We’d love to hear from you if you have any interesting samples that could contribute to this research. As you have seen in this blog, and can even see in your own sysdiag analysis, the Shutdown.log file does not contain any personal information, so feel free to contact us at intelreports@kaspersky.com if you’d like to contribute.
    Source : https://securelist.com/shutdown-log-lightweight-ios-malware-detection-method/111734/

    SeedTheNet
    The Many Faces of Undetected macOS InfoStealers | KeySteal, Atomic & CherryPie Continue to Adapt
    We have been reporting on the rise of infostealers targeting macOS since early last year, but threat actors show no signs of slowing down. Throughout last year, we saw variants of Atomic Stealer, macOS MetaStealer, RealStealer and others.
    Recent updates to macOS’s XProtect signature database indicate that Apple are aware of the problem, but early 2024 has already seen a number of stealer families evade known signatures.
    In this post, we provide details on three active infostealers that are currently evading many static signature detection engines. We provide a high-level overview of each along with relevant indicators to aid threat hunters and defenders.

    KeySteal | Jumping on the AI Bandwagon
    First noted in 2021, the internals of KeySteal have changed markedly since it was first described by Trend Micro. Apple added a signature almost a year ago to XProtect in v2166 (Feb 2023), but this no longer detects current versions, some of which are distributed as a binary named “ChatGPT”.
    A recent sample of KeySteal uses the name ‘ChatGPT’ for its executable
    Initially, KeySteal was distributed in .pkg format with an embedded macOS utility called “ReSignTool” – a legitimate open-source application for signing and bundling apps into .ipa files for distribution on iOS devices.
    The malware authors modified the code to steal Keychain information and to drop persistence components in the following locations:
    /Library/LaunchDaemons/com.apple.googlechrome.plist ~/Library/LaunchAgents/com.apple.googleserver.plist The latest round of KeySteal samples have changed considerably. They no longer leverage the ReSign tool and instead appear in multi-architecture Mach-O binaries with names such as “UnixProject” and “ChatGPT”. Distribution methods are unclear at this time. Some of the most recent versions undetected by XProtect also enjoy low detection scores on VirusTotal.
    Undetected by XProtect, these KeySteal samples also have low scores on VirusTotal
    Both versions are written in Objective C but the primary methods responsible for the malicious behavior have changed from JKEncrypt in the early versions to UUnixMain, KCenterModity, and ICenterModity in the most recent versions.
    One factor in common between the early and current iterations of KeySteal is the hardcoded C2, and threat hunters and static detections will still have some luck pivoting off that.
    usa[.]4jrb7xn8rxsn8o4lghk7lx6vnvnvazva[.]com However, it is quite unusual for threat actors not to rotate C2 addresses, and we would encourage defenders to develop better hunting and detection rules to detect KeySteal in advance of an inevitable change.
    KeySteal samples that we have observed are signed with an ad hoc code signature with artifacts suggesting the binary was built in Xcode, Apple’s development IDE.
    KeySteal sample with an ad hoc code signature
    Atomic InfoStealer | Multiple Variants Continue to Evade
    We first wrote about Atomic Stealer last year, and since then ourselves and other industry peers have noted a number of changes. Many of these iterations are being seen in the wild concurrently, indicating completely different development chains rather than one core version that is being updated.
    Prior to this writing, Malwarebytes reported on an obfuscated Go version of Atomic Stealer which appeared shortly after Apple’s XProtect update v2178 (Jan 2024). Apple’s update included a detection rule for the version described by MalwareBytes under the rulename SOMA_E.
    However, we have already seen variations appearing since then that are not currently detected by XProtect.
     
    Some of these samples also have low detection scores on VirusTotal at the time of writing.
    The most recent version of Atomic Stealer are not well detected on VirusTotal
    This version of Atomic Stealer is written in C++ and includes logic to prevent the victims, analysts or malware sandboxes from running the Terminal at the same time as the stealer. In addition, it checks to see if the malware is being run inside a Virtual Machine.
    Atomic Stealer closes the Terminal
    Unlike the obfuscated versions from earlier in January, these samples use hard-coded AppleScript in clear text, clearly indicating the malware’s stealing logic.
    Atomic still makes heavy use of hardcoded AppleScript
    Initial distribution is likely through torrents or gaming-focused social media platforms as the malware continues to appear in .dmg form with names such as ‘CrackInstaller’ and ‘Cozy World Launcher’.
    An Atomic Stealer installer instructing the victim to override Gatekeeper control
    CherryPie | Caught by Apple, But Many Static Engines Lagging Behind
    macOS CherryPie was added to XProtect in v2176. Also known as Gary Stealer, AT&T Labs described the same malware as “JaskaGo” in December 2023.
    CherryPie / Gary Stealer 09de6c864737a9999c0e39c1391be81420158877
    While Apple’s XProtect rule continues to remain robust against further samples that we have identified, VirusTotal engines are faring less well in some cases.
    The following sample – first uploaded on 09, Sept 2023 – along with its embedded malware binary, remains undetected on VirusTotal as of today.

    macOS.CherryPie undetected on VirusTotal
     
    CherryPie is a cross-platform Windows/macOS stealer written in Go and containing extensive logic for anti-analysis and VM detection. Despite that, the malware authors have left seemingly obvious strings embedded in the malware to indicate both its purpose (stealer) and its intent (malicious).
    CherryPie contains some rather telling hardcoded strings
    Some versions of CherryPie use the legitimate open-source Wails project to wrap their malicious code into an application bundle.
    CherryPie samples we have observed are signed with an ad hoc signature. As part of the application’s set up it also calls the macOS spctl utility with the --master-disable argument. This code is used to disable Gatekeeper and is run with administrator privileges via sudo.
    macOS.CherryPie attempts to disable Gatekeeper with admin privileges
    SentinelOne Detects macOS InfoStealers
    SentinelOne customers are protected from macOS KeySteal, Atomic InfoStealer, and CherryPie/Gary Stealer.
    With the policy set to ‘Detect-Only’, the SentinelOne agent issues alerts for each of the threats when executed.

    When the policy is set to ‘Protect’ the malicious behaviors are killed without any action needed from the management console.
    Conclusion
    The continued prevalence and adaptation of macOS infostealers like KeySteal, Atomic InfoStealer, and CherryPie underscores the ongoing challenges facing macOS enterprise users. Despite solid efforts by Apple to update its XProtect signature database, these rapidly evolving malware strains continue to evade.
    Given these challenges, it is vital to adopt a comprehensive, defense-in-depth approach. Relying solely on signature-based detection is insufficient as threat actors have the means and motive to adapt at speed. Aside from a modern EDR platform with native macOS capabilities, proactive threat hunting, enhanced detection rules, and awareness of the evolving tactics can help security teams to stay ahead of threats targeting the macOS platform.
    To learn how SentinelOne can help protect the macOS devices in your fleet, contact us or request a free demo.
    Indicators of Compromise
    KeySteal
    95d775b68f841f82521d516b67ccd4541b221d17
    f75a06398811bfbcb46bad8ab8600f98df4b38d4
    usa[.]4jrb7xn8rxsn8o4lghk7lx6vnvnvazva[.]com
    Atomic InfoStealer
    1b90ea41611cf41dbfb2b2912958ccca13421364
    2387336aab3dd21597ad343f7a1dd5aab237f3ae
    8119336341be98fd340644e039de1b8e39211254
    973cab796a4ebcfb0f6e884025f6e57c1c98b901
    b30b01d5743b1b9d96b84ef322469c487c6011c5
    df3dec7cddca02e626ab20228f267ff6caf138ae
    CherryPie
    04cbfa61f2cb8daffd0b2fa58fd980b868f0f951
    09de6c864737a9999c0e39c1391be81420158877
    6a5b603119bf0679c7ce1007acf7815ff2267c9e
    72dfb718d90e8316135912023ab933faf522e78a
    85dd9a80feab6f47ebe08cb3725dea7e3727e58f
    104[.]243[.]38[.]177
     
    https://www.sentinelone.com/blog/the-many-faces-of-undetected-macos-infostealers-keysteal-atomic-cherrypie-continue-to-adapt/
     
     

    SeedTheNet
    Hidden crypto miner in pirated software makes cybercriminals rich at the expense of their victims
    January 15, 2024
    Doctor Web is reporting on an increase in cases of cryptocurrency-mining trojans being found hidden in pirated software that is available in Telegram and on some Internet sites.
    In December 2023, virus analysts at Doctor Web noticed an increase in the detection rates of Trojan.BtcMine.3767 and its companion malware Trojan.BtcMine.2742, which, as it turned out, were ending up on users' computers with pirated software.
    Trojan.BtcMine.3767 is a trojan program for Windows written in C++. It is a crypto-miner loader based on the SilentCryptoMiner project. The platforms used to distribute the infected software packages are the t[.]me/files_f Telegram channel (over 5,000 subscribers) and the itmen[.]software and soft[.]sibnet[.]ru websites. Interestingly, in the latter case the hackers went the extra mile and prepared custom builds using the NSIS installer. After unpacking the installation packages, our analysts discovered the paths used by the attackers to store the trojan's source files:
    C:\bot_sibnet\Resources\softportal\exe\ C:\bot_sibnet\Resources\protect_build\miner\ According to the Dr.Web malware analysis lab, in one of the distribution campaigns the trojan has infected over 40 000 computers in a little less than two months. Considering the number of views in Telegram and website traffic, the scale of the problem may be much larger.
    When launched, the loader copies itself to the %ProgramFiles%\google\chrome\ directory under the name updater.exe and creates a scheduler task so that it can run on startup. To make it look harmless, the task is named GoogleUpdateTaskMachineQC. In addition, the loader adds its file to the Windows Defender exceptions and prevents the computer from shutting down and hibernating. The initial settings are embedded in the trojan and then updated from a remote host. Once initialized, the loader injects Trojan.BtcMine.2742, the payload responsible for hidden cryptocurrency mining, into the explorer.exe process.
    In addition, this loader allows the r77 fileless rootkit to be installed on a compromised computer, Windows updates to be disabled, website access to be blocked, trojan source files to be auto-deleted and -restored, the cryptomining process to be suspended, and the RAM and VRAM occupied by the miner to be unloaded when the computer user runs process-monitoring programs.
    Dr.Web anti-virus successfully detects and neutralizes Trojan.BtcMine.3767 and Trojan.BtcMine.2742, so they do not pose a threat to our users.
    https://news.drweb.com/show/?i=14792&lng=en

    SeedTheNet
    A resident of Mykolaiv infected the server of a well-known American company with a miner virus. In the course of an international police operation, law enforcement officers conducted searches and stopped the activity of the hacker.
    Operatives of the Cyber Police Department and investigators of the Main Investigative Department of the National Police under the procedural guidance of the Prosecutor General's Office together with colleagues from Europol (the EU law enforcement agency for combating international organized crime) exposed the 29-year-old hacker.

    Starting in 2021, the man infected the servers of one of the world's largest e-commerce companies. First, the hacker "hacked" 1,500 accounts of the subsidiary company. For this, the attacker used self-developed software for automatic password selection - the so-called "brutforce".
    Using compromised accounts, the hacker gained access to the management of the service. In the future, the person involved created a computer virus-miner for cryptocurrency mining, which secretly infected the company's server equipment. To ensure the operation of the malicious software, the hacker created more than one million virtual computers.
    It was established that for more than two years of criminal activity, the man withdrew almost two million US dollars in cryptocurrency to controlled electronic wallets, which is equivalent to more than 75 million hryvnias.
     

    With the support of the TOR special unit, law enforcement officers conducted authorized searches in the suspect's premises on the territory of Mykolaiv.
    Computer equipment, bank and SIM cards, electronic media and other evidence of illegal activity were seized.

    On the territory of the Netherlands, Europol established a special working group and a VCP (Virtual Command Point) for the urgent analysis of information received during investigative actions on the territory of Ukraine. Europol provided assistance in blocking the electronic wallets of the person involved with the assets on them.
    Investigators of the Main Investigative Department of the National Police have opened criminal proceedings under Part 5 of Art. 361 (Unauthorized interference in the work of information (automated), electronic communication, information and communication systems, electronic communication networks) of the Criminal Code of Ukraine.
    Investigative actions are ongoing with the aim of establishing possible accomplices of the figure and his involvement in pro-Russian hacker groups. Based on the results, additional qualification is possible.
    Cyber Police Department of the National Police of Ukraine
    Source : https://cyberpolice.gov.ua/news/zavdav-providnij-svitovij-kompaniyi-sotni-miljoniv-zbytkiv-kiberpolicziya-ta-slidchi-naczpolu-vykryly-xakera-2238/
     

×
×
  • Create New...