Skip to content

Lab 4.2: Timeline Investigations

Est. Time: 30 minutes

Optional

Goals:

  • Work a mock ticket using an Elastic Timeline and Case
  • Fill out a Jira ticket on the issue for the “customer”

Instructions

If you’re on your own machine, these are the scripts you will need for this lab:

Lab4-2.ps1

Lab4-2-Cleanup.ps1

In this lab you’ll be asked to run a PowerShell script which triggers an Atomic to generate the “hidden” activity you’ll need to investigate. I can’t stop you from looking up that Atomic in ART, but I would recommend not doing so- often in SOC work you won’t have that luxury of knowing what commands exactly were run.

  1. To prepare for this lab, in an administrative PowerShell window run the script: Lab4-2.ps1

    1. Navigate to wherever you have the scripts located

      cd "C:\Users\Administrator\Desktop\Lab Scripts"

    2. Run the PowerShell lab script 4-2:

      powershell -exec bypass
./Lab4-2.ps1

  2. The scenario of this lab starts with you receiving an email directly from a customer:

    Hello my favorite SOC,

    Something weird is going on with my computer, . I was just browsing my favorite Myspace pages and now every so often I see a bunch of commands pop up on my screen for a second. I’m scared of commands. Please help!

    1. In this scenario, the customer has emailed you directly, not your Jira email, and told you that something strange is happening on their PC. You need to investigate this within an Elastic Case and Timeline.
    2. Since this request didn’t get generated by your SIEM, you’ll need to create a ticket to work in. You can either create both a Jira ticket and an Elastic Case, or you can create an Elastic Case and have that create the ticket for you. The latter is the method I’m going to do.
    3. Create an Elastic Case and Timeline for you to investigate in.

    1. In mine I included the information sent to me by the customer, gave it a generic name, set myself as the assignee, and set it as high priority.

    2. Near the bottom of the screen under “External incident management system”, select:

      1. Your Jira connector
      2. The [System] Incident issue type
      3. Your alert priority (in this example, I went with “High”)

      4. Then create the case

  3. Your case should now look something like this:

  4. This should also have created a Jira ticket in your SOC queue:

    1. Note that from Jira you can get right to the Elastic case with the URL sent along by Elastic.
    2. Two last things are needed before we can investigate.

    3. First, the ticket needs to be claimed. Mark the Elastic case as in progress.

  5. In this lab, you are investigating within a Timeline, therefore you need a timeline. You should have an untitled one at the bottom of your screen by default:

    1. Click “untitled timeline” or create a new timeline with the plus symbol.
    2. Save the timeline with a name; either the name of your Elastic case or your Jira ticket ID.

    3. Attach your timeline to your case with the “Attach to case” dropdown in the top right of the Timeline. It may already be connected if you created it from the Case itself.

      1. Notice that you could have actually created the case here as well!
        1. Once you select the Case, it pre-generates a comment for you on that Case. This is so either yourself or anyone else in the SOC looking at this Case can reference which Timeline is being used for the investigation.

  6. Now to investigate! In this scenario the hostname of the user’s computer is the name of your VM/test host. The customer didn’t give you too much to go on, but try your best to apply the ideas you’ve learned so far. Remember to use the timeline for your investigation, and to provide a good write up in your Jira ticket to the customer.

    • Tips

      1. Pin events of interest in your Timeline.
      2. If a search isn’t working, try something else!
      3. Add notes if you need to remember what something is.

      4. Keep an eye out for the analzer. Remember the analyzer means something is there to analyze.

      5. Do your best to explain what is going on, and write up that ticket to the customer.

      6. Keep your working notes as “Internal notes” in Jira, and then create a customer-facing note if you are ready to escalate.
      7. Generally the customer will only be able to view your Jira tickets, not your Elastic Cases. So make your comments to them there. Elastic should be for you and your team.
      8. When you’re done, close out your Jira ticket and your Elastic case!
      9. Solution: Below is the path I took to find the events in question.
        1. I started by looking at network events for that host. Is our user a developer? Because they’re hitting Github. That isn’t necessarily bad, but it makes me curious what they’re downloading.

    • What process is connecting to Github? Filtering by the process.pid of that network connection cues us in to that. The process connecting to GitHub is PowerShell. Definitely odd.

    • Looking at that PowerShell event, we can look to see what the command was that ran. In this case, PowerShell downloaded and ran a batch file from Github.

    • This would be a good event to pin in your timeline; this will allow you to easily return to it later if you need to.

    • That PowerShell event also can be analyzed; looking at that, there is quite a lot of activity going on:

      1. So far this activity looks far from normal. Exploring the analyzer can be a good way to visualize what sort of things a process has done. You can view the same activity in the logs, but sometimes a visual view helps.

    • Back in the timeline query, we can filter by the process.pid to see what else that PowerShell process did. It’s safe to say at this point that this process is not a friendly one.

    1. You may have also gotten another alert during this lab; that is because net user is part of this Atomic test!

      1. Check out the parent.process.pid; It’s the same as the one above doing all sorts of weird registry things.
        1. At this point is when you should realize that something malicious has occurred on this device. The next steps for you as a SOC analyst would be escalating this activity to the customer with all of the necessary information. As for remediation of the issues, that would largely depend on your SOC’s setup so I won’t cover that here.
      2. When you’re done, run the cleanup command:
    ./Lab4-2-Cleanup.ps1

  7. Now to explain what happened here.

    1. The attack that was run:
      1. The Atomic
      2. MITRE Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
    2. This Atomic executes a persistence mechanism where certain values are added to the registry at locations called the “Run keys”, which execute when a user logs in. In this case, a batch file was executed when the “customer” “logged in” again.
    3. You may have found the creation of these registry keys during this lab; if you found that, awesome job! And if you caught on as the Net User alert fired, also amazing job!
    4. Your alerting stack provided some layers of defense. You didn’t have a detection that caught the registry keys being created, but you had one that caught some of it’s other activities. The more high quality detections you have, the more layers of defense you’ll have.

    Additional Resources