Last Updated: 2009-04-02 20:39:08 UTC
by Handlers (Version: 1)
This diary entry is an attempt to share one persons perspective on the importance of the CWG. It is written from my own perspective in an as honest as possible manner. I feel that it is of some value to share my own view of things. I am not using my name for one main reason, I am a bit busy right now and do not want to deal with press or other distractions. I also feel strongly that my name has little or no value in being known. I hope the value in this diary is found is in its message, and not the name attached to it.
First a bit about my background.
I have been working at and a Registry Operator for the last 3.5 years in a Senior Information Security role. I was responsible for daily security operations as well as helping develop the registry industries first domain investigation and take down policy as well as a set of technical procedures to support that. I can not tell you how incredibly amazing it was to work with the high caliber of individuals at the registry I work for. It is the first time I have ever heard of or seen such tight integration between senior business leaders, senior legal leaders, senior technical leaders, and of course the “in the trenches” technical folks like myself. From this amazing effort was spawned a well structured and important framework of contractual obligations, technical investigatory procedures, and business leader commitments.
As the above paragraph will hopefully highlight, I have spent a good portion of the last three years of my professional career dealing with malware, malicious domains, and the registry industry. This is in my opinion the most important thing to walk away with from this entire Conficker ordeal. This is the FIRST TIME that multiple industries have collaborated in tackling such a large threat. While the “Conficker Cabal” (sorry again for suggesting that name!) has grown from a small group of 8-10 individuals into a large ad-hoc organization that contains representatives from various industries there still remains one motivation. Do what we can to mitigate and clean up Conficker with the understanding that the relationships that are built now will be used in the future for other threats.
It is in that last sentence that the importance of all the buzz surrounding Conficker should hit home. While this effort that sprung up has been very much ad-hoc, there are plenty of examples in the security industry of similar groups that are alive and well. It is this shift towards building out trust networks within the security community that has truly empowered this process and the CWG. If the existing trust between key players did not exist the ability to coalesce into a group would have been severely restricted. So it is in that tone that I thank the combination of media attention, industry participation, and of course the authors of Conficker for providing the perfect storm for the formation of such a group. In my view this group, and the coming evolution of this group could provide the Internet community its best shot at tackling emerging large scale threats. As others in the CWG have noted, this community captures the very early spirit that spawned the internet in the first place.
It is my honest hope that the level of awareness and participation that this effort produces jump starts the adoption of this behavior in the registry industry. The current threat environment is such that registry operators provide a very important capability in mitigation of certain malicious threats. It is the dawning of this cognition on the industry that is so critically important. No doubt those with any insight will quickly chime in with “they will move away from using domains!”. I completely agree with that this will happen, but what this does is erode away the convenience, stability, and scalability that DNS provides. This of course forces our opponents into a realm of less stable and more “ad hoc” methods. I am of the view that any and all costs that can be forced on an opponent are worthwhile when engaging in wars of attrition.
As I have stated before, this will hopefully be the first of many such efforts by the community to self organize and execute mitigation efforts for large scale threats.
I would like to personally thank the following industries for their hard work
A certain Operating System vendor
Registry Operators (gTLD as well as ccTLD's)
Law Enforcement (world wide)
International CERT/CSIRT teams
Non profit security and infrastructure groups/companies
Security Research Companies
Private researchers (who contribute as individuals selflessly)
You will notice that I do not mention names, this is on purpose. We are literally talking about a large portion if not ALL of the players in the above industries. Now if only we could start a fund to pay for all the marriage counseling that is need now due to the extra hours everyone worked.
To quote another participant in CWG, “i doubted it would work, i signed up reluctantly. i am glad i was proven wrong.”
Last Updated: 2009-04-02 00:39:28 UTC
by Bojan Zdrnja (Version: 1)
In my last two diaries (http://isc.sans.org/diary.html?storyid=6001 and http://isc.sans.org/diary.html?storyid=6010) I described two very common attacks on web servers that I have seen in the wild recently. During the forensic analysis, I acquired two attack tools that were used in almost all cases, so here is a short description of them.
However, in cases where they couldn’t do this (for one reason or the other), they used a very simple file injection named JS.exe, which you can see disassembled below:
The other attack tool I recovered is a log cleaner for Windows. It’s another simple tool which allows attackers to easily delete all IIS, FTP and EventLog logs. The help window is shown below:
While the both files are very simple, finding them solved another puzzle that troubled many web administrators lately as attacks such as those I describe are becoming increasingly common.
I’d like to use this opportunity to warn people about the “unpatched” Windows vulnerability described in http://isc.sans.org/diary.html?storyid=6010 again, since I’ve seen it used in the wild again. While Microsoft listed some workarounds, for most users using IIS 6 they will not be acceptable as they require one to disable the Distributed Transaction Coordinator service. The workaround for IIS 7 is better, but some (many?) shops can’t easily migrate to it so they are kind of left in the open.
If you have more experience or comments about these workarounds please do contact us.