Carlos Perez – TrustedSec Research Practice Lead

Carlos Perez has been active in the security community since 1999

when he began working for the government of Puerto Rico, and he

now leads TrustedSec's research team. Carlos has presented at

many security events, including DEFCON, DerbyCon, Hack3rCon,

and BSides, and has both created and contributed to open-source

projects, such as Metasploit, DNSRecon, and Posh-SSH, among

others. For the past five years, Carlos has been awarded the

Microsoft MVP award for Data Center Management in the

specialties of Enterprise Security and PowerShell.

Strategic vs Tactical

• The focus of the series is a tactical one but we should not

forget the strategic purpose of the exercise.

• What are the areas we are testing?

• What are the targets of impact for the given scenario?

Post Exploitation

•Under what process

•What privilegesWhere and Who

•What AV/EDR/Firewall/SIEM

•Operating System ControlsIdentify Controls

•What is the role of the system

•Who uses the systemProfile System

•Health of host

•Methods to usePersistence

• Find and exfiltrate dataPilfering

•Get the lay of the land

• Find targets of interestNetwork Enumeration

•Operating System Credentials

•Application CredentialsCredential Harvesting

•Expand control of the target environment.Lateral Movement

PTES -Protect the Client

• All traffic and data at rest must be encrypted, secured, and destroyed after the engagement.

• Do not make changes that may impact performance or availability of any system.

• Don’t include sensitive data like hashes, passwords, personal information, or secret business information on reports.

• If evidence of a prior compromise is found, the engagement stops. Ensure that it is in the SOW.

PTES-Protect Yourself

• Ensure you have a properly signed SOW with ROEs (Rules of

Engagement) agreed to and signed before starting.

• Log and document all actions and the time they are taken.

• Make sure you checked that they have an 'Acceptable

Use' policy, and if not, be careful with what data is pulled and

leveraged on the system.

• Have a communication plan, if it does not work, ensure that

you can change it.

Where and Who

Where and Who

• After landing on a system, we must now understand what

process we are working under.

• We must know what our initial set of privileges are.

• Confirm the type of version of the Operating System.

• Reasons:

– Avoid trying to run tools not available to the system.

– Prevent taking action for which we do not have privilege and

expose ourselves.

Where and Who

• In Cobalt Strike, the User Interface will show if you are

running under a Admin token by putting a * beside the

user name and changing the icon of the host:

Where and Who

• We can pull in Cobalt Strike with the reg command a

more detailed Windows version:

reg query x86 HKLM\Software\Microsoft\Windows NT\CurrentVersion ProductName

Where and Who

• Metasploit Meterpreter has the sysinfo command to pull

info on the Operating System, language, Domain, logged

on users, and general version of Windows:

Where and Who

• Cobalt Strike, when interfacing with the Beacon, will show

the NetBIOs name and PID at the top.

• getuid will tell us under what user context we are running:

Where and Who

• In Meterpreter the getuid command will provide

information on the user the payload is running under:

Where and Who

• A better option is to use the post module

post/windows/gather/win_privs, since it includes information of

what current privilages and permission the payload is running

under:

Tip

• When using Metasploit modules, ensure that they are

performing action that may get you caught. When you

load a module use the edit command after loading to look

at the source code.

• The pentest plugin provides the check_footprint

command to check modules for possible dangerous

actions.

Tip

The Pentest Plugin can aid you with knowing the

hidden TTP cost:

Where and Who

• We can pull in Meterpreter with the reg command a more

detailed Windows version:

reg queryval -k "HKLM\Software\Microsoft\Windows NT\CurrentVersion" -v ProductName

Where and Who

On Linux and Mac Operating Systems with Metasploit

Mettle Meterpreter payloads the commands are the same

as in Windows:

Where and Who

Where and Who

• On most distribution we can determine the name by

checking /etc/*-release and /etc/*-version:

Where and Who - Summary

• Many times, when we land on a host, we have little to no

knowledge of the Operating System we landed and its

capabilities.

• The host environment, where in the process tree and

what privilege will dictate our tooling and actions.

• Without knowledge of controls until enumerate initial

actions should be following the strangest of OPSEC.

Identify Controls

• Identify controls before further actions to prevent detection and/or loss of session

• Controls to look for:– Endpoint Detection and Protection

– Anti Virus/Malware

– Controls on Scripting Environments (WSH, PowerShell)

– Execution Controls:• AppLocker/Windows Defender Application Control

• Auditing:– Process Auditing

– SIEM/Event Collection

Identify Controls

• We need to identify controls by leveraging initially native APIs when possible.

• Most payloads support:– Listing Processes – any process name that matches known

security control software or tools that pose risk

– Listing Files• On Windows, check for known drivers of security vendors and applications

under program files.

• Linux/Mac Operating Systems, check for presence and size of log files for auditing

– List Services – On Windows if Registry or ServiceControl API is used. (Don’t Run sc.exe, reg.exe or net start)

Identify Controls

• Once a control is identified, we should see if we can pull

the configuration:

– Firewall – Open Ports, Executables Allowed

– AntiVirus – Exclusions, management server, and additional

features

– Execution Controls what is actually blocks and exceptions

Identify Controls

• Aggressor script EDR.cna and ProcessColor.cna from

harleyQu1nn is a great safe start since it only uses in-

memory APIS to list files and match on those

• Aggressor script ProcessTree.cna from ars3n11

identifies EDR/AV, Admin tools, and other interesting

processes

https://github.com/harleyQu1nn/AggressorScripts/blob/master/EDR.cna

https://github.com/ars3n11/Aggressor-Scripts

Identify Controls

– EDR.cna:

Identify Controls

– ProcessTree.cna:

Identify Controls

• For Metasploit, the post module from Carlos Perez

enum_securitycenter uses in memory WMI:

https://github.com/darkoperator/Meterpreter-Scripts/blob/master/post/windows/gather/enum_securitycenter.rb

Identify Controls

• In Metasploit, we can use the post module post/windows/gather/enum_applications to enumerate installed applications via the registry uninstall key using OPSEC safe API to enumerate the key.

• In Cobalt Strike, the registry API does not allow for callback, and enumerating each key by hand is not possible unless a .Net or reflective DLL is created. An alternative would be listing C:\Program Files and C:\Program Files (x86) folders.

Identify Controls

Tip

• Both Cobalt Strike and Metasploit allow for the listing of

processes. Check to ensure that no process was missed

by any of the tools.

• Fork and keep improving on existing detections and

expand their coverage.

• For aggressor scripts, check that they are not leveraging

PowerShell since a defender with a mature blue team will

quickly notice its actions.

Identify Controls - OS

• The first Operating System control one should check for is Process Auditing.

– Windows: Process Auditing with WEF

– Linux: Auditd with Syslogd

– Mac OS: OpenBSM with Syslogd

• These audit controls are protected by permissions so from enumeration by none privileged users.

• As an unprivileged user, we can determine if they are enabled.

Identify Controls - Windows

• On Windows:

– Process Auditing as a privileged user can be checked by using

the command auditpol/list. If enabled, the action of checking

will be logged.

– Meterpreter allows for the execution of a PE file in memory and

auditpol it self can be ran or another program like GetAufitPol:

https://github.com/darkoperator/GetAuditPol

execute -H -i -c -m -d calc.exe -f /tmp/GetAuditPol.exe -a -w

Identify Controls - Windows

• On Windows:

– Any good organization will log the full command line. This was enabled on latest versions of Windows and added to 2007/2008 with KB30004375.

– The registry key is readable by any use: • Key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit

• Property: ProcessCreationIncludeCmdLine_Enabled

– If the key is present with a value of one more than likely, process auditing is enabled.

Identify Controls - Windows

• On Windows:

– Both Cobalt Strike Beacon and Meterpreter have commands to query the registry that can be used.

– For WEF, best practice is to have clients push to the collector (WEC Server) checking registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager

– For Meterpreter, post module named check_event_forwarding will enumerate subscriptions on the client: https://github.com/darkoperator/Meterpreter-Scripts/tree/master/post/windows/gather

Identify Controls - Linux

• On Linux:

– Auditing of processes is done by the Audit Daemon, it is not installed by default.

– The presence of auditd and syslogd processes is enough to confirm in most cases that auditing is enabled and logs are being shipped off system.

– A more popular alternative is OSQuer: https://github.com/facebook/osquery

• OSQuery and auditd can not be running at the same time.

• osqueryd is the daemon process for it.

Identify Controls – Mac Operating System

• On MacOS:

– OpenBSM is used for process auditing.

– As of 10.6.x it is enabled by default but does not log process

execution (exec flag). It is extremely rare to see it used in the

real world.

– A more popular alternative is OSQuery:

https://github.com/facebook/osquery

• OSQuery hooks OpenBSM /dev/auditpipe to gather event information.

• osqueryd is the daemon process for it.

Identify Controls – Windows PowerShell

• Why?

– It has become very popular in the last couple of years.

– The Windows PowerShell teams have invested a lot to mitigate

the abuse of it.

– Cobalt Strike and Metasploit leverage Windows PowerShell,

other tools are more heavily dependent on it.

Identify Controls – Windows PowerShell

• What?

– The two mains controls against successfully leveraging PowerShell are:

• Logging both Transcript and ScriptBlock

• Availability of the PowerShell v2 engine

– Application Whitelisting does enforce greater controls when AppLocker or Windows Defender Application Control (Device Guard), but it is rarely seen do its complexity of management.

– The simple use of PowerShell leaves artifacts in the logs but many organizations do not even look at them.

Identify Controls – Windows PowerShell

• Microsoft extended the amount of logging information that can

be captured in PowerShell 4.0 (8.1 and 2012 R2 with KB

3000850) and 5.0.

• It will log more information on each PowerShell command ran

and it will also log any script block it sees for the first time

catching any code either ran on the console, ISE, or as a

parameter to PowerShell.exe.

• Under Microsoft-Windows-PowerShell/Operational all event

will have the Process ID and Thread ID for the session.

Identify Controls – Windows PowerShell

• ScriptBlock Logging is controlled by

– Path: HKLM\Software\Policies\Microsoft\Windows\PowerShell\Scrip tBlockLogging

– Value: RegDword EnableScriptBlockLogging set to '1' to enable

• Transcript Logging is controlled by

– Path: HKLM:\Software\Policies\Microsoft\Windows\PowerShell\Tran scription"

– Value: RegDword EnableTranscripting set to '1' to enable

– Value: RegDword OutputDirectory set to '1' to enable

– Value: RegDword EnableInvocationHeader set to '1' to enable

Identify Controls – Windows PowerShell

• Event will be saved in Applications and Service Logs/Microsoft/Windows/PowerShell/Operational

– Executing Pipeline - Event ID 4103, will provide the Runspace ID and will let you know how the Runspace was started and its parameters.

– Starting Command - Event ID 4104, provides the first time the code has been seen since the computer rebooted and the ScriptBlock ID for tracking execution.

– Starting/Stopping Command - Event ID 4105 (Starting Scriptblock) and 4106 (Completing Scriptblock) each will include the ScriptBlockID and RunSpace ID

Identify Controls – Windows PowerShell

• In PowerShell v5.0 > Microsoft added a series of check on

ScriptBlocks looking for specific strings and on any match a event

is recorded.

• Events are recorded in Microsoft-Windows-

PowerShell/Operational with the Event ID of 4104 with Level of

Warning (3) with the ScriptBlock that matched the strings that

Microsoft has in their list.

[ScriptBlock].GetField('signatures','NonPublic,Static').GetValue($null) | sort

Identify Controls – Windows PowerShell

• Easy to bypass by applying just a bit of obfuscation to the

string:

Identify Controls – Windows PowerShell

• By using the PowerShell v2 engine will bypass:

– Module Logging

– Transcript Logging

– ScriptBlock Logging

• PowerPick and Meterpreter PowerShell Extension use the

v2 engine by default.

• On Windows 10 Creators edition and above it is no longer

installed by default on a clean installed.

Identify Controls – Windows PowerShell

• For ScriptBlock Warning logs one can set the list of

strings to NULL …☺ Yes, it is that simple.

• In https://github.com/darkoperator/Metasploit-Plugins the

enum_ps_env post module will check what logging is

enabled and if the PSv2 Engine is installed or not on more

modern versions of Windows.

[ScriptBlock]."GetFiel`d"('signatures','N'+'onPublic,Static') .SetValue($null,(New-Object Collections.Generic.HashSet[string]))

Identify Controls – Windows PowerShell

Identify Controls – Summary

• We only covered a small subset of controls that one needs to check.

• Every EDR/AV host product is constantly being updated and so should our checks and setting enumerations for them.

• With the constant release of Windows 10 versions Microsoft keeps enhancing logging and adding new controls, ensure to check release notes and add coverage.

Next webinars:

January 30th at 1PM EST

February 20th at 1PM EST

March 6th at 1PM EST

¿Questions?