2022年6月のアップデートで導入されたDanaBotマルウェア運用の脆弱性により、最近の法執行活動において、その運用が特定、起訴、解体された。
DanaBotは、2018年から2025年にかけて活動したマルウェア・アズ・ア・サービス（MaaS）プラットフォームで、銀行詐欺、クレデンシャルの窃盗、リモートアクセス、分散型サービス拒否（DDoS）攻撃に使用されていました。
DanaBleed」と名付けられたこの脆弱性を発見したZscalerのThreatLabz研究者は、メモリリークによってマルウェアの内部オペレーションとその背後にいる人物に深く入り込むことができたと説明している。
この欠陥を活用してサイバー犯罪者に関する貴重な情報を収集することで、「Operation Endgame」と名付けられた国際的な法執行活動により、DanaBotのインフラをオフラインにし、脅威グループのメンバー16人を起訴することができた。
DanaBleed
DanaBleedの欠陥は、2022年6月にDataBotのバージョン2380で導入され、新しいコマンド＆コントロール（C2）プロトコルが追加された。
この新しいプロトコルのロジックの弱点は、クライアントに対するC2サーバーの応答を生成するメカニズムにあり、ランダムに生成されたパディング・バイトを含むはずでしたが、これらのために新たに割り当てられたメモリを初期化していませんでした。
Zscalerの研究者は、メモリ・リーク・バグのために、サーバーのメモリから取り残されたデータ断片を含む多数のC2レスポンスを収集し、分析した。
この暴露は、2014年に発見され、ユビキタスなOpenSSLソフトウェアに影響を与えたHeartBleed問題に類似している。
DanaBleedの結果、以下を含む広範な個人データが時間の経過とともに研究者に暴露された：
- 脅威行為者の詳細（ユーザー名、IPアドレス）
- バックエンドのインフラ（C2サーバーのIP/ドメイン）
- 被害者データ（IPアドレス、認証情報、流出情報）
- マルウェアの変更履歴
- プライベート暗号キー
- SQLクエリとデバッグログ
- C2ダッシュボードからのHTMLとウェブインターフェースのスニペット
DanaBotは、3年以上もの間、開発者やクライアントがセキュリティ研究者に暴露されていることに気づくことなく、危険なモードで動作していました。
これにより、十分なデータが収集された時点で、標的を絞った法執行活動が可能になった。
ソースはこちら：Zscaler
ロシアにおけるDanaBotの中核チームは起訴されただけで、逮捕されたわけではありませんが、重要なC2サーバー、650のドメイン、約400万ドルの暗号通貨を押収したことで、今のところ脅威は効果的に無力化されています。
今後、脅威行為者がサイバー犯罪活動に戻ろうとする可能性は低くないが、ハッカー・コミュニティからの信頼の低下は彼らにとって大きな障害となるだろう。
.ia_ad { background-color：#width: 95%; max-width: 800px; margin: 15px auto; border-radius: 8px; border：1px solid #d6ddee; display: flex; align-items: stretch; padding: 0; overflow: hidden; }：0; overflow: hidden; } .ia_lef { flex: 1; max-width: 200px; height: auto; display: flex; align-items: stretch; } .ia_lef a { display: flex; width: 100%; height: 100%; } .ia_lef a img { width: 100%; height: 100%; object-fit: cover; border-radius: 8px 0 0 8px; margin: 0; display: block; } .ia_rig { flex: 2; padding：display: flex; flex-direction: column; justify-content: center; } .ia_rig h2 { font-size: 17px !important; font-weight: 700; color：#line-height: 1.4; font-family：margin: 0 0 14px 0; } .ia_rig p { font-weight: bold; font-size: 14px; margin: 0 0 clamp(6px, 2vw, 14px) 0; } .ia_button { background-color：#border：1px solid #3b59aa; color: black; text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; cursor: pointer; padding：10px 20px; width: fit-content; } .ia_button a { text-decoration: none; color: inherit; display: block; } @media (max-width: 600px) { .ia_ad { flex-direction: column; align-items: center; text-align: center; } .ia_lef { max-width: 100%; } .ia_lef a img { border-radius: 8px 8px 0 0; } .ia_rig { padding：15px; width: 100%; } .ia_button { width: 100%; } .
ITチームが手作業によるパッチ管理をやめる理由
かつてはパッチ適用といえば、複雑なスクリプト、長時間の作業、終わりのない消火訓練が必要でした。今は違います。
この新しいガイドでは、Tines氏が最新のIT組織が自動化によってどのようにレベルアップしているかを解説している。複雑なスクリプトは必要ありません。
Comments