It looks like you're using an Ad Blocker.
Please white-list or disable AboveTopSecret.com in your ad-blocking tool.
Thank you.
Some features of ATS will be disabled while you continue to use an ad-blocker.
Why not break into smaller chunks and transmit more slowly to avoid detection? Wouldn't you want to maintain access?
Why is the conclusion of an insider job so difficult for you to consider? It appears to challenge some deeply held world view or something.
All we have so far is innuendo, suggestion, accusation and summary judgment supporting that belief.
One piece of substantial evidence is all it would take.... ?
originally posted by: Dudemo5
Except if you can see the data was downloaded, you can see to where. This is complete nonsense.
Intelligence Committee Chairman Richard Burr (R-N.C.) stopped short of endorsing Trump's Thursday morning call for a congressional investigation of the media. But Burr did predict that the final product of his panel's bipartisan inquiry into Moscow's disruption of the 2016 election would illustrate factual errors in some media reports on the issue.
"We're not going to investigate news organizations, but we will use the findings of our report to let the American people hold every news organization accountable for what they portrayed as fact, in many cases without sources — at least, no sources that would admit to it," Burr told POLITICO.
"And I think, when we finish our report, we will find that quite a few news organizations ran stories that were not factual," he added.
originally posted by: Dudemo5
originally posted by: JBurns
a reply to: Dudemo5
But he didn't say anything about a destination or source IP. What he does say is that data was copied in two separate bursts, 12 minutes apart totaling 87 seconds. 16GB is a lot of data to copy in such a short time, and it is unlikely they would do so with such speed over the network/WAN. Doing so would certainly raise red flags, so it would've been split into much smaller chunks and possibly transmitted as another type of data (for instance, HTTP requests/responses).
By "it" what do you mean? The Windows event log? Or /var/log? My point is that USB file transfer wouldn't be documented the same way as data going across a network. Anything having to do with an IP address would be separate from local file transfer disk I/O stuff. You might have a hardware address that is specific to that USB device, but it wouldn't have an assigned IP in any way.
Right. The disk I/O stuff is separate from the network activity. However, we have the destination IP address, so clearly there was an IP address associated with the breach through which logs show significant outbound traffic.
No, the USB drive does not have an IP address.
originally posted by: network dude
originally posted by: Dudemo5
originally posted by: JBurns
a reply to: Dudemo5
But he didn't say anything about a destination or source IP. What he does say is that data was copied in two separate bursts, 12 minutes apart totaling 87 seconds. 16GB is a lot of data to copy in such a short time, and it is unlikely they would do so with such speed over the network/WAN. Doing so would certainly raise red flags, so it would've been split into much smaller chunks and possibly transmitted as another type of data (for instance, HTTP requests/responses).
By "it" what do you mean? The Windows event log? Or /var/log? My point is that USB file transfer wouldn't be documented the same way as data going across a network. Anything having to do with an IP address would be separate from local file transfer disk I/O stuff. You might have a hardware address that is specific to that USB device, but it wouldn't have an assigned IP in any way.
Right. The disk I/O stuff is separate from the network activity. However, we have the destination IP address, so clearly there was an IP address associated with the breach through which logs show significant outbound traffic.
No, the USB drive does not have an IP address.
Where did you get your facts from? If there was an IP associated with this "hack" then it's location will be easy to pinpoint. I had not heard of any of that information being released. I guess when you post your link to the data, I will have learned something new. Thanks in advance for proving your statement.
They were files from the DCCC — from the DCCC hack. If you look at it again real quick, you'll notice that the mod times are all 2016-07-05 (6-7 weeks after the CrowdStrike announcement).
originally posted by: Dudemo5
originally posted by: network dude
originally posted by: Dudemo5
originally posted by: JBurns
a reply to: Dudemo5
But he didn't say anything about a destination or source IP. What he does say is that data was copied in two separate bursts, 12 minutes apart totaling 87 seconds. 16GB is a lot of data to copy in such a short time, and it is unlikely they would do so with such speed over the network/WAN. Doing so would certainly raise red flags, so it would've been split into much smaller chunks and possibly transmitted as another type of data (for instance, HTTP requests/responses).
By "it" what do you mean? The Windows event log? Or /var/log? My point is that USB file transfer wouldn't be documented the same way as data going across a network. Anything having to do with an IP address would be separate from local file transfer disk I/O stuff. You might have a hardware address that is specific to that USB device, but it wouldn't have an assigned IP in any way.
Right. The disk I/O stuff is separate from the network activity. However, we have the destination IP address, so clearly there was an IP address associated with the breach through which logs show significant outbound traffic.
No, the USB drive does not have an IP address.
Where did you get your facts from? If there was an IP associated with this "hack" then it's location will be easy to pinpoint. I had not heard of any of that information being released. I guess when you post your link to the data, I will have learned something new. Thanks in advance for proving your statement.
From: time.com...
Fancy Bear... was sending command and control instructions from a server with an Internet Protocol (IP) address of 176.31.112.10.