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.

DeepSeek Breach: What Went Wrong?

On January 29, 2025, a major security breach involving DeepSeek, a prominent Chinese artificial intelligence (AI) startup, was reported. The breach resulted in the exposure of over one million log lines and highly sensitive secret keys. This exposure has triggered serious concerns about the security of AI systems, the integrity of the data involved, and the broader implications for both organizations and industries relying on AI.

The exposed data includes sensitive information that could potentially allow attackers to gain unauthorized access to critical systems, databases, and AI models used by DeepSeek and its clients. Such a breach also raises questions about the risks of large-scale AI deployments, especially given the growing reliance on AI-driven automation, decision-making, and prediction systems.

Background on DeepSeek

DeepSeek has rapidly gained attention in the AI community for developing a chatbot that rivals leading models like OpenAI’s ChatGPT. Notably, DeepSeek achieved this with a development budget of approximately £4.8 million, significantly lower than the £80 million invested in ChatGPT. The chatbot’s competitive capabilities have led to concerns about data harvesting and potential dissemination of propaganda, especially given that user data is stored in China and subject to local censorship laws.

Details of the Breach

While specific technical details of the breach are limited, the exposure of over one million log lines and secret keys suggests a significant lapse in security protocols. Log lines typically contain records of system activities, user interactions, and error messages, which can provide insights into system operations and potential vulnerabilities. Secret keys are critical components used for authentication and encryption, ensuring secure communication and data protection.

The exposure of such sensitive information can have several implications:

• Unauthorized Access: Attackers can use exposed secret keys to gain unauthorized access to systems, databases, or APIs, potentially leading to data theft or further exploitation.
• Data Manipulation: With access to log files, malicious actors can understand system workflows and potentially manipulate data or system behaviors.
• Impersonation: Exposed keys can allow attackers to impersonate legitimate services or users, leading to phishing attacks or dissemination of false information.

Potential Vulnerabilities

Exploited Vulnerabilities – The breach is believed to have occurred due to misconfigurations in DeepSeek’s cloud-based infrastructure. Specifically, the exposed database was not properly secured with the necessary access controls and encryption standards. A lack of multi-factor authentication (MFA) and outdated firewall configurations further compounded the vulnerabilities.

Data Leak Pathway – Attackers likely gained access through publicly exposed databases that lacked security layers. Given the unencrypted nature of the log lines, attackers could scrape sensitive information from these logs. In addition, the exposed secret keys, used for API authentication and server access, could have been exploited to pivot further into DeepSeek’s environment, potentially compromising even more data.

Impact of the Breach

• Reputation Damage – DeepSeek’s reputation as a reliable AI provider has likely taken a significant hit due to this incident. Clients may lose trust in the company’s ability to secure sensitive data.
• Client Data Compromise – Clients using DeepSeek’s AI platforms could have their own data compromised or altered, leading to financial loss or other legal ramifications.
• Service Disruptions – Exposure of secret keys could lead to unauthorized system changes, including shutdowns, data manipulation, or the disruption of AI services.
• Intellectual Property Theft – Competitors or cybercriminals could reverse-engineer DeepSeek’s algorithms and models for malicious use or resale.

Recommendations

• Input Validation – Implement strict input validation to prevent injection attacks. Ensure that all user inputs are sanitized and validated before processing.
• Secure Key Management – Adopt robust key management practices, including the use of hardware security modules (HSMs), regular key rotation, and strict access controls to ensure that secret keys are stored securely and accessed only by authorized entities.
• Comprehensive Logging Practices – Ensure that logs do not contain sensitive information. Implement access controls to protect log files and regularly audit logging practices to identify and mitigate potential risks.
• Data Encryption – Sensitive data such as API keys, passwords, or personal information should not be logged in plain text. Implement redaction or encryption of log files to avoid exposure.

Final Thoughts

The DeepSeek AI breach serves yet another reminder that even the most advanced AI companies are not immune to security risks. As AI continues to integrate deeper into our lives, safeguarding these systems against cyber threats must be a top priority.

Companies must act fast to patch vulnerabilities, protect user data, and build trust. Otherwise, we may see more breaches like this, each with potentially devastating consequences for individuals and industries alike.

AWS S3 Buckets Under Attack

In January 2025, the ransomware group “Codefinger” has exploited Amazon Web Services (AWS) to launch a sophisticated campaign targeting Simple Storage Service (S3) buckets. Using compromised AWS credentials, the attackers leveraged AWS’s Server-Side Encryption with Customer Provided Keys (SSE-C) to encrypt stored data. This innovative use of legitimate AWS features complicates detection and remediation, underscoring the importance of robust cloud security practices.

Attack Pathway

The Campaign

The “Codefinger” ransomware group initiated their campaign in late 2024, focusing on organizations heavily reliant on cloud-based storage solutions. By gaining unauthorized access to AWS accounts, they encrypted sensitive data stored in S3 buckets and demanded ransom payments in Bitcoin to provide the decryption keys. Victims faced an additional threat: the attackers used AWS Object Lifecycle Management policies to set a seven-day deletion deadline for encrypted data, heightening urgency for ransom payment.

How The Attack Happened?

Credential Compromise

Codefinger obtained AWS credentials with permissions to read and write S3 objects through methods such as:

• Phishing and Social Engineering – Tricking users into revealing login information.
• Credential Dump Exploitation – Leveraging leaked credentials from prior breaches.
• Misconfigured IAM Policies – Exploiting overly permissive access configurations.

SSE-C Encryption Abuse

AWS’s SSE-C enables customers to encrypt S3 data using their own encryption keys. Codefinger exploited this feature by:

1. Generating unique AES-256 keys for encryption.
2. Using compromised credentials to encrypt data via SSE-C.
3. Ensuring AWS logged only a hash-based message authentication code (HMAC) of the encryption key, which attackers used to their advantage, knowing recovery would be impossible without their key.This approach rendered the data inaccessible without the attacker’s cooperation, as AWS itself does not store or manage customer-provided keys.

Ransom Note Placement

After encrypting the data, the attackers left ransom notes within affected directories. These notes included payment instructions and warnings about data deletion, with threats escalating after a seven-day period.

Lifecycle Policies Exploitation

The attackers employed AWS S3 Lifecycle Management to add a deletion rule for encrypted data. By doing this, they introduced a ticking clock for victims, amplifying psychological pressure to pay the ransom.

Possible Impact

The financial and operational consequences for affected organizations were severe:

1. Data Unavailability – Critical files became inaccessible, disrupting operations.
2. Financial Loss – Victims faced significant ransom demands.
3. Reputational Damage – Trust eroded as customers and partners questioned the organization’s security measures.

Recommendations

To defend against such attacks, organizations should consider the following measures:

Restrict SSE-C Usage – Implement Identity and Access Management (IAM) policies to limit the use of SSE-C to authorized users and data.

Regular Credential Audits – Frequently review AWS key permissions, disable unused keys, and rotate active ones to minimize the risk of unauthorized access.

Monitoring and Logging

• Enable Detailed Logging – Use AWS CloudTrail to monitor S3 bucket activities.
• Event Notifications – Set up alerts for changes to lifecycle policies or bulk encryption operations.

Security Best Practices

• Use AWS GuardDuty and Amazon Macie for anomaly detection.
• Regularly audit S3 bucket configurations for misconfigurations and overly permissive access.
• Train employees to recognize phishing attempts.

Conclusion

Codefinger’s attack on AWS S3 buckets demonstrates the sophisticated threats facing cloud environments. Organizations must adopt a proactive approach, combining robust technical controls, vigilant monitoring, and user education, to mitigate the risks of such attacks.

By understanding the attack vectors and implementing layered defenses, businesses can protect their critical assets from similar threats in the future.

Secrets Exposure Via Azure Key Vault Role

In December 2024, Researchers identified a potential privilege escalation vector in Azure Key Vault. The issue arises from the misconfiguration of the permissions associated with the “Key Vault Contributor” role. While this role is documented to allow management of key vaults without granting data access, it includes the Microsoft.KeyVault/vaults/write permission. This permission enables users to modify access policies, effectively allowing them to grant themselves or others full access to the key vault’s data.

What is Azure Key Vault?

Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Access to these resources is managed through two primary models:

• Azure Role-Based Access Control (RBAC): Provides fine-grained access management of Azure resources.
• Key Vault Access Policies: Offer a separate permissions model specific to Key Vault.

The Key Vault Contributor role is designed to manage key vaults without granting access to the stored data.

What Went Wrong?

Azure Key Vault uses roles to manage permissions. Among these roles is the “Key Vault Contributor,” primarily intended for managing key vault resources. In theory, this role does not allow access to sensitive data such as secrets or cryptographic keys.

However, the “Key Vault Contributor” role includes the Microsoft.KeyVault/vaults/write permission. This permission allows changes to the vault’s access policies, enabling users to grant themselves or others the permissions to access sensitive data. This misalignment between intended and actual permissions creates a potential attack vector for privilege escalation, making it critical to understand how it can be exploited.

How Privilege Escalation Happens?

A typical exploitation scenario:

1. Role Misuse – A user or attacker with the “Key Vault Contributor” role modifies the key vault’s access policies.
2. Granting Data Access – They add new permissions, such as “Get,” “List,” or “Decrypt,” for themselves or a compromised identity.
3. Data Exfiltration – With these elevated permissions, they can access secrets, keys, and certificates stored in the vault and exfiltrate data.

Real-World Risks

Data Exposure

An attacker or malicious insider with “Key Vault Contributor” permissions can modify access policies to grant themselves “Get” or “List” permissions. This enables unauthorized access to secrets, keys, or certificates stored within the vault.

Impact

• Compromised Credentials: Exposed secrets, such as API keys, database connection strings, and tokens, can lead to unauthorized access to other systems.
• Leaked Cryptographic Keys: Attackers gaining access to cryptographic keys can decrypt sensitive data or impersonate systems.
• Data Breaches: Public disclosure or exploitation of these secrets can result in major data breaches.

Compromised Cloud Workloads

Many Azure resources rely on Azure Key Vault for secrets and credentials. If an attacker accesses the vault, they can use those credentials to compromise workloads such as virtual machines, applications, or containerized environments.

Impact

• Unauthorized Application Access: Secrets used by Azure App Services or Functions can be extracted and used to interact with production systems.
• Disruption of Operations: With stolen credentials, attackers can alter configurations or disrupt services, causing operational downtime.
• Service Abuse: Using stolen secrets, attackers could rack up significant costs by deploying unauthorized resources under the compromised account.

Persistent Backdoors

An attacker could alter the access policies to create persistent backdoors by granting permissions to additional accounts or service principals under their control.

Impact:

• Stealthy Persistence: Attackers could maintain long-term access to the vault and its secrets even after initial detection.
• Repeated Data Exfiltration: Persistent access enables attackers to periodically extract updated secrets, ensuring continuous exploitation.
• Compromised Recovery Efforts: During incident recovery, attackers can use the backdoor to disrupt remediation efforts or regain access to compromised systems.

Microsoft’s Response

Upon disclosure, Microsoft classified this behaviour as “by design” and updated their documentation to clarify the capabilities of the Key Vault Contributor role. The updated guidance emphasizes that this role can modify access policies and recommends using the Azure RBAC permission model to mitigate such risks.

Lessons Learned

To address this vulnerability, organizations should adopt a combination of technical controls and best practices:

Transition to Azure RBAC

• Replace traditional access policies with Azure Role-Based Access Control (RBAC). RBAC offers better granularity and is integrated with Azure’s logging and monitoring systems.

Restrict Role Assignments

• Minimize the use of the “Key Vault Contributor” role and assign it only to users or systems requiring explicit management capabilities.
• Use custom roles to enforce stricter separation between management and data access permissions.

Enable Logging and Monitoring

• Turn on Azure Monitor logs for key vaults and monitor for unusual changes to access policies.
• Set up alerts for unauthorized modifications to access policies or suspicious access attempts.

Review and Audit Access Policies Regularly

• Periodically review who has permissions to modify access policies and ensure that they align with the principle of least privilege.

Implement Just-In-Time Access with Azure PIM

• Use Privileged Identity Management (PIM) to enforce time-bound access to roles like “Key Vault Contributor,” reducing the window for potential misuse.

Conduct Security Assessments

• Perform regular vulnerability scans and penetration tests on your Azure environment to identify and address misconfigurations.

Conclusion

The Azure Key Vault privilege escalation incident highlights the importance of robust role design and access control mechanisms. Misconfigured permissions can have far-reaching consequences, including access to Non-Human Identities including API Keys, Tokens, Certificates, Passwords, allowing threat actors to compromise sensitive data and critical systems.

By adopting security best practices, leveraging Azure RBAC, and continuously monitoring access configurations, organizations can mitigate the risks associated with this vulnerability and ensure their Azure environments remain secure.