As we move forward in our technological advancements, there will be a concurring rise in damage that results from technological attacks. The more interconnected we become, the more vulnerable we are when a new form of threat arises.

VPNFilter demonstrates how cybercriminals advance with the new technology and integrate degrees of portability by building code to target different forms of architecture.

VPNFilter chooses an architecture that is never thought about, and the least suspected. The little box sitting on your shelf that only gains attention when your internet drops for a moment, is the current danger generator.

VPN Filter

The Origins

For the past several months, Cisco TALOS has been working in tandem with public and private-sector threat intelligence partners and law enforcement, in pursuit of a highly active and sophisticated modular malware system that is now known as “VPNFilter”. Through this pursuit, it has become known that the VPNFilter is a widespread problem that interacts with another known malware known as “BlackEnergy” which is a malware that has caused alot of destruction and stress in the past in Ukraine.

The Current Status

As far as we know thus far, there been a recorded  500,000+ routers and network storage devices infected by the malicious components of VPNFilter.

Thanks to the release of research on the VPNFilter by the Cyber Threat Alliance, SophosLabs researchers gained early access to malware samples that had been collected by Cisco TALOS. With this, followed an update to the protection data that is essential in repelling and preventing VPNFilter from gaining ground. There has also been a mapping of a 3 stage attack that VPNFilter botnet follows. The following will describe those three stages of attacks.


1st stage of attack

The first stage of attack takes place as a compiled x86 ELF executable.



This executable was submitted first to VirusTotal on June 12th, 2017 from a user in Taiwan, and with it, it was discovered that the file has a name


Right now there is speculation that the file was fetched from a remotely hosted script called “qsync.php”, using a Windows system. Thus far it is not clear how the sample was used to compromise devices.

When the executable is run, it implants a schedule that executes it periodically, and to accomplish this, it modifies the crontab (cron table) file.

The cron fromat has five time and date fields: minute, hour, day of month, month, day of week.

If there is a specified valaue such as */step, execution takes place at every interval of step through the unrestricted range.

By appending the scheduled execute argument */5**** to the crontab, the implant then executes every 5 minutes:

fd = open_file(“/etc/config/crontab”, “a”); _fd = fd; if (fd) { format_sys_write(fd, “*/5 * * * * %s\n”, (int)&fname); fd = close(_fd); }

the implant keeps its critical strings encrypted. This is accomplished by relying on a modified RC4 algorithm. A normal RC4 algorithm initializes routinely calculates an index into the state table, using the key. Then, 2 bytes in the state table are swapped in place, the first byte being pointed by the incremented index i, and the second byte- by the newly calculated index index2, this is shown below.

#define swap_byte(a, b) {swapByte = a; a = b; b = swapByte;}

for (i = 0; i < 256; i++)state[i] = i;

key_index = 0;

index2 = 0;

for (i = 0; i < 256; i++)

{index2 = (key[key_index] + state[i] + index2) & 0xFF;swap_byte(state[i], state[index2]) if (++key_index == key_size)key_index = 0;}

The implant however, initializes the state table in a different manner. Instead of permutating the state table through swapping the bytes, it applies XOR to the state table, using the same RC4 key.

This form of RC4 initialization is known to be used by BlackEnergy

for (i = 0; i < 256; i++)state[i] = i;

key_index = 0;

for (i = 0; i < 256; i++)

{state[i] ^= key[key_index];if(++key_index == key_size)key_index = 0;}

The RC4 key is a 4-character string hard-coded as %^:d. The rest of the RC4 implementation is identical to the standard algorithm.

There are a total of 12 encrypted strings within the body implant. Each string is stored as something that takes 1 byte, followed with the encrypted string.

When each string is decrypted, they become the following:


As seen above, the first three strings are the filenames where the plant saves 3 client certificates, hard coded within its own body. The client-side SSL certificates are used for authentication requests to the C2 server, over HTTPS (port 443)

The version number 0.3.9qa is saved into the file /var/run/msvf.pid

The /var/vpnfilter is used as a temporary filename for the downloaded files.

Hard coded Photobucket URLs are relied on by the implants or the implants rely on Toknowall C2 website to fetch the images.  The images serve a purpose of extracting a 2nd stage server IP from the EXIF metadata.

Once that is accomplished, a payload module is fetched from the 2nd stage server through the URL path /update/test. The download module is then saved as /var/vpnfilter, which assigned execution permission with the chmod(511) command, and then finally, executed with sys_execve(). 


2nd stage of attack: Backdoor trojan

The second stage of attack involves a payload fetched by the implant


Which is a backdoor trojan compiled as x86 ELF executable.

Just like the 1st stage implant, it has it’s critical strings encrypted using the same method. The RC4 however is different this time:


The decrypted strings expose backdoor commands, IP addresses of C2, and some other configuration parameters.

The backdoor is able to accept and execute the following remote commands:

The backdoor relies on a user agent string randomly selected from a list of 9 strings:

user_agent = user_agents[PRNG() % 9];

The user_agents table consists of the following:

Through a SSL connection, the backdoor communicates with its proxies just like the implant, and relying on client-side SSL certificates.

With the attempt at parsing socket info from /proc/net/tcp the module tries to determine the presence of TOR. For each enumerated socket descriptor, it then attempts to find a descriptor of a

socket that has open connection on port 9050, that is used by TOR.

With a TOR module installed as a 3rd stage plugin, the communication takes place via the following .onion domains:

backdoor modules are almost identical in their functionality when built for different platforms. The strings are encrypted using the same key.

There is a subtle difference that exists in the internal platform ID parameters. An example is the x86 module uses IDs:

The ARM CPU may have parameters set for backdoor built modules like the following:

A variation compiled for MIPS:


3rd Stage of Attack: Plugin

A 3rd stage plugin


is a TOR client. As yet another x86 ELF executable, it shares the same known open-source TOR client implementations.

Another 3rd stage plugin has been found to be built for MIPS architecture


The plugin represents itself a sniffer that looks for several interesting traffic patters such as


Other related patterns to HTTP authentication packets:


the intercepted data is stacked into the files, formatted as:



The %Dir% is a working directory, such as /var/run/vpnfilterw.


Keep up to date on your technology and it’s vulnerabilities and solutions with RE2Tech. We make I.T. easy!

Have you taken precautions with your router?

Give us a call or send us an email for all your I.T needs! We at Re2tech make I.T. happen!

Phone: 952-223-4422