初めに
今回はWordpress(Alma Linux)に対してWPScan(Kali Linux)をしそのログをSplunkで分析しました。経緯としては学校の授業でSplunkがあり、ログ分析とKali Linuxに興味があったので自身でログを作成し解析をしようと考えたのが始まりです。
このプロジェクトは仮想環境上で構築したWordPressに対して、Kali Linux からWPScanを用いたスキャンを行い、Splunkでログ解析を行う実験の成果物です。
大層なタイトルではありますが中身はスカスカです。期待しないでください。
前後編に分けて投稿予定で、本記事である前編ではWPScan、Splunkの練習とログ収集の確認をしていきます。
後編では主に管理画面に対して攻撃を仕掛けWAF導入時のログ、Basic認証導入時のログなどいくつかのセキュリティをしその比較をしようと考えています。
⚠️注意事項
・本記事に含まれる内容は全て学習目的です
・実在するシステムや第三者への攻撃を目的としたものではありません
・WEB上で公開されているWEBページに本記事の内容を行わないでください
・本記事のIPアドレスは全てプライベートIPアドレスになります
環境
VirtualBoxにて仮想マシンを3つ作成し行っています。SplunkはWordpressのマシンとは同期をせずログファイルを転送する形でログ分析を行っています。同期のやり方わかりませんでした。
各仮想マシンの役割
AlmaLinux①：WordPress（Apache＋PHP＋MySQL）（NAT+ホストオンリーアダプター）
IPアドレス:192.168.56.103
AlmaLinux②：Splunk（受信＆解析）（NAT+ホストオンリーアダプター）
IPアドレス:192.168.56.104
Kali Linux：攻撃用（NAT+ホストオンリーアダプター）
IPアドレス:192.168.56.102
環境設定のポイント
仮想マシン同士で通信を行う必要があるためホストオンリーアダプターを設定しています。また、外部との通信（SSH）のためにNATを有効化しています。ポート番号は競合が発生しないようにしています。
もし同時起動ができない場合はポートの競合、もしくはメモリ不足です。仮想マシンのメモリを減らすかスペックのいいPCでやってみて。
WordPress
・WordPressではプラグインの導入と有効化を行ってください。
Contact-From-7はプラグイン列挙の際に引っ掛かるので導入をします。（何もなかったら面白くない）
・管理者ユーザ以外のユーザを作成します。
やること
今回は「WPScanの実行」「Splunkログ解析」の2つを実施していきます。
後編に向けて手順確認の準備になります。
WPScanの実行
WPScanはWordPressの脆弱性診断に用いられるソフトになります。脆弱性診断ができるということは悪用できるということです。今回は「プラグインの列挙」「ユーザ列挙」「ブルートフォース攻撃」を実行しログイン情報を入手してみます。
プラグインの列挙
まずは WPScanがどのようなものかわからないので簡単なプラグインの列挙を行います。コマンドは
wpscan --url http://IPアドレス/wordpress --enumerate p
出力に内容を上からみていくと画像の箇所があると思います。
WPScanではWordPressの様々な情報を知ることができます。たとえば上画像のログはWP-cronにアクセス可能なことを示しており、したはWordPressのバージョンを表示しています。
cronではDDos攻撃の踏み台に、バージョンはもし古いバージョンを使用している場合は狙われてしまいます。他にも色々な情報があるので調べながらみていくと面白いです。
そしてスクロールしていくと、
プラグインが出力されている箇所を見つけました。
こちらには有効化されているプラグインを検出し表示してくれます。一部検出できないプラグインもあります。それらを見つけるにはまた別のコマンドでいま打ったコマンドより深い階層を見るコマンドを打つことになります。
ユーザの列挙
続いて「ユーザの列挙」を行います。
wpscan --url http://IPアドレス/wordpress --enumerate u
スクロールしていくと User(s)という箇所があり見てみると、登録されているユーザが一覧で出力されています。一番上が最初に作成される管理者ユーザ。あとは作成した順番で出力されます。これで不正アクセスに必要なユーザ名を取得することができました。
ブルートフォース攻撃（パスワードリスト攻撃）
ユーザ名を取得できたので続いてパスワードを入手しアクセス情報を入手します。パスワードを入手する方法はいくつかありますが今回は簡単なパスワードリストを作成しそれを基に攻撃を仕掛けます。なのでリスト内にパスワードを入れて作成してください。
まずはパスワードリストを作成しましよう。
vi wordlist.txt
viエディタを開きます。今回ユーザーのパスワードは全て「0000」のしているので0000を含めて作成していきます。
admin
admin123
password
letmein
qwerty
123456
0000
654321
13579
wpadmin
入力出来たら保存して以下のコマンドを打ってみます。
wpscan --url http://IPアドレス/wordpress -U test01 -P ./wordlist.txt
-Uでユーザを指定し、-Pでパスワードを指定しています。今回はファイルを選択しているのでこの名から総当たりでログインを検証しています。
実行すると以下の画像と同じ出力がされていれば成功です。
[!] Valid Combinations Found:
| Username: test01, Password: 0000
上記の部分がユーザーとパスワードの有効な組み合わせという意味になります。パスワードリストは AI に作らせてもいいですしネットにあるものを使用していろいろ検証してみるのも面白いと思います。
また、画像にはないですが以下の出力もみられるはずです。
Performing password attack on Xmlrpc
これは攻撃にxmlrpc.phpが使用されたことを表しています。
xmlrpc.phpとは WordPressがAPI経由でやり取りするファイルになり脆弱性の一つになります。以下のサイトが詳しく解説しているので気になる方は読んでみて下さい。
Splunkログ解析
これまでの操作により多くのログが溜まっているはずです。アクセスログ、エラーログをSplunkで解析します。まずはログのコピーを取り、Splunkへ転送します。下記では私が行なった方法を紹介しますが送れればどうやってもいいです。
ログ保存と追加
ログをコピーし別ファイルに保存、> でファイルの中身をリセットします。次回はセキュリティの比較を行うため、行ったセキュリティそれぞれの比較用ログが欲しいためリセットをします。
cp /var/log/httpd/access_log /var/log/httpd/access_log.test
> /var/log/httpd/access_log
完了したらaccess_logをerror_logに変更しエラーログも保存しましょう。
そうしたら下記コマンドでzipファイルにまとめFTPを使用しホストOSに転送しましょう。
cd /var/log/httpd
zip testlogs.zip access_log.test error_log.test
一つのファイルにまとめられたらあとはftpでホストOSに転送しWEBブラウザからスプランクを起動、データの追加をしましょう。
プラグインの列挙
プラグインを特定する際には plugins にアクセスしているはずなのでIPアドレスを指定し、plugins にアクセスしているかをサーチします。
index="accesslog_test" sourcetype="access_combined" clientip="192.168.56.102" uri_path="/wordpress/wp-content/plugins/*"
SPL解説
このサーチ文は、特定のIPアドレス（192.168.56.102）からWordPressのプラグインディレクトリ（/wp-content/plugins/）へのアクセスを抽出するものです。
index="accesslog_test"
検索対象のインデックスを指定しています。Splunkはログをインデックスに分けて管理しており、ここでは「accesslog_test」というインデックスからデータを検索しています。
sourcetype="access_combined"
データの種類を指定しています。access_combinedはApacheなどのWebサーバーのアクセスログの一般的なフォーマットです。
clientip="192.168.56.102"
アクセス元のIPアドレスを絞り込みます。これにより、WPScanによる攻撃ログのみを抽出できます。
uri_path="/wordpress/wp-content/plugins/*"
アクセスされたURIのパスを指定します。*はワイルドカードで、plugins/以下のすべてのファイルやディレクトリを検索対象に含めます。
すると画像の出力結果が出ました。これらの結果から以下のことが読み取れます。
ここから読み取れる要素
攻撃者のIPアドレス： 192.168.56.102
アクセス日時： 2025/08/03 22:52:11
HTTPメソッド： GET, HEAD
アクセスされたパス： /wordpress/wp-content/plugins/...
ステータスコード： 200（成功）, 404（見つからない）
User-Agent： WPScan v3.8.28 ←超重要！
WPScanという単語が頻出しているためWPScanによる攻撃だと読み取れます。
また HEADリクエストが多くみられます。HHTPヘッダインジェクションなどに使用されるようです。今回は効率よく探すために使用されたのでしょう。
今回特定されたプラグインはContactForm7のみだったのでステータスコード200に絞って調べてみます。先ほどのサーチ文に半角スペースと200と入力してみます。すると、
このログからは
「攻撃者IPがWPScanを用いてcontact-form-7の存在確認・情報収集をしていた」
「readme.txtやJS/CSSなどの静的ファイルを通じてプラグインの構造を探ってた」
という攻撃の偵察フェーズが読み取れます。
ユーザの列挙
続いてユーザ列挙の攻撃ログを調べていきます。author=NのようなURLを使用してユーザを調べていきます。このauthor=Nでユーザ情報を抜き取られるのも脆弱性の一つになります。
index=accesslog_test sourcetype=access_combined clientip=192.168.56.102
uri_query="*author=*"
| stats count by clientip, uri_query, _time
| sort -_time
SPL解説
このサーチ文は、WPScanによるユーザー列挙攻撃のログを解析するものです。author=Nというクエリパラメータを悪用したアクセスを特定します。
uri_query="author="
URIのクエリ部分（?以降）にauthor=という文字列が含まれるイベントを抽出します。
| stats count by clientip, uri_query, _time
|（パイプ）は、直前の検索結果を次のコマンドに渡すことを意味します。statsコマンドは、指定したフィールド（clientip、uri_query、_time）ごとにイベントの数をカウントします。これにより、どのIPアドレスがどのクエリを何回実行したかを統計的に把握できます。
| sort -_time
検索結果を時系列（_time）で降順（-）に並べ替えます。これにより、最新のアクセスから順に確認できます。
となります。実行結果は以下のようになりました。
author=1はsplunk(管理者ユーザ)、2、3 はtest01、test02になります。なのでこれらのイベントをみると200が返されていますが、それ以外ではユーザが存在しないため404が返されています。
author=1とauthor=10 の結果を見比べてみます。
author=1
author=10
画像だと時間も混ざってみにくいので同じ時間で比較してみると、、、
2025/08/03 22:27:16.000
192.168.56.102 - - [03/Aug/2025:22:27:16 +0900] "GET /wordpress/?author=1 HTTP/1.1" 200 52430 "http://192.168.56.103/wordpress" "WPScan v3.8.28 (https://wpscan.com/wordpress-security-scanner)"
host = vboxsource = access_log.testsourcetype = access_combined
2025/08/03 22:27:16.000
192.168.56.102 - - [03/Aug/2025:22:27:16 +0900] "HEAD /wordpress/?author=1 HTTP/1.1" 200 - "http://192.168.56.103/wordpress" "WPScan v3.8.28 (https://wpscan.com/wordpress-security-scanner)"
host = vboxsource = access_log.testsourcetype = access_combined
2025/08/03 22:27:16.000
192.168.56.102 - - [03/Aug/2025:22:27:16 +0900] "HEAD /wordpress/?author=10 HTTP/1.1" 404 - "http://192.168.56.103/wordpress" "WPScan v3.8.28 (https://wpscan.com/wordpress-security-scanner)"
host = vboxsource = access_log.testsourcetype = access_combined
違いとしてauthor=10の方は404が返されているのに対しauthor=1は200が２回返されています。これは200 52430という箇所がauthor=1ユーザのページを表示しているためです。52430とはレスポンスのバイト数になります。
つまりまとめると、
１. HEAD /?author=1 でそのページがあるかを軽くチェック（負荷を抑えるため）
２. 返ってきたステータスが 200 OK だったら…
３. GET /?author=1 を使って、本文を取りにいく（＝ユーザー名抽出）
以上の動作を行いユーザ名の抽出、列挙を行っています。
ブルートフォース攻撃（パスワードリスト攻撃）
最後にブルートフォース攻撃を（パスワードリスト攻撃）のサーチを行っていきます。
index=accesslog_test sourcetype=access_combined clientip=192.168.56.102
uri="/wordpress/wp-login.php" method=POST
| stats count by clientip, uri, status, _time, useragent
| sort -_time
SPL解説
このサーチ文は、ログインページ（wp-login.php）に対するブルートフォース攻撃を解析するものです。
uri="/wordpress/wp-login.php"
WordPressのログインページへのアクセスを抽出します。
method=POST
HTTPメソッドがPOSTであるイベントに限定します。ログイン情報の送信には通常POSTメソッドが使用されるため、これによりログイン試行を効率的に特定できます。
| stats count by clientip, uri, status, _time, useragent
statsコマンドを使用し、クライアントIP、URI、ステータスコード、時間、ユーザーエージェント別にアクセス数をカウントします。これにより、同じIPから繰り返しログインが試行され、ステータスコードがどのように変化したか（成功/失敗）を確認できます。
| sort -_time
検索結果を最新のイベントから順に表示します。
ユーザ抽出ではauthor=Nを使用しましたが、ブルートフォース攻撃ではログインページのURLを指定します。
上記サーチを行うと結果は以下結果が出力されました。
これから読み取れること
1. 22:27〜22:43までの間にWPScanでログイン試行（失敗っぽい）を何度もやってる
ステータス200はログイン失敗でフォーム再表示のサイン
User-AgentがWPScanで、連続複数回の試行（計9回）
これはパスワード総当たり（ブルートフォース）攻撃の典型パターン
2. 23:02に「Mozilla」ユーザーエージェントでステータス302のアクセスがある
302はリダイレクトなので、ログイン成功した可能性大
User-AgentがChromeなので、攻撃ツールじゃなく本物っぽいブラウザか、攻撃者がUser-Agentを偽装してるか
3. WPScanによるログイン試行後に、別のツールやブラウザで成功ログインしたと推測できる
WPScanが成功したパスワードを見つけてから、攻撃者が手動か別ツールでログインしたと読み取れます。今回は手動でログインをしました。
以上からWPScanのブルートフォース攻撃（パスワードリスト攻撃）によりパスワードが特定されログインをされたことが分かります。
反省点
ログの少なさ
ログが攻撃ログしかなくログ分析をするまでもなく攻撃とわかってしまいました。内容的には攻撃ログのみあれば問題ないのですが実際の状況を考えた場合、正規のログに紛れていることの方が多いはずなので次回の後編ではこの問題をどうにか解決しようと思います。
サーチ文（SPL）の勉強不足
ほぼすべてをAIに頼ってしまいました。ただ何をしているのか理解はできているので次回は自分で考えてSPLを書けるように勉強をしていこうと思います。
リアルタイムログ収集
同期をしてリアルタイムタイムで収集することが出来ませんでした。後編では実装します。
良かった点
実際に攻撃ができた
実際に自身で攻撃をしてログを収集できたのはとても良かったと思います。kali linux の使い方を学ぶきっかけにもなりました。
新たな知識を身につけた
なにも得られないのがよくないので得るものがあってよかったです。ユーザーエージェントに絞ってログを調べるなど考えたことがなかったので知れてよかったです。
感想
目的の WPScan、Splunk の練習という目的は達成できたと思います。ただ反省点にも書いてある通り多くの反省点、改善点があったのでそれらを次回には改善できるようにしたいと思います。
また全体的に内容が浅いので随時追記していきます。
次回
次回は管理画面にいくつかのセキュリティを施し、それらのログを比較をしてきます。
WAF(MOD security)、Basic認証(プラグイン)、パスワード(強弱の差)、これらのログを比較していこうと思います。
セキュリティ対策の効果をログ分析によって確かめる内容を書こうと思います。