明德鑑識科學班 培育未來柯南

十二年國教高中要力拚特色，新北市明德高中和鑑識專家李昌鈺博士合作，將成立國內第一所高中「鑑識科學專班」，要培育未來的柯南和福爾摩斯，吸引基測達前三志願的考生申請。李昌鈺預定九月回國親自主持開班典禮，明年十二年國教上路後，鑑識科學專班將採特色招生選才。

美國電視影集《CSI犯罪現場》廣受歡迎，也讓鑑識科學變熱門，但國內鑑識人才的培育管道很有限。明德高中校長黃棋楓指出，「鑑識科學專班」要招收四十名國三畢業生，分為刑事鑑識、經濟鑑識兩組，相當於高中自然組及社會組，傳授刑事犯罪和經濟犯罪科學基礎鑑識課程。

今年九月第一年試辦師資採外聘，由警察大學、警專、台北大學、法務部調查局、刑事警察局和李昌鈺博士物證科學教育基金會教授群，親自到高中授課。

黃棋楓說，歐美等國都極力培養鑑識科學人才，曾任美國康州警政廳榮譽廳長的李昌鈺，更在康州致力發展鑑識科學教育，美國目前已有近二十所高中成立鑑識科學班，澳洲、英、法、德等國也在積極培育鑑識人才；台灣則由明德高中開先鋒。

「鑑識科學專班」除了一般高中必修課程外，高一、高二各選修五學分專業課程，包括會計學、資產鑑價實務分析、電腦審計與內部稽核，及物理、化學、生物鑑識科學和犯罪現場調查概論等。

高三上學期要準備學測考試，不開專業課程，但高三下學期甄選入學放榜後，將和大學合作開三個學分的先修課程，先修學分升上大學後可抵免，學生也會到警大、刑事局見習。

黃棋楓說，將和開設相關科系、學程的大學洽談，希望每所大學提供一到三名繁星推薦名額。今年第一年試辦，第一階段免試入學已吸引十二名校排名前百分之五的 國三生報到，第二階段申請入學也錄取七名考生，包括基測成績三九六分可進前三志願程度的考生，其餘名額將留給登記分發錄取學生就讀。

大學開鑑識學程 成風潮

黃棋楓表示，鑑識科學人才的起薪相當誘人，刑事鑑事人員起薪「55K」，法務部調查局負責經濟鑑識的三等調查員，起薪更高達「77K」。另外，從事不動產 或動產的鑑價，也需要科學鑑識人才。目前除了警察大學和警專外，一般大學體系的中正大學、東吳大學、台北大學都開設鑑識學程。技職體系的台科大則先在通識 課程試水溫，在校內成立第一個與鑑識科學相關的資通安全中心。

與李昌鈺博士交情深厚的台科大前校長陳希舜，曾邀李昌鈺到台科大擔任講座，每場都爆滿。陳希舜認為，讓學生接觸跨界、跨領域的知識，有助於創意激發；東吳 大學「鑑識科學學程」是前行政院長劉兆玄擔任東吳校長任內規畫，結合理學院的物理、化學、微生物、心理四個系，和法學院合作開設鑑識科學。

台北大學則開「資本市場鑑識學分學程」，必修學分包括犯罪學、鑑識會計與犯罪偵察、經濟犯罪專題研討等，主要在培育經濟鑑識人才，防範經濟犯罪、查假帳、洗錢等。

轉自：http://www.merit-times.com.tw/NewsPage.aspx?Unid=312953
 

電腦鑑識與鑑識會計

轉自 law

筆者算是國內比較早接觸電腦鑑識(數位鑑識)這個領域，大約在91年間就開始閱讀相關文獻，但是那時候很少資料，連英美國家的電腦鑑識書籍，也非常少，而且概念非常混亂。(那時候差不多是網路剛興起及網路泡沫時代)

為了讓資訊科技發達的我國，也不會與電腦鑑識這個時代潮流脫節，經過努力整理當時各國的書籍與文獻，曾經於93年間出版過一本「電腦鑑識與企業安全」，但是當時這個領域太冷門，出版社後來好像也不知去向，這本書也絕版了。(希望不會是因為本書)

但無論如何，也成就了亞洲應該是第一本有關電腦鑑識的書籍。雖然從現在的角度來看，這本書的內容頗為粗淺，但畢竟是一個小小里程碑......

過了幾年，實務上有了長足的發展，政府部門也在95年間成立了第一座實驗室，又建立了第二座里程碑。

筆者沒有再深入學習進階的電腦鑑識，開始再開發更冷門的數位證據領域，也在98年間寫了一本「圖解數位證據」的著作，將法院判決中的錯誤見解，在清楚又簡單的編排架構下呈現出來。當然這個領域還是很冷門，所以銷售情況依舊慘澹。

不過這類型的書籍本來就不是以銷售為目的。經過幾年，感覺這個領域一直在冰箱中，冷到不行。在此冷到不行的同時，筆者也在100年6月完成了法律博士的學位，主題也就是「數位證據」。

99年間個人資料保護法的通過，電腦鑑識的領域突然熱門了起來。也許是電腦鑑識可以幫助瞭解資料外洩的原因，可以作為企業免責的證明，再加上個人資料保護法的賠償金額過高，迄今每一場相關的研討會都是滿場，其中也幾乎都有一場是有關電腦鑑識的議題。

本來筆者並未有意踏入個人資料這一個領域。

為什麼呢？

理由很簡單，電腦鑑識並非僅與個人資料有關係，電腦鑑識應該是與每個領域都有關聯性，因為每個領域都有可能涉及到數位證據，電腦鑑識就是一種嚴謹的採證與分析數位證據的程序。

但是筆者聽過許多講座之後，發現許多主講者也許是為了資訊產品的行銷，講偏了電腦鑑識的真正意涵，搞得好像個人資料保護法的立法目的，是為了相關資訊產業能賣出產品。

所以，近來筆者開始公告將整合個人資料保護法與電腦鑑識領域，從非商業產品推銷的角度，將正確的知識推廣給想聽的朋友。

目前也在短短的兩個月不到的期間講了六場，全省超過千人聽過，更利用自己的休閒時間，三個月內已經完成「圖解個人資料保護法」的著作，就等101年年中施行細則的通過，即可出版，相信屆時可以作為有需要朋友的參考。

最近有某研究所的教授徵詢筆者意見，希望能在其「鑑識會計」的課程中，向研究生解說一下電腦鑑識的概念。如上圖，電腦鑑識確實為鑑識會計領域中的一小部份，透過電腦鑑識的方式，找到企業營運的問題與弊病，如同前面所述，每個領域都有可能涉及到數位證據。

鑑識會計在100年高考三級中，也首次成為考題，看來繞著電腦鑑識領域打轉的議題，也將會愈來愈多。

和亞桑傑通聯 美大兵證實洩密維解

法新社馬里蘭州米德堡20日電：美國大兵曼寧（Bradley Manning）遭控向維基解密（WikiLeaks）網站洩密。軍方調查人員今天首次端出直接連結曼寧和維解創辦人亞桑傑（Julian Assange）的證據。
 

調查人員出庭作證時表示，曼寧電腦硬碟裡發現亞桑傑的聯絡資訊。曼寧案庭訊將決定他是否需至軍事法庭受審。
 

數位鑑識專家也表示發現曼寧和另1名網路帳號為「亞桑傑」的電腦使用者交談證據。
 

庭訊在馬里蘭州米德堡（Fort Meade）基地舉行，目前已進入第4天。今天的證詞是截至目前政府在建立曼寧和此案關聯上，所拿最具說服力的證據。此案也是美國史上最重大情資外洩案之一。
 

美軍電腦犯罪調查小組（CCIU）的約聘人員強生（Mark Johnson）表示，曼寧電腦硬碟裡有亞桑傑的聯絡資料。
 

軍方檢察官展示硬碟檔案1則訊息的螢幕快照，當中顯示：「你可以直接連絡我們在冰島的調查編輯－354 862 3481－24小時都可－找亞桑傑。」
 

調查人員也指出，他們回復曼寧和1名為「亞桑傑」的電腦使用者之間的交談紀錄，當中在討論維基解密。

轉自 http://www.cdnews.com.tw/cdnews_site/docDetail.jsp?coluid=109&docid=101766046

Windows 8 Forensic Overview

I finally submitted my term paper for my Forensics class, While there are some things to be said for waiting until the last minute, my problem was as I delved into the four points I wanted to cover, I found Windows 8 exhibiting some interesting behavior, I also noticed that some of the things I thought would change, did not.


I will be making my paper available for download soon, but I need to clean up a few things, and will let you know when you can grab it. Meanwhile, here is a few things that I want to pass on. 

When I initially started this paper I took a dive into Windows Registry I was at a loss with what to look for. I posted questions onto Twitter with some guidance of where to look. Eventually I stumbled across the Registry Key called TypedURLsTime, trying to decipher the value contained in the data field I posted to Twitter the information I was looking at.  Harlan Carvey explained that this data is filetime data; I came to rely on the experience of Harlan and others as I asked questions, I am grateful for their experience and willingness to answer my questions and be patient with me. Harlan, went as far to help as sending me a copy of his Windows Registry Forensics book, this is an incredible resource for anyone interested in looking at and understanding the registry.

Building off what I learned from Harlan's book Windows Registry Forensics I was able to confirm that the primary registry hives, SAM, System, Security, Software, NTUser and UsrClass all were retained within Windows 8.  I returned to the Registry Keys for the typedURLs and TypedURLsTime and did some more digging around. Here are the keys below for reference, as you can see URL10 is in both locations, one showing the location visited and the other the filetime that is was accessed.

Through some more analysis of the registry I came across the following keys, which appear to be related to the Immersive Browser that Microsoft is pushing in Windows 8. I attempted to test the typedurls-immersive-browser key, but this feature was not accessible in this build.

While listening to Wade Wegner presentation at the 2011 Build conference, Microsoft touted the ability to allow applications and user to save data to the cloud. With the option of using your Windows Live ID as your user name to facilitate this idea I decided to look a little more regarding this. I found the following while digging into the directory structure of a Live user:

C:\Users\USERID\AppData\Local\Microsoft\Windows\Live\Roaming\2d5b1639895c2556\CloudSync

Within this directory there were numerous files with the SDF file type, some of the files are named the same as the immersive browser keys in the previous images. I decided to look further into the registry to see if I could find any reference to the CloudSync option and I came across the following:

It appears that the Immersive Browser and CloudSync Registry keys will need to be analyzed further. I am planning on looking into them more over the next few weeks, will update blog with the information.

When I was typing out this blog I had I was going to delve deeper into Jump Lists, but they appear to be similar to the Windows 7 area, and felt that my research could be utilized in a different approach. It does not appear that Metro Applications keep a jump list; instead they keep their information in the respective program folder within AppData. I noticed this behavior while utilizing the PicStream Metro App. Digging into the file path I found the following folder structure:

Within each of those sub directories there was a regular file and a file slack for each image I viewed through Picstream application. Further research should define the naming convention of the INetCache sub directories.

Within the Windows 8 Operating system, they have introduced file history backup which changes the way that backups were previously used. In previous versions of windows, backups could only be maintained and restored using the default system. Within windows 8 this solution is more robust and allows backups to be stored both on removable media and remote network shares. By default this will backup folders such as Music, Documents, Videos, Contacts and Favorites.

There are a few artifacts that are established when file history is turned on, this includes File History folder, Registry Value, and Windows Events. The file history folder can be found at C:\Users\USERID\AppData\Local\Microsoft\Windows\FileHistory within this folder there is a configuration folder and a data folder. The data folder is a temporary staging directory for the files that are to be backed up. The Configuration folder contains at least 2 files, they are an EDB file named Catalog#.edb and a XML file names Config#. These files are created both Locally and on the drive being used as backup. As of this writing I have not be able to explore the EDB file. The Config file on the other hand offers the following information: 

If the File History option has been turned on there is also a registry key that is created, this key is only found on users that have turned on this feature. The Registry key can be found at:

HKU\Software\Microsoft\Windows\CurrentVersion\FileHistory 


Within this directory there is a key named ProtectedUpToTime that shows the last time this process backed up the files. This value can be deciphered utilizing a 64 Bit Hex Value - Big Endian values. The DCode application can handle this.

There is also another area in the HKLM registry that may provide more information and keys of importance, this is t. This is the FHSVC which is the File History Service and can be found here: 

HKLM\System\Controlset001\Services\fhsvc. 

Keys in the FHSVC folder













Keys in the Config files

Another area worth looking at in gathering File History information is within the System Events. The following Event Sources provide us with auditing information related to the File History:

• FileHistory-Catalog
• FileHistory-ConfigManager
• FileHistory-Core
• FileHistory-Engine
• FileHistory-EventListener
• FileHistory-Service

The final features of Windows 8 that I am going to cover in this blog are the Refresh and Recovery options. The Recovery feature will bring your windows to a factory state, similar to re-installing the operating system, the refresh feature acts like a restore point, but will clean everything needed for the OS to run, leaving individual files, and applications from the Microsoft store untouched, deleting any other 3rd party application.

When looking at a refreshed image of the windows operating system within AccessData FTK Imager, there are three items that are quickly noticed. These are two partitions and an unpartitioned space.

Partition 1 is a 350MB partition that contains the information needed to boot up the operating system. There are a few interesting files that can be found in this partition that can provide some more clues about what has happened on with the operating system and if the device has been recovered or refreshed. When comparing this partition against machines that have had the refresh/recover option ran against them and those that have not we can see some differences in files.

The screen shot on the left is from a machine that has not been refreshed or restored, while the one on the right has been refreshed. From my analysis of this partition from a refreshed or recovered is there will be more unallocated spaces in a recovered machine. On all images there is a folder called Recovery in the System32 folder, within this directory there is a file called ReAgent.xml, this file is used to recover or refresh. 

On a Refreshed/Recovered machine there is a new folder named Log under the recovery folder. In that folder is a file called Reload.XML. The Reload.xml is an updated ReAgent.xml file; it will also have a different timestamp from the ReAgent. This folder and file will give a good idea if the machine has been refreshed or restored. Out of the 24 lines in these xml files, the only line different is:

                    

For a non-refreshed or recovered system the state and status would both be 0.

Partition 2 is the main system partition that is mapped to the C: Drive. This partition also allows us to know if the machine was refreshed or restored. A restored machine will have a lot of unallocated spaces of various sizes that can still be data carved against. The directories and files shown between a Restored and a Non-Restored machine will be similar, but against a refreshed machine there will be two new Directories that contain data. These folders are the $SysReset and Windows.old, as can be seen below.

Within these folders we can still access the previous data that was on the drive, this data still remains in its file structure under the Windows.Old folder. Within the $SysReset there are two directories that contain what appears to be potential useful information. Within the Logs folder there are three files that will provide some usable data. The SystemResetPlatform.log and the setupact.log provides details of what was changed, the MigLog.xml will contain the Users that were retained and their current mappings. This can be beneficial after a reset a user account is deleted.  There two files located in the Framework/Migration/Preserve that also may provide evidence at a later date, they seem to deal with the Microsoft Store, and since this feature is currently not available I am unable to investigate.

Over the next few months I will research more artifacts that might be left behind in Windows 8, and the behaviors that the new operating system brings with it. As more features are unlocked there is potential for more locations that must be analyzed to find the big picture.


轉自 http://randomthoughtsofforensics.blogspot.com/2011/12/windows-8-forensic-overview.html 

Back to Basics, CD and DVD basic forensics

At G-C (my company) we try to have an internal training topic for about 30 minutes to an hour every day (that I'm in the office). Often times we will go over case studies of recently solved cases but other times we get back to basics because you can't assume everyone knows everything you do. One class we recently did was on CD/DVD forensics and since it was received well I thought I should do a similar thing here on the blog. I admit I was watching the barefoot contessa's 'back to basics' show before i wrote this so the title is most likely influenced by delicious food.

I think a lot of people have forgotten about DVDs and CDs as important forensic evidence with the widespread use of cheap reusable USB storage (commercially introduced in December 2000 (Thanks wikipedia!)), but back when I got started (1999) it was very much 'a thing'. There are four important things we can determine forensically from a CD/DVD.

1. The volume name of the CD (always)
2. When it was burned (always)
3. What software made the CD (sometimes)
4. The previous burns (always)
and some easter eggs.

1. The volume name of the CD
All of the CDs I reviewed start with a ISO9660 session on the disk which began at an offset of 8000. You can see in the screenshot below that standard identifier has been set as 'CD001' which is the default for most burners when a ISO9660 session is selected. However what we care about is right after that the name of the CD is ' Oct 28 11 09:33'.

You may think, why do I care about this, this is the volume name that I can see in any tool? Well if you have a multi session disk the volume name will be set to the current session, this may be the only way you have to determine the labels of the prior sessions. We will talk more about sessions in 4.

2. When it was burned
Near the end of the ISO9660 session block are four time stamps, I've always seen them set to the same time. This is the time the CD/DVD was created.

Let's break the timestamp down to a more readable form:

2011102808333500è
2011102808333500è
2011102808333500è
2011102808333500è

As you can see each of them terminates with ascii character è which is hex E8. Breaking down an individual entry we can see that the time is:
2011 10 28 08 33 3500
So October 28, 2011 at 8:33:35am is when the CD was burned, notice this is one hour off of the CD label time. Note that this time is only as accurate as the system clock that burned the CD/DVD.

3. What burned it
Depending on what software burned the CD/DVD many of them will also place the name and version of the software in the reserved space of the ISO9660 session start. In our example we can see that the name of the software that burned it is 'PRASSI2.1.374'.

Doing some quick searches for 'Prassi cd burning software' reveals that this is Primo Prassi version 2.1.374 a now defunct company whose software was bundled with some CD/DVD burners.
Why do we care? If you are trying to prove that a CD/DVD was burned on a particular system matching the software name and version to what was installed on the system can be one indicator that you can use.

4. The previous burns
If you are inspecting a rewritable CD/DVD and it has had more than one write burned to it, then each of the writes are still available. There are multiple layers of burnable media within a rewritable disk and when inserted into a CD/DVD ROM your computer will only show the most recent session. When you image the CD/DVD using a tool like FTK Imager all the prior sessions will be viewable. This is why determining the name of the session may be important as we detailed in 1.

5. Easter Eggs
Sometimes you'll find something unexpected. The ISO9660 specification does not state what can't exist within the reserved space of the session start and systems don't parse for unused areas. For instance within MSDN DVDs you'll be Microsoft's name, address and phone number. What is contained within the session start beyond what we've described here will also depend on what the burning software programmer decided to place within it.

That's it, I hope this shined some light on a possibly forgotten set of facts. Let me know what you think, your comments help to motivate me to keep posting in between baby bottles. 

轉自 http://hackingexposedcomputerforensicsblog.blogspot.com/2011/12/back-to-basics-cd-and-dvd-basic.html 

HowTo: File Extension Analysis

Many times when I am browsing through online lists and forums, I see questions geared along this avenue; an analyst finds a file with a specific extension, and wants to know which application uses it or may have been used to modify that file.  Most times, this is just a small part of a much larger question, and initial attempts to answer the question via Google searches may have led to additional confusion (specified application does not appear to be installed on the system, etc.).  However, there are things that an analyst can do to answer that question using the data currently available, within the collected image.

File Extension Analysis
So you have a file that you're interested in, along with a path, name, and extension, and you want to know which application may have been used to create or modify that document.  One way we can go about this is to use Registry analysis.  Within the acquired image, locate the Software hive (usually in the path "\Windows\system32\config"), and within that hive, look to the Classes key.  Many of the first subkeys that you'll see beneath this key are file extensions, such as ".3g2".  The "(Default)" value of this key is "QuickTime.3g2", which indicates that this system will attempt to open a file with this extension using the QuickTime application.  Additionally, the "OpenWithList" subkey includes a subkey named "QuickTimePlayer.exe". Locating the key "Classes\QuickTime.3g2", I saw that that key had a "shell\open\command" subkey with a "(Default)" value that pointed to QuickTimePlayer.exe (along with the complete path to that file).

As another example, beneath the "Classes\.aa" key, the "OpenWithList" subkey contains a subkey named "iTunes.exe", which indicates that the iTunes application will be used to open a file that ends in the ".aa" extension.  Some extensions may have multiple subkeys beneath the "OpenWithList" key, which serves as an indicator to the type of file with which the extension is associated.

Other keys beneath the "Classes" key may have different information that may indicate how the file had been accessed or used on the system.  On a system I was looking at, I found the ".rnk" extension, and the key only had a "(Default)" value with "rnkfile".  I then located the "Classes\rnkfile" key, which had a "shell" subkey, with additional subkeys that referred to different commands.  When I went to the command line on that system and typed "assoc rnkfile", the response was "rnkfile=Dial-Up Shortcut". 

As this technique is based on Registry analysis, analysts need to keep in mind that it may often be unique to the system being analyzed, and findings on one system may not necessarily map directly to or represent those on another system.  Also, these artifacts are based on file associations, which many times will be set when an application is installed, during the installation process.  As such, when the application is uninstalled, those associations may be removed.

As this technique involves Registry analysis, there are other areas you can check, as well.  For example, each user hive (XP) has a "Software\Classes" key within the NTUSER.DAT hive that may contain file associations specific to the user.  On Vista and above systems, this information will be located in the root of the USRCLASS.DAT hive.  You can also look to the RecentDocs key within the NTUSER.DAT hive to see which files the user has accessed, by extension.  Also, if you suspect that someone may have purposely deleted any of the keys or values of interest, be sure to use regslack to check the unallocated space within the hive files for those artifacts.

If you have a file name (as opposed to just an extension) you might open up the user's hives in something like MiTeC's Windows Registry Recovery tool or the Registry Decoder from DFS, and search for the file name...you may find a reference in the application MRU listing.

轉自 http://windowsir.blogspot.com/2011/09/howto-file-extension-analysis.html

Windows 7 Registry Forensics

How is management going to handle this situation? A typical approach would be to confront the workers. However, they most likely would deny any wrongdoing and probably try to obfuscate any potential evidence. Probably the best approach would be to covertly triage the live computers and perform post-mortem examinations of their hard drives. Frequently a business or corporation’s IT department members will lack the necessary qualifications or experience to perform these types of forensic examinations. This is not uncommon since IT personnel normally are not trained as forensic examiners.

Usually management will have to contract with an external digital forensics consulting firm to provide the services. In today’s world, it has become essential that management have processes in place (i.e. a plan) such that when an intrusion occurs or employee misconduct is alleged, they will have a firm foundation to support and assist with any potential civil or criminal proceedings. Failure to do so can have a detrimental effect upon the business or corporation.

Background
A Windows computer system has several forensically important areas where probative information can be found: in the computer’s RAM (if the system is live), in the Registry, or on the computer’s hard drive. The examination and extraction of probative information from a live computer system involves the use of triage tools which themselves will make changes to those same forensically important areas! Although this violates the “golden rule” of digital forensics, in some circumstances there is no alternative. Presuming that examiners have previously verified the functionality of their triage tools, they should have a fairly good understanding, and be able to document, what changes are made to a live computer system when they use those tools.

Unless they are involved in incident response, examiners are not often confronted with having to image a live system. Normally they would forensically image computer hard drives post-mortem, in a controlled work environment. The image would then be examined for probative information. Most forensic tools incorporate automated built-in features such as recovering deleted folders, performing keyword searches, carving data from unallocated space, searching directories and files, and so forth. Automated features are a necessity as it would be extremely labor intensive for an examiner to manually search a hard drive. In today’s digital forensics environment, examiners must have specialized training, knowledge, skills, abilities, tools, and experience to ensure reliable and repeatable results when triaging either a live system or examining a computer hard drive post-mortem.

What Is the Windows Registry and What Does It Do?
Early Windows operating systems included a “WIN.INI” file (which controlled the desktop and all applications on the computer system) and a “SYSTEM.INI” file (which controlled the computer’s hardware). They also used the configuration files “config.sys” (which loaded device drivers) and “autoexec.bat” (which ran startup programs and set environment variables). When Windows 3.1 was introduced, it was initially targeted to the corporate work environment. One of the assumptions made was that very few Windows applications would be installed on each computer. This would then limit the number of stored system and application settings. Since program developers still needed to store application specific settings, they used individual “.ini” human readable text files which were linked to the “WIN.INI” file. These were generally organized in groups located in a shared location. However, there were a number of drawbacks to this practice: it did not allow for user-specific settings in a multi-use environment; there were no rules placed upon their storage by the operating system; their proliferation and storage anywhere on the hard drive made it difficult or virtually impossible to manage and optimize their performance; and their size limitations and slow access often hindered system operation.

The release of Windows 95 introduced a new concept, the “Registry.” Its purpose was to store all application settings in a standardized binary format in a centralized location and replace text-based configuration and “.ini” files. Because it provided one unified solution for accessing both system and application settings, the Registry was initially praised by developers, users, and administrators. Its advantages included: the binary format allowing for more efficient file parsing; Registry settings loading from user-specific paths; permitting multiple users to share the same computer; accessing a computer remotely, allowing for ease of backups and restorations. However, the introduction of the Registry created another whole set of unintended consequences: it now became more difficult to back up and recover individual applications; automated installers and uninstallers became more complex because configuration settings had to be created by the applications; a damaged or corrupted Registry might fail to load the device drivers necessary to boot the system. With the continuing requirements and demands of complex applications and network solutions, each iteration of the Windows Registry has grown larger and more complex.

The Microsoft Computer Dictionary, Fifth Edition, defines the Registry as: “A central hierarchical database used in Microsoft Windows 9x, Windows CE, Windows NT, and Windows 2000 used to store information that is necessary to configure the system for one or more users applications and hardware devices.” Windows XP, Windows Vista, and Windows 7 also contain a Registry. Although referred to as a “central hierarchical database,” the Registry is in fact a collection of files that are located in the “C:\Windows\System32\config” and “C:\Users\(Username)\” directories (Windows 7). The Registry contains information that Windows continually references such as the applications installed on the computer, the user profiles, the hardware on or attached to the system, property sheet folder settings, the ports being used, application icons, and so on. From a forensic perspective, the Registry is a gold mine that can often provide probative information to an investigator. For instance, some of the information that can be found in the Registry includes:

• All the wireless networks that the computer has connected to
• Recent search terms
• Lists of the most recently used files or applications
• Autorun locations that list applications to automatically run when the computer is booted
• Contents of the User(s) desktop
• All USB storage devices that have been attached to the computer
• Malware (if it has installed itself as a service)
• The directory structure and file names contained on external devices that have been attached to the computer (pre-Windows 7)

While the Windows Registry is forensically important, frequently it is not captured during the triage of a live system. Similarly, it is often overlooked during post-mortem examinations. Daily, examiners are faced with many challenges: a lack of training to perform triage on a live system; examining multiple hard drives containing terabytes of data; dealing with pressures from management to complete an arbitrary, often unrealistic, quota of examinations per month; constantly juggling and prioritizing overwhelming case loads; shortages of personnel; and until recently, limited tools for examining Registry files. When faced with these challenges, it is easy to understand why the Registry is not often forensically examined.


轉自 http://www.dfinews.com/article/windows-7-registry-forensics-part-1?page=0,1

重生：Windows數據恢復技術極限剖析

重生：Windows數據恢復技術極限剖析（簡體書）

I S B N：730225012X
I S B N 13：9787302250128

作    者：馬林
裝訂： 平裝
出版社：清華大學出版社（大陸）
出版日：2011/07/01

一次使用多種鑑識程式 以交叉驗證提高證據公信力

中央警察大學資訊密碼暨建構實驗室（ICCL）

數 位證據的鑑識結果常常因為所使用的工具軟體不同而導致有所差異，而且僅僅依賴一種鑑識軟體所做的鑑定結果，會有人為操作錯誤以及產生誤差的可能性，也容易 被質疑該鑑識軟體的可靠性。因此，本文將以相同的數位證據在Windows-Based鑑識工具以及Unix-Based鑑識工具下的鑑識結果，達到不同 作業系統之間數位鑑識公信力為目的。

傳統犯罪隨著當代資訊科技與網路的發達，而產生許多新興型態的資訊犯罪模式。犯罪者藉由資訊科技與網路將犯罪領域延伸，傳統的偵查技術和方法不足以偵查存留在資訊設備與網路中的線索，再加上網路具有隱匿的特性，已逐漸成為治安的死角。  

  因此，唯有藉助專門的電腦犯罪偵查技術和方法才能有效地進行偵查。現今的資訊犯罪偵查以結合傳統證據和數位證據偵查模式為主要趨勢。  

由於數位證據的鑑識結果會因為所使用的工具軟體不同而有差異。而這其間的差異，往往是嫌疑人及其辯護律師的質疑重點。  

法官也常將鑑識結果，轉交由原鑑識單位以外的第三方做進一步的檢驗，以確定其結果是否正確無誤。這個證據檢驗的往返，不只浪費許多時間，也突顯出數位鑑識結果未經交叉檢驗的缺點。  

為了要得到具有公信力的檢驗報告，就必須了解各項鑑識軟體的功能與特點，比較並確認是否存在支援或互斥的關係。  

如果能在送上法庭之前就先以不同種類的工具，做第二次檢驗，例如對於Windows作業系統的數位鑑識結果，除了第一次檢驗時使用Window- Based的EnCase工具軟體作鑑識之外，再一次使用Window-Based的Forensic Toolkit（FTK）的鑑識軟體做第二次的檢驗。  

而對於使用FTK工具軟體做第一次檢驗的Windows作業系統的數位鑑識結果，再一次使用EnCase工具軟體做第二次的檢驗，以驗證其所得到的結果是否相同。  

那麼，發生人為操作錯誤的機率，應可降到最低，並且，也能大幅提升數位證據的法效性（即「證據能力」）。  

數位鑑識及工具簡介 
數位鑑識所得到的數位證據並不是實體物質，並且其具有三個主要的特性：容易複製與修改、不易證實其來源及完整性、無法直接被人類所感知及理解的內容。  

在數位鑑識的過程，為了使數位證據具有法定效力，根據ACPO國際電腦證據組織（Internation Organizatioin of Computer Evidence）於1999年提出的「The Good Practice Guide for Computer-Based Evidence」電腦證據指導原則，才能讓數位證據在法庭上具有其法定效力。  

數位鑑識程序 
就一般的情況來講，具備證據能力之後，該證據是否能夠有效連結案件，呈現證明事實，形成法官心證，亦即證明力，其關鍵就在於證據和犯罪事件關聯性是否緊密。
 
在部分執法人員如果缺乏數位證據蒐集、檢驗、分析的訓練、知識與技術，不熟悉數位證據處理準則並且沒有遵照程序取得數位證據，證據的取得是否具備證據能力備受質疑，遑論所證犯罪事實是否足以採信。  

數位證據易於複製與修改、不易證實來源與完整性、不易蒐集取得、無法被人類直接感知與理解等特性，取得證據的作為更須小心謹慎，避免脆弱的數位證據因人為不當取證因素，而喪失證據能力及減弱證明力成效。 邏輯性鑑識的程序運作包括以下幾項：  

1. 證據收集：最常見的做法為磁碟備份、復原及密碼破解工具軟體。事實上，證據收集必須在任何資訊能夠存在的角落進行收集工作。不管是網路上或電腦中，根據犯罪手法的不同，得使用不同的工具進行蒐證。  

2. 證據保存：對脆弱的數位證據來說，保存的工作相當重要。因為保存不當會降低 證物日後在法庭上的證據力和證明力。對於採證的過程應詳加記錄，且要在不改變或破壞證物的情況下取得證物。非必要時也不得關閉電腦，因為像記憶體中揮發性 的資料會隨著電源的關閉而流失，重要的證據可能因此而消逝。另外，蒐證時盡可能保持兩人同時參與的原則，防止資料單一竄改的顧慮。  

3. 證據檢驗及分析：必須從收集到的資料中找尋與犯罪相關的證物，包括文字、圖片、影像、聲音及被刪除的檔案。在取得證據之後，將證物做分類、比對及個化，並嘗試與不法行為做連結，以確認嫌犯者的罪行。
 
4. 證據呈現：由於數位證據是抽象的，加上法官等司法人員對電腦鑑識知識並非全然清楚，所以證據的取得必須做完整的解釋說明，且要能邏輯性說明在蒐證的過程中證物沒有遭到改變，以確保證物的證據力。  
數位鑑識工具 
因應不同的網路犯罪（Cyber Crime）型態，一般的作法是對於犯罪現場的電腦系統做出不同的檢驗，利用鑑識工具將電腦主機的系統建立複本，再從複本上進行徹底的檢驗及搜尋動作。  
較常使用的鑑識工具包括EnCase、NTI Forensic Utilities、Access Data's Forensic Toolkit（FTK）、Knoppix STD等，雖然有些工具有圖形化介面，但仍以文字介面居多，使用者最好具有Unix/Unix-like的使用背景。  

以下針對最常使用到的鑑識工具軟體EnCase、FTK（Forensic Tool Kit）和TCT（The Coroner’s Toolkit）做概略介紹。  

Encase
Guidance software公司所生產的EnCase軟體，在電腦鑑識領域享富盛名，此軟體的評價深受全世界肯定，而且擁有一群研究團隊時常公開發表新的鑑識技術，更為此軟體打下一針強心劑。  

此軟體為目前台灣地區警政署、法務部調查局及國安局等相關單位最常使用的電腦鑑識軟體，同時也是國際大多數國家的法庭上最具公信力之電腦鑑識軟體之一。  
Encase主要的特色可歸納如下：以具有法律效益的鑑識方法取得鑑識資料，並為世界各地之法院採證；在不變動證據的前提下進行物證分析；以鑑識的角度取 得資料，不管是被隱藏、刪除或覆蓋的檔案；檢閱功能可幫助非鑑識操作人員很容易地檢視證物；可快速簡單地產出完整的鑑識報告。  

Forensic Toolkit（FTK）
為利用Windows內建在Win32的命令列的工具來協助檢視NTFS分割硬碟中的每一個檔案。這些檢視動作包括檔案最後一次的存取時間，以及顯示被隱藏的檔案等。
 
FTK鑑識工具最大的特色莫過於其資料庫式的資訊架構，當磁碟的副本被匯入時，其針對資料庫的內容進行排序或以字串比對出磁碟副本內的檔案，而不需要掃描整個磁碟的副本資料。 

FTK可以分析、獲取、組織並保存數位證據，透過索引化的概念將所有文字內容建立索引，強大的過濾及搜索功能為其主要特色。但礙於其價格昂貴，且使用前必須有概括性的了解，一般的機構或公司部門較少使用。其主要的工具包括：  

‧ Forensic Toolkit（FTK）：數位鑑識分析工具
‧ Password Recovery Toolkit（PRTK）：密碼分析、破解與回復工具
‧ Registry Viewer：登錄檔分析及解密工具
‧ FTK Imager：數位證據預覽及獲取映像工具
‧ Wipe Drive：硬碟資訊及資料完全清除工具 

The Coroner’s Toolkit（TCT）
The Coroner’s Toolkit（TCT）是一套由C和Perl語言寫成的鑑識工具集。它可以用來搜尋或分析Unix（Unix-like）系統上的資料，簡單來講，它是一款收集許多工具的組件包，可用於分析Unix環境。  

此組件包中包含Grave-Robber（擷取分析檔案的資料）、Mactime（找尋Mtime/Atime/Ctime工具）、Unrm（找出位置在Unallocated尚未配置空間中的檔案）以及lazarus（分析來源所擷取的資料）。分別說明如下：
 
1. Grave-Robber
Grave-robber是TCT的核心工具，主要用來下達指令以擷取檔案系統中的資料，或是儲存一些需要分析的檔案。在正常的情況下，Grave- Robber會掃描整個系統，並盡可能地擷取所有資料，例如暫時（Temporary）資料（如網路封包狀態）、系統硬體結構（特別是磁碟或磁碟分割）、 檔案系統的重要檔案如Configuration Files、Log Files。  

但是，該工具如果一定要以可取得系統最高權限的身分（root）來執行，它會阻止使用者擷取root權限的檔案，所以為確保所有的證據資料皆能被擷取，最好以root身分執行此工具。  

2. MACtime
這是一個收集Mtime、Atime、Ctime的鑑識工具。Mtime（Modified time）是檔案最後被修改的時間，Atime（Access time）是檔案最後讀取的時間，而Ctime（Changed time）是檔案屬性最後被改變的時間。這些時間很容易被竄改，必須要小心處理，以免造成證據的更動。  

3. Unrm和Lazarus
一般人以為損壞或遺失的檔案無法復原，其實它還在硬碟的某一個地方，只是需要工具把它重新找回來，而這兩個工具，便如同大家常使用的FinalDa-ta 工具般擁有救回原來檔案的能力。Unrm是一個以C語言寫成的工具，它可以找出未配置空間（Unallocated）的資料，挖掘潛在的檔案。例如有 20GB的硬碟空間已經使用12GB，它可以把剩下8GB的未配置資料復原。接著，透過Lazarus從Unrm復原的檔案或所有檔案內找尋需擷取的資 料。Lazarus適用在UFS、EXT2、NTFS、FAT32檔案系統上，其擷取資料之後所呈現的型式會隨著不同檔案系統而有所不同。  

數位鑑識工具與交叉驗證 
鑑識人員可利用現有的鑑識軟體去執行鑑識工作，但是獲得數位證據後並無法馬上成為可用的數位證據，甚至無法稱作具有「證據能力」的數位證據。  

所謂「證據能力」是指可以用來作為證據的資格，法律對一個物件是否可以作為證據通常都會有一定的限制。  

依據刑事訴訟法第154條第2項規定：「犯罪事實應依證據認定之，無證據不得認定犯罪事實。」而其所謂證據則是指刑事訴訟法第155條第2項所規定，具有證據能力且經過合法調查的證據。  

換言之，並非所有的證據都能認定該犯罪事實，要能夠證明犯罪事實的證據，必須先具備有證據能力，如果具有可以作為證據的資格，經過合法的調查程序，使法官 對於該證據的證明力（證據價值有所評斷）信服，最終的心證才具有認定犯罪事實的能力，依據刑事訴訟法第155條第1項規定：「證據之證明力，由法院本於確 信自由判斷，但不得違背經驗法則及論理法則。」  

就像前面所論述的，數位證據的鑑識結果，會因為所使用的工具軟體不同而有差異，僅依賴一種鑑識軟體所做的鑑定結果，有人為操作錯誤及產生誤差的可能，也容易被質疑該鑑識軟體之可靠性，因此該數位證據連證據能力都不足，更遑論以其作為證明犯罪事實的證明能力。  

雖然，對同一份證據副本，使兩種鑑識軟體進行檢驗，會耗費許多的時間與心力。然而，此舉也減低發生人為操作錯誤的機率和風險。  

在鑑識軟體的可靠性及數位證據「證據能力」不足的情況下，透過交叉驗證讓數位證據足以被法院所採信，以完成具證據能力的數位證據是勢在必行。  

至於該證據能證明的程度如何，當然就交由法官的自由心證。因此，將首先取得的數位證據透過整合鑑識，其結果以供日後證據之交叉分析使用，如圖1和圖2所示：  

▲圖1 尚未具「證據能力」的數位證據。

▲圖2 具「證據能力」的數位證據。

統整上述的概念理論，對於證據能力和證明力的區分，可以用圖3的數位證據法效性轉化過程來簡述：  

▲圖3 證據之證據能力和證明力。

▲圖4 交叉驗證。

 
交叉驗證 
本文內所提到的交叉驗證涵義，是指對於數個尚未檢驗的待檢驗檔案，透過選擇的兩個鑑識工具去驗證比對後，將其結果進行比較分析，檢驗是否具有相同的結果？ 是否完全無關？抑或是互相排斥？另一種交叉比對資料方法，可以互補證據的不足，或者加強對數位證據之證據能力，如圖4所示。
 
鑑識工具的交叉驗證 
這裡以EnCase、FTK與TCT這三種整合型電腦鑑識工具做探討，討論其功能特色，並做交叉檢驗比較整理，了解Windows-based的圖形化介 面鑑識工具軟體（EnCase與FTK）與Unix-Based的命令列模式鑑識工具軟體（TCT）之間的操作關係，以確保交叉分析的效益和可行性，而其 比較差異如表1所示。  

表1 鑑識軟體識別檔案類型比較表 
在表1中鑑識軟體交叉驗證所分析的檔案標的，以常見到的檔案為主軸，例如Microsoft Office文件軟體的.doc或.docx、各類繪圖所用的應用軟體、pdf檔案、Web檔案格式（如HTML Files）、映像檔（Image）等，讓鑑識人員對常見的犯罪檔案格式進行檢驗，其數位證據的交叉驗證可以一目瞭然，大幅提升數位證據可信度驗證的效率 問題。  

由表1並可得知，大部分常見的檔案類型用EnCase和FTK鑑識軟體幾乎都可以互相交叉驗證比對證據，但TCT鑑識軟體由於是Unix-Based的命令列模式，所以無法直接檢視其內容檔案，但透過另存方式還原檔案檢視其內容後，也可以和其他數位鑑識工具軟體比對分析。  

歸納總結 
數位證據在面對嫌疑人及其辯護律師的質疑下，究竟是否具有證據能力，常是此證據是否可以採用的關鍵，因此法官常將鑑識結果轉交由原鑑識單位以外的第三方做進一步的檢驗，以確定其結果是否正確無誤，以確保其具有證據能力。 

在這證據檢驗的往返之間，不只浪費許多時間，也突顯了數位鑑識結果未經交叉檢驗的缺點。而且，僅依賴一種鑑識軟體所得到的鑑定結果，有人為操作錯誤及產生誤差的可能，也容易被人質疑該鑑識軟體的可靠性。  

而透過鑑識軟體之比較，可得知EnCase、FTK和TCT這三大鑑識軟體各有其優缺點，例如EnCase可支援各種 同系統及環境所使用的鑑識軟體，但是EnCase在搜尋檔案及回復檔案的效率上不如FTK來得快，而FTK只支援Windows環境下的鑑識工作，在 Linux系統環境中只有EnCase及TCT可以完成工作。  

所以，各種不同的鑑識軟體各有其優缺點，鑑識人員可依不同的環境及犯罪現場來適時使用不同的電腦鑑識工具交叉比對數位證據，經由上述所整理的結果，期許能讓電腦鑑識人員節省使用電腦鑑識工具的時間，得以在第一時間掌握重要數位證據的內容，以為鑑識報告的依據。  
就實驗比較表來觀察，對於交叉檢驗所使用的鑑識軟體，可以提出如下的論點分析：Windows作業系統的鑑識，若是使用FTK鑑識軟體做第一次鑑定，再交 由EnCase鑑識軟體來做第二次檢驗，或是使用EnCase鑑識軟體做第一次鑑定，再交由FTK鑑識軟體做第二次檢驗，兩者所得的結果，可以斷定一樣。 因此，Windows作業系統的鑑定，僅需要EnCase或FTK其中一種軟體即可以得到具有公信力的鑑識結果。  

另外，在Unix作業系統的鑑識方面，基於一般企業內部網路多數使用Linux、Solaris、SunOS與FreeBSD等Unix-like的作業 系統，作為Web Server、File Server、Mail Server與FTP Server的伺服器主機，使用TCT鑑識軟體做第一次鑑定，再輔以EnCase可外掛File Viewer的圖形介面與細部說明，以作為補強式的第二次鑑識，將使鑑識結果更具公信力。 

結語 
本篇在了解鑑識工具關聯後，提供了交叉檢驗數位證據的方法，可兼顧鑑識需求以及證據的證據能力，作為提升數位鑑識的可信度與說服力的準則。另外須注意的是，在鑑識工具的交叉檢驗實驗方面，數位鑑識的檢驗結果，會因為所使用的工具軟體不同而有差異。  

為了要得到具有公信力的檢驗報告，必須了解各項鑑識軟體的功能、特點與極限，也須提升數位證據在法庭上的可用性，進而獲得數位證據的「證據能力」。最後，再由法官心證的證明力去研判對犯罪事實的可用程度。

轉自 http://www.netadmin.com.tw/article_content.aspx?sn=1107140002

SIM Forensics - Part 1

A smart card, also known as an Integrated Circuit Card (ICC), is a micro-controller based access module. It is a physical/logical entity and can be either a Subscriber Identity Module (SIM) or a Universal Integrated Circuit Card (UICC). Originally, the ICC defined for 2G networks was the SIM. In 3G networks, the SIM may also be a logical entity (application) on a 3G UICC thereby making it functionally the same as a 2G SIM. The Universal Subscriber Identity Module (USIM) is a logical application running on a UICC smart card, which normally only accepts 3G Universal Mobile Telecommunications Service (UMTS) commands. A USIM can have multiple phone numbers assigned to it, thus allowing one phone to have multiple numbers. If the USIM and SIM applications reside on the same UICC, they cannot be active at the same time.


SIM Technology and Functionality
SIMs are found in GSM, iDEN, and Blackberry handsets and are also used by satellite phone networks such as Iridium, Thuraya, and Inmarsat. Under the GSM framework, a cell phone is termed a Mobile Station, consisting of a SIM card and a handset (Mobile Equipment–ME). One very important and functional feature of a SIM card is that it can be moved from one GSM compatible phone to another, thereby transferring all of the subscriber’s information.

The first SIM cards were about the size of a credit card. As cell phones began to shrink in size, the mini-SIM (about one-third the size of a credit card) was developed. Today an even smaller version, the micro-SIM, is available. Each of these three iterations varies in physical size and the functionality supported. Normally, a SIM card provides functionality for both the identification and authentication of the subscriber’s phone to its network; contains storage for phone numbers, SMS, and other information; and allows for the creation of applications on the card itself. The basic functions are illustrated in Figure 1.



SIM Structure
SIMs contain both a processor (CPU) and an operating system which is either native (proprietary, vendor specific) or Java Card (a subset of the Java programming language). SIMs also have Electrically Erasable Programmable Read Only Memory (EEPROM), Random Access Memory (RAM) for controlling program execution, and persistent Read Only Memory (ROM) which stores user authentication, data encryption algorithms, the operating system, and other applications. Communication between the SIM card and the handset is via a serial interface.

A SIM card also contains a hierarchical file system which resides in EEPROM. The file structure consists of a Master File (MF), which is the root of the file system, Dedicated Files (DFs), and Elementary Files (EFs). Dedicated Files are subordinate directories under the MF, their contents and functions being defined by the GSM11.11 standards. Three are usually present: DF (DCS1800), DF (GSM), and DF (Telecom). Also present under the MF is EF (ICCID). Subordinate to each of the DFs are supporting EFs which contain the actual data. The EFs under DF (DCS1800) and DF (GSM) contain network related information and the EFs under DF (Telecom) contain the service related information. A typical SIM card file system is shown in Figure 2.

While all the files have headers, only the EFs contain data. The first byte of the header identifies the file type. Headers contain the security and meta-information related to the structure and attributes of the file, such as length of record. The body of the EFs contains information related to the application(s). Files can be either administrative or application specific and access to stored data is controlled by the operating system.



SIM SECURITY
SIM cards have built in security features that are designed to make them tamper resistant, thereby ensuring data security. A SIM card’s MF, DFs, and EFs all contain security attributes. One security attribute, the access conditions, are constraints upon the execution of commands. They filter every execution attempt, thus ensuring that only those with the proper authorization can access the requested functionality controlled by the DFs or EFs. Access conditions can be thought of as somewhat analogous to the user rights associated with the file/directory attributes found in computer operating systems. There are different levels of access conditions associated with DF and EF files:

• Always (ALW): file access is allowed without restrictions and the command is executable upon the file.
• Card Holder Verification 1 (CHV1): file access is allowed with the valid verification of the users PIN1 (or PIN1 verification is disabled) and the command is executable upon the file.
• Card Holder Verification 2 (CHV2): file access is allowed with a valid verification of the user’s PIN2 (or PIN2 verification is disabled) and the command is executable upon the file.
• Administrative (ADM): the administrative authority (i.e. the card issuer who provides the SIM card to subscribers), is responsible for the allocation of these levels.
• Never (NEV): file access is prohibited and the command is never executable upon the file.

Data of Forensic Value
Depending upon the phone’s technology and access scheme, the same data, such as a contact list, may be stored on the SIM, in the handset, or on the phone’s memory card. SIM cards themselves contain a repository of data and information, some of which is listed below:

• Integrated Circuit Card Identifier (ICCID)
• International Mobile Subscriber Identity (IMSI)
• Service Provider Name (SPN)
• Mobile Country Code (MCC)
• Mobile Network Code (MNC)
• Mobile Subscriber Identification Number (MSIN)
• Mobile Station International Subscriber Directory Number (MSISDN)
• Abbreviated Dialing Numbers (ADN)
• Last Dialed Numbers (LDN)
• Short Message Service (SMS)
• Language Preference (LP)
• Card Holder Verification (CHV1) and (CHV2)
• Ciphering Key (Kc)
• Ciphering Key Sequence Number
• Emergency Call Code
• Fixed Dialing Numbers (FDN)
• Local Area Identity (LAI)
• Own Dialing Number
• Temporary Mobile Subscriber Identity (TMSI)
• Routing Area Identifier (RIA) network code
• Service Dialing Numbers (SDNs)

A discussion of some of this data and what it means will continue in the next column.


轉自 http://www.forensicmag.com/article/sim-forensics-part-1?page=0,2

Windows平台下的安全事件處理

引用來源：Windows平台下的安全事件處理

作者：沈志昌／林敬皇 

摘要
當 我們使用的 Windows 系統環境中遭遇安全性事件時，我們如何準備事件回應及保留相關證據。本文將逐一說明在 Windows 系統環境中如何準備事件的處理、證據的蒐集與保留及保護等，並以 Guideline 的方式引導您了解 Windows 平台下的安全事件如何處理。

一、前言隨 著網際網路的逐漸普遍，為人類帶來許多生活上的改變，相對的網路入侵事件日益頻繁，無論您的使用平台為何，都免除不了遭受入侵的威脅，從電腦安全的觀點 來看，完整的建築保護電腦的工事，是第一要務，然而，在資安界流傳「最安全的網路環境，是不接上網路的單機作業」，這說明了，不論怎樣維護安全的網路環 境，還是難免有漏洞，除了完整的防護措施外，如何有效發現及發現入侵後如何應變，也是相當需要重視的一環。因此，本文的重點在於，如何在充滿威脅的環境 下，能夠有效的發現異常情況且能進一步蒐集與提出相關證據，以利於安全人員作有效的處理，甚至涉及相關法律處理程序時，作為協助辦案的佐證。 

當 您發現系統遭受入侵且可能有資料被盜失，大多數人的反應是希望儘快恢復成原先的正常運作狀況，且進一步找出破壞 者，但在處理這些事件時，最常見的處理方法就是直接拔除網路線，接著系統重新安裝系統，這樣的動作似乎可以順利完成問題的排除，然而，在電腦犯罪日漸囂張 的今日，除了恢復系統外，更需將您的重點放置於入侵軌跡及犯罪證據的蒐集。因此，無論是個人、企業組織都應在處理資安問題時，將此列入資安政策（ policy ）內。 

瞭解蒐證的必要性後，如何有效的蒐集及回報資訊，也是的另一重點。不同的入侵行為會產生不同的記錄及影響，資安事件回報機制就是在此背景下產生的，國內常見的資安事件回報機制，政府等公務單位有國家資通安全技術服務中心（簡稱 ICST ）的資訊安全事件回報系統，而民間單位則有台灣電腦網路危機處理暨協調中心（簡稱 TWCERT/CC ）的安全事件回報機制，透過這些回報機制及單位，可以將您所遭受的入侵行為或是攻擊行為透過這些組織來幫您與對方的 ISP 進行反應，若判定為惡意行為，也可依據通報的紀錄，考量將處理的層級提升至相關的法律行動。因此，如何有效的保留資訊及通知問題處理單位，就成了處理資安 問題的首要任務。本文的目的即在提供資安事件蒐證工具建議，並且說明如何有效的使用這些工具來取得 MS-Windows 系統安全事件相關證據，，提供相關安全事件回報機制及單位的處理者最詳細的資訊，以順利解決您的資安事件。 

二、入侵應變
入 侵應變階段是在發現異常情形時，從有限的主機資訊中提存有關資訊安全事件的行動，內容包含可能所發生的損害或是影響程度，這是所有處理資安事件的第一階 段，接著即是應變的實行，依照組織內的資安策略，決定是否繼續監控，或是需要離線修復之工作。在入侵應變階段，通常需要注意 5W1H 原則：

• Who ：誰發現入侵行為？
• How ：如何發現？
• When ：何時發現？
• What ：受損害的程度為何？
• Where ：攻擊從何開始？
• What techniques ：怎樣的技術造成系統的損害？及需要什麼技術來進行處理？

根據以上幾點，您可以依據不同的入侵型態來設計應對策略以及需要的通報資訊，要成功的處理入侵事件並不單只是仰賴快速的回復系統狀態，而是還要兼顧入侵資訊的蒐集和證據的取得。 

當 系統可能發生遭受入侵的情形時，最常被問到的問題通常是， ” 是否要立即將系統離線 ” 、 ” 是不是要將系統關機 ” 、 ” 要不要馬上將系統重安裝 ”，但這些都不是最好的解決方式，而是必須考量您先前所設計的資訊安全策略。舉例來說，若入侵者還潛伏在您的系統中，也許您不應該立即斷線而驚動對方，反之 您可以進行安全通報後，藉由監控程式追蹤出對方的來源。但倘若您的資料屬於重要的機密資料，這時您可能就須以保護資料為優先，立即斷線以防止更嚴重的損害 發生。 

三、取得證據數 位證據是相當容易建立，也是容易修改，通報者必須十分注意取得的證據，重要的是必須注意每一個蒐集的程序及所蒐集到的資訊種類。在資安事件上，入侵行為 未必會立即提昇至需要法律行動，但對於企業組織來說這些相關資訊的取得，都可能在將來資安事件等級提昇時，轉變為有力的證據，因此，對於蒐集的時間點、技 術等，都應該利用可信任及可驗證的方式進行。對於記錄的方式、時間、媒體以及如何整合這些證據的方式，都應要事先建立標準程序，以因應問題發生時之處理， 在記錄這些證據時，您必須注意底下事項，確保蒐集的資訊是有效的。

• 避免寫入原來的媒體
• 避免直接刪除所有執行程序
• 避免干預系統時間
• 避免使用非信任的軟體
• 避免干預系統狀況（包含重開機、更新檔、修正檔、或是重新修改系統組態）

四、保護容易消失的資訊
當 資安處理程序進入鑑識（ forensic ）分析程序時，有可能會採用系統關機或是離線調查的方式。然而電腦系統有許多的資訊是容易消失（或揮發）的（例如：記憶體資料、時間、內容、連線狀況 等），因此，在系統存活時（ live system ）即時保存甚至是保護這些容易消失的資訊，對於數位證據的蒐集上，是相當重要的步驟。底下列舉這些容易消失的儲存設備種類，這些是蒐集及保存系統現況資訊 重要的處理標的：

• Registers, cache 內容
• 記憶體內容
• 網路連線狀態
• 正在執行的程序（ running processes ）
• 正在使用的檔案內容及磁碟裝置
• 可攜式裝置或是備份媒體內容（光碟機、磁帶機、 flash 碟等 … ）

而在動手取得這些易消失證據時，底下幾項是需要注意的事項：

• 系統時間及日期
• 正在執行和運行的程序（ process ）
• 目前的網路連線狀態
• 應用程式所開啟的通訊埠（ sockets ）
• 系統上登入的使用者

取得以上這些容易消失的資訊，對於蒐證來說是相當重要的一環，在某些案例中，入侵者（如： hacker ）常會利用駭客工具來達成目的，此時所使用的工具程式就會常駐在記憶體、網路連線中，完整的取得這些資訊，對於成功的處理資安事件有絕對必要性。

五、建立蒐證工具集(Toolkits)
取 得資安事故證據及確定其正確無誤的是重要的，因此，可信的蒐證程式與工具將是蒐證的第一步驟，建議將這些工具建立在 CD-ROM 中攜帶至受入侵系統或是事件現場將會是個不錯的處理方式，管理者需要經常更新蒐證工具且定期蒐集系統內資訊，才能確保所取得的資訊能最接近於事發時間。

下提供有關於 Window 底下蒐集系統安全資訊的工具，您可以依照您的所需要取得資訊多寡程度，來決定所使用的數量及使用的等級，依此建立您的處理工具集（ Toolkits ），並測試及確認在蒐集資安事件資訊時，這些工具不會改變任何系統的狀態，這對於將來進行鑑識 (forensic) 時，將會有很大影響。

表 1 ： Window-base 蒐集系統安全資訊的工具

工 具	描 述	來 源
ipconfig	用來確認系統上 ip 位址。	可信任的系統
netstat	用來確認系統上 ip 位址。	可信任的系統
nbstat	用以顯示 NetBIOS 至 TCP/IP （ NetBT ）協定狀態，本機端到遠端電腦的 NetBIOS table 狀態。	可信任的系統
date	確認系統日期。	可信任的系統
time	確認系統時間。	可信任的系統
psuptime	用來確認 win NT/2k 系統已開機執行的時間。	www.sysinternals.com
net	用來確認 NetBIOS 連線、使用者帳號、分享資料夾及啟動服務等功能。	可信任的系統
psloggedon	用來顯示本地端使用者帳號連結至遠端的情形。	www.sysinternals.com
pulist	命令模式工具，用來顯示本機上所有執行中的程序，並且可以擷取使用者正在執行的程序。	www.sysinternals.com
pslist	命令模式，顯示所有執行程序使用 CPU 的資訊，包含時間、負載百分比、核心或是使用者模式及記憶體使用量，可選擇即時監控或是直接擷取方式。	www.sysinternals.com
listdlls	列出本機上所有使用的 DLLs ，包含版本、放置位置。	www.sysinternals.com
fport	用來顯示系統上目前執行程序，及該程序所使用之 PID 、 PORT 狀態。	www.sysinternals.com
psservice	用來顯示系統狀態、組態、服務的 service 並可以進行管理系統服務。	www.sysinternals.com
ps-info	顯示 windows NT/2K 上 OS 及所有人的狀態、及主機上的所有資訊。	www.sysinternals.com
arp	系統上將 IP 位址與 MAC 位址做對應之工具。	可信任的系統
ntlast	監控登入的狀況（失敗或成功）。	www.sysinternals.com
reg	系統上用來編輯、管理 registry 工具。	NT resource Kit
auditpol	用來決定系統所使用的 audit policy 。	NT resource Kit
regdmp	將系統 registry 轉換成文字檔輸出。	NT resource Kit
md5sum	用來產生檔案的 hash 值，確保輸出的檔案不被修改。	unxutils.sourceforge.net
netcat(cryptcat)	用來將資訊寫入或讀取網路連結當中， Cryptcat 與 netcat 相同，不過還可以建立加密的通訊管道。	www.atstake.com
filemon	監控系統上檔案系統活動情形，並且可觀察應用程式所使用的 DLLs 狀態。	www.sysinternals.com
windump	用來擷取分析系統 TCP 連線內容工具。	www.dump.polito.it
process explorer	Windows 下套裝軟體，可以用來監控系統程序狀況及使用 DLLs 的情形。（包含位置、版本資訊等）。	www.sysinternals.com
cmd.exe	用來啟動命令列工具。	可信任的系統

       
六、取得Windows平台證據

6.1 Step by Step當然，我們並不能確保每個管理者都能夠在第一時間就發覺入侵行為，通常發現問題時，系統可能已經重新啟動，喪失之前的原始狀況，即使發生上述情形，對於蒐證來說，儘早進行蒐證的程序，仍是正面積極的行動，底下將一步一步告訴您該如何進行資訊的蒐集工作。

6.1.1 ：開啟信任的工具列工具 ( 從您的 Toolkits)將您所建立好的蒐證工具集放置於受入侵之機器的 CD-ROM ，並且啟動您系統上的開始選單，在執行的選項上執行 "cmd.exe" 啟動命令列視窗。

6.1.2 ：準備好蒐證系統記 得先前您已經將您的蒐證工具集放置於受害機器上，接下來步驟就是開始要利用這張光 碟來進行資訊的蒐集，並且把蒐集的證據存放到儲存媒體。在此之前，您可以利用網路方式來進行證據的存放，因此，您需要在遠端啟動蒐證系統，以 netcat 為例（您也可使用加密的方式，如 cryptcat ，可以避免遭受竊聽），首先您必須在您的蒐證機器上，啟動 netcat 並給於此服務一個聆聽埠（ listen port ），準備接收來自受害主機的資訊。

蒐證機器上執行： nc –l –p 12345 >> d:\collect.txt

在此， -l 為開啟 listen port ， -p 則是指定您的 listen port ，最後轉向到您所欲儲存的位置上，在設置好蒐證系統的準備工作後，接著就是回到受害主機上進行蒐證的工作。在受害主機上，您必須建立與蒐證系統的連線工作。 

受害主機上： nc < 蒐證系統 ip 位址 > -e

舉例來說，若您欲將受害主機目錄下檔案結構傳遞至蒐證主機，您可以在命令欄位上使用 dir 這個指令，

如下：

nc 192.168.1.9 12345 -e dir 或是 dir | nc 192.168.1.9 12345

6.1.3 ：蒐集易消失證據在蒐證的第一要務為蒐集系統上容易消失的重要資訊，包含了：

• 系統中基本資訊
• 執行中的程序
• 開啟的通訊埠
• 網路連線狀態
• 網路分享狀況
• 網路使用者

底下是此一階段需要執行的指令，而系統時間及日期是在執行所有程序的前需要先蒐集的資訊（請記住，以下步驟皆是在受害主機端進行）

指 令	說 明
date /ttime/t	蒐集主機上之系統時間，在執行此一動作同時，需先檢查系統時間與實際時間是否有所差別，若有，也請詳細記錄差異的數值，這對將來比對網路設備端之記錄是相當重要的。
ipconfig /all	記錄目前主機所使用的網路連線基本資訊。
psinfo	記錄系統資訊，包含修正檔的版本、修正的次數。
psuptime	紀錄系統啟動的時間。
psloggedon	記錄遠端與本機端使用者的連線狀態。
ntlast –r -f	記錄系統中使用者登入的狀況。（包含成功與失敗）
net < 參數 >	檢 測系統中網路選項資訊，參數種類包含 ，請將這些資訊都個別記錄下來。
nbtstat –n nbtstat –c nbtstat -s	存取遠端 NetBIOS 名稱、目前 NetBIOS 的連線狀態、及最後連線狀態。 取得本機端與遠端的 NetBIOS table 狀態。分辨登入的使用者。
pclip	取得 clipborad 的資訊。
pslist pulist psservice	取得系統執行程序的資訊。 列出正在執行的程序； 列出正在活動（ active ）的程序。列出目前服務的狀態。
listdlls	記錄目前所使用的 DLLs ，包含放置位置、版本及數量。在此也可以發現是否有木馬程式或其他惡意程式存在。
fport	記錄目前所使用的程序、 PID 、及所使用的通訊 port 。參考： http://isc.sans.org/port_detial.html
netstat -an	記錄目前 listening 的服務（ service ）、目前系統開啟的 port 。
netstat –rn	記錄 routing table 。
arp -a	IP address 與 MAC address 表。
dir /t:a /a /s /o:d c:	取得最後存取時間。
dir /t:w /a /s /o:d c:	取得修改時間。
dir /t:c /a /s /o:d c:	取得最後建立時間。（若有多部磁碟機，請自行改變磁碟機代號）利用 dir 可以建立在蒐證時，磁碟機內檔案、時間資訊、連結等資訊。
hfind c:	紀錄磁碟機內所有屬性為隱藏（ hidden ）的檔案。用來區分隱藏與一般屬性的檔案。
md5sum	給予檔案 hash 值，用來確保蒐集的檔案不被竄改。

註：上述指令詳細功能，請自行參考指令說明檔。 ( 程式範例請參照附錄 )

上述所有蒐集動作，看似繁雜且枯燥，但當所有資訊都蒐集齊全時，將會成為系統的縮影，資安處理單位可以根據上述資訊進一步還原系統原貌，連線、檔案結構。

6.1.4 ：蒐集系統 logs完 成受測系統環境資訊蒐集後，接著就要針對此部機器的歷史資訊進行蒐集，所謂歷史資 訊指的是本機的記錄檔 (logs) ，藉由取得 log 檔，在電腦鑑識 (computer forensic) 階段時，將可以根據歷史資訊來分析該機器特定時間點發生何事，提供了怎樣的服務，可以更接近於當時系統狀態，若蒐集環境資訊是屬於靜態分析， log 分析則是屬於動態的部份。當然，前提是您在安裝設定您系統時，您已經知道啟動歷史紀錄檔的必要性，在此階段所蒐集的 log 有：

• Registry
• Events logs
• Relevant application logs

指 令	說 明
auditpol	用來設定系統所使用的策略。
reg query	取得 registry 下 ”Run”, 下列是需要檢查的 registry, 目的用來確認是否有木馬程式常駐在系統中。
HKLM\Software\Microsoft\Windows\Current Version\Run /s	檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。
HKLM\Software\Microsoft\Windows\Current Version\RunOnce /s	檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。
HKLM\Software\Microsoft\Windows\Current Version\RunServices /sc	檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。
HKLM\Software\Microsoft\Windows\Current Version\RunServicesOnce /s	檢視 Most Recently Used(MRU, 最近使用過 ) 檔案。用來辨別是否曾經有使用過特殊的檔案。
HKCU\Software\Microsoft\Windows\Current Version\Explorer\	追蹤曾經安裝過的程式檔案。用來判別過去使用過程式及是否有遭受木馬程式攻擊。
Streams –s c:	檢查磁碟機中 NTFS 檔案結構

 註：有多部磁碟機時，請自行改變磁碟機代號
接著繼續蒐集事件（ Event ） Logs 及其他應用程式記錄檔。 

Logs	存放位置
Event logs APP	c:\WINNT\system32\config\AppEvent.Evt
Event logs SEC	c:\WINNT\system32\config\SecEvent.Evt
Event logs SYS	c:\WINNT\system32\config\SysEvent.Evt
IIS Web Log ( 若有安裝 )	c:\WINNT\system32\logfiles\W3SVC1\
Mail logs( 若有安裝 )	c:\WINNT\system32\logfiles\SMTPSVC1\
DNS logs( 若有安裝 )	c:\WINNT\system32\config\DNSEvent.Evt

註：若您使用其餘服務，請自行尋找該服務程式之記錄檔

在您尋找到該 log 檔後，請利用 md5sum 將其加上 hash 碼，以確保資訊在傳輸時不會遭受竄改，並將這些記錄檔存放置蒐證主機上。 

6.1.5 ：網路連線封包內容蒐集本 階段為蒐集網路連線目前的動作，若情況允許的話，您可以利用網路工具進行監控主機 的動作，利用 sniffer （監聽）工具可以監控網路及封包狀況，藉此瞭解傳輸內容，以及預防入侵者再次返回系統進行破壞（當然，設下陷阱也是可以採行的方案，一切原則以組織中的安 全策略為依歸）。 

工具	目的
WinDump/Snort/ 其他監控軟體	網路狀況監控，分析目前網路流量、內容，進一步更可監控入侵者是否返回。

6.2 蒐證步驟自動化上 述所使用之指令，您可以利用批次檔方式撰寫，可以增加蒐證的效率與速度，您也可以 根據不同的蒐證環境建立您不同的蒐證批次檔，如下 Windows Forensic Script ，之後就可以利用這個批次檔還進行自動化地蒐證，並利用『 > 』重導的方式寫入檔案或送至遠端的鑑識主機即可。

如： wfs.bat > 2004-08-11-ip-forensic.txt

6.3 Identification of footprints （辨識足跡）綜合上述，您目前已經蒐集了：

• 系統基本資訊
• 執行中程序（ processes ）
• 開啟的通訊埠
• 網路連線狀態
• 網路分享狀況
• 使用者狀況
• 相關的系統記錄檔（ logs ）

接下來的步驟就是要尋跡，藉由比對及檢查我們所蒐集的資訊，去發現異常之處，底下則檢查的重點：

• 檢查異常的程序與開啟的 port （如平常不常見的通訊埠，或是常駐程式）
• 檢查異常的應用程式要求（包含連線、分享資源等）
• 驗證正在執行的工作（ jobs ），可與正常無誤的系統做比對
• 分析信任關係（比方來自於沒見過的 user 或是遠端）
• 檢測可疑的使用者帳號
• 決定系統內修正檔階層（注意修正的紀錄檔）

透 過檢測以上各點，您將會發現不少可疑之處，將其記錄下來，並且與 event logs 及時間記錄（之前所做的檔案時間記錄）相互比對，尋找該時間點有所關連的檔案、連線、使用狀態、與系統的關係。利用時間點切割方式，可以有助於分析事件發 生的起源及影響的範圍，進一步的，可以再利用外部諸如防火牆、網路設備的系統記錄進行分析，經由比對可以尋找出更多關於事件的證據。 

特 別需要補充說明的是，當您分析 IIS 下的紀錄時，請記住 IIS 是使用 UTC 時間，原因在於其設計用來提供在全球 www 服務 ( 即使用 multiple time zone) ，因此，分析時您必須根據時差進行系統時間的比對，當您分析此類 log 時，這是需要注意的事項。最後，您可以藉由檢測系統 Registry 來發現：

• 軟體安裝的歷程（包含以前）及目前安裝的軟體
• 判斷系統之安全狀態
• 判斷常駐、開機時啟動的程式即可能會出現的木馬程式
• 判斷曾經使用過的（ Most Recently Used, MRU ）檔案資訊

七、後續處理
藉由入侵蒐證程序，將可以發現系統中異常之處，判斷出問題的發生點以及影響範圍，當完成這些程序後，接下來您必須思考：

• 是否需要將整個系統經由備份工具進行整體的調查（或直接將硬碟當作證據）。
• 是否提升處理等級並採取法律行動。
• 或是恢復系統至正常狀態（ reinstall,patch 或是提升系統安全防護程度）。

當 您完成可疑事件判斷後，將會發現入侵者資訊將不是那麼容易能追溯，此時您可以透過 ISP 進行反應，或是至您所處地的網路危機處理中心進行申訴，以台灣來說，台灣網路危機處理暨協調中心 (TWCERT/CC) ，負責國內及國外入侵事件的回報處理，您可以至該中心入侵回報系統中進行通報，該中心技術人員將會義務為您處理（ https://www.cert.org.tw/service/ir_form.php ），若能附上您所蒐集到的資訊及處理的過程，想必一定能順利解決資安問題，並且經由對方 ISP 防堵該入侵者再度侵害您的系統。

八、結論
所 謂防範未然，入侵應變處理計畫及程序的建立，對於個人或是組織資訊安全是不可或缺的部份，沒有人能保證自己的系統絕對安全，也因此，在不安全的環境下， 防護體系的存在是為了將危險性降至最低，而事發處理計畫，則是為了將傷害降低之最低，其重要性與防衛體系是同等的。建立一套標準程序及完整蒐集工具，能有 助於第一時間保存容易損害的電腦資訊，確保所蒐證之資訊可以最接近於事發當時情況，也有助於恢復至原始環境。 

所建立的處理程序，亦可 設計為定期檢測計畫，系統安全檢測與備份系統也是同等重要，若能於日常工 作同時，落實回應計畫的實施，想必對於解決資安事件，將不會再是難事，也可以降低因為關鍵性資訊的流失，造成日後證據上不足，影響處理甚至進一步判案上的 困擾，因此，在閱讀本文後，您應開始思考您的資訊安全策略是否有缺失，並立即建立您的入侵應變計畫，別讓惡意的入侵者造成你的損害。