Archiv für die Kategorie: News

By Jessica Bair Security Operations Center at RSAC APJ 2019
For the 3rd year, RSAConference 2019 APJ created an educational exhibit, sponsored by RSA, Cisco and M.Tech, to monitor the RSA Conference public Wi-Fi network provided by the Marina Bay Sands (MBS). This exhibit was created in the form of the RSA Conference Security Operations Center (SOC). RSA and Cisco provided technology and staffing to monitor the network for threats, but also to educate attendees on the risks of free Wi-Fi.
What is the difference between a SOC and a NOC?
Network Operations CenterThe NOC is usually responsible for monitoring and maintaining the overall network infrastructure—its primary function is to ensure uninterrupted network service
Security Operations CenterThe SOC is responsible for protecting networks, as well as web sites, applications, databases, servers and data centers and other technologies
RSA and Cisco provided the SOC. The NOC was provided by the MBS.
The mission of the RSAC SOC was to ensure the conference Wi-Fi is not attacked (denial of service, laterally spreading malware, etc.). We did not block malicious DNS traffic, downloads or attachments; as this was a learning and demonstration environment. We make sure that network is protected from attackers. We locate (when we can) and advise users when they are at risk.
What technology is in the RSAC SOC?
MBS provided the RSAC SOC a span of all network traffic from the .RSACONFERENCE network, which was passed through the Cisco Next Generation Firewall / ISP and then split the traffic to NetWitness Packets NetWitness Packets and the Cisco Stealthwatch teams.
RSA used NetWitness Packets to collect and investigate all traffic on the Wi-Fi network, from the firewall; to detect deviations from normal behavior and create a probability-weighted risk score for alerts based on these results. NetWitness inspects every network packet session for threat indicators at time of collection and enriches this data with threat intelligence and business context. At the end of the conference, all of this data was wiped from NetWitness.
For suspicious files that might be malicious, NetWitness Packets checks a community AV lookup, some static analysis and its own network intelligence. Then NetWitness Malware Analysis sends the files to Cisco Threat Grid for dynamic malware analysis.
Threat Grid combines advanced sandboxing with threat intelligence into one unified solution to protect organizations from malware. Threat Grid analyzes the behavior of a file against millions of samples and billions of malware artifacts. The SOC team had a global and historical view of the malware, what it’s doing and how large a threat it posed to the RSAC network.
Threat Grid identifies key behavioral indicators of malware and their associated campaigns. The SOC team was able to save time by quickly prioritizing attacks with the biggest potential impact. We used tools like Glovebox, to safely interact with samples and observe malware behavior directly. In addition, we used Cisco Umbrella to have visibility in all DNS activity. We also used the Threat Intelligence of Cisco Threat Response and Talos Intelligence.
When the Cisco team found a potential threat, they handed it off to the RSA team for further investigation. In summary, the technology stack was:
Firewall – Cisco Next Generation Firewall with IPS
Full Packet Capture and Investigation – RSA NetWitness Packets
Dynamic File Analysis – Cisco Threat Grid
DNS / IP Intelligence – Cisco Umbrella / Cisco Umbrella Investigate
Encrypted Traffic Analytics – Cisco Stealthwatch
Threat Intelligence – Cisco Threat Response / Talos Intelligence
Perimeter Defences: Stopping Threats That Matter
Cisco’s Next-Generation Firewall running Firepower Threat Defence (FTD) software was set up as the perimeter security device. The firewall inspected all wireless guest traffic from event attendees, configured in monitor-only mode. FTD offers breach detection, threat discovery and security automation. Rich contextual information (such as Applications, Operating Systems, Vulnerabilities, Intrusions, and Transferred Files) served the SOC to help uncover threats lurking in the environment.
Discovered Applications

Discovered Files

Intrusion Information

During the conference, several intrusion events were recorded by FTD. Automated event analysis correlated threat events with contextual endpoint data, to identify IPS events that require immediate investigation. Whenever a working exploit targeted a vulnerable host on the guest network, an Impact 1 event was raised. For the SOC, that helped cut through the noise and focus attention to save previous time.
Multiple events were categorized as high priority.

One of the Impact Flag 1 events shown below, signalling about suspicious .bit query going over DNS, and associated with a Network Trojan.

The FTD would drop this communication, if it were in a production environment and configured in the active blocking mode. Reviewing the host profile, we confirmed that the target host had a large number of high-severity vulnerabilities associated with unpatched software versions. It may have been infected by malware attempting to control it remotely.

When you request a .jpg and get ransomware
On the first day of the Conference, the SOC team observed a .JPG file served to a conference attendee who connected to a website. The .JPG file was extracted by NetWitness and found to actually have a file header of MZ, used for executables.

Since it was an executable, it was automatically sent for analysis. The static analysis had a score of 0 and 50 from the RSA Malware Analysis Community lookup, meaning it had never been detected by dozens of AV vendors.
The Dynamic Analysis/Sandbox score from Threat Grid was 100, meaning confirmed malicious based on behavior. The team went into action to assess the threat.

The supposed .JPG file was assigned a Threat Score of 100 for the Behavior of Troldesh Ransomware Detected. Troldesh, also known as Shade, is a Russian-targeted Ransomware variant written in Visual Basic. It will encrypt user files and request a ransom to be delivered after contacting a supplied e-mail address. All encrypted files will have an .xtbl extension appended to them.

We also noted the sample attempted to hide itself as a Windows system file, opened up a Personal VPN – Proxy/Anonymizer and wrote files to a USB drive.

We pivoted to Threat Response to learn more and determine if it had been seen before.

With Threat Response we were able to have a global view of the file, that it was first seen November 2018. In a production environment, this threat intelligence would have blocked the file on all integrated Cisco Security platforms.

The NetWitness team investigated the machine that requested the .jpg and confirmed it downloaded other suspicious files.

One of those was titled Memorandum of Sale, but also was an executable that attempts to steal Firefox passwords.

Phishing attack
We also saw a phishing attack, masquerading as a banking email. NetWitness reconstructed the email and sent the attachments to Threat Grid for analysis.

The Payment Advice attachment was actually the LokiBot malware.

Standing up a malicious domain for 24 hours
On the first day of the conference, we noticed some suspicious DNS traffic in Umbrella to a newly created domain. The requests happened throughout the day.

We moved to Umbrella Investigate to learn more and confirmed the sudden malicious activity of 0 DNS requests to over 120,000 global requests.

The requests spiked to 151,000 over the 24-hour period and then they stopped, globally.

We could see the domain was registered in Russia and the distribution of the requesters.

Looking at the NetWitness logs, we could see all requests from RSAC came from Android devices.
Outbound traffic for hostname rousema[.]com [208.67.220.220] we can see 13 sessions from 10:50 AM – 16:50 PM SGT Tues 16th/Jul.

service type UDP DNS & HTTPS

This is originating from 3 IPs

10.10.1.143 Android 9 Samsung Phone sm-g955f running dalvik/2.1.0, Samsung M1client daylite/3.0.05.9 & x86_64 Linux – 11:06 AM SGT – 15:23 PM – (All traffic from IP from 10:31 AM – 16:59 PM)

10.10.5.9 Android 7.0 Phone trt-l21a running dalvik/2.1.0 & Android 2.2 – 10:50 AM SGT – 17:06 PM – (All traffic from IP from 10:51 AM – 23:19 PM)

10.10.2.31 x86_64 Linux & Android 9 Samsung Phone sm-n950f running dalvik/2.1.0(13:12 AM SGT – 13:12 PM – (All traffic from IP from 10:31 AM – 14:16 PM)

Dalvik is the discontinued process Virtual Machine in Android 4.4 and earlier
It was a textbook example of a temporary domain infrastructure that would be blocked in a production environment.

Overall, we saw over 5m DNS requests during RSAC APJ. A couple of thousand would have been blocked in a production environment.
We were also able to have visibility in the 2,001 apps that had DNS activity during the conference.

Stealthwatch brings additional network visibility
Stealthwatch detected insider threat activities like Command & Control activity and Data Exfiltration just over the baseline period of two days, indicating potential threats on the network.

The solution with its unique ability to look at encrypted traffic without decryption, also detected users with unknown TLS version.

Now we can extend this comprehensive visibility to cloud networks as well with an offering called Stealthwatch Cloud.

You can checkout the RSAC USA 2019 SOC Report in comparison.
Come visit us in the Black Hat USA 2019 NOC, 3-8 August 2019.

Acknowledgements
Thank you to Terence Tang, Michael Auger, Evgeny Mirolyubov, Sabiha Rouksana Hashmat Mohideen Pasha and Chong Chee Chua and Cisco Security, who contributed to this blog. Also, our deepest appreciation to our RSA Security partners, especially Chris Thomas, Percy Tucker, Lee McCotter and Mohammed Behlim.

Source:: Cisco Security Notice

By Kevin Skahill All great teams have a shared language. Whether you’re the reigning World Cup Champions or an IT team on the frontlines of network defense, collaboration is the key to success. And effective collaboration hinges on communication.
For years, Cisco has operated on the cutting-edge of communication standards, working tirelessly to make multi-platform communication seamless and efficient.
This June, Cisco achieved a historic milestone when the Internet Engineering Task Force (IETF) declared our XMPP-Grid architecture an official Internet standard for security information exchange.

Cisco’s Extensible Messaging and Presence Protocol (XMPP) – the underpinnings of Cisco Platform Exchange Grid (pxGrid for short) 1.0 – ushered in a new era of seamless collaboration, allowing information to be shared between security platforms from multiple vendors. Prior to this innovation, IT teams faced a discouraging reality: Despite having a wealth of security information from dozens of multivendor platforms at their fingertips, it was nearly impossible for IT teams to configure these technologies to share identity and context information in real-time.
pxGrid enables IT teams to harness the full potential of their security technologies. An open, scalable, and highly-secure form of security information exchange, Cisco’s pxGrid technology facilitates integrations between its 60 Technical Alliance Partners today. These integrations eliminate the complexity of single-purpose APIs by allowing all integrated platforms to publish and subscribe to relevant security information. With this additional security context, actionable intelligence is available to perform automated incident response, for mitigating risks and containing threats more effectively. In short, pxGrid enhances the power of your security apparatus through effective communication.
And this is only the start: As Cisco’s nearly 40,000 Identity Services Engine customers migrate to pxGrid 2.0’s WebSocket based architecture, Cisco continues to lead the way in a growing ecosystem of open security information exchange.
Cisco’s implementation of the standard, pxGrid, is available on Cisco Identity Services Engine (ISE). If you are one of our Cisco ISE customers already collaborating effectively via Cisco pxGrid, thank you for supporting our community! And if you have technology partners who have not yet integrated their platforms with Cisco pxGrid, please request that they adopt this new standard.

If you are a Cisco ISE customer but have yet to benefit from security ecosystem integrations to address use cases such as intent based network segmentation and rapid threat containment, please learn about how Cisco pxGrid can be licensed and deployed.
Megan Rapinoe and Alex Morgan would probably be the first to say that the success of the US Women’s National Team depends on superior communication. As an IETF-approved internet standard, pxGrid helps elevate your information security practices. Through this open communication standard, your security technologies work together to form a solid defense, so your company is free to concentrate on business and score big where it matters.

Source:: Cisco Security Notice

By Ben Nahorney You’ve probably heard the stories by now: one of the fundamental technologies that keeps the internet working has recently become a regular target for attackers.
Earlier this month, the UK’s National Cyber Security Centre released an advisory warning of DNS hijacking attacks across multiple regions and sectors. (This was their second such advisory in six months.) Last month, in their 2019 Global DNS Threat Report, IDC highlighted an increased number of DNS attacks and the subsequent costs. And earlier this year, ICANN warned of “ongoing and significant risk to key parts” of the internet’s DNS infrastructure, calling for the adoption of more robust security implementations.
Cisco Talos, Cisco’s threat intelligence group, had been watching DNS closely during this time. Talos spotted multiple attacks relying on DNS hijacking and manipulation as their main infection vector, releasing research that prompted many of these warnings.
Attacks against DNS is of significant concern. But what exactly is DNS? How is it being attacked? And what can be done to protect against these attacks?
DNS basics
Let’s start with a brief explanation of the technology. The Domain Name System (DNS) is the core technology that directs users to different web sites and other locations on the internet. Think of it like asking a librarian for help locating a book. Only instead of asking about a book, you ask for a particular web site. DNS checks its records, and then tells your computer where the web site is located.
DNS also works as a translator of sorts. It takes the human-readable domains (e.g. www.example.com) and matches it to the site’s IP address, the number that computers use to identify the location of the domain. In short, the user asks, “What is the IP address of this domain?” and DNS tells you.
Figure 1- How DNS works
The standard process for looking up domains is a little more complicated than described, involving more than one DNS server. The first server contacted, the DNS Resolver, is much like the librarian. The process from there often goes as follows:
The resolver will ask the DNS Root Server where the web site resides in much the same way the librarian will consult the card catalog for the location in the library.
The root server will send the resolver to the Top Level Domain server (TLD)—the DNS servers broken down by .com, .net, .org, etc. Think of this as a digital Dewey Decimal System.
The TLD server will know where the DNS Name Server is—the official DNS server of the domain you are trying to reach—and will tell the resolver the IP address. The name server is the card for the book.
The resolver tells your computer the IP address of the domain, and your computer goes to the site. This is the location of the book printed on the card.
Figure 2- How DNS works (detailed)
Where it all goes wrong
The thing about DNS attacks is that they don’t go directly after their intended target. Rather, they attack the librarian.
This attack is commonly referred to as “DNS hijacking” or “DNS redirection.” You are asking for the location of a particular book, but the information the librarian has is compromised. Instead of sending you to the correct location where your book resides, the librarian instead sends you to a dark, spiderweb-infested corner of the library. Even the book you pull off the shelf may look like what you wanted, but actually be something entirely different—the supposed children’s book turns out to be the Anarchist Cookbook instead.
The attack comes down to altering the route to a legitimate website to lead to a malicious one, ultimately compromising the target. You ask for the IP address of a particular domain you want to visit, but the DNS records have been changed so that you are sent to a malicious IP address instead.
Figure 3 – DNS redirection
There are a number of points at which a malicious actor can compromise DNS records. To name a few:
The DNS administrator may be phished, giving up his or her credentials, and the attackers log into the DNS interface and change the site’s IP address.
The DNS hosting interface—where records are managed and updated—may be compromised, allowing the attacker to change records for the domain.
Any of the DNS servers or infrastructure along the DNS request chain could be compromised, leading to a redirection.

A decade of redirection attacks
While various flaws and weaknesses in the DNS system had been known for a while, the first notable DNS attacks began in 2009. At the time, attackers managed to briefly change the DNS records for twitter.com to point to a hacktivist website for the Iranian Cyber Army.
Over the course of the next few years, a number of DNS-related attacks occurred:
In 2011 a Turkish hacker managed to redirect roughly 186 domains to point to a “you’ve been hacked”-type page.
The Syrian Electronic Army managed to redirect The New York Times, Twitter, and The Huffington Post to a hacktivist web site, and then attempted the same against Facebook, in attacks carried out in 2013 and 2014. (The Facebook attack was stopped in part thanks to multi-factor authentication.)
In 2015, regional Google sites for Vietnam and Malaysia were hijacked via DNS redirection.
The cryptocurrency company, Blockchain, had its DNS records hijacked in 2016. (Fortunately, the record change was quickly spotted by OpenDNS and restored.)
There have been many more such attacks during this 10-year timespan, some successfully, some not. However, Talos researchers discovered DNS attacks had reached a whole new level in late 2018.
DNSpionage
It all started with a LinkedIn message. The DNS administrator, thinking it was from a recruiter who was impressed with their work, clicked on a link that lead to a document that they thought they could fill out to apply for an open position.
Figure 4 – Malicious document used in DNSpionage
However, the document was actually infected with malicious macros. The administrator’s machine was compromised as a result, allowing the attackers to steal DNS login information.
Having gained the ability to control the domain, the attackers subsequently redirected a webmail server to a malicious IP address, and registered valid certificates to “legitimize” the redirected domain. Any visitor to this site would be wholly unaware that anything was out of the ordinary.
Figure 5 – DNSpionage attack process
In the process of investigating the tactics, techniques, and procedures of the DNSpionage attackers, Talos Intelligence discovered another separate, and arguably more concerning, attack against TLD DNS servers.
Sea Turtle

While having a similar end-goal as DNSpionage—stealing information—the attackers behind Sea Turtle went after the network infrastructure where the TLD servers were hosted, exploiting known vulnerabilities in these servers to gain access. Once the TLD servers where compromised, they modified the IP addresses of the name servers for particular domains.
This approach gave the attackers more control over the redirection. Setting up a malicious name server, the attacker can choose when requests for a particular domain is sent to the legitimate site or a malicious site.
Figure 6 – Sea Turtle attack process
Similar to DNSpionage, Sea Turtle changed records of webmail servers, where they can intercept and steal the information that they were after, and then send the target on to the legitimate system when done.
Other related attack techniques
In this blog we’ve focused on various DNS redirection attacks and techniques. There is far, far more to the attacks than is covered here. Talos has published multiple blogs on the attack that include details on payloads and the malicious techniques used by the attackers. Links to these blogs are included in the “Additional Reading” section below.
There are a few other ways that attackers have used DNS to perform malicious activities. Some threats, such as DNSpionage and DNSMessenger, communicate with command and control (C2) systems using DNS. DNSMessenger, along with other threats, has also been seen tunneling through DNS in order to exfiltrate stolen data.
Another recent area of concern is threats using the DNS over HTTPS (DoH) protocol. The purpose of this protocol is to increase the security of DNS queries, preventing eavesdropping and MitM attacks. However, earlier this month, a malware family named Godlua was found using the protocol for malicious communications. Given DoH’s ability to mask traffic, it’s possible more threats will follow suit.
How to protect against DNS attacks
Unfortunately, as a end-target of a DNS attack, there isn’t too much you can do. From a user’s standpoint, the DNS communication to get to a web site appears legitimate, especially when the attacker creates valid certificates for the malicious sites after compromising the DNS records.
The responsibility to defend in this case falls to those who administer and host DNS services. Fortunately, there are steps that can be taken at this level.
Monitor your DNS records. Tools like Umbrella Investigate allow you to quickly look up changes to DNS records.
Require multi-factor authentication (MFA) for DNS record changes. MFA solutions, such as those offered by Cisco Duo, can prevent arbitrary changes to your records without authentication.
Use tools such as BGPmon to monitor for DNS hijacking attempts, changes to TLD records, or traffic redirection and interception.
Keep your systems patched. In the case of Sea Turtle, attackers got in by exploiting vulnerabilities, some of which were 10 years old.
Implement DNSSEC in your environment. DNSSEC adds digital signatures to DNS communications, allowing for origin authentication and ensuring the request hasn’t been modified.
Finally, if you host a web site or domain, be sure to confirm that your DNS provider’s security posture includes the above.

Additional reading
DNSpionage Campaign Targets Middle East
DNSpionage brings out the Karkoff
DNS Hijacking Abuses Trust In Core Internet Service
Sea Turtle keeps on swimming, finds new victims, DNS hijacking techniques
Covert Channels and Poor Decisions: The Tale of DNSMessenger
Spoofed SEC Emails Distribute Evolved DNSMessenger
Detecting DNS Data Exfiltration

Like this post? Subscribe to the Threat of the Month blog series and get alerted when the next blog post is released.

Source:: Cisco Security Notice

By Jessica Bair RSA and Cisco released the first ever Findings Report from the RSA Conference 2019 Security Operations Center (SOC).
The RSA® Conference SOC analyzes the Moscone Center wireless traffic, which is an open network during the week of the Conference. The SOC began collecting traffic on Monday, March 4, 2019 and through 4:00PM Thursday, March 7, 2019. There were 70,440,988 sessions throughout this period.
The role of the SOC at RSA Conference is an educational exhibit sponsored by RSA and Cisco. It is not a true SOC like you would create to protect an organization. The RSAC SOC doesn’t have an infrastructure at the Moscone Center and only has a SPAN of the network traffic from the Moscone Center wireless network. There are not any logs, firewalls or endpoint protection infrastructure; just a copy in real time of the traffic traversing the wireless network.
The goal of the RSAC SOC is to use technology to educate conference attendees about what happens on a typical wireless network. The education comes in the form of daily SOC tours, an RSA Conference session and after the event, a RSA Conference virtual webcast reviewed the findings and a Cisco Security webinar on the technology in the SOC.
This year did have encouraging metrics in that our encrypted traffic increased over last year. Keep it up! Use a VPN!
The findings report addresses several security topics, including:
Plain text passwords
Unencrypted network traffic
Malware
DNS security
Cryptomining…and more
We will be back in 2020 and we’ll report once again how we’re doing as a community.

Download the RSA Conference 2019: Lessons from Monitoring the Wireless Network report here.
Acknowledgements: Special thanks to Neal R. Wyler and Percy Tucker of RSA Security; and to the team members of the RSA and Cisco SOC staff.
As always, we welcome your comments below. Did anything in the report surprise you? Are you in the process of setting up a SOC?

Source:: Cisco Security Notice