There's an interesting article by Lauro DiDio over on NewsFactor about the Linux vs. Windows Total Cost of Ownership (TCO) argument. The article has some really interesting comments (for the popular media, that is), specifically, that there is no one-size-fits-all, silver bullet solution.
Wow. This harkens back to the "which is more secure" argument...I think the best response to that one is that the operating system is irrelevant in the face of poor administration.
Something that really jumped out at me from the article was the following: "If you do not know what is on your network...then you cannot truly evaluate whether Linux, Windows or Unix is right for your business."
How true is that? I've seen it with large as well as small networks...folks just have no idea what's out there. The same holds true with incident response...
Wednesday, August 17, 2005
Industry_Insider article
An article I wrote appeared in the MS Industry Insider blog recently. The article is about two misconceptions I see in the IT world when it comes to incident response, specifically on Windows systems...that the best thing to do if you think that a Windows system has been compromised or infected is to wipe it and re-install from clean media, and that bootable Linux distributions are the best tools to use for Windows incident response.
My comments on these misconceptions are supported by the recent NIST document SP 800-86: Guide to Computer and Network Data Analysis: Applying Forensic Techniques to Incident Response. I found the link to this paper over on Keith Jones' blog.
So...take a look, I'd appreciate any comments you may have, particularly regarding the article.
My comments on these misconceptions are supported by the recent NIST document SP 800-86: Guide to Computer and Network Data Analysis: Applying Forensic Techniques to Incident Response. I found the link to this paper over on Keith Jones' blog.
So...take a look, I'd appreciate any comments you may have, particularly regarding the article.
Monday, August 15, 2005
GMU2005 presentations updated!
Well, the first day of GMU2005 went off without a hitch. Sunday evening I updated my presentations...nothing major, just a bullet here, a link there. I've also added some of the Perl scripts mentioned in my presentations...after posting the presentations, some folks reviewing them began asking me for the scripts. I didn't provide them because, well, in the past, no one seemed interested.
To get the new archive, just click here.
There was a glitch with presenters this morning, so I pulled out an already-approved presentation and gave that one to fill the time (and yes, that one's included in the archive as well..."The Windows Registry as a Forensics Resource").
Everything went pretty smoothly, and I got some interesting comments, both during and after the presentations. Some folks would come up and say, "great job!", while others would say something along the lines of, "I'm working on a case where I could really use this information."
To all who attended my presentations today...thanks!
Tomorrow and Thursday, I'll be presenting two presentations each day...one on file metadata, and another on USB-connect storage devices. After each presentation, I'll ask a question, and whomever answers it correctly gets a free copy of my book!
To get the new archive, just click here.
There was a glitch with presenters this morning, so I pulled out an already-approved presentation and gave that one to fill the time (and yes, that one's included in the archive as well..."The Windows Registry as a Forensics Resource").
Everything went pretty smoothly, and I got some interesting comments, both during and after the presentations. Some folks would come up and say, "great job!", while others would say something along the lines of, "I'm working on a case where I could really use this information."
To all who attended my presentations today...thanks!
Tomorrow and Thursday, I'll be presenting two presentations each day...one on file metadata, and another on USB-connect storage devices. After each presentation, I'll ask a question, and whomever answers it correctly gets a free copy of my book!
Friday, August 12, 2005
GMU2005 presentations posted!!
I finally received approval for public release of my presentations for GMU2005...which starts Monday. ;-) Ugh...don't even...
There are three PPTs in the archive...one on the Windows Event Log file format, one on tracking USB storage devices across Windows systems, and one on file/document metadata. Take a look, and if you have any questions or comments, please feel free to post them here, or email me...
There are three PPTs in the archive...one on the Windows Event Log file format, one on tracking USB storage devices across Windows systems, and one on file/document metadata. Take a look, and if you have any questions or comments, please feel free to post them here, or email me...
Thursday, August 11, 2005
FRUC INI files
If you're currently using the FSPC/FRUC tools, what would you think about posting your INI files for others to see?
An explanation of the FSPC and the FRUC
Okay, so I posted my updates of the FRUC yesterday, and I'm glad I got that out of the way. But I probably need to give an explanation of the FRUC, and talk about why I wrote it in the first place.
When performing incident response activities, it's generally considered a GOOD THING to get the data you're collecting off of the victim system. In some cases, writing files to the hard drive of the victim system may overwrite important data that's in slack space, but just getting the data off of the system so that it can be analyzed quickly is important. You may simply want to determine quickly whether you have a real incident or not.
Well, on way of doing this is to write the files to the drive, archive them using a zipping utility, and then FTP/TFTP the archive to a waiting server. Hhhhmmm...lots of steps, creates files on the drive...okay, that may work sometimes, but what else have you got?
Another option is to use netcat to get the data off of the system. The way it works is this...you open netcat as a listener on your forensic server and head on over to the victim system. Once there, you run the commands you would use to gather data...command line tools that will display their output at the console, or STDOUT...and rather than viewing the output of the commands on the screen in front of you, you "pipe" the output through netcat, sending the data to the waiting server. For the sake of brevity, the specifics of this are covered in my book, as well as in online resources like this one from Keith Jones.
Okay, so what we've got here is a way to get data off of the system. When you're all done, it ends up on your forensic server in one big file, which you have to parse apart before you analyze it. Also, you've had to maintain a notebook detailing everything you've done...commands you ran, when you ran them, etc. Just typing in all those commands can be pretty tedious, even if you have them written down...right? Say that you have multiple boxes you're looking at...what then? You've got to retype all of those commands...and maintain the notebook.
There must be an easier way...and there is!
Let's start with the server component first...the FSPC. This is the component that sits on your forensic server, waiting for connections. The FSPC basically handles data management...when a connection is received, the FSPC puts the files that it's sent into a directory, and keeps a timestamped log of everything that goes on. When data is sent to the FSPC, it generates a hash for the file that it creates. If a file is copied to the FSPC, it will verify the hashes of the file when it writes it to the hard drive.
The FRUC is the "First Responder Utility (Commandline)"...this means that there's no GUI, no buttons to push. The FRUC runs from a preconfigured .ini file, or via arguments entered at the commandline. Basically, the investigator or first responder copies the FRUC files (.exe files, supporting DLL, .ini file) and any third-party utilities that the FRUC will run to some media...a CD, a USB-connected thumb drive, etc. Once done, she carries it with her, or deploys it for someone else to use. Once the media is inserted into the machine, a single command is run, and all of the data that the investigator wants to collect is sent to the forensic server for storage.
Pretty simple, eh? Powerful tools, automated (to minimize mistakes and reduce the amount of time necessary to collect data), and minimal interaction required by the user.
The framework seems to be pretty complete for data collection at this point. As I've said before, data collection is easy...and from looking at the FSP, I hope you see that, too. It's the data analysis that's tough. One way to deploy this is to have multiple .ini files on the media. The user will insert the media and run the first .ini file, which collects certain data...say, process and network connection information, etc. On the server side, the investigator can run quick analysis tools/scripts, and determine whether a more detailed look is necessary. For larger investigations involving multiple machines, the investigator can open multiple FSPC listeners on the server, each on a different port, and instruct first responders to run the FRUC with the necessary commandline switch to change the port used in the .ini file.
There are other toolkits for pulling information from Windows systems, most notably IRCRv2 and WFT. However, I prefer the FSP framework...not just because I wrote it, but because I think that by removing some of the interaction that the first responder will have with the tools, it's easier to deploy and use, particularly in larger environments.
Also, while the FSPC and FRUC are deployed as executables, their Perl source is also provided (ie, the tools are compiled into executables using Perl2Exe). This makes the tools very extensible...using the Perl source, you can easily make your own modifications to the code, and extend the tools for your own use, in your own environment.
When performing incident response activities, it's generally considered a GOOD THING to get the data you're collecting off of the victim system. In some cases, writing files to the hard drive of the victim system may overwrite important data that's in slack space, but just getting the data off of the system so that it can be analyzed quickly is important. You may simply want to determine quickly whether you have a real incident or not.
Well, on way of doing this is to write the files to the drive, archive them using a zipping utility, and then FTP/TFTP the archive to a waiting server. Hhhhmmm...lots of steps, creates files on the drive...okay, that may work sometimes, but what else have you got?
Another option is to use netcat to get the data off of the system. The way it works is this...you open netcat as a listener on your forensic server and head on over to the victim system. Once there, you run the commands you would use to gather data...command line tools that will display their output at the console, or STDOUT...and rather than viewing the output of the commands on the screen in front of you, you "pipe" the output through netcat, sending the data to the waiting server. For the sake of brevity, the specifics of this are covered in my book, as well as in online resources like this one from Keith Jones.
Okay, so what we've got here is a way to get data off of the system. When you're all done, it ends up on your forensic server in one big file, which you have to parse apart before you analyze it. Also, you've had to maintain a notebook detailing everything you've done...commands you ran, when you ran them, etc. Just typing in all those commands can be pretty tedious, even if you have them written down...right? Say that you have multiple boxes you're looking at...what then? You've got to retype all of those commands...and maintain the notebook.
There must be an easier way...and there is!
Let's start with the server component first...the FSPC. This is the component that sits on your forensic server, waiting for connections. The FSPC basically handles data management...when a connection is received, the FSPC puts the files that it's sent into a directory, and keeps a timestamped log of everything that goes on. When data is sent to the FSPC, it generates a hash for the file that it creates. If a file is copied to the FSPC, it will verify the hashes of the file when it writes it to the hard drive.
The FRUC is the "First Responder Utility (Commandline)"...this means that there's no GUI, no buttons to push. The FRUC runs from a preconfigured .ini file, or via arguments entered at the commandline. Basically, the investigator or first responder copies the FRUC files (.exe files, supporting DLL, .ini file) and any third-party utilities that the FRUC will run to some media...a CD, a USB-connected thumb drive, etc. Once done, she carries it with her, or deploys it for someone else to use. Once the media is inserted into the machine, a single command is run, and all of the data that the investigator wants to collect is sent to the forensic server for storage.
Pretty simple, eh? Powerful tools, automated (to minimize mistakes and reduce the amount of time necessary to collect data), and minimal interaction required by the user.
The framework seems to be pretty complete for data collection at this point. As I've said before, data collection is easy...and from looking at the FSP, I hope you see that, too. It's the data analysis that's tough. One way to deploy this is to have multiple .ini files on the media. The user will insert the media and run the first .ini file, which collects certain data...say, process and network connection information, etc. On the server side, the investigator can run quick analysis tools/scripts, and determine whether a more detailed look is necessary. For larger investigations involving multiple machines, the investigator can open multiple FSPC listeners on the server, each on a different port, and instruct first responders to run the FRUC with the necessary commandline switch to change the port used in the .ini file.
There are other toolkits for pulling information from Windows systems, most notably IRCRv2 and WFT. However, I prefer the FSP framework...not just because I wrote it, but because I think that by removing some of the interaction that the first responder will have with the tools, it's easier to deploy and use, particularly in larger environments.
Also, while the FSPC and FRUC are deployed as executables, their Perl source is also provided (ie, the tools are compiled into executables using Perl2Exe). This makes the tools very extensible...using the Perl source, you can easily make your own modifications to the code, and extend the tools for your own use, in your own environment.
Wednesday, August 10, 2005
FRUC Updated!!
Finally!
I finally completed my development and testing of an updated version of the First Responder Utility (Commandline), the data collection portion of the Forensic Server Project.
A bit ago, one of the FSP users pointed out two things...first, that the commands listed in the INI file weren't run in order (he had included "date /t" and "time /t" at the beginning and the end of the list of commands...), and that there were some issues with commands that would hang.
So, I wanted to get this blog entry out...I'll be writing more about the use of the FSP and the FRUC as time goes on, but I wanted to let you know that the new version is out.
I finally completed my development and testing of an updated version of the First Responder Utility (Commandline), the data collection portion of the Forensic Server Project.
A bit ago, one of the FSP users pointed out two things...first, that the commands listed in the INI file weren't run in order (he had included "date /t" and "time /t" at the beginning and the end of the list of commands...), and that there were some issues with commands that would hang.
So, I wanted to get this blog entry out...I'll be writing more about the use of the FSP and the FRUC as time goes on, but I wanted to let you know that the new version is out.
Tuesday, August 09, 2005
A web site in an alternate data stream
A new blog by Inge Henriksen of Norway was pointed out to me today, and the posts so far are very interesting. One of the posts describes how to create an entire web site within NTFS Alternate Data Streams (ADSs).
An interesting thing about ADSs is that if you have a file with an ADS associated with it on a file share, and you drag-n-drop that file to another NTFS partition, the ADS will remain with the file. However, if you download files via HTTP or FTP, the ADSs are not persistent. But that's not what Inge is doing...the web server is simply serving up a file, and that's all that an ADS really is anyway...a file.
Remember, while Windows has native tools for creating ADSs, there are no tools native to the Windows distributions that allow you to view the existance of arbitrary ADSs.
If you're not familiar with ADSs, take a look at this article that I wrote on the subject...or read about ADSs in chapter 3 of my book.
An interesting thing about ADSs is that if you have a file with an ADS associated with it on a file share, and you drag-n-drop that file to another NTFS partition, the ADS will remain with the file. However, if you download files via HTTP or FTP, the ADSs are not persistent. But that's not what Inge is doing...the web server is simply serving up a file, and that's all that an ADS really is anyway...a file.
Remember, while Windows has native tools for creating ADSs, there are no tools native to the Windows distributions that allow you to view the existance of arbitrary ADSs.
If you're not familiar with ADSs, take a look at this article that I wrote on the subject...or read about ADSs in chapter 3 of my book.
USB blocking software
I ran across this NetworkWorld article on USB blocking software products, by Ellen Messmer, this morning. There's not a whole lot of interest in the article, from my perspective...it basically says that McAfee and Sygate are adding the functionality to their products.
What did catch my attention is the first sentence: Unauthorized use of USB hardware to gain access to information in laptops and servers is a growing concern.
Really? A growing concern for whom? What about all of those systems out there that haven't had the software installed on them yet, and may possibly have already been used in this unauthorized manner?
Well, if you're a regular reader of this blog, you already know how to go into systems and check to see if any USB removable storage devices have been connected to the system.
What did catch my attention is the first sentence: Unauthorized use of USB hardware to gain access to information in laptops and servers is a growing concern.
Really? A growing concern for whom? What about all of those systems out there that haven't had the software installed on them yet, and may possibly have already been used in this unauthorized manner?
Well, if you're a regular reader of this blog, you already know how to go into systems and check to see if any USB removable storage devices have been connected to the system.
Monday, August 08, 2005
Hashing code updates
Jesse Kornblum has updated md5deep, so head on over and pick up your copy. The tools include hashing programs for MD5, SHA-1, SHA-256, Tiger, and Whirlpool. Very, very cool. Jesse is THE MAN when it comes to these hashing programs, and he even goes so far as to provide a Windows binary of the tools.
MSRC Strider HoneyMonkey Project
I ran across the MS Security Response Center's (MSRC blog) Strider HoneyMonkey project this morning...very interesting stuff. From the web site:
The Strider HoneyMonkey Exploit Detection System, as the research project is code-named, was created to help detect attacks that use Web servers to exploit unpatched browser vulnerabilities and install malware on the PCs of unsuspecting users. Such attacks have become one of the most vexing issues confronting Internet security experts.
Sounds like it's kind of a client-based honeypot, with the system automating the actions of a user to have the browser go out and visit suspect web sites. This would be done by automating IE, and analyzing the system after it was infected. Wanna see how easy it is to automate IE? Check out Dave Roth's Perl on Win32 web site. Go to the Scripts archive and check out his IEEvents.pl script. This shows you how to use the Win32::OLE module to automate IE (which is a COM server) and have it do things for you.
And yet, like the GhostBuster thingy, this won't be a product that's released for use by anyone outside of MS.
Addendum [9 Aug]: It seems that others have (had??) picked up on the ol' honeymonkey. Rob Lemos has a SecurityFocus article on the honeymonkey, which points to a paper that MS just released this month. The paper even mentions that the honeymonkey detected a zero-day exploit, specifically the javaprxy.dll vulnerability (1, 2) that was known, but did not have an available patch. At the time it was detected (ie, early July 2005) it was not known whether it was being publicly exploited or not.
The Strider HoneyMonkey Exploit Detection System, as the research project is code-named, was created to help detect attacks that use Web servers to exploit unpatched browser vulnerabilities and install malware on the PCs of unsuspecting users. Such attacks have become one of the most vexing issues confronting Internet security experts.
Sounds like it's kind of a client-based honeypot, with the system automating the actions of a user to have the browser go out and visit suspect web sites. This would be done by automating IE, and analyzing the system after it was infected. Wanna see how easy it is to automate IE? Check out Dave Roth's Perl on Win32 web site. Go to the Scripts archive and check out his IEEvents.pl script. This shows you how to use the Win32::OLE module to automate IE (which is a COM server) and have it do things for you.
And yet, like the GhostBuster thingy, this won't be a product that's released for use by anyone outside of MS.
Addendum [9 Aug]: It seems that others have (had??) picked up on the ol' honeymonkey. Rob Lemos has a SecurityFocus article on the honeymonkey, which points to a paper that MS just released this month. The paper even mentions that the honeymonkey detected a zero-day exploit, specifically the javaprxy.dll vulnerability (1, 2) that was known, but did not have an available patch. At the time it was detected (ie, early July 2005) it was not known whether it was being publicly exploited or not.
Thursday, August 04, 2005
Analysis of a Win2K rootkit
I ran across this site recently (can't remember where I originally got the link) and finally got around to actually reading through it.
The first thing that jumps out at me is that the content is incorrectly titled. When talking about rootkits, particularly on Windows systems, the term most generally refers to tools that are used to hide the attacker's presence from not only the Administrator, but the operating system and native tools, as well. However, I suppose that since the attacker "had root", used two self-extracting archives (kits) to move his tools over, and "hide" from casual viewing by (a) using the attrib command, and (b) deleting some files, then technically, it is a "root kit".
Like I've said before, I really like to see things like this posted...seriously. I've heard from others that not only are such things interesting to read, but they provide a great learning opportunity, and I wholeheartedly agree.
I do have a couple of suggestions for improvement, and a question. First, the question...the author makes reference to the HKU\{SID}\Software\Microsoft\Internet Explorer\Explorer Bars\{GUID}\FilesNamedMRU key, and seems to indicate that this location can be used as an autostart location (ie, "...thus executing all of the files listed if any one of them is started.").
Does anyone have any insight on this? I'm going to try this out and see what happens, but I'd love to know how close he is on this.
Okay...suggestions...constructive stuff. I like the screen captures, but there's a lot going on in the article that would really benefit from a screen capture or two. For example, ...used an MSBlaster style exploit to open port 4444 with root privileges... Okay...but can we see that? For example, how about showing the output of fport/openports side-by-side with the output of handle.exe, showing the user context of the process? That would be cool.
Throughout the article, the author speculates as to the intentions of the attacker. I don't necessarily disagree with his assessment of the skill level of the attacker (though I'd like to see more detailed information), but I think that sometimes we can misguide ourselves when we try to guess someone's intentions.
Finally, there are some confusing statements in the article. For example,
The first thing that jumps out at me is that the content is incorrectly titled. When talking about rootkits, particularly on Windows systems, the term most generally refers to tools that are used to hide the attacker's presence from not only the Administrator, but the operating system and native tools, as well. However, I suppose that since the attacker "had root", used two self-extracting archives (kits) to move his tools over, and "hide" from casual viewing by (a) using the attrib command, and (b) deleting some files, then technically, it is a "root kit".
Like I've said before, I really like to see things like this posted...seriously. I've heard from others that not only are such things interesting to read, but they provide a great learning opportunity, and I wholeheartedly agree.
I do have a couple of suggestions for improvement, and a question. First, the question...the author makes reference to the HKU\{SID}\Software\Microsoft\Internet Explorer\Explorer Bars\{GUID}\FilesNamedMRU key, and seems to indicate that this location can be used as an autostart location (ie, "...thus executing all of the files listed if any one of them is started.").
Does anyone have any insight on this? I'm going to try this out and see what happens, but I'd love to know how close he is on this.
Okay...suggestions...constructive stuff. I like the screen captures, but there's a lot going on in the article that would really benefit from a screen capture or two. For example, ...used an MSBlaster style exploit to open port 4444 with root privileges... Okay...but can we see that? For example, how about showing the output of fport/openports side-by-side with the output of handle.exe, showing the user context of the process? That would be cool.
Throughout the article, the author speculates as to the intentions of the attacker. I don't necessarily disagree with his assessment of the skill level of the attacker (though I'd like to see more detailed information), but I think that sometimes we can misguide ourselves when we try to guess someone's intentions.
Finally, there are some confusing statements in the article. For example,
- The svc.bat file sets the user name of the IRC bot in win.dll (which is actually just a plain text file)...
- ...but instead sets the machine up as a warez server via IRC. The bot installed connects to irc.efnet.com and joins the channel #XiSO...
- Edit the C:\WINNT\system32\Setup\svchost\x.pid file to find the process id (PID) of the IRC daemon
- This stops the IRC daemon from running
- ...suggest the intended use for this kit is not just to run an IRC bot...
So, is it a 'bot or a daemon? Client or server? It sounds like it's a 'bot/client, based on the explanation, but the use of the term 'daemon' suggests a server or service. This is an important distinction.
The author says, "This results in 3 processes called lsass.exe, though only one is legitimate." This demonstrates a "hiding" technique that still works. Basically, the attacker started several processes named "lsass.exe", but because the executable images weren't in the system32 directory, there were no issues with WFP. Even though you won't see the full path to the executable images in the Task Manager, just having more than one copy of lsass.exe running should be a tip to even the most casual observer. Now, using 'svchost.exe' is another matter entirely...
Overall, a great job. Shout-outs/greetz to the author.
MS Office 2003 Redaction tool
I got an email this morning about a tool released by MS called the "Office 2003 Redaction Tool". This tool is an Office 2003 add-in that allows you to redact documents.
Now, many of us are aware of issues with redaction, as well as with metadata in Office documents in general. In the past, folks have posted "redacted" PDF documents to the web, only to have someone with a slow download speed find out that the redaction was...well...not a good as expected. Talk about low-tech! Some of the earliest issues I'm aware of involved someone downloading a PDF document, and then being surprised when, through a slow link, serveral words were suddenly replaced with black blocks! Hey! In a nutshell, it simply took a few more seconds for the redaction blocks to crawl through the link and make their appearance on the page. At that point, all the reader had to do was remove the blocks.
So, I downloaded and installed the redaction tool, and opened up a small document I have on my desktop. I redacted two unique words in the document, and saved the resulting document. I then opened the resulting document in a hex editor and found that in hex, the redacted words had been replaced by "7C". Wow.
This is simply an initial test. There's lots more to do. For example, it appears that the redaction tool also looks in the document properties (ie, metadata) for the same redacted words...I say "appears" because I don't know for sure yet.
Something else to consider is this...let's say that you have a Word document, and in the interests of national security, you need to redact the phrase "small happy dog". Now, let's then assume that you have the phrase "I'm really happy about my job" in the comments (metadata) for the document.
Now, many of us are aware of issues with redaction, as well as with metadata in Office documents in general. In the past, folks have posted "redacted" PDF documents to the web, only to have someone with a slow download speed find out that the redaction was...well...not a good as expected. Talk about low-tech! Some of the earliest issues I'm aware of involved someone downloading a PDF document, and then being surprised when, through a slow link, serveral words were suddenly replaced with black blocks! Hey! In a nutshell, it simply took a few more seconds for the redaction blocks to crawl through the link and make their appearance on the page. At that point, all the reader had to do was remove the blocks.
So, I downloaded and installed the redaction tool, and opened up a small document I have on my desktop. I redacted two unique words in the document, and saved the resulting document. I then opened the resulting document in a hex editor and found that in hex, the redacted words had been replaced by "7C". Wow.
This is simply an initial test. There's lots more to do. For example, it appears that the redaction tool also looks in the document properties (ie, metadata) for the same redacted words...I say "appears" because I don't know for sure yet.
Something else to consider is this...let's say that you have a Word document, and in the interests of national security, you need to redact the phrase "small happy dog". Now, let's then assume that you have the phrase "I'm really happy about my job" in the comments (metadata) for the document.
Wednesday, August 03, 2005
Process monitoring and malware analysis
As part of looking into ways of improving malware analysis, I got to thinking about some things. For instance, some malware may maintain encrypted strings (ie, passwords or URLs) which it then decrypts in memory, and deletes once the string has been used. Some data used by the malware process may be transient in memory. So what do you do?
Well, I had a thought...what if you could run a process for a specified period of time, dump the contents of memory (and maybe run some other tools), then resume the process for a short period of time? Using Perl, we can do this! Here's the code:
#! c:\perl\bin\perl.exe
# strap.pl
# use to launch an application (malware) and then at predefined
# intervals, suspend() the process, perform some actions (ie, dump
# contents of memory, run external programs like listdlls.exe, etc.)
# then resume the application
use strict;
use Win32::Process;
So, we're using the Win32::Process module. Now, let's set up our variables. For testing purposes, I used AIM...
my $proc;
my $app = "c:\\program files\\aim\\aim.exe";
my $args = "";
my $dir = ".";
my $exit_code;
Now, let's go ahead and create our process...
if (Win32::Process::Create($proc,$app,$args,0,NORMAL_PRIORITY_CLASS,$dir)) {
print "Process created.\n";
# Get PID
my $pid = $proc->GetProcessID();
print "Process $pid created.\n";
Now that we've created our process, let's let it run for a bit (in this case, 3 seconds), then suspend the process. What we're doing, for testing purposes is running this loop only 10 times. This can be expanded (and the Wait() time changed, as well), or an entirely different loop structure can be used.
foreach (1..10) {
$proc->Wait(3000);
$proc->Suspend();
print "Process suspended.\n";
Now that the process has been suspended, we can go ahead and do things like dump process memory (with pmdump.exe), or run tools like handle.exe, listdlls.exe, etc.
sleep(3);
Once we're done, go ahead and resume the process...
$proc->Resume();
print "Process resumed.\n";
}
}
Now, just a little error checking...
else {
print "Process creation failed: ".Win32::FormatMessage Win32::GetLastError()."\n";
exit(1);
}
So, once this script has completed, you can conduct your analysis. For memory dumps, run strings.exe against the files, or use scripts to extract email or IP addresses, etc.
Addedum: In responding to some comments this morning, I thought that something I said should be included in the text of the post itself.
What I've presented above is not meant to replace anything. Rather, it's a tool...nothing more. Like any tool, it's effectiveness depends upon how you use it. One possible scenario for the use of this tool would be where an administrator or analyst has an unknown bit of software (we won't call it malware yet b/c we don't know). When looking at the program with a hex editor (part of performing static analysis), the analyst may believe that the program is encrypted or obfuscated in some manner. Now, most admins/analysts don't have tools like IDAPro at their disposal, and don't have the necessary skill sets to use things like debuggers and disassemblers. So, moving on to dynamic analysis, they want to run the program on a "sacrificial lamb" system to see what it does. Loading up monitoring tools, the analyst may want to run the application in a more controlled fashion, dumping memory contents along the way.
The above script will let you do that. Admittedly, the script itself is raw, and in it's early stages...but the basic idea is there. The great thing about scripts like this is that they can be easily expanded. For example, let's say we replace sleep(3) the necessary command to run pmdump.exe. When the above script ends, you'll have a directory with a bunch of memory dump files. Well, at that point, the script can then:
Well, I had a thought...what if you could run a process for a specified period of time, dump the contents of memory (and maybe run some other tools), then resume the process for a short period of time? Using Perl, we can do this! Here's the code:
#! c:\perl\bin\perl.exe
# strap.pl
# use to launch an application (malware) and then at predefined
# intervals, suspend() the process, perform some actions (ie, dump
# contents of memory, run external programs like listdlls.exe, etc.)
# then resume the application
use strict;
use Win32::Process;
So, we're using the Win32::Process module. Now, let's set up our variables. For testing purposes, I used AIM...
my $proc;
my $app = "c:\\program files\\aim\\aim.exe";
my $args = "";
my $dir = ".";
my $exit_code;
Now, let's go ahead and create our process...
if (Win32::Process::Create($proc,$app,$args,0,NORMAL_PRIORITY_CLASS,$dir)) {
print "Process created.\n";
# Get PID
my $pid = $proc->GetProcessID();
print "Process $pid created.\n";
Now that we've created our process, let's let it run for a bit (in this case, 3 seconds), then suspend the process. What we're doing, for testing purposes is running this loop only 10 times. This can be expanded (and the Wait() time changed, as well), or an entirely different loop structure can be used.
foreach (1..10) {
$proc->Wait(3000);
$proc->Suspend();
print "Process suspended.\n";
Now that the process has been suspended, we can go ahead and do things like dump process memory (with pmdump.exe), or run tools like handle.exe, listdlls.exe, etc.
sleep(3);
Once we're done, go ahead and resume the process...
$proc->Resume();
print "Process resumed.\n";
}
}
Now, just a little error checking...
else {
print "Process creation failed: ".Win32::FormatMessage Win32::GetLastError()."\n";
exit(1);
}
So, once this script has completed, you can conduct your analysis. For memory dumps, run strings.exe against the files, or use scripts to extract email or IP addresses, etc.
Addedum: In responding to some comments this morning, I thought that something I said should be included in the text of the post itself.
What I've presented above is not meant to replace anything. Rather, it's a tool...nothing more. Like any tool, it's effectiveness depends upon how you use it. One possible scenario for the use of this tool would be where an administrator or analyst has an unknown bit of software (we won't call it malware yet b/c we don't know). When looking at the program with a hex editor (part of performing static analysis), the analyst may believe that the program is encrypted or obfuscated in some manner. Now, most admins/analysts don't have tools like IDAPro at their disposal, and don't have the necessary skill sets to use things like debuggers and disassemblers. So, moving on to dynamic analysis, they want to run the program on a "sacrificial lamb" system to see what it does. Loading up monitoring tools, the analyst may want to run the application in a more controlled fashion, dumping memory contents along the way.
The above script will let you do that. Admittedly, the script itself is raw, and in it's early stages...but the basic idea is there. The great thing about scripts like this is that they can be easily expanded. For example, let's say we replace sleep(3) the necessary command to run pmdump.exe. When the above script ends, you'll have a directory with a bunch of memory dump files. Well, at that point, the script can then:
- Hash each of the files (using Jesse's tools)
- Run strings.exe against each file
- Grep() through each file looking for email or IP addresses, keywords, etc.
- Run 'diff' between all of the files to see what changed between snapshots
- Save the results to a flat file, a spreadsheet, or a database for analysis
To me, it's all kinda cool! Something like this would have been kind of interesting when I was using netcat to demonstrate Locard's Exchange Principle.
Tuesday, August 02, 2005
iPod info
I was doing my monthly check of the e-Evidence.info site this morning, and I ran across an interesting article on how iPods are used as hard drives. So I plugged an iPod into my Windows box and fired up UVCView, and pulled the serial number from the device...in this case, "0000008A0136".
From there, I went to the Registry and navigated to the HKLM\System\CurrentControlSet\Enum Registry key, then dropped down and opened up the USBStor subkey. There, I found the device ID I was looking for...Disk&Ven_Apple&Prod_iPod&Rev_1.62. Beneath this subkey, I found the instance ID that contained the serial number of the device; "0000008A0136&0". From there, I mapped the ParentIdPrefix value to the corresponding value under HKLM\System\MountedDevices and located the drive letter that the device had been mapped to; in my case, \DosDevices\G:.
So what does this all mean? If you're looking around for who's been using iPods at work, you know which key to check. If you're performing a forensic investigation, you should check under the ControlSet00x key, rather than the CurrentControlSet key.
From there, I went to the Registry and navigated to the HKLM\System\CurrentControlSet\Enum Registry key, then dropped down and opened up the USBStor subkey. There, I found the device ID I was looking for...Disk&Ven_Apple&Prod_iPod&Rev_1.62. Beneath this subkey, I found the instance ID that contained the serial number of the device; "0000008A0136&0". From there, I mapped the ParentIdPrefix value to the corresponding value under HKLM\System\MountedDevices and located the drive letter that the device had been mapped to; in my case, \DosDevices\G:.
So what does this all mean? If you're looking around for who's been using iPods at work, you know which key to check. If you're performing a forensic investigation, you should check under the ControlSet00x key, rather than the CurrentControlSet key.
Monday, August 01, 2005
Training Poll
A while ago, I posted about a training course based on my book. Since then, I've received emails from folks, asking about when such a course would be available near them, so I thought I'd post here and see what folks are interested in...
When I taught my Windows 2000 Incident Response course, I would generally go on-site and teach approximately 20 folks at a time, for two days. In some cases, attendees would ask me to come on-site to their location, and provide specialized content, based on the needs of their particular group. This sort of set-up (ie, having me come on-site) worked out really well for the folks who took advantage of it, because they saved a ton of money. Having me come on-site for two days to teach a dozen (most cases were closer to 20) folks the material was less expensive than sending 3 people off to other training courses (that shall remain nameless). Also, they didn't have to deal with processing travel claims for all those folks...and the material that I presented could be...and was...used immediately.
However, this kind of set up does not work for everyone. Not everyone can provide 8, 10, or more folks at one time, in one location, for two days. Some folks would be happier going off-site for three or four days. And still others would be happier doing it all online.
So, here're my questions to you, dear reader...
1. Would you be interested in a training course (2-3 days), based on my book? The material would be technical, with a lot of hands-on work, includes labs/exercises.
2. If you would be interested in such a course, what information, specifically, would you be interested in? My data hiding presentation has always been popular, but my "Windows Registry as a forensic resource" can be a bit out of reach for some folks. What type of content would you like to see, specifically? Would you be more incident response oriented?
3. What type of setting/forum would you like to see? Would you prefer to have me come on-site, or would you like to go somewhere off-site? If you're more interested in an web-based approach, can you point me toward some services?
Thanks. Feel free to post a comment (please sign it) or email me...
When I taught my Windows 2000 Incident Response course, I would generally go on-site and teach approximately 20 folks at a time, for two days. In some cases, attendees would ask me to come on-site to their location, and provide specialized content, based on the needs of their particular group. This sort of set-up (ie, having me come on-site) worked out really well for the folks who took advantage of it, because they saved a ton of money. Having me come on-site for two days to teach a dozen (most cases were closer to 20) folks the material was less expensive than sending 3 people off to other training courses (that shall remain nameless). Also, they didn't have to deal with processing travel claims for all those folks...and the material that I presented could be...and was...used immediately.
However, this kind of set up does not work for everyone. Not everyone can provide 8, 10, or more folks at one time, in one location, for two days. Some folks would be happier going off-site for three or four days. And still others would be happier doing it all online.
So, here're my questions to you, dear reader...
1. Would you be interested in a training course (2-3 days), based on my book? The material would be technical, with a lot of hands-on work, includes labs/exercises.
2. If you would be interested in such a course, what information, specifically, would you be interested in? My data hiding presentation has always been popular, but my "Windows Registry as a forensic resource" can be a bit out of reach for some folks. What type of content would you like to see, specifically? Would you be more incident response oriented?
3. What type of setting/forum would you like to see? Would you prefer to have me come on-site, or would you like to go somewhere off-site? If you're more interested in an web-based approach, can you point me toward some services?
Thanks. Feel free to post a comment (please sign it) or email me...
Thursday, July 21, 2005
A/V software on web servers, revisited
The subject thread I've been following and contributing to has proved to be interesting, to say the least, and the most interesting aspects have little to do with the subject...
First off, I guess I really shouldn't be surprised how many respondants go almost immediately off-topic, without bothering to change the subject line. Bad etiquette, guys, but I guess that's to be expected.
I want to take a second or two so summarize some of the most popular responses I've seen in watching this thread, and comment on them...
There's a lot of talk about "protecting against currently unknown exploits"...and I have to ask, if it's unknown, how do you protect against it and how do you know A/V will help you? Really. One example came up of a new exploit in which the bad guy took control of the system and dropped an already-known rootkit (ie, HackerDefender, etc.) on the system...in such a case, A/V would work. Yes, and you'd be very lucky, b/c the bad guy was very stupid. If the bad guy gained such access, why would he not bother to disable or even uninstall the A/V first? Or roll back the .dat file? Or why use something that's old? If he's using a zero-day exploit, why would he then use an old rootkit?
There have been mentions of Code Red, SQL Spida, and SQL Slammer. To me, it's odd that someone would use those examples and say, "I've seen A/V come to the rescue with these viruses", when the infections could have been easily prevented in the first place with configuration settings. With Code Red, all the IIS admin had to do was disable the .ida/.idq script mappings...something not many folks used anyway. With SQL Spida, all the SQL admin had to do was put a password on the 'sa' account. Need I say it? Duh!
Another biggy is that A/V protects against the things that have been missed, the things that haven't been done. Good point, but I would suggest that perhaps the security process itself needs to revisited. If something wasn't done, why was that? Was it part of the process and the setting wasn't verified before putting the server into production? Or had it been changed? Yet again, A/V software is justified...but as a band-aid approach.
There have been respondants who are in positions where the web servers are administered by multiple folks, and perhaps even developers have admin access to the servers, for adding updates. This falls right into the same category as malware that gains SYSTEM level access...A/V isn't going to help, b/c at that point, it's GAME OVER, guys! Someone with that level of access can simply disable your A/V software.
So...am I being arrogant? I don't think so. I've managed IIS 4.0/5.0 web servers and watched the logs fill up with failed Code Red/Nimda attempts, etc. I've had NT 4.0 boxes (my own) connected to a DSL hookup with no firewall, and no A/V software...and the only time I've ever gotten a virus, worm, or rootkit on my system is when I put it there myself.
Am I saying that A/V software shouldn't be used? Not at all...I think like every tool, it has it's place. However, I do think that if a web server admin is doing their job, then it's not necessary to put A/V software on a web server. That was the original question I responded to.
First off, I guess I really shouldn't be surprised how many respondants go almost immediately off-topic, without bothering to change the subject line. Bad etiquette, guys, but I guess that's to be expected.
I want to take a second or two so summarize some of the most popular responses I've seen in watching this thread, and comment on them...
There's a lot of talk about "protecting against currently unknown exploits"...and I have to ask, if it's unknown, how do you protect against it and how do you know A/V will help you? Really. One example came up of a new exploit in which the bad guy took control of the system and dropped an already-known rootkit (ie, HackerDefender, etc.) on the system...in such a case, A/V would work. Yes, and you'd be very lucky, b/c the bad guy was very stupid. If the bad guy gained such access, why would he not bother to disable or even uninstall the A/V first? Or roll back the .dat file? Or why use something that's old? If he's using a zero-day exploit, why would he then use an old rootkit?
There have been mentions of Code Red, SQL Spida, and SQL Slammer. To me, it's odd that someone would use those examples and say, "I've seen A/V come to the rescue with these viruses", when the infections could have been easily prevented in the first place with configuration settings. With Code Red, all the IIS admin had to do was disable the .ida/.idq script mappings...something not many folks used anyway. With SQL Spida, all the SQL admin had to do was put a password on the 'sa' account. Need I say it? Duh!
Another biggy is that A/V protects against the things that have been missed, the things that haven't been done. Good point, but I would suggest that perhaps the security process itself needs to revisited. If something wasn't done, why was that? Was it part of the process and the setting wasn't verified before putting the server into production? Or had it been changed? Yet again, A/V software is justified...but as a band-aid approach.
There have been respondants who are in positions where the web servers are administered by multiple folks, and perhaps even developers have admin access to the servers, for adding updates. This falls right into the same category as malware that gains SYSTEM level access...A/V isn't going to help, b/c at that point, it's GAME OVER, guys! Someone with that level of access can simply disable your A/V software.
So...am I being arrogant? I don't think so. I've managed IIS 4.0/5.0 web servers and watched the logs fill up with failed Code Red/Nimda attempts, etc. I've had NT 4.0 boxes (my own) connected to a DSL hookup with no firewall, and no A/V software...and the only time I've ever gotten a virus, worm, or rootkit on my system is when I put it there myself.
Am I saying that A/V software shouldn't be used? Not at all...I think like every tool, it has it's place. However, I do think that if a web server admin is doing their job, then it's not necessary to put A/V software on a web server. That was the original question I responded to.
Training
I recently had someone contact me, someone who had read my book and wanted to see about attending my course. Well, one way to do that would be to sign up at MegaMind.org (note: the course actually covers much more than just Window2000). Another way to do it is to have me come on-site and teach it at your facility.
This person suggested that I contact Amazon for a list of names of people who are interested in the training, but to my knowledge, Amazon doesn't maintain anything like that.
So I thought I would pose the question via the blog and see what kind of response I got...so, here it is...
If you're interested in incident response training specific to Windows systems, what sort of program do you prefer? Would you prefer traveling to another location to take the course, or having me come to your facility and teach it? How about the material? The course is specific to incident detection, verification, and resolution on live systems...but I have tailored it to the specific needs of the certain organizations (i.e., I've extended the 2-day course to 5 days, added or removed material as needed, etc.).
How about forensic analysis of Windows systems? As I've already started working on another book along those lines, I can easily see the necessary material for a detailed, hands-on course coming together.
So...what are your thoughts, preferences, comments?
This person suggested that I contact Amazon for a list of names of people who are interested in the training, but to my knowledge, Amazon doesn't maintain anything like that.
So I thought I would pose the question via the blog and see what kind of response I got...so, here it is...
If you're interested in incident response training specific to Windows systems, what sort of program do you prefer? Would you prefer traveling to another location to take the course, or having me come to your facility and teach it? How about the material? The course is specific to incident detection, verification, and resolution on live systems...but I have tailored it to the specific needs of the certain organizations (i.e., I've extended the 2-day course to 5 days, added or removed material as needed, etc.).
How about forensic analysis of Windows systems? As I've already started working on another book along those lines, I can easily see the necessary material for a detailed, hands-on course coming together.
So...what are your thoughts, preferences, comments?
Tuesday, July 19, 2005
A/V software on web servers
There's an interesting thread over on the SecurityFocus Focus-MS list, regarding the installation of anti-virus software on IIS 6.x web servers. I attempted to ignore it, but this morning felt the need to interject.
In a nutshell, my point has simply been that if a web server is just that...a web server...then for the most part, it's serving up content via port 80 (and possibly port 443). If the system is properly configured, why then is anti-virus software needed? If it's just a web server, and your LAN/infrastructure is properly configured and administered, what is the purpose of adding yet another software package to a system, that's going to generate yet another set of logs that will be ignored?
One post mentioned the fact that you can't possibly know all of the threats you'll face. Well, that's true...if you've got your head stuck in the sand. Remote attacks come down to two basic types...those that exploit poor configurations (ie, weak passwords, running unnecessary services, etc.), and those that exploit improper bounds checking in the software itself (ie, buffer overflows). Understanding this makes it easier to reduce the attack surface by greatly restricting the avenues available to an attacker. In fact, it is possible to reduce the attack surface to the point where you still have your necessary functionality, but pretty much the only way to compromise the system is to be the administrator sitting at the console...and at that point, no amount of anti-virus software is going to do you any good.
Another post mentioned that the web server is the public interface to the rest of the world, and anything that gets on the LAN can make it over to the web server, and you may possibly end up with an embarrassing situation (ie, defacement, malware proliferation, etc.). This may be the case...if you've got your web server installed on the same LAN segment as your employee desktops. However, the most likely avenue of attack at that point would be via NetBEUI/file sharing, and it that's enabled on your web server, then it's no longer just a web server, is it?
Take a look at some of the stuff that's hit the Internet. Remember Code Red? Well, some folks at MS set up an IIS 4.0 web server, and it was not susceptible to Code Red a full year before Code Red was launched. In fact, if everyone had simply disabled the proper script mapping the day before Code Red came out, they would not have been vulnerable.
If you're considering putting anti-virus software on a web server, I'd suggest that you look at the root cause as to why you want to do that. Perhaps a better investment would be in training of your staff (ie, support staff, as well as management), or in another product all together.
Am I saying that web servers should never have A/V installed? No, not at all...what I am saying is that before doing so, you should take a hard look at the reasons why you're doing so. Sometimes just setting some ACLs and removing unnecessary services will go a lot further than installing another software package that needs to be maintained.
As a side note, it seems to me that a lot of folks out there are of the mind, "if you're running Windows, you must have anti-virus installed." To me, this seems to be a very uneducated and misinformed position. I do not use A/V software on any of my personal systems, and have never been infected when I haven't done so intentionally. At work, there are no log entries from the corporate A/V software to indicate an infection of any kind on my workstation. Sure, if your kids are using a home system, you'd want to have anti-virus software installed, but that applies regardless of the platform.
Addendum: I was checking out Bruce Schneier's blog this morning and noticed something that rang true with this blog entry. Specifically, in one of his entries about turning off cell phones in tunnels, Bruce says, "This is as idiotic as it gets. It's a perfect example of what I call "movie plot security": imagining a particular scenario rather than focusing on the broad threats." Wow. Bruce gets lauded as a security expert when he says things like that (and I happen to think he's right). However, when I say something like, "There's no point in installing A/V software on a web server", which is pretty much along the same lines as what Bruce said, only mapped to the digital world, I end up getting emails that are better not quoted in public.
Most known threats can be protected against without the use of A/V software on web servers. New threats won't be caught because they're new, and not yet subject to scrutiny by the A/V community.
Oh, and one other thing...more than one person sent me email telling me that they "saw" A/V software protect systems from being infected with the SQLSpida worm. All I can say is, thanks guys, but you made my point for me.
In a nutshell, my point has simply been that if a web server is just that...a web server...then for the most part, it's serving up content via port 80 (and possibly port 443). If the system is properly configured, why then is anti-virus software needed? If it's just a web server, and your LAN/infrastructure is properly configured and administered, what is the purpose of adding yet another software package to a system, that's going to generate yet another set of logs that will be ignored?
One post mentioned the fact that you can't possibly know all of the threats you'll face. Well, that's true...if you've got your head stuck in the sand. Remote attacks come down to two basic types...those that exploit poor configurations (ie, weak passwords, running unnecessary services, etc.), and those that exploit improper bounds checking in the software itself (ie, buffer overflows). Understanding this makes it easier to reduce the attack surface by greatly restricting the avenues available to an attacker. In fact, it is possible to reduce the attack surface to the point where you still have your necessary functionality, but pretty much the only way to compromise the system is to be the administrator sitting at the console...and at that point, no amount of anti-virus software is going to do you any good.
Another post mentioned that the web server is the public interface to the rest of the world, and anything that gets on the LAN can make it over to the web server, and you may possibly end up with an embarrassing situation (ie, defacement, malware proliferation, etc.). This may be the case...if you've got your web server installed on the same LAN segment as your employee desktops. However, the most likely avenue of attack at that point would be via NetBEUI/file sharing, and it that's enabled on your web server, then it's no longer just a web server, is it?
Take a look at some of the stuff that's hit the Internet. Remember Code Red? Well, some folks at MS set up an IIS 4.0 web server, and it was not susceptible to Code Red a full year before Code Red was launched. In fact, if everyone had simply disabled the proper script mapping the day before Code Red came out, they would not have been vulnerable.
If you're considering putting anti-virus software on a web server, I'd suggest that you look at the root cause as to why you want to do that. Perhaps a better investment would be in training of your staff (ie, support staff, as well as management), or in another product all together.
Am I saying that web servers should never have A/V installed? No, not at all...what I am saying is that before doing so, you should take a hard look at the reasons why you're doing so. Sometimes just setting some ACLs and removing unnecessary services will go a lot further than installing another software package that needs to be maintained.
As a side note, it seems to me that a lot of folks out there are of the mind, "if you're running Windows, you must have anti-virus installed." To me, this seems to be a very uneducated and misinformed position. I do not use A/V software on any of my personal systems, and have never been infected when I haven't done so intentionally. At work, there are no log entries from the corporate A/V software to indicate an infection of any kind on my workstation. Sure, if your kids are using a home system, you'd want to have anti-virus software installed, but that applies regardless of the platform.
Addendum: I was checking out Bruce Schneier's blog this morning and noticed something that rang true with this blog entry. Specifically, in one of his entries about turning off cell phones in tunnels, Bruce says, "This is as idiotic as it gets. It's a perfect example of what I call "movie plot security": imagining a particular scenario rather than focusing on the broad threats." Wow. Bruce gets lauded as a security expert when he says things like that (and I happen to think he's right). However, when I say something like, "There's no point in installing A/V software on a web server", which is pretty much along the same lines as what Bruce said, only mapped to the digital world, I end up getting emails that are better not quoted in public.
Most known threats can be protected against without the use of A/V software on web servers. New threats won't be caught because they're new, and not yet subject to scrutiny by the A/V community.
Oh, and one other thing...more than one person sent me email telling me that they "saw" A/V software protect systems from being infected with the SQLSpida worm. All I can say is, thanks guys, but you made my point for me.
Monday, July 18, 2005
Bots writing Registry entries
As I've purused some of the anti-virus sites of late, I've noticed a trend that malware...specifically, bots...are writing two particular Registry entries:
[HKCUHKLM]\System\CurrentControlSet\Control\Lsa
and
[HKCUHKLM]\Software\Microsoft\OLE
I'm seeing this with several bots...W32.Bropia, W32.MyTob, etc. Some A/V sites point out that these are variations of SD-Bot, which wrote to the keys, as well...but why? A/V companies do a great job of saying which keys get created or modified, but it's tough to figure out *why*.
What's the purpose for writing to these keys? Does it have something to do with the LSASS vulnerality in MS04-011? Is this another autostart location?
[HKCUHKLM]\System\CurrentControlSet\Control\Lsa
and
[HKCUHKLM]\Software\Microsoft\OLE
I'm seeing this with several bots...W32.Bropia, W32.MyTob, etc. Some A/V sites point out that these are variations of SD-Bot, which wrote to the keys, as well...but why? A/V companies do a great job of saying which keys get created or modified, but it's tough to figure out *why*.
What's the purpose for writing to these keys? Does it have something to do with the LSASS vulnerality in MS04-011? Is this another autostart location?
Subscribe to:
Posts (Atom)