はじめに
2026年8月9日、当サイトでは、.envや.git/config、設定ファイル、クラウド認証情報を連想させるパス、複数のWebフレームワーク固有の管理・診断URLなどを連続して探索する大量アクセスを観測しました。
結論から言うと、今回の挙動はDDoSを主目的とした攻撃というより、秘密情報や管理エンドポイントを探す自動化されたActive Scanning、特にWordlist Scanningである可能性が高いと判断しています。
MITRE ATT&CKでは、一般的なファイル名・ディレクトリ名や製品固有の名称を一覧化し、存在するWebコンテンツを探索する行為を「T1595.003 Wordlist Scanning」と分類しています。
当サイトではApplication側で拒否していましたが、攻撃リクエスト自体は前段を通過していました。そのため最終的にCloudflare側で送信元をEdge Blockし、Cloudflareでは攻撃要求が続いている一方、Origin側への該当探索アクセスが止まったことを確認しました。
この記事では、今回の攻撃が何に見えるのか、どう確認したのか、どのように封じ込めたのか、情報漏えいや侵入の有無をどのように調査するべきかを整理します。
なお、公開記事のため、攻撃元IP、内部システムの判定条件、検知閾値、内部API、未修正の防御ロジックなど、攻撃回避に利用される可能性がある情報は掲載していません。
結論・要点
この記事の要点
- 今回の攻撃は秘密情報・設定ファイル・管理URLを探索するWordlist Scanningである可能性が高い。
-
.envや.git/configへのアクセスだけでは情報漏えい成功を意味せず、実際のHTTPレスポンスを確認する必要がある。 - 複数フレームワーク向けURLが短時間に連続する場合、対象技術を把握した攻撃より汎用自動スキャナの可能性が高まる。
- Application側のHTTP 403と、Originへ到達する前のEdge Blockは防御位置が異なる。
- CloudflareではSecurity AnalyticsとEventsの意味が異なり、EdgeでBlockされた通信も分析画面には現れる。
- Security Eventsはサンプリングされる場合があるため、「表示0件」と「通信0件」は同義ではない。
- ログのイベント生成時刻と、実際のHTTPアクセス時刻は必ずしも一致しない。
- 秘密情報の露出が確認された場合は、該当Credentialを失効・ローテーションし、不正利用の有無を調査する。
- 単一IPの悪性判定だけを根拠にCIDRやASN全体へ遮断範囲を広げるべきではない。
- 防御後は「攻撃者がアクセスをやめたか」ではなく「Originへ到達しなくなったか」で確認することが重要である。
この記事で分かること
この記事では、「大量の.envアクセスを見つけたが、これは何なのか」という疑問から始め、攻撃分類、危険性、ログの確認方法、Cloudflareなどによる封じ込め、情報漏えい確認、Credential対応、EDRを含めた事後調査まで説明します。
内部IPSそのものの改修設計については、公開記事とは分離して管理しています。
対象読者・前提環境
対象は、インターネットへWebサイトやAPIを公開している運用者です。
特に、CloudflareなどのReverse Proxy/WAF、Nginx、Apache、Django、Laravel、Spring Bootなどを利用している環境を想定しています。
今回の考え方自体は特定製品に限定されません。
用語と全体像
Wordlist Scanningとは
簡単に言えば、
「ありそうな隠しファイル名や管理URLを名簿にして、片っ端から試す偵察」
です。
例えば攻撃者は、次のような名前が存在するかを機械的に確認します。
/.env /.git/config /config.yaml /secrets.yml /actuator/env
MITRE ATT&CKではWordlist ScanningをT1595.003として分類しています。
目的はパスワードそのものを総当たりすることではなく、後続の攻撃に利用できるWebコンテンツ、管理画面、古いページ、設定情報などを発見することです。
今回何が起きたのか
今回のアクセスでは、特定の技術だけではなく、複数のWeb技術を想定したパスが短時間に連続していました。
例えば、
環境変数ファイル Git関連ファイル YAML設定ファイル クラウド認証情報を連想させるファイル Java系管理エンドポイント PHP系診断エンドポイント .NET系診断エンドポイント
といった種類です。
この挙動から、
「このサイトはDjangoだからDjangoだけ攻撃しよう」
という詳細な事前調査より、
Django? Laravel? Spring? .NET? クラウド設定? .env? Git? → 全部試す
という汎用スキャナの挙動に近いと判断しました。
CISAでも.env探索を伴う実攻撃が報告されている
.env探索そのものは珍しいものではありません。
CISAとFBIが公開したAndroxgh0stに関する共同勧告でも、/.env、/.git/config、AWS関連Credential、各種設定ファイルなどを探索するアクセスが実際の攻撃活動として報告されています。CISAは、.envに保存されていたCredentialを利用する不正アクセスについても注意を呼び掛けています。
ただし重要なのは、
今回の攻撃＝Androxgh0st
とは断定できないことです。
同じ探索手法は複数のScanner、Bot、攻撃Campaignで利用できます。
今回確認できるのはTTPが類似していることまでです。
なぜ.envや設定ファイルが狙われるのか
Web公開領域へ本来公開する必要のないファイルが置かれていると、
DB接続情報 API Key Cloud Credential SMTP Credential 内部ホスト名 デバッグ設定 ファイルパス 管理機能の情報
などが漏れる可能性があります。
OWASP Web Security Testing Guideでも、古いファイル、Backup、参照されていない設定ファイルなどがWebから取得できると、Credentialや内部構成などの機密情報が漏れる可能性があると説明されています。
そのため攻撃者にとっては、
「とりあえず有名な名前を試して、200が返ったら詳しく調べる」
という方法が効率的です。
自分のサイトにも関係するか
インターネットへ公開しているWebサイトなら関係があります。
重要なのは、
/.env にアクセスされた
という事実ではありません。
確認すべきなのは、
/.env に対して何を返したか
です。
例えば、
404 Not Found
または、
403 Forbidden
なら、少なくともそのリクエストからファイル本文を取得できたとは考えにくくなります。
一方、
200 OK
で実際の設定内容を返していた場合は、情報漏えいインシデントとして扱う必要があります。
DDoS攻撃ではないのか
今回の中心的な挙動は、サービス停止より情報探索に見えます。
MITREではActive Scanningを、攻撃対象のInfrastructureへ直接Probeを送り、その後の攻撃に利用できる情報を集めるReconnaissance活動として整理しています。
また、製品固有の管理URLや診断URLを探す行為にはVulnerability Scanningの要素が含まれる場合があります。MITREのT1595.002は、対象ApplicationのSoftwareやConfigurationが悪用可能な条件と一致するか調査する行為をVulnerability Scanningとして整理しています。
もちろん、大量Scannerが結果的にサーバ負荷を発生させることはあります。
しかし、
負荷が発生した
＝ DDoSが主目的
とは限りません。
最初はApplication側で拒否していた
今回、攻撃リクエストの一部はApplication側で拒否されていました。
イメージすると、
Internet | v Cloudflare | v Origin | v Web Server / Application | +--> 403
です。
403を返せているので、Applicationとしては要求を拒否しています。
しかし、Originまでは通信が届いています。
そのため、
TLS処理 Web Server処理 ログ記録 Application判定
などの負荷は発生します。
対応：遮断位置をEdge側へ移した
今回の対応では、悪性と判断した送信元についてCloudflare側で個別にBlockしました。
ここで重要なのは、
必要以上に遮断範囲を広げなかったこと
です。
単一IPについてEvidenceが揃っていても、同じネットワーク全体が悪性とは限りません。
そのため今回は、根拠なく、
/24全体 ASN全体 広範囲のIPv6 prefix
へ遮断を拡大していません。
Cloudflareで本当にBlockされたか確認する
Cloudflareでは現在、Security関連の分析画面としてTrafficとEventsを利用できます。
Cloudflare公式では、Trafficは受信HTTPトラフィック全体の分析、EventsはSecurity製品によってActionまたはFlagされたイベントの確認という役割に分かれています。
今回の確認ではEvents上で、
Action Block Service Custom Rules
となっているイベントを確認しました。
その後、Origin側で同じ探索アクセスが新しく観測されなくなったことも確認しています。
したがって、
攻撃者 | | アクセスは継続 v Cloudflare | +--> Block X | Origin
という状態へ移行できたと判断しました。
Cloudflareに攻撃アクセスが残って見えるのは正常
ここは今回かなり混乱しやすかった部分です。
CloudflareでBlockしていても、Traffic側では攻撃リクエストを見ることがあります。
理由は単純です。
攻撃者 | v Cloudflare ← ここまでは到着 | X Block | Origin
だからです。
Cloudflareへ到着したことと、Originへ転送されたことは別です。
Cloudflare公式も、Security Analyticsでは受信トラフィック全体を分析し、EventsではSecurity製品によって処理されたリクエストを確認するという役割分担を示しています。
「データなし」でも攻撃0件とは限らない
Cloudflare Eventsでは、大量トラフィック時にSampled logsが利用される場合があります。
Cloudflare公式も、Samplingによってすべての個別イベントが表示されるわけではなく、Filter結果やPaginationが期待どおりにならない場合があると説明しています。
したがって、
検索結果 0件
だけで、
実通信 0件
とは判断しません。
今回の調査でも、広い時間範囲では確認できたイベントが、狭い範囲へ絞り込むとSampled logs上から見えなくなるケースがありました。
セキュリティ監視では非常に重要な注意点です。
ログの「検知時刻」にも注意する
今回もう一つ重要だったのが、監視システム上のイベント時刻と実際のHTTPアクセス時刻が必ずしも同じではないことです。
例えば、
実HTTPアクセス ↓ ログ保存 ↓ 複数イベントを集計 ↓ セキュリティイベント生成
という監視システムでは、
実アクセス時刻
と、
集約イベント作成時刻
に差が出ます。
そのため、
セキュリティイベントが18:00に生成された
＝ 18:00にそのHTTPリクエストがOriginへ到達した
とは限りません。
今回の調査でも、後から生成された集約イベントをRaw HTTPアクセスと混同すると、Edge Block後も攻撃がOriginへ届き続けているように誤認する可能性があることを確認しました。
公開記事では内部の集約条件や判定ロジックは掲載しませんが、「生ログ」と「分析結果のイベント」は分けて考える必要があります。
確認方法1：機密ファイルが公開されていないか
目的
.envなどがインターネットから取得可能になっていないか確認します。
実行場所
自分が管理するサイトに対して、外部の検証端末から実行します。
他人のサイトには実施しないでください。
コマンド
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/.env
正常例
404
または、
403
異常例
200
判断方法
200の場合は、実際に秘密情報を返していないか安全な方法で確認し、公開されている場合は直ちに公開停止とCredential調査へ移ります。
OWASPも、設定ファイルやBackupなどをWebアクセス可能領域へ置くことで機密情報が漏れる危険性を指摘しています。
確認方法2：Git関連ファイルが公開されていないか
目的
.git配下が外部から取得可能でないことを確認します。
実行場所
自分が管理するサイトへ外部検証端末から実行します。
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/.git/config
正常例
403
または、
404
異常例
200
200の場合は公開設定を修正し、Repository informationや過去の秘密情報が外部から取得可能ではなかったか追加調査します。
CISAのAndroxgh0st勧告でも、/.git/configは実際に観測された探索URIの一つとして掲載されています。
対処方法
今回のようなScannerへの対応は、単にIPを一つBANして終わりではありません。
| 防御層 | 役割 |
|---|---|
| Edge/WAF | Originへ到達する前に明確な悪性通信を拒否 |
| Rate Limit | 高頻度な自動探索を抑制 |
| Web Server | 本来公開しないファイルを403/404にする |
| Application | 認証・認可・入力検証 |
| IPS/IDS | 複数アクセスを相関しScannerとして検知 |
| EDR | 侵害後のProcess・File・Network異常を検知 |
| SIEM/XDR | 複数Evidenceを一つのIncidentとして調査 |
MITREのWordlist Scanning Detection Strategyでも、単一送信元などから発生する大量の疑わしいNetwork Trafficを監視することがDetectionの基本として挙げられています。
.envが200だった場合の対応
もし秘密情報を含むファイルが外部から取得可能だった場合は、単なるScanner対応ではなく情報漏えいの可能性があるIncidentとして扱います。
確認対象は例えば次です。
| 種類 | 対応 |
|---|---|
| Database Credential | Password変更、不正接続確認 |
| Cloud Credential | Key失効・Rotation、Cloud Audit確認 |
| SMTP Credential | Rotation、不正送信確認 |
| API Token | 失効・再発行、利用履歴確認 |
| Application Secret | 影響評価後にRotation |
| OAuth Secret | Client Secret更新、Token利用状況確認 |
CISAも.envにCredentialが保存されていたサービスについて、不正アクセス・不正利用を確認することを推奨しています。
侵入成功の有無も別途確認する
WAFでScannerを止められたことと、
過去に侵入されていないこと
は同じではありません。
事後確認では、EDRやOS、Applicationのログから、不審なProcess、未知のService、Web rootの変更、異常なOutbound通信、管理ユーザー作成、認証異常などがないか確認します。
今回確認した範囲では、探索活動とBlockは確認していますが、今回のデータだけから侵入成功を示す事実は確認できません。
動作確認
対策後は「Block Ruleが存在する」だけでは不十分です。
理想的には、
攻撃要求 ↓ Edge側では継続観測 しかし Origin側 ↓ 新規到達なし
となることを確認します。
つまり、
攻撃者が攻撃をやめたか
ではなく、
自分が保護しているサーバへ攻撃を届けなくできたか
で評価します。
今回も、この方法でEdge側とOrigin側の観測を突き合わせました。
再発防止
再発防止で最も重要なのは、個別IPの永久BANリストを増やすことではありません。
.env、Git関連ファイル、Backup、設定ファイルなど本来外部へ公開する必要のないResourceを公開しないこと、WAFやRate Limitを利用して高頻度Scannerを早い段階で抑えること、Application・Web Server・EDRなど複数の防御層を重ねることが重要です。
MITREもWordlist ScanningのMitigationとして、外部公開する必要のないSystemやResourceへのアクセスを減らし、外部から得られる情報の量と機密性を最小化することを挙げています。
注意点・よくある誤解
「.envへアクセスされたので情報漏えいした」
アクセスされたことと取得成功は別です。
HTTP statusと実際のResponseを確認します。
「Cloudflare Analyticsに攻撃が見えるのでBlockできていない」
Cloudflareへ届いたリクエストはEdgeでBlockされても分析対象になり得ます。TrafficとEventsを使い分けます。
「Eventsが0件なので攻撃はなかった」
Samplingされている場合は断定できません。
「同じネットワークのIPは全部BANした方が安全」
誤遮断の危険があります。単一IPのEvidenceだけでCIDRやASN全体へ拡大しない方が安全です。
「このパスなら特定マルウェアだ」
URIだけで攻撃主体やMalwareを断定するのは危険です。今回もAndroxgh0stと共通するTTPはありますが、帰属は行っていません。
まとめ
今回観測したアクセスは、.envやGit関連ファイルだけでなく、複数のWeb技術やクラウド環境を想定したURLを短時間に連続して試していました。
そのため、
特定のWebフレームワークだけを狙った攻撃というより、秘密情報・設定ファイル・管理エンドポイントを探す自動化Wordlist Scanning
と考えるのが最も妥当です。MITRE ATT&CKではT1595.003に近い活動です。
今回の対応では、Application側の拒否だけでなくEdge側へ遮断位置を移し、Cloudflare EventsでBlockを確認したうえで、Origin側への該当探索アクセスが止まったことを確認しました。
そして調査で改めて重要だと分かったのは、
「攻撃が検知された時刻」と「実際にHTTPアクセスが到達した時刻」を混同しないこと
です。
攻撃を止めるだけではなく、何を観測し、どこで遮断し、本当にOriginへ届かなかったかまで確認することが、正確なIncident Responseにつながります。
FAQ
Q. 大量の.envアクセスを見つけたらすぐ緊急事態ですか？
探索自体はインターネット公開サイトで発生し得ます。まずHTTP 200で内容を返していないか確認してください。
Q. .envが404ならCredential変更は不要ですか？
今回の探索だけを理由に全Credentialを変更する必要性は低くなります。ただし過去に公開されていた可能性や別経路からの漏えいがある場合は別途調査が必要です。
Q. IPを永久BANすれば終わりですか？
攻撃元は変更できます。個別IP Blockだけでなく、Resource非公開化、WAF、Rate Limit、Application Security、EDRなど多層防御が重要です。
Q. CloudflareのBlock後もAnalyticsに送信元が出ています。
正常に起こり得ます。Cloudflareへ届いた後、Originへ転送する前にBlockされている可能性があります。EventsでActionを確認してください。
Q. Androxgh0stだったのですか？
確認できません。CISAが公開したTTPと類似する点はありますが、特定には追加Evidenceが必要です。
参考情報
CISA/FBI「Known Indicators of Compromise Associated with Androxgh0st Malware」では、.env、.git/configやCloud Credentialなどを狙う実際の探索TTPと対策が掲載されています。
コメント（0件）
まだコメントはありません。最初のコメントを投稿してください！