Windowsの「.ms-ad」フォルダとその役割

「.ms-ad」という名前だけからActive Directoryのsystem folderだと判断してはいけません。公開されているMicrosoftやAdobeの製品資料には、このfolderをWindowsの必須構成として説明する明確な仕様が見当たりません。PDFを開いた直後など再現条件があるなら、folderを作成したprocessをProcess Monitorで特定するのが安全です。

結論は「削除や除外設定を先に行わず、作成時刻・owner・内容を記録し、Process MonitorでPathをfilterして作成processを確認します。Adobe Readerが関係する場合はversionとsecurity updateを確認します」です。

目次

名前ではなく生成processから役割を調べる

まずfolderのfull path、作成時刻、owner、hidden属性、内部fileの有無を確認します。user profile直下か、application data配下かで意味が変わります。PDFをAdobe Acrobat Readerで開くと現れるという報告はありますが、community報告を製品仕様として断定せず、実機でcreator processとoperationを捕捉します。

  • .ms-adのfull pathと作成・更新時刻
  • folder内のfile、ACL、owner、hidden属性
  • 発生直前に起動したPDF viewerと正確なversion
  • 別viewerや空のtest PDFでも再現するか
  • endpoint protectionや会社policyが作成していないか

Process Monitorはfile system、Registry、process活動をreal timeで記録できます。capture範囲が広いのでPath is対象folderというfilterを先に設定し、個人情報が多いtraceを長時間採らないようにします。Process NameだけでなくImage Path、Parent PID、Operation、Resultを確認します。

結論から言うと、「.ms-ad」という名前だけで役割を特定できるMicrosoft公式仕様は確認できません。Active Directoryの必須フォルダー、Adobe Readerの標準フォルダー、マルウェアのいずれとも断定しないでください。フルパス、作成時刻、所有者、ACL、内部ファイル、直前に起動したプロセスを記録し、同名でも別の場所にあるものは別対象として扱います。

Process Monitorで一回だけ再現を採取する

無害なtest PDFを用意し、folderが存在しない状態と存在する状態の二回を比較します。ただし削除前にfolderが本当に空か、別processがhandleを持っていないか、会社policyで保護されていないかを確認します。trace開始、PDF open、folder出現、capture停止という短い一連の操作に限定します。

folder情報を読み取りで確認

PowerShell:
Get-Item -LiteralPath "$HOME\.ms-ad" -Force |
  Select-Object FullName,CreationTime,LastWriteTime,Attributes
Get-Acl -LiteralPath "$HOME\.ms-ad" | Format-List Owner,AccessToString

存在しない場合のerrorと、存在するが空の場合を分けて記録します。

内部entryを表示

Get-ChildItem -LiteralPath "$HOME\.ms-ad" -Force |
  Select-Object Name,Length,CreationTime,LastWriteTime,Attributes

hidden entryを含め、内容が空だと確認しても役割を推測しません。

Process Monitorのfilter

Filter:
Path  begins with  C:\Users\対象user\.ms-ad  Include
Operation is CreateFile または SetBasicInformationFile  Include

実際のprofile pathを選択し、traceを数秒に限定します。

viewer別の再現表

Acrobat Reader current: 出現 / 非出現
Microsoft Edge: 出現 / 非出現
test PDF: file hashと時刻
network切断時: 出現 / 非出現

同じPDF、同じuser、同じ時刻帯で一条件だけ変えます。

Adobe Readerの更新状態を確認

Acrobat Reader → Help → About Adobe Acrobat Reader
Help → Check for Updates

会社管理端末では更新操作を行う前にdeployment policyを確認します。

短時間のProcess Monitor採取でPath begins with対象の.ms-adを指定し、CreateFile、WriteFile、SetBasicInformationFileを発生させたImage PathとPIDを確認します。実行ファイルが判明したらSigcheckまたはGet-AuthenticodeSignatureで署名者とハッシュを読み、ベンダー公式の配布元・インストール先・現行版と照合します。空のテストPDFなど機密を含まない入力で一回だけ再現してください。

空folderでも断定できない理由

dotで始まる名前はUnix系ではhidden慣例がありますが、Windowsで名前だけがsecurity上の特別な権限を与えるわけではありません。空folderでもapplicationのstate marker、temporary working directory、失敗した初期化の残りなど複数の可能性があります。creator processとcall stackが分かるまで「Windowsが必要」「malware」「Adobeの仕様」のいずれにも断定できません。

  • Microsoft Process Monitorはfile system operationとprocess情報を同時に記録できる
  • AdobeはAcrobat/Readerのsecurity update情報を継続公開している
  • 同名folderでもpathとownerが違えば別の対象である
  • 空であることは不要である証明にならない
  • community上の再現報告はvendorの正式仕様とは区別する必要がある

先頭のドットは名前の一部にすぎず、Windowsがそのフォルダーへ特別な信頼を与える印ではありません。空フォルダーでも状態マーカー、一時作業場所、失敗した初期化の残骸など複数の可能性があります。作成元プロセス、呼び出し操作、署名、親プロセス、再現条件がそろって初めて由来を絞れます。名前の連想や検索結果だけで用途を決めないことが重要です。

security softwareの除外へ入れない判断

security productのscan除外へ.ms-adを追加しないでください。creatorが不明なfolderをstartup scriptで毎回消すと、application errorやtrace消失を招きます。Process Monitor traceには他のpathやuser情報が含まれるため、filter後の必要部分だけを保管し、外部共有前にreviewします。

  • ms-adという名前からActive Directory必須folderと断定する
  • 空なので無条件に定期削除する
  • community回答だけを公式仕様として引用する
  • folderをantivirus除外へ追加する
  • Process Monitorを長時間無filterでcaptureする

正体が不明な段階で定期削除タスクを作ったり、Windows Securityの除外へ登録したり、Everyoneへ書き込み権限を付けたりしません。Process MonitorのPMLには他のユーザー名やパスが含まれるため、対象イベントだけを抽出し保管範囲を限定します。未知の署名なし実行ファイルやスクリプトが内部にある場合は開かず、端末をネットワークから隔離するかをセキュリティ担当へ相談します。

PDF viewer別に発生条件を比べる

同じviewerを二回起動して同じprocessがfolderを作るか、最新版へ更新後も再現するか、別viewerでは作られないかを確認します。調査終了時はfolderを残した場合と移動したtest copyの場合のapp動作を記録し、Windows Updateとsecurity scanが正常であることも確認します。

  1. folderを作成したexecutableの署名・path・versionが特定できた
  2. .ms-adへ行われたoperationと発生条件を再現できた
  3. security除外や広いpermission変更を行っていない
  4. vendor update後の再現有無と保留事項を記録した

同じアプリ・同じテストファイルで二回再現し、同じ署名済み実行ファイルが同じ操作で作成するかを確認します。アプリを終了した状態、別の公式ビューアー、更新後の版でも比較します。フォルダーを残したままでも機能影響がないかを観察し、削除検証が必要ならバックアップした試験端末だけで行います。作成元を特定できない状態は「未解決」と記録します。

調査を閉じるための記録項目

signed Adobe processが毎回作成し、最新版でも空folderだけが残り機能影響がないなら、無理に消すよりvendorへ再現情報を添えて問い合わせる方が安全です。未知のunsigned process、実行file、scriptが内部に作られる、ACLが不審という場合は隔離判断をendpoint security担当へ委ねます。

Microsoftまたはベンダーが当該パスと用途を公式に説明していない限り、記事では役割を確定しません。署名済みの既知製品が毎回作り、内容が無害でも仕様が不明なら、プロセス名・版・ハッシュ・操作・Procmonイベントを添えてベンダーへ問い合わせます。署名不明、異常な親プロセス、実行可能ファイル、権限変更が見つかった場合は、一般的なアプリ不具合ではなくセキュリティ調査へ切り替えます。

公式情報・参考資料

この記事を書いた人

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

コメント

コメントする

目次