Suspicious Powershell Script Executed

Hello folks,

This is Jayanth K, and today we are going to investigate one more interesting security alert.

This alert was generated by LetsDefend and indicates a suspicious PowerShell execution on an employee’s host.

PowerShell is a legitimate Windows tool that is widely used by system administrators and security teams. However, attackers also commonly abuse PowerShell to execute commands, download payloads, perform reconnaissance, or carry out other malicious activities.

So, when a SOC analyst receives an alert related to suspicious PowerShell activity, it is important not to immediately assume that it is malicious. We need to investigate the available evidence and understand what actually happened.

Let’s start by looking at the alert details below.

Incident Responder Path — Lets Defend alert info

Let’s click the Investigate button and check the logs. In the Monitoring Channel, we can see the details of this alert.

Monitoring Tab alert info

Investigation

Based on the hint, our next step is to decode the PowerShell script and see what’s hiding inside it.

endpoint.ps1 script

The script contains Base64-encoded data, which is later decompressed and executed. This is a strong indication that we need to investigate the script further.

After decoding the content, we can confirm that the PowerShell script is malicious. So, let’s move forward and find out how the attacker got access to the machine.

Initial Access

The compromised machine is named Matt. Let’s first check whether any services are exposed to the internet.

Netstat screenshot

The investigation shows that RDP is exposed to the internet, so our next step is to check the RDP login activity.

The PowerShell script was executed using the Administrator account. When we check the RDP logs, we find a successful login from 3.16.42.241 at 12:12 on 05.09.2021.

successful RDP login

Now let’s check the failed login attempts before the successful login. We can see multiple failed attempts from the same IP address.

This tells us that the attacker gained access through an RDP brute-force attack.

What Did the Attacker Do?

Now that we know how the attacker got in, let’s follow their activity on the machine.

We start with Sysmon Event ID 11, which helps us identify files created on the system.

We can see four important files:

• new1.bat

• Advanced_Port_Scanner_2.5.3869.exe

• nc111nt.zip

• endpoint.ps1

These files give us a starting point for building the attack timeline.

Next, let’s check Sysmon Event ID 1 to understand which processes were executed.

The attacker executed new1.bat using cmd.exe. Since the batch file was deleted, we cannot directly view its contents, so we follow its child processes instead.

The child processes show that the attacker was collecting information about the system, including applications, processes, and active network connections.

The attacker also searched for domain names on the system, potentially looking for files containing sensitive information.

Internal Network Scanning

Next, we can see that the attacker executed Advanced Port Scanner.

We can then use Sysmon Event ID 3 to identify network activity. The logs show that the attacker scanned ports on the internal network.

This suggests the attacker was looking for other systems that could potentially be targeted.

Finally, at 12:43, the attacker executed endpoint.ps1 — the PowerShell script that triggered our original alert.

Data Exfiltration

Now let’s check whether the attacker actually stole any data.

The investigation shows that the attacker used Netcat to transfer data from the compromised machine.

The connection was made to 3.16.42.144 on port 4444.

Let’s check the endpoint command history to understand what was transferred.

The command history shows that the attacker exfiltrated an SQL database backup named **user-db-backup.sql**.

showing user-db-backup.sql.

Containment

At this point, we have confirmed that the machine was compromised and data was exfiltrated.

The next step is to isolate the affected machine Matt from the network.

This helps cut off the attacker’s access and prevents further movement through the network.

Eradication

After containment, we need to remove the attacker’s access.

• Change the Administrator account password.
• Remove the Administrator account from the Remote Desktop Users group if it is not required.
• Remove the files downloaded by the attacker.

MITRE Mapping

Cyber Kill Chain

Artifacts

Lessons Learned

This investigation gives us a few important takeaways:

• Avoid exposing RDP directly to the internet.
• If RDP is required, restrict access to trusted IP addresses.
• Use strong, unique passwords.
• Remove unnecessary users from the Remote Desktop Users group.

Final Takeaway

What started as a suspicious PowerShell alert revealed a much bigger attack.

The attacker gained access through RDP brute force, performed reconnaissance and internal scanning, executed a malicious PowerShell script, and finally exfiltrated an SQL database backup.

The key lesson: don’t stop at the alert. Follow the logs and build the complete attack story.

Thanks for reading! If you found this investigation useful, feel free to share your thoughts or connect with me for more SOC and cybersecurity investigations.

— Jayanth K