Showing posts with label Targeted attacks - about. Show all posts
Showing posts with label Targeted attacks - about. Show all posts

Sunday, June 5, 2011

Six ways sensitive data finds its way to personal email accounts

    There has been a lot of speculation recently on how much sensitive data a hacker can find on personal email accounts, considering it is against the rules in most places to use personal accounts for work . Although there are strict rules for classified messages and documents, the intruders are often satisfied with just sensitive or just informational messages for building the picture they need. While I don't know how strict the rules are at the White House, the following behavior is common for at least some US Government offices and for many companies. This information is from my own knowledge, as well as accounts of people working for the US Government, military, as well as Fortune 500 companies, non-government research institutions, and other places.

I am sure you will find none of these scenarios surprising, they all are very common.
   
SIX WAYS SENSITIVE DATA FINDS ITS WAY TO PERSONAL EMAIL ACCOUNTS
    1.   Google Apps accounts are often created in addition to corporate/work mail to alllow easy document sharing between different companies  - for one project, or as a permanent setup
    2.   Employees create autoforwarding of all work emails to their personal accounts for easy reading on personal mobile devices (not everyone has work-issued mobile device)
    3.   Employees, regardless of their employer, need to communicate with people who work elsewhere. They cannot control whether their recipients use free webmail or what they do with their mail - and their recipients can be targeted
    4.   Employees often trust personal webmail more than their work accounts for privacy reasons. They know their work mail is heavily monitored, archived, filtered and they sometimes need to say something to each other "off the record". This may include work related topics, their supervisors, etc.
    5.   Employees, especially when traveling, often manually forward selected messages from work to personal accounts. This is  because it is easier to check personal accounts rather than logging in with smart cards, RSA keys, VPN just to refer to a few things they may need for work during their travel or work at home period.
    6.   Employees may forward mail to personal accounts before leaving their job - some places allow auto-forward and in others you can do it manually. People forward contacts or important messages that they may need after they start a new job

Related posts : Targeted attacks against personal accounts of military, government employees and associates

Sunday, January 24, 2010

Weekends

I noticed a while ago, and this trend continues, that our creative senders take weekends off. Mailings stop on Friday afternoon and do not resume until 8-10 pm Sunday (which is already Monday is some parts of the world). The greeting cards and banking scam artists take no days off - maybe because they are not salary men?
I hope you all are enjoying your weekend
M
 

Wednesday, November 18, 2009

Heap Spraying with Actionscript by FireEye and From Targeted PDF Attack to Backdoor in Five Stages y McAfee



Excerpt
FireEye Malware Intelligence Lab
Julia Wolf @ FireEye Malware Intelligence Lab

Heap Spraying with Actionscript

Why turning off Javascript won't help this time
 Introduction


As you may have heard, there's a new Adobe PDF-or-Flash-or-something 0-day in the wild. So this is a quick note about how it's implemented, but this blog post is not going to cover any details about the exploit itself.


Background Summary


Most of the Acrobat exploits over the last several months use the, now common, heap spraying technique, implemented in Javascript/ECMAscript, a Turing complete language that Adobe thought would go well with static documents. (Cause that went so well for Postscript) (Ironically, PDF has now come full circle back to having the features of Postscript that it was trying to get away from.) The exploit could be made far far less reliable, by disabling Javascript in your Adobe Acrobat Reader.


But apparently there's no easy way to disable Flash through the UI. US-CERT recommends renaming the “%ProgramFiles%\Adobe\Reader 9.0\Reader\authplay.dll” and “%ProgramFiles%\Adobe\Reader 9.0\Reader\rt3d.dll” files. [Edit: Actually the source for this advice is the Adobe Product Security Incident Response Team (PSIRT).]


Anyway, here's why… Flash has it's own version of ECMAScript called Actionscript, and whoever wrote this new 0-day, finally did something new by implementing the heap-spray routine with Actionscript inside of Flash. More
II. http://www.avertlabs.com/research/blog/index.php/2009/09/14/from-targeted-pdf-attack-to-backdoor-in-five-stages/

McAfee Labs Blog
Excerpt
          From Targeted PDF Attack to Backdoor in Five Stages
          Monday September 14, 2009 at 12:33 pm CST
          Posted by Dennis Elser

 As reported by Adobe in July, a Flash vulnerability is being actively exploited by targeted attacks against Adobe Reader. Yes, embedding Flash movies in PDF documents is supported in Adobe Acrobat 9. The idea of allowing Flash movies to be displayed within PDFs isn’t bad if you like your documents spiced up with a bit of interactivity or training videos. From a security perspective, however, this poses yet another attack vector for criminals to take control of vulnerable systems. As history has shown, complexity and feature richness go hand in hand with remotely exploitable vulnerabilities. It is unfortunately no different with this latest PDF feature.


The exploitation of this vulnerability continues. Below are screenshots from one such malicious PDF document, discovered in a targeted attack this week. The attack contains several compressed streams and at least two embedded Flash movies. The first embedded Flash movie is clean, the second 6exploits CVE-ID 2009-1862, which causes a memory corruption and allows an attacker’s code to execute. Underneath the compression layer, JavaScript code is embedded in the PDF document. This code fills heap memory with the attacker’s shellcode. Apart from the PDF acting as an additional obfuscation layer around the exploit, the JavaScript code, once unpacked, contains another function that attempts to evade detection. More