Incident Response - PowerShell Hunting

Use PowerShell to Remote Into a Machine for Investigation as an Alternative to RDP, to Protect from the Threat of Credential Theft by the Attacker when Remoting Into a Machine for Investigation

Incident Response Process:

• Preparation
• Detection and analysis
• Containment, eradication, recovery
• Post incident activity, including reporting and communication with stakeholders

Incident response process courtesy of NIST (US National Institute for Standards and Technology):

NIST computer security incident handling guide

Why PowerShell?

• Gives ability to dive deep into the system.
• PowerShell gives the ability to automate this process across scale.
• PowerShell is a secure remoting protocol

Enable PowerShell Remoting

Follow the steps illustrated in the series of snapshots below to enable PowerShell remoting on your home network or any other network or machine that is not part of a domain or Active Directory...

PowerShell remoting uses port 5985 for http and 5986 for https, and should be used to look into...

• Process list and loaded DLL’s….
• Running services
• Scheduled tasks
• Network connections…
• Non-volatile data(reg,mft etc)
• Windows event logs(.evtx files)
• Installed apps

The following code is an example of a script that can be run in a remote session to get the parent process of a running process using a WMI object.

What to hunt for?

• Commands for command prompt CLI (cmd.exe etc) although this is suspicious and almost certainly will be flagged by ML tool
• Command and control (C2) servers or other functional URL's
• Registry entries
• printf* strings
• API's
• Processes, mutexes, file paths, passwords, keys, and PowerShell commands
• Malware disguised as svchost(which should only be run by services.exe)
• Unknown or unsigned DLL/s
• Memory/dll injection
• Suspicious services
• Scheduled tasks
• Non whitelisted or unknown domains




Keep following me on social media to stay tuned for the follow up to this post...