Honeypot Findings

How data was collected

The data was collected using a single sensor that used the Internet Storm Centers Honeypot solution called DShield running on a cloud instance. The project, put on by SANS, allows anyone to set up a small inexpensive Honeypot anywhere in the world to collect information about attackers who scan the internet. This data includes SSH scan requests and data including username and password, as well as HTTP requests made to the server which returns a 404. It also logs what ports are being scanned on the honeypot at any given time. This is a fantastic resource for research and a fun pet project. The DShield homepage can be found here: https://isc.sans.edu/tools/honeypot/

I installed the honeypot and allowed it to run for around 8 days. I decided to dig into the HTTP requests and SSH log first because that is the most interesting to me.

SSH Logs

From the one scanner I was able to look at the usernames and passwords being passed to the machine via SSH. An interesting finding I came across was that around 40% of all scans had an overlap of username and password, meaning that 1694/4197 access attempts exchanged the username for the same password such as root:root or admin:root root:admin.

4197 Unique passwords or usernames passed to the machine over 8 days 1694 of which unique strings, either password or username overlapped.

And the top 10 username and password were:


   1447 "345gs5662d34" "345gs5662d34"
    964 "root" "3245gs5662d34"
    446 "root" "admin"
    355 "admin" "admin1234"
    241 "root" "root"
    232 "admin" "admin"
    180 "admin" "123456"
    161 "user" "user"
    142 "root" "123456"
    137 "admin" "password"

Top ten passwords and their counts were:


   1619 "123456"
   1447 "345gs5662d34"
   1445 "3245gs5662d34"
    751 "admin"
    499 "password"
    395 "123"
    373 "admin1234"
    365 "1234"
    321 "root"
    176 "user"

Top ten usernames and counts were:


  17568 "root"
   1522 "admin"
   1447 "345gs5662d34"
    629 "user"
    324 "ubuntu"
    306 "ubnt"
    209 "pi"
    182 "usr"
    156 "test"
    138 "oracle"

404 Error Data

The data collected for the 404 errors are all scans that attempt to probe the fake webservice for a URI that might be interesting. Often times another URL will be put into the URI field which would look like google.com/www.google.com:443. I am guessing that this is to test to see if the site is vulnerable to redirects? anyways I am removing the ?redirect testing? from the analisis I am doing and will be focusing only on the "interesting" resources such as .git and .env which indicate an exposed configuration file.

The top ten URI requests made for the 8 days of running the honeypot were:

      4 "/actuator/health"
      4 "/debug/default/view"
      4 "/geoserver/web/"
      4 "/_profiler/phpinfo"
      5 "/actuator/gateway/routes"
      5 "/.git/config"
     15 "/boaform/admin/formLogin"
     17 "/.env"
     48 "/favicon.ico"
    269 "/"

No surprise the root directory of the server was top of the list. This kind of scan is done just to see what the web server is hosting. The second most common scan was for the favicon.ico file. This is a standard file that most browsers will look for to load as the page Icon in the browser bar. If the image used is the one used by a web framework by default then an attacker can narrow down what kinds of scans they can run against the website. the .env and /.git/config are configuration files. The /_profiler/phpinfo file is a file that will display php version information from a site this can be used to see what modules are running for php and the version number of php itself. These files can be useful to an attacker when gathering information on potential targets, because with the information collected they are able to possibly determine services running, version numbers, and configurations if exposed. There are two paths that mention the actuator service which is scanning for exposed API endpoints for a service called spring which provides developers the ability to manage Virtual Machines by endpoints. The path /debug/default/view is looking for more version and service disclosure vulnerabilities. I also thought it was interesting to see people scanning for geoserver. Geoserver is a open source server that allows people to collaborate on geospatial projects. The only page that would give the attacker access to a website would be the /boaform/admin/formLogin page which seems to be attempting to exploit the CVE-2022-30023 to get a remote shell in a home router.

Sources:

boaform login CVE https://nvd.nist.gov/vuln/detail/CVE-2022-30023

geoserver wikipedia page : https://en.wikipedia.org/wiki/GeoServer

takeaway: Attackers will most likely be scanning for exposed configuration files and anything that can be used to leverage against the target later on in the attack, such as misconfiguration and version numbers. The data from this single node is very limited because these are initial scans preformed against an IP that has not been mapped to a domain. To attackers there is no obvious service running and they get a 404 error upon requesting a http resource from the honeypot, so these are just what attackers are looking for initially.

x