 Hello, Blue Team Village at DEFCON 3010Ds. My name is Matt Shear. You may follow me on Twitter at C3RKAH. My talk is called LemmierIRs. A slide deck is available by going to slides.dfirmat.com, which will take you to my GitHub repository. What I do is I work for a big, well-known organization as an assistant vice president of computer security and incident response. However, I have many years of hands-on technical experience, including digital forensics and incident response. I'm also a podcast host for ThreatReel. Where I volunteer is I'm an official hacking is not a crime advocate. I am also a WAMSA, which is the Women's Security Alliance Technical Mentor. Please check out their websites for additional details on those organizations. A quick disclaimer is that, yes, I have a day job. However, opinions expressed are based solely on my own independent security research, and did not express or reflect the views or opinions of my employer. My objectives are to show demo reenactments of real attacks, how these real-world attacks worked, how and why they defeated security solutions, and then show incident responses to these attacks, demo investigation tools and techniques, and discuss lessons learned in key takeaways. Just so we're all starting on the same page, some acronyms that will be used are IOC or IOC, which is an indicator of compromise, IR, which is incident response, and DFIR, which is digital forensics and incident response. Other disclaimers, demos are based on 100% true stories. These demos dutifully recreate actual attacks. However, some details were altered. Also, investigation demos are sped up considerably in the interest of allotted presentation time, and I will be doing demos on a live system. However, please pretend that's a sandbox because one should only perform these techniques in a dedicated and securely isolated and volatile sandbox. My first scenario is called the mystery attachment. Let me preface this scenario by saying there was a news headline from August 17th of 2018, and the headline was MouseBand Campaign targets banks using Microsoft Publisher. This was very unusual. Not that MouseBand campaigns or targeting banks is unusual, but it was the fact that the threat actors were using Microsoft Publisher to deliver their payload. You expect to find those type of payloads in Microsoft Word or Microsoft Excel, things that can have macros. You might even expect to see them within Adobe PDF files, but to see this distributed through Microsoft Publisher was very unusual. The headline was The Fault Amy Rat was part of and occurs botnet is reported by researchers at TrustWave, and there's a link in the slide deck to that article. After that was released, it was picked up by a number of other news agencies. The following week, as I'm sitting at my desk dutifully multitasking on a lot of things, I had somebody run up to my desk and they are very anxious in a frantic manner. They're saying, Matt, help one of our VIPs with access to lots of very sensitive information just got hit in that recent MouseBand campaign targeting banks. It matches the IOCs from reports of that new flawed Amy rat, which is part of the occurs botnet. The recipient attempted to open the Microsoft Publisher attachment on their smartphone. I need you to drop whatever you are doing and investigate this. We'll get you the attachment ASAP. In this instance, I'm not particularly the best mobile forensics person or the best mobile incident responder, but there really wasn't anybody else qualified to look at it. So I agreed that I would be happy to do it. And when they first came up to my desk, I'm really focused on thinking through what I'm gonna do with the investigation because they stood there and continued talking. Really, they sort of got me amped up and worked up because of their anxiety. So to talk through the investigation of this scenario, we're gonna open up the file in the sandbox. Now, in my case, I'm doing this on a live Linux system. I do not have Microsoft Publisher available to me. So I'm gonna open the file inside of Libre Office draw. And for our purposes, we'll just have to pretend that is the professional sandbox that has Microsoft Publisher in it. I'm gonna do a strings demo and then I'm gonna hash the file and show everyone what the search look like. Now that's a very small snippet. I actually spent a lot of time investigating, researching and reading about Flotami, reading about Necurz, looking for indicators to compromise, looking for any details that would help explain what this does and how it works. And then finally, I will take a look at the exit data and demo that as I ponder my next steps. So let's go ahead and take a look at the file. Again, this is inside of Libre Office draw. In Microsoft Publisher, I couldn't actually find where the macros were at and I myself never used Microsoft Publisher. So I was a little lost. What was interesting though is the publisher file itself sort of looked like this. It came up and stated that macros had to be enabled to display the contents of the document. And I had an instruction to click on the enable content button. In my situation, I could never get the enable content button to essentially pop up. I couldn't find the macros in the file. And when the analysis was complete in the sandbox, it actually gave the file a relatively clean bill of health. It did not detect anything malicious about it, which I thought was highly unusual, especially given what I was looking at. So I wanted to do a little bit more research on it. One thing I like to do as well is just to see if there's anything hidden in the file that I don't know about. So what the strings command will do is the strings command will essentially pull human readable text of any particular file. Now what I like to do personally is I like to pipe out the strings command into the less command. That way when I run it, I can essentially arrow up and down and navigate through the file without everything scrolling by past my ability to read it. And at the top, there's some interesting things here. As I did research, I found out these looked very much in place for what you would expect for a genuine Microsoft publisher file. I did arrow down and read through a whole lot of stuff. I didn't find anything particularly interesting about the file I was analyzing. So what I wanted to do next was essentially hash the file. In my case, all of our tools used SHA-256, which is something I was comfortable with gathering and then looking within our security toolkits. When you're looking for malware and looking for known samples, MD5 is probably sufficient. If you have MD5 in your environment and that's the preferred hashing algorithm, that's probably what you wanna use. In our case, it was SHA-256, but you can essentially do that either way. So I run that command. I'm able to get a hash value for the particular file and essentially search on that. If I did wanna run the MD5 sum, I can do that as well and get the results for that. So what I did when I had the hash is I started searching for it. And of course, one of the first go-to places for me personally was VirusTotal. And it may be difficult to read, but in the address field of the browser, you can actually see the hash value in there. In this case, no match is found on VirusTotal, which I thought was unusual because VirusTotal gets an awful lot of samples. JottyMowerScan doesn't have as many scan engines as VirusTotal, but it's a similar type of solution. And when I looked out there, again, I found nothing of interest or value. You can see the hash file there and you can see the hash was not found. So I went into hybrid analysis and again, no results for the engine while querying the hash value. And finally, I just actually did a Google search just to see if anything at all would come back. And it really came back that no documents, nothing was matched. So I wasn't quite sure exactly what I wanted to do next at that point. Again, I spent a lot of time researching things and so forth. And then I'm thinking, well, this mobile device, it's sort of at risk. Is this something that we want to get from the end user? And essentially, what do we do with it? Is it sufficient to do a security wipe on the device and give it back to the user? Do we confiscate this thing? What exactly is a good course of action? I didn't feel that essentially saying, well, the chances Microsoft Publisher infecting an iPhone are small. That just wasn't acceptable level of risk. I also wasn't sure I was even comfortable with the risk of wiping the device and letting the user have it back. In fact, I can tell you that I wasn't comfortable with that at all. And so another thought I had was, let me look into it. This particular user was not due for a device refresh yet but they were very close to it. So I was almost thinking, well, perhaps we can confiscate the device, shut it down and then put it in our forensics lab and then get this individual a new device issued. They were close enough to the date where we definitely could have justified that. As I'm thinking through these and other thoughts and spending time research, I thought, well, this is sort of silly, but I actually have not looked at the exit data for the file. Now, when does that simply right-clicking in the file, going into the properties and drawing into the details to see what you can learn about it? You always have to take exit data with a grain of salt though, because exit data can be spoofed. And so it's not perfectly reliable, but I thought, well, maybe there's another artifact I can find in exit data that will tell me something interesting about the file. So let me go back to my command prompt. Let me go ahead and clear the screen. And in my case, since I'm on Linux, I'm gonna run the plural exit tool on this particular publisher file. And when I do that, some interesting information, I have the file name at the top. I can see the date, timestamps, and so forth. This was interesting, the file type and file extension, FPX, not something I've really seen before, but then again, I'd never really looked at publisher files before. My research told me that those were legitimate things that you expect to find within a publisher file, the MIME type image, vnd.fpx, and then later on you see that it is Microsoft Publisher. I get to the author and it didn't exactly say test fish. It wasn't quite that blatant, but let's go ahead and talk about what it was. Really for me personally, it was a face palm moment, just simply realizing that the email attachment I spent all this time analyzing actually came from our test fishing vendor. Now I said that exit data can be spoofed and that is true. So I didn't just accept that as definitive. What I did do though is I went through and I looked at our email system and I double checked the message headers and they were what I expected. It came from the IP address associated with our test fishing vendor mail servers. Of course, when I'm looking at it, I'm reading, yes, Matt, this really is your test fishing vendor's IP address, you doled. It's okay if you wanna laugh at my pain. This was a definite painful lesson learned in this particular case, but what went wrong in my case is I got caught up in the moment by subconsciously letting somebody else influence my investigation. So their anxiety and bad assumptions wore off on me. One should always start with the message headers when they're conducting an investigation of a fishing email and the contents. And ironically, I've given talks on fishing forensics and I've always, always always stated to start with the message headers, but this one time I got tunnel visioned on the attachment and so I've banned in my own standards this one time by focusing on the attachment first and it really came back to bite me. In this case, there really were no remediation steps as it was what you might consider a false alarm. The road to redemption in this case were painful lessons learned for my reminders to stick to my standard investigative processes and procedures. If I had started my investigation by inspecting the message headers first, I could have closed out the investigation in minutes instead of hours and then in this particular instance, no further technical actions were required. My second scenario is called security scanner evasion. I'd like to preface this scenario by stating that there were identical fishing emails and they started hitting inboxes. We were actually getting wide scale reports of fishing and the link, what was interesting about the link is when I looked at it in a security scanner tool is it appeared that the page was already offline. If that were truly the case, then it might be a situation where it was nothing to worry about. I wasn't quite ready to accept that at face value. So let's go ahead and investigate this and find out. What we're gonna do for our investigation is we're gonna take a look at the email message and the source code. We're gonna note any hyperlinks and then we're gonna check out the landing page with our security scanner and that's something I'm just sort of simulating here. Then we're gonna take a look at the landing page source code and then finally we're gonna open up the fishing page in a sandbox. And again, I'm on my local machine here doing demos. So this is gonna be a simulated pretend sandbox if you will. Let's go ahead and take a look at the email message itself. And so here's a sample email message. And so the from field in this particular one I've called it from evil.scammer at promisewearelegit.com. The subject in this email message is this link is totally safe. And in this case, it's coming to fishing target which is unwitting.victim at randomtarget.org. Email message simply reads hello fishing target. We have a really important message for you to retrieve your message click here and that's not real subtle. It stands out about as much as it could possibly stand out regards spoof sender. Not had a lot of people ask me, Matt have you actually used this as a test fishing template to do fishing testing for user educational purposes? And the answer is no. And part of that is I'm not sure I really wanna know because my deepest fear is there's still gonna be that one person in the organization that's still gonna be gullible enough to actually click on this hyperlink. And so even though there's more red flags in this particular email than Vladimir Putin has in his garage as souvenirs from his old KGB days my fear is somebody would still actually click on it. In this case, a lot of people will tell you to hover over to get the hyperlink in an email message. I don't like to do that for a couple reasons. One is you might accidentally click on the link and two, I'm just sort of leery back in the distant past there used to be some issues with certain mail clients and web mail where JavaScript might run on a mouseover or an on hover, that kind of thing. So I tend to go the extra cautious route and I'm gonna go ahead and come in here into the view menu and pull up the message source. I wanna make this a little bit bigger so it's not such an itch art to try and read. And what I like to do in an email message is if I just do a search, a text search for HTTP I'm generally gonna find what I'm looking for. And in this case, I have one result and it found my hyperlink. And so I'm gonna go ahead and copy this particular link and see what we have. And let me go back to my command line and there's a couple of things that we can do to obtain the source code for this. Before I do that, let me go ahead and show what it actually looks like inside of my test sandbox. So if I open up the page I get what appears to be a normal looking 404 page saying that the file or the directory is not found. If this were truly the case, it could be a situation where this has already been cleaned up and there's nothing to worry about because it would appear that the malicious site is offline. Not wanting to take that at face value there's a couple of ways we can look at the source code for that. One of them is we can use the curl command and we can paste in the address and I can output the results to a file of my choosing. So for output, let me go ahead and call this something like first page. I'm sorry, let me go ahead and call this unknown.html. And it retrieves the file. There's other ways to do this. If you don't have curl available in a system you could always try WGet and see if WGet is installed. And with that, I'm gonna go ahead and repaste the address in here. It's gonna retrieve the file for me. This case, let me clear off this stuff. And so I've retrieved the file a couple of different ways. Forensically, it doesn't gonna make a big difference which way I use to prove that. Let me go ahead and take a look at the HTML files in here. Now we've got different names based on how I output those results. But what we can tell is that roughly we have the same file bite size on these. Now, one thing it's an artifact of demoing this on a local system that's running a local web server is that the WGet actually retains the original date that that was created. That's really just an artifact of the fact that it's on a local system. Typically when you run WGet online you're gonna get the current time when it was retrieved just like my curl output here. But you can see that we definitely have the same file sizes. And again, just to prove that these really are the same file, I'm gonna go ahead and run a SHA-256 sum on all of the HTML files in here. And what we can see is it doesn't matter if we use curl or if we use WGet. These results really are identical. And so what we wanna do is actually take a look at one of these files. So let me just go ahead and pop up one of these inside of a text editor here. And it doesn't really matter which text editor you use. I'm just using something that's simple that I can make bigger that hopefully isn't too difficult to read on screen. Now, whether you can actually read the JavaScript or not, I'm gonna explain how this works. So here at the top, we have our standard HTML file. It's declaring script. And in this case, it's gonna be JavaScript. And what we start seeing is we see an if else loop. And so what it's looking for is user agents. So navigator.userAgent. And so we see things that should be recognizable here. And so this one in particular is Chrome and what we see is it's doing an if if it's Chrome then replace the window location or in other words redirect the traffic to another page. And we have near identical code except down here we're looking at Microsoft Edge. We're looking at Firefox. We're looking at Microsoft Internet Explorer, the Opera web browser and the Safari web browser. And so we have all these different if statements and then down here we have our final else. So if none of these things matched then it should replace the window location with a 404 page. And now that's interesting because these are really all of the common web browsers that most systems would tend to have. So in other words, if a visitor is going to a website using a popular web browser it's going to send the traffic one place. And if it doesn't match any of that it's sending it to this 404 page. And if you remember from our security scanner demo that what we had was in fact a 404 page. And so it's interesting because the result doesn't necessarily match what has been hidden underneath the scenes down here. So this tells us an awful lot. And to give everybody an idea of what this actually looks like if we open up the web page in a browser Google actually tells us, hey this looks so much sketchy and when I pull it up here what I get is what very much appears to be a typical Microsoft Office 365 type of login. So we can actually see what's happening when the site is visited by a common web browser. Well, so let's go ahead and talk about this a little bit. We looked at the browser user agent string redirection. Sort of explained how that works. Taking this a step further in this case I got lucky because the threat actors had used JavaScript. So I could tell there were redirects happening and I could tell exactly how they were happening if the threat actors had used a server side language and there's certainly a number of them here including PHP, Python and several others I have listed by no means is that an all-inclusive list but those are very common to find as server side languages. What's interesting is you can't view source code on server side languages and is standard properly secured web server configuration. What is also interesting is that if let's say, for example, the threat actors had a payload that only worked within the Firefox web browser, for example, they could actually target the payload based on a specific web browser so that it would only round robin execute a malicious download. For example, when people using the Firefox web browser might visit a particular page, those same code snippets I showed could be further targeting specific browser versions within those brands. So for example, if we had a version of an exploit that worked only on certain browsers below a certain version number, those checks could be baked into the code and they would be very hard to sort of analyze then but also typically that round robin could redirect a user so fast that they wouldn't even notice that the page took time to load but it would also make it very tricky to analyze. So those are sort of things that threat actors could do to make this worse. And honestly, I think I've sort of seen some of these type of things in the wild. It's just very hard if you don't have direct control or access to a web server to know for certain. In this case, our remediation steps were, we determine the actual phishing landing page and we blocked it through web content filtering. We also worked with our secure email gateway vendor to block the active phishing campaign. My second scenario is called security scanner evasion. I'd like to preface this scenario by stating that there were identical phishing emails and they started hitting inboxes. We were actually getting wide scale reports of phishing and the link, what was interesting about the link is when I looked at it in a security scanner tool is it appeared that the page was already offline. If that were truly the case, then it might be a situation where it was nothing to worry about. I wasn't quite ready to accept that at face value so let's go ahead and investigate this and find out. What we're gonna do for our investigation is we're gonna take a look at the email message and the source code. We're gonna note any hyperlinks and then we're gonna check out the landing page with our security scanner and that's something I'm just sort of simulating here. Then we're gonna take a look at the landing page source code and then finally we're gonna open up the phishing page in a sandbox. And again, I'm on my local machine here doing demos. So this is gonna be a simulated pretend sandbox if you will. Let's go ahead and take a look at the email message itself. And so here's a sample email message. And so the from field in this particular one I've called it from evil.scammer at promisewearelegit.com. The subject in this email message is this link is totally safe. And in this case, it's coming to phishing target which is unwitting.victim at randomtarget.org. Email message simply reads hello phishing target. We have a really important message for you. To retrieve your message, click here and that's not real subtle. It stands out about as much as it could possibly stand out regards spoof sender. Not had a lot of people ask me, Matt, have you actually used this as a test phishing template to do phishing testing for user educational purposes? And the answer is no. And part of that is I'm not sure I really wanna know because my deepest fear is there's still gonna be that one person in the organization that's still gonna be gullible enough to actually click on this hyperlink. And so even though there's more red flags in this particular email than Vladimir Putin has in his garage as souvenirs from his old KGB days my fear is somebody would still actually click on it. In this case, a lot of people will tell you to hover over to get the hyperlink in an email message. I don't like to do that for a couple of reasons. One is you might accidentally click on the link and two, I'm just sort of leery back in the distant past there used to be some issues with certain mail clients and web mail where JavaScript might run on a mouseover or an on hover, that kind of thing. So I tend to go the extra cautious route and I'm gonna go ahead and come in here into the view menu and pull up the message source. I wanna make this a little bit bigger so it's not such an it chart to try and read. And what I like to do in an email message is if I just do a search, a text search for HTTP I'm generally gonna find what I'm looking for. And in this case, I have one result and it found my hyperlink. And so I'm gonna go ahead and copy this particular link and see what we have. And let me go back to my command line and there's a couple of things that we can do to obtain the source code for this. Before I do that, let me go ahead and show what it actually looks like inside of my test sandbox. So if I open up the page I get what appears to be a normal looking 404 page saying that the file or the directory is not found. If this were truly the case, it could be a situation where this has already been cleaned up and there's nothing to worry about because it would appear that the malicious site is offline. Not wanting to take that at face value there's a couple of ways we can look at the source code for that. One of them is we can use the curl command and we can paste in the address and I can output the results to a file of my choosing. So for output, let me go ahead and call this something like first page. I'm sorry, let me go ahead and call this unknown.html and it retrieves the file. There's other ways to do this. If you don't have curl available in a system you could always try WGet and see if WGet is installed. And with that, I'm gonna go ahead and repaste the address in here. It's gonna retrieve the file for me. This case, let me clear off this stuff. And so I've retrieved the file a couple of different ways. Forensically, it doesn't gonna make a big difference which way I use to prove that. Let me go ahead and take a look at the HTML files in here. Now we've got different names based on how I am output those results. But what we can tell is that roughly we have the same file bite size on these. Now one thing it's an artifact of demoing this on a local system that's running a local web server is that the WGet actually retains the original date that that was created. That's really just an artifact of the fact that it's on a local system. Typically when you run WGet online you're gonna get the current time when it was retrieved just like my curl output here. But you can see that we definitely have the same file sizes. And again, just to prove that these really are the same file, I'm gonna go ahead and run a SHA-256 sum on all of the HTML files in here. And what we can see is it doesn't matter if we use curl or if we use WGet. These results really are identical. And so what we wanna do is actually take a look at one of these files. So let me just go ahead and pop up one of these inside of a text editor here. And it doesn't really matter which text editor you use. I'm just using something that's simple that I can make bigger that hopefully isn't too difficult to read on screen. Now whether you can actually read the JavaScript or not I'm gonna explain how this works. So here at the top we have our standard HTML file. It's declaring script and in this case it's gonna be JavaScript. And what we start seeing is we see an if else loop. And so what it's looking for is user agents. So navigator.useragent. And so we see things that should be recognizable here. And so this one in particular is Chrome and what we see is it's doing an if if it's Chrome then replace the window location or in other words redirect the traffic to another page. And we have near identical code except down here we're looking at Microsoft Edge. We're looking at Firefox. We're looking at Microsoft Internet Explorer the Opera web browser and the Safari web browser. And so we have all these different if statements and then down here we have our final else. So if none of these things matched then it should replace the window location with a 404 page. And now that's interesting because these are really all of the common web browsers that most systems would tend to have. So in other words, if a visitor is going to a website using a popular web browser it's going to send the traffic one place. And if it doesn't match any of that it's sending it to this 404 page. And if you remember from our security scanner demo that what we had was in fact a 404 page. And so it's interesting because the result doesn't necessarily match what has been hidden underneath the scenes down here. So this tells us an awful lot and to give everybody an idea of what this actually looks like if we open up the web page in a browser Google actually tells us, hey this looks somewhat sketchy. And when I pull it up here what I get is what very much appears to be a typical Microsoft Office 365 type of login so we can actually see what's happening when the site is visited by a common web browser. So let's go ahead and talk about this a little bit. We looked at the browser user agent string redirection sort of explained how that works taking this a step further. In this case I got lucky because the threat actors had used JavaScript. So I could tell there were redirects happening and I could tell exactly how they were happening if the threat actors had used a server side language and there's certainly a number of them here including PHP, Python and several others I have listed by no means is that an all-inclusive list but those are very common to find as server side languages. What's interesting is you can't view source code on server side languages and is standard properly secured web server configuration. What is also interesting is that if, let's say for example, the threat actors had a payload that only worked within the Firefox web browser for example they could actually target the payload based on a specific web browser so that it would only round robin execute a malicious download for example when people using the Firefox web browser might visit a particular page. Those same code snippets I showed could be further targeting specific browser versions within those brands. So for example, if we had a version of an exploit that worked only on certain browsers below a certain version number those checks could be baked into the code and they would be very hard to sort of analyze then but also typically that round robin could redirect a user so fast that they wouldn't even notice that the page took time to load but it would also make it very tricky to analyze. So those are sort of things that threat actors could do to make this worse. And honestly, I think I've sort of seen some of these type of things in the wild. It's just very hard if you don't have direct control or access to a web server to know for certain. In this case, our remediation steps were we determine the actual phishing landing page and we blocked it through web content filtering. We also worked with our secure email gateway vendor to block the active phishing campaign. My third scenario is called the rabbit hole. I wanna preface this scenario by saying that I received a request from a user to investigate email message. They received to determine if it was legitimate or not. The email appeared fishy at first glance but I had to ask, is it just suspicious or is it malicious? For the investigation, I can tell from the message headers that the source IP address was a mismatch from the sender's domain. However, the message source was particularly interesting because the link text did not match the hyperlink destination. And we're gonna do a quick demo of that and then the malicious threat actors objective appeared to be credential harvesting for the purposes of account takeover. So let's go ahead and take a look at the email message and then also take a look at the hyperlink. So here's our email message. And so it comes from PayPal support but the address is ppsupportatpwned-server.org. The subject is PayPal bank account change confirmation and it's to phishing target which again is our unwitting.victim at randomtarget.org. The email simply reads, dear PayPal customer, we received a request to update your bank account on file. This process will complete in the next four hours. If you did not request these changes to your PayPal account, please log in to reject the pending activity. And here is a link that would actually take you to PayPal's actual login page if that is where you are being sent. And then in this case, sincerely PayPal support. And I mentioned in there that the link text reads one thing but the actual hyperlink can go somewhere quite a bit different. So let's go ahead and take a look at the message source code here. So I'm gonna go into the view menu, pull up the message source and make this a little more readable for everyone. And so if I search on HTTP, it will find HTTP, HTTPS traffic. And so here we have the PayPal sign in address that we just looked at moment ago in the live email message. But what gets interesting is when we see the actual hyperlink in the source code it's actually going somewhere completely different. So I'm gonna go ahead and copy that address and have that here so we can do some analysis on this. Let's go ahead and see what this looks like on a live website. And so again, this would be something you would typically do in your sandbox environment to see what's going on here. And it certainly has the look and feel for a PayPal login page when we go there. But what we wanna do is understand what is actually happening behind the scenes when we investigate this. So we've taken a look at the link text. We see that the hyperlink is going somewhere else. We know the threat actors are trying to harvest user names and passwords for PayPal so that they can log in as the user and deplete the account of funds, maybe make fake purchases, essentially committing financial fraud. So what we're gonna do is we're taking a look at the first destination. And we took a look at the source code just a moment ago and we know it's going to a web host in a foreign country. But we're gonna go ahead and take a look at that. So let's do that now. I'm going to go ahead and run curl and I'm gonna paste in the address I copied moment tarot ago. And I'm gonna output this and I'm gonna call it something like firstpage.html, retrieve that. And so I wanna take a look at this file and see what it actually looks like so I can understand the source code of the page and what's happening. And again, what we see in the address here is a dot BE top level domain which we know is the country of Belgium. Certainly if we're an American customer on PayPal we shouldn't be going to a Belgium domain and everything in that phishing email essentially tells the user, hey, you have four hours to essentially save your account information. So people will unfortunately maybe fall for that lure and think that they're acting in good faith to protect their account when the reality is they're actually handing over all of their credentials to the threat actors. So let's go ahead and take a look at this source code and see what it looks like. Yeah, I'll make this just a little bit bigger here. For an active webpage, this doesn't look like it has a whole lot of information in here. We see it as a conventional HTML file and we see, you know, title, please log in. What's interesting down here is we have this HTTP equiv equals refresh inside of this meta tag. This is a meta redirect and content equals zero means it's going to happen instantaneously. In other words, it's not gonna be a five second delay. It's going to do it immediately. And what we see here based on the source code is it's not going to PayPal, certainly. It's not even staying in the Belgium domain. Here we have a .de domain, which we know is in Germany. And this is certainly highly unusual because now we have something where the link text did not match the hyperlink which went to Belgium. Now we have a webpage being served up, we believe in Germany. And these are all very likely compromised web servers in these foreign countries. So, now that we have copied the second destination address, the landing page appears to be a compromised web host in a foreign country, but we're going to take a look at this, get the source code and figure out how this looks behind the scenes. So, similar to what we did before, I'm going to run curl, I'm going to go ahead and paste in the address for our second destination. And this time I'm going to output it to something called second page that HTML. And this, again, will retrieve the source code from the second web page. And we want to take a look at this and understand what's happening. So, let's go ahead and run gedit again. And in this case, I'm going to go ahead and pull up second page. And you can certainly use whatever preferred editor. Again, I'm just doing demos here and trying to make this somewhat easy. The ampersand should just open in a disassociated process and return the terminal back to normal. Let me go ahead and make this bigger. Now, this is not the same thing that we had for our redirect before. This looks just a little bit different. One, you can tell it's obviously a little bit bigger HTML file. We have HTTP meta information, but not a refresh here. What's interesting is there is a declared title on the page of log into your PayPal account, which will be something that would pop up and appear within the web browser. What's different this time, though, is we have an iframe. And the iframe has another web address in it. So, this is actually not serving up the web page we saw. This is actually serving up in an iframe. And what we can tell here with absolute positioning and 100% width and height and no border that it's a seamless iframe. So, in other words, when somebody visits this particular page, it won't look any different that they went to, but the reality is it's actually serving up content from this different address. So, this is definitely getting very interesting very quickly. Let's go ahead and take a look at the third destination address. And so, again, we have, if we look at the where this is going, we can tell that very soon that we have .nl as our top level domain. So, that is something in the Netherlands. So, we're going ahead and curling this page. We're going to go ahead and output this and we'll call it thirdpage.html and we'll get that. And so, before we've looked at these different kinds of files and we've retrieved them, we'll go ahead and do the same here. And so, I'm going to do my editor. We'll start typing in third page, do an ampersand. And what we get this time isn't the nice source code that we've looked at recently. We have really what is not human readable Govity Gooke. And if we scroll through here, there's really very little other than the script tag down here that tells us much of anything. We know based on the top that it is JavaScript. And what's interesting here is we have something called an unescape. And I'm going to explain this a little bit. So, this is an unescape sequence. And then what we have down here, we have something that's DF. Believe it or not, I actually made this a little more human readable and you might be thinking, Matt, this is not readable at all. And that's true, but bear in mind when you see this stuff in real life, there may be no white spacing at all to separate out what this is. Now, if I come here at the very end of the first lines, you know, we can see here at the end our unescape sequence based on what's happening here. I'm going to go ahead and guess that this might be some sort of a function. It's certainly not human readable. And back in the old days to understand what was happening here, we would actually have to get the unescape sequence. And then we would have to feed the function back into our unescape sequence to translate this into something that we might be able to read. Let's go back to our slide deck real quick. We've got our source code, we've perused it. And so what we can tell again is that the threat actors use JavaScript and coding to avoid analysis and detection while also hiding the page source. So we're going to take a look at decoding the page source using the built-in browser developer tools. The important thing to remember here is that anything that can be rendered in a web browser has to be something that can be decoded in order to serve up the page. So in other words, it somewhere has to be readable. Here we actually have the destination from the iframe itself. Let's go ahead and pull up the browser developer tools and we can actually leverage those as a faster method to actually understand what the source of the page is doing. Let me come back in here and do a quick refresh. And what we have when we look at this is on the network tab inside of our browser developer tools. Right now we're looking at everything and we're going to see headers. And so here we have our web page and we can see what the headers look like and that sort of thing and a little bit of the source code but we really don't see a whole heck of a lot here. If I come back into the elements tab, I've got some code here but it doesn't really break down a whole lot of detail. In other words, what I'm seeing on the screen I'm not really seeing a whole lot of code for. And what I mentioned before, the good thing is that this stuff has to be decodable or else the web page itself would never render and the threat actors would not be able to do account takeovers. So if I do it edited HTML, this starts to look very similar to what we had before and we have again our unescape sequence here. It's same stuff we were just looking at but what gets really nice is once we get past this blob of JavaScript encoded stuff that isn't human readable in our browser developer tools we actually do get to a point where we get to actual source code and here we can actually see the unescape sequence in here. It's already done the heavy lifting for us. And again, I was just guessing based on how the code looked that that might be a function. And sure enough here, we see that it is trying to do some sort of a function call based on the unescape sequence. And what we notice here is that this is readable code for the most part. We see the title login to your PayPal account. What gets really weird though is that we have more stuff that isn't exactly human readable when we get around to this section. And what it tells us here is a shortcut icon and we look at the MIME type. It's data image X icon base 64. So I'm gonna go ahead and guess that this is likely some sort of base 64 encoded content. And we'll go ahead and kind of scroll past that stuff a little bit based on what we see here. It might even be an icon file of some sort. We'll go ahead and go back down and here again, we actually start seeing our HTML coding that we can actually now read. What gets interesting is that we get down here, we've got a table item and this would appear to likely be an image source. And here again, potentially base 64 encoded, probably base 64 encoded based on the MIME type and how that's defined in here. We have data image. So I'm gonna guess that this is an image file. And if we scroll through quite a ways, takes us a little while before we get back to the actual content. Now this is something that's actually relatively simple to analyze here within the developer tools. We go back to our network tab and we look at some of what's in here. Let me make that just a little bit smaller. Here we see what was retrieved. We have an image file that is a JPEG and we have base 64 encoding. And if we were to go back and look, it's gonna be the same code that we looked at in that second file that was base 64 encoded. And what is really nice is they have a preview tab here. That actually shows us what the file looks like. We bounce back to our webpage where we loaded this again in our pretend sandbox. Here's the logo file itself for PayPal in this particular location. So we've done this with the browser developer tools and we've seen that this is indeed all part of this single file that we've looked at the source code for. But what you might recall is that there were two base 64 encoded things in here. And so again, I'll have to go ahead and click edit as HTML. And if I scroll past the encoded parts it'll actually give me the decoded version of the webpage. And here again, I'm guessing that it's an icon file in all likelihood. What I wanna do to manually do this and what I wanna show is how you manually decode base 64 items. And so I'm gonna go ahead and copy this whole blob of stuff. I'm going to open up a new tab here. And I wanna go ahead and paste this in here. And what we have is this big base 64 encoded data. And I wanna go ahead and save this particular data. And I'm gonna go ahead and call it unknown.txt. That's essentially what we have. We have text, we can see what's here but it's not necessarily human readable. And what we wanna do with this is show how we would manually decode base 64 content. So let me go ahead and list out my text file here. And here I have it unknown.txt. Let me go ahead and clear this again. And so what we wanna try and do here is base 64 for the command. We'll do a dash I just to sort of ignore any warnings or errors or that kind of thing. We'll do a dash D for decode. And let me go ahead and pull unknown.txt. And what I'm gonna do is redirect the output. And what I'm gonna redirect the output to is fave icon.ico. Hit enter. And now if I do an LSL, start.ico, I should see that I have a fave icon.ico file. So this is great. It appears like we may have decoded this thing successfully. And here's my fave icon.ico file. If I double click on this, open it up in an image viewer and I make this much bigger than the default. Here we can see what would appear to be a fave icon within PayPal. Now this is gonna be somewhat tricky to see here but in the browser at the top, we see our fave icon file up here. This is all interesting stuff. What we've observed through this is that we've seen encoded elements. And I'm not sure whether the Thread Actor used encoded elements to avoid analysis and detection or they simply wanted to keep the entire site as a single page file, but they use base 64 encoded elements inside of their JavaScript encoded page. And we've looked at demos for that. We've also seen how to decode the base 64 using the built-in browser developer tools. And we've also walked through how to decode those elements by hand. In this case, the remediation steps were that we determined the final phishing landing page and we blocked through web content filtering. We also went ahead and blocked intermediary, compromised web servers through content filtering since we had identified numerous compromised web hosts in foreign countries. And then we reported the compromised websites to domain owners and hosting companies through their who is contact records. That's a little bit of a leap of faith now because everything is privatized. So hopefully the privacy email address is forwarding somewhere that's being actively monitored. We can only control so much on our end, but those are the remediation steps we took in this case. That's all I have for this presentation. I'd like to thank everyone for tuning in. As you see me hanging out on Discord or at Defconn, please share your own DFIR stories. Friends, Romans, Defconn attendees, lend me your IRs. And with that, I will be hanging out on the Discord to answer any questions. Please feel free to reach out to me there. And I wanna thank everybody for tuning in and hope everybody enjoys the rest of their conference.