The Breach: An Attack Scenario
This article was something that I wrote back in school while taking a cybersecurity class. It describes an attack where a threat actor (a gray hat) gains access to a Windows IIS server and steals a file. I have done this attack many times during my work as a penetration tester. Here are the inter-workings of that attack.
Note: This attack was preformed on a customer system with consent from the customer. This article is for educational purposes only.
Network security is a topic I have dealt with for a long time and is also something that very much interests me. Before we start talking about network security, we must understand one thing, and that is: no network is truly 100 percent secure or impenetrable. There will always be an out of date system, user error, vulnerability, or backdoor. All an attacker must do is find it.
This process however, can sometimes be tedious and long. Here are the steps that I usually go through to breach a network and accomplish a goal. Keep in mind that all information provided here is for educational purposes only and I will leave it to your imagination as to how this data was acquired.
The following is written from a point of view of a malicious grey hat hacker (basically a cyber vigilante or activist) whose mission is to gain access to a secured IIS web services server and copy some information.
Choosing The Target
Most attackers skip this step. Choosing a target is only required when the attacker does not have a clear goal in mind or if they are unsure of exactly where the target resides. Scanning for targets is quite easy. You can use a free tool to go out and scan the internet or a large network and gain data about various targets.
Choosing the target is the difficult part. You will want a target of value. Remember, the question to ask is “is this worth my time and effort / possible consequences?” If the answer to even one part is “no”, then move on. Most attackers will already have a target chosen or assigned to them. In this case the target has been pre-assigned and the web address of the IIS server is known.
Casing the Target
One of the most important things to do in any attack is homework. By the time you are done studying the network, it’s users, it’s defenses and above all, the target, you will want to know more than the network administrator does. (I know that this is a near impossible goal, however for illustration, this is the level that your knowledge should be).
Doing research on the target network usually involves some form of passive attack such as packet capture or simply looking at public log files or even physical user activity in the building.
Find The Key
Ok, you have the knowledge you need to attack the network successfully. At this point, I would say to go back and review the data that was collected. Focus on things like honeypots, intrusion detection technologies, and other systems that might prevent a successful attack.
Once this has been complete, the fun begins. The IIS server is a locked door. You have to get into the door. You can do this in many ways. You can pick the lock by finding vulnerabilities either in IIS itself or the underlying PHP or ASPX code that runs the hosted content.
You can go around the door and use a backdoor such as an administrative account, or a privilege escalation attack. Or, you can break the door down and simply SYN flood the IIS instance until it crashes (this only applies when you want to take down the server, not get into it.) Or, as we will do in this case, you can do a combination of things.
Get In
For the purposes of this post we will use what is known as a man in the middle attack. Think of this attack is a 3rd party intercepting traffic that you send to a server or that a server sends to you. In this case, the attacker intercepted an authentication packet when an application superuser logged in. The login request was still processed, however the attacker also got a copy of the authentication packet and deciphered it.
The attacker was then able to inject a modified packet back into the user’s traffic with the server to impersonate as the user. For this attack to be carried out successfully, the following things need to be true: no server / client encryption or SSL, no session ID to user IP validation, no external intrusion prevention system, and weak encryption of the login system itself.
The attacker now gains access to the application, injects some code to access the underlying IIS instance (XSS or cross site scripting attack / SQL injection attack). The attacker then accesses the needed webserver instance via .NET console and accomplishes the objective.
Get Out
After the attack is complete, getting out is not as simple as closing the window with an X. In this case, the attacker is an experienced IIS admin and knows the location of the logfiles and registry entries that will allow a clean getaway. IIS by default, keeps minimal access logs and records only the most critical data to the windows registry. A simple PowerShell based IIS log cleanup script will suffice in most cases.
Analysis
The following controls / standards were violated:
· IIS instances should not be publicly assessable when running critical internal applications
· IIS instances should be secured with extended validation SSL based certificate systems or CAS based authentication
· The service account / SQL server running account should have the minimal permissions required to run the applications and should NEVER have access to multiple IIS instances
· Application code should be written in a quality matter and constantly checked for security
· IIS log files should not be accessible to anyone but a forensics team or application admin
· GPO based policy should be in effect on the web services server to prevent the deletion of logs
This was written according to ISO 27001–27002 standards
ISO/IEC 27002 code of practice. (n.d.). Retrieved from http://www.iso27001security.com/html/27002.html
