分析在ntfs文件系统下的数据隐藏(三)

Analysis techniques

Figure 12 shows the flow to analyse hidden data in $DATA attribute of directory.

 

 

Figure 12: Flow to analyse hidden data in $DATA attribute of directory

List directory entries information of all directories

./fls -rDf ntfs /case1/image1 | grep 128

Examine the result for $DATA attributes. For example, the "r/r 40-128-3" is a $DATA attribute which might contain hidden data.

 

 

Figure 13: Result of running fls command to check for $Data attributes in directories

Check the content of the $DATA attribute

./icat -f ntfs /case1/image1 40-128-3 > /case1/dataindirectory1
file /case1/dataindirectory1
hexedit /case1/dataindirectory1

Analysis techniques used to detect ADS in files also detect ADS in directory at the same time. The process has been explained in the previous section and is not repeated here.

HIDDEN DATA IN $BOOT FILE OR BOOT RECORD

Everything in NTFS is a file includes boot record, which is stored in a metadata file called $Boot. In NTFS, this is the only file with fix location, which always starts at the first cluster of the file system. Windows allocates 16 sectors to this file but in usual only half of these sectors contain non zero bit (Carrier, 2005).

According to the documentation about NTFS at Linux NTFS project (Sourceforge, n.d.), there are certain unused bytes in the boot sector. However, Windows would not mount the file system if there is any none 0 values in these unused bytes (Carrier, 2005). As a result, this cannot be used to hide data.

In $Boot file of NTFS file system, data usually is hid at the bytes allocated for boot code. Boot code is essential for bootable file system to locate needed files to boot up Windows (Carrier, 2005). For non bootable file system, it usually used to store the error message that is displayed if users try to boot from this partition.

The size of data that can be hidden in the boot code is unlimited as suspects can simply allocated more clusters to $DATA attribute of $Boot file to hide data.

Procedure to create test data

1) Run list of $Data attribute of $Boot is modified
2) Last VCN value of $Data attribute of $Boot is modified
3) Real size, allocated size and compressed size of $Data attribute of $Boot is modified
4) Allocation status of the additional clusters allocated to $Boot is set to 1
5) Hidden data is pasted to the selected clusters.

Analysis techniques

Figure 14 show the flow to analyse hidden data in $Boot file and backup boot sector.

 

 

Figure 14: Flow to analyse hidden data in $Boot file and backup boot sector

Chkdsk might return error if suspects forget to complete one of the needed step. For example, if any of the first 3 steps is not completed, error message as show in figure 15 will occur. If suspects forget to perform step 4, error message as shown in figure 16 will occur.

 

 

Figure 15: Error message displayed when running chkdsk command

 

 

Figure 16: Error message displayed when running chkdsk command

Analysis of hidden data in $Boot file should start by comparing boot sector and backup boot sector. Let's assume there are 6136830 sectors in the partition.

dd if=/case1/image1 bs=512 count=1 skip=6136829 of=/case1/backupbootsector
dd if=/case1/image1 bs=512 count=1 of=/case1/bootsector
md5sum /case1/backupbootsector
md5sum /case1/bootsector

However, this consistency check would only give indication of file system manipulation if the checksums differ from each other. If they are the same, the possibilities are that suspects copy the modified boot sector to its backup to avoid detection or the file system does not contain hidden data. The extracted content is then analysed with hex editor, foremost and comeforth similar to analysis of hidden data in faked bad clusters. Keyword search can also be performed.

 

UNCOMMON/ INEFFECTIVE DATA HIDING TECHNIQUES

From the perspective of suspects, a good data hiding techniques in NTFS file system should meet the goals of security and capacity as following (Provos & Honeyman, n.d.).

1) Normal system check with utility such as chkdsk does not return any error
2) Hidden data would not be overwritten or the possibility of data being overwritten is low
3) Normal user would not notice the hidden data
4) The technique can store reasonable amount of hidden data

Table 3 shows some uncommon and ineffective techniques which does not satisfy characteristic discussed above.

Table 3: Description of certain uncommon and ineffective data hiding techniques

Data hiding techniques	Weaknesses
Set the allocation bit of certain unallocated clusters to 1 and hide data in these clusters	Simple chkdsk validation would detect this
Hide data in unallocated clusters	High possibility of hidden data being erased unless certain countermeasures are implemented such as set the hard disk to read only access
Hide data in unallocated MFT entries	High possibility of hidden data being erased unless certain countermeasures are implemented such as set the hard disk to read only access
Unused space in a MFT file record	Hidden data is erased if more attributes is added to the MFT file record or the size of an attribute increases.

However, there are certain environments where these hiding techniques might be effective. Let's take data hiding in unallocated clusters as example. If there is hard disk write protector that protects the hard disk or rootkit installed in the system that will never write to these unallocated location, the hidden data would not be erased. As a result, a through check on the system and the physical environment are important and might give some clue about the data hiding techniques used.

CONSISTENCY CHECK ON NTFS

Certain consistency check should be performed on NTFS before any analysis starts. Chkdsk should be performed and if it returns any error, there might be file system manipulation on it that causes the file system in an unstable state.

Default cluster size of NTFS is depends on the size of file system (Svensson, 2005). Usually a normal user would not modify the default cluster size. However, suspects might modify it so that more hidden data can be stored. For example, the larger the cluster size, the more hidden data can be stored in the file slack of a file. A NTFS with cluster size that does not match its file system size is suspicious.

System should be searched for data hiding tools. Attention should also be paid on both digital and physical files that contain some weird numbers that might be the clusters address where hidden data is stored.

CONCLUSION

In general, analysis of hidden data in NTFS file system is divided into 2 phases. The first phase is to identify whether there is hidden data by searching for anomaly. For example, in the analysis of hidden data in faked bad clusters, it is abnormal to have an operating system to detect bad sectors before a hard disk does. This is suspicious and worth further analysis.

The second phase is to recover the hidden file. Due to hidden data is usually stored in the file system without any structure or metadata, it is hard to recover them. Recovery is particularly challenging if suspects store data in random order and remove the file signature.

There is no specific forensic analysis tool that checks for hidden data in NTFS file system except tools that check for alternate data stream. While the analysis techniques that already discussed might be able to detect/recover the hidden data, it is time consuming without automated tools.

The data hiding techniques that have been discussed in this paper are just a fraction of possible way to hide data. There are always new techniques to hide data and the art of data hiding is depends on suspects' creativity. One of the difficulties of analysing NTFS file system for hidden data is that it is so flexible and can support many options (Carrier, 2005). As a result, there are many possible ways to hide data. In addition, without a published specification, which value combinations are valid and which are not is unknown (Carrier, 2005).

 

REFERENCE

Carrier B. (2005, March 17). File System Forensic Analysis. Addison Wesley Professional.

Carvey H. (2004a, July 21). Windows Forensics and Incident Recovery. Addison Wesley.

Carvey H. (2004b). Data Hiding on a Live System. Retrieved September 23, 2005 from [url]http://www.blackhat.com/presentations/win-usa-04/bh-win-04-carvey.ppt[/url]

Cook R. (2005, September 16). Alternate Data Streams: Threat or Menace? Retrieved September 20, 2005 from [url]http://www.informit.com/articles/printerfriendly.asp?p=413685[/url]

Chuvakin A. (2002, March 10). Linux Data Hiding and Recovery. Retrieved September 23, 2005 from [url]http://www.linuxsecurity.com/content/view/117638/49/[/url]

Microsoft (n.d.). The NTFS File System. Retrieved September 13, 2005 from Microsoft.com: [url]http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/core/fncc_fil_khzt.asp[/url]

Kruse W. G. & Heiser J. G. (2001, September 26). Computer Forensics : Incident Response Essentials. Addison-Wesley Professional

Li K. (2003). A Guide to Programming Intel IA32 PC Architecture. Retrieved September 16, 2005 from [url]http://www.cs.princeton.edu/courses/archive/fall04/cos318/docs/pc-arch.html[/url]

Mallery J. R. (2001, July 16). Secure File Deletion, Fact or Fiction? Retrieved September 20, 2004 from [url]http://www.sans.org/rr/papers/27/631.pdf[/url]

Means R. L. (2003). Alternate Data Streams: Out of the Shadows and into the Light. Retrieved September 20, 2005 from [url]http://www.giac.com/practical/GCWN/Ryan_Means_GCWN.pdf[/url]

Mikhailov D. (n.d.). NTFS file system. Retrieved September 13, 2005 from [url]http://www.digit-life.com/articles/ntfs/[/url]

NTI (2004, January 6). File Slack Defined. Retrieved September 20, 2005 from [url]http://www.forensics-intl.com/def6.html[/url]

Paladion Network (2004). Incident handling/ Forensic FAQs. Retrieved September 23, 2005 from [url]http://www.paladion.net/papers/ihfaq.htm#hidden_data[/url]

Provos N. & Honeyman P. (n.d.). Detecting Steganographic Content on the Internet. Retrieved October 4, 2005 from [url]http://niels.xtdnet.nl/papers/detecting.pdf[/url]

sleuth kit.org (n.d.). README. Retrieved September 23, 2005 from [url]http://www.sleuthkit.org/sleuthkit/download.php[/url]

Solomon D. A. & Russinovich M. E. (2000, September 1). Inside Microsoft Windows 2000, Third Edition. Microsoft Press

Sourceforge (n.d.). Foremost. Retrieved September 16, 2005 from [url]http://foremost.sourceforge.net/[/url]

Sourceforge (n.d.). File - $Boot (7). Retrieved September 22, 2005 from [url]http://linux-ntfs.sourceforge.net/ntfs/files/boot.html[/url]

Storagereview (n.d.). Reference Guide - Hard Disk Drives: Reference Guide - Hard Disk Drives. Retrieved September 13, 2005 from [url]http://www.storagereview.com/guide2000/ref/hdd/geom/formatDefect.html[/url]

Svensson A (2005, April). Computer Forensics Applied to Windows NTFS Computers. Retrieved September 23, 2005 from [url]http://www.dsv.su.se/research/seclab/pages/pdf-files/2005-x-268.pdf[/url]

Zadjmool R. (2004, March 24). Hidden Threat: Alternate Data Streams. Retrieved September 20, 2005 from [url]http://www.windowsecurity.com/articles/Alternate_Data_Streams.html[/url]

APPENDIX A: DETAIL PROCESS OF HOW DATA IS HID IN FAKED BAD CLUSTERS

Tool used in this example is Runtime's DiskExplorer for NTFS v2.31. While using this tool to edit the NTFS might seem awkward and too complicated for script kiddies level suspects, it is just a matter of time for a tool that can automate this task to occur. This tool is used here to just to show how NTFS file system can be manipulated to hide data and prepare a test file system for analysis

1) Locate where $DATA of $Bitmap is stored. As shown in Figure 17, it is stored from x0005DA54C and it is allocated 24 clusters. 2) Inspect the clusters that are allocated to $Bitmap.

 

 

Figure 17: $DATA attribute of $Bitmap

3) Any cluster that is unallocated can be used. In this example, 12 clusters (from 383624 to 383635) would be marked as bad clusters to store hidden data as shown in figure 18. Calculation of the cluster number represented by a bit in $Bitmap is shown below:

Cluster number = ((A - B) * C * D) + (E * F * D) + (G * D) + H - 1

A = sector address of current sector
B = starting sector for $Data attribute of $Bitmap
C = number of bytes in a sector
D = number of bits per byte
E = number of rows before the targeted bit
F = number of bytes per row
G = number of bytes before the byte for that bit
H = location of the bit in that particular byte. For example, H=1 for 01 and H=4 for 08

For example, calculation of the bit that represents cluster address 383524 in $Bitmap is shown below:

Starting sector for $DATA attribute of $Bitmap: 029FE8D6
This sector: 029FE933
Cluster number = ((029FE933 - 029FE8D6) * 512 * 8) + (21 * 16 * 8) + (1 * 8) + 1 - 1
= 380928 + 2688 + 8
= 383624

4) Set cluster 383624-383635 as bad clusters in the run list of $BAD attribute as shown in figure 19. Note that this is an Intel PC and it uses little-endian-ordering, which put the least significant byte of a number in the first storage byte (Li, 2003). For example, 383624 (05dA88) is stored as 88DA05
5) Modify the size of the $Bad attribute to 0x58
6) Modify the size of the MFT to 0x180

 

 

 

Figure 18: Allocation status of faked bad clusters is set to 1

7) Hide data into that cluster 383624 using the "paste from file command" in DiskExplorer
8) Run chkdsk in Windows XP to ensure there is no structure error happen after modification.
9) The result is tested using Sleuth Kit before and after data is hidden. Before data is hide in the faked bad cluster, run dstat to ensure the target clusters are unallocated and istat to ensure no cluster is assigned to $BadClus. Example:

dstat /dev/sda2 -f ntfs 383624, repeat this for all targeted clusters
istat /dev/sda2 -f ntfs 8

10) After the data is hidden, perform the same commands again to ensure the clusters are allocated to $BadClus properly. Besides dstat and istat command, dcat command is run to check to content of hidden data. It is also recommended to try to extract the hidden clusters with dd command in Linux and try to open the file. Example:

dstat /dev/sda2 -f ntfs 383624, repeat this for all targeted clusters
istat /dev/sda2 -f ntfs 8

dcat /dev/sda2 -af ntfs 383624, repeat this for other clusters
dd if=/dev/sda2 bs=4096 skip=383624 count=12 of=/mnt/usb/recoverfile

 

 

Figure 19: Modification on the $Bad attribute of $BadClus file to create faked bad clusters

 

0人

了这篇文章

类别： 网络安全┆阅读( 0)┆评论( 0) ┆ 返回博主首页┆ 返回博客首页

上一篇 分析在ntfs文件系统下的数据隐藏(二) 下一篇 剖析NTFS下数据流的隐藏

相关文章

• 深度解析NTFS文件系统
• FreeBSD下挂载EXT2,FAT32,NTFS文件系统解决方案
• NTFS文件系统
• NTFS文件系统的安全性特点是什么

职位推荐

• web前端开发工程师
• 网络安全工程师
• 信息安全渗透工程师
• 安全开发工程师-支付产品技术部
• 渗透工程师/资深渗透工程师

文章评论

 

 

发表评论            

昵  称：

登录  快速注册

验证码：

点击图片可刷新验证码请点击后输入验证码博客过2级，无需填写验证码

内  容：

同时赞一个

每日博报 精彩不止一点

Copyright By 51CTO.COM 版权所有