Hunting with elk

Elastic's ELK is an open source stack that consists of three applications (Elasticsearch, Logstash and Kibana) working in synergy to provide users with end-to-end search and visualization capabilities to analyze and investigate log file sources in real time.

ELK's architecture, at a high level, is the following.

On demanding/data-heavy environments, ELK's architecture can be reinforced by Kafka, RabbitMQ and Redis for buffering and resilience and by ngnix for security.

Let's dive into all of ELK's components.

• Elasticsearch is a NoSQL database based on the Lucene search engine and built with RESTful APIs. It is essentially the index, store and query application of the ELK stack. It provides users with the capability to perform advanced queries and analytics operations against the log file records processed by Logstash.

• Logstash is the tool responsible for the collection, transformation and transport of log file records. The great thing about Logstash is that it can unify data from disparate sources and also normalize them. Logstash has three areas of function.

• Process input of the log file records from remote locations into a machine understandable format. Logstash can receive records through a variety of ways (https://www.elastic.co/guide/en/logstash/current/input-plugins.html) such as reading from a flat file, reading events from a TCP socket or directly reading syslog messages. When Logstash completes processing input it proceeds to the next function.

• • Transform and enrich log records. Logstash provides users with numerous methods to make changes to the format (and even content) of a log record. Specifically, filter plugins exist that can perform intermediary processing on an event (most of the times based on a predefined condition). Once a log record is transformed Logstash processes it.

  • Send log records to Elasticsearch by utilizing any of the output plugins.

  • Kibana is the tool used for visualizing the Elasticsearch documents. Through Kibana users can view the data stored in Elasticsearch and perform queries against them. It also facilitates the understanding of query results through tables, charts and custom dashboards.

• Note: Beats is an additional download that should be installed in every remote location for its logs to be shipped to the Logstash component.

  ELK's Search:

  As threat hunters, chances are that we will spend the majority of our ELK-time inside Kibana. For this reason, we will focus on submitting searches through Kibana.

• Kibana searches are usually formatted asFieldName:SearchTerm. Fields and search terms are case sensitive.

• Boolean operators like AND, OR are supported (and are sometimes implied).

• Wildcards and free text searches can be used, but use sparingly.

let's begin

Perform a hunt for well-known PowerShell Offensive Frameworks and commands

The information we are interested in is contained in the ScriptBlockText field of event ID 4104.

winlog.event_data.ScriptBlockText:(PowerUp OR Mimikatz OR NinjaCopy OR Get-ModifiablePath OR AllChecks OR AmsiBypass OR PsUACme OR Invoke-DLLInjection OR Invoke-ReflectivePEInjection OR Invoke-Shellcode OR Get-GPPPassword OR Get-Keystrokes OR Get-TimedScreenshot OR PowerView)

Perform a hunt for suspicious parent process spawning PowerShell

we'll look into Sysmon's Process creation events, event id 1 so we start by filtering out for those.

Then we proceed with our research for identifying suspicious parent processes.

winlog.event_data.ParentImage:(*mshta.exe OR *rundll32.exe OR *regsvr32.exe OR *services.exe OR *winword.exe OR *wmiprvse.exe OR *powerpnt.exe OR *excel.exe OR *msaccess.exe OR *mpub.exe OR *visio.exe OR *outlook.exe OR *chrome.exe OR *iexplorer.exe OR *sqlserver.exe) AND winlog.event_data.Image : *powershell.exe

If you expand the first match and look at the parent process's command line argument

Regsvr32 using a well-known command execution to spawn PowerShell.

Perform a hunt for renamed PowerShell.exe

we look into Sysmon again for any created process (event id 1) with description containing "PowerShell" that is not powershell.exe or powershell_ise.exe.

winlog.event_data.Description:*PowerShell AND NOT (winlog.event_data.Image:*powershell.exe OR winlog.event_data.Image:*powershell_ise.exe)

The image above reveals that the program executed is "C:\ProgramData\Windows.exe"

Another approach would be to look for EventID 400, where the HostName is ConsoleHost but the HostApplication is not powershell.exe.

Perform a hunt for base64-encoded PowerShell commands

we'll use Sysmon event id 1, looking for command line arguments that would match those of an encoded command.

(winlog.event_data.Description:*PowerShell OR  winlog.event_data.Image:*powershell.exe) AND winlog.event_data.CommandLine:*-e*

If we decode the passed command, we'll find that it is the command "whoami".

Perform a hunt for PowerShell attacks utilizing GZIP compression

We'll be looking at ScriptBlockText of event id 4104. After some research we find that GZIP archives have the magic number "H4sI", which appears quite unique. That will be our detection -- let's filter for event id 4104

winlog.event_data.ScriptBlockText:*H4sI*

Perform a hunt for obfuscated PowerShell code using XOR

we'll be looking at ScriptBlockText of event id 4104. After an extensive research, we find that XOR usage involves the operators "char", "bxor" and "join". After filtering for event id 4104

winlog.event_data.ScriptBlockText:(*bxor* AND *join*)

Perform a hunt for execution of an assembly from file by PowerShell

we'll be looking at ScriptBlockText of event id 4104. After performing a research, we find that to execute an assembly from file, a function "Load" together with either "ReadAllBytes" or "LoadFile" is utilized.

winlog.event_data.ScriptBlockText:((*Load*) AND (*ReadAllBytes* OR *LoadFile*))

Perform a hunt for PowerShell commands downloading content

we'll be looking at ScriptBlockText of event id 4104. After doing our research, we identify a large number of possibilities for download content.

winlog.event_data.ScriptBlockText:(*WebClient* OR *DownloadData* OR *DownloadFile* OR *DownloadString* OR *OpenRead* OR *WebRequest* OR *curl* OR *wget* OR *RestMethod* OR *WinHTTP* OR *InternetExplorer.Application* OR *Excel.Application* OR *Word.Application* OR *Msxml2.XMLHTTP* OR *MsXML2.ServerXML* OR *System.XML.XMLDocument* OR *BitsTransfer*)

Perform a hunt for obfuscated PowerShell commands

we'll be looking at ScriptBlockText of event id 4104. After doing a research on obfuscated commands, we identify a large number of interesting characters that may be of interest

winlog.event_data.ScriptBlockText:((*char* AND *join*) OR ((*ToInt* OR *ToInt16* OR *ToDecimal* OR *ToByte* OR *ToUnit* OR *ToSingle*) AND (*ToChar* OR *ToString* OR *String*)) OR (*ForEach* AND *Xor*))

Additional research leads us to reverse obfuscated, or certain words spelled backwards. We go through common cmdlets, and terms and construct a query with them in reverse order as follows

winlog.event_data.ScriptBlockText:(*hctac* OR *kearb* OR *dnammoc* OR *ekovn* OR *elifd* OR *rahc* OR *etirw* OR *eddih* OR *tpircs* OR *ssecorp* OR *llehsrewop* OR *esnopser* OR *daolnwod* OR *tneilcbew* OR *tneilc* OR *ptth* OR *elifotevas* OR *46esab* OR *tcejbo* OR *maerts* OR *hcaerof* OR *retupmoc*)

--

Scenario

The IT Security manager provided you with simulated malicious activity and has asked you to create hunting detection techniques for all of i

Hunt for malicious use of rundll32

Attackers are known for leveraging native Windows' functionality/binaries to evade detection while executing malicious code.

we find out that rundll32.exe can call pcwutl.dll which has the ability to execute an application. Utilizing that information

process.name:rundll32.exe AND (process.args:pcwutl.dll AND process.args:LaunchApplication)

Hunt for UAC Bypass

we focus on technique 7. According to the documentation, the bypass is implemented through an abuse of "cliconfg.exe". Because the abuse requires that cliconfg.exe loads "NTWDBLIB.dll", we'll focus our detection exactly on that, specifically filtering for Sysmon's Event ID 7 -- Image loaded.

event.id:7 AND (process.name:cliconfg.exe AND file.path:NTWDBLIB.dll)

Hunt for RDP Settings tampering

Taking into account the hint provided, if any RDP tampering or abuse (eg. RDP tunneling etc) is to occur, RDP should first be enabled.

herefore, our detection will focus on detecting whether RDP has been enabled. One of the common ways to do this, is to monitor if netsh is used to create a firewall rule that allows an RDP connection. Therefore, we focus our detection on Sysmon event ID 1 - Process Creation.

event.id:1 AND (process.name:netsh.exe AND (process.args:localport=3389 AND process.args:action=allow))

Clearly, enabling RDP on its own is not necessarily malicious, therefore, additional effort is required to conclude that. Nonetheless, tampering has occurred.

Hunt for DCSync

One way to obtain a detection rule is by looking at Sigma, specifically the DCSync detection rule here.

event.id:4662 AND NOT (user.name:*$ OR user.name:AUTHORITY OR user.name:Window) AND (object.properties:1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 OR object.properties:Replicating)

Hunt for Remote WMI Usage

we'll identify that remote usage of WMI will create an Event ID 4648 -- logon with explicit credentials, with source process of wmic.exe. That is illustrated on the image below:

Utilizing that, we can create our detection technique

event.id:4648 AND process.executable:WMIC.exe

If we expand that entry, we'll get more details on the account(s) associated with the login:

Hunt for LOLBAS openurl

Let's take into account everything the hint of this task mentioned as well as Sysmon Event ID 1 - Process Creation

process.executable:rundll32.exe AND process.args:(url.dll OR ieframe.dll OR shdocvw.dll)

we get 5 matches. A single match with ieframe.dll, which opens a URL file from a temporary directory:

The other 4 matches are related to url.dll. As we can see below, one of them executes an .hta file:

The fact that .hta file is being executed means that mshta, as the default handler, will be called. Therefore, if we utilize the following query, we can confirm that calc.hta gets executed by mshta:

process.executable:mshta.exe AND process.args:calc.hta

Hunt for persistence through scheduled Tasks

By researching the provided URL, we identify that both "at.exe" and "schtasks.exe" can be used to schedule a task on a Windows host. While "at.exe" is rarely used, we are interested in any occurrence of its execution but for "schtasks.exe", we'll only look into those that are creating new tasks. The detection is based on Sysmon Event ID 1 - Process Creation.

event.id:1 AND ((process.executable:schtasks.exe AND process.args:create) OR process.executable:at.exe)

On the output above, we can see that an action that executes "mshta.exe" against a remote URL address is added. To verify that the command executed successfully, we can perform another search for Sysmon Event ID 11 - File Create and search whether a task with the filename provided is now available under C:\Windows\Tasks where all tasks are stored:

event.id:11 AND file.path:MSOFFICE_

Hunt for UAC Bypass #2

we identify that a detection technique would be to monitor the registry key at:

"HKCU:\Software\Classes\exefile\shell\runas\command\isolatedCommand"

However, in our experience, the location of the key may change slightly, therefore, the exact location we'll be looking for is any registry key that contains "shell\runas\command\isolatedCommand". To monitor registry key events, we will utilize Sysmon Event ID 13 -- Registry event

event.id:13 AND registry_key_path:"shell\\runas\\command\\isolatedCommand"

If we expand the entry, we'll see the value which is added to the key:

Upon successful elevation, notepad.exe will start in high integrity.

--

(https://github.com/thomaspatzke/elk-detection-lab). Use it as a detection playground to practice your ELK-query-writing skills.

Go to Discover

Select winlogbeat-

Perform a hunt for account discovery

we begin by reading the documentation in the hint's area. After going through it, we'll discover that "net" is a utility often used for this enumeration. Moreover, Windows 10 has introduced two new events, which are quite interesting:

• 4798 -- A user's local group membership was enumerated

• 4799 -- A security-enabled local group membership was enumerated

winlog.event_id:(4798 OR 4799) AND winlog.event_data.CallerProcessName:(net OR net1) AND winlog.computer_name: MSEDGEWIN10

The user IEUser has been enumerating the built-in group Administrators, and the built-in account Administrator.

Hunt for Persistence through Accessibility Features

Reviewing the information available in T1015, we assemble the following list of targeted executables:

• Sethc.exe

• Utilman.exe

• Osk.exe

• Magnify.exe

• Narrator.exe

• DisplaySwitch.exe

• AtBroker.exe

taking into account that the hint refers to file replacement with cmd.exe, what we would be interested into, is if a file with any of the names listed above contains the Description field that matches cmd.exe -- essentially, we are looking for renamed cmd.exe. Finally, the user it would execute as is "NT AUTHORITY/SYSTEM".

winlog.event_data.Image:("C:\Windows\System32\osk.exe" OR "C:\Windows\System32\sethc.exe" OR "C:\Windows\System32\utilman.exe" OR "C:\Windows\System32\magnify.exe" OR "C:\Windows\System32\narrator.exe" OR "C:\Windows\System32\displayswitch.exe" OR "C:\Windows\System32\atbroker.exe") AND winlog.event_data.Description:"Windows Command Processor" AND winlog.event_data.User:"NT AUTHORITY\SYSTEM" AND winlog.computer_name:DC1.insecurebank.local

Hunt for Privilege Escalation through Scheduled tasks

we create a list of writable locations by all users, which is suspicious to run tasks from (remember to filter out known-good!). These locations are:

• C:\users\*

• C:\programdata\*

• C:\Windows\Temp\*

Now for this hunt, we have only Sysmon logs available, therefore for our detection capability will focus on Event ID 1 (Process creation) specifically looking for execution of schtasks.exe with a command line parameter that points to one of the locations listed above.

winlog.event_id:1 AND winlog.event_data.Image:"C:\Windows\system32\schtasks.exe" AND winlog.event_data.CommandLine:("C:\users" OR "C:\programdata" OR "C:\Windows\Temp")

passed to schtasks.exe, a new task is created. Following that activity, we can leverage Sysmon Event ID 11 (File create) to identify the creation

winlog.event_data.TargetFilename:"C:\Windows\System32\Tasks\elevator"

we can identify if it was executed by modifying our first query but this time, we are looking at the command line argument that contains the task name "elevator" and the string "run" (which indicates task execution).

winlog.event_id:1 AND winlog.event_data.Image:"C:\Windows\system32\schtasks.exe" AND winlog.event_data.CommandLine:("run" AND "elevator")

we would be interested to see if the task has spawned any of the following as the SYSTEM user:

• wscript.exe

• rundll32.exe

• cscript.exe

• regsvr32.exe

• cmd.exe

• wmic.exe

• mshta.exe

• powershell.exe

Taking into consideration that the environment is based on Windows 7 workstations and as stated by T1053, "taskeng.exe" will be the executing process starting one of those listed above.

winlog.event_id:1 AND winlog.event_data.ParentImage:"taskeng.exe" AND winlog.event_data.Image:("cmd.exe" OR "wscript.exe" OR "rundll32.exe" OR "cscript.exe" OR "regsrv32.exe" OR "wmic.exe" OR "mshta.exe" OR "powershell.exe")

. If we expand the fields, we will also note that it was executed as "NT AUTHORITY\SYSTEM".

Finally, we can search for traces of task deletion in a similar fashion as we searched whether it was executed, however, now we will look for "delete" instead of "run".

winlog.event_id:1 AND winlog.event_data.Image:"C:\Windows\system32\schtasks.exe" AND winlog.event_data.CommandLine:("delete" AND "elevator")

Hunt for RDP over a Reverse SSH Tunnel

to discover this activity, we should be looking at Event ID 4624 (Successful logon) with Logon type 10 (indicating RDP). Moreover, we should ensure that the network source address points to the loop IP address (127.0.0.1). Converting this into ELK query, and taking into account the computer name given in the task, we get the following:

winlog.event_id:4624 AND winlog.event_data.LogonType:10 AND winlog.event_data.IpAddress:"127.0.0.1" AND winlog.computer_name:"PC01.example.corp"

Here we see that we have a match and have therefore successfully identified the activity our hunt is focused on.