Hack Smarter - Silent Corridor (Blue Team)

One objective: determine whether GREY VEIL group has been inside Haldric’s network. If they have, we need to know what they accessed, what they took, and when it started. If they have not, we document what we checked and why we are confident.

Multiple log sources were provided for this investigation: VPN Gateway (remote access logs), WS-ENG04 (Engineering workstation), SRV-DC01 (Domain controller), and SRV-FILES02 (File server).

● Initial Access

I began by checking what users were connected to the VPN and see if there were any anomalies over there. So, I used the vpn index to filter the corresponding logs, then looked in the user list. I obtained 3 usernames: s.brandt, m.richter and k.weber.

Judging by the log count for each user, there wasn’t a really clear indicator of abnormal activity for any of them, just a higher number of entries assigned to s.brandt.

I continued by analyzing them separately. The first one was s.brandt, since he was the one with the highest count. I ran the following query in Splunk:

index=vpn user="s.brandt"
| table _time, user, group, remip, msg, tunneltype, tunnelid, action
| sort +_time

I investigated the results and looked for unusual patterns. The first stop was on 2026-02-19/20.

If all the previous logins were done from the same IP, 88.153.72.14, I got a different one now, 185.220.101.34. I could consider it just a possible different location for that day.

But the event sequence is suspicious: VPN login failed for invalid credentials - VPN login succeed - tunnel established - tunnel shutdown. One could think of a simple login typo which led to a failed login. And it’s true. However, look at the time between the failed login and the successful one, almost 2 hours and a half. No one needs that amount of time to fix a typo.

Moreover, the most alerting signal was the time when the login was done. If previous activity was recorded during the day, now the connection was established during the night, at 2 AM. Uncommon sequence, to be honest.

I dug further and observed other strange connections during the next days.

On 2026-02-23, I saw another connection from the IP encountered earlier, 185.220.101.34. Again, connected after midnight.

Two days later, on 2026-02-25, a new strange connection during the night was detected, this time from a different IP: 91.234.33.126.

The odd connections continued and another distinct IP popped up, 45.153.160.88

These weren’t the final unusual connections, because I discovered some more. Here are all the abnormal ones, by days:

2026-02-20 -> 185.220.101.34
2026-02-23 -> 185.220.101.34
2026-02-25 -> 91.234.33.126
2026-02-28 -> 91.234.33.126
2026-03-02 -> 45.153.160.88
2026-03-04 -> 45.153.160.88
2026-03-05 -> 185.220.101.34

As a comment, no more than 2 consecutive connections were established from the same IP. This could have been a measure to avoid suspicions or having the IP blacklisted.

I moved to m.richter, but I didn’t find anything doubtful. I applied the same Splunk query as before, just changing the user.

index=vpn user="m.richter" 
| table _time, user, group, remip, msg, tunneltype, tunnelid, action
| sort +_time

Only one failed login was noticed, but the successful login which came next was done after only 1 minute. Also, all the connections were done from the same remote IP: 88.153.72.201. If we look at the IP which appears most in the case of s.brandt, 88.153.72.14, we can recognize they are both part of the same subnet.

Finally, for k.weber, no strange events were encountered. All connections were done from the same IP, none of them during the night. The only observation could be that he had a different IP, 79.213.108.55, but since he’s part of the Management-VPN group and the other 2 users are members of IT-VPN and Engineering-VPN, it is not uncommon for management to have a different subnet from the others.

Now, let’s answer the questions for this section.

Q01. Profile every account in the VPN logs. One doesn’t fit. Who?
s.brandt - he was the one for whom the strange patterns were discovered

Q02. Could be a busy employee, could be someone else. Prove it. What IP first failed to authenticate as this user?
185.220.101.34

Q03. Scope the full picture for this account across the window. How many unique source IPs did it authenticate from?
4 - the legit IP, plus the other 3 suspect ones

Q04. Not all of them belong. Which ones look wrong? List in ascending order, comma-separated.
45.153.160.88, 91.234.33.126, 185.220.101.34

Q05. VPN logs show where they came from, not where they went. Check the endpoint side. What internal host did the attacker access via RDP?
WS-ENG04

To get this answer, I adjusted a bit the query I ran the first time for s.brandt. I filtered by action and added dst_host field to the output.

index=vpn user="s.brandt" action="ssl-login-succ"
| table _time, user, group, dst_host, remip, msg, tunneltype, tunnelid, action
| sort +_time

● Discovery

I continued by using a different index for my Splunk investigation, the one corresponding to the host where the attacker connected: wseng04.

I started by looking for spawned processes on this workstation, assigned to s.brandt user. First, I checked the Sysmon logs.

index=wseng04 user="s.brandt" EventCode=1 
| table _time, CommandLine, ParentCommandLine, Image, ParentImage, CurrentDirectory, ProcessId, ParentProcessId
| sort +_time

Based on the first entries of the output, I noticed the attacker performed some recon activity.

2026-02-20 -> running systeminfo to get details about the workstation's system
2026-02-23 -> looking for accounts with high privileges

I also verified the same thing by querying the Windows Event logs. This time, I discovered some extra interesting commands executed by the attacker.

index=wseng04 EventCode=4688 user="s.brandt"
| table _time, Process_Command_Line, New_Process_Name, Creator_Process_Name
| sort +_time

We can see the processes identified earlier, but also some new ones.

Now, let’s answer the questions for this section.

Q06. Find the parent process that spawned the recon activity on the beachhead.

cmd.exe - the recon activity was done via the systeminfo command, we can check the parent image of this process and observe the full path of the cmd.exe file. The executed query returns the ProcessId and ParentProcessId fields (not visible in the screenshot, unfortunately) and further searches can be done using those IDs.

Q07. Among the discovery commands, one targets accounts with full domain control. Submit it exactly as logged.

net group "Domain Admins" /dom - the accounts with high privileges the attacker is looking for are in the “Domain Admins” group.

Q08. Same window. They mapped the host’s storage with a LOLBin. Submit the full command as logged.

wmic logicaldisk get caption,filesystem,freespace,size,volumename - the attacker used wmic as LOLBin (you can check the full list of living off the land binaries here). In case the answer isn’t validated, replace filesystem with fileststem, since the attacker had a typo in the initial command he executed.

● Credential Access

I went on with the process analysis and looked for what other ones were spawned by the attacker during the next days. I kept the output from the Windows Event logs.

Something that caught my attention was the execution of the following command: wevtutil cl Security. So, the Security Windows Event log was cleared. This was run on 2026-02-23, around noon. Not during the night, like the other ones. Of course, this could also be a legit activity of an admin, but I really doubt it in this case. Maybe the attacker did it during active hours to blend in.

But the days of 2026-02-26 and 2026-02-27 revealed clear evidence of the attacker hunting for credentials.

What can we conclude from this? The malicious actor ran the following commands:

tasklist /fi "imagename eq lsass.exe" - he looked for running processes whose image is lsass.exe, something responsible for security-related operations; he was most probably looking for the associated process ID

rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump 628 C:\Windows\Temp\sys_diag.dmp full - this basically uses rundll32.exe (another LOLBin!) to run MiniDump exported function from the .dll, with the purpose of creating a full memory dump for the process having ID 628 and save it in sys_diag.dmp file; the name was chosen on purpose, to look like a diagnosis file from Windows

I searched for files created on WS-ENG04 based on this process ID and got the confirmation I was right.

index="wseng04"  EventCode=11 ProcessId=628
| table _time, User, Image, TargetFilename, ProcessId
| sort +_time

reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" - the registry was checked for already existing connections which might help him pivot

The credential search didn’t end here, because the next day, he looked for stored credentials and tried to dump a backup of the SAM file.

Now, let’s answer the questions for this section.

Q09. Before going after credential material, the attacker confirmed their target was live. Submit the full command they ran.

tasklist /fi "imagename eq lsass.exe"

Q10. They went after the target. Some log sources caught it, others didn’t. Did Defender intervene?

No - I queried Splunk for Microsoft Defender Antivirus service engine, MsMpEng.exe, but didn’t find any entries related to our attacker’s activity.

index=wseng04 *MsMpEng.exe*
| table _time, user, process_name, process_path, file_path, process_id
| sort +_time

Q11. Not everything worth stealing sits in memory. Some lives in the registry. Which key did they touch?

HKCU\Software\SimonTatham\PuTTY\Sessions - we know he checked the registry for connections after dumping the lsass.exe memory process

Q12. Same theme. They asked Windows itself which credentials were saved on the host. Submit the full command.

cmdkey /list

● Lateral Movement

Two days later, still during the night, the attacker performed some activities on the network, with a new set of credentials he obtained. Again, the output of the query for processes on WS-ENG04 workstation helped.

index=wseng04 EventCode=4688 user="s.brandt"
| table _time, Process_Command_Line, New_Process_Name, Creator_Process_Name
| sort +_time

I noticed he used m.richter:Haldric2025SecIT to map the C drive from SRV-DC01 , the domain controller. Next, he listed the processes on the DC with the help of the wmic tool. Afterwards, he created the McAfee_Logs directory in C:\Windows\Temp location. He chose this name to make it seem legit and the path was one where he could write. Over there, he created a backup of the AD database files, using the following command: ntdsutil "ac i ntds" ifm "create full C:\Windows\Temp\McAfee_Logs" .

Let’s have a look at what I found when I investigated what files were created on SRV-DC01 and involved user m.richter :

index="srvdc01" *m.richter* EventCode=11
| table _time, User, Image, TargetFilename, ProcessId
| sort +_time

I discovered the registry hives for SYSTEM and SECURITY, as well as the ntds output file. There is a one-hour difference between the timestamps for WS-ENG04 and SRV-DC01, but this might be caused by a different timezone configuration.

After this, he used netsh to create port forwarding to route the traffic from the local machine, on port 8443, to SRV-DC01, on port 445.

Next, I observed he repeated the mapping process for SRV-FILES02. Ten minutes later, I noted he deleted a couple of files and a folder, then cleared the Security Windows Event log on both servers.

I took a look through the processes created on SRV-DC01, related to m.richter. I expected to see pretty much the same thing, but I got another thing.

index="srvdc01" *m.richter* EventCode=1
| table _time, CurrentDirectory, Image, CommandLine, ParentImage, ParentCommandLine, ProcessId, ParentProcessId, CurrentDirectory
| sort +_time

There was created a shadow copy for the C drive, using vssadmin. Also, I noticed another port forwarding was done between the local machine and 10.1.36.210 IP.

Now, let’s answer the questions for this section.

Q13. The attacker reached out from the beachhead and established a remote connection. Submit the full command.

net use \\SRV-DC01\C$ /user:m.richter Haldric2025SecIT - the first command he used in pivoting

Q14. Look at the credentials passed in that connection. Which account is it?

m.richter - this is visible in the credentials passed as parameters to the previous command

Q15. Once authenticated, they needed a way to run commands on the remote side. What did they use?

wmic.exe - after mapping the C drive, the attacker started running commands remotely using this tool; check the executions which follow the mapping process

Q16. They set up a working directory disguised as a legitimate folder. Where?

C:\Windows\Temp\McAfee_Logs - verify the second command executed via wmic.exe on SRV-DC01

Q17. Map the spread. Which hosts did they touch beyond the beachhead? Alphabetical, comma-separated.

srv-dc01, srv-files02 - look through the processes spawned by m.richter on WS-ENG04 for mappings of C drives

Q18. On the higher-value target, they used a native utility to copy something they shouldn’t. What did they call?

ntdsutil.exe - available in the AD database files dump command

Q19. What file were they after?

ntds.dit - look through the files created on SRV-DC01 by m.richter

Q20. Look at the parent process. What spawned the extraction command on the remote host?

wmiprvse.exe - this is a bit weird, because it’s quite vague. On SRV-DC01, this is the parent process for cmd.exe, not for the actual ntdsutil.exe process. When I checked the process on SRV-DC01 based on Windows Event code 4688, the parent process for ntdsutil.exe was actually cmd.exe. Maybe it’s just an interpretation thing. I could see wmiprvse.exe being the parent process for cmd.exe, the one through which the deletion of the McAfee_Logs directory and the cleanup of Security Event logs was performed.

Q21. Did the attacker open any direct RDP sessions beyond the beachhead during the window? If yes, list the hosts alphabetical, comma-separated. If no, answer ‘none’.

srv-dc01, srv-files02 - check the remote logins (successful or failed) associated with m.richter user on these 2 machines by using the queries:

index="srvfiles02" EventCode=4624 OR EventCode=4625 Logon_Type=10 *m.richter*
index="srvdc01" EventCode=4624 OR EventCode=4625 Logon_Type=10 *m.richter*

One entry will be returned for each query and they both have the timestamp of 2026-02-28, during night hours, which is correlated to the previously found activity.

● Persistence

I searched through logs from WS-ENG04 workstation for signs of scheduled tasks or service creation, but didn’t encounter anything. Queries like index=wseng04 *sc.exe* or index=wseng04 *schtasks.exe* didn’t return any entry.

Next, I wanted to see if there was anything interesting in the registry, so I verified the results for this.

index=wseng04 *HKLM* EventCode=12 OR EventCode=13 OR EventCode=14
| table _time, user, action, registry_hive, registry_path, registry_key_name, registry_value_name, registry_value_data, process_name, process_path, process_id, object_path 
| sort +_time

The only relevant log was the one associated with port forwarding done by the attacker.

Did the same thing on SRV-DC01 and SRV-FILES02, found only the other port forwarding done on the domain controller.

So far, the previously discovered port forwarding technique fits in the persistence category.

Now, let’s answer the questions for this section.

Q22. They set up a way back in that survives reboots and leaves no file on disk. Submit the full command.

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8443 connectport=445 connectaddress=SRV-DC01.haldric.local - this is the actual port forwarding done on WS-ENG04

Q23. That command wrote itself into the registry. One keyword in the key path names the technique.

portproxy

Q24. Did they do the same anywhere else? If yes, name the host. If not, answer ‘none’.

srv-dc01 - when I checked the 2 servers, I found the same thing on this one

● Collection & Exfiltration

We already saw how the attacker established connections to the other 2 servers and executed commands remotely on them. I wanted to see what processes were spawned on SRV-FILES02.

index="srvfiles02" *m.richter* EventCode=4688
| table _time, src_user, process, parent_process, process_name, parent_process_name, process_path, parent_process_path, process_id, parent_process_id
| sort +_time

There are 3 commands executed during the night, on 2026-02-28, under the account of m.richter. First, he makes use of a local utility, makecab.exe, to create an archive of a document, nav_integration_spec_v4.2.docx, and place it in C:\Windows\Temp location. Next, he operates with PowerShell and builds a .zip file for C:\Engineering\Avionics\A400M_NavSys, naming it win_update_kb5034.zip, another name he chooses in his attempt to make it look legit. Finally, he encodes the content into a .b64 file with the help of certutil.exe (again, a LOLBIN!).

Apart from that, the only interesting thing I discovered is the set of processes where the attacker tried to clean his traces.

When I analyzed the files created on SRV-FILES02, I only got the confirmation of what I concluded after looking at processes.

index="srvfiles02" *m.richter* EventCode=11
| table _time, User, Image, TargetFilename, ProcessId
| sort +_time

I looked through the network connection logs, on all 3 machines, but didn’t find anything relevant.

index="wseng04" EventCode=3
| table _time, User, SourceIp, DestinationIp, SourcePort, DestinationPort, Image, ProcessId
| sort +_time

I continued by checking the DNS queries logs for all 3 machines. I found something on WS-ENG04.

index="wseng04" EventCode=22
| table _time, user, src, process_name, process_exec, query, answer
| sort +_time

There was a DNS query made during the night of 2026-03-04 to cds-telemetry.cloud-endpoint.net address.

Based on this, I looked on WS-ENG04 for processes involving PowerShell.

index="wseng04" EventCode=1 *powershell.exe*
| table _time, User, ParentUser, CommandLine, ParentCommandLine, Image, ParentImage
| sort +_time

We can see how the attacker exfiltrated the content of the .b64 file via web POST request at the address mentioned above.

Finally, I looked again for the processes created on WS-ENG04 by s.brandt.

index="wseng04" EventCode=4688 *s.brandt*
| table _time, src_user, process, parent_process, process_name, parent_process_name, process_path, parent_process_path, process_id, parent_process_id
| sort +_time

It looks like he came back and used certutil.exe to download data from the address where he exfiltrated the previous file. He wrote the response content to the response.txt file.

Now, let’s answer the questions for this section.

Q25. Find the directory the attacker went after. Submit the full path.

C:\Engineering\Avionics\A400M_NavSys\ - check when the attacker created the .zip file

Q26. Their first packaging attempt used a native utility. Submit its name.

makecab - the first command he used in the collection process

Q27. They switched approach for the rest. What did they use to package it?

Compress-Archive - this was used when he created the .zip file

Q28. The archive didn’t leave the host as-is. They ran it through a native utility first. Submit the utility and the switch.

certutil -encode - he used this after he built the .zip file

Q29. Find the outbound transfer. What pushed the data out?

Invoke-WebRequest - look at the exfiltration command ran in PowerShell, where the attacker made the POST request

Q30. Where did it go?

cdn-telemetry.cloud-endpoint.net - same as above

Q31. Later in the window, the attacker returned and probed outbound connectivity. Which native binary did they abuse?

certutil - examine when he saved the response of the web request in response.txt file

● Defense Evasion

We saw from previous steps that the attacker started to remove the traces of his activity after he managed to exfiltrate the data. I went back to the logs for the processes of s.brandt on WS-ENG04, to search for cleanup activity.

index="wseng04" EventCode=4688 earliest="02/23/2026:00:00:00" latest="02/23/2026:23:59:59" *s.brandt*
| table _time, src_user, process, parent_process, process_name, parent_process_name, process_path, parent_process_path, process_id, parent_process_id
| sort +_time

The Security Windows Event log on WS-ENG04 was initially cleaned on 2026-02-23. This happened before the actual data collection and during daytime. It could have been a legit activity, although the VPN breach occurred before and this might have been run by the attacker.

But the most relevant actions took place on 2026-02-28. The same output revealed what was done in terms of tidying up.

First, the artefacts he collected from SRV-FILES02 and exfiltrated were deleted. Then, he removed the McAfee_Logs directory from SRV-DC01. In the end, he cleared the Security Windows Event Log from both servers.

I examined the logs from the 2 servers and found the same stuff. I used m.richter in my search this time, because this is the account through which the commands were executed.

index="srvdc01" EventCode=4688 earliest="02/23/2026:00:00:00" latest="03/04/2026:23:59:59" *m.richter*
| table _time, src_user, process, parent_process, process_name, parent_process_name, process_path, parent_process_path, process_id, parent_process_id
| sort +_time

index="srvfiles02" EventCode=4688 earliest="02/23/2026:00:00:00" latest="03/04/2026:23:59:59" *m.richter*
| table _time, src_user, process, parent_process, process_name, parent_process_name, process_path, parent_process_path, process_id, parent_process_id
| sort +_time

Now, let’s answer the questions for this section.

Q32. Logs got cleared on the beachhead. Whose account did it, and when?

s.brandt, 2026-02-23 10:54:06 - this one is very tricky, because the initial Event Log cleanup was done at 12:08:32 . Honestly, I tested a lot of options here, but none of them were right. I thought I might have done something wrong, because I didn’t manage to get the correct answer. Finally, I actually wrote to Tyler Ramsbey directly, showed him my analysis and asked if I did something wrong. He sent me the answer and mentioned this might require a review from the lab owner because there could have been a mistake.

Q33. They didn’t stop at one box. How many hosts had logs cleared during the window?

3 - we have WS-ENG04, SRV-DC01 and SRV-FILES02

Q34. Something they missed. One log source stayed intact across every host. What was it?

Sysmon - the attacker cleared only the Security log from Windows Event, but not the one corresponding to Sysmon

Q35. K. Hofmann, CISO: “I need to brief the board in 30 minutes. Was IP stolen from the A400M_NavSys directory? Give me a confidence level.”

HIGH - it took me a while to realize that IP meant Intellectual Property. We know the content of that directory was compressed using PowerShell and transferred via a web POST request

Q36. Before they left the higher-value target, they tidied up. What directory did they remove?

C:\Windows\Temp\McAfee_Logs - this is the directory he removed from the domain controller

● Correlation

In this section, I will go straight to the questions.

Q37. VPN sessions don’t always end in immediate action. For the first interactive RDP logon on the beachhead by the compromised account, identify the anomalous VPN tunnel-up that preceded it. Submit the external attacker IP from that tunnel-up and the LogonId of the RDP event.

185.220.101.34, 0xA2409D - we know s.brandt was the compromised user. I checked the remote logins and noticed the first one was on 2026–02–24

index="wseng04" EventCode=4624 Logon_Type=10 *s.brandt*
| table _time, user, Logon_ID, status, src, src_ip, process, name
| sort +_time

Then, I investigated the VPN logins for the same user, which took place before this date.

index="vpn" "*s.brandt*"
| table _time, user, group, remip, dst_host, msg, reason, devname, tunneltype, tunnelid, action
| sort +_time

During unusual hours, VPN connection activity is registered from a suspicious IP.

Q38. Write a Splunk search against process command lines that would detect the technique used in this hunt regardless of which listenport or connectaddress is chosen. Submit the three durable keywords your search would require, space-separated, any order.

portproxy add v4tov4 - we know the completed command was: netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8443 connectport=445 connectaddress=SRV-DC01.haldric.local. Since ports and addresses can be different, we remove those parameters. Then, netsh is the tool name and the interface part tells netsh that we want to work with the interface. This leaves “portproxy add v4tov4”.

Hack Smarter - Silent Corridor (Blue Team) was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.