Broken Chain
Monday, September 13, 2010
The examination of the Infected 2 system didn't complete one of the initial examination steps which was examining the executables of interest. I wanted to explain how I didn't completely answer the question of how the system became infected because this step wasn't completed.
The picture below shows the evidence located from the examination and I concluded the malware identified in memory was the related to the website hosting a malicious PDF, which answered to a certain extent both of my questions 1) is the system infected and 2) how did the system become infected.
I have incorporated Dr. Peter Stephenson's End to End Digital Investigation (EEDI) framework into my investigation process. I will be explaining how I have been using EEDI in my next few posts but for this post I wanted to discuss one of the activities, which is the chain of evidence construction. The evidence located throughout the examination is correlated into a chain of evidence. "The term chain of evidence refers to the chain of events related in some consistent way that describes the incident" (Stephenson, 2009). The description of the incident could explain what happened including how the incident occurred. Each piece of evidence (event) in the chain should link to the next piece of evidence, and when the link does not exist then it should be able to be explained.
The importance of creating the chain of evidence is that the chain can be used to test your theories and/or conclusions. A theory can be tested against the evidence in the chain to see if the theory is based on fact instead of an assumption. Also, this testing can help highlight links between evidence that may require additional collaboration in order to support how the evidence ties together.
To explain how the chain of evidence can be used to test a theory I will use a scenario that every parent will encounter at some point. You walk into a room where your child is and see a disaster. One of the first questions you ask is what happened. The answer you may encounter is probably similar to some of the answers my teenager and toddler say to me when I ask them a question about some disaster. The answer will have some truth to it but will not completely answer the question because it doesn't explain how all of the evidence in the room fits together. Let’s say a window is broken and in the corner of the room is a baseball. Naturally, you ask what happened and the answer given is the window just broke. This starts the “question and answer process” of pointing out how all of the evidence in the room does not link together. The purpose of the questions is to get additional information that helps support your theory of what happened. You may point out the baseball in the corner of the room, the baseball bat in your front yard, or how all of the kids who were playing outside suddenly disappeared. Your goal is to get the answer which explains how all of the evidence links into a chain thereby describing how the disaster occurred.
Now back to why the question (how the Infected 2 system became infected) was not completely answered. Last spring, I based my conclusion that the system became infected as a result of the administrator account visiting a malicious website on the various pieces of evidence. This evidence included: the malware existing in the administrator account's temporary folder, the activity on the system only involved Internet usage, the malicious PDF was downloaded from a website, malware appeared on the system within one second of the malicious PDF appearing on the system, and the malicious PDF targeted a vulnerability that was present on the system.
However, reviewing the evidence in the picture shows there are a few unanswered questions about how the system became infected because not all of the evidence is linked together (or I haven't explained how I think the evidence links together). For example, the examination did not explain where all of the malware came from. The payload of the malicious PDF made calls to additional URLs and does not directly show a call to download any malware.
When my conclusion is tested against the evidence in the picture this test highlights the evidence which is not linked to the next piece of evidence. Take for example the first piece of malware on the system which was ~TM4.tmp. The evidence does not show directly where this malware came from so I cannot be certain this malware was the payload of the malicious PDF or came from the hxxp://googlecounter.cn website. The link between ~TM4.tmp, googlecounter.cn, and the malicious PDF needs additional collaboration. The examination step of examining executables of interest could help explain how the malware fits into the chain of evidence.
The brief examination I am going to describe is for illustration purposes only and by no means am I suggesting this is how executables should be analyzed. I didn't complete this activity last spring but I wanted to show how this step could provide additional information to help answer your questions.
The ~TM4.tmp's Virus Total report was reviewed in order to locate a detection that could be used for further analysis. I decied to use Microsoft's detection of TrojanDownloader:Win32/Bredolab.X. Microsoft’s Malware Protection Center states this malware connects to a remote server to download and execute additional files.
The installation information section on the webpage states the malware “is installed to the Startup folder using a variable file name. It injects itself in the 'svchost.exe' and 'explorer.exe' processes”. The examination of the Infected 2 system located a copy of the ~TM4.tmp file (mgjwin32.exe) in the Startup folder while the examination of the strings shows the explorer.exe and svchost.exe processes made references to the mgjwin32.exe program located in the Startup folder (this isn't reflected in my earlier post). This is useful information that could help explain how the other pieces of malware ended up on the system. However, this information doesn't explain how ~TM4.tmp ended up on the system, which is the link we are trying to establish.
Continuing with the examination of the ~TM4.tmp file, a Google search of the file's MD5 hash was performed. The search result only had one hit and this was an entry in the Malc0de database which is shown below.
* date of entry was 2010-04-08
* domain was googlecounter.cn/web/load.php
* IP address was 109.196.143.33
* Autonomous System Name was VLTELECOM-AS VLineTelecom LLC
Moscow, Russia
* file's MD5 hash is e40b4170d3f9252a4339bb2c2d0db7f2
The Malc0de database entry was on 04-08-2010 which was one day after the system was infected and the domain involved was the same one the Administrator user account visited (hxxp://googlecounter.cn). I think the most significant piece of information is that the domain listed (googlecounter.cn/web/load.php) is the same domain in the URL requests in the malicious PDF. This additional collaborating evidence establishes the link between the first piece of malware on the system, malicious PDF, and the suspected website; thereby completing this portion of the chain of evidence. The examination of the executables of interest would continue with the remaining malware in order to complete the chain of evidence.
Infected 2 System Examination Conclusion
The examination of the Infected 2 system did not completely link all of the evidence together. (Eventually, I want to be able to completely link all of the evidence together) Despite this, the examination was able to answer both of my initial questions to a certain extent. These questions were is the system infected and how did the system become infected. Memory analysis was able to locate suspicious files while uploading those files to Virus Total confirmed them as being malicious. The remaining examination steps combined with timeline analysis was able to determine the system was infected by visiting a website hosting a malicious PDF.
The examination was performed on a test system so I didn't have to determine what made the administrator user account access the malicious website. Something would have to deliver the website's URL to the administrator and this delivery mechanism could have been a link in an email, link in instant messaging, or a browser redirect from a compromised website. I think this would have been my next step in answering the question how did the system become infected. This line of thinking is what spawned my next area to explore which will be trying to gain a better understanding of the common attack vectors.
References
Stephenson, P. (2009). Cyber Investigation. In S. Bosworth, M. Kabay, & E. Whyne, Computer Security Handbook (pp. 55.1 - 55.27). Hoboken: John Wiley & Sons, Inc.
The picture below shows the evidence located from the examination and I concluded the malware identified in memory was the related to the website hosting a malicious PDF, which answered to a certain extent both of my questions 1) is the system infected and 2) how did the system become infected.
I have incorporated Dr. Peter Stephenson's End to End Digital Investigation (EEDI) framework into my investigation process. I will be explaining how I have been using EEDI in my next few posts but for this post I wanted to discuss one of the activities, which is the chain of evidence construction. The evidence located throughout the examination is correlated into a chain of evidence. "The term chain of evidence refers to the chain of events related in some consistent way that describes the incident" (Stephenson, 2009). The description of the incident could explain what happened including how the incident occurred. Each piece of evidence (event) in the chain should link to the next piece of evidence, and when the link does not exist then it should be able to be explained.
The importance of creating the chain of evidence is that the chain can be used to test your theories and/or conclusions. A theory can be tested against the evidence in the chain to see if the theory is based on fact instead of an assumption. Also, this testing can help highlight links between evidence that may require additional collaboration in order to support how the evidence ties together.
To explain how the chain of evidence can be used to test a theory I will use a scenario that every parent will encounter at some point. You walk into a room where your child is and see a disaster. One of the first questions you ask is what happened. The answer you may encounter is probably similar to some of the answers my teenager and toddler say to me when I ask them a question about some disaster. The answer will have some truth to it but will not completely answer the question because it doesn't explain how all of the evidence in the room fits together. Let’s say a window is broken and in the corner of the room is a baseball. Naturally, you ask what happened and the answer given is the window just broke. This starts the “question and answer process” of pointing out how all of the evidence in the room does not link together. The purpose of the questions is to get additional information that helps support your theory of what happened. You may point out the baseball in the corner of the room, the baseball bat in your front yard, or how all of the kids who were playing outside suddenly disappeared. Your goal is to get the answer which explains how all of the evidence links into a chain thereby describing how the disaster occurred.
Now back to why the question (how the Infected 2 system became infected) was not completely answered. Last spring, I based my conclusion that the system became infected as a result of the administrator account visiting a malicious website on the various pieces of evidence. This evidence included: the malware existing in the administrator account's temporary folder, the activity on the system only involved Internet usage, the malicious PDF was downloaded from a website, malware appeared on the system within one second of the malicious PDF appearing on the system, and the malicious PDF targeted a vulnerability that was present on the system.
However, reviewing the evidence in the picture shows there are a few unanswered questions about how the system became infected because not all of the evidence is linked together (or I haven't explained how I think the evidence links together). For example, the examination did not explain where all of the malware came from. The payload of the malicious PDF made calls to additional URLs and does not directly show a call to download any malware.
When my conclusion is tested against the evidence in the picture this test highlights the evidence which is not linked to the next piece of evidence. Take for example the first piece of malware on the system which was ~TM4.tmp. The evidence does not show directly where this malware came from so I cannot be certain this malware was the payload of the malicious PDF or came from the hxxp://googlecounter.cn website. The link between ~TM4.tmp, googlecounter.cn, and the malicious PDF needs additional collaboration. The examination step of examining executables of interest could help explain how the malware fits into the chain of evidence.
The brief examination I am going to describe is for illustration purposes only and by no means am I suggesting this is how executables should be analyzed. I didn't complete this activity last spring but I wanted to show how this step could provide additional information to help answer your questions.
The ~TM4.tmp's Virus Total report was reviewed in order to locate a detection that could be used for further analysis. I decied to use Microsoft's detection of TrojanDownloader:Win32/Bredolab.X. Microsoft’s Malware Protection Center states this malware connects to a remote server to download and execute additional files.
The installation information section on the webpage states the malware “is installed to the Startup folder using a variable file name. It injects itself in the 'svchost.exe' and 'explorer.exe' processes”. The examination of the Infected 2 system located a copy of the ~TM4.tmp file (mgjwin32.exe) in the Startup folder while the examination of the strings shows the explorer.exe and svchost.exe processes made references to the mgjwin32.exe program located in the Startup folder (this isn't reflected in my earlier post). This is useful information that could help explain how the other pieces of malware ended up on the system. However, this information doesn't explain how ~TM4.tmp ended up on the system, which is the link we are trying to establish.
Continuing with the examination of the ~TM4.tmp file, a Google search of the file's MD5 hash was performed. The search result only had one hit and this was an entry in the Malc0de database which is shown below.
* date of entry was 2010-04-08
* domain was googlecounter.cn/web/load.php
* IP address was 109.196.143.33
* Autonomous System Name was VLTELECOM-AS VLineTelecom LLC
Moscow, Russia
* file's MD5 hash is e40b4170d3f9252a4339bb2c2d0db7f2
The Malc0de database entry was on 04-08-2010 which was one day after the system was infected and the domain involved was the same one the Administrator user account visited (hxxp://googlecounter.cn). I think the most significant piece of information is that the domain listed (googlecounter.cn/web/load.php) is the same domain in the URL requests in the malicious PDF. This additional collaborating evidence establishes the link between the first piece of malware on the system, malicious PDF, and the suspected website; thereby completing this portion of the chain of evidence. The examination of the executables of interest would continue with the remaining malware in order to complete the chain of evidence.
Infected 2 System Examination Conclusion
The examination of the Infected 2 system did not completely link all of the evidence together. (Eventually, I want to be able to completely link all of the evidence together) Despite this, the examination was able to answer both of my initial questions to a certain extent. These questions were is the system infected and how did the system become infected. Memory analysis was able to locate suspicious files while uploading those files to Virus Total confirmed them as being malicious. The remaining examination steps combined with timeline analysis was able to determine the system was infected by visiting a website hosting a malicious PDF.
The examination was performed on a test system so I didn't have to determine what made the administrator user account access the malicious website. Something would have to deliver the website's URL to the administrator and this delivery mechanism could have been a link in an email, link in instant messaging, or a browser redirect from a compromised website. I think this would have been my next step in answering the question how did the system become infected. This line of thinking is what spawned my next area to explore which will be trying to gain a better understanding of the common attack vectors.
References
Stephenson, P. (2009). Cyber Investigation. In S. Bosworth, M. Kabay, & E. Whyne, Computer Security Handbook (pp. 55.1 - 55.27). Hoboken: John Wiley & Sons, Inc.
Labels:
chain of evidence,
EEDI,
malware,
malware analysis
Posts
