Tim wrote: > > For future reference, and for the benefit of people searching for > solutions to similar problems: You've made the most common rookie > mistake.
Well, I actually made 2 mistakes and the second compensated the harm the first did... My second mistake I did not mention before was to overlook various other folders in /tmp that were older than /tmp/.m and contained lots of other crap (so they are even more useful in finding the original attack vector, being older). However I did save the original launcher found in /tmp and all that older stuff too for analisys. > If you don't have budget to bring in a professional to do the > investigation, then capturing memory is probably not practical (it is > easy to do it wrong and trash useful information on disk). Using dd on /dev/mem and piping results through netcat it's not that difficult, and a bit of google explains how to do it the right way, but in my case there are two other problems: 1. The attack took place several days ago and it's likely the system ram has been overwritten several time since then 2. My server runs in a OpenVZ container (it's a hosted vps)... /dev/mem exists but it's obviously not accessible. However I understand your point. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
