 Hi, my name is Héctor Cuévas and today I'm going to talk about ATM transaction reverse of frauds and how to fact them. Thank you to the Payment Village for the opportunity, so let's start. Who am I? Well, I have been Security Consultant for many years. Today I'm proudly working at Bishop Fox as a Security Consultant. But the reason why I'm here is because of my experience with ATM security. I have been in red, blue and purple teams, also involved in ATM. So doing penetration testing to ATMs and not just that, but an integral ATM security review. I have also responded to some incidents and forensic analysis, smile wear, check pouring, black box attacks, journal analysis, and transaction reverse of frauds, like today. On threat hunting area, I have been doing some of forensic artifacts research because there is no much information out there of forensic artifacts for ATMs. And also I work in some of the automation for log analysis and from there send it into the CM and create some use cases and business cases to trigger an alert if something is happening. And yeah, that's me doing some of our engagements. So the agenda for today is that we're going to talk about some of the documentation available out there for security in ATMs. So we're going to talk about some of the attack categories that exist in ATMs. We're going to define what is a transactional reversal fraud, what is a transaction and what is a reversal before trying to understand the whole attack. And also we're going to talk about some of the ATM hardware components that are related with transaction reversal fraud. We're going to talk about then some examples about transaction reversal fraud attacks. There are many different and we're going to try to understand them. And at the end we're going to see a real forensic case that I handled where we're going to deep dive a little bit into the journal analysis, the static message and the transactional switch logs. And at the end we're going to have some recommendations and mitigations to avoid transaction reversal frauds. So some of the available documentation and resources out there are, for example, the PCI industry, but the payment car industry only has one document that talks about ATM and this document only covers the PIMPAD and the encryption that the PIMPAD must have in the ATMs. We have some associations, for example, a European Association for Secure Transactions and the ATM Industry Association, which they have a lot of information of ATMs and not only security, but in general. But these associations require you to be a member to access to some of the documents. So to become a member of these associations, you need to have some requirements and to pay a fee that sometimes could be very expensive. Also, we have some advisories from vendors, but sometimes these advisories only goes to their clients or their private. Some of the attack categories that I have seen that I have learned that exist are the physical, logical, and the fraud. So for example, in the physical, we have something that will damage the hardware. For example, a ram rate and explosive that they will not take care about anything. They will just try to do something to the hardware and try to get the money. In the logical, they will not mess with the hardware per se. They will just try to manipulate the ATM. So at some point with some logical attack, they will be able to get the money. For example, using a black box or using a malware. And in the fraud, in this one, they are going to try to do a fraud. For example, in the scheming, they will not attack the ATM. They will not attack the financial institution. They will be targeting the customers. And in the transaction reversal fraud, also, well, this is a fraud that we are going to discuss. For example, the transaction reversal fraud can also be called reverse ATM attack. I don't like too much the reverse ATM attack. But let's say that the transaction reversal fraud, it's when the ATM is manipulated, so it tricks the ATM indicating that the cash wasn't delivered to the car holder. But indeed, the car holder will get the money somehow and will cause an error into the ATM. And from that error, the transaction will be reversed and the amount will be recreated into the account of the car holder. So some of the common assumptions that exist in transaction reversal fraud is that it only occurs in ATMs, that there must be an ATM manipulation, the use of prepaid cards, and that the car will always be swallowed. So these are just assumptions because that's not always the case. And this is because, for example, if we make a transaction, a normal transaction in the ATM, a ledgy transaction with real funds and everything, it's all right. But we have an insider in the financial institution. The insider could send, could command the transaction and switch to make a reversal at the end of the transaction. So the attacker in the ATM will already have the money, will relive the ATM, but the insider will mark that transaction to be reversed. So the amount will be recreated to the account. So as we see in this example, we don't need an ATM to do this attack. Also the prepaid cards are being used by the attackers because that leaves less choices. But they could use a normal car that the account belongs to them. So also the car will be swallowed by the motorized car reader. This is not always the case because some of the transaction and reversal fraud attacks, the attacker will not deal with the car but with the money. We will talk about this later. So before that, we need to understand what is a normal transaction ATM flow. So we will use this as an example. Maybe this will not be the case, but we use this just for this purpose. So we have that the ATM will send an authorization request through the ATM acquire processor and this will redirect to the switch and the switch at the end to the car issue processor. And after the ATM, when he tries to do an online transaction that requires an authorization request, the car issue processor will answer with an authorization response and that answer will be sent back to the ATM. So if at the end of these authorizations, the ATM see that everything is all right and that he can dispense the money, he will do so. And then the ATM will send a completion message to the car issue processor. This is like the normal flow. So when happens a reversal, a reversal happens when, for example, these are normal reversals. When an ATM sends the packets and at some point, there is no response. Every part in this flow have a timer. So if there is no response at some point of the flow, this will time out and a reversal could happen. In the second example, what we see is that not because of the timeout, but if something, for example, when the car issue processor responds to that authorization and send the response to the ATM and at some point in the switch or wherever, the response doesn't arrive to the ATM, well, that could also happen. That could also make a reversal to happen. And if the authorization responds and everything is right and the ATM is commanded to dispense the money, but the ATM then, when he tried to get the notes and try to dispense, he noticed that the ATM doesn't have the enough bills, the ATM will not dispense partial notes, will not dispense at all. And because of his will not dispense, he will send this message to the car issue processor. So they could know that they have to do a reversal to that account because the amount was already debit from the account and the customer will need back the money. So as I said before, what happens if we have an insider threat? Also a reversal could happen, well, this will be a reversal for, if at some point in the flow, the insider makes the reversal happen. So because he has access into the network. So now let's talk about car reader types. We have three types of car readers, the motorized, the deep and the swipes. The motorized is also called Carb before cash because you have to insert the card and the car will stay in the ATM in the car reader until the transaction ends. When the transaction ends, then the car will be given to you. The deep, we will just dip the card and that's just it. We can make the transaction and we will not need to insert again the card or left the card in the car reader. And the swipe, well, this will just rate the max stripe of the card. Now let's talk about the common ATM transaction reversal for scenarios. The first one is the card swallow. The card swallow happens when the card is inserted, a normal transaction is happening in the ATM, but the card is not taken. So when the card is not taken, this will cause a timeout and the ATM will know that the card needs to be swallowed by the motorized car reader. But when this happens, a reversal will also happen. And then, for example, at this point, the car holder didn't take the money because the money, some of the ATMs, for example, this is not so common in Latin America, so for example, I have seen this in United States that until the card is exposed and you take, then the money will be given in Latin America, for example, this doesn't happen. You insert the card, the car will be swallowed, you make the whole transaction, the money is given. And after you finish taking the money and everything, you will be given the card. So in this part, for example, what happens is that the card will be exposed from the card reader and you have to take the card so the money will be dispensed. But the money, it's in a phase called pre-present. So the notes are already stacked and are behind the shooter, but they are not dispensed already, but they are there. So when the card is not taken and this timeout arrives, the card will be swallowed and then the attacker will open the shooter, will force the shooter and will remove the card, will remove the cash, sorry, and the card will be lost. So this is the card swallow attack. We have also the money swallowed. This happens when the card is inserted, I make the normal transaction and the money is dispensed, but I will not take the money. So if I don't take the money, a timeout will happen again and the money will be swallowed by the dispenser. But at the point that the money will be swallowed, the attacker will hold the money, will get and force the retrieve of the money and a reversal will happen and then the card will be removed. So you get the money and the card. Also we have the card jam, so this happens when I insert the card, I do a normal transaction, but when the card is exposed, the card will not be taken, that will happen at a timeout and the card will be swallowed, but the attacker, instead of letting the card reader swallow the card, will hold the card that will make a reversal and then the shooter will be forced, the money will be grabbed and the cash will be removed. We have cashclown that they are using this artifact, so here we need two transactions, a normal alleged transaction number one that will be with a little amount, so just like $20. So I will ask the ATM to give me those $20 and when they give me the $20 and the shooter opens, I will insert the cashclown device. Then I take the money and end my transaction one, I start the transaction two and then I will ask for more money, the maximum amount allowed by the ATM and when the money will be dispensed, the cash will be trapped in this cashclown and when this happens, the ATM will be jammed and a reversal will occur. Then I will force the shooter, grab the money, grab the cashclown and remove everything and I will go. Another example is cash swap. The cash swap is when I insert a card, I make a normal transaction and the card will be ejected. When the card will be ejected, what I will do is to swap this card by another one, so I will use for example this magnetic stripe card, I put it down, I will swap it, I will grab my original card and the other one will be swallowed by the ATM. But at this, sorry, but at this swapping what will occur is a reversal and then I will force the shooter and remove the cash. This chip on the strip attack is one of the most advanced that we have seen and this is just using a carrier card with a chip strip that is above this one. So what we will do with this one is that we will insert this in the carrier when the card will be ejected. I will just remove the chip on the strip card, well part of that card and I will let that the carrier swallow the carrier card and because the carrier will not accept this magnetic strip card, we will make a reversal, we will jump the ATM and then we can force the shooter and remove the card. For example, we can see this video where I have the carrier, well, just a reader and I will try to see if this magnetic stripe carrier card will work with this chip on the strip card and yeah, we can see that we can read the EMV chip. So now this is a forensic case study that I attended. So in this project what we have is that the financial institution detected an abnormal amount of reversals. So they know which are the normal flow of reversals but suddenly they saw a spike in these reversals. But when I was called, they told me we know the modus operandi because we saw the records of the video cameras, we know which ATM error is produced in these reversals, we know how much money was stolen and we know the timeline and I was like, hey, well, if you know all of these, why am I here? But okay, let's see what I can do. So now we are going to try to study a little bit of the journal analysis and try to home for this transition reversal flow. The common normal, the common journal structure for a journal is like this. So we have a wide variety of journals and this could vary from vendor to vendor, from software to software, from ATM to ATM. So we have a lot of information out there and they are not, the journals normally are not concise structure order and they could lack information. Even when you have the same ATM of the same financial institution with the same software, I have seen that the journals are different or maybe sometimes they just remove information. But we will try to see, we will try to understand how a journal is structured and what are the parts that are most important to us. So even if the journal, journal from journal differs, we will try to get the high linings or the key parts that we will need to learn to detect transaction reversal flow. Also a common problem that I have seen in the journals is when they try to translate the journal. For example, in Mexico you can find the printed information in the recipe in Spanish, but in the United States you will find it in English and in China you will find it in Chinese. So when this translation happens, sometimes the financial institution decides that they will just need in the journal like the normal language, the words that I dispense it, how many notes, the account, the name, but they get rid of all of the error codes and all of that use information that is going to be needed when you will respond to an incident. So these error codes are called a status message and these may vary from vendor to vendor and they are really important and we will see a little bit of that. But a quick spot that we can look for in the ATMs that normally almost all the journals will have if they didn't strip this information is the answer to reset the cryptogram information data in the card analysis. This will contain the RQC, the RPC, an authorization number and the status message. So really quickly, the first thing that we will see in a journal, sometimes if we are looking off, is that we will have a delimiter for the transaction, a line that tells me here starts the journal and hit finish and in between these delimiter we will first find that the card was inserted and when the card is inserted we will have an answer to reset. So if this answer to reset, for example, T is equal to 0 and T is equal to 1 we will know that that card is a smart card. But if we have that T is equal to CL we will know that this is a contactless smart card. So then in the card analysis phase we will have this cryptogram information data and if we get an AAC answer we will know that the card declines the transaction. We are not talking about online transaction, we are not asking nothing to the switch already, we are just talking about the card analysis. So if we have an AAC that means that there is an application authentication cryptogram and that the card declined anything to do with that card. But if we have TC that is transaction certificate, we will know that the card approved the transaction. Then we will have our authorization request cryptogram that will make the online authorization. We will ask for the online authorization and then we will have the received information, the name, the date, the card, the account, the amount, the RQC, all of that information but the important here will be the authorization number. The authorization number will be defined by the transactional switch and will be shared between the ATM and the transactional switch. And also we will have a status message if we have an error or something happens in the ATM and then we will be we have the message of the card rejected and the transaction will be finished. So let's talk about the status message. The status message, this is like an example like normally we will see but this can differ from self-service software but let's use this as an example. This is from NTC, this is for NCR and we have that first we will have a transaction serial number that is just an ID that this is the error number one, this is error number two, something like that. Then we will have the message type. This will tell me if that error was unsolicited by the ATM or solicited by the ATM. Then we will have a device code. This will be the identifier of the hardware that makes the error. Then we will have a transaction status. This transaction status will tell me if the transaction was approved when that error happened or if the transaction was denied or what happened in that transaction. So for example, if I have a transaction error in the dispenser, we could have a lot of errors in the dispenser but this transaction status will tell me what happened if no bills were delivered, if only partial bills were delivered, if the dispenser don't know what happened to the money, that's something that will tell me the transaction status. Then we will have a more detailed information in the diagnostic status. And at the end, we will have a supply status. So all of this information is not the same in the self-service software because they are not the same but we will see a comparative table. So for example, some of the flavors that we have is the NDC, the NDX and the Diable 9-1-1 and 9-1-2. As we can see here, for example, the NDX will compose the M and R errors in just this status. So for example, the Diable 9-1-1-1-2 will not have that identifier at the beginning. So the status mentions, they can vary widely. They are not so easy to understand. They are not so easy to parse. You will need a specific documentation for that specific self-service software. So for example, self-service software can be shared between brands. So NDC could be used in Diable, in Wincor, and in NCR. And for example, Diable 9-1-1 could be in Wincor. But sometimes I have faced that when I have an incident, they tell me, oh, here you have the documentation of Diable 9-1-1 and 9-1-2. Because this is my Wincor ATM and this Wincor ATM is using this. OK. But when I see, yeah, the journal self-service software must be using that one, but it's not using. It's using instead NDC. So the Diable 9-1-1 documentation will not help me because the errors will be totally different by what the NDC will tell me. And also, the satisfaction at the end, if you understand them enough, well, you can script it. I have done some scripts. Please don't blame me because if I leave, I have to do it really quickly. So just a quick reference. For example, we will grab NDC. If I have an error E3, this will tell me that the dispenser that is the E have an error with number three that says that a fault in the dispenser occurred and they don't know what happened with some quantity in the bills. So if I have an E5 error, it will tell me that the bills were not taken by the car holder or were retracted to the rejected bin. So NCR has a paper that talks about transaction reversal fraud and they say that if you want to focus in transaction reversal fraud errors, you will have to look for E3 and E5. That means that you will have to look for errors in the dispenser with this quantity of bills dispenser is unknown and that maybe the bills were not taken by the car holder or were retracted to the rejected bin. Nevertheless, in my experience and what I have seen, for example, in Latin America is that also we can have an E2. The tool says that no bills were dispensed. So the dispenser will say, hey, no bills were dispensed, but indeed the attacker had access to the nodes. For example, also we can have errors in the car holder because as you saw before in the examples of transaction reversal fraud attacks, we can have these attacks due to the dispenser or due to the car holder. So if the car holder is swallowed, is swapped or those attacks, we could cause an error in the car holder. So we will also look for the D1 and D2. And this is just for the NDC. If we talk about DIBOL 9-1-1-9-1-2, we will have to look for another errors. And in the diagnostic status, we have more specific examples. For example, I have dealt with this number of diagnostic status errors, the 5, 14, and 30. So where they state that there is a sensor failure, the currency was gamed, the extruder was closed, or that the percent transport sensors were blocked or failed. So we can look for these E5, 5, E5, 14, E5, 30. And we can look for these transaction reversal fraud indicators. So really quickly, a quick reading of the journal. So please don't think there is too much information. We will just try to see what we learn and read this journal very quickly. I just composed this and this says, for example, this is my delimiter that the transaction starts at this date and the transaction ends at this date. Then we will see that the card was inserted. We see Q0 and T equal to 0. We know that the card is a smart card. Then we have TC. TC means that the card was approved for transaction. If we found here, for example, AAC, we will know that this AAC means that the card was rejected. So anything below that until the delimiter, we will not be interested because we know that the card didn't accept for the transaction. But we have TC, so we will keep reading. Then we see that the card holder entering the PIN, we have the RQC, and we have the cash notes here. Two, two, three, one. But this means, for example, in many examples for the table 9-1-1, 9-1-2, I have seen this, that this means that from cassette two, two notes were dispensate. And from cassette three, one notes were dispensate. And if we know that in cassette two, we have the currency of $20 and in the cassette three, we have the currency of $50, well, we already know just because of this line that the amount dispensate was $90. Then we will have the receipt information of the transaction, the name of the ATM, the date, the card, the account, the amount, the RQC, but here the important will be the authorization number. This authorization number, as I already told you, is the number given by the transaction ID, by the transaction on the switch. And we will see in the next slide why this is so important. And then we have here an status message, an error. And this status message says that this is the error number 9999 and that we have an unsolicited error by the ATM in the dispenser and that we have an unknown amount of bill dispensate and that the error is that the presenter, transport sensor blocked or failed. So we know that the dispenser have an error because of presenter, transport sensor blocked or failed and that an unknown amount of bills were dispensate. And then we have that the deber bin is not overfilled cassette one is empty, cassette two is low and those information about the suppliers that we don't care about in this moment. Here what we will care is about where the occur happens, what happened with the transaction and which is the detail of the error. And at the end the car was ejected and the transaction ended. But as we can see here, the transaction was fine. I mean, the car was accepted, the car analysis says that yeah, this car can do online transactions, the notes were dispensate. This is the most important. And we have an authorization number that this means that the transactional switch authorized the operation, but we found an error in the dispension. So talking about the transactional switch logs, we found that for example, when the ATM tries to make a transaction, he will ask to the transactional switch and the transactional switch, he will send an authorization request. The transactional switch will send back if it was approved or it was declined. But if he was approved, the transactional switch will set an authorization number and this authorization number will be shared with ATM. So when the ATM prints the journal of the receipt, he will wrote that authorization number. And this authorization number will still be there in the transactional switch. But at some point, as we saw in the previous example, we have an error and the ATM, something happened in the hardware and he informed to the transactional switch, hey, you know, you authorized this transaction, I accepted the authorization, I was going to give the money, but something's happened with the dispenser and I don't know what happened to the notes. So I'm sending you this error, so you will make a reversal because the customer will need the record of that amount. So then the transactional switch will receive this error and will know that he will need to do a reversal and the transactional switch will use the same authorization number to do the reversal. So if you go to the logs of the transactional switch, you will find two logs of this, one that was the authorization number where the transactional switch approved the transaction and another one where the transactional switch is going to do the reversal. So the authorization numbers for transactional switch logs are key for an investigation. You cannot just do an analysis or respond to an incident of transactional reversal flow by just having the journal of the ATMs, you will go to the transactional switch, request those logs and try to do that much. So at the end of this project of this case study that I answered, what happened? The customer, the financial institution already knew that the modus operandi, because they saw the records of the CCTV, they knew the ATM error producing the reversals, they knew the amounts, they knew the dates, they almost had everything. But when I start to do this analysis on all of these 1,000 and 1,000 of journals, I found the correct ATM error. So I saw that the ATM error code that they told me and that was producing the reversals was not the correct. Indeed, the status message was different. So I identified this new status message and with this new status message, also I found a lot of new records. And with all of these, obviously the amount of money lost increases what they knew before. Also, later than this, I found some behavioral patterns. So for example, what I saw here is that the person that was doing this transaction reversal flow in these ATMs was using a card and then he was swapping to another card and he was using four cards. So I saw these consecutive transactions by the same person with different cards. How can I know that it was the same person because of the timestamps? I saw that it just takes like five seconds between transaction to transaction. And I have seen, I don't know, the normal time between transaction could be one minute, two minutes, five minutes, 10 minutes, one hour. But five seconds between each transaction, I could know that it was just the time between you take the card and insert one, take the card and insert one. So I could see just from the journal analysis that it was the same person. And also that he was using a pattern. So he was using four cards, doing the transaction reversal flow, getting the money and he left. But one hour later, he returned and do the same and use it the same four cards. And then he left and he returned again. So he used it four cards three times in one day just in that ATM. So that's some of the things that we could know because if we could identify this, hey, he's doing this one hour, hey, let's just try to see if that happens again in the same hour, in one hour later and maybe we could grab the person, I don't know. So at the end, my recommendation for this financial institution was to monitor that specific error that I gave to them, that specific status message that was working for them. To correlate this transactional switch logs with the journal logs and to make some, to analyze and do some behavioral patterns, triggers for transaction reversal flow indicators. So at the end of this talk, what I want to say is some recommendations, but I will go upside down because I have found this recommendation somewhere that is to not recredit the transaction and did with customer complaints. That means that if I go to the ATM and I try to make a normal transaction, legit transaction and the ATM doesn't have the money but they already divided that money from my account, they will not recredit that amount in my account. So I will have to go to the bank and I will have to complain and say, hey, you have to give me my money back. This is for me like the worst recommendation that somebody can give, but it's okay. And some of general recommendations that I have found also is to monitor for some increments on reversal activity. So we can defer if this is normal reversal activity or is fraudulent activity. We have to rely on CCTV records to determine the physical modus operandi because yeah, we can know what they are doing by the journals, we can learn the errors, we can know something, but at the end, if we see with the records of the cameras, we can specifically know what are they doing. And also I have heard that some ATMs have some anti-transaction reversal for enhancements. So for example, for example, they have some anti-cash cloud device, so they will not be able to do that attack and they have hardened the shooter, they have hardened the transport mechanism. The truth is that I don't know, I haven't seen this on the wild. But my recommendations will be to monitor, correlate, analyze status message. These are goals for not only for transaction reversal fraud, but for many ATM attacks. So this can happen on real time or we can do it later, it just can be host-based or this can be on the network. Of course, if we do this real time on the network will be the best thing. But we could have also an agent will be monitoring for errors in the journal and that when something happens, it will trigger and will be sent to my correlation software. Also, from the status message analysis, we can create some behavioral pattern score to determine if that activity could be maybe risky. If that's maybe some fraudulent reversal or it is just normal reversal, will still be happening in the ATMs because it's neat. And also the most important will be to test and research and perform regular ATM security reviews. And by this, I mean not just boring my ATM with Kali because I have seen many person that just do this and hey, I am a hacker of ATMs, no. We have to do one internal ATM security review that involves a lot of things. And the last one is that sharing is caring. So if you have some artifacts and you can share it with me, I will write about all of these different self-service software errors that I have seen. I will write a blog post or something, which I say, hey, I have these MDC, MDX, Diabol 911, Triton software, all of these errors and say, hey, this could be some of the triggers for transaction reversal fraud. You have to take care of this but at the end is not a receipt, you know? So you have to do your own test, you have to research, you have to test on not only on the laboratory but also on the, well, sorry. Yeah, you have to test all of the ATMs that you can in different scenarios to see what are you analyzing, what are you logging, how do you look, looks like? Because as I already told you from bank to bank, from vendor to vendor, from software to software from ATM to ATM, not always the same. So you will need to do this research before responding to one incident because for example, in this incident, I just have like one week and so I was able to do this research was not that easy. Also because one of the first slides, there is not too much information available so I went to share a little bit of this. I will try to share these artifacts with the community and yeah, I think that's it. So.