Linkfest
Taking a page from Claus's book...
I was reading the latest print edition of Hackin9, and in the In Brief section, there is a small inset that talks about some research conducted by Stephan Chenette of WebSense, in which Javascript can be used to download segments of malware code to be downloaded via different streams, allowing it to bypass gateways and AV scans. Back in the day, I'd performed some network exploitation research and written some code that would (a) download an EXE from a web site, which had been renamed to .gif, (b) break it into segments and store it in the Registry, and (c) at a specified date and time, reassemble the segments into a complete executable within the System Volume Information directory, and (d) launch it...Stephan's technique is definitely a twist on things and very interesting, in that Javascript can be used to download the EXE segments from multiple locations, as if they were .gifs on different web pages, and then reassemble them on the system. This is one of those techniques that will be difficult to address, as it doesn't really take advantage of a vulnerability that can be patched, per se. However, it may force the AV industry to evolve.
The SANS Internet Storm Center posted a link to information about the Verizon Business RISK Team's 2009 Data Breach Investigation Report, and pulled out some of the interesting statistics developed and provided in the Verizon report. You can find some additional information about the report at the Verizon Business Security Blog. Overall, like many, I think that the information provided in these reports is very useful and insightful, as the numbers are based on actual case work, NOT on questionnaires. As such, you have responders building tables of numbers and developing the percentages, rather than the victims...more accurate numbers will only help us with these issues in the long run.
Timeline Sources - Let's not forget that using Pasco, you can parse the resulting output and incorporate the contents of a user's index.dat (ForensicWiki IE history fil format page) into your timeline analysis. You can also incorporate Keith Jones' whitepaper that is the foundation of Pasco into your own timeline development process, either to parse the index.dat files directly to your timeline format, or to provide additional detail to the events that you do find. This is not to say that histories from other browsers aren't important, as well.
ForensicWiki - Firefox 3 history file format
BelkaSoft Browser Analyzer
Mandiant's WebHistorian
Also, there may be sources of timeline d
ata that are not easily defined or automatically parseable; for example, I have often looked to Dr Watson log files for indications that malware or other processes were (or were not) running at a specific point in time, as each entry in the log includes a list of the active processes at the time of the application crash. All I really have at that point is point in time and a non-specific statement. Sounds like I need to write up that GUI for entering such events...oh, wait... ;-) So this is a nice little app that lets me enter the date (numbers for the month instead of the letters...'8' instead of 'Aug'), the time (already converted to GMT) and other info, and then tell it which event file to add the information to...the five field format is used that the information is added right to the event file. At that point, all you do is re-run the event file parsing script and your new event appears in the proper location within your timeline.
I was reading the latest print edition of Hackin9, and in the In Brief section, there is a small inset that talks about some research conducted by Stephan Chenette of WebSense, in which Javascript can be used to download segments of malware code to be downloaded via different streams, allowing it to bypass gateways and AV scans. Back in the day, I'd performed some network exploitation research and written some code that would (a) download an EXE from a web site, which had been renamed to .gif, (b) break it into segments and store it in the Registry, and (c) at a specified date and time, reassemble the segments into a complete executable within the System Volume Information directory, and (d) launch it...Stephan's technique is definitely a twist on things and very interesting, in that Javascript can be used to download the EXE segments from multiple locations, as if they were .gifs on different web pages, and then reassemble them on the system. This is one of those techniques that will be difficult to address, as it doesn't really take advantage of a vulnerability that can be patched, per se. However, it may force the AV industry to evolve.
The SANS Internet Storm Center posted a link to information about the Verizon Business RISK Team's 2009 Data Breach Investigation Report, and pulled out some of the interesting statistics developed and provided in the Verizon report. You can find some additional information about the report at the Verizon Business Security Blog. Overall, like many, I think that the information provided in these reports is very useful and insightful, as the numbers are based on actual case work, NOT on questionnaires. As such, you have responders building tables of numbers and developing the percentages, rather than the victims...more accurate numbers will only help us with these issues in the long run.
Timeline Sources - Let's not forget that using Pasco, you can parse the resulting output and incorporate the contents of a user's index.dat (ForensicWiki IE history fil format page) into your timeline analysis. You can also incorporate Keith Jones' whitepaper that is the foundation of Pasco into your own timeline development process, either to parse the index.dat files directly to your timeline format, or to provide additional detail to the events that you do find. This is not to say that histories from other browsers aren't important, as well.
ForensicWiki - Firefox 3 history file format
BelkaSoft Browser Analyzer
Mandiant's WebHistorian
Also, there may be sources of timeline d
ata that are not easily defined or automatically parseable; for example, I have often looked to Dr Watson log files for indications that malware or other processes were (or were not) running at a specific point in time, as each entry in the log includes a list of the active processes at the time of the application crash. All I really have at that point is point in time and a non-specific statement. Sounds like I need to write up that GUI for entering such events...oh, wait... ;-) So this is a nice little app that lets me enter the date (numbers for the month instead of the letters...'8' instead of 'Aug'), the time (already converted to GMT) and other info, and then tell it which event file to add the information to...the five field format is used that the information is added right to the event file. At that point, all you do is re-run the event file parsing script and your new event appears in the proper location within your timeline.
