Case Study An email attached to a $20 million dollar lawsuit purported to be from the CEO of “Tech.com” to a venture capital broker. The message outlined guaranteed “warrants” on the next round of funding for the broker. “Tech.com filed counterclaim and claimed the email was a forgery. Their law firm engaged us to determine the validity of the message. We imaged all of the CEO’s computers at his office and his home. Recalled the email server backup tapes from off-site storage.
Case Study Searched all hard drives and email server backups for “questioned” message. Search revealed no trace of the message on any of the hard drives or mail spools. When the timestamps and message ids were compared with the server logs it was found that the “questioned” message could not have gone through either “Tech.com’s” webmail or mail server at the time indicated by the date/time stamp on the message. Based on our analysis Defendants filed motion to image and examine broker’s computers.
Case Study Federal Judge issued subpoena and we arrived at broker’s business, but he refused to allow his system to imaged. Broker’s lawyer went into State Court, on a companion case, and got Judge to issue an order for a new Court appointed examiner. The examination revealed direct proof of the alteration of a valid message’s header to create the “questioned” email. What follows are some of the tools and techniques used to document the activity.
Internet Standards (RFCs) RFC – (Request for Comment) Standards for Internet Protocols RFC 2821 Simple Mail Transfer Protocol (SMTP) – the objective of SMTP is to transfer mail reliability and efficiently. It is independent of the particular transmission subtype and requires only a reliable ordered data stream channel. A mail message may pass through a number of intermediate relay or gateway hosts on it’s path from sender to ultimate recipient. (Supplements RFC 821)
Internet Standards (RFCs) RFC 2822 Internet Message Format – the purpose of the standard is to establish the format of the messages. (Supplements RFC 822) 3.6.4 Identification Fields “Though optional, every message SHOULD have a ‘Message-ID:’ field.” The field “provides a unique message identifier that refers to a particular version of a particular message.” It is intended to be “machine readable and not necessarily meaningful to humans.”
Internet Standards (RFCs) Message-ID: The composition of the message-id is represented by the formula: Date/Time Integer Can be formatted to display human readable date/time, but is usually in a hexadecimal string. On Unix systems, the string represents the “number of microseconds since midnight, January 1, 1970, Greenwich Mean Time.” (Unix Time – epoch)
Internet Standards (RFCs) Authentic Message-ID String 3989F5A3.87BDEEE2@tech.com To convert to human readable change the hex to decimal and use one of the Unix time scripts or one of the websites with a converter. 3989F5A3 = hexadecimal 965342627 = decimal Aug 3, 2000 18:43 = Date & Time (+1 hour logs)
Internet Standards (RFCs) Unique id: 87BDEEE2@tech.com This is a unique identification assigned in the SMTP process. The domain name of the company is also attached to help ensure global uniqueness. ESMTP id: This is also a unique identification assigned by each intermediate relay or gateway server. This id is also usually in a hexadecimal string that is reset each day. Resulting in an id that can be resolved to a time window on a particular server.
Internet Standards (RFCs) Suspect Message-ID String 3989e793.87BDEEE2@tech.com To convert to human readable change the hex to decimal and use one of the Unix time scripts or one of the websites with a converter. 3989E793 = hexadecimal 965339027 = decimal Aug 3, 2000 17:43 = Date & Time (matches log)
Server Logs firstname.lastname@example.org Typical logs kept for a week or less and then new log spawned. syslog. = 7/30 – 8/4 (current period) syslog.0 = 7/23 – 7/30 syslog.1 = 7/16 – 7/23 syslog.2 = 7/09 – 7/16 syslog.3 = 7/02 – 7/09 syslog.4 = 6/25 – 7/02 syslog.5 = 6/18 – 6/25 syslog.6 = 6/11 – 6/18 syslog.7 = 6/04 – 6/11
Server Logs email@example.com Analysis of the webmail server logs revealed several issues regarding the validity of the suspect message. Matching trace header timestamps and ESMTP ids revealed that RAA01318 was issued at 17:41:31 to the authentic message. Comparing the 14:41:31 timestamp of the suspect message with the log revealed the server was assigning ESMTP ids beginning with “OAA” not “RRA” as represented in the header.
Server Logs firstname.lastname@example.org Analysis of the mail server logs confirmed that the suspect message was not authentic. Matching trace header timestamps and ESMTP ids revealed that the authentic Message-ID was logged at 17:41:32 and assigned ESMTP id e73MfW903843 then it was sent to the email@example.com server and it was assigned a new ESMTP id e73MfZ331592.firstname.lastname@example.org Comparing the 14:41:32 timestamp of the suspect message with the log revealed the were no messages for over an hour during that time frame.