RDPの接続履歴を確認｜リモートデスクトップのログと証拠

2026年9月13日 2026年9月23日

デジタル・フォレンジック調査ラボ

Windowsでは、SecurityログやTerminalServices関連ログ、接続元PCに残るRDPクライアントの履歴等から、リモートデスクトップ（RDP）接続に関する痕跡を確認できる場合があります。

ただし、重要なのは「RDPらしいイベントが一つあった」ことと、実際にリモートデスクトップのセッションが成立し、人が遠隔操作したことを同じ意味にしないことです。

RDP調査では、少なくとも次の段階を分けて考えます。

RDPクライアントを起動した
接続先を入力・選択した
認証が成功または失敗した
RemoteInteractiveログオンが作成された
RDPセッションが生成・再接続・切断された
そのセッション中にファイルやアプリ等が操作された

MicrosoftはSecurityイベント4624について、接続先コンピューターでログオンセッションが作成されたときに生成され、Logon Type 10は「RemoteInteractive」、つまりTerminal ServicesまたはRemote Desktopによるリモートログオンと説明しています。したがって、4624を見る場合もイベント番号だけではなくLogon Typeまで確認する必要があります。

本記事では、単なるイベントビューアーの操作方法ではなく、認証・ログオン・セッション・切断等を区別し、RDPによる遠隔接続を証拠としてどこまで評価できるのかをフォレンジックの視点から解説します。

Windows・RDP関連の技術資料は2026年9月13日時点で確認しています。

なお、現在も不審な遠隔接続やアカウント侵害が続いている可能性がある場合は、証拠保全だけを理由に被害を放置すべきではありません。必要なアクセス停止・ネットワーク隔離等を検討し、実施した担当者、日時、変更内容も記録します。NIST SP 800-61 Rev.3も、インシデント調査で取得するデータやメタデータについて、完全性・来歴を保ち、調査中に行った作業を記録することを重視しています。

RDPの接続履歴だけでなく、AnyDesk・TeamViewer、Wi-Fi、ファイルサーバーなどネットワークに残る証拠全体を確認したい場合は、サーバー・ネットワークフォレンジックで、主な調査項目と確認方法をまとめています。

RDP・リモートデスクトップの接続履歴は残る？

残る場合があります。ただし、Windowsに「過去のRDP接続をすべて一つの一覧で確認できる万能な履歴」があるわけではありません。

主な確認場所は、接続された側と接続した側で異なります。

確認する端末	主な確認対象	主に調べること
接続先PC	Securityログ	ログオン成功・失敗、Logon Type、アカウント、接続元情報
接続先PC	TerminalServices-RemoteConnectionManager	RDP認証に関する記録
接続先PC	TerminalServices-LocalSessionManager	セッションの状態、切断・再接続等
接続先PC	Security 4778・4779等	セッションの再接続・切断
接続元PC	TerminalServices-RDPClient	RDPクライアント側の接続シーケンス
接続元PC	RDPクライアント関連レジストリ	過去の接続先等
接続元PC	Default.rdp・その他の.rdpファイル	接続設定
接続元PC	Prefetch・Jump Lists等	mstsc.exeや関連ファイルを利用した手掛かり

JPCERT/CCも、現在公開しているRDPの解析資料で、接続元のRDPClientログ・Prefetchと、接続先のLocalSessionManager・RemoteConnectionManager等を確認対象として整理しています。同資料の動作確認環境にはWindows 11とWindows Server 2025の組み合わせも含まれています。

ただし、ログの保存期間、監査設定、ログサイズ、PCの継続使用、ログ消去、Windowsのバージョン等によって、調査時まで記録が残っていない場合があります。

そのため、

ログが見つからない＝RDP接続がなかった

とも一律には判断できません。

RDPクライアントを起動しただけでは接続成功とは言えない

mstsc.exeの実行が確認できても、それだけではRDP接続成功を意味しません。

mstsc.exeはWindowsのリモートデスクトップ接続クライアントです。

例えば、Securityイベント4688、Sysmon、Prefetch等にmstsc.exeの実行痕跡が残っていれば、「RDPクライアントが実行された」ことを評価する材料になります。

しかし、その後に、

接続先を入力しただけ
接続を試したが失敗した
認証画面まで進んだ
.rdp設定ファイルを編集した

という可能性もあります。

Microsoftのmstsc公式資料でも、mstsc.exeは接続だけでなく、/editを使用して既存の.rdp設定ファイルを編集できることが説明されています。したがって、mstsc.exeの実行＝RDPセッション成立とは扱えません。

これは既存の「Windowsのアプリ実行履歴」の調査とRDP調査を分ける重要な点です。

関連記事：Windowsのアプリ実行履歴はどこまで分かる？

アプリ実行履歴の記事では「プログラムが実行されたか」を主に扱います。

一方、本記事で確認するのは、その先の

認証 → ログオン → RDPセッション

です。

接続先PCで確認する主なRDPログ

接続された側のWindows PCでは、SecurityログとTerminalServices関連ログを分けて確認するのが基本です。

Securityログ

主な場所は、

イベントビューアー
→ Windows ログ
→ セキュリティ

です。

RDP調査で確認候補となる代表的なイベントには、次があります。

イベントID	主な意味	RDP調査での注意
4624	ログオン成功	4624だけではRDPとは限らない。Logon Typeを確認
4625	ログオン失敗	RDP以外の失敗も含むためLogon Type等を確認
4778	既存セッションへの再接続	RDP以外でも生成され得るためSession Name等を確認
4779	既存セッションからの切断	RDP以外でも生成され得る
4634	ログオンセッション終了	単なる切断とは区別する
4647	ユーザーがログオフを開始	4634等と照合する

Microsoftは4625について「すべてのログオン失敗」に対して記録されるイベントと説明しています。そのため、4625が大量にあることだけで「RDP攻撃」と判断することもできません。

RemoteConnectionManager

主な場所は、

アプリケーションとサービスログ
→ Microsoft
→ Windows
→ TerminalServices-RemoteConnectionManager
→ Operational

です。

ここでは、RDP接続時の認証に関する記録を確認できます。

特によく利用されるのがイベント1149です。

JPCERT/CCのRDP解析資料では、1149について、

「リモートデスクトップサービス: ユーザー認証に成功しました」

というイベントとして、ユーザー、ドメイン、ソースネットワークアドレスを確認対象にしています。

ただし、1149の扱いについては後述するように、認証成功と完全なデスクトップセッション成立を分ける必要があります。

LocalSessionManager

主な場所は、

アプリケーションとサービスログ
→ Microsoft
→ Windows
→ TerminalServices-LocalSessionManager
→ Operational

です。

このログでは、RDPセッションの状態を確認する手掛かりが得られます。

実務でよく確認されるイベントには21、24、25等があります。

JPCERT/CCの2016年の検証資料では、検証環境においてイベント21をRDPセッションのログオン成功、24をセッション切断の記録として整理しています。現在のJPCERT/CCのRDP解析資料でも、24を切断、25を再接続のイベントとして掲載しています。

ただし、ここでは**「イベント21があれば必ずこの状態」「24・25だけ見れば十分」**という読み方は避けます。

Windowsのバージョン、セッションの流れ、再接続の有無等によって現れるイベントは変わり得ます。

調査ではイベントIDだけでなく、

Provider
イベント本文
ユーザー
Session ID
Source Network Address
記録時刻

を確認し、Securityログ等と時系列で照合します。

4624とLogon Type 10から何が分かる？

Securityイベント4624があり、Logon Typeが10であれば、接続先PCでRemoteInteractiveログオンが作成されたことを示す重要な記録です。

Microsoftは4624について、接続されたコンピューター上でログオンセッションが作成されたときに生成されるイベントと説明しています。

ただし、4624には複数のLogon Typeがあります。

例えば、

Type 2＝Interactive
Type 3＝Network
Type 5＝Service
Type 7＝Unlock
Type 10＝RemoteInteractive

です。

MicrosoftはType 10を、

Terminal ServicesまたはRemote Desktopを使用したリモートログオン

と定義しています。

したがって、

4624がある
≠
RDP接続があった

です。

4624をRDP調査で評価するなら、少なくともLogon Typeを確認します。

また、Type 10が確認できたとしても、そのイベントだけから、

社員本人が操作した
何分間画面を操作した
特定ファイルを開いた
ファイルをコピーした
不正アクセスだった

とまでは言えません。

4624にはアカウント、Logon ID、Source Network Address等が含まれる場合があります。

ただしMicrosoftは、IPアドレス、ポート、ワークステーション名等のフィールドについて、認証コンテキストや使用されたプロトコルによって値の入り方が異なると説明しています。接続元IPが常に完全な形で記録されるとは限りません。

Logon IDが利用できる場合は、4778・4779・4634等の関連イベントと照合する材料にもなります。

1149だけでRDP接続成功と言える？

イベント1149だけで「利用者がデスクトップへ入り、実際に遠隔操作した」と断定するのは避けるべきです。

JPCERT/CCの現在のRDP解析資料では、RemoteConnectionManagerのイベント1149を、

ユーザー認証に成功した記録

として扱っています。

ここで重要なのは、

認証成功
≠
完全なRDPセッション成立

という区別です。

調査では1149だけを見るのではなく、同じ時間帯について、

Security 4624
Logon Type 10
対象アカウント
Source Network Address
Logon ID
LocalSessionManagerのセッション関連イベント
Security 4778・4779
接続元PC側のRDPClientログ

等を照合します。

例えば、

1149 → 4624 Type 10 → セッション関連イベント

という流れが時間・アカウント・接続元情報の面で整合すれば、単一のイベントを見るよりRDP利用を具体的に評価しやすくなります。

ただし、

「1149＋4624＋21がそろえば100％遠隔操作された」

といった独自の機械的判定式を作ることは適切ではありません。

ログの有無や順序は環境によって異なり、切断済みセッションへの再接続等もあります。

「何個そろったか」ではなく、各イベントが何を記録しているか、その時系列が一つのセッションとして整合するかを確認します。

接続元IPからどこまで分かる？

接続元IPアドレスは、RDP接続元を絞る重要な情報ですが、IPアドレスだけで特定人物を確定することはできません。

4624には、条件によってSource Network Addressが記録されます。

また4778・4779にも、Client AddressとしてクライアントIPが含まれる場合があります。Microsoftは4778・4779について、Client NameやClient Addressをイベントフィールドとして説明しています。

ただし、調査対象のネットワーク構成によっては、

NAT
VPN
RDP Gateway
プロキシ
踏み台・ジャンプサーバー
共用端末
DHCP
仮想環境

等を経由している可能性があります。

そのため、

IPアドレス＝操作した人物

とは扱えません。

例えば社内のプライベートIPが記録されている場合、同時間帯のDHCPリース情報や端末管理台帳と照合することで、どの端末だったかを絞れる場合があります。

VPN経由ならVPNログ、RDP Gateway経由ならGateway側の記録、社外アドレスならFirewall等のログを確認します。

また、端末が特定できても、

端末＝人物

ではありません。

共用PC、共有アカウント、認証情報の漏えい、別の遠隔操作手段等を検討する必要があります。

接続元PCにはどんな痕跡が残る？

RDPで接続した側のPCにも、接続先やRDPクライアント利用に関する痕跡が残る場合があります。

接続先PCしか調べられない案件もありますが、接続元と疑われるPCも回収できれば、双方の記録を照合できます。

主な確認候補は次のとおりです。

痕跡	確認できる可能性があること	それだけでは言えないこと
Terminal Server ClientのMRU	接続先として記録されたホスト名・IP	完全なセッション成立
`Servers\<接続先>`	接続先やUsernameHint等	実際の操作者
Default.rdp	RDP接続設定	特定日時の接続成功
その他の.rdpファイル	保存された接続設定	実際に使用されたか
RDPClient/Operational	クライアント側の接続シーケンス	人物本人による操作
Prefetch	mstsc.exe実行の手掛かり	接続成功
Jump Lists	mstscや.rdpファイル利用の手掛かり	セッション成立
Recent Files等	`.rdp`ファイル等を利用した手掛かり	RDP接続成功

RDPの接続先MRU

Microsoftは、

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default

に、MRU0、MRU1等として接続先一覧が保存され、MRU0が新しい接続先になることを説明しています。

値にはFQDNやIPアドレスが入る場合があります。

ただし、フォレンジックではMRU単独を「その相手への完全なRDPセッションが成立した証拠」とは扱わず、接続元・接続先双方のログと照合します。

Default.rdp

Microsoftのmstsc資料では、Default.rdpは各ユーザーのDocumentsフォルダーに隠しファイルとして保存されると説明されています。ユーザーが作成した別の.rdpファイルは、Documents以外にも保存できます。

.rdpファイルは接続設定を保持するためのファイルです。

したがって、

Default.rdpがある＝その接続先への遠隔操作が成功した

とは判断しません。

RDPClient/Operational

接続元PCでは、

Microsoft-Windows-TerminalServices-RDPClient/Operational

も確認候補です。

JPCERT/CCの現在の検証資料では、例えば、

1024＝サーバーへの接続を試みる
1025＝RDP ClientActiveXがサーバーに接続
1027＝セッションへの接続
1026＝RDP ClientActiveXの切断

等が確認されています。

MRUやPrefetchだけより具体的な接続シーケンスを確認できる場合がありますが、対象環境の実際のイベント本文を確認し、可能であれば接続先PC側の記録と照合します。

接続元と接続先を突き合わせる

双方のPCを確認できる場合は、

接続先ホスト名・IP
時刻
タイムゾーン
ユーザー・ドメイン
接続元IP
Client Name
Logon ID
Session ID

等を照合します。

接続元PCのRDPClientログと接続先PCのRemoteInteractiveログオン等が同じ時間帯・接続先・アカウント情報で整合すれば、片側の履歴だけを見るよりRDP接続の評価は強まります。

それでも、「そのPCを実際に操作していた人物」の特定は別に行います。

RDPの切断・再接続・ログオフはどう区別する？

RDPセッションの「切断」と「ログオフ」は同じではありません。

切断では、ユーザーのセッション自体が残り、後から同じセッションへ再接続できる場合があります。

ログオフでは、ログオンセッションが終了します。

Securityログでは、特に4778・4779が役立ちます。

Microsoftは、

4778＝既存のTerminal Servicesセッションへ再接続したとき
4779＝既存のTerminal Servicesセッションから切断したとき

に生成されると説明しています。

ただし、4778・4779はFast User SwitchingやHyper-V Enhanced Session等でも生成される場合があります。

そのため、RDPとして確認するときはSession Nameも確認します。Microsoftの例では、RDPセッションではRDP-Tcp#6等の名称が示されています。

LocalSessionManager側では、環境に応じて、

24＝セッション切断
25＝セッション再接続

等も確認候補になります。

一方、Securityイベント4634はログオンセッションが終了し、存在しなくなったことを示します。

4647はユーザーがログオフ処理を開始した場合に生成され、Microsoftは4634と4647の違いを明確に説明しています。

状態	主な確認候補	考え方
セッション再接続	4778、LocalSessionManager 25等	既存セッションへ戻った可能性
セッション切断	4779、LocalSessionManager 24等	セッションから離れた。ログオフとは限らない
ユーザーによるログオフ開始	4647	ログオフ操作を開始
ログオンセッション終了	4634	セッションが終了して存在しなくなった

例えば、

4624 Type 10 → 4779 → 4778 → 4779 → 4634

という記録があるなら、最初のログオンから最後までを単純に一続きの「遠隔操作時間」とするのではなく、切断と再接続を含むセッションの状態変化として整理します。

RDP接続履歴で分かること・分からないこと

RDPの痕跡は、証拠ごとに示している事実が違います。

痕跡	比較的言いやすいこと	それだけでは言えないこと
`mstsc.exe`実行	RDPクライアントが実行された手掛かり	RDP接続成功
接続先MRU	接続先として記録されたホスト名・IP	完全なセッション成立
Default.rdp	RDP接続設定が保存されている	特定日時の接続成功
4625	ログオン失敗が発生した	RDP接続成功、不正アクセス
4624 Type 10	RemoteInteractiveログオンが作成された	実際の操作者本人、操作内容
1149	RDPユーザー認証成功の手掛かり	完全なデスクトップセッション成立
LocalSessionManager	セッション状態に関する記録	セッション内で行われた全操作
4778	既存Terminal Servicesセッションへの再接続	必ずRDP、操作内容
4779	Terminal Servicesセッションからの切断	ログオフ
接続元IP	Windowsが記録した接続元ネットワーク情報	特定人物
接続元・接続先双方の整合	RDP接続の評価をより強くできる	人物の完全特定、操作内容の全容
複数痕跡の時系列一致	一連のRDP利用として評価しやすくなる	「100％本人がこの操作をした」という機械的結論

デジタルフォレンジックPROでは、Windowsイベントログ、TerminalServicesログ、Default.rdp、MRU等を、調査で確認するデジタルアーティファクトの例として公開しています。

実際の調査では、一つのアーティファクトだけで結論を出すのではなく、複数の記録を相互に照合することが重要です。

RDP接続後に何をしたか調べる方法

RDP接続が確認できても、そのセッション内で何をしたかは別の調査課題です。

例えば、あるアカウントでRDPログオンしたことが確認できても、それだけでは、

顧客ファイルを開いた
データをコピーした
PowerShellを実行した
USBへ持ち出した
Webサイトへアップロードした
ファイルを削除した

とは判断できません。

目的に応じて、別のアーティファクトを照合します。

調べたい操作	主な確認候補
アプリを実行した	4688、Sysmon、EDR、Prefetch等
ファイルを作成・変更・削除した	`$MFT`、`$UsnJrnl`、ファイルアクセス監査等
ファイルを開いた・参照した	LNK、Jump Lists、Recent Files、アプリ側履歴等
PowerShellを使用した	PowerShellログ、PSReadLine履歴、プロセス実行記録等
Webを利用した	ブラウザ履歴、ダウンロード履歴、Proxy・EDR等
USBを使用した	USB接続痕跡、LNK、ファイルシステム、外部媒体本体等
ネットワーク通信した	Firewall、EDR、Sysmon、Proxy、VPN等

関連記事：Windowsのアプリ実行履歴はどこまで分かる？

関連記事：MFT・USNジャーナルとは？Windowsのファイル履歴を解析

関連記事：Windowsでファイルを開いた履歴は分かる？

ここで注意したいのが、同じ時間帯に発生したからといって、すべてをRDP操作者の操作にしないことです。

バックグラウンド処理、別のローカルセッション、サービス、タスクスケジューラー等による操作もあります。

RDPセッションと個別操作を対応付ける場合は、時刻だけでなく、

アカウント
Logon ID
プロセス
セッション情報
対象ファイル
前後のイベント

等を確認します。

RDPにはクリップボードやドライブ等のリダイレクト機能もありますが、RDP接続があったことだけで「ファイルを持ち出した」と判断することはできません。

ファイルそのものやファイルシステム、監査ログ、接続元側の記録等を別途調べます。

不正アクセスか正規接続かを判断するときの見方

RDP接続があったことと、不正アクセスであったことは別です。

RDPは、

システム管理
テレワーク
保守作業
ベンダーによるサポート
社内サーバー管理

等、正規業務でも利用されます。

一方、正規のユーザー名とパスワードを使ったRDPログオンであっても、資格情報を第三者が取得していた可能性はあります。

そのため、不審なRDP接続を評価するときは、次のような情報を組み合わせます。

確認事項	主な着眼点
利用アカウント	そのアカウントにRDP利用権限・業務上の必要性があったか
接続日時	勤務・保守予定等と整合するか
接続元	通常利用端末・社内ネットワーク・VPN等と整合するか
認証状況	成功・失敗イベントや前後の認証を確認
接続経路	VPN、RDP Gateway、踏み台等を確認
端末	会社管理端末か、共用端末か
セッション後の操作	ファイル・アプリ・PowerShell・通信等を確認
管理記録	保守申請、作業記録、勤怠、端末台帳等と照合

「深夜だから不正」「海外IPだから攻撃」「管理者アカウントだから正規」といった単独条件で結論を出すのではなく、その接続が組織の権限・運用・業務実態と整合していたかを確認します。

また、技術的にRDPセッションを確認できることと、法的に「不正アクセス」と評価されることも同一ではありません。権限関係や事実経緯を別途整理する必要があります。

調査前に保存するログ・避けたい操作

RDPの調査を予定している場合は、イベントログが残っているうちに保全を検討することが重要です。

主な確認・保全候補には、

Security.evtx
TerminalServices-RemoteConnectionManager/Operational
TerminalServices-LocalSessionManager/Operational
接続元PCのTerminalServices-RDPClient/Operational
RDPクライアント関連レジストリ
Default.rdp・その他の.rdp
Prefetch
Jump Lists
対象ユーザーのプロファイル
Firewall・VPN・RDP Gatewayログ
DHCPログ
EDR・SIEMへ転送済みのログ

等があります。

RDP調査だけに必要なデータを限定できない場合は、PC全体の証拠保全が必要になることもあります。

特に、社内処分、紛争、訴訟、刑事手続等で後から検証する可能性がある場合は、単にイベントビューアーの画面を撮影するだけでなく、元のEVTX、取得日時、対象PC、取得方法等を説明できる形で保存することを検討します。

NIST SP 800-61 Rev.3では、インシデントデータとメタデータを収集し、完全性と来歴を保つこと、調査中に行った行為を記録することが推奨されています。

一方、調査前には次のような操作に注意します。

イベントログを消去する
PCを初期化する
Windowsを再インストールする
対象ユーザーを削除する
遠隔操作ソフトをアンインストールする
クリーンアップツールを実行する
不要なOS更新や設定変更を行う
「確認のため」にmstsc.exeや対象アプリを何度も起動する

PCを継続使用すると、新しいイベントによる上書きや、MRU・Prefetch・Jump Lists等の更新が発生する可能性もあります。

ただし、現在進行中の侵害を止める必要がある状況では、被害停止を後回しにしてまでPCを無操作にするべきとは限りません。

アカウント停止や通信遮断等が必要なら、実施した内容と時刻を記録し、そのうえで取得可能な証拠を保全します。

証拠保全そのものについては、別記事で原本・ディスクイメージ・ハッシュ・Chain of Custody等を詳しく解説しています。

関連記事：デジタルフォレンジックの証拠保全とは？

自社確認で足りる場合とフォレンジック調査を検討する目安

通常のシステム管理として「この時間にRDPログオンがあったか」を確認するだけなら、社内担当者によるイベントログ確認で足りる場合があります。

一方、目的が「証拠としてどこまで言えるか」に変わると、必要な調査範囲も広がります。

状況	自社確認で対応しやすい	フォレンジック調査を検討
定例の管理・監視	○	必須ではない
特定日時のRDPログオン有無を確認	○	条件による
接続元IPを確認	○	経路特定が複雑なら検討
誰が実際に操作したかを特定したい	△	○
RDP接続後のファイル操作を調べたい	△	○
接続元PCと接続先PCを突合したい	△	○
ログが欠落・消去・上書きされている	△	○
情報持ち出しまで確認したい	△	○
証拠隠滅や改ざんの疑いがある	△	○
懲戒・訴訟等で第三者に説明する可能性がある	△	○