Preventing ActiveX Exploits with Cisco Firewall Application Layer Protocol Inspection


What is ActiveX?
Understanding ActiveX Attacks
Detecting and Preventing ActiveX Exploitation
      Leveraging Regular Expressions
      Firewall Application Layer Protocol Inspection 
Additional Information


The purpose of this whitepaper is to provide administrators and engineers with an overview of ActiveX controls, and information on understanding and preventing the malicious use of ActiveX controls with Cisco’s firewall Application Layer Protocol Inspection feature.

What is ActiveX?

ActiveX is a technology developed by Microsoft. This technology was introduced in 1996 and is based on the Component Object Model (COM) and Object Linking and Embedding (OLE) technologies. Multiple applications, including Microsoft Windows applications Internet Explorer, Microsoft Office, Microsoft Visual Studio, and Windows Media Player, enhance their feature sets and encapsulate their functionality as ActiveX controls to embed the functionality into other applications.

ActiveX controls are small building blocks of programs (active content) that are used to create distributed applications that interoperate over the Internet through the use of web browsers (n.a. 1996, 1). The original intent of ActiveX, as defined initially with the advent of COM and OLE, was to provide easily reusable pieces of code. This reusability is achieved by creating objects that offer interfaces that can be called by other COM objects or programs, for example, Internet Explorer and its integration with COM. This integration provides the ability to seamlessly interface with Windows and third-party applications through the Internet Explorer browser. In addition, this allows the functionality of Internet Explorer to be easily extended by software developers who create complex applications that interface with websites through the browser.

ActiveX controls are often compared to Java applets because both enable end users to download small programs into their web browsers, resulting in more dynamic and interactive web pages (Felten 1997, 1). A major difference between ActiveX controls and Java applets is that ActiveX controls are granted higher levels of control over applications than Java applets. The additional privileges granted to ActiveX controls makes them a more attractive target for those looking to perform malicious activities.

Understanding ActiveX Attacks

Over the past few years, there has been a rapid increase in the use and subsequent exploitation of ActiveX controls. Many technologies and tools such as social networking websites Facebook and Myspace, applications such as Yahoo’s Music Jukebox, Real Network’s RealPlayer, and Apple’s QuickTime, have succumbed to ActiveX exploitation. The wide use of ActiveX attests to its position as a security target for vulnerability research, leading to the identification of security holes and exploits.

Although ActiveX controls are built into the Microsoft operating system and Internet Explorer, it is important to note that applications may install their own ActiveX controls to provide unique functionality through Internet Explorer. In addition, web sites install ActiveX controls. An example of this is often seen in Shockwave Flash, where a pop-up window prompts the user to install the Shockwave ActiveX control.

ActiveX controls are typically identified by their class identifier (CLSID). The CLISID is a unique value associated with each control to differentiate it from other controls. A CLSID key also exists. This key contains information used by the default COM handler to return information about a class when it is in the running state. Within the CLSID key, there are thousands of class identifiers, each specifying ActiveX controls. The unique string used for each CLSID is referred to as the globally unique identifier (GUID), which programmers often use a utility called Guidgen.exe to generate. There are websites available that list CLSIDs and what they refer to, two of which are listed below:

On devices running the Windows operating system, a list of all existing CLSIDs can be found at the following registry location:


Only a specific subset of these class identifiers can be instantiated by a website, because the CLSIDs must be marked as safe and categorized as such. An example of this is evident with controls that are marked as safe for scripting. A list of CLSIDs that contain this ability can be found at the following registry location:

HKEY_CLASSES_ROOT\CLSID\<control clsid>\Implemented Categories

The other manner in which ActiveX controls are identified is by the ActiveX control’s program identifier (ProgID). The ProgID and CLSID relationship can be compared to the relationship of an IP (Internet Protocol) address as it interacts with DNS (domain name system). Essentially, the ProgIDs can be looked up to determine the correlating CLSID. This interaction is seamless to Internet Explorer, thus it proceeds as if the CLSID had been initially provided (Warlord 2008, 4).

There are many forms of ActiveX attacks. Many of these attacks consist of a wide range of exploits. One such form is the ability to capitalize on remote code execution. Using remote code execution, an attacker can build a specially crafted web page, which would use the vulnerable ActiveX control in a user’s browser to perform remote code execution, potentially resulting in the complete control of the affected system.

Detecting and Preventing ActiveX Exploitation

To detect attempts to exploit vulnerable ActiveX controls, employ the proper use of detection tools such as the following:

  • Microsoft OLE/COM object viewer, used to gather object information, methods, interface data, and other host properties,
  • Registry Monitor, used to monitor the registry for changes by applications and ActiveX functions,
  • TCPView, used to analyze TCP and UDP ports being opened and correlate with known exploits,
  • Microsoft Windows Debugger, used to detect ActiveX execution and buffer overflows,
  • Host-based intrusion prevention systems (HIPS) such as Cisco Security Agent (CSA).

See the Additional Information section of this document for links and details regarding the aforementioned tools.

In addition, the OleView tool can be run to determine if an ActiveX control is marked as safe or not.

In regards to testing potential vulnerabilities, the use of fuzzers can be employed. Fuzzers provide a technique to send random data to the inputs of a program. The results of the fuzzer testing can then be noted and implemented for future use in mitigation actions. ActiveX fuzzers such as H.D. Moore’s Axman and iDefense’s ComRaider are two fuzzers that have the ability to provide a database of controls that Internet Explorer can recognize (Warlord 2008, 4).

To reduce the likelihood that vulnerable ActiveX controls will be exploited, the proper safeguards must be implemented. The following Cisco firewall devices can implement mitigation techniques to prevent exploitation of vulnerable ActiveX controls:

  • Cisco ASA 5500 Series Adaptive Security Appliance (ASA)
  • Cisco PIX 500 Series Security Appliance
  • Firewall Services Module (FWSM) for Cisco Catalyst 6500 Series switches and Cisco 7600 Series routers

Leveraging Regular Expressions

A regular expression matches text strings either literally as an exact string or by using metacharacters. Using metacharacters with a regular expression allows a single regex to match multiple variants of a text string. You can use a regular expression to match the content of certain application traffic; for example, you can match a URL string inside an HTTP packet.

Use Ctrl+V to escape characters that have special meaning to the CLI, such as question mark (?) or a tab. For example, type d[Ctrl+V]?g to enter d?g in the configuration. The following table describes the metacharacters often used with application layer protocol inspection. For a more extensive table, refer to the regex Metacharaters table in the Cisco Security Appliance Command Reference.

Table 1. Common Application Layer Protocol Inspection Regex Metacharacters

Metacharacter Description Example Explanation

[ ]

Character class


Matches a single lower case letter (a-z) or a single digit.

[^ ]

Negated character class


Matches any character that is not an ‘A’ or an ‘a’.




Matches either the lower case string ‘pix’ or the lower case string ‘asa’.


Quantifier, zero or one occurrences of previous expression


Matches zero or one upper case letter.


Quantifier, zero or more occurrences of previous expression


Matches zero or more digits.


Quantifier, at least one of previous expression


Matches a string made up of the letters ‘a’, ‘b’, or ‘c’ and the numbers 1 through 3.

{min) or (min,}

Quantifier, minimum repeat


Matches a string made up of the letter ‘A’three times.


Matches a single character


Matches any four characters followed by the number 4.


Escape character


Escapes the period character so that it matches a period and does not act as a wildcard.


Byte value as hex


Matches a byte containing 20 hex (a space) or a URL-encoded space (+).

Many regex options exist that aid in preventing ActiveX controls. A scale of samples exemplifying example progressions of basic regular expressions to some of the more advanced options follows:

Regex example 1: “My favorite color is (green|blue)”

Example 1 shows an exact match (including case and spaces) for the words “My favorite color is ”. The “( )” metacharacter indicates a subexpression that segregates characters and phrases from other characters so that specific actions can be taken on these characters or phrases in isolation. In this case, it isolates the words green and blue. The “|” metacharacter is an alternation indicating the regex will match either expression separated by it. In this case, the “|” separates the words “ green” and “blue”, thus, the regex will match on either of the following statements:

  • “My favorite color is green”
  • “My favorite color is blue”

Regex example 2: “[Mm]y favorite color is ([a-zA-Z]+)\.”

In example 2, the word “my” can be uppercase or lowercase as indicated by the [Mm], which indicates a match on either “M”or “m”. Example 2 reflects an exact match (including case and spaces) for the phrase “ favorite color is ”. The “( )” isolate a subexpression. The “[a-zA-Z]” metacharacter represents a character range class that means match any character in the range stated in the brackets. In this example, it means match any uppercase characters “A-Z” or lowercase characters “a-z”. The “+” metacharacter indicates that there is at least one of the previous expression. In example 2, there is at least one of the expression “[a-zA-Z]”. The “\” represents an escape character; in example 2, it escapes the period (.) indicating that the text to be matched must end with a period (.). The regex example 2 will match a statement specifying any color specified in upper or lowercase and using an upper or lowercase “my” as follows:

  • “My favorite color is brown.”
  • “my favorite color is brown.”
  • “My favorite color is Orange.”
  • “my favorite color is router.”

It is important to note the possibility of unintended matches, as shown in the last statement above.

Regex example 3: “[Mm][Yy](\x20|\x2b)[Ff][Aa][Vv][Oo][Rr][Ii][Tt][Ee](\x20|\x2b)[Cc][Oo][Ll][Oo][Rr](\x20|\x2b)[Ii][Ss](\x20|\x2b)([^\s]+?)[.!]”

In example 3, the “[Mm][Yy]” allows the use of the word “my” in upper and lowercase. The string “(\x20|\x2b)” matches the ASCII hexadecimal integer “20” or “2b” as the metacharacter “\xNN” represents an escaped two-digit hexadecimal number. The “|” is the alternation metacharacter indicating a match of either said option. The string “[Ff][Aa][Vv][Oo][Rr][Ii][Tt][Ee]” specifies a match on the word “favorite” in upper or lowercase. The string “(\x20|\x2b)” again matches either ASCII hexadecimal integer “20 or 2b”. The string “[Cc][Oo][Ll][Oo][Rr]” matches the upper or lowercase syntax of the word “color”. Again, either integer “20 or 2b” is matched. The string “[Ii][Ss]” indicates a match of the word “is” in uppercase or lowercase followed by a match on either “20 or 2b”. In the string “([^\s]+?)”, the expression “[^\s]” indicates a match on a negated character class, meaning a match on a character NOT contained in the brackets. In example 3, the “[^\s]” matches any character other than whitespace such as a space or tab. The “+” is a quantifier indicating that there is at least one of the previous expression. In example 3, the “+” indicates that there is at least one iteration of the expression “[^\s]”. In this context, the “?” indicates that the previous quantifier should match as few characters as possible. This action is called non-greedy matching. Lastly, the expression “[.!]” simply indicates a match on any single character in the “[ ]”, thus either a “.” or “!” in example 3. The use of a “.” in a character class is a special-case; when used in this manner, the “.” does not act as a metacharacter and will only match a period. With this being the case, the regex for example 3 matches any of the following options:

  • “My favorite color IS red!”
  • “my favorite color is red.”
  • “My favorite color is BLUE!”
  • “mY+forORITE cO|Or+iS layer-3-switch!”

It should be noted that a regular expression must consider any possible permutation of the data to be matched.

Firewall Application Layer Protocol Inspection

Caution: Application layer protocol inspection will decrease firewall performance. Performance impact should be tested in a lab environment before deployment in production environments.

The invocation of ActiveX controls can also be filtered using application layer protocol inspection and regular expressions on Cisco ASA, FWSM, and PIX firewalls. Regular expressions within application layer protocol inspection are supported on the PIX and ASA firewalls beginning with software version 7.2.1 and on the FWSM with software version 4.0.1 and later.

When vulnerabilities are found in ActiveX controls, the vendor typically discloses the specific vulnerable ActiveX CLSID or ProgID values. If these details are provided, the use of regular expressions can be employed within the application layer protocol inspection engine to identify specific strings in a packet and perform specific actions on this traffic as defined by the inspection policy.

Application layer protocol inspection is used for services that embed IP addressing information in the data packet, open secondary channels on dynamically assigned ports, and that require a deep packet inspection. The firewall must analyze each session of the protocol to properly identify the dynamic ports and permit the data exchange accordingly. There are numerous applications that use the application layer protocol inspection engine, including HTTP.

For a listing of the applications supported by application layer protocol inspection, and their supporting details, refer to “Supported Application Inspection Engines” under the Default Inspection Policy section of the Cisco Security Appliance Command Line Configuration Guide.

The inspection policy will leverage two regular expressions to identify packets containing the CLSID or ProgID of the CA BrightStor ActiveX control. The HTTP application layer protocol inspection will drop connections where the HTTP response body contains either the CLSID or ProgID of the Brightstor ActiveX control.

Caution: The configured regular expressions may match on any text strings within the body of a HTTP response. Care should be taken to ensure that business legitimate applications that use matching text strings without calling the ActiveX control are not impacted.

The following configuration example may be applied to PIX, ASA, or FWSM firewalls.

   function makeRegex(input){
    input = input.toLowerCase();
    var output = new String();
    for (var i = 0; i < input.length ;i += 1){
     if (input.charAt(i).match(/[a-z]/)){
      output += "[" + input.charAt(i).toUpperCase() + input.charAt(i) + "]";
     } else if (input.charAt(i).match(/\d/)){
      output += input.charAt(i);
     } else if (input.charAt(i) == '-'){
      output += "[-]";
     } else if (input.charAt(i) == '.'){
      output += "\\.";
     } else if (input.charAt(i).match(/\s/)){
      output += "(\\x2b|\\x20)";
     } else {
      output += "\\x" + input.charCodeAt(i).toString(16);
    return output;
   function buildConfig() {
    var clsid = new String(document.dynamicConfigForm.clsid.value);
    var progid = new String(document.dynamicConfigForm.progid.value);
    document.getElementById('clsidRegex').firstChild.nodeValue = '"' + makeRegex(clsid) + '"';
    document.getElementById('progidRegex').firstChild.nodeValue = '"' + makeRegex(progid) + '"';
    document.getElementById('intro').firstChild.nodeValue = "!\n\r!-- Configure regular expressions for the ActiveX Class ID\n\r!-- (" + clsid + ") and Prog ID\n\r!-- (" + progid + ") associated with the\n\r!-- vulnerable ActiveX control";

Cisco's Applied Intelligence team has incorporated a tool below which will aid with the building of regular expressions and the subsequent ASA regex configuration.

The following configuration example blocks the vulnerable CA Brightstor ActiveX control using a CLSID of BF6EFFF3-4558-4C4C-ADAF-A87891C5F3A3 and a ProgId of LISTCTRL.ListCtrlCtrl.1.

Please use the following two fields to generate a configuration example specific to the ActiveX control you want to block. This information is available in the IntelliShield alert or vendor response.

CLSID  ProgID  Create Custom Configuration Example

! !-- Configure regular expressions for the ActiveX Class ID !-- BF6EFFF3-4558-4C4C-ADAF-A87891C5F3A3 and Prog ID !-- LISTCTRL.ListCtrlCtrl.1 associated with the !-- CA Brightstor ActiveX control !-- *Class ID: BF6EFFF3-4558-4C4C-ADAF-A87891C5F3A3 !-- *Program ID: LISTCTRL.ListCtrlCtrl.1
regex CLSID_activeX
regex ProgID_activeX
! Note: A best practice for defining regular expressions is to define unique names. For example, name them according to the specific ActiveX control being filtered, this will eliminate the possiblity of overwriting previously defined expressions. ! !-- Configure a regex class to match on the regular expressions !-- configured above. Note the “match-any” vs “match-all”. !-- Match-any identifies a packet as matching as long as one of the !-- regular expressions match. Match-all requires that all stated !-- expressions be matched for a packet to be placed in the class. ! Note: If either the CLSID or ProgID is unknown or should either change, the use of the match-any is important due to the fact that it will allow the match on either parameter. ! class-map type regex match-any regex-class match regex CLSID_activeX match regex ProgID_activeX ! !-- Configure an HTTP inspection class to search HTTP response !-- bodies for the regular expressions contained in the above !-- regex class. ! class-map type inspect http match-all vulnerable-activex-class match response body regex class regex-class ! !-- The following HTTP inspection uses the Modular Policy !-- Framework (MPF) to create a policy for inspection of traffic !-- on TCP ports 80 (www), 3128, 8000, 8010, 8080, 8888, and !-- 24326, which define the default ports used by the !-- WEBPORTS variable. ! !-- Configure an object-group for the default ports used by the !-- Cisco IPS #WEBPORTS variable. ! object-group service WEBPORTS tcp port-object eq www port-object eq 3128 port-object eq 8000 port-object eq 8010 port-object eq 8080 port-object eq 8888 port-object eq 24326 ! Note: In ASA and PIX versions 8.x and later, the object-group configuration can be performed using the “service-group” feature, which is introduced in 8.x. The configuration above is based on the 7.2.x command line syntax, which will also work on 8.x and later. ! !-- Configure an access-list that utilizes the WEBPORTS object- !-- group, which will be used to match TCP packets destined to !-- #WEBPORTS. ! access-list DEFINED-IPS-WEBPORTS extended permit tcp any any object-group WEBPORTS ! !-- Configure a class that uses !-- the above configured access-list to match !-- TCP packets destined to the ports referenced by the Cisco !-- IPS #WEBPORTS variable. ! class-map MATCHING-WEBPORTS match access-list DEFINED-IPS-WEBPORTS ! !-- Configure an HTTP inspection policy that drops !-- connections containing HTTP protocol violations and !-- drops connections containing the regular expression for the !-- affected ActiveX Class ID or Program ID configured above. ! !--“protocol-violation” below is not required to !-- mitigate ActiveX controls but is !-- included to provide more robust protection against !-- potential HTTP attacks. Care should be taken to ensure that !-- legitimate applications that do not fully conform to !-- HTTP protocol standards are not dropped by this inspection. ! policy-map type inspect http http-policy parameters protocol-violation action drop-connection class vulnerable-activex-class drop-connection log ! !-- Add the preceding configured classes that match TCP packets !-- destined to default Cisco IPS #WEBPORTS to the default !–- policy “global_policy” and use it to inspect HTTP traffic !-- transiting the firewall. ! policy-map global_policy class MATCHING-WEBPORTS inspect http http-policy ! !-- By default, the policy “global_policy” is applied globally, !-- which results in the inspection of traffic entering the !-- firewall from all interfaces. ! service-policy global_policy global

To verify the application layer protocol inspection and regex configuration, use the test regex and show service-policy commands as seen below:

firewall(config)# test regex yahOO yahoo 
INFO: Regular expression match failed.
firewall(config)# test regex brightstor brightstor
INFO: Regular expression match succeeded.
firewall(config)# test regex Cisco Cisco
INFO: Regular expression match succeeded.
Note:  For additional information about the test regex command, refer to the 
Cisco Security Appliance Command Reference.
!-- To verify the statistics of the application layer protocol 
!-- inspection use the “show service-policy” command which is 
!-- applied globally by default.

firewall# show service-policy  
Global policy: 
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns preset_dns_map, packet 0, drop 0, reset-drop 0
      Inspect: ftp, packet 0, drop 0, reset-drop 0
      Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0
      Inspect: netbios, packet 0, drop 0, reset-drop 0
      Inspect: rsh, packet 0, drop 0, reset-drop 0
      Inspect: rtsp, packet 0, drop 0, reset-drop 0
      Inspect: skinny , packet 0, drop 0, reset-drop 0
      Inspect: esmtp _default_esmtp_map, packet 0, drop 0, reset-drop 0
      Inspect: sqlnet, packet 0, drop 0, reset-drop 0
      Inspect: sunrpc, packet 0, drop 0, reset-drop 0
      Inspect: tftp, packet 0, drop 0, reset-drop 0
      Inspect: sip , packet 0, drop 0, reset-drop 0
      Inspect: xdmcp, packet 0, drop 0, reset-drop 0
      Inspect: http http-policy, packet 612, drop 203,  reset-drop 0
        protocol violations
          packet 210
        class vulnerable-activex-class
          drop-connection log, packet 203

!-- For more granularity specify the specific inspection 
!-- (HTTP) policy as follows:
firewall# show service-policy inspect http
Global policy: 
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: http http-policy, packet 612, drop 203, reset-drop 0
        protocol violations
          packet 210
        class vulnerable-activex-class
          drop-connection log, packet 203
!-- Syslogs can also be used to verify the activex control is  
!-- matched and thus discarded. System log message 415007 is 
!-- generated when the message body matches the regular 
!-- expression that has been configured. 

firewall#show logging | grep 415007
  May 28 2008 15:26:43: %ASA-5-415007: HTTP - matched Class 26: 
         MATCHING-WEBPORTS in policy-map http-policy, Body matched - 
         Dropping connection from outside: 
         to inside:
  May 28 2008 15:28:04: %ASA-5-415007: HTTP - matched Class 26:
         MATCHING-WEBPORTS in policy-map http-policy, Body matched - 
         Dropping connection from outside: 
         to inside:

For further information regarding the system log message 415007, refer to the log message in the Cisco Security Appliance System Log Messages documentation.


The ability to understand protocols is essential for administrators and engineers to properly detect and prevent attacks. Application developers have increased their reliance on protocols, technological concepts, and tools such as ActiveX. It is imperative that administrators and engineers understand the numerous aspects and implications of ActiveX controls and the technology, including the configuration solutions required to prevent these attacks.


Andrae Middleton (
Security Intelligence Engineer

Andrae Middleton is a member of the Security Intelligence Engineering organization at Cisco. Additional content produced by Security Intelligence Engineering is located in the Security Intelligence Best Practices section of Cisco Security Intelligence Operations.

Additional Information

Microsoft OLE/COM Object Viewer

Microsoft RegMon




Microsoft Windows Debugger


Felten, Edward W. “Security Tradeoffs: Java vs. ActiveX.” April 28, 1997.

n.a. “Microsoft Announces ActiveX Technologies.” March, 12, 1996.

Warlord. “ActiveX Active Exploitation.” January, 2008.

This document is part of Cisco Security Research & Operations.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

Back to Top