Thursday, November 16, 2006

Case Study from SecuriTeam

Everyone loves a case study! Don't we love to read when someone posts what they did when they responded to an incident? It's great, as it gives us a view into what others are doing. SecuriTeam has not one, but two such posts...well, one post that contains two case studies.

The first is a PDF of the incident write-up for a compromise that occurred in July 2006. The second is a follow-up, and both are very interesting.

I'm going to take a process-oriented view of things. Please don't ask me if someone who defaces web pages and knows some PHP code qualifies as a "cyber-terrorist". I don't want to get mixed up in semantics.

This whole thing seems to have started on or about 11 July 2006 with a web page defacement. Evidently, the bad guys gained access to a vulnerable system (found via Google) and installed a PHP 'shell'. Page 8 of the write-up specifies the need for a "real-time forensic analysis", due to the fact that not only did the good guys need to "stop the bleeding", but they had to counter the bad guys, who were not only deploying their own counter-measures, but attacking the good guys, as well. What's interesting about this is that on page 8, the authors mention having to battle active attacks from the bad guys, saying it was a "fight between the attackers...and the incident response personnel." Oddly, pages 9 - 11 included the 12 steps that the IR personnel went through, yet nothing was mentioned about having to battle an attack. The document continues into "Attack Methodology" and "Conclusions" with no mention of IR personnel being hammered by attacks from the bad guys.

Another interesting point is that the authors mention that the user-agent found in some web logs included the term "SIMBAR", and concluded (with no supporting info) that this meant that the attacker's system was infected with spyware. While I'm not discounting this, I do find it odd that no supporting information was provided. I did a search and found references to adware, but I also found a reference to the SIMS game, as well.

Continuing along into the follow-up report, "SIMBAR" is mentioned again, and this time the authors seem to believe that this user-agent indicates that the same computer was used in multiple attacks. IMHO, this is perhaps dubious at best, particularly if it is indicative of adware...adware can be fairly widespread. Also, beyond that, I'm not sure how significant this information really is to the overall incident.

Overall, both write-ups seem to indicate that the attackers used known exploits to gain access to systems, and used relatively known and easily available tools to gain their foothold. It also seems that the authors made several unsupported assumptions. At first the write-ups are interesting read, but when you really try to dig into them and get some meat, IMHO, it just isn't there.

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

Addendum 18 Nov: Besides the comments here, there's been corresponding posts over on TaoSecurity. I just want to say that I'm not trying to grill the authors of the documents, nor am I trying to point out every little detail that I think was mishandled...not at all. What I am saying is that I think the authors did a great job, but there are things that could have been handled a bit better. Richard Bejtlich mentions "focus and rigor" in one of his recent posts...just because something is done by volunteers, does that mean that quality should suffer?

8 comments:

iamnowonmai said...

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

Keydet89 said...

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

Kfir D. said...

"fight between the attackers...and the incident response personnel."
Check out Steps 10 and 11.

SIMBAR:
http://vil.nai.com/vil/content/v_131206.htm
http://www.google.com/search?hl=en&lr=&q=SIMBAR&btnG=Search
http://www.google.com/search?hl=en&lr=&q=%22SIMBAR+Enabled%22+spyware+&btnG=Search

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)

(:

Keydet89 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 guys...it 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?

The truth is that it doesn't really matter what added the "SIMBAR Enabled" to the user-agent.

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.

If every thing was known, there wasn't any place of assumptions and there wasn't any thing to investigate.

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 unnecessary...you 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.

iamnowonmai 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.

Keydet89 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!

iamnowonmai said...

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

Keydet89 said...

No, it's always been that way.