Anatomy of a LOGJAM – another TLS vulnerability, and what to do about it

Anatomy of an APT Attack: Step by Step Approach

This article will explore the technique, design and the inner workings of an APT (Advanced Persistent Threat) attack. It will also relate various stages of attack with a few attacks that were custom-created to penetrate enterprises for extraction of internal data, trade secrets, and sensitive business information.

Introduction

APTs are designed to gain access to a network, acquire data, and secretly monitor the targeted computer systems over long periods. Many researchers agree that the term “Advanced Persistent Threat” was first coined by the U.S. Government during 2005 by Security Analysts to describe complex cyber-attacks against specific targets for financial or informational gains by a well-funded group of individuals.

The “Advanced” process signifies sophisticated techniques using malware and known vulnerabilities to exploit the internal systems. The “Persistent” process suggests that an external command and control system is continuously monitoring and extracting data from a specific target. The “Threat” process indicates human involvement in orchestrating the attack. Basically, APT is a network attack. An authorized person gains access into the network and stays there for a longer period by establishing a back door — collects data and moves out. The target networks are usually financial institutions, military intelligence. The goal of a targeted attack is to steal valuable intellectual property, money, and other personally identifiable information (PII).

In 2006, there was only a single reported APT attack, by 2014, the number spiked to over 50 known, documented incidents, according to APTnotes. These types of attacks are becoming more and more sophisticated. They have caused numerous large and costly data breaches by routinely defeating or evading traditional security measures. Even after successfully accomplishing the mission, the APT continues to live on to gather additional information. They are very difficult to detect and remove as they will not obviously appear to be malware and may be planted very deeply into an organization’s computing systems. In addition, the designers and initiators of the APT will consistently monitor and guide its activities by changing its code to evade detection.

Zero Days and Cyber Attacks

Many APT threats have been utilizing zero day vulnerabilities to target victim organizations. During 2014, an APT attack that utilized and took advantage of a zero-day vulnerability in Internet Explorer (CVE-2014-1776), consisted of phishing emails sent to a targeted group of people at defense, aerospace, energy, and research universities. The phishing emails contained a link that led to malicious websites hosting the zero-day exploit code.

They sent out many more messages to a wider set of targets, trying to infect as many endpoints as possible before a patch was made available. The attackers also updated their email templates and themes every day to keep the campaign “fresh” and evade any spam detection rules put in place to detect the previous messages.

FireEye describes an attack life cycle, or “kill chain,” of an APT attack to create a holistic view towards each step in the chain, of which identification of zero-day exploits plays a major component.

ETHICAL HACKING TRAINING – RESOURCES (INFOSEC)

Step by step analysis of APT attack

Each step in an APT attack includes a very well planned and studied move by the attackers. This includes creating internal blueprint of the IT infrastructure of the organization, malware engineering, social engineering attacks and undetected data extraction.

• Target Selection

  The first stage of in an APT attack is choosing the target organization. Few attackers choose a victim first and then perform research about then through websites, employee resumes and web data looking for the company’s use of Software and Infrastructure designs that are exploitable or comfortable to work with. Others go hunting for “accidental victims.” For example, in 2007,hacker Albert Gonzalez went war-driving in search of organizations that had vulnerable WiFi networks, and he found his victim, retail giant T.J. Maxx.

• Information Gathering

  The attackers perform a complete study about their victim profile to create a blueprint of its IT systems and search for exploitable vulnerabilities to penetrate all defenses. Details about sites, network topology, domain, internal DNS and DHCP servers, internal IP address ranges, and any other exploitable ports or services are captured. Depending on the target, this process might take some time, as large organizations tend to invest a lot more in security and set up multiple layers of defense. Knowledge is power, and the more insight a cybercriminal gains into a targeted network, the higher the chances of successful covert penetration and malware deployment.

• Point of Entry

  After collecting sufficient information to initiate an attack, they narrow down the point of entry of exploitation. Attackers also study about the security solution defenses and known attack signatures that the victim might possess. In most scenarios, attacker’s phish their target company’s employees into opening a malicious attachment or clicking a crafted URL in the hopes of delivering their payload by exploiting a zero-day vulnerability in a common browser or application such as Adobe, Java, or Microsoft Office. As discussed earlier, they can also exploit any zero-day vulnerabilities of the software used by the employees. For instance, attackers used Adobe ColdFusion’s vulnerabilities to break into the networks of LaCie, the computer hardware manufacturer.

• Planting Malware on compromised machine

  Once the attacker executes the exploit on an employee’s machine, the exploit injects malicious code into the PC to install a backdoor or allowing full access into the machine. In RSA SecureID attack where the attacker stole SecureID data by installing a customized remote administration tool (RAT) known as Poison Ivy, RAT variant. Poison Ivy has been used extensively in many other attacks, including GhostNet. Often these remote administration tools, the purpose of which is simply to allow external control of the PC or server, are set up in a reverse-connect mode, which means they pull commands from the central command & control(C&C) servers, then execute the commands, rather than getting commands remotely. This connectivity method makes them more difficult to detect, as the PC reaches out to the command and control rather than the other way around.

• Escalate privileges

  The attacker first harvests access credentials from the compromised PC or users (user, domain admin, and service accounts). They then perform privilege escalation on non-administrative users in the targeted systems, and then moved on to gain access to key high value targets, which included process experts and IT and Non-IT specific server administrators.

  To gain login credentials, attackers use keyloggers, ARP spoofing, and hooking tools among others to obtain credentials. Hooking tools basically hook functions related to password authentication while ARP spoofing tools sniff conversations between two systems or more in a network packet though spoofed ARP to steal credentials. Pwdump is another tool for getting password hashes from the Windows registry. Other tools used are Windows Credential Editor (WCE), Mapiget, Lslsass, Gsecdump, and CacheDump.

  Attackers can also use a technique called “pass the hash” which involves the use of a hash instead of a plaintext password in order to authenticate and gain higher access. They can also use a brute force attack, which is simply guessing passwords through a predefined set of passwords.

• Command and Control Communication

  Once inside the target organization, APTs are typically remotely orchestrated via “command and control” (C&C) communications between the infiltrated systems and the attackers themselves. Throughout the attack, the perpetrators will also use this channel to open and manipulate backdoor network access to discover and exfiltrate their targeted data.

  Unlike botnets that have high volume traffic to thousands of zombie PCs, APT C&C traffic is intermittent with low volume making them harder to spot. Attackers also take measures to go undetected by continuously changing IP addresses or traffic redirection via proxy servers. C&C communications that blend in with normal web traffic, use or spoof legitimate apps or sites, or use attacker created, internal C&C servers cannot be detected without advanced, local network monitoring

• Lateral movement

  If the attacker thinks they can exist in the environment without being detected, they may continue in a stealth mode for a long while. If they think they run the risk of being detected, however, they move much faster. Lateral movement usually involves activities related to reconnaissance, credentials stealing, and infiltrating other computers.

  Remote control tools enable attackers to access other desktops in the network and perform actions like executing programs, scheduling tasks, and managing data collections on other systems. Few tools and techniques used for this purpose include remote desktop tools, PsExec, and Windows Management Instrumentation (WMI).

  When communication with the compromised systems and C&C (command and control) servers is established, threat actors need to sustain persistent access across the network. To do so, they have to move laterally within the network and gain higher privileges through the use of different tools. This, in turn, enables threat actors to have access to servers, which contain valuable information—the company “crown jewels

• Asset Discovery and Persistance

  Several techniques like port scanning and network analysis are used to identify valuable servers and services that house data of interest. Some of the tools used in this activity include netstat, a command-line tool that can get network connection information via active connections and open ports. This may be used for identifying running services or internal servers accessed by the compromised computer. Port scanning tools check open network ports in order for attackers to make a tunnel connection between the compromised system and his system. Port forwarding tools like ZXPortMap and ZXProxy (aka AProxy) are used to create a tunnel connection to bypass firewall protection.

  

• Data Exfiltration

  It is the unauthorized transfer of sensitive information from a target’s network to external location which the threat actor controls. After discovering the data of interest, the APT generally gathers the data into an archive and then compresses and encrypts the archive. This enables them to hide the content of the archive from deep packet inspection and data loss prevention techniques. The next step involves the exfiltration of the data from the victims system.

  Because data routinely moves in and out of networked enterprises, data exfiltration can closely resemble normal network traffic, making detection of exfiltration attempts challenging for IT security groups. Once sensitive information is gathered, the data is funneled to an internal staging server where it is chunked, compressed, and often encrypted for transmission to external locations under an attacker’s control. Tools include Lz77 (used for compression of applications to help exfiltrate data), ZXProxy (Helps redirect HTTP/HTTPS connections for source obfuscation), LSB-Steganography (Uses steganography techniques to embed files into images), ZXPortMap (Traffic redirection tool, which helps to obfuscate the source of connections.), ZXHttpServer (Small HTTP server that is deployable and extremely flexible). Many of these tools are copied to victim machines, and are often never removed by the APT actors.

• Covering the tracks

  Once attackers have accomplished their goal, the attackers take care not to leave any traces of their covert operations. There have been instances where attackers left a backdoor open through which they waltzed in several times and robbed a victim repeatedly without being caught.

If new target data continues to become available (new customer records or updated business plans) and holds value for the attacker, data extraction phase continues for a longer duration.

Eventually, the attack will stop, either because the attacker has achieved their goal or because the victim notices and cuts off the attack. Once the APT steals the data, they then perform multiple criminal activities like:

• Selling the data.
• Threatens to publicly disclose the data
• Asks the victim to pay a ransom.

Conclusion:

Targeted attacks are successfully bypassing traditional security defenses, and the majority of IT professionals now believe their organizations have been targeted. According to an Information Week Security article by Mathew Schwartz, “APTs take a low-and-slow approach that’s difficult to detect, but which has a high likelihood of success. Attackers only need to trick a single employee into opening a piece of malware that exploits a zero-day vulnerability, thus giving them access to not just the employee’s PC, but potentially the entire corporate network.”

A strong defense against APTs must have in-depth detection and analysis capabilities across all phases of the attack lifecycle. Network administrators must implement application white listing to prevent unnecessary malwares from being installed or used on the employees systems. Organizations must utilize SIEM tools to analyze network logs. This might even help in a forensic analysis in case of data breaches.

Original Post: http://resources.infosecinstitute.com/anatomy-of-an-apt-attack-step-by-step-approach/

Resources:

http://securityaffairs.co/wordpress/33999/cyber-crime/apt-and-avt-techniques.html

http://www.trendmicro.co.in/cloud-content/us/pdfs/business/white-papers/wp_deepdiscovery.pdf

https://www.fireeye.com/blog/

http://nextpage.com/threatinsight/posts/apt-attack-utilizing-latest-internet-explorer-zero-day-vulnerability.php

https://blogs.rsa.com/anatomy-of-an-attack/

A Few Tips to Code PHP Securely

PHP is the most used language on the web. It is used to develop  webpages and help a webpage to respond to its users properly. Websites like Facebook, Yahoo, Wikipedia also uses PHP. The Language itself is easy to understand however if you make an error in your coding than you may give your audience more information than you intend to. Information like your folder structure and other things can be leaked because of poor programming. This is the reason why I’m here today. Here is a few tips that can help you to code PHP securely.

1. Use error_reporting(0);

When you are running PHP locally i.e on your computer using XAMPP or WAMP then you need to see the errors because these help you to solve the issues.

When your website goes live then you do not need to show these errors. Because these errors can compromise your Privacy. Instead of using nothing or error_reporting(E_ALL); on local server, you need to use error_reporting(0); when you make your website live. This Would Help You a lot by not showing any error to your viewers.

2. Using POST Method Instead Of GET Method

If you have been programming for a long time then you might be aware of POST and GET methods. Right!!. If not tell me in comment section below, i will make a new post on that also. When you use GET methods like the image shows below then you tell your viewers what variables you are using and then any clever viewer can just modify your variable’s value and could get into your server.

So be aware and ensure to use the POST method instead of GET method.

3. Validate Input

In addition to escaping character, another great way to protect input is to Validate it.

For example :- You have a Sign up form where you have an email section, password section and date of birth section. Here you need to Validate the Email And D.O.B Section. You need to Make sure that Email Section Contains a @ and The D.O.B section Must contain only numbers.

This way you secure your website From some kind of SQL injections.

You can use the preg_match(); to do so.

4. Check For XSS Attack In User Input

You yourself need to check your website against XSS attack. Because these attacks can be dangerous. You can check this in the section where your users can comment or post something. Just go to comment section and try putting <script>alert(‘OMG. There is a possibility.’);</script> . If this code result in nothing then your website is safe. And If you get a message then you need to secure your website from XSS attacks.

You can try to disable the use of things like < or > in the comment section. Or Try to Usepreg_replace(); .

5. Protection against SQL Injection

SQL Injection is a very dangerous and critical problem faced by us. Information about our users may be vulnerable to hackers. This problem arises when we do not replace ‘ or ‘’  in our input system.

Luckily this may be fixed. Just add mysqli_real_escape_string to your PHP code. For Example:- You can use it like this. mysqli_real_escape_string($_POST[‘email’]);

This one line of code can make a big change to your website and protect your website.

These were just a few tips that can help you to write your PHP code securely. Just remember to always follow these tips while writing code.

Original Post: http://codingsec.net/2015/03/few-tips-to-code-php-securely/

Lax Security Opens the Door for Mass-Scale Abuse of SOHO Routers

Small Office / Home Office (SOHO) router security has recently become a hot topic. For those who are unfamiliar with the situation, it can best be described as negligent, with ISPs, vendors, and users sharing a long tradition of disregarding basic security practices. The result of this negligence is the existence of hundreds of thousands—more likely millions—of hacker-controlled routers used to attack the Internet ecosystem and interconnected networks.

Several dozen Imperva Incapsula customers were recently targeted by one such DDoS botnet comprised of tens of thousands of hijacked routers. After informing the major companies involved, we are sharing attack details in an attempt to raise awareness about the dangers posed by under-secured, connected devices.

The attacks we will describe are enabled by what we perceive as particularly careless security practices. Many of these botnet devices remain active, continuing to play a role in attack attempts against our clients and other websites—even as this is being written.

Attack Description

The DDoS campaign in question amounts to a series of application layer HTTP flood attacks launched against 60 Incapsula-protected domains, which share no common relation.

We first encountered these attacks on December 30, 2014 and have been mitigating them ever since. In the last 30 days, after a short-lived lull, we saw the escalate to a new height, with double the number of attacking IPs.

Figure 1: History of DDoS attacks from routers infected with MrBlack malware

This escalation piqued our interest, prompting further investigation by the Incapsula security team. Our analysis revealed that this wave of attacks is a part of a much larger DDoS assault targeting hundreds of other domains outside of the Incapsula network, and includes other attack vectors—including network layer barrages.

Botnet Profile

What makes this specific DDoS campaign stand out is the botnet from which it’s being launched, one consisting of a large number of SOHO routers, predominantly ARM-based Ubiquiti devices.

Faced with this homogenous botnet, our security investigators’ initial assumption was that the routers were compromised by a shared firmware vulnerability. However, further inspection revealed that all units are remotely accessible via HTTP and SSH on their default ports. On top of that, nearly all are configured with vendor-provided default login credentials.

Figure 2: By punching in its IP and the default credentials, anybody can remotely access this Ubiquiti router

This combination invites trouble. At the risk of overstating the obvious, this level of access lets any perpetrator easily:

• eavesdrop on all communication.
• perform man-in-the-middle (MITM) attacks (e.g., DNS poisoning).
• hijack cookies.
• gain access to local network devices (e.g., CCTV cameras).

Setting aside the exploitation discussion, we have determined that all these exposed routers were injected with variants of MrBlack malware (a.k.a. Trojan.Linux.Spike.A), whose signatures we’ve identified while mitigating the attack.

Figure 3: Incoming DDoS traffic from a compromised router (Hi-res image)

After inspecting a sample of 13,000 malware files, we saw that on average, each compromised router held four variants of MrBlack malware, as well as additional malware files, including Dofloo and Mayday, which are also used for DDoS attacks.

Malware	Type	Variants Observed	Commonness
MrBlack	DDoS tool	137	86.57%
Dofloo	DDoS tool	19	5.48%
Mayday	DDoS tool	24	2.84%
BillGates	DDoS tool	5	2.30%
Skynet	Backdoor	5	1.46%
Unknown/New	DDoS Bot	2	1.35%

Botnet Geo-locations and C2 Data

During the 111-day period (from December 30 2014 to April 19 2015) Incapsula recorded attack traffic from 40,269 IPs belonging to 1600 ISPs worldwide. We were also able to trace the IP addresses of 60 command and control systems used by perpetrators to remotely direct malicious traffic.

More than 85 percent of all compromised routers are located in Thailand and Brazil, while the majority of the C2s are located in the US (21%) and China (73%). Overall, we’ve documented attack traffic from 109 countries around the world.

Figure 4: Top attacking countries, by number of IPs

Based on the profile of targets and the attack patterns, we know these compromised routers are being exploited by several groups or individuals. Given how easy it is to hijack these devices, we expect to see them being exploited by additional perpetrators. Even as we conducted our research, the Incapsula security team documented numerous new malware types being added—each compounding the threat posed by the existence of these botnet devices.

Figure 5: Attack heat map: Botnet and C2 geo-locations

Self-sustaining Botnets

Our analysis reveals that miscreants are using their botnet resources to scan for additional routers to add to their “flock.” They do so by executing shell scripts, searching for devices having open SSH ports which can be accessed using default credentials.

Figure 6: Scanning script used to identify remotely accessible routers

Facilitating the infiltration, all of these under-secured routers are clustered in the IP neighborhoods of specific ISPs, that provide them in bulk to end users. For perpetrators, this is like shooting fish in a barrel, which makes each of the scans that much more effective. Using this botnet also enables perpetrators to execute distributed scans, improving their chances against commonplace blacklisting, rate-limiting and reputation-based defense mechanisms.

Copycats or Lizard Stresser v2?

Those who follow the escapades of Lizard Squad have probably noticed that the above-described botnet shares several similarities with Lizard Stresser—the group’s DDoS-for-hire service.

Specifically, Lizard Squad’s botnet was also reportedly built on an infrastructure of under-secured routers that were likewise injected with malicious code, used to scan for other similarly vulnerable devices.

Despite several outward similarities, however, the two botnets don’t appear to be one and the same.

Most tellingly, the malware types observed in both cases are different. While Lizard Squad were known to use Linux.BackDoor.Fgt.1 to control their router-based botnet, the hijacked routers that we observed were mostly infected with Spike malware.

Still, looking at the historical attack data, we continue to find some interesting parallels between the attacks on our client and what has been reported about Lizard Squad’s shenanigans.

In both cases we observe similar peaks and valleys of activity. Notably, the assault on our clients started on December 30, nearly at the same exact time that Lizard Stresser was firstannounced. From there, after observing high frequency of attacks in January 2015, we saw the assault flat line in February, a week or so after Lizard Squad’s website was brought downby Anonymous.

Finally, we saw attacks become more frequent in early April, with the largest of the bunch occurring days before Lizard Squad remerged on Twitter with a promise of a new, and more powerful, botnet.

It should be pointed out that none of these circumstantial correlations offer any hard evidence of the groups’ involvement. If anything, they present us with several open questions about the possible evolution of Lizard Squad’s botnet resources and the existence of copycats that are following in the groups footsteps.

With this in mind, we ask all security researchers with any additional information about the perpetrators that are attacking on our clients, to reach us at info@incapsula.com.

Taking Action

Prior to publishing this report, Incapsula contacted the vendor of the routers and the ISPs whose routers and networks we found to be most open to abuse.

Revisiting the notion of shared responsibility, we strongly urge router owners to disable all remote (WAN) access to their router management interfaces. To verify that your own router is not open to remote access, you can use this tool from YouGetSignal to scan the following ports: SSH (22), Telnet (23) and HTTP/HTTPS (80/443).

Regardless of the result, we also strongly advise all router owners to change the default login credentials, if they haven’t done so already. You can download these user guides to learn how to do so on Ubiquiti routers. If you have other routers you should contact the vendor for the applicable user guide.

Finally, if you believe your router(s) is already compromised, upgrade your router’s firmware to the latest version provided by the manufacturer.If you never done this before, we suggest reading this post, from the Super User community blog, about “Router Flashing for mere Humans”.

VENOM – Not as Deadly as a Heartbleed

This morning, CrowdStrike issued a vulnerability disclosure for CVE-2015-3456 — branded VENOM(Virtualized Environment Neglected Operations Manipulation). VENOM is a security vulnerability in the virtual floppy drive code used by many computer virtualization platforms.

I’ve seen a few articles from reputable outlets claiming that the vulnerability is “bigger than Heartbleed.” While I do believe companies should absolutely apply patches as they become available, I’m not convinced this vulnerability will have the same level of severity as Heartbleed.

If we are measuring the importance of a vulnerability solely on how widespread the vulnerability is, VENOM is certainly “bigger” than Heartbleed. It impacts numerous virtualization platforms and appliances, notably Xen, KVM and the native QEMU client, thought it does not impact VMware, Microsoft Hyper-V and Bochs hypervisors. In addition, Amazon has stated its AWS systems are not affected. But despite the sheer breadth of systems that could be impacted, the severity is not as alarming for a few key reasons.

There isn’t currently an exploit available

At Veracode, when we are measuring the severity of a vulnerability and determining how we need to respond, one of the first questions we ask is if an exploit is already available. In this case, the answer appears to be no. CrowdStrike states that “Neither CrowdStrike nor our industry partners have seen this vulnerability exploited in the wild.” This does not mean for certain an exploit does not exist, but chances are very low.

In addition to no exploit being available, all indications are that creating one is not a trivial effort. Because it would take a lot of effort to create an executable exploit, a cybercriminal would have to be highly motivated to do so. Which brings us to …

There is very little chance the vulnerability will be exploited on any scale

While exploiting a vulnerability like Heartbleed allows an attacker to probe millions of systems, VENOM simply wouldn’t be exploitable at the same scale. Vulnerabilities like VENOM are mostly viewed as an avenue for a highly targeted attack like corporate espionage, cyberwarfare or the like. Again, that doesn’t mean there aren’t cybercriminals motivated by espionage or warfare that couldn’t create an exploit. It just means the chances of being a victim are quite low. Especially given …

Attackers have to already be in the target’s system to access the vulnerability

This is another factor we take into account when determining how we will respond to a new vulnerability disclosure — is the vulnerability susceptible to remote attacks? VENOM is not. While this does not make exploitation impossible — especially in a public cloud environment — it is a complicating factor that makes an exploit less likely. Attackers are more likely to get into your enterprise environment using SQL injection or some other web application vulnerability than they are through VENOM.

Branded vulnerabilities are here to stay; this certainly isn’t the last one we will see. And CrowdStrike is doing a great service by letting the world know about an existing vulnerability. By responsibly disclosing this vulnerability in a timely manner, CrowdStrike is giving enterprises an opportunity to patch before a reliable exploit is available, and that helps make us all more secure. Branding a vulnerability also helps bring attention to the importance of security and vulnerability testing. The downside to branded vulnerabilities is that they can cause panic leading to apathy. If every branded vulnerability causes enterprises to instantly react, eventually they will become numb to the noise. If everything is an emergency, nothing is.

I recommend companies update their systems as patches become available, but do not overreact. VENOM is not the next Heartbleed.

Original Post: https://www.veracode.com/blog/2015/05/venom-%E2%80%93-not-deadly-heartbleed

CrowdStrike Venom vulnerability:  http://venom.crowdstrike.com/

SOC Analyst Pyramid

Introduction

Last weekend, I did a 10 minute fireside chat during lunch at BSidesSATX 2015 [1].  It was an informal presentation, where I discussed some of the issues facing security analysts working at an organization’s Security Operations Center (SOC).

With only 10 minutes, the largest part of that presentation covered a “SOC analyst pyramid” of activity any organization will encounter.

For the presentation, security analysts are defined as people who monitor their organization’s network for near-real-time detection of malicious activity.  Security analysts review alerts from their organization’s intrusion detection systems (IDS) or security information and event management (SIEM) appliances.  These alerts are based on various sources, such as network traffic and event logs.

SOC Analyst Pyramid

Below is a visual representation of this pyramid:

As seen in the image above, the pyramid from top to bottom reads:

• Targeted attacks
• Malicious activity – not blocked
• Malicious activity – blocked or not applicable
• False positives or non-threat

Base of the SOC Analyst Pyramid

The base of the SOC analyst pyramid consists of false positives or valid activity unique to your organization’s network.  In my years as an analyst, investigating this activity took up the majority of my time.  At times, you’ll need to document why an alert triggers a false positive, so it can be filtered and allow the team to focus on real suspicious activity.

In my experience, no matter how well-tuned your security monitoring system is, analysts spend most of their time at this level of the pyramid.

Next Tier: Malicious Activity – Blocked or Not Applicable

The next level involves malicious activity that’s either blocked or not applicable.  Blocked activity includes spam with malware attachments (malspam) blocked by your organization’s spam filters.  Non-applicable activity includes certain types of scanning.  The intent is malicious, but the scans are blind and not applicable to the targeted host.  For example, here’s a short list of activity from the error logs of a server I run:

That server doesn’t run WordPress, nor does it have any sort of web-based administrative login, but I’ll find WordPress-based scans hitting the server’s IP every day.  That shows malicious intent, but it’s not applicable.

SOC analysts worried about near-real-time detection of malicious activity generally don’t spend much time with this tier of the pyramid.

Next Tier: Malicious Activity – Not Blocked

The next tier of the pyramid involves malicious activity that somehow makes it past your organization’s various security measures. This level includes drive-by infections from an exploit kit after viewing a compromised website.  Depending on your organization’s policies, adware might be an issue.  Resolving issues involving adware or potentially unwanted programs (PUP) might give SOC personnel practice for resolving hosts infected with actual malware.  Just make sure analysts don’t focus on the adware/PUP.  The focus of a SOC should always be on malicious activity.

This level of the pyramid is where analysts develop their skill in recognizing malicious activity.  Exploit kit traffic might not infect a user’s computer.  SOC personnel should be able to examine this sort of malicious traffic and determine if a host actually became infected.  After an alert, I’ve seen too many people assume a host was infected without digging in deeper to see what actually happened.

Malware or compromised hosts found at this level of the pyramid are not targeted.  This type of malicious activity is a concern for any organization.  It’s not limited to your employer.

Top of the Pyramid: Targeted Attacks

This tier is where a SOC proves its value to an organization.  If bad actors, criminal groups, or hostile foreign agents gain a foothold in your organization’s infrastructure, you might not be able to get rid of them.  Detecting intrusions early and preventing these bad actors from further access is extremely important.  Any number of sources will tell you data breaches are not a matter of “if” but “when” [2][3][4].

Targeted attacks include spear phishing attempts to gather login credentials from specific members.  Personnel using a chat system for sales or support can also be targeted.  Denial of Service (DoS) attacks or Distributed DoS (DDoS) attacks are usually at this tier.  Watering hole attacks [5] are also an issue.

Final Words

I’ve been a SOC analyst for two employers: one was the government, and the other is private sector.  In both cases, I believe the SOC analyst pyramid applies.  Feel free to leave a comment, if you have any opinions on the matter.

Original Post: http://dshield.org/forums/diary/SOC+Analyst+Pyramid/19677/

Russia and China sign cyber security pact, vow not to hack each other

Threat Spotlight: Rombertik – Gazing Past the Smoke, Mirrors, and Trapdoors

This post was authored by Ben Baker and Alex Chiu.

Executive Summary

Threat actors and security researchers are constantly looking for ways to better detect and evade each other.  As researchers have become more adept and efficient at malware analysis, malware authors have made an effort to build more evasive samples.  Better static, dynamic, and automated analysis tools have made it more difficult for attackers to remain undetected. As a result, attackers have been forced to find methods to evade these tools and complicate both static and dynamic analysis.

Table of Contents
Executive Summary
The 10,000 Foot View at Rombertik
Analysis
A Nasty Trap Door
The Actual Malware
Coverage and Indicators of Compromise
Conclusion

It becomes critical for researchers to reverse engineer evasive samples to find out how attackers are attempting to evade analysis tools. It is also important for researchers to communicate how the threat landscape is evolving to ensure that these same tools remain effective. A recent example of these behaviors is a malware sample Talos has identified as Rombertik. In the process of reverse engineering Rombertik, Talos discovered multiple layers of obfuscation and anti-analysis functionality. This functionality was designed to evade both static and dynamic analysis tools, make debugging difficult. If the sample detected it was being analyzed or debugged it would ultimately destroy the master boot record (MBR).

Talos’ goal is to protect our customer’s networks.  Reverse engineering Romberik helps Talos achieve that goal by better understanding how attackers are evolving to evade detection and make analysis difficult.  Identifying these techniques gives Talos new insight and knowledge that can be communicated to Cisco’s product teams.  This knowledge can then be used to harden our security products to ensure these anti-analysis techniques are ineffective and allow detection technologies to accurately identify malware to protect customers.

The 10,000 Foot View at Rombertik

At a high level, Romberik is a complex piece of malware that is designed to hook into the user’s browser to read credentials and other sensitive information for exfiltration to an attacker controlled server, similar to Dyre. However, unlike Dyre which was designed to target banking information, Rombertik collects information from all websites in an indiscriminate manner.

Rombertik has been identified to propagate via spam and phishing messages sent to would-be victims.  Like previous spam and phishing campaigns Talos has discussed, attackers use social engineering tactics to entice users to download, unzip, and open the attachments that ultimately result in the user’s compromise.

In this sample, the message observed in Rombertik’s distribution appears to come from the “Windows Corporation,” an organization that possesses “state-of-the-art manufacturing quality processes.”  The attackers attempt to convince the user to check the attached documents to see if their business aligns with the target user’s organization.  If the user downloads and unzips the file, the user then sees a file that looks like a document thumbnail.

While this file may appears to be some sort of PDF from the icon or thumbnail, the file actually is a .SCR screensaver executable file that contains Rombertik.  Once the user double clicks to open the file, Rombertik will begin the process of compromising the system.

The process by which Rombertik compromises the target system is a fairly complex with anti-analysis checks in place to prevent static and dynamic analysis.  Upon execution, Rombertik will stall and then run through a first set of anti-analysis checks to see if it is running within a sandbox.  Once these checks are complete, Rombertik will proceed to decrypt and install itself on the victims computer to maintain persistence.  After installation, it will then launch a second copy of itself and overwrite the second copy with the malware’s core functionality.  Before Rombertik begins the process of spying on users, Rombertik will perform once last check to ensure it is not being analyzed in memory.  If this check fails, Rombertik will attempt to destroy the Master Boot Record and restart the computer to render it unusable.  The graphic below illustrates the process.

Analysis

From the beginning, Rombertik incorporates several layers of obfuscation along with anti-analysis functionality.  Obfuscating the functionality of a malware sample can be accomplished in many different ways.  A common method is to include garbage code to inflate the volume of code an analyst might have to review and analyze.  In this case, the unpacked Rombertik sample is 28KB while the packed version is 1264KB. Over 97% of the packed file is dedicated to making the file look legitimate by including 75 images and over 8000 functions that are never used. This packer attempts to overwhelm analysts by making it impossible to look at every function.

As we started to slowly peel back the layers and focus on the subset of functions that are actually used, we observed an interesting sandbox evasion technique. A common technique to evade sandboxes is to sleep for extended lengths of time with the intention of forcing the sandbox to time out before the malware “wakes up” and begins executing.  In response, sandboxes got better at detecting and responding when malware slept for extended periods of time.  Rombertik employs a similar approach to delay execution, but does so without sleeping.  Rombertik instead writes a byte of random data to memory 960 Million times.  This is designed to consume time, like sleeping, but presents a couple disadvantages for sandboxes and application tracing tools.  Sandboxes may not be able to immediately determine that the application is intentionally stalling since it’s not sleeping.  The other disadvantage is that the repetitive writing would flood application tracing tools.  If an analysis tool attempted to log all of the 960 Million write instructions, the log would grow to over 100 gigabytes. Even if the analysis environment was capable of handling a log that large, it would take over 25 minutes just to write that much data to a typical hard drive.  This complicates analysis.

After intentionally stalling by writing to memory repeatedly, Rombertik checks to see if analysis tools have modified code in the Windows API ZwGetWriteWatch routine.  It does this by calling ZwGetWriteWatch with invalid arguments.  If the routine does not return with a specific error, Rombertik terminates. The assumption behind checking for a specific error versus a generic error is to check for sandboxes that suppress errors returned from API routine calls.   Once the sandbox check is complete, Rombertik calls the Windows API OutputDebugString function 335,000 times as an anti-debugging mechanism.  Finally, an anti-analysis function within the packer is called to check the username and filename of the executing process for strings like “malwar”, “sampl”, “viru”, and “sandb”. If the packer detects any of these substrings, it will stop unpacking and terminate.  At this point, the initial anti-analysis checks are complete.

Once the packer has run through initial anti-analysis checks, it will check to see if it is executing from %AppData%\rsr\yfoye.exe.  If the packer is not executing from there, it will proceed to install itself in order to ensure persistence across system reboots before continuing on to execute the payload. To install itself, Rombertik first creates a VBS script named “fgf.vbs”, which is used to kick off Rombertik every time the user logs in, and places the script into the user’s Startup folder.  Rombertik then creates %AppData%\rsr\yfoye.bat and moves the packed version of itself into %AppData%\rsr\yfoye.exe.

If Rombertik detects it is already executing from %AppData%\rsr\yfoye.exe, the malware will then begin decrypting and executing the main unpacking code in memory.  Rombertik will then proceed to execute yfoye.exe a second time to create a new instance of the process.  Once the unpacking is complete, Rombertik will overwrite the memory of the new process with the unpacked executable code.  The unpacking code is monstrous and has many times the complexity of the anti-analysis code.  The code contains dozens of functions overlapping with each other and unnecessary jumps added to increase complexity. The result is a nightmare of a control flow graph with hundreds of nodes.  Figures 3 and 4 help illustrate how complex the unpacking code in comparison to the all the code that performs anti-analysis checks.

A Nasty Trap Door

Once the unpacked version of Rombertik within the second copy of yfoye.exe begins executing, one last anti-analysis function is run — which turns out to be particularly nasty if the check fails.  The function computes a 32-bit hash of a resource in memory, and compares it to the PE Compile Timestamp of the unpacked sample. If the resource or compile time has been altered, the malware acts destructively. It first attempts to overwrite the Master Boot Record (MBR) of PhysicalDisk0, which renders the computer inoperable. If the malware does not have permissions to overwrite the MBR, it will instead destroy all files in the user’s home folder (e.g. C:\Documents and Settings\Administrator\) by encrypting each file with a  randomly generated RC4 key. After the MBR is overwritten, or the home folder has been encrypted, the computer is restarted.

The Master Boot Record starts with code that is executed before the Operating System. The overwritten MBR contains code to print out “Carbon crack attempt, failed”, then enters an infinite loop preventing the system from continuing to boot.

The MBR also contains information about the disk partitions. The altered MBR overwrites the bytes for these partitions with Null bytes, making it even more difficult to recover data from the sabotaged hard drive.

Once the computer is restarted, the victim’s computer will be stuck at this screen until the Operating System is reinstalled:

Effectively, Rombertik begins to behave like a wiper malware sample, trashing the user’s computer if it detects it’s being analyzed.  While Talos has observed anti-analysis and anti-debugging techniques in malware samples in the past, Rombertik is unique in that it actively attempts to destroy the computer if it detects certain attributes associated with malware analysis.

The Actual Malware

At this point, Rombertik will assume that all anti-analysis checks have passed and will actually begin doing what was originally intended — stealing user data.  Rombertik will scan the user’s currently running process to determine if a web browser is currently running.  If Rombertik detects an instance of Firefox, Chrome, or Internet Explorer, it will inject itself into the process and hook API functions that handle plain text data. Once accomplished, Rombertik is then able to read any plain-text data the user might type into their browser and capture this input before it gets encrypted if the input is to be sent over HTTPS. This enables the malware to collect data such as usernames and passwords from almost any website.  Rombertik does not target any site in particular, such as banking sites, but instead, attempts to steal sensitive information from as many websites as possible.  The collected data is then Base64 encoded and forwarded to http://www.centozos.org.in/don1/gate.php (in this example) over HTTP with no encryption.

Coverage and Indicators of Compromise

Sample Analysed (SHA256)

0d11a13f54d6003a51b77df355c6aa9b1d9867a5af7661745882b61d9b75bccf

Command-and-Control Servers

http://www.centozos[.]org[.]in

Conclusion

Rombertik is a complex piece of malware with several layers of obfuscation and anti-analysis functionality that is ultimately designed to steal user data.  Good security practices, such as making sure anti-virus software is installed and kept up-to-date, not clicking on attachments from unknown senders, and ensuring robust security policies are in place for email (such as blocking certain attachment types) can go a long way when it comes to protecting users.  However, a defense in depth approach that covers the entire attack continuum can help identify malware and assist in remediation in the event that an attacker finds a way to evade detection initially.

For Talos, understanding how malware changes and evolves is essential to developing detection content and ensuring that static, dynamic, and automated analysis tools remain effective. We must adapt, change, and respond accordingly to address the evolving threat landscape. Looking forward, Talos expects these methods and behaviors to be adopted by other threat actors in the future.

Original Post: http://blogs.cisco.com/security/talos/rombertik

Introducing FIDO: Automated Security Incident Response

We’re excited to announce the open source release of FIDO (Fully Integrated Defense Operation – apologies to the FIDO Alliance for acronym collision), our system for automatically analyzing security events and responding to security incidents.

Overview

The typical process for investigating security-related alerts is labor intensive and largely manual. To make the situation more difficult, as attacks increase in number and diversity, there is an increasing array of detection systems deployed and generating even more alerts for security teams to investigate.

Netflix, like all organizations, has a finite amount of resources to combat this phenomenon, so we built FIDO to help. FIDO is an orchestration layer that automates the incident response process by evaluating, assessing and responding to malware and other detected threats.

The idea for FIDO came from a simple proof of concept a number of years ago. Our process for handling alerts from one of our network-based malware systems was to have a help desk ticket created and assigned to a desktop engineer for follow-up – typically a scan of the impacted system or perhaps a re-image of the hard drive. The time from alert generation to resolution of these tickets spanned from days to over a week. Our help desk system had an API, so we had a hypothesis that we could cut down resolution time by automating the alert-to-ticket process. The simple system we built to ingest the alerts and open the tickets cut the resolution time to a few hours, and we knew we were onto something – thus FIDO was born.

Architecture and Operation

This section describes FIDO’s operation, and the following diagram provides an overview of FIDO’s architecture.

Detection

FIDO’s operation begins with the receipt of an event via one of FIDO’s detectors. Detectors are off the shelf security products (e.g. firewalls, IDS, anti-malware systems) or custom systems that detect malicious activities or threats. Detectors generate alerts or messages that FIDO ingests for further processing. FIDO provides a number of ways to ingest events, including via API (the preferred method), SQL database, log file, and email. FIDO supports a variety of detectors currently (e.g. Cyphort, ProtectWise, CarbonBlack/Bit9) with more planned or under development.

Analysis and Enrichment

The next phase of FIDO operation involves deeper analysis of the event and enrichment of the event data with both internal and external data sources. Raw security events often have little associated context, and this phase of operation is designed to supplement the raw event data with supporting information to enable more accurate and informed decision making.

The first component of this phase is analysis of the event’s target – typically a computer and/or user (but potentially any targeted resource). Is the machine a Windows host or a Linux server? Is it in the PCI zone? Does the system have security software installed and the latest patches? Is the targeted user a Domain Administrator? An executive? Having answers to these questions allows us to better evaluate the threat and determine what actions need to be taken (and with what urgency). To gather this data, FIDO queries various internal data sources – currently supported are Active Directory, LANDesk, and JAMF, with other sources under consideration.

In addition to querying internal sources, FIDO consults external threat feeds for information relevant to the event under analysis. The use of threat feeds help FIDO determine whether a generated event may be a false positive or how serious and pervasive the issue may be. Another way to think of this step is ‘never trust, always verify.’ A generated alert is simply raw data – it must be enriched, evaluated, and corroborated before actioning. FIDO supports several threats feeds, including ThreatGrid and VirusTotal, with additional feeds under consideration.

Correlation and Scoring

Once internal and external data has been gathered about a given event and its target(s), FIDO seeks to correlate the information with other data it has seen and score the event to facilitate ultimate disposition. The correlation component serves several functions – first – have multiple detectors identified this same issue? If so, it could potentially be a more serious threat. Second – has one of your detectors already blocked or remediated the issue (for example – a network-based malware detector identifies an issue, and a separate host-based system repels the same item)? If the event has already been addressed by one of your controls, FIDO may simply provide a notification that requires no further action. The following image gives a sense of how the various scoring components work together.

Scoring is multi-dimensional and highly customizable in FIDO. Essentially, what scoring allows you to do is tune FIDO’s response to the threatand your own organization’s unique requirements. FIDO implements separate scoring for the threat, the machine, and the user, and rolls theseparate scores into a total score. Scoring allows you to treat PCI systems different than lab systems, customer service representativesdifferent than engineers, and new event sources different than event sources with which you have more experience (and perhaps trust).Scoring leads into the last phase of FIDO’s operation – Notification and Enforcement.

Notification and Enforcement

In this phase, FIDO determines and executes a next action based on the ingested event, collected data, and calculated scores. This action may simply be an email to the security team with details or storing the information for later retrieval and analysis. Or, FIDO may implement more complex and proactive measures such as disabling an account, ending a VPN session, or disabling a network port. Importantly, the vast majority of enforcement logic in FIDO has been Netflix-specific. For this reason, we’ve removed most of this logic and code from the current OSS version of FIDO. We will re-implement this functionality in the OSS version when we are better able to provide the end-user reasonable and scalable control over enforcement customization and actions.

Open Items & Future Plans

Netflix has been using FIDO for a bit over 4 years, and while it is meeting our requirements well, we have a number of features and improvements planned. On the user interface side, we are planning for an administrative UI with dashboards and assistance for enforcement configuration. Additional external integrations planned include PAN, OpenDNS, and SentinelOne. We’re also working on improvements around correlation and host detection. And, because it’s now OSS, you are welcome to suggest and submit your own improvements!

References: -Rob Fry, Brooks Evans, Jason Chan from Netflix.

Original Post: http://www.hackinsight.org/news,331.html and http://techblog.netflix.com/2015/05/introducing-fido-automated-security.html

How to Become an Ethical Hacker (Infographic)

Cyber-security is one of the major concerns of online users these days and hackers are an inevitable part of this discussion. Every part of our cyber world is influenced by hackers and they exploit the vulnerabilities of systems to gain unauthorized access. While numerous people are confused between the terms hackers and cyber-criminals, many of you are willing to know more about hackers and how to become one.

Have you ever considered hacking as a career and there are few things that should be considered to figure out if hacking is the right job for you.

As I’ve discussed in my earlier article, there is great confusion among people when it comes to things like cyber criminals, hackers, ethical hacking, black hat hacking, white hat hacking and more. Here I’m going to tell you something about ethical hacking with a cool infographic and soon I’ll be writing a detailed article on all different types of hackers.

Who is an ethical hacker?

Ethical hacker performs hacking to help an individual or company and identifies the potential risks. An ethical hacker is a good guy and sometimes synonymously used with the term White Hats. They work to improve the overall internet security and search for weak points that could be exploited by the black hats – the bad guys.

Take a look at these points and you will understand what constitutes ethical hacking! These are “guidelines” that an ethical hacker must follow!

1. Respect an individual’s or company’s privacy.
2. Having a permission (expressed – often written) to break into a network and look for the loopholes.
3. After finding the vulnerabilities, you tell your employer about the unknown flaws.
4. After finishing the work, you must not anything open for later exploitation by you or someone else.
5. Do not take any kind of advantage of the permission and access granted to you.

Now, take a look at this infographic by Schools.com. It’s a very well represented career path. For choosing this career as an ethical hacker, you can start by becoming an Information Security analyst or by becoming a computer programmer.

Learn more about this career path in the infographic given below:

Original Post: http://fossbytes.com/how-to-become-a-ethical-hacker/