Menu Close

Category: ATM

Moloch Upgrade

Moloch Upgrade

  • Authors: Tomáš Mokoš, Miroslav Kohútik

Upgrading Moloch to the latest version is not possible from all versions. Some older versions require installation of newer versions in an exact order.

Upgrading to Moloch 1.1.0

The oldest version of Moloch we have had in active use was version 0.50.
Upgrading Moloch from version 0.50 to version 1.0 and higher requires reindexing of all session data due to the large changes introduced in version 1.0. Reindexing is done in the background after upgrading, so there is little downtime before the server is back online.

Analysis of the ISCX dataset from june 15th

Dataset 2012 – ISCX – Elsevier

In this article we take a closer look at the ISCX IDS 2012 dataset created by the Canadian Institute for Cybersecurity.

Network datasets serve for the purpose of training of network security systems, namely IDS and IPS.

Analysis of the ISCX dataset from June 15th in Moloch

The size of PCAP data from this day is 24.5 GB. The dataset is described in three XML files, with the attack being described in the file TestbedTueJun15-3Flows. The description implies a DDoS attack using an IRC botnet.

According to PCAP data, the most intense part of the attack lasted for one hour from 21:05 to 22:05. In the XML file, the attack is recorded at 16:04, therefore there is a 5-hour delay between the data.

The attack originated from infected devices in a private network, with the target being the device with IP address Other sessions marked as attacks were of too low intensity to be visibly displayed. According to the XML description, the attack commenced roughly one hour before the start of the most intense part and lasted for five more hours after its end.

This is an illustration of the most intense part of the attack. IP address with the highest traffic representing the device being attacked is located in the center of the graph. Network communication that was not a part of the attack is being displayed too

This illustration shows only the originating addresses of sessions with destination address – target of the attack.

Analysis of the dataset in IDS Suricata

Immediately, Suricata detected high amounts of P2P bittorrent traffic (this does not necessarily imply an attack, rather than a violation of network terms).

In the early morning hours (3 a.m. to 4 a.m. ) of the following day (16.6.), several brute force attack attempts on the aforementioned IP address ( were detected. Several attempts of the same attack in the opposite direction were also detected (internal IP address was attempting to reach an external IP address via SSH).

In addition, Suricata detected several possible Trojans and Malwares (about 60), e.g. Blue Botnet for attack generation and Sality for infection of files in OS Windows. In the afternoon and evening hours, an access to website was also detected. This site is linked to typical scammers from India who pose as MS support and demand your credit card number for cleaning of a purportedly infected computer.

Suricata failed to directly detect an ongoing DDoS attack, the only sign which was generation of “STREAM 3way handshake with ack in wrong dir” alert between IP addresses and 150x per second. However, since the alert always regarded the same IP addresses, we should have been dealing with a DoS attack, rather than a DDoS attack. The aforementioned TCP anomaly occurred for unknown reasons, if it were not for this, there would be no sign of an attack.

Suricata supports rule thresholding, which can be used to detect DDoS attacks. These thresholds have parameters which define the number of sessions, timeframe, maintaining count by source or destination IP address etc. A signature for detecting DDoS attacks using this rule is located online. However, the test performed on this dataset was unsuccessful even after editing of the aforementioned parameters. Dataset analysis revealed that the malicious packets contain TCP flags PUSH and ACK, while the signature expected packets with SYN flag (TCP SYN flood detection). After the removal of the rule, the signature was unusable, since its rules have been met even for normal traffic. I have tried editing the rule’s TCP flags to PUSH and ACK and tested its functionality.

It was necessary to find the marginal value of packets per second low enough to trigger the alert for a potential DDoS attack and high enough not to trigger the alert for common traffic and make sure that alert is triggered only for IP addresses involved in the attack.

My work was complicated by the fact that there were not just the packets incoming from the attacking IP addresses, but also packets outbound in the opposite direction because the attacked server tried to respond to all those HTTP requests. I could have set a signature rule to match destination IP address to server IP, this would, however, render the signature useless for other purposes. The solution to this was to consider only the source IP addresses of the alerts during text formatting (elimination of duplicities and other superfluous data) and ignore the destination addresses.

While counting packets by destination IP, I needed to get at least one alert. I have concluded that precisely one alert is generated at traffic exceeding 8500 packets per second. Minimal traffic involving only the attacking IP addresses was ca. 800 packets per second.

In contrast, while counting packets by source IP, it is necessary to generate at least one alert for each attacking IP address. The maximum flow at which all the attacking IP addresses were detected was ca. 200 packets per second. Minimum flow at which no attacking IP addresses were detected was ca. 100 packets per second.

Summary of attacks (excluding DDoS attacks) detected by IDS Suricata:

PCAP time Attack Src. IP and port Dest. IP and port
05:58:34.34 Blue Botnet
06:52:16.11 Blue Botnet
07:00:26.37-07:01:49.75 Blue Botnet
07:26:06.70 SSH Scan
09:13:55.36 Sality
09:52:16.48 Sality
11:52:36.59-12:20:50.57 Blue Botnet
12:22:13.68 Blue Botnet
13:42:37.50 Blue Botnet
13:43:17.58 Blue Botnet
13:43:26.02 Sality
13:50:04.74 Blue Botnet
13:51:41.43 Blue Botnet
13:52:37.86 Blue Botnet
13:52:40.68 Blue Botnet
13:52:41.26 Blue Botnet
13:53:53.14 Sality
13:54:08.33 Blue Botnet
13:55:32.63 Sality
13:57:59.03 Sality
14:01:57.07 Sality
14:30:42.14 Sality
15:00:18.78 Sality
15:52:56.48 Sality
16:19:14.08 Sality
16:36:36.10 Blue Botnet
16:39:18.07 Blue Botnet
16:54:38.75 Blue Botnet
16:55:15.07 Sality
17:21:56.68 Blue Botnet
17:56:24.79 Sality
18:54:46.43 Sality
19:17:27.72 Sality
20:27:20.45- 22:06:47.20 IRC správy * *
23:12:26.69 Sality
23:13:43.47- 23:14:04.25 Blue Botnet
00:03:06.58 Sality
03:56:02.22- 03:57:15.40 SSH Scan
04:01:24.27 MSIL/Karmen Rans.
04:36:30.46 SSH Scan

* -> -> -> -> -> -> -> -> -> -> -> -> -> ->

Dataset analysis from XML file and PDF article (JU)

  • Test period: 00:01:06 Friday, 11.06.2011 – 00:01:06 Friday, 18.06.2011

  • We have analyzed Tuesday, 15.6.2011
    • Time difference between XML and PCAP is 5 hours
      (i.e. 16:00 in XML = 21:00 in PCAP)

    How we proceeded:

        1. Information gathering and reconnaissance (passive and active)
    1. Vulnerability identification and scanning
    2. Gaining access and compromising a system
    3. Maintaining access and creating backdoors
    4. Covering tracks

    Scenario 1: infiltrating the network from the inside


    • We have used a DNS request to discover mail server IP address. Messages containing a virus were sent to e-mail addresses from the server, this enabled the attackers to access the network. Using the Metasploit tool and reverse TCP shell 5555 the attackers created connection to the devices inside the network.
      • The devices that were misused belonged to network:

      Scenario 2: HTTP DoS

      • The Slowloris tool was used to overload the Web server by sending incomplete HTTP requests to keep the socket open. Since the number of sockets available to the Web server is finite, it is only a matter of time until they are exhausted and server becomes inaccessible.

      Scenario 3: DDoS using an IRC Botnet (Internet Relay Chat)

      • This bot was sent to users as an update message
      • Subsequently, DoS launched HTTP GET attack from each infected device, creating hundreds of requests
      • The attack lasted for 60 minutes


      • AppName marked in XML: HTTPweb
      • IP address of the targeted web server:
      • Beginning and end of the attack:
        • PCAP time: approximately 21:00 – 22:00
        • XML time: 16:04:42 – 17:05:49

        First and last session that were part of the attack:

        • 16:04:42 – 16:04:43
          • IPsource: /Ps: 2677
          • IPdest: /Pd: 80
          • Duration: 1s
          • Inbound packet count (source): 103
          • Outbound packet count (dest.): 270

          17:05:48 – 17:05:49

          • IPsource: /Ps: 4131
          • IPdest: /Pd: 80
          • Duration: ?
          • Inbound packet count (source): 78
          • Outbound packet count (dest.): 170

          Scenario 4: Brute Force SSH


          • Dictionary attack on users

How to kill ESET AV process

Eset AV sometimes prevents to run and install some applications, for example microtorrent client or virtualbox extension pack. If the AV pausing does not help, there is an option to kill the AV process using a standard way (using the task manager). However, Eset AV has enabled by default a Self-defense feature preventing to do that.

Therefore to be able to kill the process this feature has to be disabled. To do that follow:

Remove Yahoo Search! from Firefox

One of firefox features is that when typing a partial URL into the URL field (URL or location bar), Firefox will automatically contact Google's search engine to find and provide search answers. This work fine till one of your computer users download the Yahoo search add-ons, which makes Yahoo Search! default Firefox search without being aware or alerted about that. So if we have the Yahoo add-on and we will type a key word (or partial Web address), we will not go straight to the Google search but instead we will see Yahoo Search results.


With the CLIP, (as mentioned before), inter-LIS communications have to go through routers. This is not an optimal solution when both nodes communicate with each other are attached to the same ATM network. A mechanism is needed for an end system to resolve the IP address of another end system in a foreign LIS into the corresponding ATM address. The NBMA (Non Broadcast, Multi Access) NHRP protocol, developed by the IETF, overcomes this limitation and provides this mechanism.


5 Signalizácia v ATM

5 Signalizácia v ATM


5.1 Súbor hosts pre ATM

ATM adresa je dlhá 20 bajtov, preto jej používanie je pri narábaní s ATM sieťov nepohodlné. Mnohé z nástrojov sady ATM Tools podporujú okrem číselných adries aj priamo napísané meno počítača. Mapovanie medzi ATM adresou a jeho menom je definované v súbore /etc/hosts.atm. Formát tohto súboru je rovnaký ako pre súbor /etc/hosts