L1130-Blue: Silent Trinity Hunt!

• Kibana and Initial Hunt
  • Login to Member Server (WS01)
  • Access Kibana on the (H)ELK SIEM
  • Initial Search: msbuild
• ElastAlert
  • Login to Member Server (WS01)
  • Access Kibana on the (H)ELK SIEM
  • ElastAlert
• Sysmon Stack
  • Login to Member Server (WS01)
  • Access Kibana on the (H)ELK SIEM
  • Sysmon Log Index
• Off-Roading with C2 Frameworks
  • Windows Events.
  • Sysmon Logs
  • Text Search MSBuild
  • Beacon Timing
  • More Safari
  • Mitre ATT&CK Technique Mapping
  • ElastAlert Index
• Shutdown Malware Stagers
  • PowerShell Stager
  • XML Stager
  • Putty Sessions
  • Reboot MemberServer WS01

Complementing L1130-Red, in this Lab we will be hunting for the trail of IoCs that were the result of malware execution on the Member Server.

• Hunt for Silent Trinity artifacts in Helk
• Utilize ElastAlerts Helk Augmenting.
• Review Sysmons Optics Malware Pathology

Connect to the Helk service. Begin hunting for evidence of a compromise. Review opportunities to use ElastAlert in the hunt. Review Sysmons optics stack that resulted from the compromise.

Kibana and Initial Hunt

Lets kickoff the hunt! Login to the WS01 system and access Kibana.

Login to Member Server (WS01)

Connect via Remote Desktop to the Member Server (WS01).

• See Lab L0200 for connection instructions.

Access Kibana on the (H)ELK SIEM

Using Chrome or Internet Explorer on Member Server, access the Kibana URI and login using the credentials below.

URL: https://10.10.98.20
Useranme: helk
Password: hunting

Initial Search: msbuild

Investigate the Kibana dashboard for activity. Use the search term msbuild as seen below. If you're not sure which index to start with, choose logs-*

msbuild

Given enough processing time, Elastic should produce a result like the following (note the 30 second refresh timer). Over a 30-minute period, the malware beaconed approximately once every six (6) seconds.

Event logs may appear as follows:

Having identified the msbuild IoC, continue to the next step of the lab.

ElastAlert

Continue the hunt!

Login to Member Server (WS01)

Connect via Remote Desktop to the Member Server (WS01).

• See Lab L0200 for connection instructions.

Access Kibana on the (H)ELK SIEM

Using Chrome or Internet Explorer on Member Server, access the Kibana URI and login using the credentials below.

URL: https://10.10.98.20
Useranme: helk
Password: hunting

ElastAlert

Investigate the Elastalert_status log index (switch log indices as demonstrated in earlier labs) and set refresh values, time window, etc. Expand a document and toggle match_body.RuleName and rule_name fields as columns.

Two techniques should come in to focus now. The first – “Signed Binary Proxy Proxy Execution” – is interesting. Note that these were not picked up because of the Signed Binary Execution, but because the port in use was TCP/4444, which is a common backport used by instructors.

The screenshot to the below has the “Suspicious Back Connect Ports” MITRE rule filtered. Under most circumstances, malware authors do not use TCP 4444 for communication channels.

Sysmon Stack

Continue the hunt!

Login to Member Server (WS01)

Connect via Remote Desktop to the Member Server (WS01).
See Lab L0200 for connection instructions.

Access Kibana on the (H)ELK SIEM

Using Chrome or Internet Explorer on Member Server, access the Kibana URI and login using the credentials below.

URL: https://10.10.98.20
Useranme: helk
Password: hunting

Sysmon Log Index

Filtering “Suspicious Ports” caused the alert for MSBuild to drop out of the ElastAlert results. Next, try the Sysmon log index to see if there are IoCs. Below, the log index was swapped to logs-endpoint-winevent-sysmon-* and a spike in activity is apparent.

The results pane seen to the below also allows an end user to draw a rectangle around a time window of interest.

Clicking on a single time column should present results like the following. The results pane below has RuleName, dst_ip_addr, and process_name toggled as columns. Sysmon appears to have caught both C2 beacons, shipped the logs to Elastic, which then mapped them to the appropriate MITRE Framework Techniques.

Lets consider going off road and see what more we can find!

Off-Roading with C2 Frameworks

Sometimes the hunt involves following leads that take you off-course, off-road, and into the weeds. With strong (verbose) threat optics, you begin to see how adversarial tools interact with the systems they attack. Some methodologies of hunts will require you to investigate and analyze what is happening in certain time periods were you know tool interaction exist.

Windows Events.

Let's start in Kibana and work backward. (Be sure to check the time in your query (Calendar Control in Kibana) Select log index: Search stager.*

We were able to catch the execution of the msbuild process.

Sysmon Logs

Let's go look at the sysmon logs. Why?

• The sysmon logs will do a much better job of tracking network connections than standard Windows logs.

Source and destination IP, destination port, actual MITRE technique mapped:

• T1218 – Signed Binary Proxy Execution.

Text Search MSBuild

Head back to Kibana and search for msbuild

msbuild

A few of the column headers shown below add value to the search. Add what you feel helpful. The pattern looks like we may have found a beacon.

Beacon Timing

Drilling down, we have what appears to be a beacon in logs.

More Safari

Another interesting search in Kibana looks like the following. It says "Show me the events where PowerShell made a network connection." By browsing other logs in the same timeframe of the beacons, you find other possible indicators.

powershell.exe and event_id: 3

Which index do you think you should use for this query? Try out a couple, did you find anything interesting?

You may find something like (once the C2 channel was established) demonstrated below.

• This is a result of powershell making outbound connections (event_id:3_).
• In a typical environment, should PowerShell be behaving such as this?

Mitre ATT&CK Technique Mapping

Because the optics chain now includes active markup and processing during log ingestion, it is possible to leverae the pipeline's Mitre ATT&CK mapping feature. You can search for specific technique's that have resulted from sysmon genreated logs.

• T1086 – PowerShell
• T1218 – Signed Binary Proxy Execution

Look at the log results below. The process_name and RuleName are document attributes listed as table columns.

• How is this helpful for a blue team?
• Do you think the red team knew this behavior could be tracked like this?

ElastAlert Index

Remember that ElastAlert is monitoring what is being added into Elastic. It processes aggregate data in Helk and generates its own alerts based on its own signature criteria.

Change the log index to elastalert_status index.

Did ElastAlert alert of anything unusual?

• Remember ElastAlert is a method of grouping many logs together to make assumptions.
• When ElastAlert creates a document in Helk, it found something interesting that warrants review.

Once you have identified some potential IOC, we need to tear-down the C2 framework.

Shutdown Malware Stagers

Lets tear down that C2 framework! Once detection has been verified, close out both command terminals on the victim machine.

PowerShell Stager

Exit the PowerShell Malware stager

• CTRL + C may work to close the PowerShell stager.

CTRL+C

[*] Executing
sYJwhAelHQ CheckIn
        [-] 'System.Management.Automation.resources.dll' was required...

Next, lets look at closing the XML stager

XML Stager

The build process for the XML stager may not close with CTRL+C. If the CTRL + C fails to halt the process, close the session window.

CTRL+C

[*] Executing
z8DiGrOcG3 CheckIn
Attempting to cancel the build...
Project "c:\Users\itadmin\Downloads\stager.xml" on node 1 (default targets).
c:\Users\heather.butler\Downloads\stager.xml(3,5): warning MSB4220: Waiting for the currently executing task "AXHzw" to
 cancel.
c:\Users\heather.butler\Downloads\stager.xml(3,5): warning MSB4220: Waiting for the currently executing task "AXHzw" to
 cancel.
c:\Users\heather.butler\Downloads\stager.xml(3,5): warning MSB4220: Waiting for the currently executing task "AXHzw" to
 cancel.
c:\Users\heather.butler\Downloads\stager.xml(3,5): warning MSB4220: Waiting for the currently executing task "AXHzw" to
 cancel

Lastly, lets look at the remaining Putty session Windows.

Putty Sessions

Ensure all sessions are closed out, including sessions running nested with "screen". To do this, go to each putty terminal and use CTRL+C to return to a bash prompt. Then use "Exit" to exit from the session. If the putty window does not close, use "Exit" again (nested session).

CTRL+C
Exit
CTRL+Z

Reboot MemberServer WS01

The closing of all the session windows should stop all Beacon traffic. However, if this the malware did not exit, the continual beacons may obscure future attack and hunting efforts. The malware stagers are not persistent, therefore, reboot the MemberServer WS01 to eliminate the possibility of recurring malware beacon attempts from the C2 Framework.

Restart-Computer

After the system has rebooted, you are finished with this lab.