Bypassing Cylance: Part 3 – Netcat & Nishang ICMP C2 Channel
The following techniques serve to illustrate methods for obtaining C2 communication in a particular Cylance protected environment. The configuration of the centralized infrastructure and the endpoint agents were not inspected prior to testing. The environment may exhibit configuration errors and may not conform with best practice for deployment of Cylance infrastructure. However, in our experience, misconfiguration is not uncommon and more times than not tends to have catastrophic results with regard to the overall security posture of an environment. This is the reason that we test deployments before accepting their stated protection levels at face value. In addition, these posts serve to illustrate the necessity for defense-in-depth. In each instance where C2 establishment was successful, a secondary or tertiary control could have (and should have) compensated for the failure of the initial control. Layered defense is a critical element of protection in any environment and organizations must face the fact that there is no silver bullet for information security. See part one, bypassing with SVAgent here and part two about bypassing with DNSCat2 here.
Netcat
The third C2 method that went undetected by Cylance was raw netcat. In this case, the listener was a raw netcat shell shoveled outbound. The netcat executable was downloaded to the target host and executed as seen below.
On the C2 server, netcat was configured to listen on this port for inbound communication. Upon connection from the end host, a Windows shell was returned.
A smart attacker might upload the Nmap port of netcat, named Ncat, which support TLS encryption. This would make the C2 channel all the more difficult to detect.
Unlike the previous C2 channels, raw netcat C2 does not conform with a specific protocol. In addition to the prior recommendations of filtering downloads and application whitelisting, this communication can be defeated through protocol inspection. If the boundary firewall supports application-level proxies that check for protocol conformance this traffic will be dropped.
Nishang ICMP C2 Channel
The final non-traditional method of C2 that went undetected by Cylance was communication using ICMP payloads. In this case, the PowerShell script Invoke-PowerShellIcmp.ps1 from the Nishang framework was used.
Investigating the deployed configuration of Cylance revealed that it was configured to prevent execution of any content through the native PowerShell.exe interpreter.
However, the PowerShell ISE was available on this host. As a result, the script could be loaded into the ISE and its functions exposed by either clicking the play button or using the familiar import-module syntax. In this instance, the play button was used.
Once the PowerShell script was loaded, it was invoked as seen below.
The waiting C2 server caught the callback from the client granting shoveled shell access to the target computer.
In this case, the organization can make a decision regarding ICMP in general. If users don’t need to ping hosts on the internet, the organization can simply drop all outbound ICMP messages from internal hosts.
While PowerShell ISE worked fine for this script, it should be noted that any script that includes embedded calls to the native PowerShell interpreter should be avoided. In addition, multi-threaded scripts may exhibit this same issue if the native interpreter is referenced.
The following PowerShell scripts were found to work when launched through the PowerShell ISE.
DomainPasswordSpray.ps1
Invoke-Kerberoast.ps1
Invoke-PowerShellICMP.ps1
PowerView.ps1
PowerUp.ps1
The CylancePROTECT script control module only blocked calls to the native interpreter.
Access to both cmd.exe and PowerShell_ise.exe should be restricted in the same fashion seen for PowerShell.exe. Both of these tools provide enormous capability to an attacker for pivoting within an environment.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
