This post was originally published on this site

Last week, the arrest of MENG Wanzou made big waves in the news. Ms. Meng was arrested in Canada based on an arrest warrant issued for the United States Department of justice. Ms. Meng, as CFO of Huawei and possible heir to her father, the CEO of Huawei, is assumed to have access to substantial wealth. This led to a wave of advanced fee scams levering this news. 

Advanced fee scams have probably been most commonly associated with “Nigerian Prince” scams. The trick is to promise substantial wealth in exchange for a relatively small advanced fee.

In this case, the message sent via WeChat suggested that a corrupt Canadian guard would let Ms. Meng escape for a few thousand dollars. The recipient of the message is asked to transfer the money to the guard’s account, and promised a large amount of money once Ms. Meng is released:

Translation: “Hello, I am MENG Wanzou. Currently, I have been detained by Canadian customs. I have limited use of my phone. Right now CIA is trying to get me into the hands of the US government. I bribed the guard of my room, and urgently need US$2000 to get out of here. Once I am out, I will reward you 200,000 shares of Huawei.  I will be good on my word. if you are single, we can also discuss the important thing in life. The guard’s name is David, the account number is 52836153836252, swift 55789034. I will be good on my word”

Of course, it is questionable how successful a crude attempt like this will be. But sadly, experience tells us that there are still people falling for the old “Nigerian scam”. By targeting Chinese individuals via WeChat, the scam may have a higher success rate than more widely distributed scams.

—
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.

This post was originally published on this site

String analysis: extracting and analyzing strings from binary files (like executables) to assist with reverse engineering.

It’s a simple method, but still useful, if you don’t have to spend hours sifting through all strings produced by the string tool. I have a tip to quickly find “interesting” strings: sort the output of the strings tool by string length. Start with the shortest strings, and end with the longest strings.

Take for example the analysis of a malicious document, that involved many steps and requires good knowledge of different file formats.

Just by extracting the strings of this document and sorting them by length, you immediately find the powershell command:

I developed my own strings.py tool, and option -L sorts strings by increasing lenght.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

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

This post was originally published on this site

Reader Jason submitted a ZIP file received via email. It contains an MHT file, an when Jason received it, it had 0 detections on VirusTotal.

When an analyst receives an unknown file with 0 detections on VirusTotal, the analyst will often try to determine of the file is malicious or not via other means than anti-virus.

For MHT files, Xavier has already explained how they can be malicious in this diary entry.

I take a look at the ZIP file with my zipdump utility:

The extension .mht indicates that it is an MHT file. I use option -e to get more information on the content of the file (together with option -S , to use a comma as separator):

It’s a small file (201 bytes decompressed), and it contains ASCII text: 27 whitespace characters and 174 printable ASCII characters (no NULL bytes, no control characters and no non-ASCII bytes).

An ASCII dump (option -a) confirms it’s text:

And thus I can safely extract the content to my console:

As Xavier explained in his diary entry on MHT files, this MHT file, when opened, will download and open a JAR file (provided Java is installed).

Files that purport to be documents, but actually download and execute programs, are clearly malicious. I often see that very small files like this MHT file, have 0 detections on VirusTotal when they are submitted right at the beginning of the malware campaign. It’s only later, when AV definitions get updated, that the detection rate on VirusTotal increases.

When I performed the initial analysis, the JAR file was no longer available.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

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

This post was originally published on this site

If you haven’t uninstalled Flash yet, maybe today should be that day.  The update posted yesterday has a remote code exec proof-of-concept already here:
https://github.com/smgorelik/Windows-RCE-exploits/blob/master/Documents/Office%2BFlash/CVE-2018-15982_%23PoC%23.zip

And Gigamon has posted that it’s being seen in the wild already:
https://atr-blog.gigamon.com/2018/12/05/adobe-flash-zero-day-exploited-in-the-wild/

 

===============
Rob VandenBrink
Compugen

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

This post was originally published on this site

In many penetration tests, there’ll be a point where you need to exfiltrate some data.  Sometimes this is a situation of “OK, we got the crown jewels, let’s get the data off premise”.  Or sometimes in this phase of the test the goal is “let’s make some noise and see if they’re watching for data exfiltration – hmm, nothing yet, let’s make some LOUDER noise and see (and so on)”.  As with most things, there’s a spectrum of methods to move the target data out, with various levels of difficulty for detection.

At the basic end of the spectrum, moving the data in clear text is a good test at the “are they even monitoring” end of things.  “Living off the land” (using natve operating system tools) is usually the prefered approach in my gigs – so the obvious method is to try ftp – there’s an ftp client on pretty much every workstation and server OS on the planet.  If you are moving identified target data (credit card information, customer account information, other PII, engineering drawings, source code or other intellectual property), this should trigger some DLP (Data Loss Protection) detection at the perimeter – often this is coded into the firewall.

What else should see this?  Really outbound FTP shouldn’t work – your client should have an egress filter on their firewall – outbound clear text file transfers to random hosts shouldn’t be allowed.  But say they it’s allowed.  Firewall logs will definitely show the transfer, but if there’s no egress filter chances are nobody’s watching the logs of the “noisiest” piece of infrastructure in the fleet – firewall logs can easily top 5GB per day, even in a small-ish organization.

A simple “cat todayslog.txt | grep /21 | grep -i permit” will show your successful exfil in the logs.  If there’s an egress filter, you’d be looking for a blocked transfer, which would look more like:
cat todayslog.txt | grep /21 | grep -i deny

If the client has Netflow running for their perimeter, Netflow will show to/from traffic by protocol, so if they’re running netflow telemetry from the firewall to a collector, your client will have you on film, with pictures (again, if they are looking).

OK, say you need to ramp it up a notch?  If you’re able to transfer any tools in (or if you’ve popped a linux host), netcat (or ncat if you’ve got an nmap install you can use) is your friend – or you can use any number of PowerShell or Python implementions of netcat if you’d rather stick to running native tools.  This will allow you to exfiltrate data, still in clear text to a host ready to receive it – it just won’t look like FTP.

This will be tougher to see, because you’re exiting out on a different port.  You might think “let’s pick 1337, that’s a really cool “leet” port”, or some other random port.  But that will pop up as an outlier in any tool if they’re looking at traffic.  Not only will DLP see the data right away, but it’ll pop up as “odd” to any log monitoring tool or netflow collector.

Maybe source it from a random port and use 80 or 443 as a target port?  We still see lots of folks that say “tcp/443 is encrypted, we won’t even inspect it”.  Or better yet, if you are exfiling from a server with an inbound web service, using ncat or similar, with the ports reversed – source port of 443 and destination some random port – to an unsusecting eye or poorly configured tool, this will look like inbound traffic to a legitimate service.  Except maybe for the volume of data leaving that is…

Let’s scramble the data – – maybe they won’t detect these same cleartext methods, but let’s base64 the data first?  If you are operating from a customer *nix server that’s easy, but if you’re on a windows host, you can base64 encode data just using certutil (included on every windows host on the planet:
certutil -encode c:foodata.binortext c:fooscrambledata.asc
and
certutil -decode c:fooscrambleddata.asc unscrambleddata.txtorbin

Powershell is a nice tool for encoding and decoding also – first, let’s encode:

PS L:datareadytoexfil.source> $test = “this is some target data.  for larger files, use get-content instead of direct assignment”
PS L:datareadytoexfil.source> $test2 = [System.Convert]::ToBase64String([System.Text.Encoding]::UNICODE.GetBytes($test))
PS L:datareadytoexfil.source> $test2
dABoAGkAcwAgAGkAcwAgAHMAbwBtAGUAIAB0AGEAcgBnAGUAdAAgAGQAYQB0AGEALgAgACAAZgBvAHIAIABsAGEAcgBnAGUAcgAgAGYAaQBsAGUAcwAsACAAdQBzAGUAIABnAGUAdAAtAGMAbwBuAHQAZQBuAHQAIABpAG4AcwB0AGUAYQBkACAAbwBmACAAZABpAHIAZQBjAHQAIABhAHMAcwBpAGcAbgBtAGUAbgB0AA==

Now, after you’ve moved the data, you’ll need to decode that data:

PS C:exfil.destination> $test3 = [System.Text.Encoding]::UNICODE.GetString([System.Convert]::FromBase64String($test2))
PS C:exfil.destination> $test3
this is some target data.  for larger files, use get-content instead of direct assignment

(Thanks Jeffrey Snover and his 2006 blog post on this!   https://blogs.msdn.microsoft.com/powershell/2006/04/25/base64-encodedecode-a-string/  )

OK, lets say that your client is equipped to see all of this so far (base64 encoding really should be triggering alarms) –  how would you kick it up a level and exfil data using real encryption?  

An SSH Tunnel or a straight up SCP file transfer is a favourite for this.  Hopefully the client has a simple rule on their firewall though that only allows this from specific hosts or specific user accounts.  This would mean that your transfer will either be a block/alert thing for them, or worst case a permit/alert thing.

If they permit it, you can try just uploading yoru data to a public HTTPS repo.  Mostly a well configured firewall should catch this though – for instance:

• dropbox, onedrive and the like – traditional clients should normally have a “we store our data here” policy – so this sort of site really should be blocked unless your compromised account is in a group with access to one or more of these general purpose “stash your files here” sites.  Of course if your client has a “the cloud is sparkly and can do no wrong” outlook, this is the perfect way to exfiltrate your data.
• Similarly, github should be restricted for most users – however, if you can compromise a developer account it makes a dandy target and will usually work.

What if you’re trying to trigger an alert?  OK, try sending your exfil via https to pastebin – – there shouldn’t be a legitimate need to access pastebin for most folks.  Hopefully any well configured firewall will block and alert on this one!

What’s the next most difficult method to see?  OK, we’ll go back to cleartext for this one, but most folks won’t be looking at their own remote access VPN for data exfiltration.  If they use a single factor authentication (userid and password, usually back-ended with active directory), then this a great method of moving lots of data.  Because why would they block that, in most cases management is in favour of people working after hours from home!  That is until you ask what happens if that salesperson who left last week managed to exfil your entire client list, current pricing matrix and maybe all the RFPs that are currently in flight?  (this exfil method is a great way to make this point)

Let’s say you want to use an encrypted data transfer direct to your $evilserver?  OK, curl will do that, but it’ll look like curl.  Changing the useragent will help, but changing it to match firefox or chrome won’t change the $evilserver destination.  hmmm – what service is usually whitelisted right near the top of the firewall list?   Yup, you guessed it, let’s make our traffic look like Windows Update -let’s change the user agent to look like a Microsoft BITS (Background Intelligent Transfer Service) file transfer.  Change the curl useragent to “Microsoft BITS/7.5” and very likely you won’t have any trouble at all getting your data out.  Often you don’t even need to encrypt it, send it out in clear text on port 443 with that useragent, and you’ll sail past everyone’s “Next Generation” firewall, IPS or whatever.

You can move data using BITSADMIN (in most Windows versions), or if you are in a newer windows version, just use the BITS commands in Powershell.

Other methods?  If there’s an inbound RDP service (either native or an RDS gateway), RDP in, and map a drive back to your client with “net use v: tsclientsharename”.  Now you can use xcopy, robocopy or whatever to move data in or out, and it’ll all be encrypted using a legitimate protocol that the client expects to see, and very (very) likely is not decrypting.  Their only hope of detection will be the target address.  If their RDS gateway allows full access from the internet, then they’re out of luck.  You’d also be surprised how many organizations allow *outbound* RDP (no matter how bad that idea is) to any target host.  If that’s the case, you can RDP back to your $evilserver from any internal customer host, map a drive back to the client host and move data using this exact same method!

One thing to note – we discussed these things more or less in order of difficulty, this isn’t normally the order you try things in.  Most often, I’ll start with the toughest ones to detect, then work my way down successively to the easier ones until I’m “caught”.  In most cases, you *want* to be caught at some point, so that you can have the conversation about what was seen and was not seen.  If you get all the way down to a plain old FTP of cleartext data and are still undetected, it’s time for a serious conversation about perimeter configs, logging and alerting 🙂

A common thread to all of this is that if your client has a “next gen” firewall, they are not safe.  If you’ve compromised AD, usually you can create a dummy user and put that user in a group that has permissions to exfiltrate the data, so that the firewall just lets it sail on through.  Change logging in AD should alert your client to this sort of activity. Or if you’re able to leverage your AD access to then login to the firewall as an admin, you’ll be able to (with permission of course), permit your exfiltrated data to pass outbound with no logging or alerting, then delete that rule.  Change logging on your firewall should catch this immediately.  If you aren’t logging admin activities on the firewall, or at least backing up your firewalls and running “diff” against yesterday’s backups, then you need to be doing that (this really is a recommendation we were making 10-15-20 years ago).

What did I miss?  Sure, you can do exactly this job with metasploit, unicorn or any number of other tools, but if possible I try to stick with what I can use on the host OS – the things that the client expects to see either from regular users or regular system administrators.   Using native tools to accomplish malicious goals will usually make a bigger impact in your report.

Even with that “living off the land’ approach, I’m sure that I’ve missed other methods of data exfiltration – what native methods have you used to exfiltrate data?  What methods worked, what methods got caught and how?  Use our comment form to fill us in!

===============
Rob VandenBrink
Compugen

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

This post was originally published on this site

Introduction

Today’s diary reviews trends in recent malicious spam (malspam) pushing Hancitor.

Background:  Malspam pushing Hancitor (also known as Chanitor or Tordal) is a long-running campaign.  In recent months, we’ve often seen waves of Hancitor malspam 2 or 3 times each week.  Infections from this malspam tend to follow predictable patterns, and have ended with Ursnif as the follow-up malware since the end of October 2018 (previously it had been Zeus Panda Banker).

Recent activity:  After a wave of malspam on 2018-10-29, this campaign went silent, and we saw no new Hancitor malspam for one month.  Last week on Thursday 2018-11-29, Hancitor malspam returned with changes to the macro code in the associated Word documents.  Hancitor is still sending Ursnif as its follow-up malware.

Today’s diary reviews an infection from Hancitor malspam seen on Tuesday 2018-12-04.

Shown above:  Flow chart for the Hancitor infection on Tuesday 2018-12-04.

The malspam

Shown above:  Screen shot from an email in this malspam wave.

The email template for Tuesday’s malspam was eFax-themed, which is something we’ve occasionally see from this campaign.  No big surprises here.  And the link to download a Word document follows the same pattern of ASCII characters at the end, where all characters after the = sign are an encoded string that represents the recipient’s email address.  I’m still not sure how to decode these strings.

Below is an example of the email headers from one of the messages on Tuesday:

Received: from lenoxia.com ([169.203.179.39]) by [removed] for [removed];
        Tue, 04 Dec 2018 15:38:56 +0000 (UTC)
Date: Tue, 04 Dec 2018 08:40:58 -0700
MIME-Version: 1.0
X-Mailer: iPad Mail (11D169b)
Content-Transfer-Encoding: 7bit
Subject: This is an automatic eFax Notification
Message-ID: <1563DCE3.5F979EAC@lenoxia.com>
From: "eFax, Inc." <efax@lenoxia.com>
Content-Type: text/html;
    charset="utf-8"
TO: [removed]
Reply-To: "eFax" <efax@lenoxia.com>

 

At first glance, the downloaded Word document looks similar to those seen in previous waves of Hancitor malspam.  Victims must enable macros to infect a vulnerable Windows host.  However, the macros act noticeably different than before (more on that later).

Shown above:  Downloading a Word document from a link in the malspam.

Infection traffic

Infection traffic follows the same patterns we’ve previously seen for Hancitor, except wotj additional infection traffic for Ursnif instead of Zeus Panda Banker.  In this case, I also saw Tor traffic, which might be related to the Ursnif activity.  An HTTP request to amalu[.]at returned an encoded binary about 2.2 MB in size, which matched a malware binary I found on the infected Windows host for Send Safe Enterprise (SSE) spambot malware.  I also saw the UDP beaconing traffic associated with SSE spambot malware.

Shown above:  The initial infection traffic filtered in Wireshark, showing Hancitor and Ursnif traffic.

Shown above:  Later in the infection, we find Tor traffic.

Shown above:  Infected host retrieves SSE spambot executable (encoded when sent over the network).

Shown above:  UDP beaconing traffic caused by SSE spambot malware.

Forensics on the infected host

Unlike previous Hancitor Word docs, ever since Hancitor reappeared on 2018-11-29, the Word documents are noticeably larger, and they contain ASCII-based hex code that is decoded as two executable files dropped after enabling macros.  These two executables are named werd.exe and wird.exe, and they’re dropped to the user’s AppDataRoaming directory.  A folder also appeared in the AppDataRoaming directory with links copied from the desktop of my infected Windows host.  I also saw folders named msohtmlclip and msohtmlclip1 that were created in the user’s AppDataLocalTemp directory.

Ursnif was made persistent through about 14MB of ASCII code stored as Windows registry entries.  This is normal for Ursnif infections, and I’ve exported a copy of these registry entries so people can review them.  See the link at the end of this dairy to access the data.

Finally, SSE spambot malware was stored in the user’s AppDataLocalTemp directory using random digits in the filename.

Shown above:  werd.exe and word.exe dropped to the user’s AppDataLocalTemp directory.

Shown above:  More artifacts from the infected Windows host.

Shown above:  Windows registry entries created by Ursnif on the infected Windows host.

Indicators

The following are indicators from an infected Windows host.  Any malicious URLs, IP addresses, and domain names have been “de-fanged” to avoid any issues when viewing today’s diary.

URL from the malspam text to download the initial Word document:

• 47.89.18[.]253 port 80 – your365realestateoffice[.]com – GET /?[string of characters]=[string of characters representing recipient’s email address]

Hancitor infection traffic after enabling Word macros:

• port 80 – api.ipify.org – GET /  (IP address check by the infected host, not inherently malicious)
• 191.101.20[.]16 port 80 – ninglarenlac[.]com – POST /4/forum.php
• 191.101.20[.]16 port 80 – ninglarenlac[.]com – POST /mlu/forum.php
• 191.101.20[.]16 port 80 – ninglarenlac[.]com – POST /d2/about.php
• 131.72.236[.]103 port 80 – todoemergencias[.]cl – GET /wp-includes/1
• 131.72.236[.]103 port 80 – todoemergencias[.]cl – GET /wp-includes/2
• 131.72.236[.]103 port 80 – todoemergencias[.]cl – GET /wp-includes/3

Ursnif infection traffic:

• 47.52.45[.]178 port 80 – api2.doter[.]at – GET /webstore/[long string]
• 47.52.45[.]178 port 80 – 47.52.45[.]178 – GET /favicon.ico
• 47.52.45[.]178 port 80 – beetfeetlife[.]bit – GET /webstore/[long string]
• 47.52.45[.]178 port 80 – beetfeetlife[.]bit – GET /jvassets/o1/s64.dat

Tor traffic seen after the initial Hancitor and Ursnif activity:

• various IP addresses over mostly port 80 – GET /tor/status-vote/current/consensus
• various IP addresses over mostly port 80 – GET /tor/server/fp/[long hex string]
• various IP addresses over port 443 – SSL/TLS traffic

Infected host retrieves SSE spambot malware:

• 46.163.119[.]217 port 80 – amalu[.]at – GET /wp-admin/includes/36s

UDP beacon caused by SSE spambot malware:

• 31.44.184[.]36 port 50012

Malware from an infected Windows host:

SHA256 hash:  eebc056d535f2b1278df043eee776595b6526e47a6cffdc67641c165b1f5e973

• File size:  458,240 bytes
• File description:  Word doc downloaded form email link, doc has macro for Hancitor
• File name:  invoice_530486.doc   (random digits in the file name)

SHA256 hash:  ad783ca9c2bd4c9905b131d170c1dce5bad9de8b8c2d4607a8cd051021284df0

• File size:  114,690 bytes
• File description:  Hancitor malware binary dropped by Word macro
• File location:  C:Users[username]AppDataRoamingwerd.exe

SHA256 hash:  a1a0cb7e5a7239b7aa69f2d052464c201bd5082d9a8b2aac6997fda5de9a7228

• File size:  52,226 bytes
• File description:  Hancitor-related executable dropped by Word macro
• File location:  C:Users[username]AppDataRoamingwird.exe

SHA256 hash:  9350609c8c806a9c1a667fd53926ea85745e1da239df7f3c2aad3e3527bd48d1

• File size:  249,544 bytes
• File description:  Ursnif executable retrieved by Hancitor-infected host
• File location:  C:Users[username]AppDataLocalTempBNA4D6.tmp   (random characters in the file name)

SHA256 hash:  86ca2f22dd4c99b57bb9d272cd5dd91978e15853efa0c05ede8c80694a8d27a6

• File size:  2,163,976 bytes
• File description:  Send Safe Enterprise (SSE) spambot malware
• File location:  C:Users[username]AppDataLocalTemp1907751.exe   (random digits in the file name)

Final words

3 email examples, a pcap of the infection traffic, and malware/artifacts associated with today’s diary can be found here.

—
Brad Duncan
brad [at] malware-traffic-analysis.net

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