TsojanScan Burp Suite Plugin for Integrated Vulnerability Detection

Why TsojanScan Exists Inside Burp Suite

TsojanScan addresses a specific problem for security testers who would otherwise need several narrow Burp Suite plugins for common vulnerability probes. The README describes the project as an integrated BurpSuite vulnerability detection plugin. Its stated purpose is to add common proof-of-concept checks to an existing framework and reduce the number of requests needed to determine whether a vulnerability appears to exist. That goal is relevant to testers working with live web applications through Burp Repeater, passive traffic and other Burp workflows.

The intended users are penetration testers, security assessors and other people performing authorized vulnerability detection against web services. The plugin is not a general web application firewall, scanner for every protocol or replacement for manual analysis. Its documented areas include Fastjson, SQL injection, Druid, ThinkPHP, WebLogic, Laravel, Spring-related services, Text4shell, Log4j and other modules. The release history also identifies a Jeecg-Boot scanner in v2.0.0.

The project makes a pragmatic choice by presenting several checks in one plugin. That can simplify tool selection and keep results in Burp Suite, but it also means the plugin has a broad scope. A result still depends on the accuracy of each module, the target behavior, request context and any external DNSLog service used for callback-based detection.

How TsojanScan Processes Requests

The repository documentation shows active probing as a request-driven process. An operator supplies a target through Burp Suite, adjusts the active scanning controls and starts a scan. TsojanScan then sends requests for its configured checks and evaluates responses. The README specifically warns about paths: when probing a directory below the root, the path must end with a slash. It gives ThinkPHP and WebLogic as examples of active modules that can use a custom directory.

TsojanScan also supports passive scanning. Passive checks can be applied to traffic that Burp Suite already observes, while active checks send additional requests. The v1.0.0 notes show why the distinction matters. The plugin added a Spring Cloud Gateway scan, but the notes say it did not add vulnerability detection for that component. This is a useful reminder that presence of a module in the release history does not guarantee a complete vulnerability check.

Some checks rely on DNSLog. The plugin can query a DNSLog provider before scanning, send callback-related requests, and later check whether requests arrived. For Fastjson detection, the README describes version inference from callback counts. It says that receiving two DNS requests indicates Fastjson 1.2.83, while receiving one indicates 1.2.80. The v2.0.0 release changes the default to callback.red and says no configuration is required. Other documented providers include Burp Collaborator, Eyes, requestrepo and DigPM.

DNSLog correlation introduces external state. A finding can depend on callback delivery, DNS resolution and provider availability. The plugin can show results in its own panel during a scan, but the README says high-risk findings appear in Burp Suite's Target and Dashboard modules only after the scan finishes. It attributes this behavior to the passive scanning method.

Installing TsojanScan and Starting a First Scan

The README does not provide a text installation procedure, package command or release asset instruction. It shows a plugin-loading screenshot under the usage section, so the documented path is to load the plugin through Burp Suite according to the interface shown there. The repository entry list contains only README.md, and the README does not identify a JAR filename, Maven coordinates, Burp menu path or version compatibility range. Those details should not be guessed.

Before starting a first scan, an operator should use the screenshots to locate the plugin interface, configure a blacklist and select a DNSLog provider if callback-based checks are needed. The README does document that Eyes requires an account at https://eyes.sh/config/ and that the user must copy a subdomain and Token into the plugin configuration. It also documents callback.red as the default in v2.0.0, so a separate Eyes setup is not necessarily required.

The documentation does not give a command-line installation block, so there is no verified command to include here. It also does not document what output a first scan should produce. The closest documented expectation is that plugin-panel results are available while scanning and that high-risk vulnerabilities are transferred to Burp Suite's Target and Dashboard modules after the process completes. Confirm those states in the interface rather than expecting immediate dashboard synchronization.

Blacklist Filtering, DNSLog and Request Control

The blacklist is a practical safety control for TsojanScan because active modules can send requests to hosts that are outside the intended assessment. The README says that users can define URLs or domains that the plugin should not scan. It gives examples such as google.com, google, 127.0.0.1 and 127.0.0.1:8080. The matching process uses regular expressions, and the blacklist has priority over scanning. Applying a blacklist affects subsequent domains or IP addresses; the documentation says an existing scan process will not be interrupted.

This behavior should be understood carefully. A blacklist is a filter, not proof that every excluded or included request is correct. The operator still needs to review target scope and ensure that custom entries match the actual host and port arrangement. The release history says v1.0.0 fixed an issue where only the host, rather than the host and port, caused different ports on the same domain to be skipped. That change shows why port-specific scope can matter in a Burp environment.

Request delay is another documented control. Version v1.4 added a configurable delay between requests. This can reduce request pressure, although the README does not state a default delay or explain whether all modules use the same pacing. DNSLog providers add another configuration dependency. The Eyes workflow requires an account, subdomain and Token, while callback.red is documented as the default for v2.0.0. Operators should verify callback delivery before treating a callback-based negative result as conclusive.

Where Fastjson Version Inference Can Mislead

The Fastjson module has one of the clearest documented decision rules, but that rule is narrow. For the documented 1.2.80 and 1.2.83 cases, the README says two DNS requests indicate 1.2.83 and one request indicates 1.2.80. This is useful because the plugin can infer a precise version or range from callback behavior rather than relying only on a response banner.

The limitation is that callback count is not the same as a complete version assessment. The rule depends on the target producing the expected DNS interactions and on the selected DNSLog service receiving them. The README does not describe behavior for every Fastjson release, network interception, disabled outbound DNS, delayed resolution or duplicate callbacks. The v2.0.0 notes say that the Fastjson payload and scanning logic were optimized and that issue titles can show a precise version or an inferred range, but they do not document the full mapping.

The module also has a historical caveat. Version v1.2 changed the bundled Fastjson library to 1.2.83 to prevent counter-measures, according to the release notes. That is a scanner implementation detail, not evidence that every target runs the same version. Treat the displayed version as an inference produced by the probe, then validate it against target response behavior and application evidence.

Maintenance, Compatibility and Upgrade Cost

The repository is not archived, and the last push was on 2026-07-20. The latest listed release is v2.0.0, also dated 2026-07-20, preceded by v2.0.0-Beta2 on 2026-01-29 and v2.0.0-Beta1 on 2026-01-23. The release notes describe substantial architectural work rather than a small bug-fix release. v2.0.0 says the plugin architecture was refactored, the default JDK changed to 17 and compatibility extends to the latest JDK 26. Earlier beta notes say it was compiled with JDK 21 and adapted to Burp Suite's newer MontoyaApi API.

That history suggests a real upgrade cost for organizations running established Burp workflows. Moving from an earlier v1 release to v2.0.0 may involve API, JDK and architecture changes. The README does not provide a migration procedure, compatibility matrix or rollback instructions. It also does not state whether existing configurations are migrated automatically. Operators should therefore inspect the plugin configuration and test target-specific checks after an upgrade rather than assuming that older settings and findings remain identical.

The license is not identified in the repository information. Consequently, the README cannot support a conclusion about redistribution rights, internal modification rights or obligations associated with deployment. This review cannot provide legal advice or infer a license from the fact that the source is visible on GitHub. Confirm the repository's license file and terms before incorporating the plugin into a commercial or distributed workflow.

TsojanScan Compared With Separate Burp Plugins

TsojanScan's main difference is consolidation. A collection of single-purpose Burp plugins may provide deeper specialization for one vulnerability family, while TsojanScan presents multiple checks through one plugin and a shared panel. The README describes custom blacklist behavior, active and passive scanning, DNSLog configuration, request delay, result deletion and export of data as CSV and HTML in the v2.0.0-Beta2 notes. That combination can reduce the number of extensions an operator has to load.

The trade-off is breadth. A consolidated plugin must support several request styles, result types and external services, so its release notes repeatedly mention compatibility fixes, scanning logic changes and framework refactoring. A specialist plugin may be easier to reason about when a team has a narrow detection need. TsojanScan is more relevant when the team wants a broad set of common checks in one Burp interface and accepts the need to validate each module's scope.

It is also not equivalent to a full vulnerability scanner. The documented checks are centered on web-facing technologies and selected proof-of-concept patterns. They do not demonstrate comprehensive authentication testing, business-logic analysis, coverage of every framework version or reliable remediation guidance. The appropriate comparison is between an integrated Burp add-on and several separate add-ons, not between TsojanScan and a complete security assessment platform.

Editorial conclusion

Adopt TsojanScan when you want several common web vulnerability checks inside Burp Suite and already operate Burp with authorized test targets. Do not treat its findings as a complete security assessment, especially when DNSLog access, target-specific paths or request throttling are required. Verify first that the plugin loads in the installed Burp Suite version, that blacklist rules exclude unintended hosts, and that the selected DNSLog provider can receive callbacks. The most recent release is v2.0.0, published on 2026-07-20, and the repository is not archived.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Tsojan/TsojanScan on GitHub