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.
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.
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:
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.
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.
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
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.
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.