In this blog post I would like to share some tricks to detect suspicious activities that could end with finding compromised hosts inside a network. I´ve noticed (I guess you too) that there are some malware out there and the first things they do, when a computer is infected, is to check the public IP address in order to let the malware developer know, where the infected host is located. We can see this behavior in a lot of malware like Cryptowall 2.0, Kriptovo, ZeroAccess and many more...
I use to work with Suricata as IDS (by the way, really happy with its performance) and Emerging Threats rules in order to detect computers trying to get its public IP address. You know... it´s weird that someone from the Human Resources department is interested in getting their computer´s public IP address...
You can find some free Suricata signatures here that are focused on that task. You can filter by "IP Check" or "External IP Lookup".
If you are using Suricata or Snort as IDS, they are good for starting an investigation when these alerts are triggered but I would like to go a little bit further without allowing the malware to get the public IP address, just to make things more difficult for the malware developer...
I´m not using Suricata as IPS but I do have an IPS and an Application Control with a Fortinet Fortigate firewall. There are many ways to achieve this goal, but this time I think my best bet is Fortinet App Control. Also, a NGFW allows us to perform a man in the middle "attack" and see what´s going on inside a SSL tunnel which makes our signatures more effective, just in case the connection goes to a SSL service...
Creating a custom App Control signature with Fortinet
I've decided to create custom signatures to detect if someone or something is trying to get the public IP address. I would like to share three options that you could work with.
It is not a big deal to create custom signatures with Fortinet App Control to detect these connections, so for me, it worth some of my time to deal with them not only to detect them but drop them.
Example 1 - Easy mode
If we get access to checkip.dyndns.org we can see that the public IP address is returned.
If we look at the pcap capture we can see (obviously) that the host reached is checkip.dyndns.org. We can see the domain in the Host line in the HTTP header, so here is where we will look and it will be defined thanks to the signature Context.
If we want to detect if someone is getting access to checkip.dyndns.org we just need to create the rule bellow via CLI.
edit "External.IP.Lookup.-checkip.dyndns.org-.Custom"
set comment ''
set signature "F-SBID( --attack_id 4467; --name \"External.IP.Lookup.-checkip.dyndns.org-.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pattern \"checkip.dyndns.org\"; --context host; --no_case; )"
set category 25
next
end
* You can find more APP controls example of rules in my Github account.
This rule doesn´t have a lot to explain, it´s really easy and "similar" to Snort/Suricata rules. This is a brief description of our rule:
Once the rules are created, you just need to add them to your AppControl sensor and set the Action.
- -- attack_id 4467; if you don´t specify an attack_id, it will automatically assigned
- --name; signature name
- --app_cat 25; correspond to Web.Ohters category
- --pattern; the string we are going to look for in the packet traffic
- --parsed_type HTTP_GET; is the HTTP method used to retrieve the public IP address
- --flow from_client; Match packets sent from the client to the server
- --no_case; by default, patterns are case sensitive so --no_case makes the pattern matching case insensitive
- --context host; context to match the pattern. There are several ones: HOST, URI, HEADER, BODY, BANNER...
Once the rules are created, you just need to add them to your AppControl sensor and set the Action.
When the changes are applied and we try to get access to checkip.dyndns.org again, the connection will be blocked and we will get that message: "Application Blocked". That is because "Replacement Messages for HTTP-based Applications" is checked.
If you don´t want to inform the users/malware you just need to unset "Replacement Messages for HTTP-based Applications"
and there will not be any messages, the session will be just dropped.
Example 2 - Medium mode
Sometimes we need to specify not just the hostname we want to monitor/block but we also need to specify the HTTP URI. Imagine we need to block "ip-api.com/xml" but we want to let our users still to get access to "ip-api.com".
We will need to check two condition:
- Host: ip-api.com
- URI: xml
So we will need to set two patterns and two context:
- --pattern \"ip-api.com\"; --context host;
- --pattern \"xml\"; --context uri;
This is the rule we need to configure.
config application customedit "External.IP.Lookup.-ip-api-.Custom"
set comment ''
set signature "F-SBID( --attack_id 5188; --name \"External.IP.Lookup.-ip-api-.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_client; --pattern \"ip-api.com\"; --context host; --no_case; --pattern \"xml\"; --context uri; --no_case; )"
set category 25
next
end
Example 3 - Paranoid mode
As you have noticed, if the malware retrieves the public IP address from a domain which has not been included in our signatures, we will not be aware of it and the session will not be monitored/dropped.
There is a possible solution. When the malware requests the public IP address from a web server, it responds with the IP address in the HTTP body.
What we can do is to look at the responses looking for our public IP addresses. Of course, we usually have more than one, in my case, a complete class B network. In order to check if our class B network (88.11.0.0/16) is included in the server response, we will use PCRE.
What we can do is to look at the responses looking for our public IP addresses. Of course, we usually have more than one, in my case, a complete class B network. In order to check if our class B network (88.11.0.0/16) is included in the server response, we will use PCRE.
To achieve our goal, we need to set the following parameters:
- --flow from_server; Match packets sent from the server to the client
- --pcre /88.11.[0-9]{1,3}.[0-9]{1,3}/; That regular expression matches from 88.11.0.0 to 88.11.999.999
- --context body; we will look at the server response in the HTTP body
config application custom
edit "External.IP.Lookup.Detected.Custom"
set comment ''
set signature "F-SBID( --name \"External.IP.Lookup.Detected.Custom\"; --app_cat 25; --protocol tcp; --service HTTP; --parsed_type HTTP_GET; --flow from_server; --pcre /88.11.[0-9]{1,3}.[0-9]{1,3}/; --context body; )"
set category 25
next
*** Think about possible false positives before setting this rule to Block. You should monitor before blocking because some web pages like glassdoor.com, returns your public IP address in the commented source code...
0 comments:
Post a Comment