Press "Enter" to skip to content

Creating Custom Apps for Phantom: Part 1


Welcome! If you’re here and wondering what Phantom is, I plan to have an introductory blog post at some point, but in the meantime head over here for more info and to sign up for a community account.

In this series of blog posts, I’ll be going over how to write custom applications for the Phantom security automation and orchestration platform.

Custom apps are a great way to add new functionality to playbooks in Phantom by interfacing with third-party services and APIs.  For this tutorial, we’ll be making a custom app for the WPScan Vulnerability Database.

The WPScan Vulnerability Database is a catalog of vulnerabilities that affect WordPress core, plugins, and themes.  We are going to build an app using their API to display those vulnerabilities based on a passed in version number, plugin slug, or theme slug.

Disclaimer: if you want to use this app in your Phantom environment, please contact the WPScan team to enquire about a commercial license. 

Getting Started

The first step to creating a custom app for Phantom is to use Phantom’s built-in app wizard.  This can be found by navigating to /apps and selecting App Wizard in the top right navigation.

This drops us off on the Basic Details section of the App Wizard. Here we can fill in basic information about what our app will be called, what it will do, and what logos it will use in the interface.

For the App Name, we’re going to use “WPScan Vulnerability Database API”. 

For the App Description, we’re going to use “The WPScan Vulnerability Database is a database of WordPress Core, Plugin and Theme vulnerabilities.” from

For the Product Vendor, we’ll use “WPScan”.

For the Product Name, we’ll use “Vulnerability Database API”.

For the App Publisher, I’ll use my name – you use yours.

For this app, let’s check the Distribute With Source checkbox.  This will put our code in the distributable tarball when we compile the app.  This will make it easier to share the code and for others to see how it works.

For the logos, I’m just going to copy the logo from the website for both light and dark.  You would want to use a different logo if the logo you want to use is similar to either the light or dark theme’s backgrounds.

When we’re done, our Basic details tab should look like this:

Now we can move on to the Asset Configuration tab. 

Asset Configuration

Here we’re going to set up any global app configuration options.  This is useful for things like an API base url or API keys or other things that can change per asset, but apply to all actions.

For this app, we’ll be setting up a base url option and an API key option. set up one configuration option

Let’s add the base url option first. For the name we’ll follow Phatom’s pereferd naming schema and use base_urlas the name, a data type of string, “WPVulnDB API Base URL” as the description, and leave it marked as not required.  Next, let’s click on the More icon and add a default base_url value of “”. We’re setting a default value since this will be the base url for 99.9% of users, but we want to make it customizable just in case.

Now, let’s do the same for the API key.  For the name we’ll use api_key. This time we’ll use password for the data type. This encrypts the value in the database, which is a good idea for api keys and passwords.  We’ll use “WPVulnDB API Key” as the description and mark this option as required and not set a default value since this will be different for everyone.

When we’re done, it’ll look something like this:

Now we can head over to the app actions tab.

App Actions

There’s not much for us to do here since our actions are a bit non-standard for this app, but let’s pick information from the drop down so we get the test connectivity action that all Phantom apps have. Also, we’ll pick lookup ip from the available information actions and add it to the selected actions as Phantom doesn’t allow you to continue without picking at least one default action, but we’ll be removing it later.

After we do that, it should look like this:

Now we can head to the last tab — Custom Actions.

Custom Actions

This tab start out blank, but here we’ll be adding the custom actions we’ll be using to interface with the WPVulnDB API.

Let’s review the actions available to us from the WPVuln DB API.  There are API endpoints for each of the following action: list WordPress core vulnerabilities for a version number (/wordpresses/{version}), list plugin vulnerabilities for a plugin slug ( /plugins/{slug}), and list theme vulnerabilities for a theme slug (/themes/{slug}).  We’re going to want to add an action for each of these.

So, back in the Custom Actions tab, let’s create three actions.  Their names will be lookup wordpress, lookup plugin, and lookup theme. They will all have the type Investigate as they are actions we’d use in the investigation phase and they will all be “Read Only” as the API calls don’t change anything on a system.

lookup wordpress will have a parameter of wordpress_version, lookup plugin will have a parameter of plugin_slug, and lookup theme will have a parameter of theme_slug.  All of these parameters will be of type string, be required, and be primary.  Setting a parameter as primary will affect how it is displayed in the widget are of an event/case which is something we’ll look at more later in this series, but let’s just leave it as primary for now. 

After we fill out the remaining descriptions, our page should look something like this:

Now we can finally hit submit!


Upon clicking submit, if everything was filled out correctly, we will get a tarball of files to help us get started on our app.  

If something didn’t go right, you should get a nice bit of red text up at the top of the wizard area telling you what is missing/incorrect.

In the next part of the series, we’ll dig into the files we just received and start implementing our actions.

Also published on Medium.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.