Bank Notes

by lg0p89

It's a Wonderful Day in the Neighborhood... To Go to a Fake Website

The following may or may not be based on actual events.  This is intended only as an educational tool.

At the bank I work at presently, there is the usual firewall, Intrusion Detection System (IDS), and Intrusion Prevention System (IPS) in place in addition to other measures to prevent the deviants.

While sitting at work at ye olde bank in mid December 2012, a quarantined email message popped up on the system.  This was just before lunch - imagine that.  This actually is unusual.  There is maybe two a year that get to this point, so, from a ratio analysis, this is a significant event.  Naturally, since this was out of the ordinary, I took notice and gave this a bit more attention than the normal email.

The report itself was very bland, merely stating the minimal amount without any details.  The only thing I knew at this point was an email to me was quarantined.  The reason was there was an attachment type policy violation.

This piqued my curiosity as I was pretty sure what was to come.

The actual attachment was: Recent_Activity.exe

Upon seeing this information, the issue was obvious.  The email was not opened in the operating environment, but was viewed in the quarantine area.

The body of the email stated:

As part of our security measures, we deliver appropriate monitoring of transactions and customers to identify potentially unusual or suspicious activity and transactions in the American Express online system. Please review the 'Suspicious Activity Report' document attached to this email. Your Card-member information is included in the upper-right corner of this document to help you recognize this as a customer service e-mail from American Express.  To learn more about e-mail security or report a suspicious e-mail, please visit us at www.americanexpress.com/phishing. Thank you for your Cardmembership. Sincerely, Tasha_Dennis Tier III Support American Express Account Security Fraud Prevention and Detection Network

The email appears to be valid.

It lulls you into a false sense of security (as any good social engineering would) with the Amex symbol, the person's name and department they work in, and the Amex website for phishing attacks.  After all, it is not logical for a phishing attack to list the alleged company's phishing warning site.  This must be a valid website (as read by the average user).

If you simply glanced at who the email was from and the body of the email, you might believe this was valid and authentic.  Well, there are a few items that would raise the big 'ole red flag.

First, the email is intended for a single person (as it is read).  After all, the attachment was for a "Suspicious Activity Report," which would need to be for a person.  The distribution was actually to eight people.  A bit strange.  Also, all eight people work at the bank, but in different areas.  The eight people also are higher up in the organization (you can tell by their titles) and not tellers, so their access to sensitive data is greater.  It appears as though the email addresses were harvested from the bank's annual report, which listed the employees, their position in the bank, and their email.  This specific issue has been addressed with management - to no avail.

The attached file was a EXE file.  This is not normal.  The file with a suspicious activity report would be a PDF and wouldn't need to be a ZIP file or EXE.  For what they were sending, an EXE file would be highly suspicious and worrisome.  There was no reason to have an EXE file in the email.

Also, the bank does not use Amex for the corporate cards.  Most use one of the other two primary cards in use (MasterCard or Visa).

Last, but not least, is something rather odd with the sender.  The sender did appear to be from Amex, but this was spoofed.  The sender actually was message@securebank.com.

If you receive an email that does not apply, e.g., an update on your Amex card when you don't have one and your corporate card also is not Amex, there may be an issue.  Don't give in to the natural curiosity urge to open this email.

Instead, question authority.

Look at how many recipients there are for the "personal" email.  If it doesn't make sense, there is probably an issue.  Don't press the button.  Please use this as a learning experience to teach your friends and staff what to look for.

Does Every Cloud Have a Silver Lining?

This is written more for the small- and medium-sized business ("SMB") needs.

Cloud, cloud, cloud, cloud.  Week after week, it seems as though there is at least one story in one of the industry journals about the cloud.  Given my and our interests, I tend to focus more on the security aspect of this.  With any project, there are the positive and negative aspects to consider.  There is no yellow brick road.  There are two camps: the group that wants to keep the security function within the business and the group that wants to have this security in the cloud.

The service providers would like all of the company's security aspects in the cloud, as it brings everything under one roof and subsequently increases their revenue.  If I did not know better, I would think they were being altruistic.  Certain portions of the security are handled on an acceptable level in the cloud, e.g. email.  However, the network security should still be handled on-site.  The amount of confidential data processed and stored by businesses and banks can be massive.  Couple this with the amount of potential liability from the clients whose data would be compromised and the seriousness is intolerable.  There also is the risk of the data moving from the site to the cloud, adding a new avenue of attack and risk.  At the local level, the next generation firewall and IPS are perfectly engineered for the local use.

From a purely operational slant, the command and control at the local level simply makes more sense.  The local network administrator ("N/A") is able to monitor the updates quicker.  As the N/A arrives at work, the N/A can take a quick look at any updates and see what needs to be pushed more quickly than others.  This is much more like a triage in a hospital.  Also the N/A does not have to wade through the 300+ emails that came in overnight, as may occur with a provider.  There is a great disparity between the number of emails received at an SMB and a global cloud service provider.

With local control, there is a quicker response for updates and patches.

For example, the N/A receives an update or patch during the work day.  The N/A can review the update or patch to analyze its impact, if any, and how serious this is.  With this process at the local level, the patch management does not have to get the push approved through two or three layers of management.  The endgame also has to be reviewed.

Say a breach occurred.  Any breach would carry an immense amount of potential liability and also a massive hit to the community rapport.  For an example to think about, let's look at a small community bank.  There is a security breach as the data is transferred from the site to the cloud.  This naturally consists of the client's name, address, Social Security Number, deposit and loan numbers, and balances.  There is everything you need to assume the person's identity except for a physical signature.  This could be social engineered, but that is another story.  Once the clients are notified of the breach, they wonder, as any of us would, how safe their personally identifiable information really was, and how safe, if at all, their money will be.  The clients would quickly and assuredly begin to move their business (a.k.a., money) to other institutions.

In summary, security is one function that should be handled locally at the business for the SMB.  Since it is easier to offload this onto a service so there is one less headache, don't do it.  You may never have an issue, but if you do, the next step is to brush off the resume, as you now have a resume updating event.

Not every cloud has a silver lining.

A Little Bit of Research Helps Immensely...

I write mostly about social engineering.  This is intentional.

This area just seems to be a bit more interesting than the others.  Coding malware or a virus ends up in a rather direct attack.  The person targets a company and sends these along hoping for the person at the other end to bite on the hook (open the email and click on something not so nice).  Social engineering requires a certain level of nuance and being slick to accomplish the task.

It was another day in the neighborhood at the local bank.  A call, much like any other call, came in.

"Hello, this is _____ from EMC."  The droll IT manager that fielded the call simply responded, sounding like Lurch from The Addams Family, with "Yes."  The EMC rep responded with "I see you are using some of our products."  Along comes the same response from the IT manager "Yes."  The EMC rep asks "Can you tell me what you use?"  After a brief hesitation, explanation to follow, the response was "No, you should be able to see what we use."  Still more hesitation.  The EMC rep slowly responds with "Well, we are working from our back-up now and can't access it."  From this point forward, the conversation was curtailed abruptly.

As a disclaimer, the IT manager is not a rough person with too little time and too many projects.  He is a great person with too little time and too many projects.  The short answers were intentional.

Social engineering is not a full frontal assault like a Distributed Denial-of-Service (DDoS).  You get a little information here and there.  After enough data in bits and pieces has been gathered, you have a better feel for their OS and other systems, which then gives you a better road map for the attack.  The strike on the target then is rather specific in the tools that are to be used.  We have been trained to not give more information out to people unless you specifically know the person.  We know not to give the information out to anyone just calling in.

The second red flag was the EMC rep not knowing what the bank was already using and purchasing.  Even if the rep was using a back-up, he still should have been able to see what the bank was using.  This was pretty blatant.

The third strike, I mean red flag, was obscured as the call came in.  The Caller ID did not show the number and the ID showed not as EMC, but as "Out of Area."  The number could at least have been spoofed.

It is so much better to be conservative and not divulge private information they should know anyway.  It would not have taken much for a person to simply answer the questions, but this would have provided far too much information, which would have been a benefit to the "EMC rep."

Thought for the day: "Via trita est tutissima."  (The beaten path is the safest.)