Security & Access Logs

Reading auth logs for attack patterns: the key signals of a brute-force attempt are volume (hundreds of attempts), regularity (one attempt per second — a machine, not a human typing), and a fixed target (same username, "admin" is a common target since it's predictable).

Vocabulary:
• Brute-force attack — systematically trying many password guesses
• Credential stuffing — trying username/password pairs leaked from other breaches, usually with many different usernames, not one
• Rate limiting — capping how many attempts are allowed per time window
• Account lockout — temporarily disabling an account after N failed attempts

Response steps: block the source IP at the firewall/WAF, verify account lockout is enabled so credential guessing can't succeed even without IP blocking, and check whether any attempt in the sequence eventually succeeded (search for a matching auth_success from the same IP or user shortly after) — that would upgrade this from "attempted" to "compromised".

SQL injection (SQLi) exploits code that builds SQL queries by concatenating untrusted input directly into the query string. The classic payload ' OR '1'='1 is designed so that, if inserted unescaped into a query like WHERE name = '<input>', it becomes WHERE name = '' OR '1'='1' — always true, potentially returning or exposing every row.

Reading this log entry:
• action: blocked — the WAF stopped the request; it never reached the application
• rule: SQLI-942100 — matches a known SQLi signature (OWASP CRS rule IDs are common)
• uri — shows the exact malicious payload in the query string

Why "blocked" matters for triage: a blocked WAF event is evidence of a probe, not necessarily a successful breach — but repeated blocked attempts from the same IP against multiple endpoints indicate active reconnaissance and should be correlated with any other suspicious activity from that source. The correct application-level defence against SQLi is parameterised queries / prepared statements, not the WAF alone — the WAF is a safety net, not the primary fix.

Impossible travel is a standard detection rule in identity security: if the same account logs in from two locations separated by a distance that couldn't be travelled in the elapsed time (accounting for flight speed, generously), it flags likely credential compromise or session hijacking.

Why VPN use complicates this: a legitimate VPN connection can also produce a distant geo value, which is why impossible-travel alerts are usually a starting point for investigation, not an automatic block — teams check for other corroborating signals: a new/unrecognised device fingerprint, a new user-agent, unusual activity following the login (privilege escalation, mass data export), or whether the user's VPN usage is already known and whitelisted.

Correct response, described professionally: "We saw an impossible-travel alert on jsmith's account — two successful logins 5 minutes apart from Kyiv and Jakarta. We're forcing a password reset and reviewing session activity from both IPs before confirming this is a false positive." This precise vocabulary — impossible travel, session hijacking, corroborating signals — is standard in security incident communication.

Port scanning is a reconnaissance technique: an attacker (or automated scanner like Shodan-style bots) systematically checks a target for open ports associated with commonly misconfigured or vulnerable services. The ports here are telling: 3306 (MySQL), 6379 (Redis), 9200 (Elasticsearch) are all databases that are dangerous to expose directly to the internet without authentication.

IDS vocabulary:
• IDS (Intrusion Detection System) — monitors traffic and alerts on suspicious patterns (passive — doesn't block)
• IPS (Intrusion Prevention System) — same detection, but actively blocks/drops matching traffic
• Signature — a known pattern used to detect a specific type of malicious traffic (the "ET SCAN" prefix here refers to the Emerging Threats ruleset)

Correct response: the priority action isn't just blocking the scanning IP (more will follow from other IPs) — it's verifying that ports 3306/6379/9200 are not actually reachable from the public internet in the first place. Port scans against exposed database ports should trigger an immediate audit of security group / firewall rules, since a scan finding an open, unauthenticated database is often the actual breach, not the scan itself.

Privilege escalation — gaining higher permissions than originally granted — is one of the most serious patterns to catch in audit logs, especially when the actor is a service account rather than a human. Service accounts are expected to follow the principle of least privilege: they should hold only the specific permissions their automated task requires (e.g. "deploy to this one S3 bucket"), never broad access like AdministratorAccess.

Why this is alarming: a legitimate deploy bot has no reason to grant itself admin rights. Two likely explanations: (1) a misconfigured CI/CD pipeline with overly broad permissions that a script accidentally used to self-escalate, or (2) the service account's credentials (an access key, a CI secret) were stolen, and an attacker is using them to expand access before doing further damage.

Correct incident response, in professional language: "We detected the svc-deploy-bot role attaching AdministratorAccess to itself at 03:41 UTC — this is not expected pipeline behaviour. We are rotating its credentials immediately, reviewing all actions taken by this identity in the last 24 hours, and revoking the AdministratorAccess attachment." Precise audit-log vocabulary — actor, action, resource, principle of least privilege — lets security teams communicate severity quickly and unambiguously.