 I'm here from Lawrence Systems, and I want to talk about some interesting links that Threat Actors are going through to obfuscate what they're actually doing, and it basically evade mailware detection. Now, there's a lot of layers of security. You know, the outer perimeter is gonna be your firewall, and hopefully it has some mitigations that block all this, and a lot of people seem to put, to my opinion, too much importance, like, well, why didn't the firewall stop it? And that's one of the things we're gonna highlight is how the firewall is blind to a lot of this. Now, this is also the other side of why endpoint is a really important layer of your security, and user training falls somewhere in there as well, making sure people don't click on things. But we know people are gonna click on things, so now we want to get to the point of how does this mailware of a detection, how did the folks at Huntress find it, and what did it do? So we're gonna break down those details, and if you can click that like button and first, if you'd like to learn more about me and my company, head over to LawrenceSystems.com. If you'd like to hire a short project, there's a hires button right at the top. If you'd like to help keep this channel sponsor-free, and thank you to everyone who already has, there is a join button here for YouTube and a Patreon page. Your support is greatly appreciated. If you're looking for deals or discounts on products and services we offer on this channel, check out the affiliate links down below. They're in the description of all of our videos, including a link to our shirt store. We have a wide variety of shirts that we sell, and new designs come out, well, randomly, so check back frequently. And finally, our forums. Forums.LauranceSystems.com is where you can have a more in-depth discussion about this video and other tech topics you've seen on this channel. Now, back to our content. Now, we've been a long-time user of the Huntress product, and I'll leave a link to a review I did before of Huntress. In that review, I need to do a new one, but it's still relevant here in September of 2020. It does everything it says in a review, plus it does more today, and I'll cover that in a future video. Of course, you can just sign up for demos and contact their salespeople, etc., etc. That's my affiliation. I'm a user of their product, and I like their threat research. So, hiding in plain sight, and John Farrell wrote this up here. And the first question is pretty simple. What do you think this file is? At first glance, it looks like a log from some application has timestamps, includes a reference to OS 6.2, the internal version number for Windows 8, and server 2012. It turns out that this file is associated with a malicious foothold that they discovered. The malware authors use several tricks to hide in plain sight, including renaming legitimate files, masquerading, and as an existing schedule task and using malicious payloads stored in a file to make it look like an error log. So, that's actually kind of clever, is putting the payload together in an error log, pulling it down, and filling it up, and then running it for execution. And I'm not going to break down every detail, but the short answer is, here's what it renamed itself to, here's how it pulls that particular line, and starts putting that together, and it's, you know, really interesting goes over all the code. Now, what does this malware do at a high level? Log file stage one. Then the renamed msht.exe used run renamed powershell, which decodes a log file. The payload from the log file makes a post to blank, blank, blank, random, dot, and pg, ssphp, and executes the response. The response is another encoded powershell command. This command makes a git request to a different URL, and the URL is randomized each time and run. Stage three, the response is also encoded in powershell. There are several functions, including encrypt, decrypt, git, av, test administrator, and others, which collect details about the host and internal machines. So, essentially what this does, and we're not sure how this got on the system, they discovered it once it's on the system, but this is not the method by which it got on, there could have been an attachment and email, some small thing. Now, the reason there's so many stages in this, because getting a large file that gets known through is going to be, well, hard, because all the different AV systems are going to find it. Finding some tiny little thing that may evade some of the AV, a tiny little powershell script, and this is something we're seeing a lot more of, that starts gathering other components, and the term is living off the land. You find out what you have on a computer, okay, we got powershell. And, you know, if this was a Linux system, it would have been bashed, but more likely they're attacking a Windows system. So, we have powershell already available to us, and powershell can be executed from a lot of different points, for example, inside of documents, or maybe as an email attachment. And a small script and powershell is hard to say, is that malicious or not? It just goes and grabs some files off this website. That's where the mistakes are starting to be made, and you're thinking, well, why didn't the firewall protect it? And that's where things get a little bit interesting, and we're going to break that down next, because how does it keep pulling, and I break down all the code here, but this is the part, part two, that really piqued my interest, hiding in plain sight part two. And they talk about, you know, the file, the log file, the peculiar scheduled task, and how it's grabbing things with powershell, but they have to peel back the layers. And so, after they dug a lot deeper, this is the part that really interests me, is how they're pulling the data. And the URL, httpsdns.google.com, your firewall wouldn't block Google, would it? You would have probably a headache if you blocked Google. And they're using the DNS servers to pull in the powershell. This is just a really clever and some really good threat hunting they did to kind of peel back these layers and figure out how it works. So they break down the code, how it goes through, how it grabs things, and then using DNS over HTTP as a means to receive other mail web here is a very clever trick, while DNS filtering might be in place on a secure network and limited and locked on HTTP access to Google is much less likely. So what is happening here, and this is common, let's say you put a lot of layers in your security network, we've got the firewall, we've got the fact that we said no, you can't use any type of DNS except for our DNS resolver. So the firewall has some type of block and it's limited and then you're doing DNS filtering through some type of paid service. So your stack is a solid firewall, a DNS filtering service that you're paid for, and that should be it, right? Servers can't make these call-outs. Well, I've done videos on like DNS over HTTPS, DNS over other things, Google supports that. So now we're looking at a DNS call, but it went to Google, so Google's not going to be on a block list, and a DNS call that's able to pull through would generally be unfiltered. So it's going to query the Google and it's going to ask for a text record because that's actually where they hit the extra code. Now, when you start digging through this, interesting that DNS query is not about identifying an IP address for name in order to make a connection. The next payload is actually embedded with a DNS text record. So let's take a look. And this is where it's kind of fun to say, hey, they're grabbing DNS text record. And for fun, I pulled this up real quick. I just threw this in here and I said, dig text outlooksetup.detroitutoringcompany.com. It's my demo domain I've used for a lot of different things. And you can really put anything in a text record. You can put a series of commands up to 255 characters, but you're thinking that's not a lot to do a payload. Well, no, you can keep adding text records to a domain. And what they were doing is as they go through here, they were interacting with Google and pulling it from Google over DNS over HTTPS. So they can keep pulling these text records. And if you have a bunch of text records put together in a DNS entry, even though each entry can only be that long, if you have enough entries, you'll put together enough code to put this together. So they were running against this, what looks like just a jQuery update.js.com, which was the suspicious domain, pulling this data. And putting it together. And then encoding it in base64 is not the best way to obfuscate things, but well, it's good enough to get by quite a few things. This doesn't do anything sensible. The payload source code wasn't interpreting a show code. In fact, they were using a forward slash as a limiter. And then he dives deeper in it to be to code each segment with a forward slash. We actually uncover more base64 data. So actually base64 with a few twists in it. So this makes it harder for nonhumans to parse. This is an important factor in also what makes a human-based interaction a little bit different than an automation. So automation tools will hammer out things and, you know, drop them in a base64 decoder and go, oh, that's base64. What is it actually trying to do? And let's reverse it. But by making slight modifications of base64, this is where some of those, you know, let's just call them AI systems. The logic systems people built may, may fall flat. And this is where you need someone really digging in and a security researcher to actually look at what they're doing. Then to go a step further, this is something I never thought about, but thought was really clever, is attempting to code a second nested base64. They find the dynamic whale servers ping. Now that's interesting. How do we ping that and make it work? Well, that's actually kind of a fun fact here. And if you notice what I threw in the text record here was just hexadecimal code, right? And the gateway here at my office is 192.1683.1. So we're going to ping a hexadecimal number. That's an interesting layer of obfuscation. So you would be suspicious if it was calling out to IP addresses. That's a lot less suspicious pinging there. And you're asking, okay, how did you do that? I'll leave a link to this because I thought it was kind of fun. We can ping it in a couple different ways. So 192.1683.1 as a integer, we can do that. Matter of fact, click here. There's the hex one, but we can also just ping an integer. And now some systems may not see that. Also, when you're trying to look through code and figure out where it's going, you just see a series of numbers that are harder at first glance to figure out. But now you have to start reversing them from their integer number or hex number versus IP. And for example, we can even do that with things like 888. So let's just do another example domain. We hit Convert and the same thing. That number there is actually Google's 888. So kind of interesting, the same thing. Again, we can ping it in hexadecimal and away we go. So another layer of obfuscation that probably in AI system, I mean, at some point they build these things in, but it takes a lot of human intervention because now you're obscuring things like one more layer. So that goes down there. And back to the original source code, we select one of those base 64 strings at random, pick an external endpoint, and a stealthy way. Keep in mind the attacker had flexible control of these last few layers of the payload. So domain and that text entry were external and could easily update or change to a third-party malware server could be moved in and out of rotation. And this is one of the things that's really important. They start moving these malware domains around, having set up a subdomains, and frequently whenever they can, threat actors will take over very legitimate common domains at a text record. And by doing these little text records on common domains that they've been taken over, they quietly will go through things and all of a sudden that once again doesn't get filtered. So no one's even questioning why you're going to some rather common websites. And this is a very important aspect of how they do it. So back to the threat here. We've seen this malware more than once. Interesting enough, the initial foothold had just slight deviations from its original they discovered. And the malware seemed to use a certain scheme, the doppelganger for legitimate MSHTA.exe application as described in part one of this blog is always renamed to a real currently active service on the target system. The second program that is ran masked the original PowerShell, this is renamed a simple lowercase in one word application, a peculiar fake log file is created as they file right with one random letter and one random extension. Now the reason they're obfuscating that they're running PowerShell is also because that's a trigger. Why is PowerShell running as compare? What do we do that needs PowerShell? So that looks that. So by obfuscating that you're running it, that's another way to try to get around some of these protections. There were a lot of unique and clever things that this malware did to avoid detection. Some of these tricks might slide right past a typical off the shelf antivirus or endpoint protection system. While seemingly simple to hide in plain sight, after peeling off the layers, you can uncover just how stealthy and meticulous attackers must be and only what tricks and techniques us defenders need to know to protect ourselves. Now the reason for all of this, my discussion on it, the write-up from Hunter Slavs, is to make more people aware as fast as possible of these security threats. And this is why one of the reasons I'm a big fan of the Huntress team is they're very quick to publish as they discover things because they believe is as do I. I've agreed with them. I've talked with Kyle many times. You know, security is a team sport. It's not about we bake this secret into our product that we're able to look at things a little different and no one else can know. No, these good write-ups and that mentality of sharing these write-ups so we can overall help keep the networks safer, help find these threats. And, you know, the idea is not just Huntress but other products will be looking at this and other threat researchers and people will be having discussions about this going, ah, that's an interesting way they're doing it. So now we have to keep an eye out and look for more suspicion when we're looking at threats. And what else, you know, when you take this and apply it to a bunch of systems, you may discover a series of data that's been quietly hanging out and doing something that you're like, huh, we always thought it was just these extra lookups to Google that we couldn't put our finger on because we never really looked at them. And so we said, oh, there's a few extra lookups to Google that's not enough to say it's a threat anomaly. That machine must want to use DNS over HTTBS. And yeah, that's just the queries it does, but it's, it's not a big deal. You know, this is that little nuance and why threat hunting is one, exciting, two, very difficult, also very satisfying when you find something like this. I can't imagine John's excitement when you put all this together, but that's what, you know, makes it kind of fun. I'll leave links to all this so you can do your own further reading on it and dive into it and, you know, really look at the code and everything else. And this is what threat hunting looks like. And it's fascinating. I love their inside look. They give us over at Huntress. And that's it. Thanks. And thank you for making it to the end of the video. If you liked this video, please give it a thumbs up. If you'd like to see more content from the channel, hit the subscribe button and hit the bell icon. If you'd like YouTube to notify you when new videos come out. If you'd like to hire us, head over to laurancesystems.com, fill out our contact page and let us know what we can help you with and what projects you'd like us to work together on. If you want to carry on the discussion, head over to forums.laurancesystems.com where we can carry on the discussion about this video, other videos, or other tech topics in general, even suggestions for new videos that are accepted right there on our forums, which are free. Also, if you'd like to help the channel in other ways, head over to our affiliate page. We have a lot of great tech offers for you. And once again, thanks for watching and see you next time.