unpack requires a string argument of length 4

[bouligo]

When executing the python code generated by client.py, I have the following flooding output :

DEBUG:__main__:recv_task error: unpack requires a string argument of length 4

I generated 2 different client scripts through the following commands (problem occurs with both scripts) :

./client.py --encrypt --compress W.X.Y.Z 80
./client.py W.X.Y.Z 80

I ran the server with

./server.py --port 80

Here is the complete output from the client :

DEBUG:__main__:[*] Searching http://W.X.Y.Z:81
DEBUG:__main__:[+] Adding escalate
DEBUG:__main__:[+] Adding icloud
.....
  "modules": [
    "escalate", 
    "icloud", 
.....
    "util", 
    "webcam"
  ]
}
DEBUG:__main__:recv_task error: ciphertext block must be 16 bytes
DEBUG:__main__:recv_task error: unpack requires a string argument of length 4
DEBUG:__main__:recv_task error: unpack requires a string argument of length 4
DEBUG:__main__:recv_task error: unpack requires a string argument of length 4
DEBUG:__main__:recv_task error: unpack requires a string argument of length 4
DEBUG:__main__:recv_task error: unpack requires a string argument of length 4
DEBUG:__main__:recv_task error: unpack requires a string argument of length 4

Am i doing something wrong ?

[BrandonFanti]

./client.py --encrypt --compress W.X.Y.Z 80
./server.py --port 80
DEBUG:main:[*] Searching http://W.X.Y.Z:81

Somethings not right here. Please update when you've decided on a port.

[malwaredllc]

@BrandonFanti The output you're seeing is correct, the server lists on PORT, it hosts post-exploitation modules on PORT+1, hosts packages/libraries on PORT+2, and handles file uploads via incoming HTTP POST requests on PORT+3.

[tdb1192]

Hello @malwaredllc ! Thanks for your work, and apologies if I am posting this in the wrong place; this is my first time ever reporting an issue on GitHub. I am experiencing more or less the same issue that Almazys was, and #124 did not appear to fix it for me. Here's a screenshot of the error I am having:

(I've redacted sensitive information)

Here's some background:

• I am building the client executable and serving the client on a Windows 10 virtual machine.
• This error occurs for me whether I run the --freeze executable or just straight python script.
• I have tested trying to use a separate virtual machine as the server, including trying to use a Linux machine (I move the stager/payload to the appropriate directories). The error is the same no matter what server I use.
• I have tested the client/server combo in BOTH python 2.7 and python 3.6 - I get the same error.
• From the inspection I did of server.py, it appears that the header being received by the server is not long enough (it seems to be empty to me).

Thanks for any insight!

[tdb1192]

Hello again, @malwaredllc! I spent some time debugging my issue, and I was actually able to resolve it. Turns out, my issue was due to the fact that my virtual machine exists in an air-gapped network. This was a problem because when the payload attempts to create a C2 connection with the server, it tries to contact an external IP to retrieve geolocation information. The malware can't even get DNS information for that hostname, so it just fails.

The following lines of code were the issue. After commenting them out, I was able to successfully create a C2 connection.

[_get_info(self) - lines 1389-1392]
\# add geolocation of host machine latitude, longitude = globals()['geolocation']() info['latitude'] = "_b64__" + base64.b64encode(latitude.encode('utf-8')).decode('ascii') info['longitude'] = "_b64__" + base64.b64encode(longitude.encode('utf-8')).decode('ascii')

To make a short story long, I tried running the malware as a python file instead of the executable, and I received this error:

Eventually I found the geolocation code in the payload file and was able to remove it.

[malwaredllc]

@tdb1192 Good catch! I will add some handling for this in client payload initialization to prevent it from simply failing.