Contents
Cisco Response
Device-Specific Mitigation and Identification
Additional Information
Cisco Security Procedures
Cisco Response
This Applied Mitigation Bulletin provides techniques that administrators can deploy on Cisco network devices to identify and mitigate the Bobax and Kraken botnet.
Vulnerability Characteristics
Hosts that are compromised by the Bobax worm attempt to join the Kraken botnet Command and Control (C&C) network via TCP and UDP ports 447 and TCP port 13789. Once the hosts have been compromised, these hosts can be used for malicious activities.Reports indicate that the malware has updated itself and now uses HTTP or HTTPS for C&C communication. The details, in this document provide information for older variants that utilize the older C&C network communication. Some of these techniques may still provide some mitigation, depending on the situation. Often these activities are to send spam or perform denial of service (DoS) attacks.
The attack vector for exploitation is through social engineering that requires user interaction on client systems.
The vectors for C&C network access is through TCP and UDP ports 447 and TCP port 13789 to a set of predetermined fully qualified domain names (FQDNs).
Details of this vulnerability are described in IntelliShield Alert 7670.
Mitigation Technique Overview
Cisco devices provide several countermeasures to defeat Bobax worm access to the Kraken botnet C&C network. Administrators are advised to consider these protection methods to be general security best practices for infrastructure devices and the traffic that transits the network. This section of the document provides an overview of these techniques.
Once an endpoint host has been compromised, the host will attempt to establish communications with the botnet C&C by contacting a series of hosts using the FQDN on TCP and UDP ports 447 and TCP port 13789. This communication can be prevented through the use of transit access control lists (tACLs) deployed on firewalls or routers.
Additionally, this communication may be stopped by preventing the resolution of the Kraken-related FQDNs via DNS. DNS-based mitigation is best performed via the DNS server; however, in cases in which an enterprise does not have control over its DNS, this can be accomplished by using the DNS application inspection capabilities of Cisco ASA and FWSM firewalls. Note that tACLs are more effective mitigation than DNS resolution-based mitigation and that only one of these methods (tACLs or DNS) needs to be performed. Additionally, DNS-based mitigation may prevent communication with legitimate hosts that are located within the blocked domains.
Cisco IOS Software can provide effective means of preventing access to the Kraken botnet C&C network via transit access control lists.
This protection mechanism filters and drops packets that attempt to connect to the Kraken botnet C&C network.
Effective use of Cisco Intrusion Prevention System (IPS) event actions provides visibility into exploited hosts that are attempting to connect to the C&C network as discussed in this document.
Effective means of exploit prevention can also be provided by Cisco ASA 5500 Series Adaptive Security Appliance, Cisco PIX 500 Series Security Appliance, and the Firewall Services Module (FWSM) for Cisco Catalyst 6500 Series switches and Cisco 7600 Series routers using the following:
- Transit access control lists (tACLs)
- Application layer protocol inspection
Note: The regular expression capabilities for application layer protocol inspection are not currently available for the FWSM.
These protection mechanisms filter and drop packets that attempt to connect to the Kraken botnet C&C network.
Cisco IOS NetFlow can provide visibility into network-based exploitation attempts using flow records.
Cisco IOS Software, Cisco ASA, Cisco PIX security appliances, and FWSM firewalls can provide visibility through syslog messages and the counter values that are displayed in the output from show commands.
The Cisco Security Monitoring, Analysis, and Response System (Cisco Security MARS) appliance can also provide visibility through incidents, queries, and event reporting.
Risk Management
Organizations are advised to follow their standard risk evaluation and mitigation processes to determine the potential impact of the worm. Triage refers to sorting projects and prioritizing efforts that are most likely to be successful. Cisco has provided documents that can help organizations develop a risk-based triage capability for their information security teams. Risk Triage for Security Vulnerability Announcements and Risk Triage and Prototyping can help organizations develop repeatable security evaluation and response processes.
Device-Specific Mitigation and Identification
Caution: The effectiveness of any mitigation technique depends on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.
Specific information about mitigation and identification is available for these devices:
Cisco IOS Routers and Switches
Mitigation: Transit Access Control Lists
To prevent compromised hosts from contacting the C&C network, administrators are advised to deploy transit access control lists (tACLs) to perform policy enforcement. Administrators can construct a tACL by explicitly permitting only authorized traffic to enter or exit the network at ingress access points or permitting authorized traffic to transit the network in accordance with existing security policies and configurations. To effectively block communication to the Kraken botnet, it is imperative that administrators apply this tACL to traffic exiting an organization.
The tACL policy denies unauthorized packets on TCP and UDP port 447 and TCP port 13789. Care should be taken to allow required traffic for routing and administrative access prior to denying all unauthorized traffic.
Additional information about tACLs is available in Transit Access Control Lists: Filtering at Your Edge.
!-- Include any explicit permit statements for trusted sources
!-- that require access on the ports to be blocked
!
access-list 150 permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 447
access-list 150 permit udp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 447
access-list 150 permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 13789
!
!-- The following vulnerability-specific access control entries
!-- (ACEs) can aid in identification of infected hosts
!
access-list 150 deny tcp any any eq 447
access-list 150 deny udp any any eq 447
access-list 150 deny tcp any any eq 13789
!
!-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance
!-- with existing security policies and configurations
!
!-- Explicit deny for all other IP traffic
!
access-list 150 deny ip any any
!
!-- Apply tACL to interfaces in the ingress direction
interface GigabitEthernet0/0
ip access-group 150 in
!
Note: Filtering with an interface access list will elicit the transmission of ICMP unreachable messages back to the source of the filtered traffic. Generating these messages could have the undesired effect of increasing CPU utilization on the device. In Cisco IOS Software, ICMP unreachable generation is limited to one packet every 500 milliseconds by default. ICMP unreachable message generation can be disabled using the interface configuration command no ip unreachables. ICMP unreachable rate limiting can be changed from the default using the global configuration command ip icmp rate-limit unreachable interval-in-ms.
Identification: Transit Access Control Lists
After the administrator applies the tACL to an interface, the show ip access-lists command will identify the number of packets on TCP and UDP port 447 and TCP port 13789 that have been filtered. Administrators are advised to investigate filtered packets to determine whether they are related to the Bobax worm. Example output for show ip access-lists 150 follows:
show ip access-lists 150
Extended IP access list 150
10 permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 447
20 permit udp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 447
30 permit tcp host 192.168.100.1 192.168.60.0 0.0.0.255 eq 13789
40 deny tcp any any eq 447 (6 matches)
50 deny udp any any eq 447
60 deny tcp any any eq 13789 (10 matches)
70 deny ip any any
In the preceding example, access list 150 has dropped the following packets that were received from an untrusted host or network:
- 6 packets on TCP port 447 for ACE line 40
- 10 packets on TCP port 13789 for ACE line 60
For additional information about investigating incidents using ACE counters and syslog events, reference the Identifying Incidents Using Firewall and IOS Router Syslog Events Applied Intelligence white paper.
Administrators can use Embedded Event Manager to provide instrumentation when specific conditions are met such as ACE counter hits. The Applied Intelligence white paper Embedded Event Manager in a Security Context provides additional details about how to use this feature.
Identification: Access List Logging
The log and log-input access control list (ACL) option will cause packets that match specific ACEs to be logged. The log-input option enables logging of the ingress interface in addition to the packet source and destination IP addresses and ports.
Caution: Access control list logging can be very CPU intensive and must be used with extreme caution. Factors that drive the CPU impact of ACL logging are log generation, log transmission, and process switching to forward packets that match log-enabled ACEs.
For Cisco IOS Software, the ip access-list logging interval interval-in-ms command can limit the effects of process switching induced by ACL logging. The logging rate-limit rate-per-second [except loglevel] command limits the impact of log generation and transmission.
The CPU impact from ACL logging can be addressed in hardware on the Cisco Catalyst 6500 Series switches and Cisco 7600 Series routers with Supervisor Engine 720 or Supervisor Engine 32 using optimized ACL logging.
For additional information about the configuration and use of ACL logging, reference the Understanding Access Control List Logging Applied Intelligence white paper.
Cisco IOS NetFlow
Identification: Traffic Flow Identification Using NetFlow Records
Administrators can configure Cisco IOS NetFlow on Cisco IOS routers and switches to aid in the identification of traffic flows that may be attempts to connect to the Command and Control network. Administrators are advised to investigate flows to determine whether they are compromised hosts attempting to connect to the Kraken botnet C&C network or whether they are legitimate traffic flows.
show ip cache flow
IP packet size distribution (14812776 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .393 .379 .026 .024 .028 .019 .003 .001 .001 .002 .002 .003 .001 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.014 .000 .004 .034 .056 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes
48 active, 65488 inactive, 770860 added
30953893 ager polls, 0 flow alloc failures
Active flows timeout in 2 minutes
Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
30 active, 16354 inactive, 399953 added, 399953 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 7219 0.0 11 47 0.0 5.9 6.1
TCP-FTP 417 0.0 4 53 0.0 6.9 31.6
TCP-FTPD 57 0.0 4022 705 0.2 36.0 1.2
TCP-WWW 31040 0.0 6 353 0.1 8.5 48.1
TCP-SMTP 275 0.0 7 147 0.0 7.4 12.0
TCP-BGP 373 0.0 4 44 0.0 14.0 60.5
TCP-other 514294 0.4 20 191 10.1 5.7 9.2
UDP-DNS 21861 0.0 5 72 0.1 47.2 39.7
UDP-NTP 128503 0.1 1 76 0.1 5.3 58.3
UDP-other 37177 0.0 74 85 2.6 34.6 46.3
ICMP 12956 0.0 4 128 0.0 32.3 46.2
GRE 16641 0.0 27 60 0.4 119.9 0.5
Total: 770813 0.7 19 174 14.0 11.3 22.1
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 11 0978 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 11 0979 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 11 0975 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0976 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 11 0977 01BF 1
Gi0/0 192.168.208.63 Gi0/1 192.168.150.60 06 87B7 0016 191
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0016 35DD 124
Gi0/0 192.168.208.63 Gi0/1 192.168.150.60 01 0000 0303 30
Gi0/0 10.21.80.131 Gi0/1 192.168.130.41 06 FF69 01BB 12
Gi0/1 192.168.202.22 Gi0/0 192.88.226.10 11 007B 007B 1
Gi0/1 192.168.128.21 Gi0/0 10.88.226.10 11 007B 007B 1
Gi0/1 192.168.128.23 Gi0/0 10.88.226.10 11 007B 007B 1
Gi0/1 192.168.146.4 Gi0/0 10.88.226.10 11 007B 007B 1
Gi0/1 192.168.150.60 Gi0/0 172.18.104.132 06 D7ED 1A29 2
In the preceding example, there are multiple flows for TCP port 447 (hex value 01BF) and TCP port 13789 (hex value 35DD).
To view only the traffic flows for TCP and UDP port 447 (hex value 01BF), the command show ip cache flow | include SrcIf|(01BF|35DD) will display the related UDP and TCP NetFlow records.
show ip cache flow | include SrcIf|(01BF|35DD)
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 11 0978 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 11 0979 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 11 0975 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0976 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0977 01BF 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0852 35DD 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0853 35DD 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0850 35DD 1
Gi0/1 192.168.150.60 Gi0/0 192.168.208.63 06 0851 35DD 1
Cisco ASA, PIX, and FWSM Firewalls
Mitigation: Transit Access Control Lists
To prevent compromised hosts from contacting the C&C network, administrators are advised to deploy transit access control lists (tACLs) to perform policy enforcement. Administrators can construct a tACL by explicitly permitting only authorized traffic to enter or exit the network at ingress access points or permitting authorized traffic to transit the network in accordance with existing security policies and configurations. To effectively block communication to the Kraken botnet, it is imperative that administrators apply this tACL to traffic exiting an organization.
The tACL policy denies unauthorized packets on TCP and UDP port 447 and TCP post 13789. Care should be taken to allow required traffic for routing and administrative access prior to denying all unauthorized traffic.
Additional information about tACLs is available in Transit Access Control Lists: Filtering at Your Edge.
!
!-- Include any explicit permit statements for trusted sources
!-- that require access on the ports to be blocked
!
access-list tACL-Policy extended permit tcp host 192.168.100.1
192.168.60.0 255.255.255.0 eq 447
access-list tACL-Policy extended permit udp host 192.168.100.1
192.168.60.0 255.255.255.0 eq 447
access-list tACL-Policy extended permit tcp host 192.168.100.1
192.168.60.0 255.255.255.0 eq 13789
!
!-- The following vulnerability-specific access control entries
!-- (ACEs) can aid in identification of infected hosts
!
access-list tACL-Policy extended deny tcp any any eq 447
access-list tACL-Policy extended deny udp any any eq 447
access-list tACL-Policy extended deny tcp any any eq 13789
!
!-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance
!-- with existing security policies and configurations
!
!-- Explicit deny for all other IP traffic
!
access-list tACL-Policy extended deny ip any any
!
!-- Apply tACL to interface(s) in the ingress direction
!
access-group tACL-Policy in interface inside
!
Mitigation: Application Layer Protocol Inspection
Application layer protocol inspection is available beginning in software release 7.0 for the Cisco ASA 5500 Series Adaptive Security Appliance or the Cisco PIX 500 Series Security Appliance and in software release 3.1 for the Firewall Services Module. This advanced security feature performs deep packet inspection of traffic that is transiting through the firewall. Administrators may construct an inspection policy for applications that require special handling through the configuration of inspect class maps and inspect policy maps, which are applied via a global or interface service policy. The following policy uses regular expression capabilities that are available beginning in software release 7.2 for Cisco ASA 5500 Series Adaptive Security Appliance or the Cisco PIX 500 Series Security Appliance.
Additional information about application layer protocol inspection is available in Configuring Application Layer Protocol Inspection.
Caution: Legitimate domains use these DNS services. Denying access to the top-level domain will deny access to legitimate domains. Administrators should determine whether any of these domains are required for business applications.
Caution: Application layer protocol inspection will decrease firewall performance. Performance impact should be tested in a lab environment before deployment in production environments.
This Modular Policy Framework (MPF) policy inspects all DNS traffic and will apply the configured actions and parameters:
! -- Match domains of known C&C hosts
regex domain1 [Mm][Oo][Oo][Oo]\.[Cc][Oo][Mm]
regex domain2 [Yy][Ii]\.[Oo][Rr][Gg]
regex domain3 [Dd][Yy][Nn][Dd][Nn][Ss]\.[Oo][Rr][Gg]
regex domain4 [Dd][Yy][Nn][Ss][Ee][Rr][Vv]\.[Cc][Co][Mm]
! -- Create regex class map to match on regular expression configured above
class-map type regex match-any bobax_kraken_domains
match regex domain1
match regex domain2
match regex domain3
match regex domain4
! -- Configure DNS inspection class
class-map type inspect dns bobax_kraken_query
match not header-flag QR
match question
match
domain-name regex class bobax_kraken_domains
! -- Configure DNS inspection policy
policy-map type inspect dns bobax_kraken_drop
class bobax_kraken_query
drop log
!
class-map inspection_default
match default-inspection-traffic
!
policy-map
global_policy
class inspection_default
inspect dns bobax_kraken_drop
! -- Apply policy
service-policy global_policy global
!
Identification: Transit Access Control Lists
After the tACL has been applied to an interface, administrators can use the show access-list command to identify the number of packets on TCP and UDP ports 447 and TCP port 13789 that have been filtered. Administrators are advised to investigate filtered packets to determine whether they are attempts from compromised hosts to join the Kraken botnet C&C network. Example output for show access-list tACL-Policy follows:
firewall# show access-list tACL-Policy
access-list tACL-Policy; 6 elements
access-list tACL-Policy line 1 extended permit tcp host 192.168.100.1
192.168.60.0 255.255.255.0 eq 447 (hitcnt=0)
access-list tACL-Policy line 2 extended permit udp host 192.168.100.1
192.168.60.0 255.255.255.0 eq 447 (hitcnt=0)
access-list tACL-Policy line 3 extended permit tcp host 192.168.100.1
192.168.60.0 255.255.255.0 eq 13789 (hitcnt=0)
access-list tACL-Policy line 4 extended deny tcp any any eq 447 (hitcnt=6)
access-list tACL-Policy line 5 extended deny udp any any eq 447 (hitcnt=0)
access-list tACL-Policy line 6 extended deny tcp any any eq 13789 (hitcnt=0)
In the preceding example, access list tACL-Policy has dropped 6 packets on TCP port 447 that are destined to untrusted hosts. In addition, syslog message 106023 can provide valuable information, including the source and destination IP address, the source and destination port numbers, and the IP protocol for the denied packet.
Identification: Firewall Access List Syslog Messages
Firewall syslog message 106023 will be generated for packets that are denied by an access control entry (ACE) that does not have the log keyword present. Additional information about this syslog message is available in Cisco Security Appliance System Log Message - 106023.
Information about configuring syslog for the Cisco ASA 5500 Series Adaptive Security Appliance or the Cisco PIX 500 Series Security Appliance is available in Configuring Logging on the Cisco Security Appliance. Information about configuring syslog on the FWSM for Cisco Catalyst 6500 Series switches and Cisco 7600 Series routers is available in Configuring Monitoring and Logging on the Cisco FWSM.
In the following example, the show logging | grep regex command extracts syslog messages from the logging buffer on the firewall. These messages provide additional information about denied packets that could indicate potential attempts to exploit the C&C network described in this document. It is possible to use different regular expressions with the grep keyword to search for specific data in the logged messages.
Additional information about regular expression syntax is available in Using the Command Line Interface.
firewall#show logging | grep 106023
Apr 09 2008 14:41:12: %ASA-4-106023:
Deny tcp src inside:192.168.150.60/40806
dst outside:192.168.208.63/447 by
access-group "tACL-Policy"
Apr 09 2008 14:41:13: %ASA-4-106023:
Deny tcp src inside:192.168.150.60/40807
dst outside:192.168.208.63/447 by
access-group "tACL-Policy"
Apr 09 2008 14:41:14: %ASA-4-106023:
Deny tcp src inside:192.168.150.60/40808
dst outside:192.168.208.63/447 by
access-group "tACL-Policy"
Apr 09 2008 14:41:15: %ASA-4-106023:
Deny tcp src inside:192.168.150.60/40809
dst outside:192.168.208.63/447 by
access-group "tACL-Policy"
firewall#
In the preceding example, the messages logged for the tACL Transit-ACL-Policy show packets for TCP port 447 sent to the addresses with an outside destination.
Additional information about syslog messages for ASA and PIX security appliances is available in Cisco Security Appliance System Log Messages. Additional information about syslog messages for the FWSM is available in Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Logging Configuration and System Log Messages.
For additional information about investigating incidents using syslog events, reference the Identifying Incidents Using Firewall and IOS Router Syslog Events Applied Intelligence white paper.
Identification: Application Layer Protocol Inspection
Firewall syslog message 410003 will be generated when an HTTP message body matches a user-defined regular expression. The syslog message will identify the corresponding DNS class and DNS policy and indicate the action applied to the HTTP connection. Additional information about this syslog message is available in Cisco Security Appliance System Log Message - 410003.
Information about configuring syslog for the Cisco ASA 5500 Series Adaptive Security Appliance or the Cisco PIX 500 Series Security Appliance is available in Configuring Logging on the Cisco Security Appliance. Information about configuring syslog on the FWSM for Cisco Catalyst 6500 Series switches and Cisco 7600 Series routers is available in Configuring Monitoring and Logging on the Cisco FWSM.
In the following example, the show logging | grep regex command extracts syslog messages from the logging buffer on the firewall. These messages provide additional information about denied packets that could indicate potential attempts to exploit the C&C network described in this document. It is possible to use different regular expressions with the grep keyword to search for specific data in the logged messages.
Additional information about regular expression syntax is available in Using the Command Line Interface.
firewall# show logging | grep 410003
Apr 09 2008 15:28:04: %ASA-4-410003:
DNS Classification: Dropped DNS request (id 30553)
from inside:192.168.150.60/32792 to outside:192.168.2.10/53;
matched Class 32: bobax_kraken_query
Apr 09 2008 15:28:05: %ASA-4-410003:
DNS Classification: Dropped DNS request (id 30553)
from inside:192.168.150.60/32793 to outside:192.168.1.10/53;
matched Class 32: bobax_kraken_query
firewall#
With DNS application inspection enabled, the show service-policy inspect command will identify the number of DNS packets inspected and dropped by this feature. Example output for show service-policy inspect dns follows:
firewall(config)# show service-policy inspect dns
Global policy:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns bobax_kraken_drop, packet 48, drop 12, reset-drop 0
dns-guard, count 18
protocol-enforcement, drop 0
nat-rewrite, count 0
class bobax_kraken_query
drop log, packet 12
Cisco Intrusion Prevention System
Mitigation: Cisco IPS Signature Event Actions
Administrators can use the Cisco Intrusion Prevention System (IPS) appliances and services modules to provide threat detection and help prevent attempts to access the botnet C&C network. Starting with signature update S329 for sensors running Cisco IPS version 6.x or 5.x, the botnet C&C access can be detected by signatures 6537/0 and 6537/1 (Signature Name: Kraken Botnet Traffic). These signatures are enabled by default, trigger a High severity event, have a signature fidelity rating (SFR) of 80, and are configured with a default event action of produce alert. Signatures 6537/0 and 6537/1 fire when a single packet sent using UDP port 447 is detected. Firing of this signature may indicate an attempt to access the botnet C&C network described in this document.
Administrators can configure Cisco IPS sensors to perform an event action when the signature is detected. The configured event action performs preventive or deterrent controls to help prevent access to the botnet C&C network.
Traffic that is easily spoofed may cause a configured event action to inadvertently deny traffic from trusted sources.
For additional information about the risk rating and threat rating calculation, reference Risk Rating and Threat Rating: Simplify IPS Policy Management.
Identification: IPS Signature Events
Signature: 6537/0 Kraken Botnet Traffic
IDS# show events alert | include 6537
evIdsAlert: eventId=1184147509279040194 severity=high vendor=Cisco
originator:
hostId: IDS
appName: sensorApp
appInstanceId: 23387
time: 2008/04/17 16:27:11 2008/04/17 11:27:11 CDT
signature: description=Kraken Botnet Traffic id=6537 version=S329
subsigId: 0
sigDetails: Trojaned Host Connect Attempt
marsCategory: Penetrate/Backdoor/Trojan/Connect
interfaceGroup: vs0
vlan: 0
participants:
attacker:
addr: locality=OUT 192.168.0.1
port: 3106
target:
addr: locality=OUT 192.168.0.2
port: 447
os: idSource=unknown relevance=unknown type=unknown
triggerPacket:
! -- Cli Truncated
riskRatingValue: targetValueRating=medium 75
threatRatingValue: 75
interface: ge0_0
protocol: udp
Cisco Security Monitoring, Analysis, and Response System
Identification: Cisco Security Monitoring, Analysis, and Response System Incidents
The Cisco Security Monitoring, Analysis, and Response System (Cisco Security MARS) appliance can create incidents on events for the Kraken botnet C&C access using IPS signatures 6537/0 and 6537/1/ (Signature Name: Kraken Botnet Traffic). After the S329 dynamic signature update has been downloaded, using keywords NR-6537/0 and NR-6537/1 for IPS signatures 6537/0 and 6537/1 and a query type of All Matching Events on the Cisco Security MARS appliance will provide a report that lists the incidents created by the IPS signature.
The following screen shot shows the value(s) used to query for events created by IPS signatures related to these vulnerabilities:
The following screen shot shows the query results for these vulnerabilities created by the Cisco Security MARS appliance:
Beginning with the 4.3.1 and 5.3.1 releases of Cisco Security MARS appliances, support for the Cisco IPS dynamic signature updates feature has been added. This feature downloads new signatures from Cisco.com or from a local web server, correctly processes and categorizes received events that match those signatures, and includes them in inspection rules and reports. These updates provide event normalization and event group mapping, and they also enable the MARS appliance to parse new signatures from the IPS devices.
Caution: If dynamic signature updates are not configured, events that match these new signatures appear as unknown event type in queries and reports. MARS will not include these events in inspection rules; thus, incidents may not be created for potential threats or attacks that occur within the network.
By default, this feature is enabled but requires configuration. If it is not configured, the following Cisco Security MARS rule will be triggered:
System Rule: CS-MARS IPS Signature Update Failure
When this feature is enabled and configured, administrators can determine the current signature version downloaded by MARS by selecting Help > About and reviewing the IPS Signature Version value.
Additional information about and instructions for configuring dynamic signature updates are available for the Cisco Security MARS 4.3.1 and 5.3.1 releases.
Additional Information
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.
Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt.
