# Intrusion Detection With Splunk (Real-world Scenario)

## Introduction

The `Windows Event Logs & Finding Evil` module familiarized us with log exploration on a single machine to pinpoint malicious activity. Now, we're stepping up our game. We'll be conducting similar investigations, but on a much larger scale, across numerous machines to uncover irregular activities within the entire network instead of just one device. Our tools will still include Windows Event logs, but the scope of our work will broaden significantly, demanding careful scrutiny of a larger pool of information, and identifying and discarding false positives whenever possible.

```
index="main" earliest=0
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FGk3myVSsSlOF8nlYm2ur%2F1.webp?alt=media&#x26;token=c5ec98ab-3268-440f-8f35-c0088a32152c" alt=""><figcaption></figcaption></figure>

## Searching Effectively

Let's dive into our data. Our first objective is to see what we can identify within the Sysmon data. We'll start by listing all our sourcetypes to approach this as an unknown environment from scratch. Run the following query to observe the possible sourcetypes (the screenshot may contain a WinEventLog sourcetype that you will not have).

```shell-session
index="main" | stats count by sourcetype
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FEGX29YcqaMMif67IMemM%2F2.png?alt=media&#x26;token=5e9ef7eb-e708-4b1d-a4b2-bd0078a7effb" alt=""><figcaption></figcaption></figure>

This will list all the sourcetypes available in your Splunk environment. Now let's query our Sysmon sourcetype and take a look at the incoming data.

```shell-session
index="main" sourcetype="WinEventLog:Sysmon"
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FHgFkqw1V3UkVzhtGNnzh%2F3.webp?alt=media&#x26;token=68a155ed-3dea-4f98-b460-30c6305ca5fb" alt=""><figcaption></figcaption></figure>

We can delve into the events by clicking the arrow on the left.

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F6bF7HkGcd9FM2MrPBZRF%2F4.webp?alt=media&#x26;token=a1dc593b-ccd8-4df1-aa6a-4a031971218c" alt=""><figcaption></figcaption></figure>

Let's execute some generalized queries to illustrate performance differences. Let's search for all possible instances of `uniwaldo.local`.

```shell-session
index="main" uniwaldo.local
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2Fh0V4TSgCKaq9vqJpmqHt%2F5.webp?alt=media&#x26;token=438cb724-854d-4852-aa6c-1fb1a5b54993" alt=""><figcaption></figcaption></figure>

Now let's attempt to find all instances of this string concatenated within any other string such as "myuniwaldo.localtest" by using a wildcard before and after it.

```shell-session
index="main" *uniwaldo.local*
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FxWYQNnHCzpBhXldFG01e%2F6.png?alt=media&#x26;token=ba3cd41d-76af-4fa7-8cc2-29bc9290c30e" alt=""><figcaption></figcaption></figure>

Now let's target this string within the `ComputerName` field only, as we might only care about this string if it shows up in `ComputerName`. Because no `ComputerName` `only` contains this string, we need to prepend a wildcard to return relevant results.

```shell-session
index="main" ComputerName="*uniwaldo.local"
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FB1HumyiFVfCewgHrwdcV%2F7.webp?alt=media&#x26;token=50817ca1-c31f-4b1a-83ff-28ab9dcfe122" alt=""><figcaption></figcaption></figure>

You'll find that this query returns results `much` more swiftly than our previous search. The point being made here is that targeted searches in your SIEM will execute and return results much more quickly.

### Embracing The Mindset Of Analysts, Threat Hunters, & Detection Engineers

Making progress on our journey, let's pivot our focus towards spotting anomalies in our data. Remember the foundation we established in the `Windows Event Logs & Finding Evil` module, where we explored the potential of event codes in tracing peculiar activities? We utilized public resources such as the Microsoft Sysinternals guide for [Sysmon](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon). Let's apply the same approach and identify all Sysmon EventCodes prevalent in our data with this query.

```shell-session
index="main" sourcetype="WinEventLog:Sysmon" | stats count by EventCode
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FvR9O17qeWWUdQdWNmf1i%2F8.webp?alt=media&#x26;token=35a3b1ec-7b71-40b6-9e34-670f5bf79eb9" alt=""><figcaption></figcaption></figure>

Based on these `EventCodes`, we can perform preliminary queries. As previously stated, unusual parent-child trees are always suspicious. Let's inspect all parent-child trees with this query.

```shell-session
index="main" sourcetype="WinEventLog:Sysmon" EventCode=1 | stats count by ParentImage, Image
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FbL4lnIv4M2EyXIZ09VEx%2F9.png?alt=media&#x26;token=89dd2e09-712a-42df-861d-9c9780d2d5fa" alt=""><figcaption></figcaption></figure>

We're met with 5,427 events, quite a heap to manually sift through. We have choices, weed out what seems benign or target child processes known to be problematic, like `cmd.exe` or `powershell.exe`. Let's target these two.

```shell-session
index="main" sourcetype="WinEventLog:Sysmon" EventCode=1 (Image="*cmd.exe" OR Image="*powershell.exe") | stats count by ParentImage, Image
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2Fj4RHyUIO4R7d299ud7P5%2F10.webp?alt=media&#x26;token=763a2a17-8f53-4eef-9390-f1372d4e1847" alt=""><figcaption></figcaption></figure>

The `notepad.exe` to `powershell.exe` chain stands out immediately. It implies that notepad.exe was run, which then spawned a child powershell to execute a command. The next steps? Question the `why` and validate if this is typical.

```shell-session
index="main" sourcetype="WinEventLog:Sysmon" EventCode=1 (Image="*cmd.exe" OR Image="*powershell.exe") ParentImage="C:\\Windows\\System32\\notepad.exe"
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F3yRLt8m9rnDoQnMXqMJJ%2F11.png?alt=media&#x26;token=f1f36aab-ff27-4cd7-90b3-a1ee245dad5f" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FoCgcttUXXWnrmYqdlMxQ%2F12.webp?alt=media&#x26;token=09ede80e-84c7-4541-b305-6c524259e689" alt=""><figcaption></figcaption></figure>

We see the `ParentCommandLine` (just `notepad.exe` with no arguments) triggering a `CommandLine` of `powershell.exe` seemingly downloading a file from a server with the IP of `10.0.0.229`!

Our path now forks. We could trace what initiated the `notepad.exe`, or we could investigate other machines interacting with this IP and assess its legitimacy. Let's unearth more about this IP by running some queries to explore all sourcetypes that could shed some light.

```shell-session
index="main" 10.0.0.229 | stats count by sourcetype
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F61JdjbBc3QtCqcayvDOL%2F13.webp?alt=media&#x26;token=a91ce00a-2ad1-40b7-938d-e5ffe9853c9b" alt=""><figcaption></figcaption></figure>

```shell-session
index="main" 10.0.0.229 sourcetype="linux:syslog"
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F4VWGm0KvWcOQMmBUymEg%2F14.webp?alt=media&#x26;token=8c461132-21e2-41c2-b735-2b12e58c76d7" alt=""><figcaption></figcaption></figure>

Here we see that based on the data and the `host` parameter, we can conclude that this IP belongs to the host named `waldo-virtual-machine` on its `ens160` interface. The IP seems to be doing some generic stuff.

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FKBH9VplZ28s5JF2XOhpd%2F15.webp?alt=media&#x26;token=7efc5ccc-9269-428c-bfea-db9d547e58b3" alt=""><figcaption></figcaption></figure>

This finding indicates that our machine has engaged in some form of communication with a Linux system, notably downloading executable files through `PowerShell`. This sparks some concerns, hinting at the potential compromise of the Linux system as well!

```shell-session
index="main" 10.0.0.229 sourcetype="WinEventLog:sysmon" | stats count by CommandLine
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2Fean1zC6JS6qdT2QhA6h0%2F16.webp?alt=media&#x26;token=da7c343a-c6d8-4495-ade5-af20e194021b" alt=""><figcaption></figcaption></figure>

At this juncture, alarm bells should be sounding! We can spot several binaries with conspicuously malicious names, offering strong signals of their hostile intent.

From our assessment, it's becoming increasingly clear that not only was the spawning of `notepad.exe` to `powershell.exe` malicious in nature, but the Linux system also appears to be infected.

```shell-session
index="main" 10.0.0.229 sourcetype="WinEventLog:sysmon" | stats count by CommandLine, host
```

Our analysis indicates that two hosts fell prey to this Linux pivot. Notably, it appears that the DCSync PowerShell script was executed on the second host, indicating a likely `DCSync` attack.

```shell-session
index="main" EventCode=4662 Access_Mask=0x100 Account_Name!=*$
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FZ7p82Cy1xYYOa9wg1Tm9%2F18.webp?alt=media&#x26;token=9781f110-acac-4a32-85aa-537bcde37157" alt=""><figcaption></figcaption></figure>

Now, let's dissect the rationale behind this query. Event Code `4662` is triggered when an Active Directory (AD) object is accessed. It's typically disabled by default and must be deliberately enabled by the Domain Controller to start appearing. `Access Mask 0x100` specifically requests `Control Access` typically needed for DCSync's high-level permissions. The `Account_Name` checks where AD objects are directly accessed by users instead of accounts, as DCSync should only be performed legitimately by `machine accounts` or `SYSTEM`, not users.

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2Fki2tZYnvnB4MgTDGgOGH%2F19.webp?alt=media&#x26;token=7cc76550-029d-4f00-b321-8e63175777d3" alt=""><figcaption></figcaption></figure>

We notice two intriguing GUIDs. A quick Google search can yield valuable insights. Let's look them up.

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F3Lq2DAD6dRJQaZnMH3CE%2F20.webp?alt=media&#x26;token=b2417f89-9849-483b-b52f-ddc0a49b3729" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FGvsUEhMWM1apnk2ADBL4%2F21.webp?alt=media&#x26;token=1d1af3b4-85b2-4cdb-bcd8-bb14d4f57df1" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FsiCpJdIZ0Y5x0Ld6sNDU%2F22.webp?alt=media&#x26;token=ce9c2998-6187-4ff7-944a-dd722a8891df" alt=""><figcaption></figcaption></figure>

Upon researching, we find that the first one is linked to `DS-Replication-Get-Changes-All`, which, as per its description, "...allows the replication of secret domain data".

This gives us solid confirmation that a DCSync attempt was made and successfully executed by the Waldo user on the `UNIWALDO` domain. It's reasonable to presume that the Waldo user either possesses `Domain Admin` rights or has a certain level of access rights permitting this action.

However, it's evident that we've barely scratched the surface of the attacker's activities. The attacker must have initially infiltrated the system and undertaken several maneuvers to obtain domain admin rights, orchestrate lateral movement, and dump the domain credentials.

```shell-session
index="main" EventCode=10 lsass | stats count by SourceImage
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FFARf6iML8XKqOfxxl9w2%2F23.png?alt=media&#x26;token=d2a6980c-df15-45b1-b40d-c4233f4a5110" alt=""><figcaption></figcaption></figure>

We'll begin by examining any conspicuous strange process accesses to lsass.exe by any source image. The most noticeable ones are `notepad` (given its absurdity) and `rundll32` (given its limited frequency). We can further explore these as we usually do.

```shell-session
index="main" EventCode=10 lsass SourceImage="C:\\Windows\\System32\\notepad.exe"
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FL9rkNShaeuDx8ZbQUy7a%2F24.webp?alt=media&#x26;token=ffccdb03-64c1-4905-bb08-16a042bf032e" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F6DjzXqkwPO0OWM1vZSLz%2F25.webp?alt=media&#x26;token=d38e65d6-9379-45f7-92f0-98cb45eb0b50" alt=""><figcaption></figcaption></figure>

To the untrained eye, it might not be immediately apparent that the callstack refers to an `UNKNOWN` segment into `ntdll`. In most cases, any form of shellcode will be located in what's termed an `unbacked` memory region. This implies that ANY API calls from this shellcode don't originate from any identifiable file on disk, but from arbitrary, or `UNKNOWN`, regions in memory that don't map to disk at all. While false positives can occur, the scenarios are limited to processes such as `JIT` processes, and they can mostly be filtered out.

## Creating Meaningful Alerts

Armed with this newfound source of information, we can now aim to create alerts from malicious malware based on API calls from `UNKNOWN` regions of memory. It's crucial to remember that generating alerts differs from hunting. Our alerts must be resilient and effective, or we risk flooding our defense team with a glut of data, inadvertently providing a smokescreen for attackers to slip through our false positives. Moreover, we must ensure they aren't easily circumvented, where a few tweaks and seconds is all it takes.

We'll start by listing all the call stacks containing `UNKNOWN` during this lab period based on event code to see which can yield the most meaningful data.

```shell-session
index="main" CallTrace="*UNKNOWN*" | stats count by EventCode
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FJkvUPAk9J1Ys1HuK5eMQ%2F26.png?alt=media&#x26;token=a6b6ff0e-d95a-43a6-9331-ba59916d1642" alt=""><figcaption></figcaption></figure>

It appears that only event code 10 shows anything related to our `CallTrace`, so our alert will be tied to process access! This means we'll be alerting on anything attempting to open handles to other processes that don't map back to disk, assuming it's shellcode. We see 1575 counts though...so we'll begin by grouping based on `SourceImage`.

```shell-session
index="main" CallTrace="*UNKNOWN*" | stats count by SourceImage
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FQy6vzNTVlOhK1YATVlhk%2F27.png?alt=media&#x26;token=b7a3291f-8479-49cd-ae50-1a2039998d4b" alt=""><figcaption></figcaption></figure>

Here are the false positives we mentioned, and they're all `JITs` as well! `.Net` is a `JIT`, and `Squirrel` utilities are tied to `electron`, which is a chromium browser and also contains a JIT. Even with our smaller dataset, there's a lot to sift through, and we're not sure what's malicious and what's not. The most effective way to manage this is by linking a few queries together.

```shell-session
index="main" CallTrace="*UNKNOWN*" | where SourceImage!=TargetImage | stats count by SourceImage
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F52vWKbzvJ0GlyGj6itv8%2F28.webp?alt=media&#x26;token=c8ecca11-0506-4414-bc23-e3d204460877" alt=""><figcaption></figcaption></figure>

Next, we know that `C Sharp` will be hard to weed out, and we want a high-fidelity alert. So we'll exclude anything `C Sharp` related due to its `JIT`. We can achieve this by excluding the Microsoft.Net folders and anything that has `ni.dll` in its call trace or `clr.dll`.

```shell-session
index="main" CallTrace="*UNKNOWN*" SourceImage!="*Microsoft.NET*" CallTrace!=*ni.dll* CallTrace!=*clr.dll* | where SourceImage!=TargetImage | stats count by SourceImage
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FomfdPQ3l1OxDQFI09GsI%2F29.webp?alt=media&#x26;token=975834b7-e843-410b-b5a2-924b1f7f34a2" alt=""><figcaption></figcaption></figure>

In the next phase, we'll be focusing on eradicating anything related to `WOW64` within its call stact.

```shell-session
index="main" CallTrace="*UNKNOWN*" SourceImage!="*Microsoft.NET*" CallTrace!=*ni.dll* CallTrace!=*clr.dll* CallTrace!=*wow64* | where SourceImage!=TargetImage | stats count by SourceImage
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FuVaEo3Nn75bDHmptvinf%2F30.png?alt=media&#x26;token=eb48cb92-aa0f-45f8-ab70-14f6188b4900" alt=""><figcaption></figcaption></figure>

Moving forward, we'll also exclude `Explorer.exe`, considering its versatile nature. It's akin to a wildcard, capable of undertaking an array of tasks. Identifying any malicious activity within Explorer directly is almost a Herculean task.

```shell-session
index="main" CallTrace="*UNKNOWN*" SourceImage!="*Microsoft.NET*" CallTrace!=*ni.dll* CallTrace!=*clr.dll* CallTrace!=*wow64* SourceImage!="C:\\Windows\\Explorer.EXE" | where SourceImage!=TargetImage | stats count by SourceImage
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FXS0D18cPkumLKwgdK1un%2Fbrowser.webp?alt=media&#x26;token=e49c42f7-8b01-43cb-a815-a41674d6df32" alt=""><figcaption></figcaption></figure>

With the steps outlined above, we've now established a reasonably robust alert system for our environment. This alert system is adept at identifying known threats. However, it's essential that we review the remaining data to verify its legitimacy.

```shell-session
index="main" CallTrace="*UNKNOWN*" SourceImage!="*Microsoft.NET*" CallTrace!=*ni.dll* CallTrace!=*clr.dll* CallTrace!=*wow64* SourceImage="C:\\Windows\\Explorer.EXE" | where SourceImage!=TargetImage | stats count by SourceImage, TargetImage, CallTrace
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FcoVNvaF2ab8VXil55G80%2F31.webp?alt=media&#x26;token=e2c7f1fb-2123-48be-9688-6584a847f054" alt=""><figcaption></figcaption></figure>

uilding this alert system was relatively simple due to the limited data and false positives in our current environment. However, in a real-world scenario, the volume of data would be much larger, necessitating more sophisticated methods to detect potential malicious activities. It's also crucial to consider the effectiveness of the alert—how easily could it be bypassed? For example, a hacker could evade detection by loading a random DLL with "NI" appended to its name. Enhancing the alert would require considering such bypass techniques and fortifying against them.

In summary, we've developed skills to analyze large datasets, identify potential threats, explore SIEM systems for valuable data sources, trace attacks, and create effective alerts. While our examples were simplified with a smaller dataset of about 500,000 events, real-world scenarios might involve different scales of data, requiring more advanced techniques. As you progress in cybersecurity, remember the importance of effective search strategies, innovative data analysis, leveraging open-source intelligence, and creating robust alerts that are difficult to bypass.

## Practical Exercises

1\) Navigate to http://\[Target IP]:8000, open the "Search & Reporting" application, and find through an SPL search against all data the other process that dumped lsass. Enter its name as your answer. Answer format: \_.exe

```
index="main" sourcetype="WinEventLog:Sysmon" EventCode=10 lsass 
| stats count by SourceImage, TargetImage
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F7dwl0Ev6woFZlJITE0iR%2FScreenshot(10).png?alt=media&#x26;token=d9baec26-fec9-4aa7-885b-53b082fc089d" alt=""><figcaption></figcaption></figure>

Answer:  rundll32.exe

2\) Navigate to http://\[Target IP]:8000, open the "Search & Reporting" application, and find through SPL searches against all data the method through which the other process dumped lsass. Enter the misused DLL's name as your answer. Answer format: \_.dll

```
index="main" sourcetype="WinEventLog:Sysmon" EventCode=10 lsass SourceImage="C:\\Windows\\System32\\rundll32.exe"
| stats count by SourceImage, TargetImage, CallTrace
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FDcR4H35pZRDhOX9yAH0D%2FScreenshot(11).png?alt=media&#x26;token=203bf3b0-9727-4cf5-9079-f228f397e4f9" alt=""><figcaption></figcaption></figure>

`rundll32.exe` is a legitimate Windows utility used to execute DLLs (Dynamic Link Libraries) and call specific functions from them. However, attackers often misuse `rundll32.exe` to execute malicious activities, as it allows them to run code in a way that might evade detection.

`comsvcs.dll` is a legitimate Windows system DLL that is associated with COM+ services and is part of the Microsoft COM+ application environment. One of its lesser-known functions is the `MiniDump` function, which can be used to create memory dumps of processes, including the Local Security Authority Subsystem Service (LSASS).

Answer:  comsvcs.dll

3\) Navigate to http://\[Target IP]:8000, open the "Search & Reporting" application, and find through an SPL search against all data any suspicious loads of clr.dll that could indicate a C# injection/execute-assembly attack. Then, again through SPL searches, find if any of the suspicious processes that were returned in the first place were used to temporarily execute code. Enter its name as your answer. Answer format: \_.exe

```
index="main" EventCode=7 ImageLoaded="*clr.dll" 
| stats count by Image
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F6rFi09acDaRQSy6IwxtJ%2FScreenshot(12).png?alt=media&#x26;token=5df85f84-ebd1-40cb-87a7-7f057a01c776" alt=""><figcaption></figcaption></figure>

In a standard, legitimate scenario, `clr.dll` would not be loaded by `rundll32.exe`. Seeing this behavior in logs or security events can be an indicator of malicious activity or process injection. This pattern is not typical for legitimate software, suggesting that an attacker may be trying to use native Windows utilities to execute their malicious code.

Using `rundll32.exe` to invoke the CLR provides a stealthy way to execute .NET-based payloads without triggering alarms.

Answer:  rundll32.exe

4\) Navigate to http://\[Target IP]:8000, open the "Search & Reporting" application, and find through SPL searches against all data the two IP addresses of the C2 callback server. Answer format: 10.0.0.1XX and 10.0.0.XX

```
index="main" sourcetype="WinEventLog:Sysmon" EventCode=3
| stats count by Image, DestinationIp
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2F3moiqxtxMUhlpyzFBobi%2FScreenshot(13).png?alt=media&#x26;token=b354a11f-1016-4d7b-81db-f9cd2b8280b0" alt=""><figcaption></figcaption></figure>

```
index="main" sourcetype="WinEventLog:Sysmon" EventCode=3 Image="C:\\Windows\\system32\\notepad.exe" 
| stats values(DestinationIp) as destination_ips
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FLy4zI7sG1at3O0UBGQOR%2FScreenshot(14).png?alt=media&#x26;token=b7e847c9-bb04-42e9-94f1-52b81d289211" alt=""><figcaption></figcaption></figure>

Answer:  10.0.0.186 and 10.0.0.91

5\) Navigate to http://\[Target IP]:8000, open the "Search & Reporting" application, and find through SPL searches against all data the port that one of the two C2 callback server IPs used to connect to one of the compromised machines. Enter it as your answer.

```
index="main" sourcetype="WinEventLog:Sysmon" EventCode=3 (SourceIp="10.0.0.186" OR SourceIp="10.0.0.91")
| stats values(DestinationPort) as destination_ports
```

<figure><img src="https://2537271824-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FIswWWP3l0rGuQmG2WUcr%2Fuploads%2FgsXDl1x6eD8qUdzh7Jt9%2FScreenshot(15).png?alt=media&#x26;token=49eed372-6992-47f4-8265-ed122d763976" alt=""><figcaption></figcaption></figure>

Answer:  3389
