Kategorie

All major web browsers, including Google Chrome, Apple Safari, Microsoft Edge, Internet Explorer, and Mozilla Firefox, altogether today announced to soon remove support for TLS 1.0 (20-year-old) and TLS 1.1 (12-year-old) communication encryption protocols. Developed initially as Secure Sockets Layer (SSL) protocol, Transport Layer Security (TLS) is an updated cryptographic protocol used to

Posted by David Benjamin, Chrome networking

TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Over that time, we have learned a lot about how to build secure protocols.

TLS 1.2 was published ten years ago to address weaknesses in TLS 1.0 and 1.1 and has enjoyed wide adoption since then. Today only 0.5% of HTTPS connections made by Chrome use TLS 1.0 or 1.1. These old versions of TLS rely on MD5 and SHA-1, both now broken, and contain other flaws. TLS 1.0 is no longer PCI-DSS compliant and the TLS working group has adopted a document to deprecate TLS 1.0 and TLS 1.1.

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

Site administrators should immediately enable TLS 1.2 or later. Depending on server software (such as Apache or nginx), this may be a configuration change or a software update. Additionally, we encourage all sites to revisit their TLS configuration. Chrome’s current criteria for modern TLS is the following:

• TLS 1.2 or later.
• An ECDHE- and AEAD-based cipher suite. AEAD-based cipher suites are those using AES-GCM or ChaCha20-Poly1305. ECDHE_RSA_WITH_AES_128_GCM_SHA256 is the recommended option for most sites.
• The server signature should use SHA-2. Note this is not the signature in the certificate, made by the CA. Rather, it is the signature made by the server itself, using its private key.

The older options—CBC-mode cipher suites, RSA-encryption key exchange, and SHA-1 online signatures—all have known cryptographic flaws. Each has been removed in the newly-published TLS 1.3, which is supported in Chrome 70. We retain them at prior versions for compatibility with legacy servers, but we will be evaluating them over time for eventual deprecation.

None of these changes require obtaining a new certificate. Additionally, they are backwards-compatible. Where necessary, servers may enable both modern and legacy options, to continue to support legacy clients. Note, however, such support may carry security risks. (For example, see the DROWN, FREAK, and ROBOT attacks.)

Over the coming Chrome releases, we will improve the DevTools Security Panel to point out deviations from these settings, and suggest improvements to the site’s configuration.

Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by setting the SSLVersionMin policy to “tls1.2”. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 until January 2021.

Evidence shows that three of the most destructive incidents seen in modern cyber-history are the work of one APT.

Facebook's VP of product management was able to discuss more specifics about how the breach itself occurred.

Two weeks after Facebook's first serious data breach, and the social network has shared what it has figured out so far.

Avast v Brně slavnostně otevřel své nové sídlo. Najdete ho v areálu bývalého závodu Vlněna, na jehož místě nyní vzniká nový komplex moderních kancelářských budov. V první dokončené budově našel nové zázemí právě Avast. Přibližně čtyři stovky zaměstnanců se nestěhovaly z daleka, doposud měly ...

In the past, they've pretended to have your passwords - now they're pretending to send email from your "hacked" account, too.

In a twist on Business Email Compromise, they're spoofing literary agents and going after manuscripts at Penguin Random House and Pan Macmillan.

Hned šest podvodných bankovních aplikací, prostřednictvím kterých se snaží kybernetičtí piráti připravit uživatele o peníze, objevili bezpečnostní experti z antivirové společnosti Eset. Situace je o to závažnější, že všechny programy mohli lidé stáhnout přímo z oficiálního obchodu z aplikace Google Play.

From the WhatsApp hack to the world's most expensive USB stick, and everything in between. Catch up with everything we've written in the last 7 days - it's weekly roundup time.

Hi there,

This is my latest article on a topic near and dear to my heart: making IDA Pro more modern and, well, better.

Those familiar with IDA Pro probably know that feeling: there are glitches in the processor modules that you use, you don't have the source code, and they are driving you crazy! Unfortunately, not all of the glitches discussed here qualify as bugs, meaning that the developers are unlikely to ever fix them—unless you fix them yourself.

Localizing the glitchesNote: In this article, I will be looking for bugs and issues in the Motorola M68000 module (which happens to be my favorite, as well as a commonly used one).

Glitch #1: Addressing relative to the PC register. Specifically, the disassembler listing for such instructions is not always correct. Check out this screenshot:


Everything seems fine at first glance. And the glitch does not even interfere with analysis. But the opcode has been disassembled incorrectly. Let's look at this in an online disassembler:


We see that our addressing should be relative to the PC register since the target address of the reference is within the signed short range.

Glitch #2: "Mirrors" for RAM and certain other regions. Since addressing on m68k is 24-bit, all access to high (or low) regions should be re-addressed to the same range as the cross-references.

Glitch #3 (which is more like "missing functionality" than an actual glitch): The so-called lineA (1010) and lineF (1111) emulators. These opcodes did not make it into the main command set, so they have to be handled in a special way by interrupt vectors. The size of the opcodes depends only on the implementation in the handler. I've seen only a two-byte implementation. So we'll be adding this.

Glitch #4: Trap #N instruction" does not give any cref to the trap handlers.

Glitch #5: The movea.w instruction should make a full xref to an address from a word reference, but we get only a word integer.

Fixing the glitches (empty template)
To understand how to fix a particular processor module, you have to know what our abilities are in this regard, and what exactly a "fix" means.

In short: a fix is delivered in the form of a plug-in, which can be written in either Python or C++ (I chose the latter). C++ is less portable but if anyone is willing to take up the task of porting the plug-in to Python, I will be only grateful!

First we create an empty DLL project in Visual Studio: File->New->Project->Windows Desktop Wizard->Dynamic link library (.dll). Select the Empty Project checkbox and clear all the other checkboxes:


We unpack the IDA SDK and indicate it in the Visual Studio macros (here I am using the 2017 version), which makes it easy to refer to in the future. We simultaneously will add a macro for the path to IDA Pro.

Go to View->Other Windows->Property Manager:


Since we are working with SDK version 7.0, compilation will be performed with the x64 compiler. So select Debug | x64->Microsoft.Cpp.x64.user->Properties:


In the User Macros section, click Add Macro. There we will indicate IDA_SDK alongside the path of where we unpacked the SDK:


Now we can do the same with IDA_DIR (the path being for your copy of IDA Pro):


(By default, IDA is installed in %Program Files%, which requires administrator rights.)

Let's also get rid of the Win32 configuration (this article does not cover compilation for x86 systems) and leave just x64.

Create the empty file ida_plugin.cpp, which for the moment contains no code. Now we can select the character set and other settings for C++:




Now add some includes:



And SDK libraries:



Now we drop in the code template:

#include #include #include #include #include #include #define NAME "M68000 proc-fixer plugin"#define VERSION "1.0" static bool plugin_inited; static bool my_dbg; //--------------------------------------------------------------------------static void print_version(){ static const char format[] = NAME " v%s\n"; info(format, VERSION); msg(format, VERSION); } //--------------------------------------------------------------------------static bool init_plugin(void){ if (ph.id != PLFM_68K) return false; return true; } #ifdef _DEBUGstatic const char* const optype_names[] = { "o_void", "o_reg", "o_mem", "o_phrase", "o_displ", "o_imm", "o_far", "o_near", "o_idpspec0", "o_idpspec1", "o_idpspec2", "o_idpspec3", "o_idpspec4", "o_idpspec5", }; static const char* const dtyp_names[] = { "dt_byte", "dt_word", "dt_dword", "dt_float", "dt_double", "dt_tbyte", "dt_packreal", "dt_qword", "dt_byte16", "dt_code", "dt_void", "dt_fword", "dt_bitfild", "dt_string", "dt_unicode", "dt_3byte", "dt_ldbl", "dt_byte32", "dt_byte64", }; static void print_insn(const insn_t *insn){ if (my_dbg) { msg("cs=%x, ", insn->cs); msg("ip=%x, ", insn->ip); msg("ea=%x, ", insn->ea); msg("itype=%x, ", insn->itype); msg("size=%x, ", insn->size); msg("auxpref=%x, ", insn->auxpref); msg("segpref=%x, ", insn->segpref); msg("insnpref=%x, ", insn->insnpref); msg("insnpref=%x, ", insn->insnpref); msg("flags["); if (insn->flags & INSN_MACRO) msg("INSN_MACRO|"); if (insn->flags & INSN_MODMAC) msg("OF_OUTER_DISP"); msg("]\n"); } } static void print_op(ea_t ea, const op_t *op){ if (my_dbg) { msg("type[%s], ", optype_names[op->type]); msg("flags["); if (op->flags & OF_NO_BASE_DISP) msg("OF_NO_BASE_DISP|"); if (op->flags & OF_OUTER_DISP) msg("OF_OUTER_DISP|"); if (op->flags & PACK_FORM_DEF) msg("PACK_FORM_DEF|"); if (op->flags & OF_NUMBER) msg("OF_NUMBER|"); if (op->flags & OF_SHOW) msg("OF_SHOW"); msg("], "); msg("dtyp[%s], ", dtyp_names[op->dtype]); if (op->type == o_reg) msg("reg=%x, ", op->reg); else if (op->type == o_displ || op->type == o_phrase) msg("phrase=%x, ", op->phrase); else msg("reg_phrase=%x, ", op->phrase); msg("addr=%x, ", op->addr); msg("value=%x, ", op->value); msg("specval=%x, ", op->specval); msg("specflag1=%x, ", op->specflag1); msg("specflag2=%x, ", op->specflag2); msg("specflag3=%x, ", op->specflag3); msg("specflag4=%x, ", op->specflag4); msg("refinfo["); opinfo_t buf; if (get_opinfo(&buf, ea, op->n, op->flags)) { msg("target=%x, ", buf.ri.target); msg("base=%x, ", buf.ri.base); msg("tdelta=%x, ", buf.ri.tdelta); msg("flags["); if (buf.ri.flags & REFINFO_TYPE) msg("REFINFO_TYPE|"); if (buf.ri.flags & REFINFO_RVAOFF) msg("REFINFO_RVAOFF|"); if (buf.ri.flags & REFINFO_PASTEND) msg("REFINFO_PASTEND|"); if (buf.ri.flags & REFINFO_CUSTOM) msg("REFINFO_CUSTOM|"); if (buf.ri.flags & REFINFO_NOBASE) msg("REFINFO_NOBASE|"); if (buf.ri.flags & REFINFO_SUBTRACT) msg("REFINFO_SUBTRACT|"); if (buf.ri.flags & REFINFO_SIGNEDOP) msg("REFINFO_SIGNEDOP"); msg("]"); } msg("]\n"); } } #endif static bool ana_addr = 0; static ssize_t idaapi hook_idp(void *user_data, int notification_code, va_list va){ switch (notification_code) { case processor_t::ev_ana_insn: { insn_t *out = va_arg(va, insn_t*); if (ana_addr) break; ana_addr = 1; if (ph.ana_insn(out) <= 0) { ana_addr = 0; break; } ana_addr = 0; #ifdef _DEBUG print_insn(out); #endif for (int i = 0; i < UA_MAXOP; ++i) { op_t &op = out->ops[i]; #ifdef _DEBUG print_op(out->ea, &op); #endif } return out->size; } break; case processor_t::ev_emu_insn: { const insn_t *insn = va_arg(va, const insn_t*); } break; case processor_t::ev_out_mnem: { outctx_t *outbuffer = va_arg(va, outctx_t *); //outbuffer->out_custom_mnem(mnem); //return 1; } break; default: { #ifdef _DEBUG if (my_dbg) { msg("msg = %d\n", notification_code); } #endif } break; } return 0; } //--------------------------------------------------------------------------static int idaapi init(void){ if (init_plugin()) { plugin_inited = true; my_dbg = false; hook_to_notification_point(HT_IDP, hook_idp, NULL); print_version(); return PLUGIN_KEEP; } return PLUGIN_SKIP; } //--------------------------------------------------------------------------static void idaapi term(void){ if (plugin_inited) { unhook_from_notification_point(HT_IDP, hook_idp); plugin_inited = false; } } //--------------------------------------------------------------------------static bool idaapi run(size_t /*arg*/){ return false; } //--------------------------------------------------------------------------const char comment[] = NAME; const char help[] = NAME; //--------------------------------------------------------------------------//// PLUGIN DESCRIPTION BLOCK////--------------------------------------------------------------------------plugin_t PLUGIN = { IDP_INTERFACE_VERSION, PLUGIN_PROC | PLUGIN_MOD, // plugin flags init, // initialize term, // terminate. this pointer may be NULL. run, // invoke plugin comment, // long comment about the plugin // it could appear in the status line // or as a hint help, // multiline help about the plugin NAME, // the preferred short name of the plugin "" // the preferred hotkey to run the plugin};

Show/Hide

Fixing the bugs (filling out the template)
The print_op() and print_insn() functions are needed so we can see which flags have been set by the current processor module for certain instructions. This is necessary for finding flags for available opcodes so we can use them in our fix.

The body of our "fixer" is the hook_idp() function. For our needs, we will need to implement three callbacks in it:

1. processor_t::ev_ana_insn: this is needed if the processor module does not implement some opcodes
2. processor_t::ev_emu_insn: here you can make cross-references to data/code to which new opcodes refer (or old ones do not refer)
3. processor_t::ev_out_mnem: new opcodes need to get output somehow—so that's what goes on here

The init_plugin() function will stop our fixer from launching on other processor modules.
And most importantly, we hook the whole callback to processor module events:

hook_to_notification_point(HT_IDP, hook_idp, NULL);

The trick with the ana_addr global variable is necessary so that ana_insn does not get stuck in recursion when trying to get information about an instruction that we do not parse manually. This crutch has been around for a long time since early versions, and alas, doesn't seem to be going away anytime soon.
Fix for Glitch #1
Finding a solution required a lot of mucking about with the debugger output that I implemented for the purpose. I knew that in some cases, IDA successfully outputs references relative to PC (for instructions where a jump is made based on an offset table that is near the current instruction plus register index); but proper display of addressing had not been implemented for the lea instruction. Ultimately, I found one such instruction with a jump and figured out which flags are needed to make PC display properly with parentheses:

case processor_t::ev_ana_insn: { insn_t *out = va_arg(va, insn_t*); if (ana_addr) break; ana_addr = 1; if (ph.ana_insn(out) <= 0) { ana_addr = 0; break; } ana_addr = 0; for (int i = 0; i < UA_MAXOP; ++i) { op_t &op = out->ops[i]; switch (op.type) { case o_near: case o_mem: { if (out->itype != 0x76 || op.n != 0 || (op.phrase != 0x09 && op.phrase != 0x0A) || (op.addr == 0 || op.addr >= (1 << 23)) || op.specflag1 != 2) // lea table(pc),Ax break; short diff = op.addr - out->ea; if (diff >= SHRT_MIN && diff <= SHRT_MAX) { out->Op1.type = o_displ; out->Op1.offb = 2; out->Op1.dtype = dt_dword; out->Op1.phrase = 0x5B; out->Op1.specflag1 = 0x10; } } break; } } return out->size; } break;
Fix for Glitch #2
Here things are simple. We simply mask addresses for a specific range: 0xFF0000-0xFFFFFF (for RAM) and 0xC00000–0xC000FF (for VDP video memory). The main thing is to filter by operand type with o_near and o_mem.

case processor_t::ev_ana_insn: { insn_t *out = va_arg(va, insn_t*); if (ana_addr) break; ana_addr = 1; if (ph.ana_insn(out) <= 0) { ana_addr = 0; break; } ana_addr = 0; for (int i = 0; i < UA_MAXOP; ++i) { op_t &op = out->ops[i]; switch (op.type) { case o_near: case o_mem: { op.addr &= 0xFFFFFF; // for any mirrors if ((op.addr & 0xE00000) == 0xE00000) // RAM mirrors op.addr |= 0x1F0000; if ((op.addr >= 0xC00000 && op.addr <= 0xC0001F) || (op.addr >= 0xC00020 && op.addr <= 0xC0003F)) // VDP mirrors op.addr &= 0xC000FF; } break; } } return out->size; } break;

Fix for Glitch #3
To add the opcodes, what we need to do is:

1. Define indexes for the new opcodes. All new indexes should start with: CUSTOM_INSN_ITYPE

enum m68k_insn_type_t{ M68K_linea = CUSTOM_INSN_ITYPE, M68K_linef, };

2. The lineA/lineF opcodes trigger when the following bytes are encountered in the code: 0xA0/0xF0. So we read one byte.

3. Get reference to the handling vector. The interrupt vectors are located in the first 64 dwords of the header, in my case. The lineA/lineF handlers are at positions 0x0A and 0x0B:

value = get_dword(0x0A * sizeof(uint32)); // ...value = get_dword(0x0B * sizeof(uint32));

4. In ev_emu_insn we add cross-references for handlers and the following instruction to avoid interrupting the code flow:

insn->add_cref(insn->Op1.addr, 0, fl_CN); // code ref insn->add_cref(insn->ea + insn->size, insn->Op1.offb, fl_F); // flow ref

5. In ev_out_mnem we output our custom opcode:

const char *mnem = (outbuffer->insn.itype == M68K_linef) ? "line_f" : "line_a"; outbuffer->out_custom_mnem(mnem);


enum m68k_insn_type_t{ M68K_linea = CUSTOM_INSN_ITYPE, M68K_linef, }; /* after includes */ case processor_t::ev_ana_insn: { insn_t *out = va_arg(va, insn_t*); if (ana_addr) break; uint16 itype = 0; ea_t value = out->ea; uchar b = get_byte(out->ea); if (b == 0xA0 || b == 0xF0) { switch (b) { case 0xA0: itype = M68K_linea; value = get_dword(0x0A * sizeof(uint32)); break; case 0xF0: itype = M68K_linef; value = get_dword(0x0B * sizeof(uint32)); break; } out->itype = itype; out->size = 2; out->Op1.type = o_near; out->Op1.offb = 1; out->Op1.dtype = dt_dword; out->Op1.addr = value; out->Op1.phrase = 0x0A; out->Op1.specflag1 = 2; out->Op2.type = o_imm; out->Op2.offb = 1; out->Op2.dtype = dt_byte; out->Op2.value = get_byte(out->ea + 1); } return out->size; } break; case processor_t::ev_emu_insn: { const insn_t *insn = va_arg(va, const insn_t*); if (insn->itype == M68K_linea || insn->itype == M68K_linef) { insn->add_cref(insn->Op1.addr, 0, fl_CN); insn->add_cref(insn->ea + insn->size, insn->Op1.offb, fl_F); return 1; } } break; case processor_t::ev_out_mnem: { outctx_t *outbuffer = va_arg(va, outctx_t *); if (outbuffer->insn.itype != M68K_linea && outbuffer->insn.itype != M68K_linef) break; const char *mnem = (outbuffer->insn.itype == M68K_linef) ? "line_f" : "line_a"; outbuffer->out_custom_mnem(mnem); return 1; } break;
Fix for Glitch #4Find the opcode for the trap instruction, get the index from the instruction, and take the handler vector at that index. The result resembles the following:



case processor_t::ev_emu_insn: { const insn_t *insn = va_arg(va, const insn_t*); if (insn->itype == 0xB6) // trap #X { qstring name; ea_t trap_addr = get_dword((0x20 + (insn->Op1.value & 0xF)) * sizeof(uint32)); get_func_name(&name, trap_addr); set_cmt(insn->ea, name.c_str(), false); insn->add_cref(trap_addr, insn->Op1.offb, fl_CN); return 1; } } break;

Fix for Glitch #5
Things are clear-cut here too: first filter by the movea.w operation. Then, if the operand is of the word type and refers to RAM, we make a snazzy reference relative to the base 0xFF0000. Here's how this looks:



case processor_t::ev_ana_insn: { insn_t *out = va_arg(va, insn_t*); if (ana_addr) break; ana_addr = 1; if (ph.ana_insn(out) <= 0) { ana_addr = 0; break; } ana_addr = 0; for (int i = 0; i < UA_MAXOP; ++i) { op_t &op = out->ops[i]; switch (op.type) { case o_imm: { if (out->itype != 0x7F || op.n != 0) // movea break; if (op.value & 0xFF0000 && op.dtype == dt_word) { op.value &= 0xFFFF; } } break; } } return out->size; } break; case processor_t::ev_emu_insn: { const insn_t *insn = va_arg(va, const insn_t*); for (int i = 0; i < UA_MAXOP; ++i) { const op_t &op = insn->ops[i]; switch (op.type) { case o_imm: { if (insn->itype != 0x7F || op.n != 0 || op.dtype != dt_word) // movea break; op_offset(insn->ea, op.n, REF_OFF32, BADADDR, 0xFF0000); } break; } } } break;

Conclusions
Making fixes to modules can be rather involved, especially when it's something more complicated than simply implementing unknown opcodes.

This can mean hours of debugging the current implementation and trying to figure out how it all works (perhaps with some reversing of the module itself). But the results are well worth it.

Link to code: https://github.com/lab313ru/m68k_fixer

Author: Vladimir Kononovich, Positive Technologies

For the last two years we have been monitoring a Russian-language cyberespionage actor that focuses on Central Asian users and diplomatic entities. We named the actor DustSquad and have provided private intelligence reports to our customers on four of their campaigns involving custom Android and Windows malware. In this blogpost we cover a malicious program for Windows called Octopus that mostly targets diplomatic entities.

The name was originally coined by ESET in 2017 after the 0ct0pus3.php script used by the actor on their old C2 servers. We also started monitoring the malware and, using Kaspersky Attribution Engine based on similarity algorithms, discovered that Octopus is related to DustSquad, something we reported in April 2018. In our telemetry we tracked this campaign back to 2014 in the former Soviet republics of Central Asia (still mostly Russian-speaking), plus Afghanistan.

In the case of Octopus, DustSquad used Delphi as their programming language of choice, which is unusual for such an actor. Among others exceptions are the Russian-language Zebrocy (Sofacy’s Delphi malware), the Hindi-language DroppingElephant and the Turkish-language StrongPity. Although we detected Octopus victims that were also infected with Zebrocy/Sofacy, we didn’t find any strong similarities and we don’t consider the two actors to be related.

What happened?

In April 2018 we discovered a new Octopus sample pretending to be communication software for a Kazakh opposition political group. The malware is packed into a ZIP file named dvkmailer.zip with a timestamp from February-March 2018. DVK stands for Kazakhstan Democratic Choice, an opposition political party that is prohibited in the country. The image below shows the acronym ‘ДВК’ in Russian (Демократический Выбор Казахстана). DVK enjoys a healthy Telegram presence, making Telegram´s potential ban a hot topic in Kazakhstan. The dropper pretends to be Telegram Messenger with a Russian interface.

We couldn´t find any legitimate software that this malware appears to be impersonating; in fact, we don´t believe it exists. The Trojan uses third-party Delphi libraries like The Indy Project for JSON-based C2 communications and TurboPower Abbrevia (sourceforge.net/projects/tpabbrevia) for compression. Malware persistence is basic and achieved via the system registry. The server side uses commercial hosting in different countries with .php scripts deployed. Kaspersky Lab products detect the Octopus Trojan as Trojan.Win32.Octopus.gen. For more information, please contact: intelreports@kaspersky.com.

Technical details

The attackers used the potential Telegram ban in Kazakhstan to push its dropper as an alternative communication software for the political opposition.

‘Telegram messenger’ establishes network module persistence in the simplest way and starts the module

We can’t confirm how this malware is being distributed, although it clearly uses some form of social engineering. This actor previously used spear phishing to spread malware.

Dropper MD5 hash 979eff03faeaeea5310df53ee1a2fc8e Name dvkmailer.zip Archive contents d6e813a393f40c7375052a15e940bc67 CsvHelper.dll Legit .NET CSV files parser 664a15bdc747c560c11aa0cf1a7bf06e Telegram Messenger.exe Persistence and launcher 87126c8489baa8096c6f30456f5bef5e TelegramApi.dll Network module d41d8cd98f00b204e9800998ecf8427e Settings.json Empty Launcher MD5 hash 664a15bdc747c560c11aa0cf1a7bf06e File name Telegram Messenger.exe PE timestamp 2018.03.18 21:34:12 (GMT) Linker version 2.25 (Embarcadero Delphi)

Before any user interaction, inside the FormCreate() function the launcher checks for a file named TelegramApi.dll in the same directory. If it exists, the launcher copies the network module to the startup directory as Java.exe and runs it.

The ‘Send mailing’ button in the bottom right corner doesn’t even have a handler function

Delphi Visual Component Library (VCL) programs are based on event handlers for form elements. Such programs are extremely large (about 2.6 MB and 12,000 functions), but all this code is mostly used to handle the visual components and run-time libraries. There are only three programmer-defined handlers for controlling elements inside the Octopus launcher.

Function name Functionality FormCreate() Runs as constructor before any user activity. Makes the network module persistent via Startup directory and runs it Button1Click() Shows the explorer dialog window to choose the “mailing file” DateTimePicker1Click() Shows calendar to select the “mailing date”

There is no handler for the ‘Send mailing’ button, so the launcher pretends to be an alternative communicator that in reality does nothing. This may be because the malware is still unfinished – after all, messages sent through it could be of value to the attackers. However, we believe it is more likely that the malware was created in a hurry and the attackers decided to skip any communication features.

Network module

C2 communication scheme

MD5 hash 87126c8489baa8096c6f30456f5bef5e File name TelegramApi.dll PE timestamp 2018.02.06 11:09:28 (GMT) Linker version 2.25 (Embarcadero Delphi)

Despite the file extension, this network module is a self-sufficient portable executable file and not a dynamic-link library. The first sample checks for files with names like 1?????????.* in the user’s temporary folder and deletes any files it finds. Then it creates .profiles.ini in the Application Data directory where the malware stores its log.

HTTP request Response GET /d.php?check JSON “ok” GET /d.php?servers JSON domain name GET /i.php?check= JSON “ok” POST /i.php?query= JSON response code or command depends on POST data

First stage .php script to check connection and get C2 domain name

All network modules consist of hardcoded IP addresses belonging to commercial web-hosting services based in different countries. The operators simply deploy their first-stage .php script in them, which will check the connection and get the actual C2 server domain name using an HTTP GET request.

After the initial connection check, the malware receives a JSON with the actual C2 domain name

Then the network module checks against the hardcoded victim’s id

The network module checks against a 32-digit hardcoded victim id and sends the gathered data to the C2 using a HTTP POST request. In terms of programming, this id is strange, because the malware simultaneously ‘fingerprints’ its victim with an MD5 hash of its system data.

JSON-based gathered data sent in a HTTP POST base64-encoded request

All communication with the C2s is based on JSON-formatted data and the HTTP protocol. For that, the developers used The Indy Project (indyproject.org) publicly available library as well as the third-party TurboPower Abbrevia (sourceforge.net/projects/tpabbrevia) for compression.

After all the initial HTTP GET requests, the malware starts to gather JSON-formatted system data. For all the fixed drives in the system, the network module stores the disk name and size, as well as computer and user name, Windows directory, host IP, etc. One interesting field is “vr”:”2.0″ which appears to be the malware version encoded in the communication protocol.

The ‘id’ field is the victim’s fingerprint for which the malware actively uses the Windows Management Instrumentation mechanism. The Trojan runs WMIC.exe with the following arguments:

C:\WINDOWS\system32\wbem\WMIC.exe computersystem get Name /format:list C:\WINDOWS\system32\wbem\WMIC.exe os get installdate /format:list C:\WINDOWS\system32\wbem\WMIC.exe path CIM_LogicalDiskBasedOnPartition get Antecedent,Dependent

Then the module concatenates the gathered ids and computes an MD5 hash, which will be the victim’s final id. The “act” field numbers the communication stage (0 for initial fingerprinting). After this, the HTTP POST control server returns a JSON {“rt”:”30″} and the client continues with the next “act” in the HTTP POST:

At this point the C2 sends a JSON with commands to execute, including uploading/downloading files, taking a screenshot and finding *.rar archives on the host.

Other software

Besides the Trojan itself, the Octopus developers used the password dumping utility fgdump.

Infrastructure MD5 hash IPs C2 domain 87126c8489baa8096c6f30456f5bef5e 185.106.120.27
204.145.94.10 porenticofacts.com ee3c829e7c773b4f94b700902ea3223c 38f30749a87dcbf156689300737a094e 185.106.120.240
204.145.94.101 certificatesshop.com 6e85996c021d55328322ce8e93b31088 5.188.231.101
103.208.86.238 blondehairman.com 7c0050a3e7aa3172392dcbab3bb92566 5.8.88.87
103.208.86.237 latecafe.in 2bf2f63c927616527a693edf31ecebea 85.93.31.141
104.223.20.136 hovnanflovers.com d9ad277eb23b6268465edb3f68b12cb2 5.188.231.101
103.208.86.238 blondehairman.com

The most recent samples (2017-2018) of hardcoded IPs and web domains obtained from the .php script

Conclusions

Political entities in Central Asia have been targeted throughout 2018 by different actors, including IndigoZebra, Sofacy (with Zebrocy malware) and most recently by DustSquad (with Octopus malware). Interestingly, we observed some victims who are ‘threat magnets’ targeted by all of them. From our experience we can say that the interest shown by threat actors in this region is now high, and the traditional ‘players’ have been joined by relative newcomers like DustSquad that have sprung up locally.

Indicators of compromise File hashes

87126c8489baa8096c6f30456f5bef5e
ee3c829e7c773b4f94b700902ea3223c
38f30749a87dcbf156689300737a094e
6e85996c021d55328322ce8e93b31088
7c0050a3e7aa3172392dcbab3bb92566
2bf2f63c927616527a693edf31ecebea
d9ad277eb23b6268465edb3f68b12cb2

Domains and IPs

85.93.31.141
104.223.20.136
5.8.88.87
103.208.86.237
185.106.120.240
204.145.94.101
5.188.231.101
103.208.86.238
185.106.120.27
204.145.94.10
hovnanflovers.com
latecafe.in
certificatesshop.com
blondehairman.com
porenticofacts.com

Auxiliary URLs to upload/download files:

www.fayloobmennik.net/files/save_new.html
http://uploadsforyou.com/download/
http://uploadsforyou.com/remove/

The following are old indicators of compromise no longer used by this actor, but which can be used for forensic purposes:

031e4900715564a21d0217c22609d73f
1610cddb80d1be5d711feb46610f8a77
1ce9548eae045433a0c943a07bb0570a
3a54b3f9e9bd54b4098fe592d805bf72
546ab9cdac9a812aab3e785b749c89b2
5cbbdce774a737618b8aa852ae754251
688854008f567e65138c3c34fb2562d0
6fda541befa1ca675d9a0cc310c49061
73d5d104b34fc14d32c04b30ce4de4ae
88ad67294cf53d521f8295aa1a7b5c46
a90caeb6645b6c866ef60eb2d5f2d0c5
ae4e901509b05022bbe7ef340f4ad96c
ca743d10d27277584834e72afefd6be8
ce45e69eac5c55419f2c30d9a8c9104b
df392cd03909ad5cd7dcea83ee6d66a0
e149c1da1e05774e6b168b6b00272eb4
f625ba7f9d7577db561d4a39a6bb134a
fc8b5b2f0b1132527a2bcb5985c2fe6b
f7b1503a48a46e3269e6c6b537b033f8
4f4a8898b0aa4507dbb568dca1dedd38

First stage .php script placed at:

148.251.185.168
185.106.120.46
185.106.120.47
46.249.52.244
5.255.71.84
5.255.71.85
88.198.204.196
92.63.88.142

Domains returned by .php script:

giftfromspace.com
mikohanzer.website
humorpics.download
desperados20.es
prom3.biz.ua

Společnost Facebook upřesnila detaily útoku, v jehož rámci mělo být ohroženo až 50 miliónů uživatelů. Zástupci společnosti na konci minulého týdne upřesnili, že hackeři se dostali jen k 29 miliónům účtů.

In an effort to secure users' data while maintaining privacy, Google has announced a new security measure for Android Backup Service that now encrypts all your backup data stored on its cloud servers in a way that even the company can't read it. Google allows Android users to automatically backup their essential app data and settings to their Google account, allowing them to simply restore it

Itálie se staví proti záměru ostatních zemí Evropské unie sankcionovat státy, které podnikají kybernetické útoky. Podle agentury Reuters to ukazuje tajný unijní dokument, který dostala k nahlédnutí. Postoj Říma by korespondoval s dřívějšími výzvami ke snižování napětí ve vztahu k Rusku, píše Reuters.

** Co se může stát, když relativně maličký dron narazí do křídla letadla? ** Tuto otázku zodpověděli odborníci laboratorním pokusem ** Kvadrokoptéra způsobila významné poškození křídla

Pardubická policie v sobotu varovala lékaře a podnikatele před podvodníky, kteří rozesílají faktury za údajně sjednané reklamní služby a požadují peníze. Kriminalisté evidují již desítky poškozených. Rozesílané mailové zprávy podle policie obsahují spoustu chyb.

Late last month Facebook announced its worst-ever security breach that allowed an unknown group of hackers to steal secret access tokens for millions of accounts by taking advantage of a flaw in the 'View As' feature. At the time of the initial disclosure, Facebook estimated that the number of users affected by the breach could have been around 50 million, though a new update published today by

Americkému ministerstvu obrany unikla data o cestovních záznamech s citlivými informacemi o vojácích a civilních zaměstnancích. Pentagon oznámil, že rozsah incidentu je stále předmětem vyšetřování, podle informací televize Fox News ale mohl postihnout až 30 000 zaměstnanců.

A survey of ICS security posture found outdated firewalls, improper segmentation password mistakes and more.