Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • David Vassallo 10:32 am on April 4, 2017 Permalink | Reply
    Tags: , , ,   

    Threat hunting using DNS indicators 

    DNS is a great source of information for security analysts… if you’re not already monitoring DNS activity in your network — you should start asap, for the reasons we’ll explore in this article

    DNS is one of the major workhorses that powers the Internet. Everything uses DNS — browsers, apps, updates… and malware. Almost every malware needs to “phone home” to receive instructions, exfiltrate data or otherwise communicate with attackers. Malware authors utilize a variety of DNS tricks to control the malware they spread, such as:

    • Domain Generation Algorithms
    • Fast Flux Domains
    • DNS Covert Channels
    • Familiar or misspelt domains

    Domain Generation Algorithms

    Once malware is installed on a target system, it usually needs to communicate back to its C&C server for instructions. Hardcoding a domain into the malware would make the malware very short lived… malicious activity is banned on many hosting providers who are quick to revoke DNS records involved in such activity. So, authors program malware using Domain Generation Algorithms [DGAs] to generate algorithms on the fly, usually by using a combination of the current date. This increases the chances of malware being able to communicate with a DNS domain that is still active — increasing it’s useful lifespan. Wikipedia has a very interesting and easy to read article on DGA, including examples from CornFlicker, CryptoLocker, and others.

    Typically these domains are quite random in nature, for example “intgmxdeadnxuyla” and “axwscwsslmiagfah”. That makes it quite easy for a human to pick out. The downside is that there are way too many DNS records to check manually, and automated malware domain lists don’t usually include DGA generated domains, there are simply too many and they change every day

    CyberSift helps out by performing a number of language structure checks on visited domains. In the example below we investigate a DGA generated domain that has quite a high abnormal score of 22.853 (anything above a 10.0 warrants some investigation). As you can see in the highlighted portion of our output, a model named “Score” contributed quite a large number of points (13.515) to the abnormal score. The score model uses statistical analysis to determine how likely a domain has a given structure, and how often it is used. Since DGAs output random domains that dont usually look anything like proper language, they tend to trigger this model

    CyberSift DGA Detection

    Fast Flux Domains

    Fast flux domains are a tried and tested malware and phishing technique. In it’s simplest form, malware authors register hundreds (or thousands) of IP address for a given domain. The DNS records are given a short time to live, so that infected victims connect to different IP addresses for any given malware domain, reducing the chances of an IP address being blocked. Sometimes, fast flux domains are used in combination with DGA to further increase the chances of infected machines communicating back to their handlers.

    Some advertising networks (usually shady ones…) tend to use fast-flux domains, which return a high number of IP addresses. In our example below we see one such advertising network, returning an abnormally high number of IP addresses, and contributing quite a large chunk to the anomaly score

    DNS Covert Channels

    DNS covert channels are particularly interesting. We mentioned that practically any program needing to connect to the Internet requires DNS to function properly, so two things are pretty much guaranteed:

    1. Outbound DNS requests are not blocked
    2. Since DNS proxies are not as prolific as HTTP/S proxies, DNS traffic is very probably not monitored

    This creates a perfect medium for attackers to use… by tunneling data through DNS traffic. As recently as last month (March 2017), security researches have observed malware leveraging this concept to hide their communication traffic in plain sight:

    Covert Channels and Poor Decisions: The Tale of DNSMessenger

    DNSMessenger used TXT records to create a covert channel, that would be difficult to detect. Looking at CyberSift’s output during testing, we see an alert that there was anomalous activity in our environment’s DNS activity:

    CyberSift detecting anomalous DNS activity

    CyberSift uses intelligent clustering techniques to detect anomalous behavior when it comes to the amount of DNS queries being sent by your environment, to detect issues such as mis-configuration, or — as in the example above — covert malicious activity

    This makes threat-hunting quite easy. A sample security threat hunter’s workflow using CyberSift would be something as follows:

    CyberSift vs DNSMessenger Summary

    Familiar or misspelt domains

    You’ve definitely seen this age-old but extremely popular technique from scam and phishing campaigns. Attackers love to use familiar looking domains such as “” (or “”) and similar domains which most analysts wouldn’t give a second glance to, since they’d assume it’s a legitimate service. This has become quite a problem especially with free SSL certificate authorities:

    An example of this technique in use in the wild can be seen in the “OilRig” campaign:

    OilRig Campaign Analysis from AlienVault OTX:

    From the section “Indicator of Compromise” in the above screenshot, we see a domain which certainly looks familiar: An analyst is certainly forgiven if they don’t investigate this domain more thoroughly — it does after all look like something Google would really use.

    But a closer look with CyberSift reveals a different story:

    Again, the “Score” model comes to the rescue here. The model realizes that the word “google” is usually not seen in this context, and adds just enough point to make this domain anomalous (remember anything over 10.0 is considered worth investigating). Over and above that, the site in this case did not resolve, so this caused the DNS anomaly engine to push up the anomaly score even further.

    Interested in learning more about CyberSift? Have feedback or would like to try out CyberSift? Contact us for more information

  • David Vassallo 8:29 pm on March 19, 2017 Permalink
    Tags: , , Java, , REST   

    Elasticsearch REST API: JEST upsert 

    I’ve already written about tips and tricks when using the Elasticsearch Java API. The Elasticsearch REST API has been going from strength to strength, and it seems that going forward the Elasticsearch team will focus more on the REST API than the native JAVA client. At the time of writing however, the official java REST library doesn’t seem to have support for the abstraction of the bulk API, so I followed some advice and looked into the JEST library.

    The only snag with the Jest library is that when it comes to bulk operations, the documentation only gives examples of scripted updates. The Elasticsearch update API also allows for updates using partial documents. Jest supports this functionality, but I couldn’t find good documentation for this. Here-under is an example for anyone looking for this:

    The important points:

    • You can still use the official java elasticsearch client’s “XContentFactory.jsonBuilder” library to more easily build your JSON objects.
    • The trick is in line 26 above:


    This creates a nested object with “doc” as the inner JSON object, as outlined by the elasticsearch documentation:

        "doc" : {
            "name" : "new_name"

    The first “startObject()” creates the outer curly brackets, while the second startObject(“doc”) creates the inner “doc” object.

    • We add content to the JSON object in lines 27-29
    • Just like we had to use two startObject() calls, we need to close the object with two endObject() calls as shown in line 31

    The rest of the snippet deals with the actual bulk update. We pass the object we just created into an Update Builder, which gives us a “Bulkable Object” that we can pass on to the jest bulk processor. The snippet is taken from a larger program where it resides in a loop – which explains the if/else clause in lines 37-48; it’s important to “flush” the bulk service every so often. The native java client would to this automatically – so far in Jest you need to account for this yourself








Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc
%d bloggers like this: