About the event types

The Historical Events view displays all normalized events in the Refined Results column. You can configure these events with the Policy commands.

To view all events, click the drop-down menu and select Events.

When you select an event, the corresponding normalized alerts display in the second column. For example, when you click Access, all access-related alerts display in the second column.

SEM includes five types of events. The following table lists each event type and their corresponding alerts.

Event type	Description
Asset events	Addresses the changing state of different types of enterprise assets, including software, hardware, and users. Asset event alerts indicate changes made to system configuration, software updates, patch applications, vulnerability information, and other system events.
Audit events	Address normal network activity that would not be considered an attack, compromise, or misuse of resources. Many audit alerts are associated with rules that can be used to threshold and escalate "normal" behavior into something that might be considered a security event.
Incident events	Raise global enterprise-wide visibility in response to any issue detected by Rules. Incidents reflect serious issues that should be addressed. Because incidents are created by rules, any combination of malicious or suspicious traffic from any other single alert or combination of alerts can create an incident.
Internal events	Address SEM system operations. Any event generated by SEM relating to Active Response, SEM users, or SEM errors display as one of the many children. These alerts are for informational purposes only. They do not necessarily reflect conditions that should cause alarm. Events that might reflect potential issues with SEM are specifically marked for forwarding to SolarWinds.
Security events	Address network activity that is consistent with an internal or external attack, a misuse or abuse of resources, a resource compromise, resource probing, or other abnormal traffic that is noteworthy. Security events indicate aggressive behavior that might lead to an attack or resource compromise, or suspicious behavior that might indicate unauthorized information gathering. SEM infers some security events from is normally considered audit traffic, but it escalates the events from alert status based on thresholds that are defined by rules.

Asset events

Asset events address assets and asset scan results. They relate to the changing state of different types of enterprise assets, including software, hardware, and users.

Asset information can come from centralized directory service connectors. The information can also be scanned information from security scan connectors, including vulnerability assessment and patch management connectors. These alerts indicate changes made to system configurations, software updates, patch applications, vulnerability information, and other system events.

Listed below are all asset event alerts in alphabetical order.

AssetManagement

AssetManagement alerts gather non-realtime data about system assets (such as computer, software, and users). The data comes from various sources, including directory service connectors.

AssetManagement > MachineAsset

MachineAsset is a specific type of AssetManagement alert that indicates additions, removals, and updates (including software installation) of specific nodes that exist in the enterprise.

AssetManagement > MachineAsset > MachineAssetAdded

MachineAssetAdded alerts indicate a new presence of a node (host or network device) in the enterprise.

AssetManagement > MachineAsset > MachineAssetRemoved

MachineAssetRemoved alerts indicate the removal of a node (host or network device) from the enterprise.

AssetManagement > MachineAsset > MachineAssetUpdated

MachineAssetUpdated alerts indicate a change to an existing node (host or network device) in the enterprise, including new software and software patch installations on the node.

AssetManagement > MachineAsset > MachineAssetUpdated > SoftwareAssetUpdated

SoftwareAssetUpdated alerts indicate an attempted software change (including the application of a software patch) to an existing node (host or network device) in the enterprise, successful or failed.

AssetManagement > MachineAsset > MachineAssetUpdated > SoftwareAssetUpdated > SoftwareAssetPatched

SoftwareAssetPatched alerts indicate a successful application of a software patch to an existing node (host or network device) in the enterprise.

AssetManagement > MachineAsset > MachineAssetUpdated > SoftwareAssetUpdated > SoftwareAssetPatchFailed

SoftwareAssetPatchFailed alerts indicate a failed application of a software patch to an existing node (host or network device) in the enterprise.

AssetManagement > SoftwareAsset

SoftwareAsset is a specific type of AssetManagement alert that indicates additions, removals, and updates of specific software and software versions that exist in the enterprise.

AssetManagement > SoftwareAsset > SoftwareAssetAdded

SoftwareAssetAdded alerts indicate a new presence of an installation of specific software applications or operating systems in the enterprise.

AssetManagement > SoftwareAsset > SoftwareAssetAdded > SoftwareAssetVersionAdded

SoftwareAssetVersionAdded alerts indicate a new version installation of specific known software applications or operating systems in the enterprise.

AssetManagement > SoftwareAsset > SoftwareAssetRemoved

SoftwareAssetRemoved alerts indicate removals of specific software applications or operating systems from the enterprise.

AssetManagement > UserAsset

UserAsset is a specific type of AssetManagement alert that indicates additions, removals, and updates to users and user groups that exist in the enterprise.

AssetManagement > UserAsset > GroupAssetAdded

GroupAssetAdded alerts indicate a new presence of a user group in the enterprise.

AssetManagement > UserAsset > GroupAssetRemoved

GroupAssetRemoved alerts indicate the removal of a user group from the enterprise.

AssetManagement > UserAsset > GroupAssetUpdated

GroupAssetUpdated alerts indicate a change to a user group that exists in the enterprise, including group member additions and deletions.

AssetManagement > UserAsset > GroupAssetUpdated > GroupAssetMemberAdded

GroupAssetMemberAdded alerts indicate an addition of a user member to a user group that exists in the enterprise.

AssetManagement > UserAsset > GroupAssetUpdated > GroupAssetMemberRemoved

GroupAssetMemberRemoved alerts indicate a removal of a user member from a user group that exists in the enterprise.

AssetManagement > UserAsset > UserAssetAdded

UserAssetAdded alerts indicate a new presence of a user in the enterprise.

AssetManagement > UserAsset > UserAssetRemoved

UserAssetRemoved alerts indicate the removal of a user from the enterprise.

AssetManagement > UserAsset > UserAssetUpdated

UserAssetUpdated alerts indicate a change to a user that exists in the enterprise.

AssetScanResult

AssetScanResult contains alerts useful for data gathered from security scan results (reports). These alerts are commonly gathered from vulnerability assessment and patch management connectors.

AssetScanResult > ExposureFound

ExposureFound alerts indicate scan results that are not high risk but demonstrate configuration issues or potential risks. These alerts may indicate exposures that can potentially cause future exploits or have been common sources of exploits in the past, such as common open ports or host configuration issues.

AssetScanResult > VulnerabilityFound

VulnerabilityFound alerts indicate scan results that demonstrate high risk vulnerabilities. These alerts can indicate the presence of serious exposures that should be addressed and can represent significant risk of exploit or infection of enterprise assets.

GeneralAsset

GeneralAsset alerts are generated when a supported product outputs data that is not normalized into a specific alert, but known to be asset issue-related.

Audit events

Audit events are generally related to normal network activity that would not be considered an attack, compromise, or misuse of resources. Many of the audit alerts have rules that can be used to threshold and escalate “normal” behavior into something which may be considered a security event.

Listed below are all audit event alerts in alphabetical order.

AuthAudit

AuthAudit events are related to authentication and authorization of accounts and account containers, such as groups or domains. These alerts can be produced from any network node including firewalls, routers, servers, and clients.

AuthAudit > DomainAuthAudit

DomainAuthAudit events are authentication, authorization, and modification events related only to domains, subdomains, and account containers. These alerts are normally operating system related. However, they can be generated by any network device.

AuthAudit > DomainAuthAudit > NewDomainMember

NewDomainMember events occur when an account or account container is added to a domain. Usually, these additions are made by a user account with administrative privileges. Occasionally, a NewDomainMember alert will also occur when local system maintenance activity takes place.

AuthAudit > DomainAuthAudit > DeleteDomainMember

DeleteDomainMember events occur when an account or account container is removed from a domain. Usually, these changes are made by a user account with administrative privileges. Occasionally a DeleteDomainMember alert can also occur when local system maintenance activity takes place.

AuthAudit > DomainAuthAudit > ChangeDomainMember

A ChangeDomainMember alert occurs when an account or account container within a domain is modified.Usually, these changes are made by a user account with administrative privileges. Occasionally, a ChangeDomainMember alert can also occur due to local system maintenance activity.

AuthAudit > DomainAuthAudit > ChangeDomainMember > DomainMemberAlias

DomainMemberAlias events occur when an account or account container within a domain has an alias created, deleted, or otherwise modified. This event is uncommon and is used to track links between domain members and other locations in the domain where the member may appear.

AuthAudit > DomainAuthAudit > NewDomain

NewDomain events occur when a new trust relationship is created between domains, a new subdomain is created, or new account containers are created within a domain. Usually, these creations are done by a user account with administrative privileges.

AuthAudit > DomainAuthAudit > ChangeDomainAttribute

ChangeDomainAttribute events occur when a domain type is changed. These events are uncommon and usually provided by the operating system. Usually, these changes are made by a user account with administrative privileges. Occasionally, a ChangeDomainAttribute alert occurs when local system maintenance activity takes place.

AuthAudit > DomainAuthAudit > DeleteDomain

DeleteDomain events occur when a trust relationship between domains is removed, a subdomain is deleted, or account containers within a domain are deleted. These changes are usually performed by a user account with administrative privileges.

AuthAudit > GroupAudit

GroupAudit events are authentication, authorization, and modification events related only to account groups. These alerts are normally operating system related. However, they can be produced by any network device.

AuthAudit > GroupAudit > ChangeGroupAttribute

ChangeGroupAttribute events occur when a group type is modified. Usually, these changes are made by a user account with administrative privileges. Occasionally, a ChangeGroupAttribute alert will also occur when local system maintenance activity takes place.

AuthAudit > GroupAudit > DeleteGroup

DeleteGroup events occur when a new group of any type is deleted. These deletions are usually made by a user account with administrative privileges.

AuthAudit > GroupAudit > DeleteGroupMember

DeleteGroupMember events occur when an account or group is removed from a group. These changes are usually made by a user account with administrative privileges. Occasionally, a DeleteGroupMember alert will also occur when local system maintenance activity takes place.

AuthAudit > GroupAudit > NewGroup

NewGroup events occur when a new group of any type is created. These additions are usually made by a user account with administrative privileges.

AuthAudit > GroupAudit > NewGroupMember

NewGroupMember events occur when an account (or another group) is added to a group. These additions are usually made by a user account with administrative privileges. Occasionally, a NewGroupMember alert will also occur when local system maintenance activity takes place or a new user, machine, or service account is added to the group.

AuthAudit > MachineAuthAudit

MachineAuthAudit events are authentication, authorization, and modification events related only to computer or machine accounts. These alerts can be produced from any network node including firewalls, routers, servers, and clients. Normally, they are related to the operating system.

AuthAudit > MachineAuthAudit > MachineAuthTicketFailure

MachineAuthTicketFailure alerts reflect failed computer or machine account ticket events from network devices that use a ticket-based single-sign-on system (such as Kerberos or Windows domains). Each alert reflects the point on the network where the computer or machine was attempting a logon. In larger quantities, these alerts may reflect a potential issue with a computer or set of computers. As individual events, they are generally not a problem.

AuthAudit > MachineAuthAudit > MachineAuthTicket

MachineAuthTicket alerts reflect computer or machine account ticket events from network devices that use a ticket-based single-sign-on system (such as Kerberos or Windows domains). Each alert reflects the type of device the logon was intended for, along with all other relevant fields.

AuthAudit > MachineAuthAudit > MachineDisable

MachineDisable events occur when a machine account is actively disabled and/or when an account is forcibly locked out by the operating system or another authentication connector. These events are usually operating system related and could reflect a potential issue with a computer or set of computers.

AuthAudit > MachineAuthAudit > MachineEnable

MachineEnable alerts reflect the action of enabling a computer or machine account. These events are normally related to the operating system and triggers when a machine is 'enabled', normally by a user with administrative privileges.

AuthAudit > MachineAuthAudit > MachineLogoff

MachineLogoff alerts reflect computer or machine account logoff events from network devices (including network infrastructure devices, where appropriate). Each alert reflects the type of device from which the user was logging off. These alerts are usually normal events, but are tracked for consistency and auditing purposes.

AuthAudit > MachineAuthAudit > MachineLogonFailure

MachineLogonFailure alerts reflect failed computer or machine account logon events from network devices (including network infrastructure devices, when appropriate). Each alert reflects the point on the network where the computer or machine was attempting a logon. In larger quantities, these alerts can reflect a potential issue with a computer or set of computers. As individual events, they are generally not a problem.

AuthAudit > MachineAuthAudit > MachineLogon

MachineLogon events reflect computer or machine account logon events from network devices monitored (including network infrastructure devices, when appropriate). Each alert reflects the type of device that the logon was intended for, along with all other relevant fields. These events are normally related to the operating system.

AuthAudit > MachineAuthAudit > MachineModifyAttribute

MachineModifyAttribute events occur when a computer or machine type is changed. These events are uncommon and usually provided by the operating system.

AuthAudit > MachineAuthAudit > MachineModifyPrivileges

MachineModifyPrivileges events are created when a computer or machine's privileges are elevated or demoted based on their logon or activities they are performing. These events are uncommon.

AuthAudit > UserAuthAudit

UserAuthAudit events are authentication, authorization, and modification events that only apply to user accounts. These alerts can be produced from any network node including firewalls, routers, servers, and clients.

AuthAudit > UserAuthAudit > UserAuthTicketFailure

UserAuthTicketFailure alerts reflect failed user account ticket events from network devices that use a ticket-based single-sign-on system (such as Kerberos or Windows domains). Each alert reflects the point on the network where the user was attempting a logon. In larger quantities, these alerts may reflect a potential issue with a user or set of users. Ass individual events, they are generally not a problem.

AuthAudit > UserAuthAudit > UserAuthTicket

UserAuthTicket alerts reflect user account ticket events from network devices monitored that use a ticket-based single-sign-on system (such as Kerberos or Windows domains). Each alert reflects the type of device that the logon was intended for, along with all other relevant fields.

AuthAudit > UserAuthAudit > UserDisable

UserDisable events occur when a user account is actively disabled and/or when a user is forcibly locked out by the operating system or another authentication connector. These events are usually operating system related and can reflect a potential issue with a user or set of users.

AuthAudit > UserAuthAudit > UserEnable

UserEnable alerts reflect the action of enabling a user account. These events are normally related to the operating system and triggers when an account is unlocked after lockout due to unsuccessful logons and 'enabled' in the traditional sense.

AuthAudit > UserAuthAudit > UserLogoff

UserLogoff alerts reflect account logoff events from network devices (including network infrastructure devices). Each alert reflects the type of device from which the user was logging off. These alerts are usually normal events, but are tracked for consistency and auditing purposes.

AuthAudit > UserAuthAudit > UserLogon

UserLogon alerts reflect user account logon events from monitored network devices (including network infrastructure devices). Each alert reflects the type of device that the logon was intended for, along with all other relevant fields.

AuthAudit > UserAuthAudit > UserLogonFailure

UserLogonFailure alerts reflect failed account logon events from network devices (including network infrastructure devices). Each alert reflects the point on the network where the user was attempting a logon. In larger quantities, these alerts may reflect a potential issue with a user or set of users. As individual events they are generally not a problem.

With SolarWinds policy, you can configure combinations of this event to escalate to FailedAuthentication in the Security tree, reflecting the increase in severity of the event over several occurrences.

AuthAudit > UserAuthAudit > UserModifyAttribute

UserModifyAttribute events occur when a user type is changed. These events are uncommon and usually provided by the operating system.

AuthAudit > UserAuthAudit > UserModifyPrivileges

UserModifyPrivileges events are created when a user's privileges are elevated or demoted based on their logon or activities they are performing. These events are uncommon.

GeneralAudit

GeneralAudit alerts are generated when a supported product outputs data that has not yet been normalized into a specific alert, but is known to be audit-related.

MachineAudit

MachineAudit alerts track hardware or software status and modifications. These events are generally acceptable, but do indicate modifications to the client system that may be noteworthy.

MachineAudit > SoftwareInstall

SoftwareInstall alerts reflect modifications to the system at a software level, generally an operating system level (or equivalent, in the case of a network infrastructure device). These alerts are generated when a user updates a system or launches system-native methods to install third party applications.

MachineAudit > SoftwareInstall > SoftwareUpdate

SoftwareUpdate is a specific type of SoftwareInstall alert that reflects a more current version of software being installed to replace an older version.

MachineAudit > SystemScan

SystemScan alerts reflect information related to scheduled or on-demand scans of systems. These alerts are generally produced by anti-virus, patch management, and vulnerability assessment connectors. Additionally, these alerts indicate the start, finish, and information related to a scan.

MachineAudit > SystemScanInfo

SystemScanInfo is a specific type of SystemScan alert that reflects information related to a system scan. Most of these events can safely be ignored, as they are generally normal activity that does not reflect a failure or abnormal state.

MachineAudit > SystemScanStart

SystemScanStart is a specific type of SystemScan alert that indicates the initiation of a system scan.

MachineAudit > SystemScanStop

SystemScanStop is a specific type of SystemScan alert that indicates a system scan is completed. This activity is generally normal. However, in the error or failure state, a specific alert will be generated.

MachineAudit > SystemScanWarning

SystemScanWarning is a specific type of SystemScan alert that indicates a scan has returned a 'Warning' message, indicating an issue. These alerts may indicate scan issues that should be corrected for future scans.

MachineAudit > SystemStatus

SystemStatus alerts reflect general system state events. These events are generally normal and informational. However, they could potentially reflect a failure or issue which should be addressed.

MachineAudit > SystemStatus > SystemReboot

SystemReboot is a specific type of SystemStatus alert used to audit system restarts. This alert will only be generated if the system restart was normal and not a result of a crash or other failure condition.

MachineAudit > SystemStatus > SystemReboot > SystemShutdown

SystemShutdown is a specific type of SystemStatus alert used to audit system shutdowns, including both expected and unexpected shutdowns. If the shutdown was unexpected, the event detail notes the information provided by the connector related to the abnormality.

PolicyAudit

PolicyAudit events are used to track access, modification, scope change, and creation of authentication, domain, account, and account container policies. Many of these alerts reflect normal system traffic. Most PolicyAudit alerts are provided by the operating system.

PolicyAudit > NewAuthPolicy

NewAuthPolicy alerts occur when a new authorization or authentication package, process, or logon handler is applied to an item (usually an account or domain). In the operating system context, these events will often occur on boot, as the system initializes the appropriate authentication policies for itself.

PolicyAudit > PolicyAccess

PolicyAccess alerts reflect all levels of access to policy These alerts mostly targeting domain, account, access, and logon policy modifications.

PolicyAudit > PolicyAccess > PolicyModify

PolicyModify alerts reflect all types of modifications to contained policies, both at a local and domain/account container level. In the context of a network infrastructure device, this would be a modification to access control lists or other similar policies on the device.

PolicyAudit > PolicyAccess > PolicyModify > DomainPolicyModify

DomainPolicyModify alerts are a specific type of PolicyModify alerts that reflect changes to domain and account container level policies. These types of policies are generally related to the operating system. These modifications are usually made by a user with administrative privileges. Occasionally, these changes can also be triggered by the local system.

PolicyAudit > PolicyAccess > PolicyScopeChange

PolicyScopeChange alerts are a specific type of PolicyAccess alert that reflect a new scope or assignment of policy to users, groups, domains, interfaces, or other items. In the context of the operating system, these events are usually describing elevation of user privileges according to predefined policies.

The process of this elevation is considered a scope change, as the user is being brought under a new scope of privileges appropriate to the type of access they are requesting (and being granted). These events may accompany or precede object or file opens, including other policies.

PolicyAudit > PolicyAccess > GroupPolicyModify

GroupPolicyModify alerts are specific PolicyAccess alerts used to describe modifications to account group policies. Usually, these modifications are made by a user with administrative privileges. Occasionally, these changes can also be triggered by the local system.

ResourceAudit

Members of the ResourceAudit tree are used to define different types of access to network resources. These resources may be network bandwidth/traffic, files, client processes or services, or other types of shared security-related 'commodities'.

ResourceAudit > FileAudit

FileAudit alerts track file activity on monitored network devices, usually through the Operating System or a Host-Based IDS. These events will note success or failure of the requested operation.

ResourceAudit > FileAudit > FileAuditFailure

FileAuditFailure alerts track failed file activity on monitored network devices, usually through the operating system or a host-based intrusion detection system (IDS). These events will note what requested operation failed.

ResourceAudit > FileAudit > FileRead

FileRead is a specific FileAudit alert generated for the operation of reading files (including reading properties of a file or the status of a file). These alerts may be produced by any connector used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileRead > FileExecute

FileExecute is a specific FileRead alert generated for the operation of executing files. These alerts may be produced by any connector used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileRead > FileDataRead

FileDataRead is a specific FileRead alert generated for the operation of reading data from a file (not just properties or status of a file). These alerts may be produced by any connector that is used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileWrite

FileWrite is a specific FileAudit alert generated for the operation of writing to a file (including writing properties of a file or changing the status of a file). These alerts may be produced by any connector that is used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileWrite > FileDataWrite

FileDataWrite is a specific FileWrite alert generated for the operation of writing data to a file (not just properties or status of a file). These alerts may be produced by any connector used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileWrite > FileCreate

FileCreate is a specific FileWrite alert generated for the initial creation of a file. These alerts may be produced by any connector that is used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileWrite > FileMove

FileMove is a specific FileWrite alert generated for the operation of moving a file that already exists. These alerts may be produced by any connector that is used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileWrite > FileDelete

FileDelete is a specific FileWrite alert generated for the deletion of an existing file. These alerts may be produced by any connector that is used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileWrite > FileAttributeChange

FileAttributeChange is a specific FileWrite alert generated for the modification of file attributes (including properties such as read-only status). These alerts may be produced by any connector that is used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileAudit > FileWrite > FileLink

FileLink is a specific FileWrite alert generated for the creation, deletion, or modification of links to other files. These alerts may be produced by any connector that is used to monitor the activity of file usage, including a host-based IDS and some operating systems.

ResourceAudit > FileHandleAudit

FileHandleAudit alerts are used to track file handle activity on monitored network devices, usually through low-level access to the operating system, either natively or with or a host-based IDS. These events note the success or failure of the requested operation.

ResourceAudit > FileHandleAudit > FileHandleClose

FileHandleClose is a specific FileHandleAudit alert generated for the closing of file handles. These alerts may be generated by a connector with low-level file access, such as an operating system or some host-based IDS.

ResourceAudit > FileHandleAudit > FileHandleCopy

FileHandleCopy is a specific FileHandleAudit alert generated for the copying of file handles. These alerts may be generated by a connector that has low-level file access, such as an operating system or some host- based IDS.

ResourceAudit > FileHandleAudit > FileHandleOpen

FileHandleOpen is a specific FileHandleAudit alert generated for the opening of file handles. These alerts may be generated by a connector that has low-level file access, such as an operating system or some host- based IDS.

ResourceAudit > FileSystemAudit

FileSystemAudit alerts reflect hardware to file system mapping events and usage of file system resources. These events are generally normal system activity, especially during system boot.

ResourceAudit > FileSystemAudit > MountFileSystem

MountFileSystem alerts are a specific type of FileSystemAudit that reflect the action of creating an active translation between hardware to a usable file system. These events are generally normal during system boot.

ResourceAudit > FileSystemAudit > UnmountFileSystem

UnmountFileSystem alerts are a specific type of FileSystemAudit that reflect the action of removing a translation between hardware and a usable file system. These events are generally normal during system shutdown.

ResourceAudit > NetworkAudit

Members of the NetworkAudit tree are used to define events centered on the usage of network resources and bandwidth.

ResourceAudit > NetworkAudit > ConfigurationTrafficAudit

ConfigurationTrafficAudit alerts reflect application-layer data related to the configuration of network resources. Included in ConfigurationTrafficAudit are protocols such as DHCP, BootP, and SNMP. ConfigurationTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of misconfiguration, inappropriate usage, attempts to enumerate or access network devices or services, attempts to access devices that are configured via these services, or other abnormal traffic.

ResourceAudit > NetworkAudit > CoreTrafficAudit

CoreTrafficAudit alerts reflect network traffic sent over core protocols. Events that are children of CoreTrafficAudit are related to the TCP, IP, UDP, and ICMP protocols. Events of this type and its children do not have any application-layer data.

Events placed in the parent CoreTrafficAudit alert are known to be a core protocol, but are not able to be further categorized based on the message provided by the connector.

ResourceAudit > NetworkAudit > CoreTrafficAudit > TCPTrafficAudit

TCPTrafficAudit alerts are a specific subset of CoreTrafficAudit alerts where the protocol is known to be TCP. TCPTrafficAudit alerts may indicate normal traffic inside the network, normal traffic pass-through, denied traffic, or other non-application TCP traffic that is not known to have any immediate attack basis.

ResourceAudit > NetworkAudit > CoreTrafficAudit > IPTrafficAudit

IPTrafficAudit alerts are a specific subset of CoreTrafficAudit alerts where the protocol is known to be IP. IPTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of spoofs, routing issues, or other abnormal traffic. Generally, for the abnormal traffic that is appropriate to escalate, a policy is defined to escalate this to an alert in the Security tree based on a threshold.

ResourceAudit > NetworkAudit > CoreTrafficAudit > UDPTrafficAudit

UDPTrafficAudit alerts are a specific subset of CoreTrafficAudit alerts where the protocol is known to be UDP. UDPTrafficAuditEvents may indicate normal traffic inside the network, normal traffic pass-through, denied traffic, or other non-application UDP traffic that is not known to have any immediate attack basis.

ResourceAudit > NetworkAudit > CoreTrafficAudit > ICMPTrafficAudit

ICMPTrafficAudit alerts are a specific subset of CoreTrafficAudit alerts where the protocol is known to be ICMP. ICMPTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of scans, floods, or other abnormal traffic. Generally, for the abnormal traffic that is appropriate to escalate, a policy is defined to escalate this to an alert in the Security tree based on a threshold.

ResourceAudit > NetworkAudit > CoreTrafficAudit > IPSecTrafficAudit

IPSecTrafficAudit alerts are a specific subset of CoreTrafficAudit alerts where the traffic is known to be related to non-application layer IPSec events (such as key exchanges). IPSecTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of misconfigured IPSec peers, problems with IPSec communication, or other abnormal traffic.

ResourceAudit > NetworkAudit > LinkControlTrafficAudit

LinkControlTrafficAudit alerts are generated for network events related to link level configuration. LinkControlTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of misconfiguration at the link level, inappropriate usage, or other abnormal traffic.

ResourceAudit > NetworkAudit > RoutingTrafficAudit

RoutingTrafficAudit alerts are generated for network events related to configuration of network routes using protocols such as IGMP, IGRP, and RIP. RoutingTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of misconfigured routing, unintended route configuration, or other abnormal traffic.

ResourceAudit > NetworkAudit > RoutingTrafficAudit > RIPTrafficAudit

RIPTrafficAudit alerts are a specific subset of RoutingTrafficAudit alerts where the protocol is known to be RIP. RoutingTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of misconfigured routing, unintended route configuration, or other abnormal traffic.

ResourceAudit > NetworkAudit > NamingTrafficAudit

NamingTrafficAudit alerts are generated for network events related to the naming of network resources and nodes, using protocols such as WINS and DNS. NamingTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of inappropriate DNS authority attempts, misconfiguration of naming services, and other abnormal traffic. In several cases, for traffic that is appropriate to escalate, a policy is defined to escalate this to an alert in the Security tree based on a threshold.

ResourceAudit > NetworkAudit > FileSystemTrafficAudit

FileSystemTrafficAudit alerts are generated for network events related to requests for remote file systems, using protocols such as SMB and NFS. FileSystemTrafficAudit alerts generally indicate normal traffic for networks that have remote file system resources, such as SMB and NFS shares. However, alerts of this type could also be symptoms of attempts to enumerate shares or services, misconfiguration of such resources, or other abnormal traffic. For networks that do not have remote file system resources, these alerts will generally indicate abnormal traffic.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit

ApplicationTrafficAudit alerts reflect network traffic that is mostly or all application-layer data. Events that are children of ApplicationTrafficAudit are also related to application-layer resources. Events placed in the parent ApplicationTrafficAudit alert are known to be application-related, but are not able to be further categorized based on the message provided by the connector, or because they are uncommon and rarely, if ever, imply network attack potential.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit > EncryptedTraffic

EncryptedTraffic alerts reflect application-layer traffic that is encrypted and intended for a secure host. Included in EncryptedTraffic alerts are client and server-side application events, such as key exchanges, that normally occur after the low-level session creation and handshaking have completed.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit > EncryptedTraffic > EncryptedTrafficError

EncryptedTrafficError alerts are a specific subnet of EncryptedTraffic alerts that reflect problems while exchanging keys or data.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit > MailTrafficAudit

MailTrafficAudit alerts reflect application-layer data related to mail services. Included in MailTrafficAudit are client and server mail events from protocols such as IMAP, POP3, and SMTP. MailTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of excessive mail usage, unintended mail traffic, abnormal command exchanges to a server, or generally abnormal traffic.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit > WebTrafficAudit

WebTrafficAudit alerts reflect application-layer data related to web services. Included in WebTrafficAudit are client and server web events from web servers, web applications, content filter related events, and other web services. WebTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of inappropriate web usage, potential abuse of web services, or other abnormal traffic.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit > TimeTrafficAudit

TimeTrafficAudit alerts reflect application-layer data related to network time configuration. Included in TimeTrafficAudit are protocols such as NTP and activities, such as detection of client-side network time updates. TimeTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of misconfiguration, inappropriate usage, or other abnormal traffic.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit > TimeTrafficAudit > NTPTrafficAudit

NTPTrafficAudit alerts are a specific type of TimeTrafficAudit related to the Network Time Protocol.

ResourceAudit > NetworkAudit > ApplicationTrafficAudit > FileTransferTrafficAudit

FileTransferTrafficAudit alerts reflect application-layer data related to file retrieval and send to and from remote hosts. Included in FileTransferTrafficAudit are protocols such as TFTP and FTP. FileTransferTrafficAudit alerts generally indicate normal traffic. However, alerts of this type could also be symptoms of misconfiguration, inappropriate usage, attempts to enumerate or access file transfer services, attempts to access devices that require file transfer services for configuration, or other abnormal traffic.

ResourceAudit > NetworkAudit > PointToPointTrafficAudit

PointToPointTrafficAudit alerts reflect application-layer data related to point-to-point connections between hosts. Included in PointToPointTrafficAudit are encrypted and unencrypted point-to-point traffic.

ResourceAudit > NetworkAudit > PointToPointTrafficAudit > PPTPTrafficAudit

PPTPTrafficAudit alerts are a specific type of PointToPointTrafficAudit alerts that reflect application-layer encrypted peer-to-peer tunneling protocol (PPTP) activities. Included in PPTPTrafficAudit alerts are tunnel creation, tunnel deletion, session creation, and session deletion, among other PPTP-related events.

PPTPTrafficAudit alerts generally indicate normal traffic for networks that have PPTP-accessible devices on the network. However, alerts of this type could also be symptoms of inappropriate access, misconfiguration of the PPTP server or clients, other communications errors, or other abnormal traffic. For networks that do not have remote file system resources, these alerts will generally indicate abnormal traffic.

ResourceAudit > NetworkAudit > RemoteProcedureTrafficAudit

RemoteProcedureTrafficAudit alerts reflect application-layer data related to remote procedure services. Included in RemoteProcedureTrafficAudit are the traditional RPC services used to service remote logons and file shares. Also included are other services that require remote procedure access to complete authentication, pass data, or otherwise communicate.

RemoteProcedureTrafficAudit alerts generally indicate normal traffic for networks that have remote procedure services on their network. However, alerts of this type could also be symptoms of inappropriate access, misconfiguration of the remote procedure services, errors in the remote procedure calls, or other abnormal traffic.

ResourceAudit > NetworkAudit > RemoteProcedureTrafficAudit > RPCTrafficAudit

RPCTrafficAudit is a specific subset of RemoteProcedureTrafficAudit related to traditional RPC services, including portmapper. ResourceAudit > NetworkConnectionAudit NetworkConnectionAudit alerts are generated when a connection is initiated on a network client.

ResourceAudit > NetworkConnectionAudit > LANConnection

LANConnection is a specific type of NetworkConnectionAudit that reflects a successful connection on a physical network interface, such as an Ethernet card.

ResourceAudit > NetworkConnectionAudit > VPNConnection

VPNConnection is a specific type of NetworkConnectionAudit that reflects a successful connection to a remote VPN.

ResourceAudit > NetworkConnectionAudit > DialupConnection

DialupConnection is a specific type of NetworkConnectionAudit that reflects a successful connection through a traditional modem.

ResourceAudit > ObjectAudit

ObjectAudit alerts track special object activity on monitored network devices, usually through the operating system or a host-based IDS. Generally, objects are special types of system resources, such as registry items or user account databases. These objects may be actual files on the system, but are not necessarily human readable. These events will note success or failure of the requested operation.

ResourceAudit > ObjectAudit > ObjectAuditFailure

ObjectAuditFailure alerts track special object activity on monitored network devices, usually through the operating system or a host-based IDS. Generally, objects are special types of system resources, such as registry items or user account databases. These objects may be actual files on the system, but are not necessarily human readable. These events will note a failure of the requested operation.

ResourceAudit > ObjectAudit > ObjectDelete

ObjectDelete is a specific ObjectAudit alert generated for the deletion of an existing object. These alerts may be produced by any connector that is used to monitor the activity of file and object usage, including a host-based IDS and some operating systems.

ResourceAudit > ObjectAudit > ObjectLink

ObjectLink is a specific ObjectAudit alert generated for the creation, deletion, or modification of links to other objects. These alerts may be produced by any connector that is used to monitor the activity of file and object usage, including a host-based IDS and some operating systems.

ResourceAudit > ProcessAudit

ProcessAudit alerts are generated to track launch, exit, status, and other events related to system processes. These events usually reflect normal system activity. Process-related activity that may indicate a failure will be noted separately from normal activity in the alert detail.

ResourceAudit > ProcessAudit > ProcessStop

ProcessStop is a specific type of ProcessAudit alert that indicates a process stopped. ProcessStop usually reflects a normal application exit. However, in the event of an unexpected error, the abnormal state is noted.

ResourceAudit > ProcessAudit > ProcessStart

ProcessStart is a specific type of ProcessAudit alert that indicates a new process has been launched. ProcessStart usually reflects normal system activity.

ResourceAudit > ProcessAudit > ProcessWarning

ProcessWarning is a specific type of ProcessAudit alert that indicates a process has returned a Warning message that is not a fatal error and may not have triggered an exit of the process.

ResourceAudit > ProcessAudit > ProcessInfo

ProcessInfo is a specific type of ProcessAudit alert that reflects information related to a process. Most of these events can safely be ignored, as they are generally normal activity that does not reflect a failure or abnormal state.

ResourceAudit > ServiceAudit

ServiceAudit alerts are generated to track information and other events related to system components. These events usually reflect normal system activity. System service-related activity that may indicate a failure are noted separately from normal activity in the alert detail.

ResourceAudit > ServiceAudit > ServiceInfo

ServiceInfo is a specific type of ServiceAudit alert that reflects information related to a service. Most of these events can safely be ignored, as they are generally normal activity that does not reflect a failure or abnormal state.

ResourceAudit > ServiceAudit > ServiceStart

ServiceStart events are a specific type of ServiceAudit alert that indicates a new system service is starting.

ResourceAudit > ServiceAudit > ServiceStop

ServiceStop events are a specific type of ServiceAudit alert that indicates a system service is stopping. This activity is generally normal. However, in the event of an unexpected stop, the abnormal state will be noted.

ResourceAudit > ServiceAudit > ServiceWarning

ServiceWarning is a specific type of ServiceAudit alert that indicates a service has returned a Warning message that is not a fatal error and may not have triggered an exit of the service.

Incident events

Incident events reflect global enterprise-wide issues that should be raised for system-wide visibility. These alerts generally reflect serious issues that should be monitored and addressed. They are sub-categorized into different types of Incidents events that can provide more detailed information.

Because incident events are created by rules, any combination of malicious or suspicious traffic from any other single alert or combination of alerts can create an Incident event.

Listed below are all incident event alerts in alphabetical order.

HostIncident

HostIncident alerts reflect global enterprise-wide host system issues that should be raised for system-wide visibility. These alerts indicate issues on hosts that should be tracked and addressed, including security and administrative issues that apply specifically to host-based information.

HybridIncident

HybridIncident alerts reflect global enterprise-wide combined network and host system issues that should be raised for system-wide visibility. These alerts are used to indicate the combination of network and host-based issues that should be tracked and addressed, including security and administrative issues that span both network and host-based information.

NetworkIncident

NetworkIncident alerts reflect global enterprise-wide network system issues that should be raised for system-wide visibility. These alerts indicate network-based issues that should be tracked and addressed, including security and administrative issues that apply specifically to network-based information.

Internal events

Events that are a part of the InternalEvent node are related to the operation of the LEM system. Any events generated by the system relating to Active Response, Internal users, or Internal errors will appear under one of the many children.

These alerts are for informational purposes and do not necessarily reflect conditions that should cause alarm. Events that may reflect potential issues within the system are specifically marked for forwarding to SolarWinds.

Listed below are all internal event alerts in alphabetical order.

InternalAudit

InternalAudit alerts reflect attempted accesses and changes to components of the SEMsystem by existing SolarWinds users. Both successful and failed attempts will generate alerts.

InternalAudit > InternalAuditFailure

InternalAuditFailure is a specific type of InternalAudit alert that indicates failed audit information. These alerts are generated when a user fails to view or modify (including creation, update, and deletion) anything within the SolarWinds system. The alert includes the user, type of access, and item being accessed.

InternalAuditFailure events are uncommon and can indicate an attempted privilege escalation within the SEM system by unprivileged users.

InternalAudit > InternalAuditSuccess

InternalAuditSuccess is a specific type of InternalAudit alert that indicates successful audit information. These alerts are generated when a user successfully views or modifies (including creation, update, and deletion) anything within the SEM system. The alert will include the user, type of access, and item being accessed.

InternalCommands

InternalCommands alerts are only used internally with few exceptions. These alerts are used for sending commands through the system to complete active responses.

InternalCommands > InternalAgentToolCommand

InternalAgentToolCommand alerts are internal only. They are fired between managers and agents to manage the connector settings.

InternalCommands > InternalAgentFastPack

InternalAgentFastPack alerts are internal only. They are fired between managers and agents to configure updated connector signatures.

InternalFailure

Events that are a part of the InternalFailure tree reflect potential issues within the system. These alerts could reflect configuration issues, issues that cannot be resolved without contacting SolarWinds, and potential serious issues that also merit contacting SolarWinds.

InternalFailure > InternalError

InternalError alerts reflect configuration or install issues that should be reported to SolarWinds. These are generally internal errors related to connectors that may be producing unexpected log entries or conditions that were unexpected. These issues generally cannot be solved without contacting SolarWinds. However, they should not be fatal errors.

InternalFailure > InternalException

InternalException alerts reflect more serious problems within the system. These problems generally lie within the product implementation and may require a software update to eliminate. These alerts and their surrounding conditions should be reported to SolarWinds.

InternalFailure > InternalWarning

InternalWarning alerts are generally problems that can be solved by the user. Usually, these alerts are configuration related and may assist in debugging the underlying issue. InternalWarning alerts do not reflect internal problems within the system and thus should not be immediately reported to SolarWinds. However, they may assist with solving a technical support issue should the need arise.

InternalGeneralEvent

InternalGeneralEvent events are uncommon events used to track Internal information that has not been placed into a more specific InternalEvent. Events of the InternalFailure family providing more information will be generated in addition to this event, if the event is serious.

InternalInfo

Events within the InternalInfo family are related to events that occur within the system. Generally, these informational alerts are confirming or reporting normal activity, such as user updates, user logons, policy updates, and agent connection-related events.

InternalInfo > InternalAgentOffline

InternalAgentOffline alerts reflect detection of an agent disconnect to its manager. These alerts occur when the manager detects that the agent closed the connection. This may be due to network down time of the agent or the agent service shutting down.

InternalInfo > InternalAgentOnline

InternalAgentOnline alerts reflect successful connection of agents to their respective managers. These alerts occur when an agent initiates successful communication with the manager. This can be due to network down time of the manager or agent or due to an update of the targeted agent.

InternalInfo > InternalDuplicateConnection

InternalDuplicateConnection alerts occur when an agent attempts to connect to their manager more than once. These alerts are usually triggered by network issues on the agent end due to a possible asynchronous disconnection detection (for example, the manager was not able to detect the agent went offline, but the agent service was restarted). This issue can usually be resolved by stopping the agent service, waiting for the InternalAgentOffline alert, and then restarting the agent service.

InternalInfo > InternalInvalidConnection

InternalInvalidConnection alerts occur when an agent that the manager recognizes, but cannot communicate with, attempts to connect. These alerts usually reflect agents that are missing an update that was applied to the manager.

Ensure that the indicated agent is upgraded to the same release version of the system that is installed on your manager. If this alert persists, uninstall and reinstall the agent triggering the alert. This will force the Agent to re-initialize connection to the manager.

InternalInfo > InternalInvalidInstallation

InternalInvalidInstallation alerts occur in the unlikely case that the manager can communicate with the agent, but there are errors detected in the manager-to-agent relationship. These alerts are very uncommon, but may be triggered during an upgrade process.

Ensure that the targeted agent is upgraded to the same release version of the system installed on your manager. If this alert persists, uninstall and reinstall the agent triggering the alert. This will force the agent to re-initialize connection to the manager.

InternalInfo > InternalLicenseMaximum

InternalLicenseMaximum alerts reflect an attempt to add more agents to a manager that exceed the manager license tier. The number of agents that can be added is a hard limit that the manager stores and this limit is also enforced by the console. If more licenses are required, contact SolarWinds Sales for an update.

InternalInfo > InternalNewToolData

InternalNewToolData alerts generally reflect issues related to connectors with unexpected log entries or other unexpected conditions. These issues, although not fatal, generally cannot be solved without contacting SolarWinds.

InternalInfo > InternalPolicyConfiguration

InternalPolicyConfiguration alerts reflect the successful or unsuccessful attempts to update the policy on a given manager. These alerts are generated after the policy is successfully installed to the manager or after an error is detected. Generally, an error in updating the policy will also produce an alert from the InternalFailure family, providing more information.

InternalInfo > InternalToolOffline

InternalToolOffline alerts reflect a successful stop of an Internal tool. These alerts are generated after a connector stops the log file reader that was created when the connector was brought online. Generally, an error in an attempt to stop a connector will produce an alert from the InternalFailure family, providing more information.

InternalInfo > InternalToolOnline

InternalToolOnline alerts reflect the successful startup of an internal tool. These alerts are generated after a connector has successfully created a log file reader and has begun the reading process. Generally, an error in an attempt to start a connector produces an alert from the InternalFailure family, providing more information.

InternalInfo > InternalUnknownAgent

InternalUnknownAgent alerts occur when an agent that the manager does not recognize attempted to connect. Commonly, this alert is caused by removing the agent from the console before removing the agent service on the client.

These alerts may also be triggered during an upgrade process. In this case, they may reflect agents that are not up to date. This issue can usually be resolved by uninstalling and reinstalling the agent triggering the alert. This will force the agent to re-initialize connection to the manager.

InternalInfo > InternalUnsupportedAgent

InternalUnsupportedAgent alerts are generated when a valid agent connects and has not been upgraded to the same release version as the manager. The targeted agent failed to properly negotiate its connection or respond to a query, and has been assumed to be missing a required feature.

Ensure that the targeted agent is upgraded to the same SolarWinds release version that is installed on your manager. If this alert persists, uninstall and reinstall the agent triggering the alert. This will force the agent to re-initialize its connection to the manager.

InternalInfo > InternalUserLogoff

InternalUserLogoff alerts are generated when a user logs off or is disconnected from the console.

InternalInfo > InternalUserLogon

InternalUserLogon alerts are generated when a user successfully completes the logon process to a manager using the console. Failed log-on attempts are produced in a separate InternalUserLogonFailure alert.

InternalInfo > InternalUserLogonFailure

InternalUserLogonFailure alerts are generated when a user completes the initialization of a connection to the console, but enters an incorrect user name and/or password.

InternalInfo > InternalUserUpdate

InternalUserUpdate alerts are generated when a user is modified and the update is sent to the manager, or when the update has failed to apply. These updates include change or addition of an email address, change or addition of a pager, and change or addition of blocked alerts from selected agents. Generally, an error in updating a user will also produce an alert from the InternalFailure family.

InternalPolicy

InternalPolicy alerts reflect information related to correlation rules. These alerts indicate that a rule was triggered, either in test mode or under normal operating conditions.

InternalPolicy > InternalTestRule

InternalTestRule alerts reflect rule activity where a correlation rule is triggered and is set in Test mode. It indicates the trigger of the rule and includes an enumeration of what actions would take place (if any) if the rule was fully enabled. To remove a rule from Test mode, clear the Test checkbox for the rule in the Rule Builder.

InternalPolicy > InternalRuleFired

InternalRuleFired alerts reflect rule activity, specifically where a correlation rule has triggered. It indicates the trigger of the rule and includes an enumeration of what actions were triggered in response to the correlation.

Security events

Security events are generally related to network activity that is consistent with:

• Internal or external attacks

• Misuse or abuse of resources

• Resource compromise, resource probing, or other abnormal traffic that is noteworthy

Security events indicate aggressive behavior that may lead to an attack or resource compromise, or suspicious behavior that may indicate unauthorized information gathering. SEM infers some security events from what is normally considered audit traffic, but it escalates the events to alert status based on thresholds that are defined by rules.

Listed below are all security event alerts in alphabetical order.

AttackBehavior

Events that are children of AttackBehavior are generally related to network activity that may be consistent of an attack, misuse or abuse of resources, a resource compromise, or other abnormal behavior that should be considered indicative of a serious security event.

AttackBehavior > InferredAttack

InferredAttack alerts are reserved AttackBehavior alerts used for describing attacks that are a composite of different types of alerts. These events will be defined and inferred by policy.

AttackBehavior > ResourceAttack

Members of the ResourceAttack tree are used to define different types of malicious or abusive access to network resources, where these resources may be network bandwidth/traffic, files, client processes or services, or other types of shared security-related commodities.

AttackBehavior > ResourceAttack > NetworkAttack

Members of the NetworkAttack tree are used to define events centered on malicious or abusive usage of network bandwidth and traffic. These events include access to network resources, relaying attacks through network resources, or denial of service behavior on network resources.

AttackBehavior > ResourceAttack > NetworkAttack > Access

Children of the Access tree define events centered on malicious or abusive usage of network bandwidth or traffic where the intention or result is inappropriate or abusive access to network resources.

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess

ApplicationAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources where the related data is mostly or all application-layer.

Generally, ApplicationAccess alerts reflect attempted exploitation of weaknesses in server or client software, or information that is restricted or prohibited by device access control or policy. These alerts are generally provided by network-based intrusion detection systems. Iin some cases, network infrastructure devices (such as firewalls or proxy servers) may also provide them.

Events placed in the parent ApplicationAccess alert are known to be application-related, but not able to be further categorized based on the message provided by the connector or because they are uncommon.

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > DataBaseAccess

DataBaseAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through the application-layer database traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in database server or client software. These alerts are generally provided by network-based intrusion detection systems, the database server, or the client software.

The appropriate response to these alerts may require:

• Improving the access control of database servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to database servers or clients

• Remoing the database service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > FileTransferAccess

FileTransferAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer file transfer traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in file transfer server or client software. These alerts are generally provided by network-based intrusion detection systems, file transfer server, or the client software.

The appropriate response to these alerts may include:

• Improving the access control of file transfer servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to file transfer servers or clients

• Removing the file transfer service or client application related to this event.

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > FileTransferAccess > FTPFileAccess

FTPFileAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to file systems of resources through application-layer file transfer traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in file transfer server or client software with the intent of information gathering or low-level file system access of the server or client. These alerts are generally provided by network-based intrusion detection systems, file transfer server, or the client software.

The appropriate response to these alerts may require:

• Improving the access control of file transfer servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to file transfer servers or clients

• Removing the file transfer service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > FileTransferAccess > FTPInvalidFormatAccess

FTPInvalidFormatAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer file transfer traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in file transfer server or client software with the intent of information gathering or low-level access to the server or client. These attacks are always abnormal traffic that the file transfer server or client is not prepared to respond to.

Attacks such as buffer overflows may also result in the server or client software or system being halted. These alerts are generally provided by network-based intrusion detection systems, file transfer server, or the client software.

The appropriate response to these alerts may include:

• Improving the access control of file transfer servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to file transfer servers or clients

• Removing the file transfer service or client application related to this event.

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > FileTransferAccess > FTPCommandAccess

FTPCommandAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer file transfer traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in file transfer server software with the intent of information gathering or low-level access to the server or client. These attacks are always abnormal command traffic that the file transfer server is not prepared to respond to, but may provide access to (such as debug or legacy commands). These alerts are generally provided by network-based intrusion detection systems, file transfer server, or the client software.

The appropriate response to these alerts may include:

• Improving the access control of file transfer servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to file transfer servers or clients

• Removing the file transfer service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess

MailAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer mail transfer, retrieval, or service traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in mail-related server or client software. These alerts are generally provided by network-based intrusion detection systems, file transfer server, or the client software.

The appropriate response to these alerts may include: 

• Improving the access control of file transfer servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to file transfer servers or clients

• Removing the file transfer service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailTransferAccess

MailTransferAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer mail transfer traffic.

Generally, these alerts will reflect attempted exploitation of weaknesses in SMTP server software. These alerts are generally provided by network-based intrusion detection systems, or the SMTP server software .

The appropriate response to these alerts may include:

• Improving the access control of the SMTP server (such as restriction by IP address and/or user name to ensure only trusted clients are connecting, especially for SMTP servers that relay mail for external or remote entities)

• Applying updates or patches to SMTP servers

• Removing the SMTP server related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailTransferAccess > SMTPInvalidFormatAccess

SMTPInvalidFormatAccess alerts reflect malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources through application-layer mail transfer traffic.

Generally, these alerts will reflect attempted exploitation of weaknesses in SMTP server software with the intent of information gathering or low-level access to the server. These attacks are always abnormal traffic that the SMTP server is not prepared to respond to; attacks, such as buffer overflows, may also result in the server software or system being halted. These alerts are generally provided by network-based intrusion detection systems, or the SMTP server software.

The appropriate response to these alerts may include:

• Improving the access control of the SMTP server (such as restriction by IP address or user name to ensure only trusted clients are connecting, especially for SMTP servers that relay mail for external/remote entities)

• Applying updates or patches to SMTP servers

• Removing the SMTP server related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailTransferAccess > SMTPInvalidFormatAccess > SmailAccess

SmailAccess alerts reflect malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources through application-layer mail transfer traffic.

Generally, these alerts will reflect attempted exploitation of weaknesses in SMTP server software with the intent of information gathering or low-level access to the server. These attacks are always abnormal traffic that the SMTP server is not prepared to respond to; they may also result in the server software or system being halted. The smail attack specifically attempts to execute applications resulting in compromise of the SMTP server system.

These alerts are generally provided by network-based intrusion detection systems, or the SMTP server software.

The appropriate response to these alerts may include:

• Improving the access control of the SMTP server (such as restriction by IP address or user name to ensure only trusted clients are connecting, especially for SMTP servers that relay mail for external/remote entities)

• Applying updates or patches to SMTP servers

• Removing the SMTP server related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailTransferAccess > SMTPCommandAccess

SMTPCommandAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer mail transfer traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in SMTP server software with the intent of information gathering or low-level access to the server. These attacks are always abnormal command traffic that the SMTP server is not prepared to respond to, but may provide access to (such as debug or legacy commands).

These alerts are generally provided by network-based intrusion detection systems, or the SMTP server software.

The appropriate response to these alerts may include: 

• Improving the access control of the SMTP server (such as restriction by IP address or user name to ensure only trusted clients are connecting, especially for SMTP servers that relay mail for external/remote entities)

• Applying updates or patches to SMTP servers

• Removing the SMTP server related to this event.

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailDeliveryAccess

MailDeliveryAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer mail retrieval traffic.

Generally, these alerts eflect attempted exploitation of weaknesses in mail retrieval related server or client software—the mail delivery agent (MDA) or mail user agent (MUA).

These alerts are generally provided by network-based intrusion detection systems, or the SMTP server software.

The appropriate response to these alerts may include:

• Improving the access control of the SMTP server (such as restriction by IP address or user name to ensure only trusted clients are connecting, especially for SMTP servers that relay mail for external/remote entities)

• Applying updates or patches to SMTP servers

• Removing the SMTP server related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailServiceAccess

MailServiceAccess alerts reflect malicious or abusive usage of network resources where the intention ir result is gaining access to resources through application-layer mail service traffic.

Generally, these alerts reflect attempted exploitation of weaknesses in mail service-related server or client software, including services such as mailing list software, spam filters, email redirection software, and other mail filtering software.

These alerts are generally provided by network-based intrusion detection systems, mail service, or client software.

The appropriate response to these alerts may include:

• Improving the access control of mail services or servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to mail services or clients

• Removing the mail service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailServiceAccess > MajordomoAccess

MailServiceAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer mail service traffic. Generally, these alerts reflect attempted exploitation of weaknesses in Majordomo, which is a specific type of mailing list software.

These alerts are generally provided by network-based intrusion detection systems or mail service. Appropriate response to these alerts may include:

• Improving the access control of mail services or servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to the mail service, or the removal of the mail service related to this event.

Generally, the most appropriate response will be updates or patches that can be retrieved from the Majordomo web site or your operating system vendor.

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > NewsAccess

NewsAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer news traffic (over protocols such as NNTP). Generally, these alerts reflect attempted exploitation of weaknesses in the news server or client software.

These alerts are generally provided by network-based intrusion detection systems, news server, or client software.

The appropriate response to these alerts may include:

• Improving the access control of news servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

  Applying updates or patches to news servers or clients

• Removing the news service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > PrinterAccess

PrinterAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer remote printer traffic. Generally, these alerts reflect attempted exploitation of weaknesses in the remote printer server or client software.

These alerts are generally provided by network-based intrusion detection systems, remote printer server, or client software.

The appropriate response to these alerts may include: 

• Improving the access control of remote printer servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote printer servers or clients

• Removing the remote printer service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess

WebAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic. Generally, these alerts reflect attempted exploitation of weaknesses in the web server or client software.

These alerts are generally provided by network-based intrusion detection systems, web server, or client software.

The appropriate response to these alerts may include:

• Improving the access control of web servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• pplying updates or patches to web servers and/or clients

• Removing the web service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPClientAccess

HTTPClientAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic where the information flow is from server to client. Generally, these alerts reflect attempted exploitation of weaknesses in the client software or abuse and/or misuse of resources from clients.

These alerts are generally provided by network-based intrusion detection systems, the web client software, proxy servers, content filters, or firewalls with the capability to monitor incoming web traffic.

The appropriate response to these alerts may include:

• Applying updates or patches to web client software

• Restricting incoming/outgoing web requests/responses to reflect inappropriate or abusive access

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPClientAccess > FraudulentCertificateAccess

FraudulentCertificateAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic where the information flow is from server to client. Generally, these alerts reflect attempted exploitation of weaknesses in the client software through fraudulent certificates. The intent of these attacks may be to forge certificates that convince the client that the site is trusted, when in fact it is not, passing data along with those certificates that may be inappropriate or contain exploits.

These alerts are generally provided by network-based intrusion detection systems, the web client software, proxy servers, content filters, or firewalls with the capability to monitor incoming web traffic.

The appropriate response to these alerts may include:

• Applying updates or patches to web client software

• Restricting incoming/outgoing web requests/responses to reflect the abusive access

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPClientAccess > ProhibitedHTTPControlAccess

ProhibitedHTTPControlAccess alerts reflect malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources through application-layer WWW traffic in which the information flow is from server to client. Generally, these alerts will reflect attempted exploitation of weaknesses in the client software or abuse or misuse of resources from clients through client controls such as ActiveX and Java.

These alerts are generally provided by network-based intrusion detection systems, the web client software itself, proxy servers, content filters, or firewalls with capability to monitor incoming web traffic.

The appropriate response to these alerts may include:

• Applying updates or patches to web client software

• Restricting incoming/outgoing web requests/responses to reflect inappropriate or abusive access

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPServerAccess

HTTPServerAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic where the information flow is from client to server. Generally, these alerts will reflect attempted exploitation of weaknesses in the server software or abuse or misuse of server resources.

These alerts are generally provided by network-based intrusion detection systems, web server or service software, or firewalls with the capability to monitor incoming/outgoing web traffic.

The appropriate response to these alerts may include:

• Improving the access control of web servers (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to web servers, services, or clients

• Removing the web service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPServerAccess > HTTPApplicationAccess

HTTPApplicationAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts reflect attempted exploitation of weaknesses in applications running on top of the server software, such as PHP, CGI, administrative sites, and other application services.

These alerts are generally provided by network-based intrusion detection systems, the web server, the service software, or firewalls with capability to monitor incoming/outgoing web traffic.

The appropriate response to these alerts may include:

• Improving the access control of web servers or the service itself (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to web servers, services, or clients

• Removing the web service application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPServerAccess > HTTPApplicationAccess > HTTPAdministrationAccess

HTTPAdministrationAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts reflect attempted exploitation of weaknesses in applications run on top of server software that are related to remote administration of sites, services, or systems.

These alerts are generally provided by network-based intrusion detection systems, web server, service software, or firewalls with capability to monitor incoming or outgoing web traffic.

The appropriate response to these alerts may include:

• Improving the access control of web servers or the service (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to web servers, services, administrative sites, or clients

• Removing the web service application or administrative site related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPServerAccess > HTTPApplicationAccess > HTTPDynamicContentAccess

HTTPDynamicContentAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts reflect attempted exploitation of weaknesses in applications running on top of the server software that generate dynamic content, such as PHP, CGI, and ASP.

These alerts are generally provided by network-based intrusion detection systems, web server, service software, or firewalls with capability to monitor incoming or outgoing web traffic.

The appropriate response to these alerts may include:

• Improving the access control of web servers or the service (such as restriction by IP address or user name to ensure only trusted clients are connecting)

• Applying updates or patches to web servers, services, dynamic content, and/or clients

• Removing the web service application or dynamic content related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPServerAccess > HTTPApplicationAccess > HTTPFileRequestAccess

HTTPFileRequestAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts reflect attempted exploitation of weaknesses in applications running on top of server software related to remote administration of sites, services, and/or systems with the intent of information gathering or low-level file system access of the server or client.

These alerts are generally provided by network-based intrusion detection systems, web server, service software, and/or firewalls with capability to monitor incoming/outgoing web traffic.

The appropriate response to these alerts may include:

• Improving the access control of web servers or the service (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to web servers, services, and/or clients

• Removing the web service application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPServerAccess > HTTPApplicationAccess > HTTPServiceAccess

HTTPServiceAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer WWW traffic where the information flow is from client to server. Generally, these alerts reflect attempted exploitation of weaknesses in applications running on top of server software related to remote services such as printing or console access.

These alerts are generally provided by network-based intrusion detection systems, web server, service software, and/or firewalls with the capability to monitor incoming/outgoing web traffic.

The appropriate response to these alerts may include:

• Improving the access control of web servers or the service (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to web servers, services, and/or clients

• Removing the web service application or site related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > WebAccess > HTTPServerAccess > HTTPInvalidFormatAccess

HTTPInvalidFormatAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer web traffic in which the information flow is from client to server. Generally, these alerts will reflect attempted exploitation of weaknesses in web server software with the intent of information gathering or low-level access to the server. These attacks are always abnormal traffic that the web server is not prepared to respond to; attacks, such as buffer overflows, may also result in the server software or system being halted.

These alerts are generally provided by network-based intrusion detection systems, web server, service software, and/or firewalls with the capability to monitor incoming/outgoing web traffic.

The appropriate response to these alerts may include

• Improving the access control of the web server (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to web servers or services

• Removing the web server related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > NamingAccess

NamingAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer naming service traffic (using protocols such as DNS and WINS). Generally, these alerts will reflect attempted exploitation of weaknesses in the naming server or client software.

These alerts are generally provided by network-based intrusion detection systems, naming server, or the client software.

The appropriate response to these alerts may include:

• Improving the access control of name servers (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to naming servers and/or clients

• Removing the naming service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > RemoteConsoleAccess

RemoteConsoleAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through application-layer remote console service traffic (services such as telnet, SSH, and terminal services). Generally, these alerts reflect attempted exploitation of weaknesses in the remote console server or client software.

These alerts are generally provided by network-based intrusion detection systems, remote console server, or the client software.

The appropriate response to these alerts may include:

• Improving the access control of remote console servers (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote console servers and/or clients

• Removing the remote console service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > TimeAccess

TimeAccess alerts reflect malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources through application-layer remote time service traffic (using protocols such as NTP). Generally, these alerts will reflect attempted exploitation of weaknesses in the remote time server or client software.

These alerts are generally provided by network-based intrusion detection systems, the time server, or client software itself.

The appropriate response to these alerts may include: 

• Improving the access control of remote time servers (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote time servers and/or clients

• Removing the remote time service or client application related to this event.

AttackBehavior > ResourceAttack > NetworkAttack > Access > ConfigurationAccess

ConfigurationAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through resource configuration traffic (using protocols such as DHCP, BootP, and SNMP). Generally, these alerts reflect attempted exploitation of weaknesses in the configuration server or client software or attempts to gain system-level access to configuration servers. In the case of SNMP and similar configuration protocols, it could reflect an attempt to enumerate a device or devices on the same network for further attack.

These alerts are generally provided by network-based intrusion detection systems, configuration server, or the client software.

The appropriate response to these alerts may include:

• Improving the access control of configuration servers and services (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to configuration servers and/or clients

• Removing the configuration service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > CoreAccess

CoreAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources where the related data is mostly or all core protocols (TCP, UDP, IP, ICMP). Generally, CoreAccess alerts reflect attempted exploitation of weaknesses in network protocols or devices with intent to gain access to servers, clients, or network infrastructure devices.

These alerts are generally provided by network-based intrusion detection systems. In some cases, network infrastructure devices such as firewalls or routers may also provide them. In other cases, these events are escalated from the Audit tree through policy.

Events placed in the parent CoreAccess alert are known to be related to a core protocol. However, they are not able to be further categorized based on the message provided by the connector or because they are uncommon.

AttackBehavior > ResourceAttack > NetworkAttack > Access > CoreAccess > ICMPRedirectAccess

ICMPRedirectAccess alerts reflect a specific type of CoreAccess alert where the attack traffic is all ICMP Redirects (ICMP type 5) and the intent is to redirect traffic to enumerate devices or client machines or gather information on devices or client traffic to further attack those or other resources.

Redirects are generally benign ICMP messages sent to hosts to redirect traffic intended for a network that another gateway can control. In cases where ICMP Redirects are used for attacking, a host will generally pretend to be a router, pass a redirect to a client machine to modify its routing table to send traffic to the false router instead of their normal network gateway, and proceed to enumerate, gather information, or attack the redirected host. As a result, the false router will send the traffic on to the correct gateway while the host has no idea of what has occurred (unless another device or connector detects it). This is one type of what is commonly referred to as a man-in-the-middle attack.

These alerts are generally provided by network-based intrusion detection systems and network infrastructure devices, such as firewalls or routers.

The appropriate response to these alerts may include:

• Blocking or resetting the local or remote user's connection/IP address

• Updating the network infrastructure devices

• Restricting incoming/outgoing ICMP redirect requests/responses to reflect inappropriate or abusive access

The appropriate methods to prevent ICMP redirect attacks would include:

• Limiting hosts who can broadcast ICMP Redirects across network devices to correct routers and gateways.

• Limiting ingress and egress ICMP traffic.

• Verifying that clients, servers, and network infrastructure devices are configured with the latest operating system or other networking software. This process helps ensure that other attacks related to ICMP Redirect attacks of this type (such as denial of service attacks) do not occur.

AttackBehavior > ResourceAttack > NetworkAttack > Access > CoreAccess > IPFragmentationAccess

IPFragmentationAccess alerts reflect a specific type of CoreAccess alert where the attack traffic is all IP traffic and the intent is to mask possible malicious or abusive data past an IDS or other detection device by using many IP fragments (usually much larger or smaller than normal fragments).

The network infrastructure devices handling the traffic will reassemble and pass on the traffic correctly. However, an IDS on the network may not be able to detect the malicious traffic, but only the presence of fragments. The attack may be allowed to pass through the network either incoming or outgoing, thereby eliminating one line of defense. Normal IP fragmentation (data that was taken apart because it is too large based on network parameters) should not trigger an IPFragmentationAccess alert.

Fragmentation alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

The appropriate response to these alerts may include:

• Blocking or resetting the local or remote user's connection/IP address

• Applying updates or patches to server and/or client software (especially the IDS)

• Updating the network infrastructure devices

• Restricting incoming/outgoing network requests/responses to reflect inappropriate or abusive access

AttackBehavior > ResourceAttack > NetworkAttack > Access > CoreAccess > IPSourceRouteAccess

IPSourceRouteAccess alerts reflect a specific type of CoreAccess alert where the attack traffic is all IP traffic and the intent is generally to misrepresent the originating address to bypass detection.

IPSourceRouteAccess is a type of IP spoofing where an attacker falsifies network information to convince the destination that the given source is something other than the actual source, directing the destination to return the traffic through an IP Source Route option that traces the traffic to the trusted host and then on to the untrusted attacker. The trusted host receives the traffic from the destination and because of the IP Source Route, it passes the traffic on to the untrusted attacker. The data is not modified, and the attacker has tricked the network into passing the traffic on. Generally, while spoofed, clients will attempt to gather information, perform actual attacks on internal or external devices, or perform denial of service attacks.

These alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

Response to IP spoofing is difficult, as the originating host may be alternating spoofed hostnames or IP addresses to continually circumvent detection. However, response to IP spoofing that uses the IP source route could include removing the ability to pass traffic through routers or gateways that contains an IP Source Route option.

Initial appropriate response to these alerts may include blocking or resetting the local or remote user's connection/IP address, which may prove ineffective or unrealistic. Other responses may include:

• Applying updates or patches to server and/or client software

• Updating network infrastructure devices

• Restricting incoming/outgoing network requests/responses to reflect inappropriate or abusive access

Unfortunately, it may be difficult to derail an attempted attack through IP spoofing, as routing and firewall policies (including disallowing traffic with the IP Source Route option) should prevent further access through spoofed addresses.

AttackBehavior > ResourceAttack > NetworkAttack > Access > CoreAccess > IPSpoofAccess

IPSpoofAccess alerts reflect a specific type of CoreAccess alert where the attack traffic is all IP traffic and the intent is to misrepresent the originating address to either bypass detection or misdirect response to attack activity.

IP Spoofing falsifies network information to convince the destination (and any network hops in between) that the given source is something other than the actual source. Generally, while spoofed, clients will attempt to gather information, perform actual attacks on internal or external devices, or perform denial of service attacks.

These alerts are generally provided by network-based intrusion detection systems and network infrastructure devices, such as firewalls or routers. Response to IP spoofing is difficult, as the originating host may be alternating spoofed hostnames or IP addresses to continually circumvent detection.

Initial appropriate response to these alerts may include blocking or resetting the local or remote user's connection/IP address. However, this may prove ineffective or unrealistic. Other responses may include:

• Applying updates or patches to server and/or client software

• Updating infrastructure devices

• Restricting incoming/outgoing network requests/responses to reflect inappropriate or abusive access.

Unfortunately, it may prove difficult to derail an attempted attack through IP spoofing. Routing and firewall policies should prevent further access through spoofed addresses.

AttackBehavior > ResourceAttack > NetworkAttack > Access > CoreAccess > TCPHijackAccess

TCPHijackAccess alerts reflect a specific type of CoreAccess alert where the attack traffic is all TCP traffic and the intent is to hijack a user's connection.

The intent of TCP Hijacking is to take over another network user's connection by sending malformed packets to confuse the server into thinking that the new user is the original user. In doing so, the original user is removed from his connection to the server and the new user injects himself, taking over all attributes the server assumed from the original, including levels of security and/or trust.

TCP Hijacking can be used to place future attack connectors on client systems, gather information about networks and/or client systems, immediately attack internal networks, or other malicious and/or abusive behavior.

These alerts are generally provided by network-based intrusion detection systems. In some cases, network infrastructure devices (such as firewalls or routers) may also provide them.

The appropriate response to these alerts may include:

• Blocking or resetting the remote hijacker's connection/IP address.

• Applying updates or patches to server and/or client software.

• Applying updates to network infrastructure devices.

• Restricting incoming/outgoing network requests/responses to reflect inappropriate or abusive access.

AttackBehavior > ResourceAttack > NetworkAttack > Access > CoreAccess > TCPTunnelingAccess

TCPTunnelingAccess alerts reflect a specific type of CoreAccess alert where the attack traffic is all TCP traffic and the intent is to tunnel a possible malicious or abusive connection through other TCP traffic.

TCP tunneling uses permitted TCP traffic to bypass access policies on network devices, content filtering, monitoring, and other traffic shaping or behavior policies. TCP tunneling is performed by initiating a known, 'acceptable' TCP connection through allowed policies and piggybacking an unacceptable connection atop the granted one.

On the new 'tunnel' that the user built, they are allowed to pass any traffic through that does not match other policies. Often, after the connection is initiated, it may be difficult to detect and prevent further malicious or abusive activity.

These alerts are generally provided by network-based intrusion detection systems. In some cases, they are provided by network infrastructure devices such as firewalls or routers.

The appropriate response to these alerts may include: 

• Blocking or resetting the local or remote user's connection/IP address, applying updates or patches to server and/or client software.

• Updating network infrastructure devices.

• Restricting incoming/outgoing network requests/responses to reflect inappropriate or abusive access.

AttackBehavior > ResourceAttack > NetworkAttack > Access > FileSystemAccess

FileSystemAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through remote file system traffic (using protocols such as SMB and NFS). Generally, these alerts reflect attempted exploitation of weaknesses in the remote file system server, client software, or attempts to gain system-level access to remote file system servers.

These alerts are generally provided by network-based intrusion detection systems, remote file system server, or client software.

The appropriate response to these alerts may include:

• Improving access control of remote file systems (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote file system servers and/or clients

• Removing the remote file system service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > FileSystemAccess > NFSAccess

NFSAccess alerts are a specific type of FileSystemAccess alert that reflects malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources through NFS (network file share) remote filesystem traffic. Generally, these alerts reflect attempted exploitation of weaknesses in the NFS server or client software or attempts to gain system-level access to NFS servers themselves.

These alerts are generally provided by network-based intrusion detection systems, the remote file system server, or the client software itself.

The appropriate response to these alerts may include:

• Improving access control of remote file systems (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote file system servers and/or clients.

• Removing the remote file system service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > FileSystemAccess > SMBAccess

SMBAccess alerts are a specific type of FileSystemAccess alert that reflects malicious or abusive usage of network resources where the intention or result is gaining access to resources through server message block (SMB) remote file system traffic. Generally, these alerts reflect attempted exploitation of weaknesses in the SMB server or client software or attempts to gain system-level access to SMB servers.

These alerts are generally provided by network-based intrusion detection systems, remote file system server, or the client software.

The appropriate response to these alerts may include.

• Improving access control of remote file systems (such restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote file system servers and/or clients

• Removing the remote file system service or client application related to this event.

AttackBehavior > ResourceAttack > NetworkAttack > Access > LinkControlAccess

LinkControlAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources where the related data is low-level link control (using protocols such as ARP). Generally, LinkControlAccess alerts reflect attempted exploitation of weaknesses in switching devices by using malformed incoming or outgoing data with the intent to enumerate or gain access to or through switching devices, clients that are also on the switching device, and entire networks attached to the switching device. In some cases, a managed switch with restrictions on port analyzing activity may be forced into an unmanaged switch with no restrictions, allowing a malicious client to sniff traffic and enumerate or attack.

These alerts are generally provided by network-based intrusion detection systems and network infrastructure devices with link level control (such as switches).

The appropriate response to LinkControlAccess events may include:

• Clearing the link-level control mechanisms of the switching device (such as flushing the ARP cache)

• applying updates or patches to switching devices

• Improving segmentation of networks to prevent information disclosure if an attack occurs

AttackBehavior > ResourceAttack > NetworkAttack > Access > PointToPointAccess

PointToPointAccess alerts reflect malicious or abusive usage of network resources where the intention ro result is gaining access to resources through point-to-point traffic (using protocols such as PPTP). Generally, these alerts will reflect attempted exploitation of weaknesses in point to point server or client software, attempts to enumerate networks, or attempts to further attack devices on trusted networks.

These alerts are generally provided by network-based intrusion detection systems. In some cases, network infrastructure devices such as firewalls, routers, or VPN servers may also provide them.

The appropriate response to these alerts may include:

• Improving access control of remote access services (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote access servers and/or clients

• Removing the remote point to point service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > PointToPointAccess > PPTPSpoof

PPTPSpoof alerts reflect a specific type of PointToPointAccess alert where the attack traffic is all point to point tunneling protocol (PPTP) traffic and the intent is to misrepresent the originating address to either bypass detection or misdirect response to attack activity. Often, the target of these attacks are internal trusted networks that allow remote access through PPTP tunneling.

PPTP spoofing is performed by falsifying network information to convince the destination (and any network hops in between) that the given source is something other than the actual source. Generally, while spoofed, clients attempt to gather information, perform actual attacks on internal devices, or perform denial of service attacks.

These alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers. Response to PPTP spoofing is difficult, as the originating host appears to be coming from a trusted address that completed initial handshaking and key sharing.

The initial appropriate response to these alerts may include:

• Blocking or resetting the local or remote user's connection/IP address

• Applying updates or patches to server and/or client software

• Applying updates to network infrastructure devices

• Restricting incoming/outgoing PPTP traffic requests/responses to reflect inappropriate or abusive access

AttackBehavior > ResourceAttack > NetworkAttack > Access > RemoteProcedureAccess

RemoteProcedureAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through remote procedure call traffic (using protocols such as the traditional RPC services, RMI, and CORBA). Generally, these alerts reflect attempted exploitation of weaknesses in the remote procedure server or client software or attempts to gain system-level access to remote procedure servers.

These alerts are generally provided by network-based intrusion detection systems, the remote procedure server, or the client software.

The appropriate response to these alerts may include:

• Improving access control of remote procedure (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote procedure servers and/or clients

• Removing the remote procedure service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > RemoteProcedureAccess > RPCPortmapperAccess

RPCPortmapperAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through remote procedure call traffic using the traditional RPC portmapper service.

Generally, these alerts reflect attempted exploitation of weaknesses in the remote procedure server or client software or attempts to gain system-level access to remote procedure servers themselves. These alerts are generally provided by network-based intrusion detection systems, the remote procedure server, or the client software.

The appropriate response to these alerts may include:

• Providing improved access control of remote procedure (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to remote procedure servers and/or clients

• Removing the remote procedure service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Access > RoutingAccess

RoutingAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources where the related data is routing-related protocols (RIP, IGMP, and so on). Generally, RoutingAccess alerts reflect attempted exploitation of weaknesses in routing protocols or devices with the intent to enumerate or gain access to or through routers, servers, clients, or other network infrastructure devices. These routing protocols are used to automate the routing process between multiple devices that share or span networks.

These alerts are generally provided by network-based intrusion detection systems and network infrastructure devices that use routing protocols, such as firewalls and routers.

The appropriate response to RoutingAccess events may include:

• Improving access control of the routing devices (such as restriction of what devices are allowed to update routing by IP address to ensure only trusted devices are passing data)

• Applying updates or patches to routing servers and/or devices

• Removing the automated routing protocols from servers and/or devices

AttackBehavior > ResourceAttack > NetworkAttack > Access > RoutingAccess > MalformedRIPAccess

MalformedRIPAccess alerts reflect malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources where the related data is all Routing Information Protocol (RIP).

Generally, MalformedRIPAccess alerts reflect attempted exploitation of weaknesses in RIP by using malformed incoming or outgoing data, with the intent to enumerate or gain access to or through routers, servers, clients, or other network infrastructure devices. RIP automates the routing process between multiple devices that share or span networks.

These alerts are generally provided by network-based intrusion detection systems and network infrastructure devices that use routing protocols such as firewalls and routers.

The appropriate response to RIP Access events may include:

• Improved access control of the routing devices (such as restriction of what devices are allowed to update routing by IP address to ensure only trusted devices are passing data).

• Apply updates or patches to routing servers and/or devices.

• Remove the automated routing protocols from servers and/or devices.

AttackBehavior > ResourceAttack > NetworkAttack > Access > TrojanTrafficAccess

TrojanTrafficAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through malicious code commonly known as a Trojan Horse.

This alert detects the communication related to trojans over the network (generally, trojaned clients calling home to the originator). Trojans are generally executables that generally require no user intervention to spread and contain malicious code that is placed on the client system and used to exploit the client (and return access to the originator of the attack) or exploit other clients (used in attacks such as distributed denial of service attacks).

These alerts are generally provided by a virus scanner, a network-based intrusion detection system, or in some cases, the operating system or network infrastructure devices such as firewalls and routers.

The appropriate response to these alerts may include:

• Quarantine the node from the network to prevent internal attacks and further compromise of the client system.

• Update the virus scanner pattern files on this and other network nodes to prevent future or further infection.

• Perform virus scans on this and other network nodes to detect further infection if any has taken place.

• Research into the offending Trojan to find out methods of removal (if necessary).

AttackBehavior > ResourceAttack > NetworkAttack > Access > TrojanTrafficAccess > TrojanCommandAccess

TrojanCommandAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through malicious code commonly known as Trojan Horses.

This alert detects the communication related to trojans sending commands over the network (infecting other clients, participating in a denial of service activity, being controlled remotely by the originator, and so on). Trojans are generally executables that generally require no user intervention to spread and contain malicious code that is placed on the client system and used to exploit the client (and return access to the originator of the attack) or exploit other clients (used in attacks such as distributed denial of service attacks).

These alerts are generally provided by a virus scanner, a network-based intrusion detection system, or in some cases, the operating system or network infrastructure devices such as firewalls and routers.

The appropriate response to these alerts may include:

• Quarantine the node from the network to prevent internal attacks and further compromise of the client system.

• Update virus scanner pattern files on this and other network nodes to prevent future or further infection.

• Perform virus scans on this and other network nodes to detect further infection if any has taken place.

• Research the offending trojan to find out methods of removal (if necessary).

AttackBehavior > ResourceAttack > NetworkAttack > Access > TrojanTrafficAccess > TrojanInfectionAccess

TrojanInfectionAccess alerts reflect malicious or abusive usage of network resources where the intention or result is gaining access to resources through malicious code commonly known as a Trojan Horse.

This alert detects the infection traffic related to a Trojan entering the network (generally with intent to infect a client). Trojans are generally executables that usually require no user intervention to spread. They contain malicious code that is placed on the client system. This code exploits the client (and return access to the originator of the attack) or exploit other clients (used in attacks such as distributed denial of service attacks).

These alerts are generally provided by a virus scanner, a network-based intrusion detection system, or in some cases, the operating system or network infrastructure devices such as firewalls and routers.

The appropriate response to these alerts may include:

• Quarantine the node from the network to prevent internal attacks and further compromise of the client system

• Update the virus scanner pattern files on this and other network nodes to prevent future or further infection, virus scans on this and other network nodes to detect further infection if any has taken place

• Research the offending trojan to find out methods of removal (if necessary)

AttackBehavior > ResourceAttack > NetworkAttack > Access > VirusTrafficAccess

VirusTrafficAccess alerts reflect malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources through malicious code commonly known as viruses.

This alert detects the communication related to viruses over the network (generally, the spread of a virus infection or an incoming virus infection). Viruses are generally executables that require user intervention to spread, contain malicious code that is placed on the client system, and exploit the client and possibly spread itself to other clients.

These alerts are generally provided by a virus scanner, a network-based intrusion detection system, or in some cases, the operating system or network infrastructure devices such as firewalls and routers.

Appropriate response to these alerts may include:

• Quarantine the node from the network to prevent internal attacks and further compromise of the client system

• Update the virus scanner pattern files on this and other network nodes to prevent future or further infection, virus scans on this and other network nodes to detect further infection if any has taken place

• Research the offending virus to find out methods of removal (if necessary)

AttackBehavior > ResourceAttack > NetworkAttack > Denial

Children of the Denial tree define events centered on malicious or abusive usage of network bandwidth/traffic where the intention or result is inappropriate or abusive access to network resources through a denial of service attack.

These alerts are generally provided by network-based intrusion detection systems, but an also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > ApplicationDenial

ApplicationDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is application-layer protocols. The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

ApplicationDenial events may be attempts to exploit weaknesses in software to gain access to a host system, attempts to exploit weaknesses in network infrastructure equipment to enumerate or reconfigure devices, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems. They can also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > ApplicationDenial > FileTransferDenial

FileTransferDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is application-layer file transfer-related protocols (FTP, TFTP, etc.). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

FileTransferDenial events may be attempts to exploit weaknesses in file transfer-related software to gain access to a host system, attempts to exploit weaknesses in the software to enumerate or reconfigure, or other denial of service activities. These alerts are generally provided by network-based intrusion detection systems. They can also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > ApplicationDenial > MailDenial

MailDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is application-layer mail-related protocols (SMTP, IMAP, POP3, etc.) or services (majordomo, spam filters, etc.). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

MailDenial events can be attempts to exploit weaknesses in mail-related software to gain access to a host system, attempts to exploit weaknesses in the software to enumerate or reconfigure, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems. They may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > ApplicationDenial > MailDenial > MailServiceDenial

MailServiceDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is application-layer mail-related services (majordomo, spam filters, and so on). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack. MailServiceDenial events can be attempts to exploit weaknesses in mail-related software to gain access to a host system, attempts to exploit weaknesses in the software to enumerate or reconfigure, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > ApplicationDenial > MailDenial > MailServiceDenial > MailSpamDenial

MailSpamDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is application-layer mail-related services (usually SMTP). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack through excessive mail relaying.

MailSpamDenial events reflect excessive attempts to relay mail through an SMTP server from remote sites that should not typically be relaying mail through the server, let alone excessive quantities of mail. The goal of these attacks may not be to enumerate or exploit weaknesses in the mail server, but to relay as much mail through an open relay mail server as quickly as possible, resulting in a denial of service attack.

These alerts are generally provided by network-based intrusion detection systems. They can also be provided by the mail server, firewalls, or other network infrastructure devices. These alerts can indicate an open relay on the network or an attempt to find an open relay. The appropriate response can be to restrict access to SMTP servers to only internal and necessary external IP addresses.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > ApplicationDenial > WebDenial

WebDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is application-layer web-related protocols (HTTP, HTTPS, and so on) or services (CGI, ASP, and so on). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

WebDenial events may be attempts to exploit weaknesses in web-related software to gain access to a host system, attempts to exploit weaknesses in the software to enumerate or reconfigure, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems. They can also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial

CoreDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is core protocols (TCP, IP, ICMP, UDP). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack. CoreDenial events may be attempts to exploit weaknesses in software to gain access to a host system, attempts to exploit weaknesses in network infrastructure equipment to enumerate or reconfigure devices, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems. They can also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > ChargenDenial

ChargenDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service through UDP character generator (chargen) or echo services.

This attack attempts to exploit network infrastructure devices and hosts by pointing two character generator (chargen) or echo hosts at each other. This process forces a multitude of responses. flooding the network and hosts. In response to a request to the echo or character generator (chargen) port, the second device sends a response, which triggers another request, which triggers a response, and so on. The source of the initial request is a spoofed IP address that appears as one of the hosts, which will be a party in the attack (sent to the second host). This will render both devices and possibly the network they are on useless either temporarily or for a significant amount of time by the sheer amount of traffic that is created.

ChargenDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > ICMPFloodDenial

ICMPFloodDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by an ICMPbased flood attack that uses several, very large ICMP packets.

The network infrastructure devices handling the traffic may pass on the traffic correctly. However, any vulnerable client or device on the network may not be able to process the incoming traffic (it may use up system resources to the point where the device is rendered useless and cannot accept network connections). Normal ICMP Traffic should not trigger an ICMPFloodDenial alert.

ICMPFloodDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > ICMPFragmentationDenial

ICMPFragmentationDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack by using several ICMP fragments (usually either much larger or smaller than normal fragments).

The network infrastructure devices handling the traffic will reassemble and pass on the traffic correctly. However, any vulnerable client on the network may not be able to reassemble the fragmented traffic (it may overflow the stack, triggering a host or service crash). Normal ICMP fragmentation (data that was disassembled because it is too large based on network parameters) should not trigger an ICMPFragmentationDenial alert.

Fragmentation alerts themselves are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > ICMPSourceQuenchDenial

ICMPSourceQuenchDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by an ICMP-based attack (which uses many ICMP packets set to type 4 - Source Quench).

The network infrastructure devices handling the traffic may pass on the traffic correctly. However, any client listening and responding to source quench traffic may be slowed down to the point where rendered useless by way of correct response to the quench request. Normal ICMP traffic (including single, normal, source quench packets) should not trigger an ICMPSourceQuenchDenial alert.

ICMPSourceQuenchDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > IPFloodDenial

IPFloodDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by an IP-based flood attack (which uses several, very large IP packets).

The network infrastructure devices handling the traffic may pass on the traffic correctly. However, any vulnerable client or device on the network may not be able to process the incoming traffic (it may use up system resources to the point where the device is rendered useless and cannot accept network connections). Normal IP Traffic should not trigger an IPFloodDenial alert.

IPFloodDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > IPFragmentationDenial

IPFragmentationDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack by using many IP fragments (usually either much larger or smaller than normal fragments).

The network infrastructure devices handling the traffic will reassemble and pass on the traffic correctly. However, any vulnerable client on the network may not be able to reassemble the fragmented traffic (it may overflow the stack, triggering a host or service crash). Normal IP fragmentation (data that was taken apart because it is too large based on network parameters) should not trigger an IPFragmentationDenial alert.

Fragmentation alerts themselves are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > IPFragmentationDenial > PingOfDeathDenial

PingOfDeathDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by a 'ping of death' attack (which uses many large ICMP Echo Request packets).

The network infrastructure devices handling the traffic will pass on the traffic correctly. However, any vulnerable client on the network may not be able to process the incoming traffic (it may be processed in such a way that triggers a host or service crash). Unpatched Windows NT and 95/98 clients are especially vulnerable to this type of attack.

NormalICMP Echo Traffic should not trigger a PingOfDeathDenial alert. PingOfDeathDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > LandAttackDenial

LandAttackDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by a land attack. This type of attack uses TCP traffic with the SYN bit set and the same source IP and port as the destination.

The network infrastructure devices handling the traffic will pass on the traffic correctly. However, any vulnerable client on the network may not be able to process the incoming traffic (it may be processed in such a way that triggers a host or service crash). Normal TCP traffic (with or without the SYN bit) should not trigger a LandAttackDenial alert.

LandAttackDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > SmurfDenial

SmurfDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by a 'Smurf' attack.

A Smurf attack attempts to exploit a vulnerability in some network infrastructure devices by sending ICMPEcho Requests to devices that will re-broadcast the traffic to internal devices. In response to the broadcast Echo Request, all of the devices will send an ICMP Echo Reply, which will effectively overflow the device.

The destination of the ICMP Echo Reply is a spoofed 'victim' IP address that will also be overflowed by the actual replies sent to their host. This will render both devices useless either temporarily or for a significant amount of time.

SmurfDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > SnorkDenial

SnorkDenial alerts reflect a specific type of CoreDenial alert where the intent, or the result, of this activity is inappropriate or abusive access to network resources through a denial of service by a 'Snork' attack.

A Snork attack attempts to exploit a vulnerability in Windows NT devices by using the Windows RPC service and sending packets to devices that will broadcast the traffic to other internal Windows NT devices using RPC. In response to the broadcast, all of the Windows NT devices will send another packet, and this process will continue until it effectively overflows the device and possibly the network.

The destination or source of the initial packet is a spoofed 'victim' IP address which will create the illusion of internal activity. This will render both devices useless either temporarily or for a significant amount of time.

SnorkDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > SynFloodDenial

SYNFloodDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by a TCP-based 'flood' attack. This attack uses several, very large TCP packets with the SYN bit set.

The network infrastructure devices handling the traffic may pass on the traffic correctly. However, any vulnerable client or device on the network may not be able to process the incoming traffic. It may use up system resources to the point where the device is rendered useless and cannot accept network connections. Normal TCP Traffic (with or without the SYN flag) should not trigger a SYNFloodDenial alert.

SYNFloodDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > TeardropDenial

TeardropDenial alerts reflect a specific type of CoreDenial alert where the intent or result of this activity is inappropriate or abusive access to network resources through a denial of service by a teardrop attack. This type of attack uses many overlapping IP fragments, usually either much larger or smaller than normal fragments.

The network infrastructure devices handling the traffic will reassemble and pass on the traffic correctly. However, any vulnerable client on the network may not be able to reassemble the fragmented traffic. The traffic may be reassembled in such a way that triggers a host or service crash. Normal IP fragmentation (data that was disassembled because it is too large based on network parameters) should not trigger a TeardropDenial alert.

TeardropDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > CoreDenial > UDPBombDenial

UDPBombDenial alerts reflect a specific type of CoreDenial alert where the iintent or result , of this activity is inappropriate or abusive access to network resources through a denial of service by a UDP-based 'bomb' attack. This type of attack uses sevaral large UDP packets.

The network infrastructure devices handling the traffic may pass on the traffic correctly. However, any vulnerable client or device on the network may not be able to process the incoming traffic. It may be processed in such a way that triggers a host or service crash. Normal UDP Traffic should not trigger a UDPBombDenial alert.

UDPBombDenial alerts are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > ConfigurationDenial

ConfigurationDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is protocols related to configuration of resources (DHCP, BootP, SNMP, etc.). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

ConfigurationDenial events may be attempts to exploit weaknesses in configuration-related software to gain access to a host system, attempts to exploit weaknesses in network infrastructure equipment to enumerate or reconfigure devices, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > FileSystemDenial

FileSystemDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is remote file system-related protocols (NFS, SMB, and so on). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

FileSystemDenial events may be attempts to exploit weaknesses in remote file system services or software to gain access to a host system, attempts to exploit weaknesses in network infrastructure equipment to enumerate or reconfigure devices, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > LinkControlDenial

LinkControlDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is link level protocols (such as ARP). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

LinkControlDenial events may be attempts to exploit weaknesses in link-level control software to gain access to a host system, attempts to exploit weaknesses in network infrastructure equipment to enumerate or reconfigure devices, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > RemoteProcedureDenial

RemoteProcedureDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is remote procedure-related protocols (traditional RPC, RMI, CORBA, etc.) or service (portmapper, etc.). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

RemoteProcedureDenial events may be attempts to exploit weaknesses in remote procedure services or software to gain access to a host system, attempts to exploit weaknesses in the software to enumerate or reconfigure, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > RemoteProcedureDenial > RPCPortmapperDenial

RPCPortmapperDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is remote procedure-related protocols specifically related to the RPC portmapper service. The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

RPCPortmapperDenial events may be attempts to exploit weaknesses the remote procedure service or software to gain access to a host system, attempts to exploit weaknesses in the software to enumerate or reconfigure, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > RoutingDenial

RoutingDenial events are a specific type of Denial event where the transport of the malicious or abusive usage is routing-related protocols (RIP, IGMP, etc.). The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

RoutingDenial events may be attempts to exploit weaknesses in routers or routing software to gain access to a host system, attempts to exploit weaknesses in the routing software or service to enumerate or reconfigure, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Denial > TrojanTrafficDenial

TrojanTrafficDenial events are a specific type of Denial event where the transport of the malicious or abusive usage originates with malicious code on a client system known as a Trojan. The intent or result of this activity is inappropriate or abusive access to network resources through a denial of service attack.

TrojanTrafficDenial events may be attempts to exploit weaknesses in software to gain access to a host system, attempts to exploit weaknesses in network infrastructure equipment to enumerate or reconfigure devices, attempts to spread the Trojan to other hosts, or other denial of service activities.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Relay

Children of the Relay tree define events centered on malicious or abusive usage of network bandwidth/traffic where the intent or result is relaying inappropriate or abusive access to other network resources (either internal or external).

Generally, these attacks will have the perimeter or an internal host as their point of origin. When sourced from remote hosts, they may indicate a successful exploit of an internal or perimeter host.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

AttackBehavior > ResourceAttack > NetworkAttack > Relay > DDOSToolRelay

DDOSToolRelay events reflect potential network traffic related to known Distributed Denial of Service connectors. These connectors are used to relay attacks to new remote (and possibly local) hosts to exploit or inundate the remote host with data in an attempt to cripple it.

Generally, these attacks will have a perimeter or an internal host as their point of origin. When sourced from remote hosts, they may indicate a successful exploit of an internal or perimeter host.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by firewalls or other network infrastructure devices.

The appropriate response to these events may include: 

• Restrict the source from accessing any external network

• Run a virus scanner or other detection utility to detect and remove the presence of any relay connector (in some cases known as a 'zombie')

• Quarantine the source node from the network to further isolate the issue (if necessary)

If these events are sourced from a completely external network, the appropriate actions may include:

• Blocking the remote host

• Provide better access control of clients, servers, and services, such as restriction by IP address and/or user name to ensure only trusted clients can connect

• Apply updates or patches to servers and/or clients

• Remove the service related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Relay > FileTransferRelay

FileTransferRelay events reflect potential network traffic related to known attack connectors that operate over file transfer protocols. These connectors are used to relay attacks to new remote (and possibly local) hosts to exploit or abuse services.

Generally, these attacks will have a perimeter or an internal host as their point of origin. When sourced from remote hosts, they may indicate a successful exploit of an internal or perimeter host.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by the file transfer software itself, and firewalls or other network infrastructure devices.

The appropriate response to these events may include: 

• Restrict the source from accessing any external network

• Run a virus scanner or other detection utility to detect and remove the presence of any relay connector

• Quarantine the source node from the network to further isolate the issue (if necessary)

If these events are sourced from a completely external network, the appropriate actions may include:

• Blocking the remote host, better access control of file transfer servers (such as restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to file transfer servers and/or clients

• Removing the file transfer service or client application related to this event

AttackBehavior > ResourceAttack > NetworkAttack > Relay > FileTransferRelay > FTPBounce

FTPBounce events are a specific type of FileTransferRelay related to known attack connectors using file transfer protocols that are used to launder connections to other services, redirect attacks to other hosts or services, or to redirect connections to other hosts or services.

Generally, these attacks will have a perimeter or an internal host as their point of origin. When sourced from remote hosts, they may indicate a successful exploit of an internal or perimeter host.

These alerts are generally provided by network-based intrusion detection systems, but may also be provided by the file transfer software or service itself, and firewalls or other network infrastructure devices.

The appropriate response to these events may include:

• Restrict the source from accessing any external network

• Run a virus scanner or other detection utility to detect and remove the presence of any relay connector

• Quarantine the source node from the network to further isolate the issue (if necessary)

If these events are sourced from a completely external network, the appropriate actions may include:

• Blocking the remote host

• Providing better access control of file transfer servers (such restriction by IP address and/or user name to ensure only trusted clients are connecting)

• Applying updates or patches to file transfer servers and/or clients

• Removing the file transfer service or client application related to this event

AttackBehavior > ResourceAttack > ServiceProcessAttack

Members of the ServiceProcessAttack tree define events centered on malicious or abusive usage of services or user processes. These events include abuse or misuse of resources from malicious code placed on the client system.

AttackBehavior > ResourceAttack > ServiceProcessAttack > VirusAttack

VirusAttack alerts reflect malicious code placed on a client or server system, which may lead to system or other resource compromise and further attack. The severity of this alert depends on the ActionTaken field, which reflects whether the virus or other malicious code was successfully removed.

These alerts are usually provided by a virus scanner running on the client system. The appropriate response to these alerts may include:

• Quarantine the node from the network to prevent further outbreak

• Update the virus scanner pattern files on other network nodes to prevent further outbreak

• Run virus scans on other network nodes to detect further outbreak if any has taken place

• Research the offending virus to discover removal methods

AttackBehavior > ResourceAttack > ServiceProcessAttack > VirusSummaryAttack

VirusSummaryAttack alerts reflect malicious code placed on a client or server system, which may lead to system or other resource compromise and further attack. The severity of this alert depends on the ActionTaken field that reflects whether the virus or other malicious code was successfully removed. These alerts differ from VirusAttack in that they may be a composite of virus events normally due to a scheduled scan on the client system as opposed to a real-time scan.

These alerts are usually provided by a virus scanner running on the client system. Appropriate response to these alerts may include: 

• Quarantine the node from the network to prevent further outbreak

• Update the virus scanner pattern files on other network nodes to prevent further outbreak

• Run virus scans on other network nodes to detect further outbreak if any has taken place

• Research into the offending virus to discover removal methods

GeneralSecurity

GeneralSecurity alerts are generated when a supported product outputs data is not normalized into a specific alert, but is known to be a security-related issue.

SuspiciousBehavior

Events that are children of SuspiciousBehavior are generally related to network activity that may be consistent of:

• Enumeration of resources

• Unexpected traffic

• Abnormal authentication events

• Other abnormal behavior that should be considered indicative of a serious security event

SuspiciousBehavior > AuthSuspicious

Members of the AuthSuspicious tree define events regarding suspicious authentication and authorization events. These events include:

• Excessive failed authentication or authorization attempts

• Suspicious access to unauthenticated users

• Suspicious access to unauthorized services or information

SuspiciousBehavior > AuthSuspicious > FailedAuthentication

FailedAuthentication events occur when a user makes several attempts to authenticate themselves and continuously fails, or when a logon failure is serious enough to merit a security event on a single failure.

SuspiciousBehavior > AuthSuspicious > GuestLogin

GuestLogin events describe user authentication events where a successful or unsuccessful attempt was made to grant access to a user that generally has no assigned password (such as anonymous, guest, or default) and no special privileges. A user with this privilege level may be granted access to enough of the client system to begin exploitation.

These events are usually produced by a client or server operating system. However, they may also be produced by a network-based IDS or network infrastructure device when it is possible or appropriate.

SuspiciousBehavior > AuthSuspicious > RestrictedInformationAttempt

RestrictedInformationAttempt events describe a user attempt to access local or remote information that their level of authorization does not allow. These events may indicate user attempts to exploit services that they are denied to or inappropriate access attempts to restricted information.

SuspiciousBehavior > AuthSuspicious > RestrictedServiceAttempt

RestrictedServiceAttempt events describe a user attempt to access a local or remote service that their level of authorization does not allow. These events may indicate user attempts to exploit services that they are denied access to or inappropriate access attempts to services.

SuspiciousBehavior > InferredSuspicious

InferredSuspicious alerts are reserved SuspiciousBehavior alerts used to describe suspicious behavior that is a composite of different types of alerts. These events are defined and inferred by policy.

SuspiciousBehavior > ResourceSuspicious

Members of the ResourceSuspicious tree define different types of suspicious access to network resources. These resources may include network bandwidth/traffic, files, client processes or services, or other types of shared security-related commodities.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious

Members of the NetworkSuspicious tree define events regarding suspicious usage of network bandwidth/traffic. These events include unusual traffic and reconnaissance behavior detected on network resources.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon

Children of the Recon tree reflect suspicious network behavior with the intent of gathering information about target clients, networks, or hosts.

Reconnaissance behavior may be valid behavior on a network. However, only as a controlled behavior in small quantities. Invalid reconnaissance behavior can reflect attempts to determine security flaws on remote hosts, missing access control policies that allow external hosts to penetrate networks, or other suspicious behavior that results in general information gathering without actively attacking.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate

Enumerate alerts reflect attempts to gather information about target networks (or specific target hosts) by sending active data that elicit responses and reveal information about clients, servers, or other network infrastructure devices. The originating enumeration source is generally attempting to acquire information that may reveal more than what is revealed by normal traffic to the target.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > ApplicationEnumerate

ApplicationEnumerate alerts reflect attempts to gather information about target hosts, or services on target hosts, by sending active application-layer data which will elicit responses that reveal information about the application or host. This enumeration may be a LEMple command sent to the application to attempt to fingerprint what is allowed or denied by the service, requests to the application which may enable an attacker to surmise the version and specific application running, and other information gathering tactics.

These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the host or application that may work correctly the first time. This process enables them to modify their methodology to continue relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > ApplicationEnumerate > FileTransferEnumerate

FileTransferEnumerate alerts reflect attempts to gather information about target hosts, or services on target hosts, by sending active application-layer data to file transfer services that elicit responses and reveal information about the application or host.

This enumeration may be a simple command sent to the file transfer service to attempt to fingerprint what is allowed or denied by the service, requests to the file transfer service that may enable an attacker to surmise the version and specific service running, and other information gathering tactics.

These enumerations may result in providing Information that allows an attacker to craft a specific attack against the file transfer service or application that may work correctly the first time. This enables them to modify their methodology to continue relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > ApplicationEnumerate > FileTransferEnumerate > FTPCommandEnumerate

FTPCommandEnumerate alerts reflect attempts to gather information about target hosts (or services on target hosts) by sending active application-layer data to file transfer services that elicit responses and reveal information about the application.

This enumeration specifically includes commands sent to the FTP service to attempt to fingerprint what is allowed or denied by the service, requests to the FTP service that may enable an attacker to surmise the version and specific service running, and other information gathering tactics that use FTP commands to query. These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the FTP service that may work correctly the first time, enabling them to modify their methodology to continue relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > ApplicationEnumerate > MailEnumerate

MailEnumerate alerts reflect attempts to gather information about target hosts (or services on target hosts) by sending active application-layer data to mail-related services that will elicit responses and reveal information about the application or host.

This enumeration may be a simple command sent to the mail service to attempt to fingerprint what is allowed or denied by the service, requests to the mail service that may enable an attacker to surmise the version and specific service running, and other information gathering tactics. These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the mail service or application that may work correctly the first time - enabling them to modify their methodology to go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > ApplicationEnumerate > MailEnumerate > SMTPCommandEnumerate

SMTPCommandEnumerate alerts reflect attempts to gather information about target hosts, or services on target hosts, by sending active application-layer data to mail-related services that will elicit responses and reveal information about the application.

This enumeration specifically entails commands sent to the SMTP service to attempt to fingerprint what is allowed or denied by the service, requests to the mail service that may enable an attacker to surmise the version and specific service running, and other information gathering tactics that use SMTP commands to query. These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the mail service that may work correctly the first time - enabling them to modify their methodology to go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > ApplicationEnumerate > WebEnumerate

WebEnumerate alerts reflect attempts to gather information about target hosts (or services on target hosts) by sending active application-layer data to web-related services that will elicit responses and reveal information about the application or host.

This enumeration may be a simple command sent to the web service to attempt to fingerprint what is allowed or denied by the service, requests to the web service that may enable an attacker to surmise the version and specific service running, and other information gathering tactics. These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the web service or application that may work correctly the first time , enabling them to modify their methodology to go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > BannerGrabbingEnumerate

BannerGrabbingEnumerate alerts reflect attempts to gather information about target hosts (or services on target hosts) by sending a request that will elicit a response containing the host or service's 'banner'.

This 'banner' contains information that may provide a potential attacker with details such as the exact application and version running behind a port. These details could be used to craft specific attacks against hosts or services that an attacker may know will work correctly the first time , enabling them to modify their methodology go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > MSNetworkingEnumerate

MSNetworkingEnumerate alerts reflect attempts to gather information about target hosts, or services on target hosts, by sending active data to Microsoft networking services (using protocols such as NetBIOS and SMB/CIFS) that will illicit responses that reveal information about the application, host, or target network.

This enumeration may be a simple command sent to the networking service to attempt to fingerprint what is allowed or denied by a service, requests to a service that may enable an attacker to surmise the version and specific service running, requests to a service that may enable an attacker to fingerprint the target network, and other information gathering tactics.

These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the networking service, host, or application that may work correctly the first time, enabling them to modify their methodology to go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > RemoteProcedureEnumerate

RemoteProcedureEnumerate alerts reflect attempts to gather information about target hosts (or services on target hosts) by sending active data to Remote Procedure services (using protocols such as RMI, CORBA, and traditional RPC) that elicit responses and reveal information about the application or host.

This enumeration may be a simple command sent to the remote procedure service to attempt to fingerprint what is allowed or denied by the service, requests to the remote procedure service that may enable an attacker to surmise the version and specific service running, and other information gathering tactics.

These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the remote procedure service or application that may work correctly the first time - enabling them to modify their methodology to go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > RemoteProcedureEnumerate > RPCPortmapperEnumerate

RPCPortmapperEnumerate alerts reflect attempts to gather information about target hosts, or services on target hosts, by sending active data to the Portmapper Remote Procedure service that will illicit responses that reveal information about the application or host.

This enumeration may be a simple command sent to the portmapper service to attempt to fingerprint what is allowed or denied by the service, requests to the portmapper service that may enable an attacker to surmise the version and specific service running, and other information gathering tactics.

These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the portmapper service or client application that may work correctly the first time, enabling them to modify their methodology to go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Enumerate > RemoteProcedureEnumerate > RPCPortScanEnumerate

RPCPortScanEnumerate alerts reflect attempts to gather information about target hosts (or services on target hosts) by sending active data to Remote Procedure services (using protocols such as RMI, CORBA, and traditional RPC) that will elicit responses that reveal information about the application or host.

This specific type of enumeration is performed by sending queries to RPC related ports to attempt to fingerprint the types and specific services running, and may involve other information gathering tactics.

These enumerations may result in information being provided that can allow an attacker to craft a specific attack against the remote procedure service or application that may work correctly the first time - enabling them to modify their methodology to go on relatively undetected.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Footprint

Footprint alerts reflect attempts to gather information about target networks by tracing the network through routers, clients, servers, or other network infrastructure devices. The originating source of the footprint is generally attempting to acquire information that may reveal more about network behavior than normal traffic to the target would.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Footprint > DNSRequestFootprint

DNSRequestFootprint alerts are a specific type of Footprint alert that reflects a DNS record request that may serve to reveal the DNS configuration. Contained within this DNS configuration may be information that reveals internal networks, protected devices, or IP addresses of potential targets.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Footprint > FirewalkingFootprint

FirewalkingFootprint alerts are a specific type of Footprint alert that reflects the usage of a connector that attempts to gather information about network infrastructure device access control and filtering lists.

Firewalking works by passing TCP and UDP packets to determine what packets a given device will forward. This activity may reflect attempts to enumerate devices beyond the perimeter of a network, gathering information about activity that is allowed or denied past given gateways.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Footprint > TraceRouteFootprint

TraceRouteFootprint alerts are a specific type of Footprint alert that reflects an IP packet route trace from source to destination. Generally, this route will not reveal specific information about device types or hosts on a network, but will trace the path of IP traffic across routing devices. This traffic may be an attempt to discover routing devices that are misconfigured (which may be vulnerable to attacks such as IP spoofing or IP fragmentation).

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan

Scan alerts reflect attempts to gather information about target networks (or specific target hosts) by sending scans that will elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include a list of applications listening on ports, operating system information, and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan

CoreScan alerts reflect attempts to gather information about target networks (or specific target hosts) by sending scans over core network protocols (TCP, IP, ICMP, UDP) that will elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include a list of applications listening on ports, operating system information, and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > HostScan

HostScan alerts reflect attempts to gather information about specific target hosts by sending scans which will elicit responses that reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include a list of applications on the host, operating system information, and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

These scans generally do not occur across entire networks and generally have the intent of discovering operating system and application information which may be used for further attack preparation.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > ICMPQuery

ICMPQuery alerts reflect attempts to gather information about specific target hosts (or networks) by sending ICMP-based queries that will elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include operating system information and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

These scans generally do not occur across entire networks, contain many sequential ICMP packets, and generally have the intent of discovering operating system and application information which may be used for further attack preparation.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > PingSweep

PingSweep alerts reflect a specific type of CoreScan alert that describe an attempt to gather information about target networks, and hosts on those networks, by sending ICMP or TCP ping packets to test whether hosts are alive.

The originating source of the scan is generally attempting to acquire information about network topology or groups of specific hosts on the network, and may have the intent of gathering information for future attack attempts.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > PingSweep > ICMPPingSweep

ICMPPingSweep alerts reflect a specific type of CoreScan alert that describe an attempt to gather information about target networks, and hosts on those networks, by sending ICMP ping packets to test whether hosts are alive.

The originating source of the scan is generally attempting to acquire information about network topology or groups of specific hosts on the network, and may have the intent of gathering information for future attack attempts.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > PingSweep > TCPPingSweep

TCPPingSweep alerts reflect a specific type of CoreScan alert that describe an attempt to gather information about target networks, and hosts on those networks, by sending TCP ping packets to test whether hosts are alive.

The originating source of the scan is generally attempting to acquire information about network topology or groups of specific hosts on the network and may have the intent of gathering information for future attack attempts.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > PortScan

PortScan alerts reflect attempts to gather information about target networks, or specific target hosts, by sending scans over core network protocols (TCP, IP, ICMP, UDP) that will elicit responses that reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include a list of applications listening on ports, operating system information, and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

Portscans specifically operate by sending probes to every port within a range, attempting to identify open ports that may use applications or services that are easy to enumerate and attack.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > PortScan > TCPPortScan

TCPPortScan alerts reflect attempts to gather information about target networks (or specific target hosts) by sending scans over TCP that will elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target would. This information can include a list of applications listening on ports, operating system information, and other information that a probe may discover without enumeration of the specific services or performing attack attempts. TCP portscans specifically operate by sending TCP probes to every port within a range, attempting to identify open ports that may use applications or services that are easy to enumerate and attack.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > PortScan > UDPPortScan

UDPPortScan alerts reflect attempts to gather information about target networks (or specific target hosts) by sending scans over UDP that will elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include a list of applications listening on ports, operating system information, and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

UDP portscans specifically operate by sending UDP probes to every port within a range, attempting to identify open ports that may use applications or services that are easy to enumerate and attack.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > StackFingerprint

StackFingerprint alerts reflect attempts to gather information about specific target hosts by sending a certain set of packets to probe a device's network stack that will elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include operating system information (including type and version) and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

These scans generally do not occur across entire networks and generally have the intent of discovering operating system information, which may be used for further attack preparation.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > StackFingerprint > ICMPStackFingerprint

ICMPStackFingerprint alerts reflect attempts to gather information about specific target hosts by sending a certain set of ICMP packets to probe a device's ICMP stack that elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include operating system information (including type and version) and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

These scans generally do not occur across entire networks and generally have the intent of discovering operating system information, which may be used for further attack preparation.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > CoreScan > StackFingerprint > TCPStackFingerprint

TCPStackFingerprint alerts reflect attempts to gather information about specific target hosts by sending a certain set of TCP packets to probe a device's TCP/IP stack that elicit responses and reveal information about clients, servers, or other network infrastructure devices.

The originating source of the scan is generally attempting to acquire information that may reveal more than normal traffic to the target. This information can include operating system information (including type and version) and other information that a probe may discover without enumeration of the specific services or performing attack attempts.

These scans generally do not occur across entire networks and generally have the intent of discovering operating system information, which may be used for further attack preparation.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > Recon > Scan > TrojanScanner

TrojanScanner alerts reflect attempts of Trojans on the network to gather information about target networks (or specific target hosts) by sending scans that elicit responses and reveal information about the host.

The originating Trojan source of the scan is generally attempting to acquire information that reveals whether a target host or network has open and available services for further exploitation, whether the target host or network is alive, and how much of the target network is visible. A Trojan may run a scan before attempting an attack operation to test potential effectiveness or targeting information.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > UnusualTraffic

UnusualTraffic alerts reflect suspicious behavior on network devices where the traffic may have no known exploit, but is unusual and could be potential enumerations, probes, fingerprints, attempts to confuse devices, or other abnormal traffic.

UnusualTraffic may have no impending response. However, it could reflect a suspicious host that should be monitored closely.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > UnusualTraffic > UnusualICMPTraffic

UnusualICMPTraffic alerts reflect ICMP-based suspicious behavior on network devices where the traffic may have no known exploit, but is unusual and could be potential enumerations, probes, fingerprints, attempts to confuse devices, or other abnormal traffic.

UnusualICMPTraffic may have no impending response. However, it could reflect a suspicious host that should be monitored closely.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > UnusualTraffic > UnusualIPTraffic

UnusualIPTraffic alerts reflect IP-based suspicious behavior on network devices where the traffic may have no known exploit, but is unusual and could be potential enumerations, probes, fingerprints, attempts to confuse devices, or other abnormal traffic.

UnusualIPTraffic may have no impending response, however, it could reflect a suspicious host that should be monitored closely.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > UnusualTraffic > UnusualProtocol

UnusualProtocol alerts reflect suspicious behavior on network devices where the traffic is targeted at unknown, unassigned, or uncommonly used protocols. This traffic may have no known exploit, but is unusual and should be considered potential enumerations, probes, fingerprints, attempts to confuse devices, or other abnormal traffic.

UnusualProtocol may have no impending response. However, it could reflect a suspicious host that should be monitored closely.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > UnusualTraffic > UnusualTCPTraffic

UnusualTCPTraffic alerts reflect TCP-based suspicious behavior on network devices where the traffic may have no known exploit, but is unusual and could be potential enumerations, probes, fingerprints, attempts to confuse devices, or other abnormal traffic.

UnusualTCPTraffic may have no impending response. However, it could reflect a suspicious host that should be monitored closely.

SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious > UnusualTraffic > UnusualUDPTraffic

UnusualUDPTraffic alerts reflect UDP-based suspicious behavior on network devices where the traffic may have no known exploit, but is unusual and could be potential enumerations, probes, fingerprints, attempts to confuse devices, or other abnormal traffic.

UnusualUDPTraffic may have no impending response. However, it could reflect a suspicious host that should be monitored closely.