Thu. May 26th, 2022


  • Another Vulnerability in a Cloud Framework
    Another Vulnerability in a Cloud Framework

    Rapid7 has found a spring framework vulnerability called Spring4Shell


    As usual a new vulnerability requires risk management to be reassessed.

   Leads to

    Which says the following information which is important.

    CVE-2022-22965: Spring Framework RCE via Data Binding on JDK 9+

    Affected VMware Products and Versions

    Severity is critical unless otherwise noted.

    • Spring Framework
      • 5.3.0 to 5.3.17
      • 5.2.0 to 5.2.19
      • Older, unsupported versions are also affected


    Time to work on your vulnerability management

    Contact Us to discuss.


    Update on April 11th – there are now indications of successful attacks:  post:

    Attackers are abusing Spring4Shell vulnerability to spread Mirai botnet malware

    Unfortunately it did not take long to see this vulnerability being exploited.


    And I see it on(mid-day on the 11th of April) Internet Storm Center now:

    From their forum area – it was briefly put on the front page.

    Internet storm center gets into a lot more detail of a probe – to see if your systems are vulnerable.

    Our “First Seen URL” page did show attempts to access /actuator/gateway/routes this weekend. So I dug in a bit deeper to see what these scans are all about. The scans originate from and have been going on for a few days already, but our first-seen list doesn’t display them until they hit a threshold to consider the scans significant. We also see scans from a couple of our IPs, but at a much lower level.

    A typical complete request from

    GET /actuator/gateway/routes HTTP/1.1
    Host: [redacted]:80
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
    Accept-Encoding: gzip
    Connection: close

    So it looks like the probes are looking for more vulnerabilities besides Spring4Shell.


    Contact Us to discuss.




  • Fileless Malware Attacks VERY Hard to Detect
    Fileless Malware Attacks VERY Hard to Detect

    As a Malwarebytes blogpost states, here are 5 reasons why fileless malware is used by attackers:

    The most common use cases for fileless malware are:

    • Initial access. The first step of a cyberattack is to gain a foothold on a system. This can be stealing credentials or exploiting a vulnerability in an access point.
    • Harvest credentials. Fileless malware is sometimes used to hunting for credentials, so an attacker can use alternative entry points or elevate their privileges,
    • Persistence. To ensure they have permanent access to a compromised system, an attacker might use fileless malware to create a backdoor.
    • Data exfiltration. An attacker might use fileless malware to hunt for useful information, such as a victim’s network configuration.
    • Dropper and/or payload. A dropper downloads and starts other malware (the payload) on a compromised system. The payload may come as a file, or it can be read from a remote server and loaded into memory directly.



    How could one detect fileless malware?

    What you need is anti-malware software that uses behavioral analysis, ideally supported by an Artificial Intelligence (AI) component. And for a large attack surface you will need something like a Security Information Event Management (SIEM) system to tie all the alerts and detection together.


    Another good post about fileless malware on Threatpost:

    The bottom line is the attacker uses power shell or other commands to install their program in resident memory not as a file on the filesystem. So this will make the attack software harder to detect as most defensive software looks for files.

    Threatpost mentions a couple of hacker tools:

    The first stage of the attack involves the adversary driving targets to a legitimate website and enticing the target to download a compressed .RAR file boobytrapped with the network penetration testing tools called Cobalt Strike and SilentBreak. Both tools are popular among hackers who use them as a vehicle for delivering shellcode to target machines.

    Cobalt Strike and SilentBreak utilizing separate anti-detection AES decryptors, compiled with Visual Studio.

    The digital certificate for the Cobalt Strike module varies. According to Kaspersky, “15 different stagers from wrappers to last stagers were signed.”


    The ability to inject malware into system’s memory classifies it as fileless. As the name suggests, fileless malware infects targeted computers leaving behind no artifacts on the local hard drive, making it easy to sidestep traditional signature-based security and forensics tools. The technique, where attackers hide their activities in a computer’s random-access memory and use a native Windows tools such as PowerShell and Windows Management Instrumentation (WMI), isn’t new.

    The defensive software you have is unable to detect fileless software and there is a reason  for this as behavioral analysis programs would generate a large amount of data.  But endpoint software does have to check for powershell commands and other areas where fileless  software hides.

    In my opinion the best way to defend against fileless software is to deny the attacker a foothold into the system by updating systems as well as possible. Doing the basics well is important, keeping up on vulnerabilities – testing your systems for vulnerabilities not yet upgraded (or patched) is part of it.

    contact us to discuss this subject.

Latest News