Thursday, November 16, 2006

Case Study from SecuriTeam








But hey, who am I? What do you think?



Anonymous said...

What about them using the hacker tools to get the SQL password on the server because there was no administrator around?

H. Carvey said...

Great comment...what're your thoughts on that?

Anonymous said...

Check out Steps 10 and 11.


The truth is that it doesn't really matter what added the "SIMBAR Enabled" to the user-agent. The idea is that the attacker user-agent contained a string that helped to pinpoint his traffic in the logs. Finding SIMBAR in the second incident may have been coincidence, but once again it helped us to mark the intruder's activity.

Further more it was mentioned that there were a few computers involved in both incidence. The "Simbar" computer was involved in the initial attack and uploaded some tools in both of the incidence.

If every thing was known, there wasn't any place of assumptions and there wasn't any thing to investigate.
“There are things known and there are things unknown, and in between are the doors of perception” (Aldous Huxley)


H. Carvey said...

kfir d...

Hey, thanks for dropping by and commenting...

Check out Steps 10 and 11.

I did. In step 10, the authors state that they found a user logged in and attempting to use the exploit. However, that's it...there's no further discussion of the attackers/users battling the responders. In fact, step 10 doesn't say anything about the responders actively battling the bad just says that a user was logged in and says nothing at all about what the responders did with regards to that fact. Did the bad guy taunt the responders with messages? Did the bad guy try to delete things?


Excellent point. If that's the case, though, why was it so prominently mentioned in both reports? You could have simply stated that the string assisted in log analysis.

BTW...I did the same searches as you did, and found the same things. In fact, the second search string was the first one I used.

IMHO, I think it would've had greater impact in the report had the authors really went with the fact that the "SIMBAR" string assisted with log analysis, and perhaps stayed away from speculative things like the stating that the remote system was infected with spy- or adware.


I tend to agree with your statement in general, but I'm not clear on how it applies to this incident. It seems very clear to me that the authors had a lot that they didn't know, and a lot that they investigated. It also seems that some of the speculation was even pointed that out yourself.

Again, I do applaud their efforts overall, and I thank them for taking the time and effort to write up what they did.

Anonymous said...

I suppose the fact that they had management approval to use the tool left by the attacker and get the SQL password mitigates any liability on their part. I don't know, just doesn't feel right to me.

They did do a great job, but as you note, not a professional job.

H. Carvey said...

Well, from a forensic perspective, that may not have been the best thing to do, but from an operational perspective, it may have been the ONLY thing to do!

Anonymous said...

That brings up another question - is incident response turning into "get the machine up ASAP" at the expense of collecting evidence?

H. Carvey said...

No, it's always been that way.