This is my first-ever breach report, in which I discovered a potentially infected network belonging to a company that was running scans and breach attempts against my honeypot system.

Attack Observation Disclaimer

This post is based on a research assignment completed during my time with the SANS Internet Storm Center internship program. The data represented was collected using a personal Cowrie/DShield honeypot running on a Raspberry Pi CM4. Please note that this observation reflects findings at the time of analysis and may no longer be relevant, as attack vectors and threat actor behaviors evolve rapidly. Any businesses, sources, or indicators mentioned are included as originally observed and should not be considered current or actionable without further verification. This write-up is based on an assignment originally written on November 25, 2024.

Privacy Disclaimer

All identifiable information in this post has been redacted to protect the privacy and security of the company to which I made the breach report. Unfortunately, there will be many redactions below; the purpose of this post is to showcase my workflow, the tools I used, and how I came to my conclusions. Still, even with my redactions, please do not attempt to identify the victim. This write-up is purely educational and should not be used for malicious or monetary purposes.

Background

For this attack observation, I will be analyzing a potentially compromised system that belongs to a company which was caught scanning and attempting to breach my honeypot system. On September 23rd, 2024, my honeypot logged a connection from IP: XX.XX.XXX.XXX (REF: Company IP), which had quite a lot of activity on my system that day—2,213 logged events just on September 23rd alone. What caught my attention regarding this address was that the IP address looked very similar to my own IP addresses. My own IP address from my ISP begins with the same prefix as the attacker's, "XX." Two IP addresses having the same prefix may not mean much; all it means is that they potentially belong to the same IP block/network range. However, I wanted to see why a business-class administered IP address was actively performing attacks within my honeypot system. I used mxtoolbox.com to get more information on this IP address and potentially see who it belongs to, so I could figure out if this entity was performing malicious attacks themselves or if one of their systems had been compromised.

The ARIN information for XX.XX.XXX.XXX details the following important snippets of information:

[Section 1]
NetRange:       XX.XX.x.x - XX.XX.xxx.xxx
CIDR:           XX.XX.x.x/14
NetName:        ...REDACTED...
NetHandle:      NET-XX-XX-x-x-1
Parent:         NETXX (NET-XX-x-x-x-x)
NetType:        Direct Allocation
OriginAS:       XXXXXX
Organization:   ...REDACTED...
RegDate:        REDA-CT-ED
Updated:        REDA-CT-ED
Ref:            ...REDACTED...

[Section 2]
NetRange:       XX.XX.xxx.x - XX.XX.xxx.xxx
CIDR:           XX.XX.xxx.x/20
NetName:        ...REDACTED...
NetHandle:      NET-XX-XX-xxx-x-1
Parent:         ...REDACTED...(NET-XX-XX-x-x-x)
NetType:        Reallocated
OriginAS:       
Organization:   ...REDACTED...
RegDate:        REDA-CT-ED
Updated:        REDA-CT-ED
Ref:            ...REDACTED...

[Section 3]
NetRange:       XX.XX.xxx.xxx - XX.XX.xxx.xxx
CIDR:           XX.XX.xxx.xxx/28
NetName:        ...REDACTED...
NetHandle:      NET-XX-XX-xxx-xxx-x
Parent:         ...REDACTED... (NET-XX-XX-xxx-x-x)
NetType:        Reassigned
OriginAS:       
Customer:       ...REDACTED...
RegDate:        REDA-CT-ED
Updated:        REDA-CT-ED
Ref:            ...REDACTED...

[Section 4]
CustName:       ...REDACTED...
Address:        ...REDACTED...
City:           ...REDACTED...
StateProv:      ...REDACTED...
PostalCode:     ...REDACTED...
Country:        US
RegDate:        REDA-CT-ED
Updated:        REDA-CT-ED
Ref:            ...REDACTED...

ARIN Breakdown

Section 1

This section gave me a better understanding of which ranges were allocated to the IP address used by the attacker. XX.XX.x.x – XX.XX.xxx.xxx was allocated to COMPANY-ISP-REDACTED, which turns out to actually be a competitor of my ISP. It just happens that the prefix for the IP address is the same, and the IP addresses were simply part of the same block, allocated to two different ISPs. However, this still maintained my interest, as an IP belonging to COMPANY-ISP-REDACTED is typically assigned to businesses as static IPs. If I could figure out who owns it, I could attempt to contact them to inform them about this occurrence. Using RIPE.net, I was able to confirm more details about the IP address XX.XX.XXX.XXX (REF: Company IP). I will go into more detail about this later, after the following section summaries.

Section 2

Section 2 gave us more information regarding the specific range that XX.XX.XXX.XXX (REF: Company IP) belongs to. The range, XX.XX.xxx.x - XX.XX.xxx.xxx, is a smaller range within the allocation given to COMPANY-ISP-REDACTED, which may direct to a specific regional location. The NetName section indicates “...REDACTED...”; however, to be sure, I wanted to go a little deeper to confirm this. I was able to confirm that at least the IPs of concern and the start/end of the range all point to StateProv-REDACTED by using geolocation.com. This will hopefully assist me in narrowing down any potential identities that I may come across later in this observation.

Section 3

This section now gives us a clearer indication of who this specific IP belongs to. The range of XX.XX.xxx.xxx - XX.XX.xxx.xxx belongs to the customer “CUSTOMER-ISP-IDENTIFICATION-REDACTED,” which can help us potentially get closer to understanding more about this entity and what is occurring within their systems.

Section 4

This section gives us all the information about the specific customer themselves; their physical address is provided as well. I will go into further detail regarding this after the section summaries.

RIPE.net Information Gathering

RIPE.net is a tool I used to get further details regarding the IP address of concern. Specifically, I wanted to get the IP’s reverse DNS hostname. The reverse DNS hostname revealed XX-XX-XXX-XXX-REDACTED.REDACTED.REDACTED.TLD, which confirmed my suspicions that the attacker’s IP address belonged to a business-class IP range.

Customer Details via ARIN Lookup

Going back to the information gathered within the section summaries for MXToolBox.com’s ARIN lookup tool, we can see that the IP XX.XX.XXX.XXX belongs to a customer named “COMPANY-NAME-REDACTED” with an address of STREET-ADDRESS-REDACTED, CITY-REDACTED, STATE-REDACTED, US POSTAL-REDACTED`.

A simple Google Maps lookup gives us an aerial view of the location, which appears to be some sort of business park:

Attack Observation: Honeypot - First Breach Report

I curated a list of the businesses at that business park, along with their domains (if available): LIST-REMOVED-FOR-PRIVACY Since the customer appears to be a corporate park, I will include the additional business tenants that may be located within the property: LIST-REMOVED-FOR-PRIVACY

Initial Analysis Information Gathering

I want to avoid using port scanners, as I feel that may be highly invasive and potentially prohibited in most scenarios. I will be sticking to using publicly available information as much as possible.

With all this information, I was able to get a near-close match for who this IP address belongs to. It appears that the range that belongs to this customer is the range of IPs this business park allocates to its tenant businesses.

In the previous section, I was able to gather a small list of businesses and their websites that belong to this park.

Below is the IP address correlated to each business’s website, obtained from infobyip.com:

Attack Observation: Honeypot - First Breach Report

The results were disappointing; not a single one of the identified businesses led to an IP address belonging to the range allocated to the customer. Two of the businesses use Cloudflare, which may be proxying the true IP address of the domain. However, using a tool such as Shodan may provide better insights on the attacker’s IP address and some of the other IPs belonging to this customer. My goal is to attempt to identify a point of contact that I can use to inform them about this attack.

Shodan.io Analysis

One of the most useful, publicly available means of gathering information on an IP address is Shodan.io. A previous SANS course I had taken taught me extensively about Shodan.io and how it can provide useful information and potential vulnerabilities within just a single lookup.

XX.XX.XXX.XXX Shodan Lookup:

XX.XX.XXX.XXX is our attacker’s IP address and this link will provide the Shodan results: LINK-REDACTED

Shodan shows us that ports 21 and 22 are both open, and we can see some further information regarding both these ports and their services.

Port 21 appears to be running the service vsFTPd 3.0.2. Port 22 appears to be a standard SSH service, SSH-2.0-OpenSSH_7.4.

On Port 21, we see the following information:

220 (vsFTPd 3.0.2)
530 Login incorrect.
530 Please login with USER and PASS.
211-Features:
 EPRT
 EPSV
 MDTM
 PASV
 REST STREAM
 SIZE
 TVFS
 UTF8
211 End

On Port 22, we see the following information:

SSH-2.0-OpenSSH_7.4
Key type: ssh-rsa
Key: XXXXX...REDACTED...
Fingerprint: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX ...REDACTED...

Kex Algorithms:
    curve25519-sha256
    [email protected]
    ecdh-sha2-nistp256
    ecdh-sha2-nistp384
    ecdh-sha2-nistp521
    diffie-hellman-group-exchange-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group18-sha512
    diffie-hellman-group-exchange-sha1
    diffie-hellman-group14-sha256
    diffie-hellman-group14-sha1
    diffie-hellman-group1-sha1

Server Host Key Algorithms:
    ssh-rsa
    rsa-sha2-512
    rsa-sha2-256
    ecdsa-sha2-nistp256
    ssh-ed25519

Encryption Algorithms:
    [email protected]
    aes128-ctr
    aes192-ctr
    aes256-ctr
    [email protected]
    [email protected]
    aes128-cbc
    aes192-cbc
    aes256-cbc
    blowfish-cbc
    cast128-cbc
    3des-cbc

MAC Algorithms:
    [email protected]
    [email protected]
    [email protected]
    [email protected]
    [email protected]
    [email protected]
    [email protected]
    hmac-sha2-256
    hmac-sha2-512
    hmac-sha1

Compression Algorithms:
    none
    [email protected]

CVEs & Vulnerabilities

Port 22 had 18 listed vulnerabilities based on the information that was scoped out. The age of these vulnerabilities ranges from as far back as 2007 up until 2023. The SSH version specifically, SSH-2.0-OpenSSH_7.4, was released on December 19th, 2016. At the time of writing this, we are currently on version 9.9, released on September 19th, 2024.

There also appears to be a critical CVE (level 9.3), CVE-2008-3844, for this port, which lists the following information:

“Certain Red Hat Enterprise Linux (RHEL) 4 and 5 packages for OpenSSH, as signed in August 2008 using a legitimate Red Hat GPG key, contain an externally introduced modification (Trojan Horse) that allows the package authors to have an unknown impact. NOTE: since the malicious packages were not distributed from any official Red Hat sources, the scope of this issue is restricted to users who may have obtained these packages through unofficial distribution points. As of 20080827, no unofficial distributions of this software are known.”

You can read more about this vulnerability here: NIST.gov - CVE-2008-3844

However, reviewing this specific CVE, it appears that Shodan only included it because the specific operating system could not be determined and it only relied on the version of OpenSSH. This CVE regards a malicious package for Red Hat Enterprise Linux that was distributed from unofficial sources, not from their official distributions. However, additional CVEs were described that detail more potential points of breach that could uncover additional information.

A few of the additional CVEs are listed below (5.0 or higher):

CVE-2020-15778 (6.8)

“scp in OpenSSH through 8.3p1 allows command injection in the scp.c toremote function, as demonstrated by backtick characters in the destination argument. NOTE: the vendor reportedly has stated that they intentionally omit validation of ‘anomalous argument transfers’ because that could ‘stand a great chance of breaking existing workflows.’”

From: NIST.gov - CVE-2020-15778

CVE-2019-6111 (5.8) - Important

“An issue was discovered in OpenSSH 7.9. Due to the scp implementation being derived from 1983 rcp, the server chooses which files/directories are sent to the client. However, the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file).”

From: NIST.gov - CVE-2019-6111

CVE-2017-15906 (5.0)

“The process_open function in sftp-server.c in OpenSSH before 7.6 does not properly prevent write operations in readonly mode, which allows attackers to create zero-length files.”

From: NIST.gov - CVE-2017-15906

CVE-2018-15473 (5.0)

“OpenSSH through 7.7 is prone to a user enumeration vulnerability due to not delaying bailout for an invalid authenticating user until after the packet containing the request has been fully parsed, related to auth2-gss.c, auth2-hostbased.c, and auth2-pubkey.c.”

From: NIST.gov - CVE-2018-15473

CVE-2018-15919 (5.0)

“Remotely observable behaviour in auth-gss2.c in OpenSSH through 7.8 could be used by remote attackers to detect existence of users on a target system when GSS2 is in use. NOTE: the discoverer states 'We understand that the OpenSSH developers do not want to treat such a username enumeration (or "oracle") as a vulnerability.'”

From: NIST.gov - CVE-2018-15919

Out of these CVEs, one specific one caught my attention: CVE-2019-6111. This CVE describes how an attacker could potentially overwrite the .ssh/authorized_keys file. Why this caught my attention was that in a previous attack observation, attack observation #6, I noted that the most downloaded file to my honeypot system was a specific authorized_keys file with the hash of a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2

This specific hash of a downloaded file was found in numerous attacks within my honeypot’s logs. In fact, it was even discovered that this current observation’s attacker also downloaded this specific file. On my Kibana dashboard, I noted that this specific IP address attempted to download this authorized_keys file 28 times within multiple sessions. Below is a snippet of a few of those examples:

Attack Observation: Honeypot - First Breach Report

I noted this hash being downloaded 11,847 times within the date ranges of September 11th, 2024 to November 11th, 2024.

Although not as important for this observation, the authorized_keys file includes the following information:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr

Another interesting action committed by the attacker was the download of a hosts.deny file saved to /etc/hosts.deny. What was interesting about this download was that the hosts.deny file was completely empty, indicating that the attacker may have installed an empty hosts.deny file to overwrite the system’s current hosts.deny file. This could have been done as an attempt to bypass access restrictions, cover their own tracks, etc.

Preliminary Identification

Returning back to the initial point of this observation, who the victim is and how they were breached will need to be figured out.

AbuseIPDB.com Details on XX.XX.XXX.XXX

Using AbuseIPDB.com, we can get an accurate estimate of how long this IP has been under the attacker’s control. For XX.XX.XXX.XXX, there had been 35,826 reports, with the most recent being just over a minute ago (at the time of writing this). Also included is the first-reported date of June 14th, 2022. This indicates that the IP XX.XX.XXX.XXX has potentially been active for well over 2 years and is still currently active in its malicious campaigns.

With this information, we can see that the victim was likely compromised sometime around June of 2022.

Victim Identification Challenges

Finding information about the victim themselves may pose more of a challenge than I had originally anticipated. Shodan only reports two open ports—ports 21 and 22; no web ports are open, which removes the opportunity for me to directly correlate the IP to a business domain. We know that the ISP customer has a lease for the IP ranges of XX.XX.xxx.xxx - XX.XX.xxx.xxx, a block containing 16 IP addresses. Typically, with most ISPs, the first and last IP in the ranges are unusable. XX.XX.xxx.xxx would typically be used as the network identifier, which is not assignable to a host. The last IP, XX.XX.xxx.xxx, is the broadcast address, also not assignable to a host. This leaves the customer with 14 static IP addresses, which may be useful in providing me with further information. I decided to use Shodan once again with each usable IP address to see what further information I could find.

IP Addresses on Shodan

  1. XX.XX.xxx.xxa
  2. XX.XX.xxx.xxb
  3. XX.XX.xxx.xxc
  4. XX.XX.xxx.xxd
  5. XX.XX.xxx.xxe
  6. XX.XX.xxx.xxf

XX.XX.xxx.xxa Shodan Results

Hostname: XX-XX-xxx-xxa-REDACTED.REDACTED.REDACTED.tld
CVEs:
    CVE-2015-4000 (4.3)
    CVE-2015-0204 (4.3)
Port(s) Open:
    Port 443:
        Identified: ZyWALL USG 200
            Description: Zyxel Firewall
            MAC Address: B0:B2:DC:XX:XX:XX
                MAC Address Information:
                    OUI: B0:B2:DC
                    Organization: Zyxel Communications Corporation
                    Assignment: MA-L
                    Registration Date: 2012-03-13
            SSL Certificate (Summarized):
                Issuer: Subject: CN=usg200_MAC-REDACTED
                Subject: Subject: CN=usg200_MAC-REDACTED
                Validity: REDACTED_DATE, 2012 -> REDACTED_DATE, 2032
                Public Key: RSA 1024-Bit Key
                Signature Algorithm: SHA-1
                Certificate: Self-Signed

Problem(s)

The certificate has an almost 20-year-long validity period. This in itself is a problem, as a certificate that is not renewed could be vulnerable to future or current compromise. This, along with the RSA 1024-Bit Key (insecure) and an algorithm of SHA-1 (deprecated), poses many issues already.

Gaining Access

This certificate supports TLS1.0, which most modern browsers do not allow for use anymore. TLS1.0 is extremely vulnerable to many forms of attack. Using the Mullvad Browser, I set my minimum accepted TLS version to 1.0 and was able to access the ZyXEL administrator login page (screenshot below):

Attack Observation: Honeypot - First Breach Report

I was unable to find firmware for this exact model that is still available. However, I did stumble upon a Zyxel Community thread from March of 2022 discussing where the poster could find legacy firmware for the Zywall USG 200. A responder in that thread mentioned a few versions that were available, and v3.30(AQU.7)C0 appears to be the latest firmware that was released for this model. I found this specific firmware available on Softoware.org, which appears to have been uploaded around March 15, 2016. This indicates that, if the owner of this firewall was at the very least updating the system’s firmware, the latest firmware installation would have been in 2016 (assuming the upload date on softoware.org reflects a date near the actual release date). Another Zyxel community thread from around December of 2023 also confirms that the ZyWALL USG 200 has been out of support with no downloads available. One interesting thing to point out is that v3.30(AQE.7) is an older firmware version than the most recent version available, 3.30(AQE.7)ITS-WK48-r74988. In 3.30(AQE.7)ITS-WK48-r74988, a fix was implemented to finally allow for TLS1.2 support, which was discussed on a different Zyxel community thread. This could potentially indicate that the owner of this ZyWall had not updated their firmware throughout multiple releases.

Vulnerability Potential

We can now safely assume that this firewall is definitely vulnerable to many attacks. The fact that the administrative login page is accessible externally already indicates a major flaw in basic security. Attackers can utilize CVEs to find a way into this device, and if this device is connected to a network that also includes our offending IP, XX.XX.XXX.XXX, we can assume that this firewall may have been a point of entry. However, I will continue with the remaining IPs and their descriptions.

XX.XX.xxx.xxb Shodan Results

Hostname: XX-XX-xxx-xxb-REDACTED.REDACTED.REDACTED.tld
Port(s) Open:
    Port 1723:
        Identified: PPTP
        Firmware: 256
        Vendor: Allworx Server VPN
    Port 8081:
        Identified: N/A     # Presumably linked to Allworx Server VPN

Problem: Port 1723

PPTP, known as Point-to-Point Tunneling Protocol, is an older, outdated, VPN protocol with numerous well-know security flaws. In this specific case, it appears that the TCP port 1723 is used to connect remote VOIP lines together. Reference: AllworxForums.com Thread

Vulnerability Potential: Port 1723

This port may or may not have been a point of compromise, as the PPTP port seems to only be for VOIP connections. Although it has many well-known security flaws, most of the attacks mentioned do not seem to be the potential “easiest” way for the attacker to have breached the system. This service is still a consideration, but not a priority currently. Reference: (Wikipedia: Point-to-Point Tunneling Protocol - Security)

Access: Port 8081

8081 is a typical port for web applications; however, upon loading the page, I get an immediate 404 error.

Problem: Port 8081

Although this page throws a 404 error, upon further research on Allworx devices, I found a page that explains how to integrate Allworx with a third-party firewall. This creates a clearer picture if the ZyWALL firewall happens to be the firewall system administering connections for the Allworx VOIP system. Port 8080 is used to serve HTTP connections for the Allworx system.

XX.XX.xxx.xxc Shodan Results

Hostname(s): 
    XX-XX-xxx-xxc-REDACTED.REDACTED.REDACTED.tld
    REDACTED-SUB-DOMAIN.REDACTED-DOMAIN-A.tld
    www.REDACTED-SUB-DOMAIN.REDACTED-DOMAIN-A.tld
Port(s) Open:
    Port 80:
        Identified: Apache HTTPD
    Port 443:
        Identified: Apache HTTPD
    Port 449:
        Identified: IBM OS/400 as-servermapd

Hostname Notes

REDACTED-DOMAIN-A.tld could allow us to better understand who the potential victim could be. Looking into the website REDACTED-DOMAIN-A.tld, we see that the website is “Under construction” and appears to be a domain registered with REDACTED-DOMAIN-REGISTRAR.tld.

Additionally, looking into the business profile for REDACTED-DOMAIN-A on Better Business Bureau - BBB.org, we see that the business is located in REDACTED-CITY, REDACTED-STATE and started in 19XX (Year Partially Redacted). To confirm this connection further, the address listed on BBB.org and similar websites all list the address as REDACTED-ADDRESS, REDACTED-CITY, REDACTED-STATE Redacted Postal. This is the exact same address as the other businesses in that Corporate Park. Although this is not the offending IP, the addition of an identifiable hostname linked to a business that operates within this IP range assists in discovering who the potential victim may be, if not REDACTED-DOMAIN-A.tld themselves.

Port 80 Notes

Identified: Apache HTTPD

Forced redirection to HTTPS port 443

Access: Port 443

Identified: Apache HTTPD

Seems to be a default/sample webpage for “HTTP Server wapl2” — wap in "wapl2" is probably "Wireless Application Protocol", and 2 in "wapl2" probably indicates WAP 2.0.

Port 443 Notes

We finally see the use of a more secure SSL setup, albeit only serving for a sample page. The certificate here uses SHA-256 and 2048-bit RSA. If "wapl2" actually relates to a web portal of sorts for mobile devices connecting to a wireless network at that business, we can assume that this technology was added separately and probably at a much later date than the current vulnerable systems.

Port 449 Notes

Identified: IBM OS/400 as-servermapd

The IBM OS/400 was developed in December of 1985; OS/400 was later rebranded as i5/OS in 2004. This is a very old system, but the use of systems this old is not as uncommon as most may think.

Problem: Port 449

Port 449 is externally exposed to serve the IBM OS/400 with as-servermapd. Servermapd uses port 449 for the Server Mapper Protocol on IBM systems. The official term is as-svrmap, but this naming difference could be due to a customization, older terminology, etc. Reference: IBM.com Documentation: IBM i - Port numbers for host servers and server mapper

Server Mapper on IBM systems is primarily used for service discovery for client systems. If an attacker was able to access this, they could use it to enumerate local systems connected to the network(s) that server mapper services. This is another potential way these attackers may have performed reconnaissance on the network as a whole.

XX.XX.xxx.xxd Shodan Results - Offending IP

Hostname(s): XX-XX-xxx-xxd-REDACTED.REDACTED.REDACTED.tld
CVE(s):     # Refer to previous analysis earlier in this observation
Port(s) Open:
    Port 21:
        Identified: vsFTPd 3.0.2
    Port 22:
        Identified: SSH-2.0-OpenSSH_7.4

Potential Vulnerability: Port 21

Identified: vsFTPd 3.0.2

The Shodan results currently list vsFTPd on version 3.0.2, released in September of 2012 (additionally confirms potential lack of firmware updates in previous systems mentioned in this observation). Although vsFTPd itself does not release updates as often, there have been at least 3 major updates since the release of 3.0.2. The very next update after 3.0.2, 3.0.3, was a fix for SSL and was an overall update that fixed security as a whole. 3.0.4, released in 2021, also finally implemented support for TLSv1.2+. 3.0.4 also included many security upgrades and fixes to mitigate known CVEs at the time. This information builds a strong correlation between all previously mentioned systems regarding how security is handled and how firmware updates may have never been performed since, potentially, 2012.

Lastly, vsFTPd may also simply have weak credentials and/or weak or lacking encryption, which would give attackers easy access to whichever system vsFTPd serves.

Potential Vulnerability: Port 22

Identified: SSH-2.0-OpenSSH_7.4

To start, this system runs on OpenSSH v7.4; the current version is v9.9 at the time of writing this observation. Version 7.4 was released in December of 2016, giving us some hope that at least one service was updated. This can also just mean that OpenSSH was installed back in 2016 for additional company needs. Based on Shodan alone, this installation of OpenSSH v7.4 may potentially be at risk with a reported 18 CVE vulnerabilities that could be used against it.

CVEs of Concern

There are a few CVEs that were listed that may explain how an attacker gained access to this system. Below is a list of all the most likely CVEs that could have been used.

  1. CVE-2023-51385: This CVE describes how attackers can perform command injections using Shell metacharacters in user/host names. The use of this could potentially allow the attacker to bypass authentication completely and execute commands on the server.

  2. CVE-2023-48795 (Terrapin Attack): This attack could have also been used to gain SSH access. The process works by forcing the use of weaker encryption/authentication during handshakes. If the attacker was able to intercept traffic while weaker encryption/authentication was being used, they could intercept credentials that can be used to gain SSH access.

  3. CVE-2019-6111: This CVE in specific is what I believe describes this attack perfectly. This CVE describes how attackers can exploit the scp tool to overwrite files during transfers. This works by tricking the victim into using scp into communicating with a compromised server. This specific CVE mentions how an overwrite to .ssh/authorized_keys could allow the attacker to gain SSH access without the need of credentials. Through my Honeypot logs, we can see how this could have been the very method used by the attacker to gain SSH access without the need of credentials as the attacker also attempted to overwrite .ssh/authorized keys on my honeypot.

  4. CVE-2018-15473: This CVE was a common tactic that allowed for username enumeration by measuring the response delay that the SSH client has when attempting to verify the existence of the username. When an attacker is able to figure out the username, it enables for a much easier brute-force process as the attacker needs to only focus on passwords rather than a combination of passwords and usernames.

XX.XX.xxx.xxe Shodan Results

Hostname(s): XX-XX-xxx-xxe-REDACTED.REDACTED.REDACTED.tld
Port(s) Open:
    Port 80:
        Identified: Apache HTTPD

Access: Port 80

A similar message as the one available on XX.XX.xxx.xxc was presented to me when accessing the webpage: “Seems to be a default/sample webpage for ‘HTTP Server wapl1’”

Looking through the links available on this webpage, I noted two links:

  1. "For information on changing this page or serving additional pages using wapl1, refer to the iSeries Information Center." LINK - 404 Error
  2. To learn more, please refer to the list of documentation available on the HTTP server documentation page. LINK - No Longer Available

Both webpages no longer exist, however, we can infer a few clues from the links. iSeries Information Center is an information directory for IBM iSeries systems. The HTTP Server documentation page also leads to an iSeries software documentation page. This gives us more affirmation that either this IP range is used for one large network or that the setup for most networks within this IP range are alike.

XX.XX.xxx.xxf Shodan Results

Hostname(s): 
    XX-XX-xxx-xxf-REDACTED.REDACTED.REDACTED.tld
    REDACTED-SUB-DOMAIN.REDACTED-DOMAIN-A.tld
    www.REDACTED-SUB-DOMAIN.REDACTED-DOMAIN-A.tld

Port(s) Open:
    Port 80:
        Identified: Apache HTTPD
    Port 443:
        Identified: Apache HTTPD

Hostname Notes

A second instance of REDACTED-DOMAIN-A.tld being the hostname for one of the IPs in this range. Although this may simply mean that REDACTED-DOMAIN-A.tld was simply provisioned two IPs from the Corporate Park entity, or that they may as well be maintaining the entire network.

Port 80/443 Notes

This IP leads to a webpage that is exactly the same as XX.XX.xxx.xxe’s page, content-wise.

Shodan Result Outcome

With all the information I was able to collect, I can confidently say that the victim appears to be either REDACTED-DOMAIN-A.tld or may be within the networks that are provisioned by the Corporate Park. Both REDACTED-DOMAIN-A.tld and the Corporate Park have contact phone numbers available online, and my first step would be to contact either one of these individuals and let them know that a potential breach in their network was discovered and that contact should be made with whomever has authority to access the on-site systems. Once in contact, I can inform them with all the information I have gathered and potential steps for removal of adversaries and recovery.

Vulnerabilities Exploited

CVEs

Described in detail within this observation:

  • CVE-2019-6111
  • CVE-2018-15473
  • CVE-2023-48795 (Terrapin Attack)
  • CVE-2023-51385

MITRE ATT&CK Techniques

  • T1078 - Valid Accounts: The attacker using the authorized_keys file may suggest the purpose was for persistent SSH access with valid credentials.

  • T1071 - Application Layer Protocol: SSH was used and exploited in this attack, along with vsFTPd, which could have potentially been exploited for this attack.

  • T1203 - Exploitation of Vulnerability: CVEs were more than likely directly exploited within the attack on the victim, especially CVE-2019-6111 and CVE-2018-15473.

  • T1070.003 - Indicator Removal on Host: Clear Command History: The attacker overwriting hosts.deny to empty it could indicate attempts to remove evidence or cover their tracks.

  • T1020 - Automated Exfiltration: The attacker more than likely performed automated methods of exfiltration, as most of the attacks appeared to have been automated entirely. Judging by the IP abuse reports with thousands of entries, it can be assumed the attacker runs campaigns automatically.

  • T1588 - Obtain Capabilities: The attacker could have used publicly available information regarding the system, e.g., from Shodan, to understand attack vectors.

Attacker's Goal

The attacker’s primary goal appears to be to compromise as many systems as possible using already compromised systems. This can be verified, as the attacker was using a potentially compromised system to attack and compromise my own system in similar fashion. The goal could be for the attacker to build and maintain a botnet of sorts to launch further campaigns in the future, if it’s not already happening.

Attack Success in Vulnerbale Systems

This attack observation details vulnerable systems within a network and how they could have been compromised. It can be seen with the victim’s system that not only were severely outdated services present and externally accessible, but even systems such as the firewall’s administration page were publicly accessible and vulnerable to attacks like brute force or even breaches using default credentials if they had never been changed. Systems like these are all too common, and websites like Shodan give us in-depth details about vulnerable networks and systems. This attack, which was recorded on my honeypot, could have been the same method the attacker used to compromise the victim in my observation, showing its success in other networks and systems.

Attack Defense Recommendations

Frequent updates are needed. A system like this could have potentially avoided compromise if services and systems had been updated. Important security updates for services like vsFTPd and OpenSSH were missed, and even the firewall needed a physical upgrade to a newer machine, as their current firewall was no longer supported or maintained.

Ensure that critical systems are not exposed externally and accessible freely. Although possible, it is not advisable for the firewall’s administration page to be externally accessible. With this firewall in particular, due to the lack of newer security updates, vulnerabilities can exist and be discovered with no mitigation provided by the manufacturer. Something as simple as a newly discovered command injection exploit could render any security on the web administration page useless, allowing attackers easy access into one of the most crucial parts of the network.

Conclusion: Post-Breach Report

This is now being written in the present.

Shortly after submitting my attack observation, I decided to call one of the businesses within that Corporate Park. An employee there picked up the phone, and I gave her a basic rundown of the suspected intrusion within their networks and warned them of potential risks. The employee stated that she was not very familiar with the technical systems at their offices but told me she would let someone know who would contact me soon regarding my findings. Unfortunately, I never received a call back. Checking the Shodan information again, it appears that the business has not updated their outdated systems and services. Unfortunately, it's to be assumed that my report was either forgotten or not taken seriously. However, for my first report, I was very happy with the details I was able to obtain simply with publicly available resources.