Reading Time: 20 minutes

Case 001 AutoRuns Analysis

Case 001 Brief and Materials.

Get the materials and follow along!

Have you built your DFIR Fort Kickass, yet? How to build a DFIR Analyst Workstation found here.

Make sure you understand the basic rundown of forensic artifacts.

This post assumes you have a DFIR Analyst Station ready to analyze the AutoRuns and Disk Images of the Domain Controller from The Case of the Stolen Szechuan Sauce.

Supporting the Website

Feel free to check out our shop if you want to support the website. The money goes to supporting our starving website dev and costs of hosting. It’s like buying us a cup of coffee!

 

---

Learning Objectives

• Be able to describe Autostart Extensibility Points (ASEP)
• Understand the importance of examining the ASEP’s on hosts
• Have functional knowledge of the Autorunsc tool and know when to deploy it

Semi-Required Knowledge

• Basic Linux Command Line Fu
• Basic Excel Spreadsheet use

Common Tools

• Excel or Open Office Calc
• SysInternals: Autoruns

Tools Covered Here

• Autorunsc (The C at the end means its the Console Version)

Other Learning Resources on this Topic

• Autoruns

Music

• Robot Music
• Metal Forensics

Notes

• Keep solid notes on your thinking around evidence and data that you find
  • This is for team mates to understand your thinking
  • Understand your own thinking later… or after sleep.
• Notes should be accompanied by screenshots that tell a story
  • Examples: Highlights, Boxes, Arrows Text. The reader should quickly understand what they’re looking at with the photo alone.
• A great note keeping App that teams can use to coordinate is OneNote.
  • Each host gets a tab etc.
• A great piece of software to take Screen Shots is Greenshot

Applicable Pivots

• From Disk Analysis: Malicious filenames or paths
• To Disk Analysis: Malicious filenames or paths, possibly IP addresses
• From Memory Analysis: Malicious Filenames or paths
• To Memory Analysis: Malicious IP Addresses, Malicious Filenames
• etc

---

AutoRuns Overview

What are AutoRuns?

“Autoruns” is a term used to refer to the collection of locations Windows looks for processes to start during boot time. From Microsoft’s Aaron Margosis and Mark Russinovich’s article about Autoruns:

Autostarts is the term I use to refer to software that runs automatically without being intentionally started by a user. This type of software includes drivers and services that start when the computer is booted; applications, utilities, and shell extensions that start when a user logs on; and browser extensions that load when Internet Explorer is started. Over 200 locations in the file system and registry allow autostarts to be configured on x64 versions of Windows. These locations are often referred to as Autostart Extensibility Points, or ASEPs.

ASEPs have legitimate and valuable purposes. For example, if you want your instant messaging contacts to know when you are online, having the messaging client start when you log on is a great help. Users enjoy search toolbars and PDF readers that become part of Internet Explorer. And much of Windows itself is implemented through ASEPs in the form of drivers, services, and Explorer extensions.

Aaron Margosis and Mark Russinovich are the experts on the matter. The take away here is that when Windows boots up it will automatically start a lot of software without any sort of intervention or interaction from the user.

Why Defenders Care about Autoruns

Malware is software. Malware isn’t some dark magic or sentient thing (yet). Software has to be told when to execute. ASEP’s are a very common way for both legitimate and malicious software to start on a Windows host. Defenders can often find the mechanisms malware is using to stay on a system by analyzing the data collected from using the Autorunsc tool. The mechanisms used by malware to stay on a system are commonly referred to as “Persistence”.

How are Autoruns Collected

Windows SysInternals is a collection of tools originally created by Mark Russinovich. These tools allow a in-depth view of things going on behind the scenes in a Windows Host. One of these tools is appropriately named Autoruns and Autorunsc. The former is GUI based where as the latter is run from the command line. The command line tool is preferred for incident responders as it lightweight and can easily be incorporated in forensic collection scripts. Autoruns is best run on a live host. Recently, there were some updates to the tool that allows it to be run against a dead box image. A dead box image is slang for an image of a hard drive taken from a live host and then examined offline. The images included in The Case of the Stolen Szechuan Sauce are dead box images. Chad Tilbury reports that while autoruns does have the ability to be run against a dead box image it wasn’t a great experience.

Autoruns Collection and Incident USB’s

Until dead box autoruns is improved it is recommended to gather the autoruns data from a live host when the disk and memory images are collected. One method of doing this is to include the Autorunsc program on the incident thumb drive. An incident thumb drive (or any external drive) is a removable drive loaded with the forensic evidence tools needed to get forensic artifacts from a compromised host. As modern networks are managed, and secured, remotely the logistics of this are not always easy. This has given rise to many platforms and tools being developed for defenders to reach their protected hosts from across the globe and retrieve artifacts remotely. This brings its own set of challenges outside the scope of this article. For local incidents (or admins being directed from afar) an incident drive should include items like:

• FTK Imager Lite to gather the disk and memory images
• Autorunsc to collect the ASEP data
• cmd.exe for various builds of Windows to avoid using a compromised version on the host
• FireEye/Mandiants Red Line Collector tool, Cyber Triage or Eric Zimmerman’s KAPE for forensics triage

These items would be run directly from the thumb drive to reduce the pollution of the victim system as much as possible. NOTE: artifact collection should go in order of volatility. This means collect the memory image, then the disk image, and finally the Autoruns. The following screen shots show an example incident drive, a 256 Gig USB 3.0 Thumb Drive, providing incident collection tools to be used on the victim host. The appropriate cmd.exe on the thumb drive was selected and run as Administrator. The command .\autorunsc64.exe -accepteula -a * -s -h -c > .\autoruns-citadeldc01.csv. Let’s break the command down:

• .\autorunsc64.exe runs Autorunsc64.exe from the thumbdrive
• -accepteula accepts the End User License Agreement
• -a * Show all startup locations
• -s Verify digital signatures
• -h Show file hashes
• -c Print as csv
• > .\autoruns-citadeldc01.csv redirect output to a CSV on the thumb drive with a name that tells us what is and what system it was collected from.

The incident responder now has an autoruns csv to examine offline on their DFIR Analysis Station.

Preparing for the Analysis of the CSV

The resultant CSV file from the autorunsc output is easily opened with LibreOffice Calc on your DFIR Analyst Station. Alternatively, it can be opened by Eric Zimmerman’s TimeLine Explorer tool. Eric Zimmerman’s TimeLine Explorer is a great tool for this – especially if you do not own Microsoft Excel. Regardless of the tool used the approach will be the same. If you have Indicators of Compromise (IOC) from other artifacts analysis prior to this point use those as pivots. Pivots are essentially keywords that can used as search terms to quickly find interesting things in large amounts of data. The second approach is to look at common locations for malware to hide. The CSV’s provided for the Case of the Stolen Szechuan Sauce are about 900 lines of data for the Domain Controller, and about 1300 for the Windows 10 Desktop. A good analyst will find ways to quickly move through the data.

Common Hiding Spots

A great reference for hunting persistence mechanisms is the checklist found on the Windows Forensic Analysis Poster. The newer version is included in the SIFT VM on the desktop. Just in case there is an older version here. The older one will work for this purpose. If you look at “Step 5” of the analysis process on the poster you will find a great checklist of items to search through on the poster.

All of these items should be checked on a compromised host. While autoruns certainly can’t see all of the items on the list it can catch most of them either directly or through related data. A checklist to run through while search autoruns might looks something like:

1. Scheduled Tasks
2. Services
3. Auto-start Registry Keys
4. Hijacks

CSV Viewing Tool Selection and Setup

Microsoft Excel

Open Excel then open the CSV through Excel’s File menu option. Then:

1. Select the option: delimited and Start import at row 1.
2. Check My data has headers and then Next.
3. Under delimiters select Comma
4. Optional: Select Date and MDY for the Time Column
5. Select Finish
6. Highlight first row by selecting the row 1 id of 1
7. CTRL+B to make the first row bold
8. Menu Item: View> Freeze Cells > Freeze Top Row
9. Menu Item: Data > Filter
10. Select the “funnel” icon in the main ribbon, or the menu item: Data > AutoFilter

LibeOffice Calc

Open LibreOffice then open the CSV through the LibreOffice File menu option. Then when the import menu appears:

1. Select Comma in the Separator options, then OK.
2. Select row 1 by selecting the row 1 id number of 1
3. CTRL+B to bolden the first row
4. Menu Item: View > Freeze Panes >Freeze Top Row

Eric Zimmerman’s Timeline Explorer

Open the CSV from the file menu.

Any of the 3 tools above will work great for this task. They all allow for easy searches and filtering of data.

Great intro to using Zimmerman’s TimeLine Explorer (3 Minute Video).

Autoruns Analysis

Regardless of the tool the general approach can look the same. Select an item from the checklist of persistent mechanisms to search for and isolate it. To isolate it have the viewing tool filter on that Category. For any of the 3 tools find the Category column and select the filter symbol (a small funnel or inverted triangle) next to it and ensure that only the targeted category is selected.

For example, to filter on the Scheduled Tasks of the host the analyst would select the filter symbol next to the word Category in the top row of the tool.

This filtering reduces our data from 902 lines to 77. That’s over 90% reduction in the noise. If we want to further reduce the noise we can filter out additional items. For example, if you wanted to remove Tasks that were “Signed” by Microsoft or other trusted sources from the noise you would simply deselect them from the Signer column filter.

Data Filters that Work Here

In the Citadel-DC01 Autoruns CSV this particular filter combo does bring us any wins. Some example filter combos to continue to searching the data for include (not all inclusive):

1. All data not signed by anyone
2. All ASEPS’s signed by an unknown or unfamiliar source
3. All ASEPS’s that is enabled and not signed by a trusted source
4. All ASEP’s that is enabled and there is no company associated with the ASEP.
5. All ASEP’s found at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
6. All ASEP’s found with the Description of Windows PowerShell
7. All ASEP’s found top be enabled and in the Logon category

 

Pitfalls and Things to Try

• Don’t fall for the trap of thinking all malicious ASEP’s will be signed or fall in the date range of the incident. For example, if the adversary is using PowerShell to kick off the malicious script it will appear signed by Microsoft because PowerShell itself is signed.
• Once you think you have something interesting located take a look at the Image Path and the Launch String columns for your interesting findings. Keep in mind items like PowerShell will simply show up as a signed version of PowerShell if its the legitimate version of PowerShell calling on an evil script.
• Go ahead and give it a whirl. Can you find anything on your own using the knowledge above?

---

Spoilers ahead.

 

 

 

 

 

 

 

 

 

You should find 2 interesting items.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

If you didn’t find anything that is OK. This takes practice and patience. For the first interesting item filter on the ASEP’s where the Image Path is  c:\windows\system32\windowspowershell\v1.0\powershell.exe? Look at the Launch String. It is %COMSPEC% /b /c start /b /min powershell -nop -w hidden -c "sleep 0; iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((Get-Item 'HKLM:Software\9sEoCawv').GetValue('45SVAG2o'))))"". This could also been found when looking at “All ASEP’s found top be enabled and in the Logon category” portion mentioned above.

What in the world is that? The first thing that should catch the eye of an analyst is that this is PowerShell trying to hide (hidden), invoke an expression (iex) of string of Base64 from an odd looking registry key. That is enough to immediately demand further scrutiny. Let’s dig into that one.

Registry Rabbit Hole (1st Finding)

To dig into the registry the analyst must have the victim hard drive mounted. If the drive is not mounted please see this walk-through on how to do so. After mounting the Domain Controllers drive image navigate to the standard location of the windows registry. This should will be /Windows/System32/config. If that is mounted at /mnt/windows_mount the full path in SIFT-REMnux would be:/mnt/windows_mount/Windows/System32/config.

Eric Zimmerman’s Registry Explorer

Retrieving Hives of Interest

1. Make a directory to store the DC Reg Hives we are interested in. For now we are really only interested in SOFTWARE but lets grab SYSTEM while we are it.
2. Copy the SYSTEM hive over to our new directory.
3. Copy the SOFTWARE hive over to our new directory.
4. Change to that directory.
5. zip up the hives for transportation. We don’t need to password protect since these aren’t suspected malware files.
6. Use the GUI to copy the new zip to the clip board.
7. Paste to a place on your host, then copy that file and paste it into your Windows Forensics box.

Voila. We have it positioned for examination with Eric Zimmerman’s Registry Explorer Tool.

When it asks if you want to replay the transaction logs answer, No. Then select Yes when it asks if you want to load a dirty hive.

Investigating the Malicious Launch String in the Registry

Recall the suspicious item from the from the autoruns Launch String at one of the CurrentVersion\Runs locations. It was:
%COMSPEC% /b /c start /b /min powershell -nop -w hidden -c "sleep 0; iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((Get-Item 'HKLM:Software\9sEoCawv').GetValue('45SVAG2o'))))""


Reading through this does not require you understand every piece of what it is doing. This should be a goal but it’s not required. In short it is calling on PowerShell to run a command in the background. The command is directing PowerShell to Invoke an Expression (iex) of a Base64 string located in the Registry SOFTWARE hive. It is looking to load that Base64 string presumably found in the value name of <code>45SVAG2o</code>  under the Key 9sEoCawv. In other words, it is directing PowerShell to go to SOFTWARE\9sEoCawv\45SVAG2o, retrieve a string of Base64, and execute it. Anything trying this hard to hide is immediately very interesting to us.

Using Registry Explorer to follow the path we find this:

Note the date and time of the last write to this registry key. This will likely indicate when the value was placed here. If this value turns out to in fact be a persistence mechanism this will tell us when the adversary was installing malware on our victim server.

Translating the Base64 with Cyber Chef

One of the quickest ways to translate the Base64 is to use Cyber Chef. Cyber Chef is an amazing tool kit. It is already installed in your SIFT-REMnux box, or can be accessed with a web browser. To load it in your SIFT-REMnux box locally simply hit the favorite/special key on your keyboard and type Cyberchef and hit enter. If you are using a web browser search for Cyber Chef and go to their .io github page.

Chef Recipe

1. From the Favorites tab on the left drag From Base64 to the recipe.
2. Then go to Utils and drag in Remove null bytes.
3. You’re now ready to bake the first layer!
4. Copy the huge chunk of Base64 by selecting it in registry explorer (the base64 will highlight in all blue). Press CTRL+C to copy it to the keyboard
5. Then drop it (paste it) into the Input section of Cyber Chef.

 

What we find is that the Base64 stored in the registry value is in fact another PowerShell command. Payloads like this are rather common. For a deeper dive into exactly what it is doing check out this article from Richard De La Cruz. For now just understand that the command is going to load a string of Base64 into memory as  compressed data and execute it in memory. We want to do is extract this payload for further analysis. If you do this in SIFT-REMnux it is far easier (and safer) to analyze the file we will uncover there.

1. Replace Input with Output
2. Clean up the leading and trailing PowerShell command stuff to isolate the base64 so it starts with H4sIAC...
3. and ends with AAA=
4. It should be 1840 bytes long
5. Change out the Remove null bytes ingredient for Gunzip found under the compression options. The recipe is now From Base64 then Gunzip

Read through this function until you find yet another Base64 String. If you look at the lingo leading up to this string you will catch the word Byte just before the Base64. This is setting up to setup a Byte Array in memory. This Byte array is going to be loaded in memory. Notice its not being executed directly like the previous Base64 Strings. Those were obfuscated script blocks. This is something different. Lets talk adversary tactics for a moment.

So far we have been decoding blocks of PowerShell that were being loaded into memory with the second block loading this final bit of obfuscated information we just uncovered. The second block of PowerShell was loading this into memory from a compressed state. Avoiding detection is a goal of any worthy attacker. All of the efforts from the malware so far have been to avoid touch the disk and triggering AntiVirus products. The newly discovered, and final, base64 string discovered here is Shell Code. Shell code is typically a very small piece of code that when executed will do some function. This is often directing the victim machine to send a shell to a remote system. In other words, this is what causes the victim to open communications with the attackers. Note: As it turns out the shell code planted here by meterpreter during the lab execution appears to be broken in someway; and further analysis proved to be beyond triage forensics. Often useful information can quickly be extracted from Shell Code using FLOSS, Strings, capa, or scdbg.

VirusTotal was successful in identifying this as Shell Code. However, as an analyst you could have quickly derived this by seeing a few key pieces of the code found in the function loading the byte array.

This is not a reverse engineering course. Don’t worry you have to understand ALL of what you see here. The important notes here are:

• The function is getting the address of a process
• It’s setting up a Byte array (think raw chunk of data …. or shell code)
• It’s then clearing some room in memory with VirtualAlloc
• It’s then going to create a thread with the byte array of shell code in that thread with CreateThread

If that is all Klingon to you that is OK! If you dug through layers of obfuscation and found a byte array all stuffed into a registry value you are looking at something very likely to be malicious. That is a solid find! Screen shot all of it and make notes. Save the Shell Code for a reverse engineer and keep moving.

NOTE: In our quests of finding evil, VirtualAllocEx is a key ingredient to Process Injection and an immediate red flag. Process Injection is a way for malware to move from on process to another. To be clear this does not look like injection yet.

Shell Code Analysis with Capa

The shell code here was generated and dropped into the registry using a meterpreter shell that was on the host with system level privileges. In this case there seems to be an issue with the shell code. Though it proved to be rather difficult to use this shell code to teach some triage tactics with- it is still valuable to share what we do in the field. Capa is quickly becoming a “go to move” on binaries and shell code. Even with this particular piece of shell code being rather difficult to analyze we can still confirm it is likely malicious x64 bit shell code. The Base64 in the byte array above was saved to a file and examined.

capa --format sc64 shellcode.dat. Note: if you are unsure if the bin is 32 or 64 bit you can quickly run capa and try both formats. Here sc64 is the only format to return results. Later, we will confirm the attacker was using x64 bit payloads.

T1129 is identified here by capa along with access PEB ldr_data. This tells us this shell code is looking to call on DLL’s, or sections of DLL’s, found in Windows along with enumerating the PEB (Process Environment Block) – a favorite maneuver of memory based (file-less) malware. If you are new to all of this that is also likely Klingon. Lets briefly break this down. We found a series of obfuscated PowerShell scripts nested inside each other that eventually carved out space in memory to load shell code. That shell code looks like it is going to load DLL’s, or sections of DLL’s, in memory along with hunting for API addresses in memory. This all smells of file-less malware. Beyond this would take a skilled Reverse Engineer and is beyond the scope of this post.

---

Suspicious Service (2nd Interesting Finding)

To find the second finding you should filter the CSV for ASEP’s that are Enabled and Unsigned. Filter on Enabled ASEP’s items in the Enabled column. Next filter on instances where there was no signer of the software by selecting “blank” signers.

You should end up with only a few ASEP’s that make the list. Immediately something stands out. Windows is starting an executable known as coreupdater.exe from the System32 folder. That is interesting for a few reasons.

1. Would something need to update every time the computer boots up? Maybe. Maybe not. It could be something legitimate… but…
2. It is launching from a sacred folder. System32 is a folder that can only be written to by privileged users and typically contains legit signed software. Note: if this is in fact a malicious binary it was likely put there by a privileged user. This could indicate that the attacker had System, or Administrator, level access. This is bad.
3. All of this as a service. Services are favorites for attackers installing persistence.

Retrieval and Analysis

With the victim drive mounted lets retrieve the file and analyze it. Move the suspect file from the Windows image to either your SIFTREMnux box or to your Windows Analysis FLARE box. Here we are simply moving it to our cases folder in the SIFTREMnux box.

Malware Triage

Now for some fast analysis to see what we are dealing with here.

Quick Static Analysis

File Type

File ,trid, and xxd will quickly confirm it is in fact a 64 bit Windows Executable. 4d5a is hex for MZ, the “magic number” for a Windows Portable Executable. All three tools were used here to quickly demonstrate three ways of obtaining the data.

We already assumed this file was a Windows Executable based on the fact it is setup to run at boot time and is an image being called by the registry. In forensics we always want to confirm and prove what we think.

Antivirus Check

Clamscan can often get us quick win. Lets try it out. Make sure you update clamscan with freshclam.

Clamscan said it’s clean! Do not be fooled. As hackers we always strive to dive deeper and check things out. We never take the return of a single tool as the sole source of truth. Clamscan is a great product and works well at identifying malware.

Executable Capabilities Check

FireEye’s program capa should be installed on your SIFTREMnux box. Capa is a great piece of kit that landed in the public domain in the late summer of 2020. Let’s direct capa to analyze this file for us.

capa coreupdater.exe

Colored output was disabled in the screen shot to make highlighting easier. Here we can see that this file is XOR’d. XOR can be used to obfuscated data during static analysis (what we are doing right now). In this business if it is trying trying to hide it’s interesting and suggests its malicious. Legitimate files typically do not try and hide what they are doing.

Sandbox Detonation

–Same instruction set from the PCAP Analysis post where this same file is retrieved–

It looks like static analysis of this file is not giving us any quick wins. At this point a junior analyst needs to send the file to a reverse engineer, or detonate the file in a sandbox. Up until this point we have been conducting static analysis. The next phase is to see the file actually run and do what it is designed to do. This is called dynamic analysis. Executables that are obfuscated must de-obfuscate themselves to run. “Malware can hide but it has to run”. Systems designed to detonate malware and safely observe its behavior are called sandboxes. Advanced adversaries use malware that is aware of sandboxes and will not detonate if it detects, or suspects, it is “sandboxed”.

A quick easy option are online sandboxes. Be careful. Some adversaries watch these public sandboxes for when their malware is detonated there and will act accordingly (see above). For this exercise we will use one of the many free online sandboxes, any.run.

Once logged in you can search for the hash to see if someone had previously detonated this malware. If nothing is found you can submit the file.

When you go to submit this file it doesn’t run! Hmmm. Could it be this is a 64-bit file? Did you notice that it only supports 32-bit?

Let’s try another Sandbox, Joe Sandbox.

Notice even Joe tries to warn you that you are about to tip your hand to the World that you found this malware.

Once you confirm the payload detonation it will take a few minutes. However, the results are worth the wait.

WHAM! We have successfully uncovered the secrets of coreupdater.exe. When the IOC tab is selected we find a new IOC to add to the Board ‘o Doom: 203.78.103.109.

We now know we are dealing with a malicious Trojan that is part of the Metasploit toolkit and it’s calling back to 203.78.103.109, a server likely residing in Thailand.

An amazing feature Joe Sandbox offers free users is a full report generated on the Malware for you! Grab a copy.

Select the PDF Report.

Read through it until you find the MITRE ATT&CK portion of the report.

This is also known as a “Cross Walk”. The MITRE ATT&CK Matrix is one of the best resources to hit the industry in the past decade. It deserves its own post. For now, understand that this is here and is one of the easiest ways to understand the capabilities and intent of an adversaries malware. Take a look through the report. It’s pretty epic for no money, and 5 minutes of waiting for it to detonate.

---

Conclusion

We opened the CSV file for the autorunsc output from the Domain Controller. We opened the file in Excel, Eric Zimmerman’s TimeLine Explorer, or Calc. From here we filtered the data to find 2 interesting artifacts. The first one we examined was a PowerShell command we found stuffed into the registry. The second was a file being called as a service at boot time. In each case we pursued the finding to try and determine if the item automatically started by windows was malicious or benign.

For the powershell command found hiding as a registry value we found it to be an obfuscated series of nested commands that eventually launched some sort of shell code. Doing a quick and dirty analysis we see believe it to be some form of file-less malware. File-less malware is a bit of a misnomer and is really just malware loading itself into memory, or assembling itself in memory on the fly, and then executing.

The second interesting finding was a Windows Executable being called at boot time. We were able to retrieve the file from the image of the Domain Controller’s Disk Image. Static and Dynamic analysis were performed on the file to conduct triage analysis. It was determined this executable was in fact a Meterpreter payload calling back to 203.78.103[.]109.

Analyzing autoruns outputs is a search for a thread to pull on. Once a thread is discovered it must be followed. Analysts must have the ability to quickly triage findings and to know when they have hit their limit. In modern incident response speed is becoming of utmost importance. Many attackers want to ransomware the network. It is best to cut them off as quickly as possible and forensics triage is key.

Can you find the persistence installed on the desktop?

Desktop Autoruns
Desktop Disk Image

IOC’s to Take Away and Pivot with from the Domain Controller

IP Address: 203.78.103.109
Malicious file path and name: \Windows\System32\coreupdater.exe
Persistence in the registry at CurrentVersion\Run and installed as a service.

Choose Your Next Move

I want to look at the Memory!

I want to look at the PCAP!

I want to look at the Disk Image and Timelines (Coming soon).

Don’t forget to leave any thoughts or questions you have on AutoRuns Analysis in the comments.

Supporting the Website

Feel free to check out our shop if you want to support the website. The money goes to supporting our starving website dev and costs of hosting. It’s like buying us a cup of coffee!