- ウクライナのハッカーグループが軍情報機関と協力し、ロシアの主要ドローン製造会社 Gaskar Integration のITインフラを機能停止に追い込む
- 47TBを超える重要データとバックアップ資料が削除され、中核事業の運営が中断
- 工場内部システムと会計、生産プログラムがすべて動作不能な状態に陥る
- 生産工場の出入口の扉まで封鎖され、従業員は非常口を使って出入り
- 窃取されたデータには従業員の個人情報やドローンの技術文書が含まれ、ウクライナ国防省に提供される
主な内容
- ウクライナのサイバー活動家は軍情報機関と協力し、ロシア軍にドローンを供給する最大級の製造会社の一つである Gaskar Integration のネットワークとサーバーインフラを攻撃
- この攻撃により47TBを超える技術情報と10TBのバックアップ資料まで破壊され、当該データにはロシアと中国の緊密な協力の状況も含まれている
- ハッキングにより、インターネット、製造プログラム、会計プログラムなど企業内のすべてのシステムが麻痺し、Gaskarの研究開発センターも正常な運営が不可能になる
- すべてのドローン生産工場内の出入口が封鎖され、従業員が非常口を通って退勤・移動しなければならない状況が発生
- 窃取した情報には従業員の機密アンケート、ドローン生産に関する技術文書などが含まれており、その情報はウクライナ国防省傘下の専門家たちに引き渡される
追加の背景
- 軍情報局所属のサイバー専門家は以前にも、ロシア鉄道のウェブサイトを強力な攻撃で無効化した事例がある
- 過去にもロシアのRegiontransserviceに対する攻撃を成功させ、すべてのサービスを停止させた実績がある
1件のコメント
Hacker Newsのコメント
自宅で小規模なラボを運用していて、サービスは30個くらいある。
ある日メインディスクを交換した際、バックアップを使ってすべてをゼロから再構築したが、1時間で復旧できた。
しかしその後1週間、あちこちを修正したり、なぜこんな設定にしたのか思い出せない部分まで面倒を見るのに苦労した。
これは1人で管理しているシンプルなDockerベースのラボで、私自身もITの仕事をしている。
でも、複数の人が何年もかけて管理してきたインフラ全体をゼロから復旧するのは、本当にとてつもない仕事だ。
近所の病院がランサムウェア被害に遭ったとき、ボランティアで復旧を手伝ったことがあるが、そこのIT担当2人は何をすべきかまったく分かっておらず、公式の支援も期待外れだった。
大企業のランサムウェア事故も手伝ったことがあるが、なぜシステムがこう構成されているのかを思い出そうとする労力が非常に大きかった。
文書化やテストはされていたとしても、本番では現実の壁を思い知らされる。
昔、警察の家宅捜索を受けて、デスクトップ、ノートPC、NAS、ハードドライブなど1万ドル分の機材を持っていかれたことがある。
前職でバックアップと災害復旧計画を担当していたおかげで、準備はしてあった。
1〜2日で大半を復旧でき、データ損失は2日分ほどだった。幸い自宅用だったので致命的ではなかった。
この出来事をきっかけにさまざまな構造的改善を行い、今後同様の被害はさらに小さくできるようになった。
（そして8か月後、警察は私が無実だと結論づけて機材を返却するよう指示したが、子どもたちはトラウマを負った。）
文書化が本当に重要な理由がこれだ。ソフトウェアアーキテクチャのレベルでも同じ。
数か月もすれば、なぜこの選択をしたのか自分でも忘れがちだ。
たとえば「なぜORM/SQLツールにKyselyを選んだのか」「なぜDeno/Bunを使うのか」「フォルダ構成を機能単位にした理由」「ライブラリをforkした理由とその管理方法」「AWS/GCP/Azure/ Dockerを選んだ理由」「Kubernetesディストリビューションを選んだ理由」「そもそもこのプロジェクトを始めた理由や目標は何か」など。
だからREADME.mdに # Decisions セクションを作って文書化している。
おかげで、自分の判断を延々と疑いながらドキュメントを掘り返し続ける苦行から解放された。
90年代のメインフレームはあまりにも安定していて冗長構成もしっかりしていたので、10年以上再起動しないこともあったし、カーネルですら無停止アップグレードできた。
ところが、ある会社で停電が起き、非常用発電機も失敗して、電源が戻ったときには、そのマシンが実際に何をしていたのか、どう起動すべきなのかを把握するのに数か月かかった。
その後、多くの会社が6か月に1回、メインフレームを意図的に再起動して再立ち上げのテストをするようになった。
現代のIT運用では、災害復旧がほとんど考慮されていない。
厳格にバックアップしている組織でも、実際に復元テストまで行うケースはまれだ。
人手が足りないので、とにかく早く何かを積み上げるだけになりがちだ。
再構成しやすいインフラを設計するのは、ただ導入するだけの2倍の労力がかかる。
病院のランサムウェア復旧をボランティアで手伝った話が気になる。
ヘルスケアITではアクセス権限を非常に厳格に扱うので、以前ならPHI研修や身元調査なしではシステムに触れなかったはずだが、緊急事態ということで迅速な臨時オンボーディング手続きを踏んだのか、それとも病院内の人脈経由でボランティア参加したのかを聞いてみたい。
私はドイツの会社で働いている。
生産管理は3か月前の計画をExcelで印刷して回している。
ERPシステムのマイグレーションに失敗したが、誰も解決方法を知らない。
生産管理部門はその事実を隠していて、エンジニアリング部門にも伝えていない。
この状況は何年も続きそうで、コンサルタントの飯の種になっている。
製造にITインフラは必須ではないことを証明している。なくてもいい、あれば便利という程度だ。
90年代末から2000年代初頭、デンマーク国防省でSAPベースの新しい調達システムDeMarsを導入しようとしていた。
調達業務をしていた友人は、DeMars導入直前に自分の担当物資をとてつもない量まとめて発注し、詐欺の疑いで呼び出されたことさえあった。
DeMarsへの不信感が強く、在庫を持つことが重要だと判断したからだ。
実際、DeMarsが導入されると調達業務は1年間ほぼ停止した。
結局、友人の担当品目だけが新システム導入期間を通じて在庫を維持できた。
90年代後半、製造業でファームウェア開発者として働いていた。
まだ何もかも紙に記録していた時代だった。
社内でOracleベースのERPを無事構築して皆が喜んでいたが、6か月後、誰かが機械室の壁にフォークリフトをぶつけ、UPSから出火してOracleサーバーなど3ラック分の機材が全焼した。
誰もシステムを完全には信用しておらず、依然として紙でも記録していたため、6年後に退職するまで紙＋Excelの帳票で仕事をしていた。
結果として、紙ベースの方法はフォークリフトにも強いことが証明された。
Excelは多くの事務職社員が直感的に理解して修正できる。
ITインフラの大半にも、こうしたアクセスしやすい機能が導入されれば、もっと実用的になる気がする。
一方で、IT自動化が生産現場に完全に根付き、以前の手作業方式に慣れた人材がいなくなっていると、手動運用に戻すのは本当に難しいこともある。
注文やワークフローの複雑さにもよるだろうが。
ソフトウェアがなければドローンも役に立たない。
部品在庫を覚えていれば、手動操縦用のクアッドコプターを組み立てる程度はできるかもしれないが、3Dプリント部品の生産、安定飛行、自律運航、監視、その他の高度な運用は不可能だ。
遠隔操作も難しいだろう。
ウクライナでのサイバー戦は新たな段階に達しつつあり、単なるサイバー攻撃を超え始めている。
今回攻撃を受けたロシアのドローン製造施設のように、ドローンはこの戦争の様相を変えた中核的存在だ。
ドローンは偵察、妨害、弾薬迎撃などの革新をもたらしている。
材料費に対して破壊力が大きく、映像認識技術の進歩によって、電波妨害下でも一部は機能する。
まるでスパイ映画のような現実が進行している。
ウクライナが非対称戦の達人であることを示している。
長距離爆撃機の破壊やドローン生産拠点の麻痺によって、ロシアの主力戦力を揺さぶっている。
戦争がどう終わるかは分からないが、ウクライナの抵抗が続くことだけは明らかだ。
小説 Ministry of the Future では、ドローンが発達しすぎた結果、誰も安全ではない世界になり、伝統的な戦争が意味を失う未来が描かれている。
小さな集団でも世界中のどこででも誰でも暗殺できるようになる。
面白くはあるが、物語としては弱いので、本そのものはあまりおすすめしない。
「電波妨害下でも動作するドローン」について言えば、最近は電磁波を使わず、光ファイバーケーブルで制御されるドローンもある。さらに恐ろしい現実だ。
今回の戦争でドローンが重要な役割を果たしていることが、今後ほかの戦争にもそのまま当てはまるかは見守る必要がある。
ロシアが莫大な人的損失を受け入れながら少しずつ前進しているという特殊事情が、FPVドローンの価値を高めている。
ほとんどの国はそこまでの損失を受け入れないだろうから、この形が戦争の標準になるとは思えない。
むしろ安価な長距離ジェットドローンの方が重要な役割を担うようになるかもしれない。
記事にある情報には推測がかなり混じっている。
こちらが聞いているのは一方の話だけで、プロパガンダ価値のために誇張されている可能性もある。
バージョン管理がきちんとしていて、各開発者がコードやCADファイルをローカルにコピーしているのは普通のことだ。
メールやオフィス文書などは失われたかもしれないが、それが致命的損失とは限らない。
Webサイトもそのまま動いている。
今回攻撃を受けたこの会社は、ドローンコミュニティでも特に有名なところではないので、大型モデルの生産停止のような話ではなさそうだ。
バージョン管理のような常識を知らないはずもないし、コメントの文体がChatGPTっぽい気もする。
私はスイスの中堅企業で働いている。
自社ERPを開発中だが、スタックは悪夢そのものだ。
自分たちではこれを「混乱によるセキュリティ」と呼んでいる。
攻撃者が侵入しても、たぶん抜け出せないだろう。
コードの90%が破壊されてもサービスに影響はない。なぜなら95%はすでに役に立たないコードだからだ。
大企業向けMRPシステムを自分で開発したことがあるので、このやり方がどう転ぶのか気になる。
私は通常、推奨されるセキュリティ／災害復旧方式に加え、OTPハッシュベースの鍵認証レイヤーまで追加する。
自分でもやりすぎ気味だと思っていたが、このシステムはほとんど世紀末サバイバルのシナリオのように感じる。
これは進化の過程で生まれたレジリエンスのようにも見える。
現実世界のICEの壁みたいで笑う。
怖くもあるが、感心する面もある。
ほとんどの企業は、社内のほぼすべてのデータストアが完全消去され、ゼロから再デプロイしなければならない状況を明確には想定していない。
実際にゼロから復旧したことがないなら、デプロイ依存関係に循環がある可能性が高い。
Jenkins/Puppet/Ansibleでconfig pusherをデプロイしているうちに、ある時点でJenkins自体もconfig pusherに依存するようになり、単純に順番に構築できなくなって、過去からすべての変更履歴をたどり直す羽目になる。
ITにはほとんどあらゆる場所に循環依存がある。
SSOがほぼすべてのシステムの依存先になり、SSO内のネットワークや各種システム管理にも循環構造が生まれる。
完全なコールドスタートは常に難しく、時間もかかる。
完全に分離した二重インフラを構築しない限り、この問題を完全に解決するのは実質不可能だ。
私の知るある会社も、1年前に同じようなことを経験した。
すべてが依存していたメインのストレージクラスタが死んだ。
結局、開発者のノートPCからすべてを再デプロイして復旧した。
black start（完全初期化からの復旧）はものすごく難しい問題だ。
Facebookも過去に、データセンターのドアロックをドリルでこじ開けて復旧したことがある。
こういう状況で、どうすれば復旧できるのか気になる。
紙の文書でも残っていればそれでブートストラップ可能なのか、それともそれすら失われた前提で考えるべきなのか、疑問だ。
建設業も似た問題を抱えている。
製品寿命が50年以上、ひどい場合は数百年にもなるのに、30年前に作った設計ファイルが今ではファイル形式の互換性の問題で開けないことが多い。
デジタル化の話は何十年も前からあるが、結局、古い2D図面（あるいは今でいう「デジタルな紙」であるPDF）が将来役立つかもしれない。
本物の紙の使用は減っているが、ファイル互換性の問題を考えると、結局は紙が有用になる可能性があると思う。
記事タイトルでは攻撃者が「サイバーアクティビスト」とされているのに、本文では「サイバー犯罪者」と呼ばれている。
昔の帆船時代の私掠船や拿捕免許のように、境界線上で行動する存在を思い出す。
第四世代戦争論では、民間と軍事の境界が曖昧になるのが特徴だった。
交戦規則はますます不明瞭になっている。
ロシアは毎日ドローンで民間人を殺している。
これはグレーゾーンのハイブリッド戦争のような曖昧な話ではなく、ただ市民が隣人をドローンの犠牲にさせないようにしているだけだ。
これは翻訳の問題っぽい。
そのサイトはウクライナ寄りの色が強いので、ハッカーを悪く見せたくなくて、
cyber criminalを単に「ハッカー」程度の意味で使ったのかもしれない。実際にはウクライナ軍が組織的に動いていると考えるのがいちばん妥当だろう。
だから犯罪者ではないと見るべきだ。
ロビンフッドのような話だ。
ある人には英雄で、別の人には犯罪者。
たぶん記事自体が複数の記事を継ぎ合わせたもので、用語が混ざったのだろう。
サイバー戦で陣営を分けて語るための別の用語があればいいのにと思う。
「サイバーアクティビスト」だと単なるオンライン抗議者っぽいので、映画で使い古された語より、「サイバー兵士」や「ネットワーク民兵」のような言葉の方がよさそうだ。
記事写真の日付がUnixエポック開始日と1日違いなのを見て、ひとりで面白がっていた。
そのWebサイトがとても独特だ。
ロシア政府に遮断されてTLSエラーが出て、それを回避してもCloudflareの「ブロックされました」ページになり、VPNを使ってようやく記事原文（ロシア語）にたどり着ける。
リンク先のページは英語だが、ロシアの現地ユーザーにとって、そのサイトのロシア語版はそもそも対象ではなかったのかもしれない。
ロシアでは言語問題に敏感だが、ウクライナでは実際にロシア語も広く使われており、ロシア語の記事も出版されている。
archive.today や archive.org（Internet Archive）など、アーカイブサイトをぜひ活用するといい。
アーカイブリンク も最近誰かが保存していた。
これはそのWebサイト自体の問題ではなく、政府による遮断、あるいはCloudFlare側の問題かもしれない。
TLSエラーの根本原因によってCloudflareがブロックしている可能性もある。
両陣営ともドローンのファームウェアを気にしているのだろうか。
敵が使うドローンに改ざんファームウェアをこっそり仕込めたら、戦略的価値は高そうだ。
面白いがリスクが大きい（簡単に見抜かれ、作戦全体を無効化しかねない）。
結局のところ、強硬な手段が最も合理的だと思う。
ドローンは通常、任務の直前にファームウェアを書き込む。
実際には工場を止めるより、ドローンがこっそり別の行動を取るようにする方が効果的かもしれない（たとえば発射時に本拠地を攻撃するとか、遠隔制御を奪うとか）。
面白い戦術の1つとして、ドローンのSDカードにウイルスを仕込んでおき、ドローンが敵地に落ちて敵兵がそれをコンピュータに挿したとき、そのコンピュータが感染するという話も聞いたことがある。
「ウクライナのサイバー活動家が軍情報機関と協力して…」
つまり、海外の情報機関から合図を受けているだけで、直接的なサイバー戦ではないという意味だ。
「海外の情報機関が合図しているだけだから直接的なサイバー戦ではない」という意見について。
ロシアの情報機関はすでにNATO諸国を直接攻撃しており、ほとんど言い逃れの余地はない。
ウクライナとロシアの間ではすでに何年も戦争状態なのだから、もっともらしい否認可能性など今さら必要ない。
その外国情報機関が何を指すのか気になるし、実際には世界中で常時攻撃が飛び交っているのだから、甘く考えるなという話だ。
記事には「外国情報機関」とは書かれていないと指摘している。
ウクライナの軍情報機関だと明記している。