top of page

Intrusion Detection Systems CTD.

Updated: Sep 29, 2023


Image showing hands coming out of computers.

In this blog:

This is a continuation of my introduction to Intrusion Detection Systems blog ➡️


What breaches can IDS's reduce?


Since intellectual property is the target of an increasing volume of cyber-attacks involving ransomware as a service (RaaS), it’s imperative that businesses guard their environments against such threats to eliminate the possibility of an intrusion.


NIS Regulations require OES and RDSPs to have sufficient security systems in place to prevent data from compromise and to report Incidents to a competent authority like the ICO.

Image showing webpage.
Click to see more about NIS on the ico website.

IDS’s can passively detect changes in network traffic/ host behaviour or actively step in to mitigate threats on behalf of security responders.


For example, an abnormally high volume of internet traffic from the same IP address would signal an attempted Denial of Service attack, resulting in the event being recorded for and the security team being notified of the incident.


NIDS comb through packet headers and dig deeper into TCP/ UDP payloads by following protocol streams and identify abnormal behaviour as they are programmed to understand how such protocols should normally work.

Image showing NIDS and HIDS in a network.
NIDS and HIDS working in a network.

A HIDS can also detect unapproved login, access efforts, escalation of privilege and trace the attempts back to the root address for analysis during incident response.


Alteration of application binaries and file configurations can also be detected, as changes in the source code of critical files can lead to system shutdown.


All events are logged as per universal regulations.

What breaches can't IDS's reduce?


One major downfall of an IDS is the high volume of false negatives. In particular, ‘Zero-day’ vulnerabilities that employ new tactics and rely on exploits that an IDS may be unfamiliar with.


An example of a zero-day vulnerability is the Microsoft Office RCE 0-Day CVE-2022-30190, or “Follina”.


According to Microsoft guidance, remote code can be executed when MSDT is called using the URL protocol from calling applications like Word (shown in figure 2 below).


Unzipping an affected word document, a .xml file reveals an external reference to ➡️

Image showing link address.
External link embedded in malicious Word document.

The script consists of 4096 bytes worth of commented ‘A’ characters, due to a hardcoded buffer size for an HTML processing function.


The MS-MSDT: URI handler has components implemented in PowerShell so you can craft a URI where some parts of arguments are specified to be subexpressions.


The attack gets the URI to open without prompting.


The vulnerability is particularly dangerous running from the trusted Word application, with no macros to trigger familiar warning signs.

Image showing Follina exploit chain.
Follina exploit chain.

HIDS’s can detect malicious directory traversal, for example, by sub-processes that normally wouldn’t be running from a Word document.


However, since this is a 0-day vulnerability and uses Microsoft’s diagnostic tool, there’s little for Windows defender and other detection services to go off.


What’s worse is that Rich Text Format files (.RTF) can trigger the exploit with just the preview pane inside Windows File Explorer.

Image showing Microsoft Word file.
Rich Text Format file delivering payload. Image from Huntress, by John Hammond. Click to see John Hammond’s proof of concept for CVE-2022-30190.

Of course, this now changes the ‘single-click’ requirement to a ‘zero-click’ attack which increases its severity, like the NSO developed ‘Pegasus’ spyware created in 2016.

Image showing webpage.
Click to see how to duplicate the malware in a Virtual Machine.

Implementing IDS within a company


There are two main types ➡️ Host-Based and Network-Based.


Host-Based systems are deployed on a single host to track packets aimed at the host's local system or processes, whereas Network-Based systems use network cards in promiscuous mode to analyse all packets on network segments.


NIDSs are implemented using appliances and software-based IDS.


Appliances like Cisco’s IDS are made up of an IDS sensor and an IDS director.

Image showing webapge.
Click to see more about Cisco's Talos software.

The sensor is placed in the specific connection which you wish to monitor, detecting unauthorised activity by analysing the traffic against rule-based signature files.


The sensor then sends alarms to the management console and controls other network devices like routers to block suspicious sessions at which point it’s the network analyst’s role to analyse the alarm and take appropriate actions.


The IDS director is a software-based management system that monitors sensor activity. Sensors are located on the local or remote network segments.


Network traffic can be tracked using software based IDSs that can be installed on the operating system.


These IDSs can be handled by Cisco Systems and outsourced, for instance via Snort.org. Snort is a suite of three programmes that includes a packet sniffer, packet logger, and intrusion detection. It uses rules (written by your company's security administrators or downloaded from the Snort community) to identify attacks such as port scanning, SMB probing, OS fingerprinting, and others using both signature-based and anomaly-based techniques.

Image showing Snort webpage.
Click to see more about Snort.

Once you have decided which IDS to go with, the next step is deployment. The four typical areas of monitoring are ➡️

Server farms, Wan backbone, Network parameter, and LAN backbones.


  • The network perimeter consists of points of entry and exit on each side of the firewall, as well as connections to cooperative networks and cloud services. Typically, these vectors serve as the point of entry for external attacks.

  • The WAN backbone frequently harbours illegal activities and LAN backbones are hubs of heavy traffic. Not the best for an IDS.

  • Finally, servers are located in their own segments with a huge volume of data – Again, not good for an IDS. The best course of action would be to evaluate and select targets of most value to instal sensors on and monitor if server farm traffic is too heavy to monitor collectively.

Deciding where to deploy IDS sensors is important as various aspects of security should be considered. For example, you must make sure the IDS doesn’t affect the performance of the network segment you are monitoring.

Cost of staffing


As the number of warnings rises, an IDS requires more adjustment and analysis, and smaller businesses could lack the resources necessary to manage all devices at full capacity.


A NIDS sensor can monitor a network without changing the infrastructure and responds more quickly than HIDS-based sensors.


Additionally, NIDS are less expensive to set up and maintain, making it a more viable option for many smaller organisations.


Because different products have different blind spots that must be dynamically addressed, no one security solution in the enterprise market is ideal, and no instrument should be depended upon more than the others. It's also important to note that an IDS cannot replace a solid security policy.


Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
  • GitHub
  • Twitter
  • LinkedIn
bottom of page