Link to part 2: https://securityshenaningans.medium.com/architecture-of-a-ransomware-2-2-e22d8eb11cee

Last couple of months we’ve seen a rise in ransomware related incidents, mostly due to the increase of remote work because of COVID-19. Nevertheless, not all ransomware works in the same way, and in order to have a better incident response in the event of a successful attack, we should have a good understanding of its inner workings. This can hopefully help you to reverse the encryption mechanism of the ransomware, or at least prevent further infection.

One of the best ways of learning how something truly works is to try to build it yourself (and this is what I did). So in this two part write up we’ll spend the first explaining principles and concepts you need to understand. …


In part 1(https://securityshenaningans.medium.com/architecture-of-a-ransomware-1-2-1b9fee757fcb) we explained key concepts necessary to understand how an efficient ransomware works. In this part we’ll illustrate a couple these concepts with some python code. We’ll also go into basic usage of the pycryptodome python library for encryption. I won’t be publishing the full source code since I don’t want to help script kiddies on their criminal careers. The purpose of this article is only to share knowledge about ransomware malware and it shouldn’t be used for malicious activities.

General considerations


Link to part 1.

Recap: In part 1 we saw general considerations you should keep in mind in order to start setting up your infrastructure, as well as technical steps to setup your domain with SPF and DKIM records. In this part we’ll get to a score of 10/10 and I’ll show you how to manage big campaigns, as well as 10 tips at the end to improve your reception percentage. We’ll also talk about SMTP relays and when you should use them.

DNS records

After you’re done setting everything up in Part 1, you should have between 6 and 9 DNS records. …


Link to part 2: https://medium.com/bugbountywriteup/recipe-for-a-successful-phishing-campaign-part-2–2–68552806dcba

Introduction

Phishing attacks are great first-entry vectors with technical details which are frequently overlooked by both white and blackhat hackers.

Having participated in multiple phishing campaigns over the years, both in offensive as well as defensive teams, I’ve learned from trial and error a lot of these things to pay attention to. This article will try to summarize them.

Technical subjects

Even if phishing campaigns are often associated with Social Engineering, they have technical components which you need to be aware of in order to be successful. Some of the topics we will cover (superficially) are:

  • Difference between common phishing and spear…


Introduction

In part 1 we compromised an account with multiple permissions, but no Administrator access. We found a potential role that would allow us to escalate privileges, following one of the methods in Rhinosecuritylab’s post. Briefly explained, we’ll try to create an instance and attach to it a privileged role at creation time. After that, if we can access the instance, we’ll be able to query the metadata and extract the credentials that will allow us to use this role. If you’re not sure what this means, you can find it better explained in my previous write-up.

The potential privilege escalation we identified before used a role that we called danger-role for obvious reasons. …


Note: Here’s the link to part 2.

Introduction

This is a real case study of how to enumerate and use IAM permissions to your advantage. I strongly suggest you read my previous article on how IAM permissions work. It’s long, but necessary to understand most of the things we did here. Another thing I want to clarify, this exploitation was long and somewhat technical, so I wont go too deep on the easier vulnerabilities we found (one of them is also covered in a previous writeup). We’ll cover manually enumerating IAM policies and roles, as well as automated tools that can do it for you (and why you shouldn’t trust them 100% of the time). …


Introduction

When I started getting into AWS pentesting, one of the hardest things to fully understand was IAM. AWS documentation is usually great, but can be extensive, and IAM has a lot of similar terms. You have users, roles, groups, managed policies, inline policies, instance roles, etc…
This article will try to shine some light on the subject, as well as some ways to enumerate this information with different tools.

Warning: the post will contain only theory, I’ll publish a write up with practical examples about this next week, but you’ll need the knowledge in this one before the “fun” one.

Later Edit: Heres the link to the practical example writeup which I was talking…


This is the story of how only two insecure configurations allowed us to take down an entire cloud hosted company. It was a gray box pentest for a relatively big client, in which we were tasked with assessing the security of about 5 development endpoints, accessible only using a client certificate. After setting up our environment, we started scanning the endpoints, and Nessus quickly returned an exploitable vulnerability:

Image for post
Image for post

Hadoop exposes this API to allow management of it’s resources. Authentication should be in place to prevent anonymous command execution. A quick searchploit search returned an available RCE exploit.

Image for post
Image for post

The description shows something like…


On part 1 we briefly explained how we got administrator privileges to almost all BMC devices hosting a native Openstack cloud. In this part we’ll show how we used these to achieve complete compromise.

If you’ve read up on BMC devices, by now you’ll know that they allow you to

  • Monitor
  • Reboot
  • Reinstall
  • KVM

the attached devices. This is great and all, but they only simulate physical access to the server, you still need to get inside. Yes, you could DOS them by shutting them down, but we thought that this wasn’t enough, so we kept digging.

One of the most common ways of compromising an equipment having physical address is rebooting it and manipulating the startup in order to come up with a root shell. You can do this in Unix, Mac and Windows as well. …


Link to part 2

Introduction

In this write up we’ll see how we were able to combine direct sqlmap connection to a database with BMC/IPMI exploitation to compromise a big cloud-hosted client.

Getting a foothold

A couple of years ago, our team was tasked with performing an infrastructure pentest in an Openstack network. It was formed by about 2000 physical servers, hosting over 25K virtual instances. We started the pentest located in a small subnet which didn’t have a lot of outbound traffic allowed. After a quick Nmap scan, we weren’t able to find any simple vulnerabilities to exploit, so we started looking into the services available to us. Amongst them, we found an exposed PostgreSQL server, hosted in a development server. After creating a custom wordlist with multiple derivations of the company’s name, we were able to login with relatively trivial credentials. …

About

Security Shenanigans

I’m a security engineer who enjoys writing about experiences in the infosec field. OSCP. linkedin.com/in/federlago.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store