Archive for July 9th, 2020

Excel spreasheet macro kicks off Formbook infection, (Fri, Jul 10th)


Formbook has been around for years.  According to FireEye, Formbook has been “..advertised in various hacking forums since early 2016.”  My previous diary about Formbook was back in November 2019, and not much has changed since then.  It still bears documentation, though, if only to show this malware is still active and remains part of our threat landscape.

Today’s diary covers a Formbook infection from Thursday, June 9th 2020.

Shown above:  Flow chart for the Formbook infection covered in today’s diary.

The lure

The lure for this particular infection was a malicious Excel spreadsheet.  Searching through VirusTotal, I found a malware sample that I tested in my lab.  The submission name was /tmp/eml_attach_for_scan/2433e76542036ab53b138a98eeda548a.file, so I don’t know what the original file name was.

Shown above: Malicious Excel spreadsheet I found in VirusTotal.

Shown above: The malicious spreadsheet opened on a vulnerable Windows 10 host, ready for me to enable macros.

Initial infection

The initial infection happened immediately after I enabled macros, when my lab host retireved a Windows executable (EXE) for Formbook from hxxp://sagc[.]be/svc.exe and executed the file.  See the images below for details.

Shown above:  My lab host retrieving the Formbook EXE from sagc[.]be after enabling macros.

Shown above: Initial location where the Formbook EXE was saved to my lab host.

Shown above:  Formbook EXE’s final location on my infected lab host with a Windows registry update to keep it persistent.

Data exfiltration

Post-infection traffic was sent to several different domains using URL patterns shown in the next image.

Shown above: Traffic from an infection filtered in Wireshark.

Data stolen by Formbook included a screenshot of my infected lab host, along with keystroke logs, application passwords, sensitive data from the browser chache, and information contained in the clipboard.  This data is temporarily stored in a randomly-named folder under the infected user’s AppDataRoaming directory.  These artifacts are deleted after the data is exfiltrated through Formbook command and control (C2) traffic.

Shown above: Stolen data from the infected Windows host, waiting for Formbook to exfiltrate it over C2 traffic.

Indicators of Compromise (IoCs)

SHA256 hash: 148a026124126abf74c390c69fbd0bcebce06b600c6a35630cdce29a85a765fc

  • File size: 94,829 bytes
  • File name: unknown
  • File type: Microsoft Excel 2007+
  • File description: Excel spreadsheet with macro for Formbook malware

SHA256 hash: 9ebc903ca6847352aaac87d7f904fe4009c4b7b7acc9b629e5610c0f04dac4ef

  • File size: 481,792 bytes
  • File location: hxxp://sagc[.]be/svc.exe
  • File location: C:Users[username]AppDataLocalTempputty.exe
  • File location: C:Program Files (x86)Bwlsuserwzqlrdw.exe
  • File description: Windows executable (EXE) file for Formbook malware

Traffic from an infected Windows host:

Excel macro retrieves Formbook EXE:

  • 92.48.206[.]34 port 80 – sagc[.]be – GET /svc.exe

Formbook post-infection traffic:

  • 157.7.107[.]81 port 80 – www.lovelydays[.]info – GET /ns424/?[long string]
  • 23.235.199[.]50 port 80 – www.rightwebmarketing[.]com – GET /ns424/?[long string]
  • 23.235.199[.]50 port 80 – www.rightwebmarketing[.]com – POST /ns424/
  • 63.250.34[.]167 port 80 – www.mansiobok2[.]info – GET /ns424/?[long string]
  • 63.250.34[.]167 port 80 – www.mansiobok2[.]info – POST /ns424/
  • 34.102.136[.]180 port 80 – www.confidentbeauty[.]tips – GET /ns424/?[long string]
  • 34.102.136[.]180 port 80 – www.confidentbeauty[.]tips – POST /ns424/
  • 198.54.117[.]217 port 80 – www.donateoneeight[.]net – GET /ns424/?[long string]
  • 198.54.117[.]217 port 80 – www.donateoneeight[.]net – POST /ns424/

Unresolved DNS queries from the infected Windows host caused by Formbook:

  • DNS query for www.bakingandcookingandmore[.]com – response: No such name
  • DNS query for www.systemscan12[.]top – response: No such name
  • DNS query for www.lux-dl[.]com – response: No such name
  • DNS query for www.duongtinhot24h[.]com – response: No such name
  • DNS query for www.kcsmqd[.]com – response: No such name
  • DNS query for www.pksbarandgrill[.]net – response: No such name
  • DNS query for www.lx-w[.]com – response: No such name
  • DNS query for www.costcocanadaliguor[.]com – response: No such name
  • DNS query for www.autohaker[.]com – response: No such name
  • DNS query for www.e-golden-boy[.]com – response: No such name
  • DNS query for www.angelalevelsup[.]com – response: No such name

Final words

Formbook infections work nearly the same as they did when I wrote my first diary about Formbook in October 2017.  I’m surprised that I still occasionally run across a sample during my day-to-day research.  An up-to-date Windows 10 with default security settings should prevent these sorts of infection from happening.  I guess it’s still somehow profitable for criminals behind Formbook to continue developing this malware.  Apparently, there’s no shortage of vulnerable Windows hosts for potential targets.

A pcap of the infection traffic and malware samples for today’s diary can be found here.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Active Exploit Attempts Targeting Recent Citrix ADC Vulnerabilities CTX276688 , (Thu, Jul 9th)

I just can’t get away from vulnerabilities in perimeter security devices. In the last couple of days, I spent a lot of time with our F5 BigIP honeypot. But looks like I have to revive the Citrix honeypot again. As of today, my F5 honeypot is getting hit by attempts to exploit two of the Citrix vulnerabilities disclosed this week [1]. Details with proof of concept code snippets were released yesterday [2].

It is not clear exactly which CVE was assigned to which vulnerability, but the possible candidates are CVE-2020-8195, CVE-2020-8196, 

The first issue, probably the more severe one, is allowing for arbitrary file downloads. I see this issue currently exploited from just one IP address: (Amazon.. my honeypot must have Amazone Prime to get exploits next day).

POST /rapi/filedownload?filter=path:%2Fetc%2Fpasswd HTTP/1.1 

The second vulnerability (which I don’t think has a CVE assigned to it, but I will update this diary if I find one), allows retrieval of a PCI-DSS report without authentication. Actually… you still need to “authenticate” I guess, by adding “sig_name=_default_signature_” to the URL :/. 

The full request I see being used (just the Apache log):

POST /pcidss/report?username=nsroot&set=1&type=allprofiles&sid=loginchallengeresponse1requestbody HTTP/1.1" 404 211 "-" "python-requests/2.19.1"

Interestingly: So far, most of the IPs that are scanning for this vulnerability belong to “”

Current IPs:

The vulnerability isn’t all that “bad” (I have to look if the report leaks anything specific). It is not allowing access to anything else. But it could very well be used to identify unpatched devices. Some of the other vulnerabilities patched with this update are “interesting”, but more tricky to exploit.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →