Ransomware Reconnaissance: Interrogating Certiﬁcates Towards

Proactive Threat Mitigation

Steph Rudd

Centre of Excellence in Terrorism, Resilience, Intelligence and Organised Crime Research, CENTRIC,

Shefﬁeld Hallam University, Shefﬁeld, U.K.

Keywords:

Security, Certiﬁcates, X.509, SSL, TLS, Ransomware, Remote Interrogation, CA, PKI, OpenSSL.

Abstract:

“Got Root?” Presented herewith is an innovative approach to ransomware defence by interrogating the secu-

rity certiﬁcate chain pertaining to modern website security. It is a proactive strategy to scrutinise the online

resources prior to download for assessment of likelihood that ransomware may be present as a result of in-

consistencies between the URL and its security certiﬁcate. OpenSSL is employed for interrogating certiﬁcate

attributes, including characteristics such as domain mismatch and revocation status, through the systematic

approach of certiﬁcate retrieval, parsing and validation. Whilst not a ‘silver bullet solution’ to the wider realm

of ransomware attacks, this study presents a nuanced approach to suspicion detected under certiﬁcate-related

vulnerabilities at a preemptive and reconnaissance stage of hazard - a necessary basis for any subsequent cyber

security investigation.

1 INTRODUCTION

An investigation into the inspection of SSL/TLS

X.509 security certiﬁcates towards ascertaining the

possibility and probability of ransomware opportuni-

ties - and subsequent proposals towards safeguarding.

1.1 Context and Motivation

With ransomware becoming increasingly widespread,

the study places focus on the pivotal role of SSL/TLS

certiﬁcates in protecting information. Errors in these

certiﬁcates can lead to major security breaches, yet

they can be remotely analysed quickly and with re-

liable results. The urgency to fortify digital sys-

tems against such threats forms the core motivation

of our study. Challenging the conventional reliance

on tools such as Certbot as trusted Certiﬁcate Author-

ities (CA), in the context of ransomware exploit op-

portunities, provided insights into the areas requiring

future safeguarding, and proposed recommendations

of improvements beyond the remit of this study.

https://orcid.org/0009-0004-8503-373X

1.2 Novelties and Contributions

Listed non exhaustively are the key observations de-

duced from the study:

• Overlooked Vulnerabilities in Certbot. Whilst

the trusted CA, Certbot, provides robust and free

security certiﬁcates, this study presents evidence

that critical misconﬁgurations such as lacking in-

tegrity in certiﬁcate chains, and revoked certiﬁ-

cates, seemingly valid, are subject to manipula-

tion.

• Browser Validation Limitations. Proof that

browsers cannot detect incomplete certiﬁcate

chains or revoked certiﬁcates, advantageous for

ransomware deception

• Alternative Subject Analysis. Inappropriate cer-

tiﬁcate labelling also evades detection, allowing

malicious domains to appear trustworthy.

• Revocation. Revoked certiﬁcates can remain ac-

tive yet undetected, allowing loopholes. Error

testing: Positioning of context between SSL/TLS

vulnerabilities against the advance and prevention

of ransomware opportunities.

Rudd, S.

Ransomware Reconnaissance: Interrogating Certiﬁcates Towards Proactive Threat Mitigation.

DOI: 10.5220/0012710600003705

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 9th International Conference on Internet of Things, Big Data and Security (IoTBDS 2024), pages 97-106

ISBN: 978-989-758-699-6; ISSN: 2184-4976

1.3 Structure

The balance of this paper describes the background

problem, introducing the signiﬁcance of ransomware

as a topical cyber threat, subsequently detailing pit-

falls of certiﬁcate vulnerabilities leading to attack op-

portunities. The most concerning pitfalls are carried

forward to testing, in which live nested subdomains

with deliberate errors are deployed using a trusted CA

and tested as they would be in industry. Conclusions

are drawn from these concerns and future work is pro-

posed to mitigate vulnerabilities discovered.

2 PROBLEM BACKGROUND

Ransomware, a rapidly evolving cyber threat, lever-

ages various attack vectors to inﬁltrate systems, en-

crypt data, and demand ransom. A critical and of-

ten underestimated avenue for these attacks is the ex-

ploitation of X.509 certiﬁcate vulnerabilities. The

security of these certiﬁcates is paramount as they

authenticate and secure communications for various

sensitive online processes such as ﬁnance, healthcare

and other personal or sensitive data. It is a major

concern that vulnerabilities such as expired certiﬁ-

cates, weak encryption algorithms, or misconﬁgura-

tions can provide a conduit for ransomware attacks.

Such vulnerabilities not only weaken encryption, but

also erode trust mechanisms as a holistic entity - those

integral to digital security.

A further challenge towards mitigating ran-

somware risks associated with certiﬁcate vulnerabil-

ities is user naivety. The average user often lacks

the expertise to understand the nuances surrounding

Transport Layer Security (TLS) security in general -

let alone certiﬁcate inspection within or even beyond

the browser interface. Ignorance of browser warning

regarding safety of expired and untrusted certiﬁcates

however is fairly obvious. The type of person who

would happily disregard the safety of a browser on

their private device is unlikely to possess the where-

withal to proceed beyond that warning, as the process

is deliberately obfuscated - and most organisational

ﬁrewalls will prevent that proceeding for users who

can. More poignantly is the fact that such vulnerabil-

ities are permitted to launch in the ﬁrst instance - and

these are the errors on which this study is based.

How possible is it to manipulate, mimic, and mock

a trusted CA? Having achieved a number of deliberate

errors into a server, how well can they be hidden, by

the casual browser, or by closer inspection of a desig-

nated tool such as OpenSSL (Tuleuov and Ospanova,

2024)?

The answers to these questions will inform us of

the realities of certiﬁcate vulnerabilities, but more im-

portantly bring concrete indicators to the next gener-

ation of CA infrastructures and safety requirements.

3 VULNERABILITIES

Presented below are details of the tool used for test-

ing, and which vulnerabilities are suitable for testing

given the behaviour and automated safety settings of

such.

3.1 Related Work

There are several recent studies in detection of ma-

licious software in IoT (Tam

as et al., 2021), Ma-

chine Learning (ML) neural models (Obetta and

Moldovan, 2023), Artiﬁcial Intelligence (AI) (Lu and

Thing, 2022), and advanced malicious binaries ex-

isting within system ﬁles (Chukka and Devi, 2021),

there is little coverage on direct and simplistic pre-

ventative tactics such as addressing publicly-available

security information directly. Whilst such advanced

technologies are indeed necessary and with great suc-

cess, this study places focus on how vulnerabilities in

remote servers can indicate the possibilities of mali-

cious attempt - thus providing advanced warning, and

ideally, preventing the ransomware connection.

3.2 Obvious Indications

Many certiﬁcate vulnerabilities will ﬂag in the

browser automatically, warning them that the site is

insecure and creating an extra layer of difﬁculty to

proceed any further. This is often enough to scare

users from venturing any further, and therefore cer-

tiﬁcate vulnerabilities that provide this function need

not be considered. For less obvious certiﬁcate vul-

nerabilities, ie, those that do not trigger such warn-

ings, interaction with Certbot is considered. Cert-

bot is a trusted and open-source Certiﬁcate Authority

(CA), used to issue X.509 certiﬁcates, ensuring safety

throughout. Ideally, Certbot will prevent any artiﬁcial

vulnerability implementation, representative of resis-

tance against ransomware.

3.3 Potential Pitfalls

These are the multiple vulnerabilities pertaining to

X.509 certiﬁcates (Zulﬁqar et al., 2022), and their un-

derlying centralised management system Public Key

Infrastructure (PKI), (Vlad et al., ; Housley and Polk,

2001):

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

1. Expired Certiﬁcates. Expired certiﬁcates, or

very short validity periods, cannot be set in Cert-

bot, but auto-renewal can be disabled to create

the same in time. Expired certiﬁcates, while not

directly linked to ransomware, raise red ﬂags in

browsers, and therefore require no further consid-

eration.

2. Short Key Lengths. Certiﬁcates with short cryp-

tographic key lengths are more vulnerable to

brute-force attacks, but fortunately, Certbot does

not support modiﬁcation of key lengths - and so

they will always abide by the latest TLS standard.

3. Misconﬁgured Certiﬁcates. Misconﬁgurations

related to the setup of the certiﬁcate (such as en-

abled cipher suites and protocols) can be exam-

ined using OpenSSL . This is a broad turn of

phrase, largely referring to the misconﬁguration

of cipher suites and SSL or TLS protocols, which

could potentially be modiﬁed in the generated

conﬁguration ﬁles after certiﬁcate issuance.

4. Self-Signed Certiﬁcates. Certiﬁcates generated

without a CA ﬂag up on browsers and are amongst

the most obvious of all dangerous website indica-

tors. Certbot is a trusted CA, and thus does not

produce self-signed certiﬁcates.

5. Revoked Certiﬁcates. These are valid certiﬁcates

that have been withdrawn for whatever reason. If

they remain unidentiﬁed, they can be exploited

for ransomware attacks by mimicking trustworthy

sites and misleading users into downloading ma-

licious content. This is an important vulnerability

to investigate using Certbot.

6. Domain Mismatch Certiﬁcates. Generate cer-

tiﬁcates where the Common Name (CN) or Sub-

ject Alternative Name (SAN) doesn’t match the

subdomain. Although not a direct vector for ran-

somware, it can often play a part in sophisticated

phishing schemes, leveraging the naivety of the

user, and often opens the possibilities of Man-in-

the-Middle (MitM) attacks.

7. Certiﬁcates with Invalid Signatures. These are

certiﬁcates where the signature veriﬁcation fails,

indicating potential tampering or corruption, but

will also ﬂag immediately in the browser.

8. Certiﬁcates with Incorrect Usage Flags. Cer-

tiﬁcates that are not ﬂagged correctly for their in-

tended use, such as a certiﬁcate meant for securing

email being used for a web server.

9. Wildcard Certiﬁcates for Suspicious Domains.

While wildcard certiﬁcates are legitimate, their

use in certain contexts (like a brand-new or low-

reputation domains) can be suspicious. Cert-

bot insists on domain validation within the DNS

records for issuance of such certiﬁcates, and will

therefore always be valid on completion.

10. Certiﬁcates with Very Long Validity Periods.

Abnormally long validity periods might be a sign

of non-compliance with best practices or an at-

tempt to avoid frequent renewal scrutiny, which

is why Certbot will provide a set 90-day validity

period with auto-renewal so this cannot occur.

11. Certiﬁcates with Incomplete Chain of Trust.

These certiﬁcates do not have a complete path to

a trusted root CA, often because of missing inter-

mediate certiﬁcates. This is a vulnerability to be

tested, as modiﬁcation of conﬁguration ﬁles may

be available using certiﬁcate paths.

12. Certiﬁcates with Suspicious Subject Informa-

tion. This includes certiﬁcates with vague or

misleading information in the subject ﬁeld, like

generic names or placeholder details. Certbot

populates these details automatically from within

the domain path and therefore will not occur.

13. Overly Broad Subject Alternative Names

(SANs). Certiﬁcates that cover an unusually wide

range of domain names or include unrelated do-

mains can be suspicious. This will be investigated

amongst other nested subdomains, subdomains,

or domains using conﬁgured DNS ‘A’ records.

14. Certiﬁcates Issued in the Future. Certiﬁcates

with a ‘Not Before’ date set in the future can be in-

dicative of system misconﬁgurations or malicious

intent. Certbot will not allow this behaviour as

auto-renew is available for the 90-day validity pe-

riod.

3.4 Concerns to Be Carried Forward to

Testing

Whilst it is understood that browsers will ﬂag up the

most obvious of certiﬁcate non-compliance and sus-

picion, and Certbot can prevent the majority of mod-

iﬁcations towards certiﬁcate detriment, there still re-

main a small number of item in abeyance:

1. Incomplete Certiﬁcate Chains. Maintaining a

chain can be disturbed such as from changes in

the CA’s intermediate certiﬁcates.

2. Subject Alternative Names (SANs). Unrelated

subjects may be legitimate, but can pose risks if

mismanaged.

3. Deprecated Cipher Suites. Default conﬁgura-

tions may be subject to modiﬁcation or change

over a long period of time or through auto-renewal

using the same parameters.

Ransomware Reconnaissance: Interrogating Certiﬁcates Towards Proactive Threat Mitigation

4. Deprecated Protocols. As with cipher suites.

5. Domain Mismatch. The conﬁguration of server

ﬁles are beyond the remit of Certbot’s direct con-

trol, presenting a challenge in consistency be-

tween certiﬁcate and server setup.

6. Revocation. The discovery of revocation may or

may not be detected, depending on additional in-

frastructures and recognition, or as intermediaries

change over time.

4 TESTING METHODOLOGY

AND RESULTS

Firstly, risk rankings are assigned by severity, to the

attributes which will undertake testing - followed

by an introduction to an appropriate testing setup,

and how to invoke such to effectively make use of

OpenSSL in a native environment from remote and

secure access to the server. The errors will then be

implemented onto separate websites, and interrogated

remotely using OpenSSL. This will demonstrate how

publicly available security information can return low,

medium, high and critical vulnerability indicators.

4.1 Assign Severity Ratings

It is understood within the wider consensus of secu-

rity practice, that assigning severity scores to vulner-

abilities is an objective method of user-oriented deci-

sion making (Rudd and Cunningham, 2022). Gener-

ally, low-medium warnings are acceptable, and high-

critical warnings are not. With reference to the risk

rating methodology by the Open Web Application Se-

curity Project ((OWASP), ), the assignments are pre-

sented as:

1. Low. Minor risks, negligible direct exploitation

threat.

2. Medium. Moderate risks, conditional exploita-

tion potential.

3. High. Signiﬁcant risks, high exploitation likeli-

hood.

4. Critical. Severe risks, immediate and widespread

damage potential.

1. ICC, Incomplete Certiﬁcate Chain. This error

is usually rated with low to medium severity and

occurs when a server does not provide the full

chain of certiﬁcates. It can lead to trust issues but

is less directly related to severe attacks like ran-

somware. It can also be indicative of poor security

practices - a low warning, rated 2.

2. SAN, Overly Broad of Inappropriate Subject

Alternative Names (SANs). Involves certiﬁcates

with subject alternative names that don’t align

with the domain’s typical use. Rated medium,

in severity, this error could indicate broader se-

curity governance issues and open vectors for at-

tacks like phishing, a common ransomware deliv-

ery method, rated 2.

3. WCS, Using Weak Cipher Suites. Occurs when

a server supports outdated or weak cipher suites,

making encrypted communications vulnerable to

interception, and therefore a critical concern since

it can lead to data breaches or credential theft,

rated 4.

4. ODP, Outdated SSL/TLS Protocols. Employing

deprecated protocols like TLS 1.0 or SSLv3 sig-

niﬁcantly increases the risk of cyber attacks, in-

cluding ransomware incidents, as protocols con-

tain known vulnerabilities that can be exploited

by attackers, thus marked as critical, 4.

5. DMM, Domain Mismatch. Rated high in sever-

ity, domain mismatches can indicate a Man-in-

the-Middle attack, often used for initial reconnais-

sance, inﬁltration, or delivering ransomware - a

prerequisite to attack, rated 3.

6. RVC, Revoked Certiﬁcates. Also a high-severity

issue, a revoked certiﬁcate often signals a security

compromise. If a certiﬁcate has been revoked due

to key compromise, it could potentially be used by

attackers to impersonate legitimate services, lead-

ing to ransomware deployment, rated 4.

4.2 Setup the Environment

To test and analyse the six deliberate SSL/TLS cer-

tiﬁcate errors (ICC, SAN, WCS, ODP, DMM, RVC),

an environment was established encompassing nested

subdomains on a Linux Virtual Private Server (VPS),

to accommodate the Linux-native issuance of certiﬁ-

cates, by entering the remote server using the Se-

cure Shell (SSH), through a Linux terminal Command

Line Interface (CLI).

1. Nested Subdomains for Browser View. Each er-

ror type is assigned a unique nested subdomain,

allowing for isolated testing and clear visualisa-

tion in a web browser. This structure facilitates

the demonstration of how browsers react to each

speciﬁc SSL/TLS error.

2. Linux Environment for OpenSSL. OpenSSL

commands are used to simulate and test the cer-

tiﬁcate errors, providing a robust platform for ma-

nipulation and analysis.

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

100

3. Creation of Certiﬁcates for Each Nested

Subdomain. Individual SSL/TLS certiﬁcates are

created for each nested subdomain using Let’s En-

crypt’s Certbot. These certiﬁcates are issued from

a recognised CA, and then modiﬁed to introduce

the speciﬁc errors.

4. Creation of Each of the Six Errors. Individually

created post-certiﬁcate issue:

(a) ICC (Incomplete Certiﬁcate Chain). Conﬁg-

ured by omitting intermediate certiﬁcates from

the server’s certiﬁcate chain, leading to trust

warnings in browsers.

(b) SAN (Overly Broad or Inappropriate

Subject Alternative Names). Implemented

by generating certiﬁcates with SANs that do

not match the intended domain’s typical usage,

potentially causing validation issues.

lished by conﬁguring the server to prefer weak

or deprecated cipher suites, detectable through

SSL/TLS handshake analysis.

(d) ODP (Outdated SSL/TLS Protocols). En-

acted by setting the server to use outdated pro-

tocols like TLS 1.0 or SSLv3, exposing known

vulnerabilities.

(e) DMM (Domain Mismatch). Achieved by us-

ing a certiﬁcate issued for one domain on a dif-

ferent subdomain, leading to mismatch errors

in browsers.

(f) RVC (Revoked Certiﬁcates). Introduced by

revoking a certiﬁcate post-issuance, then veri-

fying its status using OCSP or CRL checks.

The Linux, Apache, MySQL and PHP (LAMP)

stack was setup on the global server to accommodate

the dynamic websites, and the following ﬁles were

added for deployment:

• DNS ‘A’ Record. Added to the root

domain in the format of ‘subsubdo-

main.subdomain.domain.co.uk’.

• /var/www. Folder for mir-

rorXX.ransomrecon.domain.co.uk, containing

index.php so to distinguish which error

• /etc/apache2/sites-available. mir-

rorXX.ransomrecon.domain.co.uk.conf, con-

taining the VirtualHost port 80 (insecure HTTP),

server name, document root, directory settings,

log paths, and SSL certiﬁcate paths, which will

automatically populate in their own conf ﬁle once

they are installed.

• /etc/apache2/sites-enabled. These are

symbolic links that automatically popu-

late once the nested subdomains are de-

ployed using the command ‘a2ensite mir-

rorXX.ransomrecon.domain.co.uk.conf’, fol-

lowed by restarting the server using ‘systemctl

apache2 restart’. Such commands require sudo or

admin privileges.

4.3 Implementation of Speciﬁc Error

Types

Following issuance of a valid certiﬁcate on each

nested subdomain, each will contain the entire cer-

tiﬁcate chain (fullchain.pem), the servers own certiﬁ-

cate for that speciﬁc nested subdomain (cert.pem),

and the private key (privkey.pem) of the server, or

nested subdomain, which is used to decrypt informa-

tion encoded using the server’s public key and should

be kept secret from everything.

4.3.1 Issue the Only X.509 Certiﬁcate that Will

Remain Valid

Issue and retain one valid, error-free X.509 certiﬁcate

to use a benchmark for errors.

˜$ sudo certbot --apache -d

mirror01.ransomrecon.domain.co.uk

˜$ sudo systemctl restart apache2

˜$ sudo openssl s_client -connect

mirror01.ransomrecon.domain.co.uk:443

-servername

mirror01.ransomrecon.domain.co.uk

4.3.2 ICC Incomplete Certiﬁcate Chain:

Severity 2

Conﬁgure the server to utilise the certiﬁcate only

(cert.pem), as opposed to the complete chain

(fullchain.pem), thus negating the integrity through-

out. This can appear valid from the browser, but

should show issues on deep inspection accessible us-

ing OpenSSL.

1. Issue Certiﬁcate, Restart the Server, Validate

the Certiﬁcate on Port 443, HTTPS:

˜$ sudo certbot --apache -d

mirror02.ransomrecon.domain.co.uk

˜$ sudo systemctl restart apache2

˜$ sudo openssl s_client -connect

mirror02.ransomrecon.domain.co.uk:443

-servername

mirror02.ransomrecon.domain.co.uk

Ransomware Reconnaissance: Interrogating Certiﬁcates Towards Proactive Threat Mitigation

101

2. Identify the Certiﬁcate File Name:

˜$ nano /etc/sites-available/mirror02.

ransomrecon.domain.co.uk-le-ssl.conf

3. Modify the File to Reﬂect the Path of Cert.Pem

and Restart the Server - Change From:

SSLCertificateFile /etc/letsencrypt/

live/mirror02.ransomrecon.domain.

co.uk/fullchain.pem

to:

SSLCertificateFile /etc/letsencrypt/

live/mirror02.ransomrecon.domain.

co.uk/cert.pem

˜$ sudo systemctl restart apache2

4. Test the Conﬁguration:

˜$ sudo openssl s\_client -connect

mirror02.ransomrecon.domain.co.uk:443

-servername

mirror02.ransomrecon.domain.co.uk

4.3.3 SAN Overly Broad of Inappropriate

Subject Alternative Names (SANs):

Severity 2

Request a certiﬁcate with an extra SAN, a domain be-

yond the remit of the nested subdomain.

1. Issue Certiﬁcate, Restart the Server, Validate

the Certiﬁcate, as Before.

2. Request Certiﬁcates From Two Domains, One

the Mirror, and One Unrelated:

˜$ sudo certbot certonly --webroot

-w /var/www/subdomain.unrelated-

domain.co.uk -d mirror03.

ransomrecon.domain.co.uk -d

geocash.domain.co.uk

(choose option 2 for extend domains)

3. List Certiﬁcates to View SANs:

˜$ sudo certbot certificates

4.3.4 WCS Using Weak Cipher Suites: Severity

Change the conﬁguration ﬁle to use deprecated cipher

suites such as MD5 rather than SHA256.

1. Issue Certiﬁcate, Restart the Server, Validate

the Certiﬁcate, as Before.

2. Change the Certbot-Generated Conﬁguration

File to Include Weak Cipher Suites: HIGH,

MEDIUM, LOW will allow cipher suites of such

varying strengths, whilst an exclamation mark

will disallow the subsequent attribute; !aNULL

will disallow anonymous authentication. The

weaker suites can then be queried in OpenSSL.

˜$ nano /etc/apache2/sites-available/

mirror04.ransomrecon.domain.co.uk

-le-ssl.conf

To:

˜$ SSLCipherSuite

HIGH:MEDIUM:LOW!aNULL

3. Test the Conﬁguration:

˜$ openssl s_client -connect

mirror04.ransomrecon.domain.

co.uk:443 -cipher MD5

4.3.5 ODP Outdated SSL/TLS Protocols:

Severity 4

Change the conﬁguration ﬁle to use deprecated

SSL/TLS protocols such as SSL v3 or TLS v1.0.

1. Issue Certiﬁcate, Restart the Server, Validate

the Certiﬁcate, as Before.

2. Change the Certbot-Generated Conﬁguration

File to Include Weak Cipher Suites:

˜$ SSLProtocol all -SSLv3 -TLSv1 - TLSv1.1

3. Test the Conﬁguration:

˜$ openssl s_client -connect mirror05.

ransomrecon.domain.co.uk:443 -ssl3

˜$ openssl s_client -connect mirror05.

ransomrecon.domain.co.uk:443 -tls1

˜$ openssl s_client -connect mirror05.

ransomrecon.domain.co.uk:443 -tls1_1

4.3.6 DMM Domain Mismatch: Severity 3

Obtain a valid certiﬁcate for a speciﬁc nested subdo-

main, then apply it to a separate subdomain. In this

scenario, mirror05 is valid, and used as support to er-

ror test mirror06, which is invalid.

1. Issue Certiﬁcate, Restart the Server, Validate the

Certiﬁcate, as Before.

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

102

2. Repeat the Process for Another Nested Subdomain,

mirror06.

3. Reconﬁgure the le-ssl.conf File for mirror06 to Point

to the Paths for mirror05:

˜$ sudo nano mirror06.ransomrecon.domain

.co.uk-le-ssl.conf

From:

SSLCertificateFile /etc/letsencrypt/

live/mirror06.ransomrecon.domain.co.uk/

fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/

live/mirror06.ransomrecon.domain.co.uk/

privkey.pem

To:

SSLCertificateFile /etc/letsencrypt/

live/mirror05.ransomrecon.domain.co.uk/

fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/

live/mirror05.ransomrecon.domain.co.uk/

privkey.pem

4. Test the Conﬁguration:

˜$ sudo openssl s_client -connect

mirror06.ransomrecon.domain.co.uk:443

-servername mirror06.ransomrecon.

domain.co.uk

4.3.7 RVC Revoked Certiﬁcates: Severity 4

Obtain a valid certiﬁcate and then revoke it. The certiﬁcate

should initially appear valid but should show as revoked

upon checking its revocation status.

1. Issue Certiﬁcate, Restart the Server, Validate the

Certiﬁcate, as Before.

2. Locate the Certiﬁcate and Full Chain Paths From

Checking the Certiﬁcate-Generated Conﬁguration

File Using Global Regular Expression Print (GREP)

Command, Where:

• -R or -r: Recursively search ﬁles in the speciﬁed

directory and all sub directories.

• -i: Ignore case distinctions in both the pattern and

the input ﬁles.

• -l: (Lowercase ’L’) List only the names of ﬁles with

matching lines, once for each ﬁle.

˜$ grep -Ril "SSLCertificateFile.

*mirror07.ransomrecon.domain.co.uk"

/etc/apache2/sites-available/

3. Revoke cert.pem and Validate the Certiﬁcate:

˜$ certbot revoke --cert-path

/etc/letsencrypt/live/mirror07.

ransomrecon.domain.co.uk/cert.pem

˜$ sudo openssl s_client -connect

mirror07.ransomrecon.domain.co.uk:443

-servername mirror07.ransomrecon.

domain.co.uk

Congratulations! You have

successfully revoked the certificate

that was located at /etc/letsencrypt/

live/mirror07.ransomrecon.domain.co.uk/

cert.pem.

4. Revoke fullchain.pem and Validate the Certiﬁcate:

˜$ certbot revoke - -cert-path

/etc/letsencrypt/live/mirror08.

ransomrecon.domain.co.uk/fullchain.pem

˜$ sudo openssl s_client -connect

mirror08.ransomrecon.domain.co.uk:443

-servername mirror08.ransomrecon.

domain.co.uk

Congratulations! You have

successfully revoked the certificate

that was located at /etc/letsencrypt/

live/mirror08.ransomrecon.domain.co.uk/

fullchain.pem.

5 DISCUSSION

We present the ﬁndings from the only valid certiﬁcate, and

the six deliberate errors, summarised below initially, and

subsequently expanded:

1. ICC, Incomplete Certiﬁcate Chain. Medium severity.

Showed valid on the browser, detected issues.

2. SAN, Overly broad of inappropriate Subject Alter-

native Names (SANs). Medium severity. Showed valid

on the browser, detected issues.

3. WCS, Using Weak Cipher Suites. Critical severity.

Seemingly possible by modiﬁcation, but was not.

4. ODP, Outdated SSL/TLS Protocols. High severity.

Seemingly possible by modiﬁcation, but was not.

5. DMM, Domain Mismatch. High severity. Flagged as

a browser safety error, but no issues detected.

6. RVC, Revoked Certiﬁcates. Critical Severity. Showed

valid on the browser, detected issues.

5.1 Issue the Only X.509 Certiﬁcate that

Will Remain Valid

Various details about the certiﬁcate and the TLS connection,

the output summary is:

1. Certiﬁcate Issuer and Subject Information. The

issuer details of the certiﬁcate, typically Let’s En-

crypt for a Certbot-issued certiﬁcate, and subject in-

formation, including the domain name for which

Ransomware Reconnaissance: Interrogating Certiﬁcates Towards Proactive Threat Mitigation

103

the certiﬁcate was issued - in this case, mir-

ror01.ransomrecon.domain.co.uk

2. Certiﬁcate Validity Dates. The date from which the

certiﬁcate is valid, expiration date of the certiﬁcate.

3. Public Key Information. Type of key; RSA, ECDSA

etc, length; 2048 bits, and the public key itself in a

human-readable format.

4. Certiﬁcate Chain: List of certiﬁcates in the chain,

from the server certiﬁcate up to the root certiﬁcate, and

validation status of the chain.

5. SSL/TLS Version. SSL or TLS version used for the

connection; generally TLSv1.2 or TLSv1.3.

6. Cipher Suite. The cipher suite used for establishing

the secure connection; more recently ECDHE-RSA-

AES256-GCM-SHA384.

7. Session Data. Session ID, if any, and key exchange,

encryption, and hash algorithms used in the session.

8. Handshake and Encryption Details. SSL/TLS hand-

shake process, and any encryption parameters that were

negotiated during the handshake.

9. Veriﬁcation Outcome. Success or failure of the

SSL/TLS certiﬁcate, details about any errors encoun-

tered during the veriﬁcation process.

10. Additional SSL/TLS Information. Any extensions or

additional features supported in the SSL/TLS protocol.

This is how a certiﬁcate output should look. It is a conﬁr-

mation that Certbot has set up the attributes and completed

the handshake successfully, and by visiting the nested sub-

domain URL, it can be observed that the HTTPS status is

present and details of the browser security is provided.

5.2 Errors 1-6

Presented below are explorations into the results of deliber-

ate certiﬁcate errors 1-6:

5.2.1 ICC Incomplete Certiﬁcate Chain:

Severity 2

There are errors indicating problems with the SSL certiﬁ-

cate chain, cited in the output ﬁle content:

1. Error 20. Unable to get the local issuer certiﬁcate: This

error occurs when OpenSSL cannot ﬁnd the intermedi-

ate or root certiﬁcate necessary to validate the chain of

trust. It suggests that the server may not be correctly

conﬁgured to send the intermediate certiﬁcates, which

are essential for the client to validate the server’s SSL

certiﬁcate.

2. Error 21. Unable to verify the ﬁrst certiﬁcate: This

error is related to Error 20 and occurs when the SSL

client is unable to verify the server’s certiﬁcate in the

absence of the necessary intermediate certiﬁcates.

OpenSSL has correctly ascertained the certiﬁcate issuer and

ﬁrst certiﬁcate to be questionable. The trust mechanism is

compromised, contributing to weakness and misdirection of

an original domain location.

5.2.2 SAN Overly Vroad of Inappropriate

Subject Alternative Names (SANs):

Severity 2

OpenSSL discovered a SAN entry for the unrelated domain,

and so the script was successful. The browser did not show

any indication of questionable trust, and the HTTPS with

veriﬁcation details were sound. As a result, the conclusion

was that even though the site appeared to be valid through

the URL’s browser, there was potential for vulnerabilities

and issues pertaining to integrity and trustworthiness:

- - - - - - - - - - - - - - - - - - - - -

Certificate Name: mirror03.ransomrecon.

domain.co.uk

Serial Number:

4c23fc4e840ded31893085c20de0e34553e

Key Type: RSA

Domains: mirror03.ransomrecon.domain.

co.uk subdomain.unrelated-domain.co.uk

Expiry Date: 2024-04-17 15:49:53+00:00

(VALID: 89 days)

Certificate Path: /etc/letsencrypt/live/

mirror03.ransomrecon.domain.co.uk/

fullchain.pem

Private Key Path: /etc/letsencrypt/live/

mirror03.ransomrecon.domain.co.uk/

privkey.pem

- - - - - - - - - - - - - - - - - - - - -

5.2.3 WCS Using Weak Cipher Suites: Severity

Upon OpenSSL interrogation, there was no report of

weak cipher suites in use. It was discovered that Cert-

bot does not allow modiﬁcation towards deprecated

and weak ciphers in any way, and even for educational

or testing purposes that this safety feature cannot be

overridden - which is very reassuring, considering this

would otherwise be a critical-severity vulnerability.

5.2.4 ODP Outdated SSL/TLS Protocols:

Severity 4

Exactly the same as with the cipher suite selection,

upon OpenSSL interrogation, there was no report of

weak SSL/TLS protocols in use. It was discovered

that Certbot does not allow modiﬁcation towards dep-

recated and weak protocols in any way, and even for

educational or testing purposes that this safety feature

cannot be overridden - which is very reassuring, con-

sidering this would also be a critical-severity vulnera-

bility.

5.2.5 DMM Domain Mismatch: Severity 3

Although the browser will render a safety issue as

with self-signed certiﬁcates, querying sudo certbot

certiﬁcates will display the certiﬁcate as valid as they

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

104

haven’t been overwritten when the path within the

VirtualHost was overwritten:

- - - - - - - - - - - - - - - - - - - - -

Certificate Name: mirror06.ransomrecon.

domain.co.uk

Serial Number:

33055c210727eab94d1162d4c6f217f4ec5

Key Type: RSA

Domains: mirror06.ransomrecon.domain.co.uk

Expiry Date: 2024-04-17 17:03:32+00:00

(VALID: 89 days)

Certificate Path: /etc/letsencrypt/

live/mirror05.ransomrecon.domain.co.uk/

fullchain.pem

Private Key Path: /etc/letsencrypt/live/

mirror05.ransomrecon.domain.co.uk/privkey.pem

- - - - - - - - - - - - - - - - - - - - -

5.2.6 RVC Revoked Certiﬁcates: Severity 4

The output does not contain any infor-

mation indicating that cert.pem for mir-

ror07.ransomrecon.domain.co.uk has been revoked.

The SSL handshake is successful, and the certiﬁcate

appears to be valid. On browser visit to the URL, it

also appears secure and valid. The output does not

contain any information indicating that fullchain.pem

for mirror08.ransomrecon.domain.co.uk has been

revoked. The SSL handshake is successful, and the

certiﬁcate appears to be valid. On browser visit to the

URL, it also appears secure and valid.

A revoked certiﬁcate often indicates a security

compromise. If a certiﬁcate has been revoked due

to key compromise, it could potentially be used by

an attacker to impersonate a legitimate service, lead-

ing to ransomware deployment. It is a great con-

cern that an in-built error such as certiﬁcate revocation

with a severity rating of 4, or critical, can so easily

be left unnoticed by browser security features, even

OpenSSL interrogation. Whilst Let’s Encrypt’s Cert-

bot is a trusted, and largely robust implementation of

free and secure certiﬁcates, this is the one example

of where it shows considerable, critical vulnerabil-

ity. Towards addressing this concern, Online Certiﬁ-

cate Status Protocol (OCSP), and a Certiﬁcate Revo-

cation List (CRL), should be installed globally within

the subdomain to impact on nested subdomains, and

within the root domain to impact on nested subdo-

mains, subdomains, and the domain itself.

5.3 Results Summary

Of the six original errors subject to testing, four

were permitted by modiﬁcation of Certbot-generated

conﬁguration ﬁles or otherwise interference via

OpenSSL. Reassuringly, tampering with item WCS

and ODP, cipher suites and protocols respectively),

were blocked by Certbot infrastructure. DMM was

also seemingly available to manipulate, but then

ﬂagged as the same safety warning as self-signed cer-

tiﬁcates, and so the user was protected from that.

However, there were three permitted issues, over-

looked by Certbot, and of various severity and detec-

tion via OpenSSL:

1. ICC, Incomplete Certiﬁcate Chain. Medium

severity, and unﬂagged from the browser. Upon

closer inspection from OpenSSl, the output

showed two errors proving the valid status was

false.

2. SAN, Overly broad of inappropriate Subject

Alternative Names (SANs). Medium severity.

Showed valid on the browser, and OpenSSL de-

tected no issues displaying two very different

branches of subdomains. Not even nested subdo-

mains; one was nested (the mirror), and one was

not - so they were not even on the same hierar-

chical level. RVC, Revoked Certiﬁcates. Crit-

ical Severity. This was very concerning, as the

revoked certiﬁcate did not ﬂag up either on the

browser nor the OpenSSL query, even though we

have written evidence that the certiﬁcate was re-

voked - proving that X.509 certiﬁcate are a liabil-

ity for attacks pertaining to ransomware, or even

support the distribution of ransomware itself.

6 CONCLUSION AND FURTHER

WORK

This study has highlighted numerous unobvious and

intricate vulnerabilities of CA certiﬁcate issuance, un-

derpinning the susceptibility of current certiﬁcate in-

frastructure to ransomware attack. Whilst CA tools

such as Certbot offer a largely robust and reliable

framework for certiﬁcate management, the ﬁndings

of the study reveal vulnerabilities still exist, rang-

ing from negligible to critical risk. Particularly con-

cerning incomplete chains and revoked certiﬁcates,

security breaches are at their highest potential and

particularly as automation in attacks grows through

bleeding-edge technologies. With support for ran-

somware deployment through Artiﬁcial Intelligence

(AI), Machine Learning (ML), and the decentralised

Web, Web3, it is paramount that future efforts towards

safeguarding are brought forward.

Ransomware Reconnaissance: Interrogating Certiﬁcates Towards Proactive Threat Mitigation

105

6.1 Future Work

Towards such future work, or preferably, imminent

work, let us consider the following innovative oppor-

tunities:

• Improvements on Current Certiﬁcate Is-

suance. Introducing inherent Online Certiﬁcate

Status Protocol (OCSP), and Certiﬁcate Revoca-

tion Lists (CRL), which should correlate and up-

date the certiﬁcates under revocation to be subse-

quently reﬂected in the browser as a ﬂagged warn-

ing as other breaches currently are.

• Improvements on Current Query Tools. Auto-

mated scripting techniques through Bash (Singh

and Vishwakarma, 2023), or similar in a plug-and-

play execution ﬁle for ease of use, where severity

ratings are automatically issued to the user from

queries launched on URL browsing. Such query

tools could be added as browser extensions for au-

tomated detection.

• User Education Programmes. User education in

organisational training - although it is widely un-

derstood this is not a reliable method of eradicat-

ing ransomware per se, and automated prevention

is preferable.

• Utilisation of AI and ML. Models to crawl the

web towards detecting potential ransomware en-

try points by employing query tools and other

automated scripts through user behaviour - but

as these models demand enormous datasets, this

could be a slow exercise and may also be criti-

cised in attempt to ‘boil the ocean’.

• Advancements Towards Web3. As the web in

general moves increasingly towards decentralised

and distributed practices, smart contracts and im-

mutable rulesets are coming into their own. This

is potentially the most effective starting point, as

such practices are currently an open area and col-

laboration with large and mature, trusted CA such

as Let’s Encrypt need not be approached for col-

laboration with suggestions of improvement.

REFERENCES

Chukka, A. and Devi, V. (2021). Detection of malicious

binaries by deep learning methods. In Proceedings

of the 6th International Conference on Internet of

Things, Big Data and Security. SCITEPRESS - Sci-

ence and Technology Publications.

Housley, R. and Polk, T. (2001). Planning for PKI: Best

Practices Guide for Deploying Public Key Infrastruc-

ture. John Wiley & Sons, Inc., New York, NY, USA,

1st edition.

Lu, Z. and Thing, V. L. L. (2022). PhilaeX: Explaining the

failure and success of AI models in malware detection.

Obetta, S. O. and Moldovan, A.-N. (2023). Detection of

DDoS attacks on urban IoT devices using neural net-

works. In Proceedings of the 8th International Con-

ference on Internet of Things, Big Data and Security.

SCITEPRESS - Science and Technology Publications.

(OWASP), O. W. A. S. P. OWASP risk rating methodology.

https://owasp.org/www-community/OWASP Risk R

ating Methodology. Accessed: 2021-10-16.

Rudd, S. and Cunningham, H. (2022). Threat modelling

with the GDPR towards a security and privacy metrics

framework for IoT smart-farm application.

Singh, K. and Vishwakarma (2023). Automation in man-

ual penetration testing using bash shell script. Inter-

national Research Journal of Modernization in Engi-

neering Technology and Science.

Tam

as, C., Papp, D., and Butty

an, L. (2021). SIM-

BIoTA: Similarity-based malware detection on IoT

devices. In Proceedings of the 6th International Con-

ference on Internet of Things, Big Data and Security.

SCITEPRESS - Science and Technology Publications.

Tuleuov, B. I. and Ospanova, A. B. (2024). OpenSSL. In

Tuleuov, B. I. and Ospanova, A. B., editors, Begin-

ning C++ Compilers: An Introductory Guide to Mi-

crosoft C/C++ and MinGW Compilers, pages 157–

163. Apress, Berkeley, CA.

Vlad, A., Luca, A., Hodea, O., and Tataru, R. Proceedings

of the romanian academy. https://acad.ro/sectii2002/p

roceedings/doc2013-3s/ProceedingsSpecialssue2013

.pdf#page=20. Accessed: 2024-1-25.

Zulﬁqar, M., Janjua, M. U., Hassan, M., Ahmad, T.,

Saleem, T., and Stokes, J. W. (2022). Tracking adop-

tion of revocation and cryptographic features in x.509

certiﬁcates. Int. J. Inf. Secur., 21(3):653–668.

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

106