The document discusses prioritizing CVE research through automation. It begins by outlining challenges with manually researching the large number of CVEs, such as time consumption and human error. It then describes starting with a basic Python script to gather CVE data from sources and write it to a spreadsheet. The script evolved to incorporate more data sources and a scoring system to prioritize CVEs based on factors like availability of public proofs-of-concept, common affected products, and relevance to the organization. This developed into a full system with a dashboard interface to easily identify high priority CVEs for further study. The benefits of automated prioritization for security research are discussed.

1. Join Us:
https://www.linkedin.com/compa
ny/application-security-virtual-
meetups
QR Link:

2. AppSec Trends, Methodologies and
Toolsets
Useful tools and methods to spice up your penetration testing
routines
www.effectivesec.com
Shay Chen

3. Spicing up your application security tests
Spice it up
Fuzz,
Bruteforce
and Analyze
prior to
pentesting
Be a cheater
Obtain
information
relevant to
hacking the
app
Make it easy
Identify
alternative /
unprotected
replicas /
targets

4. Organizations will typically try to secure assets
they are either focused or even aware of –
But
What about assets & content they are NOT
aware of ?

5. WHY ?
Naïve and Unaware

6. Impacts
So what can go wrong ? right?

7. AWS Key leakage to Github

8. Code leakage to public
repositories

9. Targets & Methodology

10. Toolsets and Methodologies
▪ Unmonitored / Unprotected Assets
▪ Target associated assets of obsolete and/or unmonitored / or unprotected systems
▪ Dev / Test / Staging and Forgotten Replicas
▪ Ips not protected by WAF, TST/DEV replicas exposed to the internet, internal assets
▪ Unmonitored Applications
▪ Applications that can be found in unmonitored URLs and subdirectories
▪ Forgotten Entry points
▪ Hidden Pages
▪ Hidden APIs
▪ Hidden methods
▪ Hidden functionality through secret parameters

11. What’s the benefits
▪ Unprotected Ips and Replicas
▪ Test / Dev replicas tend to be less protected and with less hardening implementation
▪ Unprotected Ips won’t include mechanism that block automation / fuzzing / attacks
▪ Unmonitored systems, applications and entry points
▪ More likely to include security vulnerabilities
▪ Less likely to be covered by monitoring systems that will alert the organization SOC and/or
trigger the WAF/IDS/IPS

12. Attack Pattern Flowchart
Identify
Search
Tokens
Org/Bran
d/App
Names
Domains /
Sub-
domains
Favicons /
Titles
Acquire
Targets
Subdomain
Enumeratio
n
Associated
Server IPs
Cloud /
SAAS
Accounts
Search
Relevant
Informatio
n
Source
Code
Repositorie
s /
Containers
Leaked
Keys &
Credentials
Cached /
Indexed
Entry-
points
Initial
Attack
Sequence
Target
DEV/Test
Replicas
Tech
Specific
Fuzzing
Infrastruct
ure
Vulnscan /
Exploits
Vulnerabili
ty
Discovery
Good
Old
Pentestin
g
Exploitatio
n
WAF Bypass
via
IP/TST/DEV
Replicas
Manual
Exploitati
on
Analyze
Content for
Additional
entry
points

13. Toolsets and Methodologies
▪ VPNs
▪ Bypass IP address restriction – useful for block evasion and for accessing DEV/TST/Admin
instances
▪ Content Replicas
▪ Search via subdomains / associated domains
▪ Search via favicon hash / logo / title
▪ Code/Key/Credentials Discovery
▪ Technology specific code pattern search in github/gitlab/bitbucket/DOCKERHUB
▪ Fuzzing and Content Discovery
▪ Search engines and Caching engines
▪ Fuzzing specific technologies

14. Data Sources
▪ Search engine indexing
▪ DNS servers, domain registrant repositories, certificate repositories
▪ Data Sharing repositories (pastebin, etc.), credential repositories
▪ Unintentional “leftovers” in public organization documents
▪ Document metadata
▪ Credentials, URLs, images and emails in documents and help pages
▪ Public Source Code Repositories
▪ Github, Bitbucket, Gitlab, etc.
▪ Container repositories such as DockerHub
▪ Data unintentionally leaked in the past and CACHED in the internet
▪ Wayback Machine
▪ Google Cache
▪ Mirroring services/BD Search Engines

15. Identify Search Tokens
Brandnames, Apps, Subdomains, Icon Hash, Titles

16. Search tokens
▪ Organization / Application
▪ Brand name, CNs, alternate names
▪ Domains / Subdomains
▪ Search via subdomains / associated domains associated to the organization/app brand
▪ Certificates
▪ CN field
▪ O field
▪ Registrant email
▪ Favicon Hash
▪ https://mmhdan.herokuapp.com/
▪ https://github.com/kh4sh3i/Favicon-Hash
▪ Search via title / content
▪ Search via asset title or response content

17. Subdomain enumeration – search tokens

18. Org Names / Brand Names / Titles

19. Acquire / Identify Targets
Subdomain / Servers / Ips / SAAS
Accounts

20. Discover replicas / assets by signature
Organization
Subdomain
Certificate
Title
Favicon
Technology
Host/Server search
engines
Search tokens

21. Discover replicas / assets by signature

22. Search for relevant
information
Code, Containers, Keys, Credentials, Docs, URLs

23. Identify information relevant to search tokens
▪ Code / Keys / Credentials / URLs
▪ Github, Gitlab, Bitbucket, etc.
▪ Containers
▪ Dockerhub
▪ Employee / User Credentials
▪ Paste repositories
▪ Credential repositories (intelx / etc.)
▪ Documentation
▪ Default URLs / credentials
▪ Replicas
▪ Indexed URLs / credentials of technology replicas

24. Source Code Repositories

25. Data Sharing / Pasting Repositories

26. Identify entry points
Via fuzzing / analysis / cache

27. Identify entry points
▪ Cached Content
▪ Indexed URLs / content
▪ Wayback machine
▪ Fuzzing
▪ Identify directories and subdirectories
▪ Identify files and APIs
▪ Search content / log hacking
▪ Locate entry points in HTML/JS content displayed by the target site
▪ Search via similar systems
▪ Similar systems of the same developer
▪ Indexed pages of different deployments of the same application

28. Cached content - archive

29. Cached content - indexed

30. Fuzzing

31. Fuzzing for apps/directories

32. Fuzzing for entry points

33. Technology Specific Entry Point Discovery
Tech.
Fingerprint
Fuzzing
Shortname Scan
Microsoft CGIs
Secondary
Fuzzing
Tech.
Fingerprint
Fuzzing
AppServer
Content
Secondary
Fuzzing
Tech.
Fingerprint
Fuzzing
Server Content
Secondary
Fuzzing
Tech.
Fingerprint
Fuzzing
Route Content
Secondary
Fuzzing
Tech.
Fingerprint
Fuzzing
Server Content
Secondary
Fuzzing
ASP/.Net/MVC/C
ore
Java/JSP/JAXRS/Spri
ng
PHP / Drupal / Joomla /
WP
NodeJS / Express /
MeteorJS
Python / Flask /
Django

34. Content search

35. Questions

36. PAGE
Yuval Rabinowitz | Cyber Security Researcher at Pentera
Presentation actually by ChatGPT and Midjourney
Automating security research
prioritization
How to Calculate
CVE Reputation

37. PAGE
A little bit about me
37
Built Escape Rooms
while finishing my BCS
Joined the army -
Windows Forensics
and Incident Response
PENTERA
Cyber Security Researcher
Backend Developer
Lives in Ramat Gan, Israel
25 Years old

38. PAGE
CVE
Common Vulnerabilities and Exposures
CVE Structure
CVE - 2019 - 1214
Year Numbering
Prefix
Identical
for each ID
Four digits, year
of publication
Ongoing: four, five
or seven digits
38

39. PAGE
Identifying a Problem
• Task - Find the next CVE to research
39

40. PAGE
Identifying a Problem
• Task - Find the next CVE to research
• Challenges of manual CVE lookups
• Huge number of CVEs!
• Constantly changing
• Expensive man hours
• Time consuming
• Human error
40

41. PAGE
Identifying a Problem
• Task - Find the next CVE to research
• Challenges of manual CVE lookups
• Huge number of CVEs!
• Constantly changing
• Expensive man hours
• Time consuming
• Human error
41

42. PAGE
Identifying a Problem
• Task - Find the next CVE to research
• Challenges of manual CVE lookups
• Huge number of CVEs!
• Constantly changing
• Expensive man hours
• Time consuming
• Human error
• Side note - Midjourney drew me ->
42

43. PAGE
What happens when we have a lot of work to do?
So lets create
a python script
to do it for us!
43

44. PAGE
The evolution of a script
We will talk about:
• How we started with a small script and ended with a full infrastructure
• How we use this system to stay ahead of attackers
• Results and successes
• How we can improve this system in the future
44

45. PAGE
Automation challenges
• What service does the vulnerability affect?
• How harmful can it be were it to be implemented?
• Does it cause a denial of service?
Or maybe an entire system shutdown?
• What are the vulnerable products and versions?
• Could our existing clients be affected by them?
• Was there a big hype around it?
45
• Are they widespread enough that it’s reasonable
to think that future clients will be vulnerable?
• Is there a public PoC available?
That could save us days of researching
• Is the vulnerability attractive for an external
attacker
• And more
How can we automatically ID the importance of a CVE?
There are so many factors…

46. PAGE
Start small
• Lets create a POC, even if it just writes data to an Excel file
• We’ll start finding data sources online that can help us
• Importance of generic code from the start
• Basic data sources like - Nist NVD and RedHat
• Basic data like - CVE number, name, score, etc…
46

47. PAGE
GO
BIGGE
R
• The script begins to take shape - we even have a
database instead of Excel
• Let's add more advanced data sources based on
what might interest us if we were to search for a
CVE manually
• Can we find a public POC? Lets search on github!
• Is the CVE interesting?
Lets check on GoogleTwitteretc.!
• Is the vulnerable version common in the world?
Lets search on Shodan and ZoomEye!
• Does Pentera have users with vulnerable machines?
Lets integrate with our databases!
• And as many more as you can think of
47

48. PAGE
We have a lot of data! Now what?
• Let's look into the data and see how we can prioritize
• We should create a scoring system!
• Each data component has its own “weight”
• We can create a “formula” for calculating the score
• Heavily based on trial and error when starting
48

49. PAGE
Scoring system
• Main goal - Find the CVEs that are most critical for
our clients
• We need to think like an attacker
• Clients’ assets that are visible from the
Internet - External attack surface
• CVEs that have public POCs
• CVEs that can achieve code execution
• Every scoring system must be customized
49

50. PAGE
How can a hacker use it
50
Find the easiest
vulnerabilities to exploit
Immediately identify
vulnerabilities
when they arise
Automated attacks
from POCs

51. PAGE
Let's show our findings
• Let's turn our script into a system with a
clear interface to easily highlight our findings
• All of our data and scores are already in a database,
we only need to query it
• Open source system - Redash
• Server with a nice UI
• Supports queries and dashboards
51

52. PAGE
Let's show our findings
• Let's turn our script into a system with a
clear interface to easily highlight our findings
• All of our data and scores are already in a database,
we only need to query it
• Open source system - Redash
• Server with a nice UI
• Supports queries and dashboards
52

53. PAGE
Results
• After using the prioritizer for a short period, we found relevant CVEs to start researching
• The information and graphs are easily accessible for users to see
53

54. PAGE
Results
(Example)

55. PAGE
Results
(Example)

56. PAGE
Actual results on a client’s account!

57. PAGE
CVE Summary
• We did it! We saw immediate success.
• The system is now used by the product team to identify which CVE could cause the most damage
• The scoring system can still be tweaked to apply to more applications
• What else can we do?
57

58. PAGE
Expanding CVE Prioritizer's Capabilities
• Generic architecture for prioritization can allow us to use this system for whatever
we wish to prioritize
• For example: Static code analysis
58

59. PAGE
Expanding CVE Prioritizer's Capabilities
• Generic architecture for prioritization can allow us to use this system for whatever
we wish to prioritize
• For example: Static code analysis
• Inspects the source code without executing the program
• Identifies possible security vulnerabilities in the code
• Detects patterns that may lead to security breaches such as SQL injection, cross-site
scripting (XSS), and buffer overflow
59

60. PAGE
OSP Prioritization
• Scan open source projects (OSP)
• Identify the most common open source projects used by our clients
• Automatically run static code analysis scans on the projects
• Prioritize which projects may be vulnerable for additional research
60

61. PAGE
OSP Prioritization
Results (Example)

62. PAGE
OSP Prioritization - Results (Example)
• Example: ProFTPd
• Why did we choose the project?
• FTP server used by several of our clients that was identified as potentially vulnerable
• Initial findings showed the project was susceptible to almost 40 different code analysis queries
62

63. PAGE
OSP Prioritization - Results (Example)
63

64. PAGE
Next steps
64
AI Automated POC testing
● For open source projects
● For CVEs
Ongoing use
by our product
and research teams
1. 2. 3.

65. PAGE
Think like a hacker
• Hackers can do what we did automatically -
and without avoiding DOS attacks
• And they probably are
• We always need to find their next step, and if we can,
automate that process
65

66. Thank you!
Questions?
● Contact us at labs@pentera.io
● Read more Pentera Labs research at pentera.io/pentera-labs

67. Chasing Bug
Bounties

68. Beware, Hacker!!
Rotem Bar - Cyber Paladin - Ethical Hacker
Appsec Innovation Labs @ Palo Alto Networks

69. Why Hackers do Bug hunting?
Why Companies do Bug Hunting?
Going back to bug bounty hunters
Inside the mind of a bug hunter
Why should a company use them?
What do they actually do?
01
02
03
04 Summary

70. WHY do hackers Hunt?

71. Money
1. The more you hack the
more money you will
receive
1. One bug can get you
multiplications
2. Automate yourself for
passive income

72. Collaboration
1. Knowledge sharing
2. Give and Receive help
3. Part of a community
4. Together we push our
limits

73. Challenge
1. This is not a CTF. You
are the first person to
find this specific flaw
1. Hacking into the most
secure systems
1. Finding a new ZERO-
DAY

74. HERO
1. Make the world a safer
place
1. Help Humanity
1. Get Recognition

75. Compare to Pentest
Bug Hunting Pentest
Compensation
●Impact Based
●Endless
●Fixed
●Promised
●Capped
Challenge
●No Trivial issues
●Constant Competition
●Pre-Production
●First eyes
Coverage ●Statistical Only ●Time based

76. The Company
& Bug Hunting
Do we need pentest or bug bounty?

77. Code
Configuration
Servers
Cloud Assets
Apps
Code
Configuration
Servers
Cloud Assets
Apps
App
Developers
Code
Devops
IT
BI
Configuration
Servers
Cloud Assets
Apps
…
Company 101

78. Code
Configuration
Servers
Cloud Assets
Apps
Code
Configuration
Servers
Cloud Assets
Apps
App
Developers
Code
Devops
IT
BI
Configuration
Servers
Cloud Assets
Apps
…
Adding Security
Continuously
PR Scanning
IDE Scanning
Peer Review
–
App Scanning
Infra Scanning
Cloud Scanning
CVE Scanning
CICD Scanning
Yearly/Quarterly
Code Review
Configuration Audit
App Pentest
Infra Pentest

79. Reality Check
Continuously
PR Scanning No all languages supported, Needs appsec customization
IDE Scanning Many developers bypass this, work in unsupported ides
Peer Review Most developers don’t really look at security
–
App Scanning Crawlers get stuck, IDOR/BOLA not supported, …
Infra Scanning It’s all about the payloads, Hackers are learning much faster
Cloud Scanning Mainly CSPM and configurations, too many living assets going up and
down
CVE Scanning False positives, False Negatives, Too much results, No one validating
CICD Scanning Early stages of maturity, Attackers have the upper hand
Yearly/Quarterly
Code Review Audit only critical systems once a year, fix only the bugs
with severity
Configuration Audit high and above, Give the auditor company minimum resources and limit
App Pentest the time they have for each audit.
Infra Pentest Need a clean report for compliance and/or to send to
customers

80. Closing the GAP
Bug Bounty Hunters!!!

81. ● Recon
○ Scanning for new
assets
● New 1-Days
● Fuzzing Targets
● They don’t have a time limit..
Can go deep, learn your
systems and find those crazy
bugs
● Understand your systems
better than your security team
Heard about dependency
confusion?
They like to share with each
other, With the world
Scanning Manual Testing
New Tactics Community
What exactly do Bounty Hunters do?

82. BUT!! They are sensitive creatures
● They go with the interest/money
○ You have to engage them constantly
● They smell weak programs
○ If you have many duplicates, screw with them, They and their friends
will ditch you
● Have a large selection of customers
○ Need to focus them on hacking you (LHE, bonuses, new scope, …)

83. Some Bug Bounty Examples:

84. Do you have the bug bounty
Immune System in your company?

85. Does anyone have any
questions?
THANKS!

86. Thank You!
Questions?
To be continued…
https://www.linkedin.com/company/application-security-virtual-meetups