Email intercepted by criminals?!

Hi guys

We've had a major possible breach over at our side.

One of our accountants ended up sending an email to a client with our bank details etc. Few days passed and our accountant asked where the money was and was told the client had wired it to them.

Anyway after checking, the client showed a screenshot of the account details that they were sent by our accountant. When we looked, the account details had been manipulated!! They were totally different.
I am trying to investigate whether it was our emails that were intercepted or the client.

I have some tools which I can install, but we are within a guarded firewall environment. The firewalls are Watchguard's and we have got all of the APT and IP intrusion selected. We are in a domain environment. We use Messagelabs to protect our perimeter from spam emails etc.

In terms of intercepting the email, is it possible that our account has had some sort of keylogger or malware installed that feeds information back to the criminals?

Thanks for helping
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The first thing i would check is messagelabs. See if they can get you a copy of the email that your accountant sent. Also, see who your client uses and see if they can do the same thing. we use mimecast and we have the ability to search all our emails.

If you search message labs and find the original email from your accountant and the bank details have not been tampered with, then you at least know that it *might* not be on your side.

The hard part will be getting the original that the client received. The other problem will be that it was a few days beofre you found this out. A lot can happen in a few days.
Brian BEE Topic Advisor, Independant Technology ProfessionalCommented:
I'll just throw in that you should see if the client actually received that email from your company. They will have to check message headers, but also both your company and their should check firewall and email logs to track what that message was delivered from. Was it your company or someone else?
Dr. KlahnPrincipal Software EngineerCommented:
The accountant involved needs a savage kick in the posterior, and your IT Security people need to have a long talk with the Accounting department.

Anyone who would send bank account information by plaintext email should not be allowed to deal with money.  That kind of information should only be given by telephone after determining the person on the other end of the line, by certified mail, or by email encrypted with the intended recipient's PGP or GPG public key.
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

The other company also needs to be kick kicked in the rear.  They should have called and verified the data before sending any wire.  Emails have always been an insecure method of sending information, especially sensitive information.
Blue Street TechLast KnightCommented:
Hi Yashy,

This is a serious security event and should be treated accordingly. I'd clean house and perform a full stack security sweep/inspection...make sure all your ducks are in order on your side of things.

Make sure your environment is configured the way you think it is (selecting security features is far from proper configuration of them) and that all machines are infection free. AV (AntiVirus) = near real-time infection prevention; AM (AntiMalware) is for post infection remediation (infections that were undetected or otherwise got through). Scan with User education is always important but most users don't care because there is really no skin in the game for them or penalties for violating the AUP (Acceptable Usage Policies), which rarely exist, are written well, nor are enforced. And since we know users are the weakest links in our security models this means we need to design mechanisms to ensure that even if users do dumb things the architecture is in place will thwart/correct that behavior. Nothing in terms of PII (Personally Identifiable Information) should ever leave your company without strong encryption let alone sensitive info aka financials, etc. and some of the data should never leave the company under any circumstance. DLP (Data Loss Prevention) obviously seems to be a big hole in your security architecture, which can be plugged by designing policies within the products you already have.

Messagelabs can prevent data loss through their Content Control policies. You should create policies for all PII, & sensitive info such as SSN, Driver's License #'s, Banking Account #, Credit Card #, etc. so that when these types of info are flagged they are blocked & reported.
Messagelabs also allows you to create PBE (Policy-Based Encryption) if you configure this, all PII & Sensitive info can now be automatically be encrypted, transmitted & report generated, instead of just being blocked.

Using both of these mechanisms you can design a structure where sensitive info that needs to go outbound is automatically encrypted and info that should never go out will be blocked.  Both actions should be logged & reported for posterity.

If you work exclusively with some companies where it doesn't make sense to Federate them but you need to exchange sensitive data regularly then setting up S/MIME between both mail servers would be beneficial since it would encrypt all messages between the companies by default if configured properly. This way decryption would occur on the mail servers rather than on each client's machine.

As an Email Best Practice, you should also setup an integrity triad: SPF, DKIM & DMARC.
SPF - shows an authoritative list of servers that are allowed to send mail for your domain/s.
DKIM - verifies that the messages’ content are trustworthy, meaning that they weren’t changed from the moment the message left the initial mail server. This additional layer of trustability is achieved by an implementation of the standard public/private key signing process.
DMARC - utilizes & empowers both SPF & DKIM by stating an explicit policy to be used in the event either the aforementioned tools' policies are violated, & includes reporting functions.

Signing emails with DKIM & enforcing the signature with DMARC will help alleviate many of these types of attacks by preventing an adversary from modifying intercepted emails. The adversaries don't have access to the legitimate DKIM private key, so when the receiving server checks for the presence of DKIM & checks the email signature, if the email was modified in any way, the receiving server will reject it. DMARC also helps in detecting attacks against your domain by allowing you to supply an email address where you will receive a statistical report of how many emails have failed the DKIM signature check.

If DNSSEC is available for your Public DNS provider you should configure it. Once DNSSEC & DANE are widely adopted & enforced, DNS MX record hijacking attacks, DNS poisoning, DNS spoofing attacks, etc. will cease to succeed. See below how this affects your situation.

In terms of intercepting the email, is it possible that our account has had some sort of keylogger or malware installed that feeds information back to the criminals?
Again, the attack vector is pretty is it possible...yes! However, I don't see how keyloggers would come into play with this type of attack unless the entire email was fabricated by an adversary who compromised the accountant's mail account. Since you said you compared the bank account numbers and they were different you need to determine where the attack occurred: either in your network, the public network (in transit) or the recipient's. Compare the email headers & email bodies' sources on both sides. You need to have cooperation with your recipient's company to properly investigate this. The method of the attack could have originated from a variety of forms including DNS MX record hijacking attacks, DNS poisoning, DNS spoofing attacks, DNS Rebinding attacks, TLS downgrade attacks, Spoofing attacks, MitM (Man-in-the-Middle) attacks, Malware, etc. From my understanding the body of the email content changed so the attack would have been separate from the actual manipulation of the email body contents, meaning ATP would not have seen the manipulation because it is not a malicious threat - its a benign textual modification from the standpoint of a security inspection engine. However, the breach/attack on the other hand would have been executed in a manner where ATP should have seen it locally provided it is configured correctly. Assuming you have your Gateway configured correctly I'd suspect the attack occurred in transit or on the recipient side. If that is the case you company is still at fault for sending sensitive data in plaintext.

With regards to inspecting the email headers specifically look into the Submitting/Receiving Hosts and their corresponding Timestamps & Delays per hop for all. If there is a spoofed submitting host, host that should not belong in the hops, and/or there is a long Delay in the Timestamp between hops; these can be (delays are not always indicators) an indicator of MitM attack.

Depending upon how much money was transferred I wouldn't rule out an inside job on either your side or the recipient's side. Modification of emails once delivered is easy to do and extremely benign in nature.

Let me know if you have any questions!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
@Dr Klahn:

Unless I have misunderstood, I have to completely disagree with your post above.

It is very normal to give out bank account details.  Every company does this, including, for example, utility companies - if you check your utility bills it is highly likely that their bank account details are on there, and will also be available on their web site.

The accountant has done nothing wrong or out of the ordinary.

Blue Street TechLast KnightCommented:
@Alan, it could possibly be a difference of country...possibly. In the US there is no bank account info or any sensitive info of any kind (aside from name, address & utility account#) on utility bills. Banking regulations & PCI-DSS prohibit such info from being recorded on statements.

I won't mention the methods but all an adversary needs to do an illegally debit a bank account electronically and drain it over a relatively short term cycle is the name, phone#, address, bank routing/ABA# and bank account#. A little stalking (physically or digitally) would supply all the info needed provided that banking details are shared.

In the US this accountant's act would be considered negligent, reason for termination, and ultimately a guaranteed insurance claim for many companies who understand the risks associated of what the accountant did.

In the EU, the GDPR (General Data Protection Regulation) redefines a data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored otherwise processed”. The GDPR also applies to US companies that do business with or have offices in the EU.

I guess its possible there is a difference in country.  What I am saying would certainly apply in the UK, New Zealand, and Australia at least, and I would imagine most other places.

This is an example from NZ:

There is no risk at all with giving out account details to a customer so they can pay you.

If you don't have bank account information, how do you make a payment in the US?

Blue Street TechLast KnightCommented:
Interesting. So if you are asking about how companies request for payment, they provide you with your account number and their web address, toll-free telephone number, or their mailing address to send payment. All forms are relatively secured and by phone you must authenticate before payment or any account details are shared. Even online banking/bill pay only requires payee name, mailing address, and telephone #.

I would suspect that Spark bank account musty be a special "deposit-only" account meaning all debits are automatically blocked.

But in this case the term "wired" was used which implies a specific wire transfer info was supplied. Again, not sure if this is specific to country or not but in the US the bank account Routing # is different for deposits than it is for money transfers which require either an ISO 9362 BIC/SWIFT code for international money transfers or an ABA (American Banking Association) routing number for wire transactions. So, each code/number is very explicit in nature.
One of the biggest things is never to transmit that type of information over something like an insecure email. It's already been mentioned that encryption should be used if email has to be utilized. Otherwise, look at other means like certified mail. Regardless, there should exist a standard organization policy around exactly how this would work.

I am more than willing to bet there is an issue at the client's end, granted this is something you should clearly be investigating on your end as well (obviously others have mentioned this already). Ideally IT at the client's end is willing to share data with you (like headers and so on), which would at least lead to the beginning of how this came to be. And for your client's sake, I hope this has been reported to their bank and proper authorities.
YashyAuthor Commented:
Guys, I genuinely appreciate all of the feedback and input that has come this way. It does make for a very insightful read. Dr Klahan, your comment did make me laugh, although I did not know it was an issue to send out those details. We have secured Messagelabs to prevent any credit card of any sort being submitted so it is flagged.

Bluestreet Tech, I need to enable SPF, DKIM and DMARC for the domain name record. It's only been done on the Messagelabs side, but that's just not enough if the Domain name itself hasn't got the txt records added with those records against it. You are right, that sending sensitive information like that in plaintext is just plain stupid and we need to re-consider this strategy going forwards.

So, our investigations are showing that the recipient has a 'Btconnect' email address and that person does not have a proper I.T department or security. My guess is that our accountant's email was received into this mailbox, the persons monitoring this mailbox received it and then spoofed the email by sending it again to the same person but as though it came from us.

We do educate our users and have actually got decent security around the perimeter, nevertheless we could still be talking about our end having an issue. Either way, this is an on going investigation and I will tighten up the Messagelabs security features
Blue Street TechLast KnightCommented:
We have secured Messagelabs to prevent any credit card of any sort being submitted so it is flagged.
Be diligent to make sure they are not only flagged but action is taken, either thwarting or forced encryption by the feature I cited in my previous comment.

I need to enable SPF, DKIM and DMARC for the domain name record. It's only been done on the Messagelabs side, but that's just not enough if the Domain name itself hasn't got the txt records added with those records against it.
You are correct, it all needs to be done on your doesn't matter if you email is hosted or on-premise or relayed to MessageLabs, your domain is where all these mechanisms (SPF, DKIM & DMARC) need to be configured ultimately. A great DMARC manager & reporting engine is

Best of luck with it all! Let me know if you have any other questions!
Blue Street TechLast KnightCommented:
Glad I could help...thanks for the points!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.