AiTM攻撃とは？ 10分でわかりやすく解説

UnsplashのEd Hardieが撮影した写真      

AiTM攻撃（Adversary-in-the-Middle）は、逆プロキシ型のフィッシングでログイン処理をその場で中継し、認証後のセッションを奪う手口です。MFAを入れていても、認証後に出るセッションCookieやトークンを取られると、攻撃者にログイン済みの状態を使われるおそれがあります。この記事では、何が起きるのか、どこを狙うのか、どう備えるのかを順に見ます。

AiTM攻撃とは？

AiTM攻撃は、攻撃者が利用者と正規サイトの間に入り、ログインの流れを中継しながらセッションを盗む攻撃です。MITMが通信の盗み見や書き換えまで含む広い言い方なのに対し、近年AiTMと呼ばれる手口は、偽のサイトでログインを中継し、認証後のセッションを取る点に重きがあります。

AiTM攻撃で起きること

• 利用者は本物そっくりの偽サイトに誘導され、IDとパスワードを入れる
• 偽サイトが入力内容を正規サイトへそのまま流し、正規サイト側でログインが進む
• 利用者がMFAの確認を通すと、正規サイトはセッションを張る
• 攻撃者はセッションCookieや認証トークンを手に入れ、なりすましに使う

AiTM攻撃の流れ

代表的な流れは次の通りです。

1. 攻撃者は、正規サイトに似せたフィッシングサイトを用意します。
2. 利用者は、その偽サイトへアクセスし、ログインに使う情報を入れます。
3. 偽サイトは、その内容を正規サイトへ流します。
4. 正規サイトは、MFAの確認を始めます。
5. 利用者は、SMSなどで受け取った確認コードを偽サイトへ入れます。
6. 偽サイトは、そのコードを正規サイトへ流し、ログインを通します。
7. 正規サイトは、ログイン済みのセッションを始め、Cookieやトークンを出します。
8. 偽サイトは、そのCookieやトークンを取ります。
9. 攻撃者は、取ったCookieやトークンで、利用者としてログイン済みの状態を再現します。

このように、AiTM攻撃ではMFAそのものが破られたように見えますが、実際に取られているのは、利用者が正規サイトで通した認証の結果としてできたセッションです。

AiTM攻撃が狙うもの

AiTM攻撃で主に狙われるのは次の内容です。

• 利用者のログインIDとパスワード
• MFAで使うコードや承認
• 認証後のセッションCookieやトークン
• 利用者に関わる情報や、社外に出せない情報

特にセッションCookieやトークンを取られると、攻撃者は利用者のログイン済みの状態を使えるため、MFAをすり抜けたのに近い被害につながります。

AiTM攻撃が通りやすい場面

• SMSの確認コードなど、利用者が自分でコードを入れるMFAを使っている
• 正規ドメインに似たURLへ誘導されると、URL確認だけでは気付きにくい
• 認証後のセッションが長く残り、不自然な利用にすぐ止めが入らない
• 管理者アカウントに追加の守りが薄い

AiTM攻撃の手口

AiTM攻撃で狙われるのは、認証を通った後のログイン済みの状態です。ここでは、偽サイトへの誘導、認証の中継、セッションの持ち去り、なりすましの順で見ます。

偽サイトへの誘導

最初の段階では、攻撃者が正規サイトに似せたフィッシングサイトを用意します。見た目だけでなく、MFAを入れる画面や画面の移り方まで似せてくるため、表示だけで見分けるのは難しくなっています。

セッションCookieやトークンの持ち去り

利用者がMFAを通すと、正規サイトはセッションを張り、Cookieやトークンを出します。AiTMでは、それが利用者の端末へ渡る前後の流れで攻撃者側にも渡ってしまいます。結果として攻撃者は、ログイン済みの状態を自分の環境で使えるようになります。

なりすまし

攻撃者は取ったセッション情報で正規サイトへ入り直します。サイト側から見ると有効なセッションなので、利用者と同じ権限で操作されるおそれがあります。メールの転送設定の追加、クラウド上のデータ取得、MFAの設定変更など、あとから戻しにくい被害につながることもあります。

MFAを入れていても危ない理由

AiTMは、MFAそのものを破る攻撃ではありません。利用者が正規サイトで通した認証の流れを中継し、その結果としてできたセッションを取る手口です。そのため、MFAを入れていても、フィッシングに強い方式でなければ悪用される余地があります。

AiTM攻撃への対策

AiTM攻撃への備えは、誘導されにくくする対策と、取られた後に使わせにくくする対策を分けて考えると進めやすくなります。ここでは、認証方式、セッション管理、到達しにくくする対策、気付きと失効の順で見ます。

フィッシングに強い認証方式を使う

• FIDO2 / WebAuthnなど、フィッシングに強い方式を優先する
• 可能なら、管理者や重要業務から順に広げる

SMSやTOTPのように利用者がコードを入れる方式は導入しやすい半面、AiTMでは中継されやすい傾向があります。どこからFIDO2のようなフィッシングに強い方式へ切り替えるかが、実際の進め方で大きな差になります。

セッションを使い続けにくくする

• セッションの有効時間を短くする
• 大事な操作の前で再認証を求める
• 不自然な利用を見つけたらセッションを自動で失効させる
• 端末、場所、IPなどの条件で利用を見直す

AiTMではセッションそのものが取られるため、取られても長く使えない状態を作ることが大切です。

偽サイトへ行きにくくする

• URLフィルタリングやDNSの保護で不正サイトへ届きにくくする
• メール経由の誘導を想定し、SPF、DKIM、DMARCを整える
• 従業員向けの教育は、見分け方だけでなく迷ったときの報告手順まで含める

不正利用に早く気付いて止める

AiTM対策では、侵入を完全にゼロへ寄せることだけでなく、入られた後に早く止める考え方も要ります。

まとめ

AiTM攻撃は、フィッシングサイトでログインの流れを中継し、認証後のセッションCookieやトークンを取ってなりすます攻撃です。MFAを入れていても、フィッシングに強くない方式や、長く残るセッションでは被害につながるおそれがあります。備えとしては、フィッシングに強い認証方式を軸にしつつ、セッションを短く保つこと、不正サイトへ届きにくくすること、入られた後に早く気付いて止めることを組み合わせる必要があります。

よくある質問（FAQ）

Q. AiTM攻撃は中間者攻撃（MITM）と同じですか？

重なる部分はありますが、近年は偽サイトでログインを中継し、認証後のセッションを取る手口をAiTMと呼ぶことが多いです。

Q. MFAを入れていればAiTM攻撃は防げますか？

防げない場合があります。AiTMは認証後のセッションを取るためです。一方で、FIDO2やWebAuthnのようにフィッシングに強い方式は、この手口への耐性を高めます。

Q. SMSの確認コードは危険ですか？

一定の効果はありますが、AiTMでは中継されやすい方式です。重要なアカウントでは、フィッシングに強い方式を優先する方が安全です。

Q. セッションCookieを取られると何が起きますか？

攻撃者がログイン済みの状態を再現できるため、利用者と同じ権限で操作されるおそれがあります。

Q. フィッシングサイトはURLを見れば分かりますか？

URLだけで見分けるのが難しい場面は増えています。不正サイトへ届きにくくする対策と、迷ったときの報告手順を合わせて整える必要があります。

Q. 一番効きやすい対策は何ですか？

FIDO2やWebAuthnのように、フィッシングに強い認証方式を使うことが根本の対策として有効です。

Q. 端末や場所で利用を絞るのは有効ですか？

有効です。端末、場所、IP、利用者の条件で利用を見直すと、取られたセッションの悪用をしにくくできます。

Q. セッションの有効時間を短くすると使いにくくなりませんか？

なります。大事な操作だけ再認証を求めるなど、業務への影響と危険のつり合いを取りながら決める必要があります。

Q. AiTM攻撃は見つけられますか？

可能です。ログイン直後の不自然な動きや、端末や地域の食い違いを見て、セッション失効につなげます。

Q. 事故が起きたときに最初にやることは何ですか？

該当アカウントのセッション失効、パスワード変更、不正な設定の確認を優先します。あわせて、MFAの設定が書き換えられていないかを確かめ、影響がどこまで広がったかをログで追います。