Case Study: Port 3389 Intrusion; How to stop it
After getting the alert from the IDS (Intrusion Detection System) that someone or something has breached port 3389 on computer (192.168.2.124), my first reaction is to expect the worst. This day and age we have to be on our toes about security. Any breach in security, as long as it violates our company’s policies, has to be taken seriously. The reason I say it must violate our company’s policy is because we have numerous people here who are extreme power users and they should be trusted when given authority to breach some of our policies. Some policies may include, but not limited to remote desktop, file sharing, IIS configuration, and SQL/ORACLE programming. If my IDS has not been configured to ignore these users, then I have to treat every intrusion as a security threat and look over the security logs. I will briefly go over the mental approach that I have to take, how I isolate this computer, how I track down the perpetrator, who I notify and the review of the security logs.
Port 3389 is the remote desktop port that allows people to control other computers remotely. The question is this port being intruded from outside this network or from within? And if it from within, is it one of my power users or someone who is just lurking around? Since I see the person has taken control of the computer, I can not simply block port 3389 by turning off the remote desktop from that computer. I have to so to the authenticating server running Windows server 2003, visit the firewall settings and block port 3389 to IP 192.168.2.124. I go back to the affected computer and perform a cold boot. After it boots up, I noticed no one can remote on to the computer.
After checking on the computer every hour for the first four hours to make sure the computer is not affected. I notify my supervisor about the attack and how I have it under control. Still at this time, we do not know if this was an attack or a legitimate work related process. A quick way to tell the difference is when the person who was trying to remote into the computer will call the Help Desk and question why his privileges were revoked. This should make its way back to the IT Security professional and they can have a dialog about the situation. If there is no phone call, we can assume that the person may have had ill intent when accessing the computer. After talking this over with my supervisor, he advises that I look over the logs from the computer and the firewall.
First, I have to determine if this was an attack or was it from one of my power users before I start notifying everyone and causing panic. There are two areas that I can look for the history of the terminal services and they are the computer that was attacked and at the server at the firewall. I chose the attacked computer first because it is easier to go to the source to find the problem. After reviewing the log, I can determine if the IP address of the attacker was from within the company or from an outside computer. It is determined that it was a computer inside this building. I simply pinged the attacker’s IP address to see if the computer is turned on and responding to the network. I could then remote into this computer to see who is logged in to it so I can give this person a call. After calling this person, it was determined that this person is one of my power users and was trying to install a new application on a computer that the person did not understand the remote desktop feature.
All of this could have been avoided if the attacker, who should now be referred to as the power user, just called the person and explained what they were doing. If this was an actual attack, I would have to notify my supervisor, the person who was attacked, their supervisor and probably everyone in the company warning them of a possible outside attack on your computer. My advice in this situation is to have IT security keep a log of users that are considered power users and their IP addresses or machine names so it can reduce the money wasted reviewing every step when it could have been avoided.
Microsoft (March 28, 2003).
What Is Terminal Services?/support.microsoft.com,
Retrieved February 22, 2009, from
Tony Bradley (1999). Introduction to Intrusion Detection Systems (IDS)/www.netsecurity.about.com,
Retrieved February 22, 2009, from