company logo

Product

Our Product

We are Reshaping the way Developers find and fix vulnerabilities before they get exploited.

Solutions

By Industry

BFSI

Healthcare

Education

IT & Telecom

Government

By Role

CISO/CTO

DevOps Engineer

Resources

Resource Library

Get actionable insight straight from our threat Intel lab to keep you informed about the ever-changing Threat landscape.

Subscribe to Our Weekly Threat Digest

Company

Contact Us

Have queries, feedback or prospects? Get in touch and we shall be with you shortly.

loading..
loading..
loading..
Loading...

Mexico

Prometheus

Grief

loading..
loading..
loading..

Mexican Govt. data publicized with new ransomware group Prometheus & Grief

Prometheus has disclosed data on 27 victims, primarily from Mexico Government, and it looks like this is just the beginning...

01-Jun-2021
7 min read

Related Articles

loading..

Supply Chain Attack

Learn about the recent supply chain attack on the Solana web3.js npm library, im...

A recent supply chain attack on the [`@solana/web3.js`](https://www.npmjs.com/package/@solana/web3.js)[ library](https://www.npmjs.com/package/@solana/web3.js) has underscored the need for heightened security in software development. This [Threatfeed](https://www.secureblink.com/cyber-security-news) offers a detailed analysis of the incident to help developers, security researchers, and organizations understand the attack and implement preventive measures. ## Background of the Attack On December 2, 2024, versions `1.95.6` and `1.95.7` of the popular `@solana/web3.js` library was compromised by a supply chain attack. A supply chain attack occurs when an attacker compromises a trusted software component at the source, introducing malicious code that gets distributed to end users. This library is a crucial JavaScript client that allows interaction with the Solana blockchain, used extensively by decentralized applications (dApps) to interface with the blockchain network. More information can be found on the [official Solana JavaScript client documentation](https://solana.com/docs/clients/javascript). The incident exposed sensitive private keys to threat actors. In blockchain, private keys are used to authorize transactions and manage cryptocurrency wallets. If compromised, these keys allow attackers to drain funds, creating severe financial risks for developers and organizations. A supply chain attack occurs when a trusted software component is compromised at the source, leading to the introduction of malicious code into the software. In this case, attackers leveraged compromised developer credentials to publish malicious versions of the library. The compromised versions included malicious code designed to steal private keys, enabling attackers to drain cryptocurrency wallets. ### Example of Supply Chain Attack For example, in a typical supply chain attack, an attacker might compromise a developer's credentials or use phishing techniques to gain access to the publishing environment of a popular library. Once they have access, they introduce malicious code that gets distributed to end users who trust the library. This was precisely the scenario that occurred with `@solana/web3.js`, where the malicious versions were able to steal sensitive data from unsuspecting users. ## Affected Versions and Technical Details ### Versions Impacted - **Affected Versions**: `1.95.6` and `1.95.7`. - **Safe Version**: Developers are advised to update to version `1.95.8`, that was released to remove the malicious code. You can find more details in the [official GitHub release notes](https://github.com/solana-labs/solana-web3.js/releases/tag/v1.95.8). - **Vulnerability Detection**: npm swiftly unpublished the compromised versions once the attack was detected. Detailed information on the detection and response can be found in this [Socket.dev blog post](https://socket.dev/blog/supply-chain-attack-solana-web3-js-library). ### Nature of the Malicious Code - The injected code targeted private keys, stealing them and transmitting them to a **hardcoded wallet address**. The data was disguised using legitimate-looking CloudFlare headers, making it difficult to detect, and it was transmitted without encryption, leaving sensitive information vulnerable to interception. - The associated **Solana address** (`FnvLGtucz4E1ppJHRTev6Qv4X7g8Pw6WPStHCcbAKbfx`) received the stolen credentials, putting affected wallets at significant risk. Mentioning the specific address helps in tracking the movement of stolen assets and providing transparency for affected users. ### Attack Timeline - The affected versions were available from **3:20 p.m. UTC to 8:25 p.m. UTC on December 2, 2024**. - The attack targeted projects that directly handled private keys within this narrow timeframe. ## Impact on Developers and Projects ### Who Was Affected? - Projects that **directly handle private keys** and updated to one of the compromised versions during the affected window. - **Non-custodial wallets** were **not affected** as they generally do not expose private keys during transactions, minimizing the risk of compromise. Non-custodial wallets are wallets where users retain full control over their private keys without relying on a third party. ### Scope of the Risk - **Developers and dApps**: Developers who used these versions in their projects faced the risk of having their private keys compromised, leading to a significant security breach. - **Financial Risk**: Exposure of private keys puts connected funds and wallets at risk of being drained by attackers. ## Mitigation Steps for Developers To mitigate the impact of the attack and ensure ongoing security, it is crucial to take immediate action to prevent further risks. The following actions are recommended: ### 1. **Update to Version 1.95.8** - **Upgrade Immediately**: All Solana developers must update to version `1.95.8` immediately to protect against vulnerabilities. Developers with pinned dependencies to `latest` must also ensure their environments are updated. ### 2. **Rotate Compromised Keys** - Developers who suspect compromise should **rotate authority keys** immediately, including: - **Multisignature Keys** (multisigs). - **Program Authorities** (used for smart contracts). - **Server Keypairs** (used for backend operations). - To rotate keys, developers should generate new keypairs and update their configuration files or environments to reflect the new keys. This will prevent attackers from continuing to use compromised credentials. ### 3. **Audit Dependencies** - **Check for Suspicious Code**: Review the `node_modules` directory and dependency trees to ensure no unauthorized modifications were made. - Use **Socket's CLI** (`socket scan create .`) or the **Socket GitHub app** to detect compromised dependencies. ### 4. **Revoke Permissions** - Revoke permissions granted to any compromised authority keys to prevent unauthorized access and minimize potential damage. ## Detailed Analysis of the Malicious Function ### `addToQueue` Function - The attack involved the addition of a **malicious function** named `addToQueue`, as shown in Where  1. - **Purpose**: The function exfiltrated private keys by injecting itself into legitimate code paths that accessed private key data. - **Exfiltration Mechanism**: It used **CloudFlare headers** to disguise the traffic as legitimate, effectively bypassing most security detection systems that might monitor for anomalous behavior. ### Command-and-Control Server - **Domain**: The C2 server (`sol-rpc[.]xyz`) was registered on **November 22, 2024**, via **NameSilo** and was hosted behind **CloudFlare**. - The server was used to collect stolen credentials but is currently **offline**, suggesting ongoing mitigation efforts by security teams. ## Root Cause Analysis and Attack Mechanism ***Figure 2: The 'addToQueue' function repeatedly called with secret key data, exfiltrating sensitive information.*** ### Publish-Access Compromise - The root cause of the attack appears to be a **phishing/social engineering** attack that compromised the **publish-access account** for the `@solana/web3.js` library. Common signs of phishing attacks include unexpected emails or messages asking for sensitive information, suspicious links, and requests for credentials that seem urgent or out of context. For further information on these incidents, refer to [this post by Christophe Tafani-Dereeper on Bluesky](https://bsky.app/profile/did\:plc\:zwlpsxw2udovqf4mbfi4ibqf/post/3lcgt6l7s4c2a). Developers should be vigilant about these warning signs to help prevent similar incidents in the future. - Phishing attacks typically involve tricking the target into revealing sensitive information, such as account credentials, which the attacker then uses to gain unauthorized access, as illustrated in Figure 2. Once the account was compromised, the attacker could publish unauthorized versions, embedding the malicious code. ### Abuse of Open Source Trust - The attack emphasizes the inherent **vulnerabilities of the open-source ecosystem**, which arise from the trust developers place in shared libraries that may not always be securely maintained. Trust in these libraries can be risky because attackers can exploit them by injecting malicious code, as was the case in this incident. - Attackers exploited this trust, embedding backdoors in widely used packages, highlighting the need for **additional security checks** and **code audits**. ## Preventive Strategies for Developers To prevent similar incidents in the future, developers should adopt the following strategies: ### 1. **Implement Secure Key Management** - **Avoid Hardcoding Keys**: Never hardcode private keys directly into your code. Use secure environment variables or external secret management systems. - **Use Hardware Security Modules (HSMs)**: Utilize HSMs or secure key storage services to handle sensitive key material, reducing the chances of exposure. ### 2. **Apply Principle of Least Privilege** - **Limit Access**: Only provide the minimum required access permissions to accounts that interact with publish-access controls. This limits the potential damage if an account is compromised. ### 3. **Conduct Regular Security Audits** - **Static Code Analysis**: Use static code analysis tools to identify vulnerabilities and malicious changes in code dependencies. - **Dependency Monitoring Tools**: Tools such as Dependabot or Snyk can automatically notify developers of vulnerabilities in third-party libraries. Additionally, you can read more about similar malicious packages in this [Socket.dev blog post](https://socket.dev/blog/malicious-npm-packages-threaten-crypto-developers). ### 4. **Use Multi-Factor Authentication (MFA)** - Require **MFA** for all developer accounts that have access to publish or modify packages, adding an extra layer of protection against unauthorized access. ### 5. **Implement Supply Chain Security Tools** - Utilize specialized tools such as **Sigstore** to verify the provenance of open-source packages. Supply chain security tools help ensure that the code being deployed has not been tampered with.

loading..   05-Dec-2024
loading..   8 min read
loading..

Data Security

Signzy

Signzy, an online ID verification company, has confirmed a cybersecurity inciden...

Signzy, a vendor providing verification services, confirmed a security incident that has impacted its global clientele, including major banks and fintech companies. The startup, which onboarded over 10 million customers monthly, faced a cyberattack, raising concerns about data safety. Signzy confirmed the incident without providing details on its nature or scope, citing an ongoing investigation and security reasons. This news comes amid rising concerns over cybersecurity for financial institutions, given that Signzy works with over 600 financial entities, including India's largest banks. ## **Details of the Security Incident** Multiple sources, including two major Signzy clients—PayU and ICICI Bank—informed [TechCrunch](https://techcrunch.com/2024/12/02/indian-online-id-verification-firm-signzy-confirms-security-incident/) that Signzy fell victim to a cyberattack last week. The incident involved sensitive customer data, including personal identification details and financial records, potentially being exposed, as seen in a cybercrime forum post. India’s Computer Emergency Response Team (CERT-In) acknowledged awareness of the incident and mentioned it was actively managing the situation by monitoring affected systems, providing guidance, and coordinating with other agencies. PayU, one of Signzy’s clients, clarified that it suffered no impact from the attack, likely due to its independent security measures and lack of direct data integration with Signzy's affected systems. _"There is no impact on PayU customers or their data due to Signzy's [information](https://www.upguard.com/security-report/signzy) stealer malware,"_ stated Dimple Mehta, a PayU spokesperson. Similarly, ICICI Bank confirmed that their customer data remained unaffected. ## **Uncertain Impact on Customers** Concerns linger as to the full impact on Signzy’s other customers, which include top financial institutions such as SBI, Mswipe, and Aditya Birla Financial Services, potentially facing data theft or service disruptions. The firm has engaged a professional cybersecurity agency to investigate the breach, but has yet to disclose whether any customer data had been compromised. Debdoot Majumder, a spokesperson for Signzy, stated that the startup had informed its clients, regulators, and stakeholders of the measures being taken and provided a timeline of the investigation. However, when asked if the company had engaged with the Reserve Bank of India (RBI), Signzy confirmed no such communication had taken place. The RBI did not respond to requests for comment. ## **Rising Concerns Over Data Security** The incident highlights the increasing threat that cyberattacks pose to financial infrastructure, with cybercrime-related financial losses reaching $4.2 billion globally in 2023, according to industry reports. With over 600 clients, Signzy is a major player in the identity verification ecosystem, providing services across multiple industries. The potential exposure raises significant concerns, especially given the critical nature of ID verification for preventing fraud and financial crimes. Experts warn that financial institutions must enhance cybersecurity as they increasingly rely on digital onboarding, such as implementing multi-factor authentication, conducting regular security audits, and training employees on phishing prevention. The involvement of information-stealer malware suggests a targeted attack, making it imperative for other stakeholders in the financial sector to assess their security postures by updating software, conducting vulnerability tests, and ensuring timely patch management. ## **Signzy's Action Plan** Signzy has stated that it is cooperating with authorities and has retained cybersecurity professionals to address the incident, including conducting forensic analysis, securing affected systems, and implementing additional safeguards to prevent future breaches. Backed by investors such as Mastercard, Vertex Ventures, Kalaari Capital, and Gaja Capital, the company is under pressure to ensure that its internal security framework is resilient enough to protect its users. As part of the ongoing investigation, Signzy's leadership is expected to provide more details regarding how the incident occurred, what data might have been affected, and steps to prevent similar breaches. Investors and clients will be watching closely for updates, particularly given the growth in reliance on digital identity solutions.

loading..   03-Dec-2024
loading..   4 min read
loading..

Salt Typhoon

T-Mobile halts a Chinese state-sponsored cyberattack by Salt Typhoon, safeguardi...

T-Mobile recently disclosed a security breach involving the Chinese state-sponsored hacking group referred to as "Salt Typhoon", also tracked as Earth Estries, FamousSparrow, Ghost Emperor, and UNC2286. While the hackers exploited vulnerabilities in the company's network routers, T-Mobile's defensive measures reportedly mitigated further damage, securing sensitive customer information. ### Key Incident Details - 1. Initial Compromise: Salt Typhoon accessed T-Mobile's network via routers, likely as part of lateral movement efforts to explore network vulnerabilities. The attack originated from a compromised wireline provider's network, underscoring the risks posed by interconnected systems. - 2. Detection and Response: The breach was identified when T-Mobile engineers observed unusual reconnaissance commands on routers, correlating with known Salt Typhoon tactics and indicators of compromise. Proactive monitoring and network segmentation enabled T-Mobile to block the threat actors before sensitive data was compromised or services disrupted. - 3. Extent of Damage: T-Mobile has confirmed that no customer data, including calls, messages, or voicemails, were accessed or stolen. Connectivity with the compromised provider's network was severed, effectively containing the attack. - 4. Collaboration and Transparency: T-Mobile shared findings with federal authorities and industry partners, emphasizing a collaborative approach to tackling cyber threats. ### Broader Implications of Salt Typhoon Activities This breach is part of a larger wave of telecom attacks attributed to Salt Typhoon, targeting critical infrastructure in Southeast Asia, the United States, and Canada: #### Targeted Entities: Telecom providers, including AT&T, Verizon, and Lumen Technologies, alongside government agencies and political institutions. Attacks extended to private communications, law enforcement data, and wiretapping platforms, reflecting a focus on espionage and intelligence collection. #### Duration and Impact: In some cases, breaches persisted for months or longer, allowing hackers to exfiltrate extensive internet traffic and sensitive data. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the FBI confirmed that attackers accessed sensitive communications involving government officials. #### Geopolitical Context: Canada's disclosure of network scans linked to Chinese threat actors highlights the global scale of such campaigns, which align with China's broader cyber-espionage strategy. ### Additional Insights: Connections with Volt Typhoon Though not directly linked to Salt Typhoon, the Chinese Volt Typhoon group recently executed attacks on ISPs and Managed Service Providers (MSPs) in the U.S. and India. These breaches leveraged stolen credentials and zero-day exploits, mirroring the persistence and sophistication seen in the Salt Typhoon campaign. ### Takeaways and Recommendations - 1. Strengthen Interconnection Security: Telecom companies must enforce stricter security protocols when interfacing with third-party networks. The breach's origin in a compromised provider highlights the need for secure collaboration. - 2. Proactive Monitoring and Threat Intelligence: Continuous network monitoring and real-time threat intelligence sharing, as demonstrated by T-Mobile, are critical in mitigating advanced persistent threats. - 3. Zero-Trust Architecture: Implementing a zero-trust framework can limit attackers' ability to navigate laterally within networks after initial compromise. - 4. Vulnerability Management: Regular audits and timely patching of known vulnerabilities, such as zero-day exploits seen in Versa Director attacks, are essential. ### Final Note T-Mobile's response demonstrates the effectiveness of early detection and strong cyber defenses in preventing catastrophic breaches. However, the broader implications of the Salt Typhoon campaign reveal persistent vulnerabilities in the telecommunications sector, warranting enhanced international cooperation and cybersecurity measures.

loading..   30-Nov-2024
loading..   3 min read