137. Mobile Device Attacks (OBJ 3.5)
In this lesson we’re going to talk about mobile device attacks. Now, many of us carry mobile devices with us and most employees for organizations do as well. These mobile devices are essentially mini computers and therefore they’re still subject to the same types of malicious attacks and malicious programs, as other computers too. Things like spyware, Trojans, rootkits, viruses and worms are all different types of malware that can be made to affect mobile devices like iPhones and Android, smartphones or tablets.
So we’re not going to spend a lot of time talking about those types of malicious programs because they’re the exact same as you would use against a larger device like a laptop or a desktop or a server. The only difference is we compile that code to run towards Android or iOS, depending on what type of model we’re going after in terms of mobile devices. When it comes to installing malware on a victim’s device, it is a little bit more challenging if they’re using an iPhone since it relies on the iOS platform. iOS is really considered a walled garden and it’s more restrictive and is a lot more difficult to be able to get things onto those devices.
The exception of this is if that user has jailbroken their device. If they’ve jailbroken their device this is going to allow you to install apps outside of the official App Store. And this will allow you to have malware and other malicious things installed on this device. In terms of Android, it really is a lot easier to get malware installed onto those devices because they’re less restrictive by design. Android was developed to be an open OS. This means you can install apps from third-party sources outside of the official Google Play Store. Now that also means we have the ability to actually get malware onto those devices a lot easier. If those Android devices are rooted, those apps that we install could be run using root permissions and that will give us access over the entire device to do whatever we want. Another common attack against mobile devices is the overreach of permissions.
Now the overreach of permissions is really based on the fact that different apps are going to be installed on a mobile device and the end user will give those apps different permissions. For example, if you’ve ever installed a game and ask can I have access to your contact list? That is really an overreach of permissions because the game doesn’t really have a need to be able to access your contacts or maybe you’ve had some that ask if they can access your microphone or your camera or your photos. Again, all of these can be an overreach of permissions, as a penetration tester we can use overreach of permissions to our own advantage though because if we can get our target organization to start installing applications that we put out there that have this overreach of permissions we can then gather data on those targets, using our application and send it back to our servers. Another area that we see a lot of mobile device attacks occurring in is the world of social engineering. This includes things like vishing and smishing and spamming. When you’re dealing with vishing remember, this is a type of phishing that occurs using voiceover internet protocol or voice calls. If you’re dealing with smashing this has to do with text messages. If you’re dealing with spamming this can be the unsolicited calls or text or even emails to a particular mobile user.
By using social engineering a penetration tester can do a smishing campaign where they try to get somebody to click on one of those link shortened URLs. That’ll actually lead them to install some sort of malicious code onto that device. This is a very common tactic, and you probably see this yourself every single day where you’re getting at least one or two of these text messages to your phone try to get you to click on some kind of a link. Normally they’re going to use something that sounds familiar like this is the tracking link for your Amazon order or your PayPal account has been over-drafted. And so you need to click on this link to go and check your balance. All these are things you can use in your own campaigns as well, to get that mobile user to click on a link and install your malicious application onto their device. Other common area to attack on a mobile device is Bluetooth. Now in Bluetooth, we have a couple of different ways to attack this. The first way is to do what’s called Bluejacking. Bluejacking is a method used by attackers to send unwanted text messages, images and videos out to a mobile device user over their Bluetooth connection. Essentially, when you hear Bluejacking, I want you to remember you are sending something to somebody unsolicited.
Now, on the other hand we have something called Bluesnarfing. Bluesnarfing is a more aggressive type of attack where the penetration tester or attacker is trying to read information from that victim’s Bluetooth device. The end goal inside of Bluesnarfing is to snarf or grab information off of that device. So remember, Bluejacking is sending information, Bluesnarfing is taking information. Another common attack against Bluetooth is to hack the Bluetooth signal itself and be able to pair and create a personal area network between your attack device and the Bluetooth device that you’re trying to attack. This can then allow you to either do Bluejacking where you’re sending data to them. Bluesnarfing, we are taking data from them or simply using their device as a pivot point into the network using the other methods of communication on that device such as their WiFi or cellular modem.
138. Malware Analysis (OBJ 3.5)
As a penetration tester, sometimes you have to get your hands dirty to create unique exploits, especially when dealing with mobile devices. To do this, one of the best ways to learn is to actually look at other malware that’s out there, take it apart, and figure out how it operates. In order to do that safely, you’re either going to have to use sandboxing or reverse engineering to identify how a piece of malware works. Malware creators are getting more advanced in their techniques to disguise their malicious intent. Now, to compete with this, malware analysts need to keep improving their techniques and their ability to conduct manual analysis of the malware. To do this, they have to run malware in a controlled environment to observe its effects, but they don’t want infect their own networks and systems. To do this, they use a technique called sandboxing. Now, sandboxing is a computing environment that’s isolated from the host system to guarantee that the environment runs in a controlled, secure fashion, and that the communication links between the sandbox and the host are usually completely prohibited. Now, most often, you’ll see a sandbox environment created by using a virtual machine or a virtual box, this allows us to install whatever operating system we want, set up the parameters we need, take a snapshot, and then we can load malware inside of it and find out a couple of things about it. For example, if we run a malicious file inside a sandbox, we can determine if that file really is malicious. Also, we can determine any effects it’s going to have on the system.
And finally, we can identify any dependencies with files and the hosts that may exist when you run that piece of malware. By using sandboxing, it allows you to quickly test malware in multiple different environments across multiple different operating systems without affecting your underlying host. Now, to effectively analyze malware, we’re going to use a sandbox, and we’re going to use a lot of different features of that sandbox. For example, we can monitor any system changes without any direct user intervention. So, if I run the file and all of a sudden, some changes happen to the system, I can identify that within the sandbox. Also, I can execute files that are known malware, and if they are known malware, I’m going to be able to monitor for any changes to processes that happen on that system. And I can use that as a way to develop my signatures. Additionally, I can monitor network sockets for attempted connections, and that way, I can identify any known bad IPs or any command and control notes that may be getting called out to by using DNS. After that, I can also monitor for system calls, and this way, I can also see if there’s any APIs that are going on that are being called out by this malicious program. Also, we can use a snapshot feature inside of our sandbox, and this allows us to take a periodic snapshot of the environment before we run the program, and then we can run the program and roll back to that previous snapshot.
Another thing that allows us to do is to record any file creation or deletions that may happen when we run that piece of malware. And finally, it’s going to allow us to dump the virtual machine’s memory from that sandbox, we can do this at key points of time, so, sometimes when we’re dealing with a piece of malware, it may be packed or compressed, and it won’t be unencrypted or decompressed until we run it, and so, by running it inside a sandbox, we can dump that virtual memory and capture the malware that way. Now, one of the big keys you have when you’re dealing with the sandbox is that your sandbox host, which is a virtual machine, should not be used for any other purpose except for your malware analysis, this keeps your sandbox clean and once infected, it keeps that infection from spreading elsewhere. Now, there are a lot of different tools we can use when we’re doing sandboxing. One of my favorites is called FLARE VM, and it’s provided by FireEye. This is a free program that you can install on top of a Windows 10 machine, and this will then allow you to run Windows binaries, and with the right emulators, you can also run Android apps to see how they operate.
Another great tool that’s out there is called Cuckoo, and Cuckoo Sandbox is a program that will allow you to automatically run a bunch of different malware samples in it and be able to see what it does inside of a Linux environment, a Windows environment, or even a Mac environment. Cuckoo does a really great job of providing you a lot of automation tools, so you don’t have to do as much manual analysis as you’re going through and doing your malware analysis. Now, because the CompTIA exam is considered vendor neutral, they’re not going to ask you about these two specific tools, I’m just mentioning them, because they are great tools if you want to get into the world of malware analysis. Now, if you want to do a complex analysis, though, you may need to create a honeypot lab, and this will have multiple sandbox machines and internet access, so you can actually study the malware and its C2 structure as it starts communicating with lots of other things. Again, it is something that in the real world, if you’re working as a malware analyst, you may set up and you may use. Next, let’s talk about reverse engineering. Reverse engineering is the process of analyzing the structure of hardware or software to reveal more about its functions. Now, a malware reverse engineer can determine who actually wrote the code by starting to learn their patterns. Most people who code have their own style, their own way of writing. If you’ve ever read somebody’s handwriting, you can look at it and over time start learning whose handwriting belongs with which person. Well, coders are much the same, and as you start reading enough of somebody’s code, you can start seeing exactly their processes, and you start identifying this piece of malware with this particular person. And that’s one of the benefits finding a strong malware reverse engineer working on your team if you’re doing a lot of instant response or you’re working for a threat intelligence gathering agency. Now, as you’re reverse engineering malware, some malware is easier to reverse engineer than others. For example, if you’re using something like Java, like Android apps, this can be easily decompiled back into the source code that looks like this.
Once you have the source code, you can then understand what’s being done inside the malware. Now, unfortunately, not all malware is easy to read and dissect like this Java code. A lot of malware writers will actually obfuscate their code before it’s assembled or compiled to prevent analysis by a reverse engineer. This makes it convoluted and very non-straightforward in the way that somebody could read it. And this makes your job much harder if you’re a reverse engineer. Now, there’s a couple of tools that will help us with that, though. For example, the first one is sandboxing. Whatever difficulty you may have when you’re reverse engineering malware, if you’re doing it in a sandbox environment, it’s going to have no impact on your production systems. This is especially necessary for malware when you’re trying to detect what is being done as it’s being deconstructed or run, doing something in a more dynamic method. Now, when you start doing things statically, you have to have actually get to the code, and we use a couple of tools to do this. The first one is known as a disassembler. Now, a disassembler is a computer program that translates that machine language into assembly language. Now, machine code, when we talk about machine language, is simply the binary code that’s executed by your processor.
Typically, it’s represented by two hex digits for each byte, and each bite is eight ones and zeros. Now, what does this look like? Well, here on the screen, you can see the memory view, and I have that 6F highlighted in blue. That is the first byte that we’re looking at at that particular memory location. That is a two-digit hex code, that translates to a series of ones and zeros, and that tells the computer what it should be doing based on that instruction code. Now, as a human, though, that doesn’t mean much to me, those codes are very difficult to read, and if I have a whole screen filled with those type of hex digits, it’d be very hard for me to figure out exactly what that program’s doing. Now, the next step up from machine code is going to be assembly code. Where machine code is written in ones and zeros or hex digits, assembly code is written in something that’s more human-readable. Now, this is the native processor instruction set that’s used to implement a program. In the old days, we used to actually write programs inside assembly, but nowadays, that is also a little bit hard to do. So, if we look here at the next screen, you can see, up at the top, I’ve highlighted the first two lines of that hex machine code. Now, if you see, I highlight the bottom in the disassembly section, this is that same hex codes from the top. Again, not very easy for us to read, but if I look over to the right side, you will see the assembly code. Now, this is more human-readable. You can read this. I see mov, which tells me I’m probably moving stuff from one register of the memory to another. I have push, which says I’m putting something into memory.
I’m calling, I’m pulling things from memory. These aren’t necessarily the easiest thing to read, but it is still something that a human can read, and back in the 70s and 80s, a lot of our computer programs were written straight in assembly. Now, to get to assembly, we use a decompiler, and a decompiler is software that translates a binary or low-level machine language into a higher-level language. So, if I take the binary and I move it to assembly, a decompiler can do that or a disassembler can do that. Now, once I have that, I can put it through a decompiler and get it to a higher-level code. Now, when I talk about a higher-level code, what is that really? Well, high-level code is real or pseudocode in human-readable form that makes it easier to identify functions, variables, programming logic, and other things like that that are used in the code. Now, I talk about a higher-level code, I’m talking about things like C, or BASIC, or Java, or something like that, those are all languages that, if I gave you some script from that, you could probably figure out what’s going on just by reading it, ’cause it reads similar to English, not like assembly and definitely not like machine language. Now, let’s take a look here on the screen. Here on the screen, I have a program called IDA Pro, which is a famous decompiler. It takes the ones and zeros, that binary and hex values, translates it into assembly language by doing a disassembly function, and then it can take that disassembly function and run it through a decompiler and come up with this pseudocode.
Now, this code is not what the original programmer wrote, but this is an equivalent program that would do the functions of what that person wrote, and so, this will allow us to go through, as we’re doing a our reverse engineering, and understand it a little bit more than using something like assembly. Now, some languages, like Java, have their own decompilers, and they can take it from the ones and zeros all the way back up to something that looks like real Java, as you could see here on the screen. This is an example of a Java decompiler, and we’ve taken this binary class file and it’s gone through and brought it back into the text where it’s very easy for you and I to read it. Now, why do we care about getting all of this stuff back to a human-readable form? Well, there’s a couple of reasons, one is we could figure out what logic is being used inside this malware and what functions it’s doing, and another is to identify strings, because as a reverse engineer, we want to attempt to identify malware by finding strings to use for signature-based rule detection. Now, by doing that, we can identify these different strings from the code, we can put that into our rules, and then we can flag that and alert on that when malware tries to attack us. Now, when I talk about a string, a string is simply any sequence of encoded characters that appears within the executable file. These strings can be lots of different things. You can find things like ASCII sequences that contain user names, or passwords, or file names, or function calls, or even things like a URL. For instance, if a malware contains a string with a function called InternetOpenURL, and another string that says URL, you probably can guess that it’s trying to attempt to download something from that web address as part of the malware. Maybe this is a dropper, it’s going to download some second-stage malware by going to this URL. Now, there’s a tool that you can use to dump these strings very easily without having to go through all the reverse engineering, it’s called Strings.
And the Strings tool will dump all the strings that are over three characters in ASCII or Unicode encoding to a text file or to your screen, so you can then look at it and analyze it yourself. Now, the one problem when you’re using Strings is that it will find anything that is over three characters, which means it can find a lot of garbage too. When I run this, when I’m doing malware analysis, you will see that a lot of the stuff that it outputs to us is stuff that just looks like gobbledygook, it’s something you can’t even see, but you’ll also find some valuable things in there too, and so, that’s why we still run Strings against malware samples. Now, the next tool we want to talk about in our reverse engineering of malware is program packers. Now, malware can use a program packer, which is a method of compression in which the executable is mostly compressed, and the part that isn’t compressed basically just contains code to decompress the executable. Essentially, a packed program is a type of self-extracting archive. Now, there are a couple of reasons that malware writers use these packed programs. One is that it makes the file size a lot smaller, so it’s easier to transmit this malware, and the second is it makes it harder for us as reverse engineers to see the file’s contents, because we have to unpack it first before we can see it. This is another way that they do this to obfuscate things. Now, some people think, “Well, anything that’s packed must be bad, right?” Well, not necessarily.
A lot of organizations who share proprietary software will use program packing to deter theft of intellectual property and copyright violations and piracy. So, you can’t just block every program that’s packed, because it doesn’t necessarily mean it’s malicious, but a lot of them are. So, what do you do if you have a piece of packed malware? Well, first you’re going to unpack it before you can analyze it, because until it is unpacked, packed malware can mask literal strings and effectively modify its signatures to avoid triggering signature-based scanners. And this is why you’re going to have to unpack the malware and then perform your analysis on it. In fact, when I do malware analysis, we actually will do the analysis on the packed program first, and then we will do it again once we unpack the program, because sometimes, we can find different strings in there and use those to build our signature rules.
