Sign in
Follow

How to analyze scanning events

There are essentially 5 phases of an attack

  • Reconnaissance—collecting data (active and passive)
  • Scanning—use the collected data to examine the network for vulnerabilities
  • Gaining access
  • Maintaining access
  • Covering tracks

For this article, we are only covering how to detect ‘active’ reconnaissance and scanning.

With the help of Network Intrusion Detection (NIDS) events, you are usually able to detect most ‘active’ reconnaissance and scanning and deal with it prior to the attacker gaining access.

NetWatcher leverages the Emerging Threats NIDS rules, which can detect scanning attempts and create alarms.  Before we will look in detail how to analyze events related to scan, we must briefly define:

  • Types of scans
    • Reconnaissance is when an intruder engages with the targeted system to gather information about open ports, open services, applications, operating systems, models of LAN/WAN equipment. Some common ‘active’ tools attackers use are Nmap, Hping3, Maltego, FOCA, pygeoip, Whois,  Sparta, Recon-ng and zMap.  Other ‘passive’ tools that don’t leave a footprint are found on sites such as https://io & https://searchdns.netcraft.com
    • Vulnerability scanning is a security technique used to identify security weaknesses in a computer system by throwing Network Vulnerability Tests (NVTs) at the asset. Individuals or network administrators, for security purposes, can use vulnerability scanning. Hackers attempting to gain unauthorized access to computer systems can use it as well. One example of a full on vulnerability scanner is OpenVAS.
  • Which events can detect scanning? Events that appear on one of the following categories:
  • What are the basic recommendations to thwart scans?
    • Shutting down all unneeded ports and services;
    • Allow critical devices, or devices housing or processing sensitive information, to respond only to approved devices;
    • Closely manage system design, resisting attempts to allow direct external access to servers except under special circumstances and constrained by end-to-end rules defined in access control lists
    • Maintain proper patch levels on endpoints, LAN/WAN systems, servers OS, applications etc.

Unfortunately, there is no common industry guide for how to analyze scanning events, but we will give you a couple of examples with the basic instructions of what to check first and what to do if you detected a successful scan.

Here are the basic event analyses steps:

  1. First, you need to determine if the scan resulted in an established connection or not. If the connection was not established (for example, if it was blocked by the firewall or the requested service was not running on asset) you can stop analyzing the event. Only look at the related events to be sure that there are no other serious issues (events).  An easy way to do this is to download the session PCAP or look at the Netflow Analytics and see if there are more than 3 to 10 packets in total between the 2 assets.
  2. The most critical step: If a connection was established, we must understand what the rule says and what it detects. Each event contains “Snort Rule Information” like on the screenshot below:1.png

To be able to understand the rule please refer to:

In the examples below, we will refer to some portion of the rule.

  1. Download the session PCAP and read the information from “reference” part of the rule. The PCAP will give you all necessary network flow details and the link from the “reference” will give you an advanced explanation about the threat, which the rule detected. In the example, we will explain why it is crucial to read “reference” info.   
  2. Figure out the relevance of the event by reviewing the targeted internal asset. There are many automatic vulnerability scanners on the Internet that performs a so-called "blind scan". We must determine whether the analyzed event carries a threat to our asset. If an event is triggered does it pose a threat to our asset (for example threat related to Cisco router but was launched to our Microsoft IIS web server)?
  3. The final step is to eliminate the detected threat and strengthen protection.

 

Now we have basic instructions and we can continue with several examples.

 

Example 1: Detecting scanning attempt

NetWatcher Event name: ET SCAN JCE Joomla Scanner

NetWatcher Alarm name: Someone is scanning your network with JCE Joomla Scanner.

Attack vector: Scan victim server for vulnerable Joomla version and lunch webshell/backdoor for remote administration purpose. 

Links to additional information:

 

This is what the event looks like in NetWatcher:

 2.png

This is the event rule:

 3.png 

  • Pay attention to the content of the rule. Following content will trigger an event: "User-Agent|3a| BOT/0.1 (BOT for JCE)"

At the beginning of this example, you can refer to the exploit explanation and what is JCE BOT

  • We downloaded the PCAP and can see the network flow details. We see that our server is likely not vulnerable to that exploit because it responded with the message: “HTTP Error 400. The request is badly formed”

 

HTTP/1.1 400 Bad Request

Content-Type: text/html; charset=us-ascii

Server: Microsoft-HTTPAPI/2.0

Date: Sun, 18 Mar 2018 14:41:25 GMT

Connection: close

Content-Length: 311

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request</h2>

<hr><p>HTTP Error 400. The request is badly formed.</p>

</BODY></HTML>  

 

Action:

  • Contact with web server owner for additional information (web server passport);
  • Investigate if this vulnerability is acceptable to your web server.
  • Run your own NetWatcher vulnerability scanner against the web server to be sure that you are not mistaken in your conclusion.
  • The blacklist attacker IP address (e.g. create Firewall block rule, move IDS signature to prevention mode, or if your website should not be accessible from the Internet, block all access to it, and so on …)
  • If your server is vulnerable to attack explained in reference links to this example you must immediately upgrade your system or install necessary patches.

Advanced attack explanation: https://www.trustwave.com/Resources/SpiderLabs-Blog/-Honeypot-Alert--JCE-Joomla-Extension-Attacks/

 

Example 2:

NetWatcher Event name: ET SCAN LibSSH Based Frequent SSH Connections Likely Bruteforce Attack.

NetWatcher Alarm name: Device or system brute force attempt.

Attack vector: someone is trying to pick up a password for your server with enabled SSH service (classic brute force).   

Links to additional information:

 

This is how the event looks like in NetWatcher DSAP:

4.png

  

This is the rule from the event:

5.png

  • Pay attention to the “threshold” rule statement. Obviously, it means that rule will trigger when NIDS will see more than 5 SSH connection attempts within 30 seconds for the same source IP address. Classic brute-force, is it not?
  • Most important from this event is that you have up-and-running SSH service. SSJ server accessible from the whole internet (we come to such a conclusion because connection originated Ukraine).

Action:

  • Restrict access to your SSH server based on IP address or geolocation. The best solution will be to open access only for some IP which you can control.
  • If SSH is not required, disable SSH service on the server.
  • If necessary, configure strong login and password and decrease privileges for remote users.    

 

Example 3:

NetWatcher Event name: ET SCAN Nessus User Agent.

NetWatcher Alarm name: Someone is scanning your network with Nessus.

Attack vector: Someone is trying to scan your network with the help of Nessus scanner.

Links to additional information:

 

This is how the event looks like in NetWatcher DSAP:

 6.png

This is the rule from the event:

7.png

As we can see in the rule if the user agent in the HTTP header contains “Nessus” this rule triggers.

Nessus is a vulnerability scanner (please refer to “reference” portion of the rule), and attackers use it (for example trial version) to scan networks for vulnerabilities or for information gathering (recon).

Our action, in this case, will be very easy:

  • If this scan was unauthorized, we can block the attacker’s IP on the firewall.
  • If you have a WAF, you can configure a rule to block such HTTP requests in future.

 

 

Now, let's look at how to analyze the event from “ET EXPLOIT” category. As mentioned before, many attackers miss the reconnaissance phase and immediately run vulnerability scanners. The main difference between “ET SCAN” and “ET EXPLOIT” categories is that “ET EXPLOIT” immediately launches an attempt to exploit certain vulnerabilities, sometimes not paying attention to the lack of information about the target assets. The analysis of “ET EXPLOIT” rules is more complex since you are required to check the applicability of the attack to your asset. For that, in most case, you must:

  • You must understand the rule. Use “reference” portion of the rule, use google search, use NVD and CVE, use some keywords from the PCAP (for example URI form HTTP header or user agent names if they are suspicious). After this research you must understand why this event happens, what is the goal of the attack and the rule to which system this vulnerability applies.
  • The most critical step - If you are not sure if the detected exploit attempt applied to your system, you must do security research. For example, you see that the rule detects some exploit attempt for a vulnerable WordPress website. You know that your website is built on WordPress. Also, you investigated that certain vulnerabilities exist on some versions of WordPress (not for all versions). Finally, you must scan your asset for the following information: version, plugins, existing vulnerabilities. For that, you can use your NetWatcher vulnerability scanner.
  • As usual, you need to take appropriate action based on the analysis results.

 

Now let’s pick up a couple of events.

Example 1:

NetWatcher Event name: ET EXPLOIT Possible ZyXELs ZynOS Configuration Download Attempt (Contains Passwords.

Attack vector: someone is trying to exploit vulnerable ZYXEL firmware (ZynOS). In a nutshell in vulnerable wi-fi routers with ZynOS we can get rom-0 file which contains admin password in clear text.

Links to additional information:

 

Let’s skip the screenshot and refer to the rule:

8.png

We see that this will trigger when someone creates a specific HTTP request.

The request should look like “http://destination_ip_address/rom-0”

“rom-0” is a file-specific file which contains passwords in clear text.

Now we should refer to the analysis steps described on top and answer the question – Is our system vulnerable to such attack?

The answer is NO! Let’s explain why not -

PCAP from the event:

GET /rom-0 HTTP/1.1

Host: 172.23.100.100

Cookie: C6=rom0

Connection: Close

 

HTTP/1.0 404 Not Found

Date: Tue, 13 Mar 2018 17:55:33 GMT

Cache-Control: private

Accept-Ranges: bytes

Connection: close

Content-Type: text/html

Last-Modified: Thu, 01 Jan 1970 00:00:55 GMT

Content-Length: 0 

Explanation:

  • Our system responded with error. No file was downloaded.
  • Next, we made a request to http://172.23.100.100 . We clarified that 172.23.100.100 is MXmeeting (Zultys) appliance with proprietary software. Pay attention that this system is definitely not vulnerable to attack described at the top.

Action:

  • No action required. We did a short investigation and proved that attack is not relevant to our system. We can consider, as a variant, creating a more restrictive access rule, but it is not necessary.

 

Example 2 (advanced):

NetWatcher Event name: ET EXPLOIT Joomla RCE M2 (Serialized PHP in UA).

Attack vector: object injection via the HTTP user agent that leads to a full remote command execution. Affected Joomla version from 1.5 to 3.4.

Links to additional information:

 

Rule from event:

 9.png

PCAP from event:   

GET / HTTP/1.1

Connection: Close

Accept: text/html, */*

User-Agent: }__test|O:21:"JDatabaseDriverMysqli":3:{s:4:"\0\0\0a";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:5:"cache";b:1;s:19:"cache_name_function";s:6:"assert";s:10:"javascript";i:9999;s:8:"feed_url";s:54:"eval(base64_decode($_POST[111]));JFactory::get();exit;";}i:1;s:4:"init";}}s:13:"\0\0\0connection";i:1;}....

Host: nwtest.com

 

Now you need to clarify - Is your server vulnerable to this attack or not? As you are not a web server owner, you may not be familiar with the version of your server, for example.  But know that only Joomla websites version from 1.5 to 3.4 are vulnerable.

To accomplish our goal we can refer to Kali Linux. As a security analyst, you should be familiar with what Kali is and how to use it.

Below we will show you an example how Kali can be useful in this particular case. But be informed that Kali has a lot of features and tools which you can use for very different tasks (e.g. information gathering, exploitation, vulnerability scanning, and much more).

Ok, let’s see - Do we have Joomla on the interested server and what version do we have?

Run metasploit in Kali box:

Type command:

msf > search joomla_version

You should see option:

 auxiliary/scanner/http/joomla_version

Choose it:

msf > use auxiliary/scanner/http/joomla_version

msf auxiliary(joomla_version) >

Configure and run the scan of you server:

msf auxiliary(joomla_version) > set RHOSTS 172.23.100.100

RHOSTS => 172.23.100.100

msf auxiliary(joomla_version) > run

[-] It doesn't look like Joomla is up and running at /

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

 

As you can see, we scanned our server and we did not find any Joomla version on it. Our server is not vulnerable to detected attack.

 

There is no common guide for “how to analyze scanning events” because each case (event) is unique.

Keep in mind before proceeding to the analysis stage, you must carefully read all the reference links. If they are not available or detailed in regard to understanding how the attack works, try a simple Google search. 98% of all attacks are already very well documented and easily accessible.

Comments

Powered by Zendesk