Open Sh4d0wHunt3rX opened 2 months ago
If you run wpscan manually on that URL, does it behave okay?
In the debug log, it says: host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...",
I think because of url': 'http://dev... , is this ok?
This is the complete log, for example line 8016.
The "{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev..."
is just because its been truncated in the log file
I have re-run bbot on just the host dev.gardenmaster.co.za
with the same modules enabled and it ran without issue.
2024-09-02 12:58:51,796 [DEBUG] bbot.modules.wpscan base.py:1235 Got TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'}) from wappalyzer
2024-09-02 12:58:46,938 [DEBUG] bbot.modules.wpscan base.py:1235 TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'}) passed post-check
2024-09-02 12:58:46,939 [DEBUG] bbot.modules.wpscan base.py:1235 Handling TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'})
2024-09-02 12:58:46,939 [HUGEVERBOSE] bbot.core.helpers.command logger.py:132 run: wpscan --url https://dev.gardenmaster.co.za/ --user-agent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.2151.97' --max-threads 5 --request-timeout 60 --connect-timeout 30 --enumerate vp,vt,tt,cb,dbe,u,m --disable-tls-checks --format json
2024-09-02 12:58:48,525 [DEBUG] bbot.modules.wpscan base.py:1235 Finished handling TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'})
It might make sense to put an idle_timeout=
on the wpscan command, in case it decides to get stuck again.
Unfortunately, it got stuck again on another scan, stuck on wpscan(930:1:0) for 45 minutes and killed manually : (
wpscan.handle_event(HTTP_RESPONSE("{'url': 'https://stories.flipkart.com/', 'timestamp': '2024-09-03T10:32:31.27834...", module=httpx, tags={'ip-192-124-249-115',
Part of the debug: wpscan.txt
Is it possible to skip a url if stuck on it and goes to the next one?
We can put the idle_timeout=
on the wpscan command but it already has a --request-timeout 60
and --connect-timeout 30
on the tool command. So I'm not 100% sure its stuck, im running it now and it is getting data its just not very fast (or verbose) 15+ minutes so far.
I wouldn't want to set an idle_timeout
just for it to kill the process when its actually getting results just not within the time limit
(Ugh wpscan --verbose
option only works through the CLI not the json output bbot needs :( )
Anyway, ive done some testing and looks like the bruteforce enumeration is eating the time, e.g.
When request-timeout=60 and connect-timeout=30 (canceled after 45 minutes)
Fingerprinting the version - Time: 00:11:13 <===============================================================> (702 / 702) 100.00% Time: 00:11:13
[+] Enumerating Vulnerable Themes (via Passive and Aggressive Methods)
Checking Known Locations - Time: 00:04:16 <===== > (56 / 652) 8.58% ETA: 00:45:34
When request-timeout=5 and connect-timeout=5 (canceled after 30 minutes)
Fingerprinting the version - Time: 00:02:32 <===============================================================> (702 / 702) 100.00% Time: 00:02:32
[+] Enumerating Vulnerable Themes (via Passive and Aggressive Methods)
Checking Known Locations - Time: 00:07:31 <============================================ > (446 / 652) 68.40% ETA: 00:03:29
[+] Enumerating Timthumbs (via Passive and Aggressive Methods)
Checking Known Locations - Time: 00:02:41 <=== > (161 / 2575) 6.25% ETA: 00:40:25
So the fingerprinting takes a long time adjusting the request/connect timeout did help but there are so many potential requests that it has to make for full enumeration
version detection = 702 requests
vp = unknown
vt = 652 requests
tt = 2575 requests
cb = 137 requests
dbe =
u1-10 =
m1-100 =
So the best way forward here seems to be adjusting the default module options!
Default request/connect timeout is 60s/30s
These are the available options for enumeration, the default is vp,vt,tt,cb,dbe,u,m
-e, --enumerate [OPTS] Enumeration Process
Available Choices:
vp Vulnerable plugins
ap All plugins
p Popular plugins
vt Vulnerable themes
at All themes
t Popular themes
tt Timthumbs
cb Config backups
dbe Db exports
u User IDs range. e.g: u1-5
Range separator to use: '-'
Value if no argument supplied: 1-10
m Media IDs range. e.g m1-15
Note: Permalink setting must be set to "Plain" for those to be detected
Range separator to use: '-'
Value if no argument supplied: 1-100
Separator to use between the values: ','
Default: All Plugins, Config Backups
Value if no argument supplied: vp,vt,tt,cb,dbe,u,m
Incompatible choices (only one of each group/s can be used):
- vp, ap, p
- vt, at, t
So removing them enumeration options could speed it up massively.
@Sh4d0wHunt3rX if you want to change those options right now you can use modules.wpscan.enumerate=
, modules.wpscan.request_timeout=
and modules.wpscan.connection_timeout=
So we could enhance this module by changing the defaults to make it faster. And users can change the module options to increase coverage if they wish
@Sh4d0wHunt3rX did you run it using those options? I was thinking to change the defaults to
modules.wpscan.enumerate=vp,vt,cb,dbe
modules.wpscan.request_timeout=5
(Same as HTTPX)modules.wpscan.connection_timeout=2
But was wondering your thoughts?Hey @domwhewell-sage , unfortunately, still I have not tested with different settings but I guess the new set that you have in mind will be much faster. ❤️
During Scan, it seems wpscan stuck.
Keep seeing this in debug