Archive for July, 2019

Targeted Phishing Attacks in the Financial Industry: Fire-3 Phishing Kit, (Wed, Jul 31st)

[Thanks to Justin Trujillo (Cyber Security Analyst) from loanDepot for alerting us of this particular incident, and for co-authoring this article]

Financial companies are heavily targeted with various more or less targeted phishing attempts. The attacks are often trying to collect e-mail credentials for business-email-compromise (BEC) attacks. The attacker will log in to the victim’s cloud-based email account to either add a “Forward” address or read the users e-mail. Once an email asking for payment instructions arrives, the attacker will respond with fake instructions.

It isn’t often that we not only get a hold of the email triggering the attack but also a copy of the full phishing kit used by the attacker.

The email, in this case, is very typical for this type of attack.

The from address used an existing domain name that was likely unrelated to the attack and spoofed. The domain uses a generic SPF record for Outlook 365, so it likely was a nice “From” domain to use and to slip past filters.

The victim, in this case, is a company providing home loans. Receiving documents from a title company is likely part of everyday business. In this case, the document is not attached to the email. Instead, it claims to be reachable via a cloud storage service. Clicking on the link leads to a lookalike “Box” page:

The page offers logins for pretty much any major cloud-based email service. The logins are done pretty well. Here is the Office 365 version of the login:

In a lucky break for us, the attacker made a mistake this time around. The landing page didn’t work correctly.

These are classic PHP error messages, revealing the location of files. It appears that the directory the log file was supposed to be stored in was deleted and the PHP page did not properly handle the error. Taking things further and going back a directory, we can see what’s inside the index:

Looks like the “Attached-Docs/” file was the phishing landing page, but “” seemed out of place. “Parent Directory” just takes us back to the hacked website, but “” downloads an actual zip file. The zip file was password less, and that’s where we see that file name:

In Justin’s own words “I had seen this file reference pop up more times than I could count during phishing investigations. I opened the file and discovered the complete phishing kit. This kit included all the HTML, CSS, JavaScript and image files used for the phishing pages, as well as some PHP code.”

The fire-3 folder contains a few files of interest:

CONTROLS.php: Any credentials harvested are exfiltrated via email. This file includes the email address receiving the data: [email protected] . (I contacted the address for comment but didn’t receive any answer yet)

Includes/blacklist.dat: A list of blacklisted networks. This is the usual list of security company and cloud service IPs that are blocked from accessing the site. There is also an “unknown” IP section that suggests the attacker had been updated the list based on previous campaigns.

Includes/netcraft_check.php: This file checks the user agent to block access from Netcraft (not sure if that user agent is actually used by Netcraft).

assets/logs/ips.txt: Unfortunately, this file was blank due to broken functions, but any IP addresses and user agents are logged to this file in an access log like format.

It looks like we are not the first once to come across this phishkit. A tweet by IpNigh from about a week ago did point to the same email address used in this phish. However, the phishing page looked a bit different and the attacker attempted to impersonate Dropbox, not @IpNigh is a bot that will post phishing page information to Twitter.


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

Can You Spell 2FA? A Luno Phish Example, (Tue, Jul 30th)

This week, I am teaching our intrusion detection in depth class. Probably one of the more technical courses we have to offer, and it is fun to watch students in class getting the hang of “becoming one with the packet” and figuring out how all the bits and bytes align. A couple of doors down, one of my heroes, Doc Blackburn, is teaching probably one of our least technical classes: SEC301, Introduction to Cyber Security (don’t tell him: But we sometimes call it security kindergarten). But truth be told, he probably makes more of a difference than all of our fancy technical classes. One of the things he is teaching this week is what “two-factor authentication” (2FA) means. You may remember that from your introduction to cybersecurity: Something you know… something you own… something you are… pick two of them. [2]

So why am I telling you about this? Earlier today, I received a simple, pretty straight forward and reasonably well-done phish for the Luno cryptocurrency exchange:

The email hit the typical phishing marks, including the fake Avast notice at the bottom, promising it to be safe. The link leads to hxxps:// rebrand .ly/5xb0pv, a link shortener, which redirects to hxxps:// psd. The phishing page looked pretty good. Here is an image of the fake and the real login page:


The actual login page will offer an option to login via Google and Facebook. The phishing page doesn’t provide these options. Also, note that the phishing page copied the cute warning to verify the URL.

The page will ask for the information twice, claiming that it wasn’t entered correctly the first time. This is likely done to avoid typos, and maybe also to catch users that try to prevent phishing by first entering a wrong password to check if it is rejected. 

Next, the phishing page will ask for the password as well as for a one-time password code. Great! So Luno uses two-factor authentication? Does the phishing page intercept the authentication and do “something fancy”? No… wait a second.

After asking for your Luno credentials, the phishing page will ask you for your e-mail credentials and phone number. ok… Maybe to be able to reset your credentials?

So I went ahead and signed up for a Luno account. First, the password policy isn’t exactly “great.” “Password123” was accepted just fine. It never asked me to set up a second factor, so I figured that this is an optional step to be completed after I sign in. 

After verifying my email address, and signing in the first time, Luno announced that it would send a one-time password to my email address. Wait… didn’t I “give” my email address and password to a phisher? This is why they need it! Luno’s two-factor isn’t two-factor. All I need is a second password (your email password). 

Luno does offer an optional two-factor option that uses SMS. Probably why the phishing page asked for my phone number. However, it appears that this only enables sending the code via SMS in addition to e-mail, not instead of email, plus SMS should not be considered a “second factor” for high-value websites  [3]. I am not totally opposed to SMS as a second factor (the phone is becoming what “you have”), but only for lower-risk applications, not for financial sites.


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

Recognizing ZLIB Compression, (Mon, Jul 29th)

In diary entry “Analyzing Compressed PowerShell Scripts” and video “Video: Analyzing Compressed PowerShell Scripts” I show how to decompress ZLIB compressed data.

Let me share some more info on ZLIB compressed data. Compressing data with ZLIB is called deflating, and the algorithm is called DEFLATE.
When I compress the text “Hello, Hello, Hello, Hello” with Python’s ZLIB module, I obtain the following binary data (represented in hexadecimal): 789cf348cdc9c9d751f0c0a400745608b5.

This data is structured according to RFC 1950: the first byte (0x78 in this example) if known as CMF (Compression Method and Flags). This byte is very often equal to 0x78. The 4 least significant bits identify the compression method (8 is DEFLATE and 15 is reserved), the 4 most significant bits are used to encode the size of the window when the compression method is 8. This value is often 7 (32K window size).
0x78 is a lowercase letter x, so easy to recognize in an ASCII dump. So, if you encounter some high entropy data that starts with x (0x78), it might be ZLIB compressed data according to RFC 1950.

My tool can be used, with function ZlibD (ZLIB Decompression), to decompress this data:

There’s a second header byte after CMF: FLG (flags). And depending on these flags, there might be some more data, but usually, it’s the compressed data that follows. This is compressed with the DEFLATE algorithm, and is structured according to RFC 1951. can also decompress this data, using function ZlibRawD.

If you mix-up data format and functions, you get an error.
Inflating data with a header with function ZlibRawD produces this error:

And inflating data without a header with function ZlibD produces this error:

In my tool, I have some custom definitions to detect ZLIB compressed data (RFC1950):

If you see a byte sequence starting with 7801, 789C or 78DA, your best chance is to first to try to decompress it with ZlibD.

And GZIP? That’s RFC 1952. The content of a GZIP file looks like this:

The compressed data in this example is RFC 1951.

I’ll provide more details in an upcoming diary entry, but there are many tools to decompress GZIP files.


Didier Stevens
Senior handler
Microsoft MVP

(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...»