ブログ
/
Email
/
March 8, 2024

Malicious Use of Dropbox in Phishing Attacks

Understand the tactics of phishing attacks that exploit Dropbox and learn how to recognize and mitigate these emerging cybersecurity threats.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Ryan Traill
Analyst Content Lead
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
08
Mar 2024

Evolving Phishing Attacks

While email has long been the vector of choice for carrying out phishing attacks, threat actors, and their tactics, techniques, and procedures (TTPs), are continually adapting and evolving to keep pace with the emergence of new technologies that represent new avenues to exploit. As previously discussed by the Darktrace analyst team, several novel threats relating to the abuse of commonly used services and platforms were observed throughout 2023, including the rise of QR Code Phishing and the use of Microsoft SharePoint and Teams in phishing campaigns.

Dropbox Phishing Attacks

It should, therefore, come as no surprise that the malicious use of other popular services has gained traction in recent years, including the cloud storage platform Dropbox.

With over 700 million registered users [1], Dropbox has established itself as a leading cloud storage service celebrated for its simplicity in file storage and sharing, but in doing so it has also inadvertently opened a new avenue for threat actors to exploit. By leveraging the legitimate infrastructure of Dropbox, threat actors are able to carry out a range of malicious activities, from convincing their targets to unknowingly download malware to revealing sensitive information like login credentials.

Darktrace Detection of Dropbox Phishing Attack

Darktrace detected a malicious attempt to use Dropbox in a phishing attack in January 2024, when employees of a Darktrace customer received a seemingly innocuous email from a legitimate Dropbox address. Unbeknownst to the employees, however, a malicious link had been embedded in the contents of the email that could have led to a widespread compromise of the customer’s Software-as-a-Service (SaaS) environment. Fortunately for this customer, Darktrace / EMAIL quickly identified the suspicious emails and took immediate actions to stop them from being opened. If an email was accessed by an employee, Darktrace / IDENTITY was able to recognize any suspicious activity on the customer’s SaaS platform and bring it to the immediate detection of their security team.

Attack overview

Initial infection  

On January 25, 2024, Darktrace / EMAIL observed an internal user on a customer’s SaaS environment receiving an inbound email from ‘no-reply@dropbox[.]com’, a legitimate email address used by the Dropbox file storage service.  Around the same time 15 other employees also received the same email.

The email itself contained a link that would lead a user to a PDF file hosted on Dropbox, that was seemingly named after a partner of the organization. Although the email and the Dropbox endpoint were both legitimate, Darktrace identified that the PDF file contained a suspicious link to a domain that had never previously been seen on the customer’s environment, ‘mmv-security[.]top’.  

Darktrace understood that despite being sent from a legitimate service, the email’s initiator had never previously corresponded with anyone at the organization and therefore treated it with suspicion. This tactic, whereby a legitimate service sends an automated email using a fixed address, such as ‘no-reply@dropbox[.]com’, is often employed by threat actors attempting to convince SaaS users to follow a malicious link.

As there is very little to distinguish between malicious or benign emails from these types of services, they can often evade the detection of traditional email security tools and lead to disruptive account takeovers.

As a result of this detection, Darktrace / EMAIL immediately held the email, stopping it from landing in the employee’s inbox and ensuring the suspicious domain could not be visited. Open-source intelligence (OSINT) sources revealed that this suspicious domain was, in fact, a newly created endpoint that had been reported for links to phishing by multiple security vendors [2].

A few days later on January 29, the user received another legitimate email from ‘no-reply@dropbox[.]com’ that served as a reminder to open the previously shared PDF file. This time, however, Darktrace / EMAIL moved the email to the user’s junk file and applied a lock link action to prevent the user from directly following a potentially malicious link.

Figure 1: Anomaly indicators associated with the suspicious emails sent by ’no.reply@dropbox[.]com’, and the corresponding actions performed by Darktrace / EMAIL

Unfortunately for the customer in this case, their employee went on to open the suspicious email and follow the link to the PDF file, despite Darktrace having previously locked it.

Figure 2: Confirmation that the SaaS user read the suspicious email and followed the link to the PDF file hosted on Dropbox, despite it being junked and link locked.

Darktrace / NETWORK subsequently identified that the internal device associated with this user connected to the malicious endpoint, ‘mmv-security[.]top’, a couple of days later.

Further investigation into this suspicious domain revealed that it led to a fake Microsoft 365 login page, designed to harvest the credentials of legitimate SaaS account holders. By masquerading as a trusted organization, like Microsoft, these credential harvesters are more likely to appear trustworthy to their targets, and therefore increase the likelihood of stealing privileged SaaS account credentials.  

Figure 3: The fake Microsoft login page that the user was directed to after clicking the link in the PDF file.

Suspicious SaaS activity

In the days following the initial infection, Darktrace / IDENTITY began to observe a string of suspicious SaaS activity being performed by the now compromised Microsoft 365 account.

Beginning on January 31, Darktrace observed a number of suspicious SaaS logins from multiple unusual locations that had never previously accessed the account, including 73.95.165[.]113. Then on February 1, Darktrace detected unusual logins from the endpoints 194.32.120[.]40 and 185.192.70[.]239, both of which were associated with ExpressVPN indicating that threat actors may have been using a virtual private network (VPN) to mask their true location.

FIgure 4: Graph Showing several unusual logins from different locations observed by Darktrace/Apps on the affected SaaS account.

Interestingly, the threat actors observed during these logins appeared to use a valid multi-factor authentication (MFA) token, indicating that they had successfully bypassed the customer’s MFA policy. In this case, it appears likely that the employee had unknowingly provided the attackers with an MFA token or unintentionally approved a login verification request. By using valid tokens and meeting the necessary MFA requirements, threat actors are often able to remain undetected by traditional security tools that view MFA as the silver bullet. However, Darktrace’s anomaly-based approach to threat detection allows it to quickly identify unexpected activity on a device or SaaS account, even if it occurs with legitimate credentials and successfully passed authentication requirements, and bring it to the attention of the customer’s security team.

Shortly after, Darktrace observed an additional login to the SaaS account from another unusual location, 87.117.225[.]155, this time seemingly using the HideMyAss (HMA) VPN service. Following this unusual login, the actor was seen creating a new email rule on the compromised Outlook account. The new rule, named ‘….’, was intended to immediately move any emails from the organization’s accounts team directly to the ‘Conversation History’ mailbox folder. This is a tactic often employed by threat actors during phishing campaigns to ensure that their malicious emails (and potential responses to them) are automatically moved to less commonly visited mailbox folders in order to remain undetected on target networks. Furthermore, by giving this new email rule a generic name, like ‘….’ it is less likely to draw the attention of the legitimate account holder or the organizations security team.

Following this, Darktrace / EMAIL observed the actor sending updated versions of emails that had previously been sent by the legitimate account holder, with subject lines containing language like “Incorrect contract” and “Requires Urgent Review”, likely in an attempt to illicit some kind of follow-up action from the intended recipient.  This likely represented threat actors using the compromised account to send further malicious emails to the organization’s accounts team in order to infect additional accounts across the customer’s SaaS environment.

Unfortunately, Darktrace's Autonomous Response was not deployed in the customer’s SaaS environment in this instance, meaning that the aforementioned malicious activity did not lead to any mitigative actions to contain the compromise. Had RESPOND been enabled in autonomous response mode at the time of the attack, it would have quickly moved to log out and disable the suspicious actor as soon as they had logged into the SaaS environment from an unusual location, effectively shutting down this account takeover attempt at the earliest opportunity.

Nevertheless, Darktrace / EMAIL's swift identification and response to the suspicious phishing emails, coupled with Darktrace / IDENTITY's detection of the unusual SaaS activity, allowed the customer’s security team to quickly identify the offending SaaS actor and take the account offline before the attack could escalate further

Conclusion

As organizations across the world continue to adopt third-party solutions like Dropbox into their day-to-day business operations, threat actors will, in turn, continue to seek ways to exploit these and add them to their arsenal. As illustrated in this example, it is relatively simple for attackers to abuse these legitimate services for malicious purposes, all while evading detection by endpoint users and security teams alike.

By leveraging these commonly used platforms, malicious actors are able to carry out disruptive cyber-attacks, like phishing campaigns, by taking advantage of legitimate, and seemingly trustworthy, infrastructure to host malicious files or links, rather than relying on their own infrastructure. While this tactic may bypass traditional security measures, Darktrace’s Self-Learning AI enables it to recognize unusual senders within an organization’s email environment, even if the email itself seems to have come from a legitimate source, and prevent them from landing in the target inbox. In the event that a SaaS account does become compromised, Darktrace is able to identify unusual login locations and suspicious SaaS activities and bring them to the attention of the customer for remediation.

In addition to the prompt identification of emerging threats, Darktrace's Autonomous Response is uniquely placed to take swift autonomous action against any suspicious activity detected within a customer’s SaaS environment, effectively containing any account takeover attempts in the first instance.

Credit to Ryan Traill, Threat Content Lead, Emily Megan Lim, Cyber Security Analyst

Appendices

Darktrace Model Detections  

- Model Breach: SaaS / Access::Unusual External Source for SaaS Credential Use

- Model Breach: SaaS / Unusual Activity::Multiple Unusual External Sources For SaaS Credential

- Model Breach: SaaS / Access::Unusual External Source for SaaS Credential Use

- Model Breach: SaaS / Access::Unusual External Source for SaaS Credential Use

- Model Breach: SaaS / Unusual Activity::Multiple Unusual SaaS Activities

- Model Breach: SaaS / Unusual Activity::Unusual MFA Auth and SaaS Activity

- Model Breach: SaaS / Compromise::Unusual Login and New Email Rule

- Model Breach: SaaS / Compliance::Anomalous New Email Rule

- Model Breach: SaaS / Compliance::New Email Rule

- Model Breach: SaaS / Compromise::SaaS Anomaly Following Anomalous Login

- Model Breach: Device / Suspicious Domain

List of Indicators of Compromise (IoCs)

Domain IoC

mmv-security[.]top’ - Credential Harvesting Endpoint

IP Address

73.95.165[.]113 - Unusual Login Endpoint

194.32.120[.]40 - Unusual Login Endpoint

87.117.225[.]155 - Unusual Login Endpoint

MITRE ATT&CK Mapping

DEFENSE EVASION, PERSISTENCE, PRIVILEGE ESCALATION, INITIAL ACCESS

T1078.004 - Cloud Accounts

DISCOVERY

T1538 - Cloud Service Dashboard

RESOURCE DEVELOPMENT

T1586 - Compromise Accounts

CREDENTIAL ACCESS

T1539 - Steal Web Session Cookie

PERSISTENCE

T1137 - Outlook Rules

INITIAL ACCESS

T156.002 Spearphishing Link

Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Ryan Traill
Analyst Content Lead

More in this series

No items found.

Blog

/

Network

/

April 16, 2026

中国系サイバー作戦の進化 - それはサイバーリスクおよびレジリエンスにとって何を意味するか

Default blog imageDefault blog image

サイバーセキュリティにおいては、これまではインシデント、侵害、キャンペーン、そして脅威グループを中心にリスクを整理してきました。これらの要素は現在も重要です -しかし個別のインシデントにとらわれていては、エコシステム全体の形成を見逃してしまう危険があります。国家が支援する攻撃者グループは、個別の攻撃を実行したり短期的な目標を達成したりするためだけではなく、サイバー作戦を長期的な戦略上の影響力を構築するために使用するようになっています。  

当社の最新の調査レポート、Crimson Echoにおいてもこうした状況にあわせて視点を変えています。キャンペーンやマルウェアファミリー、あるいはアクターのラベルを個別のイベントとして分類するのではなく、ダークトレースの脅威調査チームは中国系グループのアクティビティを長期的に連続した行動として分析しました。このように視野を拡大することで、これらの攻撃者がさまざまな環境内でどのように存在しているか、すなわち、静かに、辛抱強く、持続的に、そして多くのケースにおいて識別可能な「インシデント」が発生するかなり前から下準備をしている様子が明らかになりました。  

中国系サイバー脅威のこれまでの変化

中国系サイバーアクティビティは過去20年間において4つのフェーズで進化してきたと言えます。初期の、ボリュームを重視したオペレーションは1990年代にから2000年代初めに見られ、それが2010年代にはより構造化された、戦略に沿った活動となり、そして現在の高度な適応性を備えた、アイデンティティを中心とした侵入へと進化しています。  

現在のフェーズの特徴は、大規模、攻撃の自制、そして永続化です。攻撃者はアクセスを確立し、その戦略的価値を評価し、維持します。これはより全体的な変化を反映したものです。つまりサイバー作戦は長期的な経済的および地政学的戦略に組み込まれる傾向が強まっているということです。デジタル環境へのアクセス、特に国家の重要インフラやサプライチェーン、先端テクノロジーにつながるものは、ある種の長期的な戦略的影響力と見られるようになりました。  

複雑な問題に対するダークトレースのビヘイビア分析アプローチ

国家が支援するサイバーアクティビティを分析する際、難しい問題の1つはアトリビューションです。従来のアプローチは多くの場合、特定の脅威グループ、マルウェアファミリー、あるいはインフラに判定を依存していました。しかしこれらは絶えず変化するものであり、さらに中国系オペレーションの場合、しばしば重複が見られます。

Crimson Echo は2022年7月から2025年9月の間の3年間にDarktrace運用環境で観測された異常なアクティビティを回顧的に分析した結果です。ビヘイビア検知、脅威ハンティング、オープンソースインテリジェンス、および構造化されたアトリビューションフレームワーク(Darktrace Cybersecurity Attribution Framework)を用いて、数十件の中~高確度の事例を特定し、繰り返し発生しているオペレーションのパターンを分析しました。  

この長期的視野を持ったビヘイビア中心型アプローチにより、ダークトレースは侵入がどのように展開していくかについての一定のパターンを特定することができ、動作のパターンが重要であることがあらためて確認されました。  

データが示していること

分析からいくつかの明確な傾向が浮かび上がりました:

  • 標的は戦略的に重要なセクターに集中していたのです。データセット全体で、侵入の88%は重要インフラと分類される、輸送、重要製造業、政府、医療、ITサービスを含む組織で発生しています。   
  • 戦略的に重要な西側経済圏が主な焦点です。米国だけで、観測されたケースの22.5%を占めており、ドイツ、イタリア、スペイン、および英国を含めた主要なヨーロッパの経済圏と合わせると侵入の半数以上(55%)がこれらの地域に集中しています。  
  • 侵入の63%近くがインターネットに接続されたシステムのエクスプロイトから始まっており、外部に露出したインフラの持続的リスクがあらためて浮き彫りになりました。  

サイバー作戦の2つのモデル

データセット全体で、中国系のアクティビティは2つの作戦モデルに従っていることが確認されました。  

1つ目は“スマッシュアンドグラブ”(強奪)型と表現することができます。これらはスピードのために最適化された短期型の侵入です。攻撃者はすばやく動き  – しばしば48時間以内にデータを抜き出し  – ステルス性よりも規模を重視します。これらの侵害の期間の中央値は10日ほどです。検知の危険を冒しても短期的利益を得ようとしていることが明らかです。  

2つ目は“ローアンドスロー”(低速)型です。これらのオペレーションはデータセット内ではあまり多くありませんでしたが、潜在的影響はより重大です。ここでは攻撃者は持続性を重視し、アイデンティティシステムや正規の管理ツールを通じて永続的なアクセスを確立し、数か月間、場合によっては数年にわたって検知されないままアクセスを維持しようとします。1つの注目すべきケースでは、脅威アクターは環境に完全に侵入して永続性を確立し、600日以上経ってからようやく再浮上した例もありました。このようなオペレーションの一時停止は侵入の深さと脅威アクターの長期的な戦略的意図の両方を表しています。このことはサイバーアクセスが長期にわたって保有し活用するべき戦略的資産であることを示しており、これは最も戦略的に重要なセクターにおいて最もよく見られたパターンです。  

同じ作戦エコシステムにおいて両方のモデルを並行して利用し、標的の価値、緊急性、意図するアクセスに基づいて適切なモデルを選択することも可能だという点に注意することも重要です。“スマッシュアンドグラブ” モデルが見られたからといって諜報活動が失敗したとのみ解釈すべきではなく、むしろ目標に沿った作戦上の選択かもしれないと見るべきでしょう。“ローアンドスロー” 型は粘り強い活動のために最適化され、“スマッシュアンドグラブ” 型はスピードのために最適化されています。どちらも意図的な作戦上の選択と見られ、必ずしも能力を表していません。  

サイバーリスクを再考する

多くの組織にとって、サイバーリスクはいまだに一連の個別のイベントとして位置づけられています。何かが発生し、検知され、封じ込められ、組織はそれを乗り越えて前に進みます。しかし永続的アクセスは、特にクラウド、アイデンティティベースのSaaSやエージェント型システム、そして複雑なサプライチェーンネットワークが相互接続された環境では、重大な持続的露出リスクを作り出します。システムの中断やデータの流出が発生していなくても、そのアクセスによって業務や依存関係、そして戦略的意思決定についての情報を得られるかもしれません。サイバーリスクはますます長期的な競合情報収集に似てきています。

その影響はSOCだけの問題ではありません。組織はガバナンス、可視性、レジリエンスについての考え方を見直し、サイバー露出をインシデント対応の問題ではなく構造的なビジネスリスクとして扱う必要があります。  

次の目標

この調査の目的は、これらの脅威の仕組みについてより明確な理解を提供することにより、防御者がより早期にこれらを識別しより効果的に対応できるようにすることです。これには、インジケーターの追跡からビヘイビアの理解にシフトすること、アイデンティティプロバイダーを重要インフラリスクとして扱うこと、サプライヤーの監視を拡大すること、迅速な封じ込めのための能力に投資すること、などが含まれます。  

ダークトレースの最新調査、Crimson Echo: Understanding Chinese-nexus Cyber Operations Through Behavioral Analysisについてより詳しく知るには、ビジネスリーダー、CISO、SOCアナリストに向けたレポート全文およびサマリーを ここからダウンロードしてください。 

Continue reading
About the author
Nathaniel Jones
VP, Security & AI Strategy, Field CISO

Blog

/

OT

/

April 16, 2026

Inside ZionSiphon: Darktrace’s Analysis of OT Malware Targeting Israeli Water Systems

Default blog imageDefault blog image

What is ZionSiphon?

Darktrace recently analyzed a malware sample, which identifies itself as ZionSiphon. This sample combines several familiar host-based capabilities, including privilege escalation, persistence, and removable-media propagation, with targeting logic themed around water treatment and desalination environments.

This blog details Darktrace’s investigation of ZionSiphon, focusing on how the malware identifies targets, establishes persistence, attempts to tamper with local configuration files, and scans for Operational Technology (OT)-relevant services on the local subnet. The analysis also assesses what the code suggests about the threat actor’s intended objectives and highlights where the implementation appears incomplete.

Function “ZionSiphon()” used by the malware author.
Figure 1: Function “ZionSiphon()” used by the malware author.

Targets and motivations

Israel-Focused Targeting and Messaging

The clearest indicators of intent in this sample are its hardcoded Israel-focused targeting checks and the strong political messaging found in some strings in the malware’s binary.

In the class initializer, the malware defines a set of IPv4 ranges, including “2.52.0.0-2.55.255.255”, “79.176.0.0-79.191.255.255”, and “212.150.0.0-212.150.255.255”, indicating that the author intended to restrict execution to a narrow range of addresses. All of the specified IP blocks are geographically located within Israel.

The malware obfuscates the IP ranges by encoding them in Base64.
Figure 2: The malware obfuscates the IP ranges by encoding them in Base64.

The ideological motivations behind this malware are also seemingly evident in two Base64-encoded strings embedded in the binary. The first (shown in Figure 1) is:

Netanyahu = SW4gc3VwcG9ydCBvZiBvdXIgYnJvdGhlcnMgaW4gSXJhbiwgUGFsZXN0aW5lLCBhbmQgWWVtZW4gYWdhaW5zdCBaaW9uaXN0IGFnZ3Jlc3Npb24uIEkgYW0gIjB4SUNTIi4=“, which decodes to “In support of our brothers in Iran, Palestine, and Yemen against Zionist aggression. I am "0xICS".

The second string, “Dimona = UG9pc29uaW5nIHRoZSBwb3B1bGF0aW9uIG9mIFRlbCBBdml2IGFuZCBIYWlmYQo=“, decodes to “Poisoning the population of Tel Aviv and Haifa”.  These strings do not appear to be used by the malware for any operational purpose, but they do offer an indication of the attacker’s motivations. Dimona, referenced in the second string, is an Israeli city in the Negev desert, primarily known as the site of the Shimon Peres Negev Nuclear Research Center.

The Dimona string as it appears in the decompiled malware, with the Base64-decoded text.
Figure 3: The Dimona string as it appears in the decompiled malware, with the Base64-decoded text.

The hardcoded IP ranges and propaganda‑style text suggest politically motivated intent, with Israel appearing to be a likely target.

Water and desalination-themed targeting?

The malware also includes Israel-linked strings in its target list, including “Mekorot, “Sorek”, “Hadera”, “Ashdod”, “Palmachim”, and “Shafdan”. All of the strings correspond to components of Israel’s national water infrastructure: Mekorot is Israel’s national water company responsible for managing the country’s water system, including major desalination and wastewater projects. Sorek, Hadera, Ashdod, and Palmachim are four of Israel’s five major seawater desalination plants, each producing tens of millions of cubic meters of drinking water annually. Shafdan is the country’s central wastewater treatment and reclamation facility. Their inclusion in ZionSiphon’s targeting list suggests an interest in infrastructure linked to Israel’s water sector.

Strings in the target list, all related to Israel and water treatment.
Figure 4: Strings in the target list, all related to Israel and water treatment.

Beyond geographic targeting, the sample contains a second layer of environment-specific checks aimed at water treatment and desalination systems. In the function ”IsDamDesalinationPlant()”, the malware first inspects running process names for strings such as “DesalPLC”, “ROController”, “SchneiderRO”, “DamRO”, “ReverseOsmosis”, “WaterGenix”, “RO_Pump”, “ChlorineCtrl”, “WaterPLC”, “SeaWaterRO”, “BrineControl”, “OsmosisPLC”, “DesalMonitor”, “RO_Filter”, “ChlorineDose”, “RO_Membrane”, “DesalFlow”, “WaterTreat”, and “SalinityCtrl”. These strings are directly related to desalination, reverse osmosis, chlorine handling, and plant control components typically seen in the water treatment industry.

The filesystem checks reinforce this focus. The code looks for directories such as “C:\Program Files\Desalination”, “C:\Program Files\Schneider Electric\Desal”, “C:\Program Files\IDE Technologies”, “C:\Program Files\Water Treatment”, “C:\Program Files\RO Systems”, “C:\Program Files\DesalTech”, “C:\Program Files\Aqua Solutions”, and “C:\Program Files\Hydro Systems”, as well as files including “C:\DesalConfig.ini”, “C:\ROConfig.ini”, “C:\DesalSettings.conf”, “C:\Program Files\Desalination\system.cfg”, “C:\WaterTreatment.ini”, “C:\ChlorineControl.dat”, “C:\RO_PumpSettings.ini”, and “C:\SalinityControl.ini.”

Malware Analysis

Privilege Escalation

The “RunAsAdmin” function from the malware sample.
Figure 5: The “RunAsAdmin” function from the malware sample.


The malware’s first major action is to check whether it is running with administrative rights. The “RunAsAdmin()” function calls “IsElevated()”, which retrieves the current Windows identity and checks whether it belongs to the local Administrators group. If the process is already elevated, execution proceeds normally.

The “IsElevated” function as seen in the sample.
Figure 6: The “IsElevated” function as seen in the sample.


If not, the code waits on the named mutex and launches “powershell.exe” with the argument “Start-Process -FilePath <current executable> -Verb RunAs”, after which it waits for that process to finish and then exits.

Persistence and stealth installation

Registry key creation.
Figure 7: Registry key creation.

Persistence is handled by “s1()”. This routine opens “HKCU\Software\Microsoft\Windows\CurrentVersion\Run”, retrieves the current process path, and compares it to “stealthPath”. If the current file is not already running from that location, it copies itself to the stealth path and sets the copied file’s attributes to “hidden”.

The code then creates a “Run” value named “SystemHealthCheck” pointing to the stealth path. Because “stealthPath” is built from “LocalApplicationData” and the hardcoded filename “svchost.exe”, the result is a user-level persistence mechanism that disguises the payload under a familiar Windows process name. The combination of a hidden file and a plausible-sounding autorun value suggests an intent to blend into ordinary Windows artifacts rather than relying on more complex persistence methods.

Target determination

The malware’s targeting determination is divided between “IsTargetCountry()” and “IsDamDesalinationPlant()”. The “IsTargetCountry()” function retrieves the local IPv4 address, converts it to a numeric value, and compares it against each of the hardcoded ranges stored in “ipRanges”. Only if the address falls within one of these ranges does the code move on to next string-comparison step, which ultimately determines whether the country check succeeded.

The main target validation function.
Figure 8: The main target validation function.
 The “IsTargetCountry” function.
Figure 9 : The “IsTargetCountry” function.


IsDamDesalinationPlant()” then assesses whether the host resembles a relevant OT environment. It first scans running process names for the hardcoded strings previously mentioned, followed by checks for the presence of any of the hardcoded directories or files. The intended logic is clear: the payload activates only when both a geographic condition and an environment specific condition related to desalination or water treatment are met.

Figure. 10: An excerpt of the list of strings used in the “IsDamDesalinationPlant” function

Why this version appears dysfunctional

Although the file contains sabotage, scanning, and propagation functions, the current sample appears unable to satisfy its own target-country checking function even when the reported IP falls within the specified ranges. In the static constructor, every “ipRanges” entry is associated with the same decoded string, “Nqvbdk”, derived from “TnF2YmRr”. Later, “IsTargetCountry()” (shown in Figure 8) compares that stored value against “EncryptDecrypt("Israel", 5)”.

The “EncryptDecrypt” function
Figure 11: The “EncryptDecrypt” function

As implemented, “EncryptDecrypt("Israel", 5)” does not produce “Nqvbdk”, it produces a different string. This function seems to be a basic XOR encode/decode routine, XORing the string “Israel” with value of 5. Because the resulting output does not match “Nqvbdk” the comparison always fails, even when the host IP falls within one of the specified ranges. As a result, this build appears to consistently determine that the device is not a valid target. This behavior suggests that the version is either intentionally disabled, incorrectly configured, or left in an unfinished state. In fact, there is no XOR key that would transform “Israel” into “Nqvbdk” using this function.

Self-destruct function

The “SelfDestruct” function
Figure 12: The “SelfDestruct” function

If IsTargetCountry() returns false, the malware invokes “SelfDestruct()”. This routine removes the SystemHealthCheck value from “HKCU\Software\Microsoft\Windows\CurrentVersion\Run”, writes a log file to “%TEMP%\target_verify.log” containing the message “Target not matched. Operation restricted to IL ranges. Self-destruct initiated.” and creates the batch file “%TEMP%\delete.bat”. This file repeatedly attempts to delete the malware’s executable, before deleting itself.

Local configuration file tampering

If the malware determines that the system it is on is a valid target, its first action is local file tampering. “IncreaseChlorineLevel()” checks a hardcoded list of configuration files associated with desalination, reverse osmosis, chlorine control, and water treatment OT/Industrial Control Systems (ICS).  As soon as it finds any one of these file present, it appends a fixed block of text to it and returns immediately.

The block of text appended to relevant configuration files.
Figure 13: The block of text appended to relevant configuration files.

The appended block of text contains the following entries: “Chlorine_Dose=10”, “Chlorine_Pump=ON”, “Chlorine_Flow=MAX”, “Chlorine_Valve=OPEN”, and “RO_Pressure=80”. Only if none of the hardcoded files are found does the malware proceed to its network-based OT discovery logic.

OT discovery and protocol logic

This section of the code attempts to identify devices on the local subnet, assign each one a protocol label, and then attempt protocol-specific communication. While the overall structure is consistent across protocols, the implementation quality varies significantly.

Figure 14: The ICS scanning function.

The discovery routine, “UZJctUZJctUZJct()”, obtains the local IPv4 address, reduces it to a /24 prefix, and iterates across hosts 1 through 255. For each host, it probes ports 502 (Modbus), 20000 (DNP3), and 102 (S7comm), which the code labels as “Modbus”, “DNP3”, and “S7” respectively if a valid response is received on the relevant port.

The probing is performed in parallel. For every “ip:port” combination, the code creates a task and attempts a TCP connection. The “100 ms” value in the probe routine is a per-connection timeout on “WaitOne(100, ...)”, rather than a delay between hosts or protocols. In practice, this results in a burst of short-lived OT-focused connection attempts across the local subnet.

Protocol validation and device classification

When a connection succeeds, the malware does not stop at the open port. It records the endpoint as an “ICSDevice” with an IP address, port, and protocol label. It then performs a second-stage validation by writing a NULL byte to the remote stream and reading the response that comes back.

For Modbus, the malware checks whether the first byte of the reply is between 1 and 255, for DNP3, it checks whether the first two bytes are “05 64”, and for S7comm, it checks whether the first byte is “03”. These checks are not advanced parsers, but they do show that the author understood the protocols well enough to add lightweight confirmation before sending follow-on data.

 The Modbus read request along with unfinished code for additional protocols.
Figure 15: The Modbus read request along with unfinished code for additional protocols.  

The most developed OT-specific logic is the Modbus-oriented path. In the function “IncreaseChlorineLevel(string targetIP, int targetPort, string parameter)”, the malware connects to the target and sends “01 03 00 00 00 0A”. It then reads the response and parses register values in pairs. The code then uses some basic logic to select a register index: for “Chlorine_Dose”, it looks for values greater than 0 and less than 1000; for “Turbine_Speed”, it looks for values greater than 100.

The Modbus command observed in the sample (01 03 00 00 00 0A) is a Read Holding Registers request. The first byte (0x01) represents the unit identifier, which in traditional Modbus RTU specifies the addressed slave device; in Modbus TCP, however, this value is often ignored or used only for gateway routing because device addressing is handled at the IP/TCP layer.

The second byte (0x03) is the Modbus function code indicating a Read Holding Registers request. The following two bytes (0x00 0x00) specify the starting register address, indicating that the read begins at address zero. The final two bytes (0x00 0A) define the number of registers to read, in this case ten consecutive registers. Taken together, the command requests the contents of the first ten holding registers from the target device and represents a valid, commonly used Modbus operation.

If a plausible register is found, the malware builds a six-byte Modbus write using function code “6” (Write)” and sets the value to 100 for “Chlorine_Dose”, or 0 for any other parameter. If no plausible register is found, it falls back to using hardcoded write frames. In the main malware path, however, the code only calls this function with “Chlorine_Dose".

If none of the ten registers meets the expected criteria, the malware does not abandon the operation. Instead, it defaults to a set of hardcoded Modbus write frames that specify predetermined register addresses and values. This behavior suggests that the attacker had only partial knowledge of the target environment. The initial register-scanning logic appears to be an attempt at dynamic discovery, while the fallback logic ensures that a write operation is still attempted even if that discovery fails.

Incomplete DNP3 and S7comm Logic

The DNP3 and S7comm branches appear much less complete. In “GetCommand()”, the DNP3 path returns the fixed byte sequence “05 64 0A 0C 01 02”, while the S7comm path returns “03 00 00 13 0E 00”. Neither sequence resembles a fully formed command for the respective protocol.

In the case of the S7comm section, the five byte‑ sequence found in the malware sample (05 00 1C 22 1E) most closely matches the beginning of an S7comm parameter block, specifically the header of a “WriteVar (0x05)” request, which is the S7comm equivalent of a Modbus register write operation. In the S7comm protocol, the first byte of a parameter block identifies the function code,  but the remaining bytes in this case do not form a valid item definition. A vaild S7 WriteVar parameter requires at least one item and a full 11-byte variable-specification structure. By comparison this 5‑ byte array is far too short to be a complete or usable command.

The zero item count (0x00) and the trailing three bytes appear to be either uninitialized data or the beginning of an incomplete address field. Together, these details suggest that the attacker likely intended to implement S7 WriteVar functionality, like the Modbus function, but left this portion of the code unfinished.

The DNP3 branch of the malware also appears to be only partially implemented. The byte sequence returned by the DNP3 path (05 64 0A 0C 01 02) begins with the correct two‑byte DNP3 link‑layer sync header (0x05 0x64) and includes additional bytes that resemble the early portion of a link‑layer header. However, the sequence is far too short to constitute a valid DNP3 frame. It lacks the required destination and source address fields, the 16‑bit CRC blocks, and any application‑layer payload in which DNP3 function code would reside. As a result, this fragment does not represent a meaningful DNP3 command.

The incomplete S7 and DNP3 fragments suggest that these protocol branches were still in a developmental or experimental state when the malware was compiled. Both contain protocol‑accurate prefixes, indicating an intent to implement multi‑protocol OT capabilities, however for reasons unknow, these sections were not fully implemented or could not be completed prior to deployment.

USB Propagation

The malware also includes a removable-media propagation mechanism. The “sdfsdfsfsdfsdfqw()” function scans for drives, selects those identified as removable, and copies the hidden payload to each one as “svchost.exe” if it is not already present. The copied executable is marked with the “Hidden” and “System” attributes to reduce visibility.

The malware then calls “CreateUSBShortcut()”, which uses “WScript.Shell” to create .lnk files for each file in the removable drive root. Each shortcut’s TargetPath is set to the hidden malware copy, the icon is set to “shell32.dll, 4” (this is the windows genericfile icon), and the original file is hidden. Were a victim to click this “file,” they would unknowingly run the malware.

Figure 14:The creation of the shortcut on the USB device.

Key Insights

ZionSiphon represents a notable, though incomplete, attempt to build malware capable of malicious interaction with OT systems targeting water treatment and desalination environments.

While many of ZionSiphon’s individual capabilities align with patterns commonly found in commodity malware, the combination of politically motivated messaging, Israel‑specific IP targeting, and an explicit focus on desalination‑related processes distinguishes it from purely opportunistic threats. The inclusion of Modbus sabotage logic, filesystem tampering targeting chlorine and pressure control, and subnet‑wide ICS scanning demonstrates a clear intent to interact directly with industrial processes controllers and to cause significant damage and potential harm, rather than merely disrupt IT endpoints.

At the same time, numerous implementation flaws, most notably the dysfunctional country‑validation logic and the placeholder DNP3 and S7comm components, suggest that analyzed version is either a development build, a prematurely deployed sample, or intentionally defanged for testing purposes. Despite these limitations, the overall structure of the code likely indicates a threat actor experimenting with multi‑protocol OT manipulation, persistence within operational networks, and removable‑media propagation techniques reminiscent of earlier ICS‑targeting campaigns.

Even in its unfinished state, ZionSiphon underscores a growing trend in which threat actors are increasingly experimenting with OT‑oriented malware and applying it to the targeting of critical infrastructure. Continued monitoring, rapid anomaly detection, and cross‑visibility between IT and OT environments remain essential for identifying early‑stage threats like this before they evolve into operationally viable attacks.

Credit to Calum Hall (Cyber Analyst)
Edited by Ryan Traill (Content Manager)

References

1.        https://www.virustotal.com/gui/file/07c3bbe60d47240df7152f72beb98ea373d9600946860bad12f7bc617a5d6f5f/details

Continue reading
About the author
あなたのデータ × DarktraceのAI
唯一無二のDarktrace AIで、ネットワークセキュリティを次の次元へ