 All right, how's everyone doing? My name is Steven Adair, and I am here as a security researcher from the Shadow Server Foundation also for the day job. I do cyber threat work for a large federal agency. I'm supposed to be co-presenting with Matt Richard, who's obviously not up here. I encourage you, if you were going to throw anything or heckle, to save it till it's 2 o'clock talk. And even if you weren't going to, I'd really encourage you to harass him or do whatever, for him not being here. Other than that, our presentation today is on the whole, a big Adobe vulnerability that was back in, well, technically January, February timeframe, and our presentation is entitled Zero Day Ghost Net with a zero, the Adobe JVig 2 decode disclosure debunkle. And presentation is not as exciting as it sounds, but I find if you set low expectations, it's easier to exceed them. So a quick standard disclaimer, this applies to both Matt and myself. Anything we've seen here, anything dumb, anything smart, it's not on behalf of our employers, doesn't represent them in any way, shape, or form. None of the information in here, since we talked about some targeted attack stuff, stuff related to cyber espionage, this has not come from our places of work, this has not come from other people's places of work. We're not taking any kind of data we shouldn't have in presenting it here. We have it from other sources, legitimate sources. And we have permission from the sources to present on these topics, share, and do everything we're doing today. So we didn't hack anything, do anything illegal, we didn't steal anything, we're okay with this. So the agenda, a quick item, we're going to do a quick background. I know there's a certain number of people here, probably have no idea what the hell I'm talking about right now. So we'll give a quick background into all the Adobe stuff, what we're actually talking about. The inside story being how this really came to light from our end. I don't know the inner workings of what happened at Adobe or how a source fire did all that stuff, or any of that good stuff. We'll tie that right into a timeline, largely related. Do a little bit of the analysis of some of the malicious PDF, why it's relevant, the evolution of them. This is really Matt's slide, so I'm going to talk to them. It sounds like I'm making stuff up, it's because I am just making up stuff. Then we'll go into disclosure, the classic partial, full, no disclosure. We're not trying to reinvent the wheel or do any kind of crazy new debate or new take on it, but this whole incident ended up being a really good example of a good case study. If you want to look at the different types of disclosure options and how it went through all of them, it really comes to a conclusion whether it's good or bad, what's the right one, but we definitely had some interesting results. Finally, before we conclude, we'll take a look at what we're calling GhostNet in our presentation with a zero. GhostNet being the report that was put out by the Information Warfare Monitor in March of this year, and it ties back into cyber espionage. Here's a quick background for some of you who don't know what's going on. I'm not going to go into too long of the details, I'm going to try and speed through these slides since I tend to talk a lot. We're talking about the Adobe Vulnerability and Adobe Acrobat and Acrobat Reader. This is what is known as Adobe's Apple Product Security Advisory, their first one of this year. There's a CV number if you wanted, there's tons of other reference numbers, that's what we're talking about. I'm an expert on JBig2 and that stuff, but it's basically JBig2 is an image compression format that's used in code images so a lot of times you get a PDF with a fax or something's been scanned, like a black and white image a lot of time. It really decreases the size. And then JBig2 to code. And here in Adobe is the reason we're here today, it's the vulnerable function that resulted in this pretty bad exploit that led to this presentation. So the inside story, so how did it all start? Basically it kind of started with rumors. There was some stuff going on, some people mentioning a few things, some talk on some lists, there was some discussions about a new vulnerability. No one had any details. It was just a talk of Adobe vulnerability that's affecting multiple versions, that's a zero day, but really, really, really lacking any kind of details on what's actually exploited. Someone pointed to a semantic page at some point that we found had a write-up that was really vague. The write-up had a mention of this JS001.3322.org. That's a host name on a Chinese CN99 dynamic DNS provider frequently used in malware authors. And that's really all it had. It referenced the PDF, it didn't say it was a zero day, it didn't say it was, and it was very vague. So I was talking with Matt and realized I'd already had a sample of this. And actually, because I get a lot of samples from different sources, looking at targeted attacks, this is like your PDF files, Excel spreadsheets, PowerPoint, Office docs, all kinds of stuff, Windows help files, .chm. I realized I'd actually already analyzed a sample on February 12th, the day of that advisory. So this is around February 13th, 14th that this is like coming to light. So I looked in my DNS monitors, I take all these targeted attacks and throw them in the DNS monitors so we can actually watch where the IPs bounce around so they will change where they're hosted at. This one is already in there, and I could quickly go back through my repository and see, oh yeah, here it is, I found it, grabbed a copy of it. And then I say I'm not technical, but I'm not the reverse engineering type. I don't know the breakdowns of like JBigTutu code. I don't do a lot of reverse engineering. That's Matt's area. We're working on that. Send it over to him. Didn't take him too long to figure out it was a JBigTutu code vulnerability. This is details that were not out there anywhere. We just got it. We just found it. We found it. I mean, someone else obviously found it. We didn't invent it, but we found out what it was. So now we had some information other people didn't, and we started looking through our other samples, started working backwards. We started going through even new ones that were coming in, seeing what other ones referenced JBigTutu code that are also involved with exploits. I mean, JBigTutu code is a legitimate function. But if you open the PDF, it exploits and puts a trojan on your computer. That's probably not what it's supposed to do in a good way. So once again, at this point in time, there is no advisory. There's no mention. There's nothing public from Adobe. We pinged them and kind of said, hey, are you aware of this? I said, what are you talking about? I said, hey, this. And they said, yeah, we were working on that. And that's around the 14th, I believe, 14th or 15th. So we found some more samples. We started working back. Ultimately, we'd come, you'll see in the timeline, which needs to be updated when we found some of the earliest samples. But we found more and more people are looking for, more and more rumors. People didn't know what to look for. It really blended in. There weren't a lot of them out there. This was not a widespread exploit. This was being used very targeted attacks. And even then, the targeted attacks are extremely limited. So people didn't know what to look for. So they just opened up all these Adobe files and it would look just like any other one. So we then became aware of more attacks. So from our sources, we knew that other people were being hit with this. We knew this was, we already knew it was in the wild, but we knew that people were actually being hammered with this exploit. So got a little antsy about that. We're not a big fan of different institutions being hammered with Zero Day. Especially when no one has any information out there to protect themselves. So this is where we opted on the Shattered Server blog to do something we call the partial disclosure. We basically let people know there's a vulnerability. One, we didn't mention the function. We didn't know any information on how they could recreate the exploit. But we gave them a solution. We said, disable JavaScript. Now you can read tons and tons of people will say, oh yes, yes, we already knew this. I can't remember if we addressed this in the post or not. You could circumvent JavaScript. And I think someone, I don't know if it was immunity or in the Canvas frame, someone actually created something that can do it. But to date, we have never seen an actual targeted exploit that has actually been able to, that actually used a method that circumvented JavaScript. So this solution would work 100% for you, the one that we provided. To this date, we're not... I'm sorry? Well, yeah, that's another issue, I guess. Well, there's lots of Adobe fun out there. But yeah. Another solution that was really good is having, if you had DEP on, having that enabled would pretty much stop the exploit as well. Having that on, it would crash and everything, but it would actually would not exploit the system. Possible also to probably write something that could circumvent that. We still have yet to see anything like that in the wild. So this results in Adobe publishing an advisory, which is definitely a good thing. It's kind of what we wanted. But like I said, they can't put a lot of the details out there, but they didn't put a workaround. And the key component is that it would be patched in about a month. So that's a long time to wait for something that's already been out for a while. So here's the timeline. We mentioned earlier the JS001.3322.org. That's on January 6th. We looked through that same host name, which we hadn't seen before in any of our other attacks on our other files we've analyzed. And found a thread expert. They had a sample from January 6th. And then I think another one on January 12th. We don't know that that's related. But I suspect that it could be. There's a couple of people who said even going back to December, this exploit existed. We haven't found any evidence of that. The first hash from all the files we had, we didn't know the date, but we punched them in the virus total. That date actually needs to be corrected. Matt's not here. I blame him again. January 16th is the first J-Big2 to code vulnerable file attacking file that we found. So we know as of pretty much about a month before, we posted the advisory that were active live exploits that were working in the wild. February 12th, we talked about the semantic post at an advisory. Didn't have a lot of details. We suspect they may have been under an NDA. 19th was our advisory. Same day, Adobe advisory. Then SourceFire put out a blog, which basically detailed what the actual function was. They then got a copy of it. I think they had it in their repository. Yeah. Okay. I did not use J-Big in my post. You're thinking of the McAfee advert log, but the Shattiser did not have J-Big2 in it anywhere. Well, it's incorrect, but thanks. Anyway. The exploit, you can pull it up right now. Feel free to pull up the post. It's right there. Feel free to pull it up and show me where it says anything about J-Big. It doesn't. Anyway. So we got the Millworm proof of concept came out. Someone else put up the proof of concept. Got picked up on Millworm on the 23rd. The SourceFire, they put out a homebrew patch. That was actually something that really helped. They took the DLL file from, I don't know exactly what they changed in it, but they were able to make it so if the exploit would load in Adobe, it actually would not exploit the system. So Adobe, excuse me, SourceFire put out that and shortly after they also put out some clam AV signatures and sort signatures that would help as well. Then also March 5th, we started to see a large increase in J-Big2 exploits. This is a number of different modified ones. We'll touch on that in a little bit. And then finally, Adobe patched shortly after. It actually came in piecemeal. It was one after another for different versions. It took them a little bit of time to patch the different eight, nine and so on and then different OS flavors were patched later on. So this is starting on matte slides. I'm going to go on to basically, give me some notes on his. So some of the key items you probably wanted to add, I'm not going to touch on, but I'll do this best I can. So kind of some of the key components in analyzing the malicious PDFs, especially if you want to start doing like attacker attribution and comparing. A lot of the metadata is pretty useful. There's some interesting information in it. You've got the encoded JavaScript or other attack code. And then you've got a lot of the other object tags that are in there. So you start to notice things that aren't in other files. So all the exploit files may have J-Big2 to code in it, for example. You might have the other JavaScript tags, which media or flash things in there. And you can look for other unusual parts in the PDF, for example. If you see an embedded executable, either in ClearXSword or otherwise, that's probably a clear indicator. This is probably a bad PDF. You start to match when you start comparing them to other PDFs. So what Matt has on here, he said PDFs are probably derived from any attributes. He calls it like the, in his terms, the DNA. There's some parts that you start to see in PDF files that you're not going to see in a lot of others. And if they start matching and you have a lot of matches, they're probably derived from the same initial exploit pack or exploit developer. There are things that you just don't see in the wild or normal PDFs a lot of the time. And then a lot of these also, if you start modifying a PDF like in Adobe, you can keep the original content and start adding onto it. So the old stuff's there. And one of the cute items they always have are these timestamps. Now timestamps can always be bogus, but we touch on this because you start to see this, we see this in a lot of targeted attacks that have to do with Adobe, but especially here too. You start seeing GMT plus 0800, which is Chinese time zone. So that's a pretty interesting item that you start to see when you start wanting to correlate where this stuff's coming from. So early PDFs, in his slides, had one or two payloads. You see on there the metadata at the top. It's pretty unique. All these Xs, XXXE for the email, and then you have Xs and Ds. This is not something that you see very normal, very normally, and then you wouldn't get this on accident. So you start to be able to compare the exploits and the different files out there, and you see a lot of matches. They also use the octal encoding for the JavaScript, which was very large. That's where you have the backslash and then the three numbers. That was a big point that made these files around a little over 800 kilobytes. They're pretty large files. They had, like I said, a lot of unique metadata, and then they had a couple Xs or keys that were the same throughout all the different exploits. And the initial sample that we found, that we initially knew of, was the JS001.3322.org. And this is an example right from it. So from the semantic advisory, this is what we found. We've got the original JS001 from. Didn't have a lot of details. But it did have on here, down on the bottom, you can see the command and control server that it uses. That's how we originally found it. Comparing the virus tool of data before the 12, there were any virus vendors that would pick up these malicious files, but it was not because of the specific detection for this exploit. It was picking up on other things like odd JavaScript or shell code or other weird things during the variation. So starting about February 12, we believe it may have been because of under NDA, MacAfee and Symantec, I believe, started detecting this. And soon after, the disclosure and additional details from SourceFire, others were able to start picking it up and adding better AV detection. And at that point, the files got shared around a bit more. So the first known malware, like we said, was a Ghost Remote Access Trojan. It became the JS001.3322.org on Port 220. So the Ghost Remote Access Trojan is a pretty powerful Trojan that's got a lot of attackers. It's out there and it's open. It's available. You can download this yourself and set it up, but it's very frequently used by Chinese malware authors and attackers. And what they do, it allows them to get on the system. They can run a lot of functions. They can set on the computer as if they are sitting at it. They have full control over the system. It's pretty powerful. And like I said, Symantec mentioned it on the 12th, and then we can see going back to the 6th of January that this very sample, the very same Trojan, existed. Not sure exactly when it first started using the PDF, but we know as of the 12th it did. So the earliest sample we had goes back to January 16th. This is the earliest one we could find. A few people said maybe a week or two before this. They had samples, but we haven't seen any. This is the best we can do. It's pretty much identical to the JS001 sample we were talking about. Got the same author, the same email, the same web. The encoding is the same, the same XOR keys. So it's obviously derived from the same kit, except for here it is nearly a month earlier. So this thing has been around for a while. It's changed hand a few times. And we found some other samples from different attackers that are using it in this particular one. So this is what I'm talking about, the AV detection. This is that sample from virus total on the 16th. It had 5 out of 39 could detect it. What they weren't looking for was things like, it wasn't specifically detecting this exploit. It was flagging on other things. So you were still somewhat protected, but you didn't have very good protection out there, and you weren't specifically protected from this vulnerability. And you can see the file size. It's nearly 830 kilobytes, which we'll see in a minute gets dramatically reduced. So this earliest sample, once again, just to talk about the malware behind it. So the first known attacker that we have with this that we know of, their malware dropped the Poison Ivy Remote Access Trojan. Very similar to Ghost, it's pretty powerful. Has a lot of root kit functionalities. A lot of different things you can do with it. It's also favored quite heavily by Chinese malware authors, but it is, once again, open and available on the web. Anyone can download it. You can go out there and do it yourself. In this sample, it connected to a host name called yo-yo.networksec.net on port 443. In this sample, we talked about how some are a little more advanced than others. This one, when it crashed, it did not open up or provide any kind of replacement PDF. So if someone opened it, they would see a crash and they wouldn't get anything new. Not as advanced. Probably just a bad choice on the attackers part because some of the other samples did do this. But this is also an attacker we've known previously as of December using Office Zero Day. We believe it's some few different exploits. We also had the WordPad text converter exploit. So this is not the first time these guys have popped up with some form of a Zero Day. So they're probably not just some random person testing or playing around. We don't have any information in the back end of their server, but it starts to lend an eye to cyber espionage-related activity. So February samples. This is where the code starts getting a little better. From February 7th and 10th, we start getting some new samples that we looked and see how they start to change. This is a few days before the February 12th sample we had that was identical to the one in January 16th. So once again, working off matte slides here, you start seeing some of the differences. PDF header changes. It has a similar heap spray, the same comments in it. So if you looked at the code, the actual comments in there were the same. They were just reusing it, but now the big difference, they were able to dramatically shrink the file because they just used flake decode. So now instead of having all that gigantic octal encoding in there and the clear, it now is all encoded. So it took up a lot less space. So it went from 830 kb to about 108 kb. So the question is, are these new attackers or just people that took the exploit and are trying to refine it? We never saw any overlap from our initial attackers, the command and control servers to the new ones. So we don't know, there could be new people with new command and control servers, new Trojans or just someone who got a copy of it and started messing around with it to improve it. And then some of the PDFs had multiple versions showing what changed in each revision. You can see some of the differences. And once again, if you take a look at the bottom there, you see the attackers when they started modifying it now have a mod date that involves plus 0800. So once again, obviously it could be anyone could say that to anything, but that's where we are once again. So code got a little better. ABtection did too. This time they flagged shell code signatures for a few of them. The other ones pretty much remained the same for the JavaScript. Files a lot smaller. You can take that for what it's worth. So now we can see the attackers are evolving. So we had the initial encode was improved. We saw the size shrink a lot, and then we saw better attacks. It's pretty standard operation for an attacker with a targeted office or PDF or doc file exploit to have a replacement document open. The initial couple we saw didn't do that. They got a little better. Probably someone who's a little bit smarter had this happen. And still some attackers don't have the exploit. So those that didn't have it were still looking for it. So this is the point at which the Millworm exploit becomes weaponized. So the Millworm proof of concept, the proof of concept itself came out on the 22nd, posted Millworm on the 23rd. You can see this is actually run through all this. The formatting you see here is a tool that Matt Richard wrote, calls a PDF parse. He said it'll make it available. He's not here to speak to that, but I don't know where to tell you to go to get a copy of it. But he said it'll make it available if anyone wants it. So feel free to email him at the end of this. So he scans it, looks for some key objects and the red is kind of what changed between them. So if you approve a concept on the left and then on your right you have the PDF in the wild. This PDF in the wild, we don't detail the attack on it. It's one we're actually very well familiar with. It's an attacker group that's been around for a couple of years, heavily into cyber espionage activity. They actually took the code off of Millworm and they edited it, modified it, and made it work for them. And once again the mod date of 0800 appears in there. They edited it with Adobe. They did some stuff on it with GhostScript. So the attacker actually took it, and that proved a concept and weaponized it. And I know there's lots of other people who were playing around with it, but this is the one that was actually used in real live attacks. So at this point it brings us to the whole disclosure. So this is a regular old debate. It's a long running debate. No clear answer. There's pros and cons of pretty much all the ones that we saw. So we didn't want to disclose. Here's a quote that Matt liked that he put in here. He thinks he kind of liked it too. This is from H.D. Moore. He was actually talking on the Adobe issue from the 23rd. He said, the strongest case for information disclosure is when the benefit of releasing the information outweighs the possible risk. In this case, like many others, the bad guys already won. Exploits are already being used in the wild and the fact that the rest of the world is just now taking notice doesn't mean that these are new vulnerabilities. And he says, at this point the best strategy is to raise awareness, distribute and to patch, especially with the last line that we agree wholeheartedly. I think everyone involved in the disclosure process here was pretty much on the same page with that. So no disclosure was a major fail. We're not here to beat up on anyone, so we're not beating up on Adobe. We've seen a lot of things just from the casual observer improvement that we like. For whatever it's worth, our opinion. So obviously Adobe, they didn't disclose it right away. What did it make a big difference? I don't know, and maybe they kind of worked with more antivirus owners. I don't know the case, but obviously no disclosure didn't help here. And he said the AV vendors, we think some of them may have been under NDA so they couldn't put a whole lot out there. Are there others who could have noticed it or found it or done something? That's a question. So basically in this case from no disclosure, the only ones who were benefiting were the attackers. They were running rampant for at least over a month before anyone even started to do anything about it. And they had another month from there before there was any kind of patch from Adobe. So like I said, we were in favor of partial disclosure and we only give it a partial win. So they had issued an advisory, that's great. What did we get out of that? So Adobe said there's an issue out there, so I guess people know we're not lying. That's the only real plus of it. Potential workarounds, we like that because we had potential workarounds. They could be circumvented, but they were valid, they worked, they prevented stuff from people who were being exploited. So we had a form of fighting chance and we're just complete sitting ducks at this point. And then also it led to the full disclosure which is kind of like a gray area depending on who you talk to. So full disclosure, we said it succeeds. So there's some things we liked about it and there's others we didn't. So Where's Fire pulses the volume details basically a day later and it's not complete and I think they actually, I think McAfee actually let some of the cat out of the bag from one of the presentations that's all in a form of a hex editor, so you could have actually taken that and figured out some of it. So it was kind of out there. Someone would have gotten out there one way or another anyway, but they were able to release an unofficial patch a day later. So we consider that actually a pretty good win. I had no idea how many people actually were able to apply that, but at least like I said there's another solution out there. But then the Millworm exploit came out pretty much the same day and that pretty led to some new detection. Many virus detection started improving at this point. More information is out there. There's more people know what to look for, but this also leads to the quicker weaponized exploit development. So like I said, disclosure kind of leads to new attacks. This is going to happen regardless, but it happened a little quicker we think in some cases. So like I said, the proof of concept code the 22nd, Millworm shortly after. One of the codes references the Sourcefire blog. That would detect some of the attacks, which would later get changed and they wouldn't be as effective, but that's pretty much the cat and mouse game of antivirus detection. So it takes a little over a week from this point where we start seeing derivative attacks that are modified more and more. So start changing little pieces, start doing different things to avoid detection. And then by March 5th, we basically I said all hell is broken loose and there's massive uptick in attacks basically. I think a lot of people knew the impending patch of firing them out there. We saw a massive increase in the number of exploits coming in. So signature power. So this is some of the signatures. I believe Matt posted these on here. I think they're the ones Sourcefire put out for the ClamAV and I believe this may be their sort signature. So what it does is they look for the a lot of the time they look for the J-BigDudeGode, the stream followed by the carriage return and the line feed. But the PDF spec actually allows just a carriage return without a line feed, a small issue for things that started evading detection. As you can see in the red, that's the carriage return line feed. Same thing with the snort signature. So we started seeing evasion signatures. This is always the case with antivirus though and other things. A lot of them are unless they're fully heuristics based they pretty much match exact known attacks the best they can, which in this case would probably for a while get the bulk of them. They can quickly change it. Like I said, they can use just the carriage return. They can exploit. That would cause it. That would no longer be detected. And then some other things replace the letters with ordinal values or they start finding creative ways or trying to change the case for some things and not detect that. So basically, right now our patch is our main solution. This is a picture of the DOMO-KIN. Every time you open most PDF, God kills the kitten. I'm probably going to hell now. So, final tie-in. This is where we start talking about, GhostNet. GhostNet, the report that was put out by the Information Warfare Monitor. So, is there any connection between the malware and the GhostNet report? So that's a good question. Is it cyber espionage or just one in games? Is this random malware? Is it something like, it's really not a big deal. So, March 29th, 2009 this is when GhostNet report came out from the Information Warfare Monitor. When they put out this report, I think maybe one or two of the guys here talked with them, I want them pretty extensively and another one a little bit. What they did is they looked into some of the targeted attacks using a lot of these same type of attack techniques using like different Adobe files using office documents and things that were targeting the Tibetan community and they had some pretty much unprecedented access to the office of the Holy Dalai Lama and what they found in the report, it was a pretty long report, they found a network of systems being controlled by these guys with different attackers. Some of the attacker sets on there, it's not real clear whether or not they're actually related it's probably more than one group attacking Tibetans in the office of the Dalai Lama but they had some pretty good information in there and some of the questions are being raised this report came out in March is what's the relation between what we're seeing now and the stuff that was put out by the GhostNet report? Is there a connection? The best answer is not exactly. I'll put out a question mark because there are some loose ties to it. So to keep in mind one thing is that the GhostNet research was from 2008 so this being a 2009 vulnerability the vast majority of what's in GhostNet report was from the previous year. This exploit is not known to exist in 2008 or excuse me, in the wild exploit is not known to exist in 2008. So our title GhostNet actually with a zero is kind of initially, so Matt wanted to gather his presentation and so I agreed to present with it and to kind of late he just took the GhostNet with a zero just off the bat based on the initial malware that we saw. So it was the ghost remote access erosion which was built with a zero it's kind of a play on GhostNet without it. So we weren't really expecting to find any close ties to it it's kind of a nice cyber espionage is related it's interesting so we just kind of put it in there but we found a loose connection after all so we see from the report there's three different there's several different commanding controls listed in there but there's three of them in particular that we're familiar with so a lot of the attacks from GhostNet we've seen have copies of it we're aware of but in particular three of the commanding controls listed in the GhostNet report mcafferyresponse.org, msnxy.net and lookbytheway.net These are ones that have a loose tie to what we saw in the early attacks in January. So this malware is often called TrojanInfo what it does is it steals different information from the systems it'll rip off files it'll take off credentials, it'll take off emails usually attackers specified they'll beacon in they'll beacon in with the commands that look like this they'll post different data they identify themselves with the computer name and the MAC address and then the attacker will respond back with what they want from the system and I think I actually owe if Martin Van Hornbeek's here because I had the Trojan name wrong so it's actually Info and not Rihler which they're easily mixed up so it steals various information this one's been around for quite a while I think the first mention of it on an antivirus page is sometime in 2004 on one of the, I see the storm center, the sands blog they mention this a while back for Tibetan attacks using this very same thing so this malware is not very common it sides directly back into the ghostnet report this is what the malware looks like they have this in their report so we went back and looked at our earliest samples we actually only had four that we could find that we could confirm were from January the first one we already talked about it beacon to yo-yo network sec everyone that went to mail.nti-mobile.com one that went to any mail that's so web mail.com and then we have the last one in the red search.touracealv.com so this is one where we actually found some of these similarities so these four different trojans are completely different trojans different command and control servers but one of them has a similarity to ghostnet so the first one that we had a similarity was, or the only one really was search.tourace.clv.com not only is this one that had a similarity it's a known command and control to us it's one that we've seen before we've seen it in other attacks it's the endfall trojan like I said this is a very uncommon trojan in terms of total number of IP address it's the only one we've probably seen at a given point in time active less than 10 this is pretty much seen in a lot of attacks originating and coming from China usually against the Tibetan group so we also started to see some other stuff like we said it shares IP address so this host, we have several other command and controls we know of that are on the same IP address it's search.touracealv.com and these are all hosts that we know on a couple of them have been involved with attacking any of the European Union so they've gone directly after EU and European hosts so this starts to be a decently interesting and strong cyber espionage time because this thing is being hosted on the same box we know has been attacking EU entities with different targeted attacks different exploits so like I said search here's from our DNS monitor search.touracealv is hosted at this very moment I've had a few different IP addresses over time at 60.10.4.94 Chinese IP address there's a few other hosts blueandnt.com ggsddup.com if you do a lot with targeted malware attacks these are probably ones you probably come across at some point in time this is that Trojan, very uncommon sharing IP addresses with these so just taking some of the file names sometimes we have file names sometimes we don't you can look at some of them having to do with Brussels exhibit imitation suite in public planning for the public procurement these are not like some of them are not run in the mill a lot of them if you opened them they would crash like I said they'd open a new file a lot of those new files had specifically to do with European conferences or things going on in different parts of Europe whether it was Sweden Belgium, other places Germany so these are very in line with one another from across the different domains that were attacking other EU entities so we saw only a thing a lot of them were like jbig2 decode exploits and one of them was an older powerpoint exploit we go back further I think we have some samples that attack like MSO6 different word doc vulnerabilities so some of these have been around for quite a while and they've been attacking quite a number of different things so we started to get to cyber espionage and jbig2 we know that even the earliest of jbig2 samples can be tied back to what we are sure cyber espionage so there's a number of them where there's even a few samples where we've been provided information on the back end we know who's been targeted we've seen the infected host so we know some of these have definitely been used to attack financial systems or foreign governments things like that and many other samples are related or other known attacks like the past screen we're going to talk about in a minute I'll go back to the JS001 another item we've seen from that different groups appear to be operating kind of with the same exploits we didn't really see a lot of overlap in the initial stuff was kind of surprising it seemed at least four or five different groups had the exploit for about a month and they didn't really fire it out a lot like we didn't see massive influx of it either out of people who weren't realizing what they had and it just wasn't getting reported and down through the chain so we're not sure how it stayed so it stayed relatively quiet yet it seemed to be in the hands of multiple different groups so another interesting item is all the initial command and control servers pointed back to Chinese IP addresses so this is coincidence that's possible so interesting enough that JS001 that 3322.org connection how does that tie back to cyber rescue now well it currently sits on a Chinese IP address like we said it's up there that host also has another domain called cyhk.3322.org on it they share the IP address no who cares why is that interesting well the reason that's kind of interesting is there's multiple reports out there one of them is put out by Symantec that in April 2008 there were email attacks against Japanese businesses they were purporting their B they were spoofed from the Japanese government and if they succeeded they beacon back to the cyhk3322.org host name which now also shares an IP address most likely run by the same attacker that runs JS001 our guys that had the one of the earlier people to get the jbig2 to code exploit so this is the look at it took a sampling of about 82 different host names that were involved in jbig2 host names that came as a result of jbig2 pdf files that exploited and took the IP addresses that they bounced around to over the period of time so sometimes some people will change every couple of days some of them since February have been on the same IP address till today as you got a mixed bag but if you take a look at the samples you see that excuse me China 202 of the 301 different IP addresses were there so about 67% you go Korea, Hong Kong US, Taiwan and Japan and it just kind of works down with the intermingling between different countries I mean bad guys or anyone who does this they can hack a server anywhere they can take a credit card or they can buy a server anywhere so it doesn't definitively prove anything once again but we can start to come to some conclusions so obviously our first conclusion is that China is behind all attacks involving zero day exploits and cyber espionage okay you might hear that in the news or something okay that's obviously just a joke so if you're going to quote me on that please add the just kidding at the end but no in seriousness so we know the conclusions as we say there's a group there's multiple groups out there there's people that do it for obviously to sell it or profit there's other people who do it to get what they need from systems so they're making some of them manage to stay pretty quiet with their exploits another thing we need to realize from this we can't fully rely on the security community to identify and protect this from zero day and it's kind of common sense but it's just another item that's kind of highlighted out there there's a lot of people out there looking at the same file like I said if they are getting I don't know how many pds to come in a day to different antivirus vendors but if they're getting like hundreds of them thousands of them and one of them is slightly different like this like I said and there wasn't like hundreds or thousands of jb2 to code adobe exploits coming there's just a couple it's kind of hard for them to identify so I guess it's probably someone got hit with it reported it and that's how the initial detection and people started looking into it adobe and the antivirus vendor so it's not a real good way out there for security community to protect this right off the bat it seems like full and partial disclosure fail us to some degree but they also succeed but what's very clear is that no disclosure obviously was the worst option of all these so if people start to find out about stuff and like I said I don't know I'm not in adobe shoes but it seems like if they could sing something a little bit sooner probably would have been a better solution so then our bad actors whether it's ghostnet or ghostnet our way or anyone they're pretty much busy at work we know this for a fact there's zero days pretty frequently in different file formats that we see they're always looking for new ways around new exploits it's been happening for a long time but they've been pretty busy at work adobe's had a few other issues recently such that real quick on the last slide and another thing is a key item Matt really want to put in your pds carry a lot of useful information so like all that like you start editing it keeps old revisions all the header information the mod dates if you if you can trust the data or it's valid there's actually a lot of useful information there especially if you want to start doing tracking back different attacks seeing how they evolve so for example the one taken from Millworm when it was actually weaponized if you decoded it they actually left in all the same exact same code a lot of the words down to the words so you could see that the weaponized version was without a doubt taken from Millworm so that's what that's what's kind of interesting some of the data all the data that's inside pds and they start adding it with other file they started adding in other timestamps you can see other information you can start kind of trying to figure out who it ties back to so final some of the final conclusions so kind of this it's certainly I think it really served as a lesson to learn how the community a lot of people came together a lot of people argued a lot of people did different things a lot of people pointed fingers but in the end I think a lot of people learned some lessons that helped with the next time so this is not the first time this has occurred it's not going to be the last time I think we've already seen some improvement from Adobe for example the recent flash vulnerability they seem to have got maybe it was easier for them to patch actually but they got some stuff turned around quicker it seems like people are starting to to learn and get some better feedback and response from it all so that is that is our presentation thanks for attending I said Matt Richard didn't make it you can ask him for his tool you can harass him at two o'clock feel free to do whatever feel free to come find me later thank you