Breach Detection

New Ransomware called LooCipher has been found in the Wild

According to Bleeping Computer, a new ransomware called LooCipher has been found in the wild. https://www.bleepingcomputer.com/news/security/new-loocipher-ransomware-spreads-its-evil-through-spam/   In usual fashion, it is impacting users through spam.  Unsuspecting users are opening the phishing email, clicking on the link, giving the file authorization to use macros, and ultimately getting the malicious file installed.

In 2011, Lockheed Martin is credited with the idea of a cyber security kill-chain.  The cyber security kill-chain, as designed, organizes threats into categories as well as security controls that can be deployed in those categories to mitigate those risks.  If we apply the kill-chain to the Loocipher ransomware, we see the following:

  1. The phishing email, in the delivery category, should have been caught by commercial email protection tools.
  2. The dropper file (Info_BSV_2019.docm), in the delivery category, should have been caught by malware tools as well as other AV tools. Note, the end user in this case had to allow the macros to run.  User awareness is still essential to defending against these types of attacks!
  3. Once the macros have been enabled, the malware reaches out to a TOR server to download another file (http://hcwyo5rfapkytajg.onion.pet/3agpke31mk.exe) In this case, this should have been detected in the command and control as well as the delivery category.  These categories usually are defended by threat intel tools, malware tools, and host based tools.
  4. Finally, a new file (c2056.ini) will be created and the file encryption process begins. This file creation and subsequent encryption should be caught in the actions and exfiltration category and protected by tools such as threat intel, process anomaly detection, firewalls, and malware tools.

 

What’s was not accounted for in the cyber kill-chain was the advance of machine learning and AI.  Applying these tools to the data at each category of the kill-chain improves our ability to catch the anomalous behavior at each category, as well as improving the mitigation at each category by correlating the detections.

Starlight is committed to utilizing our Unified Security Analytics Platform to detect, alert, and respond to these types of behaviors.  Our pervasive data collection, coupled with advanced data handling and machine learning, gives us multiple areas where we can detect these types of attacks across the cyber kill-chain.  If the attack is missed in one stage of the kill chain, we will catch it in another stage.  Once detected, we have the ability to take automated action against those anomalous behaviors.   Applying our technology to the Loocipher ransomware, we would potentially detect and mitigate it in the following ways:

  1. Our phishing detection would evaluate the malicious URL and mitigate its risk
  2. The dropper file referenced above would have been evaluated by our malware tool and mitigated.
  3. Had the dropper file passed the malware test, the server sensor would have caught the behavior change (i.e. new process spawn with a new connection to the TOR server).
  4. If the dropper file passed the malware and server sensor assessment, the call to the TOR server could have been mitigated at the network level. The Starlight platform would have signaled the network firewalls to implement a block to the target server.
  5. The new file download (http://hcwyo5rfapkytajg.onion.pet/3agpke31mk.exe) could have been caught and mitigated at the server sensor or malware assessment.
  6. Finally, the encryption process would be detected by the server sensor and mitigation techniques applied to prevent/stop the process from continuing.

 

Ransomware is a huge industry.  Backups are essential but so is defense-in-depth.  If you are not protecting your environment at the various stages of the kill-chain, you should consider doing so.  If you are struggling to implement these concepts because you have too many tools that don’t interoperate, give us a call.  We can help!

Breach Detection, Data Collection

DNS under fire lately as nation-states and hacker groups steal credentials from unsuspecting victims.

DNS has come under fire lately as nation-states and hacker groups have targeted DNS as a method to steal credentials from unsuspecting victims.

According to Techcrunch the hackers first compromised the intended target via spearphishing.  They then used known exploits to target servers and routers and move laterally within the network.  In that process, the hackers obtained passwords which let them update the DNS records pointing the domain name away from the IP address on the target’s server to a server controlled by the hacker.  This allowed the hacker to gather username and passwords utilizing man-in-the-middle attacks.  The hacker also used fake certificates to make the malicious hacker server appear to be the real web server.

 

There are very few ways to prevent this attack.  A few areas to focus on include:

  1. Implementing two factor authorization for all DNS record changes.  While in theory, a very smart move, in practice difficult as not all registrars support this.
  2. Registry Lock – this is like a credit lock on your financial records.  This prevents unauthorized, unwanted or accidental changes to the domain name at the sponsoring registrar.  Unfortunately, not all top level domains support Registry Lock.
  3. Deploying email security to intercept and prevent the successful phishing campaign
  4. Host based malware detection tools

 

Starlight is committed to utilizing our Unified Security Analytics Platform to detect, alert, and respond to these types of behaviors.  Our pervasive data collection, coupled with advanced data handling and machine learning, gives us multiple areas where we can detect these types of attacks across the Lockheed Martin cyber kill-chain.  If the attack is missed in one stage of the kill chain, we will catch it in another stage.

  1. Successful spearphishing campaigns ultimately leave new binaries to be executed.  Stellar Cyber has built in malware analysis that would reassemble the binary in transit, evaluate it against known signatures, and ultimately put it in a sandbox for testing.  The results of that testing would drive action should the test determine the binary is malicious in nature.
  2. If the binary passes the malware testing, our server sensors detect the installation and execution of anomalous binaries and alert on those activities.
  3. If the binary is not detected, the resulting command and control activities will be detected, alerted, and potentially blocked.
  4. Binaries that issue commands to the OS are also detected as anomalous and would trigger an alert.
  5. Domain validated certificates – As these certificates can be generated without human intervention, they can be used to give the end user a false sense of security.  One example of a domain validated certificate is “Lets Encrypt.”  Our Starlight platform has the ability to detect domain validated certificates and alert on them.

Defense in-depth is still very much alive (despite some discussions to the contrary).  Catching new attack methods depends on visibility and detections at all stages of the cyber security kill-chain.  Stellar Cyber is uniquely positioned to help you quickly detect and protect against these types of attacks.

 

David W. Barton
Chief Information Security Officer
615-939-2861
www.stellarcyber.ai

Breach Detection

What Are DGAs and How to Detect them?

Domain Generation Algorithms (DGAs) are a class of algorithms that periodically and dynamically generate large numbers of domain names. Typically, the domains are used by malware and botnets as rendezvous points to facilitate callback to the malicious actor’s Command & Control servers. DGAs allow malware to generate tens of thousands of domains per day, the vast majority of them unregistered. The enormous numbers of unregistered domains are used to masquerade the registered ones, allowing the infected botnets to evade detection and deterrence by signature or IP-reputation based security detection systems.

The first known malware family to use a DGA was Kraken in 2008. Later that year, the Conflicker worm pushed the DGA tactic into notoriety. Even after 10 years, it is still possible to find Conflicker or one of its variants on some of today’s networks.

In tandem with the increasing proliferation of malware, the usage of DGAs has become more pervasive.

The Objectives of DGA Detection

Because DGA activity is a considerable indicator of compromise, it becomes critical to detect any such activities on your network. There are three levels of DGA detection, with each subsequent level correlating to a rise in severity. Detection at later levels is more difficult, but more critical.

If a DGA is detected, it means that one or more of your systems have been infected by DGA-based malware and have become botnets. Some actions need to be taken. The first objective is to identify the affected systems, properly cleaning or quarantining them to prevent escalation.

The next objective is to determine whether a given DGA domain name is registered. If the domain is registered, it has become an active Command & Control server that presents a great risk to your network. Infected systems, now botnets, may use these servers to call home and receive commands from the malicious attacker. Therefore, the second component of an effective DGA detection system is the ability to differentiate registered domains from the unregistered ones.

For example, a DGA may generate 1000 domains, from xyzwer1, xyzwer2 …. to xyzwer1000. The hacker only needs to register one domain, i.e., xyzwer500, not the other 999 domains. If the registered domain and its associated IP can be identified, the information can be used to block the communication channel between the targeted system and the Command & Control server. Additionally, the intel should be propagated to all other prevention or detection systems in place to obstruct callback to that server from any system in the network.

The last but most critical objective of a DGA detection system is to determine whether callback was successful with the registered domains and contact was made between the infected system(s) and the Command & Control server. If such activity is detected, some damage may have already been done. Perhaps the malware in your network was updated, or new malware was installed. Sensitive data may have been exfiltrated.

How does DGA Detection work?

DGA activity is detected by capturing and analyzing network packets, usually in five general steps.

Step 1 – Detect DNS Application
Detection begins via DNS request and/or response messages. DNS is a fundamental Internet protocol, and most firewalls have a policy to allow outgoing DNS traffic on its reserved port 53. However, a hacker may take advantage of port 53 to send its traffic without adherence to the standard DNS message format. This attack is called DNS tunneling. A Deep Packet Inspection (DPI) Engine is recommended to identify the DNS applications more precisely.

Step 2 – Extract Domain Names
Once a network application is identified as DNS, the domain names in the DNS query and response messages need to be extracted. In order to extract the right domain name, the DNS message’s content needs to be parsed carefully and a DPI engine is required to perform this task.

Step 3 – Detect any DGA
Analysis needs to be performed on the domains extracted from DNS messages to determine whether they are DGAs. This is perhaps the most complicated step. The challenge is to reduce both false positives as well as false negatives. Detection mechanisms have evolved dramatically over the last 10+ years.
Some mechanisms are based on the relatively simple Shannon Entropy.
https://www.splunk.com/blog/2015/10/01/random-words-on-entropy-and-dns.html
Some mechanisms are based on more sophisticated Ngrams as presented by Fyodor in the Hitb conference
Lately, with machine learning becoming popularized, its methodologies have also been applied to DGA detection. Machine learning can combine the features of Ngrams, Shannon Entropy, as well as the length of the domain names to influence decisions. Several machine learning models have been tried. There is a very good blogpost by Jay Jacobs in 2014 describing the process.
Here is another open source DGA detector based on Machine Learning with Markov Chain:
https://github.com/exp0se/dga_detector

Step 4 – Detect Registered DGA Domains
In order to detected whether a DGA domain name is registered, DNS responses need to be checked. Merely tracking DNS requests is not sufficient – the detection system should track the entire transaction to facilitate correlation between pieces of information.

Step 5 – Detect Traffic to Registered DGA Domains
When most existing DGA detection systems focus on detecting whether a domain name is a DGA domain, they often forget the last question, the most important one: is there any traffic that has been sent to the registered DGA domains? In order to detect this in a timely fashion, DGA domain detection must be tightly coupled with network traffic inspection. The results need to be echoed back to the traffic inspection engine immediately before any damage is done.

Step 6 – Blocking the Traffic to Registered DGA Domains
While not technically a part of detection, if there is an integration with a prevention system such as a Firewall or IPS, a rule should be inserted right away to block all the traffic to the registered domains.

A great DGA detection system should perform all 5 steps. An excellent DGA detection system should also include Step 6. Unfortunately, most DGA detection systems today stop at either step 3 or step 4.

Conclusion
Because DGAs are difficult to detect with signature or reputation based detection or prevention system, they have become quite popular with malware developers.
An intelligent detection system is required to perform the detection. An excellent DGA detection system must extract domain name information from DNS transactions, perform thorough analytics to detect DGA status, check registration status of suspected domains, correlate with network traffic inspection to assess the level of compromise, and ideally integrate with prevention systems to avoid further compromise. In order to reduce both false positives as well as false negatives, a machine learning should be seriously considered. Only with comprehensive and pervasive intelligence at every stage can the threat be truly ameliorated.

Resources

The repository in Github by Andrey Abakumove contains algorithms for generating domain names, as well as dictionaries of malicious domain names.

Artificial Intelligence, Breach Detection, Data Collection

The 2017 Equifax Breach

In 2017, Equifax, one of the world’s largest credit reporting agencies suffered a cyber breach of unprecedented impact and scale.  More than 145 million records of personal identifiable information were stolen by cyber criminals.  Because of the nature of this breach, the CEO of Equifax resigned, a congressional investigation commenced, Equifax’s stock took a hit and a 50-state class action lawsuit was filed.

Continue reading “The 2017 Equifax Breach”