Sizing up CVE-2010-1885 Exploit Artifacts
Monday, December 13, 2010
0
comments
There are numerous resources available to assist you during a system examination. A few of them include search engines, blogs, books, forums, and listservs. These resources have helped me gain a better understanding of the data I’m seeing when processing cases. I thought one of the benefits of documenting the exploit artifacts left on a system would be to have a resource that could be referenced during examinations of compromised systems. I felt this would have been helpful during the examination of the system I discussed in the post Anatomy of a Drive-by II. I was unfamiliar with some of the artifacts from the attack against the system and this made it difficult to determine what vulnerability was exploited which lead to the malware being downloaded.
The one area of the attack vector I wasn't as confident about was the exploit used. The examination showed it could have involved Java, Adobe Reader, or the Windows Help Center Vulnerability. This was one of the reasons of why I started documenting the various attack vector artifacts by focusing on exploits instead of the delivery mechanisms. To identify the potential exploit artifacts I’m using the exploits in Metasploit by running the exploits against various test systems in order to see what artifacts are created. The first vulnerability I researched using Metasploit was the CVE-2010-1885 (Windows Help Center vulnerability) explot and the potential artifacts I found are documented here. However, this testing made me question if it’s feasible to use the artifacts left by Metasploit as a reference to compare against the exploits being used in the wild. I wondered if there was enough similarity between the various implementations of exploits (various exploit packs available) to make identifying the various artifacts meaningful. One way to find out is to compare the artifacts left by Metasploit against the artifacts left by an exploit pack being used in the wild. I'm going to be comparing the CVE-2010-1885 exploit artifacts against the system I suspected this vulnerability was exploited by an exploit pack. This will not only help determine the feasibility of using Metasploit to document exploit artifacts but the comparison can also show how useful a reference about attack vector artifacts could be.
Metasploit Potential Artifacts Summary
The potential artifacts of the CVE 2010-1885 exploit included the exploit itself and the changes the exploit caused in the operating system environment. As a reminder, the following is the summary of the five artifact areas and the artifacts located in those areas:
* Artifact with references to the ASX and iframe variables
- htm file located in a temporary folder
* Artifacts associated with the files specified in the ASX and iframe variables being accessed
- ASX file located in a temporary folder (parname = )
- htm file containing the iframe pointing to the hcp string
- Image file located in a temporary folder
- References to the above artifacts being accessed [Internet Explorer history contained entries of the files being accessed].
* Folder of interest associated with the exploit
- Activity involving the helpctr folder
* Artifacts associated with the hcp protocol
- Internet Explorer’s index.dat file recorded the activity of the hcp protocol
- Files located in the Temporary Internet Files folder. Files located in this folder are the same files which were located in the helpctr folder
* Artifacts associated with the Windows programs executed during the exploit
- Programs were executed verclsid.exe, helpctr.exe, and helpsvc.exe
Review of the Anatomy of a Drive-by Examination
The comparison will be made using the timeline and image of the system I referenced in the Anatomy of a Drive-by posts. The system will be examined to identify any of the potential artifacts from the Windows Help Center vulnerability being exploited. The bullets below show the attack artifacts I located when I examined this system (I copied the bullets from the drive-by post):
* 09/12/10 06:38:25PM show[1].htm file was created on the system. This file had references to a few of the artifacts (jar file and the Windows Help Center vulnerability). Also, this file was associated with the xhaito[dot]com domain.
* 09/12/10 06:38:35PM The hcp[1].htm file was created on the system. The content of this file is associated with the Windows Help Center vulnerability.
* 09/12/10 06:38:35PM 0.8503427712213907.exe (Hiloti MD5 a06e417b9743e65bbb9ace16d6d3a65f) was created.
To be safe I'm starting the review one minute before 06:38:25PM and five minutes afterwards. I think this timeframe is sufficient to identify if any CVE-2010-1885 exploit artifacts are present. The picture below shows the first portion of the system activity involving the Windows Help center vulnerability.
The xhaito domain was hosting an exploit pack used to compromise the system. There was a hidden iframe in the rain[1].htm that pointed to the xhaito domain (Line 847906) and the PrivacIE entry showed the system visited the malicious domain (Line 847904). The first artifact of the CVE-2010-1885 exploit was the htm file named show[1].htm in the Temporary Internet Files folder (line 847907). Jsunpack was used to examine the htm file when the malicious domain was still active. As a result, not only could you see a reference to an ASX file but the ASX file was actually downloaded as shown below.
I examined the show[1].htm file again to see if there was still a reference to an ASX file when the malicious domain was no longer active. The ASX file wasn’t downloaded but there was still a reference indicating an ASX file was involved.
The show[1].htm file also had a reference to the htm file containing the hcp string. The entire string was captured by Jsunpack when the malicious domain was still active as shown below.
There was only a reference to the htm file containing the hcp string when the domain was active. This reference can still be used to explain where the htm file came from.
The picture below shows the next portion of the system activity involving the Windows Help Center vulnerability.
The htm file (hcp[1].htm) referenced in the show[1].htm file was created on the system in the Temporary Internet Files folder (line 847947). The file’s content was obfuscated as shown below.
I used Jsunpack to examine the file in order to deobfuscate the file’s content. This revealed the hcp string as shown below.
The picture below shows the last portion of the system activity involving the Windows Help Center vulnerability.
The first artifact in the picture occurred on Line 847985 which was a modification to the registry key HKU\Software\Microsoft\MediaPlayer\Health. This same registry key was modified when Metasploit was run against the test systems running Internet Explorer 8. I didn’t find a lot of information about this key but I came across a forum where a person stated Windows Media Player may use this key to determine if the player shut down properly. I ran a few tests using Procmon and found that Windows Media Player creates a subkey in this location with a name similar to {4AC12489-C148-4C7F-9FA0-3C5D8A590E0D} when the player is started. This subkey is deleted when the player shuts down properly but remains if not properly shut down. I consistently saw this behavior in my testing on XP and this registry modification may indicate that Windows Media Player was running. The last artifact was the pchealth\helpctr folder being accessed. This activity occurred on Lines 847993 and 847994.
Potential Artifacts Comparison
The examination was able to locate various artifacts associated with the CVE 2010-1885 exploit. It may not be clear how many of the Metasploit artifacts were actually located on the system. To help this comparison the five Metasploit artifact areas and the artifacts located in those areas are listed below with notes in red highlighting if the artifact was present on the system:
* Artifact with references to the ASX and iframe variables
- htm file located in a temporary folder *** Artifact not present ***
* Artifacts associated with the files specified in the ASX and iframe variables being accessed
- ASX file located in a temporary folder (parname = ) *** show[1].htm file with references to an ASX file ***
- htm file containing the iframe pointing to the hcp string *** show[1].htm file with references to the iframe containing the hcp exploit ***
- Image file located in a temporary folder *** Artifact not present ***
- References to the above artifacts being accessed [Internet Explorer history contained entries of the files being accessed] *** Artifact not present ***
* Folder of interest associated with the exploit
- Activity involving the helpctr folder *** helpctr folder was accessed ***
* Artifacts associated with the hcp protocol
- Internet Explorer’s index.dat file recorded the activity of the hcp protocol *** Artifact not present ***
- Files located in the Temporary Internet Files folder. Files located in this folder are the same files which were located in the helpctr folder *** Artifact not present ***
* Artifacts associated with the Windows programs executed during the exploit
- programs were executed verclsid.exe, helpctr.exe, and helpsvc.exe *** Only artifact present in the timeline of interest was the registry key HKU\Software\Microsoft\MediaPlayer\Health indicating the player was running. Verclsid.exe executed 30 minutes after my timeline of interest ***
Conclusion
As I was going back over the examination of this system I kept thinking how useful this information would have been when I first examined the system. I was still able to identify the CVE-2010-1885 exploit was involved with the attack but I didn’t locate all of the artifacts of this attack such as the helpctr folder activity. Having a resource with this information would have allowed me to see the pattern of this attack in the data. I think this pattern could be helpful even when certain artifacts are not present on the system.
The system didn’t have the entire documented CVE-2010-1885 exploit artifacts present. However, I don’t think the same artifacts would appear between the various exploit packs targeting this vulnerability. For example, a member of the Win4n6 Yahoo group said they located the web browser entries in unallocated space showing activity of the hcp protocol. One of the entries even contained the hcp exploit string. This artifact wasn’t present on the system I examined but this artifact was present on the test system Metasploit was run against. Even with this slight variation, I think the artifacts that are present could be used to determine if this vulnerability was targeted in an attack.
I know this is only one comparison but there appears to be enough similarity between the various implementations of an exploit to make identifying the various artifacts meaningful. Metasploit is one tool that could be used to help identify and document these artifacts.
Thoughts? Comments?
The one area of the attack vector I wasn't as confident about was the exploit used. The examination showed it could have involved Java, Adobe Reader, or the Windows Help Center Vulnerability. This was one of the reasons of why I started documenting the various attack vector artifacts by focusing on exploits instead of the delivery mechanisms. To identify the potential exploit artifacts I’m using the exploits in Metasploit by running the exploits against various test systems in order to see what artifacts are created. The first vulnerability I researched using Metasploit was the CVE-2010-1885 (Windows Help Center vulnerability) explot and the potential artifacts I found are documented here. However, this testing made me question if it’s feasible to use the artifacts left by Metasploit as a reference to compare against the exploits being used in the wild. I wondered if there was enough similarity between the various implementations of exploits (various exploit packs available) to make identifying the various artifacts meaningful. One way to find out is to compare the artifacts left by Metasploit against the artifacts left by an exploit pack being used in the wild. I'm going to be comparing the CVE-2010-1885 exploit artifacts against the system I suspected this vulnerability was exploited by an exploit pack. This will not only help determine the feasibility of using Metasploit to document exploit artifacts but the comparison can also show how useful a reference about attack vector artifacts could be.
Metasploit Potential Artifacts Summary
The potential artifacts of the CVE 2010-1885 exploit included the exploit itself and the changes the exploit caused in the operating system environment. As a reminder, the following is the summary of the five artifact areas and the artifacts located in those areas:
* Artifact with references to the ASX and iframe variables
- htm file located in a temporary folder
* Artifacts associated with the files specified in the ASX and iframe variables being accessed
- ASX file located in a temporary folder (parname = )
- htm file containing the iframe pointing to the hcp string
- Image file located in a temporary folder
- References to the above artifacts being accessed [Internet Explorer history contained entries of the files being accessed].
* Folder of interest associated with the exploit
- Activity involving the helpctr folder
* Artifacts associated with the hcp protocol
- Internet Explorer’s index.dat file recorded the activity of the hcp protocol
- Files located in the Temporary Internet Files folder. Files located in this folder are the same files which were located in the helpctr folder
* Artifacts associated with the Windows programs executed during the exploit
- Programs were executed verclsid.exe, helpctr.exe, and helpsvc.exe
Review of the Anatomy of a Drive-by Examination
The comparison will be made using the timeline and image of the system I referenced in the Anatomy of a Drive-by posts. The system will be examined to identify any of the potential artifacts from the Windows Help Center vulnerability being exploited. The bullets below show the attack artifacts I located when I examined this system (I copied the bullets from the drive-by post):
* 09/12/10 06:38:25PM show[1].htm file was created on the system. This file had references to a few of the artifacts (jar file and the Windows Help Center vulnerability). Also, this file was associated with the xhaito[dot]com domain.
* 09/12/10 06:38:35PM The hcp[1].htm file was created on the system. The content of this file is associated with the Windows Help Center vulnerability.
* 09/12/10 06:38:35PM 0.8503427712213907.exe (Hiloti MD5 a06e417b9743e65bbb9ace16d6d3a65f) was created.
To be safe I'm starting the review one minute before 06:38:25PM and five minutes afterwards. I think this timeframe is sufficient to identify if any CVE-2010-1885 exploit artifacts are present. The picture below shows the first portion of the system activity involving the Windows Help center vulnerability.
The xhaito domain was hosting an exploit pack used to compromise the system. There was a hidden iframe in the rain[1].htm that pointed to the xhaito domain (Line 847906) and the PrivacIE entry showed the system visited the malicious domain (Line 847904). The first artifact of the CVE-2010-1885 exploit was the htm file named show[1].htm in the Temporary Internet Files folder (line 847907). Jsunpack was used to examine the htm file when the malicious domain was still active. As a result, not only could you see a reference to an ASX file but the ASX file was actually downloaded as shown below.
I examined the show[1].htm file again to see if there was still a reference to an ASX file when the malicious domain was no longer active. The ASX file wasn’t downloaded but there was still a reference indicating an ASX file was involved.
The show[1].htm file also had a reference to the htm file containing the hcp string. The entire string was captured by Jsunpack when the malicious domain was still active as shown below.
There was only a reference to the htm file containing the hcp string when the domain was active. This reference can still be used to explain where the htm file came from.
The picture below shows the next portion of the system activity involving the Windows Help Center vulnerability.
The htm file (hcp[1].htm) referenced in the show[1].htm file was created on the system in the Temporary Internet Files folder (line 847947). The file’s content was obfuscated as shown below.
I used Jsunpack to examine the file in order to deobfuscate the file’s content. This revealed the hcp string as shown below.
The picture below shows the last portion of the system activity involving the Windows Help Center vulnerability.
The first artifact in the picture occurred on Line 847985 which was a modification to the registry key HKU\Software\Microsoft\MediaPlayer\Health. This same registry key was modified when Metasploit was run against the test systems running Internet Explorer 8. I didn’t find a lot of information about this key but I came across a forum where a person stated Windows Media Player may use this key to determine if the player shut down properly. I ran a few tests using Procmon and found that Windows Media Player creates a subkey in this location with a name similar to {4AC12489-C148-4C7F-9FA0-3C5D8A590E0D} when the player is started. This subkey is deleted when the player shuts down properly but remains if not properly shut down. I consistently saw this behavior in my testing on XP and this registry modification may indicate that Windows Media Player was running. The last artifact was the pchealth\helpctr folder being accessed. This activity occurred on Lines 847993 and 847994.
Potential Artifacts Comparison
The examination was able to locate various artifacts associated with the CVE 2010-1885 exploit. It may not be clear how many of the Metasploit artifacts were actually located on the system. To help this comparison the five Metasploit artifact areas and the artifacts located in those areas are listed below with notes in red highlighting if the artifact was present on the system:
* Artifact with references to the ASX and iframe variables
- htm file located in a temporary folder *** Artifact not present ***
* Artifacts associated with the files specified in the ASX and iframe variables being accessed
- ASX file located in a temporary folder (parname = ) *** show[1].htm file with references to an ASX file ***
- htm file containing the iframe pointing to the hcp string *** show[1].htm file with references to the iframe containing the hcp exploit ***
- Image file located in a temporary folder *** Artifact not present ***
- References to the above artifacts being accessed [Internet Explorer history contained entries of the files being accessed] *** Artifact not present ***
* Folder of interest associated with the exploit
- Activity involving the helpctr folder *** helpctr folder was accessed ***
* Artifacts associated with the hcp protocol
- Internet Explorer’s index.dat file recorded the activity of the hcp protocol *** Artifact not present ***
- Files located in the Temporary Internet Files folder. Files located in this folder are the same files which were located in the helpctr folder *** Artifact not present ***
* Artifacts associated with the Windows programs executed during the exploit
- programs were executed verclsid.exe, helpctr.exe, and helpsvc.exe *** Only artifact present in the timeline of interest was the registry key HKU\Software\Microsoft\MediaPlayer\Health indicating the player was running. Verclsid.exe executed 30 minutes after my timeline of interest ***
Conclusion
As I was going back over the examination of this system I kept thinking how useful this information would have been when I first examined the system. I was still able to identify the CVE-2010-1885 exploit was involved with the attack but I didn’t locate all of the artifacts of this attack such as the helpctr folder activity. Having a resource with this information would have allowed me to see the pattern of this attack in the data. I think this pattern could be helpful even when certain artifacts are not present on the system.
The system didn’t have the entire documented CVE-2010-1885 exploit artifacts present. However, I don’t think the same artifacts would appear between the various exploit packs targeting this vulnerability. For example, a member of the Win4n6 Yahoo group said they located the web browser entries in unallocated space showing activity of the hcp protocol. One of the entries even contained the hcp exploit string. This artifact wasn’t present on the system I examined but this artifact was present on the test system Metasploit was run against. Even with this slight variation, I think the artifacts that are present could be used to determine if this vulnerability was targeted in an attack.
I know this is only one comparison but there appears to be enough similarity between the various implementations of an exploit to make identifying the various artifacts meaningful. Metasploit is one tool that could be used to help identify and document these artifacts.
Thoughts? Comments?
Labels:
attack vectors,
exploits,
hcp
Posts
