<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: Tapped on the Shoulder

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

We recently made an interesting discovery during a proof of concept with a large university in the United States. This university has a small security operations center, mostly run by volunteer cybersecurity students. They monitor a vast network across the university’s campus accessed by both university-owned and student-owned devices.

With a high number of unmanaged personal devices operating on public networks, endpoint detection is virtually impossible, leaving the university with a significant lack of visibility that makes them vulnerable to malicious traffic originating from those devices.

While performing a proof of concept with the Stamus Security Platform, the university was alerted by the Multi-State Information Sharing and Analysis Center (MS-ISAC) — a US government agency — to a known suspicious IP that was communicating with an IP registered to the school.

The university engaged with a representative from Stamus Networks to use SSP and investigate further.

What we found and how we found it

Armed with the IP information provided by the MS-ISAC, we began a hunt to find the suspicious traffic. First, we filtered through the last 7 days of traffic using the source and destination IP addresses provided by MS-ISAC, which returned a single “sighting”. In the Stamus Security Platform, sightings are another term for previously unseen communications. This feature enables us to pinpoint the first time a piece of metadata (such as domain, TLS certificate, HTTP host/user agent/server, JA3, JA3S, file checksum, filename etc) has been seen in the enterprise.

Using SSP’s conditional PCAP storage, we downloaded the PCAP and imported it into Wireshark, then followed the TCP stream for the session.

We then copied the session payload and input that into CyberChef to decode, where we then discovered evidence of a likely crypto wallet stealer malware. This inference was based on the names of popular crypto wallets found in the decoded payload (see image below). Further investigation confirmed our suspicions and revealed a malware called ViperSoftX, a known information stealer and random access trojan (RAT) commonly used to steal crypto wallet addresses and password information stored in browsers and password managers.

How it happened

This type of thing isn’t actually uncommon for a large university like this. With thousands of students, there are a lot of unmanaged devices accessing public networks. Between students’ cell phones, computers, gaming devices, smart TVs, and other connected devices, it becomes incredibly difficult, if not impossible, to realistically maintain visibility into an individual device. In this scenario, it wasn’t even possible to determine which particular student the malware gained access through. This is because the university was only monitoring internet traffic during the proof of concept, with no probe on the inside of any routers to see specific traffic to internal IP addresses.

Even if they could determine which student was targeted, the university doesn’t own the student’s machine, and therefore cannot determine whether the student was affected. Nor could they go onto the machine to purge the software as they would on one of their university-owned machines. The only action they could take in this scenario was to block the destination IP traffic to prevent it from accessing the network again.

An alternate reality

While the university was first cued in to the suspicious IP address by MS-ISAC, they would likely have identified it on their own. This could have been done in two ways, the first being the “Sightings” feature, and the second through a Declaration of Compromise™.

As we mentioned before, a sighting in the Stamus Security Platform is any previously unseen or novel communication happening on the network. It is not uncommon for many organizations, especially those with public networks being accessed by uncontrolled devices, to have a large number of sightings every day. Not all sightings are inherently bad, and the majority of them are normal, non-malicious traffic. There are instances however, such as this one, where a sighting can lead to the discovery of a malicious presence on the network. Had the university reviewed their sightings, they likely would have found their way to the same conclusion eventually.

The second way they would have identified this threat is through Declarations of Compromise™. A Declaration of Compromise (often referred to as a DoC) is a high-confidence and high-priority security event generated by Stamus Security Platform, signaling a “serious and imminent” threat on an asset. When SSP generates a DoC, it creates a data record that contains a substantial amount of meta data and associated artifacts that help the analyst understand exactly why it triggered and provide evidence for any investigation that may follow.

During the proof of concept, the university actually had a DoC issued for this exact traffic. They just hadn’t checked it yet.

Stamus Security Platform includes DoC coverage for hundreds of threats across 23 different threat families. This threat coverage is updated daily by the team at Stamus Labs, and an email is sent to customers detailing newly covered threats and detection methods in a weekly Threat Detection Update email. SSP users can see a list and descriptions of the currently covered threats and threat families on the “Stamus Threat Research” screen, accessed from the “Coverage” link on the SSP left-hand menu.

Why this matters

Despite not being able to do much in the way of response, the fact that the university was able to identify the threat at all is impressive in its own right. This scenario is an excellent example of how network detection and response (NDR) can augment endpoint detection and response (EDR) in a large environment with a diverse network set-up. Without NDR, this particular threat would have continued to go completely unnoticed until it spread to a university-controlled endpoint.

The most effective threat detection and response strategy involves monitoring both the network and the endpoints to minimize gaps in visibility. To learn more about how NDR can compliment your existing security tools, read our white paper “EDR, NDR, and XDR: Exploring Three Approaches to Threat Detection and Response”.

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.

Phil Owens

Phil is the vice president of customer solutions at Stamus Networks. He has over 25 years experience in IT, networking, and cyber security. As a Systems Engineer he has been a trusted advisor to several fortune 500 companies. As a product manager he has created successful cyber security software products. Prior to joining Stamus Networks he held positions at RSA Security, AT&T and IBM. Phil is also proud to have served in the United States Air Force. Phil resides in Florida, USA.

Schedule a Demo of Stamus Security Platform

REQUEST A DEMO

Related posts

Introducing Clear NDR™

At Stamus Networks, we have always been driven by a commitment to openness, transparency, and...

Uncovered: SSP Identifies Massive Breach During Evaluation

For many organizations considering Network Detection and Response (NDR), one of the most valuable...