Development and operations a practical guide

Do not attempt to exploit or attack unencrypted websites or

Download 4.62 Mb.

View original pdf

Page	60/96
Date	11.02.2023
Size	4.62 Mb.
	#60628

1 ... 56 57 58 59 60 61 62 63 ... 96

1 Joe Vest, James Tubberville Red Team Development and Operations

Do not execute from non-executable locations
Do not use binaries for initial capabilities
Do not download restricted datasets

Do not attempt to exploit or attack unencrypted websites or
applications
As tempting as it maybe, do not attack unencrypted websites. Simple attacks can trigger IDSs.
Always know your target IP space. There are likely several websites available for review. Proper reconnaissance or coordination should have discovered each. Create a list of sites in your target log.
Include IP addresses, URLs, an educated guess at the functions, ports, protocols, etc.
Focus Point
Prior to performing any exploitation and attacks against a web server, refer to your Rules of Engagement and fully understand:
Who actually owns the website?
Who owns the system where the website is hosted?
Who owns the back-end application?
Have proper approvals been obtained for testing?
Do not execute from non-executable locations
●
Execution in a Windows environment must occur in a location typical of Windows
●
Executable locations such as c:\programdata, c:\progam files, and c:\windows\ are common
●
Execution from locations such as c:\windows\temp should never occur or be used with an understanding of risk

Do not use binaries for initial capabilities
As a general rule, do not drop binaries on the system. First, use builtin commands to achieve your goals. This is not always possible, and binaries maybe required however, binaries must be vetted,
obfuscated, and tested against detection before use.
●
Ensure all other Dos and Don’ts" are met for all binaries
●
Consult a senior operator before dropping any binary
Do not download restricted datasets
NEVER download (or remove from the target network) any PII, HIPAA, PCI, or other restricted datasets. A good rule of thumb is to annotate the type of data, location, access method, and level of access to restricted data in the log.
●
Ensure the log notes include a reference to the type of data discovered for quick reference
●
Take a screenshot of the displayed filename and location (assuming the filename has no restricted data included)
●
Screenshot a portion of the dataset without capturing the restricted data. The operator may do so for proof of access.
●
If the data set is of concern, attempt to copy the file to anew name in the same location. This will validate access without exposing the data.
●
DO NOT take screenshots of the data itself!

Download 4.62 Mb.

Share with your friends:

1 ... 56 57 58 59 60 61 62 63 ... 96