PonyNet（AS53667）からのパスワードスプレー攻撃対策｜Entra ID（Azure AD）とAzure Resource Managerを守る実務手順

PonyNet（AS53667）配下の複数IPから、Azure Resource Manager（ARM）を狙った大量のサインイン試行が継続し、「条件付きアクセスを入れてもノイズが止まらない」「ASN単位でMicrosoftが止めてくれないのか」と悩むケースがあります。本記事では、Microsoft側の“できる／できない”を整理しつつ、MSRCへの通報、上流へのエスカレーション、そして自社テナントで現実的に効果が出る多層防御の作り方を具体的にまとめます。

PonyNet（AS53667）からのサインイン試行が続くときに起きていること

AzureポータルやARM（Azure Resource Manager）へのサインインログで、特定のASN（ここではAS53667）に属するIPから、短時間に大量の失敗ログが積み上がる場合、典型的にはパスワードスプレー攻撃が疑われます。

• 対象：一般ユーザーだけでなく、グローバル管理者や特権ロール、古い運用で残った休眠アカウント
• 狙い：アカウント侵害（成功したらAzure管理権限奪取、横展開、データ窃取、ランサム前段など）
• 特徴：1アカウントを総当たりするのではなく、多数アカウントに少数パスワードを薄く試すため、単純なロックアウトだけでは止めにくい

ここで重要なのは、攻撃が「あなたの社内ネットワーク」を経由しているのではなく、Microsoft Entra ID（旧Azure AD）というクラウド認証基盤に直接飛んでいる点です。つまり、社内FWで弾いても、ARMのサインイン試行自体は止まりません（ログは出続けます）。止めるには、認証・アクセス制御の設計を“突破されない状態”へ寄せるのが現実的です。

パスワードスプレー攻撃とは（混同されがちな攻撃との違い）

「何が起きているのか」を社内説明・稟議に通すためにも、用語を整理しておくとスムーズです。

攻撃種別	試行の仕方	ログ上の見え方	主な対策の方向性
パスワードスプレー	多数アカウント × 少数パスワード	1IP/複数IPから多数ユーザーへ失敗、ロックアウトが発動しにくい	MFA/パスワードレス、リスクベース制御、レガシー認証遮断、監視と自動封じ込め
ブルートフォース（総当たり）	少数アカウント × 多数パスワード	特定ユーザーへの失敗が集中、ロックアウトが効きやすい	ロックアウト強化、強固なパスワード、MFA
クレデンシャルスタッフィング	漏えいID/パスをそのまま多数サイトで試す	成功が混じることがある、IP分散しがち	MFA、漏えい検知、パスワードレス、異常サインイン検知

ARMがターゲットの場合、成功時のインパクトが大きい（リソース操作・権限奪取に直結）ため、「失敗が大量＝放置してよい」ではない点に注意が必要です。攻撃者は失敗ログを積み上げながら、どこかの弱い穴（MFA未設定、レガシー認証、例外ポリシー、古い管理者アカウント）を探します。

「MicrosoftにAS53667を丸ごとブロックしてほしい」が通りにくい理由

結論から言うと、特定ASN（AS53667など）をEntra ID側で“丸ごと一括ブロックしてほしい”という要望は、基本的に実現しにくいのが現実です。理由は次の通りです。

• 巻き添え（誤ブロック）リスク：同一ASNの中に正当な利用者・企業・クラウド・VPN出口が混在する可能性がある
• テナント個別要望でのグローバル遮断は難しい：Microsoftは全世界の共通基盤を運用しており、特定顧客の事情でインフラ全体を変えるのはハードルが高い
• 攻撃者はすぐにIP/ASNを変える：ASN単位の遮断だけに依存すると、迂回されて終わる
• “止める”より“突破されない”の設計が優先：ID基盤は、攻撃トラフィックが一定量ある前提で防御を組む思想になりがち

一方で、Microsoft側が何もしないわけではありません。大規模な脅威インテリジェンスや検知・緩和の仕組みは存在します。ただし、それを「このASNを今すぐ全部止めて」とピンポイント指定で動かすのは期待しにくい、という整理が重要です。

観点	期待できること	期待しにくいこと
Microsoft側（共通基盤）	脅威インテリジェンスへの反映、検知精度向上、既知の悪性IPの緩和	顧客要望のみでASN全体を恒久的に遮断、個別テナント専用のグローバル遮断
テナント側（自衛）	条件付きアクセス、MFA/パスワードレス、リスクベース制御、監視・自動化	ログ自体をゼロにする（攻撃試行の発生源を世界から消す）

まず最初にやるべき一次対応（被害の芽を潰す）

「ログがうるさい」以前に、成功されない状態を最優先で作ります。特にARM狙いの場合、管理系アカウントのガードが最重要です。

サインインログで“成功が混じっていないか”を確認する

失敗が多数でも、1件の成功が致命傷になり得ます。以下を優先的に確認してください。

• 対象アプリ：Azure Resource Manager（必要に応じて Azure Portal / Microsoft Graph / Office 365 なども）
• 成功（Result = Success）や、MFA要求後の失敗（MFA拒否/タイムアウト）の有無
• 同一ユーザーへの試行が続くか、ユーザーが広く散っているか（スプレーの典型）
• 特権ロール（管理者）に試行が入っていないか

緊急の“穴塞ぎ”チェックリスト

優先度	対策	目的	現場のポイント
最優先	管理者・特権ロールに強制MFA（可能ならフィッシング耐性）	パスワード突破だけで侵害できない状態にする	Push通知だけに頼らず、可能ならFIDO2/証明書/WHfB等を検討
最優先	レガシー認証の遮断	MFAが効きにくい経路を閉じる	IMAP/POP/SMTP AUTHなど例外運用が残りがち
高	スマート ロックアウト（挙動の確認・しきい値方針）	連続失敗の抑止	スプレーは回避してくるため、他対策と必ず併用
高	Identity Protection（サインインリスク/ユーザーリスク）	怪しいサインインの自動ブロック/MFA強制	運用ルール（例外申請、解除手順）を先に決める
中	不要アカウントの無効化、休眠・退職者棚卸し	当たりやすい的を減らす	スプレーは“弱いアカウント”探し。棚卸しは効果が出やすい

Microsoftへの報告・エスカレーションの現実解（MSRC＋サポートを使い分ける）

Abuse窓口（電話・メール）が実質機能していない場合でも、やるべき報告はあります。目的は「今すぐASN遮断してもらう」よりも、脅威情報を正規ルートに乗せ、継続的な検知・緩和の材料にすることです。

MSRC（Microsoft Security Response Center）へ報告する

MSRCは、Microsoft製品・サービスに関するセキュリティ問題の受付窓口です。パスワードスプレー自体は“インシデント”として扱われることが多く、必ずしも個別対応を約束するものではありませんが、観測情報をMicrosoft側の脅威インテリジェンスへ反映してもらう狙いがあります。

報告フォームは msrc.microsoft.com/create-report です（ブラウザで検索して開けます）。送付情報は「相手が動ける粒度」に揃えるのがコツです。

項目	入れるべき内容	理由
攻撃元情報	IPアドレス一覧、ASN（AS53667）、AS組織名（PonyNet等）	相関・解析に必要
観測期間	開始日時〜現在、タイムゾーン（UTC推奨）	トレンド把握、再現性の確認
対象	対象アプリ（Azure Resource Manager）、対象テナント種別、対象ユーザー傾向	影響範囲・再現性の判断
ログ	サインインログ抜粋（失敗理由、クライアントアプリ、ユーザー名のパターン等）	攻撃パターン特定と検知改善
対策状況	条件付きアクセス、MFA、レガシー認証遮断の有無	攻撃がどこを突いているかの判断材料

Azureポータルからサポートチケットを起票する

Microsoftサポートが「こちらでは対応できない」と返す背景には、“個別顧客の要望で全世界の認証エッジを変える”という対応ができないという事情があり得ます。ただし、サポートチケットを起票しておく価値はあります。

• 社内監査・説明のために「公式ルートへ報告した証跡」を残せる
• MSRC報告と合わせて、社内のエスカレーション材料になる
• サポート担当が、該当チームへ情報共有する導線になる場合がある

ポイントは「ASNブロック要求」だけで終わらせず、観測ログ・影響・ビジネスリスク・既存対策・追加で欲しい助言までセットで伝えることです。例：

• 影響：ARMへのサインイン試行が継続、アカウントロック/ヘルプデスク増加、監視アラート逼迫
• リスク：管理者侵害リスク、運用影響（管理作業の遅延）
• 依頼：Microsoft側で既知の悪性として扱われているか、推奨設定、追加で有効な制御（リスクポリシー等）の確認

上流トランジット事業者・関連組織への通報（任意だが効くことがある）

PonyNet側のAbuse窓口が機能していない場合、ネットワークの“上流”に通報するという実務手もあります。BGP上の上流回線事業者（トランジット）により、悪質なトラフィックへの是正が進む可能性があります。ただし、必ず動くとは限りません。

• WHOIS/BGP情報から、上流AS（トランジット）を特定して通報する
• 通報内容はMSRCと同様に、IP・日時・ログ・影響を含める
• 感情論ではなく、客観ログを添付する（“このIPがいつ何回、どのサービスへ”）

また、レジストリ情報（ARIN WHOIS）のAbuse窓口が実質機能していない場合、WHOIS情報の不備としてレジストリへ問題提起する道もあります。ただし、これは「攻撃を止める」よりも「連絡先の正当性を是正する」意味合いが強い点は理解しておきましょう。

報告先	狙い	期待できる成果	注意点
MSRC	Microsoftの脅威情報へ反映	検知・緩和の改善に寄与	個別ASN遮断の約束ではない
Azureサポート	正式なケース記録、助言獲得	内部連携の導線、説明責任	“できないこと”も明確にされる
上流トランジット	ネットワーク是正の働きかけ	是正・フィルタが入る可能性	対応は事業者次第、時間がかかることも
レジストリ（WHOIS）	Abuse窓口の不備の是正	連絡性改善の可能性	攻撃停止に直結しない

テナント側でできる“現実的に効く”多層防御（Entra ID編）

ASN一括遮断が期待しにくい以上、勝ち筋は多層防御です。ここでは「パスワードが当たっても突破できない」「怪しい動きを早期に遮断する」「運用で回る」ことをゴールに設計します。

MFAは“全員”へ、特に管理者は“強いMFA”へ

パスワードスプレーの本質は「パスワードしか守っていないアカウント」を探すことです。従って、MFA（多要素認証）を徹底するだけで、攻撃の費用対効果は大きく下がります。

• 管理者・特権ロール：必須。可能ならフィッシング耐性（FIDO2、証明書、Windows Hello for Business等）を検討
• 一般ユーザー：業務影響が許す範囲で段階的に全員へ
• 例外：例外は必ず“期限付き・理由付き・監査ログあり”にする

加えて、ARM（Azure Resource Manager）を操作できるユーザーは、たとえ一般ユーザーでも影響が大きいので、優先度高で強化します。

レガシー認証を遮断する（抜け道を閉じる）

パスワードスプレーで怖いのは、「本来MFAで止まるはずが、古い認証経路で迂回される」ことです。環境に残りがちな例：

• 古いメールクライアントが使うIMAP/POP/SMTP AUTH
• 古いOfficeクライアント、古いサードパーティアプリ

条件付きアクセスやテナント設定で、レガシー認証は可能な限り遮断し、例外が必要なら最小範囲・最短期間で運用します。

Identity Protection（リスクベース制御）で“怪しいサインイン”を自動で止める

攻撃者はIPを変え、地域を変え、端末指紋も変えます。そこで効くのが、サインインのリスクを評価してブロックやMFAを強制する設計です。

• サインインリスクが高い場合：ブロック、またはMFA必須
• ユーザーリスクが高い場合：パスワード変更を強制

実運用で詰まりやすいのは例外処理です。運用ルール（解除申請、一次対応、本人確認）を先に決め、ヘルプデスクと合意してから有効化すると、現場が回ります。

条件付きアクセスで“Azure管理”を守る（ARM/ポータルの防御）

ARM狙いの攻撃では、Azure管理操作に到達させないのが要点です。おすすめの方向性は次の組み合わせです。

• Azure管理操作は、準拠デバイス（Intune等）または特定端末（PAW）からのみ許可
• 管理者のサインインは特定のネットワーク（オフィス/VPN出口）に制限
• 不審な国・地域、匿名プロキシなどはブロック（業務要件に合わせて）

「ASNで指定できない」問題は、条件付きアクセス側で“IPレンジとしてNamed locationに登録してブロック”という形で回避できます。つまり、AS53667に属するIPレンジを収集し、Named locationに登録して“ブロック”します。

ただし重要な注意点があります。

• 攻撃者はIPを変えるため、IPレンジのメンテナンスが必要
• 誤ブロックの可能性があるため、いきなり全体ブロックではなく、観測ログに基づき段階導入が現実的
• ARMのサインイン試行自体は発生し得るため、ログは「ブロックされた試行」として残る

ネットワーク側のIP/ASNブロックが効く領域と効かない領域（誤解ポイント）

ここは現場で混乱しやすいポイントです。Azure Firewall/WAFで弾けば全部止まる、と思いがちですが、Entra IDのサインイン（ARM含む）には直結しないケースが多いです。

対象	どこに攻撃が飛ぶか	Azure Firewall / WAFでの遮断	有効な主戦場
ARM/ポータルへのサインイン	Microsoftの認証基盤（Entra ID）	基本的に止まらない（自社ネットワークを通らない）	条件付きアクセス、MFA、Identity Protection、監視
自社Webアプリへの攻撃	Application Gateway/WAF、Webサーバ	止められる	WAFカスタムルール、IPブロック、Bot対策
API/管理エンドポイント（自社管理）	自社の公開IP	止められる	Azure Firewall、NSG、IP allowlist

つまり、今回のように「Azure Resource Managerへのサインイン試行」が主問題なら、ネットワーク機器だけで解決しようとするより、Entra ID側の制御と監視・自動化を中心に組み立てるのが近道です。

Microsoft Sentinelで“検知→自動封じ込め”を回す（運用品質を上げる）

同じ攻撃が何週間も続くと、手作業対応は破綻します。そこで、Microsoft Sentinel（または同等SIEM）で、サインインログを使った検知と自動化を組み込みます。

まずはログを“分析できる形”にする

• Entra IDのサインインログをLog Analyticsへ送る（Sentinelを有効化）
• 運用者が見たい軸（ユーザー、IP、ASN、アプリ、失敗理由、国/地域）で追えるようにする
• ログ保持期間・監査要件に合わせて、長期保管も検討する

AS53667を軸にしたKQL例（観測・状況把握）

環境によりフィールド名が異なる場合がありますが、概念としては次のように「ASNで絞って、失敗数・ユーザー数・IP数」を可視化します。

SigninLogs
| where TimeGenerated > ago(24h)
| where AutonomousSystemNumber == 53667
| where AppDisplayName == "Azure Resource Manager"
| summarize
    Attempts = count(),
    Users = dcount(UserPrincipalName),
    IPs = dcount(IPAddress)
  by bin(TimeGenerated, 1h)
| order by TimeGenerated asc

「パスワードスプレーっぽさ」を掴むには、短時間に多数ユーザーへ失敗が広がるパターンを見るのが有効です。

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| summarize
    Failed = count(),
    Users = dcount(UserPrincipalName)
  by IPAddress, bin(TimeGenerated, 5m)
| where Users >= 10 and Failed >= 50
| order by Failed desc

アラート設計のコツ（誤検知を減らす）

• 「失敗回数」だけでなく「対象ユーザー数（dcount）」も条件に入れる（スプレー特徴）
• 社内プロキシ/VPN出口など“正当な集中IP”は除外する
• AppDisplayName（ARMなど）を入れて、重要な面に絞る
• 攻撃が多い時間帯を前提に、しきい値は段階的に調整する

自動封じ込め（Playbook/Logic Apps）の方向性

「ASNを止めたい」という要望を“運用で実現”するなら、次のような形が現実的です。

• 検知したIPを、Azure FirewallのIPグループやWAFのカスタムルールへ自動追加（自社アプリが狙われる場合に有効）
• 管理者向けの監視を強化し、特権ロールが狙われたら即時に通知・強制リセット・一時停止などの運用フローへ
• 短期間で大量試行が出たIPは、一定期間だけブロックして自動解除（運用負荷と誤ブロックのバランス）

ARMのサインインそのものをFWで止めるのは難しい一方、“成功されない状態”＋“異常の早期検知”＋“運用自動化”に寄せると、実被害の確率と運用コストを同時に下げられます。

AS53667のIPレンジ収集とブロック運用を“破綻させない”ための考え方

ASN単位でのブロック要望が強い場合、現場では「ASN→IPレンジ」の変換をして運用することになります。しかし、ここには落とし穴があります。

• ASN配下のプレフィックスは変動し得る（増減・移動・委譲）
• すべてを遮断すると誤ブロックが起きる可能性がある
• “ブロックリストの肥大化”が運用破綻を招く

そこでおすすめは、いきなり全遮断ではなく、次の運用に寄せることです。

段階	やること	狙い	実務のポイント
観測	サインインログでAS53667の試行パターンを把握	本当にスプレーか、成功がないかを確認	ARM以外も見て「別経路で成功」していないか確認
抑止	MFA/レガシー遮断/リスクポリシーを強化	突破率をゼロに寄せる	特権ロールから着手し、例外は期限付き
限定ブロック	観測されたIP/レンジをNamed location等でブロック	ノイズ・試行を減らす	誤ブロックが出ない範囲から始める
自動化	Sentinelで検知→ブロック更新	運用負荷を下げる	自動解除・承認フローを用意して暴走を防ぐ

「Abuse窓口が機能していない」状況で、報告を通すためのログ添付テンプレート

MSRCやサポート、上流事業者への通報は、情報の粒度で結果が変わります。次のテンプレートを使うと、担当者に伝わりやすくなります。

本文テンプレ（そのまま貼れる形）

件名：AS53667（PonyNet）配下IPからの継続的なパスワードスプレー攻撃（Azure Resource Manager）

概要：
当組織のMicrosoft Entra IDテナントに対し、AS53667配下の複数IPからAzure Resource Managerを対象としたサインイン試行（失敗）が継続して発生しています。
攻撃は多数アカウントに対し少数パスワードを試行する挙動で、パスワードスプレーと判断しています。

観測期間（UTC）：
YYYY-MM-DD HH:MM ～ 現在

対象：
AppDisplayName: Azure Resource Manager
（必要に応じて：Azure Portal / Microsoft Graph など）

攻撃元：
ASN: 53667
AS組織名：PonyNet（WHOIS/BGP上の表記）
攻撃元IP（例）：x.x.x.x, y.y.y.y, ...

ログ抜粋：
・失敗理由（Failure Reason）：
・クライアントアプリ：
・ユーザー名パターン：
・試行回数（期間内合計）：
・成功の有無：

当方の対策状況：
・MFA：管理者は必須、一般ユーザーは段階導入中
・条件付きアクセス：適用中（Named location等）
・レガシー認証：遮断（例外なし/例外あり）
・Identity Protection：有効/導入検討中

依頼事項：
貴社側での既知の悪性トラフィックとしての取り扱い状況の確認、推奨される追加対策、必要な追加情報をご教示ください。

このテンプレをベースに、「攻撃の客観ログ」「期間」「対象アプリ」「対策状況」「依頼事項」を揃えると、受け手が次アクションを取りやすくなります。

よくある疑問（現場で詰まるポイント）

ASNブロックができないなら、条件付きアクセスは意味がない？

意味はあります。ASNを直接指定できなくても、IPレンジブロックや、準拠デバイス制限、特定ネットワーク制限、リスクベース制御など、“突破させない設計”を組めます。ログのノイズが残っても、成功率を極小化できればリスクは大幅に下がります。

ブロックしてもサインイン試行ログが出続けるのは正常？

正常です。攻撃者が試行している限り、ブロックの判定が走った記録としてログが残ることがあります。「ログをゼロにする」のは難しいため、成功ゼロを維持し、異常を検知して運用を回すのが現実解です。

管理者だけは特にどう守るべき？

• 日常業務アカウントと管理者アカウントを分離
• 管理操作は専用端末（PAW）や準拠デバイスに限定
• 強いMFA（可能ならフィッシング耐性）を必須化
• 特権は常時付与せず、必要時に昇格（PIM等）
• 管理者アカウントへのスプレー兆候は即時アラート

Abuse窓口が機能していない場合、どこにエスカレーションすべき？

実務上は、MSRC＋Azureサポートの二本立てが基本です。加えて、上流トランジットへの通報が通る場合があります。いずれも「ログ添付」と「客観情報」が重要です。

まとめ：PonyNet（AS53667）由来のスプレーは“多層防御＋継続報告”で勝つ

• Microsoftに「ASN全体の一括ブロック」を期待しすぎない（巻き添え・運用思想の壁がある）
• 報告ルートはMSRCとAzureサポートチケットを中心に、必要に応じて上流へ
• テナント側では、MFA（特に管理者）／レガシー認証遮断／リスクベース制御／条件付きアクセスで突破を防ぐ
• 運用を破綻させないために、Sentinelで検知→自動化を組み込む
• 「ログをゼロにする」より「成功ゼロを維持し、異常を即時に封じ込める」設計が現実的