Research Saturday 4.21.18
Ep 32 | 4.21.18

InnaputRAT exfiltrates victim data — Research Saturday


Dave Bittner: [00:00:03] Hello everyone, and welcome to the CyberWire's Research Saturday presented by the Hewlett Foundation's Cyber Initiative. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities, and solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Dave Bittner: [00:00:26] And now, a moment to tell you about our sponsor, the Hewlett Foundation's Cyber Initiative. While government and industry focus on the latest cyber threats, we still need more institutions and individuals who take a longer view. They're the people who are helping to create the norms and policies that will keep us all safe in cyberspace. The Cyber Initiative supports a cyber policy field that offers thoughtful solutions to complex challenges for the benefit of societies around the world. Learn more at

Dave Bittner: [00:01:02] And thanks also to our sponsor, Enveil, whose revolutionary ZeroReveal solution closes the last gap in data security: protecting data in use. It's the industry's first and only scalable commercial solution enabling data to remain encrypted throughout the entire processing lifecycle. Imagine being able to analyze, search, and perform calculations on sensitive data, all without ever decrypting anything. All without the risks of theft or inadvertent exposure. What was once only theoretical is now possible with Enveil. Learn more at

Richard Hummel: [00:01:42] This particular one came to our attention via some spam messaging.

Dave Bittner: [00:01:45] That's Richard Hummel. He's the Threat Intelligence Manager for Arbor Networks' ASERT team. The research we're discussing today is titled "Innaput Actors Utilized Remote Access Trojan Since 2016, Presumably Targeting Victim Files."

Richard Hummel: [00:02:00] We were able to look at some of the metadata and look at the actual payloads attached. And from there it kind of led us to what we call the "InnaputRAT." So, everything here spawned from the phishing emails. And, you know, typically phishing emails are a dime a dozen. So, what brought our attention to this and made us focus on it was the themes. Some of the senders were masquerading as - appear to be political entities. And it appeared they were targeting commercial aspects, just based on the theme of the message - the subject lines, the body of the messaging, and then who it's actually targeting. So, we didn't capture all of the phishing messages themselves. But we were able to retrieve the content, which led us to kind of the path that we were walking here.

Dave Bittner: [00:02:45] Well, let's start with those phishing messages. What was the content that got people hooked?

Richard Hummel: [00:02:51] One thing I would just kind of call out as anecdotal, initially, as a caveat, is we don't typically look into victim environments. We observe a lot of things from a network perspective. I mean, if you look into our ATLAS dataset, it's primarily just network-based data. So, I can't confirm that any victims actually were compromised by this.

Dave Bittner: [00:03:11] I see.

Richard Hummel: [00:03:12] So, we're looking at the outside, right? We know that it was sent to X victims, but we don't know the follow through.

Dave Bittner: [00:03:19] I see.

Richard Hummel: [00:03:20] So, yeah. So, I can't I can really go into, like, you know, what made them click on it. But, essentially, the phishing emails themselves come at a time where there's a lot of political upheaval. Various different geopolitical discussions and disagreements going on. And then, when you're targeting commercial manufacturing, a lot of players are in different countries, right? So, they have awareness of what's happening in the geopolitical space. So it's definitely something that comes at an opportune time for attackers to then go ahead and manipulate would-be victims by using those themes.

Dave Bittner: [00:03:51] So, let's dig in some and talk about this InnaputRAT element to this. Describe to us what's going on here.

Richard Hummel: [00:03:59] Sure. So, when we first came across this, like I said, we started with the phishing messages. And then from there, we were basically able to look at the command-and-control infrastructure. From there, we found our initial payload which was directly tied to the phishing email. We started looking at it, analyzing it, one of our reverse engineers ripped it apart, figured out exactly what it did.

Richard Hummel: [00:04:22] It's fairly trivial, as far as a RAT goes. There's a lot of RATs out there that have a whole lot of functionality. This one's not necessarily full-function. It's pretty basic in what it does. It's able to profile the system that it's on and then able to exfiltrate data. Now, there's no additional components to it, right? So, how an attacker's using it we don't know. Again, we don't sit in that victim environment. We suspect, though, that the RAT is used as kind of a backdoor. And then, once the attacker has compromised victims, they're then able to use that RAT to exfiltrate data that they manually find on those systems. But, again, that's speculation at this point since we don't actually see inside that environment.

Dave Bittner: [00:05:00] So, the RAT itself could be a first step in compromising a system.

Richard Hummel: [00:05:06] It's definitely part of that. We also saw later versions of it being distributed with Godzilla Loader, which is a fairly common cyber criminal tool that you can purchase from underground forums, and that's basically the stager, right? So, the phishing email is kind of ground zero. That's not to say they don't use other methods to get on the network, but phishing emails is definitely the one that we observed.

Richard Hummel: [00:05:27] Then we saw the InnaputRAT that was distributed directly. But then later on, we saw that Godzilla Loader as kind of the intermediary. So, maybe they didn't have enough success distributing InnaputRAT directly, and so they then used Godzilla Loader. Because it's paid-for service, they're fairly good about getting around security and things like that in victim environments for successful infections.

Dave Bittner: [00:05:49] And what are some of the details, what do we need to know about Godzilla Loader itself?

Richard Hummel: [00:05:53] So, we didn't spend a whole lot of time analyzing Godzilla Loader, just because there's a plethora of sites out there and other security researchers that have done ample research dissecting Godzilla Loader.

Dave Bittner: [00:06:03] Gotcha.

Richard Hummel: [00:06:03] I guess the main thing to note is that they are using it, right? So, any number of research blogs out there it could go through the details of stripping Godzilla Loader apart. The important thing to note here - and I think kind of lending to attribution a little bit - is it's a cyber criminal tool purchased on an underground forum. That's not say that APT type actors don't use it - we have seen more of that. But it is cyber criminal world. So, it could lend credence to the fact that these guys are organized crime. They could be just criminals moonlighting. We don't really necessarily know who they are, but the fact that they're finding Godzilla Loader and that it's typically purchased on underground forums is of note.

Dave Bittner: [00:06:42] So, one of the things you noted in your research was this evolution of InnaputRAT, and how that allowed you to sort of rewind the clock and see how far back this might have gone. Can you take us through that evolution and how the functionality changed over time?

Richard Hummel: [00:06:59] The changes themselves aren't super important, right? It doesn't really change the functionality and the capabilities of the RAT itself. What we noticed over time is evolution of how they're distributing the bot, as well as how it gets installed. So, going chronologically, we could start with Sample 1, which goes all the way back to 2016.

Richard Hummel: [00:07:19] The third sample that we have listed in our chronological order here is the one that we first started with. So, we started doing binary analysis. We did a bunch of different searches using a bunch of different tools. We have our internal malware sandboxing system. We have millions of samples that are categorized and stored. We also have some partnerships with other vendors that have sample sources. So, we were able to basically do some searching. We created some of YARA signatures looking for particular aspects of it. We looked at the actual command-and-control looking for additional samples. And through the course of analyzing all the different binders we found a couple of different ones.

Richard Hummel: [00:07:56] And then we found even more looking at the actual infrastructure itself. So, we found a total of five binaries, at least the ones that we analyzed. I think we have hundreds of them at this point, but the ones that we pulled out were ones that had differences or were tied together through the infrastructure, which is kind of why we have five samples listed here.

Richard Hummel: [00:08:14] So, starting with the first one, I think the most notable difference between Sample 1 and Sample 2 is that they changed the order of the commands that they use. So the command options are basically API calls in a Windows environment that it's using to perform various functions, right? So here we see it reading files. It can write files, it can delete files, and basically do some system scanning. The way that they call this particular API, the ReadFile, changed from the first sample to the second sample.

Richard Hummel: [00:08:45] So that's one change. The other thing is the infrastructure itself has an overlap. And then, when we actually go and we match these binaries together, there's a bunch of different functions in a particular binary. And so, the more matches you have, the more likely it is it's the same compiled code. Although, typically when you have a new variant, there's going to be functions that stand out as different. That's pretty atypical when you're analyzing samples over time.

Richard Hummel: [00:09:11] That read call is the main thing that changed. And then also the persistence method. So, the first sample would create a Windows service. That was kind of how it installed its persistence. It was called OfficeUpdateService. And that's fairly common for a lot of different binaries. That is the second most common. The first most common would be creating a Windows registry key to auto run upon booting your system up. And that's the change that happened between the first sample and the second sample. So, Sample 1 we have Windows service that's created, and in Sample 2 it actually creates a persistence key in the windows registry to run upon system boot up.

Richard Hummel: [00:09:48] Moving into Sample 3, not a whole lot changed from one to the other. The biggest change here was going to be the actual filename. So it went from something called SafeApp.exe to NeutralApp.exe. The whole command options were persistent from Sample 2 to Sample 3. We didn't do any diff matching, like Diaphora differential matching, with this sample because this was our ground zero sample, but it does match a lot of the other other ones as well.

Richard Hummel: [00:10:15] So then, moving on to Sample 4, we can look at, again, some of the same command-and-control infrastructure overlap, persistence with the naming of the sample and NeutralApp.exe as well. And you could see that we matched 33 of the particular functions, with 13 unmatched.

Richard Hummel: [00:10:32] In this particular sample, Sample 4, is when they started doing a little bit of anti-analysis. So, some of the API names, the various strings within the binary, are obfuscated. Now, they're not using a super sophisticated method for this. They're just using a simple XOR with an 8-byte key. It's fairly simplistic, but it's enough to get around some of the different pattern-matching signatures that we might have. For instance, if we were looking for a particular string or particular function call using YARA, and we were just looking at regular ASCII text, if they did this obfuscation with XOR, we're not going to see that unless we know that key, and then we can basically decode those before we do our pattern matching.

Richard Hummel: [00:11:08] And then in Sample 5, we basically - the biggest change here is that more of those strings and more of those API calls were obfuscated. And you'll note that the matching function diminishes slightly. So, we have 27 unmatched as opposed to the 13. And that's just because they're adding that additional obfuscation, so things aren't going to match one-for-one.

Dave Bittner: [00:11:30] Yeah. And so, when you look at how it changed over time, is there a story there? You know, behind the scenes, what their goals were, what they were trying to do? I mean, it seems to me like the obfuscation is the main thread through this - is that accurate?

Richard Hummel: [00:11:44] Yeah, I would say that's probably the biggest change, the biggest change that's really going to impact the RAT itself. The changes of the various read calls, the change of the persistence mechanism - those are really going to change a whole lot. I mean, both of those are fairly common, as far as persistance mechanisms, and they're both really common places for security applications and tools to look for malicious apps. So, that's not really going to impact the bot itself. It's not going to really impact their viability to stay on a system.

Richard Hummel: [00:12:11] The obfuscation, though, is what's going to enable them to get around a particular set of scanning rules. So that's probably going to be the biggest change that occurred between the variations. And, honestly, if you look at the actual evolution, it's fairly trivial. I mean, there are minor increments of code updates. It could just be that, over time, they figure new ways to do things, or, hey, why aren't we obfuscating? Let's go ahead and add that in. So, I don't think it's, like, super significant, and they're not using a very complex algorithm, but it is sufficient to deny pattern matching for certain things.

Dave Bittner: [00:12:43] So, what's your perception of the sophistication of these actors? And I guess the second part of that would be, for the type of information they're looking for, is sophistication necessary?

Richard Hummel: [00:12:57] I wouldn't say that they're highly sophisticated. I mean, when you compare them against other threats, it seems like more of the run-of-the-mill stuff to me. And is it necessary? I don't know. When we look at a lot of potential APT actors, for instance, a lot of times they don't necessarily care about stealth, right? They want to get into the system, they are going to exfiltrate as much as they can, and they're going to get out. A lot of the tools they use - Poison Ivy, njRAT - they're very noisy, right? So, it's not like they're trying to evade stuff. But if they accomplish the goal of exfiltrating certain data - mission accomplished, right?

Richard Hummel: [00:13:28] So, I don't think they have to be highly sophisticated. It could be a highly-sophisticated actor using primitive tools to do something like this. Maybe they're doing it moonlighting or a side project or something like that. They did go to the effort of using Godzilla Loader, which means they did drop some funds in order to acquire the use of that software. So there is some aspect here where they're paying to increase their sophistication slightly or increase their success rate. But I don't necessarily think that these guys are super highly-sophisticated in that sense.

Dave Bittner: [00:13:58] So, let's talk about the attribution. Take us through what your conclusions are.

Richard Hummel: [00:14:04] Just kind of based anecdotally here, and a caveat before we go into this, we're basing this largely on information presented to us and available online. Right? Any actor anywhere could basically masquerade this data, they could create fake entries, they could create fake email addresses. So, take kind of what we've written here as a grain of salt. We've, you know, appropriately caveated that, hey, we believe this based on what we've found, but that's saying, you know, an attacker could go in and create all these personas. They could create these fake Twitter accounts, these fake Facebook accounts, all to make them look more legitimate.

Richard Hummel: [00:14:39] So, that said, we can dive into this. Basically, what we first looked at is the initial infrastructure and that phishing message. From there, it led us to InnaputRAT. And then we started looking at who registered them, looking at their email addresses, the phone numbers within various Whois information, and then we started doing some chain analysis. So, whatever graphing tool you might be used to - Analyst's Notebook or Maltego or something like that - we started plotting these various entities out, highlighting their names, their addresses, their phone numbers, their email addresses.

Richard Hummel: [00:15:10] And then from there, pivoting to additional infrastructure that they might have registered. And that led us to additional samples of InnaputRAT. And so, through basically a series of looking at different domains, looking at the IP addresses in the hosting, as well as the registrar data, we were able to basically find these five different samples, as well as a bunch of different infrastructure that matches our original phishing message theme like the MFA events we saw US Embassy report. So these same themes are things that we identified. On top of that we had some more generic stuff, like Google and Microsoft.

Richard Hummel: [00:15:48] So, some of the different campaigns and themes that I've seen over the years working these types of threats - a lot of them have actors that zero in or home in on a specific AO that they're really interested in. But oftentimes you also have them do more generic stuff. So, a lot of the crime actors, they kind of - they shoot shotgun shots out, right? They want to hit wide. They don't necessarily care about necessarily specific entities, but sometimes they will drill down a little bit further if they're - maybe they're contracted out by somebody or they have a particular interest in a certain financial organization, then they might single them out to go a little bit further.

Richard Hummel: [00:16:27] But a lot of times they like to try to go wide, get as many people compromised as possible because they're going to get a better return of their investment and their time. So, often, even though we might see some targeted activity, we'll also see the stuff that kind of targets wide with Google, Microsoft, various web mail providers, and things like that.

Richard Hummel: [00:16:44] Through the course of all of our investigation and tying all of this together, we came across three particular entities. And, again, they could be made up. We don't know. But based off of what we were able to see, they all have kind of a Russian flavor to them. Whether that's APT or crime, at this point we don't know. We basically just presented the facts of our findings and then highlighted the differences and what led us to believe that it might be a Russian-type nexus.

Dave Bittner: [00:17:12] Is this still an active campaign? And if so, how can folks protect themselves against it?

Richard Hummel: [00:17:18] Yeah, so, as of yesterday, I was just talking to the researchers that are primarily responsible for this, and we were still seeing some of the activity. The command-and-control infrastructure for at least one of them is still live. We've been looking at contacting various ISPs to see what we can do to try to help eliminate some of this malicious activity.

Richard Hummel: [00:17:38] But right now, the biggest thing that you can do really is practice good hygiene, right? Don't open emails from untrusted senders. If something looks a little bit suspicious forward it to your support desk and ask them for guidance. A lot of these threats - I'd say the probably the number one threat impacting organizations, going back how many years I don't know at this point, is email. Attackers like to include malicious attachments, they'll include links. The link might appear to be benign but the actual hyperlinked text itself is leading you to malicious site.

Richard Hummel: [00:18:11] So really, just a practice a little bit of caution. When you're opening up an email, make sure it's from somebody you trust. If you're uncertain, reach out to them separately, ask them, hey, did you send this to me? When you are opening things just ensure you're not actually executing a binary. If you open up a document and it has macros or some type of script content inside, don't enable that without getting a verification of where that came from.

Richard Hummel: [00:18:38] So there's a lot of just general use practices that can be done to help eliminate this threat. One of the things that we do here is all the indicators of compromise that we see, as well as signatures for the particular activity, we include those into our systems so that, when when we're blocking the activity - whether it's via our ATLAS intelligence feed or one of our systems like APS - we're pushing all of these IOCs and what we call policy or a signature to our systems, so that we can then block the malicious activity.

Dave Bittner: [00:19:14] Our thanks to Richard Hummel from Arbor Networks' ASERT team for joining us. The research is titled "Input Actors Utilize Remote Access Trojan Since 2016, Presumably Targeting Victim Files." You can find it in the blog section of the Arbor Networks website.

Dave Bittner: [00:19:30] Thanks to the Hewlett Foundation's Cyber Initiative for sponsoring our show. You can learn more about them at

Dave Bittner: [00:19:38] And thanks to Enveil for their sponsorship. You can find out how they're closing the last gap in data security at

Dave Bittner: [00:19:46] The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technology. It's produced by Pratt Street Media. The coordinating producer is Jennifer Eiben. Editor is John Petrik. Technical editor is Chris Russell. Executive editor is Peter Kilpe. And I'm Dave Bittner. Thanks for listening.