VKG2AG : Generating Automated Knowledge-Enriched Attack Graph

(AG) from Vulnerability Knowledge Graph (VKG)

Md Rakibul Hasan Talukder

, Rakesh Podder

and Indrajit Ray

Department of Computer Science, Colorado State University, Fort Collins, Colorado, U.S.A.

Keywords:

Attack Graph, Knowledge Graph, Security Vulnerability, Computer Network.

Abstract:

Attack Graph (AG) analysis is a well-established technique to asses security threats in networked systems.

However, traditional AGs primarily rely on coarse level vulnerability information from the Common Vulner-

abilities and Exposures (CVE) repository for identifying attack paths and suggesting patch-based mitigation

strategies. This approach presents signiﬁcant limitations, including unavailability of patches, compatibility

constraints, and system downtime, leaving security analysts without viable alternatives for optimized risk mit-

igation. To address this challenge, we propose two new paradigms: a novel knowledge-enriched AG frame-

work and a Vulnerability Knowledge Graph (VKG). VKG incorporate ﬁne-grained, structured vulnerability

information that allows exploration of additional attack mitigation strategies beyond vulnerability patching in

the AG analysis. We formally deﬁne VKG and AG along with algorithms for automated knowledge build-up,

integration, and querying. To ensure seamless interoperability, we develop an interface that facilitates dynamic

knowledge transfer between VKG and AG, enabling enhanced security reasoning without introducing inter-

dependencies. We evaluate our methodology on a test network and demonstrate how the knowledge-driven

AG can improve security decision-making by providing system administrators with adaptable, scenario-based

defense mechanisms with actionable insights.

1 INTRODUCTION

Attack Graph (AG) analysis (Lallie et al., 2017) is

one of the most effective ways to evaluate the under-

lying security posture of a large networked system.

The ability to provide meaningful insights in AG anal-

ysis depends heavily on the granularity of underly-

ing information from various sources (e.g., hosts, net-

works, vulnerabilities, attack frameworks), and how

the information is synthesized and used. In the vast

majority of state-of-the-art AG analysis techniques,

vulnerability information as available from the Com-

mon Vulnerabilities and Exposure (CVE) repository

is a major source of information on potential attacks

and recommended patching as defensive measures.

However, unavailable patches, compatibility issues of

published patches with existing services, and system

downtime during patching can leave decision-makers

without sufﬁcient alternative mitigation options. On

the other hand, in our research, we have observed that

CVE descriptions are being underutilized in many AG

https://orcid.org/0009-0007-7820-0853

https://orcid.org/0009-0008-7394-1369

https://orcid.org/0000-0002-3612-7738

CVSS Score

Published Date Vendor

Software

Affected Version

References

Description

Software

Published Date

CVSS Score

Vendor Source of Bug

Trigger to Bug

Reason

Attacker Action

System State

Networking State

Privilege Level

Consequence

User Interaction

Vulnerability

Type

Operating

System

Patch Available

References

Affected

Version

CVSS Score

Published Date

References

Description

Old CVE

Itemized CVE

New CVE

Figure 1: Potential of a CVE record (old & new).

analysis. As Figure 1 shows, there are many hidden

information in a CVE description that can provide

critical insights and actionable feedback for optimiz-

ing defense strategies without necessarily relying on

patching of the vulnerability. In this paper, we de-

velop a technique to better utilize CVE description for

AG Analysis.

Typically, AGs use the underlying vulnerability

information that can be readily extracted from the

CVE repository as attack attributes. The effective-

420

Talukder, M. R. H., Podder, R. and Ray, I.

VKG2AG : Generating Automated Knowledge-Enriched Attack Graph (AG) from Vulnerability Knowledge Graph (VKG).

DOI: 10.5220/0013526700003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 420-428

ISBN: 978-989-758-760-3; ISSN: 2184-7711

ness of AG Analysis for alleviating the patching prob-

lem is dependent on the relevancy of the extracted

information for mitigation strategies, the granular-

ity level of the vulnerability knowledge, the automa-

tion level of organizing, accessing, and transferring

knowledge, and the ﬂexibility of interfacing with the

system. There have been some works in extracting in-

formation from vulnerability descriptions using NLP

techniques. Unfortunately, these requirements im-

posed by AG analysis have not driven the attribute

extraction and utilization process.

To mitigate this, we propose a novel technique to

create a Vulnerability Knowledge Graph (VKG) that

synthesizes more relevant attributes extracted from

CVE (shown as ‘Itemized CVE’ in Figure 1) that is

then used to drive better AG generation and analysis.

A key advantage of a separate knowledge graph is that

it is independent of the AG generation process and the

target system’s conﬁguration. We also propose an in-

terface to seamlessly integrate information from the

VKG into AG. Our key contributions are as follows:

1. We developed an improved, detailed vulnerability

dataset, incorporating well-deﬁned, ﬁne-grained

attributes extracted from the CVE repository to

provide structured vulnerability information.

2. We designed a modular, ﬂexible Vulnerability

Knowledge Graph (VKG) that formalizes the data

structure and serves as an independent, integrable

source for organizing vulnerability attributes.

3. An interface between the VKG and AG has been

designed with necessary algorithms to enable

seamless dissemination of vulnerability attributes

into AG generation automatically.

4. We evaluated the effectiveness of our approach on

a test network and discussed how it can be effec-

tive for AG analysis.

2 RELATED WORK

There have been works on automating the incorpora-

tion of knowledge into Attack Graphs (AGs) in the

ﬁeld of automated AG generation AttacKG+ (Zhang

et al., 2024) is a framework to generate attack knowl-

edge graph via LLM techniques based on MITRE

TTP deﬁnitions. But the proposed framework did

not pay sufﬁcient attention to the detail of vulner-

ability weakness information. There were attempts

(Inokuchi et al., 2019; Jing et al., 2017) to incorporate

automatic extraction of vulnerability descriptions to

extend MulVal’s (Ou et al., 2005) capability to gener-

ate AG. Their deﬁnition of attack status (or condition)

either is not in granular details (Inokuchi et al., 2019)

or has some limited ﬁxed pre-deﬁned values (Jing

et al., 2017). In recent years, there have been few

works to build knowledge graphs from vulnerability

repositories. Anders et al. construct the knowledge

graph by performing NER using a pre-trained model

and relationship extraction between entities (Anders

et al., 2023). VulKG, is constructed from vulnera-

bility descriptions to ﬁnd a weakness (CWE) chain

in a graph (Yin et al., 2024). SecKG2vec provides

a combination of structural and semantic embedding

models to ﬁnd the relationship between CVE, CWE,

and CAPEC (Liu et al., 2025). However, VulKG or

SecKG2vec were not developed to interface with AG,

insufﬁcient to meet the required vulnerability knowl-

edge requirements for AG analysis.

The purpose of generating an AG is to perform

various analyses, such as analyzing large networks

efﬁciently (Ou et al., 2006), improving cyber-attack

modeling (Lallie et al., 2017), enhancing scalabil-

ity (Jia et al., 2015), risk analyzing (Poolsappasit

et al., 2011) or providing any mitigation solutions

(Ray et al., 2023; Bashir et al., 2024). However, the

main drawback the security researchers or system ad-

ministrators face is a structural and granular vulnera-

bility knowledge about the system/network. This in-

formation is critical for a resource-constrained envi-

ronment where performing cost-effective analysis for

patching or mitigating vulnerabilities is crucial. In

this paper, we address these issues and demonstrate

how our proposed method can solve these problems.

3 VULNERABILITY

KNOWLEDGE GRAPH (VKG)

CVE is the largest and widely used vulnerability

repository, where each record represents a vulnera-

bility in a semi-structured form. Our proposed Vul-

nerability Knowledge Graph (VKG) provides a more

structured and automation-compatible form of vulner-

abilities that preserves in-detail CVE information.

3.1 CVE Dataset for VKG

Currently, CVE records are semi-structured. The

data items we can retrieve directly from CVE (‘New

CVE’) records are: publishing date, description,

CVSS score, references, vendor, software, and af-

fected versions. Though recent CVEs provide vendor,

software and version information as individual data

items, the older ones mention them only in the de-

scription (as ‘Old CVE’ shown in Figure 1).

The most signiﬁcant but poorly deﬁned data item

of the CVE record is description. It contains the most

VKG2AG : Generating Automated Knowledge-Enriched Attack Graph (AG) from Vulnerability Knowledge Graph (VKG)

421

valuable information about the vulnerability. So, we

break the description item into multiple data items

with precise deﬁnitions. We also propose a few addi-

tional data items to address a vulnerability in a more

exhaustive manner. The additional items that can be

extracted from CVE description are marked with • in

the Table 1. Considering the new deﬁnition of a CVE

record, we build the most comprehensive and in-detail

vulnerability dataset, to the best of our knowledge.

We built ﬁne-detailed dataset based on the de-

ﬁned data types in Table 1. We have performed

prompt engineering via OpenAI Batch APIs on the

pre-processed data and extracted the desired data

items according to deﬁned data types. The detailed

mechanism to extract the redeﬁned data from vulner-

ability description is beyond the scope of this work.

3.2 Structure of VKG

The VKG is deﬁned as a tuple where V is a set of

nodes (vertices) and E denotes relationships (edges)

between those nodes.

V KG = ⟨V, E⟩

where,

V = {v

, v

....v

}, E = {(v

, v

)|v

, v

∈ V, i ̸= j}

Note that throughout this paper, we will use the

terms vertex and node interchangeably, so the words

relationship and edge.

Assumption: The deﬁnition of the VKG is based

on the dataset described in the previous sub-section

3.1. The incremental data items (as columns) in the

dataset can be easily integrated into the VKG.

3.2.1 Nodes, Types, Groups

Depending on the data types (Table 1), each vertex (or

node), v ∈ V is associated with exactly one data type

t ∈ T , where T is a set of all vertex types.

T = {V R, S, SV, SR, R, SS, NA, UI, P, OS, AA, T R, C, V T }

Type can be represented as function where each node v

corresponds to exactly one type t,

Type : V → T

So, V

⊆ V represents the set of vertices of type t ∈

T . For example, V

is a set of vertices of type Trigger,

is a set of vertices of type System State.

A group (G) is a collection of vertices of speciﬁc

types. We have identiﬁed ﬁve necessary characteris-

tics that essentially denote ﬁve groups of certain data

types. A group is expressed as a tuple of vertices of

pre-deﬁned types. The elaboration of each group with

permitted vertex types is given below:

Identity (I): An identity tuple is a group of three types

of vertices: v

vendor

, v

so ftware

and v

so ftware version

- which

provides sufﬁcient identiﬁcation information about the

vulnerability.

Origin (O): The origin tuple consists of two types of

vertices, v

source

and v

reason

- pointing exactly where and

why the vulnerability exists.

Exploiting Conditions (EC): This group includes,

but not limited to ﬁve types of vertices that repre-

sent necessary conditions to exploit the vulnerability:

operating system

, v

system state

, v

network access

, v

user interaction

and v

privilege

Actions (A): Any tuple from this group contains two

vertices: v

trigger

and v

attacker action

- that denotes the initi-

ation of the exploitation and manifestation of the attack

respectively.

Consequence (C): This tuple has only one element

consequence

representing consequence of the exploita-

tion.

3.2.2 Relationships, Edges

To understand the relationships in VKG, it is important

to realize that our knowledge graph is generated based

on published existing vulnerabilities (CVEs). So, each

vertex contains information about the associated CVEs

it has extracted from. Another important fact is that

multiple CVEs can correspond to a single vertex. For

example, a vertex v

= Execute remote code can be at-

tacker action for more than one CVE.

All the edges are directional. The connecting nodes

for an edge have f rom → to relationships between

them. Observing the nature of relationships between

different data types, we ﬁnd two kinds of relationships

(edges): static and dynamic. There are some types

of nodes (e.g., vendor, software, software version) that

maintain a ﬁxed relationship with their related nodes.

For example, for speciﬁc software (e.g., Windows), the

vendor is always ﬁxed (Microsoft), and this ownership

relation does not change across multiple CVEs. The

edge from v

= Microsoft to v

= Windows is consid-

ered as a static edge. Edges from vendor to software

(V − S) and software to software version (S − SV) rep-

resent static relationships in the VKG:

V − S ⊆ {(v

, v

)|v

∈ V

, v

∈ V

}

S − SV ⊆ {(v

, v

)|v

∈ V

, v

∈ V

}

It seems logical to deduce that the elements in Iden-

tity (I) tuple present static edges between them, which

indicates key identiﬁcation properties for any vulnera-

bility. V −S and S −SV can be combined in a 3-member

tuple I:

I = {(v

, v

)|v

∈ V

, v

∈ V

, v

∈ V

}

The rest of the tuple groups contain dynamic rela-

tionships between the elements of the tuple. For exam-

ple, the nodes for Exploiting Condition tuples do not

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

422

Table 1: Deﬁnition of different attributes of a vulnerability.• marked item can be extracted from CVE description

No. Data Type Deﬁnition Example

1 cve id Unique identiﬁer CVE-2020-12510

3 published date Date-time when published in CVE repository 2020-11-19T00:00:00

4 cvss score Vulnerability severity score assigned by NVD. It ranges from 1 to 10 7.3

5 vendor raw Name of the vendor that owns the software Beckhoff

6 software raw Vulnerable software name TwinCat XAR 3.1

7 vendor• Alt. vendor name Beckhoff

8 software• Alt. software name TwinCAT XAR 3.1

9 software version• Affected versions by the speciﬁc vulnerability. E.g., before version x.x , upto version y.y, from

x through y, x.x and prior etc.

all versions

10 operating system• If vulnerability requires any OS speciﬁcation to get exploited. E.g., Linux, windows,iOS, etc. Windows

11 source • Security bug where the initial weakness originates from. E.g., endpoint, webpage, API, compo-

nent, service, process, ﬁle, module, etc. Strongly speciﬁc to software and version

Default installation path and permissions

12 reason• Reason why the bug exists. E.g., improper validation, improper neutralization of input, etc.

Weakly speciﬁc to certain vulnerability. Multiple bugs can have common reason.

Installation path permissions allow local

user modiﬁcation

13 trigger• Initial action that exploits the security bug. Should be speciﬁc to the source of vulnerability Execution of TcSysUI.exe during user login

14 attacker action• Manifestation of attack. Additional details or steps to the trigger. May or may not be speciﬁc to

the vulnerable software’s security bug

Replace TcSysUI.exe with malicious code

15 user interaction• If any interaction is required from the user. Yes/No value. Detail of required interaction if Yes Yes, requires login by a high-privileged user

16 system state• Required system conﬁguration information for exploitation. Can be speciﬁc, like conﬁguration

cache enabled in GitHub Actions workﬂows and generic, like target device with physical access

Installation path at C:\TwinCAT with insuf-

ﬁcient permissions

17 network access• Type of access required to exploit the vulnerability. E.g., local access, remote access, network

access with HTTP or TLS or IIOP or T3 protocols, etc. Not strictly speciﬁc to the vulnerability

Local access

18 privilege• Level of privilege required to exploit the vulnerability. Can be generic, like user-level authen-

ticated, admin-level authenticated, unauthenticated, etc. Can be speciﬁc, like user must have

’clusters, get’ RBAC access (CVE-2023-40029)

Less privileged local account

19 vulnerability type• Type of vulnerability. Can be compared to CWE (Common Weakness Enumeration) Privilege Escalation

20 consequence• Consequence of successful exploitation. Can be speciﬁc, like ability to sign in admin web

portal. Can be generic malicious code execution

Allows execution of malicious code by

higher-privileged users

have any ﬁxed edges between certain values for any

data types like network access and privilege. Though

an edge exists between v

= local access and v

= with

less privileged local account for CVE-2020-12510, it is

not true across all CVEs.

O = {(v

src

, v

)|v

src

∈ V

src

, v

∈ V

}

EC = {(v

, v

, ..., v

)|v

∈ V

, v

∈ V

, ..., v

∈ V

}

A = {(v

, v

)|v

∈ V

, v

∈ V

}

C = {(v

)|v

∈ V

}

All the elements in the tuple (Except C) are in an or-

dered relationship. Order between data types in tuples

I, O, and A are considered ﬁxed, though Exploitation

Condition data types can be in different order. In this

work, we do not present implementation mechanism to

extract order relationships between EC tuples from spe-

ciﬁc CVEs; rather, we have assumed a common order

for the test implementation. The generation of tuples

for a group is performed by invoking cve-id as input to

different functions. Each function takes cve-id as input

and provides an ordered tuple as output.

: ID → I, id ∈ ID, i ∈ I

: ID → O, id ∈ ID, o ∈ O

: ID → EC, id ∈ ID, ec ∈ EC

: ID → A, id ∈ ID, a ∈ A

: ID → C, id ∈ ID, c ∈ C

where, ID = {cve − id

, cve − id

, .....cve − id

}

3.3 Implementation of VKG

The implementation of VKG is similar to any other

graph. Iteratively instantiating nodes and edges accord-

ing to the deﬁnition results in the whole VKG. Before

executing the VKG generation (algorithm 1), the dataset

and conﬁguration ﬁle must be ready. Details about the

dataset and its attributes are explained in sub-section

3.1.

VKG Conﬁg: The conﬁguration ﬁle VKG.conﬁg pre-

serves the deﬁnition and rules for generating the

VKG from VKG-Dataset. The VKG implementa-

tion provides the ﬂexibility to incorporate changes

or regenerate VKG conveniently. The generation al-

gorithm 1 and other functionality algorithms 2, 3,

and 4 need no changes. For example, a new data

type certiﬁcate expired has been introduced into the

dataset. To include this data type into ‘EXPLOIT-

ING CONDITIONS’ in VKG, only the VKG.conﬁg ﬁle

needs to be updated.

VKG Generation: This procedure takes the dataset

and conﬁg ﬁle as input and returns the VKG as out-

put. The initialization process pulls the conﬁguration

of types, groups, and static edge types into the vari-

ables. Then, iteratively for each CVE record, a list of

vertices is constructed according to the list of vertex

types. No new vertex is created if there is already an

existing vertex of the same type containing the same se-

mantic meaning. Vertices of the same type having com-

mon semantic meaning are consolidated into one repre-

sentative vertex. As a result, instead of creating vertex

for all the CVEs of the same data type, fewer vertices

are created to represent data items containing exactly

equal or similar meanings. A list of cve ids and refer-

ences of neighboring nodes are stored at each vertex.

After creating vertices for each CVE record, static and

all other edges are created according to CVE record and

VKG.conﬁg. Vertices and edges instantiated for each

CVE are merged to obtain the VKG.

VKG2AG : Generating Automated Knowledge-Enriched Attack Graph (AG) from Vulnerability Knowledge Graph (VKG)

423

Algorithm 1: VKG Generation.

Input: (VKG-Dataset, VKG.conﬁg )

Initialization:

v types ← initialize vertex types(V KG.con f ig.types);

groups ← initialize groups(V KG.con fig.groups);

static edges con fig, non static edges con f ig ←

initialize edge vertex types(VKG.con fig.st edges

types, VKG.con fig.non st edges types);

all vertices ← [ ];

all edgess ← [ ];

Output: V KG ← (all vertices, all edgess);

for each cve in VKG-Dataset do

cve vertices ← [ ] ;

for each type in v types do

v data ← get data(cve[type]);

vertex ← ∅

if get vertex(cve[cve-id],type) is ∅ then

rep vertex ← get representative vertex(type, v data);

if rep vertex is ∅ then

vertex ← create vertex(ty pe, type.grou p,

v data, cve[cve − id]);

else

vertex ← add cve id to rep vertex(rep

vertex, cve[cve − id]);

end

add to cve vertices(vertex);

end

all edges ← create edges(static edges con f ig,

non static edges con f ig, cve vertices);

all vertices ← merge(cve vertices);

end

VKG Functionality: The structure of VKG serves part

of the compatibility, and the rest is served by providing

query-in-VKG capability. Deﬁning and implementing

VKG as a graph provides the built-in analysis capability

as any generic graph, like traversal, shortest path, node

analysis, etc. To extract vulnerability knowledge and in-

terface with AG, 3 query functionalities have been pro-

vided and deﬁned below:

• get-group(cve id,group-name): This procedure

(Algorithm 2) extracts the tuple of vertices speci-

ﬁed by a cve id and a group name. This procedure

is used in mapping attributes of pre-conditions and

post-conditions to generate the AG (Algorithm 5).

Algorithm 2: Get Speciﬁc Group by CVE ID.

Input: (cve-id,VKG.conﬁg.groups[‘group name’])

Initialization:

group ← {group name : group name, tuple : ( )};

Output: group;

for each type in VKG.conﬁg.groups[group name] do

vertex ← get vertex(cve − id, type);

add to group tuple(vertex, group.tuple);

end

reorder tuple elements i f required(group);

• get-all-groups(cve id, VKG.conﬁg): This proce-

dure (Algorithm 3) provides more automation while

extracting the vertices for a speciﬁc CVE. All the

vertices wrapped in tuples are returned in a list. The

list can be iteratively used without knowing the ac-

tual group name.

• ﬁnd-path(cve id): The purpose of this method (Al-

gorithm 4) is to get all the vertices for a CVE in the

order of progression from identiﬁcation to conse-

quence.

Algorithm 3: Get All Groups by CVE ID.

Input: (cve-id,VKG.conﬁg.groups)

Initialization:

groups ← [ ]

Output: groups

for each group name in VKG.CONFIG.groups do

group ←

V KG.get group(cve − id, V KG.con f ig.groups[group name]);

add to groups(group);

end

Algorithm 4: Find Path for CVE ID.

Input: (cve-id,VKG.conﬁg)

Output: path

Initialization:

groups ← V KG.get all groups(cve− id, V KG.con f ig.groups);

path ← ( );

for each group in groups do

for each vertex in group do

add to path(vertex, path);

end

4 AG GENERATION FROM VKG

An Attack Graph (AG) is a hierarchical representation

used in network vulnerability management to showcase

the potential sequences and combinations of attacks that

could compromise a system. To perform any type of

“what-if analysis”, the most crucial step is generating a

detailed and structured AG. In this section, we deﬁne an

AG and explain the architecture behind automatically

generating AG from VKG.

4.1 Attack Graph (AG)

Traditionally, AG is deﬁned as a Directed Acyclic

Graph (DAG), where the nodes represent speciﬁc states

or conditions of interest to an attacker, while the edges

indicate the cause-consequence relationships. The AG

simpliﬁes the understanding of complex attack scenar-

ios by using explicit conjunctive and disjunctive branch

decompositions, offering a clear picture of the hierar-

chies present between attacker sub-goals. We are fol-

lowing the state-of-the-art deﬁnitions of attribute, at-

tack, and AG (Dewri et al., 2007).

Deﬁnition 1. The attribute-template (S

) refers to the

underlying categories or characteristics that make up

attributes of hosts, vulnerabilities, connections, etc.,

such as:

• host-level attribute-template (S

): associated with

host name, software, versions, etc.

• vulnerability-level attribute-template (S

): associ-

ated with CVEs, exploits, triggers, sources, etc.

• network-level attribute-template (S

): associates

with connectivity, port, IP address, access, etc.

For a network with multiple hosts, an attribute tem-

plate is deﬁned as S

= S

. This attribute

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

424

template helps in systematically structuring and orga-

nizing the critical information of a network.

Deﬁnition 2. An attribute (s) is a speciﬁc instance de-

rived from a broader category of properties (attribute-

template) concerning the network’s hardware or soft-

ware conﬁguration, host-id, port, IP, access, etc., which

can be either true or false. We denoted S as the set of

attributes where s ∈ S.

Each attribute-template (S

) points to a set of at-

tributes S that consists of particular types of attributes.

Deﬁnition 3. Given a set of attributes S, attack (A) is

deﬁned as a mapping A : S × S → {true, false}. a ∈ A

is deﬁned as a tuple of ⟨pre(a), post(a)⟩ and is valid if

pre(a) ̸= post(a) and post(a) is true iff pre(a) is true.

pre() ⊆ S and post() ⊆ S are the pre-conditions and

post-conditions of the attack, respectively.

Each attack is a result of exploring some vulnerabil-

ities in the network. For an attack to be successfully ex-

ecuted, an attacker has to satisfy the pre-conditions that

lead to exploitation and thus resulting post-conditions,

which an attacker leverages to launch further attacks in

the network. Once we sum up all the attacks and their

conditions, we can construct an AG.

Deﬁnition 4. Given a set of all attacks A, the Attack

Graph G is deﬁned as a tuple G = ⟨N , E⟩, where,

• N is the set of nodes such that each node n ∈ N

represents a state or condition of a host in the

network, captured by a function φ(n) = s

where

⊆ S.

• E ⊆ N × N is the set of directed edges. An edge

e = (n

, n

) ∈ E exists if and only if there exists

an attack a ∈ A such that: ⟨pre(a), post(a)⟩ =

true, φ(n

) ⊆ pre(a), and φ(n

) ⊆ post(a)

and pre(a), post(a) ⊆ S.

The relationship between nodes and edges can be

expressed as:

1. For every edge e = (n

, n

), n

and n

are distinct

nodes where:

∃a ∈ A : [φ(n

) ⊆ pre(a)]∧ [φ(n

) ⊆ post(a)].

2. Each edge e may also capture logical dependencies

between attacks:

• Conjunctive (AND) dependencies: for e =

, n

) is active if pre(a) =

∈N

φ(n

) ⊆ S.

• Disjunctive (OR) dependencies: e =

, n

) is active if pre(a) ⊆ φ(n

As we deﬁne AG as DAG, we assume that attacks

have no cyclic dependencies. However, for real-world

scenarios with feedback or loops, G may contain cy-

cles. Now to automatically construct the attacks and AG

from the VKG, we deﬁne a mapping function called λ

which maps the vertices value of VKG to an attribute

for the AG.

Deﬁnition 5. We deﬁne a mapping function λ, that

maps the vertices of VKG to the attributes of AG, such

as λ

: V → S and groups (G) of VKG to attribute-

template of AG, λ

: G → S

. For each vertex v ∈ V

in VKG, there exists an attributes s ∈ S in AG, captured

by the function λ

∀v ∈ V |λ

: v → s, where s ∈ S

Similarly, λ

maps groups (G) in VKG to attribute-

templates in AG as,

: I → S

: {V

, V

} → S

⊆ S;

: {O, EC, A, C} → S

: {{V

src

, V

}, {V

, V

, ..., V

, V

, }, V

} → S

⊆ S;

We assume that the connectivity template S

can

be obtained by using any network scanner. The in-

formation about vulnerability can be obtained from

VKG. So, we have the complete attribute-template S

. An attack a ∈ A on a node n

∈ N is de-

ﬁned by a set of tuples ⟨pre(a), post(a)⟩. From VKG

we can obtain all the Identity (I) vertices as the host-

level attributes:

: {v

, v

} → φ(n

)

Also, the pre(a) ⊆ S is related to the vulnerability and

host-level attributes, which can be obtained from the

VKG’s Identity (I), Origin (O), Exploiting Conditions

(EC), Actions (A) group of vertices.

: {{v

, v

}, {v

src

, v

}, {v

, ..., v

}, {v

, v

}} → pre(a)

And the post(a) ⊆ S of the node n

is nothing but the

Consequences (C) described in VKG.

: {v

} → post(a)

As previously deﬁned, the pre- and post-conditions

are a subset of attributes for AG. We automatically iden-

tify which group of vertices in VKG can be used for pre-

and post-conditions, and by using λ, we populate the

values for AG. The architecture and algorithm to gener-

ate AG from VKG are discussed in the next section.

4.2 Architecture for AG Generation

Figure 2 illustrates the overall architecture for automat-

ically generating AG from VKG. How the VKG is con-

structed is described in Section 3 along with algorithms

for VKG Generation (algorithm 1), ﬁnding groups (al-

gorithms 2, 3) and paths (algorithm 4).

The algorithm for generating AG from VKG (al-

gorithm 5) systematically constructs an AG based

VKG2AG : Generating Automated Knowledge-Enriched Attack Graph (AG) from Vulnerability Knowledge Graph (VKG)

425

Network

Configuration

(Host,

Vuln era bil it y,

Connectivity)

CVE Dataset –

from NVD,

MITRE

1. NLP, LLM

2. Redefined

Ontology for

CVEs

Vuln era bil it y

Knowledge

Graph Dataset

Vuln era bil it y

Knowledge

Graph

Configurations

VKG

Generation

Algorithm (1)

VKG

GET_GROUP

Algorithm (2)

VKG

GET_ALL_GRO

UP Algorithm (3)

VKG

GET_CVE_PATH

Algorithm (4)

AG Generation

Algorithm (5)

Vuln era bil it y

Knowledge

Graph

Attack Graph

Figure 2: Overall architecture for VKG to AG generation.

Algorithm 5: Attack Graph Generation from VKG.

Input: (VKG, Network Scan Data)

Output: (Attack Graph G = (N , E)

Initialization:

N ← [ ], E ← [ ], cve list ← [ ];

for each n in N do

n ← each host from network scan data;

cve list ← cve ids for each node n;

end

pre(a) ← [ ], post(a) ← [ ];

for each n in N do

for each cve id in cve list do

groups ← V KG.get all groups(cve− id, V KG.con f ig.groups)

for each group in groups do

if group.group name ==

′

Consequence

′

then

G ← V KG.get group(cve id, group.group name)

for each v in G.tuple do

if v.v data == ∅ then

skip;

end

post(a) ← {v.type : v.v data};

end

else

G ← V KG.get group(cve id, group.group name)

for each v in G.tuple do

if v.v data == ∅ then

skip;

end

pre(a) ← {v.type : v.v data};

end

for each e in E do

for i = 0 to i = n + 1, i + + do

e ← connections between (n

, n

i+1

) ∈ N ;

if e == ∅ then

if post(a

).value match any pre(a

i+1

).value then

e ← (post(a

));

end

on vulnerability information derived from both net-

work scan data and the VKG. For each CVE, rele-

vant groups from the Vulnerability Knowledge Graph

(VKG) are retrieved: “Consequence” data is stored

as post-conditions (post(a)), while others are stored

as pre-conditions (pre(a)). Edges are created between

nodes if any post(a) of one matches a pre(a) of the

next, forming a valid attack path. The algorithm out-

puts a graph G = (N , E), where N is the set of nodes

representing hosts in the network and E is the set of

edges representing potential attack paths.

5 EVALUATION

In this section, we demonstrate the effectiveness of our

approach by applying it to a test network.

5.1 Test Network & Host Information

Figure 3 shows the test network we used in this study.

We employ the topology of a server-based network.

The network is divided into two sub-networks: Sub-

Network 1 (demilitarized zone), and Sub-Network 2

(trusted zone). A DNS Server, Mail Server, and Web

Server are located in the DMZ (demilitarized zone). W-

1 & W-2 are services or applications ( on a machine) in

the Web Server, M-1 & M-2 for the Mail Server, and

D-1 & D-2 for DNS Server. There are three servers in

the TZ (trusted zone): the FTP Server with F-1, F-2, &

F-3, Database Server with S-1, S-2 & S-3, and Admin

Server with A-1 & A-2. Table 2 lists the vulnerabilities

present in this network.

Figure 3: Topology of Test Network.

Table 2: Vulnerabilities (CVE ID) on each server.

Host System Conﬁg: Vulnerabilities

Web Server

(192.168.1.1)

W-1: Script execution. (CVE-2020-11026)

W-2: Remote code execution. (CVE-2020-5902)

DNS Server

(192.168.2.1)

D-1: Remote Code Execution. (CVE-2021-26897)

D-2: Remote Code Execution. (CVE-2020-0718)

Mail Server

(192.168.3.1)

M-1: SQL Injection (CVE-2023-3087)

M-2: Unauthorized access and modiﬁcation due to type

juggling issue. (CVE-2023-6875)

Database Server

(192.168.4.1)

S-1: SQL Injection. (CVE-2024-26026)

S-2: Denial of Service. (CVE-2022-3931)

S-3: Improper validation of cstrings. (CVE-2021-20329)

Admin Server

(192.168.5.1)

A-1: Incorrect privilege assignment. (CVE-2020-1989)

A-2: Privilege Escalation. (CVE-2020-15264)

FTP Server

(192.168.6.1)

F-1: Privilege Escalation. (CVE-2021-1572)

F-2: Backdoor. (CVE-2021-33540)

F-3: Directory Traversal. (CVE-2020-29026)

5.2 VKG for Test Network

To incorporate the vulnerability knowledge into the AG

for the test network, we extract the vulnerability sub-

graphs from the generated global VKG. Depending on

each host conﬁguration in the test network, the ex-

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

426

Vendor: WordPress

Software: WordPress

Version: before 5.4.1

(patched in versions

5.4.1 and prior minor

releases)

Source: Media section

file upload

Reason: special crafted

file name handling

Trigger: uploading files

with a specially crafted

name

User Interaction: No

Network Access: Local

Privilege: Authenticated

user with file upload

privileges

W1-

Webserver

(WordPress)

CVE_id: CVE-

2020-11026

Consequences: Arbitrary

script execution upon

accessing the uploaded file

Vendor: F5 Networks

Software: BIG-IP

Version:15.0.0-15.1.0.3,

14.1.0-14.1.2.5, 13.1.0-

13.1.3.3, 12.1.0-12.1.5.1,

11.6.1-11.6.5.1

Source: Traffic

Management User

Interface (TMUI) or

Configuration utility

Reason: undisclosed

pages vulnerable to RCE

Trigger: Accessing

unspecified vulnerable

pages

User Interaction: No

Network Access: Remote

Privilege:

Unauthenticated

W2-

Webserver

(BIG-IP)

CVE_id: CVE-

2020-5902

Consequences: Execution

of arbitrary code on the

server

Attacker Action: Execute

remote code

Attacker Action:

uploading files with a

specially crafted name

Webserver

IP:192.168.1.1

Compromised

AND

Mail Server

IP:192.168.3.1

Compromised

Database

Server

IP:192.168.2.1

Compromised

Via Router-3

Via Router-1

System Config (AG)

VKG: Identity

Vulnerability Info (AG)

VKG: Origin, Exploiting Conditions, Actions

Vulnerability Info (AG)

VKG: Origin, Exploiting Conditions, Actions

System Config (AG)

VKG: Identity

System Config (AG)

VKG: Consequence

System Config (AG)

VKG: Consequence

Figure 4: Automatically generated knowledge-enriched Attack Graph (for Web Server).

tracted sub-graphs are different. First, we run a vul-

nerability scanner on each host that provides the CVE

identiﬁers (CVE IDs) for potential vulnerabilities (Ta-

ble 2). Using the CVE IDs, we search for the sub-

graphs on VKG using algorithms 2 and 3. The ex-

tracted sub-graph for each CVE contains all the ﬁne-

detailed vulnerability information in the form of nodes

and edges. All the vulnerability-related information can

be extracted from VKG by querying through cve id or

system information.

5.3 AG for Case Study

Once we gather all the information about the network,

hosts, and vulnerabilities, we construct AG using al-

gorithm 5. We extract the related vertices from VKG

and automatically generate the attack vector for CVE-

2020-11026 and CVE-2020-5902 associated with Web

Server. The post-conditions, derived from the VKG’s

“Consequence” vertices, indicate the ﬁnal state of ex-

ploitation, leading to Web Server compromise. Since

the vulnerabilities in WordPress and BIG-IP are in-

dependent of each other, the compromise of the Web

Server is represented with an ‘OR’ logic.

Once the Web Server is compromised, the attacker

can leverage its connectivity to other systems. Informa-

tion from the network scan reveals that the Web Server

connects to the Mail Server via Router 3, and the Mail

Server is connected to Database Server via Router 4.

This allows the attacker to penetrate further into the

network, expanding the AG as additional systems are

compromised. The iterative nature of this process illus-

trates how vulnerabilities propagate through a network,

enabling gradual and systematic construction of the AG

illustrated in Figure 4.

5.4 Discussion

Our knowledge-based AG is enriched with more com-

prehensive content, providing deeper insights for net-

work and system administrators. For instance, a con-

ventional AG might represent an attack vector for Web

Server as follows: ‘Exploit CVE-2020-11026 → Script

execution in WordPress → Web Server (W-1) compro-

mised’ or ‘Exploit CVE-2020-5902 → Remote code ex-

ecution in F5 BIG-IP → Web Server (W-2) compro-

mised’. The rest of the graph in traditional AG follows:

[CVEs] → [exploitations] → [compromise].

Our AG addresses previously mentioned limitations

by offering actionable alternatives to patch vulnerabil-

ities. For example, instead of simply recommending

‘patching CVE-2020-5902’, from our knowledge-based

AG, sys-admin can obtain multiple alternatives, such as

modifying the TMUI, altering the conﬁguration utility,

upgrading the BIG-IP version, restricting network ac-

cess from remote to local, or changing the authentica-

tion privileges, etc. Any of this information can provide

a suggestion to mitigate the vulnerability according to

the on-premise scenario. These options provide sysad-

mins with greater ﬂexibility to formulate optimal miti-

gation strategies.

Our dataset encompasses over 1,500+ categorized

CVEs, which, while not exhaustive, continues to ex-

pand as part of an ongoing effort.

6 CONCLUSION

In this work, we have addressed the challenges of en-

hancing Attack Graph (AG) analysis by integrating

more in-depth and meaningful vulnerability informa-

VKG2AG : Generating Automated Knowledge-Enriched Attack Graph (AG) from Vulnerability Knowledge Graph (VKG)

427

tion to support improved security planning. To achieve

this, we developed an architecture that leverages a sep-

arate Vulnerability Knowledge Graph (VKG), which

provides ﬁne-grained, structured insights into system

weaknesses. Unlike traditional approaches, our VKG is

built on a comprehensive, in-depth vulnerability dataset

and designed to function independently from the AG

while enabling seamless knowledge transfer. We for-

mally deﬁned the structure of both graphs along with

the algorithms for generation and querying, ensuring a

granular-level integration of vulnerability attributes into

the AG without introducing inter-dependencies. The fu-

ture goal is to develop automated mechanisms for up-

dating the VKG with emerging vulnerabilities, ensur-

ing its continued relevance and accuracy. Additionally,

incorporating a feedback loop from AG to VKG could

enable dynamic reﬁnement of vulnerability insights, fa-

cilitating more advanced reasoning and analysis.

REFERENCES

Anders, Lison, P., and Moonen, L. (2023). Construct-

ing a knowledge graph from textual descriptions of

software vulnerabilities in the national vulnerability

database. In Alum

ae, T. and Fishel, M., editors,

Proceedings of the 24th Nordic Conference on Com-

putational Linguistics (NoDaLiDa), pages 386–391,

orshavn, Faroe Islands. University of Tartu Library.

Bashir, S. K., Podder, R., Sreedharan, S., Ray, I., and Ray,

I. (2024). Resiliency graphs: Modelling the interplay

between cyber attacks and system failures through ai

planning. In 2024 IEEE 6th International Conference

on Trust, Privacy and Security in Intelligent Systems,

and Applications (TPS-ISA), pages 292–302. IEEE.

Dewri, R., Poolsappasit, N., Ray, I., and Whitley, D. (2007).

Optimal security hardening using multi-objective op-

timization on attack tree models of networks. In Pro-

ceedings of the 14th ACM conference on Computer

and communications security, pages 204–213.

Inokuchi, M., Ohta, Y., Kinoshita, S., Yagyu, T., Stan, O.,

Bitton, R., Elovici, Y., and Shabtai, A. (2019). De-

sign procedure of knowledge base for practical attack

graph generation. In Proceedings of the 2019 ACM

Asia Conference on Computer and Communications

Security, Asia CCS ’19, page 594–601, New York,

NY, USA. Association for Computing Machinery.

Jia, F., Hong, J. B., and Kim, D. S. (2015). Towards

automated generation and visualization of hierarchi-

cal attack representation models. In 2015 IEEE In-

ternational Conference on Computer and Informa-

tion Technology; Ubiquitous Computing and Commu-

nications; Dependable, Autonomic and Secure Com-

puting; Pervasive Intelligence and Computing, pages

1689–1696. IEEE.

Jing, J. T. W., Yong, L. W., Divakaran, D. M., and Thing,

V. L. L. (2017). Augmenting mulval with automated

extraction of vulnerabilities descriptions. In TENCON

2017 - 2017 IEEE Region 10 Conference, pages 476–

481.

Lallie, H. S., Debattista, K., and Bal, J. (2017). An em-

pirical evaluation of the effectiveness of attack graphs

and fault trees in cyber-attack perception. IEEE

Transactions on Information Forensics and Security,

13(5):1110–1122.

Liu, X., Guo, X., and Gu, W. (2025). Seckg2vec: A novel

security knowledge graph relational reasoning method

based on semantic and structural fusion embedding.

Computers & Security, 149:104192.

Ou, X., Boyer, W. F., and McQueen, M. A. (2006). A scal-

able approach to attack graph generation. In Proceed-

ings of the 13th ACM conference on Computer and

communications security, pages 336–345.

Ou, X., Govindavajhala, S., and Appel, A. W. (2005). Mul-

VAL: A logic-based network security analyzer. In

14th USENIX Security Symposium (USENIX Security

05), Baltimore, MD. USENIX Association.

Poolsappasit, N., Dewri, R., and Ray, I. (2011). Dy-

namic security risk management using bayesian attack

graphs. IEEE Transactions on Dependable and Secure

Computing, 9(1):61–74.

Ray, I., Sreedharan, S., Podder, R., Bashir, S. K., and Ray, I.

(2023). Explainable ai for prioritizing and deploying

defenses for cyber-physical system resiliency. In 2023

5th IEEE International Conference on Trust, Privacy

and Security in Intelligent Systems and Applications

(TPS-ISA), pages 184–192. IEEE.

Yin, J., Hong, W., Wang, H., Cao, J., Miao, Y., and Zhang,

Y. (2024). A compact vulnerability knowledge graph

for risk assessment. ACM Trans. Knowl. Discov. Data,

18(8).

Zhang, Y., Du, T., Ma, Y., Wang, X., Xie, Y., Yang, G.,

Lu, Y., and Chang, E.-C. (2024). Attackg+:boosting

attack knowledge graph construction with large lan-

guage models. arXiv 2405.04753, Available from

https://arxiv.org/abs/2405.04753.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

428