If I see an outbound LDAP connection, does that always mean the exploit succeeded?

Not always. The outbound LDAP connection shows the Java process reached the attacker's server, which means the exploit worked. However, the attacker may not have completed their follow up actions. Treat it as a confirmed compromise and investigate further for process and host evidence.

Can a Log4Shell exploit succeed without any outbound network traffic?

No. The JNDI lookup requires network access to the attacker's server. Without outbound traffic on LDAP, RMI, or DNS, the payload cannot execute. If you see no such traffic, the attempt likely failed.

How long after the attempt should I look for persistence artifacts?

Check for new scheduled tasks, cron jobs, user accounts, and web shells created within 24 hours after the attempt timestamp. Attackers often establish persistence quickly after gaining access.

I patched Log4j after the attempt. Is the host safe now?

No. Patching Log4j stops future exploitation but does not remove any backdoor, account, or malware the attacker already installed. You must still isolate, investigate, and rebuild the host.

Signs a Log4Shell Attempt Succeeded: Post-Exploitation Checks

Seeing a JNDI string in a log file proves an attempt, not a breach. Success requires a vulnerable Log4j version and a network path from that host to the attacker's server. The evidence that separates a logged probe from a confirmed compromise lives in three places: the network, the running Java process, and the host itself.

Network Evidence of Successful Exploitation

Start with the traffic leaving the application host. A successful exploit forces the Java runtime to reach out to infrastructure the attacker controls. Pin your investigation to the time window around the logged attempt. Seconds matter.

LDAP and RMI Connections

The clearest signal is a connection from the application host to an external IP on an LDAP port. The attacker's JNDI payload references an LDAP server they run. Check firewall logs for TCP 389 (standard LDAP) or 636 (LDAPS). A connection on TCP 1099 signals RMI activity, another common JNDI vector. Any such connection from the host that an administrator did not initiate is a log4shell indicator of compromise.

Unexpected DNS Lookups

Even without LDAP or RMI, the JNDI payload triggers a DNS lookup for the attacker's domain. Review your DNS logs for queries to domains that appear in the JNDI strings you already found. A single lookup to an unusual domain at the same second as the attempt is suspicious. Multiple lookups or repeated queries mean the payload executed and the attacker's server responded.

Process Evidence Java Spawning a Shell

On the host, the most telling sign is a Java process spawning a command interpreter. Normal Java applications do not launch sh, bash, cmd.exe, or powershell.exe. If your EDR or host logs show a child process of the Java runtime that is a shell, you have strong evidence of a log4j compromise sign. Investigate immediately.

Look for process trees where the parent is the Java process running Log4j and the child is any interpreter. The attacker uses the shell to download tools, run reconnaissance commands, or establish persistence. A java process spawning shell is a confirmed compromise. Treat it as one.

Host Artifacts Files, Accounts, and Scheduled Tasks

After gaining a shell, attackers install persistence. Compare the timestamps of the Log4Shell attempt with the creation or modification times of these artifacts on the host.

New scheduled tasks or cron jobs added after the attempt timestamp.
New user accounts, especially those with administrative privileges.
New files in web-accessible directories (web shells) or unexpected executables in temporary directories.
Modified system binaries or startup scripts.

Reported post-exploitation activity after Log4Shell includes cryptocurrency miners, botnets such as Mirai and Muhstik, Cobalt Strike beacons, and Khonsari ransomware. Each leaves files, processes, or network signatures. A new scheduled task that runs a downloaded binary is a clear persistence indicator.

Correlating Logs Across Systems

No single log type confirms success. Correlate evidence from multiple sources using this procedure:

Note the exact timestamps of the Log4Shell payloads from your scanner or application logs.
Pull firewall logs for the same window. Check for connections on TCP 389, 636, or 1099 from the application host.
Check DNS logs for queries to the domain in the JNDI payload. Note the time and the source IP.
Review EDR logs for process trees showing a Java process spawning a shell, or for new binaries executing around that time.
Examine system logs for new user accounts, cron jobs, or scheduled tasks created in the hours after the attempt.

Evidence in two or more categories means compromise is likely. A single LDAP connection without any host change may still be a failed attempt if the attacker's server was unreachable. Shell spawning is definitive.

What Successful Post-Exploitation Looks Like

Attackers who succeed follow up. Knowing their next moves tells you what to hunt for. Reported post-exploitation activity includes cryptocurrency miners that consume CPU, botnets (Mirai and Muhstik) that enlist the host for DDoS, Cobalt Strike beacons for remote access, and Khonsari ransomware for extortion. Each leaves distinct traces: miners show high CPU from a suspicious process, botnets generate traffic on uncommon ports, beacons create periodic HTTPS callbacks, and ransomware changes file extensions and drops ransom notes.

A process with no legitimate parent making continuous connections means compromise. Files being encrypted means compromise. Patching Log4j afterward does not remove attacker persistence. The access, if established, remains until you remove it.

Immediate Steps After Confirming Compromise

If your investigation concludes a Log4Shell attempt succeeded, treat it as an incident. Do not patch first and hope the problem goes away. Patching after the fact does not remove attacker persistence.

Isolate the affected host from the network to prevent further damage or data exfiltration.
Preserve evidence: take a memory dump, capture disk images, and save logs before any cleanup.
Rebuild the host from a known good image after documenting all findings.
Rotate credentials for any accounts stored or used on the compromised host, including service accounts and application secrets.

These steps apply regardless of the specific malware or ransomware found. Stop the attack, understand what happened, and return to a clean state.