This is another feel-good, success story from today where the good guys won!

Dual Singapore Phish Contained

This morning, three employees of one of our clients were targeted with a clever phish that got all three to click. Two logged into a fake Adversary-in-the-Middle MFA Phish Site, instantly exposing session tokens to an attacker. These tokens are just long random looking strings of letters and numbers, but they satisfy the MFA requirement and can be used anywhere an MFA authenticated session is required, on behalf of the user.

The nature of these phishes are a lot like actual fishing: the lures are sent out and hours or days later the person behind the lures can come back to see what was harvested. Victims have a little time, but it’s not a guarantee and the trend is getting faster and faster before the attackers reach their goals.

This incident resulted in several detection events, that Wirespeed nicely grouped into two primary cases containing a handful of detections each. This is one of the detections from the first case:

Case Summary Trusting Microsoft's verdict is not always wise

You can see in this first case, we have noted that Microsoft “mitigated” a login and we have called it “benign.” This is the constant struggle with trusting detection vendors’ content. In this case, Microsoft “mitigates” the login by first acknowledging the username and password combination (1FA) is risky given something about the surrounding metadata, such as the IP address, ASN, geolocation (we don’t trust Microsoft’s geolocation data), user agent, time of day, etc. Microsoft “mitigates” this risky login by sending the user an MFA prompt that works fine through an adversary’s reverse proxy.

If you haven’t paid the “security tax” to Microsoft, purchasing the higher tiers of licensing, you often will not see the reason and detail behind a detection. In this case, we could see quite a bit. This is a detection from case 2:

Case Summary An additional alert, with threat intel enrichment identifying the MFA reverse proxy attack

This detection from Microsoft is unusual in that it comes with additional threat intelligence to confirm what we saw in several other detections: these were clearly an account takeover. We were already in the process of invoking ChatOps, which for this customer was emails to the victims to confirm the unusual details of the logins, which asked them if they just logged in from Singapore. Considering both of them were present in the US today, the answer is a very clear: NO!

This is the actual timeline from one of the cases:

The Actual (Redacted) Case Timeline for Case 1

Since this Wirespeed MDR tenant is setup to use ChatOps, but not to use automatic containment, this case was immediately escalated to a responsible party within the security administration for the organization. The security admin quickly agreed with our verdict and clicked the “contain” button on both cases, which told the EDR tool to isolate the endpoints from the network, disabled the user accounts in Microsoft Entra and their on-premise Active Directory, and kill all existing sessions, including the sessions stolen by the malicious domain and IP (which are visible in the top screenshots).

The attackers had access for approximately 27 minutes to one victim and 17 minutes to the other, both longer than our preference, but massively faster than industry average, especially considering the completeness of the response including informing the victims of the event and the actions taken. If auto-containment would have been enabled—instead of escalation to the responsible party—we would have contained both in just a few minutes. However, Wirespeed puts the customer in control with how far we automate, so we can build their trust of the platform and its decisions, all of which are transparently logged in the timeline above. This customer trusts the ChatOps and wants the control of the containment decisions, which we very much appreciate and respect.

Case Summary A view into our [data lake](/siem) for the event

Also, we haven’t formally announced its presence yet, but we soft launched our own super fast data lake built for hyperscale, running on the amazing analytical, column first data warehouse, ClickHouse. We’ll dig into more of its details another time, but this example shows our customer’s DNS requests, captured by [Cisco Umbrella}(https://umbrella.cisco.com), one of our many integrations, and stored natively in vendor-neutral OCSF format. We don’t plan to charge extra for our base storage retention duration, and we give customers the option to retain data by source for as long as they like at a very low per TB price, to satisfy any compliance issues they may have. All of our integrations are very easy to enable, most just a few clicks or a copy/paste of an API key, and the data is immediately ready for hunting, searching, and DFIR. On our case detailed view page, we expose a prebuilt query to show any event within the time window of the case, from any log source, that includes any OCSF observable item (assets such as user, host, IP, domain, hash, etc.).

This is great for situations like this, where we can know for certain when the first interactions with the attacker’s infrastructure took place and when it finished. Here is an example, exploded view of the very first DNS request from the client’s organization to the attacker’s infrastructure:

Case Summary A detailed view of the first DNS query to the malicious domain

#Bottom Line

This was a very fast overall response (although we will be making it faster!), with no material impact, and the customer was in control of the automation, ChatOps, and Containment decisions the entire time.

Want to learn more about how Wirespeed can make security painless for you? Contact us to start a FREE TRIAL today.