Implications of TRITON attack on the Future of ICS Security
Explore how the TRITON malware attack reshapes OT cybersecurity strategies and the necessary steps to protect ICS networks effectively. Learn more here!
No items found.
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.
No items found.
Share
21
Jan 2018
The recent TRITON malware attack against a critical infrastructure organization sought to modify and manipulate industrial safety systems with the intention of causing potentially catastrophic physical damage. ICS systems create an interface between physical and digital environments, meaning that the repercussions of an unhandled failure can be fatal.
The TRITON campaign can be divided into two conceptual phases. First, the attackers managed to gain remote access to an engineering workstation attached to the SIS (Safety Instrumented System) network, after which they deployed a program that was masquerading as a legitimate application produced by a critical control and system safety supplier. The framework for mimicking this legitimate application is not readily available, so there is reason to believe TRITON is the creation of well-funded and highly capable actors with intentions that probably reach beyond minor monetary gains.
The attackers successfully subverted traditional network defenses. Once they had established this foothold, they opted to delve deeper into the network and perform detailed reconnaissance – the second phase of the attack. Thankfully, they accidentally triggered a partial system failure which the internal security team investigated and remediated.
Having failed to achieve their ultimate goal, the attackers will likely be evaluating where they went wrong, so that next time they don’t give themselves away at such a late stage. They may also be considering whether that reconnaissance step is worthwhile, as clearly, they were capable of significant sabotage from that location without any further chances to be caught. Their success in penetrating the network as far as they did undetected with their current tools and methods means that they will almost certainly use them against other organizations.
TRITON should be considered a significant precedent for ICS security. What this incident shows is that traditional demilitarized zones, heavy network segregation and multiple firewalls are definitively not sufficient to protect the essentially defenseless machines that make up ICS networks. How then should infrastructure providers adjust their security postures in the light of the TRITON attack?
With regards to the second phase, anomaly detection is a clear solution for pinpointing unusual activity within the control system, highlighting unexpected reprogramming or reconnaissance for the security team’s attention. The typically predictable communications made between ICS devices such as HMIs and PLCs are intuitively a fertile ground for this type of approach. Regulators have taken notice, and in the UK for example the incoming NIS Directive legislation mandates that critical infrastructure providers have anomaly detection for their relevant networks.
However, defenders do not want their first opportunity to catch the attacker to be when they have already reached the control system and are making use of automation protocols and exploiting inherently vulnerable devices. They want to be alerted to the earlier parts of the cyber kill chain, as the attacker makes their way towards these networks, and be able to remediate them there instead. This can only be achieved by extending the anomaly and cyber-threat detection outwards from the control system through the other networks (demilitarized zones, corporate) that can form defensive buffers around it.
This is why Darktrace’s Industrial Immune System is designed to monitor all of these networks simultaneously, embracing the full range of device types from PLCs out through the nearly standard IT systems in OT control rooms, and all the way to the edge of the organization’s possible visibility – even into the cloud if need be. It is not sufficient for those tasked with protecting control system to monitor just the automation protocols or the networks that contain them.
No items found.
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.
“I wonder if running that tool influenced the connectivity in some way.”
“I might need to target down or reboot, but first, I'll investigate the network using ARP. I wonder if ARP is responding properly. If I see "ip neigh stale," that could indicate a problem. I think arping might help in this situation, but I’ll need to keep an eye on how the network is behaving. It's all about figuring out where the issue lies!”
図10：エージェントの異常なLDAPアクティビティに対してトリガーされたこのLinuxサーバーに対するモデル検知は、Cyber AI Analystによって自律的に調査され、その調査結果にはエージェントの異常なSMBセッションアクティビティに関する内容が含まれ、Cyber AIAnalystインシデントに記録されました。
DarktraceのCyber AI Analystは、エージェントのアクティビティによってトリガーされたモデル検知を自律的に調査し、その調査結果を1つの重要なインシデントレポートにまとめました。インシデント報告書の内容は、エージェントによるネットワークスキャンから始まりコーディング演習内容のSMBベースの上書きで終わる、エージェントの行動の各段階を詳しくカバーしています。
図20：Cyber AI Analystは、モデル検知に対する自律的な調査を通じて得られた所見をつなぎ合わせ、エージェントの進行状況のタイムラインを作成し、アクティビティを視覚的に表したグラフとともに提供しました。
Cyber Verification Program下のAnthropic Opus 4.6モデルなど、他のフロンティアモデルを使用したエージェントも、Darktraceのシミュレートされた環境で同じ設定とタスクを使ってテストされました。反復の度に、エージェントは演習の内容または採点プログラムを変更して不正を行おうとしました。基盤となるモデルに関係なく、エージェントは自分が置かれた環境を侵害することで、100％のスコアを達成する方法を見つけることに成功していました。これらのエージェントによるハッキングは、アクティビティの内容こそ違っていましたが、すべてその環境のベースラインの振る舞いから大きく逸脱した動作を引き起こしていました。これらの逸脱はDarktraceプラットフォームに十分な検知の機会を提供し、エージェントの逃げ場はありませんでした。
エージェンティックハーネスは会話履歴をローカルに保存しますが、ダークトレースの研究者たちは、保存されたAIの応答が本当にモデルによって生成されたものであるかどうかの検証が行われていないことを発見しました。また、この設計上の選択がAnthropic Claude Code、AWS Kiro-CLI、OpenAI Codex、およびオープンソースのPiにわたって共通していることを確認しました。
会話履歴は多くの場合クライアント側に保存されます。例えば、Anthropic Claude Code、OpenAI Codex、AWS Kiro-CLI、Piなどでもそうです。そのため、ユーザーはセッションを自由に再開でき、一部の製品にはその履歴を操作する機能が組み込まれています。たとえば、会話の中の特定の時点に戻り、送信したメッセージを編集して、会話を別の軌道へ進めていくことができます。きわめて重要な点として、私たちが調査したすべてのケースにおいて、保存されているAIの応答が対応するモデルから生成されたものであり改ざんされていないことの検証は行われていませんでした。
