Have you ever heard the saying "You never get a second chance to make a first impression"? The same applies to malware analysis, and information security in general.
This morning I was doing some research into some malicious spam emails that were coming in. They were your normal click-on-a-link-and-be-redirected-to-50-sites emails and I had tracked it down to the last site. After decoding the JS it gave out, I could see the attacks it was going to perform and the URLs it was going to go to. So close to the malicious executable...so close.
So I typed the followed at my prompt:
curl -D header.txt "http://badsite.com/welcome.php?id=12&pid=10&1=12"
See any problems?
Curl writes anything it downloads to standard output by default. In other words, since I didn't redirect the output to a file or use the -O option, the file from the malicious site was written to my screen. Normally, this wouldn't have been such a bad thing except it was gzip compressed, so my screen was filled with binary characters.
No problem, right? All I have to do is download it again, this time redirecting. Here's what happened:
curl -D header.txt "http://badsite.com/welcome.php?id=12&pid=10&1=12" > 1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 bytes downloaded? What happened?
Many web-based malicious toolkits used by attackers have an option to only allow the attack file to be downloaded once per IP address. This prevents multiple re-infections on clients and analysts (like me) from exploring their site. When I initially requested the file and didn't redirect the output, I used my one shot. The second time I went to download it, the site saw me and didn't let me access it again. Of course, there are ways around this, but thats for another post.
So, what did I take away from this?
1. Everyone makes mistakes. Hell, I make alot of them. If anyone tells you they don't, they're lying. Learn and move on.
2. I need better web download tools. Well, the tools (eg. curl) work fine. I'm flawed. I've already started to create a script that does all that needs done for me. No more mess ups.
I hope others can read this and learn from my mistake. I'd love to hear how others download malicious websites.
Monday, August 16, 2010
Friday, August 13, 2010
Introduction to Malware Analysis Course
Once again I will be teaching my Introduction to Malware Analysis course this year at the NE Ohio Information Security Summit that takes place on October 11-15, 2010 in Cleveland, Ohio. My course is in the pre-conference training and will take place on Oct 12-13.
The 2 day introduction to malware analysis class is geared to those who want to learn malware analysis or are just starting out. We'll cover all of the basics for malware analysis including setting up your analysis lab, static analysis and dynamic analysis. In the end, you'll walk out of the class with the knowledge of how to take a malware sample and determine what it does, who it contacts and what risk it poses.
The class is structured around labs where you'll use the techniques taught to analyse live malware. Since we will be analyzing actual malware, students will need to bring their own laptops (requirements will be posted closer to the class).
The end of the class will also feature an analysis contest where students will compete to win some cool prizes. Last year I gave away a copies of Hacker and Pandemic...so we'll see what happens this year!
Even if you don't take my course, I highly recommend attending the conference. Its an amazing conference for the price ($300 until 9/15). There are lots of great speakers (many of which speak at Black Hat, Defcon, Shmoocon, etc.).
Look forward to seeing you there!
The 2 day introduction to malware analysis class is geared to those who want to learn malware analysis or are just starting out. We'll cover all of the basics for malware analysis including setting up your analysis lab, static analysis and dynamic analysis. In the end, you'll walk out of the class with the knowledge of how to take a malware sample and determine what it does, who it contacts and what risk it poses.
The class is structured around labs where you'll use the techniques taught to analyse live malware. Since we will be analyzing actual malware, students will need to bring their own laptops (requirements will be posted closer to the class).
The end of the class will also feature an analysis contest where students will compete to win some cool prizes. Last year I gave away a copies of Hacker and Pandemic...so we'll see what happens this year!
Even if you don't take my course, I highly recommend attending the conference. Its an amazing conference for the price ($300 until 9/15). There are lots of great speakers (many of which speak at Black Hat, Defcon, Shmoocon, etc.).
Look forward to seeing you there!
Wednesday, May 12, 2010
Simulating the User Experience: Part 3
In the first two parts of this blog series, I detailed an issue I found where not all of the user environment variables were set for a program run with winexe. This was causing an issue during analysis of some malware since the samples were looking for those variables. As a work-around, a batch script was uploaded to the Windows sandbox and scheduled to run. When the scheduled job ran, all of the environment variables were set and the malware ran as it normally would.
The whole situation got me thinking - are public sandboxes setting all of the environment variables? As was seen, some malware rely on these variables and if they aren't set the malware won't run. If someone were to use a public sandnet to test malware that relies on these variables and the malware didn't run, they could be under the false impression that the program is benign.
Before I go on I should state that this post is not a knock against public sandboxes. They provide a great service to the security community. I did not do this to find any weaknesses in them to exploit or publish maliciously. My goal here was to determine which sandboxes, if any, miss some variables that may be required for malware to run.
To test this, I wrote a program that would obtain the environment variables and write each one to its own registry key/value pair. Since the public sandboxes report any registry modifications made by the program, I would be able to see all of the environment variables available to the program. This program was then uploaded to a number of different public sandboxes and the results analyzed. The sandboxes I used were Anubis, Comodo, CWSandbox, Joebox, ThreatExpert, BitBlaze and the Norman Sandbox.
In my testing, none of the sandboxes set all 30 of the environment variables I originally saw in my test. BitBlaze set 29; Anubis, Comodo, CWSandbox and Joebox set 28; and the Norman Sandbox only set 16. For some reason, ThreatExpert did not report anything back from my program - this could be a problem with my program or some type of security measure on their part.
* Note: I will not say which variables were and were not set. That information could be used by malware to determine it was running in one of these sandnets and that is not my purpose.
Due to the way the malware is executed in my system, I think that having only 28 or 29 environment variables is a perfectly normal variation. Therefore, my conclusion to all of this is that with the exception of Norman Sandbox, the sandnets appear to be setting the variables they should and represent a likely variation in the systems malware would run on.
As for Norman Sandbox, they are setting a small number of environment variables. This is perhaps a likely scenario for some systems. However, the variation of such a small amount being set would concern me as I don't know if all malware would work as it normally would. Only further testing can tell.
The whole situation got me thinking - are public sandboxes setting all of the environment variables? As was seen, some malware rely on these variables and if they aren't set the malware won't run. If someone were to use a public sandnet to test malware that relies on these variables and the malware didn't run, they could be under the false impression that the program is benign.
Before I go on I should state that this post is not a knock against public sandboxes. They provide a great service to the security community. I did not do this to find any weaknesses in them to exploit or publish maliciously. My goal here was to determine which sandboxes, if any, miss some variables that may be required for malware to run.
To test this, I wrote a program that would obtain the environment variables and write each one to its own registry key/value pair. Since the public sandboxes report any registry modifications made by the program, I would be able to see all of the environment variables available to the program. This program was then uploaded to a number of different public sandboxes and the results analyzed. The sandboxes I used were Anubis, Comodo, CWSandbox, Joebox, ThreatExpert, BitBlaze and the Norman Sandbox.
In my testing, none of the sandboxes set all 30 of the environment variables I originally saw in my test. BitBlaze set 29; Anubis, Comodo, CWSandbox and Joebox set 28; and the Norman Sandbox only set 16. For some reason, ThreatExpert did not report anything back from my program - this could be a problem with my program or some type of security measure on their part.
* Note: I will not say which variables were and were not set. That information could be used by malware to determine it was running in one of these sandnets and that is not my purpose.
Due to the way the malware is executed in my system, I think that having only 28 or 29 environment variables is a perfectly normal variation. Therefore, my conclusion to all of this is that with the exception of Norman Sandbox, the sandnets appear to be setting the variables they should and represent a likely variation in the systems malware would run on.
As for Norman Sandbox, they are setting a small number of environment variables. This is perhaps a likely scenario for some systems. However, the variation of such a small amount being set would concern me as I don't know if all malware would work as it normally would. Only further testing can tell.
Saturday, May 8, 2010
Simulating the User Experience: Part 2
In my last post I discussed the problem I found with winexe and how it did not set all the Windows environment variables needed to simulate a complete user experience. This problem was preventing some malware from running in my malware analysis sandnet - a problem I needed to overcome.
The way I looked at it, I had 3 options:
Using winexe to run 'cmd /c malware.exe' was out as this was the method I was using before. I then tried creating a batch script to run the malware and executing it with winexe. No luck there either; the environment variables weren't created. Finally, I had an idea...what if I scheduled a job to run the malware? If I scheduled it as the user it should inherit all of the correct variables and run correctly.
To test it out I created a batch script (named test.bat) in the Windows system that would run set and redirect the output into a file. I then ran the following command (from the Linux box):
Success!!! When the script ran and dumped the environment variables into a file, all 30 were there! The next step was to create a script to run the malware in the system.
The automation script was modified to upload the malware to the Windows box along with a batch script that performs the following commands:
Why delete the scheduled job? When scheduling the job, it is scheduled to run every minute. By deleting the scheduled job there's no worry the malware will run more than once. Why schedule it to run every minute? Call it paranoia. :)
After making the modifications to my automation script and testing it, I ran it with the Koobface sample that started all my problems and...success! The results showed the sample ran correctly, dropped the right files and set the right registry keys. Tests with additional malware have shown that its working correctly as well.
This test got me thinking...how do publicly available sandnets work? Are they setting the environment settings correctly? I'll discuss this in the part 3 of this post.
The way I looked at it, I had 3 options:
- Modify the source code for winexe to get it to work as I wanted. However, this was more than I wanted to do at this time. Maybe later.
- Use a program like webjob to provide another means to remotely execute the program. However, this would require me to modify the Windows analysis host which, for reasons I won't go into, is a huge PITA. Any solution that required me to modify the host was out for now.
- Figure out a way to remotely execute the malware on the Windows system using already present tools and still get the user environment I wanted.
Using winexe to run 'cmd /c malware.exe' was out as this was the method I was using before. I then tried creating a batch script to run the malware and executing it with winexe. No luck there either; the environment variables weren't created. Finally, I had an idea...what if I scheduled a job to run the malware? If I scheduled it as the user it should inherit all of the correct variables and run correctly.
To test it out I created a batch script (named test.bat) in the Windows system that would run set and redirect the output into a file. I then ran the following command (from the Linux box):
winexe -U administrator%mypass //192.168.1.5 'schtasks /create /tn testjob /tr c:\temp\test.bat /sc minute /mo 1 /ru administrator /rp mypass'
Success!!! When the script ran and dumped the environment variables into a file, all 30 were there! The next step was to create a script to run the malware in the system.
The automation script was modified to upload the malware to the Windows box along with a batch script that performs the following commands:
schtasks /delete /tn jobname /fThe automation script then schedules a job to run the uploaded script. When the scheduled job kicks off, the batch file runs. The batch file deletes the scheduled job and run the malware.
start c:\path\to\malware.exe
Why delete the scheduled job? When scheduling the job, it is scheduled to run every minute. By deleting the scheduled job there's no worry the malware will run more than once. Why schedule it to run every minute? Call it paranoia. :)
After making the modifications to my automation script and testing it, I ran it with the Koobface sample that started all my problems and...success! The results showed the sample ran correctly, dropped the right files and set the right registry keys. Tests with additional malware have shown that its working correctly as well.
This test got me thinking...how do publicly available sandnets work? Are they setting the environment settings correctly? I'll discuss this in the part 3 of this post.
Simulating the User Experience: Part 1
Part of malware analysis, especially automated malware analysis, is to simulate the user environment as closely as possible. After all, our goal is to determine how malware behaves when it is run by a user. For the last few months I've worked on an automated malware analysis system which I thought did just that.
Let me explain my automated analysis system. It is similar to the one I described in my Hakin9 articles last year. Basically I have a host system running Linux that executes an automation script. The automation script starts up a VM, launches some monitoring tools, uploads and executes the malware, records the results and performs cleanup. In all, it takes about 5-7 minutes per malware, depending on the settings I am running. So far it performed extremely well and cut my analysis time down dramatically.
Imagine my frustration this week when I ran a new Koobface sample in it only to find the malware didn't do anything. It would launch, perform some start-up operations, then exit. No registry modifications, no process injection, no network traffic. However, when I would manually launch it or run it through ThreatExpert, it would run fine.
In looking closer, I found out that the malware was trying to place a copy of itself in the %APPDATA% directory. Since %APPDATA% is an environment variable for the user, it should have been set - or so I thought.
I took a step back and started to examine the method I was using to execute the malware. My "host" system which executes the automation scripts runs Linux. In order to execute the malware in the Windows system, smbclient is used to upload the malware and winexe is used to execute it. After some thought, I came up with a theory that winexe was not setting all of the environment variables when it executed malware. I was right.
It turns out that in a default Windows XP SP3 system, 30 environment variables are set. With the way I was running winexe (--system --interactive=1), only 22 of the variables were set - %APPDATA%, %CLIENTNAME%, %HOMEDRIVE%, %HOMEPATH%, %LOGONSERVER%, %SESSIONNAME%, %USERDOMAIN% and %USERNAME% are missing.
To make sure it wasn't because of the way I was running winexe, I ran a number of tests. Each test consisted of running winexe with different settings. The command that was run was "cmd.exe /c set > outfile". To be fair, I also tested PsExec (from another Windows system). These are the results I found:
It turns out that no matter what options you use, winexe does not set the environment variables above. Note that I also ran winexe with the --runas option and got the same results. PsExec sets all of the environment variables, except when you specify it to run as SYSTEM. This makes sense as most of those variables are used to specify user settings and SYSTEM would not have those.
Obviously, winexe wasn't going to cut it any more because it wasn't setting a complete user environment which, in turn, was preventing malware from running. So, what to do? Winexe was my only way to remotely execute a program on a Windows system from a Linux system (without modifying the Windows system and installing other programs). To find out what I did, you'll have to stay tuned for part 2! :)
As a side note, if anyone knows of another program similar to winexe, please let me know. Also, if anyone knows of a way to get winexe to run correctly, I'd love to hear it.
Let me explain my automated analysis system. It is similar to the one I described in my Hakin9 articles last year. Basically I have a host system running Linux that executes an automation script. The automation script starts up a VM, launches some monitoring tools, uploads and executes the malware, records the results and performs cleanup. In all, it takes about 5-7 minutes per malware, depending on the settings I am running. So far it performed extremely well and cut my analysis time down dramatically.
Imagine my frustration this week when I ran a new Koobface sample in it only to find the malware didn't do anything. It would launch, perform some start-up operations, then exit. No registry modifications, no process injection, no network traffic. However, when I would manually launch it or run it through ThreatExpert, it would run fine.
In looking closer, I found out that the malware was trying to place a copy of itself in the %APPDATA% directory. Since %APPDATA% is an environment variable for the user, it should have been set - or so I thought.
I took a step back and started to examine the method I was using to execute the malware. My "host" system which executes the automation scripts runs Linux. In order to execute the malware in the Windows system, smbclient is used to upload the malware and winexe is used to execute it. After some thought, I came up with a theory that winexe was not setting all of the environment variables when it executed malware. I was right.
It turns out that in a default Windows XP SP3 system, 30 environment variables are set. With the way I was running winexe (--system --interactive=1), only 22 of the variables were set - %APPDATA%, %CLIENTNAME%, %HOMEDRIVE%, %HOMEPATH%, %LOGONSERVER%, %SESSIONNAME%, %USERDOMAIN% and %USERNAME% are missing.
To make sure it wasn't because of the way I was running winexe, I ran a number of tests. Each test consisted of running winexe with different settings. The command that was run was "cmd.exe /c set > outfile". To be fair, I also tested PsExec (from another Windows system). These are the results I found:
| winexe | |||
|---|---|---|---|
| no settings | interactive | interactive + system | |
| %APPDATA% | |||
| %CLIENTNAME% | |||
| %HOMEDRIVE% | |||
| %HOMEPATH% | |||
| %LOGONSERVER% | |||
| %SESSIONNAME% | |||
| %USERDOMAIN% | |||
| %USERNAME% | |||
| psexec | |||
|---|---|---|---|
| no settings | interactive | interactive + system | |
| %APPDATA% | X | X | |
| %CLIENTNAME% | X | X | |
| %HOMEDRIVE% | X | X | |
| %HOMEPATH% | X | X | |
| %LOGONSERVER% | X | X | |
| %SESSIONNAME% | X | X | |
| %USERDOMAIN% | X | X | |
| %USERNAME% | X | X | |
It turns out that no matter what options you use, winexe does not set the environment variables above. Note that I also ran winexe with the --runas option and got the same results. PsExec sets all of the environment variables, except when you specify it to run as SYSTEM. This makes sense as most of those variables are used to specify user settings and SYSTEM would not have those.
Obviously, winexe wasn't going to cut it any more because it wasn't setting a complete user environment which, in turn, was preventing malware from running. So, what to do? Winexe was my only way to remotely execute a program on a Windows system from a Linux system (without modifying the Windows system and installing other programs). To find out what I did, you'll have to stay tuned for part 2! :)
As a side note, if anyone knows of another program similar to winexe, please let me know. Also, if anyone knows of a way to get winexe to run correctly, I'd love to hear it.
Tuesday, April 27, 2010
/Launch Malicious PDF
Wow - I'm posting!! :)
Today I, and others around the Internet, received an email that stated:
Examining the PDF with Didier Steven's pdfid.py showed that there was an OpenAction in the PDF, but no JavaScript. Interesting. Using pdf-parser.py, the object pointed to by the OpenAction was examined:
This shows that the /Launch vulnerability/feature of PDFs is being used to drop a VB script and execute it. What is interesting is the VB script (named script.vbs) parses the original PDF for another VBS to run! A quick look at the PDF finds the other VBS:
(The image above has had code removed for brevity.)
The new VBS (named batscript.vbs) contains an executable broken up into its hex bytes. The script will write each byte out to a file named game.exe and then will execute it. After executing, it sleeps for 3 seconds then covers its tracks by deleting game.exe, batscript.vbs and script.vbs.
game.exe, meanwhile, will copy itself to c:\program files\microsoft common\svchost.exe and set itself up to run in the registry whenever explorer.exe runs.
While I know the /Launch vulnerability has been exploited recently, this is the first I've seen on a mass-email scale (but isn't the first ever). I'm sure we'll be seeing more of these as time goes on.
Today I, and others around the Internet, received an email that stated:
Subject: setting for your mailbox are changedThe email had a PDF attached to it. Given the number of malicious PDFs that have been seen lately, this was likely a bad thing.
SMTP and POP3 servers for YOUREMAILADDRHERE mailbox are
changed. Please carefully read the attached instructions
before updating settings.
Examining the PDF with Didier Steven's pdfid.py showed that there was an OpenAction in the PDF, but no JavaScript. Interesting. Using pdf-parser.py, the object pointed to by the OpenAction was examined:
This shows that the /Launch vulnerability/feature of PDFs is being used to drop a VB script and execute it. What is interesting is the VB script (named script.vbs) parses the original PDF for another VBS to run! A quick look at the PDF finds the other VBS:
(The image above has had code removed for brevity.)
The new VBS (named batscript.vbs) contains an executable broken up into its hex bytes. The script will write each byte out to a file named game.exe and then will execute it. After executing, it sleeps for 3 seconds then covers its tracks by deleting game.exe, batscript.vbs and script.vbs.
game.exe, meanwhile, will copy itself to c:\program files\microsoft common\svchost.exe and set itself up to run in the registry whenever explorer.exe runs.
While I know the /Launch vulnerability has been exploited recently, this is the first I've seen on a mass-email scale (but isn't the first ever). I'm sure we'll be seeing more of these as time goes on.
Sunday, January 31, 2010
Who are the APT targets?
I've been publicly quiet on the whole APT discussions as of late, with good reason. There are lots of blogs out there which share (and do not share) my opinion, so there is no need for me to chime into the myriad of voices out there.
However, an anonymous comment on one of the recent taosecurity posts brought up a point that I have not seen anyone else talk about. The comment stated:
If you read Mandiant's excellent report, you will see specific examples (mentioned in the comment above) which are documented APT targets. Yes, these are what you think of as nation-state attack targets.
However, I have personally seen the APT attack and compromise systems in networks which have no ties to that nation-state and you would not consider enemies of that nation-state (or any for that matter). In these cases, the organizations were small-medium sized companies whose systems were compromised in order to be used as command and control systems for the APT's backdoors.
Of course, there are those that will say that this is the same technique that all attackers use - compromise less secure systems and use them as a go-between to attack other systems. And I will 100% agree with them on that! But that re-enforces my point as well! No one is safe from attack from APT and therefore there should be no reason why organizations should not take every reasonable precaution to against these (or any) attackers and learn as much as they can.
Yes, there will be those companies that use the term APT as a marketing tool. Yes, there will be those who say this is a limited threat to some organizations (and to some extent I agree with that). But in the end, it is a real threat that exists and any organization that does not perform the due diligence to at least learn about the potential threat will be at a disadvantage when they do get attacked; maybe not by the APT but by the next threat.
However, an anonymous comment on one of the recent taosecurity posts brought up a point that I have not seen anyone else talk about. The comment stated:
Reading the Mandiant Report, we see:The part I'd like to focus on is the last statement. The APT problem is not only the problem of those seen as the enemy of certain nation states. It is the problem of everyone.
1.) Government
2.) Defense Contractors
3.) Fortune XXX acquiring a Chinese compnay
4.) A Law Firm involved in a Chinese civil litigation case
5.) A non-profit trying to spread "democracy and free enterprise in China" (maybe they could also do that in the USA).
Look, it doesn't take Arthur Conan Doyle to piece together the storyline here. This clearly isn't "everyone's problem". It's a problem for those that are seen as an enemy of certain nation-states.
If you read Mandiant's excellent report, you will see specific examples (mentioned in the comment above) which are documented APT targets. Yes, these are what you think of as nation-state attack targets.
However, I have personally seen the APT attack and compromise systems in networks which have no ties to that nation-state and you would not consider enemies of that nation-state (or any for that matter). In these cases, the organizations were small-medium sized companies whose systems were compromised in order to be used as command and control systems for the APT's backdoors.
Of course, there are those that will say that this is the same technique that all attackers use - compromise less secure systems and use them as a go-between to attack other systems. And I will 100% agree with them on that! But that re-enforces my point as well! No one is safe from attack from APT and therefore there should be no reason why organizations should not take every reasonable precaution to against these (or any) attackers and learn as much as they can.
Yes, there will be those companies that use the term APT as a marketing tool. Yes, there will be those who say this is a limited threat to some organizations (and to some extent I agree with that). But in the end, it is a real threat that exists and any organization that does not perform the due diligence to at least learn about the potential threat will be at a disadvantage when they do get attacked; maybe not by the APT but by the next threat.
Thursday, January 21, 2010
Funky Ivy
I was testing out some functionality with the Poison Ivy backdoor today when I grabbed this screenshot. Very psychedelic!
Tuesday, January 12, 2010
Malware Analysis in the Incident Response Process followup
I just finished giving my webcast of Malware Analysis in the Incident Response Process at brighttalk.com. A few questions came in after the presentation ended so I'll answer them here and hopefully those who asked will see it.
You indicated it is inevitable to get malware. What is the best prevention…having dedicated PCs for missions critical functions (e.g. online banking)?
I honestly believe that the best way to prevent getting malware on systems is to run users with reduced privileges. I have seen first hand where restricting what activities a user can do on their system (install software, etc) will significantly decrease the amount of malware compromises you have.
Of course, there are other options as well. A good defense in depth strategy will make it more difficult for malware to compromise your systems. Using up-to-date AV on the desktop and your email systems, restricting Internet access and requiring all web-traffic to go through filtering proxy servers will help.
Are there any books you would recommend for beginners to learn malware analysis?
There are lots of great books out there that I would recommend to anyone who wants to learn malware analysis. The following are just a few of the ones I've read.
Malware Forensics by Aquilina, Casey and Malin
The Art of Computer Virus Research and Defense by Peter Szor
Malware: Fighting Malicious Code by Skoudis and Zeltser
There are others, but these are a good start.
Can you post a recent example of an analysis?
Unfortunately, I do not have one. However, I recommend checking out the results from the 2008 Malware Challenge for some analysis reports. I will also try to post something in the next few weeks.
Thanks to those who listened to the webcast. If you have any other questions, feel free to post them in the comments or send me an email!
You indicated it is inevitable to get malware. What is the best prevention…having dedicated PCs for missions critical functions (e.g. online banking)?
I honestly believe that the best way to prevent getting malware on systems is to run users with reduced privileges. I have seen first hand where restricting what activities a user can do on their system (install software, etc) will significantly decrease the amount of malware compromises you have.
Of course, there are other options as well. A good defense in depth strategy will make it more difficult for malware to compromise your systems. Using up-to-date AV on the desktop and your email systems, restricting Internet access and requiring all web-traffic to go through filtering proxy servers will help.
Are there any books you would recommend for beginners to learn malware analysis?
There are lots of great books out there that I would recommend to anyone who wants to learn malware analysis. The following are just a few of the ones I've read.
Malware Forensics by Aquilina, Casey and Malin
The Art of Computer Virus Research and Defense by Peter Szor
Malware: Fighting Malicious Code by Skoudis and Zeltser
There are others, but these are a good start.
Can you post a recent example of an analysis?
Unfortunately, I do not have one. However, I recommend checking out the results from the 2008 Malware Challenge for some analysis reports. I will also try to post something in the next few weeks.
Thanks to those who listened to the webcast. If you have any other questions, feel free to post them in the comments or send me an email!
Friday, January 8, 2010
Malware Analysis in the Incident Response Process
Next week I'll be giving an online presentation at BrightTalk on Malware Analysis in the Incident Response Process. The description of the talk is:
To attend my talk, you can go to the following URL:
http://www.brighttalk.com/webcasts/7977/attend
Hope you can join!
Malware has become the primary vector of compromise within organisations. Due to this, it has become necessary for incident response teams to have the ability to perform in-house malware analysis. This presentation will discuss how malware analysis can benefit an organisation and what options are available.The talk is scheduled for next Tuesday, January 12 at 6PM EST and is part of their Intrusion Prevention Summit. The summit has alot of interesting talks all day, so I recommend checking it out.
To attend my talk, you can go to the following URL:
http://www.brighttalk.com/webcasts/7977/attend
Hope you can join!
Subscribe to:
Posts (Atom)