Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Baza de date emails pt shop online

    Posturi insuficiente pentru Market. Categorie gresita. Gunoi.
  3. Cumpar baza de date email

    Posturi insuficiente pentru Market. Categorie gresita. Gunoi.
  4. Vand Pagini de Facebook Internationale

    Categorie gresita. Posturi insuficiente pentru market. Gunoi.
  5. Vești bune! Toată lumea poate descărca gratuit 13 programe gratuite de la WonderFox 2017 Campanie de acordare a zilei de mulțumire pentru Software! Lista software-ului de tip giveaway: WonderFox HD Video Converter Factory Pro Filigranul software WiseCare 365 Pro Seed4.Me VPN WinToFlash Professional RightNote Standard ONLYOFFICE Office Cloud Epubor Ultimate Folder Marker Home Clipà.Vu preloaders Animiz Professional DoYourData Uninstaller Pro Ora: 16 noiembrie-29 noiembrie Pagina campaniei: http://www.videoconverterfactory.com/thanksgiving/?erf
  6. Today
  7. Uber concealed a hack that affected 57 million customers and drivers, the company has confirmed. The 2016 breach was hidden by the ride-sharing firm which paid hackers $100,000 (£75,000) to delete the data. The company's former chief executive Travis Kalanick knew about the breach over a year ago, according to Bloomberg, which first broke the news. The hackers found 57 million names, email addresses and mobile phone numbers, Uber said. Within that number, 600,000 drivers had their names and licence details exposed. Articol complet: http://www.bbc.co.uk/news/technology-42075306
  8. Realizez aplicatii web

    Multumesc, te mai astept.
  9. Vand 3 site-uri

    Apai..faci site-uri pe banda. La tine a face un site inseamna a pune o tema nulled pe un host + un domeniu amarat si gata site-ul. S-a umplut internetul de copii (dubluri) si site-uri aparute ca ciupercile. * Puteai macar sa ascunzi cercurile alea de la messenger cand ai facut printurile...totusi.
  10. Keyword stuffing in title and contents

    Keyword stuffing is regarded as a good way of black hat SEO. To rank, a website up on the search engine result page (SERP) keyword stuffing is a good process. Keyword stuffing is a way of injecting more keyword in the content. Usually, upto 4% keyword in the content is natural. but if we put more in our content is would be deemed as keyword stuffing. when a crawler comes to the website it watches more keyword so it enables your site to show on high-rank position. But, you might face a penalty for keyword stuffing. So you need to do it perfectly
  11. By Anatoly Kazantsev on November 8, 2017. 10:00 am sursa: https://securelist.com/using-legitimate-tools-to-hide-malicious-code/83074/ The authors of malware use various techniques to circumvent defensive mechanisms and conceal harmful activity. One of them is the practice of hiding malicious code in the context of a trusted process. Typically, malware that uses concealment techniques injects its code into a system process, e.g. explorer.exe. But some samples employ other interesting methods. We’re going to discuss one such type of malware. Our eye was caught by various samples for .NET that use the trusted application InstallUtil.exe from the Microsoft .NET Framework (information from Microsoft’s website: “The Installer tool is a command-line utility that allows you to install and uninstall server resources by executing the installer components in specified assemblies. This tool works in conjunction with classes in the System.Configuration.Install namespace”). The technique was described by information security researcher Casey Smith aka subTee (Proof of Concept). Briefly, the console utility InstallUtil.exe runs a malicious .NET assembly, bypassing the entry point of the assembly; all malicious activity is then hidden in the context of the trusted process. The spreading of malicious samples follows a standard pattern: they basically reach the user in a password-protected archive, and the executable file icons in most cases are chosen specially so that the victim perceives the file as a normal document or photo. We also encountered executable files masquerading as a key generator for common software. To begin with, the malicious content of the generator got inside the %TEMP% folder, where it was run later in the described manner. Users are misled by executable file icons Analysis All the malicious files we encountered were heavily obfuscated, which complicated their manual analysis. We took the sample 263dc85de7ec717e8940b1ccdd6ee119 and deobfuscated its strings, classes, methods, and fields. Here’s how the file looked before deobfuscation: Sample before deobfuscation InstallUtil.exe allows file execution to start not from the .NET assembly entry point: execution begins from a class inherited from System.Configuration.Install.Installer. To facilitate manual analysis, this class was renamed InstallUtilEntryClass in the sample under investigation. The code in static class constructors is known to execute first when the assembly is loaded into memory, a feature utilized by the authors of this piece of malware. Let’s examine the behavior of the malicious file in the order of methods execution. First up is FirstMainClass, since its constructor is marked with the keyword “static” and assembly execution begins with it: The static constructor of FirstMainClass that is triggered when the assembly is loaded The constructor does the following: CheckSandboxieEnvironment() determines whether the file is running in Sandboxie by attempting to load the SbieDll.dll library. If the library can be loaded, the malicious process terminates; CheckVirtualBoxEnvironment() searches for the vboxmrxnp.dll library, which belongs to VitrualBox. If the library can be found, the malicious process likewise terminates; AddResourceResolver() adds a method for handling the resource load event. This method unpacks the assembly, which is packed by the Deflate algorithm, from a specific resource and loads the assembly into memory; The method responsible for loading the assembly from the resource The assembly is unpacked from the resource and loaded into memory The UnpackAllAssemblies() method of the AssemblyResourceLoader class iterates through all the assembly resources and, if the resource name contains the string “+||”, unpacks the assemblies from these resources. The assemblies unpacked by this method are required by the malicious file to operate, and are legitimate libraries: Interop.MSScript.Control, Interop.TaskScheduler, SevenZipSharp; RemoveZoneIdentifier() deletes the NTFS alternate stream Zone.Identifier through the command line to prevent a warning at startup if the file was downloaded from the Internet. The authors made a slight mistake in the command line (“cmd.exe /c (echo. > file path:Zone.Identifier) 2 > Null”) by leaving a space between the characters 2 and >, which produces an error in the console: The warning issued on deleting Zone.Identifier The ElevatePrivilegesProxy() method is the wrapper for the ElevatePrivileges() method, which in turn uses the known UAC bypass technique described by Matt Nelson aka enigma0x3. Control then passes to the traditional entry point—the Main() method, which is located in the Form5 class: The traditional entry point is the Main() method We see that a WMI object is retrieved after a 30-second pause. Next, the ScriptControlClassInstance object is customized, which the language (Visual Basic script) and the body of the script are transferred to: The script that runs the executable file using InstallUtil.exe The AddCode() method adds and executes a VB script that runs the current assembly using InstallUtil.exe. After that, the current process is closed by calling Environment.Exit(0). At the next stage, the malicious object is run using the InstallUtil tool and once more executes the static constructor of the FirstMainClass class examined above; control passes to the static constructor of the InstallUtilEntryClass class, which, as mentioned, is inherited from System.Configuration.Install.Installer: The static class constructor called by InstallUtil.exe The functions of this class include: Copying the malicious file to %APPDATA%\program\msexcel.EXE, setting the Hidden+System attributes for the “program” folder, running msexcel.EXE, and terminating the current process; Adding the copied file to autorun (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run); Creating a task called “filesqmaepq0d.tnk” that runs msexcel.EXE every minute to ensure survival on the victim’s computer; Checking if the malicious process is already running. An event with the name “78759961M” is created, and if such an event already exists in the system, the new process terminates; Creating the Form5 class and calling its destructor. Let’s sum up the interim results: all the actions described above (entrenchment in the system, elevation of privileges, startup from a trusted application) are essentially laying the foundation for the main task. Let’s move on to analyzing the next stage of the preparatory actions, which will take us closer to the heart of the malicious activity. The malicious assembly contains, inter alia, five classes inherited from System.Windows.Forms.Form. Inheritance from the Form class is not accidental: in its inheritance hierarchy it implements several interfaces, one of which is IDisposable, which allows to override the Dispose() method for its own purposes. Dispose() methods are called by the garbage collector in order to free up unmanaged resources used by the class when closing or unloading the assembly. Now let’s look at the source code of the Dispose() method of the Form5 class: The overridden Dispose() method of the Form5 class As we can see, various methods are executed at each iteration of the cycle, and the results are saved. Let’s take a closer look: At the first iteration, the full path to the RegAsm.exe utility from .NET Framework is retrieved; A chain of nested methods is called with a view to decoding strings from Base64 that are stored in another class and unpacking the resulting array using the SevenZipExtractor library. As a result, we get an array that is the remote administration tool NanoCore Client; The PERun.dll library is loaded from the assembly that was previously unpacked from the resource into memory; A class with the name “RunPE” and the Run method of this class are sought in this library; At the final iteration, the parameters are transferred and the Run method is called. Knowing that the legalProgramPath variable contains the full path to the legitimate utility RegAsm.exe, PEFileByteArray contains the executable file in the form of a byte array, while the class name is RunPE; it is not hard to figure out that the Run() method employs the technique of hiding malicious code in the address space of the trusted process RunPE. This technique is widely known and described here, for instance. Deep inside the Run() method, a legitimate utility process is created in CREATE_SUSPENDED state (the sixth parameter is 4u): Creating a legitimate program process in CREATE_SUSPENDED state Eventually, the RegAsm.exe process is loaded in the address space and starts to execute the payload: the remote administration tool NanoCore Client. Only trusted processes remain in the list of running processes, and even an experienced user might not realize that the system is compromised: Only legitimate utilities can be seen in the list of running processes RegAsm.exe was chosen as the “carrier” because (a) it is a legitimate utility from Microsoft, (b) it is located in the same directory as InstallUtil.exe, and (c) a utility from .NET Framework calling another utility from the same framework is less suspicious than calling, say, notepad.exe. In fact, the use of RegAsm.exe is not critical: the “carrier” could be any program that does not arouse the suspicion of security software and users. It is also important that all actions involving a malicious module are executed in memory, which allows file scanners to be bypassed. As we’ve mentioned, this sample contains NanoCore Client, which can be used to control the victim’s computer, take screenshots, record keystrokes, download files, and much more. It should be noted that the payload here can be anything: from “fashionable” encrypters and miners to advanced Trojans. Conclusion Malware writers employ various tricks to conceal malicious activity, and the above technique allowing the execution of malicious code in the context of two legitimate programs is an obvious example. Detecting this kind of concealment method requires a behavioral analysis of the program. Kaspersky Lab’s security solutions detect this behavior as PDM: Trojan.Win32.Generic and PDM: Exploit.Win32.Generic. IOC (MD5) 263DC85DE7EC717E8940B1CCDD6EE119 payload: EF8AF3D457DBE875FF4E3982B34F1DE9 3E4825AA1C09E27C2E6A1309BE8D6382 payload: 82709B139634D74DED404A516B7952F0 7E3863F827C1696835A49B8FD7C02D96 payload: D1A9879FFCB14DF70A430E59BFF5EF0B 8CB8F81ECF1D4CE46E5E96C866939197 payload: D8652841C19D619D2E3B5D7F78827B6E FDF4086A806826503D5D332077D47187 payload: BF4A3F4B31E68B3DE4FB1F046253F2D0
  12. Sursa: https://www.zscaler.com/blogs/research/microsoft-dde-protocol-based-malware-attacks Introduction Over the past few weeks, there have been several reports about the Microsoft Dynamic Data Exchange (DDE) vulnerability. To no one's surprise, hackers have been quick to exploit this vulnerability to spread malware through rigged Microsoft Word documents. In this same timeframe, the Zscaler ThreatLabZ team has seen a number of these malicious documents using the DDE vulnerability to download and execute malware. Most of the payloads we saw were Remote Access Trojans (RATs), ransomware, and backdoors. In this blog, we will share a detailed technical analysis of a few of these exploitations and their payloads. Background The Microsoft Dynamic Data Exchange (DDE) protocol allows data to be transferred between applications. These applications can use DDE for one-time data transfers or for continuous exchanges; for example, a Microsoft Word document that uses data from an Excel spreadsheet is updated automatically through DDE as the spreadsheet data is updated. The DDE protocol sends messages between applications that share data and uses shared memory to exchange data between the applications. Microsoft Word documents have been used before to spread malware, but in those cases the victim would have to manually enable macros for the payload to be downloaded onto the victim’s system. With the DDE vulnerability (feature) in Microsoft Word, attackers can embed a malicious script that can download and execute malware without the use of macros. Case I: DDE protocol abuse leads to post-exploitation using PowerShell One Word file we analyzed exploited the DDE vulnerability to download and execute a PowerShell script using a post-exploitation framework. Filename - Communications_Suggestions_by_Press_Office_Director.docx The document looks like this: Fig1: Malicious document Generally, fake documents like this are spread via an email campaign targeting small and large groups of businesses in numerous industry sectors. The workflow of the document is as follows: Fig2: Document Workflow (case I) In this document, the attacker uses the DDE protocol to launch a Windows command line tool (cmd.exe), which uses PowerShell to download and execute the malware from a given URL. The field content looks like this: Fig3: DDE field code It downloads and executes a file using cmd.exe and PowerShell, which is present at the following URL: hxxp://citycarpark[.]my/components/com_admintools/mscorier. The downloaded data (mscorier) is an obfuscated batch script that creates a PowerShell script and executes it. Fig4: Obfuscated batch script (payload 1) This script downloads another payload (wsdprintproxy) from hxxp://185.128.42[.]194/wsdprintproxy and stores it in the following registry to make itself persistent: HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\ThemeVersion Fig5: Storing payload 2 in registry Fig6: Registry entry of payload 2 For persistence, payload 1 also creates two scheduled tasks, which execute the obfuscated script. Fig7: Code for persistence One scheduled task is created with name FlashUpdateServiceInit, which runs daily at 11:00 a.m., and another task with name FlashUpdateService, which runs daily at 3:00 p.m. After these tasks run, the script bypasses the PowerShell ScriptBlock logging, which means that the first execution of the malicious script will turn off all further logging. Fig8: Enabling script block logging To download its next payload, the malware initiates a GET request with the cookie “session=j4ppw/hpWdU/l5V3v9eymlAYxmE=” and downloads payload 3 from hxxps://185.128.42[.]194:8080/news.php. Fig9: Downloading payload 3 from server Fig10: Downloaded encrypted payload 3 The downloaded data is encrypted with RC4. Data[0:4] = IV Data[4:length(Data)] = Encrypted data Key is hardcoded in the script which is: Key = “a231fe7690a85f02eb147f53229c8e02” Fig11: RC4 algorithm The script will decrypt the downloaded data. It is, again, a PowerShell script, which is executed after decryption. The decrypted PowerShell script sends the encrypted RSA key with “IV” to the server at: hxxps://185.128.42[.]194:8080/news.php. In response, the server sends the encrypted AES key to victim. The script fetches information from the victim’s machine, encrypts it with the AES key, and sends it to the server at: hxxps://185.128.42[.]194:8080/process.php. Nonce|Server_URL|UserDomainName|UserName|Machine|IPAddress|OperatingSystem|True(if UserName=”system”)Otherwise False|CurrentProcessName|ProcessID|powershell|PowershellVersion The server responds with the final payload PowerShell script which appears to be a part of the PowerShell empire framework post-exploitation. Transactions of this post-exploitation framework look like this: Fig12: Network transactions The PowerShell empire is a post-exploitation framework that provides a Metasploit-like framework in PowerShell and Python. It includes different types of backdoors with multiple modules. It deals strictly with Windows machines and is extremely useful in penetration testing. In some cases, however, attackers use this framework to hijack a user’s system and perform malicious activities. Case II: DDE protocol abuse leads to Locky ransomware In another recent case, a campaign of spam emails was delivering a Word document attachment that used the DDE technique, and the final payload of that campaign is Locky ransomware. Fig 13: DDE protocol abuse leads to Locky ransomware (case II) In this case, attackers are writing obfuscated malicious field code in Word documents to evade detection; this code can be found in word-document.xml after extraction. Fig14: Field word-document.xml obfuscated code The exploit downloads the encoded PowerShell script from: hxxp://lestrangeresearch[.]com/kdjsw23FGS. It then decodes and executes it through cmd. Fig15: Encoded PowerShell (payload 1) The decoded script look like this: Fig16: Decoded PowerShell script (payload 1) The decoded PowerShell script has six hardcoded malicious URLs. The script will try to download the content from a URL and store it in %temp% with the name hti4.exe. Upon successful download, the script executes the downloaded file. Fig17: Downloaded payload 2 Payload 2 is the intermediate payload. Its function is to check the system for specified parameters. If it satisfies specific criteria, it then downloads encrypted data from: hxxp://spooner-motorsport[.]com. Fig18: Encrypted Locky ransomware (payload 3) This encrypted data is decrypted and launched by the intermediate payload (payload 2). After decryption, the final payload is Locky ransomware, which encrypts the files, appends the .asasin extension after encryption, and demands ransom in Bitcoin for decryption. Fig19: Ransom note (asasin.bmp) Fig20: Locky payment site Case III: Attack in New York Recently, researchers at McAfee found a new phishing campaign from Russia's hacking group APT28 known as “Fancy Bear.” APT28 capitalized on the recent terror attack in New York City by spreading email with an attached malicious Word document named IsisAttackInNewYork.docx, and the document appears to leverage the DDE technique. In this case, the first-stage payload was a PowerShell script that downloads another base64 encoded PowerShell script. After that, the second-stage payload script downloads a new variant of Seduploader, which is spyware capable of taking screenshots, gathering sensitive data, and other intrusive activities. Preventions: If a document contains embedded malicious DDE code, it shows the following warning to users as they open it. Fig 21: Microsoft Word warning The best way to prevent this DDE attack vector is to click “No” when this dialog box appears; this will stop further execution of the malware. Another way to prevent this attack is to disable it by modifying the registry. Microsoft has also published security advisoryfor securely opening Microsoft documents that contain a DDE field. Conclusion: Attackers are abusing the Microsoft DDE protocol to download and execute malware using PowerShell. In an earlier case, PowerShell led to an entire post-exploitation framework used for penetration testing. But attackers are using the framework for malicious purposes, such as stealing a user’s sensitive information, uploading and executing malware on a user’s machine, altering the user’s data, and so on. In recent cases, the DDE protocol led to ransomware, including Locky, which encrypts the victim’s data and demands ransom for the decryption. The malware analyzed in this blog is detected as COM.Downloader.DDE
  13. alimentare bitcoin

    Daca vrei sa cumperi ceva, la aparatele de le gasesti prin oras trebuie sa cumperi minim de 100 de lei
  14. Yesterday
  15. alimentare bitcoin

    Prin ce ai spus, ai deschis mintile la multi, cred ca am vazut 1000 de topicuri pe alte forumuri in care toti ziceau ca e anonim, ca plm, ca nu stiu ce. 80% din cei care stiu de existenta acestei monede cred ca este total anonima si nu poti fii gasit daca o utilizezi, ideea asta e cea mai mare prostie, ca nu e un wallet anonim, este unul public. (M-am referit strict la cumparaturile care implica obiecte fizice nu virtuale)
  16. alimentare bitcoin

    Lasa prostiile ca nu e de tine. Va jucati cu lucruri pe care nu le intelegeti. Ca idee: Bitcoin ofera 0(zero) anonimitate. Toate tranzactiile BTC sunt publice. Deci ca idee daca vrei sa utilizezi BTC pentru orice fel de achizitie reala poti fi gasit (relativ usor). Daca vrei anonimitate zkSNARKS in Monero sau scheme de spalat bani Multi-level. (Banuiesc ca te depasesc tare). PS: Ca iti cere buletinul sau nu BTC e tot public si walletul tau va fi foarte usor legat de persoana ta fizica. Complete: Bitcoin's blockchain technology assures imutability, descentralization, distribution of all the transactions. It DOES NOT assure: anonimity, privacy, security (of private keys), protection against corelation attacks.
  17. Many people realize that smartphones track their locations. But what if you actively turn off location services, haven’t used any apps, and haven’t even inserted a carrier SIM card? Even if you take all of those precautions, phones running Android software gather data about your location and send it back to Google when they’re connected to the internet, a Quartz investigation has revealed. Since the beginning of 2017, Android phones have been collecting the addresses of nearby cellular towers—even when location services are disabled—and sending that data back to Google. The result is that Google, the unit of Alphabet behind Android, has access to data about individuals’ locations and their movements that go far beyond a reasonable consumer expectation of privacy. Quartz observed the data collection occur and contacted Google, which confirmed the practice. The cell tower addresses have been included in information sent to the system Google uses to manage push notifications and messages on Android phones for the past 11 months, according to a Google spokesperson. They were never used or stored, the spokesperson said, and the company is now taking steps to end the practice after being contacted by Quartz. By the end of November, the company said, Android phones will no longer send cell-tower location data to Google, at least as part of this particular service, which consumers cannot disable. It is not clear how cell-tower addresses, transmitted as a data string that identifies a specific cell tower, could have been used to improve message delivery. But the privacy implications of the covert location-sharing practice are plain. While information about a single cell tower can only offer an approximation of where a mobile device actually is, multiple towers can be used to triangulate its location to within about a quarter-mile radius, or to a more exact pinpoint in urban areas, where cell towers are closer together. The practice is troubling for people who’d prefer they weren’t tracked, especially for those such as law-enforcement officials or victims of domestic abuse who turn off location services thinking they’re fully concealing their whereabouts. Although the data sent to Google is encrypted, it could potentially be sent to a third party if the phone had been compromised with spyware or other methods of hacking. Each phone has a unique ID number, with which the location data can be associated. The revelation comes as Google and other internet companies are under fire from lawmakers and regulators, including for the extent to which they vacuum up data about users. Such personal data, ranging from users’ political views to their purchase histories to their locations, are foundational to the business successes of companies like Facebook and Alphabet, built on targeted advertising and personalization and together valued at over $1.2 trillion by investors. The location-sharing practice does not appear to be limited to any particular type of Android phone or tablet; Google was apparently collecting cell tower data from all modern Android devices before being contacted by Quartz. A source familiar with the matter said the cell tower addresses were being sent to Google after a change in early 2017 to the Firebase Cloud Messaging service, which is owned by Google and runs on Android phones by default. Even devices that had been reset to factory default settings and apps, with location services disabled, were observed by Quartz sending nearby cell-tower addresses to Google. Devices with a cellular data or WiFi connection appear to send the data to Google each time they come within range of a new cell tower. When Android devices are connected to a WiFi network, they will send the tower addresses to Google even if they don’t have SIM cards installed. “It has pretty concerning implications,” said Bill Budington, a software engineer who works for the Electronic Frontier Foundation, a nonprofit organization that advocates for digital privacy. “You can kind of envision any number of circumstances where that could be extremely sensitive information that puts a person at risk.” The section of Google’s privacy policy that covers location sharing says the company will collect location information from devices that use its services, but does not indicate whether it will collect data from Android devices when location services are disabled: According to the Google spokesperson, the company’s system that controls its push notifications and messages is “distinctly separate from Location Services, which provide a device’s location to apps.” Android devices never offered consumers a way to opt out of the collection of cell tower data. “It is really a mystery as to why this is not optional,” said Matthew Hickey, a security expert and researcher at Hacker House, a security firm based in London. “It seems quite intrusive for Google to be collecting such information that is only relevant to carrier networks when there are no SIM card or enabled services.” While Google says it doesn’t use the location data it collects using this service, its does allow advertisers to target consumers using location data, an approach that has obvious commercial value. The company can tell using precise location tracking, for example, whether an individual with an Android phone or running Google apps has set foot in a specific store, and use that to target the advertising a user subsequently sees. Via qz.com
  18. alimentare bitcoin

  19. alimentare bitcoin

    Pai ti se cere actul de identitate
  20. Ajutor!!

    O sa vorbesc cu un avocat si o sa vad ce se poate face in acest caz. Mulțumesc încă o data pentru sfatul si ajutorul primit. Toate respectele mele!
  21. Vand 3 site-uri

    iti cumpar eu site-ul daca imi dai si profilul fetei din screen
  22. DNS-shell

  23. Ajutor!!

    Asta este partea proasta. Te lasă sa renunți cu condiția sa cedezi altcuiva .
  24. RPC Forge

    RPC Forge RPC Forge is a local Python fuzzer of Windows RPC interfaces available over ALPC. The fuzzer parses the interfaces definitions and automatically performs valid calls on the RPC methods. This is more a PoC than a real fuzzer. Its aim was to be able to forge a valid serialized stream reaching RPC methods code without being rejected by the Windows RPC Runtime (because of bad arguments type leading to error: RPC_X_BAD_STUB_DATA). Thus, it doesn't contain any instrumentation in the server side to improve code coverage. RPC Forge was part of our work on Windows RPC and was introduced at PacSec 2017: A view into ALPC-RPC. Internal working Select one random interface Connect and bind to it through epmapper RPC service or fixed ALPC endpoint name (see Usage) Randomly choose one method Generate valid call arguments according to the method parameters types based on Sulley Generator Save the logs (call information) in a local file (depends on config.py) Perform the call with marshaled (NDR) generated arguments Extract any context_handle from the returned stream (to forge calls expecting a valid context_handle) Loop (Step 1 or Step 3) Deps PythonForWindows providing a Python implementation to play with ALPC and RPC. Sursa: https://github.com/sogeti-esec-lab/RPCForge
  25. Detecting reflective DLL loading with Windows Defender ATP msft-mmpcNovember 13, 2017 Today's attacks put emphasis on leaving little, if any, forensic evidence to maintain stealth and achieve persistence. Attackers use methods that allow exploits to stay resident within an exploited process or migrate to a long-lived process without ever creating or relying on a file on disk. In recent blogs we described how attackers use basic cross-process migration or advanced techniques like atom bombing and process hollowing to avoid detection. Reflective Dynamic-Link Library (DLL) loading, which can load a DLL into a process memory without using the Windows loader, is another method used by attackers. In-memory DLL loading was first described in 2004 by Skape and JT, who illustrated how one can patch the Windows loader to load DLLs from memory instead of from disk. In 2008, Stephen Fewer of Harmony Security introduced the reflective DLL loading process that loads a DLL into a process without being registered with the process. Modern attacks now use this technique to avoid detection. Reflective DLL loading isn’t trivial—it requires writing the DLL into memory and then resolving its imports and/or relocating it. To reflectively load DLLs, one needs to author one’s own custom loader. However, attackers are still motivated to not use the Windows loader, as most legitimate applications would, for two reasons: Unlike when using the Windows loader (which is invoked by calling the LoadLibrary function), reflectively loading a DLL doesn’t require the DLL to reside on disk. As such, an attacker can exploit a process, map the DLL into memory, and then reflectively load DLL without first saving on the disk. Because it’s not saved on the disk, a library that is loaded this way may not be readily visible without forensic analysis (e.g., inspecting whether executable memory has content resembling executable code). Instrumentation and detection A crucial aspect of reflectively loading a DLL is to have executable memory available for the DLL code. This can be accomplished by taking existing memory and changing its protection flags or by allocating new executable memory. Memory procured for DLL code is the primary signal we use to identify reflective DLL loading. In Windows 10 Creators Update, we instrumented function calls related to procuring executable memory, namely VirtualAlloc and VirtualProtect, which generate signals for Windows Defender Advanced Threat Protection (Windows Defender ATP). Based on this instrumentation, we’ve built a model that detects reflective DLL loading in a broad range of high-risk processes, for example, browsers and productivity software. The model takes a two-pronged approach, as illustrated in Figure 1: First, the model learns about the normal allocations of a process. As a simplified example, we observe that a process like Winword.exe allocates page-aligned executable memory of size 4,000 and particular execution characteristics. Only a select few threads within the Winword process allocate memory in this way. Second, we find that a process associated with malicious activity (e.g., executing a malicious macro or exploit) allocates executable memory that deviates from the normal behavior. Figure 1. Memory allocations observed by a process running normally vs. allocations observed during malicious activity This model shows that we can use memory events as the primary signal for detecting reflective DLL loading. In our real model, we incorporate a broad set of other features, such as allocation size, allocation history, thread information, allocation flags, etc. We also consider the fact that application behavior varies greatly because of other factors like plugins, so we add other behavioral signals like network connection behavior to increase the effectiveness of our detection. Detecting reflective DLL Loading Let’s show how Windows Defender ATP can detect reflective DLL loading used with a common technique in modern threats: social engineering. In this attack, the target victim opens a Microsoft Word document from a file share. The victim is tricked into running a macro like the code shown in Figure 2. (Note: A variety of mechanisms allow customers to mitigate this kind attack at the onset; in addition, several upcoming Office security features further protect from this attack.) Figure 2. Malicious macro When the macro code runs, the Microsoft Word process reaches out to the command-and-control (C&C) server specified by the attacker, and receives the content of the DLL to be reflectively loaded. Once the DLL is reflectively loaded, it connects to the C&C and provides command line access to the victim machine. Note that the DLL is not part of the original document and does not ever touch the disk. Other than the initial document with the small macro snippet, the rest of the attack happens in memory. Memory forensics reveals that there are several larger RWX sections mapped into the Microsoft Word process without a corresponding DLL, as shown in Figure 3. These are the memory sections where the reflectively loaded DLL resides. Figure 3. Large RWX memory sections in Microsoft Word process upon opening malicious document and executing malicious macro Windows Defender ATP identifies the memory allocations as abnormal and raises an alert, as shown in Figure 4. As you can see (Figure 4), Windows Defender ATP provides context on the document, along with information on command-and-control communication, which can allow security operations personnel to assess the scope of the attack and start containing the breach. Figure 4. Example alert on WDATP Microsoft Office 365 Advanced Threat Protection protects customers against similar attacks dynamic behavior matching. In attacks like this, SecOps personnel would see an Office 365 ATP behavioral detection like that shown in Figure 5 in Office 365’s Threat Explorer page. Figure 5. Example Office 365 ATP detection Conclusion: Windows Defender ATP uncovers in-memory attacks Windows 10 continues to strengthen defense capabilities against the full range of modern attacks. In this blog post, we illustrated how Windows Defender ATP detects the reflective DLL loading technique. Security operations personnel can use the alerts in Windows Defender ATP to quickly identify and respond to attacks in corporate networks. Windows Defender Advanced ATP is a post-breach solution that alerts SecOps personnel about hostile activity. Windows Defender ATP uses rich security data, advanced behavioral analytics, and machine learning to detect the invariant techniques used in attacks. Enhanced instrumentation and detection capabilities in Windows Defender ATP can better expose covert attacks. Windows Defender ATP also provides detailed event timelines and other contextual information that SecOps teams can use to understand attacks and quickly respond. The improved functionality in Windows Defender ATP enables them to isolate the victim machine and protect the rest of the network. For more information about Windows Defender ATP, check out its features and capabilities and read about why a post-breach detection approach is a key component of any enterprise security strategy. Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge. Christian Seifert Windows Defender ATP Research Sursa: https://blogs.technet.microsoft.com/mmpc/2017/11/13/detecting-reflective-dll-loading-with-windows-defender-atp/?ocid=cx-twitter-mmpc
  26. ENGINEERING BLOG Dangers of the Decompiler A Sampling of Anti-Decompilation Techniques November 16, 2017 / Markus Gaasedelen Traditional (assembly level) reverse engineering of software is a tedious process that has been made far more accessible by modern day decompilers. Operating only on compiled machine code, a decompiler attempts to recover an approximate source level representation. "... and I resisted the temptation, for years. But, I knew that, if I just pressed that button ..." --Dr. Mann (Interstellar, 2014) There’s no denying it: the science and convenience behind a decompiler-backed disassembler is awesome. At the press of a button, a complete novice can translate obscure ‘machine code’ into human readable source and engage in the reverse engineering process. The reality is that researchers are growing dependent on these technologies too, leaving us quite exposed to their imperfections. In this post we’ll explore a few anti-decompilation techniques to disrupt or purposefully mislead decompiler-dependent reverse engineers. Positive SP Value The first technique is a classic, but ‘noisy’, method of disrupting the Hex-Rays decompiler. In IDA Pro, the decompiler will refuse to decompile a function if it does not clean up its stack allocations (balancing the stack pointer) prior to returning. The error message raised by IDA when a positive stack pointer is detected during decompilation This happens occasionally (innocently) when IDA cannot reasonably devise the type definition of certain function calls. As an anti-decompilation technique, a developer can elicit this behavior in a function they would like to ‘hide’ by using an opaque predicate that disrupts the balance of the stack pointer. // // compiled on Ubuntu 16.04 with: // gcc -o predicate predicate.c -masm=intel // #include <stdio.h> #define positive_sp_predicate \ __asm__ (" push rax \n"\ " xor eax, eax \n"\ " jz opaque \n"\ " add rsp, 4 \n"\ "opaque: \n"\ " pop rax \n"); void protected() { positive_sp_predicate; puts("Can't decompile this function"); } void main() { protected(); } The instruction add rsp, 4 in the positive_sp_predicate macro defined above can never get executed at runtime, but it will trip up the static analysis that IDA performs for decompilation. Attempting to decompile the protected() function generated by the provided source yields the following result: Using opaque predicates to unbalance the stack pointer as a means of anti-decompilation This technique is relatively well known. It can be fixed via patching, or correcting the stack offset by hand. In the past I’ve used this technique as a simple stopgap to thwart novice reverse engineers (eg, students) from skipping the disassembly and going straight to decompiler output. Return Hijacking An aspiration of modern decompilers is to accurately identify and abstract away low-level bookkeeping logic that compilers generate, such as function prologues/epilogues or control flow metadata. Compiler generated function prologues will typically save registers, allocate space for the stack frame, etc Decompilers strive to omit this kind of information from their output because the concepts of saving registers, or managing stack frame allocation do not exist at the source level. An interesting artifact of these omissions (or perhaps a gap in the Hex-Rays decompiler heuristics) is that we can ‘pivot’ the stack just prior to returning from a function without the decompiler throwing a warning or presenting any indication of foul play. Pivoting the stack pointer (RSP) onto a ROP chain embedded into the binary Stack pivoting is a technique commonly used in binary exploitation to achieve arbitrary ROP. In this case, we (as developers) use it as a mechanism to hijack execution right out from underneath an unsuspecting reverse engineer. Those focused solely on decompiler output are guaranteed to miss it. Decompiling main, and a deceptive function ending with a stack pivot We pivot the stack onto a tiny ROP chain that has been compiled into the binary for this exercise of misdirection. The end result is a function call that is ‘invisible’ to the decompiler. Our discretely called function simply prints out ‘Evil Code’ to prove that it was executed. Executing the compiled binary making use of the return hijacking anti-decompilation technique The code used to demonstrate this technique of hiding code from the decompiler can be found below. // // compiled on Ubuntu 16.04 with: // gcc -o return return.c -masm=intel // #include <stdio.h> void evil() { puts("Evil Code"); } extern void gadget(); __asm__ (".global gadget \n" "gadget: \n" " pop rax \n" " mov rsp, rbp \n" " call rax \n" " pop rbp \n" " ret \n"); void * gadgets[] = {gadget, evil}; void deceptive() { puts("Hello World!"); __asm__("mov rsp, %0;\n" "ret" : :"i" (gadgets)); } void main() { deceptive(); } Abusing ‘noreturn’ Functions The last technique we’ll cover exploits IDA’s perception of functions that are automatically labeled as noreturn. Some everyday examples of noreturn functions would be exit(), or abort() from the standard libraries. While generating the pseudocode for a given function, the decompiler will discard any code after a call to a noreturn function. The expectation is that in no universe should a function like exit() ever return and continue executing code. The code directly following a call to a noreturn function is invisible to the decompiler. If one can trick IDA into believing a function is noreturn when it actually isn’t, a malicious actor can quietly hide code behind any calls made to it. The following example demonstrates one of many ways we can achieve this result. // // compiled on Ubuntu 16.04 with: // gcc -o noreturn noreturn.c // #include <stdio.h> #include <stdlib.h> void ignore() { exit(0); // force a PLT/GOT entry for exit() } void deceptive() { puts("Hello World!"); srand(0); // post-processing will swap srand() <--> exit() puts("Evil Code"); } void main() { deceptive(); } By compiling the code above and running a short Binary Ninja based post-processing script against the resulting binary, we can swap the pushed ordinal numbers in the Procedure Linkage Table. These indexes are used to when resolving library imports at runtime. Swapping PLT ordinal numbers in the ELF header In this example we swap the ordinals for srand() with exit() and doctor some calls for compile-time convenience. As a result, IDA believes the deceptive() function in the modified binary is calling exit(), a noreturn function, instead of srand(). Decompiling main, and deceptive function concealing code behind a noreturn call The exit() call we see in IDA is in-fact srand() (effectively a no-op) at runtime. The effect on the decompiler is almost identical to the return hijacking technique covered in the previous section. Running the binary demonstrates that our ‘Evil Code’ is getting executed, unbeknownst to the decompiler. Executing the compiled binary making use of the noreturn anti-decompilation technique While the presence of malicious code is blatant in these examples, hiding these techniques within larger functions and complex conditionals makes them exceptionally easy to glaze over. Conclusion Decompilers are an impressive but imperfect technology. They operate on incomplete information and do their best to approximate for us humans. Malicious actors can (and will) leverage these asymmetries as a means of deception. As the industry grows more reliant on the luxuries of today’s decompilers, the adoption of anti-decompilation techniques will increase and evolve in the same vein as anti-debugging and anti-reversing have. Sursa: https://blog.ret2.io/2017/11/16/dangers-of-the-decompiler/
  27. BlueBorne RCE on Android 6.0.1 (CVE-2017-0781) [English] A few days ago, the company Armis published a proof of concept (PoC) of a remote code execution vulnerability in Android via Bluetooth (CVE-2017-0781), known as BlueBorne. Although BlueBorne refers to a set of 8 vulnerabilities, this PoC uses only 2 of them to achieve its goal. The exploitation process is divided into 2 phases, first the memory leak vulnerability (CVE-2017-0785) is used to know the memory addresses and bypass the ASLR protection, and thus make a call to the function libc library system and execute code on the phone, in this case a reverse shell. The original source code of the Armis PoC is oriented to Android 7.1.2 on Pixel and Nexus 5X phones, and it is implied that to use it in another model it is only necessary to modify in the code the offsets of libc and bluetooth libraries. Later we will see how in the version 6.0.1 analyzed, the changes in the code of the bluetooth library are significant, complicating the exploitation and forcing us to make more modifications in the code of the PoC. To perform some of the following actions it is necessary to have root privileges on the phone. Libraries download The first step is to extract the libraries to analyze them on our computer with IDA or Radare. $ adb pull /system/lib/hw/bluetooth.default.so $ adb pull /system/lib/libc.so libc system function We open libc.so with Radare and look for the system function. As we can see it is in the address 0x3ea04, which we introduce in the variable LIBC_TEXT_STSTEM_OFFSET = 0x3ea04 +1. $ r2 -A libc.so > afl~system 0x0003ea04 10 184 sym.system Articol complet: https://jesux.es/exploiting/blueborne-android-6.0.1-english/
  1. Load more activity