How to Detect Account Security Threats Using Log Analysis and Alerts

Introduction

With the Cybersecurity Law and updated graded‑protection policies, security has become a mandatory requirement for enterprises, and account security now poses a serious risk to core data.

1. Overview

Accounts created from operating systems, databases, or network devices cannot be casually deleted, so during staff turnover privilege accounts often remain active. Poor handling leads to credential leakage, unauthorized access, data deletion, privilege escalation, and large‑scale intrusion.

2. Account Security Threat Detection Measures

1. Blacklist Account Login

Alert scenario: The account is not in a user‑defined whitelist and has a history of malicious or policy‑violating actions.

Attack method: Login using a blacklisted account.

Detection logic: Compare login logs with a custom whitelist; if the account is absent from the whitelist and appears on the blacklist, trigger an alert.

Log source: Linux system login logs.

<code>Sep 2 15:47:10 localhost sshd[21996]: Accepted password for blackhat from 192.168.1.41 port 60982 ssh2</code>

Manual analysis: Build black/white‑list dictionaries, filter logs, and match accounts.

Tool analysis: Centralized log collection, parse fields, and match against the dictionaries to raise alerts.

2. Expired Account Login

Alert scenario: The login originates from an account that has been disabled, deleted, or has expired (e.g., a former employee).

Attack method: Use the expired account to log in.

Detection logic: Check login logs for accounts listed in an “expired‑account” dictionary.

Log source: Linux system login logs.

<code>Sep 10 15:40:10 localhost sshd[21996]: Accepted password for invalid from 192.168.1.41 port 60982 ssh2</code>

Manual analysis: Filter logs for accounts matching the expired list.

Tool analysis: Same as above, using an expired‑account dictionary.

3. Multiple Accounts Failing to Log Into the Same Asset

Alert scenario: Three or more distinct accounts repeatedly fail to log into the same target host, indicating a possible credential‑guessing attack.

Attack method: Brute‑force password guessing across many accounts.

Detection logic: If more than three different accounts generate failed login events for the same host within a short time window, raise an alert.

Log source: Linux system login logs.

<code>Sep 10 15:40:10 localhost sshd[21996]: Failed password for userA from 192.168.1.41 port 60982 ssh2</code><code>Sep 10 15:42:12 localhost sshd[6116]: Failed password for userB from 192.168.1.39 port 60982 ssh2</code><code>Sep 10 15:43:15 localhost sshd[1828]: Failed password for userC from 192.168.1.21 port 60982 ssh2</code>

Manual analysis: Review failed‑login logs for the same host, checking for multiple source IPs and accounts.

Tool analysis: Aggregate failed‑login events, count distinct accounts per host, and trigger alerts when the threshold is exceeded.

4. Single Account Multiple IP Login

Alert scenario: The same account logs in successfully from different source IPs without logging out, suggesting credential leakage.

Attack method: An attacker uses stolen credentials from multiple locations.

Detection logic: Correlate successful login events; if the same username appears with different source IPs, raise an alert.

Log source: System login logs (Linux

/var/log/secure

, Windows Security log).

<code>May  8 17:13:00 localhost sshd[1234]: Accepted password for root from 192.168.1.162 port 54321 ssh2</code><code>May  8 17:13:05 localhost sshd[1235]: Accepted password for root from 192.168.1.3 port 54322 ssh2</code>

Manual analysis: Identify the same user with two successful logins from different IPs within a short interval.

Tool analysis: Parse login logs, group by username, and flag when source IPs differ while the login result is successful.

5. Off‑Hours Login

Alert scenario: A user logs in during non‑working hours (e.g., 22:00–04:00), which is considered suspicious.

Attack method: Malicious insider or compromised account used after hours.

Detection logic: Extract the login timestamp; if it falls within the defined off‑hours window and the login is successful, trigger an alert.

Log source: Linux

/var/log/secure

and Windows Security log.

<code>May  8 23:47:09 localhost sshd[1657]: Accepted password for root from 192.168.114.1 port 57115 ssh2</code><code>May  8 13:14:49 localhost sshd[51628]: Failed password for root from 192.168.114.1 port 49237 ssh2</code>

Manual analysis: Check the “Accepted” keyword for success and compare the timestamp against the off‑hours range.

Tool analysis: Define time‑range rules in a log‑analysis platform; successful logins outside normal hours generate alerts.

6. Bypass Bastion Host Login

Alert scenario: An account logs in from an IP that is not part of the authorized bastion‑host list, indicating a bypass of audit controls.

Attack method: Direct login from a non‑bastion IP.

Detection logic: If a successful login originates from an IP not in the bastion‑host whitelist, raise an alert.

Log source: System login logs (Linux and Windows).

<code>May  8 09:47:09 localhost sshd[1657]: Accepted password for root from 192.168.114.1 port 57115 ssh2</code>

Manual analysis: Verify that the source IP is absent from the bastion‑host list.

Tool analysis: Enrich login events with bastion‑host inventory and trigger alerts on mismatches.

7. Password Guessing

Alert scenario: Multiple consecutive failed login attempts followed by a successful login from the same source IP.

Attack method: Brute‑force or credential‑spraying attempts.

Detection logic: Detect a pattern of several failures within a short period that culminates in a success.

Log source: System login logs.

<code>2020-05-20 18:37:00 sshd[1111]: Failed password for user from 192.168.1.10 port 34567 ssh2</code><code>2020-05-20 18:38:05 sshd[1112]: Accepted password for user from 192.168.1.10 port 34568 ssh2</code>

Manual analysis: Correlate failure‑then‑success events for the same user/IP.

Tool analysis: Define a temporal rule that counts failures and flags the subsequent success as a password‑guessing alert.

8. High‑Risk Command Execution

Alert scenario: Execution of predefined high‑risk commands (e.g.,

rm –rf

,

DROP TABLE

,

shutdown

) that could damage systems or data.

Attack method: Malicious insider or attacker runs destructive commands.

Detection logic: Parse host or database logs; if a command matches the high‑risk list, raise an alert.

Log source: Host logs or database audit logs.

<code>BELONGAPP=||COMMAND=DELETE||...||RESOURCE_IP=134.240.7.8||TABLE_NAME=rpl_table_T||</code>

Manual analysis: Identify log entries where COMMAND equals DELETE, DROP, INSERT, UPDATE, etc., on sensitive objects.

Tool analysis: Load a high‑risk command dictionary into the SIEM and generate alerts on matches.

9. Sensitive File Access

Alert scenario: Access, modification, or deletion of files or database tables classified as sensitive (e.g.,

/etc/passwd

, configuration files, critical tables).

Attack method: Privilege escalation to read or alter sensitive resources.

Detection logic: Match file paths or table names against a sensitive‑resource list; if an access event occurs, trigger an alert.

Log source: Host audit logs or database audit logs.

<code>COMMAND=SELECT||RESOURCE_IP=192.168.1.162||TABLE_NAME=BS_INFO_TYPE_T</code><code>COMMAND=UPDATE||RESOURCE_IP=192.168.1.162||TABLE_NAME=BT_ACT_SUBPROC</code>

Manual analysis: Review logs for operations on the listed sensitive objects.

Tool analysis: Enrich logs with a sensitivity tag and raise alerts when such objects are accessed.

Conclusion

The methods described—ranging from blacklist/expired‑account checks to multi‑IP, off‑hours, bastion‑bypass, password‑guessing, high‑risk command, and sensitive‑file detections—can be implemented manually or, more efficiently, via automated log‑analysis tools to promptly identify abnormal account activities, mitigate threats, and reduce security losses.