Corporate Network Blasted From Abroad

Computerworld - My company has offices all over the world, including a software development center in India. Many of the networks located in such locations are managed independently. I'm not sure why we have continued to let those overseas locations administer their own networks, but the policy has created extra headaches for my team in the past few weeks as we battled Blaster and other worms that exploit vulnerabilities in Windows' remote procedure calls (RPC).
These worms take advantage of a previously discovered vulnerability in the way the Windows operating system handles RPCs, Microsoft's methodology for allowing its operating system to run programs on a remote server.
When a worm finds a server with an open, vulnerable RPC port (typically Port 135), it creates a buffer-overflow condition to force the server to spawn a shell, typically on Port 4444, and download the worm to the server. The worm then starts the process again.
Not only can a vulnerable system be used to propagate the worm, but a malicious user can also take advantage of this buffer-overflow vulnerability to execute arbitrary commands on a vulnerable server.
We first noticed problems when our network operations center (NOC) reported an increase in network utilization within our data center in the U.S. After some investigation, we determined that the source of the problem was TCP/IP traffic with a large range of source and destination IP addresses, all of it destined for Port 135. Our company keeps that port open internally so we can run programs such as Microsoft Exchange, Active Directory and print services.
Externally, however, we block it at our core routers and firewalls. Shortly after the NOC detected the bandwidth problem, we started getting calls from both our Windows NT network administrators and our customers. They reported problems ranging from unauthorized accounts being created to arbitrary reboots, as well as problems when launching Microsoft Word or Excel. The call volume escalated so quickly that our help desk was inundated within an hour.
After some analysis of the Port 135 traffic, we noticed that over 40% of it was coming from the India development site. The rest came from various IP addresses within the company. We also discovered that a Web server had been compromised and that a Web page had been altered at the India site. This was alarming because all authorized Web servers are supposed to reside in our corporate headquarters.
What's worse, the Web server in question was not only running on a publicly accessible IP address, but it also contained links