PTES reporting

Summary

このスクリプトは、渗透テストの報告フレームワークについて説明しています。生徒は、PTES（Penetration Testing Execution Standard）のサブセットを使用して、攻撃対象マシンの情報を収集し、脆弱性を見つけ出し、攻撃を行い、最終的には改善策を提案する報告書を作成することが求められます。報告書には、実行概要、技術報告、そして改善策の提案が含まれます。特に重要な点は、脆弱性に対する具体的な改善策を提供することです。

Takeaways

• 📝 レポートの目的は、最終レポートに関連し、Peterの指示に従うことです。
• 🔍 ペネトレーションテストの実施サマリーを含め、全ての対象マシンを1つの文書にまとめてください。
• 🎯 レポートには、目標を達成したレベルと推奨事項を簡潔に述べる必要があります。
• 🔒 報告書には、侵入できたホストとできなかったホストの両方を含めるべきです。
• 💡 情報収集やスキャンの実施を報告すると、ボーナスポイントが得られます。
• 🛠️ 脆弱性を見つけた場合、それを攻撃し、脆弱性が実際に存在することを確認することが重要です。
• 📈 脆弱性に対する攻撃が成功した場合には、どのようなエクスプロイトを使用したか、どの程度のアクセスを獲得したか、さらにアクセスを昇格させる方法についても報告する必要があります。
• 🚫 修正方法を含まないペネトレーションテストレポートは、価値がありません。
• 📋 レポートには、問題とその修正方法を明確に記載することが不可欠です。
• 📊 結論の章は必要ではありませんが、興味深い内容があれば短くまとめることができます。
• 📈 複数の脆弱性が存在する可能性があるため、全ての脆弱性を見つけることが求められます。

Q & A

Penetration testingの報告書にはどのような内容が含まれますか？

Penetration testingの報告書には、実行概要、ターゲットホストのリスト、情報収集、ホスト情報、見つかった脆弱性、実施された攻撃、脆弱性の悪用に成功したかどうか、どのような悪用手法が使用されたか、アクセスの昇格パス、そして最終的にどのように問題を修正するかの修正策が含まれます。

レポートの実行概要には何を含める必要がありますか？

実行概要には、バックグラウンド、達成された目標、推奨事項を簡潔に述べる必要があります。これは、コースの課題であるため、一般的なレベルで言及されます。

レポートでターゲットホストをリストアップする際に注意すべき点は何ですか？

レポートでターゲットホストをリストアップする際には、達成できていないホストも含めることが重要です。また、情報収集やスキャンを行ったにもかかわらず、実際に侵入できなかったホストについても報告することが求められます。

脆弱性に対する攻撃を実施する際にはどのようなことが重要ですか？

脆弱性に対する攻撃を実施する際には、脆弱性が実際に存在することを確認することが重要です。また、脆弱性が実際に活発ではない場合や、ホスト上で有効ではない場合についても報告することが求められます。

レポートで推奨される修正策を含める際に注意すべき点は何ですか？

修正策を含める際には、問題を示すだけでなく、どのようにして修正されるかのアドバイスも含める必要があります。具体的には、コードの修正方法を詳細に指示する必要はありませんが、問題点を明確にし、修正策を提案する必要があります。

レポートの技術部分にはどのような内容が含まれますか？

レポートの技術部分には、情報収集、脆弱性評価、悪用、昇格、そして修正策の詳細が含まれます。また、各ターゲットホストに対して特定のセクションを作成し、それぞれのホストに関する情報を記載することが求められます。

レポートの締めくだりや結論部分にはどのような内容が含まれますか？

締めくだりや結論部分には、テストの概要と、セキュリティ・ポスチャの改善に向けたアイデアが含まれます。ただし、この場合は結論部分が必ずしも必要ではなく、もし興味深い内容がない場合は一つか二つの文でまとめることも可能です。

PETRA標準のレポート構造についてどうやって理解できますか？

PETRA標準のレポート構造については、petrastandard.orgで技術ガイドラインをチェックすることができます。特にレポートの部分に焦点を当て、今日はレポートに関する情報のみを焦点にしています。

レポートの執筆において、どのようなポイントが評価に影響を与えますか？

レポートの執筆において、完全なレポートだけでなく、情報収集やスキャンの実施、攻撃の実施、昇格のパス、そして特に修正策の提案が評価に影響を与えます。不完全なレポートや修正策の提案が不足している場合は、評価からポイントが差し引かれる可能性があります。

レポートを提出する際に名前とコース名を含める理由は何ですか？

レポートに名前とコース名を含めることで、インストラクターはレポートを特定の学生に関連付けることができます。これは、学習プラットフォーム外でレポートを読む場合でも、インストラクターが学生とレポートを適切に関連付けることができるようにするものです。

PETRA標準でなくても、どのような一般的なPenetration Testingのレポートテンプレートを使用できますか？

PETRA標準でなくても、通常のレポートテンプレートを使用することができます。インストラクターからの要求は、レポートの表紙に名前とコース名を含めることで、レポートを特定の学生に関連付けられるようにすることです。

Outlines

00:00

📝 レポート制作とPenTestの基礎

この段落では、PenTestのレポート制作フレームワークと最終レポートに従う必要性について説明されています。PTES（Penetration Testing Execution Standard）のサブセットを使用し、ターゲットマシンの全てを含む一つの文書を作成することが求められています。レポートには、背景、目標、推奨事項、そして利用できなかったと成功したホストのリストが含まれます。また、情報収集、スキャン、攻撃の詳細と、期待されたが実際には効果なかった攻撃についても含めるべきです。

05:02

🎯 脆弱性と攻撃の詳細報告

この段落では、脆弱性を見つけ出し、攻撃を実施した際の詳細を報告することが重要であると強調されています。脆弱性に対する攻撃を検証し、どの脆弱性が実際に悪用可能かを確認し、使用した.Exploitの種類や得られたアクセスレベル、さらに特権昇格のパスを記録することが求められます。最後に、どのようにして脆弱性を修正するか、つまりどのようにホストを修正するかを含める必要があります。

10:02

📊 実行概要と技術報告の分割

この段落では、レポートの構造について説明されています。実行概要はビジネスのラインに向けていて、技術報告はより詳細な情報を提供します。実行概要では、セキュリティの状況やリスクの影響、推奨事項の概要を述べる一方、技術報告では個別のターゲットに焦点を当てた報告が行われます。また、脆弱性の確認と全ての脆弱性に対する攻撃を試みることが求められます。

15:02

🔍 情報収集と脆弱性評価

この段落では、情報収集と脆弱性評価の過程について説明されています。オープンソースインテリジェンスは除外され、アクティブインテリジェンスに焦点が当てられます。ポートスキャン、ソフトウェアバージョンの特定、そしてターゲットに対する攻撃を理解するための活動が含まれます。また、脆弱性評価では自動化ツールを使用して脆弱性をスキャンし、攻撃の実行には手動テストが行われます。

20:02

🚫 省略可能なセクションとレポートのフォーマット

この最終段落では、レポートのフォーマットと構造について説明されています。PTESの標準的なガイドラインに従い、実行概要、技術報告、そして推奨事項を含む必要があります。特定のセクション（例えば、間接攻撃やリスクと露出の評価）はこのコースでは省略可能であり、レポートの構造はシンプルで明確にすることが期待されています。また、レポートのフロントページには名前とコース名を含めるよう要求されています。

Keywords

💡Penetration Testing

Penetration Testing（侵入テスト）は、システムのセキュリティを評価するために行われるプロセスで、不正ユーザーがシステムに侵入し、データや機能に影響を及ぼす可能性を探るために、技術的な手法を用いてテストを行います。このビデオでは、Penetration Testingの実施方法と報告書の作成について説明されています。

💡Reporting Framework

Reporting Framework（報告書の枠組み）は、Penetration Testingの結果を効果的に報告するための構造化された方法です。この枠組みは、報告書に含めるべき要素や、それらをどのように記述するかを定義します。ビデオスクリプトでは、PTESのサブセットを使用して報告書を作成する手順が説明されています。

💡Executive Summary

Executive Summary（実行概要）は、報告書の概要を要約した部分です。このセクションは、ビジネスのリーダーや決定権を持つ人々がシステムのセキュリティ状況を理解するために読むことが想定されています。ビデオスクリプトでは、実行概要の重要性や、どのような内容を含めるべきかについて説明されています。

💡Technical Report

Technical Report（技術報告）は、Penetration Testingの詳細な結果を記録した部分です。このセクションでは、技術的な情報やデータ、脆弱性の詳細、攻撃手法、および修正策が含まれます。ビデオスクリプトでは、技術報告の作成方法と、どのようにターゲットごとに分割するかについて説明されています。

💡Vulnerabilities

脆弱性とは、システムのセキュリティにおける弱点のことを指します。これらの弱点は、攻撃者によって悪用される可能性があります。ビデオスクリプトでは、脆弱性の発見、分析、および報告について説明されています。

💡Exploits

Exploits（悪用）は、システムの脆弱性を利用して攻撃を行う技術的な手法です。Penetration Testingにおいては、発見された脆弱性を悪用して、攻撃者がシステムに侵入したり、データにアクセスしたりする可能性を検証するためにExploitsが使用されます。ビデオスクリプトでは、Exploitsの使用とその結果の報告について説明されています。

💡Privilege Escalation

Privilege Escalation（特権昇格）は、攻撃者がシステム内でより高い権限を持つアカウントにアクセスすることを指します。これにより、攻撃者はシステムの制御をより多く得ることができます。ビデオスクリプトでは、Penetration Testingにおいて特権昇格の経路を発見し、報告することの重要性について説明されています。

💡Remediation

Remediation（修正）は、発見された脆弱性やセキュリティの問題を解決するためのプロセスです。Penetration Testingの目的の一つは、問題点を特定し、それらを修正するためのアドバイスを提供することです。ビデオスクリプトでは、報告書においてどのように修正策を提案するかについて説明されています。

💡PTES

PTES（Penetration Testing Execution Standard）は、Penetration Testingの実施方法を標準化するための国際的なガイドラインです。ビデオスクリプトでは、PTESの一部を使用して報告書を作成するプロセスについて説明されています。

💡Information Gathering

Information Gathering（情報収集）は、Penetration Testingの最初のステップであり、ターゲットシステムに関する情報を集めることです。これには、オープンソースの情報を収集する手間不到な方法から、より深いfootprintingや脆弱性スキャンなどの技術的な手法までがあります。ビデオスクリプトでは、情報収集の重要性について説明されています。

💡Risk Management

Risk Management（リスク管理）は、組織が潜在的なリスクを識別、評価、および制御するプロセスです。セキュリティリスク管理の一環として、Penetration Testingの結果を使用して、リスクを評価し、適切な対策を決定します。ビデオスクリプトでは、リスク管理の技術的な詳細を省略し、Penetration Testingの実際の実施に焦点を当てています。

Highlights

The lecture focuses on reporting penetration testing and introduces the PTES (Penetration Testing Execution Standard) reporting framework.

Students are required to create a single document for their report, covering all target machines and including an executed summary, background, goals, and recommendations.

Bonus points are awarded for reports that include information gathering, scanning, and conducted attacks, even if penetration was not successful.

Reports should detail the vulnerabilities found, attacks conducted, and the level of access gained, including the escalation path to higher privileged accounts.

Remediation suggestions are crucial; a report without remediation steps is considered worthless for the company or blue team.

The report should include both an executive summary for non-technical stakeholders and a technical report for colleagues in the organization.

The executive summary should provide a high-level overview of the company's security posture, while the technical report should contain detailed guidance.

Students must successfully penetrate and escalate at least three machines and report on them to pass the assignment, with additional points for more machines.

Incomplete reports, especially those lacking remediation guidance, may result in the loss of half the points for the assignment.

Students are encouraged to submit their first report version by the end of March for feedback and potential improvement.

The PTES reporting structure includes an executive summary, technical report, and a focus on the impact to the business rather than listing every technical detail.

Reports should summarize recommendations for improving the company's security posture at a high level, such as creating a patch management process.

For the technical report, each target should have a specific section detailing information gathering, vulnerability assessment, and exploits.

Reports should include relevant details from vulnerability scans, avoiding irrelevant information for readability and clarity.

Students are not expected to perform client-side or browser-side attacks in this course, simplifying the report structure.

The report should document the path of privilege escalation and any countermeasures encountered during the testing.

Risk and exposure assessment is not required in the report, focusing instead on the direct attack and remediation steps.

Transcripts

so

uh welcome again to the lecture today's

topic is

the reporting penetration testing

reporting framework that we are going to

use the p test

and it's

closely related to your final report

since it should follow the peter's

instructions

and more specifically we are using a

subset of the standard

so you are not required to complete the

full peta standard report instead please

use this structure here

so

for your own report please create a

single

document that contains all the target

machines

and then

include these so include one executed

summary which describes quickly or

briefly what

what's the background uh in this case

this is a course assignment

um in general level the achieved

goals and then recommendations and then

list all the target hosts that you were

unable and you were able to exploit

so

for your report most of your create will

come from these

target hosts

that you were able to exploit but i will

grant

bonus points

for good reports that include

this

information

gathering

and

scanning and

conducted so

even if you are unable to actually

penetrate the host

please

include everything that you did or all

the information that you gathered

and all the attacks attacks that were

not really

uh that you ex

expected or assumed that would be

effective but turned out not to be so

just a reminder you are allowed to

report on other machines to not just the

ones that you were able to exploit

for the machines that you were able to

exploit

the same topics so information gathering

host information in this case these are

basically the same since

the target host or the target is an

individual host on all cases

then any vulnerabilities that you are

able to find um any attacks that you

conduct against those vulnerabilities

especially

just to verify that the vulnerability

exists or to find out that the

vulnerability isn't actually

active or

in this host

and then finally which vulnerabilities

you were success can be successfully

exploited

what kind of exploits did you actually

use

what level of access you gained what was

the escalation path so how did you gain

additional access once you gained so you

typically in these

penetration

tests you gain initial access on some

low level account and then you are able

to escalate to hire

more privileged account typically a root

account or an administrator account is

the

final target

and finally please do not forget

to include the remediation so so how

should this vulnerability or how should

this host be fixed

what the defenders should do

to actually

secure this machine

and this is always the most important

part of your feedback so

a penetration testing or a red team

report which

does not include any suggestions on how

to fix the situation is basically

worthless for the company for the

blue team for the software developers

so if you don't tell

how

the problems can be fixed then

no one is going to have time

to recreate the conditions and retest

and find out what happened instead

that's the main service that you are

providing as a penetration tester

you are telling

these are the problems and here are the

fixes

of course you don't have to give line by

line instructions

how to fix the code but you have to tell

what is the problem in the code that

should be

remediated

i hope that's clear and finally you can

basically

have a short conclusions chapter

but

if you don't

find anything interesting to write in

this chapter

it it can be one or two sentences long

so conclusions are not really necessary

in this case since you already have the

uh general executive recommendations

here

so the main split in these two parts is

executive summary is meant for the line

of business

this is for the people who have the

money but who do not have the technical

expertise

so here you should help them understand

what is the security posture of the

company

how secure they are how secure they

should feel themselves

and in the technical part you are giving

guidance to your uh your other your

colleagues in the organization the

people who are actually developing the

software

uh administering administering the

servers and so on

so technical part should contain

technical details executive summary

should contain just a high level

overview of the situation

and finally please remember that a

single target may contain more than one

exploitable vulnerability so

there can be and there are in couple of

the machines at least several

vulnerabilities

uh on some machines

they are on the

sort of initial access level

like in the target one there are at

least three ways of attacking that

machine

and on some machines they are

on the escalation path so there are at

least two or three different ways of

gaining

root access on those machines

so try

to

check everything

excuse me

once you have collected all the

information you have collected the

vulnerabilities please try to check all

of them don't just stop when you find

the first one

do a thorough job so

you are

being paid well in this case with uh

study credits but anyhow you are paid to

do a full scan and full attack on the

machine not just find a single entry

point

so this is not like the cpfs this is not

like the

in that sense these are not your typical

try hack me rules

where you are you expect to find one way

into the machine and then you just fill

in the

flags and be done with it

now these rooms

or of course they are try hackney rules

in the sense that that's where they are

hosted but they do contain at least some

of them do contain several

vulnerabilities

and for the

grading

so you have to find or you have to

successfully

penetrate and escalate at least three

machines and report on them that's a

one

great one and then for each

additional machine that you are able to

uh gain access to or gain root level

level access to gives you another point

up to

five so

and i may

deduct half a point for

incomplete report on a

host so you might lose basically half of

the points

for this assignment if you don't

include all the information especially

if you don't include remediation

guidance

so for that reason it's also a good idea

to also include the rest of the work

that you do because that will give you

bonus points back back and will give you

an idea

um and of course it's a good idea

to return

the first version already at the end of

the march because then you will receive

the feedback and hopefully you will see

where you can

make your report better and gain those

lost points back

okay

then for a couple of details on the

peta standard

and especially the reporting page so you

can check the whole peters technical

guideline on the petastandard.org

we'll focus only on the reporting here

for today

in the

sort of unabridged so the complete

report

the structure is the same so that's the

executing summary and then there's a

technical report

but especially the executive summary is

a lot more comprehensive than in our

document so

you are not required to do this security

risk rating

you don't have to generate risk scales

i believe you studied iso 27000

iso 27005

includes risk management techniques

let's leave it out of this report and

focus on the actual penetration testing

you don't have to create

risk origin category diagrams

you don't have to create road maps for

the fixes

so the only things that you should

document on some level is the

overall

okay the background

so

what you are doing the overall posture

so

what

what is the impact to the business

how badly things are

in the network if there is

something

a systemic

so

for example

lacking effective patch management

process so if it looks like the

uh

all the targets are missing missing

latest patches then that's

stuff that you can mention here

but

don't focus on these symptoms so even if

ms-08067

bug or deep

problem is on some host

please don't list them in this overall

posture those are the technical details

focus on what's

the impact to the business

and finally a summary of recommendations

so

you

have the

remediation descriptions for each target

then final once you are finished with

those pick

the

again the common theme

on those so what are the

what are the large steps that the

company should take to fix the security

posture so

all these message machines exist in one

company for this assignment

even though they don't look anything

like they would

exist in a single company

so what are the sort of

procedural or governmental issues

in the company

that you recommend them

to focus on to fix the security

not single technical fixes but

sort of

high level

for example

create a patch management process

conduct

quarterly

vulnerability scans

include vulnerability scanning in the

acceptance testing

that's sort of

already close to technical detail but

give the customer higher level

recommendations what to do how to create

the road map basically

you don't have to create the actual

roadmap so we are leaving that also out

of this

assignment

then for the technical report

so

here it's

in our case it's easiest if you split

the technical part

um

to a

target specific sections so create one

section for each target

from one to eight

missing two

you

probably will not be doing information

gathering you want to be doing passive

intelligence in this case the machines

are given to you

you receive the ib addresses and there

is really nothing

in in google or in anywhere else in the

internet

about these machines

so

the information gathering the open

source intelligence part can be left out

at this point

but you should

do the uh active intelligence so

this is the footprinting this is the

nmap scans this is

trying to find out so port scanning

identifying

the software versions stuff like that

trying to understand what are you are

up against

at this point

then corporate intelligence personal

intelligence

don't really con

concern us on this report

but vulnerability assessment

so this is the step where you

use the automatic automated tools to

scan

the

post

trying to find

any level

vulnerabilities in any technical level

of the target

[Music]

you

may

include a screenshot of the results

but please make sure that your results

are actually relevant

to the target host

so

don't just screenshot everything that

you do and include that

instead

either type out the relevant parts to

your report or screenshot things that

only contain

information that is

relevant one of the sort of

typical

problems with reports

on this course and on real life too is

on this step

you have to identify the operating

system

and

some have some level understanding of

the software versions that are installed

in the machine

so for example if you run the

nmap

vulnerability scan against the host

you will

find uh multiple occur occurrences of

the same cve

so that because the same cv i can't

recall now

what it is but there are are a couple of

cves that exist on all linux

distributions for example

so i don't want to see a report which

lists that this

host which we already know is a ubuntu

12.04 for example

contains

cve something something

for

oracle linux

because obviously

this cve concerns a different operating

system a different distribution it

cannot be relevant for this report

and especially if you have pages and

pages

of basically listing all possible linux

versions for example

that's not relevant that's not a good

report

so especially on those cases please just

pick

the relevant parts of the

output

and just include them

if you feel that you need to include

more information for completeness sake

then just create an appendix and include

it there that's a sort of

service for the

blue team

they can actually see

the scan and the results directly from

there but if

if you included it inside the actual

report it just makes it harder to read

then the exploits so

on this step you basically manually test

the vulnerabilities that you located in

the assessment phase

and at that point you basically check

whether this exploit works against this

host or not

there are exploits

that don't work

there are exploits that do work and then

there are exploits that should work but

for some reason just don't

you probably should report

though especially those that you believe

exist in the machine but you were unable

to actually get working

because um

that helps again the defenders

they might

identify that yes we are using an

exploitable or vulnerable version

but for some reason there is a some

configuration parameter

or there's

some closed port or non-standard

configuration option which for this case

prevented this exploit from running

these are things that you probably will

not be able to find out but the blue

team the

developers should have pretty good

understanding of

so

these are valid this is valuable

information

for the defenders

even if the attack is not successful

to understand

why you expected this attack to work

they can then verify from the source

code for example or fro from the

configurations that yep this actually

should have worked

except we had this parameter a bit

differently so if the attacker had

noticed this parameter they would have

been able

to exploit this vulnerability and they

then they can fix this

even if you were not able to gain access

through there

so don't leave

stuff out of the report just because you

were unable to exploit it

but please do

leave stuff out of the report that

should never be able to be exploited

against this host

so which is meant against a different

software version different uh operating

system

so on different processor architecture

what not

okay uh the indirect attack you can

basically skip completely

uh we are not performing these on this

course so no facing no client side

attacks no browser side attacks so

that's why i've left the directed attack

from the

structure

i've simplified this a bit

on that level too

and

rearranged it a bit too

okay and then we don't

really have to go to the post

exploitation so

yep you have to document the path that

you took

for the privilege escalation

it's sort of included here

but you don't have to evaluate

the countermeasure effectiveness

there is uh

at least one simple web application

firewall

or sort of

application level firewalling

going on in at least one of the machines

which does prevent

brute force attacks

after a couple of tries but

nothing really

heavily guarded on this

assignment

and finally you can leave the risk and

exposure

out of your report

and

so the conclusion as it says here

is that you echo portions of the test

and give ideas for the posture

yeah please do that but

you don't have to focus on the

conclusions so

the most

relevant part is the

directed attack this part here

what vulnerabilities exist what

vulnerabilities you were able to exploit

and

how you were able to escalate your

access and what are the remediation

steps that the defenders should take

that's the structure of a good report

and

as i mentioned this is the

this is the outline that i expect you to

use you can use

as your reporting

template

the

normal to us report template or just

grab a word template from the

default directory if you feel that

that's easier

what i do request is that include your

name and the course name on the front

page of the report so that that if i

have to

uh read them outside of its learning

i can still

attach them to you so that i can create

you

without too much default i should be

able to see them inside its learning and

then i can just directly create you

but just in case something happens

okay

any questions about

the peta's structure or the reporting

instructions at this point

okay

if not then

[Music]

thanks for listening i'll end the

english recording here and then we can

continue

with your specific questions