@port139 Blog

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

Plaso Filestatパーサでタイムスタンプがズレる件

Plaso 1.4.0 ベースの Log2timeline ですが、Windows 7 環境上で実行すると、ファイルのタイムスタンプ情報が数秒ズレるという事象に悩んでいます。

具体的にはWindows 7 64bit環境で 32bit版の Plaso 1.4 を使い、filestat パーサでタイムスタンを作成した場合、該当ファイルやフォルダが持っているタイムスタンプから数秒ズレた値が結果として出力されます。（64bit版はなぜか手元でエラーになった為検証は未実施）

 

しかし、Windows 10環境上で同じく Plaso 1.4 ベースで filestat パーサを利用しても時刻ズレは発生しません。

log2timeline.exe --parsers filestat c:\case\filesta.db c:\Temp\example

psort.exe -z Japan -w c:\case\filestat.csv -o L2tcsv c:\case\filesta.db

 実行環境のOSによる差異が起きる原因が不明ですが、Windows 10環境上では問題が再現しないという事は確認できました。

 

ファイルシステムのタイムラインを作成する場合、Plaso の filestat では削除ファイルが含まれない、$FILE_NAME 属性のタイムスタンプが含まれない、という点もあり fls ベースでタイムラインを生成する方がメリットがある場合もあります。

速度的にも fls ベースでタイムラインを作成した方が早いという点がありますね。

 

flsで作成した body ファイルを Plaso の mactime パーサで処理するという案もありますが、日本語ファイル名が含まれる場合は文字化けが発生しますので、この点はやや課題でしょうか。

 

コピー手順におけるミスやトラブルからキーポイントを考える

フォレンジック

デジタル・データの（正しい）コピー手順とキーポイントを考える際に、過去の失敗から何か学ぶ事ができるのか？と思い整理してみています。

小ネタとしてお話するには良いかもしれませんが、こういった事に注意してください！！と手順書に書いたところで意味がなさそうですね。

ちなみに、自分がやらかした事例も中にはありますが、呑み会などでネタとしてお話されていたものを含みます。

 

  1. 対象と異なる機器の複製を取得した。（つまり別のパソコンだった）
  2. カートリッジに入ったDVD-RAMメディア、A面とB面があるのにA面だけコピーしてB面を取り忘れた。
  3. 電源ケーブルを抜く時、間違えて作業中機器の電源ケーブルを抜いてしまいコピー処理中の機器が落ちた。
  4. ノートパソコンで電源ケーブルが正しく接続されておらず、バッテリ駆動のままだったので途中で電源が落ちた。
  5. コピー途中で省電力モードに入ってしまった。
  6. コピー途中でスクリーンセイバーにより画面がロックされてしまった。（パスワードが分からないので解除できない）
  7. HDDパスワードが設定されているがパスワードが分からない。（つまりアクセスできない）
  8. ノートパソコンにPCMCIAタイプのLANカードを接続してコピー中、カード部分が高熱になりコピー途中で熱暴走が発生。
  9. 外付けUSB-HDDケースが2Tを超えるサイズのHDDに対応しておらず、正しくディスク全体が認識されない。（同様のパターンは複製装置・ライトブロッカーにおいても発生する）
  10. 複製装置の時刻が正しい時刻でなく、ずれていた。（時刻の設定忘れ）
  11. 複製装置のケーブル類を忘れた。
  12. 複製装置でコピーを取得したら、DDイメージファイルがまったく出来ていなかった。（複製装置の不具合）
  13. 複製装置でエラーセクタが大量にあるHDDのコピーを取得したところ、DDイメージファイルがまったく出来ていなかった。（装置の不具合）
  14. HPA・DCO領域があるHDDをコピーしようとして、複製装置でエラーが発生した。（装置の利用者がHPA・DCOを知らなかった）
  15. 複製装置のHDDチェック機能を利用して、コピー先ディスクのファイルシステムが消えた。
  16. IDEハードディスクのピンを曲げた、（IDEケーブルの向きを間違えて差し込んで）折ってしまった。
  17. IDEハードディスクのジャンパーをマスターに変更するのを忘れた。（昔はそういった手順が必要なことがあった）
  18. ２Tを超えるボリュームをツールからマウントし、ファイルを取得したら、Non-Residentのファイルの中身が全てゼロだった。（Residentのデータだけ取れていた）
  19. ネットワーク経由のコピー中に、ネットワーク機器（HUB）が再起動された。
  20. 夜間を利用してのコピー中にバックアップ処理が開始されてしまい、コピーに影響が出た。
  21. ファイルが自動的にアーカイブサーバに退避される仕組みが導入されており、コピーしたファイルがリンクだけで実体ファイルが取れていなかった。
  22. デスクトップPCのケース取り外しの際に、ケースのピンが折れた。
  23. HDDの取り外し作業中、外したネジが足りない、または戻したはずなのに余る。
  24. 取得対象のディスクの選択を間違え、（ライトブロッカーの先にあるHDDを対象とすべきところ）作業PCに内蔵されているディスクのイメージを取得した。
  25. 複製先のHDDをライトブロックした状態でイメージを出力した。（イメージの書き込みは全てブロックされる）
  26. Liveでイメージ取得している最中にWindowsがブルースクリーンになった。（エラーセクタが大量にあるHDDだった）
  27. イメージファイルを取得するコマンドラインで、オプション項目の指定を間違えていた。
  28. イメージファイルを取得する際に入力する項目で、タイプミスしていた。（綴り間違い、Notesメッセージの記入ミス等）
  29. イメージファイルの出力先を間違えた。
  30. イメージファイルの保存先がFAT32なのに、4GB以上のファイルを出力しようとした。
  31. 取得したイメージファイルの中身が全てゼロだった。
  32. 取得したイメージファイルが壊れていた。
  33. 取得したイメージファイルが自動的に暗号化されていた（つまり読めない）。
  34. Liveでのイメージ取得において、対象環境のOSが古すぎるため、最近のツールはエラーになり起動できない。
  35. Liveでのメモリイメージ取得中に、OSがブルースクリーンになった。
  36. Liveでのメモリイメージ取得中に、PCがリセットされた。（ブルースクリーンにならず強制的にハードウェアがリセット）
  37. 論理取得の対象ファイルのアクセス権が無かった。（つまりコピーできない）
  38. 論理取得の対象ファイルがオープンされていた。（つまりロック状態でコピーできない）
  39. BIOS設定画面に入る必要があるのに、BIOSの呼び出しに失敗しWindowsを起動してしまった。（Windowsに限らず、OSを起動してしまうケース）
  40. BIOS設定（起動順序）を変更する必要があるのに、BIOSのパスワードが分からず変更できない。
  41. BIOS設定を元に戻す作業を忘れた。
  42. 変更前のBIOS設定を記録に残すのを忘れた。（元の設定に戻せない）
  43. Secure Boot環境に気が付かず、CD/DVDで起動しようとして起動に失敗した。
  44. 古いMacのフロッピーディスクをWindows用のFDドライブで読み込もうとした。（つまり読めない）
  45. ハードディスクの空気穴がある部分にラベルを貼っていた。
  46. シンクライアントになっている環境で、ローカルのディスク内容だけコピーしたので必要なデータが取れていなかった。
  47. 仮想環境でスナップショットが複数あり、古いスナップショットのデータを取得していた。（最新の情報が取得出来ていない）
  48. DDイメージファイルの順番を間違えて連結しマウントした。（データに不整合が発生する）
  49. DDイメージファイルの名前が全部同じ為、DDイメージを取り違えた。
  50. 取得したイメージファイルを間違えて削除した。

 <10/4追記>

その後、Facebookで他にも、コピー開始後に機器を動かして接触不良になった、HDD取り外し時にネジ穴がすでにつぶれていた、なども教えていただきました。

恐らく、他にも色々な事例があると思うのですが、それらに対して「作業時には注意してください！！」といっても無理があると思いますので、過去の事例を参考にしつつ、正しい手順を組み、ミスが起きないように手順化する必要がありますね。

 

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

フォレンジック

皆さんの組織では、マルウェア感染した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）