【永続化編】cron・systemd・scheduled task・WMIで居座る手口と検知｜CTF思考フレームワーク #39
安全に生きたい編集部
安全に生きたい
【RDP編】リモートデスクトップを外部公開する危険と守り方｜CTF思考フレームワーク #26
安全に生きたい編集部
こんにちは、アンペンです。
今回は、RDP、つまりリモートデスクトップを題材にします。RDPは、離れた場所からWindows端末やサーバを操作するための便利な入口です。管理者がサーバに入って作業する、在宅勤務で会社PCに接続する、保守会社が一時的に接続する、といった場面で使われます。
便利な入口は、攻撃者から見ても入口です。特にRDPがインターネットから直接見えている場合、攻撃者は「そこにログイン画面がある」と分かります。そこから、認証情報の使い回し、弱いパスワード、過去に漏れたアカウント、設定不備を狙う流れが生まれます。
この記事では、RDPを「3389番ポートが開いているか」だけで終わらせず、CTFでどう観察し、どんな仮説を立て、どこで判断を止めるべきかを整理します。実在する環境へのログイン試行や総当たりは扱いません。学ぶべき中心は、公開範囲・認証・防御設計です。
注意：RDPへのログイン試行、パスワード推測、認証情報の試行は、許可されたCTF・公式ラボ・自分の検証環境だけで行ってください。第三者のRDPに対して接続確認やログイン試行を行うことは、法的にも倫理的にも問題になります。
Contents
RDPは「遠隔操作用の玄関」
RDPを日常の例に置き換えるなら、会社の建物にある遠隔操作用の玄関です。正しい社員証と暗証番号を持つ人だけが入れるなら便利です。しかし、その玄関が道路から丸見えで、しかも何度でも暗証番号を試せるなら、攻撃者にとっては非常に分かりやすい標的になります。
RDPそのものが悪いわけではありません。問題は、どこから到達できるか、誰が使えるか、何回失敗したら止まるか、追加認証があるか、ログを見ているかです。CTFでも実務でも、RDPを見つけたら「開いている」だけでなく、「この入口はどれくらい守られているか」を考えます。
RDPって、パスワードが分からなければ入れないんだから安全じゃないの？
パスワードだけに頼っている入口は弱くなりやすいです。漏えい済みパスワード、使い回し、弱いパスワード、アカウントロックなし、MFAなしが重なると、RDPは侵入の入口になります。
RDPで大事なのは、「ログインできるか」より先に、「誰に向けて入口が見えているか」を確認することです。
観察：3389番ポートだけで判断しない
RDPの代表的なポートはTCP 3389番です。CTFで対象マシンを調べるとき、3389番が開いていればRDPの可能性を考えます。ただし、ポート番号だけで決めつけるのは危険です。サービスが本当にRDPなのか、Network Level Authentication、つまりNLAが有効か、証明書やホスト名から何が分かるかも見ます。
nmap -p 3389 -sV 10.10.10.10ここで見るのは、RDPがあるかどうかだけではありません。Windows Serverらしい応答があるか、ホスト名が見えるか、古いOSの気配があるか、別のサービスで得たユーザー名とつながりそうか、という周辺情報です。
RDPが開いていても、すぐにログイン試行へ進む必要はありません。CTFでは、RDPの前にWeb、SMB、FTP、メール、設定ファイルなどから認証情報が見つかることがあります。RDPは、その認証情報を使う可能性がある場所として記録しておきます。
| 観察したこと | 考えること | 次に確認すること |
|---|---|---|
| 3389番が開いている | RDPの入口が存在する可能性がある | サービス識別、NLA、有効なユーザー名の有無 |
| ホスト名やドメイン名が見える | Windows環境や組織名の手がかりになる | SMB、LDAP、Web上の表記と一致するか |
| NLAが有効 | 認証前に画面情報を出しにくい構成 | 別経路で正当な認証情報を探す |
| NLAが無効または古い挙動 | 古い設定や脆弱な運用の可能性 | OS、パッチ、公開範囲、ログ監視の観点を確認 |
仮説：RDPは「最後に使う入口」かもしれない
RDPが見えたとき、最初に立てるべき仮説は「ここから直接突破する」ではありません。より現実的なのは、「別の場所で認証情報を見つけたら、ここで使えるかもしれない」です。
たとえば、SMB共有から users.txt が見つかる。Webアプリの設定ファイルから管理者名が分かる。メモに初期パスワードの形式が書かれている。こうした情報がそろったとき、RDPは次の確認先になります。つまり、RDPは単独で考えるより、他のサービスから得た情報を受け止める入口として見る方が自然です。
3389番が開いていたら、すぐRDPでログインを試す流れになるの？
いいえ。まずは他の場所から正当な手がかりを探します。RDPは、見つけた認証情報が使えるかを確認する入口として考える方が自然です。
この考え方は、守る側でも重要です。RDP自体を強くしていても、別の場所に認証情報が漏れていれば危険です。RDPの安全性は、RDP設定だけでなく、パスワード管理、共有フォルダ、メール、VPN、MFA、ログ監視とつながっています。
検証：許可された環境では「入口の状態」を記録する
CTFや自分の検証環境でRDPを確認する場合、記録すべきなのは試行回数ではありません。入口の状態です。RDPが外部から見えているのか、NLAが有効なのか、証明書の名前は何か、ログイン失敗時にロックされるのか、MFAがあるのか。これらの情報が、攻撃側の次の判断にも、防御側の改善にもつながります。
CTFで認証情報を別の場所から得た場合だけ、許可範囲内でRDP接続を試します。そのときも、手当たり次第に試すのではなく、「このユーザー名とパスワードはどこから得たのか」「このアカウントはRDPログオン権限を持つはずか」「失敗したら別の入口を見るべきか」を考えます。
xfreerdp /v:10.10.10.10 /u:USERNAME /p:'PASSWORD'上のような接続例は、CTFや自分のラボで、正当な認証情報を得た後に使う確認です。現実の第三者環境で認証情報を試すためのものではありません。RDPはログが残りやすく、認証失敗は監視対象になります。学習でも実務でも、「試す前に許可範囲を確認する」という姿勢が必要です。
失敗しやすい見方：RDPを見つけた瞬間に総当たりへ飛ばない
RDP編で一番避けたい失敗は、3389番が開いているのを見て、すぐにパスワード総当たりを連想することです。CTFの初心者ほど、ツールで突破する方向に意識が向きやすいですが、実際にはそれより前に見るべきことがあります。
まず、RDPがインターネットに公開されている時点で、防御上の論点があります。公開範囲は適切か、VPNや踏み台を経由しているか、MFAがあるか、アカウントロックがあるか、監視があるか。この確認だけでも記事として十分に価値があります。
次に、攻撃側の思考としても、総当たりは効率が悪く、検知されやすい方法です。CTFであっても、別サービスから得た認証情報を使う、ユーザー名の規則を読む、設定ファイルや共有フォルダを探す、といった静かな調査が先です。RDPは「手元の認証情報を試す場所」であって、「何もない状態から殴る場所」ではない、と考えると整理しやすくなります。
RDPの失敗ログって、ログインできなかった記録だから放置でもよい？
放置しない方がよいです。失敗ログは、攻撃が成功する前に入口が狙われていることを知らせる早期警戒の材料になります。
RDPが見えたら、まず「直接公開されているか」「追加認証があるか」「ロックアウトがあるか」「別サービスから認証情報が得られるか」を確認します。これがCTFでも実務でも自然な順番です。
守る側：RDPを外に直接見せない
守る側の第一原則は、RDPをインターネットへ直接公開しないことです。必要であれば、VPN、ゼロトラストアクセス、踏み台サーバ、条件付きアクセスなどを使い、RDPに到達できる人と場所を絞ります。
次に、認証を強くします。MFAやパスキー相当の追加認証、強いパスワードポリシー、アカウントロック、不要アカウントの無効化が基本です。特に、退職者アカウント、保守用アカウント、共通アカウントは放置されやすく、RDPの弱点になります。
さらに、ログを見る体制が必要です。RDPログオン成功、ログオン失敗、短時間の連続失敗、普段と違う国・時間帯・端末からの接続は、インシデントの早期発見につながります。RDPは入口なので、失敗した攻撃も含めて記録を残す価値があります。
ログ：失敗ログは攻撃の予告として読む
RDPを守るとき、成功ログだけを見るのは不十分です。むしろ重要なのは、失敗ログです。短時間に同じアカウントで失敗が続いている、存在しないユーザー名が大量に試されている、普段使われない時間帯に接続がある、海外IPや見慣れない接続元から試行がある。これらは、侵入が成功する前の予告として扱えます。
Windows環境では、ログオン成功、ログオン失敗、アカウントロック、リモートデスクトップサービスの接続イベントを組み合わせて見ます。単発の失敗だけで即インシデントとは言い切れませんが、同じ接続元から複数アカウントを試している場合や、ひとつのアカウントに対して大量に失敗している場合は、調査対象にする価値があります。
CTFのWriteupでも、RDPに成功した事実だけでなく、「本来ならどのログに残るか」を一言添えると、防御側の学びが残ります。攻撃手順と防御観点をつなげることで、記事が単なる攻略記録ではなく、実務に戻せる教材になります。
| 防御項目 | 良い状態 | 危ない状態 |
|---|---|---|
| 公開範囲 | VPNや条件付きアクセス経由のみ | インターネットから3389番に直接到達できる |
| 認証 | MFA、強いパスワード、不要アカウント無効化 | パスワードのみ、共通アカウント、古い保守アカウント |
| ロックアウト | 失敗回数に応じて制限される | 何度でも試行できる |
| 権限 | RDPログオンできるユーザーを限定 | 広いグループにRDP権限が付いている |
| 監視 | 成功・失敗・異常接続を検知する | ログはあるが誰も見ていない |
CTFのWriteupでは、RDPをどう書くか
RDPが登場するWriteupでは、「3389が開いていたのでRDPした」とだけ書くと、判断の流れが抜けます。読者に伝えるべきなのは、RDPへ進む理由です。たとえば、SMBでユーザー名を得た。Webの設定ファイルでパスワードを得た。その認証情報がWindowsユーザーらしい。だからRDPで確認した、という流れです。
また、RDPでログインできなかった場合も重要です。RDP権限がない、NLAで弾かれる、パスワードはSSHでは使えるがRDPでは使えない、という結果は次の判断材料です。失敗結果を捨てずに、「この認証情報は別サービス用かもしれない」「このユーザーはRDPグループにいないかもしれない」と切り替えます。
| Writeupに残すこと | 理由 |
|---|---|
| RDPを発見した方法 | 入口をどう見つけたかが分かる |
| 認証情報を得た経路 | なぜそのユーザーで試したのかが分かる |
| 成功・失敗の結果 | 次の判断の根拠になる |
| 防御上の問題 | 単なる攻略ではなく学びに戻せる |
まとめ：RDPは便利な入口だからこそ隠す・絞る・監視する
RDPは、管理や遠隔作業にとって非常に便利です。しかし、便利な入口が外から直接見えていると、攻撃者にとっても分かりやすい入口になります。CTFでは、RDPを見つけたら、ポート、NLA、認証情報の入手経路、ログイン権限を順に考えます。いきなり総当たりへ飛ぶのではなく、他のサービスから得た情報とつなげることが重要です。
守る側では、RDPを直接公開しない、MFAを入れる、RDPログオン可能なユーザーを限定する、アカウントロックを設定する、ログを監視する、という基本を積み重ねます。RDPの安全性は、ひとつの設定だけで決まるものではありません。公開範囲、認証、権限、監視の組み合わせで守るものです。
- RDPは遠隔操作の入口であり、攻撃者にも見えやすい標的になる。
- CTFでは、RDP単体ではなく、SMBやWebから得た認証情報と組み合わせて考える。
- RDPが見えたら、3389番、NLA、認証情報の経路、ログオン権限を順に確認する。
- 守る側は、直接公開を避け、MFA・最小権限・ロックアウト・監視を組み合わせる。
次に読みたい記事
RDPの次は、TLS設定不備を見ていきます。暗号化されている通信でも、設定が古い、証明書が不適切、弱い暗号スイートが残っている、といった状態では安心できません。
TLS設定不備編｜暗号化されていても安心できない理由と守り方 →
参考資料
実務でRDPを扱う場合は、Microsoftのリモートデスクトップセキュリティ関連ドキュメント、組織の認証基盤、VPN・ゼロトラストアクセスの運用ルールを合わせて確認してください。CTFでは、RDPを「認証情報を使う入口」として位置づけ、どの情報がどこからつながったのかを記録しながら進めるのが安全です。
