Examples:Spectorsoft eBlaster 5 (Keylogger)

From SpybotWiki
Revision as of 21:56, 28 June 2008 by PepiMK (talk | contribs) (first draft of a first demonstration)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page shows an example file in SBI file format for detecting the keylogger eBlaster by Spectorsoft. Please note that as a demo, this does not claim to be a perfect detection pattern, it's just something that shows how it was done.



We decided for a classic approach for testing easy things, since we're not dealing with a rootkit or very amibitious thing here:

  1. We decided on a name, something useful to do as an early step. In this case, we decided on Spectorsoftware.eBlaster.5 following our Malware naming guidelines.
  2. We prepared a virtual machine by resetting it to its default state.
  3. We ran InCtrl5 in free mode.
  4. We started an installer we knew would install this keylogger.
  5. After playing around with it a bit, we closed it to make sure any changes it would apply on exiting would apply as well.
  6. We ran InCtrl5 again and let it finish the log.

In a real world situation, we would test this multiple times on multiple samples, and with more advanced tools, to make sure there are no random aspects to the system changes a sample applies.


Writing the detection pattern is usually something we do outside of the infected virtual machine.

  1. We extracted the HTML report created by InCtrl5 from the virtual machine.
  2. We ran OpenSBI Edit Lite and created a new file Spectorsoft.sbi inside the <$PROGRAMFILES>\Spybot - Search & Destroy\Includes\ folder. You could call it any way you like, but it would be a good idea to not use any of the official filenames.
  3. In its File menu, we picked the option to import a InCtrl5 report, and selected the file from step 1.
  4. Now comes the most challenging part of this: going through the list of system changes and selecting all changes that have been part of keylogger, in contrast to those changes that belong to the Operating System doing regular stuff in the background (this is one reason where other tools like FileMon and RegMon are more helpful, since they show the causing application executable for each change).
  5. Once satisfied, a press of the OK button put a code construct into the editor itself. We now have to deal with a second challenging task, refining file pattern by for example choosing advanced file parameters (md5 might do fine here if we expect files to be static) for each File command.
  6. Finally, we noticed that many lines were still displayed with the yellow warning background color. Pressing F1 told us that the default descriptions chosen by the import were not perfect yet. A look at the Description Templates tab showed us which templates we could use.


Here's the code created in this short demonstration, taking less than an hour.

// info: OpenSBI example
// author: Patrick M. Kolla (PepiMK)
// date: 2008-05-23 (1.6)
// copyright: (c) 2008 Safer Networking Ltd. All rights reserved.
// count: 14

:: Spectorsoftware.eBlaster.5
// {Cat:Keylogger}{Cnt:1}
// {Det:patrick,2008-05-23}
RegyKey:"<$REG_BHO>",HKEY_LOCAL_MACHINE,"\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\","{93AA1CB6-383A-49EF-B197-D31B4D577B90}"

A few notes pointing at things that might be of interest here:

  • The first four lines define the detection of registry keys just by using their name. GUIDs, as used for CLSIDs, are usually very unique, but doing a search on our LASSH database might help to avoid false positives. Also, multiple test installations would either verify that these are static, are show how we would need to refine them by checking subvalues (as done in the fifth command).
  • All files are showing filesize and md5 parameters. While the first one has been retrieved from the log, the secone one has to be choosen by hand, e.g. by using FileAlyzer on these files. It's safer to do this in the sandbox environment than on the host.
  • The last line, showing a Directory command, shows some flow control. As the name of the folder itself might be regarded as unsafe, since it's too ambiguous, we did use setenv on a previous File command as a condition that is here tested by isenv, which means that unless the file described as svrxp.exe is detected, this one will be skipped.
  • For similar cases where there would be more than just one unsafe line, NoOp combined with isenv and skipcount might be worth a look.