Using Azure Sentinel for daily Security Operations

Why correlation is key in providing cybersecurity

In handling cyberattacks, there is a distinction between alerts and incidents. An alert is a potentially malicious activity on the customer environment that stands on itself. An incident, on the other hand, is a security threat concerning multiple alerts. In our SOC, alerts are handled by first responders (tier 1), and for incidents, more senior security staff (tier 2) are consulted.

Since we implement a strict security baseline for our customers, an alert is only an Indicator of Compromise (IoC), which deserves investigation but doesn’t justify the additional effort in the response phase. This can thus be handled by the first responders in the SOC. A single alert could nevertheless lead to an incident, and Azure Sentinel Fusion helps in the detection of incidents and subsequently correlating these alerts into an incident. In case of an incident, tier 2 provides the response.

So why is the correlation of incidents important? Attackers often attempt to gain access via e-mail, after which they try to extend this access to endpoints (e.g., a laptop) or account details. Correlated events are thus an effective indicator that an attacker attempts to gain access to your systems.

At InSpark, we differentiate between four layers of security:

• Identity. We monitor the activities related to Azure Active Directory and Active Directory. Anomalies and malicious activities trigger alerts that get investigated.
• Endpoints. Having access to endpoints (devices) provides access to data and sensitive information. We set up devices in such a way that even a stolen or hacked device is still protected against unwanted access. Potentially unwanted software, malware, and possible threats on devices all trigger alerts.
• Apps & Data. Office 365 apps & data are monitored 24/7 for unusual activities, possible threats, policy violations, andanomalies from normal behavior.
• Platform. All Azure workloads are monitored for possible threats because hackers sometimes do not go for (personal) accounts, but they go for resources (workloads). Monitoring Azure workloads and securing the resources is of crucial importance to keep your environment safe.

Scenario

A real-world example of an attack

We are confronted on a daily basis with situations in which we see hackers trying their utmost to gain access to the systems of our customers. To illustrate the way we apply Azure Sentinel, we picked a scenario where different layers and different products/tooling worked together to keep our customers safe.

1. Phishing e-mail
   The situation started after a user within one of our customer’s tenants received a phishing e-mail. 
2. Malicious attachment
   1. The e-mail had a PDF file attached’, and within the PDF file, an image was showing that a file was ready to open with a malicious URL behind the image. 
   2. The URL behind the image directed the user to a lookalike Microsoft sign-in page. The phishing e-mail was recognized by Office 365 Advanced Threat Protection (Protect within Data/apps Protection) 
3. Delivered to Junk folder thanks to Office 365 Advanced Threat Protection
   1. The e-mail was delivered to the Junk folder as configured within Office 365 ATP.
      
      Good to mention that this user was not really known with the modern tooling and systems. User awareness and ignorance is the main cause of this compromise.
4. Ignorance #1 – handling e-mails from the Junk folder
   1. The user opened the e-mail from the Junk folder and opened the attachment (PDF file)
      1. Cloud SOC alert: Potential malicious URL was clicked (Detect within Data/apps Protection integrated with Endpoint Protection)
5. SmartScreen – layered protection
   1. The user clicked on the image within the PDF file, which took the user to a fake Microsoft sign-in page. But before landing on that website, the user received a warning from SmartScreen informing about an unsafe website (Protect within Endpoint Protection)
      
6. Ignorance #2 – ignoring warnings
   1. The user ignored the warning and proceeded to the website, giving the credentials away by trying to sign in. 
   2. This was the moment where the credentials became stolen, but no further harm was done yet. The hacker acted quickly, though.
7. Having credentials only is not enough
   1. The hacker continuously tried to sign in to the account with the credentials received earlier. Using different protocols (including legacy protocols to bypass MFA), the sign-ins all failed because of the MFA challenge + block legacy authentication policy (Protect within Identity Protection).
8. Ignorance #3 – approving access for the hacker
   1. Until the user was becoming tired of all the push notifications from Authenticator on the mobile phone, and the user approved not knowing that the user approved access for the hacker.
      1. -SOC alert: Sign-in from unusual location (Detect within Identity Protection)
9. Mail forward to hide presence (maintain access)
   1. After being able to successfully sign in to the account, the first action the hacker took was setting up an e-mail forwarding rule so the user wouldn’t receive any e-mails informing the user about the malicious activities (from either contacts or automated systems) 
      1. SOC alert: E-mail forwarding rule is set (Detect within Data/apps Protection)
10. Attempt for Lateral movement
    1. The same PDF file that the hacker used initially to mislead the user was uploaded to the user’s personal OneDrive. 
    2. From the users OneDrive, the file was shared with the whole organization. 
    3. All these e-mails were delivered because it was shared by OneDrive, some other users clicked on the URL within the e-mail, but no user proceeded to sign-in on the fake website and followed on the warning from SmartScreen on their devices. 

This all happened within an hour, and the compromise was mitigated within minutes after access to the account was possible. Even though the hacker did have access for a short period of time, there was no persistence, and the hacker was locked out after a password reset + revokes all active sessions. 

How Azure Sentinel helps with auto-remediation

After this situation and after setting up an RCA (Root Cause Analysis), we were able to make use of Azure Sentinel for automation in this case. Using functionality called Fusion, we were able to correlate these activities to receive a higher severity alert with 24/7 follow-up. Using Azure Sentinel Playbooks, we have implemented auto-remediation on this case: 

• Alert: Potential malicious URL was clicked
  • Followed by alert: Sign-in from an unusual location
    • Actions:
      • Revoke MFA sessions
      • Block AAD account
      • P1 incident for 24/7 follow up

We received from our customers: in this case, it’s better to be safe than sorry!

Conclusion

Are you interested in the possibilities of Azure Sentinel, you can contact us to inform you further about the capabilities of our award-winning Cloud Security Center. 

• Why Cloud Security Center?
  • You choose what you wish to protect, by means of four protection packs for Microsoft 365 and Azure
  • We continuously provide your cloud environment with the latest security features
  • You make maximum use of the AI-driven security services of Microsoft
  • We provide not only protection but also 24/7 follow-ups in the event of attacks.
  • You are proactively informed about and protected against attacks
  • Security is tailored to your security policy and secured through the Incident Response Plan
  • Transparent all-in fee per user/workload per month