Slashdot Mirror

This is the guy the DNC hired for their server and worked with Comey. Everything else you posted about is just using your own "alternate Facts" to invent another conspiracy.

Here is report from Cloudstrike on why they beleive it was the Russians: https://www.crowdstrike.com/bl...

> Which is why the credibility of the reporter quoting the anonymous source matters.

No, it doesn't. I give credit to factual evidence, not anonymous rumors.

I give credit to the heuristics that most reliably lead me to the truth.

Finding people or institutions who are good sources of information and have a good track record is a better than average method for finding the truth.

Attempting to independently verify a small subset of the relevant facts in a field for which I have limited expertise is a very easy way to be wrong.

Yay, we finally get something like a fact. You should really point here though as it has more details.

Though that's an earlier article that leaves out the smoking gun of the same IP being used as the control address for the DNC hack and the hack on the German parliament demonstrating the same actor was behind both.

But when we get to the bottom of it, we find it's mostly assumed because of a few RATs (remote access trojans). Problems with that:

- Guccifer 2.0 took credit for it.

Which never made sense, a fairly advanced hacker emulating a guy who guessed password resets do dump celebrity emails?

See also: https://www.sovereignman.com/trends/former-intelligence-officer-on-the-bogus-russian-hack-20578/

A source who both mischaracterizes the Iraq war build up (the CIA did not generally agree with Bush), who undersells the Russian hack evidence (leaving out the control addresses), and is mostly trying to sell a conspiratorial anti-government book and speaking/consulting business.

And one last note, but they were planning to blame Trump for being too cozy to Russia from the beginning.
https://wikileaks.org/podesta-emails/emailid/25651

The timing doesn't work out either, because Trump was still a dark horse candidate during the first leaks

But Trump's uncomfortable pro-Russian biases and entanglements were known all along, that may have been one of the reasons Putin was willing to through with it.

and the DNC itself was asking its media allies to support Trump as one of the "pied piper" candidates, as you can see in the PDF attached to this email

So?

> Which is why the credibility of the reporter quoting the anonymous source matters.

No, it doesn't. I give credit to factual evidence, not anonymous rumors.

Yay, we finally get something like a fact. You should really point here though as it has more details.

But when we get to the bottom of it, we find it's mostly assumed because of a few RATs (remote access trojans). Problems with that:

- Guccifer 2.0 took credit for it. There were allegations made about his use of Russian language, but nobody bothered to give quotes.
- The RATs were widely available on underground forums.

See also: https://www.sovereignman.com/trends/former-intelligence-officer-on-the-bogus-russian-hack-20578/

And one last note, but they were planning to blame Trump for being too cozy to Russia from the beginning.
https://wikileaks.org/podesta-emails/emailid/25651

The timing doesn't work out either, because Trump was still a dark horse candidate during the first leaks and the DNC itself was asking its media allies to support Trump as one of the "pied piper" candidates, as you can see in the PDF attached to this email.

So this pretty much looks like a case of confirmation bias to me.

No, it's Russian because Volexity did decent attribution, unlike the twits at Slate.

APT29 is a well-studied group. Their malware is compiled during the Russian workday. They skip Russian holidays. They target groups that are strategically significant to Russian government. FireEye says they're Russian. CrowdStrike says they're Russian. Even Kaspersky has tied them to existing Russian tools.

Trump may blame 400-pound bedridden hackers, but some of us actually do the hard work to have a fucking clue.

- A Real Cyber Security Researcher

Then don't stop the simulator and return properly after exploiting whatever hole you found in the simulator. See eg. http://venom.crowdstrike.com/

I think they're both important. The shit in the emails is a big deal. But if there is a nation-state sponsored Watergate going on, that's a big deal too.

Vice.com makes a pretty convincing case, but it could be some kind of next-level false flag too. But even if it is, "Guccifer 2.0" is still bullshit.

Maybe there's a thread-the-needle version of reality where there actually is a lone hacker, but reading CrowdStrike's original report about multiple Russian intrusions, it's hard to read that (written before Guccifer 2 showed up) and come away thinking it's that simple...

Seems a lot of hype about nothing to be honest and scaremongering.

From venom.crowdstrike.com:

Floppy drives are outdated, so why are these products still vulnerable?
For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default. And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

Can you link to any currently active examples?

Sure, we can do that.

The best short term defense against this?

Just put
exit 0
at the end of your /etc/rc.local and the rootkit becomes unloadable. Just like in Debian Squeeze.

I did not get that. Would you kindly explain that?

Well, it's even in TFA, and described in more detail here. According to the guy who analyzed it (Georg Wicherski): "the command is appended to the end of rc.local" and "On a default Debian squeeze install, /etc/rc.local ends in an exit 0 command, so that the rootkit is effectively never loaded". This is what happens when you try to install the rootkit on Debian Squeeze.

Dunno about AC, but first glance seems to be that it exploits shitty PHP code in order to get itself hosted onto the websites.

According to TFA, it appears to target one specific kernel (Debian-based), and tries to do some hokey-pokey with RAM to get itself executed. If you want a better description go to the original report

TFA gives some details, however:

The kernel module in question has been compiled for a kernel with the version string 2.6.32-5. The -5 suffix is indicative of a distribution-specific kernel release. Indeed, a quick Google search reveals that the latest Debian squeeze kernel has the version number 2.6.32-5.

The module furthermore exports symbol names for all functions and global variables found in the module, apparently not declaring any private symbol as static in the sources. In consequence, some dead code is left within the module: the linker can't determine whether any other kernel module might want to access any of those dead-but-public functions, and subsequently it can't remove them.

...doesn't say exactly how, but there is one thing that is entirely left out of the equation... if it's a drive-by download, does it definitely require user involvement, or not? According to the original report, the complaints were that they customers were being redirected to a malicious site, but nothing about a trojan being involved.