*本記事は英文技術レポートの抄訳です。
長い間、ランサムウェアのギャングは主にMicrosoft Windowsオペレーティングシステムに焦点を合わせていました。UnixまたはLinuxベースの専用ランサムウェアが時折見られましたが、クロスプラットフォームのランサムウェアはまだ発生していませんでした。しかし、サイバー犯罪者は眠ることがなく、ここ数ヵ月、いくつかのランサムウェアギャングがクロスプラットフォーム言語のGolang（Go）でバイナリを作成しようとしていることに気付きました。
Babukが地下フォーラムでLinux／UNIXおよびESXiまたはVMwareシステムを対象としたクロスプラットフォームバイナリを開発していると発表したとき、私たちの最悪の恐れが確認されました。企業の多くのコアバックエンドシステムは、これらの* nixオペレーティングシステムで実行されています。仮想化の場合は、複数のサーバーまたは仮想デスクトップ環境をホストするESXiについて考えてみてください。
以前のブログで、Babukチームが犯している多くのコーディングミスとともに、これについて簡単に触れました。
Babukはこのシーンでは比較的新しいものですが、バイナリに関する多くの問題にもかかわらず、その亜種は著名な企業に多く感染しています。
最初のBabukブログで、McAfee Advanced Threat Research（ATR）と業界の同業者が、Windowsバイナリの問題のいくつかについて説明しました。 Babukは、Golangバイナリと復号ツールの開発に関して、被害者に対してライブベータテストを採用しているようです。バイナリまたは復号化機能の障害が原因で、修復不可能なほど暗号化された被害者のマシンがいくつか見られました。
被害者が要求に屈し、身代金の支払いを余儀なくされたとしても、ファイルを取り戻すことはできませんでした。品質の低いコーディングがBabukとその亜種とアフィリエイトにも影響を与えることを強く望んでいます。アフィリエイトは実際の侵害を実行しているものであり、現在、支払いをしてもデータを取り戻すことができない被害者に直面しています。 これにより、犯罪のダイナミクスが恐喝から破壊に変わり、犯罪者の観点からすると、収益性が大幅に低下します。
図1：Linuxバージョンのランサムウェアに関するBabukからの投稿
Babukの脅威アクターが使用する方法論の概要を説明する前に、ランサムウェア攻撃がどのように発生し、どのグループが攻撃の背後にいるのかについての一般的な背景知識が必要です。
以下では、最初にランサムウェア攻撃の一般的なフェーズと、Babukランサムウェアで使用されるRansomware-as-a-Serviceモデルについて説明します。続いて、典型的なBabukランサムウェア攻撃がどのように見えるか、およびBabuk脅威アクターによって使用される特定の脅威、戦術、および手順を示します。最後に、攻撃者が使用したランサムウェアのテクニカル分析により、被害者のデータの破壊につながるコード内に多くの欠陥が見つかったことがわかります。
ランサムウェア攻撃のフェーズ
サイバー攻撃中に攻撃者が実行するさまざまな手順は、3つの主要なカテゴリに分類できます。これを使用して、Babukの脅威アクターの典型的な攻撃について説明します。
•初期アクセス（IN）•ネットワーク伝播（THROUGH）•目標に対する行動（OUT）
図2：ランサムウェア攻撃フェーズ
サービスとしてのランサムウェア（Ransomware-as-a-Service）のサプライチェーン
最近、「サービスとしてのランサムウェア（RaaS）」がサイバー犯罪業界で頻繁に確認されています。 RaaSは、ランサムウェアの開発者の間で人気が高まっているビジネスモデルです[1]。 RaaSは、サイバー犯罪者がランサムウェアをレンタルできるようにするランサムウェア開発者によって提供されるサービスです。 RaaSは、犯罪者が取得した身代金の一部と引き換えに独自のランサムウェアを構築するための技術的スキルが不足している犯罪者に対するランサムウェア攻撃を簡素化することを目的としています。このビジネスモデルにより、多くのランサムウェア開発者は、すでにアクセスできる大規模なネットワークにランサムウェアを配布できる他の熟練したサイバー犯罪者と協力することができます。 Babukランサムウェアは、2021年4月末にランサムウェアの運用を停止する前に、このようなモデルを利用していました。
RaaSは、ランサムウェア攻撃の仕組みを変革しており、いくつかの異なるアクターが関与しています。一般的に、このような攻撃のサプライチェーンは、以下に示すように4つの段階に分けることができます。
図3：サプライチェーンスキーム
| Technique | Tactic | Observable |
| Exploit public-facing application (T1190) | Initial access | CVE-2021-27065を使用したExchangeサーバーの悪用 |
| Valid accounts (T1078) | Persistence | グループは、ほとんどのアクティビティで正当なドメイン管理者の資格情報を利用 |
| Create account (T1136) | Persistence | Petrという名前のドメインアカウントを作成 |
| Exploitation for privilege escalation (T1068) | Privilege escalation | ドメイン管理者アカウントを取得するためのZerologonエクスプロイト、追加のアカウントクレデンシャルを取得するためのMimikatz |
| Impair Defenses (T1562) | Defense Evasion | アンチウイルスソリューションを無効にするためのGMERルートキットリムーバーの使用 |
| Account discovery (T1087) | Discovery | ADFindを使用して、ドメイン内のすべてのアカウントを一覧表示 |
| Remote System Discovery (T1018) | Discovery | ADFindを使用して、ドメイン内のすべてのシステムを一覧表示 |
| Remote System Discovery (T1018) | Discovery | ネットワーク上のシステムを識別するためのNetScanの使用 |
| File and Directory Discovery (T1083) | Discovery | ネットワーク共有にあるファイルを見つけるためのLANSearchProの使用 |
| Remote Services (T1021) | Lateral Movement | システム間を移動するためのRDPとSSHの使用 |
| Lateral Tool Transfer (T1570) | Lateral Movement | Linuxシステムにファイルを転送するためのWinSCPの使用 |
| Multi-Stage Channels (T1104) | Command and Control | 環境内で持続性を得るためのCobalt strikeの使用 |
| Archive Collected Data (T1560) | Collection | 抽出前にデータをアーカイブするためのWinRARの使用 |
| Exfiltration Over Web Service, Transfer Data to Cloud Storage (T1567.002) | Exfiltration | MegaSyncアプリケーションを使用したMEGAへのデータ抽出、およびGoogleChromeを使用したGoogleドライブへのデータ抽出 |
| Data Encrypted for Impact (T1486) | Impact | ランサムウェアを使用してシステムを暗号化 |
図4：MITRE マトリックス
IN
Northwaveが調査したBabuk攻撃中に、攻撃者はインターネットに直接接続されたサーバー（この場合はCVE-2021-27065）の脆弱性を悪用して、被害者のネットワークにアクセスしました。この脆弱性は、Microsoftによってパッチが適用される前に、HAFNIUM脅威アクターによって積極的に悪用されていたものでした。パッチが発行された後、この脆弱性はいくつかの脅威グループによって検出され、Northwaveは、いくつかの調査でこの脆弱性がさまざまなランサムウェアの脅威アクターによって悪用されていることを確認しました。
被害者のネットワークに侵入すると、攻撃者は1週間以上休眠状態になりました。これは、ネットワークへのアクセスを取得した当事者が、ランサムウェア関連会社へのアクセスを販売する最初のアクセスブローカーであったためと考えられます。
THROUGH
上記のように、攻撃者は最初の侵害から1週間後まで、被害者のシステムで偵察と横方向の動きを開始しませんでした。以下の段落では、脅威アクターが環境を完全に制御するために使用した方法について説明します。
アクセスを取得した後、攻撃者はシステムにCobaltStrikeバックドアを配置しました。 Cobalt Strikeは、攻撃者が被害者のネットワークで永続性を確保するために頻繁に使用します。 Northwaveは、攻撃者がネットワーク内のいくつかの主要なシステムにCobaltStrikeバックドアを配置していることを発見しました。さらに、Northwaveは、攻撃者がルートキット削除ツールであるGMERを利用していることを発見しました。このツールは、被害者のシステムのウイルス対策ソリューションを削除または無効にするために使用された可能性があります。攻撃者はMetasploitをダウンロードしたことも判明しましたが、この被害者への攻撃中に実際には使用していませんでした。
攻撃者は、カスタムバージョンのzer0dump[2]を使用して、ドメイン管理者の資格情報を取得しました。このツールは、Zerologon[3]エクスプロイトを使用して、ドメインコントローラーを危険にさらすことで特権を昇格させます。攻撃者は新しいドメインアカウントを作成せず、既存のアカウントの資格情報も変更しませんでした。代わりに、攻撃者は、元の資格情報を使用して、既存のドメイン管理者アカウントを使用することを選択しました。攻撃者はMimikatzを使用して、被害者のネットワーク上に存在する他のドメインの資格情報へのアクセスを取得しました。攻撃の後の段階で、攻撃者は、追加の永続性の手段として、一部のシステムに新しいローカル管理者アカウントを作成することを選択しました。
Windowsシステム間の横方向の移動は、RDPを使用して実現されました。 Linuxシステムへの接続では、攻撃者はSSHを利用しました（Puttyを使用）。Linuxシステムへのファイルの移動は、WindowsシステムからWinSCPを使用して行なわれました。 Windowsシステムで使用されるツールはインターネットからダウンロードされました。攻撃者は、ウェブサイトをホストしている「temp.sh」および「wdfiles.ru」ファイルを利用して、ほとんどのツールをホストしていました。その他のツールは、GitHubまたはそれぞれの開発者のウェブサイトから直接ダウンロードされました。攻撃者は、EternalBlueエクスプロイトに対して脆弱なシステムをスキャンするためのツールをダウンロードしましたが、攻撃中にそれを使用したようには見えませんでした。
環境の偵察は、ADFind、NetScan、およびLAN SearchProを使用して行なわれました。 ADFindは、調査で頻繁に見られるツールであり、トリートアクターがドメイン内のすべてのシステムとユーザーのリストをダンプできるようにします。 NetScanは、スキャンを実行して、ログオンしているユーザー、インストールされているソフトウェア、およびリモートマシンに関するその他のさまざまな情報を含むネットワークをマップすることができる管理ツールです。 LAN Search Proは、ユーザーがローカルネットワークのネットワーク共有上のファイルを検索できるようにするユーティリティです。
OUT
被害者のネットワークでランサムウェアの展開を開始する前に、攻撃者はデータを盗み出しました。攻撃者はWinRARを使用してデータを圧縮し、データの発信元であるファイルサーバーに盗み出されたデータをステージングしました。次に、攻撃者はこのデータをメガドライブとグーグルドライブの両方に盗み出しました。 Megaへのデータの抽出はMegaSyncアプリケーションを使用して行なわれ、Googleドライブへのデータの抽出はChromeブラウザを介して行なわれました。
攻撃者は、環境を完全に制御し、被害者からデータを盗み出した後、最初にバックアップ関連ファイルを削除し、次にバックアップシステムにランサムウェアを配備することで、被害者のバックアップを破壊しました。
最後に、攻撃者は、バックアップを使用して被害者が攻撃から回復する方法がないことを確認した後、被害者のESXiホストに移動し、プリコンパイルされたランサムウェアバイナリを展開しました。ランサムウェアバイナリは、被害者のすべての仮想マシンの暗号化に進みます。残念ながら、このランサムウェアバイナリは実装が非常に不十分であり、データの不可逆的な破損をもたらすいくつかの異なる設計上の欠陥が含まれていることが判明しました。このバイナリは、下のセクションで分析されます。
4月末、Babukは事業を停止し、別のビジネスモデルに切り替えると発表しました。このグループはもはやシステムを暗号化せず、代わりにデータの漏えいに専念します[4][5][6]。さらに、グループは、コードをオープンソースプロジェクトとしてランサムウェアに公開すると述べました。攻撃者は、身代金要求に反応しなかった被害者からのデータの公開に焦点を当てると述べました。さらに、攻撃者は、他のグループのデータをホストおよび公開することを示しました。そのため、Babukの提供元の犯罪者はデータ管理の立場に向かっているようです。
図5：Babukのサイトへの投稿
ランサムウェアの設計が不十分であることを考えると、Babukに攻撃されたときにデータが完全に失われることから、かなりの数の被害者を救う必要があります。 前のセクションで述べたように、Northwaveは、脅威アクターがデータを暗号化することで被害者を恐喝するスキームから、脅威アクターが被害者のデータを暗号化して侵入する二重恐喝スキームにゆっくりと移行するのを見てきました。 脅威アクターが、被害者を恐喝する唯一の圧力源が機密データの漏洩であるスキームに向かっているのを見るのは興味深いことです。
ウェブサイトで前述したように、Babukチームは、ランサムウェア環境からデータ漏洩の開示者になりました。
図6：Babukの新しいウェブサイト-> Payload.bin
まず、2021年5月末に待望のゲームCyberpunk 2077のソースコードをリリースしました。ゲームの背後にあるチーム、CD ProjektRedは、洗練されたビデオゲームの開発者、発行者、および配布者です。 リークには、PS5、PCなどのさまざまなビデオゲームプラットフォームでのCyberpunk2077のソースコードが含まれています。
図7：リークされたすべてのCyberPunk2077ソースコード
この最初のリーク以来、攻撃者からの新たな動きは見られませんでした。
このマルウェアは、オープンソースのプログラミング言語であるGolangで記述されています。これは、開発者が単一のコードベースをすべての主要なオペレーティングシステムにコンパイルできるためと考えられます。 これは、静的リンクのおかげで、LinuxシステムのGolangで記述されたコードがWindowsまたはMacシステムで実行できることを意味します。 これは、さまざまなシステムアーキテクチャで構成されるインフラストラクチャ全体を暗号化しようとしているランサムウェアギャングに大きな利点をもたらします。
Babukサンプル：
| Filename | Babuk_nas.bin |
| File Type | ELF 32-bit LSB executable |
| File Size | 2MB |
| SHA256 | e43462670c467d4899ce61e2d202d93049499b10fcaaf05d98d53616567a4276 |
| Sections | 23 |
図8: Babuk サンプル概要
ご存知のとおり、Windowsの場合、Babukは1月中旬にChacha暗号化をHC-128アルゴリズムに置き換えましたが、Linuxバージョンの場合は引き続きChachaおよびCurve25519アルゴリズムを使用します。
図9：Babukが使用するメインのGoファイル
暗号化プロセスを開始する前に、サンプルはプロセッサがMMX命令を許可しているかどうかを確認します。これは、Goが正しくコンパイルするためにMMXサポートを必要とするためです。
図10：BabukがMMX命令のサポートを確認
MMX命令を使用すると、プログラムをその形式で表現できる場合に限り、単一の命令を複数のデータ項目に対して同時に実行できます。
また、「getproccount」および「sched_getaffinity」システムコールを使用して仮想プロセッサを探し、複数の呼び出しを回避してファイルシステムにアクセスすることにより、CPUのマッピングを続行します。
図11：CPUチェックフローとマッピング
プロセッサーの認識後、サンプルは環境を正しく実行するように設定します（GCC（GNUコンパイラコレクション）の設定、ゴルーチンのデフォルトスタックサイズの増加、アトミックとの同期アルゴリズムの実装など）。
Babukは、犠牲のコンピューターから多くのバッファーを操作します。特に、ガベージコレクター（GC）プロセスを使用してメモリーを解放し、他のゴルーチンがそれを変更します。たとえば、GCがメモリーを解放している場合、ゴルーチンはすべてのメモリー書き込みを報告します。目標は、現在の解放フェーズで同時メモリー変更が見落とされるのを防ぐことです。これを行なうために、Golangは書き込みを実行してGCに通知する「書き込みバリア」を使用します。
このサンプルでは、メモリーに書き込む前に、コードはいくつかの変数をチェックします。
-「書き込みバリア」がアクティブ化され、「runtime.gcWriteBarrier」を呼び出す場合：
図12：書き込みバリアチェック
-そのポインターが書き込む場合は、疑似パッケージ「C」のインポートに使用されるCGO（囲碁で使用されるツール）ルールに従います。 Goコードは、C.size_tなどの型、C.stdoutなどの変数を参照できます。「C」のインポートの直前にコメントがある場合、そのコメント（プリアンブルと呼ばれます）がヘッダーとして使用されます。パッケージのCパーツをコンパイルする場合：
図13：疑似Cパッケージのインポート
CGOのすべてのチェックは、アトミックを使用して行なわれます。
このサンプルは、「書き込みバリア」スローパスを実装しています。書き込みバリアには、Pごとの書き込みバリアバッファにエンキューする高速パスと呼ばれるものがあります。このバッファはアセンブリで書き込まれ、汎用レジスタを上書きしないため、Go呼び出しの通常のオーバーヘッドはありません。バッファがいっぱいになると、低速パスが使用されます。書き込みバリアは、低速パス「wbBufFlush」を呼び出して、バッファをGCワークキューにフラッシュします。このパスは、すべてのレジスタをスピルし、スタックフレームを監視する可能性のあるGCセーフポイントを禁止します。
注意すべき点のひとつは、サンプルがHugePagesサイズをチェックすることです。これは、デフォルトサイズよりも大きいメモリーページが操作を最適化できるようにするメカニズムです。これを行なうには、次のように宣言された変数「sysTHPSizePath」を使用して、パス「/ sys / kernel / mm / transparent_hugepage / hpage_pmd_size」をチェックします。
var sysTHPSizePath =[]byte(“/sys/kernel/mm/transparent_hugepage/hpage_pmd_size\x00”)メモリー割り当て：
次に、サンプルはいくつかのGolang関数を使用してメモリー割り当てプロセスの開始を開始します。 まず、「runtime.mallocinit」を使用し、「physPageSize」を数回使用してマッピングおよびマッピング解除操作を行なうことにより、物理ページサイズをチェックします。
図14：メモリー割り当て+「physPageSize」チェック
コードサンプルは次のとおり：
// Check physPageSize.if physPageSize == 0 {// The OS init code failed to fetch the physical page size.throw(“failed to get system page size”)}if physPageSize > maxPhysPageSize {print(“system page size (“, physPageSize, “) is larger than maximum page size (“, maxPhysPageSize, “)\n”)throw(“bad system page size”)}if physPageSize < minPhysPageSize {print(“system page size (“, physPageSize, “) is smaller than minimum page size (“, minPhysPageSize, “)\n”)throw(“bad system page size”)}if physPageSize&(physPageSize-1) != 0 {print(“system page size (“, physPageSize, “) must be a power of 2\n”)throw(“bad system page size”)}if physHugePageSize&(physHugePageSize-1) != 0 {print(“system huge page size (“, physHugePageSize, “) must be a power of 2\n”)throw(“bad system huge page size”)次に、「mallocinit」を使用して仮想メモリーを将来の割り当て用に予約し、すべてのメモリー関連オブジェクトの中央ストレージとして使用される「mheap」グローバル変数を初期化します。
予想どおり、ヒープはアロケータを初期化することによってメモリーを割り当てるために使用され、サンプルが新しいmcache、mspanなどを割り当てようとするたびに「fixAlloc_Alloc」関数を呼び出します。メモリーを割り当てますが、構造の実際のサイズを割り当てる代わりに（ f.size bytes）、「_ FixAllocChunk」バイトを設定します。 残りの使用可能なスペースはアロケーターに保管されます。
最後に、キャッシュは次のように初期化されます。
_g_ := getg()_g_.m.mcache = allocmcache()「allocmcache」関数は「fixAlloc_Alloc」を呼び出して、新しいmcache構造体を初期化します。 mcacheフィールドは、現在実行されているスレッドに対してのみ初期化され、プロセスの切り替えが発生するたびに別のスレッドに再配置されます。
暗号化の前にシステムを準備するために、サンプルによって多くの設定が行なわれます。 これはこのサンプルにとって最も興味深い部分ではないため、ここではこれについて詳しく説明しません。
暗号化：
ディレクトリとファイルは、パッケージ「filepath」を使用して一覧表示されます。 不思議なことに、サンプルは「ReadAtLeast」関数を使用して各ファイルの最初の250バイトのみを読み取ります。これは異常であり、Babukチームによって文書化されていません。
最初に、「io.ReadAtLeast（）」はbyteSliceが保持できる限り多くのバイトを読み取ります。 次に例を示します。
byteSlice := make([]byte, 512)minBytes := 8numBytesRead, err := io.ReadAtLeast(file, byteSlice, minBytes)if err != nil {log.Fatal(err)したがって、理論的には、このサンプルには実装の問題があります。
次に、Babukは、キーを保護してファイルを暗号化するためのキー生成および交換アルゴリズム用にCurve25519をインスタンス化します。
図15：インスタンス化されたCurve25519
次に、Curve25519アルゴリズムとSHA256ハッシュから生成されたキーを使用して、暗号化部分にChachaアルゴリズムを使用します。
図16：生成されたキーで使用されるSHA256
図17：Babuk暗号化の例
このサンプルは512バイト以上を暗号化するため、受け取った暗号化ファイルはこのサンプルに属していません（16進数で0x200。他のバージョンは0x250バイトしか暗号化していないようです。このサンプルでは、ファイルの最後に「chu …」というテキストは追加されていません）。
Decryptorは同じサンプルに属しているように見えますが、前に見たように、復号化する最大バイト数には制限があり、これは奇妙なことです。
全体として、復号ツールは拡張子「.babyk」のみをチェックするため、被害者がファイルを回復しようとして名前を変更した可能性のあるファイルをすべて見逃してしまいます。また、復号ツールは、ファイルの長さが32バイトを超えているかどうかを確認します。これは、最後の32バイトが後で他のハードコードされた値と結合されて、最終的なキーが取得されるためです。これらの32バイトは、顧客が物を作るなどの理由で、キーではなくゴミ箱になる可能性があるため、これは悪い設計です。マルウェアでチェックされたパスをチェックすることによって効率的に動作せず、代わりにすべてを分析します。私たちが気付いたもう1つのエラーは、復号化ツールが、マルウェアが各フォルダーに作成するものと同じではない身代金メモ名を削除しようとすることでした。おそらく、Babukの開発者/オペレーターが、異なるバージョンやサンプルで機能する復号ツールを提供していない限り、これは意味がありません。
もうひとつの重要な点は、このサンプルは手動で、または暗号化するパスとして引数を使用してスクリプトを使用して起動するように設計されていることです。このパスを使用して、マルウェアは「/path/filepath.Walk」のOS関数を呼び出します。この関数には、新しいgスレッド（プロセスを高速化するGolangメカニズム）として検出されたファイル／フォルダーごとに実行されるコールバック関数である1つの引数が必要です。引数がない場合、マルウェアはターミナルでの使用状況の報告を終了します。このコールバック関数は、ファイル/フォルダーがオペレーティングシステムの一部のパス（身代金メモの名前）に存在しないことを確認し、必要に応じて身代金メモを作成し、ファイルを暗号化するために新しいgスレッドを起動します。 gスレッドを使用するこの手順により、ランサムウェアの暗号化が非常に迅速になります。これらは、ミューテックスメカニズム（ロックとロック解除）で同期を制御し、さらに、一部の重要な部分では、Goライブラリの「待機」コマンドを使用してすべてのgスレッドを制御します。暗号化された各ファイルは、ターミナルに情報を表示します。
Babukを提供する犯罪者集団は、活動が短期間でしたが、欠陥のあるランサムウェアを操作することで多くの被害をもたらしました。 このブログでは、提供元の状態を確認し、それが使用するランサムウェアを分析しました。 その中で特定のインスタンスで復号化プロセスがどのように失敗し、回復不能な損傷を引き起こすかを示すいくつかの欠陥が特定されました。ランサムウェアのこの不十分な設計が、攻撃者がデータ管理の立場に移行することを決定した理由であると思われます。
YARAルール
rule RANSOM_BabukLocker_NAS_Apr2021 {meta:description = “Rule to detect BabuLocker Linux edition”author = “TS @ McAfee ATR”date = “04-27-2021”hash = “a564da1ed886756e375de5f56241699e”malware_type = “Ransom”strings:$s1 = “BABUK_LOCK_curve25519” wide ascii$s2 = “crypto/chacha20” wide ascii$s3 = “filepath.Walk” wide ascii$s4 = “/sys/kernel/mm/transparent_hugepage/hpage_pmd_size” wide asciicondition:filesize >= 1MB and filesize <= 3MB and4 of ($s*)} IOCs: Babuk NAS Locker
8c6f768c90103857c59f031fb043d314db6a7371908a1f45bc2e86cf2ad682688daf429bb21285cfcf24dcc4797501ee3d4daf73364055ee5b002492ad55a3e1e505b24de50b14aed35cf40725dc0185cab06fed90269d445ec7a4b36de124b6e8cee8eab4020e1aadd4631ed626ab54d8733f8b14d683ca943cd4e124eeef55[1] http://essay.utwente.nl/81595/1/Keijzer_MA_EEMCS.pdf
[2] https://github.com/bb00/zer0dump
[3] https://www.secura.com/blog/zero-logon
[4] https://www.databreaches.net/babuk-closes-one-shop-switches-to-raas/
[5] https://heimdalsecurity.com/blog/babuk-ransomware-leaks-personal-data-of-metropolitan-police-officers/
[6] https://www.bleepingcomputer.com/news/security/babuk-ransomware-readies-shut-down-post-plans-to-open-source-malware/
※本ページの内容は2021年7月28日更新の以下のレポートの内容です。原文：Babuk: Moving to VM and *nix Systems Before Stepping Away著者：McAfee Labs
■関連サイト