08. 11. 2024 Luca Zeni Blue Team, SEC4U, Threat Intelligence

SATAYO And SOC: Exchanging Data For Better Insight

In this post, we’ll explore the synergy between a Cyber Threat Intelligence (CTI) platform and a traditional Security Operations Center (SOC) service. For those interested in the topic, I recommend reading my previous article, where I demonstrated a concrete example of integration between our SIEM and SATAYO, the CTI platform we use in our SOC. However, this time we’ll shift the focus from integration to the real-world results of this collaboration. We’ll dive into a case that shows how this synergy can provide a more comprehensive understanding of threats, by analyzing them from two distinct and complementary perspectives.

The threat that will be analyzed involves an unauthorized access attempt to a Microsoft 365 account using compromised corporate credentials. The goal is to understand the causes of this incident and the effects it had. To do this, we’ll look at the incident from two separate perspectives: that of the SIEM and the CTI platform.

The SIEM Side

Date: Saturday, July 20, 2024, 00:37 AM
A series of alerts appeared on the SIEM, indicating a possible brute-force attack. Specifically, the rule “Attempts to Brute Force a Microsoft 365 User Account” was triggered. This rule activates when multiple failed login attempts are recorded for a particular user. The SIEM query that was triggered by this event is similar to the following:

event.dataset:o365.audit and event.provider:(AzureActiveDirectory or Exchange) and event.category:authentication and event.action:(UserLoginFailed or PasswordLogonInitialAuthUsingPassword) and not o365.audit.LogonError:(UserAccountNotFound or EntitlementGrantsNotFound or UserStrongAuthEnrollmentRequired or UserStrongAuthClientAuthNRequired or InvalidReplyTo) and event.outcome:failure

Through further analysis, important details emerged. The login attempts originated from multiple IP addresses, all flagged as malicious due to prior brute-force activity. None of these IPs were part of the corporate network, and none had been previously used to log in. Additionally, the unusual time of the login strongly suggested that a real-time attempt at unauthorized access was in progress, not a false positive.

The failed login attempts returned error code 50131 (ConditionalAccessFailed), which means that a conditional access policy set by the Azure AD administrator had blocked the login. There are several parameters for these policies, such as device type, authentication factors, and geographical location.We couldn’t understand which of these parameters were missing, but the important thing is that the accesses were blocked.

This analysis gave us critical insight into an attack in progress, showing an intermediate stage where compromised credentials were being used. However, the origin of these credentials remained unknown until nearly a month later…

The CTI Side

Date: Wednesday, August 14, 2024
On August 14th, our SATAYO Cyber Threat Intelligence platform detected suspicious company credentials being sold in two different underground marketplaces specializing in logs and access credentials obtained via malware stealers. The analysis of these logs showed an infection by not just one but two infostealer malware: Vidar and RedLine.

The compromised device was a private laptop, not part of the corporate environment. This machine had been infected by the malware, which exfiltrated various types of data, including credentials saved on the device. Among the stolen credentials were the login details for various Microsoft services, including the email account targeted in the brute-force attack a month earlier. What had initially been classified as a brute-force attempt turned out to be an unauthorized access attempt using compromised credentials from this infected device.

With this information, we were able to explain the earlier attack: the credentials used in the Microsoft 365 access attempt had been stolen through malware on the compromised laptop.

While the source of the credential theft was identified, the origin of the malware infection itself remained unclear. To investigate further, log files such as cookies, browser history, and the victim’s online activity were analyzed. Based on available data, two plausible hypotheses emerged:

Downloading of unofficial software (cracked software) – The victim may have downloaded executable files from untrustworthy sources
Unverified ZIP file downloads (via torrenting) – The victim’s download history showed several ZIP files from free-resource or file-sharing platforms, potentially leading to the malware infection

While we can’t say with absolute certainty how the malware was introduced, these are the most likely scenarios based on our analysis.

Conclusion

This case demonstrates the benefits of combining different approaches. Each solution, whether it’s the SIEM or a CTI platform, has its own strengths and limitations. A SIEM provides excellent monitoring and detection capabilities for events as they happen, but may not always reveal the origins of an attack. On the other hand, a CTI platform excels at identifying the source of a threat and providing proactive intelligence but may struggle to detect exploitation in real-time.

By combining the two, we were able to form a complete picture of the attack, allowing us not only to detect unauthorized access attempts but to trace them back to their origin as well. This synergy allows organizations to enhance security posture, providing broader visibility and more effective monitoring of potential attack surfaces.

These Solutions are Engineered by Humans

Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find cybersecurity issues interesting, maybe you could start in a cybersecurity or similar position here at Würth Phoenix.