セキュリティ侵害に至る過程

  • [アーティクル]

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012

法則番号 7: 最も安全なネットワークは、十分に管理されたネットワークである。 - セキュリティ管理に関する 10 の不変の法則 (英語)

致命的な侵害イベントが発生した組織を評価すると、通常、組織の IT インフラストラクチャの実際の状態の可視性が限られていて、"文書化されている" 状態とは大きく異なる場合があることが判明します。 これらの差異により、環境が侵害にさらされる脆弱性が生じ、多くの場合、攻撃者が環境を実質的に "所有" する時点まで、検出されることがほぼありません。

これらの組織の AD DS 構成、公開キー インフラストラクチャ (PKI)、サーバー、ワークステーション、アプリケーション、アクセス制御リスト (ACL)、その他のテクノロジを詳細に評価すると、構成ミスや脆弱性が明らかになり、修正されていれば、当初の侵害を防ぐことができた可能性があります。

IT ドキュメント、プロセス、および手順の分析では、管理プラクティスのギャップによって生じる脆弱性を特定します。攻撃者はこの脆弱性を利用して、最終的に特権を取得し、Active Directory フォレストを完全に侵害するために使用しました。 完全に侵害されたフォレストとは、攻撃者が個々のシステム、アプリケーション、またはユーザー アカウントを侵害するだけではなく、アクセス権をエスカレートして、フォレストのすべての側面を変更または破壊できるレベルの特権を取得したフォレストです。 Active Directory のインストール済み環境がそこまで侵害されると、攻撃者は、環境全体にわたって存続を維持し、さらに悪いことに、ディレクトリ、および管理するシステムとアカウントを破壊することを可能にする変更を加えることができます。

以降の説明で一般的に悪用される脆弱性の多くは Active Directory に対する攻撃ではありませんが、これらの脆弱性によって、攻撃者が環境に足がかりを確立し、特権エスカレーション (特権昇格とも呼ばれる) 攻撃を実行するために使用して、最終的に AD DS を標的にして侵害できるようになります。

このドキュメントのこのセクションでは、攻撃者がインフラストラクチャへのアクセス権を取得し、最終的に特権昇格攻撃を開始するために通常使用するメカニズムについて説明します。 次のセクションも参照してください。

注意

このドキュメントでは、AD DS ドメインの一部である Active Directory および Windows システムに焦点を当てていますが、攻撃者が Active Directory と Windows のみに焦点を当てることはほとんどありません。 オペレーティング システム、ディレクトリ、アプリケーション、およびデータ リポジトリが混合している環境では、Windows 以外のシステムも侵害されているのが一般的です。 これは特に、Windows と UNIX または Linux のクライアントによってアクセスされるファイル サーバー、複数のオペレーティング システムに認証サービスを提供するディレクトリ、異なるディレクトリにまたがってデータを同期するメタディレクトリなどの、Windows 環境と Windows 以外の環境の間に "ブリッジ" を提供する場合に該当します。

AD DS は、提供する機能が一元化されたアクセスと構成の管理であるため、Windows システムだけでなく、他のクライアントも対象にします。 認証と構成管理サービスを提供するその他のディレクトリまたはアプリケーションは、特定の攻撃者によって標的にされる可能性があります。 このドキュメントでは、Active Directory インストール済み環境の侵害の可能性を低減できる保護に重点を置きますが、Windows 以外のコンピューター、ディレクトリ、アプリケーション、またはデータ リポジトリが含まれるすべての組織も、それらのシステムに対する攻撃に備える必要があります。

初期侵害の対象

組織が侵害にさらされるように意図的に IT インフラストラクチャを構築する人は誰もいません。 Active Directory フォレストが最初に構築されたとき、通常、そのフォレストは混じりけのない最新状態です。 年月が経ち、新しいオペレーティング システムとアプリケーションが取得されると、フォレストに追加されます。 Active Directory によって提供される管理容易性というメリットが認識されているため、ディレクトリに追加されるコンテンツが増え、コンピューターやアプリケーションを AD DS と統合するユーザーが増え、最新バージョンの Windows オペレーティング システムによって提供される新機能をサポートするためにドメインがアップグレードされます。 ただし、時間の経過にともなって、新しいインフラストラクチャが追加されても、インフラストラクチャの他の部分が当初と同様には保守されない場合があります。システムとアプリケーションは正常に機能するために注目されず、レガシ インフラストラクチャを除去していないことを組織が忘れ始めます。 侵害されたインフラストラクチャの評価で確認した内容に基づくと、環境が古く、大きく、複雑になるほど、一般的に悪用される脆弱性事例が多数存在する可能性が高くなります。

攻撃者の動機に関係なく、ほとんどの情報セキュリティ侵害は、一度に 1 つまたは 2 つのシステムの侵害から始まります。 こうした最初のイベント (ネットワークへのエントリ ポイント) では、多くの場合、修正できていたはずが修正されなかった脆弱性が活用されています。 いくつかの国のセキュリティ機関や他の企業と協力して Verizon RISK Team によって作成された年次調査である 2012 Data Breach Investigations Report (DBIR) では、攻撃の 96% は 「非常に困難ではない」と述べ、「侵害の 97% は単純な、または中程度の制御によって回避可能だった」と述べています。これらの結果は、後続の、一般的に悪用される脆弱性の直接的な結果である可能性があります。

ウイルス対策とマルウェア対策の展開のギャップ

法則番号 8: 古いマルウェア スキャナーは、スキャナーがまったくないのと比べてわずかに良いだけである。 - セキュリティに関する 10 の不変の法則 (バージョン 2.0) (英語)

組織のウイルス対策とマルウェア対策の展開の分析では、多くの場合、ほとんどのワークステーションが有効で最新のウイルス対策ソフトウェアとマルウェア対策のソフトウェアを使用して構成されている環境が明らかになります。 通常、例外は、企業環境にあまり接続しないワークステーションや、ウイルス対策とマルウェア対策のソフトウェアの展開、構成、更新が困難な従業員のデバイスです。

ただし、サーバー内容は、多くの侵害された環境で保護の程度が一貫して低い傾向があります。 2012 Data Breach Investigations での報告によると、すべてのデータ侵害の 94% がサーバーに関連するものであり、前年より 18% 増加していて、マルウェアが組み込まれた攻撃の 69% を示しています。 サーバー内容では、ウイルス対策とマルウェア対策のインストール済み環境が矛盾した構成になっていたり、古かったり、構成が誤っていたり、無効にさえなっていたりすることが珍しくありません。 管理スタッフによってウイルス対策とマルウェア対策のソフトウェアが無効にされている場合もありますが、攻撃者が他の脆弱性を利用してサーバーを侵害した後にソフトウェアを無効にする場合もあります。 ウイルス対策とマルウェア対策のソフトウェアが無効になると、攻撃者は次にマルウェアをサーバーにインストールし、サーバー内容全体に侵害を拡大することに集中します。

システムを最新の包括的なマルウェア保護で保護するように確保するだけではなく、システムでウイルス対策とマルウェア対策のソフトウェアの無効化や削除が行われていないかを監視し、手動で無効にしたときには自動的に保護を再開することが重要です。 ウイルス対策とマルウェア対策のソフトウェアで、すべての感染の防止と検出を保証することはできませんが、ウイルス対策とマルウェア対策の実装を適切に構成して展開すると、感染の可能性を低減できます。

不完全なパッチ適用

法則番号 3: 最新のセキュリティ修正に対応せずにいると、ネットワークは近いうちに乗っ取られる。 - セキュリティ管理に関する 10 の不変の法則 (英語)

Microsoft は毎月第 2 火曜日にセキュリティ情報をリリースしますが、まれに、お客様のシステムに緊急のリスクが生じる脆弱性が判断されると、月次セキュリティ更新プログラムの間にセキュリティ更新プログラム (これらは "定例外" 更新プログラムとも呼ばれる) がリリースされます。 小規模企業が Windows Update を使用してシステムとアプリケーションのパッチの適用を管理するように Windows コンピューターを構成する場合でも、大規模な組織が Microsoft Endpoint Configuration Manager などの管理ソフトウェアを使用して詳細で階層的な計画に従ってパッチを展開する場合でも、多くのお客様は、ほぼ適時に Windows インフラストラクチャにパッチを適用しています。

ただし、Windows コンピューターと Microsoft アプリケーションのみを含むインフラストラクチャは少なく、侵害された環境では、組織のパッチ管理戦略にギャップが含まれているのが見つかることが珍しくありません。 これらの環境の Windows システムには一貫性のないパッチ適用が行われています。 Windows 以外のオペレーティング システムには、パッチが適用されているとしても散発的です。 商用の市販 (COTS) アプリケーションには、パッチが存在するが適用されていない脆弱性が含まれています。 ネットワーク デバイスは、多くの場合、出荷時の既定の資格情報で構成されていて、インストール後何年もファームウェアが更新されません。 ベンダーによってサポートされなくなったアプリケーションとオペレーティング システムは、脆弱性に対してパッチを適用できなくなったにもかかわらず、実行され続けることがしばしばあります。 これらのパッチが適用されていない各システムは、攻撃者のもう 1 つの潜在的なエントリ ポイントになります。

IT のコンシューマライゼーションにより、従業員所有のデバイスが会社所有のデータにアクセスするために使用されているという新たな課題が生じていますが、組織は従業員の個人デバイスのパッチの適用と構成をほとんど制御できません。 エンタープライズ クラスのハードウェアには、通常、個々のカスタマイズとデバイスの選択の選択肢が少ない代わりに、エンタープライズ対応の構成オプションと管理機能が搭載されています。 従業員向けハードウェアには、幅広い製造元、ベンダー、ハードウェア セキュリティ機能、ソフトウェア セキュリティ機能、管理機能、構成オプションが提供されますが、多くのエンタープライズ機能がまったく存在しない場合があります。

パッチと脆弱性管理ソフトウェア

Windows システムと Microsoft アプリケーションに対して効果的なパッチ管理システムが設定されている場合は、パッチが適用されていない脆弱性によってもたらされる攻撃面の一部が対処されています。 ただし、Windows 以外のシステム、Microsoft 以外のアプリケーション、ネットワーク インフラストラクチャ、および従業員のデバイスも、パッチや他の修正プログラムに関して最新の状態に維持されていない限り、インフラストラクチャは脆弱なままです。 アプリケーションのベンダーが自動更新機能を提供する場合もありますが、そうでない場合は、パッチや他の修正プログラムを定期的に取得して適用するアプローチを考案することが必要な可能性があります。

古いアプリケーションとオペレーティング システム

"6 年前のオペレーティング システムが、6 か月前に誕生した攻撃から保護してくれることは期待できません。"- エンタープライズ インストール済み環境の保護で 10 年の経験を持つ情報セキュリティの専門家

"最新情報に遅れずについていきましょう" と言うとマーケティングのうたい文句のようですが、古くなったオペレーティング システムやアプリケーションは、多くの組織の IT インフラストラクチャでリスクをもたらします。 2003 年にリリースされたオペレーティング システムは、ベンダーによって引き続きサポートされ、脆弱性に対処する更新プログラムが提供される場合がありますが、そのオペレーティング システムには、新しいバージョンのオペレーティング システムに追加されたセキュリティ機能が含まれていない可能性があります。 古いシステムでは、それらのコンピューターの機能不足に合わせるために、AD DS のセキュリティ構成の低下させることさえ必要になる場合があります。

アプリケーションをサポートしなくなったベンダーによって記述された、レガシ認証プロトコルを使用するアプリケーションは、通常、再編成して、より強力な認証メカニズムをサポートするようにはできません。 それにもかかわらず、このようなアプリケーションをサポートするために、LAN Manager ハッシュや逆暗号化されたパスワードを格納するように、組織の Active Directory ドメインが構成される場合があります。 新しいオペレーティング システムの導入前に作成されたアプリケーションは、最新のオペレーティング システムでは正常に機能しないか、まったく機能しない場合があるため、組織では次第に古くなっていくシステムと、場合によっては、まったくサポートされていないハードウェアおよびソフトウェアを保守する必要があります。

組織がドメイン コントローラーを Windows Server 2012、Windows Server 2008 R2、または Windows Server 2008 に更新している場合でも、メンバー サーバー内容のかなり多くの部分で (まったくサポートされていない) Windows Server 2003、Windows 2000 Server、または Windows NT Server 4.0 を実行しているのが見つかることがよくあります。 組織が古くなっていくシステムを保守する期間が長くなると、機能セット間の差が大きくなり、実稼働システムがサポートされなくなる可能性が高くなります。 さらに、Active Directory フォレストの保守期間が長くなると、レガシのシステムとアプリケーションがアップグレード計画で見落とされることが多くなるのが確認されます。 つまり、単一のアプリケーションを実行している 1 台のコンピューターでもドメインまたはフォレスト全体の脆弱性をもたらす可能性があるということです。Active Directory がレガシのプロトコルと認証メカニズムをサポートするように構成されているためです。

レガシのシステムとアプリケーションを除去するには、まずそれらを識別してカタログ化し、次にアプリケーションまたはホストをアップグレードするか置き換えるかを決定する必要があります。 サポートもアップグレード パスもない高度に特殊化されたアプリケーションの代わりを見つけるのは困難である可能性がありますが、"創造的破壊" と呼ばれる概念を利用して、レガシ アプリケーションを必要な機能を提供する新しいアプリケーションに置き換えることができる場合があります。 侵害対策の計画については、このドキュメントの後半の「侵害対策を計画する」で詳しい説明を参照してください。

誤った構成

法則番号 4: そもそもセキュリティで保護されたことがないコンピューターにセキュリティ修正プログラムをインストールしてもあまり効果はない。 - セキュリティ管理に関する 10 の不変の法則 (英語)

システムがおおむね最新の状態に保たれ、パッチが適用されている環境でも、オペレーティング システム、コンピューターで実行されているアプリケーション、および Active Directory でギャップや構成ミスが特定されることが一般的です。 一部の構成ミスでは、侵害にさらされるのはローカル コンピューターのみですが、コンピューターが "所有" されると、攻撃者は通常、他のシステムにまたがってさらに侵害を拡大することに集中し、最終的には Active Directory に到達します。 リスクをもたらす構成が特定される一般的な領域の一部を次に示します。

Active Directory の場合

攻撃者が最も多く標的にする Active Directory のアカウントは、Active Directory で最も高い特権を持つグループのメンバー (Domain Admins (DA)、Enterprise Admins (EA)、ビルトイン Administrator (BA) グループのメンバーなど) です。 これらのグループの攻撃面が限定されるように、これらのグループのメンバーシップを可能な限り少ない数のアカウントに減らしてください。 これらの特権グループの "永続的な" メンバーシップを除去することもできます。つまり、ドメインとフォレスト全体の特権が必要なときにのみ、これらのグループを一時的に設定できるような設定を実装できます。 高度な特権を持つアカウントを使用するときは、ドメイン コントローラーやセキュリティで保護された管理ホストなどの、指定され、セキュリティで保護されたシステムでのみ使用する必要があります。 これらの構成の実装に役立つ詳細については、「Active Directory への攻撃面を削減する」を参照してください。

Active Directory で最も高い特権グループのメンバーシップを評価すると、多くの場合、3 つの最も高い特権グループすべてで過剰なメンバーシップが見つかります。 組織が DA グループに数十、さらに数百ものアカウントを持っている場合があります。 DA グループよりもビルトイン Administrator グループが "特権が低い" と考えて、組織がアカウントをそのグループに直接配置している場合もあります。 そのようなことはありません。 多くの場合、EA 特権はごくたまに一時的に必要であるにもかかわらず、フォレスト ルート ドメインに EA グループの一部の永続的なメンバーが見つかります。 実質的には冗長な構成ですが、3 つのグループすべてで IT ユーザーの日常管理アカウントが見つかることも多くあります。 「Active Directory への攻撃面を削減する」で説明しているように、アカウントが永続的なメンバーとして所属しているのがこれらのグループの 1 つであっても、すべてであっても、AD DS 環境と、それによって管理されているシステムおよびアカウントを侵害し、さらに破壊するためにアカウントを使用される可能性があります。 Active Directory でのセキュリティで保護された構成と特権アカウントの使用に関する推奨事項については、 「Active Directory への攻撃面を削減する」を参照してください。

ドメイン コントローラーの場合

ドメイン コントローラーを評価すると、メンバー サーバーと相違なく構成および管理されていることがしばしばあります。 ドメイン コントローラーに必要だからではなく、それらのアプリケーションが標準ビルドの一部だからという理由で、ドメイン コントローラーでメンバー サーバーにインストールされているのと同じアプリケーションとユーティリティが実行されることがあります。 これらのアプリケーションは、ドメイン コントローラーの最小限の機能を提供しているかもしれませんが、その攻撃面を大幅に拡大します。ポートを開いたり、高い特権を持つサービス アカウントを作成したり、認証やグループ ポリシー アプリケーション以外の目的ではドメイン コントローラーに接続しないようにする必要があるユーザーによるシステムへのアクセスを許可したりする構成設定を必要とするためです。 一部の侵害では、ドメイン コントローラーに既にインストールされていたツールを攻撃者が使用して、ドメイン コントローラーへのアクセスを取得するだけでなく、AD DS データベースを変更または破壊しました。

ドメイン コントローラー上の Internet Explorer の構成設定を抽出すると、Active Directory で高いレベルの特権を持つアカウントを使用してユーザーがログオンし、そのアカウントを使用して、ドメイン コントローラーからインターネットおよびイントラネットにアクセスしたことがわかります。 場合によっては、アカウントがインターネット コンテンツのダウンロードを許可するようにドメイン コントローラー上の Internet Explorer 設定を構成し、インターネット サイトからフリーウェア ユーティリティをダウンロードして、ドメイン コントローラーにインストールしていました。 Internet Explorer セキュリティ強化の構成は、既定ではユーザーと管理者に対して有効になっていますが、管理者に対して無効にされていることがしばしばあります。 高い特権を持つアカウントがインターネットにアクセスし、任意のコンピューターにコンテンツをダウンロードすると、そのコンピューターは深刻なリスクを負うことになります。 コンピューターがドメイン コントローラーであるときは、AD DS のインストール済み環境全体が危険にさらされます。

ドメイン コント ローラーの保護

ドメイン コントローラーは、重要なインフラストラクチャ コンポーネントとして扱われ、より厳密に保護され、ファイル、印刷、アプリケーションの各サーバーよりも厳格に構成される必要があります。 ドメイン コントローラーが機能するために必要ではないソフトウェアや、ドメイン コントローラーを攻撃から保護しないソフトウェアは、ドメイン コントローラーで実行しないでください。 ドメイン コントローラーはインターネットにアクセスできないようにし、セキュリティ設定はグループ ポリシー オブジェクト (GPO) によって構成および適用する必要があります。 ドメイン コントローラーのセキュリティで保護されたインストール、構成、および管理に関する詳細な推奨事項については、「ドメイン コントローラーを攻撃から保護する」を参照してください。

オペレーティング システム内

法則番号 2: 悪意のあるユーザーがコンピューター上のオペレーティングシステムを変更できると、コンピューターが乗っ取られる。 - セキュリティに関する 10 の不変の法則 (バージョン 2.0) (英語)

組織によっては、さまざまな種類のサーバーのベースライン構成を作成し、インストール後に許可されるオペレーティング システムのカスタマイズ範囲を制限していますが、侵害された環境の分析では、多数のサーバーがアドホックな方法で展開され、手動で独自に構成されたことがしばしば明らかになります。 同じ機能を実行する 2 台のサーバー間の構成がまったく異なっていて、どちらのサーバーも安全に構成されていない場合があります。 逆に、サーバー構成ベースラインは一貫して適用されているが、一貫して構成が誤っている、つまり、特定の種類のすべてのサーバーが同じ脆弱性をもたらすように構成されている場合もあります。 構成の誤りには、セキュリティ機能の無効化、アカウント (特にサービス アカウント) への過度な権限とアクセス許可の付与、システムにまたがって同一のローカル資格情報の使用、独自の脆弱性をもたらす未承認のアプリケーションやユーティリティのインストールの許可などの運用が含まれます。

セキュリティ機能の無効化

セキュリティが強化された Windows ファイアウォール (WFAS) は構成が困難であるか、集中した構成作業が必要であると考えて、組織が WFAS を無効にする場合があります。 しかし、Windows Server 2008 以降では、何らかのロールまたは機能がサーバーにインストールされると、そのロールまたは機能が機能するために必要な最小限の特権で既定で構成され、Windows ファイアウォールはそのロールまたは機能をサポートするように自動的に構成されます。 WFAS を無効にすると (そして他のホストベースのファイアウォールを使用しないと)、Windows 環境全体の攻撃面が増加します。 周囲のファイアウォールは、インターネットから環境を直接標的にする攻撃に対して何らかの保護を提供しますが、ドライブバイ ダウンロード 攻撃や、イントラネット上の他の侵害されたシステムから発生する攻撃などの、他の攻撃ベクトルを悪用する攻撃に対する保護を提供しません。

管理スタッフがメッセージをわずらわしいと考えて、サーバーで、ユーザー アカウント制御 (UAC) の設定を無効にする場合があります。 Microsoft サポート記事 2526083 で、Windows Server で UAC を無効にしてかまわないシナリオについて説明していますが、Server Core のインストール済み環境 (UAC が設計上無効にされている) を実行していない限り、慎重に考慮して調査することなく、サーバー上の UAC を無効にしないでください。

組織がオペレーティングシステムの変更を反映いてベースラインを変更せずに、新しいオペレーティング システムに古いサーバー構成設定を適用 (Windows Server 2012、Windows Server 2008 R2、または Windows Server 2008 を実行しているコンピューターに Windows Server 2003 のベースラインを適用するなど) しているために、サーバー設定がセキュリティの低い値に構成されている場合もあります。 新しいオペレーティングシステムに古いサーバーベースラインを使用するのではなく、新しいオペレーティングシステムを展開するときに、セキュリティの変更と構成設定を検討して、実装される設定が新しいオペレーティングシステムに適用可能であり、適切であることを確認してください。

過剰な特権の付与

評価したほぼすべての環境で、Windows システムのローカル アカウントとドメインベースのアカウントに過度の特権が付与されていました。 ユーザーにワークステーションのローカル管理者権限が付与され、メンバー サーバーは機能するために必要なレベルを超えた権限で構成されたサービスを実行し、サーバー内容をまたがるローカル管理者グループに数十または数百のローカルとドメインのアカウントが含まれます。 コンピューター上の特権アカウントが 1 つ侵害されるだけで、攻撃者は、コンピューターにログオンするすべてのユーザーとサービスのアカウントを侵害し、資格情報を取得および利用して他のシステムにセキュリティ侵害を拡大できます。

Pass-the-Hash (PTH) やその他の資格情報の盗難攻撃は、現在増えていますが、それは、攻撃者がコンピューターに対して管理者またはシステム レベルのアクセス権を取得したときに、他の特権アカウントの資格情報を単純かつ簡単に抽出できるようにする、無料で利用できるツールがあるためです。 ログオン セッションから資格情報を取得できるツールがない場合でも、コンピューターへの特権アクセスを持つ攻撃者は、キーストローク、スクリーンショット、およびクリップボードの内容をキャプチャするキーストローク ロガーを簡単にインストールできます。 コンピューターへの特権アクセスを持つ攻撃者は、マルウェア対策ソフトウェアの無効化、ルートキットのインストール、保護されたファイルの変更、攻撃を自動化したり、サーバーをドライブバイ ダウンロード ホストに変換したりするマルウェアのコンピューターへのインストールを実行できます。

1 台のコンピューターを超えて侵害を拡大するために使用される戦術はさまざまですが、侵害を拡大するための鍵は、追加のシステムへの高度な特権アクセスを取得することです。 すべてのシステムについて特権アクセスを持つアカウントの数を減らすことで、そのコンピューターの攻撃面だけでなく、攻撃者がコンピューターから貴重な資格情報を収集する確率を減少させることができます。

ローカル管理者の資格情報の標準化

Windows コンピューター上のローカル管理者アカウントの名前を変更する価値があるかどうかに関して、セキュリティの専門家の間では長期にわたる論争がありました。 ローカル管理者アカウントで実際に重要なのは、複数のコンピューター間で同じユーザー名とパスワードを使用して構成されているかどうかです。

ローカル管理者アカウントの名前がサーバー間で同じ値に設定されていて、そのアカウントに割り当てられたパスワードも同じ値に構成されている場合、攻撃者は、管理者またはシステム レベルのアクセス権を取得した 1 台のコンピューターからアカウントの資格情報を抽出できます。 最初は、攻撃者が管理者アカウントを侵害する必要はありません。ローカルの Administrators グループのメンバーであるユーザー、または LocalSystem として、あるいは管理者権限で実行するように構成されているサービス アカウントのアカウントを侵害するのみで十分です。 攻撃者は次に、管理者アカウントの資格情報を抽出し、ネットワーク上の他のコンピューターに対するネットワーク ログオンでそれらの資格情報を再利用できます。

別のコンピューターに、提示されているアカウントの資格情報と同じユーザー名とパスワード (またはパスワード ハッシュ) を持つローカルアカウントがある限り、ログオン試行は成功し、攻撃者は対象のコンピューターへの特権アクセスを取得します。 現在のバージョンの Windows では、ビルトイン Administrator アカウントは既定で無効になっていますが、レガシ オペレーティング システムでは、アカウントは既定で有効になっています。

注意

組織によっては、他のすべての特権アカウントがシステムからロックアウトされている場合は、"フェイルセーフ" が提供されると考えて、ローカル管理者アカウントを意図的に有効にするように構成しています。 ただし、ローカル管理者アカウントが無効になっていて、アカウントの有効化や管理者特権を使用したシステムへのログオンを可能にする他のアカウントがない場合でも、 Microsoft サポート記事 814777 で説明されているように、システムをセーフ モードで起動し、組み込みのローカル管理者アカウントを再び有効にできます。 さらに、システムが GPO を正常に適用した場合でも、管理者アカウントを (一時的に) 再度有効にするように GPO を変更することも、ドメインベースのアカウントをローカルの Administrators グループに追加するように制限されたグループを構成することもできます。 修復を実行して、管理者アカウントを再び無効にできます。 組み込みのローカル管理者アカウントの資格情報を使用した水平方向の侵害を効果的に防ぐには、ローカル管理者アカウント用に一意のユーザー名とパスワードを構成する必要があります。 GPO を使用してローカル管理者アカウント用の一意のパスワードを展開するには、TechNet の「Solution for management of built-in Administrator account's password via GPO」を参照してください。  

未承認のアプリケーションのインストールの許可

法則番号 1: 悪意のあるユーザーからコンピューターでプログラムを実行するように誘導されると、そのコンピューターが部分的に乗っ取られる。 - セキュリティに関する 10 の不変の法則 (バージョン 2.0) (英語)

組織でサーバー全体に一貫したベースライン設定を展開するかどうかにかかわらず、サーバーに定義されたロールの一部ではないアプリケーションのインストールは許可しないようにする必要があります。 サーバーによって指定された機能の一部ではないソフトウェアをインストールできるようにすると、サーバーは、サーバーの攻撃面を増やしたり、アプリケーションの脆弱性がもたらしたり、システムが不安定にさせたりするソフトウェアが、不注意または悪意によってインストールされる可能性があります。

アプリケーション

前述のように、アプリケーションは、アプリケーションが実際に必要とするレベルを超えた特権が付与されているアカウントを使用するようにインストールおよび構成されていることがしばしばあります。 アプリケーションのドキュメントで、サービス アカウントをサーバーのローカル管理者グループのメンバーにするか、LocalSystem のコンテキストで実行されるように構成する必要があることを指定している場合もあります。 これは多くの場合、アプリケーションにこれらの権限が必要だからではなく、アプリケーションのサービス アカウントに必要な権限とアクセス許可を決定するには追加の時間と労力がかかるためです。 アプリケーションのインストールが、アプリケーションとその構成機能が機能するために必要な最小限の特権で行われていない場合、システムは、オペレーティング システム自体に対する攻撃なしに、アプリケーションの特権を活用する攻撃にさらされます。

セキュリティで保護されたアプリケーションの開発方法の欠如

インフラストラクチャは、ビジネス ワークロードをサポートするために存在します。 これらのワークロードがカスタム アプリケーションに実装されている場合は、アプリケーションが安全なベスト プラクティスを使用して開発されるようにすることが重要です。 企業全体のインシデントの根本原因分析では、最初のセキュリティ侵害がカスタム アプリケーション (特にインターネットに接続しているアプリケーション) 経由で発生したと明らかになることがよくあります。 これらの侵害のほとんどは、SQL インジェクション (SQLi) やクロスサイト スクリプティング (XSS) 攻撃などの有名な攻撃による侵害によって達成されています。

SQL インジェクションは、ユーザー定義の入力によって、実行のためにデータベースに渡される SQL ステートメントの変更を可能にするアプリケーションの脆弱性です。 この入力は、アプリケーションのフィールド、パラメーター (クエリ文字列や Cookie など)、またはその他の方法を使用して指定できます。 このインジェクションの結果として、データベースに提供される SQL ステートメントは、開発者が意図したものとは根本的に異なるものになります。 たとえば、ユーザー名とパスワードの組み合わせの評価で使用される一般的なクエリは次のとおりです。

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

データベース サーバーによってこれが受信されると、サーバーはユーザー テーブルを検索し、ユーザー名とパスワードがユーザーによって (おそらく何らかのログイン フォーム経由で) 指定されたものと一致する userID レコードを返します。 当然、この場合の開発者の意図は、ユーザーが正しいユーザー名とパスワードを指定できた場合にのみ、有効なレコードを返すことです。 いずれかが正しくない場合、データベース サーバーは一致するレコードを検索できないため、空の結果を返します。

問題は、攻撃者が有効なデータの代わりに独自の SQL を提供するなどの、予期しない操作を実行した場合に発生します。 SQL はデータベース サーバーによってすぐに解釈されるため、インジェクションされたコードは、開発者自身がそれを挿入したかのように処理されます。 たとえば、攻撃者がユーザー ID として administrator と入力し、そのパスワードとして xyz または 1 = 1 を入力した場合、データベースによって処理されるステートメントは次のようになります。

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

このクエリがデータベース サーバーによって処理されると、1 = 1 は常に True と評価されるため、テーブル内のすべての行がクエリで返されます。このため、正しいユーザー名とパスワードを知っていて、指定したかどうかは関係なくなります。 ほとんどの場合、最終的な結果として、ユーザーはユーザーのデータベースの最初のユーザーとしてログオンします。ほとんどの場合、これが管理ユーザーになります。

単にログオンするだけでなく、このような不適切な形式の SQL ステートメントを使用して、データを追加、削除、変更したり、データベースからテーブル全体をドロップ (削除) したりすることもできます。 SQLi と過剰な特権とが組み合わされた最も極端な例では、オペレーティング システム コマンドを実行することで、新しいユーザーの作成、攻撃ツールのダウンロード、または攻撃者によるその他の任意のアクションの実行を可能にできます。

クロスサイト スクリプティングでは、アプリケーションの出力に脆弱性が導入されます。 攻撃は、攻撃者がアプリケーションに不適切な形式のデータを提供することから始まりますが、この例では、不適切な形式のデータは、標的のブラウザーによって実行されるスクリプト コード (JavaScript など) の形式になっています。 XSS の脆弱性を悪用すると、攻撃者は、ブラウザーを起動したユーザーのコンテキストでターゲット アプリケーションの任意の機能を実行できるようになります。 XSS 攻撃は、通常、アプリケーションに接続して攻撃コードを実行するリンクを選択するようにユーザーに促すフィッシング メールによって開始されます。

XSS は、攻撃者が悪用されたユーザーのコンテキストで購入または送金を行うことができるオンライン バンキングと電子商取引のシナリオでしばしば悪用されます。 カスタムの Web ベース ID 管理アプリケーションで攻撃を受けた場合は、攻撃者が独自の ID を作成し、アクセス許可と権限を変更して、全体的な侵害を招く可能性があります。

クロスサイト スクリプティングと SQL インジェクションの詳細については、このドキュメントでは説明しませんが、「Open Web Application Security Project (OWASP)」では、脆弱性と対策の詳細な説明を含む上位 10 件のリストが公開されています。

インフラストラクチャのセキュリティに投資しても、設計とコード記述の品質が低いアプリケーションがそのインフラストラクチャ内に展開されていると、環境は攻撃に対して脆弱になります。 適切に保護されたインフラストラクチャでも、これらのアプリケーション攻撃に対する効果的な対策を提供できないことがしばしばあります。 この問題を総括すると、不適切に設計されたアプリケーションでは、アプリケーションを機能させるために、サービス アカウントに過剰なアクセス許可を付与する必要があります。

Microsoft セキュリティ開発ライフサイクル (SDL) は、セキュリティを強化するために動作する構造的なプロセス コントロールのセットであり、初期の要件収集から開始して、アプリケーションが使用停止になるまでそのライフサイクルを通じて拡張を行います。 この効果的なセキュリティ コントロールの統合は、セキュリティの観点から重要なだけではなく、コストとスケジュールに対して効率良くアプリケーションのセキュリティを確保するためにも重要です。 実質的なコードの完了時にアプリケーションのセキュリティ上の問題を評価すると、組織がアプリケーションのセキュリティに関する決定を行う必要が生じるのがアプリケーションを展開する直前、または後になることさえあります。 組織は、アプリケーションを実稼働環境に展開する前にアプリケーションの欠陥に対処してコストと遅延を発生させるか、既知のセキュリティ欠陥があるまま実稼働環境にアプリケーションを展開して組織を侵害にさらすかを選択することになります。

組織によっては、実稼働コードのセキュリティの問題の修正に問題 1 件あたり 1 万ドルを超える総費用をかけますが、効果的な SDL なしで開発されたアプリケーションは、10 万行のコードあたり 10 件を超える高い重大度の問題が発生する可能性があります。 大規模なアプリケーションでは、コストが急激に増大します。 これに対し、多くの企業は、SDL の最終コード レビュー ステージで、10 万行のコードごとに 1 件未満の問題のベンチマークを設定し、実稼働環境で高いリスクのアプリケーションでの問題ゼロ件を目指しています。

SDL を実装すると、初期のアプリケーションの要件収集でセキュリティ要件を組み込み、高いリスクのアプリケーションの設計に脅威モデリングが提供され、開発者の効果的なトレーニングと監視が要求され、明確で一貫性のあるコード標準とプラクティスが要求されることでセキュリティが向上します。 SDL の最終的な効果は、アプリケーションのセキュリティの大幅な向上と、アプリケーションの開発、展開、保守、および使用停止のコストの削減です。 SDL の設計と実装の詳細については、このドキュメントでは説明しませんが、詳細なガイダンスと情報については「Microsoft セキュリティ開発ライフサイクル」に関するページを参照してください。