Radware Threat Research Center has identified a hijacking campaign aimed at Brazilian Bank customers through their IoT devices, attempting to gain their bank credentials.
The research center has been tracking malicious activity targeting DLink DSL modem routers in Brazil since June 8 th . Through known old exploits dating from 2015, a malicious agent is attempting to modify the DNS server settings in the routers of Brazilian residents, redirecting all their DNS requests through a malicious DNS server. The malicious DNS server is hijacking requests for the hostname of Banco de Brasil ( www.bb.com.br ) and redirecting to a fake , cloned website hosted on the same malicious DNS server, which has no connection whatsoever to the legitimate Banco de Brasil website.
Itau Unibanco, another Brazilian financial institution, hostname ( www.itau.com.br ) is also being redirected, although not backed by a cloned website for now. For all other DNS requests, the malicious server works as a forwarder and resolves just as an ISP DNS server would. The malicious DNS server set up by the hackers becomes an effective man-in-the-middle that provides the malicious actor with the flexibility to bring up fake portals and web fronts to collect sensitive information from users whose routers were infected.
Unique about this approach is that the hijacking is performed without any interaction from the user. Phishing campaigns with crafted URLs and malvertising campaigns attempting to change the DNS configuration from within the user’s browser have been reported as early as 2014 and throughout 2015-2016. In early 2016 an exploit tool known as RouterHunterBr 2.0 was published on the internet and used the same malicious URLs, but there are no reports that we are aware of to date of abuse originating from this tool.
The attack is insidious in the sense that a user is completely unaware of the change. The hijacking works without crafting or changing URLs in the user’s browser. A user can use any browser and his/her regular shortcuts, he or she can type in the URL manually or even use it from mobile devices such as iPhone, iPad, Android phones or tablets. He or she will still be sent to the malicious website instead of to their requested website, so the hijacking effectively works at the gateway level.
[You might also like: DNS: Strengthening the Weakest Link] Details of the attackFrom June 12 th our deception network has been recording multiple infection attempts for an old D-Link DSL router exploit.
The exploit allows unauthenticated remote configuration of DNS server settings on the modem router. The malicious URL is in the form of:
/dnscfg.cgi?dnsPrimary=<malicious_DNS_IP>&dnsSecondary=<malicious_DNS_IP >&dnsDynamic=0&dnsRefresh=1Exploits were published as early as Feb 2015 for multiple DSL routers, mostly D-Link:
Shuttle Tech ADSL Modem-Router 915 WM / Unauthenticated Remote DNS Change: Exploit http://www.exploit-db.com/exploits/35995/ D-Link DSL-2740R / Unauthenticated Remote DNS Change Exploit : http://www.exploit-db.com/exploits/35917/ D-Link DSL-2640B Unauthenticated Remote DNS Change Exploit: https://www.exploit-db.com/exploits/37237/ D-Link DSL-2780B DLink_1.01.14 Unauthenticated Remote DNS Change: https://www.exploit-db.com/exploits/37237/ D-Link DSL-2730B AU_2.01 Authentication Bypass DNS Change: https://www.exploit-db.com/exploits/37240/ D-Link DSL-526B ADSL2+ AU_2.01 Unauthenticated Remote DNS Change: https://www.exploit-db.com/exploits/37241/Our deception network recorded almost 500 attempts between June 8 th and August 10 th . All our So Paulo based honeypots captured these attempts, without exception. The rest of our global deception network did not capture any of these attempts, meaning the malicious agent was focusing his attack on Brazilian targets only, trying to increase efficiency while staying under the radar from honeypots outside of Brazil.
Exploit attempts were performed from a handful of servers. Most of the servers were located in the U.S. but the most active and at this day the only active server is located in Brazil. Below are the 5 IPs accounting for the 500 attempts:
Originally the malicious DNS server IP used in the exploit was 69.162.89.185. The IP changed to 198.50.222.136 from August 2 nd 2018.
Resolving the hostname for Banco de Brazil ( www.bb.com.br ) through the malicious DNS server:
Equally so for Itua Unibanco:
The fake cloned website for Banco de Brasil is located at https://198.50.222.136/pbb/web and uses a self-signed certificated with a validity starting date of August 1 st 2018, matching the change of malicious DNS server IP in the exploit attempts. We emphasize that that the fake cloned website for Banco de Brasil is hosted on a malicious server that has no connection whatsoever to the legitimate Banco de Brasil website.
When trying to access the account through the fake cloned website, the user is presented with a form asking for the bank agency number, account number and an eight-digit pin.
Next, the fake site requires confirmation of identity by asking users to provide mobile phone, card pin, and a CABB number.
Impact for the end-users
The banks referenced above were not directly attacked nor breached, however their users can suffer financial and private data losses through this malicious hijacking attack. The ‘only’ indicator for the user is the invalid certificate which all modern browsers clearly indicate when using secure connections. It is not even possible to access the website without explicitly confirming the “Not Secure” exception! However, the malicious website, unlike the original website, does allow unsecure connections. If the user, for some reason, bookmarked or typed a unsecured url (http:// instead of https://), the malicious website happily stay in unsecure connection and there will be no visible warning for the user.
Another impact on the victims will occur when the malicious DNS server goes offline or is taken down. The attacker is attempting to modify both primary and secondary name servers with the same malicious server IP, meaning that when the malicious server is offline, all infected homes will fail to further resolve any hostnames and their internet will be virtually inaccessible until the users manually update their router settings or the ISP ov