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.

Krebs on Security In-depth security news and investigation

  • Microsoft Patch Tuesday, June 2019 Edition
    by BrianKrebs on June 12, 2019 at 1:26 pm

    Microsoft on Tuesday released updates to fix 88 security vulnerabilities in its Windows operating systems and related software. The most dangerous of these include four flaws for which there is already exploit code available. There’s also a scary bug affecting all versions of Microsoft Office that can be triggered by a malicious link or attachment. And of course Adobe has its customary monthly security update for Flash Player. […]

  • LabCorp: 7.7 Million Consumers Hit in Collections Firm Breach
    by BrianKrebs on June 4, 2019 at 9:45 pm

    Medical testing giant LabCorp. said today personal and financial data on some 7.7 million consumers were exposed by a breach at a third-party billing collections firm. That third party — the American Medical Collection Agency (AMCA) — also recently notified competing firm Quest Diagnostics that an intrusion in its payments Web site exposed personal, financial and medical data on nearly 12 million Quest patients. Just a few days ago, the news was all about how Quest had suffered a major breach. But today’s disclosure by LabCorp. suggests we are nowhere near done hearing about other companies with millions of consumers victimized because of this incident: The AMCA is a New York company with a storied history of aggressively collecting debt for a broad range of businesses, including medical labs and hospitals, direct marketers, telecom companies, and state and local traffic/toll agencies. […]

  • Report: No ‘Eternal Blue’ Exploit Found in Baltimore City Ransomware
    by BrianKrebs on June 4, 2019 at 12:16 am

    For almost the past month, key computer systems serving the government of Baltimore, Md. have been held hostage by a ransomware strain known as “Robbinhood.” Media publications have cited sources saying the Robbinhood version that hit Baltimore city computers was powered by “Eternal Blue,” a hacking tool developed by the U.S. National Security Agency (NSA) and leaked online in 2017. But new analysis suggests that while Eternal Blue could have been used to spread the infection, the Robbinhood malware itself contains no traces of it. […]

  • NY Investigates Exposure of 885 Million Mortgage Documents
    by BrianKrebs on May 31, 2019 at 1:58 pm

    New York regulators are investigating a weakness that exposed 885 million mortgage records at First American Financial Corp. [NYSE:FAF] as the first test of the state’s strict new cybersecurity regulation. That measure, which went into effect in March 2019 and is considered among the toughest in the nation, requires financial companies to regularly audit and report on how they protect sensitive data, and provides for fines in cases where violations were reckless or willful. […]

  • Canada Uses Civil Anti-Spam Law in Bid to Fine Malware Purveyors
    by BrianKrebs on May 30, 2019 at 10:21 pm

    Canadian government regulators are using the country’s powerful new anti-spam law to pursue hefty fines of up to a million dollars against Canadian citizens suspected of helping to spread malicious software. […]

BleepingComputer BleepingComputer – All Stories

Security Latest Channel Description

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

  • Know Your Limitations
    by noreply@blogger.com (Richard Bejtlich) on May 29, 2019 at 1:55 pm

    At the end of the 1973 Clint Eastwood movie Magnum Force, after Dirty Harry watches his corrupt police captain explode in a car, he says “a man’s got to know his limitations.”I thought of this quote today as the debate rages about compromising municipalities and other information technology-constrained yet personal information-rich organizations.Several years ago I wrote If You Can’t Protect It, Don’t Collect It. I argued that if you are unable to defend personal information, then you should not gather and store it.In a similar spirit, here I argue that if you are unable to securely operate information technology that matters, then you should not be supporting that IT.You should outsource it to a trustworthy cloud provider, and concentrate on managing secure access to those services.If you cannot outsource it, and you remain incapable of defending it natively, then you should integrate a capable managed security provider.It’s clear to me that a large portion of those running PI-processing IT are simply not capable of doing so in secure manner, and they do not bear the full cost of PI breaches.They have too many assets, with too many vulnerabilities, and are targeted by too many threat actors.These organizations lack sufficient people, processes, and technologies to mitigate the risk.They have successes, but they are generally due to the heroics of individual IT and security professionals, who often feel out-gunned by their adversaries.If you can’t patch a two-year-old vulnerability prior to exploitation, or detect an intrusion and respond to the adversary before he completes his mission, then you are demonstrating that you need to change your entire approach to information technology.The security industry seems to think that throwing more people at the problem is the answer, yet year after year we read about several million job openings that remain unfilled. This is a sign that we need to change the way we are doing business. The fact is that those organziations that cannot defend themselves need to recognize their limitations and change their game.I recognize that outsourcing is not a panacea. Note that I emphasized “IT” in my recommendation. I do not see how one could outsource the critical technology running on-premise in the industrial control system (ICS) world, for example. Those operations may need to rely more on outsourced security providers, if they cannot sufficiently detect and respond to intrusions using in-house capabilities.Remember that the vast majority of organizations do not exist to run IT. They run IT to support their lines of business. Many older organizations have indeed been migrating legacy applications to the cloud, and most new organizations are cloud-native. These are hopeful signs, as the older organizations could potentially  “age-out” over time.This puts a burden on the cloud providers, who fall into the “managed service provider” category that I wrote about in my recent Corelight blog. However, the more trustworthy providers have the people, processes, and technology in place to handle their responsibilities in a more secure way than many organziations who are struggling with on-premise legacy IT.Everyone’s got to know their limitations.Copyright 2003-2018 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com) […]

  • Dissecting Weird Packets
    by noreply@blogger.com (Richard Bejtlich) on May 9, 2019 at 2:30 pm

    I was investigating traffic in my home lab yesterday, and noticed that about 1% of the traffic was weird. Before I describe the weird, let me show you a normal frame for comparison’s sake.This is a normal frame with Ethernet II encapsulation. It begins with 6 bytes of the destination MAC address, 6 bytes of the source MAC address, and 2 bytes of an Ethertype, which in this case is 0x0800, indicating an IP packet follows the Ethernet header. There is no TCP payload as this is an ACK segment.You can also see this in Tshark.$ tshark -Vx -r frame4238.pcapFrame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)    Encapsulation type: Ethernet (1)    Arrival Time: May  7, 2019 18:19:10.071831000 UTC    [Time shift for this packet: 0.000000000 seconds]    Epoch Time: 1557253150.071831000 seconds    [Time delta from previous captured frame: 0.000000000 seconds]    [Time delta from previous displayed frame: 0.000000000 seconds]    [Time since reference or first frame: 0.000000000 seconds]    Frame Number: 1    Frame Length: 66 bytes (528 bits)    Capture Length: 66 bytes (528 bits)    [Frame is marked: False]    [Frame is ignored: False]    [Protocols in frame: eth:ethertype:ip:tcp]Ethernet II, Src: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb), Dst: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)    Destination: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)        Address: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)        …. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)        …. …0 …. …. …. …. = IG bit: Individual address (unicast)    Source: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)        Address: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)        …. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)        …. …0 …. …. …. …. = IG bit: Individual address (unicast)    Type: IPv4 (0x0800)Internet Protocol Version 4, Src: 192.168.4.96, Dst: 52.21.18.219    0100 …. = Version: 4    …. 0101 = Header Length: 20 bytes (5)    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)        0000 00.. = Differentiated Services Codepoint: Default (0)        …. ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)    Total Length: 52    Identification: 0xd98c (55692)    Flags: 0x4000, Don’t fragment        0… …. …. …. = Reserved bit: Not set        .1.. …. …. …. = Don’t fragment: Set        ..0. …. …. …. = More fragments: Not set        …0 0000 0000 0000 = Fragment offset: 0    Time to live: 64    Protocol: TCP (6)    Header checksum: 0x553f [validation disabled]    [Header checksum status: Unverified]    Source: 192.168.4.96    Destination: 52.21.18.219Transmission Control Protocol, Src Port: 38828, Dst Port: 443, Seq: 1, Ack: 1, Len: 0    Source Port: 38828    Destination Port: 443    [Stream index: 0]    [TCP Segment Len: 0]    Sequence number: 1    (relative sequence number)    [Next sequence number: 1    (relative sequence number)]    Acknowledgment number: 1    (relative ack number)    1000 …. = Header Length: 32 bytes (8)    Flags: 0x010 (ACK)        000. …. …. = Reserved: Not set        …0 …. …. = Nonce: Not set        …. 0… …. = Congestion Window Reduced (CWR): Not set        …. .0.. …. = ECN-Echo: Not set        …. ..0. …. = Urgent: Not set        …. …1 …. = Acknowledgment: Set        …. …. 0… = Push: Not set        …. …. .0.. = Reset: Not set        …. …. ..0. = Syn: Not set        …. …. …0 = Fin: Not set        [TCP Flags: ·······A····]    Window size value: 296    [Calculated window size: 296]    [Window size scaling factor: -1 (unknown)]    Checksum: 0x08b0 [unverified]    [Checksum Status: Unverified]    Urgent pointer: 0    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps        TCP Option – No-Operation (NOP)            Kind: No-Operation (1)        TCP Option – No-Operation (NOP)            Kind: No-Operation (1)        TCP Option – Timestamps: TSval 26210782, TSecr 2652693036            Kind: Time Stamp Option (8)            Length: 10            Timestamp value: 26210782            Timestamp echo reply: 2652693036    [Timestamps]        [Time since first frame in this TCP stream: 0.000000000 seconds]        [Time since previous frame in this TCP stream: 0.000000000 seconds]0000  fc ec da 49 e0 10 38 ba f8 12 7d bb 08 00 45 00   …I..8…}…E.0010  00 34 d9 8c 40 00 40 06 55 3f c0 a8 04 60 34 15   .4..@.@.U?…`4.0020  12 db 97 ac 01 bb e3 42 2a 57 83 49 c2 ea 80 10   …….B*W.I….0030  01 28 08 b0 00 00 01 01 08 0a 01 8f f1 de 9e 1c   .(…………..0040  e2 2c   You can see Wireshark understands what it is seeing. It decodes the IP header and the TCP header.So far so good. Here is an example of the weird traffic I was seeing.Here is what Tshark thinks of it.$ tshark -Vx -r frame4241.pcapFrame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)    Encapsulation type: Ethernet (1)    Arrival Time: May  7, 2019 18:19:10.073296000 UTC    [Time shift for this packet: 0.000000000 seconds]    Epoch Time: 1557253150.073296000 seconds    [Time delta from previous captured frame: 0.000000000 seconds]    [Time delta from previous displayed frame: 0.000000000 seconds]    [Time since reference or first frame: 0.000000000 seconds]    Frame Number: 1    Frame Length: 66 bytes (528 bits)    Capture Length: 66 bytes (528 bits)    [Frame is marked: False]    [Frame is ignored: False]    [Protocols in frame: eth:llc:data]IEEE 802.3 Ethernet    Destination: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)        Address: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)        …. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)        …. …0 …. …. …. …. = IG bit: Individual address (unicast)    Source: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)        Address: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)        …. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)        …. …0 …. …. …. …. = IG bit: Individual address (unicast)    Length: 56        [Expert Info (Error/Malformed): Length field value goes past the end of the payload]            [Length field value goes past the end of the payload]            [Severity level: Error]            [Group: Malformed]Logical-Link Control    DSAP: Unknown (0x45)        0100 010. = SAP: Unknown        …. …1 = IG Bit: Group    SSAP: LLC Sub-Layer Management (0x02)        0000 001. = SAP: LLC Sub-Layer Management        …. …0 = CR Bit: Command    Control field: U, func=Unknown (0x0B)        000. 10.. = Command: Unknown (0x02)        …. ..11 = Frame type: Unnumbered frame (0x3)Data (49 bytes)    Data: 84d98d86b5400649eec0a80460341512db97ac0d0be3422a…    [Length: 49]0000  fc ec da 49 e0 10 38 ba f8 12 7d bb 00 38 45 02   …I..8…}..8E.0010  0b 84 d9 8d 86 b5 40 06 49 ee c0 a8 04 60 34 15   ……@.I….`4.0020  12 db 97 ac 0d 0b e3 42 2a 57 83 49 c2 ea c8 ec   …….B*W.I….0030  01 28 17 6f 00 00 01 01 08 0a 01 8f f1 de ed 7f   .(.o…………0040  a5 4a                                             .JWhat’s the problem? This frame begins with 6 bytes of the destination MAC address and 6 bytes of the source MAC address, as we saw before. However, the next two bytes are 0x0038, which is not the same as the Ethertype of 0x0800 we saw earlier. 0x0038 is decimal 56, which would seem to indicate a frame length (even though the frame here is a total of 66 bytes).Wireshark decides to treat this frame as not being Ethernet II, but instead as IEEE 802.3 Ethernet. I had to refer to appendix A of my first book to see what this meant.For comparison, here is the frame format for Ethernet II (page 664):This was what we saw with frame 4238 earlier — Dst MAC, Src MAC, Ethertype, then data.Here is the frame format for IEEE 802.3 Ethernet.This is much more complicated: Dst MAC, Src MAC, length, and then DSAP, SSAP, Control, and data.It turns out that this format doesn’t seem to fit what is happening in frame 4241, either. While the length field appears to be in the ballpark, Wireshark’s assumption that the next bytes are DSAP, SSAP, Control, and data doesn’t fit. The clue for me was seeing that 0x45 followed the presumed length field. I recognized 0x45 as the beginning of an IP header, with 4 meaning IPv4 and 5 meaning 5 words (40 bytes) in the IP header.If we take a manual byte-by-byte comparative approach we can better understand what may be happening with these two frames. (I broke the 0x45 byte into two “nibbles” in one case.)Note that I have bolded the parts of each frame that are exactly the same.This analysis shows that these two frames are very similar, especially in places where I would not expect them to be similar. This caused me to hypothesize that frame 4241 was a corrupted version of frame 4238.I can believe that the frames would share MAC addresses, IP addresses, and certain IP and TCP defaults. However, it is unusual for them to have the same high source ports (38828) but not the same destination ports (443 and 3339).  Very telling is the fact that they have the same TCP sequence and acknowledgement numbers. They also share the same source timestamp.Notice one field that I did not bold, because they are not identical — the IP ID value. Frame 4238 has 0xd98c and frame 4241 has 0xd98d. The perfectly incremented IP ID prompted me to believe that frame 4241 is a corrupted retransmission, at the IP layer, of the same TCP segment.However, I really don’t know what to think. These frames were captured in a Linux 16.04 VirtualBox VM by netsniff-ng. Is this a problem with netsniff-ng, or Linux, or VirtualBox, or the Linux host operating system running VirtualBox?I’d like to thank the folks at ask.wireshark.org for their assistance with my attempts to decode this (and other) frames as 802.3 raw Ethernet. What’s that? It’s basically a format that Novell used with IPX, where the frame is Dst MAC, Src MAC, length, data.I wanted to see if I could tell Wireshark to decode the odd frames as 802.3 raw Ethernet, rather than IEEE 802.3 Ethernet with LLC headers.Sake Blok helpfully suggested I change the pcap’s link layer type to User0, and then tell Wireshark how to interpret the frames. I did it this way, per his direction:$ editcap -T user0 excerpt.pcap excerpt-user0.pcapNext I opened the trace in Wireshark and saw frame 4241 (here listed as frame 3) as shown below:DLT 147 corresponds to the link layer type for User0. Wireshark doesn’t know how to handle it. We fix that by right-clicking on the yellow field and selecting Protocol Preferences -> Open DLT User preferences:Next I created an entry fpr User 0 (DLT-147) with Payload protocol “ip” and Header size “14” as shown:After clicking OK, I returned to Wireshark. Here is how frame 4241 (again listed here as frame 3) appeared:You can see Wireshark is now making sense of the IP header, but it doesn’t know how to handle the TCP header which follows. I tried different values and options to see if I could get Wireshark to understand the TCP header too, but this went far enough for my purposes.The bottom line is that I believe there is some sort of packet capture problem, either with the softare used or the traffic that is presented to the software by the bridged NIC created by VirtualBox. As this is a lab environment and the traffic is 1% of the overall capture, I am not worried about the results.I am fairly sure that the weird traffic is not on the wire. I tried capturing on the host OS sniffing NIC and did not see anything resembling this traffic.Have you seen anything like this? Let me know in a comment here on on Twitter.PS: I found the frame.number=X Wireshark display filter helpful, along with the frame.len>Y display filter, when researching this activity.Copyright 2003-2018 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com) […]

  • Troubleshooting NSM Virtualization Problems with Linux and VirtualBox
    by noreply@blogger.com (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 192.168.40.76  gateway 192.168.40.1  netmask 255.255.255.0  dns-nameservers 192.168.40.1  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 (taosecurity.blogspot.com and www.taosecurity.com) […]

  • Thoughts on OSSEC Con 2019
    by noreply@blogger.com (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 (taosecurity.blogspot.com and www.taosecurity.com) […]

  • Twenty Years of Network Security Monitoring: From the AFCERT to Corelight
    by noreply@blogger.com (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 (taosecurity.blogspot.com and www.taosecurity.com) […]

Naked Security Computer Security News, Advice and Research

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

Talos Blog Talos Group, by Cisco

  • Threat Roundup for June 7 to June 14
    by noreply@blogger.com (William Largent) on June 14, 2019 at 4:58 pm

    Today, Talos is publishing a glimpse into the most prevalent threats we’ve observed between June 07 and June 14. As with previous roundups, this post isn’t meant to be an in-depth analysis. Instead, this post will summarize the threats we’ve observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, or ClamAV.net.For each threat described below, this blog post only lists 25 of the associated file hashes and up to 25 IOCs for each category. An accompanying JSON file can be found here that includes the complete list of file hashes, as well as all other IOCs from this post. As always, please remember that all IOCs contained in this document are indicators, and one single IOC does not indicated maliciousness.The most prevalent threats highlighted in this roundup are:Win.Trojan.Gh0stRAT-6993126-0 Trojan Gh0stRAT is a well-known family of remote access trojans designed to provide an attacker with complete control over an infected system. Capabilities include monitoring keystrokes, collecting video footage from the webcam, and uploading/executing follow-on malware. The source code for Gh0stRAT has been publicly available on the Internet for years, significantly lowering the barrier for actors to modify and reuse the code in new attacks. Win.Worm.Vobfus-6992861-0 Worm Vobfus is a worm that copies itself to external drives and attempts to gain automatic code execution via autorun.inf files. It also modifies the registry so that it will launch when the system is booted. Once installed, it attempts to download follow-on malware from its command and control (C2) servers. Win.Dropper.Nymaim-6992731-0 Dropper Nymaim is malware that can be used to deliver ransomware and other malicious payloads. It uses a domain generation algorithm to generate potential command and control (C2) domains to connect to additional payloads. PUA.Win.Adware.Qjwmonkey-6992589-0 Adware Qjwmonkey is adware that modifies the system and browser settings to display advertisements to the user. Win.Packed.NjRAT-6992540-1 Packed njRAT, also known as Bladabindi, is a remote access trojan (RAT) that allows attackers to execute commands on the infected host, log keystrokes and remotely turn on the victim’s webcam and microphone. njRAT was developed by the Sparclyheason group. Some of the largest attacks using this malware date back to 2014. Win.Malware.Tofsee-6992280-0 Malware Tofsee is multi-purpose malware that features a number of modules used to carry out various activities, such as sending spam messages, conducting click fraud, mining cryptocurrency, and more. Infected systems become part of the Tofsee spam botnet and are used to send large volumes of spam messages in an effort to infect additional systems and increase the overall size of the botnet under the operator’s control.  Win.Malware.Yobrowser-6992453-0 Malware Yobrowser is adware that typically masquerades as cracked versions of legitimate software ThreatsWin.Trojan.Gh0stRAT-6993126-0Indicators of CompromiseRegistry Keys Occurrences <HKCU>\Software\Microsoft\Windows Script Host\Settings 26 Mutexes Occurrences guduyinan.gnway.net 6 127.0.0.1 2 soiufnrfjowieursmpwoeirfujaiurvnapoai39w45 2 y927.f3322.org 2 ddos-cc.vicp.cc 2 192.168.1.100 2 linchen1.3322.org 2 \BaseNamedObjects\linchen1.3322.org 2 119.98.51.129 1 115.28.32.138 1 203.156.199.11 1 q727446006.gicp.net 1 zy520.f3322.org 1 169.254.22.15 1 118.244.153.46 1 121.199.6.242 1 192.168.1.68 1 850967012.f3322.org 1 169.254.25.100 1 a678157.oicp.net 1 192.168.0.13 1 192.168.0.101 1 cfhx.f3322.org 1 xueyang22.gicp.net 1 \BaseNamedObjects\www.touzi1616.com 1 See JSON for more IOCs IP Addresses contacted by malware. Does not indicate maliciousness Occurrences 118[.]5[.]49[.]6 2 197[.]4[.]4[.]12 2 115[.]28[.]40[.]12 2 49[.]2[.]123[.]56 2 118[.]244[.]185[.]113 2 116[.]255[.]131[.]145 2 174[.]128[.]255[.]245 1 189[.]163[.]17[.]5 1 54[.]76[.]135[.]1 1 188[.]5[.]4[.]96 1 61[.]142[.]176[.]23 1 27[.]9[.]199[.]217 1 110[.]251[.]189[.]65 1 114[.]239[.]19[.]101 1 222[.]186[.]27[.]216 1 115[.]28[.]44[.]116 1 123[.]131[.]15[.]109 1 120[.]9[.]228[.]6 1 119[.]98[.]51[.]129 1 101[.]16[.]198[.]98 1 203[.]156[.]199[.]11 1 115[.]28[.]32[.]138 1 169[.]254[.]22[.]15 1 121[.]199[.]6[.]242 1 118[.]244[.]153[.]46 1 See JSON for more IOCs Domain Names contacted by malware. Does not indicate maliciousness Occurrences guduyinan[.]gnway[.]net 5 y927[.]f3322[.]org 2 ddos-cc[.]vicp[.]cc 2 linchen1[.]3322[.]org 2 xm974192128[.]3322[.]org 1 guduyinan[.]gnway[.]com 1 278267882[.]f3322[.]org 1 a3328657[.]f3322[.]org 1 www[.]touzi1616[.]com 1 jie0109[.]hackxd[.]net 1 zy520[.]f3322[.]org 1 q727446006[.]gicp[.]net 1 850967012[.]f3322[.]org 1 a678157[.]oicp[.]net 1 cfhx[.]f3322[.]org 1 xueyang22[.]gicp[.]net 1 Files and or directories created Occurrences %TEMP%\jnbxmapdsg.vbs 1 %TEMP%\rlzocrfujx.vbs 1 %TEMP%\bvjkzncqf.vbs 1 %TEMP%\mxoejtdhe.vbs 1 %TEMP%\ofcspybli.vbs 1 %TEMP%\imopeshvj.vbs 1 %TEMP%\paybqnqnd.vbs 1 %TEMP%\ntvxzbqf.vbs 1 %TEMP%\rvxmapdsgv.vbs 1 %TEMP%\dkaqshjynd.vbs 1 %TEMP%\vbdsgvjy.vbs 1 %TEMP%\noqftiwlzo.vbs 1 %TEMP%\ovxncegixm.vbs 1 %TEMP%\qhxurnkcs.vbs 1 %TEMP%\eyaodrgujx.vbs 1 %TEMP%\zyvhdvlis.vbs 1 %TEMP%\zdrshixlao.vbs 1 %TEMP%\waoqethv.vbs 1 %TEMP%\ulabqeth.vbs 1 %TEMP%\othjxmapd.vbs 1 %TEMP%\zdeguvky.vbs 1 %TEMP%\gzgjxmoqeg.vbs 1 %TEMP%\fqwzqhkh.vbs 1 %TEMP%\ulabqrguix.vbs 1 %TEMP%\vrfxlaods.vbs 1 See JSON for more IOCs File Hashes0477c2b9ba7eecc8b0827400576860257e62a306a3e0c310eb84c537ec47e01813287e727a2be4b6a3533e768b4babfd9191ec65002abcdf77c43e69278963be1d7633311c1f671c60422a4d6723aa10a37e833e2d5df732f3988b3e379b2ee92a38fbbcef4bc83582ccd98c9bf96ff29e4c915d90802ec799420420f2cad6e62b19de056a388d0ee3672be895f4e446c42053034c68675585dd3fb54b8d1eb73821a10495fb4759fbab1ef7868eeb1e207ea6bf4211370f072b0215a14b46c83ae58dca3ce80c3ed4b65f610eee921dbeb3343619caace78c6afe21ec237f083d54f0fbd50f0b91f635a9ecc89ef8cb58c021bb60326b5fa2db75989d1bff5a3fdd3b5333f7e526e80599add12fdeef663c59ad79ef4e71491204303837773047c349433e77aefb18ea384f6ab4759f7bd49466f7a747255d19d4648fecc76249752684078dfa74cd25adbbdc9bbf7a98e6f96f5355cd52b8b77738506673e74e5a282c7230242d090844875c9f5c432dc2c4bad3ba13fa2a7df86843785f7553e08241abdfe3f13d6aa875642638d1badc6ec59cdb9757fe0fd598dc73692757fc8d1737521cb0af37fcf70079603dc0eb5da1b3bbef9bad334dfe791760685ba20f4aaf94b4f418501ae977d1f6cf947accf8134c3b9487b42cdd65ef715b5fab1a54d1338b2cb906aae3b2f5292d47445aae2af383c2a0e99b4ccf86326260f6548844d59e59dc90a12fcb97396793c20687947a6eb5cc543debecf607d161caab6c70480cd6db4f33234cfc86467bff26c2e19b804211be8c822218a940623fbdc46be1a797f743894e3e1cc003a29692d6fb9b3246de80282207d99b9c63746003a0c8fcdf11f9367ca5102c8413ee5e2cd298079de5a3ab0ba5493ea766b770d0d2e02739e0495d30f9f56c717989eec3f1da96c7ffa01b05deffeb3768d644144b33f4766a3e11a33c471cf877d5801e1833d1d1813d4a06125ff2a96a820f70fc59abd8d0b5202de65a9fc51312d18322e55b24d1f63a2339ff13d36cb616c3229fd37e2615de709496215cc9138436b16eab265e9feae9d81cfac26ed77af0d3929a62256c7aac5068ff7ca337460cb813863d7c528e95f503cc59See JSON for more IOCsCoverage Screenshots of DetectionAMPThreatGridWin.Worm.Vobfus-6992861-0Indicators of CompromiseRegistry Keys Occurrences <HKLM>\SOFTWARE\POLICIES\MICROSOFT\WINDOWS\WindowsUpdate 25 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXPLORER\ADVANCED Value Name: ShowSuperHidden 25 <HKLM>\SOFTWARE\WOW6432NODE\Policies 25 <HKLM>\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU 25 <HKLM>\SOFTWARE\POLICIES\MICROSOFT\WINDOWS\WINDOWSUPDATE\AU 25 <HKLM>\SOFTWARE\POLICIES\MICROSOFT\WINDOWS\WINDOWSUPDATE\AU Value Name: NoAutoUpdate 25 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: jauxec 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: qiusooj 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: mokiy 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: wiiorit 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: kuivuo 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: viezus 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: fonef 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: znxaaq 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: reiiraj 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: wauul 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: wlcug 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: wzzuf 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: laociek 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: tioila 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: tstoj 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: yeeuqov 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: vyjuos 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: zeuub 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: teozuim 1 Mutexes Occurrences \BaseNamedObjects\A 25 IP Addresses contacted by malware. Does not indicate maliciousness Occurrences 216[.]218[.]206[.]69 1 Domain Names contacted by malware. Does not indicate maliciousness Occurrences ns1[.]helpchecks[.]com 25 ns1[.]helpchecks[.]info 25 ns1[.]helpchecks[.]at 25 ns1[.]helpchecks[.]eu 25 ns1[.]helpchecks[.]by 25 ns1[.]helpcheck1[.]org 25 ns1[.]helpcheck1[.]com 25 ns1[.]helpcheck1[.]net 25 Files and or directories created Occurrences \??\E:\autorun.inf 25 \autorun.inf 25 \??\E:\System Volume Information.exe 25 \System Volume Information.exe 25 \$RECYCLE.BIN.exe 25 \??\E:\$RECYCLE.BIN.exe 25 \Secret.exe 25 \??\E:\Passwords.exe 25 \??\E:\Porn.exe 25 \??\E:\Secret.exe 25 \??\E:\x.mpeg 25 \Passwords.exe 25 \Porn.exe 25 \Sexy.exe 25 %HOMEPATH%\Passwords.exe 25 %HOMEPATH%\Porn.exe 25 %HOMEPATH%\Secret.exe 25 %HOMEPATH%\Sexy.exe 25 \??\E:\Sexy.exe 24 %HOMEPATH%\Passwords.exe (copy) 24 %HOMEPATH%\Porn.exe (copy) 24 %HOMEPATH%\RCX1.tmp 24 %HOMEPATH%\RCX2.tmp 24 %HOMEPATH%\RCX3.tmp 24 %HOMEPATH%\RCX4.tmp 24 See JSON for more IOCs File Hashes03f2507d1db297b7176fddce8540639e2a8986045af7d4cf27b09a424629a08d181896288ffa6cfea0d847eda1cbce7462fbdfbf6536c6b6d874155f8d23058c366c47a2774078e135f48b03f4facbbba80aa4e294d523f0112d1cf001a93e4a59570b2c73227359544e6c7fde4ba2368170ca48482cdb530de097bb833c177d5a8e8c501cc8864d928beddb8837e0ce70f272a9a6ae13d175dfcbe52d2f3d7e5b4ebc908f6cff3ad1acc262790b3b7ad1e2e65031c7b0f8c55f700ae499f40d5c314363a05429b3a76149ed8a0ab9b9342b69d76794ba9d02e3ab09092ff4ad5f06f5540689bd9346ae76995c25e8efd60d10c22ec9f6723cd6467dabd0b78e60398eff74f6a02cd6dad118d7dc028102b56b20dc6ff7bc0c383b6accdac8e960b898046d99e11912349e895685616d5c59a1d0e6d05fa23fdb654a96c6793162070e7ac4e86195d915ffecd132823e178fb7eaad331fea65926fa2bb80f23b6b63b301a133703b5a6fe3c99c4e2c5a421490daf2a26682a83b95b1eaecb18671999972c8bd0259bab9d76a6e2d9525a141ad7ba151d0b8bf77876b6d6660c77271cb745dcca0d0bb516b7ff4cd69d2c5c261df33e48091890450ca789ae081753c11420e4a06bcb790a51918923c564c6da62c46d923eeb3541e342667a45375a188c634a0c857220ee7c6ad848293ec08d1d8a9f6027f39a02194665edffe7da2c1a73cfa87b1a66d4c0bbe2b1b18ae7540e3ae4de407092fe5f56a44d77280107ca033df25818e9bb64aed5f088c98b4c75d8a3ed3d3a47bb0f2660a2b2d8b76268bc5255134ff460ee3356797657f98f8a0cc6fef98d0e173e367b6734b92944feb88a896a922c9a88fef2683e864b931fd919c4405eeab4ed6cc2a7e02a3b82b5badf315c723973a8e8d8441351a6aea76541d888bdf1db29fd4b3721bae5a2a2a0cd106146aa40390596bba6c72fa7d8c75ab237b3cbb040946fcac19afb4401b564b6330f107b4a8d95e7d28429957929140a84ee99f01eae3fc5619b3f564ef2e4550601f2728da6eec584fadcb7b5060a0df91ed2cbf4e306c5189c80909dfb38fc5646008338b31bf576275d59c5880403adc8e5bb072eec9ce1bSee JSON for more IOCsCoverage Screenshots of DetectionAMPThreatGridUmbrellaWin.Dropper.Nymaim-6992731-0Indicators of CompromiseRegistry Keys Occurrences <HKCU>\Software\Microsoft\GOCFK 24 <HKCU>\SOFTWARE\MICROSOFT\GOCFK Value Name: mbijg 24 Mutexes Occurrences Local\{369514D7-C789-5986-2D19-AB81D1DD3BA1} 24 Local\{D0BDC0D1-57A4-C2CF-6C93-0085B58FFA2A} 24 Local\{F04311D2-A565-19AE-AB73-281BA7FE97B5} 24 Local\{F6F578C7-92FE-B7B1-40CF-049F3710A368} 24 Local\{306BA354-8414-ABA3-77E9-7A7F347C71F4} 24 Local\{F58B5142-BC49-9662-B172-EA3D10CAA47A} 24 Local\{C170B740-57D9-9B0B-7A4E-7D6ABFCDE15D} 24 Local\{764A5E5B-9D8B-4E3E-3AE5-6BA089B04B34} 24 Local\{D6E0445C-66CF-7E18-EE4D-5700342376D0} 24 IP Addresses contacted by malware. Does not indicate maliciousness Occurrences 66[.]220[.]23[.]114 24 64[.]71[.]188[.]178 18 184[.]105[.]76[.]250 18 Domain Names contacted by malware. Does not indicate maliciousness Occurrences jexzc[.]in 24 nenpzs[.]com 23 Files and or directories created Occurrences %ProgramData%\ph 24 %ProgramData%\ph\fktiipx.ftf 24 %TEMP%\gocf.ksv 24 %TEMP%\fro.dfx 23 \Documents and Settings\All Users\pxs\pil.ohu 23 %LOCALAPPDATA%\giy4vh3 5 %APPDATA%\io77x 5 %LOCALAPPDATA%\av1165d 5 %APPDATA%\tv2 5 %ProgramData%\0c7 4 %LOCALAPPDATA%\g816 4 %APPDATA%\p3f 4 %LOCALAPPDATA%\r4v2rp 4 %APPDATA%\3w7 4 %ProgramData%\3e9sq 3 %ProgramData%\qi39 3 %LOCALAPPDATA%\yp870bk 3 %ProgramData%\4b8s2 3 %ProgramData%\q8216p 3 %ProgramData%\94z 2 %ProgramData%\igzk4 2 %LOCALAPPDATA%\ycq1ac 2 %APPDATA%\867j 2 %ProgramData%\9d0g9 2 %ProgramData%\0186d9m 2 See JSON for more IOCs File Hashes08beb94545dabf135ef630b432f00fc603f3797328b5a9681d9d1a80412381470be51b6a0e11b6d807c4e6d2eea49b0c9e60c23babbb48ff17c27ee2e2050eef0fee18d7562b359c642e4a953d08251b36c3971f8fc9dbfce46af98fe26f04e8160fb874c1e78de9cb2e7d6a829e5f1e40aba2edae9de7a274a9639b80b6df9d17b5939fc77e2acb9a76c9baa6c4de01822ef4633da4732a49c4cd26f2ff024c1bef5f7889b5b8528bd9f20d6218dd4faa6ff70ad60cfd182e80374045ff9faf281bae2b93ae03725217deac68fd1f513d0a0267dda486e4d2d51f92044c8fca41d57f15b7c1ffd1c4bc5af862da97963405eace4c67574d68fcd39eb4dbe6c044b688082d3305d8e0d29bf7d6d78b60078592f1bda83a90ec6d227823d0e2974cde92c748f5aa5912a83d075dae2241de2496d4f4cf8e69a04a65c2080ff0b8507340f713f0c6f4172253b20bab21bdc6dbdd7ad4866d037894acdf167c60dc50a3f7c98b739d33ff4ba7b3ef38e553a42d7b47bc8b34f2d877055da9eaa1e9514affb7cd921abb88040abc8beb7af9139488da9f625dfb8647fdab665c38c55bf35c74cfc5908e266e3d59615a16b30eb9b6de68759fe346257b420edf674867989a565971fbe6f02c909b0696edc0de6ec1234129c4df4455a1f63a70218969f167f13f7e93a17d8dfaf59eb97014aa1446db339e300982aa8dc5ca3f14e370e414e8f7895b3ed7dec9e71693f1f8ca9ad6421fe9b3c0d38280cdb1c4608a74bb6e3a0ddaf3f2d7ad6e12513004c6efd77ad6a21f2faeef0fedd214f5f3fc74d43a9e8803c815e03184619fe2ea10029e8db22c68a24290495b506fcea48e7b6a3b68714b06b9f749a20c22461ff0c7e0759f7a5ca8d51e318dec2d88be517eb6295c6f70a823a6a02f1728cb16827c545737e0b7a0a5a1cb06ebbcf965a582c92424c692ee6769d9e2f3e9e9accf5c45794cd27b95a68f507eff88850a9883929ceb3274a34650127a4cb9ccac5b5bcb559fd43f39b6b64081bd3255dccb8c665d48bddc2f4436223689fd97f11790481f8df7f0e4c91af31aed0b4a471191e25ed856ffb9ea7cea06e4de5e5eb689063324e9268730e03cd34f4dc3ee68See JSON for more IOCsCoverage Screenshots of DetectionAMPThreatGridPUA.Win.Adware.Qjwmonkey-6992589-0Indicators of CompromiseRegistry Keys Occurrences N/A – Mutexes Occurrences ATL:MemData03EAPC 10 \BaseNamedObjects\ATL:MemData03EA899552 1 \BaseNamedObjects\ATL:MemData03EA830021 1 \BaseNamedObjects\ATL:MemData03EA841675 1 \BaseNamedObjects\ATL:MemData03EA358075 1 \BaseNamedObjects\ATL:MemData03EA675052 1 \BaseNamedObjects\ATL:MemData03EA134349 1 \BaseNamedObjects\ATL:MemData03EA414408 1 \BaseNamedObjects\ATL:MemData03EA124406 1 \BaseNamedObjects\ATL:MemData03EA651689 1 \BaseNamedObjects\ATL:MemData03EA172892 1 IP Addresses contacted by malware. Does not indicate maliciousness Occurrences 47[.]102[.]38[.]15 10 39[.]108[.]27[.]173 9 47[.]95[.]181[.]45 2 36[.]99[.]227[.]233 1 Domain Names contacted by malware. Does not indicate maliciousness Occurrences x[.]93ne[.]com 10 cdn[.]zry97[.]com 1 Files and or directories created Occurrences %System32%\d3d9caps.dat (copy) 10 %System32%\d3d9caps.tmp 10 %APPDATA%\GlobalMgr.db 10 File Hashes068eda364702ce61530d3b06ff1edb490fa157572ebf936ad9ad0d913c44e46d0c748be9a32bc9ce08709f67a45fc9e3e76a06b6e30091ea6e75014651449bd61211299848ddadcaefe019ade6a5394a744297e5fbe8182d0156faffe2f40e34275b0dad9af4cad57d9fe546b7f8c11e55b848b2ca68959bbe8d45fc3195a85b326d9df48f47cad42b8a6bac64061b9e2592d62ad5c8fd2a727865f84a79b6c932a0d53d2716251728d4120e5cceb4eb8894fd830841d9476820cd868420d37a6f5854d4dce3170393d74fb216573d08b694d7ec2982f02d3e46fe34b3ba0ed770ab5cb1653e39937408d71b70c9bd3952c572a2b54bc2b039794130efe5ae778da41212571b8b910ec657bc8f1b67ef22dd3c15e40280d5c6f93a5104227c0f90a457c02c2e659902d1be908c53c38eec47574101f14477c22ec87968b5b8709ae31bf1c30051d3438f3548d5f7593c24aa9297cb9f89b26b04d01482f776229dcb833bbac2d4fabafe49babb53b127349be1ee1444031cccb77d2752206813c3e2f2e2e17f0408b11bd9cc8dc3ea97364fec6d3dea07ba896901d24f89fef4c48b5755d64f2fa9fe6bdeec4605d5352e196db78d507608fc9f181be93f9da1c4e26e43528d8be9dba86a1b7c30b4ef8bdca67b56bbcab2d7fc76cb12004b14c88992429426ed40e4a5ff37c0ff0b3ecdb52a07f7e6b4b2377a6c4160263419d29b9fa55f21577991f220bec9bbc89969e843b6b03f7dad0084e80b86961c97d2bcb4e712ee873f8cce82a2783b84bf2a11f275e9064581cf00fd88323e803ddace1d73cd93785decdc4993f12de1b214b0a836539063c5fac8b154ce948eb1db55da939400d9d718b39e20280da3317cd1d35a522ec4927b059fefea4aa754df38320eb4d1eedf53b9927cb734bf2506e3d38d04c9279e65aea08391bc6caae8a913bb3211a926e04ce387dadf74d262e287070ad08192153b4a07f8914544ed613488a7bdde693d5b819ce946a8e9865426b9ea7cbbab8a867dc4db79d483Coverage Screenshots of DetectionAMPThreatGridWin.Packed.NjRAT-6992540-1Indicators of CompromiseRegistry Keys Occurrences <HKLM>\System\CurrentControlSet\Services\NapAgent\Shas 32 <HKLM>\System\CurrentControlSet\Services\NapAgent\Qecs 32 <HKLM>\System\CurrentControlSet\Services\NapAgent\LocalConfig 32 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\NAPAGENT\LOCALCONFIG\Enroll\HcsGroups 32 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\NAPAGENT\LOCALCONFIG\UI 32 <HKU>\S-1-5-21-2580483871-590521980-3826313501-500 Value Name: di 32 <HKCU>\ENVIRONMENT Value Name: SEE_MASK_NOZONECHECKS 32 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON Value Name: ParseAutoexec 32 <HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: 7a6058fe5633bcc68b913467734f0f12 1 <HKCU>\SOFTWARE\7A6058FE5633BCC68B913467734F0F12 Value Name: [kl] 1 <HKCU>\Software\5d6c253999006e0a364768488fca8056 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: 5d6c253999006e0a364768488fca8056 1 <HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: 5d6c253999006e0a364768488fca8056 1 <HKCU>\SOFTWARE\5D6C253999006E0A364768488FCA8056 Value Name: [kl] 1 <HKCU>\Software\81d13862f7a9e91b88ef1cf04880f30b 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: 81d13862f7a9e91b88ef1cf04880f30b 1 <HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: 81d13862f7a9e91b88ef1cf04880f30b 1 <HKCU>\Software\c4356a2f1cc184765354ac346ff3c760 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: c4356a2f1cc184765354ac346ff3c760 1 <HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: c4356a2f1cc184765354ac346ff3c760 1 <HKCU>\SOFTWARE\81D13862F7A9E91B88EF1CF04880F30B Value Name: [kl] 1 <HKCU>\SOFTWARE\C4356A2F1CC184765354AC346FF3C760 Value Name: [kl] 1 <HKCU>\Software\92c90be64c51c97abffcb0136889e008 1 <HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: 92c90be64c51c97abffcb0136889e008 1 <HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: 92c90be64c51c97abffcb0136889e008 1 Mutexes Occurrences \BaseNamedObjects\23f0e3bce589df29a3e6f3e8879b41c1 1 cf56ee275cc59274062dc1b03224ca99 1 7224ecb50ef565a251e4dca6d8280c72 1 ddb5e6e34f69e8c18573f23e18eb66b5 1 dbac86ee556aeefaf987b893994aa8a6 1 9933a39bcdb4ca2ba91ddfbf0eb49c28 1 27e6ba15367cfc6ccdb30fd12c8ebc9a 1 551c2891c1a5b14d85bd8205beca398a 1 6f548f49442e3cf6cd712e1421ced30b 1 ea48d06232228d6119e51286c4c0d7cb 1 6843bfb57b172a29eaca1016ea14dd34 1 b6a24dab009c0449997c4b895176ddee 1 b17b3051ec3895b563f6189b117c7103 1 61d4512a2b96204a3981459fa733229e 1 b1471de1dda54e505e7a2fe5dc250cbd 1 5b9aa31356f88f5efd2d650bab2fd205 1 227ae895ae9adabb3c9cc7efd9b8f180 1 cf10c5de3b577ea5f5b8886499972c21 1 89ced9869827e13512140dfd15310bdb 1 7a6058fe5633bcc68b913467734f0f12 1 5d6c253999006e0a364768488fca8056 1 81d13862f7a9e91b88ef1cf04880f30b 1 c4356a2f1cc184765354ac346ff3c760 1 92c90be64c51c97abffcb0136889e008 1 d8cff2de0df1355a3d74ec30295aa1da 1 See JSON for more IOCs IP Addresses contacted by malware. Does not indicate maliciousness Occurrences 2[.]91[.]138[.]211 2 197[.]206[.]180[.]205 1 85[.]170[.]230[.]163 1 185[.]17[.]1[.]245 1 Domain Names contacted by malware. Does not indicate maliciousness Occurrences youwave932[.]no-ip[.]biz 10 dmar-ksa[.]ddns[.]net 3 karem[.]no-ip[.]org 3 alkhorsan[.]linkpc[.]net 2 sabridz[.]no-ip[.]biz 1 alkhorsan2016[.]no-ip[.]biz 1 amiramir[.]noip[.]me 1 MSKGH[.]DDNS[.]NET 1 mskhe[.]ddns[.]net 1 paleb[.]no-ip[.]org 1 yeswecan[.]duckdns[.]org 1 megatn[.]publicvm[.]com 1 Files and or directories created Occurrences %TEMP%\server.exe 4 %TEMP%\svchost.exe 2 %TEMP%\svhost.exe 1 %APPDATA%\google.exe 1 %TEMP%\system.exe 1 %TEMP%\win32.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\9933a39bcdb4ca2ba91ddfbf0eb49c28.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\27e6ba15367cfc6ccdb30fd12c8ebc9a.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\551c2891c1a5b14d85bd8205beca398a.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\6f548f49442e3cf6cd712e1421ced30b.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\cb0bc0e4b97025e4a12cd7655f373600.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ea48d06232228d6119e51286c4c0d7cb.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\6843bfb57b172a29eaca1016ea14dd34.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\b17b3051ec3895b563f6189b117c7103.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\b6a24dab009c0449997c4b895176ddee.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\61d4512a2b96204a3981459fa733229e.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\b1471de1dda54e505e7a2fe5dc250cbd.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\5b9aa31356f88f5efd2d650bab2fd205.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\cf10c5de3b577ea5f5b8886499972c21.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\89ced9869827e13512140dfd15310bdb.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\7a6058fe5633bcc68b913467734f0f12.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\5d6c253999006e0a364768488fca8056.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\81d13862f7a9e91b88ef1cf04880f30b.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\c4356a2f1cc184765354ac346ff3c760.exe 1 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\92c90be64c51c97abffcb0136889e008.exe 1 See JSON for more IOCs File Hashes04675d38c3f123c6cfe12a8b96c840894985d77a044aa009b6f6a2d1d9bd42a5070a2b244bfb020dc8c3203831e14d3f27f3a3d5a7bc0df2e1a1acc1b7a5b48a0bfae405fffc2cb791f7eefb7c4d2efe4b76235289e5a043718bc6ed7480c4f10c75f012571cc271d8c19d95b714f425bf6f5ef7b09a646c18cd0b99e0050ede0e37c0759ded6594cf671c82ea8d8404b2c8ad34c8b7c772d4f4bcdbc01f6b28133d714e145400b9adc0ac24584745443fee2a9cdcda31bd3251264e46c846071444bf151e764ffe3402827f60a142f20a0e6060ad8fb80255e1a82c63ec70e0146054936453e72343079c7c89517cef5a8e270ba827c321ce6c6740775df7c419b06c7cf56e2148202b8051d64823817d8c81afd9e6061e6e625b953439b9eb26f3184e05046a17a8a470a0ca2088a8774641729eb86c6f84310707014dfb6b2d4c6b0074ca4866f50c7242882e467a65da7f7dc28fd9c2bbd09caa6f99a8d6369f407ad2e8321d87ac5f32241d7cf2a0e72aae0b8c0caed4f30faa042ed85e3bb55a41fa1c485c018b03b521beb74a4baea14bc2b89b8b69713e07079771f93d0946ab360b335a58789cc81cb5711e438f312426b2477b2777a256f2b772c6452ec0f00cee0a7ea6c104d9835af5f3999c50b37d22081dee4b47e75b794cad469d100e0e62a4099313c485e24f134abd32e598a7f65f147342ac7ea9274f2a4cd937a9a1914666ebe671b2b9f4db59806dbacd6ae784b10f5b625e1448649f560a570d89a632b81d34cf4d1e20a86c35657d9211ac4061c419883e2b108e635da16143a544f7c51cdd146540b5393113a6768162328cfccb5e484c64472ec6619b638736132bd02470c09508cb63a3fb753c6ee0f8dab4f4af6c2694f9095f6323174f37df70906257ac7b545eeed4e1cfaea1cbbba74d5acc49230fadcf7364f50c68d48d152eba786380b7a1db84f94f28c63f34ccb499008e1889ee0675694a3485ae77c8e024295e34caf2f335eeb61d4ebcda6fd5789086526ae44a9f6aacdb0640cda4db32f307b91e4d0d6bb4d88429a14308fb90ec573a9c892afb7530fc29bdc4ae5be727789818541dafcb590bdd708e64e8bde0a4c99b37b2f7See JSON for more IOCsCoverage Screenshots of DetectionAMPThreatGridWin.Malware.Tofsee-6992280-0Indicators of CompromiseRegistry Keys Occurrences <HKLM>\System\CurrentControlSet\Services\NapAgent\Shas 17 <HKLM>\System\CurrentControlSet\Services\NapAgent\Qecs 17 <HKLM>\System\CurrentControlSet\Control\SecurityProviders\Schannel 17 <HKLM>\System\CurrentControlSet\Services\NapAgent\LocalConfig 17 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\NAPAGENT\LOCALCONFIG\Enroll\HcsGroups 17 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\NAPAGENT\LOCALCONFIG\UI 17 <HKU>\.DEFAULT\Control Panel\Buses 17 <HKU>\.DEFAULT\CONTROL PANEL\BUSES Value Name: Config3 17 <HKLM>\SOFTWARE\MICROSOFT\WINDOWS DEFENDER\EXCLUSIONS\PATHS Value Name: C:\Windows\SysWOW64\wpdjiqwl 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\wpdjiqwl 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: Type 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: Start 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: ErrorControl 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: DisplayName 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: WOW64 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: ObjectName 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: Description 3 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\WPDJIQWL Value Name: ImagePath 3 <HKLM>\SOFTWARE\MICROSOFT\WINDOWS DEFENDER\EXCLUSIONS\PATHS Value Name: C:\Windows\SysWOW64\gzntsagv 2 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\gzntsagv 2 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\GZNTSAGV Value Name: Type 2 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\GZNTSAGV Value Name: Start 2 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\GZNTSAGV Value Name: ErrorControl 2 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\GZNTSAGV Value Name: DisplayName 2 <HKLM>\SYSTEM\CONTROLSET001\SERVICES\GZNTSAGV Value Name: WOW64 2 Mutexes Occurrences N/A – IP Addresses contacted by malware. Does not indicate maliciousness Occurrences 239[.]255[.]255[.]250 17 69[.]55[.]5[.]250 17 192[.]0[.]47[.]59 16 144[.]76[.]199[.]43 15 176[.]111[.]49[.]43 15 46[.]4[.]52[.]109 15 144[.]76[.]199[.]2 15 85[.]25[.]119[.]25 15 43[.]231[.]4[.]7 15 172[.]217[.]164[.]132 15 94[.]23[.]27[.]38 15 216[.]146[.]35[.]35 14 208[.]76[.]51[.]51 13 172[.]217[.]192[.]26 13 74[.]6[.]141[.]40 13 212[.]82[.]101[.]46 12 98[.]136[.]96[.]73 12 98[.]136[.]101[.]116 12 67[.]195[.]228[.]87 12 66[.]218[.]85[.]151 12 213[.]205[.]33[.]63 12 98[.]137[.]157[.]43 12 87[.]250[.]250[.]89 12 74[.]125[.]193[.]26 12 172[.]217[.]6[.]228 11 See JSON for more IOCs Domain Names contacted by malware. Does not indicate maliciousness Occurrences 250[.]5[.]55[.]69[.]in-addr[.]arpa 17 250[.]5[.]55[.]69[.]zen[.]spamhaus[.]org 17 250[.]5[.]55[.]69[.]cbl[.]abuseat[.]org 17 250[.]5[.]55[.]69[.]dnsbl[.]sorbs[.]net 17 250[.]5[.]55[.]69[.]bl[.]spamcop[.]net 17 250[.]5[.]55[.]69[.]sbl-xbl[.]spamhaus[.]org 17 microsoft-com[.]mail[.]protection[.]outlook[.]com 17 whois[.]iana[.]org 16 whois[.]arin[.]net 16 sweety2001[.]dating4you[.]cn 16 honeypus[.]rusladies[.]cn 16 katarinasw[.]date4you[.]cn 16 marina99[.]ruladies[.]cn 16 mx-aol[.]mail[.]gm0[.]yahoodns[.]net 13 hotmail-com[.]olc[.]protection[.]outlook[.]com 13 mx1[.]emailsrvr[.]com 13 aol[.]com 13 mx-eu[.]mail[.]am0[.]yahoodns[.]net 12 tiscali[.]it 12 mxs[.]mail[.]ru 12 mx[.]yandex[.]net 12 mx[.]yandex[.]ru 12 msx-smtp-mx2[.]hinet[.]net 12 tiscalinet[.]it 11 inmx[.]rambler[.]ru 11 See JSON for more IOCs Files and or directories created Occurrences %SystemRoot%\SysWOW64\config\systemprofile:.repos 17 %SystemRoot%\SysWOW64\config\systemprofile 17 %HOMEPATH% 15 %SystemRoot%\SysWOW64\wpdjiqwl 3 %SystemRoot%\SysWOW64\gzntsagv 2 %SystemRoot%\SysWOW64\athnmuap 2 %SystemRoot%\SysWOW64\slzfemsh 2 %TEMP%\utjfmin.exe 1 %TEMP%\evorylxw.exe 1 %TEMP%\gstniefc.exe 1 %TEMP%\otggjiyd.exe 1 %TEMP%\edtpwsx.exe 1 %TEMP%\uutzkyfi.exe 1 %TEMP%\rlnkeakp.exe 1 %TEMP%\azlhmwgt.exe 1 %TEMP%\wytkbvcv.exe 1 %TEMP%\uboorcup.exe 1 %TEMP%\uxffdbfo.exe 1 %TEMP%\ondzgch.exe 1 %TEMP%\arknuhts.exe 1 %TEMP%\tyllondi.exe 1 %TEMP%\qpfbiej.exe 1 %TEMP%\jhokjsqh.exe 1 %TEMP%\lkwsxhre.exe 1 %TEMP%\pjlicyin.exe 1 See JSON for more IOCs File Hashes116bb71b6e6866ba5862d18e5361fe70ad2f9adb3ed8f5f1606e2561bff9fa792b9c74a2ffb4d1164048adec4381d151922244be8855026bff683abbf4122684397ad676785c8e47422e723c081e44172dd935bcfe1389a039ac4bb1013c50c059639b75a9ebe2fdcf6ec9623454f06455a5fa6f0a23e47cece96d98c8c0f324650c6dae8c1553d599d15e7c3d2235a393f498b743538674c7a1d87a8b627d907b962ff72c455f123c5ee0ba29aeea11e6fa23d595a0be8aad7b0235d5280d7985bd864d585a37662a1c6a28daef2ac8c97996e52bf37209e76b0a8a9d6494e1a1fd580e38af18c70ede2540e309a513e85b9a06423aee45f35fbbf1bfa517b9a94cea85efa1c6842892248e1724cd17fb66a34435c9797d9809c3e25a5e6770bad0767a0cf7088aed7904551b26bafd66b4bbc1257518275a1b277f27d1f7a9c3bb4a36939e8f6d2acf8b57b0676ca8c7bafea33cfd15bedecf192f0610e6e9c5ed772f6cb0aa202fb87049bd20063741fd62023f7d9c924876e28711dab3f2de76a7d7af2c38342333014608b75117a2d1868d9020f62fdd117cdfb5ed30fae1cfadc86259f90b2f1fb5cd23bd267a94ed8c8a2d72035b6e335fd5e68d5866ec4960b3885c4bb63032883cd088585e4f347c4ac9659f49982f999775d90a21f1e790bcc0711047ab255646e07ef7d2fb644c45b24a4bc67250e2c8ee9318a1f7699a1eafb0aded81818b28fd1c897e3e2e22d9d7b4297d97654a5aca09da49Coverage Screenshots of DetectionAMPThreatGridUmbrellaWin.Malware.Yobrowser-6992453-0Indicators of CompromiseRegistry Keys Occurrences <HKCU>\Software\Microsoft\RestartManager\Session0000 33 <HKCU>\SOFTWARE\MICROSOFT\RESTARTMANAGER\SESSION0000 Value Name: Sequence 33 <HKCU>\SOFTWARE\MICROSOFT\RestartManager 33 <HKCU>\SOFTWARE\MICROSOFT\RESTARTMANAGER\SESSION0000 Value Name: Owner 33 <HKCU>\SOFTWARE\MICROSOFT\RESTARTMANAGER\SESSION0000 Value Name: SessionHash 33 Mutexes Occurrences Local\RstrMgr-3887CAB8-533F-4C85-B0DC-3E5639F8D511-Session0000 33 Local\RstrMgr3887CAB8-533F-4C85-B0DC-3E5639F8D511 33 IP Addresses contacted by malware. Does not indicate maliciousness Occurrences N/A – Domain Names contacted by malware. Does not indicate maliciousness Occurrences N/A – Files and or directories created Occurrences %LOCALAPPDATA%\Programs 33 %LOCALAPPDATA%\Programs\Common 33 %TEMP%\is-C6FN7.tmp\32dfee8be7cca7d0ed5b84fe8deff6d7177042a802586d16c26176ec58952309.tmp 1 %TEMP%\is-9HDTO.tmp\_isetup\_setup64.tmp 1 %TEMP%\is-9HDTO.tmp\_isetup\_shfoldr.dll 1 %TEMP%\is-9HDTO.tmp\trithiweate.dll 1 %TEMP%\is-7CPIN.tmp\36ca931623f279c6683ace47e425666510034f5e18441f90e895a3fc6cd2bbdb.tmp 1 %TEMP%\is-0142V.tmp\_isetup\_setup64.tmp 1 %TEMP%\is-0142V.tmp\_isetup\_shfoldr.dll 1 %TEMP%\is-0142V.tmp\trithiweate.dll 1 %TEMP%\is-CRK4O.tmp\42827e85051a54995e67aeb54b9418968224f6c299887e4afca574e08b2b76c1.tmp 1 %TEMP%\is-Q964A.tmp\482675e5774d1714ae17b5daefd13697fe3a921feb20fc4360065c2135b9c7b0.tmp 1 %TEMP%\is-9AA9G.tmp\3f2c22316bc2184f740f39499e41002c6d525a2c4c18dd0b9170c90410a5e4d1.tmp 1 %TEMP%\is-T68TS.tmp\4a55c9ceaa100182f6fc1ce9c8ec3c0f9eb58b7841c46c7d1d66fa5eaa4f410e.tmp 1 %TEMP%\is-8V9B2.tmp\_isetup\_setup64.tmp 1 %TEMP%\is-8V9B2.tmp\_isetup\_shfoldr.dll 1 %TEMP%\is-8V9B2.tmp\trithiweate.dll 1 %TEMP%\is-P9KOG.tmp\_isetup\_setup64.tmp 1 %TEMP%\is-P9KOG.tmp\_isetup\_shfoldr.dll 1 %TEMP%\is-FPHCP.tmp\_isetup\_setup64.tmp 1 %TEMP%\is-P9KOG.tmp\trithiweate.dll 1 %TEMP%\is-FPHCP.tmp\_isetup\_shfoldr.dll 1 %TEMP%\is-FPHCP.tmp\trithiweate.dll 1 %TEMP%\is-3SHVR.tmp\_isetup\_setup64.tmp 1 %TEMP%\is-3SHVR.tmp\_isetup\_shfoldr.dll 1 See JSON for more IOCs File Hashes02be7ea7484ce02344237e4aab046aaa3af0f67f5b5bc7530b7757c1820083740912999b354d903202f981d327670d3dd5a6f37f3c3374cfbf29b9d5dce86e5a0bd58e14131755d1671174225ea1349a9c9ca54e76a29c2696aab762859ed6ea1150e22d4d164cd9a07ee28a6c6d33e657e10e1af6f06a3423c56a5f0449b02c1609b08dc860872a1a37967ec01e9c8d90813e42f4c32a4a5c7651b226bf1c7f16ee969920278d950596ee85505d40ed1b4265d6fdfa35dc55dd6d188c43261418c140ae4eb5f0bdff9f07ba176fba6873e5359ff689145bf4d41defec9f635f224b4f9f98e7d9887ebcae15c02d8973264f31d12ff87a30d696139a316e2cf9259546449e9e630fbe3bdcfbda7c51de9c1e7bb93022bda08d89bea95ad23a2426b5593a4e7c8b5accf97029cf6c646c7769cecd36d105153f228f03a20f24be2e39806e189e988a6bb094359db5aab14638a1737fded6ab00095425672aa13d2fc0b64cf4ab9d6a6a3b607b999b1e47551bfb62acf143bd08faebf0485157d732dfee8be7cca7d0ed5b84fe8deff6d7177042a802586d16c26176ec5895230936c8f82ff5ebd1647044f14b83dbfb93e1ad5e8e80d95cb2f6e3f463cf4ac94e36ca931623f279c6683ace47e425666510034f5e18441f90e895a3fc6cd2bbdb3f2c22316bc2184f740f39499e41002c6d525a2c4c18dd0b9170c90410a5e4d142827e85051a54995e67aeb54b9418968224f6c299887e4afca574e08b2b76c1482675e5774d1714ae17b5daefd13697fe3a921feb20fc4360065c2135b9c7b04843bffb11be8da31b059e63973b2f97a3a093cf80b537cb19629f49099a35c44a55c9ceaa100182f6fc1ce9c8ec3c0f9eb58b7841c46c7d1d66fa5eaa4f410e4f349d22bc1cb7e4defbd97debebe906a5408351e7069cf5cc2333338d5be8ed5677386b0050cff2f5a2c12430999d569dc744944f2f2d9c29f3bab6d5d43edf5ca1ade829002a58684dc8ff37b11e7b07d91b61a26d89a6736f884d14a0d00f5ddbe11ee1e50f6a198f1e331e55621fcfc02870f6e8b4e4d5d171bf008938b564543ddc78b58da0236310fcee0b447e153d94a4cd393c1975bbe6b000acc960See JSON for more IOCsCoverage Screenshots of DetectionAMPThreatGridExprevCisco AMP for Endpoints protects users from a variety of malware functions with exploit prevention. Exploit prevention helps users defend endpoints from memory attacks commonly used by obfuscated malware and exploits. These exploits use certain features to bypass typical anti-virus software, but were blocked by AMP thanks to its advanced scanning capabilities, even protecting against zero-day vulnerabilities. Madshi injection detected (3267) Madshi is a code injection framework that uses process injection to start a new thread if other methods to start a thread within a process fail. This framework is used by a number of security solutions. It is also possible for malware to use this technique.Kovter injection detected (2041) A process was injected into, most likely by an existing Kovter infection. Kovter is a click fraud Trojan that can also act as an information stealer. Kovter is also file-less malware meaning the malicious DLL is stored inside Windows registry and injected directly into memory using PowerShell. It can detect and report the usage of monitoring software such as wireshark and sandboxes to its C2. It spreads through malicious advertising and spam campaigns.Process hollowing detected (1016) Process hollowing is a technique used by some programs to avoid static analysis. In typical usage, a process is started and its obfuscated or encrypted contents are unpacked into memory. The parent then manually sets up the first stages of launching a child process, but before launching it, the memory is cleared and filled in with the memory from the parent instead.Excessively long PowerShell command detected (676) A PowerShell command with a very long command line argument that may indicate an obfuscated script has been detected. PowerShell is an extensible Windows scripting language present on all versions of Windows. Malware authors use PowerShell in an attempt to evade security software or other monitoring that is not tuned to detect PowerShell based threats.Dealply adware detected (284) DealPly is adware, which claims to improve your online shopping experience. It is often bundled into other legitimate installers and is difficult to uninstall. It creates pop-up advertisements and injects advertisements on webpages. Adware has also been known to download and install malware.Gamarue malware detected (197) Gamarue is a family of malware that can download files and steal information from an infected system. Worm variants of the Gamarue family may spread by infecting USB drives or portable hard disks that have been plugged into a compromised system.PowerShell file-less infection detected (53) A PowerShell command was stored in an environment variable and run. The environment variable is commonly set by a previously run script and is used as a means of evasion. This behavior is a known tactic of the Kovter and Poweliks malware families.Atom Bombing code injection technique detected (45) A process created a suspicious Atom, which is indicative of a known process injection technique called Atom Bombing. Atoms are Windows identifiers that associate a string with a 16-bit integer. These Atoms are accessible across processes when placed in the global Atom table. Malware exploits this by placing shell code as a global Atom, then accessing it through an Asynchronous Process Call (APC). A target process runs the APC function, which loads and runs the shellcode. The malware family Dridex is known to use Atom Bombing, but other threats may leverage it as well.Fusion adware detected (35) Fusion (or FusionPlayer) is an adware family that displays unwanted advertising in the form of popups or by injecting into browsers and altering advertisements on webpages. Adware is known to sometimes download and install malware.Installcore adware detected (32) Install core is an installer which bundles legitimate applications with offers for additional third-party applications that may be unwanted. The unwanted applications are often adware that display advertising in the form of popups or by injecting into browsers and adding or altering advertisements on webpages. Adware is known to sometimes download and install malware. […]

  • Vulnerability Spotlight: Multiple vulnerabilities in Schneider Electric Modicon M580
    by noreply@blogger.com (Jonathan Munshaw) on June 12, 2019 at 5:45 pm

    Jared Rittle of Cisco Talos discovered these vulnerabilities.Executive summaryThere are several vulnerabilities in the Schneider Electric Modicon M580 that could lead to a variety of conditions, including denial of service and the disclosure of sensitive information. The Modicon M580 is the latest in Schneider Electric’s Modicon line of programmable automation controllers. The majority of the bugs we will discuss exist in UMAS requests made while operating the hardware.In accordance with our coordinated disclosure policy, Cisco Talos worked with Schneider Electric to ensure that these issues are resolved and that an update is available for affected customers.Vulnerability detailsSchneider Electric Modicon M580 UMAS release reservation denial-of-service vulnerability (TALOS-2018-0735/CVE-2018-7846)An exploitable denial-of-service vulnerability exists in the UMAS Release PLC Reservation function of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to invalidate a session without verifying the authenticity of the sender, resulting in the disconnection of legitimate devices. An attacker can send unauthenticated commands to trigger this vulnerability.Exploitation of this vulnerability leverages a technique similar to that used by Eran Goldstein on other Modicon controllers in 2017, which can be found here.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS strategy transfer denial-of-service vulnerability (TALOS-2018-0737/CVE-2018-7849)An exploitable denial-of-service vulnerability exists in the UMAS strategy transfer functionality of the Schneider Electric Modicon M580 programmable automation controller firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a recoverable fault state, resulting in a stoppage of normal device execution. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS memory block read denial-of-service vulnerability (TALOS-2018-0738/CVE-2018-7843)An exploitable denial-of-service vulnerability exists in the UMAS memory block read function of the Schneider Electric Modicon M580 programmable automation controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS read memory block information disclosure vulnerability (TALOS-2018-0739/CVE-2018-7844)An exploitable information disclosure vulnerability exists in the UMAS read memory block function of the Schneider Electric Modicon M580 programmable automation controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to return blocks of memory, resulting in the disclosure of plaintext read, write and trap SNMP community strings. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS strategy read information disclosure vulnerability (TALOS-2018-0740/CVE-2018-7848)An exploitable information disclosure vulnerability exists in the UMAS strategy read functionality of the Schneider Electric Modicon M580 Programmable Automation Controller firmware version SV2.70. A specially crafted UMAS command can cause the device to return blocks of the programed strategy, resulting in the disclosure of plaintext read, write, and trap SNMP community strings. An attacker can send unauthenticated commands to trigger this vulnerability.Exploitation of this vulnerability leverages a technique similar to that used by Reid Wightman on the Modicon Quantum line of controllers in 2012, which can be found here.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS improper authentication vulnerability (TALOS-2018-0741/CVE-2018-7842)An exploitable improper authentication vulnerability exists in the UMAS PLC reservation function of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can allow an attacker to masquerade as an authenticated user, resulting in the ability to bypass password protections in place on the device. An attacker can send unauthenticated commands to trigger this vulnerability.Exploitation of this vulnerability leverages a technique similar to that used by Eran Goldstein on other Modicon controllers in 2017, which can be found here.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS strategy file write vulnerability (TALOS-2018-0742/CVE-2018-7847)An exploitable unauthenticated file write vulnerability exists in the UMAS strategy programming function of the Schneider Electric Modicon M580 programmable automation controller, firmware version SV2.70. A specially crafted sequence of UMAS commands can cause the device to overwrite its programmed strategy, resulting in a wide range of effects, including configuration modifications, disruption of the running process and potential code execution. An attacker can send unauthenticated commands to trigger this vulnerability.Exploitation of this vulnerability leverages a technique similar to that used by Reid Wightman on the Modicon Quantum line of controllers in 2012, which can be found here.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UnityPro reliance on untrusted inputs vulnerability (TALOS-2018-0743/CVE-2018-7850)An exploitable reliance on untrusted inputs vulnerability exists in the strategy transfer function of the Schneider Electric UnityProL Programming Software. When a specially crafted strategy is programmed to a Modicon M580 Programmable Automation Controller, and UnityProL is used to read that strategy, a configuration different from that on the device is displayed to the user. This results in the inability for users of UnityProL to verify that the device is acting as intended. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS read memory block out-of-bounds information disclosure vulnerability (TALOS-2018-0745/CVE-2018-7845)An exploitable information disclosure vulnerability exists in the UMAS memory block read functionality of the Schneider Electric Modicon M580 Programmable Automation Controller. A specially crafted UMAS request can cause an out-of-bounds read, resulting in the disclosure of sensitive information. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS function code 0x6d multiple denial-of-service vulnerabilities (TALOS-2019-0763/CVE-2018-7852)Multiple denial-of-service vulnerabilities exist in the UMAS protocol functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. Specially crafted UMAS commands can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger these vulnerabilities.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS function code 0x28 denial-of-service vulnerability (TALOS-2019-0764/CVE-2018-7853)An exploitable denial-of-service vulnerability exists in the UMAS function code 0x28 functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS function code 0x65 denial-of-service vulnerability (TALOS-2019-0765/CVE-2018-7854)An exploitable denial-of-service vulnerability exists in the UMAS function code 0x65 functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS set breakpoint denial-of-service vulnerability (TALOS-2019-0766/CVE-2018-7855)An exploitable denial-of-service vulnerability exists in the UMAS set breakpoint functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS memory block write denial-of-service vulnerability (TALOS-2019-0767/CVE-2018-7856)An exploitable denial-of-service vulnerability exists in the UMAS memory block write functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS write system coils and holding registers denial-of-service vulnerability (TALOS-2019-0768/CVE-2018-7857)An exploitable denial-of-service vulnerability exists in the UMAS write system coils and holding registers functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS read system blocks and bits information disclosure vulnerability (TALOS-2019-0769/CVE-2019-6806)An exploitable information disclosure vulnerability exists in the UMAS Read System Blocks and Bits functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted UMAS command can cause the device to return blocks of memory, resulting in the disclosure of plaintext read, write, and trap SNMP community strings. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric Modicon M580 UMAS write system bits and blocks denial-of-service vulnerability (TALOS-2019-0770/CVE-2019-6807)An exploitable denial-of-service vulnerability exists in the UMAS write system bits and blocks functionality of the Schneider Electric Modicon M580 Programmable Automation Controller, firmware version SV2.70. A specially crafted set of UMAS commands can cause the device to enter a non-recoverable fault state, resulting in a complete stoppage of remote communications with the device. An attacker can send unauthenticated commands to trigger this vulnerability.For more information on this vulnerability, read the complete advisory here.Schneider Electric UnityPro PLC simulator remote code execution vulnerability (TALOS-2019-0771/CVE-2019-6808)An exploitable remote code execution vulnerability exists in the UMAS strategy programming functionality of the Schneider Electric Unity Pro L Programming Software PLC Simulator. A specially crafted sequence of UMAS commands sent to the software’s PLC simulator can cause a modified strategy to be programmed, resulting in code execution when the simulator is switched into the start mode. An attacker can send unauthenticated commands to trigger this vulnerability.Exploitation of this vulnerability leverages a technique similar to that used by Mille Gandelsman and Avihay Kain on Unity Pro in 2016, which can be found here and here.For more information on this vulnerability, read the complete advisory here.Versions testedTalos tested and confirmed that that the Schneider Electric Modicon M580, BMEP582040 SV2.70 is affected by these vulnerabilities.CoverageThe following SNORTⓇ rules will detect exploitation attempts. Note that additional rules may be released at a future date and current rules are subject to change pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.Snort Rules: 48521 – 48528 […]

  • Microsoft Patch Tuesday — June 2019: Vulnerability disclosures and Snort coverage
    by noreply@blogger.com (Jonathan Munshaw) on June 11, 2019 at 6:42 pm

    Microsoft released its monthly security update today, disclosing a variety of vulnerabilities in several of its products. The latest Patch Tuesday covers 88 vulnerabilities, 18 of which are rated “critical,” 69 that are considered “important” and one “moderate.” This release also includes a critical advisory regarding security updates to Adobe Flash Player.This month’s security update covers security issues in a variety of Microsoft’s products, including the Chakra scripting engine, the Jet database engine and Windows kernel. For more on our coverage of these bugs, check out the Snort blog post here, covering all of the new rules we have for this release.Critical vulnerabilitiesMicrosoft disclosed 19 critical vulnerabilities this month, 10 of which we will highlight below.CVE-2019-0988, CVE-2019-0989, CVE-2019-0991, CVE-2019-0992, CVE-2019-0993, CVE-2019-1002, CVE-2019-1003 and CVE-2019-1024 are all memory corruption vulnerabilities in the Chakra scripting engine. An attacker could exploit any of these bugs by tricking a user into visiting a specially crafted, malicious website while using the Microsoft Edge browser. If successful, the attacker could then corrupt memory in such a way that would allow them to take control of an affected system.CVE-2019-0620 is a remote code execution vulnerability in Windows Hyper-V that exists when Hyper-V fails to properly validate input on a host server from an authenticated user using a guest operating system. An attacker could exploit this bug by running a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code.CVE-2019-0888 is a remote code execution vulnerability that exists in the way ActiveX Data Obejcts handles object in memory. An attacker could exploit this vulnerability by tricking the user into visiting a specially crafted, malicious website. If successful, the attacker could then execute code in the context of the current user.The other critical vulnerabilities are:CVE-2019-0709CVE-2019-0722CVE-2019-0985CVE-2019-0990CVE-2019-1038CVE-2019-1051CVE-2019-1052CVE-2019-1055Important vulnerabilitiesThis release also contains 65 important vulnerabilities, one of which we will highlight below.CVE-2019-1065 is an elevation of privilege vulnerability that occurs when the Windows kernel improperly handles objects in memory. An attacker would first have to log onto the system in order to exploit this vulnerability, and then run a specially crafted application to take control of the system. They would then have the ability to run arbitrary code in kernel mode.The other important vulnerabilities are:CVE-2019-0710CVE-2019-0711CVE-2019-0713CVE-2019-0904CVE-2019-0905CVE-2019-0906CVE-2019-0907CVE-2019-0908CVE-2019-0909CVE-2019-0941CVE-2019-0943CVE-2019-0959CVE-2019-0960CVE-2019-0968CVE-2019-0972CVE-2019-0973CVE-2019-0974CVE-2019-0977CVE-2019-0983CVE-2019-0984CVE-2019-0986CVE-2019-0998CVE-2019-1005CVE-2019-1007CVE-2019-1009CVE-2019-1010CVE-2019-1011CVE-2019-1012CVE-2019-1013CVE-2019-1014CVE-2019-1015CVE-2019-1016CVE-2019-1017CVE-2019-1018CVE-2019-1019CVE-2019-1021CVE-2019-1022CVE-2019-1023CVE-2019-1025CVE-2019-1026CVE-2019-1027CVE-2019-1028CVE-2019-1029CVE-2019-1031CVE-2019-1032CVE-2019-1033CVE-2019-1034CVE-2019-1035CVE-2019-1036CVE-2019-1039CVE-2019-1040CVE-2019-1041CVE-2019-1043CVE-2019-1044CVE-2019-1045CVE-2019-1046CVE-2019-1047CVE-2019-1048CVE-2019-1049CVE-2019-1050CVE-2019-1053CVE-2019-1054CVE-2019-1064CVE-2019-1069Moderate vulnerabilityThere is one moderate vulnerability, CVE-2019-0948, which is an information disclosure vulnerability in Windows Event Manager.Coverage In response to these vulnerability disclosures, Talos is releasing the following SNORTⓇ rules that detect attempts to exploit them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Firepower customers should use the latest update to their ruleset by updating their SRU. Open Source Snort Subscriber Rule Set customers can stay up-to-date by downloading the latest rule pack available for purchase on Snort.org.Snort rules: 44813-44814, 48051-48052, 49762-49765, 50162-50163, 50183-50184, 50198-50199, 50357-50376, 50393-50408, 50411-50414 […]

  • How Cisco Talos helped Howard County recover from a call center attack
    by noreply@blogger.com (Jonathan Munshaw) on June 10, 2019 at 8:59 pm

    On Aug. 11, 2018 the 911 non-emergency call center in Howard County, Maryland was in crisis — not for the types of calls flooding into dispatchers, but simply for the sheer numbers. The center, which usually receives 300 to 400 calls a day was now getting 2,500 in a 24-hour span of time. The center, which takes calls for everything from home security alarms going off to cats getting stuck in trees was overwhelmed. What was going on?James Cox, a network-server team manager for the Howard County government was tasked with answering that question. It turns out, a lone foreign actor created this crisis. “The phone system doesn’t care who you are,” Cox explained. “You hit that 10-digit number and the phone rings. There’s no check and there’s no balance.”At this point, Howard County called on Cisco Talos for assistance. Cox talked about the lessons he learned from this during the second annual Talos Threat Research Summit, a sold-out one-day conference for security professionals who are also attending Cisco Live.Read the complete story over at the Cisco Newsroom here. […]

  • Using Firepower to defend against encrypted RDP attacks like BlueKeep
    by noreply@blogger.com (Nick Biasini) on June 10, 2019 at 4:37 pm

    This blog was authored by Brandon StultzMicrosoft recently released fixes for a critical pre-authentication remote code execution vulnerability in Remote Desktop Protocol Services (RDP). Identified as CVE-2019-0708 in May’s Patch Tuesday, the vulnerability caught the attention of researchers and the media due to the fact that it was “wormable,” meaning an attack exploiting this vulnerability could easily spread from one machine to another. This was discussed at length in episode 54 of our ‘Beers with Talos’ podcast.Cisco Talos started reverse-engineering work immediately to determine how exactly RDP was vulnerable. Talos wrote and released coverage as soon as we were able to determine the vulnerability condition. SID 50137 for SNORT® correctly blocks exploitation of CVE-2019-0708 and scanning attempts that leverage this vulnerability.This rule prevents exploitation of CVE-2019-0708 by blocking any RDP connection that attempts to use the “MS_T120” virtual channel. The RDP protocol defines virtual channels that can be used to transfer different kinds of data (e.g. clipboard, audio, etc.). In addition to these client-specified channels, Microsoft creates the “MS_T120” channel in the Windows RDP system. Clients are not expected to create the “MS_T120” channel. A remote unauthenticated attacker can exploit CVE-2019-0708 by sending crafted data to this internal channel.Since RDP servers are not aware of which virtual channels the client supports, the client provides a list of desired channels in the connect-initial packet at the start of the RDP session.Client –> Connection Request –> ServerClient <– Connection Confirm <– Server– Optionally switch transport to TLS –Client –> MCS connect-initial –> ServerClient <– MCS connect-response <– ServerIt is possible to specify in the RDP connection request that the client is TLS capable. In most cases, this causes the server to switch the connection to TLS after the Connection Confirm packet. This means that Cisco Firepower will only scan the virtual channel list in the encrypted case if TLS decryption is set up for RDP.While the aforementioned Snort rule can help protect against BlueKeep, it is still possible for attackers to carry out an encrypted attack — essentially sneaking past users and remaining undetected. Unless users set up TLS decryption for RDP on their Firepower device, there is a chance an attacker could exploit CVE-2019-0708 to deliver malware that would have the potential to spread rapidly.The following is a guide to set up RDP decryption on Cisco Firepower. This guide specifically applies to Windows Server 2008 instances (newer versions of Windows Server are not vulnerable to BlueKeep). Additionally, Windows 7 only allows setting up a custom RDP certificate in the registry. It is possible to export the self-signed RDP certificate and private key in Windows 7 but this requires using the mimikatz tool as the private key for the auto-generated certificate is marked as “not exportable”. Considering these hurdles, we focused on Windows Server 2008 for this guide.*Note this procedure requires an inline Firepower device that supports SSL decryption. For more information, visit: Cisco Next-Generation Intrusion Prevention System (NGIPS) – Cisco.Steps for RDP Decryption1. Determine the certificate used by the RDP serverIn Windows Server 2008, TLS certificates for RDP are configured in “Remote Desktop Session Host Configuration.”Once the remote desktop host configuration is opened, double-click on any RDP connections and note the certificate used by the RDP server — we will need this later.2. Export the RDP certificate and private keyOpen mmc.exe and navigate to: File -> Add/Remove Snap-inSelect “Certificates” on the left and click “Add.”Click “Computer account,” “Next,” then “Finish.”Finally, click “OK” to add the certificates snap-in.Navigate on the left to the Local Computer certificates and locate, on the right, the certificate used by the RDP server we found before in the Remote Desktop Session Host Configuration.Right click on the certificate and in “All Tasks” click on “Export.”Click “Yes, export the private key” in the Certificate Export Wizard then click “Next.”Make sure “Personal Information Exchange” is selected, then click “Next.”Type in an import password to encrypt the PFX file. Remember this password — we will need it later. Click “Next.”Type in a file name for the PFX file and click “Next.”Finally, click “Finish.”You have successfully exported the RDP certificate and private key.Now, prepare them for the Firepower appliance.3. Prepare the RDP certificate and private key for FirepowerFor this step, you will need the OpenSSL tool and the PFX file exported in Step 2(dc1.pfx in this example).Extract the RDP certificate from the PFX file:$ openssl pkcs12 -in dc1.pfx -clcerts -nokeys -out cert.pemEnter Import Password:The command above will ask for the import password, this is the password we typed in Step 2.Extract the RDP private key from the PFX file:$ openssl pkcs12 -in dc1.pfx -nocerts -out key.pemEnter Import Password:Enter PEM pass phrase:Verifying – Enter PEM pass phrase:The above command will ask for the import password again, as well as a PEM password. Remember this private key passphrase, — we will need it when we add the RDP certificate to Firepower.4. Import the RDP key into FirepowerAt this point, you should have the RDP cert “cert.pem,” as well as the encrypted RDP private key “key.pem.”Navigate to Objects -> Object Management.Select “Add Internal Cert” on the top right.Name the certificate (e.g. the server name) and either paste in the “cert.pem” or browse to the “cert.pem” file in the “Certificate Data” section. Do the same for “key.pem” in the “Key” section. Click the “Encrypted” box and type in the PEM password from Step 3.You have successfully imported the RDP certificate and private key. Now, create an SSL policy for decryption.5. Create an SSL policyNavigate to Policies -> SSLSelect “New Policy.”Enter a policy name and description with default action “Do not decrypt.”Once the policy editor has loaded, select “Add Rule” (top right).Name the rule and give it the action “Decrypt – Known Key.” Click the “with” field and select the certificate you imported earlier in Step 4.If applicable, select “Source” and “Destination” networks or leave them as “any.”Click on the “Ports” tab and input the TCP port 3389 (if appropriate for your environment) under “Selected Destination Ports” and click “Add.”Under the “Logging” tab, enable logging at the end of the connection if desired.Click “Add” and then “Save” to save the rule.Additional SSL documentation is available here. 6. Enable the Intrusion Prevention Rule for BlueKeepNavigate to Policies -> Access Control -> Intrusion Prevention.Edit the desired Intrusion Policy.Filter for Snort ID 50137 “OS-WINDOWS Microsoft Windows RDP MS_T120 channel bind attempt.”Click the checkbox and select Rule State -> Drop and Generate Events.Click “Policy Information” and commit changes.7. Configure the Access Control PolicyNavigate to Policies -> Access Control and edit the relevant Access Control Policy.Under the “Advanced” tab, edit “SSL Policy Settings.”Select the SSL Policy we created in Step 5 and click “OK.”Ensure that your Intrusion Prevention Policy is selected under “Intrusion Policy used before Access Control rule is determined” in the “Network Analysis and Intrusion Policies” section of the “Advanced” tab.Under the “Rules” tab of your Access Control Policy, ensure you have an appropriate Intrusion Policy set for any “Allow” rules.If appropriate, enable the Intrusion Prevention Policy for your Default Action, as well.Save and deploy changes.Verify RDP connectivity and functionality.Encrypted Exploit in ActionLet’s start this by walking through what happens when the exploit is attempted on an unpatched, unprotected Windows 7 system.As you can see, when the exploit is launched, it results in a denial of service on the system, as expected. Now we will demonstrate the process once you have enabled the SSL decryption for RDP, described in this blog, and leverage the detection capabilities of Firepower.In this instance, no denial of service occurs and the system is unaffected, despite the attack being encrypted. Below is a screen capture showing SID 50137 alerting and dropping the encrypted BlueKeep exploit in Firepower.ConclusionOver the last several years we have seen several high profile vulnerabilities affecting services associated with various Windows services. Some, if not all, of these services should not be exposed to the internet. To reduce external exposure organizations need to take additional steps to ensure that services like RDP and SMB are not exposed unless explicitly required, but does not eliminate the need for patching. This is yet another example of why patching is one of the core fundamental concepts in information security. Vulnerabilities this severe appear periodically, and organizations need to be prepared to respond in a variety of different ways. Patching takes time and making sure that you have detection and prevention in place can require varying levels of difficulty. In this particular example, in order to get a higher level of visibility, SSL decryption is required for more thorough protections. As encryption becomes more ingrained in the internet and more applications take advantage of it, these types of steps are going to become more common. Adversaries are always going to look for ways to evade any type of detection and using encryption is a great way to evade some of these technologies. Regardless, Cisco Talos will always be looking at the ways adversaries are operating and developing new and clever techniques to defeat them. […]

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 https://isc.sans.edu/contact.html .

  • ISC StormCast for Friday, June 14th 2019
    by Johannes B. Ullrich, Ph.D. on June 14, 2019 at 1:10 am

    Exim Flaw Exploited https://www.cybereason.com/blog/new-pervasive-worm-exploiting-linux-exim-server-vulnerabilityYubico Recalling FIPS Certified Yubikeys https://www.yubico.com/support/security-advisories/ysa-2019-02/Vulnerable Infusion Pumps https://www.bd.com/en-us/support/product-security-and-privacy/product-security-bulletins/alaris-gateway-workstation-unauthorized-firmwareTelegram DDoS Attack https://twitter.com/telegram/status/1138768124914929664Ghidra Tips for IDA Users: Function Call Graphs https://isc.sans.edu/forums/diary/A+few+Ghidra+tips+for+IDA+users+part+4+function+call+graphs/25032/Joel Chapman: Security Consideration for Voice over Wifi (VoWifi) Systems https://www.sans.org/reading-room/whitepapers/telephone/paper/38945 […]

  • ISC StormCast for Thursday, June 13th 2019
    by Johannes B. Ullrich, Ph.D. on June 13, 2019 at 1:05 am

    Sandbox Escaper Publishes Additional CVE-2019-0841 Bypass http://archive.is/3toQY http://sandboxescaper.blogspot.com/p/disclosures_8.htmlBypassing NTLM Message Signing (CVE-2019-1040) https://blog.preempt.com/drop-the-micDetails About macOS Keysteal Vulnerability https://www.pinauten.de/resources/KeySteal_OBTS_2019.pdf […]

  • ISC StormCast for Wednesday, June 12th 2019
    by Johannes B. Ullrich, Ph.D. on June 12, 2019 at 1:45 am

    Microsoft Patches https://isc.sans.edu/forums/diary/MSFT+June+2019+Patch+Tuesday/25024/Adobe Patches https://helpx.adobe.com/security.htmlSAP Security Notes https://www.onapsis.com/blog/sap-patch-notes-june-2019Intel Updates https://www.us-cert.gov/ncas/current-activity/2019/06/11/Intel-Releases-Security-Updates-Mitigations-Multiple-ProductsMicrosoft Certificate DoS https://bugs.chromium.org/p/project-zero/issues/detail?id=1804GPS Receiver Woes https://www.flightglobal.com/news/articles/collins-gps-outage-grounds-regional-flights-458819/RAMBleed Attack https://www.documentcloud.org/documents/6150180-RamBleed-attack-CVE-2019-0174.htm […]

  • ISC StormCast for Tuesday, June 11th 2019
    by Johannes B. Ullrich, Ph.D. on June 11, 2019 at 1:20 am

    Interesting JavaScript Obfuscation Example https://isc.sans.edu/forums/diary/Interesting+JavaScript+Obfuscation+Example/25020/Spam Taking Advantage of DNS over HTTPS https://myonlinesecurity.co.uk/it-looks-like-another-dns-compromise-hack-happening/European Mobile Operator Traffic Leaked to China https://arstechnica.com/information-technology/2019/06/bgp-mishap-sends-european-mobile-traffic-through-china-telecom-for-2-hours/?comments=1VLC Update Patches Various Security Flaws http://www.jbkempf.com/blog/post/2019/VLC-3.0.7-and-security […]

  • ISC StormCast for Monday, June 10th 2019
    by Johannes B. Ullrich, Ph.D. on June 10, 2019 at 2:35 am

    Keep An Eye On Your WMI Logs https://isc.sans.edu/forums/diary/Keep+an+Eye+on+Your+WMI+Logs/25012/Sysmon DNS Query Logging https://isc.sans.edu/forums/diary/Tip+Sysmon+Will+Log+DNS+Queries/25016/Komodo Agama Vulnerability and Breach https://komodoplatform.com/update-agama-vulnerability/Lessons Learned From Microsoft SOC https://www.microsoft.com/security/blog/2019/06/06/lessons-learned-from-the-microsoft-soc-part-2b-career-paths-and-readiness/ […]

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

McAfee Labs – McAfee Blogs Securing Tomorrow. Today.

  • Mr. Coffee with WeMo: Double Roast
    by Sam Quinn on May 30, 2019 at 4:50 pm

    McAfee Advanced Threat Research recently released a blog detailing a vulnerability in the Mr. Coffee Coffee Maker with WeMo. Please refer to the earlier blog to catch up with the processes and techniques I used to investigate and ultimately compromise this smart coffee maker. While researching the device, there was always one attack vector that […] The post Mr. Coffee with WeMo: Double Roast appeared first on McAfee Blogs. […]

  • Cryptocurrency Laundering Service, BestMixer.io, Taken Down by Law Enforcement
    by John Fokker on May 22, 2019 at 2:57 pm

    A much overlooked but essential part in financially motivated (cyber)crime is making sure that the origins of criminal funds are obfuscated or made to appear legitimate, a process known as money laundering. ’Cleaning’ money in this way allows the criminal to spend their loot with less chance of being caught. In the physical world, for […] The post Cryptocurrency Laundering Service, BestMixer.io, Taken Down by Law Enforcement appeared first on McAfee Blogs. […]

  • RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708
    by Eoin Carroll on May 21, 2019 at 9:09 pm

    During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the […] The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs. […]

  • LockerGoga Ransomware Family Used in Targeted Attacks
    by Marc Rivero Lopez on April 29, 2019 at 5:10 pm

    Initial discovery Once again, we have seen a significant new ransomware family in the news. LockerGoga, which adds new features to the tried and true formula of encrypting victims’ files and asking for payment to decrypt them, has gained notoriety for the targets it has affected. In this blog, we will look at the findings […] The post LockerGoga Ransomware Family Used in Targeted Attacks appeared first on McAfee Blogs. […]

  • IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target?
    by Steve Povolny on April 18, 2019 at 8:14 pm

    Effective malware is typically developed with intention, targeting specific victims using either known or unknown vulnerabilities to achieve its primary functions. In this blog, we will explore a vulnerability submitted by McAfee Advanced Threat Research (ATR) and investigate a piece of malware that recently incorporated similar vulnerabilities. The takeaway from this blog is the increasing […] The post IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? appeared first on McAfee Blogs. […]

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

  • Mirai malware family variants rack up exploit totals
    by Bradley Barth on June 15, 2019 at 6:19 pm

    A newly discovered variant of Echobot, an offshoot of the Mirai family of Internet of Things botnet malware, was found to contain a whopping 26 different exploits for infecting victim machines. This revelation is the latest in a string of research reports detailing Mirai-related malwares with increasingly large exploit totals. In a company blog post… The post Mirai malware family variants rack up exploit totals appeared first on SC Media. […]

  • AESDDoS botnet malware target Docker containers
    by Robert Abel on June 14, 2019 at 7:09 pm

    A newly discovered botnet malware exploits an API misconfiguration in the open-source version of the DevOps tool, Docker Engine-Community, to infiltrate containers and run a variant of the Linux botnet malware AESDDoS, according to a Trend Micro blog post. “Docker APIs that run on container hosts allow the hosts to receive all container-related commands that… The post AESDDoS botnet malware target Docker containers appeared first on SC Media. […]

  • Flaw in Alaris medical devices exposes infusion pumps to possible sabotage
    by Bradley Barth on June 14, 2019 at 6:52 pm

    Medical tech company Becton, Dickinson and Company (BD) has advised users of its Alaris Gateway Workstation – a smart connectivity and integration solution for infusion pump devices – to update their firmware, following the discovery of a highly critical remote code execution vulnerability. CyberMDX researcher Elad Luz found that multiple versions of the workstation –… The post Flaw in Alaris medical devices exposes infusion pumps to possible sabotage appeared first on SC Media. […]

  • Exim vulnerability being exploited in the wild
    by Doug Olenick on June 14, 2019 at 6:44 pm

    Just one week after a previously patched vulnerability in Exim mail servers was disclosed by Qualys, attackers have begun searching out vulnerable Exim systems prompting the Cybersecurity and Infrastructure Security Agency (CISA) to encourage users to update their systems to the latest version. CISA reported the vulnerability CVE-2019-10149 was detected in exploits in the wild… The post Exim vulnerability being exploited in the wild appeared first on SC Media. […]

  • ACLU warns security cameras could lead to surveillance
    by Robert Abel on June 14, 2019 at 6:39 pm

    Millions of security cameras become equipped with “video analytics” and other AI-infused technologies that allow computers not only record but “understand” the objects they’re capturing, they could be used for both security and marketing purposes, the American Civil Liberties Union (ACLU) warned in a recent report ,“The Dawn of Robot Surveillance.” As they become more… The post ACLU warns security cameras could lead to surveillance appeared first on SC Media. […]

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

  • Improving Security and Privacy for Extensions Users
    by Eugene Liderman on June 12, 2019 at 5:02 pm

    No, Chrome isn’t killing ad blockers — we’re making them saferPosted by Devlin Cronin, Chrome Extensions TeamThe Chrome Extensions ecosystem has seen incredible advancement, adoption, and growth since its launch over ten years ago. Extensions are a great way for users to customize their experience in Chrome and on the web. As this system grows and expands in both reach and power, user safety and protection remains a core focus of the Chromium project. In October, we announced a number of changes to improve the security, privacy, and performance of Chrome extensions. These changes include increased user options to control extension permissions, changes to the review process and readability requirements, and requiring two-step verification for developers. In addition, we’ve helped curb abuse through restricting inline installation on websites, preventing the use of deceptive installation practices, and limiting the data collected by extensions. We’ve also made changes to the teams themselves — over the last year, we’ve increased the size of the engineering teams that work on extension abuse by over 300% and the number of reviewers by over 400%. These and other changes have driven down the rate of malicious installations by 89% since early 2018. Today, we block approximately 1,800 malicious uploads a month, preventing them from ever reaching the store. While the Chrome team is proud of these improvements, the review process alone can’t catch all abuse. In order to provide better protection to our users, we need to make changes to the platform as well. This is the suite of changes we’re calling Manifest V3. This effort is motivated by a desire to keep users safe and to give them more visibility and control over the data they’re sharing with extensions. One way we are doing this is by helping users be deliberate in granting access to sensitive data – such as emails, photos, and access to social media accounts. As we make these changes we want to continue to support extensions in empowering users and enhancing their browsing experience. To help with this balance, we’re reimagining the way a number of powerful APIs work. Instead of a user granting each extension access to all of their sensitive data, we are creating ways for developers to request access to only the data they need to accomplish the same functionality. One example of this is the introduction of the Declarative Net Request API, which is replacing parts of the Web Request API. At a high level, this change means that an extension does not need access to all a user’s sensitive data in order to block content. With the current Web Request API, users grant permission for Chrome to pass all information about a network request – which can include things like emails, photos, or other private information – to the extension. In contrast, the Declarative Net Request API allows extensions to block content without requiring the user to grant access to any sensitive information. Additionally, because we are able to cut substantial overhead in the browser, the Declarative Net Request API can have significant, system-level performance benefits over Web Request. This has been a controversial change since the Web Request API is used by many popular extensions, including ad blockers. We are not preventing the development of ad blockers or stopping users from blocking ads. Instead, we want to help developers, including content blockers, write extensions in a way that protects users’ privacy. You can read more about the Declarative Net Request API and how it compares to the Web Request API here. We understand that these changes will require developers to update the way in which their extensions operate. However, we think it is the right choice to enable users to limit the sensitive data they share with third-parties while giving them the ability to curate their own browsing experience. We are continuing to iterate on many aspects of the Manifest V3 design, and are working with the developer community to find solutions that both solve the use cases extensions have today and keep our users safe and in control. […]

  • Use your Android phone’s built-in security key to verify sign-in on iOS devices
    by Eugene Liderman on June 12, 2019 at 4:00 pm

    Posted by Kaiyu Yan and Christiaan Brand Compromised credentials are one of the most common causes of security breaches. While Google automatically blocks the majority of unauthorized sign-in attempts, adding 2-Step Verification (2SV) considerably improves account security. At Cloud Next ‘19, we introduced a new 2SV method, enabling more than a billion users worldwide to better protect their accounts with a security key built into their Android phones. This technology can be used to verify your sign-in to Google and Google Cloud services on Bluetooth-enabled Chrome OS, macOS, and Windows 10 devices. Starting today, you can use your Android phone to verify your sign-in on Apple iPads and iPhones as well. Security keysFIDO security keys provide the strongest protection against automated bots, bulk phishing, and targeted attacks by leveraging public key cryptography to verify your identity and URL of the login page, so that an attacker can’t access your account even if you are tricked into providing your username and password. Learn more by watching our presentation from Cloud Next ‘19. On Chrome OS, macOS, and Windows 10 devices, we leverage the Chrome browser to communicate with your Android phone’s built-in security key over Bluetooth using FIDO’s CTAP2 protocol. On iOS devices, Google’s Smart Lock app is leveraged in place of the browser. User experience on an iPad with Pixel 3Until now, there were limited options for using FIDO2 security keys on iOS devices. Now, you can get the strongest 2SV method with the convenience of an Android phone that’s always in your pocket at no additional cost. It’s easy to get startedFollow these simple steps to protect your Google Account today: Step 1: Add the security key to your Google Account Add your personal or work Google Account to your Android 7.0+ (Nougat) phone. Make sure you’re enrolled in 2-Step Verification (2SV). On your computer, visit the 2SV settings and click “Add security key”. Choose your Android phone from the list of available devices. Step 2: Use your Android phone’s built-in security key On both of your devices, make sure Bluetooth is turned on. On your iPhone or iPad (iOS version 10.0 or up), sign in to your Google Account with your username and password using the Google Smart Lock app. Check your Android phone for a notification. Follow the instructions to confirm it’s you signing in. You can find more detailed instructions here. Within enterprise organizations, admins can require the use of security keys for their users in G Suite and Google Cloud Platform (GCP), letting them choose between using a physical security key, an Android phone, or both. We also recommend that you register a backup hardware security key (from Google or a number of other vendors) for your account and keep it in a safe place, so that you can gain access to your account if you lose your Android phone. […]

  • PHA Family Highlights: Triada
    by Eugene Liderman on June 6, 2019 at 5:14 pm

    Posted by Lukasz Siewierski, Android Security & Privacy Team We continue our PHA family highlights series with the Triada family, which was first discovered early in 2016. The main purpose of Triada apps was to install spam apps on a device that displays ads. The creators of Triada collected revenue from the ads displayed by the spam apps. The methods Triada used were complex and unusual for these types of apps. Triada apps started as rooting trojans, but as Google Play Protect strengthened defenses against rooting exploits, Triada apps were forced to adapt, progressing to a system image backdoor. However, thanks to OEM cooperation and our outreach efforts, OEMs prepared system images with security updates that removed the Triada infection. History of TriadaTriada was first described in a blog post on the Kaspersky Lab website in March 2016 and in a follow-up blog post in June 2016. Back then, it was a rooting trojan that tried to exploit the device and after getting elevated privileges, it performed a host of different actions. To hide these actions from analysts, Triada used a combination of dynamic code loading and additional app installs. The Kaspersky posts detail the code injection technique used by Triada and provide some statistics on infected devices at the time. In this post, we’ll focus on the peculiar encryption routine and the unusual binary files used by Triada. Triada’s first action was to install a type of superuser (su) binary file. This su binary allowed other apps on the device to use root permissions. The su binary used by Triada required a password, so was unique compared to regular su binary files common with other Linux systems. The binary accepted two passwords, od2gf04pd9 and ac32dorbdq. This is illustrated in the IDA screenshot below. Depending on which one was provided, the binary either 1) ran the command given as an argument as root or 2) concatenated all of the arguments, ran that concatenation preceded by sh, then ran them as root. Either way, the app had to know the correct password to run the command as root. This Triada rooting trojan was mainly used to install apps and display ads. This trojan targeted older devices because the rooting exploits didn’t work on newer ones. Therefore, the trojan implemented a weight watching feature to decide if old apps needed to be deleted to make space for new installs. Weight watching included several steps and attempted to free up space on the device’s user partition and system partition. Using a blacklist and whitelist of apps it first removed all the apps on its blacklist. If more free space was required it would remove all other apps leaving only the apps on the whitelist. This process freed space while ensuring the apps needed for the phone to function properly were not removed. Every app on the system partition had a number, or weight, associated with it. The weight was a sum of the number of apps installed on the same date as the app in question and the number of apps signed with the same certificate. The apps with the lowest weight were installed in isolation (that is, not on a day that the device system image was created) and weren’t signed by the OEM or weren’t part of a developer bundle. In the weight watching process, these apps were removed first, until enough space was made for the new app. su binary accepts two passwordsIn addition to installing apps that display ads, Triada injected code into four web browsers: AOSP (com.android.browser), 360 Secure (com.qihoo.browser), Cheetah (com.ijinshan.browser_fast), and Oupeng (com.oupeng.browser). The code was injected using the same technique described in our blog post about the Zen PHA family and in previously mentioned Kaspersky blog posts. The web browser injection was done to overwrite the URLs and substitute ad banners on websites with ads benefiting the Triada authors. Triada also used a peculiar and complex communication encryption routine. Whenever it had to send a request to the Command and Control (C&C) server, it encrypted the request using two XOR loops with different passwords. Because of XOR rules, if the passwords had the same character in the same position, those characters weren’t encrypted. The encrypted request was saved to a file, which had the same name as its size. Finally, the file was zipped and sent to the C&C server in the POST request body. The example below illustrates one such request. The yellow bytes are the zip file’s signature of the central directory file header. The red bytes show the uncompressed file size of 0x0952. The blue bytes show the file name length (4) and the name itself (2386, a decimal version of 0x0952). 09 00 00 50 4B 01 02 14 00 14 00 08 00 08 00 4F …PK……….O91 F3 48 AE CF 91 D5 B1 04 00 00 52 09 00 00 04 ..H……..R….00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….00 32 33 38 36 50 4B 05 06 00 00 00 00 01 00 01 .2386PK………00 32 00 00 00 E3 04 00 00 00 00 .2………The underlying data protocol changed periodically. It was either a simple JSON, a list of key-value pairs similar to the properties file, or a proprietary format as shown below. [collect_Head]device=Nexus 5X[collect_Space]xadevicekey=xxxxx…[collect_Space]collentmod=opappresultmode[collect_Space]registerUser=true[collect_End]When Triada was discovered, we implemented detection that removed Triada samples from all devices with Google Play Protect. This implementation, combined with the increased security on newer Android devices, made it significantly harder for Triada to infect devices. When rooting doesn’t work…During the summer of 2017 we noticed a change in new Triada samples. Instead of rooting the device to obtain elevating privileges, Triada evolved to become a pre-installed Android framework backdoor. The changes to Triada included an additional call in the Android framework log function, demonstrated below with a highlighted configuration string. LABEL+13: V18 = -1;LABEL_18: j___config_log_println(v7, v6, v10, v11, “cf89450001”); if ( v10 )This backdoored log function version of Triada was first described by Dr.Web in July 2017. The blog post includes a description of Triada code injection methods. By backdooring the log function, the additional code executes every time the log method is called (that is, every time any app on the phone tries to log something). These log attempts happen many times per second, so the additional code is running non-stop. The additional code also executes in the context of the app logging a message, so Triada can execute code in any app context. The code injection framework in early versions of Triada worked on Android releases prior to Marshmallow. The main purpose of the backdoor function was to execute code in another app’s context. The backdoor attempts to execute additional code every time the app needs to log something. Triada developers created a new file format, which we called MMD, based on the file header. The MMD format was an encrypted version of a DEX file, which was then executed in the app context. The encryption algorithm was a double XOR loop with two different passwords. The format is illustrated below. Each MMD file had a specific file name of the format <MD5 of the process name>36.jmd. By using the MD5 of the process name, the Triada authors tried to obscure the injection target. However, the pool of all available process names is fairly small, so this hash was easily reversible. We identified two code injection targets: com.android.systemui (the System UI app) and com.android.vending (the Google Play app). The first target was injected to get the GET_REAL_TASKS permission. This is a signature-level permission, which means that it can’t be held by ordinary Android apps. Starting with Android Lollipop, the getRecentTasks() method is deprecated to protect users’ privacy. However, apps holding the GET_REAL_TASKS permission can get the result of this method call. To hold the GET_REAL_TASKS permission, an app has to be signed with a specific certificate, the device’s platform cert, which is held by the OEM. Triada didn’t have access to this cert. Instead it executed additional code in the System UI app, which has the GET_REAL_TASKS permission. The injected code returned the app running on top (the activity running in the foreground and being actively used by the device user) to other apps on the device. This app was exposed using two methods: an intent or a socket created for this purpose. When an app on the device sent the intent or wrote to a socket created by Triada’s code injection, it received the package name of the app running on top. Triada used the package name to determine if an ad was displayed. The assumption was that if the app running on top was a browser, the user would expect to see some ads, so Triada displayed ads from the background. The second injection target was the Google Play app. This injection supported five commands and responses to them. The supported commands are shown below in Chinese, a language that was used throughout the Triada app and injection. English translations are given on the right. 下载请求 下载结果 安装请求 安装结果 激活请求 激活结果 拉活请求 拉活结果 卸载请求 卸载结果 download request download result install request installation result activation request activation result pull request pull the results uninstall request uninstall result The commands trigger the heartbeat (pull request), download, installation, uninstallation (in the Google Play app context), and activation (the first execution) of the apps. In the Google Play app context, installation meant that Triada didn’t have to turn on installation from unknown sources and all app installs looked like they were from Google Play. The apps were downloaded from the C&C server and the communication with the C&C was encrypted using the same custom encryption routine using double XOR and zip. The downloaded and installed apps used the package names of unpopular apps available on Google Play. They didn’t have any relation to the apps on Google Play apart from the same package name. The last piece of the puzzle was the way the backdoor in the log function communicated with the installed apps. This communication prompted the investigation: the change in Triada behavior mentioned at the beginning of this section made it appear that there was another component on the system image. The apps could communicate with the Triada backdoor by logging a line with a specific predefined tag and message. The reverse communication was more complicated. The backdoor used Java properties to relay a message to the app. These properties were key-value pairs similar to Android system properties, but they were scoped to a specific process. Setting one of these properties in one app context ensures that other apps won’t see this property. Despite that, some versions of Triada indiscriminately created the properties in every single app process. The diagram below illustrates the communication mechanisms of the Triada backdoor. Communication mechanisms of TriadaReverse engineering countermeasures and developmentThe Triada backdoor was hidden to make the analysis harder. The strings in the Android framework library that related to Triada activities were encrypted, as shown below. Android framework stringsThe strings were encrypted using the algorithm of two XOR loops. However, the first highlighted string, 36.jmd, wasn’t encrypted. This is the MMD file name string mentioned before. Another anti-analysis measure implemented by the Triada authors was function padding, including additional exported functions that don’t serve any purpose apart from making the file size bigger and the function layout more random with every compilation. Four types of these functions are shown in the screenshots below. Example of function paddingOne final interesting feature of Triada worth mentioning is the development cycle. By analyzing subsequent versions of the Triada backdoor (up to 1.5.1) we saw the changes in the code. In the newest version, they substituted MD5 with SHA1. This is used to hash the filenames, which come from a restricted pool of values. The newest version also encrypted the 36.jmd string and introduced changes to the code for compatibility with Android Nougat. There are also code stubs pointing at the modification of the SystemUI and WebView Android framework elements. We couldn’t find the code that was executed by these modifications, just code stubs suggesting more development in the future. OEM outreachTriada infects device system images through a third-party during the production process. Sometimes OEMs want to include features that aren’t part of the Android Open Source Project, such as face unlock. The OEM might partner with a third-party that can develop the desired feature and send the whole system image to that vendor for development. Based on analysis, we believe that a vendor using the name Yehuo or Blazefire infected the returned system image with Triada. Production process with malicious partyWe coordinated with the affected OEMs to provide system updates and remove traces of Triada. We also scan for Triada and similar threats on all Android devices. OEMs should ensure that all third-party code is reviewed and can be tracked to its source. Additionally, any functionality added to the system image should only support requested features. It’s a good practice to perform a security review of a system image after adding third-party code. SummaryTriada was inconspicuously included in the system image as third-party code for additional features requested by the OEMs. This highlights the need for thorough ongoing security reviews of system images before the device is sold to the users as well as any time they get updated over-the-air (OTA). By working with the OEMs and supplying them with instructions for removing the threat from devices, we reduced the spread of preinstalled Triada variants and removed infections from the devices through the OTA updates. The Triada case is a good example of how Android malware authors are becoming more adept. This case also shows that it’s harder to infect Android devices, especially if the malware author requires privilege elevation. We are also performing a security review of system images through the Build Test Suite. You can read more about this program in the Android Security 2018 Year in Review report. Triada indicators of compromise are one of many signatures included in the system image scan. Additionally, Google Play Protect continues to track and remove any known versions of Triada and Triada-related apps it detects from user devices. […]

  • New research: How effective is basic account hygiene at preventing hijacking
    by Eugene Liderman on May 17, 2019 at 4:00 pm

    Posted by Kurt Thomas and Angelika Moscicki Every day, we protect users from hundreds of thousands of account hijacking attempts. Most attacks stem from automated bots with access to third-party password breaches, but we also see phishing and targeted attacks. Earlier this year, we suggested how just five simple steps like adding a recovery phone number can help keep you safe, but we wanted to prove it in practice. We teamed up with researchers from New York University and the University of California, San Diego to find out just how effective basic account hygiene is at preventing hijacking. The year-long study, on wide-scale attacks and targeted attacks, was presented on Wednesday at a gathering of experts, policy makers, and users called The Web Conference. Our research shows that simply adding a recovery phone number to your Google Account can block up to 100% of automated bots, 99% of bulk phishing attacks, and 66% of targeted attacks that occurred during our investigation. Google’s automatic, proactive hijacking protectionWe provide an automatic, proactive layer of security to better protect all our users against account hijacking. Here’s how it works: if we detect a suspicious sign-in attempt (say, from a new location or device), we’ll ask for additional proof that it’s really you. This proof might be confirming you have access to a trusted phone or answering a question where only you know the correct response. If you’ve signed into your phone or set up a recovery phone number, we can provide a similar level of protection to 2-Step Verification via device-based challenges. We found that an SMS code sent to a recovery phone number helped block 100% of automated bots, 96% of bulk phishing attacks, and 76% of targeted attacks. On-device prompts, a more secure replacement for SMS, helped prevent 100% of automated bots, 99% of bulk phishing attacks and 90% of targeted attacks. Both device- and knowledge-based challenges help thwart automated bots, while device-based challenges help thwart phishing and even targeted attacks.If you don’t have a recovery phone number established, then we might fall back on the weaker knowledge-based challenges, like recalling your last sign-in location. This is an effective defense against bots, but protection rates for phishing can drop to as low as 10%. The same vulnerability exists for targeted attacks. That’s because phishing pages and targeted attackers can trick you into revealing any additional identifying information we might ask for. Given the security benefits of challenges, one might ask why we don’t require them for all sign-ins. The answer is that challenges introduce additional friction and increase the risk of account lockout. In an experiment, 38% of users did not have access to their phone when challenged. Another 34% of users could not recall their secondary email address. If you lose access to your phone, or can’t solve a challenge, you can always return to a trusted device you previously logged in from to gain access to your account. Digging into “hack for hire” attacksWhere most bots and phishing attacks are blocked by our automatic protections, targeted attacks are more pernicious. As part of our ongoing efforts to monitor hijacking threats, we have been investigating emerging “hack for hire” criminal groups that purport to break into a single account for a fee on the order of $750 USD. These attackers often rely on spear phishing emails that impersonate family members, colleagues, government officials, or even Google. If the target doesn’t fall for the first spear phishing attempt, follow-on attacks persist for upwards of a month. Example man-in-the-middle phishing attack that checks for password validity in real-time. Afterwards, the page prompts victims to disclose SMS authentication codes to access the victim’s account.We estimate just one in a million users face this level of risk. Attackers don’t target random individuals though. While the research shows that our automatic protections can help delay, and even prevent as many as 66% of the targeted attacks that we studied, we still recommend that high-risk users enroll in our Advanced Protection Program. In fact, zero users that exclusively use security keys fell victim to targeted phishing during our investigation. Take a moment to help keep your account secure Just like buckling a seat belt, take a moment to follow our five tips to help keep your account secure. As our research shows, one of the easiest things you can do to protect your Google Account is to set up a recovery phone number. For high-risk users—like journalists, activists, business leaders, and political campaign teams—our Advanced Protection Program provides the highest level of security. You can also help protect your non-Google accounts from third-party password breaches by installing the Password Checkup Chrome extension. […]

  • Advisory: Security Issue with Bluetooth Low Energy (BLE) Titan Security Keys
    by Eugene Liderman on May 15, 2019 at 4:07 pm

    Posted by Christiaan Brand, Product Manager, Google Cloud We’ve become aware of an issue that affects the Bluetooth Low Energy (BLE) version of the Titan Security Key available in the U.S. and are providing users with the immediate steps they need to take to protect themselves and to receive a free replacement key. This bug affects Bluetooth pairing only, so non-Bluetooth security keys are not affected. Current users of Bluetooth Titan Security Keys should continue to use their existing keys while waiting for a replacement, since security keys provide the strongest protection against phishing. What is the security issue?Due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, it is possible for an attacker who is physically close to you at the moment you use your security key — within approximately 30 feet — to (a) communicate with your security key, or (b) communicate with the device to which your key is paired. In order for the misconfiguration to be exploited, an attacker would have to align a series of events in close coordination: When you’re trying to sign into an account on your device, you are normally asked to press the button on your BLE security key to activate it. An attacker in close physical proximity at that moment in time can potentially connect their own device to your affected security key before your own device connects. In this set of circumstances, the attacker could sign into your account using their own device if the attacker somehow already obtained your username and password and could time these events exactly.Before you can use your security key, it must be paired to your device. Once paired, an attacker in close physical proximity to you could use their device to masquerade as your affected security key and connect to your device at the moment you are asked to press the button on your key. After that, they could attempt to change their device to appear as a Bluetooth keyboard or mouse and potentially take actions on your device. This security issue does not affect the primary purpose of security keys, which is to protect you against phishing by a remote attacker. Security keys remain the strongest available protection against phishing; it is still safer to use a key that has this issue, rather than turning off security key-based two-step verification (2SV) on your Google Account or downgrading to less phishing-resistant methods (e.g. SMS codes or prompts sent to your device). This local proximity Bluetooth issue does not affect USB or NFC security keys. Am I affected?This issue affects the BLE version of Titan Security Keys. To determine if your key is affected, check the back of the key. If it has a “T1” or “T2” on the back of the key, your key is affected by the issue and is eligible for free replacement. Steps to protect yourself If you want to minimize the remaining risk until you receive your replacement keys, you can perform the following additional steps: iOS devices: On devices running iOS version 12.2 or earlier, we recommend using your affected security key in a private place where a potential attacker is not within close physical proximity (approximately 30 feet). After you’ve used your key to sign into your Google Account on your device, immediately unpair it. You can use your key in this manner again while waiting for your replacement, until you update to iOS 12.3. Once you update to iOS 12.3, your affected security key will no longer work. You will not be able to use your affected key to sign into your Google Account, or any other account protected by the key, and you will need to order a replacement key. If you are already signed into your Google Account on your iOS device, do not sign out because you won’t be able to sign in again until you get a new key. If you are locked out of your Google Account on your iOS device before your replacement key arrives, see these instructions for getting back into your account. Note that you can continue to sign into your Google Account on non-iOS devices. On Android and other devices: We recommend using your affected security key in a private place where a potential attacker is not within close physical proximity (approximately 30 feet). After you’ve used your affected security key to sign into your Google Account, immediately unpair it. Android devices updated with the upcoming June 2019 Security Patch Level (SPL) and beyond will automatically unpair affected Bluetooth devices, so you won’t need to unpair manually. You can also continue to use your USB or NFC security keys, which are supported on Android and not affected by this issue.How to get a replacement keyWe recommend that everyone with an affected BLE Titan Security Key get a free replacement by visiting google.com/replacemykey. Is it still safe to use my affected BLE Titan Security Key?It is much safer to use the affected key instead of no key at all. Security keys are the strongest protection against phishing currently available. […]

WordPress Appliance - Powered by TurnKey Linux