Technical Exhibits, Michael Sussmann Trial

Thanks to those who’ve donated to help defray the costs of trial transcripts. Your generosity has funded the expected costs of transcripts. But if you appreciate the kind of coverage no one else is offering, we’re still happy to accept donations. This coverage reflects the culmination of eight months work. 

Most of my coverage during the Michael Sussmann trial will be trial related, describing what witnesses and exhibits say about the case.

But there are good reasons to question the conduct of the investigation — and that’s a topic a lot of people have independent interest in. So I wanted to start a running post on technical issues.

If there’s a link that doesn’t work, it probably means I’ve forgot to set permissions to public (some of this needs redaction before posting). Leave a comment or tweet me at @emptywheel.

FBI investigation

160921 Allison Sands’ Lync Notes (thru 161012)

160922: Scott Hellman/Nate Batty assessment

160923: Electronic Communication opening investigation

160923: EC plus all three shared documents

160926: Curtis Heide Lyncs

160926: Heide to Hellman, Hope our assessment is good

160926: Ryan Gaynor notes (includes details on election protection efforts)

161004: Kyle Steere document contents thumb drives

161005: Investigative update from Allison Sands

Includes:

  • FBI conclusion on changing DNS records
  • FBI’s response to David Dagon’s defense
  • Logs from Cendyn, with Listrak still to come
  • Barracuda reference
  • Discussion of Tor node

161007: Sands Draft FD-1023 CHS Report

170118: Sands Closing Memo

170327: 302 interview Alfa Bank

Materials shared with FBI

White paper

DNS logs

62 pages of DNS logs

Trump Who Is

9 IP Addresses

15 Trump mail domains

160919 Expert White Paper

Joffe data requests (postdates original data in white paper)

160820: Antonokakis to DeJong requesting data (including dcleaks)

List of IP addresses

Alfa Bank script

160915: DeJong shares results with Joffe

170718: DeJong to Joffe: I have four jobs that look for Trump

Posts related to technical issues

The Methodology of Andrew DeFilippis’ Elaborate Plot to Break Judge Cooper’s Rules

image_print
18 replies
  1. Xboxershorts says:

    Thank you for this, I was hoping additional data on this was available. Only data I’d seen was the L Jean Camp archive.

    PS…Nobody runs a TOR node accidentally.

    • Xboxershorts says:

      There’s a lot more here that I wasn’t aware of, ferinstance, the domain transfer in 2009.
      Kind of explains why the old MX record had a TTL of 1 hour. But it’s on CenDyn to clear the full DNS zone and any related records from their DNS and they didn’t do that. Why is a very good question to ask. I have yet to see it answered.

      Also, if CenDyn were no longer authoritative for for the domain, the root name servers would never direct a query for that domain to the CenDyn DNS servers. Finding this one improperly registered server through DNS queries to the root name servers would only work if the domain transfer had been incomplete. The IP Address is registered by ARIN to Listrak, so CenDyn hosting a DNS record for a Listrak IP address is a real odd anomaly.

      Also…an unregistered TOR exit node? In a health care provider’s network? Man, that’s an instant audit right there. And there ought to be legal ramifications for that.

    • arj says:

      Agreed—the Tor node would have been picked up by a routine vulnerability can or a penetration test.

      Based on on a quick search of their security scorecard scores for the past year, it’s not obvious that they’ve been negligent, at least since mid-2021 anyway.

      I didn’t see Spectrum in any of the intrusion databases in the 2016–2017 timeframe, either. (There was one in 2020, via Blackbaud).

      In other words, the security staff does not seem to be incompetent.

    • Rayne says:

      LOL I’m going to laugh about the idea of an accidental Tor node all day. Oh, oops, it’s an onion!

  2. Alda Earnest Goodpeople says:

    Having gone through all of this, it seems clear that it was “at least possible” to set up communications between Trump Organization, Alfa Bank, and/or Spectrum Health (whose Devos family had some sort of rewards or credit card deal with Alfa Bank via Amway), as follows. Because of the employment of so many “different” domain names, different IP addresses, different times, and different queries (thousands within a few months, so about less than 100 per day), some in “exclusive” channels (at least Spectrum Health), and where encryption was also employed, and given “back channels” were discussed and sought out, and given Trump and Russian representatives went back and forth, it would have been possible to create a “basic” communications system, for example, but not limited to, using different IP addresses as commands and responses, one IP for “go”, one IP for “stop”, one IP for “hold”, one IP for “yes”, one IP for “no”, and where domain names, and/or times sent could have been predetermined questions, missions, projects, orders, et cetera. Other similar configurations of the many different IP, domains, times, queries, could develop similar “basic” communications systems. Of course none of this proves anything, but it was “at least possible” that those going back and forth on behalf of Trump and Russia (for example but not limited to nor accusing Kislyak) could have set up a cryptic back channel communication in this or a similar manner by bringing the list of predetermined questions, topics, orders, projects, missions, plots, et cetera that would correspond to different times, dates, IPs, domains, et cetera, allowing Trump and Russia to communicate through DNS queries, but not limited to nor alleging the same. Just stating the same was “at least possible”, but then who really needs another Trump rabbit hole? ;0)

  3. John says:

    Curious that the Spectrum Health children’s hospital in Grand Rapids Michigan is less than ten miles from three DeVos/Prince estates and the Amway corporate headquarters…

    [Welcome back to emptywheel. Please use the same username each time you comment so that community members get to know you. This is your second user name which isn’t differentiated enough from all the other “John” or “Johnathan” members here. You’ve posted 10 comments previously as “John Gurley.” Thanks. /~Rayne]

  4. picklefactory says:

    I’ve run some email and DNS servers before. I read the exhibits above because the DNS query log intrigued me after semi-following it here in the past.

    My take overall: vanilla-style delivering mail to a recipient should result in an MX record lookup, and then maybe also lookups for mail-related TXT records for sender policy and so on, and then A/AAAA record lookup for the selected mail exchange, and then contacting that mail exchange and requesting to deliver mail to a recipient. The usual standard is that no authentication is needed for port 25 delivery, but the receiving exchange sometimes does things like a reverse lookup on the contacting address, matching it against an allow- or deny-list, or negotiating an encrypted connection and checking TLS certificates.

    Let’s say I have a server in my domain already, however, and I want it to be able to send emails for notification purposes to an existing email infrastructure. Or maybe I have arranged some regular clandestine transfer of information between parties in different countries! In this case I might not bother setting it up the plain-vanilla way (“look it up in public records and relay accordingly”), because that is bringing the availability and correctness of DNS records into the equation when I already know where the mail will end up.

    So I just hard-code the mailserver DNS A record name (mail1.example.com) into the script or configuration that’s sending it, and let it authenticate itself with a username and password or client TLS certificate or whatever (or a combination of these). In this case, no MX lookup to DNS is produced because we know the name to fetch an A record before we even got started (mail1.example.com). On the other side, mail1.example.com has been configured with its allow-list or other auth, knows the entity on the other end because it’s been prearranged, and accepts mail for delivery.

    Hey-presto, a publicly accessible email server with a configuration that appears legitimate until you attempt to deliver mail without being in on the secret(s). TOR will attempt to obscure the origin of inbound delivery connections. Not super complicated in that it requires only the technical expertise of the channel-opening part and none required for sending/receiving/interpreting once that’s done; the user-facing part of it would be 100% familiar.

    Does that track at all with the thinking about what was happening? Fully admit to not having read everything about it previously, there’s a lot.

    • Eric says:

      Intriguing. Let’s say the parties involved have no desire to acutally send actual emails … but rather just want to communicate via the technique of “foldering”. Where they just communicate via draft emails in the drafts folder and nothing is ever actually sent. I am assuming what you are describing could accommodate this as well … correct?

      • picklefactory says:

        What I am describing is interactions between DNS and MTA (mail transfer agents). MTAs are used to do mail routing and delivery between addresses — this can be local ([email protected] emails [email protected]) or between domains ([email protected] emails [email protected]).

        An email in “draft” status gets into an email system via a mail client protocol like POP or IMAP, or by being saved from a web-based client, not via MTA. It gets to a recipient when an email client puts it in *their own* MTA, usually these days via the “submission” port (587) and requiring a username and authentication as opposed to the “smtp” (25) port used for delivery that anyone can talk to (but hopefully in practice other mail servers). Their own MTA takes care of giving it a message ID and other identifiers, signing it, finding out where it ought to go, contacting DNS…

        So I don’t think this is a sign of foldering as you describe it.

        All that said, though, if there’s a few things admin and operations experience will build in a person, it’s debugging and lateral thinking practice and a toolbox to employ them, and there’s no doubt any number of folks who could come up with a different or more effective way of doing things than the way I outlined above that could leave the same kind of evidence here and there.

        It’s hard to think of everything, though, which I suppose is why we have this leakage.

        • Eric says:

          Sorry I don’t think I explained that well. All parties involved all have access to one single “email account” or messaging app like Metron. They all log /authenticate into the same single account. No email is ever sent or received. That would be the point … to not leave any paper trial of messages ending up being delivered (regardless of how covertly they were sent) to another network. So I guess we are probably talking about two different things … since in this case a MTA is never really used? Or is it still triggered to create the draft … regardless of it ever ending up being sent?

  5. Jean Camp says:

    Yes that tracks reasonably with what was going on, particularly with the strange query that looks like someone trying to hand-code.

    The data have never been investigated. Meuller punted on it. He literally asked the server admins, they were like NOPE. It was a sentence or two in the report.

    I maintain my original position: this is some weird shit and should have been investigated, not dismissed (as emptywheel did with tit jokes and a comment that it was desperate of the HRC campaign, which had nothing to do with the data nor any of my discussions with the press).

    • emptywheel says:

      Welcome, Jean.

      I dismissed the Spectrum Health claims about the DeVoses–based on data, including data about the unusual timeline of the DeVoses’ late support for Trump that year, data that in no way tracked the timeline of the anomaly traffic.

    • emptywheel says:

      Incidentally, I’m trying to go through and arrange the files that were on the thumb drive here.

      I need to post them, but do the enclosures on the Kyle Steele doc match the files you posted one-to-one, or is there an additional one?

    • Eric says:

      Hi Jean so sorry what you have had to endure over these past many years. I do have a couple of questions that maybe you or anyone else following along here could maybe answer. 1) Agent Hellman made this statement that made it into Sands final report. “There is no network traffic between the Alfa Bank and the trump-email[.]com domains, only DNS queries”. Curious how he exhaustively made that conclusion? 2) Oddly this particular IP address (192.216.142[.]4) which was in the Joffe report submitted to the FBI appears to have been excluded in some of the original data that was leaked / circulated online. Curious if that matches with what you saw … or if we just missed from some kind of copy-paste error? As a side the clustering of some of the other seemingly random IPs around Bedminster, NJ (Trump National Golf Club) is rather interesting.

  6. FL Resister says:

    Is there any chance this microscopic examination of the Alfa Bank logs and Trump server could yield conclusions that were once dismissed?

Comments are closed.