This is the first in a series of technical blog posts examining various attack scenarios through video simulations of CounterTack’s Event Horizon platform.
Today’s attackers are motivated, highly focused and much more determined than the hackers of five years or even 12 months ago. Though there are some still seeking targets of opportunity, or simply looking to access and overtake machines to increase the capacity for a botnet, the majority of today’s attackers are after something very specific – your intellectual property, personally identifiable information or financial data.
Whatever their motivation, sophisticated hackers know a thing or two about hiding their tracks. This makes it increasingly difficult for organizations focused on trying to understand what an attack “looks like” by analyzing past events to help stop future break-ins. Yet many companies still rely on system logs (syslogs) to do just that.
Syslogs provide information about the activities of the machine, including user activity and history. On Linux systems, for example, the bash_history file holds the list of all commands executed by a particular user (there is a file for each user, including root). By analyzing the syslog, security personnel can detect malicious or suspicious activity, and call for incident response and/or forensic investigation if necessary.
But what happens if the syslog doesn’t show suspicious activity and the bash_history is empty? Often times, if nothing is detected, business goes on as usual. But by disabling action logging capabilities, the hacker can go on with his business as well. Check out this short video example captured by our Event Horizon virtual machine.
1. Notice that the very first thing the intruder does is to unset the history file “HISTFILE” and history save “HISTSAVE.” This ensures that the commands used during the shell session cannot be logged into the bash_history file.
2. Next, the attacker unsets “WATCH,” preventing any scheduled commands that the system administrator has configured from being executed as scheduled. This allows the attack to operate under the radar – ensuring his actions are not being, well, watched.
3. Then, the attacker makes sure that in the event the command history is enabled, it gets written to nowhere (“dev/null”). Now the host is primed for some real action.
4. The attacker does a final check to see if anyone else is logged into the system, then kills the cron job.
5. After gaining access to the virtual machine, the attacker now owns the system. His actions will not be exposed to anyone performing lightweight analysis.
Event Horizon allows us to see all of this, as it is happening, down to the timing of the commands being executed and the sloppy typos the attacker has made along the way. In fact, we’ve seen this guy before – several times, actually. Feels almost like family…