The disruption affecting four major Iranian banks, which began in late June and later expanded to six banks, initially looked like a familiar banking outage under cyber pressure. Point-of-sale terminals returned errors, mobile banking apps failed to load, money transfers faced restrictions and some customers could not get clear answers even after visiting bank branches. But the official narrative that followed painted a more complex picture: a cyberattack against a shared service core, the temporary suspension of some services to prevent unauthorized access and a gradual recovery of systems that took days to return. In the latest update, the Central Bank said services at all banks except Bank Melli, Bank Saderat and Bank Tejarat had returned to normal, and that the remaining problems at those three banks would be resolved by the end of June 23, 2026.

In an incident like this, what users see is not necessarily the attack itself. Part of the disruption may be the result of defensive decisions, isolation measures, stability testing and staged recovery.

The banking incident did not happen in a vacuum. In the preceding days, several military, cyber and propaganda-related developments had turned critical infrastructure into a central arena of competing narratives. First, claims circulated about an encounter involving an Apache helicopter and an IRGC drone entering its cockpit. CENTCOM then targeted an antenna or drone-control station in the Sirik area, a site located near water tanks. After the strike, Islamic Republic media launched a campaign around the destruction of water tanks and water outages in the Sirik and Kuhestak area. One day later, the Handala group claimed it had breached water infrastructure in California and published part of the customer data of a water utility in the United States.

A few days later, as Iran’s banking disruption widened, TRoLL Team claimed responsibility for an attack on Bank Melli and framed it as a disruptive operation against the Islamic Republic’s financial infrastructure in response to that strike.

These incidents do not necessarily form a single, proven operational chain. Taken together, however, they show that amid escalating tensions, critical infrastructure, from water systems and drone-control facilities to electronic banking, has become a field for operational pressure, psychological warfare and the display of cyber capability. The banking attack, therefore, should not be read only as a service disruption, but as part of a broader contest over public trust and the resilience of critical infrastructure.

What We Know and What We Still Do Not Know

The recent banking disruption is filled with incomplete accounts, official claims and hacktivist assertions. To understand the incident more precisely, it is necessary to separate what is known from what remains unclear.

What We Know

• Four banks were at the center of the disruption: Bank Melli, Bank Saderat, Bank Tejarat and the Export Development Bank of Iran. In the following days, some reports also pointed to the involvement or indirect impact on several other banks, with the scope of the disruption reaching six banks in some accounts.
• The official narrative also changed over the course of the crisis. What was initially described as a “technical disruption” or a problem in the infrastructure of the Informatics Services Corporation was later referred to in official statements and comments as a “cyberattack.”
• In explaining the scope of the incident, officials referred to a “shared infrastructure” or a “shared service core” among the affected banks. That wording suggests the issue was likely not limited to banking apps or a single bank, but related to a shared layer within the architecture of electronic banking.
• Some card-based services and money-transfer functions returned gradually, but recovery was uneven. Some services, including SATNA, PAYA, checks, branch services and online or remote banking services, stabilized later or continued to operate under restrictions.
• The Informatics Services Corporation also said in its own statement that some services had been temporarily suspended to prevent unauthorized access. This is important because it suggests that part of the disruption users experienced may not have been the direct effect of the attack itself, but the result of defensive decisions, isolation measures and staged recovery.
• In reports published on June 23, there were references to a new wave or continued disruption affecting some banks and services. On the same day, the Central Bank said services at all banks except Bank Melli, Bank Saderat and Bank Tejarat had returned to normal, and that the remaining problems at those three banks would be resolved by the end of June 23, 2026.

What We Still Do Not Know

• The attack vector remains unclear. It is not known what path or weakness the attackers used: traffic flooding, disruption of communication routes, abuse of access, a software vulnerability, an attack on a shared service or a combination of several factors.
• It is still unclear whether the attack was limited to DDoS or involved a deeper intrusion. Service outages can result from an availability attack, but they do not by themselves prove that an attacker entered the internal network, core systems or databases.
• We still do not know whether the attacker gained access to internal networks or sensitive systems. Officials have spoken of preventing unauthorized access and protecting data, but no technical report has been released to clarify the actual level of the threat.
• No reliable public evidence has yet emerged showing the extraction or leakage of customer data. At the same time, the absence of public evidence of a leak does not prove the absence of unauthorized access.
• It is still unclear why backup mechanisms, disaster recovery, DR and failover did not enable a faster and more uniform restoration of services. The prolonged disruption and uneven recovery raise serious questions about the resilience of this infrastructure.
• The real role of TRoLL Team also remains unclear. The group claimed responsibility for the attack on Bank Melli and referred to Layer 4 and Layer 7 DDoS attacks, but it has so far not published sufficient technical evidence, such as logs, traffic charts, IOCs or proof of access.

Ultimately, the most important gap in the case remains the absence of a public post-incident analysis. Until the Central Bank, the Informatics Services Corporation or an independent technical body publishes a report on the type of attack, the scope of impact, the intrusion path, containment measures and the recovery process, much of this incident will remain in the same gray layer between attack, containment and recovery.

Timeline of the Incident: From a “Technical Problem” to a “Limited Attack”

Stage One: General Disruption: Initial reports pointed to disruptions in services at four banks. For users, the problem appeared at the level of everyday banking services: point-of-sale terminals returned errors, ATMs and mobile banking apps experienced problems, money transfers faced restrictions and some customers could not get clear answers even after visiting branches.

Stage Two: Attribution to the Informatics Services Corporation: The initial narrative attributed the problem to the infrastructure of the Informatics Services Corporation. From the outset, that explanation suggested the disruption had likely occurred at a shared point among several banks, rather than within a single app, branch or isolated service.

Stage Three: The Shift to a Cyberattack Narrative: The Coordination Council of Banks and other official sources later referred to a “limited cyberattack.” With this shift, the case moved from the level of a technical disruption to that of a security incident. Still, no technical details about the attack, the intrusion vector, the real scope of impact or verifiable evidence were released.

Stage Four: Uneven Service Recovery: Card-based services returned earlier than some other services, but SATNA, PAYA, checks, branch services and some online or remote banking services stabilized later or continued to operate under restrictions. That uneven recovery was itself an important technical signal: the return of card services did not mean the full recovery of the banks.

Stage Five: The Containment Narrative: The Informatics Services Corporation said some services had been temporarily taken offline to prevent unauthorized access. This means that part of what users experienced as disruption may have resulted from a defensive decision to contain risk, not only from the direct effect of the attack.

Stage Six: Officially Announced Recovery, With Three Banks Still Under Review: In the next stage, the Central Bank said services at all banks except Bank Melli, Bank Saderat and Bank Tejarat had returned to normal. It also promised that the remaining problems at those three banks would be resolved by the end of June 23, 2026. The statement suggested that, from the official perspective, the crisis had entered the final phase of recovery. But the fact that three major banks remained under review still showed that the restoration of services had not been complete, uniform or immediate.

This sequence shows that the crisis was not just a single, momentary attack. It was a full incident cycle involving detection, containment, emergency shutdowns, recovery, stability testing and incomplete public communication.

Architecture Map: At Which Layer Did the Incident Occur?

To understand the recent banking disruption, it is necessary to distinguish between what users see and what happens inside the operational layers of banking. POS errors, mobile banking outages or transfer restrictions are only the external symptoms of the crisis. The main point of failure may have been located in a deeper and more shared layer. In its simplest form, the architecture of this incident can be understood across five layers.

The first layer is the user-facing channel layer: POS terminals, ATMs, mobile banking, internet banking and branches. This is the level citizens encountered directly.

The second layer is the banking service layer inside each bank: core banking, card switches, authentication services, balance inquiry, money transfers and checks. This layer determines how a user request is processed inside the bank.

The third layer is the shared and interbank systems layer: SATNA, PAYA, Shetab, Shaparak, communication routes, switches and shared services. Disruption in this layer can affect connections between banks, payments and interbank transfers.

The fourth layer is the Informatics Services Corporation and the shared service core: the point where several banks may rely on a common service, route, platform or operational core. If the incident occurred at this layer, it could affect several banks at once without each bank having to be targeted separately.

The fifth layer is incident management: DR, failover, disconnection, isolation, hardware replacement and staged recovery. This layer helps explain why part of the disruption may not have been the direct effect of the attack itself, but the result of defensive decisions and the recovery process.

If the incident had occurred at the user layer, it would likely have disrupted only one app, one channel or one type of service. If it had occurred in Shetab or Shaparak, the scope of impact should have been much broader and more nationwide. The fact that the crisis remained limited to several banks, while affecting multiple types of services at the same time, points to the need to examine the middle layer and the shared service core.

Attack, Containment or Secondary Failure? Three Technical Scenarios

The public information released so far is not sufficient to determine the exact type of attack. But the pattern of the incident suggests that this was not a simple, single-cause disruption. At least three technical scenarios need to be considered at the same time: external traffic pressure, an attack or disruption affecting a shared service core, and defensive decisions involving isolation and staged recovery.

Scenario One: A Heavy DDoS Attack Against External Services: This scenario is consistent with TRoLL Team’s claim and with part of the disruption users experienced. If the bank’s external services, including mobile banking, internet banking, APIs, load balancers, firewalls or public communication routes, were placed under DDoS pressure, the result could appear as app errors, service slowdowns, failed logins, transfer disruptions or parts of the service becoming unavailable.

But the limitation of this scenario is clear: DDoS alone does not prove intrusion into core banking, access to internal databases or extraction of customer data. A DDoS attack targets availability, not necessarily confidentiality or data integrity. Therefore, even if part of the incident resulted from traffic pressure, that explanation is not sufficient to account for all dimensions of the crisis.

Scenario Two: An Attack on the Shared Service Core or Connection Routes: This scenario is more consistent with the newer official narrative. Officials have referred to a “shared infrastructure” or a “shared service core” among the affected banks. If the point of impact was in such a layer, each bank would not need to have been targeted separately; disruption in a shared service, route, platform or node could affect several banks at the same time.

This scenario also helps explain why the crisis did not remain limited to a single app or banking channel and instead affected different services, from cards and mobile banking to PAYA, SATNA, branches and checks. Such a pattern looks more like an incident in the middle layer of electronic banking, where banks, shared systems, communication routes and infrastructure service providers are interconnected.

Scenario Three: Emergency Shutdown and Failed or Slow Failover: The third scenario explains the effect of defensive decisions and the recovery process. The Informatics Services Corporation had said that some services were temporarily taken offline to prevent unauthorized access. This means that part of what users experienced as disruption may not have been the direct effect of the attack, but the result of isolation, emergency shutdowns, stability testing or staged recovery.

In such a situation, the main question is not only what the attacker did. The more important question is why backup mechanisms, DR and failover were unable to enable a faster, safer and more uniform restoration of services. If service recovery took days and some services returned earlier than others, the issue points to the quality of redundancy architecture, the operational independence of banks and incident-response readiness.

The recent incident was probably not caused by a single factor. It is more likely that it involved a combination of pressure or attack, defensive isolation and weak rapid recovery across shared services. That is why explanations such as “it was only DDoS,” “it was only a technical failure” or “it was only an attack on one bank” do not capture the full picture. The more important point is that an incident in the middle layer of banking infrastructure was able to affect the user layer, banks’ operational services and public trust at the same time.

TRoLL Team: Hacktivist Claim or Technical Evidence?

With the publication of TRoLL Team’s posts, the incident moved beyond the group’s initial claim of a DDoS attack against Bank Melli. In later messages, the group claimed deep intrusions into the infrastructure of Bank Pasargad and Bank Keshavarzi and published a list of technical details: exploitation of an API Gateway, lateral movement inside the network, access to VMware and Active Directory environments, deployment of WebShell and Cobalt Strike, access to Oracle Core Banking, extraction of several terabytes of data, Layer 7 DDoS attacks, disabling of monitoring systems and even ransomware deployment.

Analytically, these claims matter because they show that the group is trying to frame the incident not merely as an availability disruption, but as a multi-stage and destructive intrusion. If such claims are accurate, the issue moves beyond an availability attack and into the realm of internal access, exfiltration, destruction, extortion and chained threats against banking infrastructure.

At this stage, however, the claims have not reached the level of reliable technical evidence. TRoLL Team has used many technical terms and details, but it has not released verifiable logs, IOCs, credible and redacted data samples, traffic charts, malware samples, verifiable screenshots from internal environments or an independent report. A partial hash or an alleged database query is not, by itself, proof of access.

Some parts of the claims are plausible: DDoS against external services, pressure on mobile and internet banking, API disruption or the exploitation of older weaknesses in banking systems. But claims such as access to core banking, extraction of several terabytes of data, acquisition of HSM keys, ransomware deployment across a large portion of servers and wiping of backups are highly significant assertions and should not be treated as confirmed without independent evidence.

TRoLL Team’s claims expand the possible scope and seriousness of the incident, but until verifiable technical evidence is released, they remain somewhere between hacktivist lead, psychological operation and unproven assertion.

Layer 4 and Layer 7 DDoS: Why a Service Outage Is Not the Same as an Intrusion

TRoLL Team’s claims and some early narratives about the banking disruption repeatedly referred to Layer 4 and Layer 7 DDoS attacks. To understand this claim, one distinction is essential: DDoS is an attack on availability. It can slow a service down, make it unstable or take it offline, but it does not by itself show that the attacker entered the internal network, accessed core banking systems or extracted customer data.

A Layer 4 DDoS attack targets the network transport layer, where TCP and UDP traffic, communication paths, firewalls, load balancers and bandwidth capacity come into play. In this type of attack, the attacker attempts to overwhelm communication routes or edge infrastructure with large volumes of packets or half-open connections. For users, the result can appear as slowness, connection errors, service outages or an inability to use an application.

A Layer 7 DDoS attack targets the application layer, where requests are sent to websites, APIs, login pages, mobile banking, internet banking or authentication services. This type of attack may use less traffic but be more targeted, because it puts pressure on functions that require heavier processing: user login, balance inquiry, money transfer, transaction history retrieval or communication with backend services.

But there is an important boundary here. Core banking should not be directly reachable from the public internet in a way that makes it vulnerable to ordinary DDoS pressure. If a bank’s core systems, internal transactions or branch services were also disrupted, other explanations must be examined: architectural dependencies between external and internal services, defensive shutdowns to contain risk, disruption in intermediary services, problems in shared routes or a separate intrusion into the internal network.

Therefore, if the attack was truly only DDoS, the main crisis was not intrusion, but the overexposure of critical services to pressure points and insufficient separation. If the incident went beyond DDoS, the main crisis is the lack of transparency about the attacker’s level of access, the real scope of disruption and the status of the data.

One important point in analyzing DDoS attacks is that disruption of availability is not always the final objective. In cybersecurity literature, patterns such as diversionary DDoS or DDoS as a smokescreen are well known: an attacker creates widespread disruption to keep technical and security teams occupied, while more hidden activities may be taking place at the same time, such as unauthorized access, money transfers, changes to security settings, data exfiltration or malware deployment.

This pattern has a history in the financial sector. In some cases, noisy service-level disruption or mass calls to victims have been used to divert attention from the main operation. Agencies such as CISA have also warned that DDoS can be used as a distraction to conceal other malicious activity. Therefore, in the recent banking incident, although DDoS alone does not prove intrusion, the possibility that it was used as cover for a deeper operation cannot be dismissed either.

The main question, then, is not only whether the services were taken down by DDoS. The more important question is what else happened inside the network during the disruption. Were unusual access attempts recorded? Were security settings changed? Were logs deleted? Was there any sign of data transfer, lateral movement or internal access? These questions cannot be answered without the release of a technical report, IOCs, verifiable logs or a summary of the incident-response process.

Service Recovery, Data Uncertainty: Why the End of the Outage Does Not Mean the End of the Crisis

The return of some banking services did not mean the crisis was fully over. Banking services are not unified or equal in function; card purchases, balance inquiries or some simple transfers may come back online while SATNA, PAYA, checks, branch services, mobile banking or large transfers still depend on systems that remain under isolation, recovery, stability testing or operational restrictions. For this reason, resolving POS disruption does not necessarily mean the full recovery of a bank; it only shows that one access channel has been restored. This uneven recovery itself raises important technical questions.

Alongside the issue of recovery, the status of customer data still requires greater transparency. Officials say customer information has not been exposed, and no reliable public evidence has so far emerged to disprove that claim. But the absence of leaked data samples does not, by itself, prove that there was no unauthorized access. Because no independent technical report, IOC, forensic report or summary of the incident-response process has been released, claims about the complete security of the data cannot be publicly verified.

For now, the most accurate formulation is this: there is no public evidence of a customer data leak, but the absence of public evidence of a leak does not prove the absence of unauthorized access. If the incident was only an availability attack, the absence of data leakage is plausible. But if the attack did reach the shared service core or more sensitive layers of the banking infrastructure, the level of transparency must be much higher than general public statements.

Infrastructure Concentration: A Strength That Became a Point of Failure

Modern banking is almost impossible to imagine without shared services, central systems and coordinated interbank routes. Shetab, Shaparak, SATNA, PAYA, shared switches, service cores and infrastructure providers were all designed to increase speed, standardization and connectivity among banks. But the same concentration, if not accompanied by redundancy, proper separation, technical transparency and institutional accountability, can turn from an operational advantage into a systemic risk.

One naming ambiguity also needs to be clarified here. The phrase “National Informatics Services Company” is not precise. In Iran’s banking structure, a distinction should be made between the National Informatics Corporation as the holding-level entity and the Informatics Services Corporation, or Ranfour, as the operational arm. The Informatics Services Corporation is not merely an ordinary contractor; in Iran’s banking network, it is connected to core services, shared infrastructure and technical routes related to the Central Bank, card systems, Shetab, Shaparak, PAYA, SATNA and other shared services. This does not mean that all of these systems were affected in the recent incident. Officials have even said that some of these infrastructures remained active. The issue is that the declared incident appears to have occurred in the “shared service core” of several banks, and if disruption or an attack happens at such a layer, its effects can appear across multiple banks at the same time without each bank necessarily having been hacked separately. This concentration has at least three consequences.

1. First, operational concentration: when several major banks depend on a shared service, route, platform or core, disruption at that point can affect several banks at once. In such an architecture, each bank does not need to fail separately; damage or disruption in the shared layer can create a cascading effect.
2. Second, risk concentration: for an attacker, the shared point is more attractive than attacking each bank separately. If an attacker can pressure a central node, shared route, intermediary service or infrastructure provider, the effect can go beyond one bank and turn into a multi-bank crisis.
3. Third, ambiguity concentration: when an incident occurs, responsibility is spread among the banks, the Central Bank, the Informatics Services Corporation, shared systems and technical contractors. As a result, the public response often remains general, delayed and incomplete. For a citizen whose card, mobile banking or money transfer is not working, it is not clear who is ultimately responsible or which layer was actually affected.

For this reason, infrastructure concentration is defensible only when it is accompanied by redundant architecture, reliable failover, separation of critical services, transparent reporting and public accountability. Otherwise, the same mechanism that was supposed to make banking faster and more integrated can become a shared point of failure during a crisis.

Conclusion: Banking Security Means Resilience, Not Just Preventing Intrusion

An attack on financial infrastructure is not merely an attack on a bank or a company; it is an attack on public trust, people’s access to money and the perception of stability. In recent years, Iran’s financial sector has been targeted not only for extortion and theft, but also for disruption and psychological operations. This history makes the possibility of an attack in the recent incident meaningful, but it does not replace technical evidence for attribution, determining the level of intrusion or proving a data leak.

The main questions remain unanswered: which system or set of systems exactly made up the shared service core? Did the attack target only Bank Melli or the shared infrastructure of several banks? If it was DDoS, why did recovery take so long? If it went beyond DDoS, what level of access did the attacker have? The status of DR, failover, defensive shutdowns, hardware replacement and the role of groups such as TRoLL Team still require a technical report.

Even if TRoLL Team exaggerated its claims, even if no data was leaked and even if part of the outage resulted from defensive decisions, the recent incident revealed an important reality: Iran’s financial infrastructure is vulnerable at the shared-services layer in terms of risk concentration, recovery and incident communication. Banking security is not only about whether an attacker got in; it is about whether people can still access their money, cards, transfers and essential services during a crisis.