見習いフォレンジッカーのメモ

デジタルフォレンジックに関することを書いていこうと思います。誤りを含む可能性も高いので、信じるか信じないかはあなた次第です。。

Catalina上で保全してきたUnifiedLogを解析する -Analyze the acquired UnifiedLog on Catalina-

ご存知の方もいらっしゃるかもしれませんが、今回も調査に役立つかもしれない調査方法を見つけたので、今わかっていること(こうだと思っていること)やちょっとした検証や考察などについて書きます。

Some of you may know, I found a way of invistigation that might be useful.
So I wrote about what I know now (what I am thinking), how I found this, some verifications, and considerations.

【概要(前置き)】[Introduction]
現在のmacOSの主要ログであるUnifiedLogですが、mojaveではこちらの記事(https://support.blackbagtech.com/hc/en-us/articles/360024686592-Examining-USB-Device-Connections-from-macOS-Sierra-High-Sierra-and-Mojave)のように/private/var/db/diagnostics/と/private/var/db/uuidtext/の中身を1つのディレクトリに格納し、そのディレクトリ名を~.logarchiveとすることでmacOS標準のlogコマンドやコンソール.appを使って解析することができました。
しかし、Catalinaになると、同じことをしても下記のようにエラーになり解析することができませんでした。

When analyzing UnifiedLog in mojave, [merge the contents of "/private/var/db/diagnostics/" and "/private/var/db/uuidtext/" into one directory, and then change the directory name to "~.logarchive"] can possible to analyze using the  "log" command and "Console.app"(as in this article. https://support.blackbagtech.com/hc/en-us/articles/360024686592-Examining-USB-Device-Connections-from-macOS-Sierra-High-Sierra-and-Mojave).
However, in Catalina, even if I did the same thing, the following error occurred and I could not analyze it.

f:id:kasasagi_f:20200311024433p:plain

live環境であれば、調査対象Mac上のターミナルからlogコマンドでunifiedログを調査可能(もしくはsudo log collectでCatalina上でもlogコマンドで解析可能な.logarchiveを作成可能)ですが、実際の調査時は証拠保全やTriageしてきたファイルから調査することも多いと思いますので、この方法ができないとUnifiedLogの解析がし難いという問題があります(商用ツールなどがあれば別ですが)。そこで今回は、この対処法について考えてみました。

In a live environment, the unified log can be investigated using the log command from the terminal on the target mac(or you can create a .logarchive that can be analyzed with the log command on Catalina with sudo log collect). However, at the time of actual investigation, I think that it is often the case to investigate from the files that have undergone evidence preservation and Triage, so there is a problem that it is difficult to analyze UnifiedLog because this(.logarchive) method is not possible (except for commercial tools etc. ). So this time, I thought about this solution.

  

【意義】[How it can be useful for investigation]
Catalina上でも、証拠保全やTriageしてきたファイルからlogコマンドやコンソール.appで解析可能なlogarchiveを生成することができます。

Even on Catalina, logarchive that can be analyzed with "log" command or "Console.app" can be generated from files that have undergone evidence preservation and triage.

 

【解析対象ファイルの場所】[Location of files to be analyzed]
/private/var/db/diagnostics/
/private/var/db/uuidtext/

 

【検証】[verification]
まず始めに、今回の事象が、OSのVer.によって引き起こされる問題なのか(あるいはlogコマンドの仕様が変更されたのか)、それとも、Logファイルの中身の問題なのか切り分ける為、Catalinaで作成したエラーが出てlogコマンドを受け付けない.logarchiveファイルを、mojaveに持っていきlogコマンドがきくか確かめました。
すると、mojave上でものままではlog showコマンドで解析できませんが、ガイダンスの通りlog show --forceのオプションを用いればCatalinaから持ってきた.logarchiveが、使用可能な状態にupdateされることがわかりました。(一方でCatalinaでは--forceコマンドを使用してもlog showコマンドをupdateしたり閲覧することはできません)

First of all, I decided to determine whether this is a problem caused by the OS Ver.(or whether the specification of the log command has been changed) or a problem in the contents of the Log file.
Therefore, I moved the .logarchive file created by Catalina, which had an error and did not accept the log command, to mojave and checked whether it could be processed by the log command.
Then, it is not possible to analyze with the log show command as it is on mojave, but if you use the option of log show --force as guidance, the .logarchive brought from Catalina was updated to a usable state. (On the other hand, in Catalina, it is not possible to update or view the log show command even if you use the --force command)

f:id:kasasagi_f:20200311025749p:plain

f:id:kasasagi_f:20200311030832p:plain

f:id:kasasagi_f:20200311030106p:plain
このことから、logの中身そのものではなく、OSやlogコマンドの仕様変更が原因だと仮説を立てました。また、log show初回実行時の警告文から、Catalinaで処理できないlogarchiveは古い形式(Ver.4以前 3?)であるのではないかと考えました。

Based on this, we hypothesized that the cause was not the .logarchive itself, but a change in the specifications of the OS and the log command. Also, from the warning message at the time of the first execution of log show, I thought that logarchive that can not be processed by Catalina may be in old format (Ver.3 ?).

次に、もう一度同じ検証を繰り返し、このlog showコマンドがきくアップデート後のlogarchive(--force後)と、うまくいかないアップデート前のlogarchive(--force前)の内容物を比較すると、うまくいくケースのlogarchiveにはinfo.plistと言うファイルがあることに気づきました。(また、log collectというコマンドを使用するとCatalina上でも解析可能な.logarchiveが作成されるので、これと、log showコマンドが効かない.logarchiveも比較してみましたが、同じくlog show可能な方にはinfo.plistが存在することを確認しました)

Next, we repeated the same verification again, and compared the contents of logarchive (before --force) where the log show command works, and logarchive (before --force) before the update that did not work. Then I noticed that a successful logarchive had a file called info.plist. (In addition, I know that using the command "log collect" creates a .logarchive that can be analyzed on Catalina. And, I also confirmed that info.plist exists in it.)

f:id:kasasagi_f:20200311032038p:plain

--force前

f:id:kasasagi_f:20200311032115p:plain

--force後

このファイルはxml形式のplistで、中には下記のようなキーや値が格納されていました。

This file was an xml format plist, which contained the following keys and values.

f:id:kasasagi_f:20200311032429p:plain

--force後に作成されたinfo.plist

f:id:kasasagi_f:20200311033301p:plain

log collectコマンドで作成した.logarchiveの中のinfo.plist(抜粋)

今回の検証の目的は、証拠保全やTriageしてきたファイルからもlogコマンドで解析する方法を探すことなので、このinfo.plistを人工的に作り出せば解析可能なlogarchiveになるのではないかと考え、このinfo.plistに必須と思われる要素を探しました。
1つ1つkeyや値を削除して、logコマンドで解析可能か確認し、なくてはならない要素を絞り込みました。その結果、--force後のinfo.plistの内容を追加することでCatalinaのlogコマンドでも解析可能な.logarchiveファイルになることがわかりました。(実際は、--force後のplistの中身がミニマムであろうという見立てを立て、その後そうじゃない可能性を検証しました)

The purpose of this verification is to find a way to analyze the log command from the files that have undergone evidence preservation and triage, so we thought that if this info.plist was created artificially, it would be a logarchive that could be analyzed. I looked for elements that seemed to be required in info.plist.
Each key and value were deleted in order, and the log command was used to check whether it could be analyzed, and the essential elements were narrowed down. As a result, it was found that by adding "contents of info.plist after --force", it becomes .logarchive file that can be analyzed even by Catalina's log command.

【追記】[add]:2021/01/18
こちらのリンクにある様に、info.plistの中身のOSArchiveVersionは4にすると時間がずれる為、2が良いとの事でした。我ながらこのブログの間違え率高いですね。そして、去年はinputもoutputもかなり怠っていたのでそれも悔やまれます。申し訳ございません。
As you can see in this link, the OSArchiveVersion in the info.plist should be 2, because the time is shifted if it is 4. I have a high rate of mistakes in this blog. I also regret that I neglected to do input last year. I also apologize for that.
【要確認のより詳細な検証結果】[confirmation required]
https://www.mac4n6.com/blog/2020/4/20/analysis-of-apple-unified-log-quarantine-edition-entry-1-converting-log-archive-files-on-1015-catalina

 

あらゆるCatalinaで試したわけではないですが、いくつかの環境では同様のinfo.plistをlogarchiveの中に追加する方法で、logコマンドで解析不能なlogarchiveを解析可能な状態にすることができました。
log showの結果に、"log: warning: The log archive contains partial or missing metadata"というメッセージが出ていたり、log collectの中には他にも沢山のデータがあるので欠損などが生じないか注意は必要ですが、この方法を用いれば全く調査できないという事態は回避できそうに見えます。

Although I did not try with a lot of Catalina, in some environments it was possible to make a logarchive that could not be parsed with the log command parseable by adding a same info.plist to the logarchive .
In the result of log show, the message "log: warning: The log archive contains partial or missing metadata" appears, and there is a lot of other data in log collect, so be careful if there is any loss etc. It is necessary, but it seems that using this method can avoid a situation where no investigation is possible.

【追記】[add]:2021/01/18
前述の様にOSArchiveVersionは2の方が良さそうです。
The OSArchiveVersion should be set to 2.


【考察】[Consideration]
これは、恐らくlogコマンドが対応しているlogarchiveのフォーマットに起因すると思われます。
先述の通り、mojaveにおいて、info.plistがない.logarchiveを使用する場合は、「Version4にアップデートする必要があります」と言ったエラーが出てくる為、info.plistがないものはVer.3かそれ以前のものであったようです。
しかし、CatalinaからはVer.4しか受け付けてくれず、かつVer.4へのアップデート機能もなくなったので、log showで内容の閲覧ができなくなったのではないかと思われます。
その為、info.plistに「OSArchiveVersion」が「4」という設定を入れて、logarchiveに混ぜ込めばVer.4と認識され、処理可能になったのではないでしょうか。

This is probably due to the format of the logarchive supported by the log command.As mentioned above, when using logarchive without info.plist in mojave, an error stating "It is necessary to update to Version 4" appears. It seems to have been the previous one.
However, since Catalina only accepted Ver.4 and the update function to Ver.4 was also lost, it seems that the contents could not be viewed with log show.
Therefore, if you set "OSArchiveVersion" to "4" in info.plist and merge it with logarchive, it will be recognized as Ver.4 and it will be possible to process it.

From next time, I would like to introduce my recently announced self-made tools for mac4n6.

【追記】[add]:2021/01/18
OSArchiveVersionは2でも良さそうなので、この仮説は間違っている様です。
This hypothesis seems to be wrong, since OSArchiveVersion can be 2.

 

macOS上に現存するappの痕跡?-appList.datについて- [Trace of app path on macOS -About appList.dat-]

※This is a very simple first report, there is the possibility of including mistakes.
 We need further verification.

ご存知の方もいらっしゃるかもしれませんが、今回も調査に役立つかもしれないアーティファクトを見つけたので、今わかっていること(こうだと思っていること)や私がこれを見つけた経緯、ちょっとした検証や考察などについて書きます。

Some of you may know, I found an artifact that might be useful for investigation.
So I wrote about what I know now (what I am thinking), how I found this, some verifications, and considerations.

 

【解析対象ファイルの場所】[Location of files to be analyzed]
/Users/$USER/Library/Application Support/com.apple.spotlight/appList.dat

 

【わかること】[What we can know]
現存するappのパス。

The app path. 

 

【意義】[How it can be useful for investigation]
このアーティファクトは、アプリインストールに関わる既存のアーティファクトとして知られる"/Library/Receipts/InstallHistory.plist"と比較すると、より多くの.appの情報を保持している可能性があります。
InstallHistory.plistは、インストーラで「インストールを行ったapp」の情報を保持している様ですが(ただし、何らかの条件によりインストーラでインストールしてもここに残らない場合もあるように思えます)、appList.datでは単純に「appのパス」を記録している様に見えます。
その為、Visual Stadio Codeの様なappをApplicationsディレクトリに配置するだけのタイプのアプリだとInstallHistory.plistには記録が残されていないのですが、appList.datには残されているというパターンもありそうです。
ただし、残念ながら手元の検証では、appを削除した場合このアーティファクトの該当レコードも削除される為、app削除による証拠隠滅の影響を受けるかもしれません。

This artifact may hold more .app information than "/Library/Receipts/InstallHistory.plist", known as an existing artifact related to app install.
InstallHistory.plist seems to hold the information of the app that "installed" via installer(However, it seems that it may not remain here even if installed via installer due to some other condition), but appList.dat seems to record "app path".
Therefore, if it is a type of app that simply places an app such as "Visual Stadio Code" in the Applications directory, it is not left in InstallHistory.plist, but there is also a pattern that it is left in appList.dat.
However, unfortunately, in the verification at hand, if the app is deleted, the corresponding record of this artifact is also deleted, so it may be affected by the destruction of the evidence by deleting the app.

 

【見つけた経緯・検証】[Background and verification found]
JSACのCFP応募に向けて作成中だったMac Forenscisのツールの作成課程において、appList.datという名前的にアプリケーションリストではないかと思われる、ファイルがあったので、中身を見てみることにしました。
まずはじめに、fileコマンドでファイルの形式を確認します。その結果、このファイルはApple binary property listであることがわかりました。

In the process of creating a Mac Forenscis tool that was being created for JSAC's CFP, there was a file named appList.dat, which seems to be an application list, so I decided to take a look inside .
First, check the file format with the file command. As a result, this file was found to be an Apple binary property list.

f:id:kasasagi_f:20190916165810p:plain

 Apple binary property listはいわゆるplist(Mac OSの設定ファイルの様なもので、Windowsでいうレジストリのキーがバラバラになって散っているイメージ)のバイナリ形式のもので、「plutil -p "file"」で中身を表示することができます。このコマンドで中身を見てみます。

Apple binary property list is a binary format of plist (like a Mac OS configuration file, an image in which Windows registry keys are  scattered),
"plutil -p file“ The contents can be displayed with. Let's look at the contents with this command.

f:id:kasasagi_f:20190916173637p:plain

f:id:kasasagi_f:20190916173922p:plain

この形式は、見たところデータ冒頭(上の画像)の赤枠内にある通り「NSKeyedArchiver format」と呼ばれる形式ではないかと考えられます。詳細なデータの辿り方は、既にまとめられているサイトがあるのでこちらをご参照ください。(今回のものは少し参考サイトと雰囲気が違うようですが)
https://www.mac4n6.com/blog/tag/ccl_bplist.py  

This format seems to be a format called “NSKeyedArchiver format” as shown in the red frame at the beginning of the data (top image).
For details on how to follow the data, please refer to the site.(This time is a little different from the reference site)

上記の画像内のデータの見方を簡単に説明すると(多分こうだというものですが)、
「"displayName" => <CFKeyedArchiverUID 0x7fd9e9f08d60 [0x7fff9a11f8e0]>{value = 3}」とあるので、その下にある3をみると「3 => "iTerm.app"」とあり、「"displayName" = "iTerm.app"」となり、iTermというappの情報が記載されていることがわかります。
同じように「"URL" => <CFKeyedArchiverUID 0x7fd9e9f08d40 [0x7fff9a11f8e0]>{value = 5}」を辿っていくと、「"NS.relative" => <CFKeyedArchiverUID 0x7fc2fbf04100 [0x7fff9a11f8e0]>{value = 6}」から「 6 => "file:///Applications/iTerm.app/"」という箇所にたどり着き、"iTerm.app"は「"file:///Applications/iTerm.app/"」にあることを示すように見えます(実際には複数のappの情報が格納されているので、ちゃんと全てのデータを紐づけようとするともう少し複雑ですが)。

Briefly explaining the data in the above image.(Maybe like this)
You can see ["DisplayName"=> <CFKeyedArchiverUID 0x7fd9e9f08d60 [0x7fff9a11f8e0]> {value = 3}]".
So if you look at "3" below it, you can see [3 =>"iTerm.app"] .
It means ["displayName"= "iTerm.app"] .
So you can see that the app information is called iTerm.
In the same way, if you follow ["URL"=> <CFKeyedArchiverUID 0x7fd9e9f08d40 [0x7fff9a11f8e0]> {value = 5}, go to "NS.relative" => <CFKeyedArchiverUID 0x7fc2fbf04100 [0x7fff9a11f8e0]>{value = 6}, finaly you will reach [6 => "file: ///Applications/iTerm.app/]. 
"ITerm.app" appears to indicate that it was in "file: ///Applications/iTerm.app/".
(In fact, since multiple app information is stored, trying to link all the data properly is a bit more complicated)

「plutil -p "/Users/$USER/Library/Application Support/com.apple.spotlight/appList.dat" | grep -i file」というようにすれば、appのパスの一覧を取得できます。

"Plutil -p "/ Users / $ USER / Library / Application Support / com.apple.spotlight / appList.dat "| grep -i file" can be used to get a list of app paths.

f:id:kasasagi_f:20190916201529p:plain

ここから、上記仮説の妥当性やその他の挙動を検証していきます。
手順は下記の通りです。

・検証1(存在していなかったapp作成によるappList.datの変化を検証)
1.現在のappList.datのデータ出力を退避する
2.現在MacbookProに存在していないappであるBlockBlock(https://objective-see.com/products.html)のインストーラをDownloadし、unzipする
3.appList.datのデータ出力を1と比較する

・検証2(既にappList.datに追加されているappを別の場所にコピーした際のappList.datの変化及び、記録されているappを削除した際の挙動を検証)
1.現在のappList.datのデータ出力を退避する
2.既にappList.datにも記録があるKnockKnock.appをユーザのApplications(日本語だと「アプリケーション」)からDesktopにコピーし、Applications内のKnockKnock.appを削除する。
3.appList.datのデータ出力を1と比較する

From here, I will examine the validity of the above hypothesis and other behaviors.
The procedure is as follows.

・ Verification 1 (Verify appList.dat changes due to app creation that did not exist)
1. Save the current appList.dat data output.
2. Download the installer of BlockBlock (https://objective-see.com/products.html), an app that does not exist, and unzip it in the directory.
3.Compare the data output of appList.dat with 1. 

・ Verification 2 (Verify changes in appList.dat when copying an app that has already been added to appList.dat to another location, and verify the behavior when deleting the recorded app)
1. Save the current appList.dat data output.
2. Copy KnockKnock.app that is already recorded in appList.dat from Applications to the Desktop, and delete KnockKnock.app in Applications.
3.Compare the data output of appList.dat with 1.

 

検証1 [Verification 1]

検証用MacbookPro内に無いappであるBlockBlock(https://objective-see.com/products.html)のインストーラ(BlockBlock_0.9.9.4.zip)をダウンロードしてきます。
Downloadしてきてzipを解凍する前のappList.datの中には、blockを含むものはありません。

Download and unzip BlockBlock (https://objective-see.com/products.html) installer (BlockBlock_0.9.9.4.zip) which is an app that is not in MacbookPro for verification.
In appList.dat before downloading and unzipping zip, there is nothing that contains block.

f:id:kasasagi_f:20190916185642p:plain

BlockBlock_0.9.9.4.zipをunzipしBlockBlock Installer.appを取り出してから約1分後のappList.datの中には、BlockBlockのapp名やパスが追加されています。

After unzipping "BlockBlock_0.9.9.4.zip" and taking out "BlockBlock Installer.app", app name and path of BlockBlock are added in appList.dat about 1 minute after.

f:id:kasasagi_f:20190916185718p:plain

以上のことから、appのアプリ名やパスがappList.datに追加されていそうだということがわかりました。この他に別のappでも検証を行いましたが、同様の結果が得られました(検証数は多くないのでまだ注意は必要です)。

From the above, it was found that the app name and path of apps seems to have been added to appList.dat.
In additional verification, similar results were obtained (the number of verifications is not large, so attention is still needed).


検証2[Verification 2]
既にApplicationsディレクトリに追加して使用していたKnockKnock.appに関する、appList.dat内の現在のgrep結果を表示します。

Displays the current grep result in appList.dat for KnockKnock.app that was already added to the Applications directory.

f:id:kasasagi_f:20190916194330p:plain

このKnockKnock.appをDesktopにコピーします。
すると、1-2分経ってからDesktopにコピーしたKnockKnock.appに関する記述が新たに追加されました。この時点ではコピー前、コピー後どちらの情報も記録されています。

Copy this KnockKnock.app to your Desktop.
Then, after 1-2 minutes, a description about KnockKnock.app copied to Desktop was newly added to appList.dat. At this point, both pre-copy and post-copy information is recorded.

f:id:kasasagi_f:20190916195440p:plain

次に、ApplicationsディレクトリにあったKnockKnock.appを削除します。
すると、1-2分経ってからApplicationsディレクトリにあったKnockKnock.appの記述が消えました。

Next, remove KnockKnock.app from the Applications directory.
Then, after 1-2 minutes, the description of KnockKnock.app in the Applications directory disappeared.

f:id:kasasagi_f:20190916195856p:plain

以上のことから、appList.datには現存するappファイルのパスが残り、appを削除するとそのappファイルに関連するレコードは消えるという挙動をしているように見受けられました。

From the above, it seems that appList.dat has the path of the existing app file, and when app is deleted, the appList.dat record related to that app file disappears.

 

【その他の検証】[Other verification]
また、別途行った検証では、Visual Stadio Codeのようなインストーラによるインストールをしていないappにおいては、「/Library/Receipts/InstallHistory.plist」には情報が存在しないが、「appList.dat」には存在しているものがあることを確認しています。
更に、上記のBlockBlock Installer.appはインストーラでインストールを実施したのですが、InstallHistory.plistにはなぜか記録されていない様子でした。(従って、InstallHistory.plistの記録有無は単なるインストーラ使用の有無だけではなく、インストーラの形式にもよるのかもしれません)

Also, in the verification that I conducted separately, in the app that is not installed by the installer such as "Visual Stadio Code", although there is no information in “/Library/Receipts/InstallHistory.plist”, “appList.dat” seems to be information inside.
Furthermore, the above "BlockBlock Installer.app" was installed by the installer, but it seemed that it was not recorded for some reason in "InstallHistory.plist". (Therefore, whether or not InstallHistory.plist is recorded may depend not only on whether or not the installer is used, but also on the format of the installer.)

 

【感想など】[Impressions etc.]
各appの実行時間があったり、appが削除されていてもアーティファクトが残ればもっと有用だったのですが、残念です。。。
あと、今回は英語を添えたのですがもう少しまともな英語を書けるようにもなりたいですね。。。

It would be more useful if there was an all execution time and if the artifact remained even if the app was deleted.
I added English this time, but I want to be able to write more decent English.

このブログは1年度に1つは新しい発見をしてブログを書くぞというのが目標だったので、今年度も一応は達成できてよかったです。(とはいえまだ半年あるので時間を作ってもう少し役に立ちそうなものを見つけたいですが)

また、当初の検証ではappList.datには実行痕跡が残っていると思っており、某所のLTでそのように話したのですが、追加の検証から、実行しなくてもappが存在さえしていればパスが残るということがわかり、仮説をたてて検証する際に確証バイアスからどう逃れるか(そうじゃない可能性をどこまで検証できるか)ということの難しさを改めて認識しました。

 

【検証OS】 [Verification OS]
macOS 10.14.6(18G95)
macOS 10.15(19A602)

Mac OSXのIME(Imput Method Editor)アーティファクトに関して(About Mac OSX IME Artifact)

※This is a my very simple first report, there is the possibility of including mistakes.
 We need further verification.

ご存知の方もいらっしゃるかもしれませんが、今回も調査に役立つかもしれないアーティファクトを見つけたので、今わかっていること(こうだと思っていること)や私がこれを見つけた経緯、ちょっとした検証や考察などについて書きます。

また、簡単なパーサを書いたのでそちらもご紹介します。

【解析対象ファイルの場所】
/Users/USERNAME/Library/Dictionaries/JapaneseInputMethod/
ディレクトリ下の

  • DynamicBigramPhraseLexicon_ja_JP.db
  • DynamicPhraseLexicon_ja_JP.db
  • LexicalLearning_ja_JP.db
  • NonLexicalLearning_ja_JP.db
    *未確認ですが恐らく日本語環境にしかありません

【わかること】
ユーザが過去に入力した文字列

もう少し詳細を書くと、これは日本語環境のMacで使用されているIME(Input Method Editor)入力の変換履歴ではないかと考えており、「ユーザが入力し変換した(もしくは自動変換された)文字列」が残されているように見えます。「Dynamic」「LexicalLearning」「NonLexicalLearning」といったファイル名などから、自動変換や変換時の精度向上などの為に記録されているものではないかと予測されます。

日本では、アルファベットだけではなく、ひらがな、カタカナ、漢字の3つの形式(適切な表現が他にあるかもしれませんが)の文字を組み合わせて文章を書きます。これらを入力・変換するために使用しているのがIMEです。
下記のように、日本語入力モードで文字を入力すると下線が引かれ一部の文字は自動で変換されます。下線が引かれている状態でスペースキーを押すと、カタカナや漢字に変換できます。この下線が引かれた範囲がdbに記録されるように見えます。

IMEを使用して変換を行うと下記のようになります。

文字を入力すると下線が引かれ、一部の文字は自動で変換されます。スペースキーを押せば右下の変換候補から変換したい変換パターンを選択できます。

f:id:kasasagi_f:20190219232356p:plain

スペースを押して任意の候補に変換

f:id:kasasagi_f:20190219232824p:plain

Enterを押して決定

f:id:kasasagi_f:20190219232705p:plain

 【意義】
このアーティファクトは、IMEを使用して変換をすれば記録されると考えられるので、日本語入力を使っていれば、アプリケーションやブラウザ上のウェブページで入力したものも記録されます。
従って、掲示板やウェブチャット・メールに書き込んだ文字列も残されています。様々な秘匿化の影響を受けない可能性が高い為、他のアーティファクトでは調査困難なことも調べられるかもしれません。
しかしながら、際限なく残ってるわけではないようなので、運が良ければという話にはなります(自分の検証した範囲では、業務等で常時利用しているような端末であれば、1日〜1週間程度かと思います。あまり文章などを書かないという用途であれば多少長く残っていそうです)。

実際に私のMacで検証した結果、自分がテキストエディタ・パワーポイント・Webメール・Slack・Facebook Messenger等で打ち込んだ文字列が記録されていました。

また、現在は日本語環境でしか検証していませんが、他のIMEを使用している環境でも同じような仕組みがあるのではないかと考えられます。

【見つけた経緯・検証】
最近はMacフォレンジックに興味があり、簡単な調査ツールなどを作成していたので、Japan Security Analyst Conference 2019の会場や懇親会で「Macフォレンジックツールで欲しい機能ありますか」と聞いて回ったところ、「IMEみたいな日本独自のアーティファクト系は?」という声を頂いたので、遅くなりましたが先日探してみました。

今回はIMEの記録を探そうと思い意図的に探したので、findコマンド等でIMEと関係のありそうなフォルダやファイルを探していきました。
その中に、dbファイルを見つけた為、何らかの記録データが格納されているのではないかとあたりをつけてSQLite Viewerで中身を確認しました。(下記の例ではDynamicPhraseLexicon_ja_JP.dbを対象にしています)

f:id:kasasagi_f:20190220223741p:plain

f:id:kasasagi_f:20190220225751p:plain

すると、

FirstSurface SecondReading SecondSurface

 などのカラムに何らかのバイナリが入っていることを確認し、バイナリエディタへコピーして読める文字にならないか確認しました。

その結果、UTF-16(Little Endian)で変換すると日本語に戻ることを確認しました。

下記の18 8a 32 93を例にします。

f:id:kasasagi_f:20190221003806p:plain

これをHex Fiend(バイナリエディタ)に貼り付け、UTF-16(Little)で表示すると
「記録」になります。
(解析気分を味わいたければ、2バイトづつ逆バイトオーダーで取り出し上記の例でいうと8a 18 93 32に並び替えてUTF-16(Big Endian)に変換しても良いです。また、何れにせよサロゲートペアの文字だとこのような単純なやり方で戻すのは難しいかもしれません)

f:id:kasasagi_f:20190223165244p:plain

f:id:kasasagi_f:20190223165412p:plain
全て手で戻すのは面倒なので、pythonで簡単なスクリプトを書きました。
このスクリプトを用いると、バイナリの箇所だけ日本語に変換した状態でテーブルの内容をcsvに書き出すことができます。
(プログラミングが得意はわけではないので、拙いものですが。。。)

GitHub:
https://github.com/fkasasagi/OSX_IME_Parser

使い方(python3のみ対応):
python osx_ime_parser.py -f DynamicBigramPhraseLexicon_ja_JP.db

以下が実行ディレクトリに作成されるアウトプットです。

f:id:kasasagi_f:20190221013344p:plain

ファイル名は処理した「ファイル名_ファイルの更新時間.csv」です。

検証用に文字を打ち込んで半日ほど経った後、ツールを使い、できたcsvexcelで開くと下記のような感じでした。

  • DynamicBigramPhraseLexicon_ja_JP.db
    FirestSurfaceに最初に打ち込んだ文字、SecondReadingにFirestSurfaceの後に続く言葉の変換前、SecondSurfaceにSecondReadingの変換後の文字が入っているように見えます。その他のカラムの中身も謎です。私が検証用に入力した文字が残されていました。「入力するとカタカナや漢字に変換できます」と自然に打ったのですが、何気なく打ったので、「に」だけ入力後変換せずにエンターを押してしまい結果抜けているように見えます。「Dynamic」とあることから、自動変換などに関連があるのではないかとも予想されます。もう一度しっかり記録をとって細かい検証をしたいところです。

f:id:kasasagi_f:20190221005916p:plain

  • DynamicPhraseLexicon_ja_JP.db
    Readingに変換前、Surfaceに変換後の文字が記録されているように見えます。その他のカラムの中身は謎です。私が検証用に入力した文字が残されていました。
    こちらも「Dynamic」とあることから、自動変換などに関連があるのではないかとも予想されます。

f:id:kasasagi_f:20190221010344p:plain

  • LexicalLearning_ja_JP.db
    Readingに変換前、Surfaceに変換後、LeftSurface1にSurfaceの直前の文字、LeftSurface2にLeftSurface1前の文字が記録されているように見えます。
    その他のカラムの中身は謎です。私が検証用に変換した文字が残されていました。ファイル名から、語彙を学習し変換等に役立てているのでしょうか。

f:id:kasasagi_f:20190221010825p:plain

  • NonLexicalLearning_ja_JP.db
    謎です。

f:id:kasasagi_f:20190221011017p:plain

現在作成中のMac Forensicsをもっと楽にする簡素なGUIを持ったpythonツールにも組み込む予定です。(こちらはいつリリースできるかわかりませんが)

 

【その他】
下記のこともまだわかっていません
・自動変換された場合とスペースキーで手動変換した場合の差
・DBが更新されるタイミング
・記録されるものと記録されないものを決める条件が他にあるか
・どの程度の数(または量)の変換記録が残されているか
MacのどのVer.からこのアーティファクトはあるのか 

【検証OS・使用ツール】
Mac OS Mojave Ver.10.14.3 on MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
・DB Browser for SQLite Ver.3.10.1
・Hex Fiend Ver.2.8 (1517561380)
OSX_IME_Parser Ver.01(https://github.com/fkasasagi/OSX_IME_Parser)


*前回のbamに関してのブログから1年が経ちましたが、辞めた訳ではありません。
  細く長く自分のペースでやっていくつもりです。

bam キー(実行痕跡?) について(2) & レジストリのトランザクションログ

前回の投稿でbamキーについて記事を書いた後、twitter宛にいくつかのメッセージを頂きました。

いつの間にか海外のフォレンジックコミュニティーにも記事の内容が共有され、様々な議論が交わされて、何名かのフォレンジッカーがこのキーについて追加の検証を行い結果を共有してくれました。

頂いたメッセージは、「良くやった!」というものから誤りを指摘してくれるものまで様々ありましたが、どれも私にはとても価値がある嬉しいものでした。

今回は、その中であった素晴らしい指摘や、それを元に行った簡単な追加検証の結果などについて共有したいと思います。

 

まず、bamキーに関する前回からの大きな更新点は、レジストリファイル(SYSTEM)上のbamキーの値が更新されるタイミングについてです。

私は、前回の検証において「シャットダウン時にレジストリファイルが更新される」と書きましたが、これは間違いでした。(シャットダウン時にも更新されますが、他にも条件があります)

この点に関しては、@errno_fail 氏から下記の様な指摘があり、今回再検証したところ一定の時間が経てばレジストリファイルが更新されることを確認しました。

https://twitter.com/errno_fail/status/967831155310518272

※こちらも合わせてご参照ください。非常に価値の高い資料です。

https://github.com/msuhanov/regf-samples/blob/master/8.1-unreconciled/Flush strategies in the Windows registry.md

https://support.microsoft.com/ja-jp/help/2784761/saving-application-registry-changes-on-windows-8-or-windows-server-201

 

この指摘(及びこれを元に派生するtwiitter上の議論、上記の2つの記事)によると、

Windows 8.1以降では、bamキーに関わらず全レジストリへの変更は、変更時に一度全てレジストリトランザクションファイル(レジストリファイルと同じフォルダにある"{HIVE名}.LOG*")に書き込まれ、その後ユーザが非アクティブになる、シャットダウンなどでハイブがアンロードされる、最後のレジストリファイルへの書き込み後1時間経過する、など一定の条件をトリガーにレジストリファイルへ書き込まれるため、レジストリファイルへの書き込みには遅延が発生すると書かれている様にみえます。(英語力やフォレンジック知識の不足で間違っていたらすみません。誤りをご指摘頂けたら嬉しいです)

従って、これが事実であれば、静的なレジストリファイルを解析する際は、状況に応じてこれらのトランザクションログファイルを一緒に取得・解析する必要があると考えられます。自分が普段使っているファストフォレンジック用の収集ツールがこれらを収集する仕様になっているか確認し、いざという時の収集手段を準備しておく必要がありますね。

 

 

このトランザクションログの処理を踏まえて、bamキーのレジストリファイルへの書き込みについて、簡単に追加検証をしてみました。

 

まず、現在bamキーにないx64dbgを起動します。

f:id:kasasagi_f:20180305233509p:plain

次に、regeditでbamを確認。 x64dbgの実行記録が残っています。

f:id:kasasagi_f:20180305233357p:plain

 

FTK ImagerでレジストリファイルとトランザクションログファイルをExport(※)し、Registry Explorer v1.0.0.0で確認します。

(このRegistry Explorer v1.0.0.0は、レジストリファイルに反映されてないトランザクションログの存在を検知し、更にトランザクションログファイルの内容を反映することができる優れものです。更に、bamキーの記事が話題になった翌朝にはbamキーとそれによく似た痕跡の残るとされるdamキー(Desktop Activity Moderator? でしょうか。残念な事に私の環境ではこのキーの中に有用な情報は見つかりませんでした)のプラグインを完成させるなど、作者のEric Zimmerman氏の仕事には驚愕させられます)

 

SYSTEMファイルをロードすると、ダーティー(まだ反映されていないレジストリトランザクションログがある状態)であることを検知し警告が出てきます。トランザクションファイルの内容を取り込むか聞かれますので、「YES」を選択します。

f:id:kasasagi_f:20180305233424p:plain

f:id:kasasagi_f:20180305233430p:plain

 取り込みたいトランザクションログファイルを選択します。

f:id:kasasagi_f:20180306004435p:plain

次に、取り込んだトランザクションログの内容を反映した新しいレジストリファイルを保存する場所を聞かれるので、任意の場所を指定します。この例だとSYSTEM.LOG1を指定したので、保存名もSYSTEM_LOG1にしました。

f:id:kasasagi_f:20180306004614p:plain

f:id:kasasagi_f:20180306004407p:plain

保存した新しいレジストリファイルをロードするか聞かれるので「YES」を選択します。

f:id:kasasagi_f:20180306005026p:plain

トランザクションログを反映前のダーティーなファイルもロードするか聞かれます。今回は比較のため「YES」を選択します。

f:id:kasasagi_f:20180306005303p:plain

トランザクションログ反映前(上の"SYSTEM")とトランザクションログ反映後(下の"SYSTEM_LOG1")が下記のようにロードされます。

f:id:kasasagi_f:20180306005611p:plain

上の"SYSTEM"のbamキーを見ると先ほど実行したx64dbgの実行痕跡は反映されていませんが、下のトランザクションログを反映した"SYSTEM_LOG1"を見るとx64dbgの実行痕跡があります。

f:id:kasasagi_f:20180306011147p:plain

f:id:kasasagi_f:20180306011201p:plain

ということで、レジストリの変更(トランザクションログの内容)がレジストリファイルへ書き込まれる前にレジストリファイルを取得した場合は、Registry Explorer v1.0.0.0等を使用してトランザクションログをレジストリファイルに反映させることで、最新状態のレジストリを調査することが可能になるようです。

 

 

さて、次なる疑問は、果たして実際にこの後どのくらい時間が経ったらレジストリファイルにこのトランザクションログの内容が反映されるかという点です。

x64dbgを実行後、10分ごとにレジストリファイルのエクスポートと確認を行い、レジストリファイルに変更が適用されるまでの時間を観測してみました。(もっと楽で適切な方法があるのではないかとも思いますが、今回は原始的な方法でやりました)

VMのスナップショットでx64dbgの実行前に戻してから、再びx64dbgを実行し経過観察という流れを2回実施し、その後他のPCでも同様の検証を1回実施してみました。(なお、検証中はForensic Lunchを見るなどしてずっとPCを使用し続けました)

 

1回目の検証(スナップショットを戻してすぐx64dbgを実行)

10分後、、、、変更なし

20分後、、、、変更なし

30分後、、、、変更なし

40分後、、、、変更なし

50分後、、、、変更なし

1時間後、、、、変更されている!

 

2回目の検証(再度スナップショットを戻して1日程度放置した後)

10分後、、、、変更なし

20分後、、、、変更されている!

 

3回目の検証(別のPC)

10分後、、、、変更なし
20分後、、、、変更なし
30分後、、、、変更なし
40分後、、、、変更されている!

 

ということで、私の手元では、1回目は50分-1時間、2回目は10-20分、3回目は30-40分の間にレジストリファイルが更新されたという結果でした。環境間での差ももちろん、同じ環境でもタイミング次第で、レジストリ(bamキー)への変更内容がプライマリのレジストリファイルに反映されるまでの時間には結構差がありました。

(別途、スクリーンセイバーにしたりサインアウトしたりする検証もしましたが、これによってレジストリファイルへの更新が即時にされるわけではありませんでした。ユーザが非アクティブになった際にはトランザクションログがレジストリファイルに反映されるとのことなので、サインアウトした際には更新が行われると思ったのですが、私の手元ではそのような結果は得られませんでした。更なる検証が必要かもしれません)

 

従って、やはり検証の結果からも、私が前回の記事で記載した「シャットダウン時にレジストリファイルが更新されるのではないか」というのが誤りだとわかりました。
時間が経てばシャットダウンなしでもレジストリファイルに反映されます。

誤った情報を発信してしまったことを謝罪致します。しかしながら、今回の記事のようにそこから学べることもあるので、失敗を恐れずに引き続き検証などを続けていきたいと思います。これは見習いフォレンジッカーのメモですので。

 

 なお、同様のRegistry Explorerを使用した検証は下記のブログでも行われています。

いつもながら素晴らしい内容です。

http://port139.hatenablog.com/entry/2018/03/03/110202

 

検証使用ツール:

・registry
 →Registry Explorer v1.0.0.0

 →Registry Editer(regedit)

・registryの抽出

 →FTK Imager Ver.3.4.0.1
(※ 私の手元ではExportした.LOG*ファイルは属性がHSAなのでRegistry Explorerでうまく読み込むことが出来ず、同じディレクトリに2度Exportして作成された.LOG*.copy0(属性がAのみ)をリネームして.LOG*にすると読み込めました。attribコマンドを使って属性変更した方が早いかもしれません。)

・検証環境

 →Windows 10 Pro 1709 on VM

 

 

 

bam キー(実行痕跡?) について(最終更新:2018/02/28 00:15 JST)

※This is a my very simple first report, as many people have pointed out, there is the possibility of including mistakes. We need further verification.更新:2018/02/27 22:00 JST

 

ご存知の方もいるかもしれませんが、
調査に役立つ可能性のあるレジストリキーをみつけたので、
今わかっていること(こうだと思っていること)や私がした簡単な検証について書きます。ただし、あくまでまだ検証段階です。

 

キーの場所:HKLM/SYSTEM/CurrentControlSet/Services/bam/UserSettings/{SID-RID}

わかること:簡単に言うとUserAssist({CEBFF5CD-ACE2-4F4F-9178-9926F41749EA})のようなexeの実行痕跡があるように見えます。

 

もう少し詳細を書くと

・exeを実行すると実行ファイルのフルパスと最終実行日時が残る(Keyの「Data」値の先頭に最終実行日時と考えられるタイムスタンプがある(Windows 64bit Hex Value -Little Endian))
シャットダウン時にSYSTEMファイルに書き込みされる

といった決まりがあるように見受けられます。

→下記のレジストリファイルへの書き込みタイミングに関する考察によれば、これは誤りで時間が経てば更新される可能性がありますので、更なる検証が必要です:参考 

github.com

更新:2018/02/28 00:15 JST

 

 

経緯:

時折、検証がてらレジストリ全体に対し自分が実行したプログラムの実行ファイル名で検索をかけたりするのですが、ある時見慣れないキーにFTK Imagerの実行ファイル名があることに気付きました。同じキーの他の値をみてみると、実行痕跡のようなものに見えます。もしそうなら、CCleanerなどを使われても消えない有用なアーティファクトになるかもしれません。→検証してみませう

f:id:kasasagi_f:20180221215616p:plain

 

検証:

これがもし実行痕跡だった場合は、実行時間が欲しいところなので、そこから探ります。とりあえず、パッと見で「Data」値の先頭に8個のHEX Valueがあります。

これは何だか手が勝手に動くやつですね。

f:id:kasasagi_f:20180221220422p:plain

 

DCODE(Decode)すると、我々の世界の時間として受け入れ得る値がでてききました。
(2018/02/20 04:11:51(UTC))

f:id:kasasagi_f:20180221221410p:plain

 

果たしてこれは実行時間なのでしょうか?
もし最終実行時間であれば、再びFTK Imagerを起動すれば更新されるはずです。

 

と思いFTK Imagerを起動後、SYSTEMファイルをExportし再度確認しましたが、値は更新されませんでした。

 

今度は試しにbamに現在実行痕跡のないWRR.exeを実行し、SYSTEMファイルの変化をみてみます。。。

→が、同様に値に変化なし。。。

 

泣きながらRegeditを起動して現在のbamキーをみてみます。

→あれ、WRR.exeが追加されている(Dataに今さっき実行した実行時間も入っている!)

 

もう一度SYSTEMファイルをExportしてWRR.exeを確認。

→WRR.exeの痕跡なし。

f:id:kasasagi_f:20180221224903p:plain

 

あれ、これあれか、AppCompatCacheパターンか!(シャットダウン時にレジストリファイルに書き込まれる)

ということで、再起動後SYSTEMファイルをExportしbam配下のFTK Imager.exeやWRR.exeの痕跡を確認します。

→やはりFTK Imager.exeの「Data」値が実際にシャットダウン時点で最後に実行した時間(※)になっている!

f:id:kasasagi_f:20180221232935p:plainf:id:kasasagi_f:20180221233247p:plain

 

→WRR.exeがSYSTEMファイル内にある!(Dataに今実行した実行時刻も入っている!)

f:id:kasasagi_f:20180221231037p:plain

f:id:kasasagi_f:20180222095332p:plain

 

ということで、どうやらシャットダウン時にexeなど一部のファイルの実行パスと最終実行時間がこのbam下のキーに書き込まれているようにみえます。

上記の通り誤りである可能性があります。時間が経てば値が更新される可能性があります。 更新:2018/02/28 00:15 JST

 

※bam配下の最終実行時間は、同行為によって発生したと思われるUserAssistやPrefetchの実行日時の痕跡とかなり近い日時でした。逆をいえば少しだけ違うということでもありますがWindowsって割とこんなノリな気もします。

・bam配下のFTK Imagerの最終実行時間?:2018/02/21 13:34:12(UTC)
・UserAssistのFTK Imagerの最終実行時間:2018/02/21 13:33:23(UTC)
・PrefetchのFTK Imagerに関する同タイミングの実行日時:2018/02/21 13:33:21(UTC)

f:id:kasasagi_f:20180221235511p:plain

f:id:kasasagi_f:20180222001206p:plain

(FTK Imagerは再起動後もレジストリファイルの出力に使ったのでPECmdの結果は直近の実行時間ではないですが、確かに過去その時間に実行された記録が残っています) 

 

bamとは何か?:

何かの答えにはなっていないかもしれませんが、これではないかと思っています。
Background Activity Moderator Driver (bam) Service Defaults in Windows 10

 

意義:

アンチフォレンジック(CCleaner等)によりUserAssistの値などが削除された際に多少の代替手段になるかもしれませんね。

 

その他:

・USERASSISTに近いものが残っているように見えるが、数は少ない

・一部のプログラム(Background Activity Moderator ?だけあってタスクマネージャーでみたときにバックグラウンドプロセスにいるようなプログラム?)に関しては、タイムスタンプ更新の法則が違う可能性がある 更新:2018/02/23 2:23(JST)
・何がここに記録され、何が記録されないか要検証

手元だと値の内容がかわっても数は57個で固定:時間の古いものなど、消える順番は要検証→これは間違いでした。回数は57個固定ではないようです(皆さん思ったと思いますが、やはりこの回数は変ですよね。) 更新:2018/02/23 0:47(JST)

・よく探すと過去に1人だけbamがDFIRに有効だと言っている人を発見。
Fall Creators Update/Redstone 3からこのアーティファクトは追加された?
Alex Ionescuさん がハッシュタグ #DFIR をつけたツイート一覧 - 1 - whotwi グラフィカルTwitter分析

・DCODEで頑張らなくても、Registry ExplorerのData Interpreterでこの最終実行日時と思しき時間に直してくれる(のを最後にみつける。涙)

f:id:kasasagi_f:20180222023847p:plain

 

検証使用ツール:

・registry
 →Registry Explorer Ver.0.9.0.0

 →Registry Editer(regedit)

・registryの抽出

 →FTK Imager Ver.3.4.0.1

・Prefetch

 →PECmd Ver.0.7.1.0