Blog

Archive for SANS

Ursnif infection with Dridex, (Tue, Dec 3rd)

Introduction

I frequently see indicators of malicious spam (malspam) pushing Ursnif malware.  Specifically, I often find Ursnif pushed by a long-running malspam campaign that uses password-protected zip attachments that contain word documents with macros designed to infected a vulnerable Windows host.  The password has usually been 777 for the zip attachments.  Word documents contained within those zip archives follow a specific naming convention.  For example, a Word document from this campaign on December 2nd would be named info_12_02.doc.

Today’s diary reviews an Ursnif infection from this campaign that I generated in my lab environment on Monday, December 2nd.

The malspam and initial infection

Malspam from this campaign is spoofing replies to emails found on infected Windows hosts in the wild.  Since these are possibly real people, I’ve redacted any sensitive information in the images below.  As I already described, these emails contain password-protected zip archives, and these zip archives contain Word documents with macros to install Ursnif on a vulnerable Windows host.  In this case, enabling macros on the Word document dropped a script file in the C:WindowsTemp directory, and the script file retrieved the initial Windows executable (EXE) file for Ursnif.


Shown above:  An example of malspam pushing Ursnif malware.


Shown above:  Opening a zip archive from this type of malspam requires a password stated in the email.


Shown above:  Microsoft Word document extracted from the attached zip archive.


Shown above:  Malware note on the infected Windows host after enabling macros.

The infection traffic

Traffic generated by Ursnif infections follows relatively consistent patterns.  During these type of Ursnif infections, we often find follow-up malware retrieved by the Ursnif-infected host.  In this case, it was Dridex.  The image below shows my Ursnif infection traffic filtered in Wireshark, and it highlights the URL that returned the initial Ursnif EXE.


Shown above:  Traffic from an infection filtered in Wireshark, highlighting the URL that returned the initial Ursnif EXE.


Shown above:  Later in the infection traffic, we see indicators of the victim host being infected with Dridex.

Post-infection forensics

Ursnif makes itself persistent through the Windows registry, where it copies itself and deletes the initial Ursnif EXE.  Dridex is made persistent through DLL files that are called by legitimate system files copied to randomly-named directories established during the Dridex infection process.  Dridex is made persistent through the Windows registry, a scheduled task, and a Windows shortcut in the Startup menu.


Shown above:  Ursnif persistent on my infected Windows host.


Shown above:  Dridex persistent as DLL file called by the Windows registry.


Shown above:  Dridex was also persistent through a DLL file called by a scheduled task.


Shown above:  Dridex also persistent as a DLL called by a Windows shortcut in the Startup folder.

Indicators of Compromise (IoCs)

URL that retrieved initial Windows executable file for Ursnif:

  • 188.120.241[.]200 port 80 – ragenommad[.]com – GET /edgron/siloft.php?l=utowen4.cab

URLs generated by initial Windows executable file for Ursnif:

  • 23.202.231[.]167 port 80 – nxbpierrecjf[.]com – GET /images/[long string].avi
  • 23.202.231[.]167 port 80 – spt71igina[.]com – GET /images/[long string].avi
  • 109.196.164[.]8 port 80 – jyomacktom[.]top – GET /images/[long string].avi

Post-infection traffic after Ursnif has established persistence:

  • 194.61.1[.]178 port 443 – m38kxy54t[.]com – HTTPS/SSL/TLS traffic generated by Ursnif

URLs generated by Ursnif-infected host to obtain follow-up malware:

  • 77.93.211[.]211 port 80 – zontcentrum[.]ru – GET /wp-content/uploads/2019/11/2unovarios.rar
  • 77.93.211[.]211 port 80 – zontcentrum[.]ru – GET /wp-content/uploads/2019/11/unovarios.rar

Post-infection traffic caused by Dridex:

  • 5.134.119[.]57 port 443 – HTTPS/SSL/TLS traffic generated by Dridex
  • 89.100.104[.]62 port 3443 – HTTPS/SSL/TLS traffic generated by Dridex

Malware and artifacts

SHA256 hash: ac13e6f727b207384d24ce3ac710f5bfa507ea8f906136b03745a030050905c5

  • File size: 57,450 bytes
  • File name: [name redacted].zip
  • File description: password-protected zip archive from malspam (password: 777)

SHA256 hash: 57d7f95629d7c1e0025043dc05ff1c859bb79a1616a7c4296a6ec23b27ee49cd

  • File size: 63,466 bytes
  • File name: info_12_02.doc
  • File description: Word doc with macro for Ursnif

SHA256 hash: d329921115fa57c30ba54e8b697658839918ac2e915c0274f2dc9028f7b9db88

  • File size: 238,080 bytes
  • File location: hxxp://ragenommad[.]com/edgron/siloft.php?l=utowen4.cab
  • File location: C:WindowsTempainJ45.exe
  • File description: Initial Ursnif EXE retrieved after enabling Word macro

SHA256 hash: 52acd832d2036fc326743e63b2a50615be9a6e04d0b4f06e0e8d0e681bf78c9f

  • File size: 495,616 bytes
  • File location: C:Windowssystem3241ftQHUxTheme.dll
  • File description: Dridex DLL persistent on the infected Windows host (1 of 3)

SHA256 hash: 4dcb69610bd18e00449dccb8a31f13e84fc348a242fe98cd2b4681040453fe72

  • File size: 499,712 bytes
  • File location: C:Users[username]AppDataRoamingJC85wnMFPlat.DLL
  • File description: Dridex DLL persistent on the infected Windows host (2 of 3)

SHA256 hash: 896fe4ae5367929ba7a48221f95d52d7795f614958c4cc1c4c7beeca4cc6b92a

  • File size: 491,520 bytes
  • File location: C:Users[username]AppDataRoamingL3CfQGVERSION.dll
  • File description: Dridex DLL persistent on the infected Windows host (3 of 3)

Final words

A pcap of the infection traffic and the associate malware 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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Next up, what's up with TCP port 26?, (Mon, Dec 2nd)

Whenever I sign up for another shift, if I don’t already have a diary topic in mind, I take a look at the top 10 ports in the dashboard when I login to isc.sans.edu. For the last few weeks, I’ve noticed %%port:26%% showing up, so I decided to see if I could figure out what was going on there.

In this case much of the top 10 is stuff to be expected, port 445 is perpetually near or at the top of this chart (please don’t leave it open to the internet), port 23 has been there since Mirai first hit more than 3 years ago, 80 and 8080 are web servers and proxies, port 22 (ssh) is not at all unusual, port 5555 is the Android Debug Bridge which has been popular for a few months, but that port 26 just is really strange and it is sitting at number 5. So, let’s take a look at the last year of port 26 traffic and see what we can see.

Okay, with the exception of a brief spike in targets last January, there was hardly any traffic on port 26 until September and even then, the number of sources was very small until about the second week of November. So what are they looking for? Well, there is no service officially assigned that port by IANA, so my next thought was to take a look at Shodan and see, what tends to be running there. A quick look there suggests that port 26 is most often used as an alternate SMTP port.

Okay, I suppose there might be reasons for that, you often find web servers running on port 81, so why not SMTP on port 26? In fact, most often it is Exim which has had a couple of vulnerabilities lately. Most recently, a remote code execution vulnerability in September. So, maybe the attackers are looking for vulnerable Exim servers. Now that I have an hypothesis, it is time to test it. A few weeks ago, when I noticed the increase in traffic on %%port:853%%, I wasn’t able to setup a honeypot before my shift to try to capture some of the traffic, but this time, since I actually noticed this several weeks ago and signed up for the shift last week, I figured I should actually capture some of the traffic to test my hypothesis. I decided to try out fellow handler, Didier Steven’s tcp-honeypot (something I’ve been meaning to play with for months). So, I set it up on a couple of VPSen that I have scattered around and… things didn’t work. So, I talked to Didier and discovered that despite the comments in the code to the contrary, the version currently in github (as of 30 Dec 2019 anyway) did not, in fact, work with Python 3. Oops, he’ll get that straightened out shortly. Fortunately, it worked with Python 2 (>= 2.7.12, anyway, didn’t seem to work with 2.7.8). Okay, that allowed me to fire up several honeypots scattered around where I figured they would get scanned. I copied the config for port 25 and modified it to send back the Exim banners that I saw on Shodan, like these 

And… I didn’t get (much) SMTP scanning. In fact, I got exactly 1 SMTP probe, 2 SSH probes (from the connection string, it looks like python scripts using paramiko) and lots and lots of apparent telnet connections (IPs obscured to protect the guilty).

I’m not sure what this tells us. There must be some devices out there that are running telnet (or similar) on port 26 because there is a whole lot of scanning and brute force password guessing going on there, but apparently it isn’t attempting to take advantage of and Exim RCE vulnerabilities. If any of our dear readers know what they are actually looking for, I’d love to hear about it, you can let us know in the comments below, via e-mail, or via our contact page, Now that I see it is apparently telnet, I’m very tempted to put up a cowrie instance and see what they do once they get in, but I’ll save that for a weekend where I don’t have other stuff going on.

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

ISC Snapshot: Search with SauronEye, (Fri, Nov 29th)

SauronEye is a search tool built to aid red teams in finding files containing specific keywords.

If you’ve ever conducted a penetration test or a red/purples team engagement, you’ve been there. You’re staring at the target agency’s SharePoints and file shares and have recognized the bloody gold mine of pwnzorship it represents. Yet, as well we know, the search features in these scenarios are less than optimal. Maybe you’ve written scripts to help with this and batched up something useful, or cranked it out in PowerShell. @_vivami’s SauronEye is here to help. SauronEye is a “search tool to find specific files containing specific words, i.e. files containing passwords.”

SauronEye features, as cited from it’s GitHub page, include search of:
– multiple (network) drives
– contents of files
– contents of Microsoft Office files (.doc, .docx, .xls, .xlsx)
– multiple drives multi-threaded for increased performance
…and support for regular expressions in search keywords. Note too that SauronEye does not search %WINDIR% and %APPDATA%. Use the -SystemDirs flag to search the contents of Program Files*. SauronEye relies on multi-threading libraries only available from .NET 4.0 and later. SauronEye is a source package, you’ll need to roll your own here. I’ll assume you already have Visual Studio Community, here’s a quick build walkthrough. I work out of my C:coding directory. In Visual Studio Community, click Clone or check out code, and give it you local path and the .git URL for SauronEye (Figure 1).

Figure 1

Figure 1: Clone SauronEye source

In Solution Explorer navigate to SauronEye.sln and open it.
In Solution Configuratons, switch from Debug to Release.
Click Build and select Build Solution.

Figure 2

Figure 2: Build SauronEye

That’s it, the resulting binary will be found in C:codingSauronEyesrcSauronEyebinRelease.

The working scenario/user case here is again one that should be very familiar to red teamers and adversaries alike. I have NEVER assessed an organization where I didn’t find information and data stored on SharePoint or file shares that enabled either the compromise of individuals or systems, or both. Password files, sensitive PII, private keys, configuration strings, you name it, you’ll find it. It is here where SauronEye shines.
To validate SauronEye’s efficacy I planted a few files throughout my file directory. These included a SQL connection string in DocumentsCache, 500 really bad passwords in a text file on my Desktop, a PII file with SSNs in Documents, and 1000 test credit card numbers in Downloads. I ran SauronEye as follows:

C:codingSauronEyesrcSauronEyebinRelease>SauronEye.exe -Dirs C:Usersrmcree -Keywords password, connection, ssn, card* -Filetypes txt, .xls, .xlsx, .conf -Contents > results.txt

SauronEye immediately landed relevant file paths, then moved on to content:

	 === SauronEye === 

Directories to search: c:usersrmcree
For file types: .txt, .xls, .xlsx, .conf
Containing: password, connection, ssn
Search contents: True
Search Program Files directories: False

Searching in parallel: c:usersrmcree
[+] c:usersrmcreeAppDataLocalMicrosoftWindowsFileHistoryData613CUsersrmcreeDocumentscacheSQLconnection.txt
[+] c:usersrmcreeDesktop500-worst-passwords.txt
[+] c:usersrmcreeDocumentscacheSQLconnection.conf
[*] Done searching file system, now searching contents

Content discovered from my planted files included the SQL connection string:

[+] c:usersrmcreeAppDataLocalMicrosoftWindowsFileHistoryData613CUsersrmcreeDocumentscacheSQLconnection.txt: 
	 Server=Pwn3dSQLServerPwnM3;Database=IMPWN3D;User Id=ImaDumass;Password=123456;

Results from the 500 worst passwords are seen in Figure 3.

Figure 3

Figure 3: SauronEye finds really bad passwords

Customer PII is uncovered in Figure 4.

Figure 4: SauronEye reveals PII

From the 1000 credit card records:

[+] c:usersrmcreeDownloads1000_CC-Records.xlsx: 
	 Jefferson Trina A Carroll Jason K Bray Denny

This is a project to watch, and definitely one to try out during your next red team engagement, penetration test, or audit/assessment. It’s guaranteed you’ll find useful results. Please use SauronEye responsibly. Vincent is committed to this project, was immediately responsive to a bug query, and deployed a fix in less than 24 hours. Please support him with bug reports, feature requests, or pull requests.

Cheers…until next time.

Russ McRee | @holisticinfosec

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

Finding an Agent Tesla malware sample, (Wed, Nov 27th)

I was browsing through the Any Run sandbox looking through the public submissions of malware with pcaps of infection traffic from Tuesday 2019-11-26.  I found this one, and it’s tagged agentteslaAgent Tesla is an information stealer.  Based on the file name, this Agent Tesla malware sample may have been disguised as an installer for Discord.


Shown above:  The Agent Tesla malware sample I found on Any.Run.

I retrieved the pcap from Any.Run’s analysis of this malware sample, so I could review the traffic.  Agent Tesla sends an email containing information from the victim’s Window host.  In many cases, email traffic generated by Agent Tesla is encrypted SMTP, but sometimes the post-infection SMTP traffic is unencrypted.  Luckily, this example was unencrypted SMTP.


Shown above:  Getting the pcap from analysis of the malware sample.


Shown above:  Filtering on the pcap in Wireshark and finding the TCP stream to follow for the SMTP traffic (over TCP port 587).


Shown above:  TCP stream showing unencrypte SMTP traffic caused by this sample of Agent Tesla.

As shown in the image above, this sample of Agent Tesla malware exfiltrated stolen data to the email address [email protected].  I’ve filtered out what would normally be sensitive data in the above image, so if you’re curious, you can review the pcap (here’s a link again for the analysis page) and discover for yourself.


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Lessons learned from playing a willing phish, (Tue, Nov 26th)

Replying to phishing e-mails can lead to some interesting experiences (besides falling for the scams they offer, that is). Since it doesn’t require a deep technical know-how or any special expertise, it is something I recommend everyone to try out at least once, as it can lead to some funny moments and show us that the phishing trade doesn’t always operate in the way we might expect it to.

When it comes to phishing e-mails, unless they are successful, highly targeted, or part of a larger attack pattern of a single threat actor, most of us tend to just delete the messages and quickly forget them. But sometimes it can be quite instructive to bait the phishers and play a potential victim of the scam they thought up. Although most of us won’t be able to come close to making the attacker join our fictitious religion and send us his photograph with his breast is painted red, along with a sum of money[1], the experience can still be quite interesting and teach us a lot.

If you chose to bait phishing attackers, it is advisable not to do so from your own e-mail account but use another one – ideally a “burner” account you don’t mind losing. This brings us to one of the first things pretty much anyone who tries to bait phishers learns – unless it’s a targeted attack, the scammers don’t (for obvious reasons) check whether the e-mail address they receive a reply from was part of the list of addresses they originally send the phishing to.

If we reply to a phishing e-mail within a couple of days after receiving it, chances are that phishers will get in touch with us. Phishing messages usually ask us (again, for obvious reasons) to reply to a different address than the one we (seemingly) received it from. For run of the mill phishing attacks, most threat actors stop (or are forced to stop) using any e-mail addresses associated with a phishing campaign fairly quickly, although this is not always the case. The campaign which prompted me to write this diary actually surprised me very much in this regard. And, since it was otherwise quite “normal”, we’ll use it as an example of how phishing campaigns may progress.

It started all the way back in August with an e-mail in which the author, claiming to be an attorney of a recently deceased wealthy man, promised me untold riches if I act as a relative of the deceased in order to get his vast fortune as an inheritance. It contained the following text in both English and Spanish.

From: Ike Kekeli  
To: undisclosed-recipients:;
Subject: Hi ,
Date: 13 Aug 2019 17:29 (GMT +02:00)

Hi,

Firstly, let me identify myself without any intention of equivocation
on this business opportunity to you my name is Ike Kekeli , A
Fiduciary bank Attorney At Law ?s wish to know if we can work
together. I would like you to stand as the surviving beneficiary to my
deceased client ( Mr . Gilbert ) who made some deposit of $7.9 Million
Dollars to be transferred to any possible safe account with your good
assistance.

He died without leaving any WILL and any registered next of kin and as
such the funds now have an open beneficiary mandate. Kindly get in
touch with me through my email address ( barristerikek  gmail.com ) for
more guidelines to the repatriation of this fund.

Regards,
Attorney Ike Kekeli . ( Esq )

 

I only noticed the e-mail when I was going through my phishing quarantine nearly two weeks after it was delivered and although the e-mail wasn’t special in any way (this sort of lure is quite common in phishing), and I wasn’t holding much hope with regards to the address still being active, I decided to reply. The reaction from the attackers didn’t take long – within 10 minutes, I had another e-mail in my inbox, this time asking me for my personal information. Although this sort of reaction time puts even many professional support teams to shame, it is actually not uncommon for phishers to reply to their potential victims very quickly. Sometimes, it might take a day or two to get a reply back, but in many other cases (especially in cases of BECs), five or ten minutes may be more than enough time.

After exchanging couple of messages with “attorney Ike”, he sent me couple of forms pre-filled with the personal information I’ve provided earlier and asked me to send these to a “bank” – a different e-mail address used by the attackers. This is another quite common technique used by malicious actors as it lends the scam much more credibility if multiple “trustworthy” parties seem to be involved. The reply from the bank contained a spectacularly looking letter in a PDF from the “bank president” asking me for a copy of my ID card.

 

Sending the phishers a document can be a good way to determine their external IP address – I send the “bank” a TinyUrl link which redirected a visitor to my logger script, which, after saving the IP address of the visitor and some additional information, redirected them to what seemed to be a corrupted JPEG file. Since most phishers don’t have a high level of technical expertise or security awareness, they tend to click pretty much anything one sends them, so it didn’t take long to get a hit on the logger script and determine where the attackers were from.

The “bank” afterwards asked me to send in a filled in form with my personal information and a photo. I’m the first to admit that I can be a bit juvenile in such cases – I usually pick one of the more famous actors out there, as you may see bellow, and see whether I get any interesting reaction from the phishers. Although it is surprising, they usually don’t notice it.

It was at this point that both “Ike” and the “bank” started to ask for money – since the “bank” sent me an account number to transfer the money to (account in a different bank, then the one they were acting as, of course), I contacted the real bank with the account information and after exchanging couple of additional messages broke off the contact with the scammers. Getting the account number and providing it to the bank which hosts the account is usually the most one can do in such cases, without straying outside the reasonable ethical boundaries. It took about two weeks for the phishers to give up after I stopped responding at the beginning of September.

The most interesting part of this phishing campaign came only last week, when I received a new message from “Ike”, promising me a reward for helping him although the deal didn’t work out. That is not so unusual, what is – at least in my experience – quite unique is that the message was sent from the same e-mail address the attackers used during our original interaction.

And this is, so far, the last lesson which interacting with phishers has taught me – although I would have expected that any e-mail address used for phishing could not stay active for so long, there are some (or certainly at least one) which have been used for more than a quarter of a year and are still being actively used.

[1] https://419eater.com/html/joe_eboh.htm

———–

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

My Little DoH Setup, (Mon, Nov 25th)

“DoH”[1], this 3-letters acronym is a buzzword on the Internet in 2019! It has been implemented in Firefox, Microsoft announced that Windows will support it soon. They are pro & con about encrypting DNS requests in  HTTPS but it’s not the goal of this diary to restart the debate. In a previous diary, he explained how to prevent DoH to be used by Firefox[2] but, this time, I’ll play on the other side and explain to you how to implement it in a way to keep control of your DNS traffic (read: how to keep an eye on DNS request performed by users and systems). For a while, I had the idea to test a DoH configuration but I had some requirements:

  • It must be transparent for users
  • DNS requests must be logged (who resolved which domain and when)
  • Local DNS zones like ‘lab.domain.tld’ or ‘iot.domain.tld’ must be supported (resolved via a local bind instance)
  • Users are protected via a PiHole[3] (against advertisements & malicious domains)
  • Integration with 3rd party tools

This weekend, I decided to reconfigure my network. Here is my current setup:

Endpoints (laptops, tablets, phones, visitors, etc) are using a PiHole instance (provided via DHCP) from their VLAN. Servers are using the normal Bind instance. PiHole forwards the allowed DNS requests to Bind. It is master and can resolve RFC1918 addresses from local zones (ex: *.lab.domain.tld). If the FQDN is unknown, it is forwarded to a local cloudflared[4] daemon via UDP/5353 that used DoH to resolve public names. To keep an eye on DNS requests, PiHole and Bind send their logs to my SIEM for further processing and reporting/alerting.

From a setup point of view, everything is running in Docker containers and, to increase my detection capabilities, my MISP instance is feeding PiHole and Bind with a daily export of malicious domains[5]. Let’s see how it works in the coming days…

[1] https://en.wikipedia.org/wiki/DNS_over_HTTPS
[2] https://isc.sans.edu/forums/diary/Blocking+Firefox+DoH+with+Bind/25316
[3] https://pi-hole.net/
[4] https://github.com/cloudflare/cloudflared
[5] https://isc.sans.edu/forums/diary/DNS+Firewalling+with+MISP/24556

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) →
Page 3 of 312 12345...»