Leaderboard

socialscan is an accurate command-line tool to check For email and social media username usage on online platforms, given an email address or username, socialscan returns whether it is available, taken or invalid on online platforms. Other similar tools check username availability by requesting the profile page of the username in question and based on information like the HTTP status code or error text on the requested page, determine whether a username is already taken. This is a naive approach that fails in the following cases: Reserved keywords: Most platforms have a set of keywords that they don’t allow to be used in usernames (A simple test: try checking reserved words like ‘admin’ or ‘home’ or ‘root’ and see if other services mark them as available) Deleted/banned accounts: Deleted/banned account usernames tend to be unavailable even though the profile pages might not exist Therefore, these tools tend to come up with false positives and negatives. This method of checking is also dependent on platforms having web-based profile pages and cannot be extended to email addresses. socialscan aims to plug these gaps by directly querying the registration servers of the platforms instead, retrieving the appropriate CSRF tokens, headers, and cookies. Install Socialscan Command-Line Tool To Check For Email And Social Media Username Usage pip > pip install socialscan > git clone https://github.com/iojw/socialscan.git > cd socialscan > pip install . ocialscan Command-Line Tool To Check For Email And Social Media Username Usage usage: socialscan [list of usernames/email addresses to check] optional arguments: -h, --help show this help message and exit --platforms [platform [platform ...]], -p [platform [platform ...]] list of platforms to query (default: all platforms) --view-by {platform,query} view results sorted by platform or by query (default: query) --available-only, -a only print usernames/email addresses that are available and not in use --cache-tokens, -c cache tokens for platforms requiring more than one HTTP request (Snapchat, GitHub, Instagram. Lastfm & Tumblr), reducing total number of requests sent --input input.txt, -i input.txt file containg list of queries to execute --proxy-list proxy_list.txt file containing list of HTTP proxy servers to execute queries with --verbose, -v show query responses as they are received --show-urls display profile URLs for usernames on supported platforms (profiles may not exist if usernames are reserved or belong to deleted/banned accounts) --json json.txt output results in JSON format to the specified file --version show program's version number and exit You can download Socialscan here: socialscan-v1.4.2.zip Or read more here. Sources: darknet.org.uk github.com

moonwalk Cover your tracks during Linux Exploitation / Penetration Testing by leaving zero traces on system logs and filesystem timestamps. 📖 Table of Contents Introduction Features Installation Usage Contribution License ℹ️ Introduction moonwalk is a 400 KB single-binary executable that can clear your traces while penetration testing a Unix machine. It saves the state of system logs pre-exploitation and reverts that state including the filesystem timestamps post-exploitation leaving zero traces of a ghost in the shell. ⚠️ NOTE: This tool is open-sourced to assist solely in Red Team operations and in no means is the author liable for repercussions caused by any prohibited use of this tool. Only make use of this in a machine you have permission to test. Features Small Executable: Get started quickly with a curl fetch to your target machine. Fast: Performs all session commands including logging, trace clearing, and filesystem operations in under 5 milliseconds. Reconnaissance: To save the state of system logs, moonwalk finds a world-writable path and saves the session under a dot directory which is removed upon ending the session. Shell History: Instead of clearing the whole history file, moonwalk reverts it back to how it was including the invokation of moonwalk. Filesystem Timestamps: Hide from the Blue Team by reverting the access/modify timestamps of files back to how it was using the GET command. Installation $ curl -L https://github.com/mufeedvh/moonwalk/releases/download/v1.0.0/moonwalk_linux -o moonwalk (AMD x86-64) OR Download the executable from Releases OR Install with cargo: $ cargo install --git https://github.com/mufeedvh/moonwalk.git Install Rust/Cargo Build From Source Prerequisites: Git Rust Cargo (Automatically installed when installing Rust) A C linker (Only for Linux, generally comes pre-installed) $ git clone https://github.com/mufeedvh/moonwalk.git $ cd moonwalk/ $ cargo build --release The first command clones this repository into your local machine and the last two commands enters the directory and builds the source in release mode. Usage Once you get a shell into the target Unix machine, start a moonwalk session by running this command: $ moonwalk start While you're doing recon/exploitation and messing with any files, get the touch timestamp command of a file beforehand to revert it back after you've accessed/modified it: $ moonwalk get ~/.bash_history Post-exploitation, clear your traces and close the session with this command: $ moonwalk finish That's it! Contribution Ways to contribute: Suggest a feature Report a bug Fix something and open a pull request Help me document the code Spread the word Find something I missed which leaves any trace! License Licensed under the MIT License, see LICENSE for more information. Liked the project? Support the author by buying him a coffee! Support this project by starring ⭐, sharing 📲, and contributing 👩‍💻! ❤️ Sursa: https://github.com/mufeedvh/moonwalk

A vulnerability discovered in GitHub Actions could allow an attacker to poison a developer's pipeline, highlighting the risk that insecure software pipelines pose. Source: SeventyFour Images via Alamy Stock Photo An attacker submitting changes to an open source repository on GitHub could cause downstream software projects that include the latest version of a component to compile updates with malicious code. That's according to software supply chain security firm Legit Security, which said in an advisory published on Dec. 1 that this "artifact poisoning" weakness could affect software projects that use GitHub Actions — a service for automating development pipelines — by triggering the build process when a change is detected in a software dependency. The vulnerability is not theoretical: Legit Security simulated an attack on the project that manages Rust, causing the project to recompile using a customized — and malicious — version of the popular GCC software library, the company stated in the advisory. The problem likely affects a large number of open source projects because maintainers typically will run tests on contributed code before they actually analyze the code themselves, says Liav Caspi, chief technology officer of Legit Security. "It is a common pattern today," he says. "A lot of open source projects today, upon a change request, they run a bunch of tests to validate the request because the maintainer does not want to have to review the code first. Instead, it automatically run tests." The attack takes advantage of the automated build process through GitHub Actions. In the case of the Rust programming language, the vulnerable pattern could have allowed an attacker to execute code in a privileged way as part of the development pipeline, stealing repository secrets and potentially tampering with code, Legit Security said. "To put it simply: in a vulnerable workflow, any GitHub user can create a fork that builds an artifact," the company stated in its advisory. "Then inject this artifact into the original repository build process and modify its output. This is another form of a software supply chain attack, where the build output is modified by an attacker." The vulnerability enables an attack similar to the malware-insertion attack that targeted CodeCov and, through that company's software, its downstream customers. "[T]he lack of native GitHub implementation for cross-workflow artifacts communication led many projects and the GitHub Actions community to develop insecure solutions for cross-workflow communication and made this threat highly prevalent," Legit Security stated in the advisory. GitHub confirmed the issue and paid a bounty for the information, while Rust fixed its vulnerable pipeline, Legit Security stated. Source: Legit Security Software Supply Chain Needs Security The vulnerability is the latest security issue to affect software supply chains. Industry and government agencies have increasingly sought to bolster the security of open source software and software provided as a service. In May 2021, for example, the Biden administration released its executive order on Improving the Nation's Cybersecurity, a federal rule that, among other requirements, mandates that the government will require baseline security standards for any software its purchases. On the private industry side, Google and Microsoft have pledged billions of dollars to shore up security in the open source ecosystem, which provides the code that comprises more than three-quarters of the average application's codebase. Logical, But Vulnerable The security issue belongs to a hard-to-find class of problems known as logic issues, which include issues with permissions, the potential for forked repositories to be inserted into a pipeline, and a lack of differentiation between forked and base repositories. Because software projects often use automated scripts to check code submissions before forwarded them to the maintainers, pull requests will be run through automation before any human checks them for malicious code. While the automation saves time, it also should be considered a way for attackers to insert malicious code into the pipeline. "When you are doing open source development, the problem is bigger, because you are accepting contribution from anyone in the world," Caspi says. "You are executing things that you cannot trust." GitHub acknowledged the issue and expanded the ways of excluding submissions from outside collaborators from being automatically inserted into the Actions pipeline. The company updated its GetArtifact and ListArtifacts APIs with the goal of providing more information to help determine whether an artifact can be trusted. "Anyone that does anything like the Rust project did — trusting the input from a third party — then they are still vulnerable," Caspi says. "It is a logic problem. GitHub just made it easier to write a safer script." Via darkreading.com