Sunday, March 25, 2018

CERTs, CSIRTs and SOCs after 10 years from definitions

Nowadays is hard to give strong definitions on what are the differences between Security Operation Centers (SOC), Computer Emergency Response Teams (CERT) and Computer Security Incident Response Teams (CSIRT) since they are widely used in many organisations accomplishing very closed and similar tasks. Robin Ruefle (2007) on her paper titled "Defining Computer Security Incident Response Teams" (Available here) gave us a nice idea. She also admits (at the end of the paper) there is not such a strong difference between those common terms: CSIRT, CERT, CSIRC, CIRT, IHT. Her conclusion made me thinking about how this topic has been evolving over the past 10 years.  

Despite her amazing work on defining (let me call) CSIRTs I would give you more details on how those teams have been evolving over the past decade based on my personal experiences directly to the field. Indeed after being involved on building several CERTs, organising CSIRTs and evaluating SOCs I started to spot strong and soft similarities between those teams. Today I'd like to share with you those strong and soft similarities without talking about "differences" since there are not evidence on differences at all.

Each team is asked for CyberSecurity incidents but each team holds specific aims and respond to cybersecurity incident in a specific way. Every team needs to understand what happened after a cybersecurity related incident and this is the very strong common point that every team takes care of: deeply understand what happened. Nobody is better then other or nobody is more addicted respect to other in understanding what really happened during an incident, every team have fully autonomy to figure out what happened through inspection and analytical skills.  The weak similarities come after the initial understanding (analysis) phase. CSIR Teams ad SOC Teams usually study the related incident looking for a response while CERT usually tries to forecast incidents. The definition of response highlight the "weak similarities" between CSIRT and SOC. 

CSIRT usually (but not necessary) look to the incident with a "business" perspective taking care of (but not limited to): communication countermeasures, policy creations, insurance calls, business impact analysis, technical skillset and off course taking care about technical mitigations. For example a CSIRT would evaluate according to the marketing area a communication strategy after a successful incident hit the company, or it could call insurances to evaluate if they will cover some damages or again it could interact to HR area to define missing skillsets in the organisation. Off course it is able to interact with defensive technologies but it's only one ste of its tasks.

A SOC usually (but not necessary) look to the incident with a more "technical" perspective taking care of (but not limited to): incident forensic, log analysis, vendor calls, patch distributions, vulnerability management and software/hardware tunings.  For example after an incident happened to an organisation its SOC would try to block it involving all its resources to block the threat by acting on peripheral devices or running commands directly on user's machines. The SOC deeply understands SIEM technology and it is able to improve it, it is also able to use and to interact through defensive teams and/or technology like sandboxes, proxy, WAF as well. The SOC team holds strong network oriented capabilities.

CER Teams usually take care about incidents following the community sharing procedures such as (but not limited to): feeds, bulletin, Index of Compromises and applying effective governance actions to local IT/SOC teams enabling them to mitigate the incident in the fastest way possibile. CERT team members work a lot with global incidents understanding new threats and tracking known threat movements. They usually work with Threat Intelligence Platforms and with high level dashboard to better understand the evolution of threats to forecast new attacks.

CERTs and SOCs are usually focused on prevention such as (but not limited to): what are the best rules to apply ? What are the procedures in case of incidents ? They are really focused on using threat intelligence in order to spot attack and to block incidents. On the other hand CERTs and CSIRTs are mostly focused on Guidelines and business impact analysis while SOCs and CSIRTs really need to follow incident response procedures in order to apply their high technical skills to mitigate the attack. The following image tries to highlight the main (but not the only) keywords that you would probably deal if you work on a SOC a CERT or in a CSIRT.

The main ideas (but not the only ones) behind the 3 teams could be summed up in the following terms: Mitigation (belongs to SOC), Response (belongs to CSIRT) and Alerting-Prevention (belongs to CERT). I'd like to point out that mitigation and response are quite different concepts. Indeed mitigation holds a technical view of the resolution, response holds a more business view of the resolution. While mitigating an incident means to "take it down" and so to restore the attacked system as it was before the incident, an incident response could include more sophisticated actions that could include the board of director in the decision process as well.
Similar teams but with strong attitudes need different professional profiles. Usually (but again not necessary) SOC Teams need more technical profiles which includes hard skills such as: vendor based certifications, network oriented attitudes and forensic attitudes. CSIRT teams needs a mixup profiles more oriented to technical skills but also with business view such as: risk evaluation, guideline buildings and communication skills. CERTs need to have a wide landscape vision about threats and for such a reason they need to know threat intelligence, they need to know prevention tools and to be part of strong IoC sharing communities. Developer skills are not mandatory on those teams but if "weak and dirty" scripting skills are in place, the entire team will benefit from them. Automation and integration are widely needed on such a teams and a scripting profile would create such an integrations.

As mentioned at the beginning of this "post" it is hard ...  almost impossible ... to give hard definitions about the evolution of "CSIRTs" but it's possible to observe strong and weak similarities in order to better understand what team is most suitable for every organisation.  If you belongs to a "CSIRT" or to a "SOC" or to a "CERT" and you feel like you are doing a little bit of each team according to my post, well, it is ok ! In ten years "things" have been changed a lot from the original definitions  and it's quite normal being involved in hybrid teams.

Wednesday, February 21, 2018

Control Flow Integrity: a Javascript Evasion Technique

Understanding the real code behind a Malware is a great opportunity for Malware analysts, it would increase the chances to understand what the sample really does. Unfortunately it is not always possible figuring out the "real code", sometimes the Malware analyst needs to use tools like disassemblers or debuggers in order to guess the real Malware actions. However when the Sample is implemented by "interpreted code" such as (but not limited to): Java, Javascript, VBS and .NET there are several ways to get a closed look to the "code”.

Unfortunately attackers know what the analysis techniques are and often they implement evasive actions in order to reduce the analyst understanding or to make the overall analysis harder and harder. An evasive technique could be implemented to detect if the code runs over a VM or it could be implemented in order to run the code only on given environments or it could be implemented to avoid debugging connectors or again to evade reverse-engineering operations such as de-obfuscations techniques. Today "post" is about that, I'd like to focus my readers attention on a fun and innovative way to evade reverse-engineering techniques based on Javascript technology.

Javascript is getting day-by-day more important in term of attack vector, it is often used as a dropper stage and its implementation is widely influenced by many flavours and coding styles but as a bottom line, almost every Javascript Malware is obfuscated. The following image shows an example of obfuscated javascript payload (taken from one analysis of mine).

Example: Obfuscated Javascript

As a first step the Malware analyst would try to de-obfuscate such a code by getting into it. Starting from simple "cut and paste" to more powerful "substitution scripts" the analyst would try to rename functions and variables in order to split complexity and to make clear what code sections do. But in Javascript there is a nice way to get the callee function name which could be used to understand if a function name changed over the time. That function is the arguments.callee.caller. By using that function the attacker can create a stack trace where it saves the executed function chaining name list. The attacker would grab function names and use them as the key to dynamically decrypt specific and crafted Javascript code. Using this technique the Attacker would have an implicit control flow integrity because if a function is renamed or if the function order is slightly different from the designed one, the resulting "hash" would be different. If the hash is different the generated key would be different as well and it wont be able to decrypt and to launch specific encrypted code.

But lets take a closer look to what I meant. The following snip shows a clear (not obfuscated) example explaining this technique. I decided to show not obfuscated code up here just to make it simple.

Each internal stage evaluates ( eval() ) a content. On row 21 and 25 the function cow001 and pyth001 evaluates xor decrypted contents. The xor_decrypt function takes two arguments: decoding_key and the payload to be decrypted. Each internal stage function uses as decryption key the name of callee by using the function. If the function name is the "designed one" (the one that the attacker used to encrypt the payload) the encrypted content would be executed with no exceptions. On the other side if the function name is renamed (by meaning has been changed by the analyst for his convenience) the evaluation function would fail and potentially the attacker could trigger a different code path (by using a simple try and catch statement). 

Before launching the Sample in the wild the attacker needs to prepare the "attack path" by developing the malicious Javascript and by obfuscating it. Once the obfuscation took place the attacker needs to use an additional script (such as the following one) to encrypt the payloads according to the obfuscated function names and to replace the newly encrypted payload to the final and encrypted Javascipt file replacing the encrypted payloads with the one encrypted having as a key the encrypted function names.

The attacker is now able to write a Javascript code owning its own control flow. If the attacker iterates such a concept over and over again,  he would block or control the code execution by hitting a complete reverse-engineering evasion technique.
Watch it out and be safe !

Saturday, January 20, 2018

Huge Botnet Attacking Italian Companies

On January 18 a colleague of mine (Luca) called me telling a malicious email was targeting Italian companies. This is the beginning of our new analysis adventure that Luca and I run together.

The email pretended to be sent by "Ministero dell' Economia e delle Finanze" the Italian Department of Treasury  and it had a smart subjects such as:
    • Codici Tributo Acconti
    • F24 Acconti-Codice Tributo 4034
The attacker knows very well the Italian Fiscal Year since those modules are very popular from company administration employees at that time. The attacker would probably exploit this attack path reaching out as many companies as possible. The email address was not coming from the "Ministero dell' economia e delle Finanze" at all, it was coming from the following addresses:
The email looks like :

Malicious eMail

A simple link pointing to a high reputation domain was popping out the default browser and downloading the following Javascript file. The high level of obfuscation and the way the content was provided was so suspicious to be worth to follow the analysis.

Infection: Stage 1 Obfuscated

After a deobfuscation phase the javascript looked much more easy te be read from a human side.

Infection: Stage 1 Clear Text
A romantic "drop and execute" section was happening. A GET connection to was dropping a file named 1t.exe and later on the same script was able to execute the dropped file.  The file 1t.exe was running on the victim machine contacting the Command and Control waiting for further commands.

The new sample looks like GootKit, a weaponized version of Banker Malware.  The malware installs itself and contacts Command and Control asking "what to do" and sending the "stolen credentials" directly to the Command and Control server. Details on IPs, Persistencies and so on, is provided in the IoC section, but todays we wont describe GootKit, we got access to the Dropping site !  

We want to figure out if we might help victims to deactivate the malicious botnet by providing as much as possible details without focusing on reverse the Malware per se since appears to be known. 

By getting further analyzing the dropping web site we immediately understood that the same URL was dropping another threat. The parallel threat the dropping website was spreading to the world was called "Nuovo Documento 2008" and it was a .bat file as follows.

New Threat Stage 1

That executable .bat file on a first stage opens up a browser pointing to a legitimate image but later on it uses an notorious technique called "certutil for delivery of file" to drop and execute an another file. This technique is well described here  by carnal0wnage. Basically the attacker uses the certutil.exe program do download a Base64 encoded payload, to decoded it and to run it. This technique is very silent since the User-Agent of certutils.exe is not suspicious because it needs to connect outside the company networks to check certificates, so not much IPS rules on it. The dropped file name unslss.exe appears to be very close to the previous analyzed one (1t.exe) it contacts the same C&C and it behaves in the similar way.   But again we wont focus on reverse such a malware but rather we wont be able to reach the highest number of IoC to protect as much as possible the victims. By analyzing the Dropping website we founded that a significative number of connections had additional referrers, so we decided to focus our attention on how many DNS were pointing to such a domain. We did it and the result was quite impressive (please see the Dropping URLS IoC Section). 

Following the research on the dropping website we found an interesting log within all the connection coming from possible victims. We collected that log, and we built the following possible infection list (possible Victims). We wont publish the Victims IP addresses but if you can prove you are legitimated by your company to ask that logs we can give you (for free, of course)  the IP addresses we've found related to your company. Please contact A detailed list of possible infected networks follows. 

Possible Victims:

  • ACI informatica s.p.a.

    • AGOS-AS
    • AGSM Verona Spa
    • ASGARR Consortium GARR
    • Acantho S.p.a
    • Alfanews S.r.l.
    • Ambrogio s.r.l.
    • Asco TLC S.p.A.
    • Autostrade-as
    • BT Italia
    • BT Italia S.p.A.
    • Banca Monte Dei Paschi Di Siena S.P.A.
    • Brennercom S.p.A.
    • COLT Technology Services Group Limited
    • Camera dei deputati
    • Cesena Net srl
    • Clouditalia Telecomunicazioni S.p.A.
    • Comune Di Brescia
    • Comune di Bologna
    • Consortium GARR
    • Consorzio per il Sistema Informativo
    • Costacrociere-as
    • Duebite-as
    • E4A s.r.l.
    • Energente S.r.l.
    • FINECO Banca del Gruppo Unicredit
    • Fastweb
    • Forcepoint Cloud Ltd
    • GenyCommunications
    • Global Com Basilicata s.r.l.
    • H3G Italy
    • Hynet S.R.L.
    • IBSNAZ
    • ICT Valle Umbra s.r.l.
    • InAsset S.r.l.
    • InfoCamere SCpA
    • Infracom Italia S.p.A.
    • Inrete s.r.l
    • Insiel- Informatica per il sistema degli enti loca
    • di Stefania Peragna impresa individual
    • Intred S.p.A.
    • KPNQWest Italia S.p.a.
    • LEPIDA
    • Lepida S.p.A.
    • Liguria Digitale S.C.p.A.
    • Linea Com S R L
    • Linkem spa
    • Lombardia Informatica S.p.A.
    • Mandarin S.p.A.
    • Mc-link SpA
    • Metrolink S.R.L.
    • Ministero dell'Interno
    • Mnet srl
    • NGI SpA
    • Nemo S.r.l.
    • Nordcom S.p.a.
    • Officine Informatiche Srl
    • Progetto Evo S.r.l.
    • Provincia di Reggio nell'Emilia
    • Qcom spa
    • Raiffeisen OnLine GmbH
    • Regione Basilicata
    • Regione Toscana
    • Regione Veneto
    • STI ADSL
    • Sardegnait-as
    • Societa' Gestione Servizi Bp S.p.A.
    • TELEX S.r.l.
    • TWT S.p.A.
    • Telecom Italia
    • Terra S.p.a.
    • Time-net S.r.l.
    • Tiscali SpA
    • Trenitalia SpA
    • Trentino Network S.r.l.
    • Universita' degli Studi di Milano
    • Venis S.p.A.
    • Videotime SPA
    • Vodafone Group Services GmbH
    • Vodafone Italia DSL
    • Vodafone Omnitel B.V.
    • Vodafone Omnitel N.v.
    • WIIT S.p.A.
    • Welcome Italia S.p.A
    • Wind Telecomunicazioni
    • Wind Telecomunicazioni SpA
    Following the found IoC provided by the long "analysis journey". I managed this analysis over the night, so I am sure there would be some imprecisions, but I preferred to speed up the entire analysis process to give the opportunity to block such infamous threat as soon as possible.

    Hope it helps the community.

    Original Early Warning (Italian): Yoroi Early Warning


    • eMail:
    • Dropping URLS:
    • Command and Controls
    • Hashes
      • 63d6927881d4978da4e162c17d82e9c009d0a93e
      • 7ea33f51b6c4aa54beee7fd878886339c22d2232
      • 8cae0dc9255978a35cfd8db64cbe80001400de9b
      • 839ff9f4c3980ac67d4cbef296520ee364a0911f
      • 8cae0dc9255978a35cfd8db64cbe80001400de9b

    UPDATE 1:

    Many AV and NGFirewall Companies contacted me and they updated "signatures", so probably on from now everybody having such a products should be protected.

    UPDATE 2:

    Victims are still growing UP !

  •  Asco TLC S.p.A.
  •  ASGARR Consortium GARR
  •  Bancalombarda
  •  B.B.Bell SPA
  •  Brennercom S.p.A.
  •  BrianTel SRL
  •  Consiglio Nazionale delle Ricerche
  •  Elsynet S.r.l.
  •  Fastcon-as
  •  Informatica System S.r.l.
  •  Inrete s.r.l
  •  IPERV Internet Per Il Veneto
  •  I.S.I.D.E. S.p.A.
  •  Mc-link SpA
  •  Nemo S.r.l.
  •  Regione Autonoma Friuli Venezia Giulia
  •  Tiscali SpA
  •  UmbriaNet
  •  Universita' degli Studi di Palermo
  •  AGOS-AS
  •  Comune di Bologna
  •  ENEA - Agenzia nazionale per le nuove tecnologie
  •  Intred S.p.A.
  •  Iren Energia S.p.a
  •  Linkem spa
  •  NGI SpA
  •  Phoenix Informatica Bancaria S.p.A.
  •  Telemar s.p.a.
  •  TWT S.p.A.
  •  COLT Technology Services Group Limited
  •  Consortium GARR
  •  H3G Italy
  •  Banca Monte Dei Paschi Di Siena S.P.A.
  •  BT Italia S.p.A.
  •  Infracom Italia S.p.A.
  •  KPNQWest Italia S.p.a.
  •  Vodafone Omnitel B.V.
  •  Liguria Digitale S.C.p.A.
  •  Regione Toscana
  •  Welcome Italia S.p.A
  •  Wind Telecomunicazioni
  •  Lepida S.p.A.
  •  Vodafone Italia DSL
  •  Fastweb
  •  Telecom Italia

  • Thursday, December 28, 2017

    Info Stealing: a new operation in the wild

    Attack attribution is always a very hard work. False Flags, Code Reuse and Spaghetti Code  makes impossible to assert "This attack belongs to X". Indeed nowadays makes more sense talking about Attribution Probability rather then Attribution by itself. "This attack belongs to X with 65% of attribution probability" it would be a correct sentence.

    I made this quick introduction because the following analysis would probably take the reader to think about specific attribution, but it wont be so accurate, so please be prepared to have not such a clear conclusions.

    Today I'd like to show an interesting analysis of a quite new InfoStealer Malware delivered by eMail to many International Companies. The analysis shows up interesting Code Reuse capabilities, apparently originated by Japanese Attackers reusing an English Speaker Attacker source code. Again I have not enough artifacts to give attributions but only few clues as follows. In the described analysis, the original sample was delivered by (with high probability a compromised South Africa account) to one of my spamming email addresses.

    The obtained sample is a Microsoft Word document within macro in it. The macros were heavily obfuscated by using four rounds of substitutions and UTF-8 encoding charsets (which, by the way, is super annoying). The following image shows the obfuscated macro code with UTF-8 charsets.

    Stage 1: Obfuscation
     By using oletools and "tons" of cups of coffee (to be awake until late night to make recursive steps) I finally was able to extract the invoked command, showed in the following image.

    Stage 1: Invoked Command
    A fashionable powershell command drops and executes: hxxp:// Powershell seems to be a "must have" in contemporary Malware. Analyzing the "dropping" url and tracking down the time it is in "Index Of" mode (2017-0-13), I suspect it is not a compromised website rather a crafted web server or a compromised host of a dead company.

    Dropping Web Site

    By surfing on the Malware propagator web site I founded out many malicious executables (sees IoC section) each one showing up specific behaviors such as: password stealers, RAT and Banking Trojans. Even if the samples were developed for different targets, all of them shared the following basic behaviors:

    • Check for victims IP address before getting into Malicious activities (maybe related to targeted activities)
    • Install itself into auto execution path
    • Tries to fingerprint the target system (such as CPU, HD, Memory, Username, System, etc..)
    • Sniff for Keystrokes

    I'd like to write a simple analysis for each found sample, but today time is not my friend, so let's focalize to one of the malicious samples. Let's get done the received sample by digging into the "second stage" dropped by the powershell "first stage" from After few seconds on second stage (off.exe) it became clear that it was a .NET software. By reversing the interpreted .NET language some clear text comments appeared interesting. Japanese language such as comments and variable names came out from static analysis. Let's have a look to them.

    Stage 2: Apparently Japanese characters

    While the sample pretends to be compiled from "Coca-Cola Enterprise" (maybe a target operation against Coca-Cola ? Or a targeted operation agains Coca-Cola Suppliers ? So why it ended up to my inbox ? Anyway ... ) google translator suggests me that Japanese characters are in text: such as the "Entry Point", "Class names" and "Function Names". 

    Stage 2: Japanese Names and Self Encoding Structures

    It was not hard to figure out that Stage 2 was auto-extracting bytes from itself (local variables) and saving them back to hard drive after having set up auto execution registry key on windows local registry.  The following image shows the xoring function used to decrypt converted bytes to the real payload. 

    Stage 2: Xoring function to extract Stage 3

    On my run, the xored payload took the name of GIL.exe; another .NET  executable. We are now facing the third stage. By analyzing the decompiled sample it became clear that:
    • The coding style was quite different from the previous stage (Stage 2)
    • The implementation style was different from the previous stage as well
    • The sample was interested on information about the user, the machine, the webservices on the PC and to many more windows specific parameters.
    Stage 3:  New Language in Strings and Class names
    Stage 3: New Code Style

    By closely investigating Stage 3, the analyst would probably notice the heavy presence of "decorators", a different format in the definition style and last but not least the code composition. Everything looks like belonging to different single developers. The variable language, the comments structure and the general usage of terms, takes the analyst to believe in having found two different developers belonging to different cultures (maybe countries). Finally the malware looks for users, computes, and webservices informations and drops everything up to C2 by posting parameters to :

    Following the principal IoC for the described threat.
    • Hash Stage 1:
      • 7f1860673de9b1c2e6f7d6963a499e8ba4e412a1
      • bf4a26c9e52a8cacc7afd7d95d197bff1e47fb00
    • Hash Stage 2:
      • ac55ee783f3ed0bd23eccd01040a128dc6dc7851
    • Hash Stage 3:
      • 6a38e4acd9ade0d85697d10683ec84fa0daed11c
    • Persistence: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\kij %APPDATA%\Roaming\kij\kij.exe
    • Dropping URL:
    • Command and Control:
    • Related hashes from harvesting Dropping URL:
      • 62c9d2ae7bafa9c594230c570b66ec2d4fa674a6
      • b15b69170994918621ceb33cb339149bdff5b065
      • 55abcfb85e664fbc8ad1cb8b60a08409c2d26caa
      • f843427e9b7890f056eaa9909a5103bba6ffb8fd
      • f2b81e66fcb1032238415b83b75b3fe8bf28247d
      • cab90f7c935d355172b0db123d20b6a7d1403f65
      • c1ba30d7adec6d545d5274f95943f787ad4c03e7
      • ed9959bb0087f2c985b603cee0e760f3e0faaab15
      • c93851627ffd996443f85d916f3dbedd70e0ff69
      • 144b34b4816062c2308a755273159e0460ffd604
      • 98293b80ccf312a8da99c2b5ca36656adebd0d0f 
      • 2875d1b54337b1c17c8f4cd5f6b2d579667ee3d9 
      • 0b4299ffb3f9aa59e19dd726e79d95365fe1d461
      • 46bb0b10d790a3f21867308e7dcdeb06784a1570
      • 0960726560a94fbbb327aa84244f9588a3c68be8 
      • a480a75c3af576e5656abadb47d11515a18a82be
      • 2ba809c53eda2a475b1353c34f87ce62b6496e16
      • 5b0c3071aa63e18aa91af59083223d3cceb0fa3c 
      • dc780bf338053e9c1b0fdf259c831eb8a2768169

    As final thought I'd like to highlight the following key concept of that analysis:
    • From a single email, the analyst could discover attacker's assets, mapping them and disarming them (through IoC). 
    • The analyzed code shows apparent evidences to belonging to different groups of attackers.
    • The analyzed samples show code reuse. Code reuse is dangerous because it makes attackers more powerful and extremely quick to change Malware behavior.
    Hope you enjoyed.

    Wednesday, November 15, 2017

    Unprotecting VBS Password Protected Office Files

    Hi folks,
    today I'd like to share a nice trick to unprotect password protected VB scripts into Office files. Nowadays it's easy to find out malicious contents wrapped into OLE files since such a file format has the capability to link objects into documents and viceversa. An object could be a simple external link, a document itself or a more complex script (such as Visual Basic Script) and it might easily interact with the original document  (container) in order to change contents and values.

    Attackers are frequently using embedded VB Scripts to perform malicious actions such as for example (but not limited to): payload downloading, landing steps, environment preparation and payload execution. Such a technique needs "the user agreement" before the execution takes place, but once the user gave the freedom to execute (see the following image) the linked code on the machine, the VB script would be free to download content from malicious website and later on to execute it the victim machine.

    Enable "Scripting" Content

    Cyber Security Analysts often need to read "raw code"  by opening it and eventually digging into obfuscation techniques and anti-code analysis in order to figure out what it really does. Indeed contemporary malware performs evasive techniques making the simple SandBox execution useless and advanced attackers are smart enough to block VB code through complex and strong passwords. Those techniques make the "raw code analysis" hard if the unlocking password is unknown. But again, the a Cyber Security Analyst really needs to open the document and to dig into "raw code" in oder to defend victims. How would I approach this problem ?

    Following a simple method to help cyber security analysts (NB: this is a well known technique) to bypass password protected VB Scripts.

    Let's suppose you have an Excel file within Visual Basic code, and you want to read the password protected VB Script. Let's call such a first Excel file: victim_file.

    As a first step you need to open the victim_file. After opening it you need to create a additional excel file. Let's call it: injector_file.xlsm. Open the VB editor and add the following code into Module1.

    Now create a new module: Module2 with the following code. It represents the "calling function". Run it and don't close it. 

    It's time to come back to your original victim_file, let's open the VB Editor and: here we go ! Your code is plain clear text !

    At that point you are probably wondering how this code works. So let's have a quick and dirty explanation about it. Once the VBProject gets opened it visualizes a dialogBox asking for a password (a String). The WinAPI eventually checks if the input string is equals to the encoded static string (file body not code body) and it returns "True" (if the strings are equals) or "False" (if the strings are not equals). The function Hook() overrides the User32.dll DialogBoxParamA returning parameter by making it returns always the value "True".  

    Technically speaking:
    • Raw 45 saves the original "call" (User32.dll DialogBoxParamA) parameters into TmpBytes
    • If the password is correct TempBytes(0) gets the right pointer to the current process 
    • If the password is not correct the script saves the original bytes into OriginalBytes (length 6)
    • Raw 50  takes the address of MwDialogBoxProgram
    • Raw 52  forces the right handler 
    • Raw 53  saves the current value
    • Raw 54  forces the return par as True
    • Raw 56  moves the just crafted parameters into the right location into user32.dll
    Have nice VBA Password un-protection :D

    This is a well-known method: it is not new.
    I wrote it down since it becomes useful for cyber security analyst to fight against Office Macro malware. Don't use it unlawfully.
    Do not use it to break legal documents.
    I am not assuming any responsibility about the usage of such a script.
    It works on my machine :D  and I will not try to get it working on your :D (programming Horror humor)

    Monday, November 13, 2017

    TEDxMilano: What a great adventure !

    Hi folks, 
    today I want to share my "output" of a super nice adventure I had this year which took me to actively participate to TEDxMilano. It is definitely one of the most exiting stage I've been so far.

    My usual readers would probably think: "Hey Man, you are a technical person, you should participate to DefCON, Black Hat, NullCon, SmooCon, Toorcon and much more technical conferences like these where you have the opportunity to show reverse engineering techniques, new vulnerabilities or new attack paths,  I wont see you on a TEDx conference! ".

    Well actually I have participated to a lot of such a conferences (just take a look to "Selected Publications" on top of this page) but you know what ? CyberSecurity is a hybrid world where technologies meet people, where most sophisticated evasion techniques meet human irrationality and where a simple "click" can make the difference between "levelUP" or "GameOver". So I believe being able to comunicate such a complex world to a "not technical people" is a great way to contribute to the security of our digital Era. If you agree (and you know Italian language) please have a look ! I will appreciate.  

    “As long as a human being is the one profiting from an attack, only a human being will be able to combat it.” This is how we can define Marco Ramilli’s essence, a computer engineer and an expert in hacking, penetration testing, and cyber security. Marco obtained a degree in Computer Engineering and, while working on a Ph.D. in Information Security, served the security division of the U.S. Government’s National Institute of Standards and Technology, where he conducted research on Malware Evasion and Penetration Testing techniques for the electronic voting system. In 2014 he founded Yoroi, a startup that has created one of the best cyber security defense centers he ever developed. This talk was given at a TEDx event using the TED conference format but independently organized by a local community.

    Tuesday, September 26, 2017

    Advanced 'all in memory' CryptoWorm


    Today I want to share a nice Malware analysis having an interesting flow. The "interesting" adjective comes from the abilities the given sample owns. Capabilities of exploiting, hard obfuscations and usage of advanced techniques to steal credentials and run commands. 

    The analyzed sample has been provided by a colleague of mine (Alessandro) who received the first stage by eMail. A special thanks to Luca and Edoardo for having recognized XMRig during the last infection stage.   

    General View.

    The following image shows the general view of the entire attack path. As you might appreciate from the picture, that flow could be considered a complex flow since many specific artifacts were included in the attack phases.  The initial stage starts by abusing the user inexperience taking him/her to click on a first stage file called  (in my case) y1.bat. Nowadays eMail vector is one of the most favorite vectors used by attackers and easily implemented to deliver malicious contents. Once the first stage is run, it downloads and executes a second stage file called info6.ps1: a heavy obfuscated PowerShell script which drops (by de-obfuscate it directly on body) three internal resources: 
    1. Mimikatz.dll. This module is used to steal user administrative credentials.
    2. Utilities. This module is used to scan internal networks in order to propagate the infection, it is used to run several internal utilities such as (but not limited to): de-obfuscation routines,  ordering arrays and running exploits. This module is also used to drop and execute an additional file (from the same server) named info.vbs.
    3. Exploits. This module is a set of known exploits such as eternalblue7_exploit and eternal_blue_powershell used from the initial stage of attack to infect internal machines .
    Full Stage Attack Path

    The last stage (info.vbs) drops and runs an executable file which has been recognized to be XMRig. XMRig is an open sourced Monero CPU Miner, freely available on github. The infection tries to propagate itself by scanning and attacking internal resources through the Exploit module, while the XMRig module mines Monero cryptocurrency giving to the attacker fresh "crypto money" by stealing victims resources. 


    A romantic but still "working" .bat file is propagated to the victim by email or message. Once the user clicks on it, the .bat file would run the following command spawning a powershell able to download and run a script called info6.ps1 from

    Stage1: Downloads and Run 
    The downloaded powershell file is clearly divided into two macro blocks both of them obfuscated. The following image shows the two visual sections which I am going to call them: "half up" (section before the "new line") and "half down" (section after the "new line").

    Stage2: Two Visual Sections to be explored
    While the "half up" section fairly appears to be a Base64 encoded text file, the "half down" section looks like encoded through a crafted function which, fortunately (and certain), appears in clear text at the end of such a file. By editing that function it is possible to modify the decoding process making it saving the decoded text file directly to a desired folder. The following image shows the decoded second stage "half dow" section.  

    Decoded Second Stage "Half Down"
    Analyzing the section code it would be easy to agree that the main used functions are dynamically extracted from the file itself, by performing a substring operations on the current content.




    The content of $fa variable and every function related to it is placed in the "half up" section which after being decoded looks like the following image.

    Decoded Second Stage "Half Up"
    The second stage "half up" code is borrowed from Kevin Robertson (Irken), the attacker reused many useful functionalities from Irken including the Invoke-TheHas routine which could be used through SMB to execute commands or to executes direct code having special rights. 

    A surprisingly interesting line of code is found on the same stage (Second stage "half down"): NTLM= Get-creds mimi mimi  where the Get-creds function (coming from the Based64 decoded "half up") runs, by using the reflectoin techique, a DLL function. So by definition the mimi parameter has to be a DLL file included somewhere in the code. Let's grab it by running the following code: $fa.sUBStrInG(406494,1131864) Where 406494 is the start character and the 1131864 is the last character to be interpreted as a dynamic loaded library. Fortunately the dropped DLL is a well known library, widely used in penetration testing named Mimikatz. It would be clear that the attacker uses the Mimikatz library to grab user (and eventually administrators) passwords. Once the passwords stealing activity is done the Malware starts to scan internal networks for known vulnerabilities such as MS17/10. The identified exploits have been borrowed from tevora-thrat and woravit since same peace of codes, same comments and same variable names have been found. If the Malware finds vulnerability on local area networks it tries to infect the machine by injecting itself (info6.ps1) through EthernalBlue and then it begins its execution from the second Stage.

    On the same thread the Malware drops and runs a .vbs file (Third Stage) and it gets persistence through WMIClass on service.

    Introducing the Third Stage
     The info.vbs drops and executes from itself a compiled version of XMRIG renamed with the "mimetic" string: taskservice.exe.  Once the compiled PE file (XMRig) is placed in memory the new stage starts it by running the following commands.

    Third Stage Execution of Monero Miner
    The clear text Monero address is visible on the code. Unfortunately the Monero address is not trackable so far. 

    Monero address: 46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE

    and the used server is: stratum+tcp:// "%temp%\taskservice.exe  -B -o stratum+tcp:// -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE  -o stratum+tcp://  -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE -o stratum+tcp://   -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE -p x" ,0
    Many interesting other sections should be analyzed but for now lets stop here.


    Please find some of the most interesting IoC for you convenience.

    - URL:
    - Monero Address: 46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE
    - Sha256: 19e15a4288e109405f0181d921d3645e4622c87c4050004357355b7a9bf862cc
    - Sha256: 038d4ef30a0bfebe3bfd48a5b6fed1b47d1e9b2ed737e8ca0447d6b1848ce309


    We are facing one of the first complex delivery of cryptocoin mining Malware. Everybody knows about CryptoMine, BitCoinMiner and Adylkuzz Malware which basically dropped on the target machine a BitCoin Miner, so if you are wondering: Why Marco do you write: "one of the first Malware" ? Well actually I wrote one of the "first complex" delivery. Usual coins Malware are delivered with no propagation modules, with no exploiting module and with not file-less techniques. In fact, the way this Monero CPU Miner has been delivered, includes advanced methodologies of memory inflation, where the unpacked Malware is not saved on Hard Drive (a technique to bypass some Anti Virus) but it is inflated directly on memory and called directly from memory itself. 

    We can consider this Malware as a last generation of -all in memory- CryptoWorm. 

    Another interesting observation, at least on my personal point of view, comes from the first stage. Why the attacker included this useless stage ? It appears to be not useful at all, it's a mere dropper wth no controls nor evasions. The attacker could have delivered just the second stage within the first stage in it, assuring a more stealth network fingerprint. So why the attacker decided to deliver the CryptoWorm through the first stage ? Maybe the first stage is part of a bigger framework ? Are we facing a new generation of Malware Generator Kits ? 

    I wont really answering to such a questions right now, but contrary I'd like to take my readers thinking about it.

    Have fun