L1150-Blue Pass The Hash - CrackMacExec

• EventID 4624
  • Login to Member Server (WS01)
  • Access Kibana on the (H)ELK SIEM
  • Begin the hunt:
  • More hunting
  • Yet More Hunting Chaos
• ElastAlert

Using Kibana and ElastAlert, find IOC's for the PassTheHash attack

By starting with a search during the time-frame and knowledge of event-ids, being hunting for evidence of a pass the hash attack.

Utilize the threat-optics tool set and skills learned to define an IOC for pass-the-hash attacks.

EventID 4624

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
Username: helk
Password: hunting

Begin the hunt:

The first thing to look for is a logon event that includes the itadmin account. Because the event was generated by the initial pass-the-hash attack, the search terms are apparent.

event_id: 4624 and itadmin

Catching this specific attack can be a challenge. To find this attack, toggle the following fields as columns.

• logon_process_name
• src_ip_addr
• user_name
• user_reporter_sid

Continue hunting; based on the results, this Elastic query and filter set produce reasonable results that tend to identify potential pass-the-hash attacks.

event_id: 4624 and logon_type: 3 and user_reporter_sid: "s-1-0-0" and logon_process_name: ntlmssp

Save this query for future use if desired.

More hunting

Let's investigate this further. As shown below, we can generate and review other authentication types and the combinations of reported items we see during authentication.

Start by adding columns of interest to the Kibana results table.

• Shown below are event_id, logon_process_name, logon_type, user_name, and user_reporter_sid.
• Two different authentication events generated the following logs:
  • first (at the bottom), an RDP session to the DC was created and we see what appeared to be a normal user32 logon_type 10 (RemoteInteractive).
  • The next set of authentication events were the result of the itadmin user browsing the C:\Labs share. These were reported as logon_type 3 (Network – usually file shares).

Finally, to validate what we believe about the pass-the-hash, the following events were reported when authentication events originated from CrackMapExec.

We should be suspicious of the NTLM security service provider. As shown, when combined the network logon, and user_reporter_sid of S-1-0-0 (NULL / NOBODY), we have a potentially compromised account. Below, we add the src_ip field and prove that these are high fidelity queries to identify pass the hash attacks.

Next, let's investigate the ElastAlert_status index and see if any SIGMA alerts have triggered on this behavior. As we have learned, much of the malicious behavior performed on the network has generated spikes in events. In this case, there was a potential spike in events. Though, when looking at our rule matching dashboard, it is clear something triggered a flood of matches.

Drilling down through time analysis and choosing the rule_name field, we should find something like the following. The DC sync and NTDS operation we performed with CrackMapExec matched against several noteable rules.

Yet More Hunting Chaos

What else can we determine about how a Pass-The-Hash attack works?

event_id: 4624
logon_process_name: ntlmssp
user_report_sid: S-1-0-0
logon_type: 3

Save this query for future use if desired. When the query results appear similar, the lab is complete.

ElastAlert

Switch the Kibana index source to elastalert_status. You might also note the applied filter (NOT rule_name: Rule). The Nishang PowerShell rule triggers often.

After filtering some of the noise, we can find interesting happenings in the ElastAlert_status index. As shown in the next screenshot, after dumping the domain’s NTDS, enough evidence was dumped via our logging optics in to ElasticSearch. ElastAlert does not act on live data ingests, rather on definable time windows against the Elastic database. Something you definitely want to catch is a DCSync from a non-DC.