Pacifier APT: Liviu Arsene from Bitdefender.

Dave Bittner: [00:00:03] Hello everyone, and welcome to the CyberWire's Research Saturday. 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:23] I'd like to tell you a little bit about our sponsor, Cybrary, the people who know how to empower your security team. Cybrary is the learning and assessment tool of choice for IT and security teams at today's top companies. They deliver the kind of hands-on training fifty-five percent of enterprises say is the most important qualification when they're hiring. And once you hire, you want to retain. And Cybrary helps there too, because seventy percent of employees say professional development is a big reason for staying on board. Visit www.cybrary.it/teams and see what they can do for your organization. Not only is it effective - it's affordable too, costing just about a twelfth of what legacy approaches to training would set you back. So contact Cybrary for a demo. That's www.cybrary.it/teams, and tell them the CyberWire sent you.

Liviu Arsene: [00:01:20] A year ago we uncovered a very, very interesting and advanced piece of malware targeting specific individuals in a very interesting way.

Dave Bittner: [00:01:28] That's Liviu Arsene. He's a senior e-threat analyst for Bitdefender. He and his team uncovered a new advanced persistent threat that they call "Pacifier."

Liviu Arsene: [00:01:37] At that point we only uncovered part of the attack, or part of the malware, as it were. Now, we followed up on that investigation and in this report we actually have three new components, or actually modules, that are actually dropped by the same by the same APT. We call it Pacifier APT.

Dave Bittner: [00:01:56] So let's start with some attribution. You all are saying that this is coming from the Turla group. Tell us about them.When

Liviu Arsene: [00:02:04] When we started the investigation about a year ago, we didn't know actually who might have been behind the attack. But as we came up with the investigation and we published a report, other security researchers in the industry started to do their own investigations, and found that the same module that we analyzed was actually used in another series of campaigns attributed to the Turla group.

Liviu Arsene: [00:02:23] So the Turla group is actually believed to have - to be backed up by the Russian government, working for the Russian government. So that's how the whole idea got fed into this grinder, if you will. That the entire APT Pacifier campaign is backed up by the Turla group.

Dave Bittner: [00:02:39] So give us an overview. What's involved with the APT Pacifier?

Liviu Arsene: [00:02:44] What we know is that it's a very complex, very well-written, very complex, and modular piece of malware designed to exfiltrate data for a very long time and remain persistent without triggering any suspicion from traditional security mechanisms. For example, in this new paper that we published, we have three new modules that have three different ways of exfiltrating data, while remaining completely undetected in the process.

Liviu Arsene: [00:03:10] So one of these modules is actually a traditional binary file. And what's interesting about that is that it can broadcast information from a non-Internet-connected computer to the Internet, to the attacker. It does that by - it knows in advance how the internal network topography of the victim looks like, and it has a hard-coded IP address of the local Internet computer that has Internet access. So, once the non-Internet-connected computer victim is infected, data is exfiltrated through the Internet-connected computer over the local network, and then it reaches the attacker.

Dave Bittner: [00:03:47] Let's go through them one at a time. I mean, this first backdoor - it seems to be a way around air-gapped systems. Let's dig into some of the details here. First of all, how does it get the topography of that local network ahead of time?

Liviu Arsene: [00:04:03] That is a very interesting question. We didn't know that until we analyzed the third backdoor - the third module that I'm about to discuss right now. That third component is what we believe to be responsible for gathering intelligence from the victim. It's actually a component - pretty much a simple script. The basic script that executes a series of common Windows commands, and then runs through a series, or a list, of command-and-control addresses, and broadcasts the information it collects from those commands.

Liviu Arsene: [00:04:33] It's kind of like running a command line with the instructions on giving you system information about the current computer, and then broadcasts that information to the attacker. So the attacker would know what operating system you're using, what's the internal IP address of your LAN network, of your local network, what's your DHS server, and stuff like that. So it's basically just system information and that's practically used for data reconnaissance.

Dave Bittner: [00:05:00] So, let's go through each of these components one by one. The first section you label "No Internet? There's a Backdoor for That." And this is the one that can compromise air-gapped systems. Share with us some of the details on that one.

Liviu Arsene: [00:05:14] Well, the module was designed to specifically spread using USB devices. So, once it detected a USB flash drive, it created a hidden folder, if you will, and then it piggybacked its way onto one computer to another until it reached its victim. Once it did that, it was programmed to exfiltrate specific pieces of information, and because it had prior knowledge - it had been priorly coded with the internal network's topography - it knew exactly which computer from within the local network to contact in order to get that information from the non-Internet connected computer to the attackers over the Internet.

Dave Bittner: [00:05:50] And what was the initial vector for infection?

Liviu Arsene: [00:05:52] Well, we believe that they were all dropped by the same dropper that we analyzed about a year ago. That's also known as Skipper, as some other security researchers have named it. So all of these modules can actually be downloaded either all at the same time or separately, depending on what the threat actor's intent is. So if they want just to download the reconnaissance component after the original spear-phishing email has been sent, they can just do that. If they want to download additional tools, they can do that as well.

Liviu Arsene: [00:06:23] For example, besides these three modules that we analyzed, there are also some open-source, free tools that have been downloaded by attackers on the victim's computer specifically to perform reconnaissance actions, or forensic actions, like dumping a process's memory or performing man-in-the-middle attacks on browsers. You know, they were able to intercept encrypted and non-encrypted browser network traffic communication. And again, these are all open-source tools that were probably downloaded after the original infection point.

Dave Bittner: [00:06:57] And this system uses a fairly sophisticated communications systems between the target computer - the air-gapped computer - and the computer on the LAN that's connected to the Internet?

Liviu Arsene: [00:07:07] Well, it's not necessarily very sophisticated communications system between these two computers, but the fact that it had prior knowledge of what that Internet computer was. That's the interesting part...

Dave Bittner: [00:07:18] I see.

Liviu Arsene: [00:07:18] ...Because that demonstrates the attackers actually knew precisely how the internal network of the victim looks like and how to exploit it at its finest.

Dave Bittner: [00:07:28] The second part is the transport module.

Liviu Arsene: [00:07:32] This - the transport module is just a subsection of this data exfiltration - of this first Trojan that we analyzed.

Dave Bittner: [00:07:38] I see.

Liviu Arsene: [00:07:39] So, with - doing technical analysis, we broke down each Trojan into separate modules and how they operate.

Dave Bittner: [00:07:46] I see.

Liviu Arsene: [00:07:46] The three main Trojans are basically this one, that connects non-Internet-connected computers to the Internet. There's the second one that is a Visual Basic script. And there's the third one that was used for reconnaissance, for collecting information about this.

Dave Bittner: [00:08:00] I see. So let's move on to the second one using the browser cache to evade security. This is a fairly novel system here.

Liviu Arsene: [00:08:08] This is actually something very interesting and I personally haven't seen it in the wild up till now. If I'm mistaken, probably I'll get a lot of hurt from that from other security researchers, but I personally haven't seen it used ever before. Why? Well, the reason for that is simple. Using the browsers cache mechanism is a legitimate action. It's the way browsers are supposed to work. Whenever you connect to a browser - to a home page, for example - you download components from that web page, especially if you are connecting to it for the first time. If you are connecting to it for a second time, or a third time, the browser automatically knows that you have previously visited that web page and you don't have to download all the components because it already has a couple of images or Cascade Style Sheets already saved in a temporary folder. So that's the way the browser caching mechanism works.

Liviu Arsene: [00:09:01] What attackers did in this case, is they developed a Visual Basic script, which is pretty much - it's a script. It's not a binary, it's usually not scanned by traditional security solutions, so it can pass by undetected. A script is basically a series of commands that are executed. So they devised a Visual Basic script that changes the home page address of Internet Explorer. It changes that address to a legitimate website.

Liviu Arsene: [00:09:29] So each time a user would open Internet Explorer - again, that would mean that the attackers had prior knowledge that their victim would often use Internet explorer. So when the user opens Internet Explorer he will be redirected automatically to that legitimate website. However, that legitimate website would contain a JavaScript. It's not uncommon for websites to use JavaScript. They do all sorts of interesting stuff, magic stuff. It's really cool.

Liviu Arsene: [00:09:56] However, this JavaScript was not meant to be there. So, this JavaScript was actually added by the attackers on a legitimate website. How they did that is probably by exploiting a vulnerability in the website, and they simply placed it there so that whenever a victim connects to the website, they can relay commands through that JavaScript to the browser - to the victim's browser - ultimately saving those commands in the cache, in the browsers cache. So those commands are actually translated from the website's JavaScript to the browser's local cache, where they get stored.

Liviu Arsene: [00:10:32] Fine and dandy up until now. There's practically no hint of a warning. There's practically no malicious behavior whatsoever whatsoever up until this point. It's practically normal behavior.

Liviu Arsene: [00:10:43] Okay, the interesting thing happens when the same Visual Basic script that altered the home page of Internet Explorer starts at random intervals to check the browser's memory cache for files containing specific instructions for a specific task at random intervals - it doesn't matter. Whenever it finds a file containing commands, it starts executing them, and the output gets saved in the same local cache - in the same browser's local cache.

Liviu Arsene: [00:11:12] Now, this is where I'm going to pause for a second, because the real kicker is, attackers usually want access to information as fast as possible. They want to get in and out in a matter of seconds, hours, days, it doesn't matter. But they want continuous access to that information. Now the kicker is, that once those malicious commands were executed and the data or the output was saved in the browser's cache, it can get broadcasted immediately.

Liviu Arsene: [00:11:36] Actually, it was the user inadvertently broadcasting the information to the attacker. Why? Well, because activating or opening Internet Explorer, again, it would make the victim connect to the same website hosting the malicious JavaScript. So that, in turn, would force the browser's cache - so, the local cache - to be broadcasted to the website, to the malicious website, and in turn relay that information to the attackers.

Liviu Arsene: [00:12:01] So it's kind of like using the user's own habits against him without leaving any footprint. So you can - the attackers would not - would never have gained access to the user's information unless the user would have opened, again, Internet Explorer. Which is pretty interesting, because that's the novelty of it all - using the browser's cache and actually relying on the user's behavior to gain information from him without compromising your persistence on the system.

Liviu Arsene: [00:12:29] Because usually, when a piece of malware wants to exfiltrate information, it starts making up all the connections with the command-and-control server. It starts its own processes, it starts speaking to random IP addresses. Usually, you can spot these kind of activities. But when you're using the browser, specifically local cache, and you're using a legitimate website to do so, it means that there's going to be no suspicion whatsoever.

Dave Bittner: [00:12:54] So, is there anything you can do within, say, Internet Explorer to disable the execution of a Visual Basic script?

Liviu Arsene: [00:13:03] Well, the execution of the Visual Basic script can only be prevented if you delete the registry key. So, if you delete that registry key, practically you stop the entire process.

Dave Bittner: [00:13:13] But that's not something someone would know to do...

Liviu Arsene: [00:13:16] (Laughs)

Dave Bittner: [00:13:16] ...And this is all happening behind the scenes and there's, again, there's no indication that anything is out of the ordinary.

Liviu Arsene: [00:13:22] Absolutely. The average user would not know anything is wrong. Plus, traditional security solutions are not designed to scan for registry keys. I mean, they do check for malware that tries to run at startup by creating a registry key, but they don't usually scan the contents of that registry key, or they don't scan the contents of a Visual Basic script. Just like I mentioned earlier, a Visual Basic script is just a series of commands. It's like typing in command line "ping google.com." It's that simple.

Dave Bittner: [00:13:51] So, what kind of information are they looking to get from the victims?

Liviu Arsene: [00:13:56] Well, it's difficult to tell, because there's no way of actually knowing what they actually managed to get a hold of, or what they were interested in finding out. By deploying these tools, these modules, they were able to gain access to content from browsers, from Microsoft Outlook, or other usually business-related applications.

Dave Bittner: [00:14:16] And is there - in the communications between the system and the command-and-control server - is that communication encrypted?

Liviu Arsene: [00:14:25] Well, the funny part is, in some modules, yes. And in others -for example, the third module, the one that is responsible for gaining information about the victim's computer, the one that is simple enough - the communication seems to be unencrypted. It uses plain HTTP. No encryption whatsoever. Because apparently the attackers weren't concerned - I'm assuming - that they weren't concerned that system information would be something that important to be encrypted. Even if you were able to scan HTTP, you will only find system information, and that's it. There would be no actual classified information or sensitive information that you would consider to be of importance.

Dave Bittner: [00:15:05] So, let's go through that third component. This is "Victim Profiling with a JavaScript Backdoor." Take us through how this part works.

Liviu Arsene: [00:15:12] The JavaScript backdoor was a pretty obfuscated script, but it had a very, very simple purpose. Its purpose was to execute a series of commands designed to gain or collect as much information as possible about the victim's computer and the network it's connected to - it's attached to. For example, it would gain information about what type of operating system the victim has, what Internet Explorer version they run, what type of subnet IP address they have, and so on.

Liviu Arsene: [00:15:42] So all of this information was practically broadcasted to a list of command-and-control servers that the script would just parse through. And all of that information would be sent unencrypted in plain text, and that's it. At some point, it would repeat the process to see whether or not any of that information has changed, but that would only happen at random intervals. There was no timer set to it. There was no timer in terms of every day, every hour, every thirty minutes. It was a random interval that script would activate and send that information.

Dave Bittner: [00:16:14] So, I think one of the things, as you mentioned earlier, that's interesting is that these folks seem to have an unusual amount of patience.

Liviu Arsene: [00:16:21] Exactly. Not just an unusual amount of patience, but they're also very focused. They know exactly how the victim behaves, they know exactly what tools they use, and they are very skilled at implementing new techniques. For example, these three modules have different functions, they have different behavior, they have been coded differently, they look completely different, and they use three separate communication channels - three separate communication methods, if you will. They seem to be highly versed and highly skilled at what they're doing.

Dave Bittner: [00:16:55] And how did these initially come to your attention?

Liviu Arsene: [00:16:58] Well, the investigation started about a year ago when we uncovered the original - the first components that we dubbed Pacifier. That was spread through a series of phishing emails designed to exploit a vulnerability in Microsoft Office. And then we caught our attention when the vulnerability downloaded a dropper - a malicious payload. And when we analyzed that dropper, we figured that at some point some additional modules might be downloaded because that dropper had the capability of doing so. Naturally, we came out and published that paper, and we continued our investigation and found these new components.

Dave Bittner: [00:17:33] What's your sense for how widespread this is? Is this only hitting - is this a highly-targeted attack, or is this something that, you know, regular folks need to be concerned about?

Liviu Arsene: [00:17:44] Judging by the way these modules operate, it seems to be a highly-targeted and very specific attack. Just like I mentioned earlier, the fact that one of the modules knew exactly which computer to connect within the local - to connect to within the local network to broadcast information, or the fact that they knew that the user ultimately use Internet Explorer, or the fact that they knew that user would probably open Internet Explorer at least a couple of times a day. So they would have to be patient and not necessarily force a connection to the command-and-control server.

Dave Bittner: [00:18:18] As a result of learning what you have about these attacks, what sort of advice do you have for people in terms of protecting themselves against this sort of thing?

Liviu Arsene: [00:18:27] Well, it's difficult to give you a specific advice on how to protect yourself. There are a general set of rules, best practices, that you can do that you can do, that you can adhere to. For example, you can try not to open email attachments from a untrusted sources, or not double click any URLs that you receive in emails. For example, if you receive an email - if you work in a front desk, and you receive an email saying "check out the attached invoice," you naturally get the impulse, the urge, to double click the attachment. But take a while, take a second or two to look at the email address that sent you the attachment. Try to figure out whether or not that might be, or might not be, a phishing email.

Liviu Arsene: [00:19:07] Secondly, try to at least have a security solution installed. Some security solutions are great at preventing or blocking attacks. Some steps during the attack change, so that at least will prevent the attacker from going further with the attack, or block the attacker completely as soon as he tries to gain access to your computer.

Liviu Arsene: [00:19:27] And of course, the best advice I can give you is, never trust everything that you read.

Dave Bittner: [00:19:34] (Laughs) Never trust everything you read. Go on...

Liviu Arsene: [00:19:39] Never trust everything that you read in terms of emails that you get that sound too interesting, too preposterous, too alluring. Never click on URLs that you have never visited before. Never buy stuff from websites that you have never heard about. So, caution is always the best advice in terms of security.

Dave Bittner: [00:20:01] But in terms of, you know, automated scanning systems, you know, virus protection sort of thing. I mean, this system would have flown under the radar of all those sort of systems, yes?

Liviu Arsene: [00:20:14] Well, it is possible. I mean, just like I mentioned earlier, a security solution has multiple layers of security defenses. So, it stands to reason that one of those layers would have prevented the attack during at least one of these phases.

Liviu Arsene: [00:20:28] For example, it might not have prevented the original dropper from being executed, but it might have prevented one additional module from being downloaded from the Internet. So whenever the attacker would have tried to download an additional component, probably the antivirus solution or the security solution would have stepped in and said, hey, this - you're not supposed to download this file, this is a binary file, we don't trust it, block it. And then some suspicions might have been raised.

Dave Bittner: [00:20:56] Our thanks to Liviu Arsene from Bitdefender for joining us. You can find the complete report on the Pacifier APT on Bitdefender's website.

Dave Bittner: [00:21:05] And thanks again to our sponsor, Cybrary, for making this edition of Research Saturday possible. Visit www.cybrary.it/teams and see what they can do for your organization.

Dave Bittner: [00:21:17] Don't forget to check out our CyberWire Daily News Brief and podcast, along with interviews, our glossary, and more on our website, thecyberwire.com.

Dave Bittner: [00:21:25] The CyberWire Research Saturday is produced by Pratt Street Media. Our 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.