LetsDefend — PowerShell Script Challenge Walkthrough
PowerShell Script Analysis with CyberChef
Introduction:
Hello! I just started checking out the practice labs over at LetsDefend and adding them into my rotation. I want to take the opportunity to give back and do some write-ups as I go through the site to help anyone who stumbles across this post to level-up their analysis. This challenge room is rated easy, but it presents a great opportunity not only to get familiar with the platform (and find some flags!) but also sharpen my own skills by digging deeper with some research into some fundamentals PowerShell script analysis. Thanks for reading!
Challenge Link: https://app.letsdefend.io/challenge/powershell-script#virtual
Challenge Scenario:
You’ve come across a puzzling Base64 script, seemingly laced with malicious intent. Your mission, should you choose to accept it, is to dissect and analyze this script, unveiling its true nature and potential risks. Dive into the code and reveal its secrets to safeguard our digital realm. Good luck on this daring quest!
Tool Needed: Cyberchef
File Location: C:\Users\LetsDefend\Desktop\script.txtThis challenge prepared by ZaadoOfc
Credit: csnp.org
Question 1: What encoding is the malicious script using?
First, let’s take a quick look at this script and focus on the parameters:
Notice the -Enc
parameter and the script that follows? PowerShell supports abbreviated parameters as long as it is unambiguous and couldn’t be confused with another command. With that in mind, this looks like it is the abbreviated parameter of -EncodedCommand
. According to Microsoft Learn, this parameter allows PowerShell to accept a Base64 encoded command. The encoding obfuscates the script so that security tools and defenders won’t be as easily able to detect and analyze the contents.
Let’s try the answer…
Nice, we got one! Let’s keep moving.
Question 2: What parameter in the powershell script makes it so that the powershell window is hidden when executed?
Looking at the parameters again, one sticks out:-W Hidden
If we refer to Microsoft Learn, it seems that -W
is a shorthand for -WindowStyle
where Hidden
is a value that makes the session not visible to the user when the script is executed.
Question 3: What parameter in the Powershell script prevents the user from closing the process?
Approaching this the same way as the last question, there is a parameter that seems like it might correct: -NonI
Going back to Microsoft Learn, this seems to be a parameter abbreviation for -NonInteractive
which means that the session won’t prompt for/require user input during execution of the script.
Question 4: What line of code allows the script to interact with websites and retrieve information from them?
From Question 1, we know that we are looking at a Base64 encoded script so we need to decode and analyze the payload to understand what it is doing. Our challenge scenario tells us we will want to jump into CyberChef to decode
Now, let’s apply the From Base64 operation to our recipe. We are getting closer and the script is starting to become readable, but notice the NULL bytes?
What if we add Remove Null Bytes to the recipe, too?
That looks better!
Now that we can read this, let’s take a closer look and tackle the rest of this question. We are looking for a “line of code allows the script to interact with websites and retrieve information from them” — let’ look at the first line. We see a reference to the string WebClient, this seems like a good place to start!
Microsoft Learn states that WebClient
is a class in the System.Net namespace and is used to download or upload data to the internet. So by creating this class you can perform web-related tasks such as downloading files from URLs.
If we take the whole line, it looks like we have our answer and can start to understand that the script might be trying to download something from somewhere…
Question 5: What is the user agent string that is being spoofed in the malicious script?
Looking at the next line, we see the $u
variable set as this string:
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
According to Mozilla, this looks like a pretty standard user agent string so we probably our answer already. For context, user agent strings are used by servers to identify requesting client details like the operating system, web browser version, and the web rendering engine.
While not required for this challenge, a cool thing you can do is try a user agent lookup tool to help provide some context for the spoofed user agent string. If we run the string from the challenge, we can get some additional intelligence and see what client the script is spoofing!
Question 6: What line of code is used to set the proxy credentials for authentication in the script?
Okay, looking at the decoded script we see a reference to Proxy.Cedentials
which puts us in the right place for the question.
The full code seems to be suggesting that the script sets the variable to use the System.Net.CredentialCache.DefaultNetworkCredentials
property of the credential cache. After doing some research, it seems that when using PowerShell to connect out to external web (HTTP/HTTPS) resources, it does not use the system’s specified proxy server settings by default and they must be specified — Microsoft Learn states that:
The credentials returned by DefaultNetworkCredentials represents the authentication credentials for the current security context in which the application is running. For a client-side application, these are usually the Windows credentials (user name, password, and domain) of the user running the application.
That’s a lot of information! Essentially, it appears that the command is simply using the current security context (user name, password, and domain) to set proxy authentication in the script to make the web request to ensure that it gets out.
Question 7: When the malicious script is executed, what is the URL that the script contacts to download the malicious payload?
We made it, last one! This one is easy to spot. Let’s look at the $DownloadString
— this is pointing our $WC (WebClient)
instance to download the content of the specified URL.
Now that we have the URL, we could apply additional intelligence, perform further analysis, and apply mitigations for the indicator but for the purposes of this challenge this is as far as we need to go. Let’s submit the flag and wrap this up!
Conclusion:
Whew! We made it through the challenge and we also have a better working understanding of this script: basically when the victim executes the script, PowerShell runs the code in a hidden, non-interactive window where it downloads the malicious payload from an external URL. Good work!
Thanks for checking out this walkthrough and thank you to LetsDefend.io for the fun lab. I hope whoever stumbled upon this post found it helpful and that the additional analysis and context added some value for you. Stay curious!