AP and Dell SecureWorks Breakdown Evidence of Russian Hacking - Part I

a reply to: dragonridr

I'm not confusing anything. And once again, you're not responding to what I said. Let's not forget that this started with an abysmally inaccurate claim made by you that there's no way phishing can lead to an intrusion. You haven't acknowledged that you were wrong and you've just steamed right along.

Next up, you made another inaccurate claim that "a hacker will leave zero evidence behind." That's not true either. I explained why that wasn't true and once again, you just ignored what I said and pressed on.

Now you're claiming that I'm confusing detection with attribution while simultaneously and inaccurately characterizing the operation of IDSes to somebody who literally wrote his last Snort rule a month ago.

So how can you identify the hacker If caught by what software they attempted to use problem is that software is always made available by its creators on hacker sites. Because the more people that use the lower your risk of being Identified.

That sounds good but it's actually not true. I've been out of the scene for years now but not THAT long. What you'll find on hacking sites are products of the scene. What you seem not to understand is that hackers don't want to be detected in the first place. While sharing your tools with the world may make attribution more difficult, it also makes detection easier.

a reply to: theantediluvian

The only way phishing leads to an intrusion is if you have a clueless administrator that gives root access to all users. While simultaneously not verifying adresses of users. It never happens on a well maintained system. An intrusion will only occur by using exploits which are easily available on hacker sites for download.

The trick of a true hacker is to hide the software from detection and I explained how that Is done. As for the exploits they are put out daily on hacker sites . Even the NSA tool kit hit the Web recently.

One more thing this isn't the 1980s anymore. Was tough doing all that hacking with your commodore 64 wasn't it? Most of the exploits today involve java and coming in the Web page designs by say apache.

a reply to: theantediluvian

Before we proceed though, I would note that the date of these mod times is 2016-07-05 — July 5th? That's almost a month after CrowdStrike had given the hackers the boot.

Exactly. It wasnt a hack. thats the whole point.

That's also weeks after Assange claimed to have emails that would hurt Clinton and weeks after "Guccifer 2.0" had already been releasing documents?

That's because the emails were not released in that batch:

Source

The documents posted online do not appear to contain any email or communications, but rather include shared passwords for the committee shared accounts to various news services, Lexis, and a federal courts public access system called PACER.

And really? Cygwin? What maverick of forensics is using Cygwin?

I support government encryption and RF engineers that frequently use Cygwin. Whats your point and please dont spare the technical details.

I was going to address the 22 MB/s thing.

That's not that fast. That's like 176 Mb/s. Let's pretend that the date makes sense and just for the sake of argument go by this rather unsupported notion that we've got files copied from the DNC to somewhere remote.

* Where were the DNC servers located? On site in the offices? Or were they hosted somewhere?
* What kind of connection did the DNC have?
* How do we know that point B was local to the hacker and not an interim server?

I also support multiple clients with high bandwidth connections to the internet in the same city or state. (MD/DC) where we are close to a central hub (Mae East). Even with the same service provider and close proximity we never see consistent high bandwidth transfer speeds. The speeds vary 10-15%. And you NEVER see full bandwidth utilization without pretty intense tuning of tcp windowing, MSS and receive window. Even with a dedicated connection supporting jumbo frames and highly tuned gear at both ends, I've only ever seen just over 85% utilization. Internet doesn't support jumbo frames. On the contrary, all packets max out at 1500bytes and are fragmented, needing re-assembly at the receiving end. This adds latency on top of internet propagation time. Then there's out of order packets, retransmissions etc. etc. Possible? Yes but HIGHLY HIGHLY improbable.

What exactly is the author saying in this mess here?

Conclusion 5: The lengthy time gaps suggest that many additional files were initially copied en masse and that only a small subset of that collection was selected for inclusion into the final 7zip archive file (that was subsequently published by Guccifer 2). Given the calculations above, if 1.98 GB were copied at a rate of 22.6 MB/s and all the time gaps were attributed to additional file copying then approximately 19.3 GB in total were initially copied. In this hypothetical scenario, the 7zip archive represents only about 10% of the total amount of data that was initially collected

Hes presenting a scenario where a group of files copied, then some were zipped, and then another group of files were added to the zip file.

The problem there of course is that that if the files were copied in a single batch, the time between last mod times doesn't make sense for the theory because the start of each transfer would fall within a second of the last mod of the file transferred immediately before.

Thats the point. The conclusion is that files were copied as a batch initially and then selected files from the batch were chosen for inclusion in the 7zip file. the gaps are where files that were copied were excluded from the 7zip.

So the obvious solution is to then invent theoretical missing files to fill in the gaps? And how would one determine the size and number of files in the gaps?

Easy. Given that there was a consistent bit rate and average file size, a reasonable estimate could be determined.

Initially when this data was analyzed, the “time gaps” were attributed to “think time”, where it was assumed that the individual who collected the files would copy the files in small batches and in between each batch would need some “think time” to find or decide on the next batch to copy. This may be an equally valid way to explain the presence of time gaps at various junctures in the top-level files and folders. However, in this analysis we will assume that a much larger collection of files were initially copied on 7/5/2016; the files in the final .7z file (the subject of this analysis) represent only a small percentage of all the files that were initially collected.

I certainly wouldn't point to this as any reason to say "case closed." It's not even remotely definitive. Relies on a TON of assumptions and ignores more plausible scenarios.

Whether it was think time or selecting groups for inclusion after the batch copy, that doesnt negate the data transfer rate which is really the whole point.

a reply to: Mike.Ockizard

Exactly. It wasnt a hack. thats the whole point.

You mean that was the conclusion the author started with?

That's because the emails were not released in that batch:

Thank you for pointing this out. This archive was made public on or about Sept 13, 2016 from the looks of it. The files are not from the DNC hack but rather from the DCCC hack announced at the end of July. The DCCC is a separate entity focused on fundraising for Democrats in the House of Representatives.

I haven't done much reading at all about it but skimming through some stuff now, it looks like it started with a phishing campaign using the domain actblues.com to mimic the legitimate domain of their donations site, hosted by their payment processor, actblue.com. That domain was registered on June 14th, the same day the DNC hack was announced.

The dates fit within the timeline of the DCCC hack from what I can tell without doing any digging. However, since they're not from the DNC computers, they don't inform anything about the DNC hack directly. Let's assume a hypothetical insider. Do the DNC and DCCC share staff? I think we can infer from the CrowdStrike involvement that they don't share infrastructure.

I support government encryption and RF engineers that frequently use Cygwin. Whats your point and please dont spare the technical details.

Cool story? I don't know what technical details you're expecting me not to spare. Except for some very specific circumstances, I can't conceive of a good reason to use Cygwin. It was almost cool but still kinda Mickey Mouse when I was a teenager in the 90's. Now it's 2017 and virtualization is ubiquitous. Perhaps my imagination is failing me. Either way, if it offends you greatly, I'll withdraw my off-the-cuff slight. Cygwin 4 life, it's k-rad.

I also support multiple clients with high bandwidth connections to the internet in the same city or state. (MD/DC) where we are close to a central hub (Mae East). Even with the same service provider and close proximity we never see consistent high bandwidth transfer speeds. The speeds vary 10-15%. And you NEVER see full bandwidth utilization without pretty intense tuning of tcp windowing, MSS and receive window. Even with a dedicated connection supporting jumbo frames and highly tuned gear at both ends, I've only ever seen just over 85% utilization. Internet doesn't support jumbo frames. On the contrary, all packets max out at 1500bytes and are fragmented, needing re-assembly at the receiving end. This adds latency on top of internet propagation time. Then there's out of order packets, retransmissions etc. etc. Possible? Yes but HIGHLY HIGHLY improbable.

Gosh. That's a nice block of unnecessary verbiage. I have nothing to add I guess except that water is wet and it's self-evident that "the Internet doesn't support jumbo frames" considering the Internet doesn't deal in frames at all.

Not that this isn't fun but I'm fairly certain it's just you and I participating in this thread at this point so let's just cut to the chase. Here's the real problem: the author is building on a bunch of unsupported assumptions.

1. We have absolutely no idea between what computers this hypothetical transfer occurred.

2. It's just as likely that the hypothetical transfer occurred between two boxes at the DCCC... prior to exfiltration.

3. It's also equally likely that the hypothetical transfer occurred between computers at Hacker HQ.

4. It's also possible that transfer were between servers in datacenters somewhere which is the point I was trying to make when I asked if the DNC (now I know DCCC) servers were on site at the offices or not. I regularly get transfer rates in the neighborhood of 20MB/s between VPSes at different ISPs, thousands of miles away. I'll be happy to screen shot it if you're skeptical. We already know that in the case of the DNC hack, that they were using US VPSes, purchased with BTC, for their C2 servers.

The claim that this analysis "proves" an inside source falls completely flat on its face on the above alone without even getting into the hazy methodology of estimating transfer speeds from gap times.

If the hypothesized transfer rate cannot exclude the aforementioned transfer scenarios — which are entirely consistent with a hack — what is the "whole point" again?

a reply to: theantediluvian

So it all boils down to the speed and whether we trust CrowdStrike? There's also the case for whether the file this came from is actually from Guccifer.

The speed cited in the report is consistent with USB 2.0 speeds. Coupled withthe date/time stamps, although capable of being modified, is circumstantial evidence that the files were downloaded on the East Coast. This implies the CrowdStrike, Govt and Guccifer versions are not correct.

And we aren't even considering Sy Hersh's claim that the FBI has a report which states that Seth Rich was in contact with Wikileaks and offered them DNC documents in exchange for money, and that Wikileaks had access to Rich's DropBox account. Hersh also claims that the entire Russiagate/DNC hack story was a disinformation campaign run by John Brennan at CIA.

The smoking gun for me though is the question of what speed connection the DNC has. That would shine light on this whole thing.

For me, looking at a BS CrowdStrike report and the other circumstantial evidence, I choose the circumstantial evidence as being a more likely explanation.