Leaderboard
Popular Content
Showing content with the highest reputation on 07/14/20 in all areas
-
Aici e un forum de baieti discreti pe umarul carora poti plange. @aismen iti poate trimite un cod de introducere.4 points
-
Nu stiu de ce, dar pari genul de om care face asta: - Instalezi windows curat apoi descarci un activator pentru licenta - Intrii pe filelist si descarci un antivirus cu crack, ca astia sunt escroci si cer bani pe ele - Ai impresia ca securitatea se rezuma la un software instalat in cateva click-uri2 points
-
Sigur ai trimis ceva nașpa. Asa ca nu dau click👍 Aș aprecia să nu va irositi timpul degeaba scriind alte chestii de prisos. Mulțumesc!1 point
-
1 point
-
Dc e vdf poti verifica nr catre care se initiaza apeluri se trimite sms. Trebuie sa te loghezi in cont. https://www.vodafone.ro/vfrointegration/appmanager/vfroportal/cartela?_nfpb=true&_windowLabel=OCS_DetaliereServicii&_urlType=action&wlpOCS_DetaliereServicii_action=search&_pageLabel=OCS_Detaliere_Servicii_Page Trebuie sa citesti si sa fii de acord si sa respecti termenii si conditiile:1 point
-
Sa-i "spionezi" telefonul poate avea consecinte legale destul de grave.1 point
-
Nu se transfera nimic automat. Ce poate sa faca e sa scaneze de porturi si sa gaseasca vreun serviciu vulnerabil, asa sa se "multiplice". Ceea ce e putin probabil. Acel RAT a ajuns la tine pentru ca probabil ai descarcat cine stie ce mizerie infectata. De unde stii ca ai RAT daca nu e detectabil? Instaleaza un antivirus adevarat, Kaspersky sau Bitdefender si scaneaza. Daca gasesc ceva, il sterg. Daca nu, nu il ai. Nu vine NSA sa lucreze ani de zile la bypassuri de AV pentru un RAT care sa ajunga la oameni random.1 point
-
Dacă și FoxNews și CNN sunt rusești apoi eu îmi tai coele. Daca te deranjează adevarul stai in banca ta și nu mai inventa propagande rusești sau alte vrăjeli. Testele CoVID sunt o vrajeala mare pentru prosti, mai ales pentru medicii prosti și cei slugaci. https://www.foxnews.com/world/coronavirus-tests-uk-contaminated-covid-19 https://edition.cnn.com/world/live-news/coronavirus-pandemic-04-19-20-intl/h_b3536880a979b718016cd9774815ee141 point
-
@RazvanDC @andr82 Mai usor cu prelandezul. Cititi o stire si o faceti suprodoza cu propaganda ruseasca. Ca fapt divers NIMENI nu a fost diagnosticat gresit cu covid din cauza testelor contaminate. Ce s-a intamplat e ca mai multe firme private care fac testul s-au grabit si au facut o greseala foarte comuna de a lasa contaminanti in primer. Chestia asta se mai intampla daca laboratorul nu are o exigenta foarte mare. Reactia PCR de detectare a virusului are insa 3 parti foarte importante. Test reaction unde e monstra de la pacient si unde ar trebui sa apara virusul Negative control unde nu e monstra de la pacient si unde nu ar tebui sa apara nimic. Practic care confirma ca testul e valid Positive control unde e o monstra verificata si unde trebuie sa apara virusul. Ei bine, kiturile contaminate in primer au iesit pozitive pe negative control! Adica nimeni nu a putut fi diagnosticat! Adica e rau ca tehnicienii in loc sa testeze pacientii se chinuie cu teste invalide sa le faca de 100 de ori. Adica nu e nicio conspiratie aici. Doar niste firme care s-au supra-muncit si niste tehnicieni enervati.1 point
-
Orice setare de genul pe o sapuniera de router, este inutila. Firewall-ul este activ la routing / forwarding intre WAN si LAN, nu intre LAN si LAN. (reteaua interna). Pe LAN <-> LAN e doar switching.1 point
-
I indexed all Windows files which appear in Windows update packages, and created a website which allows to quickly view information about the files and download some of them from Microsoft servers. The files that can be downloaded are executable files (currently exe, dll and sys files). Read on for further information. Motivation During a recent research project, I had to track down a bug that Microsoft fixed in one of the drivers. I needed to find out which update fixed the bug. I knew that the bug exists on an unpatched RTM build, and is fixed on a fully patched system. All I needed was the dozens of file versions of that driver, so that I could look at them manually until I find the version that introduced the fix. Unfortunately, to the best of my knowledge there was no place where one could get just these dozens of files without downloading extra GBs of data, be it ISOs or update packages. While searching for the simplest solution, these are the options I considered: Install an unpatched RTM build with automatic updates disabled, and install each update manually. Get the driver file after each installed update. A more efficient option would be to do a binary search, installing the middle update first, and then continuing with the relevant half of the updates depending on whether that update fixed the bug. Extract each version of the file from a Windows package, such as an update package that can be download from the Microsoft Update Catalog or an archive from the Unified Update Platform. Look for the driver files on the internet. There are various fishy “dll fixer” websites that claim to provide versions of system files. Unfortunately, not only that these websites are mostly loaded with ads and the files are sometimes wrapped with a suspicious exe, they also don’t provide any variety of versions for a given file, usually having only one, seemingly randomly selected version. There are also potentially useful services like VirusTotal, but I didn’t find any such service which allows to freely download the files. Option 3 didn’t work, and I chose option 2 over 1 since downloading and extracting update packages seemed quicker than updating the OS every time. I also chose the Microsoft Update Catalog over the Unified Update Platform, since the latter is not really documented and is more obscure, and other than that provides no obvious benefits. Also, the update history is nicely documented by Microsoft: Windows 10 update history. There’s also Windows 7 SP1 update history and Windows 8.1 update history, but I focused on Windows 10. What’s in an update package Each update package that can be downloaded from the Microsoft Update Catalog is an msu file, which is basically a cab archive. Extracting it results in some metadata and another cab archive, which in turn contains the Windows files of the update. The update files are divided to assemblies, each assembly having a manifest file and a folder with the actual files. I expected that it would be enough to grab the file I’m looking for from the corresponding folder, but it turns out that newer update packages contain forward and reverse differentials instead of the actual files. Only 6 KB, no MZ header, clearly not the file I’m looking for. A quick search about the diff patching algorithm didn’t yield results, and I’d need the base Windows version anyway, so this option didn’t look appealing anymore. Just before giving up and trying the other options (the Unified Update Platform and installing updates manually), I looked at the information that is available in the manifest file. The only potentially interesting piece of information that I found is the list of files, which, among various unhelpful (for me) information, contains the file’s SHA256 hash: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved."> <assemblyIdentity name="Microsoft-Windows-SMBServer-v2" version="10.0.19041.153" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> <dependency discoverable="no" resourceType="Resources"> <!-- ... --> </dependency> <file name="srv2.sys" destinationPath="$(runtime.drivers)\" sourceName="srv2.sys" importPath="$(build.nttree)\" sourcePath=".\"> <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" /> <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:Transforms> <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" /> <dsig:DigestValue>pD5a0dKSCg7Kc0g1yDyWEX8n8ogPj/niCIy4yUR7WvQ=</dsig:DigestValue> </asmv2:hash> </file> <memberships> <!-- ... --> </memberships> <instrumentation xmlns:ut="http://manifests.microsoft.com/win/2004/08/windows/networkevents" xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <!-- ... --> </instrumentation> <localization> <!-- ... --> </localization> <trustInfo> <!-- ... --> </trustInfo> </assembly> You can see it under DigestValue, encoded as base64. In this case, that’s pD5a0dKSCg7Kc0g1yDyWEX8n8ogPj/niCIy4yUR7WvQ= which translates to a43e5ad1d2920a0eca734835c83c96117f27f2880f8ff9e2088cb8c9447b5af4. Can a SHA256 hash help me get the file? Maybe… The Microsoft Symbol Server Having some experience with the Microsoft Symbol Server, I know that it doesn’t only store symbol files, but also the PE (Portable Executable) files themselves. You can refer to the great article Symbols the Microsoft Way by Bruce Dawson for more details, but the most important detail for us is that the format for the path to each PE file in a symbol server is: “%s\%s\%08X%x\%s” % (serverName, peName, timeStamp, imageSize, peName) This means that all we need to retrieve the file from the Microsoft Symbol Server is to know the file’s timestamp and image size. But at this point, we only have the file’s SHA256 hash. VirusTotal to the rescue VirusTotal is a well known service for scanning files and URLs with multiple antivirus products and online scan engines. In addition to the scan results, VirusTotal displays some information about the submitted files. For PE files, it displays information such as imports and resources, but more importantly, it also displays the files’ timestamp and a list of sections. The latter can be used to calculate the file’s image size. In addition, if the file was scanned with VirusTotal before, the information can be retrieved by providing the file hash. That means that for each file previously scanned by VirusTotal, the SHA256 hash is enough to deduce the correct path on the Microsoft Symbol Server and download the file. Back to our example, the a43e5ad1d2920a0eca734835c83c96117f27f2880f8ff9e2088cb8c9447b5af4 hash can be found on VirusTotal, and the parameters that we need are the creation time: Creation Time: 2096-10-28 20:47:11 And the last section in the list of sections: Name: .reloc Virtual Address: 798720 Virtual Size: 12708 … You can Google for an “epoch converter” to convert the creation time to an epoch timestamp: 4002295631, or in hex: 0xee8e2f4f. You might need to append “GMT” to prevent the converter from reading the creation time as a local time. To calculate the image size, just add the virtual address and size of the last section: 798720+12708 = 811428 = 0xc61a4, and then align to the size of a page, which is 0x1000: 0xc7000. Combining the above, we can now build our download link: https://msdl.microsoft.com/download/symbols/srv2.sys/EE8E2F4Fc7000/srv2.sys Here’s a simple Python script which generates a Microsoft Symbol Server link from a file name and a file hash, automating what we just did manually. P.S. In case you’re wondering how come the file was created in 2096, it wasn’t. Starting with Windows 10, the timestamps of the system’s PE files are actually file hashes, a change that was made to allow reproducible builds. For more details see Raymond Chen’s blog post, Why are the module timestamps in Windows 10 so nonsensical?. P.P.S. If you read Bruce Dawson’s article, you saw that he talked about possible collisions in case there are two different files with the same timestamp and image size. He also described how Chrome had this exact problem. But Chrome used real timestamps, what about the pseudo-timestamps which are in fact file hashes that Windows 10 is using? In Windows’ case there are many collisions. I stumbled upon one, and got curious about the actual amount of such collisions, so I wrote a script to find all of them. Here’s the result, 3408 collisions! For most collisions (all but 54) the only different section is .rsrc which contains resource information, which means that the code and the data are the same. Perhaps the hashing algorithm isn’t affected by that section. I took one specific example (aitstatic.exe) and compared my system’s file (in a collision list) with the file served by the symbol server. The two had a different file version, the file served by the symbol server wasn’t signed, and the checksum (the real checksum field in the PE header, not the timestamp-checksum) was different. Also the file that was served by the symbol server was different than all of the files that I found in update packages. Looks like the symbol server sometimes returns a development file instead of a production one, which might be unsigned and have a different version. It might be confusing, and I’ve been bitten by this once, so remember: never trust the version of a file you download from the Microsoft Symbol Server. The other 54 collisions are of .NET PE files, and in this case other sections are different as well. But that doesn’t really matter, since they’re not available via the symbol server at all. Building an index That’s how I solved my problem, downloading several update packages and getting the driver files with the help of VirusTotal. But since all the files are so conveniently available via the Microsoft Symbol Server, I thought that it would be nice to index all of the files once, making the links for all PE files and versions available and saving myself and others from having to go through the procedure in the future. All I had to do is to get the list of updates from the Windows 10 update history page (for now, I looked only at Windows 10 updates), download these updates from the Microsoft Update Catalog, fetch the file names and hashes, query VirusTotal for these hashes, and make some nice interface to search in this index and generate links. Getting the list of updates That was the easy part, a simple Python script did the job. A funny thing I noticed is that the help page titles are edited manually, since they’re almost uniform, but some of them contain minor mistakes. Here are two examples for pages with a properly formatted title: June 18, 2020—KB4567523 (OS Build 19041.331) May 19, 2019—KB4505064 (OS Build 17134.766) And here are a couple of examples of titles with minor mistakes: May 21, 2019—KB4497934 (OS Build OS 17763.529) (an extra “OS”) September 29, 2016 — KB3194496 (OS Builds 14393.222) (“Builds”, but just one build) January 26, 2017—KB 3216755 (OS Build 14393.726) (the only entry with a space after “KB”) July 16, 2019—KB4507465 (OS Build 16299.1296 ) (a space before “)”) Downloading the updates from the Microsoft Update Catalog Most updates are available for three architectures: x86, x64 and ARM64. There are also updates for Windows Server in addition to Windows 10, but most, if not all of them are the same files for both Windows 10 and Windows Server. For now, I decided to limit the scope to x64. This part wasn’t as easy as the previous one, mainly because it’s so time consuming. In addition, it turned out that not all of the updates are available in the Microsoft Update Catalog. Out of the 502 updates available for Windows 10 while writing these lines, only 355 are available for x64. Out of the 147 which aren’t available, 27 are for Windows 10 Mobile (discontinued), one is only for x86, and one is only for Windows Server 2016. The other 118 are truly missing, 2 of which have a “no longer available” notice, and the others’ absence is not explained. Here is a detailed table with all of the updates and their availability for x64. Querying VirusTotal There are files of various types in the update packages, including non-PE files such as txt and png. For now, I decided to focus on exe, dll and sys which are the most common PE file types, even though there are other PE file types such as scr. Querying VirusTotal is quite simple, as I demonstrated with the Python script in the previous section about VirusTotal. The problem was that I needed to query information about 134,515 files, which is not a small amount. I was afraid of a strict rate limiting, but fortunately, the rate limiting wasn’t so strict. After a while I got a response similar to the following: { "error": { "code": "TooManyRequestsError", "message": "More than 1000 requests from 66.249.66.153 within a hour" } } So no more than 1000 requests within an hour, which means 5.5 days of downloading. I could use more computers, but that would be inconvenient. Even though it’s not too bad, I was uncomfortable seeing my script waiting every hour for the next quota of 1000 requests, so I used PyMultitor, the Python Multi Threaded Tor Proxy tool created by Tomer Zait. I heard about the tool a while ago, and finally had the perfect use case for it. I was pleasantly surprised how stable and easy to use it is (stability should also be attributed to the Tor project). With PyMultitor, I was able to reduce the time to 3 days of downloading. Of course, no data is returned if a file was never submitted to VirusTotal. Out of the 134,515 files, 108,470 were submitted, which is a success rate of 80.6%. Not bad! Also, 190 of the files were submitted, but the report for them didn’t contain details about the PE format. Rescanning them solved the problem. The result After building the index of files, I created a simple website which displays the data in a table. Here it is: Winbindex - the Windows Binaries Index All the files that were found in the update packages are listed, but currently only exe, dll and sys files have download links, except for those that weren’t submitted to VirusTotal. Possible further work I think that the index can already be very useful, but it’s not complete. Here are some things that can be done to further improve it: Indexing files from base builds. Currently, files which don’t appear in any update package, but appear in the initial Windows release aren’t indexed. To fill the gap, I’ll probably have to get the corresponding ISO files of the initial Windows releases. Indexing files which aren’t available on VirusTotal. There are several possible options here: Automating a VM that updates itself and grabs all the files. Understanding the diff algorithm to be able to get all the files from the update packages. Using the Unified Update Platform, although I’m not familiar enough with it to say if it can help with this. Indexing files of other architectures: x86 and ARM64, and of other Windows versions: Windows 7, Windows 8/8.1. I don’t plan to do any of that in the near future, but I might do that one day when I stumble upon another task which requires it. Source m417z.com1 point
-
1 point
-
Salutare la toti de mult nu am mai intrat pe forum si am fost activ dar acum am un pic de timp :) si m-am gandit sa mai postez si eu ceva. O zi buna va doresc. Buffer Overflow Attack in PDF ShapingUp. https://youtu.be/7wxQmmHjrLc1 point
-
Sursa: https://github.com/enkomio/shed/blob/master/README.md Shed is an application that allow to inspect the .NET runtime of a program in order to extract useful information. It can be used to inspect malicious applications in order to have a first general overview of which information are stored once that the malware is executed. Shed is able to: Inject a .NET Assembly in a remote process (both managed and un-managed) Extract all objects stored in the managed heap Print strings stored in memory Save the snapshot of the heap in a JSON format for post-processing Dump all modules that are loaded in memory Download Source code Download binary Using Shed Shed is a command line tool. To display all available options run: shed.exe --help Inspecting an already running application In order to inspect an already running process you have to pass the pid to Shed. Example: Shed.exe --pid 2356 Inspecting a binary In order to inspect a binary, Shed needs to execute it and to attach to it in order to inspect the runtime. Example: Shed.exe --exe malware.exe You can also specify the amount of time (in milliseconds) to wait before to suspend the process. This will allow the program to have the time to initialize its properties. Example: Shed.exe --timeout 2000 --exe malware.exe Injecting an Assembly in a remote process With Shed is possible to inject a .NET Assembly in a remote process thanks to the ManagedInjector Library. In order to do so, it is necessary to specify the pid of the process and the exe to inject. Once that the Assembly is injected is possible to activate it by invoking a specific method. The rules to identify the method are inherithed by the ManagedInjector project and are the following: You must specify the full method name to invoke (eg. this.is.my.namespace.class.method) You can inject an executable that defines an EntryPoint method to execute (like a Console project) You can define a method with the following signatue: <public|private> static void Inject() For example, to inject the Assembly InjectedAssembly into the process with pid 1234, you have the run Shed with the following command: shed.exe --pid 1234 --exe InjectedAssembly.dll --inject With the --method option you can specify a method, from InjectedAssembly.exe to invoke. Find below an example of execution: Dumping options By default Shed dump both the heap and the modules. If you want only one of that specify the --dump-heap option to dump only the objects in the heap or the --dump-modules to dump only the modules. Dumping the heap can produce a lot of information which are not strictly useful for the analysis. You can filter it by using two files: blacklist.txt this file contains the type names prefix that must not be logged whitelist.txt this file contains the type names prefix that must be logged even if blacklisted For example, if you want to filter all the System.IO namespace but you are interested in logging System.IO.MemoryStream, you can add the first value to blacklist.txt and the second one to whitelist.txt. Examples In the Examples folder you will find three different projects that you can use in order to test Shed. Example: Shed.exe --exe ..\Examples\ConfigurationSample\ConfigurationSample.exe When the analysis is completed, Shed will print where you can find the result, as shown below: [+] Result saved to C:\Shed\Result\7800 Build Shed If you have installed Visual Studio, just run the build.bat batch file, it will create a zip file inside the build folder. License information Copyright (C) 2017 Antonio Parata - @s4tan License: GNU General Public License, version 2 or later; see LICENSE included in this archive for details.1 point
-
ZLoader 4.0 Macrosheets Evolution Posted on 2020-05-06 by William MacArthur, Amirreza Niakanlahiji, and Pedram Amini. In January of 2019, we published a blog titled "Extracting 'Sneaky' Excel XLM Macros" that detailed a technique attackers had adopted for embedding malicious logic under a less understood facet of Excel Spreadsheets, Excel 4.0 macros aka XLM macros. In March of this year, we published "Getting Sneakier: Hidden Sheets, Data Connections, and XLM Macros", that evolved the stealthiness of the approach through the remote embedding of later-stage content via Excel DCONN records. Today, we uncover yet another iteration on this tactic. We are examining a novel and advanced obfuscation scheme with macrosheets embedded in the (newer) Office 2007+ format, versus the legacy OLE format (Object Linking and Embedding). Initial Samples, Low Detection Rates Tracing back through recent history, the first sample we're able to identify from this campaign appeared on VirusTotal on Monday, May 4th (Star Wars Day): InQuest Labs: 955d59e66e24b4585dd044b1576f03ff0e6d8306397766420806979475eededd VirusTotal: 1/58 Detection rates for this and all related samples is rather abysmal, with decent coverage coming from just a single vendor, Qihoo-360, identifying the threat as Macro.office.07defname.gen. While this sample was the earliest, the first sample that caught our eye, and the primary one we'll be examining below is: 8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf You can download this sample to follow along yourself through our open data portal, InQuest Labs. Let's start by highlighting the "hidden" / "very-hidden" sheets and obfuscated AutoOpen hook from xl/workbook.xml: ... <sheets> <sheet name="Sheet1" sheetId="1" r:id="rId1"/> <sheet name="Izdxo9x56IFL1JQZhlGzFBCxVIEmmW" sheetId="2" state="veryHidden" r:id="rId2"/> </sheets> <definedNames> <definedName name="_xlnm.Auto_openhFX8u" hidden="1">Izdxo9x56IFL1JQZhlGzFBCxVIEmmW!$AG$4609</definedName> </definedNames> ... The Microsoft Office suite provides a large, feature-rich, backwards compatible, and ever-changing landscape for malicious actors to discover and leverage new threat tactics. Weighing in at 10's of millions of lines and countless installations globally, it's not hard to see why attackers favor the platform. This novel tactic for pivoting to the execution of embedded logic is the latest in a long and seemingly never-ending trail of successful creativity. An Effective Detection Anchor One consistency among non-exploit-based malware lures is the need to coerce the target into enabling the execution pivot. The requirement for user consent is a double-edged sword. On the one hand, it reduces the immediate impact of the threat. On the other, multiple interactions (consider the DDE based command execution tactic from 2017) can result in lower detection rates. A common tactic that has remained consistent for years is the usage of embedded media to coerce the target user into taking a wary action. This campaign is no different; here's an example sourced from xl/media/image1.jpg: Fig 1. Coercion Lure. Notice the feint green-on-green coloring and low image fidelity. Undoubtedly designed to bypass attempts at Optical Character Recognition (OCR). The choice of JPG over PNG for this image would make a graphic designer cringe, but the lossy format plays to the attackers favor. It's prudent for us to note that InQuest OCR is more than capable of discerning accurate text and producing an alert on the image alone. We can search InQuest Labs for samples that trigger our coercion heuristics. From a sampling of lures associated with this campaign, here is the breakdown of embedded image hashes: Key|Ct (Pct) Histogram 6b435bbf9b254681dafd6abf783632ac|10 (13.16%) ----------------------------------- 667de8e48255ae7183077b889a271c1e| 8 (10.53%) ---------------------------- d98d763d6ca4f1c736b3fbc163669224| 7 (9.21%) ------------------------ d59b82fd9504ba9b130c0d048b492a10| 6 (7.89%) --------------------- cdb3950c2a0e342c793ccdc1eb566803| 5 (6.58%) ------------------ 98e8cd0a87fb4f3549a15c1e52043df4| 5 (6.58%) ------------------ 879ee929dd80ff750e442e3e0befda6b| 4 (5.26%) -------------- 63282400dbdeb0dc7382bd86d768cfd7| 4 (5.26%) -------------- 4a20b2d5bb46837bae61d73291712319| 4 (5.26%) -------------- 444520d98f7fe4b6dd0da106ab87a1fb| 4 (5.26%) -------------- 075356a385451f7a14d7322cd334f2b7| 4 (5.26%) -------------- fa9dbfda5aebfd3d4a8b4c198e38e4bb| 3 (3.95%) ----------- dd607e4daa5b52d1cc0353bf484296e4| 3 (3.95%) ----------- 2764db07e1a670674a65b9f7c3417487| 3 (3.95%) ----------- 01ef5c035ec3aa501b9ab085e862a34f| 3 (3.95%) ----------- Intelligently, the attackers have decided to modify the image dimensions slightly to reduce detection exposure on the media asset. This is a less commonly seen tactic, let's explore the most common images by dimension (instead of cryptographic hash): Key|Ct (Pct) Histogram 574x345|29 (38.16%) ------------------------------------------------------------ 579x345|20 (26.32%) ----------------------------------------- 568x345|13 (17.11%) --------------------------- 563x345| 8 (10.53%) ----------------- 585x345| 4 (5.26%) --------- 607x361| 1 (1.32%) --- 385x393| 1 (1.32%) --- We can see more overlap with this "fuzzier" approach. This extra step taken by the operators to evade detection shows an increased level of sophistication, especially when you consider that many attackers leave valuable XMP identifiers in their graphical assets that can be used as a fast/ accurate detection anchor, as well as a pivot point for mapping relationships between samples. Browsing the graphics embedded in the variety of captured samples, they're all the same with the exception of that last one (385x393), which belongs to sample e468618f7c42c2348ef72fb3a733a1fe3e6992d742f3ce2791f5630bc4d40f2a and carries the following image: Fig 2. Roflanbuldiga. Apparently a "roflanbuldiga"? @RoflanB. No conclusions can or have been drawn from this graphical asset, it's just interesting to note. In the next section we'll take a glance at some of the novel obfuscation tactics employed by this campaign to deter detection. Obfuscated Macrosheet Download either the extracted macrosheet with XML tags stripped, or, a trivially reformatted version that we've prepared to ease readability: XML stripped macrosheet: 8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf Formatted macrosheet: 8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf.formatted There are several interesting obfuscation techniques that are used to evade detection and also complicate automated / manual deobfuscation processes. Fig 3. "veryHidden". The macrosheet is flagged as veryHidden (recall from our previous blog that the BIFF file format supports binary level flags for hidden and very-hidden) and contains a defined name that will execute automatically on open _xlnm.Auto_openhFX8u, this is different than the familiar auto_open and related derivatives. Defenders should note that these names are NOT case-sensitive and that regardless of what suffix is appended to the defined name, Microsoft Excel will autostart the embedded logic. Digging further, note the following: Fig 4. FORMULA.FILL(). It relies on FORMULA.FILL() to generate code. After each FORMULA.FILL() we have a "jump" through usage of the RUN function. While still under active development and not currently supporting all the features of this sample, usage of XLMMacroDeobfuscator can assist us in dissecting further: Fig 5. Loading Cells. The code first fills several cells with a few numbers derived from the current date (NOW()) and the properties of several cells such as their height or their font color (GET.CELL()). For example, GET.CELL(17, EC9093) returns the height of the row which cell EC9093 resides on (i.e., row 9093). To learn more about GET.CELL() take a look at this Excel 4.0 Functions Reference. The first cell that contains the obfuscated formula is AK47754: Fig 6. Cell AK47754. To deobfuscate each character of the formula, the macrosheet logic performs calculations based on two cell values, the value of one cell is already there, the value of the other one calculated based on the current date or some properties of the other cells. In previous samples, they relied only on one calculated value (current date or properties of some cells) to decode all the characters in one formula. As a result, if we could guess what would be one of the deobfuscated characters in the formula, we could find out the calculated value. In fact, we know that the formula always starts with an equal sign (=). As a result, it was trivial to compute the calculated value without knowing the target date or retrieving the properties of other cells. For reference, see the following Tweet from Amir (@DissectMalware). Unfortunately, this oversight has been since addressed by the campaign operators. To deobfuscate a formula, we must now calculate several values. Another change is that all the deobfuscated formulas are scattered over the macrosheet makes it harder to analyze the whole code. In the following YouTube video, we describe in details how one can manually deobfuscate macros in these samples: YARA Hunt Rule, Samples, Shunting InQuest customers can find protection for this and related samples through both our signature-less machine-learning model-based detection engine, as well as a number of our bundled heuristic signatures including event IDs: 1000037, 1000047, 3000562, and 4000173. These signatures rely heavily on the pre-processing and normalizing from our Deep File Inspection (DFI) engine. Additionally, we're open-sourcing a suitable YARA hunting rule for Virus Total Intelligence. A simple rule that looks for standard named macrosheets (note, these names can be altered) within the compressed XLS* format can be found in our public yara-rules Github repository Github/InQuest/yara-rules. While the complete collection of malware samples can be found on InQuest Labs. We have additionally made a collection of 20 samples and their extracted macrosheets available for download in our public malware-samples Github repository our Github repository Github/InQuest/malware-samples. Shout out to @seraphimdomain and @James_inthe_box for initially collaborating with us! As mentioned, this threat evaded detection by most static and dynamic analysis tools we tested. One of our sandbox partners, Joe Security was able to detect the obfuscated macrosheet. Additionally, note that in the behavior graph excerpt from Joe below, the network connectivity is benign. The malware sample is able to "shunt" between the operator's real infrastructure and benign infrastructure based on the validity of the target. Again, a sign of sophistication. The full behavior report is available here. Fig 7. Joe Sandbox Behavior. Let's dive deeper into this concept of network shunting, a tactic known to be in use by the Zloader operators. If the underlying system does not meet the infection requirements as defined by the operators, then the malware logic suddenly changes paths, and "shunts" to an alternative payload. Here is an example of the operating system of the analysis machine not meeting the proper criteria and being "shunted" to a benign Microsoft Azure Cloud IP and domain. skypedataprdcoluks04.cloudapp[.]net 52.114.158[.]91 AS8075 | US | MICROSOFT-CORP-MSN-A An example where the criteria requirements are satisfied and the resulting network traffic connects to actual infrastructure, can be found in this behavioral analysis report from any.run. Fig 9. GET Request. Unfortunately, the payload was offline by the time we attempted to acquire it: hacked wordpress account: shetkarimarket[.]com shared hosting IP: 160.153.133[.]148 AS21501 | DE | GODADDY-AMS Relationship Graphing A core facet of the InQuest platform is drawing relationships between related campaigns through a variety of identified "pivot anchor" such as embedded IOCs. You can get an idea for some of these capabilities through the DFI section on InQuest Labs, which allows for searching for and clustering samples based on a variety of shared anchors. Researchers with access to Virus Total Intelligence can leverage the graph interface to build visual clusters of these representations. This is a work in progress that we'll add additional information to in the future, but to give a high-level glance at the process, we depict an overview here: Fig 8. Virus Total Intelligence Graph. Additional Observations and IOCs As another quite aside, we can automate the extraction of relevant IOCs from InQuest Labs via our open API. In the following example we're mixing direct access via 'curl' as well as showing off python-inquestlabs a command-line interface and importable library that provides a Pythonic interface over the API: $ for hash in `curl -s "https://labs.inquest.net/api/dfi/search/alert?title=Macrosheet%20CHAR%20Obfuscation" | jq -r '.data[].sha256' | sort` do echo $hash; for ioc in `curl -s "https://labs.inquest.net/api/dfi/details/attributes?sha256=$hash" | jq -r '.data[] | select(.attribute=="url") | .value'` do echo " $ioc"; done done For an continuously updating list of matching samples, search InQuest Labs for the CHAR() Obfuscation, as of the time of this writing, the following list of hashes is nearly complete: 01b9b8580230a33a84fa39cf8238fef4d428cd9cf83f9acfb449626ee5b8ea8c InQuest Labs, VT 01eb92643ad7c0d6f962cef1058c0b7bf2cea2ffb26f1addb528aa51d0d801be InQuest Labs, VT 034727d9d7d2405e5c8dc7e7389fbbdee22e9a30da244eb5d5bf91e4a1ba8ea7 InQuest Labs, VT 05d8a7144a984b5f9530f0f9abe96546cfec0ad2c8cdc213bc733d7e14e750df InQuest Labs, VT 06ac09e487c9892aa0389ab18eaf49b3156ccb385c73eea17ebee49ffc6cc2c9 InQuest Labs, VT 0de8f64c4547649d613fec45cb7a3c6b878753045c448ac5aa4a09879ed14c9c InQuest Labs, VT 0f27a954be7a868f71e0635e1f31c294a3dbd48839372c05b99de981789f162d InQuest Labs, VT 0f75b7f01e21ea4fa028c2098f5e98ef2cb5b65aea0799a38323ea762c84ea21 InQuest Labs, VT 10f79daf80a8c4c608fb6cfa7e1d7764dbf569a9a15832174225dda3c981062a InQuest Labs, VT 16fc7fc8328ebb1e695917017bfda60408e2c6d0b6de5d56f4e14b0dca05cb06 InQuest Labs, VT 18305d1efe2efa29dfcdffbfbb8a9f7900ae09f4a3c833aa1a756dea150a1733 InQuest Labs, VT 23378ceac2d30515419a0a4e51c009eba6f910173e09e1292820277804e6b26b InQuest Labs, VT 2418faaee50d2f14c9d2140d2d5e08933b3ce772cc624540f60baaa6757c8ae6 InQuest Labs, VT 284c7be60b77434f91fce2572e45adddca0cdfb25cce4cf63bc4f7e1c17e1025 InQuest Labs, VT 2abbf872f2f44cb8b8fb2bbd7bb0fdc4f6be4eec8098ce97dd931e5953082010 InQuest Labs, VT 3611917480763942f7b8a2e7b407b081059a305bd6fa2a2c0f017a5f8520dbac InQuest Labs, VT 3c4d881f9b9ca8a4a2387f79640d914b0c14792030fb9c762bf65b9e3503f3b8 InQuest Labs, VT 3f73d0063b3eb141f7847c2f5477aff0c95a8f70998b9baa55059bdf74f70525 InQuest Labs, VT 44457b45620327b7bddd7e441a8a369de22dd568457193de0e3317bdda09b4fd InQuest Labs, VT 44558f2bf67d9fb936abd4d28df3efedfa9a863db88158ec3a8d31463c4033e1 InQuest Labs, VT 4538af0fe8dd2c8477f4f0f62a1b468de0af46a681a79ffbc2b99d839c13b826 InQuest Labs, VT 467c668373171fa4900025633e43ddb6e2aea0a2b44573f0648323374404b4ab InQuest Labs, VT 477bf4d158decc2388692fce07c01c73ab94b1002938b50e9df20422230e48da InQuest Labs, VT 4977447b055636772f26ab45416a2580c40bd49963e49687327958fd1700af84 InQuest Labs, VT 4c01b534c5a654e7d1441c34bbc842d6616164f6d547f1c5e8d72040bd934d90 InQuest Labs, VT 4e105f96511b17aab8bbf9d241a665b466e4d0c4dd93af83710ec6423ceb1b0f InQuest Labs, VT 54e24143d4534279197382e3de600d9c9da61809044608d2a0dde59234b9dfe6 InQuest Labs, VT 5690149163be72ab526817ce42254efdfac36cc909656fc9e681a1fc2dec5c68 InQuest Labs, VT 56f1feda6292a6d09ad5fae817bdd384e7644a9990a9fe2fdabf2df013018d54 InQuest Labs, VT 58e2b09425bb741c3e61f76d59d4528a548fbad248649c50fc38b37044ad7947 InQuest Labs, VT 5d126829d37640cd200e99af723b681eff45ed1de3bfbcb0e3c1721c15dfc651 InQuest Labs, VT 60e71559052012c4ba8c306057712da64d8f9f0a9767ed8e69cd38609841e079 InQuest Labs, VT 6654a38cba97469680b916233fa9e3a2cf97a1f6f043def9c76a64fb285f32de InQuest Labs, VT 6d61f0ca90d9872906dd224ff4757150b346acba0977a1106bf51b45b8229db1 InQuest Labs, VT 7951eeb4e888889f8384c75bcf094c5d901ea036c09af0ab0a6bcccfa9375e2d InQuest Labs, VT 7b40c9372dbf3bf008d07fcd94cf9677d80771be5cbf2682ea2004c4c27b2cd2 InQuest Labs, VT 7cce4070d19cb5aaaf5d8ebc92fc3d5fa1cc15112fb2ce750106baca1cfd76c8 InQuest Labs, VT 8718b3c22083fe5185a6781ac1c58a009e859c0e0e00833f0b4a6df58e4468e4 InQuest Labs, VT 89a2f612e3b86974e862334844991e0fc60ff1c2aca26498722670713bb2553a InQuest Labs, VT 8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf InQuest Labs, VT 8e0ffc819b4abaa2753120547ffd70d0d1868b5ad6f269c06eb2ef19cf24eefc InQuest Labs, VT 905bd680d5fcb70da36847406655dd9aaafabff2329e46e2dd89667f9434de92 InQuest Labs, VT 9267ebb91110d9c686bd83ed9c6bade5c5066220873f11e756112dd5a53a4eca InQuest Labs, VT 9309ec88e2ce12fd2304a5007feee41f11b3ce51510c96f95bf64d3770a2064b InQuest Labs, VT 955d59e66e24b4585dd044b1576f03ff0e6d8306397766420806979475eededd InQuest Labs, VT 95d7f675d8c63be4aa86df6670537638557589b2e98a0d3f4087800d05fb7e04 InQuest Labs, VT 97489f14edf02081943ba6bdc4f8ddc61b489c2d114eff2fc560f6225f3c8907 InQuest Labs, VT 9a986ac244f8f65bc151cac813228ab38c9882b37f40d0e4c44ca15ac5ef6353 InQuest Labs, VT a3c2b927224bf96e9c92c7430a42dd0b399d72e27d54edafada375ab5a91871c InQuest Labs, VT a86275faa2934c1b5de6796b7aba5b4b17d1bc33c2c69eeb0aa8a6d560fb3230 InQuest Labs, VT ac1faa3883789dfe81791ba5e653a38b2a89a397dab952a962c642dc89f2c514 InQuest Labs, VT ad2089580d0aa874ef3ecdc8e88487f552e760d32028ddf35574f3d7020ec61c InQuest Labs, VT b77d17b89be9ae351c496c22750a132020668ae4342b05f00f8430ce4cbb4792 InQuest Labs, VT bd7cdfe5d7164ccfd251fbec6d2256a765b496bfff8e72358800fd6f416f785f InQuest Labs, VT bd8e014f428f455df4347aa27a9281a6cfdb6b3375699ef8e581ca05790c5aa1 InQuest Labs, VT c5ef34f410d708520bc5d56cac0d418fed0a8316d53c5e737c28d1a3480fd559 InQuest Labs, VT cdacf5204c7c0ccb7d936ddb684306a80e54a177735c8742eb38d600eb6e7eb7 InQuest Labs, VT d07556af26a8c273f112725a4171898fb7a29ac9b5c1e075cfa2494d4ab9a820 InQuest Labs, VT d1506e2684cba9fc75b909d2b6acbcd9ba8c7ce613fd464e147bd6d2e217ae78 InQuest Labs, VT d8374f78c29ed45265ca65a13b4a84bb2ad6eed434fdd2d9af75394753a7cfb8 InQuest Labs, VT d886df7150bc956ecdae96ad119845558c4413b03383c219c99e175ab219a39e InQuest Labs, VT dbc2e390b9fbd9bbb046cb38582a125aec405cda17a71c29ed2a25abb6c63855 InQuest Labs, VT dbfd7810f2198eee4d92313db61b13ca702946a72c38c3498a99d5ac3943c0de InQuest Labs, VT de511a3682b5a7a0c239395eb53fcce01b2f2d265ce56f477ab246b0df63c9cc InQuest Labs, VT de534a59a6b5a0dab1cde353473657d1a3fb2bd4a8839cf8555afadc8aabbf72 InQuest Labs, VT de9ef9ddcc649559b3166ba13b73da19da93b33bda401e4007190253964aaed4 InQuest Labs, VT e11f77f4fb5dfa34ad52137aa8bda5555ba962528b7e39db4b0a71ec138ed79f InQuest Labs, VT e468618f7c42c2348ef72fb3a733a1fe3e6992d742f3ce2791f5630bc4d40f2a InQuest Labs, VT e75c0c54aeffac6316e56d1e9c363008b5de12de264da4498efa5d56b14e153f InQuest Labs, VT f2a41bbae3de5c4561410e71f7c7005710d1f6f0874f6add0ec5f797dce98076 InQuest Labs, VT f39f7ee103e33432a5faa62ab94bbf29476f0f7d41f5683a257e648a11d69e43 InQuest Labs, VT f405e108872cdfe8ea3d9a57a564c272c2d738316bce3c40df79eeeb312409ab InQuest Labs, VT f4e43a4ef567bf7f3c057478f6eaefb62f7ef57e76bce2275e3eb536be942480 InQuest Labs, VT fd493baba5aaf55b0d9a6f317b66983b20559a673358f472991c528823257b40 InQuest Labs, VT fd961ad277c047ec93d0fb8561ecce285bb9263de2408ba60ef8efd53013549d InQuest Labs, VT fe13dcf6fe72e89413d4b4297205b4ffeab39384f127d18b1d43c89aebe6d6a8 InQuest Labs, VT The following samples were observed to follow a different attack sequence while matching Zloader sample patterns. After further analysis, these hashes were discovered to belong to the Dridex family of banking trojans: 1cddbb162a43e08997bab20b8a2926495763a117dec8c0cbf898844a23d7d2b1 InQuest Labs, VT 316edaff165c6148de4f6672c867da1a3ac3ababd2d1709f2f4c695d4fe637fc InQuest Labs, VT 7217d06b0c3860cd671a95db5df024b64592788634e71683389843693f1ef9cf InQuest Labs, VT 79f8ab4f45113916fcc6e46289f38df6e3db49e47621b439d4df4c3e0145f3d7 InQuest Labs, VT c01e9dc36e11c8ea226f076e31914272e6f6dc58afea557242c6da44d9985fbb InQuest Labs, VT c07f9c7bc2614979354299183a4b0bdf1729af65b36d6b3bc612b8e7947737b0 InQuest Labs, VT c5b99d2371f542cf90063ce1ea55c2dd621658baeb19520737faa7850b1dd9f6 InQuest Labs, VT d1c53de4faccb95a8fe202541aa17147dc5e171dee6f2a26b167794bb7f335ad InQuest Labs, VT ff0f168140bc9deba47986c40e1b43c31b817ad2169e898d62f4f59bb4996252 InQuest Labs, VT Payload URL: hxxp://ginduq[.]com/glex.exe (registered in the past few days and can be heavily pivoted on to gain traction on the Dridex malware campaign). 8.208.78.74 AS45102 | CN | CNNIC-ALIBABA-US-NET - Alibaba (US) Technology Co., Ltd. For further details, comments, and suggestions... please reach out to the team on Twitter @InQuest. Sursa: https://inquest.net/blog/2020/05/06/ZLoader-4.0-Macrosheets-1 point
-
Buna tuturor! SOTUL MĂ ÎNȘEALĂ ! Am ajuns într-un moment foarte dureros din viata mea. Am o căsnicie cu soțul meu de 10 ani, iar de 2 ani de zile lucrează in străinătate si simt ma înșeală. Ma poate ajuta cnv cu un program de citire a sms-urilor in timp real?Am citit despre ss7, dar mi se pare foarte complicat.Stie cineva o alternativă ??? Va rog ajutati-ma .multumesc0 points
-
Buna tuturor! SOTUL MĂ ÎNȘEALĂ ! Am ajuns într-un moment foarte dureros din viata mea. Am o căsnicie cu soțul meu de 10 ani, iar de 2 ani de zile lucrează in străinătate si simt ma înșeală. Ma poate ajuta cnv cu un program de citire a sms-urilor in timp real?Am citit despre ss7, dar mi se pare foarte complicat.Stie cineva o alternativă ??? Va rog ajutati-ma .multumesc0 points
-
Buna tuturor! SOTUL MĂ ÎNȘEALĂ ! Am ajuns într-un moment foarte dureros din viata mea. Am o căsnicie cu soțul meu de 10 ani, iar de 2 ani de zile lucrează in străinătate si simt ma înșeală. Ma poate ajuta cnv cu un program de citire a sms-urilor in timp real?Am citit despre ss7, dar mi se pare foarte complicat.Stie cineva o alternativă ??? Va rog ajutati-ma .multumesc0 points