Stopping every intrusion before the attacker is able to enter your network is a dream. We all know that prevention eventually fails, but does that mean that we’ve failed? I don’t think so. I think that if we can detect and stop an intruder before they are able to accomplish whatever goal they have we’ve succeeded. There is a saying that intruder needs to be right only once and a defender needs to be right every time. I disagree with this statement. An attacker will leave traces of their activity and if we layer our detection we will have a better chance of identifying their activity during the course of an intrusion. Before we do this though, we should think about what it takes for an adversary to be successful and encompass those actions into our detection and hunting strategies. This is the first post in a series I wanted to do on this topic.
I was having a conversation with a colleague a while back and the topic came up on what an intruder needs the ability to do during a targeted intrusion. The following are the ones that I came up with, though he had a few others.
1. An adversary needs to enter your network
2. Maintain persistence in your environment
3. Have the ability to execute commands with the correct privileges
4. Locate the data they are after
5. Get the data out
2. Maintain persistence in your environment
3. Have the ability to execute commands with the correct privileges
4. Locate the data they are after
5. Get the data out
Thinking about the above and knowing that an attacker can’t hide every trace of their activity, that’s 5 different stages an intruder needs to accomplish in order to be successful.
An adversary needs to enter your network
This usually involves exploiting some type of weakness in your environment.
1. Exploiting an end user system via a phishing attack or watering hole.
2. Exploiting a vulnerability on an internet facing device.
3. Using stolen legitimate credentials to login as a normal user.
4. Successful password guessing attack against an external facing applications (are administrative portals open to the internet? If so, do you know the password complexity?)
This usually involves exploiting some type of weakness in your environment.
1. Exploiting an end user system via a phishing attack or watering hole.
2. Exploiting a vulnerability on an internet facing device.
3. Using stolen legitimate credentials to login as a normal user.
4. Successful password guessing attack against an external facing applications (are administrative portals open to the internet? If so, do you know the password complexity?)
Maintain persistence in your environment
Companies that have experienced compromises that have lasted months to years know too well that the attacker was able to enter their network at will. As the intrusion progressed the methods of access or number of access points may very well have changed too.
1. Backdoor’s
2. Webshells
3. Credentials via legitimate access
Companies that have experienced compromises that have lasted months to years know too well that the attacker was able to enter their network at will. As the intrusion progressed the methods of access or number of access points may very well have changed too.
1. Backdoor’s
2. Webshells
3. Credentials via legitimate access
Have the ability to execute commands with the correct privileges
This stage may encompass several different steps for them to be successful.
1. Credential harvesting
2. Remote CLI
3. Remote Desktop
4. Remote task scheduling
5. Attacker tools
This stage may encompass several different steps for them to be successful.
1. Credential harvesting
2. Remote CLI
3. Remote Desktop
4. Remote task scheduling
5. Attacker tools
Locate the data they are after
An attacker typically won’t land on the device or devices they intend to steal data from when they gain their initial foothold. They will likely need to first locate it (if they don’t already know). Gain access to it and locate the data on it.
1. Scanning
2. Lateral movement
3. Attacker tools
An attacker typically won’t land on the device or devices they intend to steal data from when they gain their initial foothold. They will likely need to first locate it (if they don’t already know). Gain access to it and locate the data on it.
1. Scanning
2. Lateral movement
3. Attacker tools
Get the data out
Once the data is located how is the attacker able to move it off the device and out of your network.
1. Data packaging
2. Data staging
3. Exfiltration
4. Attacker tools
Once the data is located how is the attacker able to move it off the device and out of your network.
1. Data packaging
2. Data staging
3. Exfiltration
4. Attacker tools
Since step one is usually very short lived I’ll skip that one and go onto step 2. I spend a lot of time looking at ways attackers may take advantage of different tools and how this may look in different sets of data. If we look at the use of webshells in an intrusion what are the different ways someone may be able to find them. I’ve actually posed this question to people on a few occasions and I think this is a good one to talk about as the responses are usually very different. I’m not at all saying they are wrong, but simply the responses cover a wide range of ideas.
Below are some of the ways I think you may have success when looking for compromised webservers in your environment.
AV
People say that AV is dead, but I disagree. AV may not catch everything or block what it is able to detect, but the logs can be invaluable when hunting for compromised hosts on your network. When looking for compromised webservers it may be good to initially look for any AV hits where the file extension matches .asp, .aspx, .jsp, .php, .cfm or.js to name a few. If you do find any hits, is the alert related to a file that would be in the DOCUMENT_ROOT of the webserver? Another indication may be other AV hits for types of recon tools.
People say that AV is dead, but I disagree. AV may not catch everything or block what it is able to detect, but the logs can be invaluable when hunting for compromised hosts on your network. When looking for compromised webservers it may be good to initially look for any AV hits where the file extension matches .asp, .aspx, .jsp, .php, .cfm or.js to name a few. If you do find any hits, is the alert related to a file that would be in the DOCUMENT_ROOT of the webserver? Another indication may be other AV hits for types of recon tools.
URI structure and POST data
Thinking about what a webshell would typically provide to an attacker, one of the most common things would be command line access to the webserver. When a command is executed it is often not from a running cmd window, but rather each command is executed one by one and each calling cmd.exe. For these commands to be executed the “/c” argument will need to be used in conjunction with cmd.exe or just cmd. The command will also need to be passed by the webshell and would commonly be in a http POST request. Some webshells may pass the command in the URI while others may pass it in the POST data and may be encoded somehow. When looking for compromised webservers it may be good to look for either the string “cmd.exe /c” or “cmd /c” using ascii or commonly used encoding types such as hex and base64. You may also find some wins looking for the string “C:\” using the same method. Note: Don’t forget to include HTML safe characters when searching for ascii (C:\ would translate to C%3A%5C).
Thinking about what a webshell would typically provide to an attacker, one of the most common things would be command line access to the webserver. When a command is executed it is often not from a running cmd window, but rather each command is executed one by one and each calling cmd.exe. For these commands to be executed the “/c” argument will need to be used in conjunction with cmd.exe or just cmd. The command will also need to be passed by the webshell and would commonly be in a http POST request. Some webshells may pass the command in the URI while others may pass it in the POST data and may be encoded somehow. When looking for compromised webservers it may be good to look for either the string “cmd.exe /c” or “cmd /c” using ascii or commonly used encoding types such as hex and base64. You may also find some wins looking for the string “C:\” using the same method. Note: Don’t forget to include HTML safe characters when searching for ascii (C:\ would translate to C%3A%5C).
Other things you can look for as it relates to URI’s may be GET requests to odd file extensions with high byte counts. Repetitive GET requests to odd file extensions in the same directory path.
String scanning
Scanning the filesystem of webservers can be an effective way to identify known webshells. This can be easily accomplished with grep or powershell and a word list. When creating your wordlist try to identify items that may not be frequently changed like function names and try to include a few of them per webshell you are scanning for. Another tool that can be used for this is CrowdResponse which I will talk about in a later post.
Scanning the filesystem of webservers can be an effective way to identify known webshells. This can be easily accomplished with grep or powershell and a word list. When creating your wordlist try to identify items that may not be frequently changed like function names and try to include a few of them per webshell you are scanning for. Another tool that can be used for this is CrowdResponse which I will talk about in a later post.
Network session data
When an attacker compromises a webserver expect them to attempt to move laterally from it. You can use session data to identify internal network connection attempts that have been initiated from your webservers. Some things to look at may be:
1. Are these consistent with typical activity or are these attempts new?
2. How did these sessions end and what did the byte counts look like?
3. Are there any patterns that may indicate attempted scanning?
4. What are the destination ports i.e. 445, 3389, 1443?
5. For any of the above ports, what is the duration and byte count of the sessions?
When an attacker compromises a webserver expect them to attempt to move laterally from it. You can use session data to identify internal network connection attempts that have been initiated from your webservers. Some things to look at may be:
1. Are these consistent with typical activity or are these attempts new?
2. How did these sessions end and what did the byte counts look like?
3. Are there any patterns that may indicate attempted scanning?
4. What are the destination ports i.e. 445, 3389, 1443?
5. For any of the above ports, what is the duration and byte count of the sessions?
Established network connections
If you have the ability to pull network connection data from your hosts, do you see any connections spawned from a webserver process to a port on localhost i.e. localhost TCP 3389 <- TCP 2222? This may indicate some type of tunneling over http. Processes
Webserver processes such as w3wp, Tomcat, Apache should be monitored very closely for what child processes are spawned under them. I wrote a post a few months back that talked about this so I will just link to that post here Another hunting post
If you have the ability to pull network connection data from your hosts, do you see any connections spawned from a webserver process to a port on localhost i.e. localhost TCP 3389 <- TCP 2222? This may indicate some type of tunneling over http. Processes
Webserver processes such as w3wp, Tomcat, Apache should be monitored very closely for what child processes are spawned under them. I wrote a post a few months back that talked about this so I will just link to that post here Another hunting post
I know that what I talked about above has bled over to a few of the other stages, but I feel they all relate to finding webshells in your environment. If you have additional ideas regarding this topic I would love to hear them. Feel free to reach out to me on (@jackcr) twitter.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.