先だっての記事で、「IPアドレス直打ちやヘッダーがないアクセスはたたき落とす」という設定を紹介しました。では、そういう直打ち以外の「きちんとこちらのホスト名、ドメイン名を調べ、そしてリクエストヘッダーも指定した攻撃はどういうものになるのか?」の実例を、筆者が実際に受けたログから紹介します。
1. 検出されたログの抜粋
以下は、検知されたエラーログの要約です(連続して複数のルールに抵触したため、重要なものを抜粋・統合しています)。
今回も攻撃者のIPアドレスは残しません。「テロリストに名前を与えてはいけない」からです。
# 1. Unicode難読化とプロトタイプ汚染の検知
[Date/Time] [security2:error] [client 192.0.2.1] ModSecurity: Warning. Pattern match "(?i)\\\\x5cu[0-9a-f]{4}" at ARGS:0. [file "REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [id "920540"] [msg "Possible Unicode character bypass detected"] [data "ARGS:0={\x22value\x22:\x22{\x5c\x22then\x5c\x22: \x5c\x22$B0\x5c\x22}\x22,\x22then\x22:\x22$1:__proto__:then\x22, ..."] [hostname "example.com"]
# 2. リモートコード実行(RCE)の検知
[Date/Time] [security2:error] [client 192.0.2.1] ModSecurity: Warning. Pattern match ... at ARGS:0. [file "REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [id "932235"] [msg "Remote Command Execution: Unix Command Injection"] [data "Matched Data: eval)(global[\x5c\x22\x5c\x5cu0042... .from('KGFzeW5jIGZ1bmN0aW9uKCl7..."] [hostname "example.com"]
# 3. Node.js インジェクションおよびプロトタイプ汚染ルールの発火
[Date/Time] [security2:error] [client 192.0.2.1] ModSecurity: Warning. Pattern match ... [file "REQUEST-934-APPLICATION-ATTACK-GENERIC.conf"] [id "934100"] [msg "Node.js Injection Attack 1/2"]
[Date/Time] [security2:error] [client 192.0.2.1] ModSecurity: Warning. Pattern match "__proto__" at ARGS:0. [file "REQUEST-934-APPLICATION-ATTACK-GENERIC.conf"] [id "934130"] [msg "JavaScript Prototype Pollution"] [hostname "example.com"]
# 4. 異常スコア超過によるアクセス拒否(403)の実行
[Date/Time] [security2:error] [client 192.0.2.1] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:blocking_inbound_anomaly_score. [file "REQUEST-949-BLOCKING-EVALUATION.conf"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 65)"] [hostname "example.com"]
2. 攻撃の意図
この攻撃の主な意図は、
- サーバーの制御権の奪取(バックドアの設置)
- クラウド認証情報の窃取」 です。
ログに記録されたペイロード(ARGS:0)を解析すると、以下の3つのステップを実行しようとしていたことが分かります。
- プロトタイプ汚染 (Prototype Pollution):
- JavaScript特有のオブジェクト仕様である
__proto__やthenを悪用し、アプリケーション全体の挙動を書き換えようとしています。
- JavaScript特有のオブジェクト仕様である
- 難読化によるWAFの回避:
Bufferという文字列を\u0042\u0075\u0066...のようにUnicodeエスケープし、WAFの単純な文字列チェックをすり抜けようとしています。
- ペイロードの実行(RCE)
- 送信データ内には Base64 でエンコードされたスクリプト(
KGFzeW5j...)が含まれていました。これをデコードすると、// fast_recon_v6 — signature-rotated recon payload(自動偵察用スクリプト)というコメントが出現します。 - 攻撃が成功すると、サーバー内部で
eval()が実行され、AWSやGCPといったクラウド環境のメタデータ(IMDS)から認証情報を盗み出す、あるいは外部からコマンドを自由に入力できる状態(リモートコード実行)に陥る危険がありました。
- 送信データ内には Base64 でエンコードされたスクリプト(
3. 攻撃者の「技術スタック」
ログから推測される、この攻撃を仕掛けてきたボット(または攻撃者)の技術的な背景やツール群は以下の通りです。
- 言語・ターゲット環境:
- JavaScript / Node.js
- ターゲットを完全に Node.js(Express や Next.js などのWebフレームワーク)に絞り込んでいます。
- 使用ツール:
- 既知の脆弱性スキャンツール(自動化ボット)
- * ペイロード内のコメント(
fast_recon_v6)から、アンダーグラウンドやオープンソースで流通している、あるいは独自に開発された高度な自動脆弱性スキャン・バックドア設置ツールキットである可能性が高いです。
- インフラ(踏み台): クラウドサービス(Google Cloud など)
- * 接続元IPを調査すると大手のパブリッククラウドに割り当てられたIPであり、攻撃者は自身のアドレスを隠すため、クラウド上のVPSや乗っ取ったサーバーを踏み台にしてスキャンを実行しています。
4. 攻撃が成功してしまった場合のシーケンス(最悪のシナリオ)
もしWebアプリケーション側に脆弱性があり、WAFを導入していなかった場合、攻撃は以下のように進行します。
5. 今回の ModSecurity が阻止した実際の動き
実際には、ModSecurity(OWASP CRS)がリクエストの段階で脅威を検知し、アプリケーションにデータが届く前に処理を遮断しました。
6. そもそもの問題として
筆者のサイトにNode.jsは含まれていないというのがポイントです。筆者の技術スタックが
- LAMP
- もしくはRails
という枯れた技術だったのが幸いしていました。攻撃者は「Node.jsだと決めつけていた」のです。
自動スキャンは効率を重視します。相手が誰かではなく、「大量に存在する技術スタック」に対して決め打ちでペイロードを送りつけます。つまり、この攻撃は筆者個人を狙ったものではなく、「Node.jsで動いているなら当たれ」という散弾銃です。そして今回は、その散弾がたまたまLAMP環境に飛んできただけでした。
WAFはその誤射を淡々と403へ変え、ログだけを残しました。ログを読むということは、「何を防いだか」を知るだけではありません。攻撃者が世界をどう見ているかを知ることでもあるのです。
とはいえ、筆者がModSecurityで設定している
# 1-3. IPアドレス直打ちアクセス対策
SecRule REQUEST_HEADERS:Host "@rx ^[\d.]+(:\d+)?$" \
"id:10004,\
phase:1,\
deny,\
status:404,\
log,\
msg:'[CUSTOM RULE] Host header is a numeric IP address (incl port). Blocked immediately.',\
tag:'application-attack',\
tag:'PROTOCOL_VIOLATION/INVALID_HREQ'"
# Hostヘッダーが存在しない場合は即ブロック
SecRule &REQUEST_HEADERS:Host "@eq 0" \
"id:10005,\
phase:1,\
deny,\
status:404,\
log,\
msg:'[CUSTOM RULE] Missing Host Header. Blocked immediately.'"
を見事すり抜けました。つまり、きちんと筆者VPSのドメインを調べ、正しいHostヘッダーを付与してきたということです。この点については、攻撃者に敬意を表します。少なくとも、IPアドレス直打ちしかできないボットよりは、こちらを相手として認識していたのですから。そのおかげでWAF(ModSecurity)は仕事をし、評価を行い、その上でブロックしました。
この状況をたとえて言うならば『ジョジョの奇妙な冒険 戦闘潮流』の
まず、このワムウに殺される資格はあるッ!
といったところでしょうか。

















