Tag Archives: Technology

WannaCry a Birthday Gift??

I woke up on the 12th of May, it was my birthday, and I looked on the news feed and saw a burst of articles regarding the WannaCry Ransomware that has swept across the globe.

number20of20symantec20detections20for20wannacry20may201120to2015
In the last few days, a new type of malware called Wannacrypt has done worldwide damage.  It combines the characteristics of ransomware and a worm and has hit a lot of machines around the world from different enterprises or government organizations:

https://www.theregister.co.uk/2017/05/13/wannacrypt_ransomware_worm/

While everyone’s attention related to this attack has been on the vulnerabilities in Microsoft Windows XP, please pay attention to the following:

  • The attack works on all versions of Windows if they haven’t been patched since the March patch release!
  • The malware can only exploit those vulnerabilities it first has to get on the network.  There are reports it is being spread via email phishing or malicious web sites, but these reports remain uncertain.

 

Please take the following actions immediately:

  • Make sure all systems on your network are fully patched, particularly servers.
  • As a precaution, please ask all colleagues at your location to be very careful about opening email attachments and minimise browsing the web while this attack is on-going.

 

The vulnerabilities are fixed by the below security patches from Microsoft which was released in Mar of 2017, please ensure you have patched your systems:

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Details of the malware can be found below.  The worm scans port TCP/445 which is the windows SMB services for file sharing:

https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-widespread-attacks-all-over-the-world/

Preliminary study shows that our environment is not infected based on all hashes and domain found:

 

URL:

www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

MD5 hash:

4fef5e34143e646dbf9907c4374276f5
5bef35496fcbdbe841c82f4d1ab8b7c2
775a0631fb8229b2aa3d7621427085ad
7bf2b57f2a205768755c07f238fb32cc
7f7ccaa16fb15eb1c7399d422f8363e8
8495400f199ac77853c53b5a3f278f3e
84c82835a5d21bbcf75a61706d8ab549
86721e64ffbd69aa6944b9672bcabb6d
8dd63adb68ef053e044a5a2f46e0d2cd
b0ad5902366f860f85b892867e5b1e87
d6114ba5f10ad67a4131ab72531f02da
db349b97c37d22f5ea1d1841e3c89eb4
e372d07207b4da75b3434584cd9f3450
f529f4556a5126bba499c26d67892240

 

Per Symantec, here is a full list of the filetypes that are targeted and encrypted by WannaCry:

  • .123
  • .3dm
  • .3ds
  • .3g2
  • .3gp
  • .602
  • .7z
  • .ARC
  • .PAQ
  • .accdb
  • .aes
  • .ai
  • .asc
  • .asf
  • .asm
  • .asp
  • .avi
  • .backup
  • .bak
  • .bat
  • .bmp
  • .brd
  • .bz2
  • .cgm
  • .class
  • .cmd
  • .cpp
  • .crt
  • .cs
  • .csr
  • .csv
  • .db
  • .dbf
  • .dch
  • .der
  • .dif
  • .dip
  • .djvu
  • .doc
  • .docb
  • .docm
  • .docx
  • .dot
  • .dotm
  • .dotx
  • .dwg
  • .edb
  • .eml
  • .fla
  • .flv
  • .frm
  • .gif
  • .gpg
  • .gz
  • .hwp
  • .ibd
  • .iso
  • .jar
  • .java
  • .jpeg
  • .jpg
  • .js
  • .jsp
  • .key
  • .lay
  • .lay6
  • .ldf
  • .m3u
  • .m4u
  • .max
  • .mdb
  • .mdf
  • .mid
  • .mkv
  • .mml
  • .mov
  • .mp3
  • .mp4
  • .mpeg
  • .mpg
  • .msg
  • .myd
  • .myi
  • .nef
  • .odb
  • .odg
  • .odp
  • .ods
  • .odt
  • .onetoc2
  • .ost
  • .otg
  • .otp
  • .ots
  • .ott
  • .p12
  • .pas
  • .pdf
  • .pem
  • .pfx
  • .php
  • .pl
  • .png
  • .pot
  • .potm
  • .potx
  • .ppam
  • .pps
  • .ppsm
  • .ppsx
  • .ppt
  • .pptm
  • .pptx
  • .ps1
  • .psd
  • .pst
  • .rar
  • .raw
  • .rb
  • .rtf
  • .sch
  • .sh
  • .sldm
  • .sldx
  • .slk
  • .sln
  • .snt
  • .sql
  • .sqlite3
  • .sqlitedb
  • .stc
  • .std
  • .sti
  • .stw
  • .suo
  • .svg
  • .swf
  • .sxc
  • .sxd
  • .sxi
  • .sxm
  • .sxw
  • .tar
  • .tbk
  • .tgz
  • .tif
  • .tiff
  • .txt
  • .uop
  • .uot
  • .vb
  • .vbs
  • .vcd
  • .vdi
  • .vmdk
  • .vmx
  • .vob
  • .vsd
  • .vsdx
  • .wav
  • .wb2
  • .wk1
  • .wks
  • .wma
  • .wmv
  • .xlc
  • .xlm
  • .xls
  • .xlsb
  • .xlsm
  • .xlsx
  • .xlt
  • .xltm
  • .xltx
  • .xlw
  • .zip

As you can see, the ransomware covers nearly any important file type a user might have on his or her computer. It also installs a text file on the user’s desktop with the following ransom note:

2cry

Advertisements

How to prepare for PWK/OSCP, a noob-friendly guide

Few months ago, I didn’t know what Bash was, only heard of SSH tunneling, no practical knowledge. I also didn’t like paying for the PWK lab time without using it, so I went through a number of resources till I felt ready for starting the course.

Warning: Don’t expect to be spoon-fed if you’re doing OSCP, you’ll need to spend a lot of time researching, neither the admins or the other students will give you answers easily.

1. PWK Syllabus
1.1 *nix and Bash
1.2 Basic tools
1.3 Passive Recon
1.4 Active Recon
1.5 Buffer Overflow
1.6 Using public exploits
1.7 File Transfer
1.8 Privilege Escalation
1.9 Client-Side Attacks
1.10 Web Application Attacks
1.11 Password Attacks
1.12 Port Redirection/Tunneling
1.13 Metasploit Framework
1.14 Antivirus Bypassing
2. Wargames
2.1 Over The Wire: Bandit
2.2 Over The Wire: Natas
2.3 Root-me.org
3. Vulnerable VMs

1. PWK Syllabus:

Simply the most important reference in the list, it shows the course modules in a detailed way. Entire preparation I did was based on it. Can be found here.

1.1 *nix and Bash:

You don’t need to use Kali Linux right away, a good alternative is Ubuntu till you get comfortable with Linux.

1. Bash for Beginners: Best Bash reference IMO.
2. Bandit on Over The Wire: Great start for people who aren’t used to using a terminal, aren’t familiar with Bash or other *nix in general. Each challenge gives you hints on which commands you can use, you need to research them.
3.  Explainshell: Does NOT replace man pages, but breaks down commands easily for new comers.

1.2 Basic tools:

You will use these tools a lot. Make sure you understand what they do and how you can utilize them.

Netcat: Most important tool in the entire course. Understand what it does, what options you have, difference between a reverse shell and a bind shell. Experiment a lot with it.
Ncat: Netcat’s mature brother, supports SSL. Part of Nmap.
Wireshark: Network analysis tool, play with it while browsing the internet, connecting to FTP, read/write PCAP files.
TCPdump: Not all machines have that cute GUI, you could be stuck with a terminal.

1.3 Passive Recon:

Read about the following tools/techniques, experiment as much as possible.

1. Google dorks
2. Whois
3. Netcraft
4. Recon-ng: Make sure you check the Usage guide to know how it works.

1.4 Active Recon:

  • Understand what DNS is, how it works, how to perform forward and reverse lookup, what zone transfers are and how to perform them. Great resource here.
  • Nmap: One of the most used tools during the course (if not the most). I’d recommend to start by reading the man pages, understand different scanning techniques and other capabilities it has (scripts, OS detection, Service detection, …)
  • Services enumeration: SMTP, SNMP, SMB, and a lot others. Don’t just enumerate them, understand what they’re used for and how they work.
  • Great list for enumeration and tools.

1.5 Buffer Overflow:

Most fun part in my opinion. There are countless resources on how to get started, I’d recommend Corelan’s series. You probably need the first part only for PWK.

1.6 Using public exploits:

Occasionally, you’ll need to use a public exploit, maybe even modify the shellcode or other parts. Just go to Exploit-db and pick one of the older more reliable exploits (FTP ones for example). The vulnerable version is usually present with the exploit code.

1.7 File Transfer:

Not every machine has netcat installed, you’ll need to find a way around it to upload exploits or other tools you need. Great post on this is here.

1.8 Privilege Escalation:

A never ending topic, there are a lot of techniques, ranging from having an admin password to kernel exploits. Great way to practice this is by using Vulnhub VMs for practice. Check my OSCP-like VMs list here.

Windows:Elevating privileges by exploiting weak folder permissions
Windows: Privilege Escalation Fundamentals
Windows: Windows-Exploit-Suggester
Windows: Privilege Escalation Commands
Linux: Basic Linux Privilege Escalation
Linux: linuxprivchecker.py
Linux: LinEnum
Practical Windows Privilege Escalation
MySQL Root to System Root with UDF

1.9 Client Side Attacks:

Try out the techniques provided in Metasploit Unleashed or an IE client side exploit.

1.10 Web Application Attacks

Another lengthy subject, understand what XSS is, SQL injection, LFI, RFI, directory traversal, how to use a proxy like Burp Suite. Solve as much as you can from Natas on Over The Wire. It has great examples on Code Injection, Session hijacking and other web vulnerabilities.

Key is research till you feel comfortable.

1.11 Password Attacks:

Understand the basics of password attacks, difference between online and offline attacks. How to use Hydra, JTR, Medusa, what rainbow tables are, the list goes on. Excellent post on this topic here.

1.12 Port redirection/tunneling:

Not all machines are directly accessible, some are dual homed, connected to an internal network. You’ll use such techniques a lot in non-public networks. This post did a great job explaining it.

1.13 Metasploit Framework:

Decided to skip this part, but if you still want to study it, check out Metasploit Unleashed course.

 

1.14 Antivirus Bypassing:

Skipped this part too.

2. Wargames

Use them as a prep for vulnerable machines.

2.1 Over The Wire: Bandit

Great start for people who aren’t familiar with Linux or Bash.

2.2 Over The Wire: Natas

Focused on web application, many challenges aren’t required for OSCP, but it helps for sure.

2.3 Root-me.org

Has great challenges on privilege escalation, SQL injection, Javascript obfuscation, password cracking and analyzing PCAP files

3. Vulnerable Machines

Boot-to-root VMs are excellent for pentesting, you import a VM, run it and start enumerating from your attacking machine. Most of them result in getting root access. Check the post on which machines are the closest to OSCP, there is also the https://lab.pentestit.ru/ .

Blog posts regarding my journey through Pentestit.ru.:

Pentestit Lab v10 – Introduction & Setup
Pentestit Lab v10 – The Mail Token
Pentestit Lab v10 – The Site Token

How to Sniff a Network: Decoding the IP Layer

 

Following from previous post, which can be found at: How to Sniff a Network : Packet Sniffing on Windows and Linux and How to Sniff a Network : Raw Sockets and Sniffing.

Sniffing one packet is not overly useful, so let’s add some functionality to process more packets and decode their contents.

In its current form, our sniffer receives all of the IP headers along with any higher protocols such as TCP, UDP, or ICMP. The information is packed into binary form, and as shown above, is quite difficult to understand. We are now going to work on decoding the IP portion of a packet so that we can pull useful information out such as the protocol type (TCP, UDP, ICMP), and the source and destination IP addresses. This will be the foundation for you to start creating further protocol parsing later on. If we examine what an actual packet looks like on the network, you will have an understanding of how we need to decode the incoming packets. Refer to Figure 3-1 for the makeup of an IP header.

Figure 3-1 Typical IPv4 header structure
Figure 3-1: Typical IPv4 header structure

We will decode the entire IP header (except the Options field) and extract the protocol type, source, and destination IP address. Using the Python ctypes module to create a C-like structure will allow us to have a friendly format for handling the IP header and its member fields. First, let’s take a look at the C definition of what an IP header looks like.

struct ip {
u_char ip_hl:4;
u_char ip_v:4;
u_char ip_tos;
u_short ip_len;
u_short ip_id;
u_short ip_off;
u_char ip_ttl;
u_char ip_p;
u_short ip_sum;
u_long ip_src;
u_long ip_dst;
}

You now have an idea of how to map the C data types to the IP header values. Using C code as a reference when translating to Python objects can be useful because it makes it seamless to convert them to pure Python. Of note, the ip_hl and ip_v fields have a bit notation added to them (the :4 part). This indicates that these are bit fields, and they are 4 bits wide. We will use a pure Python solution to make sure these fields map correctly so we can avoid having to do any bit manipulation. Let’s implement our IP decoding routine into sniffer_ip_header_decode.py as shown below.

import socket


import os
import struct
from ctypes import *

# host to listen on
host = "192.168.0.187"


# our IP header
u class IP(Structure):
_fields_ = [
("ihl", c_ubyte, 4),
("version", c_ubyte, 4),
("tos", c_ubyte),
("len", c_ushort),
("id", c_ushort),
("offset", c_ushort),
("ttl", c_ubyte),
("protocol_num", c_ubyte),
("sum", c_ushort),
("src", c_ulong),
("dst", c_ulong)
]


def __new__(self, socket_buffer=None):
return self.from_buffer_copy(socket_buffer)


def __init__(self, socket_buffer=None):


# map protocol constants to their names


self.protocol_map = {1:"ICMP", 6:"TCP", 17:"UDP"}


v # human readable IP addresses


self.src_address = socket.inet_ntoa(struct.pack("<L",self.src))
self.dst_address = socket.inet_ntoa(struct.pack("<L",self.dst))


# human readable protocol
try:
self.protocol = self.protocol_map[self.protocol_num]
except:
self.protocol = str(self.protocol_num)


# this should look familiar from the previous example
if os.name == "nt":
socket_protocol = socket.IPPROTO_IP
else:
socket_protocol = socket.IPPROTO_ICMP


sniffer = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket_protocol)


sniffer.bind((host, 0))
sniffer.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)


if os.name == "nt":


sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)

try:


while True:


# read in a packet
w raw_buffer = sniffer.recvfrom(65565)[0]


# create an IP header from the first 20 bytes of the buffer
x ip_header = IP(raw_buffer[0:20])


# print out the protocol that was detected and the hosts
y print "Protocol: %s %s -> %s" % (ip_header.protocol, ip_header.src_¬
address, ip_header.dst_address)


# handle CTRL-C
except KeyboardInterrupt:

# if we're using Windows, turn off promiscuous mode
if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)

The first step is defining a Python ctypes structure u that will map the first 20 bytes of the received buffer into a friendly IP header. As you can see, all of the fields that we identified and the preceding C structure match up nicely. The __new__ method of the IP class simply takes in a raw buffer (in this case, what we receive on the network) and forms the structure from it. When the __init__ method is called, __new__ is already finished processing the buffer. Inside __init__, we are simply doing some housekeeping to give some human readable output for the protocol in use and the IP addresses v.
With our freshly minted IP structure, we now put in the logic to continually read in packets and parse their information. The first step is to read in the packet w and then pass the first 20 bytes x to initialize our IP structure. Next, we simply print out the information that we have captured y.
Let’s try it out.

Kicking the Tires

Let’s test out our previous code to see what kind of information we are extracting from the raw packets being sent. I definitely recommend that you do this test from your Windows machine, as you will be able to see TCP, UDP, and ICMP, which allows you to do some pretty neat testing (open up a browser, for example). If you are confined to Linux, then perform the previous ping test to see it in action.

Open a terminal and type:

python sniffer_ip_header_decode.py

Now, because Windows is pretty chatty, you’re likely to see output immediately.
I tested this script by opening Internet Explorer and going to www
.google.com, and here is the output from our script:

Protocol: UDP 192.168.0.190 -> 192.168.0.1
Protocol: UDP 192.168.0.1 -> 192.168.0.190
Protocol: UDP 192.168.0.190 -> 192.168.0.187
Protocol: TCP 192.168.0.187 -> 74.125.225.183
Protocol: TCP 192.168.0.187 -> 74.125.225.183
Protocol: TCP 74.125.225.183 -> 192.168.0.187
Protocol: TCP 192.168.0.187 -> 74.125.225.183

Because we aren’t doing any deep inspection on these packets, we can only guess what this stream is indicating. My guess is that the first couple of UDP packets are the DNS queries to determine where google.com lives, and the subsequent TCP sessions are my machine actually connecting and downloading content from their web server. To perform the same test on Linux, we can ping google.com, and the results will look something like this:

Protocol: ICMP 74.125.226.78 -> 192.168.0.190
Protocol: ICMP 74.125.226.78 -> 192.168.0.190
Protocol: ICMP 74.125.226.78 -> 192.168.0.190

You can already see the limitation: we are only seeing the response and only for the ICMP protocol. But because we are purposefully building a host discovery scanner, this is completely acceptable. We will now apply the same techniques we used to decode the IP header to decode the ICMP messages. Stay tuned for the next post.

How to Sniff a Network: Packet Sniffing on Windows and Linux

Network sniffers allow you to see packets entering and exiting a target machine. As a result, they have many practical uses before and after exploitation. In some cases, you’ll be able to use Wireshark (https://wireshark.org/) to monitor traffic or use a Pythonic solution like Scapy (which we’ll explore in the later posts). Nevertheless, you can read more: How to Sniff a Network : Raw Sockets and Sniffing.

 

Accessing raw sockets in Windows is slightly different than on its Linux brethren, but we want to have the flexibility to deploy the same sniffer to multiple platforms. We will create our socket object and then determine which platform we are running on. Windows requires us to set some additional flags through a socket input/output control (IOCTL),1 which enables promiscuous mode on the network interface. In our first example, we simply set up our raw socket sniffer, read in a single packet, and then quit.

import socket
import os
# host to listen on
host = "192.168.0.196"

# create a raw socket and bind it to the public interface
if os.name == "nt":
u socket_protocol = socket.IPPROTO_IP
else:
socket_protocol = socket.IPPROTO_ICMP
sniffer = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket_protocol)
sniffer.bind((host, 0))

# we want the IP headers included in the capture
v sniffer.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)

# if we're using Windows, we need to send an IOCTL
# to set up promiscuous mode
w if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)

# read in a single packet
x print sniffer.recvfrom(65565)

# if we're using Windows, turn off promiscuous mode
y if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)

We start by constructing our socket object with the parameters necessary for sniffing packets on our network interface u. The difference between Windows and Linux is that Windows will allow us to sniff all incoming packets regardless of protocol, whereas Linux forces us to specify that we are sniffing ICMP. Note that we are using promiscuous mode, which requires administrative privileges on Windows or root on Linux. Promiscuous mode allows us to sniff all packets that the network card sees, even those not destined for your specific host. Next we set a socket option that includes the IP headers in our captured packets. The next step w is to determine if we are using Windows, and if so, we perform the additional step of sending an IOCTL to the network card driver to enable promiscuous mode. If you’re running Windows in a virtual machine, you will likely get a notification that the guest operating system is enabling promiscuous mode; you, of course, will allow it. Now we are ready to actually perform some sniffing, and in this case we are simply printing out the entire raw packet x with no packet decoding. This is just to test to make sure we have the core of our sniffing code working. After a single packet is sniffed, we again test for Windows, and disable promiscuous mode y before exiting the script.

Kicking the Tires

Open up a fresh terminal or cmd.exe shell under Windows and run the
following:

python sniffer.py

In another terminal or shell window, you can simply pick a host to ping.
Here, we’ll ping nostarch.com:

ping nostarch.com

In your first window where you executed your sniffer, you should see
some garbled output that closely resembles the following:

('E\x00\x00:\x0f\x98\x00\x00\x80\x11\xa9\x0e\xc0\xa8\x00\xbb\xc0\xa8\x0
0\x01\x04\x01\x005\x00&\xd6d\n\xde\x01\x00\x00\x01\x00\x00\x00\x00\x00\
x00\x08nostarch\x03com\x00\x00\x01\x00\x01', ('192.168.0.187', 0))

You can see that we have captured the initial ICMP ping request destined for nostarch.com (based on the appearance of the string nostarch.com).
If you are running this example on Linux, then you would receive the response from nostarch.com. Sniffing one packet is not overly useful, so let’s add some functionality to process more packets and decode their contents in the following post.

 

How to Sniff a Network : Raw Sockets and Sniffing

Network sniffers allow you to see packets entering and exiting a target machine. As a result, they have many practical uses before and after exploitation. In some cases, you’ll be able to use Wireshark (https://wireshark.org/) to monitor traffic or use a Pythonic solution like Scapy (which we’ll explore in the later posts). Nevertheless, there’s an advantage to knowing how to throw together a quick sniffer to view and decode network traffic. Writing a tool like this will also give you a deep appreciation for the mature tools that can painlessly take care of the finer points with little effort on your part. You will also likely pick up some new Python techniques and perhaps a better understanding of how the low-level networking bits work.

In the previous chapter, we covered how to send and receive data using TCP and UDP, and arguably this is how you will interact with most network services. But underneath these higher-level protocols are the fundamental building blocks of how network packets are sent and received. You will use raw sockets to access lower-level networking information such as the raw IP and ICMP headers. In our case, we are only interested in the IP layer and higher so we won’t decode any Ethernet information. Of course, if you intend to perform any low-level attacks such as ARP poisoning or you are developing wireless assessment tools, you need to become intimately familiar with Ethernet frames and their use. Let’s begin with a brief walkthrough of how to discover active hosts on a
network segment.

 

Building a UDP Host Discovery Tool

The main goal of our sniffer is to perform UDP-based host discovery on a target network. Attackers want to be able to see all of the potential targets on a network so that they can focus their reconnaissance and exploitation attempts. We’ll use a known behavior of most operating systems when handling closed UDP ports to determine if there is an active host at a particular IP address. When you send a UDP datagram to a closed port on a host, that host typically sends back an ICMP message indicating that the port is unreachable. This ICMP message indicates that there is a host alive because we’d assume that there was no host if we didn’t receive a response to the UDP datagram. It is essential that we pick a UDP port that will not likely be used, and for maximum coverage, we can probe several ports to ensure we aren’t hitting an active UDP service. Why UDP? There’s no overhead in spraying the message across an entire subnet and waiting for the ICMP responses to arrive accordingly. This is quite a simple scanner to build with most of the work going into decoding and analyzing the various network protocol headers. We will implement this host scanner for both Windows and Linux to maximize the likelihood of being able to use it inside an enterprise environment. We could also build additional logic into our scanner to kick off full Nmap port scans on any hosts we discover to determine if they have a viable network attack surface. These are exercises left for the reader, and I look forward to hearing some of the creative ways you can expand this core concept.
Let’s get started.

 

Network sniffing

Additional Resources for Week 3 RITx: CYBER501x Cybersecurity Fundamentals

Kerckhoff’s Principle

Encryption

This video explains how the RSA public key and private key are created to be fully dependent on each other. The first part of the video explains the concepts with paint and colors. The second part contains heavy duty math, which may not be as easily understood:

Heartbleed

These links detail the Heartbleed bug from 2014. This vulnerability shows that even though data is protected both in transit and at rest with encryption, data that is being processed is not protected. The encrypted data needs to be decrypted before it’s processed, and therefore is vulnerable at this stage.

 

Week 3 Additional Resources

Additional Resources for Week 2 RITx: CYBER501x Cybersecurity Fundamentals

Authentication

Exploits

Non-Human Threats

The Verizon Data Breach Investigations Report

Each year, Verizon publishes its Verizon Data Breach Investigations Report (DBIR), which lists and examines thousands of incidents from around the world. Verizon uses that data to create the Data Breach Digest, detailed case studies of cyber crimes that illustrate many of the common or emerging cyber threats.

You will use the Data Breach Digest to delve into a cybercrime case study for an activity in section 2.3.

 

Week 2 Additional Resources

 

Site Security Policy Development

Abstract

Computer systems are powerful tools that touch upon many aspects of life in modern society. They can be used to enhance the quality of life or degrade it. The impact of this effect may range from negligible to the dramatic.

In order to ensure that computer systems are used in an effective and productive way, it is important that the owners, operators and users of these systems have a clear understanding of acceptable standards of use. Such an understanding can be gained as part of a Site Computer Security Policy.

The security requirements of computer systems owned and operated by one organisation will almost certainly differ from the requirements of another organisation. It is, therefore, important that each organisation formulates its own Site Computer Security Policy.

This paper outlines some issues that the writer of a Site Computer Security Policy may need to consider when formulating such a document.

Disclaimer

The information contained in this paper is given freely as an account of the author’s own experience, and may be used by the reader as the reader sees fit.

No responsibility or liability will be accepted by the author or the author’s employer for any damages caused by direct or indirect use of the information or functionality described in this paper.

1.0 What Is A Site Computer Security Policy?

In the same way that any society needs laws and guidelines to ensure safety, organisation and parity, so any organisation requires a Site Computer Security Policy (CSP) to ensure the safe, organised and fair use of computational resources.

The use of computer systems pervades many aspects of modern life. They include academic, engineering, financial and medical applications. When one considers these roles, such a policy assumes a large degree of importance.

A CSP is a document that sets out rules and principles which affect the way an organisation approaches problems.

Furthermore, a CSP is a document that leads to the specification of the agreed conditions of use of an organisation’s resources for users and other clients. It also sets out the rights that they can expect with that use.

Ultimately a CSP is a document that exists to prevent the loss of an asset or its value. A security breach can easily lead to such a loss, regardless of whether the security breach occurred as a result of an Act of God, hardware or software error, or malicious action internal or external to the organisation.

2.0 Why Does An Organisation Need A Site Computer Security Policy?

In addition to the benefits outlined above, a CSP offers an organisation the following benefits:

(a) It helps to make decisions with regard to other policies. It is not uncommon for a policy on a particular matter to refer to other policies. For instance, a CSP may refer to a policy on Copyright or a policy on dealing with the Press. Similarly, other policies may need to refer to specific sections of a CSP. This obviously is not possible if a CSP has not been formulated.

(b) It helps in making purchasing decisions. A CSP offers guidelines for standards of protection required on particular classes of computer systems. If a software or hardware component under consideration for purchase could be used to (or will actually) compromise these standards, then this may have an influence on whether the component is purchased.

(c) A CSP forms a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP may contain guidelines of what authority particular people have to take certain actions to minimise the impact of that breach. Furthermore, after the breach, the policy will provide guidelines regarding the course of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach. This removes the scope for independent reasoning at inappropriate times.

(d) A CSP should be considered as a living, long-term document that provides guidelines for the development of procedures applied to an organisation’s computer systems on a regular or day-to-day basis. These procedures would be described in a Site Procedures Manual, and would be concerned with the specifics of an organisation’s computer system and networking resources. Whereas the CSP describes principles (not implementation specifics) and should only ever be changed infrequently (when necessary), the Site Procedures Manual would be more volatile.

(e) Similarly to the above, a CSP will offer a framework for computer system configuration and network design and configuration.

(f) Because the development and enforcement of a CSP (and a Site Procedures Manual) is a non-trivial task, the existence and use of these documents is testament to the commitment of an organisation to professionalism.

(g) An important aspect of law is that ignorance is no excuse. Similarly, a well formulated and well advertised CSP leaves all people who have contact with an organisation’s computer systems with a clear understanding of what constitutes acceptable behaviour, effectively removing ignorance of acceptable standards as an excuse for antisocial behaviour. (The reader should note that acceptable behaviour standards form only one part of a CSP, as explained in Section 4, What Does a Site Computer Security Policy Contain?.)

(h) A CSP may be required by an auditor in the course of an organisational audit.

3.0 What Are The Characteristics Of A Site Computer Security Policy?

An effectively written CSP should have the following characteristics:

(a) It should be useful, and preferably written in a form that is easy to read (implying usable and understandable English).

(b) It will be structured in a form that lends itself to finding relevant sections of the policy easily.

(c) Initial forms, and subsequent updates should be versioned and dated.

(d) In order to have any authority, it must be accepted as the official reference document by the authoritative people in the organisation.

(e) It must set out principles only. It should be written with the intention that it will be a living reference document, used over a long period of time, with infrequent (and preferably none) changes during its lifetime.

(f) It must be carefully worded. The key to preparing a policy document is to ensure that all terms are accurately and precisely defined, and that these terms are used exactly as they are intended. A careful balance must be achieved in the wording of concepts. Each concept must be worded precisely enough to effectively communicate the meaning of the concept, but not so precisely so as to be dependent upon a particular technology, or to otherwise unintentionally allow a breach of the intention (if not the wording) of the concept.

(g) A CSP should be considered as a parent document to a Site Procedures Manual, and prepared as such.

(h) Not only must a CSP set out acceptable conditions of use, but it should also set out unacceptable conditions of use.

(i) The CSP should be widely advertised to those people who are affected by it. Furthermore, there should be a section in the CSP about the advertising of the CSP.

(j) Because the CSP is intended to be a living document, it should be reviewed at regular intervals, and at any other time required. Furthermore, there should be a section in the CSP about these reviews.

(k) The CSP must not simply be an Acceptable Usage Policy (that is a policy on acceptable behaviour of users of computer systems). The CSP must also outline what rights and expectations of the resource provider users have with regard to the use of computer systems, guidance on various issues for system managers and decision makers, definitions of terms and so on.

4.0 What Does A Site Computer Security Policy Contain?

A CSP can be viewed as a document of three distinct parts, all of which are necessary, but within themselves not sufficient.

The first part outlines the parameters within which the policy will operate, and may consist of many sections.

The second part of the policy is essentially a risk analysis, which discusses assets that need to be protected, the threats that may cause damage to the assets, and the mechanisms that may be used to realise these threats. The material in this part forms the logic behind the rules and guidelines that form the actual security policies that are formally defined in the third part.

The following material outlines issues that the author of a CSP may like to address in the document. This is not necessarily exhaustive, and the content of the CSP ultimately rests with its author.

4.1 Abstract

The abstract should set out what the document is and the organisation for whom it has been written.

4.2 Context

This section should outline the context within which the resources under the control of the policy operate. For instance, a private company may not be connected to any network outside of its own domain, or on the other hand, it may be connected to banks throughout the world. A CSP for a university may describe the significance of Internet and AARNet, and the relationship of these entities with the campus network.

This context is important as it effectively determines what the governing policies are of the CSP, and influences the philosophy and procedural guidelines set out in the CSP.

4.3 Philosophy and Functions

The writer of a CSP will inevitably be faced with several alternatives when deciding on a particular policy for a particular issue. The classic instance of such a dilemma occurs when one determines that a compromise of a computer system is actively in progress, and that the compromise possibly includes a breach of Commonwealth Law. Does the system manager take steps to reduce the impact of the compromise (by, for example, disconnecting the compromised network from the source of the compromise), or does the system manager allow the compromise to continue in an attempt to identify the attacker at the risk of damaging or losing resources permanently?

The basic philosophy that should be used when constructing policies that may be used for making non-deterministic decisions should be outlined in this section.

The writer should also outline the functions that the CSP is expected to serve within the organisation. Similarly to the philosophy behind the CSP, the functions that the CSP will serve will affect the content of the CSP.

4.4 Definitions

As mentioned earlier in this paper, the key to writing an effective CSP is accurate and precise definitions of terms. Any term that may have any ambiguity attached to it must be defined in a precise manner. Any loopholes left in this section or in the sections regarding the rights and responsibilities of users and resource providers may be exploited by people in order to circumvent the CSP.

For instance, consider a policy which states, in part, that “all accounts must be protected by a password”. This obviously precludes the use of guest accounts with no passwords. However, what effect does this have on anonymous ftp? Is it conceivable that one could make a case that the anonymous account is not password protected since any password could be used to access the account?

What constitutes an account? The login identifier only, or the resources associated with the account? Does the account holder own the account and those resources, or does the resource provider? Should the term “account” be omitted, and replaced by the concepts “user account”, “privileged account” and “public access account”?

When a policy refers to a Chief Executive Officer (CEO) of an organisation, should the term “Chief Executive Officer” be redefined to include the CEO and agents of the CEO, where an agent is any person authorised by the CEO to be such? If not, then the policy may award the CEO many rights and tasks, leaving nobody else with any rights or tasks at all, let alone the authority to act in the absence of the CEO!

Two of the most critical concepts that must be clarified are the concepts of authorisation and permission. At a technical level, is permission simply granted by access permission bits on a file, or is permission a combination of technical feasibility and authority to carry out an activity? Is authority implicit with technical feasibility, is it a property that must be explicitly granted, or is it a property associated with position?

These are but a sample of the terms that need to be defined for a CSP. This (crucial) section should be carefully and painstakingly constructed, and whenever there is any doubt as to whether a term should be defined, or what the definition should be, then one should err on the side of caution.

4.5 Governing Policies

It is important to make mention of the policies which govern the CSP.

The CSP may only make mention of policies that directly affect it, rather than get bogged down in all policies that may indirectly affect the document in varying degrees for pragmatic reasons. Examples of such direct policies include Commonwealth Law, State Law, (perhaps) the AARNet Acceptable Usage Policy and the “Terms and Conditions of AARNet Network Affiliate Membership” document (if appropriate). Other policies internal to the organisation may also be referred to in this section.

It is recognised that the content of this section is affected by external influences. However, it is these same external influences that affect the content of the CSP as a whole, and the interpretation of it. By including references to the governing policies, content of the CSP is simplified, and guidelines for action in the event of a security breach are automatically provided should such a breach influence an organisation’s environment.

However, because of the external nature of these governing policies, interpretation of them in this section should be kept to a minimum (again for pragmatic reasons).

4.6 Authority

In order to be effective, the CSP must be the product of a directive from an influential and authoritative person within the organisation.

It is important to define the driving force behind the development and implementation of the policy. Furthermore, this section must outline the person who has ultimate authority in the interpretation and application of it to a particular situation, particularly in lieu of any issue that may be addressed in subsequent sections.

Another consideration when writing this section is that of allowing for flexibility. That is, decision makers may need a clause in the policy that allows for a policy statement to be temporarily waived from time to time by a person of authority under certain conditions or guidelines. Such a clause allows those in authority to act with initiative (and still within policy boundaries) should unusual situations arise.

4.7 Distribution

The organisation should formally define the standards it will adhere to ensure that the people affected by the policy are appropriately informed of its contents (as is its moral responsibility).

4.8 Review

A CSP that is prepared in a final form and never reviewed for the appropriateness of its contents during its lifetime may quickly become a document that is either cumbersome or useless. This section should formally set out the periodicy and necessity for reviews of the CSP.

4.9 Risk Analysis

The previous sections set out the parameters within which the policy will be effective. This section outlines the assets that must be protected, and from what threats. This is necessary to provide the underlying logic for the following sections which formally define the rules that apply to the use of those assets.

The preparation of this section can be laborious and can require a great deal of insight. The depth of this analysis is up to the organisation and the uses to which the CSP will be put. For instance, if the CSP is expected to be heavily used in making purchasing decisions, particularly with regard to asset defence, then a full financial and likelihood analysis of the impact of any and all realised threats may be required. However, if this is not one of the main purposes of the CSP, then this section may only need to outline the assets, threats and vulnerabilities which ultimately justify the logic behind the following sections.

It is essential that in its most minimal form, this section has at least three subsections.

In the first subsection, a list of various asset categories must be provided, since the loss of an asset represents a significant loss to the organisation. In some cases, a lost asset cannot be replaced, particularly in the case of goodwill, trust, or confidential research. Examples of asset categories include:

- documentation;
- goodwill and reputation;
- hardware;
- people and skills; and
- software.

A discussion of these assets should include some indication of the size and type of investment that the asset represents, the impact on the organisation of the loss of the asset and how easily replaceable (if at all) the asset is. When considering assets in the information category, it is important to emphasise that a loss may be suffered simply by unauthorised access to that information, even if that information is still available to the organisation.

The loss of an asset is caused by the realisation of a threat. The threat is realised via the medium of a vulnerability. Threats cannot be controlled within an organisation as a threat is essentially a product of the organisation’s environment. This is not so for vulnerabilities, which usually exist within the organisation. Hence the purpose of the security policy and its associated procedures is to minimise the number and size of any vulnerabilities and thus negate any potential threat and its impact on an organisation’s assets should a threat be realised.

The second subsection might therefore be devoted to threats. Examples of threats that may be examined are:

- denial of service;
- destruction (of assets);
- disclosure of information;
- theft (of information or physical assets); and
- unauthorised access.

The examination of these threats might include a discussion on both the probable and maximum possible impact of the realisation of the threat upon the organisation, as well as the consequences for the organisation should these scenarios occur. It may also be useful to explore what further threats could be realised as a consequence of the realisation of an initial threat.

The third essential subsection must tie together the assets and threats to give some indication of the likelihood of and likely extent of damage of the threat being realised on the assets. This subsection therefore discusses vulnerabilities.

Vulnerabilities may differ from organisation to organisation. However, a possible categorisation of a vulnerability set may be:

- Host based:
     - Compromise;
     - Destruction;
- Network based:
     - Destruction;
     - Eavesdropping;
     - Flooding;
- Non-discriminatory (e.g. Acts of God); and
- Procedural.

This can be a difficult subsection to write. For each vulnerability identified, the following aspects might be discussed.

(a) Form, in which it is explained in understandable terms what the vulnerability is, possibly through the use of (or including) realistic examples.

(b) Type (whether the vulnerability allows a threat to be realised in a deliberate or accidental manner), as this may have a bearing on policies, procedures and penalties.

(c) Extent, in which it is discussed what type of threat(s) might be realised by the vulnerability, both in the first instance and subsequently (giving some justification for the statements regarding impact).

(d) Impact on the organisation, possibly in both financial and non-financial terms. The impact may be expressed as a range, rather than a discrete value. Examples of non- financial impact are “negligible”, “little” (where alternative workarounds are available with comparatively little effort and expense), and “complete” (the organisation will fold). The expression of non-financial impact is purely up to the ability, imagination and experience of the CSP author.

(e) Cause, in which a brief discussion is given of the primary reasons behind how and why the vulnerability may lead to the realisation of the threat.

(f) Solutions (possibly) to either effectively negate the cause or minimise the impact.

4.10 Rights and Responsibilities of Users

This section (and the next two) are the heart and soul of a CSP. It can be difficult to draw distinct lines between the rights and responsibilities of users and the resource provider, since many issues may be considered to be in the domain of either (privacy being one such issue). The key to writing this section and the next is to make a firm decision on which issues belong in which section (e.g. by preparing a detailed table of contents) and thus avoid duplication and complexity.

Issues that could be addressed in this section are listed below.

(a) Account use, by both the account holder and the resource provider. Special conditions may apply to the use of normal user accounts, and public access accounts (like anonymous ftp), and these conditions could be expressed here.

(b) Software and data access and use, including sources of data and software.

(c) Disclosure of information which is potentially harmful, such as password information or system configuration information.

(d) Etiquette, including acceptable forms of expression (e.g. non-offensive expression expected for unsolicited electronic mail), and unacceptable practices (such as the forging of electronic mail and news articles).

(e) Password use and format.

(f) Rights to privacy, and the circumstances under which the resource provider may intrude on the files held under or activities practiced by an account.

(g) Other miscellaneous guidelines regarding reasonable practices, such as the use of CPU cycles and temporary general access storage areas. Copyright issues may also be discussed here.

4.11 Rights and Responsibilities of the Resource Provider

There is a myriad of information that could be placed in this section. The content of this section assumes a large degree of importance (indeed, probably more than the previous section) when one considers recent statistics regarding the proportion of crimes involving computers that are committed by people internal (or recently internal) to the organisation.

Some (but by no means all) issues that could be addressed here include:

- backups;
- contact information;
- dial-up access;
- host configuration guidelines, including:
     - allocation of responsibility;
     - network connection guidelines;
     - authentication guidelines;
     - authority to hold and grant account guidelines;
     - auditing and monitoring guidelines;
     - password    format,   enforcement   and    lifetime
          guidelines; and
     - login banners;
- network  construction, configuration and use guidelines,
     including:
     - allocation of responsibility;
     - supported protocols;
     - network design principles;
     - address allocation and authority guidelines; and
     - use of network management and other equipment;
- physical security guidelines; and
- privacy guidelines.

There are no doubt many other issues and principles that could be discussed in this section. The content of this section is really a product of the basic philosophy of the organisation providing the resource.

4.12 Violation

A stated function of a CSP is to form a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP needs to offer to those who must take action, necessary guidelines as to what authority they have in order to minimise the impact of that breach. Furthermore, after the breach, the policy must provide guidelines for courses of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach.

It is therefore obvious that this section is also a non-trivial section concerned only with identification and discipline.

There could be a subsection devoted entirely to security incident handling principles. This subsection would be used directly in the construction of a set of procedures to be followed in the event of an actual security breach in progress. It could broach such issues such as:

  • parties who should be notified, and the method and urgency of such notification;
  • policy on the necessity, timing and requirements of any backups taken and logging that must be carried out;
  • computer system and network isolation authority and guidelines;
  • statement of entrapment policy (if this is not already expressed in the CSP philosophy); and
  • statement of policies and requirements should an alleged offender be traceable and possibly confronted (particularly where actions may be affected by external requirements such as a Statute dictating that Security Officers must identify themselves).

It may be desirable to also offer guidelines for liability of personnel with regard to security breaches. Such policies may tend to encourage people who are the victims of ignorance but honest intent to offer information that can be used constructively to prevent future incidents, rather than attempt to hide details of a breach that they may have (somewhat innocently) been involved in.

This section also needs to discuss, in some detail, guidelines regarding investigation of incidents and courses of action that could be taken by decision-makers based upon details of the security breach. Such guidelines may include guidelines about referral of various matters to law enforcement agencies, as well as internal investigation and disciplinary principles.

There should be some emphasis placed upon not only minimising the impact of and recovering from a security breach, should one occur, but also in learning any constructive lessons possible from an incident. The way in which this can be done is to carry out a post-mortem of incidents. Requirements for post-mortem procedures and reports could be outlined in this section. Such a post-mortem could include preparation of reports containing details like cause and effect of the incident, side-effects of the incident, costs involved in terms of losses and recovery, and possible repulsion and impact minimisation strategies should a similar incident occur in future.

5.0 Conclusion

The absence of a Site Computer Security Policy leaves a large void in any organisation’s ability to operate effectively and maintain business continuity, and allows for ad-hoc decisions to be made by unauthorised personnel. Conversely, a well written and easily understandable Site Computer Security Policy provides an effective basis for decision making and planning. It gives the providers and users of a resource a clear understanding of what is expected, and what may be expected in return. Adherence to such a policy lends some evidence to an organisation’s integrity and trustworthiness.


References

Caelli, W., Longley, D. and Shain, M., Information Security Handbook, Macmillan Publishers Ltd, 1991. ISBN 0-333-51172-7.

Site Security Policy Handbook Working Group, “Site Security Handbook”, RFC 1244, Internet Engineering Task Force, July 1991.

Netmask Translation Table

This is a Netmask Translation Table. It can be used to determine what IPs should be used and which ones cannot be used.

Netmask                CIDR         Notes
=====================================================================

255.255.255.255        /32          Host (single address)
255.255.255.254        /31          Unusable

255.255.255.252        /30            4 IPs with   2 Usable
255.255.255.248        /29            8 IPs with   6 Usable

255.255.255.240        /28           16 IPs with  14 Usable
255.255.255.224        /27           32 IPs with  30 Usable

255.255.255.192        /26           64 IPs with  62 Usable
255.255.255.128        /25          128 IPs with 126 Usable

255.255.255.0          /24         256 IPs with  254 Usable "Class C"

Note: The first and last IP of a series are NOT usable and the first  
usable IP is normally set up for the router.
The 1st IP is the network address. The last IP is the broadcast address.
=====================================================================

Each customer will be given their own unique IP block necessary to configure their own network. This unique IP information will be supplied by their Account Manager.

The below is only an EXAMPLE, do NOT use its IPs, instead, use those IP numbers that come from your Account Manager.

Your Account Manager should give you all the following information.

Dear Customer:

Your IP block is 205.177.54.32/28

Gateway IP address (Router IP)      205.177.54.33
Useable IP's                        205.177.54.34-46
Subnet Mask                         255.255.255.240

DNS Servers:    ns.cais.com         205.177.10.10
                ns2.cais.com        199.0.216.222



Subnetmask Translation Table

This is a Netmask Translation Table. It can be used to determine what IPs should be used and which ones cannot be used.

Subnetmask            Subnetmask (binary)                    CIDR         Notes
=================================================================================================

255.255.255.255       11111111.11111111.11111111.11111111    /32          Host (single address)

255.255.255.254       11111111.11111111.11111111.11111110    /31          Unusable
255.255.255.252       11111111.11111111.11111111.11111100    /30            4 IPs with   2 Usable
255.255.255.248       11111111.11111111.11111111.11111000    /29            8 IPs with   6 Usable
255.255.255.240       11111111.11111111.11111111.11110000    /28           16 IPs with  14 Usable
255.255.255.224       11111111.11111111.11111111.11100000    /27           32 IPs with  30 Usable
255.255.255.192       11111111.11111111.11111111.11000000    /26           64 IPs with  62 Usable
255.255.255.128       11111111.11111111.11111111.10000000    /25          128 IPs with 126 Usable
255.255.255.0         11111111.11111111.11111111.00000000    /24         256 IPs with  254 Usable 
                                                                                "Class C"

255.255.254.0         11111111.11111111.11111110.00000000    /23         
255.255.252.0         11111111.11111111.11111100.00000000    /22         
255.255.248.0         11111111.11111111.11111000.00000000    /21         
255.255.240.0         11111111.11111111.11110000.00000000    /20         
255.255.224.0         11111111.11111111.11100000.00000000    /19         
255.255.192.0         11111111.11111111.11000000.00000000    /18         
255.255.128.0         11111111.11111111.10000000.00000000    /17         
255.255.0.0           11111111.11111111.00000000.00000000    /16         
                                                                                "Class B"

255.254.0.0           11111111.11111110.00000000.00000000    /15         
255.252.0.0           11111111.11111100.00000000.00000000    /14         
255.248.0.0           11111111.11111000.00000000.00000000    /13         
255.240.0.0           11111111.11110000.00000000.00000000    /12         
255.224.0.0           11111111.11100000.00000000.00000000    /11         
255.192.0.0           11111111.11000000.00000000.00000000    /10         
255.128.0.0           11111111.10000000.00000000.00000000    /9          
255.0.0.0             11111111.00000000.00000000.00000000    /8         
                                                                                "Class A"

254.0.0.0             11111110.00000000.00000000.00000000    /7         
252.0.0.0             11111100.00000000.00000000.00000000    /6         
248.0.0.0             11111000.00000000.00000000.00000000    /5         
240.0.0.0             11110000.00000000.00000000.00000000    /4         
224.0.0.0             11100000.00000000.00000000.00000000    /3         
192.0.0.0             11000000.00000000.00000000.00000000    /2         
128.0.0.0             10000000.00000000.00000000.00000000    /1          
0.0.0.0               00000000.00000000.00000000.00000000    /0         
                                                                                IP space



Note: The first and last IP of a series are NOT usable and the first  
usable IP is normally set up for the router.
The 1st IP is the network address. The last IP is the broadcast address.
=====================================================================

Star Trek – Ransomware Brings us Monero and a Spock Decryptor!

Boldly going where no man has gone before, the Kirk Ransomware brings so much nerdy goodness to the table that it could make anyone in IT interested. We have Star Trek, Low Orbital Ion Cannons, a cryptocurrency payment other than Bitcoin, and a decryptor named Spock! Need I say more?

Discovered today by Avast malware researcher Jakub Kroustek, the Kirk Ransomware is written in Python and may be the first ransomware to utilize Monero as the ransom payment of choice.

Kirk Ransomware

At this time there are no known victims of this ransomware and it does not appear to be decryptable.  For those who want to discuss this ransomware or receive updates about it, they can subscribe to our Kirk Ransomware Support & Help topic.

Kirk Ransomware uses Monero for Ransom Payments

Ever since Monero was released, it has been highly touted as a more secure and anonymous payment system than Bitcoin. This has caused  underground criminal sites, like AlphaBay, to accept it as payment and for criminals to mine it using mining Trojans. It was only a matter of time until ransomware developers started requesting it.

For possibly the first time, with the release of Kirk Ransomware, Monero has been introduced as a ransom payment. The problem is that this is only going to confuse victims even more. Even with Bitcoin becoming more accepted, it is still not easy to acquire them. By introducing a new cryptocurrency into the mix, victims are just going to become more confused and make paying ransoms even more difficult.

How the Kirk Ransomware Encrypts a Computer

While it is not currently known how the Kirk Ransomware is being distributed, we do know that it is masquerading as the network stress tool called Low Orbital Ion Cannon.  Currently named loic_win32.exe, when executed Kirk Ransomware will now generate a AES password that will be used to encrypt a victim’s files. This AES key will then be encrypted by an embedded RSA-4096 public encryption key and saved in the file called pwd in the same directory as the ransomware executable.

If you plan on paying the ransom for the Kirk Ransomware, you must not delete the pwd file as it contains an encrypted version of your decryption key. Only the ransomware developer can decrypt this file and if a victim wishes to pay the ransom they will be required to send them this file.

Below is the current embedded RSA key used to encrypt the victim’s encryption key.

-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAoQpUk7lhDoenoPTCLRjGLStBjoT9owWl3HuYezrpmDt60t0P4/jlrwDC06POYxGpDDUbC2SfhcvbemFXWmX/zCM92h94v6sxfc6GOfKLbdwudSMOJ+TOSd7XGa3okcIbAh7bVR28XPBOGcg203Z/7YJh+wHHnjGjOxcUZIcM3X2BPDIEuc1jxgWgDEIMmjb+yi6m3YdtAmwmurV8wb61jXrBY936IVxYc3sxw94x9GjfsIspmdurV5En1DEkXPORp7IU5q6Zj4ZZsLwyT+xX5V5MdWVYhOJV4X8pLPHUPjvAHQX1POGnX/DVlieG//RXOi0mnR+Vh4OjvBsXC10VqrQgZZXByHOtjrdfXgZH8Izr+KuyTVRGILvj884EZ1DMI6L4sb4F9EUjcRacO/tURdduUTw3Q5qsbLPQiS/V4MBEQswlH7UVMiWxfNymyvM5I3BfFeW2QwauRGH5xmaDsQG0Yy/AsPzvHKqoShP/LepO1bYUdUodvnfVbChPGTYzZrwmnixS/m5AxyhUh/Ex3cxZ5raJWnBfx72wsviuAPIrXqyzlTlNo6aPX029Oh52ezk4uYwLpN02IjJ6yUEgyFkqbhASCtvYjqAprvCheane2j7+U7RnjZ+jLNgMWSc5M1pdGK4YYT+U3yfWqbdGRSie6e+LhifKADqjHeXSAVsCAwEAAQ==
-----END PUBLIC KEY-----

Kirk Ransomware will now display a message box that displays the same slogan as the LOIC network stress tool. This slogan is: “Low Orbital Ion Cannon | When harpoons, air strikes and nukes fail | v1.0.1.0”.

Fake Low Orbital Ion Cannon Alert
Fake Low Orbital Ion Cannon Alert

At this point, the ransomware infection will begin to scan the C: drive for files that have certain file extensions. At the time of this writing, Kirk Ransomware targets 625 file types, which are listed at the end of the article.

If a matching file is detected, it will encrypt it using the previously created AES encryption key and then append the .kirked extension to the encrypted file’s name. For example, a file called test.jpg would be encrypted and renamed to test.jpg.kirked.

When the ransomware finishes encrypting the files it will drop a ransom note called RANSOM_NOTE.txt in the same folder as the executable. It will also display the ransom note in a Window on your desktop. A full version of the ransom note can be see at the end of the article.

This ransom note tells the victim that they must purchase ~1,100 worth of the Monero currency and send it to the enclosed Monero address. Once a payment is made, the victim must email the pwd file and the payment transaction ID to the kirk.help@scryptmail.com or kirk.payments@scryptmail.com email addresses to receive the decryptor.

The Spock Decryptor

This wouldn’t be a Star Trek themed ransomware without Spock. The developer agrees as they have named the decryptor “Spock” and it will be supplied to the victim once a a payment is made.

The Spock Decryptor

At this time we have not seen a sample of the decryptor, so cannot provide more info regarding it.

As previously said, unfortunately at this time the ransomware does not look like it can be decrypted.  For those who want to discuss this ransomware or receive updates about it, they can subscribe to our Kirk Ransomware Support & Help topic.

 

IOCS:

Files associated with the Kirk Ransomware:

loic_win32.exe
pwd
RANSOM_NOTE.txt

Hashes:

SHA256: 39a2201a88f10d81b220c973737f0becedab2e73426ab9923880fb0fb990c5cc

Targeted File Extensions:

.cfr,  .ytd,  .sngw,  .tst,  .skudef,  .dem,  .sims3pack,  .hbr,  .hkx,  .rgt,  .ggpk,  .ttarch2,  .hogg,  .spv,  .bm2,  .lua,  .dff,  .save,  .rgssad,  .scm,  .aud,  .rxdata,  .mcmeta,  .bin,  .mpqe,  .rez,  .xbe,  .grle,  .bf,  .iwd,  .vpp_pc,  .scb,  .naz,  .m2,  .xpk,  .sabs,  .nfs13save,  .gro,  .emi,  .wad,  .15,  .vfs,  .drs,  .taf,  .m4s,  .player,  .umv,  .sgm,  .ntl,  .esm,  .qvm,  .arch00,  .tir,  .bk,  .sabl,  .bin,  .opk,  .vfs0,  .xp3,  .tobj,  .rcf,  .sga,  .esf,  .rpack,  .DayZProfile,  .qsv,  .gam,  .bndl,  .u2car,  .psk,  .gob,  .lrf,  .lts,  .iqm,  .i3d,  .acm,  .SC2Replay,  .xfbin,  .db0,  .fsh,  .dsb,  .cry,  .osr,  .gcv,  .blk,  .4,  .lzc,  .umod,  .w3x,  .mwm,  .crf,  .tad,  .pbn,  .14,  .ppe,  .ydc,  .fmf,  .swe,  .nfs11save,  .tgx,  .trf,  .atlas,  .20,  .game,  .rw,  .rvproj2,  .sc1,  .ed,  .lsd,  .pkz,  .rim,  .bff,  .gct,  .9,  .fpk,  .pk3,  .osf,  .bns,  .cas,  .lfl,  .rbz,  .sex,  .mrm,  .mca,  .hsv,  .vpt,  .pff,  .i3chr,  .tor,  .01,  .utx,  .kf,  .dzip,  .fxcb,  .modpak,  .ydr,  .frd,  .bmd,  .vpp,  .gcm,  .frw,  .baf,  .edf,  .w3g,  .mtf,  .tfc,  .lpr,  .pk2,  .cs2,  .fps,  .osz,  .lnc,  .jpz,  .tinyid,  .ebm,  .i3exec,  .ert,  .sv4,  .cbf,  .oppc,  .enc,  .rmv,  .mta,  .otd,  .pk7,  .gm,  .cdp,  .cmg,  .ubi,  .hpk,  .plr,  .mis,  .ids,  .replay_last_battle,  .z2f,  .map,  .ut4mod,  .dm_1,  .p3d,  .tre,  .package,  .streamed,  .l2r,  .xbf,  .wep,  .evd,  .dxt,  .bba,  .profile,  .vmt,  .rpf,  .ucs,  .lab,  .cow,  .ibf,  .tew,  .bix,  .uhtm,  .txd,  .jam,  .ugd,  .13,  .dc6,  .vdk,  .bar,  .cvm,  .wso,  .xxx,  .zar,  .anm,  .6,  .ant,  .ctp,  .sv5,  .dnf,  .he0,  .mve,  .emz,  .e4mod,  .gxt,  .bag,  .arz,  .tbi,  .itp,  .i3animpack,  .vtf,  .afl,  .ncs,  .gaf,  .ccw,  .tsr,  .bank,  .lec,  .pk4,  .psv,  .los,  .civ5save,  .rlv,  .nh,  .sco,  .ims,  .epc,  .rgm,  .res,  .wld,  .sve,  .db1,  .dazip,  .vcm,  .rvm,  .eur,  .me2headmorph,  .azp,  .ags,  .12,  .slh,  .cha,  .wowsreplay,  .dor,  .ibi,  .bnd,  .zse,  .ddsx,  .mcworld,  .intr,  .vdf,  .mtr,  .addr,  .blp,  .mlx,  .d2i,  .21,  .tlk,  .gm1,  .n2pk,  .ekx,  .tas,  .rav,  .ttg,  .spawn,  .osu,  .oac,  .bod,  .dcz,  .mgx,  .wowpreplay,  .fuk,  .kto,  .fda,  .vob,  .ahc,  .rrs,  .ala,  .mao,  .udk,  .jit,  .25,  .swar,  .nav,  .bot,  .jdf,  .32,  .mul,  .szs,  .gax,  .xmg,  .udm,  .zdk,  .dcc,  .blb,  .wxd,  .isb,  .pt2,  .utc,  .card,  .lug,  .JQ3SaveGame,  .osk,  .nut,  .unity,  .cme,  .elu,  .db7,  .hlk,  .ds1,  .wx,  .bsm,  .w3z,  .itm,  .clz,  .zfs,  .3do,  .pac,  .dbi,  .alo,  .gla,  .yrm,  .fomod,  .ees,  .erp,  .dl,  .bmd,  .pud,  .ibt,  .24,  .wai,  .sww,  .opq,  .gtf,  .bnt,  .ngn,  .tit,  .wf,  .bnk,  .ttz,  .nif,  .ghb,  .la0,  .bun,  .11,  .icd,  .z3,  .djs,  .mog,  .2da,  .imc,  .sgh,  .db9,  .42,  .vis,  .whd,  .pcc,  .43,  .ldw,  .age3yrec,  .pcpack,  .ddt,  .cok,  .xcr,  .bsp,  .yaf,  .swd,  .tfil,  .lsd,  .blorb,  .unr,  .mob,  .fos,  .cem,  .material,  .lfd,  .hmi,  .md4,  .dog,  .256,  .eix,  .oob,  .cpx,  .cdata,  .hak,  .phz,  .stormreplay,  .lrn,  .spidersolitairesave-ms,  .anm,  .til,  .lta,  .sims2pack,  .md2,  .pkx,  .sns,  .pat,  .tdf,  .cm,  .mine,  .rbn,  .uc,  .asg,  .raf,  .myp,  .mys,  .tex,  .cpn,  .flmod,  .model,  .sfar,  .fbrb,  .sav2,  .lmg,  .tbc,  .xpd,  .bundledmesh,  .bmg,  .18,  .gsc,  .shader_bundle,  .drl,  .world,  .rwd,  .rwv,  .rda,  .3g2,  .3gp,  .asf,  .asx,  .avi,  .flv,  .ai,  .m2ts,  .mkv,  .mov,  .mp4,  .mpg,  .mpeg,  .mpeg4,  .rm,  .swf,  .vob,  .wmv,  .doc,  .docx,  .pdf,  .rar,  .jpg,  .jpeg,  .png,  .tiff,  .zip,  .7z,  .dif.z,  .exe,  .tar.gz,  .tar,  .mp3,  .sh,  .c,  .cpp,  .h,  .mov,  .gif,  .txt,  .py,  .pyc,  .jar,  .csv,  .psd,  .wav,  .ogg,  .wma,  .aif,  .mpa,  .wpl,  .arj,  .deb,  .pkg,  .db,  .dbf,  .sav,  .xml,  .html,  .aiml,  .apk,  .bat,  .bin,  .cgi,  .pl,  .com,  .wsf,  .bmp,  .bmp,  .gif,  .tif,  .tiff,  .htm,  .js,  .jsp,  .php,  .xhtml,  .cfm,  .rss,  .key,  .odp,  .pps,  .ppt,  .pptx,  .class,  .cd,  .java,  .swift,  .vb,  .ods,  .xlr,  .xls,  .xlsx,  .dot,  .docm,  .dotx,  .dotm,  .wpd,  .wps,  .rtf,  .sdw,  .sgl,  .vor,  .uot,  .uof,  .jtd,  .jtt,  .hwp,  .602,  .pdb,  .psw,  .xlw,  .xlt,  .xlsm,  .xltx,  .xltm,  .xlsb,  .wk1,  .wks,  .123,  .sdc,  .slk,  .pxl,  .wb2,  .pot,  .pptm,  .potx,  .potm,  .sda,  .sdd,  .sdp,  .cgm,  .wotreplay,  .rofl,  .pak,  .big,  .bik,  .xtbl,  .unity3d,  .capx,  .ttarch,  .iwi,  .rgss3a,  .gblorb,  .xwm,  .j2e,  .mpk,  .xex,  .tiger,  .lbf,  .cab,  .rx3,  .epk,  .vol,  .asset,  .forge,  .lng,  .sii,  .litemod,  .vef,  .dat,  .papa,  .psark,  .ydk,  .mpq,  .wtf,  .bsa,  .re4,  .dds,  .ff,  .yrp,  .pck,  .t3,  .ltx,  .uasset,  .bikey,  .patch,  .upk,  .uax,  .mdl,  .lvl,  .qst,  .ddv,  .pta

Ransom Note Text:


                     :xxoc;;,..                                        .
                    cWW0olkNMMMKdl;.                       .;llxxklOc,'
                   oWMKxd,  .,lxNKKOo;.                  :xWXklcc;.     ...'.
           k      lMMNl   .    ON.                         :c.             ''.  ':....
          .WXc   ;WMMMXNNXKKxdXMM.                                                .    .
          .NdoK: XMMMMMMMMMMMMMMM;oo;                                ...;,cxxxll.       .
          .WX.K0'WMMMWMMMMMWMNXWMooMWNO'                         ..,;OKNWWWWMMMMMXk:.
           KK:xKKWMMMXNMMMMW;  .. :WNKd,                ..    .'cdOXKXNNNNNWWMMMMMMMW0,
           lNMXXMMMMMMMMWWMMWKk,  ;0k'                    .,cxxk0K0O0XXWWMMMMMMMMMMMMMMX:..   ..
            ..,;XMMMMMMMWXWWK0KK: .;.                    .:lddddxOOO0XWMMMMMMMMMMMMMMMMMMO.    .,
              .kKXMMMMMWkoxolcc;..                      .':loodxO00OO0NNXNWMMMMMMMMMMMMMMMN;     '.
              .MK;kWMMMWWKOc.  .                        ..';cdxkKNX0kOOOKNMMMMMMMMMMMMMMMMMW:    .
              ,MW:,:x0NMMMMWW0x'                          ..,:dXNWW0xkkKWMMMMMMMMMMMMMMMMMMWk.  ..
              oMMN;    ;odoccc;c:.                         ...lXWWMOok0NMMMMMWNXKXKXWMMMMMMMOc.
              XMMMX,                                    ....';lldkWkodK0loc'.  .'lxx0kOKNMMMXo.
            'XMMMMMNc                                            .dldXWx.      ..,,coOXOkXMMMK,
       ,.   .:dk0KNWMk.                                 ...        .kWMK,.  ..:c .:.. .0MWMMMMO.
  .':x0K0:.          ..   .                                 .      .OWMNNXO:cccdxKXWMW0o0WWMMMM;.
 00000000000kdl:,'.                                      ..'o00l   'KMMNKNWWNKXWWMMMMMMMMMMMMMM0.
 0000000000000000000Oxl:'                                .;xKWWx  .xNMMMWNMMMMMMMMMMMMMMMMMMMMMMl
 0000000000000000000000000x;. ..,::,.                  .ck0KKk'   '0WMMMMMMMWWMMMMMMMMMMMMMMMMMM0.   .'
 0000000000000000000000000000Oxdllc:;,....,'...       .cdkOko:     ,cOKKXWMMMKd0WMMMMMMMMMMMMMWW0. 'Kc:,
 000000000000000000000000000000000OkkkxdoodxOkoooool   .;okOx,       .,'...cKMXl'oKWMMMMMMMWWNXN0  'MMc0.
 0000OO000000000000000000000000000000000000000kc.      .:dk0c         ,KNKxdKMMM0;;kMMMMMMMMWNKXO  ,kW0xl
 OdloxO000000000000000000000000000000000000000000x,     .,ll;      .lokKWMMMMMMMMM0xNMMMMMMMNXXNo.xK;cXKx
 lx000000000000000000000000000000000000000000000000l     .'..    .'cKWXOXMMMMMMMMMMMMMMMMMWWNXXNKX0MNkNK0..
 00000000000000000000000000000000000000000000000000O      ..    ..,;ok0X000KKXWMNNMMMMMMMMNNXKKXX00MMMWWc',
 00000000000000000000000000000000000000000000000000d              .. ..........;;.cKMMMMMWNXKKXNKxkNMMX,
 000000000000000000000000000000000000000Ko.0000000Ol                .'::odkkOOOxxxoxNMMMMNNWNXKK0k..;'
 0000000000000000000000000000000000000000..:000000kl             .:coododkXWMMMMMMMWWMMMNNNNNKOkkx:
 :;ok00000000000000000000000000000000000O.;.d00000dc        ...   .........cONMMMMMMMMMNXXXN0dlddxN.
 .dk000000000000000000000000000000000000;ld,.O00kocc        ..    ...,;::lokKNMMMMMMMMWKOO0OxloocxM:
 OO0000000000000000000000000000000000000ol0Koc0xc:ll  .         ..;lxO0XNNMMMMMMMMMMMN0xoxOdl::,;0Md
 :;,'..;loxk000000000000000000000000000000000lx..loo ,0          .'';lkKKNMMMMMMMMMNOd:;lc:;'..,kWMK
 cccldxkkkO00Okdooddxk00000000000000000000000Oc'lddl dK,            .':ollokOOOOOOOc'.........lXMMMM,
 000000kdoc,....;cldkO0000000000000000000000Okdodddo'K0'.                   .......        .oKMMMMMM0
 :,'....',;:ldkO0000000000000000000000000000Okxodddd;Xk,...                              .l0NMMMMMMMM:
 OO000000000000000000000000000000000000000000OkodxxxoXo,,,..                           .:kKWMMMMMMMMMW'
 dO0000000000000000000000000000000000000000000OodxxxkKl;,,,,                          'dOKWMMMMMMMMMMMX

      _  _____ ____  _  __   ____      _    _   _ ____   ___  __  ____        ___    ____  _____ 
     | |/ /_ _|  _ \| |/ /  |  _ \    / \  | \ | / ___| / _ \|  \/  \ \      / / \  |  _ \| ____|
     | ' / | || |_) | ' /   | |_) |  / _ \ |  \| \___ \| | | | |\/| |\ \ /\ / / _ \ | |_) |  _|  
     | . \ | ||  _ <| . \   |  _ <  / ___ \| |\  |___) | |_| | |  | | \ V  V / ___ \|  _ <| |___ 
     |_|\_\___|_| \_\_|\_\  |_| \_\/_/   \_\_| \_|____/ \___/|_|  |_|  \_/\_/_/   \_\_| \_\_____|


Oh no! The Kirk ransomware has encrypted your files!


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

> ! IMPORTANT ! READ CAREFULLY:

Your computer has fallen victim to the Kirk malware and important files have been encrypted - locked
up so they don't work. This may have broken some software, including games, office suites etc.

Here's a list of some the file extensions that were targetted:

    .3g2      .rar      .jar      .cgi      .class    .jtd      .potx     .xex      .dds      
    .3gp      .jpg      .csv      .pl       .cd       .jtt      .potm     .tiger    .ff       
    .asf      .jpeg     .psd      .com      .java     .hwp      .sda      .lbf      .yrp      
    .asx      .png      .wav      .wsf      .swift    .602      .sdd      .cab      .pck      
    .avi      .tiff     .ogg      .bmp      .vb       .pdb      .sdp      .rx3      .t3       
    .flv      .zip      .wma      .bmp      .ods      .psw      .cgm      .epk      .ltx      
    .ai       .7z       .aif      .gif      .xlr      .xlw      .wotreplay.vol      .uasset   
    .m2ts     .dif.z    .mpa      .tif      .xls      .xlt      .rofl     .asset    .bikey    
    .mkv      .exe      .wpl      .tiff     .xlsx     .xlsm     .pak      .forge    .patch    
    .mov      .tar.gz   .arj      .htm      .dot      .xltx     .big      .lng      .upk      
    .mp4      .tar      .deb      .js       .docm     .xltm     .bik      .sii      .uax      
    .mpg      .mp3      .pkg      .jsp      .dotx     .xlsb     .xtbl     .litemod  .mdl      
    .mpeg     .sh       .db       .php      .dotm     .wk1      .unity3d  .vef      .lvl      
    mpeg4     .c        .dbf      .xhtml    .wpd      .wks      .capx     .dat      .qst      
    .rm       .cpp      .sav      .cfm      .wps      .123      .ttarch   .papa     .ddv      
    .swf      .h        .xml      .rss      .rtf      .sdc      .iwi      .psark    .pta      
    .vob      .mov      .html     .key      .sdw      .slk      .rgss3a   .ydk                
    .wmv      .gif      .aiml     .odp      .sgl      .pxl      .gblorb   .mpq                
    .doc      .txt      .apk      .pps      .vor      .wb2      .xwm      .wtf                
    .docx     .py       .bat      .ppt      .uot      .pot      .j2e      .bsa                
    .pdf      .pyc      .bin      .pptx     .uof      .pptm     .mpk      .re4                

There are an additional 441 file extensions that are targetted. They are mostly to do with games.

To get your files back, you need to pay. Now. Payments recieved more than 48 hours after the time of
infection will be charged double. Further time penalties are listed below. The time of infection has
been logged.

Any files with the extensions listed above will now have the extra extension '.kirked', these files
are encrypted using military grade encryption.

In the place you ran this program from, you should find a note (named RANSOM_NOTE.txt) similar to this one.
You will also find a file named 'pwd' - this is your encrypted password file. Although it was
generated by your computer, you have no way of ever decrypting it. This is due to the security
of both the way it was generated and the way it was encrypted. Your files were encrypted using
this password.

 ____  ____   ___   ____ _  __   _____ ___     _____ _   _ _____    ____  _____ ____   ____ _   _ _____ _ 
/ ___||  _ \ / _ \ / ___| |/ /  |_   _/ _ \   |_   _| | | | ____|  |  _ \| ____/ ___| / ___| | | | ____| |
\___ \| |_) | | | | |   | ' /     | || | | |    | | | |_| |  _|    | |_) |  _| \___ \| |   | | | |  _| | |
 ___) |  __/| |_| | |___| . \     | || |_| |    | | |  _  | |___   |  _ <| |___ ___) | |___| |_| | |___|_|
|____/|_|    \___/ \____|_|\_\    |_| \___/     |_| |_| |_|_____|  |_| \_\_____|____/ \____|\___/|_____(_)

  "Logic, motherfucker." ~ Spock.


Decrypting your files is easy. Take a deep breath and follow the steps below.

 1 ) Make the proper payment.
     Payments are made in Monero. This is a crypto-currency, like bitcoin.
     You can buy Monero, and send it, from the same places you can any other
     crypto-currency. If you're still unsure, google 'bitcoin exchange'.

     Sign up at one of these exchange sites and send the payment to the address below.

     Make note of the payment / transaction ID, or make one up if you have the option.

    Payment Address (Monero Wallet):
      4AqSwfTexbNaHcn8giSJw3KPiWYHGBaCF9bdgPxvHbd5A8Q3Fc7n6FQCReEns8uEg8jUo4BeB79rwf4XSfQPVL1SKdVp2jz

      Prices:
        Days   :  Monero  : Offer Expires
        0-2    :  50      : 03/18/17 15:32:14
        3-7    :  100     : 03/23/17 15:32:14
        8-14   :  200     : 03/30/17 15:32:14
        15-30  :  500     : 04/15/17 15:32:14

    Note: In 31 days your password decryption key gets permanently deleted.
          You then have no way to ever retrieve your files. So pay now.

 2 ) Email us.
     Send your pwd file as an email attachment to one of the email addresses below.
     Include the payment ID from step 1.

     Active email addresses:
        kirk.help@scryptmail.com
        kirk.payments@scryptmail.com

 3 ) Decrypt your files.
     You will recieve your decrypted password file and a program called 'Spock'.
     Download these both to the same place and run Spock.
     Spock reads in your decrypted password file and uses it to decrypt all of the
     affected files on your computer.

     > IMPORTANT !
       The password is unique to this infection.
       Using an old password or one from another machine will result in corrupted files.
       Corrupted files cannot be retrieved.
       Don't fuck around.

 4 ) Breathe.


       _     _____     _______    _     ___  _   _  ____ 
      | |   |_ _\ \   / / ____|  | |   / _ \| \ | |/ ___|
      | |    | | \ \ / /|  _|    | |  | | | |  \| | |  _ 
      | |___ | |  \ V / | |___   | |__| |_| | |\  | |_| |
      |_____|___|  \_/  |_____|  |_____\___/|_| \_|\____|
                         _    _   _ ____     ____  ____   ___  ____  ____  _____ ____  
                        / \  | \ | |  _ \   |  _ \|  _ \ / _ \/ ___||  _ \| ____|  _ \ 
                       / _ \ |  \| | | | |  | |_) | |_) | | | \___ \| |_) |  _| | |_) |
                      / ___ \| |\  | |_| |  |  __/|  _ <| |_| |___) |  __/| |___|  _ < 
                     /_/   \_\_| \_|____/   |_|   |_| \_\\___/|____/|_|   |_____|_| \_\



Full version of the Ransom Note:

Full Ransom Note