Yes, that is exactly what I am saying. I used Metasploit for the testing. I could not get any signature to fire. Nor did my bloodhound definitions fire for Symantec AV and the exploit was successful. I did a reverse shell and it worked perfectly. I also downloaded and executed a file (calc.exe) and there was no detection by anything. The tcpdump showed the traffic went past the sensor. Not too sure if the signatures are written for the exploit or the vulnerability but from what my testing showed it did not detect it.

I'm seeing 5477-2 firing and assumed that it was the IE exploit trigerring it, this is a concern if it's not the case. Why haven't CISCO responded to this particular threat?

I'm interested in how you tested the exploit, can you provide further info?

5477-2 should fire off of this traffic, but why it's not firing could be one of a couple things.

First, retire/unretire 5477-2 (Retire, apply changes, Unretire, apply changes). Might be a config issue and this will force a rebuild of that signature in the regex tables.

Second, it could be that the sensor is seeing compressed traffic. In some instances, as in your case, the modules are defaulting to gzipping the traffic for transparent compression... browsers will transparently decompress this data. When compression is applied, the result is that we have a very high entropy return data stream very similar to an encrypted data stream, largely due to the fact that the underlying data is also mostly random itself. We are aware of this and are working on a solution that

will address it. The solution will require modification to the sensor inspection code and has been added to the enhancement list for a future

version.