Development and operations a practical guide


Perform Situational Awareness



Download 4.62 Mb.
View original pdf
Page59/96
Date11.02.2023
Size4.62 Mb.
#60628
1   ...   55   56   57   58   59   60   61   62   ...   96
1 Joe Vest, James Tubberville Red Team Development and Operations
Perform Situational Awareness
After gaining access to a remote system or application, perform situational awareness before moving on.

Understand the environment you are in. (Is the target in scope?)

What protections exist on the system or network?

What are the risks of being caught, and what attack paths does the system provide?

Are there pre-established connections to other network resources?

Who is currently logged into the system?

Who has recently logged into the system?
Minimize callback (C) volume
Unless a host-based protection mechanism is triggered, it is more likely to be discovered or caught by a defender's recognition or analysis of traffic on the network. To avoid early detection follow good tradecraft procedure to limit and control the amount of traffic generated during an engagement. There are several general concepts that, if followed, increase the success of the engagement while decreasing the chances of being discovered:

Keep traffic internal to a network One of the most common issues, and one you should always attempt to change, is the limited number of sensors inside a network. Most network protections are currently applied at the boundary.

Pivot Command and Control traffic to a minimal number of outbound sources Maintain at least two outbound sources for C redundancy however, use only one for operations
(considered an interactive tier. The second (along- or short-haul tier) is dormant or extremely slow and used as a backup if/when the primary is discovered.
Do not use unencrypted channels for C (unless blending into
network traffic)
Command and Control data exiting the network must be encrypted. An IDS or other network defense will detect cleartext data, such as uploading a binary, issuing an operating system command, or using a web shell. It has become common for IPSs/IDSs to detect specific strings discovered in cleartext

traffic. For example, "C:\Windows\System32" has become a common trigger for investigation.
Some defenders have even gone the extra mile in legitimizing a potential threat. Assume the defenders or IT staff uses a remote administration tool regularly. Ignoring recommendations, this traffic is unencrypted. Rather than causing an alert each time the tool is used legitimately the alert is configured to look for inconsistencies in the usage. For example, most attackers are accustomed to typing lowercase commands in Windows. The defender ignores "C:\Windows\System32" but alerts on "c:\windows\system32"
Internal encryption is another example of where peers should be consulted to determine the best course of action before deploying C further into a network.
The encryption of internal C traffic depends upon several different factors:
Are there sensors inside the network?
Are there other encrypted communications occurring between target systems?
Would encrypted traffic standout more than unencrypted traffic?

Download 4.62 Mb.

Share with your friends:
1   ...   55   56   57   58   59   60   61   62   ...   96




The database is protected by copyright ©ininet.org 2024
send message

    Main page