139. Conducting Malware Analysis (OBJ 3.5)
In this lesson, I’m going to do a little bit of static and dynamic malware analysis to demonstrate the concepts of how you might do this in the real world. We’re going to go through and look at how we can use a debugger and a decompiler to analyze some of the code and conduct some basic reverse engineering. We’re also going to run it in our sandbox environment too. Now, for the exam, you do not need to know how to actually conduct reverse engineering and static analysis of malware, or even how to perform dynamic analysis, using a sandbox. But I wanted to introduce you to these concepts because it may be part of the penetration testing and instant response world that you haven’t gotten to experience before.
So in this lesson, we’re really just here to give you an introduction to some of the tools and techniques that reverse engineers use. For this example, I’m going to perform malware analysis on a suspicious Windows executable file, but these same concepts do apply if you’re performing this type of analysis on malicious mobile apps in Android too. Let’s jump into my sandbox and get started. Now, the first thing we’re going to do before trying to analysis, is going look at it statically. And so we’re going to open up a Command Prompt, so click on your Windows icon and type in the word “Command,” and from the Command Prompt, we want to change directories into the Desktop. And if you notice here, we do have Trickster on the Desktop.
Now, we need to extract Trickster. So we’re going to right-click it, go to 7-Zip, and go to extract here. It’s going to ask us for the password, and the password is malware123. We’ve password-protected this to make sure you don’t accidentally unzip it on a system you don’t want to. So in this case, we’re going to go ahead and hit Okay, and you’ll now see Trickster is there on the Desktop. If we hit dir again, you’ll see, there it is. So what we want to do is pull out any ASKII strings inside that binary, by going through a program called FLOSS, and it’s F-L-O-S-S, and then the name of the file you want it to search through, which will be trickster.exe, and we’re going to pipe that into a text file called tricksters_strings.txt. That’s going to go through that entire file, find anything that looks like an ASKII character, text that we can read, and put it into a file for us to review. So to look at that, we’re just going to use “type” and then trickster-strings.txt, and then the command “more” to see it a page in a time. Now, notice here, it says, there’s a comment, “This program cannot be run DOS,” that’s fine. And then it’s going to start outputting any ASKII characters it finds.
And then you could see here, it found 2w3, it found this garbage, it found .text, .rdata, .data, and then a whole bunch of stuff that just looks encrypted. And if I go a couple more pages here, you’re going to see, there’s a lot of content that I just can’t read. It doesn’t make any sense, what is all this data here? Well, what I’m really looking for is IP addresses, I’m looking for host names, I’m looking for email addresses or program file names or anything like that. But in the case of Trickster, all I’m finding is a garbled mess. That indicates that this malware has been protected using encryption to keep people like us try to do malware analysis from detecting its true source. And that means that static analysis here isn’t going to work real well because it’s all encrypted. Okay, so Trickster was encrypted and we couldn’t do static analysis, but here’s where it gets fun. We are going to look at this thing dynamically, we’re going to start running the program and try to identify its purpose and what the file does.
We’re going to try to figure out what the malware does to the system, what chain changes does it make? Does it call out to a remote website, does it download files, does it mess up your registry? What is it going to do? Well, we’re going to figure that out here, so the first thing we want to do here is we want to create a known good baseline of our system. What I want to figure out is what does the registry look like, what does the task manager look like? What does the scheduled task look like? All of those type of details. And to do that, we can use a program from system internals called Autoruns, A-U-T-O-R-U-N-S, Autoruns. Just go ahead and enter it from your Command Prompt and hit Enter, and the program will launch for you.
I’m going to go ahead and maximize it here. And I’m going to go ahead and go to File, and there’s a setting called Run as Administrator. I want to do that so that system internals and Autoruns can see the entire system, regardless of what user it is. And so we’re going to let it run here for a second, it’ll take about 30 seconds, and when it’s done, it’s going to say, “Ready,” in the bottom left quarter, as it just did. This is the baseline, this is a system that is not infected with malware, nothing bad has happened yet.
So what we want to do is go to File and save this. And I’m going to save this to the Desktop, and I’m going to call it baseline. Go ahead and save, and you’ll see that it does show up here on my Desktop, right there, baseline.autorun file. Now, what do we want to do next? Well, we want to run Trickster, we want to run it as an administrator. So we’re going to right-click it and say, “Run as administrator, and infect this machine.” Go ahead and hit, Yes, give it a second here, and Trickster will run, and start doing whatever it does to our machine, which we don’t know what it does yet, but we can find that out. So what we’re going to do is maximize our auto runs again, go over here to the Refresh button and hit Refresh. It’s going to scan your system again and figure out what does an infected system look like?
So now that it’s done and it’s ready, we’re going to go up to File, and compare it to our known good baseline, that baseline.arn file. And all this is going to do is take what the current system found and then take away anything that was in the old baseline system. And whatever’s left is what Trickster did. So if we go ahead and hit Open, we have one thing, all Trickster did when it ran was added a task scheduler, and it has one called Services Update, and the file that it’s telling you to run is this users/ieuser/appdata/roaming/winapp_usjdltufs.exe. Now, as I talk about this file when we go through our analysis, I’m going to refer to it as u.exe, because I don’t want to have to keep saying usjdltufs, because that’s just a really long weird name. So anyway, we see here that this was a change to the task scheduler, it didn’t touch the registry, it didn’t touch the file system, with the exception of putting this one file here in this path, and it’s being run through the task scheduler. So to look further into it, we’re going to go into our task scheduler. So let’s go ahead and open up our task scheduler by clicking on the windows icon, and typing in “Task scheduler.” And there it is, go ahead and open it. We’ll maximize this here and you can see that task name, Services Update, is showing up here and it’s set to run at 5:03 PM, which is in about three minutes from now, and it has multiple triggers to find. So let’s go ahead and look at these triggers and figure out what does this file do?
So if I double click on it, it will open up and you’ll see that the name with services update. You’ll see the description is, “Look for services monitor,” which doesn’t really make much sense in English. So that tells me that this may also be not a legitimate program. Now, let’s go ahead and look at Triggers. Under Triggers there are two triggers. Anytime somebody logs on the system, this task is going to be run, and then it’s going to happen daily, at 5:00 PM every day, which coincidentally is when we ran tricker.exe, and after it’s triggered, it’s going to happen every three minutes for one day. So every three minutes for the next 24 hours, it’s going to keep doing this program. And what is it going to do? Well, it’s going to start this program, this u.exe program. Now, we don’t know what u.exc does yet, but we do know that Trickster wants it to run every three minutes. So if you had to venture a guess as to what function of this program is, what do you think it would be? I think it’s probably a beacon, it’s probably calling out to a command and control server and saying, “Hey, I’ve infected this machine,
I’m here and I’m ready for orders.” That’s what I think this is doing, but we’ll look into that as we go through and try to prove our thoughts on this. Next, we can look at the conditions and you can see that it will start all the time. It will only stop if the computer ceases to be idle, and we can look at our settings here, it’s going to be a task that’s run on demand, it’s going to run it as soon as possible, and we can see the history. Has it happened yet? Well, not really because history was disabled here, there is no logging. But on a good system in an enterprise network, you may have this enabled and be able to see all the times that it ran. But since we don’t, we’re going to go ahead and look at this system, and see if we can figure it out. And so we can see the next time This is going to run is in just about a minute. Now, if we sit here for a minute, we’re not going to see anything because this program is run in the background, this program is run as a beacon and that’s just going to run where we can’t even see it.
And so we’re going to have to look at something like a process explorer, or be able to see the network traffic and see that callout occur. We’re going to use a program to see that callout happen and prove if this is or is not a beacon. Now, if you remember, we had a file, that u.exe that was being run on our machine. It is located under the C drive, and then under the User drive, under our user account of IEUser, under AppData, under Roaming, and then under winapp. And you’ll see, there it is. Now, there are three other things here, one folder and two files. Let’s see if there’s anything inside this Modules folder. Well, there isn’t yet, and the reason why is the Stage 1 malware, this us.exe file, has been making its call, but we stopped it before it ever had a chance to download any modules or malware, and really the reason why is because the IP addresses it’s calling to are benign, they are not malicious. But if this was a real piece of malware that was dangerous, it could be calling out and downloading that stuff into these modules and running that Stage 2 malware, to make it part of a botnet, or still your files, or conduct ransomware, or whatever its decided method would be. Next, it has two text files here, client_id and group_tag. And I’m going to open up client_id first, and we’re going to go ahead and open this with Notepad. Now, the client_id here, this is my host name, MSEDGEWIN10. What is all of this behind it? Well, this becomes a unique identifier or a serial number. And that’s what this malware is doing, it is going to be connecting to all of these machines and try to do something with that information. If it’s putting ’em in a botnet, it needs to know what machines are what. If it’s going to do ransomware, it needs to know who you are, something you pay them they can release your machine or not, depending on how the attacker’s going to do their job, but again, they need a way to identify you. And that’s what this client_id is, it’s just simply a serial number.
Next, we have this group_tag, and if we open up the group_tag in Notepad, we can see it’s just says, “TT0002,” which is just an alpha numeric code for this group that your machine is being put into. And again, if you’re going to be part of a botnet, maybe I want to be able to sell off 100 machines or a 1000 machines or 10,000 machines at a time, to connect a DDOS attack. Well, I need a way to group those together, and this group tag is simply that. So those are those two files and the module, and that’s what it did on to our hard drive. But it really hasn’t done anything malicious yet because this is just the Stage 1 dropper. Now, you can see how we might be going down all the way through, and digging really, really deep into this malware to figure exactly what it’s doing and how it’s doing it. And you can keep following these breadcrumbs all the way down, but at this point, we already have three different indicators to compromise. The first would be the file hash for tricker.exc.
The second would be the fact that it goes and creates this process, this executable, this u.exc file, and places it in the roaming winapp directory. Another one is the fact that it creates this client_id and this group_tag and this Modules folder. So we already have three right there, but if we want to dig deeper, we can actually start digging into this further and further and further. So now that we’ve done the dynamic analysis and figured out that this is a Stage 1 dropper, that it’s beaconing out every three minutes, and that it’s calling out to this particular IP address and it’s creating this client_id and this group_tag, let’s go and look at it statically, and dig just a little bit deeper to figure out what else we can determine inside of Trickster. So now that we’ve exhausted what we can do dynamically, we’re going to dig back into static analysis just little bit. So the way we’re going to do this is by opening up the u.exe file in a program called IDA. Now, IDA is a decompiler and we can find it here inside of FLARE, and then into Disassemblers. Now this decompiler, we’re going to open up is IDA Free, which is the freeware version of IDA Pro. It’s going to allow us to quite a bit, and we’re only going to use a very little bit about it.
So what we’re going to do is we’re going to disassemble a new file, and all we have to do here is drag it on here to disassemble it. So I’m going to bring back up that file, u.exe, and drag it and drop it onto IDA. So we’re going to load it up and we have to choose, is it an execute from DOS, a portable executable or a binary file? In our case, I believe it to be a portable executable because it’s running inside of Windows and not inside of DOS, as we saw from that comment we pulled out using the FLOSS tool. So we’re just going to go ahead and hit, Okay, and up, it’s going to pop. Now, if you notice here in, IDA View A on the left side, it’s going through and giving us the assembly code for this program, the best it can based on decompiling it and making its best guesses. Now, what we really care about here in IDA, though, is what imports and exports is this thing using? So I’m going to go ahead and hit Exports, and we really don’t see anything. If I go ahead and hit Imports, you can see all of the different processes and functions that are called from the kernel and from the APIs in Windows. And so here we have our imports and we can see the different types of functions that this program calls.
For instance, it opens and closes registry keys, and queries them, and we noticed that in process monitor that it did a lot of things with the registry. We can see the fact that it can create files or get a current directory, it can get command line arguments and run commands, it can load strings, it can register classes, it can do all sorts of different things. And as we scroll through this, we can learn a little bit about the program and what it’s capable of doing, just by looking through the different processes that it may be able to run. Now, that gives us some information, but it doesn’t give us a whole lot to go on. So unless you’re able to actually read these assembly language programs and be able to go through it step by step, this is not really going to help us for an introductory-level malware analysis. Now, let’s go ahead and close out of IDA, and we’ll go ahead and just say, “Okay,” and what we’re going to look at here is we are going to take this program, u.exe, and run it through a debugger. Now, a debugger allows us to run a program step by step, one instruction at a time as it goes through. So we’re just going to just go ahead and say, “Yes,” here, and, “Yes.” Now, what I want to do is I want to open up our file inside of Ali.Debugger.
And to do that, I’m just going to go in here to the C drive, going to go down to Users, IEUser, AppData, Roaming, and then down to the bottom for winapp, and there is u.exe. Once we open that up here, you can see, just like before, we have all of our assembly language here, as best as this can decompile and run it through step by step. Now, a lot of malware is going to protect itself from being run step by step. Let’s find out if Trickster and u.exe is one of those pieces of malware. So what we are going to do is we are going to go ahead and play it. And if you see the little play icon right here, and just say, “Yes,” it goes through and attempts to play this program step by step. Now, when we do it, it runs very quickly, and then it just terminates. Nothing really happened for us, right? Well, that means that this piece of malware, most likely, is detecting the fact that it’s in a debugger and going step by step. And so we’re going to have to use a little bit more complex method to be able to pull out that code and then analyze it in our static analysis. We saw that it was encrypted when we tried to run FLOSS earlier on, and now when we try to run through a debugger, we are actually getting it where it stops immediately, so it’s detecting the fact that it’s being stepped through the program. So instead, what we’re going to have to do is we’re going to have to run the process, capture it in memory while it’s being unpacked, and then be able to analyze it.
Now, to do that, we have to start with a clean VM again. And so what I’m going to do here is I’m going to pause this, and bring ourself back up to a clean VM with our antivirus turned off, our firewall turned off, and Trickster expanded onto the Desktop. So we are back and we now have our FLARE VM, and we should have our antivirus off, we have our firewall off, and we’ve unzipped the Trickster file. But before we move any further, we need to download a piece of software called Process Dump. So we’re going to go ahead and open up our Edge browser, and from our Edge browser, we want to go to split-code.com/processdump.html, that’s split code.com/processdump.html. And when we go there, you are going to be able to download the Process Dump file, which currently is version 2.1 for Windows 32 or 64 bit. And since we’re operating on a 64-bit operating system, that will work for line for us. We’re going to go ahead and hit Open, and it’s going to open it here in our Desktop, and we’re going to take PD64 and drop it onto our Desktop so it’s ready for us to use. And we can go ahead and close our Edge browser.
So now that we have PD64 in the Desktop, we want to go ahead and open up a Command Prompt, but I want to right click on it this time and run it as administrator. So go ahead and say, “Yes.” So now that we have our Command Prompt open as an administrator, we want to get into the directory that is our Desktop, which is going to be under C:/Users/IEUser/Desktop. And if we hit dir, you can see Trickster and PD64 are sitting there on the Desktop. So now I want to go ahead and run PD64, and create a hash database of all of this processes that are currently running before I put any malware in there. So I’m going to do that by doing pd64.exe-db, for database, space, gen, or G-E-N for generate. and then go ahead and hit Enter. Now, this is going to go through and find all of the processes that are sitting there on this system. And it’s going to capture them and create a good hash value for all of those processes. Now, this is going to take somewhere around five to 10 minutes, depending on how fast your system is. And so I’m going to go ahead and pause the video here, and come back once that hash database has been created. Then we’re going to be able to go and run Trickster and capture that malicious process and dump it, and then look at it inside of IDA.
Now, once the program is done, you’re going to get this, “Finished, the clean hash database has now been created,” and you’ll notice here on your Desktop, you have the clean_hashes file that is going to serve as that database. The next step to capture Trickster is to type in the command, “pd64.exe-p,” and then the name of the file that’s going to be running, which is trickster.exe. But don’t hit Enter just yet, we have to go and create Trickster first, because if I try to hit Enter right now, it’s not going to find anything because Trickster doesn’t exist. So I’m going to get it ready to go, right-click on Trickster, tell it to run as admin, then as soon as I hit, Yes, I’m going to click on the Command Prompt and hit Enter, to capture that process. So, Yes, click Enter, and you’ll see here that it is dumping that exe file to the file, trickster_exe_PIDed_trickster.exe, this big long file named right here, and as you can see, that is now on the Desktop, which is that piece of malware, unpacked and straight from memory. So the next step is to open this up in IDA again. So we’re going to go ahead and go to our Windows icon, type in I-D-A, and IDA should show up. We’ll open that up, tell it we don’t need the information displayed, agree to the terms and conditions, and tell it, “New.” And we’ll go ahead and hit Cancel. Then we need to go ahead and get the file from the Desktop, that trickster_exe file, that new one that we just dumped, and drop it into IDA, go ahead and hit, Okay, and Okay. .
And now we have that file we just captured from memory that we dumped from that process, and we can start low looking at it to see if there’s anything of interest to us. This should be a little bit more fruitful than the first time we looked at it in IDA. So let’s go ahead and look at our imports one more time. Now, we have a couple of new ones here that we didn’t have last time, namely the Sleep and the GetTickCount. Now, do these do? Well, GetTickCount is counting the processes, it’s basically a clock. And then there’s this Sleep function. Now, What is that doing? Well, let’s go ahead and double click on Sleep, we see that we have this sleep is going to happen for some amount of milliseconds. And if I go ahead and look at this, I can see here it says, “push 1388h,” which is the amount of milliseconds that it’s going to wait as it’s sleeping. Now, what does that equate to? Well, that equates to five seconds.
Now, why might it be waiting five seconds? Well, if we start walking through this program, you’re going to see that the reason is sleeping for five seconds and using that tick count to figure out what time it is, is so that it has time to launch the program, and then create, the file in folder and copy in u.exe to the hard drive, and then run u.exc. That’s what these calls are there for, so it starts, it waits, it creates the folder, it waits, it runs the program, it waits, that’s the idea here. So those are two new functions. Now, why does it do that? The reason why is because it is doing this as a way to detect if things are ready for the next step. And so you can see, if you can read assembly code, as you go through here, all of the things that this particular piece of malware does. Now, again, we’re not going to go through and dig into every single line of this code, it’s just too much and too in-depth for this course. This is not a class on assembly language or malware reverse engineering, but I just wanted to give you an idea of the type of information that you can find by process dumping this and loading it up into IDA, doing a very cursory search.
So again, this class is not designed to have you dig through this static analysis and learn every single piece about this program and how to reverse engineer it, instead, I just wanted to give you a couple of quick tidbits so that you can wet your appetite, if you want to go down this malware reverse engineering route, and really start digging into assembly code and how these things work. This is just to give you a little bit of exposure to it, not to make you an expert. Wow, I know that was a long video and that was a ton of information that was way in depth. Now, the good news is for the exam, you do not need to know how to do everything I just walked through in this video. Instead I was doing it just to give you an introduction, so you could see how this stuff works and start putting some of these pieces together as we talk about indicators that compromise on the network, as we talk about indicators that compromise from the file system, as we talk about persistence, like we saw with the scheduled tasks, and things like that. So this is just to give you a good overview into each of those areas, and you’ll really be answering multiple choice questions on the exam about these concepts, as opposed to having to actually do the physical work of analyzing every single piece of this malware, like I was doing inside this video.
140. Mobile Device Tools (OBJ 3.5)
For the exam, you need to know what several tools are used for in terms of exploiting and attacking mobile devices. This includes Drozer, APKX, APK Studio, APK SDK, Frida, Objection, Needle, Ettercap, the Mobile Security Framework, Burp Suite, and Postman. First, we have Drozer. Drozer is a complete security audit and attack framework, meaning you can think about this like you would the Metasploit Framework. Drozer provides us with the tools to use and share public exploits focusing on the Android operating system instead of Linux at large, OS X, Windows, or other desktop operating systems. Essentially, it narrowly focuses on exploits for the Android platform only, and that way, we can attack our smartphones and tablets. Second, we have APKX. APKX is the Android APKD compiler. We can give this tool an APK file, which is an Android binary or application, and it’s going to be able to extract that back down into its Java source code. As we do this, we can then look for vulnerabilities that we may turn into exploits. Once we identify that vulnerability and we have an exploit, we can then try to attack mobile devices using those exploits against those Android apps.
Third, we have APK Studio. APK Studio is a cross-platform IDE which is an Integrated Development Environment. This is what programmers use to write the source code for their applications for the Android operating system. Using the APK Studio, we can conduct reverse engineering against an Android application binary, and then we can modify that source code and then recompile it. If we took source code using APKX, we can then use APK Studio to be able to put that back together. When using APK Studio, it’s important to understand that there’s a decompiler, debugger, and compiler built right into it. Fourth, we have APK SDKs. Now, Android SDKs are a large set of tools, libraries, documentation, code samples, processes, and guides that are created specifically for use for the Android operating system. As a developer, you can use these functions and libraries that are defined by the Android SDK in your own malicious Android applications if you need to, and it can save you a lot of time. As you can see, Drozer, APKX, APK Studio, and the Android SDK all work together very nicely so that we can take that APK file, which is an application binary, pull it back down into its Java source code, and then bring that Java source code into the APK Studio where we can go through it line by line, add in exploits or vulnerabilities, recompile it, and then put it back out there into the wild as a form of malware inside of a Java application binary that can be read on any Android smartphone or tablet. Fifth, we have Frida. Frida is an open-source tool that provides custom developer tools for use by a penetration tester when they’re conducting application pentesting on mobile applications. Frida is a dynamic instrumentation toolkit for developers, reverse engineers, and security researchers, and this allows you to inject your own scripts into this black box that is a compiled Android application. This will also allow you to hook any function in that application, spy on cryptographic API calls, and trace functions as they’re called throughout the application even if you don’t have the source code. The great thing about Frida is that it’s not limited to Android applications, though. It also works with iOS, which is run on the iPhone, as well as Windows, macOS, and Linux operating systems.
Sixth, we have Objection. Objection is a runtime mobile exploitation toolkit that’s powered by Frida and built to help you assess the security posture of your mobile applications, without requiring that device to be jailbroken. Objection also supports both iOS and Android operating systems, and it comes with the ability to bypass SSL certificate pinning. Objection can also be used to explore and manipulate the memory heat, perform memory dumping and patching, and conduct inspection of the container file systems on those mobile devices. Seventh, we have Needle. Needle is an open-source, modular framework that’s used to streamline the security assessment process on iOS applications. While this tool is mentioned by name in the exam objectives, it is not included in the official CompTIA PenTest+ textbook because this tool has been decommissioned ever since the release of iOS 11. Since iOS made some tremendous increases in security, it essentially broke this tool completely. Instead of rewriting the entire tool, the developers instead recommended that pentesters switch over to using Frida which already developed a method to bypass some of the iOS 11 security controls. Therefore, Needle hasn’t been used since around 2017 or 2018, and Frida is a much better choice for iOS exploitation in your current engagements. Eight, we have Ettercap.
Ettercap is a comprehensive toolkit for conducting on-path attacks. Ettercap can sniff live connections, conduct content filtering on the fly, and support active and passive dissection of many different network protocols. Ettercap does come installed in Kali Linux by default. Now, note, Ettercap is not exclusively a mobile exploitation tool, but instead, it can be used against any network connected host or device, but the exam objectives do list it under mobile tools, so that’s why we’ve included it here. Ninth, we have the Mobile Security Framework, known as MobSF. The Mobile Security Framework is an automated, all-in-one mobile application pentesting, malware analysis, and security assessment framework that’s capable of performing both static and dynamic analysis for Android, iOS, and Windows mobile devices. The Mobile Security Framework supports mobile app binaries, including APKs, XAPKs, IPAs, and APPXs, along with zipped source code, and provides REST APIs for seamless integration into your CI/CD or DevSecOps pipelines. It also includes a dynamic analyzer that helps you perform one-time security assessment and interactive instrumented testing. Tenth, we have Burp Suite. Burp Suite is a web intersection proxy, and it is by far the most famous web intersection proxy. This is a graphical suite that’s used for web application security, and it allows for the interception, inspection, and modification of raw traffic that passes through it. Burp Suite is heavily used by penetration testers because it allows us to modify all of these things like session keys and passwords and hidden forms and things like that.
The reason Burp Suite is being mentioned in this lesson on mobile penetration testing tools is that it has a special module that’s designed to test iOS devices, too, but keep in mind Burp Suite’s primary function is as a web proxy and not as a specialized mobile device penetration tool. Eleventh, we have Postman. Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so developers can better create APIs faster. If you’re conducting a penetration test against a mobile application, you’re also likely going to be using Postman to test each of those APIs that are being called by that mobile application to ensure that they’re safe and secure.
Postman can also be used to automate much of your testing across different APIs and applications that are relying on those APIs which is why we cover it in this lesson. As you can see, there are lots of different tools that touch or use our different mobile devices. This includes things like Drozer, APKX, APK Studio, APK SDKs, Frida, Objection, Needle, Ettercap, the Mobile Security Framework, Burp Suite, and Postman. For the exam, you need to be familiar with what each tool is and what its particular use case is. For instance, if I ask you which of these tools was a mobile decompiler, you would probably say APKX because that is its main function. On the other hand, if I ask you which of these can be used as a web intersection proxy with a mobile device, that would be Burp Suite. That’s the level of detail you really need to know when it comes to tools on the PenTest+ exam.
