According to almost every cyber security vendor, the biggest trend in the last few years is the use of Non-Malware attacks. Scripting languages are becoming more prominent than before—a few lines of PowerShell code can be used as a full hacking toolkit, open source hacking frameworks based on PowerShell and Python are easily accessible, and the bad guys are taking advantage of the “new reality” we’re living in.

Take, for example, these posts from Symantec, Carbon Black, Securelist and Threatpost about the trend of Non-Malware attacks.

There are a few reasons why we see increased use of scripting language based malwares:

  • 1. Some of them are installed by default on every Windows operating system.
  • 2. They’re hard to detect because they leverage legitimate tools to perform malicious activity.
  • 3. Shell-based attacks have the ability to exist only in memory.


Since Windows 7 and above, the conhost.exe process is responsible for each opened instance of command-line consoles. For each newly opened console shell, a new conhost process is opened as well. So dumping the content of the conhost process can carve us the actual input and output of each command-line application, such as PowerShell, CMD, Python, Wscript, and more.

New conhost process opened for each console shell








Until now, the most common way to investigate shells during forensics investigation was using the CMDSCAN and CONSOLES modules in rekall and Volatility frameworks—but they don’t always extract all of the data available inside the memory section of the conhost process. Additionally, executing memory analysis using these tools is usually slow as it needs full memory dump, whereas another faster and more scalable solution might be desirable.

Hey Rekall, I need the results now!










Investigating command-line console is most effective when running it immediately after the console was opened because most of the volatile data still resides in the memory. That’s why an easy and fast Powershell-based tool will be the best choice for your automated IR arsenal.

We created a PowerShell-based script called Get-ShellContent, leveraging a modified Strings2 tool loaded in-memory, to extract all the strings of any running or dumped process. This script is parsing and distilling the input and output of the investigated shell. You’ll get full visibility into the screen buffer the attacker used, the commands he wrote, and the results he received—Incident Response Forensics at its best!












This small script runs in-memory, so no additional files are necessary to execute the tool. It offers a fast, accurate, and scalable method to investigate remote and local shells without any hustle—the cleanest methodology as possible. (Note: remote capabilities require WinRM.)

So far, the tools extracted the content of the following command-line shells: PowerShell, CMD, Python, Wscript, MySQL Client, and some custom shells such as Mimikatz console. In some cases, the tools might be helpful to extract encrypted shells like the one used in PowerShell Empire Agent. You can point the script straight to the shell process instead of the conhost process, or use the –Deep flag.

Introducing Get-ShellContent v1.0, supporting PowerShell v2.0 and above, with remote WinRM capabilities.

  • * Use –ComputerName [TARGET] to analyze shells on remote target endpoint.
  • * Use –ProcDump [DumpPath] to analyze Process Dump (Conhost or Shell) file.
  • * Use –Deep to scan the actual process of the shell for any remaining data (You’ll get FP).
  • * Use –ProcessID [PID] to analyze specific (Conhost or Shell) process; don’t use the flag if you want to scan all the processes automatically.

Download the script from our github:


[gs_lp_like_post] 0