@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

プログラムの通信履歴を残す

フォレンジック

皆さんの組織では、マルウェア感染したWindows PCが（組織内の）何処と通信したか？、を追跡できるログを取っていますでしょうか？

先日のプログラム実行履歴についてTwitterで呟いたところ「次のトピックはSysmonですねｗ」と Haruyama さんから突っ込みをいただいたので、Sysmon を利用したプログラムの通信履歴保存についてです（笑）

プログラムの実行履歴はWindowsの監査機能を利用する事でセキュリティログに記録する事ができますが、プログラムが何処と通信したかは記録されていません。

いわゆる標的型攻撃、APT攻撃と呼ばれる攻撃では、マルウェア感染した機器を踏み台として、組織内の広い範囲への侵入や情報の搾取が行われます。

この為、被害範囲が広がっているのかを確認するには、マルウェア感染した端末が、何処と通信を行っていたのか？が重要な手がかりになります。

プログラムが何処と通信したかがログに記録されていれば、被害範囲を特定する時間やコストを小さくする事が出来るはずです。（被害範囲を迅速に特定できれば、復旧にかかる時間を短くする事ができ、全体コストを抑えられます）

プログラムの通信履歴を残す方法は幾つか案があるかと思われますが、マイクロソフト社が提供しているSysmon を利用すると比較的簡単にイベントログに通信履歴を残す事ができます。

Sysmon v3.0
https://technet.microsoft.com/ja-jp/sysinternals/dn798348

Sysmon を利用すると、プロセスの実行履歴、ドライバのロード時にデジタル署名とハッシュ値を記録する、ネットワーク通信の記録などが可能になります。

プロセスの実行履歴、ファイル作成日時の変更、ドライバロードに関する記録なども残せますが、これら全てを記録していくとログが膨大になり、正直ノイズだらけになります。

 ノイズが多いログは、調査時に“時間とコスト増加”の原因になります。不要なログは取得しないのが一番です。断捨離が必要になりますので、Sysmonの設定ファイルを利用して、ネットワークの通信履歴以外は取得しないようにフィルタします。

まずは、Sysmonのインストールを行います。コマンドラインから操作する必要がありますが、以下のコマンドを実行します。

Sysmon.exe -i -n

ライセンスの確認ダイアログが表示されますので、確認してください。

インストール時に -n オプションを指定することで、ネットワークのログも取られるようになります。（後から設定ファイルでも変更できます）

現在の状況を確認するには、以下のコマンドを実行します。「Network connection: enabled」となっていることを確認できます。

>Sysmon.exe -c

Sysinternals Sysmon v3.00 - System activity monitor
Copyright (C) 2014-2015 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Current configuration:
- Service name: Sysmon
- Driver name: SysmonDrv
- HashingAlgorithms: SHA1
- Network connection: enabled
- Image loading: disabled

No rules installed

 

この状態でどの様なログが出力されるかは、イベントビューアで確認する事ができます。

イベントビューアを起動し、「アプリケーションとサービス ログ」を開きます。新たな項目として、Microsoft⇒Windows⇒Sysmon があるはずです。

 

次に、設定ファイルを作成します。例えば、ネットワークの履歴だけ取得する場合には以下のような設定ファイルを作成します。（Hostnameの部分はインストールするコンピュータのホスト名を記入しておきます）

<Sysmon schemaversion="2.0">
<HashAlgorithms>md5</HashAlgorithms>
<EventFiltering>
<ProcessCreate onmatch="include" />
<ProcessTerminate onmatch="include" />
<FileCreateTime onmatch="include" />
<ImageLoad onmatch="include" />
<CreateRemoteThread onmatch="include" />
<DriverLoad onmatch="include" />
<NetworkConnect onmatch="include">
<SourceHostname>Hostname</SourceHostname>
<DestinationHostname>Hostname</DestinationHostname>
</NetworkConnect>
</EventFiltering>
</Sysmon>

この設定ファイルを作成しておき、-c オプションの引数として指定します。（インデントがうまくいけてないのと、Webから貼り付けるとうまくいかないケースがあるかもしれません）

>Sysmon.exe -c sysmon_conf.xml

Sysinternals Sysmon v3.00 - System activity monitor
Copyright (C) 2014-2015 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Loading configuration file with schema version 2.00
Configuration file successfully applied
Configuration updated.

 設定ファイルが有効になっているかは以下のコマンドで確認できます。

>Sysmon.exe -c

Sysinternals Sysmon v3.00 - System activity monitor
Copyright (C) 2014-2015 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Current configuration:
- Service name: Sysmon
- Driver name: SysmonDrv
- HashingAlgorithms: MD5
- Network connection: enabled
- Image loading: disabled

Rule configuration (version 1.00):
- ProcessCreate onmnatch: include
- ProcessTerminate onmnatch: include
- FileCreateTime onmnatch: include
- ImageLoad onmnatch: include
- CreateRemoteThread onmnatch: include
- DriverLoad onmnatch: include
- NetworkConnect onmnatch: include
SourceHostname filter: is value: 'Hostname'
DestinationHostname filter: is value: 'Hostname'

 この設定ファイルの例では、ネットワークの項目で Include を指定し、SourceHostname か DestinationHostname のいずれかが自分宛てである場合にログを残すようにしています。

ただ、これでもまだノイズとなるレコードは出ると思いますので、更にフィルタできると良いのですが、Include で IS NOT を併用しても手元ではうまくフィルタできませんでした。

この例では Include をデフォルト指定にしていますが、Exclude をデフォルトにして、ノイズを落とすような条件を設定する方が結果的には良い場合もあるかと思います。

特に定期的に127.0.0.1 宛ての通信が出るなど、無駄なレコードがある場合には Exclude として条件を構築した方がすっきりする印象があります。

最後に忘れずに、sysmon のログサイズを増やしてください。デフォルトでは 65536 KB になっているかと思いますが、環境によっては全然足りないかと思います。

手元のPCでは、5MB/day という感じですので、 一ヶ月約150MB、3カ月程度は遡れるようにしたいとすれば450MB～500MBにサイズを増やしておく必要があります。

クライアントPCであれば500MB程度を消費してもそれほど空き領域を圧迫するということは無いと思われます。

逆にサーバで通信の履歴を取得するのはかなり困難が予想されますので、事前にテストしてから判断いただく必要があると思われます。

サーバ側では、ファイルへのアクセス履歴などを検討した方が標的型攻撃による被害を想定した場合には現実的かもしれません。プロセスの通信履歴を残したとしても、その通信でどのファイルをC&Cへ送ったのか？という事は追跡できませんので、どの様なファイルにアクセスしたか、流出した可能性があるのか？を追跡するには、別途ファイルアクセスの履歴が残されている必要があります。

 

<お願い>

皆さんのご協力があって、目標金額に達したようです！！ありがとうございました！！

 

プログラムの実行履歴を残す

フォレンジック

皆さん、プログラムの実行履歴って取られてますか？

Windows が標準で搭載している監査機能を利用すると、プログラムの実行をセキュリティログに残す事ができます。

具体的にはローカルセキュリティポリシーなどで、「プロセス作成の監査」を有効にすればイベントID 4688 ”新しいプロセスが作成されました。” がセキュリティログへ記録されるようになります。*1

プログラムを起動するたびにレコードが記録されます。ノイズとなる部分もありますが、標的型攻撃などを受けてマルウェアが実行されたか？を確認する際にはログがあれば簡単に特定しやすくなります。

デジタル・フォレンジック的には、プログラムの実行痕跡を確認するという方法もありますが、プリフェッチやらレジストリやらを各種ツールで確認するよりも、イベントビューアで ID 4688 をフィルタして確認した方が早く確実ではないでしょうか？*2

 

イベントビューアならリモートからエンドポイントへ接続してログを確認する事も可能でしょうし、イベントログをSyslogで飛ばしておいてそちらで確認するという方法でも良いかもしれません。*3

 

残念ながらこの監査設定はデフォルトでは有効になっていませんので、別途有効にする必要があります。*4

Audit Process Creation

https://technet.microsoft.com/ja-jp/library/dd941613(v=WS.10).aspx

事故を想定した仕組みを構築する際は、ぜひこの設定を有効にする事を検討いただけると、インシデント対応時により迅速に影響範囲の確認が取れるかと思います。

例えば電子メールにマルウェアが添付されており、PCの利用者が誤って実行したか特定したいケースや、実行した後にどの様なプログラムが実行されたかをログからすぐに確認が出来るはずです。

注意点として、このログはセキュリティログに記録されますので、セキュリティログのサイズをデフォルトよりも大きくしておかないと、ローテーションされてしまう可能性があるという事です。

どの程度のサイズまで増やしておけば良いのか？というのは、実際にログを取得し、どの程度の期間までを残せるかテストした上で決めていただく必要があると思います。例えばざっくり200MB程度に増やしたとしても、最近のPCであればHDDの空き容量としては余裕ではないでしょうか。

 

Windowsの標準機能でもプログラムの実行履歴を残す事が可能ですが、もし資産管理ツールなどが導入されており、そちらでプログラムの実行履歴を残る事ができるのであれば、そちらを使う方法でも良いと思います。低コストで実現できるのであれば、その手段を取るのが一番よいと思います。一部機能的な制限があるとしても、何も取ってないよりは良いと思います。

問題はログのサイズと運用管理という点になると思われますが、一度取得しているログが本当に役立つのか棚卸しを行い、不要なログは削除するなり、取得を止めるなど、セキュリティについても断捨離を行うと追加コストを抑えて改善していける可能性があります。

 

 記録してあると助かる「プロセス作成の監査」ですが、実はこのログだけでは解決できない大きな問題があります。どの様なプロセスが起動したかを確認できますが、そのプロセスが何処と通信したのか？はログに残りません。

標的型攻撃ではマルウェアがPCへ侵入した後、C&Cとの通信を行う、組織内の別のPCや機器へ接続する、などの行動を攻撃者が行いますが、それを追跡するのがプロセスの実行履歴だけでは困難という事です。

起動したマルウェアプロセスが何処と通信していたのか、それが特定できると更に便利だと思いませんか？

 

 

 

*1:Windows vista および Windows Server 2008 のセキュリティ イベントの説明 https://support.microsoft.com/ja-jp/kb/947226/ja

*2:プリフェッチファイルを確認した方が、セキュリティログでポイントを絞る事もできますので、どちらも簡単に把握できるスキルがあると良いとは思います

*3:WinSyslogとEventReporterの組み合わせで簡単に実現できますね

*4:更に詳細にコマンドライン記録を設定する事も最近は可能です

ホワイトリストによる通信制限

フォレンジック

マルウェアへの感染が発覚した場合、該当端末を一時的にネットワークから隔離し、その後、より詳細に調査を行うという手順が一般的に取られるかと思います。

明確な対応手順が決まってない組織では、ネットワークからの隔離後に色々と操作をしてしまい、せっかく残っていた痕跡を消してしまう事があるようです。

「隔離後は触らずに、次の正しい手順を確認する」としていただけると、その後の対応コストを抑える事ができるかもしれません。*1

次の手順として、セキュリティベンダへ連絡する、というのは時間がかかりますので注意してください。窓口へ連絡し、事情を説明したり、守秘義務契約や対応コストの見積もりを取るなどしていれば、すぐに数時間は経過してしまいます。

必要最低限のことは、自組織内で対応できるようにしておかないと、復旧までの時間が長引きコストが増える事になります。

 

ここ最近の流れとしては、標的型攻撃を受け侵入された事が判明した場合には、感染端末の隔離後、上流でネットワークを一旦遮断する方向になりつつあるようです。

昨今、インターネット接続が完全に遮断されると業務への多大な影響（コスト）が発生しますので、いかに早く復旧していくかが課題になります。

事案発生後、一時的に通信を遮断するとして、その後はホワイトリストに従い安全かつ必要な通信は許可する必要があります。例えばWindows Updateや、ウイルス対策ソフトのアップデートなどは行う必要がありますので、それらに対するWebの通信は許可する必要があります。

ただし、マイクロソフト社へのアクセスを全て許可するというのはお薦めできません。過去にTechnetのフォーラムがC&C通信で利用されていた事があったようですので、マイクロソフト社のサイトでも必要最低限な範囲に絞って通信を許可する方が安全です。

その他、過去にはアプリケーションをアップデートする仕組みが悪用されたケースもありますので、アプリケーションの更新であれば全てホワイトリストに含める、というのは危険です。

 

自社のWebサイトやポータルもホワイトリストへ登録する事は危険です。いわゆる水飲み場攻撃では、安全と考えられているサイトが改ざんされ攻撃に利用されるケースがある為です。

例えば、年金機構に関連した報道の中には、攻撃者が侵入した機器でWebブラウザが保存していたパスワードを搾取する事例について紹介がありました。

最近のマルウェアは標的型に関わらず、感染した機器に保存されている認証情報を収集する機能が備わっているようです、該当機器から漏えいした自社のWebサイトに関する認証情報などが悪用されるケースにも備える必要があります。

Webサイトに限らず、メールサーバへのログオン情報や（個人が利用している）SNSに関するアカウント情報なども保存していれば盗まれていきます。

標的型攻撃によるマルウェアに感染した端末では、これらのパスワード変更も急ぎ必要になります。社外サイトの場合にはそこにアクセスしてパスワードを変更する必要が出てきますが、通信が完全に遮断されているとうまく対応できない可能性があります。

この他、クラウド上のストレージなどを含め様々なサービスがある（便利な仕組みは攻撃者も利用する可能性がある）ので、Webの通信だけを考慮しても、ホワイトリストの整備はかなりのコストがかかる事になります。

 

ホワイトリストの厳格な適用とは別に、侵害範囲の特定、侵害されていない安全な機器を素早く確認し、安全性が確認でき、一定の基準をクリアした機器からの通信は許可する基準や仕組みを構築しておけば、復旧に要する時間や全体コストを下げられる可能性があります。

そして、その基準を考慮する際には、端末機器におけるホワイトリストの整備が必要になってきます。

米国では NIST が National Software Reference Library（http://www.nsrl.nist.gov/）としてハッシュ値を公開しています。しかし、日本国内ではこういった取り組みをどこか国の機関が実施し公開しているというのは聞いた事がありません。

日本国内で流通しているOSやアプリケーションなどのハッシュ値を適宜収集、ホワイトリストとして提供されていると役立つと思うのですが、何処もやらないのでしょうか？

 

 

 

*1:ネットワークケーブルを抜いたり、無線LANを無効化する前に、メモリダンプの取得なり、netstat -nab コマンドを実行しておくと、マルウェアプロセスの特定が簡単になるかもしれません。なお、ネットワークケーブルを抜いた後でもプログラムの実行・通信先がすぐに確認できる仕組みを運用しておくのが理想でしょうか。

メールの添付ファイルを実行禁止にする

フォレンジック

年金機構における標的型攻撃による情報漏えい事件を受け、様々な組織で同様のウイルス、マルウェアへの感染が無いか、一斉に点検や対応が行われているようです。

報道発表によれば、一連の攻撃で使われたマルウェアは Emdivi と呼ばれているマルウェアということですが、課題として出てきているのは、「ウイルス対策ソフトで検知できないマルウェアをいかに発見・駆除するか？」という点のようです。

従来は、ウイルス感染が疑われる端末では、まずはウイルス対策ソフトのパターンファイルを最新にし、スキャンを行い検知されたものを駆除するというが基本的な対応手順でした。

頼みの綱であるウイルス対策ソフトが使えない場合、どの様に調べればマルウェア感染を確認する事が出来るでしょうか？

さて、この問題いわゆるパソコン遠隔操作事件でも発生した課題ですよね。あの事件では、犯人が作成した遠隔操作ウイルスを発見できなかった事から、その後は複数のウイルス対策ソフトによるスキャンを実施するようにした県警もあるようですが、果たして見つかるのか？と個人的には素朴に感じた事を思い出します。

もちろん、複数のウイルス対策ソフトを利用しスキャンを行うことで、マルウェアを検出する事が出来る場合もあると思います。

特に、現在各組織が対応を進めていくなかで、新たな検体が発見されればそれはウイルス対策ソフトの開発元ベンダへ提供され、パターンの更新や提供が行われるはずです。これにより、最新のパターンファイルを利用して駆除が可能になるマルウェアもあるはずです。

報道発表があった時点で組織内のPCについて、マルウェアのスキャンを行い何も出なかったから安心している組織は、そろそろ最新パターンでスキャンしてみると良いかもしれません。

以前は発見されていなかったマルウェアが新たに発見できる可能性もありますので、報道発表があった段階でスキャンしたから大丈夫！、とは思わず、時間の経過と共に検出される可能性について考慮しておく必要があると思われます。

「最新のパターンファイルでスキャンし、何も無かったので大丈夫です」と上司へ報告してしまってから、後日、マルウェアを検出すると言い訳が大変そうです。（元々ウイルス対策ソフトでスキャンしても見つからないと言われているのに、スキャンして何も無いから大丈夫としてしまうところに無理があると思いますが）

 

また、いわゆる標的型攻撃と訳されるこの攻撃ですが、元々は APT という表現をされる攻撃タイプかと思います。「Advanced persistent threat」というのが元々の単語ですよね。

英語に弱い私はうまくニュアンスを取れていないかもしれませんが、注目すべき単語は「persistent」だと思われます。この単語の意味を調べると「しつこい」とか「根気強い」などの訳文が表示されるはずです。

つまり、攻撃者（個人か組織かは不明ですが）は継続して攻撃を仕掛けてくるというところに特徴があるわけで、終わりが何時か分からないということです。マルウェアは一時的に駆除できても、攻撃者を駆除する事はできません。

せめて綺麗なお姉さんが、生活苦をなんとかするため、怖い人に脅されて日々せっせとマルウェアを添付したメールを書いて送りだしている...とでも想像したいところです。

 

攻撃者側もウイルス対策ソフトが標的組織で使われている事はよく知ってるでしょうから、ウイルス対策ソフトで検知されないように改良してきます。

これにより、ウイルス対策ソフトを最新パターンファイルで利用していたとしても、感染し侵入されてしまうところに厄介さがあります。

完全には防げないので、「不審なメールの添付ファイルは開かないように！」という事しか言えない状況です。多くの人が思うように「不審」ってどうなら不審なのか？という点には誰も答えてくれないですが。

 

さて、結局のところウイルス対策ソフトは事後的に感染を知る事はできても、完全に防ぐ事は困難ですので、まちがえて添付ファイルをダブルクリックしても影響を受けないようにしておきたところです。

Windows には標準で「ソフトウェアの制限のポリシー」という機能があることをご存知でしょか？

ソフトウェアの制限のポリシーの概要

https://technet.microsoft.com/ja-jp/library/hh831534.aspx

この機能を使うと、指定したフォルダについては、プログラム実行を禁止する事ができます。つまり、電子メールが添付ファイルを保存するフォルダや、テンポラリフォルダについてはプログラムの実行禁止を設定しておけば、間違って添付されていた EXE ファイルをダブルクリックしても防げる場合があるという事です。（添付ファイルを実行制限していないところに保存し、そこで実行すれば感染しちゃいますので、あくまで実行が制限されているフォルダ内でダブルクリックした場合などダメなケースもありますので、完璧ではありません）

 昔からある機能なのですが、なぜかあまり紹介されていることが少ないようですので、この機会に使ってみてはいかがでしょうか？

 ソフトウェアの制限ポリシーを Windows 8 で設定するには、まずローカルセキュリティ設定を開く必要があります。Windows 7 までは管理ツールにあると思いますが、Windows 8.x では下記 URL で紹介されている方法で開く事ができます。

ローカルグループ ポリシー エディターの起動 - Windows8
http://pc-karuma.net/windows8-group-policy-editor/

実際の設定方法については、下記のURLが参考になります。

Windows で特定の名前で実行ファイル、特定フォルダ内の実行ファイルを起動しないようにする方法Add Star
http://futuremix.org/2009/10/limit-program-exe-file

基本的にはパスの規則を使い、実行を制限したフォルダを指定する事になります。

制限しておくとよいフォルダとして、①メールのフォルダ（添付ファイルの保存フォルダを含む）、②ユーザーのテンポラリフォルダ（例 C:\Users\ユーザー名\AppData\Local\Temp）、③Windowsのテンポラリフォルダ、あたりです。例えば、マイドキュメント配下を制限しても困らないのであれば、それらも制限しても良いかもしれませんが、間違えて広く設定すると困るケースがありますので、まずは必要なフォルダ（間違えてダブルクリックするとまずいフォルダ）だけにしておくと良いです。

日々の注意点として、例えば、ユーザーのテンポラリフォルダを制限するとかなり強力な防御になるのですが、逆にソフトウェアがアップデートを行う時に困るケースがあります。

この為、ソフトウェアの制限ポリシーでテンポラリフォルダなどを制限した場合には、各種アプリケーションの自動更新に影響がないかを確認してください。もし、影響がある場合には、アップデート処理を行う時には制限を一時的に解除し、アップデート処理後に再び制限するという運用が必要になります。

また、新しいアプリケーションをインストールする際にも、制限にひっかかるケースがありますので、新しいアプリケーションをインストールする際には、事前にテンポラリフォルダに対する制限は解除しておくと良いと思います。

私はSetup.exeをダブルクリックしてしばらく待って、ああぁぁ制限してた！と思い出すことが良くあります。。。

 

最初、設定方法まで書こうと考えていたのですが、Windows 8.1 Homeだとローカルセキュリティ設定が無いのですね。

(補足)その後、FaceBookのコメントで、AppLockerを利用する方法もあるという情報を頂きました。

AppLocker の技術概要
https://technet.microsoft.com/ja-jp/library/hh831440.aspx

 

kayo-chan.com

雑談：neuro:on ってやはり詐欺なの？

雑談（無駄話）

睡眠時間が短くて済みますって宣伝文句に釣られてしまい、プレオーダーで注文してしまったのが1月12日のこと。

その翌日、やはり思い直して1月13日にキャンセルのメールを送ったんですけど、返事がないので時間を空けつつ、6回目 1月30日にやっと下記のメールが届きました。

Aleksandra Siciarz (Intelclinic)

Jan 30, 9:54 AM

Hi,

Sorry for the delay with the answer. Your cancellation inspiring accepted, you can expect the return on PayPal account within one week.

Best regards,

Aleksandra Siciarz
Business Development Manager
Business Analyst
Intelclinic LLC

さて、その後ですが、一週間後どころか一ヶ月経ってますけど返金処理はされていません。2週間くらい待って更に何度もメールはしているんですが、返事なし。

なんか、この会社は日本でも展示会か何かに出展していたようで、上記の返事を書いてた人も居たみたいですけど、個人的にはすっかり騙されちゃったなぁという感じです。

Paypal 経由の支払いを初めて使ったのですが、即時にクレジットカードへ課金されていてキャンセルできなかったのも痛いですが、Paypal経由の支払はこの辺り気を付けないといけないんでしょうかね。

これは結局この後どうなるんでしょうねぇ、キャンセルって扱いで商品も届かず、お金も戻ってこないという事になりそうな予感がしていますが、アップデートがあったらまた書きます。

 <追記>

その後、3/4 になってやっと返金処理したよという返事があり、Paypal からも返金処理のメールが届きました。

 

ブラウザ キャッシュ痕跡を上書きする仕組みが使われたケース

いわゆる、PC遠隔操作事件の中で誤認させる為に？使われた手法には、デジタル・フォレンジック調査で対象になってくる「ブラウザの履歴やキャッシュ情報」について考慮されている部分があります。

【PC遠隔操作事件】ラストメッセージ全文（下）(江川紹子) - 個人 - Yahoo!ニュース より引用

２）キャッシュで罠スクリプトを発見されない工夫

A「直接踏ませるスクリプト。BをJSONPでクロスドメイン読み込みして実行する」

B「CSRFを行う有害スクリプト。Aとは別サイトに設置。」

の2部構成。

Bの側に、１）で書いた制御を入れました。

そして、Aでは、

「Bを読み込んで変数に格納（B１）→Bを再度読み込む（B２）→B１を実行」

というフローで動作します。Bを2回読み込むというのが肝心です。１）の制御により、B１はCSRF、B２は無害スクリプトになります。

永続性記憶装置に保存されるブラウザのキャッシュには、B１はB２に上書きされ、B２だけが残ります。

変数に格納されただけのB１は実行後、DRAMから揮発してしまいます。

ただし再読み込み時、キャッシュ再利用の挙動はブラウザごとに異なります。

IE等では、２回目の読み込みは発生せず、キャッシュから拾ってきてしまいます。（２回目もB１になる。）

 

 上記では、B2の無害スクリプトとされているデータがディスクに残るように意図されていますので、単純にディスクにある該当時間帯の履歴とキャッシュを確認しても、スクリプトの存在は確認できない事になります。

普通にデータ見ただけでは、履歴とキャッシュされている内容から判断していくでしょうから、この段階で何かしらの特異点が他になければ見落としそうな仕組みですね。この点については、松本さんが下記記事の中で指摘されています。

第２７６号コラム「フォレンジック調査員から見た遠隔操作事件「ラストメッセージ」」 | コラム | デジタル・フォレンジック研究会

 

犯人からのメール内では、IEは再読み込みしてもキャッシュから読み込んでしまうという記述がありますが、IE はキャッシュデータなりの何を基準に更新されていないと判断して再読み込みを行わないのか？という辺り。

IEではキャッシュに関連する設定は「Webサイトデータの設定」にある「インターネット一時ファイル」で制御できますが、デフォルトの設定では「自動的に確認する」という値になっています。この「自動的に確認する」の動作についてはマイクロソフト社の下記記事が参考になります。

Caching Improvements in Internet Explorer 9

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

"セッションごとに 1 回" のキャッシュ検証を理解する
http://blogs.msdn.com/b/ie_jp/archive/2011/10/03/10219064.aspx

 IEについてはこの仕組みによる判断で、Bのスクリプトを再度読み込んでも更新されなかったものと推測されますが、サーバB側の設定なりでキャッシュを制御するというのはうまく動作しなかったのかな？という素朴な疑問を持っていたりします。

他のChromeなどのブラウザでは（ローカルにある）キャッシュのリロードをどの様に判断しているのか？という点もありますが、詳細な情報どこかに無いのでしょうか？

 

 いずれにしても、ブラウザのキャッシュファイルは常に更新される可能があるデータです。ここも可能な範囲で分解し、どの様な視点を持つ事ができるのかを整理した方がよいのかもしれません。

  1. キャッシュファイルの作成日時
  2. キャッシュファイルの更新日時
  3. キャッシュファイルのファイルスラック領域
  4. キャッシュファイルを管理しているレコード構造
  5. キャッシュファイルを管理しているレコードが持つ日付情報（Expireなど）
  6. キャッシュファイルの内部構造（Chromeのキャッシュファイル等）
  7. キャッシュファイル内部構造で管理されている日付情報（作成日時など）
    ⇒これパースするフォレンジック系のツールあるんですかね？
  8. サーバ側から与えられるキャッシュデータの生存期間情報
  9. サーバ側から与えられるコンテンツの更新日時
  10. HTTPレスポンスヘッダ
  11. URLフィンガープリント
  12. Webブラウザのリロード処理
  13. Webブラウザのスーパーリロード処理
  14. Webブラウザのキャッシュに関する設定（期間・サイズ）
  15. Webブラウザのシークレットモード（キャッシュを残さない閲覧モード）

 ■ブラウザがキャッシュデータを保持する部分についての参考情報

ブラウザキャッシュのまとめ
http://please-sleep.cou929.nu/browser-caching-tutorial-memo.html

ブラウザのキャッシュを活用する
https://developers.google.com/speed/docs/insights/LeverageBrowserCaching

 

例題「電子メールに添付されたマルウェア」に感染を分解する

フォレンジック

例えばトレーニングで「電子メールに添付されたマルウェアに感染」したケースを説明しなければいけないとします。

受講者が事前に学習する必要がある項目には何があるのでしょうか？、関連する技術要素として、どこまで事前に知っている必要があるのか？という点を考えてみたいと思います。

受信した電子メールには圧縮ファイルが添付されていました。この圧縮ファイルにはパスワードが設定されており、展開ツールを使ってファイルを取り出す際にパスワードが求められるようになっており、ウイルス対策ソフトは中身を確認する事ができない仕組みになっています。

圧縮ファイルのパスワードは電子メール本文に書かれており、本文内に書かれたパスワードを入力する事でファイルを取り出す事ができます。取り出されたマルウェアプログラムが人間により“実行”される事でコンピュータがマルウェアに感染する事になりました。

この例を理解し調査する為には、どの程度の知識が必要になるか？を把握したいわけです。まずは、理解が必要な技術的な要素に分解してみます。（項目によっては更に詳細に分割できる項目もありますが、まずは大き目に分解してみます）

項目によっては必須の項目・別に知らなくても困らない項目もあると思います。分解した項目に対して、更に必須項目を絞り込んでいく必要があります。（事前に知っているべき事柄と、上記例題を説明していく際に、何を理解いただくのかは分離して考える必要がありますが）

 

■電子メール関連

  1. SMTPプロトコル（TCP、IP、MACアドレス、ルーティング）
  2. DNS MXレコード（ドメイン名とMXの関係）
  3. メールの配信（MUAとMTAの関係、配信経路、時刻情報）
  4. メールサーバのログ（SMTPログ、時刻情報）
  5. メールアカウント（Userと認証、容量制限、ログイン日時、etc）
  6. メールボックス（POP・IMAPプロトコル、Web経由のアクセス、転送）
  7. メールヘッダ（日付、配信、各種ヘッダ）
  8. メールアドレス（TO、CC、BCC、From）
  9. メールソフトウェア（MUA）
  10. メールソフトウェア毎のメールボックス形式
  11. メールの保存形式（Mbox、PST、EML、etc）
  12. メールボックスの所在（ファイルシステム上のパス又はCloud）
  13. メールボックス内のメタデータ（MAPI情報、作成・更新、フラグ etc）
  14. メールのソースデータ（オリジナルのデータ）
  15. メールを開いた（読んだ）日時
  16. 文字コード（ISO-2022-JP、UTF-8、etc）
  17. 添付ファイル（ファイル名、エンコード形式、MIMEエンコード）
  18. 添付ファイルのタイムスタンプ
  19. 電子メールソフトウェアでの添付ファイルの取り扱い（一時フォルダ）
  20. 添付ファイルをオープン（取り出し）した日時
  21. オープンされた添付ファイルが持つファイルシステム上のタイムスタンプ

■ファイル形式

  1. ファイル名と拡張子（データ内容）、拡張子の種類
  2. ファイル名の長さ、文字コード
  3. 拡張子の表示
  4. 拡張子とアプリケーションの関連付け
  5. ファイル形式（実行ファイル、圧縮ファイル、etc）
  6. 圧縮ファイルとその種類
  7. 圧縮ファイルの作成・展開ツール
  8. 圧縮ファイルのパスワード設定、暗号化
  9. 圧縮ファイル内ファイルのタイムスタンプ
  10. 圧縮ファイル自体のファイルシステム上でのタイムスタンプ（作成・更新）
  11. 圧縮ファイルを展開した際のファイルタイムスタンプ
  12. 実行形式ファイル（OSやアーキテクチャによる違い）
  13. 実行形式ファイル内のタイムスタンプ
  14. 実行ファイルのファイル名偽装方法
  15. 実行ファイルのアイコン偽装

■プログラム実行

  1. プログラムの実行の仕組み（実行方法）
  2. プログラムの権限
  3. プログラムの実行痕跡
  4. マルウェアプログラムの特性
  5. マルウェアの感染痕跡
  6. マルウェアの追跡（発見）

 

前提としてWindowsを想定していますが、スマートフォンを含めていくと更に項目が増えていきますね。

2015年時点での自分的 EnCaseスキルセットを棚卸し(2)

フォレンジック

基本的な処理（調査を開始する前に行う下ごしらえ？と言えるのかもしれませんが）に関する項目は以下でしょうか。

主にはファイルの種類を特定したり、既知ファイルを除外する、検索を行い関連するデータを特定するといった部分になり、アーティファクトのパースなどは含んでいません。

 

■シグネチャ分析

  1. ファイルタイプの定義内容の理解（ヘッダ・フッタ パターン、サイズ、カテゴリ）
  2. 既存のシグネチャタイプをカスタマイズして利用する（シグネチャをカスタマイズする事でより分類を詳細に行う）
  3. 自分で必要なシグネチャをファイルタイプに登録・テストする
  4. 予め定義されているファイルタイプで不要（ノイズ）となるパターンの変更
  5. シグネチャ分析の実行（Evidence Processor又は選択対象に対して手動実行）
  6. シグネチャ分析結果の確認とフィルタ（コンディション・フィルタの利用）
  7. ファイル拡張子が変更されているパターン（エイリアス）の確認・フィルタ
  8. シグネチャ分析の結果がマッチするケース（TXTなど）の理解
  9. シグネチャ分析の結果がBadまたはUnKnownになるデータ内容の理解
  10. ファイルが暗号化されているパターンをシグネチャ分析の結果から確認する
  11. ファイルシグネチャを利用したUnallocated Clustersからのカービング
  12. File Carverモジュールを利用したファイルのカービングと制限事項
  13. File CarverモジュールのOptimizedオプションの利用方法
  14. ZIPファイルのカービング（破損データの修復）
  15. Recover Foldersにより表示されているファイルに対するシグネチャ分析実行による破損ファイル等の検出・フィルタ
  16. 拡張子が変更されていた画像ファイルのギャラリービューでの閲覧（シグネチャ分析の実施後）

■コンパウンド（複合）ファイルの取り扱い

  1. EnCaseでマウント可能な複合ファイル、マウントできない複合ファイル（LZH etc...）の理解
  2. View File Structure のマウント時のオプションに関する理解（Unallocated Clustersの計算、削除メールの検索等）
  3. EnCaseがマウントに失敗したファイルの特定（原因の確認）
  4. 複合ファイルに含まれるファイル名が文字化けする場合の原因と対処方法
  5. Evidence ProcessorのExapnd compound filesが対象とするファイルタイプの理解（レジストリは対象外となる）
  6. パスワード付きZIPファイルのマウント（パスワードを入力したかった場合、Secure Storageへのパスワード登録）

■パスワード保護・暗号化されているファイルの分析

  1. Evidence ProcessorのAnalyzing Protected（Passware Toolkit）を使った保護ファイルの検出
  2. 検出された保護ファイルの確認（フィルタ）
  3. Passware 連携機能の理解
  4. エントロピー値の計算手順

■ハッシュ分析

  1. 既知ファイルからハッシュセットの作成
  2. ハッシュセットに含められるメタデータの理解
  3. ハッシュ分析の実行（ハッシュセットの選択）
  4. NSRL、NSRLJP の利用手順の理解
  5. 既知ファイルのハッシュセットを利用したファイルの除外
  6. 既知ファイルのハッシュセット、ハッシュ値を利用したファイルの特定

■RAW キーワード検索

  1. RAWキーワードの登録と適切なCode Page設定の理解
  2. RAWキーワード検索ではヒットしないデータタイプや文書ファイルタイプの理解（ZIP, DOCX, PDF, Base64,Protected Files etc...） 
  3. RAWキーワードとして日本語文字列を検索する場合に指定する適切な Code Page の理解（932,51932,20221 etc...）
  4. RAWキーワードの一括登録（Code Page 指定含む）
  5. RAWキーワード検索の実行・結果（ヒット）の確認
  6. GREP パターンの登録・事前検証

 ■インデックス検索

  1. インデックスが作成される仕組みの理解（Outside In、Transcript、文字化け）
  2. インデックスされるデータ範囲の理解（メタ、本文、対象文字コード、埋め込みデータ部分）
  3. 圧縮ファイル、PDFの添付ファイル、メールの添付ファイルなど他のデータを含んでいるデータに対するインデックス処理の理解
  4. インデックスされない（検索できない）ファイルタイプやデータ内容に対する正しい理解
  5. インデックスされない(されていない)ファイルの検出・フィルタ
  6. 日本語を含むアジア言語を含むデータのインデックスオプションの設定
  7. 日本語文字列に対するインデックス段階での正規化処理の理解（カタカナ、濁点・半濁点、全角英数の処理）
  8. 日本語文字列を利用したインデックス検索と、ハイライトの関係（正規化処理の影響）
  9. 日本語文字列の形態素解析（ワードブレイカーの動作）の理解
  10. 中国語・韓国語に対する形態素解析と正規化処理の影響の理解
  11. インデックス内容のエクスポート（IndexDataExtractor）

 

2015年時点での自分的 EnCaseスキルセットを棚卸し(1)

フォレンジック

EnCase を使い始めてかなりの年数が経過していますが、他のツールも使うようになりつつあるので、一度 EnCase に対して（自分にとって）必要な項目を棚卸ししてみたいと思います。まずは、データの取得から表示辺りまで。

 

■インストール・設定・ケース作成

  1. 最新版EnCaseのダウンロード&適切なインストール
  2. EnCaseが利用するフォルダパスとそれぞれの役割理解
  3. ダウンロードしたCertファイルの役割と配置方法
  4. EnCaseの起動モード（AcquisitionとForensics）の違いについての理解
  5. EnCase のバージョン番号や追加モジュールの有無をHELPから確認
  6. Options⇒Globalタブの設定項目についての理解
  7. Options⇒Code Page設定の役割と、各OSに応じた設定すべきCode Pageについての理解
  8. Options⇒Code Page設定が誤っている場合に発生する、文字化け範囲の理解
  9. Options⇒Flag Lost Filesの設定に関連するFATファイルシステムの仕組の理解
  10. Options⇒Dateタブで日付形式の設定や表示方法の変更。
    曜日表示、タイムゾーン表示の設定変更。
  11. Options⇒Colors上の配色変更、それぞれの色がどこで使われるかの理解
  12. Options⇒Fonts設定で多言語を表示する為の変更、Arial Unicode MS の役割理解
    フォントセットとCode Pageの役割理解
  13. Options⇒Data Pathタブの内容理解
  14. 新規ケースの作成方法（ケースフォルダの適切な配置）
  15. Evidence Cacheフォルダの役割理解
    セカンダリEvidence Cacheの役割理解
  16. バックアップ設定の理解と適切な設定
  17. バックアップ対象と制限事項の理解
  18. バックアップからのリストア手順の理解

■イメージコピーの取得・証拠ファイル形式

  1. 証拠ファイル形式についての理解（E01,Ex01）
  2. 論理証拠ファイル形式についての理解（L01,Lx01）
  3. 証拠ファイル形式の内部構造の理解（CRC,ハッシュ値）
  4. 証拠ファイルの作成時に設定するオプション項目の理解
  5. 証拠ファイルの圧縮方式の違いと、コピー速度への影響についての理解
  6. 証拠ファイルのパスワード設定と暗号化の違いについての理解
  7. イメージコピー作成中の中断処理と再開処理の理解
  8. イメージコピー作成中に発生するエラー処理と設定の理解
  9. 証拠ファイルのベリファイ手順・処理の理解
  10. 証拠ファイルのベリファイ処理でエラーになった場合の対処
  11. 証拠ファイル・イメージファイルの手動でのハッシュ計算
  12. 証拠ファイルの再取得・圧縮方法
  13. 証拠ファイルをRAW形式へ変換する
  14. 物理ディスク・論理ボリュームの取得
  15. デバイス追加時、Edit 画面で設定可能な項目の理解
  16. RAIDボリュームの取得
  17. 暗号化ディスク・暗号化ボリュームの取得
  18. 稼働中システムの取得
  19. RAW形式を証拠ファイル形式へ変換する
  20. FastBloc SEの利用方法＆書き込み禁止措置の理解
  21. HPA・DCO設定と対応方法に関する理解
  22. Linenの利用方法（OS起動メディアの準備）
  23. サーブレットの作成手順、Direct Network Previewの利用方法
  24. サーブレットを使ったメモリイメージの取得方法
  25. Winenを使ったメモリイメージの取得方法
  26. Winacqを使ったディスクイメージの取得方法
  27. WIPE機能の利用方法
  28. イメージファイルの物理ディスクへのリストア方法

■ケースへの証拠ファイル追加（Add Eviddnce）

  1. プレビューとイメージ閲覧の違いの理解
  2. ローカルディスクのプレビュー方法
  3. サーブレットを使ったプレビュー方法（Direct Network Preview）
  4. クロスケーブルを使ったプレビュー方法 (Crossover Preview)
  5. RAW形式イメージファイルの追加（DD、ISOイメージ等）
  6. 証拠ファイルの追加
  7. GUIDとEvidence cacheファイル内の関係についての理解
  8. Singleファイルの追加（Singleファイルの制限・注意事項）

■パーティション・ボリュームの追加・閲覧・コピー

  1. ドライブ文字の付与ルール、ドライブ文字の変更方法
  2. デバイス・ボリュームの詳細情報確認（レポート）
  3. 未使用範囲の確認
  4. （削除）パーティションの追加・削除
  5. （削除）パーティションの検索（VBRの検索）
  6. バックアップVBRを利用したパーティションの復元
  7. BitLocker暗号化ボリュームの追加
  8. RAIDボリュームの再構成手順
  9. LVMボリュームの再構成手順（Scan for LVM）
  10. EFS暗号化の利用確認（Description）と対応（Analyze EFS...）
  11. Windows タイムゾーンの確認方法（SYSTEMレジストリ）
  12. Linux タイムゾーンの確認方法
  13. Mac OS X タイムゾーンの確認方法
  14. タイムゾーンの設定、反映確認方法
  15. FATボリューム上の削除ファイルにおいて、日本語だと先頭が正しく扱われないケースへの対応
  16. FATボリュームのボリューム名が文字化けする場合の確認方法
  17. FATボリューム上のInvalid Cluster表示に関するクラスタ開始位置に関する理解
  18. Unallocated Clusters の意味と役割の理解
  19. VFSを利用した（仮想的な共有ドライブを通じた）エクスプローラからのデータアクセス
  20. PDEを利用した（仮想的な物理ディスクを通じた）エクスプローラからのデータアクセス
  21. PDEを利用した VSS （以前のバージョン）へのアクセス
  22. Copy Files/Copy Foldersを利用したファイルのコピー方法、コピー範囲、ファイルの連結、フォルダ構造を維持したコピー、重複ファイル名の扱い、長いパスの扱いについての理解
  23. Copy Files/Copy Foldersを利用したファイルコピー時のタイムスタンプ維持についての理解
  24. Copy Files/Copy Foldersの設定において、分割サイズを０に設定しておくことで分割を行わずに取り出す
  25. Copy Files/Copy Folders の対象に $BadClus;$Bad は含めない意図の理解
  26. View File Structureを使ったコンパウンドファイルのマウント手順
  27. View File Structureでマウントしたコンパウンドファイルのアンマウント手順
  28. デバイスのキャッシュファイル削除方法と影響の理解

■削除ファイルの取り扱い

  1. 削除ファイルに関連したアイコン、関連カラムの表示内容の理解
  2. 削除ファイル（Overwritten）の上書きファイルの名前確認と参照方法
  3. Lost Filesに含まれるファイルの意味（親が不明）とファイルシステム側での仕組みの理解
  4. Recover Foldersの手動実行と結果セットの削除方法
  5. Recover Foldersの役割（対象範囲）とNTFS・FATファイルシステム上での仕組みの理解
  6. Recover Foldersを実行した場合の、Unallocated Clusters への影響（該当クラスタの取り扱い）
  7. 削除ファイルの上書き判定（先頭クラスタによる判断）の理解
  8. FATボリューム上での削除ファイルの先頭ファイル名の取り扱い
  9. FATボリューム上での削除ファイルのサイズ（データ範囲）の取り扱い
  10. ゴミ箱フォルダへのファイル移動時に発生するNTFS上の変化についての理解
  11. ゴミ箱フォルダへのフォルダ移動時に発生するNTFS上の変化についての理解
  12. ゴミ箱フォルダ内データの表示ルール（$I、$Rの取り扱い）
  13. ゴミ箱フォルダ内ファイルの削除日付の扱い
  14. ゴミ箱フォルダ内ファイルのオリジナルパス（$Iとの関連、$Iが無い場合）
  15. ゴミ箱フォルダ内 INFO2 ファイルのデコード、スラック上の取り扱い
  16. ゴミ箱フォルダ内のSIDとユーザー名の紐づけ（SID、RID、プロファイル）
  17. スラック領域の表示色と範囲の理解（各スラック領域）

■画面表示

  1. セットインクルードとブルーチェックの役割理解
  2. ディクソンボックスの役割理解
  3. GPSバーに表示される各項目の理解
  4. GPSバーのLE値を使った範囲の選択
  5. GPSバーのFO, SO 値を使ったオフセット位置の確認
  6. 各カラムが表示する内容の理解
  7. テーブルペイン上カラムの表示列のロック方法・解除方法
  8. テーブルペイン上カラムの非表示設定
  9. テーブルペイン上カラムのソート方法・解除方法、6段階でのソート追加
  10. テーブルペイン上カラムの並び順の変更
  11. 特定のカラムに対応したビューペイン上のタブについての理解
  12. ビューペイン上にある各タブが表示する内容の理解
  13. ビューペイン上にあるDocビューとTranscriptタブの役割の理解
  14. ビューペイン上Textタブでの日本語（CJK）表示方法
  15. ビューペイン上TextタブでのShift_JISやUnicodeを指定した場合に、文字列が２バイト単位で扱われている方法の理解（折り返し位置で化ける場合）
  16. ビューペイン上Textタブで、複数文字コードのデータが混在する場合の表示
  17. 日本語文字列を表示する際に利用するCode Page番号の理解
  18. Outside Inの役割と制限事項の理解
  19. Go To 画面の使い方（数値変換、マイナス値非対応）
  20. ビューペイン上 Decode タブを利用したデータの変換方法
  21. ビューペイン上 Picture タブでの画像表示（Options設定との関係）
  22. ビューペイン上 Picture タブがサポートする画像ファイル形式
  23. ビューペイン上 Picture タブの画像表示制限（レイヤーを扱えない）
  24. ビューペイン上 Attributes タブの役割（表示内容）の理解
  25. ビューペイン上 Console の役割と表示される項目の理解
  26. ビューペインの取り外しと、戻し方
  27. ギャラリービューの制限事項（シグネチャ解析後でなければ拡張子に依存して画像を表示）
  28. ギャラリービューのレンダリング順序変更（Optionsでの設定変更）
  29. ギャラリービューにおける破損画像の取り扱い（Optionsでの設定変更）
  30. テーブルエントリでアイテムをダブルクリックした時の動作（呼び出されるアプリケーションとの関連付け）
  31. 外部ビューアの登録と呼び出し方、外部ビューアで扱う為の一時ファイルの取り扱いについての理解

 

 

2015年に取り組むにはちょっと出遅れかもしれないテーマ SQlite3 と Cloud

すでにエッジな話題ではなく、ツールなども充実してきているのであまり斬新な分野ではないですが、もし今年からデジタル・フォレンジック始めました！みたいな若者に「これやっとけ」と言うなら、個人的には SQlite3 でしょうかね。

まぁ、正直あまりいけてないテーマかなぁという気もするのです。実務的な部分では役立つ項目でしょうし、データベースの基本的な技術知識は他でも役立つだろうという、ちょっと保守的なテーマですけど。

SQlite3 はデータベースですので、残っているファイルを調べる部分についてはそれほど難しくないかもしれませんが、トランザクションログや、削除データの抽出といった部分はまだ少しこなれてない部分でしょうか。

また、Webブラウザやスマートフォンアプリの多くがデータの収納先として利用していますので、色々なデバイス上のデータについて理解を進める事ができそうなのも、お薦めとしている理由の一つでしょうか。

データはどんどんクラウド側に移行していますが、それにアクセスする端末やアプリケーション（Webブラウザ）には部分的には痕跡が残っており、それが SQLite3 を使っているケースも多い気が個人的にはしています。（平たく言うと、Cloud Forensics の入口としては丁度よくね？という意図だったりもします）

いずれはSQLite3ではなく、別の仕組みが利用されるようになる気もしますので、10年後でも役立つ技術かは、2025年になってこの Blog を読み返してみないと分かりません（笑）

挑戦するなら最初からエッジな分野がいい！という野望をお持ちでしたら、Cloud Forensics に突入するのも選択肢の一つでしょうか。

もし自分だったら、NIST が出している資料をベースに、課題となっている項目を確認していくアプローチをとるかもしれません。Cloud といっても、基本的にはドキュメント ライフ サイクルをベースに考えて取り組む必要があるというのが個人的な印象です。

将来的には、FATやNTFSとか読む必要がなくなり、全部 Cloud です！っていう世界であれば、ファイルシステムよりそっちを優先して取り組む方が、今からの若手にはあってそうな気がしている今日この頃です。