Security incident / suspicious access

For suspicious access, an unexpected privilege change or a possible data leak, a decision tree that leads, based on the symptom, to the right response steps (lock the account, revoke excess privileges, cut connections, determine scope) and to permanent post-incident hardening.

What did you notice?

Choose the incident type. Is the symptom a suspicious login or a burst of failed logins, an unexpected privilege (GRANT/role) change, a possible data leak / abnormal export, or is the incident closed and you are doing permanent hardening? Choose the most appropriate branch based on your first observation. First, note the time of the incident and the affected account/resource.

• Suspicious login / burst of failed logins
• Unexpected privilege (GRANT/role) change
• Data leak / abnormal export
• Permanent post-incident measures (hardening)

Identity incident: which symptom?

Many failed logins point to a brute-force / credential stuffing attack. In contrast, a successful but unexpected login (from an unusual IP/at an unusual time) indicates the account may have been compromised. In both cases, collect evidence first, then respond.

SELECT username, os_username, userhost, timestamp, returncode FROM dba_audit_session WHERE returncode <> 0 ORDER BY timestamp DESC;

• Burst of failed logins (brute force)
• Successful but unexpected login (compromise)

Brute force → block the source and protect the account

With a burst of failed logins, access may not have been gained yet; the goal is to block the source, protect the account with lockout/delay, and rule out any successful intrusion.

Compromised account → stop, investigate, rotate credentials

An unexpected successful login indicates the account has been compromised. First stop the account and its sessions, investigate what it did, then reset the password and narrow the access source.

Privilege escalation → audit and revoke excess privileges

An unexpected GRANT, role assignment or a new highly privileged account may be the second stage of a compromise (persistence/privilege escalation). Audit recent privilege changes, revoke those that are not legitimate and return to the principle of least privilege.

Data leak → cut access and determine scope

Abnormally large queries/exports or unexpected external connections point to a data leak. First cut the active dangerous connections, then determine the scope with the audit trail/logs: which data was accessed, by whom and when.

Permanent post-incident hardening

After the emergency response, apply permanent controls to prevent recurrence: enable auditing, enforce least privilege, restrict network access and record the incident completely.