Network Bastion: FBI

This is a re-post of a notification sent out by the FBI

The original link is located at: http://www.fbi.gov/seattle/press-releases/2013/man-in-the-e-mail-fraud-could-victimize-area-businesses?utm_campaign=email-Daily&utm_medium=email&utm_source=seattle-press-releases&utm_content=278754

======================================================================

Man-in-the-E-Mail’ Fraud Could Victimize AreaBusinesses

Dec. 2, 2013

The FBI Seattle Division is aware of a fraud victimizing Washington state-based businesses, nicknamed “man-in-the-e-mail” scheme for being an e-mail variation of a known “man-in-the-middle” scam. The FBI wants the public to learn about this scam in order to avoid being victimized.
In 2013, at least three area companies—in Bellevue, Tukwila, and Seattle—were led to believe they were sending money to an established supply partner in China. In reality, fraudsters intercepted legitimate e-mails between the purchasing and supply companies and then spoofed subsequent e-mails impersonating each company to the other. The fraudulent e-mails directed the purchasing companies to send payments to a new bank account because of a purported audit. The bank accounts belonged to the fraudsters, not the supply companies.

Total loss experienced by the three area companies is roughly $1.65 million. In some cases, the metadata on the spoofed e-mails indicated that they actually originated in Nigeria or South Africa.

Under this scam, both companies in a legitimate business relationship can be victimized. The supplier may first ship out the legitimately ordered products and then never receive payment (because the purchasing company was scammed into paying the scammer-controlled bank account). Or, the purchasing company may first make a payment and then never receive the ordered goods (because the supply company never receives that payment).

Here are some of the ways businesses can reduce their chance of being scammed by this man-in-the- e-mail fraud:

Establish other communication channels, such as telephone calls, to verify significant transactions. Arrange this second-factor authentication early in the relationship and outside the e-mail environment to avoid interception by a hacker.
Utilize digital signatures in e-mail accounts. Be aware that this will not work with web-based e-mail accounts, and some countries ban or limit the use of encryption.
Avoid free, web-based e-mail. Establish a company website domain and use it to establish company e-mail accounts in lieu of free, web-based accounts.
Do not use the “Reply” option to respond to any business e-mails. Instead, use the “Forward” option and either type in the correct e-mail address or select it from the e-mail address book to ensure the real e-mail address is used.
Delete spam: Immediately delete unsolicited e-mail (spam) from unknown parties. Do not open spam e-mail, click on links in the e-mail, or open attachments.
Beware of sudden changes in business practices. For example, if suddenly asked to contact a representative at their personal e-mail address when all previous official correspondence has been on a company e-mail, verify via other channels that you are still communicating with your legitimate business partner.

If you or your business has been targeted by the man-in-the-e-mail fraud, report it to the Internet Crime Complaint Center (IC3) at www.ic3.gov. The following information is helpful to report:

Header information from e-mail messages

Identifiers for the perpetrator (e.g., name, website, bank account, e-mail addresses)

Details on how, why, and when you believe you were defrauded

Actual and attempted loss amounts

Other relevant information you believe is necessary to support your complaint

Reference to the man-in-the-e-mail fraud

Filing a complaint through IC3’s website allows analysts from the FBI to identify leads and patterns from the hundreds of complaints that are received daily. The sheer volume of complaints allows that information to come into view among disparate pieces, which can lead to stronger cases and help zero-in on the major sources of criminal activity. The IC3 then refers the complaints, along with their analyses, to the relevant law enforcement agency for follow-up.

The public can learn about other common scams by visiting http://www.fbi.gov/scams-safety/frauds-from-a-to-z and learn about ways to reduce their risk of being scammed: http://www.fbi.gov/scams-safety/fraud/Internet_fraud.

To subscribe to the FBI news feeds, goto: https://delivery.fbi.gov/subscribe

When the hacker group, Anonymous, found out that Scotland Yard and the FBI were planning a conference call to discuss how to deal with Anonymous, and several other groups considered to be nefarious, the e-mail, setting up and giving conference call meeting instructions, was intercepted by someone from the group Anonymous.

Anonymous then used this information to their advantage to turn the tables on the FBI and Scotland Yard by recording the scheduled call and posting it on YouTube.

You can listen to the recording of this call, made by Anonymous, on YouTube

Read a rough transcription of the conversation here.

So how was Anonymous able to intercept an e-mail which should have been both encrypted prior to sending and sent via an encrypted network?

The answer lies in the fact that all e-mail is sent as PLAIN TEXT across the Internet. Unless the message is encrypted, either at the workstation, or via the e-mail server software, it is PLAIN TEXT and can be read by anyone who can capture the data during its journey.

Short answer: Either someone at the FBI got lazy, and there was no SSL/TLS on the FBI e-mail servers or one or more of the recipients has a very poor password on their e-mail account.

Whether the original sender of the message “forgot” to encrypt, his workstation was not equipped to encrypt, the connection between his workstation was not encrypted, or the FBI is not equipped to encrypt, this incident is unforgivable and, once an investigation has been completed, the responsible parties be should terminated.

In fact, this should not be under the control of the sender of the e-mail at all. With any government security agency, or even with any business, the process of encrypting e-mail should be fully automatic and transparent to the users.

E-mail, unless encrypted, is sent as plain text over the public Internet, I always advise both my hosted and consulting clients to “never write anything in an e-mail message you would not want to see in the newspaper or on TV.” They usually laugh when I say that but my concerns are being borne out by both the reports which have so frequently appeared in the new and the fact that there are so many new legal requirements mandating e-mail encryption in the banking, healthcare, legal, and ever increasing numbers of other business groups.

So, now that the proverbial cat is out of the bag at the FBI, what can you do to prevent your e-mail from getting into the wrong hands?

At ChicagoNetTech we run TLS on our SmarterMail e-mail server product. TLS is an extension of the SSL encryption protocol which actually allows our clients to both make an SSL connection to the e-mail server to originate their e-mail via POP, IMAP, ActiveSync, or our SSL encrypted web interface if so desire, originate their e-mail message, and send it through the Internet via the TLS security protocol.

TLS is a relatively new encryption capability on many e-mail systems and, as part of the transmission process, encrypts inter-e-mail server data traffic so it cannot be easily intercepted.

Whether or not TLS is supported by an e-mail server is very easily tested. In the case of e-mail sent to and from Timothy Lancaster, the originator of the conference call intercepted by Anonymous, we see the following results:

The US FAILS:

TestReceiver

CheckTLS Confidence Factor for "Timothy.Lauster@ic.fbi.gov": 0

MX Server	Pref	Con- nect	All- owed	Can Use	TLS Adv	Cert OK	TLS Neg	Sndr OK	Rcvr OK
mail.ic.fbi.gov [153.31.119.142]	10	OK (85ms)	OK (786ms)	OK (74ms)	FAIL	FAIL	FAIL	OK (1,020ms)	OK (76ms)
Average		100%	100%	100%	0%	0%	0%	100%	100%

The results in the grid above show that the FBI’s e-mail server FAILS the most basic of Internet e-mail security, TLS. The e-mail server used for the FBI’s domain, IC.FBI.GOV does not have even the most basic of security enabled.

Repeating this TLS check test for Stewart.Garrick@met.police.uk shows the same thing:

ENGLAND

FAILS:

TestReceiver

CheckTLS Confidence Factor for "Stewart.Garrick@met.police.uk": 0

MX Server	Pref	Con- nect	All- owed	Can Use	TLS Adv	Cert OK	TLS Neg	Sndr OK	Rcvr OK
mail3.met.police.uk [212.74.97.198]	15	OK (180ms)	OK (167ms)	OK (169ms)	FAIL	FAIL	FAIL	OK (682ms)	OK (163ms)
mail4.met.police.uk [212.74.97.212]	15	OK (181ms)	OK (165ms)	OK (164ms)	FAIL	FAIL	FAIL	OK (673ms)	OK (165ms)
mxbackup.uk.cw.net [195.92.195.234]	20	OK (155ms)	OK (241ms)	OK (144ms)	FAIL	FAIL	FAIL	OK (686ms)	OK (782ms)
Average		100%	100%	100%	0%	0%	0%	100%	100%

The e-mail servers for the domain MET.POLICE.UK FAIL the TLS test and do not have the capability to encrypt inter-domain e-mail messages.

Validating against other domains included in the e-mail message intercepted by Anonymous, we the following results on the part of the e-mail servers used by other high-level security officials in other countries who were invited to participate in the conference call:

FRANCE PASSES:

TestReceiver

CheckTLS Confidence Factor for "olivier.nael@interieur.gouv.fr": 90

MX Server	Pref	Con- nect	All- owed	Can Use	TLS Adv	Cert OK	TLS Neg	Sndr OK	Rcvr OK
tigre.interieur.gouv.fr [212.234.218.76]	10	OK (172ms)	OK (337ms)	OK (162ms)	OK (161ms)	FAIL	OK (1,433ms)	OK (163ms)	FAIL
Average		100%	100%	100%	100%	0%	100%	100%	0%

Note: Cert failures do not affect TLS encryption, but may mean the site isn't who they say they are.

NOTE that the CERT failure means that the TLS test was unable to verify the e-mail address. They may be because it was changed since being published by Anonymous or that the domain INTERIEUR.GOUV.FR runs Greylisting. If we test in a few minutes and the CERT OK changes to PASS, then we will know they run Greylisting.

The NETHERLANDS PASSES:

TestReceiver

CheckTLS Confidence Factor for "michel@nhtcu.nl": 90

MX Server	Pref	Con- nect	All- owed	Can Use	TLS Adv	Cert OK	TLS Neg	Sndr OK	Rcvr OK
pochta3.nhtcu.nl [83.149.67.40]	8	OK (154ms)	OK (688ms)	OK (144ms)	OK (143ms)	FAIL	OK (1,663ms)	OK (150ms)	OK (149ms)
pochta4.nhtcu.nl [83.149.94.112]	9	OK (154ms)	OK (159ms)	OK (144ms)	OK (145ms)	FAIL	OK (1,138ms)	OK (150ms)	OK (151ms)
Average		100%	100%	100%	100%	0%	100%	100%	100%

GERMANY PASSES:

TestReceiver

CheckTLS Confidence Factor for "andre.dornbusch@iuk.bka.de": 90

MX Server	Pref	Con- nect	All- owed	Can Use	TLS Adv	Cert OK	TLS Neg	Sndr OK	Rcvr OK
smtp.ts-businessmail.de [217.150.155.10]	100	OK (209ms)	OK (696ms)	OK (174ms)	OK (175ms)	FAIL	OK (1,934ms)	OK (404ms)	FAIL
Average		100%	100%	100%	100%	0%	100%	100%	0%

SWEDEN FAILS:

TestReceiver

CheckTLS Confidence Factor for "peter.ericson@rkp.police.se": 0

MX Server	Pref	Con- nect	All- owed	Can Use	TLS Adv	Cert OK	TLS Neg	Sndr OK	Rcvr OK
mail.telia.com [62.20.233.128]	10	OK (193ms)	OK (182ms)	OK (178ms)	FAIL	FAIL	FAIL	OK (1,118ms)	FAIL
Average		100%	100%	100%	0%	0%	0%	100%	0%

Getting back to that "what happened" question asked at the top of this posting, it looks like neither the FBI, nor several other high-security installations run TLS!

While I would certainly not consider TLS to be the only security protocol implemented for communications between international security agencies, it should, at the very least, be a jumping off point for any secure e-mail communication.

No matter what kind of e-mail server you are running, or what purpose you are running your e-mail for: personal, business, not-for-profit, whatever the use, always remember that e-mail is transmitted as plain text across the internet and should always be encrypted.

The level of encryption depends on both regulatory requirements and what your business does. HIPAA / HITECH, Sarbanes Oxley, and government regulations all have similar, and, because of highly publicized incidents like the one outlined above, merging requirements.

Protect yourself now. Check the status of your e-mail encryption and make certain you are running TLS on your mail servers – as a very MINIMUM requirement.

You can check your e-mail server's TLS capabilities at: http://www.checktls.com/perl/TestReceiver.pl.

Select "CertDetail" from the drop-down box for intensive result reporting.

If you have any questions, please feel free to contact me and we can discuss your e-mail and network security to make certain your business is protected.

Now for the fun part, the actual e-mail intercepted by Anonymous is listed below.

NOTE: Because this has been previously published on the Internet by Anonymous, we decided to keep all of the data exactly as previously published:

======================================
MIME-Version: 1.0
acceptlanguage: en-US
Accept-Language: en-US
Content-class: urn:content-classes:message
Subject: Anon-Lulz International Coordination Call
Date: Fri, 13 Jan 2012 19:21:49 -0000
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: Anon-Lulz International Coordination Call
From: "Lauster, Timothy F. Jr." Timothy.Lauster@ic.fbi.gov To: "Reichard, Gerald A." Gerald.Reichard@ic.fbi.gov,
paul.hoare2@met.police.uk,
Raymond.Massie@met.police.uk,
trevor.dickey@met.pnn.police.uk,
Stewart.Garrick@met.police.uk,
"Gillen, Paul G" paul.g.gillen@garda.ie,
"Gallagher, Colm" colm.gallagher@garda.ie,
pim@nhtcu.nl,
Gea@nhtcu.nl,
michel@nhtcu.nl,
olivier.nael@interieur.gouv.fr,
olivier.moalic@interieur.gouv.fr,
thierry.mezenguel@interieur.gouv.fr,
andre.dornbusch@iuk.bka.de,
peter.ericson@rkp.police.se,
stefan.kronqvist@rkp.police.se,
ulrika.sundling@rkp.police.se,
Jaap.Oss@europol.europa.eu,
valentin.gatejel@europol.europa.eu,
"Helman, Bruce C. Jr." Bruce.Helman@ic.fbi.gov,
"Sporre, Eric W." Eric.Sporre@ic.fbi.gov,
"Buckler, Lesley" Lesley.Buckler@ic.fbi.gov,
"Geeslin, Robert C." Robert.Geeslin@ic.fbi.gov,
"Plunkett, William R." William.Plunkett@ic.fbi.gov,
"Roberts, Stewart B." Stewart.Roberts@ic.fbi.gov,
"Brassanini, David" David.Brassanini@ic.fbi.gov,
"Stangl, Christopher K." Christopher.Stangl@ic.fbi.gov,
"Patel, Milan" Milan.Patel@ic.fbi.gov,
"Ng, William T." William.Ng@ic.fbi.gov,
"Adams, Melanie" Melanie.Adams@ic.fbi.gov,
"Culp, Mark A." Mark.Culp@ic.fbi.gov,
"Arico, Nicholas J." Nicholas.Arico@ic.fbi.gov,
"Tabatabaian, Ramyar" Ramyar.Tabatabaian@ic.fbi.gov,
"Penalosa, Jensen" Jensen.Penalosa@ic.fbi.gov,
"Bales, Will" Will.Bales@ic.fbi.gov,
"Burton, Kevin C." Kevin.Burton@ic.fbi.gov,
"Nail, Michael A." Michael.Nail@ic.fbi.gov,
"Grasso, Thomas X." Thomas.Grasso@ic.fbi.gov,
"Thomas, Christopher T." Christopher.Thomas@ic.fbi.gov,
"Caruthers, John" John.Caruthers@ic.fbi.gov,
"Phoenix, Conor I." Conor.Phoenix@ic.fbi.gov,
"Hunt, Chad R." Chad.Hunt@ic.fbi.gov,
"Willett, Bryan G." Bryan.Willett@ic.fbi.gov,
"Patrick, Kory D." Kory.Patrick@ic.fbi.gov

All,

A conference call is planned for next Tuesday (January 17, 2012) to discuss the on-going investigations related to Anonymous, Lulzsec, Antisec, and other associated splinter groups

The conference call was moved to Tuesday due to a US holiday on Monday.

Date: Tuesday, January 17, 2012
Time: 4:00 PM GMT=20
BridgeTN: 202-393-2430
Access Code: 6513211#

Please contact me if you have any questions.

Regards,
Tim

SSA Timothy F. Lauster, Jr
Federal Bureau of Investigation
202-651-3211 (w)
202-651-3193 (f)

Protect your e-mail server today

- ENCRYPT YOUR COMMUNICATIONS!

======================================

Network Bastion

03 December 2013

FBI Notifies Businesses to be aware of "Man in the E-Mail" Scam

Man-in-the-E-Mail’ Fraud Could Victimize AreaBusinesses

Dec. 2, 2013

06 February 2012

Anonymous vs the FBI . . .