McDonald’s AI Chatbot “McHire” Exposes 64 Million Job Applications via Default Credentials

Overview

On June 30, 2025, security researchers uncovered a critical vulnerability in the AI-powered recruitment platform McHire, used by McDonald’s and operated by Paradox.ai. This vulnerability exposed over 64 million job applications, including personal information, chat histories, and authentication tokens, all due to legacy credentials with admin rights.

What Is McHire and Who Is Olivia?

McHire is McDonald’s AI-driven recruitment platform that uses “Olivia,” a virtual assistant developed by Paradox.ai, to interact with applicants. Olivia helps job seekers apply, asks screening questions, and schedules interviews, all automatically.

The platform is used by over 90% of McDonald’s franchises, meaning this vulnerability had massive reach.

But while Olivia sounded friendly, behind the scenes, she was working in an environment lacking the most basic security hygiene.

How Did This Happen?

The story starts with two security researchers, Ian Carroll and Sam Curry, who noticed strange behavior in Olivia’s responses and decided to investigate. Their journey took just 30 minutes:

1. They applied for a job to understand how the system worked
2. They found a staff login portal and guessed common credentials
3. After trying “admin/admin,” they tested “123456/123456”, and gained full admin level access to the platform

From there, they uncovered an API vulnerable to IDOR (Insecure Direct Object Reference). By simply changing the value of a lead_id, they could access any applicant’s data, including:

• Names, email addresses and phone numbers
• Auth tokens that could be used for impersonation

Technical Failures

• Default Admin Credentials – The infamous 123456 password had remained active in production since 2019. There was no MFA, no lockout policy, and no alerting for suspicious logins
  
• Insecure API Design (IDOR) – The backend API used numeric identifiers (lead_id) with no authorization checks. This allowed an attacker to enumerate through millions of records
  
• Lack of Monitoring – There was no evidence the platform had caught this unauthorized access until the researchers disclosed it. highlighting gaps in logging, alerting, and incident response

What Happened After Disclosure?

• On June 30, the researchers responsibly disclosed the issue to Paradox.ai and McDonald’s
• By July 1, the credentials were revoked and the IDOR vulnerability patched
• Paradox.ai announced plans to launch a bug bounty program and improve its security contact process

Why This Matters for AI & NHI Security

Olivia, like many AI systems, is a non-human identity, an autonomous agent operating on behalf of a brand. But unlike human users, NHIs often lack lifecycle governance, credential hygiene, or ownership.

In this case:

• The AI chatbot was handling high volumes of sensitive data
• It was interacting autonomously with users across McDonald’s franchise network
• It was part of a system with privileged backend access but no modern security controls

This incident proves that non-human identities are critical assets in your security model and must be governed, monitored, and protected.

Recommendations

• Scan for hardcoded or default credentials across environments
• Enforce strong password policies and credential rotation
• Use password managers or secret vaults for all credentials
• Assign clear ownership and lifecycle management for every non-human identity
• Implement role-based access control (RBAC) and least privileges for all NHIs
• Encrypt sensitive data both at rest and in transit
• Use short-lived secrets with limited scope and clear expiration policies
• Log all access to sensitive systems, especially from NHIs

Conclusion

The McHire incident highlights how even simple oversights. Like default credentials and insecure APIs can lead to massive data exposure. As AI and automation become central to business operations, securing non-human identities is no longer optional. Governance, visibility and lifecycle controls must apply to every system.

Inside the Scania Data Breach – Lessons in Supply Chain and Identity Security

Overview

On May 28, 2025, Scania, a leading Swedish manufacturer of heavy trucks, buses and a member of the Volkswagen Group, fell victim to a security incident that started quietly but quickly turned into an extortion campaign. Attackers exploited credentials belonging to an external IT partner to gain unauthorized access to Scania’s insurance claims portal, downloading thousands of sensitive documents.

But this wasn’t just another data leak, it became a targeted extortion attempt, with employees directly contacted by the attackers via encrypted email services. This incident adds to the growing wave of breaches that leverage third-party access and stolen credentials as their entry point.

What Happened?

Here’s a breakdown of the timeline and nature of the attack:

• May 28–29 – Attackers used login credentials belonging to an external IT provider to access Scania’s insurance claim management system.
• Data exfiltration – Over 34,000 files and scanned forms were stolen. These likely contain names, ID numbers, addresses, financial details, and medical information tied to vehicle insurance claims.
• May 30 – The threat actors began contacting Scania staff using ProtonMail accounts, threatening to release the data unless their demands were met.

Screenshots of the files appeared on underground forums shortly after, and one attacker offered “exclusive access” to the data in a post signed by “hensi”.

How It Happened?

The attackers used stolen third-party login credentials to access Scania’s insurance system. based on early analysis and threat intel, here’s what likely happened:

• Third-Party Access Exploitation – The attackers exploited stolen credentials not from Scania’s core infrastructure but from a third-party IT supplier managing part of their insurance platform. This highlights the risks existing in supply‑chain security.
  
• Infostealer Malware – Analysis suggests the credentials were probably harvested using Infostealer malware, infostealers often harvest tokens, cookies, and saved credentials from infected machines.
  
• Data Exfiltration – Once in, they exfiltrated insurance claim documents, likely containing sensitive personal, financial, and potentially medical data.
  
• Extortion phase – The attackers escalated from theft to blackmail, aiming to monetize stolen information by pressuring Scania and selling data samples.

Impact

While Scania described the overall business impact as “limited,” the breach raises several concerns:

• Privacy Exposure -Personal, financial, and possibly medical information was part of the 34,000+ files leaked. Even if not “widely” exposed yet, the files are in criminal hands.
  
• Reputational Risk – Scania operates globally and is part of the Volkswagen Group. Any public data mishandling even via a partner can trigger regulatory investigations and erode trust.
  
• Regulatory Fallout – Regulatory bodies may impose fines or compliance mandates, especially if data belonging to EU citizens was impacted.

Recommendations

• Supply-chain hygiene – Enforce strict vendor risk assessments and continuous monitoring for third-party partners.
  
• Monitor for anomalies – Implement real-time detection of unusual data exports and access patterns.
  
• Encrypt sensitive data – Ensure all critical data, especially personal, are encrypted in transit and at rest.
  
• Credential Management – Audit for exposed secrets, deploy credential vaulting, and rotate partner access regularly.

Conclusion

The Scania data breach is an example of how a single compromised partner can open the door to a damaging chain of events. Just one infostealer, one set of stolen credentials, and a trusted connection that was taken for granted.

This incident reminds us that even trusted partners can become security risks if their access isn’t managed carefully. It’s not just about protecting your own systems anymore; it’s about keeping a close eye on how others connect to them.

At the end, breaches like this are preventable. Stronger identity controls, better monitoring, and clear boundaries with vendors can make all the difference.

The Story Behind Deloitte 2025 Breach

Overview

On May 30, 2025, a threat actor using the alias “303” claimed responsibility for a significant cyberattack on Deloitte, one of the world’s leading consulting firms. The attacker alleged that they had accessed and exfiltrated sensitive internal data, including GitHub credentials and proprietary source code from Deloitte’s U.S. consulting division. This breach was reportedly disclosed on a well-known dark web forum.

What Happened?

A threat actor using the alias “303” claimed responsibility for breaching Deloitte’s internal systems. According to their claims later supported by early security analyses, the breach centered around sensitive data belonging to Deloitte’s U.S. consulting division.

What Was Compromised?

The two primary assets compromised in the breach were:

• GitHub Credentials – These credentials, found in public or poorly protected GitHub repositories, potentially allowed unauthorized access to Deloitte’s internal development infrastructure. This includes build environments, CI/CD pipelines, or private repositories used by the consulting arm of the firm.
• Proprietary Source Code – The threat actor allegedly accessed and exfiltrated source code from internal project repositories. This proprietary code could relate to client-facing applications, internal tools, or frameworks developed and maintained by Deloitte’s U.S. consulting division.

How Did It Happen?

While specific technical details of the breach remain undisclosed, the nature of the compromised data suggests potential vulnerabilities in Deloitte’s access controls and credential management practices. The exposure of GitHub credentials indicates that attackers may have exploited weak authentication mechanisms or insufficiently secured repositories.

The leak of proprietary source code raises concerns about the security of Deloitte’s software development lifecycle. Unauthorized access to source code can enable attackers to identify and exploit vulnerabilities, potentially compromising client systems or sensitive data.

Previous Deloitte Breaches

This latest incident highlights an ongoing pattern of cybersecurity challenges for Deloitte. Just recently, in December 2024, Deloitte faced allegations from the Brain Cipher ransomware group, which claimed responsibility for breaching Deloitte UK and stealing over a terabyte of sensitive data. Deloitte addressed these claims by clarifying that the data breach occurred within a client’s isolated system not on Deloitte’s internal networks and asserted that their core systems remained secure.

Additionally, this isn’t the first time Deloitte has dealt with compromised credentials. Back in 2017, security experts uncovered Deloitte’s internal VPN passwords, usernames, and operational information openly accessible within a publicly available GitHub repository, indicating historical challenges in maintaining robust credential management practices.

Possible Impacts of the Deloitte Data Breach

The Deloitte data breach could have substantial repercussions, both immediately and in the long term. Here are the primary areas where the impacts might manifest:

• Compromise of Internal Infrastructure – Exposed GitHub credentials could grant unauthorized access to Deloitte’s internal development environments. Attackers leveraging these credentials might escalate privileges, insert malicious code, or modify existing software, potentially disrupting internal operations and impacting clients who rely on Deloitte’s services.
  
• Exposure of Sensitive Source Code – The theft of proprietary source code poses a critical risk. Attackers with access to the company’s internal codebase can conduct detailed analyses to uncover vulnerabilities, facilitating targeted exploits against Deloitte and potentially against client systems that rely on this software.
  
• Reputational Damage – Repeated cybersecurity incidents can significantly damage Deloitte’s reputation as a trusted global consulting leader. Trust and credibility are important in professional services, and high-profile breaches may erode client confidence and discourage future business partnerships.
  
• Regulatory and Compliance Consequences – Depending on the nature and extent of the leaked data, Deloitte might face regulatory scrutiny and possible sanctions. This breach could trigger investigations under data protection regulations such as GDPR, potentially resulting in substantial fines, mandatory audits, and costly compliance remediation efforts.

Lessons Learned

The Deloitte breach serves as a cautionary tale for organizations worldwide. Key takeaways include:

1. Secure Code Repositories – Ensure that all code repositories are private and access is restricted to authorized personnel.
   
2. Employee Training – Conduct regular cybersecurity awareness training to educate employees about the best practices and emerging threats.
   
3. Regular Audits – Conduct periodic audits of codebases and infrastructure to identify and remediate potential vulnerabilities.
   
4. Adoption of Secret Management Tools – To prevent future leaks, organizations should integrate secrets management solutions that automatically detect and manage secrets.
   
5. Automated Scanning – Utilize tools that automatically scan code repositories for exposed secrets before code is pushed to public platforms.

Conclusion

The 2025 Deloitte breach, if confirmed, highlights the evolving challenges in cybersecurity, especially concerning secrets management in the age of AI, Cloud computing and DevOps. As organizations navigate this complex landscape, proactive measures, continuous monitoring, and a culture of security awareness become important in safeguarding digital assets.

How iOS Apps Are Leaking Secrets and Endangering User Privacy

In March 2025, The mobile world is buzzing after recent research uncovered a shocking truth about iOS apps: many are riddled with secret leaks, and the coding practices behind them are far from secure. With over a billion iPhones in use worldwide, these revelations raise serious concerns about the safety of personal data and the standards upheld by developers.

The Research That Shocked the App World

The researchers analyzed over 156,000 iOS applications, approximately 8% of the Apple App Store’s offerings. The results were staggering, more than 71% of these apps contained at least one hardcoded secret, averaging 5.2 secrets per app. In total, over 815,000 hardcoded secrets were identified, encompassing API keys, cloud storage credentials, and payment processor information. 

The research highlights two key issues:

1. Widespread Secret Leaks – Many apps are unintentionally leaking sensitive information, including authentication tokens, passwords, and private keys, through insecure channels. These leaks often go unnoticed by developers but are a goldmine for hackers.
2. Poor Coding Practices – The research team found that many iOS apps were plagued by poor coding practices, including improper encryption, hard-coded secrets, and insecure data storage. These vulnerabilities leave users exposed to risks such as data breaches, account hijacking, and even identity theft.

Understanding Hardcoded Secrets

Hardcoded secrets refer to sensitive data embedded directly within an application’s source code. This practice is risky because, despite the compiled nature of iOS applications, determined attackers can decompile the apps to retrieve these secrets. Once obtained, these credentials can grant unauthorized access to various services, potentially leading to data breaches, unauthorized transactions, and compromised user privacy.

Commonly Exposed Secrets

The study highlighted several frequently exposed types of sensitive information:

Payment Processor Keys – Hundreds of sensitive keys related to payment processors were discovered, which could be exploited to initiate unauthorized payments or refunds.

Cloud Storage Endpoint – Approximately 83,000 hardcoded cloud storage endpoints were found, with 836 lacking authentication measures, thereby exposing around 406TB of data. ​ 

Firebase Database URLs – Over 51,000 Firebase endpoints were identified, many of which were accessible without proper authentication, posing risks of unauthorized data access. ​ 

API Keys for Third-Party Services – Thousands of keys for services such as Fabric API, Live Branch, and MobApp Creator were exposed, potentially allowing attackers to manipulate app functionalities or access sensitive user data. ​ 

How Could This Happen in 2025?

In a world where digital privacy is increasingly prioritized, how can such sloppy coding practices still be so prevalent? Part of the problem lies in the rush to market. With tight deadlines and high consumer demand, developers often cut corners, overlooking important security checks.

Some apps use outdated libraries, while others rely on open-source code without fully understanding its security implications. Worse, certain app developers might prioritize features and user experience over security, assuming Apple’s robust iOS framework will act as a fail-safe. Unfortunately, that assumption can be dangerously wrong.

Potential Consequences

The implications of this discovery are far-reaching. If you’ve ever used an app to manage your bank accounts, shop online, or even control smart home devices, your sensitive data could be at risk. The leaked secrets could allow cybercriminals to:

• Unauthorized Data Access – Attackers can retrieve personal user information, leading to privacy violations and potential identity theft.​

• Financial Fraud – Exposed payment processor keys can be misused to conduct unauthorized transactions, resulting in financial losses for users and businesses alike.​
• Reputation Damage – Companies found to have such vulnerabilities may suffer reputational harm, leading to decreased user trust and potential loss of business.​
• Regulatory Penalties – Non-compliance with data protection regulations due to such exposures can result in hefty fines and legal repercussions.
• Hijack Accounts – Attackers could use leaked API keys or tokens to access user accounts without their knowledge.

Recommendations

While users are encouraged to protect themselves by keeping apps up to date and being cautious with the permissions they grant, much of the onus falls on developers. To safeguard applications and their users, developers should adopt the following best practices:

1. Secure Coding Practices – Developers must prioritize security in the coding process, ensuring encryption is applied correctly and sensitive data is never hard-coded or exposed in plaintext.
2. Perform Code Audits and Penetration Testing – Regular audits and testing can reveal hidden vulnerabilities before they reach the hands of the public, allowing developers to fix potential problems before they are exploited.
3. Implement Secure Authentication Mechanisms – Ensure that all endpoints, especially those related to cloud storage and databases, are protected with robust authentication and authorization protocols.​
4. Keep Libraries Updated – Many vulnerabilities arise from using outdated libraries or open-source code that has not been properly vetted. Developers must ensure that third-party code is up to date and secure.

Conclusion

This research serves as a stark reminder of the fragility of our digital ecosystem. As mobile users, we put our trust in developers and companies to secure our data, but this trust is easily shattered by weak security measures and poor coding practices. For developers, it’s time to step up. Building secure apps is not just a best practice, it’s a responsibility.

How reviewdog action Exposed Thousands of Secrets?

On March 11, 2025, The reviewdog/action-setup GitHub Action became the focus of a significant supply chain attack. Malicious activity was first detected when researchers observed that the v1 tag of reviewdog/action-setup had been altered between 18:42 and 20:31 UTC, allowing attackers to inject malicious code into the tool. This modification went unnoticed for a short period, but the consequences were immediate and widespread.

Background

GitHub Actions Overview

Before we delve deeper into the attack, it’s essential to understand how GitHub Actions work. GitHub Actions allow developers to automate tasks such as code building, testing, and deployment using pre-configured workflows. Developers often rely on third-party GitHub Actions, like reviewdog, which helps with automated code review by integrating it into continuous integration/continuous deployment (CI/CD) pipelines.

What Happened?

It all began with a seemingly harmless GitHub Action, reviewdog/action-setup, designed to streamline code reviews. Unfortunately, on March 17, this action was compromised by attackers, allowing them to slip malicious code into the heart of workflows that relied on it.

Within just a few hours:

• Developers worldwide saw their CI/CD workflows execute this tampered action, unknowingly giving attackers access to sensitive environment variables.
• This led to widespread secrets leaks, affecting everything from private API keys to Personal Access Tokens (PATs).

The alarming aspect? Most of the victims had no idea their secrets were being exposed until it was too late.

Attack Methodology 

This wasn’t just a simple attack; it a was well-coordinated attack designed to exploit the trust developers place in third-party GitHub Actions. Here’s how the attackers managed to wreak havoc:

1. Malicious Code Injection

The attackers modified the reviewdog/action-setup Action by injecting a Base64-encoded malicious payload into the install.sh script. This script runs during setup and executes commands for the installation of Reviewdog, allowing it to access sensitive environment variables.

Once executed in the CI/CD pipeline, the malicious code would:

• Decode the Base64-encoded payload to reveal a script designed to extract secrets.
• Read environment variables, such as API keys, access tokens, and other confidential data.
• Print or encode this sensitive information in workflow logs, making it publicly accessible.

2. Execution in Workflow

The compromise was stealthy since many workflows used the reviewdog/action-setup@v1 tag, allowing the injected malicious code to execute across many repositories without detection. The attack went unnoticed until security researchers identified the unauthorized changes in the action’s setup script.

3. Compromised Personal Access Token (PAT)

As part of the attack, the tj-actions-bot account’s Personal Access Token (PAT) was compromised, giving attackers the ability to modify downstream actions. This led to the unauthorized modification of repositories using tj-actions/changed-files, further exacerbating the exposure of sensitive credentials.

4. Supply Chain Propagation

The compromise extended to tj-actions/eslint-changed-files and other actions that relied on reviewdog/action-setup. In particular, tj-actions/changed-files, a popular action that detects changed files in pull requests, was compromised as it inherited the malicious setup from reviewdog/action-setup.

Mistakes Made?

1. Usage of Mutable Version Tags

One of the primary vulnerabilities exploited in this attack was the use of mutable version tags (v1), which allowed the attacker to silently introduce malicious code without altering the version number. This practice is common in GitHub workflows but poses a significant risk, as it can allow undetected changes to run in production environments.

2. Weak Token Security

The compromised Personal Access Token (PAT) used by tj-actions-bot highlights the importance of stricter token management. Weak token security allowed the attackers to escalate their privileges and modify repositories, leading to further propagation of the attack.

Impact 

The cascading supply chain attack led to the exposure of CI/CD secrets from over 23,000 repositories in the case of tj-actions/changed-files. Although the reviewdog compromise itself affects a smaller subset (limited to the v1 tag), its role in the chain has significant implications.

Recommendations

Audit and Identify

• Use GitHub search queries or automation tools to identify workflows that reference the affected reviewdog/action-setup@v1 and dependent actions.
• Review CI/CD logs for evidence of the malicious payload (look for double-encoded Base64 strings).

Rotate Compromised Credentials

• Immediately rotate any secrets that might have been exposed, including PATs, AWS keys, and other sensitive tokens.

Remove or Replace Affected Actions

• Stop using the affected actions across all branches not just the main branch, to prevent inadvertent execution.
• Replace references to mutable version tags with pinned commit hashes. This prevents future modifications from going undetected.

Adopt Immutable Versioning

• Always use specific commit SHAs instead of mutable tags (v1, latest). This practice ensures that the exact version of an action is being used and prevents attackers from altering code in previously trusted versions.

Audit Third-Party Actions

• Regular audits of third-party actions should be conducted to ensure that no unauthorized changes have been made. GitHub’s security features, such as Dependabot and CodeQL, should be employed to scan for vulnerabilities.

Conclusion

The reviewdog/action-setup supply chain attack highlights the critical security risks associated with CI/CD pipelines and third-party dependencies. The cascading nature of the attack, where a single compromised action led to a widespread breach, underscores the need for stricter security practices in the GitHub Actions. By taking immediate steps to audit affected workflows, rotate credentials, and improve token security, organizations can mitigate the damage caused by this attack and prevent future incidents.

OmniGPT Breach: 34M Conversations Exposed

In February 2025, a significant data breach involving OmniGPT, a widely-used AI-powered chatbot platform, was reported. A threat actor known as “Gloomer” claimed responsibility for the breach, alleging the exposure of sensitive user information, including email addresses, phone numbers, API keys, and extensive chat logs. This report delves into the specifics of the breach, examines the potential vulnerabilities exploited, assesses the impact, and offers recommendations to prevent similar incidents in the future.

Background on OmniGPT

OmniGPT serves as an AI aggregator, providing users with access to multiple AI models such as ChatGPT-4, Claude 3.5, Gemini, and DeepSeek. The platform integrates seamlessly with various workplace applications, including WhatsApp, Slack, Google Workspace, and Notion, enhancing productivity and collaboration. Its widespread adoption has made it a repository of vast amounts of user-generated content and sensitive data.

Details of the Breach

The breach was first reported on February 11, 2025, when “Gloomer” posted on a notorious platform for illicit data trading. The hacker claimed to have accessed and leaked:

• Personally Identifiable Information (PII) – Approximately 30,000 user email addresses and phone numbers.
• Chat Logs – Over 34 million lines of user conversations with various AI models.
• API Keys and Credentials: Sensitive information potentially allowing unauthorized access to linked services.
• File Links – URLs to files uploaded by users on the platform.

Samples of the leaked data were made available publicly, with the full dataset offered for sale on the dark web. The exposure of such a vast amount of data raises significant concerns about user privacy and platform security.

Cause of the Breach

While the exact method of intrusion remains under investigation, several potential vulnerabilities could have been exploited:

• Inadequate API Security – Weak authentication mechanisms or lack of proper input validation may have allowed unauthorized access to backend systems.
• Insufficient Data Encryption – Storing sensitive data without robust encryption could have made it easier for attackers to extract information.
• Vulnerable Third-Party Integrations – Compromises in integrated services such as Slack, Google Workspace, might have served as entry points.
• Weak Access Controls – Failure to implement the principle of least privilege could have enabled attackers to escalate privileges and access sensitive data.

Impact Assessment

• User Privacy Compromise – Exposure of PII and personal conversations can lead to identity theft, phishing attacks, and other malicious activities.
• Credential Leakage – Access to API keys and other credentials may allow attackers to infiltrate connected services, posing further security risks.
• Reputation Damage – Users may lose confidence in AI platforms’ ability to safeguard their data, potentially leading to decreased adoption and engagement.
• Regulatory Consequences – The breach could draw the attention of data protection authorities, potentially resulting in fines, legal actions, and stricter compliance requirements for OmniGPT.

Recommendations

• API Key Management – Enforce strict controls over API key generation, storage, and usage.
• Input Validation – Implement strict input validation to prevent injection attacks. Ensure that all user inputs are sanitized and validated before processing.
• Regular Security Assessments – Conduct periodic penetration testing and vulnerability assessments to identify and address potential security gaps.
• Robust Data Encryption – Ensure all sensitive data, both at rest and in transit, is encrypted using industry-standard protocols.
• Use Token-Based Authentication – Implement OAuth 2.0, OpenID Connect (OIDC), and JWTs for secure, short-lived API access tokens.
• Database Access Restrictions – Enforce strict role-based access control (RBAC) and least privilege principles.
• Monitor Model Behavior for Anomalies – Deploy monitoring systems that detect unusual AI interactions or unauthorized API queries.
• Vendor Security Assessments – Regularly audit third-party integrations (e.g., Slack, Google Workspace, Notion) for vulnerabilities.

Conclusion The OmniGPT breach serves as a clear example of how poor management of NHIs can lead to devastating consequences. As AI platforms continue to expand and integrate with numerous third-party services, the associated security risks will also grow. Securing NHIs, enforcing stronger access controls, and enhancing monitoring mechanisms are vital to protecting AI systems from such breaches in the future.

Salt Typhoon Used Cisco Flaw & Stolen Credentials to Hack U.S. Telecoms 

In February 2025, Cisco Talos reported that the advanced persistent threat (APT) group known as Salt Typhoon, believed to be linked to China’s Ministry of State Security (MSS) or Guoanbu, managed to infiltrate several U.S. telecommunications networks. Shockingly, some of these intrusions went unnoticed for more than three years. The attackers took advantage of an old but still unpatched vulnerability in Cisco’s Smart Install feature, known as CVE-2018-0171, while also leveraging stolen credentials to deepen their access. Their approach combined stealth and persistence, making detection incredibly difficult until significant damage had already been done.

Background on Salt Typhoon

Salt Typhoon is a highly skilled cyber-espionage group believed to be backed by the Chinese government. Known for their calculated and methodical approach, they invest significant resources into long-term infiltration of targeted networks. Their primary goal is intelligence gathering, with a strong focus on monitoring communications, conducting counterintelligence operations, and extracting sensitive data, particularly from critical infrastructure like telecommunications. Their ability to remain undetected for extended periods makes them a formidable threat in the cybersecurity landscape.

Vulnerability Exploited: CVE-2018-0171

CVE-2018-0171 is a critical vulnerability within Cisco’s Smart Install (SMI) feature, which facilitates the deployment of new switches. The flaw arises from improper validation of packet data, enabling an unauthenticated, remote attacker to trigger a stack-based buffer overflow. Successful exploitation allows the execution of arbitrary code on the affected device, granting the attacker control over the system. Despite the availability of patches since 2018, Salt Typhoon capitalized on unpatched systems within U.S. telecom networks to gain access.

Attack Methodology

1. Initial Access – Salt Typhoon primarily entered targeted networks through two avenues:

• Use of Stolen Credentials – Salt Typhoon obtained legitimate login credentials to access targeted systems. The exact methods of credential acquisition remain undetermined; however, the group demonstrated capabilities to capture SNMP, TACACS, and RADIUS traffic, including secret keys, to enumerate additional credentials. 
• Exploitation of CVE-2018-0171 – The Attacker leveraged this vulnerability to gain unauthorized access to Cisco devices. The exploitation allowed the attackers to execute arbitrary code, facilitating deeper penetration into the network infrastructure. Notably, no new Cisco vulnerabilities were identified during this campaign.

2. Establishing Persistence – Post-compromise, Salt Typhoon employed several techniques to maintain long-term access:

• Creation of Local Accounts – They generated new user accounts with elevated privileges on compromised devices.
• Enabling Guest Shell Access – This provided a Linux-based container within IOS XE, allowing the execution of scripts and utilities directly on the device.
• SSH Configuration – Modifications were made to permit remote SSH access, facilitating control over the devices from external locations.

3. Configuration Exfiltration – Salt Typhoon exfiltrated device configurations using protocols such as TFTP and FTP. These configurations often contained sensitive authentication materials, including SNMP Read/Write community strings and local accounts with weak password encryption types. 

4. Lateral Movement and Data Exfiltration – To traverse networks and extract data, the group utilized:

Living-off-the-Land (LOTL) Techniques – By leveraging existing tools and commands within the network environment, they minimized the likelihood of detection.JumbledPath Utility – A custom-developed Go-based ELF binary, JumbledPath enabled packet capture on remote Cisco devices via an attacker-defined jump host. It also possessed capabilities to clear logs and disable logging, obscuring malicious activities.

Impact Assessment

Data Exfiltration – Access to sensitive metadata, including call logs and text message details, was achieved, potentially compromising the privacy of millions of users.

National Security Risks – The interception of communications involving high-profile individuals posed significant counterintelligence threats.

Operational Disruption – The unauthorized access and potential manipulation of core network components threatened the integrity and reliability of telecommunications services.

Recommendations

• Data Encryption – Ensure that all sensitive data is encrypted during transmission and while stored.
• Network Segmentation – Divide networks into segments to ensure that even if one segment is compromised, lateral movement across the organization is limited.
• Zero-Trust Architecture – Adopt a zero-trust security model where every access request is verified, irrespective of its origin within the network.
• Vulnerability Scanning – Implement automated tools to regularly scan systems for known vulnerabilities, such as CVE-2018-0171. 
• Regular Secrets Rotation – Use an automated secrets manager to rotate your secrets periodically to avoid any data breaches or leaks.
• Regularly Apply Patches – Implement a strict patch management policy to ensure all critical vulnerabilities are patched in a timely manner.
• Anomaly Detection – Implement machine learning and behavior analytics tools to detect deviations from normal system activities, which may indicate lateral movement or other malicious actions.

Conclusion

The Salt Typhoon intrusion into U.S. telecommunications networks underscores the critical need for proactive cybersecurity measures. The exploitation of a known vulnerability, combined with the use of stolen credentials, facilitated a prolonged and damaging breach. Organizations must prioritize the implementation of robust security protocols, regular system updates, and continuous network monitoring to safeguard against such sophisticated threats.

Cisco Data Breach – Leaks Active Directory Credentials

On 10th February 2025, the Kraken ransomware group claimed responsibility for a data breach involving Cisco Systems. They alleged that they had infiltrated Cisco’s internal network and exfiltrated sensitive credentials from the company’s Windows Active Directory (AD) environment. The leaked data included usernames, security identifiers (SIDs), and NTLM password hashes. Cisco has refuted these claims, asserting that the data in question originates from a previously addressed incident in May 2022.

What Happened?

The Kraken ransomware group published a dataset on their dark web blog, which reportedly comprises:

• Usernames and Domains – Identifying individual users and their associated AD domains.
• Relative Identifiers (RIDs) – Unique identifiers assigned to user accounts within the AD environment.
• NTLM Password Hashes – Hashed representations of user passwords.

The structure of the leaked data suggests extraction via credential-dumping tools such as Mimikatz, pwdump, or hashdump. These tools are commonly used to harvest credentials from system memory or the Security Account Manager (SAM) database.

Breach Analysis

Credential Dumping Techniques

Credential dumping involves extracting authentication credentials from operating systems. Tools like Mimikatz can access the Local Security Authority Subsystem Service (LSASS) memory to retrieve plaintext passwords, hashes, and Kerberos tickets. In this case, the attackers likely used such tools to obtain NTLM hashes from Cisco’s AD environment.

NTLM Hashes

NTLM (NT LAN Manager) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. Despite being outdated, NTLM remains in use for backward compatibility. The exposure of NTLM password hashes is concerning due to the following exploitation methods:

• Pash The Hash Attacks – Attackers use the captured hash to authenticate as a user without knowing the actual plaintext password.
• Dictionary Attacks – Attackers attempt to crack the hashes to retrieve plaintext passwords, especially if weak passwords are used.

The presence of privileged accounts, such as the Administrator:500 account and the krbtgt account (responsible for Kerberos ticket-granting), in the leaked data poses significant risks. Compromise of these accounts could allow attackers to forge authentication tickets or escalate privileges within the network.

Potential Impact

If the leaked credentials are still valid, the attackers could:

• Escalate Privileges – Gain administrative access to critical systems.
• Lateral Movement – Navigate through the network to access additional resources.
• Data Exfiltration – Extract sensitive corporate or customer data.
• Deploy Ransomware – Encrypt data to disrupt operations and demand ransom.

The inclusion of domain controller accounts in the leak indicates that the attackers may have had deep network access, potentially compromising the integrity of the entire AD infrastructure.

Cisco’s Response

Cisco has acknowledged the reports but clarified that the data is related to a security incident from May 2022, which was fully addressed at that time. The company stated that there was no impact on customers and emphasized that the incident has been resolved.

Recommendations

Regardless of the data’s origin, organizations should implement the following measures to mitigate similar risks:

1. Enforce Password Resets – Mandate immediate password changes for all potentially affected accounts.
2. Disable NTLM Authentication – Where possible, transition to more secure authentication protocols like Kerberos.
3. Implement Multi-Factor Authentication (MFA) – Add an extra layer of security to prevent unauthorized access.
4. Monitor Access Logs – Regularly review logs for unusual or unauthorized activities.
5. Conduct Security Audits – Perform periodic assessments to identify and remediate vulnerabilities.

Conclusion

This breach underscores the persistent threats organizations face from sophisticated cyber adversaries. Even if the leaked data is from a previously addressed incident, its resurfacing highlights the importance of continuous vigilance, robust security measures, and proactive incident response strategies to protect sensitive information and maintain client’s trust.

Zacks Breached, Again: The Fallout for 12 Million Users

In February 2025, the cybersecurity world faced yet another wake-up call, this time, the target was Zacks Investment Research, a well-known investment analysis firm. A hacker, going by the alias “Jurak,” claimed responsibility for leaking sensitive data belonging to 12 million Zacks customers. This breach has left millions exposed to serious risks like identity theft, credential stuffing, and financial fraud. But what’s even more alarming is that this isn’t the first time Zacks has fumbled the ball when it comes to data security.

What Happened?

Jurak claims they were able to breach Zacks’ Active Directory (AD), gaining domain administrator account privileges, essentially, the crown jewels in terms of access within any organization. With this level of control, Jurak was able to steal source code from Zacks’ primary website (zacks.com) and 16 internal and external web applications, exposing backend logic, API keys, and possibly much more. The attack goes beyond just stealing data, it reveals gaping holes in Zacks’ internal security.

What Was Stolen?

The exposed data includes a list of highly sensitive information:

• Password Hashes – Unfortunately, Zacks used a weak, unsalted SHA-256 hash to store passwords which puts users at even greater risk.

• Personally Identifiable Information (PII) – Full names, addresses, and phone numbers.

• Credentials – Usernames and email addresses.

• Technical Data – Customer IDs, IP addresses, time zone codes, and even timestamps for password resets were leaked, giving attackers a treasure trove of information.

Why Was Password Storage Such a Disaster?

The use of unsalted SHA-256 hashing to store passwords is one of the most serious flaws in this breach. Without adding a unique random string (a “salt”) to each password before hashing. Attackers can easily use precomputed rainbow tables to crack many passwords, opening the door to all kinds of attacks, especially if users reused those same passwords elsewhere.

Zacks’ History of Breaches

This breach is part of a concerning pattern at Zacks:

• December 2022 – An unauthorized party accessed an old database, compromising 820,000 Zacks accounts.
• June 2023 – Another breach exposed 8.8 million user records on a hacking forum. Compromised data included names, email addresses, and passwords.
• January 2025 – The most recent breach affects 12 million users.

Three major breaches in three years suggest a fundamental flaw in Zacks’ approach to security. Repeated failures to protect user data raise serious questions about whether they’re learning from past mistakes or simply patching problems temporarily.

What’s at Stake for Affected Users?

For the 12 million individuals impacted, the consequences go far beyond just changing a password:

• Credential Stuffing – Since passwords were stored in a weak unsalted hash, they are easily crackable. If users reused the same passwords on banking, email, or investment accounts, those accounts are now vulnerable.
• Phishing and Social Engineering: With stolen personal information in hand, hackers can launch highly targeted phishing attacks, tricking users into handing over even more sensitive data.
• Identity Theft: Full names, addresses, and phone numbers can be used to create fraudulent accounts.
• Dark Web Exposure: Once exposed, this data can be sold and re-sold on underground marketplaces, meaning the risks don’t end with this single breach.

What Can Be Done?

• Least Privilege Access – Enforce least privilege policies for all NHIs, ensuring they only have access to the resources needed for their specific function. 
• Micro-Segmentation – Segment NHIs across different environments to minimize lateral movement within the network in the event of a breach. NHIs with administrative privileges should be isolated in secure zones with rigorous monitoring.
• Credential Rotation – Implement automatic credential rotation policies for NHIs, Rotating credentials regularly reduces the risk of stolen credentials being used for prolonged periods of time.
• Use Short-Lived Tokens – Replace long-term static credentials with short-lived, ephemeral tokens that are regularly rotated and scoped to the minimum necessary privileges.
• Avoid Hardcoded Secrets – Ensure that no API keys or other NHI credentials are hardcoded into application source code. 
• Implement Stronger Cryptographic Algorithms – The use of unsalted SHA-256 for storing passwords is insufficient for protection. Organizations should use stronger, modern hashing algorithms.

Conclusion

This breach is not just about Zacks, it highlights a broader issue within the financial sector. Investment firms store vast amounts of high-value personal and financial data, making them prime targets for cybercriminals. Yet, time and again, we see companies failing to implement basic security hygiene, such as strong password hashing and proactive network monitoring.

With the increasing sophistication of cyber threats, firms like Zacks must evolve beyond reactive security measures and adopt a proactive, layered security approach. Until then, incidents like this will continue to occur, putting millions of users at risk.

How ASP.NET Machine Keys Triggered Remote Code Execution Attacks

On February 6, 2025, Microsoft revealed a major security issue involving over 3,000 publicly exposed ASP.NET machine keys. These keys, meant to protect web applications, had been inadvertently shared in public repositories, creating a significant risk of remote code execution (RCE) attacks. Exploiting these exposed machine keys, attackers took advantage of the ASP.NET ViewState mechanism to inject and execute arbitrary code on vulnerable servers.

What are ASP.NET Machine Keys?

In ASP.NET applications, machine keys are pivotal for ensuring data integrity and confidentiality. They are employed to sign and encrypt various data structures, including:

• ViewState – Prevents tampering with ViewState, which maintains UI state across postbacks
• Forms Authentication Tickets – Manages user authentication sessions.
• Cookies – Prevents modification of authentication and session cookies.

Machine keys are typically configured in the web.config file:

By default, ASP.NET can generate these keys automatically. However, in multi-server environments, administrators often hardcode the keys for consistency across servers. Unfortunately, mismanagement of these keys can lead to severe security risks if they are publicly disclosed.

What Happened?

In December 2024, Microsoft’s Threat Intelligence team identified a wave of attacks where publicly available ASP.NET machine keys were used for malicious code injection. Threat actors exploited these keys to forge cryptographic tokens, manipulate ViewState, and execute arbitrary code on web servers.

The attackers leveraged over 3,000 publicly disclosed machine keys, found in:

• Open-source repositories (GitHub, GitLab, Bitbucket)
• Public forums (Stack Overflow, Pastebin, coding blogs)
• Exposed configuration backups and logs

Instead of relying on complex exploits, attackers used pre-existing machine keys to execute arbitrary commands on servers running misconfigured ASP.NET applications.

How It Happened?

1 – Discovery of Publicly Exposed Machine Keys – Attackers collected ASP.NET machine keys from publicly accessible sources, such as:

• GitHub repositories where developers accidentally hardcoded machine keys.
• Stack Overflow discussions where users shared their web.config settings.
• Configuration backups left in publicly accessible folders.
• Leaks from previous breaches where machine keys were exposed.

2 – ViewState Exploitation – One of the primary attack vectors was exploiting ASP.NET ViewState deserialization:

ViewState Signing and Encryption

• ViewState is signed using the machine key to prevent tampering.
• If an attacker knows the machine key, they can generate their own signed ViewState payloads.

Crafting a Malicious ViewState Payload

• Attackers used tools to create a serialized .NET object payload containing malicious commands.
• This payload was encrypted and signed using the stolen machine key.

Injecting the Malicious ViewState

• Attackers submitted the ViewState payload via an HTTP POST request.
• Since the payload was correctly signed, the application trusted and deserialized it, leading to remote code execution (RCE).

Deploying the Godzilla Webshell

• Attackers used this RCE method to deploy Godzilla, a webshell that allowed persistent access.

Once installed, the webshell enabled:

• Command execution on the server.
• File uploads/downloads for data exfiltration.
• Credential theft and lateral movement within the network.

Recommendations

1. Secure Machine Key Storage

• Use secure key management solutions.
• Store keys in environment variables rather than configuration files.

2. Enable ViewState Encryption

• Set ViewStateEncryptionMode=”Always” to prevent attackers from tampering with ViewState.

3. Disable Insecure ViewState Mac Validation

• If ViewState is not needed, disable it completely by setting:

4. Regularly Audit Your Applications

• Periodically review your web.config files for exposed secrets.
• Perform static code analysis to detect hardcoded credentials.

5. Use Unique Machine Keys

• Never use default or publicly available machine keys. Each application should have a distinct machine key.

6. Keep ASP.NET Framework Updated

• Ensure your applications run on the latest version of .NET.
• Apply all Microsoft security patches.

Conclusion

The exposure of ASP.NET machine keys, whether through public disclosure or inadequate security practices, presents a significant threat to web application security.

By understanding the mechanics of these vulnerabilities and implementing robust security measures, developers can protect their applications from potential code injection attacks.