Never Ending Security

It starts all here

Category Archives: Defensive Security

Vulnerability Scanners Simply Explained

What Is Vulnerability Scanners ?

According to wikipedia, “A vulnerability scanner is a computer program designed to assess computers, computer systems, networks or applications for weaknesses.
As always, according to me, “Vulnerability scanner is program which is designed to identify the mistakes of a system.”

How Vulnerability Scanner Works ?

The vulnerability scanner works in the same way the antivirus programs does. These scanners, first gather the basic information about the host(target), such as operating system and it’s version, ports and services and then select appropriate test modules.
These vulnerability scanners having a huge database of vulnerabilities and these should be continuously updated.Scheduled scans with these continuously updating scanners can maintain a good security health in the network or system.
Vulnerability scanners not only traces the vulnerabilities but also it fixes and sometimes suggests fix for vulnerability.

What Are The Top Vulnerability Scanners ?

  • IBM AppScan
  • Netsparker
  • Nessus
  • OpenVAS
  • Retina CS Community
  • CORE Impact Pro
  • Nexpose

What Are The Best Online Vulnerability Scanners ?

  • GamaSec
  • Acunetix
  • Websecurify
  • Qualys

5 Vulnerability Scanners

1. OWASP ZAP – Zed Attack Project
The Zed Attack Proxy Is an easy to use Integrated penetration testing tool for finding vulnerabilities in web applications.It is officially designed for security experts and also for developers and functional testers who are a newbie in penetration testing.ZAP can trace out vulnerabilities automatically and manually.
So Download ZAP now.
For windows :ZAP For Windows
For Linux.     :ZAP For Linux
For Mac        :ZAP For Mac
2. Burp Suite
Burp Suite is a collection of tools for web application security testing. It includes a scanner tool for discovering vulnerabilities automatically. It also supports semi automated penetration testing.The burp suite helps to work more faster and effective.
Download Burp Suite
3. OWASP Xenotix XSS Exploit Framework 
OWASP Xenotix XSS Exploit Framework is an advanced Cross Site Scripting vulnerability detection and exploitation framework.It provides Zero False Positive scan results with its unique Triple Browser Engine (Trident, WebKit, and Gecko) embedded scanner.
It is claimed to have the world’s 2nd largest XSS Payloads of about 1600+ distinctive XSS Payloads for effective XSS vulnerability detection and WAF Bypass. Xenotix Scripting Engine allows you to create custom test cases and addons over the Xenotix API. It is incorporated with a feature rich Information Gathering module for target Reconnaissance.
The Exploit Framework includes offensive XSS exploitation modules for Penetration Testing and Proof of Concept creation.
Download OWASP Xenotix
4. Nessus
Nessus is a free to use open source powerful vulnerability scanner.Unlike other scanners, the plugins( vulnerability definitions) are also free.It provides lot’s of features like,
  • Client/server can be anywhere on the network.
  • Client/server uses SSL to protect scan results.And lot’s more !
5. Retina Core Impact
Retina Community gives you powerful vulnerability management across your entire environment.
For up to 256 IPs free, Retina Community identifies network vulnerabilities(including zero-day), configuration issues, and missing patches across operating systems, applications, devices, and virtual environments.

SQLassie – A database Firewall That Detects And Prevents SQL Injection Attacks At Runtime


SQLassie is a database firewall that detects and prevents SQL injection attacks at runtime.


SQLassie currently only supports MySQL. To start SQLassie, you’ll need to configure how SQLassie connects to the MySQL server, start SQLassie listening on a different port that is now protected, and then configure your applications to connect through this alternate port instead of directly to MySQL.

As an example, consider a scenario where you have a MySQL database engine running and listening for connections on the domain socket /var/run/mysql/mysqld.sock and are running a MediaWiki installation.

First, start SQLassie using

./sqlassie -s /var/run/mysql/mysqld.sock -l 3307

Then, edit MediaWiki’s configuration file LocalSettings.php connect to port 3307.

$wgDBServer = ""

Note that you can’t use localhost here; by default, MySQL interprets localhost as a request to use the direct database domain socket connection, and most web applications behave this way as well. Therefore, you have to use the explicit string in order to force connections to go through the TCP port. Check your application’s documentation for more information.


Now that you’ve gotten everything up and running, check to see if your web application still loads. If it does, you can check to see if SQLassie is correctly filtering attacks against your database. Bring up a terminal and run

mysql -u <user> -p -h -P 3307 -C

to connect to the database through SQLassie.

We can run a number of tests here. First, SQLassie will block most error messages that are produced by MySQL, because this information can be valuable to hackers. Start by running


Normally, MYSQL would respond with an error about no database being selected, but SQLassie intercepts the query and instead responds with Empty set. In this case, SQLassie recognized that the query was a SELECT query, and rather than give an error, it simply provided a response that made sense based on the query type.

Next, try running

SELECT first_name, last_name, age FROM user WHERE id = 1323 UNION SELECT User, Password, 1 FROM mysql.user;

SQLassie identifies this query as containing a schema discovery attack and blocks the query, responding with a fake empty Empty set message.


SQLassie comes with two Makefiles: one meant for use with gcc, and one meant for use with clang++. Support for gcc is more thorough at this time, so to start building, change into the source directory

cd src

and link to the gcc Makefile by running

ln -s Makefile.gcc Makefile

Next, you’ll need to install some dependencies. On a Debian-based system, you should get everything you need by running

apt-get install make g++ bison flex libboost-regex-dev libboost-thread-dev libboost-program-options-dev libboost-test-dev libboost-filesystem-dev libmysqlclient-dev

Finally, compile by running


The resulting binaries will be placed in the bin directory.

More information can be found at: and at:

MozDef – The Mozilla Defense Platform

MozDef: The Mozilla Defense Platform


The inspiration for MozDef comes from the large arsenal of tools available to attackers. Suites like metasploit, armitage, lair, dradis and others are readily available to help attackers coordinate, share intelligence and finely tune their attacks in real time. Defenders are usually limited to wikis, ticketing systems and manual tracking databases attached to the end of a Security Information Event Management (SIEM) system.

The Mozilla Defense Platform (MozDef) seeks to automate the security incident handling process and facilitate the real-time activities of incident handlers.


  • Provide a platform for use by defenders to rapidly discover and respond to security incidents.
  • Automate interfaces to other systems like bunker, banhammer, mig
  • Provide metrics for security events and incidents
  • Facilitate real-time collaboration amongst incident handlers
  • Facilitate repeatable, predictable processes for incident handling
  • Go beyond traditional SIEM systems in automating incident handling, information sharing, workflow, metrics and response automation


MozDef is in production at Mozilla where we are using it to process over 300 million events per day.


More Information can be found on:

BIOS Based Rootkits

BIOS Based Rootkits

This reasearch is published for purely educational purposes and it is a work of [ and not CyberPunk in any way ]. Many TnX and all the credit goes to them. Please take your time and visit their page and support the researchers. Make sure you check it out


Currently there is a very limited amount of sample code available for the creation of BIOS rootkits, with the only publicly available code being released along with the initial BIOS rootkit demonstration in March of 2009 (as far as I’m aware). My first goal was to reproduce the findings made by Core Security in 2009, and then my second task was to investigate how I could extend their findings. My ultimate goal was to create some sort of BIOS based rootkit which could easily be deployed.

In 2009 there was research done into a similar area of security, which is boot sector based rootkits. Unlike BIOS based rootkits, developments in this area have progressed rapidly, which has led to a number of different master boot record (MBR) based rootkits being developed and released. This type of rootkit was termed a “Bootkit”, and similar to a BIOS based rootkit it aims to load itself before the OS is loaded. This similarity led a number of bootkit developers to remark that it should be possible to perform this type of attack directly from the BIOS instead of loading from the MBR. Despite the comments and suggestions that this bootkit code could be moved into the BIOS for execution, there has not yet been any examples of such code made public.

The first stage for completing this project was to set up a test and development environment where BIOS modifications could be made and debugged. In their paper on Persistent BIOS Infection, Sacco and Ortega detail how they discovered that VMware contains a BIOS rom as well as a GDB server which can be used for debugging applications starting from the BIOS itself. After getting everything going successfully in VMware, work was done to port the VMware BIOS modifications to other similar BIOS’s, and will be described in the second half of this write-up.

VMware BIOS Configuration

Ok, enough background, onto the actually doing it!

The first step which is required is to extract the BIOS from VMware itself. In Windows, this can be done by opening the vmware-vmx.exe executable with any resource extractor, such as Resource Hacker. There are a number of different binary resources bundled into this application, and the BIOS is stored in resource ID 6006 (at least in VMware 7). In other versions this may be different, but the key thing to look for is the resource file that is 512kb in size. The following image shows what this looks like in Resource Hacker:


While this BIOS image is bundled into the vmware-vmx.exe application, it is also possible to use it separately, without the need to modify into the vmware executable after each change. VMware allows for a number of “hidden” options to be specified in an image’s VMX settings file. At some point I plan to document a bunch of them on the Tools page of this website, because some really are quite useful! The ones which are useful for BIOS modifications and debugging are the following:

bios440.filename = "BIOS.ROM"
debugStub.listen.guest32 = "TRUE"
debugStub.hideBreakpoint = "TRUE"
monitor.debugOnStartGuest32 = "TRUE"

The first setting allows for the BIOS rom to be loaded from a file instead of the vmware-vmx application directly. The following two lines enable the built in GDB server. This server listens for connections on port 8832 whenever the image is running. The last line instructs VMware to halt code execution at the first line of the guest image’s BIOS. This is very useful as it allows breakpoints to be defined and memory to be examined before any BIOS execution takes place. Testing was done using IDA Pro as the GDB client, and an example of the VMware guest image halted at the first BIOS instruction can be seen in the screenshot below:


When initially using this test environment, there were significant issues with IDA’s connection to the GDB server. After much trial and error and testing with different GDB clients, it was determined that the version of VMware was to blame. Version 6 and 6.5 do not appear to work very well with IDA, so version VMware version 7 was used for the majority of the testing. The BIOS is comprised of 16 bit code, and not the 32 bit code that IDA defaults to, so defining “Manual Memory Regions” in the debugging options of IDA was necessary. This allowed memory addresses to be defined as 16 bit code so that they would decompile properly.

Recreating Past Results – VMware BIOS Modification

As noted already, Sacco & Ortega have done two presentations on BIOS modification, and Wojtczuk & Tereshkin have also done a presentation regarding BIOS modification. Of these three presentations, only Sacco & Ortega included any source or sample code which demonstrated their described techniques. Since this was the only existing example available, it was used as the starting point for this BIOS based rootkits project.

The paper by Sacco & Ortega is fairly comprehensive in describing their set up and testing techniques. The VMware setup was completed as described above, and the next step was to implement the BIOS modification code which they had provided. The code provided required the BIOS rom to be extracted into individual modules. The BIOS rom included with VMware is a Phoenix BIOS. Research showed that there were two main tools for working with this type of BIOS, an open source tool called “phxdeco”, and a commercial tool called “Phoenix BIOS Editor”, which is provided directly by Phoenix. The paper by Sacco & Ortega recommended the use of the Phoenix BIOS Editor application and they had designed their code to make use of it. A trial version was downloaded from the internet and it appears to have all of the functionality necessary for this project. Looking for a download link again I can’t find anything that seems even half legitimate, but Google does come up with all kinds of links. I’ll just assume that it should be fairly easy to track down some sort of legitimate trial version still. Once the tools are installed, the next step is to build a custom BIOS.

I first tested that a minor modification to the BIOS image would take effect in VMware, which it did (changed the VMware logo colour). Next, I ran the Python build script provided by Sacco & Ortega for the BIOS modification. Aside from one typo in the Python BIOS assembly script everything worked great and a new BIOS was saved to disk. Loading this BIOS in VMware however did not result in the same level of success, with VMware displaying a message that something had gone horribly wrong in the virtual machine and it was being shut down. Debugging of this issue was done in IDA and GDB, but the problem was difficult to trace (plus there were version issues with IDA). In an effort to get things working quickly, a different version of VMware was loaded, so that the test environment would match that of Sacco & Ortega’s. After some searching, the exact version of VMware that they had used was located and installed. This unfortunately still did not solve the issue, the same crash error was reported by VMware. While I had seen this BIOS modification work when demonstrated as part of their presentation, it was now clear that their example code would require additional modification before it could work on any test system.

Many different things were learned as a result of debugging Sacco’s & Ortega’s code, and eventually the problem was narrowed down to an assembler instruction which was executing a far call to an absolute address which was not the correct address for the BIOS being used. With the correct address entered the BIOS code successfully executed, and the rootkit began searching the hard drive for files to modify. This code took a very long time to scan across the hard drive (which was only 15gb), and it was run multiple times before the system would start. The proof of concept code included the functionality to patch notepad.exe so that it would display a message when started, or to modify the /etc/passwd file on a unix system so that the root password would be set to a fixed value. This showed that the rootkits can be functional on both Windows and Linux systems, even if only used for simple purposes.

Bootkit Testing

While significantly later on in the project time line, the functionality of various bootkit code was also tested, and the results recreated to determine which would work best as not just a bootkit, but also a BIOS based rootkit. Four different bootkits were examined, the Stoned, Whistler, Vbootkit and Vbootkit2 bootkits. The Stoned and Whistler bootkits were designed to function much more like malware than a rootkit, and did not have a simple source code structure. The Vbootkit2 bootkit was much different, as it was not designed to be malware and had (relatively) well documented source code. This bootkit was designed to be run from a CD, but only was tested with Windows 7 beta. When used with Windows 7 retail, the bootkit simply did not load as different file signatures were used by Windows. Some time was spent determining the new file signatures so that this bootkit could be tested, but it would still not load successfully. To allow for testing a beta copy of Windows 7 was obtained instead. When the Vbootkit2 software was run on a Windows 7 beta system, everything worked as expected. The Vbootkit2 software included the ability to escalate a process to System (above admin) level privileges, to capture keystrokes, and to reset user passwords. These were all items that would be valuable to have included in a rootkit, but significant work remained to port this application to Windows 7 retail. The Vbootkit software was examined next; it was designed to work with Windows 2003, XP and 2000. While it was not packaged so that it could be run from CD, only minor modifications were required to add that functionality. This software only included the ability to escalate process privileges, but that alone is a very valuable function. This bootkit software was chosen for use with the BIOS rootkit, which is described in the next section. NVLabs ( are the authors of the bootkit itself, which in many ways represents the main functionality of this project, so a big thanks to them for making their code public! It appears their source code is no longer available on their website, but it can still be downloaded from here.

BIOS Code Injection

The proof of concept code by Sacco & Ortega which was previously tested was very fragile, and its functions were not the type of actions that a rootkit should be performing. The first step in developing a new rootkit was to develop a robust method of having the BIOS execute additional code.

Sacco & Ortega patched the BIOS’s decompression module since it was already decompressed (so that it could decompress everything else), and it is called as the BIOS is loaded. This reasoning was appropriate, but the hooking techniques needed to be modified. During normal operation, the BIOS would call the decompression module once for each compressed BIOS module that was present. The VMware BIOS included 22 compressed modules, so the decompression code was called 22 times. This module will overwrite our additional code as it resides in buffer space, so it is necessary to have our addition code relocate itself.

The process that I used includes the following steps:

  • Insert a new call at the beginning of the decompression module to our additional code.
  • Copy all of our additional code to a new section of memory.
  • Update the decompression module call to point to the new location in memory where our code is.
  • Return to the decompression module and continue execution.

This process allows for a significant amount of additional code to be included in the BIOS ROM, and for that code to run from a reliable location in memory once it has been moved there. The above four steps can be shown in a diagram as follows:
(mspaint is awesome)

Implementing this code in assembler was possible a number of different ways, but the goal was to create code that would be as system independent as possible. To accomplish this, all absolute addressing was removed, and only near calls or jumps were used. The exceptions to this were any references to our location in the free memory, as that was expected to be a fixed location, regardless of the system. The following is the assembler code which was used to handle the code relocation:

; The following two push instructions will save the current state of the registers onto the

; Segment registers are cleared as we will be moving all code to segment 0
xor ax, ax              ; (This may or may not be obvious, but xor'ing the register sets it to 0).
xor di, di
xor si, si
push cs; Push the code segment into the data segment, so we can overwrite the calling address code
pop ds; (CS is moved to DS here)
mov es, ax              ; Destination segment (0x0000)
mov di, 0x8000              ; Destination offset, all code runs from 0x8000
mov cx, 0x4fff              ; The size of the code to copy, approximated as copying extra doesn't hurt anything

; The following call serves no program flow purposes, but will cause the calling address (ie, where this code
; is executing from) onto the stack. This allows the code to generically patch itself no matter where it might
; be in memory. If this technique was not used, knowledge of where in memory the decompression module would be
; loaded would be required in advance (so it could be hard coded), which is not a good solution as it differs for every system.
call b

pop si                  ; This will pop our current address of the stack (basically like copying the EIP register)
add si, 0x30                ; How far ahead we need to copy our code
rep movsw               ; This will repeat calling the movsw command until cx is decremented to 0. When this command is 
                    ; finished, our code will be copied to 0x8000
mov ax, word [esp+0x12]         ; This will get the caller address to patch the original hook
sub ax, 3               ; Backtrack to the start of the calling address, not where it left off
mov byte [eax], 0x9a            ; The calling function needs to be changed to an Call Far instead of a Call Near
add ax, 1               ; Move ahead to set a new address to be called in future
mov word [eax], 0x8000          ; The new address for this code to be called at
mov word [eax+2], 0x0000        ; The new segment (0)

; The code has now been relocated and the calling function patched, so everything can be restored and we can return.

; The following instructions were overwritten with the patch to the DECOMPC0.ROM module, so we need to run them now before we return.
mov bx,es
mov fs,bx
mov ds,ax
ret                 ; Updated to a near return

Once the above code is executed, it will copy itself to memory offset 0x8000, and patch the instruction which initially called it, so that it will now point to 0x8000 instead. For initially testing this code, the relocated code was simply a routine which would display a “W” to the screen (see screenshot below). The end goal however was that our rootkit code could be called instead, so the next modification was to integrate that code.


As noted in the earlier section, the “VBootkit” software was determined to be the best fit for the type of rootkit functionality that could be loaded from the BIOS. The VBootkit software was originally created so that it would run from a bootable CD. While this starting point is similar to running from the BIOS, there are a number of key differences. These differences are mainly based on the booting process, which is shown below:

Our BIOS based rootkit code will run somewhere in between the BIOS Entry and the BIOS Loading Complete stages. A bootkit would instead run at the last stage, starting from 0x7C00 in memory.

The VBootkit software was designed so that it would be loaded into address 0x7C00, at which point it would relocate itself to address 0x9E000. It would then hook interrupt 0x13, and would then read the first sector from the hard drive (the MBR) into 0x7C00, so that it could execute as if the bootkit was never there. This process needed to be modified so that all hard coded addresses were replaced (as the bootkit is no longer executing from 0x7C00). Additionally, there is no need to load the MBR into memory as the BIOS will do that on its own.

The VBootkit software hooks interrupt 0x13, that is, it replaces the address that the interrupt would normally go to with its own address, and then calls the interrupt after doing additional processing. This turned out to require an additional modification as when our BIOS rootkit code is called interrupt 0x13 is still not fully initialized. This was overcome by storing a count in memory of how many times the decompression module had been run. If it had been run more 22 times (for 22 modules), then the BIOS was fully initialized, and we could safely hook interrupt 0x13.

The Vbootkit software follows the following process:

  • When first called it will relocate itself to 0x9E000 in memory (similar to our BIOS relocation done previously)
  • Next it will hook interrupt 0x13, which is the hard disk access interrupt
  • All hard disk activity will be examined to determine what data is being read
  • If the Windows bootloader is read from the hard disk, the bootloader code will be modified before it is stored in memory
  • The modification made to the bootloader will cause it to modify the Windows kernel. This in turn will allow arbitrary code to be injected into the Windows kernel, allowing for the privilege escalation functionality.

With our BIOS injection plus the bootkit loaded the process flow happens as follows:

The result of all of these modifications is a BIOS which copies the bootkit into memory and executes it, loads the OS from the hard drive, and then ends with an OS which has been modified so that certain processes will run with additional privileges. The following screenshot shows the bootkit code displaying a message once it finds the bootloader and the kernel and successfully patches them:


The code used for this rootkit was set to check for any process named “pwn.exe”, and if found, give it additional privileges. This is done every 30 seconds, so the differences in privileges are easy to see. This function can be seen in the code and screenshot below:

xor ecx,ecx
mov word cx, [CODEBASEKERNEL + Imagenameoffset]
cmp dword [eax+ecx], "PWN."         ; Check if the process is named PWN.exe
je patchit
jne donotpatchtoken             ; jmp takes 5 bytes but this takes 2 bytes

mov word cx, [CODEBASEKERNEL + SecurityTokenoffset]
mov dword [eax + ecx],ebx       ; replace it with services.exe token, offset for sec token is 200


The BIOS rootkit which has been developed could definitely include more functionality (such as what is included in Vbootkit2), but still acts as an effective rootkit in its current state.

BIOS Decompression and Patching

Now that we know how we want the rootkit to be injected into the BIOS, the next step is to actually patch the BIOS with our rootkit code. To do this we need to extract all of the BIOS modules, patch the decompression module, and reassemble everything. The modules can be extracted using the phxdeco command line tool, or the Phoenix BIOS Editor. Once the decompression module is extracted, the following code will patch it with our rootkit:

import os,struct,sys
# BIOS Decompression module patching script - By Wesley Wineberg
# The Phoenix BIOS Editor application (for Windows) will generate a number of module files
# including the decompression module which will be named "DECOMPC0.ROM". These files are
# saved to C:\Program Files\Phoenix Bios Editor\TEMP (or similar) once a BIOS WPH file is
# opened. The decompression module file can be modified with this script. Once modified,
# any change can be made to the BIOS modules in the BIOS editor so that a new BIOS WPH file
# can be generated by the BIOS editor. The decompression module can alternatively be
# extracted by phnxdeco.exe, but this does not allow for reassembly. This script requires
# that NASM be present on the system it is run on.
# This patching script requires the name and path to the BIOS rootkit asm file to be passed
# as an argument on the command line.
# This script will modify the DECOMPC0.ROM file located in the same directory as the script
# so that it will run the BIOS rootkit asm code.
# Display usage info
if len(sys.argv) < 2:
print "Modify and rebuild Phoenix BIOS DECOMP0.ROM module. Rootkit ASM code filename
# Find rootkit code name
shellcode = sys.argv[1].lower()
# Assemble the assembler code to be injected. NASM is required to be present on the system
# or this will fail!
os.system('nasm %s' % shellcode)
# Open and display the size of the compiled rootkit code
shellcodeout = shellcode[0:len(shellcode)-4]
decomphook = open(shellcodeout,'rb').read()
print "Rootkit code loaded: %d bytes" % len(decomphook)
# The next line contains raw assembly instructions which will be placed 0x23 into the
decompression rom
# file. The decompression rom contains a header, followed by a number of push instructions
and then
# a CLD instruction. This code will be inserted immediately after, and will overwrite a
number of
# mov instructions. These need to be called by the rootkit code before it returns so that
#the normal decompression functions can continue.
# The assembler instruction contained below is a Near Call which will jump to the end of the
# decompression rom where the rootkit code has been inserted. This is followed by three NOP
# instructions as filler.
minihook = '\xe8\x28\x04\x90\x90\x90'
# The following would work but is an absolute call, not ideal!
# minihook = '\x9a\x5A\x04\xDC\x64\x90' # call far +0x45A
# Load the decompression rom file
decorom = open('DECOMPC0.ROM','rb').read()
# Hook location is 0x23 in to the file, just past the CLD instruction

# Insert hook contents into the decompression rom, overwriting what was there previously
decorom = decorom[:hookoffset]+minihook+decorom[len(minihook)+hookoffset:]
# Pad the decompression rom with 100 NOP instructions. This is not needed, but does make it
# easier to identify where the modification has taken place.
# Pad an additional 10 NOP's at the end.
# Recalculate the ROM size, so that the header can be updated
# Save the patched decompression rom over the previous copy
# Output results
print "The DECOMPC0.ROM file has now been patched."

An example of how to call the above script would be:

python biosrootkit.asm

If everything works successfully, you should see something similar to the following:

Rootkit code loaded: 1845 bytes
The DECOMPC0.ROM file has now been patched.

BIOS Reassembly

For raw BIOS files, such as the one included with VMware, a number of command line utilities included with the Phoenix Bios Editor (or available from Intel) can be used to reassemble everything. Later on when testing with a real PC it was necessary to save the BIOS in more than just the raw format, so the tool for reassembly used was the GUI version of the Phoenix Bios Editor. This unfortunately means that it is not possible to simply have one application that can be run on a system which will infect the BIOS, at least not using off the shelf tools.

This now means that the BIOS infection is a three stage process, requiring some manual intervention mainly for the reassembly. The following shows the Phoenix BIOS Editor with a BIOS image open:


The Phoenix BIOS Editor is not specifically designed for swapping modules in and out, but does effectively allow for it. When a BIOS image is first opened, all of the BIOS modules will be extracted to disk in a folder located at C:\Program Files\Phoenix BIOS Editor\TEMP. The decompression module can be copied from this folder, patched, and replaced. The Phoenix BIOS Editor will not allow you to save a BIOS without a modification, so it is necessary to modify a string value and then change it back (or just leave it) so that the BIOS can be saved.

The BIOS based rootkit source code and patching scripts can be downloaded from the links near the end of this write-up if you would like to try all of this out yourself.

Real PC’s

The Phoenix BIOS was used with all of the VMware based development, so this was also chosen for testing with a physical PC. All of the physical (as opposed to virtual) BIOS testing was done using an HP Pavilion ze4400 laptop. BIOS testing was originally planned for use with PC’s and not laptops, as getting access to the PC motherboard for reflashing if necessary would be much easier. Despite this fact, quickly locating a PC with a Phoenix BIOS proved to be difficult, so a laptop was used instead (special thanks to David for reflashing my laptop when I accidently wrote source code to my BIOS!)

PC BIOS Retrieval

The first step to modifying a real system BIOS is to extract a copy of it. Phoenix has two different tools which they generally provide for this purpose, one is called “Phlash16″, and the other is called “WinPhlash”. Phlash16 is a command line utility (with a console based GUI), but will only run from DOS. WinPhlash, as its name suggests, runs from Windows. While this is a GUI based utility, it will also accept command line options, allowing us to automate the process of BIOS retrieval. For this project I ended up making some scripts to automate BIOS extraction and patching, but they’re quite basic and limited.

The following batch script will copy the BIOS into a file named BIOSORIG.WPH, and then check if it has previously been modified. The Perl script simply checks the BIOS contents for my name, which would not be in any unpatched BIOS.

@rem This file dumps the bios and checks if it has previously been patched.
@rem Dump
WinPhlash\WinPhlash.exe /ro=BIOSORIG.WPH
@rem Check if the BIOS has been patched already
Python\PortablePython_1.1_py2.6.1\App\python WinPhlash\BIOSORIG.WPH

PC BIOS Decompression and Patching

With the BIOS retrieved, the next step is to patch it with our rootkit code. This can be done using the exact same scripts that we used for VMware in the sections above. It was a goal of this project to design the patch as well as the patching process to be as compatible as possible. I am quite pleased that this turned out to be completely possible, so that the same tools can be used for completely different hardware running the same type of BIOS.

PC BIOS Reassembly

While there is a free tool which can extract modules from Phoenix BIOS’s, it appears that only the Phoenix Bios Editor will reassemble them as needed for typical PC’s. The WinPhlash tool requires additional information to be included with the BIOS, which it stores along with the raw BIOS in the WPH file. After testing many different options, it appears that the only way to successfully reassemble the WPH file is to use the GUI Phoenix Bios Editor. This unfortunately means that it is not possible to simply have one application that can be run on a system which will infect the BIOS, at least not using off the shelf tools.

Theoretically it should be possible to reverse engineer the WPH format and create a custom BIOS reassembly tool, but this was out of the scope of this project. Instead, the BIOS infection is a three stage process, requiring some manual intervention mainly for the reassembly.

As with patching the VMware BIOS, the same trick to have the Phoenix BIOS Editor reassemble a patched module can be used. When a BIOS image is first opened, all of the BIOS modules will be extracted to disk in a folder located at C:\Program Files\Phoenix BIOS Editor\TEMP. The decompression module can be copied from this folder, patched, and replaced. The Phoenix BIOS Editor will not allow you to save a BIOS without a modification, so it is necessary to modify a string value and then change it back (or just leave it) so that the BIOS can be saved.

BIOS Flashing

Once the BIOS is reassembled into the WPH file, the following batch script will flash the new BIOS image into the BIOS EEPROM and then reboot the PC so that it takes effect:

@rem This file uploads a file named "BIOSPATCHED.WPH" to the BIOS. Will reboot system when done.

Laptop Modification Results

With everything described so far put together, the following shows the BIOS code being flashed onto a laptop (being run from the infect.bat script detailed above):


Once the flash completed, the BIOS rootkit successfully ran and loaded itself into the Windows kernel. The following screenshot shows a command prompt which starts initially as a normal user, and then after 30 seconds has its privileges escalated:


This demonstrated that the BIOS rootkit was portable enough to work on multiple systems (VMware, the HP laptop), and that the infection mechanisms were functional and working properly.

The “rootkit” developed for this project only implements one simple task, but as noted regarding the Vbootkit2 software, there is no reason additional functionality cannot be added to this. BIOS’s made by Phoenix were examined for this project, and it is likely that there are many similarities between Phoenix BIOS’s and BIOS’s from other manufacturers. While it is likely that code will need to be created for each separate manufacturer, there are not a large number of different BIOS vendors, so expanding this rootkit functionality to all of the common manufacturers should be feasible.

In the introduction I noted that new BIOS features, such as signed BIOS updates, make much of what is described here far less of an issue from a security standpoint. That is definitely good to see, but it is also worth remembering that there are more “legacy” computers out there than there are “new” ones, so this type of attack will still remain an issue for quite a while to come.

Demo VMware BIOS and source code

The following source code, and patched BIOS is provided as a proof of concept. It is in no way my intention that people take this and use it for any malicious purposes, but rather to demonstrate that such attacks are completely feasible on older BIOS configurations. I do not expect that it is very feasible to take this in its current form and turn it into any sort of useful malware, and based on that I am posting this code online.

As noted in the earlier sections, this code should work to patch most “Phoenix” BIOS’s. The patching scripts can be downloaded here:

The source code for the BIOS rootkit can be downloaded here:

You will need NASM to compile the code to patch into the BIOS if you are using the above scripts / source code. NASM should either be added to your path variable, or you should update the patching script to have an absolute path to it for it to work successfully. You will also need a copy of the Phoenix BIOS Editor, or a free tool equivalent to combine the decompression module back into a complete BIOS.

If you don’t want to compile this all yourself and would simply like to try it, a pre-patched BIOS for use with VMware can be downloaded here:

PoC Usage and Notes

If you don’t feel like reading through the whole write-up above, here is the summary of how to try this out, and what it does.

  • First, download the BIOS_rootkit_demo.ROM BIOS image from the above link.
  • To try it, you need a copy of VMware installed, and a guest Windows XP operating system to test with. I’ve personally tested this with a bunch of different versions of VMware Workstation, as well as the latest version of VMware Player (which is free). I am also told that VMware Fusion works just fine too.
  • Before opening your guest WinXP VM, browse to where you have the VM stored on your computer, and open the .vmx file (ie WindowsXP.vmx or whatever your VM is called) in notepad. Add a new line at the end that matches the following: bios440.filename = "BIOS_rootkit_demo.ROM". Make sure you copy BIOS_rootkit_demo.ROM to that folder while you’re at it.
  • Now open and start the VM, then rename a program to pwn.exe (cmd.exe for example).
  • Wait 30 seconds, and then start the Task Manager. Pwn.exe should be running as user “SYSTEM” now instead of whatever user you are logged into XP with.

The list of steps described above should work in an ideal world. Testing has shown the following caveats however!

  • OS instability. Sometimes when booting or just simply closing your pwn.exe application Windows will BSOD.
  • Task Manager will lie about your process user if you open it in advance of the 30s permission escalation time. Use something like cmd with whoami to properly check what your permissions are.
  • While I have loaded this successfully onto a real PC, I take no responsibility for the results if you do the same. I’d love to hear about it if you brick your motherboard in some horrendous way, but I probably won’t actually be able to help you with it! Use at your own risk!
  • If you just want to watch a video of what this does, Colin has put one up on YouTube:

    I recommend actually trying it in VMware, it’s way more fun to see a hard drive wipe do nothing, and your system still affected!

OSSEC: Open-Source Host-Based Intrusion Detection System for Linux


OSSEC is an open-source, host-based intrusion detection system (HIDS) that performs log analysis, integrity checking, Windows registry monitoring, rootkit detection, time-based alerting, and active response. It can be used to monitor one server or thousands of servers in a server/agent mode. If properly configured, OSSEC can give you a real-time view into what’s happening on your server.

This tutorial will show you how to install and configure OSSEC to monitor Ubuntu server. We’ll configure OSSEC so that if a file is modified, deleted, or added to the server, OSSEC will notify you by email – in real-time. That’s in addition to other integrity-checking features that OSSEC offers.

OSSEC can do more than notify you of file modifications, but one article is not enough to show you how to take advantage of all its features.

You need to have a server that you want to monitor. This tutorial assumes that you already have one and that it’s already set up for use. The most important thing is that you have access to it and can log in via SSH. Setting up OSSEC is not something you want to undertake when you still don’t know how to ssh into your server.

  • Ubuntu server
  • You should create a sudo user on the server. In this example, the user is named root
  • Optional: If you want to send mail from a local SMTP server, you should install Postfix for simple email sending
  • Installation of OSSEC involves some compiling, so you need gcc and make installed. You can install both by installing a single package called build-essential
  • You also need to install a package called inotify-tools, which is required for real-time alerting to work

Open-Source Host-Based Intrusion Detection System: OSSEC Open-Source Host-Based Intrusion Detection System: OSSEC Open-Source Host-Based Intrusion Detection System: OSSECTo install all required packages, first update the server:

apt-get update

The install the packages:

apt-get install build-essential inotify-tools

Download and Verify OSSEC

Since this a security article, we’re going to do a little extra work to verify that we’re installing valid software. The idea is that you generate the MD5 and SHA1 checksums of the downloaded OSSEC tarball and compare them with those in the checksum file. If they match, then you can assume that the tarball has not been tampered with.

At the time of writing, the latest server edition of OSSEC is version 2.8.1. To download it, type:

wget -U ossec

To download the checksum file, type:

wget -U ossec

To verify that both files are in place, type:

ls -l ossec*

You should see the files:


Now, let’s examine the checksum file with the cat command, like so:

cat ossec-hids-2.8.1-checksum.txt


MD5(ossec-hids-2.8.1.tar.gz)= c2ffd25180f760e366ab16eeb82ae382
SHA1(ossec-hids-2.8.1.tar.gz)= 0ecf1df09558dc8bb4b6f65e1fb2ca7a7df9817c

In the above output, the important parts are those to the right of the = sign. Those are the MD5 and SHA1 checksums of the tarball.

Now we’ll make sure the checksums we generate for the tarball match the checksums we downloaded.

To generate the MD5sum of the tarball, type:

md5sum ossec-hids-2.8.1.tar.gz

Expected output:

c2ffd25180f760e366ab16eeb82ae382  ossec-hids-2.8.1.tar.gz

Compare the generated MD5 checksum with the one in the checksum file. They should match.

Do the same for the SHA1 checksum by typing:

sha1sum  ossec-hids-2.8.1.tar.gz

Expected output:

0ecf1df09558dc8bb4b6f65e1fb2ca7a7df9817c  ossec-hids-2.8.1.tar.gz

If both match, you’re good to go.

Install OSSEC

OSSEC can be installed in server, agent, local or hybrid mode. This installation is for monitoring the server that OSSEC is installed on. That means a local installation.

Before installation can start, you have to extract the file. You do that by typing:

tar -zxf ossec-hids-2.8.1.tar.gz

After that, you should have a directory named ossec-hids-2.8.1. To start installation, you have to change (cd) into that directory, which you do by typing:

cd ossec-hids-2.8.1

To see the contents of the directory that you’re now in, use the ls command by typing:

ls -lgG

You should see these files and directories:

total 100
drwxrwxr-x  4  4096 Apr  9 23:34 active-response
-rw-rw-r--  1   542 Apr  9 23:34 BUGS
-rw-rw-r--  1   289 Apr  9 23:34 CONFIG
drwxrwxr-x  6  4096 Apr  9 23:34 contrib
-rw-rw-r--  1  3196 Apr  9 23:34 CONTRIBUTORS
drwxrwxr-x  4  4096 Apr  9 23:34 doc
drwxrwxr-x  4  4096 Apr  9 23:34 etc
-rw-rw-r--  1  1848 Apr  9 23:34 INSTALL
-rwxrwxr-x  1 32019 Apr  9 23:34
-rw-rw-r--  1 24710 Apr  9 23:34 LICENSE
-rw-rw-r--  1  1664 Apr  9 23:34
drwxrwxr-x 30  4096 Apr  9 23:34 src

The only file of interest to us in that listing is That’s the OSSEC installation script. To initiate installation, type:


You will be prompted to answer some installation questions.

The first task that will be required of you is the selection of the language. As shown in the output below, the default is English. Throughout the installation process, if you’re required to make a selection, any entry in square brackets is the default. If the default is what you want, press the ENTER key to accept the default. Other than having to type your email address, we recommend that you accept all the defaults — unless you know what you’re doing.

So if your language is English, press ENTER. Otherwise, type the two letters for your language and press ENTER.

  (en/br/cn/de/el/es/fr/hu/it/jp/nl/pl/ru/sr/tr) [en]:

After selecting the language, you should see this:

OSSEC HIDS v2.8 Installation Script -

 You are about to start the installation process of the OSSEC HIDS.
 You must have a C compiler pre-installed in your system.
 If you have any questions or comments, please send an e-mail
 to (or

  - System: Linux arrakis 3.13.0-36-generic
  - User: root
  - Host: arrakis

  -- Press ENTER to continue or Ctrl-C to abort. --

After pressing ENTER, you should get:

1- What kind of installation do you want (server, agent, local, hybrid or help)? local

Type local and press ENTER. You should get:

  - Local installation chosen.

2- Setting up the installation environment.

  - Choose where to install the OSSEC HIDS [/var/ossec]:

Accept the default and press ENTER. After that, you’ll get:

    - Installation will be made at  /var/ossec .

3- Configuring the OSSEC HIDS.

  3.1- Do you want e-mail notification? (y/n) [y]:

Press ENTER.

  - What's your e-mail address?

Type the email address where you want to receive notifications from OSSEC.

  - We found your SMTP server as:
  - Do you want to use it? (y/n) [y]:

--- Using SMTP server:

Press ENTER unless you have specific SMTP server settings you want to use.

Now’s time to let OSSEC know what checks it should be running. In response to any prompt from the script, accept the default by pressing ENTER.

ENTER for the integrity check daemon.

  3.2- Do you want to run the integrity check daemon? (y/n) [y]:

- Running syscheck (integrity check daemon).

ENTER for rootkit detection.

  3.3- Do you want to run the rootkit detection engine? (y/n) [y]:

- Running rootcheck (rootkit detection).

ENTER for active response.

  3.4- Active response allows you to execute a specific command based on the events received.  

   Do you want to enable active response? (y/n) [y]:

   Active response enabled.

Accept the defaults for firewall-drop response. Your output may show some IPv6 options – that’s fine.

  Do you want to enable the firewall-drop response? (y/n) [y]:

- firewall-drop enabled (local) for levels >= 6

   - Default white list for the active response:

   - Do you want to add more IPs to the white list? (y/n)? [n]:

You may add your IP address here, but that’s not necessary.

OSSEC will now present a default list of files that it will monitor. Additional files can be added after installation, so press ENTER.

3.6- Setting the configuration to analyze the following logs:
    -- /var/log/auth.log
    -- /var/log/syslog
    -- /var/log/dpkg.log

 - If you want to monitor any other file, just change
   the ossec.conf and add a new localfile entry.
   Any questions about the configuration can be answered
   by visiting us online at .

   --- Press ENTER to continue ---

By this time, the installer has all the information it needs to install OSSEC. Kick back and let the installer do its thing. Installation takes about 5 minutes. If installation is successful, you are now ready to start and configure OSSEC.

Note: One reason installation might fail is if a compiler is not installed. In that case, you’ll get an error like this:

5- Installing the system
 - Running the Makefile
./ 85: ./ make: not found

 Error 0x5.
 Building error. Unable to finish the installation.

If you get that error, then you need to install build-essential.

If installation succeeds, you should see this type of output:

 - System is Debian (Ubuntu or derivative).
 - Init script modified to start OSSEC HIDS during boot.

 - Configuration finished properly.

 - To start OSSEC HIDS:
                /var/ossec/bin/ossec-control start

 - To stop OSSEC HIDS:
                /var/ossec/bin/ossec-control stop

 - The configuration can be viewed or modified at /var/ossec/etc/ossec.conf

    ---  Press ENTER to finish (maybe more information below). ---

OSSEC is now installed. The next step is to start it.


By default OSSEC is configured to start at boot, but the first time, you’ll have to start it manually.

If you want to check its current status, type:

/var/ossec/bin/ossec-control status

Expected output:

ossec-monitord not running...
ossec-logcollector not running...
ossec-syscheckd not running...
ossec-analysisd not running...
ossec-maild not running...
ossec-execd not running...

That tells you that none of OSSEC’s processes are running.

To start OSSEC, type:

/var/ossec/bin/ossec-control start

You should see it starting up:

Starting OSSEC HIDS v2.8 (by Trend Micro Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-monitord...

If you check the status again, you should get confirmation that OSSEC is now running.

/var/ossec/bin/ossec-control status

This output shows that OSSEC is running:

ossec-monitord is running...
ossec-logcollector is running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild is running...
ossec-execd is running...

Right after starting OSSEC, you should get an email that reads like this:

OSSEC HIDS Notification.
2015 Apr 10 11:15:38

Received From: ossec2->ossec-monitord
Rule: 502 fired (level 3) -> "Ossec server started."
Portion of the log(s):

ossec: Ossec started.

That’s another confirmation that OSSEC is working and will send you email alerts whenever something it’s configured to monitor happens. Even when it is restarted, OSSEC will send you an email.

If you didn’t get this email right away, don’t worry. You may still need to tweak your email settings to make sure your OSSEC server’s emails can get through to your mail provider. This is especially true for some 3rd-party email service providers like Google and Fastmail.

Configure OSSEC for Real-time Alerts on File Modifications

OSSEC’s default directory is a chroot-ed (sandbox) environment that only a user with root (admin) privileges can access. A standard user cannot cd into /var/ossec or even list the files in it. As the root (or admin) user, however, you can.

So, cd into the installation directory by typing:

cd /var/ossec

To list the files in your new working directory, type:

ls -lgG

You should see these files and directories:

total 40
dr-xr-x---  3 4096 Apr 10 10:16 active-response
dr-xr-x---  2 4096 Apr 10 10:16 agentless
dr-xr-x---  2 4096 Apr 10 10:16 bin
dr-xr-x---  3 4096 Apr 10 10:16 etc
drwxr-x---  5 4096 Apr 10 10:16 logs
dr-xr-x--- 11 4096 Apr 10 10:16 queue
dr-xr-x---  4 4096 Apr 10 10:16 rules
drwxr-x---  5 4096 Apr 10 10:16 stats
dr-xr-x---  2 4096 Apr 10 10:16 tmp
dr-xr-x---  3 4096 Apr 10 10:16 var
  • OSSEC’s main configuration file is in the /var/ossec/etc directory.
  • Predefined rules are in the /var/ossec/rules directory
  • Commands used to manage OSSEC are in /var/ossec/bin
  • Take note of the /var/ossec/logs directory. If OSSEC ever throws an error, the/var/ossec/logs/ossec.log file in that directory is the first place to look

Main configuration file, /var/ossec/etc/ossec.conf

To access the main configuration file, you have to change into /var/ossec/etc. To do that, type:

cd /var/ossec/etc

If you do an ls while in that directory, you’ll see these files and directories:

ls -lgG


total 120
-r--r----- 1 97786 Apr 10 10:23 decoder.xml
-r--r----- 1  2842 Apr 10 10:23 internal_options.conf
-r--r----- 1  3519 Apr 10 10:23 localtime
-r--r----- 1  7752 Apr 10 10:23 ossec.conf
-rw-r----- 1    87 Apr 10 10:23 ossec-init.conf
drwxrwx--- 2  4096 Apr 10 10:23 shared

The main configuration file is /var/ossec/etc/ossec.conf.

Before modifying the file, make a backup copy, just in case. To make that copy, use the cp command like so:

cp /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf.00

The idea is if your changes don’t work or mess up the system, you can revert to the copy and be back to normal. It’s the simplest disaster recovery practice that you should always take advantage of.

Now, open ossec.conf by using the nano editor.

nano /var/ossec/etc/ossec.conf

The configuration file is a very long XML file with several sections.

Email settings

Note: Email is finicky in general, especially if you are sending to a stricter mail provider like sending to a Gmail address. Check your spam, and tweak your settings if necessary.

The first configuration options you’ll see are the email credentials you specified during installation. If you need to specify a different email address and/or SMTP server, this is the place to do it.


By default, OSSEC sends 12 emails per hour, so you’ll not be flooded with email alerts. You can increase or decrease that value by adding the <email_maxperhour>N</email_maxperhour> setting to that section so that it reads:


Please replace N with the number of emails you want to receive per hour, between 1 and 9999.

Some third-party email service providers (Google and Fastmail, for example) will silently drop alerts sent by OSSEC if the <email_from> address does not contain a valid domain par. To avoid that, make sure that that email address contains a valid domain part.

If you don’t want to use an external email provider’s SMTP server, you can specify your own SMTP server, if you have one configured. If your SMTP server is running on the same system as OSSEC, change the<smtp_server>setting to localhost. For example:


If you still aren’t receiving expected emails from OSSEC, check the logs at/var/ossec/logs/ossec.log for mail errors.

Example mail errors:

2015/04/10 11:28:35 os_sendmail(1767): WARN: End of DATA not accepted by server
2015/04/10 11:28:35 ossec-maild(1223): ERROR: Error Sending email to (smtp server)

You can use these error messages to help you debug any issues with receiving email notifications.

Frequency of scans

In the <syscheck> section of ossec.conf, which starts like this:

    <!-- Frequency that syscheck is executed - default to every 22 hours -->

We will turn on alerts for new file creation. Add the line <alert_new_files>yes</alert_new_files>so that it reads like this:

    <!-- Frequency that syscheck is executed - default to every 22 hours -->


For testing purposes, you may also want to set the frequency of the system check to be much lower. By default, the system check is run every 22 hours. For testing purposes, you may want to set this to once a minute, that is,60 seconds. Revert this to a sane value when you are done testing.

    <!-- Frequency that syscheck is executed - default to every 22 hours -->


Directory and file change settings

Right after that, you should see the list of system directories that OSSEC monitors. It reads like:

<!-- Directories to check  (perform all possible verifications) -->
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories check_all="yes">/bin,/sbin</directories>

Let’s enable real-time monitoring by adding the settings report_changes="yes" realtime="yes" to each line. Modify these lines so they read:

<!-- Directories to check  (perform all possible verifications) -->
<directories report_changes="yes" realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories report_changes="yes" realtime="yes" check_all="yes">/bin,/sbin</directories>

report_changes="yes" does exactly what is says. Ditto for realtime="yes".

In addition to the default list of directories that OSSEC has been configured to monitor, you can add new directories that you wish to monitor. In this next section, we are telling OSSEC to monitor /root and/var/www. We are going to add a new line right under the existing ones, so that that section now reads:

<!-- Directories to check  (perform all possible verifications) -->
<directories report_changes="yes" realtime="yes" check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<directories report_changes="yes" realtime="yes" check_all="yes">/bin,/sbin</directories>

<directories report_changes="yes" realtime="yes" restrict=".php|.js|.py|.sh|.html" check_all="yes">/root,/var/www</directories>

You should modify the directories to match your desired settings. If your user is not named root, you will want to change the path to the home directory.

For the new directories to monitor, we’ve added the restrict option, which tells OSSEC to monitor only the specified file formats. You don’t have to use that option, but it comes in handy when you have other files, like image files, that you don’t want OSSEC to alert on.

That’s all the changes for ossec.conf. You may save and close the file.

Local rules in /var/ossec/rules/local_rules.xml

The next file to modify is in the /var/ossec/rules directory, so cd into it by typing:

cd /var/ossec/rules

If you do an ls in that directory, you’ll see a bunch of XML files like these:

ls -lgG

Abbreviated output:

total 376
-r-xr-x--- 1  5882 Apr 10 12:13 apache_rules.xml
-r-xr-x--- 1  2567 Apr 10 12:13 arpwatch_rules.xml
-r-xr-x--- 1  3726 Apr 10 12:13 asterisk_rules.xml
-r-xr-x--- 1  4315 Apr 10 12:13 attack_rules.xml


-r-xr-x--- 1  1772 Apr 10 12:13 local_rules.xml


-r-xr-x--- 1 10359 Apr 10 12:13 ossec_rules.xml


Only two of those files are of interest to us now – local_rules.xml and ossec_rules.xml. The latter contains OSSEC’s default rule definitions, while the former is where you add your custom rules.

The default rule definitions in ossec_rules.xml are useful to look at so we can modify and copy them into our local rules. In ossec_rules.xml, the rule that fires when a file is added to a monitored directory is rule554. By default, OSSEC does not send out alerts when that rule is triggered, so the task here is to change that behavior. Here’s what rule 554 looks like in the default version:

<rule id="554" level="0">
<description>File added to the system.</description>

OSSEC does not send out an alert if a rule has a level set to 0. We want to modify this rule to raise the alert level. Instead of changing it in the default file, we will copy the rule to local_rules.xml and modify it so that it can trigger an alert.

To do that, make a backup copy of the /var/ossec/rules/local_rules.xml file:

cp /var/ossec/rules/local_rules.xml /var/ossec/rules/local_rules.xml.00

Edit the file with nano:

nano /var/ossec/rules/local_rules.xml

Add the new rule at the end of the file. Make sure that it is within the <group> ... </group> tag.

<rule id="554" level="7" overwrite="yes">
<description>File added to the system.</description>

Save and close the file.

Those are all the changes necessary.

Restart OSSEC

All that’s left now is to restart OSSEC, something that has to be done every time you modify OSSEC’s files. To restart OSSEC type:

/var/ossec/bin/ossec-control restart

If all is working correctly, you should receive an email from OSSEC informing you that it has (re)started.

WAP – Web Application Protection

WAP – Web Application Protection

WAP 2.0 is a source code static analysis and data mining tool to detect and correct input validation vulnerabilities in web applications written in PHP (version 4.0 or higher) and with a low rate of false positives.

WAP detects and corrects the following vulnerabilities:

  • SQL Injection (SQLI)
  • Cross-site scripting (XSS)
  • Remote File Inclusion (RFI)
  • Local File Inclusion (LFI)
  • Directory Traversal or Path Traversal (DT/PT)
  • Source Code Disclosure (SCD)
  • OS Command Injection (OSCI)
  • PHP Code Injection

This tool semantically analyses the source code. More precisely, it does taint analysis (data-flow analysis) to detect the input validation vulnerabilities. The aim of the taint analysis is to track malicious inputs inserted by entry points ($_GET, $_POST arrays) and to verify if they reaches some sensitive sink (PHP functions that can be exploited by malicious input). After the detection, the tool uses data mining to confirm if the vulnerabilities are real or false positives. At the end, the real vulnerabilities are corrected with the insertion of the fixes (small pieces of code) in the source code.

WAP is written in Java language and is constituted by three modules:

  • Code Analyzer: composed by tree generator and taint analyser. The tool has integrated a lexer and a parser generated by ANTLR, and based in a grammar and a tree grammar written to PHP language. The tree generator uses the lexer and the parser to build the AST (Abstract Sintatic Tree) to each PHP file. The taint analyzer performs the taint analysis navigating through the AST to detect potentials vulnerabilities.
  • False Positives Predictor: composed by a supervised trained data set with instances classified as being vulnerabilities and false positives and by the Logistic Regression machine learning algorithm. For each potential vulnerability detected by code analyser, this module collects the presence of the attributes that define a false positive. Then, the Logistic Regression algorithm receives them and classifies the instance as being a false positive or not (real vulnerability).
  • Code Corrector: Each real vulnerability is removed by correction of its source code. This module for the type of vulnerability selects the fix that removes the vulnerability and signalizes the places in the source code where the fix will be inserted. Then, the code is corrected with the insertion of the fixes and new files are created.

More information can be found at:

ApplicationLayerIntrustionDetection and OWASP AppSensor


Application Layer Intrusion Detection

Today’s applications are responsible for securely performing critical operations for individuals and businesses around the world. From transferring money, to managing health records, web enabled applications handle immense amounts of sensitive data each day. Despite the critical role they play, the security defenses within these applications are seriously lacking. The attackers are organized, motivated, and backed by a network of resources and talent. If our applications have any hope of standing up to such formidable opponents, then we need to move beyond just attempting to design our applications securely. We need to implement robust attack detection within the application to identify malicious users before they are successful in their attack. Just like in the real world, we would prefer to detect and prevent an attack instead of just responding after a compromise has occurred.

How do we bridge the technology gap to implement appropriate security controls in our critical applications? The first step is to realize that in order to detect and respond to malicious activity at the application layer we need to be able to monitor and understand a user’s actions within the application. Security approaches of previous years are not sufficient. A firewall provides no protection; its purpose is to allow users to access the application. Nor does a network based IDS system since it will have no insight to our application specific traffic. Antivirus is also out of the question since this is a signature based approach that knows nothing of custom web application vulnerabilities.

We need to move into the application layer to understand our attackers. One potential solution is a web application firewall (WAF). A WAF is able to detect generic application attacks such as basic SQL injection attacks or common actions of a known attack sequence. While some detection is better than none, a generic product could never fully understand the intricacies of each custom web application. This approach is just not sufficient to properly protect critical applications that process sensitive financial data or personal user information. Imagine trying to design an effective building alarm system without any knowledge of how the building is designed or even where the doors and windows are located.

The solution is to design and integrate a detection and response system into the application itself. Within the application we have a full understanding of the user initiating an action, the target of that action and whether that action should be allowed for that user. Inside the application our protection system can identify advanced attacks that are attempting to exploit specific features of our application. Within the application we can easily identify attempts to circumvent security controls or use the application in an unintended manner. After we have determined that a particular user has malicious intent and is attempting to identify weaknesses in our system, we can immediately respond and block the user from future access to the application, or take whatever other action is appropriate. Once locked out, such users can no longer login and are limited to attacking the perimeter of an application, which often contains limited functionality and is typically well secured. Alternatively, some organizations may wish to forego an automated lockout response and instead generate an attack alert and allow their security-monitoring center to perform an immediate investigation and decide upon the appropriate response.

The rigor of response is a decision for each organization in relation to their tolerance for risk and specific needs for an application. However, it is clear that this level of detection capability is a must for any organization wishing to prevent skilled and persistent attackers from compromising their critical applications.

OWASP AppSensor

OWASP is committed to the protection of applications through application attack detection and automated response. The OWASP AppSensor project has been established in response to the clear need for guidance and knowledge in this area.

AppSensor provides the following:

  • Recommendations for what application actions should be detected as malicious along with suggested responses
  • Guidance on designing and implementing an attack detection and response system within an application
  • A Java reference implementation that you can integrate into your application as the basis for your Application Layer Intrusion Detection and Response mechanism

OWASP AppSensor

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.


If you walk into a bank and try opening random doors, you will be identified, led out of the building and possibly arrested. However, if you log into an online banking application and start looking for vulnerabilities no one will say anything. This needs to change! As critical applications continue to become more accessible and inter-connected, it is paramount that critical information is sufficiently protected. We must also realize that our defenses may not be perfect. Given enough time, attackers can identify security flaws in the design or implementation of an application.

In addition to implementing layers of defense within an application, we must identify malicious individuals before they are able to identify any gaps in our defenses. The best place to identify malicious activity against the application is within the application itself. Network based intrusion detection systems are not appropriate to handle the custom and intricate workings of an enterprise application and are ill-suited to detect attacks focusing on application logic such as authentication, access control, etc. This project delivers a framework which can be used to build a robust system of attack detection, analysis, and response within an enterprise application.

Detect and Respond to Attacks from Within the Application


AppSensor defines over 50 different detection points which can be used to identify a malicious attacker.


AppSensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described.

Defending the Application

An attacker often requires numerous probes and attack attempts in order to locate an exploitable vulnerability within the application. By using AppSensor it is possible to identify and eliminate the threat of an attacker before they are able to successfully identify an exploitable flaw.


  • CrossTalk, The Journal of Defense Software Engineering
    • Creating Attack-Aware Software Applications with Real Time Defenses, Vol. 24, No. 5, Sep/Oct 2011

Find out more at: The OWASP AppSensor Project

OWASP ModSecurity Core Rule Set (CRS)

OWASP ModSecurity Core Rule Set (CRS)

The OWASP ModSecurity CRS Project’s goal is to provide an easily “pluggable” set of generic attack detection rules that provide a base level of protection for any web application.


The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform ModSecurityWeb Application Firewall (WAF).


The OWASP ModSecurity CRS provides protections if the following attack/threat categories:

  • HTTP Protection – detecting violations of the HTTP protocol and a locally defined usage policy.
  • Real-time Blacklist Lookups – utilizes 3rd Party IP Reputation
  • HTTP Denial of Service Protections – defense against HTTP Flooding and Slow HTTP DoS Attacks.
  • Common Web Attacks Protection – detecting common web application security attack.
  • Automation Detection – Detecting bots, crawlers, scanners and other surface malicious activity.
  • Integration with AV Scanning for File Uploads – detects malicious files uploaded through the web application.
  • Tracking Sensitive Data – Tracks Credit Card usage and blocks leakages.
  • Trojan Protection – Detecting access to Trojans horses.
  • Identification of Application Defects – alerts on application misconfigurations.
  • Error Detection and Hiding – Disguising error messages sent by the server.


OWASP ModSecurity CRS is free to use. It is licensed under the Apache Software License version 2 (ASLv2), so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

Open HUB

more info can be found at: and here:

Little Snitch: Alerts you about outgoing network connections on Mac OS X

Little Snitch gives you control over your private outgoing data.

Track background activity
As soon as your computer connects to the Internet, applications often have permission to send any information wherever they need to. Little Snitch takes note of this activity and allows you to decide for yourself what happens with this data.

Control your network
Choose to allow or deny connections, or define a rule how to handle similar, future connection attempts. Little Snitch runs inconspicuously in the background and it can even detect network-related activity of viruses, trojans, and other malware.

For more information or to download Little Snitch go to:

MASSIVE COLLECTIONS: Awesome, Awesome All, Awesome-Awesome, Awesome-Awesomes, Awesome Awesomeness, Awesome-Collection, Lists, Lists Of Github Lists, List of Lists, Must-Watch-List and Wiki China Lists


A curated list of awesome lists
For more info check:


Programming languages

Front-end development

Back-end development

Computer science

Big data



Awesome All

A curated list of all the awesome lists of awesome frameworks, libraries and software
For more info check:


Please take a quick gander at the contribution guidelines first. Thanks to all contributors; you rock!



A curated list of awesome curated lists! Inspired by inspiration.
For more info check:

Awesome Awesome

A curated list of amazingly awesome curated lists of amazingly awesome libraries, resources and shiny things for various languages and frameworks.
For more info check:



Common Lisp










Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language, or closely related :D
For more info check:

Feel free to add new lists or categories! Remember, it’s not mandatory that name starts with awesome- ;)

Programming languages | Frameworks, platforms, etc | Related and useful

Programming Languages


  • Awesome C – A curated list of awesome C libraries, frameworks and other shinies.


  • Awesome Clojure – A curated list of awesome clojure libraries and software

Common Lisp

  • Awesome Common Lisp – A curated list of awesome Common Lisp libraries, software and other shinies.


  • Awesome D – A curated list of awesome D documents, frameworks, libraries and software


  • Awesome Elixir – A curated list of amazingly awesome Elixir libraries, resources and shiny things



  • Awesome Go – A curated list of awesome Go frameworks, libraries and software


  • Awesome Haskell – A curated list of awesome Haskell frameworks, libraries and software



  • Awesome JavaScript – A curated list of amazingly awesome browser-side JavaScript libraries, resources and shiny things


  • Awesome PHP – A curated list of amazingly awesome PHP libraries, resources and shiny things


  • Awesome Python – A curated list of awesome Python frameworks, libraries and software



  • Awesome Scala – A curated list of awesome Scala frameworks, libraries and software

Frameworks, platforms, etc



  • Awesome Node.js – A curated list of astonishing Node.js frameworks, libraries and resources

Ruby on Rails

  • Awesome Rails – A curated list of amazingly awesome open source rails related resources


Related and useful



  • Awesome Dev Env – A curated list of awesome tools, resources and workflow tips making an awesome development environment.


  • Awesome Shell – A curated list of awesome command-line frameworks, toolkits, guides and gizmos


  • Awesome Sysadmin – A curated list of amazingly awesome open source sysadmin resources


  • Awesome Talks – List of online talks that you would love to watch


  • Awesome Machine Learning – A curated list of awesome machine learning frameworks, libraries and software (by language).


  • Awesome Awesomes – This one!! ;) Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language :D
  • Awesome Awesomeness – A curated list of awesome awesomeness
  • Awesome Awesome – A curated list of awesome curated lists! Inspired by inspiration

Awesome Awesomeness

A curated list of amazingly awesome awesomeness. Also available on:
And Github:

Awesome Awesome

A curated list of awesome curated lists of many topics, can also found on:

Computer management

  • awesome-shell – Command-line frameworks, toolkits, guides and gizmos.
  • awesome-sysadmin – Backups, configuration management, DNS, IMAP/POP3, LDAP, monitoring, SSH, statistics, troubleshooting, virtualization, VPN and more.

Data processing

Programming languages

  • awesome-clojure – Package management, audio, HTTP, database, websocket and testing.
  • awesome-c – C frameworks, libraries, resources and other cool stuff.
  • awesome-cpp – C/C++ frameworks, libraries, and resources.
  • awesome-cobol – Web frameworks, template engine, forms, authentication & OAuth, database, e-mail, messaging, imagery, text processing, machine learning, testing, audio, video and logging.
  • awesome-common-lisp – Common Lisp frameworks, libraries, resources and other shinies.
  • awesome-d – Build tools, compilers, IDE, GUI, database clients.
  • awesome-elixir – Elixir libraries, resources and shiny things.
  • awesome-go – Go frameworks, libraries and software.
  • awesome-java – Build tool, code analysis, database, GUI, IDE, JSON, machine learning, PDF, science, testing and web crawling.
  • awesome-javascript – JavaScript libraries, resources and shiny things.
  • awesome-julia – List of Julia resources and packages.
  • awesome-perl – Benchmarks, databases, images, logging, profiling, testing, text processing and web frameworks.
  • awesome-php – Frameworks, templating, URL, e-mail, files, imagery, testing, security, documentation, geolocation, date, PDF, search and authentication.
  • awesome-python – Files, dates, text processing, NLP, imagery, audio, video, geolocation, web frameworks, OAuth, web crawling, networking, GUI, game development, testing, science and data analysis and machine learning.
  • [awesome-R] – Not yet! Do it yourself!
  • awesome-ruby – Ruby libraries, tools, frameworks and software
  • awesome-scala – Scala frameworks, libraries and software.
  • awesome-swift – Swift documentation, projects, tutorials, updates, etc


  • [awesome-biology] – Not yet! Do it yourself!
  • [awesome-chemistry] – Not yet! Do it yourself!
  • [awesome-geography] – Not yet! Do it yourself!
  • [awesome-math] – Not yet! Do it yourself!
  • [awesome-physics] – Not yet! Do it yourself!

Web browsers

  • [awesome-firefox] – Not yet! Do it yourself!


  • [awesome-github] – Not yet! Do it yourself!
  • [awesome-flickr] – Not yet! Do it yourself!
  • [awesome-twitter] – Not yet! Do it yourself!
  • awesome-wikipedia – Datasets, frameworks, libraries and other software related to Wikipedia.
  • [awesome-youtube] – Not yet! Do it yourself!

Web platforms


  • [awesome-music] – Not yet! Do it yourself!


a list of awesome repos
For more info check:

awesome lists

  • Awesome – A curated list of awesome lists
  • awesome-all – A curated list of awesome lists of awesome frameworks, libraries and software
  • awesome-awesome by @emijrp – A curated list of awesome curated lists of many topics.
  • awesome-awesome by @erichs – A curated list of awesome curated lists! Inspired by inspiration.
  • awesome-awesome by @oyvindrobertsen – A curated list of curated lists of libraries, resources and shiny things for various languages.
  • awesome-awesomeness – A curated list of awesome awesomeness
  • awesome-awesomes – Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language
  • lists – The definitive list of (awesome) lists curated on GitHub. (comment: No awesome, but more awesome)

Programming languages



The definitive list of (awesome) lists curated on GitHub.
For more info check:
List of useful, silly and awesome lists curated on GitHub. Contributions welcome!




Lists of lists

  • awesome – A curated list of awesome lists.
  • awesome-all – A curated list of awesome lists of awesome frameworks, libraries and software
  • awesome-awesome by @emijrp – A curated list of awesome curated lists of many topics.
  • awesome-awesome by @erichs – A curated list of awesome curated lists! Inspired by inspiration.
  • awesome-awesome by @oyvindrobertsen – A curated list of curated lists of libraries, resources and shiny things for various languages.
  • awesome-awesomeness – A curated list of awesome awesomeness
  • awesome-awesomes – Awesome collection of awesome lists of libraries, tools, frameworks and software for any programming language
  • awesome-collection – A list of awesome repos.
  • ListOfGithubLists – List of github lists
  • list-of-lists – A meta list of lists of useful open source projects and developer tools.
  • must-watch-list – List of must-watch lists.
  • this one
  • wiki In Chinese – A curated list of awesome lists.

Lists of lists of lists

Lists of lists of lists of lists

Lists of lists of lists of lists of lists

List of github lists

Creating a github list is so trendy nowadays, so here’s another one.
Fore more info check:

Pull requests are welcome



A meta list of lists of useful open source projects and developer tools
For more info check:


Frameworks / Libraries


Other lists of lists



A list of must-watch lists
For more info check:

Overview of all lists from this post:
Awesome All:
Awesome Awesome:
Awesome Awesome:
List Of Github Lists:
Wiki China Lists:

Awesome-Awesomeness (zeef):

Building Your Own IDS/UTS Firewall with pfSense

Build Your Own IDS Firewall With pfSense:
Introduction, Firewall vs. IDS, pfSense:
Build, Performance:
PFSense Install, Snort:
IP-Blocklist, Packages, Tips, Conclusion:

Build Your Own UTM With pfSense – Part 1:
Introduction, UTM, IDS, AV:
Anti-Spam, Traffic, Enterprise:

Build Your Own UTM With pfSense – Part 2:
Introduction, Multi-WAN:
Install Squid:
Configure IDS:
Anti-Virus Install:

Build Your Own UTM With pfSense – Part 3:
Introduction, Content Filtering, SquidGuard:
Traffic Control:
Load Balancing & Failover:
Load Balancing & Failover – more:

Build Your Own UTM With pfSense – Part 4:
Monitoring and Logging:
Performance, Conclusion:

Taming Your Network’s Bandwidth Hogs:
pfSense – more, Testing:
Tweaking, Finding Ports, Closing Thoughts:

How to install DNSCRYPT from OpenDNS in pfSense:

Setting up pfSense 2.2-BETA x64 as VPN client with Stunnel:

SSLBL – SSL Blacklist Website

SSL Blacklist (SSLBL) is a project maintained by The goal is to provide a list of “bad” SSL certificates identified by to be associated with malware or botnet activities. SSLBL relies on SHA1 fingerprints of malicious SSL certificates and offers various blacklists that can found in the SSL Blacklist section at:

MITM Attacks with ARP Poisoning and how to defend against ARP Poisoning

In the first link will be described what an Man In The Middle (MITM) is, and how something works with ARP Poisoning.
These info can be found here:

The second link will describe how you can defend against ARP Poisoning on Linux systems by creating a script that will let you make use of static ARP entries, so they can’t change anymore without your knowledge, and will protect you against this kind of attacks.
These info can be found here: