An Ontology for Digital Forensics in IT Security Incidents - OPUS
An Ontology for Digital Forensics in IT Security Incidents - OPUS An Ontology for Digital Forensics in IT Security Incidents - OPUS
66 CHAPTER 8. EVALUATION 6. The last step, was to query the database for evidence. This step is described in sections 8.3, 8.4, 8.5 and 8.6. For these sections it is assumed that it is not known what kind of malware was run. The approach is to run selected queries to get an overview and then examine more in detail. 8.2 SPARQL Queries This section shows the queries that are used to nd traces of malware. Some of them are already explained in detail in chapter 7. 8.2.1 Find le A query to nd les as shown in listing 7.4 is explained in section 7.6.1. FILENAME has to be replaced by the string to search for. The result contains all les that have the given string in their path. 8.2.2 Autorun The query shown in listing 7.6 is explained in section 7.6.2. It lists all key-value pairs of the values of the Windows/CurrentVersion/Run registry subtrees. These subtrees contain the programs that are started with the operating system. 8.2.3 Network Another sign for malware may be the network connections. The query from listing 8.1 can be used to nd all processes that have TCP connections. This returns the processes and what they are connected to. Replace the two tools in the hasForensicTool lines by their socket equivalent (see 4.3.2) to search for all network protocols. 8.2.4 Parent Process The query explained in section 7.6.3 and shown in listing 7.7 lists all processes that do not have a normal line of ancestors. 8.2.5 Resources A useful piece of evidence is which resources a process uses. To obtain this information the query from listing 8.2 can be used. The query binds the process to the variable ?pid and lters the name matching the regular expression PROCESSNAME. If the resource is a le, the OPTIONAL block binds the name of the le to the variable ?filename.
8.3. CASE 1 67 SELECT DISTINCT ? pid ? name ? conn ? local ? remote WHERE { {? pid for : hasForensicTool base : volatility_connscan . } UNION {? pid for : hasForensicTool base : volatility_connections . } ? pid rdf : type pro : Process . ? pid pro : Name [ rdf : value ? name ] . ? pid pro : hasConnection ? conn . ? conn pro : Local_Address [ rdf : value ? local ] . ? conn pro : Remote_Address [ rdf : value ? remote ] . } Listing 8.1: Processes with connections SELECT DISTINCT ? pid ? name ? resource ? filename WHERE { ? pid rdf : type pro : Process . ? pid pro : Name [ rdf : value ? name ] . FILTER ( regex ( str (? name ), " PROCESSNAME ", "i ")) ? pid pro : hasResource ? resource . OPTIONAL { ? resource fsfn : name ? filename . } } Listing 8.2: Resources of a process 8.3 Case 1 The Autorun query from section 8.2.2 returns key: "mydnswatch.exe" value:"C:\mydnswatch\mydnswatch.exe" besides the normal values. A lookup on the internet for mydnswatch.exe proves that malware was running on the computer. The rst query from section 8.2.3 shows that the processes explorer.exe and winlogon.exe have connections. Both of them should not have any connection. All addresses the both processes are connected to do not look familiar and a search on the internet shows that they belong to malware related servers. 8.4 Case 2 The Autorun query from section 8.2.2 returns key: "CTEMON.EXE" value: ""C:\Dokumente und Einstellungen\All Users\Application Data\winlogon .exe" /h" besides the normal values. The rst thing that confuses is that
- Page 18 and 19: 16 CHAPTER 4. FORENSICS Basic rules
- Page 20 and 21: 18 CHAPTER 4. FORENSICS 4.1.2.2 Ran
- Page 22 and 23: 20 CHAPTER 4. FORENSICS entry conta
- Page 24 and 25: 22 CHAPTER 4. FORENSICS 4.2.3.1 Reg
- Page 26 and 27: 24 CHAPTER 4. FORENSICS vulnerable
- Page 28 and 29: 26 CHAPTER 4. FORENSICS The fls -m
- Page 30 and 31: 28 CHAPTER 4. FORENSICS of the sock
- Page 32 and 33: 30 CHAPTER 4. FORENSICS
- Page 34 and 35: 32 CHAPTER 5. ONTOLOGY Person name
- Page 36 and 37: 34 CHAPTER 5. ONTOLOGY 5.1.1 Creati
- Page 38 and 39: 36 CHAPTER 5. ONTOLOGY Resource Des
- Page 40 and 41: 38 CHAPTER 5. ONTOLOGY to be Augsbu
- Page 42 and 43: 40 CHAPTER 5. ONTOLOGY Gephi and Cy
- Page 44 and 45: 42 CHAPTER 5. ONTOLOGY
- Page 46 and 47: 44 CHAPTER 6. FORENSIC ONTOLOGY for
- Page 48 and 49: 46 CHAPTER 6. FORENSIC ONTOLOGY pro
- Page 50 and 51: 48 CHAPTER 6. FORENSIC ONTOLOGY reg
- Page 52 and 53: 50 CHAPTER 6. FORENSIC ONTOLOGY 6.9
- Page 54 and 55: 52 CHAPTER 6. FORENSIC ONTOLOGY Par
- Page 56 and 57: 54 CHAPTER 6. FORENSIC ONTOLOGY
- Page 58 and 59: 56 CHAPTER 7. IMPLEMENTATION 7.3 RD
- Page 60 and 61: 58 CHAPTER 7. IMPLEMENTATION the co
- Page 62 and 63: 60 CHAPTER 7. IMPLEMENTATION 1 SELE
- Page 64 and 65: 62 CHAPTER 7. IMPLEMENTATION Anothe
- Page 66 and 67: 64 CHAPTER 7. IMPLEMENTATION 7.8 St
- Page 70 and 71: 68 CHAPTER 8. EVALUATION key (CTEMO
- Page 72 and 73: 70 CHAPTER 9. SUMMARY after some is
- Page 74 and 75: 72 APPENDIX A. EXTRACTION TOOL LIST
- Page 76 and 77: 74 APPENDIX A. EXTRACTION TOOL LIST
- Page 78 and 79: 76 APPENDIX B. FORENSIC TOOLS OUTPU
- Page 80 and 81: 78 APPENDIX C. SCREENSHOTS Figure C
- Page 82 and 83: 80 APPENDIX C. SCREENSHOTS Figure C
- Page 84 and 85: 82 APPENDIX C. SCREENSHOTS Figure C
- Page 86 and 87: 84 APPENDIX C. SCREENSHOTS
- Page 88 and 89: 86 BIBLIOGRAPHY [Carrier, 2012c] Ca
- Page 90 and 91: 88 BIBLIOGRAPHY [Microsoft, 2010] M
- Page 92: 90 BIBLIOGRAPHY [W3C, 2004] W3C (20
8.3. CASE 1 67<br />
SELECT DISTINCT ? pid ? name ? conn ? local ? remote<br />
WHERE {<br />
{? pid <strong>for</strong> : hasForensicTool base : volatility_connscan . }<br />
UNION<br />
{? pid <strong>for</strong> : hasForensicTool base : volatility_connections . }<br />
? pid rdf : type pro : Process .<br />
? pid pro : Name [ rdf : value ? name ] .<br />
? pid pro : hasConnection ? conn .<br />
? conn pro : Local_Address [ rdf : value ? local ] .<br />
? conn pro : Remote_Address [ rdf : value ? remote ] .<br />
}<br />
List<strong>in</strong>g 8.1: Processes with connections<br />
SELECT DISTINCT ? pid ? name ? resource ? filename<br />
WHERE<br />
{<br />
? pid rdf : type pro : Process .<br />
? pid pro : Name [ rdf : value ? name ] .<br />
FILTER ( regex ( str (? name ), " PROCESSNAME ", "i "))<br />
? pid pro : hasResource ? resource .<br />
OPTIONAL { ? resource fsfn : name ? filename . }<br />
}<br />
List<strong>in</strong>g 8.2: Resources of a process<br />
8.3 Case 1<br />
The Autorun query from section 8.2.2 returns key: "mydnswatch.exe"<br />
value:"C:\mydnswatch\mydnswatch.exe" besides the normal values. A<br />
lookup on the <strong>in</strong>ternet <strong>for</strong> mydnswatch.exe proves that malware was runn<strong>in</strong>g<br />
on the computer. The rst query from section 8.2.3 shows that the processes<br />
explorer.exe and w<strong>in</strong>logon.exe have connections. Both of them should<br />
not have any connection. All addresses the both processes are connected to<br />
do not look familiar and a search on the <strong>in</strong>ternet shows that they belong to<br />
malware related servers.<br />
8.4 Case 2<br />
The Autorun query from section 8.2.2 returns key: "CTEMON.EXE" value:<br />
""C:\Dokumente und E<strong>in</strong>stellungen\All Users\Application Data\w<strong>in</strong>logon<br />
.exe" /h" besides the normal values. The rst th<strong>in</strong>g that confuses is that