Have you already heard about THOR Thunderstorm,  a self-hosted THOR as a service? In this blog post, we will show how you can leverage THOR Thunderstorm to level up your email infrastructure security.

THOR Thunderstorm is a web API wrapped around THOR, which accepts file uploads and returns matches in JSON format. It can process thousands of samples per minute sent from any device within the network. The abilities are seemingly endless, from scanning exotic OSs to integrating custom services (e.g., mail server). Check out this introduction blog for a taste of the many use cases of THOR Thunderstrom. Lets get started with some background on Postfix and Milter.

The Postfix mail server is a popular and highly configurable Mail Transfer Agent (MTA) used for routing and delivering email messages within a network or across the Internet. Similar to the Sendmail MTA, it can use Milter (protocol) to scan incoming emails for spam or malware. On incoming emails, compatible MTAs use the Milter protocol to communicate with an extra service, which also speaks the Milter protocol. This extra service scans the email and responds with its findings. Based on the response of the extra service the MTA can filter, discard, or quarantine the email. In this blog post, we are releasing an open-source implementation of a Milter Service called “postfix2thunderstorm” which allows you to scan emails using THOR Thunderstorm: https://github.com/NextronSystems/postfix2thunderstorm .

Supercharging your Postfix involves three things:

First, you need to set up THOR Thunderstorm – our manual will help you here. Make sure that there are the appropriate firewall rules in place to allow communication between the Milter service and THOR Thunderstrom.

Second, you need the “postfix2thunderstorm” service itself. You can find setup and usage instructions in the GitHub repo. Make sure that Postfix is able to reach this service via the network.

Last, you need to configure Postfix to “speak” to the “postfix2thunderstorm” service. To do this, add the following to your Postfix config (/etc/postfix/main.cf) and restart it:

# See https://www.postfix.org/MILTER_README.html for more information
# IP/Port of host where the postfix2thunderstorm service is running  
# (might be a good idea to make it the localhost (or use TLS)) 
smtpd_milters = inet:<IP>:<Port> 
# default action in case of error/timeout/... 
milter_default_action = accept  

• https://thor-thunderstorm-setup-guide.nextron-systems.com/en/latest/
• https://github.com/NextronSystems/thunderstorm-collector
• https://github.com/NextronSystems/thunderstormAPI

In case you need additional help, drop us a line.

In this blog post, we address a critical security concern and explore methods for evaluating potential compromises on devices like Ivanti Endpoint Manager Mobile (EPMM) / MobileIron Core using THOR or the free THOR Lite YARA and IOC scanners.

Recently, a severe remote unauthenticated API access vulnerability, known as CVE-2023-35078, has been identified in Ivanti Endpoint Manager Mobile. This vulnerability, previously branded as MobileIron Core, poses a significant threat to the security of organizations relying on this software.

If you found our previous blog post on performing compromise assessments on NetScaler / Citrix ADC Appliances with THOR helpful, then you’ll find this guide invaluable for evaluating potential compromises on your Ivanti EPMM / MobileIron Core appliances. Let’s dive in and learn how to gain deeper insights into potential compromises through remote scans.

Prerequisites

• Define “Enable Secret” via MICS dashboard
  • https://<mi-core>:8443/mics/mics.html#settings:mi-cli
  • Settings –> CLI –> “Change Enable Secret”
• SSH to Core and create “misupport” user
  • ssh admin@<mi-core> (login with admin password, same  as with WebUI access)
  • $> enable
  • $> configure terminal
  • $> service support will output the one-time-password:
    One-time-password for account misupport set to AsdfGhJkL job 93 at Tue Jul 25 14:14:00 2023 misupport user session will be expire in 30 minutes.

Mounting the Remote File System via SSH

First we create a new folder and mount the remote file system to that local folder:

sudo mkdir -p /mnt/remotefs
sudo sshfs -o reconnect misupport@<mi-core>:/ /mnt/remotefs

The -o reconnect option makes sure to reconnect the session on unstable networks.

Scanning the Mount Point with THOR Lite

With THOR Lite we can now run a so-called “Filescan” on the mounted drive.

sudo ./thor-lite-linux-64 -a FileScan --alldrives -p /mnt/remotefs

The following scan is much more intense as it scans every single file regardless of its extension or type. Scanning every file usually leads to much longer scan times and higher network load (be careful when using the --intense flag).

sudo ./thor-lite-linux-64 -a FileScan --alldrives -p /mnt/remotefs --intense

Scanning the Mount Point with THOR

With a full featured THOR and a so-called Lab license we can use the –virtual-map flag to virtually map the folder /mnt/remotefs to / internally. This means that signatures and filename patterns that make use of the virtual and not the actual path. We can also define a hostname that will appear in the log file using the -j flag. Otherwise the log would always contain the hostname of the scanning workstation.

sudo ./thor-linux-64 -a FileScan --alldrives -p /mnt/remotefs

Using the full version, we would use a different flag combination for a more intense scan of the remote system. The full version with a lab license allows us to use the --lab flag.

sudo ./thor-linux-64 --lab -p /mnt/remotefs --virtual-map /mnt/remotefs:/ -j my-ns-hostname

The --lab flag automatically activates the intense scan mode that checks every file, multi-threaded scanning, deactivates resource control and some other flags that can be useful in a lab scanning scenario.

Example Match

The provided screenshot demonstrates an illustrative match of an CVE-2023-35078 exploitation attempt. This attack’s specific rule is accessible in THOR and the free THOR Lite version. 

Specific Detection Rules

YARA

All the rules and IOCs have been shared in the free version of our scanner named THOR Lite

• LOG_EXPL_Ivanti_EPMM_MobileIron_Core_CVE_2023_35078_Jul23_1
• MAL_WAR_Ivanti_EPMM_MobileIron_Mi_War_Aug23
• MAL_WAR_Ivanti_EPMM_MobileIron_LogClear_JAVA_Aug23

Hash IOCs

The hash IOCs used in THOR and THOR Lite can be found here.

We created the log detection rule by analyzing a report that was shared under TLP:AMBER with affected parties. The rule relies on the URI path and the status code returned by a successfully exploited service.

The rule to detect the successful exploitation of the vulnerability looks like this:

The other rules are based on samples mentioned in the CISA report.

Other Notes

• Scans over SSH mounts can take longer than usual
• A network disconnect only pauses the scan, a forced “umount” crashes the scanner
• We tested network disconnects of 1 and 5 minutes. After a reconnect THOR just resumes the scan where it left off

Conclusion

As the frequency and complexity of cyberattacks continue to rise, ensuring the security of Internet-facing devices becomes paramount. By incorporating YARA rules from THOR into compromise assessment scans, users can bolster their cybersecurity defense and remotely identify potential threats on devices like Invanti EPMM / MobileIron Core and others.

Additionally, the ability to extend this coverage to unsupported devices opens up new possibilities for safeguarding critical systems. Adopting these cutting-edge cybersecurity practices will undoubtedly prove instrumental in mitigating risks and protecting digital assets in an ever-evolving threat landscape.

Advantages of the full THOR version

Apart from the usual advantages of the full THOR version over THOR Lite, there are a few more reasons to use the full version in this scenario:

• Use multiple instances on a single source system to scan many different remote systems at the same time
• Use virtual drive mapping to allow for additional detection opportunities
• Set a custom host name that appears in the log files (helpful when you scan many different targets)

If you’re interested in the full version, contact us using the “Get Started” button in the upper right corner. 

The first part of this blog series covers how THOR can be used to scan a Docker image. In the second part of this series, we will talk about how you can use THOR to scan running Docker containers. Now, consider this new use case: You want to check if your running Docker container was attacked by some Log4Shell exploit. To do this, we will show you how you can start THOR inside a running container!

Prerequisites

• Running Docker container with a shell installed (e.g. sh, bash, …)
  • In this example we will use Alpine Linux
• THOR 🙂
  • In this example we will use Thor-Lite. However, for a real-world usecase you should consider using the full Thor version (Thor vs Thor-lite).

Running THOR in a Docker container

First, we have to find the Docker ID of the container we want to check using: docker ps.
This will list all Docker containers running on the current host.

Sidenote: The following should also work with all the other containerization platforms (e.g. podman, Kubernetes, OpenShift, etc.).

docker cp thor/. 84d1624f0083:/thor

docker exec -it 84d1624f0083 /bin/sh

Inside the Docker container you can cd thor and start THOR: ./thor-lite-linux.

• {docker-id}_files_md5s.csv
• {docker-id}_thor_{date}.html
• {docker-id}_thor_{date}.txt

These files contain all findings of the THOR scan.

• docker cp 84d1624f0083:/thor/dffcea1e1fe9_files_md5s.csv .
• docker cp 84d1624f0083:/thor/dffcea1e1fe9_thor_2023-04-26_0728.html .
• docker cp 84d1624f0083:/thor/dffcea1e1fe9_thor_2023-04-26_0728.txt .

Note: You have to replace 84d1624f0083 with our Docker ID.

Lastly, to clean up your container run the following: docker exec -it 84d1624f0083 rm -rf thor.
This will delete all files that were created in the earlier steps.

In this blog article, we will talk about how you can use THOR to scan Docker images. Consider the following use case:  Before using an upstream Docker image, you want to precheck it for known IOCs and backdoors. THOR can help you with this!

Prerequisites

• Docker image with a shell installed (e.g. sh, bash, etc.)
  • In this example we will use Alpine Linux
• THOR 🙂
  • In this example we will use Thor-Lite. However, for a real-world usecase you should consider using the full Thor version (Thor vs Thor-lite).

Running THOR in a Docker container

In your THOR folder run: docker run --rm -it -v ${PWD}:/thor alpine /bin/sh. This will create a Docker container based on Alpine Linux, mount your working directory (where THOR is stored) to /thor in the container, and will drop you into the sh shell. Inside the Docker container you can cd /thor and start THOR: ./thor-lite-linux. You can exchange alpine with any Docker image, as long as it includes a shell.

• {docker-id}_files_md5s.csv
• {docker-id}_thor_{date}.html
• {docker-id}_thor_{date}.txt

These files contain all findings of the THOR scan.

By using THOR to scan Docker images, you do not have to blindly trust the author of an upstream Docker image – you can see for yourself!

In part 2 of this series we explain how to scan Docker containers using THOR.