Newsfeed
Nachrichtenbote
This summer has included the appearance of two strong new malware families onto the file encrypting Windows ransomware market: CryptoWall and CTB-Locker. Of these, CTB-Locker has been the more advanced family, with its use of elliptic curve cryptography for file encryption and Tor for communication with the command & control server. CryptoWall, meanwhile, has used the more traditional combination of RSA and AES for file encryption and HTTP for C&C communication.
At the end of last month, however, a new version of CryptoWall emerged into the wild. This latest version is mostly identical to earlier versions in functionality but with one important difference. CryptoWall now also uses Tor for communicating with its command & control servers. Like CTB-Locker, CryptoWall doesn't take the traditional easy approach of using the legitimate Tor-executable obtained from the project's official website, but instead uses it's own obfuscated version of Tor.
On the left, CryptoWall with Tor functionality, and on the right, CryptoWall without Tor functionality. Note that except for the call to f_setupTorCommunication(), the code is identical.
The approach used by CryptoWall is interesting. First, it attempts to connect over HTTP to a number of hardcoded URLs. From these URLs it attempts to download an RC4 encrypted file. The file is structured to first contain the length of the encryption key used, followed by the key itself. Next it contains the length of the actual payload and finally the payload itself. Once the malware has successfully downloaded the payload and decrypted it, it is copied to a newly allocated memory segment and a new thread is created to execute the payload.
Beginning of the downloaded payload as viewed in a hexeditor
The payload itself is a custom version of Tor wrapped inside two layers of obfuscation. Once both layers have finished execution and unpacked the final code into memory, the payload will attempt to establish a connection to the Tor network. Once the connection has been established, a flag value will be set by the payload in a global memory buffer shared by both the payload thread and the original CryptoWall thread. The payload will also set a pointer in the same buffer to point to one of the payload's functions. This is the function that is actually responsible for sending and receiving data.
Once the original CryptoWall thread sees that the global flag has been set, it will then continue with its own execution. The addresses of three command & control servers on the Tor -network are hardcoded in the original CryptoWall binary, not in the payload. The actual message contents of the C&C communication are also handled by code from the original binary. The payload is only responsible for handling the Tor-connection and sending and receiving the data.
Perhaps ransomware operators were switching from CryptoWall to CTB-Locker. Or perhaps the author(s) of CryptoWall just don't like being second best. In any case, the competition for nastiest piece of ransomware is still on!
CryptoWall samples with Tor functionality:
3370f29350115af162b613c45fd5a6a44315a213
6698bb2df60685863a664e282e493ca1e886fec3
Post by Artturi (@lehtior2)
On 05/08/14 At 11:23 AM
Weiterlesen...
At the end of last month, however, a new version of CryptoWall emerged into the wild. This latest version is mostly identical to earlier versions in functionality but with one important difference. CryptoWall now also uses Tor for communicating with its command & control servers. Like CTB-Locker, CryptoWall doesn't take the traditional easy approach of using the legitimate Tor-executable obtained from the project's official website, but instead uses it's own obfuscated version of Tor.
On the left, CryptoWall with Tor functionality, and on the right, CryptoWall without Tor functionality. Note that except for the call to f_setupTorCommunication(), the code is identical.
The approach used by CryptoWall is interesting. First, it attempts to connect over HTTP to a number of hardcoded URLs. From these URLs it attempts to download an RC4 encrypted file. The file is structured to first contain the length of the encryption key used, followed by the key itself. Next it contains the length of the actual payload and finally the payload itself. Once the malware has successfully downloaded the payload and decrypted it, it is copied to a newly allocated memory segment and a new thread is created to execute the payload.
Beginning of the downloaded payload as viewed in a hexeditor
The payload itself is a custom version of Tor wrapped inside two layers of obfuscation. Once both layers have finished execution and unpacked the final code into memory, the payload will attempt to establish a connection to the Tor network. Once the connection has been established, a flag value will be set by the payload in a global memory buffer shared by both the payload thread and the original CryptoWall thread. The payload will also set a pointer in the same buffer to point to one of the payload's functions. This is the function that is actually responsible for sending and receiving data.
Once the original CryptoWall thread sees that the global flag has been set, it will then continue with its own execution. The addresses of three command & control servers on the Tor -network are hardcoded in the original CryptoWall binary, not in the payload. The actual message contents of the C&C communication are also handled by code from the original binary. The payload is only responsible for handling the Tor-connection and sending and receiving the data.
Perhaps ransomware operators were switching from CryptoWall to CTB-Locker. Or perhaps the author(s) of CryptoWall just don't like being second best. In any case, the competition for nastiest piece of ransomware is still on!
CryptoWall samples with Tor functionality:
3370f29350115af162b613c45fd5a6a44315a213
6698bb2df60685863a664e282e493ca1e886fec3
Post by Artturi (@lehtior2)
On 05/08/14 At 11:23 AM
Weiterlesen...