You know those ads hawking bogus brain pills? Security researchers just helped take out a bunch of the spammers behind them.

Nick Biasini and Edmund Brumaghin authored this blog post with contributions from Andrew Williams.

Introduction to JasperLoader

Malware loaders are playing an increasingly important role in malware distribution. They give adversaries the ability to gain an initial foothold on a system and are typically used to deliver various malware payloads following successful compromise. These attacks are popping up more frequently, as we covered in July with Smoke Loader and Brushaloader earlier this year. Loaders allow attackers to decide which malware to drop based on how they feel they can best monetize the access they gained. While malware loaders are commonly seen with email-based threats, they have also been prevalent within the exploit kit landscape for years. Recently, Cisco Talos observed an increase in loader activity being used to deliver various malware to systems located in various European countries.

Specifically, we're tracking a loader known as "JasperLoader," which has been increasingly active over the past few months and is currently being distributed via malicious spam campaigns primarily targeting central European countries with a particular focus on Germany and Italy. JasperLoader employs a multi-stage infection process that features several obfuscation techniques that make analysis more difficult. It appears that this loader was designed with resiliency and flexibility in mind, as evidenced in later stages of the infection process.

Over the past several months, we've seen several spam campaigns with signed emails attempting to infect victims with JasperLoader and ultimately the Gootkit banking trojan. Message signing makes use of certificates' verification to confirm the authenticity of the person sending the email, as only those with access to the private keys should be able to sign the message. Message signing is not the same as message encryption and is used only to validate the identity of the message sender not to guarantee the confidentiality of the message itself. Talos has identified several malicious campaigns making use of this type of message signing as a way to lend credibility to their messages and maximize the likelihood that potential victims will open the malicious attachments.

Malicious spam campaigns

As with many email-based threats, Talos observed multiple distinct campaigns being leveraged to distribute JasperLoader. Each campaign featured various email templates and downloader configurations. Each campaign was also relatively localized and featured multiple languages specific to each of the countries that were being targeted. Most of the campaign activity targeted European countries with a specific focus on Italy. However, we have identified campaigns targeting countries outside of Europe. Below is an example of an email associated with one of the campaigns targeting Germany.

The email is fairly basic and includes an attached ZIP archive. The subject line "Zahlungserinnerung" roughly translates to "Payment Reminder," which is a theme consistent with many of the malspam campaigns commonly observed in the wild. This particular campaign leveraged a Visual Basic for Applications (VBS) script that was responsible for initiating the JasperLoader infection process. We'll dive into the obfuscated script later. The campaigns targeting Germany were some of the only ones that were observed using VBS files to initiate the JasperLoader infection. Most of the attacks generally used DOCM files to download JasperLoader, and ultimately Gootkit.

As previously mentioned, most of the JasperLoader campaign activity that has been observed over the past few months has been targeting Italy. As can be seen in the screenshot below, these emails are significantly different than those seen in the other campaigns. Rather than containing a malicious file attachment, these emails purport that they are notifications associated with the receipt of a "certified email" and contain an attached EML file.

The threat actors distributing JasperLoader are leveraging a legitimate certified email service called Posta Elettronica Certificata (PEC) to distribute these emails. This is a certified email service related to legislation recently passed in Italy involving new requirements associated with electronic invoicing that took effect at the beginning of 2019. This new legislation requires Italian businesses to use electronic invoicing to deliver invoices for both business-to-business (B2B) and business-to-consumer (B2C) transactions. Attackers have recognized that this is an attractive way to leverage an already trusted email service to maximize the likelihood that they can convince potential victims to open their malicious emails.

One of the requirements associated with this new legislation is that all electronic invoicing emails must be signed and sent using a new platform called "Sistema di Interscambio (SDI)." Additionally, invoices should be sent using a specific XML-based format for consumption and that format should be verified and its validity confirmed before being transmitted to the recipient of the invoice.

As you can see, this particular campaign is leveraging this service, which allows them to transmit messages that meet the requirements associated with this new legislation and abuse the trust between potential victims and the certified email service.

The certificate itself is valid and associated with the PEC certified email service that was described above. Using the PEC certified email service, organizations are allowed to send attachments of up to 30MB to recipients. Posta Elettronica Certificata (PEC) is currently being widely used in Italy, Switzerland and Hong Kong and allows people to send registered email messages. The idea behind this project is to allow anyone — whether living in the country or not — to communicate through official channels, while allowing for the verification of the authenticity of the message sender. This service enables the communication of official business-related information without relying on physical mail services, facilitating faster real-time communications.

The campaigns observed to be leveraging the PEC service contained emails that claim to be notifications of the receipt of a "certified email message" and featured EML attachments. The screenshot below shows what one of these EML attachments looks like when opened by potential victims.

As can be seen above, the attached EML files contain attached ZIP archives that hold Microsoft Word DOCM files that reference the same invoice as the emails to which they were attached. The DOCM files contain malicious embedded VBA macros that initiate the JasperLoader infection process. The metadata associated with the DOCM files used across many of the campaigns have been observed containing the string value "VPS2day" in several of the metadata fields.


Talos identified multiple unique malicious DOCM files associated with JasperLoader campaigns taking place over the course of several weeks. An example search for files with metadata containing the string "VPS2day" resulted in 167 unique files in VirusTotal.

In addition to the campaigns using malicious DOCM files to distribute JasperLoader, we also observed messages containing malicious JS downloaders. There were also some campaigns that featured legitimate and malicious file attachments. For example, some of the observed campaigns included ZIP files containing JS and XML files and benign PDF invoices. In several of the campaigns, some of the files were improperly named. For example, the XML files were .XM instead of .XML and the PDF invoices were .PF instead of .PDF.

Subtle changes like this can be surprisingly effective when attempting to convince potential victims to open file attachments. Talos also observed campaigns that leveraged PDF attachments that contained no file extension whatsoever. Investigating the PEC certified email service, we identified that this service is being widely abused by threat actors for a variety of malicious purposes dating back to the beginning of 2019 when the legislative requirements took effect.

One other interesting aspect of this campaign was its utilization of Domain Shadowing, a technique Cisco Talos discovered, which was pioneered by exploit kit users back in 2015. This technique allows the adversary to host malicious content on subdomains associated with legitimate domains. This is typically achieved through abuse of the registrant account, allowing for the creation of subdomains pointing to adversary-owned infrastructure.

JasperLoader details

Microsoft Word documents were attached to several of these malicious emails. When opened, these documents displayed this decoy image:

The message displayed in the image is in Italian, and translates to:

This file was created with a prior Microsoft Office 365 version. To view the contents you need to click on the "Enable modifications" button, located on the yellow bar at the top, and then click on "Enable content."

JasperLoader Stage 1

The Microsoft Word documents contain malicious macros that execute JasperLoader and start the infection process. Using the Python oletools package, we can further analyze the macro execution and determine how the infection process takes place.

As displayed in the screenshot above, oletools detects the presence of the VBA macros embedded within the Word document. The macro is configured to execute when the Word document is opened and is responsible for executing the commands to initiate the infection. The presence of "Chr" within the VBA macros may indicate that the macros have been obfuscated, which we will walk through to provide an example of the process analysts can take to analyze these types of malware loaders.

In addition to the use of Microsoft Word documents, Talos also observed the use of ZIP archives that directly contain VBS downloaders. The infection process is the same in both cases. While the obfuscation differs slightly between the two types of campaigns, the approach is very similar. We will walk through the infection process using the VBS with the following hash (SHA256): dc78dbd42216fdb64c1e40c6f7a2fad92921f70c40446d62eb1873d6b77ee04c.

As previously reported by oletools, the macros have been obfuscated to make static analysis more difficult. The macros define a variable and then an array containing a large number of elements.

At the end of the script, the following code is responsible for performing a mathematical operation on all of the numbers in the array, reconstructing it into code that can be executed, and then executing it to continue the infection process:

The value assigned to the variable d1 is 267. To identify what is actually going to be executed, we can subtract 267 from each of the numbers present in the array and convert the resulting value into the corresponding VBScript character using a conversion table similar to the one available here.

Once we have replaced the array values with the correct VBScript character value, we can see that the VBScript is responsible for executing PowerShell commands. However, there are still a lot of artifacts from the VBScript obfuscation present, which makes additional analysis difficult. Talos has observed that the value used for the subtraction changes frequently across samples, but that the logic remains the same.

The next step is to remove all of the unnecessary characters that were part of the VBScript obfuscation to recreate the VBScript, as well as the PowerShell associated with this stage of the infection. Once we have removed these extra characters, we are left with the following partially obfuscated code:

Several string values have been inserted into the PowerShell that the VBScript will execute in order to avoid string-based detection and make much of the PowerShell unreadable. A closer look at the portion of the PowerShell instructions that haven't been obfuscated show that during the execution process, -replace will be used to remove these extra string values to allow for the reconstruction of the obfuscated Powershell. Examples of this operation can be seen in the below syntax:

-replace '6ayBRVW',"";
-replace 'uVRWRut',"";
-replace '6xzQCRv',"";

This code instructs the system to replace these three string values throughout the script with nothing, effectively removing them and allowing the Powershell code to properly execute. Manually removing all references to these three strings results in the following:

This script performs the following operations:

• Calls WScript and uses it to execute PowerShell.

• PowerShell is used to invoke the Get-UICulture cmdlet to identify the language set used on the system.

• If the language set is associated with one of the following countries, the infection process terminates:

• Russia
• Ukraine
• Belarus
• The People's Republic of China

• Downloads additional data from the following URLs:

• hxxp://cdn[.]zaczvk[.]pl/loadercrypt_823EF8A810513A4071485C36DDAD4CC3.php?vid=

• hxxps://www[.]telekom[.]de/resources/images/130468/eSS-illustrations-V006-MeineErsteRechnung-FN-SG.png

• hxxp://cloud[.]diminishedvaluecalifornia[.]com/501?dwgvhgc

• The data downloaded from the aforementioned URLs is saved to the following file location, respectively:

• %TEMP%\SearchIE32.js
• %TEMP%\illustrations5543.png
• %TEMP%\AdobeAR.exe

• Executes the downloaded files, continuing the infection process.

The infection process then continues with the execution of the contents that were retrieved from the attacker's distribution servers.

JasperLoader Stage 2

As previously mentioned, the PowerShell executed in Stage 1 is responsible for reaching out to three distinct URLs used to retrieve and execute content on infected systems. The first URL that is defined is: hxxp://cloud[.]diminishedvaluecalifornia[.]com/501?dwgvhgc.

The malware loader initiates an HTTP GET request for contents hosted at the aforementioned URL and returns a numerical value from the attacker-controlled server. Note that the code is present within the Content Body of the HTTP Server Response:

As defined by the Powershell instructions in Stage 1, the returned content is then saved to %TEMP%\AdobeAR.exe.

In addition to the value "500" that is returned to the client, Talos has also observed additional codes being returned such as "404,""408," etc. In all of the cases Talos observed, the HTTP Response Code remains 200 OK, but the code present in the Content Body varies.

The malware loader also reaches out to the attacker's server at hxxp://cdn[.]zaczvk[.]pl/loadercrypt_823EF8A810513A4071485C36DDAD4CC3.php?vid=.

Following an HTTP GET request by the malware loader, the malicious server responds by sending back an HTTP response that contains obfuscated JavaScript:

As defined in Stage 1, the contents of the returned JavaScript are saved to the %TEMP%\SearchIE32.js and executed. The contents have been obfuscated to make analysis more difficult. Similar to what was seen with the VBScript obfuscation in the previous stage of the infection, the code defines an array, and then uses push() to create the string of obfuscated data. JavaScript code at the end of the returned content is responsible for reassembling, deobfuscating, and then using eval() to execute the JavaScript.

The good news with JavaScript obfuscation is that, typically, the code deobfuscates itself prior to execution. Rather than attempt to manually deobfuscate the JavaScript, we can rely on this behavior to have the code deobfuscate itself automatically. In order to more efficiently deobfuscate and analyze the malicious JavaScript, we can use an analysis tool like Malzilla.

Malzilla will deobfuscate the JavaScript and display it in the lower pane. In the case of JasperLoader, this results in another script containing a partially obfuscated set of PowerShell instructions that defines how the malware will continue the infection process.

The returned script is partially obfuscated using the same method we encountered previously. As we saw before, we simply need to remove the junk strings included throughout the script to fully deobfuscate it. Once those strings are removed, we are left with a script that looks similar to what we saw earlier, with a few changes included:

This script is responsible for performing the retrieval of the commands associated with the next stage of the infection process. It performs the following actions:

• Calls WScript and uses it to execute PowerShell.

• PowerShell is used to invoke the Get-UICulture cmdlet to identify the language set used on the system.

• If the language set is associated with one of the following countries, the infection process terminates:

• Russia
• Ukraine
• Belarus
• The People's Republic of China

• Downloads additional data from: hxxp://cdn[.]zaczvk[.]pl/crypt0DD1D2637FDB71097213D70B94E86930.php

• Saves the downloaded contents to %TEMP%\SearchIE32.txt

• Reads the contents of the downloaded file and performs a Regex based replacement to deobfuscate it.

• Executes the deobfuscated code to continue the infection process.

In addition to retrieving the data required to continue the infection process, the script also implements a Sleep cmdlet for 180 seconds then attempts to retrieve the latest obfuscated JavaScript that is hosted at the same URL that was referenced in Stage 1.

This JavaScript is then executed again. This is a mechanism that can be used to ensure that as the attackers modify the infection process, they can ensure that any previously infected systems automatically retrieve the modifications and are updated accordingly. This demonstrates an approach that ensures that this loader can be used repeatedly, potentially to deliver different malware payloads over time.

As previously mentioned, the malware makes an HTTP GET request to the following URL to obtain additional instructions from the attacker-controlled server: hxxp://cdn[.]zaczvk[.]pl/loadercrypt_823EF8A810513A4071485C36DDAD4CC3.php.

The obfuscated data that is returned by the server is then saved to %TEMP%\SearchIE32.txt. The script then reads back the contents of this file and performs a regex replacement operation to deobfuscate it so that it can be executed:

In order to further analyze the infection process, we need to deobfuscate the contents that were retrieved by the PowerShell. One way is to manually perform the same operation as the PowerShell.

In the previous screenshot, the following line of PowerShell is responsible for deobfuscating the code that was previously retrieved and adding it to the end of a variable assignment, which is later executed:

As the SearchIE32.txt file is read back in, the -replace statement is responsible for removing two of every three characters from the file to deobfuscate and reconstruct the PowerShell commands to be executed. The operation looks like this:

The obfuscated code contains a lot of junk code:

0zig7fs9(y4 7b(i6G7aet5tvf-giUdtIacC4zuxelactd7u6wr53ehy)26.izNejahgm71ewf ga-99mefau6twyctvhu6 6w'cxRf7Ua5|5aUuzAxi|4uBv6Yez|7eCd7N13'v3)66{v4 81eigxjyitct83;3e z4}e0

For every three characters present in the obfuscated code, the first two characters are removed and the remaining character is added to the end of the variable $jwihbyjzvhwwziwzadiuxat

For example, the string:

0zig7fs9(y4 7b(i6G7aet5tvf-giUdtIacC4zuxelactd7u6wr53ehy)26.izNejahgm71ewf ga-99mefau6twyctvhu6 6w'cxRf7Ua5|5aUuzAxi|4uBv6Yez|7eCd7N13'v3)66{v4 81eigxjyitct83;3e z4}e0 

Becomes the PowerShell command:

if( (Get-UICulture).Name -match 'RU|UA|BY|CN'){ exit; } 

In order to more efficiently deobfuscate the next stage of instructions, we will leverage the PowerShell ISE console to unpack the code for us. We can do this by copying the data retrieved from the server to our system and modifying the same PowerShell commands specified in the aforementioned script:

Now that the variable $jwihbyjzvhwwziwzadiuxat contains the deobfuscated code, we can simply retrieve the current value stored in this variable:

This causes the PowerShell ISE console to provide the deobfuscated commands that will be used for the next series of operations. We can now retrieve this information and continue our analysis.

JasperLoader Stage 3

Now that we have obtained the PowerShell responsible for the next stage of the infection process, we can begin to observe the main characteristics of the malware loader itself. Below is the Powershell code associated with this stage of operations.

As can be seen in the screenshot above, this is where the majority of the activity associated with JasperLoader takes place. The PowerShell present in this stage is responsible for the operations described in the following sections.

Geolocation checks

The PowerShell associated with Stage 3 of the JasperLoader infection process performs exactly the same geolocational verification that we have observed in all previous stages of the infection. It checks the UICulture of the system and terminates execution if the UICulture matches Russia, Ukraine, Belarus, or People's Republic of China.

Achieving persistence

The next series of actions are associated with maintaining access to the system. A function called CreateShortcut() is defined that is responsible for achieving persistence by creating a LNK shortcut in the Startup folder of the infected system to ensure that the malware will execute when the system reboots.

Bot ID generation

The malware also queries the system using WMI and retrieves various pieces of information that are used to generate a unique identifier for the infected system. This information is later transmitted to the C2 server to register the newly infected system and allow for it to be uniquely identified. These activities are performed by the CreateID() function that is defined, as shown below:

Bot registration and command retrieval

The infected system then uses an HTTP GET request to beacon out to the command and control (C2) server and transmits the unique bot identifier to register the new bot. It also waits for a response from the C2 server to determine how to proceed:

As can be seen in the observed screenshot, the C2 server issues HTTP responses that include pipe-delimited parameters that provide additional commands to JasperLoader and direct it how to proceed.

Supported commands:

JasperLoader currently has support for three distinct commands that may be received from the C2 server during this operation. They are denoted by the first character that is present in the response received from the C2 server. (Such as the letter "d" in the previous screenshot.)

Update mechanism ("u")

The "u" command may be received from the C2 server and directs JasperLoader to attempt to attempt to update itself using the parameters received from the C2 which are handled as values in an array assigned to the variable $action.

Bot management mechanism ("m")

The "m" command provides a mechanism with which the attacker can execute arbitrary system commands using Powershell on infected systems. The loader waits for a response from the C2 server that contains pipe-delimited information. It retrieves PowerShell commands from C2 and passes them to the Invoke-Expression (IEX) PowerShell cmdlet so that they can be executed.

Download mechanism ("d")

The "d" command directs the infected system to retrieve the final malware payload and provides the parameters with which this operation should take place. It informs JasperLoader where to go to retrieve the final malware payload, where to save it, and where to send status updates following successful deployment of the final payload.


It also creates a Windows Defender AV exclusion for the directory in which the PE32 will be stored if the system is running PowerShell version 4 or higher.

The system then attempts to retrieve the PE32 file that is the malicious payload in this particular infection. The screenshot below shows the C2 server delivering the malicious PE32 file to the infected system.

The status of the successful deployment of the malware payload is then further communicated to the attacker's server.

In this particular case, the malicious payload being delivered by JasperLoader is a widely distributed banking trojan called "Gootkit." This malware mainly looks to steal users' information and can act as a backdoor to the compromised machine.

Conclusion

JasperLoader is a malware loader that features a multi-stage infection process. This process has been constructed in a way that makes the loader resilient and provides flexibility to adversaries that are attempting to leverage it to spread malware. While it is currently being used to spread the Gootkit banking trojan, it will likely be used to distribute additional malware payloads in the future, as it has been designed in a way that allows the operators of the loader's infrastructure to use it for new payloads in the future as they choose to monetize their operation in different ways. The choice to abuse certified email services such as PEC demonstrates that as attackers are always looking for new ways to lend credibility to their social engineering attacks. In this case, abusing a legitimate email service allowed them to deliver their malicious emails in a way that would maximize the likelihood that a potential victim would open the attachments and infect themselves with JasperLoader. In addition to the various threats that we have already observed abusing these services, we expect additional threats to begin leveraging them as well.

Coverage

Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Additional protections with context to your specific environment and threat data are available from the Firepower Management Center.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

Indicators of compromise

The following IOCs are associated with various malware distribution campaigns that were observed during the analysis of JasperLoader activity.

Attachment hashes (SHA256)

A list of hashes observed to be associated with malicious email attachments can be found here.

Domains

A list of domains observed to be associated with JasperLoader can be found here.

IP addresses

A list of IP addresses observed to be associated with JasperLoader can be found here.

The news today is full of a new deserialization vulnerability in Oracle WebLogic.  This affects all current versions of the product (the POC is against 10.3, but 12.x versions are also affected).  The vulnerability affects the wls9_async_response package (which is not included by default in all builds), so the workaround is to either ACL the Z/_async/* and /wls-wsat/* paths, or delete wls9_async_response.war.  A successful attack gets the attacker remote code exec on the vulnerable server.

The root cause here seems to be that the affected WAR components ingest and process all serialized data, and have a blacklist of "bad" content.  What this means to me is that we're likely to see a number of similar vulnerabilities / attacks crop up over the next while, until Oracle changes this approach.

Indications are that this is in the "tens of thousands" of affected sites, not hundreds or thousands or millions (not yet at least).

The vulnerability is posted as CNVD-2018-07811 (China National Vulnerability Database) at http://www.cnvd.org.cn/flaw/show/CNVD-2018-07811.  We don't have a CVE yet.

This bug was originally disclosed by the China Minsheng Banking Co.  There's a good write-up by the KnownSec 404 Team with  a bit more detail here: https://medium.com/@knownseczoomeye/knownsec-404-team-oracle-weblogic-deserialization-rce-vulnerability-0day-alert-90dd9a79ae93

This comes just one week after Oracle's "Patch Everything" Critical Patch Update (CPU) last week.  The next CPU isn't due for 3 months, so it'll be interesting to see what the out-of-band response patch or patches (if any) to this might be.

Stay tuned - we'll udpate this story as we get more information - in particular if we see attacks in the wild we'll post IoC's as we get them.

======= Update =======

Thanks to our reader who commented below!

The matching CVE number for this is CVE-2018-2628, which was identified as patched in last week's patches (Oracle's CPU - Critical Patch Updates).  However the POC mentioned was against a patched server, so I guess the patch isn't complete - nor can it be given Oracle's approach against this issue.

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

In today’s 24x7, “always on” world, the company’s data network must be as reliable as possible.…

UPDATE: Flashpoint Intel issued a response to my research. UPDATE: SCMagazine picked up the story. UPDATE: Anti-Malware.name picked up the story. UPDATE: EnterpriseTimes picked up the story UPDATE: Rambler News picked up the story. It appears that Flashpoint's official Web site is currently embedded with malware-serving malicious script potentially exposing its visitors to a multi-tude of

While foreign phone carriers are sharing data to stop SIM swap fraud, US carriers are dragging feet.

This new version of format-bytes.py (a tool to decompose structured binary data with format strings) brings a couple of new features.

Format strings can now be stored in libraries: you can store often used format strings (option -f) in text files and refer to them for using with format-bytes.py. A library file has the name of the program (format-bytes) and extension .library. Library files can be placed in the same directory as the program, and/or the current directory.
A library file is a text file. Each format string has a name and takes one line: name=formatstring.

Example:
eqn=<HIHIIIIIBBBBBBBBBB40sIIBB*:XXXXXXXXXXXXXXXXXXsXXXX

This defines format string eqn. It can be retrieved with option -f name=eqn.
This format string can be followed by annotations (use a space character to separate the format string and the annotations):

Example:
eqn=<HIHIIIIIBBBBBBBBBB40sIIBB*:XXXXXXXXXXXXXXXXXXsXXXX 1: size of EQNOLEFILEHDR 9: Start MTEF header 14: Full size record 15: Line record 16: Font record 19: Shellcode (fontname)

A line in a library file that starts with # is a comment and is ignored.

Format strings inside a library can be used with option -f. For example, to use format string eqn1, you use option -f name=eqn1. You prefix the format string name with “name=”, like in this example:

Option -s can also take value r now, to select the remainder: -s r. Like this:

The FILETIME format has been added. To use it explicitly, use representation format T.

And finally, with option -F (Find), you can search for values inside a binary file. For the moment, only integers can be searched. Start the option value with #i# followed by the decimal number to search for.

Example:

format-bytes_V0_0_8.zip (https)
MD5: 22F216C2304434A302B0904A9D4AF1FE
SHA256: A38D9B57DDB23543E2D462CD0AF51A4DCEDA1814CF9EAD315716D471EAACEF19

In diary entry "Dissecting a CVE-2017-11882 Exploit" I analyze an equation editor exploit. These kind of exploits have become prevalent, I often see malware exploiting this vulnerability.

In my diary entry, I use my tool format-bytes.py to dissect the exploit using a long string of format specifiers. This is not practical if you have to do this often:

That's why I have now added a library of format strings to my tool format-bytes.py, eqn1 is the format string to use for this exploit:

So in stead of typing "-f "<HIHIIIIIBBBBBBBBBB40s..." ", you can now just type: "-f name=eqn1".

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.comDidierStevensLabs.com

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

Mueller report fallout, a biometrics database, and more of the week's top security news.

For months, Facebook has been heavily refactoring the entire osquery codebase, migrating osquery away from standard development tools like CMake and integrating it with Facebook’s internal tooling. Their intention was to improve code quality, implement additional tests, and move the project to a more modular architecture. In practice, the changes sacrificed support for a number of architectures, operating systems, and a variety of useful developer tools that integrate well only with the standard build system preferred by the open-source C++ community.

Worse still, the project’s new inward focus has greatly delayed the review of community contributions — effectively stalling development of features or fixes for the needs of the community — without a clear end in sight. Lacking a roadmap or predictable release cycle, user confidence in the project has fallen. Enterprises are postponing their planned osquery deployments and searching for alternative solutions.

Many of the most secure organizations in the world have already invested in making osquery the absolute best endpoint management solution for their needs. Being forced to look elsewhere would be a waste of their investment, and leave them relying on less effective alternatives. That is why we are announcing the community-oriented osquery fork: osql.

What are the goals of osql?

With osql, we are committed to restoring the community’s confidence in the osquery project, to making the development process more open and predictable, and to reviewing and accepting community contributions more quickly. Our goal is to restore direct community participation.

An open and transparent development process

In the immediate term, osql will be maintained as a “soft-fork.” We will closely track Facebook’s upstream updates without diverging from the codebase. Plenty of completed work is simply waiting upstream, in Pull Requests. We prepared a workflow through which the osql project can accept Pull Requests that the community deems stable enough to be shipped, but which have been ignored by the upstream maintainers. The community can pick and choose its priorities from those contributions, and incorporate them into the next release of osql.

Continuous Integration, Continuous Delivery

We’ve also integrated a much-needed public CI using Azure Pipelines, which will build and run tests at each commit. Find the results here. The CI will help us build, test, and release faster and more frequently. We are committing to release a new osql binary (package installer) on a regular monthly cadence. We will communicate the changes that users can expect in the next release. They will know when to expect it, and that the version they download has passed all tests.

Restoring standard tool support for developers

We rewrote the build system from scratch to return it to CMake, the C++ community’s de-facto standard for building projects. This effort was non-trivial, but we believe it was central to preserving the project’s compatibility with open-source toolchains. The libraries and tools that represent the foundation of modern C++ development, such as Boost or the LLVM/Clang compiler toolchain, all support CMake natively. The most-used third party libraries use CMake as well, making it quite easy to include them in a CMake-based project.

Developers benefit from built-in CMake support in their IDEs. Visual Studio, VS Code, CLion and QtCreator can all easily open a project from its CMakeLists file, enabling a precise view of the project’s structure and the outputs of its build process. They’ll also regain the convenience of CMake-supporting static analyzer frameworks, like Clang’s scan-build, which helps discover critical bugs across an entire project.

By re-centering everything around a CMake build process, we made osql a more developer-friendly project than upstream osquery. If you would like to see for yourself and begin contributing to osql, check out the build guide.

What’s next for osql

Our work is just beginning! We plan to continue improving the automation of osql releases. Initially, osql releases will be unsigned binaries/packages. The next priority for the project is to implement a secure code-signing step into the CI procedure, so that every release is a binary signed by the “osql” organization.

The osquery project’s build process used to allow you to choose whether to download or to build third-party dependencies, thanks to easily modifiable Homebrew formulas. Not only that, you could also choose from where these dependencies were downloaded. That is no longer true for osquery currently, but we will restore that ability in osql (a task made easier thanks to CMake).

We also plan to extend the public CI for osql to enable it to test PRs opened against upstream osquery. This will help the community review those PRs, and provide a kind of quality assurance for their inclusion in a future release of osql.

In the longer term, thanks to CMake’s support for building on various platforms, it will be possible for osql to be built for whatever new systems that the community demands.

Want More? Let’s Talk

When we originally ported osquery to Windows, we didn’t imagine it would become so big, or that it would outgrow what Facebook alone could maintain. A whole community of organizations now deploy and depend on osquery. That’s why we’ve launched osql, the community-oriented osquery fork. If you are part of this community and are interested in porting to other platforms, need special features from the project, or want some customization done to the core, join our osquery/osql support group or contact us!

Zone transfers are a classical way of performing reconnaissance in networks (or even from the internet). They require an insecurely configured DNS server that allows anonymous users to transfer all records and gather information about host in the network. What not many people know however is that if Active Directory integrated DNS is used, any user can query all the DNS records by default. This blog introduces a tool to do this and describes a method to do this even for records normal users don’t have read rights for.

Knowing where you are and where to go

Personally whenever I arrive at a new pentest or red team assignment I want to learn about the layout of the network, the software in use and where the interesting data is. If a company has non-descriptive server names or descriptions, tools like BloodHound or ldapdomaindump are not going to help much since SRV00001.company.local still doesn’t tell me what runs on this host. Running discovery tools like EyeWitness on a large range of IP addresses often returns a lot of default Apache/IIS pages, since most sites are configured to listen on a DNS name and not on the IP address. Knowing that gitlab.company.local also points to the same IP as SRV00001.company.local tells me that this is an interesting server if I’m after source code. Having access to DNS entries for AD is thus in my opinion quite valuable. Thus I wrote this small tool that can dump those records. You can either run it directly from a host within the network, or through a SOCKS tunnel using your favourite implant.

Prior work

This started when I was looking at Active Directory DNS, mostly inspired by Kevin Robertson’s work on ADIDNS. I tried to figure out how AD uses zones in LDAP for storing DNS records as I pulled up ADSI Edit and suddenly saw an overview of all the DNS records in the domain, using only a limited regular user. As I shared my surprise, Kevin pointed out to me that mubix already wrote about this back in 2013. So there was already a PowerShell script that could do this, but it didn’t do exactly what I wanted, so I decided to write a version in Python and add some options to enumerate more records than possible by default.

The “hidden” DNS records

The most obvious way to query for DNS records in LDAP would be to perform a query selecting all objects of the class dnsNode, which represent entries in the DNS zone. When I performed a query with the filter (objectClass=dnsNode), this returned quite limited results, even though I could see several more records when manually browsing to the DNS zone:

As visible on the image above, for several objects the objectClass is not visible. This is because of the default permissions on computer DNS records (and I think on other records not created via the AD DNS gui as well), which don’t allow all users to see the contents. Since the IP addresses are actually stored as a property of this object, it isn’t possible to view the IP address for these records either.

But like any user can create new DNS records by default, any user can also list the child objects of a DNS zone by default. So we know a records is there, we just can’t query it using LDAP.

Once we know a records exists by enumerating with LDAP, we can however query for it using DNS directly (since performing regular DNS queries doesn’t require privileges). This way we can resolve all records in the zone.

Querying records with adidnsdump

With adidnsdump, which you can get from my GitHub, it is possible to enumerate all records in the DNS zone. To get started, first display the zones in the domain where you are currently in with --print-zones. This will show which zones are present. Not all zones are interesting, for example forward, cache and stub zones don’t contain all the records for that domain. If you find these zones, it’s better to query the domain to which they actually belong. The output below shows that my test domain has only the default zones:

user@localhost:~/adidnsdump$ adidnsdump -u icorp\\testuser --print-zones icorp-dc.internal.corp
Password:
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Found 2 domain DNS zones:
internal.corp
RootDNSServers
[-] Found 2 forest DNS zones:
..TrustAnchors
_msdcs.internal.corp

If we specify the zone to the tool (or leave it empty for the default zone), we will get a list of all the records. Records which can be listed but not read (so called “hidden” records) are shown but only with a question mark, as it is unknown which type of record is present and where it points to. The records are all saved to a file called records.csv.

To resolve the unknown records, specify the -r flag, which will perform an A query for all unknown records (you can easily change this to AAAA in the code if you’re in an IPv6 network). Several nodes which were blank before now suddenly have records:

If you don’t have a direct connection but are working via an agent, you can proxy the tool through socks and perform the DNS queries over TCP with the --dns-tcp flag.

Mitigations

You shouldn’t really rely on secrecy of your DNS records for security. If you really want to hide this information, removing the “List contents” permission for “Everyone” and “Pre-Windows 2000 Compatible Access” does prevent regular users from querying the entries, but this does require disabling inheritance on the DNS zone and may break stuff, so I don’t really recommend going that way. Monitoring for high volumes of DNS queries or enabling auditing on DNS zone listings may be a better way to deal with this, by detecting instead of blocking this kind of activity.

The tools

adidnsdump is available on GitHub and on PyPI (pip install adidnsdump). Right now the tool only dumps records to CSV files, but feel free to submit requests for alternate formats.

This blog was originally published on dirkjanm.io

This new version of jpegdump.py (a tool to analyze JPEG pictures) adds 2 new options: -t and -A.

Option -t: consider everything after the first EOI as trailing.

Option -A: perform ascii dump with RLE

jpegdump_V0_0_7.zip (https)
MD5: DF600AAADD1E6335CB1DC5FEF895B2AE
SHA256: 123CDBACA0533BE975751F935EA9C6CEF75B7F8E67CC0FBAD36F8C66DD9354D8

Recently, FortiGuard Labs captured a suspicious email. After an analysis, we discovered that it was spreading the malware TrickBot. Read to learn more.

Docker, a company that created an open platform for building and running distributed applications, reported to users that its Docker Hub database had been breached, exposing sensitive data from approximately 190,000 accounts. While that figure makes up less than five percent of Hub users, the data included some usernames and hashed passwords as well as Github and Bitbucket tokens for Docker autobuild. The company reported that the tokens have been revoked, and said it “acted quickly to intervene and secure the site.”

Experts who spoke with Motherboard indicated that the worst-case scenario is that hackers gain access to proprietary source code of some of those accounts. For context, companies on Docker’s roster include the likes of Paypal and Visa. Microsoft quickly reported that its official files hosted in Docker Hub were not compromised.

According to Veracode CTO Chris Wysopal, it is not yet known what the underlying vulnerability was at Docker Hub, but it is a serious breach as attackers could use the access tokens to get at a company’s source code. It is unclear if the attackers would have write privileges, which would enable backdooring into the code. Wysopal said each customer that was notified should be resetting access tokens and looking at logs for access. With revision control, this is all heavily audited.

Since Docker notified customers quickly, hopefully the impact is limited. The company emailed those impacted by the breach directly with a password reset link. Customers using autobuilds should check to ensure that their GitHub or Bitbucket repositories are still linked to the Docker Hub to ensure autobuilds work correctly moving forward.

Thousands of companies and millions of developers around the world use Docker to run containers, which are software packages that include code, runtime, settings, system libraries, and system tools. By isolating software from its surroundings, software containers enable code to always run the same regardless of the environment it is operating within. Although the company is still investigating the breach, if hackers have access to the private code in the repositories, they may be able to inject malicious code into software autobuilt by Docker.

If you're going up against an army of the undead, maybe plan a little better.