From 225f1d7da7049a99e65536bb5ef9b6fd39b2a2a4 Mon Sep 17 00:00:00 2001
From: Spencer McIntyre <58950994+smcintyre-r7@users.noreply.github.com>
Date: Thu, 20 May 2021 14:03:34 -0400
Subject: [PATCH] Updated Get Started Writing an Exploit (markdown)

---
 Get-Started-Writing-an-Exploit.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Get-Started-Writing-an-Exploit.md b/Get-Started-Writing-an-Exploit.md
index e5e1b5b9ac..b2ecb2db59 100644
--- a/Get-Started-Writing-an-Exploit.md
+++ b/Get-Started-Writing-an-Exploit.md
@@ -9,6 +9,8 @@ The real kung-fu behind exploit development isn't actually about which language
 
 ## Plan your module
 
+First, ask yourself will exploiting this vulnerability result in executing a payload? If not, then despite exploiting a vulnerability, for Metasploit's purposes the module would fall into the [[auxiliary|How-to-get-started-with-writing-an-auxiliary-module]] category.
+
 Unlike writing a proof-of-concept, when you write a Metasploit module, you need to think about how users might use it in the real world. Stealth is usually an important element to think about. Can your exploit achieve code execution without dropping a file? Can the input look more random, so it's more difficult to detect? How about obfuscation? Is it generating unnecessary traffic? Can it be more stable without crashing the system?
 
 Try to be precise about exploitable requirements. Usually, a bug is specific to a range of versions or even builds. If you can't automatically check that, you need to at least mention it in the description somewhere.