開発者ツール · Base64 エンコーダーおよびデコーダー
疑わしい Base64 PowerShell コマンドを実行せずにデコードする方法
· なぜそれが重要なのか
base64 セキュリティ
攻撃者は Base64 を使用してスクリプトを非日常的な検査から隠します。この投稿では、-EncodedCommand ペイロードを実行せずにデコードする方法、UTF-8 デコーダーで出力が奇妙に見える理由、および何を探すべきかを示します。
2,000 文字の引数を持つスケジュールされたタスク — エンコードされたコマンドが出現する場所と、それが危険信号である理由
システム管理者は、疑わしいと思われる 2,000-character -EncodedCommand 引数を持つスケジュールされたタスクを発見しました。タスクは、高い特権を持つサービス アカウントで実行されます。
コマンドを PowerShell に貼り付けて実行して、その動作を確認しようとする誘惑は危険です。コマンドが悪意のあるものである場合、それを実行するとシステムが危険にさらされます。より安全なアプローチは、何かを実行するかどうかを決定する前に、Base64 をローカルでデコードし、出力をテキストとして読み取ることです。この投稿では、PowerShell コマンドを実行せずに安全にデコードする方法、標準の UTF-8 デコーダーで出力が文字化けして見える理由、およびコマンドが安全か疑わしいかを評価するために何を確認する必要があるかについて説明します。
デコードして実行しない - 分析を安全に保つルールと、ブラウザー専用デコーダーが適している理由
重要な洞察は、PowerShell が -EncodedCommand に UTF-8 ではなく UTF-16LE エンコーディングを使用するため、標準ツールでは null ターミネータとして解釈される 1 バイトおきのバイトが 0 であるということです。疑わしいコードを分析するためのルールは単純です。「デコードし、決して実行しない」です。これは、Base64 でエンコードされたコマンド、圧縮されたスクリプト、信頼できないソースからのスクリプト、および不慣れなエンコードのチェーン内のあらゆるものに当てはまります。スクリプトの実行は後戻りできません。実行されると、システムに変更が加えられ、アクセスが許可され、データが流出します。
スクリプトをデコードしてテキストとして読み取ると、元に戻せないステップの前にスクリプトを評価できます。 2 番目のルールは、ローカルで実行され、ネットワーク要求を行わないツールを使用することです。ブラウザベースのデコーダは、ポータブルで追加のソフトウェアを必要とせず、疑わしいペイロードをサーバーにアップロードせずにデバイス上に保持するため、理想的です。ツールがリモート デコーダ サービスにポストする種類の場合は、使用しないでください。その後、ペイロードがそのサービスに公開されます。 PowerShell -EncodedCommand パラメーターは、デコード時に PowerShell スクリプトを含む Base64 文字列を受け入れます。
デコードされたバイトが UTF-8 テキストと異なる理由 — この UTF-8 テキスト ツールに解釈を依頼するのではなく、UTF-16LE バイト パターンを 16 進数で検査してください
ただし、PowerShell はこれに UTF-8 エンコードを使用しません。 UTF-16LE (リトルエンディアン UTF-16) を使用します。 UTF-16 では、すべての ASCII 文字は、文字コードの後にゼロバイトが続く 2 バイトとして表されます。文字 A は 16 進数で 41 00 です。文字 B は 42 00 です。 Hello のような文字列は、UTF-16LE バイトで 48 00 65 00 6C 00 6C 00 6F 00 として表示されます。これが Base64 でエンコードされている場合、結果には、すべてのゼロを含むすべてのバイトのエンコードされた形式が含まれます。標準の UTF-8 デコーダーを使用してデコードすると、UTF-8 は NULL バイトを文字列終端文字として扱うため、テキストが文字化けするか、最初のゼロ バイトが切り捨てられます。
出力は Hello ではなく H e l o のようになり、文字がランダムであるか、テキストが欠落しているように見えます。実際に実行された例は、問題と解決策を示しています。 PowerShell コマンドが単純な文字列 Write-Host Hello をエンコードしているとします。これを PowerShell UTF-16LE ですべてのゼロを含むバイトにエンコードし、そのバイトを Base64 でエンコードして、VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA のような長い文字列を生成します。この文字列をブラウザの Base64 エンコーダとデコーダにコピーし、[デコード] をクリックします。デフォルトのデコーダは結果を UTF-8 テキストとして解釈しようとし、ゼロが埋め込まれているために破損または切り詰められた出力を生成します。
作業例: 無害なサンプルのエンコードされたコマンドのデコード - インターリーブされたゼロバイト以降のテキストの読み取り
解決策は、代わりに 16 進ビューを使用することです。 16 進ビューに切り替えると、次のバイトが表示されます。 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00。これらのバイトを UTF-16LE ペアとして読み取ると、W-r-i-t-e---K-o-s-h---H-e-l-l-o- が生成されます。経験があれば、UTF-16LE 16 進数を直接読み取ることも、バイトをファイルに書き込んでローカルで実行する PowerShell または Python スクリプトを使用してデコードすることもできます。
実際的なアプローチは、パターンに注目し、PowerShell が UTF-16LE を使用することを覚えておくことです。ブラウザーで PowerShell -EncodedCommand をデコードし、出力が間違っているように見える場合は、テキスト ビューではなく 16 進ビューを確認してください。 16 進ビューでは、各バイトが個別に表示されます。すべての ASCII 文字は、間にゼロが入った 2 バイトとして表示されます。バイトが New-AdminAccount、DNS 逆引き参照、セキュリティ資格情報のエクスポートなどの悪意のあるコマンドを記述している場合、そのコマンドは疑わしいものです。バイトがディレクトリのリストや単純なスクリプトなどの無害なものを記述している場合、そのコマンドは無害である可能性があります。
ネストされたエンコードと圧縮 - Base64 内の Base64、およびテキストとして読み取ることができない gzip ストリーム
16 進ビューはプレーン テキストよりも読みにくいですが、破損した UTF-8 出力から推測するよりは安全です。ネストされたエンコードと圧縮により、マルウェア分析がさらに複雑になります。 PowerShell コマンドは、別の Base64 文字列を Base64 エンコードするか、スクリプトを gzip で圧縮してからその結果を Base64 エンコードする場合があります。ネストされたシナリオでは、外側の Base64 をデコードし、結果を読み取ると、それ自体が Base64 であることがわかります。これもデコードし、判読可能なテキストまたは解釈できないバイナリ形式が見つかるまで続けます。 Gzip およびその他の圧縮形式は、16 進ビューで表示されるマジック バイト (gzip の場合は 1F 8B) で始まります。
Base64 をデコードし、16 進ビューが 1F 8B で始まる場合、バイトは解凍が必要な圧縮ストリームになります。 Base64 エンコーダーとデコーダーは 16 進数を表示し、何も実行せずにこれらのパターンを識別するのに役立ちます。圧縮またはさらにエンコードされたペイロードは、難読化レイヤーを追加するため疑わしいです。
インシデント レポートに記録する内容 — ペイロード自体ではなく、デコードされたテキスト、ソース、ハッシュ
正規のコマンドでは、複数のエンコード手順が必要になることはほとんどありません。インシデントレポート用に調査結果を記録するには、規律と正確さが必要です。分析した正確な Base64 文字列を、いつ、どこで見つけたかを書き留めます。デコードして不審なコマンドが見つかった場合は、そのコマンドについて説明しますが、完全なスクリプトはまだレポートに含めません。スクリプトが複雑または長い場合があります。
検出結果を検証および追跡できるように、デコードされたスクリプトのハッシュ (SHA-256) を含めます。コマンドが明らかに悪意のあるものである場合、または既知の悪用手法が使用されている場合は、アクションを起こす前にインシデント対応チームとセキュリティ チームを巻き込んでください。コマンドの動作を確認するために、自分でコマンドを実行しないでください。インシデント対応者がテストのためにそれを実行する必要がある場合は、損害が抑制されているサンドボックス環境で実行します。あなたの仕事は、安全な距離からリスクを解読して評価することです。この記事では、マルウェア分析、サンドボックス環境、または攻撃の属性の全範囲をカバーしているわけではありません。
これでカバーされないもの — サンドボックス実行、マルウェア分析ツールおよび属性
これらは、セキュリティ専門家とインシデント対応チーム向けのトピックです。ここでの範囲は、エンコードされた PowerShell コマンドを実行せずに安全にデコードすることに限定されているため、スクリプトを読んでさらに調査する価値があるかどうかを評価できます。 Base64 エンコードは保護ではなく難読化です。エンコードとデコーダを持っている人なら誰でもスクリプトを抽出できます。攻撃者は、基本的な検出を回避し、偶発的な検査を防ぐために Base64 を使用しますが、分析から意図を隠すことはありません。リモート スクリプトを取得して実行するデコードされた PowerShell コマンドは、自分でデコードするか、セキュリティ ツールでデコードするかに関係なく、悪意があります。
疑わしいコマンドを解読した後の実際的な次のステップは、それを適切なチームに報告することです。独自のシステムの場合は、タスクが意図的に作成されたかどうか、また誰によって作成されたかを判断してください。作成日とスケジュールを作成したアカウントを確認してください。タスクが承認されていない場合は、タスクを無効にし、フォレンジック用に詳細を保存し、攻撃者がそのタスクを作成する権限をどのように取得したかを調査します。コマンドにネットワーク リクエストや、レジストリの変更やスケジュールされたタスクの作成などの永続化メカニズムが含まれている場合、それはほぼ確実に悪意があります。
要点: Base64 は保護ではなく難読化です — Base64 エンコーダーとデコーダーがペイロードをマシンから離れることなくローカルでデコードする方法
正当な管理機能を実行し、作成の詳細が正常である場合、セキュリティ ポリシーまたは大規模な自動化ツールとの統合に関連する理由でたまたまエンコードされた正当な管理スクリプトである可能性があります。どちらの方法でも実行しないでください。デコードされたテキストの評価を決定に役立ててください。疑わしい Base64 PowerShell コマンドを安全にデコードするには、簡単なプロセスに従います。 Base64 エンコーダとデコーダを使用して、文字列をアップロードしたり実行したりせずに文字列をデコードします。バイトが何を表しているかを理解するには、16 進ビューを見てください。
UTF-16LE パターン (インターリーブされたゼロ バイト) が表示された場合は、PowerShell が UTF-16LE を使用していることを思い出し、それに応じて読み取ってください。ネットワークリクエスト、権限昇格、永続化メカニズムなどの疑わしいパターンを特定します。元の Base64 文字列とそのハッシュを含む、インシデント レポートの詳細を正確に記録します。自分でコマンドを実行しないでください。管理された環境でインシデント対応者に任せてください。ローカルのデコードと平文の評価を信頼し、それを次のアクションの指針にしましょう。