Pentest Standard

Organização de alto nível do padrão
O padrão de execução de testes de penetração consiste em sete (7) seções

principais. Eles cobrem tudo relacionado a um teste de penetração - desde a
comunicação inicial e o raciocínio por trás de um pentest, passando pelas fases de coleta
de inteligência e modelagem de ameaças, onde os testadores trabalham nos bastidores
para obter uma melhor compreensão da organização testada, por meio de pesquisa de
vulnerabilidade, exploração e pós-exploração, onde o conhecimento técnico de
segurança dos testadores entra em ação e se combina com o entendimento comercial do
trabalho e, finalmente, ao relatório, que captura todo o processo, de uma maneira que
faça sentido para o cliente e forneça o mais valor para isso.
Esta versão pode ser considerada v1.0, pois os elementos principais do padrão estão
solidificados e foram "testados na estrada" por mais de um ano pela indústria. Uma
versão 2.0 estará em desenvolvimento em breve e fornecerá um trabalho mais granular
em termos de “níveis” – como nos níveis de intensidade nos quais cada um dos
elementos de um teste de penetração pode ser executado. Como nenhum pentest é igual
ao outro, e os testes irão variar desde o mais mundano teste de aplicação web ou rede,
até um envolvimento total da equipe vermelha, esses níveis permitirão que uma
organização defina quanta sofisticação espera que seu adversário exiba, e permitirá o
testador aumente a intensidade nas áreas onde a organização mais precisa. Parte do
trabalho inicial sobre “níveis” pode ser visto na seção de coleta de inteligência.
A seguir estão as principais seções definidas pela norma como base para a execução de
testes de penetração:
Interações pré-engajamento
Coleta de informação
Modelagem de ameaças
Análise de Vulnerabilidade
Exploração
Pós-exploração
Comunicando
Como o padrão não fornece nenhuma orientação técnica sobre como executar um
pentest real, também criamos um guia técnico para acompanhar o próprio padrão. O
guia técnico pode ser contatado através do link abaixo:
Diretrizes Técnicas
Para obter mais informações sobre o que é esse padrão, visite:
O padrão de execução de testes de penetração: perguntas frequentes
Pré-engajamento
Ir para a navegaçãoIr para pesquisar
Conteúdo
1Visão geral
2Introdução ao escopo
3Métricas para estimativa de tempo
4Reunião de escopo
5Suporte adicional com base na taxa horária
6Questionários
7Questões gerais
7.1Teste de penetração de rede
7.2Teste de penetração de aplicativos da Web
7.3Teste de penetração de rede sem fio
7.4Teste de penetração física
7,5Engenharia social
7.6Perguntas para gerentes de unidades de negócios
7.7Perguntas para administradores de sistemas
8Oportunista
9Especifique as datas de início e término
10Especifique intervalos de IP e domínios
10.1Validar intervalos
11Lidando com Terceiros
11.1Serviços na nuvem
11.2ISP
11.3MSSPs
11.4Países onde os servidores estão hospedados
12Definir pretextos aceitáveis de engenharia social
13Teste DoS
14Termos de pagamento
14.1Líquido 30
14.2Meio adiantado
14.3Recorrente
15Metas
15.1Primário
15.2Secundário
15.3Análise de negócio
16Estabeleça Linhas de Comunicação
17Informações para contato de emergência
17.1Processo de Relatório de Incidentes
17.2Definição de Incidente
17.3Frequência do relatório de status
17.4PGP e outras alternativas
18Regras de noivado
18.1Linha do tempo
18.2Localizações
18.3Tratamento de evidências
18.4Reuniões regulares de status
18,5Hora do dia para testar
18,6Lidando com a rejeição
18,7Permissão para testar
18,8Considerações legais
19Capacidades e tecnologia implementadas
Visão geral
O objetivo desta seção do PTES é apresentar e explicar as ferramentas e técnicas
disponíveis que auxiliam no sucesso da etapa de pré-engajamento de um teste de
penetração. As informações contidas nesta seção são o resultado de muitos anos de
experiência combinada de alguns dos testadores de penetração mais bem-sucedidos do
mundo.
Se você é um cliente em busca de um teste de penetração, recomendamos fortemente
que você vá para a seção Perguntas Gerais deste documento. Ele cobre as principais
questões que devem ser respondidas antes do início do teste. Lembre-se de que um teste
de penetração não deve ser conflituoso. Não deve ser uma atividade ver se o testador
pode “hackear” você. Deve tratar-se de identificar o risco comercial associado ao
ataque.
Para obter o valor máximo, certifique-se de que as questões deste documento sejam
abordadas. Além disso, à medida que a atividade de definição do escopo avança, uma
boa empresa de testes começará a fazer perguntas adicionais adaptadas à sua
organização.
Introdução ao escopo
Definir o escopo é sem dúvida um dos componentes mais importantes de um teste de
penetração, mas também é um dos mais negligenciados. Embora muitos volumes
tenham sido escritos sobre as diferentes ferramentas e técnicas que podem ser utilizadas
para obter acesso a uma rede, muito pouco foi escrito sobre o tema que precede a
penetração: a preparação. Negligenciar a conclusão adequada das atividades de pré-
engajamento tem o potencial de expor o testador de penetração (ou sua empresa) a uma
série de dores de cabeça, incluindo aumento de escopo, clientes insatisfeitos e até
mesmo problemas legais. O escopo de um projeto define especificamente o que deve ser
testado. A forma como cada aspecto do teste será conduzido será abordada na seção
Regras de Participação.
One key component of scoping an engagement is outlining how the testers should spend
their time. As an example, a customer requests that one hundred IP addresses be tested
for the price of $100,000. This means that the customer is offering $1,000 per IP address
tested. However, this cost structure only remains effective at that volume. A common
trap some testers fall into is maintaining linear costs throughout the testing process. If
the customer had only asked for one business-critical application to be tested at the
same pricing structure ($1,000), while the tester will still be only attacking a single IP,
the volume of work has increased dramatically. It is important to vary costs based on
work done. Otherwise a firm can easily find themselves undercharging for their
services, which motivates them to do a less than complete job.
Despite having a solid pricing structure, the process is not all black and white. It is not
uncommon for a client to be completely unaware of exactly what it is they need tested.
It is also possible the client will not know how to communicate effectively what they’re
expecting from the test. It is important in the Pre-Engagement phase that the tester is
able to serve as a guide through what may be uncharted territory for a customer. The
tester must understand the difference between a test which focuses on a single
application with severe intensity and a test where the client provides a wide range of IP
addresses to test and the goal is to simply find a way in.
Metrics for Time Estimation
Time estimations are directly tied to the experience of a tester in a certain area. If a
tester has significant experience in a certain test, he will likely innately be able to
determine how long a test will take. If the tester has less experience in the area, re-
reading emails and scan logs from previous similar tests the firm has done is a great way
to estimate the time requirement for the current engagement. Once the time to test is
determined, it is a prudent practice to add 20% to the time.
The extra 20% on the back end of the time value is called padding. Outside of
consultant circles, this is also referred to as consultant overhead. The padding is an
absolute necessity for any test. It provides a cushion should any interruptions occur in
the testing. There are many events which commonly occur and hinder the testing
process. For example, a network segment may go down, or a significant vulnerability
may be found which requires many meetings with many levels of management to
address. Both of these events are time consuming and would significantly impact the
original time estimate if the padding was not in place.
What happens if the 20% padding ends up not being necessary? Billing the client for
time not worked would be extremely unethical, so it is up to the testers to provide
additional value that may not normally have been provided if the engagement time limit
had been hit. Examples include walking the company security team through the steps
taken to exploit the vulnerability, provide an executive summary if it was not part of the
original deliverable list, or spend some additional time trying to crack a vulnerability
that was elusive during the initial testing.
Another component of the metrics of time and testing is that every project needs to have
a definitive drop dead date. All good projects have a well-defined beginning and end.
You will need to have a signed statement of work specifying the work and the hours
required if you’ve reached the specific date the testing is to end, or if any additional
testing or work is requested of you after that date. Some testers have a difficult time
doing this because they feel they are being too much of a pain when it comes to cost and
hours. However, it has been the experience of the author that if you provide exceptional
value for the main test the customer will not balk at paying you for additional work.
Scoping Meeting
In many cases the scoping meeting will occur after the contract has been signed.
Situations do occur wherein many of the scope-related topics can be discussed before
contract signing, but they are few and far between. For those situations it is
recommended that a non-disclosure agreement be signed before any in-depth scoping
discussions occur.
The goal of the scoping meeting is to discuss what will be tested. Rules of engagement
and costs will not be covered in this meeting. Each of these subjects should be handled
in meetings where each piece is the focus of that meeting. This is done because
discussions can easily become confused and muddled if focus is not explicitly stated. It
is important to act as moderator and keep the discussions on-topic, preventing tangents
and declaring certain topics more suited for off-line discussion when necessary.
Now that a Rough Order of Magnitude (ROM) value has been established for the
project it is time to have a meeting with the customer to validate assumptions. First, it
needs to be established explicitly what IP ranges are in scope for the engagement. It is
not uncommon for a client to be resistant and assume that it is the prerogative of the
tester to identify their network and attack it, to make the test as realistic as possible.
This would indeed be an ideal circumstance, however, possible legal ramifications must
be considered above all else. Because of this, it is the responsibility of the tester to
convey to a client these concerns and to impart upon them the importance of implicit
scoping. For example, in the meeting, it should be verified that the customer owns all of
the target environments including: the DNS server, the email server, the actual hardware
their web servers run on and their firewall/IDS/IPS solution. There are a number of
companies which will outsource the management of these devices to third parties.
Additionally, the countries, provinces, and states in which the target environments
operate in must be identified. Laws vary from region to region and the testing may very
well be impacted by these laws. For instance, countries belonging to the European
Union are well known to have very stringent laws surrounding the privacy of
individuals, which can significantly change the manner in which a social engineering
engagement would be executed.
Additional Support Based on Hourly Rate
Anything that is not explicitly covered within the scope of the engagement should be
handled very carefully. The first reason for this is scope creep. As the scope expands,
resources are consumed, cutting into the profits for the tester and may even create
confusion and anger on the part of the customer. There is another issue that many testers
do not think of when taking on additional work on an ad-hoc basis: legal ramifications.
Many ad-hoc requests are not properly documented so it can be difficult to determine
who said what in the event of a dispute or legal action. Further, the contract is a legal
document specifying the work that is to be done. It should be tightly tied to the
permission to test memo.
Any requests outside of the original scope should be documented in the form of a
statement of work that clearly identifies the work to be done. We also recommend that it
be clearly stated in the contract that additional work will be done for a flat fee per hour
and explicitly state that additional work can not be completed until a signed and
counter-signed SOW is in place.
Questionnaires
During initial communications with the customer there are several questions which the
client will have to answer in order for the engagement scope can be properly estimated.
These questions are designed to provide a better understanding of what the client is
looking to gain out of the penetration test, why the client is looking to have a
penetration test performed against their environment, and whether or not they want
certain types of tests performed during the penetration test. The following are sample
questions which may be asked during this phase.
General Questions
Network Penetration Test
Why is the customer having the penetration test performed against their environment?
Is the penetration test required for a specific compliance requirement?
When does the customer want the active portions (scanning, enumeration, exploitation,
etc...) of the penetration test conducted?
During business hours?
After business hours?
On the weekends?
How many total IP addresses are being tested?
How many internal IP addresses, if applicable?
How many external IP addresses, if applicable?
Are there any devices in place that may impact the results of a penetration test such as a
firewall, intrusion detection/prevention system, web application firewall, or load
balancer?
In the case that a system is penetrated, how should the testing team proceed?
Perform a local vulnerability assessment on the compromised machine?
Attempt to gain the highest privileges (root on Unix machines, SYSTEM or
Administrator on Windows machines) on the compromised machine?
Perform no, minimal, dictionary, or exhaustive password attacks against local password
hashes obtained (for example, /etc/shadow on Unix machines)?
Web Application Penetration Test
How many web applications are being assessed?
How many login systems are being assessed?
How many static pages are being assessed? (approximate)
How many dynamic pages are being assessed? (approximate)
Will the source code be made readily available?
Will there be any kind of documentation?
If yes, what kind of documentation?
Will static analysis be performed on this application?
Does the client want fuzzing performed against this application?
Does the client want role-based testing performed against this application?
Does the client want credentialed scans of web applications performed?
Wireless Network Penetration Test
How many wireless networks are in place?
Is a guest wireless network used? If so:
Does the guest network require authentication?
What type of encryption is used on the wireless networks?
What is the square footage of coverage?
Will enumeration of rogue devices be necessary?
Will the team be assessing wireless attacks against clients?
Approximately how many clients will be using the wireless network?
Physical Penetration Test
How many locations are being assessed?
Is this physical location a shared facility? If so:
How many floors are in scope?
Which floors are in scope?
Are there any security guards that will need to be bypassed? If so:
Are the security guards employed through a 3rd party?
Are they armed?
Are they allowed to use force?
How many entrances are there into the building?
Is the use of lock picks or bump keys allowed? (also consider local laws)
Is the purpose of this test to verify compliance with existing policies and procedures or
for performing an audit?
What is the square footage of the area in scope?
Are all physical security measures documented?
Are video cameras being used?
Are the cameras client-owned? If so:
Should the team attempt to gain access to where the video camera data is stored?
Is there an armed alarm system being used? If so:
Is the alarm a silent alarm?
Is the alarm triggered by motion?
Is the alarm triggered by opening of doors and windows?
Social Engineering
Does the client have a list of email addresses they would like a Social Engineering
attack to be performed against?
Does the client have a list of phone numbers they would like a Social Engineering
attack to be performed against?
Is Social Engineering for the purpose of gaining unauthorized physical access
approved? If so:
How many people will be targeted?
It should be noted that as part of different levels of testing, the questions for Business
Unit Managers, Systems Administrators, and Help Desk Personnel may not be required.
However, in the case these questions are necessary, some sample questions can be found
below.
Questions for Business Unit Managers
Is the manager aware that a test is about to be performed?
What is the main datum that would create the greatest risk to the organization if
exposed, corrupted, or deleted?
Are testing and validation procedures to verify that business applications are
functioning properly in place?
Will the testers have access to the Quality Assurance testing procedures from when the
application was first developed?
Are Disaster Recovery Procedures in place for the application data?
Questions for Systems Administrators
Are there any systems which could be characterized as fragile? (systems with tendencies
to crash, older operating systems, or which are unpatched)
Are there systems on the network which the client does not own, that may require
additional approval to test?
Are Change Management procedures in place?
What is the mean time to repair systems outages?
Is any system monitoring software in place?
What are the most critical servers and applications?
Are backups tested on a regular basis?
When was the last time the backups were restored?
Scope Creep
Scope creep is one of the most efficient ways to put a penetration testing firm out of
business. The issue is that many companies and managers have little to no idea how to
identify it, or how to react to it when it happens.
There are a couple of things to remember when battling scope creep. First, if a customer
is pleased with the work done on a particular engagement, it is very common for them
to request additional work. Take this as a compliment, and do not hesitate to ask for
additional funding to compensate for the extra time spent. If a customer refuses to pay
for the extra work, it is almost never worth staying on to do that work.
The second point is even more critical. When dealing with existing customers, take care
to keep the prices lower. Taking advantage of a good situation by price gouging is a sure
way to drive away repeat business. Take into consideration that prices can be lowered
since the firm avoided the costs of acquiring the customer such as the formal RFP
process and hunting for the customer itself. Further, the best source for future work is
through existing customers. Treat them well and they will return.
Specify Start and End Dates
Another key component defeating scope creep is explicitly stating start and end dates.
This allows the project to have definite end. One of the most common areas in which
scope creep occurs is during retesting. Retesting always sounds like a good idea when
going after a contract. It shows that the firm is caring and diligent, trying to make ensure
that the customer is secure as possible. The problem begins when it is forgotten that the
work is not paid for until it is completed. This includes retesting.
To mitigate this risk, add a simple statement to the contract which mentions that all
retesting must be done within a certain timeframe after the final report delivery. It then
becomes the responsibility of the testers to spearhead the retesting effort. If the
customer requests an extension, always allow this with the condition that payment be
fulfilled at the originally specified date. Finally, and most importantly, perform a quality
retest. Remember, the best source for future work is your existing customer base.
Specify IP Ranges and Domains
Before starting a penetration test, all targets must be identified. These targets should be
obtained from the customer during the initial questionnaire phase. Targets can be given
in the form of specific IP addresses, network ranges, or domain names by the customer.
In some instances, the only target the customer provides is the name of the organization
and expects the testers be able to identify the rest on their own. It is important to define
if systems like firewalls and IDS/IPS or networking equipment that are between the
tester and the final target are also part of the scope. Additional elements such as
upstream providers, and other 3rd party providers should be identified and defined
whether they are in scope or not.
Validate Ranges
It is imperative that before you start to attack the targets you validate that they are in
fact owned by the customer you are performing the test against. Think of the legal
consequences you may run into if you start attacking a machine and successfully
penetrate it only to find out later down the line that the machine actually belongs to
another organization (such as a hospital or government agency).
Dealing with Third Parties
There are a number of situations where an engagement will include testing a service or
an application that is being hosted by a third party. This has become more prevalent in
recent years as “cloud” services have become more popular. The most important thing
to remember is that while permission may have been granted by the client, they do not
speak for their third party providers. Thus, permission must be obtained from them as
well in order to test the hosted systems. Failing to obtain the proper permissions brings
with it, as always, the possibility of violating the law, which can cause endless
headaches.
Cloud Services
The single biggest issue with testing cloud service is there is data from multiple
different organizations stored on one physical medium. Often the security between these
different data domains is very lax. The cloud services provider needs to be alerted to the
testing and needs to acknowledge that the test is occurring and grant the testing
organization permission to test. Further, there needs to be a direct security contact
within the cloud service provider that can be contacted in the event that a security
vulnerability is discovered which may impact the other cloud customers. Some cloud
providers have specific procedures for penetration testers to follow, and may require
request forms, scheduling or explicit permission from them before testing can begin.
ISP
Verify the ISP terms of service with the customer. In many commercial situations the
ISP will have specific provisions for testing. Review these terms carefully before
launching an attack. There are situations where ISPs will shun and block certain traffic
which is considered malicious. The customer may approve this risk, but it must always
be clearly communicated before beginning. Web Hosting As with all other third parties,
the scope and timing of the test needs to be clearly communicated with the web hosting
provider. Also, when communicating with the client, be sure to clearly articulate the test
will only be in search of web vulnerabilities. The test will not uncover vulnerabilities in
the underlying infrastructure which may still provide an avenue to compromise the
application.
MSSPs
Managed Security Service Providers also may need to be notified of testing.
Specifically, they will need to be notified when the systems and services that they own
are to be tested. However, there are circumstances under which the MSSP would not be
notified. If determining the actual response time of the MSSP is part of the test, it is
certainly not in the best interest of the integrity of the test for the MSSP to be notified.
As a general rule of thumb, any time a device or service explicitly owned by the MSSP
is being tested they will need to be notified.
Countries Where Servers are Hosted
It is also in the best interests of the tester to verify the countries where servers are being
housed. After you have validated the country, review the laws of the specific country
before beginning testing. It should not be assumed that the firm’s legal team will
provide a complete synopsis of local laws for the testers. It should also not be assumed
that the firm will take legal responsibility for any laws violated by its testers. It is the
responsibility of each tester to verify the laws for each region they are testing in before
they begin testing because it will be the tester who ultimately will have to answer for
any transgressions.
Define Acceptable Social Engineering Pretexts
Many organizations will want their security posture tested in a way which is aligned
with current attacks. Social engineering and spear-phishing attacks are currently widely
used by many attackers today. While most of the successful attacks use pretexts like sex,
drugs, and rock and roll (porn, Viagra, and free iPods respectively) some of these
pretexts may not be acceptable in a corporate environment. Be sure that any pretexts
chosen for the test are approved in writing before testing is to begin.
DoS Testing
Stress testing or Denial of Service testing should be discussed before the engagement
begins. It can be a topic that many organizations are uncomfortable with due to the
potentially damaging nature of the testing. If an organization is only worried about the
confidentiality or integrity of their data, stress testing may not be necessary; however, if
the organization is also worried about the availability of their services, then the stress
testing should be conducted in a non-production environment which is identical to the
production environment.
Payment Terms
Another aspect of preparing for a test that many testers completely forget about is how
they should be paid. Just like contract dates there should be specific dates and terms for
payments. It is not uncommon for larger organizations to delay payment for as long as
possible. Below are a few common payment methods. These are simply examples. It is
definitely recommended that each organization create and tweak their own pricing
structure to more aptly suit the needs of their clients and themselves. The important
thing is that some sort of structure be in place before testing begins.
Net 30
The total amount is due within 30 days of the delivery of the final report. This is usually
associated with a per month percentage penalty for non-payment. This can be any
number of days you wish to grant your customers (i.e. 45, or 60).
Half Upfront
It is not uncommon to require half of the total bill upfront before testing begins. This is
very common for longer-term engagements.
Recurring
A recurring payment schedule is more commonly used for long-term engagements. For
example, some engagements may span as far as a year or two. It is not at all uncommon
to have the customer pay in regular installments throughout the year.
Goals
Every penetration test should be goal-oriented. This is to say that the purpose of the test
is to identify specific vulnerabilities that lead to a compromise of the business or
mission objectives of the customer. It is not about finding un-patched systems. It is
about identifying risk that will adversely impact the organization.
Primary
The primary goal of a test should not be driven by compliance. There are a number of
different justifications for this reasoning. First, compliance does not equal security.
While it should be understood that many organizations undergo testing because of
compliance it should not be the main goal of the test. For example, a firm may be hired
to complete a penetration test as part of PCI-DSS requirements.
There is no shortage of companies which process credit card information. However, the
traits which make the target organization unique and viable in a competitive market will
have the greatest impact if compromised. Credit card systems being compromised
would certainly be a serious issue, but credit cards numbers, along with all of the
associated customer data being leaked would be catastrophic.
Secondary
The secondary goals are directly related to compliance. It is not uncommon for primary
and secondary goals to be very closely related. For example, in the example of the PCI-
DSS driven test, getting the credit cards is the secondary goal. Tying that breach of data
to the business or mission drivers of the organization is the primary goal. Secondary
goals mean something for compliance and/or IT. Primary goals get the attention of
upper management.
Business Analysis
Before performing a penetration test it is beneficial to determine the maturity level of
the client’s security posture. There are a number of organizations which choose to jump
directly into a penetration test first assessing this maturity level. For customers with a
very immature security program, it is often a good idea to perform a vulnerability
analysis first.
Some testers believe there is a stigma surrounding Vulnerability Analysis (VA) work.
Those testers have forgotten that the goal is to identify risks in the target organization,
not about pursuing the so-called “rockstar” lifestyle. If a company is not ready for a full
penetration test, they will get far more value out of a good VA than a penetration test.
Establish with the customer in advance what information about the systems they will be
providing. It may also be helpful to ask for information about vulnerabilities which are
already documented. This will save the testers time and save the client money by not
overlapping testing discoveries with known issues. Likewise, a full or partial white-box
test may bring the customer more value than a black-box test, if it isn't absolutely
required by compliance.
Establish Lines of Communication
One of the most important aspects of any penetration test is communication with the
customer. How often you interact with the customer, and the manner in which you
approach them, can make a huge difference in their feeling of satisfaction. Below is a
communication framework that will aid in making the customer feel comfortable about
the test activities.
Emergency Contact Information
Obviously, being able to get in touch with the customer or target organization in an
emergency is vital. Emergencies may arise, and a point of contact must have been
established in order to handle them. Create an emergency contact list. This list should
include contact information for all parties in the scope of testing. Once created, the
emergency contact list should be shared with all those on the list. Keep in mind, the
target organization may not be the customer.
Gather the following information about each emergency contact:
Full name
Title and operational responsibility
Authorization to discuss details of the testing activities, if not already specified
Two forms of 24/7 immediate contact, such as cell phone, pager, or home phone, if
possible
One form of secure bulk data transfer, such as SFTP or encrypted email
Note: The number for a group such as the help desk or operations center can replace one
emergency contact, but only if it is staffed 24/7. The nature of each penetration test
influences who should be on the emergency contact list. Not only will contact
information for the customer and targets need to be made available, but they may also
need to contact the testers in an emergency. The list should preferably include the
following people:
All penetration testers in the test group for the engagement
The manager of the test group
Two technical contacts at each target organization
Two technical contacts at the customer
One upper management or business contact at the customer
It is possible that there will be some overlap in the above list. For instance, the target
organization may be the customer, the test group’s manager may also be performing the
penetration test, or a customer’s technical contact may be in upper management. It is
also recommended to define a single contact person per involved party who leads it and
takes responsibility on behalf of it.
Incident Reporting Process
Discussing the organization’s current incident response capabilities is important to do
before an engagement for several reasons. Part of a penetration test is not only testing
the security an organization has in place, but also their incident response capabilities.
If an entire engagement can be completed without the target’s internal security teams
ever noticing, a major gap in security posture has been identified. It is also important to
ensure that before testing begins, someone at the target organization is aware of when
the tests are being conducted so the incident response team does not start to call every
member of upper management in the middle of the night because they thought they
were under attack or compromised.
Incident Definition
The National Institute of Standards and Technology (NIST) defines an incident as
follows: “a violation or imminent threat of violation of computer security policies,
acceptable use policies, or standard security practices.” (Computer Security Incident
Handling Guide - Special Publication 800-61 Rev 1). An incident can also occur on a
physical level, wherein a person gain unauthorized physical access to an area by any
means. The target organization should have different categories and levels for different
types of incidents.
Status Report Frequency
The frequency of status reporting can vary widely. Some factors which influence the
reporting schedule include the overall length of the test, the test scope, and the target’s
security maturity. An effective schedule allows the customer to feel engaged. An
ignored customer is a former customer.
Once frequency and schedule of status reports has been set, it must be fulfilled.
Postponing or delaying a status report may be necessary, but it should not become
chronic. The client may be asked to agree to a new schedule if necessary. Skipping a
status report altogether is unprofessional and should be avoided if at all possible.
PGP and Other Alternatives
Encryption is not optional. Communication with the customer is an absolutely necessary
part of any penetration testing engagement and due to the sensitive nature of the
engagement, communications of sensitive information must be encrypted, especially the
final report. Before the testing begins, a means of secure communication must be
established with the client. Several common means of encryption are as follows:
PGP/GPG can be used to both communicate over e-mail and to encrypt the final report
(remember that subject lines are passed through in plaintext)
A secure mailbox hosted on the customer’s network
Telephone
Face to face meetings
To deliver the final report, you can also store the report in an AES encrypted archive
file, but make sure that your archive utility supports AES encryption using CBC.
Also ask what kinds of information can be put in writing and which should be
communicated only verbally. Some organizations have very good reasons for limiting
what security information is transmitted to them in writing.
Rules of Engagement
While the scope defines what will be tested, the rules of engagement defines how that
testing is to occur. These are two different aspects which need to be handled
independently from each other.
Timeline
A clear timeline should be established for the engagement. While scope defines the start
and the end of an engagement, the rules of engagement define everything in between. It
should be understood that the timeline will change as the test progresses. However,
having a rigid timeline is not the goal of creating one. Rather, having a timeline in place
at the beginning of a test will allow everyone involved to more clearly identify the work
that is to be done and the people who will be responsible for said work. GANTT Charts
and Work Breakdown Structures are often used to define the work and the amount of
time that each specific piece of the work will take. Seeing the schedule broken down in
this manner aids those involved in identifying where resources need to be applied and it
helps the customer identify possible roadblocks which many be encountered during
testing.
There are a number of free GANTT Chart tools available on the Internet. Many mangers
identify closely with these tools. Because of this, they are an excellent medium for
communicating with the upper management of a target organization.
Locations
Another parameter of any given engagement which is important to establish with the
customer ahead of time is any destinations to which the testers will need to travel during
the test. This could be as simple as identifying local hotels, or complex as identifying
the applicable laws of a specific target country.
It is not uncommon for an organization to operate in multiple locations and regions and
a few select sites will need to be chosen for testing. In these situations, travel to every
customer location should be avoided, instead, it should be determined if VPN
connections to the sites are available for remote testing. Disclosure of Sensitive
Information
While one of the goals of a given engagement may be to gain access to sensitive
information, certain information should not actually be viewed or downloaded. This
seems odd to newer testers, however, there are a number of situations where the testers
should not have the target data in their possession. For example Personal Health
Information (PHI), under the Health Insurance Portability and Accountability Act
(HIPAA), this data must be protected. In some situations, the target system may not
have a firewall or anti-virus (AV) protecting it. In this sort of situation, the testers being
in possession of any and all Personally Identifiable Information (PII) should be
absolutely avoided.
However, if the data cannot be physically or virtually obtained, how can it be proved
that the testers indeed obtained access to the information? This problem has been solved
in a number of ways. There are ways to prove that the vault door was opened without
taking any of the money. For instance, a screenshot of database schema and file
permissions can be taken, or the files themselves can be displayed without opening them
to displaying the content, as long as no PII is visible in the filenames themselves.
How cautious the testers should be on a given engagement is a parameter which needs
to be discussed with the client, but the firm doing the testing should always be sure to
protect themselves in a legal sense regardless of client opinion. Regardless of supposed
exposure to sensitive data, all report templates and tester machines should be
sufficiently scrubbed following each engagement. As a special side note, if illegal data
(i.e. child pornography) is discovered by the testers, proper law enforcement officials
should be notified immediately, followed by the customer. Do not take direction from
the customer.
Evidence Handling
When handling evidence of a test and the differing stages of the report it is incredibly
important to take extreme care with the data. Always use encryption and sanitize your
test machine between tests. Never hand out USB sticks with test reports out at security
conferences. And whatever you do, don't re-use a report from another customer
engagement as a template! It's very unprofessional to leave references to another
organization in your document.
Regular Status Meetings
Throughout the testing process it is critical to have regular meetings with the customer
informing them of the overall progress of the test. These meetings should be held daily
and should be as short as possible. Meetings should be kept to three concepts: plans,
progress and problems.
Plans are generally discussed so that testing is not conducted during a major
unscheduled change or an outage. Progress is simply an update to the customer on what
has been completed so far. Problems should also be discussed in this meeting, but in the
interest of brevity, conversations concerning solutions should almost always be taken
offline.
Time of the Day to Test
Certain customers require all testing to be done outside of business hours. This can
mean late nights for most testers. The time of day requirements should be well
established with the customer before testing begins.
Dealing with Shunning
Há momentos em que a rejeição é perfeitamente aceitável e há momentos em que pode
não se adequar ao espírito do teste. Por exemplo, se o seu teste for um teste de caixa
preta completo, onde você está testando não apenas a tecnologia, mas também os
recursos da equipe de segurança da organização alvo, evitá-lo seria perfeitamente
aceitável. No entanto, quando você está testando um grande número de sistemas em
coordenação com a equipe de segurança da organização alvo, pode não ser do interesse
do teste evitar seus ataques.
Permissão para testar
Um dos documentos mais importantes que precisam ser obtidos para um teste de
penetração é o documento Permissão para Teste. Este documento declara o escopo e
contém uma assinatura que reconhece o conhecimento das atividades dos
testadores. Além disso, deve indicar claramente que os testes podem levar à
instabilidade do sistema e todo o cuidado devido será dado pelo testador para não travar
os sistemas no processo. No entanto, como os testes podem levar à instabilidade, o
cliente não deverá responsabilizar o testador por qualquer instabilidade ou falha do
sistema. É fundamental que os testes não comecem até que este documento seja
assinado pelo cliente.
Além disso, alguns provedores de serviços exigem aviso prévio e/ou permissão separada
antes de testar seus sistemas. Por exemplo, a Amazon possui um formulário de
solicitação on-line que deve ser preenchido e a solicitação deve ser aprovada antes de
verificar qualquer host em sua nuvem. Se for necessário, deverá fazer parte do
documento.
Considerações legais
Algumas atividades comuns em testes de penetração podem violar as leis locais. Por
este motivo, é aconselhável verificar a legalidade das tarefas comuns de pentest no local
onde o trabalho será realizado. Por exemplo, quaisquer chamadas VOIP capturadas
durante o teste de penetração podem ser consideradas escutas telefônicas em algumas
áreas.
Capacidades e tecnologia implementadas
Bons testes de penetração não verificam simplesmente sistemas sem patches. Eles
também testam as capacidades da organização-alvo. Para esse fim, abaixo está uma lista
de coisas que você pode avaliar durante o teste.
Capacidade de detectar e responder à coleta de informações
Capacidade de detectar e responder à impressão do pé
Capacidade de detectar e responder a varreduras e análises de vulnerabilidades
Capacidade de detectar e responder a infiltrações (ataques)
Capacidade de detectar e responder à agregação de dados
Capacidade de detectar e responder à exfiltração de dados
Ao rastrear essas informações, certifique-se de coletar informações de tempo. Por
exemplo, se uma varredura for detectada, você deverá ser notificado e anotar qual nível
de varredura você estava realizando no momento.
Parte superior do formulário
Parte inferior do formulário
Organização de alto nível do padrão

O padrão de execução de testes de penetração consiste em sete (7) seções
principais. Eles cobrem tudo relacionado a um teste de penetração - desde a
comunicação inicial e o raciocínio por trás de um pentest, passando pelas fases de coleta
de inteligência e modelagem de ameaças, onde os testadores trabalham nos bastidores
para obter uma melhor compreensão da organização testada, por meio de pesquisa de
vulnerabilidade, exploração e pós-exploração, onde o conhecimento técnico de
segurança dos testadores entra em ação e se combina com o entendimento comercial do
trabalho e, finalmente, ao relatório, que captura todo o processo, de uma maneira que
faça sentido para o cliente e forneça o mais valor para isso.
Esta versão pode ser considerada v1.0, pois os elementos principais do padrão estão
solidificados e foram "testados na estrada" por mais de um ano pela indústria. Uma
versão 2.0 estará em desenvolvimento em breve e fornecerá um trabalho mais granular
em termos de “níveis” – como nos níveis de intensidade nos quais cada um dos
elementos de um teste de penetração pode ser executado. Como nenhum pentest é igual
ao outro, e os testes irão variar desde o mais mundano teste de aplicação web ou rede,
até um envolvimento total da equipe vermelha, esses níveis permitirão que uma
organização defina quanta sofisticação espera que seu adversário exiba, e permitirá o
testador aumente a intensidade nas áreas onde a organização mais precisa. Parte do
trabalho inicial sobre “níveis” pode ser visto na seção de coleta de inteligência.
A seguir estão as principais seções definidas pela norma como base para a execução de
testes de penetração:
Interações pré-engajamento
Exploração
Pós-exploração
Comunicando
Como o padrão não fornece nenhuma orientação técnica sobre como executar um
pentest real, também criamos um guia técnico para acompanhar o próprio padrão. O
guia técnico pode ser contatado através do link abaixo:
Diretrizes Técnicas
Para obter mais informações sobre o que é esse padrão, visite:
O padrão de execução de testes de penetração: perguntas frequentes
Pré-engajamento
Conteúdo
1Visão geral
4Reunião de escopo
6Questionários
7Questões gerais
8Oportunista
11.2ISP
11.3MSSPs
13Teste DoS
14.1Líquido 30
14.2Meio adiantado
14.3Recorrente
15Metas
15.1Primário
15.2Secundário
18Regras de noivado
18.1Linha do tempo
18.2Localizações
Visão geral
mundo.
ataque.
organização.
Um componente-chave para definir o escopo de um compromisso é descrever como os
testadores devem gastar seu tempo. Por exemplo, um cliente solicita que cem endereços
IP sejam testados pelo preço de US$ 100.000. Isso significa que o cliente está
oferecendo US$ 1.000 por endereço IP testado. No entanto, esta estrutura de custos só
permanece eficaz nesse volume. Uma armadilha comum em que alguns testadores caem
é manter custos lineares durante todo o processo de teste. Se o cliente tivesse solicitado
apenas que um aplicativo crítico para os negócios fosse testado com a mesma estrutura
de preços (US$ 1.000), enquanto o testador ainda atacaria apenas um único IP, o volume
de trabalho aumentaria dramaticamente. É importante variar os custos com base no
trabalho realizado. Caso contrário, uma empresa pode facilmente encontrar-se a cobrar
menos pelos seus serviços, o que a motiva a fazer um trabalho menos do que completo.
Apesar de ter uma estrutura de preços sólida, o processo não é todo preto e branco. Não
é incomum que um cliente não saiba exatamente o que precisa ser testado. Também é
possível que o cliente não saiba comunicar de forma eficaz o que espera do teste. É
importante na fase de pré-engajamento que o testador seja capaz de servir como um guia
através do que pode ser um território desconhecido para um cliente. O testador deve
compreender a diferença entre um teste que se concentra em um único aplicativo com
intensidade severa e um teste em que o cliente fornece uma ampla variedade de
endereços IP para testar e o objetivo é simplesmente encontrar uma maneira de entrar.
Métricas para estimativa de tempo
As estimativas de tempo estão diretamente ligadas à experiência de um testador em uma
determinada área. Se um testador tiver experiência significativa em um determinado
teste, ele provavelmente será capaz de determinar inatamente quanto tempo um teste
levará. Se o testador tiver menos experiência na área, reler e-mails e verificar logs de
testes semelhantes anteriores que a empresa fez é uma ótima maneira de estimar o
tempo necessário para o trabalho atual. Uma vez determinado o tempo de teste, é uma
prática prudente adicionar 20% ao tempo.
Os 20% extras no final do valor do tempo são chamados de preenchimento. Fora dos
círculos de consultoria, isso também é conhecido como despesas gerais de
consultoria. O preenchimento é uma necessidade absoluta para qualquer teste. Ele
fornece uma proteção caso ocorra alguma interrupção no teste. Existem muitos eventos
que comumente ocorrem e dificultam o processo de teste. Por exemplo, um segmento de
rede pode cair ou pode ser encontrada uma vulnerabilidade significativa que requer
muitas reuniões com vários níveis de gestão para ser resolvida. Ambos os eventos são
demorados e impactariam significativamente a estimativa de tempo original se o
preenchimento não estivesse em vigor.
O que acontece se o preenchimento de 20% acabar não sendo necessário? Cobrar o
cliente pelo tempo não trabalhado seria extremamente antiético, portanto cabe aos
testadores fornecer valor adicional que normalmente não teria sido fornecido se o limite
de tempo de engajamento tivesse sido atingido. Os exemplos incluem orientar a equipe
de segurança da empresa sobre as etapas tomadas para explorar a vulnerabilidade,
fornecer um resumo executivo se ela não fizesse parte da lista de entrega original ou
gastar algum tempo adicional tentando quebrar uma vulnerabilidade que era elusiva
durante o teste inicial.
Outro componente das métricas de tempo e testes é que todo projeto precisa ter um
prazo final definitivo. Todos os bons projetos têm começo e fim bem definidos. Você
precisará ter uma declaração de trabalho assinada especificando o trabalho e as horas
necessárias se tiver atingido a data específica de término do teste ou se algum teste ou
trabalho adicional for solicitado após essa data. Alguns testadores têm dificuldade em
fazer isso porque sentem que estão sendo muito chatos quando se trata de custos e
horas. No entanto, a experiência do autor mostra que, se você fornecer um valor
excepcional para o teste principal, o cliente não hesitará em pagar por trabalho
adicional.
Reunião de escopo
Em muitos casos, a reunião de definição do âmbito ocorrerá após a assinatura do
contrato. Ocorrem situações em que muitos dos tópicos relacionados ao escopo podem
ser discutidos antes da assinatura do contrato, mas são poucas e raras. Para essas
situações, recomenda-se que seja assinado um acordo de confidencialidade antes de
ocorrer qualquer discussão aprofundada sobre o âmbito.
O objetivo da reunião de definição do escopo é discutir o que será testado. As regras de
envolvimento e os custos não serão abordados nesta reunião. Cada um desses assuntos
deve ser tratado em reuniões onde cada peça seja o foco daquela reunião. Isto é feito
porque as discussões podem facilmente tornar-se confusas e confusas se o foco não for
explicitamente declarado. É importante atuar como moderador e manter as discussões
dentro do tema, evitando tangentes e declarando determinados temas mais adequados
para discussão off-line quando necessário.
Agora que um valor de Ordem de Magnitude (ROM) foi estabelecido para o projeto, é
hora de realizar uma reunião com o cliente para validar as suposições. Primeiro, é
necessário estabelecer explicitamente quais faixas de IP estão no escopo do
envolvimento. Não é incomum um cliente resistir e assumir que é prerrogativa do
testador identificar sua rede e atacá-la, para tornar o teste o mais realista possível. Esta
seria de facto uma circunstância ideal, no entanto, possíveis ramificações legais devem
ser consideradas acima de tudo. Por causa disso, é responsabilidade do testador
transmitir essas preocupações ao cliente e transmitir-lhe a importância do escopo
implícito. Por exemplo, na reunião, deve ser verificado se o cliente possui todos os
ambientes de destino, incluindo: o servidor DNS, o servidor de e-mail, o hardware real
em que seus servidores web são executados e sua solução de firewall/IDS/IPS. Existem
várias empresas que terceirizam a gestão destes dispositivos a terceiros.
Além disso, os países, províncias e estados nos quais os ambientes alvo operam devem
ser identificados. As leis variam de região para região e os testes podem muito bem ser
afetados por essas leis. Por exemplo, os países pertencentes à União Europeia são bem
conhecidos por terem leis muito rigorosas em torno da privacidade dos indivíduos, o
que pode alterar significativamente a forma como um compromisso de engenharia
social seria executado.
Suporte adicional com base na taxa horária
Qualquer coisa que não esteja explicitamente coberta no âmbito do trabalho deve ser
tratada com muito cuidado. A primeira razão para isso é o aumento do escopo. À
medida que o escopo se expande, recursos são consumidos, reduzindo os lucros do
testador e podendo até criar confusão e raiva por parte do cliente. Há outra questão em
que muitos testadores não pensam quando assumem trabalhos adicionais de forma ad
hoc: ramificações legais. Muitas solicitações ad hoc não estão devidamente
documentadas, por isso pode ser difícil determinar quem disse o quê em caso de disputa
ou ação legal. Além disso, o contrato é um documento legal que especifica o trabalho a
ser realizado. Deve estar intimamente vinculado à permissão para testar o memorando.
Quaisquer solicitações fora do escopo original devem ser documentadas na forma de
uma declaração de trabalho que identifique claramente o trabalho a ser
realizado. Recomendamos também que seja claramente indicado no contrato que o
trabalho adicional será realizado por uma taxa fixa por hora e declare explicitamente
que o trabalho adicional não pode ser concluído até que uma SOW assinada e
referendada esteja em vigor.
Pré-engajamento
Conteúdo
1Visão geral
4Reunião de escopo
6Questionários
7Questões gerais
8Oportunista
11.2ISP
11.3MSSPs
13Teste DoS
14.1Líquido 30
14.2Meio adiantado
14.3Recorrente
15Metas
15.1Primário
15.2Secundário
18Regras de noivado
18.1Linha do tempo
18.2Localizações
Visão geral
mundo.
ataque.
organização.
Um componente-chave para definir o escopo de um compromisso é descrever como os
testadores devem gastar seu tempo. Por exemplo, um cliente solicita que cem endereços
IP sejam testados pelo preço de US$ 100.000. Isso significa que o cliente está
oferecendo US$ 1.000 por endereço IP testado. No entanto, esta estrutura de custos só
permanece eficaz nesse volume. Uma armadilha comum em que alguns testadores caem
é manter custos lineares durante todo o processo de teste. Se o cliente tivesse solicitado
apenas que um aplicativo crítico para os negócios fosse testado com a mesma estrutura
de preços (US$ 1.000), enquanto o testador ainda atacaria apenas um único IP, o volume
de trabalho aumentaria dramaticamente. É importante variar os custos com base no
trabalho realizado. Caso contrário, uma empresa pode facilmente encontrar-se a cobrar
menos pelos seus serviços, o que a motiva a fazer um trabalho menos do que completo.
Apesar de ter uma estrutura de preços sólida, o processo não é todo preto e branco. Não
é incomum que um cliente não saiba exatamente o que precisa ser testado. Também é
possível que o cliente não saiba comunicar de forma eficaz o que espera do teste. É
importante na fase de pré-engajamento que o testador seja capaz de servir como um guia
através do que pode ser um território desconhecido para um cliente. O testador deve
compreender a diferença entre um teste que se concentra em um único aplicativo com
intensidade severa e um teste em que o cliente fornece uma ampla variedade de
endereços IP para testar e o objetivo é simplesmente encontrar uma maneira de entrar.
Métricas para estimativa de tempo
As estimativas de tempo estão diretamente ligadas à experiência de um testador em uma
determinada área. Se um testador tiver experiência significativa em um determinado
teste, ele provavelmente será capaz de determinar inatamente quanto tempo um teste
levará. Se o testador tiver menos experiência na área, reler e-mails e verificar logs de
testes semelhantes anteriores que a empresa fez é uma ótima maneira de estimar o
tempo necessário para o trabalho atual. Uma vez determinado o tempo de teste, é uma
prática prudente adicionar 20% ao tempo.
Os 20% extras no final do valor do tempo são chamados de preenchimento. Fora dos
círculos de consultoria, isso também é conhecido como despesas gerais de
consultoria. O preenchimento é uma necessidade absoluta para qualquer teste. Ele
fornece uma proteção caso ocorra alguma interrupção no teste. Existem muitos eventos
que comumente ocorrem e dificultam o processo de teste. Por exemplo, um segmento de
rede pode cair ou pode ser encontrada uma vulnerabilidade significativa que requer
muitas reuniões com vários níveis de gestão para ser resolvida. Ambos os eventos são
demorados e impactariam significativamente a estimativa de tempo original se o
preenchimento não estivesse em vigor.
O que acontece se o preenchimento de 20% acabar não sendo necessário? Cobrar o
cliente pelo tempo não trabalhado seria extremamente antiético, portanto cabe aos
testadores fornecer valor adicional que normalmente não teria sido fornecido se o limite
de tempo de engajamento tivesse sido atingido. Os exemplos incluem orientar a equipe
de segurança da empresa sobre as etapas tomadas para explorar a vulnerabilidade,
fornecer um resumo executivo se ela não fizesse parte da lista de entrega original ou
gastar algum tempo adicional tentando quebrar uma vulnerabilidade que era elusiva
durante o teste inicial.
Outro componente das métricas de tempo e testes é que todo projeto precisa ter um
prazo final definitivo. Todos os bons projetos têm começo e fim bem definidos. Você
precisará ter uma declaração de trabalho assinada especificando o trabalho e as horas
necessárias se tiver atingido a data específica de término do teste ou se algum teste ou
trabalho adicional for solicitado após essa data. Alguns testadores têm dificuldade em
fazer isso porque sentem que estão sendo muito chatos quando se trata de custos e
horas. No entanto, a experiência do autor mostra que, se você fornecer um valor
excepcional para o teste principal, o cliente não hesitará em pagar por trabalho
adicional.
Reunião de escopo
Em muitos casos, a reunião de definição do âmbito ocorrerá após a assinatura do
contrato. Ocorrem situações em que muitos dos tópicos relacionados ao escopo podem
ser discutidos antes da assinatura do contrato, mas são poucas e raras. Para essas
situações, recomenda-se que seja assinado um acordo de confidencialidade antes de
ocorrer qualquer discussão aprofundada sobre o âmbito.
O objetivo da reunião de definição do escopo é discutir o que será testado. As regras de
envolvimento e os custos não serão abordados nesta reunião. Cada um desses assuntos
deve ser tratado em reuniões onde cada peça seja o foco daquela reunião. Isto é feito
porque as discussões podem facilmente tornar-se confusas e confusas se o foco não for
explicitamente declarado. É importante atuar como moderador e manter as discussões
dentro do tema, evitando tangentes e declarando determinados temas mais adequados
para discussão off-line quando necessário.
Agora que um valor de Ordem de Magnitude (ROM) foi estabelecido para o projeto, é
hora de realizar uma reunião com o cliente para validar as suposições. Primeiro, é
necessário estabelecer explicitamente quais faixas de IP estão no escopo do
envolvimento. Não é incomum um cliente resistir e assumir que é prerrogativa do
testador identificar sua rede e atacá-la, para tornar o teste o mais realista possível. Esta
seria de facto uma circunstância ideal, no entanto, possíveis ramificações legais devem
ser consideradas acima de tudo. Por causa disso, é responsabilidade do testador
transmitir essas preocupações ao cliente e transmitir-lhe a importância do escopo
implícito. Por exemplo, na reunião, deve ser verificado se o cliente possui todos os
ambientes de destino, incluindo: o servidor DNS, o servidor de e-mail, o hardware real
em que seus servidores web são executados e sua solução de firewall/IDS/IPS. Existem
várias empresas que terceirizam a gestão destes dispositivos a terceiros.
Além disso, os países, províncias e estados nos quais os ambientes alvo operam devem
ser identificados. As leis variam de região para região e os testes podem muito bem ser
afetados por essas leis. Por exemplo, os países pertencentes à União Europeia são bem
conhecidos por terem leis muito rigorosas em torno da privacidade dos indivíduos, o
que pode alterar significativamente a forma como um compromisso de engenharia
social seria executado.
Suporte adicional com base na taxa horária
Qualquer coisa que não esteja explicitamente coberta no âmbito do trabalho deve ser
tratada com muito cuidado. A primeira razão para isso é o aumento do escopo. À
medida que o escopo se expande, recursos são consumidos, reduzindo os lucros do
testador e podendo até criar confusão e raiva por parte do cliente. Há outra questão em
que muitos testadores não pensam quando assumem trabalhos adicionais de forma ad
hoc: ramificações legais. Muitas solicitações ad hoc não estão devidamente
documentadas, por isso pode ser difícil determinar quem disse o quê em caso de disputa
ou ação legal. Além disso, o contrato é um documento legal que especifica o trabalho a
ser realizado. Deve estar intimamente vinculado à permissão para testar o memorando.
Quaisquer solicitações fora do escopo original devem ser documentadas na forma de
uma declaração de trabalho que identifique claramente o trabalho a ser
realizado. Recomendamos também que seja claramente indicado no contrato que o
trabalho adicional será realizado por uma taxa fixa por hora e declare explicitamente
que o trabalho adicional não pode ser concluído até que uma SOW assinada e
referendada esteja em vigor.
Questionários
Durante as comunicações iniciais com o cliente, existem várias perguntas que o cliente
terá que responder para que o escopo do trabalho possa ser adequadamente
estimado. Essas perguntas foram elaboradas para fornecer uma melhor compreensão do
que o cliente busca obter com o teste de penetração, por que o cliente deseja realizar um
teste de penetração em seu ambiente e se deseja ou não que determinados tipos de testes
sejam realizados durante o teste de penetração. A seguir estão exemplos de perguntas
que podem ser feitas durante esta fase.
Questões gerais
Teste de penetração de rede
Por que o cliente está realizando o teste de penetração em seu ambiente?
O teste de penetração é necessário para um requisito de conformidade específico?
Quando o cliente deseja que as partes ativas (varredura, enumeração, exploração, etc...)
do teste de penetração sejam realizadas?
Durante o horário comercial?
Depois do horário comercial?
Nos finais de semana?
Quantos endereços IP totais estão sendo testados?
Quantos endereços IP internos, se aplicável?
Quantos endereços IP externos, se aplicável?
Há algum dispositivo instalado que possa afetar os resultados de um teste de penetração,
como firewall, sistema de detecção/prevenção de invasões, firewall de aplicativos da
Web ou balanceador de carga?
Caso um sistema seja invadido, como a equipe de testes deve proceder?
Realizar uma avaliação de vulnerabilidade local na máquina comprometida?
Tentativa de obter os privilégios mais altos (root em máquinas Unix, SYSTEM ou
Administrador em máquinas Windows) na máquina comprometida?
Executar ataques de senha nulos, mínimos, de dicionário ou exaustivos contra hashes de
senha locais obtidos (por exemplo, /etc/shadow em máquinas Unix)?
Teste de penetração de aplicativos da Web
Quantas aplicações web estão sendo avaliadas?
Quantos sistemas de login estão sendo avaliados?
Quantas páginas estáticas estão sendo avaliadas? (aproximado)
Quantas páginas dinâmicas estão sendo avaliadas? (aproximado)
O código-fonte estará prontamente disponível?
Haverá algum tipo de documentação?
Se sim, que tipo de documentação?
A análise estática será realizada nesta aplicação?
O cliente deseja que a difusão seja realizada neste aplicativo?
O cliente deseja que testes baseados em função sejam realizados neste aplicativo?
O cliente deseja que sejam realizadas verificações credenciadas de aplicativos da Web?
Teste de penetração de rede sem fio
Quantas redes sem fio existem?
É usada uma rede sem fio para convidados? Se for assim:
A rede convidada requer autenticação?
Que tipo de criptografia é usada nas redes sem fio?
Qual é a metragem quadrada de cobertura?
Será necessária a enumeração de dispositivos não autorizados?
A equipe avaliará ataques sem fio contra clientes?
Aproximadamente quantos clientes usarão a rede sem fio?
Teste de penetração física
Quantos locais estão sendo avaliados?
Este local físico é uma instalação compartilhada? Se for assim:
Quantos andares estão no escopo?
Quais andares estão no escopo?
Há algum guarda de segurança que precisará ser contornado? Se for assim:
Os seguranças são contratados por terceiros?
Eles estão armados?
Eles estão autorizados a usar a força?
Quantas entradas existem no edifício?
É permitido o uso de gazuas ou chaves de colisão? (considere também as leis locais)
O objetivo deste teste é verificar a conformidade com as políticas e procedimentos
existentes ou realizar uma auditoria?
Qual é a metragem quadrada da área em escopo?
Todas as medidas de segurança física estão documentadas?
Estão sendo usadas câmeras de vídeo?
As câmeras são de propriedade do cliente? Se for assim:
A equipe deve tentar obter acesso ao local onde os dados da câmera de vídeo estão
armazenados?
Existe um sistema de alarme armado sendo usado? Se for assim:
O alarme é um alarme silencioso?
O alarme é acionado por movimento?
O alarme é acionado pela abertura de portas e janelas?
Engenharia social
O cliente tem uma lista de endereços de e-mail contra os quais gostaria que fosse
realizado um ataque de Engenharia Social?
O cliente tem uma lista de números de telefone contra os quais gostaria que fosse
A Engenharia Social é aprovada para fins de obtenção de acesso físico não
autorizado? Se for assim:
Quantas pessoas serão alvo?
Deve-se observar que, como parte dos diferentes níveis de testes, as perguntas para
gerentes de unidades de negócios, administradores de sistemas e pessoal de suporte
técnico podem não ser obrigatórias. Porém, caso essas perguntas sejam necessárias,
alguns exemplos de perguntas podem ser encontrados abaixo.
Perguntas para gerentes de unidades de negócios
O gerente está ciente de que um teste está para ser realizado?
Qual é o principal dado que criaria o maior risco para a organização se fosse exposto,
corrompido ou excluído?
Existem procedimentos de teste e validação para verificar se os aplicativos de negócios
estão funcionando corretamente?
Os testadores terão acesso aos procedimentos de teste de Garantia de Qualidade desde o
início do desenvolvimento do aplicativo?
Os procedimentos de recuperação de desastres estão em vigor para os dados do
aplicativo?
Perguntas para administradores de sistemas
Existem sistemas que possam ser caracterizados como frágeis? (sistemas com tendência
a travar, sistemas operacionais mais antigos ou que não foram corrigidos)
Existem sistemas na rede que o cliente não possui e que podem exigir aprovação
adicional para teste?
Os procedimentos de gerenciamento de mudanças estão em vigor?
Qual é o tempo médio para reparar interrupções nos sistemas?
Existe algum software de monitoramento do sistema?
Quais são os servidores e aplicativos mais críticos?
Os backups são testados regularmente?
Quando foi a última vez que os backups foram restaurados?
Oportunista
O aumento do escopo é uma das maneiras mais eficientes de tirar do mercado uma
empresa de testes de penetração. A questão é que muitas empresas e gestores têm pouca
ou nenhuma ideia de como identificá-lo ou de como reagir quando isso acontece.
Há algumas coisas a serem lembradas ao lutar contra o aumento do escopo. Em
primeiro lugar, se um cliente estiver satisfeito com o trabalho realizado num
determinado trabalho, é muito comum que solicite trabalho adicional. Considere isso
um elogio e não hesite em pedir financiamento adicional para compensar o tempo extra
gasto. Se um cliente se recusar a pagar pelo trabalho extra, quase nunca vale a pena
continuar fazendo esse trabalho.
O segundo ponto é ainda mais crítico. Ao lidar com clientes existentes, tome cuidado
para manter os preços mais baixos. Tirar vantagem de uma boa situação através da
manipulação de preços é uma maneira segura de afastar novos negócios. Leve em
consideração que os preços podem ser reduzidos, uma vez que a empresa evitou os
custos de aquisição do cliente, como o processo formal de RFP e a busca pelo próprio
cliente. Além disso, a melhor fonte para trabalhos futuros são os clientes
existentes. Trate-os bem e eles retornarão.
Especifique as datas de início e término
Outro componente-chave para derrotar o aumento do escopo é declarar explicitamente
as datas de início e término. Isso permite que o projeto tenha um fim definido. Uma das
áreas mais comuns em que ocorre aumento de escopo é durante o reteste. Testar
novamente sempre parece uma boa ideia quando se busca um contrato. Isso mostra que
a empresa é atenciosa e diligente, tentando garantir que o cliente esteja o mais seguro
possível. O problema começa quando se esquece que a obra não é paga até ser
concluída. Isso inclui novo teste.
Para mitigar este risco, adicione uma declaração simples ao contrato que mencione que
todos os retestes devem ser feitos dentro de um determinado prazo após a entrega do
relatório final. Torna-se então responsabilidade dos testadores liderar o esforço de
reteste. Caso o cliente solicite uma prorrogação, permita-a sempre com a condição de
que o pagamento seja efetuado na data originalmente especificada. Finalmente, e mais
importante, realize um novo teste de qualidade. Lembre-se de que a melhor fonte para
trabalhos futuros é sua base de clientes existente.
Especifique intervalos de IP e domínios
Antes de iniciar um teste de penetração, todos os alvos devem ser identificados. Essas
metas devem ser obtidas do cliente durante a fase inicial do questionário. Os alvos
podem ser fornecidos na forma de endereços IP específicos, intervalos de rede ou nomes
de domínio pelo cliente. Em alguns casos, o único alvo que o cliente fornece é o nome
da organização e espera que os testadores sejam capazes de identificar o restante por
conta própria. É importante definir se sistemas como firewalls e IDS/IPS ou
equipamentos de rede que estão entre o testador e o alvo final também fazem parte do
escopo. Elementos adicionais, como provedores upstream e outros provedores
terceirizados, devem ser identificados e definidos, estejam ou não no escopo.
Validar intervalos
É imperativo que, antes de começar a atacar os alvos, você valide se eles são de fato
propriedade do cliente contra o qual você está realizando o teste. Pense nas
consequências legais que você pode enfrentar se começar a atacar uma máquina e
penetrá-la com sucesso, apenas para descobrir mais tarde que a máquina na verdade
pertence a outra organização (como um hospital ou agência governamental).
Lidando com Terceiros
Há uma série de situações em que um compromisso incluirá o teste de um serviço ou
aplicativo hospedado por terceiros. Isso se tornou mais prevalente nos últimos anos, à
medida que os serviços “em nuvem” se tornaram mais populares. A coisa mais
importante a lembrar é que, embora a permissão possa ter sido concedida pelo cliente,
ele não fala em nome de seus fornecedores terceirizados. Portanto, a permissão também
deve ser obtida deles para testar os sistemas hospedados. A falta de obtenção das
devidas permissões traz consigo, como sempre, a possibilidade de violação da lei, o que
pode causar inúmeras dores de cabeça.
Serviços na nuvem
O maior problema com o teste do serviço em nuvem é que há dados de várias
organizações diferentes armazenados em um meio físico. Freqüentemente, a segurança
entre esses diferentes domínios de dados é muito frouxa. O provedor de serviços em
nuvem precisa ser alertado sobre o teste e precisa reconhecer que o teste está ocorrendo
e conceder à organização de teste permissão para testar. Além disso, é necessário que
haja um contato de segurança direto dentro do provedor de serviços de nuvem que possa
ser contatado caso seja descoberta uma vulnerabilidade de segurança que possa afetar
outros clientes da nuvem. Alguns provedores de nuvem têm procedimentos específicos
a serem seguidos pelos testadores de penetração e podem exigir formulários de
solicitação, agendamento ou permissão explícita deles antes que o teste possa começar.
ISP
Verifique os termos de serviço do ISP com o cliente. Em muitas situações comerciais, o
ISP terá disposições específicas para testes. Revise estes termos cuidadosamente antes
de lançar um ataque. Existem situações em que os ISPs evitam e bloqueiam
determinado tráfego considerado malicioso. O cliente pode aprovar este risco, mas deve
sempre ser comunicado claramente antes de começar. Hospedagem na Web Tal como
acontece com todos os outros terceiros, o escopo e o momento do teste precisam ser
claramente comunicados ao provedor de hospedagem na web. Além disso, ao se
comunicar com o cliente, certifique-se de articular claramente que o teste será apenas
em busca de vulnerabilidades na web. O teste não revelará vulnerabilidades na
infraestrutura subjacente que ainda possam fornecer um caminho para comprometer o
aplicativo.
MSSPs
Os provedores de serviços de segurança gerenciados também podem precisar ser
notificados sobre testes. Especificamente, eles precisarão ser notificados quando os
sistemas e serviços de sua propriedade forem testados. No entanto, existem
circunstâncias em que o MSSP não seria notificado. Se a determinação do tempo de
resposta real do MSSP fizer parte do teste, certamente não é do interesse da integridade
do teste que o MSSP seja notificado. Como regra geral, sempre que um dispositivo ou
serviço de propriedade explícita do MSSP estiver sendo testado, ele precisará ser
notificado.
Países onde os servidores estão hospedados
Também é do interesse do testador verificar os países onde os servidores estão
hospedados. Depois de validar o país, revise as leis do país específico antes de iniciar os
testes. Não se deve presumir que a equipe jurídica do escritório fornecerá uma sinopse
completa das leis locais para os testadores. Também não se deve presumir que a
empresa assumirá responsabilidade legal por quaisquer leis violadas pelos seus
testadores. É responsabilidade de cada testador verificar as leis de cada região em que
está testando antes de começar o teste, porque será o testador quem terá que responder
por quaisquer transgressões.
Definir pretextos aceitáveis de engenharia social
Muitas organizações desejarão que sua postura de segurança seja testada de forma
alinhada aos ataques atuais. Os ataques de engenharia social e de spear-phishing são
atualmente amplamente utilizados por muitos invasores. Embora a maioria dos ataques
bem-sucedidos utilize pretextos como sexo, drogas e rock and roll (pornografia, Viagra
e iPods gratuitos, respectivamente), alguns desses pretextos podem não ser aceitáveis
num ambiente corporativo. Certifique-se de que quaisquer pretextos escolhidos para o
teste sejam aprovados por escrito antes do início do teste.
Teste DoS
Os testes de estresse ou de negação de serviço devem ser discutidos antes do início do
trabalho. Pode ser um tópico com o qual muitas organizações se sentem desconfortáveis
devido à natureza potencialmente prejudicial dos testes. Se uma organização estiver
preocupada apenas com a confidencialidade ou integridade dos seus dados, os testes de
esforço podem não ser necessários; no entanto, se a organização também estiver
preocupada com a disponibilidade dos seus serviços, então o teste de esforço deverá ser
realizado num ambiente de não produção que seja idêntico ao ambiente de produção.
Termos de pagamento
Outro aspecto da preparação para um teste que muitos testadores esquecem
completamente é como devem ser pagos. Assim como as datas dos contratos, deve
haver datas e prazos específicos para pagamentos. Não é incomum que organizações
maiores atrasem o pagamento o máximo possível. Abaixo estão alguns métodos de
pagamento comuns. Estes são simplesmente exemplos. Definitivamente, é recomendado
que cada organização crie e ajuste sua própria estrutura de preços para atender mais
adequadamente às necessidades de seus clientes e delas próprias. O importante é que
algum tipo de estrutura esteja implementada antes do início dos testes.
Líquido 30
O valor total é devido no prazo de 30 dias após a entrega do relatório final. Isso
geralmente está associado a uma multa percentual mensal por falta de pagamento. Pode
ser qualquer número de dias que você deseja conceder aos seus clientes (ou seja, 45 ou
60).
Meio adiantado
Não é incomum exigir antecipadamente metade do valor total da conta antes do início
dos testes. Isso é muito comum em compromissos de longo prazo.
Recorrente
Um cronograma de pagamento recorrente é mais comumente usado para compromissos
de longo prazo. Por exemplo, alguns compromissos podem durar até um ou dois
anos. Não é incomum que o cliente pague em parcelas regulares ao longo do ano.
Metas
Todo teste de penetração deve ser orientado a objetivos. Isto quer dizer que o objetivo
do teste é identificar vulnerabilidades específicas que levam ao comprometimento dos
objetivos de negócio ou missão do cliente. Não se trata de encontrar sistemas não
corrigidos. Trata-se de identificar riscos que impactarão negativamente a organização.
Primário
O objetivo principal de um teste não deve ser determinado pela conformidade. Existem
diversas justificativas para esse raciocínio. Primeiro, conformidade não é igual a
segurança. Embora deva ser entendido que muitas organizações são submetidas a testes
devido à conformidade, esse não deve ser o objetivo principal do teste. Por exemplo,
uma empresa pode ser contratada para realizar um teste de penetração como parte dos
requisitos do PCI-DSS.
Não faltam empresas que processam informações de cartão de crédito. Contudo, as
características que tornam a organização-alvo única e viável num mercado competitivo
terão o maior impacto se forem comprometidas. O comprometimento dos sistemas de
cartão de crédito seria certamente um problema sério, mas o vazamento dos números
dos cartões de crédito, juntamente com todos os dados associados dos clientes, seria
catastrófico.
Pre-engagement
Jump to navigationJump to search
Contents
1Overview
2Introduction to Scope
3Metrics for Time Estimation
4Scoping Meeting
5Additional Support Based on Hourly Rate
6Questionnaires
7General Questions
7.1Network Penetration Test
7.2Web Application Penetration Test
7.3Wireless Network Penetration Test
7.4Physical Penetration Test
7.5Social Engineering
7.6Questions for Business Unit Managers
7.7Questions for Systems Administrators
8Scope Creep
9Specify Start and End Dates
10Specify IP Ranges and Domains
10.1Validate Ranges
11Dealing with Third Parties
11.1Cloud Services
11.2ISP
11.3MSSPs
11.4Countries Where Servers are Hosted
12Define Acceptable Social Engineering Pretexts
13DoS Testing
14Payment Terms
14.1Net 30
14.2Half Upfront
14.3Recurring
15Goals
15.1Primary
15.2Secondary
15.3Business Analysis
16Establish Lines of Communication
17Emergency Contact Information
17.1Incident Reporting Process
17.2Incident Definition
17.3Status Report Frequency
17.4PGP and Other Alternatives
18Rules of Engagement
18.1Timeline
18.2Locations
18.3Evidence Handling
18.4Regular Status Meetings
18.5Time of the Day to Test
18.6Dealing with Shunning
18.7Permission to Test
18.8Legal Considerations
19Capabilities and Technology in Place
Overview
The aim of this section of the PTES is to present and explain the tools and techniques
available which aid in a successful pre-engagement step of a penetration test. The
information within this section is the result of the many years of combined experience
of some of the most successful penetration testers in the world.
If you are a customer looking for penetration test we strongly recommend going to the
General Questions section of this document. It covers the major questions that should be
answered before a test begins. Remember, a penetration test should not be
confrontational. It should not be an activity to see if the tester can "hack" you. It should
be about identifying the business risk associated with and attack.
To get maximum value, make sure the questions in this document are covered. Further,
as the Scoping activity progresses, a good testing firm will start to ask additional
questions tailored to your organization.
Introduction to Scope
Defining scope is arguably one of the most important components of a penetration test,
yet it is also one of the most overlooked. While many volumes have been written about
the different tools and techniques which can be utilized to gain access to a network, very
little has been written on the topic which precedes the penetration: preparation.
Neglecting to properly complete pre-engagement activities has the potential to open the
penetration tester (or his firm) to a number of headaches including scope creep,
unsatisfied customers, and even legal troubles. The scope of a project specifically
defines what is to be tested. How each aspect of the test will be conducted will be
covered in the Rules of Engagement section.
One key component of scoping an engagement is outlining how the testers should spend
their time. As an example, a customer requests that one hundred IP addresses be tested
for the price of $100,000. This means that the customer is offering $1,000 per IP address
tested. However, this cost structure only remains effective at that volume. A common
trap some testers fall into is maintaining linear costs throughout the testing process. If
the customer had only asked for one business-critical application to be tested at the
same pricing structure ($1,000), while the tester will still be only attacking a single IP,
the volume of work has increased dramatically. It is important to vary costs based on
work done. Otherwise a firm can easily find themselves undercharging for their
services, which motivates them to do a less than complete job.
Despite having a solid pricing structure, the process is not all black and white. It is not
uncommon for a client to be completely unaware of exactly what it is they need tested.
It is also possible the client will not know how to communicate effectively what they’re
expecting from the test. It is important in the Pre-Engagement phase that the tester is
able to serve as a guide through what may be uncharted territory for a customer. The
tester must understand the difference between a test which focuses on a single
application with severe intensity and a test where the client provides a wide range of IP
addresses to test and the goal is to simply find a way in.
Metrics for Time Estimation
Time estimations are directly tied to the experience of a tester in a certain area. If a
tester has significant experience in a certain test, he will likely innately be able to
determine how long a test will take. If the tester has less experience in the area, re-
reading emails and scan logs from previous similar tests the firm has done is a great way
to estimate the time requirement for the current engagement. Once the time to test is
determined, it is a prudent practice to add 20% to the time.
The extra 20% on the back end of the time value is called padding. Outside of
consultant circles, this is also referred to as consultant overhead. The padding is an
absolute necessity for any test. It provides a cushion should any interruptions occur in
the testing. There are many events which commonly occur and hinder the testing
process. For example, a network segment may go down, or a significant vulnerability
may be found which requires many meetings with many levels of management to
address. Both of these events are time consuming and would significantly impact the
original time estimate if the padding was not in place.
What happens if the 20% padding ends up not being necessary? Billing the client for
time not worked would be extremely unethical, so it is up to the testers to provide
additional value that may not normally have been provided if the engagement time limit
had been hit. Examples include walking the company security team through the steps
taken to exploit the vulnerability, provide an executive summary if it was not part of the
original deliverable list, or spend some additional time trying to crack a vulnerability
that was elusive during the initial testing.
Another component of the metrics of time and testing is that every project needs to have
a definitive drop dead date. All good projects have a well-defined beginning and end.
You will need to have a signed statement of work specifying the work and the hours
required if you’ve reached the specific date the testing is to end, or if any additional
testing or work is requested of you after that date. Some testers have a difficult time
doing this because they feel they are being too much of a pain when it comes to cost and
hours. However, it has been the experience of the author that if you provide exceptional
value for the main test the customer will not balk at paying you for additional work.
Scoping Meeting
In many cases the scoping meeting will occur after the contract has been signed.
Situations do occur wherein many of the scope-related topics can be discussed before
contract signing, but they are few and far between. For those situations it is
recommended that a non-disclosure agreement be signed before any in-depth scoping
discussions occur.
The goal of the scoping meeting is to discuss what will be tested. Rules of engagement
and costs will not be covered in this meeting. Each of these subjects should be handled
in meetings where each piece is the focus of that meeting. This is done because
discussions can easily become confused and muddled if focus is not explicitly stated. It
is important to act as moderator and keep the discussions on-topic, preventing tangents
and declaring certain topics more suited for off-line discussion when necessary.
Now that a Rough Order of Magnitude (ROM) value has been established for the
project it is time to have a meeting with the customer to validate assumptions. First, it
needs to be established explicitly what IP ranges are in scope for the engagement. It is
not uncommon for a client to be resistant and assume that it is the prerogative of the
tester to identify their network and attack it, to make the test as realistic as possible.
This would indeed be an ideal circumstance, however, possible legal ramifications must
be considered above all else. Because of this, it is the responsibility of the tester to
convey to a client these concerns and to impart upon them the importance of implicit
scoping. For example, in the meeting, it should be verified that the customer owns all of
the target environments including: the DNS server, the email server, the actual hardware
their web servers run on and their firewall/IDS/IPS solution. There are a number of
companies which will outsource the management of these devices to third parties.
Additionally, the countries, provinces, and states in which the target environments
operate in must be identified. Laws vary from region to region and the testing may very
well be impacted by these laws. For instance, countries belonging to the European
Union are well known to have very stringent laws surrounding the privacy of
individuals, which can significantly change the manner in which a social engineering
engagement would be executed.
Additional Support Based on Hourly Rate
Anything that is not explicitly covered within the scope of the engagement should be
handled very carefully. The first reason for this is scope creep. As the scope expands,
resources are consumed, cutting into the profits for the tester and may even create
confusion and anger on the part of the customer. There is another issue that many testers
do not think of when taking on additional work on an ad-hoc basis: legal ramifications.
Many ad-hoc requests are not properly documented so it can be difficult to determine
who said what in the event of a dispute or legal action. Further, the contract is a legal
document specifying the work that is to be done. It should be tightly tied to the
permission to test memo.
Any requests outside of the original scope should be documented in the form of a
statement of work that clearly identifies the work to be done. We also recommend that it
be clearly stated in the contract that additional work will be done for a flat fee per hour
and explicitly state that additional work can not be completed until a signed and
counter-signed SOW is in place.
Questionnaires
Durante as comunicações iniciais com o cliente, existem várias perguntas que o cliente
terá que responder para que o escopo do trabalho possa ser adequadamente
estimado. Essas perguntas foram elaboradas para fornecer uma melhor compreensão do
que o cliente busca obter com o teste de penetração, por que o cliente deseja realizar um
teste de penetração em seu ambiente e se deseja ou não que determinados tipos de testes
sejam realizados durante o teste de penetração. A seguir estão exemplos de perguntas
que podem ser feitas durante esta fase.
Questões gerais
Teste de penetração de rede
Por que o cliente está realizando o teste de penetração em seu ambiente?
O teste de penetração é necessário para um requisito de conformidade específico?
Quando o cliente deseja que as partes ativas (varredura, enumeração, exploração, etc...)
do teste de penetração sejam realizadas?
Durante o horário comercial?
Depois do horário comercial?
Nos finais de semana?
Quantos endereços IP totais estão sendo testados?
Quantos endereços IP internos, se aplicável?
Quantos endereços IP externos, se aplicável?
Há algum dispositivo instalado que possa afetar os resultados de um teste de penetração,
como firewall, sistema de detecção/prevenção de invasões, firewall de aplicativos da
Web ou balanceador de carga?
Caso um sistema seja invadido, como a equipe de testes deve proceder?
Realizar uma avaliação de vulnerabilidade local na máquina comprometida?
Tentativa de obter os privilégios mais altos (root em máquinas Unix, SYSTEM ou
Administrador em máquinas Windows) na máquina comprometida?
Executar ataques de senha nulos, mínimos, de dicionário ou exaustivos contra hashes de
senha locais obtidos (por exemplo, /etc/shadow em máquinas Unix)?
Teste de penetração de aplicativos da Web
Quantas aplicações web estão sendo avaliadas?
Quantos sistemas de login estão sendo avaliados?
Quantas páginas estáticas estão sendo avaliadas? (aproximado)
Quantas páginas dinâmicas estão sendo avaliadas? (aproximado)
O código-fonte estará prontamente disponível?
Haverá algum tipo de documentação?
Se sim, que tipo de documentação?
A análise estática será realizada nesta aplicação?
O cliente deseja que a difusão seja realizada neste aplicativo?
O cliente deseja que testes baseados em função sejam realizados neste aplicativo?
O cliente deseja que sejam realizadas verificações credenciadas de aplicativos da Web?
Teste de penetração de rede sem fio
Quantas redes sem fio existem?
É usada uma rede sem fio para convidados? Se for assim:
A rede convidada requer autenticação?
Que tipo de criptografia é usada nas redes sem fio?
Qual é a metragem quadrada de cobertura?
Será necessária a enumeração de dispositivos não autorizados?
A equipe avaliará ataques sem fio contra clientes?
Aproximadamente quantos clientes usarão a rede sem fio?
Teste de penetração física
Quantos locais estão sendo avaliados?
Este local físico é uma instalação compartilhada? Se for assim:
Quantos andares estão no escopo?
Quais andares estão no escopo?
Há algum guarda de segurança que precisará ser contornado? Se for assim:
Os seguranças são contratados por terceiros?
Eles estão armados?
Eles estão autorizados a usar a força?
Quantas entradas existem no edifício?
É permitido o uso de gazuas ou chaves de colisão? (considere também as leis locais)
O objetivo deste teste é verificar a conformidade com as políticas e procedimentos
existentes ou realizar uma auditoria?
Qual é a metragem quadrada da área em escopo?
Todas as medidas de segurança física estão documentadas?
Estão sendo usadas câmeras de vídeo?
As câmeras são de propriedade do cliente? Se for assim:
A equipe deve tentar obter acesso ao local onde os dados da câmera de vídeo estão
armazenados?
Existe um sistema de alarme armado sendo usado? Se for assim:
O alarme é um alarme silencioso?
O alarme é acionado por movimento?
O alarme é acionado pela abertura de portas e janelas?
Engenharia social
O cliente tem uma lista de endereços de e-mail contra os quais gostaria que fosse
O cliente tem uma lista de números de telefone contra os quais gostaria que fosse
A Engenharia Social é aprovada para fins de obtenção de acesso físico não
autorizado? Se for assim:
Quantas pessoas serão alvo?
Deve-se observar que, como parte dos diferentes níveis de testes, as perguntas para
gerentes de unidades de negócios, administradores de sistemas e pessoal de suporte
técnico podem não ser obrigatórias. Porém, caso essas perguntas sejam necessárias,
alguns exemplos de perguntas podem ser encontrados abaixo.
Perguntas para gerentes de unidades de negócios
O gerente está ciente de que um teste está para ser realizado?
Qual é o principal dado que criaria o maior risco para a organização se fosse exposto,
corrompido ou excluído?
Existem procedimentos de teste e validação para verificar se os aplicativos de negócios
estão funcionando corretamente?
Os testadores terão acesso aos procedimentos de teste de Garantia de Qualidade desde o
início do desenvolvimento do aplicativo?
Os procedimentos de recuperação de desastres estão em vigor para os dados do
aplicativo?
Perguntas para administradores de sistemas
Existem sistemas que possam ser caracterizados como frágeis? (sistemas com tendência
a travar, sistemas operacionais mais antigos ou que não foram corrigidos)
Existem sistemas na rede que o cliente não possui e que podem exigir aprovação
adicional para teste?
Os procedimentos de gerenciamento de mudanças estão em vigor?
Qual é o tempo médio para reparar interrupções nos sistemas?
Existe algum software de monitoramento do sistema?
Quais são os servidores e aplicativos mais críticos?
Os backups são testados regularmente?
Quando foi a última vez que os backups foram restaurados?
Oportunista
O aumento do escopo é uma das maneiras mais eficientes de tirar do mercado uma
empresa de testes de penetração. A questão é que muitas empresas e gestores têm pouca
ou nenhuma ideia de como identificá-lo ou de como reagir quando isso acontece.
Há algumas coisas a serem lembradas ao lutar contra o aumento do escopo. Em
primeiro lugar, se um cliente estiver satisfeito com o trabalho realizado num
determinado trabalho, é muito comum que solicite trabalho adicional. Considere isso
um elogio e não hesite em pedir financiamento adicional para compensar o tempo extra
gasto. Se um cliente se recusar a pagar pelo trabalho extra, quase nunca vale a pena
continuar fazendo esse trabalho.
O segundo ponto é ainda mais crítico. Ao lidar com clientes existentes, tome cuidado
para manter os preços mais baixos. Tirar vantagem de uma boa situação através da
manipulação de preços é uma maneira segura de afastar novos negócios. Leve em
consideração que os preços podem ser reduzidos, uma vez que a empresa evitou os
custos de aquisição do cliente, como o processo formal de RFP e a busca pelo próprio
cliente. Além disso, a melhor fonte para trabalhos futuros são os clientes
existentes. Trate-os bem e eles retornarão.
Especifique as datas de início e término
Outro componente-chave para derrotar o aumento do escopo é declarar explicitamente
as datas de início e término. Isso permite que o projeto tenha um fim definido. Uma das
áreas mais comuns em que ocorre aumento de escopo é durante o reteste. Testar
novamente sempre parece uma boa ideia quando se busca um contrato. Isso mostra que
a empresa é atenciosa e diligente, tentando garantir que o cliente esteja o mais seguro
possível. O problema começa quando se esquece que a obra não é paga até ser
concluída. Isso inclui novo teste.
Para mitigar este risco, adicione uma declaração simples ao contrato que mencione que
todos os retestes devem ser feitos dentro de um determinado prazo após a entrega do
relatório final. Torna-se então responsabilidade dos testadores liderar o esforço de
reteste. Caso o cliente solicite uma prorrogação, permita-a sempre com a condição de
que o pagamento seja efetuado na data originalmente especificada. Finalmente, e mais
importante, realize um novo teste de qualidade. Lembre-se de que a melhor fonte para
trabalhos futuros é sua base de clientes existente.
Especifique intervalos de IP e domínios
Antes de iniciar um teste de penetração, todos os alvos devem ser identificados. Essas
metas devem ser obtidas do cliente durante a fase inicial do questionário. Os alvos
podem ser fornecidos na forma de endereços IP específicos, intervalos de rede ou nomes
de domínio pelo cliente. Em alguns casos, o único alvo que o cliente fornece é o nome
da organização e espera que os testadores sejam capazes de identificar o restante por
conta própria. É importante definir se sistemas como firewalls e IDS/IPS ou
equipamentos de rede que estão entre o testador e o alvo final também fazem parte do
escopo. Elementos adicionais, como provedores upstream e outros provedores
terceirizados, devem ser identificados e definidos, estejam ou não no escopo.
Validar intervalos
É imperativo que, antes de começar a atacar os alvos, você valide se eles são de fato
propriedade do cliente contra o qual você está realizando o teste. Pense nas
consequências legais que você pode enfrentar se começar a atacar uma máquina e
penetrá-la com sucesso, apenas para descobrir mais tarde que a máquina na verdade
pertence a outra organização (como um hospital ou agência governamental).
Lidando com Terceiros
Há uma série de situações em que um compromisso incluirá o teste de um serviço ou
aplicativo hospedado por terceiros. Isso se tornou mais prevalente nos últimos anos, à
medida que os serviços “em nuvem” se tornaram mais populares. A coisa mais
importante a lembrar é que, embora a permissão possa ter sido concedida pelo cliente,
ele não fala em nome de seus fornecedores terceirizados. Portanto, a permissão também
deve ser obtida deles para testar os sistemas hospedados. A falta de obtenção das
devidas permissões traz consigo, como sempre, a possibilidade de violação da lei, o que
pode causar inúmeras dores de cabeça.
Serviços na nuvem
O maior problema com o teste do serviço em nuvem é que há dados de várias
organizações diferentes armazenados em um meio físico. Freqüentemente, a segurança
entre esses diferentes domínios de dados é muito frouxa. O provedor de serviços em
nuvem precisa ser alertado sobre o teste e precisa reconhecer que o teste está ocorrendo
e conceder à organização de teste permissão para testar. Além disso, é necessário que
haja um contato de segurança direto dentro do provedor de serviços de nuvem que possa
ser contatado caso seja descoberta uma vulnerabilidade de segurança que possa afetar
outros clientes da nuvem. Alguns provedores de nuvem têm procedimentos específicos
a serem seguidos pelos testadores de penetração e podem exigir formulários de
solicitação, agendamento ou permissão explícita deles antes que o teste possa começar.
ISP
Verifique os termos de serviço do ISP com o cliente. Em muitas situações comerciais, o
ISP terá disposições específicas para testes. Revise estes termos cuidadosamente antes
de lançar um ataque. Existem situações em que os ISPs evitam e bloqueiam
determinado tráfego considerado malicioso. O cliente pode aprovar este risco, mas deve
sempre ser comunicado claramente antes de começar. Hospedagem na Web Tal como
acontece com todos os outros terceiros, o escopo e o momento do teste precisam ser
claramente comunicados ao provedor de hospedagem na web. Além disso, ao se
comunicar com o cliente, certifique-se de articular claramente que o teste será apenas
em busca de vulnerabilidades na web. O teste não revelará vulnerabilidades na
infraestrutura subjacente que ainda possam fornecer um caminho para comprometer o
aplicativo.
MSSPs
Os provedores de serviços de segurança gerenciados também podem precisar ser
notificados sobre testes. Especificamente, eles precisarão ser notificados quando os
sistemas e serviços de sua propriedade forem testados. No entanto, existem
circunstâncias em que o MSSP não seria notificado. Se a determinação do tempo de
resposta real do MSSP fizer parte do teste, certamente não é do interesse da integridade
do teste que o MSSP seja notificado. Como regra geral, sempre que um dispositivo ou
serviço de propriedade explícita do MSSP estiver sendo testado, ele precisará ser
notificado.
Países onde os servidores estão hospedados
Também é do interesse do testador verificar os países onde os servidores estão
hospedados. Depois de validar o país, revise as leis do país específico antes de iniciar os
testes. Não se deve presumir que a equipe jurídica do escritório fornecerá uma sinopse
completa das leis locais para os testadores. Também não se deve presumir que a
empresa assumirá responsabilidade legal por quaisquer leis violadas pelos seus
testadores. É responsabilidade de cada testador verificar as leis de cada região em que
está testando antes de começar o teste, porque será o testador quem terá que responder
por quaisquer transgressões.
Definir pretextos aceitáveis de engenharia social
Muitas organizações desejarão que sua postura de segurança seja testada de forma
alinhada aos ataques atuais. Os ataques de engenharia social e de spear-phishing são
atualmente amplamente utilizados por muitos invasores. Embora a maioria dos ataques
bem-sucedidos utilize pretextos como sexo, drogas e rock and roll (pornografia, Viagra
e iPods gratuitos, respectivamente), alguns desses pretextos podem não ser aceitáveis
num ambiente corporativo. Certifique-se de que quaisquer pretextos escolhidos para o
teste sejam aprovados por escrito antes do início do teste.
Teste DoS
Os testes de estresse ou de negação de serviço devem ser discutidos antes do início do
trabalho. Pode ser um tópico com o qual muitas organizações se sentem desconfortáveis
devido à natureza potencialmente prejudicial dos testes. Se uma organização estiver
preocupada apenas com a confidencialidade ou integridade dos seus dados, os testes de
esforço podem não ser necessários; no entanto, se a organização também estiver
preocupada com a disponibilidade dos seus serviços, então o teste de esforço deverá ser
realizado num ambiente de não produção que seja idêntico ao ambiente de produção.
Termos de pagamento
Outro aspecto da preparação para um teste que muitos testadores esquecem
completamente é como devem ser pagos. Assim como as datas dos contratos, deve
haver datas e prazos específicos para pagamentos. Não é incomum que organizações
maiores atrasem o pagamento o máximo possível. Abaixo estão alguns métodos de
pagamento comuns. Estes são simplesmente exemplos. Definitivamente, é recomendado
que cada organização crie e ajuste sua própria estrutura de preços para atender mais
adequadamente às necessidades de seus clientes e delas próprias. O importante é que
algum tipo de estrutura esteja implementada antes do início dos testes.
Líquido 30
O valor total é devido no prazo de 30 dias após a entrega do relatório final. Isso
geralmente está associado a uma multa percentual mensal por falta de pagamento. Pode
ser qualquer número de dias que você deseja conceder aos seus clientes (ou seja, 45 ou
60).
Meio adiantado
Não é incomum exigir antecipadamente metade do valor total da conta antes do início
dos testes. Isso é muito comum em compromissos de longo prazo.
Recorrente
Um cronograma de pagamento recorrente é mais comumente usado para compromissos
de longo prazo. Por exemplo, alguns compromissos podem durar até um ou dois
anos. Não é incomum que o cliente pague em parcelas regulares ao longo do ano.
Metas
Todo teste de penetração deve ser orientado a objetivos. Isto quer dizer que o objetivo
do teste é identificar vulnerabilidades específicas que levam ao comprometimento dos
objetivos de negócio ou missão do cliente. Não se trata de encontrar sistemas não
corrigidos. Trata-se de identificar riscos que impactarão negativamente a organização.
Primário
O objetivo principal de um teste não deve ser determinado pela conformidade. Existem
diversas justificativas para esse raciocínio. Primeiro, conformidade não é igual a
segurança. Embora deva ser entendido que muitas organizações são submetidas a testes
devido à conformidade, esse não deve ser o objetivo principal do teste. Por exemplo,
uma empresa pode ser contratada para realizar um teste de penetração como parte dos
requisitos do PCI-DSS.
Não faltam empresas que processam informações de cartão de crédito. Contudo, as
características que tornam a organização-alvo única e viável num mercado competitivo
terão o maior impacto se forem comprometidas. O comprometimento dos sistemas de
cartão de crédito seria certamente um problema sério, mas o vazamento dos números
dos cartões de crédito, juntamente com todos os dados associados dos clientes, seria
catastrófico.
Secundário
Os objetivos secundários estão diretamente relacionados ao compliance. Não é
incomum que os objetivos primários e secundários estejam intimamente
relacionados. Por exemplo, no exemplo do teste orientado por PCI-DSS, obter os
cartões de crédito é o objetivo secundário. Vincular essa violação de dados aos
motivadores de negócios ou missão da organização é o objetivo principal. Metas
secundárias significam algo para conformidade e/ou TI. Os objetivos primários chamam
a atenção da alta administração.
Análise de negócio
Antes de realizar um teste de penetração, é benéfico determinar o nível de maturidade
da postura de segurança do cliente. Há uma série de organizações que optam por saltar
diretamente para um teste de penetração, avaliando primeiro este nível de
maturidade. Para clientes com um programa de segurança muito imaturo, muitas vezes é
uma boa ideia realizar primeiro uma análise de vulnerabilidade.
Alguns testadores acreditam que há um estigma em torno do trabalho de Análise de
Vulnerabilidade (VA). Esses testadores esqueceram que o objetivo é identificar riscos na
organização-alvo, e não buscar o chamado estilo de vida “rockstar”. Se uma empresa
não estiver pronta para um teste de penetração completo, ela obterá muito mais valor
com um bom VA do que com um teste de penetração.
Estabeleça com antecedência com o cliente quais informações sobre os sistemas ele
fornecerá. Também pode ser útil pedir informações sobre vulnerabilidades que já estão
documentadas. Isso economizará tempo dos testadores e dinheiro do cliente, ao não
sobrepor as descobertas dos testes com problemas conhecidos. Da mesma forma, um
teste de caixa branca total ou parcial pode agregar mais valor ao cliente do que um teste
de caixa preta, se não for absolutamente exigido pela conformidade.
Estabeleça Linhas de Comunicação
Um dos aspectos mais importantes de qualquer teste de penetração é a comunicação
com o cliente. A frequência com que você interage com o cliente e a maneira como você
o aborda podem fazer uma grande diferença em seu sentimento de satisfação. Abaixo
está uma estrutura de comunicação que ajudará a fazer com que o cliente se sinta
confortável com as atividades de teste.
Informações para contato de emergência
Obviamente, ser capaz de entrar em contato com o cliente ou organização-alvo em caso
de emergência é vital. Podem surgir emergências e um ponto de contato deve ter sido
estabelecido para lidar com elas. Crie uma lista de contatos de emergência. Esta lista
deve incluir informações de contato de todas as partes envolvidas no escopo dos
testes. Uma vez criada, a lista de contatos de emergência deve ser compartilhada com
todos os presentes na lista. Tenha em mente que a organização alvo pode não ser o
cliente.
Reúna as seguintes informações sobre cada contato de emergência:
Nome completo
Título e responsabilidade operacional
Autorização para discutir detalhes das atividades de teste, se ainda não estiver
especificado
Duas formas de contato imediato 24 horas por dia, 7 dias por semana, como telefone
celular, pager ou telefone residencial, se possível
Uma forma segura de transferência de dados em massa, como SFTP ou e-mail
criptografado
Observação: o número de um grupo, como o suporte técnico ou o centro de operações,
pode substituir um contato de emergência, mas somente se houver atendimento 24 horas
por dia, 7 dias por semana. A natureza de cada teste de penetração influencia quem deve
estar na lista de contatos de emergência. Não apenas as informações de contato do
cliente e dos alvos precisarão ser disponibilizadas, mas eles também poderão precisar
entrar em contato com os testadores em caso de emergência. A lista deve incluir
preferencialmente as seguintes pessoas:
Todos os testadores de penetração no grupo de teste do engajamento
O gerente do grupo de teste
Dois contatos técnicos em cada organização alvo
Dois contatos técnicos no cliente
Uma gerência superior ou contato comercial no cliente
É possível que haja alguma sobreposição na lista acima. Por exemplo, a organização-
alvo pode ser o cliente, o gerente do grupo de teste também pode estar realizando o teste
de penetração ou o contato técnico de um cliente pode estar na alta
administração. Recomenda-se também definir uma única pessoa de contacto por parte
envolvida que o lidere e assuma a responsabilidade em seu nome.
Processo de Relatório de Incidentes
Discutir as atuais capacidades de resposta a incidentes da organização é importante
antes de um compromisso por vários motivos. Parte de um teste de penetração não
consiste apenas em testar a segurança que uma organização possui, mas também suas
capacidades de resposta a incidentes.
Se todo um trabalho puder ser concluído sem que as equipes de segurança interna do
alvo percebam, será identificada uma grande lacuna na postura de segurança. Também é
importante garantir que, antes do início dos testes, alguém na organização-alvo saiba
quando os testes estão sendo realizados, para que a equipe de resposta a incidentes não
comece a ligar para todos os membros da alta administração no meio da noite porque
pensaram que estavam sob ataque ou comprometidos.
Definição de Incidente
O Instituto Nacional de Padrões e Tecnologia (NIST) define um incidente da seguinte
forma: “uma violação ou ameaça iminente de violação de políticas de segurança de
computadores, políticas de uso aceitável ou práticas de segurança padrão”. (Guia de
Tratamento de Incidentes de Segurança de Computadores - Publicação Especial 800-61
Rev 1). Um incidente também pode ocorrer no nível físico, em que uma pessoa obtém
acesso físico não autorizado a uma área por qualquer meio. A organização alvo deve ter
diferentes categorias e níveis para diferentes tipos de incidentes.
Frequência do relatório de status
A frequência dos relatórios de status pode variar amplamente. Alguns fatores que
influenciam o cronograma de relatórios incluem a duração geral do teste, o escopo do
teste e a maturidade da segurança do alvo. Um cronograma eficaz permite que o cliente
se sinta engajado. Um cliente ignorado é um ex-cliente.
Uma vez definidos a frequência e o cronograma dos relatórios de status, eles deverão
ser cumpridos. Adiar ou atrasar um relatório de situação pode ser necessário, mas não
deve tornar-se crónico. O cliente pode ser solicitado a concordar com um novo
cronograma, se necessário. Ignorar completamente um relatório de status não é
profissional e deve ser evitado sempre que possível.
PGP e outras alternativas
A criptografia não é opcional. A comunicação com o cliente é uma parte absolutamente
necessária de qualquer trabalho de teste de penetração e, devido à natureza sensível do
trabalho, as comunicações de informações sensíveis devem ser criptografadas,
especialmente o relatório final. Antes do início dos testes, um meio de comunicação
seguro deve ser estabelecido com o cliente. Vários meios comuns de criptografia são os
seguintes:
PGP/GPG pode ser usado tanto para comunicação por e-mail quanto para criptografar o
relatório final (lembre-se de que as linhas de assunto são transmitidas em texto simples)
Uma caixa de correio segura hospedada na rede do cliente
Telefone
Reuniões presenciais
Para entregar o relatório final, você também pode armazenar o relatório em um arquivo
compactado criptografado AES, mas certifique-se de que seu utilitário de arquivamento
suporte criptografia AES usando CBC.
Pergunte também que tipos de informações podem ser colocadas por escrito e quais
devem ser comunicadas apenas verbalmente. Algumas organizações têm boas razões
para limitar as informações de segurança que lhes são transmitidas por escrito.
Regras de noivado
Embora o escopo defina o que será testado, as regras de engajamento definem como
esse teste ocorrerá. Esses são dois aspectos diferentes que precisam ser tratados de
forma independente um do outro.
Linha do tempo
Um cronograma claro deve ser estabelecido para o envolvimento. Embora o escopo
defina o início e o fim de um trabalho, as regras de trabalho definem tudo o que está
entre eles. Deve ser entendido que o cronograma mudará conforme o teste avança. No
entanto, ter um cronograma rígido não é o objetivo de criá-lo. Em vez disso, ter um
cronograma definido no início de um teste permitirá que todos os envolvidos
identifiquem mais claramente o trabalho que será realizado e as pessoas que serão
responsáveis por esse trabalho. Os gráficos GANTT e as estruturas analíticas do
trabalho são frequentemente usados para definir o trabalho e a quantidade de tempo que
cada parte específica do trabalho levará. Ver o cronograma dividido dessa maneira ajuda
os envolvidos a identificar onde os recursos precisam ser aplicados e ajuda o cliente a
identificar possíveis obstáculos que podem ser encontrados durante os testes.
Existem várias ferramentas gratuitas de gráfico GANTT disponíveis na Internet. Muitos
gestores se identificam intimamente com essas ferramentas. Por isso, são um excelente
meio de comunicação com a alta administração de uma organização-alvo.
Localizações
Outro parâmetro de qualquer compromisso que é importante estabelecer
antecipadamente com o cliente são os destinos para os quais os testadores precisarão
viajar durante o teste. Isto pode ser tão simples como identificar hotéis locais, ou
complexo como identificar as leis aplicáveis de um país alvo específico.
Não é incomum que uma organização opere em vários locais e regiões e alguns locais
selecionados precisem ser escolhidos para testes. Nessas situações, deve-se evitar viajar
para cada local do cliente; em vez disso, deve-se determinar se as conexões VPN aos
locais estão disponíveis para testes remotos. Divulgação de informações confidenciais
Embora um dos objetivos de um determinado compromisso possa ser obter acesso a
informações confidenciais, certas informações não devem ser realmente visualizadas ou
baixadas. Isso parece estranho para os testadores mais novos, no entanto, há uma série
de situações em que os testadores não deveriam ter os dados de destino em sua
posse. Por exemplo, Informações Pessoais de Saúde (PHI), de acordo com a Lei de
Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA), esses dados devem ser
protegidos. Em algumas situações, o sistema de destino pode não ter um firewall ou
antivírus (AV) protegendo-o. Nesse tipo de situação, os testadores que possuem toda e
qualquer informação de identificação pessoal (PII) devem ser absolutamente evitados.
Contudo, se os dados não puderem ser obtidos física ou virtualmente, como se pode
provar que os testadores obtiveram efetivamente acesso às informações? Este problema
foi resolvido de várias maneiras. Existem maneiras de provar que a porta do cofre foi
aberta sem retirar nenhum dinheiro. Por exemplo, uma captura de tela do esquema do
banco de dados e das permissões de arquivo pode ser feita, ou os próprios arquivos
podem ser exibidos sem abri-los para exibir o conteúdo, desde que nenhuma PII esteja
visível nos próprios nomes dos arquivos.
O quão cautelosos os testadores devem ser em um determinado trabalho é um parâmetro
que precisa ser discutido com o cliente, mas a empresa que realiza os testes deve sempre
ter certeza de se proteger no sentido jurídico, independentemente da opinião do
cliente. Independentemente da suposta exposição a dados confidenciais, todos os
modelos de relatório e máquinas de teste devem ser suficientemente limpos após cada
envolvimento. Como observação especial, se dados ilegais (ou seja, pornografia
infantil) forem descobertos pelos testadores, os responsáveis pela aplicação da lei
deverão ser notificados imediatamente, seguidos pelo cliente. Não siga orientação do
cliente.
Tratamento de evidências
Ao lidar com as evidências de um teste e os diferentes estágios do relatório, é
extremamente importante tomar extremo cuidado com os dados. Sempre use
criptografia e higienize sua máquina de teste entre os testes. Nunca distribua pendrives
com relatórios de testes em conferências de segurança. E faça o que fizer, não reutilize
um relatório de outro envolvimento do cliente como modelo! É muito pouco
profissional deixar referências a outra organização no seu documento.
Reuniões regulares de status
Durante todo o processo de teste, é fundamental realizar reuniões regulares com o
cliente, informando-o sobre o progresso geral do teste. Essas reuniões devem ser
realizadas diariamente e devem ser tão curtas quanto possível. As reuniões devem ser
limitadas a três conceitos: planos, progresso e problemas.
Os planos geralmente são discutidos para que os testes não sejam realizados durante
uma grande mudança não programada ou uma interrupção. O progresso é simplesmente
uma atualização para o cliente sobre o que foi concluído até agora. Os problemas
também devem ser discutidos nesta reunião, mas por uma questão de brevidade, as
conversas sobre soluções devem quase sempre ser realizadas off-line.
Hora do dia para testar
Certos clientes exigem que todos os testes sejam feitos fora do horário comercial. Isso
pode significar madrugadas para a maioria dos testadores. Os requisitos de horário do
dia devem ser bem estabelecidos com o cliente antes do início dos testes.
Lidando com a rejeição
Há momentos em que a rejeição é perfeitamente aceitável e há momentos em que pode
não se adequar ao espírito do teste. Por exemplo, se o seu teste for um teste de caixa
preta completo, onde você está testando não apenas a tecnologia, mas também os
recursos da equipe de segurança da organização alvo, evitá-lo seria perfeitamente
aceitável. No entanto, quando você está testando um grande número de sistemas em
coordenação com a equipe de segurança da organização alvo, pode não ser do interesse
do teste evitar seus ataques.
Permissão para testar
Um dos documentos mais importantes que precisam ser obtidos para um teste de
penetração é o documento Permissão para Teste. Este documento declara o escopo e
contém uma assinatura que reconhece o conhecimento das atividades dos
testadores. Além disso, deve indicar claramente que os testes podem levar à
instabilidade do sistema e todo o cuidado devido será dado pelo testador para não travar
os sistemas no processo. No entanto, como os testes podem levar à instabilidade, o
cliente não deverá responsabilizar o testador por qualquer instabilidade ou falha do
sistema. É fundamental que os testes não comecem até que este documento seja
assinado pelo cliente.
Além disso, alguns provedores de serviços exigem aviso prévio e/ou permissão separada
antes de testar seus sistemas. Por exemplo, a Amazon possui um formulário de
solicitação on-line que deve ser preenchido e a solicitação deve ser aprovada antes de
verificar qualquer host em sua nuvem. Se for necessário, deverá fazer parte do
documento.
Considerações legais
Algumas atividades comuns em testes de penetração podem violar as leis locais. Por
este motivo, é aconselhável verificar a legalidade das tarefas comuns de pentest no local
onde o trabalho será realizado. Por exemplo, quaisquer chamadas VOIP capturadas
durante o teste de penetração podem ser consideradas escutas telefônicas em algumas
áreas.
Capacidades e tecnologia implementadas
Bons testes de penetração não verificam simplesmente sistemas sem patches. Eles
também testam as capacidades da organização-alvo. Para esse fim, abaixo está uma lista
de coisas que você pode avaliar durante o teste.
Capacidade de detectar e responder à coleta de informações
Capacidade de detectar e responder à impressão do pé
Capacidade de detectar e responder a varreduras e análises de vulnerabilidades
Capacidade de detectar e responder a infiltrações (ataques)
Capacidade de detectar e responder à agregação de dados
Capacidade de detectar e responder à exfiltração de dados
Ao rastrear essas informações, certifique-se de coletar informações de tempo. Por
exemplo, se uma varredura for detectada, você deverá ser notificado e anotar qual nível
de varredura você estava realizando no momento.
Conteúdo
1Em geral
1.1Conceitos básicos
1.1.1Coleta de informações de nível 1
2Coleta de informação
2.1O que é isso
2.2Por que fazê-lo
2.3O que não é
3Seleção de Alvo
3.1Identificação e Nomenclatura do Alvo
3.2Considere quaisquer limitações das Regras de Engajamento
3.3Considere o tempo de teste
3.4Considere o objetivo final do teste
4OSINT
4.1Corporativo
4.1.1Físico
4.1.1.1Locais (L1)
4.1.1.2Difusão (L1)
4.1.1.3Relacionamentos (L1)
4.1.2Lógico
4.1.3Organograma (L1)
4.1.4Eletrônico
4.1.4.1Metadados do Documento (L1/L2)
4.1.4.2Comunicações de Marketing (L1/L2)
4.1.5Ativos de infraestrutura
4.1.5.1Blocos de rede próprios (L1)
4.1.5.2Endereços de e-mail (L1)
4.1.5.3Perfil de infraestrutura externa (L1)
4.1.5.4Tecnologias utilizadas (L1/L2)
4.1.5.5Contratos de compra (L1/L2/L3)
4.1.5.6Acesso remoto (L1/L2)
4.1.5.7Uso do aplicativo (L1/L2)
4.1.5.8Tecnologias de defesa (L1/L2/L3)
4.1.5.8.1Impressão digital passiva
4.1.5.8.2Impressão digital ativa
4.1.5.9Capacidade humana (L1/L2/L3)
4.1.6Financeiro
4.1.6.1Relatórios (L1/L2)
4.1.6.2Análise de mercado (L1/L2/L3)
4.1.6.2.1Capital comercial
4.1.6.2.2Histórico de valor
4.1.6.2.3EDGAR (SEC)
4.2Individual
4.2.1Funcionário
4.2.1.1História
4.2.1.2Perfil de rede social (SocNet)
4.2.1.3Presença na Internet
4.2.1.4Localização física
4.2.1.5Pegada móvel
4.2.1.6Informações "Para pagamento"
5Reunião secreta
5.1Corporativo
5.1.1Reunião no local
5.1.2Reunião externa
5.2HUMINT
5.2.1Resultados
6Pegada
6.1Pegada Externa
6.1.1Identificar intervalos externos do cliente
6.1.2Reconhecimento Passivo
6.1.2.1Pesquisas WHOIS
6.1.2.2Óculos BGP
6.1.3Pegada Ativa
6.1.3.1Varredura de porta
6.1.3.2Agarrando banner
6.1.3.3Varreduras SNMP
6.1.3.4Transferências de zona
6.1.3.5Recuperação de SMTP
6.1.3.6Descoberta de DNS
6.1.3.7DNS direto/reverso
6.1.3.8Força bruta de DNS
6.1.3.9Descoberta de aplicativos da Web
6.1.3.10Detecção e enumeração de hosts virtuais
6.1.4Estabelecer lista de alvos externos
6.1.4.1Mapeando versões
6.1.4.2Identificando níveis de patch
6.1.4.3Procurando por aplicativos da web fracos
6.1.4.4Identificar limite de bloqueio
6.2Pegada Interna
6.2.2Identifique os intervalos internos do cliente
6.2.3Reconhecimento Ativo
7Identificar mecanismos de proteção
7.1Proteções baseadas em rede
7.2Proteções baseadas em host
7.3Proteções em nível de aplicativo
7.4Proteções de armazenamento
7,5Proteções do usuário
Em geral
Esta seção define as atividades de coleta de inteligência de um teste de penetração. O
objetivo deste documento é fornecer um padrão projetado especificamente para o
pentester realizar reconhecimento contra um alvo (normalmente corporativo, militar ou
relacionado). O documento detalha o processo de pensamento e os objetivos do
reconhecimento de pentesting e, quando usado corretamente, ajuda o leitor a produzir
um plano altamente estratégico para atacar um alvo.
Conceitos básicos
Os níveis são um conceito importante para este documento e para o PTES como um
todo. É uma espécie de modelo de maturidade para pentesting. A definição de níveis
permite-nos clarificar os resultados e atividades esperados dentro de certas restrições do
mundo real, como tempo, esforço, acesso à informação, etc.
Os níveis de Coleta de Inteligência estão atualmente divididos em três categorias, e um
exemplo típico é dado para cada uma. Estas devem orientar a adição de técnicas no
documento abaixo. Por exemplo, uma atividade intensiva como a criação de um perfil
no Facebook e a análise da rede social do alvo é apropriada em casos mais avançados e
deve ser rotulada com o nível apropriado. Veja o mapa mental abaixo para exemplos.
Coleta de informações de nível 1
(pense: Orientado à Conformidade) Principalmente um processo de coleta de
informações por meio de um botão de clique. Este nível de informação pode ser obtido
quase inteiramente por ferramentas automatizadas. O mínimo é dizer que você fez IG
para um PT.
A Acme Corporation deve estar em conformidade com PCI/FISMA/HIPAA. Um esforço
de coleta de informações de Nível 1 deve ser apropriado para atender ao requisito de
conformidade.
(pense: Melhores Práticas) Este nível pode ser criado usando ferramentas automatizadas
do nível 1 e algumas análises manuais. Uma boa compreensão do negócio, incluindo
informações como localização física, relações comerciais, organograma, etc.
A Widgets Inc deve estar em conformidade com o PCI, mas está interessada em sua
estratégia de segurança de longo prazo e está adquirindo vários fabricantes menores de
widgets. Um esforço de recolha de informação de Nível 2 deverá ser apropriado para
satisfazer as suas necessidades.
(pense: Patrocinado pelo Estado) Pentest mais avançado, Redteam, escopo
completo. Todas as informações do nível 1 e do nível 2 junto com muitas análises
manuais. Pense em cultivar relacionamentos no SocNet, análise pesada, compreensão
profunda das relações comerciais, provavelmente um grande número de horas para
realizar a coleta e correlação.
Uma Equipe Vermelha do Exército tem a tarefa de analisar e atacar um segmento da
rede do Exército em um país estrangeiro para encontrar pontos fracos que possam ser
explorados por um estrangeiro. Um esforço de recolha de informação de nível 3 seria
apropriado neste caso.
O que é isso
A coleta de inteligência está realizando o reconhecimento contra um alvo para coletar o
máximo de informações possível para ser utilizada ao penetrar no alvo durante as fases
de avaliação e exploração de vulnerabilidade. Quanto mais informações você conseguir
reunir durante esta fase, mais vetores de ataque poderá usar no futuro.
Inteligência de código aberto (OSINT) é uma forma de gerenciamento de coleta de
inteligência que envolve encontrar, selecionar e adquirir informações de fontes
disponíveis publicamente e analisá-las para produzir inteligência acionável. [1]
Por que fazê-lo
Realizamos coleta de inteligência de código aberto para determinar vários pontos de
entrada em uma organização. Esses pontos de entrada podem ser físicos, eletrônicos
e/ou humanos. Muitas empresas não levam em consideração quais informações sobre si
mesmas são divulgadas publicamente e como essas informações podem ser usadas por
um determinado invasor. Além disso, muitos funcionários não levam em consideração
quais informações colocam sobre si mesmos em público e como essas informações
podem ser usadas para atacá-los ou a seus empregadores.
O que não é
OSINT pode não ser preciso ou oportuno. As fontes de informação podem ser
manipuladas deliberada/acidentalmente para refletir dados errados, a informação pode
tornar-se obsoleta com o passar do tempo ou simplesmente ser incompleta.
Não abrange o mergulho em lixeiras ou quaisquer métodos de recuperação de
informações da empresa a partir de itens físicos encontrados no local.
Seleção de Alvo
Identificação e Nomenclatura do Alvo
Ao abordar uma organização-alvo, é importante compreender que uma empresa pode ter
vários Domínios de Topo (TDLs) e negócios auxiliares diferentes. Embora essas
informações devessem ter sido descobertas durante a fase de definição do escopo, não é
tão incomum identificar domínios de servidores e empresas adicionais que podem não
ter feito parte do escopo inicial discutido na fase de pré-engajamento. Por exemplo, uma
empresa pode ter um TDL de .com. No entanto, eles também podem ter .net .co
e .xxx. Estes podem precisar fazer parte do escopo revisado ou podem estar fora dos
limites. De qualquer forma, ele precisa ser esclarecido com o cliente antes do início do
teste. Também não é tão incomum que uma empresa tenha várias subempresas abaixo
dela. Por exemplo, a General Electric e a Proctor and Gamble possuem muitas empresas
menores.
Considere quaisquer limitações das Regras de Engajamento
Neste ponto, é uma boa ideia rever as Regras de Engajamento. É comum que sejam
esquecidos durante uma prova. Às vezes, como testadores, ficamos tão envolvidos com
o que encontramos e com as possibilidades de ataque que esquecemos quais endereços
IP, domínios e redes podemos atacar. Sempre consulte as Regras de Engajamento para
manter o foco em seus testes. Isto não é importante apenas do ponto de vista jurídico,
mas também é importante do ponto de vista do aumento do escopo. Cada vez que você
se desvia dos objetivos principais do teste, isso lhe custa tempo. E, no longo prazo, isso
pode custar dinheiro à sua empresa.
Considere o tempo de teste
A quantidade de tempo para o teste total terá impacto direto na quantidade de Coleta de
Inteligência que pode ser realizada. Existem alguns testes em que o tempo total é de
dois a três meses. Nesses compromissos, uma empresa de testes gastaria muito tempo
examinando cada uma das principais unidades de negócios e pessoal da empresa. No
entanto, para testes mais curtos no estilo caixa de cristal, os objetivos podem ser muito
mais táticos. Por exemplo, testar um aplicativo web específico pode não exigir que você
pesquise os registros financeiros do CEO da empresa.
Considere o objetivo final do teste
Cada teste tem um objetivo final em mente – um ativo ou processo específico que a
organização considera crítico. Tendo o resultado final em mente, a fase de recolha de
informações deve incluir todos os elementos secundários e terciários que rodeiam o
objetivo final. Sejam tecnologias de apoio, terceiros, pessoal relevante, etc... Garantir
que o foco seja mantido nos ativos críticos garante que os elementos de inteligência
menos relevantes sejam despriorizados e categorizados como tal, a fim de não interferir
no processo de análise.
OSINT
Open Source Intelligence (OSINT) assume três formas; Passivo, Semipassivo e Ativo.
Coleta passiva de informações : A coleta passiva de informações geralmente só é útil se
houver um requisito muito claro de que as atividades de coleta de informações nunca
sejam detectadas pelo alvo. Este tipo de perfil é tecnicamente difícil de executar, pois
nunca enviamos qualquer tráfego para a organização alvo, nem de um de nossos hosts,
nem de hosts ou serviços “anônimos” pela Internet. Isso significa que só podemos usar e
coletar informações arquivadas ou armazenadas. Como tal, esta informação pode estar
desatualizada ou incorreta, pois estamos limitados aos resultados recolhidos de
terceiros.
Coleta de informações semipassiva : O objetivo da coleta de informações semipassiva é

traçar o perfil do alvo com métodos que pareceriam tráfego e comportamento normais
da Internet. Consultamos apenas os servidores de nomes publicados em busca de
informações, não realizamos pesquisas reversas aprofundadas ou solicitações de DNS
de força bruta, não procuramos servidores ou diretórios “não publicados”. Não estamos
executando portscans ou crawlers em nível de rede e apenas analisamos metadados em
documentos e arquivos publicados; não buscando ativamente conteúdo oculto. A chave
aqui é não chamar a atenção para nossas atividades. Post mortem, o alvo pode ser capaz
de voltar e descobrir as atividades de reconhecimento, mas não deve ser capaz de
atribuir a atividade a ninguém.
Coleta ativa de informações : A coleta ativa de informações deve ser detectada pelo alvo
e pelo comportamento suspeito ou malicioso. Durante este estágio, estamos mapeando
ativamente a infraestrutura de rede (pense em varreduras completas de portas nmap –p1-
65535), enumerando ativamente e/ou verificando vulnerabilidades dos serviços abertos,
estamos procurando ativamente por diretórios, arquivos e servidores não publicados. A
maior parte dessa atividade se enquadra nas atividades típicas de “reconhecimento” ou
“varredura” do seu pentest padrão.
Corporativo
Físico
Locais (L1)
Listagem por local de endereço completo, propriedade, registros associados (municipal,
fiscal, legal, etc.), Listagem completa de todas as medidas de segurança física para o
local (posicionamento de câmeras, sensores, cercas, postos de guarda, controle de
entrada, portões, tipo de identificação , entrada do fornecedor, localizações físicas
baseadas em blocos IP/serviços de geolocalização, etc… Para Hosts/NOC: Notação
CIDR completa de hosts e redes, listagem DNS completa de todos os ativos associados,
Mapeamento completo de AS, caminhos de peering, provisionamento de CDN,
proprietários de netblock (dados whois), registros de e-mail (MX + estrutura de
endereço de e-mail)
Proprietário (L1/L2)
Registros territoriais/fiscais (L1/L2)
Compartilhado/individual (L1/L2)
Fusos horários (L1/L2)
Anfitriões / NOC
Difusão (L1)
Não é incomum que uma organização-alvo tenha vários locais físicos separados. Por
exemplo, um banco terá escritórios centrais, mas também terá inúmeras agências
remotas. Embora a segurança física e técnica possa ser muito boa em locais centrais, os
locais remotos muitas vezes têm controlos de segurança deficientes.
Relacionamentos (L1)
Parceiros de negócios, alfândegas, fornecedores, análises via o que é compartilhado
abertamente em páginas corporativas, locadoras, etc. Essas informações podem ser
utilizadas para entender melhor o negócio ou projetos organizacionais. Por exemplo,
quais produtos e serviços são essenciais para a organização-alvo?
Além disso, essas informações também podem ser usadas para criar cenários de
engenharia social bem-sucedidos.
Relacionamentos (L2/L3)
Análise manual para examinar informações do nível 1, além de aprofundar possíveis
relacionamentos.
Espaço de escritório compartilhado (L2/L3)
Infraestrutura compartilhada (L2/L3)
Equipamento Alugado/Locado (L2/L3)
Lógico
Informações acumuladas de parceiros, clientes e concorrentes: Para cada um, uma
listagem completa do nome comercial, endereço comercial, tipo de relacionamento,
informações financeiras básicas, informações básicas de hosts/rede.
Parceiros de negócios (L1/L2/L3)
Parceiros de negócios anunciados pela Target. Às vezes anunciado no www principal.
Clientes Empresariais (L1/L2/L3)
Clientes empresariais anunciados da Target. Às vezes anunciado no www principal.
Concorrentes (L1/L2/L3)
Quem são os concorrentes do alvo. Isso pode ser simples, Ford vs Chevy, ou pode exigir
muito mais análises.
Touchgráfico (L1)
Um touchgraph (representação visual das conexões sociais entre as pessoas) ajudará a
mapear as possíveis interações entre as pessoas na organização e como acessá-las de
fora (quando um touchgraph inclui comunidades externas e é criado com um nível de
profundidade acima 2).
O touchgraph básico deve refletir a estrutura organizacional derivada das informações
coletadas até o momento, e a expansão adicional do gráfico deve basear-se nele (já que
geralmente representa melhor o foco nos ativos organizacionais e torna claros os
possíveis vetores de abordagem).
Perfil Hoovers (L1/L2)
O quê: um recurso de inteligência de código semiaberto (geralmente assinaturas
pagas). Essas fontes são especializadas na coleta de informações relacionadas aos
negócios das empresas e no fornecimento de uma visão “normalizada” dos negócios.
Por quê: As informações incluem localizações físicas, cenário competitivo, pessoal-
chave, informações financeiras e outros dados relacionados aos negócios (dependendo
da fonte). Isso pode ser usado para criar um perfil mais preciso do alvo e identificar
pessoal adicional e terceiros que podem ser usados no teste.
Como: A simples busca no site pelo nome empresarial fornece todo o perfil da empresa
e todas as informações que estão disponíveis nela. É recomendado usar algumas fontes
para fazer referência cruzada e garantir que você obtenha as informações mais
atualizadas. (pago pelo serviço).
Linha de produtos (L2/L3)
As ofertas de produtos da Target que podem exigir análise adicional, se a meta também
oferecer serviços, isso pode exigir uma análise mais aprofundada.
Mercado Vertical (L1)
Em qual setor o alvo reside. Ou seja, financeiro, defesa, agricultura, governo, etc.
Contas de marketing (L2/L3)
As atividades de marketing podem fornecer uma riqueza de informações sobre a
estratégia de marketing do alvo
Avalie todas as redes de mídia social para as personas sociais do alvo
Avalie as campanhas de marketing anteriores * do alvo
Reuniões (L2/L3)
Ata da reunião publicada?
Reuniões abertas ao público?
Datas significativas da empresa (L1/L2/L3)
Reuniões do conselho
Feriados
Aniversários
Lançamento de produto/serviço
Vagas de emprego (L1/L2)
Ao visualizar uma lista de vagas de emprego em uma organização (geralmente
encontrada na seção “carreiras” do site), você pode determinar os tipos de tecnologias
usadas na organização. Um exemplo seria se uma organização tiver uma vaga de
emprego para administrador de sistema Solaris sênior, então é bastante óbvio que a
organização está usando sistemas Solaris. Outras posições podem não ser tão óbvias
pelo título do cargo, mas uma posição aberta de administrador de rede júnior pode dizer
algo como 'preferencial CCNA' ou 'preferencial JNCIA', o que indica que eles estão
usando tecnologias Cisco ou Juniper.
Afiliações de caridade (L1/L2/L3)
É muito comum que membros executivos de uma organização-alvo estejam associados
a organizações de caridade. Essas informações podem ser usadas para desenvolver
cenários sólidos de engenharia social para atingir executivos.
RFP, RFQ e outras informações sobre licitações públicas (L1/L2)
As RFPs e RFQs muitas vezes revelam muitas informações sobre os tipos de sistemas
usados por uma empresa e, potencialmente, até mesmo lacunas ou problemas com sua
infraestrutura.
Descobrir quem são os atuais vencedores da licitação pode revelar os tipos de sistemas
usados ou um local onde os recursos da empresa podem estar hospedados fora do local.
Registros judiciais (L2/L3)
Os registros judiciais geralmente estão disponíveis gratuitamente ou, às vezes, mediante
pagamento de uma taxa.
O conteúdo do litígio pode revelar informações sobre reclamantes anteriores, incluindo,
entre outros, ações judiciais de ex-funcionários
Os registos criminais de funcionários atuais e anteriores podem fornecer uma lista de
alvos para esforços de engenharia social
Doações políticas (L2/L3)
Mapear as doações políticas ou outros interesses financeiros é importante para
identificar indivíduos essenciais que podem não estar em posições de poder óbvias, mas
que têm interesses adquiridos (ou que existem interesses adquiridos neles).
O mapeamento político das doações mudará entre países com base na liberdade de
informação, mas muitas vezes os casos de doações de outros países podem ser
rastreados usando os dados aí disponíveis.
Licenças ou registros profissionais (L2/L3)
Reunir uma lista de licenças e registros profissionais de seu alvo pode oferecer uma
visão não apenas de como a empresa operava, mas também das diretrizes e
regulamentos que eles seguem para manter essas licenças. Um excelente exemplo disso
é a certificação do padrão ISO de uma empresa que pode mostrar que uma empresa
segue diretrizes e processos definidos. É importante que um testador esteja ciente desses
processos e de como eles podem afetar os testes realizados na organização.
Muitas vezes, uma empresa lista esses detalhes em seu site como uma medalha de
honra. Em outros casos, pode ser necessário pesquisar os registros de uma determinada
vertical para verificar se uma organização é membro. A informação disponível depende
muito do mercado vertical, bem como da localização geográfica da empresa. Deve-se
também notar que as empresas internacionais podem ser licenciadas de forma diferente
e ser obrigadas a registar-se junto de diferentes normas ou organismos legais
dependentes do país.
Conteúdo
1Em geral
1.1Conceitos básicos
2Coleta de informação
2.1O que é isso
2.2Por que fazê-lo
2.3O que não é
3Seleção de Alvo
3.1Identificação e Nomenclatura do Alvo
3.2Considere quaisquer limitações das Regras de Engajamento
3.3Considere o tempo de teste
3.4Considere o objetivo final do teste
4OSINT
4.1Corporativo
4.1.1Físico
4.1.1.1Locais (L1)
4.1.1.2Difusão (L1)
4.1.1.3Relacionamentos (L1)
4.1.2Lógico
4.1.3Organograma (L1)
4.1.4Eletrônico
4.1.4.1Metadados do Documento (L1/L2)
4.1.4.2Comunicações de Marketing (L1/L2)
4.1.5Ativos de infraestrutura
4.1.5.1Blocos de rede próprios (L1)
4.1.5.2Endereços de e-mail (L1)
4.1.5.3Perfil de infraestrutura externa (L1)
4.1.5.4Tecnologias utilizadas (L1/L2)
4.1.5.5Contratos de compra (L1/L2/L3)
4.1.5.6Acesso remoto (L1/L2)
4.1.5.7Uso do aplicativo (L1/L2)
4.1.5.8Tecnologias de defesa (L1/L2/L3)
4.1.5.8.1Impressão digital passiva
4.1.5.8.2Impressão digital ativa
4.1.5.9Capacidade humana (L1/L2/L3)
4.1.6Financeiro
4.1.6.1Relatórios (L1/L2)
4.1.6.2Análise de mercado (L1/L2/L3)
4.1.6.2.1Capital comercial
4.1.6.2.2Histórico de valor
4.1.6.2.3EDGAR (SEC)
4.2Individual
4.2.1Funcionário
4.2.1.1História
4.2.1.2Perfil de rede social (SocNet)
4.2.1.3Presença na Internet
4.2.1.4Localização física
4.2.1.5Pegada móvel
4.2.1.6Informações "Para pagamento"
5Reunião secreta
5.1Corporativo
5.1.1Reunião no local
5.1.2Reunião externa
5.2HUMINT
5.2.1Resultados
6Pegada
6.1Pegada Externa
6.1.1Identificar intervalos externos do cliente
6.1.2.1Pesquisas WHOIS
6.1.2.2Óculos BGP
6.1.3Pegada Ativa
6.1.3.1Varredura de porta
6.1.3.2Agarrando banner
6.1.3.3Varreduras SNMP
6.1.3.4Transferências de zona
6.1.3.5Recuperação de SMTP
6.1.3.6Descoberta de DNS
6.1.3.7DNS direto/reverso
6.1.3.8Força bruta de DNS
6.1.3.9Descoberta de aplicativos da Web
6.1.3.10Detecção e enumeração de hosts virtuais
6.1.4Estabelecer lista de alvos externos
6.1.4.1Mapeando versões
6.1.4.2Identificando níveis de patch
6.1.4.3Procurando por aplicativos da web fracos
6.1.4.4Identificar limite de bloqueio
6.2Pegada Interna
6.2.2Identifique os intervalos internos do cliente
6.2.3Reconhecimento Ativo
7Identificar mecanismos de proteção
7.1Proteções baseadas em rede
7.2Proteções baseadas em host
7.3Proteções em nível de aplicativo
7.4Proteções de armazenamento
7,5Proteções do usuário
Em geral
Esta seção define as atividades de coleta de inteligência de um teste de penetração. O
objetivo deste documento é fornecer um padrão projetado especificamente para o
pentester realizar reconhecimento contra um alvo (normalmente corporativo, militar ou
relacionado). O documento detalha o processo de pensamento e os objetivos do
reconhecimento de pentesting e, quando usado corretamente, ajuda o leitor a produzir
um plano altamente estratégico para atacar um alvo.
Conceitos básicos
Os níveis são um conceito importante para este documento e para o PTES como um
todo. É uma espécie de modelo de maturidade para pentesting. A definição de níveis
permite-nos clarificar os resultados e atividades esperados dentro de certas restrições do
mundo real, como tempo, esforço, acesso à informação, etc.
Os níveis de Coleta de Inteligência estão atualmente divididos em três categorias, e um
exemplo típico é dado para cada uma. Estas devem orientar a adição de técnicas no
documento abaixo. Por exemplo, uma atividade intensiva como a criação de um perfil
no Facebook e a análise da rede social do alvo é apropriada em casos mais avançados e
deve ser rotulada com o nível apropriado. Veja o mapa mental abaixo para exemplos.
(pense: Orientado à Conformidade) Principalmente um processo de coleta de
informações por meio de um botão de clique. Este nível de informação pode ser obtido
quase inteiramente por ferramentas automatizadas. O mínimo é dizer que você fez IG
para um PT.
A Acme Corporation deve estar em conformidade com PCI/FISMA/HIPAA. Um esforço
de coleta de informações de Nível 1 deve ser apropriado para atender ao requisito de
conformidade.
(pense: Melhores Práticas) Este nível pode ser criado usando ferramentas automatizadas
do nível 1 e algumas análises manuais. Uma boa compreensão do negócio, incluindo
informações como localização física, relações comerciais, organograma, etc.
A Widgets Inc deve estar em conformidade com o PCI, mas está interessada em sua
estratégia de segurança de longo prazo e está adquirindo vários fabricantes menores de
widgets. Um esforço de recolha de informação de Nível 2 deverá ser apropriado para
satisfazer as suas necessidades.
(pense: Patrocinado pelo Estado) Pentest mais avançado, Redteam, escopo
completo. Todas as informações do nível 1 e do nível 2 junto com muitas análises
manuais. Pense em cultivar relacionamentos no SocNet, análise pesada, compreensão
profunda das relações comerciais, provavelmente um grande número de horas para
realizar a coleta e correlação.
Uma Equipe Vermelha do Exército tem a tarefa de analisar e atacar um segmento da
rede do Exército em um país estrangeiro para encontrar pontos fracos que possam ser
explorados por um estrangeiro. Um esforço de recolha de informação de nível 3 seria
apropriado neste caso.
O que é isso
A coleta de inteligência está realizando o reconhecimento contra um alvo para coletar o
máximo de informações possível para ser utilizada ao penetrar no alvo durante as fases
de avaliação e exploração de vulnerabilidade. Quanto mais informações você conseguir
reunir durante esta fase, mais vetores de ataque poderá usar no futuro.
Inteligência de código aberto (OSINT) é uma forma de gerenciamento de coleta de
inteligência que envolve encontrar, selecionar e adquirir informações de fontes
disponíveis publicamente e analisá-las para produzir inteligência acionável. [1]
Por que fazê-lo
Realizamos coleta de inteligência de código aberto para determinar vários pontos de
entrada em uma organização. Esses pontos de entrada podem ser físicos, eletrônicos
e/ou humanos. Muitas empresas não levam em consideração quais informações sobre si
mesmas são divulgadas publicamente e como essas informações podem ser usadas por
um determinado invasor. Além disso, muitos funcionários não levam em consideração
quais informações colocam sobre si mesmos em público e como essas informações
podem ser usadas para atacá-los ou a seus empregadores.
O que não é
OSINT pode não ser preciso ou oportuno. As fontes de informação podem ser
manipuladas deliberada/acidentalmente para refletir dados errados, a informação pode
tornar-se obsoleta com o passar do tempo ou simplesmente ser incompleta.
Não abrange o mergulho em lixeiras ou quaisquer métodos de recuperação de
informações da empresa a partir de itens físicos encontrados no local.
Seleção de Alvo
Identificação e Nomenclatura do Alvo
Ao abordar uma organização-alvo, é importante compreender que uma empresa pode ter
vários Domínios de Topo (TDLs) e negócios auxiliares diferentes. Embora essas
informações devessem ter sido descobertas durante a fase de definição do escopo, não é
tão incomum identificar domínios de servidores e empresas adicionais que podem não
ter feito parte do escopo inicial discutido na fase de pré-engajamento. Por exemplo, uma
empresa pode ter um TDL de .com. No entanto, eles também podem ter .net .co
e .xxx. Estes podem precisar fazer parte do escopo revisado ou podem estar fora dos
limites. De qualquer forma, ele precisa ser esclarecido com o cliente antes do início do
teste. Também não é tão incomum que uma empresa tenha várias subempresas abaixo
dela. Por exemplo, a General Electric e a Proctor and Gamble possuem muitas empresas
menores.
Considere quaisquer limitações das Regras de Engajamento
Neste ponto, é uma boa ideia rever as Regras de Engajamento. É comum que sejam
esquecidos durante uma prova. Às vezes, como testadores, ficamos tão envolvidos com
o que encontramos e com as possibilidades de ataque que esquecemos quais endereços
IP, domínios e redes podemos atacar. Sempre consulte as Regras de Engajamento para
manter o foco em seus testes. Isto não é importante apenas do ponto de vista jurídico,
mas também é importante do ponto de vista do aumento do escopo. Cada vez que você
se desvia dos objetivos principais do teste, isso lhe custa tempo. E, no longo prazo, isso
pode custar dinheiro à sua empresa.
Considere o tempo de teste
A quantidade de tempo para o teste total terá impacto direto na quantidade de Coleta de
Inteligência que pode ser realizada. Existem alguns testes em que o tempo total é de
dois a três meses. Nesses compromissos, uma empresa de testes gastaria muito tempo
examinando cada uma das principais unidades de negócios e pessoal da empresa. No
entanto, para testes mais curtos no estilo caixa de cristal, os objetivos podem ser muito
mais táticos. Por exemplo, testar um aplicativo web específico pode não exigir que você
pesquise os registros financeiros do CEO da empresa.
Considere o objetivo final do teste
Cada teste tem um objetivo final em mente – um ativo ou processo específico que a
organização considera crítico. Tendo o resultado final em mente, a fase de recolha de
informações deve incluir todos os elementos secundários e terciários que rodeiam o
objetivo final. Sejam tecnologias de apoio, terceiros, pessoal relevante, etc... Garantir
que o foco seja mantido nos ativos críticos garante que os elementos de inteligência
menos relevantes sejam despriorizados e categorizados como tal, a fim de não interferir
no processo de análise.
OSINT
Open Source Intelligence (OSINT) assume três formas; Passivo, Semipassivo e Ativo.
Coleta passiva de informações : A coleta passiva de informações geralmente só é útil se
houver um requisito muito claro de que as atividades de coleta de informações nunca
sejam detectadas pelo alvo. Este tipo de perfil é tecnicamente difícil de executar, pois
nunca enviamos qualquer tráfego para a organização alvo, nem de um de nossos hosts,
nem de hosts ou serviços “anônimos” pela Internet. Isso significa que só podemos usar e
coletar informações arquivadas ou armazenadas. Como tal, esta informação pode estar
desatualizada ou incorreta, pois estamos limitados aos resultados recolhidos de
terceiros.
Coleta de informações semipassiva : O objetivo da coleta de informações semipassiva é

traçar o perfil do alvo com métodos que pareceriam tráfego e comportamento normais
da Internet. Consultamos apenas os servidores de nomes publicados em busca de
informações, não realizamos pesquisas reversas aprofundadas ou solicitações de DNS
de força bruta, não procuramos servidores ou diretórios “não publicados”. Não estamos
executando portscans ou crawlers em nível de rede e apenas analisamos metadados em
documentos e arquivos publicados; não buscando ativamente conteúdo oculto. A chave
aqui é não chamar a atenção para nossas atividades. Post mortem, o alvo pode ser capaz
de voltar e descobrir as atividades de reconhecimento, mas não deve ser capaz de
atribuir a atividade a ninguém.
Coleta ativa de informações : A coleta ativa de informações deve ser detectada pelo alvo
e pelo comportamento suspeito ou malicioso. Durante este estágio, estamos mapeando
ativamente a infraestrutura de rede (pense em varreduras completas de portas nmap –p1-
65535), enumerando ativamente e/ou verificando vulnerabilidades dos serviços abertos,
estamos procurando ativamente por diretórios, arquivos e servidores não publicados. A
maior parte dessa atividade se enquadra nas atividades típicas de “reconhecimento” ou
“varredura” do seu pentest padrão.
Corporativo
Físico
Locais (L1)
Listagem por local de endereço completo, propriedade, registros associados (municipal,
fiscal, legal, etc.), Listagem completa de todas as medidas de segurança física para o
local (posicionamento de câmeras, sensores, cercas, postos de guarda, controle de
entrada, portões, tipo de identificação , entrada do fornecedor, localizações físicas
baseadas em blocos IP/serviços de geolocalização, etc… Para Hosts/NOC: Notação
CIDR completa de hosts e redes, listagem DNS completa de todos os ativos associados,
Mapeamento completo de AS, caminhos de peering, provisionamento de CDN,
proprietários de netblock (dados whois), registros de e-mail (MX + estrutura de
endereço de e-mail)
Proprietário (L1/L2)
Registros territoriais/fiscais (L1/L2)
Compartilhado/individual (L1/L2)
Fusos horários (L1/L2)
Anfitriões / NOC
Difusão (L1)
Não é incomum que uma organização-alvo tenha vários locais físicos separados. Por
exemplo, um banco terá escritórios centrais, mas também terá inúmeras agências
remotas. Embora a segurança física e técnica possa ser muito boa em locais centrais, os
locais remotos muitas vezes têm controlos de segurança deficientes.
Relacionamentos (L1)
Parceiros de negócios, alfândegas, fornecedores, análises via o que é compartilhado
abertamente em páginas corporativas, locadoras, etc. Essas informações podem ser
utilizadas para entender melhor o negócio ou projetos organizacionais. Por exemplo,
quais produtos e serviços são essenciais para a organização-alvo?
Além disso, essas informações também podem ser usadas para criar cenários de
engenharia social bem-sucedidos.
Relacionamentos (L2/L3)
Análise manual para examinar informações do nível 1, além de aprofundar possíveis
relacionamentos.
Espaço de escritório compartilhado (L2/L3)
Infraestrutura compartilhada (L2/L3)
Equipamento Alugado/Locado (L2/L3)
Lógico
Informações acumuladas de parceiros, clientes e concorrentes: Para cada um, uma
listagem completa do nome comercial, endereço comercial, tipo de relacionamento,
informações financeiras básicas, informações básicas de hosts/rede.
Parceiros de negócios (L1/L2/L3)
Parceiros de negócios anunciados pela Target. Às vezes anunciado no www principal.
Clientes Empresariais (L1/L2/L3)
Clientes empresariais anunciados da Target. Às vezes anunciado no www principal.
Concorrentes (L1/L2/L3)
Quem são os concorrentes do alvo. Isso pode ser simples, Ford vs Chevy, ou pode exigir
muito mais análises.
Touchgráfico (L1)
Um touchgraph (representação visual das conexões sociais entre as pessoas) ajudará a
mapear as possíveis interações entre as pessoas na organização e como acessá-las de
fora (quando um touchgraph inclui comunidades externas e é criado com um nível de
profundidade acima 2).
O touchgraph básico deve refletir a estrutura organizacional derivada das informações
coletadas até o momento, e a expansão adicional do gráfico deve basear-se nele (já que
geralmente representa melhor o foco nos ativos organizacionais e torna claros os
possíveis vetores de abordagem).
Perfil Hoovers (L1/L2)
O quê: um recurso de inteligência de código semiaberto (geralmente assinaturas
pagas). Essas fontes são especializadas na coleta de informações relacionadas aos
negócios das empresas e no fornecimento de uma visão “normalizada” dos negócios.
Por quê: As informações incluem localizações físicas, cenário competitivo, pessoal-
chave, informações financeiras e outros dados relacionados aos negócios (dependendo
da fonte). Isso pode ser usado para criar um perfil mais preciso do alvo e identificar
pessoal adicional e terceiros que podem ser usados no teste.
Como: A simples busca no site pelo nome empresarial fornece todo o perfil da empresa
e todas as informações que estão disponíveis nela. É recomendado usar algumas fontes
para fazer referência cruzada e garantir que você obtenha as informações mais
atualizadas. (pago pelo serviço).
Linha de produtos (L2/L3)
As ofertas de produtos da Target que podem exigir análise adicional, se a meta também
oferecer serviços, isso pode exigir uma análise mais aprofundada.
Mercado Vertical (L1)
Em qual setor o alvo reside. Ou seja, financeiro, defesa, agricultura, governo, etc.
Contas de marketing (L2/L3)
As atividades de marketing podem fornecer uma riqueza de informações sobre a
estratégia de marketing do alvo
Avalie todas as redes de mídia social para as personas sociais do alvo
Avalie as campanhas de marketing anteriores * do alvo
Reuniões (L2/L3)
Ata da reunião publicada?
Reuniões abertas ao público?
Datas significativas da empresa (L1/L2/L3)
Reuniões do conselho
Feriados
Aniversários
Lançamento de produto/serviço
Vagas de emprego (L1/L2)
Ao visualizar uma lista de vagas de emprego em uma organização (geralmente
encontrada na seção “carreiras” do site), você pode determinar os tipos de tecnologias
usadas na organização. Um exemplo seria se uma organização tiver uma vaga de
emprego para administrador de sistema Solaris sênior, então é bastante óbvio que a
organização está usando sistemas Solaris. Outras posições podem não ser tão óbvias
pelo título do cargo, mas uma posição aberta de administrador de rede júnior pode dizer
algo como 'preferencial CCNA' ou 'preferencial JNCIA', o que indica que eles estão
usando tecnologias Cisco ou Juniper.
Afiliações de caridade (L1/L2/L3)
É muito comum que membros executivos de uma organização-alvo estejam associados
a organizações de caridade. Essas informações podem ser usadas para desenvolver
cenários sólidos de engenharia social para atingir executivos.
RFP, RFQ e outras informações sobre licitações públicas (L1/L2)
As RFPs e RFQs muitas vezes revelam muitas informações sobre os tipos de sistemas
usados por uma empresa e, potencialmente, até mesmo lacunas ou problemas com sua
infraestrutura.
Descobrir quem são os atuais vencedores da licitação pode revelar os tipos de sistemas
usados ou um local onde os recursos da empresa podem estar hospedados fora do local.
Os registros judiciais geralmente estão disponíveis gratuitamente ou, às vezes, mediante
pagamento de uma taxa.
O conteúdo do litígio pode revelar informações sobre reclamantes anteriores, incluindo,
entre outros, ações judiciais de ex-funcionários
Os registos criminais de funcionários atuais e anteriores podem fornecer uma lista de
alvos para esforços de engenharia social
Doações políticas (L2/L3)
Mapear as doações políticas ou outros interesses financeiros é importante para
identificar indivíduos essenciais que podem não estar em posições de poder óbvias, mas
que têm interesses adquiridos (ou que existem interesses adquiridos neles).
O mapeamento político das doações mudará entre países com base na liberdade de
informação, mas muitas vezes os casos de doações de outros países podem ser
rastreados usando os dados aí disponíveis.
Reunir uma lista de licenças e registros profissionais de seu alvo pode oferecer uma
visão não apenas de como a empresa operava, mas também das diretrizes e
regulamentos que eles seguem para manter essas licenças. Um excelente exemplo disso
é a certificação do padrão ISO de uma empresa que pode mostrar que uma empresa
segue diretrizes e processos definidos. É importante que um testador esteja ciente desses
processos e de como eles podem afetar os testes realizados na organização.
Muitas vezes, uma empresa lista esses detalhes em seu site como uma medalha de
honra. Em outros casos, pode ser necessário pesquisar os registros de uma determinada
vertical para verificar se uma organização é membro. A informação disponível depende
muito do mercado vertical, bem como da localização geográfica da empresa. Deve-se
também notar que as empresas internacionais podem ser licenciadas de forma diferente
e ser obrigadas a registar-se junto de diferentes normas ou organismos legais
dependentes do país.
Organograma (L1)
Identificação de posição
Pessoas importantes na organização
Indivíduos a serem direcionados especificamente
Transações
Mapeamento de mudanças dentro da organização (promoções, movimentos laterais)
Afiliados
Mapeamento de organizações afiliadas vinculadas ao negócio
Eletrônico
Metadados do Documento (L1/L2)
O que é isso? Metadados ou metaconteúdo fornecem informações sobre os
dados/documento no escopo. Ele pode conter informações como nome do autor/criador,
hora e data, padrões usados/referidos, localização em uma rede de computadores
(impressora/pasta/caminho do diretório/etc. informações), geo-tag etc. contêm cor,
profundidade, resolução, marca/tipo de câmera e até mesmo as coordenadas e
informações de localização.
Por que você faria isso? Os metadados são importantes porque contêm informações
sobre a rede interna, nomes de usuários, endereços de e-mail, locais de impressoras, etc.
e ajudarão a criar um modelo do local. Também contém informações sobre o software
utilizado na criação dos respectivos documentos. Isso pode permitir que um invasor crie
um perfil e/ou execute ataques direcionados com conhecimento interno das redes e dos
usuários.
Como você faria isso? Existem ferramentas disponíveis para extrair os metadados do
arquivo (pdf/word/imagem) como FOCA (baseado em GUI), metagoofil (baseado em
python), meta-extrator, exiftool (baseado em perl). Essas ferramentas são capazes de
extrair e exibir os resultados em diversos formatos como HTML, XML, GUI, JSON etc.
A entrada para essas ferramentas é principalmente um documento baixado da presença
pública do 'cliente' e depois analisado para saber mais sobre ele . Já o FOCA ajuda você
a pesquisar documentos, baixar e analisar tudo por meio de sua interface GUI.
Comunicações de Marketing (L1/L2)
Campanhas de marketing anteriores fornecem informações sobre projetos que podem ter
sido desativados e que ainda podem estar acessíveis.
As comunicações de marketing atuais contêm componentes de design (cores, fontes,
gráficos, etc.) que também são, em sua maioria, usados internamente.
Informações de contato adicionais, incluindo organizações de marketing externas.
Ativos de infraestrutura
Blocos de rede próprios (L1)
Os blocos de rede de propriedade da organização podem ser obtidos passivamente
através da realização de pesquisas whois. DNSStuff.com é um balcão único para obter
esse tipo de informação.
Pesquisas de endereços IP de código aberto podem gerar informações sobre os tipos de
infraestrutura no destino. Os administradores costumam postar informações de endereço
IP no contexto de solicitações de ajuda em vários sites de suporte.
Endereços de e-mail (L1)
Os endereços de e-mail fornecem uma lista potencial de nomes de usuário e estruturas
de domínio válidos
Os endereços de e-mail podem ser obtidos de diversas fontes, incluindo o site da
organização.
Perfil de infraestrutura externa (L1)
O perfil da infraestrutura externa do alvo pode fornecer imensa informação sobre as
tecnologias utilizadas internamente.
Essas informações podem ser coletadas de múltiplas fontes, tanto passiva quanto
ativamente.
O perfil deve ser utilizado na montagem de um cenário de ataque contra a infraestrutura
externa.
Tecnologias utilizadas (L1/L2)
Pesquisas OSINT em fóruns de suporte, listas de discussão e outros recursos podem
reunir informações de tecnologias usadas no alvo
Uso de engenharia social contra a organização de tecnologia da informação identificada
Uso de engenharia social contra fornecedores de produtos
Contratos de compra (L1/L2/L3)
Os contratos de compra contêm informações sobre hardware, software, licenças e ativos
tangíveis adicionais existentes no destino.
Acesso remoto (L1/L2)
A obtenção de informações sobre como funcionários e/ou clientes se conectam ao alvo
para acesso remoto fornece um ponto potencial de entrada.
Muitas vezes, o link para o portal de acesso remoto está disponível na página inicial do
alvo
Documentos de instruções revelam aplicativos/procedimentos para conexão de usuários
remotos
Uso do aplicativo (L1/L2)
Reúna uma lista de aplicativos conhecidos usados pela organização alvo. Muitas vezes,
isso pode ser conseguido extraindo metadados de arquivos acessíveis ao público
(conforme discutido anteriormente).
Tecnologias de defesa (L1/L2/L3)
As tecnologias defensivas de impressão digital em uso podem ser alcançadas de várias
maneiras, dependendo das defesas em uso.
Impressão digital passiva
Pesquise fóruns e informações acessíveis ao público onde técnicos da organização alvo
possam estar discutindo questões ou pedindo assistência sobre a tecnologia em uso
Pesquise informações de marketing da organização-alvo, bem como de fornecedores de
tecnologia populares
Usando o Tin-eye (ou outra ferramenta de correspondência de imagens), pesquise o
logotipo da organização-alvo para ver se ele está listado nas páginas de referência do
fornecedor ou no material de marketing
Impressão digital ativa
Envie pacotes de investigação apropriados aos sistemas voltados ao público para testar
padrões de bloqueio. Existem diversas ferramentas para impressão digital de tipos
específicos de WAF.
As informações de cabeçalho, tanto nas respostas do site de destino quanto nos e-mails,
geralmente mostram informações não apenas sobre os sistemas em uso, mas também
sobre os mecanismos de proteção específicos ativados (por exemplo, gateway de e-mail,
scanners antivírus).
Capacidade humana (L1/L2/L3)
Descobrir a capacidade humana defensiva de uma organização-alvo pode ser
difícil. Existem várias informações importantes que podem ajudar a avaliar a segurança
da organização-alvo.
Verifique a presença de uma equipe CERT/CSIRT/PSRT em toda a empresa
Verifique se há empregos anunciados para ver com que frequência uma posição de
segurança é listada
Verifique se há empregos anunciados para ver se a segurança está listada como um
requisito para empregos não relacionados à segurança (por exemplo, desenvolvedores)
Verifique se há contratos de terceirização para ver se a segurança do alvo foi
terceirizada parcial ou totalmente
Verifique se há indivíduos específicos que trabalham para a empresa e que podem estar
ativos na comunidade de segurança
Financeiro
Relatórios (L1/L2)
As metas de relatórios financeiros dependerão muito da localização da organização. Os
relatórios também podem ser feitos através da sede da organização e não para cada
filial. Em 2008, a SEC publicou uma proposta de roteiro para a adopção das Normas
Internacionais de Relato Financeiro (IFRS) nos EUA.
Adoção das IFRS por país --> http://www.iasplus.com/en/resources/use-of-ifrs
Análise de mercado (L1/L2/L3)
Obtenha relatórios de análise de mercado de organizações de analistas (como Gartner,
IDC, Forrester, 541, etc...). Isso deve incluir qual é a definição de mercado,
capitalização de mercado, concorrentes e quaisquer alterações importantes na avaliação,
no produto ou na empresa em geral.
Capital comercial
Identifique se a organização está alocando qualquer capital comercial e qual a
porcentagem da avaliação geral e do capital livre que ela possui. Isto indicará o quão
sensível a organização é às flutuações do mercado e se depende de investimento externo
como parte da sua avaliação e fluxo de caixa.
Histórico de valor
Mapeamento da avaliação da organização ao longo do tempo, a fim de estabelecer
correlação entre eventos externos e internos, e seus efeitos na avaliação.
EDGAR (SEC)
O que é: EDGAR (sistema eletrônico de coleta, análise e recuperação de dados) é um
banco de dados da Comissão de Segurança e Câmbio dos EUA (SEC) que contém
declarações de registro, relatórios periódicos e outras informações de todas as empresas
(estrangeiras e nacionais) que são obrigados por lei a arquivar.
Por que fazer isso: Os dados EDGAR são importantes porque, além das informações
financeiras, identificam funcionários-chave dentro de uma empresa que, de outra forma,
não seriam notados no site da empresa ou em outra presença pública. Também inclui
declarações de remuneração de executivos, nomes e endereços dos principais
proprietários de ações ordinárias, um resumo dos processos judiciais contra a empresa,
fatores de risco econômico e outros dados potencialmente interessantes.
Como obter: As informações estão disponíveis no site EDGAR da SEC
( http://www.sec.gov/edgar.shtml ). Os relatórios de particular interesse incluem o 10-K
(relatório anual) e o 10-Q (relatório trimestral).
Individual
Funcionário
História
O que é: Registros judiciais são todos os registros públicos relacionados a queixas
criminais e/ou civis, ações judiciais ou outras ações legais a favor ou contra uma pessoa
ou organização de interesse.
Por que você faria isso: Os registros judiciais podem revelar informações confidenciais
relacionadas a um funcionário individual ou à empresa como um todo. Esta informação
pode ser útil por si só ou pode ser o motivador para a obtenção de informações
adicionais. Também poderia ser usado para engenharia social ou outros fins
posteriormente no teste de penetração.
Como você faria isso: Muitas dessas informações estão agora disponíveis na Internet
através de sites judiciais e bancos de dados de registros disponíveis
publicamente. Algumas informações adicionais podem estar disponíveis através de
serviços pagos, como LEXIS/NEXIS. Algumas informações podem estar disponíveis
por meio de solicitação de registros ou solicitações pessoais.
Doações Políticas (L2/L3)
O que é: As doações políticas são fundos pessoais de um indivíduo direcionados a
candidatos políticos, partidos políticos ou organizações de interesses especiais
específicos.
Por que você faria isso: Informações sobre doações políticas poderiam revelar
informações úteis relacionadas a um indivíduo. Esta informação pode ser utilizada como
parte da análise de redes sociais para ajudar a estabelecer ligações entre indivíduos e
políticos, candidatos políticos ou outras organizações políticas. Também poderia ser
usado para engenharia social ou outros fins posteriormente no teste de penetração.
através de sites publicamente disponíveis (ou seja, http://www.opensecrets.org/ ) que
rastreiam as doações políticas por indivíduo. Dependendo das leis de um determinado
estado, geralmente é necessário registrar doações acima de um determinado valor.
O que é: Licenças ou registros profissionais são repositórios de informações que contêm
listas de membros e outras informações relacionadas para indivíduos que obtiveram
uma licença específica ou alguma medida de afiliação específica dentro de uma
comunidade.
Por que você faria isso: Informações sobre licenças profissionais poderiam revelar
informações úteis relacionadas a um indivíduo. Essas informações podem ser usadas
para validar a confiabilidade de um indivíduo (eles realmente possuem uma certificação
específica conforme afirmam) ou como parte da análise de redes sociais para ajudar a
estabelecer conexões entre indivíduos e outras organizações. Também poderia ser usado
para engenharia social ou outros fins posteriormente no teste de penetração.
através de sites publicamente disponíveis. Normalmente, cada organização mantém seu
próprio registro de informações que podem estar disponíveis on-line ou podem exigir
etapas adicionais para serem coletadas.
Perfil de rede social (SocNet)
Vazamento de metadados (L2/L3)
Reconhecimento de localização por meio de metadados de fotos
Tom (L2/L3)
Resultado esperado: identificação subjetiva do tom utilizado nas comunicações –
agressivo, passivo, atraente, vendedor, elogioso, dissimulado, condescendente,
arrogância, elitista, oprimido, líder, seguidor, imitador, etc…
Frequência (L2/L3)
Resultado esperado: Identificação da frequência de publicações (uma vez por
hora/dia/semana, etc…). Além disso - hora do dia/semana em que as comunicações são
propensas a acontecer.
Consciência de localização (L2/L3)
Mapeie o histórico de localização da pessoa perfilada a partir de diversas fontes, seja
por meio de interação direta com aplicativos e redes sociais, seja por meio de
participação passiva por meio de metadados de fotos.
Aplicativos de mapas do Bing
Quadrangular
Latitude do Google
Yelp
Gowalla
Presença nas redes sociais (L1/L2/L3)
Verifique a conta/presença de mídia social do alvo (L1). E fornecer análise detalhada
(L2/L3)
Presença na Internet
Endereço de e-mail (L1)
O que é isso? Os endereços de e-mail são os IDs das caixas de correio públicas dos
usuários.
Por que você faria isso? A coleta ou pesquisa de endereços de e-mail é importante
porque serve a vários propósitos - fornece um formato de identificação de usuário
provável que pode posteriormente ser acessado por força bruta, mas o mais importante é
que ajuda a enviar spams direcionados e até mesmo para bots automatizados. Esses e-
mails de spam podem conter explorações, malware, etc. e podem ser endereçados com
conteúdo específico especialmente para um usuário.
Como você faria isso? Os endereços de e-mail podem ser pesquisados e extraídos de
vários sites, grupos, blogs, fóruns, portais de redes sociais, etc. Esses endereços de e-
mail também estão disponíveis em vários sites de suporte técnico. Existem ferramentas
de colheita e spider para realizar pesquisas de endereços de e-mail mapeados para um
determinado domínio (se necessário).
Alças/apelidos pessoais (L1)
Nomes de domínio pessoais registrados (L1/L2)
IPs/Netblocks estáticos atribuídos (L1/L2)
Localização física
Localização física
Você pode derivar a localização física do alvo
Pegada móvel
Número de telefone (L1/L2/L3)
Tipo de dispositivo (L1/L2/L3)
Usar (L1/L2/L3)
Aplicativos instalados (L1/L2/L3)
Proprietário/administrador (L1/L2/L3)
Informações "Para pagamento"
Verificação em segundo plano
Para pagamento vinculado
LEXIS/NEXIS
Reunião secreta
Corporativo
Reunião no local
Selecionar locais específicos para coleta no local e, em seguida, realizar o
reconhecimento ao longo do tempo (geralmente pelo menos 2 a 3 dias para garantir
padrões). Os seguintes elementos são procurados ao realizar a coleta de inteligência no
local:
Inspeções de segurança física
Varredura sem fio/varredura de frequência RF
Inspeção de treinamento de comportamento de funcionários
Instalações acessíveis/adjacentes (espaços compartilhados)
Mergulhar na lixeira
Tipos de equipamentos em uso
Reunião externa
Identificar locais externos e sua importância/relação com a organização. Esses são
locais lógicos e físicos, conforme abaixo:
Locais de data centers
Provisionamento/provedor de rede
HUMINT
A inteligência humana complementa a coleta mais passiva do ativo, pois fornece
informações que não poderiam ter sido obtidas de outra forma, além de adicionar
perspectivas mais “pessoais” ao quadro de inteligência (sentimentos, história, relações
entre indivíduos-chave, “atmosfera”, etc. ...)
A metodologia de obtenção da inteligência humana envolve sempre interação direta –
seja física, seja verbal. A coleta deve ser feita sob uma identidade presumida, que seria
criada especificamente para alcançar a exposição ideal de informações e cooperação do
ativo em questão.
Além disso, a recolha de informações sobre alvos mais sensíveis pode ser realizada
utilizando apenas observação - mais uma vez, quer fisicamente no local, quer através de
meios electrónicos/remotos (CCTV, webcams, etc...). Isso geralmente é feito para
estabelecer padrões de comportamento (como frequência de visitas, código de
vestimenta, vias de acesso, locais-chave que podem fornecer acesso adicional, como
cafeterias).
Resultados
Funcionários-chave
Parceiros/Fornecedores
Engenharia social
Pegada
O QUE É: A recolha externa de informação, também conhecida comofootprinting, é
uma fase de recolha de informação que consiste na interação com o target de forma a
obter informação numa perspetiva externa à organização.
POR QUE: Muitas informações podem ser coletadas interagindo com os alvos. Ao
investigar um serviço ou dispositivo, muitas vezes você pode criar cenários nos quais
ele pode receber impressões digitais ou, mais simplesmente, pode ser adquirido um
banner que identificará o dispositivo. Esta etapa é necessária para coletar mais
informações sobre seus alvos. Seu objetivo, após esta seção, é uma lista priorizada de
alvos.
Pegada Externa
Identificar intervalos externos do cliente
Um dos principais objetivos da coleta de inteligência durante um teste de penetração é
determinar os hosts que estarão no escopo. Existem várias técnicas que podem ser
usadas para identificar sistemas, incluindo o uso de pesquisas reversas de DNS, bruting
de DNS, pesquisas WHOIS nos domínios e intervalos. Essas técnicas e outras estão
documentadas abaixo.
Reconhecimento Passivo
Pesquisas WHOIS
Para a pegada externa, primeiro precisamos determinar qual dos servidores WHOIS
contém as informações que procuramos. Dado que devemos saber o TLD do domínio de
destino, basta localizar o Registrador no qual o domínio de destino está registrado.
As informações WHOIS são baseadas em uma hierarquia em árvore. ICANN (IANA) é
o registro oficial para todos os TLDs e é um excelente ponto de partida para todas as
consultas manuais de WHOIS.
ICANN - http://www.icann.org
IANA - http://www.iana.com
NRO - http://www.nro.net
AFRINIC - http://www.afrinic.net
APNIC - http://www.apnic.net
ARIN - http://ws.arin.net
LACNIC - http://www.lacnic.net
MADURO - http://www.ripe.net
Depois que o Registrador apropriado for consultado, poderemos obter as informações
do Registrante. Existem vários sites que oferecem informações WHOIS; entretanto, para
obter precisão na documentação, você precisa usar apenas o Registrador apropriado.
InterNIC - http://www.internic.net/ http://www.internic.net ]
Normalmente, um simples whois contra o ARIN irá encaminhá-lo para o registrador
correto.
Óculos BGP
É possível identificar o Autonomous System Number (ASN) para redes que participam
do Border Gateway Protocol (BGP). Como os caminhos das rotas BGP são anunciados
em todo o mundo, podemos encontrá-los usando um espelho BGP4 e BGP6.
BGP4 - http://www.bgp4.as/looking-glasses
BPG6 - http://lg.he.net/
Pegada Ativa
Varredura de porta
As técnicas de varredura de portas variam de acordo com o tempo disponível para o
teste e a necessidade de ser furtivo. Se não houver conhecimento dos sistemas, uma
varredura rápida de ping poderá ser usada para identificar os sistemas. Além disso, uma
varredura rápida sem verificação de ping (-PN no nmap) deve ser executada para
detectar as portas disponíveis mais comuns. Quando isso for concluído, uma verificação
mais abrangente poderá ser executada. Alguns testadores verificam apenas portas TCP
abertas, certifique-se de verificar também o UDP. O
documento http://nmap.org/nmap_doc.html detalha os tipos de varredura de
porta. Nmap ("Network Mapper") é o padrão de fato para auditoria/varredura de rede. O
Nmap roda em Linux e Windows.
Você pode encontrar mais informações sobre o uso do Nmap para esse fim na Diretriz
Técnica do PTES
O Nmap tem dezenas de opções disponíveis. Como esta seção trata da varredura de
portas, nos concentraremos nos comandos necessários para executar esta tarefa. É
importante observar que os comandos utilizados dependem principalmente do tempo e
do número de hosts que estão sendo verificados. Quanto mais hosts ou menos tempo
você tiver para realizar essas tarefas, menos interrogaremos o host. Isto ficará evidente à
medida que continuarmos a discutir as opções.
O IPv6 também deve ser testado.
Agarrando banner
Banner Grabbing é uma técnica de enumeração usada para coletar informações sobre
sistemas de computador em uma rede e os serviços que executam suas portas abertas. A
captura de banner é usada para identificar na rede a versão dos aplicativos e do sistema
operacional que o host de destino está executando.
A captura de banner geralmente é realizada em Hyper Text Transfer Protocol (HTTP),
File Transfer Protocol (FTP) e Simple Mail Transfer Protocol (SMTP); portas 80, 21 e
25, respectivamente. As ferramentas comumente usadas para capturar banners são
Telnet, nmap e Netcat.
Varreduras SNMP
As varreduras SNMP também são realizadas, pois oferecem toneladas de informações
sobre um sistema específico. O protocolo SNMP é um protocolo sem estado e orientado
a datagramas. Infelizmente, os servidores SNMP não respondem a solicitações com
cadeias de comunidade inválidas e o protocolo UDP subjacente não informa de forma
confiável portas UDP fechadas. Isso significa que "sem resposta" de um endereço IP
investigado pode significar um dos seguintes:
máquina inacessível
Servidor SNMP não está em execução
sequência de comunidade inválida
o datagrama de resposta ainda não chegou
Transferências de zona
A transferência de zona DNS, também conhecida como AXFR, é um tipo de transação
DNS. É um mecanismo projetado para replicar os bancos de dados que contêm dados
DNS em um conjunto de servidores DNS. A transferência de zona vem em dois sabores,
completa (AXFR) e incremental (IXFR). Existem inúmeras ferramentas disponíveis
para testar a capacidade de realizar uma transferência de zona DNS. As ferramentas
comumente usadas para realizar transferências de zona são Host, Dig e Nmap.
Recuperação de SMTP
A devolução de SMTP, também chamada de Relatório/Recibo de Não Entrega (NDR),
uma mensagem de Notificação de Status de Entrega (DSN) (com falha), uma
Notificação de Não Entrega (NDN) ou simplesmente uma devolução, é uma mensagem
de correio eletrônico automatizada de um sistema de correio informando o remetente de
outra mensagem sobre um problema de entrega. Isso pode ser usado para ajudar um
invasor a identificar o servidor SMTP, pois as informações do servidor SMTP, incluindo
software e versões, podem ser incluídas em uma mensagem devolvida.
Isso pode ser feito simplesmente criando um endereço falso dentro do domínio do
alvo. Por exemplo, asDFADSF_garbage_address@target.com poderia ser usado para
testar target.com. O Gmail oferece acesso total aos cabeçalhos, tornando-o uma escolha
fácil para os testadores.
Descoberta de DNS
A descoberta de DNS pode ser realizada observando os registros WHOIS do servidor de
nomes oficial do domínio. Além disso, as variações do nome de domínio principal
devem ser verificadas e o site deve ser verificado em busca de referências a outros
domínios que possam estar sob o controle do alvo.
DNS direto/reverso
O DNS reverso pode ser usado para obter nomes de servidores válidos em uso em uma
organização. Há uma ressalva de que ele deve ter um registro DNS PTR (reverso) para
resolver um nome de um endereço IP fornecido. Se resolver, os resultados serão
retornados. Isso geralmente é realizado testando o servidor com vários endereços IP
para ver se ele retorna algum resultado.
Força bruta de DNS
Depois de identificar todas as informações associadas ao(s) domínio(s) cliente(s), agora
é hora de começar a consultar o DNS. Como o DNS é usado para mapear endereços IP
para nomes de host e vice-versa, queremos ver se ele está configurado de forma
insegura. Procuraremos usar o DNS para revelar informações adicionais sobre o
cliente. Uma das configurações incorretas mais graves envolvendo o DNS é permitir
que os usuários da Internet realizem uma transferência de zona DNS. Existem várias
ferramentas que podemos usar para enumerar DNS, não apenas para verificar a
capacidade de realizar transferências de zona, mas também para descobrir
potencialmente nomes de host adicionais que não são comumente conhecidos.
Descoberta de aplicativos da Web
Identificar aplicações web fracas pode ser uma atividade particularmente frutífera
durante um teste de penetração. Coisas a serem observadas incluem aplicativos OTS
que foram configurados incorretamente, aplicativos OTS que possuem funcionalidade
de plug-in (os plug-ins geralmente contêm código mais vulnerável do que o aplicativo
base) e aplicativos personalizados. Impressões digitais de aplicativos da Web, como
WAFP, podem ser usadas aqui com grande efeito.
Detecção e enumeração de hosts virtuais
Os servidores Web geralmente hospedam vários hosts “virtuais” para consolidar a
funcionalidade em um único servidor. Se vários servidores apontarem para o mesmo
endereço DNS, eles poderão estar hospedados no mesmo servidor. Ferramentas como a
pesquisa do MSN podem ser usadas para mapear um endereço IP para um conjunto de
hosts virtuais.
Estabelecer lista de alvos externos
Uma vez concluídas as atividades acima, uma lista de usuários, e-mails, domínios,
aplicações, hosts e serviços deverá ser compilada.
Mapeando versões
A verificação de versão é uma maneira rápida de identificar informações do
aplicativo. Até certo ponto, as versões dos serviços podem ter impressões digitais
usando o nmap, e as versões dos aplicativos da web muitas vezes podem ser coletadas
observando-se a origem de uma página arbitrária.
Identificando níveis de patch
Para identificar internamente o nível de patch dos serviços, considere usar um software
que irá interrogar o sistema em busca de diferenças entre versões. Credenciais podem
ser utilizadas para esta fase do teste de penetração, desde que o cliente concorde. Os
scanners de vulnerabilidade são particularmente eficazes na identificação remota de
níveis de patch, sem credenciais.
Procurando por aplicativos da web fracos
Identificar aplicações web fracas pode ser uma atividade particularmente frutífera
durante um teste de penetração. Coisas a serem observadas incluem aplicativos OTS
que foram configurados incorretamente, aplicativos OTS que possuem funcionalidade
de plug-in (os plug-ins geralmente contêm código mais vulnerável do que o aplicativo
base) e aplicativos personalizados. Impressões digitais de aplicativos da Web, como
WAFP, podem ser usadas aqui com grande efeito.
Identificar limite de bloqueio

Identificar o limite de bloqueio de um serviço de autenticação permitirá garantir que
seus ataques de força bruta não bloqueiem intencionalmente usuários válidos durante
seus testes. Identifique todos os serviços de autenticação diferentes no ambiente e teste
uma conta única e inócua para bloqueio. Freqüentemente, de 5 a 10 tentativas de uma
conta válida são suficientes para determinar se o serviço bloqueará o acesso dos
usuários.
Pegada Interna
Reconhecimento Passivo
Se o testador tiver acesso à rede interna, a detecção de pacotes poderá fornecer uma
grande quantidade de informações. Use técnicas como as implementadas em p0f para
identificar sistemas.
Identifique os intervalos internos do cliente
Ao realizar testes internos, primeiro enumere sua sub-rede local e, muitas vezes, você
poderá extrapolar daí para outras sub-redes, modificando ligeiramente o endereço. Além
disso, uma olhada na tabela de roteamento de um host interno pode ser particularmente
reveladora. Abaixo estão algumas técnicas que podem ser usadas.
Os servidores DHCP podem ser uma fonte potencial não apenas de informações locais,
mas também de intervalos de IP remotos e detalhes de hosts importantes. A maioria dos
servidores DHCP fornecerá um endereço de gateway IP local, bem como o endereço dos
servidores DNS e WINS. Em redes baseadas em Windows, os servidores DNS tendem a
ser controladores de domínio do Active Directory e, portanto, alvos de interesse.
Reconhecimento Ativo
O reconhecimento ativo interno deve conter todos os elementos de um reconhecimento
externo e, além disso, deve focar na funcionalidade da intranet, como:
Serviços de diretório (Active Directory, Novell, Sun, etc...)
Sites de intranet que fornecem funcionalidade de negócios
Aplicações empresariais (ERP, CRM, Contabilidade, etc...)
Identificação de segmentos sensíveis da rede (contabilidade, I&D, marketing, etc...)
Mapeamento de acesso a redes de produção (datacenters)
Infraestrutura VoIP
Provisionamento de autenticação (kerberos, tokens de cookies, etc...)
Gerenciamento de proxy e acesso à Internet
Identificar mecanismos de proteção

Os seguintes elementos devem ser identificados e mapeados de acordo com o
local/grupo/pessoas relevantes no escopo. Isto permitirá a aplicação correta da pesquisa
e exploração de vulnerabilidades a serem utilizadas durante a execução do ataque real -
maximizando assim a eficiência do ataque e minimizando a taxa de detecção.
Proteções baseadas em rede
Filtros de pacotes "simples"
Dispositivos de modelagem de tráfego
Sistemas DLP
Criptografia/túnel
Proteções baseadas em host
Proteções de pilha/heap
Lista de permissões de aplicativos
AV/Filtragem/Análise Comportamental
Sistemas DLP
Proteções em nível de aplicativo

Identificar proteções de aplicativos
Opções de codificação
Potenciais avenidas de desvio
Páginas na lista de permissões
Proteções de armazenamento
HBA – Nível de Host
Mascaramento LUN
Controlador de armazenamento
Segredo iSCSI CHAP
Proteções do usuário
Software de filtragem AV/Spam
Configuração de SW que limita a explorabilidade pode ser considerada antispam/antiAV
Conteúdo
1Em geral
1.1Processo de modelagem de ameaças de alto nível
1.2Exemplo
1.3Ferramentas de modelagem de alto nível
2Análise de Ativos Empresariais
2.1Dados Organizacionais
2.1.1Políticas, Planos e Procedimentos
2.1.2Informações sobre o produto (por exemplo, segredos comerciais, dados de P&D)
2.1.3Informações de marketing (planos, roteiros, etc.)
2.1.4Informações financeiras (por exemplo, contas bancárias, de crédito, patrimoniais)
2.1.5Informação técnica
2.1.6Dados de funcionários
2.1.7Dados do cliente
2.2Ativos Humanos
3Análise de Processos de Negócios
3.1Processo de suporte à infraestrutura técnica
3.2Processo de suporte de ativos de informação
3.3Processo de apoio a ativos humanos
3.4Integração de terceiros e/ou uso de/por processo
4Agentes de ameaças/análise da comunidade
4.1Funcionários
4.2Gestão (Executiva, média)
5Análise de capacidade de ameaças
5.1Análise das ferramentas em uso
5.2Disponibilidade para explorações/cargas relevantes
5.3Mecanismos de comunicação
5.4Acessibilidade
6Modelagem de Motivação
7Encontrar notícias relevantes de organizações comparáveis sendo comprometidas
Em geral
Esta seção define uma abordagem de modelagem de ameaças necessária para a
execução correta de um teste de penetração. A norma não utiliza um modelo específico,
mas exige que o modelo utilizado seja consistente em termos de representação de
ameaças, suas capacidades, suas qualificações de acordo com a organização que está
sendo testada e a capacidade de ser aplicado repetidamente em testes futuros com o
mesmos resultados.
O padrão se concentra em dois elementos principais da modelagem de ameaças
tradicional: ativos e atacante (comunidade/agente de ameaça). Cada um deles é dividido
respectivamente em ativos e processos de negócios e em comunidades de ameaças e
suas capacidades.
No mínimo, todos os quatro elementos devem ser claramente identificados e
documentados em todos os testes de penetração.
Ao modelar o lado do invasor, além da comunidade de ameaças (que é principalmente
semântica e pode ser vinculada à análise SWOT de negócios da organização) e das
capacidades (que são principalmente técnicas), aspectos adicionais de modelagem de
motivação também devem ser fornecidos. Estes pontos adicionais têm essencialmente
em conta o valor dos diferentes ativos disponíveis no target e são combinados com o
custo de aquisição do mesmo. Como modelo complementar, a modelagem de impacto
também deve ser realizada para a organização, a fim de fornecer uma visão mais precisa
do “e se?” cenário que envolve o evento de perda de cada um dos ativos
identificados. Isto deve ter em conta o valor “líquido” do activo, o seu valor intrínseco e
outros custos indirectamente incorridos associados a um evento de perda.
A fase de modelagem de ameaças de qualquer envolvimento de teste de penetração é
crítica tanto para os testadores quanto para a organização. Ele fornece clareza quanto ao
apetite e priorização de riscos da organização (quais ativos são mais importantes que
outros? quais comunidades de ameaças são mais relevantes que outras?). Além disso,
permite que o testador se concentre em entregar um envolvimento que emule de perto as
ferramentas, técnicas, capacidades, acessibilidade e perfil geral do invasor, mantendo
em mente quais são os alvos reais dentro da organização, de modo que os controles e
processos mais relevantes e a infraestrutura são postas à prova, em vez de uma lista de
inventário de elementos de TI. O modelo de ameaça deve ser construído em
coordenação com a organização que está sendo testada sempre que possível, e mesmo
em uma situação de caixa preta completa, onde o testador não tem nenhuma informação
prévia sobre a organização, o testador deve criar um modelo de ameaça baseado na
visão do invasor. em combinação com OSINT relacionado à organização alvo.
O modelo deve ser claramente documentado e entregue como parte do relatório final,
pois as conclusões do relatório farão referência ao modelo de ameaça, a fim de criar
uma relevância mais precisa e uma pontuação de risco específica da organização (em
vez de uma avaliação técnica genérica). um).
Processo de modelagem de ameaças de alto nível
Reúna documentação relevante
Identificar e categorizar ativos primários e secundários
Identificar e categorizar ameaças e comunidades de ameaças
Mapeie comunidades de ameaças em relação a ativos primários e secundários
Exemplo
À luz de uma avaliação PTES, a aplicação CRM alojada internamente pode estar
abrangida. As informações do cliente armazenadas no banco de dados back-end são um
ativo primário facilmente identificável, pois estão diretamente vinculadas à aplicação no
escopo. No entanto, ao rever a concepção técnica do servidor de base de dados, também
pode ser identificado que a base de dados de RH armazenada no mesmo servidor de
base de dados back-end é um activo secundário. Um invasor pode usar o aplicativo
CRM como um trampolim para obter informações dos funcionários. Num exercício
básico de modelação de ameaças, certas comunidades de ameaças podem ser
identificadas como não relevantes quando mapeadas para a aplicação CRM, mas ao
identificar os activos secundários o cenário de ameaças muda subitamente.
Ferramentas de modelagem de alto nível
Há uma variedade de ferramentas disponíveis para identificar alvos e mapear vetores de
ataque. Normalmente, eles se concentram nos ativos de negócios (quais sistemas visar)
e nos processos de negócios (como atacá-los). Dependendo do trabalho, a equipe de
testes de penetração pode realizar esses exercícios sem nenhuma contribuição do
cliente; ou podem passar muito tempo com as partes interessadas do cliente
identificando alvos de interesse. Ferramentas com foco em ativos de negócios
geralmente exigem informações quantitativas para descrever a importância do teste de
cada alvo potencial. As informações também podem ser qualitativas, como uma
descrição feita pelo CIO do cliente de que um sistema é de missão crítica. Ferramentas
focadas em processos de negócios, fluxos de informações e arquitetura técnica são
usadas para identificar potenciais vetores de ataque e escolher quais têm maior
probabilidade de sucesso ou de uso por uma determinada classe de adversários.
Análise de Ativos Empresariais
Durante a análise de ativos de negócios, parte do exercício de modelagem de ameaças, é
adotada uma visão centrada em ativos de todos os ativos e dos processos de negócios
que os suportam, incluídos no escopo. Ao analisar a documentação recolhida e
entrevistar pessoal relevante dentro da organização, o pentester é capaz de identificar os
ativos que têm maior probabilidade de serem alvo de um invasor, qual é o seu valor e
qual seria o impacto da sua perda (parcial).
Dados Organizacionais
Políticas, Planos e Procedimentos
Políticas, planos e procedimentos internos definem como a organização faz
negócios. Esses documentos são de particular interesse, pois podem ajudar a identificar
funções-chave dentro de uma organização e processos de negócios críticos que mantêm
uma empresa funcionando.
Informações sobre o produto (por exemplo, segredos comerciais, dados de P&D)
As informações relacionadas ao produto incluem quaisquer patentes, segredos
comerciais, planos futuros, código-fonte, sistemas de suporte que afetem diretamente o
valor de mercado do produto, algoritmos e qualquer outra informação que a organização
considere um fator-chave para o sucesso comercial de tal produto.
Informações de marketing (planos, roteiros, etc.)
Planos de marketing para promoções, lançamentos, mudanças de produtos,
posicionamento, parcerias, fornecedores terceirizados, planos de negócios relacionados
a atividades dentro ou fora da organização. Além disso, dados relacionados a relações
públicas, como detalhes de parceiros, repórteres, empresa de consultoria e qualquer
correspondência com essas entidades, também são considerados um alvo muito
procurado.
Informações financeiras (por exemplo, contas bancárias, de crédito, patrimoniais)
As informações financeiras costumam ser algumas das informações mais protegidas que
uma organização possui. Essas informações podem incluir informações de contas
bancárias, informações de contas de cartão de crédito e/ou números de cartão de crédito
e contas de investimento, entre outras.
Informação técnica
As informações técnicas sobre a organização e suas operações são de interesse
exclusivo para o testador de penetração. Muitas vezes, essas informações não são o
resultado esperado de um teste de penetração; no entanto, facilitam o processo de teste,
fornecendo informações valiosas para outras áreas; as informações de projeto de
infraestrutura podem fornecer dados valiosos para o processo de coleta de inteligência.
Informações sobre projeto de infraestrutura
As informações relacionadas ao projeto de infraestrutura referem-se a todas as
principais tecnologias e instalações usadas para administrar a organização. Projetos de
construção, diagramas técnicos de fiação e conectividade, projetos de equipamentos de
computação/rede e processamento de dados em nível de aplicativo são considerados
informações de projeto de infraestrutura.
Informações de configuração do sistema
As informações de configuração do sistema incluem documentação de linha de base de
configuração, listas de verificação de configuração e procedimentos de proteção,
informações de política de grupo, imagens de sistema operacional, inventários de
software, etc. Essas informações podem ajudar na descoberta de vulnerabilidades (como
por meio do conhecimento de erros de configuração ou instalações de software
desatualizadas).
Credenciais de conta de usuário
As credenciais da conta do utilizador ajudam a facilitar o acesso ao sistema de
informação, a um nível não privilegiado, desde que exista um meio de autenticação (por
exemplo, VPN, portal web, etc.).
Credenciais de conta de usuário privilegiado
As credenciais de conta de utilizador privilegiadas ajudam a facilitar o acesso ao
sistema de informação, num nível elevado de acesso, desde que exista um meio de
autenticação (ex. VPN, portal web, etc.). A obtenção de credenciais de conta de usuário
privilegiadas muitas vezes leva ao comprometimento do sistema de informação que está
sendo testado.
Dados de funcionários
Aqui, os dados dos funcionários estão sendo analisados, pois quaisquer dados que
possam ter um efeito DIRETO na organização são obtidos ou comprometidos por um
invasor. As organizações que têm de aderir a alguma conformidade que imponha multas
à perda ou exposição de tais dados são candidatas óbvias a esse efeito de perda
direta. Além disso, as organizações cujos funcionários podem ser considerados ativos
críticos também podem estar sujeitas a esse escrutínio (órgãos governamentais
específicos, funcionários/departamentos especializados relacionados a segredos
comerciais, etc.). A lista a seguir fornece exemplos de domínios de informações de
dados pessoais que podem ser considerados ativos de negócios para a modelagem de
ameaças.
Números de identificação nacional (SSNs, etc.)
Informações de identificação pessoal (PII)
Informações de saúde protegidas (PHI)
Informações financeiras (por exemplo, banco, contas de crédito)
Dados do cliente
Assim como os dados dos funcionários, os dados dos clientes são considerados um ativo
comercial no processo de modelagem de ameaças quando tais informações incorrerão
em perdas diretas/indiretas para a organização. Além da necessidade regulatória/de
conformidade (com base em multas), um fator adicional entra em jogo aqui quando tais
dados podem ser usados para conduzir fraudes, onde a organização pode ser
responsabilizada ou processada pelas perdas relacionadas à fraude (com base na perda
as informações do cliente que permitiram a ocorrência da fraude). A lista a seguir
fornece exemplos de domínios de informações que podem conter dados relevantes do
cliente e devem ser considerados ativos de negócios para fins de modelagem de
ameaças.
Números de identificação nacional (SSN, etc.)
Contas financeiras (por exemplo, contas bancárias, de crédito, patrimoniais)
Dados do fornecedor
Informações relacionadas a fornecedores que sejam consideradas críticas para a
organização (como fabricantes de componentes críticos, acordos com fornecedores que
possam fazer parte de segredo comercial, análise de custos de componentes fornecidos),
bem como quaisquer dados que possam ser usados para afetar o negócio as operações da
organização por meio de seus fornecedores são consideradas um ativo comercial.
Dados do parceiro
Informações da conta de serviço “Cloud”
Ativos Humanos
Ao identificar os ativos humanos numa organização, temos de lembrar que o contexto é
que esses ativos fazem parte de um esforço maior para comprometer a
organização. Como tal, os ativos humanos identificados como ativos empresariais são
aqueles que poderiam ser aproveitados para divulgar informações, manipulados para
tomar decisões ou ações que afetariam negativamente a organização ou permitiriam que
um invasor a comprometesse ainda mais. Os activos humanos não são necessariamente
os mais elevados na hierarquia empresarial, mas são mais frequentemente pessoal-chave
relacionado com activos empresariais previamente identificados, ou que estão em
posições que permitem o acesso a esses activos. Esta lista também pode incluir
funcionários que normalmente não estariam associados ao acesso a ativos restritos da
empresa, mas que podem estar em posição de conceder acesso físico a uma empresa que
facilite uma violação de segurança ou de procedimento. A lista a seguir fornece alguns
exemplos de tais ativos e deve ser adaptada à organização que está sendo testada.
Gestão executiva
Assistentes Executivos
Administração média
Assistentes administrativos
Líderes técnicos/de equipe
Engenheiros
Técnicos
Recursos Humanos
Análise de Processos de Negócios
Uma empresa não é uma empresa se não dá dinheiro. A forma como isso acontece é
fazendo com que as matérias-primas ou o conhecimento passem por vários processos
para melhorá-los e criar valor agregado. Isso gera receita. Os processos de negócios e os
ativos (pessoas, tecnologia, dinheiro) que os apoiam formam cadeias de valor. Ao
mapear estes processos, identificar os processos críticos versus não críticos e,
eventualmente, encontrar falhas nos mesmos, somos capazes de compreender como o
negócio funciona, o que lhes dá dinheiro e, eventualmente, como comunidades de
ameaças específicas podem fazê-los perder dinheiro.
Na análise de processos de negócios diferenciamos entre processos de negócios críticos
e processos não críticos. Para cada categoria a análise é a mesma e leva em conta os
mesmos elementos. A principal diferença está na ponderação atribuída à ameaça de um
processo de negócios crítico em oposição a um processo não crítico. No entanto, é
imperativo lembrar que uma agregação de alguns processos de negócios não críticos
pode ser combinada em um cenário que forma essencialmente uma falha crítica dentro
de um elemento/processo. Tais cenários de ameaças também devem ser identificados
nesta fase e mapeados para uso posterior no teste de penetração.
Processo de suporte à infraestrutura técnica
Como os processos de negócio são normalmente suportados por infra-estruturas de TI
(como redes de computadores, capacidade de processamento, PCs para introdução de
informação e gestão do processo de negócio, etc...), todos esses elementos devem ser
identificados e mapeados. Esse mapeamento deve ser suficientemente claro para ser
utilizado posteriormente no processo, ao traduzir o modelo de ameaça para o
mapeamento e exploração de vulnerabilidades.
Processo de suporte de ativos de informação
Ao contrário da infra-estrutura técnica, os activos de informação são bases de
conhecimento existentes na organização que são utilizadas quer como referência, quer
como material de apoio (tomada de decisão, jurídico, marketing, etc...). Esses activos
são geralmente já identificados no processo empresarial e devem ser mapeados
juntamente com a infra-estrutura técnica, bem como qualquer infra-estrutura técnica
adicional que suporte os próprios activos de informação.
Processo de apoio a ativos humanos
A identificação dos RH envolvidos no processo de negócio deve ser feita em conjunto
com a própria análise do processo (documentada ou não), e todas as pessoas que tenham
algum tipo de envolvimento (mesmo que não esteja relacionado com um ativo de
informação específico ou um elemento de infraestrutura técnica) deve ser documentado
e mapeado no processo. Esses ativos de RH geralmente fazem parte de um subprocesso
de aprovação, de um subprocesso de verificação ou mesmo de uma referência (como
aconselhamento jurídico). Estes tipos de activos (especialmente aqueles que não têm
qualquer relação com activos de informação ou infra-estrutura técnica) seriam
posteriormente mapeados para atacar vectores que são de natureza mais social do que
técnica.
Integração de terceiros e/ou uso de/por processo
Semelhante aos recursos humanos que apoiam o processo, qualquer terceiro que tenha
algum envolvimento com o processo de negócios também deve ser mapeado. Esta
categoria pode ser difícil de mapear, pois pode conter tanto ativos humanos quanto
informações/técnicos (como um provedor de SaaS).
Agentes de ameaças/análise da comunidade
Ao definir as comunidades e agentes de ameaça relevantes, uma identificação clara da
ameaça deve ser fornecida em termos de localização (interna/externa à organização), a
comunidade específica dentro da localização e qualquer informação adicional relevante
que possa ajudar no estabelecimento de capacidades /perfil de motivação para o
agente/comunidade específico. Sempre que possível, devem ser identificados agentes
específicos. Caso contrário, uma comunidade mais geral deverá ser delineada,
juntamente com qualquer material de apoio e inteligência. Alguns exemplos de
classificações de agente de ameaça/comunidade são:
interno Externo
Funcionários Parceiros de negócios
Gestão (executiva, intermediária) Concorrentes
Administradores (rede, sistema, Empreiteiros

servidor)
Desenvolvedores Fornecedores
Engenheiros Estados da nação
Técnicos Crime organizado
Contratantes (com seus usuários

Hacktivistas
externos)
Script Kiddies (hacking

Comunidade geral de usuários
recreativo/aleatório)
Suporte remoto
Conteúdo
1Em geral
1.1Processo de modelagem de ameaças de alto nível
1.2Exemplo
1.3Ferramentas de modelagem de alto nível
2Análise de Ativos Empresariais
2.1Dados Organizacionais
2.1.1Políticas, Planos e Procedimentos
2.1.2Informações sobre o produto (por exemplo, segredos comerciais, dados de P&D)
2.1.3Informações de marketing (planos, roteiros, etc.)
2.1.4Informações financeiras (por exemplo, contas bancárias, de crédito, patrimoniais)
2.1.5Informação técnica
2.1.6Dados de funcionários
2.1.7Dados do cliente
2.2Ativos Humanos
3Análise de Processos de Negócios
3.1Processo de suporte à infraestrutura técnica
3.2Processo de suporte de ativos de informação
3.3Processo de apoio a ativos humanos
3.4Integração de terceiros e/ou uso de/por processo
4Agentes de ameaças/análise da comunidade
4.1Funcionários
4.2Gestão (Executiva, média)
5Análise de capacidade de ameaças
5.1Análise das ferramentas em uso
5.2Disponibilidade para explorações/cargas relevantes
5.3Mecanismos de comunicação
5.4Acessibilidade
6Modelagem de Motivação
7Encontrar notícias relevantes de organizações comparáveis sendo comprometidas
Em geral
Esta seção define uma abordagem de modelagem de ameaças necessária para a
execução correta de um teste de penetração. A norma não utiliza um modelo específico,
mas exige que o modelo utilizado seja consistente em termos de representação de
ameaças, suas capacidades, suas qualificações de acordo com a organização que está
sendo testada e a capacidade de ser aplicado repetidamente em testes futuros com o
mesmos resultados.
O padrão se concentra em dois elementos principais da modelagem de ameaças
tradicional: ativos e atacante (comunidade/agente de ameaça). Cada um deles é dividido
respectivamente em ativos e processos de negócios e em comunidades de ameaças e
suas capacidades.
No mínimo, todos os quatro elementos devem ser claramente identificados e
documentados em todos os testes de penetração.
Ao modelar o lado do invasor, além da comunidade de ameaças (que é principalmente
semântica e pode ser vinculada à análise SWOT de negócios da organização) e das
capacidades (que são principalmente técnicas), aspectos adicionais de modelagem de
motivação também devem ser fornecidos. Estes pontos adicionais têm essencialmente
em conta o valor dos diferentes ativos disponíveis no target e são combinados com o
custo de aquisição do mesmo. Como modelo complementar, a modelagem de impacto
também deve ser realizada para a organização, a fim de fornecer uma visão mais precisa
do “e se?” cenário que envolve o evento de perda de cada um dos ativos
identificados. Isto deve ter em conta o valor “líquido” do activo, o seu valor intrínseco e
outros custos indirectamente incorridos associados a um evento de perda.
A fase de modelagem de ameaças de qualquer envolvimento de teste de penetração é
crítica tanto para os testadores quanto para a organização. Ele fornece clareza quanto ao
apetite e priorização de riscos da organização (quais ativos são mais importantes que
outros? quais comunidades de ameaças são mais relevantes que outras?). Além disso,
permite que o testador se concentre em entregar um envolvimento que emule de perto as
ferramentas, técnicas, capacidades, acessibilidade e perfil geral do invasor, mantendo
em mente quais são os alvos reais dentro da organização, de modo que os controles e
processos mais relevantes e a infraestrutura são postas à prova, em vez de uma lista de
inventário de elementos de TI. O modelo de ameaça deve ser construído em
coordenação com a organização que está sendo testada sempre que possível, e mesmo
em uma situação de caixa preta completa, onde o testador não tem nenhuma informação
prévia sobre a organização, o testador deve criar um modelo de ameaça baseado na
visão do invasor. em combinação com OSINT relacionado à organização alvo.
O modelo deve ser claramente documentado e entregue como parte do relatório final,
pois as conclusões do relatório farão referência ao modelo de ameaça, a fim de criar
uma relevância mais precisa e uma pontuação de risco específica da organização (em
vez de uma avaliação técnica genérica). um).
Processo de modelagem de ameaças de alto nível
Reúna documentação relevante
Identificar e categorizar ativos primários e secundários
Identificar e categorizar ameaças e comunidades de ameaças
Mapeie comunidades de ameaças em relação a ativos primários e secundários
Exemplo
À luz de uma avaliação PTES, a aplicação CRM alojada internamente pode estar
abrangida. As informações do cliente armazenadas no banco de dados back-end são um
ativo primário facilmente identificável, pois estão diretamente vinculadas à aplicação no
escopo. No entanto, ao rever a concepção técnica do servidor de base de dados, também
pode ser identificado que a base de dados de RH armazenada no mesmo servidor de
base de dados back-end é um activo secundário. Um invasor pode usar o aplicativo
CRM como um trampolim para obter informações dos funcionários. Num exercício
básico de modelação de ameaças, certas comunidades de ameaças podem ser
identificadas como não relevantes quando mapeadas para a aplicação CRM, mas ao
identificar os activos secundários o cenário de ameaças muda subitamente.
Ferramentas de modelagem de alto nível
Há uma variedade de ferramentas disponíveis para identificar alvos e mapear vetores de
ataque. Normalmente, eles se concentram nos ativos de negócios (quais sistemas visar)
e nos processos de negócios (como atacá-los). Dependendo do trabalho, a equipe de
testes de penetração pode realizar esses exercícios sem nenhuma contribuição do
cliente; ou podem passar muito tempo com as partes interessadas do cliente
identificando alvos de interesse. Ferramentas com foco em ativos de negócios
geralmente exigem informações quantitativas para descrever a importância do teste de
cada alvo potencial. As informações também podem ser qualitativas, como uma
descrição feita pelo CIO do cliente de que um sistema é de missão crítica. Ferramentas
focadas em processos de negócios, fluxos de informações e arquitetura técnica são
usadas para identificar potenciais vetores de ataque e escolher quais têm maior
probabilidade de sucesso ou de uso por uma determinada classe de adversários.
Análise de Ativos Empresariais
Durante a análise de ativos de negócios, parte do exercício de modelagem de ameaças, é
adotada uma visão centrada em ativos de todos os ativos e dos processos de negócios
que os suportam, incluídos no escopo. Ao analisar a documentação recolhida e
entrevistar pessoal relevante dentro da organização, o pentester é capaz de identificar os
ativos que têm maior probabilidade de serem alvo de um invasor, qual é o seu valor e
qual seria o impacto da sua perda (parcial).
Dados Organizacionais
Políticas, Planos e Procedimentos
Políticas, planos e procedimentos internos definem como a organização faz
negócios. Esses documentos são de particular interesse, pois podem ajudar a identificar
funções-chave dentro de uma organização e processos de negócios críticos que mantêm
uma empresa funcionando.
Informações sobre o produto (por exemplo, segredos comerciais, dados de P&D)
As informações relacionadas ao produto incluem quaisquer patentes, segredos
comerciais, planos futuros, código-fonte, sistemas de suporte que afetem diretamente o
valor de mercado do produto, algoritmos e qualquer outra informação que a organização
considere um fator-chave para o sucesso comercial de tal produto.
Informações de marketing (planos, roteiros, etc.)
Planos de marketing para promoções, lançamentos, mudanças de produtos,
posicionamento, parcerias, fornecedores terceirizados, planos de negócios relacionados
a atividades dentro ou fora da organização. Além disso, dados relacionados a relações
públicas, como detalhes de parceiros, repórteres, empresa de consultoria e qualquer
correspondência com essas entidades, também são considerados um alvo muito
procurado.
Informações financeiras (por exemplo, contas bancárias, de crédito, patrimoniais)
As informações financeiras costumam ser algumas das informações mais protegidas que
uma organização possui. Essas informações podem incluir informações de contas
bancárias, informações de contas de cartão de crédito e/ou números de cartão de crédito
e contas de investimento, entre outras.
Informação técnica
As informações técnicas sobre a organização e suas operações são de interesse
exclusivo para o testador de penetração. Muitas vezes, essas informações não são o
resultado esperado de um teste de penetração; no entanto, facilitam o processo de teste,
fornecendo informações valiosas para outras áreas; as informações de projeto de
infraestrutura podem fornecer dados valiosos para o processo de coleta de inteligência.
Informações sobre projeto de infraestrutura
As informações relacionadas ao projeto de infraestrutura referem-se a todas as
principais tecnologias e instalações usadas para administrar a organização. Projetos de
construção, diagramas técnicos de fiação e conectividade, projetos de equipamentos de
computação/rede e processamento de dados em nível de aplicativo são considerados
informações de projeto de infraestrutura.
Informações de configuração do sistema
As informações de configuração do sistema incluem documentação de linha de base de
configuração, listas de verificação de configuração e procedimentos de proteção,
informações de política de grupo, imagens de sistema operacional, inventários de
software, etc. Essas informações podem ajudar na descoberta de vulnerabilidades (como
por meio do conhecimento de erros de configuração ou instalações de software
desatualizadas).
Credenciais de conta de usuário
As credenciais da conta do utilizador ajudam a facilitar o acesso ao sistema de
informação, a um nível não privilegiado, desde que exista um meio de autenticação (por
exemplo, VPN, portal web, etc.).
Credenciais de conta de usuário privilegiado
As credenciais de conta de utilizador privilegiadas ajudam a facilitar o acesso ao
sistema de informação, num nível elevado de acesso, desde que exista um meio de
autenticação (ex. VPN, portal web, etc.). A obtenção de credenciais de conta de usuário
privilegiadas muitas vezes leva ao comprometimento do sistema de informação que está
sendo testado.
Dados de funcionários
Aqui, os dados dos funcionários estão sendo analisados, pois quaisquer dados que
possam ter um efeito DIRETO na organização são obtidos ou comprometidos por um
invasor. As organizações que têm de aderir a alguma conformidade que imponha multas
à perda ou exposição de tais dados são candidatas óbvias a esse efeito de perda
direta. Além disso, as organizações cujos funcionários podem ser considerados ativos
críticos também podem estar sujeitas a esse escrutínio (órgãos governamentais
específicos, funcionários/departamentos especializados relacionados a segredos
comerciais, etc.). A lista a seguir fornece exemplos de domínios de informações de
dados pessoais que podem ser considerados ativos de negócios para a modelagem de
ameaças.
Números de identificação nacional (SSNs, etc.)
Informações financeiras (por exemplo, banco, contas de crédito)
Dados do cliente
Assim como os dados dos funcionários, os dados dos clientes são considerados um ativo
comercial no processo de modelagem de ameaças quando tais informações incorrerão
em perdas diretas/indiretas para a organização. Além da necessidade regulatória/de
conformidade (com base em multas), um fator adicional entra em jogo aqui quando tais
dados podem ser usados para conduzir fraudes, onde a organização pode ser
responsabilizada ou processada pelas perdas relacionadas à fraude (com base na perda
as informações do cliente que permitiram a ocorrência da fraude). A lista a seguir
fornece exemplos de domínios de informações que podem conter dados relevantes do
cliente e devem ser considerados ativos de negócios para fins de modelagem de
ameaças.
Números de identificação nacional (SSN, etc.)
Contas financeiras (por exemplo, contas bancárias, de crédito, patrimoniais)
Dados do fornecedor
Informações relacionadas a fornecedores que sejam consideradas críticas para a
organização (como fabricantes de componentes críticos, acordos com fornecedores que
possam fazer parte de segredo comercial, análise de custos de componentes fornecidos),
bem como quaisquer dados que possam ser usados para afetar o negócio as operações da
organização por meio de seus fornecedores são consideradas um ativo comercial.
Dados do parceiro
Informações da conta de serviço “Cloud”
Ativos Humanos
Ao identificar os ativos humanos numa organização, temos de lembrar que o contexto é
que esses ativos fazem parte de um esforço maior para comprometer a
organização. Como tal, os ativos humanos identificados como ativos empresariais são
aqueles que poderiam ser aproveitados para divulgar informações, manipulados para
tomar decisões ou ações que afetariam negativamente a organização ou permitiriam que
um invasor a comprometesse ainda mais. Os activos humanos não são necessariamente
os mais elevados na hierarquia empresarial, mas são mais frequentemente pessoal-chave
relacionado com activos empresariais previamente identificados, ou que estão em
posições que permitem o acesso a esses activos. Esta lista também pode incluir
funcionários que normalmente não estariam associados ao acesso a ativos restritos da
empresa, mas que podem estar em posição de conceder acesso físico a uma empresa que
facilite uma violação de segurança ou de procedimento. A lista a seguir fornece alguns
exemplos de tais ativos e deve ser adaptada à organização que está sendo testada.
Gestão executiva
Assistentes Executivos
Administração média
Assistentes administrativos
Líderes técnicos/de equipe
Engenheiros
Técnicos
Recursos Humanos
Análise de Processos de Negócios
Uma empresa não é uma empresa se não dá dinheiro. A forma como isso acontece é
fazendo com que as matérias-primas ou o conhecimento passem por vários processos
para melhorá-los e criar valor agregado. Isso gera receita. Os processos de negócios e os
ativos (pessoas, tecnologia, dinheiro) que os apoiam formam cadeias de valor. Ao
mapear estes processos, identificar os processos críticos versus não críticos e,
eventualmente, encontrar falhas nos mesmos, somos capazes de compreender como o
negócio funciona, o que lhes dá dinheiro e, eventualmente, como comunidades de
ameaças específicas podem fazê-los perder dinheiro.
Na análise de processos de negócios diferenciamos entre processos de negócios críticos
e processos não críticos. Para cada categoria a análise é a mesma e leva em conta os
mesmos elementos. A principal diferença está na ponderação atribuída à ameaça de um
processo de negócios crítico em oposição a um processo não crítico. No entanto, é
imperativo lembrar que uma agregação de alguns processos de negócios não críticos
pode ser combinada em um cenário que forma essencialmente uma falha crítica dentro
de um elemento/processo. Tais cenários de ameaças também devem ser identificados
nesta fase e mapeados para uso posterior no teste de penetração.
Processo de suporte à infraestrutura técnica
Como os processos de negócio são normalmente suportados por infra-estruturas de TI
(como redes de computadores, capacidade de processamento, PCs para introdução de
informação e gestão do processo de negócio, etc...), todos esses elementos devem ser
identificados e mapeados. Esse mapeamento deve ser suficientemente claro para ser
utilizado posteriormente no processo, ao traduzir o modelo de ameaça para o
mapeamento e exploração de vulnerabilidades.
Processo de suporte de ativos de informação
Ao contrário da infra-estrutura técnica, os activos de informação são bases de
conhecimento existentes na organização que são utilizadas quer como referência, quer
como material de apoio (tomada de decisão, jurídico, marketing, etc...). Esses activos
são geralmente já identificados no processo empresarial e devem ser mapeados
juntamente com a infra-estrutura técnica, bem como qualquer infra-estrutura técnica
adicional que suporte os próprios activos de informação.
Processo de apoio a ativos humanos
A identificação dos RH envolvidos no processo de negócio deve ser feita em conjunto
com a própria análise do processo (documentada ou não), e todas as pessoas que tenham
algum tipo de envolvimento (mesmo que não esteja relacionado com um ativo de
informação específico ou um elemento de infraestrutura técnica) deve ser documentado
e mapeado no processo. Esses ativos de RH geralmente fazem parte de um subprocesso
de aprovação, de um subprocesso de verificação ou mesmo de uma referência (como
aconselhamento jurídico). Estes tipos de activos (especialmente aqueles que não têm
qualquer relação com activos de informação ou infra-estrutura técnica) seriam
posteriormente mapeados para atacar vectores que são de natureza mais social do que
técnica.
Integração de terceiros e/ou uso de/por processo
Semelhante aos recursos humanos que apoiam o processo, qualquer terceiro que tenha
algum envolvimento com o processo de negócios também deve ser mapeado. Esta
categoria pode ser difícil de mapear, pois pode conter tanto ativos humanos quanto
informações/técnicos (como um provedor de SaaS).
Agentes de ameaças/análise da comunidade
Ao definir as comunidades e agentes de ameaça relevantes, uma identificação clara da
ameaça deve ser fornecida em termos de localização (interna/externa à organização), a
comunidade específica dentro da localização e qualquer informação adicional relevante
que possa ajudar no estabelecimento de capacidades /perfil de motivação para o
agente/comunidade específico. Sempre que possível, devem ser identificados agentes
específicos. Caso contrário, uma comunidade mais geral deverá ser delineada,
juntamente com qualquer material de apoio e inteligência. Alguns exemplos de
classificações de agente de ameaça/comunidade são:
Funcionários
Pessoas que trabalham diretamente para a empresa com contrato de meio período ou
período integral. Em geral, não são considerados como uma ameaça grave, uma vez que
a maioria deles depende da empresa para ganhar a vida e, assumindo que são bem
tratados, estão inclinados a proteger a empresa em vez de a prejudicar. Muitas vezes
envolvido em incidentes de perda de dados ou comprometimento acidental. Em casos
raros, podem ser motivados por terceiros para ajudar nas intrusões ou podem envolver-
se em actos maliciosos por conta própria (por exemplo, comerciantes
desonestos). Embora o nível de habilidade possa variar, geralmente é baixo a médio.
Gestão (Executiva, média)
Funcionários que trabalham diretamente para a empresa conforme descrito acima. Dada
a sua posição e função dentro da empresa, muitas vezes têm acesso a informação
privilegiada e podem
Análise de capacidade de ameaças
Uma vez
interno Externo
identificada
uma Funcionários Parceiros de negócios
comunidade de
ameaças, as Gestão (executiva, intermediária) Concorrentes
capacidades
dessa Administradores (rede, sistema,
Empreiteiros
comunidade servidor)
também devem
ser analisadas, a Desenvolvedores Fornecedores
fim de construir
um modelo de Engenheiros Estados da nação
ameaça preciso
Técnicos Crime organizado
que reflita a
probabilidade Contratantes (com seus usuários
real de tal Hacktivistas
externos)
Script Kiddies (hacking

Comunidade geral de usuários
recreativo/aleatório)
Suporte remoto
comunidade/agente agir com sucesso sobre a organização e comprometê-la. Esta análise

requer tanto uma análise técnica como uma análise de oportunidade (quando aplicável).
Análise das ferramentas em uso
Quaisquer ferramentas que estejam disponíveis para a comunidade/agente de ameaça
devem ser incluídas aqui. Além disso, as ferramentas que podem estar disponíveis
gratuitamente devem ser analisadas quanto ao nível de habilidade necessário para poder
utilizá-las em seu potencial e mapeadas na capacidade de ameaça.
Disponibilidade para explorações/cargas relevantes
A comunidade/agente de ameaça deve ser analisada em termos de sua capacidade de
obter ou desenvolver explorações para o ambiente relevante para a organização. Além
disso, a acessibilidade a tais explorações/cargas através de terceiros, parceiros de
negócios ou comunidades clandestinas também deve ser levada em consideração nesta
análise.
Mecanismos de comunicação
Uma análise dos mecanismos de comunicação disponíveis ao agente/comunidade de
ameaça deve ser feita para avaliar a complexidade dos ataques contra uma
organização. Esses mecanismos de comunicação variam desde tecnologias simples e
abertamente disponíveis, como a criptografia, até ferramentas e serviços especializados,
como hospedagem à prova de balas, uso de sites de descarte e uso de botnets conhecidos
ou desconhecidos para realizar ataques ou mascarar informações de origem. Por
exemplo, como parte dos testes, testamos para ver qual é a superfície geral de ataque
externo de uma organização. No entanto, há outro componente que muitas vezes é
esquecido. Que tipos de ameaças podem existir após a exploração? Isto se enquadra no
contexto da detecção de canais de exfiltração. Coincidentemente, os testadores de
penetração estão numa posição única para testar a capacidade de uma organização de
detectar canais de comando e controle do malware moderno de hoje. Quando isso
estiver no escopo, recomendamos que o testador crie uma série de amostras de malware
que aumentem o nível de ofuscação usado para ocultar C2. O objetivo é criar malware
que seja facilmente detectado e, em seguida, aumentar a ofuscação até o ponto em que a
detecção não ocorra mais.
Acessibilidade
O elemento final na análise da capacidade do agente da ameaça é a sua acessibilidade à
organização e/ou aos ativos específicos em questão. Completar o perfil descrito acima e
levar em conta a análise de acessibilidade permitiria que o teste de penetração criasse
cenários claros que são relevantes para o risco da organização.
Modelagem de Motivação
A possível motivação dos agentes/comunidades de ameaça deve ser anotada para análise
posterior. As motivações dos atacantes estão em constante mudança, como pode ser
visto pelo aumento de ataques de marca hacktivista por grupos como Anonymous e
Antisec. Haverá diferenças sutis nas motivações únicas com base em cada organização
e/ou mercado vertical. Algumas motivações comuns incluem:
Lucro (direto ou indireto)
Hacktivismo
Rancor direto
Diversão / Reputação
Acesso adicional a sistemas parceiros/conectados
Encontrar notícias relevantes de organizações comparáveis sendo comprometidas
Para fornecer um modelo de ameaça completo, deve ser fornecida uma comparação com
outras organizações dentro do mesmo setor vertical. Esta comparação deve incluir
quaisquer incidentes ou notícias relevantes relacionadas com essas organizações e os
desafios que enfrentam. Tal comparação é usada para validar o modelo de ameaça e
oferecer uma linha de base para a organização se comparar (levando em conta que esta
informação disponível publicamente representa apenas uma parte das ameaças e
incidentes reais que a organização comparada realmente enfrenta).
Conteúdo
1Teste
2Ativo
3Passiva
4Validação
5Pesquisar
Teste
O teste de vulnerabilidade é o processo de descoberta de falhas em sistemas e
aplicativos que podem ser aproveitadas por um invasor. Essas falhas podem variar desde
configuração incorreta de host e serviço ou design de aplicativo inseguro. Embora o
processo usado para procurar falhas varie e seja altamente dependente do componente
específico que está sendo testado, alguns princípios importantes se aplicam ao processo.
Ao conduzir análises de vulnerabilidade de qualquer tipo, o testador deve definir o
escopo adequado do teste para obter profundidade e amplitude aplicáveis para atender
aos objetivos e/ou requisitos do resultado desejado. Os valores de profundidade podem
incluir itens como a localização de uma ferramenta de avaliação, requisitos de
autenticação, etc. Por exemplo; em alguns casos, talvez o objetivo do teste para validar
a mitigação esteja em vigor e funcionando e a vulnerabilidade não esteja
acessível; enquanto em outros casos o objetivo talvez seja testar todas as variáveis
aplicáveis com acesso autenticado em um esforço para descobrir todas as
vulnerabilidades aplicáveis. Seja qual for o seu escopo, os testes devem ser adaptados
para atender aos requisitos de profundidade para atingir seus objetivos. A profundidade
dos testes deve sempre ser validada para garantir que os resultados da avaliação
atendam às expectativas (ou seja, todas as máquinas foram autenticadas, etc.). Além da
profundidade, a amplitude também deve ser levada em consideração ao realizar testes
de vulnerabilidade. Os valores de amplitude podem incluir coisas como redes alvo,
segmentos, hosts, aplicativos, inventários, etc. Em seu elemento mais simples, seu teste
pode ser encontrar todas as vulnerabilidades em um sistema host; enquanto em outros
casos você pode precisar encontrar todas as vulnerabilidades em hosts em um
determinado inventário ou limite. Além disso, a amplitude dos testes deve sempre ser
validada para garantir que você atendeu ao escopo do teste (ou seja, todas as máquinas
do inventário estavam funcionando no momento da verificação? Se não, por quê).
Ativo
O teste ativo envolve interação direta com o componente que está sendo testado quanto
a vulnerabilidades de segurança. Podem ser componentes de baixo nível, como a pilha
TCP em um dispositivo de rede, ou podem ser componentes superiores na pilha, como a
interface baseada na Web usada para administrar tal dispositivo. Existem duas maneiras
distintas de interagir com o componente de destino: automatizada e manual.
Automatizado
Os testes automatizados utilizam software para interagir com um alvo, examinar as
respostas e determinar se existe uma vulnerabilidade com base nessas respostas. Um
processo automatizado pode ajudar a reduzir o tempo e os requisitos de mão de
obra. Por exemplo, embora seja simples conectar-se a uma única porta TCP em um
sistema para determinar se ele está aberto para receber dados de entrada, executar esta
etapa uma vez para cada uma das 65.535 portas possíveis requer um tempo significativo
se for feito manualmente. Quando tal teste deve ser repetido em vários endereços de
rede, o tempo necessário pode simplesmente ser muito grande para permitir que o teste
seja concluído sem alguma forma de automação. O uso de software para executar essas
funções permite que o testador realize a tarefa em questão e concentre sua atenção no
processamento de dados e na execução de tarefas mais adequadas ao teste manual.
Scanners de vulnerabilidade geral/de rede
Baseado em porta
Uma varredura automatizada baseada em porta é geralmente uma das primeiras etapas
em um teste de penetração tradicional porque ajuda a obter uma visão geral básica do
que pode estar disponível na rede ou host de destino. Os scanners baseados em portas
verificam se uma porta em um host remoto é capaz de receber uma
conexão. Geralmente, isso envolverá os protocolos que utilizam IP (como TCP, UDP,
ICMP, etc.). No entanto, portas em outros protocolos de rede também podem estar
presentes dependendo do ambiente (por exemplo, é bastante comum em grandes
ambientes de mainframe para que o SNA esteja em uso). Normalmente, uma porta pode
ter um dos dois estados possíveis:
Aberto - a porta é capaz de receber dados
Fechada - a porta não consegue receber dados
Um scanner pode listar outros estados, como “filtrado”, se não for capaz de determinar
com precisão se uma determinada porta está aberta ou fechada.
Quando o scanner determina que uma porta está aberta, o scanner presume se uma
vulnerabilidade está presente ou não. Por exemplo, se um scanner baseado em porta se
conectar à porta TCP 23 e essa porta estiver escutando, o scanner provavelmente
informará que o serviço telnet está disponível no host remoto e o sinalizará como tendo
um protocolo de autenticação de texto não criptografado ativado.
Baseado em serviços
Um scanner de vulnerabilidade baseado em serviço é aquele que utiliza protocolos
específicos para se comunicar com portas abertas em um host remoto, para determinar
mais sobre o serviço que está sendo executado naquela porta. Isso é mais preciso do que
uma varredura de porta, porque não depende apenas da porta para determinar qual
serviço está em execução. Por exemplo, uma varredura de porta pode identificar que a
porta TCP 8000 está aberta em um host, mas não saberá, com base apenas nessas
informações, qual serviço está sendo executado ali. Um scanner de serviço tentaria se
comunicar com a porta usando protocolos diferentes. Se o serviço executado na porta
8000 for capaz de se comunicar corretamente usando HTTP, ele será identificado como
um servidor web.
Agarrando banner
A captura de banner é o processo de conexão a uma porta específica e exame dos dados
retornados do host remoto para identificar o serviço/aplicativo vinculado a essa
porta. Muitas vezes, no processo de conexão, o software fornece uma sequência de
identificação que pode incluir informações como o nome do aplicativo ou informações
sobre qual versão específica do software está sendo executada.
Conteúdo
1Teste
2Ativo
3Passiva
4Validação
5Pesquisar
Teste
O teste de vulnerabilidade é o processo de descoberta de falhas em sistemas e
aplicativos que podem ser aproveitadas por um invasor. Essas falhas podem variar desde
configuração incorreta de host e serviço ou design de aplicativo inseguro. Embora o
processo usado para procurar falhas varie e seja altamente dependente do componente
específico que está sendo testado, alguns princípios importantes se aplicam ao processo.
Ao conduzir análises de vulnerabilidade de qualquer tipo, o testador deve definir o
escopo adequado do teste para obter profundidade e amplitude aplicáveis para atender
aos objetivos e/ou requisitos do resultado desejado. Os valores de profundidade podem
incluir itens como a localização de uma ferramenta de avaliação, requisitos de
autenticação, etc. Por exemplo; em alguns casos, talvez o objetivo do teste para validar
a mitigação esteja em vigor e funcionando e a vulnerabilidade não esteja
acessível; enquanto em outros casos o objetivo talvez seja testar todas as variáveis
aplicáveis com acesso autenticado em um esforço para descobrir todas as
vulnerabilidades aplicáveis. Seja qual for o seu escopo, os testes devem ser adaptados
para atender aos requisitos de profundidade para atingir seus objetivos. A profundidade
dos testes deve sempre ser validada para garantir que os resultados da avaliação
atendam às expectativas (ou seja, todas as máquinas foram autenticadas, etc.). Além da
profundidade, a amplitude também deve ser levada em consideração ao realizar testes
de vulnerabilidade. Os valores de amplitude podem incluir coisas como redes alvo,
segmentos, hosts, aplicativos, inventários, etc. Em seu elemento mais simples, seu teste
pode ser encontrar todas as vulnerabilidades em um sistema host; enquanto em outros
casos você pode precisar encontrar todas as vulnerabilidades em hosts em um
determinado inventário ou limite. Além disso, a amplitude dos testes deve sempre ser
validada para garantir que você atendeu ao escopo do teste (ou seja, todas as máquinas
do inventário estavam funcionando no momento da verificação? Se não, por quê).
Ativo
O teste ativo envolve interação direta com o componente que está sendo testado quanto
a vulnerabilidades de segurança. Podem ser componentes de baixo nível, como a pilha
TCP em um dispositivo de rede, ou podem ser componentes superiores na pilha, como a
interface baseada na Web usada para administrar tal dispositivo. Existem duas maneiras
distintas de interagir com o componente de destino: automatizada e manual.
Automatizado
Os testes automatizados utilizam software para interagir com um alvo, examinar as
respostas e determinar se existe uma vulnerabilidade com base nessas respostas. Um
processo automatizado pode ajudar a reduzir o tempo e os requisitos de mão de
obra. Por exemplo, embora seja simples conectar-se a uma única porta TCP em um
sistema para determinar se ele está aberto para receber dados de entrada, executar esta
etapa uma vez para cada uma das 65.535 portas possíveis requer um tempo significativo
se for feito manualmente. Quando tal teste deve ser repetido em vários endereços de
rede, o tempo necessário pode simplesmente ser muito grande para permitir que o teste
seja concluído sem alguma forma de automação. O uso de software para executar essas
funções permite que o testador realize a tarefa em questão e concentre sua atenção no
processamento de dados e na execução de tarefas mais adequadas ao teste manual.
Scanners de vulnerabilidade geral/de rede
Baseado em porta
Uma varredura automatizada baseada em porta é geralmente uma das primeiras etapas
em um teste de penetração tradicional porque ajuda a obter uma visão geral básica do
que pode estar disponível na rede ou host de destino. Os scanners baseados em portas
verificam se uma porta em um host remoto é capaz de receber uma
conexão. Geralmente, isso envolverá os protocolos que utilizam IP (como TCP, UDP,
ICMP, etc.). No entanto, portas em outros protocolos de rede também podem estar
presentes dependendo do ambiente (por exemplo, é bastante comum em grandes
ambientes de mainframe para que o SNA esteja em uso). Normalmente, uma porta pode
ter um dos dois estados possíveis:
Aberto - a porta é capaz de receber dados
Fechada - a porta não consegue receber dados
Um scanner pode listar outros estados, como “filtrado”, se não for capaz de determinar
com precisão se uma determinada porta está aberta ou fechada.
Quando o scanner determina que uma porta está aberta, o scanner presume se uma
vulnerabilidade está presente ou não. Por exemplo, se um scanner baseado em porta se
conectar à porta TCP 23 e essa porta estiver escutando, o scanner provavelmente
informará que o serviço telnet está disponível no host remoto e o sinalizará como tendo
um protocolo de autenticação de texto não criptografado ativado.
Baseado em serviços
Um scanner de vulnerabilidade baseado em serviço é aquele que utiliza protocolos
específicos para se comunicar com portas abertas em um host remoto, para determinar
mais sobre o serviço que está sendo executado naquela porta. Isso é mais preciso do que
uma varredura de porta, porque não depende apenas da porta para determinar qual
serviço está em execução. Por exemplo, uma varredura de porta pode identificar que a
porta TCP 8000 está aberta em um host, mas não saberá, com base apenas nessas
informações, qual serviço está sendo executado ali. Um scanner de serviço tentaria se
comunicar com a porta usando protocolos diferentes. Se o serviço executado na porta
8000 for capaz de se comunicar corretamente usando HTTP, ele será identificado como
um servidor web.
Agarrando banner
A captura de banner é o processo de conexão a uma porta específica e exame dos dados
retornados do host remoto para identificar o serviço/aplicativo vinculado a essa
porta. Muitas vezes, no processo de conexão, o software fornece uma sequência de
identificação que pode incluir informações como o nome do aplicativo ou informações
sobre qual versão específica do software está sendo executada.
Verificadores de aplicativos da Web

Scanners de falhas de aplicações gerais
A maioria das verificações de aplicativos web começa com o endereço de um site,
aplicativo web ou serviço web. O scanner então rastreia o site seguindo links e
estruturas de diretório. Depois de compilar uma lista de páginas da web, recursos,
serviços e/ou outras mídias oferecidas, o scanner realizará testes ou auditorias com base
nos resultados do rastreamento. Por exemplo, se uma página da Web descoberta no
rastreamento tiver campos de formulário, o mecanismo de varredura poderá tentar
injeção de SQL ou script entre sites. Se a página rastreada contiver erros, o mecanismo
de varredura poderá procurar informações confidenciais exibidas nos detalhes do erro e
assim por diante.
Deve-se observar que as fases de rastreamento e teste podem ser escalonadas e
executadas ao mesmo tempo para reduzir o tempo geral de verificação. Este é o
comportamento padrão para muitos scanners de aplicativos da web.
Listagem de diretório/força bruta
Suponha que existam diretórios disponíveis no site que o rastreador não encontrará
seguindo os links. Sem o conhecimento prévio desses diretórios, fornecidos pelo
usuário, o scanner possui pelo menos duas opções adicionais.
O scanner/rastreador pode procurar diretórios “comuns”. São diretórios com nomes e
variantes de nomes comumente encontrados e incluídos em uma lista que foi compilada
como resultado de anos de experiência e digitalização. A maioria dos aplicativos da web
possui uma lista “integrada” desse tipo, enquanto alguns testadores de penetração
mantêm suas próprias listas personalizadas. Às vezes, os nomes dos diretórios são
exclusivos o suficiente para que possam ser usados para identificar um aplicativo Web
de terceiros com precisão razoavelmente alta. Uma lista de diretórios precisa muitas
vezes pode ser a chave para encontrar a parte “administrativa” de um site – uma parte
que a maioria dos testadores de penetração deveria estar altamente interessada em
descobrir.
Diretórios de força bruta são uma abordagem semelhante, embora em vez de usar uma
lista estática, uma ferramenta seja usada para enumerar todas as possibilidades que um
nome de diretório poderia ter. A desvantagem de usar essa abordagem é que ela tem o
potencial de travar ou inundar o servidor web com solicitações e, assim, causar uma
condição de negação de serviço. Deve-se tomar cuidado ao executar a força bruta de
diretório enquanto alguém monitora de perto a condição do servidor web, especialmente
em um ambiente de produção.
A razão pela qual você, como testador de penetração, deseja realizar a listagem de
diretórios é estender seu campo de ataque ou encontrar diretórios que possam conter
informações confidenciais (que, dependendo do objetivo do teste de penetração, podem
levar a uma descoberta importante dentro dele).
Versão do servidor Web/Identificação de vulnerabilidade
Muitos scanners de aplicativos web tentarão comparar a versão do servidor web com
versões vulneráveis conhecidas em avisos de segurança. Esta abordagem pode por vezes
levar a falsos positivos; pois há alguns casos em que servidores web de código aberto
são bifurcados ou copiados e recebem novos nomes, banners e recebem diferentes
números de versão. Etapas adicionais devem ser tomadas para verificar se o servidor da
web está, de fato, executando o que o banner ou o scanner da web relata.
Métodos
Vários métodos de servidor web são considerados inseguros e podem permitir que
invasores obtenham níveis variados de acesso ao conteúdo do servidor web. O fato de
esses métodos fazerem parte do software do servidor web, e não do conteúdo do site, o
diferencia de outras vulnerabilidades discutidas até agora. Alguns métodos inseguros
incluem:
OPÇÕES
Embora o método HTTP OPTIONS não seja inseguro por si só, ele pode permitir que
um invasor enumere facilmente os tipos de métodos HTTP aceitos pelo servidor de
destino. Observe que o método OPTIONS nem sempre é preciso e cada um dos métodos
abaixo deve ser validado individualmente.
COLOCAR/EXCLUIR
Usando o método PUT, um invasor pode fazer upload de conteúdo malicioso, como
páginas HTML, que podem ser usadas para transferir informações, alterar conteúdo da
web ou instalar software malicioso no servidor da web. Usando o método DELETE, um
invasor pode remover conteúdo ou desfigurar um site, causando interrupção do serviço.
Além disso, os aplicativos REST modernos usam PUT de uma maneira diferente:
Criar->POST Ler->GET Atualizar->PUT Excluir->DELETE
WebDAV
WebDAV é um componente do Microsoft Internet Information Server (IIS). WebDAV
significa “Autoria e controle de versão distribuídos baseados na Web” e é usado para
edição e gerenciamento de arquivos. As extensões WebDAV são usadas por
administradores para gerenciar e editar conteúdo da Web remotamente em servidores
Web IIS e podem incluir PROPFIND, COPY, MOVE, PROPPATCH, MKCOL, LOCK
e UNLOCK. O WebDAV interage com os principais componentes do sistema
operacional, o que pode expor um sistema a vários possíveis vulnerabilidades. Alguns
desses riscos potenciais incluem:
Condições de buffer overflow devido ao tratamento inadequado de solicitações do
usuário
Condições de negação de serviço de solicitações malformadas
Ataques de script baseados em domínio
Escalação de privilégios
Execução de código arbitrário
RASTREIO/RASTREIO
Os servidores web modernos suportam o método TRACE HTTP, que contém uma falha
que pode levar à divulgação não autorizada de informações. O método TRACE é usado
para depurar conexões de servidores web e pode permitir que o cliente veja o que está
sendo recebido na outra extremidade da cadeia de solicitações. Habilitado por padrão
em todos os principais servidores web, um invasor remoto pode abusar da
funcionalidade HTTP TRACE para divulgar informações confidenciais, resultando em
perda de confidencialidade.
Scanners de vulnerabilidade de rede/protocolos específicos

VPN
As ferramentas convencionais de avaliação de vulnerabilidades não são capazes de
realizar as negociações de protocolo corretas com dispositivos VPN que atendem ao
Internet Key Exchange (IKE). Em situações em que o IKE estiver em uso, será
necessário usar kits de ferramentas adicionais que possam executar funções como
impressão digital precisa, padrões de recuo e identificação de mecanismos de
autenticação que estão em uso. Ao identificar esses atributos de um dispositivo VPN,
podem ser identificados pontos fracos na execução de versões de código, bem como
tipos de autenticação, como chaves estáticas pré-compartilhadas.
Scanners de rede de voz
Discagem de guerra
Muitas organizações ainda utilizam acesso fora de banda em linhas telefônicas. O uso
de ferramentas de avaliação de vulnerabilidades projetadas para conduzir discagem de
guerra pode determinar pontos fracos na autenticação e na arquitetura de rede.
VoIP
As tecnologias de voz sobre IP são agora abundantes na maioria das
organizações. Muitas ferramentas foram desenvolvidas para realizar análises de
vulnerabilidade de infraestruturas VoIP. Usando essas ferramentas, é possível identificar
se as redes VoIP estão adequadamente segmentadas e se podem existir potenciais para
aproveitar essas redes para acessar sistemas de infraestrutura central ou gravar
conversas telefônicas em uma rede alvo.
Conexões diretas manuais
Como acontece com qualquer processo ou tecnologia automatizada, sempre existe
margem para erro. Instabilidades em sistemas, dispositivos de rede e conectividade de
rede podem apresentar resultados imprecisos durante os testes. É sempre recomendado
executar conexões diretas manuais para cada protocolo ou serviço disponível em um
sistema alvo para validar os resultados dos testes automatizados, bem como identificar
todos os possíveis vetores de ataque e pontos fracos não identificados anteriormente.
Ofuscado
Vários nós de saída
Os sistemas de monitoramento e defesa de segurança operam sob o pretexto de
identificar atividades maliciosas a partir de um endereço IP específico. Em situações em
que os sistemas de detecção de intrusões são implantados e monitoram atividades, a
avaliação de fornecimento e atividades de ataque de vários endereços IP fornecem
resultados mais precisos e diminuem a oportunidade de um dispositivo de
monitoramento em uma rede alvo identificar e responder. Tecnologias como os proxies
TOR podem fornecer um meio para realizar atividades de avaliação sem recorrer a um
único endereço IP.
Evasão de IDS
Ao realizar atividades de avaliação em um ambiente alvo onde as tecnologias IDS são
implantadas, pode ser necessário realizar a evasão. O uso de métodos como
manipulação de strings, polimorfismo, emenda de sessão e fragmentação pode fornecer
resultados mais precisos, ao mesmo tempo que contorna os padrões de correspondência
de assinatura implementados em dispositivos IDS.
Passiva
Análise de Metadados
A análise de metadados envolve a observação de dados que descrevem um arquivo, em
oposição aos dados do arquivo em si. Um documento do Microsoft Office, por exemplo,
pode listar o autor do documento, a empresa, quando o documento foi salvo pela última
vez, quando o documento foi criado e assim por diante. Muitos documentos permitem
até a entrada de metadados personalizados. Isso poderia conter endereços internos e
caminhos para servidores, endereços IP internos e outras informações que um testador
de penetração poderia usar para obter acesso ou informações adicionais.
Embora os metadados sejam bastante comuns em documentos localizados na rede
interna de uma empresa, as empresas devem ter o cuidado de eliminar os metadados
antes de disponibilizarem os documentos ao público ou na Internet pública. Por esta
razão, quaisquer metadados aos quais um invasor possa obter acesso passivamente (sem
atacar diretamente o alvo) devem ser considerados uma questão de segurança.
Monitoramento de tráfego
Monitoramento de tráfego é o conceito de conexão a uma rede interna e captura de
dados para análise offline. O envenenamento de rota é excluído desta fase, pois cria
“ruído” na rede e pode ser facilmente detectado. Muitas vezes é surpreendente a
quantidade de dados confidenciais que podem ser obtidos de uma rede “comutada”. Este
“vazamento de dados” em uma rede comutada pode ser categorizado da seguinte forma:
Estouro de cache ARP/MAC, fazendo com que pacotes comutados sejam transmitidos -
isso é comum em switches Cisco que possuem configurações inadequadas de
temporização de cache ARP/MAC.
Etherleak - alguns drivers de rede mais antigos e alguns drivers incorporados usarão
dados da memória do sistema para preencher pacotes ARP. Se pacotes ARP suficientes
puderem ser coletados, informações confidenciais da memória interna poderão ser
capturadas
Clusters ou balanceadores de carga mal configurados
Hubs conectados à rede Observe que algumas dessas categorias resultam apenas em
vazamento de dados para uma única sub-rede, enquanto outras podem resultar em
vazamento para segmentos de rede muito maiores.
Validação
Correlação entre ferramentas
Ao trabalhar com múltiplas ferramentas, a necessidade de correlação de resultados pode
tornar-se complicada. A correlação pode ser dividida em dois estilos distintos,
correlação específica e categórica de itens, ambos são úteis com base no tipo de
informação, métricas e estatísticas que você está tentando coletar sobre um determinado
alvo.
A correlação específica está relacionada a um problema específico definível, como ID
de vulnerabilidade, CVE, OSVDB, números de indexação do fornecedor, problema
conhecido com um produto de software, etc. e pode ser agrupada com microfatores,
como nome do host, IP, FQDN, endereço MAC, etc. Um exemplo disso seria agrupar as
descobertas do host x pelo número CVE, pois elas indexariam o mesmo problema em
várias ferramentas.
A correlação categórica refere-se a uma estrutura categórica para questões como em
estruturas de conformidade (ou seja, NIST SP 800-53, DoD 5300 Series, PCI, HIPPA,
Lista OWASP, etc.) que permitem agrupar itens por fatores macro, como tipos de
vulnerabilidade, problemas de configuração, etc. Um exemplo disso seria agrupar todas
as descobertas de hosts com senhas padrão em um grupo para complexidade de senha
dentro do NIST 800-53 (IA-5).
Na maioria dos casos, os testadores de penetração se concentrarão nos microproblemas
de vulnerabilidades específicas encontradas na redundância entre várias ferramentas no
mesmo host. Esta redundância pode distorcer os resultados estatísticos no resultado do
teste, levando a um perfil de risco falso aumentado.
O inverso disto ocorre com uma redução excessiva ou simplificação na correlação
macro (ou seja, listas dos 10/20 principais), pois os resultados podem distorcer os
resultados, resultando num perfil de risco falso reduzido.
Teste manual/específico do protocolo

VPN
Impressão digital
A impressão digital é útil para determinar o tipo de dispositivo VPN e a versão correta
do código lançado e instalado. Ao registrar com precisão as impressões digitais do
dispositivo, pesquisas e análises adequadas podem ser conduzidas no sistema de
destino.
Autenticação
Os dispositivos VPN podem operar com diversas formas de autenticação. O uso de kits
de ferramentas VPN que não fazem parte das ferramentas convencionais de avaliação de
vulnerabilidades permite a identificação adequada dos mecanismos de autenticação e
determina pontos fracos que possam existir, como chaves pré-compartilhadas ou IDs de
grupo padrão.
Citrix
Enumeração
Muitas instalações padrão e dispositivos Citrix mal configurados fornecem um meio de
enumerar aplicativos publicados e determinar nomes de usuários válidos configurados
para autenticação no dispositivo. Essas informações tornam-se cruciais durante ataques
de força bruta e tentativas de romper perfis predefinidos de usuários autorizados.
DNS
Os sistemas de nomes de domínio podem oferecer uma abundância de informações a
um invasor quando não estão devidamente protegidos. As informações da versão
permitem uma identificação adequada e uma análise de pesquisa precisa. Pontos fracos,
como transferências de zona, fornecem uma lista exaustiva de alvos adicionais para
ataque, bem como vazamento de informações de dados potencialmente confidenciais
pertencentes à organização alvo.
Rede
Os serviços da Web fornecem um amplo cenário para um invasor. Ao contrário da
maioria dos outros protocolos e serviços, os serviços da Web geralmente são executados
em várias portas de um único sistema. Os administradores podem concentrar sua
proteção nas portas comuns para serviços da Web ou diretórios publicados e
negligenciar a proteção adequada de atributos adicionais. Os serviços Web devem
sempre ser revistos de forma manual, uma vez que as ferramentas de avaliação
automatizadas não são capazes de identificar a maioria dos pontos fracos dos seus
serviços.
Correspondência
Os servidores de correio podem fornecer uma abundância de informações sobre uma
organização-alvo. Usando funções inerentes ao dispositivo alvo, a confirmação de
contas válidas pode ser realizada, bem como o desenvolvimento de uma lista de nomes
de usuário potenciais para ataques adicionais a outros sistemas. Vulnerabilidades como
a retransmissão de correio podem ser aproveitadas para ataques adicionais à
organização, como phishing. Freqüentemente, os servidores de e-mail fornecem uma
interface web para acesso remoto que pode ser alvo de campanhas de força bruta.
Avenidas de ataque
Criação de árvores de ataque
Durante uma avaliação de segurança, é crucial para a precisão do relatório final
desenvolver uma árvore de ataque à medida que os testes avançam ao longo do
trabalho. À medida que novos sistemas, serviços e potenciais vulnerabilidades são
identificados; uma árvore de ataque deve ser desenvolvida e atualizada
regularmente. Isto é especialmente importante durante as fases de exploração do
envolvimento, pois um ponto de entrada que se materializa pode ser repetido em outros
vetores mapeados durante o desenvolvimento da árvore de ataque.
Testes de laboratório isolados
A precisão da análise e exploração de vulnerabilidades é substancialmente maior
quando os ambientes replicados são configurados em um laboratório isolado. Muitas
vezes, os sistemas podem ser reforçados com conjuntos de controle específicos ou
mecanismos de proteção adicionais. Ao projetar um laboratório que imite o da
organização alvo, o consultor pode garantir que as vulnerabilidades identificadas e as
tentativas de exploração contra os alvos desejados sejam confiáveis e diminuam a
oportunidade de resultados imprecisos ou inoperabilidade do sistema.
Confirmação Visual
Conexão manual com revisão
Embora a correlação adequada possa ajudar a reduzir descobertas falsas e aumentar a
precisão geral, não há substituto para a inspeção visual de um sistema alvo. As
ferramentas de avaliação são projetadas para revisar os resultados de uma conexão de
protocolo/serviço ou a resposta e compará-los com assinaturas conhecidas de
vulnerabilidades. No entanto, as ferramentas nem sempre são precisas na identificação
de serviços em portas incomuns ou lógica personalizada que pode ser incorporada a um
aplicativo. Ao avaliar manualmente um sistema alvo, seus serviços disponíveis e os
aplicativos que fornecem funcionalidade para esses serviços, um testador pode garantir
que a validação adequada e a identificação de vulnerabilidade foram concluídas.
Pesquisar
Pesquisa Pública
Depois que uma vulnerabilidade for relatada em um sistema alvo, é necessário
determinar a precisão da identificação do problema e pesquisar a potencial exploração
da vulnerabilidade no âmbito do teste de penetração. Em muitos casos, a
vulnerabilidade será uma vulnerabilidade de software relatada em um pacote de
software comercial ou de código aberto e, em outros casos, a vulnerabilidade pode ser
uma falha em um processo de negócios ou um erro administrativo comum, como
configuração incorreta ou uso de senha padrão.
Bancos de dados de vulnerabilidade
Os bancos de dados de vulnerabilidade podem ser usados para verificar um problema
relatado por uma ferramenta automatizada ou para revisar manualmente a
vulnerabilidade de um aplicativo de destino. A maioria das ferramentas usará o
identificador CVE para uma determinada vulnerabilidade, que pode ser usado para
acessar informações resumidas e links para outras fontes no banco de dados CVE. O
CVE também pode ser usado para procurar o problema em bancos de dados de
vulnerabilidades como OSVDB e Bugtraq, ou em bancos de dados e estruturas de
exploração.
Bancos de dados de vulnerabilidade devem ser usados para verificar a precisão de um
problema relatado. Por exemplo, uma falha no servidor web Apache pode existir no
Windows, mas não no Linux, o que pode não ser levado em consideração por um
scanner automatizado.
Avisos de fornecedores
Os avisos de segurança e os logs de alterações emitidos pelo fornecedor podem fornecer
indicadores para informações de vulnerabilidade que podem não ser relatadas por
nenhuma ferramenta automatizada. Muitos dos principais fornecedores de software
relatam detalhes limitados sobre problemas descobertos internamente e problemas em
que um pesquisador independente coordena a divulgação de uma vulnerabilidade. Se o
pesquisador optar por permanecer em silêncio sobre os detalhes da vulnerabilidade, o
aconselhamento do fornecedor é frequentemente o único dado disponível. Nestes casos,
outros investigadores podem descobrir mais detalhes de forma independente e adicioná-
los a bases de dados de vulnerabilidades. A pesquisa do CVE usado em um comunicado
do fornecedor pode revelar mais detalhes sobre um problema potencialmente
explorável.
Os logs de alterações podem fornecer orientação para pesquisas adicionais,
especialmente em produtos de código aberto, onde uma diferença entre versões pode
revelar uma vulnerabilidade que foi corrigida, mas não amplamente conhecida, e talvez
não priorizada para atualização ou instalação como resultado.
Explorar bancos de dados e módulos de estrutura
Muitos bancos de dados de exploração são mantidos ativamente e acessíveis
publicamente na Internet. Os pesquisadores de segurança e os criadores de exploits nem
sempre enviam seus códigos de exploit para vários sites, por isso é aconselhável
familiarizar-se com vários sites e verificar cada um deles em busca de códigos de
exploit para usar em aplicativos potencialmente vulneráveis. Embora alguns bancos de
dados de vulnerabilidades rastreiem a disponibilidade de explorações, sua cobertura
geralmente é incompleta e não deve ser considerada exaustiva.
Estruturas de exploração comerciais e de código aberto também podem ser úteis na
pesquisa de vulnerabilidades. Na maioria dos casos, os módulos de exploração
disponíveis estão listados nos seus sites públicos e podem ser uma indicação valiosa da
explorabilidade de um problema.
Senhas comuns/padrão
Frequentemente, administradores e técnicos escolhem senhas fracas, nunca alteram o
padrão ou não definem nenhuma senha. Os manuais da maioria dos softwares e
hardwares podem ser facilmente encontrados on-line e fornecerão as credenciais
padrão. Fóruns da Internet e listas de discussão oficiais de fornecedores podem fornecer
informações sobre contas não documentadas, senhas comumente usadas e contas
frequentemente configuradas incorretamente. Finalmente, muitos sites documentam
senhas padrão/backdoor e devem ser verificados para cada sistema identificado.
Guias de proteção/configurações incorretas comuns
Um dos principais objetivos dos testes de penetração é simular as táticas e o
comportamento de um invasor real. Embora a verificação automatizada possa reduzir o
intervalo de tempo de um teste, nenhum scanner pode se comportar como um ser
humano. Os guias de endurecimento podem ser uma referência inestimável para um
testador de penetração. Eles não apenas destacam as partes mais fracas de um sistema,
mas você pode ter uma noção da diligência de um administrador ao validar quantas
recomendações foram implementadas. Durante cada teste de penetração, deve-se
reservar um tempo para revisar todos os principais sistemas e suas configurações de
proteção recomendadas, a fim de descobrir vulnerabilidades deixadas pelo
administrador.
Os fóruns de usuários e as listas de discussão podem fornecer informações valiosas
sobre os sistemas e os vários problemas que os administradores enfrentam ao configurá-
los e protegê-los. Um testador deve pesquisar os sistemas alvo como se estivesse
instalando um e descobrir onde estarão os pontos problemáticos e os prováveis erros de
configuração.
Pesquisa Privada
Configurando um ambiente de réplica
As tecnologias de virtualização permitem que um pesquisador de segurança execute
uma ampla variedade de sistemas operacionais e aplicativos, sem a necessidade de
hardware dedicado. Quando um sistema operacional ou aplicativo de destino for
identificado, um ambiente de máquina virtual (VM) poderá ser criado rapidamente para
imitar o destino. O testador pode usar esta VM para explorar parâmetros de
configuração e comportamentos do aplicativo, sem conectar-se diretamente ao destino.
Testando configurações
Um laboratório de testes de VM deve conter imagens base para todos os sistemas
operacionais comuns, incluindo Windows XP, Vista, 7, Server 2003 e Server 2008,
Debian, Ubuntu, Red Hat e Mac OS X, sempre que possível. Manter imagens separadas
para cada nível de service pack agilizará o processo de recriação do ambiente de
destino. Uma biblioteca VM completa em combinação com um ambiente VM que
suporte clonagem permitirá que um testador crie uma nova VM de destino em
minutos. Além disso, o uso de um recurso de instantâneo permitirá trabalhar com mais
eficiência e reproduzir bugs.
Confuso
Fuzzing, ou injeção de falhas, é uma técnica de força bruta para encontrar falhas de
aplicativos, enviando programaticamente entradas válidas, aleatórias ou inesperadas
para o aplicativo. O processo básico envolve anexar um depurador ao aplicativo de
destino e, em seguida, executar a rotina de difusão em áreas específicas de entrada e, em
seguida, analisar o estado do programa após qualquer falha. Muitas aplicações de
difusão estão disponíveis, embora alguns testadores escrevam seus próprios fuzzers para
alvos específicos.
Identificando possíveis caminhos/vetores
Faça login ou conecte-se a um aplicativo de rede de destino para identificar comandos e
outras áreas de entrada. Se o destino for um aplicativo de desktop que lê arquivos e/ou
páginas da web, analise os formatos de arquivo aceitos para identificar formas de
entrada de dados. Alguns testes simples envolvem o envio de caracteres inválidos ou
sequências de caracteres muito longas para causar uma falha. Anexe um depurador para
analisar o estado do programa no caso de uma falha bem-sucedida.
Desmontagem e análise de código
Algumas linguagens de programação permitem a descompilação e alguns aplicativos
específicos são compilados com símbolos para depuração. Um testador pode aproveitar
esses recursos para analisar o fluxo do programa e identificar vulnerabilidades
potenciais. O código-fonte para aplicativos de código aberto deve ser analisado em
busca de falhas. Os aplicativos da Web escritos em PHP compartilham muitas das
mesmas vulnerabilidades e seu código-fonte deve ser examinado como parte de
qualquer teste.
Exploração
Conteúdo
1Propósito
2Contramedidas
2.1Antivírus
2.1.1Codificação
2.1.2Embalagem
2.1.3Criptografando
2.1.4Ignorar lista de permissões
2.1.5Injeção de Processo
2.1.6Residente puramente de memória
2.2Humano
2.3Prevenção de Execução de Dados (DEP)
2.4Randomização de layout de espaço de endereço
2,5Firewall de aplicativos da Web (WAF)
3Evasão
4Ataque de Precisão
5Avenida de exploração personalizada
6Explorações personalizadas
6.1Explorar personalização
7Ângulo de dia zero
7.1Confuso
7.2Análise de código-fonte
7.3Tipos de explorações
7.3.1Estouros de buffer
7.3.2Sobrescrições SEH
7.3.3Programação Orientada ao Retorno
7.4Análise de Tráfego
7,5Acesso Físico
7.5.1Ângulo Humano
7.5.2Acesso ao PC
7.6Acesso por proximidade (WiFi)
7.6.1Ataques WiFi
7.6.2Atacando o usuário
8Exemplo de avenidas de ataque
9Objetivo Geral
Propósito
A fase de exploração de um teste de penetração concentra-se exclusivamente em
estabelecer acesso a um sistema ou recurso, contornando as restrições de segurança. Se
a fase anterior, a análise de vulnerabilidade, foi realizada corretamente, esta fase deve
ser bem planejada e um ataque de precisão. O foco principal é identificar o principal
ponto de entrada na organização e identificar ativos-alvo de alto valor.
Se a fase de análise de vulnerabilidade fosse devidamente concluída, uma lista de metas
de alto valor deveria ter sido cumprida. Em última análise, o vetor de ataque deve levar
em consideração a probabilidade de sucesso e o maior impacto na organização.
Contramedidas
As contramedidas são definidas como tecnologias ou controles preventivos que
dificultam a capacidade de concluir com êxito uma via de exploração. Essa tecnologia
pode ser um sistema de prevenção de intrusões baseado em host, um Security Guard,
um firewall de aplicativos da Web ou outros métodos preventivos. Ao realizar uma
exploração, vários fatores devem ser levados em consideração. No caso de uma
tecnologia preventiva, deve ser considerada uma técnica de evasão. Em circunstâncias
em que isto não seja possível, deverão ser considerados métodos de exploração
alternativos.
No geral, o objetivo é permanecer furtivo ao atacar a organização; se os alarmes forem
acionados, o nível da avaliação poderá ser diminuído. Se possível, as contramedidas
devem ser enumeradas antes de acionar a exploração. Isso poderia ser feito através de
simulações do ataque ou enumerando a tecnologia.
Antivírus
Antivírus é uma tecnologia que visa impedir a implantação de software malicioso no
sistema. Como testadores de penetração, devemos ser capazes de identificar esses tipos
de tecnologias antivírus e de nos proteger contra elas. O antivírus é um pequeno
subconjunto de todas as diferentes medidas preventivas que podem estar em vigor, por
exemplo, sistemas de prevenção de invasões baseados em host, firewalls de aplicativos
da Web e outras tecnologias preventivas.
Codificação
Codificação é o método de ofuscar dados de uma forma que faz com que o trecho de
código implantado não pareça o mesmo. Com a codificação, o ofuscamento geralmente
ocorre ao embaralhar e reorganizar as informações para ocultar o que o aplicativo está
realmente fazendo.
Embalagem
A compactação é semelhante à codificação no sentido de que tenta reorganizar os dados
para compactar o aplicativo ou "empacotá-lo". A esperança disso é que o executável ou
parte do código entregue seja ofuscado de uma maneira que não seja detectado por
tecnologias antivírus.
Criptografando
A criptografia, assim como a codificação e a embalagem, é outro método de
manipulação do código executável pretendido, de modo que ele não seja reconhecível
ou disponível para inspeção. Somente após a descriptografia na memória (com métodos
semelhantes ao empacotamento) o código real é exposto pela primeira vez -
esperançosamente, depois que os mecanismos de segurança permitirem sua passagem e
ele for executado imediatamente após ser descriptografado.
Ignorar lista de permissões
As tecnologias de lista branca aproveitaram um modelo confiável para aplicativos que
foram vistos em um determinado sistema por vez. A tecnologia toma uma linha de base
do sistema e identifica o que é normal ser executado no sistema versus o que é
estranho. O testador de penetração deve ser capaz de contornar as tecnologias da lista
branca. Um dos métodos mais comuns é através do acesso direto à memória. A lista de
permissões não tem a capacidade de monitorar a memória em tempo real e se um
programa residente na memória estiver em execução e não tocar no disco, ele poderá ser
executado sem ser detectado pela tecnologia fornecida.
Injeção de Processo
A injeção de processo é simplesmente o método para injetar em um processo já em
execução. Ao injetar em um processo, as informações do aplicativo podem ser ocultadas
em um processo que normalmente seria confiável por natureza. É muito difícil para a
tecnologia de medidas preventivas inspecionar processos em execução e quase sempre
pode se esconder em um processo diferente que o aplicativo consideraria confiável.
Residente puramente de memória
Os ataques residentes na memória são geralmente os mais preferidos, pois a maioria das
tecnologias não inspeciona a memória. Como invasor, seria mais desejável encontrar
uma maneira de viver puramente na memória. Ao gravar em disco, a maioria dos
aplicativos realizará varreduras, linhas de base e outras identificações de software
potencialmente malicioso. A capacidade de ser detectado ao gravar no disco torna-se
significativamente maior.
Humano
Ao realizar a exploração, nem sempre é o melhor caminho passar por uma exploração
direta ou por uma falha de aplicativo. Às vezes, o elemento humano pode ser a melhor
maneira de atacar uma organização. É importante compreender a via de ataque correta e
certificar-se de que o método que estamos utilizando é o melhor caminho a seguir.
Prevenção de Execução de Dados (DEP)
Ao realizar a exploração, muitas medidas preventivas podem entrar em ação. A
Prevenção de Execução de Dados é uma medida defensiva implementada na maioria
dos sistemas operacionais e impede a permissão de execução quando ocorre uma
substituição na memória. O processo de pensamento por trás da DEP é impedir que um
invasor reescreva a memória e depois execute esse código. Existem vários métodos para
contornar a prevenção de execução de dados e discutidos posteriormente na fase de
exploração do PTES.
Randomização de layout de espaço de endereço
Durante uma vulnerabilidade de buffer overflow (ou qualquer coisa onde controlamos a
memória), os endereços de memória são codificados para redirecionar o fluxo de
execução para nosso shellcode. No caso de ASLR, certos bytes são randomizados para
evitar que um invasor preveja onde ele pode ir para executar o shellcode.
Firewall de aplicativos da Web (WAF)
Firewalls de aplicativos da Web são uma tecnologia integrada a um aplicativo para
proteger contra ataques de aplicativos baseados na Web. Os firewalls de aplicativos da
Web tentam identificar ataques potencialmente perigosos ou malformados em relação a
um determinado aplicativo da Web e evitá-los. Existem várias técnicas de desvio para
firewalls de aplicativos da web e devem ser testadas durante o teste de penetração.
Evasão
Evasão é a técnica usada para escapar da detecção durante um teste de penetração. Isso
pode ser contornar um sistema de câmeras para não ser visto por um guarda, ofuscar
suas cargas para evitar sistemas de detecção de intrusões (IDS) ou sistemas de
prevenção de intrusões (IPS) ou codificar solicitações/respostas para contornar firewalls
de aplicativos da web. No geral, a necessidade de identificar um cenário de baixo risco
para evadir uma tecnologia ou pessoa deve ser formulada antes da exploração.
Ataque de Precisão
O foco principal de um teste de penetração é simular um invasor para representar um
ataque simulado contra a organização. O valor obtido por meio de um teste de
penetração geralmente não é através de técnicas de esmagamento e captura, onde os
ataques são barulhentos por natureza e na tentativa de tentar todas as explorações. Esta
abordagem pode ser particularmente útil no final de um teste de penetração para avaliar
o nível de resposta da organização a incidentes, mas na maioria dos casos a fase de
exploração é um acúmulo de pesquisas específicas sobre o alvo.
Avenida de exploração personalizada
Cada ataque normalmente não será o mesmo na forma como ocorre a via de
exploração. Para ter sucesso nesta fase, o ataque deve ser adaptado e customizado com
base no cenário. Por exemplo, se for realizado um teste de penetração sem fio e uma
tecnologia específica estiver em uso, estes precisam ser identificados e atacados com
base nas tecnologias existentes. Ter uma compreensão clara de cada cenário e da
aplicabilidade de uma exploração é um dos aspectos mais importantes desta fase do
teste de penetração.
Explorações personalizadas
Em diversas ocasiões, as explorações públicas na Internet podem precisar de algum
trabalho para serem concluídas com êxito. Na maioria dos casos, se uma exploração for
projetada para o Windows XP SP2, serão necessárias modificações específicas na
exploração para que o ataque seja bem-sucedido através do Windows XP SP3. O
testador de penetração deve ter o conhecimento necessário para poder personalizar uma
exploração e a capacidade de mudar rapidamente para concluir o ataque com êxito.
Explorar personalização
No caso de um ataque, muitas vezes é necessário simular a infraestrutura das vítimas
para garantir que a fase de exploração será bem-sucedida. As técnicas utilizadas na fase
de recolha de informação podem sempre ajudar nisso, no entanto, ter uma infra-
estrutura e sistemas funcionais em funcionamento tornará a fase de exploração muito
mais fácil. No caso de uma exploração personalizada, o testador de penetração deve ser
capaz de personalizar explorações já públicas para atacar um sistema com sucesso. Um
tema comum para explorações é atingir versões específicas de sistemas operacionais ou
aplicativos. A razão para isso é devido à mudança de endereços de memória com base
em service packs e/ou novas versões do sistema operacional. O testador deve ser capaz
de personalizar essas explorações para implantá-las com êxito em diferentes sistemas
operacionais e comprometer o sistema com êxito.
Ângulo de dia zero
Na maioria dos casos, o ângulo de dia zero costuma ser o último recurso para a maioria
dos testadores de penetração. Esse tipo de ataque geralmente representa uma
organização altamente avançada que pode lidar com um ataque direcionado contra a
organização por meio de métodos de ataque normais. Em certos cenários, pesquisas
podem ser conduzidas para fazer engenharia reversa, fuzz ou realizar descoberta
avançada de vulnerabilidades que não foram descobertas. Caso este tipo de ataque seja
aplicável, certifique-se de que o ambiente, de acordo com o conhecimento do invasor,
seja reproduzido para incluir tecnologia de contramedidas.
Para que as explorações de dia zero sejam bem-sucedidas (ou qualquer exploração nesse
sentido), ter o mesmo sistema operacional, patches e contramedidas é altamente
importante para o sucesso. Às vezes, esta informação pode não estar disponível com
base no nível de acesso ou enumeração que ocorreu.
Confuso
Fuzzing é a capacidade de recriar um protocolo ou aplicativo e tentar enviar dados para
o aplicativo na esperança de identificar uma vulnerabilidade. Muitas vezes, a esperança
de um fuzzer é identificar uma falha em um aplicativo e criar uma exploração específica
a partir dele. No caso de difusão, o invasor está tentando criar uma vulnerabilidade
específica a partir de algo que não foi descoberto antes. Como parte de um teste de
penetração, se nenhum caminho for identificado durante o trabalho, ou se o trabalho
exigir pesquisa de dia zero; técnicas de difusão devem ser aproveitadas para identificar
exposições potencialmente vulneráveis.
Análise de código-fonte
Outros caminhos que um testador de penetração tem disponível é se o código-fonte está
disponível ou é de código aberto. Se o testador tiver a capacidade de examinar o código-
fonte e identificar falhas no aplicativo, as exposições de dia zero também poderão ser
identificadas por meio desses métodos.
Tipos de explorações
Existem vários tipos de explorações que podem ser identificadas durante um teste de
penetração que pode ser classificado como dia zero. Alguns estão listados nesta seção.
Estouros de buffer
Estouros de buffer ocorrem devido a técnicas de codificação
inadequadas. Especificamente, isso geralmente ocorre quando um programa grava
dados em um buffer e, em seguida, ultrapassa o limite do buffer e começa a
sobrescrever partes da memória. Nas explorações de buffer overflow, o objetivo do
invasor é controlar uma falha e obter execução de código em um determinado
sistema. Em uma exploração de buffer overflow, uma das técnicas mais comuns é
sobrescrever um determinado registro e “pular” para o shellcode.
Sobrescrições SEH
As substituições SEH ocorrem quando o manipulador de exceções estruturado começa a
fechar um aplicativo normalmente. O invasor pode manipular o funcionamento do SEH,
sobrescrever o endereço base do manipulador SEH e obter controle do fluxo de
execução por meio do SEH. Este é um ataque comum aproveitado pela vulnerabilidade
de buffer overflow e aplicativos que foram cumpridos com SEH.
Programação Orientada ao Retorno
A Programação Orientada a Retorno (ROP) é uma técnica usada durante uma parte em
que o usuário tem controle do fluxo de execução, embora a prevenção de execução de
dados (DEP) ou outros mecanismos de defesa impeditivos possam estar em vigor. Na
situação em que a DEP está habilitada, o invasor não tem acesso direto para executar
instruções de montagem específicas; portanto, o invasor cria um gadget ROP para
preparar certas chamadas ou técnicas da API do Windows para desabilitar a DEP ou
contorná-la. Um método comum é aproveitar a chamada WriteProcessMemory para
copiar dados da pilha para um espaço de memória gravável que pode então ser
executado.
Análise de Tráfego
A análise de tráfego é a técnica de identificar que tipo de informação está sendo enviada
e a capacidade de compreender e manipular esse tráfego. Um testador de penetração
deve ser capaz de compreender como funciona um protocolo e como ele pode ser
manipulado para alavancar um ataque.
Acesso Físico
O acesso físico durante um teste de penetração pode ser um método de ataque viável
para tentar contornar os controles de segurança física e obter acesso não
autorizado. Durante um teste de penetração, o avaliador deve ser capaz de identificar
controles de segurança física potencialmente falhos e tentar obter acesso à instalação, se
estiver dentro do escopo.
Ângulo Humano
Durante um teste de penetração física, algumas das maneiras mais óbvias seriam fazer
engenharia social para entrar nas instalações e obter acesso. Isso requer um
conhecimento significativo de como a organização realiza os negócios e tudo o que
você aprendeu na fase de coleta de inteligência.
Acesso ao PC
Se o acesso físico for concedido a um PC, o testador de penetração deverá ser capaz de
atacar o PC e obter acesso através de vários métodos que permitiriam o acesso ao
sistema.
Acesso por proximidade (WiFi)
As comunicações sem fio são uma via para ataques obterem acesso por meio de
comunicações do tipo RF. O testador de penetração deve visualizar a lista de
frequências de rádio da FCC para ver se o alvo registrou frequências de espectro em
uso.
Ataques WiFi
Independentemente do protocolo, existem vários ataques disponíveis para WEP, WPA,
WPA2, EAP-FAST, EAP-LEAP e outras vias. O invasor deve estar familiarizado com
os vários protocolos e padrões de criptografia e ser capaz de testar com eficácia a
implementação dos controles implementados.
Atacando o usuário
Aproveitar pontos de acesso não autorizados para atacar a vítima costuma ser um
método de ataque benéfico e viável. Aproveitar um ponto de acesso não autorizado para
atrair vítimas, a fim de aproveitar explorações ou roubar informações confidenciais,
deve ser realizado durante uma avaliação sem fio. Existem várias técnicas comuns de
uso disso, mas mais comumente o invasor configuraria um ponto de acesso sem fio com
o mesmo nome ou um nome atraente para que a vítima se conectasse.
Exemplo de avenidas de ataque
Em qualquer cenário, os ataques devem consistir no cenário que está dentro do escopo
do engajamento. Abaixo está uma lista de vários caminhos de ataque a serem
considerados com base no cenário, mas não é de forma alguma uma lista abrangente.
Ataques de Aplicações Web Engenharia Social Ataques Físicos Abordam Explorações
Baseadas em Memória (isto é, buffer/heap overflows, corrupções de memória, uso após
liberação). Man in the Middle VLAN Hopping Implantação de USB/Flash Drive
Engenharia reversa Ângulo de dia zero Ataque ao usuário Quebra de criptografia
Unidade de processamento gráfico (GPU) Quebra de unidade de processamento gráfico
Análise de tráfego Protocolos de roteamento Firewire Phishing com pretexto
Representação de funcionário
Novamente, esses exemplos são apenas caminhos básicos para ataque com base no
cenário que você está executando para a organização. O valor de um teste de penetração
vem da criatividade e da capacidade de identificar exposições e explorá-las de maneira
precisa.
Objetivo Geral
Na fase de interação pré-engajamento com o cliente, deveria ter sido comunicada uma
definição clara dos objetivos gerais do teste de penetração. No caso da fase de
exploração, o maior desafio é identificar o menor caminho de resistência para dentro da
organização sem detecção e que tenha o maior impacto na capacidade da organização de
gerar receitas.
Ao executar as fases anteriores de maneira adequada, uma compreensão clara de como a
organização funciona e ganha dinheiro deve ser relativamente compreendida. Desde a
fase de exploração até à fase pós-exploração, os vetores de ataque devem basear-se
exclusivamente na missão de contornar os controlos de segurança, a fim de representar
como a organização pode sofrer perdas substanciais através de um ataque direcionado
contra a organização.
Pós-exploração
Conteúdo
1Propósito
2Regras de noivado
2.1Proteja o Cliente
2.2Protegendo-se
3Análise de Infraestrutura
3.1configuração de rede
3.1.1Interfaces
3.1.2Roteamento
3.1.3Servidores DNS
3.1.4Entradas DNS em cache
3.1.5Servidores proxy
3.1.6Entradas ARP
3.2Serviços de rede
3.2.1Serviços de escuta
3.2.2Conexões VPN
3.2.3Serviços de diretório
3.2.4Vizinhos
4Pilhagem
4.1Programas instalados
4.1.1Itens de inicialização
4.2Serviços instalados
4.2.1Serviços de segurança
4.2.2Compartilhamentos de arquivos/impressoras
4.2.3Servidores de banco de dados
4.2.4Servidores de diretório
4.2.5Servidores de nomes
4.2.6Serviços de implantação
4.2.7Autoridade Certificadora
4.2.8Servidor de gerenciamento de código-fonte
4.2.9Servidor de configuração de host dinâmico
4.2.10Virtualização
4.2.11Mensagens
4.2.12Monitoramento e Gestão
4.2.13Sistemas de Backup
4.2.14Serviços de rede (RADIUS,TACACS..etc)
4.3Dados sensíveis
4.3.1Registro de chaves
4.3.2Captura de tela
4.3.3Captura de tráfego de rede
4.3.4Relatórios de auditoria anteriores
4.4Informação do usuário
4.4.1No sistema
4.4.2Navegadores da Web
4.4.3Clientes de mensagens instantâneas
4,5Configuração do sistema
4.5.1Política de senha
4.5.2Políticas de Segurança
4.5.3Redes e chaves sem fio configuradas
5Alvos de alto valor/perfil
6Exfiltração de dados
6.1Mapeamento de todos os possíveis caminhos de exfiltração
6.2Testando caminhos de exfiltração
6.3Medindo forças de controle
7Persistência
8Maior penetração na infraestrutura
8.1Do sistema comprometido
8.2Através do sistema comprometido
9Limpar
Propósito
O objetivo da fase Pós-Exploração é determinar o valor da máquina comprometida e
manter o controle da máquina para uso posterior. O valor da máquina é determinado
pela sensibilidade dos dados armazenados nela e pela utilidade da máquina em
comprometer ainda mais a rede. Os métodos descritos nesta fase destinam-se a ajudar o
testador a identificar e documentar dados confidenciais, identificar definições de
configuração, canais de comunicação e relacionamentos com outros dispositivos de rede
que podem ser usados para obter acesso adicional à rede e configurar um ou mais
métodos de acessar a máquina posteriormente. Nos casos em que estes métodos diferem
das Regras de Envolvimento acordadas, as Regras de Envolvimento devem ser
seguidas.
Regras de noivado
As seguintes Regras de Compromisso são específicas para a fase Pós-Exploração de um
teste de penetração e têm como objetivo garantir que os sistemas do cliente não estejam
sujeitos a riscos desnecessários pelas ações (diretas ou indiretas) dos testadores e
garantir um procedimento mutuamente acordado a seguir durante a fase pós-exploração
do projecto.
Proteja o Cliente
As seguintes regras devem ser utilizadas como orientação de regras a estabelecer com
um cliente para garantir que as operações e dados do dia a dia do cliente não estejam
expostos a riscos:
Salvo acordo prévio, não haverá modificação de serviços que o cliente considere
“críticos” para sua infraestrutura. O objetivo de modificar tais serviços seria demonstrar
ao cliente como um invasor pode:
Escalar privilégios
Obtenha acesso a dados específicos
Causa negação de serviço
Todas as modificações, incluindo alterações de configuração, executadas em um sistema
devem ser documentadas. Depois de terminar o propósito pretendido da modificação,
todas as configurações devem retornar às suas posições originais, se possível. A lista de
alterações deve ser entregue ao cliente após o trabalho para permitir que ele garanta que
todas as alterações foram desfeitas corretamente. As alterações que não puderam
retornar às suas posições originais devem ser claramente diferenciadas das alterações
que foram revertidas com sucesso.
Deve ser mantida uma lista detalhada de ações tomadas contra sistemas
comprometidos. A lista deve incluir a ação tomada e o período em que ocorreu. Após a
conclusão, esta lista deverá ser incluída como apêndice ao relatório final.
Todos e quaisquer dados privados e/ou pessoais do usuário (incluindo senhas e histórico
do sistema) descobertos durante o teste de penetração podem ser usados como alavanca
para obter permissões adicionais ou para executar outras ações relacionadas ao teste
somente se as seguintes condições forem atendidas :
A Política de Uso Aceitável do cliente declara que todos os sistemas são de propriedade
do cliente e todos os dados armazenados nesses sistemas são de propriedade do cliente.
A Política de Uso Aceitável afirma que a conexão à rede do cliente é considerada
consentimento para que a máquina conectada seja pesquisada e analisada (incluindo
todos os dados e configurações presentes).
O cliente tem a confirmação de que todos os funcionários leram e compreenderam a
Política de Uso Aceitável.
As senhas (incluindo aquelas em formato criptografado) não serão incluídas no relatório
final ou deverão ser mascaradas o suficiente para garantir que os destinatários do
relatório não possam recriar ou adivinhar a senha. Isto é feito para salvaguardar a
confidencialidade dos utilizadores aos quais pertencem as palavras-passe, bem como
para manter a integridade dos sistemas que protegem.
Qualquer método ou dispositivo utilizado para manter o acesso a sistemas
comprometidos e que possa afetar o bom funcionamento do sistema ou cuja remoção
possa causar indisponibilidade não poderá ser implementado sem o consentimento
prévio por escrito do cliente.
Qualquer método ou dispositivo usado para manter o acesso a sistemas comprometidos
deve empregar alguma forma de autenticação de usuário, como certificados digitais ou
prompts de login. Uma conexão reversa a um sistema controlado conhecido também é
aceitável.
Todos os dados coletados pelos testadores devem ser criptografados nos sistemas
utilizados pelos testadores.
Qualquer informação incluída no relatório que possa conter dados confidenciais
(capturas de tela, tabelas, figuras) deve ser higienizada ou mascarada usando técnicas
que tornem os dados permanentemente irrecuperáveis pelos destinatários do relatório.
Todos os dados recolhidos serão destruídos assim que o cliente aceitar o relatório
final. O método utilizado e a prova de destruição serão fornecidos ao cliente.
Se os dados recolhidos forem regulamentados por alguma lei, os sistemas utilizados e as
suas localizações serão fornecidos pelo cliente para garantir que os dados recolhidos e
processados não violam nenhuma lei aplicável. Se os sistemas forem da equipe de testes
de penetração, os dados não poderão ser baixados e armazenados em seus sistemas e
apenas a prova de acesso será mostrada (permissões de arquivos, contagem de registros,
nomes de arquivos, etc.).
Não serão utilizados serviços de terceiros para quebra de senhas, nem haverá
compartilhamento de qualquer outro tipo de dados com terceiros sem o prévio
consentimento do cliente.
Caso seja encontrada evidência de comprometimento anterior no ambiente avaliado,
todos os logs com ações e tempos registrados durante a avaliação pela equipe de
penetração serão salvos, hash e fornecidos ao cliente. O cliente pode então determinar a
melhor forma de responder e lidar com a resposta ao incidente.
Nenhum registro deve ser removido, apagado ou modificado, a menos que
especificamente autorizado a fazê-lo pelo cliente no contrato de trabalho/declaração de
trabalho. Se autorizado, será necessário fazer backup dos logs antes de qualquer
alteração.
Protegendo-se
Devido à natureza de um teste de penetração, você deve garantir que cobrirá todas as
suas bases ao lidar com o cliente e as tarefas que irá executar. Discuta o seguinte com o
cliente para garantir uma compreensão clara das funções e responsabilidades do cliente
e do fornecedor antes de iniciar qualquer trabalho.
C ertifique-se de que o contrato e/ou declaração de trabalho assinado pelo cliente e pelo
fornecedor de que as ações tomadas nos sistemas que estão sendo testados sejam em
nome e em representação do cliente.
Obtenha uma cópia das políticas de segurança que regem o uso dos sistemas e
infraestrutura da empresa pelos usuários (geralmente chamadas de políticas de "Uso
Aceitável") antes de iniciar o trabalho. Verifique se a política cobre:
Uso pessoal de equipamentos e armazenamento de dados pessoais de funcionários nos
sistemas do cliente e propriedade e direitos sobre esses dados.
Propriedade dos dados armazenados nos equipamentos da empresa.
Confirme os regulamentos e leis que regem os dados que são gerenciados e usados pelo
cliente em seus sistemas e as restrições impostas a tais dados.
Use criptografia completa de unidade para os sistemas e mídias removíveis que
receberão e armazenarão dados do cliente.
Discutir e estabelecer com o cliente os procedimentos a seguir caso seja encontrado um
compromisso de terceiros.
Verifique a existência de leis relativas à captura e/ou armazenamento de áudio e vídeo,
uma vez que o uso destes métodos na pós-exploração pode ser considerado uma
violação das leis de escuta telefônica locais ou nacionais.
Análise de Infraestrutura
configuração de rede
A configuração de rede de uma máquina comprometida pode ser usada para identificar
sub-redes adicionais, roteadores de rede, servidores críticos, servidores de nomes e
relacionamentos entre máquinas. Essas informações podem ser usadas para identificar
alvos adicionais para penetrar ainda mais na rede do cliente.
Interfaces
Identifique todas as interfaces de rede na máquina juntamente com seus endereços IP,
máscaras de sub-rede e gateways. Ao identificar as interfaces e configurações, as redes
e os serviços podem ser priorizados para direcionamento.
Roteamento
O conhecimento de outras sub-redes, filtros ou esquemas de endereçamento poderia ser
aproveitado para escapar de uma rede segmentada, levando a hosts e/ou redes adicionais
para sondar e enumerar. Esses dados podem vir de diversas fontes em um determinado
host ou rede, incluindo:
Interfaces
Tabelas de roteamento, incluindo rotas estáticas e dinâmicas
Tabelas ARP, NetBios ou outros protocolos de rede usados para descoberta de serviços e
hosts.
Para hosts multihomed, determine se eles estão agindo como roteadores.
Servidores DNS
Identifique todos os servidores DNS em uso avaliando as configurações do host. Os
servidores DNS e as informações poderiam então ser usados para desenvolver e
executar um plano para descobrir hosts e serviços adicionais na rede alvo. Caso um
servidor DNS seja comprometido, o banco de dados DNS fornecerá informações
valiosas sobre hosts e serviços que podem ser usados para priorizar alvos para o restante
da avaliação. A modificação e adição de novos registros poderiam ser utilizadas para
interceptar os dados de serviços dependentes do DNS.
Entradas DNS em cache
Identifique entradas DNS de alto valor no cache, que podem incluir páginas de login
para sites de intranet, interfaces de gerenciamento ou sites externos. As interfaces
armazenadas em cache fornecem informações do host mais recente e mais usado pelo
host comprometido, fornecendo uma visão das relações e interações dos hosts,
fornecendo informações que podem ser usadas para priorizar alvos para maior
penetração na rede e infraestrutura alvo. A modificação das entradas em cache, se
permitida, pode ser usada para capturar credenciais de autenticação, tokens de
autenticação ou para obter mais informações sobre os serviços usados pelos hosts
comprometidos, levando a uma maior penetração na rede alvo.
Servidores proxy
Identifique servidores proxy em nível de rede e aplicativo. Os servidores proxy são bons
alvos quando usados em toda a empresa pelo cliente. No caso de proxies de aplicação,
pode ser possível identificar, modificar e/ou monitorar o fluxo de tráfego, ou o próprio
tráfego. Os ataques de proxy costumam ser um meio eficaz de mostrar o impacto e o
risco para o cliente.
Entradas ARP
Enumere entradas de tabelas ARP armazenadas em cache e estáticas, que podem revelar
outros hosts que interagem com a máquina comprometida. As entradas estáticas do ARP
podem representar máquinas críticas. Se o escopo da avaliação permitir interceptar e
modificar entradas ARP, é simples mostrar a possibilidade de interromper, monitorar ou
comprometer um serviço de uma maneira que normalmente não é detectada ou
protegida.
Serviços de rede
Serviços de escuta
Identifique todos os serviços de rede oferecidos pela máquina de destino. Isto pode levar
à descoberta de serviços não identificados pela varredura inicial, bem como à
descoberta de outras máquinas e redes. A identificação de serviços não mostrados na
varredura também pode fornecer informações sobre possíveis sistemas de filtragem e
controle implementados na rede e/ou host. Além disso, o testador poderá aproveitar
esses serviços para comprometer outras máquinas. A maioria dos sistemas operacionais
inclui um método para identificar conexões TCP e UDP feitas de e para a máquina. Ao
verificar as conexões de e para uma máquina comprometida, é possível encontrar
relações que eram anteriormente desconhecidas. Assim como o host, o serviço também
deve ser considerado, pois isso pode revelar serviços escutando em portas não padrão e
indicar relações de confiança, como autenticação sem chave para SSH.
Conexões VPN
Todas as conexões VPN de entrada e saída da máquina ou rede de destino devem ser
identificadas. As conexões de saída podem fornecer caminhos para novos sistemas que
podem não ter sido identificados anteriormente. Tanto o inbound quanto o outbound
podem identificar novos sistemas e possíveis relacionamentos comerciais. As conexões
VPN geralmente ignoram firewalls e sistemas de detecção/prevenção de intrusões
devido à sua incapacidade de descriptografar ou inspecionar o tráfego
criptografado. Este fato torna as VPNs ideais para lançar ataques. Quaisquer novos
alvos devem ser verificados quanto ao seu escopo antes de lançar ataques contra eles. A
presença de conexões de cliente ou servidor VPN no host de destino também pode
fornecer acesso a credenciais anteriormente desconhecidas que poderiam ser usadas
para direcionar outros hosts e serviços.
Serviços de diretório
Um host direcionado executando serviços de diretório pode fornecer uma oportunidade
de enumerar contas de usuários, hosts e/ou serviços que podem ser usados em ataques
adicionais ou fornecer alvos adicionais que podem não ter sido descobertos
anteriormente na fase de análise de vulnerabilidade. Além disso, os detalhes dos
usuários encontrados nos serviços de diretório podem ser usados para engenharia social
e ataques de campanhas de phishing, proporcionando assim uma possível taxa de
sucesso mais alta.
Vizinhos
Na rede atual, muitos serviços e sistemas operacionais usam vários protocolos para
descoberta de vizinhos, em um esforço para tornar o acesso aos serviços, a solução de
problemas e a configuração mais convenientes. Os protocolos variam dependendo do
tipo de host de destino. Equipamentos de rede podem usar protocolos como CDP (Cisco
Discovery Protocol) e LLDP (Link Layer Discovery Protocol) para identificar sistemas,
configurações e outros detalhes para hosts diretamente conectados a eles ou presentes na
mesma sub-rede. Da mesma forma, os sistemas operacionais de desktop e servidor
podem usar protocolos como mDNS (Multicast Domain Name Service) e NetBios para
encontrar detalhes de hosts e serviços na mesma sub-rede.
Pilhagem
Pilhagem refere-se à obtenção de informações (ou seja, arquivos contendo informações
pessoais, informações de cartão de crédito, senhas, etc.) de hosts-alvo relevantes para os
objetivos definidos na fase de pré-avaliação. Essas informações podem ser obtidas com
o propósito de satisfazer metas ou como parte do processo de pivotamento para obter
maior acesso à rede. A localização desses dados variará dependendo do tipo de dados,
da função do host e de outras circunstâncias. O conhecimento e a familiaridade básica
com aplicativos comumente usados, software de servidor e middleware são muito
importantes, pois a maioria dos aplicativos armazena seus dados em diversos formatos e
locais. Podem ser necessárias ferramentas especiais para obter, extrair ou ler os dados
alvo de alguns sistemas.
Programas instalados
Itens de inicialização
A maioria dos sistemas terá aplicativos que podem ser executados na inicialização do
sistema ou no logon do usuário e que podem fornecer informações sobre a finalidade do
sistema, software e serviços com os quais ele interage. Esta informação pode revelar
potenciais contramedidas que podem estar em vigor e que podem impedir uma maior
exploração de uma rede alvo e dos seus sistemas (por exemplo, HIDS/HIPS,
Application Whitelisting, FIM). As informações que devem ser coletadas incluem:
Lista dos aplicativos e suas versões associadas instaladas no sistema.
Lista de atualizações do sistema operacional aplicadas ao sistema.
Serviços instalados
Os serviços em um host específico podem servir ao próprio host ou a outros hosts na
rede de destino. É necessário criar um perfil de cada host alvo, observando a
configuração desses serviços, sua finalidade e como eles podem ser potencialmente
usados para atingir objetivos de avaliação ou penetrar ainda mais na rede.
Serviços de segurança
Os serviços de segurança compreendem o software projetado para manter um invasor
fora dos sistemas e manter os dados seguros. Isso inclui, entre outros, firewalls de rede,
firewalls baseados em host, IDS/IPS, HIDS/HIPS e antivírus. A identificação de
quaisquer serviços de segurança em um único host de destino dá uma ideia do que
esperar ao atacar outras máquinas na rede. Também dá uma ideia de quais alertas podem
ter sido acionados durante o teste, que podem ser discutidos com o cliente durante o
relatório do projeto, e podem resultar em atualizações de Políticas de Segurança, UAC,
SELinux, IPSec, modelos de segurança do Windows ou outros sistemas de segurança.
conjuntos de regras/configurações.
Compartilhamentos de arquivos/impressoras
Os servidores de arquivos e impressão geralmente contêm dados direcionados ou
oferecem uma oportunidade de penetrar ainda mais na rede e nos hosts alvo. As
informações que devem ser direcionadas incluem:
Compartilhamentos oferecidos por servidores de arquivos – Quaisquer
compartilhamentos de arquivos oferecidos pelos sistemas de destino devem ser
examinados. Mesmo apenas os nomes e comentários dos compartilhamentos podem
vazar informações importantes sobre os nomes de aplicativos ou projetos internos (ou
seja, se apenas “Fred” e “Christine” tiverem acesso à pasta “Contabilidade”, talvez
ambos sejam funcionários de contabilidade).
Listas de controle de acesso e permissões para compartilhamentos. - Do lado do cliente,
se for possível conectar-se ao compartilhamento, então deve-se verificar se a conexão é
somente leitura/gravação ou leitura/gravação. Lembre-se de que se um
compartilhamento contiver diretórios, permissões diferentes poderão ser aplicadas a
diretórios diferentes. Do lado do servidor, a configuração do servidor e as permissões de
arquivo/diretório devem ser examinadas.
Arquivo de compartilhamento de arquivos e listagens de conteúdo
Identifique os arquivos de interesse nas listagens de compartilhamento de
arquivos. Procure itens interessantes ou direcionados, como:
Código fonte
Cópias de segurança
Arquivos de instalação
Dados Confidenciais (dados financeiros em planilhas, relatórios bancários em
TXT/PDF, arquivos de senhas, etc.)
Coloque trojans ou arquivos de execução automática - Usando nomenclatura inteligente
ou imitando convenções de nomenclatura já em uso, os usuários podem ser incentivados
a executar essas cargas úteis, permitindo que o testador penetre ainda mais na rede. Se
os logs do servidor de arquivos puderem ser obtidos, usuários específicos poderão até
ser visados.
Servidores de banco de dados
Os bancos de dados contêm uma riqueza de informações que podem ser alvo de uma
avaliação.
Bases de dados - Uma lista de nomes de bases de dados pode ajudar o avaliador a
determinar a finalidade da base de dados e os tipos de dados que a base de dados pode
conter. Em um ambiente com muitos bancos de dados, isso ajudará na priorização dos
alvos.
Tabelas - Nomes de tabelas e metadados, como comentários, nomes de colunas e tipos
também podem ajudar o avaliador a escolher alvos e encontrar dados direcionados.
Conteúdo da tabela, contagem de linhas para conteúdo regulamentado
Colunas - Em muitos bancos de dados é possível pesquisar todos os nomes de colunas
de todas as tabelas com um único comando. Isso pode ser aproveitado para encontrar
dados direcionados (por exemplo, se os dados do cartão de crédito forem direcionados a
um banco de dados Oracle, tente executar select * from all_tab_columns where name =
'%CCN%'; .
Permissões de banco de dados e tabelas
Usuários, senhas, grupos e funções do banco de dados
As informações hospedadas em bancos de dados também podem ser usadas para
mostrar riscos, atingir objetivos de avaliação, determinar configuração e função de
serviços ou para penetrar ainda mais em uma rede de clientes e hosts.
Servidores de diretório
Os principais objetivos de um serviço de diretório é fornecer informações aos serviços e
hosts para referência e/ou autenticação. O comprometimento deste serviço pode permitir
o controle de todos os hosts que dependem do serviço e também fornecer informações
que podem ser utilizadas para promover um ataque. As informações a serem procuradas
em um serviço de diretório são:
Lista de objetos (Usuários, senhas, Máquinas..etc)
Conexões com o sistema
Identificação de protocolos e nível de segurança
Servidores de nomes
O servidor de nomes fornece resolução para host e serviços dependendo dos tipos de
registros que ele servidor. A enumeração de registros e controles pode fornecer uma lista
de alvos e serviços para priorizar e atacar para penetrar ainda mais na rede e nos hosts
de um cliente. A capacidade de modificar e adicionar registros pode ser usada para
mostrar riscos de negação de serviços, bem como auxiliar na interceptação de tráfego e
informações na rede de um cliente.
Serviços de implantação
A identificação dos serviços de implantação permite o acesso e enumeração de:
Arquivos de resposta autônomos
Permissão em arquivos
Atualizações incluídas
Aplicativos e versões
Essas informações podem ser usadas para penetrar ainda mais na rede e nos hosts do
cliente. A capacidade de modificar os repositórios e a configuração do serviço permite
Instalação de backdoor
Modificação de serviços para torná-los vulneráveis a ataques
Autoridade Certificadora
A identificação dos serviços da Autoridade de Certificação em um host cliente
comprometido permitirá o acesso a
CA raiz
Certificados de assinatura de código
Certificados de criptografia e assinatura
O controle do serviço também permitirá a
Criação de novos certificados para diversas tarefas
Revogação de certificados
Modificação da lista de revogação de certificados
Inserção de certificado CA raiz
O controle dos serviços apresenta riscos e permite o comprometimento de dados e
serviços na rede e nos hosts de um cliente.
Servidor de gerenciamento de código-fonte
A identificação de sistemas de gerenciamento de código-fonte pelo serviço em execução
no host comprometido ou na parte cliente do serviço oferece a oportunidade para:
Enumerar projetos - Os nomes dos projetos podem fornecer informações confidenciais
sobre os projetos da empresa.
Verifique o acesso aos arquivos de código-fonte
Modificar arquivos de código-fonte - Se for permitido no escopo, a modificação do
código-fonte prova que um invasor pode fazer alterações que afetariam o sistema
Enumerar desenvolvedores – Os detalhes dos desenvolvedores podem ser usados para
ataques de engenharia social, bem como como entradas para atacar outras áreas do
sistema
Enumerar configuração
Servidor de configuração de host dinâmico
A identificação do serviço de configuração dinâmica do host ou o uso do serviço pelo
host comprometido permite:
Locações de enumeração fornecidas
Configuração de enumeração
Opções de enumeração
Modificação de configuração
Consumo de todas as locações
O controle do serviço pode ser utilizado para mostrar risco de negação de serviço e para
uso em ataques man in the middle de hosts e serviços na rede comprometida.
Virtualização
Os serviços de virtualização de identificação ou software cliente permitem:
Enumerar máquinas virtuais (nome, configurações, sistema operacional)
Enumerar senhas e certificados digitais para sistemas de administração.
Enumerar a configuração do software de virtualização
Configuração de hosts
Mostrar risco de negação de serviço com controle do estado da VM
Acesso a dados hospedados em VMs
Interceptação de tráfego de hosts virtuais ou serviços hospedados no host comprometido
Mensagens
A identificação de serviços ou software cliente para mensagens oferece a oportunidade
de
Identificar serviços de diretório
Comprometimento de credenciais
Acesso a informações confidenciais
Identificação de hosts na rede
Relacionamentos de sistema e negócios
Todas essas informações e ações podem ser usadas para mostrar riscos e penetrar ainda
mais na rede e nos hosts de um cliente.
Monitoramento e Gestão
A identificação de serviços ou software cliente para fins de monitoramento e/ou
gerenciamento pode fornecer a identificação de servidores e serviços adicionais na rede
alvo, além dos parâmetros de configuração obtidos podem fornecer acesso a outros
hosts alvo e determinar quais ações executadas pelo testador pode ser detectado pelo
cliente. Alguns serviços a serem procurados:
SNMP (protocolo simples de gerenciamento de rede)
Registro de sistema
Alguns serviços de gerenciamento e software a serem procurados para obter credenciais,
identificar o host e obter acesso a outros serviços podem ser:
Servidor/Cliente SSH
Servidor/Cliente Telnet
Cliente RDP (Protocolo de Área de Trabalho Remota)
Servidor de terminal
Software de gerenciamento de ambiente virtual
Sistemas de Backup
A identificação de serviços ou software cliente com a finalidade de fazer backup de
dados oferece uma grande oportunidade para um invasor, uma vez que esses sistemas
exigem acesso aos dados e sistemas de que precisam para fazer backup, fornecendo ao
invasor:
Enumeração de hosts e sistemas
Enumeração de serviços
Credenciais para host e/ou serviços
Acesso a dados de backup
As informações obtidas no serviço podem ser utilizadas para evidenciar risco à
confidencialidade, integridade e acesso ao sistema e suas informações. O acesso aos
backups também pode fornecer a oportunidade de introduzir configurações incorretas,
software vulnerável ou backdoors nos sistemas dos clientes.
Serviços de rede (RADIUS,TACACS..etc)
A identificação de serviços ou o uso de serviços de rede permite:
Enumeração de usuários
Enumeração de hosts e sistemas
Comprometimento de credenciais
Mostrar risco de negação de serviço se métodos alternativos não estiverem presentes
Dados sensíveis
Registro de chaves
Ao monitorar as teclas digitadas, é possível detectar informações confidenciais,
incluindo senhas e PII. Não sei qual é a legalidade disso se o usuário estiver
conversando em mensagens instantâneas privadas enquanto também usa o software da
empresa, alguém sabe? Se a empresa disser que todos os dados da rede podem ser
monitorados, tudo bem. Se o segundo ponto em Proteja-se estiver presente e afirma que
o uso do equipamento pode ser monitorado e nenhum uso pessoal é permitido, sim, se a
política não abrange o usuário pessoal ou a propriedade dos dados, não. Deveria ser
alargado para abranger também a Rede.
Captura de tela
A captura de tela pode ser usada para mostrar evidências de comprometimento, bem
como o acesso às informações que podem ser mostradas na tela e o acesso por outros
meios não é possível. Deve-se ter muito cuidado com os dados coletados através da
captura de tela para não mostrar dados privados de funcionários de clientes do cliente.
Captura de tráfego de rede
A captura de tráfego de rede pode ser usada dependendo dos controles na rede e o meio
usado para captura pode ser usado para:
Identifique hosts na rede
Interceptar dados
Identificar serviços
Identifique relações entre hosts na rede
Captura de credenciais
Deve-se ter cuidado para capturar apenas o tráfego coberto pelo escopo do contrato e
para que as informações capturadas não caiam sob o controle de leis locais, como a
captura de chamadas de voz sobre IP. As informações retidas e apresentadas devem ser
filtradas de forma a proteger os dados pessoais e confidenciais dos clientes e/ou
funcionários do cliente.
Relatórios de auditoria anteriores
Informação do usuário
Nesta seção, o foco principal está nas informações presentes no sistema alvo
relacionadas às contas de usuários presentes no sistema ou que se conectaram
remotamente e deixaram algum rastro que o pessoal que realiza a avaliação pode coletar
e analisar para maior penetração ou fornecer o objetivo desejado da avaliação.
No sistema
As informações gerais que podem ser coletadas em um sistema comprometido são:
Arquivos de histórico - Os arquivos de histórico armazenam comandos recentes que o
usuário executou. A leitura deles pode revelar informações de configuração do sistema,
aplicativos importantes, locais de dados e outras informações confidenciais do sistema.
Chaves de criptografia (SSH, PGP/GPG)
Documentos interessantes (.doc/x, .xls/x , password.*) - Os usuários geralmente
armazenam senhas e outras informações confidenciais em documentos de texto não
criptografado. Eles podem ser localizados de duas maneiras: pesquisando nomes de
arquivos em busca de palavras interessantes, como password.txt, ou pesquisando nos
próprios documentos. Os serviços de indexação podem ajudar com isso, por exemplo, o
banco de dados de localização do Linux.
Parâmetros de configuração de aplicativo específicos do usuário
Histórico de aplicativos individuais (somente MRU Windows, arquivos de
histórico..etc)
Enumerar mídia removível
Enumerar compartilhamentos de rede/permissão de domínio (gpresult)
Navegadores da Web
As informações que podem ser coletadas de navegadores da Web e que podem ser
usadas para identificar outros hosts e sistemas, bem como fornecer informações para
penetrar ainda mais na rede e nos hosts de um cliente, são:
Histórico do navegador
Favoritos
Histórico de downloads
Credenciais
Proxies
Plug-ins/Extensões
Deve-se ter muito cuidado para que apenas os dados no escopo do trabalho sejam
capturados, uma vez que as informações de um navegador da Web podem conter dados
confidenciais e privados dos funcionários do cliente. Esses dados devem ser filtrados
dos dados retornados e do relatório.
Clientes de mensagens instantâneas
As informações que podem ser coletadas de clientes de mensagens instantâneas em um
sistema comprometido são:
Enumerar configuração de conta (usuário, senha, servidor, proxy)
Registros de bate-papo
Deve-se ter muito cuidado para que apenas os dados no escopo do trabalho sejam
capturados, uma vez que as informações de um navegador da Web podem conter dados
confidenciais e privados dos funcionários do cliente. Esses dados devem ser filtrados
dos dados retornados e do relatório.
Configuração do sistema
Política de senha
Ao enumerar a política de senha do sistema, a capacidade de usar força bruta e quebrar
senhas torna-se muito mais eficiente, por exemplo, sabendo que o comprimento mínimo
da senha é de 8 caracteres, você pode remover qualquer palavra com menos de 8
caracteres de um dicionário.
Políticas de Segurança
Redes e chaves sem fio configuradas
Ao encontrar as informações sem fio dos alvos, torna-se possível lançar ataques físicos
através do wifi da empresa quando estiver no local. Ele também pode permitir que um
AP falso seja configurado para atrair alvos para se conectarem quando estiverem fora do
local.
Alvos de alto valor/perfil
Alvos de alto valor/perfil podem ser identificados e expandidos a partir dos alvos
identificados nas reuniões de pré-engajamento através da análise dos dados coletados
dos sistemas comprometidos e das interações desses sistemas e dos serviços que neles
são executados. a operação e as interações dessas metas de alto valor/perfil ajudam na
identificação e medição do impacto que pode ser obtido para o negócio, nos dados e
processos e na integridade geral da infraestrutura e dos serviços do cliente.
Exfiltração de dados
Mapeamento de todos os possíveis caminhos de exfiltração
de cada uma das áreas onde o acesso foi conseguido, deverão ser criadas vias de
exfiltração completas. Isto inclui meios secundários e terciários de chegar ao mundo
exterior (através de diferentes sub-redes acessíveis, etc.). Uma vez fornecido o
mapeamento, o teste de exfiltração propriamente dito deve ser iniciado.
Testando caminhos de exfiltração
De acordo com o mapeamento dos caminhos de exfiltração, os dados devem ser
exfiltrados da organização que está sendo testada. Isso já deve estar coberto no
escopo do pré-engajamento e uma infraestrutura adequada deve ter sido configurada de
acordo com a política de engajamento aceitável do cliente (ou seja, os dados que estão
sendo exfiltrados geralmente são exfiltrados para um servidor com controle total do
testador e terão acesso e propriedade direito à organização testada). A exfiltração em si
deve simular estratégias de exfiltração do mundo real usadas pelos atores da ameaça que
correspondem ao Padrão de Modelagem de Ameaças relevante para a organização (ou
seja, se for criminoso principalmente, então a exfiltração "padrão" usando uma área de
preparação dentro da rede onde os dados são arquivados dentro de zip/ 7z
criptografados e, em seguida, enviados para servidores FTP/HTTP na Internet, se for um
ator de ameaça mais sofisticado, usando meios que simulem tais estratégias e táticas
usadas para exfiltração).
Medindo forças de controle
Ao realizar testes de exfiltração, o principal objetivo do teste é verificar se os controles
atuais para detectar e impedir que informações confidenciais saiam da organização
realmente funcionam, bem como exercitar as equipes de resposta caso algo tenha sido
detectado em termos de como elas reagem a tais alertas e como os eventos estão sendo
investigados e mitigados.
Persistência
Instalação de backdoor que requer autenticação.
Instalação e/ou modificação de serviços para conexão de volta ao sistema. Usuário e
senha complexa devem ser usados no mínimo; o uso de certificados ou chaves
criptográficas é preferido sempre que possível. (SSH, ncat, RDP). Podem ser utilizadas
conexões reversas limitadas a um único IP.
Criação de contas alternativas com senhas complexas.
Quando possível, o backdoor deve sobreviver às reinicializações.
Maior penetração na infraestrutura
Pivotar é a ação na qual o testador usará sua presença no sistema comprometido para
enumerar e obter acesso a outros sistemas na infraestrutura do cliente. Esta ação pode
ser executada a partir do próprio host comprometido usando recursos locais ou
ferramentas carregadas no sistema comprometido.
Do sistema comprometido
Ações que podem ser tomadas em um sistema comprometido:
Carregar ferramentas
Use ferramentas do sistema local
Varredura ARP
Varredura de ping
Enumeração DNS da rede interna
Enumeração de serviços de diretório
Ataques de força bruta
Enumeração e gerenciamento através de protocolos de gerenciamento e credenciais
comprometidas (WinRM, WMI, SMB, SNMP..etc)
Abuso de credenciais e chaves comprometidas (páginas da Web, bancos de dados, etc.)
Execute explorações remotas
A ação que será executada dependerá das informações necessárias para demonstrar risco
específico e/ou penetração adicional na rede e hosts do cliente. Recomendam-se sessões
regulares de planeamento para reavaliar a informação recolhida e decidir a melhor
abordagem para continuar a pós-exploração até que os objectivos definidos sejam
alcançados.
Através do sistema comprometido
Ações que podem ser tomadas através de um sistema comprometido:
Encaminhamento de porta
Proxy para rede interna (SSH)
VPN para rede interna
Executar exploração remota
Abuso de credenciais e chaves comprometidas (páginas da Web, bancos de dados, etc.)
A ação que será executada dependerá das informações necessárias para demonstrar risco
específico e/ou penetração adicional na rede e hosts do cliente. Recomendam-se sessões
regulares de planeamento para reavaliar a informação recolhida e decidir a melhor
abordagem para continuar a pós-exploração até que os objectivos definidos sejam
alcançados.
Limpar
O processo de limpeza cobre os requisitos para limpeza de sistemas após a conclusão do
teste de penetração. Isso incluirá todas as contas de usuário e binários usados durante o
teste
.
Remova todos os executáveis, scripts e arquivos temporários de um sistema

comprometido. Se possível, use o método de exclusão segura para remover arquivos e
pastas.
Retorne aos valores originais das configurações do sistema e dos parâmetros de
configuração do aplicativo se eles tiverem sido modificados durante a avaliação.
Remova todos os backdoors e/ou rootkits instalados.
Remova todas as contas de usuário criadas para conexão com sistemas comprometidos.

pastas.
pastas.
Comunicando
Conteúdo
1Visão geral
2Estrutura do relatório
3O Resumo Executivo
4Relatório técnico
Visão geral
Este documento tem como objetivo definir os critérios básicos para relatórios de testes
de penetração. Embora seja altamente recomendável usar seu próprio formato
personalizado e de marca, o seguinte deve fornecer uma compreensão de alto nível dos
itens exigidos em um relatório, bem como uma estrutura para que o relatório agregue
valor ao leitor.
Estrutura do relatório
O relatório é dividido em duas (2) seções principais para comunicar os objetivos,
métodos e resultados dos testes realizados a diversos públicos.
O Resumo Executivo
Esta seção comunicará ao leitor os objetivos específicos do Teste de Penetração e as
descobertas de alto nível do exercício de teste. O público-alvo serão aqueles
responsáveis pela supervisão e visão estratégica do programa de segurança, bem como
quaisquer membros da organização que possam ser impactados pelas ameaças
identificadas/confirmadas. O resumo executivo deve conter a maioria, senão todas, das
seguintes seções:
Fundo:
A seção de antecedentes deve explicar ao leitor o objetivo geral do teste. Detalhes sobre
os termos identificados na seção Pré-engajamento relacionados a riscos, contramedidas
e metas de teste devem estar presentes para conectar o leitor aos objetivos gerais do
teste e aos resultados relativos.
(Exemplo: (CLIENTE) encarregou <Pentester> de realizar uma avaliação de
vulnerabilidade interna/externa e testes de penetração de sistemas específicos
localizados em (área lógica ou localização física). Esses sistemas foram identificados
como (classificação de risco) e contêm (nível de classificação de dados ) dados que, se
acessados de forma inadequada, podem causar danos materiais ao (Cliente). Em um
esforço para testar a capacidade do (CLIENTE) de se defender contra ataques diretos e
indiretos, <Pentester> executou uma varredura abrangente de vulnerabilidade de rede,
Conformação de vulnerabilidade (<-inserir tipos de ataque acordados->) exploração de
serviços enfraquecidos, ataques do lado do cliente, ataques do lado do navegador (etc.)
O objetivo desta avaliação foi verificar a eficácia dos controles de segurança
implementados pelo (CLIENTE) para proteger informações críticas para o negócio. Este
relatório representa as conclusões da avaliação e as recomendações de remediação
associadas para ajudar o CLIENTE a fortalecer a sua postura de segurança.
Se os objetivos foram alterados durante o teste, todas as alterações deverão ser listadas
nesta seção do relatório. Além disso, a carta retificativa deve ser incluída no apêndice
do relatório e vinculada a esta seção.
Postura Geral:
Esta área será uma narrativa da eficácia geral do teste e da capacidade dos pentesters de
atingir os objetivos estabelecidos nas sessões de pré-engajamento. Uma breve descrição
dos problemas sistêmicos (ex. problema sistêmico = falta de processo de gerenciamento
de patches eficaz vs. sintomático = encontrado MS08-067 ausente na caixa xyz)
identificados através do processo de teste, bem como a capacidade de obter acesso às
informações do objetivo e identificar um impacto potencial para o negócio.
Classificação/Perfil de Risco:
A classificação/perfil/pontuação geral de risco será identificada e explicada nesta
área. Na seção de pré-engajamento, o Pentester identificará o mecanismo de pontuação
e o mecanismo individual para rastrear/classificar o risco. Vários métodos de FAIR,
DREAD e outras classificações personalizadas serão consolidados em pontuações
ambientais e definidos.
A “Pontuação de Risco Geral” para (CLIENTE) é atualmente Sete (7). Esta
classificação implica um risco ELEVADO de os controlos de segurança serem
comprometidos com o potencial de perdas financeiras materiais. O consultor
determinou essa pontuação de risco com base em uma vulnerabilidade de alto risco e
diversas vulnerabilidades de risco médio, juntamente com o sucesso do ataque
direcionado. A vulnerabilidade mais grave identificada foi a presença de senhas padrão
no site corporativo voltado para o público, que permitia o acesso a vários documentos
confidenciais e a capacidade de controlar o conteúdo do dispositivo. Esta
vulnerabilidade pode levar ao roubo de contas de usuários, ao vazamento de
informações confidenciais ou ao comprometimento total do sistema. Várias
vulnerabilidades menos graves podem levar ao roubo de credenciais de contas válidas e
ao vazamento de informações.
Constatações Gerais:
As conclusões gerais fornecerão uma sinopse dos problemas encontrados durante o teste
de penetração em formato básico e estatístico. Devem estar presentes representações
gráficas dos alvos testados, resultados de testes, processos, cenários de ataque, taxas de
sucesso e outras métricas de tendência, conforme definido na reunião de pré-
engajamento. Além disso, a causa dos problemas deve ser apresentada num formato de
fácil leitura. (ex. Um gráfico mostrando a causa raiz dos problemas explorados)
Se definida no exercício de pré-engajamento, esta área também deve incluir métricas
que retratem a eficácia das contramedidas no ambiente. (por exemplo, executamos x
ataques e o IPS bloqueou y. Outras contramedidas também devem ter métricas
semelhantes de design versus eficácia.)
Resumo da recomendação:
A secção de recomendações do relatório deve proporcionar ao leitor uma compreensão
de alto nível das tarefas necessárias para resolver os riscos identificados e o nível geral
de esforço necessário para implementar o caminho de resolução sugerido. Esta secção
também identificará os mecanismos de ponderação utilizados para priorizar a ordem de
seguimento do roteiro.
Roteiro Estratégico:
Os roteiros devem incluir um plano priorizado para remediação dos itens inseguros
encontrados e devem ser ponderados em relação aos objetivos de negócios/nível de
impacto potencial. Esta seção deve mapear diretamente os objetivos identificados, bem
como a matriz de ameaças criada na seção PTES-Modelagem de ameaças. Ao dividir-se
em metas predefinidas baseadas em tempo/objetivos, esta seção criará um caminho de
ação a ser seguido em vários incrementos. Exemplo:
Relatório técnico
Esta seção comunicará ao leitor os detalhes técnicos do teste e todos os
aspectos/componentes acordados como indicadores-chave de sucesso no exercício de
pré-engajamento. A seção do relatório técnico descreverá detalhadamente o escopo, as
informações, o caminho do ataque, o impacto e as sugestões de correção do teste.
Introdução:
A seção de introdução do relatório técnico pretende ser um inventário inicial de:
Pessoal envolvido nos testes do cliente e da equipe de testes de penetração
Informações de contato
Ativos envolvidos nos testes
Objetivos do teste
Escopo do teste
Força do teste
Abordagem
Estrutura de ameaça/classificação
Esta seção deve ser uma referência para os recursos específicos envolvidos nos testes e
para o escopo técnico geral do teste.
Coleta de informações:
A coleta de inteligência e a avaliação de informações são a base de um bom teste de
penetração. Quanto mais informado o testador estiver sobre o ambiente, melhores serão
os resultados do teste. Nesta seção deverão ser redigidos alguns itens para mostrar ao
CLIENTE a extensão da informação pública e privada disponível durante a execução da
fase de coleta de Inteligência do PTES. No mínimo, os resultados identificados deverão
ser apresentados em 4 categorias básicas:
Inteligência Passiva:
Inteligência coletada de análises indiretas, como DNS, busca de informações
relacionadas a IP/infraestrutura do Google. Esta seção se concentrará nas técnicas
usadas para traçar o perfil da tecnologia no ambiente do CLIENTE SEM enviar nenhum
tráfego diretamente para os ativos.
Inteligência Ativa:
Esta seção mostrará os métodos e resultados de tarefas como mapeamento de
infraestrutura, varredura de portas e avaliação de arquitetura e outras atividades de
pegada. Esta seção se concentrará nas técnicas utilizadas para traçar o perfil da
tecnologia no ambiente do CLIENTE, enviando tráfego DIRETAMENTE para os
ativos.
Inteligência Corporativa:
As informações sobre a estrutura da organização, unidades de negócios, participação de
mercado, verticais e outras funções corporativas devem ser mapeadas tanto para o
processo de negócios quanto para os ativos físicos previamente identificados que estão
sendo testados.
Inteligência Pessoal:
Toda e qualquer informação encontrada durante a fase de coleta de inteligência que
mapeia os usuários para a organização do CLIENTE. Esta seção deve mostrar as
técnicas usadas para coletar inteligência, como depósitos públicos/privados de
funcionários, repositórios de correspondência, organogramas e outros itens que levam à
conexão entre funcionário/empresa.
Avaliação de vulnerabilidade:
Avaliação de vulnerabilidade é o ato de identificar as vulnerabilidades POTENCIAIS
que existem em um TESTE e a classificação de cada ameaça. Nesta seção, deverá estar
presente uma definição dos métodos utilizados para identificar a vulnerabilidade, bem
como a evidência/classificação da vulnerabilidade. Além disso, esta seção deve incluir:
Níveis de classificação de vulnerabilidade
Vulnerabilidades Técnicas
Vulnerabilidades da camada OSI
Scanner encontrado
Identificado manualmente
Exposição geral
Vulnerabilidades Lógicas
Vuln NÃO OSI
Tipo de vulnerabilidade
Como/Onde é encontrado
Exposição
Resumo dos Resultados
Confirmação de exploração/vulnerabilidade:
A confirmação de exploração ou vulnerabilidade é o ato de acionar as vulnerabilidades
identificadas nas seções anteriores para obter um nível especificado de acesso ao ativo
alvo. Esta seção deve revisar detalhadamente todas as etapas tomadas para confirmar a
vulnerabilidade definida, bem como o seguinte:
Cronograma de Exploração
Alvos selecionados para exploração
Atividades de exploração
Ataque Dirigido
Hosts alvo não podem ser explorados
Hosts alvo que podem ser explorados
Informações individuais do anfitrião
Ataques conduzidos
Ataques bem-sucedidos
Nível de acesso concedido +caminho de escalonamento
Correção
Link para referência da seção Vuln
Técnica adicional de mitigação
Sugestão de controle compensatório
Ataque indireto
Phishing
Cronograma/detalhes do ataque
Alvos identificados
Proporção de sucesso/falha
Nível de acesso concedido
Lado do cliente
Alvos identificados
Lado do navegador
Alvos identificados
Pós-exploração:
Um dos itens mais críticos em todos os testes é a conexão com o impacto REAL no
CLIENTE que está sendo testado. Embora as seções acima retransmitam a natureza
técnica da vulnerabilidade e a capacidade de tirar vantagem da falha com sucesso, a
seção Pós-exploração deve vincular a capacidade de exploração ao risco real para o
negócio. Nesta área, os seguintes itens devem ser evidenciados através do uso de
capturas de tela, recuperação de conteúdo rico e exemplos de acesso privilegiado de
usuários reais:
Caminho de escalonamento de privilégios
Técnica usada
Aquisição de informações críticas definidas pelo cliente
Valor da informação
Acesso aos principais sistemas de negócios
Acesso a conjuntos de dados protegidos por conformidade
Informações/sistemas adicionais acessados
Capacidade de persistência
Capacidade de exfiltração
Eficácia da contramedida
Esta seção deve cobrir a eficácia das contramedidas implementadas nos sistemas
abrangidos. Deve incluir secções sobre contramedidas ativas (proativas) e passivas
(reativas), bem como informações detalhadas sobre quaisquer atividades de resposta a
incidentes desencadeadas durante a fase de testes. Uma lista de contramedidas que
foram eficazes na resistência às atividades de avaliação ajudará o CLIENTE a ajustar
melhor os sistemas e processos de detecção para lidar com futuras tentativas de intrusão.
Capacidade de detecção
FW/WAF/IDS/IPS
Humano
DLP
Registro
Resposta e eficácia
Risco/Exposição:
Uma vez qualificado o impacto direto ao negócio através das evidências existentes nas
seções de vulnerabilidade, exploração e pós-exploração, a quantificação do risco pode
ser realizada. Nesta seção, os resultados acima são combinados com os valores de risco,
a criticidade da informação, a avaliação corporativa e o impacto comercial derivado da
seção de pré-engajamento. Isto dará ao CLIENTE a capacidade de identificar, visualizar
e monetizar as vulnerabilidades encontradas durante os testes e ponderar efetivamente
sua resolução em relação aos objetivos de negócios do CLIENTE. Esta seção cobrirá o
risco comercial nas seguintes subseções:
Avalie a frequência de incidentes
frequência provável do evento
estimar a capacidade de ameaça (de 3 - modelagem de ameaça)
A estimativa controla a força (6)
Vulnerabilidade composta (5)
Nível de habilidade necessário
Nível de acesso necessário
Estimar a magnitude da perda por incidente
Perda primária
Perda secundária
Identifique a análise da causa raiz do risco
A causa raiz nunca é um patch
Identifique processos com falha
Derivar Risco
Ameaça
Vulnerabilidade
Sobreposição
Conclusão:
Visão geral final do teste. Sugere-se que esta seção repita partes do teste geral, bem
como apoie o crescimento da postura de segurança do CLIENTE. Deve terminar com
uma nota positiva, com o apoio e a orientação para permitir o progresso no programa de
segurança e um regime de testes/atividades de segurança no futuro.
Exploração
Conteúdo
 1Propósito
 2Contramedidas
o 2.1Antivírus
 2.1.1Codificação
 2.1.2Embalagem
 2.1.3Criptografando
 2.1.4Ignorar lista de permissões
 2.1.5Injeção de Processo
 2.1.6Residente puramente de memória
o 2.2Humano
o 2.3Prevenção de Execução de Dados (DEP)
o 2.4Randomização de layout de espaço de endereço
o 2,5Firewall de aplicativos da Web (WAF)
 3Evasão
 4Ataque de Precisão
 5Avenida de exploração personalizada
 6Explorações personalizadas
o 6.1Explorar personalização
 7Ângulo de dia zero
o 7.1Confuso
o 7.2Análise de código-fonte
o 7.3Tipos de explorações
 7.3.1Estouros de buffer
 7.3.2Sobrescrições SEH
 7.3.3Programação Orientada ao Retorno
o 7.4Análise de Tráfego
o 7,5Acesso Físico
 7.5.1Ângulo Humano
 7.5.2Acesso ao PC
o 7.6Acesso por proximidade (WiFi)
 7.6.1Ataques WiFi
 7.6.2Atacando o usuário
 8Exemplo de avenidas de ataque
 9Objetivo Geral
Propósito
A fase de exploração de um teste de penetração concentra-se exclusivamente
em estabelecer acesso a um sistema ou recurso, contornando as restrições de
segurança. Se a fase anterior, a análise de vulnerabilidade, foi realizada
corretamente, esta fase deve ser bem planejada e um ataque de precisão. O
foco principal é identificar o principal ponto de entrada na organização e
identificar ativos-alvo de alto valor.
Se a fase de análise de vulnerabilidade fosse devidamente concluída, uma lista
de metas de alto valor deveria ter sido cumprida. Em última análise, o vetor de
ataque deve levar em consideração a probabilidade de sucesso e o maior
impacto na organização.
Contramedidas
As contramedidas são definidas como tecnologias ou controles preventivos que
dificultam a capacidade de concluir com êxito uma via de exploração. Essa
tecnologia pode ser um sistema de prevenção de intrusões baseado em host,
um Security Guard, um firewall de aplicativos da Web ou outros métodos
preventivos. Ao realizar uma exploração, vários fatores devem ser levados em
consideração. No caso de uma tecnologia preventiva, deve ser considerada
uma técnica de evasão. Em circunstâncias em que isto não seja possível,
deverão ser considerados métodos de exploração alternativos.
No geral, o objetivo é permanecer furtivo ao atacar a organização; se os
alarmes forem acionados, o nível da avaliação poderá ser diminuído. Se
possível, as contramedidas devem ser enumeradas antes de acionar a
exploração. Isso poderia ser feito através de simulações do ataque ou
enumerando a tecnologia.
Antivírus
Antivírus é uma tecnologia que visa impedir a implantação de software
malicioso no sistema. Como testadores de penetração, devemos ser capazes
de identificar esses tipos de tecnologias antivírus e de nos proteger contra
elas. O antivírus é um pequeno subconjunto de todas as diferentes medidas
preventivas que podem estar em vigor, por exemplo, sistemas de prevenção de
invasões baseados em host, firewalls de aplicativos da Web e outras
tecnologias preventivas.
Codificação
Codificação é o método de ofuscar dados de uma forma que faz com que o
trecho de código implantado não pareça o mesmo. Com a codificação, o
ofuscamento geralmente ocorre ao embaralhar e reorganizar as informações
para ocultar o que o aplicativo está realmente fazendo.
Embalagem
A compactação é semelhante à codificação no sentido de que tenta reorganizar

os dados para compactar o aplicativo ou "empacotá-lo". A esperança disso é
que o executável ou parte do código entregue seja ofuscado de uma maneira
que não seja detectado por tecnologias antivírus.
Criptografando
A criptografia, assim como a codificação e a embalagem, é outro método de

manipulação do código executável pretendido, de modo que ele não seja
reconhecível ou disponível para inspeção. Somente após a descriptografia na
memória (com métodos semelhantes ao empacotamento) o código real é
exposto pela primeira vez - esperançosamente, depois que os mecanismos de
segurança permitirem sua passagem e ele for executado imediatamente após
ser descriptografado.
Ignorar lista de permissões
As tecnologias de lista branca aproveitaram um modelo confiável para

aplicativos que foram vistos em um determinado sistema por vez. A tecnologia
toma uma linha de base do sistema e identifica o que é normal ser executado
no sistema versus o que é estranho. O testador de penetração deve ser capaz
de contornar as tecnologias da lista branca. Um dos métodos mais comuns é
através do acesso direto à memória. A lista de permissões não tem a
capacidade de monitorar a memória em tempo real e se um programa
residente na memória estiver em execução e não tocar no disco, ele poderá ser
executado sem ser detectado pela tecnologia fornecida.
Injeção de Processo
A injeção de processo é simplesmente o método para injetar em um processo

já em execução. Ao injetar em um processo, as informações do aplicativo
podem ser ocultadas em um processo que normalmente seria confiável por
natureza. É muito difícil para a tecnologia de medidas preventivas inspecionar
processos em execução e quase sempre pode se esconder em um processo
diferente que o aplicativo consideraria confiável.
Residente puramente de memória
Os ataques residentes na memória são geralmente os mais preferidos, pois a

maioria das tecnologias não inspeciona a memória. Como invasor, seria mais
desejável encontrar uma maneira de viver puramente na memória. Ao gravar
em disco, a maioria dos aplicativos realizará varreduras, linhas de base e
outras identificações de software potencialmente malicioso. A capacidade de
ser detectado ao gravar no disco torna-se significativamente maior.
Humano
Ao realizar a exploração, nem sempre é o melhor caminho passar por uma
exploração direta ou por uma falha de aplicativo. Às vezes, o elemento humano
pode ser a melhor maneira de atacar uma organização. É importante
compreender a via de ataque correta e certificar-se de que o método que
estamos utilizando é o melhor caminho a seguir.
Prevenção de Execução de Dados (DEP)
Ao realizar a exploração, muitas medidas preventivas podem entrar em ação. A
Prevenção de Execução de Dados é uma medida defensiva implementada na
maioria dos sistemas operacionais e impede a permissão de execução quando
ocorre uma substituição na memória. O processo de pensamento por trás da
DEP é impedir que um invasor reescreva a memória e depois execute esse
código. Existem vários métodos para contornar a prevenção de execução de
dados e discutidos posteriormente na fase de exploração do PTES.
Randomização de layout de espaço de endereço
Durante uma vulnerabilidade de buffer overflow (ou qualquer coisa onde
controlamos a memória), os endereços de memória são codificados para
redirecionar o fluxo de execução para nosso shellcode. No caso de ASLR,
certos bytes são randomizados para evitar que um invasor preveja onde ele
pode ir para executar o shellcode.
Firewall de aplicativos da Web (WAF)
Firewalls de aplicativos da Web são uma tecnologia integrada a um aplicativo
para proteger contra ataques de aplicativos baseados na Web. Os firewalls de
aplicativos da Web tentam identificar ataques potencialmente perigosos ou
malformados em relação a um determinado aplicativo da Web e evitá-
los. Existem várias técnicas de desvio para firewalls de aplicativos da web e
devem ser testadas durante o teste de penetração.
Evasão
Evasão é a técnica usada para escapar da detecção durante um teste de
penetração. Isso pode ser contornar um sistema de câmeras para não ser visto
por um guarda, ofuscar suas cargas para evitar sistemas de detecção de
intrusões (IDS) ou sistemas de prevenção de intrusões (IPS) ou codificar
solicitações/respostas para contornar firewalls de aplicativos da web. No geral,
a necessidade de identificar um cenário de baixo risco para evadir uma
tecnologia ou pessoa deve ser formulada antes da exploração.
Ataque de Precisão
O foco principal de um teste de penetração é simular um invasor para
representar um ataque simulado contra a organização. O valor obtido por meio
de um teste de penetração geralmente não é através de técnicas de
esmagamento e captura, onde os ataques são barulhentos por natureza e na
tentativa de tentar todas as explorações. Esta abordagem pode ser
particularmente útil no final de um teste de penetração para avaliar o nível de
resposta da organização a incidentes, mas na maioria dos casos a fase de
exploração é um acúmulo de pesquisas específicas sobre o alvo.
Avenida de exploração personalizada

Cada ataque normalmente não será o mesmo na forma como ocorre a via de
exploração. Para ter sucesso nesta fase, o ataque deve ser adaptado e
customizado com base no cenário. Por exemplo, se for realizado um teste de
penetração sem fio e uma tecnologia específica estiver em uso, estes precisam
ser identificados e atacados com base nas tecnologias existentes. Ter uma
compreensão clara de cada cenário e da aplicabilidade de uma exploração é
um dos aspectos mais importantes desta fase do teste de penetração.
Explorações personalizadas
Em diversas ocasiões, as explorações públicas na Internet podem precisar de
algum trabalho para serem concluídas com êxito. Na maioria dos casos, se
uma exploração for projetada para o Windows XP SP2, serão necessárias
modificações específicas na exploração para que o ataque seja bem-sucedido
através do Windows XP SP3. O testador de penetração deve ter o
conhecimento necessário para poder personalizar uma exploração e a
capacidade de mudar rapidamente para concluir o ataque com êxito.
Explorar personalização
No caso de um ataque, muitas vezes é necessário simular a infraestrutura das
vítimas para garantir que a fase de exploração será bem-sucedida. As técnicas
utilizadas na fase de recolha de informação podem sempre ajudar nisso, no
entanto, ter uma infra-estrutura e sistemas funcionais em funcionamento
tornará a fase de exploração muito mais fácil. No caso de uma exploração
personalizada, o testador de penetração deve ser capaz de personalizar
explorações já públicas para atacar um sistema com sucesso. Um tema comum
para explorações é atingir versões específicas de sistemas operacionais ou
aplicativos. A razão para isso é devido à mudança de endereços de memória
com base em service packs e/ou novas versões do sistema operacional. O
testador deve ser capaz de personalizar essas explorações para implantá-las
com êxito em diferentes sistemas operacionais e comprometer o sistema com
êxito.
Ângulo de dia zero

Na maioria dos casos, o ângulo de dia zero costuma ser o último recurso para
a maioria dos testadores de penetração. Esse tipo de ataque geralmente
representa uma organização altamente avançada que pode lidar com um
ataque direcionado contra a organização por meio de métodos de ataque
normais. Em certos cenários, pesquisas podem ser conduzidas para fazer
engenharia reversa, fuzz ou realizar descoberta avançada de vulnerabilidades
que não foram descobertas. Caso este tipo de ataque seja aplicável, certifique-
se de que o ambiente, de acordo com o conhecimento do invasor, seja
reproduzido para incluir tecnologia de contramedidas.
Para que as explorações de dia zero sejam bem-sucedidas (ou qualquer
exploração nesse sentido), ter o mesmo sistema operacional, patches e
contramedidas é altamente importante para o sucesso. Às vezes, esta
informação pode não estar disponível com base no nível de acesso ou
enumeração que ocorreu.
Confuso
Fuzzing é a capacidade de recriar um protocolo ou aplicativo e tentar enviar
dados para o aplicativo na esperança de identificar uma vulnerabilidade. Muitas
vezes, a esperança de um fuzzer é identificar uma falha em um aplicativo e
criar uma exploração específica a partir dele. No caso de difusão, o invasor
está tentando criar uma vulnerabilidade específica a partir de algo que não foi
descoberto antes. Como parte de um teste de penetração, se nenhum caminho
for identificado durante o trabalho, ou se o trabalho exigir pesquisa de dia
zero; técnicas de difusão devem ser aproveitadas para identificar exposições
potencialmente vulneráveis.
Análise de código-fonte
Outros caminhos que um testador de penetração tem disponível é se o código-
fonte está disponível ou é de código aberto. Se o testador tiver a capacidade de
examinar o código-fonte e identificar falhas no aplicativo, as exposições de dia
zero também poderão ser identificadas por meio desses métodos.
Tipos de explorações
Existem vários tipos de explorações que podem ser identificadas durante um
teste de penetração que pode ser classificado como dia zero. Alguns estão
listados nesta seção.
Estouros de buffer
Estouros de buffer ocorrem devido a técnicas de codificação

inadequadas. Especificamente, isso geralmente ocorre quando um programa
grava dados em um buffer e, em seguida, ultrapassa o limite do buffer e
começa a sobrescrever partes da memória. Nas explorações de buffer
overflow, o objetivo do invasor é controlar uma falha e obter execução de
código em um determinado sistema. Em uma exploração de buffer overflow,
uma das técnicas mais comuns é sobrescrever um determinado registro e
“pular” para o shellcode.
Sobrescrições SEH
As substituições SEH ocorrem quando o manipulador de exceções estruturado

começa a fechar um aplicativo normalmente. O invasor pode manipular o
funcionamento do SEH, sobrescrever o endereço base do manipulador SEH e
obter controle do fluxo de execução por meio do SEH. Este é um ataque
comum aproveitado pela vulnerabilidade de buffer overflow e aplicativos que
foram cumpridos com SEH.
Programação Orientada ao Retorno
A Programação Orientada a Retorno (ROP) é uma técnica usada durante uma

parte em que o usuário tem controle do fluxo de execução, embora a
prevenção de execução de dados (DEP) ou outros mecanismos de defesa
impeditivos possam estar em vigor. Na situação em que a DEP está habilitada,
o invasor não tem acesso direto para executar instruções de montagem
específicas; portanto, o invasor cria um gadget ROP para preparar certas
chamadas ou técnicas da API do Windows para desabilitar a DEP ou contorná-
la. Um método comum é aproveitar a chamada WriteProcessMemory para
copiar dados da pilha para um espaço de memória gravável que pode então
ser executado.
Análise de Tráfego
A análise de tráfego é a técnica de identificar que tipo de informação está
sendo enviada e a capacidade de compreender e manipular esse tráfego. Um
testador de penetração deve ser capaz de compreender como funciona um
protocolo e como ele pode ser manipulado para alavancar um ataque.
Acesso Físico
O acesso físico durante um teste de penetração pode ser um método de
ataque viável para tentar contornar os controles de segurança física e obter
acesso não autorizado. Durante um teste de penetração, o avaliador deve ser
capaz de identificar controles de segurança física potencialmente falhos e
tentar obter acesso à instalação, se estiver dentro do escopo.
Ângulo Humano
Durante um teste de penetração física, algumas das maneiras mais óbvias

seriam fazer engenharia social para entrar nas instalações e obter acesso. Isso
requer um conhecimento significativo de como a organização realiza os
negócios e tudo o que você aprendeu na fase de coleta de inteligência.
Acesso ao PC
Se o acesso físico for concedido a um PC, o testador de penetração deverá ser

capaz de atacar o PC e obter acesso através de vários métodos que
permitiriam o acesso ao sistema.
Acesso por proximidade (WiFi)
As comunicações sem fio são uma via para ataques obterem acesso por meio
de comunicações do tipo RF. O testador de penetração deve visualizar a lista
de frequências de rádio da FCC para ver se o alvo registrou frequências de
espectro em uso.
Ataques WiFi
Independentemente do protocolo, existem vários ataques disponíveis para

WEP, WPA, WPA2, EAP-FAST, EAP-LEAP e outras vias. O invasor deve estar
familiarizado com os vários protocolos e padrões de criptografia e ser capaz de
testar com eficácia a implementação dos controles implementados.
Atacando o usuário
Aproveitar pontos de acesso não autorizados para atacar a vítima costuma ser
um método de ataque benéfico e viável. Aproveitar um ponto de acesso não
autorizado para atrair vítimas, a fim de aproveitar explorações ou roubar
informações confidenciais, deve ser realizado durante uma avaliação sem
fio. Existem várias técnicas comuns de uso disso, mas mais comumente o
invasor configuraria um ponto de acesso sem fio com o mesmo nome ou um
nome atraente para que a vítima se conectasse.
Exemplo de avenidas de ataque

Em qualquer cenário, os ataques devem consistir no cenário que está dentro
do escopo do engajamento. Abaixo está uma lista de vários caminhos de
ataque a serem considerados com base no cenário, mas não é de forma
alguma uma lista abrangente.
Ataques de Aplicações Web Engenharia Social Ataques Físicos Abordam
Explorações Baseadas em Memória (isto é, buffer/heap overflows, corrupções
de memória, uso após liberação). Man in the Middle VLAN Hopping
Implantação de USB/Flash Drive Engenharia reversa Ângulo de dia zero
Ataque ao usuário Quebra de criptografia Unidade de processamento gráfico
(GPU) Quebra de unidade de processamento gráfico Análise de tráfego
Protocolos de roteamento Firewire Phishing com pretexto Representação de
funcionário
Novamente, esses exemplos são apenas caminhos básicos para ataque com
base no cenário que você está executando para a organização. O valor de um
teste de penetração vem da criatividade e da capacidade de identificar
exposições e explorá-las de maneira precisa.
Objetivo Geral
Na fase de interação pré-engajamento com o cliente, deveria ter sido
comunicada uma definição clara dos objetivos gerais do teste de
penetração. No caso da fase de exploração, o maior desafio é identificar o
menor caminho de resistência para dentro da organização sem detecção e que
tenha o maior impacto na capacidade da organização de gerar receitas.
Ao executar as fases anteriores de maneira adequada, uma compreensão clara
de como a organização funciona e ganha dinheiro deve ser relativamente
compreendida. Desde a fase de exploração até à fase pós-exploração, os
vetores de ataque devem basear-se exclusivamente na missão de contornar os
controlos de segurança, a fim de representar como a organização pode sofrer
perdas substanciais através de um ataque direcionado contra a organização.
Pós-exploração
Conteúdo
 1Propósito
 2Regras de noivado
o 2.1Proteja o Cliente
o 2.2Protegendo-se
 3Análise de Infraestrutura
o 3.1configuração de rede
 3.1.1Interfaces
 3.1.2Roteamento
 3.1.3Servidores DNS
 3.1.4Entradas DNS em cache
 3.1.5Servidores proxy
 3.1.6Entradas ARP
o 3.2Serviços de rede
 3.2.1Serviços de escuta
 3.2.2Conexões VPN
 3.2.3Serviços de diretório
 3.2.4Vizinhos
 4Pilhagem
o 4.1Programas instalados
 4.1.1Itens de inicialização
o 4.2Serviços instalados
 4.2.1Serviços de segurança
 4.2.2Compartilhamentos de arquivos/impressoras
 4.2.3Servidores de banco de dados
 4.2.4Servidores de diretório
 4.2.5Servidores de nomes
 4.2.6Serviços de implantação
 4.2.7Autoridade Certificadora
 4.2.8Servidor de gerenciamento de código-fonte
 4.2.9Servidor de configuração de host dinâmico
 4.2.10Virtualização
 4.2.11Mensagens
 4.2.12Monitoramento e Gestão
 4.2.13Sistemas de Backup
 4.2.14Serviços de rede (RADIUS,TACACS..etc)
o 4.3Dados sensíveis
 4.3.1Registro de chaves
 4.3.2Captura de tela
 4.3.3Captura de tráfego de rede
 4.3.4Relatórios de auditoria anteriores
o 4.4Informação do usuário
 4.4.1No sistema
 4.4.2Navegadores da Web
 4.4.3Clientes de mensagens instantâneas
o 4,5Configuração do sistema
 4.5.1Política de senha
 4.5.2Políticas de Segurança
 4.5.3Redes e chaves sem fio configuradas
 5Alvos de alto valor/perfil
 6Exfiltração de dados
o 6.1Mapeamento de todos os possíveis caminhos de exfiltração
o 6.2Testando caminhos de exfiltração
o 6.3Medindo forças de controle
 7Persistência
 8Maior penetração na infraestrutura
o 8.1Do sistema comprometido
o 8.2Através do sistema comprometido
 9Limpar
Propósito
O objetivo da fase Pós-Exploração é determinar o valor da máquina
comprometida e manter o controle da máquina para uso posterior. O valor da
máquina é determinado pela sensibilidade dos dados armazenados nela e pela
utilidade da máquina em comprometer ainda mais a rede. Os métodos
descritos nesta fase destinam-se a ajudar o testador a identificar e documentar
dados confidenciais, identificar definições de configuração, canais de
comunicação e relacionamentos com outros dispositivos de rede que podem
ser usados para obter acesso adicional à rede e configurar um ou mais
métodos de acessar a máquina posteriormente. Nos casos em que estes
métodos diferem das Regras de Envolvimento acordadas, as Regras de
Envolvimento devem ser seguidas.
Regras de noivado
As seguintes Regras de Compromisso são específicas para a fase Pós-
Exploração de um teste de penetração e têm como objetivo garantir que os
sistemas do cliente não estejam sujeitos a riscos desnecessários pelas ações
(diretas ou indiretas) dos testadores e garantir um procedimento mutuamente
acordado a seguir durante a fase pós-exploração do projecto.
Proteja o Cliente
As seguintes regras devem ser utilizadas como orientação de regras a
estabelecer com um cliente para garantir que as operações e dados do dia a
dia do cliente não estejam expostos a riscos:
 Salvo acordo prévio, não haverá modificação de serviços que o

cliente considere “críticos” para sua infraestrutura. O objetivo de
modificar tais serviços seria demonstrar ao cliente como um invasor
pode:
o Escalar privilégios
o Obtenha acesso a dados específicos
o Causa negação de serviço
 Todas as modificações, incluindo alterações de configuração,
executadas em um sistema devem ser documentadas. Depois de
terminar o propósito pretendido da modificação, todas as
configurações devem retornar às suas posições originais, se
possível. A lista de alterações deve ser entregue ao cliente após o
trabalho para permitir que ele garanta que todas as alterações foram
desfeitas corretamente. As alterações que não puderam retornar às
suas posições originais devem ser claramente diferenciadas das
alterações que foram revertidas com sucesso.
 Deve ser mantida uma lista detalhada de ações tomadas contra
sistemas comprometidos. A lista deve incluir a ação tomada e o
período em que ocorreu. Após a conclusão, esta lista deverá ser
incluída como apêndice ao relatório final.
 Todos e quaisquer dados privados e/ou pessoais do usuário
(incluindo senhas e histórico do sistema) descobertos durante o teste
de penetração podem ser usados como alavanca para obter
permissões adicionais ou para executar outras ações relacionadas
ao teste somente se as seguintes condições forem atendidas :
o A Política de Uso Aceitável do cliente declara que todos os
sistemas são de propriedade do cliente e todos os dados
armazenados nesses sistemas são de propriedade do
cliente.
o A Política de Uso Aceitável afirma que a conexão à rede
do cliente é considerada consentimento para que a
máquina conectada seja pesquisada e analisada (incluindo
todos os dados e configurações presentes).
o O cliente tem a confirmação de que todos os funcionários
leram e compreenderam a Política de Uso Aceitável.
 As senhas (incluindo aquelas em formato criptografado) não serão
incluídas no relatório final ou deverão ser mascaradas o suficiente
para garantir que os destinatários do relatório não possam recriar ou
adivinhar a senha. Isto é feito para salvaguardar a confidencialidade
dos utilizadores aos quais pertencem as palavras-passe, bem como
para manter a integridade dos sistemas que protegem.
 Qualquer método ou dispositivo utilizado para manter o acesso a
sistemas comprometidos e que possa afetar o bom funcionamento
do sistema ou cuja remoção possa causar indisponibilidade não
poderá ser implementado sem o consentimento prévio por escrito do
cliente.
 Qualquer método ou dispositivo usado para manter o acesso a
sistemas comprometidos deve empregar alguma forma de
autenticação de usuário, como certificados digitais ou prompts de
login. Uma conexão reversa a um sistema controlado conhecido
também é aceitável.
 Todos os dados coletados pelos testadores devem ser criptografados
nos sistemas utilizados pelos testadores.
 Qualquer informação incluída no relatório que possa conter dados
confidenciais (capturas de tela, tabelas, figuras) deve ser higienizada
ou mascarada usando técnicas que tornem os dados
permanentemente irrecuperáveis pelos destinatários do relatório.
 Todos os dados recolhidos serão destruídos assim que o cliente
aceitar o relatório final. O método utilizado e a prova de destruição
serão fornecidos ao cliente.
 Se os dados recolhidos forem regulamentados por alguma lei, os
sistemas utilizados e as suas localizações serão fornecidos pelo
cliente para garantir que os dados recolhidos e processados não
violam nenhuma lei aplicável. Se os sistemas forem da equipe de
testes de penetração, os dados não poderão ser baixados e
armazenados em seus sistemas e apenas a prova de acesso será
mostrada (permissões de arquivos, contagem de registros, nomes de
arquivos, etc.).
 Não serão utilizados serviços de terceiros para quebra de senhas,
nem haverá compartilhamento de qualquer outro tipo de dados com
terceiros sem o prévio consentimento do cliente.
 Caso seja encontrada evidência de comprometimento anterior no
ambiente avaliado, todos os logs com ações e tempos registrados
durante a avaliação pela equipe de penetração serão salvos, hash e
fornecidos ao cliente. O cliente pode então determinar a melhor
forma de responder e lidar com a resposta ao incidente.
 Nenhum registro deve ser removido, apagado ou modificado, a
menos que especificamente autorizado a fazê-lo pelo cliente no
contrato de trabalho/declaração de trabalho. Se autorizado, será
necessário fazer backup dos logs antes de qualquer alteração.
Protegendo-se
Devido à natureza de um teste de penetração, você deve garantir que cobrirá
todas as suas bases ao lidar com o cliente e as tarefas que irá
executar. Discuta o seguinte com o cliente para garantir uma compreensão
clara das funções e responsabilidades do cliente e do fornecedor antes de
iniciar qualquer trabalho.
 Certifique-se de que o contrato e/ou declaração de trabalho assinado

pelo cliente e pelo fornecedor de que as ações tomadas nos
sistemas que estão sendo testados sejam em nome e em
representação do cliente.
 Obtenha uma cópia das políticas de segurança que regem o uso dos
sistemas e infraestrutura da empresa pelos usuários (geralmente
chamadas de políticas de "Uso Aceitável") antes de iniciar o
trabalho. Verifique se a política cobre:
o Uso pessoal de equipamentos e armazenamento de dados
pessoais de funcionários nos sistemas do cliente e
propriedade e direitos sobre esses dados.
o Propriedade dos dados armazenados nos equipamentos
da empresa.
 Confirme os regulamentos e leis que regem os dados que são
gerenciados e usados pelo cliente em seus sistemas e as restrições
impostas a tais dados.
 Use criptografia completa de unidade para os sistemas e mídias
removíveis que receberão e armazenarão dados do cliente.
 Discutir e estabelecer com o cliente os procedimentos a seguir caso
seja encontrado um compromisso de terceiros.
 Verifique a existência de leis relativas à captura e/ou armazenamento
de áudio e vídeo, uma vez que o uso destes métodos na pós-
exploração pode ser considerado uma violação das leis de escuta
telefônica locais ou nacionais.
Análise de Infraestrutura
configuração de rede
A configuração de rede de uma máquina comprometida pode ser usada para
identificar sub-redes adicionais, roteadores de rede, servidores críticos,
servidores de nomes e relacionamentos entre máquinas. Essas informações
podem ser usadas para identificar alvos adicionais para penetrar ainda mais na
rede do cliente.
Interfaces
Identifique todas as interfaces de rede na máquina juntamente com seus

endereços IP, máscaras de sub-rede e gateways. Ao identificar as interfaces e
configurações, as redes e os serviços podem ser priorizados para
direcionamento.
Roteamento
O conhecimento de outras sub-redes, filtros ou esquemas de endereçamento

poderia ser aproveitado para escapar de uma rede segmentada, levando a
hosts e/ou redes adicionais para sondar e enumerar. Esses dados podem vir
de diversas fontes em um determinado host ou rede, incluindo:
 Interfaces
 Tabelas de roteamento, incluindo rotas estáticas e dinâmicas
 Tabelas ARP, NetBios ou outros protocolos de rede usados para
descoberta de serviços e hosts.
 Para hosts multihomed, determine se eles estão agindo como
roteadores.
Servidores DNS
Identifique todos os servidores DNS em uso avaliando as configurações do

host. Os servidores DNS e as informações poderiam então ser usados para
desenvolver e executar um plano para descobrir hosts e serviços adicionais na
rede alvo. Caso um servidor DNS seja comprometido, o banco de dados DNS
fornecerá informações valiosas sobre hosts e serviços que podem ser usados
para priorizar alvos para o restante da avaliação. A modificação e adição de
novos registros poderiam ser utilizadas para interceptar os dados de serviços
dependentes do DNS.
Entradas DNS em cache
Identifique entradas DNS de alto valor no cache, que podem incluir páginas de
login para sites de intranet, interfaces de gerenciamento ou sites externos. As
interfaces armazenadas em cache fornecem informações do host mais recente
e mais usado pelo host comprometido, fornecendo uma visão das relações e
interações dos hosts, fornecendo informações que podem ser usadas para
priorizar alvos para maior penetração na rede e infraestrutura alvo. A
modificação das entradas em cache, se permitida, pode ser usada para
capturar credenciais de autenticação, tokens de autenticação ou para obter
mais informações sobre os serviços usados pelos hosts comprometidos,
levando a uma maior penetração na rede alvo.
Servidores proxy
Identifique servidores proxy em nível de rede e aplicativo. Os servidores proxy

são bons alvos quando usados em toda a empresa pelo cliente. No caso de
proxies de aplicação, pode ser possível identificar, modificar e/ou monitorar o
fluxo de tráfego, ou o próprio tráfego. Os ataques de proxy costumam ser um
meio eficaz de mostrar o impacto e o risco para o cliente.
Entradas ARP
Enumere entradas de tabelas ARP armazenadas em cache e estáticas, que

podem revelar outros hosts que interagem com a máquina comprometida. As
entradas estáticas do ARP podem representar máquinas críticas. Se o escopo
da avaliação permitir interceptar e modificar entradas ARP, é simples mostrar a
possibilidade de interromper, monitorar ou comprometer um serviço de uma
maneira que normalmente não é detectada ou protegida.
Serviços de rede
Serviços de escuta
Identifique todos os serviços de rede oferecidos pela máquina de destino. Isto

pode levar à descoberta de serviços não identificados pela varredura inicial,
bem como à descoberta de outras máquinas e redes. A identificação de
serviços não mostrados na varredura também pode fornecer informações sobre
possíveis sistemas de filtragem e controle implementados na rede e/ou
host. Além disso, o testador poderá aproveitar esses serviços para
comprometer outras máquinas. A maioria dos sistemas operacionais inclui um
método para identificar conexões TCP e UDP feitas de e para a máquina. Ao
verificar as conexões de e para uma máquina comprometida, é possível
encontrar relações que eram anteriormente desconhecidas. Assim como o
host, o serviço também deve ser considerado, pois isso pode revelar serviços
escutando em portas não padrão e indicar relações de confiança, como
autenticação sem chave para SSH.
Conexões VPN
Todas as conexões VPN de entrada e saída da máquina ou rede de destino

devem ser identificadas. As conexões de saída podem fornecer caminhos para
novos sistemas que podem não ter sido identificados anteriormente. Tanto o
inbound quanto o outbound podem identificar novos sistemas e possíveis
relacionamentos comerciais. As conexões VPN geralmente ignoram firewalls e
sistemas de detecção/prevenção de intrusões devido à sua incapacidade de
descriptografar ou inspecionar o tráfego criptografado. Este fato torna as VPNs
ideais para lançar ataques. Quaisquer novos alvos devem ser verificados
quanto ao seu escopo antes de lançar ataques contra eles. A presença de
conexões de cliente ou servidor VPN no host de destino também pode fornecer
acesso a credenciais anteriormente desconhecidas que poderiam ser usadas
para direcionar outros hosts e serviços.
Serviços de diretório
Um host direcionado executando serviços de diretório pode fornecer uma

oportunidade de enumerar contas de usuários, hosts e/ou serviços que podem
ser usados em ataques adicionais ou fornecer alvos adicionais que podem não
ter sido descobertos anteriormente na fase de análise de vulnerabilidade. Além
disso, os detalhes dos usuários encontrados nos serviços de diretório podem
ser usados para engenharia social e ataques de campanhas de phishing,
proporcionando assim uma possível taxa de sucesso mais alta.
Vizinhos
Na rede atual, muitos serviços e sistemas operacionais usam vários protocolos

para descoberta de vizinhos, em um esforço para tornar o acesso aos serviços,
a solução de problemas e a configuração mais convenientes. Os protocolos
variam dependendo do tipo de host de destino. Equipamentos de rede podem
usar protocolos como CDP (Cisco Discovery Protocol) e LLDP (Link Layer
Discovery Protocol) para identificar sistemas, configurações e outros detalhes
para hosts diretamente conectados a eles ou presentes na mesma sub-
rede. Da mesma forma, os sistemas operacionais de desktop e servidor podem
usar protocolos como mDNS (Multicast Domain Name Service) e NetBios para
encontrar detalhes de hosts e serviços na mesma sub-rede.
Pilhagem
Pilhagem refere-se à obtenção de informações (ou seja, arquivos contendo
informações pessoais, informações de cartão de crédito, senhas, etc.) de
hosts-alvo relevantes para os objetivos definidos na fase de pré-
avaliação. Essas informações podem ser obtidas com o propósito de satisfazer
metas ou como parte do processo de pivotamento para obter maior acesso à
rede. A localização desses dados variará dependendo do tipo de dados, da
função do host e de outras circunstâncias. O conhecimento e a familiaridade
básica com aplicativos comumente usados, software de servidor e middleware
são muito importantes, pois a maioria dos aplicativos armazena seus dados em
diversos formatos e locais. Podem ser necessárias ferramentas especiais para
obter, extrair ou ler os dados alvo de alguns sistemas.
Programas instalados
Itens de inicialização
A maioria dos sistemas terá aplicativos que podem ser executados na

inicialização do sistema ou no logon do usuário e que podem fornecer
informações sobre a finalidade do sistema, software e serviços com os quais
ele interage. Esta informação pode revelar potenciais contramedidas que
podem estar em vigor e que podem impedir uma maior exploração de uma rede
alvo e dos seus sistemas (por exemplo, HIDS/HIPS, Application Whitelisting,
FIM). As informações que devem ser coletadas incluem:
 Lista dos aplicativos e suas versões associadas instaladas no
sistema.
 Lista de atualizações do sistema operacional aplicadas ao sistema.
Serviços instalados
Os serviços em um host específico podem servir ao próprio host ou a outros
hosts na rede de destino. É necessário criar um perfil de cada host alvo,
observando a configuração desses serviços, sua finalidade e como eles podem
ser potencialmente usados para atingir objetivos de avaliação ou penetrar
ainda mais na rede.
Serviços de segurança
Os serviços de segurança compreendem o software projetado para manter um

invasor fora dos sistemas e manter os dados seguros. Isso inclui, entre outros,
firewalls de rede, firewalls baseados em host, IDS/IPS, HIDS/HIPS e
antivírus. A identificação de quaisquer serviços de segurança em um único host
de destino dá uma ideia do que esperar ao atacar outras máquinas na
rede. Também dá uma ideia de quais alertas podem ter sido acionados durante
o teste, que podem ser discutidos com o cliente durante o relatório do projeto, e
podem resultar em atualizações de Políticas de Segurança, UAC, SELinux,
IPSec, modelos de segurança do Windows ou outros sistemas de segurança.
conjuntos de regras/configurações.
Compartilhamentos de arquivos/impressoras
Os servidores de arquivos e impressão geralmente contêm dados direcionados

ou oferecem uma oportunidade de penetrar ainda mais na rede e nos hosts
alvo. As informações que devem ser direcionadas incluem:
 Compartilhamentos oferecidos por servidores de arquivos –

Quaisquer compartilhamentos de arquivos oferecidos pelos sistemas
de destino devem ser examinados. Mesmo apenas os nomes e
comentários dos compartilhamentos podem vazar informações
importantes sobre os nomes de aplicativos ou projetos internos (ou
seja, se apenas “Fred” e “Christine” tiverem acesso à pasta
“Contabilidade”, talvez ambos sejam funcionários de contabilidade).
 Listas de controle de acesso e permissões para compartilhamentos. -
Do lado do cliente, se for possível conectar-se ao compartilhamento,
então deve-se verificar se a conexão é somente leitura/gravação ou
leitura/gravação. Lembre-se de que se um compartilhamento contiver
diretórios, permissões diferentes poderão ser aplicadas a diretórios
diferentes. Do lado do servidor, a configuração do servidor e as
permissões de arquivo/diretório devem ser examinadas.
 Arquivo de compartilhamento de arquivos e listagens de conteúdo
 Identifique os arquivos de interesse nas listagens de
compartilhamento de arquivos. Procure itens interessantes ou
direcionados, como:
o Código fonte
o Cópias de segurança
o Arquivos de instalação
o Dados Confidenciais (dados financeiros em planilhas,
relatórios bancários em TXT/PDF, arquivos de senhas,
etc.)
 Coloque trojans ou arquivos de execução automática - Usando
nomenclatura inteligente ou imitando convenções de nomenclatura já
em uso, os usuários podem ser incentivados a executar essas
cargas úteis, permitindo que o testador penetre ainda mais na
rede. Se os logs do servidor de arquivos puderem ser obtidos,
usuários específicos poderão até ser visados.
Servidores de banco de dados
Os bancos de dados contêm uma riqueza de informações que podem ser alvo
de uma avaliação.
 Bases de dados - Uma lista de nomes de bases de dados pode

ajudar o avaliador a determinar a finalidade da base de dados e os
tipos de dados que a base de dados pode conter. Em um ambiente
com muitos bancos de dados, isso ajudará na priorização dos alvos.
 Tabelas - Nomes de tabelas e metadados, como comentários, nomes
de colunas e tipos também podem ajudar o avaliador a escolher
alvos e encontrar dados direcionados.
 Conteúdo da tabela, contagem de linhas para conteúdo
regulamentado
 Colunas - Em muitos bancos de dados é possível pesquisar todos os
nomes de colunas de todas as tabelas com um único comando. Isso
pode ser aproveitado para encontrar dados direcionados (por
exemplo, se os dados do cartão de crédito forem direcionados a um
banco de dados Oracle, tente executar select * from all_tab_columns
where name = '%CCN%'; .
 Permissões de banco de dados e tabelas
 Usuários, senhas, grupos e funções do banco de dados
As informações hospedadas em bancos de dados também podem ser usadas
para mostrar riscos, atingir objetivos de avaliação, determinar configuração e
função de serviços ou para penetrar ainda mais em uma rede de clientes e
hosts.
Servidores de diretório
Os principais objetivos de um serviço de diretório é fornecer informações aos

serviços e hosts para referência e/ou autenticação. O comprometimento deste
serviço pode permitir o controle de todos os hosts que dependem do serviço e
também fornecer informações que podem ser utilizadas para promover um
ataque. As informações a serem procuradas em um serviço de diretório são:
 Lista de objetos (Usuários, senhas, Máquinas..etc)

 Conexões com o sistema
 Identificação de protocolos e nível de segurança
Servidores de nomes
O servidor de nomes fornece resolução para host e serviços dependendo dos

tipos de registros que ele servidor. A enumeração de registros e controles pode
fornecer uma lista de alvos e serviços para priorizar e atacar para penetrar
ainda mais na rede e nos hosts de um cliente. A capacidade de modificar e
adicionar registros pode ser usada para mostrar riscos de negação de serviços,
bem como auxiliar na interceptação de tráfego e informações na rede de um
cliente.
Serviços de implantação
A identificação dos serviços de implantação permite o acesso e enumeração

de:
 Arquivos de resposta autônomos

 Permissão em arquivos
 Atualizações incluídas
 Aplicativos e versões
Essas informações podem ser usadas para penetrar ainda mais na rede e nos
hosts do cliente. A capacidade de modificar os repositórios e a configuração do
serviço permite
 Instalação de backdoor
 Modificação de serviços para torná-los vulneráveis a ataques
Autoridade Certificadora
A identificação dos serviços da Autoridade de Certificação em um host cliente

comprometido permitirá o acesso a
 CA raiz
 Certificados de assinatura de código
 Certificados de criptografia e assinatura
O controle do serviço também permitirá a
 Criação de novos certificados para diversas tarefas

 Revogação de certificados
 Modificação da lista de revogação de certificados
 Inserção de certificado CA raiz
O controle dos serviços apresenta riscos e permite o comprometimento de
dados e serviços na rede e nos hosts de um cliente.
Servidor de gerenciamento de código-fonte
A identificação de sistemas de gerenciamento de código-fonte pelo serviço em

execução no host comprometido ou na parte cliente do serviço oferece a
oportunidade para:
 Enumerar projetos - Os nomes dos projetos podem fornecer

informações confidenciais sobre os projetos da empresa.
 Verifique o acesso aos arquivos de código-fonte
 Modificar arquivos de código-fonte - Se for permitido no escopo, a
modificação do código-fonte prova que um invasor pode fazer
alterações que afetariam o sistema
 Enumerar desenvolvedores – Os detalhes dos desenvolvedores
podem ser usados para ataques de engenharia social, bem como
como entradas para atacar outras áreas do sistema
 Enumerar configuração
Servidor de configuração de host dinâmico
A identificação do serviço de configuração dinâmica do host ou o uso do

serviço pelo host comprometido permite:
 Locações de enumeração fornecidas

 Configuração de enumeração
 Opções de enumeração
 Modificação de configuração
 Consumo de todas as locações
O controle do serviço pode ser utilizado para mostrar risco de negação de
serviço e para uso em ataques man in the middle de hosts e serviços na rede
comprometida.
Virtualização
Os serviços de virtualização de identificação ou software cliente permitem:
 Enumerar máquinas virtuais (nome, configurações, sistema

operacional)
 Enumerar senhas e certificados digitais para sistemas de
administração.
 Enumerar a configuração do software de virtualização
 Configuração de hosts
 Mostrar risco de negação de serviço com controle do estado da VM
 Acesso a dados hospedados em VMs
 Interceptação de tráfego de hosts virtuais ou serviços hospedados no
host comprometido
Mensagens
A identificação de serviços ou software cliente para mensagens oferece a

oportunidade de
 Identificar serviços de diretório

 Comprometimento de credenciais
 Acesso a informações confidenciais
 Identificação de hosts na rede
 Relacionamentos de sistema e negócios
Todas essas informações e ações podem ser usadas para mostrar riscos e
penetrar ainda mais na rede e nos hosts de um cliente.
Monitoramento e Gestão
A identificação de serviços ou software cliente para fins de monitoramento e/ou

gerenciamento pode fornecer a identificação de servidores e serviços
adicionais na rede alvo, além dos parâmetros de configuração obtidos podem
fornecer acesso a outros hosts alvo e determinar quais ações executadas pelo
testador pode ser detectado pelo cliente. Alguns serviços a serem procurados:
 SNMP (protocolo simples de gerenciamento de rede)

 Registro de sistema
Alguns serviços de gerenciamento e software a serem procurados para obter
credenciais, identificar o host e obter acesso a outros serviços podem ser:
 Servidor/Cliente SSH
 Servidor/Cliente Telnet
 Cliente RDP (Protocolo de Área de Trabalho Remota)
 Servidor de terminal
 Software de gerenciamento de ambiente virtual
Sistemas de Backup
A identificação de serviços ou software cliente com a finalidade de fazer backup

de dados oferece uma grande oportunidade para um invasor, uma vez que
esses sistemas exigem acesso aos dados e sistemas de que precisam para
fazer backup, fornecendo ao invasor:
 Enumeração de hosts e sistemas

 Enumeração de serviços
 Credenciais para host e/ou serviços
 Acesso a dados de backup
As informações obtidas no serviço podem ser utilizadas para evidenciar risco à
confidencialidade, integridade e acesso ao sistema e suas informações. O
acesso aos backups também pode fornecer a oportunidade de introduzir
configurações incorretas, software vulnerável ou backdoors nos sistemas dos
clientes.
Serviços de rede (RADIUS,TACACS..etc)
A identificação de serviços ou o uso de serviços de rede permite:
 Enumeração de usuários
 Enumeração de hosts e sistemas
 Comprometimento de credenciais
 Mostrar risco de negação de serviço se métodos alternativos não
estiverem presentes
Dados sensíveis
Registro de chaves
Ao monitorar as teclas digitadas, é possível detectar informações confidenciais,

incluindo senhas e PII. Não sei qual é a legalidade disso se o usuário estiver
conversando em mensagens instantâneas privadas enquanto também usa o
software da empresa, alguém sabe? Se a empresa disser que todos os dados
da rede podem ser monitorados, tudo bem. Se o segundo ponto em Proteja-se
estiver presente e afirma que o uso do equipamento pode ser monitorado e
nenhum uso pessoal é permitido, sim, se a política não abrange o usuário
pessoal ou a propriedade dos dados, não. Deveria ser alargado para abranger
também a Rede.
Captura de tela
A captura de tela pode ser usada para mostrar evidências de

comprometimento, bem como o acesso às informações que podem ser
mostradas na tela e o acesso por outros meios não é possível. Deve-se ter
muito cuidado com os dados coletados através da captura de tela para não
mostrar dados privados de funcionários de clientes do cliente.
Captura de tráfego de rede
A captura de tráfego de rede pode ser usada dependendo dos controles na

rede e o meio usado para captura pode ser usado para:
 Identifique hosts na rede

 Interceptar dados
 Identificar serviços
 Identifique relações entre hosts na rede
 Captura de credenciais
Deve-se ter cuidado para capturar apenas o tráfego coberto pelo escopo do
contrato e para que as informações capturadas não caiam sob o controle de
leis locais, como a captura de chamadas de voz sobre IP. As informações
retidas e apresentadas devem ser filtradas de forma a proteger os dados
pessoais e confidenciais dos clientes e/ou funcionários do cliente.
Relatórios de auditoria anteriores
Informação do usuário
Nesta seção, o foco principal está nas informações presentes no sistema alvo
relacionadas às contas de usuários presentes no sistema ou que se
conectaram remotamente e deixaram algum rastro que o pessoal que realiza a
avaliação pode coletar e analisar para maior penetração ou fornecer o objetivo
desejado da avaliação.
No sistema
As informações gerais que podem ser coletadas em um sistema comprometido

são:
 Arquivos de histórico - Os arquivos de histórico armazenam

comandos recentes que o usuário executou. A leitura deles pode
revelar informações de configuração do sistema, aplicativos
importantes, locais de dados e outras informações confidenciais do
sistema.
 Chaves de criptografia (SSH, PGP/GPG)
 Documentos interessantes (.doc/x, .xls/x , password.*) - Os usuários
geralmente armazenam senhas e outras informações confidenciais
em documentos de texto não criptografado. Eles podem ser
localizados de duas maneiras: pesquisando nomes de arquivos em
busca de palavras interessantes, como password.txt, ou
pesquisando nos próprios documentos. Os serviços de indexação
podem ajudar com isso, por exemplo, o banco de dados de
localização do Linux.
 Parâmetros de configuração de aplicativo específicos do usuário
 Histórico de aplicativos individuais (somente MRU Windows,
arquivos de histórico..etc)
 Enumerar mídia removível
 Enumerar compartilhamentos de rede/permissão de domínio
(gpresult)
Navegadores da Web
As informações que podem ser coletadas de navegadores da Web e que

podem ser usadas para identificar outros hosts e sistemas, bem como fornecer
informações para penetrar ainda mais na rede e nos hosts de um cliente, são:
 Histórico do navegador
 Favoritos
 Histórico de downloads
 Credenciais
 Proxies
 Plug-ins/Extensões
Deve-se ter muito cuidado para que apenas os dados no escopo do trabalho
sejam capturados, uma vez que as informações de um navegador da Web
podem conter dados confidenciais e privados dos funcionários do
cliente. Esses dados devem ser filtrados dos dados retornados e do relatório.
Clientes de mensagens instantâneas
As informações que podem ser coletadas de clientes de mensagens

instantâneas em um sistema comprometido são:
 Enumerar configuração de conta (usuário, senha, servidor, proxy)

 Registros de bate-papo
Deve-se ter muito cuidado para que apenas os dados no escopo do trabalho
sejam capturados, uma vez que as informações de um navegador da Web
podem conter dados confidenciais e privados dos funcionários do
cliente. Esses dados devem ser filtrados dos dados retornados e do relatório.
Configuração do sistema
Política de senha
Ao enumerar a política de senha do sistema, a capacidade de usar força bruta

e quebrar senhas torna-se muito mais eficiente, por exemplo, sabendo que o
comprimento mínimo da senha é de 8 caracteres, você pode remover qualquer
palavra com menos de 8 caracteres de um dicionário.
Políticas de Segurança
Redes e chaves sem fio configuradas
Ao encontrar as informações sem fio dos alvos, torna-se possível lançar

ataques físicos através do wifi da empresa quando estiver no local. Ele também
pode permitir que um AP falso seja configurado para atrair alvos para se
conectarem quando estiverem fora do local.
Alvos de alto valor/perfil

Alvos de alto valor/perfil podem ser identificados e expandidos a partir dos
alvos identificados nas reuniões de pré-engajamento através da análise dos
dados coletados dos sistemas comprometidos e das interações desses
sistemas e dos serviços que neles são executados. a operação e as interações
dessas metas de alto valor/perfil ajudam na identificação e medição do impacto
que pode ser obtido para o negócio, nos dados e processos e na integridade
geral da infraestrutura e dos serviços do cliente.
Exfiltração de dados
Mapeamento de todos os possíveis caminhos de exfiltração
de cada uma das áreas onde o acesso foi conseguido, deverão ser criadas vias
de exfiltração completas. Isto inclui meios secundários e terciários de chegar ao
mundo exterior (através de diferentes sub-redes acessíveis, etc.). Uma vez
fornecido o mapeamento, o teste de exfiltração propriamente dito deve ser
iniciado.
Testando caminhos de exfiltração
De acordo com o mapeamento dos caminhos de exfiltração, os dados devem
ser exfiltrados da organização que está sendo testada. Isso já deve estar
coberto no escopo do pré-engajamento e uma infraestrutura adequada deve ter
sido configurada de acordo com a política de engajamento aceitável do cliente
(ou seja, os dados que estão sendo exfiltrados geralmente são exfiltrados para
um servidor com controle total do testador e terão acesso e propriedade direito
à organização testada). A exfiltração em si deve simular estratégias de
exfiltração do mundo real usadas pelos atores da ameaça que correspondem
ao Padrão de Modelagem de Ameaças relevante para a organização (ou seja,
se for criminoso principalmente, então a exfiltração "padrão" usando uma área
de preparação dentro da rede onde os dados são arquivados dentro de zip/ 7z
criptografados e, em seguida, enviados para servidores FTP/HTTP na Internet,
se for um ator de ameaça mais sofisticado, usando meios que simulem tais
estratégias e táticas usadas para exfiltração).
Medindo forças de controle
Ao realizar testes de exfiltração, o principal objetivo do teste é verificar se os
controles atuais para detectar e impedir que informações confidenciais saiam
da organização realmente funcionam, bem como exercitar as equipes de
resposta caso algo tenha sido detectado em termos de como elas reagem a
tais alertas e como os eventos estão sendo investigados e mitigados.
Persistência
 Instalação de backdoor que requer autenticação.

 Instalação e/ou modificação de serviços para conexão de volta ao
sistema. Usuário e senha complexa devem ser usados no mínimo; o
uso de certificados ou chaves criptográficas é preferido sempre que
possível. (SSH, ncat, RDP). Podem ser utilizadas conexões reversas
limitadas a um único IP.
 Criação de contas alternativas com senhas complexas.
 Quando possível, o backdoor deve sobreviver às reinicializações.
Maior penetração na infraestrutura

Pivotar é a ação na qual o testador usará sua presença no sistema
comprometido para enumerar e obter acesso a outros sistemas na
infraestrutura do cliente. Esta ação pode ser executada a partir do próprio host
comprometido usando recursos locais ou ferramentas carregadas no sistema
comprometido.
Do sistema comprometido
Ações que podem ser tomadas em um sistema comprometido:
 Carregar ferramentas
 Use ferramentas do sistema local
 Varredura ARP
 Varredura de ping
 Enumeração DNS da rede interna
 Enumeração de serviços de diretório
 Ataques de força bruta
 Enumeração e gerenciamento através de protocolos de
gerenciamento e credenciais comprometidas (WinRM, WMI, SMB,
SNMP..etc)
 Abuso de credenciais e chaves comprometidas (páginas da Web,
bancos de dados, etc.)
 Execute explorações remotas
A ação que será executada dependerá das informações necessárias para
demonstrar risco específico e/ou penetração adicional na rede e hosts do
cliente. Recomendam-se sessões regulares de planeamento para reavaliar a
informação recolhida e decidir a melhor abordagem para continuar a pós-
exploração até que os objectivos definidos sejam alcançados.
Através do sistema comprometido
Ações que podem ser tomadas através de um sistema comprometido:
 Encaminhamento de porta
 Proxy para rede interna (SSH)
 VPN para rede interna
 Executar exploração remota
 Abuso de credenciais e chaves comprometidas (páginas da Web,
bancos de dados, etc.)
A ação que será executada dependerá das informações necessárias para
demonstrar risco específico e/ou penetração adicional na rede e hosts do
cliente. Recomendam-se sessões regulares de planeamento para reavaliar a
informação recolhida e decidir a melhor abordagem para continuar a pós-
exploração até que os objectivos definidos sejam alcançados.
Limpar
O processo de limpeza cobre os requisitos para limpeza de sistemas após a
conclusão do teste de penetração. Isso incluirá todas as contas de usuário e
binários usados durante o teste.
 Remova todos os executáveis, scripts e arquivos temporários de um

sistema comprometido. Se possível, use o método de exclusão
segura para remover arquivos e pastas.
 Retorne aos valores originais das configurações do sistema e dos
parâmetros de configuração do aplicativo se eles tiverem sido
modificados durante a avaliação.
 Remova todos os backdoors e/ou rootkits instalados.
 Remova todas as contas de usuário criadas para conexão com
sistemas comprometidos.
Comunicando
Conteúdo
 1Visão geral
 2Estrutura do relatório
 3O Resumo Executivo
 4Relatório técnico
Visão geral
Este documento tem como objetivo definir os critérios básicos para relatórios
de testes de penetração. Embora seja altamente recomendável usar seu
próprio formato personalizado e de marca, o seguinte deve fornecer uma
compreensão de alto nível dos itens exigidos em um relatório, bem como uma
estrutura para que o relatório agregue valor ao leitor.
Estrutura do relatório
O relatório é dividido em duas (2) seções principais para comunicar os
objetivos, métodos e resultados dos testes realizados a diversos públicos.
O Resumo Executivo
Esta seção comunicará ao leitor os objetivos específicos do Teste de
Penetração e as descobertas de alto nível do exercício de teste. O público-alvo
serão aqueles responsáveis pela supervisão e visão estratégica do programa
de segurança, bem como quaisquer membros da organização que possam ser
impactados pelas ameaças identificadas/confirmadas. O resumo executivo
deve conter a maioria, senão todas, das seguintes seções:
Fundo:
A seção de antecedentes deve explicar ao leitor o objetivo geral do
teste. Detalhes sobre os termos identificados na seção Pré-engajamento
relacionados a riscos, contramedidas e metas de teste devem estar presentes
para conectar o leitor aos objetivos gerais do teste e aos resultados relativos.
(Exemplo: (CLIENTE) encarregou <Pentester> de realizar uma avaliação de
vulnerabilidade interna/externa e testes de penetração de sistemas específicos
localizados em (área lógica ou localização física). Esses sistemas foram
identificados como (classificação de risco) e contêm (nível de classificação de
dados ) dados que, se acessados de forma inadequada, podem causar danos
materiais ao (Cliente). Em um esforço para testar a capacidade do (CLIENTE)
de se defender contra ataques diretos e indiretos, <Pentester> executou uma
varredura abrangente de vulnerabilidade de rede, Conformação de
vulnerabilidade (<-inserir tipos de ataque acordados->) exploração de serviços
enfraquecidos, ataques do lado do cliente, ataques do lado do navegador (etc.)
O objetivo desta avaliação foi verificar a eficácia dos controles de segurança
implementados pelo (CLIENTE) para proteger informações críticas para o
negócio. Este relatório representa as conclusões da avaliação e as
recomendações de remediação associadas para ajudar o CLIENTE a fortalecer
a sua postura de segurança.
 Se os objetivos foram alterados durante o teste, todas as alterações

deverão ser listadas nesta seção do relatório. Além disso, a carta
retificativa deve ser incluída no apêndice do relatório e vinculada a
esta seção.
Postura Geral:
Esta área será uma narrativa da eficácia geral do teste e da capacidade dos
pentesters de atingir os objetivos estabelecidos nas sessões de pré-
engajamento. Uma breve descrição dos problemas sistêmicos (ex. problema
sistêmico = falta de processo de gerenciamento de patches eficaz vs.
sintomático = encontrado MS08-067 ausente na caixa xyz) identificados
através do processo de teste, bem como a capacidade de obter acesso às
informações do objetivo e identificar um impacto potencial para o negócio.
Classificação/Perfil de Risco:
A classificação/perfil/pontuação geral de risco será identificada e explicada
nesta área. Na seção de pré-engajamento, o Pentester identificará o
mecanismo de pontuação e o mecanismo individual para rastrear/classificar o
risco. Vários métodos de FAIR, DREAD e outras classificações personalizadas
serão consolidados em pontuações ambientais e definidos.
A “Pontuação de Risco Geral” para (CLIENTE) é atualmente Sete (7). Esta
classificação implica um risco ELEVADO de os controlos de segurança serem
comprometidos com o potencial de perdas financeiras materiais. O consultor
determinou essa pontuação de risco com base em uma vulnerabilidade de alto
risco e diversas vulnerabilidades de risco médio, juntamente com o sucesso do
ataque direcionado. A vulnerabilidade mais grave identificada foi a presença de
senhas padrão no site corporativo voltado para o público, que permitia o
acesso a vários documentos confidenciais e a capacidade de controlar o
conteúdo do dispositivo. Esta vulnerabilidade pode levar ao roubo de contas de
usuários, ao vazamento de informações confidenciais ou ao comprometimento
total do sistema. Várias vulnerabilidades menos graves podem levar ao roubo
de credenciais de contas válidas e ao vazamento de informações.
Constatações Gerais:
As conclusões gerais fornecerão uma sinopse dos problemas encontrados
durante o teste de penetração em formato básico e estatístico. Devem estar
presentes representações gráficas dos alvos testados, resultados de testes,
processos, cenários de ataque, taxas de sucesso e outras métricas de
tendência, conforme definido na reunião de pré-engajamento. Além disso, a
causa dos problemas deve ser apresentada num formato de fácil leitura. (ex.
Um gráfico mostrando a causa raiz dos problemas explorados)
Se definida no exercício de pré-engajamento, esta área também deve incluir

métricas que retratem a eficácia das contramedidas no ambiente. (por exemplo,
executamos x ataques e o IPS bloqueou y. Outras contramedidas também
devem ter métricas semelhantes de design versus eficácia.)
Resumo da recomendação:
A secção de recomendações do relatório deve proporcionar ao leitor uma
compreensão de alto nível das tarefas necessárias para resolver os riscos
identificados e o nível geral de esforço necessário para implementar o caminho
de resolução sugerido. Esta secção também identificará os mecanismos de
ponderação utilizados para priorizar a ordem de seguimento do roteiro.
Roteiro Estratégico:
Os roteiros devem incluir um plano priorizado para remediação dos itens
inseguros encontrados e devem ser ponderados em relação aos objetivos de
negócios/nível de impacto potencial. Esta seção deve mapear diretamente os
objetivos identificados, bem como a matriz de ameaças criada na seção PTES-
Modelagem de ameaças. Ao dividir-se em metas predefinidas baseadas em
tempo/objetivos, esta seção criará um caminho de ação a ser seguido em
vários incrementos. Exemplo:
Relatório técnico
Esta seção comunicará ao leitor os detalhes técnicos do teste e todos os
aspectos/componentes acordados como indicadores-chave de sucesso no
exercício de pré-engajamento. A seção do relatório técnico descreverá
detalhadamente o escopo, as informações, o caminho do ataque, o impacto e
as sugestões de correção do teste.
Introdução:
A seção de introdução do relatório técnico pretende ser um inventário inicial de:
 Pessoal envolvido nos testes do cliente e da equipe de testes de

penetração
 Informações de contato
 Ativos envolvidos nos testes
 Objetivos do teste
 Escopo do teste
 Força do teste
 Abordagem
 Estrutura de ameaça/classificação
Esta seção deve ser uma referência para os recursos específicos envolvidos
nos testes e para o escopo técnico geral do teste.
Coleta de informações:
A coleta de inteligência e a avaliação de informações são a base de um bom
teste de penetração. Quanto mais informado o testador estiver sobre o
ambiente, melhores serão os resultados do teste. Nesta seção deverão ser
redigidos alguns itens para mostrar ao CLIENTE a extensão da informação
pública e privada disponível durante a execução da fase de coleta de
Inteligência do PTES. No mínimo, os resultados identificados deverão ser
apresentados em 4 categorias básicas:
Inteligência Passiva:
Inteligência coletada de análises indiretas, como DNS, busca de informações
relacionadas a IP/infraestrutura do Google. Esta seção se concentrará nas
técnicas usadas para traçar o perfil da tecnologia no ambiente do CLIENTE
SEM enviar nenhum tráfego diretamente para os ativos.
Inteligência Ativa:
Esta seção mostrará os métodos e resultados de tarefas como mapeamento de
infraestrutura, varredura de portas e avaliação de arquitetura e outras
atividades de pegada. Esta seção se concentrará nas técnicas utilizadas para
traçar o perfil da tecnologia no ambiente do CLIENTE, enviando tráfego
DIRETAMENTE para os ativos.
Inteligência Corporativa:
As informações sobre a estrutura da organização, unidades de negócios,
participação de mercado, verticais e outras funções corporativas devem ser
mapeadas tanto para o processo de negócios quanto para os ativos físicos
previamente identificados que estão sendo testados.
Inteligência Pessoal:
Toda e qualquer informação encontrada durante a fase de coleta de
inteligência que mapeia os usuários para a organização do CLIENTE. Esta
seção deve mostrar as técnicas usadas para coletar inteligência, como
depósitos públicos/privados de funcionários, repositórios de correspondência,
organogramas e outros itens que levam à conexão entre funcionário/empresa.
Avaliação de vulnerabilidade:
Avaliação de vulnerabilidade é o ato de identificar as vulnerabilidades
POTENCIAIS que existem em um TESTE e a classificação de cada
ameaça. Nesta seção, deverá estar presente uma definição dos métodos
utilizados para identificar a vulnerabilidade, bem como a evidência/classificação
da vulnerabilidade. Além disso, esta seção deve incluir:
 Níveis de classificação de vulnerabilidade

 Vulnerabilidades Técnicas
o Vulnerabilidades da camada OSI
o Scanner encontrado
o Identificado manualmente
o Exposição geral
 Vulnerabilidades Lógicas
o Vuln NÃO OSI
o Tipo de vulnerabilidade
o Como/Onde é encontrado
o Exposição
 Resumo dos Resultados
Confirmação de exploração/vulnerabilidade:
A confirmação de exploração ou vulnerabilidade é o ato de acionar as
vulnerabilidades identificadas nas seções anteriores para obter um nível
especificado de acesso ao ativo alvo. Esta seção deve revisar detalhadamente
todas as etapas tomadas para confirmar a vulnerabilidade definida, bem como
o seguinte:
 Cronograma de Exploração
 Alvos selecionados para exploração
 Atividades de exploração
o Ataque Dirigido
 Hosts alvo não podem ser explorados
 Hosts alvo que podem ser explorados
 Informações individuais do anfitrião
 Ataques conduzidos
 Ataques bem-sucedidos
 Nível de acesso concedido +caminho
de escalonamento
 Correção
 Link para referência da
seção Vuln
 Técnica adicional de
mitigação
 Sugestão de controle
compensatório
 Ataque indireto
o Phishing
 Cronograma/detalhes do ataque
 Alvos identificados
 Proporção de sucesso/falha
 Nível de acesso concedido
o Lado do cliente
o Lado do navegador
Pós-exploração:
Um dos itens mais críticos em todos os testes é a conexão com o impacto
REAL no CLIENTE que está sendo testado. Embora as seções acima
retransmitam a natureza técnica da vulnerabilidade e a capacidade de tirar
vantagem da falha com sucesso, a seção Pós-exploração deve vincular a
capacidade de exploração ao risco real para o negócio. Nesta área, os
seguintes itens devem ser evidenciados através do uso de capturas de tela,
recuperação de conteúdo rico e exemplos de acesso privilegiado de usuários
reais:
 Caminho de escalonamento de privilégios

o Técnica usada
 Aquisição de informações críticas definidas pelo cliente
 Valor da informação
 Acesso aos principais sistemas de negócios
 Acesso a conjuntos de dados protegidos por conformidade
 Informações/sistemas adicionais acessados
 Capacidade de persistência
 Capacidade de exfiltração
 Eficácia da contramedida
Esta seção deve cobrir a eficácia das contramedidas implementadas nos
sistemas abrangidos. Deve incluir secções sobre contramedidas ativas
(proativas) e passivas (reativas), bem como informações detalhadas
sobre quaisquer atividades de resposta a incidentes desencadeadas
durante a fase de testes. Uma lista de contramedidas que foram eficazes
na resistência às atividades de avaliação ajudará o CLIENTE a ajustar
melhor os sistemas e processos de detecção para lidar com futuras
tentativas de intrusão.
o Capacidade de detecção
 FW/WAF/IDS/IPS
 Humano
 DLP
 Registro
o Resposta e eficácia
Risco/Exposição:
Uma vez qualificado o impacto direto ao negócio através das evidências
existentes nas seções de vulnerabilidade, exploração e pós-exploração, a
quantificação do risco pode ser realizada. Nesta seção, os resultados acima
são combinados com os valores de risco, a criticidade da informação, a
avaliação corporativa e o impacto comercial derivado da seção de pré-
engajamento. Isto dará ao CLIENTE a capacidade de identificar, visualizar e
monetizar as vulnerabilidades encontradas durante os testes e ponderar
efetivamente sua resolução em relação aos objetivos de negócios do
CLIENTE. Esta seção cobrirá o risco comercial nas seguintes subseções:
 Avalie a frequência de incidentes

o frequência provável do evento
o estimar a capacidade de ameaça (de 3 - modelagem de
ameaça)
o A estimativa controla a força (6)
o Vulnerabilidade composta (5)
o Nível de habilidade necessário
o Nível de acesso necessário
 Estimar a magnitude da perda por incidente
o Perda primária
o Perda secundária
o Identifique a análise da causa raiz do risco
 A causa raiz nunca é um patch
 Identifique processos com falha
 Derivar Risco
o Ameaça
o Vulnerabilidade
o Sobreposição
Conclusão:
Visão geral final do teste. Sugere-se que esta seção repita partes do teste
geral, bem como apoie o crescimento da postura de segurança do
CLIENTE. Deve terminar com uma nota positiva, com o apoio e a orientação
para permitir o progresso no programa de segurança e um regime de
testes/atividades de segurança no futuro.

Pentest Standard

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pentest Standard

Enviado por

Direitos autorais:

Formatos disponíveis

Organização de alto nível do padrão

O padrão de execução de testes de penetração consiste em sete (7) seções

Parte inferior do formulário

Organização de alto nível do padrão

Coleta de informações semipassiva : O objetivo da coleta de informações semipassiva é

Coleta de informações semipassiva : O objetivo da coleta de informações semipassiva é

Identificar limite de bloqueio

Identificar mecanismos de proteção

Proteções em nível de aplicativo

Funcionários Parceiros de negócios

Gestão (executiva, intermediária) Concorrentes

Administradores (rede, sistema, Empreiteiros

Engenheiros Estados da nação

Técnicos Crime organizado

Contratantes (com seus usuários

Script Kiddies (hacking

Script Kiddies (hacking

comunidade/agente agir com sucesso sobre a organização e comprometê-la. Esta análise

Verificadores de aplicativos da Web

Scanners de vulnerabilidade de rede/protocolos específicos

Teste manual/específico do protocolo

Remova todos os executáveis, scripts e arquivos temporários de um sistema

Remova todos os executáveis, scripts e arquivos temporários de um sistema

 2.1.4Ignorar lista de permissões

 2.1.6Residente puramente de memória

o 2.3Prevenção de Execução de Dados (DEP)

o 2.4Randomização de layout de espaço de endereço

o 2,5Firewall de aplicativos da Web (WAF)

 5Avenida de exploração personalizada

 7Ângulo de dia zero

o 7.6Acesso por proximidade (WiFi)

 8Exemplo de avenidas de ataque

A compactação é semelhante à codificação no sentido de que tenta reorganizar

A criptografia, assim como a codificação e a embalagem, é outro método de

As tecnologias de lista branca aproveitaram um modelo confiável para

A injeção de processo é simplesmente o método para injetar em um processo

Os ataques residentes na memória são geralmente os mais preferidos, pois a

Avenida de exploração personalizada

Ângulo de dia zero

Estouros de buffer ocorrem devido a técnicas de codificação

As substituições SEH ocorrem quando o manipulador de exceções estruturado

A Programação Orientada a Retorno (ROP) é uma técnica usada durante uma

Durante um teste de penetração física, algumas das maneiras mais óbvias

Se o acesso físico for concedido a um PC, o testador de penetração deverá ser

Independentemente do protocolo, existem vários ataques disponíveis para

Exemplo de avenidas de ataque

 3.1.4Entradas DNS em cache

 4.2.8Servidor de gerenciamento de código-fonte

 4.2.9Servidor de configuração de host dinâmico

 4.2.14Serviços de rede (RADIUS,TACACS..etc)

 4.3.3Captura de tráfego de rede

 4.3.4Relatórios de auditoria anteriores

 4.4.3Clientes de mensagens instantâneas

 4.5.3Redes e chaves sem fio configuradas

 5Alvos de alto valor/perfil

o 6.2Testando caminhos de exfiltração

o 6.3Medindo forças de controle

 8Maior penetração na infraestrutura

o 8.1Do sistema comprometido

o 8.2Através do sistema comprometido

 Salvo acordo prévio, não haverá modificação de serviços que o

 Certifique-se de que o contrato e/ou declaração de trabalho assinado

Identifique todas as interfaces de rede na máquina juntamente com seus