5 - Domain Delving #

Given the output of their process, it looks like the actor was after domain credentials! What could they have done with them?

To begin with we are still looking at corp-webdev.alien.local for what the adversary did next. Having gained access and privileged accounts, we’ll want to know what their next steps were and see where else they were able to get about the network. There are a few artefacts to review in this one, and a few different ways to do it, scheduled tasks, event logs, file creation and deletion, and some PowerShell to review. In this section you need to think a little bit bigger than the original evidence that we have already parsed or looked at. Pulling apart adversarial scripts and command lines can help tell us loads of the story and then point us to the right next place to look.

This section also has us starting to look at corp-dc as we see the adversary expanding their footprint.

Google is your friend, don’t expect that you will know all the Windows event log IDs, or potentially every possible attack. Googling some of the clues may point you in the right direction and give you more artefacts or things to look for to verify that’s actually what has occurred.

TA008 - Lateral Movement consists of techniques that adversaries use to enter and control remote systems on a network. Following through on their primary objective often requires exploring the network to find their target and subsequently gaining access to it. Reaching their objective often involves pivoting through multiple systems and accounts to gain. Adversaries might install their own remote access tools to accomplish Lateral Movement or use legitimate credentials with native network and operating system tools, which may be stealthier.

To complete this section I have used the following tools:

• MFT output spreadsheet
• Autopsy - ParseEVTX Python Ingest Module.

Note: See this page for tool set up and explanations.

DD-1 #

Using the parsed MFT output we can see the creation of the file “psmap.zip” in the SysInternals folder. Checking under the created column we get our answer.

DD-2 #

The screenshot from PE-6 shows another scheduled task created - Windows YUpdate. Once again we’ll grab the file from “..\ACSC_IR_Challenge_2021\artefacts\corp-webdev.alien.local\C\Windows\System32\Tasks” and open it in notepad to review what was executed.

  <RegistrationInfo>
    <Date>2021-04-01T05:10:54</Date>
    <Author>IIS APPPOOL\alien</Author>
    <URI>\Windows YUPdate</URI>
  </RegistrationInfo>
  <Triggers>
    <CalendarTrigger>
      <StartBoundary>2021-04-01T05:12:00</StartBoundary>
      <Enabled>true</Enabled>
      <ScheduleByDay>
        <DaysInterval>1</DaysInterval>
      </ScheduleByDay>
    </CalendarTrigger>
  </Triggers>
  ---
   <Exec>
      <Command>powershell</Command>
      <Arguments>-inputformat none -NonInteractive -Command Add-MpPreference -ExclusionPath "c:\sysinternals"</Arguments>
    </Exec>

We’ll go back to the Task Scheduler event log - Microsoft-Windows-TaskScheduler%4Operational.evtx to review the chain of events we can see after the registration date of the task (above):

• 1/04/2021 5:10:54 AM - Task registered - User "alien_db" updated Task Scheduler task "\Windows YUPdate"
• 1/04/2021 5:12:00 AM - Task triggered on scheduler - Task Scheduler launched "{6cf06a5d-da7c-47f2-af45-2eb6eacdf773}" instance of task "\Windows YUPdate" due to a time trigger condition.
• 1/04/2021 5:12:00 AM - Created Task Process - Task Scheduler launch task "\Windows YUPdate" , instance "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.EXE" with process ID 1312.
• 1/04/2021 5:12:00 AM - Task Started - Task Scheduler started "{6cf06a5d-da7c-47f2-af45-2eb6eacdf773}" instance of the "\Windows YUPdate" task for user "CORP-WEBDEV\alien_db".
• 1/04/2021 5:12:00 AM - Task Completed - Task Scheduler successfully finished "{6cf06a5d-da7c-47f2-af45-2eb6eacdf773}" instance of the "\Windows YUPdate" task for user "CORP-WEBDEV\alien_db".

We can also break down the PowerShell command that was set to run:

Give that the question is looking for a configuration change, the date and time when the schedule task completed and updated the Windows defender configuration would be the likely flag. So we’ll look at the defender eventlog - Microsoft-Windows-Windows Defender%4Operational.evtx. I have just reviewed this in notepad, but you could also run ParseEvtx to add this log to the timeline window in Autopsy (and why not add the Task operational log too).

Building out a timeline of activity can be immensely helpful in identifying any gaps in attacker activity, and also the time frame of the attack. In the screenshot above, its nice to be able to see the task scheduler logs and then the order of events leading up to the configuration change at 05:12:01, which is our flag.

M-5 #

Can find this in the MFT for the created date and time.

DD-3 #

• We know the lsass was dumped at 03:35:00 to disk, so the attacker would have been able to get the credentials and start lateral movement after this time.

  

• “4648: A logon was attempted using explicit credentials - This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.”

DD-4 #

The event log we looked at above (ID:4648) shows us an attempt. At 05:44:26 there is another 4648 event recorded attempting to access the file server. Presumably it will be one of these hosts.

Given they are connecting via SMB, lets parse the Microsoft-Windows-SmbClient%4Connectivity.evtx and Microsoft-Windows-SmbClient%4Security.evtx eventlogs and see what they tell us.

In our event log timeline we see the Event ID 30803 and the target system 10.1.1.226 (corp-file.alien.local) : This indicates a problem with the underlying network or transport, such as with TCP/IP, and not with SMB. A firewall that blocks TCP port 445, or TCP port 5445 when using an iWARP RDMA adapter, can also cause this issue.

Supporting this is Event ID 31010: The SMB client failed to connect to the share.

DD-5 #

From DD-4 we saw that they attempted to access corp-file as well as corp-dc. At this point I’ll add corp-dc as a data source into Autopsy and also run the eventlog parser, as well as use MFTEcmd.exe to create an MFT output.

MFTECmd.exe -f "`$MFT" --csv yourlocation\artefacts\corp-dc.alien.local\dc\Collection-corp-dc.alien.local-2021-04-06_02_12_12__0000_GMT\C --csvf corp-dc-mft.csv

Reviewing the eventlogs in Autopsy for corp-dc, we come across an item in the system event log - Event ID 7045: A new service was installed in the system.

PsExec is a tool included in the Sysinternals Suite created by Mark Russinovich. Originally, it was intended as a convenience tool for system administrators so they could perform maintenance tasks by running commands on remote hosts. By providing the address of a target host, a valid user and a password, you can get control of a machine remotely. When psexec is used to run something on a remote system, it works by creating a new service executable called psexesvc.exe and runs the desired command.

DD-6 #

Knowing that there was “some output”, I looked at the MFT output to see if I could see a likely file, and something did jump out at me … ad.zip in the C:\temp directory. So filtering on the ParentPath .\temp I now have a good starting place and an idea of what has happened.

There are two directories that were created during our attacker access, Active Directory and registry, containing ntds.jfm and ntds.dit, and SYSTEM and SECURITY files respectively. If you arent sure what is going on by this stage, its a good amount of information to turn to google to get some clues.

The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain.

Utilising the inbuilt tool ‘Ntdsutil’, the ntds.dit file and the system registry file can be copied to a location of choice, and utilising those two files password cracking can be conducted offline. This post outlines the commands and the summary very well.

I then did a keyword search in Autopsy across the event logs and found the following event confirming the use of ntdsutil and gives us the exact location: C:\Windows\System32\ntdsutil.exe.

Reviewing the event log timeline in Autopsy you can see multiple events related to the use of ntdsutil and the output directories and when the PSEXECSVC completed.

For more information and context on this style of attack:

• extracting-password-hashes-from-the-ntds-dit-file
• Ntdsutil
• OS Credential Dumping: NTDS

DD-7 #

What we know so far:

• They had previously tried and failed to access the corp-file system.
• From looking at the MFT items, ad.zip was created on disk at 06:01:30.
• We have a clue about which system to check and also a time frame.
• We also know that EventID 4648 showed us the attempts made to access the system from corp-webdev using SMB.

Time to add corp-file.alien.local artefacts to the Autopsy case and parse the Eventlogs (I’ll also parse the MFT at the same time).

From our Autopsy event log table:

• 2021-04-01 06:18:00 - SMB access attempt from corp-webdev to corp-file using account admin

• 2021-04-01 06:18:00 - EventID 4625 (An account failed to log on) in corp-file security event log.

• 2021-04-01 06:18:53 - SMB access attempt from corp-webdev to corp-file using account re_bmilton

• 2021-04-01 06:18:53 - EventID 4624 (An account was successfully logged on) in corp-file security event log.

  

DD-8 #

This is a bit of a tricky one. We need to remember that the attacker has been staging their attack from corp-webdev and the access to the file server was over SMB. If we take a look at the MFT output from corp-webdev for this timeframe we’ll see a file in the Windows\Temp directory called filedir.txt created at 2021-04-01 6:19:19.