Feature Ideas

This idea expands on the Timestamps view in FEI Viewer. For a set of items within the Evidence Grid, provide a right-click command (similar to the commands for data export) to export a combined timeline for all emails within the view. The exported timeline will be a tabular file (e.g., CSV) which will lend itself well to traditional timeline analysis.

While reviewing projects in FEI, it would be great to have a way to see the cells that are color coded by tag across the grid.

Integration with Google Web Risk or similar URL scanning API to bulk scan URLs for threats.

When searching for phishing links, it would be handy to have a list of all links from all emails, project wide. From here we can push into various link scanning APIs or domain scanning APIs. Arman suggested integration with https://cloud.google.com/web-risk , which I think is a great ida.

This is a big feature request so maybe roll out aspects of it in stages. Part 1 would be to map out a timeline or chart showing the transfer of messages in a thread or reply chain for a single email message. So if a single email was the 4th reply in a chain of emails then all 5 emails would be plotted. Example: 2021-08-01: Subject: FW: Re: Test, john@example.com -> eve@example.com 2021-07-01: Subject: Re: Test, jane@example.com -> john@example.com 2021-06-01: Subject: Re: Test, john@example.com -> jane@example.com, CC: eve@example.com 2021-05-01: Subject: Re: Test, jane@example.com -> john@example.com 2021-04-01: Subject: Test, john@example.com -> jane@example.com Part 2 would enrich the data in the plot using additional emails from an email collection which contains other emails in the thread. Color coding, comments, or tooltips could be used to indicate the reliability of plot based on how many additional emails support the data. For example, the plot from part 1 might list all 5 records as being red (less reliable) since they are based on the body of a single which is editable and could be manipulated. The same thread enriched from several different individual emails (Part 2) might show the first record (2021-04-01) as being green (very reliable) since the original email is available and the contents of the first email matches the quoted reply of its contents in the four subsequent emails. If the original copy of the second email (2021-05-01) was missing, then its record might be labeled orange (somewhat reliable) because although the original email is gone, all subsequent messages were in agreement when quoting its contents. Part 3 would be to enrich the data using whatever additional details you can pull from the email headers and server side which would hint at how many messages are supposed to have been in a thread and when they were sent.

Similar to the "Export list..." command in X-Ways Forensics, it would be extremely useful if I could select a set of records in an open project and right-click to "Export list..." as a .tsv or copy the contents to the clipboard. This would provide some basic reporting functionality within FEI so that I could generate a spreadsheet that could be shared with others.

Score emails with the NIST Phish Scale and provide the number as a FEI insight. See published protocol and scoring at the following NIST link. https://csrc.nist.gov/pubs/tn/2276/final

Ingesting a PST into FEI, then running index searches for relative evidence items- to then have the ability to export the grid into a PDF build. But also to export the emails inside the grid as PDF also.

If the email manipulations by Microsoft 365 can be measured and reversed, then it would be great if FEI could DKIM verify these emails. For any emails with a Microsoft domain as the recipient that fail DKIM, FEI could attempt to reverse common Microsoft manipulations (delete newlines between MIME boundaries, remove extra html meta tag) and then calculate DKIM. For emails that verify this way, FEI could include an entry in the DKIM Results stating as much. Something like, Verified: True (after reversing common MS manipulations).

This is a two part request. In the DKIM Results window, FEI should specify the individual components that fail or pass verification. Did the body hash not match indicating that the body was manipulated? Or did the signature data not match because the header fields were manipulated? Something like the following: Body = verified These Headers: mime-version, from, date, message-id, subject, to = failed verification Selecting one of the above fields (Body or These Headers) should highlight the associated section in the MIME window. Reason for request: When manually fixing a DKIM issue like in your CTF, I want to know which section I should be focusing on. Also, because I am not as familiar with the normalization rules for DKIM verification, it is not clear when a single line break might affect verification especially between signed header fields. Having the associated fields highlighted will make it immediately clear which characters are included in the verification calculation.

Quoted emails from Replies and Forwards are parsed to create new child email records in FEI's list of emails for the collection. This would be similar to how X-Ways' shows child objects for embedded content. The advantage of this would be when filtering the metadata of embedded objects. Example: employee@company.com -> employee@personal.email.com employee@personal.email.com -> new.boss@competitor.com In this example, email 1 is sent and then forwarded as email 2. Email 1 is then deleted and the account employee@personal.email.com is collected. All emails involving (to/from/cc/bcc) @company.com are to be collected. Since @company.com is not one of the participants to email 2, it is not identified. If the embedded email that is being forwarded in email 2 were broken out as a child object then the child object would hit on the filter for @company.com. I know that a string search across the email bodies for @company.com would also identify these emails but it would also have a lot of false positives and introduce legal complications. Lastly, the parsing required to implement this feature would likely help support development of the Email thread mapping feature I previously suggested.

Option to split large PST by multiple data ranges without file size limitation.

Be able to merge PSTs then export/save as PST

When investigation 2 .msg file will be easier to have 2 instances Viewer open

When launching FEI and choosing to Launch Viewer, it would be nice to have access to the 4 Intel buttons (IP Intel, Domain Intel, Email Intel, and URL Intel) without loading an email. Currently they are grayed out be default. Basically, I would like to be able to use FEI to access these various APIs for things other than email investigation. FEI can currently do this but I have to load a dummy email before getting access to those features.