Automatic Transfer Systems (ATS) for Beginners

ATS is one of the newer techniques employed by banking malware that not many people are familiar with so I thought I’d do a small post explaining it. To fully appreciate the complexity of ATS we have to take a look at a brief history of financial malware and how they harvest financial information such as bank logins, I did write some individual posts about formgrabbers, and webinjects but figured a quick recap would be better.

Formgrabbing
A formgrabber is a malicious module that is injected into the user’s browser and modifies the code flow to intercept POST requests between form submission and SSL/TLS encryption; as a result formgrabbing malware is capable of intercepting HTTPS requests before they are encrypted, thus can log usernames and passwords for HTTPS sites such as PayPal. All intercepted credentials would then be sent back to the C&C server where they would most likely be sold in bulk to other criminals willing to use them. Although formgrabbers work fine for most sites which only require usernames an passwords, banks generally require extra information during log in to prevent use of stolen credentials.

Webinjects
Webinjects are an extension to formgrabbing which adds the ability to intercept web responses, which nicely compliments the formgrabber’s ability to harvest credentials by intercepting requests. A response can be modified after the browser has decrypted it but prior to it being displayed to the user, allowing malware to modify any and all page content for any site the user visits. The main purpose of webinjects are to add fields on bank login forms to requests extra information that is required to log in, then when the form is submitted it is picked up by the formgrabber. Here’s an example of when webinjects are useful: My personal bank account requires a second password to log in and it’ll say something like “enter character 2, 6, and 7”, if the request was intercepted then the C&C would only have characters 2, 6, and 7 stored but next time the bank might ask for characters 1, 3, and 5, making it impossible for someone to log in until all characters have been logged (At the rate I log into online banking, this would take many months). A solution to this problem would be for the webinjects to add a message to the login page which says “To confirm your identity, please enter your full secondary password” followed by a text box, then upon log in all required information would be intercepted by the formgrabber and sent to the C&C.

The main problem with standard webinjects is they are completely useless for banks which use two factor authentication (2FA). If a bank texts a unique one-time code to a customer’s phone which they have to enter in order to log in, there’s no extra information that can be requested by the webinjects which would allow someone else to log in, other than the physical phone, though modifying the webpage to request that the victim mails their phone and pin code to a shady address in Russia is unlikely to fool most people.

Automatic Transfer System (ATS)

Under the hood ATS are simply just webinjects wearing a different hat, the purpose is shifted from gathering credentials for use/sale to automatically initiating wire transfers from the victims own computer (all without needing to log their credentials, bypassing 2FA and all anti-fraud measures).

Once the victim logs into their account normally, the webinjects would inject a script which would callback to the C&C with information such as account number, bank balanced, and bot unique ID; from here a decision on if to initiate a transfer would be made based on factors like bank balance and if any mules are available to receive the transfer (mules are people responsible for handling and laundering stolen funds). If the transfer is authorized, the script would then automatically fill out a transfer with an amount and mule’s bank account number, then submit the request from the victim’s logged in bank account (transfers could be initiated via XMLHttpRequest or by modifying something like a welcome page to contain the pre-filled transfer form hidden from view, which would then be submitted when the user clicks the “Close” button). A real major benefit of ATS comes in when cybercriminals are looking to steal money from secure corporate accounts; If an account were to require transfers to be approved using another one-time code, because the account owner is currently logged in it would be fairly simple for the ATS script to inject a pop up saying something along the lines of “your session has timed out, we’ve sent you a new one-time code which you can enter here to continue”, then pass that code on to the ATS script to silently approve the transfer. It’s also possible for ATS/Webinjects to “correct” the account balance and any pages containing information about the transfer to conceal any funds stolen by the system, leaving the victim completely unaware that anything happened until they log in on a computer that isn’t infected.

 

Conclusion

Due to the fact ATS scripts must be individually tailored and maintained for each bank, and the large amount of money mules required to maintain cash flow, malware making use of ATS is still fairly uncommon and mostly restricted to large groups such as the one behind the Dridex malware. It may also be possible that ATS becomes even more uncommon with criminals opting to just ransomware the victims and have them handle the sending of funds themselves, rather than stealing them.