Earlier this afternoon, the Mozilla Foundation released an update for their Firefox web browser to correct a number of security issues. Most of the issues corrected in this release are listed at a critical severity. As such, organizations should consider pushing the updated web browser in the near future.

If you do have a web server, and browse your logs regularly, you will probably find regular probes for various web applications, even some that you don't even use. In many cases, these probes are looking for very common web applications with well known vulnerabilities. Most of the time, the vulnerabilities are old, and a patched version of the application is available. But web applications can be hard to patch and are usually not included in normal patch routines. These web applications are also often customized and the customization makes patching harder. To make things even more complex: It is not always the application itself, but a plugin that is causing the problem.

What I am trying to do here is to assemble a list of the most dangerous web applications. We will use a survey, the 404 project and any other data people may have to rank them. Once these applications are identified, we will try to collect hardening guides to help you run these applications securely.

Please see the survey here http://isc.sans.edu/survey/4 and consider participating to get this project started. The survey will just be one source of data we will be using.

With the start of a new school year right around the corner, there is usually an uptick in phishing scams directed toward Academia. As has been reported many times over the past several years, the number of new faculty and students in Higher Ed, coupled with the limited amount of access controls in place on many systems, makes this an optimal time for the scams to be directed at our campuses.

I am a huge advocate of educating these new members of our community concerning the protection of their user credentials. For my environment, I am actively making the case that a personalized message be sent to each and every individual in our organization to educate (or at least remind) about how we conduct our business involving password changes and the use of credentials in our environment. By in large, many of our phishing scam victims were blissfully unaware of the value to their account credentials to an attacker. Or they just assumed an email claiming to be from the university sent to their university email account must be legit.

A number of years ago Johannes presented 6 Simple Steps to Beat Phishing [http://isc.sans.org/presentations/phishthat.pdf ]. These steps are still very valuable in the effort to limit the exposure. Many organizations have conducted "spear phishing" attacks against their own users as a way to raise security awareness. This type of penetration testing, or ethical hacking, likely does has some impact on the overall security posture of your users but I expect that your mileage may vary based on organizational culture.

Unfortunately, there will always be a small number of users who will fall victim to phishing scams, no matter the amount of training, education or other preventative measures you take.

So what things can you do to recover from a compromised user account. In most of the phishing scams targeting my institution, the intruders were mostly focused on using the account to send out junk mail or other scams.

Junk Email/Scam Attack

Lock out the user account or reauthorize their ability to authenticate.

Clean out mail queues to remove any messages which have not been delivered

Monitor SMTP logs to identify RBLs which may be blocking campus mail servers.

Reverse any changes to the compromised user account, such as Forwarding Address, Formal Name, signature, Reply-to: and similar.

Review logs to identify the source IP addresses of the intruders, and identify any other compromised accounts.

Communicate the abusive behavior to the Net Block in question, and block the IP range if appropriate.

Review logs to identify any tell-tale addresses which may be used by the intruders to test an account as functional. These addresses are an excellent early warning system to identify accounts which are about to be used in an attack.

If available, review the content of any phishing scams directed at your organization for phrases, URLs or other details which may be included in spam filters.

And, obviously, communicate with the user of the account to change their account credentials to prevent unauthorized use.

So what other things would your recommend as part of the recovery of the intrusion? Are there are other steps that need to be followed should the intruder access other resources other than email services?