Security Intelligence Analysis and Insight for Information Security Professionals Tue, 01 Sep 2015 20:53:08 +0000 en-US hourly 1 The Danger in Downplaying Smartphone Security Tue, 01 Sep 2015 15:12:40 +0000 Enterprises can't afford to sweep smartphone security under the rug. In the age of bring-your-own-device, mobile security is essential.

The post The Danger in Downplaying Smartphone Security appeared first on Security Intelligence.

Through direct conversations with business managers and end users, as well as stories from my colleagues in IT, I’ve heard one phrase a thousand times: “I don’t have anything of value on my smartphone.” It’s the main reason (see: excuse) that people don’t put passwords on their mobile devices. Yet I’m convinced it’s a fundamental way of thinking that’s leading to many of the data breaches we hear about.

Smartphone Security Matters

The downplaying of smartphone security risks seems justified. After all, in many cases, they’re seen as mere communication devices rather than computing devices. It can be argued that a good portion of people aren’t even aware of the technology at their disposal, let alone the information being stored that’s facilitating unnecessary risks with smartphones.

The average smartphone today has gigabytes worth of storage potential, often with the option to add more. Virtual private network (VPN) connections are made with these devices. Corporate emails are accessed. Sensitive files are loaded, stored and shared. Mobile apps are downloaded and used as needed.

Imagine the possibilities for data breaches when devices are lost or stolen, used on unsecured wireless connections and even infected with malware. The typical smartphone is just about as powerful as — and has as much or more utility than — modern laptop computers, yet we’re still treating them as novelty items.

Executives Must Take the Lead

The phenomenon of “I don’t have anything of value” comes from all employees, but it’s executives that seem to say it the most. Ironically, these are the people whose phones — and the information stored on them — are at the greatest risk!

Just recently, I heard a C-level executive say, “The phones belong to our users, so there’s nothing we can do about them.” I’ve heard this many times before. It’s as if many business leaders have given in to the perceived reality that users call the shots. Or, just as badly, they view it as something that IT is handling and they leave it at that.

Smartphone vulnerabilities are not just a technical problem for IT or security teams to fix. This is a business risk that needs to be addressed — and enforced — at the highest levels of the organization. Acknowledge the security challenges these seemingly innocuous devices are creating. More importantly, vow to address the issue and then make sure it happens. Be it passwords, a full-blown mobile device management (MDM) system or ongoing assessments, do something about the security of your smartphones before they end up making you look dumb.

The post The Danger in Downplaying Smartphone Security appeared first on Security Intelligence.

]]> 0
C-Suite Spotlight: Sandy Bird, IBM Security CTO Tue, 01 Sep 2015 15:02:41 +0000 IBM Security CTO Sandy Bird provides insight into what he thinks is top of mind for customers right now (hint: advanced threats).

The post C-Suite Spotlight: Sandy Bird, IBM Security CTO appeared first on Security Intelligence.

IBM Security CTO Sandy Bird gives us his insight into what he thinks is top of mind for customers right now (hint: advanced threats), as well as what he’s not hearing about enough. Sandy also talks about the excitement of being in the security industry, the landscape change that is going on now, the cloud and the willingness of organizations to share information when they are breached.

Watch the video:

The post C-Suite Spotlight: Sandy Bird, IBM Security CTO appeared first on Security Intelligence.

]]> 0
Keeping Your Data Safe: How to Build an Endpoint Security Strategy Based on Confidence Tue, 01 Sep 2015 13:32:39 +0000 Is your organization approaching its endpoint security with confidence or fear? Your answer could impact how effectively you prevent data breaches.

The post Keeping Your Data Safe: How to Build an Endpoint Security Strategy Based on Confidence appeared first on Security Intelligence.

I read an article a few days ago in which the author subtly advocated that organizations should adopt a viewpoint based on fear when it comes to security breaches. The basic subtext was something like, “The cyberattackers are coming — run to your bunker!” The truth of the matter is that, in some ways, he’s right; it’s really not a question of if you will be breached, but when.

In fact, according to the IBM 2015 Cyber Security Intelligence Index, the average organization experienced 2.1 security incidents each week, when an incident is a security event that has been reviewed by IBM analysts and deemed worthy of deeper investigation. The study also showed that the incident-to-attack percentage, where an attack is defined as a security event that’s been identified as malicious activity, is on the rise, with the overall ratio increasing from .65 percent to .91 percent. That means cybercriminals are not only getting more prevalent, they’re also becoming more proficient at what they do.

The cost of a data breach is increasing, as well. A recent study from the Ponemon Institute revealed an average cost of nearly $3.8 million for the companies that participated in the project.

But even with these startling statistics, I’d much rather come from a place of confidence than fear when it comes to cybersecurity.

Choose Confidence, Not Fear

So how do you approach a security strategy with confidence instead of fear? First you have to look at the facts and know what you’re dealing with. If your organization is like most, you have a diverse mix of devices — desktops, laptops, servers and more — connecting to your corporate data. Moreover, you probably also deal with the reality of having to manage and secure a constantly changing landscape of devices linked to your data, including rogue devices into which you have no visibility and over which you have no control. That means you can’t quickly identify and respond to threats before widespread damage can occur.

Another potential problem is that in many organizations, IT security creates the endpoint policies while IT operations implements them. That means every new handoff, tool and process between the two teams creates an additional opportunity for out-of-compliance endpoints that can be breached.

It sounds like a scary scenario since every noncompliant endpoint on your system is a potential window into which a cyber burglar can climb. And managing and securing all those endpoints can seem like an overwhelming task.

But overwhelming doesn’t mean impossible, and it doesn’t even have to mean scary. A well-thought-out approach to cybersecurity based on confidence — instead of fear — needs to focus on managing and securing endpoints before, during and after a potential breach.

What to Do With Your Endpoint Security


Clearly, the best protection against threats is to discover and quarantine them before damage is inflicted across the network. This requires intelligence to monitor and report on the status of every endpoint, regardless of type or location, in real time. Any endpoint found to be out of compliance should be automatically remediated and made compliant or quarantined completely before it can infect the broader network.


Security teams are overwhelmed by an influx of vulnerabilities and lack the contextual data to help them prioritize the greatest threats, making it possible for months to pass between the discovery of a vulnerability and the application of a patch. To effectively cut through the noise of millions of security events, companies need to use analytics-based solutions to assess and display vulnerabilities by threat level.


Once a vulnerability is discovered, action needs to be taken quickly on all endpoints, both on and off the network. Any noncompliant or infected endpoints need to be isolated until remediation is complete. The No. 1 factor that helps reduce the cost of a data breach is having an effective response strategy in place, according to the Ponemon study. With real-time, automated processes, endpoints can be disinfected in minutes.

Managing Endpoint Security

A well-structured endpoint security strategy needs to recognize that endpoints provide criminals with entry into an organization’s most valued data and understand that managing and securing those endpoints is critical. Now you can approach this security from a place of confidence — not fear — with IBM BigFix.

IBM Big Fix gives you the visibility and control to quickly detect and respond to cyberthreats at every stage and across all endpoints. IBM Big Fix:

  • Monitors and secures every endpoint — on and off the corporate network — before, during and after an attack;
  • Delivers real-time situational awareness and incident response across endpoints to mitigate damage;
  • Protects an ever-increasing number of endpoints, letting you manage and secure up to 250,000 of them from a single server — whether they’re connected to your network or not;
  • Gives you advanced protection against malware from the moment a threat is released until security patches are in place;
  • Bridges the endpoint gap between IT ops and security to reduce operational costs while improving security posture.

Learn more about IBM BigFix, our unified endpoint security and management platform, to understand how it can help you be confident you’re prepared and your data is secure.

The post Keeping Your Data Safe: How to Build an Endpoint Security Strategy Based on Confidence appeared first on Security Intelligence.

]]> 0
The Myth of the Obvious Malware Tue, 01 Sep 2015 12:02:46 +0000 Malware doesn't present itself like it's often depicted in the movies, so it's up to enterprises to be on the lookout for these stealthy programs.

The post The Myth of the Obvious Malware appeared first on Security Intelligence.

Wouldn’t it be nice if life were like a movie where we had the rugged handsomeness of a neo-noir hero, it was easy to tell the good guys from the bad and malware announced itself as soon as it entered your network? Alas, cyberattacks don’t reveal themselves in blaring lines of identifiable code that ignite a room of perfectly coifed forensics analysts into action. Well, the last part is true with enough money and enough concern, but the first part is sheer Hollywood fiction.

Crippling malcode now lies in wait: a dormant dweller that you’ll never be able to identify without smart (not well-coifed) IT professionals and analytic algorithms that expect the unexpected. Remember the “Blade Runner” Replicants of the far-off future, with androids becoming more than machine? It was an android so sophisticated that Harrison Ford’s Decker could only see behind the veil by breaking down the very root of the being’s logic and semblance of awareness with a sophisticated bio-response lie detector. Malware is smart, and it’s getting Replicant-smarter every day.

But you can be a Decker in days with the right endpoint protection.

We’ve Seen Things You Wouldn’t Believe

The security researchers at IBM X-Force have seen a multitude of malware samples. With 270 million monitored endpoints sending in data, that’s a lot of malcode to wade through. Although there are many variants, advanced persistent threats (APTs) share some common traits.

Malware MythsSuccessful malware is highly evasive. It can remain stealthy on the machine for long periods of time until certain criteria are met, using sophisticated techniques to bypass detection. It is not engineered to stroll into a noodle bar and announce itself in Cityspeak; rather, it sidles into the network through vectors such as sophisticated phishing or social engineering schemes. For advanced malware that is massively distributed, the threats are even greater: Off-the-shelf malware campaigns can be purchased by attackers with a comprehensive menu of functions and repurposable config files.

These new capabilities use a mix of techniques that can include keystroke logging, RAM scraping, browser hooking to get one-time passwords (OTPs), man-in-the-browser capabilities, dynamic webinjection, persistent rootkits and even virtual network computing (VNC) to launch a connection to the target site from an infected machine. These APT kits are made to be reusable and adaptable to the target environment.

The Voight-Kampff for Advanced Malware

Since real-life malcode doesn’t announce itself with distinguishing red lettering on your screen like in the movies, you have to watch for more subtle signs, or the equivalent of bio-response micro-tells. Here are a couple things to watch for to indicate if you’ve been infected on an endpoint:

  • Sluggish performance: Even with no resource-heavy applications running, random system crashes or constantly churning CPUs can be a sign of infection. If you also hear the CPU fan running at full speed for sustained periods as soon as the computer is booted, it is another indication of potential compromise.
  • Unexpected email activity: Perhaps your emails are being received or sent erratically, you are hearing from colleagues that they received emails from you that you did not send or you are getting out-of-office notices for emails you did not send. It’s possible your email password was stolen or your system was infiltrated.
  • Strange windows or messages: If programs are starting or stopping without your intervention, you’re getting notification pop-ups like a sea of billboards in a dystopian future, new programs are attempting to access the Internet or you open a PDF and it instantly disappears, you could be infected with malcode.
  • Sudden endpoint protection disablement: Advanced malware will often disable traditional antivirus protection to save itself from certain death. If you notice your antivirus or endpoint protection is suddenly disabled, this is most certainly a sign of trouble.

Do Hackers Dream of Electric Sheep?

Recently, the security researchers at IBM Security X-Force have discovered several particularly potent malware samples in the wild, including the Tinba Trojan and new variants of Dyre. The creators of this type of malcode work together in an ecosystem, collaborating on penetration and evasion strategies to maximize their investment in the code creation. Their best hope is to lull the target system into a sense of complacency — to be the virtual wolf in electric sheep’s clothing, waiting for the right time to expand and gather sensitive data.

Although potentially highly entertaining, the “Hollywood O/S” does not exist. Clumsy malware does not last long in the wild, and we are left to fight insidious malcode that snakes through networks and hides itself in plain sight like a Nexus-6 replicant. There is no four-year expiration date on this code either, as it continues to be reinvented, reinvigorated and rebuilt to attack more and better targets.

Advanced malware protection solutions can help stop exploits by focusing on and stopping the behavior of malware. By blocking malicious communication channels between the malware and the attacker, stopping anomalous activity caused by exploits and protecting credentials against reuse or submission on phishing sites, these solutions can help stop attackers from stealing your data.

To learn more about advanced malware protection, watch this video from IBM Security Trusteer Apex — flying cars sold separately.

The post The Myth of the Obvious Malware appeared first on Security Intelligence.

]]> 0
Shifu: ‘Masterful’ New Banking Trojan Is Attacking 14 Japanese Banks Mon, 31 Aug 2015 18:32:42 +0000 A brand -ew advanced banking Trojan discovered in the wild has been named Shifu by IBM Security X-Force, after the Japanese word for thief.

The post Shifu: ‘Masterful’ New Banking Trojan Is Attacking 14 Japanese Banks appeared first on Security Intelligence.

Co-authored by Denis Laskov and Ilya Kolmanovich

A brand-new advanced banking Trojan discovered in the wild has been named “Shifu” by IBM Security X-Force, after the Japanese word for thief. The malware appears to have been active since as early as April 2015; it was unearthed by IBM Security antifraud platforms through continuous protection of customer endpoints all over the world.

Shifu currently targets 14 Japanese banks and select electronic banking platforms used across Europe; however, at this time, only Japan is seeing active attacks.

Shifu Trigger Distribution per Target Country (Source: IBM Security)

Due to the capabilities Shifu presents, it is considered a highly sophisticated banking Trojan. Our analysis reveals that some of this malware’s features and modules were borrowed from other banking Trojans’ leaked source codes, including Shiz, Gozi, Zeus and Dridex, making it a power-patchwork of sorts.

Cybercrime’s New Familiar Face

The Shifu Trojan may be a new beast, but its inner workings are not entirely unfamiliar. The malware relies on a few tried-and-true Trojan mechanisms from other infamous crimeware codes. It appears that Shifu’s internal makeup was composed by savvy developers who are quite familiar with other banking malware, dressing Shifu with select features from the more nefarious of the bunch.

Some examples of those similarities are:

  • Domain Generation Algorithm (DGA): Shifu uses the Shiz Trojan’s DGA. The exposed algorithm itself is easy to find online, and the developers behind Shifu have elected to use it for the generation of random domain names for covert botnet communications.
  • Theft From Bank Apps: Theft of passwords, authentication token files, user certificate keys and sensitive data from Java applets is one of Shifu’s principal mechanisms. This type of modus operandi is familiar from Corcow’s and Shiz’s codes. Both Trojans used these mechanisms to target the banking applications of Russia- and Ukraine-based banks. Shifu, too, targets Russian banks as part of its target list in addition to Japanese banks.
  • Anti-Sec: Shifu’s string obfuscation and anti-research techniques were taken from Zeus VM (in its Chtonik/Maple variation), including anti-VM and the disabling of security tools and sandboxes.
  • Stealth: Part of Shifu’s stealth techniques are unique to the Gozi/ISFB Trojan, and Shifu uses Gozi’s exact same command execution scheme to hide itself in the Windows file system.
  • Config: The Shifu Trojan is operated with a configuration file written in XML format — not a common format for Trojans, and similar to the Dridex Trojan’s configuration (Dridex is a Bugat offspring).
  • Wipe System Restore: Shifu wipes the local System Restore point on infected machines in a similar way to the Conficker worm, which was popular in 2009.

On the less technical side, Shifu communicates via secure connection that uses a self-signed certificate, just like the one used by the Dyre Trojan.

Shifu comes with basic built-in capabilities, which are supplemented by additional modules once it contacts its command-and-control (C&C) server.

The initial package comes with features like:

  • Anti-research, anti-VM and anti-sandbox tools;
  • Browser hooking and webinject parser;
  • Keylogger;
  • Screenshot grabber;
  • Certificate grabber;
  • Endpoint classification, monitoring applications of interest;
  • Remote-access tool (RAT) and bot-control modules.

Out to Get It All

For a banking Trojan to be defined as advanced, it would typically need to possess a variety of real-time theft mechanisms and more than one way to control infected endpoints, including user-grade takeover via RDP/VNC. Shifu appears to come with quite a few bells and whistles in that regard.

This Trojan steals a large variety of information that victims use for authentication purposes, covering different sorts of authentication. For example, it keylogs passwords, grabs credentials that users key into HTTP form data, steals private certificates and scrapes external authentication tokens used by some banking applications. These elements enable Shifu’s operators to use confidential user credentials and take over bank accounts held with a large variety of financial service providers.

Shifu scans, parses and exfiltrates data from smartcards if they are attached to a smartcard reader on the endpoint, and searches cryptocurrency wallets to steal from the infected victim.

Are You a Point of Sale?

Beyond their interest in defrauding bank accounts, Shifu’s operators target payment card data. The malware scans infected endpoints for strings that may indicate it has landed on a point-of-sale (POS) endpoint, and if that sort of string is found on the machine, Shifu deploys a RAM-scraping plugin to collect payment card data. RAM scraping is the top method for siphoning credit and debit cards’ track 1 and track 2 data, used in major breaches like the Target breach.

Electronic Banking Platforms Join the Hit List

While webinjections are a common Trojan capability, very few Trojans target banking platforms. Such an attack type is known from older malware like Shiz that targeted banking platforms used by Russian banks. Shifu has a similar aim on Java applet-based platforms, where it hooks the Java processes and scans for .tok files. What Shifu is after in this case are tokens used as short-term authorizations for external authentication schemes.

Moreover, Shifu looks for digital signature credentials issued by certification authorities to business banking users, particularly in Italy. By resetting the PIN on the certificate, Shifu’s operators can impersonate the victim in fraudulent banking operations that authenticate users based on their valid digital signature.

Targeting banking applications rather than specific websites provides the benefit of making attacks more generic in the sense that they will fit more targets. If the malware’s developer finds a way to compromise an application/platform in one case, it will likely work the same on other banks using that platform.

Local Deobfuscation Server Hides Injection C&C

Reminiscent of another advanced banking malware — like Dyre — Shifu conceals its webinjections and does not show them in the configuration file. Instead, it fetches them in real time from a remote server. But this is where its resemblance to other Trojans end. To call on the correct injection at the right time, Shifu’s developers have created an interesting round-robin resolution to a local PHP server opened on the infected machine.

When a new endpoint is infected by Shifu, the malware downloads and deploys an archived file folder on that PC that turns it into a LocalHTTPServer. This local Apache server is then used for decrypting webinjections, hosting and receiving injected JavaScript from a remote Shifu server.

To implement this real-time fetching, Shifu accesses a remote webinjects server, the address of which it strives to keep concealed. The server’s name as it appears in the configuration is not decipherable and seems bogus at first glance. In reality, the request is obfuscated, and instead of going to the Web browser as is, Shifu’s requests first go to the local PHP server for deobfuscation. The local server has HEXtoString function instructions to interpret the request, fix it and then send the real one off to the browser in its proper form.

Shifu’s injections are selective and change according to the targeted entity. In some cases, it replaces the bank’s entire page with a fake replica designed to harvest the data Shifu’s operators are after. In other cases, the Trojan displays social engineering content on the page using JavaScript injections to ask victims for additional authentication elements it will need for a subsequent fraudulent transaction, such as PII or one-time passwords.

Intruders: Back Off!

Shifu’s operators appear to have no intention of sharing the spoils with anyone outside their gang. Once Shifu has landed on a newly infected machine, it activates an antivirus-type feature designed to keep all other malware out of the game by stopping the installation of suspicious files.

Shifu monitors the processes of a list of applications that interact with the Internet on a regular basis, it hooks the URLDownloadtoFile function and keeps close watch on the incoming files the endpoint receives. Files that may harbor malware will be stopped if they:

  • Come from unsecured connections (HTTP);
  • Are executables;
  • Are unsigned.

As soon as a file of that sort is downloaded by the Web browser, Shifu copies it to the local disk and names it “infected.exx.” It then exfiltrates it to its master’s C&C server. Shifu also spoofs a reply to the operating system trying to run the downloaded file with an “Out of Memory” message.

This feature serves to keep Shifu exclusive on the machines it infects. Moreover, sending malware files to its operator on a regular basis allows Shifu to keep tabs on the competition and find out when other cybercriminals are attacking in the same geographical turfs.

This is the first time we are seeing malware build “rules” for suspicious files in order to make sure that the endpoint it’s on remains in its exclusive control from the moment of infection. If the endpoint is already infected with other malware, Shifu does not find and delete other malware; but by stopping new files from coming in, it can prevent malware from receiving version and configuration updates, potentially cutting its ties with other botmasters.

Shifu’s Likely Origins

So who put the masterful Shifu together? Following analysis of Shifu’s scripts, our researchers found comments written in Russian. Shifu’s developers could be either Russian speakers or native to countries in the former Soviet Union. It is also possible that the actual authors are obfuscating their true origin, throwing researchers off by implicating an allegedly common source of cybercrime.

Some specific strings found during analysis of Shifu are not written in Cyrillic letters, but have meanings in Russian. For example:

  • BUH: References the word “accounting” in Russian;
  • KASSA: “Cashbox” in Russian;
  • FINOTDEL: Corporate slang for the “accounting department”;
  • ROSPIL: Russian government most prominent opposition party.

Shifu’s servers are located in different countries, with domains hosted on IP addresses alongside a plethora of .ru domains that may or may not be linked to the same gang.

More to Come

Shifu is a complex and interesting new malware. At this time, the malware is actively attacking banks in Japan, but it has the potential — and a target list in place — to spread. Its main fraud methods are based on credential grabbing, webinjections and certificate theft. Having been built with codebase from other crimeware families, Shifu is also protecting its infected turf against other malware, shutting out the competition from its spoils.

IBM Security X-Force has issued a complete report on Shifu and will release it in the coming week. Stay tuned for additional information both here on Security Intelligence and on IBM X-Force Exchange.

Shifu sample MD5 b9bc3f1b2aace824482c10ffa422f78b is presently detected as a generic malware by 19 of 56 (34 percent) antivirus engines, according to VirusTotal and IBM X-Force Exchange as of Aug. 27, 2015.

The post Shifu: ‘Masterful’ New Banking Trojan Is Attacking 14 Japanese Banks appeared first on Security Intelligence.

]]> 0
Anomaly Detection: The Power of Next-Generation SIEM Mon, 31 Aug 2015 13:02:38 +0000 If a corporate network has been breached, prevent further damage with anomaly detection and behavioral analytics stemming from SIEM tools.

The post Anomaly Detection: The Power of Next-Generation SIEM appeared first on Security Intelligence.

I pay too much for my cellphone service. My family burns through our data plan without realizing what’s going on as they browse the net, communicate with friends, stream videos and so on. What I really need is some sort of security information and event management (SIEM) for my cellular service that would alert me when anomalistic behaviors are occurring.

Right now, my carrier sends me a text when 75 percent, 90 percent and 100 percent of my data plan is consumed, which prompts me to review all the usage and find out who did what with 11 GB of data in as little as two weeks. The statistics typically reveal that it’s video streaming, but the connect times are short and occur during all hours of the day and night. It would’ve been great to get the alert that my son’s phone is processing video at 3 a.m. before all the data is used.

Behavioral Analytics Finds Abnormal Behavior

QRadar Security Intelligence performs this sort of anomaly detection — also known as behavioral analytics — in real time as it compares current activity to a moving average baseline used to define normal operations. This is calculated using the accumulated log source event and flow data for associated collections of IP addresses, usernames, workgroups, etc. so it can alert on a wide variety of conditions. Wouldn’t you sleep easier knowing that your IT security team will see the first occurrences of what may be a newly installed botnet agent calling home to a command-and-control (C&C) server? Or how about the first time an unauthorized user accesses a highly valued system?

The concept of applying behavioral profiling to computer networks isn’t exactly new. It was originally proposed by Dorothy Denning back in her 1987 IEEE paper “An Intrusion-Detection Model,” but IBM Security’s QRadar implementation takes it a step further. Many vendors are only able to look at syslog events and NetFlow information, which only reveal part of the story — like seeing odd cellular data traffic at off hours. QRadar Security Intelligence incorporates Layer 7 or application insights that can quickly discover things like nonstandard protocols running through essentially reserved ports.

How QRadar Can Help

QRadar’s QFlow Collector processors employ deep packet inspection (DPI) to help uncover things like IRC traffic over Port 80, which is typically reserved for HTTP. It can also be used to identify potential data loss through file transfer protocol (FTP) servers transmitting prohibited content, such as audio or video recordings created by commercial studios. It’s like having the additional insight that the cell traffic occurring is video destined for YouTube.

This type of anomaly detection is the next best line of defense once a network’s perimeter has been breached. Today, just about the only thing attackers can’t know about our networks is what’s normal, making their movements more easily discovered when activity deviates. It’s one area you can have an advantage, and anomalies can be defined in several ways.

In addition to the behavioral profiling previously discussed, QRadar can generate alerts and offenses based on all the following: when new hosts and services appear on the network; when existing services stop or crash; when a highly valued server starts using new applications or suddenly starts communicating with assets outside your network; and when the amount of data transferred to an external source exceeds a defined threshold.

QRadar SIEM’s advanced search capabilities can also help security professionals discover low-and-slow attacks occurring over longer time periods than would surface using 30-day exponential smoothing algorithms. QRadar event and flow processor appliances often retain more than 180 days of security data, and their retention periods can easily be doubled or tripled with the addition of QRadar Data Node appliances.

Using SIEM to Improve Overall Security Posture

One of the challenges associated with SIEMs using anomaly detection technology is to know when not to apply this analysis or how to adjust any time intervals to accommodate infrequent and random acts of humans. Anomaly detection also doesn’t help the IT security professional understand the type of attack or define any remediation activities. This is why QRadar Security Intelligence includes both SIEM investigation capabilities for inspecting all the underlying events and flows and QRadar Incident Forensics technology for retrieving and analyzing all associated network packet transfers.

After the second month of paying overage charges on my data plan, my son downloaded the account app and began looking at his data usage. He’s a budding YouTube channel publisher, and there was some background service running that never seemed to quit. Once properly identified, he simply deactivated the app whenever he wasn’t editing or uploading. Immediate value was realized from insights into user and data activity, just as next generation SIEMs are able to deliver.

Read the Ponemon Institute’s IBM QRadar Security Intelligence Perception Capture Study

The post Anomaly Detection: The Power of Next-Generation SIEM appeared first on Security Intelligence.

]]> 0
Protecting Student Information: A CISO’s Point of View Mon, 31 Aug 2015 12:32:57 +0000 David Sherry, the CISO at Brown University, describes the steps taken to secure student information without inhibiting information sharing.

The post Protecting Student Information: A CISO’s Point of View appeared first on Security Intelligence.

Universities are a treasure trove of information that goes far beyond just student information. According to David Sherry, CISO of Brown University, the job of a university CISO can be compared to securing a small city. Apart from the need to protect students, faculty and staff, information related to applicants, alumni, parents, donors, summer school students, visiting scholars and sports groups needs to be considered. Then there are ancillary services such as residential and catering, hospital, police, entertainment and athletics to be considered. Each has its own unique area where security comes into play.

As an Ivy League university, brand and reputation are of paramount importance to Brown. As Sherry said, Brown would rather be on the front page of the news for producing the next Nobel Prize winner than for a damaging breach. But this could be at odds with its goals of academic freedom and collaboration, with information sharing highly prized.

A Prime Target for Attackers

According to Sherry, the vast amount of information produced and collected by the university makes it a prime target for attackers. Every day, it is bombarded with 50,000 to 60,000 attacks, with brute-force and distributed denial-of-service (DDoS) attacks, as well as phishing attempts, among the most common. Constant security awareness training is necessary. But Sherry brushes off such strikes as “digital door-rattling” rather than targeted attacks, stating that very few of them are successful.

Security problems are exacerbated by high levels of bring-your-own-device (BYOD) since mobile devices are not supplied to students. It is not uncommon for each student to own 10 or even 15 devices. Sherry says this is something that the higher education sector has been dealing with for an extremely long time — and to a greater degree than enterprises.

As well as completing awareness training, students are expected to abide by Brown’s acceptable use policies. They are also required to register before accessing resources, and authentication and authorization controls are stringent.

Security Measures Are Holistic, Robust and Scalable

Among the reasons for the low level of attack success is that Brown takes rigid security measures to protect students’ information and that of others in the campus community. Sherry states that the security measures Brown implements are holistic, robust and scalable. It deploys a wide range of security controls, including intrusion detection and prevention systems, firewalls, email alerts, file integrity monitoring, data exfiltration systems and dedicated personnel in the security operations center who are constantly monitoring for anomalous traffic and performing risk and compliance assessments.

Compliance assessments are essential since higher education is covered by many regulations. Of these, the one most specific to this sector is the Family Educational Rights and Privacy Act (FERPA), which governs the security and privacy of student information, including education records, enrollment and even billing information. Higher education institutions must also take copyright extremely seriously — something made harder by widespread use of file sharing sites such as Box and Dropbox.

Although there are no restrictions on the use of such sites, Brown’s restricted data policy clearly spells out what can and cannot be shared on different systems and sites, and it harvests the email addresses of Brown community members using such sites. The university is currently investigating the possibility of providing its own collaboration platform to all users, placing a priority on both security and potential risks to its reputation.

Access controls are stringent to ensure that sensitive data is protected, with particular attention paid to privileged user access to satisfy segregation of duty requirements and to ensure no one person has excessive access rights. Recently, the university has been rolling out two-factor authentication, which Sherry believes will help to reduce the number of threats encountered by a large margin. This strong authentication rollout began with faculty and staff members and is now continuing among the student population.

Returning to the analogy of securing a small city, one of the characteristics of universities is that they tend to be decentralized. Because of this, Brown operates a highly segmented network architecture, with internal firewalls, network security zones and demilitarized zones (DMZs) used to segment traffic. The protected areas of the network can only be accessed when on campus, or off campus with a user’s virtual private network (VPN) credentials to determine access rights so they may only access areas of the network for which they have entitlements.

To protect student information outside of classrooms and research labs, the residential network is completely separated via a firewall. In this way, Brown is really taking on the role of an ISP so that it is protected at all hours. That is necessary for students, especially since Sherry states that the amount of traffic between 11 p.m. and 4 a.m. is mind-boggling.

A Culture of Information Sharing Among Peers

Information sharing among peers in the same industry remains a pipe dream for many. Various governments are attempting to promote information sharing, including the EU, which published a Good Practice Guide for Network Security Information Exchanges in 2009, and the U.S. government, which published a Guide to Cyber Threat Information Sharing in October 2014, detailing both the benefits and the challenges of information sharing. The following month, it passed the National Cybersecurity Protection Act, which aims to promote information sharing among federal and private sector entities.

Sherry, who has worked both in government and the financial services sector, states that he has never seen information sharing to the extent that it is practiced in higher education. Among universities, there is a culture of constant information sharing among peers — helped by the fact that, although they may compete for a small population of students, they are not otherwise in direct competition with each other. When an incident occurs at one institution, information is immediately shared with other universities.

Conferences provide a key forum for information sharing, with much more information shared than at regular security conferences, and peers will often discuss potential security vendors amongst themselves, sharing details of how well they perform and how fit for purpose their products and services are. Sherry states that this culture of information sharing is one of the coolest things about higher education, making universities more secure and their security posture more cutting-edge.

The central mission of all universities is to make higher educational successful so that students can reach their full potential. All universities want to ensure that they are as secure as possible and, by sharing information amongst themselves, no institutions will get left behind. This is one of the main reasons that Sherry, as a CISO, is looking forward to spending the remainder of his career in the higher education sector.

The post Protecting Student Information: A CISO’s Point of View appeared first on Security Intelligence.

]]> 0
Watch Out for CoreBot, New Stealer in the Wild Fri, 28 Aug 2015 17:02:33 +0000 IBM Security X-Force researchers recently discovered CoreBot, a seemingly generic malware that actually operates on a highly sophisticated level.

The post Watch Out for CoreBot, New Stealer in the Wild appeared first on Security Intelligence.

Co-authored by Martin Korman

When it comes to discovering new malware, it is much more common for researchers to run across information stealers, ransomware and remote-access tools (RATs) than it is to encounter brand new complex codes like banking Trojans or targeted attack tools such as Duqu.

Nonetheless, it is the lesser breeds, like information stealers and RATs, that are a lot more prolific in the wild. And while banking Trojans or targeted attacks are quite specific in what they do, information stealers are by far less discriminatory and thus end up affecting a greater number of people and organizations.

That brings us to CoreBot, a new information stealer discovered and analyzed by IBM Security X-Force researchers, who indicate this is one malware piece to watch out for. CoreBot appears to be quite modular, which means that its structure and internal makeup were programmed in a way that allows for the easy adding of new data theft and endpoint control mechanisms.

CoreBot was discovered while the researchers were studying the activity of malware on Trusteer-protected enterprise endpoints. The malware’s compiled file was named “core” by its developer. Antivirus engines do not specify this malware’s name yet and detect it under generic names such as Dynamer!ac or Eldorado. But while CoreBot may appear artless at first glance, without real-time theft capabilities, it is more interesting on the inside.

Info Stealers: Prevalence and Risk Factors

When it comes to generic malware, many believe it is less targeted and therefore less damaging than more elaborate malcode. In reality, the opposite is true. Generic malware is frequently the sort of Trojan that harvests passwords indiscriminately, which ends up compromising a broader set of the user’s personal accounts, including bank account credentials, email and e-wallets. When they land on an enterprise endpoint, information stealers gather email credentials, software keys and anything else saved on that drive that can be interesting to attackers. On top of that, it can download and execute other malware at will.

Many times, info-stealer Trojan botnets siphon this sort of data from a myriad of endpoints and trade it in the underground, selling it to cybercriminals who will find ways to use or monetize it.

In a recent report released by IBM Security about enterprise threats, data collected from Trusteer Apex Advanced Malware Protection showed that the most rampant type of malware targeting employee endpoints in July 2015 was info stealers.

Top Most Prevalent Threats Attacking Enterprise Endpoints (July-2015)

CoreBot Infiltrates PCs via Dropper

To begin, CoreBot infiltrates new endpoints by means of a dropper. Once the dropper is executed, it launches a svchost process in order to write the malware file to disk and then launch it. The dropper then exits.

Sets Persistence

Next, CoreBot generates a globally unique identifier (GUID) using the CoCreateGuid API Call. The GUID is used by CoreBot to define its persistence via a run key in the Windows Registry. For example:

RegSetValue HKCU\Software\Microsoft\Windows\CurrentVersion\Run\f9111abc-8f81-200b-8b4a-bd8fd4a43b8h

CoreBot GUID

Modular Plugin System

CoreBot’s most interesting facility is its plugin system, enabling it to be modular and easily supplemented with new theft capabilities. CoreBot downloads plugins from its command-and-control (C&C) server right after setting its persistence mechanism on the endpoint. It then loads the plugins using the plugininit export function in the plugin’s DLL.

At present, the main plugin is called Stealer. The MD5 of that plugin is:


CoreBot steals passwords, but it is currently incapable of intercepting real-time data from Web browsers. Instead, it steals saved passwords stored in the endpoint’s browsers, scanning for passwords on all the most popular browsers.

CoreBot further searches an extensive list of FTP clients, mail clients, webmail accounts, cryptocurrency wallets, private certificates and personal data from a list of various desktop applications.

The example below shows how CoreBot scans for private certificates in store and then steals them:

Steal Private Certificates

Domain Generation Algorithm (DGA)

Unlike most information stealers, CoreBot has a domain generation algorithm (DGA) in place, although it is not presently activated. The DGA is a feature designed to enable malware botnets to communicate with their central C&C through dynamically generated domain names. With the DGA, the domain name is supposed to only be known in advance to the malware’s operator, thus preventing security researchers from being able to take down the site or for other criminals to hijack the botnet.

In CoreBot’s case, the DGA parameters appear to generate different domains for geographical zones of the botnet and for groups of bots defined by the botmaster — a rather interesting concept for malware that is merely a generic stealer.


Upon infection of a new endpoint, CoreBot calls home with a live signal and downloads the Stealer plugin. The malware communicates with two domains: vincenzo-sorelli[.]com and arijoputane[.]com.

Both of CoreBot’s communication domains were registered by the same person, email address and Russia-based physical address. A WHOIS lookup brings up personal details.

The Risks of CoreBot Malware for Organizations

Password and Data Collection

On infected employee endpoints, malware such as CoreBot can harvest access credentials to a plethora of resources used by the employee for work and for personal browsing. Since corporate passwords are all too often reused on other websites, fraudsters can attempt to use the stolen credentials to infiltrate the organization, send malware to other users and expand the overall compromise.

It is important to keep in mind that Trojan operators will typically exfiltrate confidential business data like customer information, budget plans or even confidential insider information. Therefore, even a few infected endpoints inside the organization can end in very significant data security consequences.

Download and Launch Other Malware

Using Windows PowerShell, Microsoft’s task automation and configuration management framework, CoreBot can fetch other malware from the Internet, download and execute it on the infected PC.

CoreBot Uses PowerShell to Donwload More Malware

CoreBot downloads and launches new versions of the executable in order to update itself according to predefined parameters of the latest version on the infected machine.


Stop the Inevitable

Any malware on enterprise endpoints is bad news for the organization, but avoiding malware is, in reality, nearly impossible. In almost all cases of malware infiltrating employee endpoints, the malicious file was probably opened by the employee from unsolicited email or inadvertently contracted while browsing infected or watering-hole attack sites.

One of the best ways to protect enterprise endpoints is to supplement employee awareness with specialized protection that can stop malware at the exploitation or launch stages, but also stifle its data exfiltration attempts if it is already on the endpoint.

Proper detection and classification of malware like CoreBot, beyond merely generic designation, is necessary in order to properly assess the risk level it poses. Security Intelligence is writing about this because, although CoreBot isn’t very sophisticated right now, it is still new malware designed to be easily updated, and it could evolve into a more complex threat in the near future.

The post Watch Out for CoreBot, New Stealer in the Wild appeared first on Security Intelligence.

]]> 0
Travel Security: Protecting Your Personal and Corporate Wallets While Traveling Fri, 28 Aug 2015 13:02:28 +0000 Best practices for travel security span everything from personal safety to managing company wire transfers and business credit cards.

The post Travel Security: Protecting Your Personal and Corporate Wallets While Traveling appeared first on Security Intelligence.

You’re traveling, on the road again for the company. You’ve listened to the travel security briefs and — unless you are on a trek to the Arctic with all your supplies in hand — you will be engaging in commerce for goods and services. Theses interactions require cash, credit or barter to complete. It is at this time during travel that individuals are most vulnerable, being far from their personal and professional support system.

Many have had an instance where they go to make a purchase and the individual processing the transaction takes a gulp and says, “There seems to be a problem with your card.” We all try to avoid such an event, but often, circumstances outside our control trigger a fraud alert. Losing one’s credit card can also create a minor crisis. And while bank transfers within our own ecosystem are easily understood, the process gets complex quickly when a foreign entity is brought into play. The seriousness and stress of these issues makes learning about the best travel security practices essential.

Traveling With Credit Cards

Your employer may have a travel security program that provides workers access to an employer-provided credit card. These are issued through financial institutions and normally allow the company to directly access the credit card accrued expenses and pay those charges based on a confirmation of validity as both appropriate and true in accordance with the employee handbook on travel expenses.

Ordinarily, these credit cards are viewed as company cards, but their misuse can and will have a deleterious effect on one’s personal credit rating. Whether you are using your personal or business credit card, you must exercise due caution when at ATMs or during vendor transactions. At the former, watch for card skimmers, which are devices that skim the electronic data and allow criminals to duplicate the card and run up charges.

Managing Wire Transfers

But individual travel expense vulnerability isn’t the only worrisome area for companies. While you’re in travel mode, the enterprise is communicating with you differently than if you were sitting in the office and available for a face-to-face chat. This extends to approving wire transfer requests. There may be transactions requiring your approval or financial items you will generate when abroad. It is paramount that travel security discussions within your company include each and every person involved in the fiscal aspects of the company so they can be trained on the processes that result in payment or transfer of funds.

Take technology startup Ubiquiti, which found itself on the losing end of a sophisticated social engineering attack that resulted in $46 million being siphoned out of its treasury, $8 million of which was eventually recovered. The methodology used was a variant on CEO fraud, or business email compromise.

In 2014, the FBI investigated $226 million in losses from U.S. companies that fell victim to the email scam. Compromise of a company’s email system allows the criminals to spoof directions as if the demands are coming from those officials with authority to make the fiscal decisions. The FBI report stated that “email accounts of the chief executive officers or chief financial officers of a targeted business were hacked or spoofed, and wire payments were requested to be sent to fraudulent locations.”

Travel Security Tips

Any employee can follow a few general travel security tips to help stay safe when abroad and avoid falling victim to common schemes. Before departing, you should complete several key tasks, including:

  1. Register your itinerary with your company. Include a copy of your passport data page with your records.
  2. Register with your country’s embassy or consulate in the given locale. For U.S. citizens, it is the U.S. Department of State, which offers the Smart Traveler Enrollment Program (STEP) to make this process easier.
  3. Contact your credit and debit card-issuing institution and inform their fraud department that you will be traveling to a given locale. Provide the dates and specific locations. This allows the fraud department to monitor for unusual activity and activity outside the window of your travel.
  4. Make copies of all your travel documents and credit cards to leave with a trusted individual. Should you need to replace any or all of these resources, the copies will be instrumental in accomplishing the task.
  5. Review the precise circumstances in which wire transfers and the like can take place with your enterprise’s finance personnel. Check what authentication protocols are in place to avoid spoofing.
  6. Review and train on the remote use of company email systems to avoid compromise. This may include adopting the use of a virtual private network (VPN) or restricting yourself to secure email.

The post Travel Security: Protecting Your Personal and Corporate Wallets While Traveling appeared first on Security Intelligence.

]]> 0
Side-Channel Attacks Against Multicore Processors in Cross-VM Scenarios: Part II Fri, 28 Aug 2015 12:17:27 +0000 Discussion of two side-channel attacks meant to retrieve sensitive information from a virtual machine (VM) on the same physical processor package.

The post Side-Channel Attacks Against Multicore Processors in Cross-VM Scenarios: Part II appeared first on Security Intelligence.

In Part I, we introduced the notion of a side-channel attack and discussed its uses in infrastructure-as-a-service (IaaS) clouds. In this second part, I will discuss two side-channel attacks meant to retrieve sensitive information from a target virtual machine (VM) on the same physical processor package.


The first attack, FLUSH+RELOAD, is described as a multicore side channel with the last-level cache (LLC). The FLUSH+RELOAD attack relies on a feature that has been discouraged by virtual machine manager (VMM) creators such as VMware but still may be used in private clouds: page sharing across VMs. This means that the VMM deduplicates memory pages, usually those shared by executables such as libc in a Unix environment or kernel32.dll in a Windows environment. This results in the same physical memory pages being mapped into the virtual address space of multiple VMs. When this happens, the FLUSH+RELOAD attack becomes possible.

Note that this is exactly the same attack used against platform-as-a-service (PaaS) clouds. The difference here is that PaaS clouds typically share the same binaries and the same OS kernel, as well as shared memory pages. These are exactly the conditions required for the FLUSH+RELOAD attack to work. Plus, the attack can be much more precise because there is quite a bit known about the internal state of the target tenant’s platform environment.

This attack consists of three steps:

1. Evicting the Cache Line

In the first step, the attacker measures the length of time it takes to read a memory address. Then, a cache line is evicted from the LLC. A cache line is a small chunk of memory belonging to the cache that is used to allocate and transfer requests from a lower-level cache to upper-level caches, eventually resulting in requests to the LLC if no hits have been found on the core’s private caches.

The eviction is done using the cflush instruction, which is an unprivileged instruction on the X86 architecture. Note that it is a privileged instruction on other processors such as the ARM. The code to do this requires the serialization of instructions with the mfence and lfence instructions to prevent parallel and out-of-order execution common on modern cores. The cpuid instruction will largely do this, but this instruction is usually emulated by the hypervisor.

2. Waiting for Access

Next, the attacker allows the target time to access that flushed cache line. Note that this interval must be carefully chosen — too long an interval will result in a loss of resolution, but too short of a wait period will result in overlapping access of the cache by the attacker VM and the target VM, potentially resulting in false negatives.

3. Accessing the Flushed Cache Line

In the third step, the attacker VM accesses that flushed cache line. If the target has utilized the cache line, the load will be quicker than if the target has not and the cache line must be loaded from memory. The attacker uses empirical measurements on the particular compute node to set a threshold, under which the target is assumed to have accessed the cache line and above which it has not. The attacker uses the RDTSC instruction to get an accurate timing. Xen, a hypervisor, emulates this instruction by default with a hybrid algorithm but can be forced to emulate it in all cases. This emulation makes this attack far more difficult, if not impossible.

Using the temporal technique, an attacker can derive whether or not certain instructions have been executed. If the attacker has a copy of the binary under test on the target and has introspection into that binary, he or she can trigger the execution of an algorithm and know whether the instructions have been executed. Depending on the algorithm, this may leak bits of the values being processed by the algorithm. The attacker simply loads and maps the executable into the attacker VM’s virtual address space, and if the hypervisor deduplicates, the attacker has access to the shared physical memory pages.

Prime+Probe Attacks

As mentioned above, hypervisor creators have strongly discouraged deduplication across VMs, so the FLUSH+RELOAD attack is usually not practical. A new attack was created, the multicore Prime+Probe attack, which only requires the LLC on a CPU and the ability to map large memory pages into a VM, which is nearly always allowed for performance reasons. “Last-Level Cache Side-Channel Attacks Are Practical” demonstrates attacks against the El Gamal encryption scheme as implemented in GNU PG/libcrypt, both with the square-multiply-reduce algorithm and the new sliding-window modular exponentiation algorithm. This makes the multicore Prime+Probe attack extremely powerful.

How It Works

This attack is based on the Prime+Probe method discussed in “Cache Attacks and Countermeasures: the Case of AES.”

The attacker fills one or more cache sets with chosen data or instructions. The attacker then waits for a period of time to allow the target to execute and access the cache. Similar to the FLUSH+RELOAD attack, if the target has utilized the cache, it will have removed some of the attacker’s data or code. When the attacker reads the cache sets that have been primed, the probe determines whether or not the target has used the cache sets by comparing the probe’s access time with a threshold designed to determine if the information came from the cache or from main memory.

The probe acts as the prime phase for the next execution of the algorithm. As mentioned above, Xen emulates the RDTSC instruction by default in a hybrid algorithm but can be forced to emulate it in all situations. This makes this attack extremely difficult and lowers its resolution perhaps to the point of impracticality.

Challenges to Prime+Probe Attacks

There are several challenges to the success of this technique, outlined in section 2D of “Last-Level Cache Side-Channel Attacks Are Practical.” To meet these challenges, the attack relies upon several features that are ubiquitous in modern compute nodes. For example, modern caches are inclusive, meaning that it is possible to replace the target’s data at all levels of the cache hierarchy.

In order to avoid having to prime and probe the entire LLC, the attack identifies certain cache sets that are relevant to security accesses by the target. To do this, the attacker scans the entire LLC, looking for temporal patterns that match the security algorithm in question — that is, the attacker must know the target’s algorithm in order to discover the security-relevant cache sets. This is clearly suboptimal, and a solution to this problem would be extremely valuable.

Another challenge is constructing an eviction set that only flushes one cache set known to the attacker so that it can be probed. This is difficult because the VMM indirectly maps emulated physical memory to actual physical memory, and the attacker has no way of accessing this mapping.

Furthermore, the new slice concept of the LLC in which each core has a fragment of the LLC connected by a ring bus to the other cores makes it necessary to know the slice ID, which is the output of a secret hashing function created by Intel.

How Attacks Occur

The solution is to use large memory pages. With 2 MB pages, all the index bits of the LLC fall within the page offset, and this attack becomes practical — that is, the page value is split into two sections, an offset and a page number. This is done to preserve precious entries in the translation lookaside buffer of the CPU. The higher bits assigned as the page number are part of the virtual address space of the process, which is doubly obfuscated both by the processor mapping to emulated physical memory and then by the VMM, which maps it to real physical memory.

The lower bits of the virtual address are mapped to a value known as the offset. The offset is not mapped by the memory management unit (MMU) of the CPU and is therefore the same value in physical and virtual memory. This means that bits of the physical address are leaked to the attacker since the offset is not changed.

When the attacker uses large pages, more bits are leaked in the offset value that map to physical addresses. The MMU only maps the page number, so with large pages, the number of bits mapped by the MMU grows reasonably small. Because the large page is backed up in physical memory by a large page, this allows access to the LLC.

Note that there is still the difficulty of slices. The authors created an algorithm to combat this, the details of which can be found in “Last-Level Cache Side-Channel Attacks Are Practical,” figure 2B.

To overcome the limited probing resolution of this technique, the attack can be run asynchronously without the need to preempt the target. This limits the resolution to the speed at which the attacker can execute the probe step. The LLC is much slower than the higher-level caches for several reasons, including more required memory accesses and the physical speed difference of the caches.

Preventing Problems

As I discussed above, cache lines are the lines connecting caches with each other and with the main memory. We must create an eviction set from these cache lines and do so in a manner that is not predictable by the processor’s prefetch unit. The lines of the eviction sets are organized in a random linked list. This avoids processor optimizations such as fetching of contiguous memory lines.

Listing 1 of “Last-Level Cache Side-Channel Attacks Are Practical” shows how to probe a cache set. With these tools, the Prime+Probe attack proceeds. See section 4C of the paper for a discussion of optimizations of the attack.

In Part III of this series, I will discuss a third side-channel attack.

The post Side-Channel Attacks Against Multicore Processors in Cross-VM Scenarios: Part II appeared first on Security Intelligence.

]]> 0