4 ms·
> Salt your password hashes As brown9-2 mentions in his reply, it was a Windows Domain Controller > Train your staff NOT to open attachments from unknown sour
by nikcub 14y ago
> Salt your password hashes
As brown9-2 mentions in his reply, it was a Windows Domain Controller
> Train your staff NOT to open attachments from unknown sources
Spear phishing attacks are more sophisticated than that. They aren't sending .EXE files. The two most common attachments are RTF[0] and PDF[1], or a link in the email body to a website that will attempt a drive-by download.
These emails are composed in a way to make them look innocent (for eg. 'Twitter Password Reset Request', 'New Amazon.com Order', or an email from a new source, etc.).
It is also likely that at this level of sophistication that there are 0day exploits involved.
Attackers can send hundreds of spear emails over weeks and months, they just need a single click from one user to get their foot in the door.
> quarantine any attachment (inbound or outbound) that isn't of a type defined in a very strict white list
As mentioned above, the attachment types are RTF, PDF and XLS - and much more common is a link in an HTML email.
> make use of the software firewall on the PC's
The command and control servers send commands to ordinary looking websites using HTTPS. If you read the analysis of Flame or Stuxnet you will see the lengths that the designers went to to obfuscate this traffic.
This analysis[2] describes what the C&C servers looked like for Flame. The admin panels make no mention of bots or worms, it looks like any other intranet site.
It is really difficult to defend against these types of attacks. An attacker only needs 2 or 3 decent exploit writers to come up with a unique attack vector and a custom trojan tailored for the target. Also, time is on their side and they only need a single hit while you need to find and shut down all of the attempts.
[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3333 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3333
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4363 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4363
[2] http://www.securelist.com/en/blog/750/Full_Analysis_of_Flame_s_Command_Control_servers http://www.securelist.com/en/blog/750/Full_Analysis_of_Flame...
- corford 14y agoRe: Windows Domain Controllers - I wasn't aware they didn't have the ability to salt hashes (I last used domain controllers and active directory back in the Win2K days). I could be facetious and say "move to open ldap, samba 4, zarafa and an open stack" but I realise that isn't being very helpful :) Re: spear phishing attacks All it takes is a bit of training and common sense to significantly reduce the effectiveness of this vector. Examples: 1). Remove Flash and, if possible, Java from all the desktop PCs and work laptops. [0] 2). Use a non-Adobe product for reading PDFs 3). Standardise on one browser (e.g. Chrome), force all users to use it and have someone in IT be responsible for tracking all security announcements from the manufacturer. 4). Ban browser addons 5). Train staff to hover over any link in an email and verify where it's going to before clicking it (and to be especially vigilant if the url purports to be from a well known website i.e. amazon, twitter etc) 6). Ban staff from clicking on any link rendered by an url shortening service. 7). Ban staff from opening any attachment from a new/unrecognised email source (regardless of file format). 8). Re-work your provisioning, network architecture and file storage setup so that it becomes quick and painless to regularly (even randomly) format user's machines and install a clean image. 9). If feasible, configure all user's email programs to render emails in plain text and encourage staff to avoid checking their private accounts on work provided machines (especially high profile users). 10). Ban users from connecting non-work appliances to the network. Use MAC filtering if you have to enforce this. Re: firewalling That's why I said block everything going out and only white list a very limited number of _processes_ not ports. Do it via the native software firewall or something like TinyWall. [0] If a user really needs either of these, they can apply for special dispensation and IT can (after making sure the user is security trained) give them a locked down virtualbox instance they can launch from the desktop. If possible this could also be scripted so that it gets deleted every day or week and re-provisioned from a "gold" vm image. Some attacks would still make it through despite the above but that's life. At the very least it raises the bar needed for a successful attack, making vanity hacks (like in the case of the latest one on the NYT) less common.