In July, a report was released spotlighting a threat actor known as Robin Banks. WMC Global was also tracking this threat actor and noticed the scammer's attack infrastructure quickly went offline at the time of the article’s publication. It is possible this was done by the intel vendor or the threat actor trying to hide but may also have been an unknown party. Only a matter of weeks later, WMC Global analysts discovered Robin Banks was still operating and had rebuilt their backend phishing operation to be more resilient to takedowns, highlighting their awareness of the original article.
WMC Global analysts are experts in discovering credential phishing campaigns and work hard to collect, archive, and enrich the phishing kits used in these campaigns. Having access to the threat actors’ source code offers enhanced viability into the threats posed by these scammers. Robin Banks kits have been collected and parsed allowing WMC Global analysts to fully understand the source code.
Robin Banks Phishing Kit REVISIONS
Within the code of the Robin Banks phishing kit there is a file that makes a request to download a php file from a static IP address. Previously the URL (Figure 1) receiving the requested php file data was set to collect it directly from the Robin Banks shop domain, but after the initial take downs, the threat actor has changed the process to be more resilient.
Figure 1:Request for text file
The same file in the new code now makes a request to a text file hosted on a new IP address. WMC Global has detected multiple IP addresses linked to Robin Banks which have been used in the new kits. Using several IP addresses allows for no one endpoint which protects against a single point of failure.
Figure 2: Text file contents
The content of the text file is a CSV list of URL domains.
Figure 3: Robin Banks login page
When examining the list of URLs, WMC Global realized the first domain listed is online, but simply has a “test” string. The second URL actually hosts a Robin Banks login page.
Figure 4: Appending domain to final request for the php page
Once the file in the site code has pulled the list of URLs from the text file, it then moves on to a getPage function. This will extract the first item in the domain list and then make a request to a file on the associated URL. The sample in Figure 4 has been taken from a Citibank kit.
Figure 5: New vs old caller requests
Figure 5 shows a comparison of new vs old caller requests. This “call-to-directory” behavior is similar to the older, original phishing kits which didn’t use the dynamic URL system, however this kit uses a static domain to request the php file. If for any reason the call to the fixed IP address does not return any URLs, (if the IP address has been taken down, for example), the original php file still houses two more hardcoded URLs as backups. These found URLs previously hosted Robin Banks login pages allowing us to assert the threat actor did control them and both domains appear to be down at the time of writing.
Figure 6: Backup domains with a call out to IronNet
WMC Global analysts also noticed that Robin Banks is using specific domain names that seem to refer to IronNet, author of the original report. These domains only appeared after the report was written and seems to suggest Robin Banks read the post and keeps up with news on their kits.
Robin Banks has added obfuscation to their kit files meaning the kits are illegible and without spending time to decode, it is difficult for analysts to understand what the code is doing. WMC Global has successfully deobfuscated these files and found a lackluster attempt at user authentication created by Robin Banks.
We often see threat actors attempting to run their own code security systems to prevent other threat actors stealing their code, but the following attempt by Robin Banks is one of the weakest we have ever seen.
Figure 7: Robin Banks file header code
This header (Figure 7) appears to be the actor self-promoting and fingerprinting their kits which is a common practice. In the decoded source code, however, WMC Global found a regex search looking for the signature header within one of the layers.
Figure 8: Deobfuscated validity checking
This code segment (Figure 8) will first look for the signature line and ensure it matches the string as wrapped in the source. If it does not match, the code will exit and the phishing page will never render. It is expected that each unique customer of Robin Banks will get their own unique signature.
The next code line checks how many total lines are in the file. There are 9 lines in the original file so if the file has been modified in any way and there are different number of code lines then the code again will exit.
Finally, there is a basic check to ensure the threat actor's own signature is present within the kit. If the signature header is not found, then the code exits stating that the file has been corrupted.
The threat actor’s intent to protect their code with these checks is clear, but their method is not well thought out. It is fairly simple with a little time to decode the layers and alter or remove them altogether allowing for anyone to then reuse and re-purpose the kits.
For KITIntel users, you can find a full de-obfuscated version of Robin Banks kits in kit UUID e6356d92-9947-4ee4-94d4-3065edd90435
It is clear from the changes and new domains added that Robin Banks keeps an eye on developments within the cybersecurity industry. They have made tactical changes within their kits that not only reflect their knowledge of the initial article, but they have also made changes that prevent a rapid takedown operation from being effective.
Robin Banks kits are more well-constructed than others that WMC Global has analyzed, but they are not sophisticated as demonstrated by the poor attempt at preventing others from stealing the code. Also, the threat actor's operational security is weak and has meant they have leaked a large amount of their backend infrastructure publicly, which has allowed for a deep dive into how the kits work.