You’ll never guess where Russian spies are hiding their control servers

Enlarge (credit: Instagram)

A Russian-speaking hacking group that, for years, has targeted governments around the world is experimenting with a clever new method that uses social media sites to conceal espionage malware once it infects a network of interest.

According to a report published Tuesday by researchers from antivirus provider Eset, a recently discovered backdoor Trojan used comments posted to Britney Spears's official Instagram account to locate the control server that sends instructions and offloads stolen data to and from infected computers. The innovation—by a so-called advanced persistent threat group known as Turla—makes the malware harder to detect because attacker-controlled servers are never directly referenced in either the malware or in the comment it accesses.

Turla is a Russian-speaking hacking group known for its cutting-edge espionage malware. In mid-2014, researchers from Symantec documented malware dubbed Wipbot that infiltrated the Windows-based systems of embassies and governments of multiple European countries, many of them former Eastern Bloc nations. A few months later, researchers at Kaspersky Lab discovered an extremely stealthy Linux backdoor that was used in the same campaign, a finding that showed it was much broader than previously believed. Turla has also been known to use satellite-based Internet connections to cover its tracks. In March, researchers observed Turla using what was then a zero-day vulnerability in Window to infiltrate European government and military computers.

Read 6 remaining paragraphs | Comments

How To Plan For Security Incident Response

Planning for the seemingly unlikely event of a severe cybersecurity incident seems unwieldy and time-consuming for many organizations. But consider this: According to the Ponemon Institute, 90% of organizations that go offline due to a cyberattack shutter their windows in the following two years.

A strong incident response plan is clearly a necessity these days. From threats like the recent WannaCry ransomware attack to the Google Docs phishing scam, there are a number of ways a security incident can unfold at your organization. Having a tested incident response plan in your back pocket can make the difference between a swift recovery or a high stress situation where every minute the incident remains unresolved results in more financial or reputational damage.

There are three fundamental components that will help ensure that your company’s incident response plan is a success.

Define security incidents and likely scenarios. While all IT service incidents deserve swift identification and triage, security incidents – which often have malicious intent – must be identified and tackled even more quickly. For example, a server at your company is unexpectedly rebooted in the middle of the day. This could be caused by an innocuous outage or it could be something far more sinister. Perhaps an unknown third party has installed a rootkit, and the system is restarting so changes can be applied allowing that third party unauthorized system access.

As you think through the possible incidents and scenarios, think about security best practices that can be circumvented (such as authentication) and cues from the news as your guide to recent, real threats (such as phishing and ransomware attempts).

What experts and stakeholders will be mobilized to handle all of the security, privacy and legal implications when a security incident occurs? How will your organization recover from a successful phishing attack? How will your organization cope with news of a severe data leak? What will you do once hackers are booted from your system? Play out each possible incident and how you would realistically respond. From there, write your incident response plan and procedures accordingly.

One resource to get you started is a generic incident handling procedure template from the Computer Security Incident Response Team. This is a good baseline document, but you’ll need to tailor it to meet your organization’s specific needs.

Communicate and train on the plan. Once your plan has been developed, reviewed and approved, the roles and responsibilities everyone plays should be disseminated to all relevant parties. An incident can be detected by anyone with the right “visibility.” Your IT team is obviously on the front lines for incident detection and response, but many people in your organization could end up identifying a problem first. Maybe your marketing team, who owns the website, notices some highly suspect traffic one day or encounters issues with the server. Do they know where to go? Any of your end users could click on a link in an email and realize afterwards that it seemed suspicious. Do they know who to call or email?

A hands-on and interactive way to ensure that key stakeholders know what role they play in incident response is to conduct tabletop exercises. A tabletop exercise is usually led by a security subject matter expert who walks a team of diverse stakeholders (from IT, security, management, legal, HR, etc.) through an impactful security incident scenario, facilitating the decisions made and providing feedback afterwards on how well the participants were aware of their responsibilities and the company’s policies. Tabletop exercises are one way of doing “red teaming” because they simulate how internal processes will play out if a real security incident gets reported and escalated.

Proactively mitigate your losses. A security incident that turns into a validated security breach can lead to devastating financial or reputational loss. Such losses are not easy to recover from, and in some scenarios, organizations never fully rebound. The Anthem Healthcare breach of 2015 came with a price tag well into the billions of dollars. And the code-hosting service, Code Spaces, went under in the months following its breach.

In addition to putting preventative best practice technical measures in place and preparing an actionable incident response plan, consider building relationships and lines of communication now with relevant government agencies, external legal counsel, digital forensics firms and potentially procuring cybersecurity liability insurance. All of these measures will be things your Board of Directors will and should expect you to have answers to, and communicating with your Board on these matters is an art unto itself.

In a world where it isn’t a question of “if,” but “when” your company may find itself the target of a cyber incident, a detailed incident response plan will be your lifeline to weathering the storm of security incidents in measurable ways. Executed well, it can help you demystify the what-if scenarios, decrease your panic about who will do what and plan through the worse-case scenarios to make sure you have all the experts and resources you need to handle any security incident scenario.


This article was written by Christie Terrill from Forbes and was legally licensed through the NewsCred publisher network. Please direct all licensing questions to [email protected].

The post How To Plan For Security Incident Response appeared first on McAfee Blogs.

How a few yellow dots burned the Intercept’s NSA leaker

Enlarge (credit: Ars Technica)

When reporters at The Intercept approached the National Security Agency on June 1 to confirm a document that had been anonymously leaked to the publication in May, they handed over a copy of the document to the NSA to verify its authenticity. When they did so, the Intercept team inadvertently exposed its source because the copy showed fold marks that indicated it had been printed—and it included encoded watermarking that revealed exactly when it had been printed and on what printer.

The watermarks, shown in the image above—an enhancement of the scanned document The Intercept published yesterday—were from a Xerox Docucolor printer. Researchers working with the Electronic Frontier Foundation have reverse-engineered the grid pattern employed by this class of printer; using the tool, Ars (and others, including security researcher Robert Graham) determined that the document passed to The Intercept was printed on May 9, 2017 at 6:20am from a printer with the serial number 535218 or 29535218.

Read 1 remaining paragraphs | Comments