129.226.36.183

Regular View Raw Data History
Last Seen: 2023-02-08

GeneralInformation

Country India
City Mumbai
ISP Tencent Building, Kejizhongyi Avenue
ASN AS132203

WebTechnologies

Vulnerabilities

Note: the device may not be impacted by all of these issues. The vulnerabilities are implied based on the software and version.

CVE-2022-0778 The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
CVE-2020-1971 The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. Fixed in OpenSSL 1.1.1i (Affected 1.1.1-1.1.1h). Fixed in OpenSSL 1.0.2x (Affected 1.0.2-1.0.2w).
CVE-2018-5407 Simultaneous Multi-threading (SMT) in processors can enable local users to exploit software vulnerable to timing attacks via a side-channel timing attack on 'port contention'.
CVE-2017-3736 There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen.
CVE-2017-3737 OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.
CVE-2019-1547 Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
CVE-2017-3735 While parsing an IPAddressFamily extension in an X.509 certificate, it is possible to do a one-byte overread. This would result in an incorrect text display of the certificate. This bug has been present since 2006 and is present in all versions of OpenSSL before 1.0.2m and 1.1.0g.
CVE-2022-1292 The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd).
CVE-2017-3738 There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.
CVE-2022-2068 In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze).
CVE-2021-3712 ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
CVE-2021-4160 There is a carry propagation bug in the MIPS32 and MIPS64 squaring procedure. Many EC algorithms are affected, including some of the TLS 1.3 default curves. Impact was not analyzed in detail, because the pre-requisites for attack are considered unlikely and include reusing private keys. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH private key among multiple clients, which is no longer an option since CVE-2016-0701. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.0. It was addressed in the releases of 1.1.1m and 3.0.1 on the 15th of December 2021. For the 1.0.2 release it is addressed in git commit 6fc1aaaf3 that is available to premium support customers only. It will be made available in 1.0.2zc when it is released. The issue only affects OpenSSL on MIPS platforms. Fixed in OpenSSL 3.0.1 (Affected 3.0.0). Fixed in OpenSSL 1.1.1m (Affected 1.1.1-1.1.1l). Fixed in OpenSSL 1.0.2zc-dev (Affected 1.0.2-1.0.2zb).
CVE-2018-0737 The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a cache timing side channel attack. An attacker with sufficient access to mount cache timing attacks during the RSA key generation process could recover the private key. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2b-1.0.2o).
CVE-2018-0734 The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.1a (Affected 1.1.1). Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.0.2q (Affected 1.0.2-1.0.2p).
CVE-2018-0732 During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2-1.0.2o).
CVE-2021-23840 Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
CVE-2021-23841 The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
CVE-2018-0739 Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack. There are no such structures used within SSL/TLS that come from untrusted sources so this is considered safe. Fixed in OpenSSL 1.1.0h (Affected 1.1.0-1.1.0g). Fixed in OpenSSL 1.0.2o (Affected 1.0.2b-1.0.2n).
CVE-2020-1968 The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. This issue affects OpenSSL 1.0.2 which is out of support and no longer receiving public updates. OpenSSL 1.1.1 is not vulnerable to this issue. Fixed in OpenSSL 1.0.2w (Affected 1.0.2-1.0.2v).
CVE-2019-1552 OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).
CVE-2019-1551 There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u (Affected 1.0.2-1.0.2t).
CVE-2019-1559 If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). Fixed in OpenSSL 1.0.2r (Affected 1.0.2-1.0.2q).
CVE-2019-1563 In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).

OpenPorts

1113151719212223252637434953707980818283848810411011111311912313514317517918019522126431138942744344444946549150250351554855458759363163666677178980087388090299299399510231024102510631099111011531200123413111337140014331471152115881599160417231741183018831911192519261935196219902000200220182030205520562067208120822083208620872096212121542181222222322233232323322345237523762379240424432455248025492550255226502761276230003001304830503082308331053107311131163117312831293211322132603268326932993301330633103311338833893401354135423551368937493780379039223950400040014022404040634064424243214369443344434444450045054506452345674643466447474782478648404848489949114949499950005001500450055006500750095010502550905150517252015222526953575431543255555560559656015604560756725800580158585900590159075938598459855986600060016002608061026264630863796443651165606580660066336653666266646666666766686697674867897000700170047070707170807090717172187415744374747500754775487634765777777779798980008001800580088009801080118013801780228023803380348038805180608066806980808081808280838084808680878089809080968098809981008112812381268139814081598180818182008291833383348401840684138415841984328433844384458446850085458553855485758590863786498728880088018803880688128822882388258827883088348836883788388846888088818888888988909000900190029003900690099017901890309042904890519080908290889089909090919092909490959100910591079151916091919199920092039220929593069308931094189433944394459530959596009761980098699876994399449981999899991000010001102431044310554110001111211210113001137112000135791414714265160101699216993170001808118245190001907120000202562054721025213792302323424250012510525565270152701728015280173133732400327643306035000372153777741800441584481849152491535000050050500705010051106512355286954138550005544255443555535555460001616136161662078
-878581687 | 2023-02-03T14:28:15.672375
        
11 / tcp
-878581687 | 2023-02-07T07:13:57.934634
        
13 / tcp
-878581687 | 2023-02-08T00:09:55.423934
        
15 / tcp
827007667 | 2023-02-06T22:46:55.418455
        
17 / tcp
-878581687 | 2023-02-07T07:14:09.559928
        
19 / tcp
-878581687 | 2023-01-24T14:25:56.346291
        
21 / tcp
751465492 | 2023-02-07T14:48:51.822096
        
22 / tcp
-878581687 | 2023-01-22T08:49:14.046402
        
23 / tcp
-878581687 | 2023-02-03T04:09:04.322309
        
25 / tcp
751465492 | 2023-02-04T14:40:57.780894
        
26 / tcp
-878581687 | 2023-02-04T05:00:08.870305
        
37 / tcp
-878581687 | 2023-01-23T20:05:46.603981
        
43 / tcp
-878581687 | 2023-02-07T14:10:23.011511
        
49 / tcp
-878581687 | 2023-02-06T23:19:43.477432
        
53 / tcp
-878581687 | 2023-02-07T20:41:19.333162
        
70 / tcp
-878581687 | 2023-02-07T14:53:02.464856
        
79 / tcp
-878581687 | 2023-02-08T05:29:47.332341
        
80 / tcp
-878581687 | 2023-02-03T23:17:37.485104
        
81 / tcp
-878581687 | 2023-02-07T00:34:10.537841
        
82 / tcp
-878581687 | 2023-02-04T12:46:28.540338
        
83 / tcp
-878581687 | 2023-02-04T03:36:25.902235
        
84 / tcp
-878581687 | 2023-02-07T14:51:15.622970
        
88 / tcp
-878581687 | 2023-02-07T08:17:35.183721
        
104 / tcp
-878581687 | 2023-02-06T22:55:02.573590
        
110 / tcp
-1345205424 | 2023-02-04T15:54:35.274181
        
111 / tcp
-878581687 | 2023-02-03T02:41:02.275827
        
113 / tcp
-878581687 | 2023-02-07T23:33:31.540112
        
119 / tcp
1142120941 | 2023-02-04T17:41:42.638872
        
123 / udp
-878581687 | 2023-02-07T10:34:00.483513
        
143 / tcp
-878581687 | 2023-02-08T00:08:03.063263
        
175 / tcp
-878581687 | 2023-02-06T21:03:18.113597
        
179 / tcp
-878581687 | 2023-01-23T21:34:16.586149
        
180 / tcp
-878581687 | 2023-02-04T12:50:05.740396
        
195 / tcp
-878581687 | 2023-02-07T23:39:45.457668
        
221 / tcp
-878581687 | 2023-02-06T22:45:16.329690
        
264 / tcp
-878581687 | 2023-02-07T14:10:03.436057
        
311 / tcp
-878581687 | 2023-02-07T15:03:44.764252
        
427 / tcp
1981207042 | 2023-02-04T11:37:54.230096
        
443 / tcp
-878581687 | 2023-02-03T18:49:17.206594
        
444 / tcp
-878581687 | 2023-02-08T06:16:11.595062
        
449 / tcp
-1675418583 | 2023-02-03T23:26:36.657697
        
465 / tcp
-878581687 | 2023-01-20T12:59:02.854501
        
491 / tcp
-878581687 | 2023-01-24T15:15:48.490718
        
502 / tcp
-878581687 | 2023-02-03T11:47:56.847577
        
503 / tcp
-878581687 | 2023-01-24T16:05:13.613364
        
515 / tcp
-878581687 | 2023-02-02T21:32:28.972577
        
548 / tcp
-878581687 | 2023-01-24T14:28:18.436901
        
554 / tcp
-878581687 | 2023-02-06T21:48:43.106610
        
587 / tcp
-878581687 | 2023-02-08T00:06:30.360276
        
593 / tcp
-878581687 | 2023-02-07T20:11:32.202101
        
631 / tcp
-1675418583 | 2023-01-24T14:15:12.242932
        
636 / tcp
-878581687 | 2023-02-07T06:34:05.304846
        
666 / tcp
-878581687 | 2023-02-08T00:03:22.822129
        
771 / tcp
-878581687 | 2023-02-07T20:54:30.201776
        
789 / tcp
-878581687 | 2023-02-03T11:44:10.873381
        
800 / tcp
-878581687 | 2023-02-07T14:31:42.250878
        
873 / tcp
-878581687 | 2023-02-03T03:43:36.859418
        
880 / tcp
-878581687 | 2023-02-03T03:40:42.474285
        
902 / tcp
-878581687 | 2023-02-07T14:44:57.345650
        
992 / tcp
-878581687 | 2023-01-22T18:27:04.143193
        
993 / tcp
-878581687 | 2023-02-07T14:10:09.675367
        
995 / tcp
-878581687 | 2023-02-07T09:11:41.672502
        
1023 / tcp
-878581687 | 2023-02-03T12:02:10.097191
        
1024 / tcp
-878581687 | 2023-02-07T14:05:35.806891
        
1025 / tcp
-878581687 | 2023-02-07T19:38:11.745370
        
1063 / tcp
-878581687 | 2023-01-24T05:49:58.599081
        
1099 / tcp
-878581687 | 2023-01-21T07:54:38.775093
        
1110 / tcp
-878581687 | 2023-02-03T03:56:49.999335
        
1153 / tcp
-559552633 | 2023-02-03T14:36:07.267174
        
1200 / tcp
-1367686861 | 2023-02-03T21:30:07.843524
        
1234 / tcp
-878581687 | 2023-02-07T05:07:15.565888
        
1311 / tcp
-878581687 | 2023-02-07T07:20:59.746757
        
1337 / tcp
-878581687 | 2023-02-06T22:29:44.145297
        
1400 / tcp
-878581687 | 2023-02-07T16:15:45.508881
        
1433 / tcp
-878581687 | 2023-02-07T13:54:33.316606
        
1471 / tcp
-878581687 | 2023-02-08T00:07:11.209797
        
1521 / tcp
-878581687 | 2023-02-07T13:55:19.616670
        
1599 / tcp
-878581687 | 2023-02-06T22:55:46.159223
        
1604 / tcp
-878581687 | 2023-02-07T16:00:32.486329
        
1723 / tcp
-878581687 | 2023-02-04T04:54:38.420611
        
1741 / tcp
-878581687 | 2023-02-03T03:46:05.235110
        
1830 / tcp
-878581687 | 2023-02-08T00:16:31.291672
        
1883 / tcp
-878581687 | 2023-01-24T15:17:32.251342
        
1911 / tcp
-878581687 | 2023-02-07T10:24:45.779186
        
1925 / tcp
-878581687 | 2023-02-08T00:07:10.997643
        
1926 / tcp
-878581687 | 2023-02-03T10:08:45.589277
        
1935 / tcp
-878581687 | 2023-02-06T20:49:56.215674
        
1962 / tcp
-878581687 | 2023-02-04T02:26:49.737948
        
1990 / tcp
-878581687 | 2023-02-07T14:05:59.972787
        
2000 / tcp
-878581687 | 2023-02-07T15:41:37.892893
        
2002 / tcp
-878581687 | 2023-01-22T06:12:07.305799
        
2018 / tcp
-878581687 | 2023-01-16T00:32:14.415646
        
2030 / tcp
-878581687 | 2023-01-18T09:19:55.988885
        
2055 / tcp
-878581687 | 2023-02-07T08:22:44.984986
        
2067 / tcp
-878581687 | 2023-01-24T16:05:14.701973
        
2081 / tcp
-878581687 | 2023-02-07T14:45:15.194101
        
2082 / tcp
-878581687 | 2023-02-07T07:08:29.143888
        
2083 / tcp
-878581687 | 2023-02-08T00:04:40.274946
        
2086 / tcp
-878581687 | 2023-02-07T05:02:07.386246
        
2087 / tcp
-878581687 | 2023-01-24T14:45:39.228364
        
2096 / tcp
-878581687 | 2023-02-02T21:40:11.843927
        
2121 / tcp
-878581687 | 2023-01-24T13:43:35.703912
        
2154 / tcp
-878581687 | 2023-02-04T01:04:28.548073
        
2181 / tcp
-878581687 | 2023-02-06T22:56:16.157365
        
2222 / tcp
-878581687 | 2023-01-13T13:09:23.982220
        
2233 / tcp
-878581687 | 2023-01-24T15:18:36.912532
        
2323 / tcp
-878581687 | 2023-02-07T23:52:38.702978
        
2332 / tcp
-878581687 | 2023-02-07T23:43:38.970863
        
2345 / tcp
-878581687 | 2023-02-04T12:06:12.076774
        
2375 / tcp
-878581687 | 2023-01-24T04:38:51.857729
        
2376 / tcp
-878581687 | 2023-01-22T16:28:30.404397
        
2379 / tcp
-878581687 | 2023-02-06T18:56:16.831376
        
2404 / tcp
-878581687 | 2023-01-23T14:42:29.297067
        
2443 / tcp
-878581687 | 2023-02-07T12:26:01.938157
        
2455 / tcp
-878581687 | 2023-01-24T15:36:04.348276
        
2480 / tcp
-878581687 | 2023-01-22T09:04:40.882289
        
2549 / tcp
-878581687 | 2023-01-18T12:05:12.691232
        
2550 / tcp
-878581687 | 2023-01-19T20:51:55.282242
        
2552 / tcp
-878581687 | 2023-02-04T17:06:02.127896
        
2650 / tcp
-878581687 | 2023-02-07T14:17:13.415203
        
2761 / tcp
-878581687 | 2023-02-07T14:40:04.029175
        
2762 / tcp
-878581687 | 2023-02-07T19:31:19.850474
        
3000 / tcp
-878581687 | 2023-02-07T10:15:35.768744
        
3001 / tcp
-878581687 | 2023-01-21T09:19:46.951877
        
3048 / tcp
-878581687 | 2023-02-02T22:58:38.403687
        
3082 / tcp
-878581687 | 2023-01-12T05:25:35.413990
        
3083 / tcp
-878581687 | 2023-01-20T17:05:31.986395
        
3105 / tcp
-878581687 | 2023-01-24T16:22:59.346964
        
3107 / tcp
-878581687 | 2023-01-09T12:36:10.304945
        
3111 / tcp
-878581687 | 2023-02-04T05:20:39.952803
        
3116 / tcp
-878581687 | 2023-01-21T20:23:07.902022
        
3117 / tcp
-878581687 | 2023-02-07T15:30:44.431559
        
3128 / tcp
-878581687 | 2023-01-14T09:43:18.141262
        
3129 / tcp
-878581687 | 2023-01-23T18:46:52.185365
        
3211 / tcp
-878581687 | 2023-01-21T20:48:08.826645
        
3221 / tcp
-878581687 | 2023-02-08T00:20:32.105169
        
3260 / tcp
-878581687 | 2023-02-08T00:21:18.235313
        
3268 / tcp
-1675418583 | 2023-02-03T02:21:44.917338
        
3269 / tcp
-878581687 | 2023-02-07T15:09:35.534537
        
3299 / tcp
-878581687 | 2023-02-08T00:08:32.406864
        
3301 / tcp
794847741 | 2023-02-07T14:41:11.821102
        
3306 / tcp
-878581687 | 2023-01-24T14:21:05.416225
        
3310 / tcp
-878581687 | 2023-01-14T21:25:54.759106
        
3311 / tcp
-878581687 | 2023-01-21T15:44:27.996771
        
3401 / tcp
-878581687 | 2023-02-07T14:19:12.080280
        
3541 / tcp
-878581687 | 2023-02-07T23:37:53.454549
        
3542 / tcp
-878581687 | 2023-02-04T07:48:09.030854
        
3551 / tcp
-878581687 | 2023-02-06T21:40:43.944198
        
3689 / tcp
-878581687 | 2023-02-04T11:43:26.132263
        
3749 / tcp
-878581687 | 2023-02-07T23:40:23.587964
        
3780 / tcp
-878581687 | 2023-02-07T23:55:22.956996
        
3790 / tcp
-878581687 | 2023-01-20T08:35:20.832795
        
3922 / tcp
-878581687 | 2023-01-15T12:32:04.881462
        
3950 / tcp
-878581687 | 2023-02-04T16:19:42.484390
        
4000 / tcp