I wrote about my new oledump plugin plugin_msi_info that analyzes MSI files (MSI files are OLE files) in diary entry "oledump & MSI Files".

I have a new release that brings some changes to the output.

Let me illustrate with this sample from MalwareBazaar:

At the end of the report (Remaining streams), I've added an indicator.

! indicates PE files and CAB files.

? indicates files that are not images (PNG, JPEG, BMP), neither PE or CAB files.

In this example, a SVG file (image) is marked with indicator ?.

I parse CAB files to list their content.

And you can change the hash algorithm with environment variable DSS_DEFAULT_HASH_ALGORITHMS.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Over the years I have found grep to be very versatile. The most common use of grep is to find if the logs have a string that match an IP address, a domain, a service or protocol, some application was logged, etc.

Years ago, when I initially built my first DNS Sinkhole [1], I used several combination of grep to parse and compare files to build the bind lists of domains to sinkhole. I now use Pi-Hole [2] which uses the same principals which is now managed via its interface.

My early sinkhole used a series of grep commands to compare two files. The following example use a wildcard list of country codes that were already blocked by the sinkhole against a list of known bad domains published on various websites [3]. To demonstrate how to use a list to compare and remove the blocked domains, I will use my pi-hole domain list.

First step is to create the file the filter list called; toremove, which contains the following blocked top-level domains that are already blocked (it could be as many as the organization need). Another list could be applied for domains already blocked (i.e. google.com, sans.isc):

.*\.bazar
.*\.biz
.*\xyz

Before we start, lest get a count of how may lines we have the file list.2.pihole.xxxx.ca.domains with wc -l to establish a baseline:

This picture shows there is 505196 records in this file. The options use with grep are as follow:

• w - Select only those lines containing matches that form whole words.
• h - Suppress the prefixing of file names on output.
• v - Invert the sense of matching, to select non-matching lines.
• f - Obtain patterns from FILE, one per line.

The next step is to compare the top-level domain list against a downloaded domain list:

grep -whvf /root/toremove list.2.pihole.xxxx.ca.domains

This picture shows when grep was first run with the result above the command. Re-run of the same command and this time grepping for any domains ending with .xyz$ have been removed from the list. The $ at the end of xyz is to indicate the 'end of the line'.

Let’s recheck what we have left after removing the 3 top-domains from the list:

We now have 375686 domains left in the list. The command removed 129510 records.

Windows findstr

It is possible to repeat the same search using Windows findstr. Lest list the options used to filter the file:

• /v - Prints only lines that don't contain a match.
• /g:filename - Gets search strings from the specified file.

This is how to do it:

findstr /v /g:toremove list.2.pihole.xxxx.ca.domains | findstr .xyz$

This is the options used with find (find /?) to count the number of lines left:

• /V - Displays all lines NOT containing the specified string.
• /C - Displays only the count of lines containing the string.
• "" - Specifies the text string to find.

Let’s recheck to confirm that findstr (findstr /?) remove the 3 top-domains from the list:

findstr /v /g:toremove list.2.pihole.xxxx.ca.domains | find /v /c ""

This output the same result as grep: 375686 domains left in the list. The command removed 129510 records.

This highlight the versality of both of these tools to work through large amout of data quickly and still obtain the same result. This is another example of Living Off the Land Binaries (LOLBins).

[1] https://www.sans.org/white-papers/33523/
[2] https://pi-hole.net/
[3] https://raw.githubusercontent.com/jonschipp/mal-dnssearch/master/mandiant_apt1.dns
[4] https://isc.sans.edu/diary/Linux+LOLBins+Applications+Available+in+Windows/29296

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

In my last Diary[1], I shortly mentioned the need for correctly set Content Security Policy and/or the obsolete[2] X-Frame-Options HTTP security headers (not just) in order to prevent phishing pages, which overlay a fake login prompt over a legitimate website, from functioning correctly. Or, to be more specific, to prevent them from dynamically loading a legitimate page in an iframe under the fake login prompt, since this makes such phishing websites look much less like a legitimate login page and thus much less effective.

Discussion of the aforementioned headers has led me to a question of how common use of these headers is and how they are commonly set. Which is what we will take a short look at today.

Although data about general trends in the use of these headers may be found online[3,4], I wanted to go a little bit more in-depth. I have therefore written a short Python script, which would go through the current Tranco list of one million most popular domains[5] and gather data about which HTTP security-related headers were used on each one (provided the domains pointed to a HTTP server).

In total, the script gathered data about 21 different headers (e.g., X-XSS-Protection, Strict-Transport-Security, Cross-Origin-Resource-Policy, etc.) and their specific settings. Since results for the other headers might be interesting as well, I might write another diary discussing those once I’ve had more time to go over the data. For now, however, let us take a look at how common the use of the two headers which may be used to set restrictions for embedding a websites in an iframe or other object is. Specifically, we will look at the use of X-Frame-Options header and the use of CSP policies containing the frame-ancestors directive (since CSP doesn’t block the behavior we are interested in – the so called “framing attacks” – without this directive in place, we will only focus on CSP headers in which the directive is present).

As you may see from the following chart, at the time of writing, over 27.1% of the top 1000 most popular domains according to the Tranco list used either one or both of the aforementioned headers to prevent embedding of their content on undesirable domains. Of the top 100k domains, it was however only 20.6% and of the top 1 million domains, it was only a little more than 14.4%.

On the following charts, you may see how different X-Frame-Options and CSP frame-ancestors directives were represented in different sample sizes.

From the available data, it appears that while the X-Frame-Options HTTP header is used on more than 13.84% of the top 1 million domains, CSP with the frame-ancestors directive is set only by 1.91% web servers hosted on such domains.

Since one can reasonably assume that the domains listed on the Tranco list would have above-average, or at least average security measures in place, it would seem that when it comes to protecting us from framing attacks (and from the aforementioned phishing pages which take advantage of them), the deprecated X-Frame-Options header is still the most commonly used mechanism on the internet... Which is supported even by results from Shodan[6,7], which, at the time of writing, detected X-Frame-Options header on more than 41 million public IPs and CSP with the frame-ancestors directive only on approximately 12 million IPs.

[1] https://isc.sans.edu/forums/diary/IPFS+phishing+and+the+need+for+correctly+set+HTTP+security+headers/29638/
[2] https://w3c.github.io/webappsec-csp/#frame-ancestors-and-frame-options
[3] https://trends.builtwith.com/docinfo/X-Frame-Options
[4] https://trends.builtwith.com/docinfo/Content-Security-Policy
[5] https://tranco-list.eu/
[6] https://www.shodan.io/search?query=HTTP+%22x-frame-options%22
[7] https://www.shodan.io/search?query=HTTP+%22content-security-policy%22+%22frame-ancestors%22

-----------
Jan Kopriva
@jk0pr
Nettles Consulting

Overview

On March 29, a massive supply chain compromise in 3CX software resulted in malware being installed globally across multiple industries. It is similar to the other high-profile supply chain attacks (like SolarWinds and Kaseya) in that rather than targeting a single organization, the criminals target a popular service or software provided to many large organizations. With one single compromise of the supplier, dozens and potentially hundreds of organizations may fall in turn.

Trustwave is diligently monitoring the situation for exposure and associated attacks and will provide updates here as we have them.

In this case, the supplier is 3CX, a software company that makes a very popular VOIP software phone system. These 3CX software phones are very popular and by 3CX’s own count they service over 600,000 companies globally and more than 12 million users daily. Their client list contains dozens of highly recognizable corporate entities.

Affected Versions

The trojanized binary affects both Electron Windows App (versions 18.12.407 & 18.12.416) as well as Electron Mac App (versions 18.11.1213, 18.12.402, 18.12.407 & 18.12.416). Users that either installed an update (Update 7) or installed a fresh instance of these versions may be affected. As of March 30, Shodan shows close to a quarter of a million publicly exposed 3CX management systems.

Figure 1: Shodan results for publicly exposed 3CX management systems

The full attack results in an Infostealer strain of malware on the victim system via a trojanized DLL.

Attack Chain

Upon installing either the full software (via MSI) or the update (Update 7), the software will load ffmpeg.dll which, in turn, will sideload d3dcompiler_47.dll. ffmpeg.dll is then used to extract and decrypt the second stage malware from d3dcompiler_47.dll. That second stage malware is encrypted using RC4 with a static key of "3jB(2bsG#@c7", which many organizations have pointed to as a common static key used in other malware attributed to North Korean (DPRK) state sponsored threat actors.

The second stage malware will then wait seven days before attempting to download one of sixteen Windows icon files (.ICO) from a public GitHub repository (already taken down). These fully functional icon files have a base64 string appended to the end of the file which provides the malware with the URI for its C2 server. At least one of the icons was originally uploaded to GitHub on 7.Dec.2022.

After connecting to the C2 server defined in the .ICO file, the final malware stage will be downloaded to the victim system. This final stage is a novel, previously unseen Infostealer. The Infostealer grabs standard system info and browsing history from Chrome, Edge, Brave, and Firefox browsers. 

Remediation

3CX is currently working on an update to patch the malicious code. In the meantime, 3CX recommends that users uninstall any current version and switch to the unaffected 3CX Progressive Web App (PWA) version of its software.

Attribution

Several organizations attribute this attack to North Korea (DPRK), specifically Lazarus or a sub-organization of that group. Trustwave has not confirmed any attribution at this time.

IOCs

Windows Hashes

3CXDesktopapp-18.12.407.msi

Hash Type	Hash
SHA256	aa124a4b4df12b34e74ee7f6c683b2ebec4ce9a8edcf9be345823b4fdcf5d868
SHA1	bea77d1e59cf18dce22ad9a2fad52948fd7a9efa
MD5	f3d4144860ca10ba60f7ef4d176cc736

3CXDesktopApp.exe (v18.12.407)

Hash Type	Hash
SHA256	dde03348075512796241389dfea5560c20a3d2a2eac95c894e7bbed5e85a0acc
SHA1	6285ffb5f98d35cd98e78d48b63a05af6e4e4dea
MD5	bb915073385dd16a846dfa318afa3c19

3CXDesktopApp.exe (v18.12.407) Additional Hashes

Hash Type	Hash
SHA256	54004dfaa48ca5fa91e3304fb99559a2395301c570026450882d6aad89132a02
SHA1	480dc408ef50be69ebcf84b95750f7e93a8a1859
MD5	08d79e1fffa244cc0dc61f7d2036aca9

3CXDesktopApp-18.12.416.msi

Hash Type	Hash
SHA256	59e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983
SHA1	bfecb8ce89a312d2ef4afc64a63847ae11c6f69e
MD5	0eeb1c0133eb4d571178b2d9d14ce3e9

3CXDesktopApp.exe (v18.12.416)

Hash Type	Hash
SHA256	fad482ded2e25ce9e1dd3d3ecc3227af714bdfbbde04347dbc1b21d6a3670405
SHA1	8433a94aedb6380ac8d4610af643fb0e5220c5cb
MD5	9833a4779b69b38e3e51f04e395674c6

3CXDesktopApp.exe (v18.12.416) Additional Hashes

Hash Type	Hash
SHA256	a60a61bf844bc181d4540c9fac53203250a982e7c3ad6153869f01e19cc36203
SHA1	413d9cbfcbf8d1e8304eab0aa5484f5eec5185f5
MD5	704db9184700481a56e5100fb56496ce

 ffmpeg.dll

Hash Type	Hash
SHA256	7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896
SHA1	bf939c9c261d27ee7bb92325cc588624fca75429
MD5	74bc2d0b6680faa1a5a76b27e5479cbc

 d3dcompiler_47.dll

Hash Type	Hash
SHA256	11be1803e2e307b647a8a7e02d128335c448ff741bf06bf52b332e0bbf423b03
SHA1	20d554a80d759c50d6537dd7097fed84dd258b3e
MD5	82187ad3f0c6c225e2fba0c867280cc9

 Final stage Infostealer malware

Hash Type	Hash
SHA256	8ab3a5eaaf8c296080fadf56b265194681d7da5da7c02562953a4cb60e147423
SHA1	3b3e778b647371262120a523eb873c20bb82beaf
MD5	7faea2b01796b80d180399040bb69835

MacOS Hashes

3CXDesktopApp-18.11.1213.dmg

Hash Type	Hash
SHA256	5407cda7d3a75e7b1e030b1f33337a56f293578ffa8b3ae19c671051ed314290
SHA1	19f4036f5cd91c5fc411afc4359e32f90caddaac
MD5	5729fb29e3a7a90d2528e3357bd15a4b

3CXDesktopApp.app (v18.11.1213)

Hash Type	Hash
SHA256	92005051ae314d61074ed94a52e76b1c3e21e7f0e8c1d1fdd497a006ce45fa61
SHA1	5d833bcc679db38a45111269e727ec58b75c8d31
MD5	3703770e32820397c6e7e1e1221e6d0d

 3CXDesktopapp-latest.dmg (v18.12.416)

Hash Type	Hash
SHA256	e6bbc33815b9f20b0cf832d7401dd893fbc467c800728b5891336706da0dbcec
SHA1	3dc840d32ce86cebf657b17cef62814646ba8e98
MD5	d5101c3b86d973a848ab7ed79cd11e5a

 3CXDesktopApp.app (v18.12.416)

Hash Type	Hash
SHA256	b86c695822013483fa4e2dfdf712c5ee777d7b99cbad8c2fa2274b133481eadb
SHA1	f3487a1324f4c11b35504751a5527bc60eb95382
MD5	ca8c0385ce2b8bdd19423c8b98a5924b

 libffmpeg.dylib

Hash Type	Hash
SHA256	a64fa9f1c76457ecc58402142a8728ce34ccba378c17318b3340083eeb7acc67
SHA1	769383fc65d1386dd141c960c9970114547da0c2
MD5	660ea9b8205fbd2da59fefd26ae5115c

C2 Domains

(NOTE: These Domains have been taken down, but existing infected systems may still try to reach out to these hosts)

akamaicontainer[.]com

msedgepackageinfo[.]com

akamaitechcloudservices[.]com

msstorageazure[.]com

azuredeploystore[.]com

msstorageboxes[.]com

azureonlinecloud[.]com

officeaddons[.]com

azureonlinestorage[.]com

officestoragebox[.]com

dunamistrd[.]com

pbxcloudeservices[.]com

glcloudservice[.]com

pbxphonenetwork[.]com

qwepoi123098[.]com

zacharryblogs[.]com

sbmsa[.]wiki

pbxsources[.]com

sourceslabs[.]com

journalide[.]org

visualstudiofactory[.]com

C2 URIs

https[:]//www.3cx[.]com/blog/event-trainings/

https[:]//github[.]com/IconStorages/images

https[:]//raw[.]githubusercontent[.]com/IconStorages/images/main/icon%d.ico

https[:]//akamaitechcloudservices[.]com/v2/storage

https[:]//azureonlinestorage[.]com/azure/storage

https[:]//msedgepackageinfo[.]com/microsoft-edge

https[:]//glcloudservice[.]com/v1/console

https[:]//pbxsources[.]com/exchange

https[:]//msstorageazure[.]com/window

https[:]//officestoragebox[.]com/api/session

https[:]//visualstudiofactory[.]com/workload

https[:]//azuredeploystore[.]com/cloud/services

https[:]//msstorageboxes[.]com/office

https[:]//officeaddons[.]com/technologies

https[:]//sourceslabs[.]com/downloads

https[:]//zacharryblogs[.]com/feed

https[:]//pbxcloudeservices[.]com/phonesystem

https[:]//pbxphonenetwork[.]com/voip

https[:]//msedgeupdate[.]net/Windows

https[:]//msedge[.]com/Windows

https[:]//sbmsa[.]wiki/blog/_insert

References

3CX Alert: https://www.3cx.com/blog/news/desktopapp-security-alert/

3CX Remediation: https://www.3cx.com/blog/news/desktopapp-security-alert-updates/