Roger Stone and Jerome Corsi Pushed Seth Rich Lie After Privately Admitting

a reply to: Wardaddy454

And the best that Crowdstrike and FireEye could come up with is a bunch of "possibly, appears, connects, indicates".

Attribution ain't easy and they're cybersecurity firms not intelligence agencies or law enforcement. What exactly were you expecting from them?

Phishing attacks are not a tactic unique to Russia.

Ok?

Add to that the Gussifer 2.0 information is bunk. Is there proof that he worked for the Russian government? If not, then it just makes him a liar.

This is what I'll tell you re Guccifer 2.0. "He"/they had the goods. There were files from the DCCC that were provided to Aaron Nevins, Roger Stone, etc. There were mails from Sarah Hamilton that were hosted in password protected archives on DCLeaks, along with emails from Billy Rhinehart, Colin Powell and others that "Guccifer 2.0" gave TSG and other outlets access to.

And we know from the Bitly links collected by SecureWorks that all of those were part of the same phishing campaign that snared John Podesta whose emails ended up published by Wikileaks.

That was all known from info in the public sphere. The Mueller indictments went much further. For instance, the email address dirbinsaabol@mail[.]com was used to register DCLeaks domain and the Bitly account (john356gh) that created all the shortened links used in the phishing campaign as well as for the crypto site (not sure which) which hosted the wallet from which the funds were sent to pay for DCLeaks VPS (in Malaysia). Further, the same BTC wallet was apparently used to register the domains and lease the servers used for the phishing campaign (accounts-qooqle.com, account-gooogle.com) as well as the VPN that was used when connecting to the @Guccifer_2 twitter account.

Granted, this doesn't prove that the perps were Russian but it does connect the dots between the phishing campaign, Guccifer 2.0, DCLeaks, the DCCC hack and the Podesta emails (and the Powell, Breedlove, Rhinehart, Hamilton and other emails), etc.

Having absolutely nothing to do with Seth Rich.

I could go on but suffices to say I've been through everything I could find as it's become available and I've found NOTHING that contradicts the initial claims of CS and everything from all of these sources jives perfectly. So I'm inclined to accept the attribution from Mueller without further reservation.

Maybe I'll put together a thread recapping everything that's out now but honestly, I'm a little tired of talking about it only to have people who are deep in politically-motivated denial vomit well debunked talking points because anything is better than admitting that what they want to believe is wrong.

Next, Crowdstrike characterized the groups supposedly involved as top tier groups. But suddenly this one time they get sloppy and make amateurish mistakes like leaving Cyrillic identifiers, and "accidentally" forgetting to turn a VPN on?

You're referring "Guccifer 2.0" reportedly connected from a GRU HQ IP to an unnamed social media site (probably Twitter) a single time, as reported by The Daily Beast, citing an unnamed source with knowledge of the investigation? Assuming the reporting is accurate, it's not really *that* shocking — everyone makes mistakes. I don't care how smart you are, given enough time you'll make mistakes. In the case of G2 though, as you note, there were other flubs. My suspicion had been that the G2 persona wasn't being run by the hackers themselves.

That suspicion was seemingly confirmed in the Mueller indictments where it was Unit 26165 that was primarily responsible for the hacking and Unit 74455 primarily responsible for running the social media accounts.

Interestingly, everyone in the Mueller indictments is GRU and nobody was SVR ("Fancy Bear" vs "Cozy Bear") so maybe the initial CS assessment was wrong or the SVR tradecraft was better? (or maybe there's more to come from Mueller?)

Or is it more likely that a paid private group found an easy payday by claiming it was the Russians.

There wouldn't have been anything easy about it. It would have to been done from the beginning with the intent of framing the Russians. We're talking back in 2015. There's overlapping infrastructure with prior operations on top of that, not to mention the selection of targets from the larger phishing campaign (in the thousands) best fits the Russians.

And really, if you look at what's in the Mueller indictment, there's no way all of that came from forensics. So unless they pulled it out of their asses, it's the product of state-level sources and methods.

Why are you so interested in it being anyone BUT the Russians? I wonder if the Russians had done the same to the Republicans, Trump, etc if you'd be so keen on looking for any alternative to attributing it to the Russians?

We'll never know because the DNC, the victim of a crime, paid a private company $$$ to handle this instead of the FBI.

Yeah... that's an extremely superficial talking point really. Notice that nothing I mentioned above comes from the DNC servers? Setting aside the fact that forensic images of those servers were provided to the FBI, none of this happened in a vacuum. There were servers for the spoofed sites for the phishing, C&C servers for the implants, at least one VPS for a site for publishing exfiltrated material, Bitly accounts used for shortened URLs in the phishing emails, domain registrations, certs, VPNs, operational emails, hosted BTC wallets, social media accounts, etc, etc, etc.

And there were human beings, working at computers, in offices, behind network connections, doing all of this and those people in turn were in units within agencies with superiors they answered to in their own offices. So besides just the straight forensics and whatever crazy # the USIC and its allies have up their sleeves interms of CYBINT, you've got all the potential for intelligence gathering from SIGINT, HUMINT, etc.

a reply to: theantediluvian

The Russian stuff in the Mueller "indictments" are so far unproven innuendo and display window dressing.

The fact is, the DNC refused to give the server itself to the FBI and I wonder WHY.

😆🤦😆

a reply to: Witness2008

Im laughing right now. Has it been proven that Russia did the hack? Are you serious?

a reply to: xuenchen

Where is the skepticism when you are creating threads?

a reply to: xuenchen

no no no

originally posted by: xuenchen
a reply to: theantediluvian

The Russian stuff in the Mueller "indictments" are so far unproven innuendo and display window dressing.

The fact is, the DNC refused to give the server itself to the FBI and I wonder WHY.

😆🤦😆

I don't know why you put indictments in scare quotes and that's not what innuendo means. As for giving the FBI the server — there's no "server" to give them per se.

The servers were virtual machines. Typically, the way that works is that there are physical servers that are hosts where the processing is done for multiple virtual machines and separate shared storage (storage servers) where the virtual drives are stored as VMDKs/VHDs/VHDXs (basically files that contain all the data that would be on a non-virtual server's hard drives).

Forensic images of the virtual disks (themselves drive images) were provided to the FBI.

Furthermore, if CrowdStrike was trying to conceal something or fabricate something, they wouldn't have needed to do anything elaborate. They could have just altered the filesystems in place and let the FBI image them. It really wouldn't have made a bit of difference. It would literally take zero extra effort.

The only reason to turn over the physical hardware (which would have precluded using it for freshly created VMs) would have been if there was some suspicion that it had been tampered with.

Why did the DNC deny the FBI access to its server? Because it was an inside job.
a reply to: TheOne7

originally posted by: gimcrackery
Why did the DNC deny the FBI access to its server? Because it was an inside job.
a reply to: TheOne7

As the Antideluvian posted above, there was no physical DNC server that was hacked. It was a combination of email and virtual machines.

The GRU team was able to obtain "snapshots" of the virtual machines with DNC data sets and then move them to an account that they had set up with the same hosting service. The indictment does not name the service.

arstechnica.com...

originally posted by: BlackJackal

originally posted by: watchitburn
a reply to: TheOne7

Except the actual forensic data made available would necessitate a direct download and not remote access.

Is this the forensic data you are referring to? LINK

If so, I'm sorry but this does not pass even the smell test. Maybe this guy can fool people who don't understand how computer forensics actually work, but that's about it.

So the entire interruption that the data was downloaded locally and not remotely comes from this guy William Binney a former technical director for the NSA. I have no idea why this guy would lie, and maybe he isn't lying but the data he has provided as evidence of his claim is severely lacking.

Binney says the highest transfer rate was 49.1 megabytes per second, which is much faster than possible from a remote online connection. He says some colleagues challenged this assumption and ran various tests, from the Netherlands, Albania, Belgrade and in the UK and he says, “The fastest rate we got was from a data center in New Jersey…to a data center in the UK and that was 12 megabytes per second, which is less than a fourth of the rate necessary to transfer the data, as it was listed from Guccifer 2.0…However, it is the perfect download rate for a thumb drive.” He says their findings don’t prove who did it but they do prove that the data breach was local and did not consist of an overseas hack.

Ok, so the first big read flag here is how can anyone familiar with network forensics not be able to tell the difference between network traffic (AKA remote traffic) and local USB transfers? How could he even confuse the two? They are recorded in two very different ways. Network traffic is captured by either a network device such as a gateway or a tap or an application like Wireshark. The output of that data is a PCAP file. Transfers between a USB drive and a host machine are recorded in multiple places on the host machine. None of those data stores even store transfer rates at all.

The USBSTOR located in the SYSTEM hive (SYSTEMCurrentControlSetEnumUSBSTOR) USBSTOR contains details on the vendor and brand of USB device connected, along with the serial number of the device that can be used to match the mounted drive letter, user, and the first and last connected times of the device.

The MountedDevices key (SYSTEMMountedDevices) Allows investigators to match the serial number to a given drive letter or volume that was mounted when the USB device was inserted. It’s possible that the investigator won’t be able to identify the drive letter if several USB devices have been added, since the mapped drive letter only shows the serial number for the most recently mounted device for each letter assigned.

The MountPoints2 key found in a user’s NTUSER.dat hive
(NTUSER.datSoftwareMicrosoftWindowsCurrentVersionExplorerMountPoints2) This information will reveal which user was logged in and active when the USB device was connected. MountPoints2 lists all of the device GUIDs that a particular user connected, so you might need to search through each NTUSER.dat hive on the system to identify which user connected a particular device.

The USB key in the SYSTEM hive (SYSTEMCurrentControlSetEnumUSB) This key provides investigators with vendor and product ID for a given device, but also provides the last time the USB device was connected to the system. Using the last write time for the key of the device serial number, investigators can identify the last time it was connected.

The setupapi log (ROOTWindowsinfsetupapi.dev.log for Windows Vista/7/8)(ROOTWindowssetupapi.log for Windows XP) Searching for the serial number in this file will provide investigators with information on when the device was first connected to the system in local time. Examiners must exercise caution, as unlike the other timestamps mentioned in this article which are stored in UTC, the setupapi.log stores its data in the system’s local time and must be converted to UTC to correctly match any timeline analysis being performed by the investigator.

LINK

I'm sorry, I find it incredulous to believe that any forensic analyst worth a damn would not be able to tell the difference between a USB file transfer and a network transfer. It is literally two separate mechanisms for transferring data. So, literally the only proof that this was a USB transfer and not a remote transfer of data is the word of one man. Also, I am unaware of any forensic indicator which records the speed of USB transfers.

So I am left with a couple of questions. Where and what kind of data is he referring to when he says the transfer rate was 49.1 MB/s. How did he confuse USB and Network traffic?

Hate to tell you this, but -- even if it was downloaded to a USB drive, it was through intranet, which is local, but networked, which would log the data transfer speeds in the network adapter logs. It's also miraculous, that the transfer speed is essentially basic, in that the speed recorded is synonymous with standard wifi speed.