Windowsの「.ms-ad」フォルダーを安全に調べる方法

Windowsで見慣れない「.ms-ad」フォルダーを見つけても、名前だけでActive Directoryの必須フォルダー、Adobe製品の標準フォルダー、マルウェアのいずれかと決めることはできません。本記事で参照したMicrosoftの診断ツール資料とAdobeの製品・更新資料だけでは、この名前のフォルダーの作成元や用途は確定できません。

削除やセキュリティ除外を先に行わず、フルパスと現在の状態を記録し、必要に応じて短時間のProcess Monitor記録でアクセス元と操作内容を調べます。この記事は調査方法の説明であり、特定の端末で「.ms-ad」を作成したプロセスを確認した実測報告ではありません。

目次

まずフォルダーの場所と状態を記録する

同じ名前でも保存場所が違えば別の対象です。ユーザープロファイル直下なのか、アプリのデータ保存先なのかを区別し、次の情報を控えます。所有者や作成時刻は手掛かりですが、どの実行ファイルが作成したかを単独で証明する情報ではありません。

  • フルパス、作成日時、最終更新日時、確認時刻とタイムゾーン
  • 所有者、アクセス許可(ACL)、隠し属性などの属性
  • 直下のファイルやサブフォルダーの有無。内容を調べるために未知の実行ファイルやスクリプトを起動しない
  • 気付く直前に使用したアプリ名と正確なバージョン、行った操作
  • 会社管理端末の場合は、配布アプリや端末管理の方針に関する管理者の情報

PowerShellで読み取り確認する

次は現在のユーザーのホームフォルダー直下を調べる例です。別の場所に見つかった場合は、$targetを実際のフルパスに変更してください。通常の権限で確認し、アクセス拒否が出ても所有権やACLを変更して通そうとしません。

$target = Join-Path -Path $HOME -ChildPath '.ms-ad'

Get-Item -LiteralPath $target -Force -ErrorAction Stop |
  Select-Object FullName,PSIsContainer,CreationTime,LastWriteTime,Attributes

Get-Acl -LiteralPath $target -ErrorAction Stop |
  Format-List Owner,AccessToString

「見つからない」「アクセスが拒否された」「存在する」を区別して記録します。-Forceは隠し項目などを表示するための指定で、アクセス権を迂回する指定ではありません。PSIsContainerがFalseならフォルダーではありません。また、属性にReparsePointがある場合はリンクなどの可能性があるため、リンク先を確認せずに内部の調査を進めないでください。

直下の項目を一覧にする

通常のフォルダーであることを確認できたら、同じPowerShellセッションで次を実行します。再帰検索はせず、直下の項目だけを読み取ります。

Get-ChildItem -LiteralPath $target -Force -ErrorAction Stop |
  Select-Object Name,PSIsContainer,Length,CreationTime,LastWriteTime,Attributes

エラーがなく一覧が空でも、その時点で直下の項目が見えなかったことを示すだけです。必要性や安全性までは判断できません。先頭のドットも用途や信頼性を保証する印ではなく、隠し属性は名前とは別に確認します。

Process Monitorで短時間の操作記録を採る

Microsoft SysinternalsのProcess Monitorは、ファイルシステムやレジストリ、プロセスなどの活動を記録するツールです。過去に終わった作成操作をさかのぼって記録するものではありません。すでにあるフォルダーへのアクセスだけが見えた場合、最初の作成元は未確認のままです。

使用する場合は公式配布元で対応OSと利用条件を確認します。管理者権限での記録が必要になるため、会社管理端末では担当者に相談してください。調査のために既存フォルダーを削除・移動・改名したり、新たなアプリを導入したりする必要はありません。

表示フィルターは対象そのものと配下を分ける

起動直後に記録が始まることがあるため、まず[File]→[Capture Events]の状態を確認して停止します。[Filter]で既存の条件を確認し、今回の調査と無関係な条件で対象が隠れないよう整理します。次の表はフィルター画面に追加する設定例で、PowerShellコマンドではありません。C:\Users\SampleUser\.ms-adは実際のパスに置き換えます。

ColumnRelationValueAction
PathisC:\Users\SampleUser\.ms-adInclude
Pathbegins withC:\Users\SampleUser\.ms-ad\Include

同じPath列のInclude条件はORで組み合わされ、1行目で対象フォルダーそのもの、2行目でその配下を表示します。2行目の末尾のバックスラッシュ(\)を省くと、.ms-ad-oldなど同じ文字列で始まる隣のフォルダーまで一致します。[Path is]だけでは内部ファイルの操作を見落とすため、配下の条件も加えます。

最初からProcess NameをAdobe製品に限定したり、OperationをCreateFileだけに限定したりしません。別のプロセスや名前変更などの操作を見落とすためです。読み取り、書き込み、属性変更を含む対象パスのイベントを確認し、必要になった段階で表示をさらに絞ります。

フォルダーを消さずに観察する

  1. 既存の記録を必要に応じて保管し、今回の開始前の状態と時刻を控える。記録には関係のない作業を混ぜない
  2. [Capture Events]を有効にする。Ctrl+Eでも切り替えられるが、開始・停止の状態を画面で確認する
  3. 普段の操作のうち、発生に関係しそうなものを一度だけ行う。PDFを使うなら自分で用意した機密情報のない既知のテスト文書を、すでに導入済みの信頼できるビューアーで開く
  4. 観察した操作が終わったらすぐ記録を停止し、開始・終了時刻、表示の変化、エラーの有無を記録する

既存フォルダーがあるなら、そのままアクセスを観察します。自然に新規作成が起きる場面を記録できなければ、無理に作り直さず「アクセス元は確認、作成元は未確認」とします。未知のPDFやフォルダー内の実行ファイルを、再現のために開かないでください。

CreateFileだけで作成元と決めない

OperationがCreateFileでも、新規作成とは限りません。Windowsのファイル操作には、存在する対象を開く場合と新たに作る場合があり、成功を示すResultだけでも区別できません。MicrosoftのZwCreateFile資料でも、要求する処理と、作成・オープンなどの結果は区別されています。Procmonのイベント名を、同名のWin32 APIが直接呼び出された証拠と考えないでください。

対象イベントを開き、時刻、Path、Process Name、PID、Image Path、親プロセス、Operation、Result、Detailを照合します。作成要求を表すDispositionだけでなく、表示される場合はOpenResultと、フォルダーを示すOptionsも確認します。次は読み取り方の例で、実際に採取した結果ではありません。

イベントの例読み取れることと限界
CreateFile、SUCCESS、OpenResult: Opened既存の対象を開いた記録です。このイベントだけでは新規作成を示しません。
対象フォルダーそのものへのCreateFile、SUCCESS、OptionsにDirectory、OpenResult: Createdその時刻に、そのフォルダーの作成が記録されたことを示す根拠になります。配下のファイルの作成と取り違えず、実行ファイルと前後の操作も照合します。
Disposition: OpenIf存在すれば開き、なければ作る要求です。要求だけではどちらが起きたか決まりません。
WriteFileやSetBasicInformationFile書き込みや基本属性などの変更の手掛かりです。対象フォルダーの新規作成を単独で証明するものではありません。
NAME NOT FOUND、ACCESS DENIEDなどその要求が成功した作成記録とは扱いません。エラーの意味は前後の操作と合わせて確認します。

作成に相当する結果が確認できない場合、最初にアクセスしたプロセスを「作成元」としないでください。記録の開始が遅い、フィルターが違う、別名から移動・改名されたなどの可能性も残ります。イベントがないことは、フォルダーが不要または安全である証明にもなりません。

表示の絞り込みとログの保存範囲を区別する

Process Monitorの通常のフィルターは非破壊的な表示フィルターです。画面が「.ms-ad」だけになっても、見えないイベントが元の記録から消えたわけではありません。フィルターを設定しただけで収集範囲や保存範囲が限定されたと思わないでください。短時間の記録でも、ほかのパス、ユーザー名、コマンドラインなどが含まれ得ます。

[File]→[Save]では保存対象を明示的に確認します。共有用に対象イベントだけを別ファイルへ書き出すなら、[Events displayed using current filter]を選び、不要なプロファイリングイベントなどを追加しない設定を確認します。[All events]を選ぶと、収集済みの非表示イベントも保存対象になります。元のPMLやバックファイルも別に残っている場合があります。

書き出したファイルを開き直し、表示フィルターを外した状態でも意図した範囲だけになっているか確認します。ただし、対象イベントの詳細にもユーザー名やパスなどは残るため、イベントを絞ることは匿名化ではありません。外部へ渡す前に内容と共有先を確認し、必要なら個人情報を伏せた最小限の説明や抜粋を用意します。

[Drop Filtered Events]は通常の表示フィルターとは異なり、条件から外れたイベントを記録時に捨てる設定です。後で条件を広げても捨てた記録は戻らず、過去の記録を匿名化する機能でもありません。用途や設定の違いを理解せず、ログを安全にするための万能な設定として使わないでください。保存方法の基本はMicrosoftのProcess Monitor採取・保存手順も参照してください。

アクセスした実行ファイルと製品の情報を確認する

Image Pathが分かったら、ファイルを実行せずに署名とバージョンを確認します。Get-AuthenticodeSignatureは署名情報を取得するコマンドです。ハッシュは別のコマンドで取得します。次の$exeには、イベントから確認した実際の実行ファイルのフルパスを指定してください。

$exe = 'C:\Program Files\ExampleApp\Example.exe'

Get-AuthenticodeSignature -LiteralPath $exe |
  Format-List Path,Status,StatusMessage,SignerCertificate

(Get-Item -LiteralPath $exe -ErrorAction Stop).VersionInfo |
  Format-List FileVersion,ProductVersion,CompanyName,OriginalFilename

Get-FileHash -LiteralPath $exe -Algorithm SHA256 -ErrorAction Stop

署名者、配置先、製品の正規配布元、記録時のバージョンを合わせて確認します。署名が有効でも、その操作の安全性やフォルダーの用途まで保証されるわけではありません。署名がない場合も、それだけでマルウェアと断定しません。会社名などのバージョン情報は、署名の検証とは別の情報です。

Sigcheckでも署名、バージョン、ハッシュを調べられますが、VirusTotalへの照会やファイル送信機能もあるため、内容を確認せずに外部送信のオプションを使わないでください。自動起動との関係を調べる必要がある場合はAutorunsが補助になります。ただし登録があることは作成元の証明ではなく、この調査では項目の無効化や削除を行いません。

Adobe製品が関係する場合の確認項目

PDFを開いた時刻とフォルダーの変化が近くても、それだけでAdobe製品が作成したとは限りません。実際のイベントで該当プロセスを確認できた場合に、Adobe Acrobat/Acrobat Readerの製品名、正確なバージョンと更新状態を記録します。

  • バージョンは[ヘルプ]→[Acrobatについて]などの製品情報画面で確認する。製品や画面構成によって名称が異なるため、表示された文字列をそのまま控える
  • 更新確認はWindows版の[メニュー]→[ヘルプ]→[アップデートの有無をチェック]が目安。会社管理端末では、更新の適用は組織の配布方針に従う
  • 比較するなら、同じユーザー、同じ既知のテスト文書を使い、すでにある別のビューアーや承認済みの更新前後など、一度に変える条件を一つにする
  • 各回について、事前のフォルダーの有無、アプリと版、操作時刻、該当イベント、機能への影響を記録する。既存フォルダーを消して出現をやり直す比較はしない

手順はAdobeの製品・バージョンの確認と手動更新の案内、更新情報はセキュリティ情報を参照してください。これらの更新資料は「.ms-ad」の用途や原因を説明する根拠ではありません。

削除や除外設定ではなく調査結果を残す

空に見えるからと定期削除タスクを作ったり、セキュリティソフトの除外へ追加したり、Everyoneへの書き込み許可などへ変更したりしません。再現のためにネットワーク接続や保護設定を変更する必要もありません。削除や設定変更でアプリへの影響や調査の手掛かりが変わることを避けます。

不審な実行ファイル、予期しない親プロセスや権限の変化、セキュリティ製品の警告がある場合は、そのファイルを開かず、追加の再現操作を止めて管理者やセキュリティ担当へ相談してください。製品との関係が絞れても用途が不明なら、確認した範囲と未確認事項を分け、必要最小限の情報でベンダーへの問い合わせを検討します。

  • 確認できた事実:対象パス、確認時刻、状態、操作を行ったプロセスとImage Path、PID、バージョン、署名、ハッシュ
  • 作成の根拠:対象そのものへの成功した作成結果を記録できたか。アクセスや配下ファイルの作成しかない場合は、その旨を明記する
  • 再現条件:使用したアプリと文書、開始・終了時刻、既存フォルダーを変更していないこと、機能への影響
  • 未確認事項:最初の作成元、製品上の用途、削除可否など。根拠がなければ未解決として残す
  • 保存・共有範囲:元のログと共有用抜粋を区別し、個人情報の確認状況を記録する

「.ms-ad」という名前そのものより、どの場所にあり、どのプロセスが、どの操作を成功させたかが重要です。観測できたアクセスと実際の作成を区別し、分からない点を残したまま安全性や削除可否を断定しないことが、調査の基本です。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次