Anonymous proxies play an important role in protecting one’s privacy while on the Internet; however, when unsuspecting individuals have their systems turned into proxies without their consent, it can create a dangerous situation. Palo Alto Networks researchers recently discovered a family of malware, designated ProxyBack, and observed over 20 versions that have been used to infect systems as far back as March 2014.
The primary distribution observed by Palo Alto Networks is focused heavily in Europe with most targets belonging to educational institutions.
Figure 1 – ProxyBack distribution shown in AutoFocus
In this report, we’ll dive into the behavior of a recent sample of ProxyBack, examine how it establishes the victim proxy, and analyze the traffic using this service.
ProxyBack Malware
To be an effective proxy, network traffic must be able to flow through the proxy unhindered. In a typical setup, this may be accomplished by allowing a proxy system to receive traffic over a network socket designated for this function and then forwarding the network traffic on as its own.
Figure 2 – Classic proxy setup
The problem for a non-legitimate proxy is that the network traffic destined to reach the proxy server, which is a compromised system, will usually not be able to reach it because of firewalls or other network based restrictions put in place to protect systems.
Figure 3 – Corporate firewalls prevent the victim from being accessed in a classic proxy setup
ProxyBack gets over this hurdle by building a reverse tunnel over TCP to an attacker controlled proxy server. In other words, it has the victim proxy make the initial call home, thus allowing the proxy server to send its traffic through the tunnel and out to the Internet, or to other devices internal to that network.
Figure 4 – Victim proxy establishes a connection with the attacker-controlled server
- Victim proxy pokes a hole in the firewall by establishing a TCP connection with the attacker controlled proxy server.
- The proxy server validates it has access to the victim proxy and that it can successfully route traffic through it to the Internet.
- The users of this proxy service are now able to route traffic through the attacker-controlled proxy and exit any of the victim proxies they’ve validated.
- The victim proxy is now unwillingly participating in the routing of web traffic to the Internet
ProxyBack Analysis
To establish this tunnel, ProxyBack will initially make a connection to a web server hosting a PHP file that simply contains a URL to another PHP file on the same server. This subsequent PHP file will be used by the malware to send commands to the initial web server and fetch information used to setup its proxy connection. Each GET Request Method observed since early 2014 contains a User-Agent string of “pb”, which makes it trivial to detect.
Figure 5 – User-Agent “pb”
The first variable passed, “getip”, to the “command” parameter retrieves the public IP address of the victim proxy.
Figure 6 – “command=getip”
The second variable passed, “getid”, retrieves the ID for the victim proxy, which will be used in subsequent commands to keep track of the victim proxy. From the initial assessment of this malware until today, the ID number has continued to sequentially increment. So far, it has increased by 11,149, which may be indicative of the number of victim proxies compromised.
Figure 7 – “command=getid”
The third variable passed, “ghl”, to the “command” parameter receives an encoded base64 string for a URL. This URL led to another PHP file, which contained a URL to another PHP file; however, the subsequent URLs were never live during analysis.
Figure 8 – “command=ghl”
The fourth variable passed, “dl”, receives an encoded base64 string, “fA==”, which signifies the delimiter to be used in the subsequent command.
Figure 9 – “command=dl”
The fifth variable, “version”, deserves some extra attention as it has changed during the course of this analysis. Initially, the URI included the ID of the victim proxy and the variable “version” passed to the “command” parameter; now, the URI includes the version of the running malware, the victim proxy ID, and the running operating system.
Figure 10 – Old “command=version”
Figure 11 – New “command=version” with current version and OS
Additionally, the ProxyBack malware is capable of reporting the following operating system versions, which suggests it can run each of them.
Figure 12 – Operating Systems
The content returned from the fifth command remains similar between versions. The “version” variable receives an encoded base64 string that includes the version number of the malware and a URL to the malware version, delimited by the previously retrieved character. Another change noted is that versions were previously in the following format, “17.exe”, “20.exe”, and “41.exe”; whereas in November 2015 they started to include the first three letters of the web server domain in which they are hosted, such as “sof1.8.exe” on “softwearfounds[.]com” and “sky2.1.exe” on “skyjfasters[.]com”.
Figure 13 – Old “command=version” response
Figure 14 – New “command=version” response
Figure 15 – New “command=version” response
At this point, if the version running deviates from the version returned, it will use the GET Request Method and download the version provided in the output of the “version” variable. After that, the process restarts from the beginning but will keep the same ID value that was previously assigned.
Figure 16 – Downloading the new version
The next variable passed, “getbackconnect”, to the “command” parameter is used to get the IP address and port of the remote system with which the victim proxy should establish the reverse tunnel.
Figure 17 – “command=getbackconnect”
Once the ProxyBack malware has this information, it begins the process of building the TCP session to be used over the course of this session. For this particular sample, the destination port provided was “495”. After the TCP handshake completes, a series of packets with PSHACK flags are transmitted back and forth containing data appended to them that control the flow of this process.
The first packet in this series is sent from the victim proxy to the malicious proxy server and includes a sequence number, followed by a null byte, followed by two bytes that serve as delimiters for the rest of the data.
Figure 18 – Sequence 1, Initial PSHACK packet
The proxy server replies with the next packet in the sequence that tells the malware what IP and port to pass as variables in the next GET Method Request to the original server. The last two bytes tell the malware which new socket to open a TCP connection to for transferring the data that is being sent through the TCP tunnel.
Figure 19 – Sequence 2, 0x2EA5DED4 = 46.165.222.212, 0x13FC = 5116, 0x13FC = 5114
ProxyBack now passes the variable “update2” to the “command” parameter with the additional data received from the PSHACK. The web server simply replies with an “Ok”.
Figure 20 – “command=update2”
The next PSHACK in the series is sent to the victim proxy and tells the malware to create a TCP session over the additional port provided in the second sequence of the PSHACK packets.
Figure 21 – Sequence 3, Stop and switch
Figure 22 – Switching ports
The victim proxy sends the 4th PSHACK packet to let the proxy server know it’s ready to continue on the new port.
Figure 23 – Sequence 4, Continuation
Similar to the first packet in this PSHACK series, the proxy server initializes the session with a delimiter to be used in subsequent commands.
Figure 24 – Sequence 5, New delimiter
Also of note is the value 0x02 after the sequence number. This seems to indicate additional commands for this phase are to follow, or possibly the number of packets to expect. The victim proxy responds with the value 0x0500 and then the proxy server sends the final packet in this sequence, which contains an IP address and a destination port, which the ProxyBack malware will open a TCP session with.
Figure 25 – Sequence 5, 0xBC741763 = 188.116.23.99, 0x0050 = 80
Figure 26 – Completing the three-way handshake
After the handshake is complete, the victim proxy notifies the proxy server of the source IP and source port used in the three-way handshake as the last PSHACK packet in sequence 5.
As the last validation step, the proxy server issues a GET Request Method through the tunnel established over TCP/5114 and the victim proxy forwards it on.
Figure 27 – Validating the victim proxy
The return data from 188.116.23.99 is sent back to 46.165.222.212 over TCP/5114 as data in a PSHACK packet, which completes the validation phase. It’s interesting to note that the proxy server IP and “secret” key are included in the URI. The returned data is a serialized PHP formatted configuration file with information about the web server hosting it. The “secret_string” variable observed in the URI and the configuration file has not changed since the first samples were seen in March of 2014.
Figure 28 – Returned configuration
Traffic will begin to flow through the victim proxy once it has been validated
Figure 29 – Traffic going through victim proxy
Every 27 minutes, the ProxyBack malware on the victim machine will send the “update” variable to the “command” parameter on the original web server hosting the PHP file to see if it needs to change malicious proxies or update it’s software.
Figure 30 – Software update
To wrap up this section, below are the available commands found in the old and new versions of the ProxyBack malware. Throughout the period this malware was observed, neither “log” nor “update” variables were ever passed to the “command” parameter.
Figure 31 – Available commands
Conclusion
When a system infected with ProxyBack was actively operating, there was an sizeable volume of traffic being routed through. It was clear that there were legitimate, benign, users of the SOCKS proxy, along with malicious users as well, further adding weight to the conclusion that this is a proxy service. Users of these services should be aware that their traffic is neither anonymous nor safe from tampering.
Upon review of the web traffic routed through our victim proxy, the majority of that traffic appeared to source from an automated system creating fake accounts and soliciting people across dating sites like “farmersonly.com”, “match.com”, “meetme.com”, and “okcupid.com”. The legitimate traffic included sites like eBay, Twitter, Craigslist, Facebook, Wikipedia, and more.
Another website that stood out during this review was “buyproxy.ru”, which was the only site that seemed to match a proxy service found within our captures. Looking deeper into this traffic, we see a GET Request Method to http://buyproxy.ru/proxy/ at less than 4 hours into our capture, which lists our victim proxy.
Figure 32 – Web source that contains victim proxy
What’s interesting to note here is that our victim proxy’s reverse PTR record is shown in the sixth column, whereas in the second column, our malicious proxy server is listed for users to presumably connect to. In an odd twist of fate, the same users of the service also betray it.
Figure 33 – Proxy connection with “185.72.244.171”
When visiting the buyproxy[.]ru site, it states in their FAQ that they have been in business for over seven years, they provide only private proxy servers that are not in public proxy bases, they average between 700-3,000 proxies per day, proxies usually live between 4 to 24 hours, nothing is logged, and they use a “BackEnd proxy” which shares an IP for access but distributes the exit. In addition, on their main page they tout that the connections are encrypted and use a “proprietary technology of traffic tunneling”.
When accessing the site with a registered account, you are presented with three proxy options:
- “Private proxy” – Supposedly maintained by “buyproxy[.]ru”.
- “Public proxy list” – Public proxies.
- “Personal proxies” – Proxies dedicated to the buyer.
Figure 34 – “buyproxy[.]ru” main menu
On the “Private proxy” page we find our victim proxy under the United States, among others. One thing that immediately stands out is yellow highlighted entries, which follow the same characteristics as our victim proxy. The IP address differs from the listed domain, possibly implying they are also victim proxies.
Figure 35 – Victim proxies
Whether the people behind “buyproxy[.]ru” are responsible for the distribution of the ProxyBack malware or not is unknown; however, it is clear that the ProxyBack malware is designed for, and used in, their service.
Palo Alto Networks has released the IPS signature 14864 to detect and block ProxyBack traffic. WildFire properly classifies ProxyBack executables as malicious and AutoFocus users can track this threat using the ProxyBack tag.
Observed Indicators
Proxy Server IPs
5.9.212.53
5.79.85.212
46.38.51.49
46.165.193.67
46.165.222.212
46.165.223.193
62.75.255.52
69.64.32.110
85.17.30.89
91.121.193.50
91.185.215.137
93.189.40.164
93.189.42.9
93.189.42.43
104.238.173.238
108.59.9.15
185.72.244.171
185.72.246.23
194.247.12.11
194.247.12.49
213.229.102.157
217.172.179.88
User-Agents
pb
Mutexes
PB_MAIN_MUTEX_GL_63785462387
PB_SCH_MUTEX_GL_A58B78398f17
PB_SN_MUTEX_GL_F348B3A2387
Hosting Web Servers
bugertwist[.]com/vb.php
bugertwist[.]com/memb.php
creativanalyticks[.]com/va.php
creativanalyticks[.]com/spool.php
czonainsit4e[.]com/ocfg.php
depasistat[.]com/home.php
drythisworld[.]com/main.php
hclickmeterg[.]com/solomon.php
heljeanvos[.]com/q.php
heljeanvos.com/eome.php
iholpforyou4[.]com/d_index.php
lancer-moto[.]com/cfg.php
markovqwesta[.]com/que.php
masyaget[.]com/dse.php
masyaget.com/wed.php
mintoolses[.]com/mint.com
nsit4esite[.]com/faq.php
nsit4esite[.]com/mod_rw.php
papausafr[.]com/psin.php
pllsest2[.]com/pils.php
qforumjail[.]com/faq.php
robjertovines[.]com/sta.php
singlearthousse[.]com/ocfg.php
skyjfasters[.]com/do.php
solocoufandle[.]com/md.php
sweedfolz[.]com/list.php
texasgodchang[.]com/teh.php
truedonell[.]com/fa.php
uarushelp[.]com/fix.php
xclotusm[.]com/go.php
littlepartygodd[.]com (not yet used)
solognomwedgt[.]com (not yet used)
HTTP Commands
php?command=getid
php?command=getip
php?command=update&id=
php?command=update2&id=
php?command=version&id=
php?command=getbackconnect
php?command=ghl&id=
php?command=dl&id=
php?command=log&id=
HTTP String
BER5w4evtjszw4MBRW
Sample Hashes
938eb65b201ffe2b95b8004d51eea4343ac1c2e5307acf0aabb0e310f33949ce | sof1.8.exe
ea86ea5ecc8a63db91bd528a78db5e71734be9693dcda860044fbe522a6e1b4b | sof1.7.exe
87bc6ae4d46c460c58ac4131ad15e0c8f217e2152efb2c23b23a4d51852abdb9 | sof1.6.exe
452511487941bcc6fbc5b3e76859740837df20e86121db9fb5be3f1456a3e653 | sof1.4.exe
96b9a8024f5796a610402ac857d318d00951b661c2bc96b91878b3c970c7de14 | 11.exe
f79059de5345197935581365bc11a25afe8ad77eac82b128068543c2f15ec8fb | 12.exe
b74b0d1e68c201047eeb2dfeaf6b7ffc6ff29cccff8e6acbf25f560fff66f36b | 13.exe
544269fa321651535bf30e8b07e7a19eb2407e3cc16c121333fa2d9e5ee5d4b2 | 14.exe
6ab78fc4263af8e7f76cc66e4d0f610a1990237bd48550c84f7c5b03e79ac5e0 | 15.exe
897fa587053e6997288b94ebf3a56f0f5c63053643faf0df48882b69a5788319 | 16.exe
db7952c408a62d7bb5747f917db554aa5aff19faa76b80d8ab0c47cb461fe53d | 17.exe
a74b19b76c0a76d95e48c2c4d230afa7ac490b2aca3f581d6505f227897df7c2 | 20.exe
0cccb9d2e2aeef636d32f487bcfb588b6769428554949db1cd30f9f6a01daa43 | 21.exe
d1bc4e42d818ff751c97e0c5667d03097a7e99f8a98d48bac9ac7394f771346a | 25.exe
7fcd05b00d6e37ef765ec10fb23ce9c78114b09b5a99eab957fb65a05df565a7 | 26.exe
5c0d8009ca816fc1e5d6c9f9366a678cb947d9ac1e87da76f19103703ce6bb7c | 40.exe
f5848d197f5fb48fca2b48c54f6a26ff6a84e3576d16dccdece135edd8b7a9e9 | 41.exe
f310c8e3baebbdee8e80a974608451e6c0292c12fc1e3068ed445fe74c42d882 | 55.exe
f1485e53403de8c654783ce3e0adf754639542e41c2a89b92843ce8ecdeb4646 | 90.exe
c550a0730c9cf10751a3236ef57fafb5af844bef3874855a215519a9ffcec348 | 91.exe
1b583827e4d010bf7ac0e72fca5158bb03cb84c6db93de198d0ba56b990d1a9f | 1122.exe
Get updates from
Palo Alto
Networks!
Sign up to receive the latest news, cyber threat intelligence and research from us
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.