Lab 2.3: Baby’s first query

Est. Time: 30 minutes

Goals:

• Learn how to search in Elastic with KQL
• Make your search easy to look at
• Find a few log events:
  • Our first log-in event to the VM
  • Enrollment of the host in our elastic cluster
  • The whoami command we ran

Instructions

1. In this lab you are going to write some KQL queries to look for a few specific log events that you generated earlier:
   1. Your initial log-in event to the VM
   2. The command that was run to enroll the host in the elastic agent
   3. The WHOAMI command you ran after installation of the agent

2. Begin by navigating to the Discover tab in your Elastic instance.

   

3. First, adjust the time range of your search, as well as the dataview.

   1. You can guesstimate how long ago you ran the commands in question, or you can search a longer range.
   2. Note: on a production server with numerous hosts and more data, searching a longer time range will take longer and cause more load. In our case though, we are only logging from one host that isn’t doing much.
   3. In my case I set the time range as “Last 7 days”; and given the state of our cluster this should be absolutely fine.
   4. As for the dataview, you may default to metrics-* which is not going to contain the new Windows logs we’re shipping. The default depends on your deployment type. Security solution default is often the default for Serverless which is fine.

4. Before you even start searching, you should add a few basic fields to your table. You can always change this later by expanding an event and adding more fields, but to start with, it is recommended to include a few basic fields that you prefer.

   1. The basic fields I usually include in all my investigative queries are:
      1. event.action and/or event.code
      2. host.name
      3. user.name
      4. process.pid
      5. process.executable
      6. process.command_line
   2. If a field doesn’t exist in a log event, you can’t add it from the Expanded view.

   3. If a field doesn’t exist within an event you are viewing, you can still add it from the Sidebar. For that reason I usually will add all my fields from the sidebar before I start searching.

      

5. Now that the search results won’t look like a wall of text, there are a few ways you can find these events in Elastic. In this lab you can find them however you like, but If you need hints I’m going to include the queries I used below.

6. Reminder that the three events you need to find are:
   1. The ini
   2. The command that was run to enroll the host in the elastic agent
   3. The WHOAMI command you ran after installation of the agent

Help and Tips

General tips:

• Selecting the right columns when searching can make your life significantly easier, since the data you’re looking for will be readily available and easily filterable.
• Don’t be afraid to use wildcards.

Further tips:

• Log-In Event

  1. To find the log-in event, I’m going to search by the eventcode for a Windows log on event (4624) and filter the timestamp to look for the oldest event
  2. I also know that the username of this account (from running our WHOAMI command!) is “Administrator” (uh oh, bad practice), so I’m going to explicitly specify that. The user.name field is case sensitive.

  3. Solution:

     The KQL query I used is:

     event.code: 4624 and user.name: Administrator
     

     Looking at the results, I see a couple of log-in events

     

     Both of these events are effectively part of the same logon. The logon type of 3 is a network logon- and 10 is a RemoteInteractive: https://learn.microsoft.com/en-us/windows-server/identity/securing-privileged-access/reference-tools-logon-types

• Elastic Agent Enrollment

  1. There are several ways to look for this one. We could look for the process we ran the event from, we could look for part of the elastic command, or we could look for the whole thing.

  2. For this example, let’s say we don’t really know what to look for. That’s occasionally the case during an investigation. So let’s do a very broad search to narrow down our results. That search might look like:

     process.command_line: *elastic*
     

  3. Solution:

     Filtering by process.command_line: *elastic* we almost immediately can see the command are looking for, both for installation and enrollment. We can tell by the process command line flags of install and enroll.

     

     Maybe if we wanted we could have also filtered the command_line also by “enrollment” or some other key word we’re looking for, for other ideas.

     Another way you might find something like this, in a very specific sense, would be a query like:

     process.name: "elastic-agent.exe"
     

     This would be less resource intensive than having two wildcards, but we’ll talk a lot more about optimizing searches later.

• The WHOAMI

  1. This one is easy enough to find by the process name.

  2. Solution

     process.name: whoami.exe
     

     This one also should also pop up right away.

     

Additional References

• KQL Syntax