Shelia is an intrusion detection system for the client side. It comes with a client emulator that 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.
The fist release of Shelia for Windows was written by Joan Robert Rocaspana and assumes the presence of the Outlook Express mailreader. Later versions show modifications and extensions by Georgios Portokalidis, Philip Homburg, and Herbert Bos. They no longer need Outlook Express and handle both IMAP email and manual feeds of suspicious URLs and attachments (basically, everything that feeds the Shelia input DB is fine). Note: this is experimental software to deal with malicious code. Use at your own risk. Neither the authors, nor the Vrije Universiteit will accept liability for any damage caused by this software.
The main idea behind Shelia is that it emulates a naive user: someone who will follow all links and open all attachments in spam email, and clicks all links received via other means (say, instant messaging). Whenever Shelia detects a malicious website or attachment, it raises an alert.
What sets Shelia apart from most other client honeypots is the way in which it decides that something is malicious. Unlike most other systems, Shelia creates virtually no false positives (although there may be false negatives). Engrained in is design philosophy is that false positives are much more important than false negatives.
False positives are avoided by detecting intrusions not by looking at changes to the file system after visiting a website (a common way in such honeypots), but by tracking who calls the sensitive operations. More precisely, whenever a call is made to change the registry, the file system, or network activity, Shelia tracks whether the call is coming from an area that is not supposed to contain code. If so, it raises an alert.
The other design goal is that it should be easy to manage. For instance, it should be as trivial as sending email to have Shelia check certain links or attachments.
In recent months, the Shelia architecture has witnessed a major overhaul. as a result, the system is more stabile, more flexible and less tied to particular software of modes of operations. For instance, the previous version of Shelia required OutlookExpress and POP access to email. Neither are necessary in the current version. In this section we summarise the changes:
Shelia monitors the processes and generates alerts when the process attempts to execute an invalid 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. A precise description can be found in the documentation which is permanently in draft status. Shelia may even allow the attack to run until it downloads the malware, which is then captured and stored in a specific directory (not unlike the download of malware offered by projects like Nepenthes).
Examples of some of the information generated by Shelia can be found in the shelia/shelia/logs directory. In later versions, however, such data is stored in a much more structured way in a MySQL database.