Submit a ticketCall us

Webinar: Web Help Desk for HR, Facilities and Accounting Departments
This webinar will focus on use cases for HR, Facilities and Accounting.

Having a unified ticketing and asset management system for all the departments in your company can provide end-users with a seamless experience and make things easier for your IT team. Yet, with different business tasks and objectives, many departments don’t fully understand the capabilities of Web Help Desk and how the software can be customized for effective use in their departments.
Register Now.

Home > Success Center > Log & Event Manager (LEM) > SolarWinds LEM 6.3 User Guide > Event type descriptions

Event type descriptions

Created by Caroline Juszczak, last modified by Caroline Juszczak on Sep 21, 2017

Views: 105 Votes: 2 Revisions: 12

Updated March 11th, 2016

 

This topic describes every event type that is displayed in the Events Panel and that can be configured with the Policy commands.

 

LEM reports events in a hierarchical node tree, shown below. When you click a node to open it, you see that most nodes also have lower-level nodes. Each node that has lower-level nodes is called a parent node. Similarly, all lower-level nodes below a particular parent node are child nodes or children to that parent node. The term parent and child applies to the node, relative to its position and role on the node tree. A node can be a child to one node, and a parent to others.

File:Classic_Support/Security_&_Compliance/01Log_&_Event_Manager_(LEM)/LEMUserGuide_MT/0I0/Policies-Collapsed75.png

LEM automatically assigns alerts to the nodes of the alert tree based on the specific nature of the alert and its severity.

Event types

There are five types of events.

  • Asset Events relate to the changing state of different types of enterprise assets, including software, hardware, and users. These alerts can indicate changes made to system configurations, software updates, patch applications, vulnerability information, and other system events.
  • Audit Events are 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 that might be considered a security event.
  • Incident Events are used to 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 are related to the operation of the LEM system. Any events generated by LEM relating to Active Response, LEM users, or LEM errors appear under one of the many children. These alerts are for informational purposes. They do not necessarily reflect conditions that should cause alarm. Events that might reflect potential issues within LEM are specifically marked for forwarding to SolarWinds.
  • Security Events are related to 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. LEM 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.

Asset Events

Asset Events deal with 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, or it can be scan information from security scan connectors, including Vulnerability Assessment and Patch Management connectors. Therefore, these alerts indicate changes made to system configurations, software updates, patch applications, vulnerability information, and other system events.

 

Each Asset Event is described below, listed alphabetically.

  • AssetManagement
    • AssetManagement alerts are for gathering non-realtime data about system assets (computer, software, users). The data will come 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 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 has not yet been normalized into a specific alert, but is known to be asset issue-related.

Audit Events

Events that are children of AuditEvent node 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.

 

Each Audit Event is described below, listed alphabetically.

  • AuthAudit
    • Events that are part of the AuthAudit tree 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.
  • 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, and 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 initiation of a system scan.
  • MachineAudit > SystemScanStop
    • SystemScanStop is a specific type of SystemScan alert that indicates completion of a system scan. 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.
  • 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 could be produced by any network device.
  • AuthAudit > DomainAuthAudit > NewDomainMember
    • NewDomainMember events occur when an account or account container has been added to a domain. Usually, these additions are made by a user account with administrative privileges, but occasionally a NewDomainMember alert will also happen when local system maintenance activity takes place.
  • AuthAudit > DomainAuthAudit > DeleteDomainMember
    • DeleteDomainMember events occur when an account or account container has been removed from a domain. Usually, these changes are made by a user account with administrative privileges, but occasionally a DeleteDomainMember alert will also happen 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, but occasionally a ChangeDomainMember alert will also happen when local system maintenance activity takes place.
  • AuthAudit > DomainAuthAudit > ChangeDomainMember > DomainMemberAlias
    • DomainMemberAlias events happen 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.
    • The alias for a domain member has been changed.
  • AuthAudit > DomainAuthAudit > NewDomain
    • NewDomain events occur upon creation of a new trust relationship between domains, creation of a new subdomain, or creation of new account containers 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, but occasionally a ChangeDomainAttribute alert will also happen when local system maintenance activity takes place.
  • AuthAudit > DomainAuthAudit > DeleteDomain
    • DeleteDomain events occur upon removal of a trust relationship between domains, deletion of a subdomain, or deletion of account containers within a domain. Usually, these changes are made 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 could 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, but occasionally a ChangeGroupAttribute alert will also happen when local system maintenance activity takes place.
  • AuthAudit > GroupAudit > DeleteGroup
    • DeleteGroup events occur upon deletion of a new group of any type. Usually, these deletions are made by a user account with administrative privileges.
  • AuthAudit > GroupAudit > DeleteGroupMember
    • DeleteGroupMember events occur when an account or group has been removed from a group. Usually, these changes are made by a user account with administrative privileges, but occasionally a DeleteGroupMember alert will also happen when local system maintenance activity takes place.
  • AuthAudit > GroupAudit > NewGroup
    • NewGroup events occur upon creation of a new group of any type. Usually, these additions are made by a user account with administrative privileges.
  • AuthAudit > GroupAudit > NewGroupMember
    • NewGroupMember events occur when an account (or other group) has been added to a group. Usually, these additions are made by a user account with administrative privileges, but occasionally a NewGroupMember alert will also happen when local system maintenance activity takes place.
    • A new user, machine, or service account has been 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, but are normally operating system related.
  • 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 will reflect the point on the network where the computer or machine was attempting logon. In larger quantities, these alerts may reflect a potential issue with a computer or set of computers, but as individual events they are generally not a problem.
  • AuthAudit > MachineAuthAudit > MachineAuthTicket
    • MachineAuthTicket alerts reflect computer or machine account ticket events from network devices monitored by Contego that use a ticket-based single-sign-on system (such as Kerberos or Windows domains). Each alert will reflect 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 other 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 OS-related and will trigger 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 will reflect 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 will reflect the point on the network where the computer or machine was attempting logon. In larger quantities, these alerts may reflect a potential issue with a computer or set of computers, but 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 by Contego (including network infrastructure devices, when appropriate). Each alert will reflect the type of device that the logon was intended for along with all other relevant fields. These events are normally operating system related.
  • 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 related only 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 will reflect the point on the network where the user was attempting logon. In larger quantities, these alerts may reflect a potential issue with a user or set of users, but as individual events they are generally not a problem.
  • AuthAudit > UserAuthAudit > UserAuthTicket
    • UserAuthTicket alerts reflect user account ticket events from network devices monitored by Contego that use a ticket-based single-sign-on system (such as Kerberos or Windows domains). Each alert will reflect 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 other authentication connector. These events are usually operating system related and could 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 OS-related and will trigger both 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 will reflect 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 network devices monitored by Contego (including network infrastructure devices). Each alert will reflect 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 will reflect the point on the network where the user was attempting logon. In larger quantities, these alerts may reflect a potential issue with a user or set of users, but 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 are used to 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 OS 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 that reflects a more current version of software being installed to replace an older version.
  • 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 that is 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 that is used to audit system shutdowns, including both expected and unexpected shutdowns. In the event the shutdown was unexpected, the event detail will note 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, 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. Usually these modifications are made by a user with administrative privileges, but 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, but 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 are used to 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 are used to track failed file activity on monitored network devices, usually through the Operating System or a Host-Based 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 that is 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 that is 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 that is 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 will note 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 that has 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 filesystem mapping events and usage of filesystem 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 filesystem. 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 filesystem. These events are generally normal during system shutdown.
  • ResourceAudit > NetworkAudit
    • Members of the NetworkAudit tree are used to define events centered on usage of network resources/bandwidth.
  • ResourceAudit > NetworkAudit > ConfigurationTrafficAudit
    • ConfigurationTrafficAudit alerts reflect application-layer data related to 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 all 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 itself 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 Contego Policy has been 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 Contego Policy has been 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 Contego Policy has been 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 filesystems, using protocols such as SMB and NFS.
    • FileSystemTrafficAudit alerts generally indicate normal traffic for networks that have remote filesystem 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 filesystem 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 itself 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 has been encrypted and is 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/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 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 filesystem 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, and other services which 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 are used to 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 are used to 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. Usually, these events 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 has exited. Usually, ProcessStop reflects normal application exit, however in the event of an unexpected error the abnormal state will be noted.
  • ResourceAudit > ProcessAudit > ProcessStart
    • ProcessStart is a specific type of ProcessAudit alert that indicates a new process has been launched. Usually, ProcessStart 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. Usually, these events reflect normal system activity. System service-related activity that may indicate a failure will be 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.

 

Each Incident alert is described below, listed alphabetically.

  • HostIncident
    • HostIncident alerts reflect global enterprise-wide host system issues that should be raised for system-wide visibility. These alerts are used to 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 are used to 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.

 

Each Internal Event is described below, listed alphabetically.

  • InternalAudit
    • InternalAudit alerts reflect attempted accesses and changes to components of the LEM system by existing SolarWinds users. Both successful and failed attempts will generate alerts in this part of the tree.
  • 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 will include the user, type of access, and item being accessed. InternalAuditFailure events are uncommon and can indicate an attempted privilege escalation within the LEM 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 LEM 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 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 which 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 not expected. 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 which 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 yet 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 are happening 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 disconnection of an Agent to its Manager. These alerts will happen when the Manager has detected that the Agent closed the connection, whether that be due to network down time of the Agent or due to a shut down of the Agent service.
  • InternalInfo > InternalAgentOnline
    • InternalAgentOnline alerts reflect successful connection of Agents to their respective Managers. These alerts will happen when an Agent initiates successful communication with the Manager, whether that be due to network down time of the Manager or Agent or due to an update of the Agent in question.
  • InternalInfo > InternalDuplicateConnection
    • InternalDuplicateConnection alerts occur when an Agent has attempted to connect to their given Manager more than once. Usually these alerts are 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).
    • Usually this issue can 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 has already been applied to the Manager.
    • Please ensure that the indicated Agent has been 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.
    • Please ensure that the indicated Agent has been 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 > InternalLicenseMaximum
    • InternalLicenseMaximum alerts reflect an attempt to add more Agents to a Manager than that Manager is licensed for. 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 needed, this issue can be resolved by contacting SolarWinds Sales for an update.
  • InternalInfo > InternalNewToolData
    • InternalNewToolData alerts generally reflect issues related to connectors with unexpected log entries or other conditions that were not expected. These issues generally cannot be solved without contacting SolarWinds, however they are not fatal.
  • InternalInfo > InternalPolicyConfiguration
    • InternalPolicyConfiguration alerts reflect successful or unsuccessful attempts to update Policy on a given Manager. These alerts are generated after Policy has been successfully installed to the Manager or after an error has been detected. Generally, an error in updating Policy will also produce an alert from the InternalFailure family, providing more information.
  • InternalInfo > InternalToolOffline
    • InternalToolOffline alerts reflect successful stop of an Internal Tool. These alerts are generated after a connector has stopped 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 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 will produce an alert from the InternalFailure family providing more information.
  • InternalInfo > InternalUnknownAgent
    • InternalUnknownAgent alerts occur when an Agent that the Manager does not recognize has 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 that case, they may reflect Agents that have not yet been brought up to date.
    • Usually this issue can 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 Agent in question failed to properly negotiate its connection or respond to a query and has been assumed to be missing a feature required of it. Please ensure that the indicated Agent has been upgraded to the same release version of SolarWinds 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 > 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 via the Console. Failed log-on attempts are produced in a separate alert, InternalUserLogonFailure.
  • InternalInfo > InternalUserLogonFailure
    • InternalUserLogonFailure alerts are generated when a user has completed 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 has successfully been 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 are used to indicate that a rule has been triggered, either in test mode or in normal operating conditions.
  • InternalPolicy > InternalTestRule
    • InternalTestRule alerts reflect rule activity where a correlation rule has 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 were 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

Events that are a part of the SecurityEvent node are generally related to 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 Event events indicate aggressive behavior that may lead to an attack or resource compromise, or suspicious behavior that may indicate unauthorized information gathering. LEM 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.

 

Each Security Event is described below, listed alphabetically.

  • 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 Contego 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/traffic. These events include access to network resources, relaying attacks via 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/traffic where the intention, or the 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 the result, is gaining access to resources where the related data is mostly or all application-layer. Generally, ApplicationAccess alerts will reflect attempted exploitation of weaknesses in server or client software, or information that is restricted/prohibited by device access control or policy.
    • These alerts are generally provided by network-based intrusion detection systems; in some cases, network infrastructure devices such as firewalls or proxy servers may also provide them.
    • Events placed in the parent ApplicationAccess alert itself 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 the result, is gaining access to resources via application-layer database traffic. Generally, these alerts will 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 itself. Appropriate response to these alerts may entail better access control of database servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to database servers and/or clients, or the possible removal of 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 the result, is gaining access to resources via application-layer file transfer traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in file transfer server or client software.
    • These alerts are generally provided by network-based intrusion detection systems, the file transfer server, or the client software itself. Appropriate response to these alerts may entail better access control of file transfer servers (e.g. 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, or the possible removal of 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 the result, is gaining access to filesystems of resources via application-layer file transfer traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in file transfer server or client software with the intent of information gathering or low-level filesystem access of the server or client.
    • These alerts are generally provided by network-based intrusion detection systems, the file transfer server, or the client software itself. Appropriate response to these alerts may entail better access control of file transfer servers (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via application-layer file transfer traffic. Generally, these alerts will 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, the file transfer server, or the client software itself. Appropriate response to these alerts may entail better access control of file transfer servers (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via application-layer file transfer traffic. Generally, these alerts will 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 (e.g. debug or legacy commands).
    • These alerts are generally provided by network-based intrusion detection systems, the file transfer server, or the client software itself. Appropriate response to these alerts may entail better access control of file transfer servers (e.g. 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, restriction of allowed commands, or the possible removal of 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 the result, is gaining access to resources via application-layer mail transfer, retrieval, or service traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in mail-related server or client software.
    • These alerts are generally provided by network-based intrusion detection systems or the mail server, service, or client software itself. Appropriate response to these alerts may entail better access control of mail servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to mail servers and/or clients, or possible removal of the mail server, 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 the result, is gaining access to resources via 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 itself. Appropriate response to these alerts may entail better access control of the SMTP server (e.g. restriction by IP address and/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, or the possible removal of 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 via 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 itself. Appropriate response to these alerts may entail better access control of the SMTP server (e.g. restriction by IP address and/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, or the possible removal of 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 via 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 itself. Appropriate response to these alerts may entail better access control of the SMTP server (e.g. restriction by IP address and/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, or the possible removal of 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 the result, is gaining access to resources via 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 command traffic that the SMTP server is not prepared to respond to, but may provide access to (e.g. debug or legacy commands).
    • These alerts are generally provided by network-based intrusion detection systems, or the SMTP server software itself. Appropriate response to these alerts may entail better access control of the SMTP server (e.g. restriction by IP address and/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, restriction of allowed commands, or the possible removal of 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 the result, is gaining access to resources via application-layer mail retrieval traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in mail retrieval related server or client software - the MDA (mail delivery Agent) or MUA (mail user Agent).
    • These alerts are generally provided by network-based intrusion detection systems, or the mail server, service, or client software itself. Appropriate response to these alerts may entail better access control of mail servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to mail servers and/or clients, or the possible removal of the mail server, service, or client application related to this event.
  • AttackBehavior > ResourceAttack > NetworkAttack > Access > ApplicationAccess > MailAccess > MailServiceAccess
    • MailServiceAccess alerts reflect malicious or abusive usage of network resources where the intention, or the result, is gaining access to resources via application-layer mail service traffic. Generally, these alerts will 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, the mail service, or the client software itself. Appropriate response to these alerts may entail better access control of mail services or servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to mail services and/or clients, or the possible removal of 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 the result, is gaining access to resources via application-layer mail service traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in Majordomo, a specific type of mailing list software.
    • These alerts are generally provided by network-based intrusion detection systems, or the mail service itself. Appropriate response to these alerts may entail better access control of mail services or servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to the mail service, or the possible 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 (Great Circle Majordomo (© 2017 Great Circle Associates, Inc, available at http://www.greatcircle.com/, obtained on February 2, 2016.)) 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 the result, is gaining access to resources via application-layer news traffic (over protocols such as NNTP). Generally, these alerts will reflect attempted exploitation of weaknesses in the news server or client software.
    • These alerts are generally provided by network-based intrusion detection systems, the news server, or the client software itself. Appropriate response to these alerts may entail better access control of news servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to news servers and/or clients, or the possible removal of 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 the result, is gaining access to resources via application-layer remote printer traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in the remote printer server or client software.
    • These alerts are generally provided by network-based intrusion detection systems, the remote printer server, or the client software itself. Appropriate response to these alerts may entail better access control of remote printer servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to remote printer servers and/or clients, or the possible removal of 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 the result, is gaining access to resources via application-layer WWW traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in the web server or client software.
    • These alerts are generally provided by network-based intrusion detection systems, the web server, or client software itself. Appropriate response to these alerts may entail better access control of web servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to web servers and/or clients, or the possible removal of 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 the result, is gaining access to resources via application-layer WWW traffic where the information flow is from server to client. Generally, these alerts will 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 itself, proxy servers, content filters, and/or firewalls with capability to monitor incoming web traffic. Appropriate response to these alerts may entail applying updates or patches to web client software, or restriction of 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 the result, is gaining access to resources via 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 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 and/or contain exploits.
    • These alerts are generally provided by network-based intrusion detection systems, the web client software itself, proxy servers, content filters, and/or firewalls with capability to monitor incoming web traffic. Appropriate response to these alerts may entail applying updates or patches to web client software, or restriction of 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 via 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 and/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, and/or firewalls with capability to monitor incoming web traffic. Appropriate response to these alerts may entail applying updates or patches to web client software, or restriction of 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 the result, is gaining access to resources via 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 and/or misuse of server resources.
    • These alerts are generally provided by network-based intrusion detection systems, the web server or service software itself, and/or firewalls with the capability to monitor incoming/outgoing web traffic. Appropriate response to these alerts may entail better access control of web servers (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts will 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 itself, and/or firewalls with capability to monitor incoming/outgoing web traffic. Appropriate response to these alerts may entail better access control of web servers or the service itself (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts will reflect attempted exploitation of weaknesses in applications run on top of server software that are related to remote administration of sites, services, and/or systems.
    • These alerts are generally provided by network-based intrusion detection systems, the web server, the service software itself, and/or firewalls with capability to monitor incoming/outgoing web traffic. Appropriate response to these alerts may entail better access control of web servers or the service itself (e.g. 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, and/or clients, or the possible removal of 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 the result, is gaining access to resources via application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts will 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, the web server, the service software itself, and/or firewalls with capability to monitor incoming/outgoing web traffic. Appropriate response to these alerts may entail better access control of web servers or the service itself (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to web servers, services, dynamic content, and/or clients, or the possible removal of 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 the result, is gaining access to resources via application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts will reflect attempted exploitation of weaknesses in applications running on top of server software that are related to remote administration of sites, services, and/or systems with the intent of information gathering or low-level filesystem access of the server or client.
    • These alerts are generally provided by network-based intrusion detection systems, the web server, the service software itself, and/or firewalls with capability to monitor incoming/outgoing web traffic. Appropriate response to these alerts may entail better access control of web servers or the service itself (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via application-layer WWW traffic in which the information flow is from client to server. Generally, these alerts will reflect attempted exploitation of weaknesses in applications running on top of server software that are related to remote services such as printing or console access.
    • These alerts are generally provided by network-based intrusion detection systems, the web server, the service software itself, and/or firewalls with capability to monitor incoming/outgoing web traffic. Appropriate response to these alerts may entail better access control of web servers or the service itself (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via 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, the web server, the service software itself, and/or firewalls with capability to monitor incoming/outgoing web traffic. Appropriate response to these alerts may entail better access control of the web server (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to web servers or services, or the possible removal of 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 the result, is gaining access to resources via 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, the naming server, or the client software itself. Appropriate response to these alerts may entail better access control of name servers (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via application-layer remote console service traffic (services such as telnet, SSH, and terminal services). Generally, these alerts will reflect attempted exploitation of weaknesses in the remote console server or client software.
    • These alerts are generally provided by network-based intrusion detection systems, the remote console server, or the client software itself. Appropriate response to these alerts may entail better access control of remote console servers (e.g. 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, or the possible removal of 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 via 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. Appropriate response to these alerts may entail better access control of remote time servers (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via resource configuration traffic (using protocols such as DHCP, BootP, and SNMP). Generally, these alerts will reflect attempted exploitation of weaknesses in the configuration server or client software or attempts to gain system-level access to configuration servers themselves. 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, the configuration server, or the client software itself. Appropriate response to these alerts may entail better access control of configuration servers and services (e.g. 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, or the possible removal of 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 the result, is gaining access to resources where the related data is mostly or all core protocols (TCP, UDP, IP, ICMP). Generally, CoreAccess alerts will 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 some cases, these events are escalated from the Audit tree via Contego Policy.
    • Events placed in the parent CoreAccess alert itself are known to be a core protocol-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 > 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 either enumerate devices or client machines, or to gather information on devices or client traffic to further attack those or other resources. ICMP Redirects are generally benign ICMP messages sent to hosts to redirect traffic intended for a network that another gateway can control. In the cases where ICMP Redirects are used for attacking, a host will generally feign themselves as a router, pass a redirect to a client machine to modify it's 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. The false router will then send the traffic on to the correct gateway, and 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. Appropriate response to these alerts may entail blocking or resetting the local or remote user's connection/IP address, updates to network infrastructure devices, or restriction of incoming/outgoing ICMP redirect requests/responses to reflect inappropriate or abusive access. Appropriate methods of prevention of ICMP redirect attacks would be to limit hosts who can broadcast ICMP Redirects across network devices to correct routers and gateways, limit ingress and egress ICMP traffic, and to make sure clients, servers, and network infrastructure devices are current with regards to operating system or other networking software to 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 and the intent is to mask possible malicious or abusive data past an IDS or other detection device 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, an IDS on the network may not be able to detect the malicious traffic, only the presence of fragments (if even that). 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 has been taken apart because it is too large based on network parameters) should not trigger an IPFragmentationAccess alert.
    • Fragmentation alerts themselves are generally provided by network-based intrusion detection systems and network infrastructure devices such as firewalls or routers. Appropriate response to these alerts may entail 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), updates to network infrastructure devices, or restriction of 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 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 itself is difficult as the originating host may be alternating spoofed hostnames or IP addresses in order to continually circumvent detection; however, response to IP spoofing which utilizes the IP source route could entail removing the ability to pass traffic through routers or gateways that contains an IP Source Route option. Initial appropriate response to these alerts may entail 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, updates to network infrastructure devices, or restriction of incoming/outgoing network requests/responses to reflect inappropriate or abusive access. Unfortunately, it may prove difficult to derail an attempted attack through IP Spoofing, however, routing and firewalling 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 and the intent is to misrepresent the originating address to either bypass detection or misdirect response to attack activity. IP Spoofing is done 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 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 in order to continually circumvent detection. Initial appropriate response to these alerts may entail 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, updates to network infrastructure devices, or restriction of incoming/outgoing network requests/responses to reflect inappropriate or abusive access. Unfortunately, it may prove difficult to derail an attempted attack through IP Spoofing, however, routing and firewalling 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 and the intent is to hijack a user's connection. TCP Hijacking is done with the intent 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 gets removed from his connection to the server and the new user has injected 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. Appropriate response to these alerts may entail blocking or resetting the remote hijacker's connection/IP address, applying updates or patches to server and/or client software, updates to network infrastructure devices, or restriction of 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 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 done 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 has built, they are allowed to pass any traffic through that does not match other policies - often after the connection has been 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, network infrastructure devices such as firewalls or routers may also provide them. Appropriate response to these alerts may entail blocking or resetting the local or remote user's connection/IP address, applying updates or patches to server and/or client software, updates to network infrastructure devices, or restriction of 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 the result, is gaining access to resources via remote filesystem traffic (using protocols such as SMB and NFS). Generally, these alerts will reflect attempted exploitation of weaknesses in the remote filesystem server or client software or attempts to gain system-level access to remote filesystem servers themselves.
    • These alerts are generally provided by network-based intrusion detection systems, the remote filesystem server, or the client software itself. Appropriate response to these alerts may entail better access control of remote filesystems (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to remote filesystem servers and/or clients, or the possible removal of the remote filesystem 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 via NFS (network file share) remote filesystem traffic. Generally, these alerts will 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 filesystem server, or the client software itself. Appropriate response to these alerts may entail better access control of remote filesystems (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to remote filesystem servers and/or clients, or the possible removal of the remote filesystem 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 the result, is gaining access to resources via SMB (server message block) remote filesystem traffic. Generally, these alerts will reflect attempted exploitation of weaknesses in the SMB server or client software or attempts to gain system-level access to SMB servers themselves.
    • These alerts are generally provided by network-based intrusion detection systems, the remote filesystem server, or the client software itself. Appropriate response to these alerts may entail better access control of remote filesystems (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), applying updates or patches to remote filesystem servers and/or clients, or the possible removal of the remote filesystem 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 the result, is gaining access to resources where the related data is low-level link control (using protocols such as ARP). Generally, LinkControlAccess alerts will reflect attempted exploitation of weaknesses in switching devices by usage of malformed incoming or outgoing data, with 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). Appropriate response to LinkControlAccess events may be to clear the link-level control mechanisms of the switching device (things such as flushing the ARP cache), applying updates or patches to switching devices, or better 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, or the result, is gaining access to resources via 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. Appropriate response to these alerts may entail better access control of remote access services (e.g. 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, or the possible removal of 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 PPTP and the intent is to misrepresent the originating address to either bypass detection or misdirect response to attack activity; often times the target of these attacks are internal trusted networks that allow remote access through PPTP tunneling. PPTP Spoofing is done 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 will 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 has already completed initial handshaking and key sharing. Initial appropriate response to these alerts may entail blocking or resetting the local or remote user's connection/IP address, applying updates or patches to server and/or client software, updates to network infrastructure devices, or restriction of 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 the result, is gaining access to resources via remote procedure call traffic (using protocols such as the traditional RPC services, RMI, and CORBA). Generally, these alerts will 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 itself. Appropriate response to these alerts may entail better access control of remote procedure (e.g. 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, or the possible removal of 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 the result, is gaining access to resources via remote procedure call traffic using the traditional RPC portmapper service. Generally, these alerts will 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 itself. Appropriate response to these alerts may entail better access control of remote procedure (e.g. 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, or the possible removal of 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 the result, is gaining access to resources where the related data is routing-related protocols (RIP, IGMP, etc.). Generally, RoutingAccess alerts will reflect attempted exploitation of weaknesses in routing protocols or devices with 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 utilize routing protocols such as firewalls and routers. Appropriate response to RoutingAccess events may be better access control of routing devices (e.g. 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, or the possible removal of 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 RIP (Routing Information Protocol). Generally, MalformedRIPAccess alerts will reflect attempted exploitation of weaknesses in RIP by usage of 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 is 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 utilize routing protocols such as firewalls and routers. Appropriate response to RIP Access events may be better access control of routing devices (e.g. 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, or the possible removal of 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 the 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. Appropriate response to these alerts may entail a quarantine of the node from the network to prevent internal attacks and further compromise of the client system, updates of 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, and 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 the 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, etc.). 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. Appropriate response to these alerts may entail a quarantine of the node from the network to prevent internal attacks and further compromise of the client system, updates of 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, and research into 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 the 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 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. Appropriate response to these alerts may entail a quarantine of the node from the network to prevent internal attacks and further compromise of the client system, updates of 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, and research into 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 are used to 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 entail a quarantine of the node from the network to prevent internal attacks and further compromise of the client system, updates of 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, and research into 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 the 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 may 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 the 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, but may 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 the 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, but may 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 the result, of this activity is inappropriate or abusive access to network resources through a denial of service attack. MailDenial events may 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
    • 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, etc.). The intent, or the result, of this activity is inappropriate or abusive access to network resources through a denial of service attack. MailServiceDenial events may 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 the 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, but may also be provided by the mail server itself, firewalls, or other network infrastructure devices. These alerts may indicate an open relay on the network or an attempt to find an open relay; appropriate response may be to close 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, etc.) or services (CGI, ASP, etc.). The intent, or the 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, but may 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 the 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, but may 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 the result, of this activity is inappropriate or abusive access to network resources through a denial of service via UDP chargen or echo services. This attack attempts to exploit network infrastructure devices and hosts by pointing two chargen or echo hosts at each other and forcing so many responses that the network and hosts are flooded. In response to a request to the echo or chargen port, the second device will send a response, which will trigger another request, which will trigger a response, etc. The source of the initial request is a spoofed IP address, which 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 the result, of this activity is inappropriate or abusive access to network resources through a denial of service by an ICMP-based 'flood' attack (which uses many 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 the result, of this activity is inappropriate or abusive access to network resources through a denial of service attack by using many 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 has been taken apart 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 the 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 the 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 many 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 the 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 has been 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 the 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. Normal ICMP 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 the result, of this activity is inappropriate or abusive access to network resources through a denial of service by a 'land' attack (which 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). Unpatched Windows 3.11, NT, and 95 clients are especially vulnerable to this type of attack. 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 the 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 ICMP Echo 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 which 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 the result, of this activity is inappropriate or abusive access to network resources through a denial of service by a TCP-based 'flood' attack (which uses many 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 the result, of this activity is inappropriate or abusive access to network resources through a denial of service by a teardrop attack (which 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 (it may be reassembled 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. Normal IP fragmentation (data that has been taken apart 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 intent, or the result, of this activity is inappropriate or abusive access to network resources through a denial of service by a UDP-based 'bomb' attack (which uses many 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 the 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 filesystem-related protocols (NFS, SMB, etc.). The intent, or the 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 filesystem 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 the 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 the 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 the 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 the 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 the 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 intention, or the 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.
    • Appropriate response to these events may be to restrict the source from accessing any external network, running a virus scanner or other detection utility to detect and remove the presence of any relay connector (in some cases known as a 'zombie'), and if necessary, to quarantine the source node from the network to further isolate the issue. If these events are sourced from a completely external network, blocking the remote host, better access control of clients, servers, and services (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), application of updates or patches to servers and/or clients, or the possible removal of the service related to this event may also be appropriate actions.
  • 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.
    • Appropriate response to these events may be to restrict the source from accessing any external network, running a virus scanner or other detection utility to detect and remove the presence of any relay connector, and if necessary, to quarantine the source node from the network to further isolate the issue. If these events are sourced from a completely external network, blocking the remote host, better access control of file transfer servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), application of updates or patches to file transfer servers and/or clients, or the possible removal of the file transfer service or client application related to this event may also be appropriate actions.
  • 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.
    • Appropriate response to these events may be to restrict the source from accessing any external network, running a virus scanner or other detection utility to detect and remove the presence of any relay connector, and if necessary, to quarantine the source node from the network to further isolate the issue. If these events are sourced from a completely external network, blocking the remote host, better access control of file transfer servers (e.g. restriction by IP address and/or user name to ensure only trusted clients are connecting), application of updates or patches to file transfer servers and/or clients, or the possible removal of the file transfer service or client application related to this event may also be appropriate actions.
  • AttackBehavior > ResourceAttack > ServiceProcessAttack
    • Members of the ServiceProcessAttack tree are used to 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 may lead to further attack. The severity of this alert will depend 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. Appropriate response to these alerts may entail a quarantine of the node from the network to prevent further outbreak, updates of virus scanner pattern files on other network nodes to prevent further outbreak, virus scans on other network nodes to detect further outbreak if any has taken place, and research into the offending virus to find out methods of removal.
  • 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 may lead to further attack. The severity of this alert will depend on the ActionTaken field which 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 entail a quarantine of the node from the network to prevent further outbreak, updates of virus scanner pattern files on other network nodes to prevent further outbreak, virus scans on other network nodes to detect further outbreak if any has taken place, and research into the offending virus to find out methods of removal.
  • GeneralSecurity
    • GeneralSecurity alerts are generated when a supported product outputs data that has not yet been normalized into a specific alert, but is known to be security issue-related.
  • 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, or other abnormal behavior that should be considered indicative of a serious security event.
  • SuspiciousBehavior > AuthSuspicious
    • Members of the AuthSuspicious tree are used to define events regarding suspicious authentication and authorization events. These events include excessive failed authentication or authorization attempts, suspicious access to unauthenticated users, and suspicious access to unauthorized services or information.
  • SuspiciousBehavior > AuthSuspicious > FailedAuthentication
    • FailedAuthentication events occur when a user has made several attempts to authenticate themselves which has continuously failed, 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 an attempt was made successfully or unsuccessfully granting access to a user that generally has no password assigned (such as anonymous, guest, or default) and no special privileges. Access of a user with this level of privileges 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 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 which they are denied access to or inappropriate access attempts to 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 which they are denied access to or inappropriate access attempts to services.
  • SuspiciousBehavior > InferredSuspicious
    • InferredSuspicious alerts are reserved SuspiciousBehavior alerts used for describing suspicious behavior that is a composite of different types of alerts. These events will be defined and inferred by Contego Policy.
  • SuspiciousBehavior > ResourceSuspicious
    • Members of the ResourceSuspicious tree are used to define different types of suspicious 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'.
  • SuspiciousBehavior > ResourceSuspicious > NetworkSuspicious
    • Members of the NetworkSuspicious tree are used to 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 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 may 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 which will elicit responses that reveal information about clients, servers, or other network infrastructure devices. The originating source of the enumeration is generally attempting to acquire information that may reveal more than normal traffic to the target would.
  • 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 - enabling them to modify their methodology to go on 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 which will elicit responses that reveal information about the application or host. This enumeration may be a LEMple 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 information being provided that can allow an attacker to craft a specific attack against the file transfer 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 > 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 which will elicit responses that reveal information about the application. This enumeration specifically entails 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 go on 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 which will elicit responses that reveal information about the application or host. This enumeration may be a LEMple 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 which will elicit responses that 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 which will elicit responses that reveal information about the application or host. This enumeration may be a LEMple 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 which will elicit a response containing the host or service's 'banner'. This 'banner' contains information that may provide a potential attacker with such details 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 LEMple 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 will elicit responses that reveal information about the application or host. This enumeration may be a LEMple 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 LEMple 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 done 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 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 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 would, information such as 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) 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 would, information such as 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 would, such as 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 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 would, such as 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 would, such as 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 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 would, such as 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 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 would, such as 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, 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 would, such as 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, 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 would, such as 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, 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 would, such as 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 which will elicit responses that reveal information about the host. The originating Trojan source of the scan is generally attempting to acquire information that will reveal 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.
Last modified
10:22, 21 Sep 2017

Tags

Classifications

Public