Kev

Articol complet: Meet 'Jack' from Romania! Mastermind Behind Golden Chickens Malware The identity of the second threat actor behind the Golden Chickens malware has been uncovered courtesy of a "fatal" operational security blunder, cybersecurity firm eSentire said. The individual in question, who lives in Bucharest, Romania, has been given the codename Jack. He is one of the two criminals operating an account on the Russian-language Exploit.in forum under the name "badbullzvenom," the other being "Chuck from Montreal." eSentire characterized Jack as the true mastermind behind Golden Chickens. Evidence unearthed by the Canadian company shows that he is also listed as the owner of a vegetable and fruit import and export business. "Like 'Chuck from Montreal,' 'Jack' uses multiple aliases for the underground forums, social media, and Jabber accounts, and he too has gone to great lengths to disguise himself," eSentire researchers Joe Stewart and Keegan Keplinger said. "'Jack' has taken great pains to obfuscate the Golden Chickens malware, trying to make it undetectable by most [antivirus] companies, and strictly allowing only a small number of customers to buy access to the Golden Chickens MaaS." Golden Chickens (aka More_eggs) is a malware suite used by financially-motivated cybercrime actors such as Cobalt Group and FIN6. The threat actors behind the malware, also known as Venom Spider, operate under a malware-as-a-service (MaaS) model. The JavaScript malware is distributed via phishing campaigns and comes with several components to harvest financial information, perform lateral movement, and even drop a ransomware plugin for PureLocker called TerraCrypt. Jack's online activities, according to eSentire, go all the way back to 2008, when he was just 15 years old and signed up for various cybercrime forums as a novice member. All his aliases are being collectively tracked as LUCKY. The investigation, in putting together his digital trail, traces Jack's progression from a teenager interested in building malicious programs to a longtime hacker involved in developing password stealers, crypters, and More_eggs. Golden Chickens Malware Some of the earliest malware tools developed by Jack in 2008 consisted of Voyer, which is capable of harvesting a user's Yahoo! instant messages, and an information stealer christened FlyCatcher that can record keystrokes. A year later, Jack released a new password stealer dubbed CON that's designed to siphon credentials from different web browsers, VPN, and FTP applications as well as now-defunct messaging apps like MSN Messenger and Yahoo! Messenger. Jack, later that same year, began advertising a crypter referred to as GHOST to help other actors encrypt and obfuscate malware with the goal of evading detection. The unexpected demise of his father in a car accident is believed to have caused him to pause development of the tool in 2010. Fast forward to 2012, Jack started to gain a reputation in the cybercriminal community as a scammer for failing to provide adequate support to customers purchasing the product from him. He also cited "big life problems" in a forum post on April 27, 2012, stating he is contemplating moving to Pakistan to work for the government as a security specialist and that one among his crypter customers "works at pakistan guv" [read government]. It's not immediately clear if Jack ended up going to Pakistan, but eSentire said it spotted tactical overlaps between a 2019 campaign conducted by a Pakistani threat actor known as SideCopy and Jack's VenomLNK malware, which functions as the initial access vector for the More_eggs backdoor. Jack is suspected to have crossed paths with "Chuck from Montreal" sometime between late 2012 and October 4, 2013, the date on which a message was posted from Chuck's badbullz account on the Lampeduza forum containing contact information – a Jabber address – associated with LUCKY. It's speculated that Jack brokered a deal with Chuck that would allow him to post under Chuck's aliases "badbullz" and "badbullzvenom" on various underground forums as a way to get around his notoriety as a ripper. Lending credence to this hypothesis is the fact that one of LUCKY's new tools, a kit for building macros called MULTIPLIER, was released in 2015 via the badbullzvenom account, while the threat actor behind the LUCKY account ceased posting through that handle. "By using the badbullzvenom and badbullz accounts, and unbeknownst to forum members, he is essentially starting with a clean slate, and he can continue to build his credibility under the account aliases: badbullz and badbullzvenom," the researchers explained. Subsequently in 2017, badbullzvenom (aka LUCKY) released a separate tool called VenomKit, which has since evolved into the Golden Chickens MaaS. The malware's ability to bypass security software also caught the attention of Cobalt Group, a Russia-based cybercrime gang that leveraged it to deploy Cobalt Strike in attacks aimed at financial entities. Two years later, another financially motivated threat actor labeled FIN6 (aka ITG08 or Skeleton Spider) was observed using the Golden Chickens service to anchor its intrusions targeting point-of-sale (POS) machines used by retailers in Europe and the U.S. The cybersecurity firm said it also found the identities of his wife, mother, and two sisters. He and his wife are said to reside in an upscale part of Bucharest, with his wife's social media accounts documenting their trips to cities like London, Paris, and Milan. The photos further show them wearing designer clothing and accessories. "The threat actor who went by the alias LUCKY and who also shares the badbullz and badbullzvenom accounts with the Montreal-based cybercriminal 'Chuck,' made his fatal mistake when he used the Jabber account," the researchers said. Author: Ravie Lakshmanan

cum vrei sa te protejezi cu IP-uri publice? majoritatea utilizate de ciori

https://docs.directadmin.com/other-hosting-services/preventing-spam/outgoing-spam.html

An advance cross-platform and multi-feature GUI web spider/crawler for cyber security proffesionals. Spider Suite can be used for attack surface mapping and analysis. For more information visit SpiderSuite's website. Installation and Usage Spider Suite is designed for easy installation and usage even for first timers. First, download the package of your choice. Then install the downloaded SpiderSuite package. See First time crawling with SpiderSuite article for tutorial on how to get started. For complete documentation of Spider Suite see wiki. Contributing Can you translate? Visit SpiderSuite's translation project to make translations to your native language. Not a developer? You can help by reporting bugs, requesting new features, improving the documentation, sponsoring the project & writing articles. For More information see contribution guide. Contributers 3nock (main developer) Credits This product includes software developed by the following open source projects: Google's Gumbo HTML Parser Google's Protocal bufffers SQLite database library Graphviz library Download: SpiderSuite-main.zip or git clone https://github.com/3nock/SpiderSuite Source

PromptFlow is a tool that allows you to create executable flowcharts that link LLMs (Large Language Models), Prompts, Python functions, and conditional logic together. With PromptFlow, you can create complex workflows in a visual way, without having to write too much code or deal with complicated logic. How it works PromptFlow is based on a visual flowchart editor that allows you to create nodes and connections between them. Each node can be a Prompt, a Python function, or an LLM. Connections between nodes represent conditional logic, and allow you to specify the flow of your program. When you run your flowchart, PromptFlow will execute each node in the order specified by the connections, passing data between nodes as needed. If a node returns a value, that value will be passed to the next node in the flow. Initial Setup Install the required dependencies. Python 3.8+ is required to run PromptFlow. python -m pip install -r requirements.txt Launching Promptflow can be run with Python from the commandline: python run.py If you're having trouble ensure your PYTHONPATH is set correctly: export PYTHONPATH=$PYTHONPATH:. Documentation Official docs website: promptflow.org Building from source To build the sphinx documentation, run: cd docs make html Then open docs/build/html/index.html in your browser. Contributing If you are interested in contributing to PromptFlow, you can do so through building a node. If you find any bugs, do not hesitate to create an issue or open a PR or let us know in Discord. Download: promptflow-main.zip or git clone https://github.com/InsuranceToolkits/promptflow.git

The latest cyber-attack techniques were highlighted by a range of experts during the RSA 2023 Conference. SEO-Based Attacks There has been a significant growth in threat actors leveraging search engine optimization and malvertising to infiltrate users and organizations, according to, Katie Nickels, certified instructor, SANS Institute, and director of intelligence at Red Canary. She said this shift is a sign that “perimeter defenses are improving,” but means that attackers’ utilization of legitimate search engine optimization services is a major new challenge for organizations. Here, threat actors are paying search engine websites to push their malicious sites to the top of search results. Nickels demonstrated that this is proving effective, with the first three results of a particular search she used showing malicious sites. This technique is used for “lots of different intrusions,” including infecting users with infostealer malware, she said. Mitigating these types of attacks is difficult, as the perpetrators are utilizing legitimate and trusted services. Therefore, education is vital – for example, encouraging users to directly enter legitimate websites instead of using a search engines. Nickels added that organizations should utilize tools like ad-blocking software, and most importantly, to report malicious websites being displayed in search engine results on every possible occasion. Targeting of Developers Dr Johannes Ullrich, dean of research, SANS Technology Institute College, highlighted a growing number of attacks “specifically targeting developers.” This is an effective tactic, as developers are typically the first employees in an organization to be exposed to code. There have been numerous cases where threat actors have exploited vulnerabilities in software components to inject malicious software, that are then installed by developers in their business, said Ullrich. This was shown in the LastPass breaches in 2022, in which the attackers targeted a DevOps engineer's home computer by exploiting a vulnerable third-party media software package. Once installed by the developer, the attackers gained the privileges required for remote code execution. Ullrich said increased dialogue with developers from security teams, such as educating them about these types of threats, is crucial to mitigating the risk. Malicious Use of ChatGPT The next attack trend discussed in the session was the nefarious use of ChatGPT – for malware and exploit development. Stephen Sims, offensive operations curriculum lead and fellow, SANS Institute, demonstrated testing he had undertaken on the AI chatbot, to see if he could get it to write ransomware code. Although ChatGPT refused to do so when asked directly, Sims was able to find a way round it by instead asking the tool to write code for the individual components of ransomware, such as code just for encryption. Ultimately, “it wrote the whole thing for us.” Heather Mahalik, DFIR Curriculum Lead, SANS Institute, and senior director of digital intelligence at Cellebrite, also highlighted emerging threats from ChatGPT, focusing on how it can create realistic social engineering campaigns for a range of nefarious purposes. She demonstrated a potentially disturbing use of the tool – to try and sound like a nine-year-old child to entice a child into giving their home address. It proved highly effective in writing a realistic message in this manner. She argued this type of use of ChatGPT is an underappreciated risk, and “one of the biggest threats is definitely ignorance.” New Threat Report Insights During RSA 2023, BlackBerry published its latest Quarterly Global Threat Intelligence Report, covering the period between December 1, 2022 and February 28, 2023. Ismael Valenzuela, Vice President, threat research & intelligence at Blackberry sat down with Infosecurity at the show to discuss some of the main findings. The firm detected a significant increase in cross-platform malware, in which code is created that works across different platforms. “That makes sense as attackers are focused on impact,” Valenzuela stated. Another trend is the rise of infostealers, often used to steal credentials as even relatively minor organizations can provide access to high-value targets, he said. “There’s a lot of people going after credentials, no matter who you are,” added Valenzuela. The report also highlighted regional differences regarding attack techniques being used. Notably, there was a significant uptick in attacks targeting countries in South-East Asia, with Singapore appearing in the top 10 countries that experienced cyber-attacks and Hong Kong in the top 10 countries where unique malware samples were used. It is very important to highlight these variations as “the threats we see there are very unique to that region,” said Valenzuela. He highlighted an attack on a semi-conductor manufacturing company in Taiwan during this period. In this case, a remote access infostealer tool called Warzone was used in a very focused way. “We saw that this malware used geofencing, which means the malware is only going to detonate if it’s executing within a particular region,” explained Valenzuela. This highly targeted incident is very notable, and something to keep an eye on in Taiwan given the geopolitical situation with China. Source

Ce model de camere detii?

Two out of three public-facing app instances open to hijacking Apache Superset until earlier this year shipped with an insecure default configuration that miscreants could exploit to login and take over the data visualization application, steal data, and execute malicious code. The open source application, based on Python's Flask framework, defaulted to a publicly known secret key: SECRET_KEY = '\2\1thisismyscretkey\1\2\e\y\y\h' In an advisory on Tuesday, security firm Horizon3.ai explained that when a user logs into a Superset instance, the web application sends a session cookie with a user identifier back to the visitor's web browser. "The web application signs the cookie with a SECRET_KEY, a value that is supposed to be randomly generated and typically stored in a local configuration file," said Naveen Sunkavally, chief architect at Horizon3.ai. If an attacker knows the value of SECRET_KEY, that person can then generate and sign cookies, effectively authenticating as the app administrator. And it turns out to be trivial to check whether Superset is using the default key with a tool called flask-unsign. According to Sunkavally, about two-thirds of those using the software failed to generate a new key when setting up Superset: as of October 11, 2021, the application had almost 3,000 instances exposed to the internet, about 2,000 of which relied on the default secret key. The Apache security team responded the following day and by January 11, 2022, made some changes, which established a new default secret key: "CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET" But this time the app included a check to see whether the new default remained unchanged. If so, the app issued a warning to the app's log file, with instructions for how to generate a secure key. Heeding the warning, however, was left to users. More than a year after this change was made, on February 9, 2023, Horizon3.ai again checked to see how many Superset instances were configuring their app with a public default secret key. This time they expanded their Shodan.io search to four different default keys – the original, the new one, and two others – one from a deployment template and one from the documentation. And not much had changed. Out of 3,176 Superset instances, 2,124 (~67 percent) were using one of the four default keys. So Horizon3.ai contacted the Apache security team again. And two weeks later, on February 24, 2023, the project maintainers committed an update that would ship as part of the 2.1 release on April 5, 2023, to "impose harsher measures when a default SECRET_KEY is identified." The change made it so the app would not start with a default key. "With this update, many new users of Superset will no longer unintentionally shoot themselves in the foot," said Sunkavally, who cautioned that it's still possible to end up with an insecure version of Superset if the software is installed via a docker-compose file or a helm template. "The docker-compose file contains a new default SECRET_KEY of TEST_NON_DEV_SECRET that we suspect some users will unwittingly run Superset with. Some configurations also set admin/admin as the default credential for the admin user." The Superset vulnerability was disclosed as CVE-2023-27524 on Monday. Sunkavally said concerned Superset users can check to see whether their server has a default key with this script that relies on flask-unsign. The 2,000+ vulnerable Superset instances identified were operated by companies large and small, government agencies, and universities, according to Sunkavally, who added that some of these organizations addressed the vulnerability after being notified about it. Sunkavally said this episode illustrates that users do not read documentation and don't read logs. "The best approach is to take the choice away from users and require them to take deliberate actions to be purposefully insecure," he said. ® Via theregister.com

Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH. Single executable including both client and server. Written in Go (golang). Chisel is mainly useful for passing through firewalls, though it can also be used to provide a secure endpoint into your network. Table of Contents Features Install Demo Usage Contributing Changelog License Features Easy to use Performant* Encrypted connections using the SSH protocol (via crypto/ssh) Authenticated connections; authenticated client connections with a users config file, authenticated server connections with fingerprint matching. Client auto-reconnects with exponential backoff Clients can create multiple tunnel endpoints over one TCP connection Clients can optionally pass through SOCKS or HTTP CONNECT proxies Reverse port forwarding (Connections go through the server and out the client) Server optionally doubles as a reverse proxy Server optionally allows SOCKS5 connections (See guide below) Clients optionally allow SOCKS5 connections from a reversed port forward Client connections over stdio which supports ssh -o ProxyCommand providing SSH over HTTP Install Binaries See the latest release or download and install it now with: curl https://i.jpillora.com/chisel! | bash Docker docker run --rm -it jpillora/chisel --help Fedora The package is maintained by the Fedora community. If you encounter issues related to the usage of the RPM, please use this issue tracker. sudo dnf -y install chisel Source $ go install github.com/jpillora/chisel@latest Demo A demo app on Heroku is running this chisel server: $ chisel server --port $PORT --proxy http://example.com # listens on $PORT, proxy web requests to http://example.com This demo app is also running a simple file server on :3000, which is normally inaccessible due to Heroku's firewall. However, if we tunnel in with: $ chisel client https://chisel-demo.herokuapp.com 3000 # connects to chisel server at https://chisel-demo.herokuapp.com, # tunnels your localhost:3000 to the server's localhost:3000 and then visit localhost:3000, we should see a directory listing. Also, if we visit the demo app in the browser we should hit the server's default proxy and see a copy of example.com. Usage $ chisel --help Usage: chisel [command] [--help] Version: X.Y.Z Commands: server - runs chisel in server mode client - runs chisel in client mode Read more: https://github.com/jpillora/chisel $ chisel server --help Usage: chisel server [options] Options: --host, Defines the HTTP listening host – the network interface (defaults the environment variable HOST and falls back to 0.0.0.0). --port, -p, Defines the HTTP listening port (defaults to the environment variable PORT and fallsback to port 8080). --key, An optional string to seed the generation of a ECDSA public and private key pair. All communications will be secured using this key pair. Share the subsequent fingerprint with clients to enable detection of man-in-the-middle attacks (defaults to the CHISEL_KEY environment variable, otherwise a new key is generate each run). --authfile, An optional path to a users.json file. This file should be an object with users defined like: { "<user:pass>": ["<addr-regex>","<addr-regex>"] } when <user> connects, their <pass> will be verified and then each of the remote addresses will be compared against the list of address regular expressions for a match. Addresses will always come in the form "<remote-host>:<remote-port>" for normal remotes and "R:<local-interface>:<local-port>" for reverse port forwarding remotes. This file will be automatically reloaded on change. --auth, An optional string representing a single user with full access, in the form of <user:pass>. It is equivalent to creating an authfile with {"<user:pass>": [""]}. If unset, it will use the environment variable AUTH. --keepalive, An optional keepalive interval. Since the underlying transport is HTTP, in many instances we'll be traversing through proxies, often these proxies will close idle connections. You must specify a time with a unit, for example '5s' or '2m'. Defaults to '25s' (set to 0s to disable). --backend, Specifies another HTTP server to proxy requests to when chisel receives a normal HTTP request. Useful for hiding chisel in plain sight. --socks5, Allow clients to access the internal SOCKS5 proxy. See chisel client --help for more information. --reverse, Allow clients to specify reverse port forwarding remotes in addition to normal remotes. --tls-key, Enables TLS and provides optional path to a PEM-encoded TLS private key. When this flag is set, you must also set --tls-cert, and you cannot set --tls-domain. --tls-cert, Enables TLS and provides optional path to a PEM-encoded TLS certificate. When this flag is set, you must also set --tls-key, and you cannot set --tls-domain. --tls-domain, Enables TLS and automatically acquires a TLS key and certificate using LetsEncrypt. Setting --tls-domain requires port 443. You may specify multiple --tls-domain flags to serve multiple domains. The resulting files are cached in the "$HOME/.cache/chisel" directory. You can modify this path by setting the CHISEL_LE_CACHE variable, or disable caching by setting this variable to "-". You can optionally provide a certificate notification email by setting CHISEL_LE_EMAIL. --tls-ca, a path to a PEM encoded CA certificate bundle or a directory holding multiple PEM encode CA certificate bundle files, which is used to validate client connections. The provided CA certificates will be used instead of the system roots. This is commonly used to implement mutual-TLS. --pid Generate pid file in current working directory -v, Enable verbose logging --help, This help text Signals: The chisel process is listening for: a SIGUSR2 to print process stats, and a SIGHUP to short-circuit the client reconnect timer Version: X.Y.Z Read more: https://github.com/jpillora/chisel $ chisel client --help Usage: chisel client [options] <server> <remote> [remote] [remote] ... <server> is the URL to the chisel server. <remote>s are remote connections tunneled through the server, each of which come in the form: <local-host>:<local-port>:<remote-host>:<remote-port>/<protocol> ■ local-host defaults to 0.0.0.0 (all interfaces). ■ local-port defaults to remote-port. ■ remote-port is required*. ■ remote-host defaults to 0.0.0.0 (server localhost). ■ protocol defaults to tcp. which shares <remote-host>:<remote-port> from the server to the client as <local-host>:<local-port>, or: R:<local-interface>:<local-port>:<remote-host>:<remote-port>/<protocol> which does reverse port forwarding, sharing <remote-host>:<remote-port> from the client to the server's <local-interface>:<local-port>. example remotes 3000 example.com:3000 3000:google.com:80 192.168.0.5:3000:google.com:80 socks 5000:socks R:2222:localhost:22 R:socks R:5000:socks stdio:example.com:22 1.1.1.1:53/udp When the chisel server has --socks5 enabled, remotes can specify "socks" in place of remote-host and remote-port. The default local host and port for a "socks" remote is 127.0.0.1:1080. Connections to this remote will terminate at the server's internal SOCKS5 proxy. When the chisel server has --reverse enabled, remotes can be prefixed with R to denote that they are reversed. That is, the server will listen and accept connections, and they will be proxied through the client which specified the remote. Reverse remotes specifying "R:socks" will listen on the server's default socks port (1080) and terminate the connection at the client's internal SOCKS5 proxy. When stdio is used as local-host, the tunnel will connect standard input/output of this program with the remote. This is useful when combined with ssh ProxyCommand. You can use ssh -o ProxyCommand='chisel client chiselserver stdio:%h:%p' \ user@example.com to connect to an SSH server through the tunnel. Options: --fingerprint, A *strongly recommended* fingerprint string to perform host-key validation against the server's public key. Fingerprint mismatches will close the connection. Fingerprints are generated by hashing the ECDSA public key using SHA256 and encoding the result in base64. Fingerprints must be 44 characters containing a trailing equals (=). --auth, An optional username and password (client authentication) in the form: "<user>:<pass>". These credentials are compared to the credentials inside the server's --authfile. defaults to the AUTH environment variable. --keepalive, An optional keepalive interval. Since the underlying transport is HTTP, in many instances we'll be traversing through proxies, often these proxies will close idle connections. You must specify a time with a unit, for example '5s' or '2m'. Defaults to '25s' (set to 0s to disable). --max-retry-count, Maximum number of times to retry before exiting. Defaults to unlimited. --max-retry-interval, Maximum wait time before retrying after a disconnection. Defaults to 5 minutes. --proxy, An optional HTTP CONNECT or SOCKS5 proxy which will be used to reach the chisel server. Authentication can be specified inside the URL. For example, http://admin:password@my-server.com:8081 or: socks://admin:password@my-server.com:1080 --header, Set a custom header in the form "HeaderName: HeaderContent". Can be used multiple times. (e.g --header "Foo: Bar" --header "Hello: World") --hostname, Optionally set the 'Host' header (defaults to the host found in the server url). --tls-ca, An optional root certificate bundle used to verify the chisel server. Only valid when connecting to the server with "https" or "wss". By default, the operating system CAs will be used. --tls-skip-verify, Skip server TLS certificate verification of chain and host name (if TLS is used for transport connections to server). If set, client accepts any TLS certificate presented by the server and any host name in that certificate. This only affects transport https (wss) connection. Chisel server's public key may be still verified (see --fingerprint) after inner connection is established. --tls-key, a path to a PEM encoded private key used for client authentication (mutual-TLS). --tls-cert, a path to a PEM encoded certificate matching the provided private key. The certificate must have client authentication enabled (mutual-TLS). --pid Generate pid file in current working directory -v, Enable verbose logging --help, This help text Signals: The chisel process is listening for: a SIGUSR2 to print process stats, and a SIGHUP to short-circuit the client reconnect timer Version: X.Y.Z Read more: https://github.com/jpillora/chisel Security Encryption is always enabled. When you start up a chisel server, it will generate an in-memory ECDSA public/private key pair. The public key fingerprint (base64 encoded SHA256) will be displayed as the server starts. Instead of generating a random key, the server may optionally specify a key seed, using the --key option, which will be used to seed the key generation. When clients connect, they will also display the server's public key fingerprint. The client can force a particular fingerprint using the --fingerprint option. See the --help above for more information. Authentication Using the --authfile option, the server may optionally provide a user.json configuration file to create a list of accepted users. The client then authenticates using the --auth option. See users.json for an example authentication configuration file. See the --help above for more information. Internally, this is done using the Password authentication method provided by SSH. Learn more about crypto/ssh here http://blog.gopheracademy.com/go-and-ssh/. SOCKS5 Guide 1. Start your chisel server docker run \ --name chisel -p 9312:9312 \ -d --restart always \ jpillora/chisel server -p 9312 --socks5 --key supersecret 2. Connect your chisel client (using server's fingerprint) chisel client --fingerprint 'rHb55mcxf6vSckL2AezFV09rLs7pfPpavVu++MF7AhQ=' <server-address>:9312 socks 3. Point your SOCKS5 clients (e.g. OS/Browser) to: <client-address>:1080 4. Now you have an encrypted, authenticated SOCKS5 connection over HTTP Caveats Since WebSockets support is required: IaaS providers all will support WebSockets (unless an unsupporting HTTP proxy has been forced in front of you, in which case I'd argue that you've been downgraded to PaaS) PaaS providers vary in their support for WebSockets Heroku has full support Openshift has full support though connections are only accepted on ports 8443 and 8080 Google App Engine has no support (Track this on their repo) Contributing http://golang.org/doc/code.html http://golang.org/doc/effective_go.html github.com/jpillora/chisel/share contains the shared package github.com/jpillora/chisel/server contains the server package github.com/jpillora/chisel/client contains the client package Changelog 1.0 - Initial release 1.1 - Replaced simple symmetric encryption for ECDSA SSH 1.2 - Added SOCKS5 (server) and HTTP CONNECT (client) support 1.3 - Added reverse tunnelling support 1.4 - Added arbitrary HTTP header support 1.5 - Added reverse SOCKS support (by @aus) 1.6 - Added client stdio support (by @BoleynSu) 1.7 - Added UDP support License MIT © Jaime Pillora Source

stenography

Multiple QNAP operating systems are affected, including QTS, QuTS hero, QuTScloud, and QVP Pro appliances, and some don't yet have patches available. Source: Aleskey Funtap via Alamy Stock Photo A pair of zero-day vulnerabilities in several Quality Network Appliance Provider (QNAP) operating systems (OS) for network-attached storage (NAS) appliances are impacting an estimated 80,000 devices worldwide. They remain unpatched for two of the four affected OSes. QNAP provides gear and software for Internet of Things (IoT) storage, networking, and smart video. The OS bugs, discovered by researchers at Sternum, are memory access violations, which could cause unstable code and could provide a path for an authenticated cybercriminal to execute arbitrary code. The vulnerabilities, tracked under CVE-2022-27597 and CVE-2022-27598, impact the QTS, QuTS hero, QuTScloud, and QVP OS, according to Sternum, and have been fixed in QTS version 5.0.1.2346 build 20230322 (and later) and QuTS hero version h5.0.1.2348 build 20230324 (and later). The QuTScloud and QVP OS remain unpatched, but QNAP said that it is "urgently fixing" the flaws. Source: QNAP Sternum researchers explain the memory access violations affect the performance, as well as the security of the QNAP devices. The QNAP security advisory adds, "If exploited, the vulnerability allows remote authenticated users to get secret values." While the bugs are rated "low severity," and so far, Sternum's researchers have not seen them exploited in the wild, getting a patch in place quickly matters — QNAP users continue to be a favorite target among cybercriminals. Why Is QNAP Cyberattacker Catnip? The DeadBolt ransomware group in particular was seen exploiting a range of zero-day vulnerabilities in a series of wide-rangingcybercampaigns against QNAP users in 2022 alone, surfacing regularly in May, June, and September. DeadBolt is clearly dead set, as it were, on putting effort into finding — and exploiting — QNAP flaws, preferably critical zero-days, according to Mark Parkin, senior technical engineer with Vulcan Cyber. "It's sometimes said that finding one vulnerability in a target will lead people into looking for more," Parkin explains. "The issue here is that they are finding more as they look. It almost makes you wonder if the attackers don't have access to the source code, or some other way to get an inside track." Collusion suspicions aside, it's up to organizations to make sure their highly targeted QNAP systems are up to date, especially given that new bugs are coming to light with some frequency. In addition to the most recent findings from Sternum, in February, users of QNAP QTS OS were alerted to a critical SQL injection issue with a CVSS score of 9.8. The disclosures just widen the attack surface further. In the case of the most recent vulnerabilities, users with systems without a patch available should employ a strong endpoint detection and response (EDR) solution and look for indicators of compromise. Because cyberattackers would need to be authenticated, doing an audit of who has access to vulnerable systems and providing additional authentication protection could also help mitigate an attack. One researcher warns that even in cases where patches are available, truly locking down the appliances might require a shift in mindset for some companies. "QNAP devices are very attractive to cybercriminals whose strategy is to ask a large number of victims for a small amount of money," Bud Broomhead, CEO of Viakoo says. "Because QNAP devices, along with many other IoT devices, are largely managed outside of IT, they are often misconfigured, left unprotected by a firewalls, and left unpatched." He adds, "These devices often are invisible to corporate IT and security teams and do not get audited or observed when they fall out of compliance, such as by being on out-of-date and insecure firmware." Source

Slowloris

Nosey Parker is a command-line tool that finds secrets and sensitive information in textual data. It is useful both for offensive and defensive security testing. Key features: It supports scanning files, directories, and the entire history of Git repositories It uses regular expression matching with a set of 95 patterns chosen for high signal-to-noise based on experience and feedback from offensive security engagements It groups matches together that share the same secret, further emphasizing signal over noise It is fast: it can scan at hundreds of megabytes per second on a single core, and is able to scan 100GB of Linux kernel source history in less than 2 minutes on an older MacBook Pro This open-source version of Nosey Parker is a reimplementation of the internal version that is regularly used in offensive security engagements at Praetorian. The internal version has additional capabilities for false positive suppression and an alternative machine learning-based detection engine. Read more in blog posts here and here. Building from source 1. Prerequisites This has been tested on several versions of Ubuntu Linux on x86_64 and on macOS running on both Intel and ARM processors. Required dependencies: cargo: recommended approach:install from https://rustup.rs clang: needed for building the vectorscan-sys crate cmake: needed for building the vectorscan-sys crate python3: needed for building the vectorscan-sys crate 2. Build using Cargo cargo build --release This will produce an optimized binary at target/release/noseyparker. Docker Usage A prebuilt Docker image is available for the latest release for x86_64: docker pull ghcr.io/praetorian-inc/noseyparker:latest A prebuilt Docker image is available for the most recent commit for x86_64: docker pull ghcr.io/praetorian-inc/noseyparker:edge For other architectures (e.g., ARM) you will need to build the Docker image yourself: docker build -t noseyparker . Run the Docker image with a mounted volume: docker run -v "$PWD":/opt/ noseyparker Note: The Docker image runs noticeably slower than a native binary, particularly on macOS. Usage quick start The datastore Most Nosey Parker commands use a datastore. This is a special directory that Nosey Parker uses to record its findings and maintain its internal state. A datastore will be implicitly created by the scan command if needed. You can also create a datastore explicitly using the datastore init -d PATH command. Scanning filesystem content for secrets Nosey Parker has built-in support for scanning files, recursively scanning directories, and scanning the entire history of Git repositories. For example, if you have a Git clone of CPython locally at cpython.git, you can scan its entire history with the scan command. Nosey Parker will create a new datastore at np.cpython and saves its findings there. $ noseyparker scan --datastore np.cpython cpython.git Found 28.30 GiB from 18 plain files and 427,712 blobs from 1 Git repos [00:00:04] Scanning content ████████████████████ 100% 28.30 GiB/28.30 GiB [00:00:53] Scanned 28.30 GiB from 427,730 blobs in 54 seconds (538.46 MiB/s); 4,904/4,904 new matches Rule Distinct Groups Total Matches ─────────────────────────────────────────────────────────── PEM-Encoded Private Key 1,076 1,192 Generic Secret 331 478 netrc Credentials 42 3,201 Generic API Key 2 31 md5crypt Hash 1 2 Run the `report` command next to show finding details. Scanning Git repos by URL, GitHub username, or GitHub organization name Nosey Parker can also scan Git repos that have not already been cloned to the local filesystem. The --git-url URL, --github-user NAME, and --github-org NAME options to scan allow you to specify repositories of interest. For example, to scan the Nosey Parker repo itself: $ noseyparker scan --datastore np.noseyparker --git-url https://github.com/praetorian-inc/noseyparker For example, to scan accessible repositories belonging to octocat: $ noseyparker scan --datastore np.noseyparker --github-user octocat These input specifiers will use an optional GitHub token if available in the NP_GITHUB_TOKEN environment variable. Providing an access token gives a higher API rate limit and may make additional repositories accessible to you. See noseyparker help scan for more details. Summarizing findings Nosey Parker prints out a summary of its findings when it finishes scanning. You can also run this step separately: $ noseyparker summarize --datastore np.cpython Rule Distinct Groups Total Matches ─────────────────────────────────────────────────────────── PEM-Encoded Private Key 1,076 1,192 Generic Secret 331 478 netrc Credentials 42 3,201 Generic API Key 2 31 md5crypt Hash 1 2 Additional output formats are supported, including JSON and JSON lines, via the --format=FORMAT option. Reporting detailed findings To see details of Nosey Parker's findings, use the report command. This prints out a text-based report designed for human consumption: $ noseyparker report --datastore np.cpython Finding 1/1452: Generic API Key Match: QTP4LAknlFml0NuPAbCdtvH4KQaokiQE Showing 3/29 occurrences: Occurrence 1: Git repo: clones/cpython.git Blob: 04144ceb957f550327637878dd99bb4734282d07 Lines: 70:61-70:100 e buildbottest notifications: email: false webhooks: urls: - https://python.zulipchat.com/api/v1/external/travis?api_key=QTP4LAknlFml0NuPAbCdtvH4KQaokiQE&stream=core%2Ftest+runs on_success: change on_failure: always irc: channels: # This is set to a secure vari Occurrence 2: Git repo: clones/cpython.git Blob: 0e24bae141ae2b48b23ef479a5398089847200b3 Lines: 174:61-174:100 j4 -uall,-cpu" notifications: email: false webhooks: urls: - https://python.zulipchat.com/api/v1/external/travis?api_key=QTP4LAknlFml0NuPAbCdtvH4KQaokiQE&stream=core%2Ftest+runs on_success: change on_failure: always irc: channels: # This is set to a secure vari ... (Note: the findings above are synthetic, invalid secrets.) Additional output formats are supported, including JSON and JSON lines, via the --format=FORMAT option. Enumerating repositories from GitHub To list URLs for repositories belonging to GitHub users or organizations, use the github repos list command. This command uses the GitHub REST API to enumerate repositories belonging to one or more users or organizations. For example: $ noseyparker github repos list --user octocat https://github.com/octocat/Hello-World.git https://github.com/octocat/Spoon-Knife.git https://github.com/octocat/boysenberry-repo-1.git https://github.com/octocat/git-consortium.git https://github.com/octocat/hello-worId.git https://github.com/octocat/linguist.git https://github.com/octocat/octocat.github.io.git https://github.com/octocat/test-repo1.git An optional GitHub Personal Access Token can be provided via the NP_GITHUB_TOKEN environment variable. Providing an access token gives a higher API rate limit and may make additional repositories accessible to you. Additional output formats are supported, including JSON and JSON lines, via the --format=FORMAT option. See noseyparker help github for more details. Getting help Running the noseyparker binary without arguments prints top-level help and exits. You can get abbreviated help for a particular command by running noseyparker COMMAND -h. Tip: More detailed help is available with the help command or long-form --help option. Contributing Contributions are welcome, particularly new regex rules. Developing new regex rules is detailed in a separate document. If you are considering making significant code changes, please open an issue first to start discussion. Download: noseyparker-main.zip or git clone https://github.com/praetorian-inc/noseyparker.git

Intro With Apple's Universal Clipboard, you can copy content from one Apple device and paste onto another. With Telltail, you copy text from any device to any other device. Tailscale helps you to weave a secure connection between your devices. And Telltail leverages that connection to transfer text over. Telltail is an independent project and is not affiliated with Tailscale. How to use We have prepared a guide for you that would help you to configure it. How it works It has two parts: Center: A program that stores the text you want across your devices, and Sync: Interacts with Center and lets you copy and paste with your usual keyboard shortcuts. (Available for Linux (X11), macOS and Windows.) This repository contains the former, Center. Sync can be found here. How it is made I've published a blog post about it which you can read to understand more. Download: https://github.com/ajitid/telltail-center.git Download ZIP: https://github.com/ajitid/telltail-center/archive/refs/heads/main.zip Source

https://frida.re/docs/gadget/ https://lief-project.github.io/doc/latest/tutorials/09_frida_lief.html https://koz.io/using-frida-on-android-without-root/ https://github.com/sensepost/objection/ https://github.com/NickstaDB/patch-apk/ https://neo-geo2.gitbook.io/adventures-on-security/frida-scripting-guide/frida-scripting-guide Sursa: https://github.com/ax/apk.sh