両刃の刀の PowerShell
2019 年 6 月 21 日 Emil Hozan 著
Eset の研究者が先日、サイバー犯罪に使用されている、かなり高度なファイルレスマルウェアのいくつかのサンプルを発見しました。ファイルレスマルウェアとは、コンピュータのメモリで直接実行される不正ソフトウェアであり、従来のマルウェア製品では検知が困難です。ウォッチガードの脅威ラボは、2019 年にファイルレスマルウェアが全体として増加すると予測し、より具体的に言えば、ファイルレスマルウェアにネットワークへと自動的に拡散する技術が組み込まれた、「vaporworm」と呼ばれる新しい脅威が登場すると予測しましたが、この予測が早くも現実のものになったようです。
この記事では、Eset による調査と、攻撃者がファイルレスマルウェアで使用することが多い、Windows の PowerShell スクリプト言語の不正使用について解説します。今回の攻撃の場合は、攻撃者が Turla である点にも注目する必要があるでしょう。記事でも強調されているように、Turla には、多種多様な手段を使って標的を攻撃するという特長があります。それでは早速、彼らの攻撃の仕組みを説明することにしましょう。
これらの攻撃の仕組み
Kaspersky の研究者たちによって、Turla グループが Posh-SecMod と呼ばれるオープンソースプロジェクトをベースとする PowerShell ローダを使用していたことがすでに明らかにされています。Turla グループはこれらのスクリプトを書き換え、3 つの重要な機能、すなわち、永続性の維持、復号化、埋め込み実行可能ファイルまたはライブラリのメモリへのロードを追加しました。これらの異なる段階がどのように進行するかを明らかにするため、カテゴリごとに若干の説明を加えながら、それぞれの段階での対策のためのヒントも併せて提示します。
永続性
更新されたスクリプトは、2 つの PowerShell メソッドを利用することで、永続性を維持します。
- WMI(Windows Management Instrumentation)イベントのサブスクリプション
WMI は、エンタープライズ環境で管理情報にアクセスする目的で使用されるテクノロジである WBEM(Web-Based Enterprise Management)の Microsoft による実装です。簡単に言えば、WBEM を使用してシステム管理情報の取得方法を標準化することで、多数のコンピュータのリモート管理が容易になります。 - PowerShell プロファイルファイルの変更
PowerShell は、システム管理者に柔軟性を提供する対話型のコマンドラインシェルで、管理者はこれを利用することで、オペレーティングシステムの管理タスクを迅速に自動化できます。PowerShell プロファイルは、ユーザ固有の構成を可能にするカスタマイズ可能な環境であり、これを利用することで、複数のシステム管理者がお互いの PowerShell プロファイルと競合することなく設定を微調整できます。
最初に、WMI メソッドについて説明します。
上記の WMI の簡単な説明を、もう少し詳しく、順を追って説明します。WMI メソッドは、イベントプロバイダと呼ばれるものによって利用可能になるイベントを使用します。イベントとは、コンピュータで通知を生成するデータまたはサービスのことで、イベントプロバイダとは、WMI と管理対象オブジェクトのインタフェースの役割を果たす抽象レイヤのことです。WMI に提供されるデータを必要に応じてカスタマイズすることもできます。イベントの例としては、サービスの機能が停止した、データストレージプールのしきい値が間もなく満杯になる、セキュリティログが生成されたなどがあります。
イベントプロバイダが WMI に提供するデータを収集するには、クライアントを利用しますが、これは具体的に言えば、前述のデータへのアクセスということになります。PowerShell の使用もその 1 つの方法ですが、他にもいくつかの言語を使用でき、WMI クライアントの作成方法については、こちらで詳しく解説されています。
2 つのイベントフィルタと 2 つのイベントコンシューマの合計 4 つのイベントサブスクリプションが作成されます。イベントフィルタは基本的には、WMI がコンシューマに送信するイベントを決定します。そのため、イベントコンシューマは、そのイベントの処理方法を詳しく記述します。
これら 2 つのフィルタは、特定の時間、すなわち、1 つはシステムの起動の 5〜7 分後に、もう 1 つは午後 3 時 30 分 40 秒に実行されます。そして、これらのフィルタによって、コンシューマの PowerShell コマンドが起動されます。base64 でエンコードされたコマンドには、別の暗号化された PowerShell スクリプトが存在する Windows レジストリ内の場所と、そのレジストリエントリの復号化に必要なパスワードとソルトが含まれています。Turla グループは、base64 エンコードと暗号化を使用することで、スクリプトがローカルのセキュリティ対策による検知を回避しようとしています。コンシューマはさらに、これらの PowerShell コマンドの結果を Windows レジストリに保存します。
管理者と攻撃者の双方にとって多くのメリットがある点を強調しておきたいと思います。しかしながら、脅威への対策という点から見れば、セキュリティを十分に考慮してセットアップしておくことが極めて重要です。この記事では、WMI の複雑さについて詳しく説明しますが、リモート WMI 接続の保護については、Microsoft のこちらの資料でも説明されています。また、攻撃者が WMI をどのような方法で不正目的に使用するかについての詳細は、Matt Graebar 氏が 2015 年の Black Hat で発表した資料や、WMI 攻撃の調査をまとめたこちらの記事を参照してください。
次に、PowerShell プロファイルメソッドについて説明します。
このプロファイルメソッドも概念的には似たものであり、今回の攻撃者は、PowerShell プロファイルファイルを乗っ取って、base64 でエンコードしたコマンドをそこに埋め込んでいます。PowerShell スクリプトの処理は上記と同じで、初期化の際にそのプロファイルを実行し、結果として、不正ストアドスクリプトを実行します。そして、上記の場合と同様、これらの不正スクリプトは、レジストリのさまざまなエントリを取得し、情報を保存します。
ここで対策として重要なのは、管理者が自分の構成プロファイル定期的に見直し、不審な点がないか確認することです。作成した覚えがないのに PowerShell プロファイルが存在したとすれば、大きな赤信号と考えるべきでしょう。お勧めするのは、既知の正しい状態のバックアップを作成してオフラインで保存し、両者を時々比較する方法です。もちろん、管理者が自分のプロファイルを編集した場合は、オフラインのバックアップを取得し直して、比較できるようにしておきます。PowerShell を紹介する 2 番目のハイパーリンクに、このプロファイルについて詳しく説明されていますが、カスタマイズ方法については、こちらを参照してください。
これ以外にも、PowerShell プロファイルのエクスプロイトについては、多くの調査結果が公開されています。これらのプロファイルのエクスプロイトの具体的な方法については、こちらの短めの記事で説明されています。これは、最終的には電卓プログラムをバックグラウンドでサイレント実行する概念実証であり、この記事では、PowerShell を使用したいくつもの攻撃方法が紹介されています。そしてもちろん、Ryan Kazanciyan と Matt Hastings が Black Hat USA 2014 で発表した、PowerShell 攻撃の調査も参考になります。
簡単に言えば、2 つの Windows に内蔵されたメカニズムとレジストリに暗号化されたデータを保存できる、これらの PowerShell スクリプトによって、ファイルレスマルウェアが永続性を手に入れることができます。
ここで、どのシナリオにもレジストリが共通して関係していること、そして、Windows レジストリがどのような役割を果たすものであるのかを知っておくと良いでしょう。Microsoft の文書はレジストリのことを、「…アプリケーションやシステムのコンポーネントが構成データを保存し、取得する、システム定義のデータベースである」と説明しています。このリソースでは、レジストリの階層と対応するエディタの使用方法の要点が説明されていますが、上級ユーザの方は、Microsoft の階層に関するこちらの文書、またはこちらのページを参照してください。
レジストリの基本を理解できたので、次に、その使い方を調べてみることにしましょう。この説明には、CSO のこの記事を利用しますが、調査の背後にある考え方を理解するために、こちらのページも参考にしてください。PowerShell プロファイルのアプローチと同様、バックアップを定期的に取得して、両者を比較して変更された箇所がないか確認します。管理者が認識していない変更点があれば、すぐにわかるはずです。さらに詳しい情報については、レジストリのフォレンジックについて詳しく説明されている、FireEye の記事を参照してください。
復号化
Windows レジストリに置かれている 2 つ目の PowerShell ペイロードスクリプトは、オープンソースのペネトレーションテストフレームワークである PowerSploit からのものです。このペイロードは、3DES を使って暗号化されています。ペイロードの暗号化によって、暗号化されたコンテンツの格納方法の特性上、検知を逃れられるため、攻撃者にとって有利になります。平文でコンテンツが保存されている場合は、ウイルス対策メカニズムによるコンテンツのスキャンが可能になりますが、コンテンツが暗号化されていると、検知が困難になります。
ウォッチガードの Corey Nachreiner が以前に執筆した 2 部構成の連載記事で、マルウェア作成者がコンピュータシステムでマルウェアを隠す方法について解説したことがあります。Dark Reading の第 1 部の記事で、暗号化を使うマルウェアについて説明されていますので、参考にしてください。
ペイロードを復号化したところ、システムで実行中である別のプロセスをランダムに選択し、そのメモリに自らをロードするツールであることがわかりました。この機能は PowerSploit でも利用できるものであり、Kaspersky の実行形式ファイルへのインジェクションを防ぐためのロジックが追加されている例もありました。この戦略は、マルウェア対策ベンダの製品に関連付けられたデータの改ざんを防ぐために使用されるものであり、Kaspersky を始めとする多くの会社には、このような活動を常に監視するための専任のマルウェアアナリストがいます。
AMSI(Anti-malware Scan Interface)の制限
変更されたバージョンの中には、AMSI セキュリティ機能の回避能力も備えているものもあります。AMSI は、アプリケーションやサービスをホストコンピュータにインストールされているすべてのマルウェア対策製品との統合を可能にするインタフェースです。このスクリプトには、Black Hat Asia 2018 で紹介された手法が使用されていましたが、この機能は、PowerShell スクリプトが常に「AMSI_RESULT_NOT_DETECTED」フラグをサービスに返すためのもので、これによって、基本的には何かがスキャンされるのを防止し、何もスキャンする能力がなければ、このサービスは無効であると判断されます。
ペイロード
Turla グループは、いくつかの異なるペイロードを使用しています。調査結果の記事に記載されているものを以下に紹介し、概要についても併せて説明します。
- このペイロードは、RPC(リモートプロシージャコール)サーバをセットアップしています。RPC は、クライアントからサーバへの単純な何らかの要求を可能にするプロトコルで、たとえば、ファイルのアップロードやダウンロード、コマンドの実行、機能セットを拡張するためのさまざまなプラグインの受け付けなどをクライアントがサーバに要求しますが、危険度の高い機能としては、トークンを書き換えるようなものもあります。トークンは基本的には、プロセスまたはスレッドのセキュリティコンテキストであり、権限に基づいて特定のリソースへのアクセスを許可または拒否するものです。
1 つ目の方法は、システムの ImpersonateAnonymousToken 関数を使用しようとするもので、この関数は、システムで許可されている場合に匿名アクセスを許可します。もう 1 つの方法は、不正コマンドを実行するために別のプロセストークンを乗っ取ろうとするもので、これにより、そのコマンドが乗っ取ったプロセスのコンテキストであるかのように処理されます。これは、別の正規のプロセスに行動を隠す方法の 1 つですが、技術的な詳細については、こちらの記事を参照してください。
ここで重要なのは、匿名関数を実行できないようにすること(デフォルトで無効です)と、プロセストークンについてよく知識しておくことです。既知の攻撃方法については、こちらのリンクを参照してください。 - 上記と同じ戦術ですが、この方法では、RPC のスプーフィングサーバを利用して、すでに登録されている RPC インタフェースの乗っ取りを試行します。RPC インタフェースは、到着する IP 通信要求を受け付け、待機するサーバのようなものです。
このアプローチでは、プロセスリストを詳しく調査し、使用されているポート、あるいは、複数のプロセスの連携を可能にするプロセス間通信の形態であるパイプをチェックし、取得後は、Turla のニーズに合わせて、コンピュータメモリ内にあるデータが不正に書き換えられます。メモリ内の調整によって、別のプロセストークンの乗っ取りと同様に隠蔽性を高くしますが、今回は、RPC 通信のコンテキストで実行されます。
前述のとおり、いずれの方法についても、技術的な詳細がこの記事で説明されています。 - もう 1 つは、PowerShell ベースのバックドアである「PowerStallion」を利用する方法で、この場合は、Microsoft の OneDrive クラウドストレージサービスをコマンド&コントロールチャネルとして利用します。以前に取得した認証情報が、実際の従業員の名前を使ってスクリプトにハードコーディングされており、認証目的で使用されています。PowerStallion は、ネットワークドライブに接続でき、ローカルで実行できる、アップロードされたコマンドがないかチェックし(記事によれば、PowerShell スクリプトが許可されている場合のみ)、その結果を OneDrive の別のサブフォルダに出力し、XOR キー「0xAA」で暗号化します。
このペイロードに関するもう 1 つの興味深い事実は、変更、アクセス、作成のタイムスタンプが変更されていることです。つまり、ファイルのタイムスタンプが、最後に変更またはアクセスされたとき、または最初に作成されたときと一致しており、このスクリプトはログファイルのこれらのタイムスタンプを、そのコンピュータの別の正規のファイル(この例では desktop.ini ファイル)と一致するように変更しています。これは、アクセスした時刻を変更することで活動を隠す方法の 1 つです。Eset の研究者は、Turla によるそれ以上のアクセスを妨害する何かが発生した場合の PowerStallion のフェイルセーフではないかと分析しています。これは、マルウェア対策のログや実行中のプロセスなどのさまざまな状況を監視する隠された方法としても使用できるものです。
まとめ
この PowerShell 攻撃についての詳細を読んだ後の感想は、その正規のペネトレーションテストツールがセキュリティコミュニティにとって役に立つものとして善意で作成されたものではあるものの、間違いなく、不正目的で悪用される可能性があるということです。すべてとは言えないものの、ほとんどのオープンソースソフトウェアは、コミュニティの手助けになる目的で公開されていますが、残念ながら、コミュニティにいるのは善人ばかりではありません。したがって、システム管理者やネットワーク管理者は、これらの脅威についてはもちろん、オンラインで外部に公開しているものについても認識しておく必要があります。
ネットワークのセキュリティを強化するには、同様のペネトレーションツール、またはそれを専門に手掛ける企業や組織を利用して、ネットワークで定期的にペネトレーションテストを実行することを強くお勧めします。あるいは、ネットワークログを定期的に分析するという選択肢もありますが、これには、さらに高度な技術的スキルが必要です。Window OS と OneDrive への自動バックアップなどの他のクラウドベースの Microsoft サービスと連携させる方法を検討してください。PowerStallion は、類似するトラフィックに自らを隠すことで、トラフィックフローを悪用します。不正なトラフィックを正当なバックアップデータと区別するのは簡単なことではありません。事実、多くの攻撃で、IP アドレスをハードコーディングする代わりに、ホスティングプロバイダをフロントとして使用するという戦術が使われるようになっています。
この記事では、全体を通して、いくつかのヒントを提示してきましたが、最後にそれをまとめて紹介し、必要な情報を少し付加したいと思います。システム管理者には、自らの PowerShell 構成プロファイルを定期的に見直すようお勧めします。MAC 時間を変更することで活動を隠蔽する可能性があるため、管理者のプロファイルが最後に更新されて以降のタイムスタンプが見つかった場合は、特にその管理者が変更した覚えがない場合は注意が必要です。ただし、攻撃者が現在のタイムスタンプを保存したり、別のファイルのタイムスタンプをコピーしたりすることもあり、そのような改ざんされたタイムスタンプによって管理者が不正に気付かない可能性もあります。したがって、手動でファイルを見直すのが最善の方法であり、ネットワーク経由でなければアクセスできないバックアップコピーであっても、差分を検知するプログラムを使って、最新のコピーと比較できます。
しかしながら、執拗な攻撃者がセキュリティプロセスを妨害しようとする動きが継続していることから、あらゆる攻撃を防止する包括的な戦術は存在しません。最善の方法は、前述のような多角的アプローチを採用しながらも、それをホストベースの強化で拡張することです。より具体的で実践的な詳細は、こちらを参照してください。最後になりますが、レジストリは多くの場合に、ファイルレスマルウェアにとっての鍵であるため、レジストリを定期的に比較して、未知の処理が実行されていないよう確認することをお勧めします。
※ 文中のリンク先については原文をご参照ください
https://www.secplicity.org/2019/06/21/powershell-the-double-edged-sword/