Optimizing Your Security Log Strategy: How to Prevent Overwrite Issues in Sysmon Logs During Cyber Attacks

Network security

1. Preparation

1.1 Enable Log Recording

Enable logging by Sysmon according to the Security log strategy.

Security log strategy />

1.2 Optimize Log Strategy

Optimize security log overwrite strategy

Security log strategy />

1.3 Deploy Security Products

Deploy Changting Muyun HIDS host security product

2. Detection

2.1 Security Product Alerts

Fortunately, alerts were aggregated to 1 minute; otherwise, the alert storm caused by this attack would have directly DDoS’d me crazy (I think I already am).

Only one program, C:\ProgramData\2HIf.exe, but it was frequently executed by different processes, which caused the alert storm.

From the process tree, we can see that the xtgosqhl.exe process was started first, and then the 2HIf.exe process was executed.

This played a key role in the subsequent investigation because the 2HIf.exe process had such a short lifespan that the related processes were invisible.

This is the attacker’s cleverness: the disappeared 2HIf.exe process, the hidden xtgosqhl.exe file, and the high-frequency QQMusic backdoor (discussed later). If it weren’t for the HIDS alert, we might not have even known the server was compromised.

3. Containment

3.1 Terminate xtgosqhl.exe-related malicious processes and alerts

Terminate xtgosqhl.exe first, then 2HIf.exe. Because 2HIf is opened by xtgosqhl, it cannot be deleted.

Kill the process first, then delete the file. Because the file is opened by the process, it cannot be deleted.

Malicious program C:\ProgramData\xtgosqhl.exe not found.

After removing the system, hidden, archive, and read-only attributes of xtgosqhl.exe, it can be deleted.

Here, because the scheduled task backdoor executes once every minute (discussed later), the xtgosqhl.exe process starts again, and the process needs to be terminated again before the malicious program can be deleted.

3.2 Terminate 2HIf.exe-related malicious processes and alerts

No malicious processes related to C:\ProgramData\2HIf.exe were found, but the malicious program 2HIf.exe can be deleted directly, which also shows that the lifespan of the related malicious processes is very short.

4. Eradication

4.1 Delete Startup Program Backdoors

Two startup program backdoors were found using Autoruns.

They can be deleted in Autoruns.

They can also be deleted from the registry.

4.2 Delete Scheduled Task Backdoors

A scheduled task backdoor was found using Autoruns.

It repeats indefinitely every minute—very aggressive; it must be deleted.

For these two backdoors, it feels like something is missing. There’s no low-frequency to high-frequency escalation, and no malicious program download.

Instead, all their eggs are in one basket: the hidden xtgosqhl.exe program and high-frequency processes. Once detected and deleted, these two backdoors become useless.

4.3 Delete System Account Backdoors

Newly created system accounts were found. Based on the last login time, they may not be related to this incident, but they still need to be deleted.

4.4 Harden System Weak Password Vulnerabilities

Investigate whether the attacker obtained system privileges by cracking system weak passwords; however, the security log was deleted—frustrating!

Fortunately, the sysmon log is still there. Unfortunately, the sysmon log’s overwrite strategy was not optimized. Due to the excessive attack behavior during this incident, the initial intrusion log was overwritten—frustrating!

Muyun HIDS’s brute-force cracking only shows a successful record from four days ago. Based on the timeline alone, it cannot be confirmed as related to this incident—frustrating!

However, the Administrator account does have a weak password and needs to be changed.

5. Recovery

Not applicable

6. Follow-Up

6.1 Optimize Log Strategy

Optimize sysmon log overwrite strategy

Why was only the security log overwrite strategy optimized before, and not the sysmon log?

Because the incident described in the article “Incident Response in Action (8): A Run-of-the-Mill Incident Response” only resulted in the security log being overwritten, not the sysmon log. It seems the Follow-Up wasn’t thorough enough.

Share this