v4.7/v4.6 Posh_v2_xxx.dll payloads crash with 0xc0000005 about poshc2

[benpturner]

[benpturner]

Hi, I just ran the v2 and v4 DLL and this seemed to work. Are you sure Microsoft.NET v2 is installed on the host you are running this from?
Can you dir this directory: C:\Windows\Microsoft.NET\Framework\v2.0.50727

[jmhickman]

I'm super confused now.
So on my test machine, that directory exists, but simply contains a 'CONFIG' directory.
So I'm like, 'okay, my test laptop doesn't have it.' But I look in my domain lab machines, and they don't have anything else in that v2.x.xxx directory either.
What I can't wrap my head around is that I've literally been using the v2_x64.dll payload for months on these domain lab systems. I've never had an issue running them. Did they change substantively from version 4.1 (which is what I've been using during my documentation and writing project) ?

[jmhickman]

Looking in my backed up 4.1 project directory, I see the following:

drwxr-xr-x 2 root root   4096 Sep 27 21:05 ./
drwxr-xr-x 5 root root    156 Feb  1 06:17 ../
-rw-r--r-- 1 root root  67980 Sep 27 21:05 aes.py
-rw-r--r-- 1 root root   5241 Sep 27 21:05 cs_sct.xml
-rw-r--r-- 1 root root   5230 Sep 27 21:05 Launcher.hta
-rw-r--r-- 1 root root   7357 Sep 27 21:05 macro.txt
-rw-r--r-- 1 root root 310190 Sep 27 21:05 msbuild.xml
-rw-r--r-- 1 root root   5119 Sep 27 21:05 payload.bat
-rw-r--r-- 1 root root   2739 Sep 27 21:05 payload.txt
-rw-r--r-- 1 root root 457878 Sep 27 21:05 Posh32.c
-rwxr-xr-x 1 root root 465507 Sep 27 21:05 Posh32.exe*
-rw-r--r-- 1 root root 457783 Sep 27 21:05 Posh32_migrate.c
-rwxr-xr-x 1 root root 465507 Sep 27 21:05 Posh32_migrate.exe*
-rw-r--r-- 1 root root 547682 Sep 27 21:05 Posh64.c
-rwxr-xr-x 1 root root 512586 Sep 27 21:05 Posh64.exe*
-rw-r--r-- 1 root root 547587 Sep 27 21:05 Posh64_migrate.c
-rwxr-xr-x 1 root root 512586 Sep 27 21:05 Posh64_migrate.exe*
-rw-r--r-- 1 root root   8629 Sep 27 21:05 Posh.cs
-rw-r--r-- 1 root root 126046 Sep 27 21:05 Posh-shellcode_x64.bin
-rw-r--r-- 1 root root 105322 Sep 27 21:05 Posh-shellcode_x86.bin
-rw-r--r-- 1 root root 124928 Sep 27 21:05 Posh_v2_x64.dll <---------------
-rw-r--r-- 1 root root 126046 Sep 27 21:05 Posh_v2_x64_Shellcode.bin
-rw-r--r-- 1 root root 104448 Sep 27 21:05 Posh_v2_x86.dll
-rw-r--r-- 1 root root 105322 Sep 27 21:05 Posh_v2_x86_Shellcode.bin
-rw-r--r-- 1 root root 124928 Sep 27 21:05 Posh_v4_x64.dll <---------------
-rw-r--r-- 1 root root 104448 Sep 27 21:05 Posh_v4_x86.dll
-rw-r--r-- 1 root root   1983 Sep 27 21:05 py_dropper.py
-rw-r--r-- 1 root root   5421 Sep 27 21:05 rg_sct.xml

Matching filesizes, however the sha1sums don't match between them.
Did I hit some sort of payload generation issue that effectively made v4 payloads but called them v2?

[benpturner]

I dont believe they have changed at all, but we did make some modifications in the DLL to optimise the code. If you run v4 and they fail it will try v2 but looking in the DLL code if you try v2 and that fails it doesnt fall back to v4. This may have changed, which would make sense. When you run the old ones in that directory, does it fall back to v4 of the CLR

[benpturner]

[benpturner]

The reason behind this, was because most people would run v2 of the CLR to bypass any Powershell 5 logging and monitoring and therefore if v2 doesn't exist its probably an OPSEC failure to just load v4 of the CLR blindly. Its up for discussion of course, but thats my view on the best approach.

[jmhickman]

Yeah, the opsec concern makes that decision pretty straightforward, imo.
I'm just trying to figure out what on earth implant I was actually running in the end.
If I decide to enable that my old 4.1 container, is there a command I could enter that would show me what dotnet I was running on the implant's host? I'm familiar with the powershell version command already, not sure I ever ran it though.
I figure that AMSI wasn't working. I never ran the 'unhook-amsi' command (unless the v4 dll does that automatically), but stuff like invoke-mimikatz imported and ran without issues, which definitely doesn't happen when AMSI is watching.

[jmhickman]

I bet I'm just conflating the .net version with the PS version. I assume that, if PowerShell v2 is present on the host, the .Net v4 dll will still use that as the shell I interact with? That would explain what I've seen, but I would still like to check my assumption.

[jmhickman]

PS C:\Users\jhick> powershell.exe -ver 2
Version v2.0.50727 of the .NET Framework is not installed and it is required to run version 2 of Windows PowerShell.

Guess that's a no.

[benpturner]

Guess not :D

[jmhickman]

So, just to show I'm not crazy. With my old 4.1 install, running the Posh_v2_x64.dll from the payloads directory:

New Normal implant connected: (uri=c2Y3WwxdCfMlTu1 key=Yjio6Skc/ybA5O/QCqtCJ5LyDpDICWUmt/1xXlrZHjc=)
10.1.1.1:45916 | Time:02/12/2019 08:04:34 | PID:11344 | Sleep:5 | 0METALAB\userguyone (AMD64) | URL:https://192.168.10.3:443

Command issued against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:04:39)
loadmodule Implant-Core.ps1

Command returned against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:04:40)
Module loaded sucessfully

64bit implant running on 64bit machine

[+] Powershell version 5 detected. Run Inject-Shellcode with the v2 Shellcode
[+] Warning AMSI, Constrained Mode, ScriptBlock/Module Logging could be enabled

Command issued against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:05:56)
$PSversiontable

Command returned against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:05:56)


Name                           Value
----                           -----
PSVersion                      5.1.17134.407
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17134.407
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Command issued against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:06:27)
'amsiScanBuffer'

Command returned against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:06:27)

amsiScanBuffer

Typing that string into a pshell prompt on that host gives the expected angry Defender message and behavior.
So is it safe to say that the v4 fallback blocker was not a feature in the 4.1 payloads then?

What accounts for the AMSI behavior? It should be hooked in, and it isn't.

Command issued against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:17:59)
Get-Process | Where-Object { ($_.Modules).ModuleName -Contains 'amsi.dll' }

Command returned against implant 189 on host BETA 0METALAB\userguyone (02/12/2019 08:18:02)


Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    734      35    65004      72216       0.86  11784   4 powershell

That's the powershell process I launched the payload from. PID of my implant is, as above, 11344. I didn't explicitly run any amsi bypass, and my list-autorun comes back empty.