Recently, I was reviewing exploit code that we identified as part of a privilege escalation attack against a UNIX-based server. There were certainly a lot of interesting things in the exploit code, including shellcode, assembly language instructions and funny hacker ‘l33t sp3ak’ comments, but one thing that always sticks out for me – the attacker hiding their tracks.

In particular, the following code caught my eye:

The above code is run as part of the exploit. In short, it sets the environmental variables for commands executed on the UNIX command line to go to /dev/null.

/dev/null is a nix interface that acts like a black hole, so no data is actually stored or written to the file. In this case, it means anything the attacker types in the command line during his attack is never logged, since, instead, it goes to the ‘black hole of /dev/null. Like a Jedi mind trick, this technique has been used for years, and is still used today due to its effectiveness.

What does this mean to you? Well, imagine your organization was compromised and during the investigation you suddenly find that you can no longer see what the attacker was doing? Did they access sensitive data? Did they add user accounts via the command line? Did they use that system to pivot to others?

This is the equivalent to locking the door on a busy Mos Eisley street – visibility is lost. 

Depending on the skill of the attacker and exploits used, it is also possible to remove all logs generated during the attack, but in many cases the previous example is typical.

Point: It is important to always make sure systems are prepared for attacks. Hindsight is something that educates us all; learn from previous experiences and prepare for the worst. Ensuring a proper event-logging environment is implemented can preserve visibility and really help your organization during incidents.

Some good guidelines to follow to keep visibility within your network:

  • First and foremost, make sure you are logging security events
  • Ensure events are logged to a centralized logging server
  • Make sure all log sources and servers are time synchronized
  • Review logs on a regular basis
  • Implement policies and procedures to handle security events if (when?) they do arise.