NSA SOFTWARE 2 GINSU

	11/24/2000: Version 1.0 is released.  This release includes minor updates to the error message handling. The 0.9.2 release seems stable, so with this minor update I proclaim it ready for prime time.The DOS and Win32 versions are not updated yet, as I will have to get time on my home computer to build them. GINSU Copyright © 2000 Chris Gonnermanchris.gonnerman@newcenturycomputers.net CRC.C/H   Copyright © 1996-1997 Id Software, Inc. Copyright © 1999,2000 contributors of the QuakeForge project This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. DOWNLOADS Source Tarball: ginsu-1.0.tar.gz DOS Binary Zipfile: ginsu-dos-0.9.2.zip Win32 (MinGW32) Binary Zipfile: ginsu-w32-0.9.2.zip The DOS version is fully functional except for long filename support.  Included in the source archive is the Turbo C project file, ginsu.prj, used to create it. The Win32 version is compatible with the DOS version, but supports long filenames correctly (so far, anyway). INSTALLING First, edit the Makefile and set the variables for PREFIX, BINDIR, MANDIR, etc. as needed for your installation. If you have a GNU-compatible install command in your path, and want to use /usr/local/bin and /usr/local/man for the install directories, it should be fine. Run make. If it builds OK, then (as a privileged user, i.e. root) run make install. That's it, you're done. QUICK-AND-DIRTY INSTRUCTIONS Say you have this nasty Windows driver that you need to transport on diskettes, but the file is 3.1 Mb in size (yes, this is EXACTLY why I wrote this program). Do this: ginsu big-ugly-file.exe Ginsu will chop the big ugly file into pieces, where each piece (except the last) is exactly the size of the free space on a FAT 3.5" 1.44Mb disk. The "cutfiles" will be named bigugl01.gcf, bigugl02.gcf, etc. Up to 99 slices may be made. Copy the cutfiles to disk, one at a time (or look at the -p option below for help). Take the disks to the client site and copy them to a folder, along with the DOS or Win32 compiled version (available as separate downloads). To reconstruct the file, do this: ginsu bigugl01.gcf in the directory where all the cutfiles are located. Yeah, there are a mess of options, not all well documented; see the man page for more info. This software is not nearly fully tested yet, also. Below is a plaintext version of the manual page for version 0.9, which may already be out of date. Check the manual page for up-to-date info. Usage: ginsu [options] [filename] ginsu reads stdin if filename is not given. If the given file or stream does not include a ginsu chop file (gcf) header, it is assumed to be an "original" file to be chopped. A header is generated and the file is chopped into pieces and stored. If stdin is processed, 'ginsu.fil' is stored as the original filename. If the given file has a gcf header, it is assumed to be one of a number of gcf files that contain the pieces of the original file. Note that you can't use stdin in this case. ginsu validates the filename (which must be in proper format), reads the header, and begins reconstruction. GCF Filename Format: aaaaaNN.gcf (i.e. textaa01.gcf) Filename is made from first six alphabetics of the original filename, if any, converted to lowercase and padded with 'a' characters to exactly six long; then, an index number (01 to 99) for the 'slice' index of this file; finally, '.gcf' as a file extension. Options include: -cN target file size in K (for chopping) -v verbose level output -V debug level output -q quiet output (no warnings) -Q very quiet output (no messages at all) -t target file name (for reconstruction) original filename is used otherwise, if available in chop mode, this is stored in the header as the "original" filename. -d Device mode (see below) -p Prompted mode (see below) -S File stem (overrides default) -P Path (for cutfiles, overrides current directory default) Option arguments must immediately follow the option, to avoid confusion with filenames; option keyletters may not be combined. For example, this is valid: ginsu -v -c100 original.fil But these are not: ginsu -v -c 100 original.fil ginsu -vc100 original.fil The magic header of a gcf file contains lines to run ginsu if the gcf file is executed directly under Unix-like OS's, and the filename is constructed to be legal under DOS, Unix/Linux, and Windows. The Win32 version of ginsu can be associated with the .gcf extension, so that reconstruction can be initiated by double-clicking any individual gcf file. The header is also created such that a "head .gcf" will produce printable output under Unix, and has a ^Z character following so that the DOS TYPE command will print just the header without any following binary data. In stitch mode, "device mode" assumes that the filename given is probably not valid, and skips the validation step; it then opens, processes, and closes the same filename over and over, prompting before each time. The reason for this is to support /dev/fd0* under Unix/Linux. Disks must be inserted in order, since in this case ginsu can't select which file to process first. In chop mode, the -d option must be followed by the device name; ginsu will prompt to change disks between sections, and will also set the maximum chop size to the size of the media (if supported). In stitch mode, the -p option enables prompting but assumes that the filename IS valid; this is useful under DOS/Windows for processing A:\AAAAAA01.GCF, for instance, where you need to change disks before each file is processed. In chop mode, the -p option must be followed immediately by the path to write files to; ginsu will prompt before each section, allowing the disk change to be performed.

Multiple Methods for Dropping Payloads with Credentials (or Hashes)

I like the cliche that “There’s more than one way to skin a cat” because it’s how I like to operate.  I like to have a lot of different options to choose from when attempting to reach a certain goal.  In my previous post, I showed how psexec_command can be used to trigger an executable once it’s been placed on a machine.  But this could lead to the question, how can we get our payload on to our target machines in the first place?

This post won’t go into how to get your initial compromise, I assume you’ve already done that, and you’ve been able to dump hashes (and now because of mimikatz’s awesomeness) and/or cleartext credentials.  So the next step in an assessment is not to blindly move around a network, but to identify targets of value.  Once you’ve done this, our goal is to get our payload onto that target.  I’m going to show you a couple of different ways that you can do this, and I’d love to hear from anyone else on other ways to place a binary on a machine.

But for now, our first method, a normal shell.

Note: All methods displayed below will only work if the account you are operating as has permissions to drop binaries/files in the locations you are doing so.  Otherwise, it won’t work.

Windows Shell:

We can use a normal shell within windows to help us move our payload around the network.  The nice thing about using the built in shell is that it doesn’t require the use of any other tools and is simply using built in OS capabilities.  In our picture below, I’m interacting with a shell prompt spawned on a machine through a meterpreter session.  We can see that we have a binary called “evilpayload.exe”.  So, our goal is to move this payload from one machine to another.  This is easily done by using the copy command from within the shell and pointing our payload (which in this case is already on our compromised machine) towards a share on our target machine, as demoed below:

Metasploit Upload:

Metasploit has the capability to simply upload a file to a machine when provided with all the required options.  To use this, call the auxiliary/admin/smb/upload_file module.  As you’ll see in the picture below, I’ve provided a sample set of values that will allow the module to upload my payload to the target machine.  One item to note, the picture does not show the SMBUser, SMBPass, and the SMBDomain values being used with the module.  You will need to provide values for those (advanced) options in order for the module to authenticate and upload the payload to your target machine.

Once all options have been provided, executing the module will upload your binary to the target machine.

Chris Gates wrote up an awesome attack path he encountered and used the upload_file module, and can be seen here.

Metasploit Psexec:

The metasploit psexec module can be used to upload a binary, either custom compiled or generated by the metasploit framework, onto the target machine.  The obvious difference with this module is that after uploading the binary to your target machine, the framework will create a system service which executes the payload, as compared to almost all other methods within this post that simply drop the binary on the system.

As you view the screenshot below, we can se that our binary was uploaded and triggered, so we received our callback.  One item to note is that even when providing a custom executable (as I did below), the executable is renamed when it is dropped on the target machine.  In the event that you need to trigger your executable again, you’ll need to note the executable’s name on disk (in this instance, it is LtcvppBc.exe).

SMBClient.py:

The impacket library has been something that I’ve been playing around with for a little bit lately.  It has a lot of cool capabilities and allows you to write scripts to interact with a variety of protocols, one of them being SMB.  SMBClient.py is a sample script written by the developers of the impacket library to show how the library can be used to interact with SMB.  Smbclient script will let us connect to a remote share with either cleartext credentials or a hashes and upload our binary.

To initiate the connection, we’ll use open and then the ip address of the machine we want to connect to.  Once we’ve connected to the machine, we’ll authenticate with the credentials we’ve already obtained via the login command (if we only had hashes, we would use the login_hash command).  Once authenticated, we type shares to see the list of shares to connect to, and then use the C$ share.  Now, it’s simply invoking the put command, along with the file we want to upload, and then it’s complete.  You can use the ls command to verify that your file has been placed on the remote machine.

A sample workflow on how this can be used is in the screenshot below.

Psexec.py:

The impacket library developers also left us with another awesome script for uploading files to a machine, and it’s their implementation of psexec, using the impacket library, within a python script.  This script will let us spawn a command shell on the target machine, but also comes with extra capabilities, such as the ability to upload files.  We can use this script to upload our payload, and then execute it.  Great part about it, is that our session is going to be running as System!

To call psexec.py, we provide it with the credentials we want to authenticate to the machine with, the IP address of the victim machine, and the process we want to spawn.  After this, it’s simply using the put command to drop our payload on the machine, and then we can just call it within the command shell.

Larry Spohn also wrote a great post on combining Veil with psexec.py which you can read here.

A sample workflow of the psexec.py script can be seen below:

I hope this has helped to give everyone multiple different options to drop files on machines when you have user credentials.  There are other ways as well, and I’m interested in hearing other methods that have been useful for you.

https://www.christophertruncer.com/dropping-payloads-with-credentials/

 

 

 

Search

Hard Drive Firmware Implant IRATEMONK

10/26/2014 | By: Preston Hood | 1 Comment

Here is yet another one of the NSA’s firmware implants which can be used to replace your current hard drive’s firmware. This allows the NSA to gain complete control of your hard drive and through the use of other exploits they would be able to gain complete access to your system.

What It Is
IRATEMONK is a firmware implant that replaces your current hard drive’s firmware and is used as a backdoor into your system. IRATEMONK gains execution through the Master Boot Record (MBR) substitution. IRATEMONK supports the following hard drive vendors: Western Digital, Seagate, Maxtor, and Samsung. IRATEMONK does not support systems that use hardware RAID, it is not clear if this method works with software RAID, but my guess would be that it does. IRATEMONK supports the following file systems: FAT, NTFS, EXT3, and UFS (I am sure that by today they support more). To upload the hard drive firmware onto a target machine the NSA uses UNITEDRAKE or STRAITBAZZARE in conjunction with SLICKERVICAR. This is used to implant IRATEMONK and its payload or the implant installer. Once IRATEMONK has been implanted onto a target machine its frequency of execution (dropping the payload) is configurable and occurs when the system is powered on. This process is very similar to a BIOS exploit for Dell PowerEdge servers called DEITYBOUNCE, which I discussed in my article: Dell PowerEdge Servers BIOS Exploit DEITYBOUNCE.

What We Can Do
The obvious things you could do is just use a hard drive vendor which this type of attack does not affect, or use hardware RAID which would eliminate the possibility of an attack like this; however, these options are not very economical nor logical for the everyday user. A more logical and economical solution which (I believe) would work is to encrypt your entire hard drive. This can be done with the use of some sort of old on-the-fly encryption (OTFE) software that can encrypt your entire hard drive. Examples of software that can do this are TrueCrypt, Bitlocker, and dm-crypt. Even though encrypting your entire hard drive will still leave the hard drive’s firmware exposed, it will add an extra layer of security which the attacker will have to get through before they can gain access to your files or OS. This theory should work as long as the attacker does not steal your encryption keys out of your RAM.

Thank you for taking the time to read this article! As always keep the faith!

The NSA’s original documentation on IRATEMONK

The following two tabs change content below.

GBPPR Vision #28: Overview of the NSA's RAGEMASTER Radar Retro-Reflector

802.11 Sniffer Capture Analysis - WPA/WPA2 with PSK or EAP

WPA-PSK(TKIP)

1.      Beacon frames are transmitted periodically to anonunce presence of wireless network and contain all information about it(data rates, channels, security ciphers, key management etc):

2.     Probe request, is sent by STA to obtain information from AP:

3.      Probe response, AP responds with with a probe response frame, containing capability information, supported data rates, etc., when after it receives a probe request frame from STA:

4.      802.11 authentication is a process whereby the access point either accepts or rejects the identity of a radio NIC. The NIC begins the process by sending an authentication frame containing its identity to the access point. With open system authentication (the default), the radio NIC sends only one authentication frame, and the access point responds with an authentication frame as a response indicating acceptance (or rejection).:

a.       Dot11 authentication request:

b.      Dot11 authentication response:

5.     

802.11 association enables the access point to allocate resources for and synchronize with a radio NIC. A NIC begins the association process by sending an association request to an access point. This frame carries information about the NIC (e.g., supported data rates) and the SSID of the network it wishes to associate with.

a.       Dot11 association request:

After receiving the association request, the access point considers associating with the NIC, and (if accepted) reserves memory space and establishes an association ID for the NIC.

b.      Dott11 association response:

6.      4-way handshake, during this phase PTK is created, PSK is used as PMK to construct those values:

a.       AP sends 802.1x authentication frame with ANonce, STA now has all information to construct PTK:

b.      STA responds with 802.1x authentication frame with SNonce and MIC:

c.       AP constructs 802.1x frame with new MIC and GTK with sequence number, This sequence number will be used in the next multicast or broadcast frame, so that the receiving STA can perform basic replay detection:

d.      STA sends ACK:

From that point all data is sent encrypted.

WPA2-PSK(AES/TKIP)

The process if fairly the same as in previous section, I’ll highlight only information that is different.

1.      WPA2 AP management frame include RSN element that included unicast cipher suite, AKM information and GTK cipher suite (if both AES and TKIP are selected, then less stronger encryption method will be used for GTK).

2.      During 4-way handshake frames contain version information for WPA2 in “Type” fields.

Note: you can decrypt WEP/WPA-PSK/WPA2-PSK encrypted wireless traffic if 4-way handshake key exchange frames are included in trace and PSK is known.

In order to encrypt wireless traffic in wireshark open Preferences-> Protocols->IEEE 802.11 and provide PSK information and select “Enable decryption option”.

To decrypt WPA/WPA2 encrypted traffic specify Key in format:

“wpa-psk:PSK:SSID”

Note: In order to filter out WLAN traffic from specific STA in wireshark you could use “WLAN Statistic” option.

In order to filter traffic from specific STA go to “Statistics -> WLAN Traffic”, from the list of SSIDs select corresponding SSID STA is associated with, and apply filter based on the STA.

WPA/WPA2 Enterprise

1)     WPA(TKIP)/WPA2(AES) with dot1x (PEAP)

This process follows the same steps like previous except for the AKM method and deriving PTK/GTK and AP advertised attributes in 802.11 management frames.

a.       In this example AP advertises WPA(TKIP)/WPA2(AES) with dot1x authentication, both RSN and WPA tag attributes for AKM contain WPA value, whether in case of PSK authentication this field contains “PSK”. Also in this example TKIP is used for WPA and AES is used for WPA2

b.      STA selects one of authentication methods and cipher suites advertised by AP. In this case WPA2 with AES was selected, that can be seen in RSN IE parameters.

c.       After successful dot11 association dot1x authentication takes place, during this process we can see what EAP method is used by STA for authentication and certificate(s) exchange information between supplicant and AAA server.

d.      After successful dot1x authentication PMK is trasmited to AP in “Access-Accept” message from AAA server and the same PMK is derived on the client, next 4-way handshake takes place and PTK and GTK establishment.

Radius exchange between WLC and AAA server:

General flow diagram:

WPA(TKIP)/WPA2(AES) with dot1x (EAP-TLS)

Difference for this type of authentication compared to the previous one is that client provides its certificate in “Client Hello” message and mutual authentication is performed between client and AAA server based on certificates.

EAP exchange between STA and WLC:

Radius exchange between WLC and AAA server:

General flow diagram:

2)     WPA(TKIP)/WPA2(AES) with dot1x (FAST)

Only dot1x authentication stage is a bit different comparing to the previous example. After successful dot11 association dot1x authentication takes place, AP sends dot1x identity request to the STA and STA provides identity response, the response depends on what PAC provisioning is been in use (in-band PAC provisioning (phase 0) or out-of-band PAC provisioning). In case of in-band provisioning PAC is sent to the client from AAA server, once client has PAC it goes to EAP-FAST phase1 from this point TLS tunnel establishment starts (phase 1)

After TLS tunnel is established inner authentication method (phase 2) starts inside encrypted tunnel. On successful authentication PMK is send in “Access-Accept” message to AP from AAA server, the same key is derived based on dot1x exchange on STA. This key (PMK) is used to calculate PTK during 4-way handshake that will be used to secure communication between STA and AP.

General flow diagram:

https://supportforums.cisco.com/document/100611/80211-sniffer-capture-analysis-wpawpa2-psk-or-eap

NSA TRINITY HIDDEN MICRO CONTROLLER

The highly affordable STM32 Nucleo boards allow anyone to try out new ideas and to quickly create prototypes with any STM32 MCU.

Sharing the same connectors, STM32 Nucleo boards can easily be extended with a large number of specialized application hardware add-ons (Nucleo-64 include Arduino Uno rev3 & ST morpho connectors, Nucleo-32 include Arduino Nano connectors).

The STM32 Nucleo boards integrate an ST-Link debugger/programmer, so there is no need for a separate probe.

A comprehensive STM32 software HAL library together with various software examples are provided with the STM32 Nucleo boards, and seamlessly work with a wide range of development environments including IAR EWARM, Keil MDK-ARM, mbed and GCC/LLVM-based IDEs.

All STM32 Nucleo users have free access to the mbed online resources (compiler, C/C++ SDK, and developer community) at www.mbed.org allowing to build a complete application in only a few minutes.

http://www.st.com/en/evaluation-tools/stm32-mcu-nucleo.html?querycriteria=productId=LN1847

NSA WINDOWS RAM SNIFFER

you will need three tools: netcat (nc.exe), pmdump.exe (www. ntsecurity.nu/toolbox/pmdump/), and strings.exe (http://technet.microsoft.com/en-us/ sysinternals/bb897439.aspx) or BinText (available from www.foundstone.com/us/ resources/proddesc/bintext.htm). You can run this example using either one or two systems, but it works best when two systems are used. If you’re using one system, create two directories, with a copy of netcat in each directory.

Start by launching netcat in listening mode with the following command line:

This command line tells netcat to listen on port 8080, in detached mode, and when a connection is made to launch the command prompt. Once you’ve typed in the command line and pressed Enter, open the Task Manager and note the process identifier (PID) of the process you just created. (Here I am using netcat Version 1.11 NT, which I retrieved from www.vulnwatch.org/netcat. At the time of this writing, the Web site does not appear to be available.)

Now open another command prompt on the same system, or go to your other system and open the command prompt. Type the following command line to connect to the netcat listener you just created:

This command line tells netcat to open in client mode and to connect to the Internet Protocol (IP) address on port 8080, where our listener is waiting. If you’re running the test on a single system, use 127.0.0.1 as the IP address.

Once you’ve connected, you should see the command prompt header that you normally see, showing the version of the operating system and the copyright information. Type a couple of commands at the prompt, such as dir or anything else, to simply send information across the connection.

On the system where the netcat listener is running, open another command prompt and use pmdump.exe (discussed later in this topic) to obtain the contents of memory for the listener process:

This command will obtain the contents of memory used by the process and will put it into the file netcat1.log. You may also dump the process memory of the client side of the connection, if you like. Now that you have the process memory saved in a file, you can exit both processes. Run strings.exe against the memory file from the listener or open the file in BinText and you will see the IP address of the client. Doing the same thing with the client’s memory file will display information about the system where the listener was running, demonstrating the concept of Locard’s Exchange Principle.

http://what-when-how.com/windows-forensic-analysis/live-response-collecting-volatile-data-windows-forensic-analysis-part-1/