What does the bleeding edge of Magecart-style attacks look like? Why do sophisticated security professionals at large, respected retailers find themselves struggling to detect these attacks? How can merchants up their cyber security game and do better preventing these kinds of attacks?
Idan Cohen, CEO of Reflectiz, shares years of cybersecurity experience to shed light on the true extent and potential damage of malicious code injections.
Below is a complete transcript of the podcast for our hearing impaired audience.
Bradley Chalupski: In today’s competitive e-commerce environment, it’s never been more important to earn and maintain the trust of your customers. Merchant Fraud Journal’s “To Catch a Fraudster Podcast” is supported by Sift – the leader in digital trust and safety. Sift empowers companies to stop fraud and grow without risk. Visit sift.com/assessment to schedule a consultation with Sift’s trust and safety architects – industry experts who have decades of fraud-fighting experience at companies like Facebook, Square, and Google. They’ll help create a custom plan for your business with an emphasis on technology, organizational structure, and process. Visit sift.com/assessment today.
Bradley Chalupski: Idan, thanks so much for joining us.
Idan Cohen: Thank you, Bradley. Happy to be here.
Bradley Chalupski: So, let’s start with telling us who you are, where are you from, who you represent, and then we’ll take it from there.
Idan Cohen: Thank you, again. I’m Idan. I’m the CEO of Reflectiz. Reflectiz is a cybersecurity company focused on mitigating the risk created by third-party applications on a website and we will talk about it during our focus today; 31 years old; actually have a new baby in the house, that’s a few weeks ago. So, enjoying the new life to be a father and the co-founder of Reflectiz. From Israel. That’s me.
Bradley Chalupski: All right. Well, thanks so much for joining us. So, the reason that we wanted to have you on the podcast is because this issue of cybersecurity is becoming more and more intertwined with the idea of e-commerce fraud. I feel like maybe five years ago, they were thought of as similar but still very much different. Whereas now it’s the opposite, where they’re thought of as mostly the same, and then there’s kind of a little bit that might be different on either of the two competencies. So, I want you to start off by talking about where we are in cybersecurity today, vis-à-vis fraud. And as always on this podcast, any stories that you have that can illustrate what you’re talking about, we’d love to hear, and then we can continue talking about it from there.
Idan Cohen: Happily. So, cybersecurity is not something new, of course. We are doing it for many years now. But we did see, in the last few years, a great new type of attack – so, a new type of threat – that’s made me mainly focus on e-commerce companies and set it a big risk for them. Some call it in the name of [03:08 inaudible] or Westing attack. But the idea that’s today, because we all go digital and many businesses are now creating maybe their first online store or moving their operation online. They need to be aware that in cybersecurity today means absolutely they are a big reason to handle. And it’s become maybe one of the most common ways to breach organizations. And we are seeing it all over the place. We are seeing it in big enterprises and small ones – small shops on Shopify and big companies that have their own platform [03:42 inaudible] from their website from what we are calling web scanning or digital attack on their website. And this will be a whereabout about it.
Bradley Chalupski: Before we move on to the solution, I definitely want to jump into this a lot more, because I think there’s still a lot of misunderstandings or just blind spots in people’s knowledge of how this operates. So, take me through how it’s possible that these attacks happen. What is going on on the fraudster’s end? Where is the genesis idea of what they’re trying to attack, the vulnerabilities that they’re trying to find, and what are they doing to exploit them?
Idan Cohen: So, let’s start from the basics. So, when you, as the owner of the site, create your own site, you want now to sell something. You want to have something we call a website. And the website has, let’s say, two main areas; they are what we’re calling the server-side and the client-side. So, the server-side is your own server, this bit code that you’re running, and maybe there you can decide which product you’re going to sell or what is the platform you’re going to use, the server, security of them. And that’s what we use to protect. If you go five years to the back, ten years to the back, most of the security tools try to protect the server-side; try to protect your own host, your own platform to make sure that you’re secured. And I will try to show some names here but everyone has something like a WAF, like a web security tool to try to protect the website. And that’s what we did. So, five years to the past: server security, server security, server security.
Idan Cohen: In the last few years, something changed [05:48 inaudible]. So, they started to think not to attack the server itself, let’s go attack the client. And when I say in “the client,” I’m talking about attacking the end-user, the user that’s actually going to the website and maybe typing his credit card number, or maybe collecting some data on him. So, why do you want to attack the client? Why not go attack the server? Because when you’re attacking the client, you actually don’t have any security tools that are blocking you. Because me, as the website owner, can’t really protect every computer around the world. I can’t make sure what’s going on in every one of my users. I can protect maybe my servers, but I can’t protect the [06:33 inaudible]. And that’s what we’re seeing in the last few years. The movement from the server-based attacks to the client-side attacks.
Idan Cohen: So, now, let’s start to explain a bit what it means by client-side attacks and how it works. So, when you’re visiting a website, so let’s say you’re going to your best piece of the platform and you are going to the website, you’re getting on the server what you’re calling HTML page. Actually, your browser – your Chrome browser, your Firefox, your Internet Explorer browser is loading a page into your computer. The page you’re loading it on the computer is the website you know about. You see the product, you see the colors of the site, you maybe see the pricing, you see the form that you need to put maybe [07:25 inaudible] – you are getting it from the server and it’s all running on your own browser – browser meaning your Chrome, your Firefox. But when it’s loaded into your Chrome, it doesn’t stop there; it’s not like you’re just loading a page, and then you’re stopping. In that phase, actually, a lot of stuff keeps going on on your browser, because you’re moving your mouse. So, when you’re moving the mouse, maybe something will need to pop up, maybe there is a difference if you’re using a browser in your computer or browser in your mobile. So, actually, there is a lot of code that’s still happening on the user to make sure the site works, let’s say, in the most efficient way; the engagement is better; you want to have analytics that you see what the user is doing. A lot of stuff is going on the browser. And this is the place that attackers want to hack [08:25 inaudible] the party.
Bradley Chalupski: I just want to make sure we drive home that point that what you’re talking about is all the different types of softwares that people run on their business websites in order to collect analytics, in order to measure whatever they’re measuring. I think that was the thing that was most shocking to me when we were preparing for this interview, is the idea that there’s no way to close this off. You can’t run a website today that’s totally self-contained. You are required to have other people’s code running on your website that you, by definition, don’t have control over. And I think that’s the part that’s really shocking to people when they hear it for the first time.
Idan Cohen: Yes, exactly. The idea that the way that the world is built today, the website world is built today, you don’t have any other option. A single website can have more than 50, 60, 70 different applications software running on the user browser in order to make a lot of stuff; it can be analytics, engagement, maybe some advertising tools, some kind of code, a framework that other developers make a better experience. Even when you’re seeing a nice graph, like a pie chart. [09:54 inaudible] decided didn’t draw the pie chart because they just went to some kind of repository that someone else created, that no one was to outdraw the graph, and thus, copy-pasted. So, you get all this code and you’re sending it to the client-side, meaning you’re sending it to your good user, your user that just decided to buy something. But that’s when you get the problem. Because when all this code is going to the browser, I don’t have eyes anymore that what is actually doing. I don’t know if it’s doing what it’s supposed to do, let’s say collect analytics to tell me if I like the product or not; or it’s reading my keyboard typing and sending it to a different location, because it’s all on the client-side and out of my sight and I have no longer control on that area. And that’s what the attackers understand in the last few years – instead of attacking the server, and then to need to fight with all the security tools and analytics and security experts viewing every possible request, well, let us change the code that runs on the browser side, on the client-side and no one will ever know until the damage has been done.
Bradley Chalupski: So, I want you to take me through what it is that hackers can do with this type of vector? Because I think, for me who’s not technical, and some of our fraud analysts who are analytical but not necessarily technical, what are you able to do by attacking this client-side code? Because it would seem that if someone’s not hacking into your system, how much damage could that really cause?
Idan Cohen: So, when you’re running a code on your browser, you can actually do everything that the site itself can do. When you are the browser, I can decide what I will see, what I will do, what I will click. So, actually, as an attacker, I can do everything that I want; I can change the page, hence change the prices with what I’m thinking for the price on the site; I can read the different types, the different keys that the user is typing. So, let’s say that you have a credit card number form, like, you need to pay something, and you type your name and your credit card details. If I’m the browser and I’m running on the browser side, I can actually read everything you type on your keyboard. And when I read all the stuff, you’re typing on the keyboard, I can then send it to a different location, that’s actually the most common attack which I gave you, for example, a few minutes from now. I can redirect you to a bad site. It’s something very common that we’re seeing today, which is advertising, which you’re getting advertised that redirects you to a malicious site or illegitimate site, and you don’t know how you get there. But suddenly your browser starts loading and a bad page [13:18 inaudible].
Idan Cohen: So, when I’m running on the user, I can actually do everything that is possible from a browsing point of view: open a new page, change the text, do actions from the [13:31 inaudible] of the users, click a button, type on the keyboard, or just see what user is actually doing. I can’t [13:39 inaudible] the server from there, yes, because it’s the client-side of that. The server will have all the access to the user data but it won’t have the access to the site itself data. And the best way, I think, to explain it is to explain via an example. So, in 2018, British Airways got attacked by a breach by a client-side attack [14:01 inaudible]. So, what the attackers did, they found an AB testing tool that the Air British server used called Modernizr, and wherever to change the code. Not a big change, don’t get me wrong, not a big change. They absolutely changed and edited only one new line – that’s one line to the code. The line was, collect the keys that have been typed by the user and send it to a different location. That’s all – one line. I can show you the code if you want. So, when they changed and edited this line, and now I wanted to buy a flight in British Airways website; I, as a user, went to the website, went and booked a flight, and got to my browser, got the HTML, the page with the one line of message code. In that area, I didn’t know that something has changed. For me, it’s the same page. I see the logo of British Airways, I see the color, I see this form, it’s all the same. So, I got the phone, I started my details in order to pay and book the flight, typed the credit card numbers. And then this one-liner that was already there, because I just loaded it. So, my browser told my computer, “Oh, thank you for typing the credit card number, but please send it also – in your case – to the bad place, to the attackers.” So, you can say, “Oh, well, it’s only one user, what’s the damage? British Airways is a big company so one user got his data.” But it’s not one user, it’s not one client. This attack, for example, was live, it’s estimated around 15 days straight. In 15 days, more than 380,000 people try to book a flight or at least put the character numbers on the British Airways website. So, for 15 days, 380,000 people lost the credit cards to the attackers. And that’s a big deal.
Bradley Chalupski: A big deal – that’s exactly what I was going to say. From a merchant perspective, it’s not only about whether or not you’re being stolen from. Because obviously British Airways is not being directly thieved from in this instance, but what is happening is their customers are having their information stolen. And as we know, it always gets back to the customer that their information was stolen from you. And we’ve had many people on this podcast talking about there is data that proves the idea that once a customer hears that you are vulnerable and that you’ve let their information get stolen, they are definitely much more likely to go and seek out a competitor, even in a world where most of us expect that there’s a lot of security and vulnerability out there when we use the internet. So, this is definitely a huge problem for merchants, even though it’s not traditional in the sense that they’re not getting stolen from, at least in this specific example. But I want you to take me down the rabbit hole of how this is actually possible. What is going on on British Airways is? And their technical staff, I’m sure they have great technical people that work there. It’s a huge multinational corporation. I’m sure they pay top dollar. I’m sure they have a lot of people that want to work there. I’m sure they’re good at what they do. So, take me through how something like this happens. How it’s able to fly under the radar for so long. And then what actually tips them off in the end that there is a problem?
Idan Cohen: So, there are around three main ways to create the kind of attack that happened to British Airways. And in general, it’s more complicated. But to make it simple, if I am an attacker and I want to do this kind of attack on British Airways, I have three main options, always, to think how to do it. The first way is to find a vulnerability on one of these servers of British Airways. So, you’re right, British Airways have a lot of security, good security guy and a big team of security experts. But they also have a lot of resources, and a lot of servers, and a lot of website owners and teams that manage the sites. The attacker only need to find one place where the British server did a mistake – only one place – one server that maybe is available from outside to change some code, maybe if they have some kind of open hosting service so they can just add the one line. Don’t forget that all of that [19:05 inaudible] British Airways was just to find one place, one server to add one line of code that in there loaded the HTML. So, the first way is what we call [19:15 inaudible] attack. We find the bad server, the one mistake the company did, that allow me to interfere to change the HTML, to change the page that was loaded to the site, and create my own code. And it’s not easy to do, of course, compared to the company size and the amount of resources that they have but it did happen.
Idan Cohen: I didn’t say in the beginning but my entire career I started as an offensive security hacker. I manage one of the biggest offensive security companies in Israel. And my job was to do exactly that – to find the smallest mistake that maybe you did as the owner which allow me to get in. And I don’t need from you to make a lot of mistakes, I need you to make just a few just to give me the access point, the way to get inside. And once I’m inside your internal networks or your website hosting, then it’s much easier for me to just alter the pages or change something else.
Idan Cohen: So, the first way is to find this bad server and change the code. The second way, to me, is an attacker. If we try to attack the framework itself, so many today, especially in the retail world, are using known platforms like Shopify, WooCommerce, [20:42 inaudible], platforms that actually store the shops for you. So you don’t need to create a technical staff. You don’t need [20:53 inaudible] or bill to have a lot of experts from the engineering point of view. You just go into [20:58 inaudible] to your shop and upload your products. And the attackers, most of the attackers, actually trying to target these platforms because the win there is big. For instance, the most common term we’re talking about is web skimming and cybersecurity for retails is a thing called Magecart. Magecart is the name of this kind of attack – attack for [21:21 inaudible]. And the term Magecart comes from Magento, from the meet e-commerce platform to use today. So, the attackers went to the platform, investigated the platform, and tried to find the vulnerability, tried to find the problems with the way they build the platforms. And when the attackers find some kind of vulnerability, they can now bridge with less vulnerability, all the sorts of many of the subjects using this kind of platform. So, instead of just attacking one company that’s attacking no one British Airways, I can just try to breach thousands of Magento users or thousands of Shopify users. It’s actually the most common way for midsize small businesses to be breached by a web skimming attack or a digital security attack.
Idan Cohen: So, if British Airways was a targeted attack, with attackers trying to find the specific vulnerability in the servers of British Airways, for the common smaller retail, no one will target them specifically. They will target the platform, the Magento, the Shopify [22:32 inaudible], and it will try to find a vulnerability with [22:35 inaudible] all around the world and hack thousands of shops around the world. So, let’s [22:48 inaudible] because that’s, I think, the most interesting and surprising way. And that’s the thing I didn’t explain at the beginning, but I think you will find it a bit surprising.
Idan Cohen: So, the third way is what we are calling a web supply chain attack. And for that, I will need to explain a bit. So, maybe just ask a question before, so then [23:09 inaudible] about how you can do supply chain or your retail sell.
Bradley Chalupski: Go ahead. I’m really interested to hear.
Idan Cohen: So, if you remember, we talked that on the browser, you have a lot of applications running, like your analytics tool or advertise tools in order to do all the stuff we can do. Those tools didn’t create by the site itself, they’re created by a third party, they’re created by a decent vendor that read the code, that created the code. So, the easiest example is Google Analytics. So, Google Analytics, anyone using it almost around the world. And Google Analytics is created by Google, not by me or this shop. But the way that the browser is working is that I first tell the browser, “Load the code from Google.” For every one that I think ever saw and heard us and know and installed the tag of Google Analytics will know how it’s done. You just add one line of code asking to load data with Google. And what happens is that I, the user, get the HTML. And then my browser, my computer is actually going to Google, or Mixpanel, or Hotjar, or any other window and read the code from their… directly connection with the browser, the end-user, and Google or other vendors. And in this case, if the vendor will be breached, I will never know about it and all my clients will get the malicious code. That’s exactly what happened to Ticketmaster two years ago. So, Ticketmaster worked with a chatbot company from the States. And apparently, the chatbot company got breached – not Ticketmaster, that chatbot company got breached. And the attackers were able to change the code that was stalled on the chatbot company. And then everyone that wanted to buy a ticket in Ticketmaster, I think the UK, and went to the site, got in the page that they loaded, they got the request to get the code from the chatbot company. So, they went to the chatbot company, and that loaded the malicious code to the one browser.
Idan Cohen: So, think about the unique situation here. Ticketmaster, in theory, didn’t do something wrong – no one breached one of their servers, no one breached the platform they’re using. Actually, nothing happened on their own area. But because the added attack focused third party or a fourth party, then automatically all the users loaded the bad code. And that’s what you call a web supply chain attack. Supply chain is about your suppliers, and web supply chain because it’s the way that the browser’s working today – they’re going directly to the vendor, they’re not going through Ticketmaster. Ticketmaster was not able to see the communication and to know that there is an issue. It’s not about their infrastructure; it’s a direct communication between the end-user and the vendor. And that’s the third way that you can [26:41 inaudible] the situation, and you’re breaching a website, you’re hacking a client.
Bradley Chalupski: That’s really incredible to hear. And I think, for many people, it’s going to be a real shock to know that you are so vulnerable. And this is a great segue into detection and prevention. And I’m curious, one, what you can do at your sites to detect this? I know you said if you’re a merchant, that you will really have control over what goes on with Shopify’s code. Is there anything that you could do on your end that will be a red flag that somebody has targeted your website through Shopify’s code or for larger multinationals? Because our audience includes all types of companies who are in control of what they’re doing more than your average small-to-medium-sized merchant, what they can be doing to detect this not technologically? I want to get to the technology part second, but I also want to talk about the way that these hackers operate so that people can see the patterns in the attacks when they start to get maybe complaints from customers or seeing money going out the door. So, if you could talk about both, that and the technological way, and then that’ll lead us into prevention.
Idan Cohen: So, the challenge here that it’s not easy to you as their [28:18 inaudible], to know that you’ve been hacked by a client [28:21 inaudible]. And that’s exactly the main problem in that area. So, when you’re asking me, how can I know? Actually, it’s not really easy to know. Assuming you don’t have specific tools designed to block or detect these kinds of attacks, you will need us to go to a website every few minutes or days or hours, open the browser, and see the logs. If something in your own logs, in the browser logs, something goes wrong; you don’t have eyes there at all.
Bradley Chalupski: To clarify, when you’re talking about BA (British Airways), obviously, they were alerted to the problem, I assume, because many people, who were their clients, were reporting that their information has been stolen. Are you aware of any kind of volume that these types of attackers go for? Where if you start to see a 5%, 10% increase in the amount of customers who are reporting that their information is stolen? When should you start to think from the information you’re getting from customers that you might have a problem like this?
Idan Cohen: I will do it from the first complaint. If you have a customer that sees something strange on your website, then maybe I guess he has some kind of a bit more technology expertise, for instance, something goes wrong, I won’t wait for the 10 or 15 complaints, I will go and see it ASAP, it probably will be right. Because when you know how this stuff is going, you probably will understand that you have a problem. So, I won’t wait for the 5% complaints, I will go after the first complaint. Then at least checkout and check the pages that you have there. There are ways to detect attacks today. There are ways, I don’t think [30:20 inaudible] a lot of options back then. But today, there are good ways to detect those kinds of attacks, but it’s out of there. It’s out there because, again, it’s on the client-side. So, you need either to have a browser or to have a smart user, a smart client that understands that his browser is acting wrong. And yes, British Airways has got complaints from users, and also I know they’re getting from with other security companies that were monitoring the attackers themselves, and then so the attacks. So, they got a little some [30:53 inaudible], and then understand that they have a problem.
Bradley Chalupski: So, this brings us to what you guys do as a company – detection and prevention at the technological level. So, I’m curious, from my perspective, as someone who’s not really technical, it seems almost impossible to figure this out if you don’t have some kind of log of every little piece of code that’s supposed to be there that’s tagged to why it’s there. And it just seems extremely cumbersome and difficult to try to do this. So, why don’t you take us through that technological level, and the detection, and then into prevention, and how that works?
Idan Cohen: So, there are several stuff you as a store owner can do in order to reduce the risk. Let’s start from the basic, you want to make sure that you’re doing regular testing of your cybersecurity perspective, that’s always important. And it’s very common today to do what we call penetration testing or to develop vulnerability scanners to make sure that your servers are secure, and it’s important to do it. Now, after we finish with the basic and common stuff, then I will send you at the beginning, try to keep to a minimum, the third-party code you’re adding to your site. I’m not saying third-party code or script is bad, I know that they are in use, but be smart; use the ones you need and put them in places that you need them to be there. So, for instance, if you have a checkout page, and in the checkout page, that’s the place where you’re actually typing your credit card number; try to reduce to a minimum, the external code running on your checkout page. Try to keep there only the most important stuff that you need. And it is classical of risk mitigation. You don’t need to have so many external cords running on your sensitive pages. Keep them in the less sensitive areas.
Idan Cohen: So, after you do some of those scripts, I will also advise you, if you’re using some kind of open-source frameworks like Magento and others, to make sure they’re always updated to the latest version because they are keeping them secure as they can to make so they don’t have vulnerabilities. Also those known platforms as Shopify, WooCommerce, they are working very hard with big teams in order to make sure the platform is secured. And if it’s not secured, they will define vulnerability by trying to fix it ASAP. So, now that you have your platform updated and secured, and you try to keep to a minimum, the external code that you’re running to your site. Now, let’s talk a bit about how to specifically address the challenge of the client-side attacks or how you can really mitigate the risk. So, to start your height, you need to have eyes on what happened on the user side. You need to have the ability to log, as you said, all the activities, all the stuff that’s going in the client-side in order for them to understand if one of these activities is not a legitimate activity.
Idan Cohen: Now, there are two main approaches to how you can get these eyes; the ability to monitor everything that’s going on. One of [34:28 inaudible] is to install another tool, another script on your site that will be your eyes. So, except for loading the analytics tools and [34:40 inaudible] tools, you will also load another tool whose job is to look at all the other tools. It’s a very common approach. You will get the new third party, that new third party will be like the manager third party, and everyone who will do something on the page will need to go through the script or this tool. And then it will monitor you if you have any issues. There are solutions today to do it like this. There are upsides and downsides to that. But that’s one way to solve the problem. So, think about it, let’s install a security tool that will run on the browser – so, it won’t do anything on the server. It will be loaded to the user. It will be loaded on the first page. And because it’s really the first, you will be able to see what others are doing and alert you or block you if you have any problem.
Idan Cohen: The second approach – and at the beginning, [35:34 inaudible] so, that’s actually the fourth – We chose to do the other way around is to simulate the user. If we know the DoS attack could happen on the browser, let’s bring the browser to the story. So, in those [35:51 inaudible], you actually take the browser, take Chrome like we did, and visit your website and visit the store and act as a user, and moving the mouse, and typing the numbers, and circulating the menus – actually, doing anything that the user will do. And then because I’m the browser, because I’m the user who’s visiting the website, actually all the attacks will happen on me. Yes, developing on my browser, they will actually tell my browser to load the malicious code, or they actually [36:21 inaudible] into my typing in the keyboard. And then if you are a smart browser, you will see the attack easily, because they’re actually attacking their own security tool. In this approach, you can actually go live very fast because you don’t need to install anything on the shop side, you can just visit the shop from remote as a browser and then detect any attacks easily. So, those are the two main, generally speaking, but those are the two main ways that security companies today trying to block this kind of attacks, either to install a tool that will be loaded to the user and then will be like the supervisor of the HTML or to simulate the user that visits the website itself.
Bradley Chalupski: So, can you give me any examples – maybe as we get ready to wind down the conversation – of an attack that you’ve seen, and that you detected, and that you were able to prevent, and what the results of that were? I think that would be really interesting for our audience.
Idan Cohen: So, I have a good example that will also help us to summarize this kind of attack [37:36 inaudible]. So, the most common tools today in the web is Google Analytics and Google Tag Manager, and everyone is using them. Because we, the attackers, also know that the best way to confuse site owners and to make them vulnerable is to trick them to think that you have Google Analytics but to send the Google Analytics to a malicious Google Analytics. So, actually, we found thousands of websites that got hacked, though, in 2020. And the way they got hacked, that the attacker was able to upload to their own servers, a Google Analytics script. But it was not a Google Analytics script, it was a Gocgle Analytics script. They changed one letter from G-O-O-G-L-E to G-O-C-G-L-E. So, they have the same kind of Google [38:32 inaudible], changed one letter. So, the code was loaded to the different users that were browsing the page. And then what your browser did, it went to gocgleanalytics.com and loaded the malicious code. Now, the malicious code was a normal web skimmer that tried to collect credit card data. But after that is finished to skim the data, it went to Google Analytics, the real Google Analytics, and loaded legitimate regular code. So, the site owner didn’t see problems with Google Analytics. For him, Google Analytics was still running. But when the end-user, they started from the malicious entity. So, that was a very tricky attack to find. Because for the naked eye, it seems legitimate – it’s the same type of Google, just one letter changed. When you have so many lines and so many scripts, it’s very easy to fall and not to see it. And the shop didn’t know about it, because in the end, Google Analytics kept tracking of the website like it’s supposed to do.
Bradley Chalupski: So, you make the mistake once and then you forget about it, and you just don’t even know that it’s going on.
Idan Cohen: Yes. And actually, someone reached out to us to try to tell us that they think that they have problems, but they didn’t know where is the problem. They got complaints from users saying that they think they have some kind of malicious code but he didn’t find the malicious code. Because when you look on your website and check the checkout pages and [40:09 inaudible] page [40:10 inaudible]; You didn’t see anything wrong. We saw only the tool of Google Analytics. Actually, what the attackers did, that is a nice technical trick. If you will look in your eyes, you will see googleanalytics.com. But then a few lines after, they replaced the O with C. So, we need to understand that really there is some kind of replace action [40:35 inaudible] after the name, which sent on Google to Gocgle. And that’s [40:40 inaudible]. We call it the Gocgle Attack. They used a lot of different tricks of Google name like a Gocgle Tag Analytics, [40:50 inaudible] Tag Analytics, like these names, in order to make sure that no one will take them out, or at least to make it harder to detect them. Because they know, they will be detected in the end. But as British Airways go 15 days live, and I think Ticketmaster was five months or four months live, they want to make sure they will [41:11 inaudible] to keep their code with much time up until the discovery because every day it’s live, more credit cards, more users, more PII data will be extracted.
Bradley Chalupski: Well, Idan, I really appreciate you coming on and sharing this with us. I think it’s a really important conversation because it’s something that, I think, still flies under the radar a little bit in the fraud prevention industry because it is more technical. So, we really appreciate you coming on and laying it out, and showing us the examples that you don’t need to take it from you; you can see the havoc that is wrecked when these types of attacks are successful, and what it can do to brand reputation, and that’s a nightmare that nobody wants to deal with. So, we really, really appreciate you coming on. To sign off, why don’t you let everyone know, again, where they can find you on the web, and then we’ll get going.
Idan Cohen: So, if you want to hear more about the attacks, about the way to solve them, or just about Reflectiz; you can always visit us at reflectiz.com, and just look for us in the internet. I guess, in the podcast when you publish, you would also add a link. [42:31 inaudible] we have a lot of interesting stuff in our blog – from writing about different attacks around the world to how to mitigate them, to technical examples and business examples. [42:42 inaudible] if you guys want to learn more, we have a very interesting blog to you to go and read and learn about this new threat that you should know about as a retailer, also, you should know about it.
Bradley Chalupski: All right, Idan, we really appreciate your time. Thanks so much for joining us.
Idan Cohen: Happy to be here.
Bradley Chalupski: Take care.
