かつてのペンテスト、または泌尿器科医とロスコムナゾールの助けを借りてすべてを打ち破る方法

この記事は、グループ IB の専門家が数年前に実施し、大成功を収めた侵入テストに基づいて書かれました。ボリウッドで映画化される可能性のある物語が起こりました。 さて、おそらく読者の反応はこうなるだろう。「ああ、また PR 記事だ。またこのようなことが描かれている。どれだけ優れているのか。ペンテストを買うのを忘れないでね。」 まあ、一方ではそうです。 ただし、この記事が掲載された理由は他にもいくつかあります。 私は、ペンテスターが正確に何をするのか、この作業がどれほど面白くて簡単ではないのか、プロジェクトでどのようなおかしな状況が発生する可能性があるのか​​、そして最も重要なことに、実際の例を使ってライブ資料を示したかったのです。

世界の謙虚さのバランスを回復するために、しばらくしてから、うまくいかなかったペンテストについて書きます。 企業内で適切に設計されたプロセスが、たとえ十分に準備されたものであっても、そのプロセスが存在し実際に機能するというだけの理由で、あらゆる種類の攻撃からどのように保護できるかを示します。

この記事の顧客にとっても、私たちの感覚によれば、すべてが全般的に優れており、少なくともロシア連邦市場の 95% よりも優れていましたが、一連の長い出来事を形成する多くの小さな微妙な違いがありました。作業に関する長いレポートが生まれ、そしてこの記事に至りました。

それでは、ポップコーンを買いだめして、探偵物語へようこそ。 言葉 - パベル・スプリュニュク、Group-IB の「監査およびコンサルティング」部門の技術マネージャー。

パート 1. ポチキン博士

2018年顧客はハイテク IT 企業であり、同社自体が多くの顧客にサービスを提供しています。 「最初の知識やアクセスがなくても、インターネット経由で作業して Active Directory ドメイン管理者権限を取得することは可能ですか?」という質問に対する答えが知りたいと考えています。 ソーシャル エンジニアリングには興味がありません (ああ、でも無駄だった)、意図的に作業を妨害するつもりはありませんが、たとえば、動作がおかしくなっているサーバーを誤ってリロードする可能性があります。 追加の目標は、外周に対する他の攻撃ベクトルをできるだけ多く特定することです。 同社はこのようなテストを定期的に実施しており、新たなテストの期限が到来した。 条件はほぼ典型的で、適切で、理解可能です。 始めましょう。

顧客の名前があります。メイン Web サイトを含めて「会社」とします。 www.company.ru。 もちろん、顧客の呼び方は異なりますが、この記事ではすべてが非個人的なものになります。
私はネットワーク偵察を行います。顧客に登録されているアドレスとドメインを調べ、ネットワーク図を描き、これらのアドレスにサービスがどのように配信されているかを調べます。 結果は、4000 を超えるライブ IP アドレスです。 私はこれらのネットワークのドメインに注目します。幸いなことに、大多数は顧客のクライアントを対象としたネットワークであり、私たちはそれらのネットワークに正式には関心を持っていません。 顧客も同じことを考えています。

256 個のアドレスを持つ XNUMX つのネットワークが残ります。この時点で、IP アドレスごとのドメインとサブドメインの分布がすでに理解されており、スキャンされたポートに関する情報があるため、興味深いポートのサービスを調べることができます。 並行して、あらゆる種類のスキャナが利用可能な IP アドレス上で起動され、Web サイト上で個別に起動されます。

たくさんのサービスがあります。 通常、これはペンテスターに​​とって喜びであり、サービスが多ければ多いほど攻撃のフィールドが広くなり、アーティファクトを見つけるのが容易になるため、すぐに勝利するという期待です。 Web サイトをざっと見たところ、そのほとんどは大手グローバル企業の有名な製品の Web インターフェイスであり、どう見ても歓迎されていないことがわかります。 ユーザー名とパスワードを要求したり、XNUMX 番目の要素を入力するフィールドを削除したり、TLS クライアント証明書を要求したり、それを Microsoft ADFS に送信したりします。 インターネットからアクセスできないものもあります。 一部の人にとっては、明らかに XNUMX つの給与を支払うための特別な有料クライアントを持っているか、入力する正確な URL を知っている必要があります。 既知の脆弱性のソフトウェア バージョンを「突破」しようとしたり、Web パス内の隠されたコンテンツや LinkedIn などのサードパーティ サービスから漏洩したアカウントを検索したり、それらを使用してパスワードを推測したりするプロセスで、徐々に落胆するもう XNUMX 週間を省略しましょう。たとえば、自分で作成した Web サイトの脆弱性を発掘するなどです。ちなみに、統計によると、これは今日の外部攻撃の最も有望なベクトルです。 その後に発射された映画の銃にすぐに注目します。

そこで、何百ものサービスの中から際立った XNUMX つのサイトを見つけました。 これらのサイトには XNUMX つの共通点がありました。ドメインごとに綿密なネットワーク偵察を行わず、開いているポートを正面から探すか、既知の IP 範囲を使用して脆弱性スキャナーをターゲットにする場合、これらのサイトはスキャンを回避し、単純にスキャン対象外になります。 DNS 名がわからなくても表示されます。 おそらく、それらは少なくとも以前に見逃されており、たとえそれらがリソースに直接送信されたとしても、私たちの自動ツールはそれらに関する問題を検出しませんでした。

ちなみに、以前に発売されたスキャナーが一般的に見つけたものについて。 思い出してもらいたいのですが、一部の人にとって、「侵入テスト」は「自動スキャン」と同じです。 しかし、このプロジェクトのスキャナーは何も言いませんでした。 そうですね、最大値は中程度の脆弱性 (深刻度の点で 3 段階中 5 段階) で示されました。一部のサービスでは不正な TLS 証明書または古い暗号化アルゴリズムがあり、ほとんどのサイトではクリックジャッキングが発生しました。 しかし、これでは目標を達成することはできません。 おそらくここではスキャナーの方が便利かもしれませんが、思い出させてください。顧客自身がそのようなプログラムを購入して自分でテストすることができ、悲惨な結果から判断すると、彼はすでにチェックしました。

「異常な」サイトに戻りましょう。 XNUMX つ目は、標準以外のアドレスにあるローカル Wiki のようなものですが、この記事では wiki.company[.]ru とします。 また、彼女はすぐにログインとパスワードを要求しましたが、ブラウザの NTLM を使用しました。 ユーザーにとって、これはユーザー名とパスワードの入力を求める禁欲的なウィンドウのように見えます。 そして、これは悪い習慣です。

ちょっとしたメモ。 境界 Web サイトの NTLM は、さまざまな理由から悪影響を及ぼします。 XNUMX つ目の理由は、Active Directory ドメイン名が公開されてしまうことです。 この例では、「外部」DNS 名と同様に、company.ru であることが判明しました。 これを知っていると、悪意のあるものを慎重に準備して、サンドボックスではなく組織のドメイン マシン上でのみ実行されるようにすることができます。 次に、認証は NTLM 経由でドメイン コントローラーを直接経由し (驚きですよね?)、アカウントのパスワード入力試行回数が超過するのをブロックするなど、「内部」ネットワーク ポリシーのすべての機能が使用されます。 攻撃者がログイン情報を見つけた場合、そのパスワードを試行します。 アカウントが間違ったパスワードを入力するのをブロックするように構成されている場合、それは機能し、アカウントはブロックされます。 第三に、そのような認証に XNUMX 番目の要素を追加することは不可能です。 読者の中でその方法をまだ知っている人がいたら、ぜひ教えてください。とても興味深いものです。 XNUMX 番目は、Pass-the-Hash 攻撃に対する脆弱性です。 ADFS は、とりわけ、これらすべてから保護するために発明されました。

Microsoft 製品には悪い特性が XNUMX つあります。そのような NTLM を特に公開​​していなくても、少なくとも OWA と Lync にはデフォルトでインストールされてしまいます。

ちなみに、この記事の筆者も同じ手口で、ある大手銀行の行員約1000人の口座を誤ってわずかXNUMX時間でブロックしてしまい、その時は少し青ざめたことがあります。 銀行の IT サービスも青ざめていましたが、すべてがうまく適切に終了し、この問題を最初に発見し、迅速かつ決定的な修正を行ったことで賞賛さえされました。

10 番目のサイトのアドレスは「明らかにある種の姓.company.ru」でした。 Google で見つけました。XNUMX ページに次のようなものがありました。 デザインは XNUMX 年代初頭から中期のもので、立派な人がメイン ページから次のようなものを見ていました。

ここでは「Heart of a Dog」の静止画を撮ったのですが、信じてください、なんとなく似ていて、カラーデザインも同じようなトーンでした。 サイトを次のように呼びます preobrazhensky.company.ru.

それは泌尿器科医の個人的なウェブサイトでした。 泌尿器科医のウェブサイトがハイテク企業のサブドメインで何をしているのか疑問に思いました。 Google をざっと調べてみたところ、この医師は当社の顧客の法人の共同創設者であり、認可資本として約 1000 ルーブルを寄付していたこともわかりました。 このサイトはおそらく何年も前に作成され、顧客のサーバー リソースがホスティングとして使用されていました。 このサイトは長い間その関連性を失っていたが、何らかの理由で長期間にわたって機能し続けた。

脆弱性という点では、Web サイト自体は安全でした。 将来的には、これは一連の静的な情報、つまり腎臓と膀胱の形で挿入されたイラストが含まれる単純な HTML ページだったと言えます。 このようなサイトを「壊す」のは無駄です。

しかし、その下の Web サーバーはもっと興味深いものでした。 HTTP Server ヘッダーから判断すると、IIS 6.0 が搭載されており、オペレーティング システムとして Windows 2003 を使用していたことを意味します。 スキャナーは、この特定の泌尿器科医の Web サイトが、同じ Web サーバー上の他の仮想ホストとは異なり、PROPFIND コマンドに応答し、WebDAV を実行していることを以前に特定していました。 ちなみに、スキャナはこの情報を Info というマークで返しました (スキャナ レポートの言葉で言えば、これは最も危険性が低いことを意味します)。通常、このような情報は単純にスキップされます。 これが組み合わさって興味深い影響を与えましたが、これは Google で再度調査した後に初めて明らかになりました。これは、Shadow Brokers セットに関連する稀なバッファ オーバーフローの脆弱性、つまり CVE-2017-7269 であり、すでに既製のエクスプロイトが存在していました。 つまり、Windows 2003 を使用していて、WebDAV が IIS 上で実行されている場合、問題が発生します。 とはいえ、2003 年の運用環境で Windows 2018 を実行すること自体が問題です。

このエクスプロイトは最終的に Metasploit に到達し、制御されたサービスに DNS リクエストを送信する負荷で直ちにテストされました。伝統的に DNS リクエストをキャッチするために Burp Collaborator が使用されていました。 驚いたことに、これは初めて機能しました。DNS ノックアウトが受信されました。 次に、ポート 80 を介してバックコネクト (つまり、被害ホスト上の cmd.exe にアクセスできる、サーバーから攻撃者へのネットワーク接続) を作成しようとしましたが、大失敗が発生しました。 接続は確立されず、XNUMX 回目にサイトを使用しようとした後、すべての興味深い写真とともに永久に消えてしまいました。

通常、この後に「お客様、起きてください。すべてを落としました。」という形式の手紙が続きます。 しかし、このサイトはビジネスプロセスとは何の関係もなく、サーバー全体と同様に何の理由もなくそこで動作しており、このリソースを自由に使用してよいと言われました。
約 6.0 日後、サイトが突然勝手に動作し始めました。 IIS 30 上で WebDAV からベンチを構築したところ、デフォルト設定では IIS ワーカー プロセスが 30 時間ごとに再起動されることがわかりました。 つまり、制御がシェルコードを終了すると、IIS ワーカー プロセスが終了し、その後数回自動的に再起動され、その後 XNUMX 時間休止状態になります。

最初に TCP へのバック接続が失敗したため、この問題は閉じられたポートにあると考えました。 つまり、発信接続が外部に通過することを許可しない、ある種のファイアウォールの存在を想定していました。 多くの TCP ポートと UDP ポートを検索するシェルコードを実行し始めましたが、効果はありませんでした。 Metasploit からの http(s) 経由のリバース接続ロードが機能しませんでした - meterpreter/reverse_http(s)。 突然、同じポート 80 への接続が確立されましたが、すぐに切断されました。 私はこれを、検針員の交通を好まない、まだ想像上の IPS の行動によるものだと考えました。 ポート 80 への純粋な tcp 接続は通過せず、http 接続は通過したという事実を考慮して、http プロキシが何らかの形でシステムに構成されていると結論付けました。

DNS経由でmeterpreterも試してみました（ありがとう） d00kie あなたの努力のおかげで、多くのプロジェクトが救われました）、最初の成功を思い出しますが、それはスタンド上でさえ機能しませんでした - この脆弱性に対してシェルコードが大きすぎました。

実際には次のようになりました。3 分以内に 4 ～ 5 回の攻撃が試みられ、その後 30 時間待機しました。 などをXNUMX週連続で続けます。 時間を無駄にしないようにリマインダーも設定しました。 さらに、テスト環境と運用環境の動作には違いがありました。この脆弱性に対しては、同様のエクスプロイトが XNUMX つあり、XNUMX つは Metasploit から、もう XNUMX つはインターネットから、Shadow Brokers バージョンから変換されました。 そのため、Metasploit のみが戦闘でテストされ、XNUMX つ目のみがベンチでテストされました。これにより、デバッグがさらに困難になり、頭を使うことになりました。

最終的に、http 経由で特定のサーバーから exe ファイルをダウンロードし、ターゲット システム上で起動するシェルコードが効果的であることが証明されました。 シェルコードは十分小さいものでしたが、少なくとも機能しました。 サーバーは TCP トラフィックをまったく好まず、http で meterpreter の存在が検査されたため、このシェルコードを通じて DNS-meterpreter を含む exe ファイルをダウンロードするのが最も速い方法であると判断しました。

ここでも問題が発生しました。exe ファイルをダウンロードするときに、試行した結果、どれをダウンロードしてもダウンロードが中断されました。 繰り返しになりますが、私のサーバーと泌尿器科医の間にあるセキュリティ デバイスが、内部に exe を含む http トラフィックを好まなかったのです。 「迅速な」解決策は、実行中に http トラフィックを難読化して、exe の代わりに抽象バイナリ データが転送されるようにシェルコードを変更することのようです。 最終的に、攻撃は成功し、シン DNS チャネルを通じて制御が受信されました。

私が最も基本的な IIS ワークフロー権限を持っていることがすぐに明らかになり、何もすることができなくなりました。 Metasploit コンソールでは次のように表示されます。

すべての侵入テスト手法では、アクセスを取得する際に権限を増やす必要があることが強く示唆されています。 私は通常、これをローカルで行いません。最初のアクセスは単にネットワーク エントリ ポイントとして見なされ、同じネットワーク上の別のマシンを侵害することは、通常、既存のホストで権限を昇格するよりも簡単かつ迅速だからです。 ただし、DNS チャネルは非常に狭く、トラフィックが解消されないため、これは当てはまりません。

この Windows 2003 サーバーの有名な MS17-010 脆弱性が修復されていないと仮定して、メータープレッター DNS トンネルを介してローカルホストへのトラフィックをポート 445/TCP にトンネルし (はい、これも可能です)、以前にダウンロードした exe を実行してみます。脆弱性。 攻撃は機能し、XNUMX 番目の接続を受け取りますが、SYSTEM 権限が必要です。

興味深いのは、彼らが依然としてサーバーを MS17-010 から保護しようとしていたことです。脆弱なネットワーク サービスが外部インターフェイスで無効になっていました。 これにより、ネットワーク経由の攻撃から保護されますが、ローカルホスト上の SMB をすぐに無効にすることはできないため、ローカルホスト内からの攻撃は機能しました。

次に、新たな興味深い詳細が明らかになります。

1. SYSTEM 権限があると、TCP 経由でバック接続を簡単に確立できます。 明らかに、ダイレクト TCP を無効にすることは、限定された IIS ユーザーにとって厳密には問題です。 スポイラー: IIS ユーザー トラフィックは、どういうわけか双方向でローカル ISA プロキシにラップされていました。 それがどのように正確に機能するかは、私は再現していません。
2. 私は特定の「DMZ」にいます (これは Active Directory ドメインではなく、WORKGROUP です) - それは論理的に聞こえます。 しかし、予期されたプライベート (「グレー」) IP アドレスの代わりに、以前に攻撃したものとまったく同じ、完全に「白」の IP アドレスを持っています。 これは、同社が IPv4 アドレッシングの世界では非常に古く、128 年のシスコのマニュアルに記載されているように、スキームに従って NAT を使用せずに 2005 個の「ホワイト」アドレスの DMZ ゾーンを維持する余裕があることを意味します。

サーバーが古いため、Mimikatz はメモリから直接動作することが保証されています。

ローカル管理者のパスワードを取得し、TCP 経由で RDP トラフィックをトンネリングし、快適なデスクトップにログインします。 サーバーでやりたいことは何でもできるので、ウイルス対策ソフトウェアを削除したところ、サーバーは TCP ポート 80 と 443 経由でのみインターネットからアクセス可能であり、443 はビジーではないことがわかりました。 私は 443 に OpenVPN サーバーをセットアップし、VPN トラフィックに NAT 機能を追加し、OpenVPN を通じて無制限の形式で DMZ ネットワークに直接アクセスできるようにしました。 ISA は無効になっていない IPS 機能をいくつか備えているため、ポート スキャンでトラフィックをブロックしたため、よりシンプルで準拠性の高い RRAS に置き換える必要があったことは注目に値します。 そのため、ペンテスターは依然としてさまざまなことを管理しなければならないことがあります。

注意深い読者は、「XNUMX 番目のサイト、つまり NTLM 認証を備えた Wiki についてはどうでしょうか? これについては多くのことが書かれています。」と尋ねるでしょう。 これについては後で詳しく説明します。

パート 2. まだ暗号化していないのですか? それでは、私たちはすでにここであなたのところに来ています

したがって、DMZ ネットワーク セグメントにアクセスできます。 ドメイン管理者に行く必要があります。 最初に思い浮かぶのは、DMZ セグメント内のサービスのセキュリティを自動的にチェックすることです。特に、現在はさらに多くのサービスが研究のために公開されているためです。 ペネトレーション テスト中の典型的な図: 外部境界は内部サービスよりも保護されており、大規模なインフラストラクチャ内でアクセスを取得する場合、ドメイン内で拡張された権利を取得する方がはるかに簡単です。これは、このドメインが保護され始めているためです。次に、数千のホストが存在するインフラストラクチャでは、常にいくつかの重大な問題が発生します。

OpenVPN トンネル経由で DMZ 経由でスキャナを充電し、待ちます。 私はレポートを開きました - これも深刻なものではありません、どうやら誰かが私より前に同じ方法を経験したようです。 次のステップは、DMZ ネットワーク内のホストがどのように通信するかを調べることです。 これを行うには、まず通常の Wireshark を起動し、ブロードキャスト リクエスト (主に ARP) をリッスンします。 ARP パケットは XNUMX 日中収集されました。 このセグメントでは複数のゲートウェイが使用されていることがわかります。 これは後で役に立ちます。 ARP リクエストとレスポンスのデータとポート スキャン データを組み合わせることで、Web やメールなどのこれまで知られていたサービスに加えて、ローカル ネットワーク内からのユーザー トラフィックの出口ポイントを発見しました。

現時点では他のシステムにアクセスできず、企業サービス用のアカウントも XNUMX つも持っていなかったので、ARP スプーフィングを使用してトラフィックから少なくとも一部のアカウントを釣り出すことにしました。

Cain&Abel は泌尿器科医のサーバー上で起動されました。 特定されたトラフィック フローを考慮して、中間者攻撃に最も有望なペアが選択され、サーバーを再起動するタイマーを使用して、5 ～ 10 分間の短期間の起動によって一部のネットワーク トラフィックが受信されました。凍結の場合。 冗談のように、ニュースが XNUMX つありました。

1. 良い結果: 多くの認証情報が捕捉され、攻撃は全体として機能しました。
2. 悪い点: すべての認証情報は顧客自身のクライアントからのものでした。 サポート サービスを提供する際、カスタマー スペシャリストは、必ずしもトラフィック暗号化が設定されていないクライアントのサービスに接続していました。

その結果、プロジェクトの文脈では役に立たないが、攻撃の危険性を示すものとしては間違いなく興味深い資格情報を多数取得しました。 Telnet を備えた大企業のボーダー ルーター、デバッグ http ポートをすべてのデータとともに内部 CRM に転送、ローカル ネットワーク上の Windows XP から RDP への直接アクセス、およびその他の隠蔽機能。 このようになりました MITREマトリックスに基づくサプライチェーンの侵害.

また、交通機関からの手紙を集める面白い機会も見つけました。このようなものです。 これは、顧客から顧客の SMTP ポートに送信された既製の手紙の例です。これも暗号化は行われていません。 アンドレイという人は、同名の人物にドキュメントの再送信を依頼し、そのドキュメントは XNUMX 通の返信レターでログイン、パスワード、リンクとともにクラウド ディスクにアップロードされます。

これは、すべてのサービスを暗号化するためのもう XNUMX つの注意事項です。 プロバイダー、別の会社のシステム管理者、またはそのような侵入テスターなど、具体的に誰がいつデータを読み取って使用するかは不明です。 多くの人が暗号化されていないトラフィックを単純に傍受できるという事実については、私は沈黙しています。

一見成功したように見えましたが、これでは私たちは目標に近づくことができませんでした。 もちろん、長時間放置して貴重な情報を聞き出すことは可能ですが、それがそこに現れるという事実はなく、攻撃自体はネットワークの完全性の観点から非常に危険です。

サービスをさらに詳しく調べたところ、興味深いアイデアが思いつきました。 Responder と呼ばれるユーティリティがあり (この名前で使用例を簡単に見つけることができます)、ブロードキャスト リクエストを「ポイズニング」することで、SMB、HTTP、LDAP などのさまざまなプロトコルを介した接続を引き起こします。 次に、接続するすべての人に認証を求め、NTLM 経由で被害者に透過的なモードで認証が行われるように設定します。 ほとんどの場合、攻撃者はこの方法で NetNTLMv2 ハンドシェイクを収集し、そこから辞書を使用してユーザー ドメインのパスワードを迅速に回復します。 ここでも同様のものを望んでいましたが、ユーザーは「壁の後ろ」に座っていました。つまり、ファイアウォールによって分離されており、Blue Coat プロキシ クラスターを介して WEB にアクセスしていました。

Active Directory ドメイン名が「外部」ドメインと一致する、つまり company.ru であると指定したことを覚えていますか? そのため、Windows、より正確には Internet Explorer (および Edge と Chrome) では、サイトが「イントラネット ゾーン」にあると考えられる場合、ユーザーが NTLM 経由で HTTP で透過的に認証できるようになります。 「イントラネット」の兆候の XNUMX つは、「グレー」の IP アドレス、またはドットのない短い DNS 名へのアクセスです。 「白い」IP と DNS 名 preobrazhensky.company.ru を持つサーバーがあり、ドメイン マシンは通常、名前入力を簡略化するために DHCP 経由で Active Directory ドメイン サフィックスを受信するため、アドレス バーに URL を書き込むだけで済みました。 プレオブラジェンスキー、侵害された泌尿器科医のサーバーへの正しいパスを見つけるため、これが現在「イントラネット」と呼ばれていることを忘れないでください。 つまり、同時に、ユーザーの知らないうちに、ユーザーの NTLM ハンドシェイクを私に提供することになります。 残っているのは、クライアントのブラウザに、このサーバーに接続する緊急の必要性について考えさせることだけです。

素晴らしい Intercepter-NG ユーティリティが助けてくれました (ありがとう) インターセプター）。 これにより、トラフィックをその場で変更できるようになり、Windows 2003 でうまく機能しました。トラフィック フロー内の JavaScript ファイルのみを変更するための別個の機能も備えていました。 一種の大規模なクロスサイト スクリプティングが計画されました。

ユーザーがグローバル WEB にアクセスする際に経由する Blue Coat プロキシは、静的コンテンツを定期的にキャッシュしました。 トラフィックを遮断することで、彼らが XNUMX 時間体制で作業し、ピーク時のコンテンツの表示を高速化するために頻繁に使用される静的リクエストを際限なく要求していることは明らかでした。 さらに、BlueCoat には特定のユーザー エージェントがあり、実際のユーザーと明確に区​​別されていました。

Javascript が用意され、Intercepter-NG を使用して、Blue Coat 用の JS ファイルを使用して応答ごとに夜間 XNUMX 時間実装されました。 スクリプトは次のことを実行しました。

• User-Agent によって現在のブラウザを特定しました。 Internet Explorer、Edge、または Chrome の場合は、引き続き動作しました。
• ページの DOM が形成されるまで待ちました。
• フォームの src 属性を使用して、非表示の画像を DOM に挿入しました。 プレオブラジェンスキー:8080/NNNNNNNN.png、ここで NNN は BlueCoat がキャッシュしないようにするための任意の数字です。
• グローバル フラグ変数を設定して、注入が完了し、イメージを挿入する必要がなくなったことを示します。

ブラウザはこのイメージをロードしようとしましたが、侵害されたサーバーのポート 8080 で、同じレスポンダーが実行されている私のラップトップへの TCP トンネルがイメージを待機しており、ブラウザは NTLM 経由でログインする必要がありました。

レスポンダーのログから判断すると、人々は朝出勤し、ワークステーションの電源を入れ、その後、NTLM ハンドシェイクを「排出」することを忘れずに、いつの間にか泌尿器科医のサーバーに一斉にアクセスし始めました。 ハンドシェイクは一日中降り続き、明らかにパスワードを回復する攻撃が成功するための材料が蓄積されました。 レスポンダーのログは次のようになります。

ユーザーによる泌尿器科医サーバーへの大量秘密訪問

おそらくすでにお気づきかと思いますが、この物語全体が「すべてがうまくいきましたが、その後は残念なことがあり、その後は克服があり、その後すべてが成功する」という原則に基づいて構築されています。 さて、ここで残念なことがありました。 2 回のユニークな握手のうち、公開された握手は XNUMX つもありませんでした。 これは、プロセッサが故障したラップトップであっても、これらの NTLMvXNUMX ハンドシェイクが XNUMX 秒あたり数億回の試行速度で処理されるという事実を考慮しています。

パスワード変更テクニック、ビデオ カード、分厚い辞書を装備して待つ必要がありました。 長い時間が経った後、「Q11111111....1111111q」という形式のパスワードを持つ複数のアカウントが明らかになりました。これは、すべてのユーザーがかつては大文字と小文字が異なる非常に長いパスワードを考えることを強制されていたことを示唆しています。複雑になる。 しかし、経験豊富なユーザーをだますことはできません。彼はこうして自分自身を覚えやすくしました。 合計で約 5 つのアカウントが侵害され、サービスに対する貴重な権利を持っていたのはそのうちの XNUMX つだけでした。

パート 3. ロスコムナゾールの反撃

これで、最初のドメイン アカウントが受信されました。 長い文章を読んでこの時点でまだ眠っていない方は、認証の XNUMX 番目の要素を必要としないサービスについて言及したことを覚えているでしょう。それは NTLM 認証を使用する Wiki です。 もちろん、最初にすることはそこに入ることでした。 社内の知識ベースを掘り下げると、すぐに結果が得られました。

• 同社は、ローカル ネットワークにアクセスできるドメイン アカウントを使用した認証を備えた WiFi ネットワークを持っています。 現在のデータセットでは、これはすでに有効な攻撃ベクトルですが、自分の足でオフィスに行き、顧客のオフィスの領域のどこかにいる必要があります。
• ユーザーがローカル ネットワーク内にいて、自分のドメイン ログインとパスワードを自信を持って覚えている場合に、「第 XNUMX 要素」認証デバイスを独自に登録できるサービスがあるという指示を見つけました。 この場合、「内部」と「外部」は、ユーザーが本サービスのポートにアクセスできるかどうかによって決まります。 このポートにはインターネットからはアクセスできませんでしたが、DMZ 経由では十分にアクセスできました。

もちろん、私の携帯電話上のアプリケーションの形で、侵害されたアカウントに「第 XNUMX 要素」がすぐに追加されました。 アクションの「承認」/「不承認」ボタンを備えたプッシュ要求を大声で電話に送信したり、さらに独立した入力のために画面に OTP コードを静かに表示したりできるプログラムがありました。 さらに、説明書では最初の方法が唯一正しいとされていましたが、OTP 方法とは異なり、機能しませんでした。

「XNUMX 番目の要素」が壊れたため、Citrix Netscaler Gateway で Outlook Web Access メールとリモート アクセスにアクセスできました。 Outlook のメールに驚きの内容がありました。

この珍しいショットでは、Roskomnadzor がペンテスターをどのように支援しているかを見ることができます

これらは、数千のアドレスを持つネットワーク全体が容赦なくアクセス不能になった、有名な「ファン」による Telegram のブロックから最初の数か月でした。 なぜプッシュがすぐに機能しなかったのか、そしてなぜ私の「被害者」が営業時間中にアカウントを使い始めたために警報を鳴らさなかったのかが明らかになりました。

Citrix Netscaler に詳しい人なら誰でも、Citrix Netscaler は通常、ユーザーに画像インターフェイスのみを伝え、サードパーティ アプリケーションを起動してデータを転送するツールを与えず、あらゆる方法でアクションを制限するような方法で実装されていると想像するでしょう。標準の制御シェルを介して。 私の「被害者」は職業柄、1C しかもらえませんでした。

1C インターフェースを少し見て回ったところ、そこに外部処理モジュールがあることがわかりました。 これらはインターフェイスからロードでき、権限と設定に応じてクライアントまたはサーバーで実行されます。

私は 1C プログラマーの友人に、文字列を受け取って実行する処理を作成するように依頼しました。 1C 言語では、プロセスの開始は次のようになります (インターネットから抜粋)。 1C 言語の構文はロシア語を話す人々をその自発性で驚かせていることに同意しますか?

処理は完璧に実行され、侵入テスト者が「シェル」と呼ぶものであることが判明し、それを通じて Internet Explorer が起動されました。

以前、その領土へのパスを注文できるシステムのアドレスが郵便で発見されました。 WiFi 攻撃ベクトルを使用する必要がある場合に備えてパスを注文しました。

インターネットでは、顧客のオフィスにはまだおいしい無料のケータリングがあったという話がありますが、私はまだ攻撃をリモートで展開することを好みました。そのほうが穏やかです。

Citrix を実行しているアプリケーション サーバーで AppLocker がアクティブ化されましたが、バイパスされました。 http バージョンでは接続を望まなかったため、同じ Meterpreter が DNS 経由でロードされ、起動されました。また、その時点では内部プロキシ アドレスがわかりませんでした。 ちなみに、この瞬間から、外部侵入テストは実質的に完全に内部侵入テストに変わりました。

パート 4. ユーザーの管理者権限は悪いですよね?

ドメイン ユーザー セッションの制御を取得する際のペンテスターの最初のタスクは、ドメイン内の権利に関するすべての情報を収集することです。 BloodHound ユーティリティを使用すると、ドメイン コントローラーから LDAP プロトコル経由でユーザー、コンピューター、セキュリティ グループに関する情報、および SMB 経由で、どのユーザーが最近ログインしたか、ローカル管理者が誰であるかなどの情報を自動的にダウンロードできます。

ドメイン管理者権限を奪取するための典型的な手法は、単調なアクションのサイクルとして単純化されます。

• すでに取得されているドメイン アカウントに基づいて、ローカル管理者権限があるドメイン コンピューターに移動します。
• Mimikatz を起動し、最近このシステムにログインしたドメイン アカウントのキャッシュされたパスワード、Kerberos チケット、および NTLM ハッシュを取得します。 または、lsass.exe プロセスのメモリ イメージを削除し、こちら側でも同じことを行います。 これは、デフォルト設定の 2012R2/Windows 8.1 より前の Windows でうまく機能します。
• 侵害されたアカウントがローカル管理者権限を持っている場所を特定します。 最初の点を繰り返します。 ある段階で、ドメイン全体の管理者権限を取得します。

1C プログラマーがここに書くような「サイクルの終わり」。

したがって、このユーザーは、Windows 7 を搭載した XNUMX 台のホストのみのローカル管理者であることが判明しました。そのホストの名前には、個人用仮想マシンである「VDI」または「仮想デスクトップ インフラストラクチャ」という単語が含まれていました。 おそらく、VDI サービスの設計者は、VDI はユーザーの個人的なオペレーティング システムであるため、ユーザーがソフトウェア環境を自由に変更しても、ホストは引き続き「リロード」できることを意味したのでしょう。 また、一般的にこのアイデアは良いと思いました。私はこの個人用 VDI ホストに行き、そこにネストを作成しました。

• そこに OpenVPN クライアントをインストールし、インターネットを介してサーバーへのトンネルを作成しました。 クライアントはドメイン認証で同じ Blue Coat を強制的に通過する必要がありましたが、OpenVPN は、言わば「すぐに使える」それを実現しました。
• VDI に OpenSSH をインストールしました。 そうですね、実際のところ、SSH のない Windows 7 とは何でしょうか?

ライブではこんな感じでした。 これはすべて Citrix と 1C を通じて行う必要があることを思い出してください。

隣接するコンピュータへのアクセスを促進する XNUMX つの手法は、ローカル管理者のパスワードが一致するかどうかを確認することです。 ここですぐに幸運が待っていました。デフォルトのローカル管理者 (突然管理者と呼ばれるようになりました) の NTLM ハッシュが、数百ある隣接する VDI ホストへのパス ザ ハッシュ攻撃を通じて接近されました。 もちろん、その攻撃は即座に彼らを襲った。

ここでは、VDI 管理者が自分の足を XNUMX 回撃った場所です。

• XNUMX 回目は、VDI マシンが LAPS の管理下に置かれておらず、基本的に VDI に大規模に展開されたイメージからの同じローカル管理者パスワードを保持していたときでした。
• デフォルトの管理者は、ハッシュパス攻撃に対して脆弱な唯一のローカル アカウントです。 同じパスワードを使用する場合でも、複雑でランダムなパスワードを持つ XNUMX 番目のローカル管理者アカウントを作成し、デフォルトのアカウントをブロックすることで、大量侵害を回避することが可能です。

その Windows にはなぜ SSH サービスがあるのでしょうか? 非常にシンプルです。OpenSSH サーバーは、ユーザーの作業を妨げることなく、便利な対話型コマンド シェルを提供するだけでなく、VDI 上の Socks5 プロキシも提供します。 このソックスを介して SMB 経由で接続し、数百台の VDI マシンすべてからキャッシュされたアカウントを収集し、BloodHound グラフでそれらを使用してドメイン管理者へのパスを探しました。 何百ものホストを自由に使えるので、この方法はすぐに見つかりました。 ドメイン管理者権限を取得しました。

これは、同様の検索を示すインターネット上の画像です。 接続には、管理者がどこにいるのか、誰がどこにログインしているのかが表示されます。

ちなみに、プロジェクト開始時の条件「ソーシャルエンジニアリングを使用しない」を覚えておいてください。 そこで私は、ありきたりなフィッシングが依然として可能だった場合、特殊効果のあるボリウッド作品がどれだけ遮断されるかを考えてみることを提案します。 しかし、個人的には、これらすべてを行うのは非常に興味深いものでした。 楽しんで読んでいただければ幸いです。 もちろん、すべてのプロジェクトがそれほど魅力的に見えるわけではありませんが、全体としての仕事は非常にやりがいがあり、停滞することはありません。

おそらく誰かが質問するでしょう：どうやって自分を守るのですか？ この記事でも多くのテクニックが説明されていますが、その多くは Windows 管理者さえ知りません。 ただし、私はこれらをありきたりな原則と情報セキュリティ対策の観点から見てみることを提案します。

• 古いソフトウェアを使用しないでください (最初の Windows 2003 を覚えていますか?)
• 不必要なシステムをオンにしたままにしないでください (なぜ泌尿器科医の Web サイトがあったのですか?)
• ユーザーのパスワードの強度を自分でチェックしてください（そうでない場合は兵士...侵入テスト担当者がこれを行います）
• 異なるアカウントに同じパスワードを使用しない (VDI 侵害)
• そしてもう一つ

もちろん、これを実装するのは非常に困難ですが、次の記事ではそれが十分に可能であることを実際に示します。

出所： habr.com