RegisterXLLとAutoruns
トレンドマイクロ社のブログ「ChessMaster’s New Strategy: Evolving Tools and Tactics」には下記の記述があります。
The Powershell script leverages RegisterXLL, which is a component of Excel, to load BKDR_ANEL into Excel.exe
マルウェアは Excel の RegisterXLL を利用して起動しているようです、この仕組みは「Add-In Opportunities for Office Persistence」内の XLL “Add-Ins” for Excel" の項目が参考になります。
確認できるマルウェアファイルが無いので、実際にマルウェアが動作した場合にレジストリキーへ登録されるか未確認です。
アドインがレジストリキーに登録される場合、下記レジストリキーに OPTION 値として登録されます。
HKEY_CURRENT_USER\Software\Microsoft\Office\<Version>\Excel\Options
Excel 2016 環境で XLL をアドインとして登録し、レジストリキーを確認します。OPEN 値に xll が登録されています。
Autoruns 13.80 で Office タブを確認。Option キーがチェック対象ではない為、Autoruns からは XLL の登録を確認できません。
XLL ファイルは DLL ですので、署名が無い DLL ファイルをチェックするなど、別の確認手段で発見する必要があります。
参考URL：
Execute a DLL via .xll files and the Excel.Application object's RegisterXLL() method · GitHub
GitHub - MoooKitty/xllpoc: Code Exec via Excel
Win 10 と sdelete
Windows 10 ver 1709 上での sdelete コマンドの動作について。
Sdelete コマンドについては、Kazamiya さんが「SDelete | Forensicist」に詳しく整理されていますので、そちらを参照ください。
Picturesフォルダに JPEG ファイルを置いてあります。このボリュームは NTFS でフォーマットしてあります。
JPEG 画像ファイルのメタ情報をAutopsy 4.5.0 で確認します。JPEG 画像ファイルのMFTレコード番号は 39 で、親フォルダ(Pictures)の MFT レコード番号は 43 です。
sdelete を利用して JPEG ファイルを削除します。
ファイルの削除後、E: ドライブを Autopsy で確認します。先ほどのJPEG画像ファイルは Pictures フォルダ配下ではなくroot上で発見できます。
$FN属性の Parent MFT Entry が 5 になっている事を確認できます。
sdeleteはファイル名を26回変更しますが、ファイル名変更時に親フォルダをrootに設定するようですね。
フォルダを削除
再度 JPEG 画像ファイルを配置し、Pictures フォルダの単位で削除してみます。JPEG 画像ファイルの MFT レコード番号は 39、フォルダのMFTレコード番号は 43 です。
JPEGファイルのファイル名変更されています。しかし、Picturesフォルダの名前は変更されていません。
なお、JPEGファイルのデータ内容は 0x00 となっています。
Cドライブ
C:ドライブでテストファイルを作成し、sdeleteで削除します。
ファイル名の変更は行われていません。temp フォルダ配下で削除ファイルとして確認できます。データ内容は 0x00 になっています。
参考URL:
https://jpcertcc.github.io/ToolAnalysisResultSheet_jp/details/sdelete.htm
Rundll32 と Prefetch
Rundll32.exe を利用した DLL 実行と、プリフェッチファイルの関係について確認してみます。テストした環境は Win 10 1709 Build 16299.15 です。
DLL ファイルには、Didier Stevens さんの作られた cmd.dll を利用します。
Rundll32
Windows\Prefetch フォルダ配下にある .pf ファイルは削除しておきます。念のため WinPrefetchVew でも確認しておきます。
rundll32 経由で cmd.dll を起動します。
WinPrefetchViewで RunDll32 を確認します。RunDll32 のファイルリスト内に cmd.dll の項目を確認できます。
システムを再起動した後、AppCompatCache 内で cmd.dll のレコードを確認しましたが、これは存在しませんでした。
念のため、cmd.dll のパスを変更して再度テストしましたが、AppCompatCache 内にレコードは確認できませんでした。
SHELL32
次に Shell32.dll 経由で CMD.DLL を呼び出してみます。（プリフェッチファイルは事前に削除します。）
プリフェッチファイルを確認します。
システムを再起動した後、AppCompatCache 内で cmd.dll のレコードを確認します。レコードが2件ありますが、これは念のためパスを変更した場合もテストしたものとなります。
shell32.dll 経由で cmd.dll を起動した場合、 AppCompatCache 内にレコードが残るようですね。
PowerShell
PowerShdll を利用し、Rundll32 経由で PowerShell を呼び出した場合。
rundll32.exe PowerShdll,main -w
参考URL:
pentestlab.blog
$LogFile (2) と Defrag
NTFSボリューム F: 上でデフラグを実行した場合に、$LogFile に記録される内容を確認してみます。
サンプルの画像ファイル crocodile.jpg のメタ情報を確認します。クラスタ番号 34848 からデータが配置されています。
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 264 (S-1-5-21-1901480256-120802936-2790681297-1000)
Created: 2017-10-29 00:28:07.050364800 (UTC)
File Modified: 2017-09-15 22:08:28.397301700 (UTC)
MFT Modified: 2017-09-15 22:08:28.397301700 (UTC)
Accessed: 2017-10-29 00:28:07.050364800 (UTC)
DataRun
デフラグを実行
F:ドライブ上で幾つかファイルを削除した後、デフラグを実行します。
デフラグ実行後の crocodile.jpg のメタ情報を確認します。新たにクラスタ番号 1992 からデータが配置されています。
また、MFT Modified のタイムスタンプはデフラグにより変化してない事を確認できます。
$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 264 (S-1-5-21-1901480256-120802936-2790681297-1000)
Created: 2017-10-29 00:28:07.050364800 (UTC)
File Modified: 2017-09-15 22:08:28.397301700 (UTC)
MFT Modified: 2017-09-15 22:08:28.397301700 (UTC)
Accessed: 2017-10-29 00:28:07.050364800 (UTC)
DataRun
$LogFile
LogFileParser を利用して、デフラグ実行後の $LogFile ファイルをパースします。
フィルタを利用し、crocodile.jpg ファイルのレコードを表示します。
デフラグ前の DataRun値 32 78 07 20 88 00 を $LogFile で検索します。オフセット位置 4AB70 でヒットしました。この値が含まれると考えられる $LogFile のレコードオフセットは 0x0004AB08 です。
オフセット 0x0004AB08（LSN 1086817）のレコードをパースしてみます。
6195100000000000 this_lsn; ⇒ 1086817
5595100000000000 client_previous_lsn; ⇒
5595100000000000 client_undo_next_lsn;
40000000 client_data_length; ⇒ 64
0000 seq_number;
0000 client_index;
01000000 record_type;
18000000 transaction_id;
0000000000000000 reserved_or_alignment[3];
0900 redo_operation; ⇒ UpdateMappingPairs
0900 undo_operation; ⇒ UpdateMappingPairs
2800 redo_offset; ⇒ 40
1000 redo_length; ⇒ 16
3800 undo_offset;⇒ 56
0800 undo_length;⇒ 8
1800 target_attribute;
0100 lcns_to_follow;
1001 record_offset; ⇒ 272
4000 attribute_offset; ⇒ 64
0200 MFT Cluster Index
0200 alignment_or_reserved;
0D000000 Target VCN
00000000 Alignment or Reserved
0D630000 Target LCN
00000000 alignment_or_reserved1;
220001C807327806588100008AB1FFFF ⇒ redo data
3278072088000000 ⇒ undo data
上記の C807（1992）は新たに配置されたクラスタ番号のデータ部分になります。
クラスタの再配置により、クラスタ番号 1992 が長さ 1 で割り当てられた時点のデータである事を確認できます。
クラスタが徐々に割り当てられていく状況は、lf_DT_DataRuns のセル内容から確認ができます。
参考URL:
http://forensicinsight.org/wp-content/uploads/2013/06/F-INSIGHT-NTFS-Log-TrackerEnglish.pdf
https://www.sans.org/summit-archives/file/summit-archive-1493741055.pdf
$LogFile (1)
NTFS には $LogFile があります。$LogFile を調べることで、ファイルシステム上で何か変化したかをより詳細に調べる事が可能です。
テストファイルの作成
Windows 10 環境上で VHD ディスクを作成し、USN ジャーナルを有効にします。
C:\Windows\system32>fsutil usn createjournal m=1 a=1 f:
C:\Windows\system32>fsutil usn queryjournal f:
Usn Journal ID : 0x01d34abf22ab9a4c
First Usn : 0x0000000000000000
Next Usn : 0x0000000000000000
Lowest Valid Usn : 0x0000000000000000
Max Usn : 0x7fffffffffff0000
Maximum Size : 0x0000000000100000
Allocation Delta : 0x0000000000040000
Minimum record version supported : 2
Maximum record version supported : 4
Write range tracking: Disabled
F:ドライブ上に test.txt ファイルを作成し、USN Journal を確認します。
C:\Windows\system32>echo sample > f:\test.txt
C:\Windows\system32>fsutil usn readjournal f:
USN Journal ID : 0x01d34abf22ab9a4c
First USN : 0
Next USN : 240
Start USN : 0
Min major version : Supported=2, requested=2
Max major version : Supported=4, requested=4Usn : 0
File name : test.txt
File name length : 16
Reason : 0x00000100: File create
Time stamp : 10/21/2017 15:52:26
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000028
Parent file ID : 00000000000000000005000000000005
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 96Usn : 80
File name : test.txt
File name length : 16
Reason : 0x00000102: Data extend | File create
Time stamp : 10/21/2017 15:52:26
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000028
Parent file ID : 00000000000000000005000000000005
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 96Usn : 160
File name : test.txt
File name length : 16
Reason : 0x80000102: Data extend | File create | Close
Time stamp : 10/21/2017 15:52:26
File attributes : 0x00000020: Archive
File ID : 00000000000000000001000000000028
Parent file ID : 00000000000000000005000000000005
Source info : 0x00000000: *NONE*
Security ID : 0
Major version : 3
Minor version : 0
Record length : 96
$LogFileのパース
$LogFile をエクスポートし、LogFileParser ツールを利用してパースします。
CSVファイルをExcelで開き、test.txt ファイルのレコードにフィルタします。
test.txtファイルに関連した 1行目のオフセットは 0x00035D48 となっています。これは MFTレコード番号 5番の $INDEX_ALLOCATION:$I30 へデータが追加された事を示しています。
F:\ にファイルが作成されたので、ルートフォルダ内のデータを管理している $INDEX_ALLOCATION:$I30 へレコードが追加されます。MFT レコード番号 5 番はボリューム root を意味します。
$LogFile 内でオフセット 0x00035D48 (220488) のデータ内容を確認します。
参考URLの資料をベースにバイナリをパースしてみます。
A96B100000000000 this_lsn; ⇒ 1076137
9D6B100000000000 client_previous_lsn; ⇒ 1076125
9D6B100000000000 client_undo_next_lsn;
90000000 client_data_length; ⇒ 144
0000 seq_number;
0000 client_index;
01000000 record_type;
18000000 transaction_id;
0400 reserved_or_alignment[3];
000000000000
0E00 redo_operation; ⇒ AddIndexEntryAllocation
0F00 undo_operation; ⇒ DeleteIndexEntryAllocation
2800 redo_offset;
6800 redo_length;
9000 undo_offset;
0000 undo_length;
4000 target_attribute;
0100 lcns_to_follow;
0000 record_offset;
7805 attribute_offset; ⇒ 1400
0000 MFT Cluster Index
0800 alignment_or_reserved;
00000000 Target VCN
00000000 Alignment or Reserved
24000000 Target LCN
00000000 alignment_or_reserved1;
上記では attribute_offset の値が 1400 となっています。$I30 でオフセット 1400 を確認してみます。$I30 に追加されたデータを確認できます。
USN レコード
USN ジャーナルには、test.txt のレコードが3件追加ます。ファイルシステム上でtest.txtファイルが作成されていく流れに従い、USN ジャーナルのレコードも記録されています。
test.txtファイルに関連した 3行目のオフセットは 0x00036260 (221792)となっています。これは $UsnJrnl の $DATA:$J にデータが追加された事を示しています。
$LogFile 内でオフセット 0x00036260 (221792)のデータを確認します。このレコードは、USN 番号 0 の作成に対応したレコードです。
4C6C100000000000 this_lsn; ⇒ 1076300
3B6C100000000000 client_previous_lsn; ⇒ 1076283
3B6C100000000000 client_undo_next_lsn;
78000000 client_data_length; ⇒ 120
0000 seq_number;
0000 client_index;
01000000 record_type;
18000000 transaction_id;
0400 reserved_or_alignment[3];
000000000000
0800 redo_operation; ⇒ UpdateNonresidentValue
0000 undo_operation;
2800 redo_offset;
5000 redo_length; ⇒ 80
7800 undo_offset; ⇒ 120
0000 undo_length;
4802 target_attribute;
0100 lcns_to_follow;
0000 record_offset;
0000 attribute_offset; ⇒ 0
0000 MFT Cluster Index
0000 alignment_or_reserved;
00000000 Target VCN
00000000 Alignment or Reserved
C8070000 Target LCN
00000000 alignment_or_reserved1;
USN_RECORD_V2 structure のデータが 80 バイト続きます。
参考URL:
NTFS Log Tracker - blueangel's ForensicNote
http://forensicinsight.org/wp-content/uploads/2013/06/F-INSIGHT-NTFS-Log-TrackerEnglish.pdf
https://www.sans.org/summit-archives/file/summit-archive-1493741055.pdf
USN と range tracking
fsutil コマンドの「enablerangetracking」オプションを確認してみます。テスト環境は Windows 10 です。
この機能については、マイクロソフト社の下記URLで説明されています。
Tracking modified ranges of a file より引用
The NT File System (NTFS) team has added a new feature to Windows. USN Journal will output an update sequence number (USN) record containing modified ranges for a file upon close. A new record type, USN_RECORD_V4 has been introduced to record these changed ranges of a file.
F: ドライブで USN ジャーナルを有効にします。デフォルトでは「Write range tracking: Disabled」となっています。
Range trackingを有効にします。
fsutil usn enablerangetracking f:
Range trackingが有効になりました。レコードが生成される条件は下記となっています。
USN_RECORD_V4 structure (Windows) より引用
A USN_RECORD_V4 record is only output when range tracking is turned on and the file size is equal or larger than the value of the RangeTrackFileSizeThreshold member. The user always receives one or more USN_RECORD_V4 records followed by one USN_RECORD_V3 record.
今回のテストで利用するJPEGファイルのサイズは 4,022,324 バイトです。
「Write range tracking file size threshold: 1048576」よりも、サイズの大きい JPEG ファイルを利用します。
JPEG ファイルの末尾に１バイト（0xFF）を追加します。その後、USNジャーナルを確認すると、V4 レコードが追加されている事を確認できます。
USN_RECORD_V4 structure と USN_RECORD_EXTENT structure を参考に、USN V4レコード 176 のバイナリデータをパースしてみます。
50000000 RecordLength ⇒ 80
0400 MajorVersion
0000 MinorVersion
27000000000001000000000000000000 FileReferenceNumber
05000000000005000000000000000000 ParentFileReferenceNumber
B000000000000000 USN ⇒ 176
03000080 Reason
00000000 SourceInfo
00000000 RemainingExtents
0100 NumberOfExtents
1000 ExtentSize
00403D0000000000 LONGLONG Offset ⇒ 4014080
0040000000000000 LONGLONG Length ⇒ 16384
一般的なUSNパースツールが、USN V4 レコードを可視化するかは未確認です。
参考URL:
$JとUSN
NTFS USN Jornal の確認用として、新規にVHDディスクを作成し、NTFSでフォーマットします。下記図ではF:ドライブが新規に作成したNTFSボリュームになります。
fsutil コマンドを利用し、ジャーナルの状態を確認します。F:ドライブに USN ジャーナルは設定されていません。
> fsutil usn queryjournal f:
F:ドライブでUSN Jornalを有効に設定します。テスト用ですので、m と a の値は1を設定します。
fsutil usn createjournal m=1 a=1 f:
USN Jornal が有効になった事を確認します。
First Usn は 0x0000000000000000 となっています。
USN 値は $J 内のオフセット位置になっています。
Keeping an Eye on Your NTFS Drives: the Windows 2000 Change Journal Explained
より引用
The Change Journal always writes new records to the end of the file, so the implementors chose to use the file offset of a record as its USN. This makes querying the journal fast since the system can simply seek the desired record using the USN.
Autopsyを使い$UsnJrnl:$J ファイルのメタデータを確認します。この時点では、$J ストリームのサイズはゼロになっています。
F:ドライブ上にファイルa.txtを新規作成します。この操作によって、USNジャーナルにレコードが追加されます。
F:ドライブのUSNを確認します。First Usn はゼロのままで、Next Usnの値が更新されています。
メタ情報を確認します。$Jにクラスタ番号 1992 が割り当てられています。
$J のデータを参照すると、USN レコードを確認できます。
USNレコードの構造は下記のように定義されています。
USN_RECORD_V2 structure (Windows) より引用
typedef struct {
DWORD RecordLength;
WORD MajorVersion;
WORD MinorVersion;
DWORDLONG FileReferenceNumber;
DWORDLONG ParentFileReferenceNumber;
USN Usn;
LARGE_INTEGER TimeStamp;
DWORD Reason;
DWORD SourceInfo;
DWORD SecurityId;
DWORD FileAttributes;
WORD FileNameLength;
WORD FileNameOffset;
WCHAR FileName[1];
} USN_RECORD_V2, *PUSN_RECORD_V2, USN_RECORD, *PUSN_RECORD;
最初のレコードをパースしてみます。
0x00000000: 48 00 00 00 02 00 00 00 28 00 00 00 00 00 01 00 H.......(.......
0x00000010: 05 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00 ................
0x00000020: 5A 9F 5D 28 A9 41 D3 01 00 01 00 00 00 00 00 00 Z.](.A..........
0x00000030: 00 00 00 00 20 00 00 00 0A 00 3C 00 61 00 2E 00 .... .....<.a...
0x00000040: 74 00 78 00 74 00 00 00
48 00 00 00 RecordLength ⇒ 0x48 ⇒ 72
02 00 MajorVersion
00 00 MinorVersion
28 00 00 00 00 00 01 00 FileReferenceNumber ⇒ MFT Record No 40
05 00 00 00 00 00 05 00 ParentFileReferenceNumber ⇒ 親 MFT Record No 5
00 00 00 00 00 00 00 00 Usn
5A 9F 5D 28 A9 41 D3 01 TimeStamp ⇒ 2017/10/10 18:21:30.6379098 JST (UTC+9)
00 01 00 00 Reason ⇒ 00 00 01 00 ⇒ USN_REASON_FILE_CREATE
00 00 00 00 SourceInfo
00 00 00 00 SecurityId
20 00 00 00 FileAttributes
0A 00 FileNameLength ⇒ 0x0A ⇒ 10
3C 00 FileNameOffset ⇒ 0x 3C ⇒ 60
61 00 2E 00 74 00 78 00 74 00 00 00 FileName ⇒ a.txt
fsutilコマンドを使い、a.txtファイルのUSN情報を取得します。
fsutil usn readdata f:\a.txt
a.txt ファイルの USN 値として 0x90 ⇒ 144 を確認できます。
上記から、a.txtに関連した最後のUSNレコードは、$Jのオフセット144にある事が分かります。
上記の USN 値は a.txt の MFT レコード内 $STANDARD_INFORMATION で確認できます。
NTFS DOC ページ9から引用
Update Sequence Number (USN)
Last Update Sequence Number of the file. This is a direct index into the file $UsnJrnl. If zero, the USN Journal is disabled.
Autopsy では File Metadata のタブで USN を確認できます。
「Last User Journal Update Sequence Number: 」の項目で USN が 0x90⇒144 である事を確認できます。
$Jファイルのパージ
$Jに保存されるレコードが増加すると、古いレコードはパージされます。
下記は $J でレコードが増加し、First Usn が更新された状態を示しています。
First Usn : 0x0000000000080000
開始USNが 0x80000 になっている $J ファイルのデータ内容を確認します。
$J のデータ先頭部分は 00 になっています。
$J データのオフセット 0x80000 ⇒ 524288 を確認します。USN レコードが保存されている事を確認できます。
$J のメタ情報で、クラスタの割り当て状況を確認します。クラスタ番号 2184 より前はスパースの為 0 になっています。128クラスタ分がスパースとなっています。（128 x 4096 = 524288 ⇒ 0x80000）
$J の DataRun を MFT レコードで確認してみます。
Data Run 1 : 02 80 00
0 F=Size of the Offset field
2 L=Size of the Length field
80 00 Offset to the starting LCN of the previous element
Data Run 2: 21 40 88 08
2
1
40 ⇒ 64
88 08 ⇒ 2184 ⇒ Cluster No 2184（DataRun 1 Offset 0 + 2184）
Data Run 3...が続く
$J のレコードが増えた場合、データ先頭部分はパージされますが、スパースを利用して USN オフセットの位置は維持されます。
USNレコードのカービング
$J が利用していたクラスタ番号 1992 （1992 x 4096 = 8159232）のデータを確認してみます。クラスタ番号 1992 には USN レコードのデータが残っていることを確認できます。この状態であれば、USN レコードのカービングが可能です。
インデックスとUSN
USN が有効でないボリュームに対して、Index を有効にすると、自動的に USN が有効になります。
参考URL：
CCleaner と GB2312
Talosの記事には、マルウェアにより収集されたデータのスクリーンショットが掲載されています。
Cisco's Talos Intelligence Group Blog: CCleaner Command and Control Causes Concern より部分的に引用
In addition, the compromised machines would share a listing of installed programs.
一部の文字列は漢字のように見えますが、日本語としては読む事ができません。
上記には UpdateAdvisor という文字列があります、Googleで「UpdateAdvisor V3.60 L20」を検索すると富士通のサポートページがヒットします。
検索結果から日本語としては下記文字列が確認できます。カッコ内の文字列は「本体装置」となっています。
「UpdateAdvisor(本体装置)」
この文字列をCode Page 932 (ANSI/OEM Japanese; Japanese (Shift-JIS) でテキストファイルとして保存します。
次に、保存したテキストファイルをCode Page 936 ANSI/OEM Simplified Chinese (PRC, Singapore); Chinese Simplified (GB2312) を指定してテキストエディタで開きます。
記事のスクリーンショットと同じ字形が表示されます。元のデータはCode Page 932だったのでは？
UpdateAdvisor(杮懱憰抲)
他の文字コードを試してみます、Code Page 950 Big5 でファイルを開くと下記になりました。
UpdateAdvisor(?)
この場合、スクリーンショットと同じ結果になりませんでした。
その他の例として、「
」という文字列は「言語工学研究所」ですね。
仮説：
- マルウェアが取得したアプリケーションリストの文字列はCodePage 932だった。
- 日本語版Windows環境でマルウェアは実行された。
- 何らかの理由で取得した文字列はGB2312として処理された。
Security Id と $Secure
Security IDと$Secureの関係について確認します。
[注意事項]一部は不完全なパース結果となっています。
最初にサンプルファイル（crocodile.jpg）のアクセス権を確認します。
ファイル crocodile.jpg のSecurity IDを確認します。
Security ID 値は $STANDARD_INFORMATION 内に保存されています。
MFTレコードでSecurity IDを確認します。（0C 01 00 00）
NTFS DOC の内容に従い、$Secureの内容をパースしてみます。
$Secure ファイルは、 $SDH, $SDS, $SII から構成されています。それらは、$DATAや$INDEX_ROOT、$INDEX_ALLOCATION、$BITMAP などから構成されています。
11.3.2. $SDH Index
18 00 Offset to data ⇒ 24byte
14 00 Size of data ⇒ 20byte
00 00 00 00 Padding
30 00 Size of Index Entry ⇒ 48byte
08 00 Size of Index Key ⇒ 8byte
00 00 Flags
00 00 Padding
DE E3 3D 9A Key: Hash of Security Descriptor
0C 01 00 00 Key: Security Id
DE E3 3D 9A Data: Hash of Security Descriptor
0C 01 00 00 Data: Security Id
F0 06 00 00 00 00 00 00 Data: Offset to Security Descriptor (in $SDS) ⇒ 1776 byte
80 00 00 00 Data: Size of Security Descriptor (in $SDS) ⇒ 128 byte
00 00 00 00 Data: Padding
11.3.3. $SII Index
14 00 Offset to data ⇒ 20byte
14 00 Size of data ⇒ 20byte
00 00 00 00 Padding
28 00 Size of Index Entry ⇒ 40byte
04 00 Size of Index Key
00 00 Flags
00 00 Padding
0C 01 00 00 Key: Security Id
DE E3 3D 9A Data: Hash of Security Descriptor
0C 01 00 00 Data: Security Id
F0 06 00 00 00 00 00 00 Data: Offset to Security Descriptor (in $SDS) ⇒ 1776 byte
80 00 00 00 Data: Size of Security Descriptor (in $SDS) ⇒ 128 byte
11.3.1. $SDS Data Stream
DE E3 3D 9A Hash of Security Descriptor
0C 01 00 00 Security Id
F0 06 00 00 00 00 00 00 Offset of this entry in this file ⇒ 1776 byte
80 00 00 00 Size of this entry ⇒ 128 byte
$SECURITY_DESCRIPTOR (0x50)
6.3.3. Header
Table 2.9. Layout of the $SECURITY_DESCRIPTOR (0x50) attribute header
01 Revision (a)
00 Padding
04 97 Control Flags (b)
34 00 00 00 Offset to User SID ⇒ 52 byte
50 00 00 00 Offset to Group SID ⇒ 80 byte
00 00 00 00 Offset to SACL ⇒ 0 byte
14 00 00 00 Offset to DACL ⇒ 20 byte
SACL
DACL
02 ACL Revision
00 Padding (0x00)
20 00 ACL size ⇒ 32 byte
01 00 ACE count
00 00 Padding (0x0000)
ACE
00 Type ⇒ Access Allowed
00 Flags
18 00 Size ⇒ 24 byte
FF 01 1F 00 Access mask ⇒ 111110000000111111111 ⇒ Full Control
01 02 00 00 00 00 00 05 20 00 00 00 21 02 00 00 SID ⇒ BUILTIN_USERS S-1-5-32-545
User SID ⇒ S-1-5-21-1901480256-120802936-2790681297-1000
01
05 00 00 00 00 00
05
15 00 00 00 ⇒ 21
40 49 56 71 ⇒ 1901480256
78 4E 33 07 ⇒ 120802936
D1 6A 56 A6 ⇒ 2790681297
E8 03 ⇒ 1000
0000
Group SID
01
05 00 00 00 00 00
05
15 00 00 00
40 49 56 71
78 4E 33 07
D1 6A 56 A6
01 02 ⇒ 513
0000
追記
Zaki さんがSecure2Csvというツールがあると教えてくれました。これはとても便利なツールですね！！
GitHub - jschicht/Secure2Csv: Decode security descriptors in $Secure on NTFS
参考URL:
http://www.ntfs.com/ntfs-permissions-file-structure.htm より引用
2.4.2.4 Well-Known SID Structures
https://msdn.microsoft.com/ja-jp/library/cc980032.aspx
SessionEnvとTSMSISrv.dll
CCleaner version 5.33.6162 に関して下記レポートが出ています。このレポートでは、Persistenceの仕組みとしてマルウェアがサービスを利用している事を説明しています。
Progress on CCleaner Investigation より引用
The second part of the payload is responsible for persistence. Here, a different mechanism is used on Windows 7+ than on Windows XP. On Windows 7+, the binary is dumped to a file called “C:\Windows\system32\lTSMSISrv.dll” and automatic loading of the library is ensured by autorunning the NT service “SessionEnv” (the RDP service). On XP, the binary is saved as "C:\Windows\system32\spool\prtprocs\w32x86\localspl.dll” and the code uses the “Spooler” service to load.
上記レポートではDLLのファイル名が「lTSMSISrv.dll」となっていますが、下記シマンテック社の資料では「TSMSISrv.dll」となっています。
Windows 7のデフォルト環境に、TSMSISrv.dll ファイルは存在していません。
SessionEnv サービスは Windows 7 環境にデフォルトで存在する、「Remote Desktop Configuration」の事になります。
マルウェアはレジストリを変更し、このサービスが自動で開始されるように設定します。（デフォルトは手動です）
試しに、SessionEnv サービスを開始し、Process Monitorで読み込まれるDLLファイルを確認してみます。Process Monitor の結果に TSMSISrv.dll が登場します。
私はTSMSISrv.dll を入手していないので、実際にどの様に読み込まれるかは未確認です。
仮に、SessionEnv サービスが自動的にTSMSISrv.dllを読み込む場合、Autorunsツールでは検出できないですね。自動起動の仕組みとしては、見つけるのが簡単ではない点で興味深いですね。
64bit版は「EFACli64.dll」という記述がありますが、これはどの様にロードされるのでしょうかね？
参考URL：
