Security News from Some Sites I Watch

Threatpost The First Stop For Security News

The Hacker News The Hacker News (THN) is a leading, trusted, widely-acknowledged dedicated cybersecurity news platform, attracting over 8 million monthly readers including IT professionals, researchers, hackers, technologists, and enthusiasts.

  • Hacker Breaks Into French Government’s New Secure Messaging App
    by (Swati Khandelwal) on April 19, 2019 at 3:35 pm

    A white-hat hacker found a way to get into the French government’s newly launched, secure encrypted messaging app that otherwise can only be accessed by officials and politicians with email accounts associated with the government identities. Dubbed “Tchap,” the end-to-end encrypted, open source messaging app has been created by the French government with an aim to keep their officials, […]

  • Facebook Stored Millions of Instagram Users’ Passwords in Plaintext
    by (Swati Khandelwal) on April 18, 2019 at 7:29 pm

    Facebook late last month revealed that the social media company mistakenly stored passwords for “hundreds of millions” of Facebook users in plaintext, including “tens of thousands” passwords of its Instagram users as well. Now it appears that the incident is far worse than first reported. <!– adsense –> Facebook today quietly updated its March press release, adding that the actual number of […]

  • Facebook Collected Contacts from 1.5 Million Email Accounts Without Users’ Permission
    by (Swati Khandelwal) on April 18, 2019 at 11:00 am

    Not a week goes without a new Facebook blunder. Remember the most recent revelation of Facebook being caught asking users new to the social network platform for their email account passwords to verify their identity? At the time, it was suspected that Facebook might be using access to users’ email accounts to unauthorizedly and secretly gather a copy of their saved contacts. Now it turns […]

  • Drupal Releases Core CMS Updates to Patch Several Vulnerabilities
    by (Swati Khandelwal) on April 17, 2019 at 9:51 pm

    Drupal, the popular open-source content management system, has released security updates to address multiple “moderately critical” vulnerabilities in Drupal Core that could allow remote attackers to compromise the security of hundreds of thousands of websites. According to the advisories published today by the Drupal developers, all security vulnerabilities Drupal patched this month reside in […]

  • Researcher Hijacks a Microsoft Service Using Loophole in Azure Cloud Platform
    by (Mohit Kumar) on April 17, 2019 at 8:16 pm

    A cybersecurity professional today demonstrated a long-known unpatched weakness in Microsoft’s Azure cloud service by exploiting it to take control over Windows Live Tiles, one of the key features Microsoft built into Windows 8 operating system. Introduced in Windows 8, the Live tiles feature was designed to display content and notifications on the Start screen, allowing users to continuously […]

Krebs on Security In-depth security news and investigation

  • Marcus “MalwareTech” Hutchins Pleads Guilty to Writing, Selling Banking Malware
    by BrianKrebs on April 19, 2019 at 9:58 pm

    Marcus Hutchins, a 24-year-old blogger and malware researcher arrested in 2017 for allegedly authoring and selling malware designed to steal online banking credentials, has pleaded guilty to criminal charges of conspiracy and to making, selling or advertising illegal wiretapping devices. […]

  • Wipro Intruders Targeted Other Major IT Firms
    by BrianKrebs on April 18, 2019 at 5:42 pm

    The criminals responsible for launching phishing campaigns that netted dozens of employees and more than 100 computer systems last month at Wipro, India’s third-largest IT outsourcing firm, also appear to have targeted a number of other competing providers, including Infosys and Cognizant — two other large technology consulting companies, new evidence suggests. […]

  • How Not to Acknowledge a Data Breach
    by BrianKrebs on April 17, 2019 at 5:56 pm

    I’m not a huge fan of stories about stories, or those that explore the ins and outs of reporting a breach. But occasionally it seems necessary to publish such accounts when companies respond to a breach report in such a way that it’s crystal clear that they wouldn’t know what to do with a breach if it bit them in the nose, let alone festered unmolested in some dark corner of their operations. […]

  • Experts: Breach at IT Outsourcing Giant Wipro
    by BrianKrebs on April 15, 2019 at 9:19 pm

    Indian information technology (IT) outsourcing and consulting giant Wipro [NYSE:WIT] is investigating reports from multiple security experts that Wipro’s systems have been hacked and are being used to launch attacks against the company’s customers, multiple sources tell KrebsOnSecurity. The company has refused to respond to questions about the alleged incident. […]

  • ‘Land Lordz’ Service Powers Airbnb Scams
    by BrianKrebs on April 14, 2019 at 6:40 pm

    Scammers who make a living swindling customers have a powerful new tool at their disposal: A software-as-a-service offering called “Land Lordz,” which helps automate the creation and management of fake Airbnb Web sites and the sending of messages to advertise the fraudulent listings. […]

BleepingComputer BleepingComputer – All Stories

TaoSecurity Richard Bejtlich’s blog on digital security, strategic thought, and military history.

  • Troubleshooting NSM Virtualization Problems with Linux and VirtualBox
    by (Richard Bejtlich) on April 8, 2019 at 8:56 pm

    I spent a chunk of the day troubleshooting a network security monitoring (NSM) problem. I thought I would share the problem and my investigation in the hopes that it might help others. The specifics are probably less important than the general approach.It began with ja3. You may know ja3 as a set of Zeek scripts developed by the Salesforce engineering team to profile client and server TLS parameters.I was reviewing Zeek logs captured by my Corelight appliance and by one of my lab sensors running Security Onion. I had coverage of the same endpoint in both sensors.I noticed that the SO Zeek logs did not have ja3 hashes in the ssl.log entries. Both sensors did have ja3s hashes. My first thought was that SO was misconfigured somehow to not record ja3 hashes. I quickly dismissed that, because it made no sense. Besides, verifying that intution required me to start troubleshooting near the top of the software stack.I decided to start at the bottom, or close to the bottom. I had a sinking suspicion that, for some reason, Zeek was only seeing traffic sent from remote systems, and not traffic originating from my network. That would account for the creation of ja3s hashes, for traffic sent by remote systems, but not ja3 hashes, as Zeek was not seeing traffic sent by local clients.I was running SO in VirtualBox 6.0.4 on Ubuntu 18.04. I started sniffing TCP network traffic on the SO monitoring interface using Tcpdump. As I feared, it didn’t look right. I ran a new capture with filters for ICMP and a remote IP address. On another system I tried pinging the remote IP address. Sure enough, I only saw ICMP echo replies, and no ICMP echoes. Oddly, I also saw doubles and triples of some of the ICMP echo replies. That worried me, because unpredictable behavior like that could indicate some sort of software problem.My next step was to “get under” the VM guest and determine if the VM host could see traffic properly. I ran Tcpdump on the Ubuntu 18.04 host on the monitoring interface and repeated my ICMP tests. It saw everything properly. That meant I did not need to bother checking the switch span port that was feeding traffic to the VirtualBox system.It seemed I had a problem somewhere between the VM host and guest. On the same VM host I was also running an instance of RockNSM. I ran my ICMP tests on the RockNSM VM and, sadly, I got the same one-sided traffic as seen on SO.Now I was worried. If the problem had only been present in SO, then I could fix SO. If the problem is present in both SO and RockNSM, then the problem had to be with VirtualBox — and I might not be able to fix it.I reviewed my configurations in VirtualBox, ensuring that the “Promiscuous Mode” under the Advanced options was set to “Allow All”. At this point I worried that there was a bug in VirtualBox. I did some Google searches and reviewed some forum posts, but I did not see anyone reporting issues with sniffing traffic inside VMs. Still, my use case might have been weird enough to not have been reported.I decided to try a different approach. I wondered if running VirtualBox with elevated privileges might make a difference. I did not want to take ownership of my user VMs, so I decided to install a new VM and run it with elevated privileges.Let me stop here to note that I am breaking one of the rules of troubleshooting. I’m introducing two new variables, when I should have introduced only one. I should have built a new VM but run it with the same user privileges with which I was running the existing VMs.I decided to install a minimal edition of Ubuntu 9, with VirtualBox running via sudo. When I started the VM and sniffed traffic on the monitoring port, lo and behold, my ICMP tests revealed both sides of the traffic as I had hoped. Unfortunately, from this I erroneously concluded that running VirtualBox with elevated privileges was the answer to my problems.I took ownership of the SO VM in my elevated VirtualBox session, started it, and performed my ICMP tests. Womp womp. Still broken.I realized I needed to separate the two variables that I had entangled, so I stopped VirtualBox, and changed ownership of the Debian 9 VM to my user account. I then ran VirtualBox with user privileges, started the Debian 9 VM, and ran my ICMP tests. Success again! Apparently elevated privileges had nothing to do with my problem.By now I was glad I had not posted anything to any user forums describing my problem and asking for help. There was something about the monitoring interface configurations in both SO and RockNSM that resulted in the inability to see both sides of traffic (and avoid weird doubles and triples).I started my SO VM again and looked at the script that configured the interfaces. I commented out all the entries below the management interface as shown below.$ cat /etc/network/interfaces# This configuration was created by the Security Onion setup script.## The original network interface configuration file was backed up to:# /etc/network/interfaces.bak.## This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5).# loopback network interfaceauto loiface lo inet loopback# Management network interfaceauto enp0s3iface enp0s3 inet static  address  gateway  netmask  dns-nameservers  dns-domain localdomain#auto enp0s8#iface enp0s8 inet manual#  up ip link set $IFACE promisc on arp off up#  down ip link set $IFACE promisc off down#  post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done#  post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6#auto enp0s9#iface enp0s9 inet manual#  up ip link set $IFACE promisc on arp off up#  down ip link set $IFACE promisc off down#  post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done#  post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6I rebooted the system and brought the enp0s8 interface up manually using this command:$ sudo ip link set enp0s8 promisc on arp off upFingers crossed, I ran my ICMP sniffing tests, and voila, I saw what I needed — traffic in both directions, without doubles or triples no less.So, there appears to be some sort of problem with the way SO and RockNSM set parameters for their monitoring interfaces, at least as far as they interact with VirtualBox 6.0.4 on Ubuntu 18.04. You can see in the network script that SO disables a bunch of NIC options. I imagine one or more of them is the culprit, but I didn’t have time to work through them individually.I tried taking a look at the network script in RockNSM, but it runs CentOS, and I’ll be darned if I can’t figure out where to look. I’m sure it’s there somewhere, but I didn’t have the time to figure out where.The moral of the story is that I should have immediately checked after installation that both SO and RockNSM were seeing both sides of the traffic I expected them to see. I had taken that for granted for many previous deployments, but something broke recently and I don’t know exactly what. My workaround will hopefully hold for now, but I need to take a closer look at the NIC options because I may have introduced another fault.A second moral is to be careful of changing two or more variables when troubleshooting. When you do that you might fix a problem, but not know what change fixed the issue.Copyright 2003-2018 Richard Bejtlich and TaoSecurity ( and […]

  • Thoughts on OSSEC Con 2019
    by (Richard Bejtlich) on March 28, 2019 at 8:40 pm

    Last week I attended my first OSSEC conference. I first blogged about OSSEC in 2007, and wrote other posts about it in the following years.OSSEC is a host-based intrusion detection and log analysis system with correlation and active response features. It is cross-platform, such that I can run it on my Windows and Linux systems. The moving force behind the conference was a company local to me called Atomicorp.In brief, I really enjoyed this one-day event. (I had planned to attend the workshop on the second day but my schedule did not cooperate.) The talks were almost uniformly excellent and informative. I even had a chance to talk jiu-jitsu with OSSEC creator Daniel Cid, who despite hurting his leg managed to travel across the country to deliver the keynote.I’d like to share a few highlights from my notes.First, I had been worried that OSSEC was in some ways dead. I saw that the Security Onion project had replaced OSSEC with a fork called Wazuh, which I learned is apparently pronounced “wazoo.” To my delight, I learned OSSEC is decidedly not dead, and that Wazuh has been suffering stability problems. OSSEC has a lot of interesting development ahead of it, which you can track on their Github repo.For example, the development roadmap includes eliminating Logstash from the pipeline used by many OSSEC users. OSSEC would feed directly into Elasticsearch. One speaker noted that Logstash has a 1.7 GB memory footprint, which astounded me.On a related note, the OSSEC team is planning to create a new Web console, with a design goal to have it run in an “AWS t2.micro” instance. The team noted that instance offers 2 GB memory, which doesn’t match what AWS says. Perhaps they meant t2.micro and 1 GB memory, or t2.small with 2 GB memory. I think they mean t2.micro with 1 GB RAM, as that is the free tier. Either way, I’m excited to see this later in 2019.Second, I thought the presentation by security personnel from USA Today offered an interesting insight. One design goal they had for monitoring their Google Cloud Platform (GCP) was to not install OSSEC on every container or on Kubernetes worker nodes. Several times during the conference, speakers noted that the transient nature of cloud infrastructure is directly antithetical to standard OSSEC usage, whereby OSSEC is installed on servers with long uptime and years of service. Instead, USA Today used OSSEC to monitor HTTP logs from the GCP load balancer, logs from Google Kubernetes Engine, and monitored processes by watching output from successive kubectl invocations.Third, a speaker from Red Hat brought my attention to an aspect of containers that I had not considered. Docker and containers had made software testing and deployment a lot easier for everyone. However, those who provide containers have effectively become Linux distribution maintainers. In other words, who is responsible when a security or configuration vulnerability in a Linux component is discovered? Will the container maintainers be responsive?Another speaker emphasized the difference between “security of the cloud,” offered by cloud providers, and “security in the cloud,” which is supposed to be the customer’s responsibility. This makes sense from a technical point of view, but I expect that in the long term this differentiation will no longer be tenable from a business or legal point of view.Customers are not going to have the skills or interest to secure their software in the cloud, as they outsource ever more technical talent to the cloud providers and their infrastructure. I expect cloud providers to continue to develop, acquire, and offer more security services, and accelerate their competition on a “complete security environment.”I look forward to more OSSEC development and future conferences.Copyright 2003-2018 Richard Bejtlich and TaoSecurity ( and […]

  • Importing Pcap into Security Onion
    by (Richard Bejtlich) on March 28, 2019 at 8:03 pm

    Within the last week, Doug Burks of Security Onion (SO) added a new script that revolutionizes the use case for his amazing open source network security monitoring platform.I have always used SO in a live production mode, meaning I deploy a SO sensor sniffing a live network interface. As the multitude of SO components observe network traffic, they generate, store, and display various forms of NSM data for use by analysts.The problem with this model is that it could not be used for processing stored network traffic. If one simply replayed the traffic from a .pcap file, the new traffic would be assigned contemporary timestamps by the various tools observing the traffic.While all of the NSM tools in SO have the independent capability to read stored .pcap files, there was no unified way to integrate their output into the SO platform.Therefore, for years, there has not been a way to import .pcap files into SO — until last week!Here is how I tested the new so-import-pcap script. First, I made sure I was running Security Onion Elastic Stack Release Candidate 2 ( ISO) or later. Next I downloaded the script using wget from continued as follows:richard@so1:~$ sudo cp so-import-pcap /usr/sbin/richard@so1:~$ sudo chmod 755 /usr/sbin/so-import-pcapI tried running the script against two of the sample files packaged with SO, but ran into issues with both.richard@so1:~$ sudo so-import-pcap /opt/samples/10k.pcapso-import-pcapPlease wait while……creating temp pcap for processing.mergecap: Error reading /opt/samples/10k.pcap: The file appears to be damaged or corrupt(pcap: File has 263718464-byte packet, bigger than maximum of 262144)Error while merging!I checked the file with capinfos.richard@so1:~$ capinfos /opt/samples/10k.pcapcapinfos: An error occurred after reading 17046 packets from “/opt/samples/10k.pcap”: The file appears to be damaged or corrupt.(pcap: File has 263718464-byte packet, bigger than maximum of 262144)Capinfos confirmed the problem. Let’s try another!richard@so1:~$ sudo so-import-pcap /opt/samples/zeus-sample-1.pcapso-import-pcapPlease wait while……creating temp pcap for processing.mergecap: Error reading /opt/samples/zeus-sample-1.pcap: The file appears to be damaged or corrupt(pcap: File has 1984391168-byte packet, bigger than maximum of 262144)Error while merging!Another bad file. Trying a third!richard@so1:~$ sudo so-import-pcap /opt/samples/evidence03.pcapso-import-pcapPlease wait while……creating temp pcap for processing….setting sguild debug to 2 and restarting sguild….configuring syslog-ng to pick up sguild logs….disabling syslog output in barnyard….configuring logstash to parse sguild logs (this may take a few minutes, but should only need to be done once)…done….stopping curator….disabling curator….stopping ossec_agent….disabling ossec_agent….stopping Bro sniffing process….disabling Bro sniffing process….stopping IDS sniffing process….disabling IDS sniffing process….stopping netsniff-ng….disabling netsniff-ng….adjusting CapMe to allow pcaps up to 50 years old….analyzing traffic with Snort….analyzing traffic with Bro….writing /nsm/sensor_data/so1-eth1/dailylogs/2009-12-28/snort.log.1261958400Import complete!You can use this hyperlink to view data in the time range of your import:https://localhost/app/kibana#/dashboard/94b52620-342a-11e7-9d52-4f090484f59e?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:’2009-12-28T00:00:00.000Z’,mode:absolute,to:’2009-12-29T00:00:00.000Z’))or you can manually set your Time Range to be:From: 2009-12-28    To: 2009-12-29Incidentally here is the capinfos output for this trace.richard@so1:~$ capinfos /opt/samples/evidence03.pcapFile name:           /opt/samples/evidence03.pcapFile type:           Wireshark/tcpdump/… – pcapFile encapsulation:  EthernetPacket size limit:   file hdr: 65535 bytesNumber of packets:   1778File size:           1537 kBData size:           1508 kBCapture duration:    171 secondsStart time:          Mon Dec 28 04:08:01 2009End time:            Mon Dec 28 04:10:52 2009Data byte rate:      8814 bytes/sData bit rate:       70 kbpsAverage packet size: 848.57 bytesAverage packet rate: 10 packets/secSHA1:                34e5369c8151cf11a48732fed82f690c79d2b253RIPEMD160:           afb2a911b4b3e38bc2967a9129f0a11639ebe97fMD5:                 f8a01fbe84ef960d7cbd793e0c52a6c9Strict time order:   TrueThat worked! Now to see what I can find in the SO interface.I accessed the Kibana application and changed the timeframe to include those in the trace.Here’s another screenshot. Again I had to adjust for the proper time range.Very cool! However, I did not find any IDS alerts. This made me wonder if there was a problem with alert processing. I decided to run the script on a new .pcap:richard@so1:~$ sudo so-import-pcap /opt/samples/emerging-all.pcapso-import-pcapPlease wait while……creating temp pcap for processing….analyzing traffic with Snort….analyzing traffic with Bro….writing /nsm/sensor_data/so1-eth1/dailylogs/2010-01-27/snort.log.1264550400Import complete!You can use this hyperlink to view data in the time range of your import:https://localhost/app/kibana#/dashboard/94b52620-342a-11e7-9d52-4f090484f59e?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:’2010-01-27T00:00:00.000Z’,mode:absolute,to:’2010-01-28T00:00:00.000Z’))or you can manually set your Time Range to be:From: 2010-01-27    To: 2010-01-28When I searched the interface for NIDS alerts (after adjusting the time range), I found results:The alerts show up in Sguil, too!This is a wonderful development for the Security Onion community. Being able to import .pcap files and analyze them with the standard SO tools and processes, while preserving timestamps, makes SO a viable network forensics platform.This thread in the mailing list is covering the new script.I suggest running on an evaluation system, probably in a virtual machine. I did all my testing on Virtual Box. Check it out! Copyright 2003-2018 Richard Bejtlich and TaoSecurity ( and […]

  • Twenty Years of Network Security Monitoring: From the AFCERT to Corelight
    by (Richard Bejtlich) on March 14, 2019 at 8:29 pm

    I am really fired up to join Corelight. I’ve had to keep my involvement with the team a secret since officially starting on July 20th. Why was I so excited about this company? Let me step backwards to help explain my present situation, and forecast the future.Twenty years ago this month I joined the Air Force Computer Emergency Response Team (AFCERT) at then-Kelly Air Force Base, located in hot but lovely San Antonio, Texas. I was a brand new captain who thought he knew about computers and hacking based on experiences from my teenage years and more recent information operations and traditional intelligence work within the Air Intelligence Agency. I was desperate to join any part of the then-five-year-old Information Warfare Center (AFIWC) because I sensed it was the most exciting unit on “Security Hill.”I had misjudged my presumed level of “hacking” knowledge, but I was not mistaken about the exciting life of an AFCERT intrusion detector! I quickly learned the tenets of network security monitoring, enabled by the custom software watching and logging network traffic at every Air Force base. I soon heard there were three organizations that intruders knew to be wary of in the late 1990s: the Fort, i.e. the National Security Agency; the Air Force, thanks to our Automated Security Incident Measurement (ASIM) operation; and the University of California, Berkeley, because of a professor named Vern Paxson and his Bro network security monitoring software.When I wrote my first book in 2003-2004, The Tao of Network Security Monitoring, I enlisted the help of Christopher Jay Manders to write about Bro 0.8. Bro had the reputation of being very powerful but difficult to stand up. In 2007 I decided to try installing Bro myself, thanks to the introduction of the “brolite” scripts shipped with Bro 1.2.1. That made Bro easier to use, but I didn’t do much analysis with it until I attended the 2009 Bro hands-on workshop. There I met Vern, Robin Sommer, Seth Hall, Christian Kreibich, and other Bro users and developers. I was lost most of the class, saved only by my knowledge of standard Unix command line tools like sed, awk, and grep! I was able to integrate Bro traffic analysis and logs into my TCP/IP Weapons School 2.0 class, and subsequent versions, which I taught mainly to Black Hat students. By the time I wrote my last book, The Practice of Network Security Monitoring, in 2013, I was heavily relying on Bro logs to demonstrate many sorts of network activity, thanks to the high-fidelity nature of Bro data.In July of this year, Seth Hall emailed to ask if I might be interested in keynoting the upcoming Bro users conference in Washington, D.C., on October 10-12. I was in a bad mood due to being unhappy with the job I had at that time, and I told him I was useless as a keynote speaker. I followed up with another message shortly after, explained my depressed mindset, and asked how he liked working at Corelight. That led to interviews with the Corelight team and a job offer. The opportunity to work with people who really understood the need for network security monitoring, and were writing the world’s most powerful software to generate NSM data, was so appealing! Now that I’m on the team, I can share how I view Corelight’s contribution to the security challenges we face.For me, Corelight solves the problems I encountered all those years ago when I first looked at Bro. The Corelight embodiment of Bro is ready to go when you deploy it. It’s developed and maintained by the people who write the code. Furthermore, Bro is front and center, not buried behind someone else’s logo. Why buy this amazing capability from another company when you can work with those who actually conceptualize, develop, and publish the code?It’s also not just Bro, but it’s Bro at ridiculous speeds, ingesting and making sense of complex network traffic. We regularly encounter open source Bro users who spend weeks or months struggling to get their open source deployments to run at the speeds they need, typically in the tens or hundreds of Gbps. Corelight’s offering is optimized at the hardware level to deliver the highest performance, and our team works with customers who want to push Bro to the even greater levels. Finally, working at Corelight gives me the chance to take NSM in many exciting new directions. For years we NSM practitioners have worried about challenges to network-centric approaches, such as encryption, cloud environments, and alert fatigue. At Corelight we are working on answers for all of these, beyond the usual approaches — SSL termination, cloud gateways, and SIEM/SOAR solutions. We will have more to say about this in the future, I’m happy to say!What challenges do you hope Corelight can solve? Leave a comment or let me know via Twitter to @corelight_inc or @taosecurity.Copyright 2003-2018 Richard Bejtlich and TaoSecurity ( and […]

  • Thoughts on Cloud Security
    by (Richard Bejtlich) on March 14, 2019 at 1:16 pm

    Recently I’ve been reading about cloud security and security with respect to DevOps. I’ll say more about the excellent book I’m reading, but I had a moment of déjà vu during one section.The book described how cloud security is a big change from enterprise security because it relies less on IP-address-centric controls and more on users and groups. The book talked about creating security groups, and adding users to those groups in order to control their access and capabilities.As I read that passage, it reminded me of a time long ago, in the late 1990s, when I was studying for the MCSE, then called the Microsoft Certified Systems Engineer. I read the book at left, Windows NT Security Handbook, published in 1996 by Tom Sheldon. It described the exact same security process of creating security groups and adding users. This was core to the new NT 4 role based access control (RBAC) implementation.Now, fast forward a few years, or all the way to today, and consider the security challenges facing the majority of legacy enterprises: securing Windows assets and the data they store and access. How could this wonderful security model, based on decades of experience (from the 1960s and 1970s no less), have failed to work in operational environments?There are many reasons one could cite, but I think the following are at least worthy of mention.The systems enforcing the security model are exposed to intruders.Furthermore:Intruders are generally able to gain code execution on systems participating in the security model.Finally:Intruders have access to the network traffic which partially contains elements of the security model.From these weaknesses, a large portion of the security countermeasures of the last two decades have been derived as compensating controls and visibility requirements.The question then becomes:Does this change with the cloud?In brief, I believe the answer is largely “yes,” thankfully. Generally, the systems upon which the security model is being enforced are not able to access the enforcement mechanism, thanks to the wonders of virtualization.Should an intruder find a way to escape from their restricted cloud platform and gain hypervisor or management network access, then they find themselves in a situation similar to the average Windows domain network.This realization puts a heavy burden on the cloud infrastructure operators. They major players are likely able to acquire and apply the expertise and resources to make their infrastructure far more resilient and survivable than their enterprise counterparts.The weakness will likely be their personnel.Once the compute and network components are sufficiently robust from externally sourced compromise, then internal threats become the next most cost-effective and return-producing vectors for dedicated intruders.Is there anything users can do as they hand their compute and data assets to cloud operators?I suggest four moves.First, small- to mid-sized cloud infrastructure users will likely have to piggyback or free-ride on the initiatives and influence of the largest cloud customers, who have the clout and hopefully the expertise to hold the cloud operators responsible for the security of everyone’s data.Second, lawmakers may also need improved whistleblower protection for cloud employees who feel threatened by revealing material weaknesses they encounter while doing their jobs.Third, government regulators will have to ensure no cloud provider assumes a monopoly, or no two providers assume a duopoloy. We may end up with the three major players and a smattering of smaller ones, as is the case with many mature industries.Fourth, users should use every means at their disposal to select cloud operators not only on their compute features, but on their security and visibility features. The more logging and visibility exposed by the cloud provider, the better. I am excited by new features like the Azure network tap and hope to see equivalent features in other cloud infrastructure.Remember that security has two main functions: planning/resistance, to try to stop bad things from happening, and detection/respond, to handle the failures that inevitably happen. “Prevention eventually fails” is one of my long-time mantras. We don’t want prevention to fail silently in the cloud. We need ways to know that failure is happening so that we can plan and implement new resistance mechanisms, and then validate their effectiveness via detection and response.Update: I forgot to mention that the material above assumed that the cloud users and operators made no unintentional configuration mistakes. If users or operators introduce exposures or vulnerabilities, then those will be the weaknesses that intruders exploit. We’ve already seen a lot of this happening and it appears to be the most common problem. Procedures and tools which constantly assess cloud configurations for exposures and vulnerabilities due to misconfiguration or poor practices are a fifth move which all involved should make.A corollary is that complexity can drive problems. When the cloud infrastructure offers too many knobs to turn, then it’s likely the users and operators will believe they are taking one action when in reality they are implementing another.Copyright 2003-2018 Richard Bejtlich and TaoSecurity ( and […]

Naked Security Computer Security News, Advice and Research

WeLiveSecurity News, views, and insight from the ESET security community

  • Embracing creativity to improve cyber-readiness
    by Editor on April 18, 2019 at 12:29 pm

    How approaching cybersecurity with creativity in mind can lead to better protection from digital threats The post Embracing creativity to improve cyber-readiness appeared first on WeLiveSecurity […]

  • Bug in EA’s Origin client left gamers open to attacks
    by Tomáš Foltýn on April 17, 2019 at 3:38 pm

    The gaming company has rolled out a fix for the remote code execution vulnerability, so make sure you run the platform’s latest version The post Bug in EA’s Origin client left gamers open to attacks appeared first on WeLiveSecurity […]

  • Your Android phone can now double as a security key
    by Tomáš Foltýn on April 16, 2019 at 3:38 pm

    An extra layer of security never hurt anybody, and now you can turn your phone into a physical security key The post Your Android phone can now double as a security key appeared first on WeLiveSecurity […]

  • Microsoft reveals breach affecting webmail users
    by Tomáš Foltýn on April 15, 2019 at 4:55 pm

    Some users of Microsoft’s web-based email services such as had their account information exposed in an incident that, as it later emerged, also impacted email contents The post Microsoft reveals breach affecting webmail users appeared first on WeLiveSecurity […]

  • Hackers crack university defenses in just two hours
    by Tomáš Foltýn on April 12, 2019 at 1:04 pm

    More than 50 universities in the United Kingdom had their cyber-defenses tested by ethical hackers, and the ‘grades’ aren’t pretty The post Hackers crack university defenses in just two hours appeared first on WeLiveSecurity […]

Talos Blog Talos Group, by Cisco

  • DNS Hijacking Abuses Trust In Core Internet Service
    by (Warren Mercer) on April 18, 2019 at 11:08 pm

    Authors: Danny Adamitis, David Maynor, Warren Mercer, Matthew Olney and Paul Rascagneres.Update 4/18: A correction has been made to our research based on feedback from Packet Clearing House, we thank them for their assistancePrefaceThis blog post discusses the technical details of a state-sponsored attack manipulating DNS systems. While this incident is limited to targeting primarily national security organizations in the Middle East and North Africa, and we do not want to overstate the consequences of this specific campaign, we are concerned that the success of this operation will lead to actors more broadly attacking the global DNS system. DNS is a foundational technology supporting the Internet. Manipulating that system has the potential to undermine the trust users have on the internet. That trust and the stability of the DNS system as a whole drives the global economy. Responsible nations should avoid targeting this system, work together to establish an accepted global norm that this system and the organizations that control it are off-limits, and cooperate in pursuing those actors who act irresponsibly by targeting this system.Executive SummaryCisco Talos has discovered a new cyber threat campaign that we are calling “Sea Turtle,” which is targeting public and private entities, including national security organizations, located primarily in the Middle East and North Africa. The ongoing operation likely began as early as January 2017 and has continued through the first quarter of 2019. Our investigation revealed that at least 40 different organizations across 13 different countries were compromised during this campaign. We assess with high confidence that this activity is being carried out by an advanced, state-sponsored actor that seeks to obtain persistent access to sensitive networks and systems.The actors behind this campaign have focused on using DNS hijacking as a mechanism for achieving their ultimate objectives. DNS hijacking occurs when the actor can illicitly modify DNS name records to point users to actor-controlled servers. The Department of Homeland Security (DHS) issued an alert about this activity on Jan. 24 2019, warning that an attacker could redirect user traffic and obtain valid encryption certificates for an organization’s domain names.In the Sea Turtle campaign, Talos was able to identify two distinct groups of victims. The first group, we identify as primary victims, includes national security organizations, ministries of foreign affairs, and prominent energy organizations. The threat actor targeted third-party entities that provide services to these primary entities to obtain access. Targets that fall into the secondary victim category include numerous DNS registrars, telecommunication companies, and internet service providers. One of the most notable aspects of this campaign was how they were able to perform DNS hijacking of their primary victims by first targeting these third-party entities.We assess with high confidence that these operations are distinctly different and independent from the operations performed by DNSpionage, which we reported on in November 2018. The Sea Turtle campaign almost certainly poses a more severe threat than DNSpionage given the actor’s methodology in targeting various DNS registrars and registries. The level of access we presume necessary to engage in DNS hijacking successfully indicates an ongoing, high degree of threat to organizations in the targeted regions. Due to the effectiveness of this approach, we encourage all organizations, globally, to ensure they have taken steps to minimize the possibility of malicious actors duplicating this attack methodology.The threat actors behind the Sea Turtle campaign show clear signs of being highly capable and brazen in their endeavors. The actors are responsible for the first publicly confirmed case against an organizations that manages a root server zone, highlighting the attacker’s sophistication. Notably, the threat actors have continued their attacks despite public reports documenting various aspects of their activity, suggesting they are unusually brazen and may be difficult to deter going forward. In most cases, threat actors typically stop or slow down their activities once their campaigns are publicly revealed.This post provides the technical findings you would typically see in a Talos blog. We will also offer some commentary on the threat actor’s tradecraft, including possible explanations about the actor’s attack methodology and thought process. Finally, we will share the IOCs that we have observed thus far, although we are confident there are more that we have not seen.Background on Domain Name Services and records managementThe threat actors behind the Sea Turtle campaign were successful in compromising entities by manipulating and falsifying DNS records at various levels in the domain name space. This section provides a brief overview of where DNS records are managed and how they are accessed to help readers better understand how these events unfolded.The first and most direct way to access an organization’s DNS records is through the registrar with the registrant’s credentials. These credentials are used to login to the DNS provider from the client-side, which is a registrar. If an attacker was able to compromise an organization’s network administrator credentials, the attacker would be able to change that particular organization’s DNS records at will.The second way to access DNS records is through a DNS registrar, sometimes called registrar operators. A registrar sells domain names to the public and manages DNS records on behalf of the registrant through the domain registry. Records in the domain registry are accessed through the registry application using the Extensible Provisioning Protocol (EPP). EPP was detailed in the request for comment (RFC) 5730 as “a means of interaction between a registrar’s applications and registry applications.” If the attackers were able to obtain one of these EPP keys, they would be able to modify any DNS records that were managed by that particular registrar.The third approach to gain access to DNS records is through one of the registries. These registries manage any known TLD, such as entire country code top-level domains (ccTLDs) and generic top-level domains (gTLDs). For example, Verisign manages all entities associated with the top-level domain (TLD) “.com.” All the different registry information then converges into one of 12 different organization that manage different parts of the domain registry root. The domain registry root is stored on 13 “named authorities in the delegation data for the root zone,” according to ICANN.Finally, actors could target root zone servers to modify the records directly. It is important to note that there is no evidence during this campaign (or any other we are aware of) that the root zone servers were attacked or compromised. We highlight this as a potential avenue that attackers would consider. The root DNS servers issued a joint statement that stated, “There are no signs of lost integrity or compromise of the content of the root [server] zone…There are no signs of clients having received unexpected responses from root servers.”Assessed Sea Turtle DNS hijacking methodologyIt is important to remember that the DNS hijacking is merely a means for the attackers to achieve their primary objective. Based on observed behaviors, we believe the actor ultimately intended to steal credentials to gain access to networks and systems of interest. To achieve their goals, the actors behind Sea Turtle:Established a means to control the DNS records of the target.Modified DNS records to point legitimate users of the target to actor-controlled servers.Captured legitimate user credentials when users interacted with these actor-controlled servers.The diagram below illustrates how we believe the actors behind the Sea Turtle campaign used DNS hijacking to achieve their end goals.Redirection Attack Methodology DiagramOperational tradecraftInitial accessThe threat actors behind the Sea Turtle campaign gained initial access either by exploiting known vulnerabilities or by sending spear-phishing emails. Talos believes that the threat actors have exploited multiple known CVEs to either gain initial access or to move laterally within an affected organization. Based on our research, we know the actor utilizes the following known exploits:CVE-2009-1151: PHP code injection vulnerability affecting phpMyAdminCVE-2014-6271: RCE affecting GNU bash system, specifically the SMTP (this was part of the Shellshock CVEs)CVE-2017-3881: RCE by unauthenticated user with elevated privileges Cisco switchesCVE-2017-6736: Remote Code Exploit (RCE) for Cisco integrated Service Router 2811CVE-2017-12617: RCE affecting Apache web servers running TomcatCVE-2018-0296: Directory traversal allowing unauthorized access to Cisco Adaptive Security Appliances (ASAs) and firewallsCVE-2018-7600: RCE for Website built with Drupal, aka “Drupalgeddon”As of early 2019, the only evidence of the spear-phishing threat vector came from a compromised organization’s public disclosure. On January 4, Packet Clearing House, which is not an Internet exchange point but rather is an NGO which provides support to Internet exchange points and the core of the domain name system, provided confirmation of this aspect of the actors’ tactics when it publicly revealed its internal DNS had been briefly hijacked as a consequence of the compromise at its domain registrar.As with any initial access involving a sophisticated actor, we believe this list of CVEs to be incomplete. The actor in question can leverage known vulnerabilities as they encounter a new threat surface. This list only represents the observed behavior of the actor, not their complete capabilities.Globalized DNS hijacking activity as an infection vectorDuring a typical incident, the actor would modify the NS records for the targeted organization, pointing users to a malicious DNS server that provided actor-controlled responses to all DNS queries. The amount of time that the targeted DNS record was hijacked can range from a couple of minutes to a couple of days. This type of activity could give an attacker the ability to redirect any victim who queried for that particular domain around the world. Other cybersecurity firms previously reported some aspects of this activity. Once the actor-controlled name server was queried for the targeted domain, it would respond with a falsified “A” record that would provide the IP address of the actor-controlled MitM node instead of the IP address of the legitimate service. In some instances, the threat actors modified the time-to-live (TTL) value to one second. This was likely done to minimize the risk of any records remaining in the DNS cache of the victim machine.During 2019, we observe the following name servers being used in support of the Sea Turtle campaign: DomainActive Timeframens1[.]intersecdns[.]comMarch – April 2019ns2[.]intersecdns[.]comMarch – April 2019ns1[.]lcjcomputing[.]comJanuary 2019 ns2[.]lcjcomputing[.]comJanuary 2019 Credential harvesting: Man-in-the-middle serversOnce the threat actors accessed a domain’s DNS records, the next step was to set up a man-in-the-middle (MitM) framework on an actor-controlled server.The next step for the actor was to build MitM servers that impersonated legitimate services to capture user credentials. Once these credentials were captured, the user would then be passed to the legitimate service. to evade detection, the actors performed “certificate impersonation,” a technique in which the attacker obtained a certificate authority-signed X.509 certificate from another provider for the same domain imitating the one already used by the targeted organization. For example, if a DigiCert certificate protected a website, the threat actors would obtain a certificate for the same domain but from another provider, such as Let’s Encrypt or Comodo. This tactic would make detecting the MitM attack more difficult, as a user’s web browser would still display the expected “SSL padlock” in the URL bar.When the victim entered their password into the attacker’s spoofed webpage, the actor would capture these credentials for future use. The only indication a victim received was a brief lag between when the user entered their information and when they obtained access to the service. This would also leave almost no evidence for network defenders to discover, as legitimate network credentials were used to access the accounts.In addition to the MitM server IP addresses published in previous reports, Talos identified 16 additional servers leveraged by the actor during the observed attacks. The complete list of known malicious IP addresses are in the Indicators of Compromise (IOC) section below.Credential harvesting with compromised SSL certificatesOnce the threat actors appeared to have access to the network, they stole the organization’s SSL certificate. The attackers would then use the certificate on actor-controlled servers to perform additional MitM operations to harvest additional credentials. This allowed the actors to expand their access into the targeted organization’s network. The stolen certificates were typically only used for less than one day, likely as an operational security measure. Using stolen certificates for an extended period would increase the likelihood of detection. In some cases, the victims were redirected to these actor-controlled servers displaying the stolen certificate.One notable aspect of the campaign was the actors’ ability to impersonate VPN applications, such as Cisco Adaptive Security Appliance (ASA) products, to perform MitM attacks. At this time, we do not believe that the attackers found a new ASA exploit. Rather, they likely abused the trust relationship associated with the ASA’s SSL certificate to harvest VPN credentials to gain remote access to the victim’s network. This MitM capability would allow the threat actors to harvest additional VPN credentials.As an example, DNS records indicate that a targeted domain resolved to an actor-controlled MitM server. The following day, Talos identified an SSL certificate with the subject common name of “ASA Temporary Self Signed Certificate” associated with the aforementioned IP address. This certificate was observed on both the actor-controlled IP address and on an IP address correlated with the victim organization.In another case, the attackers were able to compromise NetNod, a non-profit, independent internet infrastructure organization based in Sweden. NetNod acknowledged the compromise in a public statement on February 5, 2019. Using this access, the threat actors were able to manipulate the DNS records for sa1[.]dnsnode[.]net. This redirection allowed the attackers to harvest credentials of administrators who manage domains with the TLD of Saudi Arabia (.sa). It is likely that there are additional Saudi Arabia-based victims from this attack.In one of the more recent campaigns on March 27, 2019, the threat actors targeted the Sweden-based consulting firm Cafax. On Cafax’s public webpage, the company states that one of their consultants actively manages the i[.]root-server[.]net zone. NetNod managed this particular DNS server zone. We assess with high confidence that this organization was targeted in an attempt to re-establish access to the NetNod network, which was previously compromised by this threat actor.Primary and secondary victimsWe identified 40 different organizations that have been targeted during this campaign. The victim organizations appear to be broadly grouped into two different categories. The first group of victims, which we refer to as primary victims, were almost entirely located in the Middle East and North Africa. Some examples of organizations that were compromised include:Ministries of foreign affairsMilitary organizationsIntelligence agenciesProminent energy organizationsThe second cluster of victim organizations were likely compromised to help enable access to these primary targets. These organizations were located around the world; however, they were mostly concentrated in the Middle East and North Africa. Some examples of organizations that were compromised include:Telecommunications organizationsInternet service providersInformation technology firmsRegistrarsOne registryNotably, the threat actors were able to gain access to registrars that manage ccTLDs for Amnic, which is listed as the technical contact on IANA for the ccTLD .am. Obtaining access to this ccTLD registrars would have allowed attackers to hijack any domain that used those ccTLDs.How is this tradecraft different?The threat actors behind the Sea Turtle campaign have proven to be highly capable, as they have been able to perform operations for over two years and have been undeterred by public reports documenting various aspects of their activity. This cyber threat campaign represents the first known case of a domain name registry organization that was compromised for cyber espionage operations.In order to distinguish this activity from the previous reporting on other attackers, such as those affiliated with DNSpionage, below is a list of traits that are unique to the threat actors behind the Sea Turtle campaign:These actors perform DNS hijacking through the use of actor-controlled name servers.These actors have been more aggressive in their pursuit targeting DNS registries and a number of registrars, including those that manage ccTLDs.These actors use Let’s Encrypts, Comodo, Sectigo, and self-signed certificates in their MitM servers to gain the initial round of credentials.Once they have access to the network, they steal the organization’s legitimate SSL certificate and use it on actor-controlled servers.Why was it so successful?We believe that the Sea Turtle campaign continues to be highly successful for several reasons. First, the actors employ a unique approach to gain access to the targeted networks. Most traditional security products such as IDS and IPS systems are not designed to monitor and log DNS requests. The threat actors were able to achieve this level of success because the DNS domain space system added security into the equation as an afterthought. Had more ccTLDs implemented security features such as registrar locks, attackers would be unable to redirect the targeted domains.The threat actors also used an interesting techniques called certificate impersonation. This technique was successful in part because the SSL certificates were created to provide confidentiality, not integrity. The attackers stole organizations’ SSL certificates associated with security appliances such as ASA to obtain VPN credentials, allowing the actors to gain access to the targeted network.The threat actors were able to maintain long term persistent access to many of these networks by utilizing compromised credentials.We will continue to monitor Sea Turtle and work with our partners to understand the threat as it continues to evolve to ensure that our customers remain protected and the public is informed.Mitigation strategyIn order to best protect against this type of attack, we compiled a list of potential actions. Talos suggests using a registry lock service, which will require an out-of-band message before any changes can occur to an organization’s DNS record. If your registrar does not offer a registry lock service, we recommend implementing multi-factor authentication, such as DUO, to access your organization’s DNS records. If you suspect you were targeted by this type of activity intrusion, we recommend instituting a network-wide password reset, preferably from a computer on a trusted network. Lastly, we recommend applying patches, especially on internet-facing machines. Network administrators can monitor passive DNS record on their domains, to check for abnormalities.CoverageCVE-2009-1151: PHP code injection vulnerability affecting phpMyAdminSID: 2281CVE-2014-6271: RCE affecting GNU bash system, specific the SMTP (this was part of the Shellshock CVEs)SID: 31975 – 31978, 31985, 32038, 32039, 32041 – 32043, 32069, 32335, 32336CVE-2017-3881: RCE for Cisco switchesSID: 41909 – 41910CVE-2017-6736: Remote Code Exploit (RCE) for Cisco integrated Service Router 2811SID: 43424 – 43432CVE-2017-12617: RCE affecting Apache web servers running TomcatSID: 44531CVE-2018-0296: Directory traversal to gain unauthorized access to Cisco Adaptive Security Appliances (ASAs) and FirewallsSID: 46897CVE-2018-7600: RCE for Website built with Drupal aka “Drupalgeddon”SID: 46316Indicators of CompromiseThe threat actors utilized leased IP addresses from organizations that offer virtual private server (VPS) services. These VPS providers have since resold many of these IP addresses to various benign customers. To help network defenders, we have included the IP address, as well as the month(s) that the IP address was associated with the threat actor.IP addressMonthYearCountry of targets199.247.3.191November2018Albania, Iraq37.139.11.155November2018Albania, UAE185.15.247.140January2018Albania206.221.184.133November2018Egypt188.166.119.57November2018Egypt185.42.137.89November2018Albania82.196.8.43October2018Iraq159.89.101.204December – January2018-2019Turkey, Sweden, Syria, Armenia, US146.185.145.202March2018Armenia178.62.218.244December – January2018-2019UAE, Cyprus139.162.144.139December 2018Jordan142.54.179.69January – February 2017Jordan193.37.213.61December2018Cyprus108.61.123.149February2019Cyprus212.32.235.160September2018Iraq198.211.120.186September2018Iraq146.185.143.158September2018Iraq146.185.133.141October2018Libya185.203.116.116May2018UAE95.179.150.92November2018UAE174.138.0.113September2018UAE128.199.50.175September2018UAE139.59.134.216July – December2018United States, Lebanon45.77.137.65March – April2019Syria, Sweden142.54.164.189March – April2019Syria199.247.17.221March 2019SwedenThe following list contains the threat actor name server domains and their IP address.DomainActive TimeframeIP address ns1[.]intersecdns[.]comMarch – April 201995.179.150.101ns2[.]intersecdns[.]comMarch – April 201995.179.150.101ns1[.]lcjcomputing[.]comJanuary 2019[.]lcjcomputing[.]comJanuary 2019 […]

  • Threat Source (April 18): New attacks distribute Formbook, LokiBot
    by (Jonathan Munshaw) on April 18, 2019 at 6:00 pm

    Newsletter compiled by Jonathan Munshaw.Welcome to this week’s Threat Source newsletter — the perfect place to get caught up on all things Talos from the past week.If you haven’t yet, there’s still time to register for this year’s Talos Threat Research Summit — our second annual conference by defenders, for defenders. This year’s Summit will take place on June 9 in San Diego — the same day Cisco Live kicks off in the same city. We sold out last year, so hurry to register!The top news this week is, without a doubt, Sea Turtle. Wednesday, we posted our research related to this DNS hijacking campaign that has impacted countries around the world and is going after government agencies, many dealing with national security. You can check out all the details here. This week’s episode of the Beers with Talos podcast also discusses Sea Turtle.And while it didn’t grab as many headlines, we also wrote this week about HawkEye Reborn, a variant of the HawkEye malware. The keylogger recently changed ownership, and the new actors behind the malware have recently made a sizable push to infect users.Also, take a look below to find out new information regarding LokiBot.Finally, we also have our weekly Threat Roundup, which you can find on the blog every Friday afternoon. There, we go over the most prominent threats we’ve seen (and blocked) over the past week.Upcoming public engagements with TalosEvent: Cisco Connect Salt Lake CityLocation: Salt Lake City, UtahDate: April 25Speaker: Nick BiasiniSynopsis: Join Nick Biasini as he takes part in a day-long education event on all things Cisco. Nick will be specifically highlighting the work that Talos does as one part of the many breakout sessions offered at Cisco Connect. This session will cover a brief overview of what Talos does and how we operate. Additionally, he’ll discuss the threats that are top-of-mind for our researchers and the trends that you, as defenders, should be most concerned about.  Cyber Security Week in ReviewLaw enforcement agencies are increasingly using location data from Google to find crime suspects. A new report says the company scans mobile devices to create a “net” of people who were in the area of a given crime.Ecuador says it was targeted by nearly 40 million cyber attacks last weekend after the arrest of WikiLeaks’ founder Julian Assange. Assange was being held in Ecuador’s embassy.Several phony apps on the Google Play store are stealing users’ Instagram logins. The apps have been downloaded hundreds of thousands of times and claim to help users boost their number of followers.Oracle’s latest quarterly security update includes fixes for nearly 300 vulnerabilities. Forty-two of the bugs could be exploited by attackers with no user credentials.WhatsApp will soon add a new feature that will allow users to block others from taking screen captures of their messages. However, the feature will only be blocked at the local level, not the conversation level.Cisco patched a critical vulnerability in its ASR 9000 line of wireless routers. The most serious bug had a severity score of 9.8 out of a possible 10. An attacker could exploit this flaw to launch denial-of-service attacks against the router’s owner.Attackers may have been able to read users’ emails in Hotmail, MSN and Outlook. Microsoft confirmed earlier in the week that some of the company’s email services were targeted in a cyber attack. But one employee who was witness to the attacks says the attackers were able to read some emails.The fallout of Julian Assange’s arrest continues. Some critics say that the indictment against him could have wide-reaching consequences, especially for journalists who publish classified government information.Notable recent security issuesTitle: Formbook, LokiBot attacks target Middle Eastern energy companiesDescription: From mid-February through mid-March, Talos monitored phishing campaigns purporting to be sent from a legitimate domain registered to a large organization in the oil and gas industry. Cisco Talos recently discovered yet another campaign using specially crafted, malicious — yet persuasive — emails to target a legitimate organization in the oil and gas industry in the Middle East. The campaign deploys malware that exhibits similarities to the data-stealing malware families of LokiBot and Formbook. At the end of this newsletter, you’ll see a list of IOCs related to these attacks.Title: Zero-day in Internet Explorer could be exploited even if user isn’t running web browserDescription: A vulnerability in the way Microsoft Internet Explorer handles MHT files. If a user were to open a specially crafted MHT file, an attacker could gain the ability to exfiltrate local files and carry out additional spying on locally installed program version information. The interaction could even be carried out automatically without any user interaction.Snort SIDs: 49799, 49800Most prevalent malware files this weekSHA 256: 3f6e3d8741da950451668c8333a4958330e96245be1d592fcaa485f4ee4eadb3MD5: 47b97de62ae8b2b927542aa5d7f3c858Typical Filename: qmreportupload.exeClaimed Product: qmreportuploadDetection Name: Win.Trojan.Generic::in10.talosSHA 256: 8f236ac211c340f43568e545f40c31b5feed78bdf178f13abe498a1f24557d56MD5: 4cf6cc9fafde5d516be35f73615d3f00Typical Filename: max.exeClaimed Product: 易语言程序Detection Name: Win.Dropper.Armadillo::1201SHA 256: 46bc86cff88521671e70edbbadbc17590305c8f91169f777635e8f529ac21044MD5: b89b37a90d0a080c34bbba0d53bd66dfTypical Filename: cab.exeClaimed Product: Orgs psDetection Name: W32.GenericKD:Trojangen.22ek.1201SHA 256: 790c213e1227adefd2d564217de86ac9fe660946e1240b5415c55770a951abfdMD5: 147ba798e448eb3caa7e477e7fb3a959Typical Filename: ups.exeClaimed Product: TODO: <产品名>Detection Name: W32.Variant:XMRig.22fc.1201SHA 256: d05a8eaf45675b2e0cd6224723ededa92c8bb9515ec801b8b11ad770e9e1e7edMD5: 6372f770cddb40efefc57136930f4eb7Typical Filename: maftask.zipClaimed Product: N/ADetection Name: PUA.Osx.Adware.Gt32supportgeeks::tpdIndicators of compromiseDomainsplenoils[.]comsharedrive[.]topalkzonobel[.]comweb2prox[.]comoffice[.]webxpo[.]usIPs84[.]38[.]132[.]25173[.]198[.]217[.]12337[.]49[.]225[.]195URLshxxps://sharedrive[.]top/?qphxxp://sunny-displays[.]com:80/old/lk/fre.phphxxp://sunny-displays[.]com/secured/lk/PvqDq929BSx_A_D_M1n_a.phphxxp://modernizingforeignassistance[.]net/wp-content/plugins/projects/we.htahxxp://37[.]49[.]225[.]195/hook/logs/fre.phpEmails3a5d7cd294848302f16c47735fe6342c1811c4d2309ff1a250d9bad267c2e2781ace02fe46edcff8d775e3e3865813d204b138ab50e3edf6b94fc0c3afd9e8837a47388b6d66aadeb16cf86cc27bab61006ee33f561a99d2f54f3e8b7652361ecc63041400a7b39fb0560b1e5ecfe980f0ff4915b473881e203b85a14c192e5033ae7a8b755786de1e56341449c763fa43861a503937b3de0778188814b0f5f27a47388b6d66aadeb16cf86cc27bab61006ee33f561a99d2f54f3e8b7652361ecc63041400a7b39fb0560b1e5ecfe980f0ff4915b473881e203b85a14c192e5033ae7a8b755786de1e56341449c763fa43861a503937b3de0778188814b0f5f245fd204c881bc2002cba8b58eb8f135c8e8f2b290bcede597ab1bd66470285708b6819c03ab993eb21adb59f06cb4476eb6ea869f61004b56df7b3a1ee999e2846a047e141ed8fa151a9e3cf869ed2c56234d0de0b627d998b247150c8f99984597cab0edaf0034d7aab7b1ecca1bf0dcd25a094cdaf10bca6f7cb38c7f17dafd6e4818a63a1dc2a1887135563c0591bdb4d524b6bd4d37aa5e5051935aa7578Email addressesNasser[.]K[.]@plenoils[.]comg9825@live[.]commailer@matterbusiness[.]xyzinf0-greenhillsports@outlook[.]deyouzs@ropasz[.]mlpunker@biven[.]mlotaz@viotaz[.]mlriyanlepine@drylnewby[.]cfwebxpoinc@yahoo[.]comchosipongs@gmail[.]comFormbook mMutex 8-3503835SZBFHHZMalware SHA256d667c0c158786889fafa273d81bce9980bdc6ab54ea58bd2a558e248598158ac maldocae55388db9f39945f3aee9e6c2a66bacfe6483eb83341b0982a6741c83a28a34 maldoce27d1d4de73d75968cacc3a581e54f71fef372a8661297c59a8d1a8cea60a51d .hta file8220331b94a0dc7207246b0a2193ba2335bb70c673a085f52de0bb66786c86ce3497d5897559c595f1ebd982171d74770dd135973eb6ea62f8fad6fec6438acc2718ac89d522881522af2fb0b552ef55e25308544b594ed64e7f15f31acdec73Additional Maldocs62ed293128f4728ef73efb2089d92e68fe21937aca34577d3083d1cda3fab60ebfce7a05c96bf7ffbafa03f283c0fa2bdc13521f9e2f1664cb522d88def782c6907c57b17f97570704df5391c2f49ff2a13d513f1da95c0f24f34285bb01dfe46d4211fe7b01222bfa653dcc9e3eadd542bbd5b03ab44f2c459508eff9acff39636fd49f53c72528f7a8780ccb4cf064839a9bd29f3f65499f10919ae5939c0a5b1392ad890381075aeac3ef5839aace8a42460ca80834320a483202656721d60ca5a9a87b301d664c16c9237900adf3e12a48c5a36b7d94e4beb99eeaf127d77db875e9bf67c66365778004bcb5e502f91e852ad02f99b7be5160350d3edcf2ff063e2b52f753778ac92eb436e6b35f6255c11970febc9868c29abd2e3fbeac0ca5a9a87b301d664c16c9237900adf3e12a48c5a36b7d94e4beb99eeaf127d7ff063e2b52f753778ac92eb436e6b35f6255c11970febc9868c29abd2e3fbeacdea7c0f7d5c7b941d1dbae7f271cec5906fd08d529a5165e4bdb825fd502a79fb9bc454e763b66df9623de4116503f3f1972eaa83beafe062856b214e01dad25a1f9826d9e376eaca7b6f597fbec52ae6b588d687e083fca09606cbc1bb0ce101b60205a11da53b07e53297f26353d65d6e3777de2464b59b73908dec51d85603de7152b38fa291592f749037908c01ab85705e138073ede18286dd2ac18fc4a64fc2ec1ece8ffed4d8d7a94f48fa5ac191b3b7de8a2da8971c75f28aa7dd9607db875e9bf67c66365778004bcb5e502f91e852ad02f99b7be5160350d3edcf2e27c409bd463f4d14ee606b71216ef895f8767a6d1845d8a92bd2dd17dd3f7972acc3bdf6821d27a401376845659040d75dd31d0405da2e1809a22a9b5f65145461a950af13fe9b1d18c9895b7fa844ab9fcae0b7f17af438bd886fae146502e97d3a9daa6c215983b340d8b4e8bf89561383e260a2c05f71c6d26014f6bc96d1c878537a25979839e31f128e8ef4e7f582c196448c8e0e1277f0568e566a067722be87f72a8e18c0b7f50cdac7e118f64364f519cf59d0b4e0f4798029847d8Files referring to alkzonobel[.]comb0dc50e22a2c3fe76831f2990dcd7b1b0ca969113c2d0c962d84c5e8b02ae75f maldoc1365104bee40dc25b0df2e9102961c9fbce10658cce9f15b9f45d0e60e18d3a9 maldocc08fafb05053df47f2f830d0c6d7fe34be30b13bd2280ab2db6249d7dae6b5fb maldocFiles referring to web2prox[.]com5b3c39e9d85ac947f830ed02988277f6460b991aa050063545cffb147029fd51 maldocPO58609.doc811c32c017d340fe1d198ff441b14d95c7101bd04cd4fdeaaaf03124700bf3efPO58610.doc1c3c62a64dcb66595eb8140fc73a9e0cbfdc9fe5f73f802489c04a460fa6e6ba[1][2][3][4] […]

  • Threat Source (April 4)
    by (Jonathan Munshaw) on April 18, 2019 at 3:38 pm

    Welcome to this week’s Threat Source newsletter — the perfect place to get caught up on all things Talos from the past week.If you haven’t yet, there’s still time to register for this year’s Talos Threat Research Summit — our second annual conference by defenders, for defenders. This year’s Summit will take place on June 9 in San Diego — the same day Cisco Live kicks off in the same city. We sold out last year, so hurry to register!Finally, we also have our weekly Threat Roundup, which you can find on the blog every Friday afternoon. There, we go over the most prominent threats we’ve seen (and blocked) over the past week.Upcoming public engagements with TalosEvent: Cisco Connect Salt Lake CityLocation: Salt Lake City, UtahDate: April 25Speaker: Nick BiasiniSynopsis: Join Nick Biasini as he takes part in a day-long education event on all things Cisco. Nick will be specifically highlighting the work that Talos does as one part of the many breakout sessions offered at Cisco Connect. This session will cover a brief overview of what Talos does and how we operate. Additionally, he’ll discuss the threats that are top-of-mind for our researchers and the trends that you, as defenders, should be most concerned about.  Cyber Security Week in ReviewSome Facebook users are being prompted to enter their email accounts’ password when signing up. Facebook says it will stop the practice, and reiterated that it never stored those passwords on any servers.Facebook CEO Mark Zuckerberg last week pushed for the U.S. to adopt stronger internet privacy and election laws. Zuckerberg proposed in an interview that the federal government create an independent body that would set definitions for what terrorist content and hate speech are and should, therefore, be banned online.Google’s latest security bulletin warns of three critical vulnerabilities in the Android operating system. These bugs could allow an attacker to remotely take over a device by tricking the user into opening a malicious file.Australia and Singapore introduced new laws that impose harsh punishments on websites that do not remove violent content quickly. The countries hope to reduce the amount of pro-terrorist content circulating online. The parent company behind Planet Hollywood and Buca di Beppo says more than 2 million customers had their credit card information stolen. The restaurants say a credit card skimming malware existed on their point-of-sale system for months. Bayer, one of the largest chemicals companies in the world, says it suffered a cyber attack, but no data was taken. The German company said an APT spied on its networks for months, but it so far has not discovered any “data outflow.”Two third-party app developers may have publicly exposed more than 2 million Facebook users’ personal records. Security researchers say they discovered the two data sets on exposed Amazon Web Services S3 servers.A major cryptocurrency exchange in South Korea says it lost millions of dollars worth of currencies in a heist. Bithumb says it believes the attack was carried out by a group of insiders.Cisco says two patches released earlier this year for its routers do not work properly. The company says its seen live attacks on the RV320 and RV325 routers and are working on a new fix.Notable recent security issuesTitle: Huawei PCManager could allow attackers to alter Windows kernelDescription: Microsoft recently discovered a serious vulnerability in Huawei’s PCManager that could allow attackers to alter the Windows 10 kernel in Huawei’s line of MateBook machines. The Chinese tech company patched the bug in January, but it was just disclosed last week. An attacker could exploit this vulnerability by tricking the user into running a malicious application.Snort SIDs: 49628 – 49632Title: Cisco discloses several vulnerabilities in IOS XEDescription: Cisco released a slew of patches last week to fix 24 vulnerabilities in its IOS operating system. The company also warned customers that two routers in its RV line are open to attack, and no fix is available as of yet. Fifteen of the bugs exist on IOS XE, which runs on Cisco networking gear such as switches, routers and controllers.Snort SIDs: 49606 – 49616, 49588 – 49591Most prevalent malware files this weekSHA 256: d98edcaf8acdd135b38ad5d6ce503e59868555f5acb6aaa95017ec758a6603acMD5: a7608ce0baea081df610eb9accb4400eTypical Filename: emotet_e1_d98edcaf8acdd135b38ad5d6ce503e59868555f5acb6aaa95017ec758a6603ac_2019-03-26__175503.exe_Claimed Product: Advanced PDF ConverterDetection Name: W32.d98edcaf8a.Malspam.MRT.TalosSHA 256: ec604bc4c6020b69868f14ea05295ac7c27e0ec01c288657199d8917850f3443MD5: 97911a1da380f874393cf15982c6b1b9Typical Filename: spoolsv.exeClaimed Product: Microsoft® Windows® Operating SystemDetection Name: W32.GenericKD:Trojan.22co.1201SHA 256: 3f6e3d8741da950451668c8333a4958330e96245be1d592fcaa485f4ee4eadb3MD5: 47b97de62ae8b2b927542aa5d7f3c858Typical Filename: qmreportupload.exeClaimed Product: qmreportuploadDetection Name: Win.Trojan.Generic::in10.talosSHA 256: 8f236ac211c340f43568e545f40c31b5feed78bdf178f13abe498a1f24557d56MD5: 4cf6cc9fafde5d516be35f73615d3f00Typical Filename: max.exeClaimed Product: 易语言程序Detection Name: Win.Dropper.Armadillo::1201SHA 256: 46bc86cff88521671e70edbbadbc17590305c8f91169f777635e8f529ac21044MD5: b89b37a90d0a080c34bbba0d53bd66dfTypical Filename: u.exeClaimed Product: Orgs psDetection Name: W32.GenericKD:Trojangen.22ek.1201 […]

  • Beers with Talos Ep. #51: Sea Turtles yeeting packets
    by (Mitch Neff) on April 17, 2019 at 10:17 pm

    Beers with Talos (BWT) Podcast Ep. No. 51 is now available. Download this episode and subscribe to Beers with Talos:If iTunes and Google Play aren’t your thing, click here.Recorded April 12, 2019 — Today, we rip through a few other things to spend most of our time discussing Sea Turtle, the latest DNS hijacking campaign discovered by Talos. Also, Joel causes the biggest blockchain outburst in some time. Special thanks for today’s podcast goes to Danny Adamitis, the main Talos researcher on the Sea Turtle campaign. Danny was going to be with us today, but experienced some technical issues that prevented that from happening. RIP Danny’s mic: 4-12-19.The timeline:00:35 — Roundtable: Let’s play guess why Mitch(ell) was in the ER and what Nigel scrapes off Craigslist14:10 — Banking trojans: It’s Gustuff, man.16:50 — Sextorition scam update: Cash cow or grinders game?19:00 — DNS Attacks: A primer to Sea Turtle22:00 — Sea Turtle: Abusing the fundamental trust at the core of the internet53:00 — Parting shots and closing thoughtsSome other links:TTRS tickets are on sale now!Why it is really called Sea Turtle==========Featuring: Craig Williams (@Security_Craig), Joel Esler (@JoelEsler), Matt Olney (@kpyke) and Nigel Houghton (@EnglishLFC).Hosted by Mitch Neff (@MitchNeff).Subscribe via iTunes (and leave a review!)Check out the Talos Threat Research BlogSubscribe to the Threat Source newsletterFollow Talos on TwitterGive us your feedback and suggestions for topics: […]

  • New HawkEye Reborn Variant Emerges Following Ownership Change
    by (Edmund Brumaghin) on April 16, 2019 at 6:45 pm

    Edmund Brumaghin and Holger Unterbrink authored this blog post.Executive summaryMalware designed to steal sensitive information has been a threat to organizations around the world for a long time. The emergence of the greyware market and the increased commercialization of keyloggers, stealers, and remote access trojans (RATs) has magnified this threat by reducing the barrier to entry for attackers. In many cases, the adversaries leveraging these tools do not need to possess programming skills or in-depth computer science expertise, as they are now being provided as commercial offerings across the cybercriminal underground. We have previously released in-depth analyses of these types of threats and how malicious attackers are leveraging them to attack organizations with Remcos in August and Agent Tesla in October.HawkEye is another example of a malware kit that is actively being marketed across various hacking forums. Over the past several months, Talos observed ongoing malware distribution campaigns attempting to leverage the latest version of the HawkEye keylogger/stealer, HawkEye Reborn v9, against organizations to steal sensitive information and account credentials for use in additional attacks and account compromise. History of HawkEyeHawkEye is a malware kit that has been around for several years and has seen continuous development and iterations since at least 2013. It is commonly sold on various hacking forums as a keylogger and stealer that can be used to monitor systems and exfiltrate information from those systems. It features robust stealing capabilities as it can be used to obtain sensitive information from a variety of different applications. This information can then be transmitted to the attacker using protocols such as FTP, HTTP, and SMTP. Talos has recently identified several changes concerning HawkEye Reborn in the latest version, HawkEye Reborn v9. In December 2018, a thread on HackForums described a change in the ownership and ongoing development of the HawkEye keylogger.Shortly following this exchange, new posts began to appear that were attempting to market and sell new versions of HawkEye (HawkEye Reborn v9), with these new posts also referencing the change in ownership of the project moving forward.HawkEye Reborn v9 is currently marketed as an “Advance Monitoring Solution.” It is currently being sold using a licensing model, with purchasers gaining access to the software and updates for different periods based on a tiered pricing model.HawkEye Reborn v9 also features a Terms of Service agreement that provides some additional insight. While the seller specifies that HawkEye Reborn should only be used on systems with permission, they also explicitly forbid scanning of HawkEye Reborn executables using antivirus software, likely an attempt to minimize the likelihood that anti-malware solutions will detect HawkEye Reborn binaries.Following these changes, the new developer of HawkEye Reborn has continued to make changes and we expect this to continue as long as the developer can monetize their efforts.As with other malware that we wrote about last year, while the developer claims that the software should only be used on systems with permission, or “for educational purposes,” malicious attackers have been continuously leveraging it against various targets around the world.Distribution campaignsFor several months during the last half of 2018 and continuing into 2019, Cisco Talos has observed ongoing malicious email campaigns that are being used to distribute versions of the HawkEye Reborn keylogger/stealer. The current version, HawkEye Reborn v9 has been modified from earlier versions and heavily obfuscated to make analysis more difficult.The email campaigns that have been observed feature characteristics that are consistent with what is commonly seen with malspam campaigns, with the emails purporting to be associated with various documents such as invoices, bills of materials, order confirmations, and other corporate functions. An example of one of these emails is below:Figure 1: Example email messageWhile the current email contains leverage malicious Microsoft Excel files, earlier campaigns have also been observed leveraging RTF and DOC files. Additionally, a small number of campaigns over this same period also made use of various file-sharing platforms like Dropbox for hosting the malicious documents rather than directly attaching them to the messages themselves.Figure 2: Example malicious Excel documentSimilar to the technique described in our previous blog about Remcos, the contents of the documents have been intentionally made to appear as if they are blurry, with the user being prompted to enable editing to have a clearer view of the contents. Another interesting characteristic of the malicious documents is that the metadata associated with the document files themselves also matches that found in many of the malicious documents that were previously being used to spread Remcos.Figure 3: Document metadataAdditionally, the creation and modification dates associated with these documents are shortly after we released a detailed analysis of Remcos distribution campaigns that were being observed throughout 2018. Assuming the victim opens the attachment, the infection process begins as described in the following section.Many of the distribution servers that are being used to host the HawkEye keylogger binaries that are retrieved during the infection process are hosting large numbers of malicious binaries and, in many cases, contain open directory listings that can be used to identify the scope of the infections that they are being used to facilitate. In many cases, additional stealers, RATs, and other malware were observed being hosted on the same web servers.Analysis of HawkEye Reborn The campaign starts with sending the aforementioned Excel sheets that exploit the well-known CVE-2017-11882 vulnerability, an arbitrary code execution bug in Microsoft Office. The exploit works similarly to what we saw with Agent Tesla in October. It leverages a buffer overflow in the Equation Editor, which occurs if someone hands over a font name that’s too long. The shellcode starts after the MTEF font tag “08 13 36” in this case.After execution in the Equation Editor (EQNEDT32.EXE) context, it downloads the malicious data from the malware server as you can see in the ThreatGrid Process Timeline screenshot below. After a successful download, it creates and starts the RegAsm.exe process.This RegAsm.exe process is a heavily obfuscated AutoIT script compiled into a PE. After decompiling it from the PE file, it is heavily obfuscated and still almost unreadable.We deobfuscated the script to understand how the infection process works. It first creates the “winrshost” mutex. Then, it extracts the final payload malware from two objects in the PE resource section (capisp1, appsruprov2).It concatenates them and uses AES to decrypt the result, using the hardcoded key “pydbdio…” which is handed over to the DecryptData function (see above). The screen capture below shows the decryption function.It then calls the StartAndPatchRegAsm function.This function tries to find the original Microsoft RegAsm executable path. It hands over the decrypted buffer extracted from the resource section and the path from the original RegAsm executable to the start_protect_hexcode function.Then it starts the process-hollowing shellcode, which is stored in the HEXCODE1 variable. This shellcode injects the final payload taken from the resource section into the original RegAsm.exe process. The shellcode in HEXCODE1 is very similar to this RunPE example. The AutoIT script is offering a lot of other functions which are not used in this campaign, like anti-virtual machine detection, USB drive infection and others.The final payload — which we found in the AutoIT PE file resource section and was started by the process-hollowing shellcode — is a .NET PE file that’s obfuscated with ConfuserEx. Deobfuscated, we can see it is the HawkEye Keylogger — Reborn v9, Version= When HawkEye is executed, in line 34, byte[] byte_ = gclass.method_0()[“0”, GClass30.GEnum3.RCDATA].Byte_0;it reads the encrypted configuration from the RCDATA resource and in line 33,byte[] byte_2 = GClass29.smethod_12(byte_, GClass12.string_0);and then decrypts this data with the Rijndael algorithm you can see below in the RijndaelManaged function to initialize the HawkEye configuration settings.The decrypted configuration shows us the account used for exfiltration:The main loop of HawkEye has the following functions:This shows the rich feature set of HawkEye. The adversaries can get detailed information about the victim’s machine, as you can see in the screenshot below.Beside the system information, it steals passwords from common web browsers, Filezilla, Beyluxe Messenger, CoreFTP and the video game “Minecraft.” It also starts a keylogger, steals clipboard content, takes screenshots from the desktop and pictures from the webcam. Version 9 is still using the well-known MailPassView and WebBrowserPassView freeware tools from Nirsoft to steal web and email passwords. These tools are embedded in the PE file in the form of data which is decoded at runtime and added to the local resources. Then, they are using the process hollowing technique to hide the execution of these tools inside of the original Microsoft vbc.exe (VisualBasic Compiler) process. They are starting an instance of vbc.exe via ProcessCreate, injecting the tool and resume the threat. The stolen passwords are ending up in a temporary file, which is read in and added to the list of data to be exfiltrated. HawkEye offers the following exfiltration options based on the configuration: email, FTP, SFTP, HTTP POST to PanelURL API or ProxyURL.As mentioned above, in the comments of the main loop section, it also comes with several anti-analysis features, including starting an anti-debugging thread or disabling certain AV-related programs via the Image File Execution Options (IFEO) evasion technique by registering invalid debuggers that redirect and effectively disable various system and security applications.The following diagram summarizes the full infection process:ConclusionRecent changes in both the ownership and development efforts of the HawkEye Reborn keylogger/stealer demonstrate that this is a threat that will continue to experience ongoing development and improvement moving forward. HawkEye has been active across the threat landscape for a long time and will likely continue to be leveraged in the future as long as the developer of this kit can monetize their efforts. While the Terms of Service have been written in an attempt to absolve the developer of any wrongdoing, it is actively leveraged by malicious adversaries. Organizations should be aware of this and similar threats and deploy countermeasures such as Multi-Factor Authentication (MFA) solutions such as Duo, to help reduce the impact of credential theft within their environments. Talos continues to monitor this threat as it changes to ensure that customers remain protected from this and other threats as they continue to emerge and evolve.CoverageAdditional ways our customers can detect and block this threat are listed below.Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.Email Security can block malicious emails sent by threat actors as part of their campaign.Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on of compromiseThe following IOCs are associated with various malware distribution campaigns that were observed during the analysis of Hawkeye Reborn v9 activity.Attachment hashes (SHA256)A list of hashes observed to be associated with malicious email attachments can be found here.PE32 hashes (SHA256)A list of hashes observed to be associated with malicious PE32 executables can be found here.DomainsThe following domains have been observed to be associated with malware campaigns. tfvn[.]com[.]vnshirkeswitch[.]netguideofgeorgia[.]orggulfclouds[.]sitejhssourcingltd[.]comkamagra4uk[.]compioneerfitting[.]compositronicsindia[.]comscseguros[.]ptspldernet[.]comtoshioco[.]comwww[.]happytohelpyou[.]inIP addressesThe following IP addresses have been observed to be associated with malware campaigns.112.213.89[.]4067.23.254[.]6162.212.33[.]98153.92.5[.]124185.117.22[.]19723.94.188[.]24667.23.254[.]17072.52.150[.]218148.66.136[.]62107.180.24[.]253108.179.246[.]13818.221.35[.]21494.46.15[.]20066.23.237[.]18672.52.150[.]218URLs:The following URLs have been observed to be associated with malware campaigns.https[:]//a[.]pomf[.]cat/http[:]//pomf[.]cat/upload[. […]

SANS Internet Stormcenter Daily Network/Cyber Security and Information Security Stormcast A brief daily summary of what is important in information security. The podcast is published every weekday and designed to get you ready for the day with a brief, usually 5 minute long, summary of current network security related events. The content is late breaking, educational and based on listener input as well as on input received by the SANS Internet Stormcenter. You may submit questions and comments via our contact form at .

  • ISC StormCast for Friday, April 19th 2019
    by Johannes B. Ullrich, Ph.D. on April 19, 2019 at 3:45 am

    Malware Delivered As a UDF .img file Stored Passwords in Plain Text Statesponsored Malware and Data Leaked 8 Live Tiles Domain Takeover […]

  • ISC StormCast for Thursday, April 18th 2019
    by Johannes B. Ullrich, Ph.D. on April 18, 2019 at 3:05 am

    DNS Hijacking by Sea Turtle Wifi Driver Vulnerabilities Virus Infects Samba Servers Attacks on Confluence […]

  • ISC StormCast for Wednesday, April 17th 2019
    by Johannes B. Ullrich, Ph.D. on April 17, 2019 at 3:20 am

    PoC Exploit for Windows 10 DHCP Client Vulnerability CVE-2019-0726 (russian) April 2019 Critical Patch Update Breached Via Phishing Attacks and GHydra Part 2 (Strings And Parameters) […]

  • ISC StormCast for Tuesday, April 16th 2019
    by Johannes B. Ullrich, Ph.D. on April 16, 2019 at 4:40 am

    Common “False Positives” in DNS Query Logs Plus Allows Filter List Providers to Inject Code in Pages in Polyglot DICOM Images VPN Ads […]

  • ISC StormCast for Monday, April 15th 2019
    by Johannes B. Ullrich, Ph.D. on April 15, 2019 at 4:35 am

    Configuring MTA-STS to Find Hidden Cameras in Your AirBNB Storage of VPN Credentials Patch Problems Explorer XML External Entity Vulnerability […]

Dark Reading: Security Monitoring Dark Reading: Connecting the Information and Security Community

    Feed has no items.

    SecurityWeek RSS Feed Latest IT Security News and Expert Insights Via RSS Feed

    • High-volume eGobbler malvertising campaign exploits zero-day Chrome bug
      by Bradley Barth on April 19, 2019 at 6:16 pm

      A malicious actor has been leveraging a Google Chrome browser exploit to deliver malvertisements to iOS users, including a campaign earlier this month during which 500 million user sessions were exposed to a session hijacking attack. Dubbed eGobbler by researchers at Confiant, the threat actor from April 6-10 ran a massive operation consisting of eight… The post High-volume eGobbler malvertising campaign exploits zero-day Chrome bug appeared first on SC Media. […]

    • Ransomware ravages municipalities nationwide this week
      by Doug Olenick on April 19, 2019 at 4:55 pm

      Municipalities took a beating this week with at least four reporting being shut down from new ransomware attacks or struggling to recover from an older incident. Augusta, Maine; Imperial County, Calif.; Stuart, Fla.; and Greenville, N.C. were all in different stages of recovering from ransomware attacks over the last seven days. Augusta City Center operations… The post Ransomware ravages municipalities nationwide this week appeared first on SC Media. […]

    • Drupal releases correct four moderately critical third-party vulnerabilities
      by Bradley Barth on April 19, 2019 at 3:54 pm

      Drupal this week issued a series of security releases to fix four “moderately critical” vulnerabilities, three related to the content management system’s Symfony PHP web application framework and a fourth involving the jQuery project JavaScript library. The three Symfony issues consist of: A cross-site scripting bug caused by the failure of validation messages in the… The post Drupal releases correct four moderately critical third-party vulnerabilities appeared first on SC Media. […]

    • Chucky is a rogue IoT device in latest Child’s Play trailer
      by Robert Abel on April 19, 2019 at 3:49 pm

      The most recent iteration of the Child’s Play franchise features the murderous doll Chucky as a rogue IoT device gone mad. The new film’s trailer features Chucky connected to the “Buddi” platform which allows users to control all of their connected home devices including various electronics, toys, and anything else that can be forged into… The post Chucky is a rogue IoT device in latest Child’s Play trailer appeared first on SC Media. […]

    • Mueller report details Russian interference in 2016 election, interactions with Trump team, WikiLeaks
      by Teri Robinson on April 19, 2019 at 1:23 pm

      Russian military intelligence apparently successfully penetrated an unnamed Florida county election system and gained “access to the network of at least one Florida county government.” And that’s just one of the findings in Special Counsel Robert Mueller’s much-anticipated report released Thursday. In the sprawling 448-page, partially redacted report, Mueller methodically laid out Russia’s efforts to… The post Mueller report details Russian interference in 2016 election, interactions with Trump team, WikiLeaks appeared first on SC Media. […]

    Google Online Security Blog The latest news and insights from Google on security and safety on the Internet.

    • Better protection against Man in the Middle phishing attacks
      by Google Security PR on April 18, 2019 at 7:07 pm

      Posted by Jonathan Skelker, Product Manager, Account SecurityWe’re constantly working to improve our phishing protections to keep your information secure. Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.However, one form of phishing, known as “man in the middle” (MITM), is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework – CEF) or another automation platform is being used for authentication. MITM intercepts the communications between a user and Google in real-time to gather the user’s credentials (including the second factor in some cases) and sign in. Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June. This is similar to the restriction on webview sign-ins announced in April 2016.What developers need to knowThe solution for developers currently using CEF for authentication is the same: browser-based OAuth authentication. Aside from being secure, it also enables users to see the full URL of the page where they are entering their credentials, reinforcing good anti-phishing practices. If you are a developer with an app that requires access to Google Account data, switch to using browser-based OAuth authentication today. […]

    • The Android Platform Security Model
      by Eugene Liderman on April 18, 2019 at 5:28 pm

      Posted by Jeff Vander Stoep, Android Security & Privacy TeamEach Android release comes with great new security and privacy features. When it comes to implementing these new features we always look at ways to measure the impact with data that demonstrates the effectiveness of these improvements. But how do these features map to an overall strategy? Last week, we released a whitepaper describing The Android Platform Security Model. Specifically we discuss: The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google. The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases. The complex threat model Android must address. How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model. How Android’s security systems have evolved over time to address the threat model. Android is fundamentally based on a multi-party consent1 model: an action should only happen if the involved parties consent to it. Most importantly, apps are not considered to be fully authorized agents for the user. There are some intentional deviations from the security model and we discuss why these exist and the value that they provide to users. Finally, openness is a fundamental value in Android: from how we develop and publish in open source, to the open access users and developers have in finding or publishing apps, and the open communication mechanisms we provide for inter-app interactions which facilitate innovation within the app ecosystem. We hope this paper provides useful information and background to all the academic and security researchers dedicated to further strengthening the security of the Android ecosystem. Happy reading! Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick KralevichNotesThe term ‘consent’ here and in the paper is used to refer to various technical methods of declaring or enforcing a party’s intent, rather than the legal requirement or standard found in many privacy legal regimes around the world. &#8617 […]

    • Gmail making email more secure with MTA-STS standard
      by Google Security PR on April 10, 2019 at 7:13 pm

      Posted by Nicolas Lidzborski, Senior Staff Software Engineer, Google Cloud and Nicolas Kardas, Senior Product Manager, Google Cloud We’re excited to announce that Gmail will become the first major email provider to follow the new SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 and SMTP TLS Reporting RFC 8460 internet standards. Those new email security standards are the result of three years of collaboration within IETF, with contributions from Google and other large email providers.SMTP alone is vulnerable to man-in-the-middle attacksLike all mail providers, Gmail uses Simple Mail Transfer Protocol (SMTP) to send and receive mail messages. SMTP alone only provides best-effort security with opportunistic encryption, and many SMTP servers do not prevent certain types of malicious attacks intercepting email traffic in transit.SMTP is therefore vulnerable to man-in-the-middle attacks. Man-in-the-middle is an attack where communication between two servers is intercepted and possibly changed without detection. Real attacks and prevention were highlighted in our research published in November 2015. MTA-STS will help prevent these types of attacks.MTA-STS uses encryption and authentication to reduce vulnerabilitiesA MTA-STS policy for your domain means that you request external mail servers sending messages to your domain to verify the SMTP connection is authenticated with a valid public certificate and encrypted with TLS 1.2 or higher. This can be combined with TLS reporting, that means your domain can request daily reports from external mail servers with information about the success or failure of emails sent to your domain according to MTA-STS policy.Gmail is starting MTA-STS adherence. We hope others will followGmail the first major provider to follow the new standard, initially launching in Beta on April 10th 2019. This means Gmail will honor MTA-STS and TLS reporting policies configured when sending emails to domains that have defined these policies. We hope many other email providers will soon adopt these new standards that make email communications more secure.Email domain administrators should set up DNS records and web server endpoint to configure MTA-STS and TLS reporting policies for incoming emails. Use our Help Center to find out how to set up an MTA-STS policy with your DNS server. G Suite admins can use the G Suite Updates blog to see what MTA-STS means for G Suite domains. […]

    • Android Security & Privacy Year in Review 2018: Keeping two billion users, and their data, safe and sound
      by Eugene Liderman on March 29, 2019 at 5:32 pm

      Posted by Meghan Kelly, Android Security & Privacy Team We’re excited to release today the 2018 Android Security and Privacy Year in Review. This year’s report highlights the advancements we made in Android throughout the year, and how we’ve worked to keep the overall ecosystem secure. Our goal is to be open and transparent in everything we do. We want to make sure we keep our users, partners, enterprise customers, and developers up to date on the latest security and privacy enhancements in as close to real-time as possible. To that end, in 2018 we prioritized regularly providing updates through our blogs and our new Transparency Reports, which give a quarterly ecosystem overview. In this year-in-review, you’ll see fewer words and more links to relevant articles from the previous year. Check out our Android Security Center to get the latest on these advancements. In this year’s report, some of our top highlights include: New features in Google Play Protect Ecosystem and Potentially Harmful Application family highlights Updates on our vulnerability rewards program Platform security enhancements We’re also excited to have Dave Kleidermacher, Vice President of Android Security and Privacy, give you a rundown of the highlights from this report. Watch his video below to learn more. […]

    • Managed Google Play earns key certifications for security and privacy
      by Eugene Liderman on March 21, 2019 at 5:01 pm

      Posted by Mike Burr, Android Enterprise Platform Specialist[Cross-posted from the Android Enterprise Keyword Blog]With managed Google Play, organizations can build a customized and secure mobile application storefront for their teams, featuring public and private applications. Organizations’ employees can take advantage of the familiarity of a mobile app store to browse and download company-approved apps. As with any enterprise-grade platform, it’s critical that the managed Google Play Store operates with the highest standards of privacy and security. Managed Google Play has been awarded three important industry designations that are marks of meeting the strict requirements for information security management practices. Granted by the International Organization for Standardization, achieving ISO 27001 certification demonstrates that a company meets stringent privacy and security standards when operating an Information Security Management System (ISMS). Additionally, managed Google Play received SOC 2 and 3 reports, which are benchmarks of strict data management and privacy controls. These designations and auditing procedures are developed by the American Institute of Certified Public Accountants (AICPA). Meeting a high bar of security management standardsTo earn the ISO 27001 certification, auditors from Ernst and Young performed a thorough audit of managed Google Play based on established privacy principles. The entire methodology of documentation and procedures for managing other companies’ data are reviewed during an audit, and must be made available for regular compliance review. Companies that use managed Google Play are assured their data is managed in compliance with this industry standard. Additionally, ISO 27001 certification is in line with GDPR compliance. Secure data managementWith SOC 2 and SOC 3 reports, the focus is on controls relevant to data security, availability, processing integrity, confidentiality and privacy, which are verified through auditing reports. In managed Google Play, the data and private applications that enter Google’s systems are administered according to strict protocols, including determinations for who can view them and under what conditions. Enterprises require and receive the assurance that their information is handled with the utmost confidentiality and that the integrity of their data is preserved. For many companies, the presence of an SOC 2 and 3 report is a requirement when selecting a specific service. These reports prove that a service company has met and is abiding by best practices set forth by AICPA to ensure data security. Our ongoing commitment to enterprise securityWith managed Google Play, companies’ private apps for internal use are protected with a set of verified information security management processes and policies to ensure intellectual property is secure. This framework includes managed Google Play accounts that are used by enterprise mobility management (EMM) partners to manage devices. Our commitment is that Android will continue to be a leader in enterprise security. As your team works across devices and shares mission-critical data through applications hosted in managed Google Play, you have the assurance of a commitment to providing your enterprise the highest standards of security and privacy. […]

WordPress Appliance - Powered by TurnKey Linux