 I created this directory called Rick and Morty and in this directory I have a couple of Nito files that I wanted to share and showcase here. So you can see a couple of them are executable files.exe, there's a PowerShell script in there that .ps1 file, couple INI configuration files seemingly and .temp file. I ran the file command to figure out what each of these really were if they are in fact what they say they are. It looked all good. None of the exe files were .net assemblies so I couldn't open them up in like dnspy or ilspy but that's okay. We still have plenty of story to get through here and I thought first I'd check out that .tmp or temp file because it looked kind of weird and out of place. So as it turns out, as I opened this thing up I could recognize, hey, this is visual basic script code. So I set visual basic script as my syntax highlighting profile in sublime text and then saved a copy of this file as like the name cleaned so I could go ahead and make sense of this code. So it started off with some weird comment with seemingly random base 64. That didn't actually decode to anything. It was kind of useless. So whatever, I guess that's there for some reason. Good waste of time, good waste of my time and your time. Thank you very much. Then I went along and tried to make sense of these variables here. I could see down below that one ENY QMP was being set to a new object of wscript.shell. So I went ahead and renamed all the variables to that and then I tried to make sense of the code logic or the flow of the program. There was this weird-looking function, WDNZZTNHJBXZ, that seemed to create a new string, building it out out of maybe iterating through whatever argument was passed to it and I don't know, taking, I guess, the third character of each letter in the string or the third character in each, the third, you know what? Okay, sorry, words are hard. So I renamed the argument variable and renamed the function to kind of make more sense as to what the thing actually does. So I could see that the code was using this function to extract some string out of another larger string that was seemingly nonsense. I thought I could see a file system path out of there. You could see a C colon, but it was separated with like a Q and a capital D over and over again. And the other string that it referenced was kind of completely random what the other in-between characters might be. So eventually I just thought, all right, let me recreate this in Python and then I can kind of decode those strings, quote unquote, decode, right? I cranked this out in B Python inside the interpreter and we were totally right, right on the money that first string is a file system path. So I got started kind of commented that out in the original code out of that new line in so I could make sense of it. And then I got started with the next one, but that aired. Since it had a backslash U, Python thought it was a Unicode escape character and I needed to actually escape out all those backslashes. I did this with some usual sublime text magic. Literally just find and replace. Now I could give that string to my Python function and I'll uncover that this is going to do some PowerShell bypass execution policy to run a PowerShell script. And that brings us to the next file to take a look at. I do have a copy of that PowerShell script. So I take a look at it and make a copy, renaming it to again, a little cleaned prefix because that way I know that I'm going to be working through this file and trying to make sense of it, de-obfuscated, et cetera. Now I noticed it has some weird structure in that there are a lot of try and accept or try and catch statements in PowerShell syntax, wrapping around some other functionality to do something else. First I got started trying to kind of beautify or clean up this code. So again, the logic makes sense with white space and it's much more easily readable. After that was done, I got started trying to de-obfuscate some of the things that that script might be trying to hide. The first thing that stuck out to me was this like BYJ6 or whatever variable that seemed to, after some further analysis, just contain PowerShell after it had replaced out all those things it was using to make other noise or evade signature detection. I renamed the variable and then went to go take a look at what those try catch statements were doing. They looked really weird because they had a colon kind of in between each commandlet. And I thought, is that even normal PowerShell syntax? So I tried to copy it over to an interpreter and find out. Bruh. Nope, not real PowerShell syntax, it's a lie. For whatever reason in the moment, I like didn't believe this and just continually kept trying it both in Linux PowerShell and in Windows PowerShell and went down this like research rabbit hole. But it was all stupid. It was a waste of time. It was just more random bad dead code to distract whatever antivirus product or EDR solution might be trying to look at this and figure out what it does. So I went on my merry way renaming variables trying to make sense of the code. I noticed it was doing something kind of interesting. It looked like it was getting data or more information out of the desktop.ini file, which normally people just tend to overlook but they were actually using it as a hiding place for more bad code. Eventually I realized that the commandlets kind of joined together by the colon inside of a try catch statement were there to just kind of add more noise. It's going to run in a try statement purposefully fail and then the catch block is going to end up being the code that actually executes. I went through and deleted all of those stupid completely useless try blocks because they weren't really doing anything and I was pretty upset at myself for not realizing that and noticing it kind of right off the bat. So I thought it was a fine time to take a break and like go outside or something. Just kidding, that was a stupid idea too. When I went back to the PowerShell code, I did see that it was pulling data out of that desktop.ini file and it was treating it like a PowerShell secure string with the key of the numbers one to 16. There was also this like UPD variable that was seemingly never used and I don't exactly know what that thing is for. But anyway, it ended up executing code with IEX or invoke expression based out of what it pulled from desktop.ini. Since we could see the process of how PowerShell would sort of decode or quote unquote decrypt this thing as a secure string, we had the key, we had the original file, we had the process. I thought, well, I could just do this too. So I tried to throw it into some Linux PowerShell interpreter and see what it would churn out. Oh, and if you don't believe me as to what the whole desktop.ini file thing is, here, take a look at the contents. It's this thing. So I was pasting these PowerShell commands one by one into my Linux PowerShell interpreter, checking the variable and its value and contents after each go. Now I didn't seem to get anything. It seemed like my final PowerShell string was just a double quote. Now you'll notice I'm being very careful to not copy and include that IEX or invoke expression because I don't want this thing to actually detonate. Eventually I thought, well, maybe it's just being weird because it's on Linux. So I opened up my Windows virtual machine as well and tried to see what would happen. At that point, I was pretty tired of just copying and pasting one line at a time. So I took the whole thing and just slapped it in. That got a lot of errors. So this one, I at least knew what the problem was. This one was kind of obvious to me. Oh, duh, the desktop.ini file doesn't exist on that machine. I am an idiot. That was an easy fix though, since that desktop.ini file was all plain text, I could just open it up, copy and paste it into our good friend Notepad. And just like that, the desktop.ini file is present on the Windows VM and I can work with it. Now when I slap in that PowerShell code in Windows, it does actually decode and you're gonna really love what comes out of this. This is where we finally get to Rick and Morty malware. Love a love a dub dub. You heard it here first, folks. It's got all your favorite characters, Mr. Meeseeks, Mr. Poopy Butthole, Squanchy, Bird Person. We're gonna see so much more. So I copied and pasted all this code out, put it into a new file in sublime text and got to work. Truthfully, this thing isn't really all that obfuscated. I mean, other than the fact that a lot of the variables are named after Rick and Morty characters. But like, look at this. Obviously it needs to be cleaned and beautified a little bit, but look at like the random strings in here. Little wubba lubba dub dub string. It's got Mr. Meeseeks box as a variable referring to the command prompts. There's just so much in here that is so funny to me. I was thinking, what is this? Is this normal? Is there such thing? Has anyone ever seen Rick and Morty themed malware before? So I had to do some very serious research. To clean this code, I started to remove those stray and random strings that weren't doing anything. I renamed variables so they weren't the random name, but they were something that actually made sense as I were reading through this. And I noticed it was doing some really interesting things, trying to see, okay, what executable files are in this current directory, looking for other INI files like a ping.ini. And then it starts to do some really interesting stuff by just getting a completely random process and working off of its name. I noticed there was this IFN variable that seemed to run the get process commandlet and pipe it to get random. So it looked like it was just grabbing a completely random process. I tested it out, just kind of experimenting like, hey, what would it grab? And literally it's a random process every time and it grabs the name. Now it takes that IFN variable and then seemingly just stuffs it into Plumbus, which is hilarious for one thing. And it actually takes the current directory that we've already retrieved as a variable and then adds in that IFN value and adds also a .temp file extension. Now on this target host or whatever I was looking at as the victim, I did see in the current directory, actually a service host or SVC host .temp. We'll get to that file in just a moment, but following still in the code, we see other properties being set so we don't actually show any windows and we stay hidden. And then we have this Citadel function. Now this one's kind of interesting. It looked like it was taking in arguments or grabbing code and syntax to denote something that would normally be passed in and include a .ps1 or .temp or tmp file extension. Now those look very, very similar to the same .ps1 and .temp, which were actual visual basic script that we saw earlier. It checks if those files exist and if they do, it grabs the length of that file and returns it out. So maybe that'll be useful somewhere else later. Following that, I see a primitive for just a basic sleep function or little wrapper around the start sleep power shell commandlet and then we start to do some other more interesting and peculiar things. At this point, it wants to collect information and gather some more data or knowledge about what target or victim have I actually landed on? What is this malware gonna actually execute on and what information can we grab about this host? So it retrieves the MAC address and then it starts to put that together in I guess a little hash so that it knows and can identify this specific target or victim and we'll see that more, especially as we dive into this new slmgr.ini. But before we do, I want you to notice something that's really weird. It keeps referring to the first executable that it finds in the current directory, the first .exe file. Now, we have copies of those, we have those .exe files, but what is so special about the first one and you'll notice it has this argument and it calls that first exe with a slash reset argument or parameter. Now, I was looking at this and I was trying to figure out what is that thing? What sort of argument and what would that do? So I took a look at that executable file and you might see some weird stuff. Now, this was super, super cursory analysis, right? I literally just ran strings and then sort of had enough to go off of, you know me strings is overpowered and it's the ultimate hacking tool, right? Now, this thing had a legitimate valid Microsoft cert attached to it and I kept seeing indications of bits admin and I was thinking like, whoa, like seriously for real the bits admin .exe, kind of old school DOS command prompt like cmd.exe like utility for like file transfer stuff and this is on Lulbans. Like this is a known living off the land utility that can do some interesting stuff. Typically it is used for downloading files and you can see the syntax and you can check it out online, but the arguments that we were seeing like a slash reset and we'll see even more weren't seemingly in that Lulbans syntax. So I went to go take a look at like the man page, right, the help file for bits admin and I was taking a look at what this thing could do and why it was doing what it was doing in that malware sample, that reset parameter that argument seems to delete all jobs in the manager. So I'm assuming this is going to be used more and more in the future, right? So rather than calling that that first exe in the current directory, I went ahead and renamed that variable to bits admin and how we're going to end up using bits admin for some other control across this malware. Now we can start to get into that SLMGR.ini. Typically SLMGR is used as a command to kind of modify or do things with your Windows license that you might have installed on your Windows computer. But in this case, again, we're hiding amongst that just like we did with desktop.ini. And you can see actually the process here using a PowerShell secure string with the key of one to 16 is put to use again. So yet again, we have the value for SLMGR.ini. We were able to collect that file and we can decode and figure out what is actually being hidden here. Now this one I think is interesting because we do notice some peculiar domains and HTTP URLs. Again, I know this technique seemingly only works on Windows rather than my Linux PowerShell. So I have to copy over that SLMGR.ini file contents into that Windows virtual machine and then I can slap in the code to be able to do this one more time. Now check this out. We received some new indicators of compromise here. Now before I go doing some internet detective OSINT stuff before I start to look up and do some research on these domains and what they all kind of trace back to, I am going to be continuing to work through the code. But don't worry, we're gonna toss this stuff into virus total. We're gonna kind of do some OSINT, some research on Shodan and we'll see where these are all coming from. So I took note of those domains and then continued looking through the code. We finally reached the Mr. Poopy Butthole and bird person section of our code here. And it turns out Mr. Poopy Butthole is just actually going to end up generating some random eight characters. And we're putting that together with a .log file seemingly that that Squanchy variable ends up representing. And we use bits admin of course to transfer data kind of back and forth from each domain in that list of domains that we had previously and keeping track of that information in those log files that we should see present on the file system. I took another look at the bits admin help and user information and that slash transfer argument showcases the syntax that it uses. It has a job name which is seemingly going to be that random hash that we saw generated. A priority that we saw looks like foreground was kind of noted there. And then a type whether or not it's going to be download or upload. However, that isn't supplied in the code that we saw. So it must be using that slash download kind of by default. It then takes of course the URL that it's going to reach out to which is supplied in that D variable iterating through the domains. And of course the local file that it stores here that local name where we can see okay it's going to be writing that log file with an index and our random process which now we know is going to be service host or SVC host and kind of that same compromise one that we've been looking at on this specific target. And then it runs the command and sleeps for a little bit. With that information I thought we might have some interesting files because I did have a copy of the zero underscore service host and a one underscore service host but both of these just seem to look like hashes and I wasn't exactly sure what was going to come from them. So following down on the code even more now we're starting to do some kind of peculiar while loop stuff with using an E variable seemingly to exit the while loop but it checks for each domain if there is a log file already present from our random process which we know service host and then it has these AD and DID variables I'm assuming maybe for already done or already did and it grabs a crypto key seemingly as a variable name pulling out of the content of that downloaded log file but I'm not a thousand percent positive where or when that crypto key is going to be used next or if it's just sort of the notion to hey only respond to information from this target from this specific key that I the server kind of the master overlord command and control framework that HTTP domain has willingly given you. I guess that's still up for debate. I am curious for your comments here but as you can see they do communicate with those servers they do reach out to those URLs and potentially grab information and again using that convert to secure string syntax with the key one to 16 it looks like it actually writes this out with that SLMGR.ini file. So part of me wonders is this the original installation is this how is sort of knowing and getting more information potentially from those domains from those callback servers? I guess I'm still a little questioning on this one too but I'm curious of your thoughts. At this point there was a lot going on and I was just finding more code to deal with. Thankfully a lot of the variable names we had already kind of chosen to rename are going to end up being used later down in the code so there wasn't a whole lot else to do other than clean and sort of make sense as to what was going on. I could see a lot of other reconnaissance and kind of enumeration techniques. Again it was trying to determine hey what file systems or logical disks are present here and then of course it would put together the commands to be able to copy this and maybe keep track of it for later use or install its own persistence write and dot TEMP files. It would look for the processor information like the CPU name it would start to look for the operating system caption and others and then you'll notice I have some bits admin transfer command variable names even if it isn't strictly using bits admin transfer that must be from our find and replace just clobbering that variable previously. I don't think it's all that bad I think we can still kind of make sense of it here but you can see me noting hey I'm curious is this going to end up being persistence adding in potential more information or adding in the hooks that we saw previously. There is an interesting segment coming up though if you'll notice this little F mail variable and it's trying to grab some files out of Microsoft Outlook directories and pulling files from that. It looks like this syntax just checks hey does the Outlook directory exist and if it does it runs GCI or get child item to kind of list out the information there and it's using those asterisk wildcards to look for OST files. Then the code does something awesome that it looks like it grabs the URI or kind of maybe the original link or the hostname for those callback URLs that we saw those dot EU domains. And then you can see blim blam, right? He's kind of up in action here with these another random eight characters being generated checking out the exes in the current directory and we get to see evil Rick in action. Looks like he's going to end up using that get length of script files function that we saw previously. And it actually references that UPD variable that we saw earlier in kind of the original stager. Now an interesting thing is that that value matches the name of those dot PS1 files and that dot temp visual basic script file that we all started with. So we're kind of coming full circle here. Eventually it looks like it ends up base 64 encoding all of the data that it's been able to grab thus far. The script information, the MAC address, the operating system name, the CPU, et cetera, et cetera and it bundles it all up and sends it again with bits admin transferring it back to those potential domains that we had pulled out of SLMGR dot INI. The remaining functionality in the code seems to use the same sort of syntax and structure as that while loop that we saw previously using kind of a dollar sign E variable to represent whether or not we're going to exit. And it looks like this does some sort of cleanup. It uses bits admin to list current jobs and then if it sees any error messages it looks to kill those PowerShell syntax or those PowerShell processes and it's checking, hey, do I have the correct amount of time to live or live time in sort of its communication? We see more use checking for these random process temp files generating more random eight character strings and seemingly creating these scripts themselves. I see the use of the crypto key here and I'm curious kind of all that it's doing but it looks like it's creating the same syntax as we saw kind of from our original dot PS1 file or the original dot TMP individual basics for file. It looks like there's some structure here for JSON data that I'm assuming is going to be ended up being used for the communication with that commanding control or other endpoints there. And I do see an invoke expression syntax in here but I can't track down where that might be coming from or how it ends up being generated. There's a lot of stuff happening as to how this kind of communicates but if I were to actually go finally play with these domains if I were to actually go look at these URLs and see if there's any actual information that comes from them you'll see I kind of get beat up against the wall here. Back in my just regular Linux command prompt running in bash, if I try and curl down one of those URLs, E-R-T-H-G-Y-R-T-E-H dot E-U I get a 403 Forbidden slash topic returns that and any sub directory or sub file kind of under that gets the exact same response, hey, 403 Forbidden even on the other link. Now, if I were to kind of test this in tinker with it if I go to the original root of the webpage it looks just like a flat centos maybe Linux server hosting out on the web okay just a default installation page but testing any other files like I do a little robots.txt here or I just do a simple a.html and nothing comes back. I always get a 403 Forbidden. Now, I'm not again positive I'm probably not interacting with the server the right way I don't exactly know what BitsAdmin does when it does that slash transfer. So I'm super curious, if you happen to know please fill me in, like comment and subscribe and all those things but literally running anything I do not get a response. I always get a 403 Forbidden. Obviously these servers are still up obviously they're still accessible because they are responding with something but no real data that kind of comes from it and I'm not positive whatever ended up on that target file system. How did it get there? Where did it come from? What other responses should come from this? Maybe had I been using BitsAdmin or transfer maybe that's something else we could do in another potential video it's kind of exploring this a little bit more maybe we're using that specific syntax but just curling stuff down nothing seems to come from it. Eventually I thought, all right let's go take a look at these IP addresses you know, it would be good to see where these things actually exist there's that dot EU suffix for the domain but checking it out in Shodan this does return in Amsterdam of the Netherlands which is kind of peculiar. Port 80 is open, Port 443 is open as we saw but there's also another peculiar one, 81, 81 that looked to be a maybe proxy but look at the certificate here on the SSL certificate for Port 443 what is that? andripetrandry.example.com some city, some state just kind of bogus random values here, right? Very weird, very strange and if we were to go take a look at that other domain checking that out with NSLookup or trying to get the actual IP address that comes from it it is the exact same IP address and yet there was seemingly a different response I mean, just so we think, right? The theoretically that we had a zero underscore service host dot log and a one underscore service host dot log are there some virtual host routing configurations kind of being set on that box on that machine on that server? I don't know. And then I started to Google around like look, is this a known thing? Is there genuine obfuscators for Rick and Morty malware? I wasn't able to track anything down other than some excellent Rick and Morty episodes and I thought like, all right let's kick this thing over to virus total and let's see, are these IP addresses weird? Are these domain names weird? So I passed that in and ooh, I see ESET caught it as some weirdness but it just says, hey, it's malware it gives us no explanation as to how or why or what made you think that trying the other domain, when I kick it in it takes a little bit of time to respond actually, no, that one immediately tells me hey, it's totally cool but if I were to add in the HTTPS in here actually specifying like, look look at the SSL cert, look at port 443 what are you tracking down in here? Eventually this comes back with I think one, right? Again, ESET, right? ESET getting that HTTPS. Trying the others, looking at specifically the IP address this gives us one right here and that's Sertego, Sertego but again, just tells me malicious not really anything else to glean from that no other valuable information but seemingly no one else is sort of aware has seen this in use at least from those preventative security products but that's that, I guess at this point, I don't exactly know where else to go or where more to bring this sort of at my wit's end I would love to know and to see what actually goes into that other invoke expression that we saw kind of within that last stage there but golly gee, it blew my mind when I kind of unraveled that and saw all those Rick and Morty characters I thought, man, this is a meme this is a lot of fun and maybe this could make for a good YouTube video so thank you so much for sticking with me thanks for watching I hope you've enjoyed me being a goofball, doing crazy stuff I hope it's been some fun this is one of the first videos where I have put a lot of time into sort of editing and going through and adding kind of other cuts and splicing things together so normally the hour, two hours time sink into developing the content has been blown to like eight hours to nine hours and carving this thing out so please do give me your feedback if you like that sort of thing if you had some fun with this style in format though it is a significant, significant more time investment in the normal kind of structure and style but I do want to get your feedback I do want to know what do you think so please, please, please do all those YouTube algorithm things I would love if you could like the video if you did like the video if you didn't like the video then don't and you can press dislike if you want but like why, you know I'm kidding, I'm kidding comment, do those YouTube algorithm engagement things I would love if you could subscribe please do press that bell, click that bell, smash that obliterate, destroy that bell and that will let you know when I post content and videos just like this so I'm going crazy this has been a long time editing and recording but thanks so much for watching everybody I really hope you had fun and I will see you in the next malware analysis video thanks everybody, love you, take care