こんにちは、NTTドコモグループの現場受け入れ型インターンシップに「D2：攻撃者視点に立ち攻撃技術を研究開発するセキュリティエンジニア」ポストで参加させていただきました、島田です。
本記事では、本インターンシップでの取り組みについて紹介いたします。
NTTドコモグループのセキュリティ業務、特にOffensive Securityプロジェクト（以下、PJ）に興味のある方、インターンシップの参加を検討している方などへの参考になれば幸いです。
Offensive Security PJとは
今回私が参加させていただいたワークフィールド（職場）はイノベーションセンターのテクノロジー部門内に位置するOffensive Security PJです。
Offensive Security PJ は最先端のセキュリティ技術を調査・検証し、その成果を社内外に共有していくことをミッションとしています。
特に重視しているのは「攻撃者の視点」に立つことです。防御の立場から技術を眺めるだけではなく攻撃者がどのように考え、どのような手法を用いるかを理解することで初めて本質的な対策を打つことができます。そのような視点を持ち続けることで従来の後追いの対策にとどまらず、脅威を先取りして備える「先回りの防御」を実現しようとしています。
単に攻撃手法を模倣するだけでなく、その背後にある原理やアーキテクチャや攻撃の成立条件まで掘り下げるような研究・開発をしています。
参加経緯
私は大学にてネットワークに関する研究をしていますが、個人としてRed Team寄りの技術にも強い関心を抱いています。また、趣味でCTFに参加したりHack The Boxのマシンを攻略したりしています。
技術者の方々にとって「アーキテクチャを理解していなければ実装はできない」という感覚は身近だと思いますが、セキュリティの文脈に置き換えると「攻撃者の視点を持たなければ本質的な防御は難しい」という考えに通じると思っています。日々の学習を通じてこの重要性を意識してきたこともあり、本ポストの「攻撃技術の調査・開発・検証や応用」を重視する活動方針と強く合致すると考えました。
これまで趣味として取り組んできたセキュリティと業務として取り組むセキュリティの両方を体感し、将来のアクションに繋げたいという思いもあり、今回のインターンシップへの応募を決めました。
インターンシップ概要
インターンシップは8月25日から9月5日の平日10日間で開催され、業務体験はオリエンテーションや成果報告会を除いた実質7日間で行われました。
初日と最終日は出社が必須で、それ以外の日程は出社かオンラインかを相談して決めることが出来ました。
またインターンシップ期間中は、検証業務はもちろん、SOC（Security Operation Center）の見学や海外のカンファレンスに登壇された社員の方による再演の聴講、社内LT（Lightning Talks）会への参加、他部署のインターンシップ生との交流などさまざまな体験をさせていただきました。
私が検証業務で取り組んだテーマは以下の2つです。
- Microsoft 365 Copilotの悪用
- LLM応用によるRed Teamオペレーション高度化検証
本記事では、2つのテーマのうち「LLM応用によるRedTeamオペレーション高度化検証」を紹介します。
LLM応用によるRed Teamオペレーション高度化検証
今回のインターンシップでは、Red Team オペレーションの高度化を目的としてLLM を活用した情報分析手法の検証をしました。攻撃環境において取得される大量のログや環境情報の中から攻撃に有用となる情報を「Juicy 情報」とOffensive Security PJ内で呼んでいるのですが、この「Juicy 情報」をどの程度自動で識別できるかをテーマに取り組みました。
事前に準備された被攻撃環境を対象に、権限昇格やラテラルムーブメントといった攻撃シナリオを実際に実践し、シナリオの流れやそこで得られる情報の特徴を把握しました。その上で、攻略過程で収集したログや出力のうち有効と考えられるものを整理し、分析対象のデータセットとして活用しました。
こうして得られたデータを複数の LLM に入力し、それぞれのモデルがどの程度有用な情報を抽出できるかを比較検証しました。
Juicy 情報とは
Juicy 情報とは、セキュリティの文脈で、攻撃や侵入検証において「次の一手に直結する価値の高い情報」を指すPJ内での呼称です。資格情報や接続先、永続化の手がかりなどが該当し、Red Teamのオペレーションやペネトレーションテストの際に非常に有用です。よくある例としては、パスワード、管理用IP、関連データベースの接続情報などが挙げられます。
またJuicy情報は単に次の一手につながるだけでなく、不要な調査や検証に陥るのを防ぎ、調査の優先順位付けや時間短縮にも直結します。
LLMによるRed Teamオペレーション高度化の目的
サイバーセキュリティの世界において、Red Teamオペレーションは組織の防御力、穴を実践的に評価・検証するための大きな切り札となっています。近年、大規模言語モデル（LLM）の急速な発展は Red Team をオペレーションする上でとても有用と考えられており、無限の活用方法が考えられます。
インターン中に行ったLLMを活用して取得した攻撃マシンの脆弱性情報などが、Red Teamオペレーションにおいてどの程度「Juicy（攻撃利用価値が高い）」であり、その情報をいかに迅速かつ正確に評価できるかを検証した結果を共有します。
被攻撃環境の内容
今回の検証は、実践的な攻撃フローをシミュレーションするためにあらかじめトレーナーの方に構築していただいた演習環境で行いました。標的としたホストらは、意図的に複数の既知の権限昇格系の脆弱性や設定ミスが残されたWindowsの環境です。
最初は被攻撃環境を対象とした攻撃シナリオの実践・理解のため実際にvictim1～victim3の３つの攻撃マシンの攻略をしました。ここは本業務の本質ではありませんが、非常に楽しく攻略させてもらったので少しwriteupとして記載しておこうと思います。
Victim1 から Victim2
最初に、攻撃拠点となる Attacker (Kali)マシンから WS01 (victim1)へ C2 (Command and Control) セッションを張ることから始めました。Metasploit を用いて悪意のあるペイロードを作成し、WS01 に送り込んで被害者側で実行してもらいセッションを確立しました。この時点では権限はユーザー権限のみでした。
少し探索すると dev-machine.txt と Default.rdp というファイルを見つけました。meterpreter > ls の出力は以下の通りです。
Listing: C:\Users\victim-user\Documents ======================================= Mode Size Type Last modified Name ---- ---- ---- ------------- ---- 100666/rw-rw-rw- 0 fil 2025-08-26 01:38:44 +0000 Default.rdp 040777/rwxrwxrwx 0 dir 2025-08-04 08:16:07 +0000 My Music 040777/rwxrwxrwx 0 dir 2025-08-04 08:16:07 +0000 My Pictures 040777/rwxrwxrwx 0 dir 2025-08-04 08:16:07 +0000 My Videos 100666/rw-rw-rw- 402 fil 2025-08-04 08:16:27 +0000 desktop.ini 100666/rw-rw-rw- 54 fil 2025-08-26 04:33:18 +0000 dev-machine.txt
中身を確認したところ、以下のようなファイルが見つかりました。
| ファイル名 | 中身 |
|---|---|
dev-machine.txt |
DEV01 というマシンに対するクレデンシャル（ユーザー名とパスワード） |
Default.rdp |
RDP 接続用の設定ファイル（DEV01 の IP アドレスを含む） |
これらの情報から、DEV01 (victim2)のユーザーアカウント用ログイン情報であると判断し、RDP 接続をし、 victim-user@DEV01 でのログインに成功しました。
Victim2 の privilege escalation
User一覧を見ると victim-admin というユーザーがあり、名前から管理者権限を持っていそうだと判断しました。
C:\Users\victim-user>wmic USERACCOUNT Get Domain,Name,Sid Domain Name SID DEV01 DefaultAccount xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DEV01 Guest xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DEV01 victim-admin xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DEV01 victim-user xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DEV01 WDAGUtilityAccount xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
しかし他にめぼしいものは見つからず、ほかのツールを用いてさらに調べたところ、書き込み権限のあるディレクトリを発見しました。その中で unquotedsvc 配下のパスが Modifiable と表示されました。
=== Services with Unquoted Paths === Service 'unquotedsvc' (StartMode: Manual) has executable 'C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe', but 'C:\Program Files\Unquoted Path Service\Common' is modifable.
つまり、Unquoted Service Path の脆弱性が確認されたということになります。
Windowsでは登録された Full-path が正しくダブルクオーテーションで囲まれていないと、途中のディレクトリ名を実行ファイルとして誤認される可能性があります。
そのため、悪意のあるユーザーが書き込み可能な場所に任意の実行ファイルを設置できるなら、そのサービスが管理者権限で起動した際に意図せずそのファイルが実行されます。
この脆弱性を利用して対象システムの同一ディレクトリに common.exe という名前のペイロードを配置しました。攻撃側の Kali マシンでは事前にリスニングを開始しておき、対象上で以下の操作をしました。
sc stop unquotedsvcを実行してサービスを停止。- 続けて
sc start unquotedsvcを実行してサービスを起動。
そうすると、サービスの再起動時に配置していたペイロードが自動的に起動し、期待通り権限昇格が確認できました！
この権限昇格方法は多数あったうちの１つであり、他にもバイナリ自体の書き換えが可能な脆弱性などを利用した権限昇格方法もありました。
Victim2 から Victim3
管理者権限でvictim-admin@DEV01のパスワードを変更したのちログインし、怪しいファイルがないか探していたら、Desktop上に dev というフォルダを確認しました。
中には以下のようなファイルが見つかりました。
accounts.csv |
11種類のユーザー名とパスワードが記載されているファイル |
|---|---|
userAddTest.ps1 |
リモート接続先でアカウントを追加する用途と思しきスクリプト |
ただし、別ホスト（ADMIN-SERV）への接続情報は見当たりませんでした。そこで最初にアクセスしていた WS01 のマシンで、管理者権限での探索をしていなかったことを思い出し、改めて victim1 にログインして調べ直したところ、期待通り該当しそうな.rdpファイルを発見しました。
今はこうしてしれっと書いていますが、実際攻略を試みていたときはこれに気づかず散々関係の無いログを漁ったり、無駄なスキャンをかけたりしてしまっていました。環境を用意してくれたトレーナーの方の思惑通りにハマっていたと思います。
さらに Documents 配下にあった PowerShell スクリプト（.ps1）を確認すると、ADMIN-SERV に接続するためのユーザー名とパスワードが記されていました。
その情報を用いてログインを試みたところ、無事に接続に成功！
PS C:\Users\ServAdmin> whoami admin-serv\servadmin
管理者権限であることを確認し、攻略が完了しました。
LLMによる攻撃手順の評価
こうして被攻撃環境の攻略が完了し、攻撃シナリオを把握した上で、得られた各種情報を大規模言語モデル（LLM）がどこまで識別できるか、また次の一手に繋がる有益な示唆をどれだけ提示できるかを検証します。検証の主眼は次の2点です。
- Juicy情報の迅速な識別と構造化ができるか
検出された大量の情報から、攻撃にとって最も価値の高い「Juicy情報」を抽出し、JSON 等の構造化フォーマットで出力できるかを確認。 - 情報についてのリスク評価
抽出された情報に対して、優先度（どれを最初に狙うべきか）・有効性（実際に利用可能か）・持続性（長期的に有効か）・攻撃フェーズ（初動／横展開／権限昇格など）といった実戦的観点から評価を付与できるかを検証。
今回はMicrosoft 365 Copilot（以下、Copilot） とAzure OpenAIのgpt-4.1モデル（以下、OpenAI） の2つの種類のLLMを使用し、それぞれ比較検証しました。
検証方法と検証観点
検証は以下の手順で実施しました。
victim2の権限昇格時に取得したSharpUp.exeの出力結果を LLM に入力する。- カスタムプロンプトを与えて、LLM に JSON 形式での抽出結果を出力させる。
- LLM の出力と手動で得た結果を比較し、抽出精度や実用性を評価する。
また、カスタムプロンプトは以下の観点で作成し、検証しました。
| 検証観点 | 目的 |
|---|---|
| Juicyな情報の中に優先順位をつけることはできるのか | 多数の脆弱性の中から、最も致命的なもの（Priority 1）を特定させる。 |
| 攻撃に使える有効性を示すことはできるのか | 情報が単独で即座に攻撃可能（Immediate Exploit）か、他の情報との連鎖（Requires Chaining）が必要かを判断させる。 |
| 情報が有効であり続ける期間（可変性はあるか？） | 脆弱性がシステムのライフサイクルで「Long-term（長期的）」に残るか、「Short-lived（一時的）」かを判断させる。 |
| 検証・攻撃をするどの段階で有効か？ | 情報をPrivilege Escalation、Persistence、Lateral Movementなどの攻撃フェーズに分類させる。 |
| その情報が攻撃対象の範囲を広げるかどうか？ | 権限昇格に留まらず、横展開（Lateral Movement）の足がかりとなるかを判断させる。 |
| MITRE ATT&CKマッピング | 検出された脆弱性を標準的な攻撃手法（T-ID）に紐づけさせる。 |
検証結果
実際に試してみたところ、SharpUp.exe の実行結果は、LLM に入力すると理由や優先順位なども付与された形で返ってきました。単に脆弱性を見つけるだけでは、その利用方法が分からず、手が止まってしまう場面は多々あります。しかし LLM は、そのような場面で補助的に役立ちそうだと感じました。
(左：Sharpup.exeの出力 右：OpenAI)
ここからは、2つの LLM を比較し、検証観点ごとに相違点を整理していこうと思います。
| 検証観点 | Copilot | OpenAI |
|---|---|---|
| Juicy情報の中に優先順位をつけることはできるのか | 順位にばらつきがある。prioity=1は滅多にない | 全体的に高め。priority=3 が一つもない |
| 攻撃に使える有効性を示すことはできるのか | Immediate Exploit が少ない。範囲が狭め | Copilotに比べて危険度の平均値が高め |
| 情報が有効であり続ける期間（可変性） | 長く見積る傾向高め。short-livedが少ない | 短く見積もる傾向がある |
| 検証・攻撃をするどの段階で有効か | 全て Privilege Escalationと判断 | 全て Privilege Escalationと判断 |
| その情報が攻撃対象の範囲を広げるかどうか | 限定的な拡張性の明示により現実性を重視し、誤検知を抑える方向 | 攻撃者がどう広げられるかを最大限に評価し、攻撃面を広く捉えている |
| MITRE ATT&CKマッピング | 比較的緩やかで、ATT&CKの大分類を幅広く適用 | 細分類を積極的に利用し、攻撃者の技術的アクションがより具体的 |
結論から言うと、Copilot と OpenAIのいずれも、Juicy情報の抽出と構造化を一定の精度で自動化できました。それも攻撃の材料となるデータを的確に拾い上げるだけでなく、それらを「優先度」「有効性」「持続性」「攻撃フェーズ」などの評価軸とともにJSON形式へ整理する、といったところまで対応できていました。つまり、従来であれば人間がシェルのログやスキャナの出力を目視でチェックしながら「これは使える」「これはノイズ」と判断していた作業のかなりの部分を、LLMに肩代わりさせることが現実的なレベルに来ているということだと考えます。 また、リスク評価についても両LLMとも対応可能でしたが、興味深いのは両者の回答に共通性が全く見られなく、「何をリスクとみなすか」という視点がモデルによって大きく異なる点でした。モデルごとの特徴としては以下のような点が見られました。
左: Copilot 右: OpenAI。
Copilot : 広範囲な分析を行えるが、攻撃方法そのものは示さず、脆弱性の説明に留まっている。具体的な悪用方法は一切出て来ず、技術要素の分解や分析には強みがあると感じられる回答。
OpenAI : 攻撃者の視点に立った指摘を返す傾向があり、次のステップにつながるような示唆が得られる。情報の掘り下げもやや綿密で、脅威モデリングに強みを持っていると感じられる回答。
情報の正確さについては、どちらが優れているかはこれだけでは判別できません。ただし、どちらか一方を 100％ 信用してしまうと、検証がバイアスのかかったものになりかねないため、複数の LLM を比較・併用し、相互に補完しながら評価を進めることが望ましいかもしれません。
まとめ
今回の検証を通じて、たとえ LLM のモデルが似通っていても返答内容に明確な差があることに驚かされました。そのため、調査のスコープや目的に応じてモデルを使い分けることが有効であると感じます。
また、Copilot の出力は想定よりもフィルタにかからず返ってきた点が意外でした。ただし「図示してください」といったリクエストにはフィルタが作用し、返答が返ってこなくなるなど、制御の仕組みが部分的に異なることも確認できました。
これは当たり前なのですが、今回は攻撃検証用に用意された環境だったため、つい何度もエクスプロイトを試したりスキャンを繰り返したりしてしまいました…（ごめんなさい）しかし、本番の業務では実際に企業が運用する環境を対象に検証をすることになるため、好き勝手に振る舞ってはいけません。事前の合意や関係者との調整、適切なスコープ定義やログ管理など、交渉と運用上の配慮が必須であることを改めて強く意識しました。これは業務として体験しなければ一生学べなかったことだと思うのでとてもありがたく感じています。
インターンの感想
ここ最近の学術論文を読んでいるとLLMに注目した研究が多いとは感じていました。ただ、AIという存在の大きさや複雑さを考えると、自分が対話型AIを日常的に使っているにもかかわらず、それをそのまま業務に取り入れることにはどこか違和感がありました。
しかし実際に業務として触れてみるとLLMという技術の奥深さは想像以上で、その有用性を強く実感できました。新しい生成AIツールに潜む脆弱性を体系的に調べるプロセスや、LLMをセキュリティ領域に応用する具体的な方法を学べたことは大きな収穫です。当初リモートワークの利用で、初日・最終日以外に出社しないつもりでしたが、毎日の業務があまりにも楽しく、結局なかなかの頻度でオフィスに行きました！早起きと通勤ラッシュに慣れるのは大変でしたが、今となっては毎日出社すればよかったと少し後悔しています。
さらに、流行の技術をただ追いかけるのではなくリスクを冷静に見極める視点、Offensive Security PJ から学んだチームで知見を共有しながら改善策を考える姿勢、新しい技術を導入するときに既存の仕組みとどう結びつけるかを考える柔軟さなど、こうしたものを意識できるようになったのも良い経験でした。「便利さ」と「プライバシー・リスク」のバランスを常に意識する倫理観も、自分の中に根付いたと思います。
セキュリティ技術を深めたいと思っていた私にとって、関心のあることに思いきり取り組めたこの2週間はとても充実した時間であり、自分の視野や姿勢を大きく広げてくれる経験になりました。
おわりに
今回のインターンシップでは日頃の活動だけでは決して得られないような貴重な体験をさせていただき、とても光栄に思っています。特に2週間を通じて現在ホットなテーマであるLLMのセキュリティについて深く学ぶ機会をいただき、最新動向を追い続けることの重要性やセキュリティそのものの面白さを改めて実感できました。 また、「攻撃者の視点に立つ」という考え方についてもトレーナーの皆さまからのご指導を通じて少しずつ身につけることができたと感じています。
このような貴重な機会を与えてくださったOffensive Security PJの皆さまに心より感謝申し上げます。さらに、上長の有藤さん、トレーナーの四方さん、田口さんにも厚く御礼申し上げます。
本記事を通じて少しでもインターンシップに興味を持っていただけたら大変光栄です。
