Tracking User Authentication

Wiki > Tracking User Authentication
Description Kill Chain Stage
User authentication tracking mitigates the threat of an individual user losing control of their credentials, such as through theft and/or appropriation by a third party, inappropriate sharing of credentials or other practices that are contrary to stated policy.

It also detects activity that is typical of ‘lateral movement’, where an intruder attempts to strengthen their foothold by compromising multiple user accounts

1
Threat type to monitor
■    Theft of authentication credentials (anomalous use of logins e.g. suspicious locations, timestamps versus new resources)

■    Unauthorised use of access credentials

■    Detecting Brute Force Attacks on user accounts

■    User account created for malicious purposes

■    Misuse of guest accounts

■    Harvesting of user information

Monitoring setup
■    Domain Server

■    Firewall

■    VPN

■    Concentrator

■    DHCP

■    DNS

Events Indicators
■    Connections at odd hours

■    Connection attempts from suspicious geographic locations

■    Multiple/concurrent logins using one or small set of credentials across different systems and locations in a relatively small duration

■    Multiple authentication requests towards different destinations from the same source

■    Creation and deletion of user accounts within a short duration

Data inputs
action ip.dstport event.user logon.type
user.src event.computer filter obj.name
category event.desc group obj.type
ip.dst event.source alias.host policy.name
host.dst event.type reference.id process
alias.host result.code ip.src username
host.src user.dst virusname accesses
client server audit.class auth.method
Bytes sdomain change.attrib  
Rules
■    Brute force login from the same source

■    Multiple failed logins followed by successful login and a password change

■    Multiple login failures from same source for username that does not exist

■    Multiple successful logins from a single user from multiple different sources to the same destination in the same hour

■    Multiple failed logins from multiple different users from same source to same destination

■    Multiple successful logins from a single user from multiple different sources to different destinations

■    Multiple failed logins to single host from multiple hosts

■    Malicious account creation followed by failed authorisation to neighbouring devices

■    Multiple login failures from same source IP with unique usernames

■    Attempted identity abuse via excessive login failures

■    Multiple failed logins from same user originating from different countries

■    Adapter in promiscuous mode after user creation and login

■    Multiple failed logins from single user from multiple different sources to same destination in the same hour

■    Connection attempts from suspicious geographical locations (relative to each member firm)

Triage
■    Research source IP/ calling station (whether internal or external)

■    Research related employee’s schedule and/or contact the employee’s manager or administrator (e.g. is the employee currently on business travel in the area of the source connection or on holiday/ paid time off?). If it is likely that the employee is in the region of the source connection attempt, request that the manager or administrator attempt to contact the employees to determine if he or she was attempting VPN access.

■    Employee confirmation, confirm if the employee is in the source region or not.

■    Determine if there are other similar cases.

■    Gather related logs and add to incident data.

■    Escalate to L2.

Containment
■    If the source address is an internal host classified as endpoint, request to be disconnected from the network and request host a full scan.

■    If the scan result is negative then request IR Team to reset the password (6.1) then the incident is logged and closed (6.5)

■    If the scan result is positive then the result is analysed using forensic tools and the intelligence systems are searched for more information. If none then a new intelligence feed is created, the a request is made to the IR Team to re-image the endpoint (6.2), then the incident is logged and closed (6.5)

■    If the source address is an internal host classified as a business service, request a host full scan. If the result is negative then request IR Team to reset the password (6.1) then the incident is logged and closed (6.5)

■    If the scan result is positive, analyse the result using forensic tools and search the intelligence system for more information, if none then request a new intelligence feed to be created then request deletion of the file and monitor for one day (6.3) then the incident is logged and closed (6.5).

■    If the source address is an external domain, search the intelligence system for more information and then request the IR Team to block the IP/domain (6.4) then the incident is logged and closed (6.5).

Remediation
■    Request Password reset with complexity recommendations and monitor for one day (6.1).

■    Request reimaging of the endpoint (6.2).

■    Request deletion of the file and monitor for one day (6.3).

■    Request to block the (IP/domain) (6.4).

■    log information and close incident (6.5)

Closure
■    Closure of the ticket.

■    Capture the findings and the potential root cause

■    Learnings if any

 

 

 

Category: