Expanding the functionality of our SIEM system

We meticulously study the techniques most frequently used by attackers, and promptly refine or add detection logic to our SIEM system to identify those technics. Specifically, in the update to the Kaspersky Unified Monitoring and Analysis Platform released in the second quarter of 2024, we supplemented and expanded the logic for detecting the technique of disabling/modifying a local firewall (Impair Defenses: Disable or Modify System Firewall T1562.004 in the MITRE classification), which ranks among the top tactics, techniques, and procedures (TTPs) used by attackers.

How attackers disable or modify a local firewall

The T1562.004 technique allows attackers to bypass defenses and gain the ability to connect to C2 servers over the network or enable an atypical application to have basic network access.

There are two common methods for modifying or disabling the host firewall: (i) using the netsh utility, or (ii) modifying the Windows registry settings. Here are examples of popular command lines used by attackers for these purposes:

Example of a registry key and value added by attackers, allowing incoming UDP traffic for the application C:Users<user>AppDataLocalTempserver.exe:

Another method attackers use to disable the Firewall is by stopping the mpssvc service. This is typically done with the net utility net stop mpssvc.

How our SIEM solution detects T1562.004

This is achieved using the new R240 rule; in particular, by detecting and correlating the following events:

• Attacker stopping the local firewall service to bypass its restrictions
• Attacker disabling or modifying the local firewall policy to bypass it (configuring or disabling the firewall via netsh.exe)
• Attacker changing local firewall rules through the registry to bypass its restrictions (modifying rules through the Windows registry)
• Attacker disabling the local firewall through the registry
• Attacker manipulating the local firewall by modifying its policies

With its latest update, the platform now offers more than 605 rules, including 474 containing direct detection logic. We’ve also refined 20 existing rules by fixing or adjusting their conditions.

Why we focus on the MITRE classification

MITRE ATT&CK for Enterprise serves as the de facto industry standard guideline for classifying and describing cyberattacks and intrusions, and is made up of 201 techniques, 424 sub-techniques, and thousands of procedures. Therefore, when deciding how to further develop our SIEM platform — the Kaspersky Unified Monitoring and Analysis Platform — we rely, among other things, on the MITRE classification.

As per our plan set out in a previous post, we’ve started labeling current rules in accordance with MITRE attack methods and tactics — aiming to expand the system’s functionality and reflect the level of protection against known threats. This is important because it allows us to structure the detection logic and ensure that the rules are comprehensive — with no “blind spots”. We also rely on MITRE when developing OOTB (out-of-the-box) content for our SIEM platform. Currently, our solution covers 309 MITRE ATT&CK techniques and sub-techniques.

Other additions and improvements to the SIEM system

In addition to the detection logic for T1562.004 mentioned above, we’ve added normalizers to the Kaspersky Unified Monitoring and Analysis Platform SIEM system to support the following event sources:

• [OOTB] Microsoft Products, [OOTB] Microsoft Products for Kaspersky Unified Monitoring and Analysis Platform 3, [OOTB] Microsoft Products via KES WIN: normalizers to process some events from the Security and System logs of the Microsoft Windows Server operating system. The [OOTB] Microsoft Products via KES WIN normalizer supports a limited number of audit event types transmitted to KUMA KES WIN 12.6 through syslog.
• [OOTB] Extreme Networks Summit Wireless Controller: a normalizer for certain audit events from the Extreme Networks Summit wireless controller (model: WM3700, firmware version: 5.5.5.0-018R).
• [OOTB] Kaspersky Security for MS Exchange SQL: a normalizer for Kaspersky Security for Exchange (KSE) version 9.0 system events stored in the database.
• [OOTB] TIONIX VDI file: a normalizer supporting the processing of some TIONIX VDI (version 2.8) system events stored in the tionix_lntmov.log file.
• [OOTB] SolarWinds Dameware MRC xml: a normalizer supporting the processing of some Dameware Mini Remote Control (MRC) version 7.5 system events stored in the Windows Application log. The normalizer processes events created by the “dwmrcs” provider.
• [OOTB] H3C Routers syslog: a normalizer for certain types of events coming from H3C (Huawei-3Com) SR6600 network devices (Comware 7 firmware) through syslog. The normalizer supports the “standard” event format (RFC 3164-compliant format).
• [OOTB] Cisco WLC syslog: a normalizer for certain types of events coming from Cisco WLC network devices (2500 Series Wireless Controllers, 5500 Series Wireless Controllers, 8500 Series Wireless Controllers, Flex 7500 Series Wireless Controllers) through syslog.
• [OOTB] Huawei iManager 2000 file: a normalizer supporting the processing of some of the Huawei iManager 2000 system events stored in clientlogsrpc and clientlogsdeployossDeployment files.

Our experts have also refined the following normalizers:

• For Microsoft products: the redesigned Windows normalizer is now publicly available.
• For the PT NAD system: a new normalizer has been developed for PT NAD versions 11.1, 11.0.
• For UNIX-like operating systems: additional event types are now supported.
• For Check Point: improvements to the normalizer supporting Check Point R81.
• For the Citrix NetScaler system: additional events from Citrix ADC 5550 — NS13.0 are now supported.
• For FreeIPA: the redesigned normalizer is now publicly available.

In total, we now support around 250 sources, and we keep expanding this list while improving the quality of each connector. The full list of supported event sources in the Kaspersky Unified Monitoring and Analysis Platform — version 3.2, can be found in the technical support section. Information on out-of-the-box correlation rules is also available there.