Babukランサムウェア 運用停止前に対象を拡大

*本記事は英文技術レポートの抄訳です。


はじめに

長い間、ランサムウェアのギャングは主に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の脅威アクターが使用する方法論の概要を説明する前に、ランサムウェア攻撃がどのように発生し、どのグループが攻撃の背後にいるのかについての一般的な背景知識が必要です。

以下では、最初にランサムウェア攻撃の一般的なフェーズと、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 マトリックス


Babukの脅威アクターによる典型的な攻撃

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システムで使用されるツールはインターネットからダウンロードされました。攻撃者は、Webサイトをホストしている「temp.sh」および「wdfiles.ru」ファイルを利用して、ほとんどのツールをホストしていました。その他のツールは、GitHubまたはそれぞれの開発者のWebサイトから直接ダウンロードされました。攻撃者は、EternalBlueエクスプロイトに対して脆弱なシステムをスキャンするためのツールをダウンロードしましたが、攻撃中にそれを使用したようには見えませんでした。

環境の偵察は、ADFind、NetScan、およびLAN SearchProを使用して行われました。 ADFindは、調査で頻繁に見られるツールであり、トリートアクターがドメイン内のすべてのシステムとユーザーのリストをダンプできるようにします。 NetScanは、スキャンを実行して、ログオンしているユーザー、インストールされているソフトウェア、およびリモートマシンに関するその他のさまざまな情報を含むネットワークをマップすることができる管理ツールです。 LAN Search Proは、ユーザーがローカルネットワークのネットワーク共有上のファイルを検索できるようにするユーティリティです。

OUT

被害者のネットワークでランサムウェアの展開を開始する前に、攻撃者はデータを盗み出しました。攻撃者はWinRARを使用してデータを圧縮し、データの発信元であるファイルサーバーに盗み出されたデータをステージングしました。次に、攻撃者はこのデータをメガドライブとグーグルドライブの両方に盗み出しました。 Megaへのデータの抽出はMegaSyncアプリケーションを使用して行われ、Googleドライブへのデータの抽出はChromeブラウザを介して行われました。

攻撃者は、環境を完全に制御し、被害者からデータを盗み出した後、最初にバックアップ関連ファイルを削除し、次にバックアップシステムにランサムウェアを配備することで、被害者のバックアップを破壊しました。

最後に、攻撃者は、バックアップを使用して被害者が攻撃から回復する方法がないことを確認した後、被害者のESXiホストに移動し、プリコンパイルされたランサムウェアバイナリを展開しました。ランサムウェアバイナリは、被害者のすべての仮想マシンの暗号化に進みます。残念ながら、このランサムウェアバイナリは実装が非常に不十分であり、データの不可逆的な破損をもたらすいくつかの異なる設計上の欠陥が含まれていることが判明しました。このバイナリは、下のセクションで分析されます。


Babukの提供元を取り巻く最近の動向

4月末、Babukは事業を停止し、別のビジネスモデルに切り替えると発表しました。このグループはもはやシステムを暗号化せず、代わりにデータの漏えいに専念します[4][5][6]。さらに、グループは、コードをオープンソースプロジェクトとしてランサムウェアに公開すると述べました。攻撃者は、身代金要求に反応しなかった被害者からのデータの公開に焦点を当てると述べました。さらに、攻撃者は、他のグループのデータをホストおよび公開することを示しました。そのため、Babukの提供元の犯罪者はデータ管理の立場に向かっているようです。

図5：Babukのサイトへの投稿

ランサムウェアの設計が不十分であることを考えると、Babukに攻撃されたときにデータが完全に失われることから、かなりの数の被害者を救う必要があります。 前のセクションで述べたように、Northwaveは、脅威アクターがデータを暗号化することで被害者を恐喝するスキームから、脅威アクターが被害者のデータを暗号化して侵入する二重恐喝スキームにゆっくりと移行するのを見てきました。 脅威アクターが、被害者を恐喝する唯一の圧力源が機密データの漏洩であるスキームに向かっているのを見るのは興味深いことです。


ランサムウェア開発者からデータ漏えい管理者へ

Webサイトで前述したように、Babukチームは、ランサムウェア環境からデータ漏洩の開示者になりました。

図6：Babukの新しいWebサイト-> 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セーフポイントを禁止します。

注意すべき点の1つは、サンプルが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 := 8

    numBytesRead, 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の開発者/オペレーターが、異なるバージョンやサンプルで機能する復号ツールを提供していない限り、これは意味がありません。

もう1つの重要な点は、このサンプルは手動で、または暗号化するパスとして引数を使用してスクリプトを使用して起動するように設計されていることです。このパスを使用して、マルウェアは「/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 ascii

condition:

filesize >= 1MB and filesize <= 3MB and

4 of ($s*)

}

 

IOCs: Babuk NAS Locker

8c6f768c90103857c59f031fb043d314db6a7371908a1f45bc2e86cf2ad68268

8daf429bb21285cfcf24dcc4797501ee3d4daf73364055ee5b002492ad55a3e1

e505b24de50b14aed35cf40725dc0185cab06fed90269d445ec7a4b36de124b6

e8cee8eab4020e1aadd4631ed626ab54d8733f8b14d683ca943cd4e124eeef55

[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
著者：